HPE 3PAR and
VMware VVols
Driving innovation through partnership
What are VMware Virtual Volumes (VVols)?
A new storage paradigm for virtual machines
VVols are part of the VMware vSphere VASA 2.0 specification defined by
VMware as a new architecture for VM / storage array abstraction
The VVols architecture introduces new interfaces to query storage
functionality including Storage Containers and the capabilities they support
The VASA 2.0 definition also introduces new interfaces to allow the
provisioning and management of virtual machine volumes (VVols)
This information helps vSphere’s Storage Policy Based Management
(SPBM) make decisions about virtual disk placement and compliance
Unlike with the current datastore model, each virtual machine will have
multiple dedicated VVols
VMware vSphere datastore model
Existing storage methodology
Virtual machine disks (VMDKs)
Current Model
Today, volumes are presented from the storage array to the hypervisor and
formatted with VMFS. Multiple VMs are provisioned from the same datastore
Advantages
This is a well understood methodology, but also breeds simplicity. Only one
volume is used for multiple VM disks and configuration files resulting in less
entities on the fabric
Disadvantages
VMFS datastore
HPE 3PAR StoreServ
The lowest level of granularity for storage arrays is the datastore. The use of
snapshots, replication and other data services require the same process to be
applied to every virtual machine hosted on the datastore
3PAR volume
VMware vSphere Virtual Volume (VVol) model
Entirely new storage paradigm
VMware VVOLs hosting
virtual machine files
New Model
The VASA 2.0 specification describes the use of virtual volumes (VVols) to
ease management and improve granularity. A VVol can host a traditional
storage disk (VMDK), configuration file or even a swap file
Protocol Endpoint (PE)
The protocol endpoint is the management interface between the storage array
and the hypervisor. In the VASA 2.0 specification, the PE provides the
hypervisor access to the storage array to perform storage tasks
Protocol Endpoint
HPE 3PAR StoreServ
Advantages
This approach improves manageability as the hypervisor will provision
storage directly from the array as required. Granularity of data services is
improved allowing greater flexibility and reduced management
3PAR volumes
HPE 3PAR StoreServ is the reference platform for VVols
A unique partnership with VMware
At HPE we know that
partnership breeds innovation
HPE 3PAR StoreServ is the reference
platform used by VMware to design,
architect and test VVol technology for FC
deployments around the world
This close relationship means that HPE
3PAR always supports VVol technology
on the day of it’s release to ensure
customers first-class features
5
Protocol Endpoints (PE)
Clearing up confusion
Storage Update
OS Updates
OS 3.2.2MU2 - will be available in a 2-3 weeks
OS 3:3:1 - compression and will be released in the 2H2016
New SSD
7.68TB SSD - we are qualifying as we speak, but no release date
7
What is a Protocol Endpoint (PE)?
A management access point
A Protocol Endpoint (PE) is a logical access point that enables
communication between ESXi hosts and storage arrays for VVol traffic
vCenter Server
ESXi hosts with access to PEs are able to manage multiple VVols and
generate I/O with sub-LUN access through a single I/O channel
ESXi
ESXi
A PE should be transparent to SAN and NAS protocols (iSCSI, NFS, FC
and FCoE). Currently FC is tested and supported by HPE 3PAR StoreServ
According to the VMWare VASA 2.0 specification, PEs are created by the
storage administrator
The HPE 3PAR VVol implementation includes a PE LUN with ID 256
capable of providing sub-LUN access. It is created when the system boots
The PE provides no storage, it is simply a logical entity used to provide
administrative traffic and to direct I/O flow through the fabric
Protocol Endpoint
VASA
Provider
HPE 3PAR StoreServ
ESXi
VMware vSphere VVols and HPE 3PAR Virtual Volumes (VV)
Logical mapping
VVOLs
Storage Container
Due to the unique HPE 3PAR architecture, the VVol
concept is easily applied to 3PAR’s own Virtual Volumes
(VVs)
The vSphere VVol technology defines a storage
container (a logical entity) that encapsulates a number of
VVols
3PAR Virtual Volumes
(VVs)
Each VVol is again a logical entity, but unlike other
arrays a VVol on a 3PAR array is synonymous to a
3PAR Virtual Volume (VV)
This 1:1 relationship improves clarity and manageability
on the array site in contrast to other implementations
were multiple logical VVols are hosted per array volume
9
VVol Discovery
Gaining access to VVol-enabled HPE 3PAR arrays
During an ESX rescan, the 3PAR array reports the PE as a LUN with
LU_CONG bit set in INQ data according to the T10 specification
Request
sub-LUN
report
3
vCenter Server
Report
2
ESX hosts store the discovered PEs in their local database and
report them back to the vCenter server
ESXi
ESXi
ESXi
The vCenter server sends a request to the 3PAR arrays’ embedded
VASA provider asking to report sub-LUNs (VVs) bound to the PE
1
The VASA provider responds to the vCenter server with a report of
all available sub-LUNs (VVol IDs) bound to the PE
Protocol Endpoint
The HPE 3PAR PE LUN is capable of providing sub-LUN access. It
is only available when the host port is set to persona 11 (VMware)
VASA
Provider
HPE 3PAR StoreServ
4
Array responds with
report (using VASA)
Scan
3PAR StoreServ + VVol: the life of an I/O
A new logical I/O flow through the fabric
I/O requests are issued to the PE LUN from the ESXi hosts. Each
request contains two IDs, the PE LUN ID and the sub-LUN ID
I/O is received by the target port presented to the ESXi hosts from
the 3PAR array, it is destined to the logical PE LUN
Once the I/O arrives at the target port, the sub-LUN ID is extracted.
The sub-LUN ID describes the underlying VVol destination
ESXi
1
2
Write issued to PE logical LUN
Write received by target port
Protocol Endpoint
HPE 3PAR StoreServ
3
Sub-LUN ID read
from write I/O
Once VVol is determined, the array looks up the specific 3PAR
Virtual Volume (VV) the VVol represents
4
The I/O request is forwarded to the appropriate 3PAR VV where it is
dealt with as any other I/O request
Write I/O directed to
correct underlying VV
HPE 3PAR and vSphere VVol I/O Pathing
What really changed?
Step 1
Step 2
Step 3
Step 4
An I/O request was
issued by the host,
addressed to the
logical PE
An I/O request was
received by the target
port on the 3PAR
The sub-LUN ID was
extracted and mapped
to the VVol/VLUN
Data is written to/read
from the destination
3PAR VV
Change
Change
Change
Change
No change, this is the
same as any other I/O
request
No change, this is the
same as any other I/O
request
This is essentially the
same as any other I/O
request which is mapped
to the underlying 3PAR
VV
No change, this is the
same as any other I/O
request
12
VMware VVol Protocol Endpoint advantage
Improving end-to-end storage management
VMware vSphere Protocol Endpoint
Improving manageability
Increasing scalability and simplicity
A single, logical path used
for administrative traffic
reduces complexity for
storage administrators
The Protocol Endpoint
acts as a logical proxy for
traffic as it flows through
the fabric
The creation of additional
VVols has no impact on
the fabric, zoning or
masking
13
Protocol Endpoints
Queue Depth Performance
14
Calculating Queue Depth
The new provisioning method for VVols changes Queue Depth
– To calculate the queue depth for a fabric environment, we will use the following equation:
Port QD = Host1(Host paths * LUNs * Host QD) + Host2(Host paths * LUNs * Host QD) + … + Hostn(Host paths * LUNs * Host QD)
– For vSphere ESXi, the default Queue Depths are as follows:
– Datastore: 32
– VVol PE: 128
Note that these are default values and can be increased by the vSphere administrator if required
Queue Depth Whitepaper: http://h20195.www2.hp.com/v2/GetDocument.aspx?docname=4AA4-5094ENW
15
Simple ESXi Datastore Multipath Topology
Logical view for 8200 2-Node
Queue Depth Calculation
20 x VM
ESXi
ESXi
ESXi
ESXi
Hosts per target port: 2
LUNs per target port: 2
Default queue depth: 32
Target ports: 4
Total QD per port: 2 x 2 x 32
Total QD: 128 x 4
HPE 3PAR StoreServ
Queue Depth
512
Datastore Volumes
16
Note: Host / VM / datastore ratio data from vOpenData: http://dash.vopendata.org/
Simple ESXi PE Multipath Topology
Logical view for 8200 2-Node
Queue Depth Calculation
20 x VM
ESXi
ESXi
ESXi
ESXi
Hosts per target port: 2
LUNs per target port: 1
Default queue depth: 128
Target ports: 4
Total QD per port: 2 x 1 x 128
Total QD: 256 x 4
Protocol Endpoint
Queue Depth
HPE 3PAR StoreServ
1024
VVOL Volumes (x20)
Comparative queue depth: VVols vs. datastores
Assuming defaults
Datastore available queue depth
PE available queue depth
512
1024
In these two common environments (as defined by openly available data)
using a single PE reduces the likelihood of a performance bottleneck
when using default values
Based on the solution shown, if required for performance reasons it would be possible
to increase the per-PE queue depth on the vSphere hosts up to 1536 without
exceeding the per-target port queue depth
18
Thank you
19