James Thew - Fotolia
Cloud computing is built on a number of software components and because integration is often an expensive, risky and time-consuming process, planners and architects often opt for integrated packages. One critical element in a cloud stack is the hypervisor and sometimes the "stack option" for hypervisor support can be suboptimal. To validate your own package's choice, understand the three hypervisor relationship dimensions, check the cloud software option against application needs and verify the hardware-linked feature directions carefully.
In both cloud computing and virtualization, the hypervisor divides a physical server into virtual pieces that can be allocated to applications independently. Hypervisors have three distinct relationships: with the hardware platform, with the host OS and with the guest OS. Not all address these three connections the same way, and it's those connecting dimensions you'll need to verify in your own cloud application to be sure your cloud software choice of hypervisor is optimum.
Understanding the three hypervisor types
The first question to ask about the hypervisor dimensions is the relationship the hypervisor creates among the three connected elements. There are three basic models supported: the ships-in-the-night hard virtualization model (the "Type 1" hypervisor), the OS-integrated model ("Type 2") and the container model (like Docker).
Type 1 virtualization creates a framework where the virtual machines are very much isolated from the hardware and there is no host OS. This isolation is most valuable if your cloud application requires a number of different guest OS configurations and if applications have to be stringently separated for security, compliance or multi-tenancy reasons. If your cloud software stack uses a hypervisor without the isolation and flexibility you need in guest OS terms, find another.
Type 2 virtualization is a marriage of hypervisor features with the host OS. This close relationship is helpful if the host and guest OS will be the same, which means that your cloud stack is supporting applications that all (or at least nearly all) run under the same OS. The isolation of applications offered by Type 2 hypervisors is less; applications could affect each other's performance, but the resource efficiency and operations are easier to manage. Most users are less concerned about tenant isolation than public cloud providers. Check performance of your apps carefully here, and be aware that you may not have access to all the hardware and acceleration features you might want. If you need those capabilities, you may want to switch hypervisors.
The final category is the "hypervisor-less hypervisor" or container-based cloud system. Containers are lightweight application hosting points that are even less isolated from each other than Type 2 VMs. They offer little resource control among applications and little security against crosstalk. What they do offer is exceptionally simple application deployment and efficient use of resources; you might be able to deploy five or 10 times the number of containers on a server as VMs. However, making a generic container to hold any application is difficult, so if you need to host many different apps on a large and hardware-diverse resource pool you may find a container approach difficult.
Validate apps against your hypervisor choice
The next step is to validate your applications against your hypervisor choices. In general, the more diverse an application set you have -- one that requires multiple guest OSes or different middleware versions -- the more likely it is that you'd need a Type 1 hypervisor regardless of what the cloud software includes. Be wary of deciding to stay with the cloud vendor because you've encountered only a few applications that don't fit. You may encounter a lot more as you evolve toward cloud hosting as a general IT strategy.
Licensing and support also may play a part in your decision on application-to-hypervisor optimality. You'll be running a guest OS for any hypervisor and how those OS copies are licensed and supported may bear on your total cost. Some Type 2 vendors are reluctant to support guests other than their own OS, which can complicate pricing and support significantly. Be sure you know what guest OS your applications need and how licenses will be charged, and if you don't like the option then consider a different hypervisor approach.
The hardware side of hypervisor selection is the most complicated. As virtualization and cloud computing have grown more popular, vendors have jumped to improve the performance of VMs through various hardware enhancements and software tools. These tools are often aimed at "cut-through" of network and device connections to the guest OSes. The performance difference that these tools can make is significant, so you'll need to be sure you pick a hypervisor that's got all the acceleration features that your applications might need.
Deciding whether to keep your hypervisor
General rules are always dangerous, but here is a starting point to decide whether to keep or replace a cloud platform's hypervisor.
- If you have applications that use several different OSes, you should insist on a Type 1 hypervisor and replace your cloud stack product if it's anything else.
- If your cloud is used primarily to host multiple instances of a few applications that all run under the same OS and middleware and that have fairly low utilization, you probably should be looking at a container environment rather than classic hypervisor virtualization.
- If your applications are primarily based on a single OS and middleware but you have some exceptions to that rule, you should use a Type 2 hypervisor and replace a Type 1 if your cloud stack includes it.
Remember that any time you move away from a package of cloud software, you're taking on more integration and support issues yourself. Be sure that the benefits you'll gain from changing hypervisors justify this risk.
Learn about Type 2 hypervisors
Five steps to choosing the best hypervisor