Approccio sistemico alla business continuity & disaster recovery

Back

Il presente documento viene redatto per delineare un possibile scenario di riferimento per introdurre architetture di continuità operativa (Business-Continuity e Disaster Recovery).

L’aumento delle possibilità di accesso ai servizi telematici ha nel tempo determinato l’aumento delle informazioni trattate e memorizzate presso i datacenter con conseguente crescente sensibilità da parte del management di mantenere queste informazioni altamente disponibili e salvaguardarle da possibile perdita di informazioni od operatività.

La differenziazione tra Business Continuity e Disaster Recovery è da ricercarsi nella tipologia di servizio da offrire prima che per termini tecnologici o connettività.

La prima domanda che ci dobbiamo porre nell’intraprendere una delle due alternative o propendere per la scelta di entrambe è la seguente:

Il sistema di servizi che vogliamo salvaguardare termina con la cessazione del sito su cui i servizi insistono ?

Se la risposta è Sì, il tipo di continuità operativa da intraprendere è la Business Continuity, se la risposta è no, il servizio avrà necessità di una continuità operativa geograficamente distante dal sito principale per garantire l’erogazione di servizi in caso di calamità od eventi che interessano la zona del sito principale. In quest’ultimo caso si parla di Disaster Recovery.

Per fare un esempio possiamo ipotizzare un servizio di pronto soccorso ed un servizio di un corriere internazionale. Se si dovesse verificare un evento che rendesse indisponibile totalmente il servizio stesso di pronto soccorso, allagamento, terremoto od altro evento che rendesse fisicamente non più disponibile il servizio da parte dei sanitari, l’alternativa per gli utenti sarebbe rivolgersi ad un altro pronto soccorso. In questo caso avrebbe poco senso riattivare i servizi informatici del pronto soccorso in un altro sito geograficamente distante mentre una buona resilienza locale dei servizi informatici (Business Continuity) permetterebbe una continuità operativa anche in assenza di connettività e anche nel caso in cui almeno un datacenter, all’interno di un complesso ospedaliero, risultasse agibile. Un backup dei dati situato in un sito diverso è ovviamente indispensabile.

Nel secondo caso, un’impresa di spedizioni, un eventuale problema al sito principale che rendesse indisponibili i servizi telematici dell’headquarter che li ospita, non deve causare disservizio per tutte le filiali, magazzini e la logistica in generale che dovrà assolutamente continuare indipendentemente dal sito principale. In situazioni come quest’ultima il sito di Disaster Recovery è assolutamente indispensabile per la continuità dei servizi.

Solo dopo aver risposto a questa domanda ci si può interrogare su RTO, RPO, latenze, throughput, banda e quant’altro necessario alla realizzazione della continuità operativa.

ACRONIMI E DEFINIZIONI

BC Business Continuity
DR Disaster Recovery
CLI Command Line Interface
FDR Fast Disaster Recovery
SAN Storage Area Network
SDR Site di Disaster Recovery
SS-A Semi-site A
SS-B Semi-site B
SPOF Single Point Of Failure
RSS Redundant Semi-Site
SSR Semi-sites redundancy
SSO Single Sing On
RTO Recovery Time Objective
RPO Recovery Point Objective

OBIETTIVI DEL DOCUMENTO

Il documento ha come obiettivo l’indicazione di linee guida per coloro che approcciano progetti di Continuità Operativa (Business Continuity e/o Disaster Recovery).

Un progetto di BC o DR dovrà essere eseguito con impatti nell’operatività ridotti al minimo per poter garantire la continuità di erogazione dei servizi.

Il progetto prevede le seguenti macro-fasi:

  1. Categorizzazione dei servizi ed individuazione dei servizi mission-critical
  2. Categorizzazione dei dati
  3. Allestimento dei servizi di base Storage e Storage Area Network (SAN)
  4. Messa in sicurezza dei servizi e operatività (infrastructure splitting)
  5. Test
  6. Passaggio da progetto alla gestione operativa ed evolutiva

DOCUMENTAZIONE DI RIFERIMENTO

La documentazione di riferimento è rappresentata dalle seguenti pubblicazioni che possono essere anche la base di partenza per attività non legate al settore pubblico.

http://www.digitpa.gov.it/fruibilita-del-dato/continuita-operativa
LINEE GUIDA PER IL DISASTER RECOVERY DELLE PA_0.pdf
CIRCOLARE_1_dicembre_2011_n58.pdf
Orlandi_LG_x_14_3_2013_v7.pdf
Rellini_14 marzo_v.1.0.pdf
Autovalutazione.ods
Autovalutazione.xls
LBL®Application Availability Infrastructure
LBL_BusinessContinuityAndDisasterRecovery.pdf

CONTESTO DI RIFERIMENTO

Il contesto su cui si articola questo documento prende origine dalle direttive contenute in LINEE GUIDA PER IL DISASTER RECOVERY DELLE PUBBLICHE AMMINISTRAZIONI di DigitPA pubblicate, nella loro ultima revisione, a gennaio 2012. Queste direttive possono essere utilizzate anche per attività non legate al settore pubblico essendo delle linee guida generali sulla conservazione dei dati e continuità dei servizi.

La centralizzazione dei servizi telematici e la digitalizzazione/dematerializzazione dei documenti impone l’adozione di misure che favoriscano la messa in sicurezza del patrimonio informativo mantenuto e costantemente aggiornato all’interno dei datacenter.

La messa in sicurezza delle informazioni e dell’operatività dei servizi deve necessariamente avere 3 caratteristiche fondamentali:

1 – preservazione del dato

2 – continuità nell’erogazione dei servizi critici

3 – sicurezza degli accessi ai servizi ed ai dati sensibili

Altro fattore molto importante che prenderemo in esame è l’evoluzione dei sistemi nel tempo. Se da un lato la progettualità deve tendere al raggiungimento degli obiettivi descritti nei tre punti precedenti, l’operatività e la gestione evolutiva devono essere previste in fase architetturale per non creare vincoli all’evoluzione futura ed ulteriori aggravi economici.

SITUAZIONE ARCHITETTURALE ESISTENTE

L’evoluzione dei datacenter ha visto incrementare i servizi offerti per qualità e quantità nel naturale processo di accentramento delle risorse informatiche accelerate in questi anni dall’aumento e distribuzione della connettività.

