On Fri, 21 Feb 2014 13:47:31 -0800 Adam Lawson <alaw...@aqorn.com> wrote:
> 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. I don't consider this question needing this sort of exhuberant treatment. Deployments on VMs do happen. But they aren't very economical or safe. RAID does not actually hurt all that much, depending on the level. Its downside is that 1) it buys you nothing and you're just wasting equipment, and 2) it offers admins a lot of rope to hang themselves. Since Swift audits its storage constantly, VMs hosting Swift will inevitably defeat benefits of virtualization by chewing CPU and I/O, and you can't oversubscribe. So the only benefit remainin is flexibility, such as migrations, which Swift does not need. Another problem with all this is that Swift clusters aren't very easy to migrate wholesale, unless the user app can copy all its data from cluster to cluster. Therefore, the cluster of VMs must be established with realistic parameters for numbers of partitions and replication (that means 3), even if it seems excessive. But if VMs stick around long term, I'd be afraid of the loss of availability. Sooner or later you'll have 2 VMs share a controller or SAN box (even if volumes are different). It's a huge PITA to keep track and I guarantee that admins will not. Then you're one power failure from losing quorum. But you need to present all this without passing a judgement about VMs being "utterly foolish" or such. Let's say, practice suggests that they are suboptimal and offer dangerous traps in data area. -- Pete _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack