GARA EUROPEA A PROCEDURA APERTA CON MODALITA’ TELEMATICA SU PIATTAFORMA ASP CONSIP

PER L’AFFIDAMENTO DEL CONTRATTO AVENTE AD OGGETTO

LA FORNITURA DI UN DATACENTER PER CALCOLO AD ALTE PRESTAZIONI, NELL’AMBITO DEL PROGETTO PON R&I 2014-2020 AVVISO 424/2018 AZIONE II.1 PIR01_00022 DARIAH-IT CUP B67E19000040007,

DA CONSEGNARE E INSTALLARE PRESSO CNR NANOTEC SEDE DI LECCE

Capitolato tecnico

CIG 8332391A91

CUI 80054330586201900617

CPV 48820000-2

1 Xxxxxxxx 0

0 Xxxxxxxxxx 0

0.0 Xxxxxxx della fornitura 5

2.2 Gestione, coordinamento e controllo della fornitura 5

2.3 Presentazione della relazione tecnico-illustrativa 5

2.4 Prescrizioni in materia di sicurezza 6

3 Oggetto della Fornitura 6

3.1 Caratteristiche dell’infrastruttura CDCN-LE 7

3.1.1 Caratteristiche Generali dell’architettura 7

3.1.2 Gestione del Traffico 8

3.1.3 Funzionalità di Data Center (DC) Interconnect 9

3.1.4 Virtual Networks / Multi-Tenancy 9

3.1.5 Application Flows e Statistiche 9

3.1.6 Management e monitoraggio 9

3.1.7 Caratteristiche Hardware dell’Infrastruttura del CDCN-LE 10

3.1.8 Attività di Configurazione dell’infrastruttura CDCN-LE 15

3.2 Caratteristiche dell’infrastruttura HPC 16

3.2.1 Sistema di calcolo HPC/GPU (HPCGC) 16

3.2.2 Caratteristiche comuni dei nodi HPCGC 17

3.2.3 Caratteristiche dei Nodi di Calcolo “Thin” 17

3.2.4 Caratteristiche dei Nodi di Calcolo “Fat” con GPU 20

3.2.5 Caratteristiche dei Nodi di Servizio 22

3.2.6 Infrastruttura di rete per l’Interconnessione veloce e a bassa latenza 24

3.2.7 Sistema di Storage/Cluster File System (HPCFS) 24

3.2.8 Sistema di Storage Tier2 (T2SS) 26

3.2.9 Management Data Center Network (MDCN) 26

3.2.10 Software 26

3.2.11 Attività di Installazione ed Implementazione dell’infrastruttura HPC 27

3.2.12 Verifiche e test funzionali dell’infrastruttura HPC 30

3.3 Caratteristiche dell’infrastruttura CI 30

3.3.1 Componente Computazionale 32

3.3.2 Componente Network LAN 35

3.3.3 Componente Network SAN 35

3.3.4 Componente Management 36

3.3.5 Componente Storage Tier 0 36

3.3.6 Componente Storage Tier 2 39

3.3.7 Componente Storage Tier 3 - Object Storage 45

3.3.8 Componente Software 47

3.3.9 Componente Servizi a Catalogo 49

3.3.10 Attività di installazione e configurazione dell’infrastruttura CI 50

3.4 Servizi di Assistenza e Manutenzione Sistemi CDCN-LE, HPC e CI 53

3.4.1 Servizio di manutenzione on-site 54

3.4.2 Servizio di assistenza tramite call-center 54

3.4.3 Assistenza sistemistica per la componente CI 54

3.5 Requisiti di allestimento della sala del DC-LE 54

3.5.1 Caratteristiche tecniche isola compartimentata 56

3.5.2 Caratteristiche del sistema di condizionamento del DC-LE 57

3.5.3 Caratteristiche tecniche armadi rack per apparecchiature informatiche 59

3.5.4 Caratteristiche tecniche barre d’alimentazioni intelligenti - PDU 59

3.5.5 Adeguamento Impianto elettrico 60

3.5.6 Caratteristiche tecniche UPS 61

3.5.7 Caratteristiche gruppo elettrogeno 62

3.5.8 Controllo Accessi e Videosorveglianza 64

3.5.9 Impianto antincendio 64

3.5.10 Attività di configurazione dell’infrastruttura tecnologica 64

3.5.11 Manutenzione Infrastruttura Tecnologica 64

3.6 Servizi di formazione richiesti 65

3.6.1 Workshop 65

3.6.2 Training on the Job 66

4 Marcatura “CE” 66

5 Luogo e termine di consegna e installazione 66

6 Avvio e termine dell’esecuzione del contratto 66

6.1 Avvio dell’esecuzione 66

6.2 Sospensione dell’esecuzione 66

6.3 Termine dell’esecuzione 66

7 Penalità 66

8 Modalità di resa 67

9 Oneri ed obblighi dell’Aggiudicatario 67

10 Sicurezza sul lavoro 68

11 Divieto di cessione del contratto 68

12 Verifica di conformità della fornitura 68

13 Fatturazione e pagamento 68

14 Tracciabilità dei flussi finanziari 69

15 Garanzia ed assistenza tecnica 69

16 Recesso 69

17 Risoluzione del contratto 70

1 PREMESSE

Il presente documento riguarda la fornitura di un datacenter per il calcolo ad alte prestazioni e relativi servizi per attività di ricerca scientifica del Dipartimento di Scienze Umane (DSU) del Consiglio Nazionale delle Ricerche (CNR).

Salvo diversa esplicita indicazione, ai termini riportati di seguito, viene attribuito, ai fini del presente documento, il significato indicato:

CNR, indica nel complesso le strutture organizzative facenti capo al Consiglio Nazionale delle Ricerche;

DSU, indica nel complesso le strutture organizzative facenti capo al Dipartimento di Scienze Umane del Consiglio Nazionale delle Ricerche;

NANOTEC, indica nel complesso le strutture organizzative facenti capo all’Istituto di Nanotecnologia – sede di Lecce - del Consiglio Nazionale delle Ricerche;

Capitolato tecnico, indica il presente documento;

Fornitura, indica, nel suo complesso, la vendita degli apparati elettronici, impianti tecnologici, la cessione delle licenze d’uso dei prodotti software oggetto del presente Capitolato tecnico, le licenze per l’abilitazione di funzionalità sugli apparati, nonché l’erogazione dei servizi descritti;

Società, indica l’Aggiudicatario della fornitura;

Datacenter, indica nel suo complesso il sistema di calcolo ad alte prestazioni oggetto della presente fornitura che sarà dislocato presso la sede NANOTEC di Lecce, Xxx Xxxxxxxxx xxx, x/x Xxxxxxxxx Xxxxxxxx, Xxxxxxxx X Xxxxx xxxxx; Apparecchiature HW, indica indistintamente tutte le apparecchiature elettroniche costituenti il sistema di calcolo ad alte prestazioni oggetto della fornitura;

Prodotti SW, indica il software e le licenze d’uso necessarie per il funzionamento del sistema di calcolo ad alte prestazioni oggetto del presente capitolato tecnico oltre l’eventuale software di ausilio alla gestione delle apparecchiature HW e tecnologiche;

Infrastruttura tecnologica, indica indistintamente tutte le parti strutturali ed impiantistiche necessarie per l’allestimento del datacenter, le apparecchiature elettriche di potenza, di protezione elettrica (UPS e gruppo elettrogeno) e di refrigerazione delle apparecchiature HW oggetto della presente fornitura necessarie per l’allestimento ed il funzionamento del sistema di calcolo ad alte prestazioni;

Sala, indica il locale in cui dovrà essere dislocato e installato il datacenter oggetto della presente fornitura.

2 GENERALITÀ

Il presente documento stabilisce i requisiti (i quali, salvo diversa indicazione, debbono intendersi come minimi) che devono essere soddisfatti per l’ammissibilità delle offerte.

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 della Società.

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

• Essere dello stesso Produttore, fatta eccezione per le componenti Infiniband afferenti alla rete di interconnessione a bassa latenza, le eventuali componenti software integrate della rete CDCN-LE, i cablaggi e le componenti dell’infrastruttura tecnologica di cui ai paragrafi 3.2.6 e 3.5.

• Essere nuovi di fabbrica (e recare il marchio di fabbrica del costruttore), di provenienza legale, provenienti dai canali ufficiali di rivendita/distribuzione sul territorio italiano e conservati nel packaging originale (non usato né rigenerato).

• Essere prodotti da primarie aziende internazionali, ove per aziende internazionali si intendono quelle che hanno sedi commerciali a livello mondiale, direttamente o tramite società controllate, in almeno cinque paesi europei, in U.S.A. ed in Canada.

• Rispettare le prescrizioni della normativa vigente in materia di inquinamento acustico;

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

Tutti i sistemi e le funzionalità offerte devono essere disponibili sul listino e sul portafoglio prodotti pubblico ufficiale del Produttore al momento della pubblicazione della gara.

È obbligatorio per la partecipazione alla gara effettuare un sopralluogo al fine di prendere visione e avere conoscenza degli attuali ambienti fisici (locali, scale, spazi di manovra) dell’Istituto di Nanotecnologia – sede di Lecce - del Consiglio Nazionale delle Ricerche - presso le quali si dovranno consegnare e installare gli apparati HW e tecnologici. Il sopralluogo dovrà essere effettuato secondo le disposizioni di cui all’art. 11 del Disciplinare.

2.1 Sintesi della fornitura

Nell’ambito del progetto Developing nAtional and Regional Infrastructural nodes of dAriaH in ITaly (DARIAH-IT) di rafforzamento infrastrutturale - PON Ricerca e Innovazione 2014-2020 (CCI: 2014IT16M2OP005) - che il DSU ha avuto finanziato è prevista la seguente fornitura in unico lotto:

Datacenter DSU NANOTEC Lecce - Fornitura “Chiavi in mano” di un nuovo datacenter per il calcolo ad alte prestazioni e relativi servizi che sarà dislocato presso la sede NANOTEC di Lecce, Xxx Xxxxxxxxx xxx, x/x Xxxxxx Xxxxxxxx, Xxxxxxxx X Xxxxx xxxxx (xx seguito indicato DC-LE). Tale infrastruttura di calcolo dovrà includere sia un’infrastruttura per il calcolo parallelo ad alte prestazioni (di seguito indicata HPC – High Performance Computing), sia un’infrastruttura convergente per la creazione di ambienti di calcolo virtuali ad alte prestazioni (di seguito indicata CI - Converged Infrastructure). La fornitura del DC-LE comprenderà tutte le apparecchiature HW, i prodotti SW e le infrastrutture tecnologiche e relativi servizi di preinstallazione, installazione, configurazione e attivazione apparecchiature HW e prodotti SW, compresi i servizi di formazione e manutenzione necessari per il funzionamento complessivo del DC-LE.

Tutte le apparecchiature HW e i prodotti SW e gli impianti tecnologici che saranno oggetto della fornitura devono intendersi nella loro ultima release Enterprise disponibile e con il numero maggiore di funzionalità previste anche se non esplicitamente indicato.

2.2 Gestione, coordinamento e controllo della fornitura

Al fine di assicurare una corretta esecuzione della fornitura, ovvero la gestione delle consegne i servizi di preinstallazione, installazione, configurazione e attivazione, delle apparecchiature HW, prodotti SW, e le infrastrutture tecnologiche si richiede la supervisione, di un Project Manager in possesso di almeno una certificazione tra PMI, IPMA, PRINCE2 avente le seguenti responsabilità:

- Ha la visione del disegno dell’architettura.

- Si coordina con le figure responsabili dei singoli sottosistemi nel rispetto dei requisiti tecnologici richiesti.

- Raccoglie e rielabora, se necessario, la documentazione richiesta.

- Evidenzia le criticità ed i rischi di progetto legati alla soluzione tecnica.

- Mantiene il coordinamento tecnico su tutte le iniziative progettuali.

- E’ responsabile del raggiungimento degli obbiettivi della fornitura, secondo quanto contrattualmente concordato: prodotti, qualità e tempistiche.

- Pianifica le attività e ne segue lo stato di avanzamento.

- Gestisce l’assegnazione delle risorse alle attività di fornitura.

- Gestisce la comunicazione sia interna che esterna ai gruppi di lavoro.

- Evidenzia le criticità e rimuove gli ostacoli.

- Qualifica e gestisce, in collaborazione con i referenti CNR, eventuali modifiche in corso d’opera.

- Verifica che le soluzioni tecnologiche, le procedure ed i deliverable siano adeguati ed approvati dai referenti CNR.

2.3 Presentazione della relazione tecnico-illustrativa

Per questa fornitura è richiesta ai concorrenti la produzione, contestualmente alla presentazione dell’offerta tecnica, di una relazione tecnico illustrativa riportando la progettazione preliminare del datacenter comprese le architetture di calcolo proposte, i sistemi di rete (networking) interni e per l’accesso esterno del datacenter, i sistemi di archiviazione e le infrastrutture tecnologiche. Inoltre, dovrà essere presente il piano dei servizi di preinstallazione e installazione e configurazione dei sistemi offerti ed il piano dei servizi di formazione e manutenzione.

Deve essere inclusa in tale relazione anche la documentazione tecnico-commerciale del produttore (brochure, datasheet, etc.), ad integrazione di quanto richiesto nel Capitolato tecnico.

Per ogni capitolo e relativi paragrafi del presente capitolato tecnico dovranno essere corrispondentemente illustrate le caratteristiche del prodotto che si intende fornire e la relativa rispondenza ai requisiti tecnici. La rispondenza ai requisiti richiesti dovrà potersi evincere chiaramente dalla documentazione tecnica a corredo; non saranno ammesse generiche dichiarazioni di rispondenza ai requisiti del Capitolato Tecnico prive di riferimenti documentali.

Inoltre il concorrente dovrà allegare alla relazione tecnico illustrativa, previa compilazione, il documento (vedi esempio sottostante Tabella 2.3.1), già predisposto dalla Stazione appaltante (Modello “Schede requisiti minimi DC Lecce.xls”), relativo a tutti i requisiti minimi obbligatori imposti dal presente Capitolato tecnico nonché alle eventuali migliorie rispetto

a detti requisiti minimi, in cui devono essere indicati: il documento tecnico di riferimento (brochure, data sheet, sito internet, etc., identificato dal titolo e dalla sigla), la pagina e la posizione nella pagina alla quale deve potersi chiaramente evincere il soddisfacimento/miglioramento del requisito in oggetto.

Sotto sistema Y – Requisiti minimi obbligatori
ID requisito	Requisito minimo soddisfatto?	Documento tecnico (Titolo, Sigla)	Pagina e posizione Documento tecnico nella quale sono riportate le caratteristiche tecniche richieste	Eventuali migliorie rispetto ai requisiti minimi	Eventuali note
R.Y.1
R.Y.2
…
R.Y.n

Tabella 2.3.1

2.4 Prescrizioni in materia di sicurezza

Tutte le apparecchiature fornite devono essere conformi alla normativa vigente che regolamenta la loro produzione, commercializzazione ed utilizzazione.

In particolare, devono rispettare, ciascuna per le singole specifiche caratteristiche, le seguenti prescrizioni in materia di sicurezza:

• Legge 1 marzo 1968, n. 186 “disposizioni concernenti la produzione di materiali, apparecchiature, macchinari, installazioni e impianti elettrici ed elettronici”;

• Legge 18 ottobre 1977, n. 791, così come modificata dal D. Lgs. 25 novembre 1996 n. 626, “attuazione della direttiva 93/68/CEE in materia di marcatura CE del materiale elettrico destinato ad essere utilizzato entro alcuni limiti di tensione”;

• D. Lgs. 25 luglio 2005, n. 151, “attuazione delle direttive 2002/95/CE, 2002/96/CE e 2003/108/CE, relative alla riduzione dell’uso di sostanze pericolose nelle apparecchiature elettriche ed elettroniche, nonché allo

smaltimento dei rifiuti”;

• D. Lgs. 3 aprile 2006, n. 152, “Norme in materia ambientale”;

• D. Lgs. 9 aprile 2008, n. 81 “Attuazione dell’articolo 1 della legge 3 agosto 2007, n. 123, in materia di tutela della salute e della sicurezza nei luoghi di lavoro”;

• Norme UNI e CEI di riferimento.

È fatto obbligo alla Società di garantire la sicurezza di quanto fornito documentando in particolare l’eventuale presenza di sostanze nocive o cancerogene.

La Società s’impegna inoltre a porre in essere, prima dell’inizio delle attività contrattuali, quanto necessario a garantire l’esecuzione delle attività in piena aderenza con le disposizioni del D. Lgs. 81/2008 “Testo Unico sulla sicurezza durante il lavoro”, fornendo, in particolare, il documento di valutazione dei rischi relativo alle attività di cui al presente Capitolato, ai fini anche della predisposizione/aggiornamento del D.U.V.R.I. (Documento Unico di Valutazione Rischio da Interferenze) di cui al comma 3 dell’art. 26 del suddetto decreto.

3 OGGETTO DELLA FORNITURA

Il presente documento riguarda la fornitura “Chiavi in mano” di un nuovo datacenter DC-LE per il calcolo ad alte prestazioni e relativi servizi che sarà dislocato presso la sede NANOTEC di Lecce, Via Monteroni snc, c/o Campus Ecotekne, Edificio E Piano terra. Il DC-LE dovrà includere sia un’infrastruttura per il calcolo parallelo ad alte prestazioni (HPC), sia un’infrastruttura convergente per la creazione di ambienti di calcolo virtuali ad alte prestazioni (CI).

I due sistemi HPC e CI del DC-LE, seppur logicamente distinti, condivideranno le infrastrutture tecnologiche necessarie per il funzionamento delle apparecchiature HW:

- l’infrastruttura di rete del datacenter DC-LE per l’interconnessione ad alta velocità interna ed esterna dei due sistemi HPC e CI (di seguito indicata CDCN-LE – Core Data Center Network);

- sala del DC-LE realizzata su pavimento sopraelevato, isola compartimentata per l’alloggiamento degli armadi rack che ospitano le apparecchiature HW e di refrigerazione, sistema di alimentazioni elettrica e quadri di potenza, apparati di

continuità e protezione elettrica (UPS) delle apparecchiature HW, gruppo elettrogeno di supporto al sistema elettrico, protezioni antincendio e di controllo degli accessi al personale autorizzato.

L’architettura generale di alto livello del DC-LE può essere schematizzata con il seguente diagramma:

Figura 3.1: Architettura generale di alto livello del DC-LE

3.1 Caratteristiche dell’infrastruttura CDCN-LE

Nei moderni data center, dal punto di vista del networking, risulta ormai superata la tradizionale architettura a tre livelli costituita dai livelli access, aggregation e core. Il motivo principale di ciò è da attribuire alla crescita del traffico di rete orizzontale (ovvero “east-west”) all’interno del data center (server-server, server-storage, ecc.). Pertanto l’architettura di riferimento maggiormente in uso attualmente è quella denominata Clos-based (leaf-spine). Tale nuova architettura è stata progettata per minimizzare il numero di hops tra gli hosts.

Come si evince dalla Figura 3.2, questo design appiattisce la topologia fisica, garantisce un’elevata scalabilità e fornisce una latenza predicibile switch-to-switch, rimuovendo quasi del tutto il rischio di loop di rete.

Figura 3.2: Architettura leaf-spine Requisito Progettuale Vincolante CDCN-LE 1 (RPV-CDCN-LE-1)

L’infrastruttura di rete privata del CDCN-LE, dovrà essere basata su topologia Clos-based e dovrà consentire l’interconnessione di sistemi eterogenei, dall’infrastruttura HPC e CI, ai sistemi storage e ogni altra entità di servizio del DC-LE.

3.1.1 Caratteristiche Generali dell’architettura

L’architettura di connettività proposta dovrà implementare una fabric IP-Ethernet basata su protocolli standard ed open che dovrà apparire e comportarsi verso il mondo esterno come un unico sistema logico (Virtual Fabric). Dovrà essere pertanto possibile gestire, configurare, e automatizzare l’intera fabric come un singolo sistema logico.

La componente software che implementa le funzionalità richieste dovrà poter essere eseguita direttamente all’interno degli switch fisici, senza necessità di ricorrere a controller o altre entità esterne. L’insieme degli switch fisici richiesti dal

presente Capitolato Tecnico e della componente software relativa all’implementazione delle funzionalità richieste dovranno pertanto essere autoconsistenti.

Il Sistema proposto dovrà implementare una fabric a singolo management plane, sia a livello locale che geografico, dotato di caratteristiche di alta affidabilità.

Dovrà essere possibile implementare la fabric su qualsiasi topologia fisica sottostante ed indipendentemente dall’interconnessione attraverso altri dispositivi non dello stesso vendor, senza la necessità che i sistemi siano adiacenti. La Fabric dovrà poter essere gestita mediante CLI e RESTful API. La gestione mediante CLI/API dovrà supportare l’utilizzo dei più comuni tool di automazione, come ad es. Ansible o Python.

La fabric dovrà poter essere configurata come una singola entità, ed ogni switch appartenente alla fabric dovrà poter sincronizzare il suo provisioning state in maniera autonoma, con la possibilità di effettuare rollback a stati precedenti.

La Fabric dovrà permettere di configurare oggetti a livello sia globale che locale (singolo switch) e di identificare set di oggetti fabric-wide.

La fabric dovrà supportare eventuali situazioni di split-brain senza che ciò impatti sul forwarding del traffico locale. In caso di fabric-stretch su location geografiche differenti, il sistema dovrà poter continuare a mantenere validi e operativi sia il control plane che il data plane locali.

3.1.2 Gestione del Traffico

La fabric dovrà supportare meccanismi di:

- Broadcast suppression;

- Conversational forwarding;

- ARP Optimization (possibilità di effettuare proxy ARP se l’informazione è già presente nel DB interno);

- Anycast Gateway (possibilità per gli endpoint di utilizzare lo stesso virtual MAC/Indirizzo IP su tutti i first-hop switch). Le subnet interessate da funzionalità di anycast gateway dovranno poter essere configurate come un singolo oggetto atomico fabric-wide. Il numero di istanze VRF con capacità di anycast gateway dovrà essere pari almeno a 1000.

Le ottimizzazioni di forwarding sopra menzionate dovranno essere disponibili almeno con riferimento alle seguenti operazioni: bridging, routing, extended bridging (su VxLAN tunnels) ed extended routing (su VxLAN tunnels). La fabric dovrà essere in grado di aggregare link tra due switch mediante meccanismi di Layer2 Multi-pathing e multi chassis/virtual chassis LAG. Tutti gli switch nella fabric dovranno potersi scambiare informazioni topologiche relative ai device adiacenti e dovranno implementare uno shared endpoint database.

La fabric dovrà poter implementare:

- meccanismi STP standard con altri device non appartenenti alla fabric, utilizzando protocolli standard;

- un meccanismo di loop-guard di livello 2 non basato su STP. Dovrà cioè essere possibile, senza implementare meccanismi di STP con dispositivi esterni alla fabric, individuare la presenza di loop tra due qualsiasi porte appartenenti alla fabric anche quando le porte sono ubicate su switch differenti interconnessi localmente o attraverso una rete IP.

Gli switch forniti dovranno supportare la possibilità di incapsulare e decapsulare in HW il traffico VxLAN mediante meccanismi di VxLAN Tunnel EndPoint (VTEP).

La virtual fabric nel complesso dovrà supportare funzionalità di VTEP high availability (VTEP HA) attivando funzionalità di VTEP su almeno due switch: la VTEP HA dovrà poter usare lo stesso anycast IP address su entrambi gli switch, ed entrambi gli switch dovranno poter incapsulare e decapsulare il traffico VxLAN allo stesso tempo. La funzionalità di VTEP HA dovrà essere configurabile come un singolo fabric object (non dovrà richiedere l’effettuazione della configurazione su ogni singolo switch).

La fabric dovrà essere dotata di capacità native di interscambio di informazioni con altri nodi all’interno della fabric. In caso di VXLAN, queste informazioni dovranno includere almeno:

- i dati di configurazione del VXLAN Tunnel Endpoint (VTEP), ad esempio i VTEP IP address e le Virtual Network Interface (VNIs);

- le informazioni di raggiungibilità e di routing come i MAC Address, i VTEP IP address, e le informazioni VNI.

La fabric dovrà poter creare tunnel VxLAN verso altri nodi nella fabric senza utilizzare protocolli basati su multicast.

La fabric dovrà poter supportare all’interno di una istanza isolata di Sistema Operativo (x.xx in un container o in una VM) l’implementazione di:

- Routing application stacks (OSPF o BGP);

- Interfacce OVSDB;

- Istanze virtual network manager.

I servizi implementati nelle istanze di Sistema Operativo dovranno poter essere portabili, ovvero migrabili verso nodi differenti della fabric.

La fabric dovrà inoltre supportare a livello fabric-wide funzionalità di:

- Policy-based Routing;

- Access Control;

- Line-rate control, manipolazione e redirezione logica o fisica dei flussi;

- Flow-level Security;

- Control Plane Traffic Protection: il traffic di control plane dovrà essere separabile e gestito con priorità rispetto al traffico di rete. Dovranno essere inoltre implementabili politiche di rate limiting al fine di mitigare gli effetti di eventuali attacchi di sicurezza.

3.1.3 Funzionalità di Data Center (DC) Interconnect

La fabric dovrà poter estendere eventuali domini Layer 2 su più location geografiche remote, utilizzando protocolli IP standard come VxLAN al fine di garantire l’interoperabilità con eventuali reti e sistemi di terze parti. Non saranno ammesse soluzioni che facciano uso di protocolli o sistemi specializzati per il Data Center Interconnect.

Dovrà essere possibile realizzare tunnel DC verso altre location a partire da qualsiasi switch nella fabric.

La fabric dovrà poter estendere le infrastrutture convergenti oggetto di acquisizione tra più data center, e dovrà poter raccogliere, organizzare e presentare mediante interfaccia grafica e testuale tutti i dati relativi alle connessioni (a titolo esemplificativo e non esaustivo: end-to-end latency, duration, total bytes transferred, stato delle connessioni TCP in real time) senza necessità di usare algoritmi di sampling e senza fare uso di wire taps o mirror ports.

In uno scenario multi-tenant, dovrà essere possibile implementare almeno i seguenti servizi:

- Point-to-Point Virtual Connections with HA;

- Multipoint-to-Multipoint Virtual Connections with HA;

- Fully transparent point-to-point pseudo-wires, inclusi i meccanismi di link state tracking e le informazioni di application telemetry.

La fabric dovrà supportare meccanismi avanzati di classificazione del traffico e di QoS e la capacità di regolare il traffico sia a livello di flusso che di porta fisica.

Dovrà essere possibile la tracciatura di qualsiasi flusso di traffico al fine di poter effettuare troubleshooting.

3.1.4 Virtual Networks / Multi-Tenancy

La fabric dovrà poter organizzare la rete fisica in più reti logiche (Virtual Networks o Tenant) distinte, ognuna dotata delle proprie risorse, servizi di rete e politiche QoS.

Ogni Tenant dovrà avere un singolo punto di management dedicato. Il Fabric Administrator dovrà poter assegnare l’ownership di ogni singolo tenant ad un amministratore distinto e dotato di credenziali separate, il quale potrà provvedere in autonomia alla gestione e configurazione del Tenant.

Ogni Tenant dovrà avere sia data plane che control plane isolati e separati.

3.1.5 Application Flows e Statistiche

La fabric dovrà implementare meccanismi di Application flow visibility in grado di fornire informazioni su:

- Real-time Correlation tra server e client;

- overlay/underlay Performance analysis;

- Capacity Planning & Network Troubleshooting sia a livello Intra-data center che Inter-data center;

- Security and Incident Response.

Gli switch dovranno supportare tool di sampling open-source come sFLOW e processi di metering come IPFIX in grado di fornire informazioni di traffico costanti su tutte le interfacce abilitate.

3.1.6 Management e monitoraggio

Dovrà essere reso disponibile ed incluso in fornitura un tool grafico di Fabric Management al fine di poter effettuare attività di Network Provisioning, Monitoring and Analytics.

Il tool di management dovrà poter visualizzare a livello grafico la completa topologia della rete, rappresentando tutti gli elementi che sono parte della fabric e gli eventuali device esterni ad essa interconnessi.

Attraverso il tool dovrà essere possibile effettuare il provisioning e il monitoraggio di multiple fabric instance, e dovrà

altresì essere possibile automatizzare le operazioni relative al deployment iniziale della fabric.

Il tool di management dovrà almeno essere in grado di effettuare il provisioning ed il monitoraggio dei seguenti costrutti:

- Port characteristics;

- VLANs and port VLAN membership;

- STP characteristics;

- VLAN Interfaces and layer-3 ports;

- OSPF, BGP adjacencies and static routes;

- VxLAN VTEPs and related VxLAN to VLAN mappings;

- Point-to-Point transparent pseudowires;

- Security Policies;

- QoS Policies;

- Mirror objects.

Dovrà essere possibile raccogliere e visualizzare almeno i seguenti dati:

- fabric device model, serial number, transceiver inventory, software version, licensing information;

- fabric device system health, (CPU utilization, disk and memory utilization);

- Physical port counters over time, ingress and egress, con la possibilità di comparare fino a 10 porte nello stesso tempo;

- Endpoint active on each fabric device and related flow information;

- Syslog data;

- SNMP trap.

Il tool dovrà includere una funzionalità di network analytics collector in grado di raccogliere, analizzare e presentare all’utente i dati relative ai flussi applicative di rete, utilizzando almeno le seguenti sorgenti:

- Dati di telemetria della fabric;

- Altre sorgenti dati come ad es. Netflow, sFlow devono essere supportate.

I dati raccolti dovranno essere presentati in maniera chiara ed utile all’utente mediante grafici a torta, ad istogramma, diagrammi Sankey, etc. anche al fine di consentire l’identificazione di relazioni tra le applicazioni ed il funzionamento dell’infrastruttura fisica e di eventuali colli di bottiglia.

Dovrà essere possibile configurare:

- tag personalizzati che dovranno essere memorizzati insieme ai dati al fine di migliorare l’interpretabilità degli stessi da parte degli utenti;

- Nomi per specifici valori di porte TCP.

Dovrà essere possibile integrare il collector database con metadati provenienti da sistemi di terze parti come: server DNS, sistemi di geolocalizzazione, sistemi di virtualizzazione/iperconvergenza (VMWare, Nutanix, etc.), Active Directory, ecc.

I dati raccolti dovranno poter essere filtrati e ricercabili mediante query specifiche impostate dall’utente.

Il tool dovrà mettere a disposizione una funzione di packet analytics che consenta la visibilità a livello L4-L7 dei pacchetti dati applicativi utilizzando almeno le seguenti sorgenti di dati:

- file PCAP offline;

- Traffico real-time.

3.1.7 Caratteristiche Hardware dell’Infrastruttura del CDCN-LE

Dovrà pertanto essere fornita una infrastruttura di switching ad alte prestazioni di classe data center, avente le seguenti caratteristiche HW minime:

- Architettura HW basata su chipset standard-silicon;

- Topologia fisica di tipo Spine-Leaf, con rapporto di over subscription non superiore a 3:1 e velocità di accesso alla rete pari ad almeno 25 Gbps;

- L’infrastruttura dovrà mettere a disposizione almeno 240 porte, o, un numero di porte sufficiente a garantire il collegamento in rete di tutti i nodi THIN e FAT e servizi di storage/management, di accesso di tipologia SFP28. Per il soddisfacimento del requisito, non sono ammesse eventuali porte oggetto di breakout (ad es porte a 100Gb splittate in più porte a 25Gbps);

- Velocità di interconnessione tra i layer spine e leaf non inferiore a 100 Gbps

- Alimentatori e ventole ridondati e hot-swap, assenza di ulteriori single point of failure.