I servizi erogati dai datacenter si sono evoluti negli anni in infrastrutture modulari dove più applicazioni collaborano tra loro per ottenere il servizio finale offerto al cliente.

Nella maggior parte dei casi è possibile comunque trovare un unico modello di implementazione. La distribuzione delle componenti può essere suddivisa come di seguito indicato:

– Punti di erogazione;

– Application Server;

– Database Server;

– Directory Server;

– Storage Area Network

Di seguito un’immagine che sintetizza in maniera visiva gli strati che le richieste di servizio, rappresentate dai nastri colorati, devono attraversare per poter soddisfare le richieste.

La struttura a più livelli, AppServer, Database, Storage Area Network, è stata introdotta per garantire scalabilità con l’aumentare del “pubblico” a cui questi servizi sono rivolti. Questa infatti garantisce nel contempo un’efficace diminuzione dei singoli punti di avaria permettendo la duplicazione locale delle funzioni.

Appare chiaro che una tale concentrazione di tecnologia in un unico spazio può diventare di per se stesso un singolo punto di avaria per eventi localmente generalizzati come: black-out, terremoti, inondazioni, incendi, atti vandalici, etc.

A questo proposito gli interventi architetturali dovranno prevedere delle misure che garantiscano, a vari livelli, la conservazione delle informazioni e, quando necessario, arrivare a garantire la continuità di erogazione dei servizi critici.

CONTINUITA’ OPERATIVA: SCENARIO

Il mantenimento delle informazioni e dell’operatività è sempre stato un tema importante nel trattamento automatico delle informazioni.

La base di partenza per qualsiasi progetto di alta affidabilità è sicuramente l’eliminazione dei singoli punti di avaria (SPOF Single Point Of Failure).

Agli inizi degli anni ’90 cominciarono le realizzazioni dei primi failover-cluster commerciali studiati fondamentalmente per una struttura a due livelli: Applicazione+Database; Storage.

Un limitato gruppo di persone accedeva al server dipartimentale che conteneva sia le componenti applicative sia le componenti database. Il server dipartimentale aveva un suo omologo server di ridondanza ed entrambi erano collegati ad un unico storage.

Server operativo

(Master)

Server in fail-over

(Sleeping Master)

Il sistema era stato pensato per poter garantire l’operatività esclusiva di accesso al dato ed evitare fenomeni di split-brain e conseguente corruzione logica dei dati. La strategia di conservazione del dato era formulata quindi sulla base della resilienza dello strato di memorizzazione ed in ultimo appello alle copie di salvataggio in caso di corruzione dei dati. In nessun caso i due server dipartimentali potevano accedere contemporaneamente allo storage.

Con l’avvento di Internet lo scenario architetturale di riferimento è profondamente cambiato. L’erogazione di servizi a grandi numeri di utenti in diversi formati di utilizzo ha visto evolvere l’infrastruttura tecnologica in più livelli specializzati:

All’evoluzione dell’infrastruttura in diversi livelli è seguita l’evoluzione delle tecnologie di virtualizzazione. Nella stessa maniera anche i supporti di memorizzazione di massa hanno registrato un enorme aumento delle capacità di memorizzazione e velocità di accesso aumentando nel contempo in funzionalità. Si implementano la replicazione sincrona e asincrona, gli snapshot, etc.

Tutte queste tecnologie si sono e si stanno rapidamente evolvendo ognuna mettendo a disposizione il proprio miglior risultato in termini di efficienza ed efficacia rendendo disponibili strumenti fino a qualche tempo fa non pensabili in termini di costi, densità e velocità.

E’ oggi possibile orientarsi su servizi distribuiti in diverse location e indurre alta affidabilità e continuità di servizio oltrepassando il singolo punto di avaria divenuto oggi il datacenter situato in una singola location.

Sono così state pensate e realizzate infrastrutture che possono garantire la persistenza dei dati e la continuità di servizio attraverso la duplicazione su siti adiacenti.

Se immaginassimo un progetto di questo genere partendo da un failover-cluster pensato all’inizio degli anni ’90, la trasformazione di una infrastruttura single-site in double-site sembrerebbe a prima vista molto semplice. Disponendo infatti di un cluster composto da due sistemi con servizi duplicati e utilizzando le nuove tecnologie di replicazione storage, sembrerebbe sufficiente spostare uno dei due nodi nel nuovo sito ed avviare la replica per ottenere la ridondanza su due siti.


In realtà, il risultato ottenuto non è all’altezza delle aspettative. Infatti, in caso di “disastro” del sito principale, se da un lato questa architettura ottempera alla salvaguardia dei dati e dell’operatività fisica, dall’altro non soddisfa le caratteristiche di salvaguardia dei dati nei casi più banali come la mancanza temporanea della connettività tra i due siti. Caso questo in assoluto più frequente tra tutti.

In quest’ultima evenienza, essendo i servizi distribuiti su più location e non potendo più comunicare tra loro, chi è primario tenderà a rimanere primario mentre chi era secondario, in replica, tenderà a diventare primario. I due siti procederanno al popolamento dei database in maniera parallela rendendoli logicamente inconsistenti.


Al ripristino della connettività ci saranno inoltre importanti problemi di comunicazione. I cluster fino ad ora realizzati prevedono infatti l’utilizzo di indirizzi virtuali. Indirizzi che alla riattivazione della connettività tra i due siti entreranno in contesa aumentando ulteriormente lo stato di confusione e inconsistenza. Il risultato non è predicibile.

Questa ipotesi, riportata alle attuali conformazioni architetturali, porterebbe in brevissimo tempo ad una inconsistenza logica dei dati non più riconciliabile.

SITES SPLIT BRAIN

Ogni intervento sui singoli livelli, storage, database, application server, virtualization, risulterebbe non appropriato perché parziale. Anche l’utilizzo di sistemi di quorum non permette di conseguire dei risultati certi. La moltiplicazione dei sistemi di quorum, per ogni singolo servizio, porterebbe ben presto alla non sostenibilità dell’insieme, oltre a risultare perfettamente inutile, non sapendo a priori a che livello il problema si presenterà (Split-Brain).

Il cambiamento dello scenario impone quindi un cambiamento radicale dell’approccio all’alta affidabilità in Business-Continuity.

