Neither is overlay networking new. But that's not my point.
Ceph is merely an example I use to make the point that VMs accessing
storage servers over a virtual network is not IMO compatible with arguments
for a non-traditional cloud.
Feel free to provide other real world examples of real cloud storage other
than Ceph. Would love to see what's on your list.
Best. -- aldrin
On Sunday, August 26, 2012, wrote:
> That is the case anytime a hypervisor provides a VM with a "local" block
> device which is backed by network based storage ("VM itself does not need
> to connect to network storage"). This is not something new or unique
> provided by so called "cloud storage" such as Ceph.
>
> Cheers,
>
> Brad
>
>
>
> -----Original Message-----
> *From: *Aldrin Isaac [[email protected]]
> *Sent: *Sunday, August 26, 2012 07:45 PM Central Standard Time
> *To: *Black, David
> *Cc: *[email protected]; [email protected]
> *Subject: *Re: [nvo3] Storage (part of: Let's refocus on real world)
>
> AFAIK, scale out cloud storage software such as Ceph do not rely on FC,
> FCoE, NFS or iSCSI on the VM. Ceph storage appears to the VM as local
> storage and does not depend on network virtualization. VM migration is not
> an issue for Ceph since the VM itself does not need to connect to a storage
> server over the network. So as far as real cloud storage is concerned
> nothing is being swept under the rug.
>
> -- aldrin
>
> On Sunday, August 26, 2012, Black, David wrote:
>
> Robert,
>
> > Also as you have pointed out storage discussion can not be just swapped
> > under carpet and addressed by quote: "storage issues are out of the
> scope".
>
> I agree ... and that looks like my cue to say something ... e.g., see the
> domain part of my email address ;-).
>
> iSCSI and NFS use TCP/IP in the storage stack and hence will run fine over
> all of the data encapsulations being discussed here. If the iSCSI
> initiator
> or NFS client is in the VM, that's most of the discussion. That's not
> always
> the case for a number of reasons - the obvious one is that a hypervisor
> iSCSI initiator or NFS client is required if the VM's executable image is
> being
> loaded and/or paged using one of those protocols. It's also the case that
> many hypervisors simplify the storage interface presented to VMs so that it
> looks like direct attached or internal disk drives), and map those disks to
> networked storage using a hypervisor iSCSI initiator or NFS client.
> Ensuring
> that the VM migration destination hypervisor has appropriate connectivity
> to
> storage is mostly a configuration concern. The upshot is that iSCSI and
> NFS
> run fine over nvo3-encapsulated networks.
>
> In contrast, as I said at the microphone at the nvo3 BOF in Paris, I
> suggest
> that the WG not initially consider FCoE, in order to defer spending time on
> discussing how to deliver DCB Ethernet service/behavior (required by FCoE -
> ordinary non-DCB Ethernet isn't sufficient for FCoE because FCoE is *very*
> sensitive to drops) through the encapsulation(s).
>
> Thanks,
> --David
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of
> Robert
> > Raszuk
> > Sent: Saturday, August 25, 2012 11:55 AM
> > To: Ivan Pepelnjak
> > Cc: Black, David; [email protected]; Linda Dunbar
> > Subject: Re: [nvo3] Let's refocus on real world
> >
> > Ivan,
> >
> > > ... or I may be completely wrong.
> >
> > I think you are actually right on the spot correct.
> >
> > However I am afraid authors of this document are not likely to admit
> > that TOR switches should be just basic IP nodes providing only transport
> > between servers.
> >
> > Likewise they will not likely to admit that all logic of encapsulation
> > should happen on the hyper-visors as they are simply not in that
> > technology space.
> >
> > Similarly I very much agree and support providing clear distinction
> > between "cold" and "hot" VM mobility cases and perhaps even further
> > provide number of sub-classes hot VM mobility can be accomplish today -
> > clearly there is more then one way.
> >
> > Also as you have pointed out storage discussion can not be just swapped
> > under carpet and addressed by quote: "storage issues are out of the
> scope".
> >
> > While Linda was perhaps right to say that today most storage today is
> > coming to servers via backend this is what I would call very inefficient
> > and legacy way. If we are to think ahead one needs to observe how the
> > industry advances in storage virtualization via front-end IP very often
> > not co-located with the compute racks.
> >
> > In my view network related mobility discussion is not about TOR or about
> > VLANs. It is about an IP layer above IP transport which would carry all
> > necessary information of the actual location of the VMs and which in
> > fact would play the main role in shortening or eliminating the
> > triangular routing problem.
> >
> > Rgs,
> > R.
> >
> >
> >
>
>
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
