Cloud computing and storagePresentation Transcript
Cloud Computing and StorageImplementation 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