Managing a vSphere environment is not about making use of the technology by itself, in fact, it's leveraging this technology to fulfill business needs what it really matters. Often vSphere Administrators utilize DRS affinity rules to control virtual machines placement specifying a group of hosts which might fulfill those needs, reasons vary from license constraints, specific hardware needs, increase availability etc.
With the advent of vSphere Integrated Containers, VIC, developers can instantiate their own containers, container-vms to be more precise, without the interference of a vSphere Admin, while it increases the agility of the business it also places a new challenge; as containers-vms come and go as need how admins can keep their affinity rules updated in order to fulfill the business need ??? For sure a manual intervention is not up for debate.
Luckily VIC 1.4 brought a new functionality, host affinity. When enabled, there will be a DRS VM Group for each Virtual Container Host, VCH, and as containers are created or deleted this group will be updated accordingly, helping administrators and developers life to adhere to those business need automatically.
During the creation of a VCH, you enable host affinity just specifying "--affinity-vm-group" option on the vic-machine command line (not yet available on VCH wizard).
A new DRS VM Group will be created with the same name of the VCH, you will also notice VCH VM is part of this group, it's made that way because it's impossible to create an empty VM Group, while an empty group can exist as a result of removing all VMs from it.
But what about new existing VCHs ??? Starting with VIC 1.4.1 you can reconfigure them enabling host affinity as well. After creating the VCH, vSphere Administrators just need to create a VM-Host Affinity rule that matches this newly created VM Group and a Host Group, before handling the VCH for the developers.
So every time a developer creates or deletes containers on the VCH, the VM group membership will be updated accordingly and DRS will take care of the scheduling container-vm based on the rule create before automatically. Enabling higher agility and improving operational efficiency while keeping the business need into account.
If you are still not sure why would you use this feature, I'd like to expose a few use cases; On a hypothetical scenario of a single vSphere cluster made of 10 hosts distributed on 2 physical racks you may have;
*** Licensing needs *** Let's imagine you have an application that is licensed per physical host or processor, to decrease your license cost you might create a host group containing just the hosts you have this application license for and match this group with an affinity rule for the VCH VM Group, this way you don't need to license your entire cluster;
*** Specific Hardware needs *** Now if your container benefits from a graphical intensive processor, GPU, you can create a host group containing those hosts and match this group with the VCH VM Group, now those intensive containers will always be scheduled on the right host;
*** Fault Domains *** Increasing your fault domain is always a plus when it comes to availability. You can use a Host Group to create a kind of virtual cluster inside your vSphere cluster where the members of this host are spread among the racks. While you cannot guarantee your application will always be spread evenly between racks, HA will restart your container-vms on the remaining hosts in case of rack failure.
But, if you wanna make sure your application will always be spread evenly between racks you can create two VCHs, where each one will have an affinity rule to a Host Group based on hosts of a single rack. Like VCH01 will use hosts from rack-A and VCH02 will use hosts from rack-B, now you can control the placement of your containers assuring that your application will always be available in case of a rack failure.
As you can see there's so many use cases for this feature but even more important is to support the agility you need while still aligned with your business need.
Do you have a different use case for this feature ? let us know... via Latest imported feed items on VMware Blogs https://ift.tt/2urm50E |
Comments
Post a Comment