COMUNE DI CAGGIANO Provincia di Salerno

Transcript

1 Progetto cofinanziato dall Unione Europea Fondo Europeo di Sviluppo Regionale POR FESR Campania Obiettivo Operativo 5.1 E-Government e E-Inclusion Progetto: Descrizione: Importo a base di appalto Importo per la sicurezza Documento Multiprogetto Servizi di e-government Comuni Campanipiattaforma tecnologica Procedura aperta per la fornitura di beni e servizi per la realizzazione della piattaforma tecnologica (HW e SW di base) a supporto del Multiprogetto Servizi di e-goverment Comuni campani relativo al complesso di sei interventi ammessi a finanziamento con DD n.103 del 29/11/2010 della AGC n 6 Settore n 2 della Regione Campania (PO FESR Campania 2007/2013 OO 5.1), ciascuno avente come capofila rispettivamente i comuni di Aiello del Sabato (AV), Caggiano (SA), Cercola (NA), Piedimonte (CE), Vitulazio (CE) e Asmenet Campania, per complessivi 193 comuni campani. Euro ,67 (IVA esclusa) Euro 6.000,00 (IVA esclusa) non soggetto a ribasso CAPITOLATO DI GARA Data: Maggio 2014 File: v.7 Atti di programmazione Committente REGIONE CAMPANIA POR-FESR Campania Obiettivo Operativo 5.1 E-Government e E-Inclusion Amministrazione comunale di Caggiano (Sa) Sede legale : via Nestore Caggiano, Caggiano(Sa) Capitolato tecnico di gara Pagina 1 di 45

2 CAPITOLATO DI GARA Termini usati e descrizioni Termine Capitolato tecnico Descrizione Si intende il documento che contiene le informazioni tecniche e specifica gli interventi oggetto della gara. Committente Si intende l Amministrazione comunale di Caggiano (SA) che opera in qualità di Committente per conto delle Amministrazioni capofila Aggiudicatario ovvero Appaltatore Amministrazione Regionale Si intende il soggetto (Impresa singola o RTI, Consorzio o GEIE) aggiudicatario del presente appalto ad esito della presente procedura di gara. Si intende la Regione Campania. Capitolato tecnico di gara Pagina 2 di 45

3 INDICE Articolo 1. PREMESSE... 4 Articolo 2. OBIETTIVI E CONTESTO DI RIFERIMENTO... 5 Articolo 3. ARCHITETTURA DELLA PIATTAFORMA ICT... 8 Articolo 4. OGGETTO DELL APPALTO Articolo 5. REQUISITI GENERALI DELLA FORNITURA Articolo 6. SERVIZI DI INSTALLAZIONE Articolo 7. SERVIZI DI ASSISTENZA, MANUTENZIONE E GARANZIA Articolo 8. SERVIZI DI GESTIONE DEL PROGETTO Articolo 9. SERVIZI DI FORMAZIONE Articolo 10. TERMINI DI REALIZZAZIONE DELLA FORNITURA Articolo 11. PROPRIETA DELLE SOLUZIONI ICT ADOTTATE Articolo 12. VERIFICHE DI REGOLARE ESECUZIONE DEI LAVORI E COLLAUDO FINALE Articolo 13. DOCUMENTAZIONE DI GARA Capitolato tecnico di gara Pagina 3 di 45

