Contratto Quadro SPC Cloud Lotto 1 Introduzione nuovo servizio Disaster Recovery as a Services Piano di Attivazione

Identificativo	Titolo/Descrizione
Gara Cloud Lotto 1	Gara Cloud Lotto 1_Allegato5B Capitolato Tecnico
Gara Cloud Lotto 1	Gara Cloud Lotto 1_Allegato5A Capitolato Tecnico Parte Generale
Gara Cloud Lotto 1	Offerta Tecnica del Fornitore Allegato B Relazione Tecnica Lotto 1
Agenzia per L’Italia Digitale	Linee guida per il Disaster Recovery delle Pubbliche Amministrazioni

2.4. Definizioni ed Acronimi

Definizioni/Acronimi	Descrizione
DR	Disaster Recovery
DRaaS	Disaster Recovery as a Service
RPO	Recovery Point Object
RTI	Raggruppamento temporaneo d’Impresa
RTO	Recovery Time Object
SAN	Storage Area Network

3. Deployment del servizio

Nei capitoli successivi sono riportate le attività da effettuarsi per il deployment per le Amministrazioni che aderiranno al servizio DRaaS.

3.1. Check List per servizi DRaaS

Per rendere fruibile il servizio di Disaster Recovery, è necessaria un’analisi propedeutica dell’ambiente dell’Amministrazione, in termini di caratteristiche tecniche ed organizzative. Tale analisi ha come finalità l’individuazione di tutte le attività necessarie presso l’Amministrazione al fine di rendere fattibile un servizio di Disaster Recovery.

Di seguito è riportata una check list minimale di elementi necessari che dovranno essere presi in considerazione e specificati all’interno del Piano dei Fabbisogni dello specifico servizio di DRaaS.

La check list sarà specializzata in funzione della Classe di Servizio che dovrà supportare la soluzione di DRaaS.

3.2. Check List per servizi DR - Classe 2

Per rendere possibile l’implementazione del servizio la singola Amministrazione dovrà fornire almeno le informazioni di seguito riportate:

• Ubicazione Sito Data Center Amministrazione;

• Presenza connettività, se già presente indicare la tecnologia e la banda a disposizione;

• RPO e RTO richiesti;

• Indicare il numero di server e per ciascuno di esso se è un server fisico o virtuale;

• Nel caso in cui sia presente un ambiente di virtualizzazione, quale tecnologia è in uso presso l’Amministrazione.

• Sistemi operativi e patch level sia dei sistemi fisici che virtuali (es. Windows 2008 R2);

• Memoria, CPU, Dischi locali con relativo partizionamento e storage condiviso (es: 2 cpu xeon 3GHz dual-core, 4 GB di RAM, disco «C:» da 30 GB, disco «D:» da 200 GB, storage IBM N3000 con 5 TB);

• Lista delle applicazioni critiche (Posta, DB, ecc..);

• Indicazione se le applicazioni critiche su Windows usano VSS (Volume Shadow Copy Service) writers;

• Indicazione se le applicazioni critiche su Linux usano LVM (Logical Volume Manager);

• Indicazione se ci sono cluster con relativa versione e quorum mode (es. Windows server 2008 R2 in modalità «Node and Disk Majority»);

• Quantità di dati da proteggere;

• Frequenza di modifica dei dati da proteggere (in GB al giorno, ora, ecc..);

• Servizi aggiuntivi oltre a quelli base che compongono il servizio DRaaS Classe 2 descritti nel documento Specifiche Funzionali del Servizio.

3.3. Check List DR – Classe 3

In questo scenario è innanzitutto necessario che la singola Amministrazione fornisca le informazioni necessarie alla definizione della soluzione. Sono possibili due scenari:

• Scenario 1: l’Amministrazione fornisce informazioni relative alle write I/O generate dai server e sulla banda disponibile. In base a questi valori RTI è in grado di fornire l’indicazione sull’RPO raggiungibile con la soluzione implementata;

