Worker node on demand: le soluzioni Andrea Chierici INFN-CNAF CCR 2009

Indice Introduzione Le soluzioni disponibili  INFN: CNAF, Perugia, Bari  Germania: KIT/DESY Considerazioni Conclusioni Andrea Chierici, CCR 20092

Il problema comune Desiderio di sfruttare al meglio le risorse delle moderne architetture hardware Esigenze degli esperimenti  rischio incompatibilità  Maggiore flessibilità nell’offerta di ambienti software Supporto EGEE esclusivamente per sl(c)4  Possibile problema di compatibilità con hw recente  Soltanto l’architettura a 32 bit è supportata ufficialmente Andrea Chierici, CCR 20093

La soluzione Sfruttare la virtualizzazione per eseguire “job” (grid e non) in ambienti altamente personalizzati  Isolamento degli ambienti garantito all’origine  Versatilità nella gestione delle versioni  Minima perdita prestazionale  Si dispone di un OS sempre “fresco” Andrea Chierici, CCR 20094

CNAF (1) Basato su xen  In studio supporto (migrazione) a kvm Batch system: LSF OS → host: sl5, guest: sl(c)4 Testato su o(100) VM VM richiede client per batch system Insieme di script pre-post exec LSF, non ancora pronta una release in pacchetto Andrea Chierici, CCR 20095

CNAF (2) Una VM specifica attrae i job e li “virtualizza” (bait) Script di pre-post exec via LSF selezionano l’ambiente prescelto Scheduling e fair-share gestito in modo trasparente Anche se non ha nessuna dipendenza particolare, è pensato espressamente per virtualizzazione di WN EGEE Andrea Chierici, CCR 20096

CNAF (3) Dom0 wnod_XenMaster wnod_LsfMaster Bait VWN First JobStarter LSF DomU Step 0 batch job is dispatched on BaitWN Step 1 JS stops, gets requirements and send a notify for a new batch job to process Step 2 Request a VM for batch job execution Step 3 Create or Recycle a VM for batch job execution and notify about it Step 7 VWN close waiting for a new job VWN-001 LSF DomU PostExec Second JobStarter Step 6 notification: batch job execution finished on VM Step 5 notification: batch job execution started on VM Step 4 batch job execution migrated to VM Andrea Chierici, CCR 20097

Perugia (1) Basato su xen Batch system: torque/maui OS → host: debian, gentoo, guest: slc4  Funziona anche su altri linux Python 2.3, spread toolkit Testato su o(300) VM VM richiede client per batch system Repository svn, documentazione su tesi Andrea Chierici, CCR 20098

Perugia (2) Modello client/server Vari plugin estraggono informazioni dai client che vengono aggregate sul server  Numero e stato dei nodi  Numero e stato delle VM  Caratteristiche dell’hardware Non utilizzato per middleware EGEE Andrea Chierici, CCR 20099

Perugia (3) Andrea Chierici, CCR

Bari (1) Basato su vmware server Batch system: indipendente OS → host: vmware, guest: qualunque Gridftp e mysql server Testato su o(20) VM VM non richiede client per batch system Compilazione da sorgenti Andrea Chierici, CCR

Bari (2) Dare possibilità a tutti di usare l’infrastruttura EGEE  Si sottomettono direttamente le VM Implica la possibilità di usare altri OS...  Non bisogna adattare il software  Indipendenza dal batch system  Pensato per funzionare anche su “cloud” Andrea Chierici, CCR

XML “XML Firewall” GRID WNs Log in DB MySQL EGEE VM Key Store UI RB Bari (3) Andrea Chierici, CCR

KIT, DESY (1) Libvirt → xen e kvm Batch system: torque/maui, Sun Grid Engine OS → host: suse 10sp2, guest: SLC4.7 Python Testato su o(16) VM, in corso su più VM VM non richiede client per batch system Insieme di script, documentazione su twiki Andrea Chierici, CCR

KIT, DESY (2) VM parte del job, avviata da “prologo” torque  Batch system non configurato sulla VM  Vari job-spec usati per eseguire VM differenti  VM avviata da script python usando libvirt  Dopo avvio, pipe del job via ssh  Alla fine del job, la VM viene distrutta e lo script “epilogo” lanciato automaticamente Andrea Chierici, CCR

KIT, DESY (3) Andrea Chierici, CCR

Considerazioni: implementazione Tutte le soluzioni sono basate su linux Architetture basate su plug-in e adattabili alle esigenze di ogni sito Batch system quasi sempre a scelta  Soluzioni CNAF e PG prevedono batch client attivo su VM  Le altre soluzioni prevedono la VM come parte del job, quindi nessun client attivo Questo semplifica la gestione del batch system?  Come avviene l’accounting?  Come avviene la comunicazione con il batch server? Andrea Chierici, CCR

Considerazioni: gestione VM VM preparate in locale  Supporto unicamente per binari compatibili  Sysadmin sanno sempre cosa può venire eseguito Patch applicate quando necessario VM provenienti dall’esterno  Versatilità e maggiore flessibilità  VM scatola nera, non si ha controllo di essa Andrea Chierici, CCR

Considerazioni: sicurezza VM provenienti dall’esterno possono creare problemi di sicurezza  Utente “root” all’interno della rete  VM non controllabile  Rete locale esposta a software malevolo Virtualizzazione della rete oltre che delle macchine Andrea Chierici, CCR

Conclusioni Tutte le soluzioni presentate sono estremamente interessanti La qualità del lavoro e i risultati ottenuti danno certezze per un uso in produzione Nessuna soluzione sembra facilmente esportabile presso altri siti  Documentazione Molti progetti tutti indipendenti, con scarsa distribuzione di informazioni  Auspicabile, anche attraverso il gruppo di lavoro CCR, maggiore co-operazione per la risoluzione di problemi comuni Andrea Chierici, CCR