The interest in “container” technologies is high and rising rapidly. In the next several years, the number of installed and in-use containers may reach into the billions.
Designed to be very flexible, lightweight, and portable, containers will be used to run applications in everything from traditional and cloud data centers, to cars, cruise ships, airport terminals, gateways to the Internet of Things, and yes, even in high performance computing (HPC) environments.
The truth is, using container-like technologies in high performance computing is not a new idea. The HPC community has employed these types of technologies for many years for workload resource isolation, process tracking, job controlling, and many other functions. But these HPC-oriented solutions were not true containers; instead they were technologies such as the workload manager on IBM AIX used for memory and CPU resource enforcement, or control groups in Linux environments, or logical partitions used for application isolation and mobility.
Though a number of companies and organizations are now providing what are considered true container products and solutions, one of the first and most well-known was Docker. These containers wrap a piece of software in a complete filesystem that contains everything needed to run, including application code, system tools, system libraries, other dependencies, and in fact almost everything installable to a server.
Virtual machines (VM) are yet another form of workload container used in HPC clusters and cloud environments. At the most basic level, VMs make one server appear as many – 2000 physical machines could end up as 72,000 VMs. But for many HPC use cases, VM architectures are difficult to manage and use. For example, changing VMs to run different workloads is challenging. And significant server resources are wasted in hosting separate operating system (OS) instances for each application or job.
Containers, on the other hand, provide almost the same level of isolation as VMs but with much lower overheads. A container only comprises the application and its dependencies, thus the size of the package is much smaller. It runs as an isolated process in user space on the host OS, sharing the kernel with other containers. Scheduling containers is no different from scheduling jobs. Thus, containers can work well in many different HPC environments and use cases.
Containers also offer higher performance. They provide near bare metal speeds for application runtime so management operations (boot, reboot, stop, etc.) can be done in seconds – or even milliseconds – while typical VM operations may take minutes to complete. And the benefits don’t stop there. Applications typically depend on numerous libraries for correct execution. Seemingly minor changes in library versions can result in applications failing, or even worse, providing inconsistent results. This can make moving applications from one system to another – or out on to the cloud – problematic. Containers, on the other hand, can make it very easy to package up and move an application from one system to another. Users can run the applications they need, where they need them, while administrators can stop worrying about library clashes or helping users get their applications working in specific environments.
In genomics, for example, applications have a short development lifecycle and an even shorter shelf life. Environments are constantly evolving, with one tool being rapidly replaced by new variants, or something else entirely. This presents a major challenge to administrators who need all these different versions to co-exist, when many will depend on different versions of the same library or incompatible versions. With containers, application binaries, dependencies, and configurations can all be fully encapsulated independently of the host OS and other applications on the host. Users can run different versions of the software on the same host without worrying about conflicts. And new software packages and applications can easily be pushed out to compute nodes on demand, which potentially eases the application management burden for administrators.
For HPC use cases, containers offer many advantages:
- A scientist can send an application to a colleague for verification knowing that the results aren’t going to be influenced by differences in the new environment.
- New versions of applications can be compared with prior versions without having to worry about whether a change in the environment will influence the results.
- Current application environments can be preserved, allowing results to be duplicated at some point in the future. This is particularly attractive in industries where both experiment data and applications are used to produce data and need to be preserved for longer periods for regulatory compliance and auditing purposes.
- And perhaps most importantly, containers streamline the portability of HPC applications from on-premises to the cloud.
Recently, Kubernetes – an open source system used to manage Linux containers across private, public, and hybrid cloud environments – has come to the fore as the preferred method for managing container services. IBM Spectrum
Storage family member IBM Cloud Private includes Kubernetes, as well as a private image repository, a management console, and monitoring frameworks. IBM Cloud Private is a private cloud platform for developing and running workloads locally. It enables HPC users to design, develop, deploy, and manage on-premises, containerized cloud applications and provides control for how and where applications consume cloud services.
But Kubernetes is primarily concerned with managing services, not HPC “batch” workloads. To address the full range of HPC workload scheduling and management requirements, HPC administrators turn to solutions such as the IBM Spectrum Computing family.
As modern container adoption has accelerated, the IBM Spectrum Computing family has led the way in providing innovative new capabilities. IBM Spectrum LSF offers powerful workload management for demanding HPC environments, including plenty of container functionality. All the features in existing IBM Spectrum LSF releases are available to container jobs, enabling these workloads to run on IBM Spectrum LSF managed clusters and allowing HPC users to run Dockers, as well as Shifter and Singularity containerized jobs in batch mode in the same way as running other jobs. Perhaps most importantly, IBM Spectrum LSF addresses security concerns with containers in HPC environments.
Containers offer a new tool for high performance computing that increases flexibility, portability, efficiency, and performance. The powerful functionality in IBM Spectrum LSF help containers more easily move upscale into HPC environments. Together, these tools enable HPC users to tackle complex research and industrial problems with even greater efficiency and speed, opening an even wider horizon of future possibilities.
Learn more about the powerful capabilities of IBM Spectrum LSF – and move your containers upscale.