• Scenario 2: l’Amministrazione fornisce informazioni relative alle write I/O generate dai server e sul valore di RPO che vuole ottenere. In base a questi valori RTI fornisce l’indicazione sulla banda minima richiesta per il canale di trasferimento.

La RTI può garantire che il dato sia accessibile in modalità read/write sullo storage del sito secondario nell’esatto momento in cui gli host virtuali, hanno la visibilità dello storage stesso. Pertanto bisognerà aspettare la ripartenza delle componenti applicative.

Più in generale l’Amministrazione dovrà fornire una serie di informazioni per consentire a RTI di verificare l’applicabilità della soluzione DR – Classe 3:

• Ubicazione Sito Data Center Amministrazione;

• Presenza connettività TIM, se già presente indicare la tecnologia e la banda a disposizione;

• RPO e RTO richiesti;

• Per ogni server presso l’Amministrazione si dovrà:

o Indicare se è un server fisico o virtuale;

o Nel caso in cui sia presente un ambiente di virtualizzazione, quale tecnologia è in uso presso l’Amministrazione;

o Sistemi operativi e patch level sia dei sistemi fisici che virtuali (es. Windows 2008 R2);

o N. CPU e tipo;

o Quantità Xxx;

o Modello HBA presenti sui server e relativa ridondanza (ce ne devono essere almeno 2);

o Spazio disco visto da ogni server;

o Software di cluster utilizzato (se in cluster);

o Software di multipath;

o Numero di write I/O generate dai server (informazione opzionale, ma necessaria nella successiva fase di progettazione di dettaglio per determinare necessità di banda geografica e possibilità di raggiungimento dell’RPO richiesto).

• Storage Amministrazione:

o Modello/i;

o Livello di firmware storage;

o TB utili da replicare.

• Modello switch o director della SAN

o Livello di firmware;

o Numero porte libere;

• Servizi aggiuntivi oltre a quelli base che compongono il servizio DRaaS Classe 3 descritti nel documento Specifiche Funzionali del Servizio.

3.4. Piano dei fabbisogni

L’attività indispensabile per l’implementazione del servizio di DRaaS è la definizione da parte della specifica Amministrazione del proprio Piano dei Fabbisogni. Per tale attività l’Amministrazione sarà supportata da un team di Progettazione che sarà messo a disposizione dalla RTI e che aiuterà l’Amministrazione stessa a definire il proprio contesto operativo e le modalità di evoluzione verso il servizio DRaaS proposto.

Il supporto alle Amministrazioni si configurerà, tipicamente, in modo diverso a seconda delle dimensioni e della complessità della singola Amministrazione. Per una grande Amministrazione occorrerà condurre attività di analisi approfondite, coinvolgendo diversi uffici e valutando un'ampia gamma di elementi. Per le Amministrazioni più piccole le attività saranno di norma più snelle e faranno riferimento a modelli standardizzati, concordati con Consip/AgID nelle fasi di avviamento del Servizio.

Una volta conclusa la propria analisi, l'Amministrazione avrà tutti gli elementi per prendere una decisione consapevole e stabilire se e fino a che punto aderire al nuovo modello, procedendo in quest'ultimo caso a definire il proprio Piano dei Fabbisogni.

3.5. Progetto dei fabbisogni

Il team di Progettazione della RTI, ricevuto dall’Amministrazione il documento “Piano dei Fabbisogni”, predisporrà il documento “Progetto dei Fabbisogni”, avvalendosi del supporto dell'intera struttura organizzativa del Raggruppamento.

Il documento “Progetto dei Fabbisogni” sarà quindi consegnato all’Amministrazione. Il suddetto documento conterrà:

• “Costi” previsti per la realizzazione del progetto;

• “Modalità di presentazione e approvazione degli Stati di Avanzamento Mensili”;

• “Piano di Attuazione”, articolato nei seguenti allegati:

o “Piano operativo”;

o “Documento programmatico di gestione della sicurezza dell’Amministrazione”;

o “Specifiche di dettaglio della realizzazione dei servizi richiesti e specifiche di controllo della qualità degli stessi”.