In queste circostanze la soluzione di questo problema è più semplice se affrontata da un punto di vista “architetturale” al datacenter, non intervenendo sulle singole componenti, ma nel punto in cui tutti i servizi vengono richiesti. Questi punti di accesso possono ricoprire il ruolo di coordinatori delle attività di erogazione bloccando, in caso di ambiguità della consistenza, l’accesso all’intero stack applicativo ed evitando quindi con sicurezza e semplicità split-brain logici.

Questo aspetto di “blocco” dei soli accessi ai servizi del datacenter è importantissimo poiché non altera minimamente lo stato di attività del datacenter. Tutti i layer del backend rimangono attivi e pronti ad erogare i propri servizi nel malaugurato caso in cui questi sia rimasto l’unico sito superstite.

La riattivazione della connettività e quindi l’accesso ai servizi dovrà essere in questo caso affidato ad una decisione umana. La riattivazione dell’accesso deve essere molto semplice e possibile anche da parte di operatori non specializzati visto il momento di crisi e/o dall’impossibilità di reperire personale idoneo in tempi rapidi.

Intervento umano nel sito superstite con la riattivazione dell’accesso ai servizi…


DECISIONI UMANE OD AUTOMATICHE

Sia per la Business Continuity, sia per il Disaster Recovery, è possibile utilizzare delle tecniche decisionali umane o automatiche. La tematica quindi è la possibilità che un sistema possa prendere delle decisioni per spostare i servizi da un sito ad un altro, indipendentemente che si tratti di BC o DR.

E’ normalmente accettato che quando si parla di BC si ricorra a sistemi di decisione automatica mentre se si sta parlando di DR la decisione sia demandata ad una decisione umana, di solito il comitato di DR.

In realtà la tipologia di decisione non è appannaggio della BC o del DR, vedasi introduzione sulla scelta di continuità in base al servizio da erogare, ma in quanto alla criticità del servizio e della possibilità di presidio.

Sia per la BC che per il DR se la decisione di fail-over deve essere automatica è necessario affrontare il problema dello split brain in maniera più profonda rispetto a quando la decisione viene demandata ad una volontà umana anche se comunque deve essere affrontata.

SPLIT BRAIN & QUORUMS

Quando si parla di decisioni automatiche parlare di Split Brain è inevitabile e normalmente si comincia a parlare anche di Qu




orum. In un cluster esteso, indipendentemente dal tipo di cluster (storage, database, sistema operativo, sistemi di bilanciamento etc.) il “Nodo di Quorum” identifica l’oggetto che in caso di avaria determina l’azione automatica di recovery. E’ generalmente accettato che il “Nodo di Quorum” sia indispensabile in una architettura estesa ma valutiamo bene il suo effettivo utilizzo.


Prendiamo un layer architetturale qualsiasi della nostra infrastruttura allargata (Stretched Cluster) e sintetizziamola in tre elementi: Nodo Primario, Nodo Secondario (in replica/Split IO/mpxio/o primary-primary) e nodo di Quorum.

Questi tre elementi servono a garantire l’alta affidabilità nel caso il Nodo Primario non sia più disponibile ed eseguono uno switch automatico nel sistema Secondario in Replicazione promuovendolo allo stato di Primario.


In questo caso la promozione a “Nodo Primario” del nodo in replica permette di erogare i servizi continuativamente e per questo motivo sembra essere sufficiente.

Normalmente ci si ferma sempre a questa considerazione ma affermare che questo scenario è “sempre” vero forse merita un approfondimento in considerazione del fatto che stiamo parlando di servizi critici e di un investimento considerevole sia di acquisizione sia di implementazione.


Se pensiamo allo stesso scenario con un’avaria diversa da quella appena descritta questa architettura presenta un “paradosso” che in ambienti complessi ed estesi può portare al disservizio totale invalidando quindi la caratteristica dell’alta affidabilità ed i cos

ti sostenuti. Lo scenario, purtroppo al 50% delle possibilità, è che il nodo secondario, assieme alla visibilità del Quorum, non siano più raggiungibili dal “Nodo Primario”. In questo caso, il “Nodo Primario” entrerà in “STOP” per evitare fenomeni di split-brain non avendo più la certezza del funzionamento del sito secondario.

Se applicato, ad esempio, ad uno storage, ma potrebbe essere allo stesso modo un DB, questo comportamento induce l’unico sito superstite ad un’avaria generalizzata bloccando le scritture ai volumi e conseguentemente facendo entrare in avaria istantanea Database, Applicazioni, batch di elaborazione. In questo caso il personale sarà obbligato ad un riavvio estremamente complicato di un intero sito… che in questo caso è anche l’unico superstite.

Parafrasando il celebre film “War Games”, durante il gioco del Tris (Tic-Tac-Toe), non c’è soluzione se affrontato nei singoli layer.

Una implementazione dell’infrastruttura di fail-over, nei singoli layer, comporta quindi una serie di problemi non indifferenti come, un aumento esponenziale dei “Nodi di Quorum” per ogni layer e per ogni servizio e generalmente ad una diffusa complessità che molto spesso è la causa stessa dei problemi che dovrebbe risolvere.

Proviamo ora a spostare più ad alto livello la gestione dell’alta affidabilità. Se spostiamo il problema verso l’alto, dove pervengono le richieste di erogazione di servizio, il problema dello stop sussiste ma la sola conseguenza è lo stop dell’accesso ai servizi. Una eventuale riattivazione è semplice ed immediata dovendo solo riaprire le comunicazioni verso il backend.

LBL A.A.I., controllando la rete e l’accesso ai servizi, è stato studiato per ambienti Stretched Cluster (Business Continuity & Disaster Recovery) ed è oggi il solo strumento integrato cross Platform e cross Virtualization a risolvere con semplicità questo problema. Il potente LBL ADC (ADC) integrato con le componenti di alta affidabilità geografica LBL Surface Cluster (Decision Engine e Work Flow) permette di orchestrare i fail-over in maniera semplice, efficace e tracciabile.

Quorum Games© è stato pubblicato attraverso news letter il 25 giugno 2013, tutti i diritti sono riservati

SEMPLIFICAZIONE

