Alta disponibilità e Disaster Recovery Discussione sugli strumenti attualmente in uso e possibili prossime evoluzioni WS CCR 27/5/2013 S.Zani

HA e Disaster Recovery Per riuscire a costruire Servizi in modo da essere altamente disponibili ed in grado di resistere a situazioni di “Disastro” occorre: Replicare su più di una sede dati ed application server. Costruire le procedure necessarie alla attivazione dei servizi nelle sedi secondarie ed al setup delle infrastrutture necessarie a presentare sempre all’utente l’istanza disponibile del servizio. Ovviamente si dovrà ripristinare il servizio nella sede “Master” una volta risolti i problemi che ne hanno comportato la migrazione. WS CCR 27/5/2013 S.Zani

Replica geografica Per la replica dei dati si possono utilizzare tecniche diverse: 1.Sistemi di storage che forniscano nativamente la funzionalità di replica geografica a livello di “Blocco” :EMC MirrorView, NetApp SnapMirror, Dell Equallogic Snapsot & CommVault 2.Utilizzando script personalizzati e strumenti gratuiti come per esempio rsync (in questo caso la replica potrà essere solo asincrona). 3.Utilizzando Filesystem distribuiti che consentano la replica geografica (Es. GlusterFS, GPFS.. ). Per la replica di DB occorre tenere conto del fatto che una replica brutale a livello di blocco non garantisce la consistenza del DB e quindi per ogni DB si dovranno utilizzare strumenti di replica specifici. WS CCR 27/5/2013 S.Zani

DNS HA Un componente fondamentale per una efficiente gestione di servizi in replica geografica è la disponibilità di una struttura DNS distribuita ed aggiornabile dinamicamente. I server sono stati acquistati e collocati a Bologna e Roma1. A livello prototipale il sistema è gia stato testato e garantisce la piena funzionalità in modalità mutimaster (con possibilità di modifica delle entry anche durante l’ipotetico “Down” di una delle due sedi ospitanti i DNS) WS CCR 27/5/2013 S.Zani

WS CCR 27/5/2013 DNS HA architecture (multimaster) Riccardo Veraldi infn.it server2.infn.it ns1.ha.infn.it ha IN NS ns1.ha.infn.it ha IN NS ns2.ha.infn.it ns1.ha.infn.it ns2.ha.infn.it x.y host IN CNAME host.ha.infn.it. ha IN NS ns1.ha.infn.it ha IN NS ns2.ha.infn.it ns1.ha.infn.it ns2.ha.infn.it x.y host IN CNAME host.ha.infn.it. probe Master instance at INFN ROMA1 Master instance at CNAF ns2.ha.infn.it host 60 IN A 193.x.y.z host 60 IN A a.b host 60 IN A 193.x.y.z host 60 IN A a.b nsupdate

HA DNS multimaster WS CCR 27/5/2013 In generale I servizi nazionali (host.infn.it) saranno replicati a livello geografico in almeno due siti, per esempio: CNAF e Frascati. Il sottodominio ha.infn.it è implementato con una architettura multimaster in due sedi differenti CNAF e ROMA1 –Si è impostata una delega su server2.infn.it (il DNS primario per infn.it) definendo ns1.hs.infn.it ed ns2.ha.infn.it come autoritativi per il dominio ha.infn.it. Gli hostname dei servizi da gestire in modalità HA sono definiti come CNAME che puntano agli hostname definiti nel dominio ha.infn.it. I nomi definiti su ns1.ha.infn.it ed ns2.infn.it puntano all’indirizzo IP di una delle istanze del servizio (quella master) con TTL settato a 60. Un server nagios (installato nella sede che ospita ns2.ha.infn.it) verifica tramite probe lo stato delle diverse istanze dei servizi ospitate su server distinti. –Se il server primario non risponde al probe, nagios provoca una procedura di update per modificare l’indirizzo IP su ns2.ha.infn.it o su ns1.ha.infn.it se il primo non fosse raggiungibile in modo da puntare alla istanza attiva del servizio. Per l’utente, utilizzando lo stesso CNAME definito su server2.infn.it il servizio sarà sempre raggiungibile nella sede nella quale è realmente attivo. S.Zani