4 Articolo 1. PREMESSE La Piattaforma Tecnologica oggetto della fornitura è stato definita nelle sue specifiche tecniche e funzionali in modo da poter soddisfare le esigenze elaborative relativa al complesso degli interventi ammessi a finanziamento (Multiprogetto di e-goverment Comuni Campani) con DD n.103 del 29/11/2010 della AGC n 6 Settore n 2 della Regione Campania (PO FESR Campania 2007/2013 OO 5.1), ciascuno avente come capofila rispettivamente i comuni di Aiello del Sabato (AV), Caggiano (SA), Cercola (NA), Piedimonte (CE), Vitulazio (CE) e Asmenet Campania, per complessivi 193 Comuni campani. Essa presenta le seguenti caratteristiche salienti: 1. Realizzare due data center gemelli (costituiti da un nodo primario NOP e un nodo secondario NOS) per dare attuazione a una organizzazione affidabile e resiliente del delivery dei servizi ICT nei confronti dei Comuni basata sul modello Cloud computing ; 2. In prospettiva, avrà il compito di supportare la gestione di tutti i servizi applicativi e infrastrutturali avanzati previsti negli interventi sopra riportati e rientranti nel Multiprogetto Servizi di e-government Comuni Campani (la migrazione di tali servizi non e' oggetto della presente fornitura); 3. Fornirà ai Comuni che partecipano al Cloud i servizi di Backup e Restore dei propri sistemi ICT, impiegando le risorse elaborative che verranno rese disponibili dall infrastruttura una volta realizzata e predisponendo adeguati servizi di interoperabilità tra le risorse ICT del Comune e il Cloud; 4. Prevede la presenza di un nodo locale (NOL), presso ciascun Comune, in modo da consentire un unico punto di interoperabilità tra il Cloud ed i sistemi di elaborazione in essere presso ciascun Comune; 5. Prevede un sito web da mettere a disposizione di ciascun Comune per l accesso ai servizi Cloud on-demand; Si ispira ai principi di: scalabilità dovrà essere scalabile nel tempo per far fronte ad esigenze future di capacità elaborativa acquisibile anche da fornitori di Cloud Pubblico; Openness dovrà aderire a standard aperti (senza costi di licenza) ed esporre interfacce sia grafiche che programmatiche, complete rispetto alle funzionalità fornite; in particolare si attribuisce un ruolo di primo piano ad un SISTEMA OPERATIVO CLOUD (es. OpenStack o similare): il sistema operativo cloud richiesto deve controllare un insieme di risorse computazionali, storage e risorse di rete presenti nel data center in forma virtualizzata, tutte gestite utilizzando una dashboard che fornisce il controllo completo all amministratore e inoltre, Capitolato tecnico di gara Pagina 4 di 45

5 attraverso l utilizzo di un interfaccia web, offre all utente finale le funzionalità di self-service provisioning. Continuità - dovrà supportare un adeguato livello di continuità del servizio, secondo gli standard dettati dal CAD ed in particolare dalle linee guida pubblicate dall AGID. Articolo 2. OBIETTIVI E CONTESTO DI RIFERIMENTO Il Committente intende perseguire, con l acquisizione descritta nel presente capitolato, l'obiettivo di acquisire una soluzione abilitante ad una gestione infrastrutturale e ad un erogazione dei propri servizi IT alle 193 Amministrazioni aderenti, in modo scalabile e flessibile. Il perseguimento di questo obiettivo consentirà al Committente di avvicinarsi progressivamente ad una logica di servizio erogato in modalità Cloud con risorse IT proprie. Dal punto di vista dell utilizzatore (le Amministrazioni), il Cloud Computing presenta due caratteristiche fondamentali: o o Gli utenti (le Amministrazioni) possono scalare a semplice richiesta la fornitura di risorse, senza essere vincolati ad una capacità fissa, attraverso un dimensionamento di tipo dinamico in una logica flessibile di messa a disposizione di risorse a domanda ; L eliminazione di un impegno iniziale, permettendo di allocare le risorse solo quando necessario. Dal punto di vista del Committente, queste caratteristiche richiedono la disponibilità di capacità e- laborativa integrata che viene utilizzata in maniera condivisa da diversi carichi elaborativi (workload). Nel modello a tendere, è necessario che le risorse siano virtualizzate per garantire sia l'utilizzo efficiente delle risorse che la loro programmabilità e gestione attraverso software di automazione ed orchestrazione. Ma la virtualizzazione non è da ritenersi esclusiva, devono essere contemplate anche applicazioni non virtualizzate. In sostanza, l'infrastruttura utilizzata dal fornitore di servizi di tipo Cloud presenta tre caratteristiche fondamentali: o o o risorse infrastrutturali basate su tecnologie standardizzate; virtualizzazione delle risorse elaborative per rendere possibile multiplare la capacità elaborativa in funzione dei workload; automazione dei processi di gestione del servizio. La Piattaforma Tecnologica (hardware e software), illustrata nella figura successiva, dovrà consentire: 1. L erogazione dei servizi applicativi OFF, CAN, PAE del progetto Multiservizi e-gov e servizi di cooperazione applicativa connessi per i Comuni utenti appartenenti a ciascuna aggregazione (Layer Applicativo); Capitolato tecnico di gara Pagina 5 di 45

6 2. La disponibilità dei servizi infrastrutturali avanzati di supporto ai servizi applicativi e di cooperazione applicativa; 3. L erogazione di servizi tecnologici avanzati per le funzionalità di sicurezza, backup, disaster recovery e continuità operativa; 4. La definizione di ambienti separati per test, sviluppo e produzione (Ambienti); 5. La fornitura di servizi a richiesta per i Comuni utenti riguardanti il consolidamento dei server interni degli Enti sulla piattaforma virtuale di progetto; L obiettivo di cui al precedente punto 5, non approfondito nel presente Capitolato tecnico, rappresenta elementi che dovranno essere tenuti in considerazione nell ambito della formulazione dell offerta tecnica. Capitolato tecnico di gara Pagina 6 di 45

7 Segue la rappresentazione grafica dello scenario d uso futuro. Capitolato tecnico di gara Pagina 7 di 45

8 Articolo 3. ARCHITETTURA DELLA PIATTAFORMA ICT La piattaforma tecnologica deve essere considerata una commodity (con il significato di uno strumento ottenibile comodamente, pratico). La realizzazione di questo obiettivo è aiutata dalla a- dozione della tecnologia della virtualizzazione che consente di disaccoppiare le risorse ICT (server, storage, reti) dagli apparati fisici, abbassando i costi legati all hardware e soprattutto i costi legati ai servizi di manutenzione. Significa anche avviare un percorso di integrazione delle tecnologie afferenti ai singoli nodi comunali con quelle che verranno rese operative presso il datacenter comune. E significa garantire la continuità operativa ed il Disaster Recovery dei sistemi comunali. La scelta dello strumento di virtualizzazione è di tipo open source con l apertura della piattaforma tecnologica verso diverse tipologie di hypervisor (VmWare, KVM, Xen, Hyper-V) per consentire la gestione dei diversi ambienti e semplificare ulteriormente l integrazione. La piattaforma tecnologica adotta un modello topologico di risorse elaborative che tiene conto della preesistenza di risorse elaborative già in funzione presso ciascun ente territoriale (193 comuni) e della necessità di organizzare un processo di razionalizzazione di tali risorse convergendo verso un modello Cloud. Per ragioni di resilienza ed affidabilità complessiva del sistema Cloud da realizzare, questo si appoggerà su un data center articolato su almeno due nodi territoriali installati ad almeno 200 km di distanza e perfettamente simmetrici. Come definito nelle linee guida emanate dall AGID, a cui in ogni caso si deve far riferimento nella definire la proposta, per il disaster recovery delle pubbliche amministrazioni, ai sensi del c. 3, lettera b) dell art. 50 bis del Codice dell Amministrazione Digitale (Ag-giornamento 2013), i servizi cloud richiesti per il DR rientrano in due categorie principali: - servizi cloud di DR costruiti dall utente combinando servizi IaaS; - servizi cloud definiti DR as a service (DRaaS). Nel primo caso l utente realizza una soluzione di DR su misura per le proprie esigenze combinando in modo adeguato servizi IaaS di storage e di risorse elaborative offerte dal fornitore di public cloud, gestendo in proprio il trasferimento dei dati e delle immagini delle macchine virtuali nel cloud, il ripristino in caso di disastro e l eventuale conversione a server virtuali di server fisici presenti nel sito primario. La amministrazione utente del servizio deve avere personale competente in quanto, per queste soluzioni fai da te, il fornitore, generalmente, non fornisce servizi di supporto per il trasferimento dati e immagini nel cloud, per il ripristino e per la eventuale conversione phisical-to virtual. Nel secondo caso si tratta di servizi preconfezionati definiti DR as a service finalizzati a consentire, in caso di disastro, il ripristino dei sistemi di produzione dell utente nella infrastruttura cloud con requisiti di RPO e RTO predefiniti in funzione del livello di servizio prescelto. Spesso i fornitori di servizi DRaaS forniscono software per replicare i dati e le applicazioni presenti nel sito primario dell utente al cloud e sono in grado di convertire back-up di macchine fisiche o virtuali in macchine virtuali da attivare nel cloud. Capitolato tecnico di gara Pagina 8 di 45

