Research Roundup: Virtualization and Low Latency for Global Clouds
In this week’s hand-picked assortment, researchers consider virtualizing HPC as a Service, low latency on global cloud systems as well as accelerators and surveying the HPC cloud environment as a whole.
Hardware-Assisted Virtualization for Deploying HPC-as-a-Service
Virtualization has been the main driver behind the rise of cloud computing, argued researchers out of the A*STAR Institute of High Performance Computing in Singapore. Despite cloud computing’s tremendous benefits to applications (e.g. enterprise, Web, game/ multimedia, life sciences, and data analytics), its success in High Performance Computing (HPC) domain has been limited. The oft-cited reason is latency caused by virtualization.
Meanwhile, according to the researchers, the rising popularity of virtualization has compelled CPU vendors to incorporate virtualization technology (VT) in chips. This hardware VT is believed to accelerate context switching, speed up memory address translation, and enable I/O direct access; which are basically sources of virtualization overheads.
Their paper reports the evaluation on computation and communication performance of different virtualized environments, i.e., Xen and KVM, leveraging hardware VT. Different network fabrics, namely Gigabit Ethernet and InfiniBand, were employed and tested in the virtualized environments and their results were compared against those in the native environments.
A real-world HPC application (an MPI-based hydrodynamic simulation) was also used to assess the performance. Outcomes indicate that hardware-assisted virtualization can bring HPC-as-a-Service into realization.
Low Latency Communications in Global Cloud Computing Systems
A paper out of McMaster University in Hamilton explores technologies to achieve low-latency energy-efficient communications in Global-Scale Cloud Computing systems.
A global-scale cloud computing system linking 100 remote data-centers can interconnect potentially 5M servers, considerably larger, according to the paper, than the size of traditional High-Performance-Computing (HPC) machines. Traditional HPC machines use tightly coupled processors and networks which rarely drop packets.
In contrast, today’s IP Internet is a relatively loosely-coupled Best-Effort network with poor latency and energy-efficiency guarantees, with relatively high packet loss rates. This paper explores the use of a recently-proposed Future-Internet network, which uses a QoS-aware router scheduling algorithm combined with a new IETF resource reservation signalling technology, to achieve improved latency and energy-efficiency in cloud computing systems.
A Maximum-Flow Minimum-Energy routing algorithm is used to route high-capacity “trunks” between data-centers distributed over the continental USA, using a USA IP network topology. The communications between virtual machines in remote data-centers are aggregated and multiplexed onto the trunks, to achieve significantly improved energy-efficiency.
According to theory and simulations, the large and variable queueing delays of traditional Best-Effort Internet links can be eliminated, and the latency over the cloud can be reduced to near-minimal values, i.e., the fiber latency. The maximum fiber latencies over the Sprint USA network are approx. 20 milliseconds, comparable to hard disk drive latencies, and multithreading in virtual machines can be used to hide these latencies.
Furthermore, if existing dark-fiber over the continental network is activated, the bisection bandwidth available in a global-scale cloud computing system can rival that achievable in commercial HPC machines.
Integrating Accelerators Using CometCloud
Application accelerators can include GPUs, cell processors, FPGAs and other custom application specific integrated circuit (ASICs) based devices. According to research out of Cardiff University, a number of challenges arise when these devices must be integrated as part of a single computing environment, relating to both the diversity of devices and the supported programming models.
One key challenge they consider is the selection of the most appropriate device for accelerating a particular application. Their approach makes use of a broker-based matchmaking system, which attempts to compare the capability of a device with one or more application kernels, utilising the CometCloud tuple space-based coordination mechanism to facilitate the matchmaking process.
They described the architecture of our system and how it utilises performance prediction to select devices for particular application kernels. They demonstrated that within a highly dynamic HPC system, their approach can increase the performance of applications by using code porting techniques to the most suitable device found, also; (a) allowing the dynamic addition of new devices to the system, and (b) allowing applications to fall back and utilise the best alternative device available if the preferred device cannot be found or is unavailable.
A Study of High Performance Computing on the Cloud
The popularity of Amazon’s EC2 cloud platform has increased in recent years, according to research out of the University of Arizona and Lawrence Livermore National Laboratory. However, the researchers argue, many high-performance computing (HPC) users consider dedicated high-performance clusters, typically found in large compute centers such as those in national laboratories, to be far superior to EC2 because of significant communication overhead of the latter.
Their view was that this is quite narrow and the proper metrics for comparing high-performance clusters to EC2 is turnaround time and cost. In their paper, they compared the top-of-the-line EC2 cluster to HPC clusters at Lawrence Livermore National Laboratory (LLNL) based on turnaround time and total cost of execution.
When measuring turnaround time, they included expected queue wait time on HPC clusters. Their results show that although as expected, standard HPC clusters are superior in raw performance, EC2 clusters may produce better turnaround times. To estimate cost, they developed a pricing model—relative to EC2′s node-hour prices—to set node-hour prices for (currently free) LLNL clusters. They observed that the cost-effectiveness of running an application on a cluster depends on raw performance and application scalability.