With cloud computing as the de facto deployment model in large enterprises, the usage of multiple clouds within a single enterprise has become omnipresent. The decision for a specific cloud provider often comes on the basis of the availability and the capabilities of the offered cloud services. Requirements of different groups within the enterprises lead to fragmented usage patterns favoring different cloud stacks.

This article is Part-3 of our series of Kubernetes HPC articles [Part-1, Part-2) describing some of the cloud providers’ high performance computing (HPC) offerings for demanding engineering applications and their customers’ potential need for multi-cloud adoption.

Kubernetes has become the common workload management for enterprise workloads regardless which cloud is used. In the two earlier articles, we evaluated its usefulness also for the HPC space. To demonstrate the usefulness of Kubernetes also for multi-cloud HPC, the article concludes with a case study: simulating cardiac valve leakage with patient-specific data generation and machine learning on an Azure/Google multi-cloud environment with SUSE Rancher Kubernetes management, where we worked with a customer to run 3,000 Abaqus simulations, each in its own Kubernetes cluster.

Cloud providers’ tailored HPC solution offerings often discourages multi-cloud adoption

AWS, Azure, and Google Cloud Platform come with an easy-to-use solution stack for running HPC clusters. Unfortunately, none of their HPC offerings provides solution patterns for multi-cloud adoption. The infrastructure maintenance solutions which need to be customized can only be reused inside the cloud providers’ own environment. Building a similar test or even failover environment to a different cloud provider requires learning, adapting, and maintaining completely different technology stacks. This substantially increases the complexity of the existing challenges like license management, data staging, and workload management. Hence following the cloud providers best practices leads to treating HPC workload management as a siloed problem. Due to traditional HPC workload managers’ legacy, the job scheduling, distribution, and management problem is typically only solved within a single network. What we see with our customers is the need to deploy and manage HPC workload across regions, cloud provider subscriptions, and even crossing the frontiers of a single cloud.

Can Kubernetes be the common HPC workload management layer?

With the rise of Kubernetes for enterprise workloads, all cloud providers have massively invested in their managed Kubernetes solution stacks. More than two years ago, when we started to deploy the first Kubernetes clusters serving our HPC containers, we ran into many issues which have been resolved meanwhile (lack of support of large container image sizes, long infrastructure deployment times compared to bare VMs, lack of colocation of VMs in a datacenter). Today, we even find key features like out-of-the-box InfiniBand support on the cloud provider’s roadmap, which have to be handled by our own tooling.

Given the fact that we can allocate Kubernetes clusters on all cloud providers, how does that help us in our multi-cloud journey? First of all, we can deal with the same technology stack everywhere. Even though there are minor differences, the workload management layer, i.e., the Kubernetes API server, simplifies re-using workload deployment instructions massively. Thanks to our HPC application containers, we are able to provide HPC environments with the exact same characteristics in any cloud. Kubernetes provides the required workload management abstraction on top. Due to the huge, open software ecosystem supported for Kubernetes environments, introducing customized functionalities which work and are supported independently of the cloud provider, has never been easier. Multi-cloud Kubernetes management platforms provide a single pane of glass for monitoring, logging, and workload management also for HPC workloads distributed across different regions and clouds.

The availability of the same software stack in different clouds is just one problem to tackle. What about license management? Where does the simulation input data come from and where should the results be stored? What about long-term storage? How can cross-cloud communication be secured? How can costs be managed? How can authentication and authorization be implemented? We plan to discuss these topics in a future article.

3,000 multi-physics living heart simulations in 3,000 Kubernetes Clusters in a Multi-Cloud Environment with machine learning

Recently we have been challenged by 3DT Holdings, a spinoff of the University of California San Diego, with the task of simulating cardiac valve leakage with patient-specific data generation and machine learning on an Azure/Google multi-cloud environment, with SUSE Rancher Kubernetes management and our engineering simulation platform. We supported end users Yaghoub Dabiri from 3DT Holdings, Julius Guccione, UCSF, and Ghassan Kassab, UCSD, with running 3,000 simulations, accurately simulating blood flow, stress, volume, and pressure inside a human heart. The goal was to find the optimal position of a so-called MitraClip that’s placed in the heart’s mitral valve to reduce mitral regurgitation (MR). A MitraClip is a small metal clip that allows doctors to perform catheter-based surgery to repair the mitral valve, and that brings a minimally invasive alternative to open-heart surgery. With these 3,000 simulations we collected enough simulation results in order to train a set of ML algorithms which can then predict the best suited MitraClip position at the valve in almost real time (within a couple of seconds) instead of hours or even days.

In order to stay within 3DT Holdings’ budget we used Google Cloud Platform’s C2 HPC VMs as they can be allocated in preemptible (spot) mode. But since we had to manage and monitor the environment on behalf of our customer, some of the required architecture components had been implemented within our own Azure account. While saving 80 percent of the costs, preemptible instances have no guaranteed uptime and can only stay running for a maximum of 24 hours, hence our decision to run each simulation in its own Google Kubernetes Engine cluster which is automatically started each time from scratch to reduce the risk of letting a simulation get interrupted. The remaining infrastructure, like license servers and SUSE’s Rancher for monitoring purposes, has been running on Azure. Both environments have been protected by firewall rules, only allowing traffic flowing between the components. One special GKE cluster used cheaper instance types and a GPU to run our Abaqus container, providing a remote (accessible via NI-SP’s machine image with AWS’s NICE DCV) Linux desktop with Abaqus installed. This cluster served the whole project as an entry point for the engineer, preparing the input data and supervising the output results.

While managed Kubernetes deployments added some slight overhead (management fee, more daemons / processes running on compute nodes, …), the advantages of having 80 percent cost reduction on C2 preemptible CPU price, using a consistent application stack deployed by a single command, and exploiting compatibility with the whole Kubernetes ecosystem by our SUSE Rancher integration outweighed them by far. We minimized cost and job failures due to preemption, while at the same time we could maximize cloud resource and license usage to get maximum throughput. That way, the total cost of the 3,000 simulations stayed under $20K.

Acknowledgements

The authors want to thank Microsoft Azure and Google GCP teams for excellent support, and software providers Dassault Systèmes, SUSE, and NI-SP for generously providing software licenses for Abaqus, Rancher, and DCV, respectively.

About the Authors

Daniel Gruber, Burak Yenier, and Wolfgang Gentzsch are with UberCloud, a company that started in 2013 with developing HPC container technology and containerized engineering applications, to facilitate access and use of engineering HPC workload in a shared on-premise or on-demand cloud environment.