Lab 20
Lab 20
For this lab I learned how to use a vSphere DRS cluster.
First off I created a load imbalance. I had to play with the resource allocations and cpu load generator strength to get it to detect enough of a load unbalance. If the ESXi host is not stressed enough it doesn't seem to want to balance the load. Once that was all working, I got a DRS recommendation, then I applied the recommendation to balance the load.
Imbalanced load and migration automation settings:
Imbalanced CPU usage:
Recommendation:
Applying the recommendation:
02-1 and 02-2 machines now on different hosts. Load is balanced:
Next, I played with affinity rules. These rules allow you to make specific VMs stick together, or have VMs have a higher affinity with a specific host or resource pool.
In my case I created a VM-VM affinity rule which makes specific VMs stick together on the same host is possible.
Creating the rule:
DRS showing a recommendation because of the affinity rule:
Next I had to create an ANTI-affinity rule. This is the same as an affinity rule except it keeps VMs on SEPARATE hosts rather than on the same host. You might want to do this If you had VMs that used lots of resources and you wanted them always on different hosts so they didn't overload a host by being on the same host.
It was interesting, because the lab said to keep the affinity rule, but just have it not enabled, but my affinity rule conflicted with the anti-affinity rule regardless of whether it was enabled or not. This meant that I had to delete the affinity rule before the anti-affinity rule worked.
Anti-affinity rule:
Recommendation for the anti-affinity rule:
After that I created a VM-Host affinity rule. This rule tells the VMs what host they are allowed to run on. For this rule, I created a VM Group to put 2 VMs in. This means I can work with a single object rather than multiple VMs. This makes scaling much easier because you can group VMs for easier management. In the same way you can create a Host Group to create a group of hosts that a rule will apply to. Using these groups you could specify a group of VMs that is only allowed to run on a specific group of hosts in the cluster.
Also as I quickly discovered, you MUST have groups for a VM-Host affinity rule. It does not allow you to specify specific VMs or hosts, you must add them to groups first.
With a VM-Host rule, you can also specify whether the VMs MUST or SHOULD run on the host/s in the group. With MUST, the VMs cannot ever run on other hosts; with SHOULD, VMs PREFERABLY run on the specified hosts, but are allowed to run on other hosts if there is too much load imbalance.
Creating the VM Group:
Creating a Host Group:
VM-Host affinity rule:
Recommendation:
After setting up this rule, if you try to migrate a VM onto a host that violates this rule, it will warn you. After attempting a violating migration, I deleted the rule and continued onto the next lab.
First off I created a load imbalance. I had to play with the resource allocations and cpu load generator strength to get it to detect enough of a load unbalance. If the ESXi host is not stressed enough it doesn't seem to want to balance the load. Once that was all working, I got a DRS recommendation, then I applied the recommendation to balance the load.
Imbalanced load and migration automation settings:
Imbalanced CPU usage:
Recommendation:
Applying the recommendation:
02-1 and 02-2 machines now on different hosts. Load is balanced:
Next, I played with affinity rules. These rules allow you to make specific VMs stick together, or have VMs have a higher affinity with a specific host or resource pool.
In my case I created a VM-VM affinity rule which makes specific VMs stick together on the same host is possible.
Creating the rule:
DRS showing a recommendation because of the affinity rule:
Next I had to create an ANTI-affinity rule. This is the same as an affinity rule except it keeps VMs on SEPARATE hosts rather than on the same host. You might want to do this If you had VMs that used lots of resources and you wanted them always on different hosts so they didn't overload a host by being on the same host.
It was interesting, because the lab said to keep the affinity rule, but just have it not enabled, but my affinity rule conflicted with the anti-affinity rule regardless of whether it was enabled or not. This meant that I had to delete the affinity rule before the anti-affinity rule worked.
Anti-affinity rule:
Recommendation for the anti-affinity rule:
After that I created a VM-Host affinity rule. This rule tells the VMs what host they are allowed to run on. For this rule, I created a VM Group to put 2 VMs in. This means I can work with a single object rather than multiple VMs. This makes scaling much easier because you can group VMs for easier management. In the same way you can create a Host Group to create a group of hosts that a rule will apply to. Using these groups you could specify a group of VMs that is only allowed to run on a specific group of hosts in the cluster.
Also as I quickly discovered, you MUST have groups for a VM-Host affinity rule. It does not allow you to specify specific VMs or hosts, you must add them to groups first.
With a VM-Host rule, you can also specify whether the VMs MUST or SHOULD run on the host/s in the group. With MUST, the VMs cannot ever run on other hosts; with SHOULD, VMs PREFERABLY run on the specified hosts, but are allowed to run on other hosts if there is too much load imbalance.
Creating the VM Group:
Creating a Host Group:
VM-Host affinity rule:
Recommendation:
After setting up this rule, if you try to migrate a VM onto a host that violates this rule, it will warn you. After attempting a violating migration, I deleted the rule and continued onto the next lab.
Comments
Post a Comment