Figure 2 - available via license: Creative Commons Attribution 3.0 Unported
Content may be subject to copyright.
Comparison of HEPSPEC 32-bit and 64-bit results for both the Xeon and Avoton platforms, showing native, VM and container performance.
Source publication
In this paper the emerging technology of Linux containers is examined and evaluated for use in the High Energy Physics (HEP) community. Key technologies required to enable containerisation will be discussed along with emerging technologies used to manage container images. An evaluation of the requirements for containers within HEP will be made and...
Context in source publication
Context 1
... plot on Figure 2 illustrates the HEPSPEC value per CPU core for both of the test servers (labelled Xeon and Avoton) for the 32-bit and 64-bit version of the benchmark. It is observed for all tests that the HEPSPEC values for benchmark execution in the container platform were within 2% of native performance. ...
Citations
... Note that the HS06 score reported in Fig. 1 is determined when compiling the applications with the 64-bits compiler flag (HS06 64bits ). This choice, common to other measurements done in this report, is a consequence of a number of studies [8,9] showing how the official HS06 configuration, built with 32-bits compiled flag, reports a score that is systematically lower than the 64-bits version by a factor of 10-20%. Although this discrepancy was known, the official HS06 never changed to the 64-bits flag when the HEP software moved to 64 bits. ...
The HEPiX Benchmarking Working Group has developed a framework to benchmark the performance of a computational server using the software applications of the High Energy Physics (HEP) community. This framework consists of two main components, named HEP-Workloads and HEPscore. HEP-Workloads is a collection of standalone production applications provided by a number of HEP experiments. HEPscore is designed to run HEP-Workloads and provide an overall measurement that is representative of the computing power of a system. HEPscore is able to measure the performance of systems with different processor architectures and accelerators. The framework is completed by the HEP Benchmark Suite that simplifies the process of executing HEPscore and other benchmarks such as HEP-SPEC06, SPEC CPU 2017, and DB12. This paper describes the motivation, the design choices, and the results achieved by the HEPiX Benchmarking Working group. A perspective on future plans is also presented.
... A virtual machine [3] is a completely virtualized environment that only abstracts the physical hardware; it works with its own BIOS, virtualized network adapters, disk storage, CPU and so on. ...
... Felter et al. [10] compared KVM hypervisor and Docker container manager using both micro-benchmarks and two real applications, Redis and MySQL, and had the result that Docker results in equal or better performance than KVM in almost all cases. Roy et al. [11] evaluated Docker and KVM for High Energy Physics (HEP) workloads and got the result that Docker and KVM have less than 2% and 13.4%-32.5% performance overhead, respectively. ...
... The benefits of using Docker containers [2] rather than VMs has been investigated previously (e.g. [3], [4]) however the primary focus has generally been on performance. It's when containers are managed by schedulers where even more benefits become apparent. ...
In recent years container orchestration has been emerging as a means of gaining many potential benefits compared to a traditional static infrastructure, such as increased utilisation through multi-tenancy, improved availability due to self-healing, and the ability to handle changing loads due to elasticity and auto-scaling. To this end we have been investigating migrating services at the RAL Tier-1 to an Apache Mesos cluster. In this model the concept of individual machines is abstracted away and services are run in containers on a cluster of machines, managed by schedulers, enabling a high degree of automation. Here we describe Mesos, the infrastructure deployed at RAL, and describe in detail the explicit example of running a batch farm on Mesos.
... The author specified that the average launching time of docker container is much lesser than launching time of virtual machine. The HEP workload is tested on virtual machine and container by Roy Gareth et al. [11]. The author mentioned that container's execution overhead is around 2% while virtual machine's overhead is around 10 to 20%. ...
Cloud computing is an emerging technology in the market to manage the data center's infrastructure efficiently. It provides not only more flexibility, but also increases resource utilization. However, virtualization overhead reduces the performance of the job execution. Moreover, virtual machine's specification also affects on job execution. In the scientific world, the experiment's execution time is considerably high. Therefore, it is very important to understand the performance penalties involved in adoption of cloud computing technology for the scientific workflow. In this research, we have tested the scientific workflow on multiple virtual machines and containers with different configuration. We also captured the performance of each virtual machine and container by considering execution time and energy consumption. Our results show that high configured virtual machine gives faster results. Moreover, it also shows that virtualization technology increases energy consumption considerably. About comparison between OpenStack virtual machine and Docker container, Docker container gives faster results for CPU and memory intensive jobs. With these results, scientific community will understand the impact of adoption of cloud computing technology on scientific workflow.
... A lot of work is about the use of containers and integration of CernVM-FS was presented at this conference. See for example [14] . However, the solutions mentioned above and detailed in [11] seem to be a step forward. ...
Cloud resources nowadays contribute an essential share of resources for computing in high-energy physics. Such resources can be either provided by private or public IaaS clouds (e.g. OpenStack, Amazon EC2, Google Compute Engine) or by volunteers computers (e.g. LHC@Home 2.0). In any case, experiments need to prepare a virtual machine image that provides the execution environment for the physics application at hand. The CernVM virtual machine since version 3 is a minimal and versatile virtual machine image capable of booting different operating systems. The virtual machine image is less than 20 megabyte in size. The actual operating system is delivered on demand by the CernVM File System. CernVM 3 has matured from a prototype to a production environment. It is used, for instance, to run LHC applications in the cloud, to tune event generators using a network of volunteer computers, and as a container for the historic Scientific Linux 5 and Scientific Linux 4 based software environments in the course of long-term data preservation efforts of the ALICE, CMS, and ALEPH experiments. We present experience and lessons learned from the use of CernVM at scale. We also provide an outlook on the upcoming developments. These developments include adding support for Scientific Linux 7, the use of container virtualization, such as provided by Docker, and the streamlining of virtual machine contextualization towards the cloud-init industry standard.
This paper elaborates upon the operational status and directions within the UK Computing for Particle Physics (GridPP) project as it approaches LHC Run 2. It details the pressures that have been gradually reshaping the deployed hardware and middleware environments at GridPP sites - from the increasing adoption of larger multicore nodes to the move towards alternative batch systems and cloud alternatives - as well as changes being driven by funding considerations. The paper highlights work being done with non-LHC communities and describes some of the early outcomes of adopting a generic DIRAC based job submission and management framework. The paper presents results from an analysis of how GridPP effort is distributed across various deployment and operations tasks and how this may be used to target further improvements in efficiency.
