incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: Requirements of Storage Orchestration
Date Wed, 31 Oct 2012 19:34:50 GMT
I just don't see how this would be easy to implement. Actually
creating an iscsi lun on a target would be fine, there are a few known
parameters and the plugin would do the work. Allowing someone to
configure any arbitrary storage array via plugin seems tricky. I'm not
an expert in the code though, nor do I really understand the storage
framework, but let me explain why I think it's tricky.

 Admin wants to create new primary storage, there's a plugin call
provided to list devices/disks attached to an appliance maybe? And
it's up to the plugin to do the actual work of collecting that, but it
returns a list of objects to cloudstack with a vendor-agnostic string
for disk identifier and an arbitrary set of properties based on
storage appliance capabilities, like physical blocksize of disks, disk
size, controller/backplane location, maybe some SMART attributes. Then
we query the storage plugin for methods that can be used on that
appliance to create pools out of those disks (raid levels, zpools,
etc), and what features can be set, and what values those features
accept. Then we present all of this to the admin in some way that
allows him/her to define a storage pool with compression, dedup,
encryption, ashift, and whatever features the admin wants. Then we
accept admin's input and send a create pool command to the plugin.
This command might let us set a feature on the pool to let us know if
we're dealing with a filesystem or if we need to carve that pool into
volumes. Then we can call the plugin to create volumes if necessary,
and perhaps format those volumes with some filesystem. Then call the
plugin for exporting them via NFS, or export those volumes directly as
iscsi or FC or whatever.

That last sentence makes sense to me. OpenStack for example allows you
to create iscsi luns on various appliances, to use for VMs. It's at
the point where we're actually configuring and managing the
appliance's disks and filesystems that seems redundant to the vendor
tools, difficult to do, and rarely used/useful. Even if it were
available, I wonder who would write such a plugin?

On Wed, Oct 31, 2012 at 12:39 PM, Edison Su <Edison.su@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>> Sent: Wednesday, October 31, 2012 11:13 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Requirements of Storage Orchestration
>>
>> It seems to me that for the most part these things are a function of managing
>> the storage backend, along with creating the disk pools, formatting
>> filesystems, and the like, that are used as primary storage by CloudStack.
>>
>> Should there be plugins to manage storage backends? Does any competing
>> project in the segment do this? It seems extremely complex to add in
>> functionality to expose disks and arrays from a SAN or NAS, allow the admin
>> to configure them into pools, choose filesystems, manage NFS/iSCSI/RBD
>> exports, and configure filesystem features all through cloudstack. The root
>> admin would be the only one with access and they likely would find it just as
>> easy to do it with the tools the storage vendor provides.
>
> It should be easy to add storage pool management functionality into the new storage framework.
> The primary storage layer looks like this:
> Volume service -> primary data store provider -> primary data store -> volume
> The lifecycle of primary data store is:
> Create -> attach ->detach -> delete
> Whenever admin wants to create a storage pool, call an api on the data store provider,
the provider can talk to its storage backend, create storage(an ISCSI target or nfs mount
point etc ).
> Admin can attach the storage to a zone, or pod, or cluster, or host, thus cloudstack
can use it to create volume on it.
>
>>
>> To me the only way it makes sense to roll those things in is if there's some
>> way to do it at the VM image level. I believe qcow2 supports encryption, and
>> we can probably do encrypted lvm volumes as well. I'd actually like to look
>> into this. We also need to realize that encrypting the disk doesn't do much
>> good if someone gets access to the VM host or cloudstack, they could likely
>> see the encryption key as well, but it does help in a case where someone
>> tries to download a copy of the disk image, if someone takes the physical disk
>> array, or something like that.
>>
>> Dedup will likely always be a function of the filesystem or storage array, and I
>> don't see a way for cloudstack to work at that level.
>>
>> On Wed, Oct 31, 2012 at 11:40 AM, Nguyen Anh Tu <ng.tuna@gmail.com>
>> wrote:
>> > Love to hear that!!! Some days ago I post a mail to ask community
>> > about encrypting VM data in CloudStack, but seemly not to much people
>> take care.
>> > I'm writing an encryption service based on TrueCrypt, runing in
>> > background inside the VM. It separates from CloudStack. Great to hear
>> > about the API idea. I think it's a good choice. Some questions about
>> > API scenario: how to generate passphase/key? how to keep it?
>> >
>> > 2012/10/31 Edison Su <Edison.su@citrix.com>
>> >
>> >>
>> >>
>> >> > -----Original Message-----
>> >> > From: Umasankar Mukkara [mailto:umasankar.mukkara@cloudbyte.co]
>> >> > Sent: Tuesday, October 30, 2012 9:20 AM
>> >> > To: cloudstack-dev@incubator.apache.org
>> >> > Subject: Requirements of Storage Orchestration
>> >> >
>> >> > Today I had the opportunity to listen to Kevin Kluge at the
>> >> > inauguration
>> >> event
>> >> > of Bangalore CloudStack Group. Some thoughts around new storage
>> >> > requirements popped out after this event. I thought I will post to
>> >> > the
>> >> dev
>> >> > group and check what are already in progress. Kevin said, Edison Su
>> >> > is
>> >> already
>> >> > in the process of designing and implementing/re-factoring some
>> >> > portions
>> >> of
>> >> > storage orchestrator.
>> >> >
>> >> > I could think of the following extensions to the current cloudstack
>> >> >
>> >> >
>> >> >    1. Ability to offload the data protection capabilities to the storage
>> >> >    array. (like dedup/snapshot/backup/encypt/compress)
>> >> >    2. Ability to provide an API at storage orchestrator so that the
>> >> storage
>> >> >    array can write to this API
>> >>
>> >> Only snapshot/backup are taken into consideration. Any details about
>> >> the scenario of encypt/compress/dedup?
>> >> Such as,  how to use this functionalities, what's the api should look like?
>> >> We can expose more capabilities on the API and storage driver layer.
>> >>
>> >> >    3. Extend the current storage offerings to include some of the storage
>> >> >    array capabilities such as IOPS guarantee (or throttle), throughput
>> >> >    guarantee (or throttle)
>> >> >
>> >> > Where can I learn the current development threads around these in
>> >> > cloudstack? Edision Su (or) some one who is working on this, can
>> >> > please provide some pointers these so that I can pull myself up to
>> >> > speed ?I
>> >> would
>> >> > like to actively participate and hack some parts of it :)
>> >> Oh, great! There are so many code I want to change, really need help
>> >> and get feedback from other people.
>> >> I'll send out the status of my current work and what I am trying to
>> >> do in another thread.
>> >>
>> >> >
>> >> > --
>> >> >
>> >> > Regards,
>> >> > Uma.
>> >> >
>> >> ---------------------------------------------------------------------
>> >> ---------
>> >> > CloudByte ElastiStor 1.0 is now available under Early Access
>> >> > Program<http://www.cloudbyte.com/eap.aspx>
>> >> >
>> >> ---------------------------------------------------------------------
>> >> ----------
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > N.g.U.y.e.N.A.n.H.t.U

Mime
View raw message