Most of the time when an organization first starts out with server virtualization, they might deploy a single host...
server or perhaps a single host cluster. Over time however, organizations often find that a single host cluster is inadequate. Virtualized workloads may be too demanding for a single cluster to accommodate, or there might be business requirements that demand workload isolation. Whatever the reason, it is becoming increasingly common for organizations to utilize multiple virtualization host clusters. Of course, this leads to the question of how best to manage an ever-growing virtualization infrastructure.
When it comes to managing a large collection of host servers or host clusters, the first thing that should be done is to adopt a centralized management solution that allows you to manage the entire virtualization infrastructure through a single console. Both VMware and Microsoft offer such products, and these tools go a long way toward making the management process easier.
Once a centralized management solution is in place, one of the best ways to keep your virtualization infrastructure organized is to group the host servers or host clusters in a logical manner.
In some ways, the host cluster can already be thought of as a logical grouping of hosts. After all, the virtual machines that are running within a host cluster typically have at least something in common with one another. Maybe the virtual machines all belong to the same Active Directory forest, or perhaps they perform similar tasks. In any case, there is a reason why you chose to run virtual servers within specific clusters.
This same concept can be applied to host groups. Although the implementation varies from one hypervisor vendor to the next, you can think of a host group as a high-level organizational structure. Clusters are a collection of host servers, which in turn run virtual machines. Host groups are usually a collection of clusters, but depending on the hypervisor, they can contain individual host servers in some situations.
Finding a topology that works
The trick to using virtualization host groups effectively is to develop a host group topology that mimics your business requirements. Let me give you a more concrete example.
My own infrastructure consists of two separate Hyper-V clusters, and a few VMware servers. One of my Hyper-V clusters runs virtual machines related to my production environment. The other Hyper-V cluster and my VMware servers make up my lab environment. If I were to be completely honest, host groups are probably unnecessary in such a small environment. Even so, I made the decision to create a "Production" host group and a "Lab" host group as a way of organizing my infrastructure.
The reason I did this is because my lab environment already extends beyond a single cluster (I have a Hyper-V cluster, and a few standalone VMware hosts). As such, the lab host group acts as a container for all of the resources that make up my lab environment. While it is true that the environment is small enough that I could easily manage it without a host group, I decided to make use of host groups because I expect my lab to grow in the future.
In my own organization, my host group's topology is based on business function (lab versus production). However, this is only one example of how to build an effective host group topology. It is also very common for organizations to base a host group structure on geographic location. For example, if an organization has offices in Miami, Seattle and San Francisco, they might create a separate host group for each office. In this type of situation, the host groups would contain the host servers or host clusters that physically reside in each location.
Although basing a host group structure on geographic location might initially seem to be the most logical approach, this technique might not always work. Some management platforms treat hypervisor clusters as a cohesive unit rather than dealing with cluster nodes on an individual basis. This means that if you have a host cluster that spans multiple geographic locations, it might not be feasible to group the individual cluster nodes by geographic location.
Another strategy that is worth considering involves taking a multi-tiered approach to host group topology. Depending upon the hypervisor you are using, it may be possible to create nested host groups. For instance, you might group hosts or host clusters based on geographic location, and then on function. Suppose, for example, that your organization had a satellite office in Tokyo. You might create a Tokyo host group, and then develop subgroups for the various business functions that are performed (file servers cluster, application servers cluster, etc.) in the Tokyo office.
There really isn't any right or wrong way to create a host group topology. The best approach is to base your host group structure on your business requirements. Although host group creation might initially seem like overkill for smaller organizations, taking some time to develop a logical collection of host groupings now can help to make management easier as the organization grows.