- Supporto ONIE per l’utilizzo di sistemi operativi alternativi linux-based;

- Supporto di Sistemi Operativi di Rete differenti da quelli sviluppati dal produttore degli apparati. L’utilizzo di S.O. diversi non deve inficiare il supporto HW degli apparati;

- Dimensione massima di ogni switch max 1 RU;

- Caratteristiche HW minime degli Switch di Accesso (Leaf):

o Almeno 48 porte di accesso ad almeno 25Gbps con connettori SFP28;

o Almeno 6 porte di uplink ciascuna a velocità di 100 Gbps QSFP28;

o Switching capacity minima 3,6 Tbps, non blocking;

o Gli switch dovranno essere completi di ottiche 10 e 25Gb SR in rapporto di 3:1. Per l’interconnessione dei soli nodi oggetto della presente fornitura sarà ammesso l’uso di cavi DAC in rame esclusivamente per le connessioni all’interno dello stesso rack.

- Caratteristiche HW minime degli Switch di Core (Spine):

o Almeno 32 porte 100Gbps QSFP28 con supporto delle velocità 10/25/40/100 Gbps o superiori;

o Forwarding capacity minima: 4400 Mpps (Full Duplex, packet size >350bytes);

o Switching capacity minima 6,4 Tbps, non blocking.

o Gli switch dovranno essere completi di ottiche 40GbSR per l’interconnessione alla rete NANOTEC/ GARR ed ai sistemi CI di cui ai paragrafi successivi.

Le connessioni tra gli switch spine e leaf dovranno essere effettuate mediante cavi in fibra ottica. Fanno parte della fornitura le eventuali ottiche e cavi necessari per realizzare tutte le interconnessioni tra spine e leaf e verso tutti i sistemi oggetto della presente fornitura, compresa l’interconnessione agli apparati di frontiera (router/switch) del nodo POP-GARR della rete NANOTEC.

Di seguito sono riportati i requisiti minimi obbligatori, a pena di esclusione, dell’infrastruttura CDCN-LE.

Infrastruttura CDCN-LE – Requisiti Minimi Obbligatori

ID requisito

Descrizione

Richiesta Minima

R.CDCN.1

L’infrastruttura CDCN deve essere basata su topologia Clos-based

R.CDCN.2

L’architettura di connettività proposta deve implementare una fabric IP-Ethernet basata su protocolli standard ed open che deve apparire e comportarsi verso il mondo esterno come un unico sistema logico (Virtual Fabric). Deve essere pertanto possibile gestire, configurare, e

automatizzare l’intera fabric come un singolo sistema logico

R.CDCN.3

La componente software che implementa le funzionalità richieste deve essere eseguita direttamente all’interno degli switch fisici, senza necessità di ricorrere a controller o altre entità esterne. L’insieme degli switch fisici richiesti dal presente Capitolato Tecnico e della componente software relativa all’implementazione delle funzionalità richieste deve pertanto

essere autoconsistente

R.CDCN.4

Deve essere possibile implementare la fabric su qualsiasi topologia fisica sottostante ed indipendentemente dall’interconnessione attraverso altri dispositivi non dello stesso vendor,

senza la necessità che i sistemi siano adiacenti

R.CDCN.5

La fabric deve poter essere configurata come una singola entità, ed ogni switch appartenente alla fabric dovrà poter sincronizzare il suo provisioning state in maniera autonoma, con la possibilità di effettuare rollback a stati precedenti.

R.CDCN.6

La Fabric deve poter essere gestita mediante CLI e RESTful API. La gestione mediante CLI/API deve supportare l’utilizzo dei più comuni tool di automazione, come ad es. Ansible o Python.

R.CDCN.7

La fabric deve supportare eventuali situazioni di split-brain senza che ciò impatti sul forwarding del traffico locale. In caso di fabric-stretch su location geografiche differenti, il sistema deve poter continuare a mantenere validi e operativi sia il control plane che il data

plane locali.

R.CDCN.8

La fabric deve supportare meccanismi di:

- Broadcast suppression;

- Conversational forwarding;

- ARP/ND Optimization (possibilità di effettuare proxy ARP se l’informazione è già presente nel DB interno);

- Anycast Gateway (possibilità per gli endpoint di utilizzare lo stesso virtual MAC/Indirizzo IP su tutti i first-hop switch) sia per endpoints IPV4 che IPv6. Le subnet interessate da

funzionalità di anycast gateway dovranno poter essere configurate come un singolo

oggetto atomico fabric-wide. Il numero di istanze VRF con capacità di anycast gateway dovrà essere pari almeno a 1000.

- Multicast routing con trasporto VXLAN attivabile per ciascuna istanza VRF, interoperabile con ricevitori IGMPv2 IGMPv3 e MLD

- Possibilita’ di utilizzare lo stesso VLAN ID in domini distinti sullo stesso switch

- Possibilita’ di associare VLAN ID differenti allo stesso dominio

- Interoperabilita’ con Q-in-Q con possibilita’ di trasporto VxLAN

Le ottimizzazioni di forwarding sopra menzionate devono essere disponibili almeno con riferimento alle seguenti operazioni: bridging, routing, extended bridging (su VxLAN tunnels)

ed extended routing (su VxLAN tunnels).

R.CDCN.9

La fabric deve essere in grado di aggregare link tra due switch mediante meccanismi di Layer2 Multi-pathing e multi chassis/virtual chassis LAG. Tutti gli switch nella fabric dovranno potersi scambiare informazioni topologiche relative ai device adiacenti e dovranno

implementare uno shared endpoint database.

R.CDCN.10

La fabric deve poter implementare:

- Meccanismi STP standard con altri device non appartenenti alla fabric, utilizzando protocolli standard;

- Un meccanismo di loop-guard di livello 2 non basato su STP. Deve cioè essere possibile, senza implementare meccanismi di STP con dispositivi esterni alla fabric, individuare la presenza di loop tra due qualsiasi porte appartenenti alla fabric anche quando le porte

sono ubicate su switch differenti interconnessi localmente o attraverso una rete IP.

R.CDCN.11

Gli switch forniti devono supportare la possibilità di incapsulare e decapsulare in HW il traffico VxLAN mediante meccanismi di VxLAN Tunnel EndPoint (VTEP).

R.CDCN.12

La virtual fabric deve nel complesso supportare funzionalità di VTEP high availability (VTEP HA) attivando funzionalità di VTEP su almeno due switch: la VTEP HA può poter usare lo stesso anycast IP address su entrambi gli switch, ed entrambi gli switch possono incapsulare e decapsulare il traffico VxLAN allo stesso tempo. La funzionalità di VTEP HA deve essere configurabile come un singolo fabric object (non deve richiedere l’effettuazione della

configurazione su ogni singolo switch).

R.CDCN.13

La fabric deve essere dotata di capacità native di interscambio di informazioni con altri nodi all’interno della fabric. In caso di VXLAN, queste informazioni includono almeno:

- I dati di configurazione del VXLAN Tunnel Endpoint (VTEP), ad esempio i VTEP IP address e le Virtual Network Interface (VNIs);

- Le informazioni di raggiungibilità e di routing come i MAC Address, i VTEP IP address, e le informazioni VNI.

R.CDCN.14

La fabric può creare tunnel VxLAN verso altri nodi nella fabric senza utilizzare protocolli basati su multicast.

R.CDCN.15

La fabric deve poter supportare all’interno di una istanza isolata di Sistema Operativo (x.xx in un container o in una VM) l’implementazione di:

- Routing application stacks (OSPF o BGP);

- Interfacce OVSDB;

- Istanze virtual network manager.

I servizi implementati nelle istanze di Sistema Operativo devono poter essere portabili, ovvero migrabili verso nodi differenti della fabric.

R.CDCN.16

La fabric deve supportare a livello fabric-wide funzionalità di:

- Policy-based Routing;

- Access Control;

- Line-rate control, manipolazione e redirezione logica o fisica dei flussi;

- Flow-level Security;

Control Plane Traffic Protection: il traffic di control plane deve essere separabile e gestito con priorità rispetto al traffico di rete. Dovranno essere inoltre implementabili politiche di rate

limiting al fine di mitigare gli effetti di eventuali attacchi di sicurezza.

R.CDCN.17

La fabric dovrà poter estendere eventuali domini Layer 2 su più location geografiche remote, utilizzando protocolli IP standard come VxLAN al fine di garantire l’interoperabilità con

eventuali reti e sistemi di terze parti. Non sono ammesse soluzioni che facciano uso di protocolli o sistemi specializzati per il Data Center Interconnect.

R.CDCN.18

Deve essere possibile realizzare tunnel DC verso altre location a partire da qualsiasi switch nella fabric.

R.CDCN.19

La fabric dovrà poter estendere l’infrastruttura convergente oggetto di acquisizione tra più data center, e dovrà poter raccogliere, organizzare e presentare mediante interfaccia grafica e testuale tutti i dati relativi alle connessioni (a titolo esemplificativo e non esaustivo: end-

to-end latency, duration, total bytes transferred, stato delle connessioni TCP in real time) senza necessità di usare algoritmi di sampling e senza fare uso di wire taps o mirror ports.

R.CDCN.20

In uno scenario multi-tenant, dovrà essere possibile implementare almeno i seguenti servizi:

- Point-to-Point Virtual Connections with HA;

- Multipoint-to-Multipoint Virtual Connections with HA;

- Fully transparent point-to-point pseudo-wires, inclusi i meccanismi di link state tracking e le informazioni di application telemetry.

R.CDCN.21

La fabric dovrà supportare meccanismi avanzati di classificazione del traffico e di QoS e la capacità di regolare il traffico sia a livello di flusso che di porta fisica.

Dovrà essere possibile la tracciatura di qualsiasi flusso di traffico al fine di poter effettuare troubleshooting.

R.CDCN.22

La fabric può organizzare la rete fisica in più reti logiche (Virtual Networks o Tenant) distinte, ognuna dotata delle proprie risorse, servizi di rete e politiche QoS.

Ogni Tenant può avere un singolo punto di management dedicato. Il Fabric Administrator può assegnare l’ownership di ogni singolo tenant ad un amministratore distinto e dotato di credenziali separate, il quale potrà provvedere in autonomia alla gestione e configurazione del Tenant.

Ogni Tenant ha sia data plane che control plane isolati e separati.

R.CDCN.23

La fabric deve implementare meccanismi di Application flow visibility in grado di fornire informazioni su:

- Real-time Correlation tra server e client;

- overlay/underlay Performance analysis;

- Capacity Planning & Network Troubleshooting sia a livello Intra-data center che Inter- data center;

- Security and Incident Response.

R.CDCN.24

Gli switch devono supportare tool di sampling open-source come sFLOW e processi di metering come IPFIX in grado di fornire informazioni di traffico costanti su tutte le interfacce

abilitate.

R.CDCN.25

Deve essere disponibile ed incluso in fornitura un tool grafico di Fabric Management al fine di poter effettuare attività di Network Provisioning, Monitoring and Analytics.

R.CDCN.26

Il tool di management può visualizzare a livello grafico la completa topologia della rete, rappresentando tutti gli elementi che sono parte della fabric e gli eventuali device esterni ad

essa interconnessi.

R.CDCN.27

Attraverso il tool dimanagement deve essere possibile effettuare il provisioning e il monitoraggio di multiple fabric instance, deve essere altresì possibile automatizzare le operazioni relative al deployment iniziale della fabric.

R.CDCN.28

Il tool di management è in grado di effettuare il provisioning ed il monitoraggio dei seguenti costrutti:

- Port characteristics;

- VLANs and port VLAN membership;

- STP characteristics;

- VLAN Interfaces and layer-3 ports;

- OSPF, BGP adjacencies and static routes;

- VxLAN VTEPs and related VxLAN to VLAN mappings;

- Point-to-Point transparent pseudowires;

- Security Policies;

- QoS Policies;

- Mirror objects.

- VRF distribuiti con anycast gateway

Deve essere possibile raccogliere e visualizzare almeno i seguenti dati:

- fabric device model, serial number, transceiver inventory, software version, licensing information;

- fabric device system health, (CPU utilization, disk and memory utilization);

- Physical port counters over time, ingress and egress, con la possibilità di comparare fino a 10 porte nello stesso tempo;

- Endpoint active on each fabric device and related flow information;

- Syslog data;

- SNMP trap.

Il tool deve mettere a disposizione una funzione di packet analytics che consenta la visibilità a livello L4-L7 dei pacchetti dati applicativi utilizzando almeno le seguenti sorgenti di dati:

- file PCAP offline;

	- Traffico real-time.
R.CDCN.29	Il tool di management deve includere una funzionalità di network analytics collector in grado di raccogliere, analizzare e presentare all’utente i dati relative ai flussi applicative di rete, utilizzando almeno le seguenti sorgenti: - Dati di telemetria della fabric; - Altre sorgenti dati come ad es. Netflow, sFlow devono essere supportate. I dati raccolti possono essere presentati in maniera chiara ed utile all’utente mediante grafici a torta, ad istogramma, diagrammi Sankey, ecc anche al fine di consentire l’identificazione di relazioni tra le applicazioni ed il funzionamento dell’infrastruttura fisica e di eventuali colli di bottiglia. Deve essere possibile configurare: - tag personalizzati che dovranno essere memorizzati insieme ai dati al fine di migliorare l’interpretabilità degli stessi da parte degli utenti; - Nomi per specifici valori di porte TCP.	Si
R.CDCN.30	Deve essere possibile integrare il collector database con metadati provenienti da sistemi di terze parti come: server DNS, sistemi di geolocalizzaizone, sistemi di virtualizzazione/iperconvergenza. I dati raccolti possono essere filtrati e ricercabili mediante query specifiche impostate dall’utente.	Si
R.CDCN.31	L’architettura HW deve essere basata su chipset standard-silicon	Si
R.CDCN.32	La topologia fisica della rete è di tipo Spine-Leaf, con rapporto di over subscription non superiore a 3:1 e velocità di accesso alla rete pari ad almeno 25 Gbps;	Si
R.CDCN.33	La velocità di interconnessione tra i layer spine e leaf non deve essere inferiore a 100 Gbps	Si
R.CDCN.34	Gli switch devono essere dotati di alimentatori e ventole ridondati e hot-swap, non devono essere presenti ulteriori single point of failure.	Si
R.CDCN.35	Gli switch devono supportare ONIE per l’utilizzo di sistemi operativi alternativi linux-based;	Si
R.CDCN.36	Gli switch devono supportare Sistemi Operativi di Rete differenti da quelli sviluppati dal produttore degli apparati. L’utilizzo di S.O. diversi non deve inficiare il supporto HW degli apparati;	Si
R.CDCN.37	La dimensione fisica massima di ogni switch deve essere di 1RU	Si
R.CDCN.38	Gli switch di Accesso (Leaf) devono essere dotati delle seguenti caratteristiche: o Almeno 48 porte di accesso ad almeno 25Gbps con connettori SFP28; o Almeno 6 porte di uplink ciascuna a velocità di almeno 100 Gbps QSFP28; o Switching capacity minima 3,6 Tbps, non blocking; o Gli switch devono essere completi di ottiche 10 e 25Gb SR in rapporto di 3:1. Per l’interconnessione dei soli nodi oggetto della presente fornitura saranno usati cavi DAC in rame esclusivamente per le connessioni all’interno dello stesso rack.	Si
R.CDCN.39	Gli switch di Core (Spine) devono essere dotati delle seguenti caratteristiche: o Almeno 32 porte 100Gbps QSFP28 con supporto delle velocità 10/25/40/100 Gbps o superiore; o Forwarding capacity minima: 4400 Mpps (Full Duplex, packet size >350bytes); o Switching capacity minima 6,4 Tbps, non blocking. o Gli switch dovranno essere completi di ottiche 40GbSR per l’interconnessione ai sistemi CI.	Si
R.CDCN.40	Le connessioni tra gli switch spine e leaf devono essere effettuate mediante cavi in fibra ottica. Fanno parte della fornitura le eventuali ottiche e cavi necessari per realizzare tutte le interconnessioni tra spine e leaf e verso tutti i sistemi oggetto della presente fornitura	Si
R.CDCN.41	L’infrastruttura dovrà mettere a disposizione almeno 240 porte, o, un numero di porte sufficiente a garantire il collegamento in rete di tutti i nodi THIN e FAT, del servizio di storage/management dell’infrastruttura HPC e i nodi del sistema IC (Figura 3.1), di accesso di tipologia SFP28	Si

Tabella 3.1.1

3.1.8 Attività di Configurazione dell’infrastruttura CDCN-LE

Dovranno essere descritte tutte le attività necessarie alla realizzazione della soluzione per indirizzare le tematiche dell’installazione delle componenti hardware e software dell’infrastruttura CDCN-LE e per la loro opportuna configurazione.

3.1.8.1 Servizi di Setup Fisico, Cabling e implementazione CDCN

3.1.8.1.1 Consegna ed installazione fisica

I sistemi dovranno essere consegnati in una area messa a disposizione di NANOTEC. Una volta installati gli apparati, i materiali di risulta (imballi) dovranno essere ritirati e smaltiti a norma di legge.

Tutte le attività si intendono comprensive di ogni onere relativo al trasporto, facchinaggio, consegna, installazione, asporto dell’imballaggio e di qualsiasi altra attività ad esse strumentale.

La Società dovrà garantire, durante tutte le fasi di lavorazione, il rispetto delle normative vigenti in materia di tutela della salute e della sicurezza nei luoghi di lavoro per quanto di sua competenza.

3.1.8.1.2 Posizionamento Sistemi e Allacciamenti elettrici

Relativamente al punto in oggetto dovranno essere erogati i seguenti servizi:

- Disimballaggio del materiale e relativo ritiro e smaltimento degli imballi;

- Posizionamento dei sistemi nella posizione definitiva concordata con NANOTEC;

- Installazione fisica dei dispositivi in fornitura del CDCN-LE;

- Connessione all’infrastruttura elettrica.

3.1.8.1.3 Cabling

La Società dovrà procedere allo sviluppo del piano operativo di dettaglio per il posizionamento degli apparati ed il cabling ed alla definizione degli standard di etichettatura da adottare per quanto riguarda la LAN CDCN-LE.

La Società dovrà quindi condividere il piano operativo con il personale NANOTEC e dovrà essere prodotto il GANTT relativo alle attività di Cabling del CDCN-LE.

Il cablaggio da effettuare include:

- Utilizzo di fascette e dispositivi specifici al fine di ottenere un cablaggio a regola d’arte;

- Ethernet cabling e passaggio dei cavi Ethernet tra i rack e verso gli switch di centro-stella e tra gli apparati di rete dei sistemi HPC, CI e sistemi di Storage.

- Il sistema CI dovrà prevedere il cablaggio interno strutturato ed ottimizzato negli spazi direttamente nella fabbrica del produttore hardware.

3.1.8.1.4 Implementazione della Core Datacenter Network (CDCN)

Dovrà essere implementata l’infrastruttura di rete in architettura SDN richiesta, ed in particolare le attività che dovranno essere effettuate sono le seguenti:

- Disegno di dettaglio della soluzione e della sua integrazione verso rete;

- Definizione dell’architettura Spine&leaf della rete CDCN;

- Modalità di integrazione verso la rete esterna;

- Modalità di integrazione verso le componenti di rete dei sistemi HPC, CI e sistemi di Storage;

- Condivisione della lista dei test funzionali ai fini del collaudo che sarà eseguito dal CNR.

Implementazione del disegno architetturale definito e test funzionali pre-rilascio:

- Inizializzazione degli switch;

- Implementazione sistema di controllo della soluzione attraverso una Virtual Appliance;

- Configurazione L2/L3 Spine&Leaf come definito;

- Configurazione delle VLAN necessarie a supportare i servizi storage HPC e sistemi esterni (x.xx Identity Management, ecc.).

Esecuzione dei test funzionali:

- La verifica accerterà che la fornitura, per quanto riguarda il numero e la tipologia dei componenti, tecniche e metodologie impiegate, l’esecuzione e le funzionalità, siano in tutto corrispondenti a quanto previsto dai documenti del capitolato di gara.

3.2 Caratteristiche dell’infrastruttura HPC

L’infrastruttura HPC sarà formata da un sistema di calcolo scalare/parallelo di tipo multi-nodo ossia con, nodi di calcolo “THIN”, nodi di calcolo “FAT” dotati di schede grafiche GPU della famiglia NVIDIA TESLA V100, o superiore, e nodi di servizio (I/O nodes, login node, management e monitoring nodes, etc.), da un’infrastruttura di rete veloce a bassa latenza dei nodi di calcolo basata sul protocollo Infiniband, da un’infrastruttura di rete per il management dedicata al sistema HPC, da un sistema di storage ad alte prestazioni basato e gestito dal cluster filesystem BeeGFS e da un insieme di software necessari per garantire l’operatività complessiva del sistema HPC (suite compilatori, scheduler e resource manager e cluster management system). L’infrastruttura HPC sarà bastata su di un sistema operativo Linux (CentOS o Red Hat Enterprise Linux) e per l’interconnessione veloce IP-Ethernet di rete interna ed esterna al DC-LE utilizzerà l’infrastruttura CDCN-LE descritta del paragrafo precedente.

In particolare si richiede la fornitura di:

Requisito Progettuale Vincolante HPC-LE 1 (RPV-HPC-LE-1)

- Un sistema di Calcolo HPC/GPU (HPC/GPU Cluster, di seguito HPCGC);

- Un sistema di Storage/Cluster File System (HPC Cluster File System, di seguito HPCFS);

- Un sistema di storage Tier2 (Tier2 Storage System, di seguito T2SS);

- Una Infrastruttura Rete Dati di Gestione (Management Data Center Network, di seguito MDCN);

- Infrastruttura di rete per l’interconnessione veloce a bassa latenza dei nodi basata sul protocollo EDR Infiniband;

- Componenti Software di gestione e monitoraggio del sistema: S.O., software di cluster management, job scheduler, ambienti di sviluppo, software di management Out-Of-Band (OOB) dei nodi.

Eventuali altre componenti e servizi, anche se non esplicitamente menzionati ma comunque necessari per la gestione, l’integrazione ed 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. Lo schema logico dell’infrastruttura HPC è riportato in Figura 3.3.

Figura 3.3: Schema logico infrastruttura HPC

3.2.1 Sistema di calcolo HPC/GPU (HPCGC)

L’architettura del sistema di calcolo scalare/parallelo dovrà essere del tipo multi-nodo ossia con nodi di calcolo “THIN”, nodi di calcolo “FAT” dotati di schede grafiche GPU della famiglia NVIDIA TESLA V100, o superiore, e nodi di servizio (I/O nodes, login node, management e monitoring nodes, etc.).

L’architettura del sistema che s’intende realizzare è quella standard di un cluster e sarà quindi costituita dai seguenti componenti:

- Nodi di calcolo così distinti:

o Nodi di calcolo “THIN”

o Nodi di calcolo “FAT” con GPU NVIDIA TESLA V100 o superiore.

o Nodi di Servizio.

- Infrastruttura di rete di management (MDCN) del sistema di calcolo;

- Infrastruttura di rete per l’interconnessione veloce a bassa latenza dei nodi basata sul protocollo EDR Infiniband.

3.2.2 Caratteristiche comuni dei nodi HPCGC

I nodi di calcolo componenti il sistema HPCGC dovranno essere basati su piattaforme altamente integrate e idonee all’ottimizzazione degli spazi, della potenza elettrica assorbita e dissipata.

Il fattore di forma di tutti i nodi dovrà essere rack mount con scheda madre biprocessore con densità non superiore a 1RU/nodo.

L’alimentazione dovrà essere ridondata in modalità 1+1. La caduta di un alimentatore non deve determinare alcuna variazione delle prestazioni e/o della potenza di calcolo generata dai nodi contenuti nello chassis.

La capacità di calcolo max computazionale richiesta dal processore specifico fa riferimento alla theoretical peak performance (Rpeak). Si riferisce al valore in doppia precisione per operazioni in virgola mobile della CPU ed è calcolato in modo teorico tramite la seguente formula:

𝑮𝑭𝑳𝒐𝒑𝒔 = 𝒏𝒄𝒐𝒓𝒆𝒔𝑪𝑷𝑼 ∗ 𝑭𝒓𝒆𝒒𝒖𝒆𝒏𝒄𝒚 ∗ 𝑭𝑳𝒐𝒑𝒔 𝒑𝒆𝒓 𝒄𝒍𝒐𝒄𝒌_𝒄𝒚𝒄𝒍𝒆

Tutti i nodi dovranno essere dotati di un board management controller (BMC) compatibile IPMI versione 2.0 o superiore e Redfish. Il BMC dovrà essere dotato di interfaccia di rete almeno 1Gbps Base-T dedicata.

Il BMC dovrà consentire almeno il monitoraggio delle ventole (se presenti), della temperatura dei processori e scheda madre, la gestione remota dell’alimentazione elettrica e la misura remota della potenza assorbita dal sistema.

Dovranno inoltre essere supportati:

- I protocolli per la gestione remota quali almeno: VNC, Java & HTML5 GUI;

- Funzionalità di virtual console & vMedia;

- funzionalità di scheduling dell’aggiornamento automatico del BIOS e del firmware dei componenti interni;

- Il protocollo Redfish (RESTful API);

- Funzionalità di lock-down della Server Configuration e del Firmware;

- Aggiornamenti Firmware firmati digitalmente;

- Funzionalità di rollback del Firmware;

- Funzionalità di protezione di aggiornamenti firmware dei componenti interni:

- Funzionalità di Secure Default Password;

- Funzionalità di cancellazione sicura di tutti i dispositivi storage interni al server (ISE);

- Supporto Active Directory e autenticazione LDAP;

- Il protocollo SNMP v3;

- Funzionalità di IP Blocking;

- Funzionalità di TLS 1.2 communication.

3.2.3 Caratteristiche dei Nodi di Calcolo “Thin”

Dovranno essere forniti un minimo di 80 nodi “Thin” configurati come descritto nel seguito.

Il singolo chassis del nodo dovrà soddisfare i seguenti requisiti:

- Backplane a dischi in grado di ospitare un minimo di 10 HDD/SSD 2.5” con connessione SAS. Costituirà elemento migliorativo (punteggio) la presenza di slot disco “ibridi” in grado quindi di ospitare anche dischi NVMe (almeno 8).

- Avere un’occupazione minore o uguale ad 1U per singolo nodo.

- Avere alimentatori in classe di efficienza energetica Titanium.

- Essere dotato di minimo 1 slot PCIe x16 Low Profile libero per future espansioni del sistema.

Ogni chassis dovrà inoltre essere dotato di apposito “Cable Management Arm” flessibile per agevolare le operazioni di servizio senza richiedere la rimozione della macchina dal rack in caso di intervento tecnico.

Inoltre, i nodi di calcolo “Thin” dovranno avere le caratteristiche minime descritte di seguito.

3.2.3.1 Processori

Per quanto riguarda i processori, i requisiti minimi che dovranno essere soddisfatti sono i seguenti:

- Ciascun nodo dovrà essere dotato di 2 processori multi-core x86 a 64bit Intel Xeon Gold 6248 o superiore;

- Ogni processore dovrà avere un numero di core fisici maggiore o uguale a 20;

- Frequenza del processore ≥ 2,5 GHz;

- Ogni processore dovrà avere almeno 27,5 MB di cache L3

- La theoretical peak performance del singolo nodo deve essere almeno di 3200 GFLOPS (processori di riferimento Intel Xeon Gold 6248 2.5GHz, 20C/40T).

3.2.3.2 Memoria

I requisiti relativi alla memoria sono i seguenti:

- Ciascun nodo dovrà essere equipaggiato con almeno 192 GB di RAM;

- Ciascun nodo dovrà essere dotato di memorie del tipo DDR-4 registered ECC ed operanti, nel sistema fornito, ad una frequenza effettiva di almeno 2933 MHz;

- I moduli di memoria offerti dovranno essere approvati e certificati dal costruttore della scheda madre;

- I canali di memoria dovranno essere popolati per intero ed in maniera bilanciata (almeno 1 DIMM per canale di ogni CPU) ed in base alle indicazioni fornite sia dal produttore del processore, sia dal produttore della scheda madre al fine di ottenere le prestazioni ottimali;

- Non sarà permesso combinare moduli di memoria con differente dimensione, tipo, velocità o fabbricante.

- Dovrà essere possibile espandere successivamente la memoria del sistema senza rimuovere o sostituire la memoria esistente e popolando sempre per intero ed in maniera bilanciata i canali di memoria delle CP.

3.2.3.3 Storage locale

Considerato che al momento dell’implementazione lo storage locale dei nodi dovrà ospitare unicamente il sistema operativo, ciascun nodo dovrà essere dotato di

o Backplane a disco in grado di ospitare almeno 10 HDD/SSD slot da 2,5”;

o Costituirà elemento migliorativo (punteggio) la presenza di slot disco “ibridi” in grado quindi di ospitare anche dischi NVMe (almeno 8).

o Controller RAID in HW in grado di implementare almeno i livelli RAID 0,1,10,5,50,6,60 e dotato di almeno 8GB cache;

o Nr 1 HDD da 1TB 7200rpm SAS

o Eventuali SSD per l’implementazione della funzionalità BeeOND (cfr.par. 3.2.7)

o nr 2 SSD M.2 SATA in configurazione RAID 1 (implementato in hardware mediante controller DISGIUNTO da quello di cui al punto precedente) cadauno avente capacità minima pari a 240GB.

3.2.3.4 Connettività dei nodi “Thin” all’infrastruttura CDCN-LE

Ciascun nodo dovrà essere dotato di:

- Almeno due porte 25GbE, per l’interconnessione alla Core DataCenter Network le cui caratteristiche sono descritte al paragrafo 3.1. Ogni porta deve garantire il supporto per Switch Indipendent Partitioning (NPAR) fino a 16 partizioni e il supporto dei protocolli RoCE, RoCEv2 e iWARP.

- Almeno una porta 1GbE Base-T afferente alla BMC e connessa alla rete OOB di Cluster Management Network (CMN) le cui caratteristiche sono descritte nel paragrafo 3.2.9.

- Almeno n. 1 scheda di rete a 100Gbps o superiore per interfacciarsi alla rete Infiniband di interconnessione veloce intra cluster di ultima generazione disponibile. Le caratteristiche della rete Infiniband sono descritte nel paragrafo 3.2.6.

Di seguito sono riportati i requisiti minimi obbligatori, a pena di esclusione, dei Nodi Thin.

Nodi Thin – Requisiti Minimi Obbligatori
ID requisito	Descrizione	Richiesta Minima
R.HPC.NT.1	Numero di nodi	80
R.HPC.NT.2	Dimensione dei nodi in termini di Rack Unit	≤ 1 nodo/RU
R.HPC.NT.3	Chassis dotato di alimentatori aventi classe di efficienza energetica Titanium	Si

R.HPC.NT.4

Numero Slot PCIe x16 Low-Profile liberi per futura espansione del sistema

Board Management Controller

R.HPC.NT.5

Interfaccia BMC con porta dedicata ad 1Gbps

R.HPC.NT.6

La BMC deve supportare almeno:

- I protocolli per la gestione remota quali almeno: VNC, Java & HTML5 GUI;

- Funzionalità di virtual console & vMedia;

- funzionalità di scheduling dell’aggiornamento automatico del BIOS e del firmware dei componenti interni;

- Il protocollo Redfish (RESTful API);

- Funzionalità di lock-down della Server Configuration e del Firmware;

- Aggiornamenti Firmware firmati digitalmente;

- Funzionalità di rollback del Firmware;

- Funzionalità di protezione di aggiornamenti firmware dei componenti interni:

- Funzionalità di Secure Default Password;

- Funzionalità di cancellazione sicura di tutti i dispositivi storage interni al server (ISE);

