How DRS and Vmotion Works in Vcenter
What is Storage Vmotion and how Storage vmotion works
What is Storage Vmotion and how Storage vmotion works
->As we know DRS vmotion is the feature of Vcenter and it works when we have installed and configured VCSA (Vcente Server Appliances) with Esxi Host.
->DRS (distributed resource scheduler) is a feature of Vcenter which provide ability to move the VMs (Virtual Machine) from one Esxi host to Another Esxi host without any downtime or with zero downtime,but actually there will be some down time of 15-20 second ,which is negligible as end users will not notice any downtime.
->DRS provide the ability to move the VM from one host to another host in different way like if we have schedule to move the VMs automatically then in case of Esxi host failure it will automatically move the VMs to another host and if we have configured manually action then it will not move the VMs and it will ask us to do it manually.
How DRS works
->DRS uses the Vmotion feature to move the VMs from one Esxi Host to another Esxi Host without any downtime.
Host Requirement
->DRS require shared storage -which should be accessible by both the Host.
->DRS require Kernal port group to be configured and added to move the VMs between Hosts.
->CPUs in both ESXi hosts must be compatible. CPUs need to be from the same vendor (AMD or Intel, for example), CPU family, and must support the same features. Note that some features CPU features can be hidden by using compatibility masks.
VM Requirement
-> VM should not be connected to an internal standard switch.
-> VM should not be connected to any device physically available to only one ESXi host, such as disk storage, CD/DVD drives, floppy drives, and serial ports.
-> VM should not have a CPU affinity rule configured.
-> VM must have all disk, configuration, log, and NVRAM files stored on a shared data-store accessible from both ESXi hosts.
-> VM uses RDM, the another ESXi host should be able to access it.
How Vmotion works
->Once we are compliance with pre-requisite of Vmotion then Vmotion checks the availability of CPU and memory to use after moving the Vms.
->Vmotion will prepare quiesce to move the VMs- It will prepare the memory status of VM ,which is going to move to another host.
->once memory status is prepared then Vmotion will start transferring the VM memory status from one host to another Host.
->VM memory status will get transferred part by part to another host-VM.
->Once monory status has been transferred to another host and Vmotion ensure there is no new changes are made to VM.
->now Vmotion will check and match the memory status of source and destination Esxi and make sure all the files has been transfered correctly.
->then it will unregister the VM on current host and it will register the VM on anther host.
->while unregister and registering VM will have some down time or ping failure for 10-15 sec but it will not get noticed.
->After that it will Free up the resource utilization on source Esxi.
What is Storage Vmotion and how Storage Vmotion works
What is storage vmotion.
->Storgae vmotion is use to move the VM files from one datastore to another datastore with zero downtime, If we have requirement to move the VM files (like VMDK,vmx,vmsn,vmss ) from one datastore to another datastore without any downtime then we have Vcenter feature which will move the VM files from one datastore to another.
-> When we want to migrate datastore from one storage disk to another storage disk then we use this feature to move VM files.
->If we want to move VM files to high I/O storage then we can use storage vmotion.
How Storage Vmotion works.
-> 1st it will start with copying the vmware files(config, log, swap, snapshots) to the destination Datastore.
->A Shadow VM will get powered on using the copied Vmware files. The shadow VM will wait until VMDK files gets fully copied.
->All the changes made to VM disk files used to get tracked to the destination datastore using "change block tracking" ,so that it should not miss any changed files.
-> svMotion repeats this process of copying the changed blocks from the source Datastore to the destination Datastore util the changed blocks is small enough.
->When the amount of outstanding changed blocks is small enough, svMotion invokes a Fast Suspend and Resume (FSR) of the VM (similar to vMotion) to transfer the running VM over to the idling shadow VM. as regular vMotion works same way, this transfer will happen so quickly and VM files will get moved to another datastore without any downtime and that it will be completely transparent to the VM.
->After the FSR completes vM files transfer then VM disk files are deleted from the source Datastore.
Do we need to backup VM prior to using svMotion.-> No, Storage vmotion is safe and reliable. Where vMotion transfers memory, svMotion transfer storage. They employ the same FSR logic to transfer control of the running VM. If it get failed then source VM will be always safe.
Do we check for adequate free disk space on the destination Datastore before beginning Storage vMotion.
->Yes, checks are made before we initiate the svMotion to ensure that adequate disk space is available on the destination DS. If there is not enough space, the svMotion request fails with no impact to the running VM.
What happens to the VM if you run out of storage on the destination DS.
-> If an out-of-space condition is hit svMotion will clean up the destination DS and the VM will continue to run on the source.
What happens if the iterative coping of the changed blocks fails (i.e the VM is very write intensive).
->If the VM is generating disk I/O faster than svMotion can copy, the svMotion will eventually fail leaving the VM running on the source.
Does all the svMotion traffic get copied over the vMotion network.
->No, a DataMover (DM) module built into the VMkernel, which is optimized for transferring large disk files, is used to copy the disk data. The swap files are also copied using the DM.
What is the threshold when the number of outstanding changed blocks is small enough to proceed with stunning the VM and switching to the destination DS
->It depends on the disk copy throughput. svMotion continuously monitors the copy throughput during each copy iteration, when it detects that the time needed to copy the outstanding dirty blocks is less than the target downtime (default 5 secs), it proceeds with the switch over. Note that the 5 seconds is only the time to copy the remaining disk blocks, it does not include the FSR time.
No comments:
Post a Comment