New CycleCloud HPC Cluster Is a Triple Threat: 30000 cores, $1279/Hour, & Grill monitoring GUI for Chef

Update: Wow, we've gotten tremendous feedback from this run on Arstechnica, Wired, and others, and man has it been a busy few days. We did have many people ask a quesiton that we wanted to clarify:
Q: How long would the run-time take in-house vs. in-cyclecloud?
A: The clients indicated the workload would never have happened in-house because it would have used everything they had for week(s). The in-cyclecloud run time was 7-8 hours.


In more ways than one, the Nekomata cluster is three times as impressive as our last public mega-cluster. A few months ago, we released details of the Tanuki cluster, a 10,000-core behemoth launched within AWS with the click of a button. Since then, we have been launching large clusters regularly for a variety of industries. We kept our eye open for a workload large enough to push us to the next level of scale. It didn’t take very long.

We have now launched a cluster 3 times the size of Tanuki, or 30,000 cores, which cost $1279/hour to operate for a Top 5 Pharma. It performed genuine scientific work — in this case molecular modeling — and a ton of it. The complexity of this environment did not necessarily scale linearly with the cores.

In fact, we had to implement a triad of features within CycleCloud to make it a reality:
1) MultiRegion support: To achieve the mind boggling core count of this cluster, we launched in three distinct AWS regions simultaneously, including Europe.

2) Massive Spot instance support: This was a requirement given the potential savings at this scale by going through the spot market. Besides, our scheduling environment and the workload had no issues with the possibility of early termination and rescheduling.

3) Massive CycleServer monitoring & Grill GUI app for Chef monitoring: There is no way that any mere human could keep track of all of the moving parts on a cluster of this scale. At Cycle, we’ve always been fans of extreme IT automation, but we needed to take this to the next level in order to monitor and manage every instance, volume, daemon, job, and so on in order for Nekomata to be an efficient 30,000 core tool instead of a big shiny on-demand paperweight. Our new Grill monitoring GUI app for CycleServer helped show what's cooking with our Opscode Chef environment that helped with cloud infrastructure automation for all the instances for this cluster.

The Stats

Before we step through these enhancements one by one, let’s take a moment to sit back and contemplate the sheer scale of this compute environment.

Resource Count
c1.xlarge instances 3,809
cores 30,472
RAM 26.7-TB
AWS Regions 3    ( us-east, us-west, eu-west )


  • Where Tanuki certainly encompassed a significant number of physical racks of compute hardware in the AWS datacenter, this scale meant that our footprint was a significant number of aisles. Certainly, the power, cooling, and floorspace that we occupied during this run were larger than what one would find at many moderately sized datacenters.
  • Our system placed individual staged requests to AWS that eclipsed the size of entire clusters that we considered to be large at the time (such as Oni). These requests were made relentlessly to Amazon and were fulfilled with impressive efficiency.
  • The amount of RAM available on the compute nodes was roughly 30TB, which means that it could hold the entirety of the current raw Wikipedia database 5 times over in memory (citation needed — get it?)

The workload that was run for the client in this case was a software package that consisted of  molecular dynamics approaches applied to molecular structure and functioning that were run against millions of compound targets. The expected run time on the internal cluster environment was expected to be at least a week worth of run time consuming the entire cluster.

To manage the high throughput workload of the jobs, we used the condor scheduler for load distribution and CycleServer to monitor progress of workload and job scheduling. The table below provides a synopsis of the total work that was done in this massive scale analysis.

Metric Count
Compute Hours of Work 95,078 hours
Compute Days of Work 3,961 days
Compute Years of Work 10.9 years
Number of condor jobs 154,116
Avg. Run Time per job 37 minutes

New Multi-Region Support

Because of the scale of this run, we opted to go across multiple regions to spread out the spot instance requests and increase our probability of getting the core counts we required. Drilling down a little deeper into the numbers shown in the table above, here is what the breakout across the three regions looked like. We were very pleased that provision times were very consistent across the regions.

Region Server Count Core Count RAM
US-East 2,825 22,600 19.8-TB
US-West 484 3,872 3.4-TB
EU-West 500 4,000 3.5-TB

Massive Spot Instance Support

Nekomata also marks our first use of Spot Instances. The Spot Market provides a huge discount over traditional on-demand instances which means we can do more science for less money. We’ve added support for Spot Instance bidding for CycleCloud execute hosts. Nekomata made use of over 3700 c1.xlarge Spot Instances at an average cost of 0.286 USD / instance / hour (0.036 USD / core / hour). Compare that to the 0.68 USD / instance / hour for the same On Demand instance. That’s 57% savings!

Massive Telemetry and Monitoring: CycleServer & Grill