Il Piano di Attuazione saranno descritte le attività e procedure che la RTI metterà in atto nel processo di migrazione dei servizi, al fine di minimizzare l’impatto sull’operatività dei servizi erogati e nel pieno rispetto di quanto richiesto da AGID/Consip delle prescrizioni fornite al paragrafo 7.2.4 del Capitolato Tecnico Generale alla Gara Cloud Lotto1.

Il Progetto dei Fabbisogni potrà essere modificato e/o aggiornato dall’Amministrazione ogni qualvolta questa lo ritenga necessario. In particolare, il processo di migrazione proposto sarà concordato e sottoposto all’approvazione dell’Amministrazione oggetto di migrazione dei servizi.

3.6. Disaster Recovery Plan

Fondamentale per l’implementazione del servizio di DR è la stesura del documento Disater Recovery Plan (DRP) che può essere fatto in autonomia dalla singola Amministrazione oppure in collaborazione con la RTI.

Il DRP rappresenta il documento di progettazione e pianificazione delle attività per ripristinare lo stato del Sistema Informativo, che eroga i servizi IT della specifica Amministrazione a fronte di un evento disastroso che ne compromette la funzionalità. Per evento disastroso si deve intendere una grave anomalia di qualsiasi natura, non più gestibile secondo le procedure ordinarie di Incident e Problem Management, che causi l’interruzione prolungata di uno o più servizi IT erogati. Questo evento richiede un intervento coordinato di più strutture specialistiche con l’obiettivo di ripristinare l’operatività dei servizi IT interessati nel rispetto dei livelli di servizio concordati.

All’interno del DRP saranno presenti le seguenti informazioni:

• struttura organizzativa dedicata alle esigenze del DR

• Indicazione dei siti coinvolti;

• elenco delle Applicazioni oggetto del DR

• constatazione evento disastroso

• attivazione DR

• esercizio provvisorio

• ritorno normalità sul sito primario

• elenco e contatti del personale dell’’organizzazione del DR

Il RTI collabora con l’Amministrazione nella stesura del DRP fornendo la documentazione sull’ambiente di DR, le procedure di attivazione del servizio di DR Test e le procedure di attivazione del servizio in caso di evento disastroso.

3.6.1.Struttura organizzativa dedicata alle esigenze del DR

All’interno del DRP verrà descritta la struttura organizzativa dedicata alla gestione ed esecuzione delle attività del Disaster Recovery.

La presenza di tale struttura è necessaria al fine di ottenere i seguenti benefici:

• Creazione di una struttura di governo;

• Identificazione chiara delle responsabilità e allocazione dei task;

• Abilitazione delle autorizzazioni;

• Supporto all’integrazione con organizzazioni esterne;

• Coordinamento del processo di ripristino e rientro.

A titolo di esempio, la struttura organizzativa si può pensare strutturata su 2 livelli:

• Struttura Decisionale o di Governo del DR:

o Comitato Direttivo e di Emergenza

o Gruppo di Coordinamento

• Struttura Operativa di DR in cui sono rappresentati i diversi gruppi operativi quali ad esempio:

o Gruppo sistemi

o Gruppo rete

o Gruppo sicurezza/SOC

o Gruppo supporto applicativo

o Gruppo logistica ed organizzazione

o Service Desk

Il Comitato Direttivo, costituito dal Responsabile dell’Amministrazione, dai Responsabili IT dell’Amministrazione dai Responsabili della RTI, ha la responsabilità di valutare l'entità di un eventuale danno o situazione di crisi e quindi di attivare le opportune procedure di gestione dell’emergenza.

In condizioni di emergenza il Comitato Direttivo assume il controllo di tutte le operazioni.

Il Gruppo di Coordinamento è costituito dai responsabili delle Strutture Tecniche e dai responsabili delle Conduzioni Funzionali (Responsabili di Applicazione) che gestiscono le applicazioni; esso collabora con il Comitato Direttivo nella fase di valutazione del danno, fornendo così un supporto alla decisione finale. Inoltre, assume la gestione ed ha la responsabilità del corretto svolgimento delle procedure di ripristino e rientro.

