When rPath CTO Erik Troan speaks during the opening session at this year’s High Performance Computing on Wall Street conference on Monday morning, he’ll be emphasizing something that old school HPC’ers are very familiar with: complexity. Even moderately-sized HPC clusters are a study in complexity: everything — from operating system patches to compilers and job schedulers to an individual user’s shell preferences — interacts with everything else. Getting it all working and hammered into a stable system after the initial installation can take upwards of six months (in the average case; I once had a pair of systems that took nearly two years to stabilize, though) in a process that can seem a lot like playing whack-a-mole without a hammer. Once a system is stable, administrators and center management are understandably loathe to make a change.

And yet change is precisely what is required in today’s large-scale computing environments. When clusters were primarily confined to research environments, whether in national labs or R&D units of large corporations, then it was acceptable to expect the users to adapt to the environment. If a system took a week to stabilize after an upgrade, no one liked it, but users accepted it, not least because there usually wasn’t a lot of discipline in the system change process. There might have been a list of what changed, but in many cases even that list is not made today until after the upgrade is complete and everyone gets together to compare notes.

As HPC continues to be pulled deeper into the back offices of all kinds of companies, the line between “enterprise” computing and “high performance” computing is blurring. Enterprise users expect mature systems management, including detailed planning and management with detailed manifests sufficient to completely rebuild the operating environment at any point in time, whether to rerun a legacy application or to roll back out of an upgrade that had unexpected consequences down the road.

Although old school HPC’ers are familiar with this complexity, they haven’t done much to develop the tools and disciplines to manage it in a controlled fashion. Configuration management databases (CMDBs) are not uncommon in large, production-oriented HPC centers. But CMDBs are frequently de-coupled from implementation, and this means that it is pretty easy to ignore the CM process “just this once” to make a “really important” change, at which point the database is out of synch with reality. Good admins keep notes and backups, but these tend to depend upon individual discipline and are often manual processes with a little cron scheduling thrown in.

Whittling down complexity is rPath’s mission. Before he founded the company, Erik Troan served as Red Hat’s VP of Product Engineering, chief developer for Red Hat Software, and in several other roles. He was responsible for leading development for Red Hat Linux, RPM, and Anaconda, and has co-authored two editions of Linux Application Development. Excellent chops for a guy that’s now leading a company that positions itself to help manage the complexity of the HPC software environment.

rPath is a privately-held company of about 30 people that has been through three rounds of venture funding since its founding in 2005. The company offers a release automation platform (automatic provisioning) that includes version control for everything on a system: firmware, OS, patches, compilers, linkers and applications.

Administrators can use rPath’s tools to document the complete state of a cluster (or many clusters), set up a planned change, deploy that change to all the systems in a cluster, and automatically roll back if it doesn’t go well. Troan identifies RPM and the many front-ends built on top of RPM (yum and so on) as source-level management tools, and distinguishes rPath’s tools from them based on their ability to manage and provision everything from the OS up, including complete virtual machine images if you go for that sort of thing.

When Troan talks on Monday morning, he will emphasize three rules for a scalable approach to software infrastructure management:

1. Stay application-centric.
2. Keep versions controlled on everything.
3. Automated provisioning is key.

Troan says that commercial organizations often mirror the approach to cluster building taken in research environments: start with the hardware and the operating system, and make everything else work out. This can work just fine in an environment where COTS packages don’t dominate, or where you are working with a very mature application that is flexible in terms of its operating environment. But if your application is more finicky, or held together with bailing wire and tape, or you don’t have access to the source, this is a recipe for pain. Sure you can partition up your cluster and deploy different operating systems to support all your various application requirements, but only if you actually know what those requirements are.

The point is to start with the problem the cluster is supposed to solve, figure out what tools you need to solve that problem, and build the environment that supports it. This sounds straightforward, but a key error that can happen is that the application group will do this kind of planning and then not communicate it to the technology team running the acquisition, causing problems in implementation.

Troan’s second key for scalable HPC infrastructure management is to keep track of the version on everything, and don’t make any ad hoc changes. Basically the idea is that organizations need to think of their clusters as a delicately balanced ecosystem where everything is interrelated. Strong version control will allow organizations to track back through a change that breaks something and know exactly where to look for a problem, and will also support forward planning for change.

Up to this point in Troan’s three rules, we only have a process. In fact, we really don’t have anything more than one can get by establishing a strong CM discipline in an organization with a good CMDB and maybe some ITIL practice thrown in for good measure.

Troan says the key for tying it all together is coupling version control and documentation of state with the implementation of change through an automated provisioning system. Changes are rolled forward automatically and can be rolled back as needed to any prior state. The documentation is always complete provided that the tool managing version control is linked to the tool managing implementation deployment, and if administrators always use the system (a problem) for any change, then configuration drift is eliminated as a source of instability in your production systems.

This is a discipline that I currently employ among the desktop systems in my organization, for example, but not on my HPC systems. It seems obvious now that I think about it.

rPath’s technology is seeing adoption in real HPC environments, and Troan says that organizations like the Department of Energy labs, various companies in Europe, and Sony Pictures Imageworks are using rPath tools to manage large-scale compute clusters today.

Troan’s three rules are obviously informed by where he has positioned his company and his career; they are certainly necessary, but they may not be sufficient for the establishment of a sound discipline to tame what are often wild and wooly HPC deployments. Still, I am glad to see this conversation happening at this particular event. The HPC conversation is well advanced on Wall Street, and as the adoption of our technologies there increases, they will need mileposts to help them merge our two worlds together.