CAPITOLATO TECNICO

PROCEDURA APERTA CON MODALITÀ TELEMATICA SU PIATTAFORMA ASP CONSIP PER L’AFFIDAMENTO DELL’APPALTO AVENTE AD OGGETTO LA FORNITURA, INSTALLAZIONE E CONFIGURAZIONE DI UNA INFRASTRUTTURA INFORMATICA PER IL POTENZIAMENTO DELL’ACTRIS AEROSOL REMOTE SENSING NODE CPV 30230000-0 NELL’AMBITO DEL PROGETTO PER-ACTRIS-IT COD. PIR01_00015 - IMPORTO COMPLESSIVO € 1.373.952,00 SUDDIVISO IN 3 LOTTI FUNZIONALI

GARA N. 7759770 CUP: B17E19000000007 CPV: 30230000-0

Sommario

1 – Premessa e oggetto 3

2 – Termini e luogo di consegna ed installazione 3

3 - Obblighi dell’aggiudicatario 4

3.1 - LOTTO 1 Border Firewall 4

3.2 - LOTTO 2 DC Network 7

3.3 - LOTTO 3 DC Calculus Storage 11

4 – LOTTO 1 – Border Firewall 16

5 – LOTTO 2 DC Network 18

6 – LOTTO 3 DC Calculus Storage 27

1 – Premessa e oggetto

Il presente capitolato illustra le specifiche tecnico/operative relative alla fornitura, installazione e configurazione di una infrastruttura informatica, sinteticamente indicata nella sottostante tabella, le cui caratteristiche minime sono descritte, per singolo lotto, nelle successive specifiche sessioni.

# Lotto CIG Descrizione sintetica
1	8296137CD1	Fornitura, installazione e configurazione di Border Firewall
2	829615078D	Fornitura, installazione e configurazione di DC Network
3	829616431C	Fornitura, installazione e configurazione di DC Calculus Storage

Rimane salva l’offerta migliorativa presentata dal concorrente in sede di gara.

Tutta la strumentazione dovrà essere nuova di fabbrica e allo “stato dell’arte” per l’attuale tecnologia, con possibilità di eventuali implementazioni e potenziamenti futuri. Nella fornitura delle apparecchiature richieste dovranno essere compresi, ove necessario, tutti i componenti hardware e software di ultima generazione presenti sul mercato per strumenti della medesima classe, al fine di offrire prestazioni in grado di soddisfare le esigenze del progetto.

La strumentazione dovrà essere inoltre conforme alle vigenti normative europee in materia di sicurezza.

I requisiti tecnico/funzionali espressi nel presente Capitolato Tecnico sono da intendersi requisiti minimi di fornitura pena esclusione; pertanto le caratteristiche tecniche e funzionali delle componenti offerte dovranno rispettare tutti i requisiti richiesti.

L'utilizzo nel presente documento del verbo "dovere" nelle forme di "deve" e "dovrà", anche se non seguite dall'avverbio "obbligatoriamente", indica in ogni caso obblighi di fornitura e/o proposizione tecnica non negoziabili da parte del Fornitore.

Tutti i sistemi e le relative funzionalità in offerta devono essere disponibili sul listino/portafoglio prodotti pubblico ufficiale del produttore/costruttore degli apparati al momento della sottomissione dell’offerta.

2 – Termini e luogo di consegna ed installazione

I termini di consegna, installazione e configurazione della strumentazione di cui al paragrafo § 1 sono espressi in giorni naturali e consecutivi decorrenti dal giorno successivo alla sottoscrizione del contratto sulla base della seguente tempistica stimata:

# Lotto	Termine di consegna	Termine di installazione e messa in esercizio
1	30	45
2	60	90
3	90	150

La consegna, installazione e configurazione della strumentazione dovranno essere effettuate presso gli indirizzi indicati in tabella, in accordo il Direttore dell’esecuzione del contratto (nel seguito DEC) indicato nel contratto:

# Lotto Luogo di consegna e installazione
1	Istituto di Metodologie per l’Analisi Ambientale del Consiglio Nazionale delle Ricerche (CNR-IMAA), Xxxx Xxxxxxxxxxx – 00000 Xxxx (XX)
2	Istituto di Metodologie per l’Analisi Ambientale del Consiglio Nazionale delle Ricerche (CNR-IMAA), Xxxx Xxxxxxxxxxx – 00000 Xxxx (XX)
3	Istituto di Metodologie per l’Analisi Ambientale del Consiglio Nazionale delle Ricerche (CNR-IMAA), Xxxx Xxxxxxxxxxx – 00000 Xxxx (XX)

L’aggiudicatario dovrà provvedere, a propria cura e spese allo smaltimento di tutti gli imballaggi e dei materiali di risulta nel pieno rispetto della normativa vigente in relazione alla tipologia di materiale da smaltire.

Per ogni singolo lotto, l’operatore economico dovrà fornire in sede di offerta evidenza di tutti i dati impiantistici complessivi stimati, in termini di assorbimento elettrico, di dissipazione termica, di ingombro e peso delle apparecchiature oggetto della fornitura al fine di consentire le opportune valutazioni con congruo anticipo rispetto alla fase di installazione.

3 - Obblighi dell’aggiudicatario

3.1 - LOTTO 1 – Fornitura, installazione e configurazione di Border Firewall

L’aggiudicatario si obbliga a fornire:

3.1.1 - Descrizione de progetto:

Al fine di garantire una maggiore comprensione delle caratteristiche tecniche riguardanti la fornitura oggetto del presente lotto, di seguito viene brevemente descritta l’infrastruttura che si intende realizzare (si veda anche lo schema allegato lotto1_schema_progetto.pdf).

La fornitura dovrà essere basata su un sistema di Next Generation Firewall in modalità ACTIVE/ACTIVE.

I Firewall andranno interconnessi a una coppia di Service Leaf e configurati in modalità MLAG/MC- LAG.

Tra i Firewall e i Service Leaf andranno configurati dei LAG LACP (active mode) dedicati al solo traffico di rete. Di conseguenza, le interfacce di management e di H.A. del firewall dovranno essere configurate, in modo ridondato, su interfacce fisiche dedicate.

Nell'ottica di eliminare i "single point of failure", il progetto prevede la ridondanza di tutte le componenti hardware, compresi gli uplink, i LAG, etc.

L’infrastruttura di firewalling costituirà il cuore dei servizi di sicurezza del CNR-IMAA e pertanto costituisce un'attività “mission critical” per l'Ente.

Si richiede, quindi, che il produttore degli apparati sia in grado di fornire opportuno e tempestivo supporto "mission critical", attraverso almeno un call center sempre raggiungibile - eventualmente dirottando le chiamate in altri Stati in funzione di orari e festività - in grado di gestire la prima fase di troubleshooting di concerto con il personale CNR-IMAA, e quindi di recapitare eventuali parti di ricambio presso le sedi di fornitura entro il giorno lavorativo successivo.

3.1.2 – Installazione:

La strumentazione dovrà essere installata e configurata come meglio specificato nel paragrafo “Termini e luogo di consegna e installazione e configurazione”. L’aggiudicatario dovrà provvedere

all’installazione delle apparecchiature all’interno dei rack presenti nel locale CED e alla relativa configurazione tecnica secondo lo schema di progetto allegato lotto1_schema_progetto.pdf a sue spese provvedendo, altresì, al trasporto, disimballaggio, montaggio e messa in funzione delle apparecchiature. L’aggiudicatario deve garantire la consegna della strumentazione esente da difetti e perfettamente funzionante.

3.1.3 – Messa in esercizio/configurazione:

L’operatore economico aggiudicatario dovrà presentare un progetto per l'installazione, configurazione e messa in esercizio del nuovo sistema, tenendo presente che detti lavori dovranno essere realizzati nel normale orario di lavoro del CNR (9,00-17,30 dal lunedì al venerdì), concordando preventivamente tutte le operazioni che comportano assenze di connettività.

Entro 10 giorni successivi all’aggiudicazione definitiva, l’aggiudicatario dovrà concordare con il CNR- IMAA un piano operativo che, sulla base del progetto presentato, vada a dettagliare tutte le attività da effettuare, prevedendo almeno le seguenti fasi:

1. Disegno dell'infrastruttura da realizzare e redazione del progetto esecutivo di dettaglio. Tale progetto, inoltre, dovrà dettagliare una soluzione per la migrazione dall’attuale infrastruttura di firewalling del Data Center del CNR-IMAA verso la nuova infrastruttura proposta. La soluzione proposta per la migrazione dovrà prevedere anche una fase iniziale di coesistenza dei due ambienti in modo da ridurre al minimo eventuali disservizi.

2. Messa a disposizione di un laboratorio di test, anche virtuale e remoto, dove simulare l’infrastruttura da realizzare e le relative configurazioni da implementare.

Dovranno essere inoltre previsti misuratori di performance dello stesso in accordo con gli standard “Benchmarking Methodology Working Group (BMWG)” IETF:2544 (IPv4), 2889 (LAN switch), 3918 (Multicast), 5180 (IPv6) e 5965 (IP/MPLS).

Tutti gli oneri relativi a questo specifico punto si intendono a carico dell’operatore economico.

3. Installazione e validazione dei sistemi nei rack, loro cablatura ed interconnessione alla rete elettrica. Quest'ultima attività dovrà essere eseguita secondo uno schema concordato con il personale CNR-IMAA prima della consegna del materiale.

4. Configurazione on-site, in affiancamento con il personale tecnico del CNR-IMAA, dei firewall e della piattaforma di management centralizzato, secondo le modalità concordate col personale del CNR-IMAA.

5. Integrazione dei nuovi firewall, affiancandoli a quelli esistenti, in modo da permettere un processo di migrazione che minimizzi qualsiasi disservizio ed, in particolare, quelli legati a mancanza di connettività.

6. Verifiche funzionali, tuning dei sistemi ed altre attività propedeutiche al collaudo della fornitura. In caso di positivo riscontro passaggio al successivo punto 7.

7. Messa in funzione dei nuovi firewall, dismettendo i vecchi.

8. Attività di formazione sul campo del personale del CNR-IMAA.

9. Verifica di conformità/Collaudo dell’infrastruttura.

Il completamento di ciascuna delle fasi indicate dovrà essere formalizzato con un apposito verbale di regolare esecuzione che dovrà essere approvato dal DEC.

