This summer is a great time to be a VMware and NetApp user, especially if you happen to be in the service provider space. Why? This summer NetApp is releasing version 10.0 of ONTAP tools for VMware vSphere. This release is completely rearchitected for the needs of the modern hybrid multi-cloud environment we find ourselves in today.
This initial release of the ONTAP tools 10 family is specifically designed with an API-first approach for internal, or external, cloud service providers (CSPs), and transitions away from the legacy monolithic application architecture of ONTAP tools 9.x, to a modern microservice-based and horizontally scalable architecture that eliminates all single points of failure in the stack.
Being driven with an API-first approach, version 10.0 will not have the GUI extensions you’ve all come to know and love from ONTAP tools 9.x. Likewise, it won’t have a storage replication adapter (SRA) or legacy (non-vVols) datastore support. It is in essence a dedicated VASA Provider designed only for vVols at cloud scale. However, rest assured all those features are returning in the next release!
With the introduction out of the way, let’s dive into the top five reasons why this is important to you (in no particular order).
Multi vCenter support
For the first time, ONTAP tools will support registration with multiple vCenter servers. To enable that, there is a centralized management system that facilitates managing storage access and registration with, the vCenter servers in your environment.
Secure multitenancy
The enterprise IT organizations of today are being transformed into automation and API-driven cloud service businesses, delivering everything imaginable on demand with the click of a button to their service consumers. Be they internal business units, or external tenants. Think of this as the service provider operating model.
ONTAP tools 10.0 offers intrinsic secure multitenancy, isolating your tenants from each other, whether they are your own financial operations (FinOps) department with their own VCF workload domain or an external secure customer who wants to leverage cloud-like service delivery but has data sovereignty concerns. When you use ONTAP tools 10.0 to allocate storage to a vCenter, you assign it one or more SVMs from which the vSphere admins can provision and manage vVols datastores. No SVM can interact with any other SVM since they are isolated within ONTAP itself. Likewise, no vCenter user who uses ONTAP tools can see what’s going on with another vCenter user (unless you want them to).
vVol mobility
vVols can now be moved from one vCenter to another (again - if you allow it). Consider this scenario: as a service provider, you may have a collection of virtual machines (VMs) in a central repository that you wish to offer for purchase to your tenants. By utilizing your self-service portal, tenants can buy the VMs and have the virtual volumes (vVols) cloned and transferred from the central repository to their secure environment. This process is automatically managed by the software, based on the API inputs you provide.
Simplified deployment, high availability, and scale-out capability
Ok, that’s actually three things in one, but it’s all related to the new architecture. To begin, you can deploy standard OVA templates just as you always have. Unlike many K8s applications, you don't need to bring your own distro. We understand that vSphere and storage admins may not have convenient access to an in-house K8s cluster, so we provide a pre-canned/pre-configured K8s distribution for you to utilize.
To simplify deployment even further, we will be providing Ansible samples to help you automate your deployment.
This has the additional advantage of allowing us to control what K8s flavor is being used and guarantee a higher level of quality and predictability than we would if we had to rely on unknown and untested K8s builds.
As mentioned previously, our latest scale-out architecture involves using standard OVAs. We achieve this by distributing workloads across deployed VMs (K8s nodes supplied by NetApp as OVAs), using a load balancer, and leveraging NetApp's Trident CSI technology for Kubernetes persistent volumes to store vVols state and app data directly in ONTAP. In the first release of ONTAP tools 10.0, we will use a three-OVA replica set for HA and load balancing, which can be deployed in different locations on campus for increased fault tolerance. If your service model requires more distributed AZs within a region, you can use them if they meet our latency requirements. This design allows us to scale out by adding more K8s nodes in the future (i.e. deploying more OVAs) with more preconfigured options to increase the system's tenant, VM, host, and vVol capacity. We also plan to enable resizing in the future (e.g., between small, medium, and large appliances), giving you more flexibility in expanding your datacenters.
In the demo lab, we’ve scaled to 152316 vVols across 5 vCenters with each one having a large collection of hosts accessing 5 vVols datastores each -- And have not found the limit yet!
--
--
--
Of course, one of the limitations of ONTAP tools 9.x was that it relied on vSphere HA and FT for protection. That’s no longer the case with ONTAP tools 10.x since we eliminate any single point of failure and protect the data with ONTAP.
Simplified day-2 operations
All of this brings us to the major advantage of using vVols to begin with. Smarter, simpler, and faster day-2 operations at scale.
With all of that said, if you are a service provider, or run an automation-heavy IT organization, you should be looking very hard at vVols at this point for optimizing your services, simplifying your workflows, and delivering peak system performance.