9 Warm cloud site: nel cloud sono presenti copie non in linea delle macchine virtuali che possono essere attivate in caso di disastro o per attività di test con tempi di ripristino di poche ore (RTO: 2-6 ore, RPO: 0-24 ore). Capitolato tecnico di gara Pagina 9 di 45

10 Nella figura seguente viene illustrato il network che verrà organizzato e gestito con il presente intervento: Capitolato tecnico di gara Pagina 10 di 45

11 Articolo 4. OGGETTO DELL APPALTO La fornitura ha per oggetto i beni elencati nel seguito: o o capacità elaborativa pari a 193 server, installati presso le Amministrazioni di cui al disciplinare, che ospiteranno in ambiente virtualizzato le applicazioni attualmente in esecuzione presso le infrastrutture IT degli stessi comuni e la fornitura di n 579 dispositivi portatili wifi; componenti hardware e software per i due nodi (primario, collocato preferibilmente presso un DC nel territorio della Regione Campania, e secondario ad almeno 200 km di distanza) che supportino i seguenti servizi aggiuntivi: - servizio di backup/restore, per gli stessi 193 server, erogato da un'infrastruttura centralizzata ed in configurazione Disaster Ricovery capace di garantire non oltre 4 ore di fermo del servizio; - servizio Cloud di tipo infrastrutturale (IaaS) per rendere disponibili macchine virtuali per ospitare applicazioni di interesse dei soci e da essi gestite, erogato da un'infrastruttura centralizzata ed in configurazione Disaster Ricovery capace di garantire non oltre 15 minuti di fermo del servizio. Nell ambito della presente fornitura devono essere inclusi anche i servizi professionali tecnicosistemistici necessari ad abilitare l uso delle tecnologie incluse nella fornitura. Sono da includere: o Servizi di implementazione ed avvio, in particolare: - Servizi di installazione e configurazione dei due nodi (HW e SW, incluso Open Stack o similare) - Servizi di integrazione sito primario e sito secondario - Servizi di installazione e configurazione FW - Servizi di installazione e configurazione dei servizi supportati da macchine virtuali, tra cui: Servizi di installazione e configurazione Anti Spam Servizi di installazione e configurazione IDS - IPS Servizi di installazione e configurazione Proxy Content Filtering Servizi di installazione e configurazione Log Management - Realizzazione del portale web dei servizi Cloud - Servizi di installazione dei nodi applicativi locali presso gli enti. o Servizi di addestramento Capitolato tecnico di gara Pagina 11 di 45

