SPC CLOUD LOTTO1
PROGETTO dei FABBISOGNI
per la fornitura di “Servizi di Cloud Computing”
SPC CLOUD LOTTO1
Servizi 2019 - 2020
ROMA CAPITALE
Firmato digitalmente da: XXXXXXXX XXXXXXXXXX TIM S.p.A./00488410010
Firmato il 18/06/2019 14:52
Seriale Certificato: 445219
Valido dal 20/03/2019 al 19/03/2022
TI Trust Technologies CA
REDATTO da: (Autore) | TELECOM ITALIA S.p.A. DXC Tecnology S.r.l. | |
APPROVATO da: (Proprietario) | TELECOM ITALIA S.p.A. DXC Tecnology S.r.l. | |
LISTA DI DISTRIBUZIONE: | RTI Roma Capitale |
SOMMARIO
0 REGISTRAZIONE MODIFICHE DOCUMENTO 4
1 SCOPO DEL DOCUMENTO 5
2 AMBITO 5
3 DEFINIZIONI ED ACRONIMI 6
4 RIFERIMENTI 6
4.1 Documenti contrattuali 6
4.2 Documenti di riferimento 6
4.3 Riferimenti alla documentazione contrattuale e al Portale di Governance 7
5 DESCRIZIONE DEL CONTESTO 7
6 PROPOSTA PROGETTUALE 7
7 TASK DI ATTUAZIONE DEL PROGETTO 8
7.1 Migrazione Sistemi su nuova Rete 9
7.2 Censimento 9
7.3 Ingegnerizzazione e popolamento piattaforma OpenStack 10
7.4 Disaster Recovery 10
7.4.1 Ambito X86 11
7.4.2 Ambito Power IBM 12
7.4.3 Storage e replica dati 12
7.4.4 Vincoli e prerequisiti 12
7.4.5 Effort e tempi 12
7.5 Framework WSO2 12
7.6 Presa in carico area storage 13
8 STRUTTURA FUNZIONALE E ORGANIZZATIVA 13
9 SERVIZI A SUPPORTO DEL PROGETTO 14
9.1 Servizio IaaS di Virtual Data Center (Id. servizio L1.S1.2) 14
9.2 Servizio Disaster Recovery as a service (DRaaS) 14
9.2.1 Sede di erogazione dei servizi IaaS e DRaaS 15
9.2.2 Data prevista attivazione 15
9.3 Servizi di supporto specialistico per Cloud Enabling (Id. Servizio L1.S6) 15
9.3.1 Distribuzione dei servizi professionali nello sviluppo temporale del progetto 15
9.3.2 Sede di erogazione dei servizi 15
9.3.3 Data prevista attivazione e durata 15
9.3.4 Impegni servizi professionali 15
10 PIANO DI QUALITÀ 16
11 DOCUMENTO PROGRAMMATICO DI GESTIONE DELLA SICUREZZA DELL’AMMINISTRAZIONE 16
12 SPECIFICHE DI COLLAUDO 16
13 MODALITÀ DI PRESENTAZIONE E APPROVAZIONE STATI AVANZAMENTO MENSILI 16
14 RIEPILOGO ECONOMICO DEI SERVIZI 16
15 ULTERIORI COMPONENTI DI SERVIZIO NON INCLUSE NELL’OFFERTA 16
0 REGISTRAZIONE MODIFICHE DOCUMENTO
La tabella seguente riporta la registrazione delle modifiche apportate al documento.
DESCRIZIONE MODIFICA | VERSIONE | |
Prima emissione | 1.0 | 17/06/2019 |
1 SCOPO DEL DOCUMENTO
Il presente documento ha lo scopo di raccogliere le richieste di Roma Capitale (di seguito Amministrazione), contenute nel Piano dei Fabbisogni trasmesso in data 12/06/2019 e di formulare una proposta tecnico economica del RTI (di seguito Fornitore) costituito dalle società Telecom Italia S.p.A., Enterprise Services Italia S.r.l., Poste Italiane S.p.A., Postecom S.p.A. e Postel S.p.A., secondo le modalità tecniche ed il listino previsti nel Contratto Quadro e successivo Addendum – SPC Cloud Lotto 1 per la fornitura di “Servizi di Cloud Computing”.
Tale proposta integra, sia dal punto di vista dei servizi e sia dal punto di vista temporale, quanto relativo al Progetto dei Fabbisogni rif. Doc. 1702438750586003PJFV2 del 22 maggio 2018 e relativa struttura contrattuale. La richiesta dell’Amministrazione individua diverse ulteriori aree di intervento progettuale ed estende la durata dei servizi fino al 31 dicembre 2020.
2 AMBITO
Il contratto per la fornitura dei servizi di Cloud Computing per le Pubbliche Amministrazioni nell’ambito del Contratto Quadro SPC Lotto 1 e nel successivo Addendum stipulati tra Consip S.p.A. ed il Raggruppamento Temporaneo di Impresa (RTI) costituito da:
• Telecom Italia S.p.A. (mandataria)
• Enterprise Services Italia S.r.l. (già HPE Services Italia S.r.l.)
• Poste Italiane S.p.A.
• Postel S.p.A.
prevede la fornitura dei seguenti servizi di Cloud Computing nell’ambito del Sistema Pubblico di Connettività e Cooperazione (SPC):
• servizi di tipo Infrastructure as a Service (IaaS);
• servizi di tipo Platform as a Service (PaaS);
• servizi di tipo Software as a Service (SaaS);
• servizio di tipo Disaster Recovery as a Service (DRaaS);
• servizi di Cloud Enabling.
secondo quanto stabilito nel Capitolato Tecnico e nell’Offerta Tecnica, nella misura richiesta dalle Amministrazioni contraenti con i Contratti Esecutivi in attuazione del Contratto Quadro Lotto 1 e successivi Addendum al Contratto Quadro.
Telecom Italia, in qualità di mandataria, avrà in carico tutte le attività propedeutiche all’attivazione dei servizi contrattualizzati dall’Amministrazione Contraente relative alla ricezione dei Piani dei Fabbisogni, al conseguente invio dei relativi Progetti di Fabbisogni ed all’accettazione dei Contratti esecutivi.
In particolare la procedura per l’affidamento dei predetti servizi è articolata attraverso la stipula da parte di Consip S.p.A. del Contratto Quadro Lotto 1 con l’Aggiudicatario della procedura medesima, che si impegna a stipulare, con le singole Amministrazioni Contraenti, Contratti esecutivi aventi ad oggetto i predetti servizi alle condizioni stabilite nel Contratto Quadro Lotto 1 e nei siccessivi addendum. I singoli Contratti Esecutivi di Fornitura avranno una durata decorrente dalla data di stipula del Contratto Esecutivo medesimo e sino al massimo della scadenza ultima, eventualmente prorogata del Contratto Quadro Lotto 1 e Addendum.
Le singole Amministrazioni contraenti potranno richiedere una proroga temporale dei singoli Contratti Esecutivi di Fornitura al solo fine di consentire la migrazione dei servizi ad un nuovo Fornitore al termine del Contratto Quadro e Addendum, qualora la selezione dell’Operatore Economico subentrante non sia intervenuta entro i 3 mesi antecedenti la scadenza del Contratto Quadro Lotto 1.
Il Progetto dei Fabbisogni è sottoposto ad approvazione e può essere modificato o aggiornato dalla Amministrazione con eventuali modifiche o integrazioni. Il Fornitore si impegna a aggiornare o modificare il Progetto dei Fabbisogni entro 15 (quindici) giorni solari dalla ricezione della comunicazione di modifiche e/o integrazioni.
Il Progetto dei Fabbisogni, è infine, approvato da parte dell’Amministrazione mediante stipula del Contratto Esecutivo.
Nel corso di durata del Contratto Esecutivo, l’Amministrazione può variare e/o aggiornare il Piano dei Fabbisogni ogni qualvolta lo ritenga necessario in ragione delle proprie esigenze ed al mutare delle stesse. In tale caso il Fornitore provvede all’aggiornamento del Progetto dei Fabbisogni nei tempi e modi definiti nel Contratto Esecutivo, ai fini della nuova approvazione da parte dell’Amministrazione Beneficiaria.
3 DEFINIZIONI ED ACRONIMI
La seguente tabella riporta le descrizioni o i significati degli acronimi e delle abbreviazioni presenti nel documento.
Acronimi | Descrizione |
AgID | Agenzia per l’Italia Digitale |
Amministrazione | Roma Capitale |
CED | Centro elaborazione dati |
CONSIP | Consip S.p.A. |
IaaS | Infrastructure as a Service |
PaaS | Platform as a Service |
SaaS | Software as a Service |
DRaaS | Disaster Recovery as a Service |
BaaS | Backup as a Service |
GED | Gestione Elettronica Documentale |
SPC | Sistema Pubblico di Connettività |
Piano dei Fabbisogni | |
PjF | Progetto dei Fabbisogni |
RTI | Raggruppamento Temporaneo di Imprese |
SPF0x | Servizi Professionali Figura |
VDC | Virtual Data Center |
VN | Virtual Network |
Tabella – Glossario
4 RIFERIMENTI
4.1 Documenti contrattuali
Rif. | Documento |
#1 | PIANO dei Fabbisogni SERVIZIO presentato il 12/09/2019 Prot. Num. GU20190008332 del 12/06/2019 |
Tabella dei documenti di contrattuali
4.2 Documenti di riferimento
La seguente tabella riporta i documenti che costituiscono il riferimento a quanto esposto nel seguito del presente documento.
Rif. | Documento |
#1 | BANDO DI GARA D’APPALTO – CONSIP S.p.A. |
#2 | LOTTO 1 - Relazione Tecnica “Procedura ristretta suddivisa in 4 lotti per l’affidamento di Servizi di Cloud Computing, di Sicurezza, di Soluzioni di Portali di Servizi online e di Cooperazione Applicativa per le Pubbliche Amministrazioni” (ID SIGEF 1403)” |
Rif. | Documento |
#3 | CAPITOLATO TECNICO – PARTE GENERALE – “Procedura ristretta suddivisa in 4 lotti per l’affidamento di Servizi di Cloud Computing, di Sicurezza, di Soluzioni di Portali di Servizi online e di Cooperazione Applicativa per le Pubbliche Amministrazioni” (ID SIGEF 1403)” |
#4 | Piano di Sicurezza dei Centri Servizi e Centri Servizi Ausiliari Cod. XX0000000 |
#5 | Specifiche di dettaglio delle prove di collaudo dei servizi in ambiente di test (Test Bed) |
#6 | Piano di Qualità CONSIP - Piano della Qualità Generale Lotto 1 SPCC_RTI_PianoQualitàGeneraleLotto1_x.y |
Tabella dei documenti di riferimento
4.3 Riferimenti alla documentazione contrattuale e al Portale di Governance
La documentazione contrattuale è disponibile al seguente indirizzo xxx.xxxxxx.xx/xxxx_xx_xxxxxx/0000/0/xxxxxxx_0000. Il Portale di Governo e Gestione della Fornitura è raggiungibile all’indirizzo:: xxx.xxxxxxxx.xx
5 DESCRIZIONE DEL CONTESTO
Nel Piano Strategico di Sviluppo 2019-2021, l’Amministrazione Capitolina ha espresso la volontà di rafforzare il percorso di innovazione del proprio comparto IT, per adeguarlo alla parallela evoluzione e razionalizzazione della macchina amministrativa. La fase di profonda trasformazione investe l’organizzazione, i servizi, i processi, l’impianto applicativo e infrastrutturale.
In ambito applicativo sono in corso di introduzione nuovi modelli e framework di sviluppo, nella consapevolezza che occorre impostare i nuovi progetti secondo le best practices di mercato: DevOps, CI/CD, Container, Ambienti operativi Open e utilizzo di piattaforme standard di Community Cloud; nel contempo, si sta operando per estendere la trasformazione anche al parco applicativo esistente, avviando progetti di progressivo adeguamento alle soluzioni alla base dell’innovazione tecnologica.
Lo sforzo innovativo dell’Amministrazione si colloca in uno scenario di trasformazione più ampio, che ha lo scopo di realizzare nel proprio CED un nuovo modello di erogazione, basato su una infrastruttura omologa a quella che supporta il modello di erogazione dei servizi Cloud SPC e in corso di realizzazione nel Data Center dell’Amministrazione Capitolina. L’obiettivo è sostenere l’innovazione dei sistemi applicativi attuali e l’allineamento alle nuove tecnologie di quelli previsti o in fase di realizzazione, risultati indispensabili per rendere il contesto IT compatibile con le caratteristiche di un moderno Data Center, compatibile con i servizi erogati da Roma Capitale e nell’ottica dell’estensione dei servizi ad altre amministrazioni.
Il quadro si completa con le iniziative finalizzate alla predisposizione di un nuovo Data Center di Disaster Recovery, in uno dei siti SPC, rispondenti a tutti i requisiti previsti dalla norma, e che dovrà essere in grado di fornire servizi e infrastrutture in linea con il progresso tecnologico e organizzativo del polo primario.
6 PROPOSTA PROGETTUALE
Nel quadro degli interventi di evoluzione tecnologica e di razionalizzazione del Data Center di Roma Capitale, nel corso del 2018 sono stati individuati alcuni interventi strategici, a supporto e ad integrazione della più ampia trasformazione in corso dall’inizio dell’anno e che si protrarrà anche nel 2019, 2020 e 2021.
La figura seguente illustra sinteticamente lo scenario di trasformazione previsto, indicando le ‘voci’ progettuali rilevanti e inserendo tra le aree di trasformazione anche quanto relativo allo sforzo dell’Amministrazione nel perseguire lo snellimento della macchina amministrativa del Comune.
Quanto infatti richiesto ai Fornitori, sia in ambito infrastrutturale, applicativo e più in generale relativamente al modello di erogazione dei servizi, avanzerà in parallelo a quanto la stessa Amministrazione avvierà per migliorare ed efficentare i propri processi interni e la propria organizzazione.
Da questo punto di vista, l’intervento progettuale dovrà coniugare, nel tempo, la profonda trasformazione richiesta con la progressività dell’azione, armonizzandone gli effetti con lo sviluppo e l’efficentamento della macchina amministrativa e degli Uffici coinvolti.
Per questo, il progetto complessivo si svilupperà in più fasi e il buon esito di ciascuna di esse, anche in termini di stabilizzazione della macchina gestionale a fronte dei risultati intermedi della trasformazione, sarà elemento indispensabile all’attivazione della fase successiva e ove necessario alla ricalibrazione delle attività relative.
Gli obiettivi del progetto saranno perseguiti dal Fornitore offrendo il supporto all’intero processo evolutivo, con una regia delle attività tesa ad armonizzare l’azione di tutti gli attori in campo, per il massimo del controllo pur in un’ottica di flessibilità e adeguamento alla variabilità del contesto. Il team di governance avrà in carico le seguenti attività:
• Aggiornare con continuità le attività del progetto tenendo in conto i vincoli derivanti dalle attività di gestione e dalle attività legate ai rilasci applicativi, ai nuovi sviluppi o ai periodi di particolare criticità (elezioni, scadenze amministrative etc.)
• Far emergere le opportunità tecnologiche e di ambiente che il progresso della trasformazione offrirà ai progetti applicativi e infrastrutturali, affinché ne possano usufruire;
• Integrare le attività derivanti dalle richieste di change nel disegno complessivo della trasformazione, affinché tutti i cambiamenti, anche quelli minori, siano coerenti con gli obiettivi del progetto.
7 TASK DI ATTUAZIONE DEL PROGETTO
La macro trasformazione è organizzata in più task, ciascuno dei quali ha dipendenze e interrelazioni con l’ambiente esistente, con le iniziative di rinnovamento e trasformazione già in fase di attuazione e con gli altri task del presente Progetto. Di conseguenza sarà necessario organizzare gli interventi in una pianificazione di dettaglio, che tenga conto dei vincoli e dei rischi che caratterizzano l’intero contesto.
L’evoluzione del contesto architetturale comporta un adeguamento della tipologia di servizi offerti; il presente progetto indirizza le nuove esigenze, integrando nella proposta un servizio di supporto alla piattaforma Container, analogo al servizio a catalogo SPC, indispensabile in quanto l’ambiente container è alla base degli sviluppi applicativi più recenti ed innovativi promossi dall’Amministrazione e rappresenta il nuovo standard architetturale di riferimento.
L’ampiezza della trasformazione implica lo svolgimento di attività che richiederanno il coinvolgimento della stessa Amministrazione e di organizzazioni esterne all’ambito della convenzione SPC Lotto 1, per svolgere quanto necessario nell’ambito delle rispettive responsabilità e dei relativi contratti.
Di seguito sono illustrati i principali task progettuali.
7.1 Migrazione Sistemi su nuova Rete
Il progetto completa le attività condotte ad inizio 2019, per la realizzazione della nuova infrastruttura di rete del Data Center, una infrastruttura di comunicazione moderna, efficiente e adeguata alle esigenze attuali e del prossimo futuro, integrata con la nuova infrastruttura di sicurezza e con i servizi di Disaster Recovery.
Gli obiettivi di progetto prevedono due task:
1) Componente network: reingegnerizzazione dell’uso delle VLAN, diffusione del tagging eliminando accessi statici porta/VLAN, introduzione della possibilità di gestire le configurazioni «via software» e razionalizzare il piano di indirizzamento IP;
2) Migrazione dei servizi basati su tecnologia X86 sul nuovo Cluster Hyper-V, pienamente integrato nella nuova rete a 10Gbps realizzata con gli apparati recentemente acquisiti dall’Amministrazione, attraverso una configurazione infrastrutturale in grado di preservare (salvo alcuni casi particolari) la continuità dei servizi.
Si evidenzia che il progetto è propedeutico alle altre attività progettuali proposte, in particolare al progetto di realizzazione della nuova infrastruttura di Disaster Recovery e della nuova infrastruttura di virtualizzazione basata su OpenStack.
I Deliverable previsti sono:
• Completamento della nuova infrastruttura di rete a 10Gb;
• Messa in opera di workaround finalizzati a minimizzare l’impatto sui sistemi, preservando per quanto possibile la
disponibilità delle applicazioni;
• Riorganizzazione dei Cluster Hyper-V, con integrazione dei nuovi sistemi HP Proliant attestati sulla nuova rete e ridistribuzione dei sistemi virtuali sui nodi dei Cluster reingegnerizzati;
o Analisi e disegno della soluzione;
o Sviluppo della soluzione;
o Rilascio in produzione;
• Documentazione.
Le attività di progetto sono state già in parte condotte nel periodo Gennaio – Marzo 2019. Si prevede il termine delle attività entro settembre 2019.
7.2 Censimento
Il task nasce dall’esigenza di organizzare il processo di gestione della configurazione, predisponendo nel contempo un database nel quale riversare in modo ordinato le informazioni relative ai servizi e alle infrastrutture del Comune e governare l’aggiornamento dei dati attraverso i processi di change, asset e configuration.
I deliverable previsti sono:
• Censire tutti gli apparati (Serial Number, collocazione nel DC, modello, Vendor..), anche non in carico alla RTI;
• Posizionare i sistemi in una mappa riproducente le sale CED, in formato elettronico, accurata nelle dimensioni e nella descrizione degli spazi e navigabile in formato tridimensionale con un prodotto open source;
• Individuare gli apparati non più attivi, ovvero che non erogano più servizi, per i quali possono essere intraprese azioni di rimozione dai locali del Data Center e di bonifica delle alimentazioni, cablaggi etc.;
• Associare gli apparati attivi e i sistemi virtuali su di essi ospitati;
• Per gli apparati attivi e i sistemi fisici e virtuali, individuare le relazioni con i progetti ospitati;
• Censire, per gli apparati attivi e funzionali all’erogazione dei servizi, i relativi contratti di manutenzione;
• Integrare le informazioni nel processo di asset e configuration, affinché siano mantenute aggiornate.
E’ previsto che il task si sviluppi in più fasi, come di seguito descritto:
• Fase 1: Censimento degli spazi, degli apparati fisici e mappa tridimensionale del CED;
• Fase 2: Documentazione delle relazioni tra apparati fisici e catene tecnologiche;
• Fase 3: Documentazione e modellizzazione della relazione tra ambienti operativi e applicazioni/funzioni.
Le attività sono state già in parte condotte nel periodo Gennaio – Marzo 2019. Si prevede il termine delle attività entro dicembre 2019.
7.3 Ingegnerizzazione e popolamento piattaforma OpenStack
Questa componente di trasformazione rappresenta il proseguio del progetto di evoluzione dell'infrastruttura di virtualizzazione su ambiente OpenStack, in linea con le infrastrutture e le tecnologie che caratterizzano il Contratto Consip SPC, parte del progetto dei fabbisogni in corso dal 2018.
Il progetto potrà integrarsi con il progetto di introduzione di una piattaforma di gestione del Cloud privato (Cloud Management Platform, CMP), la cui definizione, in accordo con l’Amministrazione, è stata rimandata al 2020.
Il progetto prevede la predisposizione degli specifici processi di delivery e provisioning che caratterizzano l’ambiente Cloud, per l’ottimizzazione delle risorse computazionali e le funzioni di orchestrazione della piattaforma.
I Deliverable previsti sono:
• Definizione nuovi processi di delivery e provisioning
• Configurazione ambienti di esercizio, sviluppo e collaudo
• Procedure di delivery
• Funzioni di orchestrazione
• Realizzazione ambienti a supporto architetture container e di virtualzzazione
• Documentazione a supporto
Lo Sviluppo del progetto prevede le seguenti attività:
• Analisi e disegno della soluzione:
o disegno architetturale;
o requisiti Hw e Sw;
o Requisiti di connettività;
• Individuazione degli ambienti da predisporre
• Predisposizione della connettività;
• Realizzazione funzioni di orchestrazione;
• Predisposizione procedure di delivery e provisioning;
• Documentazione, test e collaudo.
Si propone lo svolgimento del progetto nel corso del 2020.
7.4 Disaster Recovery
Il task si colloca in uno scenario complesso, con diversi vincoli di tipo infrastrutturale ed economico, di seguito riportati.
Sito primario: i sistemi di Roma Capitale presenti nel sito primario sono attribuibili a tre categorie: sistemi X86, sistemi Power IBM e sistema Mainframe Unisys. Quest’ultimo sistema rappresenta quanto ancora soggetto a lock-in tecnologico, derivante dalla specifica architettura proprietaria Unisys ClearPath. Nella categoria X86 rientrano come casi particolari il nuovo RAC Oracle e l’ambiente di containerizzazione ECaaS.
Sito secondario: Il servizio è attualmente erogato dal sito di Applico (Perugia), facendo uso di architetture proprietarie Unisys
sia per l’ambito X86 che per l’ambito Mainframe. L’Amministrazione vorrebbe ricondurre l’attuale servizio ad una soluzione
priva di lock-in tecnologici e ospitata in uno dei siti Cloud SPC. L’Amministrazione ha manifestato pertanto la necessità di intraprendere le iniziative progettuali volte ad avviare, entro la fine dell’anno 2019, la migrazione dei servizi di Disaster Recovery degli ambienti x86 e Power IBM su di un sito SPC Cloud del RTI, così da poter cessare i servizi erogati dal DC Applico a meno dell’ambito mainframe, i cui tempi sono regolati dal progetto di reingegnerizzazione SIPO.
Iniziative in corso: Sul tema del disaster recovery, nel Progetto dei Fabbisogni attualmente in vigore, è presente una componente di progetto in ambito infrastrutturale. Tale componente realizzativa è relativa all’ambiente X86: le attività consistono nel progettare e portare in produzione una nuova infrastruttura nel prescelto sito SPC. Quanto previsto nel precedente progetto dei fabbisogni relativamente ai servizi infrastrutturali, verrà modificato, integrato e superato dal presente progetto in merito a:
1. Perimetro del servizio DRaaS
2. Dimensionamento infrastrutturale
3. Tempistiche di rilascio dei nuovi servizi SPC Cloud
Iniziative proposte nel presente Progetto dei Fabbisogni: A quanto già indirizzato dal Progetto dei Fabbisogni attualmente in vigore si aggiungono altri task, parte del Progetto dei Fabbisogni descritto nel presente documento:
Ambito X86: task relativo all’attività di trasformazione che indirizza quanto necessario alla configurazione dei servizi X86 sul sito secondario. Il task deve tenere in conto anche delle nuove infrastrutture in corso di introduzione: la piattaforma di containerizzazione ECaaS, già in produzione, e la piattaforma OpenStack prevista nel 2020.
Ambito Power IBM: task relativo all’attività di progettazione, predisposizione, avvio e gestione di una infrastruttura omologa a quella di produzione nel sito SPC e trasformazione che indirizza quanto necessario alla configurazione dei servizi Power sul sito secondario.
Ambito OS2200: questo task è maggiormente articolato in quanto deve tener conto di quanto previsto dal Progetto SIPO, che prevede la reingegnerizzazione su architettura X86 dell’attuale ambiente anagrafico, oggi ospitato su infrastruttura proprietaria Unisys Mainframe. Al termine del progetto SIPO l’anagrafico potrà essere configurato in Disaster Recovery in modo analogo ad altre funzioni basate su architetture X86. Il progetto ha tuttavia un corso temporale che si estenderà oltre il 2019 e di conseguenza sarà necessario per l’Amministrazione mantenere attiva l’attuale soluzione di DR per l’ambiente OS2200.
Di seguito si espongono le proposte di trasformazione per gli ambienti X86 e IBM Power; le iniziative, pur distinte nelle
tecnologie e nelle soluzioni, sono coniugate al fine di traguardare la dismissione dell’attuale sito di DR prima possibile.
7.4.1 Ambito X86
La soluzione prospettata per l’ambiente X86 di Disaster Recovery tiene conto dei vincoli rappresentati dall’attuale infrastruttura di produzione, basata sul virtualizzatore Hyper-V. La soluzione di DR più lineare e che meglio si adatta agli stringenti vincoli temporali si caratterizza come segue:
1) Predisporre nel sito secondario (tra i siti Cloud SPC è stato prescelto il nuovo e modernissimo sito TIM di Acilia, anche in ottica di future implementazioni di servizi di Business Continuity) il servizio DRaaS per le VM costituenti l’ambiente di produzione dell’Amministrazione. Per garantire tale servizio sui cluster HyperV dell’Amministrazione, sarà necessario sviluppare un plugin che consenta di erogare il servizio DRaaS da un ambiente sorgente HyperV verso un ambiente destinazione Openstack. Si evidenzia che in ogni caso non tutte le VM dell’ambiente di produzione potranno essere oggetto di tale servizio in quanto i sistemi operativi più vecchi (ad esempio Windows 2003 server) non sono supportati dalla soluzione proposta.
2) Progettazione, predisposizione, avvio e gestione, presso il sito secondario, di un cluster Oracle RAC fisico dedicato per erogare i servizi di DR della componente Oracle. Si evidenzia che il presente progetto ricomprende solamente i servizi di Cloud Enabling relativi a tale componente, laddove la disponibilità dei prodotti hardware e software e i servizi di housing/hosting dovranno essere garantiti dall’Amministrazione al di fuori della convenzione SPC Cloud lotto 1.
3) Progettazione, predisposizione, avvio e gestione, presso il sito secondario, di un cluster HyperV dedicato per erogare i servizi di DR di quelle VM particolarmente critiche per le quali l’Amministrazione necessita di SLA di RTO e RPO stringenti e non compatibili con quanto previsto dal servizio DRaaS. Si evidenzia che il presente progetto ricomprende solamente i servizi di Cloud Enabling relativi a tale componente, laddove la disponibilità dei prodotti hardware e
software e i servizi di housing/hosting dovranno essere garantiti dall’Amministrazione al di fuori della convenzione
SPC Cloud lotto 1.
7.4.2 Ambito Power IBM
Il task ha lo scopo di integrare la nuova soluzione di Disaster Recovery per comprendere le infrastrutture Power IBM. Più in dettaglio la soluzione proposta prevede la progettazione, predisposizione, avvio e gestione di un ambiente IBM Power, dedicato ed omologo a quello del sito primario, per erogare i servizi di DR dell’ambiente IBM. Si evidenzia che il presente progetto ricomprende solamente i servizi di Cloud Enabling relativi a tale componente, laddove la disponibilità dei prodotti hardware e software e i servizi di housing/hosting dovranno essere garantiti dall’Amministrazione al di fuori della convenzione SPC Cloud lotto 1.
7.4.3 Storage e replica dati
Il task ha lo scopo di integrare la nuova soluzione di Disaster Revoery, relativamente alle componenti IBM power, Cluster Oracle RAC, Cluster HyperV dedicato, con un sistema di storage e replica dati. Più in dettaglio la soluzione proposta prevede la progettazione, predisposizione, avvio e gestione di una soluzione di storage e replica dati, dedicata ed omologa a quella del sito primario, integrata con i servizi di DR dell’ambiente IBM e dei cluster Oracle RAC e HyperV. Si evidenzia che il presente progetto ricomprende solamente i servizi di Cloud Enabling relativi a tale componente, laddove la disponibilità dei prodotti hardware e software e i servizi di housing/hosting dovranno essere garantiti dall’Amministrazione al di fuori della convenzione SPC Cloud lotto 1.
7.4.4 Vincoli e prerequisiti
Il progetto di realizzazione del nuovo ambiente di Disaster Recovery, come precedentemente illustrato, contiene numerosi elementi di criticità e vincoli temporali strettissimi. Di conseguenza, il rispetto delle date dipende in modo determinante dall’avvio delle attività di progetto.
Ai fini dell’erogazione dei servizi di DR, si sottolinea inoltre che l’Amministrazione dovrà predisporre, al di fuori della convenzione SPC Cloud Lotto 1, anche i servizi di connettività tra il proprio Data Center e il Data Center di DR SPC necessari a consentire l’allineamento dei dati e l’erogazione del servizio, nonché un servizio di connettività di tipo L2 extension tra il sito di DR SPC e il sito di DR di Perugia, necessario a garantire l’erogazione del servizio di DR dell’ambiente OS2200 anche a seguito della migrazione su SPC Cloud del DR degli ambienti x86 e IBM Power.
7.4.5 Effort e tempi
Il progetto prevede l’erogazione di servizi di Cloud Enabling finalizzati a garantire:
• Lo sviluppo, il test e il tuning del plugin che consente l’erogazione del servizio DRaaS a partire da un ambiente sorgente
HyperV
• l’integrazione tra le diverse componenti del servizio
• l’aggiornamento, nell’ambito del perimetro del servizio definito dal presente progetto e delle risorse infrastrutturali, hardware e software, contrattualizzate e/o messe a disposizione dall’Amministrazione, dei sistemi di DR in funzione delle modifiche e trasformazioni introdotte sul sito primario
• la redazione e l’aggiornamento annuale del piano di DR
• la progettazione, l’implementazione e l’esercizio degli ambienti componenti il nuovo servizio di DR
Il progetto del nuovo servizio di DR prevede l’avvio delle attività propedeutiche a partire dal mese di luglio 2019, con l’attivazione dei nuovi servizi per gli ambiti x86 ed IBM Power a partire da gennaio 2020.
7.5 Framework WSO2
Il task nasce dall’esigenza di uniformare la tecnologia alla base dei progetti di software renewal che stanno investendo il parco applicativo dell’Amministrazione e prevede la definizione e l'implementazione dell'architettura WSO2 sia in ambito di collaudo che di produzione.
L’effort relativo a questo task si svilupperà nell’arco temporale di un anno a partire da luglio 2019.
7.6 Presa in carico area storage
Il task nasce dall’esigenza di mantenere in esercizio gli apparati facenti parte dell’area storage (Dell EMC VMAX10K, switch SAN Cisco MDS e backup Oracle SL500) per il periodo necessario a completare la transizione verso i nuovi sistemi definiti dal progetto di trasformazione.
A tal fine si prevede la presa in carico di tali apparati e il loro mantenimento in esercizio per il periodo luglio 2019 – dicembre 2019.
8 STRUTTURA FUNZIONALE E ORGANIZZATIVA
Il modello organizzativo del Fornitore include funzioni di governo centrale della fornitura, che operano nella gestione del Contratto e funzioni di supporto alle singole Amministrazioni, coinvolte direttamente nella gestione dei Contratti Esecutivi con le PA.
In conformità con i requisiti di capitolato, il modello proposto prevede un Responsabile del Contratto Quadro, in relazione diretta con Xxxxxx/AgID per le tematiche legate al Contratto Quadro. Nel modello è inoltre presente il Responsabile del Contratto Esecutivo, che interagirà con l’Amministrazione contraente per tutti gli aspetti relativi all'esecuzione del contratto e per tutti i servizi contrattualizzati. I responsabili del Contratto Quadro e dei Contratti Esecutivi sono supportati da funzioni interne di staff.
Nelle tabelle che seguono si descrivono ruoli e responsabilità delle Figure di Governo.
Funzioni di Governo del contratto
Ruolo | Responsabilità |
Responsabile del Contratto Quadro | In relazione diretta con Xxxxxx/AgID per le tematiche legate al contratto quadro, è uno dei Rappresentanti del Raggruppamento nel Comitato di Direzione Tecnica |
Responsabile dei Contratti Esecutivi | Interagisce con le diverse Amministrazioni che aderiscono all'accordo per tutti gli aspetti relativi all'esecuzione dei singoli contratti. Ciascuna Amministrazione farà riferimento ad un solo Responsabile di Contratto Esecutivo per tutti i servizi contrattualizzati |
Funzioni di Staff
Ruolo | Responsabilità |
Responsabile Tecnico | Individuato per ciascuna Amministrazione, riporta funzionalmente al Responsabile del Contratto Esecutivo e assume la responsabilità tecnica dell'esecuzione di tutti i servizi e di tutte le attività progettuali: in particolare, coordina tutte le attività on premise e interagisce con le strutture operative remote per assicurare la corretta esecuzione e integrazione dei servizi secondo i requisiti dell'Amministrazione. |
Project Manager | Questa figura si rende necessaria qualora i Progetti prevedano trasformazioni significative del Contesto dell’Amministrazione contraente. Individuato per ciascuna Amministrazione, riporta funzionalmente al Responsabile del Contratto Esecutivo e ha il ruolo di Project Manager per tutte le attività progettuali: in particolare, coordina le fasi di disegno e realizzazione delle attività di trasformazione on premise e interagisce con le strutture operative remote per assicurare la corretta esecuzione e integrazione dei servizi secondo i requisiti dell'Amministrazione. |
I riferimenti delle risorse sono di seguito indicati:
o Responsabili del Contratto Esecutivo:
▪ Xxxxx Xxxxxxx Xx Xxxxx – xxxxxxxxxxxx.xxxxxxx@xxxxxxxxxxxxx.xx
▪ Xxxxxxxxx Xxxxxxxx - xxxxxxxxx.xxxxxxxx@xxx.xxx
o Responsabile Tecnico:
▪ Xxxxxxx Xxxxxx - xxxxxxx.xxxxxx@xxx.xxx
▪ Xxxx Xxxxxxxxxxxx – xxxx.xxxxxxxxxxxx@xxxxxxxxxxxxx.xx
o Responsabile del programma di trasformazione:
▪ Xxxxx Xxxxxx - xxxxx.xxxxxx@xxx.xxx
o Service Manager di Esercizio
▪ Xxxxxx Xxxxx - xxxxxx.xxxxx@xxx.xxx
o Responsabile Tecnico (Responsabile del Delivery) nel caso di servizi IaaS/PaaS/SaaS:
▪ Ilaria Vari - xxxxxx.xxxx@xxxxxxxxxxxxx.xx
o Rappresentante del Fornitore (Services Manager di esercizio):
▪ Xxxx Xxxxxxx - xxxx.xxxxxxx@xxxxxxxxxxxxx.xx
9 SERVIZI A SUPPORTO DEL PROGETTO
Sono di seguito indicati i servizi acquisiti dall’Amministrazione a supporto del Progetto dei Fabbisogni.
9.1 Servizio IaaS di Virtual Data Center (Id. servizio L1.S1.2)
Nella tabella che segue sono rappresentate le componenti di servizio SPC Cloud VDC previste nella fornitura per il Servizio di Disaster Recovery.
Le tempistiche e la modalità di attivazione di tali risorse saranno definite in accordo con l’Amministrazione. Per rispondere inoltre in modo flessibile allo sviluppo della trasformazione, potrebbero essere apportate rimodulazioni/variazioni di tali risorse.
Nell’ipotesi di lavoro attuale l’attivazione delle risorse VDC in Cloud è prevista entro il 2019 per avviare i servizi DRaaS a partire da gennaio 2020 e prefigura un corrispondente impegno economico, pari a complessivi € 342.664,62. Le risorse indicate prevedono l’erogazione di un servizio di Disaster Recovery a copertura delle VM dell’ambiente di produzione dell’ambito x86, stimate in un numero massimo di 275.
I servizi IaaS previsti dalla precedente versione del progetto dei fabbisogni, corrispondenti ad un valore complessivo di €
100.524,48, risultano superati dalla configurazione qui proposta e non saranno pertanto attivati ed erogati.
Per dettagli sulle modalità di implementazione del servizio IaaS VDC, si rimanda alla documentazione di convenzione disponibile sul Portale di Governo e Gestione della Fornitura raggiungibile all’indirizzo: xxx.xxxxxxxx.xx.
SEZIONE 6: Ambiente IaaS – Virtual Data Center - Canone | |||||||||||||||||||||||||||||||
Selezionare, per ciascun Virtual Data Center che si intende acquistare, le opzioni desiderate. Ogni Virtual Data Center è un ambiente operativo a se stante ed autoconsistente. NOTA: Per aggiungere righe, copiare e incollare a fine lista l'ultima riga, per mantenere le formule e la formattazione delle righe esistenti. | Risorse Virtuali | Servizi Opzionali | Risorse a completamento dell'Ambiente Virtual Data Center - Canone | Durata Contrattuale | |||||||||||||||||||||||||||
Pool Base: 5 vCPU, 10 GB RAM, 500 GB HD CAP. | Pool Base: 5 vCPU, 10 GB RAM, 500 GB HD PREST | vCPU aggiuntive: 1 vCPU | vRAM aggiuntiva: 1 GB | vStorage aggiuntivo: 10 GB CAPACITIVO | vStorage aggiuntivo: 10 GB PRESTAZIONALE | MS server 0000 | Xxxxxxx XX server 2012 | MS server 0000 | Xxxxxxx XX server 2016 | Red Hat | Sottoscrizione Red Hat | Suse | Sottoscrizione Suse | Oracle Linux | Sottoscrizione Oracle Lin. | SolutionStackAMM | SolutionStackConsip | Protezione Avanzata | Virtual Storage Block CAPACITIVO aggiuntivo | Virtual Storage Block PRESTAZIONALE aggiuntivo | Virtual Network aggiuntive | ||||||||||
Xsmall (100 GB) | Small (500 GB) | Medium (1 TB) | Large (2 TB) | XLarge (5 TB) | Xsmall (100 GB) | Small (500 GB) | Medium (1 TB) | Large (2 TB) | XLarge (5 TB) | 15 indirizzi IP e 1 indirizzo IP Pubblico Internet/SPC per ogni VNetwork | |||||||||||||||||||||
Virtual Data Center 1 | 1 | 1223 | 3700 | 275 | Si | 424 | 25 | 12 | |||||||||||||||||||||||
Virtual Data Center 2 | |||||||||||||||||||||||||||||||
Virtual Data Center 3 |
9.2 Servizio Disaster Recovery as a service (DRaaS)
Nelle tabelle che seguono sono rappresentate le componenti di servizio SPC DRaaS previste nell’ambito del progetto di Disaster
Recovery.
Nell’ipotesi di lavoro attuale l’attivazione del servizio DRaaS è prevista a gennaio 2020 per un numero massimo di VM pari a 275 e prefigura un corrispondente impegno economico, pari a complessivi € 690.239,00.
I servizi DRaaS previsti dalla precedente versione del progetto dei fabbisogni, corrispondenti ad un valore complessivo di €
223.347,20, risultano superati dalla configurazione qui proposta e non saranno pertanto attivati ed erogati.
Per dettagli sulle modalità di implementazione del servizio DRaaS, si rimanda alla documentazione di convenzione disponibile sul Portale di Governo e Gestione della Fornitura raggiungibile all’indirizzo:: xxx.xxxxxxxx.xx.
Id | Classe di servizio | N° sistemi¹ | Durata contrattuale |
S.DR01 | DRaaS Classe 2 ❑ | ||
S.DR02 | DRaaS Classe 3 X | 275 | 12 |
9.2.1 Sede di erogazione dei servizi IaaS e DRaaS
Centro servizi SPC Cloud Lotto 1.
9.2.2 Data prevista attivazione
La data di attivazione delle risorse elaborative in Cloud sarà concordata con l’Amministrazione, tenendo conto che il progetto di Trasformazione individua al momento l’inizio di erogazione del servizio per il giorno 1/1/2020.
9.3 Servizi di supporto specialistico per Cloud Enabling (Id. Servizio L1.S6)
I volumi relativi ai servizi di Cloud Enabling richiesti dall’Amministrazione a supporto del Progetto sono riepilogati nella tabella seguente.
Nel complesso, l’importo relativo ai servizi di Cloud Enabling è pari a € 7.732.502,25.
Servizio | Elementi | Profilo | Quantità | Importo totale € |
Servizi professionali | Capo Progetto | gg/pp | 2500 | 990.425,00 |
Servizi professionali | IT Architect Senior | gg/pp | 2199 | 820.007,10 |
Servizi professionali | Specialista di tecnologia/prodotto | gg/pp | 14005 | 4.222.927,65 |
Servizi professionali | Sistemista senior | gg/pp | 6050 | 1.699.142,50 |
9.3.1 Distribuzione dei servizi professionali nello sviluppo temporale del progetto
Le figure professionali saranno utilizzate per comporre il team di governance, supportare le attività progettuali ed erogare i servizi a supporto della gestione del Data Center.
9.3.2 Sede di erogazione dei servizi
I luoghi di erogazione dei servizi saranno concordati con l’Amministrazione in sede di pianificazione di dettaglio delle attività.
9.3.3 Data prevista attivazione e durata
La data prevista per l’attivazione delle attività relative al presente Progetto dei Fabbisogni è Luglio 2019 per un periodo di 18 mesi.
9.3.4 Impegni servizi professionali
Per l’attuazione del presente progetto saranno selezionate, in accordo con l’Amministrazione, risorse professionali con skill adeguati alle esigenze delle diverse fasi di progetto.
10 PIANO DI QUALITÀ
Per il “Piano della qualità dei singoli servizi di Cloud Enabling” contenente la descrizione dettagliata dei relativi obiettivi di qualità e la descrizione sintetica dei processi di controllo della qualità, si rimanda al Piano della Qualità generale del RTI consegnato a Xxxxxx/AgID [Rif. SPCC_RTI_PianoQualitàGeneraleLotto1 v x.y].
11 DOCUMENTO PROGRAMMATICO DI GESTIONE DELLA SICUREZZA DELL’AMMINISTRAZIONE
Si rimanda al documento consegnato a Consip: “Piano di Sicurezza dei Centri Servizi e Centri Servizi Ausiliari”.
12 SPECIFICHE DI COLLAUDO
Per le verifiche di conformità dei servizi si rimanda al documento ufficiale di collaudo dei servizi effettuato da Consip/AgID: “Specifiche di dettaglio delle prove di collaudo dei servizi in ambiente di test (Test Bed)”. L’Amministrazione può richiedere la ripetizione di test di interesse in occasione della fornitura dei singoli servizi richiesti. Tale opzione deve essere esercitata all’atto della contrattualizzazione.
Fatta salva la possibilità di ricorrere alle verifiche di cui sopra, la fatturazione dei servizi di Cloud Computing verso l’Amministrazione decorrerà dalla dichiarazione di disponibilità dei servizi da parte del Fornitore come definito nei rispettivi Piani di attivazione dei servizi. Le verifiche verranno effettuate dal Referente Tecnico dell’Amministrazione.
13 MODALITÀ DI PRESENTAZIONE E APPROVAZIONE STATI AVANZAMENTO MENSILI
Al fine di verificare l’andamento del servizio, il Fornitore produrrà dei SAL (Stato Avanzamento Lavori) contenenti le seguenti informazioni:
• avanzamento delle attività relative al piano di realizzazione;
• evidenze di eventuali scostamenti rispetto al piano temporale di realizzazione;
• eventuali proposte per la nuova pianificazione delle attività;
• evidenze di attività correttive intraprese per la gestione delle criticità rilevate;
• consuntivo delle risorse utilizzate nel periodo di osservazione;
• varianti e modifiche emerse nel periodo.
I SAL saranno prodotti con cadenza bimestrale entro il 15 del mese successivo a quello di riferimento del SAL. Tutti i SAL sono
soggetti ad approvazione da parte dell’Amministrazione.
14 RIEPILOGO ECONOMICO DEI SERVIZI
Il riepilogo economico dei servizi del presente progetto dei fabbisogni presenta:
- Servizi VDC: € 342.664,62 (importo complessivo);
- Servizio DRaaS: € 690.239,00 (importo complessivo);
- Servizi di Cloud Enabling: € 7.732.502,25 (importo complessivo);
- Servizi VDC e DRaaS previsti nel precedente Progetto dei Fabbisogni che non saranno erogati: - € 323.871,68
Il valore economico complessivo del progetto dei fabbisogni, integrativo rispetto alla precedente versione, è dunque pari a €
8.441.534,19.
15 ULTERIORI COMPONENTI DI SERVIZIO NON INCLUSE NELL’OFFERTA
Il presente Progetto dei Fabbisogni descrive i servizi di Governance, di Progetto, di supporto alla gestione e relativi ai servizi IaaS e DRaaS. Non sono inclusi nel presente progetto gli elementi aggiuntivi qui descritti, che dovranno essere garantiti dall’Amministrazione al di fuori della convenzione SPC Cloud Lotto 1:
• Mantenimento servizio di DR presso il sito di Perugia nella configurazione As Is (fino a fine 2019)
• Mantenimento servizio di DR presso il sito di Perugia per il solo ambiente OS2200 (dal 1/1/2020 al 30/6/2020)
• Connettività layer 2 tra il sito di DR SPC Cloud e il sito di Perugia per l’erogazione del servizio di DR dell’ambiente
OS2200 (1° semestre 2020)
• Acquisizione hardware IBM Power di DR da ospitare presso il sito di DR SPC Cloud per garantire il servizio di DR
dell’ambiente IBM P8.
• Acquisizione di una coppia di server, omologa a quella su cui è configurato il cluster Oracle di produzione, da ospitare presso il sito di DR SPC Cloud per garantire il servizio di DR del cluster fisico Oracle.
• Acquisizione HW x86 per realizzazione cluster dedicato HyperV per DR applicazioni critiche presso il sito di DR SPC Cloud.
• Acquisizione storage IBM SVC da ospitare presso il sito di DR SPC Cloud per garantire il servizio di replica degli ambienti IBM Power, Cluster Oracle e Cluster HyperV.
• Servizi di connettività tra il CED di Roma Capitale e il sito di DR SPC Cloud per garantire la replica e l’allineamento dei
dati
• Servizi di connettività per l’erogazione dei servizi di Disaster Recovery dal sito di DR SPC Cloud
• Mantenimento in esercizio dell’ambiente OS2200 del sito primario fino a completamento del progetto di
reingegnerizzazione SIPO e conseguente dismissione del mainframe (stimato per la fine di giugno 2020).