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: Storage Subsystem 2.0 Questions
Date Tue, 05 Mar 2013 17:56:19 GMT
Thanks, Marcus

When Edison sees this e-mail chain, he will be able to fill in extra
details.


On Mon, Mar 4, 2013 at 11:08 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:

>  Generally the targets I've worked with support different levels of
> access control, so you may have a high level block where you can't
> even see the target unless you come from the right IP (ACL/firewall),
> then you've got something like CHAP, and then maybe the target
> supports persistent reservations so that only one client can use a
> given LUN at any one time. It's a combination of the client software
> expects and what the target offers that ensures integrity.
>
> I should probably let someone else who has more insight into the
> storage 2.0 specific stuff clarify your questions, since I'm not 100%
> certain what those methods are intended for.
>
> On Mon, Mar 4, 2013 at 10:55 PM, Mike Tutkowski
> <mike.tutkowski@solidfire.com> wrote:
> > Interesting, Marcus...thanks for the comments.
> >
> > Yeah, the way it works on our SAN is a given volume is either accessible
> > via CHAP credentials or - if CHAP is not being used - a set of IQNs is
> > maintained and any initiator with a "proper" IQN can access the volume
> (we
> > depend on client-side software to be smart enough to not corrupt the
> state
> > of a volume).
> >
> > I wonder what you recommend in this situation?
> >
> > Thanks!
> >
> >
> > On Mon, Mar 4, 2013 at 10:45 PM, Marcus Sorensen <shadowsor@gmail.com
> >wrote:
> >
> >> On Mon, Mar 4, 2013 at 10:41 PM, Marcus Sorensen <shadowsor@gmail.com>
> >> wrote:
> >> > On revoke/grant access, If we're talking about individual volumes
> >> > being equal to a data/root disk, it's wise to adjust ACLs to only
> >> > allow access to the host that is currently wanting to run the VM/disk.
> >> > This way, cloudstack is authoritative in what's accessing the lun, and
> >> > you don't have to run a separate cluster/locking daemon. Otherwise, if
> >> > you launch a VM on a host, and that host goes rogue (loses some sort
> >> > of connectivity, but the vm remains running and connected to the
> >> > storage), when cloudstack tries to start that VM elsewhere then the
> >> > access to storage is cut off from the original VM. Having the same VM
> >> > running twice, connected to the same disk image, is a bad thing :-)
> >> >
> >> > In other words, before you start a VM or attach a disk, you'd revoke
> >> > access to everyone, then grant access to the host you're running the
> >> > VM/disk on.
> >>
> >> **disclaimer - I haven't done more than a cursory look at the storage
> >> 2.0 stuff, so what I'm saying might not even apply to what you're
> >> looking at now, but you probably should implement revokeAccess to
> >> remove ACLs based on the parameters passed.
> >>
> >> >
> >> > On Mon, Mar 4, 2013 at 10:21 PM, Mike Tutkowski
> >> > <mike.tutkowski@solidfire.com> wrote:
> >> >> Hi,
> >> >>
> >> >> I'm working on implementing a storage plug-in for CS 4.2.
> >> >>
> >> >> I'm looking at the following Wiki page for guidance, but have some
> >> >> questions:
> >> >>
> >> >> https://cwiki.apache.org/CLOUDSTACK/storage-subsystem-20.html
> >> >>
> >> >> One interface that needs to be implemented is PrimaryDataStoreDriver.
> >>  I'm
> >> >> not sure what is expected for all of the following methods:
> >> >>
> >> >> * grantAccess:  It looks like this is called in an attempt to confirm
> >> that
> >> >> the host which desires access to the volume in question is allowed
> to do
> >> >> so.  I suspect this is where CHAP credentials might be provided?  In
> my
> >> >> situation, there are a couple ways I'd like to restrict access:  1)
> >> CHAP or
> >> >> 2) allow a subset of IQNs to access the volume in question.  Is this
> >> kind
> >> >> of information provided to me here?  Do I simply return the IQN of
> the
> >> >> volume as a successful response from this method?  What if the access
> >> sent
> >> >> is not sufficient?  How do I deny access?
> >> >>
> >> >> * revokeAccess:  I don't really understand when this method would be
> >> called
> >> >> or why.  Perhaps I can simply implement it to return true (or false)?
> >>  In
> >> >> my situation, when a volume is dynamically created for a hypervisor
> of a
> >> >> cluster, I'd want to allow access to it from all hosts in the app
> >> cluster
> >> >> in question.  Maybe this method is called before the volume is
> deleted
> >> or
> >> >> something?
> >> >>
> >> >> * listObjects:  I don't really understand when this method would be
> >> called
> >> >> or why.
> >> >>
> >> >> * createAsync:  I believe this is where I place my code to create a
> >> volume
> >> >> (LUN) on our SAN.
> >> >>
> >> >> * deleteAsync:  I believe this is where I place my code to delete a
> >> volume
> >> >> (LUN) on our SAN.
> >> >>
> >> >> Thanks for any guidance here!
> >> >>
> >> >> --
> >> >> *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