May 21, 2010

Palm Trees, HPC and Virtualization

Wolfgang Gentzsch

We were lounging in the paradise-like ambience of the beautiful conference hotel in Hammamet, Tunisia, earlier this week, under a verdant canopy of palm trees near the beach — not a cloud to be seen. The AICCSA International Conference on Computer Systems and Applications was in full swing, where Dr. Mazin Yousif just presented the keynote on cloud computing.

Shortly after Mazin joined Intel in 2000 to work on InfiniBand, I remember, we worked together on self-adaptable grid architecture. He then got into HPC when he was the chair of the Management Working Group (MgtWG) of the InfiniBand Trade Association (IBTA) which defined the management architecture for the InfiniBand Architecture (IBA). For many of the TOP500 HPC systems today, InfiniBand is the underlying interconnect technology, optimized for high-bandwidth low-latency communication.

Through InfiniBand, HPC applications, after establishing the interconnect channel, have direct access to the hardware, bypassing the operating system and the device drivers, reducing latency to a few hundred nanoseconds. (Ethernet, on the other hand, where communication moves through the TCP transport layer, IP network layer, link layer and physical layer, is an order of magnitude slower). I found that Mazin, equipped with this expertise, was the ideal person to answer my question about how virtualization in cloud computing really affects the performance of our HPC applications. The following is the result of our conversation HPC and virtualization — under the palms.

Wolfgang Gentzsch: We hear a lot about the additional overhead caused by virtualization, these days. How does virtualization really affect the performance of HPC applications?

Mazin Yousif: To answer this question, we first should look at the role of the VMM (the virtual machine monitor, also called hypervisor). The VMM sits directly on top of the hardware, abstracting all the hardware resources into virtual resources that get aggregated and launched as Virtual Machines (VMs, the containers that run the whole software stack). Usually, the VMM also hosts the device drivers for accessing I/O resources, causing extra overhead for I/O requests.

Gentzsch: Does this mean that the performance of mainly compute-intensive applications wouldn’t be affected by the virtualization?

Yousif: Yes, if compute-intensive applications run completely within the VM with very limited enters to and exits from the VMM, the impact on the overall performance is very minimal.

Gentzsch: … and I/O-intensive applications?

Yousif: There, the overhead is going to be noticeable because all I/O requests inside the VM cause jumps to the VMM, where the I/O device drivers are accessed, and enabling access to the physical I/O resource. This usually causes an extra overhead of a few microseconds. In a more realistic HPC scenario with a mix of compute- and I/O-intensive operations, the amount of overhead is certainly somewhere in-between.

Gentzsch: Could I avoid this overhead at all?

Yousif: May be not completely, but in principle, yes. First, VM vendors could further optimize the VMM, for example by reducing the critical path for an I/O operation within the VMM code. Second, instead of going through the VMM, an I/O device could be directly assigned to a VM which would eliminate the overhead caused by the VMM. This can be achieved by configuring the VMM, resulting in a much better I/O performance. The disadvantage however is that now you need an I/O device for every VM, instead of sharing that device among several VMs, as is usual.

Gentzsch: … but isn’t it better to optimize the rate of completing HPC transactions, rather than focusing on latency alone?

Yousif: Indeed. I see rate as more important than latency alone since rate involves both bandwidth and latency (=BW/latency). Virtualization not only impacts latency, but also impacts bandwidth as well. As before, in a mainly compute-intensive workload that fits in the allocated VM memory, rate will not see any depreciation compared to running the same workload on physical resources. In a mixed-traffic workload, relying on an assigned I/O device helps considerably here.

Gentzsch: When you assign a number of VMs to run an HPC workload, would it be better to keep the environment as is for the duration of the run or should it be adapted to track workload resources’ requirements changes?

Yousif: I see it as necessary to adapt the number and configuration of VMs based on the workload’s resources requirements, as well as the service-level agreements the owner of the workload signed with the cloud provider. To track workload changes, the VMM includes provisions to scale resources assigned to a VM up or down based on that VM’s resource needs. If the elasticity provided by the VMM is not sufficient, then other capabilities such as VMware’s Distributed Resource Scheduling along with VMotion can do the trick.

Gentzsch: So what would I have to do, as an HPC user?

Yousif: If you have a feel about the mix of compute versus I/O intensity in your HPC application, you can decide whether to assign an I/O device directly to a VM or not. If, for example, your working set fits completely into the main memory allocated to a VM, there is obviously no I/O, no page faults, no disc swaps, and thus no overhead.

Gentzsch: But that means that I have to have the ability to configure my VMM. I understand that this can be done in my private cloud, but how would I do this in IBM’s public cloud, for example?

Yousif: Today you can’t. Public cloud service providers currently do not allow HPC end-users to decide whether to assign an I/O device per VM or to share it among several VMs. If there is a real need for this, the HPC community should request this feature from the public cloud service providers to enable HPC in the public clouds.

Gentzsch: So what would be your conclusion and recommendation?

Yousif: I do not see major obstacles running HPC workloads in virtualized environments as there are ways to mitigate the overhead incurred through the VMM. But to cater further to the HPC community, we urge the cloud providers to incorporate running IBA in a virtualized environment in their cloud deployments, which could be one of the best choices for the HPC community as, first, IBA is much easier to virtualize than other I/O technologies, and second, at the same time it offers much better performance than other I/O technologies. Cloud providers currently do not offer IBA support in their cloud deployments.

Addendum on Virtualization

When I checked the dictionary to learn the meaning of virtual, here is what I found, “Vir•tu•al (adjective): existing in essence or effect, though not in actual fact.” Now, virtual systems are systems that: (i) incorporate hardware-level abstraction of physical resources including processors, memory, chipset, I/O devices and others ; and (ii) encapsulate all OS & application state. This is done through the VMM virtualization software that: (i) provides extra level of indirection and decouples hardware & OS; (ii) multiplexes physical hardware across multiple Guest VMs; (iii) provides better strong isolation between VMs; and (iv) manages physical resources and improves utilization.

Virtualization provides a great deal of benefits including, but not limited to, (i) considerably increasing utilization from <15 percent to much higher numbers that can reach 90 percent; (ii) through isolation, it allows to run multiple VMs on a single physical host, and any software malware or crashes in one VM do not affect other VMs; (iii) through encapsulation, it is possible to have the entire VM (including OS, applications, data, memory and device state) as a file that will allow us to, for example, take snapshots, clones, backup, capture a VM state on the fly and restore to point-in-time; (iv) reduce total cost of ownership; and many more.

In terms of uses, examples include test and development; server consolidation and containment; and enterprise virtual desktops.