La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Domenico Diacono CNAF 22 Marzo 2006

Presentazioni simili


Presentazione sul tema: "Domenico Diacono CNAF 22 Marzo 2006"— Transcript della presentazione:

1 Domenico Diacono CNAF 22 Marzo 2006
Cluster Linux HA Domenico Diacono CNAF 22 Marzo 2006

2 Argomenti Descrizione cluster HA Esperienze in produzione Pro e contro

3 Il funzionamento in breve
LAN Collegamento alla LAN DRBD0 Partizione dedicata al cluster su device RAID 5 EIDE (o SATA) DRBD0 Spazio disco replicato sul secondo nodo Servizi in HA caso DNS: DRBD IP Named Mon Webmin DNS La slide verrà spiegata a voce RELAY Seriale Secondo servizio su un’altra parti- zione condivisa DRBD1 DRBD1 Channel bonding Collegamento interno tra i due nodi, via ethernet e seriale

4 Il funzionamento in breve
LAN DRBD0 DRBD0 DNS La slide verrà spiegata a voce RELAY Seriale DRBD1 DRBD1 Channel bonding

5 Lo spazio disco: DRBD Distributed Replicated Block Device (DRBD)
Protocollo C: il segnale di conclusione dell'operazione di I/O sul nodo primario viene inviato al SO operativo solo quando il nodo secondario comunica di aver terminato la sua operazione di scrittura, quando cioè i dati sono stati fisicamente replicati (Mirror via rete) /proc/drbd

6 Lo spazio disco: LVM Logical Volume Management
filter = [ "a/drbd.*/" , "r/.*/" ] types = [ "drbd", 16 ] Permette, montato su DRBD, di ottenere le “snapshot” per il backup del sistema. Su LVM si crea il filesystem.

7 Lo spazio disco: Channel Bonding
Due interfacce di rete agiscono come una sola interfaccia, in questo caso duplicando il segnale su due cavi: fault-tolerance (broadcast) /usr/src/linux/Documentation/network/ifenslave.c /proc/net/bonding/bond0 Questa connessione è vitale.

8 Lo spazio disco: il filesystem
Molto tempo perso inutilmente per i test di performance. DRBD introduce un certo overhead, quantificabile in circa 30% in scrittura, su ext3. MA con una mailbox di prova l'apertura via web-mail della INBOX con 4000 mail necessita, dal login alla visualizzazione della prima pagina di 25 sec con Ext3, 2 sec con XFS, 4 sec con JFS e 3 sec con Reiserfs.

9 Gestione del cluster: Heartbeat
Controlla lo stato fisico delle macchine ma non dei servizi. In caso di failure sposta un resource group Es: poffice2 drbddisk::mail lvm Filesystem::/dev/mail0::/mail0::xfs IPaddr:: /24/eth3 postfix saslauthd cyrus stunnel2 apache2 mailman imapproxy mon stunnelgate Pericolo Split-Brain: STONITH? Canali di comunicazione ridondati: 3(+1) sul DNS, 5(+1) sul server imap

10 Gestione del cluster: IpFail
Tecnicamente un plugin di Heartbeat. Controlla la raggiungibilità dell’host attraverso la interfaccia pubblica. Il resource group vien migrato se l’host esterno non viene più visto E il nodo secondario ha un ping count maggiore. In situazioni “estreme” può sbagliare.

11 Installare i servizi Creare dal nodo primario una directory nel device DRBD+LVM che contenga i file di configurazione e dati del servizio. Ad esempio: cp -a /etc/postfix /mail0/etc/postfix. Eliminare la directory di configurazione originale e sostituirla con un softlink alla directory condivisa.

12 Monitor dei servizi: MON
Un servizio può bloccarsi anche se la macchina funziona. MON è molto flessibile. Ad esempio sui miei cluster tenta prima il riavvio, poi sposta il resource group. E’ possibile monitorare separatamente i vari servizi che compongono il resource-group, e cambiare l’azione da intraprendere a seconda del nodo sul quale si trovano.

13 MON watch serviziCritici service smtp_check interval 15s
monitor smtp3.monitor -t 70 -T 30 period wd {Sun-Sat} hr {0-23} alertafter 3 alert mail.alert -S "Attenzione! postfix non risponde" alert postfixError.alert service smtp_takeover interval 120s alertafter 3 30m numalerts 1 alert mail.alert -S "Attenzione! postfix non risponde ancora: lo migro!" alert postfixTakeover.alert watch serviziSecondariImap service imap_check interval 2m monitor imap.monitor alertevery 10m alert mail.alert -S "Attenzione! Cyrus-imap non risponde" alert imapError.alert

14 Pros and Cons PROS: Facile da installare e FUNZIONA! 
La manutenzione delle macchine è enormemente semplificata Costa poco (anche niente se AA). Nessuna modifica del kernel CONS: Scarsa scalabilità: progettazione critica Necessaria molta attenzione nell’allineare le due macchine. Nessun isolamento dei servizi

15 RIFERIMENTI http://www.ba.infn.it/calcolo/documenti/Cluster.html


Scaricare ppt "Domenico Diacono CNAF 22 Marzo 2006"

Presentazioni simili


Annunci Google