As we know so far VMware vSAN is a distributed layer of software that runs natively as a part of the ESXi hypervisor. vSAN aggregates local or direct-attached capacity devices of a host cluster and creates a single storage pool shared across all hosts in the vSAN cluster. While supporting VMware features that require shared storage, such as HA, vMotion, and DRS, vSAN eliminates the need for external shared storage and simplifies storage configuration and virtual machine provisioning activities.
We will have a look on top things we should know about vSAN.
#10 – vSAN is Object Based Storage
vSAN stores and manages data in the form of flexible data containers called objects. An object is a logical volume that has its data and metadata distributed and accessed across the entire cluster. Virtual Machines deployed on a vsanDatastore may have 4 different kinds of storage objects associated with it:
- The Virtual Machine home or “namespace directory”
- A swap object (if the virtual machine is powered on)
- Virtual disks/VMDKs
- Delta-disks created for snapshots. Each delta-disk is an object.
Each object consists of one or more components. The number of components that make up an object depends primarily on a couple things: The size of the objects and the storage policy assigned to the object. The maximum size of a component is 255GB. If an object is larger than 255GB, it is split up into multiple components.
vSAN distributes components across the various hosts in the cluster and will always try to achieve an even distribution of components for balance, by meeting the availability and performance requirements.
Data on vsanDatastore are distributed based on VM Storage Policy.
For example we apply storage policy with RAID-1 (mirroring) vSAN create 2 mirror copies of the object and spread accross two hosts. If we apply RAID-5 erasure coding (Failures to Tolerate = 1) to an object. The object consists of four components—three data components and a parity component. These components are distributed across four hosts in the cluster. If disk or host containing any one of these components is offline, the data is still accessible. If one of these components is permanently lost, vSAN can rebuild the lost data or parity component from the other three surviving components.
#9 – vSAN can incur Device, Host, Rack and Site Failures
vSAN use FTT – Failures To Tolerate, by which you can specify how many failures you can tolerate for a single VM, how many copies of the data you will be create. If a host or a disk group or a disk fails, there’s still a copy left of the data.
FTT-1 with RAID-1 mirroring a minimum of three hosts is needed. (default policy).
- Erasure Coding
RAID-5/6 Erasure Coding is a space efficiency feature optimized for all flash configurations. Erasure coding provides the same levels of redundancy as mirroring, but with a reduced capacity requirement. In general, erasure coding is a method of taking data, breaking it into multiple pieces and spreading it across multiple devices, while adding parity data so it may be recreated in the event one of the pieces is corrupted or lost.
Overview of RAID-5
- Number of failure to Tolerate = 1
- Failure Tolerance Method = Capacity
- Uses x1.33 rather than x2 capacity when compared to RAID-1
- Requires a minimum of 4 hosts in the VSAN cluster
Overview of RAID-6
- Number of failure to Tolerate = 2
- Failure Tolerance Method = Capacity
- Uses x1.5 rather than x3 capacity when compared to RAID-1
- Requires a minimum of 6 hosts in the VSAN cluster
- Fault Domains / Rack Awareness
Fault domain usually refers to a group of servers, storage, and/or networking components that would be impacted collectively by an outage. A common example of this is a server rack. vSAN allows hosts to be grouped together into fault domains that act as one unit for the failures-to-tolerate policy calculation. Each host in a vSAN cluster is an implicit fault domain. vSAN automatically distributes components of a vSAN object across fault domains in a cluster based on the Number of Failures to Tolerate(FTT) rule in the assigned storage policy.
The failure of a disk or entire host can be tolerated. However, this
does not protect against the failure of larger fault domains such as an entire server rack. It is possible that multiple components that make up an object could reside in the same server rack. If there is a rack failure, the object would be offline. To mitigate this risk, place the servers in a vSAN cluster across server racks and configure a fault
domain for each rack in the vSAN UI. This instructs vSAN to distribute components across server racks to eliminate the risk of a rack failure taking multiple objects offline. This feature is commonly referred to as “Rack Awareness”
- Stretched Clusters
vSAN stretched clusters provide resiliency against the loss of an entire site. vSAN is integrated tightly with vSphere HA. If a site goes offline unexpectedly, vSphere HA will automatically restart the virtual machines affected by the outage at the other site with no data loss. The virtual machines will begin the restart process in a matter of seconds, which minimizes downtime. vSAN stretched clusters are also beneficial in planned downtime and disaster avoidance situations. Virtual machines at one site can be migrated to the other site with VMware vMotion. vSAN features the capability to create a stretched cluster across two sites. The two sites could be separate rooms at opposite ends of the same building, two buildings on the same campus, two campuses in separate cities, and so on. There are many possibilities.
Nearly all stretched cluster solutions need a RTT latency of 5 ms or less. Writes to both sites must be committed before the writes are acknowledged. RTT latencies higher than 5 ms introduce performance issues. vSAN is no exception. A 10Gbps network connection with 5 ms RTT latency or less is required between the preferred and secondary sites of a vSAN stretched cluster.
Up to 15 hosts per site are currently supported. In addition to the hosts at each site, a “witness” must be deployed to a third site. The witness is a VM appliance running ESXi that is configured specifically for use with a vSAN stretched cluster. Its purpose is to enable the cluster to achieve quorum when one of the two main data sites is offline.
vSAN Stretched Cluster is a solution which is usually implemented when there is a strong desire to be able to avoid a disaster or recover in an extremely fast way from a disaster, cost effective and you already leverage the tools you have in place.
#8 – Some features are not policy driven
- Deduplication and compression
Enabling deduplication and compression can reduce the amount of physical storage consumed by as much as 7x. Deduplication and compression is a single cluster-wide setting that is disabled by default and can be enabled using a simple drop-down menu. Nearline deduplication and compression per disk group level.
Deduplication and compression are implemented after writes are acknowledged in the vSAN cache tier to minimize impact to performance. The deduplication algorithm utilizes a 4K fixed block size and is performed within each disk group. In other words, redundant copies of a block within the same disk group are reduced to one copy, but redundant blocks across multiple disk groups are not deduplicated.
“Cold” data in the cache tier that is ready to be de-staged is moved to memory where it is deduplicated and compressed. It is then written to the capacity tier.
The compression algorithm is applied after deduplication has occurred just before the data is written to the capacity tier. vSAN will only store compressed data if a 4K block can be reduced to 2K or less. Otherwise, the block is written uncompressed to avoid the use of additional resources.
Deduplication and compression are only supported in all flash vSAN configurations.
- Data-at-rest encryption
Data-at-rest encryption is an option for vSAN datastores to further improve security and provide compliance with increasingly stringent regulatory requirements. vSAN datastore encryption uses an AES 256 cipher. vSAN encryption eliminates the extra cost, limitations, and complexity associated with purchasing and maintaining self-encrypting drives. vSAN datastore encryption is enabled and configured at the datastore level. In other words, every object on the vSAN datastore is encrypted when this feature is enabled. Data is encrypted when it is written to persistent media in the cache and capacity tiers of a vSAN datastore.
Initial configuration is done in the vCenter Server UI of the vSphere Web Client. The KMS cluster is added to vCenter Server and a trust relationship is established. The process for doing this varies depending on the KMS vendor, but it is usually quite simple.
Turning on encryption is a simple matter of clicking a checkbox. Encryption can be enabled when vSAN is turned on or after, with or without virtual machines residing on the datastore.
A rolling reformat is required when encryption is enabled.
Encryption keys are transferred to vSAN hosts using the Key Management Interoperability Protocol (KMIP). Hosts directly communicate with the KMS server. Because of this, VMware vCenter Server and PSC virtual machines can reside on the encrypted vSAN datastore.
Encryption can be disabled for a cluster. Like enabling encryption, a rolling disk format change is required. Disabling encryption can take a significant amount of time. vSAN Encryption is available for both All-Flash and Hybrid configurations and integrates with KMIP 1.1 compliant key management technologies.
vSAN Encryption is only available for vSAN datastores on hosts with vSAN 6.6. vSAN Encryption is not available for other versions of vSAN and not available for other datastores.
This article continues in next post with Part 2. To view it click here.