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:31:33 GMT
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>
*™*

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