Progetto Alta Affidabilità Leonello Servoli Workshop CCR, Otranto 8 giugno 2006
Leonello Servoli - Otranto CCR 8 giungo Sommario - Motivazioni della High Availability; - Il pacchetto XEN per la virtualizzazione; - La virtualizzazione dei servizi (GRID e non solo)
Leonello Servoli - Otranto CCR 8 giungo 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.
Leonello Servoli - Otranto CCR 8 giungo 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
Leonello Servoli - Otranto CCR 8 giungo 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.
Leonello Servoli - Otranto CCR 8 giungo Ridondanza Machine Fisiche: schema logico
Leonello Servoli - Otranto CCR 8 giungo 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.
Leonello Servoli - Otranto CCR 8 giungo 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;
Leonello Servoli - Otranto CCR 8 giungo 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.
Leonello Servoli - Otranto CCR 8 giungo 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:
Leonello Servoli - Otranto CCR 8 giungo 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:
Leonello Servoli - Otranto CCR 8 giungo 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.
Leonello Servoli - Otranto CCR 8 giungo 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
Leonello Servoli - Otranto CCR 8 giungo System Performance LXVU SPEC INT2000 (score) LXVU Linux build time (s) LXVU OSDB-OLTP (tup/s) LXVU SPEC WEB99 (score) Benchmark suite running on Linux (L), Xen (X), VMware Workstation (V), and UML (U)
Leonello Servoli - Otranto CCR 8 giungo 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.
Leonello Servoli - Otranto CCR 8 giungo VM: utilità della migrazione la migrazione della VM permette: High-availability Load balancing Xen
Leonello Servoli - Otranto CCR 8 giungo 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
Leonello Servoli - Otranto CCR 8 giungo Svantaggi di XEN il kernel è pesantemente modificato xen3 e' vincolato ad alcune versioni del kernel: (xen 3.0.1); (xen 3.0.2); la ram viene usata in modo esclusivo per ogni macchina virtuale (si puo' variare a runtime)
Leonello Servoli - Otranto CCR 8 giungo 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.
Leonello Servoli - Otranto CCR 8 giungo 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.
Leonello Servoli - Otranto CCR 8 giungo 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
Leonello Servoli - Otranto CCR 8 giungo 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:
Leonello Servoli - Otranto CCR 8 giungo 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 , 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).
Leonello Servoli - Otranto CCR 8 giungo 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.
Leonello Servoli - Otranto CCR 8 giungo 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
Leonello Servoli - Otranto CCR 8 giungo Real1Real2Real3Real4Real5Real6 VM images repository Master Private Switch VM Public Switch Rete privata di controllo Rete pubblica High Availability: Status
Leonello Servoli - Otranto CCR 8 giungo 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)
Leonello Servoli - Otranto CCR 8 giungo 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.