- Supporto Active Directory e autenticazione LDAP;

- Il protocollo SNMP v3;

- Funzionalità di IP Blocking;

- Funzionalità di TLS 1.2 communication.

CPU

R.HPC.NT.7

Il nodo è dotato di N. 2 CPU da almeno 20c, 2.5GHz, 27,5MB cache L3

R.HPC.NT.8

La theoretical peak performance del singolo nodo deve essere almeno di 3200 GFLOPS (processori di riferimento Intel Xeon Gold 6248 2.5GHz, 20C/40T).

Memoria

R.HPC.NT.9

Quantità di memoria RAM installata

192GB

R.HPC.NT.10

Ciascun nodo dovrà essere dotato di memorie del tipo DDR-4 registered ECC ed operanti, nel sistema fornito, ad una frequenza effettiva di almeno 2933 MHz; I moduli di memoria offerti dovranno essere approvati e certificati dal costruttore della scheda madre;

R.HPC.NT.11

I canali di memoria dovranno essere popolati per intero ed in maniera bilanciata (almeno 1 DIMM per canale di ogni CPU) ed in base alle indicazioni fornite sia dal produttore del processore, sia dal produttore della scheda madre al fine di ottenere le prestazioni ottimali

R.HPC.NT.12

Dovrà essere possibile espandere successivamente la memoria del sistema senza rimuovere o sostituire la memoria esistente e popolando sempre per intero ed in maniera bilanciata i canali di memoria delle CPU

Storage

R.HPC.NT.13

Backplane a disco in grado di ospitare un minimo di 10 HDD/SSD 2.5” con connessione SAS.

R.HPC.NT.14

Nr 1 HDD da 1TB 7200rpm SAS. Controller RAID in HW in grado di implementare almeno i livelli RAID 0,1,10,5,50,6,60 e dotato di almeno 8GB cache

R.HPC.NT.15

Nr 2 SSD M.2 SATA in configurazione RAID 1 (implementato in hardware mediante controller DISGIUNTO da quello di cui al requisito precedente) cadauno avente capacità minima pari a

240GB

Connettività

R.HPC.NT.16

Due porte 25GbE SFP28. Ogni porta deve garantire il supporto per Switch Independent

	Partitioning (NPAR) fino a 16 partizioni e il supporto dei protocolli RoCE, RoCEv2 e iWARP.
R.HPC.NT.17	1 scheda di rete a 100Gbps con supporto del protocollo Infiniband EDR	Si

Tabella 3.2.1

3.2.4 Caratteristiche dei Nodi di Calcolo “Fat” con GPU

Dovranno essere forniti un minimo di 8 nodi “Fat” con GPU configurati come descritto nel seguito.

Il singolo chassis del nodo dovrà soddisfare i seguenti requisiti:

- Assenza di backplane dischi al fine di minimizzare pesi e consumi, e migliorare l’efficienza del raffreddamento.

- Avere un’occupazione pari ad 1U per singolo nodo.

Inoltre, i Nodi di Calcolo “Fat” con GPU dovranno avere le caratteristiche minime descritte di seguito.

3.2.4.1 Processori

Per quanto riguarda i processori, i requisiti minimi che dovranno essere soddisfatti sono i seguenti:

- Ciascun nodo dovrà essere dotato di 2 processori multi-core x86 a 64bit Intel Xeon Gold 6230 o superiore;

- Ogni processore dovrà avere un numero di core fisici di almeno 20;

- La frequenza del processore dovrà essere ≥ 2 GHz;

- Ogni processore dovrà avere almeno 27 MB di cache L3

- La theoretical peak performance del singolo nodo deve essere almeno di 2688 GFLOPS (processori di riferimento Intel Xeon Gold 6230 2.1GHz, 20C/40T).

3.2.4.2 Memoria

I requisiti relative alla memoria sono i seguenti:

- Ciascun nodo dovrà essere equipaggiato con almeno 384 GB di RAM;

- Ciascun nodo dovrà essere dotato di memorie del tipo DDR-4 registered ECC ed operanti, nel sistema fornito, ad una frequenza effettiva di almeno 2933 MHz;

- I moduli di memoria offerti dovranno essere approvati e certificati dal costruttore della scheda madre;

- I canali di memoria delle CPU dovranno essere popolati interamente ed in maniera bilanciata (almeno 1 DIMM per canale di ogni CPU) ed in base alle indicazioni fornite sia dal produttore del processore, sia dal produttore della scheda madre al fine di ottenere le prestazioni ottimali;

- Non sarà permesso combinare moduli di memoria con differente dimensione, tipo, velocità o fabbricante.

3.2.4.3 Storage locale

Ciascun nodo dovrà essere dotato di nr. 2 SSD in configurazione RAID 1 (implementato in hardware) su scheda dedicata cadauno avente capacità minima pari a 480GB.

3.2.4.4 GPU

Ogni nodo dovrà essere equipaggiato con N.4 GPU nVIdia con architettura Volta modello Tesla V100 SXM2 (o superiore) cadauna dotata di interconnessione nVLink ed almeno 16 GB di memoria RAM.

Le GPU dovranno essere interconnesse alle CPU in maniera bilanciata (2 GPU per ogni CPU), e cadauna mediante un canale di tipo PCIe x16 dedicato e non condiviso con altri dispositivi

3.2.4.5 Connettività nodi “Fat” all’infrastruttura CDCN-LE

Ciascun nodo dovrà essere dotato di:

- Almeno due porte 25GbE SFP28, per l’interconnessione alla Core DataCenter Network le cui caratteristiche sono descritte al paragrafo 3.1.

- Almeno una porta 1GbE Base-T afferente alla BMC e connessa alla rete OOB di Cluster Management Network (CMN) le cui caratteristiche sono descritte nel paragrafo 3.2.9.

- Almeno n. 1 scheda di rete per interfacciarsi alla rete Infiniband di interconnessione veloce intra cluster di ultima generazione disponibile. Le caratteristiche della rete Infiniband sono descritte nel paragrafo 3.2.6.

Di seguito sono riportati i requisiti minimi obbligatori dei Nodi Fat.

Nodi FAT – Requisiti Minimi Obbligatori

ID requisito

Descrizione

Richiesta Minima

R.HPC.NF.1

Numero di nodi

R.HPC.NF.2

Dimensione dei nodi in termini di Rack Unit

≤ 1 nodo/RU

Board Management Controller

R.HPC.NF.3

Interfaccia BMC con porta dedicata ad 1Gbps

R.HPC.NF.4

La BMC deve supportare almeno:

- I protocolli per la gestione remota quali almeno: VNC, Java & HTML5 GUI;

- Funzionalità di virtual console & vMedia;

- funzionalità di scheduling dell’aggiornamento automatico del BIOS e del firmware dei componenti interni;

- Il protocollo Redfish (RESTful API);

- Funzionalità di lock-down della Server Configuration e del Firmware;

- Aggiornamenti Firmware firmati digitalmente;

- Funzionalità di rollback del Firmware;

- Funzionalità di protezione di aggiornamenti firmware dei componenti interni:

- Funzionalità di Secure Default Password;

- Funzionalità di cancellazione sicura di tutti i dispositivi storage interni al server (ISE);

- Supporto Active Directory e autenticazione LDAP;

- Il protocollo SNMP v3;

- Funzionalità di IP Blocking;

- Funzionalità di TLS 1.2 communication.

CPU

R.HPC.NF.5

Il nodo è dotato di N. 2 CPU da almeno 20c, 2.1GHz, 27,5MB cache L3

R.HPC.NF.6

La theoretical peak performance del singolo nodo deve essere almeno di 2688 GFLOPS (processori di riferimento Intel Xeon Gold 6230 2.1GHz, 20C/40T).

Memoria

R.HPC.NF.7

Quantità di memoria RAM installata

384GB

R.HPC.NF.8

Ciascun nodo dovrà essere dotato di memorie del tipo DDR-4 registered ECC ed operanti, nel sistema fornito, ad una frequenza effettiva di almeno 2666 MHz; I moduli di memoria offerti dovranno essere approvati e certificati dal costruttore della scheda madre;

R.HPC.NF.9

ottimali

R.HPC.NF.10

Storage

R.HPC.NF.11

Assenza di dischi e di backplane a disco.

Opzionale

R.HPC.NF.12

Nr 2 SSD M.2 SATA in configurazione RAID 1 (implementato in hardware mediante controller DISGIUNTO da quello di cui al requisito precedente) su scheda dedicata cadauno avente capacità minima pari a 480GB

GPU

R.HPC.NF.13	N.4 GPU nVIdia con architettura Volta modello Tesla V100 SXM2 (o superiore) cadauna dotata di interconnessione nVLink ed almeno 16 GB di memoria RAM	Si
R.HPC.NF.14	GPU interconnesse alle CPU in maniera bilanciata (2 GPU per ogni CPU), e cadauna mediante un canale di tipo PCIe x16 dedicato e non condiviso con altri dispositivi	Si
Connettività
R.HPC.NF.15	Due porte 25GbE SFP28.	Si
R.HPC.NF.16	1 scheda di rete a 100Gbps con supporto del protocollo Infiniband EDR	Si

Tabella 3.2.2

3.2.5 Caratteristiche dei Nodi di Servizio

Il sistema dovrà essere dotato di un minimo di 3 Nodi di Servizio, configurati come meglio descritto nel seguito.

I Nodi di Servizio dovranno avere configurazione identica ai nodi di calcolo “Thin”, (cfr. par. 3.2.3) tranne che per la configurazione delle seguenti componenti:

- Storage locale:

o Ciascun nodo dovrà essere dotato di backplane a disco in grado di ospitare almeno 10 HDD/SSD slot da 2,5”;

o Ciascun nodo dovrà essere dotato di controller RAID in HW in grado di implementare almeno i livelli RAID 0,1,10,5,50,6,60 e dotato di almeno 8GB cache;

o ciascun nodo dovrà essere dotato di nr 2 HDD 7200rpm SAS in configurazione RAID 1 cadauno avente capacità minima pari a 1TB;

o nr 2 SSD M.2 SATA in configurazione RAID 1 (implementato in hardware mediante controller DISGIUNTO da quello di cui al punto precedente) cadauno avente capacità minima pari a 240GB

- Quantità di memoria installata a bordo come meglio descritto al par. 3.2.5.1.

3.2.5.1 Memoria

I requisiti relative alla memoria sono i seguenti:

- Ciascun nodo dovrà essere dotato di memorie del tipo DDR-4 registered ECC ed operanti, nel sistema fornito, ad una frequenza effettiva di almeno 2666 MHz;

- I moduli di memoria offerti dovranno essere approvati e certificati dal costruttore della scheda madre;

- Non sarà permesso combinare moduli di memoria con differente dimensione, tipo, velocità o fabbricante.

- Ciascun nodo dovrà essere equipaggiato con la quantità minima di memoria indicata nella Tabella 3.2.3 sottostante:

	Login node	Management node	Monitoring node
Numero di nodi richiesti	1	1	1
Memoria	Almeno 384 GB	Almeno 192 GB	Almeno 192 GB

Tabella 3.2.3

Di seguito sono riportati i requisiti minimi obbligatori dei Nodi di Servizio.

Nodi Servizio – Requisiti Minimi Obbligatori
ID requisito	Descrizione	Richiesta Minima
R.HPC.NS.1	Numero di nodi	3
R.HPC.NS.2	Dimensione dei nodi in termini di Rack Unit	≤ 1 nodo/RU
R.HPC.NS.3	Chassis dotato di alimentatori aventi classe di efficienza energetica Titanium	Si

R.HPC.NS.4

Numero Slot PCIe x16 Low-Profile liberi per futura espansione del sistema

Board Management Controller

R.HPC.NS.5

Interfaccia BMC con porta dedicata ad 1Gbps

R.HPC.NS.6

La BMC deve supportare almeno:

- I protocolli per la gestione remota quali almeno: VNC, Java & HTML5 GUI;

- Funzionalità di virtual console & vMedia;

- funzionalità di scheduling dell’aggiornamento automatico del BIOS e del firmware dei componenti interni;

- Il protocollo Redfish (RESTful API);

- Funzionalità di lock-down della Server Configuration e del Firmware;

- Aggiornamenti Firmware firmati digitalmente;

- Funzionalità di rollback del Firmware;

- Funzionalità di protezione di aggiornamenti firmware dei componenti interni:

- Funzionalità di Secure Default Password;

- Funzionalità di cancellazione sicura di tutti i dispositivi storage interni al server (ISE);

- Supporto Active Directory e autenticazione LDAP;

- Il protocollo SNMP v3;

- Funzionalità di IP Blocking;

- Funzionalità di TLS 1.2 communication.

CPU

R.HPC.NS.7

Il nodo è dotato di N. 2 CPU da almeno 20c, 2.5GHz, 27,5MB cache L3

R.HPC.NS.8

La theoretical peak performance del singolo nodo deve essere almeno di 3200 GFLOPS (processori di riferimento Intel Xeon Gold 6248 2.5GHz, 20C/40T).

Memoria

R.HPC.NS.9

Quantità di memoria RAM installata

192GB su 2

nodi 384GB su un

nodo

R.HPC.NS.10

R.HPC.NS.11

R.HPC.NS.12

Storage

R.HPC.NS.13

Backplane a disco in grado di ospitare un minimo di 10 HDD/SSD 2.5” con connessione SAS.

R.HPC.NS.14

Nr 2 HDD da 1TB 7200rpm SAS. Controller RAID in HW in grado di implementare almeno i livelli RAID 0,1,10,5,50,6,60 e dotato di almeno 8GB cache

R.HPC.NS.15

Nr 2 SSD M.2 SATA in configurazione RAID 1 (implementato in hardware mediante controller DISGIUNTO da quello di cui al requisito precedente) cadauno avente capacità minima pari a

240GB

Connettività

R.HPC.NS.16	Due porte 25GbE SFP28. Ogni porta deve garantire il supporto per Switch Independent Partitioning (NPAR) fino a 16 partizioni e il supporto dei protocolli RoCE, RoCEv2 e iWARP.	Si
R.HPC.NS.17	1 scheda di rete a 100Gbps con supporto del protocollo Infiniband EDR	Si

Tabella 3.2.4

3.2.6 Infrastruttura di rete per l’Interconnessione veloce e a bassa latenza

Al fine di interconnettere tutti i nodi del sistema HPCGC, si richiede la fornitura di tutti i necessari componenti hardware e software per la realizzazione di una rete veloce e a bassa latenza basata su protocollo Infiniband almeno EDR a 100Gbps, con un rapporto di over-subscription non superiore a 2:1.

Per la realizzazione di tale rete, le interfacce di rete, gli apparati di switching ed i cavi dovranno essere dello stesso produttore e certificati per il mutuo utilizzo.

Sistema di interconnessione veloce e a bassa latenza – Requisiti Minimi Obbligatori

ID requisito

Descrizione

Richiesta Minima

R.HPC.EDR.1

Fornitura di tutti i necessari componenti hardware e software per la realizzazione di una rete veloce e a bassa latenza basata su protocollo Infiniband almeno EDR a

100Gbps, con un rapporto di over-subscription non superiore a 2:1.

Tabella 3.2.5

3.2.7 Sistema di Storage/Cluster File System (HPCFS)

Il sistema di calcolo HPCGC dovrà essere dotato di un sistema di storage HPC (HPCFS) dedicato, composto dall’integrazione di una infrastruttura HW con la soluzione software di Cluster File System basata sul Cluster File System BeeGFS.

Lo spazio disco utile fornito da tale sistema sarà utilizzato unicamente come “spazio di lavoro” (scratch file system) per memorizzare temporaneamente i risultati delle elaborazioni numeriche che saranno eseguite sul sistema HPCGC.

Per tale motivo, il sistema HPCFS dovrà garantire elevate prestazioni in termini di I/O anche in presenza di un elevato numero di richieste concorrenti.

Il sistema di storage HPCFS dovrà soddisfare le seguenti caratteristiche e funzionalità:

- Capacità utile complessiva pari ad almeno 1 PetaBytes;

- Performance aggregate di I/O sul file system pari ad almeno 10 GByte/sec sia in lettura che scrittura sequenziale, su file aventi dimensione aggregata pari ad almeno 3 volte la somma delle memorie RAM dei nodi componenti l’infrastruttura HPCFS.

- Interconnessione alla rete a bassa latenza di cui al par. 3.2.6 e alla rete del CDCN-LE.

Inoltre, a livello hardware, il sistema di storage HPC dovrà soddisfare le seguenti caratteristiche e funzionalità:

- Possibilità di espandere il sistema in termini di scalabilità verticale od orizzontale;

- Alimentatori e ventole ridondati e hot-swap

- gestione dei dischi guasti con sistema a doppia sicurezza di tipo “hot spare” e/o “distributed spare” ed in ogni caso con sostituzioni a caldo;

- L’area storage per i metadati dovrà essere implementata utilizzando dischi SSD opportunamente raggruppati;

- Tutti dispositivi forniti, inclusi gli hard-disk, dovranno essere di tipo “enterprise”, ovvero certificati per l’uso H24;

- I sottosistemi o controller storage dovranno avere funzionalità in grado di garantire l’assoluta consistenza dei dati in caso di fault come, ad esempio, il “destaging” dei dati presenti in cache prima dello spegnimento in caso di assenza di alimentazione elettrica;

- Gli apparati dovranno avere funzionalità di auto-diagnosi o essere interconnessi ad un sistema di rilevamento dei fault, al fine di informare tempestivamente gli amministratori del sistema di eventuali guasti.

Infine, a livello software, il sistema di storage HPC proposto dovrà soddisfare le seguenti caratteristiche e funzionalità:

- Dovrà essere implementata la componente di management su di un nodo separato (a tale scopo potrà essere utilizzato uno dei Nodi di Servizio)

- prestazioni elevate, parallelizzazione degli accessi e bilanciamento del carico sia a livello dei dati che dei metadati;

- compatibilità, a livello di file system, allo standard POSIX ed ai linux kernel;

- Esecuzione nello user space del S.O. e non nel kernel space.

La soluzione offerta deve comprendere altresì tutte le componenti software e licenze, necessarie a garantire la messa in esercizio e il funzionamento dello spazio disco di lavoro del sistema di calcolo parallelo HPCGC, nel rispetto delle

funzionalità e dei requisiti minimi sopra descritti.

La soluzione software offerta deve essere inclusiva del supporto ufficiale del produttore/manutentore del software BeeGFS. Non è ammesso fornire soluzioni con supporto di tipo community o più in generale non commerciale.

Di seguito sono riportati i requisiti minimi obbligatori del Sistema HPCFS.

Sistema HPCFS – Requisiti Minimi Obbligatori

ID requisito

Descrizione

Richiesta Minima

R.HPC.CFS.1

Capacità minima utile

1 PetaBytes

R.HPC.CFS.2

Performance aggregate di I/O sul file system sia in lettura che scrittura sequenziale, su file aventi dimensione aggregata pari ad almeno 3 volte la somma delle memorie RAM dei nodi componenti l’infrastruttura HPCFS.

10 GBps

R.HPC.CFS.3

Soluzione basata su Cluster File System BeeGFS

R.HPC.CFS.4

L’area storage per i metadati dovrà essere implementata utilizzando dischi SSD opportunamente raggruppati

R.HPC.CFS.5

La soluzione si interconnette alla rete a bassa latenza di cui al par. 3.2.6 e alla rete del CDCN-LE

R.HPC.CFS.6

La BMC dei nodi componenti il sistema deve supportare almeno:

- I protocolli per la gestione remota quali almeno: VNC, Java & HTML5 GUI;

- Funzionalità di virtual console & vMedia;

- funzionalità di scheduling dell’aggiornamento automatico del BIOS e del firmware dei componenti interni;

- Il protocollo Redfish (RESTful API);

- Funzionalità di lock-down della Server Configuration e del Firmware;

- Aggiornamenti Firmware firmati digitalmente;

- Funzionalità di rollback del Firmware;

- Funzionalità di protezione di aggiornamenti firmware dei componenti interni:

- Funzionalità di Secure Default Password;

- Funzionalità di cancellazione sicura di tutti i dispositivi storage interni al server (ISE);

- Supporto Active Directory e autenticazione LDAP;

- Il protocollo SNMP v3;

- Funzionalità di IP Blocking;

- Funzionalità di TLS 1.2 communication.

Scalabilità

R.HPC.CFS.7

Possibilità di espandere il sistema in termini di scalabilità verticale od orizzontale

Resilienza

R.HPC.CFS.8

Alimentatori e ventole ridondati e hot-swap

R.HPC.CFS.9

Gestione dei dischi guasti con sistema a doppia sicurezza di tipo “hot spare” e/o “distributed spare” ed in ogni caso con sostituzioni a caldo

R.HPC.CFS.10

I sottosistemi o controller storage dovranno avere funzionalità in grado di garantire l’assoluta consistenza dei dati in caso di fault come, ad esempio, il “destaging” dei dati presenti in cache prima dello spegnimento in caso di assenza di alimentazione elettrica;

R.HPC.CFS.11

Tutti dispositivi forniti, inclusi gli hard-disk, dovranno essere di tipo “enterprise”, ovvero certificati per l’uso H24

Funzionalità Software

R.HPC.CFS.12

La componente di Management è implementata su di un nodo separato

R.HPC.CFS.13

Parallelizzazione degli accessi e bilanciamento del carico sia a livello dei dati che dei metadati;

R.HPC.CFS.14

Compatibilità, a livello di file system, allo standard POSIX ed ai Linux kernel

R.HPC.CFS.15

Esecuzione delle componenti software nello user space del S.O. e non nel kernel space

R.HPC.CFS.16

La soluzione software offerta deve essere inclusiva del supporto ufficiale del

produttore/manutentore del software BeeGFS

Tabella 3.2.6

3.2.8 Sistema di Storage Tier2 (T2SS)

Requisito Progettuale Vincolante HPC-LE 2 (RPV-HPC-LE-2)

Il sistema di calcolo HPCGC dovrà essere dotato di un sistema di storage Tier2 (T2SS) dedicato attraverso una partizione del sistema Tier2 dell’infrastruttura CI come descritto nel 3.3.6.

Il sistema proposto dovrà essere una soluzione per la gestione di dati non strutturati ad accesso file level mediante servizi erogati attraverso rete Ethernet su protocolli IP e con caratteristiche tali da essere classificabile sotto la denominazione di sistema Network Attached Storage. Dovranno essere erogabili tutti i protocolli principali tipici delle soluzioni NAS e dovranno poter essere ospitati contemporaneamente anche nuovi e innovativi ambienti applicativi, di seguito elencati i protocolli richiesti:

- NFS

- CIFS/SMB

- FTP

- HTTP

- HDFS

- SWIFT

- NDMP

- Rest API

La dimensione della partizione T2SS del sistema Tier2 dell’infrastruttura CI sarà definita con il personale NANOTEC in fase di configurazione del sistema.

3.2.9 Management Data Center Network (MDCN)

Al fine di rendere possibile il management di tutti i dispositivi oggetto del seguente capitolato, si richiede la fornitura di una rete di management Out-Of-Band. Tale rete interconnetterà tutte le BMC e le interfacce di management dei sistemi HW in fornitura e dovrà essere logicamente ed elettricamente disgiunta dalla rete di produzione.

La tipologia di rete richiesta è Ethernet con velocità di accesso di almeno 1Gbps e l’infrastruttura MDCN dovrà mettere a disposizione un numero di porte tale da interconnettere con almeno 1 link fisico ogni componente della fornitura dotato di BMC o altro sistema di management integrato, ed un opportuno numero di porte di uplink/mutua interconnessione aventi velocità minima 10Gbps.

La fornitura dell’infrastruttura MDCN dovrà comprendere tutti i cavi necessari per il cablaggio dovranno essere descritte tutte le attività necessarie alla realizzazione ed implementazione (VLAN, configurazioni, etc.).

3.2.10 Software

In merito alla componente software è richiesto, salvo dove diversamente indicato, l’utilizzo di componenti Open Source e dotati di supporto community al fine di minimizzare i costi operativi del sistema HPC a scadenza della manutenzione offerta in gara.

3.2.10.1 Sistema Operativo

Il sistema operativo impiegato sui nodi di calcolo e, più in generale sulle entità del cluster HPCGC, dovrà essere un Sistema Operativo Linux x86_64 di ultima generazione di tipo CentOS o Red Hat Enterprise Linux.

3.2.10.2 Ambienti di sviluppo

Dovranno essere forniti gli strumenti Open Source per lo sviluppo e il debugging di codici seriali e paralleli installati di default con il S.O.:

- Compilatori Fortran;

- Compilatori C e C++;

- Perl;

- Python nell’ultima versione disponibile per l’architettura.

Dovrà inoltre essere fornita una licenza fino a 3 utenti contemporanei, della suite “Intel Parallel Studio XE Professional Edition for Fortran and C++ Linux” che include: C++ Compiler, Fortran Compiler, Distribution for Python, DAA library, IPP, TBB, MKL, OpenMP, Advisor, Inspector, VTune Amplifier, e tutti gli environment modules per la gestione e configurazione dei path di software, librerie e tools HPC.

Gli strumenti proposti dovranno consentire la compilazione e l’installazione delle principali librerie per il calcolo scientifico.

3.2.10.3 Scheduler e Resource Manager

Per l’implementazione delle funzionalità di Scheduling e Resource Management dovrà essere impiegato il software PBS Professional Open Source (xxxx://xxx.xxxxxx.xxx/) o altro equivalente Open Source in grado di garantire:

- La sottomissione di job seriali/paralleli e la gestione dell'allocazione delle risorse.

- Massima efficienza e produttività nella gestione dei job utente;

- Ottimizzazione statica e dinamica dell’allocazione delle risorse;

- Definizione e gestione di un sistema di code;

- Gestione di job seriali, paralleli ed ibridi openMP / MPI,;

- Gestione delle priorità dei job;

- Possibilità di sospendere i job;

- Possibilità di implementare differenti policy di scheduling;

- Possibilità di garantire priorità a classi di job e/o utenti;

- Consentire l’implementazione di workflow complessi di job (catene operative);

- Staging intelligente dei dati di input;

- Analisi statistica dell’utilizzo delle risorse (accounting su base temporale arbitraria per gruppi, utenti e progetti ed altro).

3.2.10.4 Cluster Management System (CMS)

Per l'installazione e la messa in opera del cluster dovrà essere utilizzato un software OpenSource in grado di gestire il provisioning, il monitoraggio, la gestione del cluster e garantire la continua operatività del cluster fornendo soluzioni di recovery e deploy dei nodi del cluster.

In particolare, la soluzione software fornita:

- Dovrà interfacciarsi sia con la CDCN, sia con la Management Datacenter Network (MDCN);

- Dovrà essere installata su 2 Nodi di Servizio per operare in modalità active/passive garantendo quindi la disponibilità del servizio;

- Dovrà gestire i principali dispositivi del cluster HPCGC;

- Dovrà fornire un'interfaccia web oriented (GUI) compatibile con i principali browser oltre che un'interfaccia command line (CLI);

- Dovrà gestire le principali distribuzioni linux come ad esempio Red Hat Enterprise Linux, SUSE, CentOS, Scientific Linux, Ubuntu Server Long Term e fornire funzionalità di gestione degli aggiornamenti;

- Dovrà fornire funzionalità di monitoraggio completo che consentano agli amministratori di sistema di controllare il sistema HPC e i dispositivi connessi;

- Dovrà essere in grado di rilevare situazioni di allarme o pre-allarme e, secondo modalità personalizzabili, informare gli amministratori di sistema oltre che attivare delle azioni predefinite (triggers alerts e triggers actions);

- Dovrà fornire una serie completa di strumenti per consentire agli amministratori di sistema di sviluppare, sottoporre a debug e distribuire librerie e codice HPC;

- Dovrà interfacciarsi con i principali protocolli in uso nei sistemi di Identity and Access Management (LDAP e Active Directory).

3.2.11 Attività di Installazione ed Implementazione dell’infrastruttura HPC

Dovranno essere descritte tutte le attività necessarie alla realizzazione della soluzione per indirizzare le tematiche

dell’installazione delle componenti hardware e software dell’infrastruttura HPC e per la loro opportuna configurazione.

3.2.11.1 Consegna ed installazione fisica

I sistemi dovranno essere consegnati al piano in una area messa a disposizione di NANOTEC. Una volta installati gli apparati, i materiali di risulta (imballi) dovranno essere ritirati e smaltiti a norma di legge.

Tutte le attività si intendono comprensive di ogni onere relativo al trasporto, facchinaggio, consegna “al piano”, installazione, asporto dell’imballaggio e di qualsiasi altra attività ad esse strumentale.

3.2.11.2 Servizi di Setup Fisico e Cabling

3.2.11.2.1 Posizionamento Sistemi e Allacciamenti elettrici

Relativamente al punto in oggetto dovranno essere erogati i seguenti servizi:

- Disimballaggio del materiale e relativo ritiro e smaltimento degli imballi;

- Posizionamento dei sistemi nella posizione definitiva concordata con NANOTEC;

- Installazione fisica dei dispositivi in fornitura (Server/storage/networking);

- Connessione delle PDUs all’infrastruttura elettrica.

3.2.11.2.2 Cabling

La Società dovrà procedere allo sviluppo del piano operativo di dettaglio per il posizionamento dei server ed il cabling ed alla definizione degli standard di etichettatura da adottare per quanto riguarda:

- Cabling LAN CDCN;

- Cabling Infiniband;

- Cabling MDCN.

La Società dovrà quindi condividere il piano operativo con il personale NANOTEC e dovrà essere prodotto il GANTT relativo alle attività di Cabling.

Il cablaggio da effettuare include:

- Cablaggio Infiniband Fat tree con interconnessione verso i core Switch;

- Utilizzo di fascette e dispositivi specifici al fine di ottenere un cablaggio a regola d’arte;

- Ethernet cabling (LAN CDCN, MDCN) e passaggio dei cavi Ethernet tra i racks e verso gli switch di centro-stella.

Ogni tipo di cavo (Infiniband Copper, Infiniband Fiber, Power, Giga Ethernet rame e fibra) dovrà essere steso e raccolto al fine di facilitare il passaggio dell’aria ed il raffreddamento dei dispositivi.

Inoltre, ogni cavo dovrà essere etichettato su ambo i lati per facilitare la manipolazione.

3.2.11.3 Implementazione reti di interconnessione MDCN e Infiniband

Dovranno essere implementate le reti MDCN e Infiniband mediante le seguenti attività:

Fase di Planning:

- Disegno di dettaglio dell’architettura di rete;

- Definizione delle modalità di integrazione della MDCN verso la rete esterna;

- Definizione delle modalità di integrazione delle componenti del Cluster HPC.

Implementazione del disegno architetturale definito:

- Inizializzazione degli swtich;

- Configurazione come definito dal disegno architetturale;

- Implementazione sistema di gestione dell’infrastruttura Infiniband.

3.2.11.4 Implementazione e collegamento alla Core Datacenter Network (CDCN)

Dovrà essere implementata l’infrastruttura di rete in architettura SDN richiesta, ed in particolare le attività che dovranno essere portate avanti sono le seguenti:

- Disegno di dettaglio della soluzione e della sua integrazione verso rete;

- Definizione collegamenti dell’architettura Spine&leaf della rete CDCN;

- Modalità di integrazione verso la rete esterna;

- Modalità di integrazione verso le reti LAN di gestione MDCN e le componenti del Cluster HPC;

- Condivisione della lista dei test funzionali ai fini del collaudo che sarà eseguito dal CNR.

Implementazione del disegno architetturale definito e test funzionali pre-rilascio:

- Inizializzazione degli switch;

- Implementazione sistema di controllo della soluzione attraverso una Virtual Appliance;

- Configurazione L2/L3 Spine&Leaf come definito;

- Configurazione delle VLAN necessarie a supportare i servizi storage HPC e sistemi esterni (x.xx Identity Management, ecc.).

Esecuzione dei test funzionali:

3.2.11.5 Installazione dei Nodi di Calcolo e di Servizio

La Società dovrà installare e configurare il sistema di management inclusivo delle componenti software per il deployment dei nodi di calcolo e di servizio.

Tramite tale software verrà installato il sistema operativo CentOS o Red Hat Enterprise Linux sui nodi, i server di management e gli eventuali I/O nodes per la gestione dello storage

In particolare La Società dovrà eseguire le seguenti attività:

- Installazione e configurazione dei nodi di management;

- Installazione e configurazione del software di management;

- Installazione e configurazione degli eventuali I/O nodes;

- Preparazione e test di installazione di 1 nodo di calcolo facente parte dei “Compute nodes” (gold Image)

- Installazione e configurazione del sistema operativo CentOS o Red Hat Enterprise Linux sui Nodi di Calcolo tramite il software di cluster management:

o Configurazione driver specifici;

o Installazione e configurazione interfacce di rete Ethernet e Infiniband;

o Installazione dei driver e tool specifici per InfiniBand (OFED): driver, tool diagnostica.

- Cluster command tool: per esecuzione di comandi cluster-wide;

- Gestione centralizzata degli utenti (NIS/AD/LDAP);

- Configurazione rete cluster;

- Configurazione servizi come SSH, NTP, DNS ecc.;

- Resource/Queue manager e gestione delle linee di calcolo;

- Implementazioni MPI (openMPI, mvapich) e OpenMP per compilatore standard GNU;

- Installazione Compilatori Intel;

- Tool per benchmarking del sistema: HPL e Intel MPI Benchmark;

- Compilazione e configurazione di driver e tool specifici per InfiniBand (OFED): driver, tool diagnostici.

3.2.11.6 Implementazione Sistemi di Storage

La Società dovrà prendersi carico di installare e configurare i sistemi di storage HPCFS e T2SS (partizione T2SS del sistema Tier2 dell’infrastruttura CI) come richiesto dal capitolato tecnico. Le attività previste sono le seguenti:

- Disimballaggio ed installazione fisica dei sistemi;

- Cablaggio alla rete elettrica ed alle reti dati di tutte le componenti;

- Disegno di dettaglio soluzione;

- Definizione dell’architettura di dettaglio Storage HPCFS;

- Definizione modalità di integrazione verso la rete MDCN e CDCN;

- Definizione modalità di integrazione all’interno del Cluster HPC;

- Implementazione del disegno architetturale definito;

- Inizializzazione deli sistemi;

- Implementazione del cluster parallel file system sul sistema HPCSS;

- Implementazione dello spazio NAS sul sistema T2SS;

- Integrazione con il sistema Cluster HPC;

- Configurazione dei protocolli di accesso;

- Verifiche Funzionali e Performance Tuning.

3.2.11.7 Assunti per l’erogazione dei Servizi

Al fine di portare a termine con successo e nei tempi previsti i servizi di Setup e verifica dei requisiti tecnici della fornitura, NANOTEC garantisce il rispetto dei seguenti vincoli e prerequisiti:

- Sarà definito da NANOTEC un rappresentante IT che dovrà fornire tutta l'assistenza e le informazioni necessarie ai consulenti della Società. Da parte sua, La Società si impegna a dettagliare puntualmente le informazioni che si dovranno includere in questo incarico.

- Disponibilità durante lo svolgimento del servizio di System & Network Administrators e/o specialisti di Applicazione in grado di fornire informazioni sull’infrastruttura di rete esistente, sulle convenzioni e sul piano di indirizzamento IP da utilizzare nella configurazione del Cluster.

- Fornire all'installatore tutte le informazioni e documenti necessari all’implementazione.

- Non sono previste attività in extra time notturno o fine settimana se non espressamente richiesto.

- Non sono previste attività di migrazione dati.

3.2.12 Verifiche e test funzionali dell’infrastruttura HPC

3.2.12.1 Verifica del rispetto dei requisiti tecnici della fornitura

Per ogni elemento funzionale installato, verrà effettata la verifica del rispetto dei requisiti tecnici che dovrà accertare che la fornitura, per quanto riguarda il numero e la tipologia dei componenti, tecniche e metodologie impiegate, l’esecuzione e le funzionalità, siano in tutto corrispondenti a quanto previsto dai documenti del capitolato di gara.

3.2.12.2 Test funzionali infrastruttura HPC

La Società dovrà eseguire i seguenti i seguenti test per le verifiche funzionali dell’infrastruttura:

- Esecuzione del benchmark STREAM.

- Esecuzione dei test di performance della rete Infiniband (Perftest).

- Esecuzione del benchmark HPL (High Performance Linpack).

- Esecuzione del benchmark IOR.

3.3 Caratteristiche dell’infrastruttura CI

Ad oggi esistono sul mercato 3 definizioni che caratterizzano l’area dei Sistemi Integrati:

a) Reference Architecture;

