Firstly, why should I encrypt my data? Should you even care? Well I think you should. I believe security should be top of mind across all that we do in IT, and with data being our biggest asset, we should treat it with due care.
With vSAN gaining massive adoption across customer IT estates, and for good reason, I thought it might be beneficial to comment on vSAN encryption and Stretched Clusters.
Encryption is a mechanism which protects data by converting it into an unreadable format using an encryption code (encryption key). To decrypt the data, you need the decryption key to convert the data back to a readable format. By doing that, encryption will provide a safe mechanism to store or transport your data across your environment. Without the correct mechanism and the decryption key, data is unreadable and therefore completely valueless.
There are a couple of options by VMware to encrypt your VMs, namely:
- VMcrypt (which is done on a per VM level and does not require vSAN)
- vSAN encryption (which is done on a datastore level, encrypts all the files within that datastore and does require vSAN)
Both encryption technologies provide the ability to protect data-at-rest (as long as the data is stored on persistent storage) with the major difference being VMcrypt actually encrypting the data at the hypervisor level before it makes it way to the backend storage. vSAN will send the data unencrypted across hosts and will be encrypted only when its written in the cache (SSD) or persistent disk (HDD). As the hosts would generally be kept in a secure environment, this unencrypted data-in-motion argument would usually be negligible.
The below table from a VMware KB article provides a comparison between vSAN and VMcrypt features and functionality.
vSAN encryption works in conjunction with compression, deduplication, erasure coding and stretched clusters, keeping the files encrypted during all vSAN operations. Common vSphere features like vMotion, DRS and High Availability (HA) are also compatible with vSAN encryption.
Another huge benefit is that vSAN encryption is hardware-agnostic, which makes it capable of using any solid-state drive (SSD) or hard disk drive devices (HDD) included in the VMware Hardware Compatibility Guide (HCG) for vSAN. You don't need to acquire self-encrypting drives (SEDs) which can be up to 30% more expensive than standard drives.
While the process to enable vSAN encryption is simple, the main component that needs architecture and design consideration is the Key Management Server (KMS), as this becomes a critical component to ensuring the encryption and decryption of data from the vSAN datastore is available. Encryption can be enabled on new clusters or on existing clusters, the only requirement is the Key Management Server (KMS) is provisioned and available, which will be necessary to provide the keys that you can use to encrypt the vSAN datastore. A complete list of supported KMS servers can be found here.
vSAN Stretched Cluster
While vSAN Encryption helps protect the environment against data theft, there is another feature I want to talk about that provides resiliency and availability for your data in the event of an entire site being lost – Stretched Clustering. To achieve resiliency and availability, a stretched cluster architecture extends the vSAN environment from a single site to two sites. While the implementation of stretched clustering is reasonably straight forward, there are a lot of considerations and design decisions to be made prior to implementation. From a business perspective, this platform architecture can help drive higher uptime and resiliency for business-critical applications, so we feel this is important to consider to provide value back to the business.
While the main purpose of a stretched cluster is to provide high availability, it does open the door for being able to non-disruptively evacuate workloads from an entire site, allowing for planned maintenance to occur on other infrastructure or the physical site itself with no impact to the workloads. In the event of a site failure (no matter which site), vSphere HA will be able to restart any VM using the data stored in the other site.
The RPO (Recovery Point Object) in the Stretched cluster is zero and the data must be committed on both sites to have the write operation completed and acknowledged back to the application. A maximum of 5 ms RTT (Round Trip delay Time) between the two main sites must be respected to avoid high latency on write operations.
Implementing the stretched cluster is also a fairly simple task. I will quickly describe only two of them below, but I'd recommend you have a look, or talk to us, on all requirements, especially networking considerations.
1. Witness host
The witness host is responsible for the decision of which host owns the VMs in a split-brain scenario.
There are two possible ways to deploy the witness, physical or virtual. In both cases consider keeping the witness in a third location to avoid the witness being unavailable in a site disconnection scenario.
2. Fault Domain configuration
Fault domains are used to define the protected sites. You can create a “group of hosts” inside the same vSAN cluster to define where the VMs data will be stored and where a “copy” of the data will be stored. There are three types of fault domains: the preferred site, the secondary site, and a witness host, where each fault domain represents a separate site.
To summarise, vSAN is a powerful tool which offers a Hyper Converged Infrastructure by natively including security in different levels to match different business requirements.
VMware vSAN can natively implement data-at-rest protection with encryption, requiring no additional hardware cost, whilst protecting your environment in a synchronous way, against a cluster node, or even site failure. There are plenty of reasons to review VMware HCI, which is key for delivering a Software Defined environment.
If you are thinking about how you can achieve a Software Defined platform. We are leaders in this space, so just shout out. I’m confident we can save you time, money and pain. Could even have a witness jump on a call/meeting. Bad IT vSAN humour ?.