Open Stack

(Apologies if this doesn't format well - I copied and pasted from the HTML
archive as I haven't received the associated digest yet.)

Hi Trey,

On Thu Nov 22 03:33:20 UTC 2012, "Trey Duskin" <trey at maldivica.com>
wrote:
> Forgive the ignorant question, but why is Cinder the only option for the
> backing for "file system as a service" when there is also Swift?  The
> blueprint that Netapp wrote up for this mentioned Swift would not be
> suitable, but did not explain why.

I don't think they made that thinking very clear in the blueprint, but I
understand where they are coming from, and Michael Chapman already summed
it up nicely:
"block storage and network shares are both instances of granting individual
VMs access to slices of storage resources, and as such belong under a
single project". Object storage is fundamentally different because it is a
model that has evolved specifically to cater for content download/upload
over the Internet, as opposed to storage access within a cloud deployment.
Additionally, when you start thinking about the API operations you'd want
for volumes and shares you start to see a lot of similarities, not so much
for object storage.

> I don't know much about the Cinder
> features and limitations, but in the use case of sharing and persisting
> large datasets among compute instances, it seems to me Swift would provide
> the needed scalability and durability.

It doesn't...

It certainly does provide scalability and durability for persisting large
datasets - you can tar things up and use it like a tape backup - but only
for applications that understand or can easily be made to understand object
storage.

It does sharing in part, but not efficiently and certainly nothing like a
file-system based share which multiple clients can coordinate on.

To illustrate, here are a couple of use-cases we want to be able to fulfil
which we can't (without serious back-injury as a result of jumping through
hoops...) at the moment:
* Run an _existing_ Apache site from a guest that serves mostly static
content with occasional changes (seems great for Swift right, except...),
where the content is largely file-based hierarchical datasets currently
sitting on a HSM system and too large to fit into the available ephemeral
disks or volumes.
* Host visualisation services/desktop for large datasets produced on a
local HPC facility and sitting on its' GPFS. This requires much better
bandwidth and latency than we can get using sshfs or NFS into the guest,
attempting to do it over HTTP with Swift isn't going to get us that.

--
Cheers,
~Blairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121122/7ee9a55f/attachment.html>