Just what constitutes HPC and how best to support it is a keen topic currently. A new paper posted last week on arXiv.org – Rethinking HPC Platforms: Challenges, Opportunities and Recommendations – by researchers from the University of Edinburgh and University of St. Andrews suggests the emergence of “second generation” HPC applications (and users) requires a new approach to supporting infrastructure that draws on container-like technology and services.
(Lead author Ole Weidner spoke with HPCwire after this article was first published and discussed further how it relates to other HPC container efforts. Please see the addendum at the end of the article for his additional comments.)
In the paper they describe a set of services, which they call ‘cHPC’ (container HPC), to accommodate these emerging HPC application requirements and indicate they plan to benchmark key applications as a next step. “Many of the emerging second generation HPC applications move beyond tightly-coupled, compute-centric methods and algorithms and embrace more heterogeneous, multi-component workflows, dynamic and ad-hoc computation and data-centric methodologies,” write authors Ole Weidner, Rosa Filgueira Vicente, Malcolm Atkinson, and Adam Barker.
“While diverging from the traditional HPC application profile, many of these applications still rely on the large number of tightly coupled cores, cutting-edge hardware and advanced interconnect topologies provided only by HPC clusters. Consequently, HPC platform providers often find themselves faced with requirements and requests that are so diverse and dynamic that they become increasingly difficult to fulfill efficiently within the current operational policies and platform models.”
It’s best to read the paper in full which examines in some detail the challenges and potential solutions. The authors single out three applications areas and report that as a group they have deep experience working with them:
- Data Intensive Applications. Data-intensive applications require large volumes of data and devote a large fraction of their execution time to I/O and manipulation of data. Careful attention to data handling is necessary to achieve acceptable performance or completion. “They are frequently sensitive to local storage for intermediate results and reference data. It is also sensitive to the data-intensive frameworks and workflow systems available on the platform and to the proximity of data it uses.” Examples of large-scale, data-intensive HPC applications are seismic noise cross-correlation and misfit calculation as encountered, e.g. in the VERCE project.
- Dynamic Applications. These fall into two broad categories: “applications for which we do not have full understanding of the runtime behavior and resource requirements prior to execution and (ii) applications which can change their runtime behavior and resource requirements during execution.” Two examples cited are: (a) applications that use ensemble Kalman-Filters for data assimilation in forecasting, (b) simulations that use adaptive mesh refinement (AMR) to refine the accuracy of their solutions.
- Federated applications. “Based on the idea that federation fosters collaboration and allows scalability beyond a single platform, policies and funding schemes explicitly supporting the development of concepts and technology for HPC federations have been put into place. Larger federations of HPC platforms are XSEDE in the US, and the PRACE in the EU. Both platforms provide access to several TOP-500 ranked HPC clusters and an array of smaller and experimental platforms.”
“To explore the implementation options for our new platform model, we have developed cHPC, a set of operating-system level services and APIs that can run alongside and integrate with existing job via Linux containers (LXC) to pro- vide isolated, user-deployed application environment containers, application introspection and resource throttling via the cgroups kernel extension. The LXC runtime and software-defined networking are provided by Docker and run as OS services on the compute nodes,” say the authors. (see figure 2 from the papers shown here)
The authors note prominently in their discussion that many traditional HPC applications are still best served by traditional HPC environments for which they have been carefully coupled.
“It would be false to claim that current production HPC platforms fail to meet the requirements of their application communities. It would be equally wrong to claim that the existing platform model is a pervasive problem that generally stalls the innovation and productivity of HPC applications…[There are] significant classes of applications, often from the monolithic, tightly-coupled parallel realm, [that] have few concerns regarding the issues out-lined in this paper…They are the original tenants and drivers of HPC and have an effective social and technical symbiosis with their platform environments.
“However, it is equally important to understand that other classes of applications (that we call second generation applications) and their respective user communities share a less rosy perspective. These second generation applications are typically non-monolithic, dynamic in terms of their runtime behavior and resource requirements, or based on higher-level tools and frameworks that manage compute, data and communication. Some of them actively explore new compute and data handling paradigms, and operate in a larger, federated context that spans multiple, distributed HPC clusters.”
To qualify and quantify their assumptions, the authors report they are in the process of designing a survey that will be sent out to platform providers and application groups to verify current issues on a broader and larger scale. They write, “The main focus of our work will be on the further evaluation of our prototype system. We are working on a ‘bare metal’ deployment on HPC cluster hardware at EPCC. This will allow us to carry out detailed measurements and benchmarks to analyze the overhead and scalability of our approach. We will also engage with computational science groups working on second generation applications to explore their real-life application in the context of cHPC.”
The authors are well aware of the many ongoing efforts to leverage container technology for HPC. Lead author Weidner told HPCwire, “I am familiar with the work on Singularity that Gregory Kurtzer and his peers at LBNL are doing. It is a prominent project with quite significant real-world uptake and definitely needs to be, along with a few others, added to the related work section in the next iteration of our paper.
“We can definitely observe that over the past year, operating-system level virtualization and containers have become more and more common place in HPC application and middleware stacks, especially in projects that rely on, or support what we call “second gen.” applications. Take Cornell’s BioHPC Lab (https://cbsu.tc.cornell.edu/lab/lab.aspx) for example, or NERSC’s Shifter (http://www.nersc.gov/users/software/using-shifter-and-docker/using-shifter-at-nersc/). I think with Singularity leading the way, the objective of most of these projects is to address what we refer to as the “centralized (software) deployment monopolies” and “application mobility” in our paper.
The scope for cHPC tries to be a bit broader, says Weidner. “First of all, unlike Singularity, cHPC is not production-grade software. It is a research prototype. Having said that, the vision of cHPC and the conceptual work we are doing around it is not just to encapsulate (end-)user applications but to incorporate more low-level HPC system components. Our aim is to develop blueprints for more “data-driven” HPC environments in which application adaptivity, elastic scalability and resilience strategies are supported explicitly by the platform.
“We believe that a data-driven HPC software stack is one of the critical, but still missing components to address the upcoming exascale application challenges in which real-time predictive operational analytics will play an important role to support resilience and efficiency at extreme scales. Containers are an excellent vehicle to research these new data-data driven system and application architectures without having to implement an entire HPC system from scratch. That’s why we have developed cHPC.”
Weidner and his colleagues are working on a paper in which we lay out a comprehensive framework for operational data management in HPC systems (“Data-Driven HPC”).