incubator-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: CloudStack Storage Question
Date Fri, 11 Jan 2013 20:45:15 GMT
Great, thanks, Marcus.


On Fri, Jan 11, 2013 at 1:33 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:

> Looks like with iSCSI you give it the dns name of your target, the IQN, and
> the lun #. Presuably it sets up an SR from that lun and carves volumes out
> of that, similar to how the CLVM works. Or maybe it puts a filesystem on it
> and mounts it, not sure.
>
> On Fri, Jan 11, 2013 at 1:22 PM, Marcus Sorensen <shadowsor@gmail.com
> >wrote:
>
> > On the KVM side, you can do NFS, Local disk storage, CLVM (shared block
> > device that has Clustered LVM on top of it, a primary pool is a
> particular
> > volume group and cloudstack carves out logical volumes out of it as
> > needed), and RBD (RADOS Block devices, Ceph shared storage. You point it
> at
> > your cluster and cloudstack creates RBD devices as needed). Also
> > SharedMountPoint for something like GFS,OCFS or some shared filesystem.
> >
> > Xen has NFS, a 'PreSetup' where you create an SR in your Xen cluster and
> > pass the SR to it (I think), and iSCSI (I'm not clear on how this works,
> > but I'm sure its in the docs)
> >
> >
> > On Fri, Jan 11, 2013 at 1:14 PM, Mike Tutkowski <
> > mike.tutkowski@solidfire.com> wrote:
> >
> >> So, being new to CloudStack, I'm not sure what kind of storage protocols
> >> are currently supported in the product.  To my knowledge, NFS shares are
> >> what CloudStack has only supported in the past.  Does CloudStack support
> >> iSCSI targets at present?
> >>
> >> Thanks!
> >>
> >>
> >> On Thu, Jan 10, 2013 at 3:58 PM, Mike Tutkowski <
> >> mike.tutkowski@solidfire.com> wrote:
> >>
> >> > Thanks, Edison!
> >> >
> >> > That's very helpful info.
> >> >
> >> >
> >> > On Thu, Jan 10, 2013 at 3:49 PM, Edison Su <Edison.su@citrix.com>
> >> wrote:
> >> >
> >> >>
> >> >>
> >> >> > -----Original Message-----
> >> >> > From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >> >> > Sent: Thursday, January 10, 2013 2:22 PM
> >> >> > To: cloudstack-dev@incubator.apache.org
> >> >> > Subject: CloudStack Storage Question
> >> >> >
> >> >> > Hi everyone,
> >> >> >
> >> >> > I'm new to CloudStack and am trying to understand how it works
with
> >> >> > regards to storage exposed to hypervisors.
> >> >> >
> >> >> > For example:
> >> >> >
> >> >> > My company, SolidFire, has a feature that exists at the
> >> virtual-volume
> >> >> (for us,
> >> >> > equivalent to a LUN) layer:  Hard Quality of Service.  So, for
each
> >> >> volume in
> >> >> > one of our clusters, you can specify a minimum and maximum number
> of
> >> >> > IOPS (beneficial to Cloud Service Providers who want to write
hard
> >> SLAs
> >> >> > around performance).
> >> >> >
> >> >> > We have a potential customer who is using CloudStack currently
with
> >> >> another
> >> >> > vendor (via NFS shares).  They asked me today how a hypervisor
run
> >> under
> >> >> > CloudStack would see the iSCSI storage exposed to them in one
of
> our
> >> >> > volumes.  More specifically, can the hypervisor see a volume per
VM
> >> or
> >> >> is the
> >> >> > hypervisor forced to create all of its VMs off of the same volume?
> >>  If
> >> >> the
> >> >> > hypervisor is forced to create all of its VMs off of the same
> volume,
> >> >> then this
> >> >> > would significantly reduce the value of our hard quality of service
> >> >> offering
> >> >> > since all of these VMs would have to run at the same performance
> SLA.
> >> >>
> >> >>
> >> >> It depends on hypervisor, for KVM, per VM per LUN will work,
> xenserver
> >> >> doesn't work. For Vmware, it will work, but with a limitation(one
> ESXi
> >> host
> >> >> can only have 256 LUN at max).
> >> >>
> >> >> >
> >> >> > Can anyone help me better understand how this would work?
> >> >> >
> >> >> > Thanks so much!!
> >> >> >
> >> >> > --
> >> >> > *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>
> >> >> > *(tm)*
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > *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>
> >> *™*
> >>
> >
> >
>



-- 
*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