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
