Part 1: Introduction
Part 2: With and Without VVols
Part 3: New Storage Constructs
Part 4: How are VVols instantiated
Part 5: Storage Containers & Capability Profiles
Part 6: The Mythical Protocol Endpoint
Over the last few weeks I’ve been delivering presentations with colleagues as part of internal and external training sessions on VMware VVol technology, and more specifically, it’s application when using HDS storage & software.
On August 18th VMware VVol was formally supported on HDS G1000 Storage, our first Block storage array to support VVol.
This post is the first in a series to share some of what I learned as well as how VVol will be realised with HDS technology. I hope that you will read on – this will not be a case of whether HDS implementation is better or worse than other – I will try to keep the series neutral but will describe HDS specific considerations for our customers.
We at HDS expect a phased adoption of VVol technology at least in terms of the planning and evaluation side, prior to migration. This will be due to the ramifications VVol brings to storage and virtual architectures, and more importantly the operational processes that need to be put in place to support VVol. There are significant opportunities to enhance operations with VVol which we are sure will be achieved.
Several layers of interoperability must be considered, not withstanding HDS or VMware features. So we are advising customers to consider this a number of months before deployment.
Start at the beginning
When will you deploy vSphere 6 ?
That is the first question that needs to be considered and one we ask customers first.
This is not a trivial concern due to the fundamental changes vSphere 6 brings to the landscape. Now is the ideal time to test drive the technology and get hands on experience which will inform better decision making. That depends on what equipment you have, but this is the only real way to “get your head around it”.
The ultimate deliverable and unit of consumption of VVol will be Virtual Machine Storage Policies, consumed by applications and VMs. That must not be forgotten !. Therefore, a VM Storage Policy is a fundamental construct in the VVol ecosystem.
Operational Benefits are key
No matter how you look at it, the operational benefits of VVol are clear, and even the most ardent debates ended up with audiences agreeing this point. That alone justifies adoption of the technology.
These benefits can be due to legacy constructs that exist within the presentation of storage (LUNs/VMFS) to virtual infrastructure which clearly needed a new framework. Zero Page Reclaim and SCSI UNMAP were highlighted by many on the VMware Administration side of the house as causing significant administrative overhead.
These will be a thing of the past with the adoption of VVol.
Not a question of If
In the sessions so far it is not a question of If, but rather How and When VVol can be implemented.
So in this series I will cover many of the key topics within what I am calling a foundational technology for the future of the virtual datacenter (if you’re a VMware customer).
Benefits to Cloud & “Storage As A Service”
If you are planning to consume storage at scale by provisioning large sets of virtual machines using a Cloud Management Platform (e.g. for DevOps), VVol will make possible what is otherwise very difficult from an operational perspective.
Consider creation of 400 VMs using lazyzeroedthick block allocation onto a thin pool, and the difficulties this incurs. This makes traditional storage unsuited to the rigours of flexible cloud consumption.
Now consider how the VVol disks of a Virtual Machine can be created and destroyed on-demand, via the VASA Provider. So control has moved to the hypervisor management layer. This is a KEY concept to grasp and will be a key benefit to cloud consumption models.
VVol allows consumption and capacity provisioning to be truly separate activities. This is a paradigm shift that allows a VM to be more easily offered as a service via service portal, including storage without the previous risks that went along with that.
The starting position for our sessions is always the organisational considerations. We believe VVol can help heal fractures between the Storage and Virtual Infrastructure teams in the same way it can bring closely-aligned teams even closer together.
in the next post I will start to describe the concepts from a storage and vCenter perspective. We will slowly build the picture up layer-by-layer to prevent confusion which can be common with VVol ……