author: Mark Carlson

1. Cloud Computing and Storage
Implementation Considerations on
APIs
Mark Carlson
Updated: 3/01/12

2. 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

3. 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.

4. 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?

5. 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

6. 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

7. 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

8. 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