vSphere Distributed Switch Design & Configuration - Part II: Create & Manage dvportgroup

The second chapter has been published. I hope it can be useful for you all :)

vSphere HA vs vCenter HA

 

Many times I heard my students ask what is the VCHA really and what is different between this feature and vSphere HA?

vSphere HA is a cluster-level feature that can be enabled to increase total availability of VMs inside the cluster and works whenever an ESXi host has been crashed, then HA will move VMs of that failed host to another available resources inside the cluster and reboot them in the new hosts. HA interacts directly to the ESXi HA Agent and will monitor status of each host of a cluster by investigate their heartbeats, So if an network segmentation / partitioning/ downtime is happened and also ESXi cannot provide its heartbeat to the shared datastore, HA will consider the host is failed and execute VM migration operation.

But vCenter HA is a new feature published after release of vSphere6.5 and directly related to the vCenter Server Appliance. It will create a cluster-state of VCSA VM in a triple-node structure: Active node (Primary vCenter server), Passive (Secondary vCenter acting after disaster) and Witness (act as a quorum). It's just about the VCSA availability factor only. vCenter HA is a new vCenter feature that is enabled only for VCSA (Because of PostgreSQL native replication mechanism), also can provide more availability for this mission-critical service inside the virtualization infrastructure.

As VMware said whenever VCHA is enabled, in case of vCenter failure, operation will be revived after 2~4 minutes depends on vCenter config and inventory size. Also VCHA activation process can be done less than 10 minutes.

Now I want to compare these two feature with respect to each related concept of IT infrastructure:

1. Network Complexity:

vCenter HA configuration needs a dedicated network to work and is totally separated from vCenter management network, Then to run VCHA cluster successfully it's required to have only three static IP or dedicated FQDN for assigning to each of cluster node. (I always prefer to choose a /29 subnet for them) After Active node failure, Passive will be automatically handle the vCenter management traffic and users just need to re-login their connections to the vCenter (VPXD through API or Web Client).

But a good vSphere HA operation is highly depends on cluster settings, so you don't need to do more network configuration especially for HA operation. (Just maybe in some situations you may need to separate host management and vMotion port groups based on network throughput)

2. Network Isolation:

In situation where there is a partitioning between hosts of a cluster, if a host cannot send any heartbeat to the shared datastore, it will be considered as a failed host. So HA tries to migrate and reboot all running VMs of that Host to another healthy hosts. I want to emphasis respect to availability of VMs belong to the host cluster there is two mechanisms of checking failures: network connections (between hosts and vCenter) and storage communication (inside the SAN area).

But if there is a network segmentation between vCenter HA nodes, we must care about what's really going on? I mean separation is happened between which nodes of the cluster? If Active-Passive or even Active-Witness nodes are  connected no need to worry, because the active node is still responsible of VI management operation. But what happened if active node is the isolated node?! Operationally it will get out of the VCHA cluster and stop to servicing, now the passive node will continue its job.

3. Multiple failures:

In the case of consecutive failures, if there is enough resources (RAM & CPU) inside the cluster, it can handle this problem, because vSphere HA will migrate VMs more and more to another available ESXi hosts. Just remember you must check out the Admission Control Policy settings respect to handle multiple ESXi failure.

But in vCenter HA, you should know about VCHA is not designed for multiple failures, So after the second failure, the VCHA cluster is not available and functional anymore.

4. Utilization, Performance and Overhead:

There is a little overhead for primary vCenter when VCHA is enabled, especially every time there is too many tasks to do for vCenter Server.

Witness needs the lowest CPU, because there is only VCHA service. Also it's almostly same for Passive node just for VCHA and PostgreSQL. There is no concern for memory usage.

But if you want HA works in its best mode you must pay attention to remaining resources in the cluster because bad HA configuration can make the cluster unstable, So for best performance in whole cluster you need to calculate availability rate based on remained and used physical resource. Specifying at lease two dedicated failover ESXi hosts to encounter against failure can be a suitable HA config.

Virtual Machine Snapshot Details Investigation - Part 1

