Disaster Recovery Resoconto delle attività del Gruppo di Lavoro DR CCR CNAF 5-7/2/2013 S.Zani.

Presentazione sul tema: "Disaster Recovery Resoconto delle attività del Gruppo di Lavoro DR CCR CNAF 5-7/2/2013 S.Zani."— Transcript della presentazione:

1 Disaster Recovery Resoconto delle attività del Gruppo di Lavoro DR CCR CNAF 5-7/2/2013 S.Zani

2 Componenti e Riunioni 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 Riunioni (Tele) effettuate: 26/7/2012 13/9/2012 16/10/2012 21/11/2012 17/1/2012 28/1/2012 CHIUNQUE FOSSE INTERESSATO A CONTRIBUIRE E’ IL BENVENUTO! CCR CNAF 5-7/2/2013

3 Quali sono i servizi informatici di base “Strutturali” per il funzionamento dell’Ente? 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) DISTRIBUITO + replica geografica (By design) DISTRIBUITO + Mail Relay (in caso di failure di un sito) REPLICATO DR CCR CNAF 5-7/2/2013 DR

4 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) – Quasi ultimata Vista la varietà delle piattaforme (Dai sistemi operativi alle versioni di DB ecc.) Si è scelto di utilizzare script basati su strumenti “Standard” e che permettano di recuperare i DATI in caso di “Disastro” SENZA TROPPE DIPENDENZE da altri servizi o condizioni al contorno. RSYNC: Multipiattaforma Non dipende da “cataloghi o server esterni” per funzionare Cifra I dati durante la copia Copie incrementali (trasferisce solo gli aggiornamenti) STATO ad oggi: REPLICHE GEOGRAFICE DEI BACKUP (Al giorno precedente) [Master  Sito di Bkup] CNAF DB (Contabilità, Presenze, B.I.) [CNAF  LNF] CNAF App. Server (Contabilità, Presenze, Missioni) [CNAF  LNF] LNF DB+App. Server (Stipendiale, Documentale, Protocollo da Solaris9) [LNF  CNAF] (Da concludere la validazione degli script su spazio in allocazione) CCR CNAF 5-7/2/2013

5 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 migrando i 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) CCR CNAF 5-7/2/2013

6 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 (Ora) – Utilizzo di Filesystem distribuiti che consentano di mantenere allineati in tempo reale determinati “volumi” su scala geografica (GLUSTER-FS,GPFS ?) (Attività da sviluppare) – AFS (replica della cella di LNF.. Da investigare) – EMC Mirror View (Possibile ma limitato a storage EMC + costo licenza) Possibili sviluppi futuri: Potrebbero venirci incontro soluzioni più eleganti per la replica degli application server con l’ evoluzione dei sistemi di gestione degli ambienti di virtualizzazione in ambito “Cluod”. CCR CNAF 5-7/2/2013

7 Considerazioni generali E’ auspicabile la riduzione del numero dei DB ed è necessaria la convergenza su di una unica versione. 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 piu 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 è prerogtiva di una sola persona (soprattutto con i tempi che corrono). CCR CNAF 5-7/2/2013

8 FINE CCR CNAF 5-7/2/2013

9 BACKUP SLIDES CCR CNAF 5-7/2/2013

10 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) CCR CNAF 5-7/2/2013

11 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 CCR CNAF 5-7/2/2013