12 o o o o o Servizi di gestione in pre-esercizio per sei mesi Servizi di supporto di secondo livello in esercizio per 1 anno Servizi di manutenzione delle componenti hardware e software in esercizio per 3 anni Servizi di housing e facility management comprensivo di 100 Mbit/s di banda per sei mesi sul sito di DR Servizi di gestione progettuale. Capitolato tecnico di gara Pagina 12 di 45

13 Dettaglio delle forniture hardware e software La visione unitaria dell architettura del sistema deve tradursi nella scelta di componenti in grado di assicurare il miglior compromesso fra prestazioni, affidabilità, economia di esercizio e costi di acquisto. Nel seguito verranno descritte compiutamente le caratteristiche dei sistemi server, del sistema di storage, degli apparati di rete, dei software di ambiente e di tutto quanto concorre a definire l architettura complessiva del sistema, insieme ai servizi per lo start-up del sistema. Nella tabella seguente i requisiti generali richiesti alla fornitura ed alla ditta fornitrice. Area Requisiti generali Tipologia di requisito Descrizione Generale Soluzione Architetturale Descrizione Inserire il link al documento che descrive la soluzione tecnica Inserire la soluzione architetturale di alto livello. Descrivere ad alto livello le caratteristiche di openness della soluzione in particolare se è: - una soluzione open basata su Open Source Software (OSS) Requisiti "Openness" - una soluzione proprietaria basata su Open Source Software Requisiti di Scalabilità - una soluzione proprietaria Se basata su OpenStack o similare, indicare le principali customizzazioni e le modalità di integrazione. Descrivere ad alto livello le caratteristiche di scalabilità della soluzione per far fronte ad esigenze future. In particolare descrivere: - massimo numero di oggetti gestiti - massimo numero di macchine virtuali simultaneamente in esecuzione; - massimo numero di socket, disk, VM, rack, zone gestiti Requisiti di continuità Componenti Hardware La configurazione del sistema deve garantire la continuità del servizio a fronte di un evento di tipo "disastro" con ripartenza entro 15 minuti per tutti i servizi eccetto il backup, che deve ripartire entro 4 ore. Indicare la lista delle maggiori componenti HW Capitolato tecnico di gara Pagina 13 di 45