b) Hyper Converged Infrastructure (Infrastruttura Iperconvergente);

c) Converged Infrastructure (Infrastruttura Convergente).

Oggetto di questo sottosistema del DC-LE sono tutte e sole le tecnologie appartenenti al terzo tipo, quello “c” delle Infrastrutture Convergenti, non saranno prese in considerazione risposte relative a Reference Architecture o Infrastrutture Iperconvergenti.

Per Infrastruttura Convergente (CI) si intende un insieme di apparecchiature di calcolo, networking LAN e SAN e Intelligent Storage System appositamente ingegnerizzate, integrate, certificate e commercializzate dal produttore hardware con un unico serial number. Le infrastrutture convergenti sono altamente modulari (sia in termini di calcolo che di storage e networking), completamente ridondate, flessibili e con una scelta di configurazioni che si adattano alle esigenze di carico che si dovessero presentare nel tempo.

In particolare, le Infrastrutture Convergenti di interesse dovranno permettere il contemporaneo utilizzo delle apparecchiature per ambienti virtualizzati (tramite i comuni software Hypervisor di mercato), ma anche per architetture fisiche tradizionali, tramite la possibilità di definire e configurare una parte o la sua totalità (sia in termini di computing, storage e networking) per un uso general-purpose.

Requisito Progettuale Vincolante CI 1 (RPV-CI-1)

Le Infrastrutture Convergenti di interesse dovranno permettere il contemporaneo utilizzo delle apparecchiature in ambienti virtualizzati e anche come sistemi fisici tradizionali “bare metal”, tramite la possibilità di definire e configurare una parte o la sua totalità (in termini di computing, storage e networking) per un uso general-purpose.

Il produttore hardware del sistema convergente dovrà rilasciare un unico contratto di supporto legato ad un unico serial number della infrastruttura convergente. Il sistema dovrà avere il supporto unificato attraverso un solo numero verde, in grado di intervenire in maniera integrata su tutte le varie componenti HW e SW, nonché un sistema di gestione unica

del sistema.

L’infrastruttura CI del DC-LE dovrà integrare in maniera nativa la soluzione VMware come risposta unica all’esigenza di adottare un nuovo modello di “Hybrid Cloud Computing” modello flessibile ed economico per la fornitura di servizi ICT ad utenti interni e esterni. Attraverso tecnologie innovative, consente un accesso più agevole a un insieme di risorse configurabili e condivise (risorse fisiche di rete, di storage e di processamento, servizi e applicazioni finali).

Inoltre la soluzione fornita deve avere la possibilità di ingegnerizzare ed integrare nativamente diverse soluzioni storage all flash e soluzione di protezione del dato proprietarie del produttore hardware della soluzione convergente mantenendo un unico serial number ed un unico contratto di supporto.

Viene richiesto al fine di avere evidenza dei vantaggi che la Società dovrà garantire con la sua soluzione Convergente di argomentare i benefici indicati di seguito:

• Semplicità – Ottimizzazioni tempi e risorse

• Streamlined Deployment – Attivazione strutturata e rapidità nella messa in produzione del sistema.

• System Sustainability – semplificazione aggiornamento di tutte le componenti del sistema Convergente e della gestione della configurazione.

• Converged Infrastructure Management - Software di gestione unico per l’intera soluzione, realizzato dal produttore HW dell’infrastruttura convergente, che comprenda funzioni di monitoraggio dello stato, conformità delle certificazioni e la gestione della conformità di sicurezza.

• Expand and Enhance Risk free - espansione ed ottimizzazione dei data services implementati in modo rapido e semplice

• Single-call Support – Supporto 24 ore su 24, completamente integrato con un unico punto di contatto.

• Security and Compliance - Tutti le componenti hardware e software testate e convalidati per eliminare le vulnerabilità della sicurezza e migliorare le prestazioni e l'integrità.

Il dimensionamento per il workload del servizio di produzione dell’infrastruttura CI del DC-LE dovrà rispettare i valori minimi riportati nella seguente Tabella 3.3.1:

Infrastruttura CI del DC-LE Dimensionamento minimo del workload di produzione della CI del DC-LE
ID requisito	Descrizione caratteristiche	Valori minimi CI Workload di Produzione
R.CI.1	Numero di server/lame Biprocessore installate su cui saranno installate nr. 2 GPU con licenze vmWare associate	8
R.CI.2	Numero di GPU modello NVIDIA P6 (o modello superiore) installate	16
R.CI.3	Capacità complessiva installata del sottosistema disco Tier 0	80 TeraByte RAW
R.CI.4	Capacità complessiva installata del sottosistema disco Tier 2	1,3 PetaByte RAW
R.CI.5	Capacità complessiva installata del sottosistema disco Tier 3 - Object Storage	140 TeraByte RAW

Tabella 3.3.1

Peraltro le infrastrutture Convergenti, nel rispetto dei Requisiti minimi vincolanti descritti in Tabella 3.3.1, possono essere considerati degli insiemi armonizzati, organizzati ed auto consistenti di diverse componenti, come graficamente sintetizzato qui di seguito nella Figura 3.4:

Figura 3.4: Schema logico CI del DC-LE

Nei sotto paragrafi seguenti, vengono descritte, oltre al dimensionamento della componente specifica ed agli eventuali vincoli tecnici ed architetturali che ciascuna componente dovrà soddisfare, anche le caratteristiche tecniche minime e le funzionalità che dovranno essere garantite.

La CI del DC-LE oggetto di acquisizione dovranno permettere la realizzazione di un’architettura che garantisca la certificazione per hypervisor VMware in linea con quanto descritto nel paragrafo 3.3.8.

Requisito Progettuale Vincolante CI 2 (RPV-CI-2)

La Componente di Storage Tier 2 presente nello schema logico della Figura 3.4 dovrà essere una soluzione completa di hardware e software in grado di erogare ogni servizio NAS richiesto sia per l’ambiente HPC (T2SS) che per l’ambiente CI del DC-LE rappresentati nello schema logico della Figura 3.1.

3.3.1 Componente Computazionale

Nel rispetto delle quantità minime di server/lame espresse nella Tabella 3.3.1, di seguito sono riportati i requisiti minimi obbligatori della componente computazionale della CI del DC-LE, pertanto le Società offerenti devono dichiarare che tutti i prodotti offerti hanno caratteristiche tecniche e prestazioni equivalenti o superiori a quelle richieste, pena l’esclusione dalla gara:

Componente Computazionale Cap. 3.3.1 – Requisiti Minimi Obbligatori
ID requisito	Descrizione	Richiesta Minima
R.CI.CC.1	N° Socket (Chip) installati	2
R.CI.CC.2	N° Minimo Core per Chip (CPU)	Almeno 10
R.CI.CC.3	Quantità RAM (GB)	Almeno 512
R.CI.CC.4	N° Minimo GPU NVIDIA P6 o modello superiore (non presenti su server/lame Biprocessore di tipo Bare Metal R.CI.2)	2
R.CI.CC.5	N° Porte FCoE (CNA) per la connettività interna fra blade e chassis	4x20Gbit/s

R.CI.CC.6	Tipologia server	Blade
R.CI.CC.7	Alloggiamento in Chassis	Si
R.CI.CC.8	CPU2017 Integer Rates Baseline minimo	Almeno 100
Caratteristiche dei Server Cap. 3.3.1.1 – Requisiti Minimi Obbligatori
R.CI.CC.9	Ogni lama dovrà appartenere alla più recente generazione x64 rilasciata dal produttore ed essere assemblata esclusivamente con elementi nuovi di fabbrica	Si
R.CI.CC.10	Ogni lama dovrà essere in grado di supportare I sistemi operativi a 64 bit previsti per la piattaforma X64 offerta.	Si
R.CI.CC.11	La singola lama fornita (nel rispetto della tipologia di lama espressa con i requisiti da R.CI.CC.1 a R.CI.CC.8) dovrà essere equipaggiata con tutte le CPU installate.	Si
R.CI.CC.12	I modelli di CPU x64 installati dovranno essere identici sia per tipologia che per caratteristiche tecniche a quelli utilizzati per la determinazione del benchmark prestazionale richiesto, alla loro ultima versione disponibile	Si
R.CI.CC.13	Il server dovrà essere fornito in modalità diskless e dovrà essere capace di eseguire il boot da SAN tramite FC o CNA	Si
R.CI.CC.14	Le schede CNA richieste al criterio R.CI.CC.5, potranno anche essere integrate nella scheda madre di sistema e/o utilizzare un controller multi-port	Si
R.CI.CC.15	Nel caso di scelte architetturali ove non sia disponibile connettività fra lame e chassis su FCoE, dovrà essere assicurata la connettività di rete, come indicato al criterio R.CI.CC.5, attraverso porte con banda garantita pari ad almeno 10Gb/s corredate di software per la gestione del bilanciamento di carico/alta affidabilità.	Si
R.CI.CC.16	Dovrà essere permessa la virtualizzazione in Hardware delle schede CNA	Si
R.CI.CC.17	Le schede dovranno avere la capacità di protezione su percorso alternativo delle NIC in HW senza necessità di bonding o timing	Si
R.CI.CC.18	Il sistema di gestione deve essere integrato in hardware e ridondato.	Si
R.CI.CC.19	Le schede CNA potranno anche essere integrate nella scheda madre di sistema e/o utilizzare controller multi-port purché sia rispettato il vincolo relativo al SPOF	Si
R.CI.CC.20	Lato Host è consentito sia l’utilizzo di connessioni FC (con capacità minima di 16Gbit/s per singola porta) e sia CNA.	Si
R.CI.CC.21	Lato Storage è consentito il solo utilizzo di connessione FC. E’ richiesta la fornitura di switch FC con porte ad almeno 16 Gbps, come meglio specificato nel seguito.	Si
R.CI.CC.22	Dovrà essere garantita la funzionalità di Stateless Computing, ovvero l’utilizzo di funzioni di configurazione degli apparati basate sul concetto di astrazione delle configurazioni software relativamente all’hardware dei server blade o dei rack server, denominato “profilo di servizio”: tale modalità consente di avere una definizione del server, a livello di parametri, indipendente dall’hardware utilizzato, per questo la denominazione di server “stateless”. Il profilo di servizio deve poter descrivere la configurazione del server tramite l’utilizzo di parametri. Qui una lista di quelli necessari e indispensabili per il funzionamento: NIC MACs, HBA WWNs, VLAN Assignments, VLAN Tagging, FC Fabrics Assignments, parametri di FC Boot, numero di NICs, Boot order, numero di vHBAs, QoS, BIOS firmware, Adapter firmware, BMC firmware, RAID settings, BIOS Settings, Disk Scrub Policy, IPMI. Si dovrà poter attingere da un pool di risorse che definiscono questi valori e di volta in volta applicarli al server anche sottoscrivendo i valori nativi che un server possiede come per esempio il MAC address. Inoltre deve essere possibile avere una funzione di “muti tenancy” per poter suddividere la gestione a diverse organizzazioni utilizzando meccanismi di RBAC ( role base access control ) e poter organizzare la creazione dei profili stessi tramite template. Questa astrazione delle configurazioni dal server consentirà una estrema facilità nel rendere operativo l’hardware con il proprio sistema operativo, velocizzare lo spostamento delle configurazioni da un server all’altro per manutenzione o sostituzioni degli stessi con materiale di scorta, nonché, in alcune soluzioni di software applicativi, un’ottimizzazione delle licenze, risparmiando sulle cosiddette licenze dormienti per cluster.	Si

Tabella 3.3.2

3.3.1.1 Caratteristiche degli Chassis

Di seguito sono riportati i requisiti minimi obbligatori della componente chassis della CI del DC-LE, pertanto le Società offerenti devono dichiarare che tutti i prodotti offerti hanno caratteristiche tecniche e prestazioni equivalenti o superiori a quelle richieste, pena l’esclusione dalla gara:

Caratteristiche Chassis Cap. 3.3.1.1 – Requisiti Minimi Obbligatori

ID requisito

Descrizione

Richiesta Minima

R.CI.CC.23

Dovrà essere previsto un numero di chassis sufficienti ad ospitare le 8 lame biprocessore.

R.CI.CC.24

E’ richiesta per gli Chassis Blade la fornitura di connettività tradizionale LAN e SAN o, in alternativa, connettività convergente FCOE come descritto successivamente.

Per ogni Chassis Blade offerto:

R.CI.CC.25

dovrà essere dotato di tutti gli elementi infrastrutturali necessari a garantire il corretto e completo funzionamento del numero massimo di Server Blade delle varie tipologie in esso

ospitabili anche se non completamente occupato

R.CI.CC.26

dovrà essere dotato di uno stadio di alimentazione ridondato con funzionalità Hot Swap, capace di garantire i fabbisogni di potenza dello Chassis Blade in condizioni di configurazione di massima espansione permessa dall’apparecchiatura offerta dalla Società anche in caso di

guasto parziale della componentistica di alimentazione

R.CI.CC.27

dovrà essere dotato di un sistema di ventilazione autonoma capace di garantire, anche in caso di guasto parziale del sistema di ventilazione, i fabbisogni di dissipazione del calore dello

Chassis Blade, in condizioni di configurazione di massima espansione permessa dall’apparecchiatura offerta dalla Società

R.CI.CC.28

dovrà essere dotato di opportuno hardware e/o software atto a garantire una gestione remota e in modalità grafica di ogni Server Blade presente nello Chassis Blade anche in assenza di un sistema operativo sui Server Blade

R.CI.CC.29

dovrà essere dotato di funzioni di gestione e monitoraggio di tutte le sue componenti

R.CI.CC.30

dovrà essere dotato di interconnessione ridondata LAN e SAN in caso di connettività tradizionale, o di interconnessione ridondata FCOE in caso di connettività convergente, ed in entrambi i casi, l’interconnessione dovrà essere dimensionata alla massima espansione

permessa dall’apparecchiatura offerta

R.CI.CC.31

dovrà essere dotato di tutti i pannelli ciechi per i moduli non presenti

R.CI.CC.32

devono essere dotati di moduli di management hardware integrati e ridondati, in modo che lo specifico Chassis Blade possa continuare ad essere gestito remotamente, anche nel caso in cui uno dei due moduli di management sia guasto. Non deve essere quindi necessario fornire

ulteriore server per il sistema di management

Tabella 3.3.3

3.3.1.2 Caratteristiche della connettività FCOE

Le connessioni convergenti FCOE dei Server Blade all’interno dello Chassis devono essere tutte realizzate attraverso appositi componenti di rete switch FCoE o moduli di passthrough o consolidamento quali ad esempio switch FCOE integrati nello Chassis Blade.

Di seguito sono riportati i requisiti minimi obbligatori della componente connettività della CI del DC-LE:

Caratteristiche della connettività FCOE Cap. 3.3.1.2 – Requisiti Minimi Obbligatori
ID requisito	Descrizione	Richiesta Minima
R.CI.CC.33	I moduli FCOE dovranno permettere l’interconnessione unitaria Ethernet e FC tramite protocollo FCoE verso una coppia esterna di apparati di network che rappresentano l’intelligenza di tutto il sistema: infatti, oltre a svolgere funzioni di interconnessioni verso gli chassis blade, questi svolgono anche funzione di connettività verso la LAN in Ethernet e verso lo storage utilizzando o protocolli NFS o FC/FCOE, nonché avere al suo interno il firmware necessario per il software di gestione e di monitoraggio di tutti gli chassis blade connessi, nonché di eventuali server in formato rack, evitando così la necessità dell’installazione di un cluster ad hoc.	Si
R.CI.CC.34	Sugli apparati esterni deve essere possibile configurare indifferentemente Ethernet, FC o FCOE, inserendo l’opportuno transceiver secondo la tecnologia selezionata	Si

R.CI.CC.35	Una coppia di tali apparati deve gestire fino a un massimo di 20 chassis e ogni chassis blade non deve contenere più di 8 blade per garantire una scalabilità granulare e consumi più ridotti	Si
R.CI.CC.36	A tale coppia di apparati deve essere possibile connettere non solo chassis blade, ma anche rack server, potendo così gestire entrambe i formati hardware dei server con la stessa interfaccia di gestione	Si
Per ogni apparato di rete integrato nello Chassis Blade:
R.CI.CC.37	è richiesta la fornitura di almeno due apparati di rete per Chassis hot-swap per garantire l’alta affidabilità	Si
R.CI.CC.38	è richiesto un numero di porte sufficiente a garantire il collegamento in rete dei Server Blade e nel loro numero massimo in esso ospitabili	Si
R.CI.CC.39	Le porte di uplink degli apparati di rete integrati negli chassis dovranno essere interconnesse ad apparati switch FCOE esterni che presentano anche connettività tradizionale LAN e SAN	Si
R.CI.CC.40	L’interconnessione tra i vari chassis dovrà essere realizzata da apparati esterni agli chassis in architettura ridondata (eventuali licenze e/o componenti aggiuntivi necessari per il corretto e immediato utilizzo delle porte dovranno far parte della fornitura), non è prevista l’implementazione di una topologia di tipo stackable tra i vari chassis	Si
Per ogni coppia di rete integrato nello Chassis Blade è richiesto:
R.CI.CC.41	Un numero di porte FC 16Gb/s pari a 8 ridondate per un totale di 16 porte, naturalmente comprensive di eventuali licenze e/o componenti aggiuntive necessarie per il corretto e immediato utilizzo delle porte	Si
R.CI.CC.42	la fornitura di strumenti per il controllo, il monitoraggio e la gestione, comprensivi delle licenze eventualmente necessarie sugli apparati	Si
R.CI.CC.43	la fornitura di sw e/o licenze necessarie (tools) per il controllo, il monitoraggio e la gestione di zoning, topologia connessioni	Si
R.CI.CC.44	Gli apparati di interconnessione degli chassis suddividono il traffico FCOE in traffico FC ed Ethernet verso gli apparati SAN e LAN oggetto di fornitura sempre in configurazione ridondata	Si
Software di Multipath – Requisiti Minimi Obbligatori
R.CI.CC.45	Devono essere fornite le licenze d’uso del software di multipath di tutti i controller HBA FC facenti parte della fornitura. Il software fornito deve essere certificato con la soluzione Storage fornita e con il software di virtualizzazione VMware e non deve essere quello incluso nel sistema operativo	Si
R.CI.CC.46	Tutti i software forniti devono intendersi nella loro ultima release disponibile e nella edizione con il numero maggiore di funzionalità previste anche se non esplicitamente indicato	Si

Tabella 3.3.4

3.3.2 Componente Network LAN

Per ognuno degli apparati LAN switch esterni è richiesto come requisito minimo obbligatorio:

Componente Network LAN Cap. 3.3.2 – Requisiti Minimi Obbligatori
ID requisito	Descrizione	Richiesta Minima
R.CI.NT.1	che siano dotati di uno stadio di alimentazione ridondato con funzionalità Hot Swap, capace di garantire i fabbisogni di potenza anche in caso di guasto parziale della componentistica di alimentazione	Si
R.CI.NT.2	un numero di porte ethernet, in aggiunta a quelle necessarie per l’interconnessione delle lame degli chassis, in grado di garantire la connettività di tutte le componenti del sistema integrato, naturalmente comprensive di eventuali licenze e/o componenti aggiuntivi necessari per il corretto e immediato utilizzo di tutte le porte	Si
R.CI.NT.3	Dovrà essere inclusa la fornitura di strumenti per la gestione, il controllo e il monitoraggio, comprensivi delle licenze necessarie sugli apparati	Si

Tabella 3.3.5

3.3.3 Componente Network SAN

Dovranno far parte della CI del DC-LE gli apparati di connessione FC per le connessioni interne al sistema a partire dal sottosistema a disco, e (come componenti opzionali) un set di switch FC multiprotocol FC-IP.

Di seguito sono riportati i requisiti minimi obbligatori della componente network SAN della CI del DC-LE:

Componente Network SAN Cap. 3.3.3 – Requisiti Minimi Obbligatori
ID requisito	Descrizione	Richiesta Minima

R.CI.NT.4

Devono essere forniti almeno una coppia di Switch FC con almeno 48 porte FC a 16Gbps

R.CI.NT.5

Le porte FC dovranno essere fornite attive e funzionanti con relativi connettori GBIC SFP e cavi di connessione in fibra ottica, tale da garantire la completa connettività verso gli chassis degli host in modalità ridondata

R.CI.NT.6

dovranno essere fornite eventuali opzioni o apparati aggiuntivi nonché eventuali licenze e/o software necessari per tali funzionalità, per il numero di porte definiti ai punti precedenti; il

software fornito deve essere accessibile anche via GUI

R.CI.NT.7

Dovranno essere garantiti supporto e licenze delle seguenti funzionalità sugli switch Fibre Channel forniti:

a. Protocollo N-Port ID Virtualization (NPIV)

b. Seamless fabric interoperability

c. Scalabilità a supporto della Virtualizzazione

d. Multiple fabric support

e. Device-based mapping

f. Quality of Service (QoS)

g. Proactive monitoring and alerting

R.CI.NT.8

Nella fornitura si intende incluso qualsiasi componente necessario alla corretta attivazione degli apparati, anche se non esplicitamente qui citato

Tabella 3.3.6

3.3.4 Componente Management

Dovranno far parte della soluzione dell’Infrastruttura Convergente gli apparati necessari per il management dell’intera soluzione. In particolare i requisiti minimi obbligatori per la componente di management sono:

Componente di management – Requisiti Minimi Obbligatori
ID requisito	Descrizione	Richiesta Minima
R.CI.MGT.1	Gli apparati necessari per il management dell’intera soluzione e delle sue componenti sono composti da : - Storage dedicato - Due Switch Network dedicati - Server dedicati	Si
R.CI.MGT.2	Le Infrastrutture Convergenti oggetto di fornitura dovranno essere configurabili e gestibili in maniera integrata, in ogni istante, tramite un unico punto di gestione, utilizzando server di management ridondati in modo che ne sia sempre possibile l’interfacciamento	Si
Il software unico di gestione dovrà:
R.CI.MGT.3	Gestire l’intera Infrastruttura convergente	Si
R.CI.MGT.4	Potersi integrare nativamente con la Suite vmWare scelta per l’erogazione dei servizi Cloud	Si
R.CI.MGT.5	Essere commercializzato dallo stesso produttore hardware della soluzione Convergente	Si
R.CI.MGT.6	Consentire di visualizzare ogni elemento del sistema convergente, controllare gli stati (superato o non riuscito).	Si
R.CI.MGT.7	Fornire una visualizzazione di alto livello in tutti i componenti del sistema Integrato	Si
R.CI.MGT.8	Avere la possibilità di confrontare la versione di certificazione installata nell’infrastruttura convergente con quelle successive rilasciate dal produttore, al fine di prevedere le possibili azioni da intraprendere per aggiornare il sistema nella sua totalità. Dovrà essere inoltre possibile generare report in grado di dare evidenza dei GAP da colmare tra la versione di certificazione installata e le successive rilasciate dal produttore	Si
R.CI.MGT.9	Monitorare i problemi in tempo reale che influiscono sul sistema	Si
R.CI.MGT.10	Integrarsi nativamente con VMware vRealize Operations (vROps) per fornire informazioni complete sullo stato di integrità e metriche di capacity planning	Si

Tabella 3.3.7

3.3.5 Componente Storage Tier 0

Il sottosistema storage Tier 0 dovrà essere di tipo ALL-FLASH ad elevate prestazioni per l’utilizzo con dati ad alta frequenza di accesso e tempi di lettura e di scrittura estremamente rapidi e con un alto livello di affidabilità.

Si richiede che lo storage abbia configurazione con capacità RAW pari ad almeno 80TB.

La soluzione proposta dovrà supportare una architettura futura di tipo Business Continuity (Active/Active) e/o Disaster Recovery.

Si richiede che lo storage Tier 0 deve appartenere alla più recente generazione rilasciata e dovrà essere costituito esclusivamente da elementi nuovi di fabbrica.

Dovranno essere forniti i software d’ambiente necessari al funzionamento delle singole componenti.

Le caratteristiche riportate nel seguito del presente capitolato sono da considerare quali requisiti minimi obbligatori dei prodotti richiesti, pertanto le società devono dichiarare che tutti i prodotti offerti hanno caratteristiche tecniche e prestazioni equivalenti o superiori a quelle richieste, pena l’esclusione dalla gara.

Componente Tier 0 – Requisiti Minimi Obbligatori
ID requisito	Descrizione	Requisiti Obbligatori	Richiesta Minima
R.CI.T0.1	Classe di Storage	Storage Array di classe Enterprise appartenente all’ultima generazione rilasciata dal vendor, progettato per essere integralmente ALL FLASH senza la possibilità di inserire dischi rotativi.	Si
R.CI.T0.2	Scale-Up/ Scale- Out	Il sistema deve avere due o più controller e supportare simultaneamente: scalabilità di tipo verticale - scale-up: crescita capacitiva senza dover aggiungere ulteriori storage controller; e scalabilità di tipo orizzontale (scale-out): la possibilità di aggiungere sia ulteriore capacità destinata ai dati sia ulteriori controller	Si
R.CI.T0.3	Multi-Controller	È richiesto uno storage multi-controller che preveda quindi la possibilità di scalare con un numero di controller superiore a due. Non sono ammessi sistemi federati.	Si
R.CI.T0.4	Single of Point Of Failure	Il sistema non presenta “Single Point Of Failure”, e raggiunge Six Nine’s (99,9999) di disponibilità (senza l’utilizzo di hw esterni) certificati dal produttore	Si
R.CI.T0.5	Livelli RAID Hardware	Il sistema implementa la protezione RAID in modalità Hardware. I livelli di protezione RAID minimi richiesti sono: RAID 5 e RAID 6.	Si
R.CI.T0.6	Utilizzo porte di Front End e Back End.	Il sistema utilizza i processori sulle porte di front end e di back end organizzandoli in pool virtuali di risorse al fine di ottimizzare il workload.	Si
R.CI.T0.7	Deduplica e/o Compressione	Compressione e Deduplica inline con scheda HW dedicate e ridondate a queste funzioni.	Si
R.CI.T0.8	Deduplica e/o Compressione	Le funzioni di data reduction devono poter essere abilitati per singolo volume.	Si
R.CI.T0.9	Deduplica e/o Compressione	Le funzioni di compressione e deduplica inline deve essere di tipo Globale (Unico Namespace)	Si
R.CI.T0.10	Compressione	Al fine di garantire le massime prestazioni il sistema deve poter evitare i processi di Compressione per i file più acceduti.	Si
R.CI.T0.11	Tipologia Dischi	Il sistema deve utilizzare unità disco SSD standard di mercato con interfaccia nativa NVME-Dual Port	Si
R.CI.T0.12	Tipologia Dischi	Il sistema deve essere in grado di supportare le nuove tipologie di disco definite SCM (Storage Class Memory)	Si
R.CI.T0.13	Cache	Il sistema dispone di minimo 512GB RAW di cache per controller.	Si
R.CI.T0.14	Cache	Il sistema deve poter supportare fino a 1TB di cache per controller.	Si
R.CI.T0.15	Cache	Il sottosistema storage, tramite apposita funzionalità, deve essere in grado di dividere la memoria cache in partizioni che possono essere assegnate ad applicazioni diverse qualora fosse necessario mantenerle “isolate” tra di loro.	Si
R.CI.T0.16	Configurazione storage	Il Sistema deve essere configurato con una capacità minima RAW di 80TB con unità disco di tipo NvME dual port.	Si
R.CI.T0.17	Configurazione delle porte di Front-End	Il sistema deve essere configurato con un numero di porte FC a 16Gb non inferiore a 8.	Si
R.CI.T0.18	Numero di Controller	Il sistema deve essere configurato con un numero di controller >= 2	Si
R.CI.T0.19	Thin Provisioning	Il sistema deve erogare lo spazio in modalità Thin Provisioning con la	Si

		possibilità di allocare lo spazio in componenti chunks non più grandi di 128KB.
