Inside the Enterprise Linux environment supporting Artemis II, ISS dockings, and NASA's return to the moon
At PEARC26, our booth was standing room only for one talk. Jeff Triplett, Flight Sciences Lab Lead at NASA's Johnson Space Center, and Tim Gregoire, the lab's Deputy Lead of Operations, walked the crowd through how the Flight Sciences Lab (FSL) runs its high-performance computing environment on Rocky Linux and RLC Pro, and what that support relationship actually looks like when a mission is on the line.
Jeff opened with the short version: the FSL runs primarily on Rocky Linux, and RLC Pro's support is a core part of why that works.
At a glance
- Who: The Flight Sciences Lab (FSL), NASA's Johnson Space Center HPC facility
- What they run: Two clusters, roughly 28,000 cores across 700 servers, 10+ petabytes of parallel storage, 100+ engineering workstations, 1,000+ registered users
- What's on it: Rocky Linux and RLC Pro, running FIPS 140-certified, across every node type from AMD and Intel systems to GPU-equipped workstations
- What it supports: Analysis for every NASA human spaceflight mission, including Artemis II reentry and heat shield modeling, ISS docking and berthing, Human Landing System plume analysis, and real-time support to Mission Control during active flights
- Why RLC Pro: A support relationship the FSL team describes as an on-demand extension of their own engineering team, with root-cause fixes instead of workarounds
A lab that supports every phase of getting a crew to the moon and back
The FSL formed about six years ago when three separate HPC labs at Johnson Space Center merged, each of which had been running its own duplicate compute, storage, and services. Today the lab runs two clusters totaling about 28,000 cores across roughly 700 servers, with just over 10 petabytes of parallel file storage. High-end engineering workstations connect directly into that environment at 10 gigabit, over a 100 gigabit backbone, so engineers can mount the cluster's Lustre file system directly for pre and post processing. More than 1,000 users are registered, with 300 to 400 people using the lab on any given day.
The FSL supports analysis across more than 20 engineering domains for any NASA mission that involves a human, from aerodynamics and guidance and navigation to applied injury biomechanics, where flight surgeons run Monte Carlo simulations to confirm a crew has the right supplies and skills on board if someone is hurt on a mission. During an active mission, FSL engineers sit in the Mission Evaluation Room, right behind Mission Control, running the real-time analysis flight operations needs in the moment.
Recent work has run through Artemis II, from foam-shedding analysis on the rocket to reentry modeling for the heat shield, using custom internally written software that models how the shield's material ablates layer by layer to dissipate heat on the way back from the moon. The team also supports Dragon docking and berthing at the International Space Station, plume analysis for the Human Landing System as spacecraft close in on each other in a vacuum, and every parachute simulation that has to work exactly right on the first try.
The challenge: a fleet with zero room for surprises, mid-migration
The FSL's move off CentOS 7 landed on Rocky 8, timed, as Jeff put it, right at the wire. The team paired that migration with a move to a fully automated deployment, describing it as changing the engine, the wheels, and the paint on the car while still driving it down the road. That kind of migration, on infrastructure supporting live human spaceflight analysis, leaves no margin for an operating system that can't be trusted.
The move to RLC Pro also brought the FSL into FIPS 140 certification, the government cryptography standard the lab is required to run. And the patching timeline had to change entirely: what used to mean waiting for the next quarterly cycle now means, as Jeff described it, sometimes getting a fix inside a week.
The solution: Rocky Linux and RLC Pro across the entire fleet
Rocky Linux now runs across every node type in the FSL, from AMD and Intel systems to workstations, headless servers, and machines with a range of GPU configurations. The groundwork laid during the move to Rocky 8, including full deployment automation, is why the current transition to Rocky 9 is going far more smoothly.
Tim's part of the talk focused on what changes when a support relationship actually works. Managing hardware, storage, and software vendors often turns into a finger-pointing exercise, each side pointing to the next while the team still has to launch on schedule. He described CIQ Support doing the opposite: engineers who dig into true root cause, not just the fastest way out of the ditch, and who come back with documentation running eight or nine pages covering every configuration and approach they tried.
Support in action: three problems that could have stalled a mission
Virtualization performance. Migrating workloads from bare metal to virtualization surfaced a specific performance gap moving from Rocky 7 to 8. Expecting to get redirected to another vendor, Tim instead got an email the next morning explaining that a CIQ engineer had stood up a matching Proxmox cluster, installed Rocky 8, run detailed analysis, and returned five specific fixes.
A kernel scheduler change. The same Rocky 7 to 8 migration turned a guidance and navigation simulation that normally ran in three hours into a job taking 10 to 30 days. The team worked through it with CIQ over about a week and ended up with the simulation running faster on Rocky 8 than it ever had on 7.
A graphics problem that was nearly impossible to reproduce. Large CFD meshes and geometries that had rendered in real time, around 30 frames per second, dropped to about 0.3 frames per second, and engineers could no longer run their analysis. The issue was hard to reproduce because workstation hardware, graphics cards, and drivers varied across purchasing cycles, and it looked at first like a classic "works on my machine" case. Instead of closing the ticket, CIQ shipped the FSL's exact GPU model to Japan, where a CIQ support engineer rebuilt the same configuration, reproduced the problem, and solved it. That same approach has resolved several tickets since.
Container workflows told a similar story. Moving off the legacy Apptainer and Singularity setup toward rootless Podman, needed so users could build containers without root access, opened up a long list of file system, namespace, and networking issues. CIQ worked through those with the team, and the result now supports Artemis II and is in place for Artemis III. Tim also joked that a good share of the Rocky Linux community knowledge base exists because of FSL tickets asking about DNS, DHCP, and other core services.
The result
Jeff summed up the relationship simply: when you're deciding on support, it is worth the money, and the way it works day to day feels like having another team member on demand.
Built on a community that never stops showing up
None of this happens without the Rocky Linux community. Every fix, every hardening effort, and every FIPS certification milestone that reaches an environment like the FSL starts with the people who build and maintain Rocky Linux in the open, alongside the customers who depend on it. That collaborative foundation, not a marketing message, is what makes stories like this possible.
Thank you to Jeff Triplett and Tim Gregoire for sharing how the Flight Sciences Lab operates, and to everyone who filled our booth at PEARC26 to hear it. If your team is running mission-critical HPC workloads and wants the same kind of foundation, talk to CIQ about RLC Pro.