14 Area Tipologia di requisito Componenti SW Descrizione Indicare le tipologie di licenze incluse ed il relativo supporto Inserire la lista dei servizi di supporto inclusi (relativi sia alle componenti HW che SW) nell'ambito della soluzione e le caratteristi- Servizi di supporto alle componenti architetturali (HW, SW) tipologia (on-site support, remote support, local partners support) che dello stesso. Per ogni servizio di supporto fornire il vendor, la etc. Servizi professionali Installazione Migrazione Gestione del progetto Descrizione delle attività di consegna, installazione, attivazione e configurazione delle componenti della soluzione come descritte nel documento di risposta. Definire le modalità di migrazione dallo scenario as-is allo scenario to-be Definire i meccanismi di governance e gestione progettuale. Dare evidenza del piano di progetto distinguendo le fasi di set-up e di gestione Addestramento all'esercizio Definire le modalità di erogazione di attività di addestramento finalizzate a trasferire la necessaria conoscenza per la gestione dell'infrastruttura in ambito (numero di sessioni e numero partecipanti) Profilo societario Supporto Operativo Profili Professionali Profilo Partnership Referenze Evoluzioni della soluzione Definire le modalità con cui verranno erogati i servizi di supporto operativo sull'infrastruttura in ambito Indicare le figure professionali coinvolte in ciascuna fase di progetto ed eventuali certificazioni possedute. Descrizione della società con indicazione delle sedi geografiche Indicare le partnership più significative Specificare referenze su clienti nazionali e/o internazionali con implementazioni analoghe Indicare la roadmap di evoluzione del prodotto indicando gli elementi di innovazione previsti Capitolato tecnico di gara Pagina 14 di 45

15 Area Tipologia di requisito Risorse dedicate Altre informazioni rilevanti sul tema cloud Descrizione Indicare le risorse dedicate al supporto e sviluppo dei prodotti in ambito Aggiungere ogni altra informazione attinente alle capacità "cloud" della società Capitolato tecnico di gara Pagina 15 di 45

16 Hardware Nella tabella seguente sono forniti i requisiti minimi richiesti alle componenti hardware oggetto della fornitura. I requisiti si riferiscono a tipologie di server (di tipo A) destinati ad ospitare la piattaforma di gestione del Cloud e del Backup/Restore, e server blade (di tipo B) destinati ad ospitare i servizi IaaS ed applicativi. La configurazione richiesta, in termini di CPU e memoria, deve avere lo stesso livello di espandibilità al fine di permetterne un eventuale riutilizzo nell evoluzione del sistema. Area Requisito Descrizione Quantita minima Rack Tipologia Rack Rack standard 42 U 2 Densità di server blade ospitabile all interno di un singolo rack 42U Almeno 48 server fisici in formato blade per singolo rack Chassis Minima quantità di chassis per server in formato blade Almeno N. 2 chassis per server in formato blade 2 Densità di server nello chassis Slot disponibili per le blade servers: min. 8 per singolo chassis Superiori a 8 server fisici per singolo chassis Superiori a 16 server fisici per singolo chassis 16 Architetture CPU supportate In grado di ospitare in modalità mista, server a 2 CPU e server a 4CPU con i seguenti sistemi operativi: Windows, Linux, VMWare, Possibilità di installare all'interno dello stesso chassis server in modalità mista, server a 2 CPU e server a 4 CPU con i seguenti Sistemi Operativi : Windows, Linux, Vmware, AIX Possibilità di installare all'interno dello stesso chassis blades con processori di tipo RISC Capitolato tecnico di gara Pagina 16 di 45

