Il progetto High Availability
D. Salomoni - CNAF
L. Servoli - INFN Perugia
L. Servoli - CCR Roma 15 marzo 2005
1
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.
L. Servoli - CCR Roma 15 marzo 2005
2
High Availability: Perchè?
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
L. Servoli - CCR Roma 15 marzo 2005
3
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.
L. Servoli - CCR Roma 15 marzo 2005
4
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;
L. Servoli - CCR Roma 15 marzo 2005
5
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.
L. Servoli - CCR Roma 15 marzo 2005
6
High Availability: Aree di lavoro
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);
L. Servoli - CCR Roma 15 marzo 2005
7
High Availability: Proposta VM
Si propone una soluzione basata su:
-> l'uso di macchine virtuali multiple su singole
macchine fisiche;
-> l'uso di un numero limitato di macchine fisiche;
-> l'esistenza di un sistema di monitoraggio
specifico per i singoli servizi.
L. Servoli - CCR Roma 15 marzo 2005
8
High Availability: Proposta VM
MF1
MF2
Block
Device
X
Server Fisico
MV1
Server Fisico
MV2 MV3
MV1
MV2 MV3
L. Servoli - CCR Roma 15 marzo 2005
9
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.
L. Servoli - CCR Roma 15 marzo 2005
10
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
11
High Availability: Persone
Le persone che hanno espresso interesse sono:
Bari:
Bologna:
CNAF:
Domenico Diacono
drdb + heartbeat
Vincenzo Vagnoni
interesse generale
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: [email protected]
L. Servoli - CCR Roma 15 marzo 2005
12
High Availability: Persone
Ci sono varie competenze già presenti tra le persone che hanno
espresso interesse; in particolare:
- RedHat Cluster Manager:
- Linux Virtual Server:
- Virtual Machine (Xen, qemu):
CNAF, Trieste;
CNAF, Perugia
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.
L. Servoli - CCR Roma 15 marzo 2005
13
High Availability: Attività
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.
L. Servoli - CCR Roma 15 marzo 2005
14