Open Stack

On Fri, 21 Feb 2014 13:47:31 -0800
Adam Lawson <alawson at 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