17 Area Requisito Descrizione 2 slot disponibili per i moduli switch I/O interni al singolo chassis Quantita minima Possibilità di inserire all'interno dello stesso chassis ulteriori 2 switch Ethernet analoghi a quelli forniti, oltre a eventuali passtrough, FcoE o FC a 16Gb Alimentazione Alimentatori: Ridondati e hot swap, configurati in modo da supportare la configurazione massima del Blade Chassis I/O dello chassis Raffreddamento Ventole: ridondate e hot swap, le ventole fornite dovranno essere in grado di supportare la configurazione massima del Blade Chassis Gestione integrata Modulo di management interno allo chassis, con porta e- thernet per la gestione dei server Blade e delle componenti dello Chassis via TCPIP. Tale modulo dovrà essere ridondato. Il traffico di management all'interno dello chassis dovrà avvenire su dedicata Il modulo di management dello chassis dovrà provvedere, in caso di guasto di una qualsiasi parte, alla apertura automatica della chiamata, in modalità elettronica, presso il servizio di assistenza del produttore opzionale opzionale virtualiza- I/O tion L intera architettura dello chassis e di tutti i suoi componenti deve garantire il supporto alla virtualizzazione delle connessioni, per permettere la sostituzione dei server fisici senza dover riconfigurare l intero ambiente dal punto di vista della connettività Switch Ethernet Cavi Switch Ethernet a 10Gb, hot-plug con ognuno almeno N.14 porte interne a 10Gb abilitate e N.10 porte di uplink verso la rete esterna. Per ogni swich dovranno essere forniti N.2 SFP+ a 10Gb Possibiltà di switch con scalabilità fino a 64 porte a 10Gb, tutte installate fisicamente o abilitabili tramite licenza SW (senza upgrade HW) su singolo switch Ethernet integrato fornito Possibilità di switch integrati con disponibilità di porte di u- plink a 40Gb Cavi per collegamento apparati (a soddisfo), specificare le 8 A corpo Capitolato tecnico di gara Pagina 17 di 45

18 Area Requisito Descrizione caratteristiche Quantita minima Servers Blades tipo A Blades con minimo N. 2 CPU E v2 8c e 64GB RAM espandibile a 768GB 2 Possibilità di utilizzare tutti e 24 slot di memoria RAM, con qualsiasi modello di CPU installabile sul server (indipentemente dalla CPU richiesta). Valido per sistemi con 2 CPU installate. Possibilità di ospitare fino a 8 dischi SSD non hot-plug interni (senza aggiunta di dispositivi esterni) Supporto RAID 0 1 HW Supporto RAID 5, 6, 10, 50, 60 HW (anche mediante controller SAS interno aggiuntivo) Controller Ethernet: adattatore dual port 10Gb Gigabit CNA collegato agli switch interni dello chassis via midplane Supporto di mezzanine quad port FC 16GB ed Ethernet 10gb CNA Possibilità di gestire le connessioni ethernet a 10Gb in modalità multi MAC Address (partizionamento e associazione di almeno 4 MAC Address distinti per singola porta) Blades tipo B Blades con almeno N. 2 CPU E v2 12C e 384GB RAM espandibile a 768GB 6 Possibilità di utilizzare tutti e 24 slot di memoria RAM, con qualsiasi modello di CPU installabile sul server (indipentemente dalla CPU richiesta). Valido per sistemi con 2 CPU installate. Predisposizione per installazione USB Key interna Disponibilità di 2 o piu USB Key interne con il software Hipervisor VMWARE Possibilità di ospitare fino a 8 dischi SSD non hot-plug interni (senza aggiunta di dispositivi esterni) Capitolato tecnico di gara Pagina 18 di 45

