Stoomboot & de toekomst
W. Verkerke (ATLAS)
Wouter Verkerke, NIKHEF
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
Wouter Verkerke, NIKHEF
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 Wouter Verkerke, NIKHEF
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 128256 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 Wouter Verkerke, NIKHEF
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.
Wouter Verkerke, NIKHEF
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? Wouter Verkerke, NIKHEF
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) Wouter Verkerke, NIKHEF
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)
Wouter Verkerke, NIKHEF
