Progetto Alta Affidabilità Leonello Servoli Workshop CCR, Otranto 8 giugno 2006.

Presentazione sul tema: "Progetto Alta Affidabilità Leonello Servoli Workshop CCR, Otranto 8 giugno 2006."— Transcript della presentazione:

1 Progetto Alta Affidabilità Leonello Servoli Workshop CCR, Otranto 8 giugno 2006

2 Leonello Servoli - Otranto CCR 8 giungo 2006 2 Sommario - Motivazioni della High Availability; - Il pacchetto XEN per la virtualizzazione; - La virtualizzazione dei servizi (GRID e non solo)

3 Leonello Servoli - Otranto CCR 8 giungo 2006 3 High Availability: Perchè? Nella struttura di GRID Computing (e non solo) è fondamentale che tutta una serie di servizi siano disponibili “sempre” (LSA > 99%). “sempre”  almeno il 99% < 3.6 giorni/anno Considerando la notte, le festività, le vacanze.. è facile mancare questo obiettivo.

4 Leonello Servoli - Otranto CCR 8 giungo 2006 4 High Availability: Perchè? Una prima soluzione: Ridondanza delle macchine fisiche. Cioè esiste un clone della macchina su cui è in funzione il servizio. Clone significa che nella ipotesi di interruzione del servizio, la seconda macchina prende il posto della prima nel senso di: Numero IP, Nome, Servizi

5 Leonello Servoli - Otranto CCR 8 giungo 2006 5 Ridondanza Macchine Fisiche Ci sono due macchine front-end (director1 e director2) e N real-servers. Attraverso keepalived il director2 interroga il director1, e se fallisce attua il takeover.

6 Leonello Servoli - Otranto CCR 8 giungo 2006 6 Ridondanza Machine Fisiche: schema logico

7 Leonello Servoli - Otranto CCR 8 giungo 2006 7 High Availability: Perchè? Nei Tier-N il numero di server è diventato molto elevato; solo per il middleware LCG: BDII, RB, CE, SE, MyProxy, FTS, LFC, RGMA, VOBOX, VOMS, g-PBOX, DGAS, GridICE.... Senza contare i servizi specifici di esprimento (es. Phedex) e altri servizi “normali” (es. mailserver). -> Al Tier1 – CNAF ci sono ~ 200 servers. -> Un job dipende da N server, per una inefficienza totale data dalla somma delle singole inefficienze.

8 Leonello Servoli - Otranto CCR 8 giungo 2006 8 High Availability: Perchè? I motivi di interruzione di un servizio possono essere molteplici e a volte di non facile soluzione. -> problemi hardware di un disco; -> problemi hardware sulla macchina che ospita il servizio (RAM, CPU); -> driver che accoppiati a particolari distribuzioni producono problemi software sporadici; -> generici problemi software specifici del servizio;

9 Leonello Servoli - Otranto CCR 8 giungo 2006 9 High Availability: Perchè? I tempi di ripristino possono a loro volta essere molto variabili e richiedere o meno l'intervento di un operatore umano. Si va da pochi secondi per far ripartire un servizio bloccato per motivi software, es. web server, a qualche ora per sostituire una scheda madre o replicare un disco, e qualche giorno per risolvere conflitti tra driver e distribuzioni.

10 Leonello Servoli - Otranto CCR 8 giungo 2006 10 Possibile soluzione: Macchine Virtuali replica di servizi; spostamento da un hardware all'altro; soluzione a basso costo; compatibilità con vari OS e varie piattaforme hw scalabile aumenta la sicurezza gestione dei servizi semplificata. Vantaggi:

11 Leonello Servoli - Otranto CCR 8 giungo 2006 11 Possibile soluzione: Macchine Virtuali cambiare velocemente la versione dell'OS testare un codice su diverse distrib aggiornare un sistema e testare che tutto sia ok, altrimenti è possibile tornare indietro utilizzare al meglio le risorse di una macchina migrare una macchina virtuale anche “in corsa”: - in un host con più risorse; - spostamento per manutenzione su altro hw; Ulteriori Vantaggi: creazione di nacchine di test:

