The application landscape is changing. In recent years, we have seen containerized, microlithic applications emerge alongside the traditional monolithic application, the latter normally found in virtual machine deployments. This raises a number of challenges for those who have a responsibility for managing and monitoring not just the health of the applications, but also have responsibility for the health of the underlying infrastructure on which the applications are deployed. In this article, I will highlight some of the benefits of hyperconverged infrastructure to address these challenges, with a focus on vSphere and vSAN.
HCI Simplifies Compute and Storage Management
vSAN is VMware’s Hyperconverged Infrastructure (HCI) offering. It takes the local storage from a network of ESXi hosts, and aggregates them into a distributed datastore which can then be used for provisioning workloads. VMware HCI enables admins to quickly provision and manage both compute and storage using existing virtualization tools, vSphere and vCenter. Scale up and scale out are both achieved by simply adding additional storage devices to a host, or adding a new ESXi host to the cluster respectively. HCI lifecycle management is fully integrated into the vSphere Lifecycle Manager product, with an embedded rolling upgrade methodology. Production is therefore not impacted by infrastructure upgrades or patching. While originally developed for the more traditional virtual machine workloads, vSAN is also proving to be an ideal platform for modern, containerized applications. Many VMware customers have already positioned vSAN for both their traditional and modern applications. Read on to see why.
VMware Enhances Infrastructure Visibility for Containerized Applications
One of the major concerns imparted to us by infrastructure managers is lack of visibility into how infrastructure resources are being consumed by containerized applications. For example, while IT Operators could see overall storage consumption, it was not easy to determine which applications from which Kubernetes clusters (deployed as a set of virtual machines on vSphere) were consuming which resources. This was especially problematic when there were multiple development teams and multiple Kubernetes clusters running on the same vSphere infrastructure.
This was the driving force behind our Cloud Native Storage initiative, which bubbles low level Kubernetes cluster and object metadata up into the vSphere client user interface. This provides IT Operations with full visibility into how an application is consuming vSphere storage. In this first view below, we can see the Persistent Volumes that are currently provisioned on a Kubernetes cluster that is itself provisioned as a set of virtual machines on top of a vSphere/vSAN HCI platform.
vCenter provides important information, such as:
- The volume name
- Type of storage in backing the volume (in this case it is block storage)
- Labels associated with the volume
- vSphere storage / datastore it is provisioned on
- Storage policy used to provision the volume
- Volume ID
- Kubernetes Cluster that it has been provisioned from, and
- Capacity quota
In environment where the number of PVs can easily run into the thousands, a filtering mechanism is also provided to quickly locate the interesting volume or set of volumes, based on a range of criteria such as Label, Kubernetes cluster, or PVC name.
In the Volume Name field, we provide an option to get even more insight into the volume. By clicking on the “Details” icon, we can discover:
- The name of the persistent volume claim (PVC) used to provision the volume,
- Which Pods are using it (if any), and
- Which namespace within the cluster the application resides
This is extraordinarily useful information for anyone who is managing infrastructure on which Kubernetes clusters are provisioned.
All of this is made possible by the vSphere CSI driver, which handles persistent volumes operations between a Kubernetes cluster and vSphere. Along with these volume operations, the vSphere CSI driver sends useful metadata to the Cloud Native Storage (CNS) component on vSphere, which is in turn exposed in the vSphere client UI to provide ease of management and monitoring.
Whilst the vSphere CSI driver supports all types of vSphere storage, it is particularly well suited for vSAN since it has the ability to display information about the storage objects which make up the persistent volume on the vSAN datastore. For example, if we look at the Physical Placement view in the above example, we can see that the Kubernetes persistent volume is provisioned as a RAID-1 on the vSAN datastore. The objects that make up the RAID-1 mirror are displayed, indicating which ESXi host and which physical storage device the components reside. This is critical information that can be quickly and easily discovered on this platform.
VMware HCI Provides Critical Data Services
Now that we have spent some time on the management and visibility aspect of VMware’s HCI platform, the next question you may have is regarding data services. vSAN offers the ability to protect persistent volumes using a range of storage policies, such as
- RAID-1 shown above for application performance
- RAID-5 and RAID-6 for capacity savings
- RAID-0 for apps with their own built-in protection, Thus, no protection of the PV is done at the infrastructure layer, when protection can be provided at the application level.
All of these policies can be simply consumed by adding a specification to the storage classes defined at the Kubernetes layer. The storage class parameter is mapped to a storage policy by the vSphere CSI driver in Kubernetes and the CNS component in vSphere at persistent volume provisioning time, resulting in the persistent volume matching the storage policy requirements.
Other vSAN data services which can be leveraged by Kubernetes Persistent Volumes include space efficiency services such as deduplication and compression, and security features such as Data-At-Rest encryption and Data-In-Flight encryption.
VMware HCI Provisions RWO and RWX for Persistent Storage
There is another service which would be of particular interest to the Kubernetes application developer. Alongside the vSphere CSI driver’s ability to dynamically provision read-write-once (RWO) vSAN block volumes for persistent storage, it also has the ability to dynamically provision read-write-many (RWX) vSAN file shares for persistent storage. The ability to dynamically provision RWX volumes allows the resulting volume to be shared by multiple Kubernetes Pods, a much sought after feature. Here we have a platform that can provision both block and file volumes, as well as provision both RWO and RWX volumes, for containerized applications that require persistent storage. And whilst the protocol for these RWX volumes in Kubernetes is NFS (both v3 & v4.1), vSAN File Service also supports SMB file shares for tradition applications.
Since the RWX volumes are provisioned via the vSphere CSI driver, CNS also has the ability to display all sorts of useful information about these volumes in the vSphere client just as it does for RWO block volumes. Here is an example of a RWX volume that is backed by a vSAN file share bubbled up once again by CNS to the vSphere client UI.
VMware HCI Enables Backup and Restore of Modern Applications Through Velero
I’d like to finish this article by highlighting one of the most pressing concerns that many IT Operators have today with container-based, modern application workloads, and that is the ability to backup and restore these applications. VMware is uniquely placed to address this concern through its Velero product range. Whilst Velero is open source (VMware itself is a major contributor to Kubernetes), VMware has developed a vSphere plugin for Velero which enables backup and restore of applications running in Kubernetes. The vSphere plugin uses VMware snapshot technology to capture a point-in-time copy of your applications running on vSphere storage, including vSAN. This backup copy is moved to an S3 object store and is available for future restore and migration operations. This plugin works on vSphere with Tanzu, TKGs (the vSphere with Tanzu TKG service), as well as TKGm (Tanzu multi-cloud) and upstream Kubernetes distributions.
Learn More About VMware’s Cloud Native Storage Products
In conclusion, I hope this has provided a useful insight into why we at VMware feels that our vSphere + vSAN hyperconverged infrastructure is an excellent platform for your traditional virtual machine applications, for Kubernetes clusters deployed as virtual machines, and of course, for your new containerized applications that require persistent storage. Thank you for reading. For further information please check out VMware’s Cloud Native Storage page.