Il progetto High Availability

1. D. Salomoni - CNAF L. Servoli - INFN Perugia Il progetto High Availability L. Servoli - CCR Roma 15 marzo 2005

2. 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. High Availability: Perchè? L. Servoli - CCR Roma 15 marzo 2005

3. Una prima soluzione: Ridondanza delle macchine fisiche. 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 High Availability: Perchè? L. Servoli - CCR Roma 15 marzo 2005

4. 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. High Availability: Perchè? L. Servoli - CCR Roma 15 marzo 2005

5. 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; High Availability: Perchè? L. Servoli - CCR Roma 15 marzo 2005

6. 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. High Availability: Perchè? L. Servoli - CCR Roma 15 marzo 2005

7. Il progetto si propone di studiare diverse soluzioni possibili, e di verificare quali siano le più adatte alle varie esigente: -> uso di Redhat Cluster Suite; -> uso di Linux Virtual Server; -> uso di Macchine Virtuali (Xen, qemu); High Availability: Aree di lavoro L. Servoli - CCR Roma 15 marzo 2005

8. Si propone una soluzione basata su: -> l'uso di macchine virtuali multiplesu singole macchine fisiche; -> l'uso di un numero limitato di macchine fisiche; -> l'esistenza di un sistema di monitoraggio specifico per i singoli servizi. High Availability: Proposta VM L. Servoli - CCR Roma 15 marzo 2005

9. High Availability: Proposta VM MF1 MF2 Block Device X Server Fisico Server Fisico MV2 MV3 MV2 MV3 MV1 MV1 L. Servoli - CCR Roma 15 marzo 2005

10. L. Servoli - CCR Roma 15 marzo 2005 High Availability: Proposta VM Vantaggi: • 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 e distribuirla su tutte le macchine.

11. High Availability: Proposta VM Le attività previste per la parte di VM con XEN sono: - Test di compatibilità tra kernel XEN e varie distribuzioni. - Test di caricamento di domU via Block Device Remoti (GNDB, iSCSI, FC). - Test di caricamento di domU via filesystem remoti (NFS). - Test di caricamento di domU via filesystem distibuiti (GFS, GPFS). - Test su uso di partizioni locali, remote o mix delle due. - Monitoraggio dello stato delle Macchine Virtuali. - Installazione di servizi, sia GRID che non-GRID. L. Servoli - CCR Roma 15 marzo 2005

12. Le persone che hanno espresso interesse sono: Bari: Domenico Diacono - drdb + heartbeat Bologna: Vincenzo Vagnoni - interesse generale CNAF: Davide Salomoni, altri - Coordinatore Progetto Redhat Cluster Manager, Linux Virtual Server, interesse generale Genova: Alessandro Brunengo - resp. Storage Group Perugia: Leonello Servoli, Mirko Mariotti, Massimo Mongardini - Xen, Linux Virtual Server Roma1: Alex Barchiesi, Alessandro Spanu, Marco Esposito - interesse generale Torino: Federico Nebiolo - Xen, qemu Trieste: Alessandro Tirel, Roberto Gomezel - Redhat Cluster Manager Mailing list: ha@cnaf.infn.it High Availability: Persone L. Servoli - CCR Roma 15 marzo 2005

13. Ci sono 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 Inoltre occorrerà interfacciarsi con A. Brunengo ed il Gruppo Storage. Ci sono stati alcuni scambi di opinioni su singoli argomenti e una riunione su Xen l' 8 marzo al CNAF. È prevista una riunione generale il 22 marzo al CNAF per definire nel dettaglio le attività previste. Se ci sono altri interessati ( purchèseriamente intenzionati a contribuire), contattare direttamente D. Salomoni. High Availability: Persone L. Servoli - CCR Roma 15 marzo 2005

14. Obbiettivi: entro maggio: - avere un prototipo funzionante per la proposta VM; - avere una prima valutazione delle diverse soluzioni e dei loro ambiti di applicabilità; entro settembre: - Soluzioni HA di produzione implementate per il Tier-1 per testarle 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 anche eventualmente per servizi di genere diverso dal computing di LHC. High Availability: Attività L. Servoli - CCR Roma 15 marzo 2005