About Andrei Savu

Andrei Savu · ‎12-04-2014

You can get the list file and the relevant key from here: http://archive.cloudera.com/director/ubuntu/precise/amd64/director/ You need to copy cloudera-director.list to /etc/apt/sources.list.d, load the key (via sudo apt-key add archive.key). After all that the initial apt-get install command should just work.

Andrei Savu · ‎12-04-2014

Have you configured the proper repositories? What operating system are you using?

Andrei Savu · ‎11-17-2014

> What would happen if I tried adding the nodes back in via the manager 'add new hosts to cluster'? The behavior is undefined. Director needs to do that on its own. It can't deal with external cluster topology modifications.

Andrei Savu · ‎11-17-2014

If you decide to use ephemeral storage (it's free - included in the instance price) then a 50-100GB root disk drive will probably work just fine.

Andrei Savu · ‎11-17-2014

I understand. My suggestion would be to evaluate some of the first / second generation AWS instance types with magnetic drives for ephemeral storage. For example m1.xlarge has 1.6TB of storage. My guess is that you will get better performance but I don't know if that's acceptable from a cost perspective. With regards to backups - S3 is the way to go unless you have a very strict SLA that requires another online cluster.

Andrei Savu · ‎11-17-2014

Even for long running clusters ephemeral storage is better from a performance perspective. You already get replication from HDFS. Are you using EBS as way to recover from instance failure?

Andrei Savu · ‎11-17-2014

A restart is required after changing any configuration option from that file.

Andrei Savu · ‎11-17-2014

How are you using those 1TB volumes? By default Director will try to use ephemeral storage for HDFS.

Andrei Savu · ‎11-17-2014

Currently Director considers this type of failures as being unrecoverable. We are planning to make it possible to retry in a future release but that wouldn't solve this failure. For your usecase what you probably need to do is to increase the SSH read timeout by changing the following configuration: lp.ssh.readTimeoutInSeconds either as a command line argument or by editing the configuration files under /etc/cloudera-director-server or /etc/cloudera-director (used when running in standalone mode). The read timeout should be larger than the amount of time it takes to perform that resize operation.

Andrei Savu · ‎11-17-2014

Thanks for feedback. We are working a better story for error recovery and root cause analysis.

Online	Offline
Last Visited	‎05-19-2017 10:51 AM

Member Since	‎10-13-2014 03:10 PM
Last Visited	‎05-19-2017 10:51 AM
Posts	119
Kudos received	9

Cloudera Community

Re: Deleted application.log

Re: Cloudera Manager 'First Run' command execution...

Re: cloudera manager hung on package distribution

Re: Looking for details on rootVolumeSizeGB

Re: Exception when adding Cloudera Manager via the...

Re: How do I install cloudera director? The sudo c...

Re: How do I install cloudera director? The sudo c...

Re: Bootstrap times out while resizing root partit...

Re: Bootstrap times out while resizing root partit...

Re: Bootstrap times out while resizing root partit...

Re: Bootstrap times out while resizing root partit...

Re: Bootstrap times out while resizing root partit...

Re: Bootstrap times out while resizing root partit...

Re: Bootstrap times out while resizing root partit...

Re: Cannot complete client bootstrap using m2.4xla...