19 Area Requisito Descrizione Supporto RAID 0 1 HW Quantita minima Nodo locale Nodo locale Tower Server di tipo A (consegnare ai comuni <5.000 ab.) Tower Server di tipo B (consegnare ai comuni >5.000 ab. < ab.) Supporto RAID 5, 6, 10, 50, 60 HW (anche mediante controller SAS interno aggiuntivo) Controller Ethernet: adattatore dual port 10Gb Gigabit CNA collegato agli switch interni dello chassis via midplane Supporto di mezzanine quad port FC 16GB ed Ethernet 10gb CNA Possibilità di gestire le connessioni ethernet a 10Gb in modalità multi MAC Address (partizionamento e associazione di almeno 4 MAC Address distinti per singola porta) Minimo N. 1 CPU E3-1270v2 4c 8GB RAM espandibile e hard disk n 2 x 500Gb Possibilità di ospitare almeno 4 HDD 3.5" simple swap Possibilità di ospitare almeno 8 HDD 2.5" hot swap Supporto SSD N.2 alimentatori ridondati, hot-swap e certificati 80Plus Preinstallato S.O. linux CENTOS u.v. N. 1 CPU E3-1270v2 4c 16GB RAM espandibile e hard disk n 2 x 1Tb Possibilità di ospitare almeno 4 HDD 3.5" simple swap Possibilità di ospitare almeno 8 HDD 2.5" hot swap Supporto SSD Capitolato tecnico di gara Pagina 19 di 45

20 Area Requisito Descrizione N.2 alimentatori ridondati, hot-swap e certificati 80Plus Quantita minima Nodo locale Tower Server di tipo C (consegnare ai comuni > ab.) Preinstallato S.O. linux CENTOS u.v. N. 2 CPU E3-1270v2 4c 32GB RAM espandibile e hard disk n 2 x 2Tb Possibilità di ospitare almeno 4 HDD 3.5" simple swap Possibilità di ospitare almeno 8 HDD 2.5" hot swap Supporto SSD N.2 alimentatori ridondati, hot-swap e certificati 80Plus Preinstallato S.O. linux CENTOS u.v. 10 Supporto locale Dispositivi portatili tablet 7 memoria 8 GB min 579 Rack Server Rack Server Rack Server a 2U con minimo 2 CPU E5-2650v2 8c con almeno 64GB RAM espandibile a 512GB 2 Alimentatori e ventole : Ridondati e hot swap Predisposizione per installazione USB Key interna Storage Storage Protocolli Cache Espandibilità Dimensioni fisiche dischi Sistema di Storage SAN con dual controller e almeno 240TB lordi Supporto di dischi di tipo: SAS, NL-SAS, SSD Almeno 2 porte iscsi 1 Gb, almeno 2 porte iscsi/fcoe 10Gb, almeno 3 porte SAS 6Gbps per controller Cache: Minimo 4 GB per controller Espandibilità cache ad 8GB per controller Tipologia dischi: deve poter contenere unità disco da 3,5 oppure da 2,5" 2 Capitolato tecnico di gara Pagina 20 di 45

21 Area Requisito Descrizione Numero minimo di unità disco supportate Intermix dischi: deve essere possibile, compatibilmente con la relativa form factor, l intermix dei dischi all interno dello stesso enclosure Numero minimo di unità disco supportate = 60 Raid supportati Raid supportati: 0, 1, 5, 6 e 10 Quantita minima Estrazione a caldo dei dischi Thin Provisioning Hierarchical Storage Management GUI Gestione dischi: possibilità di estrazione/inserimento a caldo dei dischi Thin Provisioning: deve consentire la over-allocation dello spazio fisico disponibile presentando volumi logici agli host senza dover allocare il relativo spazio fisico, questa funzionalità deve essere fornita per tutta la capacità disco fornita Possibilità di gestione dinamica dei tier disco in base al carico: si richiede funzionalità software che consenta, nell'ambito dei Tier presenti, di selezionare in modo dinamico e automatizzato l'utilizzo dei livelli più pregiati (SSD) per le porzioni di volumi con maggior accesso; questa funzionalità deve essere fornita per tutta la capacità disco fornita Software di Gestione: Interfaccia grafica di amministrazione semplice ed intuitiva raggiungibile via browser LUN Migration LUN migration: deve consentire la possibilità di migrare a caldo i volumi virtuali tra pool disco aventi diverse caratteristiche di prezzo e prestazioni Snapshot Replica Snapshot: possibilità di creare snapshot locali di tipo cascading, multitarget e incremental anche in modalità space efficient (ossia in modalità Thin provisioning), questa funzionalità deve essere fornita per tutta la capacità disco fornita Replica Remota: supporto per replica remota sia di tipo sincrono che asincrono. Questa funzionalità deve essere fornita per tutta la capacità disco fornita Capitolato tecnico di gara Pagina 21 di 45

