cloud computing and storage
DESCRIPTION
author: Mark CarlsonTRANSCRIPT
Cloud Computing and Storage Implementation Considerations on
APIs
Mark Carlson
Updated: 3/01/12
Various Discussion/Issues • In a Cloud Computing (IaaS) interface, how much information do you need to
expose about the storage connections and fabrics/networks used to connect the virtual machines with their volumes?
• Principals of information hiding and abstraction come into play • Private clouds and public clouds may have different requirements • Information includes:
– Interface type • Block (SAN) • File (NAS)
– Access Control • Principals • End point addressing • Fabric/VLAN Management
Background on Storage Protocols • For Fibre Channel and FCoE
– A Host Bus Adapter (HBA) or Converged Network Adapter (CNA) is required on the host
– This can be virtualized for each guest using N Port ID Virtualization (NPIV) – special driver on guest
• For IP Storage (iSCSI, NFS, CIFS/SMB/SMB2) – Only a NIC is required on the host – Guest OS loads iSCSI initiator driver or remote filesystem client
• Volumes versus disks – Volumes are shared, persistent over start/stop cycles (SAN/NAS) – Disks are provided by the Hypervisor from internal filesystem (DAS)
• Cloud provider may use different SAN/NAS technologies and different protocols between physical server hosting a virtual machine and the storage
• For Volumes, Hypervisor may also play a role to "adapt" protocols/interfaces to match client specification – e.g. virtual machine 'sees' a volume as a local SCSI device ”mapped" to a
raw device by hypervisor which in fact accesses the remote volume using iSCSI etc.
Two Basic Models for Implementations • Rather than continue to add storage concepts and management functions to
CIMI, perhaps we should reference an existing cloud storage standard (CDMI) • If the IaaS API implementation is provided by one vendor and the DaaS API
implementation is provided by a different vendor, how do they coordinate the connections? (Slide 4 shows a picture of this)
• If the IaaS API and DaaS API implementations are provided by a common infrastructure (orchestration) can the information that is exposed be abstracted/simplified? (Slide 5 shows a picture of this)
• Does the back end storage network have to be exposed in all cases? • Or can it’s management be “orchestrated” and the storage network
implementation hidden by the API?
Separate Infrastructure Implementations • Because the two
infrastructures have separate implementations, there must be information in the respective APIs that allow for Cross-Communication
• The IaaS implementation may be a Client of the DaaS API
• The DaaS implementation may be a Client of the IaaS API
Common Implementation Infrastructure • Because there is a
common implementation, the back end storage network can be “hidden” and private
• The connectivity information about this network does not need to be exposed through the APIs
• The cross communication between IaaS and DaaS implementations happens internally
Proposal
• If there are sufficient members that see a situation where we need separate implementations, we need to allow for the storage connections information to be exposed.
• Add the connectivity and credential information to the APIs but make it optional to implement (in the common infrastructure case).
• Make it as simple as possible
Proposition: Needed parameters
• Shared Storage Protocol type – FC, FCoE, iSCSI, NFS, CIFS/SMB/SMB2
• Shared “device” addressing – IP address/FQDN for IP Storage – FC WWN for FC based storage
• Share “Name” – Exported Filesystem Name (NFS/CIFS) – Target:LUN (iSCSI, FC, FCoE)
• Unique Device identification across guest Machines – Provider needs freedom to supply this from their own
infrastructure (may be opaque to client) – If Provider is also an implementation of CDMI – this would
be CDMI ObjectID