I Gruppi Operativi sono costituiti da personale dell’Amministrazione e della RTI, con elevate competenze sistemistiche, gestionali ed operative, in grado di intervenire operativamente sugli apparati IT e sulle configurazioni al momento del verificarsi del disastro, in quanto disponibili o in turno di reperibilità.

3.6.2.Indicazione dei siti coinvolti

Nel DRP sarà riportata l’indicazione dell’ubicazione dei siti coinvolti (sito principale e sito di DR).

3.6.3.Elenco delle Applicazioni oggetto del DR

Nel DPR saranno indicate le applicazioni/servizi che devono essere disponibili sul sito di DR. Non tutte le applicazioni/servizi presentano infatti lo stesso livello di criticità e pertanto l’Amministrazione potrebbe non ritenere necessaria l’attivazione completa dei servizi del sito primario sul sito di DR.

3.6.4.Constatazione evento disastroso

Nel DPR sarà descritto il processo per la definizione dell’evento disastroso a fronte del quale si rende necessaria attivare la procedura di DR.

La rilevazione dell’evento disastroso è ovviamente dipendente dalla gravità e dalla evidenza dello stesso oltre ad altre variabili come ad esempio l’orario in cui si esso si verifica. Pertanto la segnalazione alle strutture preposte alla gestione di impatto dell’evento può seguire percorsi differenti in funzione di tali aspetti.

Alcune condizioni che determinano la necessità di attivare la procedura di valutazione dell’evento disastroso sono:

• la distruzione parziale o totale delle infrastrutture nel Data Center;

• l’impossibilità di accedere ai locali CED e/o di controllare il funzionamento degli apparati in esso ospitati per un tempo indeterminato;

• l’impossibilità di erogare servizi per un tempo significativo e per una quota significativa dell’utenza

In una situazione evidente di emergenza è di importanza fondamentale l’immediatezza da parte di tutto il personale coinvolto nelle varie attività aziendali, nel recepire e segnalare tempestivamente al Personale preposto un evento potenzialmente disastroso, indicandone la tipologia ed il livello di gravità, affinché venga attivato il Gruppo di Coordinamento per la valutazione del danno.

Il Gruppo di Coordinamento acquisisce le informazioni relative all’evento disastroso in modo da delineare lo scenario della crisi e valutare le azioni da attivare.

Il gruppo di Xxxxxxxxxxxxx informerà quindi il Comitato Xxxxxxxxx che deciderà se dichiarare lo stato di DR o se utilizzare soluzioni alternative per la risoluzione della crisi.

Il Comitato Direttivo comunica la propria decisione al Gruppo di Coordinamento che provvede all’attuazione del piano di recovery.

3.6.5.Attivazione DR

Il Gruppo di Coordinamento ha la responsabilità di questa attività e pertanto attiva i gruppi Operativi per lo svolgimento di tutte le attività da eseguire durante l’Emergenza, finalizzate al recupero e al riavvio dei servizi applicativi sul sito secondario.

Nel DRP sarà inoltre descritta la procedura per il passaggio al sito secondario

3.6.6.Esercizio provvisorio

L’attivazione di tutte le applicazioni/servizi sul sito secondario conclude la fase di attivazione del DR: da questo momento viene garantita la normale operatività delle applicazioni sul sito secondario per tutto il tempo necessario al ripristino del sito primario.

Con normale operatività sono intese tutte le attività che garantiscono le funzionalità dei server e dello storage relativo alle applicazioni indicate dalle Amministrazioni come critiche.

3.6.7.Ritorno normalità sul sito primario

Nel DRP verranno indicate le modalità di ritorno sul sito primario una volta che quest’ultimo è nuovamente operativo.

In generale, ricostituita l’operatività del sito primario, il Gruppo di Coordinamento definisce nel dettaglio il piano di rientro che propone all’approvazione del Comitato Direttivo. Le attività del piano di rientro vengono effettuate dai gruppi Operativi opportunamente supervisionati dal Gruppo di Coordinamento.

