Disaster Recovery e Business Continuity

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


Introduzione:








Il progetto

La implementazione

La gestione


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


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


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


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


Introduzione:








Il progetto

La implementazione

La gestione


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


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


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


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


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


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


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


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


Ripartenza dei sistemi nel sito di DR

1


Ripartenza dei sistemi nel sito di DR 1

Il SW di gestione del backup crea i duplicati dei nastri oggetto di remote vaulting1


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 periodico dello storage tra il sito DC Roma 2 e il sito IDC Milano 2


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


Ripartenza dei sistemi nel sito di DR con perdita dei dati proporzionale alla frequenza dell’allineamento periodico

1


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 asincrono dello storage tra il sito primario IDC Roma e IDC Milano

1


Ripartenza dei sistemi nel sito di DR (IDC Milano) con perdita dei dati

1


Ripartenza dei sistemi nel sito di DR (IDC Milano) con perdita dei dati

1

Ambito DR

Minicomputer

IDCMilano

Minicomputer

Server

Storage

Minicomputer


1I server possono essere configurati in modalità

HotWarmCold

5858DR con replica Star dei dati


Architettura Logica

20 KM

Sincrono + metadatiAsincronoDelta

DCRoma 2

IDCMilano

IDCRoma


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


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


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


Ripartenza dei sistemi sui siti di DR con perdita dei dati proporzionale alla frequenza dell’allineamento periodico

1



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


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


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


Ripartenza dei sistemi nel sito di DR (IDC Milano) con perdita minimale dei dati

1




Ambito DR

Ambito BC

IDCMilano

Minicomputer

Server

Storage

Minicomputer


Cluster

Allineamento dei ServerI server in ambito BC devono essere configurati in Modalità Hot e in Cluster Metropolitano1


HotWarmCold

6161DR e BC con replica Star dei dati


Architettura Logica

20 KM

Sincrono + metadatiAsincronoDelta

DCRoma 2

IDCMilano

IDCRoma


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


Disastro Esteso nell’area romana

Ripartenza dei sistemi sui siti di DR con perdita minimale dei dati

1


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


HotWarmCold


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


Introduzione:








Il progetto

La implementazione

La gestione


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


La indisponibilità del sito bunker non comporta impatti significativi né sul sito di produzione né sul sito remoto.

7575

10/06/200810/06/2008


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

Disaster Recovery e Business Continuity

Documents

Transcript of Disaster Recovery e Business Continuity