Recently, AWS and Western Digital embarked on a very fun, challenging project of evaluating the impact of running their electro-magnetic simulations on a massive HPC cluster built on AWS using Amazon EC2 Spot Instances.   The lessons we learned and the results we were able to prove are very interesting and I am excited to share a quick overview here.

One of the biggest advantages of moving your HPC workloads to AWS is the ability to achieve extreme scales in terms of capacity and configurations – without a lot of upfront investment and heartache over long term commitments.  If you work for an organization that has moved HPC workloads to the cloud or has at least started the process by bursting to the cloud when demand spikes, you have experienced the agility and flexibility benefits afforded by the cloud.  You either have an individual account to access and request resources in the cloud or you request it via your HPC admin.  In both cases, you start building “your” cluster when you are ready. In most cases the cluster is built automatically by your job scheduler as you submit your jobs, and compute resources are ready within minutes. When the jobs are done, you shut down your cluster and stop paying for it.  When you request your cluster, unlike your on-premises environment, you can specify what type of CPUs (or GPUs, or FPGAs) you would like to run a particular application on.  Ever wonder how much faster your application would run if you had the latest CPU or GPU?  What if you wanted to determine if an I/O bandwidth optimized configuration versus CPU was better for parts of your workflow?   Well, now you can try many different configuration types without going through a cumbersome procurement process.  It becomes incredibly easy to fine tune specific portions of your HPC workflow, given the many different instance types available, and how easy it is to drop them into a workflow.   Then, there is the scale.   It does not matter if you request 1,000 cores for 8-hours or 8,000 cores for 1-hour.  You still pay the same.   So, if your application supports it, why not scale up your resources and get to results faster?

That is exactly what a recent collaborative project between AWS and Western Digital did.  First, a quick overview of the hard disk drive (HDD) market.  The HDD market is an extremely competitive one.  The ever-increasing demand for capacity from enterprises, particularly large hyper-scale data centers (like us) has been keeping Western Digital very busy.  Faced with the need to innovate to meet the growing demand for data storage capacity, the engineering teams at Western Digital are always pushing the limits of physics and engineering.  Enterprise HDDs are still confined to a 3.5 inches form factor (as they have been for years) with no chance to increase the size to accommodate additional capacity and performance requirements.  So, the only solution to meeting the increased capacity demands is to cram more bits into the same space and make sure the drives can handle the increasing demands for performance.  The technical term here is increasing the areal density of the media – meaning, keep on shrinking the geometry that you are allowed to use to capture the ones and zeros on the rotating media.  As you shrink those geometries, there are various aspects of cross talk, noise and atomic behavior that you have to comprehend to get to an ingredient combination that works 24x7x365, and can be manufactured at high volume. It is quite an art and science to get all those things to line up exactly, make it repeatable, make it manufacturable, make it operational, and, oh, by the way, get it to work for years without a failure.

A big focus of the engineering simulations work at Western Digital is to evaluate different combinations of technologies and/or solutions (or ingredients that make up the solutions) that goes into making new HDDs.  The basic design of the hard disk involves a rotating media and a head on a slider arm that moves over the media.  The engineering teams are looking at smaller and smaller geometries of recording channels on the media so they can fit more and more 1’s and 0’s or bits into the same space.  They are looking to achieve faster read and write times from that media.  The simulations thus involve many variable vectors to find the right combination of media, speed of rotation of the media, materials that constitute the media etc. that can provide that higher density and faster read-write times.   The end goal is to determine which combinations work and which don’t – and making sure those combinations that don’t work are avoided in the manufacturing process or in solutions/component recipes for the physical products.

As part of this precedent-setting collaborative work, Western Digital ran around 2.3 million simulation jobs on a Spot-based cluster of a little over one million vCPUs.   If they were to do those same 2.3 million simulations on a standard Spot based cluster of 16,000 vCPUs at a time (as they do today), it would have taken them about 20 days to get the same work done.     The idea of doing 20 days of work in 8 hours is a game changer.  The impacts go beyond the traditional business metrics – it is a great competitive advantage for a business that is driven by innovation.

So, what goes into scaling an application to run on extreme capacity infrastructure?  It is a coordinated effort between the application engineers, the infrastructure engineers, and the team at AWS.    At a 10K ft level, what we are doing here is taking a large statistical simulation, splitting it into jobs that run on a single vCPU, then when the jobs are done, bringing it all back and collating the results.   That requires work on both the application side and the infrastructure side.  The application has to ensure that the individual simulations are all done correctly, the infrastructure has to coordinate jobs across a vast number of servers/cores and bring all the data back to collate. What made this run even more interesting is that we used EC2 Spot instances, so the application had to be resilient for any job preemption or interruption that might happen. During the 8 hours run at the full one million vCPU scale, we experienced less than 1% of interruption. From an infrastructure point of view, we had to evaluate the limits that exists on number of underlying services (compute, storage, API calls) and since this was a cluster that was run all in a single region, but spanned multiple Availability Zones, we combined the features of AWS Spot Fleet with the highly-scalable cluster management and scheduling of Univa NavOps and GridEngine to coordinate cluster management across the wide capacity of our infrastructure and keep the cluster fully utilized even under such very high workload.

A few other points that are worth highlighting here.  First, Western Digital, Univa and AWS were able to fully exploit the configuration flexibility that running HPC workloads on the cloud offers.  Before embarking on this simulation, the engineers from both AWS and Western Digital spent a lot of prep time profiling the various instance types that Amazon EC2 offers. Through profiling this multitude of instance types (over 25 different instances types), we were able to land on the most optimal range of instances offering AVX acceleration for this workload, giving the AWS Spot Fleet the flexibility and freedom to find the cheapest and fastest hardware for the job.   Second, this simulation was also a major achievement in terms of the use of containers to run HPC workloads.  In this run, the entire application was ported onto containers, which is a big shift from having to haul around drivers and dependencies across jobs and VMs.   This run actually might have been one of the largest container fleets running a single application! Third, we used Amazon Simple Storage Service (Amazon S3) as the storage back-end for this simulation.  Being able to support this fast rate of data access at such massive scales required no tuning effort, as S3 bandwidth scaled gracefully and peaked at 7500 PUT/s.  And last, but not the least, this was a great example of how Spot Fleet can simplify cluster management.  In this particular case, we just had three Spot Fleet requests simultaneously and we were able to hit a million cores in the cluster in around 1 hour and 32 minutes!

To learn more, visit https://aws.amazon.com/hpc or reach out to your local AWS representative.