Ripristinata la normale operatività del sito Primario, il Comitato Direttivo dichiara la fine dello stato di Emergenza.

Il ritorno all’operatività su di esso sarà comunque subordinato ad una fase di verifica e progettazione.

3.6.8.Xxxxxx e contatti del personale dell’organizzazione del DR

Nel DRP sarà riportato un elenco dei nomativi del personale dell’Amministrazione e se previsto della RTI che costituisce l’organizzazione del DR. Per ciascun nominativo saranno indicati: ruolo, mail e cellulare.

3.7. Implementazione del servizio

Per l’attivazione del servizio verranno effettuate le attività di seguito descritte per ciascuna delle quali vengono fornite delle tempistiche indicative e non vincolanti in quanto le tempistiche dipendono dalla specifica architettura della singola Amministrazione. La valutazione degli elementi progettuali consentirà la pianificazione in giorni lavorativi delle attività. La suddetta pianificazione sarà riportata nel Progetto dei Fabbisogni.

Le attività relative all’implementazione del servizio avranno inizio dopo l’approvazione da parte dell’Amministrazione del Progetto dei Fabbisogni e la conseguente stipula del Contratto Esecutivo.

3.7.1.Predisposizione connettività

La connettività sarà fornita dall’Amministrazione. In caso di connettività dedicata la banda dovrà essere dimensionata sulla base dei volumi di dati previsti nel progetto e l’RPO richiesto mentre in caso di connessione VPN su Internet dovrà essere stata fatta preliminarmente un’analisi della capacità di banda Internet presente presso il sito Primario ed un’analisi dell’utilizzo medio della stessa, al fine di stimare la capacità di accogliere il traffico aggiuntivo relativo alla replica dei dati.

In caso di connettività SPC all’attivazione della stessa si provvede alla configurazione del routing e delle regole dei firewall in modo che la replica dei dati fra gli ambienti possa essere attivata correttamente.

In caso di connessione VPN su Internet si procederà alla configurazione della VPN, allo scopo in caso di soluzione OpenStack sarà onere dell’Amministrazione predisporre un apparato o software VPN presso il sito Primario mentre sul sito di DR verrà predisposto un terminatore VPN software.

Si ricorda che nel caso la connettività tra i due siti Primario e DR sia di tipo Internet non sarà possibile garantire il valore del parametro di RPO in quanto la connettività Internet non fornisce una banda garantita end to end.

Per le attività sopra descritte si stima un tempo pari a 15 giorni lavorativi

3.7.2.Verifica e predisposizione di sicurezza (Firewall, VPN)

Si procederà alla configurazione dei firewall infrastrutturali e alla creazione della VPN idonea a garantire la visibilità fra i sistemi interessati tra sito primario e sito di DR.

Per questa attività si stima un tempo pari a 15 giorni lavorativi

3.7.3.Allocazione risorse sul data center

Questa attività prevede la configurazione delle risorse elaborative dell’ambiente OpenStack sul sito di DR in base alle configurazioni definite nel disegno di dettaglio.

In caso di soluzione Double Take, per la soluzione DR - Classe 2 questa fase include la configurazione della VM relativa al Repository Double Take (o soluzione equivalente).

In caso di soluzione Coriolis, questa fase include la configurazione della VM di replica di Xxxxxxxx sia per lo scenario DR – Classe 2 che per lo scenario DR – Classe 3.

Per entrambi gli scenari per questa attività su stima un tempo di 20 giorni lavorativi.

3.7.4.Configurazione replica

Lo scopo di questa attività è quello di installare e configurare il SW/Appliance deputata alla replica.

Nel caso di utilizzo della piattaforma Double Take l’attività prevede l’installazione degli Agent Double Take sui server di Produzione oggetto del servizio. Saranno inoltre installati:

• Per il servizio Classe 2: il software Double Take (o soluzione equivalente) sulla VM di repository;

• Per il servizio Classe 3: gli agent Double Take (o soluzione equivalente) sulle VM configurate nell’ambiente di DR.

