Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 87644 invoked from network); 3 Apr 2010 21:54:53 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 3 Apr 2010 21:54:53 -0000 Received: (qmail 75325 invoked by uid 500); 3 Apr 2010 21:54:52 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 75311 invoked by uid 500); 3 Apr 2010 21:54:52 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 75303 invoked by uid 99); 3 Apr 2010 21:54:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Apr 2010 21:54:52 +0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=AWL,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [209.85.221.177] (HELO mail-qy0-f177.google.com) (209.85.221.177) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Apr 2010 21:54:47 +0000 Received: by qyk7 with SMTP id 7so3017962qyk.17 for ; Sat, 03 Apr 2010 14:54:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.233.75 with HTTP; Sat, 3 Apr 2010 14:54:25 -0700 (PDT) In-Reply-To: <94E21CEC-B84C-464C-AACA-A03B1FA4AA71@joestump.net> References: <94E21CEC-B84C-464C-AACA-A03B1FA4AA71@joestump.net> Date: Sat, 3 Apr 2010 14:54:25 -0700 Received: by 10.229.215.11 with SMTP id hc11mr6278024qcb.45.1270331665853; Sat, 03 Apr 2010 14:54:25 -0700 (PDT) Message-ID: Subject: Re: Deployment on AWS From: Benjamin Black To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm pretty familiar with EC2, hence the question. I don't believe any patches are required to do these things. Regardless, as I noted in that ticket, you definitely do NOT need AWS credentials to determine your availability zone. It is available through the metadata web server for each instance as 'placement_availability_zone', avoiding the need to speak the EC2 API or store credentials in the configs. b On Sat, Apr 3, 2010 at 2:45 PM, Joe Stump wrote: > > On Apr 3, 2010, at 1:53 PM, Benjamin Black wrote: > > What specific features are you looking for to operate on EC2? > > It seemed people weren't looking for features, but tools to help with the > management. The two things we've created that people might be interested = in > are: > 1. An EC2-specific rack-aware strategy. Basically, you put your AWS > key/secret into the storage-conf.xml and the node automatically figures o= ut > what AZ's (that's Amazon speak for data center) each node in the cluster = is > in and then ensures that records are stored in each AZ (depending on your > replication factor of course). This allows you to spread your writes far = and > wide and keep your reads local to each AZ. > 2. We've cooked up a lot of Fabric recipes that use Boto to provision an = EC2 > instance, bootstrap it, and add it to the cluster. All with =A0just a few > commands. It takes us about 5-10 minutes to bootstrap a new node into the > cluster. > The rack-aware strategy is attached to a ticket already[1], but I think > there is a minor bug with the patch. > --Joe > [1]=A0https://issues.apache.org/jira/browse/CASSANDRA-666