A CoreWeave Kubernetesre ültette a Slurm HPC-ütemezőt
A CoreWeave bemutatta a SUNK-ot, amely a Slurm HPC-ütemezőt Kubernetesen futtatja. A megoldás célja, hogy a kötegelt Slurm-feladatok és a hosszú futású Kubernetes-munkaterhelések ugyanazt a számítási kapacitást használhassák.
- A SUNK a Slurm HPC-ütemezőt Kubernetesen futtatja.
- A Slurm-feladatok és a Kubernetes-munkaterhelések közös számítási kapacitást használhatnak.
- A megoldás Helm-charttal és Kubernetes-alapú GitOps-munkafolyamatokkal telepíthető.
- A Nodeset és a Syncer a Slurm, illetve a Kubernetes állapotának összehangolását támogatja.
- Az egyedi Kubernetes-ütemező a Slurm állapota alapján ütemez munkaterheléseket.
Két eltérő célra készült rendszer egy platformon
A nagy teljesítményű számítástechnika és a mesterségesintelligencia-feladatok világában a Slurm és a Kubernetes eltérő szerepet tölt be. A SchedMD által fejlesztett Slurm Workload Manager, röviden Slurm, sok HPC-munkafolyamat elterjedt ütemezője. Elsősorban véges élettartamú kötegelt feladatok futtatására tervezték.
A Kubernetes ezzel szemben jellemzően hosszú ideig futó munkaterhelésekhez, például következtetési szolgáltatásokhoz használatos. A CoreWeave szerint a Kubernetes kötegelt feladatokhoz készült ütemezője kevésbé elterjedt, és bizonyos funkciókban elmarad a Slurmtól. Más Kubernetes-alapú ütemezők, például a Volcano és a YuniKorn, Slurmhez hasonló képességeket kínálnak, de a Slurm köré épült tudásbázissal is versenyezniük kell.
A két rendszer külön kezelése külön klasztereket, számítási erőforrásokat és sok esetben külön tárhelyet jelenthet. Ilyenkor a Slurm és a Kubernetes közötti erőforrás-kezelés elkülönül, az együttműködés pedig kézi munkát igényelhet.
A SUNK közös számítási kapacitást használ
A CoreWeave SUNK, vagyis „Slurm on Kubernetes” megoldása a Slurmöt Kubernetes-erőforrásként telepíti, és Slurm-ütemezőként integrálja a Kubernetesbe. A Slurm-feladatok így Kubernetesen belül futhatnak, miközben a fejlesztők a Slurm erőforrás-kezelését használhatják.
A vállalat szerint ezzel a kötegelt és a rugalmasan változó, úgynevezett bursty munkaterhelések ugyanazon a központi platformon kezelhetők. A Kubernetes és a Slurm ugyanahhoz a számítási kapacitáshoz fér hozzá, így az erőforrások a kétféle munkaterhelés között mozgathatók.
A CoreWeave a megoldás létrehozását ügyfélhatékonysági szempontokkal indokolja. Nagy és költséges HPC-klaszterek esetében fontos a kihasználtság magas szinten tartása, mivel a használaton kívüli, de kifizetett számítási kapacitás költséget jelent. A vállalat közlése szerint sok ügyfél külön kezelte a Slurmot, vagy integrációt kért hozzá, ezért olyan megoldást építettek, amely megtartja a Slurm előnyeit, miközben nem szükséges külön klasztert üzemeltetni.
Helm, GitOps és dinamikus csomópontkezelés
A SUNK egy testre szabható Helm-charttal telepíthető Slurm-klasztert használ. Ez hozzáférést ad a Kubernetes-alapú GitOps-munkafolyamatokhoz, valamint támogatja többek között a prolog- és epilog-szkriptek konfigurációjának követését, a tesztklaszterek gyors létrehozását és az s6-szkripteket, illetve szolgáltatásokat.
A hitelesítés többféleképpen konfigurálható, többek között LDAP használatával a kapcsolódó OpenLDAP Helm-charton keresztül, illetve külső megoldásokkal, például Authentikkel vagy GAuth-tal. A Kubernetes oldali képességek között a CoreWeave a gyors ütemezést, a konténerizációt, a vezérlősík magas rendelkezésre állását, a dinamikus csomópontméretezést, az erőforrás-korlátokat és a PersistentVolumeClaim-alapú megosztott fájlrendszert sorolja fel.
A SUNK állapotkezelést is biztosít a Kubernetes és a Slurm között. A rendszer dinamikus csomópontokat, automatikus topológialétrehozást, Pyxis konténerfuttatást, valamint GRES-támogatást és automatikus azonosítást kínál.
A Nodeset, a Syncer és az egyedi ütemező szerepe
Az architektúra minden szolgáltatását Kubernetes-konténerekben futtatja. A Slurm komponensei podokban kapnak helyet, a felhasználók pedig bejelentkezési csomópontokon keresztül érhetik el a klasztert. Innen a Kubernetes működése el van rejtve, így a felhasználói élmény a hagyományos Slurm-klaszteréhez hasonló.
A Slurm konfigurációját, a topológiát, a prolog- és epilog-szkripteket, valamint az érzékeny adatokat, például az adatbázis-jelszavakat Kubernetes ConfigMapekben és Secretekben kezelik. A számítási csomópontok Kubernetes-csomópontokon futó podokként jelennek meg, a slurmd és a munged pedig ezekben a podokban működik.
A CoreWeave három, kifejezetten ehhez az integrációhoz létrehozott elemet emel ki: a Nodesetet, a Syncert és az egyedi ütemezőt. A Nodeset egy Kubernetes egyéni erőforrás-definíció, amely egy Slurm-csomópontot ír le Kubernetes-környezetben, és a Kubernetes, illetve a Slurm állapota alapján támogatja a védett frissítéseket és a méretezést. A Syncer a Slurm REST API-ján keresztül továbbítja és olvassa az állapotinformációkat. Ezekre építve az operátorok figyelik az erőforrásokat, és módosításokat hajtanak végre, amikor szükséges.
A SUNK egy egyedi Kubernetes-ütemezőt is tartalmaz, amely a Slurm állapotai alapján képes Kubernetes-munkaterheléseket a számítási csomópontokra ütemezni. A CoreWeave szerint ez teremti meg annak lehetőségét, hogy ugyanaz a kapacitáskészlet a Slurm-feladatok és a Kubernetes-munkaterhelések között dinamikusan osztható legyen. A Kubernetesen futó komponensekhez Prometheuson keresztüli metrikakitettség is társul.