R.CI.T0.20	Reliability	Il sistema deve consentire la sicurezza del dato dall’arrivo alla scrittura su disco tramite lo standard T10DIF+	Si
R.CI.T0.21	Connettività front- end: protocolli	Tipologie:	Si
		SAN: FC 32Gb NVMe ready, iSCSI 10GbE;
		Replica Remota: 10GbE - FC 32Gb.
R.CI.T0.22	N° massimo di porte di front-end supportate per FC e iSCSI	64 porte FC 16Gb o 64 porte iSCSI 10GbE, oppure una combinazione delle opzioni precedenti	Si
R.CI.T0.23	Supporto protocolli NAS	Possibilità di supportare i protocolli NAS (NFS – SMB) in modalità nativa senza l’utilizzo di gateway esterni.	Si
Funzionalità
X.CI.T0.24	Aggiornamento a caldo.	Il sistema deve permettere l’aggiornamento a caldo del proprio sistema operativo (microcode).	Si
X.CI.T0.24	Aggiornamento a caldo.	Deve inoltre essere in grado di effettuare tale upgrade senza effettuare alcun processo di fail-over/fail-back dei componenti o passaggio di proprietà delle lun tra controller, bensì effettuando l'upgrade in parallelo in un tempo non superiore ai 10 secondi.	Si
R.CI.T0.25	QoS	Il sottosistema di storage deve essere in grado di misurare, controllare e assegnare priorità ad un applicativo o a gruppi di applicativi in base a:	Si
R.CI.T0.25	QoS	• Bandwidth (n°di I/O x Blocksize) • Throughput (I/O) • Tempo di risposta (RT)	Si
R.CI.T0.26	Replica Remota	Il sistema deve supportare modalità di replica remota sincrona e asincrona consistente, anche su più siti.	Si
R.CI.T0.27	Replica Remota	Il sistema deve supportare una modalità di replica remota sincrona Active/Active con accessi in read/write sulle stesse Lun e su entrambi gli storage senza l’utilizzo di apparecchiature esterne. Deve essere inoltre disponibile un Witness per la gestione dei guasti.	Si
R.CI.T0.28	Array Based Encryption	L’encryption è array based e non ha la necessità di Key Manager esterni. L’encryption è possibile anche nel caso in cui ci sia la compressione attivata.	Si
R.CI.T0.29	Application Awareness	Lo storage array deve essere in grado, tramite apposito software, di orchestrare copie locali dei dati per ottenere copie consistenti dal punto di vista applicativo, interfacciando direttamente l'applicazione.	Si
Integrazioni-Plugins
X.CI.T0.30	Integrazione con VMware tramite le VAAI	Il sistema supporta nativamente l’integrazione con gli ambienti Vmware tramite le VAAI (vmware vStorage APIs for Array Integration), ovvero si demanda allo storage tutte le operazioni di deployment, cloning, snapshot e vmotion delle Virtual Machines.	Si
R.CI.T0.31	Integrazione con VMware tramite le VASA	Il sistema deve supportare nativamente l’integrazione con gli ambienti Vmware tramite le VASA (vmware API for Storage Awareness), ovvero deve riportare automaticamente le informazioni sulle LUN, demandando la gestione delle performance direttamente al server Vsphere.	Si
R.CI.T0.32	Supporto VVols	Supporto per VMware VVols.	Si
System Monitor & Analytics

R.CI.T0.33

System Monitor & Analytics

La soluzione deve disporre di un meccanismo che si avvale di una applicazione Cloud Based in grado di fornire indicazioni proattive riguardanti il suo stato di salute.

Lo stesso meccanismo deve disporre di funzioni di analisi predittiva per i trend di crescita e di performance troubleshooting.

I dati raccolti dovranno essere inviati al centro di supporto con una periodicità non superiore a 15 minuti.

Questa applicazione dovrà essere disponibile attraverso una interfaccia WEB

e/o altro.

Tabella 3.3.8

3.3.6 Componente Storage Tier 2

Il sistema proposto dovrà essere una soluzione completa di hardware e software in grado di erogare ogni servizio NAS richiesto sia per l’ambiente HPC (T2SS) che per l’ambiente CI del DC-LE descritti nei paragrafi precedenti (Riferimento RPV-CI-2).

Il sistema dovrà poter operare in piena autonomia senza richiedere nessuna risorsa esterna con la sola eccezione dei collegamenti di rete dati e dell’alimentazione elettrica.

Non saranno pertanto considerate accettabili soluzione basate su servizi cloud (nè private cloud nè public cloud o soluzioni ibride).

Il sistema dovrà comprendere tutte le componenti necessarie all’erogazione dei servizi NAS richiesti.

Non saranno accettate soluzioni erogate sotto forma di IAAS, PAAS, hosting, housing o più in generale qualsiasi altra tipologia di acquisto o contratto che preveda la fornitura sotto forma di servizio a canone.

La soluzione offerta dovrà comprendere il sistema di doppia distribuzione di corrente in grado ricevere alimentazione da due linee distinte. Ogni linea di distribuzione dovrà essere progettata per sostenere da sola tutto il carico di potenza necessario a mantenere il sistema in piena efficienza operativa.

Il sistema proposto dovrà essere una soluzione per la gestione di dati non strutturati ad accesso file level mediante servizi erogati attraverso rete ethernet su protocolli IP e con caratteristiche tali da essere classificabile sotto la denominazione di sistema Network Attached Storage. Dovranno essere erogabili tutti i protocolli principali tipici delle soluzioni NAS e dovranno poter essere ospitati contemporaneamente anche nuovi e innovativi ambienti applicativi, di seguito elencati i protocolli richiesti:

- NFS

- CIFS/SMB

- FTP

- HTTP

- HDFS

- SWIFT

- NDMP

- Rest API

Il sistema proposto dovrà essere privo di qualsiasi elemento che possa essere considerato un “Single Point of Failure” (SPOF) e garantire quindi la piena operatività delle sue funzioni, anche se con un minimo degrado delle sue prestazioni, anche in caso di 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 la necessità di interrompere, anche per breve periodo, il funzionamento di altri componenti del sistema per eseguire la sostituzione necessaria.

Sarà tuttavia considerata accettabile una soluzione dove sia esplicitamente indicata la necessità di un fermo parziale di una parte del sistema per operare alcune tipologie di manutenzione, in tal caso però il sistema dovrà essere progettato in modo tale da mantenere ogni livello di funzione, uguale ai livelli di piena operatività, durante tutto il periodo di fermo necessario all’attività di manutenzione.

Il sottosistema software della soluzione offerta dovrà poter essere aggiornato o modificato senza eseguire alcun fermo dei servizi erogati in una modalità definibile “a caldo”. Qualora la soluzione proposta sia costituita da un insieme di nodi indipendenti operanti in una logica di intelligenza distribuita è ammessa la possibilità che l’operazione di upgrade software debba comportare il riavvio di un singolo nodo per volta durante la fase di aggiornamento, questo però non dovrà in alcun modo inficiare il livello di servizio erogabile in fase di piena operatività.

Il sottosistema hardware oltre alla già evidenziata assenza di SPOF dovrà poter essere upgradato senza dover alterare la piena operatività dei servizi erogati dal sistema; operazioni quali l’incremento dello spazio storage e della capacità

elaborativa, l'aggiunta di nuove funzionalità o licenze, o la modifica del livello di protezione dei dati del sottosistema dovranno poter essere eseguite a caldo senza che questo comporti la riduzione anche temporanea delle funzionalità o le performance del sistema.

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”, senza cioè alterare in alcun modo lo stato del sistema in esercizio, e l’architettura dovrà prevedere la possibilità di integrare tale nodo all’interno dell’insieme preesistente ridistribuendo, in modo del tutto automatico o pilotabile mediante specifiche policy, i dati, i servizi ed il carico di lavoro su tutti i nodi compreso il nuovo appena aggiunto.

3.3.6.1 Requisiti Tecnici Componente Tier2

Il sistema dovrà avere la caratteristica strutturale di essere modulare, a scalabilità lineare su tutte le sue principali componenti. Dovrà essere possibile aumentare le capacità computazionali, di memoria cache e di throughput dell’I/O di front-end in modo lineare all’aumento della capacità di archiviazione del sistema stesso.

E’ considerata una soluzione preferibile un sistema costituito da un insieme di nodi indipendenti che operano in una struttura di intelligenza distribuita che ripartisca il carico di lavoro (servizi, sessioni, I/O, dati, carico computazionale) su tutti i nodi del sistema o, mediante policy configurabili e modificabili a caldo, su un loro sottoinsieme.

La soluzione dovrà prevedere la possibilità di integrare componenti hardware di generazioni differenti mantenendo una piena compatibilità con il resto del sistema. Eventuali refresh tecnologici che si rendessero necessari per l’incremento della richiesta di prestazioni o di nuove funzionalità del sistema dovrà avvenire in modo del tutto trasparente, senza fermi o disservizi e senza la necessità di una procedura di migrazione manuale dei dati.

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 da apparire dal punto di vista logico alle applicazioni o all’utenza come una sola componente atomica.

Pur nel rispetto della caratteristica di atomicità sopra descritta, 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 rende disponibile 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à;

- Migrazione automatica dei dati in funzione della configurazione di suddivisione applicata;

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

3.3.6.1.1 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. Tale modalità di presentazione logica del dato dovrà rendere del tutto invisibile all’utente la reale collocazione del dato all’interno del sistema; eventuali upgrade del sistema non dovranno in alcun modo alterare questa 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 50 PetaByte di dati.

3.3.6.1.2 Funzionalità di bilanciamento

Il sistema deve poter supportare un set di funzionalità in grado di bilanciare in modo automatico e dinamico il carico di lavoro in modo da ridistribuirlo su tutti i suoi componenti così da sfruttare in modo completo le risorse a disposizione. È richiesto che tale bilanciamento avvenga in modo del tutto trasparente alle applicazione senza la necessità di modifiche alcune alle applicazioni client che utilizzano le risorse del sistema. Il bilanciamento dovrà essere disponibile su tutti i protocolli di comunicazione front-end messi a disposizione dal sistema senza nessuna eccezione. È consentito lo sfruttamento di tecniche quali il DNS delegation, il floating IP o mac address, multicast o protocol redirection.

In caso di indisponibilità improvvisa di una delle risorse il sistema di bilanciamento dovrà inoltre garantire l’immediata redistribuzione delle sessioni di lavoro sulle risorse rimaste disponibili riadattando la distribuzione del carico di lavoro alla nuova configurazione del sistema.

3.3.6.1.3 Autotiering

Il sistema deve poter supportare nativamente un meccanismo di automatic tiering verticale su base policy che permette di spostare a caldo ogni singolo file presente nel File System da una tipologia di dischi ad un’altra, in modo da ottimizzare le performance erogate. Tale spostamento non dovrà comportare modifiche nella struttura del File System o nell’accesso allo stesso.

3.3.6.1.4 Management unificato

Il sistema, anche se a logica distribuita, dovrà prevedere un unico punto di gestione: tale sistema di gestione dovrà essere accessibile sempre con le medesime modalità e caratteristiche a prescindere dalla disponibilità delle risorse del sistema (la caduta di uno o più componenti del sistema non dovrà inficiare l’accesso al sistema di management o una variazione alle sue modalità di accesso). Dal management unificato dovranno essere gestibili tutte le caratteristiche e le funzionalità del sistema. Sebbene sia accettata la possibilità che il management possa essere eseguito attraverso l’utilizzo di client o console dedicata, il sistema dovrà comunque prevedere un’interfaccia di gestione clientless di tipo grafico accessibile attraverso il protocollo http/ssl in grado di fornire all’operatore tecnico tutte le funzionalità di gestione delle componenti del sistema.

3.3.6.1.5 Supporto a 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.

3.3.6.1.6 Supporto e gestione delle quote

Il sistema deve poter supportare le funzionalità complete di gestione delle quote: dovrà essere 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), e un “grace period”. 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.

3.3.6.1.7 Supporto snapshot e clone

Il sistema deve poter supportare la funzionalità di gestione degli snapshot di tutto o parte del File System del sistema con una “profondità” di almeno 5 livelli di snapshot sulla singola risorsa. Se ne 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 deve prevedere la possibilità di eseguire cloni fisici alcune sezioni del File System e in generale dei dati in esso contenuti. I cloni eseguiti dovranno essere accessibili con le stesse modalità di ogni risorsa del sistema.

3.3.6.1.8 Replicazione Remota

Il sistema deve poter supportare nativamente la funzionalità di replica remota di tutti o parte dei dati contenuti nel sistema. Sebbene sia considerata sufficiente che la soluzione disponga di una replica remota asincrona, sarebbe preferibile che tale funzione sia talmente efficiente da garantire il minor RPO (Recovery Point Objective) possibile.

La modalità di replica dovrà essere eseguibile utilizzando come supporto di trasporto una normale rete TCP/IP con adeguata larghezza di banda, latenza, data loss e jitter. Eventuali richieste specifiche su tali caratteristiche devono essere indicate nella documentazione e saranno oggetto di valutazione. In caso siano considerate troppo restrittive il sistema verrà considerato privo della funzione di replica remota e valutato di conseguenza.

Non verrà in alcun modo accettata una soluzione di replica remota che preveda un canale dedicato di comunicazione tra il sistema on-line ed il sistema in replica.

3.3.6.1.9 Integrità dei dati (WORM)

Il sistema deve poter supportare 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, incluse le rigide norme americane XXX 00x-0.

3.3.6.1.10 Data Protection

Il sistema dovrà prevedere un set completo di livelli di protezione del dato inserito nel sistema.

Dovrà essere possibile configurare differenti di livelli di protezione e impostare, nel caso di sistemi a logica distribuita, la tolleranza al numero di nodi che possono essere non disponibili senza che le funzionalità del sistema debba risentirne.

Nel rispetto del vincolo di assenza di SPOF la caduta di una singola risorsa (disco o nodo che sia) non deve comunque mai rappresentare, in nessuna configurazione, un evento che porti al degrado delle funzioni del sistema o a possibili perdite di dati.

Le modalità e livelli di protezione devono essere dinamici, impostabili a caldo e configurabili a vari livelli sulle risorse del sistema fino a un livello di granularità massimo (il singolo file).

3.3.6.1.11 Protocolli supportati

Devono essere pienamente supportati i protocolli standard dei sistemi NAS:

- NFSv3, NFSv4 anche con funzionalità di authentication

- CIFS e SMB v1, v2, v2.1, v3

- FTP sia in modalità active che passive

- HTTP

- Hadoop (HDFS v1, v2, v3).

3.3.6.1.12 Supporto al Cloud

La soluzione deve poter supportare la possibilità di eseguire tiering verso Storage di tipo cloud, sia verso cloud privati che verso i maggiori provider di cloud pubblici (Amazon, Azure, Google). L’accesso al dato archiviato avvenire tramite il filesystem della soluzione NAS, ed i file non dovranno essere quindi spostati integralmente sullo storage Cloud. Non ci dovrà essere quindi un cambio di cartella o di protocollo di accesso per i file archiviati. Il tiering dovrà essere completamente trasparente alle applicazioni o agli utenti che utilizzano lo storage NAS.

3.3.6.1.13 Deduplica

Lo storage deve poter supportare meccanismi di riduzione dello spazio fisico occupato, tramite algoritmi di deduplica del dato. Tali algoritmi dovranno essere eseguiti sull’intero filesystem del NAS e sui differenti Tier di storage presenti all’interno della soluzione. Non saranno accettati validi meccanismi di deduplica che agiscono a livello di singolo volume/tier, in quanto saranno ritenuti non efficienti.

3.3.6.2 Caratteristiche tecnico funzionali minime Componente Tier2

Di seguito sono riportati i requisiti funzionali minimi della Componente Tier2 che la fornitura dovrà rispettare:

Componente Tier 2 – Requisiti Minimi Obbligatori
ID requisito	Descrizione caratteristiche funzionali	Richiesta Minima
R.CI.T2.F.1	L’architettura storage deve essere di tipologia Scale-Out NAS e in un unico sottosistema, ovvero non composta da due o più sezioni separate per la parte “computazionale”, di “accesso al file system” e “capacitiva”	Si
R.CI.T2.F.2	Dimensione dei nodi in termini di Rack Unit	Almeno 4 nodi in 4 Rack Unit
R.CI.T2.F.3	Lo storage deve essere in grado di espandere a caldo le performance e la capacità linearmente.	Si
R.CI.T2.F.4	Performance e capacità storage lineari devono poter essere raggiunte aggiungendo nodi storage, ciascuno con i suoi Dischi, Cache, I/O e potenza computazionale (CPU) per assicurare la scalabilità lineare e la crescita semplificata del sistema	Si
R.CI.T2.F.5	Tutti i nodi storage/controller devono essere attivi, contribuendo in modo paritetico alle performance e alla capacità del sistema	Si
R.CI.T2.F.6	Lo storage deve consentire la coesistenza di nodi di differenti generazioni di hardware, senza cambiamenti alla configurazione esistente e mentre il sistema è online. Deve consentire inoltre la dismissione di hardware di vecchia generazione se e quando richiesto.	Si

R.CI.T2.F.7	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.	Si
R.CI.T2.F.8	Gli upgrade devono essere applicati senza il cambio della configurazione dei controller proposta.	Si
R.CI.T2.F.9	Deve fornire l’accesso per una varietà di sistemi operativi (UNIX, MAC, Linux, Windows) usando tutti i protocolli standard: XXXx0, XXXx0, XXX0, SMB2.0 e SMB 3.0 (CIFS), HTTP, FTP, SWIFT, REST e HDFS. Tutti i protocolli devono essere inclusi senza licenze addizionali o ulteriore hardware.	Si
R.CI.T2.F.10	Il Sistema storage supporta nativamente Hadoop Distribuited File System (HDFS1.X, HDFS 2.x e 3.0)	Si
R.CI.T2.F.11	Lo storage deve essere in grado di mixare dischi SAS, 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.	Si
R.CI.T2.F.12	Lo storage deve consentire di creare differenti tier di capacità e performance composti di dischi di tipologia differente (SAS, SATA e SSD) con un file system unico. Il sistema storage è in grado di gestire il ciclo di vita dei dati e migrare i file tra i differenti tier, utilizzando politiche basate sull’età del file, sul tipo, sulla dimensione e sulla posizione nelle directory.	Si
R.CI.T2.F.13	Il sistema storage deve avere una cache coerente globale, scalabile quando vengono aggiunti più nodi al cluster	Si
File System e Scalabilità
R.CI.T2.F.14	Dimensione minima del singolo File System	Almeno 50PB
R.CI.T2.F.15	N. xxxxxxx xx xxxx aggregabili in un unico sistema	Almeno 252
R.CI.T2.F.16	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.	Si
R.CI.T2.F.17	Il file system deve essere continuamente e automaticamente bilanciato su tutti i nodi e i dischi, per eliminare colli di bottiglia e zone calde.	Si
R.CI.T2.F.18	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.	Si
R.CI.T2.F.19	L’accesso dei client al file system e alle share deve essere automaticamente distribuito su tutti i nodi per ottimizzare le performance del sistema	Si
R.CI.T2.F.20	Il file system deve permettere un numero illimitato di accessi client indipendentemente dal sistema operativo e dal protocollo.	Si
Integrità, Protezione e Disponibilità del dato.
R.CI.T2.F.21	Il sistema Storage deve poter supportare le snapshot a livello di volume e directory fino a 1024 snapshot per directory	Si
R.CI.T2.F.22	Il sistema Storage deve utilizzare un meccanismo di protezione dei dati basato su “erasure coding” (N+M)	Si
R.CI.T2.F.23	Il sistema deve poter supportare il guasto contemporaneo di almeno due dischi o di un intero nodo senza perdita dei dati.	Si
R.CI.T2.F.24	Il meccanismo di protezione deve supportare fino al guasto contemporaneo di quattro dischi o quattro nodi (con la presenza di un numero sufficiente di nodi complessivi) senza interruzione del servizio	Si
R.CI.T2.F.25	Il sistema storage deve avere funzionalità di Journal File System. Il journaling accelera i tempi di ricostruzione per gli storage media ripristinabili richiedendo la scrittura nel file solo dei blocchi nuovi/cambiati	Si
R.CI.T2.F.26	Il sistema storage deve rimanere completamente online e con tutti i dati accessibili in caso di un fallimento di un intero nodo.	Si
R.CI.T2.F.27	Il sistema storage deve consentire di modificare le impostazioni e i livelli di protezione del dato a caldo e senza disservizio	Si
R.CI.T2.F.28	Il sistema storage deve consentire di modificare il livello di protezione del dato in maniera granulare a livello sistema, directory o file	Si

R.CI.T2.F.29	Supporta/Include quota utenti con limiti soft o hard ed Over Provisioning.	Si
R.CI.T2.F.30	Supporta/Include Reporting avanzato e analisi delle performance, analisi del trend dello storage e strumenti di capacity planninng	Si
R.CI.T2.F.31	Il sistema deve supportare nativamente la possibilità di replicare i dati su un sistema remoto, tramite meccanismi di replica asincrona.	Si
R.CI.T2.F.32	Il sistema deve poter offrire supporto al protocollo NDMP per integrazione con soluzioni di backup	Si
R.CI.T2.F.33	Il sistema deve poter offrire meccanismi di deduplica per la riduzione dello spazio fisico occupato	Si
R.CI.T2.F.34	Il sistema deve poter offrire il tiering del dato verso cloud privati e/o pubblici (Amazon, Azure, Google)	Si
R.CI.T2.F.35	Supporta il WORM con meccanismi di protezione di tipo locking e compliance con le regolamentazioni SEC 17a-4	Si
Gestione e Amministrazione
R.CI.T2.F.35	Deve essere supportata l’interfaccia Web e la CLI dello storage	Si
R.CI.T2.F.36	Deve essere abilitato e supportato l’SNMP monitoring	Si
R.CI.T2.F.37	La soluzione deve supportare l’autenticazione degli utenti e degli amministratori con NIS, LDAP e Active Directory	Si
R.CI.T2.F.38	Il sistema storage deve supportare la scansione con l’Antivirus attraverso il protocollo iCAP.	Si
R.CI.T2.F.39	Il sistema storage deve fornire il monitoraggio della capacità ed il reporting a livello directory, utenti e gruppi	Si
R.CI.T2.F.40	Il sistema storage deve supportare lo storico delle performance e la loro analisi.	Si
R.CI.T2.F.41	Lo storage deve fornire funzionalità di monitoraggio remoto e di “chiama a casa” al fine di allertare il fornitore di eventuali fallimenti e/o richieste di manutenzione.	Si, almeno 3 domini diversi non in trust
R.CI.T2.F.42	Il sistema deve supportare l’integrazione con più domini Active Directory (mount-point esportato per “cliente”) anche non in trust	Si
R.CI.T2.F.43	Il sistema deve poter supportare funzioni di Auditing e la possibilità di esportare i log tramite protocollo CEE o Syslog	Si

Tabella 3.3.9

La Componente di Storage Tier2 richiesta dovrà essere composta da due Tier: un Tier Performante ed un Tier Capacitivo.

3.3.6.3 Caratteristiche Componente Tier2 Performante

Di seguito sono riportati i requisiti minimi della componente di storage Tier 2 performante che la fornitura NAS dovrà rispettare.

Componente Tier 2 – Requisiti Minimi Obbligatori
ID requisito	Descrizione caratteristiche Tier 2 Performante	Richiesta Minima
R.CI.T2.P.1	Numero di nodi nella configurazione di base	Almeno 6
R.CI.T2.P.2	Spazio RAW con dischi SATA di almeno:	600TB
R.CI.T2.P.3	Spazio RAW con dischi SSD di almeno:	9TB
R.CI.T2.P.4	Tipologia di interfacce di front-end verso i sistemi server	40GbE QSFP+
R.CI.T2.P.5	Numero di interfacce 1GbE per nodo (management)	1
R.CI.T2.P.6	Numero di interfacce 40GbE per nodo (front-end)	2
R.CI.T2.P.7	Numero di interfacce 40GbE per nodo (back-end)	2
R.CI.T2.P.8	Licenza software per la gestione delle rete, degli accessi e del failover delle porte	SI
R.CI.T2.P.9	Licenza software per la gestione delle Quote	SI

R.CI.T2.P.10	Licenza software per la gestione delle Snapshot	SI
R.CI.T2.P.11	Licenza software per il supporto alla gestione dei Pool (Tiering)	SI
R.CI.T2.P.12	Licenza software per il supporto al protocollo HDFS	SI
R.CI.T2.P.13	Software di monitoring e reportistica avanzato	SI

Tabella 3.3.10

3.3.6.4 Caratteristiche Componente Tier2 Capacitivo

Di seguito sono riportati i requisiti minimi della componente di storage Tier 2 capacitivo che la fornitura NAS dovrà rispettare.

Componente Tier 2 – Requisiti Minimi Obbligatori
ID requisito	Descrizione caratteristiche Tier 2 Capacitivo	Richiesta Minima
R.CI.T2.C.1	Numero di nodi nella configurazione di base	Almeno 4
R.CI.T2.C.2	Spazio RAW con dischi SATA di almeno:	700TB
R.CI.T2.C.3	Tipologia di interfacce di front-end verso i sistemi server	10GbE SFP+
R.CI.T2.C.4	Numero di interfacce 1GbE per nodo (management)	1
R.CI.T2.C.5	Numero di interfacce 10GbE per nodo (front-end)	2
R.CI.T2.C.6	Numero di interfacce 10GbE per nodo (back-end)	2
R.CI.T2.C.7	Licenza software per la gestione delle rete, degli accessi e del failover delle porte	SI
R.CI.T2.C.8	Licenza software per la gestione delle Quote	SI
R.CI.T2.C.9	Licenza software per la gestione delle Snapshot	SI
R.CI.T2.C.10	Licenza software per il supporto alla gestione dei Pool (Tiering)	SI
R.CI.T2.C.11	Licenza software per il supporto al protocollo HDFS	SI
R.CI.T2.C.12	Software di monitoring e reportistica avanzato	SI

Tabella 3.3.11

3.3.7 Componente Storage Tier 3 - Object Storage

Il sottosistema storage Tier 3 dovrà essere di tipo object storage e dovrà supportare i protocolli S3, SWIFT, CENTERA, ATMOS, RestAPI, HDFS, NFS, CIFS.

I dati verranno distribuiti su più sedi geografiche in un unico namespace globale allo scopo di offrire livelli di efficienza, accessibilità e scalabilità elevati.

Lo spazio fornito deve essere di almeno 140TB RAW. Il sistema deve essere di tipo di scale-out, cioè può essere espanso aggiungendo altri nodi, ma con un unico global namespace distribuito su singolo sito o multi-site.

3.3.7.1 Caratteristiche e funzionalità

Il sottosistema storage Tier 3 di tipo object storage dovrà essere in grado di:

- Protezione dei dati con replica remota: lo storage dovrà conservare una copia completa di un oggetto in locale e distribuire l'oggetto su più siti utilizzando erasure coding.

- Architettura per lettura/scrittura active-active: lo storage deve avere un'architettura active-active su più siti con un unico namespace globale e accessibilità universale (object, file e HDFS), ciò consente di accedere ai contenuti da qualunque luogo, con qualsiasi applicazione o dispositivo. Il fatto di avere bucket di dati distribuiti su più siti consentono letture e scritture da e verso qualunque ubicazione nel mondo. Inoltre lo storage deve offrire una funzionalità di caching geografico che identifica i pattern di accesso a più siti ed esegue il caching dei dati presso la posizione in cui si verifica il maggior numero di accessi.

- Accesso completo ai dati: lo storage deve consentire l'accesso simultaneo ai dati con più interfacce. Lo storage deve supportare in particolare i protocolli per Object, HDFS, NFS e CIFS. Per Object, deve supportare le API Object standard di settore Amazon S3 e OpenStack Swift. Inoltre deve essere possibile interagire con gli stessi dati tramite HDFS, compatibile con distribuzioni Hadoop come Cloudera ed Hortonworks.

- Multi-tenancy: lo storage deve avere funzionalità multi-tenant, in modo da avere l'elasticità necessaria per espandere o modificare le offerte di servizio di storage, per soddisfare le esigenze di una utenza diversificata e per garantire l'integrità dei dati dei clienti archiviati su array comuni. Le funzionalità di monitoraggio e generazione di report

possono essere personalizzate per fornire a tenant e altri utenti viste personalizzate specifiche dei propri ambienti di storage con più tipi di dati.

- Misurazione a scopo di chargeback: lo storage deve poter tenere traccia dell'utilizzo dello storage da parte dei tenant e per singolo utente.

Di seguito sono riportati i requisiti funzionali minimi della Componente Tier3 (Object Storage) che la fornitura dovrà rispettare:

Componente Tier 3 - Object Storage - Requisiti Minimi Obbligatori
ID requisito	Descrizione caratteristiche	Richiesta Minima
R.CI.T3.1	Lo spazio storage deve essere almeno di 140TB RAW	Si
R.CI.T3.2	La connettività deve essere di almeno 2 (due) porte a 10GbE	Si
R.CI.T3.3	Il fornitore deve prevedere un singolo punto di contatto per hardware e software della piattaforma storage ad oggetti garantendo SLA (Service Level Agreement) di risposta su entrambe le componenti.	Si
R.CI.T3.4	Lo storage ad oggetti deve supportare l’architettura multi-tenant con la possibilità di applicare quote/limiti su specifiche sezioni.	Si
R.CI.T3.5	Lo storage ad oggetti deve essere espandibile con nuovi dischi (capacità) e/o nodi addizionali (performance) in modalità ‘non disruptive’ senza interruzione di servizio e con il supporto al ribilanciamento dei dati.	Si
R.CI.T3.6	Lo storage ad oggetti deve supportare i protocolli SNMP e Syslog per il recupero delle informazioni associate.	Si
R.CI.T3.7	Lo storage ad oggetti deve fornire la possibilità di impostare manualmente i valori di default per la retention di differenti categorie di oggetti/contenuti nel caso in cui non sia possibile farlo a livello applicativo.	Si
R.CI.T3.8	Lo storage ad oggetti deve consentire all’amministratore di specificare le expiration policies affinché i dati siano automaticamente rimossi dal sistema allo scadere di determinati intervalli di tempo senza che vengano richiesti ulteriori interventi da parte dell’utente e/o dell’applicazione.	Si
R.CI.T3.9	Lo storage ad oggetti deve consentire di impostare il periodo di retention sia quando l’oggetto viene archiviato per la prima volta sia quando si verifica un determinato evento.	Si
R.CI.T3.10	Lo storage ad oggetti deve consentire l’operazione di “hold” di un particolare oggetto affinché venga proibita la cancellazione dello stesso fino a che la condizione di ‘hold’ non venga rimossa. Questo deve essere garantito anche se dovesse avvenire oltre il periodo di retention.	Si
R.CI.T3.11	Lo storage ad oggetti deve poter proteggere qualsiasi oggetto con meccanismi di erasure coding.	Si
R.CI.T3.12	Lo storage ad oggetti deve supportare repliche tra un numero di siti maggiore di 2.	Si
R.CI.T3.13	Lo storage ad oggetti deve consentire la ricerca sui metadati.	Si
R.CI.T3.14	Lo storage ad oggetti deve continuare ad operare in seguito al guasto di un disco o nodo anche in caso di mancata connettività coi siti remoti. La ricostruzione dei dischi e/o dei nodi deve sfruttare i meccanismi di erasure coding all’interno dello stesso sito per evitare di minimizzare il consumo della banda sulla rete WAN e di conseguenza ridurre i tempi richiesti al ripristino completo dei dati. In caso di guasto a nodi o dischi, lo storage ad oggetti deve ridistribuire i dati esposti su quanti più dischi e nodi possibili per beneficiare dei parallelismi e ridurre ulteriori rischi.	Si
R.CI.T3.15	In caso di guasto a nodi o dischi, lo storage ad oggetti deve ridistribuire i dati esposti su quanti più dischi e nodi possibili per beneficiare dei parallelismi e ridurre ulteriori rischi.	Si
R.CI.T3.16	Lo storage ad oggetti deve supportare l’encryption di tutti i dati sia in modalità ‘at rest’ che ‘in-flight’	Si