Limiti di BIND9 BIND9 – Legge i dati da un file di testo. Questo rende molto semplice fare errori in fase di editing rischiando di renderlo illeggibile da BIND. – Mantiene in RAM tutti i dati del DNS e se il DNS in questione è autoritativo per molte zone, potrebbe essere necessario ricompilare il kernel in modo da soddisfare le esigenze di RAM – All’avvio, BIND “Carica” tutti i file relativi a tutte le zone e questa operazione può impiegare anche parecchio tempo. – Ogni volta che si cambiano delle informazioni all’interno delle zone, occorre fare ripartire BIND perché le modifiche abbiano effetto. – Non supporta architetture Multimaster WS CCR 27/5/2013 S.Zani

BIND-DLZ (Dynamically Loadable Zones) BIND-DLZ è una patch per BIND9 – Permette di registrare i dati all’interno di un database PostgreSQL MySQL Berkeley DB ODBC LDAP FS hierarchical structure – Le modifiche sul DB hanno effetto immediato sulle risposte di BIND alle query DNS (non è necessario fare ripartire BIND) – Carica le zone dinamicamente all’occorrenza – E’ molto flessibile.. Si possono avere zone gestite in maniera standard e zone configurate come DLZ semplicemente indicandolo nel file named.conf WS CCR 27/5/2013 S.Zani

BIND-DLZ + MySQL CNAF ROMA1 mysql ns1.ha.infn.it ns2.ha.infn.it bind-dlz MySQL circular replicationmaster1/slave2master2/slave1 WS CCR 27/5/2013 S.Zani

Istituzione del Gruppo DR COMPONENTI : Sandro Angius Claudio Bisegni Massimo Donatelli Claudio Galli Guido Guizzunti Dael Maselli Massimo Pistoni Claudio Soprano Riccardo Veraldi Stefano Zani + Collaborazione di Nunzio Amanzi WS CCR 27/5/2013 A fine luglio dello scorso anno è stato costituito un gruppo che si deve occupare di implementare soluzioni di disaster recovery per I servizi fondamentali dell’Ente. Quali sono i servizi informatici di base “Strutturali” per il funzionamento dell’Ente? DISTRIBUITO + replica geografica (By design) DISTRIBUITO + Mail Relay DNS MAILING AAI AAI DB GODIVA Sistema Informativo Contabilità (CNAF) Portale Missioni (CNAF) Gestione Presenze (CNAF) Stipendiale (LNF) Documentale (LNF) Protocollo (LNF) Business Intell. (CNAF) DR S.Zani DR