Inoltre, relativamente alla fornitura dovranno essere rilasciati:

 I manuali (installation guide, hardware technical reference, operation's guide, ecc..), in lingua italiana o inglese, su supporto cartaceo e/o ottico;

3.1.4 – Configurazione tecnica:

L’infrastruttura da realizzare e il relativo progetto, dovranno tenere conto dei seguenti requisiti tecnici minimi:

 Gli apparati forniti dovranno essere configurati in modalità High Availability (HA) Active/Active in modo da garantire un livello di ridondanza di tipo N+1;

 Export di tutte le configurazioni del Firewall PA-3020 attualmente in funzione ed importazione delle stesse sugli apparati forniti; in particolare le configurazioni riguardano le zone di protezione (DMZ, WAN, INSIDE, etc..), gli accounting, le VPN di tipo SSL e IpSEC, le policies applicative e le configurazioni deli IDS/IPS e tutte le altre configurazioni presenti e funzionali all’infrastruttura informatica del CNR-IMAA.

 Gli apparati forniti dovranno essere configurati in modo da essere gestiti tramite la piattaforma di gestione centralizzata oggetto della fornitura.

 Dovranno essere configurate tutte le VLAN (L2) e Interface VLAN (L3) IPv4 e IPv6 dell’attuale rete 3-tier esistente. I firewall effettueranno le operazioni di routing e saranno il “gateway” di ogni Interface XXXX (xxxxx 00 XXXX L2 e Interface VLAN L3 attualmente attive, con possibilità di aumento di circa il 15% alla data di effettiva esecuzione).

 Dovrà essere utilizzato e configurato, come protocollo di routing dinamico tra i firewall e l’infrastruttura di rete del CNR-IMAA, OSPFv3.

 Dovrà essere configurata una VPN di tipo IpSEC tra i firewall e un router Cisco 2811.

 Dovrà essere configurata una VPN di tipo IpSEC tra i firewall e un firewall Paloalto Networks PA-200.

 Dovrà essere configurata una VPN di tipo SSL remote access, come sistema di accesso remoto alla rete del CNR-IMAA per gli utenti e per gli amministratori, con diversi profili di accesso.

 Dovrà essere configurata una interfaccia dedicate Out Of Band (OOB) con VRF forwarding.

3.1.5 – Formazione:

L’aggiudicatario dovrà garantire un programma di addestramento all’uso ed alla manutenzione ordinaria della strumentazione e dei relativi software di gestione, per il personale del CNR-IMAA di durata minima effettiva di almeno 36 (trentasei) ore per un’erogazione giornaliera non superiore alle sei ore complessive in non meno di 6 (sei) giornate lavorative. La formazione, effettuata da un tecnico specializzato, dovrà essere svolta on-site presso la sede di consegna ed installazione secondo un calendario preventivamente approvato dal Responsabile Unico del Procedimento sentito il Responsabile per la corretta esecuzione del contratto. Il programma di addestramento dovrà essere avviato entro 10 (dieci) giorni solari dalla verifica di conformità superata con esito positivo, salvo diverso accordo con il DEC. Il corso e la documentazione di addestramento dovranno essere in lingua italiana e/o inglese.

3.1.6 – Assistenza tecnica e manutenzione:

Considerata la complessità della fornitura, è richiesto, per quanto possibile, che l’erogazione dei servizi di assistenza tecnica e manutenzione venga effettuata direttamente dai costruttori/produttori delle componenti hardware e software oggetto della fornitura. Il personale tecnico del CNR-IMAA dovrà in ogni caso poter interagire direttamente con i costruttori/produttori senza intermediazione del fornitore. Pertanto, il concorrente dovrà offrire il servizio di manutenzione ufficiale del produttore degli apparati, agendo in tal senso esclusivamente in regime di rivenditore anche attraverso una propria rete di tecnici specializzati e riconosciuti dal produttore.

Tale requisito non è da considerarsi essenziale per le sole componenti per cui non è previsto il vincolo dell’unicità del produttore.

In tal senso, nella documentazione tecnica di gara dovrà essere acclusa la documentazione ufficiale del produttore attestante la tipologia, la codifica ed i dettagli del servizio di assistenza e manutenzione offerto.

Il servizio di assistenza e manutenzione dovrà essere di tipo Next Business Day 8x5, con i seguenti requisiti minimi:

- Call-center e portale web accessibile in modalità 24x7x365 per l’apertura delle chiamate di assistenza da parte del personale del CNR-IMAA.

- Return Merchandise Authorization (RMA) level di tipo Next Business Day (NBD).

- Disponibilità degli aggiornamenti, upgrade e bug fix software.

3.1.7 – Il produttore degli apparati dovrà garantire la disponibilità delle parti di ricambio almeno per 60 (sessanta) mesi.

3.1.8 – Garanzia:

La garanzia fornita, inclusiva di quanto riportato alla sezione 3.1.4, dovrà coprire un periodo minimo di 36 mesi (trentasei) mesi dalla data di verifica di conformità della strumentazione superata con esito positivo. Tale garanzia deve comprendere le riparazioni o sostituzioni di parti (con esclusione delle parti

c.d. “consumabili” chiaramente individuabili nella documentazione a corredo) necessarie al funzionamento ottimale della strumentazione. Xxxxxx ritenersi, inoltre, comprese nella garanzia le spese di trasferta ed i costi della manodopera dei tecnici presso la sede di consegna ed installazione. Per l’intero periodo di vigenza della garanzia, l’aggiudicatario si impegna a fornire gratuitamente gli eventuali upgrade alle licenze software necessarie al funzionamento delle apparecchiature e/o software a corredo.

3.1.9 – Verifica di conformità/collaudo:

L’aggiudicatario sarà tenuto a provvedere, a propria cura e spese, di concerto con il DEC, alla verifica tecnica di conformità della strumentazione, che dovrà essere effettuata entro 30 (trenta) giorni naturali e consecutivi dall’avvenuta installazione e configurazione della fornitura.

Le attività di verifica riguarderanno:

- La presenza di tutti gli articoli oggetto della fornitura;

- La rispondenza delle caratteristiche tecniche dei prodotti consegnati, rispetto all’offerta tecnica presentata;

- Il rispetto delle richieste di installazione e configurazione come dai punti 3.1.2, 3.1.3 e 3.1.4 del presente capitolato;

- L’assistenza tecnica e manutenzione e della garanzia offerta, come dai punti 3.1.6 e 3.1.7 del presente capitolato.

Nell’ipotesi in cui la verifica di conformità/Xxxxxxxx non dovesse essere superata con esito positivo, l’aggiudicatario avrà 30 (trenta) giorni di tempo, non derogabili, per porre in essere tutte le azioni utili al superamento della verifica di conformità/collaudo con esito positivo.

3.1.10 – Spese:

L’offerta presentata in sede di gara dall’aggiudicatario deve comprendere tutte le spese relative al trasporto, all’installazione, alla configurazione della strumentazione, alle procedure di verifica di conformità ed al programma di addestramento del personale della stazione appaltante.

3.2 - LOTTO 2 – Fornitura, installazione e configurazione di DC Network

L’aggiudicatario si obbliga a fornire: 3.2.1 - Descrizione del progetto:

Al fine di offrire una maggiore comprensione delle caratteristiche tecniche della fornitura oggetto del presente lotto, di seguito viene brevemente descritta l’infrastruttura che si intende realizzare (si veda anche lo schema allegato lotto2_schema_progetto.pdf).

L’infrastruttura di cui si richiede la quotazione dovrà essere basata su un sistema di Networking di tipo LEAF-SPINE L3/L2 EVPN-VXLAN con l’accentramento di tutti i servizi all’interno dei locali del CED del CNR-IMAA, dove si dovrà realizzare la Fabric L3/L2. Si dovranno anche effettuare le dovute configurazioni per interfacciare gli switch di piano già esistenti (Cisco Catalyst 2960-X e 3750-G) con la nuova infrastruttura di networking, attraverso gli apparati di tipo CAMPUS LEAF che andranno ad aggregare tale traffico. Inoltre, si dovranno connettere al CED, tramite VPN IPSec, una sede secondaria e una Server Farm remota del CNR-IMAA.

Per quanto riguarda gli apparati di sicurezza, attualmente il CED del CNR-IMAA è fornito di Firewall Paloalto Networks, che dovrà integrarsi con le configurazioni di tutti gli apparati di networking richiesti e con le eventuali soluzioni di firewall le cui caratteristiche sono indicate nel paragrafo precedente.

Nell'ottica di eliminare i "single point of failure", il progetto prevede la ridondanza di tutte le componenti hardware, compresi gli Switch, gli uplink tra i LEAF e gli SPINE, i LAG, etc.

L’infrastruttura di networking costituirà il cuore dei servizi di rete del CNR-IMAA e pertanto costituisce un'attività “mission critical” per l'Ente.

Si richiede quindi che il produttore degli apparati sia in grado di fornire supporto "mission critical", attraverso almeno un call center sempre raggiungibile - eventualmente dirottando le chiamate in altri Stati in funzione di orari e festività - in grado di gestire la prima fase di troubleshooting di concerto con il personale CNR-IMAA e, quindi, di recapitare eventuali parti di ricambio presso le sedi di fornitura entro il giorno lavorativo successivo.

3.2.2 – Installazione:

La strumentazione dovrà essere installata come meglio specificato nel paragrafo “Termini e luogo di consegna e installazione”. L’aggiudicatario dovrà provvedere all’installazione delle apparecchiature all’interno dei rack presenti nel locale CED secondo lo schema di progetto allegato lotto2_schema_progetto.pdf a sue spese provvedendo al trasporto, montaggio e messa in funzione delle apparecchiature.

L’aggiudicatario deve garantire la consegna della strumentazione esente da difetti e perfettamente funzionante.

3.2.3 – Messa in esercizio/configurazione:

L’aggiudicataria dovrà presentare un progetto per l'installazione, configurazione e messa in esercizio del nuovo sistema, tenendo presente che detti lavori dovranno essere realizzati nel normale orario di lavoro del CNR (9,00-17,30 dal lunedì al venerdì), concordando preventivamente tutte le operazioni che comportano assenze di connettività.

Entro 10 giorni successivi all’aggiudicazione definitiva, la società aggiudicataria dovrà concordare con il DEC un piano operativo che, sulla base del progetto presentato vada a dettagliare tutte le attività da effettuare, prevedendo almeno le seguenti fasi:

1. Disegno dell'infrastruttura da realizzare e redazione del progetto esecutivo di dettaglio. Tale progetto, inoltre, dovrà dettagliare una soluzione per la migrazione dall’attuale infrastruttura di networking del Data Center del CNR-IMAA verso la soluzione proposta. La soluzione proposta per la migrazione dovrà prevedere una fase iniziale di coesistenza dei due ambienti in modo da ridurre al minimo eventuali disservizi.

2. Messa a disposizione di un laboratorio di test anche virtuale e remoto, dove simulare l’infrastruttura da realizzare e le relative configurazioni da implementare.

Tutti gli oneri relativi a questo punto si intendono a carico dell’operatore economico.

3. Installazione e validazione dei sistemi nei rack, loro cablatura ed interconnessione alla rete elettrica. Quest'ultima attività dovrà essere eseguita secondo lo schema concordato con il personale CNR-IMAA all’uopo indicato prima della consegna del materiale.

4. Configurazione on-site, in affiancamento con il personale tecnico del CNR-IMAA, degli apparati di networking e della piattaforma di management centralizzato, secondo le modalità concordate col personale del CNR-IMAA.

5. Integrazione della nuova infrastruttura di networking, affiancandola a quella esistente, in modo da permettere un processo di migrazione parziale.

6. Verifiche funzionali, tuning dei sistemi ed altre attività propedeutiche al collaudo della fornitura e, in caso di esito positivo, passaggio al punto 7..

7. Messa in funzione della nuova infrastruttura di networking, dismettendo la vecchia.

8. Attività di formazione sul campo del personale del CNR-IMAA.

9. Verifica di conformità/Collaudo dell’infrastruttura.

Il completamento di ciascuna delle fasi indicate dovrà essere formalizzato con un apposito verbale di regolare esecuzione che dovrà essere approvato dal DEC.

Inoltre, relativamente alla fornitura dovranno essere rilasciati:

- I manuali (installation guide, hardware technical reference, operation's guide, ecc..), in lingua italiana o inglese, su supporto cartaceo e/o ottico;

3.2.4 – Configurazione tecnica:

L’infrastruttura di networking da realizzare dovrà tenere conto dei seguenti requisiti tecnici minimi:

- Dovrà essere realizzata una Layer 3 IP Fabric LEAF-SPINE EVPN (control plane) - VXLAN (data plane) con Overlay Network, basata su Protocolli Standard Open.

- Il routed interconnection tra spine e leaf dovrà essere di tipi Xxxxx-xx-Xxxxx X0 (no port- channel).

- Ogni coppia di LEAF e WAN ROUTER dovrà essere interconnessa in MLAG in modo da funzionare a livello logico come un singolo apparato.

- La connessione tra gli SPINE e i COMPUTE LEAF, CAMPUS LEAF e SERVICE LEAF dovrà avvenire tramite cavi AOC QSFP 100GbE. Ogni LEAF dovrà avere almeno n.2 uplink verso ogni singolo SPINE.

- La connessione tra i SERVICE LEAF e i WAN ROUTER dovrà avvenire tramite cavi AOC QSFP 100GbE. Ogni WAN ROUTER dovrà avere almeno n.2 uplink verso ogni singolo SERVICE LEAF.

- La connessione tra i CAMPUS LEAF e i CAMPUS ACCESS dovrà avvenire tramite cavi AOC SFP28 25/10GbE. Ogni CAMPUS ACCESS dovrà avere almeno n.2 uplink verso ogni singolo CAMPUS LEAF.

- L’infrastruttura di rete dovrà utilizzare virtual gateway active/active, per ridurre l’utilizzo di indirizzi IP.

- Il protocollo di routing dinamico da utilizzare per la comunicazione tra gli apparati leaf-spine dovrà essere eBGP con ECMP per gestire il load sharing/balance.

- Per il peering tra le coppie di LEAF in MLAG si dovrà utilizzare come protocollo di routing iBGP.

- Hardware VTEP (no software).

- VXLAN Routing Topologies: asimmetryc IRB.

- Il protocollo di routing da utilizzare per la comunicazione con gli altri apparati presenti nel datacenter dovrà essere basato su OSPFv4.

- Dovrà essere configurata una rete di management di tipo Out Of Band (OOB) con VRF forwarding.

- Dovranno essere importate le configurazioni dell’attuale rete 3-tier esistente, in particolare:

o VLAN e Interface VLAN (IPv4 eIPv6).

o Routing statico per la rete interna da integrare nel routing dinamico OSPFv3 da implementare.

o Access-list esistenti (IPv4 eIPv6).

o DHCP Relay (IPv4 e IPv6)

o Logging e SNMP.

o Routing BGP tra i WAN ROUTER del CNR-IMAA e la rete GARR.

o VRRP tra i WAN ROUTER e il Router Cisco 2851 relativo al circuito di backup MPLS.

o Un sistema per salvare in remoto la configurazione degli apparati a seguito di modifiche e/o dopo un certo periodo di tempo.

3.2.5 – Formazione:

L’aggiudicatario dovrà garantire un programma di addestramento all’uso ed alla manutenzione ordinaria della strumentazione e dei relativi software di gestione, per il personale del CNR-IMAA, di durata minima effettiva di almeno 30 (trenta) ore per un’erogazione giornaliera non superiore alle sei ore complessive in non meno di 6 (sei) giornate lavorative. La formazione, erogata da un tecnico specializzato, dovrà essere svolta on-site presso la sede di consegna ed installazione secondo un calendario preventivamente approvato dal DEC. Il programma di addestramento dovrà essere avviato entro 10 (dieci) giorni solari dalla verifica di conformità superata con esito positivo, salvo diverso accordo con il DEC. Il corso e la documentazione di addestramento dovranno essere in lingua italiana e/o inglese.

3.2.6 – Assistenza tecnica e manutenzione:

Tale requisito non è da considerarsi essenziale per le sole componenti per cui non è previsto il vincolo dell’unicità del produttore.

Viene richiesto, un servizio di assistenza e manutenzione di tipo Next Business Day 8x5, con i seguenti requisiti minimi:

- Accesso diretto alla TAC (Technical Assistance Center) del costruttore/produttore della soluzione proposta da parte del personale del CNR-IMAA.

- Call-center e portale web del costruttore/produttore della soluzione proposta accessibile in modalità 24x7x365 per l’apertura delle chiamate di assistenza da parte del personale del CNR- IMAA.

- Return Merchandise Authorization (RMA) level di tipo Next Business Day (NBD).

- Disponibilità degli aggiornamenti, upgrade e bug fix software.

3.2.7 – Il produttore degli apparati dovrà garantire la disponibilità delle parti di ricambio almeno per 60 (sessanta) mesi.

3.2.8 – Garanzia:

La garanzia fornita, inclusiva di quanto riportato alla sezione 3.2.6, dovrà coprire un periodo minimo di 36 mesi (trentasei) mesi dalla data di verifica di conformità della strumentazione superata con esito positivo. Rimane salva l’offerta migliorativa presentata dal concorrente in sede di gara. Tale garanzia deve comprendere le riparazioni o sostituzioni di parti (con esclusione delle parti c.d. “consumabili” chiaramente individuabili nella documentazione a corredo) necessarie al funzionamento ottimale della strumentazione. Xxxxxx ritenersi, inoltre, compresi nella garanzia le spese di trasferta ed i costi della manodopera dei tecnici presso la sede di consegna ed installazione. Per l’intero periodo di vigenza della garanzia, dovranno essere forniti gli eventuali upgrade alle licenze software necessarie al funzionamento delle apparecchiature.

3.2.9 – Verifica di conformità/Collaudo:

L’aggiudicatario sarà poi tenuto a provvedere, a propria cura e spese, di concerto con il DEC, alla verifica di conformità tecnica, che dovrà essere effettuata entro 30 (trenta) giorni naturali e consecutivi dall’installazione.

Le attività di verifica riguarderanno:

- La presenza di tutti gli articoli oggetto della fornitura;

- La rispondenza delle caratteristiche tecniche dei prodotti consegnati, rispetto all’offerta tecnica presentata;

- La verifica del rispetto delle richieste di installazione, messa in esercizio, configurazione e formazione come dai punti 3.2.2, 3.2.3, 3.2.4 e 3.2.5 del presente capitolato.

- La verifica dell’assistenza tecnica e manutenzione e della garanzia offerta, come dai punti 3.2.6,

3.2.7 e 3.2.8 del presente capitolato.

Nell’ipotesi in cui la verifica di conformità/Xxxxxxxx non dovesse essere superata con esito positivo, l’aggiudicatario avrà 30 (trenta) giorni di tempo, non derogabili, per porre in essere tutte le azioni utili al superamento della verifica di conformità/collaudo con esito positivo.

3.2.10 – Spese:

L’offerta presentata in sede di gara dall’aggiudicatario deve comprendere tutte le spese relative al trasporto, all’installazione, alla configurazione e alle procedure di verifica di conformità ed al programma di addestramento del personale della stazione appaltante.

3.3 - LOTTO 3 – Fornitura, installazione e configurazione di DC Calculus Storage

L’aggiudicatario si obbliga a fornire:

3.3.1 - Descrizione del progetto:

Il CED del CNR-IMAA eroga i propri servizi H24/7 mediante infrastrutture di virtualizzazione in alta affidabilità dislocate presso la sede di Xxxx Xxxxx (PZ). Tali infrastrutture sono costituite essenzialmente da sistemi di file storage FC e NAS Scale-Out completamente ridondati e da un insieme di hypervisor virtuali, basate su VMWARE vSphere (tali licenze sono già in possesso del CNR e non andranno fornite), anch'essi ridondati in tutte le loro parti, connessi fra di loro e verso il mondo esterno mediante infrastrutture di rete replicate.

L’infrastruttura oggetto del presente lotto prevede la realizzazione di un sistema di calcolo e storage, da posizionare all’interno dei locali del CED del CNR-IMAA. L’intera infrastruttura dovrà essere collocata

all’interno di due RACK 42U distinti in modo da permettere un deployment mode di tipo stretched cluster. All’interno di ciascuno dei due Rack dovranno essere alloggiati sia un dispositivo di storage a blocchi (ad esclusione dello storage di tipo NAS Scale-Out) sia la parte inerente al sistema di calcolo. In caso di malfunzionamento di uno dei due RACK, ciascuno auto consistente (al netto dello storage di tipo NAS Scale-Out), l’infrastruttura dovrà poter comunque continuare a garantire l'erogazione di tutti i suoi servizi. Tale configurazione dovrà permettere in futuro lo spostamento di uno dei due rack in un eventuale CED secondario.

Nell'ottica di eliminare i "single point of failure", si dovrà prevede la futura possibilità di poter dislocare in due sedi distinti due sistemi di storage a blocchi identici, in grado di mantenere in replica sincrona e federata ed un set di LUN decise dagli amministratori di sistema. Ogni sede ospiterà un insieme di hypervisor gestiti mediante VMWare vSphere (tali licenze sono già in possesso del CNR e non andranno fornite) che verranno configurati come una singola infrastruttura di virtualizzazione (stretched cluster), in modo da consentire sia il bilanciamento che la migrazione on-line a caldo tra le due sedi con le stesse modalità di una singola infrastruttura/cluster di virtualizzazione.

I sistemi di storage richiesti dovranno essere in grado di consentire l'utilizzo locale delle LUN (una VM in esecuzione in una sede deve poter utilizzare in maniera preferenziale il sistema di storage collocato nella stessa sede), in modo da ottimizzare le performance.

I sistemi di storage dovranno fornire un livello di affidabilità molto elevato (certificati per availability

>= 99,999%) mediante meccanismi in grado di assicurare la persistenza dei dati su disco (sistemi RAID o equivalenti) e attraverso la duplicazione di tutte le parti funzionali degli apparati (alimentatori, controller, connessioni verso gli HD, etc.).

I sistemi di storage dovranno inoltre essere in grado di gestire la replica sincrona geografica dei dati, compresa la gestione di tutte le anomalie che si possano presentare a causa di eventuali malfunzionamenti della rete (e.g. split-brain). In condizioni di questo tipo, la soluzione tecnologica dovrà consentire l’automatica risoluzione dell’impasse attraverso lo spostamento dell'accesso R/W dei dati sul sito superstite (quello che mantiene la connettività necessaria all'erogazione dei servizi) e ponendo "offline" l'altro sistema di storage. Questo al fine di consentire allo stretched cluster di dichiarare non operativi gli Hypervisor del rack in fault e di migrare conseguentemente ed in modalità "unattended" tutti i servizi nel sito che non sia interessato da malfunzionamenti.

Contestualmente all’acquisizione del nuovo sistema di calcolo e storage, la stazione appaltante intende dotarsi anche di un sistema NAS con funzioni di Data Lake, principalmente per effettuare un ulteriore backup di dati scientifici e/o degli utenti. In considerazione delle esigenze di crescita previste ed in preparazione all’esecuzione di attività di data analysis 24/7 near real time, si ritiene indispensabile dotarsi di un sistema in architettura NAS Scale-Out in grado di poter scalare secondo le necessità, in maniera lineare sia in termini capacitivi che prestazionali al crescere delle esigenze.

I sistemi di calcolo, storage/sincronizzazione e NAS oggetto del presente lotto costituiranno il cuore dell'infrastruttura di calcolo e storage di tutto il CNR-IMAA e pertanto costituiscono un'attività “mission critical” per l'Ente.

Si richiede quindi che il produttore degli apparati sia in grado di fornire supporto "mission critical", attraverso almeno un call center e un portale web sempre raggiungibile - eventualmente dirottando le chiamate in altri Stati in funzione di orari e festività - in grado di gestire la prima fase di troubleshooting di concerto con il personale dell’CNR-IMAA, e quindi di inviare eventuali parti di ricambio presso le sedi di fornitura o se necessario un tecnico on-site entro il giorno lavorativo successivo.

3.3.2 – Installazione:

La strumentazione dovrà essere installata come meglio specificato nel paragrafo “Termini e luogo di consegna e installazione”. L’aggiudicatario dovrà provvedere all’installazione delle apparecchiature all’interno del locale CED secondo lo schema di progetto allegato (All. lotto3_schema_progetto.pdf) a sue spese provvedendo al trasporto, montaggio e messa in funzione delle apparecchiature.

L’aggiudicatario deve garantire la consegna della strumentazione esente da difetti e perfettamente funzionante.

3.3.3 – Messa in esercizio:

L’aggiudicatario dovrà presentare un progetto per l'installazione, configurazione e messa in esercizio del nuovo sistema, tenendo presente che detti lavori dovranno essere realizzati nel normale orario di lavoro del CNR-IMAA (9,00-17,30 dal lunedì al venerdì), concordando preventivamente tutte le operazioni che comportino assenze di connettività.

Entro 10 giorni successivi all’aggiudicazione definitiva, la società aggiudicataria dovrà concordare con la stazione appaltante un piano operativo che, sulla base del progetto presentato vada a dettagliare tutte le attività da effettuare, prevedendo almeno le seguenti fasi:

La soluzione proposta per la migrazione dovrà prevedere una fase iniziale di coesistenza dei due ambienti.

2. Messa a disposizione di un laboratorio di test anche virtuale e remoto, dove simulare l’infrastruttura da realizzare e le relative configurazioni da implementare.

Tutti gli oneri relative a questo punto (comprese eventuali trasferte del personale del CNR- IMAA) si intendono a carico dell’operatore economico.

3. Installazione e validazione dei sistemi offerti nei rack, loro cablatura ed interconnessione alla rete elettrica e alla rete dati. Quest'ultima attività dovrà essere eseguita secondo uno schema concordato con il personale individuato del CNR-IMAA prima della consegna del materiale.

4. Pre-configurazione dei Nodi di Calcolo, dei Sottosistemi Storage e del Sistema NAS secondo le modalità concordate col personale preposto dell’Ente.

5. Implementazione dello stretched cluster e di tutte le funzionalità richieste ed oggetto di fornitura.

6. Integrazione della nuova infrastruttura affiancandola a quella esistente, al fine di agevolare il processo di migrazione.

7. Messa in funzione della nuova infrastruttura, dismettendo la vecchia.

8. Verifiche funzionali, tuning dei Sistemi compreso delle attività propedeutiche al collaudo della fornitura.

9. Attività di Formazione on-site del personale del CNR-IMAA.

10. Collaudo dell’infrastruttura.

I punti 4,5,6,7 dovranno essere obbligatoriamente realizzati da personale tecnico specializzato e certificato sui sistemi componenti l'infrastruttura. Il personale tecnico dovrà essere iscritto regolarmente a libro matricola della società produttrice/commercializzatrice dei sistemi offerti. Sarà cura della stazione appaltante verificare che il personale impiegato sia rispondente ai requisiti precedentemente riportati.

Il completamento di ciascuna delle fasi indicate dovrà essere formalizzato con un apposito verbale di regolare esecuzione che dovrà essere approvato dal DEC all’uopo nominato.

Inoltre, relativamente alla fornitura dovranno essere rilasciati:

- I manuali (installation guide, hardware technical reference, operation's guide, ecc..), in lingua italiana o inglese, su supporto cartaceo e/o ottico;

- I dati impiantistici complessivi, in termini di assorbimento elettrico e di dissipazione termica, della fornitura preferibilmente con congruo anticipo rispetto alla data di inizio delle attività di installazione.

3.3.4 – Configurazione tecnica:

La soluzione proposta per la realizzazione dell’infrastruttura di calcolo e storage dovrà tenere conto dei seguenti requisiti tecnici minimi:

- Realizzazione di uno Stretched Cluster Sincrono basato su blade server e storage all-flash. Lo streched cluster riguarderà sia la componente di rete integrata negli chassis (tramite MLAG/MC-LAG) del blade server, sia le LUN esposte dallo storage all-flash. Il cluster andrà interfacciato con gli switch Top of the Rack del CNR-IMAA con dei LAG LACP da 2x100GbE per ogni singolo modulo di connettività. LAG LACP dovranno essere configurati anche verso i vSphere Distributed Switch di VMWare.

- I moduli di connettività integrati negli chassis del blade server dovranno essere configurati in MLAG/MC-LAG (no STACK) in modo da funzionare come se fossero un unico apparato a livello logico;

- Per ogni lama server, dovrà essere installa, in base alle matrici di compatibilità di VMWare l’ultima versione disponibile di VMWare vSphere Hypervisor; inoltre dovrà essere effettuata la configurazione di vSphere (utenti, indirizzamento di management etc.) secondo le indicazioni del personale tecnico del CNR-IMAA.

- Configurazione degli switch Fiber Channel presenti negli chassis (ISL trunking) in modo da creare due fabric distinte per le componenti di storage Fiber Channel. È richiesto che ciascuno degli storage FC esponga una LUN virtuale sincronizzata. I due storage dovranno essere collegati all’infrastruttura di virtualizzazione VMWare, in modo tale da garantire le funzionalità dettate dallo stretched cluster.

- Lo storage all-flash dovrà esporre volumi mappati contemporaneamente da due array, consentendo l’accesso continuo ai volumi in alta affidabilità ossia garantendo la Business Continuity, in caso di fault di uno dei due Array.

- Dovranno essere previste e fornite tutte le componenti necessarie (eccezion fatta degli eventuali Transceiver ottici) per una futura installazione remota di uno dei due rack che compongono lo stretched cluster.

3.3.5 – Formazione:

L’aggiudicatario dovrà fornire al personale del CNR-IMAA un programma di addestramento all’uso ed alla manutenzione ordinaria della strumentazione e dei relativi software di gestione di durata minima effettiva di almeno 15 (quindici) ore divise in non meno di 3 (tre) giornate lavorative. La formazione, erogata da un tecnico specializzato, dovrà essere svolta, on-site presso la sede di consegna ed installazione, secondo un calendario preventivamente approvato dal Responsabile Unico del Procedimento. Rimane salva l’offerta migliorativa presentata dal concorrente in sede di gara. Il programma di addestramento dovrà essere avviato entro 10 (dieci) giorni solari dal positivo collaudo della strumentazione, salvo diverso accordo con il DEC. Il corso e la documentazione di addestramento dovranno essere in lingua italiana e/o inglese.

3.3.6 – Assistenza tecnica e manutenzione:

Considerata la complessità della fornitura, è richiesto, per quanto possibile, che l’erogazione dei servizi di assistenza tecnica e manutenzione venga effettuata direttamente dai costruttori/produttori delle componenti hardware e software oggetto della fornitura. Il personale tecnico dell’CNR-IMAA dovrà in ogni caso poter interagire direttamente con i costruttori/produttori senza intermediazione del fornitore. Pertanto, il concorrente dovrà offrire il servizio di manutenzione ufficiale del produttore degli apparati, agendo in tal senso esclusivamente in regime di rivenditore.

Tale requisito non è da considerarsi essenziale per le sole componenti per cui non è previsto il vincolo dell’unicità del produttore.

Viene richiesto, un servizio di assistenza e manutenzione di tipo Next Business Day 8x5, con i seguenti requisiti minimi:

- Accesso diretto alla TAC (Technical Assistance Center) da parte del personale del CNR-IMAA;

- Call-center e portale web accessibile 24x7x365 per l’apertura delle chiamate di assistenza. All'atto dell'apertura del Trouble Ticket l’assistente tecnico del Call Center del Produttore dovrà emettere un numero di identificazione univoco per ciascun ticket;

- Return Merchandise Authorization (RMA) level di tipo NBD;

- Servizio di manutenzione on-site, tramite l’invio di un tecnico specializzato del costruttore/produttore degli apparati offerti. L’intervento on site per la sostituzione delle eventuali parti guaste dovrà avvenire entro il giorno lavorativo successivo all’apertura del ticket.

3.3.7 – Il produttore degli apparati dovrà garantire la disponibilità delle parti di ricambio almeno per 60 (sessanta) mesi.

3.3.8 – Garanzia:

La garanzia fornita, inclusiva di quanto riportato alla sezione 3.3.6, dovrà coprire un periodo di 36 mesi (trentasei) mesi dalla data di verifica di conformità della strumentazione superata con esito positivo. Rimane salva l’offerta migliorativa presentata dal concorrente in sede di gara. Tale garanzia deve comprendere le riparazioni o sostituzioni di parti (con esclusione delle parti c.d. “consumabili” chiaramente individuabili nella documentazione a corredo) necessarie al funzionamento ottimale della strumentazione. Xxxxxx ritenersi, inoltre, comprese nella garanzia le spese di trasferta ed i costi della manodopera dei tecnici presso la sede di consegna ed installazione. Per l’intero periodo di vigenza della garanzia, l’aggiudicatario si impegna a fornire gratuitamente gli eventuali upgrade alle licenze software necessarie al funzionamento delle apparecchiature.

3.3.9 – Verifica di conformità/Collaudo:

L’aggiudicatario sarà tenuto a provvedere, a propria cura e spese, di concerto con il DEC, alla verifica di conformità tecnica.

Le attività di verifica riguarderanno:

- La presenza di tutti gli articoli oggetto della fornitura;

- La rispondenza delle caratteristiche tecniche dei prodotti consegnati, rispetto all’offerta tecnica presentata;

- Il rispetto delle richieste di installazione, messa in esercizio, configurazione e formazione come dai punti 3.3.2, 3.3.3, 3.3.4 e 3.3.5 del presente capitolato.

- L’assistenza tecnica e manutenzione e la garanzia offerta, come dai punti 3.3.6, 3.3.7 e 3.3.8 del presente capitolato.

In sede di verifica di conformità si procederà a verificare che gli eventuali cavi DAC, AOC e patch cord utilizzati per effettuare i collegamenti siano delle lunghezze corrette in modo da evitare eccessi di cablaggi all’interno degli armadi rack. Il non rispetto di tale requisito potrà compromettere il positivo esito della verifica di conformità.

Nell’ipotesi in cui la verifica di conformità/Xxxxxxxx non dovesse essere superata con esito positivo, l’aggiudicatario avrà 30 (trenta) giorni di tempo, non derogabili, per porre in essere tutte le azioni utili al superamento della verifica di conformità/collaudo con esito positivo.

3.3.10 – Spese:

4 – LOTTO 1 – Border Firewall – Caratteristiche tecniche della fornitura Descrizione sintetica: Fornitura, installazione e configurazione dei Firewall del nodo PER-ACTRIS-IT del CNR-IMAA.

Tutti i sistemi offerti dovranno avere le seguenti caratteristiche, pena l'esclusione dalla gara:

 Essere dello stesso Produttore (tranne se diversamente specificato/richiesto per determinati accessori oggetto della fornitura).

 Essere nuovi di fabbrica (non sono ammessi prodotti usati e/o rigenerati).

 Provenienti dai canali ufficiali di rivendita/distribuzione del produttore e consegnati nel packaging originale (non usato e/o rigenerato).

 Essere dotato di manuali, cavi di alimentazione e di collegamento con le periferiche, driver ed ogni altro componente indispensabile per il corretto funzionamento.

Il concorrente dovrà redigere un'offerta tecnica che illustra analiticamente il progetto che intende presentare per l'intera fornitura.

All'offerta tecnica il concorrente dovrà allegare la documentazione tecnica ufficiale del costruttore/produttore degli apparati, relativa a tutte le componenti del sistema offerto. Ogni parte della documentazione dovrà essere identificata mediante una sigla univoca da riportare sui documenti. A tale scopo è stato predisposto il template “Lotto1_OffertaTecnica_Modello.docx” che il concorrente dovrà compilare e allegare in un formato non modificabile.

Da tale documentazione si dovrà facilmente evincere la corrispondenza tra quanto richiesto dai capitoli e relativi paragrafi del presente capitolato tecnico e quanto offerto. Non saranno ammesse generiche dichiarazioni di rispondenza ai requisiti del Capitolato Tecnico prive di riferimenti documentali riportati nelle modalità precedentemente indicate.

Caratteristiche minime dell’aggiornamento tecnologico oggetto della fornitura:

 N. 2 Next-Generation Firewall in configurazione H.A. Active/Active, con le seguenti caratteristiche tecniche minime, riferite al singolo apparato:

 L’appliance fornita deve essere sviluppata su hardware fisico dedicato alla soluzione (firewall hardware).

 Funzionalità integrate di controllo applicativo L7 ISO/OSI. Le policy di sicurezza da implementare dovranno essere di tipo applicativo.

 Architettura del Firewall basata sulla separazione tra Data plane dedicato al traffico e Management plane dedicato alla gestione della piattaforma.

 Firewall Throughput 17/20 Gbps (http/app)1.

 Threat Prevention Throughput 8/9 Gbps (http/app)2.

 IPsec VPN Throughput 8 Gbps.

 Funzionalità di SSL remote access VPN per almeno 500 utenti.

 Sessioni massime 4.000.000.

1 Il throughput del firewall è misurato con le funzionalità di controllo applicativo e logging abilitate (64 KB HTTP/appmix transactions)

2 Il Threat Prevention Throughput è misurato con controllo applicativo, IDS/IPS, antivirus, anti-spyware, sandbox, file blocking, e logging abilitati (64 KB HTTP/appmix transactions)

 Nuove sessioni per secondo 150.000.

 10 Virtual Systems: Funzionalità di creazione di istanze separate logicamente del firewall, con separazione del traffico tra le diverse istanze.

 Funzionalità di segmentazione della rete basata su Zone e protezione delle zone.

 Interfacce configurabili in modalità L2, L3 IPv4 e IPv6.

Le 3 modalità possono essere configurate contemporaneamente, su interfacce distinte, all'interno dello stesso contesto virtuale.

 Supporto ai protocolli di routing OSPFv2/3 (graceful restart mechanism), BGP (graceful restart mechanism), RIP e rotte statiche.

 PPPoE e DHCP.

 Multicat PIM-SM, PIM-SSM, IGMPv3.

 Bidirectional Forwarding Detection (BFD).

 IPv6 SLACC.

 4096 802.1Q VLAN tags per device/interfacce.

 Funzionalità di QoS con traffic shaping basato su policy (priority, guaranteed, maximum) per applicazioni, per utenti, per tunnel, con classificazione DSCP.

 802.3ad LACP.

 NAT (IPv4): static IP, dynamic IP, dynamic IP/port.

 NAT64, NPTv6.

 High Availability active/active e active/passive; Failure detection basata su path monitoring e interface monitoring.

 Funzionalità di DoS protection per contrastare il flooding dovuto a nuove sessioni.

 Antivirus, anti-spyware (command-and-control), and vulnerability protection.

 Funzionalità di IDS/IPS;

 Funzionalità di DoS protection per contrastare il flooding dovuto a nuove sessioni.

 Export dei flussi di dati (Netflow, Sflow e/o IPFIX).

 Disponibilità di una dashboard (Application Command Center) che mostri come sommario grafico e interattivo applicazioni, utenti, URL, minacce e contenuti che attraversano la rete.

 Funzionalità di amministrazione completa delle funzionalità del firewall, tramite una interfaccia locale (integrata nel firewall) e tramite una console di management centralizzato.

 Eventuali soluzioni/funzionalità cloud based dovranno essere qualificate da AGID per il cloud della pubblica amministrazione.

 Occupazione di spazio massimo di 2 x 3 RU 19”.

 Alimentatori ridondati.

 N. 4 100/1000/10G Cu RJ45; N. 16 1G/10G SFP/SFP+; N. 4 40G QSFP+.

 N. 2 (N. 4 in totale per la coppia di FW) transceiver ottici QSFP+ 40Gb SR4 100m OM3, 12 strand MPO.

 Servizi di aggiornamento software (inteso per tutte le funzionalità e software richiesti e forniti, soggetti a licenze) – 24 mesi.

Servizio di Manutenzione e Hardware Replacement 8x5xNBD – 24 mesi.

Eventuali altri componenti e servizi, anche se non esplicitamente menzionati ma comunque necessari per la gestione, l’integrazione e il corretto funzionamento dei sistemi forniti (ad es. cavi di collegamento, strumenti HW/SW per la configurazione, per la gestione e per il monitoraggio, firmware, ecc.) dovranno anch’essi essere compresi nella fornitura.

La fornitura, inoltre, dovrà contenere esclusivamente prodotti nuovi di fabbrica di ultima generazione presenti (sia in termini di funzionalità che di caratteristiche HW) sul listino del produttore alla data di presentazione dell’offerta.

5 – LOTTO 2 DC Network – Caratteristiche tecniche della fornitura

Descrizione sintetica: Fornitura, installazione e configurazione dell’infrastruttura DC Network del nodo PER-ACTRIS-IT del CNR-IMAA.

Tutti i sistemi offerti dovranno avere le seguenti caratteristiche, pena l'esclusione dalla gara:

 Essere dello stesso Produttore (tranne se diversamente specificato/richiesto per determinati accessori oggetto della fornitura).

 Essere nuovi di fabbrica (non sono ammessi prodotti usati e/o rigenerati).

 Provenienti dai canali ufficiali di rivendita/distribuzione del produttore e consegnati nel packaging originale (non usato e/o rigenerato).

 Essere dotato di manuali, cavi di alimentazione e di collegamento con le periferiche, driver ed ogni altro componente indispensabile per il corretto funzionamento.

Il concorrente dovrà redigere un'offerta tecnica che illustra analiticamente il progetto che si intende presentare per l'intera fornitura.

All'offerta tecnica il concorrente dovrà allegare la documentazione tecnica ufficiale del costruttore/produttore degli apparati, relativa a tutte le componenti del sistema offerto. Ogni parte della documentazione dovrà essere identificata mediante una sigla univoca da riportare sui documenti. A tale scopo è stato predisposto il template “Lotto2_OffertaTecnica_Modello.docx” che il concorrente dovrà compilare e allegare in un formato non modificabile.

Da tale documentazione si dovrà facilmente evincere la corrispondenza tra quanto richiesto dai capitoli e relativi paragrafi del presente capitolato tecnico e quanto offerto. Non saranno ammesse generiche dichiarazioni di rispondenza ai requisiti del C.T. prive di riferimenti documentali riportati nelle modalità precedentemente indicate.

5.1 - Oggetto della fornitura:

 SPINE: n. 2 apparati, come meglio specificato al par. 5.4.

 COMPUTE LEAF Switch: n. 10 apparati, come meglio specificato al par. 5.5.

 CAMPUS LEAF: n. 2 apparati, come meglio specificato al par. 5.6.

 CAMPUS ACCESS: n. 2 apparati, come meglio specificato al par. 5.5.

 SERVICES LEAF: n. 2 apparati, come meglio specificato al par. 5.8.

 WAN ROUTER: n. 2 apparati, come meglio specificato al par. 5.9.

 Cavi AOC per interconnessione di LEAF e SPINE, come meglio specificato al par. 5.10.

 Cavi DAC e patch cord in fibra ottica per interconnessione con firewall, come meglio specificato al par. 5.11.

 Transceiver ottici, come meglio specificato al par. 5.12.

 Accessori per migrazione server HP esistenti, come meglio specificato al par. 5.13.

 Piattaforma di management centralizzato, come meglio specificato al par. 5.14.

La fornitura, inoltre, dovrà contenere esclusivamente prodotti nuovi di fabbrica di recente generazione presenti (sia in termini di funzionalità che di caratteristiche HW) sul listino del produttore alla data di presentazione dell’offerta.

5.2 Caratteristiche della fornitura - Requisiti minimi generali per tutti i prodotti:

5.2.1 Indicazioni generali:

I seguenti punti costituiscono i requisiti minimi e sono quindi vincolanti per la fornitura.

Per ogni punto dovranno essere fornite le specifiche e i dettagli a dimostrazione della conformità alle richieste. La valutazione sarà effettuata sulla documentazione fornita e la mancanza anche di un solo requisito minimo comporterà l’esclusione dalla gara.

È importante sottolineare che, oltre ai requisiti minimi generali di seguito indicati, i requisiti minimi specifici per i singoli apparati, di cui alla fornitura oggetto del bando, sono descritti nei relativi capitoli.

5.2.2 Unico produttore:

Al fine di garantire un elevato livello di integrazione tra le componenti ed una efficacia del supporto nel suo insieme, gli apparati oggetto della fornitura compresa la piattaforma di management centralizzato, devono essere realizzati/commercializzati tutti dallo stesso produttore. Tutte le parti hardware e software della fornitura devono essere ufficialmente commercializzate, comparire nel listino del produttore, essere in regolare produzione senza che per gli stessi sia stato annunciato il termine della manutenzione o del supporto specialistico.

Fanno eccezioni le componenti non presenti nel listino del produttore, come ad esempio eventuali patch cord in fibra ottica o rame o transceiver ottici espressamente richiesti per l’integrazione con prodotti già esistenti presso il CED del CNR-IMAA.

5.2.3 Omogeneità apparati hardware:

Gli apparati di tipologia LEAF e SPINE, ad esclusione dei WAN ROUTER e CAMPUS ACCESS, all’interno del portafoglio del produttore, devono appartenere alla stessa linea/serie di prodotti.

5.2.4 Vincoli progettuali:

Tutti gli apparati devono soddisfare i seguenti requisiti necessari ad ottemperare le richieste prestazionali e di alta disponibilità. Per completezza si riportano le definizioni dei concetti e dei termini utilizzati:

Piano di controllo (Control plane) - L’insieme delle funzioni preposte alla definizione delle informazioni che un apparato utilizza per l’inoltro dei pacchetti di dati. È rappresentato dalle istanze dei protocolli di routing con la struttura dati derivante: Routing Information Base (RIB);

Piano di inoltro (Forwarding/data plane) - L’insieme delle funzioni e delle informazioni, derivate dal piano di controllo, atte all’inoltro dei pacchetti di dati è rappresentata dalla Forwarding Information Base (FIB) per le operazioni di routing e switching.

5.2.4.1 Separazione dei piani di controllo e di inoltro:

È richiesta la separazione dei piani di controllo e di inoltro al fine di ottimizzare le strutture dati, i processori e le componenti hardware e software nel complesso, in funzione delle prestazioni richieste (tipicamente relative a operazioni di aggiornamento e modifica, da parte del control plane, e operazioni time-critical, come “table lookup” e “multi-field classification packet processing”, da parte del forwarding plane).

Tale separazione dovrà implicare anche il disaccoppiamento fisico delle parti hardware e software preposte alle due funzioni garantendo che il malfunzionamento dell’uno non impatti sull’altro.

5.2.4.2 Piattaforma non bloccante (wire speed e non-blocking o equivalente):

È richiesto che gli apparati abbiano la capacità di operare le decisioni di filtering e forwarding del traffico in condizioni di massimo carico su tutte le porte di I/O simultaneamente e distribuire arbitrariamente la totalità delle capacità delle porte di I/O tra tutte le porte dell’apparato.

Affinché la piattaforma sia wire speed e non-blocking, le prestazioni di table lookup performance e data flow capacity devono essere entrambe rispettate in assenza di perdita di pacchetti.

5.2.5 Multi Chassis Link Aggregation (MLAG o MC-LAG):

È richiesto che l’architettura proposta sia tale per cui gli apparati possano agire come un unico dispositivo logico e con Data Plane, Control Plane e i File di Configurazione separati e indipendenti.

La soluzione tecnologica proposta dovrà essere implementata da un’architettura Datacenter basata su un unico livello topologico e quindi su un unico apparato a livello logico, atta ad ottimizzare l’inoltro del traffico tra le diverse utenze afferenti. Tale architettura, inoltre, dovrà consentire l’esclusione dell’utilizzo di protocolli che inibiscano l’occupazione di tutta la banda disponibile, quali per esempio lo Spanning Tree.

Suddetta architettura sarà denominata, d’ora in avanti, di tipo MLAG. MLAG e MC-LAG sono termini equivalenti che rappresentano lo stesso sistema secondo lo standard definito. Non saranno accettati sistemi di LAG che utilizzano protocolli proprietari e non standard.

5.2.6 Line rate packet forwarding:

L’esecuzione dei compiti di packet forwarding all’interno di un apparato, che lavora a line rate, implica che tale operazione sia implementata con dei network processor ottimizzati per tali funzioni e dotati di hardware dedicato (dotazione interna al processore in termini di componenti hardware per task specifici ASIC, CAM, TCAM...) alle operazioni di table lookup, pattern matching e header rewriting.

La latenza introdotta dalla catena di processing dei pacchetti deve essere quindi trascurabile, nei limiti dello stato dell’arte dei sistemi per il packet forwarding di categoria datacenter attuali, rispetto alla latenza teorica dell’apparato al layer OSI sul quale esso opera.

5.2.7 Line rate packet processing:

Le attività di packet classification, filtering e policing in ambiente misto IPv4 ed IPv6, configurate in aggiunta alle operazioni di inoltro di protocolli standard, non devono introdurre latenze che impattino sul Throughput dichiarato dell’apparato e delle sue interfacce di rete.

5.2.8 Funzionalità di MLAG:

Non sono accettati come meccanismi di ridondanza hardware quelli basati su ridondanza a livello 3 e che garantiscono la disponibilità delle capacità di forwarding dei pacchetti all’interno dell’intero LAG mediante protocolli standard in modalità attivo/passivo o proprietari in modalità attivo/attivo.

Dovrà essere possibile la connessione verso altri switch e server attraverso LAG statici o IEEE 802.3ax Link Aggregation Control Protocol (LACP) senza l’utilizzo di protocolli proprietari.

È richiesto che l’architettura interconnetta in MLAG (per coppie di apparati) gli apparati appartenenti alla tipologia LEAF, SPINE e WAN ROUTER attraverso almeno n. 2 porte per singolo apparato alla velocità di almeno 100GbE cadauna (in grado di supportare connettività in fibra ottica QSFP, AOC o DAC) dedicate alla configurazione dell’MLAG mediante interconnessioni locali.

Si richiede che il forwarding dei pacchetti tra apparati connessi in LACP agli switch in MLAG sia nativamente ottimizzato preferendo sempre le interconnessioni locali ad uno switch, evitando di utilizzare le connessioni presenti sull’altro switch del dominio MLAG e non andando ad occupare banda sull’inter-link tra gli switch.

Fanno eccezione gli apparati di tipologia CAMPUS ACCESS per i quali è richiesto che l’architettura interconnetta in MLAG, STACK o altro protocollo proprietario, la coppia di apparati.

5.2.9 Integrazione con VMWare:

La soluzione di rete deve essere indipendente dal controller e deve poter supportare controller SDN di terze parti, come: VMWare NSX, Openstack e qualsiasi controller che supporta OVSDB o altri standard e gateway Hardware L2.

Deve supportare inoltre l’integrazione con la piattaforma VMWare NSX Hardware VTEP.

5.3 Sistema Operativo e Strumenti di Monitoraggio:

5.3.1 Architettura e caratteristiche Sistema Operativo:

È richiesto che il sistema operativo degli apparati proposti abbia le seguenti proprietà:

- Sistema operativo di rete ad architettura multi processo, in grado di separare le informazioni dai processi stessi.

- È richiesta un’architettura multi processo che permette di beneficiare di caratteristiche di elevata disponibilità, ridotte finestre di manutenzione, di miglioramento nella gestione e un più alto livello nella gestione della sicurezza del sistema operativo.

- I dispositivi devono supportare nel sistema operativo nativamente la telemetria in tempo reale, senza la necessità di licenze aggiuntive.

- Deve essere consentita l’integrazione della telemetria con piattaforme OpenSource di monitoring come per esempio Prometheus, Elastic Stack e Graphana).

- Deve esistere la possibilità di testare architetture di rete congruenti a quelle in produzione attraverso l’utilizzo di apparati in ambienti virtuali (VMWare) e containerizzati che abbiano la stessa versione software di produzione.

5.3.2 Amministrazione Sistema Operativo e configurazioni:

È richiesto che il sistema operativo sia dotato delle seguenti funzionalità per l’amministrazione del sistema operativo, degli utenti e delle relative policy di sicurezza:

Interfaccia utente (shell) con comandi per system administration, file manipulation, system monitoring e troubleshooting;

Client: Telnet e SSHv2;

AAA Radius e TACACS+ con fallback su database utenti locale al nodo; Definizione di profili;

Gestione di utenti e gruppi;

Registrazione (logging) di tutte le informazioni rilevanti circa le possibili anomalie;

Supporto di un meccanismo per filtrare e limitare il traffico destinato al “Piano di Controllo” dell’apparato.

È richiesto che il sistema operativo sia dotato delle seguenti funzionalità per l’amministrazione delle configurazioni:

Interfaccia utente (shell) con ambiente separato per la modifica delle configurazioni (e.g. configuration mode);

Log con inoltro del flusso dati su un server remoto tramite protocollo Syslog ed accessibile anche localmente tramite la shell utente (CLI - Command Line Interface);

Linguaggio di scripting: con possibilità di sviluppo di script locali sul nodo per la personalizzazione di comandi, per la schedulazione automatica di modifiche di elementi di configurazione.

5.3.3 Alta affidabilità:

I dispositivi offerti devono essere predisposti alla modalità MLAG ed implementare le funzioni centralizzate di Route Processor e Control Board su due apparati fisicamente distinti e in configurazione ad alta disponibilità.

Disponibilità di un processo di aggiornamento unificato per gli apparati dell’MLAG che non causi la perdita di connettività contemporaneo degli apparati che compongono il LAG stesso ma il riavvio selettivo e sequenziale di ogni singola unità. Tale processo deve garantire la continuità del Piano di Controllo attraverso meccanismi in grado di preservare le informazioni e gli stati generati dai protocolli di routing e dal kernel;

Possibilità di riavviare i singoli processi in “runtime” (Process Restart);

Supporto di un meccanismo di gestione dell’MLAG che eviti, in caso di guasti, la generazione di uno split del LAG stesso;

L’interfaccia appartenente ad un LAG, condiviso tra una unità che sta effettuando il reboot ed una unità attiva, deve mantenere attivo il processo di forwarding;

La procedura di aggiornamento dei dispositivi che compongono il LAG deve permettere la convivenza momentanea di unità con release di sistema operativo diverse, senza alcuna interruzione del processo di forwarding dei pacchetti sulle unità che non sono coinvolte nella procedura di reboot.

5.3.4 Monitoraggio, amministrazione e gestione (OA&M):

È richiesto che il sistema operativo sia dotato delle seguenti funzionalità:

- Comandi ICMP: ping, traceroute;

- Supporto SNMPv2 e v3, SNMP Trap e SNMP Inform. In particolare, è richiesto il supporto delle “Management Information Base” (MIB) previste dagli standard IETF e IEEE e delle relative estensioni proprietarie;

- Debugging: il livello di dettaglio delle attività di debug deve poter essere configurabile così come il suo output (file, CLI...) e il livello di debug non deve avere impatto sulle prestazioni dell’apparato.

- Gli apparati di rete devono tracciare in tempo reale le latenze e i fenomeni di micro-congestione che possono interessare ogni singola porta dell’apparato di rete con livelli di elevata granularità, permettendo alle applicazioni di reagire rapidamente ad ogni cambio delle condizioni di rete prima che avvengano perdite di pacchetti.

5.3.4.1 Traffic Mirroring e Sampling:

È richiesto che il sistema operativo supporti le funzionalità di mirroring del traffico e dei protocolli della famiglia sFlow o equivalenti.

5.3.4.2 Strumenti di OA&M:

Gli apparati devono supportare il protocollo “Bidirectional Forwarding Detection” (BFD) almeno per i protocolli OSPF, BGP, IS-IS.

5.4 SPINE:

Dovranno essere forniti n. 2 SPINE, identici in tutte le loro componenti.

Di seguito sono riportate le caratteristiche tecnico/funzionali minime di ogni singolo apparato oggetto della soluzione. Saranno escluse dalla procedura di gara le soluzioni che non rispettino una o più caratteristiche tecnico/funzionali richieste:

- Massima occupazione di spazio: 1 RU;

- Porte: n.32x100G QSFP28 (operanti a 100GbE, 40GbE);

- L2/L3 Throughput: 6.4Tbps o superiore;

- L2/L2 PPS: 2Bpps;

- Latenza: non superiore a 1000ns;

- Packet Buffer totale: 16MB (Allocazione dinamica del buffer con buffer completamente condiviso tra tutte le porte per il processing dei pacchetti dati);

- 1+1 hot-swappable power supplies;

- N+1 hot-swap fans;

- Zero Touch Provisioning (ZTP) Deployment;

- Supporto delle seguenti funzionalità: VXLAN, EVPN (Symmetric/Asymmetric IRB, L2- EVPN, L3-EVPN), ECMP, OSPF(v3), BGP, MP-BGP, VRF, VRRP, LACP, SDN, Multi Chassis Link Aggregation, QoS, IEEE 1588 PTP (Transparent Clock and Boundary Clock).

5.5 COMPUTE LEAF:

Dovranno essere forniti n. 10 COMPUTE LEAF, identici in tutte le loro componenti.

- Massima occupazione di spazio: 2 RU.

- Porte: n.48x25GbE SFP28 (dovrà essere possibile l’utilizzo diretto dei transceiver SFP operanti a 25/10/1GbE senza l’ausilio di cavi breakout), n.8x100G QSFP28 (operanti a 100GbE, 40GbE).

- L2/L3 Throughput: 2Tbps o superiore.

- L2/L2 PPS: 1Bpps.

- Latenza: non superiore a 1000ns.

- Packet Buffer totale: 32MB (Allocazione dinamica del buffer con buffer completamente condiviso tra tutte le porte per il processing dei pacchetti dati).

- 1+1 hot-swappable power supplies.

- N+1 hot-swap fans.

- Zero Touch Provisioning (ZTP) Deployment.

Per la configurazione in modalità MLAG (o protocolli simili) degli apparati, dovranno essere utilizzati cavi DAC, AOC o transceiver ottici comprensivi di patch di dimensioni non superiori a 0,5 metri e dello stesso brand degli apparati forniti. I COMPUTE LEAF dovranno essere connessi in MLAG attraverso due link a 2x100GbE (200GbE totali) a coppie di apparati.

5.6 CAMPUS LEAF:

Dovranno essere forniti n. 2 CAMPUS LEAF, identici in tutte le loro componenti.

- Massima occupazione di spazio: 2 RU;

- Porte: n.48x25GbE SFP28 (dovrà essere possibile l’utilizzo diretto dei transceiver SFP operanti a 25/10/1GbE senza l’ausilio di cavi breakout), n.8x100G QSFP28 (operanti a 100GbE, 40GbE);

- L2/L3 Throughput: 2Tbps o suoperiore;

- L2/L2 PPS: 1Bpps;

- Latenza: non superiore a 1000ns;

- Packet Buffer totale: 32MB (Allocazione dinamica del buffer con buffer completamente condiviso tra tutte le porte per il processing dei pacchetti dati);

- 1+1 hot-swappable power supplies;

- N+1 hot-swap fans;

- Zero Touch Provisioning (ZTP) Deployment;

Per la configurazione in modalità MLAG (o protocolli simili) degli apparati, dovranno essere utilizzati cavi DAC, AOC o transceiver ottici comprensivi di patch di dimensioni non superiori a 0,5 metri e dello stesso brand degli apparati forniti. I CAMPUS LEAF dovranno essere connessi in MLAG attraverso due link a 2x100GbE (200GbE totali).

5.7 CAMPUS ACCESS:

Dovranno essere forniti n. 2 CAMPUSS ACCESS, identici in tutte le loro componenti.

- Massima occupazione di spazio: 1 RU;

- N. 24 Porte RJ-45 mGig: n.8x100M-2.5G UTP PoE 30W, n.4 x 100M-5G UTP PoE 60W, n.12x100M-1G UTP PoE 15W, n.2x10GbE SFP+.

- L2/L3 Throughput: 180Gbps o superiore.

- L2/L2 PPS: 150Mpps.

- Latenza: non superiore a 1200ns.

- Packet Buffer totale: 6MB (Allocazione dinamica del buffer con buffer completamente condiviso tra tutte le porte per il processing dei pacchetti dati).

- 1+1 hot-swappable power supplies.

- N+1 hot-swap fans.

- Zero Touch Provisioning (ZTP) Deployment.

- Supporto delle seguenti funzionalità: 802.3af/at 30W, LLDP Enhancements for PoE, PoE Controls, VLAN VoIP/VOICE, QoS, Named VLAN, LACP.

Per la configurazione in modalità MLAG (o protocolli simili), STACK o altri protocolli proprietari degli apparati, dovranno essere utilizzati cavi di dimensioni non superiori a 0,5 metri e dello stesso brand degli apparati forniti.

5.8 SERVICES LEAF:

Dovranno essere forniti n. 2 SERVICES LEAF, identici in tutte le loro componenti.

- Massima occupazione di spazio: 2 RU;

- Porte: n.48x25GbE SFP28 (dovrà essere possibile l’utilizzo diretto dei transceiver SFP operanti a 25/10/1GbE senza l’ausilio di cavi breakout), n.8x100G QSFP28 (operanti a 100GbE, 40GbE);

- L2/L3 Throughput: 2Tbps o superiore;

- L2/L2 PPS: 1Bpps;

- Latenza: non superiore a 1000ns;

- Packet Buffer totale: 32MB (Allocazione dinamica del buffer con buffer completamente condiviso tra tutte le porte per il processing dei pacchetti dati);

- 1+1 hot-swappable power supplies;

- N+1 hot-swap fans;

- Zero Touch Provisioning (ZTP) Deployment;

Per la configurazione in modalità MLAG (o protocolli simili) degli apparati, dovranno essere utilizzati cavi DAC, AOC o transceiver ottici comprensivi di patch di dimensioni non superiori a 0,5 metri e dello stesso brand degli apparati forniti. I SERVICE LEAF dovranno essere connessi in MLAG attraverso due link a 2x100GbE (200GbE totali).

5.9 WAN ROUTER:

Dovranno essere forniti n. 2 WAN ROUTER, identici in tutte le loro componenti.

- Massima occupazione di spazio: 8 RU;

- Porte: n.48x25GbE SFP28 (dovrà essere possibile l’utilizzo diretto dei transceiver SFP operanti a 25/10/1GbE senza l’ausilio di cavi breakout), n.6x100G QSFP28 (operanti a 100GbE, 40GbE);

- L2/L3 Throughput: 1.8Tbps o superiroe;

- Packet Buffer totale: 8GB (Allocazione dinamica del buffer con buffer completamente condiviso tra tutte le porte per il processing dei pacchetti dati);

- 1+1 hot-swappable power supplies;

- N+1 hot-swap fans;

- Zero Touch Provisioning (ZTP) Deployment;

- I WAN ROUTER oggetto della fornitura devono essere in grado di poter programmare in hardware (FIB) la Full Internet Routing Table anche in più copie, con un minimo di 1M di rotte IPv4/IPv6.

Per la configurazione in modalità MLAG (o protocolli simili) degli apparati, dovranno essere utilizzati cavi DAC, AOC o transceiver ottici comprensivi di patch di dimensioni non superiori a 0,5 metri e dello stesso brand degli apparati forniti. I WAN ROUTER dovranno essere connessi in MLAG attraverso due link a 2x100GbE (200GbE totali).

5.10 Cavi AOC per interconnessione di LEAF e SPINE:

5.10.1 Dovranno essere forniti cavi Active Optical Cable (AOC) per l’interconnessione a 100, 25, 10GbE di tutti gli apparati di networking oggetto della fornitura. Nello specifico, le tipologie e lunghezze richieste dei cavi sono:

- n. 4 100GBASE QSFP28 to QSFP28 da 1 metro.

- n. 4 100GBASE QSFP28 to QSFP28 da 3 metri.

- n. 12 100GBASE QSFP28 to QSFP28 da 5 metri.

- n. 12 100GBASE QSFP28 to QSFP28 da 7 metri.

- n. 12 100GBASE QSFP28 to QSFP28 da 10 metri.

- n. 4 100GBASE QSFP28 to QSFP28 da 15 metri.

- n. 4 25GBASE SFP28 to SFP28 da 5 metri;

- n. 4 10GBASE SFP+ to SFP+ da 7 metri.

I cavi AOC dovranno essere dello stesso brand degli apparati di networking forniti.

5.11 Cavi DAC e patch cord in fibra ottica:

5.11.1 Dovranno essere forniti i seguenti cavi Direct Attach Copper (DAC) che permettano di interconnettere all’infrastruttura di networking oggetto della fornitura, n. 2 FIREWALL già presenti nel CED del CNR-IMAA e nello specifico:

- n. 4 40GBASE QSFP+ to QSFP+ da 1 metro.

I cavi DAC dovranno essere preferibilmente dello stesso brand degli apparati di networking forniti, al fine di evitare problemi di compatibilità in caso di apertura di una chiamata di assistenza con la TAC del produttore.

5.11.2 Patch cord in fibra ottica

- n. 6 MTP to MTP 12 core QSFP+ da 1 metro.

5.12 Transceiver ottici:

5.12.1 Transceiver ottici per gli apparati di networking forniti:

- n. 4 100GBASE-SR4 QSFP28 (50µ MMF / 70m OM3, 100m OM4).

- n. 4 40GBASE-SR4 QSFP+ (50µ MMF / 100m OM3, 150m OM4).

- n. 16 25GBASE-SR SFP28 (50µ MMF / 70m OM3, 100m OM4).

- n. 96 10GBASE-SR “LITE” SFP+ (50µ MMF / 100m).

- n. 14 10GBASE-LR “LITE” SFP+ (9µ SMF / 1km).

- n. 12 1000BASE-SX SFP (50µ MMF / 550m).

- n. 60 1000BASE-T SFP (RJ-45 Copper 100m).

I transceiver ottici dovranno essere dello stesso brand degli apparati di networking forniti.

5.12.2 Transceiver ottici per la migrazione di apparati Cisco esistenti già in possesso del CNR:

- n. 2 Transceiver Ottici Cisco compatibili 1000BASE-ZX DOM.

- n. 2 Transceiver Ottici Cisco compatibili 10GBASE-SR SFP+ DOM.

- n. 4 Transceiver Ottici Cisco compatibili SFP-10G-LR DOM.

- n. 2 Transceiver Ottici Cisco compatibili 10GBASE-ZR DOM.

Tali ottiche verranno utilizzate solo nella fase di migrazione e successivamente verranno dismesse insieme agli apparati (non coperti dal supporto del produttore). Per questo motivo verranno accettate anche ottiche compatibili e non originali.

5.13 Accessori per migrazione server HP esistenti:

- n. 2 moduli HP PCI-E 10GbSFP+ dual port, comprensivi di n. 4 transceiver SFP+ 10GbE SR, da installare in n. 2 server HP ProLiant DL385 G7 con i seguenti riferimenti:

o HP ProLiant DL385 G7 A: P/N 573088-421, S/N CZ21100C90.

o HP ProLiant DL385 G7 A: P/N 573122-B21, S/N USE105N6JZ.

5.14 Piattaforma di management centralizzato:

L’intera architettura di rete deve essere orchestrata da un singolo strumento di gestione basato su WEB- GUI HTML5 che offra funzioni di provisioning tramite modelli di configurazione personalizzati, monitoring tramite dati telemetrici in tempo reale, visualizzazione topologica tramite interfaccia grafica che permetta di mostrare dati di utilizzazione di banda e Throughput, errori e pacchetti scartati delle singole interfacce di rete.

Il sistema di gestione deve permettere l’upgrade e/o il downgrade del sistema operativo, l’installazione di eventuali patch software con workflow gestito.

Il sistema di provisioning basato su template di configurazione manuali o automatizzati deve permettere la riconciliazione delle configurazioni modificate direttamente dalla CLI e non dall’orchestratore o il rollback alla configurazione originale gestita dall’orchestratore stesso.

Deve essere garantito il deploying su più nodi (almeno 3, ridondanza N+2) del sistema di gestione su una infrastruttura di virtualizzazione basata su VMware vSphere.

La piattaforma di management centralizzato deve essere prodotta/commercializzata dallo stesso brand degli apparati di networking oggetto della fornitura.

6 – LOTTO 3 DC Calculus Storage

Descrizione sintetica:

Fornitura, installazione e configurazione dell’infrastruttura DC Calculus Storage del nodo PER- ACTRIS-IT del CNR-IMAA.

Tutti i sistemi offerti dovranno avere le seguenti caratteristiche, pena l'esclusione dalla gara:

 Essere dello stesso Produttore (tranne se diversamente specificato/richiesto per determinati accessori oggetto della fornitura).

 Essere nuovi di fabbrica (non sono ammessi prodotti usati e/o rigenerati).

 Provenienti dai canali ufficiali di rivendita/distribuzione del produttore e conservato nel packaging originale.

 Essere dotati di manuali, cavi di alimentazione e di collegamento con le periferiche, driver ed ogni altro componente indispensabile per il corretto funzionamento.

 Essere prodotti e commercializzati da aziende dotate di un proprio servizio di assistenza ufficiale sul territorio italiano.

Il concorrente dovrà redigere un'offerta tecnica che illustra analiticamente il progetto che si intende presentare per l'intera fornitura.

All'offerta tecnica il concorrente dovrà allegare la documentazione tecnica ufficiale del costruttore/produttore degli apparati, relativa a tutte le componenti del sistema offerto. Ogni parte della documentazione dovrà essere identificata mediante una sigla univoca da riportare sui documenti. A tale scopo è stato predisposto il template “Lotto3_OffertaTecnica_Modello.docx” che il concorrente dovrà compilare.

6.1 - Oggetto della fornitura:

 Blade server, come meglio specificato al par. 6.3.

 Storage ALL-FLASH, come meglio specificato al par. 6.4.

 SCALE-OUT NAS, come meglio specificato al par. 6.5.

 Fornitura dei rack, PDU, modulo di monitoraggio ambientale e predisposizione dello streched cluster, come meglio specificato al par. 6.6.

 PATCH CORD in fibra ottica e rame, come meglio specificato al par. 6.7.

 Transceiver ottici per l’interconnessione di apparecchiature già esistenti, come meglio specificato al par. 6.8.

 Upgrade di licenza per switch Brocade, come meglio specificato al par. 6.9.

6.2 Caratteristiche della fornitura - Requisiti minimi generali per tutti i prodotti:

6.2.1 Indicazioni generali:

I seguenti punti costituiscono i requisiti minimi e sono quindi vincolanti per la fornitura.

6.2.2 Unico produttore:

Al fine di garantire un elevato livello di integrazione tra le componenti ed una efficacia del supporto nel suo insieme, gli apparati oggetto della fornitura (Blade server, Storage all-flash, Scale Out-NAS), devono essere realizzati/commercializzati tutti dallo stesso produttore. Tutte le parti hardware e software della fornitura devono essere ufficialmente commercializzate, comparire nel listino del produttore, essere in regolare produzione senza che per gli stessi sia stato annunciato il termine della manutenzione o del supporto specialistico alla data di chiusura dei termini indicati nel bando di gara per la presentazione dell’offerta.

Fanno eccezioni le componenti non presenti al listino del produttore, come ad esempio eventuali rack e PDU o patch cord in fibra ottica o rame espressamente richiesti per l’integrazione con prodotti già esistenti presso il CED del CNR-IMAA. Tali componenti, essendo di tipo “passivo” non comportano problemi di compatibilità rispetto all’hardware richiesto.

6.2.3 Alta affidabilità:

Al fine di assicurare l’alta affidabilità, l’architettura generale della soluzione deve prevedere la ridondanza dei servizi sui due rack/nodi che compongono lo stretched cluster, mentre non sarà richiesto un livello di alta affidabilità pari allo stretched cluster, sulla sola componente di Scale-out NAS, che rimarrà non ridondata. I servizi non devono essere impattati nel caso di guasto di un rack/nodo o di un aggiornamento dell’architettura stessa.

Devono essere supportate le seguenti funzionalità:

- Modalità operativa delle streched cluster di tipo attivo/attivo con il rispetto delle seguenti caratteristiche tecniche:

o Copia sincrona tra gli storage all-flah e capacità di accesso ai dati di ogni storage da parte dei blade server.

o Unica fabric ethernet tra I moduli di connettività ethernet degli chassis blade server.

- Failover del traffico ethernet tra i blade server senza perdita di servizio tramite protocolli di MLGA/MC-LAG.

- LACP tra le interfacce dei moduli di connettività dei blade server.

- Sincronizzazione delle configurazioni.

- Sincronizzazione delle sessioni.

- Processo di aggiornamento dello streched cluster che non causi il riavvio contemporaneo di tutte le unità del cluster stesso, ma il riavvio selettivo di ogni singolo componente.

6.3 Blade server:

Dovranno essere forniti n.2 blade server, identici in tutte le loro componenti.

Gli chassis blade server oggetto della fornitura dovranno essere basati su piattaforme altamente integrate e idonee all’ottimizzazione degli spazi, della potenza elettrica assorbita e dissipata.

Essi dovranno offrire soluzioni di salvaguardia ed ottimizzazione dei consumi energetici e dovranno permettere la condivisione di componenti quali alimentatori, ventole e moduli di connettività Ethernet. A pena di esclusione, non è ammesso proporre sistemi in formato non modulare (ad es. server interconnessi a switch esterni) o sistemi modulari la cui componente di interconnessione (ethernet o FC) sia esterna allo chassis.

Allo stesso tempo non sarà ammesso proporre sistemi modulari che al loro interno possano integrare meno di 8 lame server, rispetto alle configurazioni richieste.

Di seguito sono riportate le caratteristiche tecnico/funzionali minime dei sistemi oggetto della soluzione, riferite al singolo sistema modulare o alla singola lama server. Saranno escluse dalla procedura di gara le soluzioni che non rispettino una o più caratteristiche tecnico/funzionali richieste.

6.3.1 Massima occupazione di spazio:

12 rack unit 19” per ogni singolo chassis blade server (massimo 24RU in totale peri due chassis).

6.3.2 Management:

Dovrà essere possibile la connessione in cascata di almeno 8 chassis blade server, gestiti tramite una singola interfaccia di management.

6.3.3 Lame server e componenti supportati nello chassis:

Lo chassis dovrà supportare almeno:

- Lame 2 Socket basate su architettura di CPU Intel ed in grado di ospitare al loro interno minimo 2 HDD/SSD/NVME da 2,5”.

- Lame 4 Socket basate su architettura di CPU Intel ed in grado di ospitare al loro interno minimo 4 HDD/SSD/NVME da 2,5”.

- Il sistema deve prevedere l’alta affidabilità a livello locale, almeno per i seguenti componenti: alimentatori (in modalità N+N), ventole, Chassis Management Controller, moduli switch Ethernet e FC, dischi di sistema.

- L’alimentazione ridondata e i sistemi di ventilazione dovranno essere dimensionati per lo chassis nella sua massima espandibilità (eventuali espansioni non dovranno richiedere l’aggiunta/modifica di alimentatori e ventole).

6.3.4 Numero e caratteristiche minime dei nodi di calcolo:

Ogni chassis blade dovrà essere popolato con almeno n. 6 lame server dual-socket (massimo n. 2 CPU) e garantire una futura espandibilità di almeno ulteriori n. 2 lame per ogni singolo chassis.

Ogni singola lama server deve rispettare le seguenti caratteristiche tecniche minime:

- N.2 CPU Intel Xeon Gold 6230 (20C/40T, 2.1GHz/3,90GHz Turbo). Si necessita di CPU Intel per la compatibilità con VMware EVC con i server già in possesso dell’ente.

- 512GB RAM DDR4 (16x32GB o 8x64GB), effettivamente funzionanti a 2933MHz;

- N.2 Dischi SSD da 480GB da 1DWPD, con controller RAID 0,1,10,5,50,6,60 dotato di almeno 2 GB cache;

- 2 porte 25GbE con offload iSCSI/FCoE;

- 2 porte FC32Gb.

6.3.5 Espandibilità RAM lame server:

Ogni lama server dovrà essere dotato di almeno 8 DIMM slot liberi per futura espansione della memoria RAM.

6.3.6 Numero e caratteristiche minime dei moduli di connettività presenti in ogni singolo chassis blade. A discrezione dell’offerente sarà possibile configurare il sistema secondo i requisiti tecnici minimi richiesti al paragrafo 6.3.6.1 o al paragrafo 0.0.0.0:

6.3.6.1 N. 2 moduli di connettività ethernet, ogni singolo modulo dovrà rispettare le seguenti caratteristiche tecniche minime (come da schema lotto3_schema_progetto.pdf pag.2):

- Un minimo di porte interne, verso le lame server, equivalenti al numero massimo di lame che lo chassis può alloggiare (minimo 8 porte interne) da 25GbE ognuna.

- 4 porte esterne da 100GbE QSFP28.

- n. 2 transceiver ottici QSFP28 100GbE SR.

- Funzionalità L2, LACP, MLAG/MC-LAG.

6.3.6.2 N. 1 modulo di connettività ethernet e n. 1 modulo di aggregazione, con le seguenti caratteristiche tecniche minime intese per singolo componente (come da lotto3_schema_progetto.pdf pag.2):

- N. 1 Modulo di connettività ethernet dotato di:

o Un minimo di porte interne, verso le lame server, equivalenti al numero massimo di lame che lo chassis può alloggiare (minimo 8 porte interne) da 25GbE ognuna.

o 4 porte esterne QSFP 100GbE.

o n. 2 trasceiver ottici QSFP 100GbE SR.

o 1 porta esterna da 200GbE per uplink verso il modulo di aggregazione dell’altro chassis blade server

o Funzionalità L2, LACP, MLAG/MC-LAG.

- N. 1 Modulo di aggregazione dotato di:

o Un minimo di porte interne, verso le lame server, equivalenti al numero massimo di lame che lo chassis può alloggiare (minimo 8 porte interne) da 25GbE ognuna.

o 1 porta esterna da 200GbE per uplink verso il modulo di connettività ethernet principale dell’altro chassis blade server.

In presenza del modulo di aggregazione si deve potere permettere la creazione di una unica fabric ethernet orizzontale (MLAG/MC-LAG) tramite i due chassis blade server (no stack), con una banda totale per l’uplink MLAG di almeno 100GbE (come da lotto3_schema_progetto.pdf pag.3).

6.3.6.3 N. 2 switch Fiber Channel Brocade 32Gb (si richiedono sw Brocade per realizzare l’ISL trunking con gli switch FC Brocade 6505 già in possesso dell’ente). Ogni singolo switch FC dovrà essere dotato di:

- Un minimo di porte interne, verso le lame server, equivalenti al numero massimo di lame che lo chassis può alloggiare (minimo 8 porte interne) da 32Gb FC.

- 8 porte esterne da 32Gb FC (multi-speed 8, 16, 32Gb).

- N. 4 ottiche SR 32Gb e n. 4 ottiche SR 16Gb.

- 2 porte esterne QSFP+ cadauna in grado di splittare in 4x32GbFC.

- Licenza Enterprise performance bundle per 16 porte complessive attive.

6.4 Storage All-flash:

Dovranno essere forniti n. 2 Storage All-Flash, identici in tutte le loro componenti e configurati come descritto nel seguito.

La configurazione dovrà permettere di utilizzare gli storage nello streched cluster richiesto e dovranno essere fornite tutte le componenti necessarie al funzionamento del sistema anche se i due rack andranno installati in locali separati (ad esclusione di eventuali transceiver ottici).

Di seguito sono riportate le caratteristiche tecnico/funzionali minime dei sistemi oggetto della soluzione, riferite al singolo storage. Saranno escluse dalla procedura di gara le soluzioni che non rispettino una o più caratteristiche tecnico/funzionali richieste.

6.4.1 Massima occupazione di spazio:

4RU per ogni singola SAN.

6.4.2 Caratteristiche tecniche del sistema:

Il sistema dovrà essere dotato di:

- Doppio controller in modalità Active-Active con 32GB cache per ogni controller.

- Alimentatori e ventole ridondate e Hot-Swap.

- Espansione di Back-end 12Gb.

- N. 4 porte esterne (2 per controller) iSCSI 10GbE.

- N. 4 porte esterne (2 per controller) FC32Gb.

- N. 4 transceiver ottici FC32Gb SR.

- Uno spazio disco utile di almeno 34TB composto mediante almeno 25 dischi SSD SAS 12G, configurati con un sistema equivalente a un RAID 6 (8+2) con un ulteriore disco di SPARE. Lo spazio utile si intende quindi al netto del RAID/SPARE e anche al netto di funzionalità di deduplica e compressione.

- Minimo 2PB RAW di capacità supportata.

6.4.3 Meccanismi di protezione:

Il sistema dovrà disporre delle seguenti caratteristiche architetturali e funzionali:

- Meccanismi di protezione del dato tali da non comportare perdita di informazioni in caso di guasto di una delle unità disco componenti il gruppo di volumi protetto.

- Sistema automatico di intervento, in caso di guasto di una delle unità disco, per la ricostruzione della integrità del gruppo dei volumi mediante uno o più dischi configurati come Global Hot Spare. Al termine della ricostruzione del contenuto del disco, il sistema deve garantire le medesime caratteristiche di funzionalità e prestazione pre-esistenti.

- Architettura almeno a doppio controller. I dischi di una qualsiasi LUN devono essere raggiungibili in maniera indipendente da ciascuno dei singoli controller.

- Dispositivo “tampone” che salvaguardi l’integrità dei dati presenti nella memoria cache o relativi alle operazioni di scrittura, per i quali, il device abbia già inviato al sistema operativo l’operazione di I/O e relativo codice di corretto completamento.

6.4.4 Funzionalità di data management:

Il sistema deve essere dotato di:

- Funzionalità di thin provisioning, compressione, deduplica, snapshot, clone. Il sistema dovrà essere comprendere tutte le licenze software necessarie ad effettuare tali operazioni, valide per tutta la capacità di storage fornita.

- Per quanto riguarda il “thin provisioning” il sistema deve garantire che tutte le componenti siano gestibili senza limitazione alcuna; in particolare ogni LUN dovrà poter:

o Essere utilizzata con qualsiasi tipologia di protezione raid indipendentemente dal livello (Tier) di storage selezionato: in modo manuale dall’utente o automatico da parte del sistema;

o Modificare dinamicamente i propri livelli di protezione raid senza che vi siano interruzioni di servizio o limitazioni di questa funzionalità;

o Essere espansa a caldo e quindi senza interruzione dei servizi applicativi;

o Beneficiare di repliche (snapshot) locali senza decadimento prestazionale. Qualsiasi limitazione costituirà elemento di decadimento della compliance dichiarata (certificazione della presenza e delle validità della soluzione di Thin provisioning offerto) rendendo di fatto il sistema non conforme alle specifiche minime richieste e pertanto esclusa.

- Il sistema dovrà supportare le feature di encryption dei dati con funzionalità KMS integrata.

- Tutte le funzionalità di autotiering dovranno essere automatizzate e gestibili oltre che automaticamente, anche in modo manuale, attraverso la definizione di profili o caratteristiche delle LUN associabili ai diversi livelli (Tier) di storage presenti nel sistema. Tale funzionalità deve poter essere svolta senza alcun fermo applicativo in caso di modifica delle caratteristiche della LUN.

L’autotiering dovrà poter essere implementato anche tra supporti SSD eterogenei – ad esempio SSD SLC e SSD e MLC.

- Le repliche dovranno poter essere realizzate senza pre-allocazione di spazio e senza decadimento di prestazioni.

- Il software di sistema dovrà prevedere funzionalità di copia e mirroring a caldo delle LUN. Dovrà essere possibile svolgere repliche remote su rete FC sia in modalità asincrona sia sincrona.

6.4.5 Management e teleassistenza

Il sistema di storage dovrà essere corredato di:

- Funzionalità di management via LAN con WEB-GUI HTML5.

- Console di gestione unificata.

- Gestione centralizzata delle repliche remote.

- Gestione dei report di sistema e funzionalità di reportistica avanzate.

- Gestione e analisi delle prestazioni del sistema.

- Gestione e analisi dello spazio occupato.

- Gestione delle soglie di occupazione e utilizzo del sistema.

- Interfaccia di linea comando utilizzabile per tutti gli ambienti operativi supportati.

Inoltre, la funzione di remote management dovrà contemplare un sistema di comunicazione automatico per i guasti e relative segnalazioni di errori. Deve disporre di un meccanismo di accesso remoto, abilitabile a discrezione da parte dall’utente, che consenta l’intervento del Centro di Assistenza Remota del produttore per eventuali attività di manutenzione, analisi e controllo del sistema.

6.5 Scale-out NAS:

Il sistema Scale-Out NAS dovrà essere un’infrastruttura storage condivisa per la gestione del Data Lake, orientata alla fornitura di servizi, con un elevato grado d’indipendenza dalle infrastrutture di elaborazione dati e dalle applicazioni connesse. Il dispositivo deve essere accessibile da tutti i sistemi e deve offrire un buon compromesso tra performance e capacità di memorizzazione dati.

La soluzione NAS dovrà poter operare in piena autonomia senza la necessità di risorse esterne, eccezion fatta per i soli collegamenti di rete dati e alimentazione elettrica. Non saranno pertanto considerate accettabili soluzione basate su servizi cloud (né private cloud né public cloud o altre soluzioni ibride).

Fanno parte integrante dell’offerta, i servizi professionali, erogati e svolti direttamente dal personale specializzato del vendor produttore del sistema. Questi, dovranno comprendere: posa in opera, installazione, configurazione di base e “messa in produzione” del sistema.

6.5.1 Caratteristiche generali:

Il sistema richiesto dovrà essere preposto alla gestione dei dati non strutturati ad accesso file level mediante servizi erogati attraverso la rete ethernet su protocolli IP. La soluzione dovrà avere caratteristiche tali da essere classificabile sotto la denominazione di sistema Network Attached Storage. In tal senso, il sistema dovrà poter lavorare sfruttando tutti i protocolli principali tipici delle soluzioni NAS.

La soluzione dovrà essere priva di qualsiasi elemento che possa essere considerato un “Single Point of Failure” (SPOF) e dovrà garantire la piena operatività delle sue funzioni nei casi in cui vi sia: un minimo degrado delle sue prestazioni, guasto o parziale malfunzionamento di una delle sue componenti

Il sistema dovrà essere dotato di un completo sottosistema (hardware e software) in grado di determinare eventuali malfunzionamenti di una delle sue componenti e segnalare tale malfunzionamento in modo tale da consentire un rapido intervento in grado di diagnosticare e risolvere il problema verificatosi.

Ogni elemento guasto dovrà poter essere sostituito a caldo senza che vi sia la necessità di interrompere, anche per breve periodo, il funzionamento di altri componenti del sistema per eseguire la sostituzione necessaria.

Qualora la soluzione proposta sia costituita da un insieme di nodi indipendenti, dovrà essere possibile aggiungere un nuovo nodo al sistema in modo “non distruttivo”. L’architettura dovrà prevedere la possibilità di integrare i nuovi nodi, ridistribuendone automaticamente o mediante policy, i dati, i servizi ed il carico di lavoro.

6.5.2 Requisiti tecnici generali:

6.5.2.1 Descrizione della soluzione richiesta:

Il sistema dovrà avere la caratteristica strutturale di essere modulare, a scalabilità lineare su tutte le sue principali componenti, senza la presenza di Single Point of Failure (SPOF).

La soluzione dovrà prevedere la possibilità di integrare componenti hardware di generazioni differenti mantenendo una piena compatibilità con il resto del sistema. Eventuali futuri aggiornamenti tecnologici che si dovessero rendere necessari per l’incremento della richiesta di prestazioni o di nuove funzionalità del sistema, dovranno poter essere applicati a caldo.

Il sistema dovrà poter prevedere la possibilità di integrare al suo interno componenti di caratteristiche e prestazioni differenti: dovrà essere possibile utilizzare dischi di tipologie, prestazioni e dimensioni differenti, componenti di I/O di front-end con prestazioni differenziate, CPU o cache memory di tipologia differenziata. Tutte queste componenti, sebbene diverse per caratteristiche dovranno poter essere completamente integrate tra loro in modo da apparire dal punto di vista logico alle applicazioni o all’utenza come una sola componente.

Pur nel rispetto delle caratteristiche sopra descritte, il sistema dovrà prevedere la possibilità di suddividere in modo granulare le sue risorse e le sue componenti in modo da poter creare dei sottosistemi specifici con caratteristiche diverse tra loro e dedicati, secondo le necessità, a compiti e servizi puntuali. Viene lasciata piena libertà sulle modalità con la quale il sistema implementa questo tipo di suddivisione delle risorse interne pur nel rispetto dei seguenti vincoli di base:

- Esecuzione a caldo della suddivisione.

- Configurazione dinamica e modificabile nel corso del tempo secondo le necessità.

- Possibilità di definire specifici servizi erogabili solo da una specifica partizione del sistema.

6.5.2.2 Global name space:

Il sistema dovrà prevedere la possibilità di poter organizzare i dati contenuti in modo che logicamente siano visti dalle applicazioni come un unico File System (c.d. Global Name space).

Tale modalità di presentazione logica del dato dovrà rendere del tutto invisibile all’utente la reale allocazione del dato all’interno del sistema; eventuali upgrade del sistema non dovranno in alcun modo alterare la rappresentazione logica del dato: il nuovo spazio a disposizione dovrà essere integrato all’interno dell’unico File System e la ridistribuzione fisica dei dati all’interno delle nuove risorse del sistema non dovrà in alcun modo alterare la collocazione logica del dato all’interno dello stesso.

Dal punto di vista delle funzionalità è richiesto che il singolo File System sia in grado di indirizzare fino ad almeno 12 PetaByte di dati utili.

6.5.2.3 Funzionalità di bilanciamento:

Il sistema dovrà consentire funzionalità di bilanciamento automatico del carico di lavoro distribuito. Il bilanciamento dovrà essere disponibile su tutti i protocolli di comunicazione front-end messi a disposizione dal sistema.

6.5.2.4 Management unificato:

Il sistema, anche se a logica distribuita, dovrà prevedere un unico punto di gestione per tutte le sue funzionalità.

6.5.2.5 Supporto servizi AAA esterni:

Il sistema dovrà essere pienamente integrabile con sistema di Authentication, Authorization e Accounting esterni che utilizzino i protocolli standard del mercato di riferimento quali LDAP, Active Directory, Kerberos. Attraverso tale integrazione dovrà essere possibile la gestione dell’accesso a ogni risorsa del sistema sia dei servizi erogati all’utenza sia della parte di management del sistema stesso.

In particolar modo il sistema, nella parte di erogazione dei servizi CIFS/SMB, dovrà essere pienamente compatibile e completamente integrabile con l’infrastruttura di Active Directory di Microsoft.

6.5.2.6 Supporto e gestione delle quote:

Il sistema dovrà prevedere funzionalità complete di gestione delle quote: dovrà essere infatti possibile definire almeno due livelli di quota per ogni singolo utente, gruppo di utenti, risorsa AD o sottoalbero del File System principale. Per ogni singolo livello di quota dovrà poter essere possibile definirne la modalità di triggering (warning o blocking). Le impostazioni di quota dovranno in ogni modo essere dinamiche e modificabili durante le normali operazioni di gestione day-by-day.

Dovrà essere possibile applicare funzionalità di quota a tutte le risorse e servizi erogati dal sistema.

6.5.2.7 Snapshot:

Il sistema deve prevedere la creazione, gestione, consolidamento e distruzione. Gli snapshot creati dovranno poter essere accessibili come risorse separate e con modalità anche diverse dalla risorsa dalla quale derivano.

Il sistema storage supporta gli snapshot a livello di volume e directory fino a 1024 snapshot per directory.

6.5.2.8 Replica remota:

Il sistema deve supportare nativamente la funzionalità di replica remota asincrona. La modalità di replica dovrà essere eseguibile utilizzando il protocollo TCP/IP.

6.5.2.9 Integrità dei dati:

Il sistema dovrà poter consentire (anche mediante eventuali licenze non incluse in fornitura e da acquisire eventualmente in seguito), la protezione dei dati in modalità WORM (Write Once Read

Many) in modo da impedire modifiche o cancellazioni accidentali o volontarie dei dati e contribuire a soddisfare i requisiti richiesti dalle normative vigenti.

6.5.2.10 Data protection:

Il sistema dovrà prevedere l’intero set dei livelli di protezione del dato. Più specificatamente, nel rispetto del vincolo di assenza di SPOF la caduta di una singola risorsa (disco o nodo che sia), non deve mai rappresentare in nessuna configurazione, un evento che porti al degrado delle funzioni del sistema o a possibili perdite di dati.

6.5.2.11 Protocolli supportati:

Devono essere pienamente supportati i protocolli standard dei sistemi NAS:

- NFSv3.

- SMBv2/CIFS.

Tutti i protocolli devono essere inclusi senza licenze addizionali o ulteriore hardware. 6.5.3 Configurazione tecnica e capacità dello Scale-Out NAS:

6.5.3.1 Spazio utilizzabile offerto al netto del livello di protezione (due dischi o un nodo) di almeno 540TiB.

Lo spazio netto utile si intende anche al netto di funzionalità di deduplica e compressione.

6.5.3.2 Livello di protezione minimo accettabile che non causi la perdita dei dati:

Guasto contemporaneo di due dischi o un interno nodo. Il sistema storage deve rimanere completamente online e con tutti i dati accessibili in tali condizioni.

6.5.3.3 Minimo n. 4 nodi nella configurazione base richiesta.

6.5.3.4 Quantità e tipologia di interfacce di rete di front-end e transceiver ottici per nodo, per l’esportazione dei dati e servizi:

N. 2 SFP+ SR 10GbE.

6.5.3.5 Quantità e tipologia delle interfacce di management per nodo:

N. 1 RJ-45 o SFP (transceiver ottico SR incluso) a 1GbE.

6.5.4 Architettura storage:

6.5.4.1 L’architettura storage deve essere di tipologia Scale-Out NAS in un unico sottosistema.

6.5.4.2 Densità dei nodi in termini di rack unit non superiore a 2 RU per nodo e 4 RU per chassis.

6.5.4.3 Performance e capacità storage lineari devono poter essere raggiunte anche aggiungendo nodi storage, ciascuno con i suoi Dischi Interni, Cache, I/O e potenza computazionale (CPU), in modo da espandere a caldo le performance e la capacità linearmente.

6.5.4.4 Lo storage deve consentire la coesistenza di nodi di differenti generazioni di hardware, senza cambiamenti alla configurazione esistente e mentre il sistema è online.

6.5.4.5 L’architettura storage deve supportare il bilanciamento automatico e senza interruzione del servizio dei dati attraverso gli storage pool per ottenere performance ottimali e efficienza della capacità, in caso di espansioni successive del sistema.

6.5.4.6 Lo storage deve essere in grado di mixare dischi SATA e SSD all’interno di un unico file system, fornendo agli utenti finali e alle applicazioni capacità aggregata e la visione delle performance del sistema.

6.5.4.7 Il sistema storage deve consentire di modificare le impostazioni e i livelli di protezione del dato.

6.5.5 File system e scalabilità:

6.5.5.1 Scalabilità minima del singolo File System – Name Space di almeno 12PB.

6.5.5.2 Il file system deve supportare l’espansione a caldo dei nodi, senza interruzione del servizio, e permettere l’utilizzo immediato della capacità e delle performance aggiunte.

6.5.5.3 Il file system deve sopportare la rottura di dischi e controller multipli, e fornire l’accesso ai dati con le performance desiderate. Il fornitore deve specificare i livelli di protezione supportati.

6.5.5.4 Il file system deve permettere un numero illimitato di accessi client indipendentemente dal sistema operativo e dal protocollo.

6.5.5.5 L’accesso dei client al file system e alle share deve essere automaticamente distribuito su tutti i nodi per ottimizzare le performance del sistema.

6.5.6 Gestione e amministrazione:

6.5.6.1 Deve essere disponibile un sistema di management tramite interfaccia Web-GUI HTML 5 e il sistema deve essere accessibile anche tramite CLI.

6.5.6.2 Deve essere abilitato e supportato il protocollo di monitoring SNMP.

6.5.6.3 La soluzione deve supportare l’autenticazione degli utenti e degli amministratori con NIS, LDAP e Active Directory.

6.5.6.4 Il sistema deve supportare il reporting avanzato e analisi delle performance, analisi del trend dello storage e strumenti di capacity planning. Il monitoraggio della capacità ed il reporting dovranno essere effettuati a livello di directory, utenti e gruppi.

6.5.6.5 Il sistema dovrà inoltre essere dotato di funzionalità di comunicazione automatica di eventuali guasti e relative segnalazioni di errori e attivare il servizio di assistenza tecnica.

Unità di Misura di riferimento per i sistemi storage dei punti 6.4 e 6.5 (Storage ALL-Flash e Scale-out NAS)

Spazio disco RAW:

Come standard in ambito storage, le unità di misura delle capacità sono da intendersi su base decimale. Pertanto, dove si fa riferimento a dimensioni multiple di Byte con riferimento a spazio disco fisico “RAW”, sono valide le seguenti relazioni:

- Kilobyte (KB) = 1.000 bytes Megabyte (MB) = 1.000.000 bytes Gigabyte (GB) = 1.000.000.000 bytes.

- Terabyte (TB) = 1.000.000.000.000 bytes Petabyte (PB) = 1.000.000.000.000.000 bytes.

Spazio disco utile:

Come standard in ambito informatico, le unità di misura delle capacità sono da intendersi su base binaria. Pertanto, dove si fa riferimento a dimensioni multiple di Byte con riferimento a spazio disco “utile”, sono valide le seguenti relazioni:

- Kibibyte (KiB) = 1.024 bytes Mebibyte (MiB) = 1.048.576 bytes Gibibyte (GiB) = 1.073.741.824 bytes.

- Tebibyte (TiB) = 1.099.511.627.776 bytes Pebibyte (PiB) = 1.125.899.906.842.624 byte.

In particolare, dovrà essere indicato come “spazio disco utile”, lo spazio disco effettivamente utilizzabile al netto di tutte le componenti necessarie al funzionamento e alla protezione dei dati (ad esempio, cache, sistemi di mantenimento della consistenza, RAID, ecc), che non rientrano nel conteggio.

6.6 Fornitura dei rack, PDU, modulo di monitoraggio ambientale e predisposizione dello streched cluster:

Al fine di predisporre il sistema per una futura configurazione “stretched cluster” dislocata in due datacenter distinti, dovranno essere forniti n. 2 armadi rack comprensivi di metered PDU e modulo di monitoraggio ambientale.

Di seguito sono riportate le caratteristiche tecnico/funzionali minime dei sistemi oggetto della soluzione.

Per questa tipologia di prodotti non è necessario rispettare il vincolo dell’unico e stesso produttore/commercializzato come per le componenti di calcolo e storage.

Saranno escluse dalla procedura di gara le soluzioni che non rispettino una o più caratteristiche tecnico/funzionali richieste.

6.6.1 N. 2 RACK 42U 19”, caratteristiche tecniche minime riferite al singolo rack:

- Dimensioni 750 x 1200mm.

- Porte anteriori e posteriori.

- Tappi anteriori e pannelli di chiusura per l’ottimizzazione della ventilazione interna, per l’intera dimensione del rack.

- Predisposizione nativa per installare le PDU richieste al successivo punto 6.6.2.

6.6.2 N.4 Metered PDU (n. 2 PDU per ogni rack), caratteristiche tecniche minime riferite alla singola PDU:

- AC 400V trifase 50/60Hz.

- Input connector N.1 IEC 60309 32A.

- Output Connectors N.30 IEC 60320 C13 e N.12 IEC 60320 C19.

- Output voltage 230V AC.

- Possibilità di connettere direttamente alla PDU sensori di temepratura/umidità.

- Management Interface Ethernet RJ45, RS-232, USB.

- Management Protocol SNMP, HTTP, SSH.

- Le PDU dovranno essere nativamente installabili nei RACK 42U 19” richiesti al punto 6.6.1.

I RACK 42U 19” relative al punto 6.6.1 e le Metered PDU relative al punto 6.6.2, dovranno essere prodotte dallo stesso costruttore/vendor, in modo da garantirne la perfetta integrazione.

6.6.3 N. 1 Modulo monitoraggio ambientale, caratteristiche tecniche minime:

- Dimensioni massime 1RU 19”.

- N. 6 collegamenti per sensori.

- N. 1 sensore di temperatura wireless.

- N. 1 Sensore cablato per la misura della temperatura e umidità.

- Sistema di monitoraggio apertura porte anteriore/posterie.

- Uscita relè per dispositivi esterni.

- Collegamento Modbus RS-485 per integrazione con un sistema di monitoraggio già presente nel Datacenter oggetto dell’intervento, basato su hardware Rasberry PI e convertitore USB-RS485 Modbus. (specificare utilizzo poiché RS-485 è un collegamento seriale di lunga distanza – più da quadri industriali).

- Collegamento di rete 10/100Base-T.

- Sorveglianza e allarme via Ethernet/browser Web/e-mail.

6.6.4 Componenti da installare in ogni rack per la predisposizione dello streched cluster: Rack A:

- N.1 chassis blade server.

- N.1 storage ALL-Flash.

- N. 2 PDU.

- N. 1 Modulo monitoraggio ambientale.

Rack B:

- N.1 chassis blade server.

- N.1 storage ALL-Flash.

- N.1 scale-out NAS.

- N. 2 PDU.

In testa ai due rack dovrà essere lasciato sufficiente spazio libero necessario all’installazione, per ogni singolo rack, di n. 2 Switch Top Of the Rack, per uno spazio totale occupato di n. 2 RU per rack.

Al fine di minimizzare l’ingombro, lo spazio occupato dai rack che ospiteranno i sistemi offerti non dovrà superare la superficie equivalente allo spazio occupato da 2 rack standard 42U, ove per standard si intendono rack aventi dimensione esterna pari a 750x1200mm.

Al netto dei componenti offerti, in ogni singolo rack dovrà essere garantito uno spazio libero minimo, in termini di RU, pari a 12.

Per consentire una corretta ventilazione dell’HW, eventuali spazi liberi nel rack dovranno essere chiusi con appositi blanking panel 19”.

Si precisa inoltre, che l’assorbimento massimo dei sistemi offerti non potrà superare le specifiche elettriche delle PDU richieste.

6.7 Patch cord in fibra ottica e rame:

Per questa tipologia di prodotti non è necessario rispettare il vincolo dell’unico produttore come per le componenti di calcolo e storage.

6.7.1 Patch cord in fibra ottica:

- N.16 OM3 LC-LC da 0,5 metri.

- N.4 OM3 LC-LC da 1 metri.

- N.4 OM3 LC-LC da 2 metri.

- N.2 OM3 LC-LC da 3 metri.

- N.5 OM3 LC-LC da 5 metri.

- N.8 OM3 LC-LC da 7 metri.

- N.8 OM3 LC-LC da 10 metri.

- N.1 OM3 LC-SC da 3 metri.

- N.4 OM3 LC-SC da 2 metri.

- N.10 OM3 ST-LC da 2 metri.

- N.2 OS1 LC-LC da 2 metri.

- N.6 MTP QSFP28 to MTP QSFP28 12 core da 3 metri.

6.7.2 Patch cord in rame:

- N.10 RJ45 Cat.6A da 2 metri.

- N.8 RJ45 Cat.6A da 5 metri.

- N.6 RJ45 Cat.6A da 7 metri.

- N.3 RJ45 Cat.6A da 10 metri.

- N.2 RJ45 Cat.6A da 15 metri.

6.8 Transceiver ottici per l’interconnessione di apparecchiature già esistenti:

- N. 4 DELL SFP-10G-SR, DP/N: 03G84K, AFBR-709SMZ-D1.

Sono richiesti i transceiver originali al fine di non compromettere la garanzia esistente sui prodotti.

6.9 Upgrade di licenza per Switch Brocade:

È richiesta l’upgrade della licenza di n. 2 Switch Brocade, per l’integrazione degli stessi con il sistema che si sta acquisendo. Di seguito i dettagli tecnici richiesti:

- Licenza Enterprise performance bundle per n. 2 Brocade 6505:

o Brocade 6505 A, S/N: 3K60T72.

o Brocade 6505 B, S/N: CL60T72.

Document Metadata

Table of Contents

Free Standard Templates

CAPITOLATO TECNICO

Document Metadata