What really is a Snapshot? Let's break into the more details. A Virtual Machine Snapshot is a technology that is executed to save a specific state of that VM by purpose of preserving VM's data, power state of VM and also its virtual memory. You can generate many snapshots to keep different states of your VM and is required for VM Backup procedure and is a great ability in test / pilot scenarios. So you can revert to any snapshot state if you need by Snapshot Manager. Then should be remembered very change is this duration (from snapshot to recent moment) will be discarded.
 But what have been affected whenever we create a new snapshot and what are the Pros and Cons of this feature? In this post I want to describe more detail about virtual machine snapshot feature inside the vSphere environments…
As a detail view snapshot exactly is a replica copy of VMDK in a specific moment. So it can be used for recovering a system from a failure state. All the Backup solutions work with snapshot every time they start a VM backup task to provide a copy of that. So as I said before snapshot generation provide a copy from these component’s contents:
1.    VM Settings (Hardware settings or any changes to the VM itself)
2.    VMDK state (Data has been write inside the VM Guest OS)
3.    VMEM Content (Virtual Memory like clipboard or swap contents)

So must be careful of using revert action because it will return all of this objects to the snapshot state. During snapshot generation it will create a delta file with .vmdk extension (also called redo logs or delta links) that acts like a child for its parent .vmdk (main VMDK before snapshot creation). So guess OS cannot do write operation on parent vmdk anymore and after that any disk writes action will be happened into the delta/child disks. First of all, child disk will be created from its parent and then the other successive children snapshots will be created from latest delta.vmdk in this chain. As its name shows, delta means difference between current state of the VM disk and last snapshot creation moment. Now any change in VM (and its Guest OS) will be writing to this new VMDK (delta file) from this moment. So we can say they are important as their parent.

But what is the exact content of snapshot files? And where data has been written after taking snapshots? Consider A as the primary VMDK of virtual machine when there is no snapshots. B series (B1, B2) are children of A and also C files (C1, C2) are descendant of B. If you are after C2 snapshot, content data after reverting to C1 state is included base VMDK  (or flat file) and previous delta files: A+B1+B2+C1. Flat.vmdk is raw data structure of base file but it’s not a separate file when you check it into the datastore.

Into the Virtual Machine File System (VMFS), delta disk act as a sparse disk and it’s required to know about how data will store in virtual disks. There is a mechanism called COW (copy-on-write) for optimization of storage spaces. It means there is nothing into the VMDK until data copy occurs. I will explain more about COW mechanism and sparse disks more deeply in another post.
Now when you create many snapshots and cause complexity in the parent/child relations between snapshots, you may need to execute consolidation to reduce this confusing situation. It will merge these redo logs/delta vmdk inside a single vmdk to avoid complex status of snapshot managing. If the child disks are large in size, the consolidation operation may take more time.
There is also some another files related to the snapshot operation:
VMSN: It is a container for memory contents of VM. As VMware said if the snapshot includes the memory option, the ESXi host writes the memory of the virtual machine to disk. The VM is stunned during memory is being written but sadly you cannot pre-calculate time duration of that because it’s dependent on many factors such as disk performance and size of memory.
Remember VMSN always will be generated even if you don’t select memory option in snapshot creation. But its size is much lesser in non-memory state. So VMSN size is an overhead for total space calculation of snapshot generation in the datastore.
VMSD: It is the snapshot database and is the primary source for snapshot manager usage and its contents are relation tree of snapshots. So snapshot.vmsd consists of current config and active state of virtual machine.

This is a sample of VMSD file:
 " .encoding = "UTF-8"
snapshot.lastUID = "1"
snapshot.current = "1"
snapshot0.uid = "1"
snapshot0.filename = "vm-Snapshot1.vmsn"
snapshot0.displayName = "Clean"
snapshot0.createTimeHigh = "360682"
snapshot0.createTimeLow = "2032299104"
snapshot0.numDisks = "1"
snapshot0.disk0.fileName = "vm.vmdk"
snapshot0.disk0.node = "scsi0:0"
snapshot.numSnapshots = "1"a  "

I will talk about snapshot quiescing option and some more detail in the next part as soon as possible. For more information you can refer to following links:

Understanding VM snapshots in ESXi/ESX

Managing Snapshots vSphere 6.7