From user-return-27387-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Tue Jul 3 13:17:14 2012 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E92D395A1 for ; Tue, 3 Jul 2012 13:17:13 +0000 (UTC) Received: (qmail 71073 invoked by uid 500); 3 Jul 2012 13:17:11 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 70899 invoked by uid 500); 3 Jul 2012 13:17:11 -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 70883 invoked by uid 99); 3 Jul 2012 13:17:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jul 2012 13:17:11 +0000 X-ASF-Spam-Status: No, hits=0.2 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [98.139.213.146] (HELO nm6-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.146) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 03 Jul 2012 13:17:02 +0000 Received: from [98.139.214.32] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2012 13:16:41 -0000 Received: from [98.139.213.14] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2012 13:16:41 -0000 Received: from [127.0.0.1] by smtp114.mail.bf1.yahoo.com with NNFMP; 03 Jul 2012 13:16:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1341321401; bh=1cgfpHSHH00uNIMeK8kodiLlmXvdkexUggpTxzsa2EE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:Content-Type:Content-Transfer-Encoding:Subject:Date:Message-Id:To:Mime-Version:X-Mailer; b=v5Q5s0xYphQFpVF3wjjw+hYlxce5z7TSIFwu23nQQsRr9AP3qIQJEkWoxrAqiNkAtK+Y23uGQo7cI+WgTX7hhRnAq1SeB0v5IJViiS0dLpI7Ey58e+VhA8z+VFMmmSnqWsdZ04a8Hjiv5YYEkJOmFmj6oV63oI8+WM3Myoljs90= X-Yahoo-Newman-Id: 340128.29527.bm@smtp114.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: yMEBGBsVM1kBCAZBMBxYtXiM7YIMJ3gBGyOCZz3RprsNzmG lcQq6D.sfxV8JsRiR4L7_Mvm7W9ME6JAka1ZGmrSjyUoXgt0X0jiBiZyRCaA ifGBBkttitsKA4gFJaoqCRfNWO6GL7.ADQ4rpOEMF4AVnFa0ePe16KvsKo7D D2iwrCvqb51VEHgy3MwQ6HEmklhT4ieXpHJpHkNwwX1FuaCQ6024FsahcEA2 QB8Sc2ZCZjTXN9wbmvQBjv7jaPn939r82iO3qQ3yEKFGm72hqdWrZaKi6CoV adN4hNyanJmO6A5uk..js.yqzqjCbtoVNxKR4aW6crHYVyC6rivFHhs3eHUy ZmMkSDIxbpMnAMD8WD2XBGfuYzIRaa7AgyT8z72NM84ravk9UeXRFPsRVZZU BFETnmdVVHbe0rf4Mrszr1OD2pnSS12p8MZa7xdzW_LIIRJoloHEF X-Yahoo-SMTP: t0UN_U2swBCFgwLIRu70LU92TrvpdQ-- Received: from [192.168.11.21] (mtheroux2@75.68.33.69 with plain) by smtp114.mail.bf1.yahoo.com with SMTP; 03 Jul 2012 06:16:41 -0700 PDT From: Michael Theroux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Expanding Cassandra on EC2 with consistency Date: Tue, 3 Jul 2012 09:16:47 -0400 Message-Id: To: user@cassandra.apache.org Mime-Version: 1.0 (Apple Message framework v1280) X-Mailer: Apple Mail (2.1280) X-Virus-Checked: Checked by ClamAV on apache.org Hello, We are currently running a web application utilizing Cassandra on EC2. = Given the recent outages experienced with Amazon, we want to consider = expanding Cassandra across availability zones sooner rather than later. We are trying to determine the optimal way to deploy Cassandra in this = deployment. We are researching the NetworkTopologyStrategy, and the = EC2Snitch. We are also interested in providing a high level of read or = write consistency, My understanding is that the EC2Snitch recognizes availability zones as = racks, and regions as data-centers. This seems to be a common = configuration. However, if we were to want to utilize queries with a = READ or WRITE consistency of QUORUM, would there be a high possibility = that the communication necessary to establish a quorum, across = availability zones? =20 My understanding is that the NetworkTopologyStrategy attempts to prefer = replicas be stored on other racks within the datacenter, which would = equate to other availability zones in EC2. This implies to me that in = order to have the quorum of nodes necessary to achieve consistency, that = Cassandra will communicate with nodes across availability zones. First, is my understanding correct? Second, given the high latency that = can sometimes exists between availability zones, is this a problem, and = instead we should treat availability zones as data centers? Ideally, we would be able to setup a situation where we could store = replicas across availability zones in case of failure, but establish a = high level of read or write consistency within a single availability = zone. I appreciate your responses, Thanks, -Mike