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

Presentazione sul tema: "Worker node on demand: le soluzioni Andrea Chierici INFN-CNAF CCR 2009."— Transcript della presentazione:

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

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

3 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

4 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

5 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

6 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

7 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

8 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 3.17.4 Testato su o(300) VM VM richiede client per batch system Repository svn, documentazione su tesi Andrea Chierici, CCR 20098

9 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

10 Perugia (3) Andrea Chierici, CCR 200910

11 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 200911

12 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 200912

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

14 KIT, DESY (1) Libvirt 0.5.1 → xen e kvm Batch system: torque/maui, Sun Grid Engine OS → host: suse 10sp2, guest: SLC4.7 Python 2.4.2 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 200914

15 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 200915

16 KIT, DESY (3) Andrea Chierici, CCR 200916

17 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 200917

18 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 200918

19 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 200919

20 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 200920