VMworld 2018 is just around the corner. This will be my 12th time in attendance, and I’ve had the opportunity to see quite a few new approaches and technologies come to the field in that time. There have been some amazing improvements in VMware over that time. I could never have envisioned what has become the norm when I began this journey using ESX 2.11. Massive improvements from VMware, with cloud integrations, containers, storage APIs, and wonderful additions to the size and functionality of the VMs themselves.
APIs and I/O
One of the most significant set of changes have been those surrounding storage APIs. vStorage API for Integration (VAAI), was announced roughly 10 years ago while I was in my vSpecialist days. By far, the largest component to this was the defining of a set of storage primitives that allowed for greater control over the I/O presented by the storage. This allowed for a higher degree of storage tiering protocols, allowing for a much more fleshed out bidirectional communication language between storage vendors and the VMware infrastructure.
Along with this greater integration, things we now take for granted, like Eager Zero thick, Full cloning, Native snapshotting, Thin provision stun, additional tunings, etc. became part of daily operations. To be clear, VAAI made the gap between the VMware administrator and the storage administrator a much smaller one. It truly began the process of removing these discrete silos of operation in the virtualization platform’s hierarchy of processes. The VAAI API set reached the end of its development in early 2013.
VAAI gave way to next major integration set, that of VASA, otherwise known as the vStorage API’s for Storage Awareness. These were introduced in the code base that was vSphere 5.0 and have been enhanced ever since. Initially designed to assist in the facilitation of the SDDC model, which conceptually began in the VAAI standard, these API’s have taken some time for some storage vendors to fully adopt. Among the key technologies launched by these API’s were the concepts of VVols, and the “Storage Virtual Appliance.”
To me, VVols or Virtual Volumes has been a critical aspect. As a discrete technology, the VVols approach places far more I/O control in the hands of the administrator. VVols takes the I/O control out of that of the individual volume and places it more squarely on that of the application itself. If a high transaction database is being virtualized onto an older storage platform, one in which the VVols set does not apply, that database would have been bound by the I/O parameters of the whole volume. Then growth of that database may be limited to the sizing parameters of that volume. Today with VVols, regardless of where the physical storage is located, the profile of the application within the virtual infrastructure would define the type of availably I/O to be provided. As a VMware administrator, these capacities granted me far more viability to control my application’s performance against the overall storage speed capacities. By simply choosing the profile of the storage to which to assign the application, we are now given the ability to assign speed capacities toward the application.
Supporting VVols
As Cody Hosterman wrote here, a huge addition to the validation of the Pure Storage platform for the API integration is the fully fleshed out support for VVols in the current release of the Purity operating system. Cody’s blog post illustrates many of the integrations. In addition, he points to many sessions being held at VMworld 2018 in which these adoptions, APIs, and even customer use-cases will apply. Of particular interest to me is that of Krispy Kreme, who are leveraging VVols extensively, and are improving their analytics on these delicious pastries.
The adoption of VVols within the FlashArray family allows the administrator so much control over the way the individual applications perform within a VMware environment residing on Pure storage that the deployment of these applications and their components are far more easily managed and give the storage full policy-based application management, along with very simple migration and policy defined upgrades to these applications.
There is so much in the way of I/O provided by the FlashArray in general that these platforms don’t always require this granular approach to the application deployment. There may be times when the administrator has a desire to deliver that I/O to certain applications over others, and allow the policies to handle the distribution of the I/O capacity.
