cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Root-disk support for managed storage
Date Sun, 26 Jan 2014 05:33:39 GMT
2) This is cloning the SAN volume that stores the SR in 1).

3) This is to use the SR on the cloned volume.


On Sat, Jan 25, 2014 at 10:31 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> I see, Marcus. That is an interesting idea definitely.
>
> The process would be on a cluster-by-cluster basis:
>
> 1) Download the template to the SR.
>
> 2) Clone the SAN volume.
>
> 3) Use the new SR.
>
> Later for a new root disk:
>
> Just do 3.
>
>
> On Sat, Jan 25, 2014 at 10:29 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:
>
>> Not's not really what I was describing, or that's not how we do it at
>> least. The first time a template is used, we create an SR with one VDI
>> (using your terminology as we don't do it in Xen, but it should map to
>> essentially the same thing) and copy the template contents into it.
>> Then we remove the SR. When a root disk is requested, we send a clone
>> command to the SAN, and then register the new clone as a new volume,
>> then attach that as a new SR dedicated to that root volume. Every root
>> disk that makes use of that template is its own SR.
>>
>> On Sat, Jan 25, 2014 at 9:30 PM, Mike Tutkowski
>> <mike.tutkowski@solidfire.com> wrote:
>> > Thanks for your input, Marcus.
>> >
>> > Yeah, the SolidFire SAN has the ability to clone, but I can't use it in
>> this
>> > case.
>> >
>> > Little note first: I'm going to put some words below in capital letters
>> to
>> > stress some important details. All caps for some words can be annoying
>> to
>> > some, so please understand that I am only using them here to highlight
>> > important details. :)
>> >
>> > For managed storage (SolidFire is an example of this), this is what
>> happens
>> > when a user attaches a volume to a VM for the first time (so this is for
>> > Disk Offerings...not root disks):
>> >
>> > 1) A volume (LUN) is created on the SolidFire SAN that is ONLY ever
>> used by
>> > this ONE CloudStack volume. This volume has QoS settings like Min, Max,
>> and
>> > Burst IOPS.
>> >
>> > 2) An SR is created in the XenServer resource pool (cluster) that makes
>> use
>> > of the SolidFire volume that was just created.
>> >
>> > 3) A VDI that represents the disk is created on the SR (this VDI
>> essentially
>> > consumes as much of the SR as it can*).
>> >
>> > If the user wants to create a new CloudStack volume to attach to a VM,
>> that
>> > leads to a NEW SolidFire volume being created (with its own QoS), a NEW
>> SR,
>> > and a new VDI inside of that SR.
>> >
>> > The same idea will exist for root volumes. A NEW SolidFire volume will
>> be
>> > created for it. A NEW SR will consume the SolidFire volume, and only ONE
>> > root disk will EVER use this SR (so there is never a need to clone the
>> > template we download to this SR).
>> >
>> > The next time a root disk of this type is requested, this leads to a NEW
>> > SolidFire volume (with its own QoS), a NEW SR, and a new VDI.
>> >
>> > In the situation you describe (which is called non-managed (meaning the
>> SR
>> > was created ahead of time outside of CloudStack)), you can have multiple
>> > root disks that leverage the same template on the same SR. This will
>> never
>> > be the case for managed storage, so there will never be a need for a
>> > downloaded template to be cloned multiple times into multiple root
>> disks.
>> >
>> > By the way, I just want to clarify, as well, that although I am talking
>> in
>> > terms of "SolidFire this an SolidFire that" that the functionality I
>> have
>> > been adding to CloudStack (outside of the SolidFire plug-in) can be
>> > leveraged by any storage vendor that wants a 1:1 mapping between a
>> > CloudStack volume and one of their volumes. This is, in fact, how
>> OpenStack
>> > handles storage by default.
>> >
>> > Does that clarify my question?
>> >
>> > I was not aware of how CLVM handled templates. Perhaps I should look
>> into
>> > that.
>> >
>> > By the way, I am currently focused on XenServer, but also plan to
>> implement
>> > support for this on KVM and ESX (although those may be outside of the
>> scope
>> > of 4.4).
>> >
>> > Thanks!
>> >
>> > * It consumes as much of the SR as it can unless you you want extra
>> space
>> > put aside for hypervisor snapshots.
>> >
>> >
>> > On Sat, Jan 25, 2014 at 3:43 AM, Marcus Sorensen <shadowsor@gmail.com>
>> > wrote:
>> >>
>> >> In other words, if you can't clone, then createDiskFromTemplate should
>> >> copy template from secondary storage directly onto root disk every
>> >> time, and copyPhysicalDisk really does nothing. If you can clone, then
>> >> copyPhysicalDisk should copy template to primary, and
>> >> createDiskFromTemplate should clone. Unless there's template cloning
>> >> in the storage driver now, and if so put the createDiskFromTemplate
>> >> logic there, but you still probably need copyPhysicalDisk to do its
>> >> thing on the agent.
>> >>
>> >> This is all from a KVM perspective, of course.
>> >>
>> >> On Sat, Jan 25, 2014 at 3:40 AM, Marcus Sorensen <shadowsor@gmail.com>
>> >> wrote:
>> >> > I'm not quite following.  With our storage, the template gets copied
>> >> > to the storage pool upon first use, and then cloned upon subsequent
>> >> > uses. I don't remember all of the methods immediately, but there's
>> one
>> >> > called to copy the template to primary storage, and once that's done
>> >> > as you mention it's tracked in template_spool_ref and when root disks
>> >> > are created that's passed as the source to copy when creating root
>> >> > disks.
>> >> >
>> >> > Are you saying that you don't have clone capabilities to clone the
>> >> > template when root disks are created? If so, you'd be more like CLVM
>> >> > storage, where the template copy actually does nothing, and you
>> >> > initiate a template copy *in place* of the clone (or you do a
>> template
>> >> > copy to primary pool whenever the clone normally would happen). CLVM
>> >> > creates a fresh root disk and copies the template from secondary
>> >> > storage directly to that whenever a root disk is deployed, bypassing
>> >> > templates altogether. This is because it can't efficiently clone, and
>> >> > if we let the template copy to primary, it will then do a full copy
>> of
>> >> > that template from primary to primary every time, which is pretty
>> >> > heavy since it's also not thin provisioned.
>> >> >
>> >> > If you *can* clone, then just copy the template to your primary
>> >> > storage as normal in your storage adaptor (copyPhysicalDisk), it will
>> >> > be tracked in template_spool_ref, and then when root disks are
>> created
>> >> > it will be passed to createDiskFromTemplate in your storage adaptor
>> >> > (for KVM), where you can call a clone of that and return it as the
>> >> > root volume . There was once going to be template clone capabilities
>> >> > in the storage driver level on the mgmt server, but I believe that
>> was
>> >> > work-in-progress last I checked (4 months ago or so), so we still
>> have
>> >> > to call clone to our storage server from the agent side as of now,
>> but
>> >> > that call doesn't have to do any work on the agent-side, really.
>> >> >
>> >> >
>> >> > On Sat, Jan 25, 2014 at 12:47 AM, Mike Tutkowski
>> >> > <mike.tutkowski@solidfire.com> wrote:
>> >> >> Just wanted to throw this out there before I went to bed:
>> >> >>
>> >> >> Since each root volume that belongs to managed storage will get
its
>> own
>> >> >> copy
>> >> >> of some template (assuming we're dealing with templates here and
>> not an
>> >> >> ISO), it is possible I may be able to circumvent a new table (or
any
>> >> >> existing table like template_spool_ref) entirely for managed
>> storage.
>> >> >>
>> >> >> The purpose of a table like template_spool_ref appears to be mainly
>> to
>> >> >> make
>> >> >> sure we're not downloading the sample template to an SR multiple
>> times
>> >> >> (and
>> >> >> this doesn't apply in the case of managed storage since each root
>> >> >> volume
>> >> >> should have at most one template downloaded to it).
>> >> >>
>> >> >> Thoughts on that?
>> >> >>
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Sat, Jan 25, 2014 at 12:39 AM, Mike Tutkowski
>> >> >> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>
>> >> >>> Hi Edison and Marcus (and anyone else this may be of interest
to),
>> >> >>>
>> >> >>> So, as of 4.3 I have added support for data disks for managed
>> storage
>> >> >>> for
>> >> >>> XenServer, VMware, and KVM (a 1:1 mapping between a CloudStack
>> volume
>> >> >>> and a
>> >> >>> volume on a storage system). One of the most useful abilities
this
>> >> >>> enables
>> >> >>> is support for guaranteed storage quality of service in CloudStack.
>> >> >>>
>> >> >>> One of the areas I'm working on for CS 4.4 is root-disk support
for
>> >> >>> managed storage (both with templates and ISOs).
>> >> >>>
>> >> >>> I'd like to get your opinion about something.
>> >> >>>
>> >> >>> I noticed when we download a template to a XenServer SR that
we
>> >> >>> leverage a
>> >> >>> table in the DB called template_spool_ref.
>> >> >>>
>> >> >>> This table keeps track of whether or not we've downloaded the
>> template
>> >> >>> in
>> >> >>> question to the SR in question already.
>> >> >>>
>> >> >>> The problem for managed storage is that the storage pool itself
>> can be
>> >> >>> associated with many SRs (not all necessarily in the same cluster
>> >> >>> even): one
>> >> >>> SR per volume that belongs to the managed storage.
>> >> >>>
>> >> >>> What this means is every time a user wants to place a root
disk
>> (that
>> >> >>> uses
>> >> >>> a template) on managed storage, I will need to download a template
>> to
>> >> >>> the
>> >> >>> applicable SR (the template will never be there in advance).
>> >> >>>
>> >> >>> That is fine. The issue is that I cannot use the template_spool_ref
>> >> >>> table
>> >> >>> because it is intended on mapping a template to a storage pool
(1:1
>> >> >>> mapping
>> >> >>> between the two) and managed storage can download the same
template
>> >> >>> many
>> >> >>> times.
>> >> >>>
>> >> >>> It seems I will need to add a new table to the DB to support
this
>> >> >>> feature.
>> >> >>>
>> >> >>> My table would allow a mapping between a template and a volume
from
>> >> >>> managed storage.
>> >> >>>
>> >> >>> Do you see an easier way around this or is this how you recommend
I
>> >> >>> proceed?
>> >> >>>
>> >> >>> Thanks!
>> >> >>>
>> >> >>> --
>> >> >>> Mike Tutkowski
>> >> >>> Senior CloudStack Developer, SolidFire Inc.
>> >> >>> e: mike.tutkowski@solidfire.com
>> >> >>> o: 303.746.7302
>> >> >>> Advancing the way the world uses the cloud™
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Mike Tutkowski
>> >> >> Senior CloudStack Developer, SolidFire Inc.
>> >> >> e: mike.tutkowski@solidfire.com
>> >> >> o: 303.746.7302
>> >> >> Advancing the way the world uses the cloud™
>> >
>> >
>> >
>> >
>> > --
>> > Mike Tutkowski
>> > Senior CloudStack Developer, SolidFire Inc.
>> > e: mike.tutkowski@solidfire.com
>> > o: 303.746.7302
>> > Advancing the way the world uses the cloud™
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
> *™*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message