Da quanto esposto fino ad ora è evidente che un’infrastruttura in alta affidabilità deve avere come obiettivo principale la semplificazione dei processi che la determinano.

La necessità di suddividere i singoli servizi in layer, che contribuiscano in maniera specializzata all’erogazione del risultato finale, la diversificazione delle piattaforme e le molteplici release dei singoli componenti, impongono l’introduzione di un elemento che possa orchestrare le attività di fail-over e ripristino in maniera coordinata, ripetibile e soprattutto auto-documentante.

Per capire le necessità di uno strumento di coordinamento delle attività all’interno del datacenter proviamo a scomporre le azioni da compiere per effettuare un fail-over in un ambiente distribuito a seguito di una avaria del semi-site primario:

Esempio di attività da svolgere nel semi-site secondario per l’erogazione dei servizi

  1. Promozione a primario degli storage in replica per i dati non strutturati
  2. Promozione a primario delle repliche DATABASE (ove presenti)
  3. Avvio/mount dei volumi dei server fisici/virtuali DATABASE
  4. Avvio dei server applicativi
  5. Avvio dei guest virtualizzati
  6. Cambiamento degli indirizzi ove necessario
  7. Start dell’erogazione dei servizi

Queste operazioni devono essere svolte in sequenza coordinata per garantire il risultato finale e cioè l’erogazione dei servizi applicativi. L’esecuzione di queste attività in maniera non coordinata comprometterebbe l’operatività finale.

Altro fattore di valutazione è la disomogeneità dei singoli elementi che compongono i servizi: Vendor differenti, Sistemi operativi differenti e di diverse release, sistemi di virtualizzazione differenti, sistemi fisici differenti.

Il coordinatore deve essere al di sopra delle parti ed il più possibile indipendente dalle piattaforme e dalle release.

LBL COMMANDER ARCHITETTURA

LBL Commander è stato studiato e realizzato cogliendo le nuove necessità emergenti con le nuove architetture stretch-cluster (Continuità Operativa).

Le necessità di alta affidabilità e la rimozione dei Single Point Of Failure (SPOF), rappresentati oggi dal datacenter, hanno fatto ridisegnare la strategia complessiva di induzione dell’alta affidabilità applicativa.

Un moderno sistema di alta affidabilità deve rispondere alle necessità esposte nei paragrafi precedenti salvaguardando 3 caratteristiche fondamentali:

Cosa fa un failover-cluster ?

  1. Verifica costantemente il buon funzionamento
  2. Prende delle decisioni
  3. Esegue una serie di azioni per riportarsi allo stato 1.

Essendo le attuali architetture strutturate su più livelli, anche il servizio di alta affidabilità deve essere ripensato in ottica distribuita.

Per rispondere alle domande 1, 2, 3 considerando gli attuali scenari distribuiti con fenomeni di split-brain e corruzione logica dei dati, è improponibile dotare di sistemi di fail-over le singole componenti, si arriverebbe ben presto all’inconsistenza, alla perdita del controllo e ad una eccessiva e costosa ridondanza hardware e software.

E’ necessario quindi diminuire i punti di controllo e dotarsi di uno strumento in grado di orchestrare e distribuire in maniera automatica le azioni da svolgere nei vari livelli per garantire il ripristino dell’operatività in caso di avaria.

Sono state quindi riassunte le 3 funzionalità di un cluster in due strumenti software in grado di concentrare le attività di controllo semplificando nel contempo la gestione.

Come funziona LBL Commander ?

  1. Verifica costantemente il buon funzionamento
  2. Prende delle decisioni
  3. Esegue una serie di azioni per riportarsi allo stato 1)

Le due componenti prendono il nome di:

LBL Commander Decision Engine

LBL Commander Work Flow

LBL Commander centralizza i punti di controllo e operatività dei servizi rendendo più semplici le attività di gestione per le persone preposte alla supervisione.

1. Verifica costantemente il buon funzionamento

2. Prende delle decisioni

3. Esegue una serie di azioni per riportarsi allo stato 1.

All’aumentare del numero di servizi da mantenere in alta affidabilità i punti di verifica rimangono inalterati, come numero e posizione, semplificando il controllo e la configurazione da parte delle persone preposte alla gestione.

Servizio A

Servizio B

In questo scenario di esempio è stato introdotto un ulteriore servizio, il servizio B. I punti di controllo non aumentano centralizzando la gestione dell’alta affidabilità.

Ruolo fondamentale in questo ambiente è LBL®ADC che ha la capacità di instradare le richieste di servizio lì dove possono e devono essere erogate. LBL®ADC collabora costantemente con LBL®Commander Decison Engine determinando assieme le rotte di instradamento.

LBL COMMANDER AUTO-DOCUMENTAZIONE

In ambienti così articolati e dinamici qualsiasi documentazione operativa “riportata a mano” dell’ambiente reale diventa immediatamente obsoleta. Il datacenter è un ambiente dinamico, in continua evoluzione. Qualsiasi strumento di alta affidabilità necessita di certificare il suo funzionamento per essere pronto ad eventi contingenti. Mantenere un ambiente in costante evoluzione e “certificato” significa eseguire test continui con metodiche che documentino l’effettivo rapporto tra “processi” e realtà implementata.

La descrizione dei processi di alta affidabilità con LBL Commander è direttamente descritta nei processi stessi che determinano l’alta affidabilità.

La scomposizione dei processi di alta affidabilità in logica e azione e la conseguente semplice descrizione delle procedure in flussi di lavoro (Workflow) auto-documenta le azioni che inducono l’alta affidabilità all’interno dell’intero datacenter:

Raccolta centralizzata di azioni coordinate

all’interno del datacenter

La possibilità di navigare attraverso le azioni che verranno intraprese in caso di avaria, momento critico, oppure per semplice routine, rendono i processi che si sviluppano all’interno del datacenter più confidenziali perché controllabili e autodocumentati.

Navigazione contestuale all’interno delle azioni con possibilità di verifica con drill-down

Lista degli step di un WorkFlow

Visualizzazione del singolo step di azione

EVOLUZIONE DEL PROGETTO: SSR / RSS

Lo sviluppo di un progetto di Continuità Operativa applicato ad un datacenter esistente prevede più fasi di attuazione. La progettazione deve tener conto non solo dalla realizzazione al momento T0, ma anche della successiva gestione ed evoluzione.

