Stoomboot & de toekomst W. Verkerke (ATLAS)
Wat is stoomboot Gebruikers definitie van concept stoomboot Op basis van gesprekken met ATLAS/LHCb/ALICE/Astro Lokale batch faciliteit met de volgende definierende (*) features Eenvoudige jobsubmissie dmv qsub/bsub een job moet kunnen worden gesubmit door enkel de command line te specificeren, of een eenvoudig script, dat exutables en toebehoren pakt van een (NFS) disk zie zowel vanaf de submitting node als het batch systeem zichtbaar is Toegang tot ruim O(Tb) NFS file systeem voor installatie software, (configuratie) data en andere job toebehoren Toegang (met beperkte bandbreedte) tot experimentele bulk data Beschikbaarheid van (minimaal 1) interactieve node met zelfde configuratie als het batch systeem
Wat is de rol van stoomboot in dagelijks gebruik Typische gebruikers activiteiten Snel analyseren van kleinere hoeveelheden data Non-event processing jobs (MC generators, theoretische berekeningen) Maximum-likelihood fits, toy MC generate-and-fit cycles Typisch gebruiks patroon Gebruiker bereidt analyse job voor op desktop of stbc-32. Installatie van software op /project of /data etc... Snelle test op klein sample op stbc-32/desktop Submit O(100-1000) jobs op stoomboot batch Stoomboot is complementair aan GRID Processing van grootschalige (LHC) data samples duidelijk domain van grid Kleinschalige, free-form computing activiteiten domein van stoomboot
Korte termijn stoomboot issues Configuratie van batch queues Origineel test queue (30 min) en qlong (48h). Elke groep kan maximaal 75% van totale capaciteit benutten. Veroorzaakt problemen in drukke tijden. Een gebruiker kan (legitiem) verhinderen dat alle andere gebruikers uit zijn groep jobs kunnen draaien gedurende 48 uur door langlopende jobs te submitten op het moment dat de farm leeg is Verbeterde configuratie: qlong queue van 8uur, xlong queue van 48h (max 25% van farm capaciteit). Iedereen krijgt toegang tot zijn fair share van stoomboot binnen 8 uur lijkt naar tevredenheid te werken. Capaciteit Recent verdubbeld van 128 256 nodes. Lijkt afdoende tot ~eind van jaar. Voor verdere uitbreiding (in enige vorm) is wat beter onderzoek nodig naar schaling van data I/O. Het is zeker nu al niet mogelijk om 256 I/O intensieve (ntuple analysis) jobs te draaien vanaf een /data disk. Nog geen effectieve capaciteits beperking omdat er ook veel CPU intensieve jobs draaien (toy MC generation, fitting, MC generators etc) Interactive access nodes Interactieve node stbc-32 wordt (om diverse redenen) als zeer nuttig ervaren. Voor meeste (alle) gebruikers zal het inruilen van de test queue (met 16 dedicated cores) voor extra 2 interactive nodes een verbetering zijn
Middellange termijn stoomboot issues Gerelateerde vraag - Wat is het (LHC) model voor data analyse op NIKHEF en wat is de rol van stoomboot hierin? Nu: stoomboot is voor (beperkte) simpele tests, GRID submission (ganga etc) voor large-scale processing Domeinen bijna volledig gescheiden (computer beheer, netwerk) Gebruikers zijn over het algemeen tevreden over het huidige stoomboot concept, modulo de bulk data access beperkingen, en vinden het zeer belangrijk dat dit blijft bestaan. Toekomst: meer synergie met GRID of meer synergie met desktop/interactive computing. Volgende slides: 2 (hypothetische) scenarios om over te discussieren.
Middellange termijn stoomboot issues Scenario 1: integreer stoomboot in GRID hardware ( GRID software & middelware) Beheer van stoomboot hardware in het administratieve domein van grid Tier1/2. Met behoud toegang via qsub/nsub & toegang tot lokale NFS disks (=essentie van het stoomboot concept) Nadelen voor gebruikers Waarschijnlijk nodig om eerst in te loggen op speciale host (ala bosui). Minder handig, maar veel gebruikers loggen nu eerst al in op stbc-32 voor job testing en submission, dus geen killer issue NFS disks gemount of stoomboot nodes aan grid kant waarschijnlijk niet zichtbaar op nikhef machines. Onhanding, maar overkomelijk als NFS disks op stoomboot groot genoeg zijn (zijn er techische oplossing mogelijk, e.g. sshfs die hier helpen?) Voordelen voor gebruikers Potentieel betere/snellere toegang tot LHC bulk data op Tier1/2? Betere groeimogelijkheden? Is het mogelijk om idle TierX CPUs te gebruiken via deze interface? Is financiering van toekomstige hardware makkelijker?
Middellange termijn stoomboot issues Scenario 2: houd stoomboot aan de nikhef kant Houd huidige constructie in stand, maar breid bv aantal interactieve nodes uit Migratie naar lxplus/lxbatch model van CERN. Een pool van batch machines en interactive machines van gelijke architectuur Nadelen voor gebruikers Blijvend beperkte bandbreedte naar Tier1/2 LHC bulk data. Blijvend kleinere capaciteit? Voordelen voor gebruikers Beschikbaarheid van veel multi-core machines voor interactief gebruik (a la lxplus) met uniforme architectuur. Goede omgeving op allerdaagse interactieve activiteiten te paralleliseren (bv make j8 voor parallel building, multi-core parellelizatie van likelihood fits, toy MC generation) Eenvoudige overgang op batch nodes van gelijke architectuur Beter en efficienter & uniform onderhouden machines dan huidige desktops Meer keuze vrijheid in desktop (in dergelijke omgeving kan lichte mac/windows desktop volstaan, zelfs als dagelijks werk op linux is)
Slotopmerkingen Voor en nadelen aan beide scenarios Gegeven scenarios uitsluitend ter illustratie, uiteraard vele andere mogelijkheiden Focus van deze presentatie uitsluitend op evolutie van stoomboot concept. Ongeacht de uitkomst van de stoomboot discussie zal ook meer aandacht nodig zijn om Nikhef gebruikers meer/efficienter gebruik te laten maken van de bestaande Tier1/2 hardware (via GRID interface)