Greater Flexibility and Security with VMware vSAN Storage Clusters in VCF 9.1

For the past several years, mounting the remote datastore of a vSAN cluster has grown into an important capability for Administrators. Initially it was used to borrow storage resources between vSAN HCI clusters, but since the introduction of vSAN storage clusters, where centralized shared storage is provided by vSAN, mounting remote vSAN datastores is now commonplace in VCF environments.

vSAN in VCF 9.1 expands its ability to mount remote datastores in important ways. Let’s take a look at how these improvements provide greater flexibility and security in your VCF environment.

Mixed Mode Support for Remote vSAN Datastores

In previous versions, older vSAN clusters running the Original Storage Architecture (OSA) could not mount a datastore of a cluster running the vSAN Express Storage Architecture (ESA). vSphere clusters also could not mount these different architectures concurrently.

In VCF 9.1, vSAN removes this mutual exclusivity. vSAN and vSphere clusters can now mount remote vSAN datastores regardless of which vSAN architecture is used. Now, environments can easily support the following:

• Mounting OSA clusters to both ESA and OSA clusters concurrently.
• Mounting ESA clusters to OSA and ESA clusters concurrently
• Mounting vSAN compute clusters (aka vSphere clusters) to OSA and ESA clusters concurrently.

Figure 1. Mixed mode support for remote vSAN datastores

This enhancement gives our customers many more options in how to navigate some of the challenging hardware shortages and market pricing.

• Repurpose OSA clusters to extend their life. Your older clusters running vSAN OSA may not be able to keep up with your performance requirements, but they could still be suitable as vSphere clusters that use a vSAN storage cluster for centralized shared storage. You might even be able to repurpose one of the NVMe devices on the old OSA cluster for the purpose of memory tiering on those repurposed clusters.
• Improve migration efforts. Support of connectivity to both cluster architectures can ease the effort to migrate from older clusters running vSAN OSA to newer clusters running vSAN ESA.
• Independent scaling. The improved connectivity options will help you with precise purchasing for whatever resources are needed in your environment most. This is one of the benefits many of our customers using vSAN storage clusters have shared, and the improved connectivity options improves this even further.

vSAN HCI to vSAN HCI Migrations

This type of migration is now trivial. On an existing vSAN OSA cluster, one could mount a remote datastore running vSAN ESA, and simply vMotion the workloads as desired. When the VM instances and their storage is migrated over, simply unmount the remote datastore and begin the decommissioning process.

Migrating to a Disaggregated Model using vSAN Storage Clusters

This type of migration allows for customers using older clusters running vSAN OSA to a disaggregated model where a vSAN storage cluster is providing the centralized shared storage, and vSphere clusters will be providing compute resources for the VM instances.

1. Ensure your new vSphere compute clusters are mounting the new ESA-based storage cluster.
2. Mount the legacy OSA cluster to those same compute clusters.
3. Use Storage vMotion to move the data from the OSA hardware to the ESA storage cluster.
4. vMotion the VM instances from the old hosts to the new compute-only hosts.

Remember that the mounting of remote datastores can occur within and across different vCenter Servers instances. So these types of transitions between VCF workload domains become easy.

Support for Data-in-Transit Encryption for Remote vSAN Datastores

When mounting remote vSAN datastores, previous versions of vSAN HCI clusters and vSAN storage clusters could encrypt the data residing on the datastore using vSAN’s native Data-at-Rest Encryption, but were unable to support the use of vSAN Data-in-Transit Encryption from the vSphere cluster mounting to the remote datastore to ensure storage traffic between the client cluster and the server cluster was fully encrypted.

vSAN in VCF 9.1 can now provide end-to-end encryption of vSAN storage across these disaggregated topologies. This will encrypt the storage traffic between the clusters that mount the datastore and the server cluster that provides the datastore resources. This has been a highly requested capability from many of our customers in the financial and health care industries.

vSAN Data-in-Transit Encryption is particularly easy to deploy, as it is an option provided at the time of mounting a remote datastore. As shown below, this toggle is completely independent from the data services on the server cluster, and as with other scenarios where vSAN Data-in-Transit is enabled, key management is all handled transparently.

Figure 2. Support of Data-in-Transit Encryption for remote datastores.

For customers interested in providing end-to-end encrypted storage using vSAN storage clusters, vSAN encryption services could be configured in one of two ways.

• Option 1: Enable Data-at-Rest encryption & Data-in-Transit encryption on the vSAN storage cluster, and enable Data-in-Transit encryption on the client cluster mounting the datastore. This will offer end-to-end encryption, and guarantees every packet transmitted within the storage network has its own unique hash. This may have some impact on storage performance for the backing storage cluster.
• Option 2: Enable only Data-at-Rest encryption on the vSAN storage cluster, and enable Data-in-Transit encryption only on the client cluster mounting the datastore. This will offer end-to-end encryption. When ESA encrypts data for Data-at-Rest encryption, it performs encryption high in the stack (DOM), but it will not necessarily use a unique hash for identically replicated traffic (a mirrored write for example). The data transmitted within the storage cluster would in fact be encrypted, just not at the level to guarantee unique hashes across the network for mirrored writes. Unless a customer is under the strictest regulatory requirements, this configuration may be good enough, and would eliminate the potential performance penalty on the east-west traffic within the storage cluster.

For more information and considerations when using vSAN encryption capabilities in your VCF environment, see the “vSAN Encryption Services” document, while design and operational guidance specific to vSAN storage clusters can be found at: “Design and Operational Guidance for vSAN Storage Clusters.” Do you have more questions on vSAN? Check out the extensive list of frequently asked questions on the vSAN FAQs document.

Summary

Expanding the scenarios that vSAN datastores can be mounted remotely, paired with the ability to cryptographically secure those connections shows that the pace of innovation in vSAN continues at a staggering rate. While they are terrific features on their own that help day-to-day operations, their true benefit may come from their ability to let you adopt new capabilities faster, and more easily.

@vmpete