R.CI.T3.17	Lo storage ad oggetti deve supportare funzionalità di ‘versioning’ per conservare e proteggere le modifiche al singolo oggetto.	Si
R.CI.T3.18	Lo storage ad oggetti deve essere gestibile e monitorabile attraverso l’interfaccia web integrata, CLI & RESTful APIs.	Si

Tabella 3.3.12

3.3.8 Componente Software

Di seguito la lista dei prodotti software del servizio di produzione dell’infrastruttura CI che devono essere inclusi nella fornitura con relativa descrizione.

- VMware vCloud Xxxxx 0000 Enterprise (include vSphere 7 Enterprise Plus for vCloud Suite and vRealize Xxxxx 0000 Enterprise);

- VMware vCenter Server 6 Standard for vSphere;

- VMware Workspace One for VDI (include VMware Horizon 7 Enterprise);

- VMware NSX Enterprise Data Center Enterprise Plus;

- VMware PKS Enterprise.

Il volume di licenze necessarie per la componente software del servizio di produzione dell’infrastruttura CI del DC-LE dovrà rispettare i valori minimi riportati nella seguente Tabella 3.3.13:

Componente Software - Requisiti Minimi Obbligatori

Volume di licenze minimo per la componente software del servizio di produzione.

ID requisito

Prodotto Software

Versione minima

Codice Prodotto

Quantità Minima

R.CI.CS.1

VMware vCloud Xxxxx 0000 Enterprise (contains vSphere 7 Enterprise Plus for vCloud Suite and vRealize Xxxxx 0000 Enterprise)

Enterprise per processor

CL19-ENT-A

16 CPU

R.CI.CS.2

VMware vCenter Server 6 Standard for vSphere

Standard per processor

VCS6-STD-A

R.CI.CS.3

VMware Workspace One for VDI (include VMware Horizon 7 Enterprise)

Enterprise

WSU-AECVP-36PT0-A1S

100 CPS

R.CI.CS.4

VMware NSX Data Center Enterprise Plus

Enterprise plus per processor

NX-DC-EPL-A

16 CPU

R.CI.CS.5

VMware PKS Enterprise (Starter Pack 000 Xxxxx)

Xxxxxxxxxx

XXX-XXX-000X-0X-XXXX-X

100 Core

Tabella 3.3.13

3.3.8.1 VMware vCloud Xxxxx 0000 Enterprise

La componente vCloud Suite Enterprise 2019 deve essere impiegata per fornire la funzione di virtualizzazione (hypervisor) e di gestione dei sistemi IT virtualizzati per soddisfare le seguenti necessità:

- Virtualizzazione (VMware vSphere): consentire ad un server fisico ospitante di eseguire diverse macchine virtuali con i relativi (diversi) sistemi operativi;

- Monitoring e Performance Management (vRealize Operations): garantire disponibilità e prestazioni dei carichi di lavoro e delle infrastrutture;

- Compliance Management (vRealize Operations): garantire la conformità a standard di sicurezza e template di riferimento industriali delle infrastrutture;

- Log Management (vRealize Log Insight): raccogliere e indicizzare i log dell’infrastruttura per rilevare malfunzionamenti e supportare le attività di identificazione delle cause;

- Capacity Management e Planning (vRealize Operations): gestire e pianificare la capacità di risorse di computazione, storage e networking;

- Automazione (vRealize Automation): eseguire il provisioning automatizzato in modalità self-service delle configurazioni infrastrutturali e dei carichi di lavoro attraverso blueprint di servizi messi a catalogo;

- Costing e Showback (vRealize Business for Cloud): determinare il costo delle infrastrutture che supportano i carichi di lavoro applicativi e ripartirli per le diverse entità organizzative che ne dispongono.

3.3.8.2 VMware vCenter Server 6 Standard for vSphere

VMware vCenter Server offre una piattaforma centralizzata ed estensibile per la gestione dell'infrastruttura virtuale. vCenter Server consente di gestire gli ambienti VMware vSphere assicurando agli amministratori IT un controllo semplificato e automatizzato sull'ambiente virtuale per distribuire l'infrastruttura in tutta sicurezza.

3.3.8.3 VMware Workspace One for VDI

VMware Workspace ONE è una piattaforma di Digital Workspace basata sull'intelligence che consente di distribuire e gestire in modo semplice e sicuro qualsiasi app su qualunque dispositivo, integrando funzionalità di controllo dell'accesso, gestione delle applicazioni e gestione degli endpoint multipiattaforma.

VMware Workspace ONE include VMware Horizon 7 Enterprise che consente di distribuire agli utenti finali applicazioni e desktop virtualizzati o in hosting tramite un'unica piattaforma. Questi servizi applicativi e desktop, che comprendono app in hosting Servizi desktop remoto (RDS), applicazioni pacchettizzate con VMware ThinApp®, app SaaS, sono tutti accessibili tramite un singolo Digital Workspace da qualsiasi dispositivo, sede, supporto e connessione, senza alcun impatto sull'esperienza d'uso. Utilizzando al meglio la gestione dell'intero ambiente dell'area di lavoro ed essendo ottimizzato per il Software-Defined Data Center, Horizon 7 aiuta a controllare, gestire e proteggere tutte le risorse Windows necessarie agli utenti finali, con la velocità desiderata e l'efficienza richiesta.

3.3.8.4 VMware NSX Enterprise Data Center Enterprise Plus

La piattaforma di virtualizzazione della rete VMware NSX è uno dei tre pilastri dell'architettura del Software Defined Data Center di VMware.

VMware NSX è integrato nativamente nell’hypervisor di VMware e permette di ottenere nell'ambito network una rivoluzione simile a quella ottenuta da ormai più di dieci anni nell'ambito server con la piattaforma di virtualizzazione VMware vSphere, in quanto così come chi gestisce i server può oggi creare virtual machine definite via software, effettuare snapshot, cancellazioni, rollback con pochi clic del mouse o in modo programmatico e automatico senza "toccare" in alcun modo i server fisici, con NSX chi gestisce le reti può definire virtual network, creandole e salvandole, con snapshot, cancellazioni, restore, modifiche, etc con pochi clic o in modo programmatico senza nessuna riconfigurazione degli apparati di rete fisica.

VMware NSX Data Center è la piattaforma di virtualizzazione e sicurezza della rete che consente una rete cloud virtuale, un approccio software-defined alla rete che si estende attraverso data center, cloud e framework applicativi. Con NSX Data Center, la rete e la sicurezza vengono avvicinate all'applicazione ovunque sia in esecuzione, dalle macchine virtuali (VM) ai container fino al bare metal. Come il modello operativo delle VM, le reti possono essere fornite e gestite indipendentemente dall'hardware sottostante. NSX Data Center riproduce l'intero modello di rete nel software, consentendo la creazione e il provisioning in pochi secondi di qualsiasi topologia di rete, dalle reti multi-tier semplici a quelle complesse. Gli utenti possono creare più reti virtuali con requisiti diversi, sfruttando una combinazione di servizi offerti tramite NSX o da un ampio ecosistema di integrazioni di terze parti, dai firewall di prossima generazione alle soluzioni di gestione delle prestazioni, per creare ambienti intrinsecamente più agili e sicuri. Questi servizi possono quindi essere estesi a una varietà di endpoint all'interno e attraverso le nuvole.

3.3.8.5 VMware PKS Enterprise

VMware PKS rappresenta un servizio containerizzato di produzione basato su Kubernetes e dotato di funzionalità̀ di rete avanzate, registro di container privato e gestione dell’intero ciclo di vita. Questa soluzione semplifica notevolmente il deployment e il funzionamento dei cluster Kubernetes, permettendo di eseguire e gestire i container su vSphere e nei public cloud secondo necessità.

VMware PKS riunisce Kubernetes, BOSH, VMware NSX-TTM Data Center e Harbor per creare un servizio di container ad alta disponibilità̀. VMware PKS mette insieme tutti questi moduli Open Source e commerciali per distribuire e gestire in modo efficiente Kubernetes e i container in esecuzione su di esso.

L’adozione di un Software-Defined Data Center VMware con VMware PKS per eseguire e orchestrare i container su macchine virtuali invece che su hardware fisico risponde a tutti i requisiti operativi, di gestione e di sicurezza per le applicazioni containerizzate estendendone al contempo la portabilità̀ al cloud.

La scelta di VMware PKS per eseguire i container su macchine virtuali in un SDDC VMware abbina i vantaggi di una tecnologia di virtualizzazione comprovata ai vantaggi emergenti dei container e dell’orchestrazione di Kubernetes. Questo

connubio crea una soluzione multi-cloud sostenibile con il potere e la flessibilità̀ di attuare la propria strategia nativa per il cloud.

3.3.9 Componente Servizi a Catalogo

In questo paragrafo sono descritti i requisiti minimi della Componente dei Servizi a Catalogo che saranno abilitati per mezzo dell’infrastruttura CI del DC-LE. Attraverso i Servizi a Catalogo gli utenti finali avranno accesso alle risorse virtuali dell’infrastruttura CI del DC-LE. Tale modello di accesso si basa sul paradigma di cloud computing definito con il termine IaaS (Infrastructure as a service).

In particolare vengono esplicitate le attività minime attese nel contesto dell’implementazione della soluzione e le caratteristiche dei servizi di supporto on-site post-rilascio e di assistenza sistemistica.

La fornitura dovrà prevedere la realizzazione di una soluzione IaaS, integrata con l’infrastruttura CI del DC-LE, in grado di fornire in maniera veloce e in modalità self-service, macchine virtuali (VM as a Service), virtualizzazione del desktop (Desktop as a Service), storage (Storage as a Service) on-demand e container (Container as a Service).

In particolare per la parte relativa ai container non è richiesta la modalità self-provisioning, ma la Società dovrà comunque presentare a catalogo le varie configurazioni disponibili per il consumo degli utenti; le modalità di deployment richieste sono meglio indicate nella sezione ”Note sul Layer di Virtualizzazione per Container”.

La soluzione dovrà quindi includere almeno i seguenti elementi standard:

- Software per la Virtualizzazione dei server;

- Software di Orchestrazione per la definizione di un Service Catalog tramite cui richiedere ed ottenere Virtual Machine, Desktop Virtuali, Storage e Container;

- Installazione software;

- Configurazione di tutte le componenti precedenti;

- Supporto on-site post rilascio;

- Assistenza sistemistica.

L’architettura di riferimento dovrà basarsi sui layer indicati nella Figura 3.5 e meglio descritti nel seguito. Il modello architetturale scelto per la realizzazione di quanto sopra esposto è basato sui componenti software di VMware come descritto nel paragrafo precedente, attraverso cui dovrà essere veicolata la gestione di tutte le risorse infrastrutturali e su cui dovrà essere costruito un catalogo servizi da esporre agli utilizzatori finali.

Figura 3.5: Schema logico IaaS

La soluzione dovrà prevedere la presenza di uno strato di orchestrazione in grado di gestire le richieste di Compute as a Service e di Storage as a Service, effettuate dagli utenti attraverso un Portale Self-Service ed un Service Catalog messo loro a disposizione a tale scopo.

Le componenti architetturali principali dovranno essere almeno le seguenti:

Portale self-service: Il portale self-service dovrà permettere di standardizzare le richieste di supporto o di risorse/servizi IT

e di automatizzarne il provisioning, riducendo significativamente l’effort di gestione e il tempo di rilascio. Il portale è destinato sia agli utenti finali, tramite il quale effettuare richieste di supporto piuttosto che di risorse e servizi IT, sia al dipartimento IT per la gestione delle attività di supporto agli utenti finali e per la gestione delle richieste IT e dell’infrastruttura a supporto.

Aspettative del portale self-service: (flussi approvativi, definizione profilazione delle utenze, RBAC – Role Based Access Control).

Orchestratore: L’Orchestratore costituisce il motore della soluzione, è deputato all’esecuzione di WorkFlow pre-integrati (modelli e pacchetti pronti all’uso) che racchiudono le operazioni necessarie per l’esecuzione automatizzata dei processi di provisioning.

Tale strato dovrà gestire tutti i flussi autorizzativi che saranno necessari per tracciare e permettere a tutti i proprietari (owner) della catena di approvazione di esprimere il proprio consenso al processamento della richiesta.

Dovranno quindi essere definite policy e profilazioni in accordo alle indicazioni di dettaglio che verranno condivise con il CNR durante la fase di progettazione esecutiva a valle dell’assegnazione dell’appalto.

L’infrastruttura fornita, che si mappa sull’architettura precedentemente descritta, dovrà essere costituita dai seguenti macro-elementi:

- Layer fisico di Computing, Network e Storage: Infrastruttura Convergente;

- Layer di Virtualizzazione Compute: VMware vSphere;

- Layer di Orchestrazione: VMware vRealize Automation e Orchestration (vRA e vRO);

- Layer di Monitoraggio e Controllo: VMware Realize Operations (vROps);

- Layer di Virtualizzazione Network (SDN): VMware NSX;

- Layer di Virtualizzazione Desktop (VDI): VMware Horizon 7;

- Layer di Virtualizzazione per Container (PKS): VMware Enterprise PKS.

Note sul Layer di Monitoraggio e Controllo

Per quanto riguarda il Layer di Monitoraggio e Controllo dovrà essere descritta la personalizzazione di VROps che si intende sviluppare, per integrarsi con gli strumenti di controllo dell’Infrastruttura CI del DC-LE; dovranno essere altresì descritte le modalità di gestione di tale sistema integrato di monitoraggio e definito il processo di Monitoraggio e Controllo che possa permettere ai referenti del DC-LE di:

- avere accesso ad un cruscotto centralizzato di visualizzazione e gestione allarmi relativi sia al Layer Infrastrutturale che a quello Virtualizzato del sistema CI del DC-LE;

- poter eseguire dei cambi di configurazione del tool di Monitoraggio, in accordo ad una profilazione specifica, del sistema CI del DC-LE.

Il progetto di dettaglio del processo di Monitoraggio e Controllo che dovrà contemplare anche la definizione di ruoli, profili, risorse sotto monitoraggio, notifiche, report e più in generale azioni da avviare a fronte di specifici trigger (soglie, allarmi, etc. etc.) sarà oggetto di idoneo approfondimento durante la fase di progettazione esecutiva.

Note sul Layer Virtualizzazione Network

Per quanto riguarda il Layer SDN, il software VMware NSX dovrà essere configurato per ottimizzare e automatizzare tutta la componente di gestione del network nell’ambito dei servizi richiesti a catalogo, ove applicabile; è richiesto alle Società di descrivere le modalità con cui intende soddisfare tale requisito.

Note sul Layer di Virtualizzazione per Container

Per quanto riguarda il Layer per la gestione dei Container, la soluzione non dovrà includere un deployment in self- provisioning completamente automatizzato, ma il requisito minimo che viene richiesto di soddisfare è che sia gestita attraverso un work-flow autorizzativo e procedurale/manuale che abbia come risultato finale la fruizione da parte dell’utente che ne ha fatto richiesta, dei container selezionati via portale.

3.3.10 Attività di installazione e configurazione dell’infrastruttura CI

3.3.10.1 Installazione e configurazione di base delle componenti hardware e software

Dovranno essere indicate tutte le attività di installazione e configurazione di base delle componenti hardware e software della soluzione CI del DC-LE.

Per quanto riguarda i test case e criteri di accettazione per i collaudi dovranno essere descritti in un Piano di Test e Accettazione che sarà oggetto di definizione puntuale durante la fase di progettazione esecutiva.

In particolare le attività inerenti la fase installazione e configurazione del layer Infrastrutturale dovranno contemplare almeno le seguenti:

- Disimballo del materiale e relativo ritiro e smaltimento degli imballi;

- Posizionamento dei sistemi nella posizione definita e concordata con NANOTEC;

- Installazione e attivazione delle apparecchiature HW dell’infrastruttura CI del DC-LE in fornitura;

- Inizializzazione dei sistemi richiesti per le successive attività di configurazione;

- Inserimento degli apparati di connettività LAN in fornitura e collegamento cavi alla CDCN-LE;

- Inserimento degli apparati di connettività LAN in fornitura e collegamento cavi agli apparati;

- Implementazione delle configurazioni di rete (creazione VLAN, etc.);

- Inserimento degli apparati di connettività SAN in fornitura e collegamento cavi;

- Implementazione delle configurazioni di SAN (definizione zoning, etc.).

3.3.10.2 Configurazioni delle Componenti del Layer di Virtualizzazione

Per quanto riguarda la parte di virtualizzazione è richiesta la configurazione di una Virtual Infrastructure (VI) basata su VMware vShpere. In tale contesto dovrà essere configurato almeno un vCenter da cui sarà possibile gestire tutta l’infrastruttura virtuale che si andrà a creare attraverso il portale di orchestrazione.

3.3.10.3 Configurazioni delle Componenti del Layer di Automazione e Orchestrazione

Tra le attività di configurazione del DC-LE dovrà essere inclusa anche la configurazione di un portale di servizio per le attività di management, controllo e orchestrazione dei servizi e di utilizzo delle risorse virtuali computazionali, di archiviazione, di rete, resi disponibili con l’infrastruttura virtuale del sistema convergente del DC-LE.

Per quanto riguarda la parte di automazione/orchestrazione dovrà essere previsto quanto segue:

- definizione del Portale Self-Service

- definizione della profilazione degli utenti

- definizione dei flussi autorizzativi della catena di approvazione

- definizione del Service Catalog per l’erogazione dei servizi di:

o VM as a Service (VMaaS):

▪ Definizione ed implementazione di flussi (blueprint) dedicati alla creazione delle VM indicate nel catalogo e al loro deployment automatizzato per renderne possibile l’uso all’utente.

▪ Nel catalogo dovrà essere possibile selezionare tra diverse tipologie di VM (flavor); nella Tabella

3.3.14 viene proposto un esempio di possibile categorizzazione dei flavor.

FLAVOR	vCPU	vGPU	Memoria	Disco di sistema	Disco dati
Basic	1	0%	1Gb	20 Gb	20Gb
Bronze	2	20%	2 Xx	00 Xx	000 Xx
Silver	4	50%	4 Xx	00 Xx	000 Xx
Gold	8	1	8 Xx	00 Xx	000 Xx

Tabella 3.3.14

La caratterizzazione definitiva sarà comunque oggetto di discussione e accordo tra le parti a valle dell’assegnazione dell’appalto.

o Desktop as a Service (DaaS):

▪ Definizione ed implementazione di flussi (blueprint) dedicati alla creazione delle VDI indicate nel catalogo e al loro deployment automatizzato per renderne possibile l’uso all’utente.

▪ Nel catalogo dovrà essere possibile selezionare tra diverse tipologie di VDI (flavor); nella Tabella

3.3.15 viene proposto un esempio di possibile categorizzazione dei flavor.

FLAVOR	vCPU	vGPU	Memoria	Disco di sistema	Disco dati
Basic	1	0%	1Gb	20 Gb	20Gb
Bronze	2	20%	2 Xx	00 Xx	000 Xx

Silver	4	50%	4 Xx	00 Xx	000 Xx
Gold	8	1	8 Xx	00 Xx	000 Xx

Tabella 3.3.15

La caratterizzazione definitiva sarà comunque oggetto di discussione e accordo tra le parti a valle dell’assegnazione dell’appalto.

o Storage as a Service (XXxxX)

▪ Definizione ed implementazione di flussi (blueprint) dedicati alla creazione delle partizioni storage indicate nel catalogo ed al loro deployment automatizzato per renderne possibile l’uso all’utente.

▪ Nel catalogo dovrà essere possibile selezionare tra diverse capacità disco; la Tabella 3.3.16 fornisce un esempio di quanto richiesto, da definire compiutamente nella fase di progettazione di dettaglio a valle dell’assegnazione dell’appalto.

Tier	Capacità
Advanced	300 Gb
Basic	150 Gb

Tabella 3.3.16

La caratterizzazione definitiva sarà comunque oggetto di discussione e accordo tra le parti a valle dell’assegnazione dell’appalto.

o Container as a Service (CaaS)

▪ Definizione ed implementazione di flussi (blueprint) dedicati alla creazione di applicazioni in container a catalogo per servizi di produzione ed al loro deployment ed esecuzione per gli utenti del servizio.

▪ Non è richiesto che la modalità di deployment sia in self-provisioning. Il flusso di deployment può seguire altre modalità, anche parzialmente automatizzate o manuali; la Società dovrà indicare la modalità che intende usare evidenziandone i benefici.

▪ Nel catalogo dovrà essere possibile selezionare tra diverse tipologie di container; la Tabella 3.3.17 fornisce un esempio di quanto richiesto, da definire compiutamente nella fase di design di dettaglio a valle dell’assegnazione dell’appalto.

FLAVOR	vCPU	vGPU	Memoria Container	Spazio Container
Basic	1	0%	1Gb	20 Gb
Bronze	2	20%	0 Xx	00 Xx
Silver	4	50%	4 Xx	00 Xx
Gold	8	1	8 Xx	00 Xx

Tabella 3.3.17

La caratterizzazione definitiva sarà comunque oggetto di discussione e accordo tra le parti a valle dell’assegnazione dell’appalto.

3.3.10.4 La fornitura Servizi

Le attività necessarie alla realizzazione della soluzione XxxX dovranno seguire un approccio metodologico che preveda almeno le seguenti fasi:

- Fase 1: Avvio Attività (kick-off);

- Fase 2: Pianificazione e Progettazione di Dettaglio della Soluzione;

- Piani di Test e di Validazione;

- Fase 3: Installazione e Configurazione layer Infrastrutturale

- Fase 4: Configurazione Soluzione IaaS;

- Fase 5: Test e Validazione;

- Fase 6: Rilascio Soluzione;

- Fase 9: Supporto Post-rilascio e Assistenza sistemistica.

Dovranno essere dettagliate sia le attività specifiche associate ad ognuna delle fasi indicate in precedenza che i relativi deliverable.

Dovranno essere altresì indicati i tempi previsti per la realizzazione di quanto in ambito di fornitura, per ogni fase.

3.3.10.5 Le attività di Configurazione della Soluzione

In questa sezione vengono indicate a titolo generale, indicativo e non esaustivo, le attività di configurazione delle componenti che dovranno costituire la soluzione IaaS.

3.3.10.6 Attività di dettaglio minimali

La soluzione dovrà avere le caratteristiche indicate di seguito per ciascuna delle componenti in ambito.

Attività:

- Installazione e configurazione di base delle componenti hardware e software

- Configurazioni delle Componenti del Layer di Virtualizzazione

- Configurazioni delle Componenti del Layer di Automazione e Orchestrazione (vRA e vRo Orchestrator)

- Configurazione delle Componenti di Monitoraggio

- Servizi di supporto Post-rilascio e di Assistenza sistemistica

3.3.10.7 Coordinamento attività

Le attività precedentemente indicate dovranno essere coordinate da un referente della Società che sarà il focal point per tutte le esigenze relative alla realizzazione di quanto previsto in fornitura in termini di hardware, software e deliverable. In particolare tale figura rappresenterà l’interfaccia ufficiale per la gestione delle comunicazioni e di tutte le esigenze inerenti la fornitura ed il rilascio della soluzione insieme alla la sua operatività, al fine di minimizzare tempi e rischi e garantire la qualità auspicata.

3.3.10.8 Supporto post-rilascio e Assistenza sistemistica

La Società dovrà prevedere nell’ambito della fornitura i servizi di supporto descritti nei paragrafi che seguono.

3.3.10.9 Supporto post-rilascio

Dovranno essere fornite delle giornate di supporto on-site di un consulente specializzato sui software che realizzano la soluzione IaaS, al fine di aiutare il CNR ad acquisire le necessarie competenze per preservare, manutenere, monitorare e fare reportistica sulla soluzione appena implementata e rilasciata.

Tale figura provvederà quindi ad un appropriato knowledge transfer e a dare indicazioni pratiche sulla gestione quotidiana della soluzione.

Lo specialista dovrà essere presente on-site durante il normale orario lavorativo (8 ore/giorno) dal lunedì al venerdì, per un periodo di tempo predefinito e pari a 3 settimane, ovvero 15 giorni lavorativi. L’avvio del supporto post-rilascio sarà formalizzato tramite modulo specifico, a valle del rilascio ufficiale della soluzione IaaS.

3.4 Servizi di Assistenza e Manutenzione Sistemi CDCN-LE, HPC e CI

Il servizio di manutenzione HW e SW offerto dalla Società sulle componenti HPC, CI e CDCN-LE dovrà avere la durata minima come specificato di seguito:

• Componenti HW afferenti ai sistemi HPC e CDCN-LE: 5 anni

• Componenti SW non Open Source afferenti ai sistemi HPC e CDCN-LE: 3 anni

• Componenti HW afferenti al sistema CI: 3 anni

• Componenti SW afferenti al sistema CI: 3 anni

• Componenti SW afferenti alla componete VMware: 3 anni

Costituirà elemento migliorativo soggetto a punteggio una estensione della durata per un massimo di due anni oltre il periodo minimo richiesto.

La durata del servizio richiesta si intende a partire dalla data di collaudo della fornitura.

Dovranno essere erogati per la durata richiesta i servizi di manutenzione e assistenza come sotto riportati:

A) Servizio di manutenzione on-site

B) Servizio di assistenza tramite call-center

Considerata la criticità della fornitura, si ritiene indispensabile che tali servizi siano erogati direttamente dai produttori delle componenti hardware con i quali il personale tecnico del CNR intende interagire direttamente e senza intermediazione della Società.

Il servizio di manutenzione di tutti gli apparati Hardware dovrà essere quello ufficiale del produttore (casa madre) fatte salve le componenti Infiniband afferenti alla rete di interconnessione a bassa latenza, i cablaggi e le componenti dell’infrastruttura tecnologica di cui ai paragrafi 3.2.6 e 3.5. La Società dovrà pertanto agire esclusivamente in regime di rivendita del servizio ufficiale.

Dovrà pertanto essere inclusa nella documentazione tecnica presentata in gara una dichiarazione del produttore attestante la tipologia e i dettagli del servizio offerto ed il ruolo della Società nella proposta di gara.

In caso di dubbi o incongruenze il CNR si riserva la possibilità di chiedere chiarimenti direttamente a casa madre. Si dettagliano nel seguito modalità e requisiti dei servizi richiesti.

3.4.1 Servizio di manutenzione on-site

Durante i periodi di garanzia il Produttore degli apparati HW dovrà assicurare i servizi di assistenza e manutenzione nel rispetto degli SLA previsti per la manutenzione, con interventi di sostituzione delle eventuali parti guaste da effettuarsi presso i locali dell’istituto comprensivi di:

• eliminazione degli inconvenienti che hanno determinato la richiesta di intervento;

• controllo e ripristino delle normali condizioni di funzionamento;

• fornitura ed applicazione di parti di ricambio originali (della stessa marca, modello e tipo di quelle sostituite);

• redazione del relativo “verbale di intervento”.

Le attività inerenti il servizio di manutenzione on-site dovranno essere erogate in modo da coprire l’intero arco della giornata lavorativa dell’istituto, ossia dalle 9:00 – 18:00, per cinque giorni lavorativi settimanali, dal lunedì al venerdì. L’intervento on site per la sostituzione delle eventuali parti guaste dovrà avvenire entro il giorno lavorativo successivo all’apertura del guasto.

Le parti sostituite saranno ritirate dal servizio di assistenza tecnica e diventeranno proprietà del Produttore.

3.4.2 Servizio di assistenza tramite call-center

A supporto delle attività di manutenzione il Produttore degli apparati HW dovrà mettere a disposizione un apposito Call Center quale centro di ricezione e gestione delle chiamate relative alle richieste di informazione ed assistenza.

Sarà cura del personale del CNR preposto alla manutenzione, aprire una chiamata di guasto (trouble ticketing) ed annotare su un apposito registro la data e l’ora della richiesta di intervento.

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.

Le attività inerenti il servizio di assistenza tramite call-center dovranno essere erogate in modo da coprire l’intero arco della giornata, ossia dalle 0:00 alle 24:00, per 7 giorni su 7 su 365 giorni l’anno.

3.4.3 Assistenza sistemistica per la componente CI

Dovrà essere fornito un servizio di assistenza remota che comprenda tutte le attività necessarie al ripristino dei servizi offerti a catalogo nel caso di malfunzionamenti software; in particolare dovrà includere le seguenti attività/possibilità:

- Help desk telefonico;

- Supporto email;

- Interventi di supporto sistemistici remoti;

- Interventi di supporto sistemistici onsite (effettuati on-demand secondo uno SLA di intervento di 4gg lavorativi, per un massimo di 15gg/anno);

- Aggiornamenti del Catalogo Servizi (fino a 5 interventi di modifica configurazione e 5 interventi per l’introduzione di nuovi blueprint).

Il servizio di manutenzione dovrà essere erogato, a seconda delle necessità, attraverso interventi effettuati da remoto e/o telefonicamente da un tecnico specializzato.

Gli eventuali interventi on-site di uno specialista, potranno essere effettuati durante il normale orario lavorativo (8 ore/giorno) dal lunedì al venerdì; non sono previsti interventi di questo tipo durante i fine settimana o i giorni festivi.

Il CNR per poter consentire un migliore livello di assistenza metterà a disposizione una connessione VPN o strumenti di connessione remota analoghi.

La descrizione delle linee-guida del processo di attivazione delle richieste, della gestione delle stesse e la descrizione delle modalità di intervento dovranno essere incluse nell’offerte delle Società.

3.5 Requisiti di allestimento della sala del DC-LE

La sala del DC-LE individuata presso la sede NANOTEC (Edificio E – Piano Terra), richiede un adeguamento infrastrutturale al fine di poter ospitare le apparecchiature HW e parte dell’infrastruttura tecnologica per la fornitura “Chiavi in mano” di

un nuovo datacenter DC-LE per il calcolo ad alte prestazioni e relativi servizi.

Si riporta in Figura 3.6 la planimetria del locale interessato che ospiterà la sala del DC-LE:

Figura 3.6: Planimetria locale individuato presso NANOTEC (Edificio E - Piano Terra)

La sala del DC-LE dovrà essere predisposta per ospitare un’isola compartimentata per l’alloggiamento degli armadi rack che ospitano le apparecchiature HW e di refrigerazione del DC-LE. Dovrà essere predisposto anche uno spazio per future espansioni del DC-LE nella misura del 20% rispetto alle apparecchiature totali della presente fornitura.