We used Nekomata to give a workout to some of the new tools we’ve been working on that provide unprecedented views into large-scale computing environments. We’re extremely excited about this, as this is the first time that we are leveraging the plugin architecture of CycleServer to enable both the collection and visualization of diverse types of data. One such tool is a new offering that we have named Grill for CycleServer.


Cycle has professed its love for Opscode’s Chef project in the past on our blog, and we continue to use it to provision even our largest clusters–Nekomata is no different. When you have hundreds of nodes converging each minute, you need a way to see precisely which converges are failing so that you can resolve the issue(s).

Using the Handler feature of open-source Chef, we wrote a Ruby gem that reports converge information to our flagship telemetry engine, CycleServer. Grill shows the result of every converge, as you can see in the screenshot below.

For Nekomata, we built a Grill view that shows a timeline of all converges and a window showing drill-down to individual hosts and their converge history. Important information such as converge duration, number of resources updated and an exception stack trace on failure are all just a click away. On the right side of the display is a stacked histogram of converges per minute with successful in green and failed in red. We have many more features planned for our upcoming release of the chef dashboards.

Along with the chef dashboards, we have also extended our telemetry engine and visualization dashboards to include  heat maps to succinctly highlight servers that are running host as well as including the data captured by ganglia to see resource utilization trends over time as illustrated with a point-in-time screenshot below from the Nekomata run.


We’ll be releasing more information in the coming weeks about these tools, so please stay tuned.

Next time around…

While all parties involved are absolutely thrilled at the achievement of the Nekomata cluster, we would be remiss if we did not share a couple of lessons learned during such a large run. You can be sure that when you run at massive scale, you are bound to run into some unexpected gotchas. As a result, it’s critical that you always execute a post mortem after such an event to identify what went well, what didn’t go well and how to do it better next time.

In our case, one of the gotchas included such things as running out of file descriptors on the license server. In hindsight, we should have anticipated this would be an issue, but we didn’t find that in our pre-launch testing, because we didn’t test at full scale ( another lesson learned….keep reading ). We were able to quickly recover from this bump and keep moving along with the workload with minimal impact. The license server was able to keep up very nicely with this workload once we increased the number of file descriptors.

Another bump that we hit were EBS volume and byte limits on EBS-backed volumes as outlined in their documentation here: Once again, once identified, necessary limits were raised and we kept moving right a long.

The Future?

What’s next from CycleComputing’s large scale clusters? Well, we already have our next use-case identified and will be turning up the scale a bit more with the next run. While we are excited about the ability to scale clusters to larger and larger core counts and forging new frontiers in cloud computing, we are most excited about the possibilities we are creating by enabling scientists to spin up such large clusters with minimal effort to answer questions that they would never have considered asking a year ago because they didn’t have access to resources that could answer those questions. Today, we have enabled them to have access to massive computing scales in minutes which in turn gives them the ability and opportunity to ask these sorts of complex questions, not once or twice, but multiple times with multiple different perspectives and multiple different variables leading to improvements in their discovery research efforts. We understand that ultimately, it’s not about core counts or TB of RAM or PB of data. Rather, it’s about how we are helping to transform how science is done.

If you’re interested in talking about high volumes of calculations of compute with Cycle Computing, or using CycleCloud, CycleServer, and Grill, then please contact us.

Share this:
  • Gordon Shephard

    What were your concerns with regards to balancing IO/Memory/DiskStorage with the cluster – did amazon’s large amounts of memory provide you some benefits that you needed versus going with a more traditional GPU solution? Did you need/utilize the extra memory/disk storage you got from all those instances – or was this a purely CPU bound process, and did the memory and disk storage for each instance go (mostly) untouched?

  • mrb

    Molecular modeling is known to be generally very well suited to GPUs. Why not run this workload on 1/10th the number of machines, eg. by using EC2’s GPU instances?

  • Hi Gordon & mrb:
    We wish there was such a thing as a “more traditional GPU solution”. Although they aren’t new, GPUs are not supported by all software algorithms. Many still need to be ported. This is one of those cases, where the preferred molecular dynamics model was (1) proprietary and (2) had no GPU support.

  • mrb

    I am surprised that this “top 5 pharma” company doesn’t seem to have an in-house team of GPU developers already working on GPU-accelerated molecular modeling for them. Or, do they?
    They are billion dollar businesses. It seems like they could gain an edge over the competition, instead of being locked into third-party proprietary CPU-only apps…

  • Adam

    Why standard extra large and not hi-cpu extra large instances? For the same price, you get 47% the RAM, but 250% the compute units.

  • The Top 5 Pharma has a vendor with a valuable molecular dynamics model, and this model isn’t available on GPU from that vendor, so in-house programmers don’t matter…

  • Adam: We did use high-cpu xlarge. It is the best CPU/$ if RAM isn’t a limitation.