Disaster Recovery e Business Continuity Seminario generale sulle architetture e sulle tecnologie adottate nelle soluzioni di Disaster Recovery e Business Continuity Maggio 2008
Disaster Recovery e Business Continuity
Seminario generale sulle architetture e sulle tecnologie adottate nelle soluzioni di Disaster Recovery e Business Continuity
Maggio 2008
Calogero Gandolfo
Responsabile Architetture e Standard Sistemi Mainframe e Soluzioni di
Continuità Aziendale
Maggio 2008
33
10/06/200810/06/2008
Il programma di questo seminario
Introduzione:
Terminologia e Standard
Normative Internazionali
I fondamenti del Disaster Recovery e della Business Continuity:
Panoramica delle soluzioni disponibili
Descrizione delle tecnologie abilitanti
I piani e le procedure organizzative
La soluzione adottata da Poste Italiane per i sistemi di Bancoposta:
Il progetto
La implementazione
La gestione
Indice degli argomenti
44
10/06/200810/06/2008
Il programma di questo seminario
Introduzione:
Terminologia e Standard
Normative Internazionali
I fondamenti del Disaster Recovery e della Business Continuity:
Panoramica delle soluzioni disponibili
Descrizione delle tecnologie abilitanti
I piani e le procedure organizzative
La soluzione adottata da Poste Italiane per i sistemi di Bancoposta:
Il progetto
La implementazione
La gestione
Indice degli argomenti
55
10/06/200810/06/2008
Il Disaster Recovery
Quale Danno al Business Aziendale può derivare dall’indisponibilitàprolungata delle Applicazioni e/o dalla perdita dei Dati Aziendali?
Il Disaster Recovery (DR) è l'insieme di…
…Tecnologie e Processi predisposti per ripristinare le …
…Applicazioni e i Dati necessari all'erogazione dei…
… Servizi di Business, interrotti a seguito di…
…Gravi Eventi Dannosi (Disastri). LocalitàApplicazioni
Tecnologie
Processi
Dati
Organizzazione
66
10/06/200810/06/2008
Business Continuity e Disaster Recovery
Business Continuity Management è un processo strategico e tattico che permette
ad un'organizzazione di avere una risposta a qualunque avvenimento e interruzione
del Business che può avere impatto sui processi aziendali che contribuiscono al
“core business” dell'azienda, garantendo un livello di servizio minimo accettabile
predefinito.
Disaster Recovery è l'insieme di processi e tecnologie atti a ripristinare sistemi, dati
e infrastrutture necessarie all'erogazione di servizi “core business” a fronte di gravi
emergenze (disastri).
77
10/06/200810/06/2008
Disastro
Un disastro è la conseguenza dell’attuarsi di una minaccia non dovuta ad
una aggressione intenzionale
1. Disastri naturali: terremoto,alluvione, tornado, eruzione vulcanica
2. Disastri dovuti all’uomo e alla tecnologia: incendio,esplosione, rottura
delle condutture dell’acqua,mancanza di corrente, di linee di
telecomunicazioni e di condizionamento ambientale
Le cose che non speri accadono più spesso di quelle che speri.Plauto( 245-184 A.C.), Mostellaria
Se una cosa può andare storta, lo faràAssioma di Murphy
88
10/06/200810/06/2008
Alcuni termini ricorrenti
Rischio: esposizione di una organizzazione a perdite o danni.
Risultato della combinazione della probabilità del verificarsi di un evento e
dell’impatto(gravità) prodotto dall’evento stesso
Minaccia: è l’elemento che rappresenta un pericolo per l’organizzazione
Vulnerabilità: una debolezza nota nel sistema rispetto a una minaccia
Attacco : tentativo deliberato di creare un danno ( es. attacco informatico,
attacco terroristico)
99
10/06/200810/06/2008
Standard BS7799/ISO17799/ISO27002
BS7799 e ISO17799 sono lo Standard per le politiche e le procedure di
Sicurezza delle informazioni
Lo standard è stato inizialmente conosciuto come standard inglese
BS7799 pubblicato dal British Standards Institution(1995)
Più tardi (2000) con diverse revisioni è stato adottato dal comitato tecnico
internazionale ISO IEC diventando ISO17799 (Information Technology-
Code of practice for information security management)
Di recente lo standard ISO17799 è stato rivisto ulteriormente ed è
diventato ISO27002 (Luglio 2007)
ISO: International Organization for Standardization
IEC: International Electrotechnical Commission
1010
10/06/200810/06/2008
Standard BS7799/ISO17799/ISO27002
Lo standard fa esplicito riferimento alla Business Continuity
Business Continuity (BS7799):
To counteract interruptions to business activities and to protect crtitical
business processes from the effects of major failures or disaster
1111
10/06/200810/06/2008
Standard BS7799/ISO17799/ISO27002
A differenza di altri standard più tecnologici, l’approccio di tale standard è
di tipo organizzativo e si rivolge ai livelli più alti della organizzazione, a
coloro, cioè, che sono in grado di prendere le decisioni.
Lo standard è una ‘guida’ per l’organizzazione verso una profonda
conoscenza dei propri processi, flussi informativi e sistemi a supporto del
business
Vengono indicate delle best practices per l’attivazione dei controlli che
l’organizzazione deve implementare, sia dal punto di vista organizzativo
che tecnologico, per poter realizzare un processo di messa in sicurezza
dei sistemi che hanno il maggior peso nella generazione del valore
1212
10/06/200810/06/2008
Standard BS7799/ISO17799/ISO27002
I principali controlli che vengono presi in considerazione relativamente alla
Business Continuity sono :
• il processo di gestione della Business Continuity
• l’analisi di impatto sulle attività dell’azienda
• la redazione e la implementazione dei piani di Business Continuity
• il monitoraggio, il testing e la revisione dei piani di Business Continuity
1313
10/06/200810/06/2008
Standard BS25999
La rilevanza assunta recentemente dalle problematiche relative aI
processo di gestione della Business Continuity ha portato alla
pubblicazione di uno standard specifico:
BS25999
Tale standard è composto da due parti :
BS25999-1:2006 Business Continuity Management. Code of practice
BS25999-2:2007 Specification for Business Continuity Management
La prima parte rappresenta una guida generale e stabilisce processi,
principi e terminologia per la gestione della Business Continuity.
La seconda parte specifica i requisiti per implementare, gestire e
migliorare un sistema documentato di Business Continuity Management
(BCMS)
1414
10/06/200810/06/2008
NIST
Da un punto di vista più tecnologico il NIST(National Institute of Standards
and Technology) ha redatto delle raccomandazioni che forniscono
indicazioni e strategie relativamente ai seguenti tipi di sistemi:
• Desktop e portatili
• Server
• Siti WEB
• LAN/WAN
• Sistemi Distribuiti
• Mainframe
1515
10/06/200810/06/2008
NIST
Il documento del NIST(Contingency Planning Guide for Information
Technology Systems) fornisce le linee guida per la predisposizione del
contingency plan per i sistemi informativi
Il contingency plan si riferisce alle misure da applicare durante il verificarsi
di una emergenza per ripristinare al più presto le funzionalità più rilevanti
dei sistemi informativi
Il NIST identifica i seguenti passi principali:
realizzazione della BIA(Business Impact Analysis)
identificazione dei controlli preventivi
sviluppo delle strategie di recupero
progettazione, testing e esercizio del contingency plan
manutenzione e aggiornamento del piano
1616
10/06/200810/06/2008
NIST
Il NIST identifica le seguenti fasi da seguire nel caso di evento catastrofico:
Attivazione
l’evento si è verificato, è stato rilevato, il personale preposto deve essere
avvertito e i danni prodotti devono essere stimati
Recupero
le azioni che ciascun gruppo preposto deve compiere a fronte dell’evento
rilevato
Ricostituzione
le azioni che devo essere messe in atto per ripristinare la normale
operatività
1717
10/06/200810/06/2008
ITIL
Molte organizzazioni di Information Technology hanno adottato per la
gestione dei servizi la metodologia ITIL
ITIL = Information Technology Infrastructure Library
Creato dalla Central Computer and Telecommunication Agency inglese
(CCTA) e mantenuto dall’Office of Government Commerce
Non è uno standard ma e’ una raccolta di ‘best practices’ per la gestione
dei servizi IT
E’ organizzato in un insieme di volumi adattabili alle esigenze delle
diverse funzioni dell’azienda
Esistono degli organismi in grado di fornire la relativa certificazione sia a
livello individuale sia a livello aziendale
1818
10/06/200810/06/2008
ITIL
Secondo ITIL la gestione dei servizi IT può essere suddivisa in :
Servizi
Supporto Erogazione
1919
10/06/200810/06/2008
ITIL
In relazione alla Business Continuity le sezioni di ITIL di maggior interesse sono :
Servizi
Supporto Erogazione
Gestione incidenti Gestione problemi Continuità di erogazione
2020
10/06/200810/06/2008
Adempimenti di ordine legislativo
Il decreto legislativo n. 196 del 30 Giugno 2003 ‘ Codice in materia di
protezione dei dati personali ’ impone alcune misure di sicurezza dei dati.
In particolare l’allegato B Disciplinare Tecnico in materia di misure minime
di sicurezza indica che deve essere riportata nel Documento
Programmatico della Sicurezza :
…… la descrizione dei criteri e delle modalità per il ripristino della
disponibilità dei dati in seguito a distruzione o danneggiamento …..
E nel caso di dati sensibili o giudiziari:
….. Sono adottati idonee misure per garantire il ripristino dell’accesso ai
dati in caso di danneggiamento degli stessi o degli strumenti elettronici, in
tempi certi compatibili con i diritti degli interessati e non superiori a sette
giorni.
2121
10/06/200810/06/2008
Basilea 2
Con ‘ Basilea 2’ si intende il nuovo accordo internazionale (2001) sui
requisiti patrimoniali delle Banche
Le banche dei paesi aderenti dovranno accantonare quote di capitale
proporzionali al rischio derivante dai vari rapporti di credito assunti
Tra i rischi da prendere in considerazione vi sono anche i rischi operativi
(frodi e indisponibilità sistema informativo)
Le Banche Centrali dovranno vigilare sul rispetto dei criteri previsti
Il Disaster Recovery e la Business Continuity rientrano quindi tra le attività
di adeguamento a Basilea 2
2222
10/06/200810/06/2008
Sarbanes – Oxley Act
Emesso dal governo americano nel 2002 riguarda i controlli che devono
essere presenti nelle aziende quotate sulla Borsa USA
L’intento è quello di garantire la trasparenza e la tracciabilità delle
operazioni compiute, a salvaguardia dei diritti degli azionisti
Anche le aziende italiane quotate a Wall Street devono implementare i
controlli previsti
Sebbene il Disaster Recovery e la Business Continuity non siano citati
esplicitamente è invece chiaro il richiamo alla implementazione dei
backup e alle modalità per il recupero dei dati
2323
10/06/200810/06/2008
Il programma di questo seminario
Introduzione:
Terminologia e Standard
Normative Internazionali
I fondamenti del Disaster Recovery e della Business Continuity:
Panoramica delle soluzioni disponibili
Descrizione delle tecnologie abilitanti
I piani e le procedure organizzative
La soluzione adottata da Poste Italiane per i sistemi di Bancoposta:
Il progetto
La implementazione
La gestione
Indice degli argomenti
2424
10/06/200810/06/2008
Perchè il Disaster Recovery?
Limitare le perdite dovute a riduzione di revenue o ad altri costi
Minimizzare l’interruzione di Processi Business Critical
Soddisfare ai requisiti imposti da obblighi di compliance
Evitare di compromettere la reputazione e la solidità della azienda
Definire dei processi semplificati di decisione e di azione per fronteggiare una situazione imprevista
Preservare le business operations e “sopravvivere” in caso di possibili failures
Prevedere un ritorno “controllato” alla normale operatività
2525
10/06/200810/06/2008
The Business ProblemLa metodologia per la Business Continuity aiuta le aziende nel proteggere il loro business e nell’ottenere la compliance con le leggi internazionali e le regolazioni, riducendo i rischi e migliorando il rapporto prestazioni/costi.
Basilea II è il nuovo accordo sui requisiti
patrimoniali delle banche; è un programma
obbligatorio al fine di ridurre:
Credit Risk. Le banche sono tenute a
immagazzinare in maniera più
strutturata i dati sensibili e storici.
Rischio operativo, che è stato definito
come “il rischio di perdita derivante dai
processi interni inadeguati o in fault,
dalla gente e dai sistemi o dagli eventi
esterni”. La banca deve valutare il loro
grado del rischio operativo.
2626
10/06/200810/06/2008
Prepararsi al Disaster Recovery
Presupposti per rispondere efficientemente ad una situazione di emergenza:
Criteri per riconoscere una Condizione
di “Disastro” e attivare le Politiche
d’Intervento
Conoscenza della Criticità dei Dati, delle
Applicazioni e la loro Priorità
Obiettivi Misurabili per il Ripristino del
Servizio
2727
10/06/200810/06/2008
Prepararsi al Disaster Recovery
Valutare il potenziale danno al business derivante dall’indisponibilità
prolungata delle Applicazioni e/o dei Dati Aziendali.
Pianificare contromisure tecnologiche e organizzative per prevenire o
gestire le Emergenze
Progettare risorse e processi per prevenire e fronteggiare le emergenze
Implementare sistemi e procedure operative di supporto
Eseguire le procedure operative ordinarie di custodia dei Dati e della
Configurazione
Verificare periodicamente e sistematicamente l’efficacia e l’efficienza di
tutte le procedure di gestione delle emergenze
Intervenire sulle Non-Conformità
Pianificare il miglioramento continuo dell’intero sistema
2828
10/06/200810/06/2008
Prepararsi al Disaster Recovery
Non è un intervento “una tantum” ma un Processo Operativo/Gestionale continuo
Non è un Lusso ma una Necessità per l’Azienda
2929
10/06/200810/06/2008
Prepararsi al Disaster Recovery
I requisiti di Business si traducono in requisiti Tecnologici, le cui metriche sono:
RTO (Recovery Time Objective) = esprime in unità di tempo, l’intervallo temporale
ammissibile di indisponibilità dei sistemi in seguito ad un disastro.
RPO (Recovery Point Objective) = esprime in unità di tempo, l’ammontare
massimo di dati che possono essere persi in seguito ad un disastro.
Recovery Time Objective
Recovery Point Objective
Completamento operazioni TransizioneAttivazioneNotificaDati Persi
Failover
3030
10/06/200810/06/2008
Costi e RTO
Costo di indisponibilitàapplicazione OLTP
Costo della soluzione di recovery
Costo di indisponibilitàapplicazione back-office
Costi
GiorniOreMinuti
RTO
3131
10/06/200810/06/2008
RPO e importanza del dato
Anche per il parametro RPO i costi aumentano sensibilmente al diminuire
del suo valore
Esso è associato alla importanza del dato e cioè alla criticità della sua
disponibilità per le applicazioni business critical
Dipende dalla distanza esistente tra i vari Data Center
Esso inoltre dipende dalla struttura organizzativa della azienda e dalla
capacità di recuperare i dati persi attraverso procedure specifiche
In ogni progetto di Disaster Recovery occorre tenere sempre presente che
l’elemento più importante è sempre il dato perché talvolta non
recuperabile
3232
10/06/200810/06/2008
Valutazione RTO e RPO
Da un punto di vista metodologico la modalità largamente adottata per la
determinazione dei parametri RTO e RPO è quella basata su :
Business Impact Analysis (BIA)
Risk Assessment (RA)
3333
10/06/200810/06/2008
Business Impact Analysis
Tecnica per l’identificazione degli asset critici di un determinato processo
di business aziendale
Analizza la criticità degli asset (personale, sedi, strumenti di lavoro,
sistemi IT) in relazione all’impatto sul funzionamento del processo
Valuta le potenziali perdite economiche derivanti dalla interruzione o dal
grave degrado nel funzionamento di un processo
I processi vengono analizzati nella loro completezza (end-to end) tenendo
in considerazione non soltanto gli asset interni ma anche quelli esterni
all’azienda
3434
10/06/200810/06/2008
Business Impact Analysis (Sistemi IT)
In particolare per i sistemi IT costituiscono obiettivi della BIA:
identificazione delle applicazioni business critical e della infrastruttura
tecnologica(Data Center,Linee TLC, server, storage, ecc.) su cui sono
installate
identificazione delle vulnerabilità degli ambienti tecnologici e analisi per le
aree a maggior rischio dei Sigle point of failure(SPOF) e dei
corrispondenti tempi di recupero
3535
10/06/200810/06/2008
Risk Assessment
Il processo di Risk Assessment (RA) non considera soltanto le
vulnerabilità esistenti ma anche le minacce che gravano sui processi critici
e le conseguenze che ne potrebbero derivare
Vengono analizzati i controlli previsti a contenere gli effetti delle minacce
incombenti
I metodi più comunemente utilizzati per eseguire il RA sono due:
metodo quantitativo
metodo qualitativo
3636
10/06/200810/06/2008
Risk Assessment – Metodo quantitativo
Nell’utilizzare tale metodo vengono presi in considerazione due elementi
fondamentali:
La probabilità che un evento si verifichi
L’impatto, cioè la perdita economica che Il verificarsi dell’evento
produrrebbe
Si definisce quindi un parametro, detto Costo Stimato Annuale, ottenuto per
ciascun evento come prodotto della perdita potenziale per la probabilità
che si verifichi
Tale metodo non è molto preciso principalmente perché la probabilità è
stimata su base statistica
3737
10/06/200810/06/2008
Risk Assessment – Metodo qualitativo
Nell’utilizzare tale metodo vengono valutati i seguenti elementi:
Minacce
Vulnerabilità
Controlli:
deterrenti
preventivi
detettivi
correttivi
Vengono definiti degli scenari e per essi vengono eseguiti dei test di
accettabilità confrontando i risultati con i requisiti attesi
Si definiscono quindi delle decisioni di salvaguardia per colmare i livelli tra
il rischio misurato e quello accettabile
Si ricicla sui test di accettabilità fino a che il rischio misurato non risulti
entro i criteri di accettabilità
3838
10/06/200810/06/2008
Determinazione RTO e RPO
I risultati ottenuti mediante BIA e RA vengono presi in considerazione
nell’ambito di una analisi costi benefici per determinare i corretti valori di
RTO e RPO che guideranno la implementazione della soluzione di
Disaster Recovery
Vengono inoltre individuate le dipendenze e le priorità da seguire nel
ripristino dei sistemi e delle applicazioni
Tutto confluisce nel documento fondamentale del Disaster Recovery che
è il DRP( Disaster Recovery Plan)
3939
martedì 10 giugno 2008martedì 10 giugno 2008
Disaster Recovery Plan - DRP
Il parametro di RPO deve essere mediato tra il valore delle perdite economiche prodotte dal disallineamento dati e i costi della soluzione necessaria a garantire l’allineamento tra il sito di DR e quello di produzione
Disallineamento Dati
Incremento Perdite
CostoAllineamento
Delta Benefici-Costi
Basso Medio Alto
K€ 100K€ M€
10M€ M€ 100K€
negativo negativo Positivo
Il parametro di RTO deve essere mediato tra il valore delle perdite economiche prodotte durante il tempo che intercorre tra il disastro e la ripartenza del servizio e i costi della soluzione necessaria a garantire la ripartenza del servizio
Tempo di Ripristino
Riduzione Perdite
Costo del Ripristino
Delta Benefici-Costi
Basso Medio Alto
M€ M€ K€
10M€ 100K€ K€
negativo Positivo nessuno
È il documento che formalizza i parametri di RTO e RPO ottimali per il contesto di business in esame ESEMPIO
4040
10/06/200810/06/2008
RTO e Tecnologie
Back-up su Tape off-site (RTO di giorni)
Electronic Tape Vaulting (RTO di parecchie ore)
Back-up Disk to Disk (RTO di alcune ore)
Remote DB Logging (RTO di alcune ore)
Remote Disk Copy Asincrono( RTO di poche ore)
Remote Disk Copy Sincrono ( RTO di minuti)
Remote Disk Copy con Server in Cluster Geografico (RTO di secondi)
4141Cluster geografico e metropolitanoIl valore di RTO può essere significativamente ridotto mediante l’utilizzo di configurazioni di cluster geografico o metropolitano
Server StorageMinicomputer
Ambito DR - Cluster Geografico
Asincrono
SAN
Minicomputer Minicomputer
SAN
SAN
MinicomputerMinicomputer
SAN
Eroga Servizi
IDC Roma
IDC Roma IDC Milano
IDC Milano
Heartbeat
Ambito DR - Risposta al disastro
Eroga Servizi
Ambito BC - Cluster MetropolitanoSincrono
SAN
Minicomputer
Minicomputer
SAN
Eroga Servizi
IDC RomaDC Roma 2
SAN
Minicomputer
Minicomputer
SANIDC Roma DC Roma 2
Heartbeat
Ambito BC - Risposta al disastro
Eroga Servizi
4242
10/06/200810/06/2008
Sistema di consolidamento e virtualizzazione server per DR
Virtualizzazione e Consolidamento dei Server Flessibilità, Efficacia e Convenienza Economica della SoluzionePer IBM RISC con AIX viene usata la tecnologia IBM POWER VirtualizationPer INTEL viene usata la tecnologia VMWARE
Replica Fisica dei Server e procedure di Clonazione (solo nei casi indispensabili)Risorse pronte per ripartire tempestivamente
4343
10/06/200810/06/2008
RPO e Tecnologie
Back-up (RPO di circa 24 ore)
Remote DB Logging (RPO di ore/minuti)
Remote Disk Copy Asincrono( RPO di minuti/secondi)
Remote Disk Copy Sincrono ( RPO tendente a zero)
4444
10/06/200810/06/2008
Il salvataggio dei dati
L’elemento più critico è costituito dai dati in quanto rappresentano l’asset
più fragile e quello completamente irrecuperabile
L’informazione associata al dato è spesso quella fondamentale per
l’erogazione dei servizi
Storicamente il dato viene salvato mediante back-up su nastro
Le evoluzioni tecnologiche dei dischi e la loro riduzione di costo
consentono di realizzare delle soluzioni di back-up Disk to Disk
Tuttavia anche i nastri hanno subito una importante evoluzione
tecnologica che ne ha migliorato le prestazioni e la capacità(> 1TB)
Le soluzioni di DR basate sul back-up dei dati presentano valori di RTO e
RPO molto alti
4545
10/06/200810/06/2008
La duplicazione dei dati
Per ottenere un sensibile miglioramento del parametro RPO è necessario
adottare una tecnica di duplicazione remota dei dati
E’ possibile replicare i dati in modo continuo e completo (mirroring
geografico) oppure inviare soltanto le variazioni delle basi dati (Remote
DB logging)
In relazione alla distanza e alle caratteristiche del sito di DR è possibile
attivare la replica sincrona o asincrona dei dati
La replica può essere ottenuta utilizzando delle funzionalità proprie dei
sottosistemi storage (Vendor dependent) oppure mediante funzionalità di
software specifici di Data mirroring (Server dependent)
4646
10/06/200810/06/2008
Sistema di Data Replication
Sincrono
1. L’operazione di scrittura viene ricevuta nelle cache dello storage Source,
2. L’operazione di I/O viene trasmessa alla cache del Target,
3. Un acknowledgment è inviato dal Target alla cache del Source,
4. Un status di fine operazione viene presentato al server.
4747
10/06/200810/06/2008
Sistema di Data Replication
Asincrono
Le operazioni di scrittura vengono catturate dall’unità‘Source’ in cache nel (Capture). Al completamento del ciclo il ‘Delta set’ viene consolidato (Transmit), in modo da remotizzare sul sito secondario solo l’ultimo aggiornamento associato ad uno specifico blocco di una traccia. I dati trasmessi sono ricevuti dall’unità‘Target’ Symmetrix (Receive). Se la trasmissione viene completata con successo, i dati vengono promossi (Apply) e da qui trasferiti su disco.
4848
10/06/200810/06/2008
Il sito di Disaster Recovery
Se l’azienda predispone un sito dedicato al Disaster Recovery esso può
essere classificato in:
Hot Site se il sito è completamente attrezzato con i sistemi, le linee TLC e con
tutti i servizi necessari pronti ad essere attivati immediatamente
Warm Site se il sito è parzialmente attrezzato o presenta dei servizi la cui
attivazione richiede del tempo
Cold Site se il sito dispone soltanto delle infrastrutture di base e di aklcuni
servizi ridotti
4949
10/06/200810/06/2008
Il sito di Disaster Recovery
Se l’azienda stipula degli accordi con altre organizzazioni per il sito dedicato
al Disaster Recovery si possono avere le seguenti opzioni:
Timeshares se il sito è destinato a fornire servizi a diverse aziende mediante
risorse che saranno approntate al bisogno
Accordi interaziendali quando aziende con tipologie di applicazioni e/o
architetture simili si impegnano a fornire reciprocamente il sito di DR in
caso di necessità
Rolling Mobile sites siti cioè realizzati utilizzando mezzi mobili quali TIR o altro
specificatamente attrezzati per le necessità di Disaster Recovery
5050
martedì 10 giugno 2008martedì 10 giugno 2008
Sito di DR e replica dati
La valorizzazione dei parametri di RTO (Recovery Time Objective) e RPO (Recovery Point Objective) influenza i costi di realizzazione e gli impatti applicativi di una strategia di DR
ESEMPIO
RTO
Costi
HotSite
WarmSite
ColdSite
Alti
Bassi
Basso Alto
InfrastrutturaHW/SW on Site e Allineamento online dei dati
InfrastrutturaHW/SW on Site e Allineamento online dei dati
InfrastrutturaHW/SW on Site senza Allineamento online dei dati
InfrastrutturaHW/SW on Site senza Allineamento online dei dati
Predisposizione del Sito di DRcon approccio Ship-to-Site
Predisposizione del Sito di DRcon approccio Ship-to-Site
Sito di DR Allineamento dati tra i Siti
RPO
Sincrono
Asincrono
Periodico
Basso Alto
Alti
sito Primario e sito di DRallineati all’ultima transazionesito Primario e sito di DRallineati all’ultima transazione
Possibile disallineamenti trasito primario e sito di DRPossibile disallineamenti trasito primario e sito di DR
Allineamento periodico offlineDel sito di DRAllineamento periodico offlineDel sito di DR
Impatti Applicati
vi
Bassi
Possibili soluzioni tecnologiche ai requisiti del DRP
5151
martedì 10 giugno 2008martedì 10 giugno 2008
RPO e soluzioni di replica dati
L’analisi dell’architettura Applicativa e Tecnologica dei sistemi coinvolti dalla strategia di DR, determina la scelta delle tecnologie opportune per la replica dei dati applicativi
ESEMPIO
DatabaseFile SystemAlti
Bassi File Transfer
Host Replication
Storage Replication
RPO
Volumi
Basso Alto
Host Replication
Storage Replication
DB Replication
DB Export
RPOBasso Alto
Alti
Back-Up/VaultingBack-Up/Vaulting
Applicabile tra storage dello stesso VendorApplicabile tra storage dello stesso Vendor
Applicabile tra storage di Vendor differentiApplicabile tra storage di Vendor differenti
Applicabile in configurazioni Warm/Cold SiteApplicabile in configurazioni Warm/Cold Site
Da Valutare per applicazioni Batch con allineamento periodico
Da Valutare per applicazioni Batch con allineamento periodico
Utilizzo delle funzionalitàNative di replica del DBMSUtilizzo delle funzionalitàNative di replica del DBMS
Salvataggio in formato nativodel DB e ftp su sito di DRSalvataggio in formato nativodel DB e ftp su sito di DR
Volumi
Bassi
Possibili soluzioni tecnologiche ai requisiti del DRP
5252Infrastrutture a supporto – Rete TLC
Le soluzioni di BC e DR devono poter contare su una rete TLC di caratteristiche adeguateESEMPIO
Rete di Interconnessione tra i Data Center (VDCN) VDCN: Virtual Data Center Network
Roma EurControl Room
IDCMILANO
IDC ROMA
DC BARI
DC Roma 2
2,5Gbit/s
10Gbit/s
5 Gbit/s
Rete ad alta velocità per il trasporto del traffico sul territorio nazionale e l’implementazione di servizi a valore aggiunto
Permette l’erogazione di servizi di interconnessione diversi in funzione del Data Center
Infrastruttura di supporto per le soluzioni di DR e BC
Infrastruttura in alta affidabilità capace di garantire la ridondanza del percorso fisico e logico
5353BC con SAN Metropolitana
Architettura Logica Allineamento dei Dati
Eroga Servizi
SAN
Minicomputer DC primario
DC secondario
Sincrono
SAN
Minicomputer
DC primarioDC Secondario
Allineamento sincrono dello storage tra il sito primario e il sito secondario
1
Ripartenza dello storage sul sito secondario senza perdita di dati, i server utilizzati per erogare i servizi rimangono quelli nel DC primario
1
Risposta al disastro localizzato nel DC Primario
Allineamento dei Server
Non in ambito
1
Risposta al disastro esteso
Non disponibile1Server
Storage
Minicomputer
5454BC con Cluster Metropolitano e Replica Sincrona
Server
Storage
Minicomputer
20 KMDC
Roma 2IDCRoma
Minicomputer Minicomputer
Cluster
Architettura Logica Allineamento dei Dati
Allineamento sincrono dello storage tra il sito primario IDC Roma e DC Roma 2
1
Allineamento dei Server20 KM
DCRoma 2IDC
Roma
Minicomputer Minicomputer
Cluster
Eroga Servizi
Sincrono
I server devono essere configurati in Modalità Hot e in Cluster Metropolitano
1
Risposta al disastro Localizzato nel IDC Roma
Ripartenza dei sistemi nel sito di BC (DC Roma 2) senza perdita di dati
1
Risposta al disastro Esteso nell’area romana
Non disponibile1
5555DR con Backup Remote Vaulting
Architettura Logica
20 KM
Corriere
IDCRoma
Ambito DR
IDCMilano
MinicomputerServerMinicomputer
Nastri
Allineamento dei Dati
Risposta al disastro Localizzato nel IDC Roma
Ripartenza dei sistemi nel sito di DR
1
Risposta al disastro Esteso nell’area romana
Ripartenza dei sistemi nel sito di DR 1
Il SW di gestione del backup crea i duplicati dei nastri oggetto di remote vaulting1
Allineamento dei Server
I Nastri sono spediti nel sito remoto con la frequenza necessaria a soddisfare i requisiti di RPO2
I server possono essere configurati in modalitàHotWarmCold
1
Storage
5656DR con replica a cascata dei dati
Architettura Logica
20 KM
SincronoPeriodico
DCRoma 2IDC
Roma
Allineamento dei Dati
Allineamento sincrono dello storage tra il sito primario IDC Roma e DC Roma 21
Allineamento periodico dello storage tra il sito DC Roma 2 e il sito IDC Milano 2
Risposta al disastro Localizzato nel IDC Roma
Allineamento dei dati necessari a sincronizzare lo storage del DC Roma 2 con quello dei DC di Milano1
Ripartenza dei sistemi nel sito di DR (DC Milano) senza perdita di dati
2
Risposta al disastro Esteso nell’area romana
Ripartenza dei sistemi nel sito di DR con perdita dei dati proporzionale alla frequenza dell’allineamento periodico
1
Allineamento dei Server
1
Ambito DR
IDCMilano
Minicomputer
Server
Storage
Minicomputer
Ambito BC
Minicomputer
I server possono essere configurati in modalitàHotWarmCold
5757DR con replica Asincrona dei dati
Architettura Logica
20 KM
Asincrono
IDCRoma
Allineamento dei Dati
Allineamento asincrono dello storage tra il sito primario IDC Roma e IDC Milano
1
Risposta al disastro Localizzato nel IDC Roma
Ripartenza dei sistemi nel sito di DR (IDC Milano) con perdita dei dati
1
Risposta al disastro Esteso nell’area romana
Ripartenza dei sistemi nel sito di DR (IDC Milano) con perdita dei dati
1
Ambito DR
Minicomputer
IDCMilano
Minicomputer
Server
Storage
Minicomputer
Allineamento dei Server
1I server possono essere configurati in modalità
HotWarmCold
5858DR con replica Star dei dati
Allineamento asincrono dello storage tra il sito primario IDC Roma e IDC Milano
Architettura Logica
20 KM
Sincrono + metadatiAsincronoDelta
DCRoma 2
IDCMilano
IDCRoma
Allineamento dei Dati
Allineamento sincrono dello storage tra IDC Roma e DC Roma 2, contestualmente sono inviati anche i metadati necessari a tracciare lo stato di avanzamento dell’allineamento asincrono tra IDC Roma e IDC Milano
1
Ambito DR
Minicomputer
Server
Storage
Minicomputer
Risposta al disastro Localizzato nel IDC Roma
Allineamento del delta dei dati necessari a sincronizzare lo storage del DC Roma 2 con quello dei DC di Milano
1
Ripartenza dei sistemi nel sito di DR (DC Milano) senza perdita di dati2
Disastro Esteso nell’area romana
Ripartenza dei sistemi nel sito di DR con perdita minimale dei dati
1
Allineamento dei Server
1 I server possono essere configurati in modalitàHotWarmCold
Minicomputer
5959DR e BC con replica a Cascata dei dati
Architettura Logica
20 KM
SincronoPeriodico
DCRoma 2IDC
Roma
Risosta al disastro Localizzato nel IDC Roma
Ripartenza dei sistemi nel sito di BC (DC Roma 2) oppure allineamento dei dati necessari a sincronizzare lo storage del DC Roma 2 con quello dei DC di Milano e successiva ripartenza dei sistemi nel sito di DR (DC Milano) senza perdita di dati
1
Risposta al disastro Esteso nell’area romana
Ripartenza dei sistemi sui siti di DR con perdita dei dati proporzionale alla frequenza dell’allineamento periodico
1
Allineamento dei Dati
Allineamento sincrono dello storage tra il sito primario IDC Roma e DC Roma 21
Allineamento periodico dello storage tra il sito DC Roma 2 e il sito IDC Milano 2
Ambito DR
IDCMilano
Minicomputer
Server
Storage
Minicomputer
Ambito BC
Minicomputer Minicomputer
Cluster
Allineamento dei ServerI Server in ambito BC devono essere configurati in Modalità Hot e in Cluster Metropolitano1
I server in ambito DR possono essere configurati in modalità
HotWarmCold
6060DR e BC con replica Parallela dei dati
Architettura Logica
20 KM
SincronoAsincrono
DCRoma 2IDC
Roma
Risposta al disastro Localizzato nel IDC Roma
Ripartenza dei sistemi nel sito di BC (DC Roma 2) senza perdita di dati oppure sul sito di DR (IDC Milano) con perdita dei dati
1
Risposta al disastro Esteso nell’area romana
Ripartenza dei sistemi nel sito di DR (IDC Milano) con perdita minimale dei dati
1
Allineamento dei Dati
Allineamento sincrono dello storage tra il sito primario IDC Roma e DC Roma 21
Allineamento asincrono dello storage tra il sito primario IDC Roma e IDC Milano
Ambito DR
Ambito BC
IDCMilano
Minicomputer
Server
Storage
Minicomputer
Minicomputer Minicomputer
Cluster
Allineamento dei ServerI server in ambito BC devono essere configurati in Modalità Hot e in Cluster Metropolitano1
I server in ambito DR possono essere configurati in modalità
HotWarmCold
6161DR e BC con replica Star dei dati
Allineamento asincrono dello storage tra il sito primario IDC Roma e IDC Milano
Architettura Logica
20 KM
Sincrono + metadatiAsincronoDelta
DCRoma 2
IDCMilano
IDCRoma
Allineamento dei Dati
Allineamento sincrono dello storage tra IDC Roma e DC Roma 2, contestualmente sono inviati anche i metadati necessari a tracciare lo stato di avanzamento dell’allineamento asicrono tra IDC Roma e IDC Milano
1
Ambito DR
Minicomputer
Server
Storage
Minicomputer
Risposta al disastro Localizzato nel IDC Roma
Disastro Esteso nell’area romana
Ripartenza dei sistemi sui siti di DR con perdita minimale dei dati
1
Allineamento dei Server
I Server in ambito BC devono essere configurati in Modalità Hot e in Cluster Metropolitano
1
Ripartenza dei sistemi nel sito di BC (DC Roma 2) oppure nel sito di DR (IDC Milano ) senza perdita di dati.
1
I server in ambito DR possono essere configurati in modalità
HotWarmCold
Minicomputer Minicomputer
Cluster
Ambito BC
6262
10/06/200810/06/2008
La documentazione completa del Piano di Continuità per il DR
Piano di DR, per la gestione della situazione di reale emergenza;
Piano di Test, per la simulazione periodica del recovery e verifica dell’efficacia della soluzione;
Piano di Gestione Ordinaria, per la quotidiana manutenzione e controllo della soluzione.
Piano di DR Piano di Test Piano di Gestione Ordinaria
Disaster Recovery
• Sistemi Storage
• Server Open \ Mainframe
• TLC
• Accesso Centro Alternativo
Processo di Gestione del Disaster Recovery
• Sistemi storage
• Server Open \ Mainframe
• Test TLC
• Test Accesso Centro DR
Test Recovery
Processo di Gestione Test Recovery
Gestione Ordinaria
• Gestione Change
• Aggiornamento Piano
• Gestione operazioni Esercizio
• Gestione operazioni Sito DR
Processo di Gestione OrdinariaProcessi
Procedure
IstruzioniOperative
6363
10/06/200810/06/2008
Il programma di questo seminario
Introduzione:
Terminologia e Standard
Normative Internazionali
I fondamenti del Disaster Recovery e della Business Continuity:
Panoramica delle soluzioni disponibili
Descrizione delle tecnologie abilitanti
I piani e le procedure organizzative
La soluzione adottata da Poste Italiane per i sistemi di Bancoposta:
Il progetto
La implementazione
La gestione
Indice degli argomenti
6464
10/06/200810/06/2008
Il progetto di Poste Italiane
Obiettivo del progetto:
Realizzare una soluzione di Disaster Recovery per le applicazioni
finanziarie e operative di Bancoposta conforme ai requisiti per la
continuità operativa emessi da Banca d’Italia a seguito degli accordi di
Basilea 2
Ambito del progetto:
Sistemi Mainframe
Sistemi Dipartimentali(Open)
Data Center
Infrastruttura TLC
6565
10/06/200810/06/2008
Sistemi Mainframe
ROMA EUR Network
IBM z/9902084/B16-315-A
IBM z/9902084/B16-315-A
IBM z/9002064/1C4-C
Escon
IBM DS/800
EsconDirectorsDirectors
0ROBOT STK 9300
6666
10/06/200810/06/2008
Sistemi Open
In relazione ai servizi in ambito Disaster Recovery sono state individuate le relative
Applicazioni e identificate le componenti tecnologiche corrispondenti
Complessivamente sono interessate 35 Applicazioni
6767
10/06/200810/06/2008
Per tutte le applicazioni che forniscono i servizi di Bancoposta e che
risiedono su sistemi Mainframe sono stati definiti, a seguito di BIA e RA,
i requisiti progettuali specifici e cioe’
RPO = 0
RTO = 2
Per tutte le altre applicazioni residenti su sistemi Open sono stati definiti
singolarmente, in relazione alle caratteristiche della applicazione, dei
valori nei seguenti range:
RPO = 0;8
RTO = 2,4,6,8
Requisiti della Soluzione di Disaster Recovery
6868
10/06/200810/06/2008
Il progetto
Le attività del progetto sono state suddivise in 6 fasi di lavoro distinte.
Fase Obiettivo
AssessmentDettagliare in modo puntuale il gap tecnologico dell’ infrastruttura
rispetto a quanto descritto nei documenti
DesignDefinire un piano tecnologico di dettaglio verso la soluzione di Disaster
Recovery
Implementation Realizzare la soluzione proposta ed accettata
Piani e Procedure OperativeDefinire ed implementare i piani e le procedure operative (DR plan) per la
gestione delle regime ordinario e degli stati di crisi
Test Verificare rispondenza della soluzione ai requisiti tecnici e funzionali
Esercizio Passaggio in produzione della soluzione
6969
10/06/200810/06/2008
Differential Resynchronization
Asynchronous disk and tape mirroring
RTO: 2 oreRTO: 2 ore
Roma 2
2
Synchronous
Disk Mirroring
Roma, v.le Europa
mainframe
server farm(*)
ReteGeo
1
Milano
ReteGeo
server farm (*)
mainframe
3
2
3
Sito IBM - Milano
STAR configuration RPO: 0 Sec.RPO: 0 Sec.
(*) soltanto alcuni sistemi dipartimentali già in gestione dal fornitore esterno
Implementazione soluzione: Sistemi Mainframe
Per rispettare il requisito di RPO=0 , la soluzione architetturale implementata, prevede la replica dati sincrona e asincrona effettuata attraverso le funzionalita’ messe a disposizione dalla tecnologia dei sottosistemi storage EMC.
7070
10/06/200810/06/2008
Implementazione soluzione: Sistemi Open
Synchronous
Disk Mirr
oring
Roma, v.le Europa
server farmserver farm
Questa soluzione di Disaster Recovery e’ in grado di garantire tutti i requisiti di RTO e RPO definiti per le singole applicazioni dei sistemi dipartimentali
1 1
1
ReteGeo
32
mainframe
D.R. IBM Site
MI Rozzano
Roma 2
RTO: 2 hoursRTO: 2 hours
RPO: 0 Sec.RPO: 0 Sec.
Differential Resinc
Asinchronous disk and tape mirroring
7171
10/06/200810/06/2008
Implementazione Soluzione:SAN Extension
Area di RomaSynchronousReplicationBusiness Continuity
IDC Centro
Internet Extranet Intranet
Extranet
IDC NORD
Area di MilanoAsynchronous ReplicationDisaster Recovery
IntranetSUD
10Gbps
Troughput complessivo = 7.5 GbpsAsynchronous Replication Open/MainframeDisaster Recovery
Internet Intranet
DC SUD
Carrier TLC 1 = 5 GbpsCarrier TLC 2 = 2,5 Gbps
Necessità di garantire continuità temporale all’erogazione dei servizi
Interoperare sfruttando un’infrastruttura di rete di trasporto dedicata.
Semplificazione della Data replication (necessaria a garantire un servizio di “business continuity” e “disasterrecovery”)
Soluzioni orientate alla realizzazione di una SAN Extension (Storage Area Network) geograficamente distribuita.
I fattori che condizionano la scelta nella realizzazione di una SAN Estesa risultano fortemente legati all’obiettivo di garantire operatività, efficienza e continuità temporale all’erogazione dei servizi applicativi. Sono:
4 Recovery Time Objective (RTO)4 Recovery Point Objective (RPO)
Carrier TLC 2 = 5 Gbps
7272
10/06/200810/06/2008
Soluzione di DRLa soluzione realizzata da Poste supera i modelli classici di soluzione di disaster recovery a caldo, basandosi su un’ architettura di remotizzazioneavanzata costituita da tre siti.
Il Sito di produzione è la sorgente da cui vengono erogati i servizi di Banco Posta e replicati i dati nelle normali condizioni di funzionamento del processo.
Il Sito bunker è dislocato a una distanza “campus” dedicato ad ospitare la replica sincrona dei dati di produzione, per mezzo di reti in fibra ottica a bassissima latenza, che garantisce il perfetto allineamento sincrono dei dati con il Sito di produzione.
La funzione del Sito bunker è quella di proteggere il Sito di produzione da un disastro circoscritto al Data Center di produzione e di ripartire dal Sito remoto con i servizi applicativi, senza perdita di dati, dopo aver eseguito il riallineamento dal Sito bunker.
Il Sito remoto è il sito di disaster recovery, preposto al ripristino dei servizi Banco Posta a fronte di un evento disastroso, dislocato ad una distanza “geografica”. Il Sito remoto viene collegato ad entrambi i Siti di produzione e bunker. L’interconnessione viene realizzata attraverso l’utilizzo della rete WAN di Poste Italiane in grado di trasmettere i dati in modalitàasincrona e senza limitazioni di distanza.
La funzione del Sito remoto è quella di proteggere il Sito di produzione da un disastro, che può essere:
limitato al solo Sito di produzione: in tal caso il Sito remoto è in grado di garantire un RPO = 0geografico, che coinvolge cioè anche il Sito bunker: in tal caso il Sito remoto consente un RPO dell’ordine di minuti.
7373
10/06/200810/06/2008
Soluzione di DR – Scenari di Disastro
L’indisponibilità del sito primario comporta l’attivazione del processo di fail over sul sito remoto mediante l’esecuzione di una sequenza di operazioni. Tale sequenza di operazioni viene attivata a valle della decisione di attuare il Piano di DisasterRecovery.
7474
10/06/200810/06/2008
Soluzione di DR – Scenari di Disastro
La indisponibilità del sito bunker non comporta impatti significativi né sul sito di produzione né sul sito remoto.
7575
10/06/200810/06/2008
Soluzione di DR – Scenari di Disastro
L’indisponibilità contemporanea dei siti di produzione e bunker rientra negli scenari di disastro che la soluzione implementata è in grado di gestire. Analogamente all’indisponibilità del solo sito secondario, l’RPO risulta dell’ordine di minuti.
7676
10/06/200810/06/2008
Processo di gestione della crisi
Sono stati i definiti i gruppi di lavoro
coinvolti e indicati i ruoli e le
responsabilità per ognuna delle
attività descritte.
La struttura organizzativa di Poste
Italiane pur mantenendo le sue
caratteristiche opererà in condizioni
di crisi secondo una diversa e
specifica assegnazione delle funzioni
ed assumerà ruoli e responsabilità
predefinite.
7777
10/06/200810/06/2008
Gestione delle attività operative
Sistemisti:1. Gestione inventario sistemi,
utilities, applicativi e fornitori2. Gestione (manutenzione e
tuning) di sistemi, prodotti programma, data base, ecc
3. Assistenza ai referenti sicurezza per pianificazione e controllo meccanismi di sicurezza dati
4. Gestione (manutenzione e tuning) sistemi di clusteringgeografico, sistemi e prodotti di replicazione dati software based.
5. Mantenimento procedure failover
6. Gestione problemi e interventi di secondo livello
7. Mantenimento documentazione tecnica.
Specialisti rete:1. Gestione accessi di rete
(configurazione e tuning)Operatori:1. Monitor e controllo dei
sistemi, della rete e dello storage in replica
2. Esecuzione delle operazioni di backup ed esternalizzazione dati.
3. Gestione problemi e intervento di primo livello
Gestione server farm
NORMALITA’ TEST DISASTRO
Sistemisti:1. Pianificazione del test:
def.obiettivi, determinazione della finestra temporale di esecuzione, formazione del team di test.
2. Predisposizione procedure per simulazione interruzione / disastro, e rientro alla normalità.
3. Verifica completezza apparato documentale
4. Supporto alla esecuzione delle operazioni in piano.
5. Esecuzione dei test6. Tuning pre-rilascio sistemi e
durante le operazioni di test Specialisti rete:1. Supporto alla esecuzione
delle operazioni di switchover della porzione di rete per test
Operatori:1. Esecuzione delle operazioni
di recovery dei sistemi, dati
Sistemisti:1. Gestione dei sistemi, dei
prodotti programma, data base, ecc
2. Assistenza ai referenti sicurezza per controllo meccanismi di sicurezza dati
Specialisti rete:1. Gestione degli accessi di
rete (configurazione e tuning)
Operatori:1. Esecuzione delle operazioni
di produzione
OPERATORIEsecuzione e controllo operazioni e supporto 1livello
SISTEMISTI Configurazione e supporto 2livello
SPECIALISTI RETEConfigurazione e supporto 2livello