Deve essere prevista la realizzazione di un pavimento modulare sopraelevato con finitura superficiale vinilica costituito da supporti regolabili e travi componibili.

Il pavimento in dettaglio deve essere composto dai seguenti elementi principali oppure da elementi con funzionalità similari o migliorative:

- piedini micrometrici in acciaio zincato con stelo filettato completi di piattello, dado di regolazione con tacche di bloccaggio, testa di appoggio a quattro vie, munita di alette verticali fermapannello, predisposta per l'inserimento dei traversini e completa di guarnizione conduttiva in PVC;

- struttura di collegamento con traversini a bordi smussati di idonea sezione in acciaio stampato zincato fissata mediante viti e completa di guarnizione superiore;

- pavimento in pannelli modulari di 60 x 60 cm con le seguenti caratteristiche: Il pavimento deve inoltre essere in possesso di un coefficiente di attrito conforme a quanto previsto dal DPR 24 luglio 1996, n°503 recante norme per l'eliminazione delle barriere architettoniche negli edifici, spazi e servizi pubblici.

Nella realizzazione devono essere compresi e compensati gli oneri per l'aspirazione del massetto, l'accurata posa a livello, il taglio, la pulizia e l'asporto del materiale di risulta a fine installazione, la raccolta differenziata del materiale di risulta, il conferimento con trasporto in discarica autorizzata del materiale di risulta e l'indennità di discarica al fine di dare fornitura finita a regola d'arte.

Il locale dovrà essere dotato di un valore di compartimentazione al fuoco REI60 / EI60.

Allo scopo di migliorare l'efficienza energetica, la coibentazione dovrà essere estesa su tutte e quattro le pareti della stanza ostruendo le finestre attualmente presenti.

In fase di valutazione delle offerte dovrà essere premiato il layout del Data Center che garantirà:

- delimitazione delle batterie degli UPS in locale dedicato;

- visita dell’infrastruttura in sicurezza da parte di personale esterno.

La Società dovrà fornire tutta la documentazione necessaria all’ottenimento delle autorizzazioni dagli enti esterni eventualmente coinvolti (Comune, VVF, ecc.).

L’offerta tecnica dovrà comprendere la progettazione preliminare dell’infrastruttura. In fase di valutazione delle offerte, dovrà essere premiato il grado di dettaglio degli elaborati progettuali.

Il DC-LE dovrà essere dotato dei requisiti corrispondenti ad un livello Tier I ed essere predisposto dal punto di vista impiantistico all’eventuale futuro upgrade al livello Tier II.

A tal proposito la Società al momento della presentazione dell’offerta dovrà possedere i seguenti requisiti:

- Avere nel proprio organico almeno un progettista iscritto al relativo albo professionale che sia accreditato presso l’UpTime Institute (ente di certificazione di Data Centers) come ATD (Accredited Tier Designer), da almeno 2 anni. Saranno premiate con punteggio aggiuntivo le proponenti che dimostreranno di avere all’interno del proprio organico più di una risorsa con tali requisiti.

- Aver progettato e realizzato negli ultimi 3 anni infrastrutture per Data Center per un importo lavori complessivo di almeno 2’500’000,00 €, di cui almeno un appalto da 800’000,00€.

- Essere dotata delle seguenti certificazioni:

o ISO 9001 (codici IAF 28-33-35 obbligatori)

o ISO 27001

o ISO 20000

o ISO 22301

o ISO 14001

o OHSAS 18001

Ai fini di una corretta formulazione dell’offerta, le Società sono tenute, a propria cura e spese, a prendere visione dei luoghi presso i quali dovrà essere realizzato il DC-LE.

3.5.1 Caratteristiche tecniche isola compartimentata

Il nuovo DC-LE dovrà essere costituito da un’isola modulare, pre-ingegnerizzata e pre-assemblata, comprendente:

- Cage compartimentata e modulare;

- Armadi rack;

- Sistema di condizionamento con compartimentazione dei corridoi caldo e freddo;

- PDU Intelligenti switched con sistema di monitoraggio micro ambientale.

Di seguito vengono descritte le caratteristiche minime e le eventuali migliorative, delle componenti dell’isola.

Tutti i componenti dell’isola dovranno essere prodotti dallo stesso costruttore o produttore, al fine di ottenere una soluzione ingegnerizzata e integrata nativamente e mantenuta dallo stesso.

Verranno valutate soluzioni pre-ingegnerizzate, che garantiscano tempi di delivery estremamente brevi, ed una puntuale certificazione dell’infrastruttura con la possibilità di determinare in anticipo il parametro PUE “Power User Effectiveness”, il cui valore che dovrà risultare compreso tra 1,3 e 1,4.

3.5.1.1 Caratteristiche della CAGE

Il principio di base della CAGE dovrà essere la segregazione del flusso d’aria freddo a livello della fila di armadi, al fine di garantire il massimo risparmio energetico del data center.

I componenti della cage dovranno essere:

- Porte scorrevoli dotati di cornice metallica e finestra in vetro temperato, maniglie con serratura.

- Tetto del corridoio compartimentato, integrato con i rack: formato da un sistema di pannelli-tetto a moduli basculanti. I moduli dovranno essere in acciaio e cristallo ad elevata trasparenza, e dovranno essere in grado, a fronte di una temperatura specifica, di aprirsi automaticamente.

- Corridoio interno, con larghezza minima di 1200mm;

- Porta d’accesso composta da una porta scorrevole, maniglie di chiusura con chiave, dotata di spazzole atte ad impedire la fuoriuscita dell’aria fredda,

- Le porte scorrevoli dovranno essere dotate di meccanismo con chiusura ammortizzata “self-closing”,

- Le porte scorrevoli dovranno essere applicate ad entrambe le estremità del corridoio.

- Sopra gli armadi sono da prevedere 3 scomparti per la gestione dei cablaggi, dello stesso tipo e colore del corridoio

- All’interno del corridoio deve essere previsto una adeguata illuminazione realizzata mediante tubi LED dotati di sistema di rivelazione della presenza (PIR)

l sistemi di gestione dei cavi per il cablaggio strutturato dovrà essere parte integrante delle cage.

3.5.2 Caratteristiche del sistema di condizionamento del DC-LE

In questo paragrafo sono riportate le caratteristiche tecniche delle infrastrutture tecnologiche costituenti il sistema di condizionamento del DC-LE.

Caratteristiche delle unità di condizionamento interne

Le unità di condizionamento dovranno essere del tipo infra-rack, ad acqua refrigerata, connesse ad adeguato chiller del tipo free cooling. Le ventole dovranno essere del tipo a commutazione elettronica ad alta efficienza, con motore elettrico di tipo brushless.

Ogni unità interna dovrà avere una larghezza massima di 600mm.

Caratteristiche dell’unità di condizionamento esterna

L’unità esterna deve essere adeguatamente scelta in modo da garantire la possibilità di lavorare in solo free cooling con la potenza frigorifera in funzionamento normale necessaria alla dissipazione termica del carico IT offerto (temperatura acqua in: 16°, temperatura acqua out 11°, con serbatoi d’accumulo di capacità minima di 600 litri).

L’unità esterna deve essere conforme alle seguenti norme armonizzate:

- 2014/68/UE (Direttiva Attrezzature a Pressione PED);

- EN 378–2:2017 (Sistemi di refrigerazione e pompe di calore – Requisiti di sicurezza ambientali- Parte 2: Progettazione, costruzione, prova, marcatura e documentazione);

- 2006/42/CE (Direttiva Macchine);

- 2014/30/UE (Compatibilità Elettromagnetica);

- 2014/35/UE (LVD) (Direttiva Bassa Tensione);

- EN 13136:2014 (Impianti di refrigerazione e pompe di calore - Dispositivi di limitazione della pressione e relative tubazioni - Metodi di calcolo);

- EN 60204:2016 (Sicurezza delle macchine - Equipaggiamento elettrico delle macchine);

- EN 00000-0-0 (2006) (Compatibilità Elettromagnetica (EMC) – Norme generiche – Immunità);

- EN 00000-0-0 (2007) + A1 (2013) (Compatibilità elettromagnetica (EMC) —Norme generiche— Emissione per gli ambienti industriali).

Refrigeratori di fluido condensati ad aria destinati al raffreddamento o riscaldamento di acqua o miscele di acqua ed agente anticongelante, in impianti di climatizzazione civile e di raffreddamento industriale.

Tale macchina deve essere dotata di compressori Scroll con refrigerante R410A, montati in una robusta struttura in lamiera zincata verniciata con polveri epossidiche in colore RAL9002e RAL7031. Tutte le pannellature devono essere realizzate in lamiera zincata verniciata con polveri epossidiche.

Il dimensionamento e la scelta dei singoli componenti deve essere mirata al contenimento dei consumi energetici con un’ottica di risparmio energetico non solo della singola macchina frigorifera ma di tutto il sistema impianto, con particolare attenzione al contenimento delle emissioni sonore, grazie ai diversi livelli di insonorizzazione.

Saranno premiate con punteggio aggiuntivo l’unità esterna in versione “A2L ready”, ossia con refrigerante tradizionale R410A ma con tutte le predisposizioni termodinamiche e di gestione delle sicurezze per la sostituzione con refrigerante R454B.

Struttura

Basamento in lamiera zincata e verniciata con polveri di poliestere bucciato per esterni . Carpenteria in lamiera zincata e verniciata a polveri di poliestere bucciato per esterni per una efficace resistenza agli agenti corrosivi. I sistemi di fissaggio devono essere realizzati in materiali non ossidabili in acciaio al carbonio con trattamenti superficiali di passivazione. Il vano compressore deve essere completamente chiuso e accessibile su 3 lati grazie a pannelli facilmente rimovibili per semplificare al massimo tutte le operazioni di manutenzione e/o controllo.

Kit idronici

Le unità devono essere dotate di connessioni idrauliche verso l’esterno con attacchi, valvole di sfiato aria opportunamente posizionate, valvola di sicurezza (se sono presenti pompe) e flussostato a paletta acqua (per prevenire flusso d’acqua troppo basso) e sonda di temperatura acqua in uscita con funzione di termostato antigelo per evitare possibilità di ghiacciamento del circuito utilizzatore.

Il gruppo pompe deve essere integrato nella struttura della macchina ed è disposto in modo tale che i motori delle medesime siano sempre raffreddati da aria esterna. Nel caso di gruppi di pompaggio con pompa di riserva il

microprocessore deve gestire le pompe in modo da ripartire equamente il numero di ore di funzionamento, ruotando le pompe in caso di anomalia.

Circuito Frigorifero

Il circuito frigorifero deve essere realizzato impiegando esclusivamente componenti di primaria marca e operatori qualificati ai sensi della Direttiva Attrezzature a Pressione PED per tutte le operazioni di brasatura.

I componenti principali del circuito frigorifero devono essere:

- Compressori di tipo scroll progettati per funzionare con R410A uniti in configurazione tandem. (In opzione le unità possono essere offerti compressori funzionanti con refrigerante R454B).

- Scambiatore a piastre saldobrasate realizzate in acciaio INOX AISI 316.

- Condensatore a pacco alettato in tubo di rame ed alette in alluminio.

- Filtro deidratatore a cartuccia solida

- Spia di flusso con indicatore di umidità.

- Valvola di espansione elettrica a controllo elettronico.

- Valvola inversione di ciclo (pompe di calore).

- Pressostati alta e bassa pressione.

- Valvola di sicurezza.

- Valvole Xxxxxxxx per controllo e/o manutenzione.

- quanto altro necessario

Compressori

I compressori devono essere di tipo scroll progettati per funzionare con R410A e gas a basso GWP (R454B) uniti in configurazione tandem. Ognuno deve essere provvisto di indicatore di livello e valvola di scarico intermedia per ottimizzare ed efficientare il funzionamento ai carichi parziali.

I compressori devono essere installati su appositi piedini antivibranti atti a disaccoppiare il compressore dalla struttura e ridurre le vibrazioni.

Scambiatori di calore a piastre

Gli scambiatori a piastre devono essere realizzati con piastre saldobrasate in acciaio INOX AISI 316 e brasatura in rame e ottimizzati per l’uso con R410A.

Valvola di espansione elettrica a controllo elettronico

Valvola di espansione elettrica a controllo elettronico comprensiva di software studiato e ottimizzato per inseguire il comportamento del carico frigorifero in ogni condizione di utilizzo.

Gruppo motoventilante

Ventilatori di tipo assiale a 4/6 poli con pale a profilo alare in materiale plastico / alluminio ibrido, bilanciati staticamente e dinamicamente su due piani, dotati di griglia di protezione e montati con interposizione di gommini antivibranti. Il ventilatore deve essere alloggiato in apposito boccaglio dal profilo tale da ottimizzare le prestazioni aerauliche. Il controllo di condensazione in pressione deve regolare in modo continuo la velocità dei ventilatori automaticamente limitando ulteriormente l’emissione acustica dell’unità nel funzionamento notturno e ai carichi parziali (opzione).

Scambiatore di calore a pacco alettato

In tubo di rame da 8 o 10 mm di diametro ed alette in alluminio, caratterizzati da ampie superfici di scambio termico. Gli scambiatori di calore a pacco alettato dovranno essere scelti in modo da ottimizzare le perdite di carico lato aria migliorando sensibilmente i livelli acustici delle unità.

Quadro Elettrico

Il quadro elettrico delle unità di condizionamento deve essere conforme alla norma EN60204-1.

Tutto il circuito ausiliario e di comando deve essere alimentato tramite trasformatore di isolamento a bassa tensione per aumentare il grado di sicurezza.

Alimentazione standard deve essere 400V 3~ 50Hz+N.

Il quadro deve essere ventilato o riscaldato per il controllo della temperatura/umidità interna in tutti i climi in cui è installata la macchina

Deve essere presente una interfaccia hard-wired verso il BMS riportata su morsettiera numerata. Interfaccia di comunicazione optoisolata verso BMS con i seguenti protocolli:

- Modbus

- Bacnet

- Interfaccia WEB TCP/IP V4 e V6 e SNMP

Sistema di Controllo

Visualizzazione di tutte le grandezze operative generali, a livello di circuito e di singolo compressore e di ogni dispositivo controllato (valvole, pompe, ventilatori, inverter compressori, umidificatore, ecc...).

Funzione di protezione antigelo dell’evaporatore con resistenza e pompa di circolazione durante i periodi di inattività della macchina.

3.5.3 Caratteristiche tecniche armadi rack per apparecchiature informatiche

Dovrà essere fornito un numero di armadi rack adeguato alla soluzione IT offerta. Sarà premiata con punteggio aggiuntivo la fornitura e installazione di un ulteriore armadio rack.

Gli armadi server per le apparecchiature informatiche dovranno avere dimensioni di 600mm di larghezza, 1200mm di profondità, 2000mm di altezza. Gli armadi di inizio e fine corridoio dovranno avere dimensioni di 800mm di larghezza, 1200mm di profondità e 2000mm di altezza Dovranno avere un frame in alluminio, con 4 montanti regolabili in profondità anch’essi in alluminio. Devono essere accessoriabili con guide cavi verticali a seconda delle richieste del CNR. Caratteristiche di base:

- Rispetta le normative EN60950, EN60204-1, EIA-310-D Tipo A, EIA-310-D Tipo C, ETS 300 119

- DIN 41 494, IEC 297 / IEC 60297 e IEC 529 / IEC 60529

- Flange laterali poste sui lati dei montanti 19”:metallica verticale in grado di impedire il passaggio della’aria ma allo stesso tempo dotata di asole verticale chiuse con le spazzole (UL94-V0) per passaggio cavi.

- Alta capacità di carico: fino a 1500 kg.

- Porta anteriore con grigliatura almeno dell’80% di vuoto per pieno, con apertura a 180°.Porta posteriore doppio battente, sempre grigliata all’80% con apertura a 180°. Xxxxxxxx basculanti a quarto di giro con serratura

- Armadio con struttura leggera in alluminio,

- 4 montanti 19” anch’essi in alluminio con continuità.

- Kit per l’aggancio di 2 PDU senza l’ausilio di attrezzi,

- Ogni rack dovrà essere dotato di 25 blanking panels “Tool-less” per la chiusura degli spazi vuoti, certificati UL94-V0.

- I rack di inizio e fine fila saranno dotati pannelli laterali ciechi e zoccoli chiusi, di stesso materiale e colore di tutta la struttura.

- I rack di inizio e fine fila dovranno essere di dimensioni di 800x1200x2000mm, mentre quelli in centro di 600x1200x2000mm

- Sugli armadi da 600mm di larghezza le Pdu dovranno essere posizionare in modo che venga lasciato più spazio possibile per lavorare sugli apparati attivi, pertanto le pdu dovranno essere installate con le prese che guardano verso la porta posteriore dell’armadio.

- Ogni rack avrà lo zoccolo tool-less, sull’anteriore e sul posteriore per impedire il passaggio dell’aria, RAL7047.

- Tutti i rack devono avere almeno 3 asole ampie sul tetto, per l’ingresso dei cavi dall'alto.

- Sul tetto del rack saranno integrati il sistema di gestione cablaggi.

I condotti per il passaggio cavi saranno di altezza 120mm, dello stesso materiale e colorazione dei rack. E cioè:

- 1 condotto cavi di potenza (200mm)

- 1 condotto cavi dati in fibra (circa 300 mm)

- 1 condotto cavi dati in rame (circa 300mm)

Quanto descritto al fine di avere 3 condotti separati per rame, fibra e potenza.

Negli armadi larghi 600mm le prese delle PDU dovranno essere rivolte verso la porta posteriore dell’armadio al fine di massimizzare lo spazio utile per lavorare sul retro degli apparati.

3.5.4 Caratteristiche tecniche barre d’alimentazioni intelligenti - PDU

In ogni rack dovranno essere presenti le unità di distribuzione dell’alimentazione (PDU) Monitered e Switched e dovranno essere predisposte per poter gestire (plug-and-play) dei sensori ambientali per temperatura, umidità, flusso d'aria, differenze di pressione dell'aria, e ingressi contatti. Deve inoltre poter supportare webcam USB. Di seguito le caratteristiche minime:

- In ogni rack una delle PDU dovrà avere un colorazione dello chassis nero, mentre l’altra dovrà avere un differente colore a scelta del CNR (es. rosso, blu):

- Dovranno essere forniti 30 cavi di colore nero del tipo anti sgancio e 30 cavi identici ma di colore differente (es. rosso, blu) . Così da dividere le alimentazioni A e B degli apparati attivi.

- Doppia porta di connessione una 10/100/100 e una 10/100 BaseT Ethernet. Optional WiFi (802.11a/b/g/n)

- Display LCD a matrice di colori che dovrà fornire informazioni circa: tensione; corrente; potenza attiva (per linea e per interruttore); allarmi; informazioni di configurazione (nome, indirizzo IP).

- Auto orientamento del display,

- Ogni PDU dovrà essere in grado di monitorare i seguenti parametri ambientali:

o Temperatura,

o Umidità

o Flusso dell’aria,

o Differenza di pressione,

o Perdite di liquido

o Ingresso contatti

- Dovranno essere forniti un sensore temperatura ed umidità per ogni rack

- Dovrà essere fornito un sensore presenza liquidi per ogni unità interna di condizionamento CDZ

CARATTERISTICHE DELLO STRUMENTO DI MISURA DELLA PDU:

Grado di precisione (+/-1%) Misure di energia [kW, kVA, V, A, Power Factor] per linea, per interruttore di protezione e per uscita. Possibilità di gestione da remoto delle uscite (switching) realizzate tramite Relè bistabili. Colore delle PDU deve essere differenziante per linea A (es. Nero) e linea B (es. Blu). Display LCD a colori in grado di mostrare: tensione, corrente e potenza attiva (per linea, per interruttore di protezione, per uscita). Gestione degli allarmi. Informazioni di configurazione (nome, rating, informazioni sulla rete/IP). Gestione da remoto tramite HTML, JSON-RPC, SSH, Telnet, MODBUS/TCP e SNMPv3. Processore embedded con clock speed minimo 400MHZ, 16MB Flash, and 64MB RAM. Modulo di gestione della pdu rimovibile a caldo.

In particolare, dovranno essere previste, in numero adeguato alla potenza e numero di apparati HW presenti nella soluzione offerta e considerando la ridondanza, le seguenti tipologie di PDU:

• PDU Trifase 32A

⮚ Vertical zero unità con almeno 36 prese in grado di gestire un carico fino a 22,2 kVA.

⮚ Input: 400v trifase con cavo e spina conforme a IEC 60309 3P+N+E 6h 32A

⮚ Output: 24 prese C13 e 12 prese C19

⮚ Le 36 prese saranno divise su sei circuiti con protezione magneto-idraulica da 16A, insensibili quindi alle temperature del corridoio caldo.

⮚ Lunghezza massima 1780mm.

• PDU Monofase 16A

⮚ Vertical zero unità con almeno 36 prese in grado di gestire un carico fino a 11,1 kVA.

⮚ Input: 400v trifase con cavo e spina conforme a IEC 60309 3P+N+E 6h 16A

⮚ Output: 24 prese C13 e 12 prese C19

⮚ Lunghezza massima 1780mm.

3.5.5 Adeguamento Impianto elettrico

L'impianto elettrico del sistema deve riguardare tutto il complesso di distribuzione FM, luce e luce di emergenza all'interno del locale, compresi il quadro generale e eventuali sistemi di scambio di alimentazione.

A cura della Società dovranno essere attestate, all'interno del locale, le linee di alimentazione elettrica con adeguata sezione dei conduttori per garantire le prestazioni di potenza indicate.

L'alimentazione elettrica dovrà essere costituita da due linee provenienti da separate cabine di trasformazione MT/BT sostenute da un gruppo elettrogeno di soccorso di adeguata potenza e di tipo silenziato. La fornitura avrà caratteristiche 3 fasi + N 400 V 50Hz.

La linea elettrica principale dovrà essere realizzata con condotti blindati e con cavi a ridotta emissione di gas tossici e corrosivi e completi di setti tagliafuoco.

Dovrà essere realizzato un quadro elettrico per lo scambio rete/gruppo elettrogeno. Il quadro elettrico principale dovrà comprendere:

- carpenteria di contenimento delle apparecchiature di segnalazione, misura , sezionamento e protezione partenze, completa di barre DIN di distribuzione , portello trasparente con chiusura a chiave e relativi accessori;

- n° 1 multimetro remotizzabile;

- protezioni magnetotermiche differenziali in adeguato numero e tipo

- interfaccia di supervisione

I singoli moduli devono presentare sul lato frontale le diciture ad essi corrispondenti, così come i punti di sezionamento, di segnalazione e di misura. Le predette diciture devono essere realizzate a mezzo di targhette in plastica rigida.

Nella sala server dovrà essere realizzato un nuovo impianto di messa a terra e dovrà garantire il coordinamento con i dispositivi di protezione attivi presenti nell'impianto elettrico (protezioni differenziali e magnetotermiche). In particolare tutte le masse e le massa estranee dovranno essere collegate tra di loro da un conduttore di idonee dimensioni in modo da garantire l’equipotenzialità tra le masse. Tutti i conduttori di terra presenti dovranno essere collegati ad un nodo equipotenziale principale che dovrà essere collegato all'impianto di messa a terra di edificio.

L'impianto deve essere conforme alla norma CEI e di sicurezza degli ambienti di lavoro e specificatamente progettato e realizzato per alimentare infrastrutture analoghe.

3.5.6 Caratteristiche tecniche UPS

L’impianto elettrico del Data Center dovrà essere dotato di un sistema UPS di tipo modulare con possibilità di manutenzione di tipo hot-swap.

Sia il sistema di potenza che il sistema batterie dovranno avere una ridondanza minima N+1. Saranno valutati con punteggio dedicato livelli di ridondanza fino ad N+3.

3.5.6.1 Armadio di Potenza

Gruppo statico di continuità trifase modulare on-line a doppia conversione ad alto rendimento, maggiore di 96% in modalità online doppia conversione e maggiore di 99% in modalità bypass.

Classificato secondo la norma IEC 62040-3 come UPS di classe VFI-SS-111 senza trasformatore in uscita, in versione modulare, avente le seguenti caratteristiche: tensione di ingresso nominale: 400 V trifase + neutro, tolleranza della tensione di ingresso: -15/+20% a 400 V, fattore di potenza in ingresso: >0,999 alla Pn, THDI a monte < 2,5 % alla Pn, tensione di uscita nominale: 400 V trifase + neutro, THDU in uscita su carico non lineare: < 1%, sovraccarico ammesso: 1,5 In – 1 min

; 1,25 In - 10 min, frequenza: 50 Hz / 60 Hz +/-0,1%.

Prestazioni devono essere testate e verificate da un organismo indipendente accreditato (es. TÜV).

L’involucro del singolo cabinet deve essere "privo di elettronica" ed in grado di ospitare 8 moduli da 25 kVA/kW, per una potenza complessiva di 200 kVA/kW con possibilità di parallelo fino a 3 cabinet per una potenza complessiva di 600 kVA/kW.

Ogni modulo di potenza deve comprendere in un involucro indipendente: raddrizzatore, inverter, regolazione, alimentazione, caricabatteria e segnalazione luminosa di stato, per garantire la completa autosufficienza dei moduli.

I connettori del modulo per la estraibilità a caldo devono garantire una temperatura di esercizio compresa tra -40°C a +125

°C e garantire il ciclo di estraibilità> di 500 cicli.

I moduli devono essere estraibili a caldo con il sistema in modalità “on-line doppia conversione” senza commutazione in modalità di bypass o passaggio su bypass manuale.

I moduli di potenza devono avere un MTBF minimo di 700.000 ore in conformità con la norma IEC/EN62830 calcolato e verificato da un organismo indipendente accreditato. Saranno premiate con punteggio aggiuntivo i moduli certificati con MTBF di 1.000.000 di ore.

I moduli dovranno essere in grado, in caso di inserimento a caldo in un sistema in esercizio, di aggiornare il firmware senza alcun intervento dell’operatore e senza perturbare lo stato dell’ UPS.

Il bypass statico deve essere fornito all'interno di un involucro indipendente, completamente separato dal resto del telaio di supporto UPS, al fine di evitare la propagazione dei guasti e deve essere un modulo inseribile o rimovibile con il sistema funzionante in modalità “online doppia conversione” senza commutazione sul bypass manuale o spegnimento dell'UPS.

Il caricabatteria deve essere in grado di funzionare con i seguenti tipi di accumulatori: al piombo ermetico / piombo a vaso aperto / NiCd / Ioni di Litio.

L'interfaccia utente dell'UPS deve essere costituita da un display grafico touchscreen a colori per fornire comandi/avvisi e avrà a disposizione per la connessione remota una scheda dati I/O programmabile con un minimo di 3 ingressi e 4 contatti di uscita e almeno una porta RS485.

Collegamento cavi dal basso o dall’alto; grado di protezione IP 20. Prestazioni conformi EN 62040-3, e certificazione antisismica UBC-1997 Zona 4 per carpenteria standard. Sistema comprensivo di armadio di accoppiamento e bypass manuale.

Il costruttore delle apparecchiature deve essere certificato ISO9001 e ISO14001 e deve poter fornire un certificato di origine dichiarante che l'UPS è stato progettato, prodotto e testato in un paese dell' Unione Europea.

Prima accensione della macchina da parte di tecnico specializzato del costruttore. L'opera s'intende comprensiva di ogni onere annesso e connesso per renderla perfettamente funzionante e realizzata a regola d'arte.

Il dimensionamento dell’UPS dovrà tener conto sia del carico IT che del carico relativo agli impianti di sicurezza.

3.5.6.2 Armadi Batterie

L’armadio dovrà avere un grado di protezione IP 20 e dovrà essere adatto ad alloggiare batterie AGM-VRLA tipologia Long Life (LL). Temperatura di funzionamento: 0 a 40 °C (15 a 25 °C consigliata per maggior vita delle batterie). Temperatura di stoccaggio e trasporto: -5 a +40 °C max (consigliato: 25 °C). Idoneo all' installazione non all'aperto in ambienti privo di elementi conduttori, infiammabili, esplosivi o corrosivi e con livello di inquinamento inferiore al grado 2 secondo norma IEC 60664-1.Umidità relativa senza condensa: fino al 95%.

L'armadio batterie deve essere compatibile con UPS equipaggiati con carica batterie con funzionamento a 3 fili con neutro centrale (A+/N/A-). Armadio completo di protezione tramite sezionatore a fusibili o interruttore magnetotermico e completo degli accessori per la connessione tra monoblocchi e protezione. Cavi di connessione con l' UPS forniti di serie per installazione affiancata.

Il singolo armadio dovrà permettere di alloggiare fino a n.12 stringhe batterie da 9 Ah inseribili a caldo.

Il sistema dovrà essere dimensionato per assicurare un autonomia di 5 min con iI carico massimo definito da progetto. Saranno valutate con punteggio aggiuntivo soluzione che aumentino l’autonomia fino a 10 min.

Collegamento cavi dal basso; grado di protezione IP 20. Prima accensione della macchina da parte di tecnico specializzato del costruttore. L'opera s'intende comprensiva di ogni onere annesso e connesso per renderla perfettamente funzionante e realizzata a regola d'arte. Il costruttore delle apparecchiature deve essere certificato ISO9001 e ISO14001 e deve poter fornire un certificato di origine dichiarante che l'UPS è stato progettato, prodotto e testato in un paese dell' Unione Europea.

3.5.7 Caratteristiche gruppo elettrogeno

Il nuovo gruppo elettrogeno da installare dovrà essere per funzionamento in emergenza alla rete elettrica principale ed essendo destinato ad alimentazioni di sicurezza dovrà rispondere alle prescrizioni della norma ISO 8528-12. Esso avrà le caratteristiche salienti di seguito riportate.

- avviamento elettrico;

- raffreddamento ad acqua in circuito chiuso con radiatore meccanico;

- mappatura motore diesel ottimizzata per basso livello emissioni allo scarico;

- installazione in proprio cofano per esterno con materiale fono assorbente;

- dati nominali (prestazioni alle condizioni ambientali di 1000 Mbar 25°C / 30% di umidità relativa):

o Tensione : 400 V

o Frequenza : 50Hz

o N° di giri 1500 g/min

3.5.7.1 Prestazioni di tensione e frequenza

In regime stazionario, il gruppo elettrogeno dovrà assicurare nel funzionamento compreso tra vuoto e pieno carico e viceversa, le seguenti prestazioni di stabilità di tensione e frequenza:

- tensione nominale di 400 V, con precisione ± 0,5 %;

- frequenza nominale di 50 Hz, con precisione ± 0,25 %.

In regime dinamico, il gruppo dovrà rispettare rigorosamente le prestazioni minime prescritte dalla classe G2 della norma ISO 8528-5.

3.5.7.2 Motore diesel

Il motore del gruppo elettrogeno dovrà avere le caratteristiche di seguito riportate:

- Sistema e tipo di Iniezione: Turbocompresso ad iniezione diretta

- Tipo di raffreddamento: ad acqua

- Raffreddamento: ad acqua dotato di radiatore meccanico

- Consumo specifico al 80% del carico: 52,6 L/h

- Regolatore giri di tipo: elettronico

- Sistema di avviamento: elettrico

- Impianto elettrico motore: 24V

- Batteria di avviamento: n.2x12V /145 Ah al piombo

- Marmitta gas di scarico: Residenziale

Il motore dovrà essere dotato di una pompa manuale per l’estrazione dell’olio dalla coppa.

Il gruppo elettrogeno è alimentato a gasolio con serbatoio incorporato con vasca di raccolta liquidi motore e carburante. Gli appositi tappi di drenaggio del serbatoio e della vasca saranno posizionati sotto al telaio in posizione facilmente accessibile.

3.5.7.3 Generatore sincrono trifase