FASE 0: Replica dei “dati” dei servizi strutturali (permette in caso di disastro almeno di recuperare i dati per un successivo ripristino nella sede originale) – Ultimata Vista la varietà delle piattaforme (Dai sistemi operativi alle versioni di DB ecc.) Si è scelto di utilizzare script basati su strumenti “Standard” (shell + rsync) che permettano di recuperare i DATI in caso di “Disastro” SENZA TROPPE DIPENDENZE da altri servizi o condizioni al contorno. STATO ad oggi: REPLICHE GEOGRAFICE DEI BACKUP (Al giorno precedente) [Master  Sito di Backup] CNAF DB (Contabilità, Presenze, B.I.) [CNAF  LNF] CNAF App. Server (Contabilità, Presenze, Missioni) [CNAF  LNF] LNF DB+App. Server (Stipendiale, Documentale, Protocollo da Solaris[LNF  CNAF] Si è realizzato un sistema in grado di conservare i backup remoti per qualche giorno in modo da gestire eventuali repliche automatiche di dati corrotti. WS CCR 27/5/2013

FASE 1: Sincronizzazione dei DB, degli applicativi e definizione delle procedure per la riattivazione dei servizi nella sede secondaria Replica dei DB: L’unico strumento certificato da Oracle per la replica sincrona dei propri database è DataGuard ma data la disomogeneità delle versioni di Oracle in uso non è possibile procedere immediatamente alla replica di tutti I DB. LNF sta ultimando la migrazione dei suoi db su di un Oracle Database Appliance (Soluzione proprietaria Oracle che però dovrebbe permetterci comunque di utilizzare DataGuard) Appena il sistema sarà in produzione si procederà alla “Messa in SYNC” dei primi DB (In verde), successivamente gli altri. – BI(11g) CNAF  LNF(Subito) – DB presenze (11g) CNAF  LNF (Subito) – GODIVA (11) LNF  CNAF (Appena realizzati i test da RAC a singola istanza di Standby) – Contabilità (10) CNAF  LNF (Quando verrà aggiornato il DB) – Stipendiale e documentale (9 su solaris) LNF  CNAF (Non si prevede di replicare fino alla migrazione a CEZANNE e DB su ODA) WS CCR 27/5/2013 S.Zani

Replica APPS: Per la replica degli application server, occorre caso per caso realizzare una copia delle macchine virtuali o mantenere in sync macchine reali gemelle di quelle in produzione. – RSYNC (In produzione ora) – Creazione di un volume in replica geografica con Gluster 3.4 Beta in fase di test (Segnalo la collaborazione con Alessandro De Salvo che ha già esperienza nell’utilizzo di GlusterFS + Pacemaker per la ridondanza di servizi di Atlas a livello locale ed ha iniziato una attività di replica fra Roma1 e Napoli) Sviluppi futuri: Una volta in sync i DB Oracle e replicati Gli App servers potremo definire le le procedure manuali per la “Migrazione” dei servizi fondamentali. Successivamente e per le applicazioni che lo consentiranno, proveremo ad utilizzare gli strumenti di clustering opportuni in modo da gestire la migrazione automatica dei servizi. Si sta valutando la possibilità di utilizzare una VLAN estesa su rete geografica (mediante VPN l3) in modo da utilizzare di fatto una rete condivisa fra due sedi su cui ospitare gli application server in modo da realizzare una replica sincrona fra le due sedi. Questa soluzione non verrà utilizzata in produzione qualora non si dimostri solida ed affidabile. WS CCR 27/5/2013

Considerazioni generali E’ auspicabile la riduzione del numero dei DB ed è necessaria la convergenza su di una unica versione. (In corso) Oltre ad individuare strumenti “Solidi” per la replica degli “Environment” fra sedi differenti, occorre da ora in poi concepire i servizi per essere “Ridondati su più sedi”. Per quelle applicazioni che hanno una reale necessità di “Continuità di Servizio” con tempi di ripristino molto bassi, occorre scegliere opportunamente le sedi gemelle in modo che vi sia personale con competenze sui servizi ospitati perchè un sistema non è realmente ridondante se la conoscenza del funzionamento dello stesso è prerogativa di una sola persona (soprattutto con i tempi che corrono). WS CCR 27/5/2013 S.Zani

Punti di discussione Chi di voi ha sperimentato soluzioni che potrebbero essere utilizzate in ambito di DR ? – Chi è interessato alla attività di sperimentazione finalizzata a questo scopo? Si è accennato ad una possibile attività per definire semplici strumenti di DR per i mail server delle varie sedi cha a coppie potrebbero offrire da backup l’una dell’altra. Potrebbe essere una attività che partendo dalle esperienze fatte sino ad ora porti alla adozione di script e procedure “Standard” per i backup in geografico? WS CCR 27/5/2013

FINE WS CCR 27/5/2013 S.Zani

BACKUP SLIDES WS CCR 27/5/2013

Componenti del Sistema informativo installati al CNAF da replicare a Frascati Contabilità: 2 Macchine Fisiche Capacità: (300GB+300GB) Gestione Presenze : 2 VM Capacità: (100GB+12GB) Portale Utente (Missioni): 1 VM Capacità: 10 GB Lo spazio disco necessario ai LNF per ospitare I DB dei servizi di base e le VM necessarie è stimato in 1TB (considerare 2TB per margine) WS CCR 27/5/2013

Componenti del Sistema informativo installati a Frascati da replicare al CNAF Stipendiale (HR) Documentale Protocollo 1 SUN Capacità 500 GB GODIVA (AAI) 2 VM Capacità 300 GB Lo spazio disco al CNAF per ospitare i DB dei servizi di base e le VM necessarie è stimato in 1TB (considerare 2TB per margine) SXGEST 2 Prevista (entro fine anno?) sostituzione di SXGEST2 con una installazione dell’applicativo CEZANNE Non sono ancora noti dettagli della implementazione ma si baserà su di un DB Oracle della dimensione di circa 500/600 GB WS CCR 27/5/2013