Open Cluster Scheduler is a workload management system used in data centres to connect tens to tens of thousands of computers into a compute cluster. It acts as the operating system of this cluster, connecting the underlying hardware according to user-configurable policies, scheduling its use, and providing computing power. – Open Cluster Scheduler 9.0.6 Installation and Upgrade Guide
Teknillistieteellisissä laskentaympäristöissä (aivan mainio ilmaisu) on iät ja ajat käytetty eräajo- ja kuormantasausohjelmistoja hallinnoimaan palvelinresurssien käyttöä, toki erilaisella painotuksella kuin esimerkiksi mainframe-järjestelmissä. Jokaisessa supertietokoneympäristössä on tällainen eräajoon ja kuormantasaukseen liittyvä toteutus – markkinoilla on sekä ilmaisia että kaupallisia ohjelmistoja.
Siitä huolimatta että instituutin ATK-keskuksessa liikennöidään parhaimmillaankin vain 1Gb verkkoratkaisulla käyttäen SER-luokitteisia tietokoneita eikä esimerkiksi low latency node interconnect juuri esiinny muutoin kuin teoreettisessa kontekstissa, instituutti kuitenkin mieltää itsensä ylevästi suorastaan superkoneympäristöksi, ainakin joidenkin yksittäisten teknisten elementtien ja kahviloiden retostelevien pöytäpuheiden osalta.
Instituutin henkilöhistoriaan liittyy useammankin passivistin osalta Nokian Tutkimuskeskus (NRC), jonka puitteissa oli sentään aika merkittävän kokoinen Solaris/HP-UX/Linux-ympäristö niin konesaleissa kuin työpöydilläkin. Mikäli muistiarkistot pitävät paikkansa, joskus 2000-luvun alussa kokeiltavana oli ainakin PBS (Portable Batch System) ja ehkä jokin muukin, mutta SGE (Sun Grid Engine) valikoitui käyttöön. SGE:n historiasta on sinällään mainio wikipedia-artikkeli ja long story short – instituutissa on kääntää paukautettu x86_64 Solaris-alustalle SGE:n nykyisistä reinkarnaatioista ehkä keskeisin, Gridware Open Cluster Scheduler.
Myös LSF (Load Sharing Facility) ja muutama muu tuote tulivat vuosikymmenten mittaan tutuiksi. Instituutin varhaisen vaiheen 40 noden Raspberry Pi 3 – klusteria hallinnoitiin nykyisin hyvin laajasti käytetyn SLURM (Simple Linux Unix Resource Manager)-ohjelmiston avulla. Se olisi ollut tässäkin ihan kelpo valinta, mutta tietyt Solaris- ja Sun-preferenssit ohjasivat OCS:n käyttöön.
Edeltävässä kuvassa on Sun Fire 6800-palvelin, jollainen löytyi myös NRC:n konesalista ja sitä “ruokittiin” SGE:n läpi melko kovalla työkuormituksella. NRC:llä oli tosiaan aika paljon Sun- ja HP(-UX)-palvelimia Linuxin ohella. Kaikki käyttöjärjestelmäalustat olivat osana SGE:tä ja taisimme ainakin jossakin vaiheessa laittaa CAD-työasematkin osaksi SGE-resursseja siten, että niitä käytettiin eräajoon yöaikaan. Jos muistikuvaan voi luottaa, noin 700 palvelinta ja työasemaa oli kaikkiaan käytössä.
OCS tullaan toki asentamaan jokseenkin kaikkiin instituutin järjestelmiin, poisluettuna ehkä jokin LDAP- tai muu infrastuktuuripalvelua tuottava entiteetti. Gridwaren sivustolta käy ilmi, että käyttöjärjestelmätuki on kattava, ja tällaisessa grid-ympäristössä laskentaresurssien käyttöä suunnitteleva toki huolehtii ohjelmakoodinsa ajettavuudesta missä tahansa käyttöjärjestelmäalustassa, ellei ole tyystin nihilisti joka pysyttäytyy vaikkapa Solariksessa.
Työkuormahan tällaisissa ratkaisuissa on tyypillisesti jokin simulaatio, massiivinen matemaattinen tai muun tieteenhaaran probleema tai mikä job nyt ylipäätään vaatii optimoitua palvelintehoa. Ideahan on siinä, että suuria palvelinryppäitä voidaan käyttää optimoidusti ja loppukäyttäjän kannalta melko transparentisti siten, että kuormitus on tasaista, ennakoitavaa ja säädeltävää. Toki tämä on melkoinen yksinkertaistus, mutta riittää tämän kirjoituksen tarpeisiin.
Tietokoneympäristöjen (ja tietokoneiden) teho on monitulkintainen juttu. Tehon määritelmä pitkälti redusoituu tehdyn työn määrään suhteessa käytettyyn aikaan. Jokin single-thread juttuhan saattaa pyörähtää nopeasti uudella prosessorilla, mutta kun käyttäjiä ja palvelimia on satoja tai jopa tuhansia ja ehkä käytetään jopa massiivisesti rinnakkaistuvaa sovelluskoodia, mielenkiinto painottuukin kokonaisuuden hahmottamiseen.
Passiivi-Instituutin HPC-palveluiden perussäännöt:
- Teho on tehty työ suhteessa käytettyyn aikaan
- Laskentajärjestelmiä on ajettava optimoidusti “hanat kaakossa”
- Joka ei huolehdi siitä, että koodinsa toimii kaikilla OS-alustoilla, on patalaiska
- MPI- ja muu rinnakkaistuva koodi alisteinen kupari-gigaiselle interconnectille latensseineen
- Edellinen kohta saattaa muuttua lottovoiton tai vastaavan johdosta
- Mikään lahjominen, uhkailu tai veruke ei riitä perusteeksi työjonon jobien priorisoinnille
Sivuhuomiona noteerattakoon, että instituutin henkilöstö hyödynsi SGE:tä aikoinaan NRC:llä myös erilaisiin sysadmin-operaatioihin järjestelmäympäristössä, kauan ennen kuin vaikkapa Ansible (2012) oli edes keksitty, eikä ole kaukaa haettua, että instituutissa tullaan OCS:n suhteen toimimaan vastaavasti – ehkä lievän periaatteellisistakin syistä.
Kirjoituksen varsinainen painopiste on tavallaan kuitenkin OCS-ohjelmiston kääntämisessä lähdekoodista Solaris 11.4 x86_64-alustalla. Se ei ollut ihan yksinkertainen operaatio, jossa kenties tietty taitojen ruostuminen vuosikymmenten mittaan näytteli osaansa.
Toistaiseksi ainoaan virtualisoituun Solaris-järjestelmään (muut kymmenen ovat fyysisiä palvelimia) tuli jo aiemmin asennettua Solaris IPS package repository, siihen toteutetaan myös AI (Automated Installer) ja lähdekoodista kääntämisen tai sovelluskehityksen kannalta GCC-välineistön ohella Oracle Developer Studio 12.6, joka sisältää tietenkin myös erilaiset kääntäjät ja muut tykötarpeet.
Kävi kuitenkin ilmi, että viimeksi vuonna 2017 päivittynyt Oracle Developer Studio ei tue dialektiltaan C++16 tuoreempia versioita. OCS lähdekoodi olisi edellyttänyt C++20-tasoa, joten oli vaihdettava GCC-vetoiseen kääntöympäristöön.
Asia ei kuitenkaan aivan tuosta vain edennyt: melko paljon piti tutkia lähdekoodia, kuormittaa Googlen kuulalaakereita ja eritoten opetella CMake:n tavoille. Vaikka lähdekoodia on tullut käännettyä ja paketoituakin aikanaan todella valtavia määriä, pitkä tauko oli pölyynnyttänyt nekin taidot eikä CMake ollut missään vaiheessa tullut kovin tutuksi.
Maailma oli kovin yksinkertainen siihen aikaan kun ./configure <vipuineen> && make && make install riitti lähdekoodin kääntämiseen. Toki aika ajoin vaikkapa HP-UX edellytti hieman esoteerisia työkaluvalintoja, kääntäjä saattoi olla HP:n oma, yksi jos toinenkin muu palikka GNU-maailmasta, ja tämä työkaludiversiteetti saattoi vaihdella käännettävän lähdekoodin nojalla.
Solaris oli suoraviivaisempi jos kohta kuten ryhmästä kokenein muistutti, optimoinnissa oli laatueroja Sunin oman kääntäjän ja GNU-kääntäjän välillä. Se optimointi on muuten aika tärkeä ominaisuus sellaisissa ympäristöissä, joissa eräajo- ja kuormantasausjärjestelmä saattaa käsitellä esimerkiksi vuorokausissa tai jopa viikoissa käsiteltäviä laajoja simulaatioita tai muuta syötettä. On suuri ero tutkimus- ja tuotekehitystyössä sillä, meneekö simulaatio läpi vuorokaudessa – vai kahdessa.
# We need extra libraries on Solaris
if(${CMAKE_SYSTEM_NAME} MATCHES "SunOS")
target_link_libraries(sge_execd PRIVATE kstat)
target_link_libraries(loadcheck PRIVATE kstat)
endif()Solariksen kstat – rajapinta muodostui lähdekoodiarkistolle ongelmaksi. Käännettäessä eräitä komponentteja juttu pysähtyi kuin seinään, tavanomaiseen undefined symbol – virheilmoitukseen, joka sinällään on ruisleipätasoisesti ymmärrettävissä mutta CMakeen harjaantumattomalla meni hetki, ennen kuin yllä näkyvän koodinpätkän sai laitetuksi oikeaan sijaintiin (päätason CMakeLists.txt).
No, tuossa se tarvittava nyt on (toki esimerkiksi -DCPM_PACKAGE_rapidjson_SOURCE_DIR=/wrk/rapidjson tuli lausua osana varsinaista cmake-komentoa), mikäli joku ei malta olla rientämättä OCS-kääntöpuuhiin Solaris 11.4 x86_64-alustalla.
Seuraavaksi instituutissa viimeistellään verkkaisesti tämän “gridin” asennus ja tämän jälkeen laajennetaan grid-nodekokoelmaan myös muita kuin Solaris-järjestelmiä. Ja ehkä syksyn mittaan instituutissa tehdään paljonkin asioita, joissa tämä OCS-kerros on avuksi ja välttämätönkin.
Valmisteilla on muun muassa kiinteistön lämmityksen shuntin ohjaaminen OCS-syötettävän ja MVS mainframelle Fortran/Cobol-prosessointiin menevän koodin avulla. Tämä erottaa instituutin keskimääräisestä Home Assistant-toteutuksesta, jos ei muulla, niin kenties outoudellaan.