Once more I’m pleased to offer a guest post from another highly valued partner of ours in the vVols space, and another design partner for Virtual Volumes: IBM.
Today’s post talks about some of the history of how IBM came to realize the promise of vVols, what problems we are all trying to fix, and how IBM helps deliver on the “beauty and benefits” of vVols based storage.
By: Tony Pearson, Master Inventor and Senior Consulting IT Specialist, IBM, with contributions by other vVols lovin’ IBMers
Email: [email protected]
Blog: ibm.co/Pearson
Twitter: @az990tony
Back in 2012, I had mentioned that VMware was cooking up an exciting new feature called vVols, short for VMware vSphere Virtual Volume.
- June 2012: [Day 3 of IBM Edge breakout sessions”], Steve Foskett was excited over solving the “I/O Blender” problem.
- October 2012: [IBM Storage VMware Integration: Get ready for VM Volumes], I went into more detail of what to expect.
Officially, the vVols concept was still just a “technology preview” in 2012, to be fleshed out over the next few years through extensive collaboration between VMware and all the major players: IBM, HP, Dell, NetApp and EMC.
In 2013 and 2014, IBM attended VMworld with live demonstrations of vVols support. VMware vSphere v6 was not yet available but when it was, we assured them, IBM would be one of the first vendors with support!
When vSphere v6 was finally made available earlier this year, [only four vendors support vVols on Day 1 of vSphere 6 GA!], keeping true to its promises, IBM was indeed one of them.
To understand why vVols is such a game-changer you have to understand a major problem with VMware version 4 and version 5, namely, their Virtual Machine File System, or [VMFS].
Here is a picture to help illustrate:
On the left, we see that VMFS datastore is a set of LUNs from the storage admin perspective, and a set of VMDK and related files from the vCenter admin perspective.
If there was a storage-related problem, such as bandwidth performance or latency, how would the two admins communicate to perform troubleshooting? For many disk systems, it is not obvious which VMDK file sits on which LUN.
There are also a variety of hardware capabilities that work at the LUN level, such as snapshots, clones or remote distance mirroring, and this would apply to all the VMDK files in the datastore across the set of LUNs — which may not be what you want.
There are two ways to address this in vSphere v4 and v5:
- The first method is to have fewer VMDK files per datastore. By defining smaller datastores with just a few VMs associated with each, you can then have a closer mapping of VMDK files to datastore LUNs. Unfortunately, VMware ESXi has a 256 limit on the number of different datastores that can be attached, so this method has its own limitations.
- The other method around this is “Raw Device Mapping” (RDM) which allowed Virtual Machines to be attached to specific LUNs. Some of the earlier restrictions and limitations for RDMs have since been relaxed over the releases, but your disk system still needs to expose the SCSI identifiers of each LUN to make this work, and additional setup is required if you plan to cluster two or more systems together, such as for a Microsoft Cluster Server (MSCS).
On the right side of the picture, using VMware v6, vCenter admins can now allocate vVols, which are mapped to specific “vVols Storage Containers” on specific storage systems. The storage admin knows exactly which vVol is in which container, so they can now communicate and collaborate on troubleshooting!
The vSphere ESXi host communicates to storage arrays via a new “virtual LUN id” called a “Protocol Endpoint”. This is to allow FCP, iSCSI and FCoE traffic to flow correctly through SAN or LAN switches. For NFS, the Protocol Endpoint represents a “virtual mount point,” so that traffic can be routed through LAN switches correctly.
Storage Policies can help determine which attributes or characteristics you want for your vVols. For example, you may want your vVols to be on a storage container that supports snapshots at the hardware level. The vCenter server can be aware of which storage arrays, and which storage containers in those arrays, through the VMware API for Storage Awareness, or VASA.
Different storage manufacturers can implement their VASA provider in different ways. IBM has opted to have a single VASA provider for all its supported devices, so as to provide a consistent client experience. When you purchase any vVols-supported storage system from IBM, you are entitled to download the IBM VASA provider at no additional charge.
Initially, the IBM VASA provider will focus on IBM XIV Storage System, an ideal platform for your vVols needs. The XIV is a grid-based storage system, utilizing unique algorithms that give optimal data placement for every LUN or vVol created, and virtually guarantees there will be no hot spots. The XIV provides an impressive selection of enterprise-class features, including snapshot, mirroring, thin provisioning, real-time compression, data-at-rest encryption, performance monitoring, multi-tenancy and data migration capabilities.
With the XIV 11.6 firmware level, you can define up to 12,000 vVols across one or more storage containers in a single XIV system. For more details, see IBM Redbook [Enabling VMware Virtual Volumes with IBM XIV Storage System].
Let me give some real world examples from Paul Braren, an IBM XIV and FlashSystem Storage Technical Advisor from Connecticut who has been working directly with XIV VMware clients over the past five years:
“Many of my customers have clearly said they really want the ability to have a granular snapshot that grabs a moment in time of just one VM, rather than all the VMs that happen to be on the same LUN. They also want to delete VMs and have the storage array automatically present that newly available space. Even better, with vVols, these SAN-related tasks appear to be executed nearly instantly, leaving behind those legacy shared VMFS datastore limitations and overhead.
The same benefits of vVols are evident when cloning or deploying VMs. Imagine being able to create a Windows Server VM with a 400GB thick-provisioned drive in under 20 seconds. Well, you don’t have to imagine it… it really happened and is captured in the video above, which I recorded at IBM’s European Storage Competency Center.
Of course, VMware will still continue to support VMFS and NFS datastores, for legacy environments. IBM storage systems will concurrently support both LUNs for traditional VMFS datastores, as well as having storage containers for vVols purposes. Once VMware and storage administrators see the benefits of vVols, however, I suspect the use of VMFS will fade out over time.
2015 sure is shaping up to be exciting for many IBM Storage customers, eager to enjoy the benefits of vVols. This paradigm shift in storage makes our customers’ virtual environments both faster and more manageable. These exciting possibilities are very real, and available already today on the XIV Storage System (shameless plug… ;-).”
We warmly invite you to see our exciting vVols and other VMware solutions in demo action at VMworld, in IBM Booth 1645. And be sure to catch the following IBM vVols-rich sessions:
- Mon, Aug 31, 1 pm, “Optimizing VMware vVols with IBM Storage,” a 10 min lecture by Yossi Siles, IBM VMware SME, IBM Booth #1645
- Tues, Sept 1, 2015, 1-2 pm, STO6671, VMware & IBM: Optimized to Manage Oceans of Data in a Digitally-Driven World, Carlos Fuente, IBM Distinguished Engineer, Paul Braren, IBM Storage Technical Advisor,VCP, vExpert
- Wed, Sept 2, 1-2 pm, STO5522, Virtual Volumes Technical Panel, Carlos Fuente, IBM Distinguished Engineer, as panelist
Learn about all IBM sessions and activities at VMworld2015 here: ibm.co/1Clt9Mg
And we’d love to meet you! Sign up for a one on-one with our SMEs here: ibm.co/1GhJY65
