Saturday, March 14, 2015

VMware new Virtual volumes technical deep dive

   I was doing some research on new VMware concept of virtual volumes. Duncan has written good briefing on his blog yellowBriks/ about virtual volumes so i thought of writing another one which can cover little bit more detail.

Today's manageability issue:  
   In existing traditional environment we need a storage administrator to manage the Storage LUNs and storage tire related management. For each new configuration of storage LUN VMware admin has to approach storage guy to configure a LUN and do LUN mapping with respective storage protocol(iqn,wwn, or NFS share).
 Traditional LUN provisioning method has following issues.
  ->Manual bookkeeping to match VMs to LUNs
  -> Over provisioning
  -> frequent data migration (SVMotion)
  -> Long maintenance window for storage related modification.
  -> VMFS LUN has upper limit 62TB
  -> Max limit of 256 connections of LUN
 
Above issues are resolved using VASA provider, Storage container and protocol endpoint.

 A) VASA Provider: control path
      It is set of storage APIs that exposes to ESXi for management activity (eg. creating snapshot). these API will do mainly 3 things.
        1) Find files of VMs (VMDK, vmx, etc.) thats why we non't need File system (VMFS)
        2) Provides storage awareness service to vSphere
        3) Responsible for creating virtual volumes so Storage admin is not required to create traditional LUN.

B) Protocol Endpoint (PE): Data path
       It is data transfer protocol embedded to storage box which helps esxi to transfer data through data path.So now storage admin has to create protocol endpoints in storage and PE will communicate through all kind of storage protocol (eg. iSCSI/NFS). Zoning and multi-pathing policies and configuration will  go to protocol endpoint (PE).

  ESXI will automatically discover all PE by scanning storage in specific interval and stores it in database

   Storage Container: Data management
          So Now we do not have concept of LUN. Now all the VMs are stored as objects in Storage container (because we can not store VMs directly in hardware array) and the storage admin has to create container instead of LUNs

   So Still we need to create datastore which is equals to storage container the reason of retaining datastore concept is because of support native vSphere  features (FT, HA, etc.). Storage admin will see the storage container and and VMware admin will see it as datastore.Initially i thought storage container as new type of LUN but there is more of it.

   slowly storage will be managed through vsphere policies and we can define actually software defined storage concept. 

    Overall it looks very exiting features but as Duncan told we have to look at its downsides before selecting it as solution.