22 Area Requisito Descrizione Predisposizione dell'infrastruttura per replica remota implementata attraverso protocollo FC e protocollo IP Quantita minima Firewall Firewall ICSA, certificazione IPSec, Stateful packet inspection, IPv6 Ready 2 Porte Gigabit Ethernet >5 Porta USB da utilizzare per connessioni WAN wireless 3G 2 Bandwidth Management per impostare priorità differenti al traffico e garantire una migliore gestione della banda passante per ogni connessione Load Balancing sulle linee WAN per garantire sempre un servizio ottimale e affidabile. Funzionalita High Availability su due dispositivi per evitare il Single Point of Failure, Active-Passive mode, Device failure detection and notification,auto-sync configurations Sistema di reporting, log management e monitoraggio servizi (statistiche accessi, ecc.) garanzia Servizio di garanzia su tutta l'infrastruttura 36 mesi con sostituzione delle parti ed intervento giorno lavorativo successivo all'apertura della chiamata (NBD) Componenti Cloud Nelle tabelle seguenti sono forniti i requisiti minimi richiesti alle componenti software oggetto della fornitura. Le forniture si intendono a corpo. Area Requisito Descrizione Self Service Provisioning Interfaccia Utente Web - La soluzione proposta dovrà avere un'interfaccia web accessibile e disponibile attraverso una rete private o pubblica. La User Interface dovrà supportare i browser più diffusi e consentire la navigazione e la ricerca degli oggetti e servizi gestiti nel catalogo. - La User interface deve essere scalabile ossia dovrà consentire l'organizzazione gerarchica di gruppi di oggetti e sottogruppi, se- Capitolato tecnico di gara Pagina 22 di 45

23 Area Requisito Descrizione lezione massiva di oggetti che soddisfano criteri definiti. - Le richieste di provisioning sono gestite per mezzo del portale del quale potrà essere visibile lo stauts delle richieste Gestione delle richieste - Dovranno essere definiti utenti abilitati al provisioning degli oggetti definiti nel catalogo ed esposti nel portale. Ogni utente potrà accedere al portale attraverso delle adeguate autorizzazioni che attribuiranno ai diversi utenti alcuni - Le autorizzazioni sono definite dall'amministratore. - L'amministratore deve poter predefinire quali oggetti non necessitano di approvazione (pre-approvati) e la dotazione iniziale di risorse (baseline) per ciascun utente o gruppi di utenti. - La richiesta dovrà consentire la pianificazione del provisioning anticipata Il portale di provisioning deve essere in grado di gestire oggetti di provisioning e di operare su di loro. Devono essere garantite le seguenti operazioni: Gestione del ciclo di vita degli oggetti gestiti - Avvio e arresto - Destroy - Riconfigurazione hardware virtuale - Delega del controllo e trasferimento dell'ownership - Aggiunta di azioni personalizzate automatiche dopo la creazione o dopo la distruzione di macchine virtuali - Avvio manuale delle azioni automatiche (personalizzate) dopo la creazione di macchine virtuali Service Catalog Statistiche d'uso del portale Lingua Console di amministrazione La soluzione dovrà consentire di raccogliere statistiche sull'utilizzo del portale Il portale dovrà essere in lingua italiana - La soluzione dovrà garantire l'esistenza di un'interfaccia Web di amministrazione. La console di amministrazione web based,dovrà consentire la definizione e la gestione degli oggetti del catalogo e la gestione della profilazione utenti con relativa attribuzione di poteri; Capitolato tecnico di gara Pagina 23 di 45