Pick the right multicore virtualization use case for your design
Use Case 4 – Dynamic Resource Management
Beyond simple consolidation, virtualization technologies have the potential to provide a great deal of flexibility around how CPU and I/O resources are used.
CPU Considerations. The software architecture of a given hypervisor may offer a number of different models for how CPU cores are allocated to virtual machines. If the performance requirements dictate it, cores may be “dedicated”, where a virtual machine gets dedicated/exclusive use of one or more cores.
Cores may be also shared. For the utilization use case discussed above, the hypervisor’s scheduling algorithm can offer flexible capabilities to configure the priority of virtual machines sharing a core, ensuring that virtual machine with the highest priority dynamically gets scheduling priority. Some schedulers allow control over which cores a particular virtual machine runs on, allowing fine grained customization of how a core’s cycles are allocated to virtual machines.
Schedulers may also allow a specific configuration of the maximum percentage of a core’s cycles that a given virtual machine is permitted. So, for example two virtual machines on a core could be allocated each 80% and 20% of the core. This flexibility allows creating configurations so that during a peak load that adequate cycles are available to the virtual machines that need them.
Cores can also potentially be hot plugged and unplugged dynamically from a virtual machine to allow runtime allocation of CPUs based on when where they are needed. Unused or under-utilized CPUs can also be placed into a low power state for power savings.
Virtualizing I/O. Hypervisors typically provide two approaches to I/O:
1) Dedicated I/O. Dedicated I/O is where a device (e.g. a PCI NIC card) is assigned to a virtual machine which gets direct, exclusive use of the device. The advantage of dedicated I/O is performance-- native I/O performance speeds may be possible.
2) Virtual I/O. Virtual I/O provides a way for virtual machines to share an I/O device. For example, multiple virtual machines may each be given a virtual network device they can use for network I/O. The hypervisor emulates the virtual devices and bridges them to a physical network interface.
Dedicated I/O devices can potentially be hot unplugged or hot plugged if the bus they reside on (e.g. PCI Express) supports hot plug, which would allow resources to be added or removed without bringing a virtual machine down.
Click on image to enlarge.
In cases where virtual I/O is used to share a physical device like a network interface, some hypervisors provide the capability to limit the traffic bandwidth to/from the virtual machine.
Use Case 5 - High Availability
For many mission critical applications, any downtime or data loss has the potential for devastating effects. On approach to solving this problem is to use redundant hardware.
For example, a high availability system (Figure 7, below) may have 2 identical hardware boards. One is considered ‘active’ and handles the normal system workload.
The second board is ‘standby’ and is prepared immediately to take over the functioning of the system if the active board fails. The standby board maintains the necessary synchronization of state with the active so that the standby can cleanly take control and keep the system alive if the active fails.
Experience has shown that a substantial majority of system failures are due to software causes. This leads to the possibility of creating high-availability systems using virtualization where the active and standby systems are virtual machines instead of redundant hardware.
If there is a system failure a “failover” event occurs and the standby VM becomes the “new- active”, takes control and keeps the system alive, while the “old-active” is reset and moves into the standby role.
This use case is another variation of consolidation through virtualization, where the system maintains high reliability while saving cost and power.
Click on image to enlarge.
A system with VMs configured in an active/standby relationship also enables the ability to upgrade a system’s software without downtime. Software in the standby VM can be upgraded without affecting the system’s normal operation.
A software controlled failover is triggered causing the standby to become the new-active. The software in the old-active VM can then be upgraded without affecting the running system.
Loading comments... Write a comment