Nel caso di utilizzo della piattaforma Coriolis per entrambe le classi di servizio l’attività prevede l’installazione del SW Coriolis sul tenant predisposto nell’ambiente di DR.

Per entrambi gli scenari per lo svolgimento dell’attività si stima un tempo pari a 20 giorni lavorativi.

3.7.5.Configurazione delle politiche di accesso all’ambiente di DR

Lo scopo di questa attività è quello di configurare la rete ed i firewall in modo da permettere l’accesso all’ambiente di DR da parte dell’Amministrazione e dei prodotti che gestiscono la replica.

In questa attività è inoltre compresa la configurazione della rete e degli accessi per permettere la corretta erogazione dei servizi applicativi durante il periodo di disastro. Tale configurazione, opportunamente descritta nel Piano di Disaster Recovery, potrà poi essere disabilitata al rientro del disastro e sarà attivata successivamente solo in caso di Disastro.

Per questa attività si stima un tempo pari a 10 giorni lavorativi.

3.8. Collaudo

Terminata l’implementazione del servizio per la singola Amministrazione verrà effettuato un collaudo atto a verificare il corretto funzionamento del servizio stesso. Tale collaudo o primo test di DR, non è soggetto alla misurazione di SLA e penali secondo quanto descritto per i servizi di erogazione del DRaaS.

La descrizione delle schede di test per i servizi di DR che l’Amministrazione intende effettuare verrà predisposta, e concordata con l’Amministrazione stessa durante la fase di delivery del servizio.

In generale i test saranno eseguiti secondo il seguente processo:

1) configurazione del servizio, degli apparati e degli strumenti in base a quanto specificato nella scheda di test;

2) esecuzione dei test secondo quanto descritto nelle relative scheda;

3) per ciascun test sulla scheda tecnica verrà riportato l’esito. In caso di esito è negativo sulla scheda all’anomalia rilevata verrà associata un livello di gravità (bloccante, grave, accettabile).

Il collaudo si ritiene superato solo nel caso in cui non siano presenti anomalie classificate come gravi o bloccanti.

In presenza di anomalie gravi e/o bloccanti, a seguito dell’analisi che verrà effettuata, verranno intraprese dalle parti le azioni correttive e si procederà ad una nuova programmazione del collaudo.

Il Piano di Test sarà articolato in schede che a titolo di esempio possono essere divise nelle seguenti sezioni:

Campo	Significato
Requisito	Identificativo del requisito oggetto del test
Scopo	Riassume l’obiettivo del test
Modalità di esecuzione	Indica la modalità di esecuzione del test, ad esempio per accesso diretto alla piattaforma, iniziando dall’accesso all’ambiente.
Scenario di riferimento	Descrive lo ‘scenario utente’ nel quale avviene il test e le condizioni che caratterizzano lo scenario
Macro azioni	Sono i passi operativi che si compiono durante la rappresentazione del test.
Risultato atteso	E’ lo scenario utente atteso, a seguito dell’esecuzione del test.
Esito del test	E’ l’esito del test, positivo se lo scenario ottenuto a seguito del test coincide con lo scenario atteso, negativo in caso contrario.

Di seguito viene riportato un esempio degli elementi oggetto dei test e di verifica.

• Verifica del piano di indirizzamento IP (ante e post switching procedura di DR) dei server sul sito remoto;

• Verifica del trasporto del protocollo IP all’interno del sito remoto e raggiungibilità degli apparati dal sito sorgente;

• Verifica della disponibilità dello storage su sito remoto;

• Verifica del funzionamento del software di replica;

• Verifica della corretta ripartenza dei sistemi e della consistenza dei dati;

• Verifica del rispetto dei parametri di RTO ed RPO contrattualizzati.

La durata del collaudo verrà definita con ciascuna Amministrazione sulla base dei test concordati.

Document Metadata

Table of Contents

Contratto Quadro SPC Cloud Lotto 1 Introduzione nuovo servizio Disaster Recovery as a Services Piano di Attivazione

Document Metadata