12 Leonello Servoli - Otranto CCR 8 giungo 2006 12 Macchine Virtuali Singola immagine di OS : Virtuozo, Vservers, etc.  Raggruppa i processi utente in contesti.  Difficile isolare un processo da un altro. Virtualizzazione completa: VMware, VirtualPC, QEMU.  Esegue un numero multiplo di OS non modificati.  Difficile ottenere una virtualizzazione efficiente per x86. Para-virtualizzazione (kernel multipli): UML, XEN  Esegue un numero multiplo di OS adattati ad una particolare architettura.  L'architettura di Xen/x86 è molto vicina al normale x86.  L'efficienza è abbastanza vicina a quella nativa x86.

13 Leonello Servoli - Otranto CCR 8 giungo 2006 13 Xen 3.0 Architecture Hardware (SMP, MMU, physical memory, Ethernet, SCSI/IDE) GuestOS (XenLinux) Device Manager & Control s/w User software VM0 GuestOS (XenLinux) Unmodified User Software VM1 Front-End Device Drivers GuestOS (XenLinux) Unmodified User Software VM2 Front-End Device Drivers Unmodified GuestOS (WinXP)) Unmodified User Software VM3 Xen Virtual Machine Monitor Back-End 32/64bit SMP Front-End Device Drivers

14 Leonello Servoli - Otranto CCR 8 giungo 2006 14 System Performance LXVU SPEC INT2000 (score) LXVU Linux build time (s) LXVU OSDB-OLTP (tup/s) LXVU SPEC WEB99 (score) 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.1 Benchmark suite running on Linux (L), Xen (X), VMware Workstation (V), and UML (U)

15 Leonello Servoli - Otranto CCR 8 giungo 2006 15 Scalabilità La scalabilità è limitata principalmente dalle richieste di risorse necessarie alle applicazioni.  qualche decina of VM possono essere create su nodi di classe server.  i normali meccanismi di paging dei OS possono ridurre l'uso della memoria a < 4MB per ogni kernel quiescente.  l'overhead di Xen per l'uso della memoria del sistema ospitante è < 32 KB. Ulteriori overhead di CPU sono trascurabili.

16 Leonello Servoli - Otranto CCR 8 giungo 2006 16 VM: utilità della migrazione la migrazione della VM permette:  High-availability  Load balancing Xen

17 Leonello Servoli - Otranto CCR 8 giungo 2006 17 Migrazione VM: Assunzioni Storage su rete:  NAS: NFS, CIFS  SAN: Fibre Channel  iSCSI, network block dev  drdb network RAID Buona connettività  L2 network comune  L3 re-routing Xen Storage

18 Leonello Servoli - Otranto CCR 8 giungo 2006 18 Svantaggi di XEN il kernel è pesantemente modificato xen3 e' vincolato ad alcune versioni del kernel:- 2. 2.6.12.6 (xen 3.0.1);- 2.6.16 (xen 3.0.2); la ram viene usata in modo esclusivo per ogni macchina virtuale (si puo' variare a runtime)

19 Leonello Servoli - Otranto CCR 8 giungo 2006 19 Gruppo High Availability Coordinatore del progetto: Davide Salomoni – CNAF Varie competenze già presenti tra le persone che hanno espresso interesse; in particolare: - RedHat Cluster Manager: CNAF, Trieste; - Linux Virtual Server: CNAF, Perugia - Virtual Machine (Xen, qemu):CNAF, Perugia, Torino Altre sedi interessate: Bari, Bologna, Genova, Roma1.

20 Leonello Servoli - Otranto CCR 8 giungo 2006 20 Proposta VM per virtualizzare i servizi Si propone una soluzione, basata su XEN 3.0, con: -> uso di macchine virtuali multiple su singole macchine fisiche; -> uso di un numero limitato di macchine fisiche; -> esistenza di un sistema di monitoraggio specifico per i singoli servizi.