La prima domanda alla quale dobbiamo dare risposta è se si vuole realizzare una Continuità Operativa con ridondanza nel singolo semi-site (redundant semi-site) oppure una ridondanza determinata dall’insieme dei due semi-site (semi-sites redundancy). Questa differenza in termini di costo è molto rilevante in quanto con una soluzione redundant semi-site (RSS) viene prevista una ridondanza delle infrastrutture su ogni singolo semi-site arrivando alla duplicazione totale delle componenti, in una ridondanza semi-sites redundancy (SSR) si raggiunge invece la ridondanza con la somma di almeno 2 semi-site:

SEMI-SITES REDUNDANCY (SSR)

REDUNDANT SEMI-SITE (RSS)

La differenza sostanziale tra le due soluzioni è che la soluzione SSR non prevede la doppia avaria mentre la soluzione RSS, in caso di non disponibilità di un intero sito, è in grado di sostenere ulteriori avarie locali. Queste soluzioni differiscono nella resilienza del singolo sito in caso di crash dell’omologo semi-site.

Anche se la scelta SSR o RSS è molto rilevante in termini di costo, da un punto di vista implementativo non presenta differenze sostanziali.

I simboli storage per entrambe le soluzioni sono rappresentati con un unico simbolo in quanto, tutti gli storage presenti sul mercato, hanno caratteristiche di persistenza dei dati in modalità ridondata attraverso tecnologie RAID. Unica caratteristica da verificare è la duplicazione delle teste di controllo (RAID CONTROLLER) sui singoli semi-site. Queste, in entrambe le soluzioni (SSR o RRS), è consigliabile siano duplicate. Sono sconsigliate soluzioni che prevedano una singola “testa” di controllo dello storage posizionata in ogni singolo semi-site.

CONSIGLIATO

SCONSIGLIATO

EVOLUZIONE DEL PROGETTO: CATEGORIZZAZIONE DEI SERVIZI

Una volta stabilita la resilienza (ridondanza) che si vuole ottenere nel singolo site, il focus deve essere orientato nella catalogazione dei servizi che devono essere posti in Continuità Operativa.

L’attività di catalogazione può essere eseguita in base alle schede di autovalutazione redatte da DigitPA che possono essere prese a riferimento anche in ambito privato.

La catalogazione deve avvenire per singolo servizio e deve comprendere le gerarchie di dipendenza delle singole componenti es.:

SERVIZIO 1
Authoritative DNS Addess xx.xx.xx.xx Server fisico ZZZZZ
Addess xx.xx.xx.xx Server fisico ZZZZZ
LBL ADC Address xx.xx.xx.xx Server fisico XXXX
Address xx.xx.xx.xx Server fisico YYYY
App server Address xx.xx.xx.xx JBOSS VMware
Address xx.xx.xx.xx JBOSS VMware
DB Server Address yy.yy.yy.yy Oracle Enterprise
SAN BBBB
SAN CCCC
Storage KKKK
SERVIZIO 2
Authoritative DNS Addess xx.xx.xx.xx Server fisico ZZZZZ
Addess xx.xx.xx.xx Server fisico ZZZZZ
LBL ADC Address xx.xx.xx.xx Server fisico XXXX
Address xx.xx.xx.xx Server fisico YYYY

La categorizzazione deve tendere ad evidenziare sia gli elementi “fisici” sia gli elementi logici come l’indirizzamento e/o la virtualizzazione. Già in questa fase è possibile distinguere per singolo servizio le dipendenze delle basi dati su cui poggiano. Per basi dati sono da intendersi anche eventuali servizi di Directory, Global File System, NAS.

Le dipendenze dei servizi sono anche da intendersi come dipendenze relative a sistemi di Single Sign On (SSO).

EVOLUZIONE DEL PROGETTO: CATEGORIZZAZIONE DEI DATI

La categorizzazione dei dati è diretta conseguenza della categorizzazione dei servizi. La categorizzazione dei dati è importantissima poiché la prima fase del progetto sarà la replicazione, in varie modalità, delle basi dati.

Per basi di dati si intendono diverse forme di memorizzazione dei dati che fondamentalmente possiamo suddividere in:

  1. NON STRUTTURATE
  2. STRUTTURATE

Per basi dati NON STRUTTURATE si intendono tutte le basi dati che contengono file o documenti non riconducibili ad una gestione astratta del dato: documenti word, file testo, pdf, immagini, html etc…

Per basi dati STRUTTURATE si intendono tutte le basi dati che hanno una gestione astratta del dato come: DB Relazionali, Directory Server.

Per la duplicazione delle basi di dati NON STRUTTURATE ci avvarremo delle tecnologie di REPLICAZIONE storage in modalità sincrona o asincrona in dipendenza delle capacità della connessione tra i due siti e della loro latenza.

Per le basi di dati STRUTTURATE la replicazione potrà avvenire in diverse modalità:

A) Attraverso gli strumenti di replicazione dei singoli prodotti (es. Oracle Dataguard,

Replicazione dei repository Active Directory o Directory server, MY SQL,

PostgreSQL, …)

B) Attraverso repliche SINCRONE degli storage

C) Attraverso repliche SINCRONE dei file system

In un ambito di Business Continuity sono da preferirsi, in entrambe le forme di base di dati, delle tecniche di replicazione SINCRONA mentre per il Disaster Recovery solitamente il limite è la connettività e la latenza e quindi si deve optare per una replicazione ASINCRONA. Sono da preferirsi e non sono obbligatorie in quanto alcune forme di replicazione di tipo (A) sono per loro natura ASINCRONE (vedi replicazione dei repository dei directory server) mentre per le repliche di tipo (B) e (C) sono da prendere in considerazione delle replicazioni in modalità SINCRONA dove permesso.

COSTI DIRETTI E INDIRETTI DELLA REPLICAZIONE:

Nella progettazione dei sistemi di replicazione sono da valutare i costi delle scelte che si andranno ad effettuare. In ambito campus, come quello in esame in questo documento, per costi diretti si intendono le spese relative all’acquisizione delle licenze hardware/software con relative manutenzioni. Nelle spese indirette si deve tener conto del costo di gestione delle tecniche di replicazione.

Per fare un esempio di come una scelta architetturale possa influenzare i costi diretti si pensi alla replicazione di basi di dati Oracle. Si possono immaginare 2 scenari, il primo in cui Oracle, attraverso Dataguard, effettuerà le repliche tra i due semi-site ed una seconda ipotesi in cui gli storage, in modalità SINCRONA, effettueranno la replicazione dei dati.

In questo caso, essendo entrambi i semi-site con istanze Oracle attive, le licenze dovranno essere conteggiate per entrambi i semi-site ed entrambe in forma Enterprise con relative manutenzioni.

Nel caso di storage replication dovranno essere conteggiate le licenze Oracle in forma Standard nel semi-site A (se la configurazione non supera i limiti della licenza Oracle Standard) e le licenze di replicazione sincrona per le componenti storage. Ovviamente dovranno essere conteggiate le manutenzioni di entrambi i prodotti.

I costi indiretti da conteggiare relativi a queste due opzioni sono da prevedersi sull’addestramento degli operatori che dovranno essere nel primo caso istruiti sia sulle tecniche di replicazione Oracle sia sulle tecniche di replicazione storage. Nel secondo caso dovranno essere addestrati solamente per la componente storage. L’addestramento dovrà essere effettuato sia per il personale che eseguirà le installazioni e configurazioni ma anche e soprattutto per coloro che dovranno gestire l’infrastruttura.

Per le componenti LBL®Commander la scelta di un’architettura rispetto ad un’altra è un’invariante. In un caso LBL®Commander dovrà invertire il flusso Dataguard e rendere primario il Semi-site B. Nel secondo caso effettuerà l’inversione delle repliche storage e attiverà l’istanza Oracle in STOP rendendola operativa.

Con l’avvento della virtualizzazione i sistemi di replicazione si stanno spostando rapidamente verso la replicazione delle immagini dei sistemi operativi GUEST che permettono una flessibilità non possibile in ambienti fisici e consentendo di avere sistemi differenti nei siti in replicazione.

Anche in questo caso per le componenti LBL®Commander la scelta di un’architettura rispetto ad un’altra è un’invariante. LBL®Commander gestirà l’avvio coordinato ed il setting dell’infrastruttura replicata durante l’evento di crisi. LBL®Commander contiene una serie di template per i più diffusi ambienti di virtualizzazione oltre a template per cambiamenti di indirizzi, zone DNS, attivazioni Database…

EVOLUZIONE DEL PROGETTO: SAN & STORAGE

 

Una volta ultimate le scelte architetturali più idonee in termini di costi/benefici ed in dipendenza degli obiettivi di alta affidabilità che si vogliono raggiungere il primo passo nella predisposizione del sistema di Continuità operativa è la realizzazione della connettività tra i due semi-site.

Immediatamente dopo aver predisposto la connettività si passerà alla predisposizione delle repliche storage-to-storage, database to database, Virtual Guest to Virtual Guest in base alla tabella di associazione servizi-dati predisposta in anticipo.

I primi test di replicazione è opportuno eseguirli su un set applicativo appositamente creato allo scopo di verificarne i comportamenti nelle diverse situazioni di utilizzo. In particolare le repliche dovranno essere prima impostate con gli strumenti messi a disposizione della piattaforma e quindi si procederà con i test di interruzione, ripresa della replica, inversione delle repliche etc.. E’ importante verificare le capacità di caching degli storage o dei sistemi di replicazione in assenza di connettività e impostare, se possibile, adeguate capacità di logging prima di dover avviare una ricostruzione totale.

Una volta determinate le potenzialità ed i comportamenti nelle varie situazioni di riallineamento, dovute a temporanee e/o prolungate disconnessioni dei due apparati, si procederà con i test delle funzionalità attraverso la command line (CLI) che con l’avvento del cloud tutti i produttori mettono a disposizione.

Per poter eseguire dei test significativi sarebbe opportuno predisporre un volume simile alla produzione in modo da poter registrare i tempi effettivi di ripristino nelle condizioni peggiori. Se la piattaforma lo permette, anche in base alle licenze acquisite, effettuare uno snapshot del volume da replicare, rendere il volume leggibile e scrivibile quindi impostare le repliche del volume ottenuto dallo snapshot.

Con alcune versioni storage high-end è possibile impostare delle repliche sincrone ed eseguire contemporaneamente il mount dei volumi (Primary e Replication) in lettura scrittura. Questa opzione, comunque utilizzabile in architetture global file system e applicazioni che lo supportino (es. Oracle RAC), non verrà analizzata in questo documento e si rimanda allo studio di implementazione di dettaglio.

Si riporta di seguito lo schema di mount contemporaneo del volume in replica utilizzabile normalmente con storage High-end. Si noti che il flusso di scrittura è comunque eseguito da un unico “controller” storage.

Altri test da eseguire si rimandano allo studio di implementazione di dettaglio.

EVOLUZIONE DEL PROGETTO: INDIRIZZAMENTO FISSO E DHCP

Il problema dell’indirizzamento dei servizi è un problema molto sentito in quanto i sistemi replicati, specie se in Disaster Recovery, devono avere indirizzamenti diversificati. La tecnica comunemente adottata nei datacenter fino ad oggi è dotare i servizi di indirizzi fissi mentre il DHCP è normalmente utilizzato per i client. L’utilizzo esteso di tecnologie di indirizzamento dinamico (DHCP) anche per i servizi server permette delle flessibilità in questi casi da tenere in considerazione per le prossime implementazioni. Questa tecnica, già utilizzata per servizi Cloud, è anche la strada per cominciare ad utilizzare l’indirizzamento IPv6 all’interno dei datacenter che avendo una rappresentazione poco “umana” deve essere utilizzato con nomi simbolici per essere ampiamente adottato.

In ogni caso la situazione da considerare è l’isolamento dei contesti applicativi ottenuto tramite vlan e vpn necessario per poter effettuare il minor numero di interventi sull’indirizzamento e lasciare la possibilità di effettuare liberamente, sia per BC sia per DR, dei test non invasivi da un punto di vista applicativo.

Si rimanda ad analisi di dettaglio tale importante considerazione, di seguito un esempio di indirizzamento incapsulato per permettere questo obiettivo.

