Open OnDemand in the Classroom

Centers use several patterns to host classroom workloads on top of OOD. Which one fits depends on your existing computing resources, how many courses you support, and how much variability you can absorb.

Classroom partition on the research cluster. The most common approach. Carve out a Slurm partition or reservation on your existing research hardware; classroom sessions run against those nodes during class hours and yield to research jobs outside them. Low incremental cost, reuses existing ops muscle. Downside: classroom UX is bounded by whatever the research side can spare.

Dedicated classroom cluster. Separate hardware for teaching. Cleanest isolation — a runaway MPI job on the research side can tank a class meeting — and easier to right-size for interactive workloads (less RAM per core, fewer GPUs, lower cost interconnect). Higher capital cost and duplicated ops. Fits centers with heavy classroom load (dozens of courses, thousands of students) or classes whose class-time SLA can not tolerate research-side contention. Some institutions repurpose older HPC resources for this use.

Kubernetes-backed OOD. Interactive sessions run as pods instead of Slurm jobs. Elastic scaling, faster startup, and a natural fit for stateless apps like Jupyter and RStudio. Does not replace Slurm for batch or MPI, so most centers run it alongside rather than instead of. Newer pattern — operational maturity varies more between sites than the older approaches.

Cloud burst. Spin up cloud capacity (AWS ParallelCluster, Azure CycleCloud, GCP) for scheduled class meetings or deadline peaks. Absorbs load spikes without buying hardware and lets you handle uncertain enrollment gracefully. Cost predictability is the catch — a poorly-scoped assignment can burn a semester budget in an afternoon, so gate it with quotas.

Hybrid. Steady-state baseline on-prem, cloud burst for known peaks. Most flexible, also the most moving parts. Sensible once you have outgrown any single pattern above.

At a glance: