Return-Path: Delivered-To: apmail-hadoop-hbase-dev-archive@minotaur.apache.org Received: (qmail 47962 invoked from network); 16 Nov 2009 19:21:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Nov 2009 19:21:10 -0000 Received: (qmail 39738 invoked by uid 500); 16 Nov 2009 19:21:10 -0000 Delivered-To: apmail-hadoop-hbase-dev-archive@hadoop.apache.org Received: (qmail 39703 invoked by uid 500); 16 Nov 2009 19:21:10 -0000 Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hbase-dev@hadoop.apache.org Delivered-To: mailing list hbase-dev@hadoop.apache.org Received: (qmail 39691 invoked by uid 99); 16 Nov 2009 19:21:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Nov 2009 19:21:10 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Nov 2009 19:21:00 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 937C7234C045 for ; Mon, 16 Nov 2009 11:20:39 -0800 (PST) Message-ID: <1368773985.1258399239588.JavaMail.jira@brutus> Date: Mon, 16 Nov 2009 19:20:39 +0000 (UTC) From: "stack (JIRA)" To: hbase-dev@hadoop.apache.org Subject: [jira] Commented: (HBASE-1961) HBase EC2 scripts In-Reply-To: <722272007.1257617733604.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HBASE-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778461#action_12778461 ] stack commented on HBASE-1961: ------------------------------ Playing with scripts more: + Has hardcoded JAVA_VERSION in hbase-ec2-env.sh. Is that intentional? + If I do the following, it doesn't work: {code} $ ./bin/hbase-ec2 list -h Required option '-K, --private-key KEY' missing (-h for usage) No running clusters. {code} The -h is not passed to ec2-describe-instances. I see that the hadoop scripts have the same issue. So it seems like we require people to fill in keys into the hbase-ec2-env.sh. Is that right? If so, lets add stuff to the readme? > HBase EC2 scripts > ----------------- > > Key: HBASE-1961 > URL: https://issues.apache.org/jira/browse/HBASE-1961 > Project: Hadoop HBase > Issue Type: New Feature > Environment: Amazon AWS EC2 > Reporter: Andrew Purtell > Assignee: Andrew Purtell > Priority: Minor > Fix For: 0.21.0, 0.20.3 > > Attachments: ec2-contrib.tar.gz > > > Attached tarball is a clone of the Hadoop EC2 scripts, modified significantly to start up a HBase storage only cluster on top of HDFS backed by instance storage. > Tested with the HBase 0.20 branch but should work with trunk also. Only the AMI create and launch scripts are tested. Will bring up a functioning HBase cluster. > Do "create-hbase-image c1.xlarge" to create an x86_64 AMI, or "create-hbase-image c1.medium" to create an i386 AMI. Public Hadoop/HBase 0.20.1 AMIs are available: > i386: ami-c644a7af > x86_64: ami-f244a79b > launch-hbase-cluster brings up the cluster: First, a small dedicated ZK quorum, specifiable in size, default of 3. Then, the DFS namenode (formatting on first boot) and one datanode and the HBase master. Then, a specifiable number of slaves, instances running DFS datanodes and HBase region servers. For example: > {noformat} > launch-hbase-cluster testcluster 100 5 > {noformat} > would bring up a cluster with 100 slaves supported by a 5 node ZK ensemble. > We must colocate a datanode with the namenode because currently the master won't tolerate a brand new DFS with only namenode and no datanodes up yet. See HBASE-1960. By default the launch scripts provision ZooKeeper as c1.medium and the HBase master and region servers as c1.xlarge. The result is a HBase cluster supported by a ZooKeeper ensemble. ZK ensembles are not dynamic, but HBase clusters can be grown by simply starting up more slaves, just like Hadoop. > hbase-ec2-init-remote.sh can be trivially edited to bring up a jobtracker on the master node and task trackers on the slaves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.