In questo caso LBL ADC esegue un disaccoppiamento delle richieste dalle richieste applicative permettendo al sito in BC/DR di eseguire test non invasivi. Si rimanda la tematica routing pubblico globale ad altro documento.

EVOLUZIONE DEL PROGETTO: INFRASTRUCTURE SPLITTING

Una volta che le tecnologie di replicazione/riconciliazione storage sono state provate e verificate è possibile passare allo splitting dell’infrastruttura identificando le seguenti tipologie di servizi:

Tipologia Layer Elementi infrastrutturali
Servizi in bilanciamento AppServer WebServer
AppServer Applicatin Server
AppServer Exchange
AppServer SAS
Servizi in fail-over Data MS SQL Server
Data ORACLE
Data MySQL
AppServer SAP Produzione
Routing Router
Routing Firewall
Routing LBL®ADC
Servizi con replica sincrona autonoma Data Oracle dataguard
Data PostgreSQL
Servizi con replica asincrona autonoma Data Tipicamente servizi di Directory server
Routing DNS Server

La fase di splitting, da un site in due semi-site, è una fase importante e critica in quanto dovrà essere eseguita producendo meno disservizio possibile alle attività in produzione.

In questo caso, a titolo di esempio, prenderemo in considerazione una architettura SSR (Semi-sites redundancy) con spostamento quindi dell’attuale ridondanza del site esistente (semi-site A) nel nuovo site (semi site B). La ridondanza dei servizi sarà quindi il risultato della somma di entrambi i semi-site (semi-site A+semi-site B).

I primi elementi che verranno separati per lavorare nei due semi-site saranno gli elementi che nella tabella sono stati definiti come Routing. Il risultato che si vuole ottenere, in un primo momento, è un comportamento analogo all’attuale in produzione con i soli servizi di Routing suddivisi nei due datacenter.

Per ottenere questo risultato dovranno essere spostati (fisicamente o logicamente in caso di virtualizzazione) i sistemi in ridondanza e rispettivamente: Router, Firewall, LBL ADC. Questi sistemi dovranno mantenere autonomia locale in termini di boot, o da propri dischi interni o da Storage area network locale al semi-site B.

Schematicamente riportiamo di seguito lo splitting dei servizi di Routing:


Questa fase è essenziale per poter eseguire gli split dei layer applicativi producendo il minimo impatto nelle attività in esercizio. Questa attività di splitting dovrebbe avere impatto zero eseguendo lo spostamento delle componenti passive. Ovviamente si rimanda ad uno studio dettagliato per l’implementazione.

In questo documento preliminare prenderemo ora in esame lo splitting di un servizio lasciando allo studio di dettaglio, non oggetto di questo documento, la trattazione delle fasi di splitting dei singoli servizi.

Si prenderà ad esempio un servizio composto da Database senza replicazione autonoma e due Application Server in bilanciamento.

I servizi in bilanciamento di carico possono essere spostati nel semi-site B senza troppi problemi avendo cura di effettuare lo spostamento nei momenti di minor utilizzo.

Una considerazione importante è che i servizi che andremo a spostare dovranno essere autonomi relativamente al boot. Questo aspetto è da tener sempre presente anche in tutte le attività successive. Il semi-site B dovrà essere completamente autonomo e dovrà essere in grado di effettuare boot totali anche in assenza del semi-site A. Eventuali aree di mount in SAN dovranno essere posizionate nel semi-site B.

Lo split del DB Layer, dove prenderemo in esame un DB senza replicazione autonoma, avverrà in due fasi. La prima fase è relativa alla replicazione dell’area dati. La replicazione dovrà essere effettuata in maniera sincrona. Si predisporrà lo storage per replicare l’area dati riservata al DB. Prima di procedere oltre si dovrà attendere affinché lo storage in replica raggiunga la sincronizzazione con lo storage Primario (anche alcune ore).

Una volta che le repliche avranno raggiunto lo stato di sync si potrà procedere con lo spostamento della componente di ridondanza DB nel semi-site B. Anche in questo caso il boot dovrà essere completamente autonomo.

Per effettuare le prove di fail-over senza ripercussioni nella produzione utilizzeremo la tecnologia snapshot, la stessa utilizzata nei test preliminari della componente storage. Questa modalità di test è importante in quanto un volume in replica non può essere “montato” da un sistema operativo in lettura e scrittura. (E’ possibile effettuare “mount” in lettura/scrittura solo in presenza di file system globali e comunque su base applicativa certificata per tale modalità, come ad esempio Oracle RAC).

Il “mount” dello snap del volume DB in replica ci permette di poter effettuare i test senza interruzione della produzione e senza interruzione della replica. Altra considerazione nello spostamento del servizio di ridondanza DB è l’indirizzamento IP. E’ possibile utilizzare due metodologie, la prima con spostamento dell’indirizzo virtuale, la seconda con routing attraverso LBL ADC.

La prima soluzione ha come svantaggio la riconciliazione in caso di fail-over con il ritorno della connettività dopo interruzione temporanea, si avrebbe infatti un conflitto di indirizzi. Questa soluzione è sconsigliata in ambienti di Continuità Operativa in quanto, per casistiche, profondamente diversi rispetto ai cluster realizzati in singolo site e con dati condivisi (si rimanda al paragrafo CONTINUITA’ OPERATIVA: SCHENARIO).

La seconda ipotesi ha come vantaggi la possibilità di provare periodicamente le procedure di Business Continuity senza condizionare la produzione. Inoltre, in caso di fail-over e repentino ripristino della connettività tra i due semi-site, lo strato di instradamento ridirigerà, senza alcuna ambiguità o conflitto, il traffico verso il DB dichiarato Master. In LBL ADC questa modalità è stata prevista in fase di progettazione del prodotto con una puntuale politica di instradamento appositamente studiata per tali architetture.

Una volta eseguiti i test dell’istanza DB nel semi-site B si procederà con l’impostare le regole di routing nello strato di instradamento. Le regole di routing saranno impostate con politiche di bilanciamento “FailOver” in modo da indirizzare la giusta componente DB. Le componenti AppServer punteranno ora allo strato di instradamento e non più direttamente al DB.

