Return-Path: 
 <user-return-28778-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org>
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 2789FDFC0
	for <apmail-cassandra-user-archive@www.apache.org>;
 Fri, 14 Sep 2012 15:35:34 +0000 (UTC)
Received: (qmail 89493 invoked by uid 500); 14 Sep 2012 15:35:31 -0000
Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org
Received: (qmail 89466 invoked by uid 500); 14 Sep 2012 15:35:31 -0000
Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@cassandra.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@cassandra.apache.org>
List-Post: <mailto:user@cassandra.apache.org>
List-Id: <user.cassandra.apache.org>
Reply-To: user@cassandra.apache.org
Delivered-To: mailing list user@cassandra.apache.org
Received: (qmail 89458 invoked by uid 99); 14 Sep 2012 15:35:31 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Sep 2012 15:35:31 +0000
X-ASF-Spam-Status: No, hits=2.1 required=5.0
	tests=FORGED_HOTMAIL_RCVD2,FSL_RCVD_USER,RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of
 gcdcu-cassandra-user-1@m.gmane.org designates 80.91.229.3 as permitted
 sender)
Received: from [80.91.229.3] (HELO plane.gmane.org) (80.91.229.3)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Sep 2012 15:35:23 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcdcu-cassandra-user-1@m.gmane.org>)
	id 1TCXv6-0007Sf-0D
	for user@cassandra.apache.org; Fri, 14 Sep 2012 17:35:04 +0200
Received: from 38.122.126.106 ([38.122.126.106])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <user@cassandra.apache.org>; Fri, 14 Sep 2012 17:35:03 +0200
Received: from chrisndodge by 38.122.126.106 with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <user@cassandra.apache.org>; Fri, 14 Sep 2012 17:35:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: user@cassandra.apache.org
From: Chris Dodge <chrisndodge@hotmail.com>
Subject: Re: Cassandra, AWS and EBS Optimized Instances/Provisioned IOPs
Date: Fri, 14 Sep 2012 15:29:51 +0000 (UTC)
Lines: 43
Message-ID: <loom.20120914T172850-62@post.gmane.org>
References: <68396945-17A6-489B-BC1C-D40453AB1032@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 38.122.126.106 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:15.0) Gecko/20100101 Firefox/15.0.1)


Michael Theroux <mtheroux2 <at> yahoo.com> writes:

> 
> Hello,
> A number of weeks ago, Amazon announced the availability of EBS Optimized
instances and Provisioned IOPs for Amazon EC2.  Historically, I've read EBS is
not recommended for Cassandra due to the network contention that can quickly
result (http://www.datastax.com/docs/1.0/cluster_architecture/cluster_planning).
> 
> Costs put aside, and assuming everything promoted by Amazon is accurate, with
the existence of provisioned IOPs, is EBS now a better option than before?
 Taking the points against EBS mentioned in the link above:
> 
> 
> EBS volumes contend directly for network throughput with standard packets.
This means that EBS throughput is likely to fail if you saturate a network link.
> According to Amazon, Provisioned IOPS guarantees to be within 10% of  of the
provisioned performance 99.9%of the time.  This would mean that throughput
should no longer fail.
> EBS volumes have unreliable performance. I/O performance can be exceptionally
slow, causing the system to backload reads and writes until the entire cluster
becomes unresponsive.
> Same point as above.
> Adding capacity by increasing the number of EBS volumes per host does not
scale. You can easily surpass the ability of the system to keep effective buffer
caches and concurrently serve requests for all of the data it is responsible for
managing.
> I believe this may be still true, although I'm not entirely sure why this is
more true for EBS volumes vs. emphemeral.
> 
> Any real world experience out there with these new EBS options?
> 
> -Mike
> 
> 
> 

Thanks for asking this as I'm wondering the same thing. I'd like to hear other
people's take on this as I'm trying to spec out a Cassandra ring on AWS.