Il generatore elettrico dovrà essere costituito da un alternatore sincrono trifase a 4 poli collegamento a stella con neutro accessibile, autoeccitato senza spazzole tipo Brushless ed autoventilato a forma d’onda sinusoidale avente le seguenti caratteristiche elettriche:

- fattore di potenza nominale: 0,8;

- tensione nominale: 400 V (trifase con neutro);

- frequenza nominale: 50 Hz;

- velocità nominale di rotazione: 1.500 giri/minuto;

- precisione di tensione a regime statico ± 0,5%;

- collegamento avvolgimenti: stella con neutro;

- isolamento avvolgimenti di statore e rotore in classe H;

- sovratemperatura avvolgimenti di statore e rotore entro limiti classe H;

- grado di protezione meccanica fra rotore e statore è almeno IP 23;

- dispositivo soppressore radiointerferenze integrato nel regolatore elettronico digitale di tensione, in osservanza principali Normative e Direttive in vigore;

- scaldiglia anticondensa avvolgimenti di statore.

- L’alternatore di primaria marca dovrà essere conforme alle CEI 2-3,IEC34-1, VDE0530, BS4999-5000 e alla EN 60034-1

3.5.7.4 Basamento di sostegno e serbatoio

Il basamento di sostegno dovrà essere comune per: motore diesel, generatore, radiatore e accessori; esso dovrà essere completo di piedini per il sollevamento tramite carrello elevatore.

Il basamento suddetto ingloberà anche il serbatoio del combustibile e dovrà essere completo della vasca di raccolta di eventuali perdite. Le perdite di gasolio nella vasca di raccolta dovranno essere opportunamente segnalate sul quadro di comando del gruppo.

Il basamento in questione dovrà essere conformato in modo da realizzare anche una vasca di raccolta di eventuali perdite di liquidi motore (olio e /o refrigerante).

Tra il basamento e l’accoppiamento motore-alternatore dovranno essere interposti dei supporti elastici antivibranti.

Il serbatoio del combustibile dovrà essere dimensionato in modo da garantire un autonomia, al 75% del carico, di 6 ore.

3.5.7.5 Quadro elettrico protezione generatore

Il quadro elettrico per protezione generatore contro sovraccarichi e corto circuiti, comando commutazione rete-gruppo, alimentazione e comando servizi ausiliari gruppo elettrogeno, a completamento delle funzioni realizzate dal pannello elettronico di controllo sopra citato, dovrà essere separato dal gruppo elettrogeno e dovrà essere in esecuzione ad armadio, per appoggio a pavimento, da realizzare in lamiera di acciaio presso piegata ed elettrosaldata e da cablare secondo la norma CEI EN 61439-1 e 2.

Detto quadro dovrà essere completo di:

- Interruttore magnetotermico quadripolare;

- Carica batteria da 5A-24V

- Centralina di avviamento automatico programmabile con le seguenti caratteristiche:

o Display grafico LCD retro illuminato;

o Visualizzazione di tutti i parametri elettrici del motore e del generatore, delle funzioni, stati del gruppo elettrogeno;

o Comando manuale e automatico delle commutazioni;

o Lettura delle 3 tensioni rete, 3 tensioni gruppo, 3 correnti gruppo, Hz rete e gruppo, contagiri, Vdc, Vd+, KW

- KVA - KWh – Cosfi;

o Segnalazioni allarmi e preallarmi;

o Storico allarmi;

o Protezioni integrate di min e max tensione, frequenza, sovraccarico e corto circuito;

o Uscita seriale RS232 per programmazione da pc;

- Allaccio diretto al magnetotermico per prelevamento potenza totale;

- Indicatore livello digitale;

- Manometro olio digitale;

- Termometro acqua digitale;

- Pulsante di arresto di emergenza;

3.5.7.6 Accessori del gruppo elettrogeno

- Filtro separatore acqua dal combustibile;

- pompa manuale scarico olio dalla coppa motore;

- tronchetto flessibile compensatore di dilatazioni per uscita comune dai turbocompressori di sovralimentazione del motore diesel, fornito separato;

- marmitta silenziatrice per i gas di scarico di tipo residenziale di tipo speciale adeguatamente coibentata, completa di flange, controflange, guarnizioni, bullonerie;

- impianto elettrico dei dispositivi di protezione, comando e controllo installati sul gruppo elettrogeno, terminante in morsettiera posizionata all’interno del pannello elettronico, realizzato con cavi elettrici di adeguata sezione protetti da guaine, in osservanza delle Normative in vigore;

- cassetta attrezzi per interventi di manutenzione ordinaria al motore diesel;

- olio di lubrificazione per riempimento coppa motore diesel;

- miscela di refrigerazione acqua-antigelo per riempimento circuito di refrigerazione motore diesel;

- targhe di identificazione e dati tecnici;

- elettropompa autoadescante, pompa manuale, segna livello, livelli elettromagnetici.

3.5.7.7 Cofanatura del gruppo elettrogeno

Il gruppo dovrà essere dotato di cabina metallica coibentata, adatta alla posa in esterno nella quale saranno ubicati: Gruppo elettrogeno, quadro di comando, serbatoio con relativi accessori.

La cofanatura dovrà essere realizzata in lamiera di acciaio al carbonio Fe360 da 20/10, realizzata in un unico blocco, silenziata adeguatamente con materiale insonorizzante e resistente al fuoco in classe 1, avrà un grado di rumorosità di 69 dB(A) ±3 a 7 mt.

3.5.8 Controllo Accessi e Videosorveglianza

I locali del Data Center dovranno essere dotati di sistema di controllo accessi e videosorveglianza con le seguenti caratteristiche:

- teste di lettura multistandard per la lettura dei badge posizionati sia lato esterno che lato interno degli ingressi

- centralina di controllo in grado di gestire fino a 20000 eventi di transito

- stampante per la produzione di badge

- software di gestione in grado di:

o definire le aperture dei varchi e di associarle alle persone censite nel sistema

o definire dei “Profilo di Accesso” che identificano le relative Autorizzazioni

o definire una configurazione logica dell'impianto garantendo elevati livelli di sicurezza

- telecamere di tipo day-night in tutti i locali interessati dall’intervento

- sistema di gestione e monitoraggio TVCC

3.5.9 Impianto antincendio

Il Data Center dovrà essere dotato di un impianto di rivelazione e spegnimento incendi. Il sistema dovrà essere composto dai seguenti componenti: centrale di rivelazione, gestione e segnalazione allarmi; rivelatori automatici d'incendio; pulsanti di allarme; targhe ottico-acustiche; sirene di allarme, elettromagneti per porte taglia fuoco; erogatori/ugelli; linee di collegamento.

3.5.10 Attività di configurazione dell’infrastruttura tecnologica

Dovranno essere descritte tutte le attività necessarie alla realizzazione della soluzione per indirizzare le tematiche dell’installazione delle componenti dell’infrastruttura tecnologica per la loro opportuna configurazione.

3.5.11 Manutenzione Infrastruttura Tecnologica

Il servizio di manutenzione richiesto è della durata di 1 anno a decorrere dall’esito positivo del collaudo di conformità della fornitura.

Sarà ritenuto migliorativo, e oggetto di specifica valutazione, l’estensione del periodo di “manutenzione e assistenza”, per gli anni successivi.

Il servizio di manutenzione deve essere prestato secondo i tempi e le modalità seguenti:

- manutenzione preventiva con almeno 2 interventi di manutenzione ordinaria all’anno: comprende tutti gli interventi volti ad incrementare l’efficienza e l’affidabilità dell’infrastruttura tecnologica, individuando in maniera preventiva i possibili malfunzionamenti. Per non creare discontinuità di servizio sarà obbligo della Società concordare preventivamente con il CNR le modalità e le tempistiche degli interventi

- manutenzione correttiva in caso di guasto: include tutti gli interventi volti alla rimozione di malfunzionamenti o guasti e al ripristino delle funzionalità attraverso interventi da remoto, o se necessario on-site presso la sede NANOTEC del CNR. Nel dettaglio le attività di manutenzione possono comprendere:

o risoluzione della causa del guasto tramite intervento on-site, sostituzione delle parti guaste, ripristino del servizio sui livelli preesistenti al guasto, verifica dell’eliminazione della causa del guasto;

o ritiro degli apparati guasti presso la sede NANOTEC e riconsegna degli stessi riparati. Gli apparati sostitutivi dovranno garantire le medesime (o in alternativa superiori) prestazioni e funzionalità di quelli guasti.

Tutte le attività sopra descritte dovranno essere svolte con personale specializzato, con comprovate competenze e esperienze nel settore di intervento.

Gli interventi si considereranno conclusi al termine delle attività di test di funzionalità con esito positivo.

Orari di erogazione del servizio e SLA

L’erogazione del servizio dovrà essere H24, 7 giorni su 7, 365 giorni/anno.

Di seguito sono elencati i Livelli di Servizio garantiti, a seconda della tipologia di guasto:

Tipologia di servizio	Tipologia di guasto	SLA Presa in carico Intervento

Risoluzione malfunzionamento a livello di manutenzione correttiva	Bloccante	Entro 1 ora dall’apertura del ticket	Entro 4 ore dalla presa in carico
	Non Bloccante	Entro 3 ore dall’apertura del ticket	NBD (Next Business Day)

Tabella 3.5.1

La Società, per tutta la durata del servizio di manutenzione dovrà erogare il servizio di monitoraggio h24 da un proprio centro servizi dotato di SPOC (Single Point of Contact) mediante utilizzo di opportuno DCIM (Data Center Infrastructure Management).

3.6 Servizi di formazione richiesti

La presente sezione descrive i requisiti relativi alle attività di formazione che dovranno essere incluse nella fornitura.

In particolare vengono esplicitate le attività minime attese nel contesto della formazione per gli operatori del CNR che saranno identificati a valle dell’assegnazione del contratto, durante una specifica fase di definizione puntuale di tale iniziativa che dovrà comunque contemplare:

- definizione dettagliata delle tematiche proposte nelle sessioni di formazione

- piano di formazione

- identificazione operatori da formare

- modalità specifiche di erogazione

- aspetti logistici delle sessioni di formazione

Le attività di formazione dovranno prevedere quanto segue per ciascuno degli ambiti oggetto di fornitura ovvero ambito HPC, Virtuale e Sistemi Convergenti:

- n° 1 Workshop di 8 ore, in aula

- n° 2 sessioni di Training-on-the-Job di 3 ore

In definitiva dovranno essere erogati n° 3 Workshop e 6 sessioni complessive di Training-on-the-Job.

Come anticipato il piano di formazione, che indicherà le date e gli orari di tali momenti, sarà concordato con il CNR; l’indicazione generale è che i workshop vengano completati prima del rilascio formale delle soluzioni per ogni ambito e che le sessioni di Training-on-the-Job vengano effettuate durante il periodo di Supporto Post-rilascio.

Viene altresì richiesto alla Società di mettere a disposizione almeno i seguenti 4 corsi di formazione da fruire anche in modalità on-line (con sottoscrizione di almeno 1 anno):

- VMware vSphere Install, Configure and Manage

- VMware vRealize Automation: Install, Configure, Manage

- VMware vRealize Operations for Operators

- Corso relativo all’infrastruttura convergente proposta in fornitura

3.6.1 Workshop

I workshop in aula dovranno essere corredati di materiale didattico che illustri i principali aspetti delle soluzioni introdotte e che ne descriva almeno:

- schemi architetturali

- caratteristiche generali delle componenti hardware e software

- personalizzazioni delle precedenti componenti, specifiche delle soluzioni in fornitura

- eventuali processi e procedure definite per lo specifico ambito

- eventuali vincoli e/o note tecniche

3.6.2 Training on the Job

Le sessioni di Training-on-the-Job hanno come obiettivo quello di fornire agli operatori del CNR delle indicazioni tecnico/pratiche di tipo gestionale/operativo sulle soluzioni implementate, che dopo essere state introdotte a livello concettuale nei precedenti workshop, dovranno essere oggetto di un approfondimento utile a fornire un’esperienza concreta sulle loro specifiche caratteristiche, funzionalità e aspetti peculiari.

4 MARCATURA “CE”

I materiali e/o le attrezzature e/o gli impianti forniti dovranno essere conformi, se applicabili, alle norme C.E.I. ed U.N.I. ed essere contraddistinti dal marchio CE, qualora applicabile.

5 LUOGO E TERMINE DI CONSEGNA E INSTALLAZIONE

Luogo di consegna e installazione: CNR-NANOTEC – c/o Campus Ecotekne, Via Monteroni, 73100 Lecce, Edificio E Piano terra.

La Tabella 3.6.1 illustra i termini di consegna ed installazione, in mesi di durata pari a 30 giorni naturali e consecutivi cadauno, con decorrenza dalla stipula del contratto, distintamente per ogni macro-attività in cui è suddiviso l’appalto:

MESE

CONSEGNA COMPONENTI PER ALLESTIMENTO SALA DC

INSTALLAZIONE INFRASTRUTTURE TECNOLOGICHE DELLA SALA DC

CONSEGNA COMPONENTI HW-SW INFRASTRUTTURA CDCN

INSTALLAZIONE E CONFIGURAZIONE INFRASTRUTTURA CDCN

CONSEGNA COMPONENTI HW-SW INFRASTRUTTURA HPC

INSTALLAZIONE E CONFIGURAZIONE INFRASTRUTTURA HPC

CONSEGNA COMPONENTI HW-SW INFRASTRUTTURA CI

INSTALLAZIONE E CONFIGURAZIONE INFRASTRUTTURA CI

CONFIGURAZIONE E AVVIO DC

FORMAZIONE

Tabella 3.6.1

A titolo meramente esemplificativo il termine ultimo per la consegna dei “COMPONENTI PER ALLESTIMENTO SALA DC” sarà di 2,5 mesi dal giorno successivo alla stipula del contratto, così come il termine ultimo per l’” INSTALLAZIONE INFRASTRUTTURE TECNOLOGICHE DELLA SALA DC” sarà di 3 mesi dal giorno successivo alla stipula del contratto. Il mancato rispetto dei termini di cui alla Tabella 3.6.1 costituirà motivo di applicazione delle penali di cui al successivo articolo 7.

6 AVVIO E TERMINE DELL’ESECUZIONE DEL CONTRATTO

6.1 Avvio dell’esecuzione

Il Direttore dell’esecuzione del contratto (DEC), sulla base delle disposizioni del Responsabile Unico del Procedimento (RUP), dopo che il contratto è divenuto efficace, dà avvio all’esecuzione della prestazione, fornendo alla Società tutte le istruzioni e direttive necessarie e redigendo, laddove sia indispensabile in relazione alla natura e al luogo di esecuzione delle prestazioni, apposito verbale come meglio disciplinato all’Art. 19 del DM n° 49 del 7 marzo 2018 del Ministero delle Infrastrutture e dei Trasporti.

6.2 Sospensione dell’esecuzione

In tutti i casi in cui ricorrano circostanze speciali che impediscano in via temporanea l’esecuzione dell’appalto si applicano le disposizioni di cui all’Art. 107 del D. Lgs. 50/2016 e s.m.i. e all’Art. 23 del già citato DM.

6.3 Termine dell’esecuzione

La Società è tenuta a comunicare alla Stazione Appaltante l’intervenuta ultimazione delle prestazioni contrattuali. Il DEC, entro 5 giorni da tale comunicazione, effettua, in contradditorio con la Società medesima, i necessari accertamenti e trasmette al RUP, entro i successivi 5 giorni, il certificato di ultimazione delle prestazione, che ne rilascerà copia conforme alla Società.

7 PENALITÀ

1. Per ogni giorno solare di ritardo nell’esecuzione della fornitura e della installazione oggetto del presente contratto si applicherà una penale pari all’1‰ (uno per mille) dell’importo contrattuale, al netto dell’IVA e dell’eventuale costo relativo alla sicurezza sui luoghi di lavoro derivante dai rischi di natura interferenziale.

2. Nel caso in cui la prima verifica di conformità della fornitura abbia esito sfavorevole non si applicano le penali; qualora tuttavia la Società non renda nuovamente la fornitura disponibile per la verifica di conformità entro i 20 (venti) giorni solari successivi al primo esito sfavorevole, ovvero la verifica di conformità risulti nuovamente negativa, si applicherà la penale sopra richiamata per ogni giorno solare di ritardo.

3. Nell’ipotesi in cui l’importo delle penali applicabili superi il 10% (dieci per cento) dell’importo contrattuale, al netto dell’IVA e dell’eventuale costo relativo alla sicurezza sui luoghi di lavoro derivante dai rischi di natura interferenziale, l’Ente potrà risolvere, ai sensi dell’Art. 108 comma 4 del Codice, il contratto in danno all’aggiudicatario, salvo il diritto al risarcimento dell’eventuale danno patito.

4. Gli inadempimenti contrattuali che daranno luogo all’applicazione di penali di cui ai precedenti periodi verranno contestati alla Società per iscritto.

5. La Società dovrà comunicare in ogni caso le proprie deduzioni nel termine massimo di 5 (cinque) giorni lavorativi dalla stessa contestazione. Qualora dette deduzioni non siano accoglibili a giudizio della Stazione Appaltante ovvero non vi sia stata risposta o la stessa non sia giunta nel termine indicato, si applicheranno le penali sopra indicate.

6. Le penali verranno regolate dalla Stazione Appaltante, o sui corrispettivi dovuti alla Società per le attività dell’appalto già effettuate oppure sulla garanzia definitiva. In quest’ultimo caso la garanzia definitiva dovrà essere reintegrata entro i termini fissati dalla Stazione Appaltante.

8 MODALITÀ DI RESA

1. Per operatori economici appartenenti a Stati membri dell’Unione europea, si applica la regola Incoterms 2010 - DAP (Delivered At Place) Istituto di Nanotecnologia del Consiglio Nazionale delle Ricerche – CNR-NANOTEC – c/o Campus Ecotekne, Via Monteroni, 73100 Lecce, Edificio E Piano terra.

2. Per operatori economici non appartenenti a Stati membri dell’Unione europea, si applica la regola Incoterms 2010 - DDP (Delivered Duty Paid) Istituto di Nanotecnologia del Consiglio Nazionale delle Ricerche – CNR-NANOTEC – c/o Campus Ecotekne, Via Monteroni, 73100 Lecce, Edificio E Piano terra.

3. Tutti gli operatori economici sono obbligati, incluso nel prezzo contrattuale d’appalto:

i. A stipulare un contratto di assicurazione per la parte di trasporto sotto la loro responsabilità;

ii. Allo scarico della merce;

iii. All’installazione della fornitura.

9 ONERI ED OBBLIGHI DELL’AGGIUDICATARIO

La Società:

1. Si impegna ad eseguire le prestazioni oggetto del presente contratto, senza alcun onere aggiuntivo, salvaguardando le esigenze della Stazione Appaltante e di terzi autorizzati, senza recare intralci, disturbi o interruzioni all’attività lavorativa in atto.

2. Rinuncia a qualsiasi pretesa o richiesta di compenso nel caso in cui lo svolgimento delle prestazioni contrattuali dovesse essere ostacolato o reso più oneroso dalle attività svolte dalla Stazione Appaltante e/o da terzi.

3. E’ direttamente responsabile dell’inosservanza delle clausole contrattuali anche se questa dovesse derivare dall’attività del personale dipendente di altre imprese a diverso titolo coinvolto.

4. Deve avvalersi di personale qualificato in regola con gli obblighi previsti dai contratti collettivi di lavoro e da tutte le normative vigenti, in particolare in materia previdenziale, fiscale, di igiene ed in materia di sicurezza sul lavoro.

5. Risponderà direttamente dei danni alle persone, alle cose o all’ambiente comunque provocati nell’esecuzione dell’appalto che possano derivare da fatto proprio, dal personale o da chiunque chiamato a collaborare. La Stazione Appaltante è esonerata da ogni responsabilità per danni, infortuni o altro dovesse accadere al personale di cui si avvarrà la Società nell’esecuzione del contratto.

6. Si fa carico, intendendosi remunerati con il corrispettivo contrattuale, di tutti gli oneri ed i rischi relativi alle attività ed agli adempimenti occorrenti all’integrale espletamento dell’oggetto contrattuale, ivi compresi, a mero titolo esemplificativo e non esaustivo, gli oneri relativi alle spese di trasporto, di viaggio e di missione per il personale addetto alla esecuzione della prestazione, nonché i connessi oneri assicurativi.

7. Si obbliga ad eseguire le prestazioni oggetto del presente contratto a perfetta regola d’arte e nel rispetto di tutte le norme e le prescrizioni tecniche e di sicurezza in vigore e di quelle che dovessero essere emanate nel corso del presente contratto, nonché secondo le condizioni, le modalità, i termini e le prescrizioni contenute nel presente contratto e nei suoi allegati;

8. Si obbliga a consegnare gli elaborati progettuali e tutte le dichiarazioni e/o certificazioni discendenti da specifici obblighi normativi e legislativi correlati con l’oggetto della prestazione;

9. Si obbliga a consegnare i certificati di omologazione “CE” per tutte le apparecchiature che lo richiedano;

10. Si obbliga a consegnare le schede tecniche e i manuali delle singole apparecchiature fornite, preferibilmente su supporto digitale;

11. A consegnare le eventuali schede di manutenzione ordinaria e straordinaria delle apparecchiature suddivise per interventi giornalieri, settimanali, mensili, etc.

10 SICUREZZA SUL LAVORO

1. La Società si assume la responsabilità per gli infortuni del personale addetto, che dovrà essere opportunamente addestrato ed istruito.

2. La valutazione dei rischi propri della Società nello svolgimento della propria attività professionale resta a carico dello stesso, così come la redazione dei relativi documenti e la informazione/formazione dei propri dipendenti.

3. La Società è tenuta a garantire il rispetto di tutte le normative riguardanti l’igiene e la sicurezza sul lavoro con particolare riferimento alle attività che si espleteranno presso l’Ente.

4. In relazione alle risorse umane impegnate nelle attività oggetto del presente contratto, La Società è tenuta a far fronte ad ogni obbligo previsto dalla normativa vigente in ordine agli adempimenti fiscali, tributari, previdenziali ed assicurativi riferibili al personale dipendente ed ai collaboratori.

5. Per quanto riguarda i lavoratori dipendenti, la Società è tenuta ad osservare gli obblighi retributivi e previdenziali previsti dai corrispondenti CCNL di categoria, compresi, se esistenti alla stipulazione del contratto, gli eventuali accordi integrativi territoriali.

6. Gli obblighi di cui al comma precedente vincolano la Società anche qualora la medesima non sia aderente alle associazioni stipulanti gli accordi o receda da esse, indipendentemente dalla struttura o dimensione del medesimo e da ogni altra qualificazione giuridica, economica o sindacale.

11 DIVIETO DI CESSIONE DEL CONTRATTO

1. E’ vietata la cessione del contratto ai sensi dell’art. 105, comma 1 del D. Lgs. 50/2016 e s.m.i.;

2. Per quanto riguarda le modificazioni soggettive che comportino cessioni di azienda e atti di trasformazione, fusione e scissione relative alla Società, si applicano le disposizioni di cui all’art. 106 del D. Lgs. 50/2016 e s.m.i.

3. La Società è tenuta a comunicare tempestivamente alla Stazione Appaltante ogni modificazione intervenuta negli assetti proprietari e nella struttura organizzativa.

12 VERIFICA DI CONFORMITÀ DELLA FORNITURA

1. La fornitura sarà soggetta a verifica di conformità per certificare che l'oggetto del contratto in termini di prestazioni, obiettivi e caratteristiche tecniche, economiche e qualitative sia stato realizzato ed eseguito nel rispetto delle previsioni contrattuali e delle pattuizioni concordate in sede di aggiudicazione, ai sensi dell’art. 102 del D. Lgs. 50/2016 e s.m.i.

2. Le attività di verifica saranno effettuate entro 30 (trenta) giorni solari dalla data di termine dell’esecuzione di cui al paragrafo 6.3.

3. Durante le suddette operazioni, la Stazione Appaltante ha altresì la facoltà di chiedere alla Società tutte quelle prove atte a definire il rispetto delle specifiche strumentali dichiarate e quant’altro necessario a definire il buon funzionamento della fornitura.

4. Xxxx rifiutata la fornitura difettosa o non rispondente alle prescrizioni tecniche richieste dal Capitolato tecnico e accettate in base all’offerta presentata in sede di gara dalla Società.

5. L’esito positivo della verifica non esonera la Società dal rispondere di eventuali difetti non emersi nell’ambito delle attività di verifica di conformità e successivamente riscontrati; tali difetti dovranno essere prontamente eliminati durante il periodo di garanzia.

13 FATTURAZIONE E PAGAMENTO

1. Ai fini del pagamento del corrispettivo contrattuale l’Aggiudicatario stabilito e/o identificato ai fini IVA in Italia emetterà fattura elettronica ai sensi e per gli effetti del Decreto del Ministero dell’Economia e delle Finanze N. 55 del 3 aprile 2013, inviando il documento elettronico al Sistema di Interscambio che si occuperà di recapitare il documento ricevuto all’Ente. In caso di Aggiudicatario straniero la fattura dovrà essere cartacea.

2. Il Consiglio Nazionale delle Ricerche è soggetto all’applicazione del meccanismo dello “split payment”.

3. E’ prevista un’anticipazione sul prezzo contrattuale pari al 20 per cento (20%) da corrispondere all'aggiudicatario, previa emissione di fattura con le modalità di cui ai commi 15.1 e 15.4 del presente articolo, entro quindici giorni dall'effettivo inizio della prestazione, sul conto corrente dedicato di cui alla tracciabilità dei flussi finanziari. L'erogazione dell'anticipazione è subordinata alla costituzione di garanzia fideiussoria bancaria o assicurativa di importo pari all’anticipazione maggiorato del tasso di interesse legale applicato al periodo necessario al recupero

dell'anticipazione stessa secondo il cronoprogramma della prestazione, rilasciata da imprese bancarie autorizzate ai sensi del decreto legislativo 1° settembre 1993, n. 385, o assicurative autorizzate alla copertura dei rischi ai quali si riferisce l'assicurazione e che rispondano ai requisiti di solvibilità previsti dalle leggi che ne disciplinano la rispettiva attività. La garanzia può essere, altresì, rilasciata dagli intermediari finanziari iscritti nell'albo degli intermediari finanziari di cui all'articolo 106 del decreto legislativo 1° settembre 1993, n. 385. Il beneficiario decade dall'anticipazione, con obbligo di restituzione, se l'esecuzione della prestazione non procede, per ritardi a lui imputabili, secondo i tempi contrattuali. Sulle somme restituite sono dovuti gli interessi legali con decorrenza dalla data di erogazione della anticipazione. Il pagamento della fattura relativa al saldo avverrà entro 30 (trenta) giorni solari dalla data del Certificato di verifica di conformità sul conto corrente dedicato di cui alla tracciabilità dei flussi finanziari.

4. La fattura dovrà contenere i seguenti dati, pena il rifiuto della stessa:

• Intestazione: CNR – Dipartimento di Scienze Umane del Consiglio Nazionale delle Ricerche 00000 - Xxxx;

• Il Codice Fiscale 80054330586;

• Xx Xxxxxxx XXX 0000000000;

• Il riferimento al contratto (N° di protocollo e data);

• Il CIG 8332391A91;

• Il CUP B67E19000040007;

• Il CUU (Codice Univoco Ufficio) dell’Ente: M6PTIJ (solo per i soggetti stabiliti e/o identificati ai fini IVA in Italia);

• L’importo imponibile;

• L’importo dell’IVA (solo per i soggetti stabiliti e/o identificati ai fini IVA in Italia);

• Esigibilità IVA “S” scissione dei pagamenti (solo per i soggetti stabiliti e/o identificati ai fini IVA in Italia);

• L’importo totale;

• L’oggetto del contratto;

• Il codice IBAN del conto corrente dedicato;

• Il “Commodity code” (solo per Aggiudicatari stranieri).

5. Ai fini del pagamento del corrispettivo la Stazione Appaltante procederà alle verifiche di legge.

6. In sede di liquidazione delle fatture potranno essere recuperate le spese per l’applicazione di eventuali penalità (di cui al paragrafo 7); la Stazione Appaltante potrà sospendere, ferma restando l’applicazione delle eventuali penali, i pagamenti all’Aggiudicatario cui sono state contestate inadempienze nell’esecuzione della fornitura, fino al completo adempimento degli obblighi contrattuali (art. 1460 C.C.). Tale sospensione potrà verificarsi anche qualora insorgano contestazioni di natura amministrativa.

14 TRACCIABILITÀ DEI FLUSSI FINANZIARI

1. La Società assume tutti gli obblighi di tracciabilità dei flussi finanziari di cui all’art. 3 della legge 13 agosto 2010 n. 136 e successive modificazioni ed integrazioni.

2. Il mancato utilizzo del bonifico bancario o postale ovvero degli altri strumenti di incasso o pagamento idonei a consentire la piena tracciabilità delle operazioni costituisce causa di risoluzione del contratto ai sensi dell’art. 3, comma 9-bis, della legge 13 agosto 2010 n.136.

3. La Società si impegna a dare immediata comunicazione al CNR – Dipartimento di Scienze Umane del Consiglio Nazionale delle Ricerche ed alla prefettura-ufficio territoriale del Governo della provincia di Roma della notizia dell’inadempimento della propria controparte (subappaltatore/subcontraente) agli obblighi di tracciabilità finanziaria.

15 GARANZIA ED ASSISTENZA TECNICA

1. La fornitura dovrà essere garantita per i periodi minimi e con le modalità indicate al paragrafo 3.4, dalla data dell’emissione del certificato di verifica di conformità con esito positivo salvo l’eventuale termine migliorativo nell’offerta presentata dalla Società in sede di gara.

16 RECESSO

1. Fermo restando quanto previsto dall’Art. 109 del Codice, la Stazione Appaltante potrà recedere dal presente contratto anche nelle seguenti ipotesi non imputabili alla Società: i) per motivi di pubblico interesse; ii) durante l’esecuzione del contratto in applicazione delle facoltà concesse dall’Art. 1464 C.C.

2. La volontà di recesso sarà comunicata alla Società con un preavviso non inferiore a 30 (trenta) giorni naturali e consecutivi. La Stazione Appaltante in caso di recesso sarà esonerata dalla corresponsione di qualsiasi indennizzo o risarcimento.

17 RISOLUZIONE DEL CONTRATTO

1. In adempimento a quanto previsto dall’art. 108 del D. Lgs. 50/2016 e s.m.i. la Stazione Appaltante risolverà il contratto nei casi e con le modalità ivi previste.

2. Per quanto non previsto nel presente paragrafo, si applicano le disposizioni di cui al Codice Civile in materia di inadempimento e risoluzione del contratto.

3. In ogni caso si conviene che la Stazione Appaltante, senza bisogno di assegnare previamente alcun termine per l’adempimento, potrà risolvere di diritto il contratto ai sensi dell’art. 1456 c.c., previa dichiarazione da comunicarsi alla Società tramite posta elettronica certificata nei seguenti casi:

i. Mancata reintegrazione della cauzione eventualmente escussa entro il termine di 10 (dieci) giorni lavorativi dal ricevimento della relativa richiesta da parte della Stazione Appaltante;

ii. Nel caso in cui l’UTG competente rilasci la comunicazione/informazione antimafia interdittiva;

iii. Nei casi di cui ai precedenti paragrafi:

• 7 Penalità;

• 9 Oneri ed obblighi dell’Aggiudicatario;

• 10 Sicurezza sul lavoro;

• 11 Divieto di cessione del contratto.

Document Metadata

Table of Contents

GARA EUROPEA A PROCEDURA APERTA CON MODALITA’ TELEMATICA SU PIATTAFORMA ASP CONSIP

Document Metadata