L’infrastruttura è pronta per fornire il servizio in Business Continuity. Le operazioni che seguono serviranno ad automatizzare le azioni che in caso di avaria del semi-site A porteranno il semi-site B nello stato di Primario. La fase successiva sarà quindi la costruzione dei Workflow che automatizzeranno le operazioni.

N.B. Nell’immagine l’elemento [Routing], tra lo strato [App Layer] e [DB Layer], è stato introdotto per semplicità espositiva. Nella realtà sono regole di instradamento nello strato di bilanciamento. Nelle prossime immagini non saranno presenti per questo motivo.

EVOLUZIONE DEL PROGETTO: CONTINUITA’ OPERATIVA

La fase di predisposizione dei Workflow serve ad automatizzare le azioni che porteranno il semi-site B allo stato di Primario in caso di failure del semi-site A. Si procederà quindi alla impostazione dei seguenti Workflow:

Nome workflow Applicazione Descrizione
Graceful shutdown Semi-Site A Esegue uno shutdown controllato dei layer superstiti nel semi-site A dopo un evento di avaria del servizio.
Restart Semi-Site A (Opzionale) Esegue un restart degli elementi che normalmente sono la causa di una avaria dell’erogazione di un servizio. Questo workflow permette di non eseguire falsi fail-over in presenza di anomalie software di alcuni componenti come memory overflow, stackoverflow, loop etc.
Take Control Semi-Site B Esegue le operazioni che porteranno il Semi-Site B ad essere primario. Eseguirà in sequenza:

A) Inversione delle repliche storage

B) Start del DB Server

(NOTA in questo caso lo Strato applicativo AppServer, non ha necessità di intervento da parte del WorkFlow perché reinstradato automaticamente da LBL®ADC. In altri casi potrebbe essere necessario avviare macchine fisiche o virtuali o processi all’interno di sistemi già avviati).

Una volta ultimati i WorkFlow necessari alle procedure di fail-over si parametrizzeranno i decisori automatici LBL Commander Decision Engine.

Le tre istanze LBL Commander Decision Engine rimarranno in numero costante per tutti i servizi da porre in fail-over automatico. LBL Commander Decision Engine è stato studiato per verificare costantemente lo stato dell’erogazione dei servizi e/o delle sue componenti.

LBL ADC, istruito da LBL Commander Decision Engine, provvederà in maniera automatica ad indirizzare le richieste di servizio in maniera consistente con lo stato del cluster.

La centralizzazione della componente di Alta Affidabilità nel modulo LBL Commander Decision Engine permetterà di avere un’unica console di verifica dello stato dell’alta affidabilità di tutto il datacenter mettendo in evidenza eventuali situazioni critiche.

Esempio di Decision Engine con evidenziazione di una evenienza critica in un servzio

Esempio di WorkFlow con i suoi step procedurali autodocumentanti

Una volta terminate le procedure di fail-over è necessario, per una corretta gestione, delineare le procedure di fail-back per ritornare alla situazione iniziale una volta superato l’evento di che ha determinato la crisi.

EVOLUZIONE DEL PROGETTO: FAIL-BACK

Le procedure di fail-back sono importantissime nei processi di Continuità Operativa e/o Disaster Recovery. Con LBL®Commander Work Flow è possibile agire su tutti i livelli e in tutti i semi-site interessati da un’unica console. E’ quindi possibile predisporre in maniera coordinata tutte le procedure di fail-back comprese le azioni da porre in atto tra più semi-site. Al termine dell’operazione il semi-site A tornerà ad erogare i servizi come Primario.

Di seguito un esempio di procedura di fail-back descritto in un WorkFlow. I semi-site vengono portati all’inizio in uno stato noto, riconciliati e quindi viene ripristinata l’operatività iniziale e la fruibilità del servizio.

BENEFICI

Quanto descritto in questo documento prescinde in gran parte dalle componenti LBL A.A.I..

Le dinamiche, le casistiche e le procedure descritte sono indispensabili per porre in continuità operativa i servizi indipendentemente dall’adozione dell’infrastruttura LBL A.A.I..

I benefici dall’adozione delle componenti LBL A.A.I. rende il processo semplice, controllabile e ripetibile nel tempo. Di seguito i benefici dell’adozione delle componenti LBL A.A.I. in ambiente di Continuità Operativa.

LBL A.A.I. punti di forza

  • diminuzione delle spese per l’acquisto di licenze cluster (non più utilizzabili in questo contesto)
  • diminuzione delle spese derivate dall’acquisto di licenze enterprise dei sistemi operativi/virtualizzazione (spesso necessari per l’acquisto delle versioni cluster)
  • eliminazione degli indirizzi virtuali nel datacenter (derivati dall’eliminazione dei cluster di prima generazione)
  • centralizzazione delle politiche di alta affidabilità
  • automazione delle procedure su diversi layer, diversi sistemi operativi, diverse tecnologie di virtualizzazione, diversi semi-site
  • riproducibilità dei test di alta affidabilità in sicurezza e con minori spese
  • integrazione con sistemi di monitoring preesistenti
  • omogeneizzazione delle operazioni di Business Continuity/Disaster Recovery/Fast Disaster Recovery con un unico strumento
  • automazione dei restart applicativi prima delle promozione dei fail-over
  • automazione delle politiche di ripristino a fronte di eventi di fail-over
  • Moving applicativo per singolo servizio con automazione delle procedure di test ed entrata in esercizio
  • Predisposizione industriale del passaggio da progetto di implementazione alla gestione attraverso procedure auto-documentate
  • Risparmio nell’operatività della gestione attraverso WorkFlow

Le componenti LBL A.A.I. sono inoltre abilitanti alla gestione di procedure di Disaster Recovery realizzabili con diversi gradi di automazione.

CONCLUSIONI

L’introduzione di funzionalità di Continuità Operativa e/o Disaster Recovery in ambienti enterprise necessita di strumenti che agevolino e centralizzino l’operatività ed il controllo.

Il mantenimento di servizi in Continuità Operativa necessita di una impostazione “industriale” dei processi e delle procedure in maniera non dissimile all’introduzione della robotica nella produzione manifatturiera.

LBLA.A.I. non esegue azioni differenti da quanto una decisione umana non farebbe, “semplicemente” le automatizza e la rende ripetibili all’infinito nel tempo.

Sei interessato alle nostre soluzioni?