Team!
Happy Saturday all! Tonight, I wanted to dip a little bit into the storage topic as it pertains to VMware and touch on the “data store versus VVol” debate. This is a conversation that I had a few months back had with one of my clients and I wanted to share some of the key thoughts behind what was discussed. Let’s go ahead a jump right into the post…
What’s a VVol?
If you haven’t been exposed to it before, VVols are a “newer age” type of storage that can be used instead of your traditional VMFS data store. I believe they’ve been around since circa 2012-ish, but a major revision was made to them and released in vSphere 6.5. That’s when they started to see a better adoption rate. VVols and data stores fundamentally accomplish the exact same thing; they are a storage component within vCenter (a VCSA is required to use them) where you can house data, VMs, etc. The way they operate is completely different. A VVol does not have a file system type and makes use of a pool of raw storage on the storage device (Look ma! No volumes needed!). This pool is called a Storage Container. It’s possible to have multiple SCs on your storage device if you wish to separate the data by different performance policies, or logically separate your web, app, database, etc. tiers if you please. This SC gets presented to your host(s) as a normal data store would. From there, you can start migrating your workloads to the vVol. Simple, right? Yes, and it is, but there’s a little more to it than that.
A What Provider?
For all of this to work, the storage device needs to have a VASA provider in it (VASA 3.0 is highly recommended). A VASA provider is a software component developed by the storage vendors and acts as a liaison between your VCSA and hosts, and the storage system. It can be in the form of a virtual appliance or native in the storage’s firmware. It provides APIs (vSphere APIs for Storage Awareness) for consumption by vCenter/vSphere. It allows your VMware infrastructure to understand what your storage system is capabilities of. These are easily integrated into vCenter by clicking your VCSA in any view > Configure > Storage Providers. You’ll need to provide an inventory/display name, the URL to the VASA provider which is usually something along the lines of https://[management IP or hostname]/vasa/version.xml, and credentials for your storage device. Don’t worry, they are not saved. They are used to retrieve a certificate from the VASA provider for communications.
What do I get out of it?
A VVols has a slew of benefits to both the storage and VMware admins. How many times have you logged into a vCenter and seen tens of data stores that you had to manage, maintain, and monitor? VVols can easily eliminate that and provide less admin overhead for both the VMware and Storage teams. With our client, we discussed one VVol per cluster for the sole purpose of logically isolating the workloads. “Don’t put all your eggs in one basket!” I knew this was coming. Sure, it may seem like one “basket”, but that the object that you see in vCenter is just a SC. If you dig deeper into the folder structure, you’ll notice that the paths of each of your VMs are different. They all have unique WWNs, so technically each VM is really its own “LUN”.
Let’s talk maintenance. I’ve been assisting with VVols for a handful of years now and, sure, you still must contend with the typical storage concerns like over-provisioning, growth, I/O performance, etc., but the only real maintenance is that you have to renew the cert on the storage provider in your VCSA before it expires. The typical life of the certificates that I’ve seen is one year. I’ll get into what happens if you don’t a bit later.
On to performance. Using VASA allows you to offload operations from your vSphere hosts to your storage device. Your SAN will be performing the clones (given that they are on the same device), snapshots, and other operations natively taking the load away from your hosts to allow something else to consume those CPU cycles. Let the storage unit do what it was designed to do, manage storage.
With VMFS data stores, if you were running Windows Server Failover Clustering you had to thick provision the disks shared amongst the cluster nodes. As of vSphere 6.7, VVols allow you to use thin provision disks instead so you can reclaim that unused space. It also permits the use of vMotion, HA, and DRS!
…and when my VASA provider breaks?
Yes, it’s true, the VASA provider is the middleman to all this magic. What if it breaks? Well, there’s different scenarios that can be used to protect against this. If you’re using a virtual appliance as a VASA provider, then chances are they allow a high availability configuration of some type. Even if they didn’t you could also meet the requirements of Fault Tolerance and enable it on this VM. If you’re relying on a VASA provider that is embedded in the storage system then you would (or should) have different levels of fault tolerance built-in to the unit to protect you against it going offline – multiple management interfaces with a virtual IP, multiple heads/storage processors, etc. I haven’t answered the question though. If it goes offline, or you forget to manually renew the certificate for your VASA provider (which essentially makes it unavailable also) the VVol will show inaccessible status in vCenter. However, your VMs and vCenter will continue to operate as normal with a few exceptions. You will not be able to create new VMs, take snapshots, power on existing VMs that are powered off, etc. Reboots will let you bring the machine down, but then you’ll hit a snag when it goes to boot so be careful!
The quick summary
All-in-all, if the you have the capability to make use of VVols I highly recommend it. It provides some substantial benefits to both your storage and vSphere infrastructures that are hard to shy away from. Below, I’ve shared some of the references that I use when we’re asked by clients for our input.
Thanks for reading. If you enjoyed the post make sure you check us out at dirmann.tech and follow us on LinkedIn, Twitter, Instagram, and Facebook!
References:
https://cormachogan.com/2015/12/04/losing-vasa-vcenter-in-vvols/
https://blogs.vmware.com/virtualblocks/2018/05/31/scsi-3-vvols/
https://blogs.vmware.com/virtualblocks/2019/08/20/hpe-vvols-10-reasons/
https://www.codyhosterman.com/2017/10/comparing-vvols-to-vmdks-and-rdms/
Paul Dirmann (vExpert PRO*, vExpert***, VCIX-DCV, VCAP-DCV Design, VCAP-DCV Deploy, VCP-DCV, VCA-DBT, C|EH, MCSA, MCTS, MCP, CIOS, Network+, A+) is the owner and current Lead Consultant at Dirmann Technology Consultants. A technology evangelist, Dirmann has held both leadership positions, as well as technical ones architecting and engineering solutions for multiple multi-million dollar enterprises. While knowledgeable in the majority of the facets involved in the information technology realm, Dirmann honed his expertise in VMware’s line of solutions with a primary focus in hyper-converged infrastructure (HCI) and software-defined data centers (SDDC), server infrastructure, and automation. Read more about Paul Dirmann here, or visit his LinkedIn profile.
