Calypso
The students sandbox cluster, hosted onsite. This page covers the machines and storage; the network layout is on ISC³ network and the software configuration (accounts, container runtimes, SLURM, registry) on Calypso software stack.
At a glance
| Role | Students sandbox cluster |
| Machines | 1× Dell R740XD (master) + 15× Dell R630 (workers) |
| Student nodes | calypso0 – calypso7 (8 active — see the note below) |
| RAM | 128 GB per worker node |
| GPUs | NVIDIA A2, one per node |
| Storage | NFS share from the FS2500 NAS mounted on every node |
| Network | Isolated network behind a Wireguard VPN |
| Access | VPN, then SSH |
calypso8 – calypso10 are gone: they are now the carnaval clusterOn 2026-08-04 those three machines were wiped and rebuilt as the Proxmox playground cluster
carnaval — the first step of
phase 3. They are no longer Calypso
nodes, no longer in SLURM, and their local /home trees were rescued to
rumba:/hdd/backup/carnaval-preinstall/ before the wipe (the NAS homes under /exports were never
touched). The remaining Calypso nodes are unchanged.
Hardware
- 1× Dell R740XD (
calypsomaster) - 18× Dell R630: 8 active workers (
calypso0–calypso7), 3 converted to carnaval, and 7 racked spares (see the rack layout) — the spares answer on no protocol at all, their iDRACs having never been put on the management LAN, so nothing about them can be checked remotely (todo) - Each worker has 128 GB RAM and one NVIDIA A2 (16 GB) GPU:
- CPU: 2× Intel Xeon E5-2690 v3 @ 2.6 GHz (48 threads) or 2× Intel Xeon E5-2697 v4 @ 2.3 GHz (72 threads), depending on the node — see the table below
The GPUs are usable from within containers through the NVIDIA Container Toolkit; see Calypso software stack for details.
Node specifications
| Node | CPU | GPU |
|---|---|---|
calypso0 | 2× E5-2690 v3 (48 threads) | NVIDIA A2 |
calypso1 | 2× E5-2697 v4 (72 threads) | NVIDIA A2 |
calypso2 | 2× E5-2697 v4 (72 threads) | NVIDIA A2 |
calypso3 | 2× E5-2697 v4 (72 threads) | NVIDIA A2 |
calypso4 | 2× E5-2690 v3 (48 threads) | NVIDIA A2 |
calypso5 | — | NVIDIA A2 |
calypso6 | — | NVIDIA A2 |
calypso7 | — | NVIDIA A2 |
Node IP addresses are listed on the Calypso network page.
Specs verified directly on the nodes (July 2026); calypso5 – calypso7 were down at that time, so their CPU model is not listed and their GPU comes from the software stack documentation. The three ex-nodes calypso8 – calypso10 are specced on the carnaval page, where their CPUs and RAM were finally measured — and two of the three differed from what was assumed here (calypso8/9 are E5-2683 v4, calypso10 has 112 GB, not 128).
Storage
Storage shared between all Calypso nodes comes from the rack's Synology FS2500 NAS (nas, 192.168.88.250), mainly for SLURM needs: jobs can run on any node against a common filesystem and write their results there. Hardware, volumes and NFS exports are detailed on the NAS page.
On the nodes, the filesystem is mounted from nas:/volume1/calypso_homes/homes/firstname.lastname to each student's shared directory /exports/firstname.lastname/.
In each student's home there is a symlink to it: ~/nas_home.
Power
Rack power is distributed by an APC AP8681 mounted vertically (0U) on the external side of the rack. Details read from the device over SNMP (July 2026):
| Model | APC NetShelter Rack PDU 2G, metered-by-outlet with switching (AP8681) |
| Capacity | 11 kW — 230 V three-phase input, 21× C13 + 3× C19 outlets |
| Management | 192.168.88.10 — web UI, SSH, SNMP (public, read-only); admin credentials in the secretzone |
| Firmware | NMC AOS/app v6.9.6, hardware rev 02 (manufactured July 2021) |
| Environment probe | Temperature/humidity sensor attached — 26.2 °C / 46 % RH in July 2026; alarms at 45/50 °C |
Load measured in July 2026: 1.1 kW total (2.8 / 2.2 / 0.6 A per phase at ~241 V), peak 3.6 kW and 10.5 MWh accumulated since the energy counter reset in November 2025. Phase L3 carries almost nothing — worth considering when plugging in new machines.
Each outlet is individually metered and switchable, so a hung machine can be power-cycled remotely from the PDU web UI.
The room overheated around June 22–23, 2026 — the probe recorded up to 76.4 °C and no machine shut down automatically. Full account in the incident log; a layered protection policy is proposed in Thermal protection & emergency shutdown.
UPS
A BlueWalker VFI 2000 RMG PF1 (2 kVA, online double-conversion) sits at the bottom of the rack at U2–3. Read over its USB link in August 2026:
| Management | No network interface. USB only — cabled to rumba since 2026-08-03, where it appears as USB HID 0665:5161 (OLHV2K0, serial 83222109100407) |
| State | Healthy and on mains — charging, AC present, no fault or replace-battery flag; battery at float (82.0 V on 72.0 V nominal = 13.67 V/cell) |
| Protects | rumba, both PSUs — cords moved 2026-08-03. Nothing else |
| Load | 14 % — ~1.0 A / 265 W, matching rumba's own draw |
| Input / output | 244 V in, 229.5 V out. Its own input comes from the PDU, so the rack total is unchanged |
The load is live on the rack status page, which also raises a Telegram alert if mains is lost. Nothing per-outlet is available: the UPS has no switchable load groups.
At 14 % the unit has plenty of headroom for rumba alone, but it could never carry the rack: the PDU recorded a 3.63 kW peak during the June 2026 heat event against ~1.10 kW at rest. Anything more that should ride through a power cut — the NAS holds the only copy of the student homes — has to be chosen deliberately, and that is an open item in the todo.
Two things still make cord tracing a desk-unfriendly job, so rename the 24 factory-default PDU outlet names the next time someone is at the rack: iDRAC reports PSU input voltage in ~8 V steps (it read a flat 240.0 V on both PSUs before the move and 232 V after, close to but not equal to the UPS's measured 229.5 V), and a PSU's standby draw sits below the UPS's measurement floor.
The driver, the full variable list and the shutdown policy are on the UPS monitoring page.
Access
Connect through the VPN, then SSH to your nodes. Check with your teacher which nodes are allocated to you; if you need to run jobs on all nodes (via SLURM), you can pick any of them to submit from.
See Getting access for details about requesting access.