Translate

Total Pageviews

My YouTube Channel

My YouTube Channel

Wednesday 9 September 2015

IBM STORAGE AND THE BEAUTY AND BENEFITS OF VVOL

I am just blogging this post again only for bookmark purpose as it is on http://blogs.vmware.com/virtualblocks/2015/08/26/ibm-storage-and-the-beauty-and-benefits-of-vvol/ but i found this article very informative.
Once more I’m pleased to offer a guest post from another highly valued partner of ours in the VVol 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 VVol, what problems we are all trying to fix, and how IBM helps deliver on the “beauty and benefits” of VVol based storage.
by Tony Pearson, Master Inventor and Senior Consulting IT Specialist, IBM, with contributions by other VVol lovin’ IBMers
email: tpearson@us.ibm.com
Blog: ibm.co/Pearson
Twitter: @az990tony
Back in 2012, I had mentioned that VMware was cooking up an exciting new feature called VVol, short for VMware vSphere Virtual Volume.
Officially, the VVol 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 VVol 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 VVol 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:VVol Support
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 “VVol 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 VVol. For example, you may want your VVol 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 VVol-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 VVol 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 VVol 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 VVol, these SAN-related tasks appear to be executed nearly instantly, leaving behind those legacy shared VMFS datastore limitations and overhead.
The same benefits of VVol 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 VVol purposes. Once VMware and storage administrators see the benefits of VVol, 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 VVol. 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 VVol and other VMware solutions in demo action at VMworld, in IBM Booth 1645. And be sure to catch the following IBM VVol-rich sessions:
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

Source:-
https://blogs.vmware.com/virtualblocks/2015/08/26/ibm-storage-and-the-beauty-and-benefits-of-vvol/
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)