21 Leonello Servoli - Otranto CCR 8 giungo 2006 21 Architettura Proposta VM MF 1 MF 2 Block Device MV 1 MV 2 MV 3 Server Fisico MV 1 MV 2 MV 3 Server Fisico X

22 Leonello Servoli - Otranto CCR 8 giungo 2006 22 Vantaggi Proposta VM Riduce il downtime quasi sempre a pochi secondi; Permette facilmente lo sviluppo ed il test di versioni diverse; In linea di principio rende indipendenti dall'hardware sottostante i servizi; Si potrebbe definire una VM tipizzata per servizi generici da distribuire su tutte le macchine. Vantaggi:

23 Leonello Servoli - Otranto CCR 8 giungo 2006 23 High Availability: Status Sono stati fatti test generici su XEN con varie distribuzioni. - test di installazione di dom0 con varie distribuzioni e architetture (32 o 64 bit) (gentoo 2006.0, SL4, Fedora 5, Slackware 10.2) - realizzazione di macchine virtuali (domU) pronte all'uso (SL3, SL4); - test del supporto SMP per le macchine domU; - test di utilizzo su diversi h/w ( più di 10 macchine fisiche diverse tra loro) - test di affidabilità e stabilità nel tempo (CE e WN su domU SL3) per diversi mesi; - stress test relativi ad uso intenso di CPU e di I/O ( > 48 ore continuative).

24 Leonello Servoli - Otranto CCR 8 giungo 2006 24 High Availability: Status Sono stati fatti test di caricamento di domU via Block Device Remoti (GNDB, iSCSI, FC). - verifica delle compatibilità delle patch XEN sia con quelle GNBD che iSCSI. - caricamento di singole macchine virtuali da Block Device Remoti. - I/O stress test (IOzone > 48 ore continuative) delle tre configurazioni. Sono stati fatti test di caricamento di domU via filesystem distibuiti (GPFS). - verifica delle compatibilità delle patch XEN con quelle GPFS. - caricamento di singole macchine virtuali via GPFS.

25 Leonello Servoli - Otranto CCR 8 giungo 2006 25 E' stato implementato quasi completamente il prototipo del pacchetto che deve controllare che siano funzionanti: - le Macchine Fisiche; - le Macchine Virtuali; - i servizi in esecuzione; Attualmente è una struttura client/server (migrerà a peer to peer): - ogni macchina, virtuale o reale, ha un daemon in esecuzione; - c'e' un server (per il momento) logicamente separato che controlla l'attività dei client monitorizzandone gli stati. ll server ha la conoscenza della corrispondenza tra le macchine reali, quelle virtuali ed i servizi. High Availability: Status

26 Leonello Servoli - Otranto CCR 8 giungo 2006 26 Real1Real2Real3Real4Real5Real6 VM images repository Master Private Switch VM Public Switch Rete privata di controllo Rete pubblica High Availability: Status

27 Leonello Servoli - Otranto CCR 8 giungo 2006 27 Prossimi passi: 1) implementazione completa del prototipo con almeno 2 macchine fisiche + n macchine virtuali con WN + CE; 2) test di scalabilità con circa 20 macchine fisiche per verificare le performance dei meccanismi di caricamento e l'architettura (file system divisi tra read-only e writable); 3) virtualizzazione delle altre componenti di GRID (RB, BDII, etc.); High Availability: Futuro Milestone proposte in marzo alla CCR: Entro maggio: - avere un prototipo funzionante; (quasi) - avere una prima valutazione delle diverse soluzioni e dei loro ambiti di applicabilità; (quasi)

28 Leonello Servoli - Otranto CCR 8 giungo 2006 28 High Availability: Futuro Milestone future: Entro settembre: - Soluzioni HA di produzione implementate per il Tier-1 (test prima della fine del SC4); - definire una “raccomandazione” HA per l'INFN, anche in funzione dei Tier-2; Fine anno: - Soluzione standard da offrire per l'implementazione anche ai Tier-2, ma eventualmente anche per servizi di genere diverso dal computing di LHC.