Open Stack

There are 2 reasons you don't want to run Swift on VMs:

1) (minor reason, depending on the use case) performance. Virtualized IO is going to have worse performance for storage than bare metal. In some cases this may not matter, and in others you may use Super Awesome Virt (tm) that doesn't have any IO penalty. But in general, there will be some performance penalty. It's up to you to see if it's worth it or not.

2) (major reason) failure domains. Swift is designed to decouple the data from the storage media. This is done by abstracting away the storage volumes (ie drives) and presenting it to the application as a unified namespace. Swift does data placement and failure handling based on the failure domains in the underlying hardware. So if you have 3 replicas of the data and 5 servers, Swift will ensure that none of the three replicas are on the same server. This gives you high availability and means that hardware failure can be seamlessly handled. If you hide the failure domains from Swift by running on virtual servers, you will be at higher risk for a loss of availability (at best) and loss of data (at worse) because your data may in fact be stored on the same physical hardware underlying the virtual machines.[1] This is the main reason you don't want to run Swift on top of other systems (hardware or software) that hide the failure domains. Swift is designed to work around failures (and does a really good job). Let it do it's job.

[1] And since VMs are designed to be moved around, starting with "we'll just make sure our VMs are on different physical servers" doesn't seem like a long-term tenable plan.

--John






On Feb 21, 2014, at 1:47 PM, Adam Lawson <alawson at aqorn.com> wrote:

> I have a large client who wants to execute a global deployment of Swift in Production but do it on VM's, shared storage and RAID.
> 
> Read on after you stop laughing. Serenity now!
> 
> Okay, their splendid idea is to start with VM's in Production, add physical hardware later then retire the VM's. This direction is completely against my recommendations but we're still talking and the direction isn't final so that's a good thing. I think I just need some relevant benchmarks to help communicate why deploying on VM's isn't a Production-worthy strategy when we're talking about Swift.
> 
> So, are there benchmarks already published somewhere that demonstrate how/why a virtual infrastructure is such a bad idea with Swift? We all know Swift is designed to be a storage provider - not a storage consumer and that running Swift with shared storage with RAID is utterly foolish. But my recommendation is being overridden by folks who feel the bad performance isn't really all that bad and because the VM's are going to be temporary. We all know temporary = permanent when you're talking about Production, . I don't have physical hardware to execute benchmarks and prove my point (well not yet anyway).
> 
> Thoughts/suggestions?
> 
> 
> Adam Lawson
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (888) 406-7620
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140221/2bc89293/attachment.sig>