Member since
07-09-2015
16
Posts
0
Kudos Received
1
Solution
My Accepted Solutions
Title | Views | Posted |
---|---|---|
4332 | 08-05-2015 08:04 AM |
08-26-2016
04:36 PM
Thanks for the response. In the end I had to log into CM and fix critical erorrs for the Impala service. No daemon roles were assigned via the config file. The fix prompted the Enable Kerberos step to complete successfully. After that I got another error that kept Imapala from starting (short-circuit read access) but that is another problem for another post. Thanks again
... View more
07-28-2015
12:10 AM
Thanks - that was helpful.
... View more
07-15-2015
07:18 PM
Hi Kirk - > 1. The application log doesn't reveal the aws CLI commands that are run. Is there a way to > see those commands? Either before (as a dry run feature) or after? Cloudera Director integrates with the AWS API using the Java SDK. There is no straightforward way to translate those method calls as AWS CLI commands you can run standalone. In theory you should be able to figure out how to use the AWS CLI to start similar instances by inspecting the existing ones. > 2. The nodes that get provisioned do not have anything in the /etc/hosts file. How are they resolving each other? > Typically, the hosts file configuration is critical to getting Cloudera Manager to run successfully. We expect DNS configuration to be handled outside of Cloudera Director using different mechanisms: VPC configuration to use AmazonProvidedDNS via DHCP Options Sets custom bootstrap script that Director runs to configure the hostname scripts embedded into a custom AMI that configure the proper hostname during boot and handle DNS registration Cloudera Director doesn't attempt to perform any DNS configs.
... View more
07-13-2015
02:17 PM
1 Kudo
The log you sent along seems to be for a different, failed run of the Director client where it couldn't find the configuration file you specified ("./demok16.aws.simple.conf"). There should have been a log generated for the successful run that bootstrapped the cluster you were talking about. It's possible that it was overwritten by a later run, or maybe you installed the client locally via tarball (if so, it's in a logs directory under where you decompressed it)? The instance type m1.xlarge does come with 4 instance store (ephemeral) volumes of 420 GB each, so what you're seeing is normal for that instance type. Director preserves those volumes and doesn't currently provide a way to resize them. (Also, Director should be naming the devices /dev/sdb through /dev/sde, unless you've configured custom configuration values for lp.ec2.ephemeral.deviceNamePrefix and lp.ec2.ephemeral.rangeStart - the log would show some more information about that.) If you don't need as much ephemeral storage, then you can try a different instance type - m1.xlarge is an older type and not recommended by AWS anyway. m3.xlarge has the same vCPU count and memory as m1.xlarge (4, 15GB) but only 2 40GB SSD instance stores. It's also cheaper than m1.xlarge, according to AWS docs. The new m4.xlarge has 4 vCPU, 16 GB memory, and does away with instance stores completely.
... View more