What is vSAN:
While vSphere ESXi pools the server resources together, the vSAN component of vSphere abstracts and pools the hypervisor storage.
Offers better performance, high availability , lowers costs and lot more….
Configurations of vSAN :
they are 2 ways balancing the caching and capacity requirements in the vSAN cluster.
- Hybrid disk group: Atleast 1 SSD for caching and 1 or more hard disk(magnetic) for capacity needs.
- All flash disk group: 1 SSD for caching and 1 or more flash(SSD) devices
- 3 ESX hosts are sufficient enough to build a vSAN cluster and can tolerate an ESX failure.
- local storage/disks is not mandatory for vSAN cluster. It can have ESX without local storage as well.
Using webclient a vSAN cluster can be created by enabling vSAN on it, and start configuring the disks.
Network requirements :
Hybrid disk group: 1GB
All flash disk group configuration: 10 GB
vSAN ESX host must have a vmkernel dedicated and configured to serve vSAN traffic which is usually among the vSAN hosts.
vSAN likes both vSS and vDS switches.
Ex: an ESX having its VM on a disk of other ESX host, the IOPS happen through the vSAN vmkernel port group.
Deduplication and compression features :
The data first enters Cache tier or disks while processing and slowly the unused data blocks will be moved over to capacity tier from cache when the data is infrequently used or becomes older. This ensures capacity tier is free enough to serve other IOPS.
The cache and capacity disks can be selected from the total available disks.
Once after completing the vSAN cluster configuration, you can actually notice under the tasks bar, all the disks being configured to vSAN cluster.
vSAN datastore :
A vsan datastore appears immediately after creation of vSAN cluster. You can find the capacity of the vSAN datastore under its ‘configuration’ tab, which is actually the aggregate of each ESXi capacity in the cluster after excluding vSAN overhead+Deduplication metadata.
vSAN capacity = aggregate ESX capcity-(vSAN overhead[1% of physical capacity]+Deduplication metadata[variable])
Storage Provider :
Storage Management Service(SMS) from vCenter automatically creates a storage provider on each host to ensure the communication between the storage layer and the vCenter.
Thought is is automatic, ensure that one host has the storage provider enabled and in active status, while the storage providers on other hosts are in standby mode.
In case the active storage provider fails, the standby one takes over.
Add more nodes to vSAN cluster: Just get the host in MM and drag, drop into vSAN cluster.
vSAN configuration assist: This is the place to check vSAN health status. Click on the ‘Retest’ to know the health each time, and start fixing the warnings, errors.
You can configure HA/DRS as well from the Configuration assistant.
vSAN provides RAID 1, RAID 5 and RAID 6 configurations to facilitate VM protection levels or fault tolerance level. RAID 5 requires a minimum of 4 ESX nodes while 6 nodes are needed by RAID 6 configuration.
vSAN facilitates protection levels on VM’s based on their priority.RAID 5 and RAID 6 configurations require less additional capacity while protection level is chosen for a VM, than RAID 1.
Ex: VM without protection level = uses normal VMDK size
VM with protection level(1) on RAID 5 or RAID 6 with protection level(2) = 1.33 *Actual VMDK size
VM with protection level(1) on RAID 1 = 2 *Actual VMDK size
How do you decide RAID 1 or RAID 5/6 on VM’s?
It’s based on 2 factors. Performance and capacity.
You need performance then RAID 1 is ideal and if you’re bothered about the capacity not the performance then either RAID 5 or RAID 6 are best options.
Storage Policies :
Number of disk stripes per object: More stripes across the capacity disks, the more redundancy on VM’s.
Flash read cache reservation: Flash capacity is reserved for VM’s and will be specified as percentage of logical size of VMDK.
Primary level of failures to tolerate: To tolerate n failures = n+1 copies of VM and 2*n+1 ESX nodes contributing storage to vSAN
Force provisioning : Ignores object storage policies
Object space reservation: % of logical space needed for VM
Object checksum: Checks every time if the copy is same as original object(VM) and corrects of not.
Failure tolerance method: Either performance or capacity.
IOPS limit for objects: Controls IOPS on disk
Storage policies can be created based on the above factors and select them while provisioning a VM.
vSAN VM Swap Object configurations:
By default the protection level for Swap object will be 1, because protection or redundancy is when a ESX server fails, it needs data. However in this situation while HA restarts the VM, the swap objects gets created automatically, once VM is powered on from a different ESX. Hence redundancy is not required for swap object.
Still there are 2 ways setting swap.
Thin method consumes more space while thick consumes very less.
As you all know, this is nothing but the way storage is connected to ESX servers i.e. through Ethernet cables.
Active-Active: LUN’s becomes accessible on all ports, paths unless a path fails
Active-Passive : Out of 2 or more Storage Processors, only one will be active while other is in standby
Asymmetrical storage system(ALUA): This is a kind of intelligent method. Host uses some paths as primary while others becomes secondary.
Virtual port storage system : Storage will be accessible through one single Virtual Port.
Now, its time to create iSCSI on vSAN, enable it and configure target, followed by that iSCSI initiator groups have to be created.
vSAN also allows data Encryption feature and this happens after all the process like deduplication and compression to ensure the data is secure and safe. This is also called data-at-rest encryption, because encryption happens both on cache and capacity disks only after all process like dedupliccation and compression, meaning the data is at rest.
This configuration requires an external Key Mangement Server(KMS), vCenter server and ESX hosts
vCenter server is responsible for requesting the KMS for a key while configuring the Encryption on vSAN cluster. Then, the KMS server generated and stores the keys on it. Now the vCenter pick them up and distributes them to ESX hosts.
One thing is that the vCenter does not store any keys on it, indeed it maintains the key ID’s assigned to hosts.
Since the KMS cluster provides encryption to vSAN datastore, we must set up the KMS cluster to support encryption. Then we need to establish a trust connection between KMS server and vCenter server.
it comes to enabling the vSAN data encryption is happens at a glance and more over it is a seamless feature similar to other vSPhere features like HA, DRS.
The vSAN cluster encrypts the data including the virtual machine files and VMDK, as soon as it is enabled. Only the administrators with encryption privileges can perform Encryption and decryption tasks.
The total process of encryption follow this manner>>
- vCenter requests for Key Encryption Key(KEK) from KMS server and upon reception, it just stores the ID of the key but not the key itself.
- The key will be assigned to ESX hosts and there happens disk level encryption on ESXi using a random Data Encryption Key.
- Similarly each host in vSAM uses the KEK key from vCenter to generate DEK , stores them on each disks. Indeed the host does not store KEK, it is the vCenter that stores it.
- When a host reboots, it does not mount the datastores unless it receives the KEK from vCenter, which could take couple of minute or even more at times.
- The Coredumps will also be encrypted using host key and to de-crypt them you require the password.
Important points to note regarding Encryption:
- You cannot configure KMS server on the same vSAN cluster
- Encryption is CPU intensive job
- The vSAN wintness host does not participate in Encryption
- It encrypts the coredumps as well because they contain sensitive information, Coredump can contain Key for ESX hosts and the data on them.
- Better always use a password while generating vm-support bundle.
Setting up Domain of trust
The first step during encryption is setting up the domain trust among KMS server, vCenter and vSAN nodes using Public Key Infrastructure (PKI) method.
The communication begins once the trust is established. Key will be exchanged between vSAN hosts and KMS server. The vSAN host requests KMS for key showing the Key ID it has got from vCenter and KMS in return provides the key to hosts.
vSAN Health check allows us to ensure the communication among hosts and KMS server is functioning well.
2-node stretched cluster configuration:
This is mostly useful in remote office branches to save costs.
Preferred domain/preferred site, read locality,
You can follow below links for more information.