Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
1
L. Servoli - CCR Roma 15 marzo 20051 Il progetto High Availability D. Salomoni - CNAF L. Servoli - INFN Perugia
2
L. Servoli - CCR Roma 15 marzo 20052 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.
3
L. Servoli - CCR Roma 15 marzo 20053 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
4
L. Servoli - CCR Roma 15 marzo 20054 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.
5
L. Servoli - CCR Roma 15 marzo 20055 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;
6
L. Servoli - CCR Roma 15 marzo 20056 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.
7
L. Servoli - CCR Roma 15 marzo 20057 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);
8
L. Servoli - CCR Roma 15 marzo 20058 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.
9
L. Servoli - CCR Roma 15 marzo 20059 High Availability: 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
10
L. Servoli - CCR Roma 15 marzo 200510 High Availability: 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 e distribuirla su tutte le macchine. Vantaggi:
11
L. Servoli - CCR Roma 15 marzo 200511 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.
12
L. Servoli - CCR Roma 15 marzo 200512 High Availability: Persone 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
13
L. Servoli - CCR Roma 15 marzo 200513 High Availability: Persone 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.
14
L. Servoli - CCR Roma 15 marzo 200514 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.
Presentazioni simili
