Home > Storage > PowerStore > Virtualization and Cloud > Dell PowerStore: VMware vSphere with Tanzu and TKG Clusters > A highly available Tanzu infrastructure
With traditional block and vVol storage, an unexpected infrastructure outage can lead to downtime and challenging recovery options for a Tanzu environment. This is because some of the Tanzu components and their corresponding storage components cannot be protected and easily recovered using traditional methods such as snapshots and asynchronous or synchronous replication. Examples of these objects can be found throughout the Workload Management hierarchy: vSphere Tanzu supervisor cluster control plane nodes, pods, Tanzu Kubernetes clusters, image registry, content library, etc.
A vSphere Metro Storage Cluster and Metro Volume with witness architecture significantly enhances both availability and recoverability of Tanzu infrastructure. In the event of a planned or unplanned datacenter or storage outage, containerized workloads and the underlying Tanzu infrastructure components can seamlessly continue running at the remote site where compute, networking, and storage remain healthy and available for consumption. Likewise, NSX Manager and NSX Edge networking components on Metro Volume with witness can also take advantage of this deployment model by remaining highly available during an unplanned outage.
In one working example of this architecture, we ran HammerDB against a containerized SQL Server instance running inside a Tanzu Kubernetes Cluster. After causing an outage of a PowerStore appliance, the HammerDB workload showed continuous availability of the back-end database. With one PowerStore appliance removed (where the back-end database was originally running), the Tanzu Kubernetes Cluster and its workloads shifted seamlessly to the surviving datacenter and PowerStore appliance.
Note: The degree of seamlessness and high availability will be influenced by front-end storage presentation. Uniform will yield the best results while non-uniform will incorporate vSphere HA during the recovery along with measurable downtime.
Leveraging Metro Volume storage for Tanzu follows the same processes outlined earlier in the document for block storage. One or more Metro Volumes with witness are created and mapped in PowerStore Manager. In the vSphere Client, the Metro volumes are formatted as a VMFS datastore, tagged, and assigned a VM Storage Policy. From that point forward, the VM Storage Policy can be selected during or after Tanzu Workload Management enablement for control plane, ephemeral, and image cache storage. The same policy can be used for the Harbor image registry.
A Tanzu Kubernetes Cluster can be deployed on Metro Volume with witness storage by using a storage class which matches the VM Storage Policy that corresponds to Metro Volume storage. Example .yaml is shown below which will deploy a Tanzu Kubernetes Cluster with three control plane nodes and three worker nodes.
apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster #required parameter
metadata:
name: tkc-01 #cluster name, user defined
namespace: devops #supervisor namespace
spec:
topology:
controlPlane:
replicas: 3 #number of control plane nodes
vmClass: guaranteed-medium #vmclass for control plane nodes
storageClass: vk8s-mv-storage #storageclass for Metro Volume
tkr:
reference:
name: v1.23.8---vmware.3-tkg.1 #resolved kubernetes version
nodePools:
- name: worker-nodepool-a1
replicas: 3 #number of worker nodes
vmClass: guaranteed-large #vmclass for worker nodes
storageClass: vk8s-mv-storage #storageclass for Metro Volume
tkr:
reference:
name: v1.23.8---vmware.3-tkg.1 #resolved kubernetes version