High Avaliability with RHCS HA INFN CNAF 22 Marzo 2006 Bologna Ricci Pier Paolo, on behalf of INFN TIER1 Staff

Presentazione sul tema: "High Avaliability with RHCS HA INFN CNAF 22 Marzo 2006 Bologna Ricci Pier Paolo, on behalf of INFN TIER1 Staff"— Transcript della presentazione:

1 High Avaliability with RHCS HA INFN CNAF 22 Marzo 2006 Bologna Ricci Pier Paolo, on behalf of INFN TIER1 Staff pierpaolo.ricci@cnaf.infn.it

2 Switch FC Power Supply 220V LAN 2 Dell 1650 2GB RAM servers Connection to LAN Eth0 Heartbeat Eth1 crosslink APC Master Switch Controller AP9224 Remote Power on/off Using IP Quorum disk Cluster RedHat A.S. 2.1 2 Storage disks 2 + 2 TB (CDF AMS) Qlogic "persistent binding" used to lock different devices to the same SCSI ID (/dev/sdX) on the OS 2 nodi in cluster con eth1 IP heartbeat e un “quorum disk” (MAX 2 nodi con la 2.1) Ogni servizio “clustered” ha il suo indirizzo IP associato (IP alias) Si ha alta affidablità solo su un singolo servizio ma e’ possibile una configurazione “active/active” su servizi differenti (che possono essere anche 2 nfs con IP e mountpoint separati) E’ stato provato con successo con I servizi NFS e Oracle (NFS in produzione per circa 1 anno). Le operazioni di mount/dismount vengono forzate automaticamente usando la SAN per accedere ai volumi. E’ stato necessario “Patchare” l’agente stonith (Shot The Other Node In The Head) per forzare il powroff utlizzando le presiere controllabili via IP di APC. Hardware watchdog instabile, software watchdog insufficente Subscription a redhat necessarie per aggiornamento (1KEuro/anno per nodo) acquistato 1.

3 2 Switch FC Power Supply 4 Diskserver Supermicro Main Services storage partitions IBM FastT900 (DS4500) Cluster RedHat A.S. 3.0 4 nodi in cluster con “quorum disk” (MAX 8 nodi con la 3.0) E’ stato provato in produzione con i servizi NFS e rfiod per circa 6 mesi a fine 2004. La versione testata dava problemi di stabilità nella rilocazione dei servizi, capitava di avere lo stesso fs montato su più nodi! (pericolo di fs corruption). Livello di supporto e possibilità di debugging bassa (log poco verbosi, non c'erano parametri di tuning) Subscription a redhat necessarie per aggiornamento (1KEuro per nodo) non sono state rinnovate Le nuove presiere di APC famiglia 79XX non erano presenti nello stomith/fencing (Shot The Other Node In The Head) per forzare il reboot utlizzando le presiere controllabili via IP di APC. Sarebbe stato necessario effettuare di nuovo il patch LAN Quorum partition Supported layout (quorum on the same hardware device) APC AP7951 Remote Power on/off Using IP HeartBeat via Tierbreaker IP sul gateway

4 Cluster RedHat A.S. 3.0 Update Training e confronto effettuato con RedHat Italia (Milano) 2 settimane fa La nuova versione del cluster per RH AS/ES 3.0 Update 6 (versione 1.2.28-1 del cluster-manager e versione 1.0.8-1 del redhat-config-cluster) sembrano molto più stabili di quelle installate in preproduzione a fine 2004 (v. 1.2.9-1 e v.1.0.1-4) Il codice dello stomith/fencing sembra includere le nostre presiere APC famiglia 79XX dalla 1.2.21 (anche se la matrice di certificazione non le cita) Il codice degli update è legalmente usabile se 1. Ricompilato dai src rpm con la rimozione dei loghi redhat. RedHat visto che si tratta di codice GPL deve rilasciare i source rpm (ftp://ftp.redhat.com) 2. Si utilizzano gli rpm ricompilati dal Cern distribiti con gli update della Scientific Linux Cern 3. Si rinuncia al supporto RedHat E' importante riprovare ad installare su macchine di produzione gli update più recenti rilasciati dei 2 rpm e effettuare test approfonditi per verificare i miglioramenti. In ogni caso il cluster ovviamente diventa un vantaggio SOLO se stabilizzato completamente, ovvero se l'introduzione del cluster in produzione non crea più problemi e un aumento dei MTBF (mean time between failure) rispetto ad avere macchine singole separate. Questo è verifcabile solo entro un consistente intervallo temporale

5 Cluster RedHat A.S. 4.0 Training e programmato con RedHat Italia (Milano) per Maggio Non si utilizzerà più il "quorum disk" ma il quorum viene effettuato usando le seconde interfaccie di rete delle macchine su una LAN/switch separato Codice riscritto da C a perl e altro. Strettamente collegato con GFS (ex. prodotto Sistina, Sistina è stata acquisita da RedHat). rpm nettamente aumentati e cambiati Il fencing include metodi meno drastici del poweroff dei nodi falliti (come la chiusura di porte FC sugli switch), l'hardware certificato nella tabella di certificazione sembra limitato ma l'unico metodo è provarlo sul nostro hardware Se si utilizza GFS è possibile usare tale clustered filesystem come layer su cui fare partire i servizi (e quindi usare modalità active/active sullo STESSO servizio da PIU' NODI)