Gara Realizzazione Infrastruttura IT
Gara Realizzazione Infrastruttura IT
Capitolato Tecnico
INDICE
1. Introduzione 4
2. Contesto 4
2.1. Il programma N(BIT)2 4
2.2. La nuova infrastruttura IT 6
2.3. Sapienza Private Cloud 10
2.4. L’infrastruttura esistente 10
3. Definizione della fornitura 13
3.1. Definizioni e acronimi 13
3.1.1. Definizioni 13
3.1.2. Acronimi 14
3.2. Oggetto 14
3.3. Durata delle attività 15
3.4. Criteri di valutazione tecnica 15
4. Progetto di riferimento 16
4.1. Architettura 16
4.2. Layout di sala 20
4.3. Framework di gestione software-based 23
5. Descrizione dell’appalto 25
5.1. Progetto esecutivo di massima 25
5.1.1. Descrizione 25
5.1.2. Requisiti 25
5.1.3. Criteri di valutazione tecnica 26
5.2. Hardware 26
5.2.1. Requisiti generali 27
5.2.2. HW-CP-01 – Blade Server 28
5.2.3. HW-CP-02 – Blade Chassis 30
5.2.4. HW-ST-01 – Storage Area Network 32
5.2.5. HW-ST-02 – Piattaforma di Virtualizzazione dello Storage 35
5.2.6. HW-NT-01 – Piattaforma DWDM 38
5.2.7. HW-NT-02 – Switch Data Center Ethernet 42
5.2.8. HW-NT-03 – Moduli e Porte per Switch Data Center Ethernet 44
5.2.9. HW-NT-04 – Switch FC 46
5.2.10. HW-NT-05 – Moduli e Porte per Switch FC 49
5.2.11. HW-NT-06 – Switch Rack Ethernet 51
5.2.12. HW-NT-07 – Apparati di Distribuzione Ethernet per Blade 53
5.2.13. HW-NT-08 – Apparati di Distribuzione FC per Blade 56
5.3. Software 57
5.3.1. Requisiti generali 58
5.3.2. SW-TL-01 – Orchestration & Automation Engine 58
5.3.3. SW-CL-01 – Cloud Service Platform 62
5.4. Accessori 66
5.4.1. AC-CP-01 – Xxxxxxx XXX 00
5.4.2. AC-NT-01 – Cablaggio della Rete Dati dei Data Center 68
5.5. Servizi 71
5.5.1. Requisiti generali 71
5.5.2. SR-PR-01 – Project Management 72
5.5.3. SR-PR-02 – Trasporto e Consegna Materiali 73
5.5.4. SR-PR-03 – Installazione e Configurazione 74
5.5.5. SR-PR-04 – Estensione Fabric FC Esistente 75
5.5.6. SR-PR-05 – Predisposizione al Collaudo 76
5.5.7. SR-PR-06 – Formazione 76
5.5.8. SR-CM-01 – Manutenzione e Assistenza per 5 Anni 77
6. Collaudo 79
7. Penali 80
1. Introduzione
Il presente documento rappresenta il Capitolato Tecnico, parte della documentazione ufficiale, della gara comunitaria a procedura aperta, indetta dal Centro Infosapienza dell’Università “La Sapienza” di Roma (nel seguito indicata con i termini Università e Ateneo o più semplicemente la “Sapienza”), per la realizzazione di una nuova infrastruttura di Information Technology (IT) richiesta dai piani di sviluppo e crescita dell’Università.
Tale documento descrive tutti gli aspetti tecnici dell’appalto, in termini di oggetto dello stesso, di requisiti e condizioni espresse dall’Università in relazione all’oggetto ed alla modalità di esecuzione, di tutte le informazioni ritenute utili per il Fornitore affinché possa formulare l’offerta più congrua e conveniente, ed infine in termini di criteri di valutazione tecnica che verranno applicati in fase di valutazione dell’offerta.
Nell’ambito del presente documento con il termine Fornitore si vuole indicare nel suo insieme il soggetto concorrente / aggiudicatario partecipante alla gara, sia questi una singola impresa o un raggruppamento in varia forma di più imprese, secondo i casi previsti dall’art. 5 del Disciplinare di gara.
2. Contesto
Il seguente capitolo sintetizza i principali fattori che caratterizzano sia l’Università “La Sapienza” di Roma nel suo complesso, che più in particolare il contesto strategico e tecnologico all’interno del quale verrà innestata l’infrastruttura IT oggetto della presente gara.
2.1. Il programma N(BIT)2
Con oltre 700 anni di storia, 120.000 studenti e 9.000 dipendenti tra professori, impiegati e tecnici, la Sapienza è la prima università in Europa. La sua missione è contribuire allo sviluppo della società della conoscenza attraverso la ricerca, la formazione di eccellenza e di qualità e la cooperazione internazionale.
Il governo dell’Ateneo, mirando a far sì che l’Istituzione possa primeggiare per modernità, innovazione ed efficienza, nei campi della didattica, della ricerca e della gestione amministrativa pubblica, ha individuato nello sviluppo e nel potenziamento delle proprie capacità e dotazioni nell’ambito dell’Information & Communication Technology una chiave di successo per il raggiungimento di tali obiettivi ed ha pertanto dato impulso ad un complesso e articolato programma di iniziative ed investimenti in questa direzione. Tale programma è stato denominato N(BIT)2 [ennebitquadro], quale espressione di massima sintesi, attraverso un gioco linguistico (in inglese), del risultato finale complessivo perseguito: Building a New Break-Through IT Infrastructure, ossia costruire una nuova infrastruttura IT, innovativa, che rappresenti un punto di svolta nelle capacità IT dell’Università.
Ideatore e conduttore del programma è il Centro Infosapienza, struttura parte delle funzioni amministrative centrali dell’Ateneo, istituita quale centro di spesa ad ordinamento speciale, di programmazione e di sviluppo tecnologico, finalizzato al supporto della Information & Communication Technology dell’Università.
Il Centro Infosapienza si occupa della progettazione e gestione dei servizi informativi indispensabili alla ricerca, alla didattica e alle attività organizzativo-gestionali e costituisce, per l’Ateneo, il centro di competenze di riferimento per la predisposizione di soluzioni innovative inerenti l’elaborazione e la disseminazione dell’informazione elettronica.
In particolare il Centro Infosapienza gestisce:
• le reti di comunicazione telematica e wireless gratuita per gli studenti e il personale, la fonia e il sistema informativo integrato della Sapienza per la gestione dei dati;
• il portale di Sapienza, i servizi web e i sistemi con autenticazione centralizzata, la posta elettronica per gli studenti e il personale;
• le applicazioni centralizzate di supporto per le attività amministrative di gestione della didattica, della carriera degli studenti, delle risorse universitarie;
• il servizio di co-location per strutture centrali e decentrate;
• lo sviluppo di progetti di innovazione tecnologica nell’ambito dei servizi di supporto alla didattica, alla ricerca, alla gestione amministrativa ed alla vita di campus.
Il programma N(BIT)2 prevede cinque macro-ambiti, denominati Work Stream, indicati in Figura 1. L’insieme di Work Stream si articola in una serie di progetti, denominati Work Package (WP), e milestone, che definiscono il percorso di attività necessarie per la produzione dei risultati attesi, identificando dipendenze e output previsti per ogni singola iniziativa. I 10 Work Package e le 4 principali milestone che costituiscono il programma sono rappresentati schematicamente in Figura 2.
Figura 1 – Work Stream del Programma N(BIT)2
Figura 2 – Work Package e milestone del Programma N(BIT)2
Nei paragrafi seguenti verranno sinteticamente esposti i contenuti dei due Work Stream IT Infrastructure e Private Cloud (rispettivamente nei paragrafi 2.2 e 2.3), rilevanti ai fini della migliore comprensione delle esigenze dell’Università nel contesto della presente gara.
2.2. La nuova infrastruttura IT
Il Work Stream IT Infrastructure rappresenta il basamento del Programma N(BIT)2 (rif. §2.1), avendo il compito di:
• progettare e realizzare una nuova infrastruttura IT, ridefinendo l’intero landscape infrastrutturale, da articolarsi su due siti locali (data center denominati INFO2 – esistente – e INFO0 – di nuova costruzione) e un sito di Disaster Recovery,
• garantire la massima ridondanza e continuità operativa della nuova infrastruttura,
• dotarsi di risorse informatiche HW e SW di ultima generazione e di nuova fattura, avendo chiari gli obiettivi finali dell’Ateneo, da svilupparsi nei Work Stream seguenti, ossia:
• migrare i servizi erogati dal Centro Infosapienza, dall’attuale landscape infrastrutturale (rif. §2.4) al
nuovo (Work Stream Services Migration),
• sviluppare innovativi servizi di tipo Cloud Computing / As-a-Service per le strutture dell’Università (Work Stream Private Cloud – rif. §2.3),
• supportare l’imponente processo di digitalizzazione del patrimonio multimediale informativo e culturale dell’Università (Work Stream Digital Library).
Il Work Stream IT Infrastructure è articolato in tre Work Package:
• WP.01 – Infrastructure Blueprint Design,
• WP.02 – New IT Resources Procurement,
• WP.03 – IT Infrastructure Implementation.
Il Work Package WP.02 rappresenta il processo di approvvigionamento delle nuove risorse HW e SW necessarie alla realizzazione della nuova infrastruttura IT; la presente gara è pertanto parte integrante dei contenuti del Work Package.
Il presente Capitolato Tecnico, e quindi tutte le scelte tecniche e progettuali e le caratteristiche dei beni e servizi oggetto dell’appalto (capitolo 5), derivano da una fase di studio e progettazione architetturale della nuova infrastruttura, condotta e terminata nel Work Package WP.01, che ha prodotto un documento interno denominato Infrastructure Blueprint.
I servizi oggetto dell’appalto (rif. §5.5) contribuiranno alla realizzazione della nuova infrastruttura, obiettivo del Work Package WP.03.
Di seguito vengono presentati alcuni degli indirizzi strategici e delle scelte architetturali più importanti fissati dalla Infrastructure Blueprint, ritenuti rilevanti per la comprensione delle finalità del presente appalto.
Innanzitutto l’obiettivo primario fissato dall’Ateneo consiste nel realizzare un’infrastruttura IT quanto più sicura e affidabile, in quanto:
• ripartita equamente, in modalità speculare e active / active, su due siti / data center di produzione distinti: INFO0 e INFO2;
• costruita by design in alta affidabilità in tutte le componenti sistemistiche e di networking.
Figura 3 – Ubicazione in mappa dei due data center INFO2 (contrassegno A) e INFO0 (contrassegno B) a Roma
Relativamente al primo punto, i due data center si trovano ubicati entrambi nel territorio del Comune di Roma, all’interno di edifici di proprietà dell’Università. In particolare:
• Il data center INFO0 è sito nel piano interrato di un edificio in Via dei Piceni, angolo Via dei Reti, fronte strada, a Roma (Figura 3). Il data center, di nuova costruzione (in corso), presenta una superficie utile di circa 120 metri quadrati, una tecnologia di raffreddamento basato su un’isola fredda, costituita da un volume chiuso di circa 65 metri cubi, attrezzato con 24 rack, ed in grado di erogare una potenza di
180.000 frigorie/ora di raffrescamento. Per il transito dei materiali sarà possibile accedere al locale attraverso un montacarichi che si apre sul piano stradale, con: portata 1.000 Kg, altezza della cabina 230 centimetri, varco di passaggio di luce netta di 100 centrimetri di larghezza e 230 centrimetri di altezza.
• Il data center INFO2 è sito nel piano interrato dell’Edificio di Fisica “X. Xxxxx” all’interno della Città Universitaria, in Xxxxxxxx Xxxx Xxxx 0 a Roma (Figura 3). Il data center, per il quale sono previsti investimenti atti a ristrutturare i locali e le dotazioni impiantistiche, presenta una superficie utile (ai fini del progetto) di circa 80 metri quadrati, in cui si prevede di allocare 12 rack, all’interno di un’isola fredda (si veda punto precedente) di circa 30 metri cubi e raffrescata con una potenza massima di
90.000 frigorie/ora circa (la costruzione dell’isola fredda fa parte della programmazione futura e non deve considerarsi una precondizione). Il locale è accessibile dall’esterno attraverso un portone di
emergenza, con luce netta di larghezza pari a 195 centimetri e altezza pari a 210 centimetri, che si apre direttamente sulla sala macchine e dà accesso ad un area di servizio di circa 8 metri quadrati. Per il transito dei materiali attraverso questo passaggio è necessario impiegare un braccio meccanico da posizionarsi sulla strada interna adiacente (a circa 10 metri di distanza e circa 5 metri più in alto rispetto al piano del passaggio). In Figura 4 vengono illustrate alcune fotografie dell’accesso in questione.
• I due data center distano tra loro in linea d’aria circa 450 metri (Figura 3) e saranno collegati attraverso una rete di interconnessione per il trasporto dati in fibra scura che garantisce due percorsi indipendenti di lunghezza non superiore ai 5 Km ciascuno, come meglio descritto nel paragrafo 2.4.
Relativamente alla ripartizione dell’infrastruttura sui due siti in modalità active / active, si ritiene importante porre l’attenzione sui servizi di data storage, rispetto ai quali l’Ateneo ha rilevato la necessità di orientarsi sulle più moderne soluzioni di storage federation, al fine di garantire una replica sincrona dei dati nei due data center; a tal proposito, si rimanda ai paragrafi 5.2.4 e 5.2.5 per ulteriori dettagli.
Infine, da un punto di vista tecnologico, l’Ateneo vuole adottare il paradigma del Software-Defined Data Center e le relative soluzioni, come recentemente affermatesi nel mercato (seppur ancora in fase di evoluzione e consolidamento). Rimandando al paragrafo 3.1.1 per la definizione adottata nell’ambito del presente documento, la declinazione pratica di questo orientamento verrà esplicitata nella descrizione di dettaglio del progetto di riferimento (capitolo 4) e dei requisiti (capitolo 5) dell’oggetto dell’appalto.
Figura 4 – Fotografie dell’accesso esterno al data center INFO2
2.3. Sapienza Private Cloud
Uno degli obiettivi del Programma N(BIT)2 e della costruzione della nuova infrastruttura, è di far evolvere i servizi IT dell’Ateneo verso una nuova modalità di erogazione del supporto informatico per le strutture interne dell’Università, che possa offrire maggiore flessibilità e adattabilità al contesto, rapidità di attivazione di nuovi servizi, adeguate prestazioni, e abilitare la creazione e diffusione di nuovi servizi innovativi e tecnologici. Tutto questo fondamentalmente grazie alle tecnologie ed alle soluzioni cosidette di Cloud Computing (si veda la definizione adottata nel paragrafo 3.1.1).
Beneficiando di un programma di investimento in attività formative offerto alla Sapienza dalla Fondazione Roma, ente morale con sede in Roma che persegue scopi di utilità sociale e di promozione dello sviluppo economico nel settore – tra gli altri – dell’Istruzione, è stato proposto ed approvato un progetto co-finanziato volto a sviluppare un catalogo di servizi Infrastructure-as-a-Service e Platform-as-a-Service (si vedano le definizione adottate nel paragrafo 3.1.1), messi a disposizione dal Centro Infosapienza per le strutture e gli utenti dell’Ateneo tramite un’infrastruttura di Cloud Computing privata.
Parte delle risorse e degli strumenti oggetto della presente gara (rif. §3.2) saranno pertanto destinati a supportare questa iniziativa, in particolare alcuni strumenti software, come meglio illustrato nel paragrafo 4.3.
A seguito dell’acquisizione di tali risorse, il Work Stream Private Cloud (non rientrante nell’ambito dell’appalto) si occuperà di:
• definire il modello di servizio complessivo ed il catalogo dei servizi IaaS e PaaS (Work Package WP.07 – Private Cloud Service Model Design);
• configurare gli strumenti ed implementare le procedure per l’erogazione dei servizi a catalogo (Work Package WP.08 – Private Cloud Sapienza).
Nell’ambito del programma presentato alla Fondazione Roma, il progetto è stato denominato “Azione N. 3.1 Cloud dedicato”. Come meglio specificato all’art. 10 del Capitolato d’oneri, in fase di esecuzione dell’appalto e di rendicontazione / fatturazione della fornitura, su indicazione del Centro Infosapienza alcuni beni ed attività dovranno essere riferiti esplicitamente ed univocamente a tale iniziativa, onde abilitare i processi di co-finanziamento. Inoltre il Centro Infosapienza si riserva di richiedere una rendicontazione / fatturazione per ulteriore quota parte dei beni forniti che sia riferita esplicitamente ed univocamente anche ad altre azioni previste nell’ambito del medesimo programma di co-finanziamento.
2.4. L’infrastruttura esistente
La forte spinta innovativa, sia nelle tecnologie che nelle metodologie di gestione, che il Programma N(BIT)2 vuole apportare, ha maturato nel Centro Infosapienza la scelta di traguardare una nuova infrastruttura IT che nascesse svincolata, per quanto possibile, da soluzioni e prodotti pre-esistenti.
Tuttavia, due fattori non possono essere del tutto elusi nella progettazione della nuova infrastruttura:
o fra i data center stessi (l’uno verso l’altro),
o verso il mondo esterno (ai data center), ossia il backbone di Ateneo, Internet ed il Sistema Pubblico di Connettività (SPC);
• la necessità, terminata la fase di realizzazione della nuova infrastruttura, di migrare i servizi erogati dal Centro Infosapienza dall’attuale landscape infrastrutturale al nuovo.
Di seguito vengono brevemente illustrate le implicazioni indotte dai suddetti fattori, rimandando ai capitoli 4 e 5 per maggiori dettagli espressi attraverso i requisiti tecnici richiesti alla fornitura.
Interconnessione fra i data center
Come già introdotto nel paragrafo 2.2, la nuova infrastruttura verrà dislocata in maniera speculare nei due siti INFO0 e INFO2. I due siti saranno collegati attraverso una rete di interconnessione per il trasporto dati che garantisce due percorsi indipendenti. In particolare:
• il percorso primario sarà formato da una coppia di fibre scure di tipo mono-modale, stese in un singolo tratto di circa 2 Km, con un’attenuazione stimata di 4,5 db misurata a 1550 ƞm;
• il percorso secondario sarà formato da una coppia di fibre scure di tipo mono-modale, stese lungo tre tratte di lunghezza complessiva di circa 5 Km, con un’attenuazione stimata in 12,75 db misurata a 1550 ƞm.
Per garantire un’adeguata ed affidabile capacità di scambio dati fra i due siti, la scelta strategica dell’Ateneo è ricaduta sulla tecnologia Dense Wavelength Division Multiplexing (DWDM), rientrante nell’ambito dell’oggetto dell’appalto; si rimanda al paragrafo 5.2.6 per maggiori dettagli e requisiti tecnici.
BACKBONE ATENEO SPC INTERNET
CORE ROUTER
FIREWALL
DWDM
DWDM
DATA CENTER INFO2
DATA CENTER INFO0
FIREWALL
CORE ROUTER
Figura 5 – Schema generale di interconnessione dei data center
Interconnessione verso il mondo esterno ai data center
In base allo schema riportato in Figura 5, gli apparati presenti dentro i due data center comunicheranno verso il mondo esterno attraverso degli apparati core (router e firewall), non rientranti nell’ambito della fornitura.
Per gli oggetti direttamente deputati al colloquio con questi apparati, come meglio descritto nel paragrafo 4.1, è richiesta una piena compatibilità verso gli attuali prodotti in uso presso l’Ateneo:
• Core router: marca Cisco serie Catalyst 6500 / 6800.
• Firewall: marca Check Point serie 12600.
Si rimanda ai paragrafi 5.2.6 e 5.2.7 per maggiori informazioni, in termini di requisiti tecnici di dettaglio della fornitura richiesta.
Infrastruttura Fabric Fiber Channel esistente
Attualmente il landscape infrastrutturale dell’Ateneo è costituito da una infrastruttura distribuita (in maniera non uniforme) fra due siti: il data center INFO2, già presentato nel paragrafo 2.2, ed il data center denominato INFO1, di cui è programmata la dismissione al termine della migrazione verso la nuova infrastruttura (Work Package WP.06 – INFO1 Turning OFF & Disposal, rif. §2.1).
Attualmente la componente più importante nell’erogazione dei servizi da parte del Centro Infosapienza è costituita da un’infrastruttura formata da sistemi Blade Server e sistemi Storage Area Network (SAN), interconnessi attraverso un network di tipo Fiber Channel (FC), basato su prodotti Brocade.
Tale infrastruttura ospita un ambiente di virtualizzazione su cui vengono esercite le macchine virtuali con i principali (e di maggiore numerosità) servizi erogati dal Centro Infosapienza e che necessariamente andranno migrate all’interno della nuova infrastruttura oggetto dell’appalto. A tale scopo è pertanto necessario che gli analoghi apparati di interconnessione FC previsti nella nuova infrastruttura (i.e. switch FC) siano compatibili con l’attuale infrastruttura Brocade e ne permettano quindi un’estensione (o in altri termini l’interoperabilità fra le due infrastrutture FC). Si rimanda ai paragrafi 5.2.9 e 5.5.5 per maggiori informazioni, in termini di requisiti tecnici di dettaglio della fornitura richiesta.
Relativamente alla componente SAN esistente, essa è costituita da due unità IBM Storwize V7000. Rimandando al capitolo 4 per maggiori spiegazioni, si anticipa qui che la piattaforma di virtualizzazione dello storage prevista nella nuova infrastruttura deve poter operare anche verso tale prodotto SAN esistente.
Piattaforma di virtualizzazione delle risorse di computing
Come sopra menzionato, i principali e più numerosi servizi erogati dal Centro Infosapienza si basano su risorse di calcolo virtualizzate (virtual machine – VM). Durante il lungo e laborioso percorso di progressiva virtualizzazione delle precedenti architetture di tipo fisico, il Centro Infosapienza si è dotato dei prodotti e delle competenze della piattaforma di virtualizzazione VMware, e delle correlate componenti di gestione centralizzata ed avanzata.
Al fine di massimizzare lo sfruttamento di tali asset, ridurre la complessità dell’attività di migrazione verso la nuova infrastruttura e dare maggiore continuità possibile alla gestione operativa nell’erogazione dei servizi (durante e dopo la migrazione), il progetto di riferimento alla base della nuova infrastruttura IT oggetto dell’appalto prevede il mantenimento dell’impiego e della centralità della piattaforma VMware (non inclusa nell’oggetto della fornitura). In particolare il software di riferimento sarà costituito dal pacchetto VMware vCloud Suite Standard.
Si rimanda al paragrafo 4.3 per una presentazione più organica del framework di gestione software-based complessivo traguardato, in grado di coniugare diversi temi contigui presentati in questo capitolo:
• il paradigma Software-Defined Data Center,
• gli strumenti di gestione dei servizi di Cloud Computing privato,
• la piattaforma di virtualizzazione delle risorse di computing,
ed al capitolo 5 per i correlati requisiti tecnici di dettaglio della fornitura richiesta.
Tecnologia dei processori
Sulla base delle medesime considerazioni di cui al punto precedente, relative alla complessità progettuale ed alla continuità operativa nella fase di migrazione, e delle caratteristiche (feature) della piattaforma di virtualizzazione in dotazione, il progetto di riferimento prevede che la migrazione di tutte le risorse di calcolo virtualizzate avvenga sfruttando al meglio le funzionalità di trasferimento delle virtual machine (VMware vMotion) fra le risorse hardware dell’attuale infrastruttura e quelle predisposte nella nuova infrastruttura.
La possibilità di accedere in sicurezza a questa funzionalità richiede che la tecnologia di costruzione dei processori sia uniforme in entrambe le infrastrutture. Ne consegue il vincolo che le risorse hardware di
calcolo della nuova infrastruttura dovranno basarsi su processori (CPU) di tecnologia Intel, come quelli presenti nell’attuale infrastruttura. Si rimanda al paragrafo 5.2.2 per maggiori dettagli.
3. Definizione della fornitura
3.1. Definizioni e acronimi
As-a-Service | Modalità di erogazione di un servizio IT (a vari livelli – da infrastrutturale ad applicativo) secondo il modello Cloud Computing. Si vedano anche le voci Infrastructure-as-a-Service e Platform-as-a-Service. |
Cloud Computing | Modello per consentire l’accesso via rete, delocalizzato, conveniente, a richiesta, ad un insieme condiviso di risorse IT configurabili, che possono essere messe a disposizione in tempi brevi, con minimi costi di gestione e minima interazione con la struttura erogante. |
Cloud Service Platform | Strumenti software per l’erogazione tramite portale di servizi di tipo Cloud Computing/As-a- Service relativamente a risorse IT a vario livello (da infrastrutturali ad applicative), sulla base di processi automatizzati di pubblicazione, erogazione, monitoraggio, misurazione, rendicontazione delle risorse, fruibili dagli utenti in modalità self-service e on-demand. |
Convergente | Da riferirsi a componenti dell’infrastruttura di networking (es. interfacce di rete, porte, ecc.), intende la capacità di implementare il protocollo Fiber Channel su rete di tipo Ethernet (i.e. Fiber Channel over Ethernet – FCoE). |
Hypervisor | Ambiente di erogazione delle risorse di calcolo, quali ad esempio CPU e RAM, tramite una tecnica di virtualizzazione grazie alla quale le risorse vengono fornite e amministrate attraverso una componente software, separata dalle componenti hardware sottostanti, in grado di implementare funzionalità di gestione avanzate, di maggiore astrazione e programmabili. |
Hypervisor Manager | Strumento software di gestione delle risorse erogate dall’Hypervisor, in grado di implementare funzionalità avanzate e programmabili, quali (a titolo di esempio non esaustivo) la gestione centralizzata e condivisa fra più istanze dell’Hypervisor stesso. |
Infrastructure-as-a- Service | Servizio As-a-Service in cui le risorse IT oggetto del servizio sono di livello infrastrutturale (computing, storage, networking e sicurezza), sia singolarmente che composte in un modello architetturale complesso (es. architettura multi-tier). |
Orchestration & Automation Engine | Strumento software di coordinamento e comando delle risorse dell’infrastruttura IT (computing, storage, networking e sicurezza), attraverso l’esecuzione automatizzabile (parzialmente o totalmente) e pianificabile di flussi di lavoro (workflow), quali (a titolo di esempio non esaustivo) processi di provisioning, di gestione sistemistica, di change management e di decommissioning. |
Platform-as-a-Service | Servizio As-a-Service in cui le risorse IT oggetto del servizio sono funzioni o ambienti di livello middleware, quali (a titolo di esempio non esaustivo) Database Management, Identity & Access Management, piattaforme di sviluppo ed esecuzione di applicazioni. |
Software-Defined Data Center | Infrastruttura IT in cui le risorse essenziali (computing, storage, networking e sicurezza) vengono fornite, messe in esercizio e gestite attraverso una serie di primitive applicative (Application Program Interface – API). Secondo la visione adottata dal Centro Infosapienza, essa comprende le componenti: Software-Managed Computing, Software-Defined Networking, Software-Defined Storage, Hypervisor, Hypervisor Manager e Orchestration & Automation Engine. |
Software-Defined Networking | Infrastruttura di networking, progettata e realizzata con una tecnica grazie alla quale le risorse (quali ad esempio switch e router – fisici e/o virtuali) vengono fornite e amministrate attraverso una componente software, separata dalle componenti hardware sottostanti, in grado di implementare funzionalità (e metodologie) di gestione avanzate, di maggiore astrazione e programmabili. |
Software-Defined Storage | Infrastruttura storage, progettata e realizzata con una tecnica grazie alla quale le risorse (quali ad esempio dischi e controller – fisici e/o virtuali) vengono fornite e amministrate attraverso una componente software, separata dalle componenti hardware sottostanti, in grado di implementare funzionalità (e metodologie) di gestione avanzate, di maggiore astrazione e programmabili. |
Software-Managed Computing | Risorse hardware di calcolo, quali ad esempio CPU e RAM, amministrabili attraverso una componente software in grado di esporre funzionalità di gestione avanzate programmabili. |
3.1.2. Acronimi
API: Application Program Interface | NTW: Network |
C-NIC: Converged Network Interface Card | OA: Orchestration & Automation |
CSP: Cloud Service Platform | OM4: Optical Multimode 4 |
DC: Data Center | OSI: Open Systems Interconnection |
DWDM: Dense Wavelength Division Multiplexing | OTU: Optical Transport Unit |
ETH: Ethernet | PaaS: Platform-as-a-Service |
FC: Fiber Channel | QSFP: Quad Small Form-factor Pluggable |
FCoE: Fiber Channel over Ethernet | RPO: Recovery Point Objective |
HBA: Host Bus Adapter | SAN: Storage Area Network |
HM: Hypervisor Manager | SDDC: Software-Defined Data Center |
HW: Hardware | SDN: Software-Defined Network |
IaaS: Infrastructure-as-a-Service | SDS: Software-Defined Storage |
IP: Internet Protocol | SFP: Small Form-factor Pluggable |
ISO: International Standards Organization | SLA: Service Level Agreement |
IT: Information Technology | SMC: Software-Managed Computing |
KVM: Keyboard-Video-Mouse | SPC: Sistema Pubblico di Connettività |
LC: Xxxxxxx Connector | SPEC: Standard Performance Evaluation Corporation |
LUN: Logical Unit Number | SW: Software |
MAC: Media Access Control | TVM: Tastiera-Video-Mouse |
MPO: Multi-fiber Push-On | VCPU: Virtual CPU |
N(BIT)2: Building a New Break-Through IT Infrastructure | VLAN: Virtual Local Area Network |
NIC: Network Interface Card | VM: Virtual Machine |
3.2. Oggetto
L’oggetto dell’appalto è costituito dai beni informatici necessari per la costruzione di una nuova infrastruttura di Information Technology (IT), rispondente alle esigenze ed alle scelte tecnico-strategico dell’Ateneo, e dai servizi necessari alla sua messa in opera ed in funzione, con manutenzione e assistenza per un periodo di 5 anni.
La Tabella 1 elenca gli elementi costituenti la fornitura, caratterizzati per tipologia e dominio IT; ad ogni elemento è assegnato un codice identificativo strutturato che lo identifica univocamente. I singoli elementi sono descritti in dettaglio nel capitolo 5.
ID | Tipologia | Dominio | Denominazione |
Hardware | Computing | Blade Server | |
Hardware | Computing | Blade Chassis | |
Hardware | Storage | Storage Area Network | |
Hardware | Storage | Piattaforma di Virtualizzazione dello Storage | |
Hardware | Network | Piattaforma DWDM | |
Hardware | Network | Switch Data Center Ethernet | |
Hardware | Network | Moduli e Porte per Switch Data Center Ethernet | |
Hardware | Network | Switch FC | |
Hardware | Network | Moduli e Porte per Switch FC | |
Hardware | Network | Switch Rack Ethernet | |
Hardware | Network | Apparati di Distribuzione Ethernet per Blade | |
Hardware | Network | Apparati di Distribuzione FC per Blade | |
Software | Tools | Orchestration & Automation Engine | |
Software | Cloud | Cloud Service Platform | |
Accessori | Computing | Console KVM | |
Accessori | Network | Cablaggio della Rete Dati dei Data Center | |
Servizi | Generale | Project Management | |
Servizi | Generale | Trasporto e Consegna Materiali | |
Servizi | Generale | Installazione e Configurazione | |
Servizi | Generale | Estensione Fabric FC Esistente | |
Servizi | Generale | Predisposizione al Collaudo | |
Servizi | Generale | Formazione | |
Servizi | Generale | Manutenzione e Assistenza per 5 Anni |
Tabella 1 – Elenco degli elementi della fornitura oggetto dell’appalto
3.3. Durata delle attività
La durata complessiva del contratto è da intendersi determinata da due componenti:
• i servizi necessari alla messa in opera, alla verifica di conformità (collaudo) ed alla messa in funzione dell’infrastruttura oggetto dell’appalto, la cui durata complessiva è valutata in circa 3 mesi solari a partire dalla data di stipula del contratto, come meglio illustrato nel paragrafo 5.5;
• i servizi di manutenzione e assistenza per un periodo di 5 anni (rif. §5.5.8) su ogni bene oggetto della fornitura, a partire dalla data di accettazione da parte del Centro Infosapienza del collaudo dell’infrastruttura IT fornita.
3.4. Criteri di valutazione tecnica
Alcuni requisiti e caratteristiche degli elementi costituenti la fornitura, così come censiti nella Tabella 1 del paragrafo 3.2, saranno oggetto di valutazione tecnica rispetto a quanto proposto in sede di Offerta Tecnica dal Fornitore; si rimanda all’art. 20 del Disciplinare di gara per maggiori dettagli.
Nel capitolo 5, oltre alla descrizione dei singoli elementi, verranno indicati, ove applicabile, i criteri di valutazione tecnica applicati a uno o più oggetti considerati.
Per ogni criterio verranno descritte le modalità e i parametri di valutazione e sintetizzate in forma tabellare le seguenti informazioni:
• il codice identificativo composito del criterio di valutazione tecnica;
• una descrizione breve del criterio;
• il codice dei requisiti (uno o più) della fornitura oggetto di valutazione attraverso il criterio;
• la quota massima di punti tecnici associati al criterio;
• la modalità di valutazione del criterio, distinguendo fra:
o tabellare SI-NO,
o tabellare a livelli,
o discrezionale,
o discrezionale con soglia;
• l’eventuale punteggio minimo di soglia;
• alcune note specifiche relative alle modalità di valutazione.
4. Progetto di riferimento
Nel presente capitolo vengono illustrati alcuni principi e soluzioni progettuali adottati dal Centro Infosapienza per impostare la realizzazione della nuova infrastruttura IT oggetto della presente gara, secondo tre dimensioni di analisi:
• l’architettura hardware e la rete di networking per l’interconnessione degli apparati,
• il layout di sala degli apparati hardware,
• il framework e gli strumenti software di gestione dell’infrastruttura.
In sede di Offerta Tecnica, è richiesto al Fornitore (come più dettagliatamente indicato nel paragrafo 5.1) di proporre un proprio progetto esecutivo di massima, che recepisca e sviluppi il progetto di riferimento di seguito esposto.
In ogni caso, tutti i vincoli e le indicazioni espressi nel presente e nel prossimo capitolo devono essere rispettati dalla soluzione proposta dal Fornitore, salvo se diversamente esplicitato.
4.1. Architettura
Dal punto di vista architetturale in sintesi gli obiettivi della nuova infrastruttura IT oggetto dell’appalto sono in primis:
• mettere a disposizione risorse di computing, di tipo server a lame;
• mettere a disposizione risorse di storage, di tipo SAN, virtualizzate e federate;
• interconnettere le risorse di computing con le risorse di storage, attraverso un network di tipo FC;
• interconnettere tutte le risorse fra di loro e con il mondo esterno (backbone di Ateneo, SPC ed Internet), attraverso un network di tipo Ethernet, ai fini sia dell’erogazione dei servizi (network di produzione) sia della gestione delle singole risorse (network di management);
• interconnettere i due siti fra loro, attraverso una piattaforma DWDM (rif. §2.4).
E inoltre:
• strutturare il network di tipo Ethernet (all’interno dei data center) in maniera gerarchica e distribuita, in modo da semplificare la progettazione e la gestione nel tempo dei cablaggi e delle matrici di connessione, in particolare in vista di necessità future ad oggi non definite;
Il progetto architetturale di riferimento schematizzato in Figura 6 intende rispondere a queste necessità. Va precisato che lo schema rappresentato descrive l’architettura all’interno di un singolo data center, da intendersi quindi poi replicata fra i due siti INFO0 e INFO2. Per una vista più ampia sul landscape complessivo si rimanda allo schema già presentato nella Figura 5 nel paragrafo 2.4.
Come meglio illustrato nel paragrafo 4.2, il progetto prevede alla base la caratterizzazione dei singoli rack presenti nel data center, distinguendo in particolare fra gli altri:
• i rack di computing, ossia destinati ad accogliere risorse di calcolo (sistemi server), sia oggetto della fornitura che loro espansioni future;
• i rack di storage, ossia destinati ad accogliere i sistemi di archiviazione dati, sia oggetto della fornitura che loro espansioni future;
• i rack destinati ad apparati legacy (di varia natura) o a future espansioni dell’infrastruttura;
Con riferimento all’elenco di elementi oggetto della fornitura, codificati nel paragrafo 3.2, il progetto prevede che:
• nei rack di computing vengano installati i Blade Chassis (codice HW-CP-02, rif. §5.2.3) con alloggiati all’interno i Blade Server (codice HW-CP-01, rif. §5.2.2);
• nei rack di storage vengano installati gli apparati Storage Area Network (codice HW-ST-01, rif.
§5.2.4) e i componenti della Piattaforma di Virtualizzazione dello Storage (codice HW-ST-02, rif.
§5.2.5).
Prima di parlare delle reti di interconnessione fra queste componenti (sia FC che Ethernet), va premessa una nota esplicativa circa il progetto di riferimento definito dal Centro Infosapienza. Avendo infatti verificato che nel mercato esistono attualmente diversi approcci e soluzioni sulla tematica, con effetti (diretti ed indiretti) profondamente differenti fra le varie soluzioni, e volendo lasciare al Fornitore la proposizione, in sede di Offerta Tecnica, della soluzione che ritiene più vantaggiosa tecnicamente e/o economicamente, nel progetto si è prevista in maniera generica la presenza di apparati di distribuzione del network non meglio identificati; il Capitolato pone invece attenzione sugli indicatori, oggetto di valutazione tecnica, attraverso i quali si potrà differenziare il valore delle soluzioni offerte.
Venendo alla rete di interconnessione di tipo FC, i Blade Server e i componenti di data storage (SAN e Piattaforma di Virtualizzazione) devono essere connessi attraverso una rete ridondata comandata da una coppia di Switch FC (codice HW-NT-04, rif. §5.2.9) in alta affidabilità, con un adeguato numero di moduli e porte disponibili e licenziati su tali switch (codice HW-NT-05, rif. §5.2.10), e formata da Apparati di Distribuzione FC per Blade (codice HW-NT-08, rif. §5.2.13), determinati e forniti dal Fornitore secondo la propria soluzione offerta (rif. §5.1) nel rispetto dei requisiti tecnici di dettaglio espressi a riguardo. Lo Switch FC deve inoltre garantire l’interoperabilità con la rete di interconnessione / switch FC legacy già esistente, basata su prodotti Brocade (rif. §5.2.9.1).
Per quanto riguarda la rete di tipo Ethernet, tutte le risorse HW (di computing o storage o networking – sia nuove che legacy) devono essere interconnesse, ai fini sia dell’erogazione dei servizi (network di produzione) sia della gestione delle singole risorse (network di management), secondo i seguenti principi:
• l’intera rete di interconnessione Ethernet deve essere comandata da una coppia di Switch Data Center (DC) Ethernet (codice HW-NT-02, rif. §5.2.7) in alta affidabilità, con un adeguato numero di moduli e porte disponibili e licenziati su tali switch (codice HW-NT-03, rif. §5.2.8);
• i Blade Server devono essere connessi agli Switch DC Ethernet attraverso una rete ridondata formata da Apparati di Distribuzione Ethernet per Blade (codice HW-NT-07, rif. §5.2.12), determinati e forniti dal Fornitore secondo la propria soluzione offerta (rif. §5.1) nel rispetto dei requisiti tecnici di dettaglio espressi a riguardo;
• eventuali risorse legacy o future (ad oggi non identificate) da allocarsi all’interno di un generico rack dovranno essere connesse agli Switch DC Ethernet in maniera ridondata attraverso una coppia di Switch Rack Ethernet (codice HW-NT-06, rif. §5.2.11), in alta affidabilità;
• per i rack di storage (rif. §4.2), è inclusa nella fornitura oggetto dell’appalto la connessione ridondata (ove applicabile) fra gli Switch Rack Ethernet e le componenti di data storage (SAN e Piattaforma di Virtualizzazione), ai fini della distribuzione del network di management;
• nella soluzione oggetto della fornitura si prevede l’installazione degli Switch Rack Ethernet, oltre che nei rack di storage (si veda il punto precedente), almeno anche nei rack per legacy, tuttavia si deve assumere che ogni rack generico possa ospitare tali switch; a tal proposito, in ogni caso, per i rack di computing gli Switch Rack Ethernet non possono coincidere con gli Apparati di Distribuzione Ethernet per Blade da prevedersi da parte del Fornitore;
• gli Switch DC Ethernet devono essere connessi con gli apparati core (firewall e router) esistenti, garantendo la compatibilità (si vedano i requisiti tecnici di dettaglio);
• gli Switch DC Ethernet devono essere connessi con la Piattaforma DWDM (codice HW-NT-01, rif.
§5.2.6), costituita da una coppia di apparati in alta affidabilità (uno per sito), in grado di garantire l’interconnessione fra i due siti, ed in particolare:
o lo scambio dati fra gli Switch DC Ethernet,
o lo scambio dati fra gli Switch FC,
o la sincronia fra gli apparati core (firewall e router esistenti),
garantendo la compatibilità con questi ultimi (si vedano i requisiti tecnici di dettaglio).
Come indicato nello schema e meglio specificato nel paragrafo 5.2.13, l’Ateneo ammette la possibilità che, in virtù di tecnologie relativamente recenti, vi sia una parziale convergenza fra la connettività di tipo FC e quella di tipo Ethernet, riconoscendovi anche una valenza migliorativa: si ritiene infatti che l’utilizzo di apparati convergenti (si veda la definizione adottata nel paragrafo 3.1.1) porti benefici in termini di semplificazione dell’infrastruttura e delle logiche di networking e relativi costi di gestione. Nel caso in cui il Fornitore offra una soluzione di questo tipo, gli Apparati di Distribuzione FC per Blade dovranno coincidere fisicamente con gli Apparati di Distribuzione Ethernet per Blade; si specifica invece che, per i particolari requisiti di compatibilità verso il network FC esistente, necessariamente lo Switch FC fornito non dovrà coincidere fisicamente con lo Switch DC Ethernet, quand’anche quest’ultimo supporti porte convergenti. Tale scenario viene illustrato in Figura 7.
Relativamente alle velocità di trasmissione dati nell’interconnessione fra le diverse risorse, il progetto di riferimento prevede quanto segue:
• Il network di produzione di tipo Ethernet deve garantire una velocità pari ad almeno 10 Gb/s su tutte le singole connessioni del backbone dei data center, ad eccezione del segmento di connessione fra lo Switch DC Ethernet e i Blade Server (i.e. attraverso gli Apparati di Distribuzione Ethernet per Blade).
• Il network di produzione di tipo Ethernet nel segmento di connessione fra lo Switch DC Ethernet e i Blade Server (i.e. attraverso gli Apparati di Distribuzione Ethernet per Blade) deve garantire una velocità pari ad almeno 1 Gb/s per singola interfaccia di rete di ogni Blade Server oggetto delle fornitura. L’Ateneo considera un fattore premiante il potenziamento dell’infrastruttura per garantire velocità superiori su tali tratte; si rimanda al paragrafo 5.2.12 per maggiori informazioni.
• Il network di tipo FC deve garantire una velocità pari ad almeno 8 Gb/s su tutte le singole connessioni del backbone dei data center, in particolare sia verso le componenti di data storage (SAN e Piattaforma di Virtualizzazione) sia fino all’arrivo sul singolo Blade Chassis (i.e. attraverso gli Apparati di Distribuzione FC per Blade). L’Ateneo considera un fattore premiante il potenziamento dell’infrastruttura per garantire una velocità pari a 16 Gb/s su tali connessioni (si vedano i requisiti tecnici di dettaglio ed i criteri di valutazione tecnica), fatta eccezione per i collegamenti verso lo switch FC legacy e verso la Piattaforma DWDM.
• La Piattaforma DWDM deve garantire una velocità pari ad almeno 10 Gb/s per le trasmissioni di tipo Ethernet fra i siti e 8 Gb/s per quelle di tipo FC. L’Ateneo considera un fattore premiante il potenziamento della piattaforma per garantire una velocità di tramissione di tipo Ethernet fino a 100 Gb/s; si rimanda al paragrafo 5.2.6 per maggiori informazioni.
• Il network di management di tipo Ethernet deve garantire una velocità pari ad almeno 1 Gb/s su tutte le connessioni, laddove previste dalla fornitura.
Riprendendo le indicazioni strategiche formulate nel paragrafo 2.2, il progetto di riferimento prevede che le due SAN (una per data center) oggetto della fornitura siano “federate” attraverso la Piattaforma di Virtualizzazione dello Storage, ossia che nella fattispecie garantiscano una sincronia in tempo reale dei dati fra i due siti, con l’obiettivo primario di offrire la massima affidabilità dell’infrastruttura nella conservazione dei dati, risultando così fortemente tollerante a problemi di natura fisica agli apparati. La federazione delle SAN può configurarsi di base come una configurazione di tipo active / passive, ossia una SAN in un sito eroga i servizi di data storage, mentre l’altra SAN nel secondo sito si occupa solo di mantenere una copia allineata dei dati. Tuttavia, nell’ottica di poter riuscire ad erogare i servizi in maniera bilanciata fra i due siti, l’Ateneo considera un fattore significativamente premiante l’implementazione di una configurazione di tipo active / active (si rimanda al paragrafo 5.2.5 per maggiori informazioni). Per completezza, si fa presente che il progetto prevede inoltre che l’accesso a tutte le SAN (sia presenti che future) sia sempre mediato dalla Piattaforma di Virtualizzazione.
Infine, per concludere l’elenco di beni materiali previsti dalla fornitura, il progetto di riferimento prevede inoltre:
• l’installazione dei moduli di un’infrastruttura di Console KVM (codice AC-CP-01, rif. §5.4.1) nei rack di cui si prevede l’impiego nell’ambito del progetto, eccetto quelli di permuta (rif. §4.2);
• il cablaggio completo della rete dati (codice AC-NT-01, rif. §5.4.2) verso tutti i rack previsti nei due data center (24 per INFO0 e 12 per INFO2 – rif. §4.2), secondo le caratteristiche dei network di tipo Ethernet e FC offerti dal Fornitore.
Come meglio descritto nel paragrafo 5.5.8, tutti i beni HW oggetto della fornitura dovranno essere coperti da un servizio di Manutenzione e Assistenza per 5 anni (codice SR-CM-01) dalla data di collaudo dell’infrastruttura (rif. §6).
4.2. Layout di sala
Di seguito si riportano gli schemi di riferimento relativi alla dislocazione degli elementi HW oggetto della fornitura all’interno dei due data center, con l’obiettivo di rendere disponibili informazioni utili affinché il
Fornitore possa adeguatamente progettare e dimensionare il cablaggio completo della rete dati (codice
AC-NT-01, rif. §5.4.2) verso tutti i rack previsti nei due data center.
In Figura 8 viene presentata una vista ortogonale dal layout di sala per i due data center INFO0 e INFO2, che, come presentato nel paragrafo 2.2, prevedono ciascuno un’isola fredda costituita da 24 e 12 rack rispettivamente.
Il progetto di riferimento prevede la caratterizzazione dei singoli rack presenti nel data center, distinguendo:
• rack di computing, destinati ad accogliere risorse di calcolo – sistemi server –, sia oggetto della fornitura che loro espansioni future;
• rack di storage, destinati ad accogliere i sistemi di archiviazione dati, sia oggetto della fornitura che loro espansioni future;
• rack del core del network, deputati ad ospitare gli apparati attivi di rete che costituiscono la struttura portante del network (di tipo Ethernet), in particolare per le funzionalità base di routing;
• rack per servizi di network, dove ospitare gli apparati attivi di rete che implementino servizi avanzati di rete, quali il load balancing hardware, l’intrusion prevention, ecc.;
• rack di permuta, per l’implementazione delle matrici fisiche di connettività (i.e. permute), parte del materiale di cablaggio previsto nella fornitura;
• rack destinati all’alloggiamento di apparati legacy (di varia natura);
• rack riservati per future espansioni dell’infrastruttura.
Xxxx non rientranti nel progetto in questione (al netto del cablaggio della rete dati, che deve interessare tutti i rack) e destinati a differenti finalità, vengono indicati in figura come rack per altri usi.
La Figura 9 riporta invece una vista concettuale frontale dei rack dei due data center, considerando i soli rack di cui si prevede l’impiego nel progetto, ossia (in totale, considerando entrambi i data center):
• 4 rack di computing,
• 2 rack di storage,
• 2 rack del core del network,
• 2 rack per servizi di network,
• 2 rack di permuta,
• 4 rack per legacy,
• 6 rack per future espansioni.
Si evidenzia ancora una volta come le composizioni degli elementi infrastrutturali nei singoli data center siano esattamente speculari.
Figura 9 – Layout concettuale frontale dei rack dei data center
4.3. Framework di gestione software-based
E’ stato già evidenziato (paragrafi 2.2 e 2.3) come la nuova infrastruttura IT dovrà nascere adottando alla radice il modello del Cloud Computing ed il paradigma del Software-Defined Data Center. Questo approccio implica anche (e soprattutto) dotarsi di strumenti SW e di metodologie che abilitino una modalità di gestione assolutamente innovativa dell’infrastruttura e delle sue risorse, per lo meno rispetto all’attuale situazione del Centro Infosapienza, fondata su approcci di tipo tradizionale. Tali strumenti permetteranno inoltre di sviluppare i servizi IaaS e PaaS del Cloud privato della Sapienza.
Nel variegato panorama di tecnologie e soluzioni ancora in forte evoluzione e non del tutto consolidato, pure in letteratura, il Centro Infosapienza ha ritenuto di definire un proprio framework di riferimento, anche ai fini di una comprensione comune con il Fornitore per interpretare le esigenze espresse dall’Ateneo nell’ambito della presente gara.
Figura 10 – Framework di gestione software-based adottato per la nuova infrastruttura IT
Il framework, di seguito illustrato, è sintetizzato in Figura 10, rimandando al paragrafo 3.1 per una spiegazione degli acronimi utilizzati e per la definizione di riferimento dei singoli componenti.
Il framework, nella sua interezza, evidenzia innanzitutto un aspetto chiave: esso mette a disposizione strumenti e servizi per due categorie di beneficiari:
• gli amministratori IT, incaricati di gestire l’intera infrastruttura alla base dei servizi erogati;
• gli utenti clienti, consumatori dei servizi di tipo Cloud Computing.
Per gli amministratori IT il framework offre innanzitutto gli strumenti di Software-Defined Data Center, che estendono l’infrastruttura prettamente hardware (mondo fisico), per introdurre utility software di progressiva astrazione e automazione. Sopra questi strumenti, si prevede la costruzione di una piattaforma di Cloud Management, volta ad erogare servizi di tipo Cloud Computing, proprio sfruttando le facilitazioni e
automazioni offerte dal layer sottostante; in questo ambito gli Amministratori IT agiscono come coloro che definiscono i servizi, mentre gli utenti clienti ne usufruiscono.
Software-Defined Data Center
Il primo passo nel passare da un’infrastruttura tradizionale ad un’infrastruttura SDDC è far evolvere singolarmente le tre componenti fondamentali che la compongono: computing, storage e network; si parla ora infatti, rispettivamente di Software-Managed Computing (SMC), Software-Defined Storage (SDS), Software-Defined Network (SDN). Rimandando per maggiori dettagli (oltre che alle definizioni) all’insieme di caratteristiche e requisiti tecnici previsti per i corrispondenti elementi hardware della fornitura (capitolo 5), si vuole qui sottolineare come il punto chiave sia il fatto che le risorse in questione da oggetti del puro mondo fisico diventano componenti definibili e/o gestibili in un ambiente software programmabile.
A queste tre componenti si affianca un quarto “dominio” già ampiamente consolidato nel panorama tecnologico, quello delle risorse di calcolo virtualizzate, sintetizzato nello schema attraverso le componenti Hypervisor e Hypervisor Manager.
Per realizzare l’infrastruttura SDDC è quindi necessario introdurre la componente Orchestration & Automation (OA) Engine (codice SW-TL-01, rif. §5.3.2), ossia uno strumento prettamente SW in grado di interagire con tutte le risorse infrastrutturali già menzionate, a vari livelli di sofisticazione, in base alle funzioni esposte dalle risorse in maniera programmabile (es. primitive API) o invocabili remotamente (es. command- line script); come meglio specificato nel paragrafo 5.3.2, l’Ateneo considera fattore premiante una capacità quanto più estesa possibile dell’OA Engine di orchestrare le risorse sottostanti, in particolare anche quelle del mondo fisico.
L’OA Engine deve rappresentare lo strumento principale con cui gli amministratori IT potranno e dovranno gestire l’intera infrastruttura, grazie alla possibilità di definire, anche in modalità visuale avanzata (es. tipo drag&drop), dei flussi di lavoro (workflow) automatizzabili (parzialmente o totalmente), pianificabili, ripetibili, monitorabili, da un punto di gestione centralizzato; si rimanda ai requisiti tecnici di dettaglio per una più ampia caratterizzazione dello strumento.
In ogni caso, il framework prevede che gli amministratori continuino per necessità od opportunità ad intervenire direttamente sulle risorse sottostanti, sia di tipo software-defined che del mondo fisico.
E’ opportuno precisare che tutte le componenti citate finora (compreso il mondo fisico) rappresentano nel framework degli oggetti concettuali, ossia un insieme di servizi e funzionalità con ruolo e obiettivi ben identificati. Tuttavia, nell’implementazione reale (compresa l’infrastruttura a tendere traguardata dal Centro Infosapienza) essi possono tradursi in multiple istanze di oggetti, anche di produttori e con tecniche di funzionamento differenti: ad esempio sono ipotizzabili diversi sistemi server / SMC oppure multipli storage area network / SDS, realizzati da produttori differenti. In tal senso, l’obiettivo del framework ed i concetti alla base dell’astrazione del SDDC sono volti proprio a garantire l’interoperabilità e l’uniformità di gestione fra soluzioni diverse, ma basate su modelli comuni e, ove possibile, protocolli aperti e/o standard, verso cui l’Ateneo auspica un forte orientamento, come indicato nei criteri di valutazione tecnica dell’OA Engine.
Rappresenta un ulteriore esempio di questo aspetto la componente Hypervisor, in cui è necessario garantire la compatibilità con i maggiori prodotti attualmente disponibili nel panorama tecnologico. Ciò non di meno, si ricorda che la soluzione offerta dal Fornitore deve rispettare il vincolo di contesto dell’infrastruttura esistente (rif. §2.4), per cui il SW di riferimento per le componenti Hypervisor e Hypervisor Manager sarà costituito dal pacchetto VMware vCloud Suite Standard.
Cloud Management
Salendo nello stack software previsto dal framework, si entra poi nell’ambito del Cloud Management, dove si prevede l’impiego di una piattaforma, denominata Cloud Service Platform (CSP, codice SW-CL-01, rif.
§5.3.3), necessaria ad erogare i servizi di tipo Cloud Computing direttamente agli utenti clienti in modalità self-service.
A tale scopo, nel framework vengono evidenziate le componenti / funzionalità minime che la piattaforma deve coprire (Portal, Profiling, Catalogue, Monitoring, Showback) e che devono essere disponibili sia agli
amministratori, quali strumenti tecnici di configurazione e gestione dei servizi, sia agli utenti clienti, quali fruitori non tecnici dei servizi. Di nuovo si rimanda alla descrizione ed ai requisiti tecnici di dettaglio per una più ampia caratterizzazione dello strumento.
Si ritiene importante evidenziare che nel framework proposto, la CSP vuole rappresentare un’ambiente e delle funzionalità SW che implementino le modalità ed i processi tipici per erogare on-line servizi di tipo Cloud Computing (si prendano a riferimento servizi As-a-Service del Cloud pubblico ormai consolidati, quali quelli offerti da Amazon, Google, Microsoft, ecc.), che inevitabilmente possono esistere e funzionare solo attraverso una stretta integrazione con l’OA Engine, che ha il compito di eseguire tutti i workflow automatici (parzialmente o totalmente – ad es. in funzione della eventuale necessità di approvazione da parte dell’amministratore delle richieste dell’utente) conseguenti alle interazioni ed alle richieste dell’utente. E’ ammissibile che le due componenti, OA Engine e CSP, possano corrispondere a moduli di una suite integrata offerta dal Fornitore o anche a sole funzionalità distribuite su moduli che non trovino una corrispondenza diretta con la suddivisione proposta dal framework dell’Ateneo.
Per concludere, si evidenzia che tutti i beni SW oggetto della fornitura:
• dovranno essere già commercializzati al momento della presentazione dell’Offerta Tecnica da parte del Fornitore (in altri termini non sono ammessi sviluppi ad hoc delle funzionalità richieste, se non in termini di semplici configurazioni o parametrizzazioni), come indicato nel paragrafo 5.3.1;
• dovranno essere coperti da un servizio di Manutenzione e Assistenza per 5 anni (codice
SR-CM-01) dalla data di collaudo dell’infrastruttura (rif. §6), come meglio descritto nel paragrafo 5.5.8.
5. Descrizione dell’appalto
5.1. Progetto esecutivo di massima
5.1.1. Descrizione
Come esposto nel capitolo 4, il presente Capitolato identifica l’infrastruttura IT complessiva da realizzare e i relativi requisiti tecnici di dettaglio sulla base di un progetto di riferimento dell’Ateneo, frutto di orientamenti strategici, di scelte tecnologiche e del contesto esistente.
Ciò nonostante, il progetto di riferimento non determina tutte le possibili scelte tecnologiche e non declina specifiche tecniche precise su tutti gli aspetti implementativi. Pertanto, per poter formulare una proposta tecnica relativa alla fornitura in oggetto, sarà onere del Fornitore definire e presentare, in sede di Offerta Tecnica, un proprio progetto esecutivo di massima, che, nel rispetto del progetto di riferimento e dei requisiti tecnici, illustri nella sostanza i principi base di progettazione adottati, gli orientamenti tecnologici integrativi seguiti, gli elementi specifici e distintivi dei prodotti selezionati ed offerti e la declinazione data ad alcune questioni tecniche solo circonstanziate nel Capitolato.
Il risultato di tale progettazione sarà oggetto di valutazione tecnica, come specificato nei paragrafi seguenti.
5.1.2. Requisiti
Codice | Categoria | Descrizione |
Generale | Il progetto esecutivo di massima redatto dal Fornitore deve illustrare la soluzione tecnica selezionata per la realizzazione dell’infrastruttura IT oggetto della fornitura, dando evidenza, ad integrazione di quanto già esplicitamente richiesto dall’Ateneo, delle scelte tecnologiche adottate e delle caratteristiche tecniche complessive (soprattutto quando costituiscono fattori premianti) dei prodotti selezionati (da intendersi chiaramente coerenti con le caratteristiche di dettaglio di ogni singolo elemento delle fornitura). In particolare, il progetto dovrà illustrare l’offerta del Fornitore rispetto ai seguenti aspetti: • modalità di distribuzione dei dati sul backbone interno ai data center, con riferimento soprattutto alla velocità delle diverse tratte di interconnessione, |
Codice | Categoria | Descrizione |
sia di tipo Ethernet che di tipo FC; • modalità di distribuzione dei dati fra gli switch centrali (ossia lo Switch Data Center Ethernet e lo Switch FC) e i sistemi Blade Server / Chassis, con riferimento soprattutto a: o tipologia, tecnologia e topologia del/dei network di interconnessione e dei relativi apparati; o velocità delle diverse tratte di interconnessione; o eventuale convergenze fra network di tipo FC e di tipo Ethernet; • organizzazione e caratteristiche della parte di infrastruttura destinata ai servizi di data storage, con riferimento soprattutto a: o ruolo e funzioni delle diverse componenti previste; o tipologia di configurazione prevista e relativi livelli di ridondanza e di capacità di recovery; • modalità di realizzazione del paradigma SDDC ed in particolare delle sue componenti SMC, SDS e SDN, evidenziando il grado di accoppiamento fra tali componenti SW e le rispettive risorse del mondo fisico fornite; • layout frontale di riferimento previsto per tutti i rack di cui è previsto l'impiego nel progetto di riferimento, dando evidenza degli effettivi ingombri dei materiali oggetto della fornitura; • tecnologie e schemi (di massima) di cablaggio della rete dati dei data center |
5.1.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di descrivere il progetto esecutivo di massima proposto per l’infrastruttura IT da realizzare, nel rispetto del requisito GN-GN-01/GEN-01, al fine di consentire la valutazione tecnica della bontà e congruità della soluzione proposta.
In particolare saranno oggetto di valutazione i parametri indicati nella scheda seguente.
Criterio | Descrizione breve | Requisiti interessati | |
VT-01 | Progetto esecutivo di massima | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
20,0 | Discrezionale con soglia | 6,0 | |
Note sulle modalità di valutazione | |||
Rispetto al progetto esecutivo di massima presentato, saranno oggetto di valutazione: • la rispondenza della soluzione con gli obiettivi e le esigenze complessive dell’Ateneo, in particolare attraverso il pieno rispetto dei vincoli di contesto indicati nel Capitolato; • la coerenza complessiva della soluzione, nell’integrazione dei diversi elementi richiesti e nelle scelte tecnologiche intraprese; • la chiarezza ed efficacia di esposizione delle caratteristiche tecniche della soluzione, in particolare in riferimento agli aspetti evidenziati nel requisito interessato; | |||
5.2. Hardware
Nella presente sezione del documento vengono dettagliati gli elementi della fornitura che rappresentano beni di tipo hardware, sia del dominio computing che storage e network.
Il paragrafo 5.2.1 presenta alcuni requisiti generali (e connessi criteri di valutazione tecnica) comuni a tutti i beni HW richiesti al Fornitore, mentre nei paragrafi successivi vengono illustrate le caratteristiche delle singole apparecchiature previste.
Codice | Categoria | Descrizione |
Generale | Ogni risorsa HW oggetto della fornitura deve essere di tipo rack-mounted, ossia installabile (come oggetto a sé stante o parte di componenti aggregati) all'interno dei rack previsti dal progetto di riferimento, di marca APC Schneider Electric modello Netshelter SX (codice prodotto AR3300), equipaggiati con fino a 6 PDU (Power Distribution Unit) della medesima marca (codice prodotto AP7553). Per maggiori informazioni si rimanda alla documentazione ufficiale di prodotto disponibile on-line all’indirizzo xxx.xxx.xxx | |
Generale | La fornitura deve comprendere la cavetteria, le slitte e tutti i materiali necessari per il collegamento (sia alla rete dati che alla rete di alimentazione elettrica) e per l’installazione, all'interno dei rack previsti dal progetto di riferimento, di ogni risorsa HW oggetto dell’appalto (come oggetto a sé stante o parte di componenti aggregati), anche se non esplicitamente indicati in sede di Offerta Tecnica | |
Generale | Tutte le componenti SW integrate nelle risorse HW oggetto della fornitura devono essere fornite all’ultima release stabile, con licenza perpetua, ove prevista; inoltre, laddove la politica di licensing sia dipendente da fattori dimensionali (es. numero di CPU/core, capacità in GB, ecc.) la fornitura deve includere tutte le licenze necessarie a garantirne il pieno utilizzo da parte dell’Ateneo sull’intera infrastruttura effettivamente offerta | |
Generale | Per ogni singolo elemento oggetto della fornitura / tipologia di risorsa HW, devono essere forniti apparati identici per marca, modello, dotazioni e configurazioni, indipendentemente dalla numerosità di unità fornite | |
Generale | Tutte le risorse HW e relativi accessori offerti dal Fornitore devono essere beni esistenti e disponibili sul mercato al momento della presentazione dell’Offerta Tecnica e devono essere fornite già assemblate, nuove di fabbrica e costruite utilizzando parti nuove | |
Tecnologia | Ogni risorsa HW oggetto della fornitura deve prevedere (come oggetto a sé stante o parte di componenti aggregati) un sistema di dissipazione del calore basato su flussi d'aria nella direzione fronte – retro | |
Certificazioni | Tutte le risorse HW e relativi accessori forniti dal Fornitore devono essere realizzate e messe in opera impiegando le più recenti tecnologie costruttive e impiantistiche e devono essere conformi alla normativa vigente che regolamenta la loro produzione, commercializzazione ed utilizzo. Il Fornitore deve garantire la conformità delle apparecchiature alle normative CEI (Comitato Elettrico Italiano) o ad altre disposizioni internazionali riconosciute e, in generale, alle vigenti norme legislative, regolamentari e tecniche disciplinanti i componenti e le modalità di impiego delle apparecchiature medesime ai fini della sicurezza degli utilizzatori. Tutte le componenti devono essere marchiate CE, fabbricate ed assemblate da primarie società certificate UNI EN ISO 9001 e 14001 in conformità con la vigente normativa in materia e sulla base delle norme internazionali di riferimento. Deve essere rilasciata (in fase esecutiva) apposita certificazione con riferimento alle direttive UE sullo smaltimento delle apparecchiature elettriche ed elettroniche usate (normativa RAEE – WEEE, 2012/19/UE) e sulla riduzione delle sostanze pericolose (normativa RoHS, 2002/95/EC); il Fornitore deve in particolare documentare la presenza eventuale di sostanze novice o cancerogene | |
Affidabilità | Ogni singola risorsa HW fornita deve essere costruita secondo un'architettura ridondata, che non presenti single point of failure per le funzionalità chiave per il suo funzionamento, almeno considerando (ove presenti/applicabili): l'alimentazione elettrica interna (in configurazione almeno N+N), le componenti di elaborazione, le componenti di comunicazione digitale con l'esterno, le componenti di dissipazione del calore, le componenti di management (ove presenti in hardware) | |
HW-GN-01/AFF-02 | Affidabilità | All’interno di ogni singola risorsa HW fornita, le componenti ridondate devono, ove tecnicamente possibile, essere di tipo hot swappable |
Codice | Categoria | Descrizione |
Amministrazione | ||
HW-GN-01/AMM-02 | Amministrazione | Ogni console di amministrazione, di cui al requisito HW-GN-01/AMM-01, deve poter essere accessibile tramite interfaccia web e connessioni SSH |
HW-GN-01/AMM-03 | Amministrazione | Ogni console di amministrazione, di cui al requisito HW-GN-01/AMM-01, deve poter attivare procedure di patch management, in grado di acquisire autonomamente dal sito del produttore le patch applicabili, per ogni componente firmware gestita |
HW-GN-01/MON-01 | Monitoraggio | Ogni console di amministrazione, di cui al requisito HW-GN-01/AMM-01, deve fornire funzioni di monitoraggio dei principali parametri di esercizio, fra cui in particolare (laddove applicabili): la velocità delle ventole, la temperatura delle CPU, i consumi elettrici. Per ogni parametro deve essere preconfigurata o impostabile una soglia di attenzione, superata la quale il sistema deve generare un avviso di allerta, verso punti di contatto configurabili |
HW-GN-01/PRT-01 | Protocolli | Ogni console di amministrazione, di cui al requisito HW-GN-01/AMM-01, deve supportare il protocollo SNMP |
HW-GN-01/SIC-01 | Sicurezza | Ogni console di amministrazione, di cui al requisito HW-GN-01/AMM-01, deve poter essere accessibile solo previa autenticazione, anche configurabile rispetto ad una fonte LDAP o Microsoft Active Directory esterna |
5.2.2. HW-CP-01 – Blade Server
5.2.2.1. Descrizione
Ogni Blade Server rappresenta un singolo apparato HW di computing, conteggiato come singola unità, da installarsi all’interno di un Blade Chassis (rif. §5.2.3) per essere poi interconnesso con l’infrastruttura complessiva.
Gli elementi maggiormente caratteristici per identificare il profilo di apparato richiesto dall’Ateneo, attraverso la specificazione dei requisiti (tecnologici, dimensionali, prestazionali, ecc.) di cui al paragrafo seguente, sono:
• i processori di calcolo – CPU,
• i moduli RAM,
• le interfacce di rete,
• le schede di espansione.
In particolare, relativamente alla CPU, è opportuno ricordare il vincolo dell’impiego della tecnologia Intel dato dal contesto esistente (rif. §2.4). Inoltre, per le CPU una grandezza importante è rappresentata dalla potenza di calcolo. Date le possibili diverse modalità per interpretare e misurare tale grandezza, il Centro Infosapienza ha deciso di ricorrere a benchmark standard di comparazione fra prodotti, regolamentati da organismi riconosciuti a livello mondiale: in particolare nella fattispecie si intende far riferimento al benchmark CINT2006 Rates definito dall’organismo Standard Performance Evaluation Corporation (SPEC); per maggiori informazioni si rimanda al sito Internet ufficale dell’organizzazione: xxxx://xxx.xxxx.xxx. L’Ateneo considera un fattore premiante la fornitura di CPU con risultati di benchmark superiori ai requisiti minimi richiesti, come indicato nel sotto-paragrafo a seguire relativo ai criteri di valutazione tecnica. E’ opportuno rilevare che necessariamente i valori di benchmark offerti devono essere disponibili in formato ufficiale (sul summenzionato sito Internet) al momento della presentazione dell’Offerta Tecnica.
Relativamente alle interfacce di rete, è assolutamente necessario che ogni Blade Server possa connettersi, in maniera ridondata, sia al network di tipo Ethernet che al network di tipo FC previsti dalla soluzione
complessiva; tuttavia le possibili scelte implementative possono variare in base alla tecnologia adottata ed in particolare sulla convergenza dei protocolli. Da parte del Fornitore è infatti possibile:
• fornire interfacce di rete specifiche per i singoli protocolli, quindi sia interfacce di rete Ethernet, indicate come NIC, che interfacce per FC, indicate come HBA;
• fornire interfacce di rete convergenti (rif. §3.1.1), indicate come Converged-NIC (C-NIC).
Infine, l’Ateneo considera come ulteriori fattori premianti la fornitura di un numero di unità Blade Server maggiore rispetto alla quantità minima richiesta o, analogamente, la fornitura di RAM con capacità migliorativa.
5.2.2.2. Requisiti
Codice | Categoria | Descrizione |
Generale | Nell'ambito dell'appalto è richiesta la fornitura di almeno 26 unità Blade Server. In ogni caso il numero complessivo di Blade Server forniti deve essere pari, da distribuirsi equamente sui due data center | |
HW-CP-01/TEC-01 | Tecnologia | Ogni Blade Server deve essere equipaggiato con CPU di tecnologia Intel |
HW-CP-01/TEC-02 | Tecnologia | Ogni Blade Server deve essere equipaggiato con RAM di tipo RDIMM con ECC |
HW-CP-01/TEC-03 | Tecnologia | Ogni Blade Server deve garantire il boot da SAN |
HW-CP-01/INT-01 | Interfacce | Ogni Blade Server deve essere equipaggiato con interfacce di rete sia di tipo Ethernet che FC. Sono possibili implementazioni separate, ossia NIC più HBA, o implementazioni convergenti, C-NIC |
HW-CP-01/INT-02 | Interfacce | Ogni interfaccia di rete di tipo Ethernet (i.e. NIC o C-NIC) deve poter essere partizionabile in almeno 4 interfacce virtuali con banda singolarmente assegnata e configurabile |
HW-CP-01/CAP-01 | Capacità | Ogni Blade Server deve essere equipaggiato con 2 socket e 2 CPU installate |
Capacità | Ogni Blade Server deve essere equipaggiato con RAM pari almeno a 192 GB | |
HW-CP-01/CAP-03 | Capacità | Tutti i canali (memory channels) di ogni CPU di ogni Blade Server fornito devono essere equipaggiati con la stessa quantità di RAM |
HW-CP-01/CAP-04 | Capacità | Ogni Blade Server deve essere equipaggiato con almeno 2 interfacce di rete di tipo Ethernet (i.e. NIC o C-NIC) e almeno 2 interfacce di rete di tipo FC (i.e. HBA o C-NIC). In caso vengano fornite C-NIC, il numero complessivo per ogni Blade Server può essere pari a 2 unità o superiore |
HW-CP-01/ESP-01 | Espandibilità | Ogni Blade Server deve essere dotato di un numero di slot disponibili per banchi RAM almeno pari a 16 |
HW-CP-01/ESP-02 | Espandibilità | Ogni Blade Server deve essere dotato di almeno 2 alloggiamenti disponibili per hard disk SAS di tipo hot swappable |
Prestazioni | Il Blade Server con le (due) CPU fornite deve garantire un valore di benchmark SPEC CINT2006 Rate almeno pari a 1180 (valore base) e un rapporto SPEC CINT2006 Rate (valore base) per core almeno pari a 42. Il valori dichiarati relativi al modello offerto devono essere disponibili sul sito xxxx://xxx.xxxx.xxx al momento della presentazione dell'Offerta Tecnica | |
Prestazioni | Ogni interfaccia di rete di tipo Ethernet (i.e. NIC o C-NIC) di ogni Blade Server fornito deve garantire una velocità di almeno 10 Gb/s in entrambe le direzioni | |
Prestazioni | Ogni interfaccia di rete di tipo FC (i.e. HBA o C-NIC) di ogni Blade Server fornito deve garantire una velocità di almeno 8 Gb/s |
5.2.2.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare saranno oggetto di valutazione alcuni fattori migliorativi, secondo i criteri illustrati nelle schede seguenti.
Criterio | Descrizione breve | Requisiti interessati | |
VT-02 | Numero di unità Blade Server | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
12,0 | Tabellare a livelli | Non applicabile | |
Note sulle modalità di valutazione | |||
Per una valutazione positiva del criterio premiante, il numero complessivo di unità Blade Server fornite deve essere superiore al minimo richiesto. Verranno assegnati i seguenti punti in funzione del numero complessivo di unità offerte: • 6 punti in caso di 28 unità fornite, • 9 punti in caso di 30 unità fornite, • 12 punti in caso di 32 unità fornite | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-03 | RAM per Blade Server | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
12,0 | Tabellare a livelli | Non applicabile | |
Note sulle modalità di valutazione | |||
Per una valutazione positiva del criterio premiante, ogni Blade Server offerto deve essere equipaggiato con RAM di capacità superiore al minimo richiesto. Verranno assegnati i seguenti punti in funzione della capacità effettiva offerta: • 6 punti per capacità pari almeno a 256 GB, • 12 punti per capacità pari almeno a 384 GB | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-04 | Prestazione delle CPU | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
12,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
della presentazione dell'Offerta Tecnica | |||
Il componente in oggetto è altresì interessato dal criterio di valutazione VT-16, al quale si rimanda (§5.2.9.3) per ulteriori dettagli.
5.2.3. HW-CP-02 – Blade Chassis
5.2.3.1. Descrizione
Ogni Blade Chassis rappresenta un singolo apparato HW di computing, conteggiato come singola unità, da installarsi all’interno di un rack di computing (rif. §4.1) per essere poi interconnesso con l’infrastruttura complessiva. All’interno di ogni Blade Chassis vengono alloggiati uno o più Blade Server (rif. §5.2.2).
Con riferimento al framework di gestione software-based (rif. §4.3), di seguito si imputano al Blade Chassis tutte le funzionalità relative alla componente Software-Managed Computing (si veda definizione al paragrafo 3.1.1), in grado di esporre quindi funzionalità di gestione avanzate programmabili delle risorse di computing, sia afferibili al Blade Chassis stesso che ai Blade Server alloggiati; la componente SMC è da intendersi
come una versione altamente evoluta della console di amministrazione già richiesta dal requisito HW-GN-01/AMM-01 (rif. §5.2.1). Ad ogni modo, in base alle tecnologie ed alle soluzioni tecniche proposte dal Fornitore, la componente SMC può essere realizzata anche al di fuori del Blade Chassis fisico, sia attraverso altre componenti HW che con altri strumenti SW, purché chiaramente vengano rispettati tutti i requisiti tecnici espressi dall’Ateneo nel paragrafo seguente; in tali condizioni, il Fornitore è comunque obbligato, in sede di Offerta Tecnica, ad illustrare adeguatamente la propria soluzione nell’ambito del progetto esecutivo di massima (rif. §5.1). Rispetto all’ampiezza ed alla rilevanza delle funzionalità esposte dalla componente SMC, e più in generale del grado di integrazione con l’OA Engine, l’Ateneo considera un fattore significativamente premiante la fornitura di una soluzione complessiva che offra un’orchestrabilità di elevato valore tecnico e di ampia flessibilità e varietà di impiego; si rimanda al paragrafo 5.3.2 per maggiori dettagli.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura, rispetto ai quali l’Ateneo considera fattori premianti una migliore efficienza energetica certificata degli alimentatori interni e funzionalità avanzate di programmabilità per i casi di failure dei Blade Server.
5.2.3.2. Requisiti
Codice | Categoria | Descrizione |
HW-CP-02/GEN-01 | Generale | Nell'ambito dell'appalto è richiesta la fornitura di almeno 4 unità Blade Chassis. Il Fornitore deve comunque fornire un numero di unità Blade Chassis tale che, a seguito dell’installazione di tutti i Blade Server effettivamente forniti, ogni Blade Chassis preservi il 20% di blade bay libere, rispetto al totale di blade bay a disposizione (sul singolo Chassis). In ogni caso il numero complessivo di unità Blade Chassis fornite deve essere pari, da distribuirsi equamente sui due data center |
Green Computing | Ogni Blade Chassis deve essere equipaggiato con alimentatori certificati secondo lo standard 80Plus, verificabile sul sito dell’organismo certificatore (xxxx://xxx.xxxxxxxxxxxxxxxxx.xxx) al momento della presentazione dell'Offerta Tecnica | |
HW-CP-02/AFF-01 | Affidabilità | All'interno del Blade Chassis, i Blade Server alloggiati devono essere di tipo hot swappable |
HW-CP-02/AFF-02 | Affidabilità | La componente SMC deve garantire il ripristino automatico della configurazione impostata, a seguito di disalimentazione elettrica anche non programmata |
HW-CP-02/AMM-01 | Amministrazione | La componente SMC deve consentire la raggiungibilità, tramite web browser, delle console remote di tutti i Blade Server installabili nel Blade Chassis, anche contemporaneamente |
HW-CP-02/AMM-02 | Amministrazione | La componente SMC deve consentire l'esposizione da remoto di un drive o di un file-immagine equivalente, verso ogni Blade Server installabile nel Blade Chassis |
Programmabilità | La componente SMC deve esporre, attraverso command line e/o API, le principali funzioni di gestione del Blade Chassis, fra le quali almeno l'accensione e lo spegnimento dei singoli Blade Server installabili |
5.2.3.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare saranno oggetto di valutazione alcuni fattori migliorativi, secondo i criteri illustrati nelle schede seguenti.
Criterio | Descrizione breve | Requisiti interessati | |
VT-05 | Certificazione 80Plus | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
4,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), ogni Blade Chassis deve essere equipaggiato con alimentatori certificati secondo lo standard 80Plus con un livello assegnato pari a Platinum o superiore, verificabile sul sito dell’organismo certificatore (xxxx://xxx.xxxxxxxxxxxxxxxxx.xxx) al momento della presentazione dell'Offerta Tecnica | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-06 | Fault Tolerance per Blade Server | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
8,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), la componente SMC deve permettere di innescare, anche in maniera programmabile, un processo di sostituzione di un Blade Server guasto con un altro Blade Server in modalità hot-spare, trasferendo al nuovo hardware sia l'indirizzo MAC sia WWN (World Wide Name) | |||
5.2.4. HW-ST-01 – Storage Area Network
Ogni Storage Area Network rappresenta un singolo apparato HW di storage, conteggiato come singola unità, da installarsi all’interno di un rack di storage (rif. §4.1) per essere poi interconnesso con l’infrastruttura complessiva.
Le SAN richieste dal Centro Infosapienza devono necessariamente garantire alcune funzionalità ormai consolidate nel panorama tecnologico delle soluzioni di data storage e ritenute strategiche per l’innovazione tecnologica e l’efficienza di esercizio che il Centro persegue nella nuova infrastruttura IT:
• automated disk tiering, ossia la capacità del sistema di gestire in modo dinamico l’allocazione dei dati tra risorse / dischi di tipologie diverse (Tier), da quelli capacitivi a basse prestazioni (es. NL-SAS) a quelli ad elevate prestazioni (es. SSD) ma dalla capacità limitata, installate all’interno della medesima unità;
• thin provisioning, per separare logicamente le quantità di disco presentate ai sistemi dall’hardware effettivamente impegnato, andando dinamicamente ad aggiungere le risorse necessarie man mano che vengono consumate.
In aggiunta a tali caratteristiche e per le stesse motivazioni, l’Ateneo ritiene un fattore premiante l’effettiva disponibilità, nell’ambito della fornitura, di ulteriori funzionalità:
• compressione dei dati, ossia la capacità di memorizzare le informazioni usando codifiche più efficienti (rispetto alle originali) in termini di spazio occupato;
• deduplica dei dati, ossia la capacità di implementare soluzioni di compressione evolute in cui ampie parti di informazioni duplicate vengono eliminate, al fine di avere un’occupazione di spazio minimale e singola per ogni dato (si parla anche infatti di single-instance data storage).
Si è inoltre prima menzionata l’assoluta necessità che ogni SAN si connetta, in maniera ridondata, allo Switch FC tramite interfacce di rete di tipo FC, che si richiede siano interfacce specifiche e non convergenti (rif. §3.1.1). A queste si aggiunge la necessità di interfacce di rete di tipo Ethernet per la connessione alla rete di management (rif. §4.1).
Infine, si evidenzia che riguardo la componente Software-Defined Storage (si veda definizione al paragrafo 3.1.1) prevista dal framework di gestione software-based (rif. §4.3), le relative funzionalità verranno imputate alla Piattaforma di Virtualizzazione dello Storage, come descritto nel paragrafo 5.2.5 a cui si rimanda.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura, rispetto ai quali l’Ateneo considera ulteriori fattori premianti una maggiore capacità offerta per la memoria di Tier 2 e di Tier 3 e la memora cache.
5.2.4.2. Requisiti
Codice | Categoria | Descrizione |
HW-ST-01/GEN-01 | Generale | Nell'ambito dell'appalto è richiesta la fornitura di 2 unità SAN, da distribuirsi equamente sui due data center |
HW-ST-01/TEC-01 | Tecnologia | Ogni unità deve implementare la funzionalità di automatic disk tiering, con la capacità di gestire almeno 3 Tier con le seguenti tecnologie di dischi: SSD, SAS, NL-SAS. Il tiering automatico deve essere eseguito almeno una volta al giorno |
Tecnologia | Ogni unità deve implementare la funzionalità di thin provisioning, in maniera integrata sull'unità e abilitata almeno sul volume di dati effettivamente fornito | |
HW-ST-01/INT-01 | Interfacce | Ogni unità deve essere equipaggiata con interfacce di rete di tipo FC specifiche |
HW-ST-01/INT-02 | Interfacce | Ogni unità deve essere equipaggiata con interfacce di rete di tipo Ethernet per la connessione alla rete di management |
HW-ST-01/AFF-01 | Affidabilità | All'interno della SAN, i dischi alloggiati devono essere di tipo hot swappable |
HW-ST-01/AFF-02 | Affidabilità | Ogni unità deve garantire l'assegnazione automatica di un disco hot spare a seguito di un failure di un disco in esercizio |
HW-ST-01/AFF-03 | Affidabilità | Ogni unità deve garantire il salvataggio automatico del contenuto della memoria cache a fronte di disalimentazione elettrica anche non programmata |
HW-ST-01/AFF-04 | Affidabilità | Ogni unità deve possedere una certificazione di affidabilità rilasciata dal produttore pari al 99,999% |
HW-ST-01/AFF-05 | Affidabilità | La console di amministrazione, di cui al requisito HW-GN-01/AMM-01, deve garantire il ripristino automatico della configurazione impostata, a seguito di disalimentazione elettrica anche non programmata |
HW-ST-01/CAP-01 | Capacità | Ogni unità deve essere equipaggiata con dischi SSD – o equivalenti purché integrati nell'unità – (Tier 1) configurati in RAID 5 (4+1) con capacità utile complessiva pari almeno a 8 TB |
Capacità | Ogni unità deve essere equipaggiata con dischi SAS (Tier 2) configurati in RAID 5 (8+1) con capacità utile complessiva pari almeno a 30 TB | |
Capacità | Ogni unità deve essere equipaggiata con dischi NL-SAS (Tier 3) configurati in RAID 6 (8+2) con capacità utile complessiva pari almeno a 60 TB | |
Capacità | Ogni unità deve essere equipaggiata con una memoria cache con capacità pari almeno a 48 GB | |
Capacità | Ogni unità deve essere equipaggiata con almeno 8 interfacce di rete di tipo FC specifiche | |
HW-ST-01/CAP-06 | Capacità | Ogni unità deve essere equipaggiata con almeno 2 interfacce di rete di tipo Ethernet per la connessione alla rete di management |
HW-ST-01/ESP-01 | Espandibilità | Ogni unità deve essere espandibile fino almeno a 500 alloggiamenti per dischi, fra tutti i Tier complessivamente |
HW-ST-01/AMM-01 | Amministrazione | La console di amministrazione, di cui al requisito HW-GN-01/AMM-01, deve fornire le seguenti funzioni, abilitate almeno sul volume di dati effettivamente fornito: • clonazione di volumi, • creazione di snapshot di volumi |
HW-ST-01/PRG-01 | Programmabilità | La console di amministrazione, di cui al requisito HW-GN-01/AMM-01, deve esporre le principali funzioni di gestione della SAN, attraverso command line e/o API |
HW-ST-01/PRE-01 | Prestazioni | Ogni disco SAS fornito deve garantire una velocità di rotazione pari almeno a 10.000 rpm |
Codice | Categoria | Descrizione |
HW-ST-01/PRE-02 | Prestazioni | Ogni disco NL-SAS fornito deve garantire una velocità di rotazione pari almeno a 7.200 rpm |
Prestazioni | Ogni interfaccia di rete di tipo FC fornita deve garantire una velocità di almeno 8 Gb/s | |
HW-ST-01/PRE-04 | Prestazioni | Ogni interfaccia di rete di tipo Ethernet fornita per la connessione alla rete di management deve garantire una velocità di almeno 1 Gb/s |
5.2.4.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare saranno oggetto di valutazione alcuni fattori migliorativi, secondo i criteri illustrati nelle schede seguenti.
Criterio | Descrizione breve | Requisiti interessati | |
VT-07 | Funzionalità di compressione dei dati implementata | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
3,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), ogni SAN deve implementare la funzionalità di compressione dei dati, in maniera integrata sull'unità e abilitata almeno sul 10% del volume di dati effettivamente fornito | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-08 | Funzionalità di deduplica dei dati implementata | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
3,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), ogni SAN deve implementare la funzionalità di deduplica dei dati, in maniera integrata sull'unità e abilitata almeno sul 10% del volume di dati effettivamente fornito | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-09 | Capacità dischi SAS | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
8,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), ogni SAN deve essere equipaggiata con dischi SAS (Tier 2) configurati in RAID 5 (8+1) con capacità utile complessiva pari almeno a 40 TB | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-10 | Capacità dischi NL-SAS | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
8,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), ogni SAN deve essere equipaggiata con dischi NL-SAS (Tier 3) configurati in RAID 6 (8+2) con capacità utile complessiva pari almeno a 80 TB | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-11 | Capacità memoria cache | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
10,0 | Tabellare a livelli | Non applicabile | |
Note sulle modalità di valutazione | |||
Per una valutazione positiva del criterio premiante, ogni SAN offerta deve essere equipaggiata con una memoria cache con capacità superiore al minimo richiesto. Verranno assegnati i seguenti punti in funzione della capacità effettiva offerta: • 3 punti per capacità pari almeno a 64 GB, • 6 punti per capacità pari almeno a 128 GB, • 8 punti per capacità pari almeno a 256 GB, • 10 punti per capacità pari almeno a 512 GB | |||
Il componente in oggetto è altresì interessato dal criterio di valutazione VT-16, al quale si rimanda (§5.2.9.3) per ulteriori dettagli.
5.2.5. HW-ST-02 – Piattaforma di Virtualizzazione dello Storage
5.2.5.1. Descrizione
La Piattaforma di Virtualizzazione dello Storage è costituita da due apparati HW identici, ciascuno conteggiato come singola unità, distribuiti sui due data center; ogni unità va installata all’interno di un rack di storage (rif. §4.1), per essere poi interconnessa con l’infrastruttura complessiva.
La soluzione offerta dal Fornitore, in base alle tecnologie ed ai prodotti selezionati, può prevedere che le funzionalità richieste dalla singola unità siano fornite da:
• un appliance (ossia un apparato HW specializzato) dedicato;
• un sistema integrato di componenti HW e SW, dedicato, in cui l’integrazione viene garantita dal Fornitore;
• la medesima SAN già oggetto di fornitura (rif. §5.2.4).
Viene usato il termine piattaforma per evidenziare come entrambe le unità previste in fornitura, configurate in cluster fra loro, siano in grado di offrire dei servizi di data storage unificati, ossia una gestione dei volumi distribuita su più SAN – al fine di garantire maggiori prestazioni, affidabilità e continuità – in maniera trasparente verso l’utilizzatore dei servizi, che vede un singolo pool complessivo di storage. A tale scopo la piattaforma deve implementare due funzionalità chiave:
• la virtualizzazione, ossia la capacità di astrarre la definizione di volume di dati servito, per separarlo dalla sua implementazione fisica su più apparati, la cui gestione viene nascosta ai servizi utilizzatori;
• la federazione, ossia la capacità di gestire in maniera unitaria differenti apparati fisici, anche di marca e tipologia differente.
Come indicato nel progetto di riferimento (rif. §4.1), il cluster può configurarsi di base secondo una configurazione di tipo active / passive, ossia una SAN in un sito eroga i servizi di data storage, mentre l’altra SAN nel secondo sito si occupa solo di mantenere una copia allineata dei dati. Tuttavia, nell’ottica di poter riuscire ad erogare i servizi in maniera bilanciata fra i due siti, l’Ateneo considera un fattore significativamente premiante l’implementazione di una configurazione di tipo active / active.
Il progetto di riferimento prevede inoltre che l’accesso a tutte le SAN (sia presenti che future) sia sempre mediato dalla Piattaforma di Virtualizzazione dello Storage: per tale motivo si richiede che la piattaforma sia abilitata a gestire tutto lo spazio utile effettivamente presente nelle SAN oggetto di fornitura più un’ulteriore quota di 50 TB per espansioni future, anche verso le SAN già esistenti.
Allargando ulteriormente l’orizzonte, la Piattaforma di Virtualizzazione potrà rappresentare in futuro la soluzione e lo strumento per estendere la nuova infrastruttura IT verso nuove tipologie di risorse storage,
che secondo gli orientamenti attuali si può prevedere saranno orientate verso il big data e/o verso il Cloud Computing ibrido (quindi includendo risorse di Cloud Computing pubblico), ossia privilegiando fortemente la capacità, la scalabilità e l’economicità, piuttosto che la disponibilità nativa di funzioni avanzate, quali quelle già introdotte e richieste per le SAN in ambito alla fornitura (rif. §5.2.4.1): automated disk tiering, thin provisioning, compressione dei dati, deduplica dei dati. In quest’ottica, il Centro Infosapienza considera un fattore premiante la capacità della Piattaforma di Virtualizzazione dello Storage di implementare tali funzionalità internamente, direttamente al livello dello storage virtualizzato, indipendentemente (ma non escludendolo) dalla loro disponibilità nativa sulle SAN (presenti o future) gestite dalla piattaforma stessa.
Con riferimento al framework di gestione software-based (rif. §4.3), di seguito si imputano alla Piattaforma di Virtualizzazione dello Storage tutte le funzionalità relative alla componente Software-Defined Storage (si veda definizione al paragrafo 3.1.1), in grado di esporre quindi funzionalità di gestione avanzate programmabili delle risorse di data storage; la componente SDS può anche coincidere con la console di amministrazione, di cui al requisito HW-GN-01/AMM-01. Ad ogni modo, in base alle tecnologie ed alle soluzioni tecniche proposte dal Fornitore, la componente SDS può essere realizzata anche al di fuori della Piattaforma di Virtualizzazione dello Storage fisica, sia attraverso altre componenti HW che con altri strumenti SW, purché chiaramente vengano rispettati tutti i requisiti tecnici espressi dall’Ateneo nel paragrafo seguente; in tali condizioni, il Fornitore è comunque obbligato, in sede di Offerta Tecnica, ad illustrare adeguatamente la propria soluzione nell’ambito del progetto esecutivo di massima (rif. §5.1). Rispetto all’ampiezza ed alla rilevanza delle funzionalità esposte dalla componente SDS, e più in generale del grado di integrazione con l’OA Engine, l’Ateneo considera un fattore significativamente premiante la fornitura di una soluzione complessiva che offra un’orchestrabilità di elevato valore tecnico e di ampia flessibilità e varietà di impiego; si rimanda al paragrafo 5.3.2 per maggiori dettagli.
Funzionalmente, ai fini della presente descrizione della piattaforma, si assume che ogni unità distingua interfacce di rete / flussi dati di back-end (da e verso le SAN) da interfacce / flussi dati di front-end (da e verso i sistemi server utilizzatori). Nei requisiti tecnici si utilizza tale distinzione per differenziare la capacità (minima) di interfacce di rete richieste per i due tipi di flussi; è tuttavia ammissibile, in funzione della soluzione proposta dal Fornitore, che negli apparati offerti tale distinzione non sia contemplata: in tal caso, le interfacce di rete fornite possono implementare entrambi i flussi contemporaneamente.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura ed i criteri di valutazione previsti.
5.2.5.2. Requisiti
Codice | Categoria | Descrizione |
HW-ST-02/GEN-01 | Generale | Nell'ambito dell'appalto è richiesta la fornitura di 2 unità costitutive della Piattaforma di Virtualizzazione dello Storage, da distribuirsi equamente sui due data center |
Tecnologia | La piattaforma deve esporre nei confronti dei sistemi utilizzatori LUN virtuali, ciascuna delle quali sia vista dai server come un singolo volume logico, indipendentemente dalla distribuzione fisica dei dati sui due siti e dal livello di ridondanza | |
HW-ST-02/TEC-02 | Tecnologia | La soluzione deve permettere la movimentazione dei volumi virtuali tra SAN eterogenee, senza interruzione del servizio nei confronti dei sistemi utilizzatori |
HW-ST-02/TEC-03 | Tecnologia | La piattaforma deve consentire l'aggiunta di nuove SAN ai pool di risorse gestite, senza interruzione del servizio nei confronti dei sistemi utilizzatori |
Codice | Categoria | Descrizione |
HW-ST-02/TEC-04 | Tecnologia | La modalità di gestione dei volumi da parte della piattaforma deve garantire che i dati, nel caso in cui la piattaforma venga rimossa dall'infrastruttura, siano fruibili anche tramite accesso diretto alle SAN sottostanti, al netto di interventi minimi di riconfigurazione |
HW-ST-02/INT-01 | Interfacce | Ogni unità deve essere equipaggiata con interfacce di rete di tipo FC specifiche |
HW-ST-02/INT-02 | Interfacce | Ogni unità deve essere equipaggiata con interfacce di rete di tipo Ethernet per la connessione alla rete di management |
HW-ST-02/AFF-01 | Affidabilità | La console di amministrazione, di cui al requisito HW-GN-01/AMM-01, deve garantire il ripristino automatico della configurazione impostata, a seguito di disalimentazione elettrica anche non programmata |
Affidabilità | La piattaforma in cluster deve garantire la replica sincrona tra i due siti in modo da supportare una situazione di Disaster Recovery a RPO = 0. E' ammissibile che tale requisito venga soddisfatto integrando anche funzionalità native delle SAN | |
HW-ST-02/AFF-03 | Affidabilità | La piattaforma in cluster deve provvedere al failover automatico fra le due unità sincronizzate, in caso di indisponibilità non programmata di uno dei due apparati |
HW-ST-02/AFF-04 | Affidabilità | La piattaforma in cluster deve provvedere al ripristino automatico della sincronia (failback) fra le due unità, nel caso in cui uno dei due apparati ritorni operativo a seguito di una indisponibilità non programmata |
Capacità | La piattaforma fornita deve essere abilitata a gestire complessivamente un volume di dati pari almeno al volume utile effettivamente gestito dalle SAN fornite, aumentato di un volume di ulteriori 50 TB riferibili a ulteriori SAN dell'Ateneo, presenti o future | |
HW-ST-02/CAP-02 | Capacità | Ogni unità deve essere equipaggiata con almeno 8 interfacce di rete di tipo FC specifiche da utilizzarsi per le connessioni di back-end e almeno 4 interfacce di rete di tipo FC specifiche da utilizzarsi per le connessioni di front-end, laddove nell’ambito della soluzione proposta dal Fornitore tali connessioni siano distinguibili. In caso contrario, ogni unità deve essere equipaggiata con almeno 8 interfacce di rete di tipo FC specifiche |
HW-ST-02/CAP-03 | Capacità | Ogni unità deve essere equipaggiata con almeno 2 interfacce di rete di tipo Ethernet per la connessione alla rete di management |
HW-ST-02/COM-01 | Compatibilità | La piattaforma deve essere in grado di operare sulla SAN IBM V7000 |
HW-ST-02/AMM-01 | Amministrazione | La componente SDS deve poter essere accessibile tramite web e connessioni SSH |
Programmabilità | La componente SDS deve esporre, attraverso command line e/o API, le principali funzioni di gestione della piattaforma e dei servizi di data storage, fra le quali almeno: • la creazione, la clonazione, il ridimensionamento e la cancellazione di volumi, • la creazione e la cancellazione di snapshot di volumi | |
Prestazioni | Ogni interfaccia di rete di tipo FC fornita deve garantire una velocità di almeno 8 Gb/s | |
HW-ST-02/PRE-02 | Prestazioni | Ogni interfaccia di rete di tipo Ethernet fornita per la connessione alla rete di management deve garantire una velocità di almeno 1 Gb/s |
HW-ST-02/SIC-01 | Sicurezza | La componente SDS deve poter essere accessibile solo previa autenticazione, anche configurabile rispetto ad una fonte LDAP o Microsoft Active Directory esterna |
5.2.5.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare saranno oggetto di valutazione alcuni fattori migliorativi, secondo i criteri illustrati nelle schede seguenti.
Criterio | Descrizione breve | Requisiti interessati | |
VT-12 | Configurazione cluster in modalità active / active | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
18,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), la piattaforma fornita deve essere configurata come un cluster in modalità active / active, in grado di garantire, oltre alla replica sincrona tra i due siti in modo da supportare una situazione di Disaster Recovery a RPO = 0, anche l'erogazione dei servizi in maniera bilanciata fra i due siti. E' ammissibile che tale requisito venga soddisfatto integrando anche funzionalità native delle SAN | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-13 | Funzionalità avanzate della piattaforma | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
6,0 | Tabellare a livelli | Non applicabile | |
Note sulle modalità di valutazione | |||
Per una valutazione positiva del criterio premiante, la piattaforma fornita deve implementare internamente alcune funzionalità avanzate di gestione dei dati direttamente a livello di storage virtualizzato, indipendentemente dalla disponibilità o meno di tali funzionalità in maniera nativa sugli apparati fisici di data storage gestiti. In ogni caso, la piattaforma può sfruttare le funzionalità native degli apparati fisici gestiti, laddove presenti. Verranno assegnati i seguenti punti in funzione delle funzionalità effettivamente implementate sulla piattaforma: • 4 punti per le funzionalità di automated disk tiering e di thin provisioning, abilitate almeno sul volume di dati effettivamente gestito dalla piattaforma nella soluzione offerta; • 6 punti per le funzionalità di automated disk tiering, thin provisioning (abilitate come al punto precedente) e inoltre di compressione o deduplica dei dati, queste ultime abilitate almeno sul 10% del volume di dati effettivamente gestito dalla piattaforma nella soluzione offerta. Per la definizione di tali funzionalità si rimanda al paragrafo 5.2.4.1 del Capitolato Tecnico | |||
Il componente in oggetto è altresì interessato dal criterio di valutazione VT-16, al quale si rimanda (§5.2.9.3) per ulteriori dettagli.
5.2.6. HW-NT-01 – Piattaforma DWDM
La Piattaforma DWDM è composta da due apparati HW identici, ciascuno conteggiato come singola unità, distribuiti sui due data center, che creano un ponte di comunicazione fra i due siti basato sull’impiego di tecnologie di trasmissione ottica avanzate, in grado di trasmettere, all’interno di un mezzo trasmissivo a fibra ottica, segnali ottici contemporanei su differenti lunghezze d’onda; ogni unità va installata all’interno di un rack del core del network (rif. §4.2), per poi essere interconnessa con l’infrastruttura complessiva.
Ogni trasmissione dei segnali ottici (su propria lunghezza d’onda) rappresenta una comunicazione a sé stante, indipendente dalle altre, e nel presente documento viene indicata come canale.
Nell’ambito del progetto di riferimento sono previsti attualmente 4 canali, da trasmettersi su entrambi i percorsi indipendenti di interconnessione dei due data center, già descritti nel paragrafo 2.4.
I 4 canali serviranno per la comunicazione fra:
• gli apparati core (router e firewall) – 1 canale (bi-direzionale);
• gli Switch DC Ethernet – 1 canale (bi-direzionale);
• gli Switch FC – 2 canali (mono-direzionali, a sensi inversi).
Viene poi richiesta la capacità di gestire un quinto canale, per usi futuri.
In Figura 11 viene schematizzato il funzionamento della Piattaforma DWDM oggetto della fornitura.
Figura 11 – Schema di funzionamento della Piattaforma DWDM
Tralasciando i dettagli della possibile architettura fisica con cui può essere costruita ogni singola unità della piattaforma, quali ad esempio chassis, moduli, circuiti e schede, si pone di seguito l’attenzione su alcune specifiche componenti concettuali, di seguito definite, rispetto alle quali nei successivi sotto-paragrafi vengono esplicitati determinati requisiti tecnici e/o criteri di valutazione:
• Interfacce di Connessione: componenti elettroniche, di cui viene corredata l’unità, necessarie per l’interfacciamento della piattaforma con le singole connessioni (i.e. cavi di rete) interne al sito, che vengono servite dalla piattaforma stessa. Nell’ambito della fornitura richiesta si considerano le seguenti Interfacce di Connessione:
o Interfacce di tipo Ethernet a 10 Gb/s o superiore;
o Interfacce di tipo FC specifiche (i.e. non di tipo convergente) a 8 Gb/s.
• Modulo di Alloggiamento delle Interfacce di Connessione: modulo di espansione dell’unità, su cui vengono alloggiate le Interfacce di Connessione. Nell’ambito della fornitura richiesta si considerano due possibili tipologie di Modulo di Alloggiamento, in base alla modalità di funzionamento:
o Modalità Transponder: il traffico dati proveniente dalle singole Interfacce di Connessione alloggiate sul modulo viene trasmesso (all’interno della piattaforma) in modalità passante;
o Modalità Muxponder: il traffico dati proveniente da una o più (anche tutte) Interfacce di Connessione alloggiate sul modulo viene tramesso (all’interno della piattaforma) in modalità aggregata su un singolo canale.
• Control Card: insieme di tutte le componenti elettroniche interne all’unità che elaborano i segnali digitali trasmessi dalle Interfacce di Connessione / Moduli di Alloggiamento e li trasferiscono da e verso l’Unità di Commutazione Ottica.
• Unità di Commutazione Ottica: componente ottica per la trasmissione dei segnali provenienti dalla Control Card sui canali ottici di collegamento fra le unità della piattaforma (e viceversa).
Come sopra indicato, il progetto di riferimento prevede l’attivazione di canali a 8 o 10 Gb/s (rispettivamente per FC ed Ethernet), tuttavia, dato il ruolo strategico sul lungo periodo della Piattaforma DWDM in vista di future probabili espansioni dei servizi IT dell’Ateneo e dei flussi di informazioni movimentate, si richiede nella fornitura che la piattaforma sia già abilitata a gestire trasmissioni inter-sito (canali) con velocità fino a 100 Gb/s. Su questa base, l’Ateneo considera un fattore premiante la fornitura integrativa delle opportune componenti (Interfacce di Connessione e/o Moduli di Alloggiamento) che realizzino tale possibilità sin dalla prima implementazione.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura e i criteri di valutazione tecnica previsti.
Codice | Categoria | Descrizione |
HW-NT-01/GEN-01 | Generale | Nell'ambito dell'appalto è richiesta la fornitura di 2 unità costitutive della Piattaforma DWDM, da distribuirsi equamente sui due data center |
HW-NT-01/TEC-01 | Tecnologia | I Moduli di Alloggiamento forniti devono poter essere configurati per funzionare sia in modalità Transponder che Muxponder |
HW-NT-01/TEC-02 | Tecnologia | Ogni Unità di Commutazione Ottica di ogni unità fornita deve poter trasmettere su fibra ottica di tipo mono-modale |
HW-NT-01/TEC-03 | Tecnologia | Ogni Unità di Commutazione Ottica fornita deve essere abilitata a trasmettere contemporaneamente trasmissioni (canali) a velocità differenti (es. un canale a 10 Gb/s insieme ad un canale a 100 Gb/s) |
HW-NT-01/TEC-04 | Tecnologia | |
HW-NT-01/PRT-01 | Protocolli | Ogni Unità di Commutazione Ottica di ogni unità fornita deve supportare i protocolli OTU, almeno nelle versioni OTU2, OTU2E e OTU4 |
HW-NT-01/AFF-01 | Affidabilità | Ogni singola unità deve essere equipaggiata con Control Card ridondate. Il traffico deve essere preservato anche in caso di failure di entrambe le Control Card per un tempo adeguato a completarne il rimpiazzo. Il rimpiazzo di una Control Card in esercizio deve essere possibile senza la necessità di preconfigurazione, ovvero la Control Card deve essere in grado di "autoapprendere" l'ultima configurazione/database in uso |
HW-NT-01/AFF-02 | Affidabilità | Ogni singola unità deve essere equipaggiata con Moduli di Alloggiamento ridondati |
HW-NT-01/AFF-03 | Affidabilità | Ogni singola unità deve essere equipaggiata con Unità di Commutazione Ottica ridondate |
Codice | Categoria | Descrizione |
Capacità | Ogni singola unità deve essere equipaggiata con Moduli di Alloggiamento in numerosità sufficiente ad alloggiare almeno (in maniera ripartita fra Moduli distinti): Le suddette coppie di Interfacce di Connessione devono essere tutte comprese nella fornitura | |
HW-NT-01/ESP-01 | Espandibilità | Ogni unità deve prevedere la possibilità di alloggiare almeno due ulteriori Moduli di Alloggiamento per possibili espansioni |
HW-NT-01/ESP-02 | Espandibilità | Ogni Modulo di Alloggiamento fornito per ogni unità prevista deve prevedere l'alloggiamento per almeno un'ulteriore Interfaccia di Connessione per possibili espansioni |
HW-NT-01/ESP-03 | Espandibilità | Tutte le componenti Moduli di Alloggiamento, Control Card e Unità di Commutazione Ottica fornite devono essere abilitate ad elaborare trasmissioni (provenienti dalle Interfacce di Connessione – sia in modalità Transponder che Muxponder) a 100 Gb/s |
HW-NT-01/COM-01 | Compatibilità | La piattaforma deve garantire la trasmissione dei flussi di sincronizzazione fra gli apparati core esistenti nei due data center, ossia i core router di marca Cisco serie Catalyst 6500 / 6800 e i firewall di marca Check Point serie 12600 |
HW-NT-01/AMM-01 | Amministrazione | La console di amministrazione deve fornire una rappresentazione sia grafica che funzionale delle interconnessioni gestite e delle singole unità e componenti della piattaforma e deve consentire di eseguire sia localmente che da remoto tutte le operazioni di configurazione del sistema, nonchè la localizzazione e il troubleshooting di problemi di trasmissione |
Prestazioni | Ogni Interfaccia di Connessione di tipo Ethernet fornita deve garantire una velocità di almeno 10 Gb/s in entrambe le direzioni | |
HW-NT-01/PRE-02 | Prestazioni | Ogni Interfaccia di Connessione di tipo FC fornita deve garantire una velocità di almeno 8 Gb/s |
HW-NT-01/PRE-03 | Prestazioni | Ogni Unità di Commutazione Ottica fornita deve essere abilitata a trasmettere su almeno 5 canali distinti |
5.2.6.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare sarà oggetto di valutazione il fattore migliorativo illustrato nella scheda seguente.
Criterio | Descrizione breve | Requisiti interessati | |
VT-14 | Espansione a 100 Gb/s | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
4,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), ogni unità offerta deve essere equipaggiata con ulteriori componenti di espansione (aggiuntivi rispetto all'equipaggiamento di base richiesto dal requisito interessato), secondo una delle due seguenti opzioni alternative: • 1 coppia di Interfacce di Connessione di tipo Ethernet a 100 Gb/s (in maniera ripartita fra due Moduli di Alloggiamento distinti fra quelli previsti di base), • 2 Moduli di Alloggiamento di tipo Muxponder, ognuno corredato di 10 Interfacce di Connessione di tipo Ethernet a 10 Gb/s ciascuna | |||
5.2.7. HW-NT-02 – Switch Data Center Ethernet
5.2.7.1. Descrizione
Ogni Switch Data Center Ethernet rappresenta un singolo apparato HW di networking, conteggiato come singola unità, da installarsi all’interno di un rack del core del network (rif. §4.2) come elemento cardine di interconnessione dell’infrastruttura complessiva. Di seguito e nei sotto-paragrafi seguenti vengono descritti i requisiti richiesti per lo Switch DC Ethernet, inteso come l’apparato su cui vengono installati moduli e porte per le connessioni di tipo Ethernet; per i requisiti relativi a quantità e caratteristiche tecniche di moduli e porte da fornire nell’ambito dell’appalto per ogni unità di Switch DC Ethernet, si rimanda al paragrafo 5.2.8.
In termini di moduli e porte installabili sull’apparato, si richiede che lo Switch DC Ethernet supporti ramificazioni del network a differenti velocità e tecnologie, da 1 Gb/s fino a 40 Gb/s; tuttavia, come previsto da progetto di riferimento (rif. §4.1), si richiede al Fornitore di implementare un network di produzione di tipo Ethernet di velocità pari ad almeno 10 Gb/s, come riscontrabile dai requisiti espressi nel paragrafo 5.2.8. Relativamente al supporto per porte con velocità di almeno 40 Gb/s (i.e. QSFP), l’Ateneo considera un fattore premiante la capacità di supportare implementazioni che sappiano ottenere tale prestazioni trasmettendo su canali composti da singole coppie di fibre ottiche, dato l’evidente beneficio apportato dalla minimizzazione del numero di fibre ottiche impiegate.
Con riferimento al framework di gestione software-based (rif. §4.3), di seguito si imputano allo Switch DC Ethernet tutte le funzionalità relative alla componente Software-Defined Networking (si veda definizione al paragrafo 3.1.1) per l’ambito Ethernet, in grado di esporre quindi funzionalità di gestione avanzate programmabili delle risorse di networking; la componente SDN può anche coincidere con la console di amministrazione, di cui al requisito HW-GN-01/AMM-01. Ad ogni modo, in base alle tecnologie ed alle soluzioni tecniche proposte dal Fornitore, la componente SDN può essere realizzata anche al di fuori dello Switch DC Ethernet fisico, sia attraverso altre componenti HW che con altri strumenti SW, purché chiaramente vengano rispettati tutti i requisiti tecnici espressi dall’Ateneo nel paragrafo seguente; in tali condizioni, il Fornitore è comunque obbligato, in sede di Offerta Tecnica, ad illustrare adeguatamente la propria soluzione nell’ambito del progetto esecutivo di massima (rif. §5.1). Rispetto all’ampiezza ed alla rilevanza delle funzionalità esposte dalla componente SDN in ambito Ethernet, e più in generale del grado di integrazione con l’OA Engine, l’Ateneo considera un fattore significativamente premiante la fornitura di una soluzione complessiva che offra un’orchestrabilità di elevato valore tecnico e di ampia flessibilità e varietà di impiego; si rimanda al paragrafo 5.3.2 per maggiori dettagli.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura ed i criteri di valutazione previsti.
Codice | Categoria | Descrizione |
HW-NT-02/GEN-01 | Generale | Nell'ambito dell'appalto è richiesta la fornitura di 4 unità, da distribuirsi equamente sui due data center |
HW-NT-02/TEC-01 | Tecnologia | Ogni unità deve rappresentare un'architettura non bloccante, ossia tutte le porte installate in massima configurazione devono poter essere utilizzate in modalità non-blocking in entrambe le direzioni |
HW-NT-02/TEC-02 | Tecnologia | Ogni unità deve implementare funzionalità di networking sia di Layer 2 (L2) sia di Layer 3 (L3), con riferimento al modello OSI, su rete di tipo Ethernet |
HW-NT-02/TEC-03 | Tecnologia | Ogni unità deve implementare funzionalità di Quality of Service (QoS), a livello di singola porta, fra cui almeno: • Ingress Policing, • Strict Priority Queue, • Monitoring della latenza |
Codice | Categoria | Descrizione |
Tecnologia | Ogni unità deve supportare moduli e porte delle seguenti tecnologie: • SFP (1 Gb/s), dei tipi 1GBase-SR (Short Range), -LR (Long Range), -ER (Extended Range) e 1000Base-T (Twinax); • SFP+ (10 Gb/s), dei tipi 10GBase-SR (Short Range), -LR (Long Range), - ER (Extended Range), -T (Twinax), -CU (rame); • QSFP (40 Gb/s), dei tipi SR4 (Short Range), LR4 (Long Range) | |
HW-NT-02/TEC-05 | Tecnologia | In ogni unità tutte le porte configurabili devono essere di tipo wirespeed |
HW-NT-02/TEC-06 | Tecnologia | |
HW-NT-02/GRN-01 | Green Computing | Ogni unità deve garantire un consumo di energia di picco non superiore a 500 W, certificato dal produttore |
HW-NT-02/PRT-01 | Protocolli | Ogni unità deve implementare almeno i seguenti protocolli di Layer 2: • VLAN, • Private VLAN, • Layer 2 switch ports and VLAN trunks, • 802.3ad, • 802.1D/S/W/AB, • Jumbo Frame Support, • Storm control (unicast, multicast and broadcast) |
HW-NT-02/PRT-02 | Protocolli | Ogni unità deve implementare almeno i seguenti protocolli di Layer 3: • Static, • RIPv2 (Routing Information Protocol), • OSPFv2/3 (Open Shortest Path First), • VRRP (Virtual Router Redundancy Protocol), • IGMP v2/3 (Internet Group Management Protocol), • IPv6 routing protocols, • BFD support (Bidirectional Forwarding Detection), • VXLAN support (Virtual eXtensible LAN) |
HW-NT-02/PRT-03 | Protocolli | Ogni unità deve implementare almeno i seguenti protocolli di monitoraggio e sicurezza: • Sampled Netflow o similari, • ACL (Access Control List), • NAT (Network Address Translation), • DHCP option 82 (Dynamic Host Configuration Protocol), • RADIUS (Remote Authentication Dial-In User Service), • TACACS+ (Terminal Access Controller Access Control System), • SNMPv1/2/3, • SSHv2, • Telnet, • AAA with RBAC (Authentication, Authorization and Accounting with Role- Based Access Control), • NTP (Network Time Protocol), • Syslog |
HW-NT-02/AFF-01 | Affidabilità | Le due unità presenti in ciascun data center devono essere configurate come una coppia in alta affidabilità |
HW-NT-02/ESP-01 | Espandibilità | Ogni unità deve prevedere la possibilità di alloggiare almeno 4 ulteriori porte di tipo SFP+ (10 Gb/s) rispetto al numero di porte effettivamente offerto dal Fornitore in ossequio al requisito HW-NT-03/GEN-01 |
HW-NT-02/ESP-02 | Espandibilità | Ogni unità deve prevedere la possibilità di alloggiare almeno 4 porte QSFP (40 Gb/s) contemporaneamente, a prescindere dal numero di porte SFP o SFP+ alloggiabili |
Codice | Categoria | Descrizione |
HW-NT-02/COM-01 | Compatibilità | Ogni unità deve garantire la piena interoperabilità rispetto agli standard di mercato verso gli apparati core esistenti nei due data center, ossia i core router di marca Cisco serie Catalyst 6500 / 6800 e i firewall di marca Check Point serie 12600 |
Programmabilità | La componente SDN deve esporre, attraverso command line e/o API, le principali funzioni di gestione dello Switch DC Ethernet, fra le quali almeno: • la creazione e la propagazione di VLAN, • la creazione e configurazione di Virtual Network, in termini di: o indirizzi di rete da utilizzare, o versione IP (IPv4, IPv6), o abilitazione del servizio DHCP server o client | |
HW-NT-02/PRE-01 | Prestazioni | Ogni unità deve garantire un tempo di latenza massimo nel traffico port-to-port non superiore a 2 microsecondi per pacchetti di grandezza uguale a 64 KB |
HW-NT-02/PRE-02 | Prestazioni | Ogni unità deve poter supportare la gestione contemporanea di: • almeno 90.000 MAC Address, • almeno 4.000 VLAN, • almeno 3.000 indirizzi IPv4, • almeno 8.000 indirizzi IPv6 |
5.2.7.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare sarà oggetto di valutazione il fattore migliorativo illustrato nella scheda seguente.
Criterio | Descrizione breve | Requisiti interessati | |
VT-15 | QSFP su singola coppia di fibre ottiche | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
4,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), ogni unità deve supportare porte di tipo QSFP in grado di trasmettere alla velocità di 40 Gb/s su singola coppia di fibre ottiche, per distanze inferiori a 100 metri | |||
5.2.8. HW-NT-03 – Moduli e Porte per Switch Data Center Ethernet
Correlata alla fornitura di ogni singola unità di Switch DC Ethernet (rif. §5.2.7), si richiede la fornitura di un adeguato numero di moduli e porte da installare sull’unità stessa, al fine di implementare tutte le connessioni di tipo Ethernet previste dal progetto di riferimento (rif. §4.1).
Come già premesso nel paragrafo 5.1, il progetto di riferimento indicato dall’Ateneo lascia al Fornitore l’onere di definire alcune scelte tecnologiche e prestazionali nella redazione del progetto esecutivo di massima; alcune di queste scelte (ad es. la natura e le caratteristiche degli Apparati di Distribuzione Ethernet per Blade) hanno un riflesso diretto nella determinazione del numero di moduli e porte necessari all’implementazione di tutte le connessioni, come richiesto; per tale motivo rimane in carico al Fornitore la determinazione del numero adeguato di oggetti da fornire, dandone evidenza in sede di Offerta Tecnica.
Vengono comunque di seguito fornite ulteriori informazioni ritenute necessarie per la determinazione della corretta numerosità:
• Con riferimento allo schema concettuale di interconnessione di livello generale presentato in Figura 6 nel paragrafo 4.1, tutte le connessioni di tipo Ethernet veicolate per il tramite dello Switch DC Ethernet
devono essere ridondante, ossia ogni coppia di apparati interconnessi deve poter comunicare tramite due percorsi fisicamente indipendenti.
• Da un punto di vista realizzativo, per implementare questa ridondanza, va tenuto da conto che:
§5.2.11.2 rispettivamente);
o come già indicato nel paragrafo 5.2.6.1, dal punto di vista della topologia fisica finale lo Switch DC Ethernet si connetterà al core router esclusivamente per tramite del firewall (da considerarsi come singola unità per sito).
In considerazione di ciò, in Figura 12 viene esplicitato lo schema di interconnessione richiesto dall’Ateneo fra le singole unità delle componenti architetturali del progetto.
• L’insieme completo di porte / interfacce di rete di tipo Ethernet messe a disposizione dalle singole unità interconnesse con lo Switch DC Ethernet deve essere ripartito equamente per il collegamento verso le due unità dello Switch stesso (si veda a titolo di esempio il punto seguente).
• Ogni unità di Switch DC Ethernet deve essere fornita con ulteriori porte libere, di vario tipo, per usi futuri, come da requisito tecnico a seguire.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura e i criteri di valutazione tecnica previsti.
5.2.8.2. Requisiti
Codice | Categoria | Descrizione |
Generale | Nell'ambito dell'appalto è richiesta una fornitura di moduli e porte in numerosità tale da garantire, per ogni unità di Switch DC Ethernet fornita: • l'implementazione di tutte le connessioni previste nel progetto di riferimento, fra lo Switch DC Ethernet e le componenti Blade Server / Chassis (per tramite degli Apparati di Distribuzione Ethernet per Blade), Switch Rack Ethernet, Piattaforma DWDM e Firewall; • la potenziale implementazione di ulteriori connessioni, nelle modalità previste nel progetto di riferimento, fra lo Switch DC Ethernet ed eventuali ulteriori Switch Rack Ethernet (che non fossero compresi nella fornitura) posizionati in tutti i rack di cui si prevede l’impiego nell’ambito del progetto di riferimento, eccetto quelli di permuta e del core del network; • 4 ulteriori porte libere di tipo SFP+ (10 Gb/s) per usi futuri. Pertanto la numerosità di moduli e porte della fornitura dovrà essere determinata dal Fornitore, in funzione della soluzione complessiva offerta | |
HW-NT-03/PRE-01 | Prestazioni | Stante l'obiettivo previsto dal progetto di riferimento, di realizzare una rete di tipo Ethernet che garantisca una velocità pari ad almeno 10 Gb/s su tutte le connessioni (tranne le eccezioni documentate), si richiede che ogni porta fornita supporti singolarmente una velocità pari almeno a 10 Gb/s in entrambe le direzioni |
Figura 12 – Schema di interconnessione del network di tipo Ethernet
5.2.8.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo. In particolare è richiesto al Fornitore di dare chiara evidenza di come il numero di moduli e porte effettivamente fornito sia sufficiente a garantire tutte le connessioni richieste, nel rispetto dei requisiti tecnici indicati dall’Ateneo.
Ogni Switch FC rappresenta un singolo apparato HW di networking, conteggiato come singola unità, da installarsi all’interno di un rack di storage (rif. §4.2) come elemento cardine di interconnessione dell’infrastruttura complessiva. Di seguito e nei paragrafi seguenti vengono descritti i requisiti richiesti per lo Switch FC, inteso come l’apparato su cui vengono installati moduli e porte per le connessioni di tipo FC; per i
requisiti relativi a quantità e caratteristiche tecniche dei moduli e delle porte da fornire nell’ambito dell’appalto per ogni unità di Switch FC, si rimanda al paragrafo 5.2.10.
Come previsto dal progetto di riferimento (rif. §4.1), il nuovo network di tipo FC dovrà estendere l’attuale infrastruttura FC esistente, la quale è costituita dai seguenti apparati Brocade:
• 4 unità modello 300 (IBM SAN24B), velocità 8 Gb/s, versione sistema operativo 6.4.3 (unità core);
• 4 unità modello 5470, velocità 8 Gb/s, versione sistema operativo 6.3.1b;
• 4 unità modello 4024, velocità 4 Gb/s, versione sistema operativo 6.2.2e;
• 4 unità modello 4020, velocità 4 Gb/s, versione sistema operativo 6.2.2d;
• 2 unità modello 200E, velocità 4 Gb/s, versione sistema operativo 6.2.2e;
di cui le prime 4 unità rappresentano lo switch FC legacy (una coppia per data center) di cui alla Figura 6 del paragrafo 4.1, verso cui dovrà essere effettuata l’interconnessione.
Si ritiene innanzitutto fondamentale evidenziare che, per raggiungere una piena interoperabilità fra i due network di tipo FC, così come intesa nei requisiti tecnici seguenti, e per preservare il complesso lavoro di costruzione del network esistente stratificato nel tempo, è obbligatoriamente richiesto che l’organizzazione della zonatura attualmente adottata, basata su Domain ID, sia mantenuta e resa operativa anche nel nuovo network di tipo FC fornito; a tal fine, il prodotto Switch FC fornito dovrà presentare tutte le caratteristiche tecniche necessarie a supportare il raggiungimento di questo obiettivo.
Per quanto riguarda le prestazioni della nuova infrastruttura, il progetto di riferimento prevede una velocità minima di almeno 8 Gb/s su tutte le connessioni. Tuttavia l’Ateneo considera un importante fattore premiante il poter disporre di un’infrastruttura potenziata, che, sfruttando le più recenti disponibilità del mercato, possa garantire una velocità complessiva di almeno 16 Gb/s (all’interno dei singoli data center e fatta eccezione per le connessioni verso lo switch FC legacy e verso la Piattaforma DWDM). Come indicato nel sotto- paragrafo a seguire relativo ai criteri di valutazione tecnica, questo potenziamento ha pieno valore solo se applicato coerentemente su tutte le connessioni del network in questione, ed anche sulla capacità di Input/Output (ossia sulle interfaccie di rete) delle componenti di data storage (SAN e Piattaforma di Virtualizzazione): per tale motivo esso ha impatto sui requisiti tecnici di tutti gli apparati coinvolti, come indicato nell’elenco dei requisiti interessati. Chiaramente, anche a fronte di un innalzamento della velocità minima a 16 Gb/s, l’infrastruttura deve continuare a garantire connessioni a 8 Gb/s.
Con riferimento al framework di gestione software-based (rif. §4.3), di seguito si imputano allo Switch FC tutte le funzionalità relative alla componente Software-Defined Networking (si veda definizione al paragrafo 3.1.1) per l’ambito FC, in grado di esporre quindi funzionalità di gestione avanzate programmabili delle risorse di networking; la componente SDN può anche coincidere con la console di amministrazione, di cui al requisito HW-GN-01/AMM-01. Ad ogni modo, in base alle tecnologie ed alle soluzioni tecniche proposte dal Fornitore, la componente SDN può essere realizzata anche al di fuori dello Switch FC fisico, sia attraverso altre componenti HW che con altri strumenti SW, purché chiaramente vengano rispettati tutti i requisiti tecnici espressi dall’Ateneo nel paragrafo seguente; in tali condizioni, il Fornitore è comunque obbligato, in sede di Offerta Tecnica, ad illustrare adeguatamente la propria soluzione nell’ambito del progetto esecutivo di massima (rif. §5.1). Rispetto all’ampiezza ed alla rilevanza delle funzionalità esposte dalla componente SDN in ambito FC, e più in generale del grado di integrazione con l’OA Engine, l’Ateneo considera un fattore significativamente premiante la fornitura di una soluzione complessiva che offra un’orchestrabilità di elevato valore tecnico e di ampia flessibilità e varietà di impiego; si rimanda al paragrafo 5.3.2 per maggiori dettagli.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura e i criteri di valutazione tecnica previsti.
Codice | Categoria | Descrizione |
HW-NT-04/GEN-01 | Generale | Nell'ambito dell'appalto è richiesta la fornitura di 4 unità, da distribuirsi equamente sui due data center |
HW-NT-04/TEC-01 | Tecnologia | Ogni unità deve implementare funzionalità di networking di Layer 2 (L2), con riferimento al modello OSI, per comunicazioni di tipo FC |
Codice | Categoria | Descrizione |
HW-NT-04/TEC-02 | Tecnologia | Ogni unità deve garantire che la propagazione dei messaggi RSCN (Registered State Change Notification) sia confinata all'interno della singola zona interessata |
Tecnologia | Ogni unità deve supportare moduli e porte di tipo SFP+ (8 Gb/s), sia SX (short distance) che LX (long distance), di tipo hot swappable | |
HW-NT-04/TEC-04 | Tecnologia | |
HW-NT-04/PRT-01 | Protocolli | Ogni unità deve implementare almeno i seguenti protocolli di Layer 2: • FSPF (Fabric Shortest Path First), • NPV (N_Port Virtualization), • FC Port Security, • FC Port Trunking, • FC Zoning |
HW-NT-04/AFF-01 | Affidabilità | Ogni unità deve possedere una certificazione di affidabilità rilasciata dal produttore pari al 99,999% |
HW-NT-04/AFF-02 | Affidabilità | Le due unità presenti in ciascun data center devono essere configurate come una coppia in alta affidabilità |
HW-NT-04/ESP-01 | Espandibilità | Ogni unità deve prevedere la possibilità di alloggiare almeno 48 porte |
HW-NT-04/COM-01 | Compatibilità | Ogni unità deve garantire l’interoperabilità verso il network di tipo FC esistente, al fine di assicurare che ogni dato presente su SAN (sia esistente che di nuova fornitura) sia accessibile in lettura e scrittura da ogni server / Blade Server (sia esistente che di nuova fornitura) al’interno dell’infrastruttura |
HW-NT-04/COM-02 | Compatibilità | Ogni unità deve garantire che, nell'interconnesione con il network FC esistente, l’organizzazione della zonatura attualmente adottata (i.e. Fabric, basata su Domain ID) sia preservata e resa operativa anche nel nuovo network FC fornito, senza interruzioni dei servizi attualmente erogati. Tale organizzazione deve comunque essere amministrabile / modificabile sia dall'unità fornita che dagli switch FC legacy |
HW-NT-04/COM-03 | Compatibilità | Ogni unità deve implementare la funzionalità di port trunking in maniera pienamente compatibile con l'implementazione adottata dagli switch FC legacy |
Programmabilità | La componente SDN deve esporre, attraverso command line e/o API, le principali funzioni di gestione dello Switch FC, fra le quali almeno la creazione e la gestione di zone |
5.2.9.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare sarà oggetto di valutazione l’eventuale offerta migliorativa di un’infrastruttura potenziata a 16 Gb/s, in tutte le componenti interessate, secondo i parametri indicati nella scheda seguente.
Criterio | Descrizione breve | Requisiti interessati | |
Network di tipo FC a 16 Gb/s | |||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
14,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), il network di tipo FC fornito deve garantire una | |||
velocità minima pari ad almeno 16 Gb/s su tutte le singole connessioni del backbone dei data | |||
center, sia verso le componenti di data storage (SAN e Piattaforma di Virtualizzazione dello Storage) sia fino all’arrivo sul singolo Blade Chassis; rappresentano un’esplicita eccezione | |||
sia le connessioni verso lo switch FC legacy che verso la Piattaforma DWDM. Nello specifico, | |||
laddove in ciascuno dei requisiti interessati dal presente criterio si richiede una velocità minima pari ad almeno 8 Gb/s, la soluzione offerta deve garantire una velocità minima pari ad almeno 16 Gb/s, per tutti i requisiti. L’infrastruttura deve in ogni caso continuare a garantire connessioni a 8 Gb/s
5.2.10. HW-NT-05 – Moduli e Porte per Switch FC
Correlata alla fornitura di ogni singola unità di Switch FC (rif. §5.2.9), si richiede la fornitura di un adeguato numero di moduli e porte da installare sull’unità stessa, al fine di implementare tutte le connessioni di tipo FC previste dal progetto di riferimento (rif. §4.1).
Come già premesso nel paragrafo 5.1, il progetto di riferimento indicato dall’Ateneo lascia al Fornitore l’onere di definire alcune scelte tecnologiche e prestazionali nella redazione del progetto esecutivo di massima; alcune di queste scelte (ad es. la natura e le caratteristiche degli Apparati di Distribuzione FC per Blade) hanno un riflesso diretto nella determinazione del numero di moduli e porte necessari all’implementazione di tutte le connessioni, come richiesto; per tale motivo rimane in carico al Fornitore la determinazione del numero adeguato di oggetti da fornire, dandone evidenza in sede di Offerta Tecnica.
Vengono comunque di seguito fornite ulteriori informazioni ritenute necessarie per la determinazione della corretta numerosità:
• Con riferimento allo schema concettuale di interconnessione di livello generale presentato in Figura 6 nel paragrafo 4.1, tutte le connessioni di tipo FC veicolate per il tramite dello Switch FC devono essere ridondante, ossia ogni coppia di apparati interconnessi deve poter comunicare tramite due percorsi fisicamente indipendenti.
• Da un punto di vista realizzativo, per implementare questa ridondanza, va tenuto da conto che:
o anche lo switch FC legacy sarà implementato come una coppia di unità in alta affidabilità.
In considerazione di ciò, in Figura 13 viene esplicitato lo schema di interconnessione richiesto dall’Ateneo fra le singole unità delle componenti architetturali del progetto.
• L’insieme completo di porte / interfacce di rete di tipo FC messe a disposizione dalle singole unità interconnesse con lo Switch FC deve essere ripartito equamente per il collegamento verso le due unità dello Switch stesso (es. di tutte le porte della singola SAN, di cui al requisito HW-ST-01/CAP-05, una metà devono essere utilizzate per la connessione verso un’unità dello Switch FC, mentre l’altra metà per la connessione verso la seconda unità dello Switch FC).
• Ogni unità di switch FC legacy mette a disposizione 2 porte di tipo FC a 8 Gb/s, le quali devono essere entrambe utilizzate per l’interconnessione verso la corrispondente unità di Switch FC, come da schema in Figura 13.
• Ogni unità di Switch FC deve essere fornita con ulteriori porte libere, per usi futuri, come da requisito tecnico a seguire.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura e i criteri di valutazione tecnica previsti.
Figura 13 – Schema di interconnessione del network di tipo FC
5.2.10.2. Requisiti
Codice | Categoria | Descrizione |
HW-NT-05/GEN-01 | Generale | Nell'ambito dell'appalto è richiesta una fornitura di moduli e porte in numerosità tale da garantire, per ogni unità di Switch FC fornita: • l'implementazione di tutte le connessioni previste nel progetto di riferimento, fra lo Switch FC e le componenti Blade Server / Chassis (per tramite degli Apparati di Distribuzione FC per Blade), SAN, Piattaforma di Virtualizzazione dello Storage, Piattaforma DWDM e switch FC legacy; • 4 ulteriori porte libere di tipo SFP+ (8 Gb/s) per usi futuri. |
Codice | Categoria | Descrizione |
Tecnico. Pertanto la numerosità di moduli e porte della fornitura dovrà essere determinata dal Fornitore, in funzione della soluzione complessiva offerta | ||
HW-NT-05/TEC-01 | Tecnologia | Ciascuna porta deve poter negoziare connessioni per frazioni della banda massima disponibile (es. a 2 o 4 Gb/s) |
Prestazioni | Stante l'obiettivo previsto dal progetto di riferimento, di realizzare una rete di tipo FC che garantisca una velocità pari ad almeno 8 Gb/s per tutte le connessioni, fino all’arrivo sul singolo Blade Chassis, si richiede che ogni porta fornita supporti singolarmente una velocità pari almeno a 8 Gb/s |
5.2.10.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo. In particolare è richiesto al Fornitore di dare chiara evidenza di come il numero di moduli e porte effettivamente fornito sia sufficiente a garantire tutte le connessioni richieste, nel rispetto dei requisiti tecnici indicati dall’Ateneo.
Il componente in oggetto è altresì interessato dal criterio di valutazione VT-16, al quale si rimanda (§5.2.9.3) per ulteriori dettagli.
5.2.11. HW-NT-06 – Switch Rack Ethernet
5.2.11.1. Descrizione
Ogni Switch Rack Ethernet rappresenta un singolo apparato HW di networking, conteggiato come singola unità, da installarsi all’interno dei rack di storage e dei rack per legacy, secondo lo schema riportato nel paragrafo 4.2, come elemento cardine di interconnessione dell’infrastruttura complessiva.
Lo Switch Rack Ethernet è deputato alla distribuzione del network di tipo Ethernet sul singolo rack. In generale, nel progetto di riferimento (rif. §4.1) ne è previsto un impiego generico, per espandibilità future verso apparati non meglio identificati, a prescindere dalle risorse di computing e storage già previste dalla fornitura. In tale ottica, l’Ateneo considera un fattore premiante la fornitura integrativa di ulteriori apparati da installarsi in un numero maggiore di rack, come indicato nel sotto-paragrafo a seguire relativo ai criteri di valutazione tecnica.
In funzione della soluzione tecnologica offerta dal Fornitore, gli apparati possono rappresentare funzionalmente delle espansioni dello Switch DC Ethernet (rif. §5.2.7); in tal caso si richiede al Fornitore di specificare adeguatamente la soluzione nel progetto esecutivo di massima (rif. §5.1). In ogni caso, con riferimento al framework di gestione software-based (rif. §4.3), si richiede che tutte le funzionalità relative alla componente Software-Defined Networking (si veda definizione al paragrafo 3.1.1), già imputate allo Switch DC Ethernet, si possano estendere funzionalmente anche agli Switch Rack Ethernet, in maniera integrata e trasparente.
Coerentemente con gli obiettivi già espressi nella descrizione dello Switch DC Ethernet, si richiede che la connessione di uplink fra Switch Rack Ethernet e Switch DC Ethernet, che costitusce parte del backbone interno di tipo Ethernet del data center, garantisca una velocità pari ad almeno 10 Gb/s e pertanto la si realizzi utilizzando (esclusivamente) le porte su fibra ottica di cui lo Switch Rack Ethernet dovrà essere equipaggiato.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura ed i criteri di valutazione previsti.
Codice | Categoria | Descrizione |
Generale | Nell'ambito dell'appalto è richiesta la fornitura di 12 unità, ossia una coppia per ogni rack di storage ed ogni rack per legacy previsto dal progetto di riferimento (rif. §4.2), da distribuirsi uniformemente sui due siti | |
HW-NT-06/TEC-01 | Tecnologia | Ogni unità deve rappresentare un'architettura non bloccante, ossia tutte le porte installate in massima configurazione devono poter essere utilizzate in modalità non-blocking in entrambe le direzioni |
HW-NT-06/TEC-02 | Tecnologia | Ogni unità deve implementare funzionalità di networking di Layer 2 (L2), con riferimento al modello OSI, su rete di tipo Ethernet |
HW-NT-06/TEC-03 | Tecnologia | Ogni unità deve supportare porte delle seguenti tecnologie: • Ethernet su rame secondo lo standard 100/1000Base-T, • Ethernet su fibra ottica secondo lo standard 10GBase-SR (Short Range) |
HW-NT-06/TEC-04 | Tecnologia | Per l'implementazione dell'uplink verso lo Switch DC Ethernet, parte del backbone interno di tipo Ethernet del data center, su ogni unità devono essere utilizzate esclusivamente le porte su fibra ottica (10GBase-SR) |
HW-NT-06/TEC-05 | Tecnologia | In ogni unità tutte le porte configurabili devono essere di tipo wirespeed |
HW-NT-06/TEC-06 | Tecnologia | |
HW-NT-06/TEC-07 | Tecnologia | Ogni unità deve presentare un ingombro massimo di 1 rack unit |
HW-NT-06/PRT-01 | Protocolli | Ogni unità deve implementare almeno i seguenti protocolli di Layer 2: • VLAN, • Private VLAN, • LLDP (Link Layer Discovery Protocol), • 802.3ad, • QoS (Quality of Service) |
HW-NT-06/PRT-02 | Protocolli | Ogni unità deve implementare almeno i seguenti protocolli di monitoraggio e sicurezza: • ACL (Access Control List), • SNMPv1/2/3, • SSHv2, • Telnet, • Syslog |
HW-NT-06/AFF-01 | Affidabilità | Le due unità presenti in ciascun rack devono essere configurate come una coppia in alta affidabilità |
HW-NT-06/CAP-01 | Capacità | Ogni unità deve essere equipaggiata con: • almeno 48 porte Ethernet su rame di tipo 100/1000Base-T, • almeno 4 porte Ethernet su fibra ottica di tipo 10GBase-SR |
HW-NT-06/PRG-01 | Programmabilità | Le funzionalità esposte dalla componente SDN, di cui al requisito HW-NT-02/PRG-01, devono potersi estendere funzionalmente anche agli Switch Rack Ethernet, in maniera integrata e trasparente |
5.2.11.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare sarà oggetto di valutazione il fattore migliorativo illustrato nelle scheda seguente.
Criterio | Descrizione breve | Requisiti interessati | |
VT-17 | Numero di unità Switch Rack Ethernet | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
10,0 | Tabellare a livelli | Non applicabile | |
Note sulle modalità di valutazione | |||
Per una valutazione positiva del criterio premiante, il numero complessivo di unità Switch Rack Ethernet fornite deve essere superiore al minimo richiesto. Verranno assegnati i seguenti punti in funzione del numero di unità offerte in aggiunta al numero minimo richiesto: • 4 punti in caso di 4 ulteriori unità fornite, da installarsi a coppie nei rack per servizi di network sui due siti; • 7 punti in caso di 8 ulteriori unità fornite, da installarsi a coppie nei rack per servizi di network e in una parte dei rack di computing, distribuiti uniformemente sui due siti; • 10 punti in caso di 12 ulteriori unità fornite, da installarsi a coppie nei rack per servizi di network e nei rack di computing sui due siti | |||
5.2.12. HW-NT-07 – Apparati di Distribuzione Ethernet per Blade
Come indicato nelle premesse al progetto di riferimento (rif. §4.1), gli Apparati di Distribuzione Ethernet per Blade rappresentano una funzionalità strettamente necessaria al funzionamento dell’architettura (in quanto implementano la parte del network di tipo Ethernet, sia di produzione che di management, tramite cui i Blade Server / Chassis – rif. §5.2.2 e §5.2.3 – si connettono allo Switch DC Ethernet), ma la cui soluzione tecnica, sia in termini tecnologici che dimensionali, viene lasciata alla progettualità del Fornitore, che ne dovrà dare illustrazione nel progetto esecutivo di massima in sede di Offerta Tecnica (rif. §5.1).
Nei sotto-paragrafi seguenti si esplicitano comunque i requisiti minimi che la soluzione dovrà soddisfare, i quali sostanzialmente coprono i seguenti temi:
• ridondanza delle connessioni dei Blade Server / Chassis verso lo Switch DC Ethernet e degli apparati utilizzati per la loro realizzazione;
• prestazioni minime in termini di banda garantita (per singola interfaccia di rete di ogni singolo Blade Server);
In relazione al primo punto menzionato, si fa presente che, non essendo note le modalità realizzative degli apparati, il presente Capitolato non specifica (come altrimenti fatto per le altre componenti della fornitura) la numerosità minima di eventuali unità, tuttavia si ritiene opportuno evidenziare che, per coerenza e completezza dell’obiettivo generale di massima ridondanza dell’infrastruttura IT traguardata:
• ogni risorsa HW fornita dal Fornitore nella soluzione proposta non deve presentare single point of failure, in applicazione del requisito generale HW-GN-01/AFF-01;
• si richiede che gli apparati forniti garantiscano connessioni ridondate su risorse HW fisicamente indipendenti.
Per quanto riguarda invece il secondo punto, ossia le prestazioni attese, il Centro Infosapienza ritiene che le differenti soluzioni tecnologiche presenti sul mercato nonché il grado di propositività in sede di gara del Fornitore, possano mettere a disposizione dell’Ateneo scenari di diverso valore, in termini appunto di banda minima garantita. Data la filiera complessa e variegata di componenti tecnologiche che interconnette i Blade Server con lo Switch DC Ethernet, verranno presi a riferimento dei precisi punti di misurazione, che il Centro Infosapienza ritiene generalizzabili, ossia:
• nella comunicazione fra due interfacce di rete di due Blade Server distinti installati all’interno di uno stesso Blade Chassis;
• nella comunicazione fra due interfacce di rete di due Blade Server installati all’interno di due Blade Chassis distinti residenti nello stesso data center;
• nella comunicazione fra ogni singola interfaccia di rete di un Blade Server fino all’arrivo sullo Switch DC Ethernet (ovviamente del medesimo data center).
I calcoli richiesti vanno effettuati nello scenario ipotetico di due Blade Chassis equipaggiati con il massimo numero di Blade Server alloggiabili (della tipologia e configurazione effettivamente offerta).
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare adeguatamente le prestazioni garantite dalla propria soluzione tecnica proposta; naturalmente il Centro Infosapienza ritiene un fattore significativamente premiante la disponibilità di prestazioni superiori alla banda minima garantita richiesta, pari a 1 Gb/s per singola interfaccia di rete fornita.
In ogni caso, gli apparati forniti non devono rappresentare un vincolo strutturale alla velocità massima raggiungibile dalla singola interfaccia di rete di tipo Ethernet per ogni Blade Server, che, come indicato dal requisito HW-CP-01/PRE-02, deve poter raggiungere almeno il valore di 10 Gb/s, in assenza di condivisione di banda con altre risorse di computing nello stesso Blade Chassis.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura ed i criteri di valutazione previsti.
Codice | Categoria | Descrizione |
HW-NT-07/GEN-01 | Generale | Nell'ambito dell'appalto è richiesta una fornitura di Apparati di Distribuzione Ethernet per Blade, così come definiti dal progetto di riferimento e nel paragrafo 5.2.12.1 del Capitolato Tecnico, secondo scelte tecnologiche e realizzative e numerosità che dovranno essere determinate dal Fornitore, nel rispetto di tutti i requisiti tecnici previsti per tali apparati |
HW-NT-07/TEC-01 | Tecnologia | Gli apparati devono implementare funzionalità di networking di Layer 2 (L2), con riferimento al modello OSI, su rete di tipo Ethernet |
HW-NT-07/PRT-01 | Protocolli | Gli apparati devono implementare almeno i seguenti protocolli di Layer 2: • VLAN, • Private VLAN, • LLDP (Link Layer Discovery Protocol), • 802.3ad, • QoS (Quality of Service) |
HW-NT-07/AFF-01 | Affidabilità | Gli apparati forniti devono implementare connessioni di tipo Ethernet fra il singolo Server Blade e lo Switch DC Ethernet, in maniera ridondata su risorse HW indipendenti |
HW-NT-07/PRG-01 | Programmabilità | Le funzionalità esposte dalla componente SDN, di cui al requisito HW-NT-02/PRG-01, devono potersi estendere funzionalmente anche agli Apparati di Distribuzione Ethernet per Blade, in maniera integrata e trasparente |
Prestazioni | Gli apparati forniti devono garantire che la velocità minima di connessione fra ogni singola interfaccia di rete di tipo Ethernet di ogni Blade Server alloggiabile in un Blade Chassis e lo Switch DC Ethernet sia pari ad almeno 1 Gb/s in entrambe le direzioni. I calcoli richiesti vanno effettuati nello scenario ipotetico di un Blade Chassis equipaggiato con il massimo numero di Blade Server alloggiabili (della tipologia e configurazione effettivamente offerta) | |
HW-NT-07/PRE-02 | Prestazioni | Gli apparati forniti devono garantire che la velocità massima di connessione fra ogni singola interfaccia di rete di tipo Ethernet di ogni Blade Server alloggiabile in un Blade Chassis e lo Switch DC Ethernet sia pari ad almeno 10 Gb/s in entrambe le direzioni, in assenza di condivisione di banda con altre risorse di computing nello stesso Blade Chassis |
5.2.12.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare verranno valutati alcuni fattori migliorativi, secondo i criteri illustrati nelle schede seguenti.
Criterio | Descrizione breve | Requisiti interessati | |
VT-18 | Velocità minima garantita intra-chassis | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
8,0 | Tabellare a livelli | Non applicabile | |
Note sulle modalità di valutazione | |||
Per una valutazione positiva del criterio premiante, gli Apparati di Distribuzione Ethernet per Blade offerti devono garantire, nella comunicazione fra due interfacce di rete di due Blade Server distinti installati all’interno di uno stesso Blade Chassis, una velocità minima in entrambe le direzioni superiore al valore minimo richiesto. Verranno assegnati i seguenti punti in funzione della velocità minima effettiva offerta: • 4 punti per velocità comprese strettamente fra 1 Gb/s e 10 Gb/s (i.e. 1 < velocità < 10, in Gb/s); • 6 punti per velocità uguali o maggiori di 10 Gb/s e strettamente minori di 40 Gb/s (i.e. 10 <= velocità < 40, in Gb/s); • 8 punti per velocità uguali o maggiori di 40 Gb/s (i.e. velocità >= 40 Gb/s). I calcoli richiesti vanno effettuati nello scenario ipotetico di un Blade Chassis equipaggiato con il massimo numero di Blade Server alloggiabili (della tipologia e configurazione effettivamente offerta) | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-19 | Velocità minima garantita inter-chassis | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
8,0 | Tabellare a livelli | Non applicabile | |
Note sulle modalità di valutazione | |||
Per una valutazione positiva del criterio premiante, gli Apparati di Distribuzione Ethernet per Blade offerti devono garantire, nella comunicazione fra due interfacce di rete di due Blade Server installati all’interno di due Blade Chassis distinti residenti nello stesso data center, una velocità minima in entrambe le direzioni superiore al valore minimo richiesto. Verranno assegnati i seguenti punti in funzione della velocità minima effettiva offerta: • 4 punti per velocità comprese strettamente fra 1 Gb/s e 10 Gb/s (i.e. 1 < velocità < 10, in Gb/s); • 6 punti per velocità uguali o maggiori di 10 Gb/s e strettamente minori di 40 Gb/s (i.e. 10 <= velocità < 40, in Gb/s); • 8 punti per velocità uguali o maggiori di 40 Gb/s (i.e. velocità >= 40 Gb/s). I calcoli richiesti vanno effettuati nello scenario ipotetico di due Blade Chassis equipaggiati con il massimo numero di Blade Server alloggiabili (della tipologia e configurazione effettivamente offerta) | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-20 | Velocità minima garantita verso lo Switch DC Ethernet | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
8,0 | Tabellare a livelli | Non applicabile | |
Note sulle modalità di valutazione | |||
Per una valutazione positiva del criterio premiante, gli Apparati di Distribuzione Ethernet per Blade offerti devono garantire, per la connessione fra ogni singola interfaccia di rete di tipo Ethernet di ogni Blade Server alloggiabile all'interno di un Blade Chassis e lo Switch DC Ethernet, una velocità minima in entrambe le direzioni superiore al valore minimo richiesto. Verranno assegnati i seguenti punti in funzione della velocità minima effettiva offerta: • 4 punti per velocità comprese strettamente fra 1 Gb/s e 2 Gb/s (i.e. 1 < velocità < 2, in Gb/s); • 6 punti per velocità uguali o maggiori di 2 Gb/s e strettamente minori di 5 Gb/s (i.e. 2 <= velocità < 5, in Gb/s); • 8 punti per velocità uguali o maggiori di 5 Gb/s (i.e. velocità >= 5 Gb/s). I calcoli richiesti vanno effettuati nello scenario ipotetico di un Blade Chassis equipaggiato con il massimo numero di Blade Server alloggiabili (della tipologia e configurazione effettivamente offerta) | |||
5.2.13. HW-NT-08 – Apparati di Distribuzione FC per Blade
Come indicato nelle premesse al progetto di riferimento (rif. §4.1), gli Apparati di Distribuzione FC per Blade rappresentano una funzionalità strettamente necessaria al funzionamento dell’architettura (in quanto implementano la parte del network di tipo FC tramite cui i Blade Server / Chassis – rif. §5.2.2 e §5.2.3 – si connettono allo Switch FC), ma la cui soluzione tecnica, sia in termini tecnologici che dimensionali, viene lasciata alla progettualità del Fornitore, che ne dovrà dare illustrazione nel progetto esecutivo di massima in sede di Offerta Tecnica (rif. §5.1).
Nei sotto-paragrafi seguenti si esplicitano comunque i requisiti minimi che la soluzione dovrà soddisfare, i quali sostanzialmente coprono i seguenti temi:
• ridondanza delle connessioni dei Blade Server / Chassis verso lo Switch FC e degli apparati utilizzati per la loro realizzazione;
• prestazioni minime in termini di banda garantita (per singolo Blade Chassis);
• estensione completa delle funzionalità della componente SDN (già imputate allo Switch FC – rif.
§5.2.9).
In relazione al primo punto menzionato, si fa presente che, non essendo note le modalità realizzative degli apparati, il presente Capitolato non specifica (come altrimenti fatto per le altre componenti della fornitura) la numerosità minima di eventuali unità, tuttavia si ritiene opportuno evidenziare che, per coerenza e completezza dell’obiettivo generale di massima ridondanza dell’infrastruttura IT traguardata:
• ogni risorsa HW fornita dal Fornitore nella soluzione proposta non deve presentare single point of failure, in applicazione del requisito generale HW-GN-01/AFF-01;
• si richiede che gli apparati forniti garantiscano connessioni ridondate su risorse HW fisicamente indipendenti.
Per quanto riguarda invece il secondo punto, ossia le prestazioni attese, analogamente a quanto già menzionato nei paragrafi 4.1 e 5.2.9, il progetto di riferimento prevede una velocità minima di almeno 8 Gb/s in arrivo sul singolo Blade Chassis; tuttavia una fornitura che garantisca una velocità di almeno 16 Gb/s, nell’ambito di un potenziamento coerente dell’intero network di tipo FC all’interno di ciascun data center, potrà godere di una valutazione premiante, nel rispetto del criterio già presentato nel paragrafo 5.2.9.3.
In ogni caso, gli apparati forniti non devono rappresentare un vincolo strutturale alla velocità massima raggiungibile dalla singola interfaccia di rete di tipo FC per ogni Blade Server, che, come indicato dal requisito HW-CP-01/PRE-03, deve poter raggiungere almeno il valore di 8 Gb/s, in assenza di condivisione di banda con altre risorse di computing nello stesso Blade Chassis.
Infine, si pone l’accento sulla possibilità, ammessa dal progetto di riferimento dell’Ateneo (si veda la Figura 7 presentata nel paragrafo 4.1), che la soluzione tecnologica offerta dal Fornitore si avvalga della convergenza tecnica fra la connettività di tipo FC e quella di tipo Ethernet nell’ambito degli apparati di distribuzione: in altri termini, attraverso l’uso del protocollo FCoE il Fornitore può proporre Apparati di Distribuzione Ethernet per Blade (rif. §5.2.12) che a tutti gli effetti esplichino le funzioni degli Apparati di Distribuzione FC per Blade (i due apparati vengono così a coincidere fisicamente), rispettando tutti i requisiti tecnici richiesti per questi ultimi e di seguito esplicitati. Tale scenario tecnologico è ritenuto un fattore premiante da parte dell’Ateneo, in quanto apportatore di benefici in termini di semplificazione dell’infrastruttura e delle logiche di networking, e relativi costi di gestione. Laddove il Fornitore ritenga di proporre tale tipologia di soluzione, ne dovrà dare opportuna e dettagliata evidenza nel progetto esecutivo di massima in sede di Offerta Tecnica (rif. §5.1).
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura ed i criteri di valutazione previsti.
Codice | Categoria | Descrizione |
Generale | Nell'ambito dell'appalto è richiesta una fornitura di Apparati di Distribuzione FC per Blade, così come definiti dal progetto di riferimento e nel paragrafo 5.2.13.1 del Capitolato Tecnico, secondo scelte tecnologiche e realizzative e numerosità che dovranno essere determinate dal Fornitore, nel rispetto di tutti i requisiti tecnici previsti per tali apparati | |
HW-NT-08/TEC-01 | Tecnologia | Gli apparati devono implementare funzionalità di networking di Layer 2 (L2), con riferimento al modello OSI, per comunicazioni di tipo FC |
HW-NT-08/PRT-01 | Protocolli | Gli apparati devono implementare almeno i seguenti protocolli di Layer 2: • FSPF (Fabric Shortest Path First), • NPV (N_Port Virtualization), • FC Port Security, • FC Port Trunking, • FC Zoning |
HW-NT-08/AFF-01 | Affidabilità | Gli apparati forniti devono implementare connessioni di tipo FC fra il singolo Server Blade e lo Switch FC, in maniera ridondata su risorse HW indipendenti |
HW-NT-08/PRG-01 | Programmabilità | Le funzionalità esposte dalla componente SDN, di cui al requisito HW-NT-04/PRG-01, devono potersi estendere funzionalmente anche agli Apparati di Distribuzione FC per Blade, in maniera integrata e trasparente |
Prestazioni | Gli apparati forniti devono garantire che la velocità minima di connessione fra ogni Blade Chassis e lo Switch FC sia pari ad almeno 8 Gb/s | |
Prestazioni | Gli apparati forniti devono garantire che la velocità massima di connessione fra ogni singola interfaccia di rete di tipo FC di ogni Blade Server alloggiabile in un Blade Chassis e lo Switch FC sia pari ad almeno 8 Gb/s, in assenza di condivisione di banda con altre risorse di computing nello stesso Blade Chassis |
5.2.13.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare sarà oggetto di valutazione il fattore migliorativo illustrato nelle scheda seguente.
Criterio | Descrizione breve | Requisiti interessati | |
VT-21 | Apparati convergenti | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
6,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), la soluzione offerta dal Fornitore deve prevedere che gli Apparati di Distribuzione FC per Blade siano fisicamente coincidenti con gli Apparati di Distribuzione Ethernet per Blade, in virtù dell'impiego di tecnologie convergenti (i.e. FCoE) da parte di questi ultimi, i quali devono pertanto implementare in toto le funzionalità richieste agli Apparati di Distribuzione FC per Blade e rispettarne tutti i requisiti tecnici richiesti | |||
Il componente in oggetto è altresì interessato dal criterio di valutazione VT-16, al quale si rimanda (§5.2.9.3) per ulteriori dettagli.
5.3. Software
Nella presente sezione del documento vengono dettagliati gli elementi della fornitura che rappresentano beni di tipo SW, sia del dominio tools che cloud, nell’ambito del framework di gestione software-based adottato dall’Ateneo (rif. §4.3). Si ricorda che l’identificazione di componenti distinte nel framework è funzionale solo
ad una più semplice enucleazione delle funzionalità richieste; è pertanto ammissibile che le due componenti di seguito trattate, OA Engine e CSP, possano corrispondere a moduli di una suite integrata offerta dal Fornitore o anche a sole funzionalità distribuite su moduli che non trovino una corrispondenza diretta con la suddivisione proposta dal framework dell’Ateneo.
Il paragrafo 5.3.1 presenta alcuni requisiti generali comuni a tutti i beni SW richiesti al Fornitore, mentre nei paragrafi successivi vengono illustrate le caratteristiche delle singole componenti SW previste.
Codice | Categoria | Descrizione |
SW-GN-01/GEN-01 | Generale | Tutte le risorse SW offerte dal Fornitore devono essere beni esistenti e disponibili sul mercato al momento della presentazione dell’Offerta Tecnica e non devono prevedere sviluppi di funzionalità ad-hoc per rispettare i requisiti richiesti dall’Ateneo (sono ammesse solo configurazioni documentate di funzionalità esistenti) |
SW-GN-01/GEN-02 | Generale | Tutte le risorse SW offerte dal Fornitore devono essere fornite con licenza perpetua in grado di operare all’interno dell’intera infrastruttura fornita e di poterla gestire / orchestrare in maniera completa, senza limitazioni. A tal scopo si richiede che l’infrastruttura sia abilitata a gestire almeno 500 VM, ospitate dalla componente Hypervisor |
5.3.2. SW-TL-01 – Orchestration & Automation Engine
L’OA Engine è la piattaforma cardine nel framework di riferimento (rif. §4.3), volto a massimizzare l’efficacia e l’efficienza del paradigma SDDC, fornendo agli amministratori IT avanzati strumenti SW di coordinamento e comando delle risorse dell’infrastruttura IT, anche in modalità automatizzata.
Chiaramente rappresenta un bene SW; relativamente all’installazione, si può assumere che tutti i moduli necessari offerti dal Fornitore verranno installati (rif. §5.5.4) utilizzando parte delle risorse computazionali e di data storage dell’infrastruttura HW fornita, illustrate nel paragrafo 5.2.
Riprendendo lo schema di Figura 10 nel paragrafo 4.3, di seguito si illustrano brevemente le principali funzionalità richieste all’engine, a cui si associano i requisiti tecnici specifici descritti nel sotto-paragrafo seguente.
Secondo la visione del Centro Infosapienza, lo strumento principale che l’engine deve mettere a disposizione sono i workflow, intesi, ai fini del presente Capitolato, come flussi di lavoro programmabili, automatizzabili (parzialmente o totalmente), pianificabili, ripetibili, monitorabili. Sostanzialmente tali workflow devono permettere di codificare nell’engine tipiche attività (sequenze di azioni) di gestione sistemistica dell’infrastruttura, in tutte le sue componenti fondamentali (computing, storage, networking e sicurezza), sia di tipo puntuale che massivo e sia di tipo ordinario che straordinario. L’Ateneo considera un fattore premiante la capacità nativa della soluzione proposta di rendere quanto più facile, rapida ed efficiente la programmazione dei workflow, attraverso la disponibilità di librerie pre-costituite di oggetti semantici rappresentativi di reali risorse infrastrutturali, applicative o custom. Inoltre rappresenta un fattore premiante anche la possibilità di automatizzare workflow / processi di verifica della compliance sulle VM e le architetture istanziate: l’Ateneo considera infatti un elemento di seria attenzione il livello generale di sicurezza e standardizzazione delle proprie risorse, e la capacità di stabilire e mantenere nel tempo delle baseline garantite può rappresentare, tra l’altro, un fattore determinante di sostenibilità nella piena adozione del modello del Cloud Computing, a fronte dei rischi di sicurezza ed instabilità che le sue proprietà (i.e. self- service a richiesta, elasticità, ecc.) intrinsecamente portano.
Per realizzare i workflow è indispensabile che l’engine sappia interagire / orchestrare le risorse infrastrutturali sottostanti; più specificatamente l’engine deve saper colloquiare con le componenti HM, Hypervisor, SMC, SDS e SDN, in modo da poter eseguire (o far eseguire) le singole funzionalità da queste esposte. Ciò
rappresenta un requisito vincolante nell’ambito delle risorse infrastrutturali fornite dal Fornitore (con riferimento alle componenti SMC, SDS e SDN) e di quelle legacy previste dal contesto dell’Ateneo (con riferimento alle componenti HM e Hypervisor); l’Ateneo considera comunque un fattore premiante la fornitura di una soluzione complessiva che offra un’orchestrabilità di elevato valore tecnico e di ampia flessibilità e varietà di impiego, pertanto si richiede al Fornitore, in sede di offerta, di esporre adeguatamente il valore della soluzione proposta, secondo i criteri di valutazione espressi nel sotto-paragrafo a seguire. Inoltre, ulteriore fattore premiante è la disponibilità, nell’ambito della soluzione offerta, di un’interazione fra l’engine e le componenti SDDC basata sull’utilizzo di protocolli aperti e/o standard, così da garantirsi nel futuro prossimo la capacità di poter integrare efficacemente nell’infrastruttura nuove risorse di computing o di storage o di networking eventualmente differenti per marca e per implementazione da quelle fornite, ma compatibili rispetto ai protocolli.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura e i criteri di valutazione tecnica previsti.
5.3.2.2. Requisiti
Codice | Categoria | Descrizione |
Tecnologia | L'engine deve permettere di disegnare workflow che implementino l'automazione: • dell'intero ciclo di vita dei servizi As-a-Service, dalla fase di provisioning alla loro dismissione; • di procedure di gestione sistemistica ordinaria (es. shutdown programmato di architetture complesse), anche massiva (es. distribuzione / installazione di applicativi o di patch / fix di sistema operativo); • di procedure di gestione sistemistica straordinaria (es. moving di risorse in caso di failover o altre situazioni critiche), anche massiva | |
Tecnologia | L'engine deve permettere il disegno di workflow attraverso attraverso tool grafici evoluti (es. di tipo drag&drop) e l'uso di librerie di oggetti semantici rappresentativi di reali risorse infrastrutturali, applicative o custom (derivanti dall'integrazione con soluzioni di terze parti non incluse nella fornitura), con il fine di accelerare i tempi di realizzazione e minimizzare la necessità di conoscenza di linguaggi di programmazione o markup come precondizione all'utilizzo | |
SW-TL-01/TEC-03 | Tecnologia | L'engine deve permettere la definizione di workflow completamente automatici o parzialmente automatici, ossia che prevedano un'interazione con persone e procedure organizzative |
SW-TL-01/TEC-04 | Tecnologia | L'engine deve permettere l'esecuzione di workflow in modalità manuale o schedulata, attraverso uno schedulatore interno |
Tecnologia | L'engine deve permettere la definizione di workflow basati su modelli complessi di tipo infrastrutturale o applicativo. In particolare, deve essere possibile definire workflow che istanzino architetture a più livelli (es. presentation/front-end, business logic/middleware, database/back-end) e/o più architetture contemporaneamente (es. ambienti di sviluppo, test e produzione) | |
SW-TL-01/TEC-06 | Tecnologia | L'engine deve permettere la gestione di un repository dei workflow disegnati, con la possibilità di riuso nella creazione di nuovi workflow per differenza e con la possibilità di esecuzioni basate su parametri di ingresso variabili |
Tecnologia | Il sistema di orchestrazione dovrà consentire il frazionamento delle risorse IT (sia fisiche che virtuali) oggetto di fornitura in partizioni, ossia in pool disgiunti e distinguibili (es. risorse di prima fascia vs risorse di seconda fascia oppure risorse dedicate ai servizi core), utilizzabili nella definizione dei workflow, in particolare nei workflow di istanziazione di servizi | |
Tecnologia | L'engine deve poter eseguire (o far eseguire) azioni sistemistiche su risorse IT di tipo fisico (non virtuali). Laddove applicabile, si può assumere che i sistemi operativi da interfacciare siano di tipo Linux o Microsoft |
Codice | Categoria | Descrizione |
SW-TL-01/TEC-09 | Tecnologia | L’engine deve permettere la definizione di workflow in grado di inviare dati o comandi a componenti esterne (es. tool di IT Service Management), qualora queste ultime espongano modalità documentate e/o basate su protocolli aperti e/o standard (es. API, web services, e-mail) per l’interazione remota |
SW-TL-01/TEC-10 | Tecnologia | La piattaforma deve essere in grado di gestire un repository permanente di immagini di VM. L'inserimento di nuove immagini nel repository deve poter avvenire almeno tramite le seguenti funzionalità: • selezione del percorso al file dell'immagine, attraverso il browsing del file system locale o di rete; • download del file dell'immagine attraverso l'accesso via HTTP o FTP ad un web server; • duplicazione di immagini già presenti nel repository (eventualmente interagendo con la componente HM); • creazione di snapshot di VM in funzione (eventualmente interagendo con la componente HM) |
Compatibilità | L'engine deve garantire un'efficace ed ampia integrazione con le specifiche componenti HM e Hypervisor previste dal progetto di riferimento (rif. §4.3); in particolare deve essere in grado di eseguire (o far eseguire) le principali azioni sulle VM, fra cui almeno: • la creazione dell'istanza di VM, • la creazione di uno snapshot, • l'assegnazione o rimozione di indirizzi IP (pubblici o privati), • la sospensione, il soft reboot, l'hard reboot e la terminazione dell'istanza, • la riconfigurazione delle risorse virtuali utilizzate dall’istanza (fra cui almeno VCPU, RAM, capacità delle unità disco virtuali), • l'esecuzione di script di comandi di sistema sull'istanza | |
SW-TL-01/COM-02 | Compatibilità | L'engine deve poter orchestrare differenti tipologie di Hypervisor (e connessi Hypervisor Manager), fra cui almeno: • VMware vCenter / VMware vCloud Suite Standard, • Microsoft Hyper-V, • Linux KVM (Kernel-based Virtual Machine) |
SW-TL-01/COM-03 | Compatibilità | L'engine deve permettere di creare, gestire ed utilizzare (nella definizione dei workflow) un repository di file-immagine di VM. L'engine deve supportare differenti formati, fra cui almeno: • ISO 9660, • UDF (Universal Disk Format), • VHD (Virtual Hard Disk, da Microsoft), • VMDK (Virtual Machine Disk, da VMware), • formati raw (es. file ".img") |
Compatibilità | L'engine deve garantire un'efficace ed ampia integrazione con la componente SMC fornita; in particolare deve essere in grado di eseguire (o far eseguire) tutte le funzionalità esposte dalla componente, come da requisito XX-XX-00/XXX-00 | |
Compatibilità | L'engine deve garantire un'efficace ed ampia integrazione con la componente SDS fornita; in particolare deve essere in grado di eseguire (o far eseguire) tutte le funzionalità esposte dalla componente, come da requisito HW-ST-02/PRG-01 | |
Compatibilità | L'engine deve garantire un'efficace ed ampia integrazione con le componenti SDN fornite, sia in ambito Ethernet che FC; in particolare deve essere in grado di eseguire (o far eseguire) le funzionalità esposte dalle componenti, come da requisiti HW-NT-02/PRG-01 e HW-NT-04/PRG-01 | |
SW-TL-01/PRG-01 | Programmabilità | L'engine deve rendere disponibili modalità documentate e/o basate su protocolli aperti e/o standard (es. API, web services, e-mail) per l'esecuzione da remoto di funzionalità native o workflow programmati o per l'interazione application-to-application o application-to-human, da parte di attori esterni (applicazioni o persone) |
Codice | Categoria | Descrizione |
SW-TL-01/PRE-01 | Prestazioni | L'engine deve essere in grado di scalare sia verticalmente che orizzontalmente per permettere l’esecuzione di centinaia di processi contemporaneamente |
SW-TL-01/SIC-01 | Sicurezza | L'interfaccia utente dell'engine deve poter essere accessibile solo previa autenticazione, anche configurabile rispetto ad una fonte LDAP o Microsoft Active Directory esterna |
5.3.2.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare saranno oggetto di valutazione alcuni fattori migliorativi, secondo i criteri illustrati nelle schede seguenti.
Criterio | Descrizione breve | Requisiti interessati | |
VT-22 | Workflow di controllo della compliance | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
6,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), l'engine fornito deve permettere di disegnare workflow che implementino l'automazione di procedure di controllo della compliance, con eventuale remediation, delle VM e delle architetture rispetto a configurazioni standard e/o best practice definite dagli amministratori IT | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-23 | Disponibilità di librerie pre-costituite | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
6,0 | Discrezionale | Non applicabile | |
Note sulle modalità di valutazione | |||
Sarà oggetto di valutazione la disponibilità, all'interno della soluzione offerta dal Fornitore, di librerie pre-costituite di oggetti semantici rappresentativi di risorse infrastrutturali, applicative o custom, e di ulteriori altri elementi (quali azioni applicative o sistemistiche – es. invio email, invocazione web service, ecc. – o funzioni logiche complesse) utili ad accelerare i tempi di realizzazione e minimizzare la necessità di conoscenza di linguaggi di programmazione o markup come precondizione all'utilizzo. Il Fornitore dovrà pertanto illustrare la numerosità e la rilevanza degli oggetti inclusi in librerie pre-costituite fornite | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-24 | Interoperabilità nella progettazione dei workflow | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
6,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l'assegnazione del punteggio (massimo), l'engine fornito deve permettere il disegno di workflow attraverso modelli e linguaggi interoperabili aperti e/o standard, quali a titolo di esempio TOSCA (Topology and Orchestration Specification for Cloud Applications), al fine di supportare la portabilità delle procedure e dei servizi implementati durante il loro ciclo di vita. Il Fornitore dovrà specificare i modelli e linguaggi a tale scopo supportati | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-25 | Orchestrabilità delle risorse software-defined | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
8,0 | Discrezionale | Non applicabile | |
Note sulle modalità di valutazione | |||
Sarà oggetto di valutazione la capacità della specifica soluzione SDDC offerta dal Fornitore di | |||
fornire strumenti di gestione software-based quanto più estesamente potenti ed integrati fra | |||
loro. Il Fornitore dovrà pertanto illustrare il grado di integrazione e l'effettiva capacità di | |||
orchestrazione, in termini di numerosità e rilevanza delle funzionalità orchestrabili, da parte | |||
dell'OA Engine verso le singole componenti SDDC, secondo il framework di riferimento | |||
adottato: HM, Hypervisor, SMC, SDS, SDN (sia in ambito Ethernet che FC) | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-26 | Utilizzo di protocolli aperti e/o standard | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
6,0 | Discrezionale | Non applicabile | |
Note sulle modalità di valutazione | |||
Sarà oggetto di valutazione la capacità dell'engine di utilizzare protocolli aperti e/o standard nell'interazione con le componenti SDDC, e la numerosità e rilevanza dei protocolli supportati. Il Fornitore dovrà pertanto specificare i protocolli aperti e/o standard supportati per l'orchestrazione delle singole componenti secondo il framework di riferimento adottato: HM, Hypervisor, SMC, SDS, SDN (sia in ambito Ethernet che FC) | |||
Criterio | Descrizione breve | Requisiti interessati | |
VT-27 | Orchestrabilità delle risorse IT di tipo fisico | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
6,0 | Discrezionale | Non applicabile | |
Note sulle modalità di valutazione | |||
Sarà oggetto di valutazione la capacità dell'engine di orchestrare in maniera quanto più estesamente potente le risorse IT di tipo fisico (computing, storage e networking), sia rispetto alla soluzione completa effettivamente offerta dal Fornitore, sia più in generale sulla base dell'utilizzo di protocolli aperti e/o standard. Il Fornitore dovrà pertanto illustrare l'effettica capacità di orchestrazione, in termini di numerosità e rilevanza delle azioni sistemistiche eseguibili, da parte dell'OA Engine verso le risorse IT di tipo fisico, nonché specificare eventuali protocolli aperti e/o standard supportati a tale scopo | |||
5.3.3. SW-CL-01 – Cloud Service Platform
5.3.3.1. Descrizione
La Cloud Service Platform è la piattaforma che, posta on-top all’OA Engine (rif. §5.3.2) nel framework di riferimento (rif. §4.3), permette la gestione e l’erogazione dei servizi di tipo Cloud Computing, in particolare IaaS e PaaS, interagendo sia con gli amministratori IT che direttamente con gli utenti clienti.
Chiaramente rappresenta un bene SW; relativamente all’installazione, si può assumere che tutti i moduli necessari offerti dal Fornitore verranno installati (rif. §5.5.4) utilizzando parte delle risorse computazionali e di data storage dell’infrastruttura HW fornita, illustrate nel paragrafo 5.2.
Riprendendo lo schema di Figura 10 nel paragrafo 4.3, di seguito si illustrano brevemente le principali funzionalità richieste alla piattaforma, a cui si associano i requisiti tecnici specifici descritti nel sotto-paragrafo seguente.
Customer Portal
Il portale self-service è il punto di accesso e di fruizione dei servizi a catalogo esposti dalla piattaforma verso gli utenti clienti. In linea generale il portale deve presentare un’interfaccia personalizzabile, ma che risulti semplice e guidata, al fine di essere adeguata ad un’utenza con limitate conoscenze IT; deve inoltre
consentire, ai medesimi utenti e con la medesima facilità, di gestire autonomamente le risorse assegnate, per minimizzare il carico di lavoro tecnico in back-office e demandare quanto più possibile l’operatività.
Admin Portal
Esso rappresenta il punto di accesso e di gestione dei servizi esposti ed istanziati dalla piattaforma, dedicato agli amministratori dei servizi di tipo Cloud Computing. Per tramite del portale ed interagendo strettamente con la componente di OA Engine, la piattaforma deve permettere agli amministratori di progettare e pubblicare i servizi nel catalogo, attraverso l’utilizzo di un’interfaccia grafica e la definizione delle componenti del servizio e delle loro relazioni, sulla base della capacità della piattaforma di aggiungere un livello di astrazione delle risorse informatiche, che semplifichi la definizione di nuovi servizi nascondendone la sottostante complessità.
Catalogue
Il catalogo dei servizi (service catalogue) è l’elemento centrale per consentire agli utenti clienti (service consumer) di identificare, selezionare e attivare i servizi di loro intereresse. Il catalogo dei servizi definisce le offering di tipo As-a-Service che possono essere utilizzate da una definita organizzazione o gruppo di utenti (interagendo a tale scopo con la funzione di Profiling). Il catalogo dei servizi è un abilitatore della standardizzazione, favorendo l’utilizzo di un linguaggio comune nella rappresentazione dei servizi, che faccia convergere la vista funzionale degli utenti clienti con quella tecnica degli amministratori. In questo modo è possibile razionalizzare la domanda, limitando le opzioni in funzione di quanto effettivamente necessario agli utenti e non considerando le tecnologie sottostanti.
Profiling
Diverse finalità ed esigenze dei servizi As-a-Service, quali la strutturazione del portafoglio dei servizi, l’efficacia dell’approccio self-service, la gestione multi-tenancy, la sicurezza, ecc., richiedono che la piattaforma sappia identificare gli utenti e segmentarli, per organizzazioni o per profili, e che tale distinzione possa essere uno strumento a disposizione nella personalizzazione dell’offerta e nella gestione puntuale del “contratto” di servizio fra l’erogatore ed il fruitore.
Monitoring e Showback
Secondo i principi fondamentali del Cloud Computing, i servizi di tipo As-a-Service erogati devono essere caratterizzati da una misurabilità, ossia deve poter essere possibile tracciare (monitoring) e rendicontare (showback) i consumi di risorse informatiche associate all’erogazione e fruizione dei servizi. Tale controllo è in primo luogo una necessità per gli amministratori, dato che l’elasticità del modello rende difficile una pianificazione (ancorché rigida e conservativa) dei consumi totali massimi sostenibili/richiesti. Per quanto riguarda gli utenti fruitori, l’Ateneo ritiene estremamente importante quantificare e rendere visibili ai consumatori l’impiego di risorse connesse con i servizi richiesti, al fine di promuovere la domanda e l’uso dei servizi in maniera consapevole, nell’ottica del sistema Sapienza nel suo complesso, nonché per abilitare una più razionalizzata distribuzione delle risorse. Pertanto si richiede alla piattaforma anche la capacità di monetizzare, in base a tariffe configurabili, i consumi e di rendicontarli; non si richiede invece di supportare processi di fatturazione / ribaltamento (chargeback) degli importi economici dei consumi.
In termini di monitoring è inoltre molto importante controllare regolarmente lo stato dei servizi e darne evidenza agli utenti clienti ed agli amministratori, al fine di garantire la maggior continuità di erogazione possibile, sia rispetto ai servizi As-a-Service stessi forniti dalla piattaforma agli utenti clienti sia rispetto ad eventuali servizi da questi esposti verso i loro utenti finali (es.: su una macchina virtuale erogata in IaaS ad un referente di un Dipartimento dell’Ateneo – utente cliente – potrebbe essere installato un sito web fruito dagli studenti del Dipartimento stesso – utenti finali –).
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura e i criteri di valutazione tecnica previsti.
5.3.3.2. Requisiti
Codice | Categoria | Descrizione |
Tecnologia | La piattaforma deve mettere a disposizione un portale web-based per la fruizione dei servizi da parte degli utenti clienti, che permetta almeno le seguenti operazioni: • esposizione e navigazione del catalogo dei servizi, con funzionalità di ricerca; • sottomissione delle richieste di servizi; • visualizzazione dello stato di lavorazione delle richieste di servizi; • visualizzazione dello stato di funzionamento dei servizi istanziati; • visualizzazione e rendicontazione degli indicatori di consumo (istantanei e comulativi su periodo selezionabile) dei servizi istanziati, sia dimensionali che monetizzati | |
SW-CL-01/TEC-02 | Tecnologia | L'utente richiedente deve poter richiedere un servizio con attivazione schedulabile, sia per data di inizio che per durata / data di fine |
SW-CL-01/TEC-03 | Tecnologia | Attraverso la piattaforma, l'utente deve poter lanciare azioni (personalizzabili e definibili dall'amministratore a seconda delle esigenze) applicabili al servizio istanziato e relative alle componenti che lo compongono, quali a titolo di esempio non esaustivo: sistema operativo, applicazioni, middleware, database |
SW-CL-01/TEC-04 | Tecnologia | La piattaforma deve mettere a disposizione processi di gestione delle richieste sottomesse dagli utenti clienti, che permettano almeno le seguenti operazioni: • applicazione di workflow di approvazione manuale; • applicazione di workflow di approvazione automatica, sulla base di policy definibili dall'amministratore; • invio di notifiche agli utenti richiedenti relativi alle fasi di lavorazione delle richieste |
SW-CL-01/TEC-05 | Tecnologia | La piattaforma deve permettere la definizione di cataloghi di servizi applicabili a una o più organizzazioni o profili di utenti. Ogni utente può accedere esclusivamente ai cataloghi validi per la propria organizzazione o profilo |
SW-CL-01/TEC-06 | Tecnologia | La piattaforma deve mettere a disposizione degli amministratori un portale web-based per la definizione ed il monitoraggio dei servizi erogati, che permetta almeno le seguenti operazioni: • definizione dei servizi attraverso tool grafici evoluti (es. di tipo drag&drop); • definizione dei servizi attraverso l'uso di librerie di oggetti sematici rappresentativi di reali risorse infrastrutturali, applicative o custom (derivanti dall'integrazione con soluzioni di terze parti non incluse nella fornitura); • definizione e manutenzione del catalogo dei servizi; • profilazione degli utenti in base a raggruppamenti per organizzazione o per profilo; • monitoraggio dello stato di funzionamento dei servizi istanziati, con possibilità di ricerca e navigazione per organizzazione e per utente e con possibilità di intervento manuale per attivazioni/disattivazioni immediate; • monitoraggio e rendicontazione degli indicatori di consumo (sia istantanei che cumulativi su periodo selezionabile), totali oppure per organizzazione oppure per utente, sia dimensionali che monetizzati |
SW-CL-01/TEC-07 | Tecnologia | Integrandosi con le capacità richieste alla componente OA Engine (si veda il requisito SW-TL-01/TEC-08), la piattaforma deve permettere agli amministratori la possibilità di definire servizi basati su ambienti fisici, con sistemi operativi Microsoft e Linux (nel caso di risorse di computing) |
SW-CL-01/TEC-08 | Tecnologia | La piattaforma deve permettere la definizione di servizi, in termini di contenuti (es. presenza o meno di determinate componenti, quali a titolo puramente indicativo DBMS, firewall, ecc.) e di caratteristiche (fra le quali almeno il tipo e la versione del sistema operativo) e di dimensioni (fra le quali almeno la quantità di VCPU, di RAM e di data storage), sia completamente predeterminati sia parzialmente configurabili dall'utente richiedente, attraverso la selezione da insiemi di opzioni disponibili preconfigurate dall'amministratore |
Codice | Categoria | Descrizione |
Tecnologia | Integrandosi con le capacità richieste alla componente OA Engine (si veda il requisiti SW-TL-01/TEC-05), la piattaforma deve permettere la definizione di servizi basati su modelli complessi di tipo infrastrutturale o applicativo. In particolare, in caso di servizi IaaS, deve essere possibile definire servizi che istanzino architetture a più livelli (es. presentation / front-end, business logic / middleware, database / back-end) e/o più architetture contemporaneamente (es. ambienti di sviluppo, test e produzione) | |
SW-CL-01/TEC-10 | Tecnologia | Integrandosi con le capacità richieste alla componente OA Engine (si veda il requisiti SW-TL-01/TEC-07), la piattaforma deve permettere di organizzare in partizioni le risorse IT utilizzate nella definizione ed istanziazione dei servizi. Tali partizioni devono essere disponibili per la definizione dei servizi a catalogo |
SW-CL-01/TEC-11 | Tecnologia | Integrandosi con le capacità richieste alla componente OA Engine (si veda il requisiti SW-TL-01/TEC-07), la piattaforma deve permettere la gestione di quote di consumo per organizzazioni e/o profili utente e/o partizioni di risorse IT, ossia di limiti massimi non superabili (in maniera bloccante o con margini di tolleranza predefiniti) sui principali indicatori di consumo relativi alle risorse consumate, includendo almeno: • numero di istanze di servizi, • numero di VM, • numero di VCPU, • capacità di RAM, • capacità di data storage, • numero di IP pubblici, • numero di network (intesi come spazi di indirizzamento), • consumi monetizzati |
SW-CL-01/TEC-12 | Tecnologia | La piattaforma deve permettere la definizione di indicatori di consumo associabili ai servizi e/o a loro singole componenti (es. VM, VCPU, RAM), sia quando predeterminate che quando parzialmente configurabili dall'utente. Ogni indicatore deve poter essere espresso sia in formato dimensionale proprio della sua natura (es. numerosità oppure quantità consumata secondo l'unità di misura specifica – quali GB, Mhz, ecc.) sia in formato monetizzato secondo la definizione di tariffe unitarie da parte dell'amministratore |
SW-CL-01/TEC-13 | Tecnologia | La piattaforma deve calcolare automaticamente gli indicatori totali applicati ad ogni singolo servizio istanziato, aggregando tutti gli indicatori di consumo (sia dimensionali che monetizzati) che si applicano al servizio stesso e a tutte le sue singole componenti |
SW-CL-01/TEC-14 | Tecnologia | La piattaforma deve esporre agli utenti clienti il catalogo dei servizi comprensivo degli indicatori di consumo e delle tariffe che si applicano ai singoli servizi e/o componenti fruibili |
SW-CL-01/TEC-15 | Tecnologia | I dati relativi alla rendicontazione dei consumi, sia destinati agli utenti clienti che agli amministratori, devono essere esportabili in formato elettronico, sia in formato grafico (es. formato PDF, HTML, ecc.) sia in formato elaborabile (es. CSV, XLS, ecc.) |
Tecnologia | La piattaforma deve permettere ad utenti clienti ed amministratori l'accesso remoto alle console di amministrazione delle VM istanziate, sia in modalità grafica che a riga di comando (es. Linux SSH e Microsoft Windows Powershell) | |
SW-CL-01/PRG-01 | Programmabilità | La piattaforma deve permettere agli amministratori di personalizzare il portale a livello di look & feel a seconda delle organizzazioni che accedono ai servizi |
SW-CL-01/SIC-01 | Sicurezza | La piattaforma deve poter integrare con molteplici LDAP e con Microsoft Active Directory, per l'autenticazione degli utenti ai portali web-based esposti |
SW-CL-01/SIC-02 | Sicurezza | La piattaforma deve supportare l'accesso in modalità sicura (cifrata) ai portali web-based (i.e. via HTTPS), ed alle console di amministrazione di cui al requisito SW-CL-01/TEC-16 |
Codice | Categoria | Descrizione |
SW-CL-01/SIC-03 | Sicurezza | Il software fornito deve essere immune da vulnerabilità conosciute, con riferimento in particolare alla lista Top 10 OWASP 2013, redatta da Open Web Application Security Project (xxx.xxxxx.xxx) |
5.3.3.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare sarà oggetto di valutazione il fattore migliorativo illustrato nelle scheda seguente.
Criterio | Descrizione breve | Requisiti interessati | |
VT-28 | Condivisione del servizio fra più utenti | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
4,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l'assegnazione del punteggio (massimo), la piattaforma deve consentire ad un utente cliente di richiedere un servizio e di abilitare la sua fruizione (sia come gestione del servizio che come accesso remoto alle VM) da parte di altri utenti clienti facenti parte, ad esempio, di un medesimo team di lavoro | |||
5.4. Accessori
5.4.1. AC-CP-01 – Console KVM
5.4.1.1. Descrizione
Da un punto di vista implementativo, la Console KVM (Keyboard-Video-Mouse) è da intendersi costituita da un’infrastruttura aggregante diversi apparati HW, ciascuno conteggiato come singola unità, distribuiti all’interno dei rack dei due data center di cui si prevede l’impiego nel progetto di riferimento (eccetto i rack di permuta), come indicato nel paragrafo 4.2.
Tale infrastruttura deve connettere in organizzazione gerarchica “a cascata”, cosidetta daisy chain, i vari apparati, i quali vengono distinti, ai fini del presente Capitolato, in tre moduli funzionali diversi:
• i Moduli Satellite, a cui si collegano gli apparati esterni all’infrastruttura, quali server, storage, switch, ecc., rispetto ai quali viene appunto remotizzata la funzionalità di console KVM – nel seguito si parlerà di apparati controllati;
• i Moduli Master, che comandano ed accentrano le funzioni dei Moduli Satellite, rendendo disponibili le funzionalità di console KVM agli utenti operatori;
• i Moduli Tastiera-Video-Mouse (TVM), con cui qui nello specifico si intendono le unità HW composte da tastiera, video e mouse messe a disposizione di un utente operatore che lavori in loco.
Si richiede che le interconnessioni (comprese nella fornitura) fra i moduli dell’infrastruttura e gli apparati controllati rappresentino un “network” dedicato indipendente, di tecnologia a scelta del Fornitore, separato dai network di tipo Ethernet sia di produzione che di management già presentati nel corso del documento. I Moduli Master vanno comunque connessi al network di tipo Ethernet di management, al fine di garantire il requisito di remotizzabilità delle funzionalità di console via IP, come specificato nel seguito; a tale scopo, si può assumere che i Moduli Master siano installati nei rack di storage.
Quanto finora esposto è sintetizzato nello schema in Figura 14. Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura.
Figura 14 – Schema di realizzazione ed interconnessione dell’infrastruttura della Console KVM
5.4.1.2. Requisiti
Codice | Categoria | Descrizione |
AC-CP-01/GEN-01 | Generale | Nell'ambito dell'appalto è richiesta la fornitura di un'infrastruttura di Console KVM formata da: • almeno 18 unità di Moduli Satellite più 2 unità di Moduli Master, ossia in generale un modulo per ogni rack (eccetto quello di permuta) di cui si prevede l’impiego nel progetto di riferimento (rif. §4.2), con un Modulo Master per sito; • almeno 4 unità di Moduli TVM, da distribuirsi equamente fra i due siti; • tutte le connessioni necessarie fra i Moduli e verso tutti gli apparati controllati effettivamente forniti nell’ambito dell’appalto; • la cavetteria necessaria per collegare ulteriori apparati controllati di tipo legacy (non inclusi nella fornitura), in numerosità di almeno 30 apparati con tastiera e mouse su connettori standard PS/2 e almeno 30 apparati con tastiera e mouse su connettori standard USB di tipo A |
AC-CP-01/GEN-02 | Generale | Ad ogni componente dell'infrastruttura di Console KVM si applicano i requisiti: |
Codice | Categoria | Descrizione |
AC-CP-01/GEN-03 | Generale | I Moduli Satellite devono essere collegati fra loro e con il Modulo Master secondo uno schema gerarchico "in cascata" (daisy chain), attraverso interconnessioni fisiche, senza perdita di porte utili. Le interconnessioni fisiche fra i Moduli e verso gli apparati controllati devono essere dedicate, di tecnologia a scelta del Fornitore, e separate dai network di tipo Ethernet sia di produzione che di management |
AC-CP-01/TEC-01 | Tecnologia | Ogni Modulo Master deve poter rendere disponibile le proprie funzioni di console KVM in maniera remotizzata, attraverso protocollo IP-based |
AC-CP-01/TEC-02 | Tecnologia | Ogni Modulo Satellite deve garantire una collegabilità, verso il generico singolo apparato controllato, che supporti connettori – lato apparato – secondo gli standard VGA, PS/2, USB di tipo A e Seriale a 9 pin (a prescindere dall’effettiva presenza e utilizzo dei connettori lato apparato controllato) |
AC-CP-01/TEC-03 | Tecnologia | Ogni Modulo Satellite e ogni Modulo Master deve essere in grado di riconoscere e gestire automaticamente (autoscan) gli apparati controllati collegati. Il collegamento verso gli apparati deve essere supportato in modalità hot-plug, ove tecnicamente applicabile |
AC-CP-01/TEC-04 | Tecnologia | Ogni Modulo TVM deve essere di tipo estraibile |
AC-CP-01/TEC-05 | Tecnologia | Ogni Modulo TVM deve presentare un ingombro massimo di 1 rack unit |
AC-CP-01/CER-01 | Generale | Ad ogni componente dell'infrastruttura di Console KVM si applica il requisito |
AC-CP-01/CAP-01 | Capacità | Ogni Modulo Satellite e ogni Modulo Master deve poter controllare almeno 24 apparati |
AC-CP-01/COM-01 | Compatibilità | Ogni Modulo TVM deve supportare risoluzioni video almeno pari a 1920 x 1440 e compatibili con lo standard DDC (Display Data Channel) |
AC-CP-01/COM-02 | Compatibilità | Ogni Modulo deve essere compatibile con tutti i principali sistemi operativi di mercato, senza richiedere installazione di driver a carico degli apparati controllati |
AC-CP-01/SIC-01 | Sicurezza | L'accesso al Modulo TVM deve poter essere accessibile solo previa autenticazione |
5.4.1.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
5.4.2. AC-NT-01 – Cablaggio della Rete Dati dei Data Center
Da un punto di vista implementativo, il cablaggio completo della rete dati è da intendersi costituito da un sistema composto da diversi componenti, in grado di implementare fisicamente tutte le connessioni previste dal progetto di riferimento (rif. §4.1) e meglio dettagliate nei precedenti paragrafi del capitolo 5.
In particolare, il sistema di cablaggio dovrà implementare, all’interno di ogni data center:
o gli apparati Blade Server, Blade Chassis, SAN, Piattaforma di Virtualizzazione dello Storage e lo Switch DC Ethernet, attraverso gli Apparati di Distribuzione Ethernet per Blade e/o gli Switch Rack Ethernet laddove previsto;
o lo Switch DC Ethernet e gli Switch Rack Ethernet dei rack per legacy e per future espansioni;
o lo Switch DC Ethernet e l’apparato core di firewall e la Piattaforma DWDM;
• tutte le connessioni di tipo FC, ridondate, richieste fra (si veda anche il paragrafo 5.2.10.1):
o gli apparati Blade Server, Blade Chassis, SAN, Piattaforma di Virtualizzazione dello Storage e lo Switch FC, attraverso gli Apparati di Distribuzione FC per Blade laddove previsto;
o lo Switch FC e lo switch FC legacy;
o lo Switch FC e la Piattaforma DWDM.
A questo si aggiunge la necessità di realizzare un cablaggio strutturale di base anche verso tutti i restanti rack previsti fisicamente nei due data center (24 per INFO0 e 12 per INFO2 – rif. §4.2), secondo i requisiti nel seguito descritti.
Sinteticamente di individuano, nel sistema di cablaggio richiesto, tre differenti componenti:
• gli apparati Patch Panel, ossia i device passivi di raccordo fra le diverse sezioni di cablaggio, ognuno dei quali conteggiato come singola unità, corredati ciascuno di moduli a cassetti per l’attestazione dei cavi e di accessori passacavi orizzontali;
• i cavi Trunk Cable, ossia cavi per l’interconnessione aggregata fra Patch Panel di rack differenti;
• i cavi Patch Cord, ossia cavi per l’interconnessione puntuale fra porte (di apparati e/o di Patch Panel).
Figura 15 – Schema di realizzazione del cablaggio della rete dati dei data center
Come schematizzato in Figura 15, il sistema di cablaggio deve essere realizzato secondo i seguenti criteri:
• in ogni rack (eccetto quelli di permuta) deve essere installato almeno un Patch Panel;
• eventuali connessioni dirette fra apparati installati nel medesimo rack devono essere implementate con Patch Cord attestati sugli apparati stessi;
• ogni connessione fra due apparati (che chiameremo A e B) installati su rack differenti (es. da uno Switch Rack Ethernet ad uno Switch DC Ethernet) deve essere implementata:
o collegando, tramite Patch Cord, l’apparato A con un Patch Panel del medesimo rack;
o collegando, tramite Trunk Cable, il Patch Panel del rack in cui risiede l’apparato A con un Patch Panel installato nel rack di permuta;
o collegando, tramite Patch Cord, l’apparato B con un Patch Panel del medesimo rack;
o collegando, tramite Trunk Cable, il Patch Panel del rack in cui risiede l’apparato B con un Patch Panel installato nel rack di permuta;
o collegando, tramite Patch Cord, le porte dei Patch Panel installati nel rack di permuta, corrispondenti alla permutazione necessaria.
Come meglio precisato nei requisiti tecnici a seguire, la soluzione richiesta dall’Ateneo si basa su fibre ottiche di tipo OM4 50/125, con terminatori MPO e LC e commutazioni fisiche a bassa perdita di inserzione (insertion loss), e su cavi in rame di tipo UTP (Unshielded Twisted Pair) Categoria 6 o superiore, con terminatori RJ45.
Di seguito si esplicitano i requisiti tecnici richiesti per la fornitura.
5.4.2.2. Requisiti
Codice | Categoria | Descrizione |
AC-NT-01/GEN-01 | Generale | Nell'ambito dell'appalto è richiesta la fornitura di un sistema di cablaggio della rete dati dei data center formata da: • unità Patch Panel da 1 rack unit con relativi moduli a cassetti ed associati accessori passacavi orizzontali (uno per ogni Patch Panel), • cavi Trunk Cable in fibra ottica per l'interconnessione fra i Patch Panel dei singoli rack ed i Patch Panel del rack di permuta, • cavi Patch Cord in fibra ottica per la connessione degli apparati nei rack verso i Patch Panel del medesimo rack, • cavi Patch Cord in fibra ottica per la realizzazione delle permutazioni fra i Patch Panel del rack di permuta, • cavi Patch Cord in fibra ottica o in rame per le connessioni fra apparati interne ad i singoli rack, secondo quanto previsto dal progetto di riferimento. |
AC-NT-01/GEN-02 | Generale | Ad ogni componente del sistema di cablaggio si applicano i requisiti: |
AC-NT-01/TEC-01 | Tecnologia | Ogni Trunk Cable fornito deve essere costituito da un cavo di fibra ottica di tipo OM4 50/125 con terminatori di tipo MPO, composto da almeno 24 fibre. Il cavo deve essere pre-terminato in fabbrica su un unico terminatore per parte e rivestito da guaina ULSZH (Universal Low Smoke Zero Halogen) |
AC-NT-01/TEC-02 | Tecnologia | Ogni Patch Cord in fibra ottica deve essere costituito da un cavo di fibre di tipo OM4 50/125 con terminatori di tipo LC, composto da almeno 2 fibre |
AC-NT-01/TEC-03 | Tecnologia | Ogni Patch Cord in rame deve essere costituito da un cavo di tipo UTP (Unshielded Twisted Pair) Categoria 6 o superiore con terminatori di tipo RJ45 |
AC-NT-01/TEC-04 | Tecnologia | Ogni Patch Panel deve essere equipaggiato con moduli a cassetti pre-cablati per connessioni di tipo MPO-LC, per la connessione rispettivamente fra Trunk Cable di tipo MPO e Patch Cord di tipo LC |
AC-NT-01/TEC-05 | Tecnologia | Le commutazioni fisiche devono garantire una perdita d’inserzione (insertion loss) non superiore a 0,25 dB |
AC-NT-01/CER-01 | Certificazioni | Ad ogni componente del sistema di cablaggio si applica il requisito |
XX-XX-00/XXX-00 | Certificazioni | Ogni componente dell'intero sistema di cablaggio deve essere verificato e testato per garantire i requisiti prestazionali richiesti dagli standard ISO/IEC 11801 e TIA/EIA-568C |
Codice | Categoria | Descrizione |
AC-NT-01/AMM-01 | Amministrazione | La fornitura di cavi Patch Cord deve rispettare una differenziazione cromatica che distingua almeno i seguenti impieghi: • cavi per flussi di tipo Ethernet interni ai data center (anche quelli che passano attraverso la Piattaforma DWDM), • cavi per flussi di tipo FC interni al data center (anche quelli che passano attraverso la Piattaforma DWDM), • cavi per flussi verso l'esterno del data center (es. verso gli apparati core) |
5.4.2.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
5.5. Servizi
Nella presente sezione del documento vengono dettagliati gli elementi della fornitura che rappresentano i servizi professionali funzionali al raggiungimento dell’obiettivo dell’appalto.
In particolare, fra i servizi indicati si distinguono:
• tutte le attività di natura progettuale, volte ad implementare ed avviare in funzione l’infrastruttura durante la fase iniziale del contratto, fino al collaudo dell’infrastruttura stessa (rif. §6) – attività complessivamente indicate come Progetto di Implementazione;
• il servizio di manutenzione e assistenza per 5 anni, che è l’unico a doversi espletare dopo il collaudo dell’infrastruttura e appunto per un periodo prolungato nel tempo.
Si noti che l’attività di collaudo, facente parte integrante del Progetto di Implementazione menzionato, non è stata indicata esplicitamente come oggetto della fornitura, perché intrinsecamente connessa e prevista dalle norme contrattuali (si rimanda all’art. 6 del Capitolato d’oneri), anche in virtù delle disposizioni di legge a riguardo.
Il documento è di seguito così strutturato:
• il paragrafo 5.5.1 presenta alcuni requisiti generali comuni per tutti i servizi professionali richiesti al Fornitore;
• nei paragrafi dal 5.5.2 al 5.5.7 vengono illustrate le caratteristiche delle singole attività previste all’interno del Progetto di Implementazione;
• nel paragrafo 5.5.8 viene invece illustrato il servizio di manutenzione e assistenza.
Codice | Categoria | Descrizione |
SR-GN-01/CER-01 | Certificazioni | Il Fornitore deve essere il produttore dei prodotti offerti nella soluzione o, in alternativa, deve presentare certificazioni aziendali di partnership tecniche di livello intermedio o superiore, rilasciate dal produttore e valide al momento della presentazione dell'Offerta Tecnica |
SR-GN-01/CER-02 | Certificazioni | Per le attività tecniche previste dal Progetto di Implementazione, il cui know- how sia strettamente correlato alle caratteristiche di prodotto dell'elemento della fornitura offerta dal Fornitore, questi dovrà allocare risorse professionali in possesso di certificazioni tecniche personali di livello intermedio o superiore, rilasciate dal produttore o da enti accreditati e valide al momento dell'esecuzione dell'attività |
5.5.2. SR-PR-01 – Project Management
5.5.2.1. Descrizione
L’attività di Project Management pone in capo al Fornitore l’onere di garantire che il Progetto di Implementazione venga avviato, eseguito e completato in maniera controllata e gestita, in modo tale da assicurare:
• rispetto di tempistiche e costi preventivati;
• qualità dei risultati, in particolare rispetto al soddisfacimento dei requisiti espressi dal committente;
• gestione tempestiva ed adeguata di xxxxxx e criticità.
Da ciò ne consegue l’impegno da parte del Fornitore nell’allocare risorse adeguate, per numero e qualità, sia professionali che strumentali e nell’adottare metodologie e pratiche di comprovata efficacia e attendibilità.
L’attività implica tutte le azioni tipiche della conduzione di progetti IT, fra cui, a titolo indicativo non esaustivo:
• gestione dell’ambito (scope) del progetto;
• pianificazione delle attività;
• organizzazione degli incontri di avvio (kick-off), di avanzamento e di chiusura del progetto;
• monitoraggio e rendicontazione degli avanzamenti delle attività e dei risultati prodotti;
• gestione delle risorse umane (del Fornitore) allocate;
• gestione di rischi e criticità e delle procedure di escalation.
Nell’espletamento di queste azioni il Fornitore dovrà interagire con il Centro Infosapienza, per tramite delle figure professioni a tal scopo predisposte, fra cui in particolare si segnalano:
• il Responsabile del Procedimento, come definito dalla normativa vigente;
• il Direttore dell’Esecuzione del Contratto, come definito dalla normativa vigente;
• i tecnici responsabili e/o esperti delle singole aree tecnologiche;
• il Responsabile della Sicurezza delle Informazioni (Security Manager), da intendersi come il referente del sistema di gestione della sicurezza delle informazioni ai sensi dello standard ISO27001, nei limiti di quanto eventualmente afferente all’oggetto della fornitura.
5.5.2.2. Requisiti
Codice | Categoria | Descrizione |
Generale | Il Progetto di Implementazione condotto dal fornitore deve rispettare i seguenti vincoli relativi alle tempistiche di esecuzione delle attività ed alle principali milestone progettuali: • l'avvio delle attività deve avvenire entro 10 giorni lavorativi dalla data di stipula del contratto, formalizzato attraverso un incontro formale del gruppo di lavoro del progetto (kick-off meeting); • la redazione del Piano esecutivo di dettaglio delle attività (si veda requisito SR-PR-01/GEN-05) deve avvenire entro 10 giorni dalla data di stipula del contratto; • la consegna dei beni oggetto della fornitura deve avvenire entro 30 giorni lavorativi dalla data di stipula del contratto; • le attività di collaudo a piano (dall'avvio alla conclusione, escluse le attività propedeutiche al collaudo) non possono esaurirsi in meno di 10 giorni lavorativi (elapsed time); • le attività di formazione (rif. §5.5.7) devono essere svolte preliminarmente al collaudo (il quale di fatto deve essere l'ultima attività progettuale a piano) e non possono esaurirsi in meno di 20 giorni lavorativi (elapsed time); • il progetto deve concludersi complessivamente entro 70 giorni lavorativi dalla data di stipula del contratto |
Codice | Categoria | Descrizione |
Generale | La pianificazione delle attività progettuali deve rispettare il vincolo della finestra di lavoro garantita dall'Ateneo, pari a 9 ore giornaliere (dalle 8:30 alle 17:30), dal lunedì al venerdì, esclusi i giorni festivi, salvo eccezioni concordate preventivamente fra le Parti | |
Generale | Il Fornitore deve allocare le risorse professionali che ritiene più opportune per il raggiungimento degli obiettivi del Progetto di Implementazione, nel rispetto dei vincoli sulle tempistiche di esecuzione delle attività e dei vincoli sulle certificazioni professionali personali necessarie. In particolare il team di lavoro deve includere: • un Contract Manager, che si interfaccerà con il Responsabile del Procedimento dell'Ateneo nella gestione complessiva del contratto e dei problemi al massimo livello di escalation; • un Project Manager, responsabile della gestione operativa del progetto, del suo monitoraggio e rendicontazione e della sua qualità, che si interfaccerà con il Direttore dell’Esecuzione del Contratto dell'Ateneo | |
Generale | Il Fornitore deve adottare metodologie e pratiche di organizzazione del lavoro e di gestione dei progetti IT che siano di comprovata efficacia e attendibilità, in modo da: • predisporre una struttura organizzativa di progetto con un'identificazione chiara ed efficace di ruoli e responsabilità da parte del Fornitore; • attuare un sistema di qualità degli artefatti (sia documentali che fisici) prodotti dalle attività di progetto | |
Generale | L'attività deve produrre, in fase esecutiva, almeno i seguenti documenti (deliverable): • Piano esecutivo di dettaglio delle attività (GANTT), • Report di Stato Avanzamento Lavori (SAL) con cadenza quindicinale, • Relazione Finale di Collaudo |
5.5.2.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di descrivere l’organizzazione di risorse e attività proposte per l’esecuzione del Progetto di Implementazione, al fine di consentire la valutazione tecnica della bontà e congruità della soluzione proposta.
In particolare saranno oggetto di valutazione i parametri indicati nella scheda seguente.
Criterio | Descrizione breve | Requisiti interessati | |
VT-29 | Modalità di organizzazione di risorse e attività | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
10,0 | Discrezionale con soglia | 3,0 | |
Note sulle modalità di valutazione | |||
Rispetto al Progetto di Implementazione presentato dal Fornitore, saranno oggetto di valutazione: • le caratteristiche e l’organizzazione di ruoli, responsabilità e risorse previste dal Fornitore; • l’organizzazione del lavoro e la pianificazione (anche in formato Gantt) delle attività proposte; • le metodologie di lavoro adottate ed il sistema di qualità previsto, sia relativamente alla documentazione dei contenuti del progetto che alla supervisione e monitoraggio delle attività ed ai meccanismi di controllo dei deliverable prodotti | |||
5.5.3. SR-PR-02 – Trasporto e Consegna Materiali
5.5.3.1. Descrizione
Il servizio prevede il trasporto e la consegna dei materiali oggetto della fornitura all’Ateneo, comprendendo tutte le attività a tal scopo necessarie, di qualsiasi natura (logistica, amministrativa, fiscale, ecc.), fino al posizionamento di ogni unità di materiale nella sua posizione di destinazione all’interno dei data center del
Centro Infosapienza; il servizio comprende anche la gestione e lo smaltimento degli imballi utilizzati per il trasporto.
5.5.3.2. Requisiti
Codice | Categoria | Descrizione |
SR-PR-02/GEN-01 | Generale | Le attività di trasporto e consegna dei materiali devono essere tutte a carico del Fornitore, fino al collocamento nella sua posizione di destinazione all'interno del data center di ogni unità di materiale fornito. In particolare, qualsiasi onere economico, amministrativo e burocratico necessario a tale scopo sarà a carico del Fornitore, comprese la predisposizione e l'impiego delle necessarie attrezzature per l'introduzione del materiale nei data center; si rimanda la paragrafo 2.2 del Capitolato Tecnico per ulteriori note relative alle modalità per trasportare il materiale dentro i locali dei data center INFO0 e INFO2 |
SR-PR-02/GEN-02 | Generale | Il Centro Infosapienza fornirà supporto, coordinandosi con il Fornitore, per garantire permessi di accesso e spazi di manovra all'interno delle sedi universitarie; in tali aree l'operato del Fornitore dovrà attenersi alle indicazioni ricevute dai referenti dell'Ateneo ed in particolare a tutto quanto prescritto nel Documento Unico di Valutazione dei Rischi da Interferenza (DUVRI), facente parte della documentazione di gara |
SR-PR-02/GEN-03 | Generale | Rimane a carico del Fornitore la gestione del materiale di imballaggio a seguito della consegna dei beni della fornitura, ossia la raccolta, la rimozione e lo smaltimento, secondo le normative vigenti, entro 2 giorni lavorativi dalla loro produzione |
SR-PR-02/GEN-04 | Generale | In caso di rigetto di beni HW da parte dell’Ateneo, per evidenti condizioni di non-integrità in fase di consegna o per mancato collaudo (rif. §6), il Fornitore sarà obbligato a rimuovere e ritirare dalle sedi dell’Ateneo tutto il materiale interessato, a propria cura e spese e sotto la propria responsabilità, entro 10 giorni solari dalla data di notifica formale dell’evento. L’Ateneo non risponderà di furti durante la permanenza dei beni rifiutati né di altre cause di danneggiamento dovute ad eventuali incidenti o disastri naturali |
5.5.4. SR-PR-03 – Installazione e Configurazione
5.5.4.1. Descrizione
Il servizio rappresenta il cardine del Progetto di Implementazione, in quanto è finalizzato all’effettiva realizzazione dell’infrastruttura (in tutte le componenti, sia HW che SW) proposta dal Fornitore, sulla base del progetto esecutivo di massima (rif. §5.1) presentato in sede di Offerta Tecnica e di un progetto esecutivo di dettaglio definito dal Fornitore in fase di esecuzione dell’appalto.
Il servizio racchiude tutte le attività di natura organizzativa, logistica e tecnica, necessarie per installare ed interconnettere (sia alla rete dati che alla rete di alimentazione) tutte le risorse informatiche fornite nell’ambito dell’appalto, verificarne singolarmente il funzionamento ed attivare la soluzione integrata HW e SW proposta.
5.5.4.2. Requisiti
Codice | Categoria | Descrizione |
SR-PR-03/DOC-01 | Documentazione | L'attività deve produrre, in fase esecutiva, almeno il seguente documento (deliverable): • Progetto Esecutivo di Dettaglio della soluzione installata |
SR-PR-03/DOC-02 | Documentazione | Per ogni bene o prodotto installato il Fornitore deve rilasciare la documentazione di prodotto in Italiano o in Inglese e la manualistica tecnica di amministrazione, emesse dal produttore, in formato elettronico |
Codice | Categoria | Descrizione |
SR-PR-03/DOC-03 | Documentazione | Al termine dell'installazione il Fornitore deve rilasciare un inventario completo (tipo/modello/serial number) di tutti i beni o prodotti forniti, in formato elettronico |
SR-PR-03/DOC-04 | Documentazione | Al termine dell'installazione il Fornitore deve rilasciare una certificazione dei requisiti prestazionali richiesti al cablaggio della rete dati dei singoli data center, secondo dagli standard ISO11801 e TIA/EIA568C. Il Fornitore deve altresì rilasciare una documentazione completa dello schema di cablaggio implementato, che includa in particolare la nomenclatura delle porte (assegnata sulla base di naming convention indicata dall’Ateneo in fase esecutiva) e lo schema delle permute fra le porte |
SR-PR-03/GEN-01 | Generale | Durante l'attività il Fornitore verrà affiancato da personale tecnico del Centro Infosapienza, affinchè questi possa sviluppare la massima consapevolezza della soluzione in corso di realizzazione, partecipare tempestivamente ad ogni decisione progettuale operativa ed acquisire in modalità training-on-the-job competenze tecniche sulle tecnologie e sui prodotti |
5.5.5. SR-PR-04 – Estensione Fabric FC Esistente
5.5.5.1. Descrizione
Il servizio è volto specificatamente ad assicurare e realizzare una completa interoperabilità fra il network FC parte della fornitura ed il network FC attualmente presente nell’ambito dell’infrastruttura esistente presso il Centro Infosapienza, come già illustrato nel paragrafo 2.4.
Le attività, che hanno come obiettivo e come criterio di verifica del corretto completamento un’effettiva estensione del network FC esistente secondo i requisiti indicati nel paragrafo seguente, dovranno tecnicamente essere organizzate e condotte secondo modalità conseguenti e coerenti con le scelte tecnologiche proposte dal Fornitore in sede di Offerta Tecnica, ossia più concretamente in funzione della posizione assunta dal Fornitore rispetto ai temi:
• network (apparati) di distribuzione FC per blade,
• velocità di trasmissione dati sulla rete FC,
• convergenza fra connettività di tipo FC e quella di tipo Ethernet, ed ai relativi fattori premianti previsti dall’Ateneo.
Per ulteriori dettagli si rimanda al paragrafo 4.1 ed alle sezioni del paragrafo 5.2 dedicati alle singole risorse in questione.
5.5.5.2. Requisiti
Codice | Categoria | Descrizione |
SR-PR-04/GEN-01 | Generale | L’attività deve garantire l’implementazione delle opportune connessioni e configurazioni affinché, nell’ambito dell’interoperabilità fra i network FC, ogni dato presente su SAN (sia esistente che di nuova fornitura) sia accessibile in lettura e scrittura da ogni server / Blade Server (sia esistente che di nuova fornitura) |
SR-PR-04/GEN-02 | Generale | L’attività deve garantire l’implementazione delle opportune configurazioni affinché, nell’ambito dell’estensione del network FC esistente, l’organizzazione della zonatura (i.e. Fabric) attualmente adottata sia preservata e resa operativa anche nel nuovo network FC fornito, senza interruzioni dei servizi attualmente erogati |
SR-PR-04/DOC-01 | Documentazione | L'attività deve produrre, in fase esecutiva, almeno il seguente documento (deliverable): • Specifiche di Interconnessione con Fabric FC Esistente |
5.5.6. SR-PR-05 – Predisposizione al Collaudo
5.5.6.1. Descrizione
Come indicato nel paragrafo 6, l’intera fornitura sarà oggetto di attività di collaudo, sia nell’ambito dei singoli beni forniti che a livello di intera infrastruttura IT progettata.
Data la complessità di integrazione delle singole componenti previste nella soluzione e l’introduzione di appositi strumenti SW volti all’implementazione di nuove modalità di gestione dell’infrastruttura e delle sue risorse, l’approccio al collaudo previsto dal Centro Infosapienza prevede la creazione e configurazione di workflow (rif. §5.3.2.1) di test ad hoc (su indicazioni dell’Ateneo), nell’ambito del Software-Defined Data Center e del Cloud Management (rif. §4.3), in grado di attivare e testare tutte le componenti dell'infrastruttura installata (HW e SW – fisica e virtuale).
Il servizio in oggetto racchiude quindi tutte le attività necessarie propedeutiche a siffatta procedura di collaudo.
5.5.6.2. Requisiti
Codice | Categoria | Descrizione |
SR-PR-05/DOC-01 | Documentazione | L'attività deve produrre, in fase esecutiva, almeno i seguenti documenti (deliverable): • Specifiche di Sviluppo dei Workflow (propedeutici al collaudo), • Piano di dettaglio (GANTT) dei test di collaudo, • Test Script per le verifiche di collaudo |
SR-PR-05/GEN-01 | Generale | Il Fornitore è tenuto a svolgere tutte le attività propedeutiche al collaudo dell’intera fornitura, sia nell’ambito dei singoli beni forniti che a livello di intera infrastruttura IT progettata |
SR-PR-05/GEN-02 | Generale | L'attività deve produrre un insieme minimo di configurazioni, workflow e altri oggetti necessari, allo scopo di poter testare e collaudare il funzionamento dell'infrastruttura in termini SDDC. Gli scenari d'uso per i test verranno concordati in fase esecutiva fra il Fornitore ed il Centro Infosapienza, garantendo che tali scenari permetteranno di: • collaudare l'installazione ed il funzionamento delle componenti OA Engine e CSP; • collaudare il funzionamento integrato delle diverse componenti del framework di gestione software-based, in particolare l'effettiva orchestrazio- ne da parte dell'OA Engine delle componenti sottostanti (HM, Hypervisor, SMC, SDS, SDN e mondo fisico). A titolo di esempio indicativo e non esaustivo, si indicano come possibili scenari d'uso di riferimento: • la creazione a catalogo di una risorsa IaaS costituita da un'architettura a tre livelli (che coinvolga tutte le componenti infrastrutturali) e la sua creazione automatizzata; • la definizione e l'esecuzione schedulata di attività sistemistiche su risorse esistenti sia di tipo computing che storage e networking; • la simulazione di condizioni di failover / moving delle risorse pilotato fra i due data center |
5.5.7.1. Descrizione
Il servizio ha lo scopo di corredare la fornitura dei beni dell’infrastruttura IT con le adeguate nozioni tecnico- professionali necessarie alla sua gestione e conduzione post-collaudo e a regime, da parte del Centro Infosapienza.
Oltre ad un affiancamento di tipo training-on-the-job già previsto nell’ambito del servizio di Installazione e Configurazione (rif. §5.5.4), si richiede la predisposizione e l’erogazione di un piano di formazione di tipo tradizionale, in aula, sui diversi ambiti tecnologici e prodotti offerti dal Fornitore nella soluzione.
Il piano dovrà prevedere un’adeguata flessibilità nelle tempistiche, per consentire ai diversi referenti del Centro Infosapienza coinvolti, di poter partecipare fruttuosamente a tutti i percorsi formativi di interesse (che possono essere più di uno per singola persona).
5.5.7.2. Requisiti
Codice | Categoria | Descrizione |
SR-PR-O6/GEN-01 | Generale | L'attività deve prevedere l'erogazione di un piano di formazione diviso in 4 aree tematiche, così strutturato: • Area Computing: corso avanzato sulle procedure e sugli strumenti di gestione e controllo delle risorse del dominio computing installate nella fornitura, con particolare enfasi sulle funzionalità delle componenti SMC. Il corso deve prevedere una durata minima pari a 3 giorni; • Area Storage: corso avanzato sulle procedure e sugli strumenti di gestione e controllo delle risorse del dominio storage installate nella fornitura, con particolare enfasi sulle funzionalità delle componenti SDS. Il corso deve prevedere una durata minima pari a 3 giorni; • Area Network: corso avanzato sulle procedure e sugli strumenti di gestione e controllo delle risorse del dominio network installate nella fornitura, con particolare enfasi sulle funzionalità delle componenti DWDM e SDN. Il corso deve prevedere una durata minima pari a 3 giorni; • Area Software: corso integrato di livello avanzato sulle funzionalità delle componenti OA Engine e di livello introduttivo sulle funzionalità delle componenti CSP installate nella fornitura. Il corso deve prevedere una durata minima pari a 5 giorni |
SR-PR-O6/GEN-02 | Generale | I corsi di formazione devono essere condotti da docenti qualificati, in aula, presso i locali dell'Ateneo, il quale si farà carico di tutta l'organizzazione logistica di supporto; si può assumere che ogni sessione di formazione preveda la partecipazione di un numero di discenti non superiore a 20 unità. La pianificazione dei corsi dovrà essere concordata in fase esecutiva fra il Fornitore ed il Centro Infosapienza, pur nel rispetto dei vincoli di pianificazione generale del Progetto di Implementazione |
SR-PR-O6/GEN-03 | Generale | I corsi devono essere erogati esclusivamente in Italiano |
SR-PR-O6/GEN-04 | Generale | Per ogni area tematica il Fornitore dovrà rilasciare all'Ateneo il materiale didattico utilizzato durante i corsi erogati, in formato elettronico. Il materiale deve essere redatto esclusivamente in Italiano o Inglese |
5.5.8. SR-CM-01 – Manutenzione e Assistenza per 5 Anni
Ogni bene HW e SW, anche di natura accessoria, oggetto della fornitura deve essere coperto da un servizio di manutenzione ed assistenza che garantisca supporto continuo da parte del Fornitore e/o del produttore per:
• mantenere il bene adeguatamente aggiornato in termini di livelli di sicurezza informatica e di affidabilità, attraverso il rilascio di patch o service pack;
• intervenire on-site su chiamata per la diagnosi (troubleshooting) e la risoluzione di guasti o malfunzionamenti, prevedendo ove necessario la riparazione o la sostituzione delle parti interessate;
• indagare e risolvere su chiamata anomalie (anche presunte) di funzionamento o di configurazione o di compatibilità con altri componenti dell’infrastruttura;
• rispondere a richieste di servizio, ossia fornire informazioni di natura tecnica e non urgente, su funzionamento, caratteristiche e configurazioni dei beni forniti e sulla soluzione installata;
• mantenere il bene fornito allineato rispetto allo sviluppo di prodotto, attraverso la possibilità di aggiornamento alle minor release rilasciate sulle componenti software (sia nel caso di beni propriamente SW che di beni HW integrati da utility SW, es. utility di gestione, firmware, SW embedded, ecc.);
• mantenere i singoli beni e l’intera soluzione in buone condizioni di esercizio, attraverso una manutenzione preventiva regolare, che includa, fra le varie operazioni, la verifica e pulitura delle ventole e la pulitura o sostituzione dei filtri dell’aria. Le modalità di esecuzione di tale manutenzione dovranno escludere ogni intervento che sia intrusivo rispetto ai servizi erogati dall’Ateneo attraverso l’infrastruttura.
In particolare, nel primo anno di esercizio della soluzione, a seguito del collaudo, l’Ateneo si attende una fisiologica maggiore incidenza delle problematiche sopra elencate; si richiede pertanto che il servizio metta a disposizione un monte di giorni/uomo da dedicarsi appositamente alla risoluzione di problemi e ad un fine tuning della soluzione complessiva, su tutte le tecnologie ed i prodotti offerti.
Come specificato dal requisito SR-CM-01/GEN-03, in caso di incidenti, il servizio deve prevedere un livello di servizio (Service Level Agreement – SLA) di tipo 9x5 con tempi di intervento il giorno lavorativo successivo (Next Business Day – NBD); è considerato un fattore premiante la garanzia di tempi di intervento entro 4 ore lavorative, come indicato nel sotto-paragrafo a seguire relativo ai criteri di valutazione tecnica.
Per tempo di intervento si intende il tempo lavorativo che intercorre fra il momento in cui l’Ateneo avanza una richiesta di manutenzione e assistenza al Fornitore attraverso i canali di comunicazione da questi messi a disposizione ed il momento in cui il Fornitore avvia le azioni necessarie per la diagnosi e la risoluzione, dandone evidenza all’Ateneo (condizione essenziale ai fini del computo); si precisa che la sola conferma di ricezione della richiesta da parte del Fornitore e le sole attività di registrazione della richiesta e di pre- qualifica iniziale non rappresentano un’azione significativa ai fini del computo.
5.5.8.2. Requisiti
Codice | Categoria | Descrizione |
SR-CM-01/GEN-01 | Generale | Il servizio deve essere attivo per 5 (cinque) anni solari consecutivi a decorrere dalla data di collaudo dell'infrastruttura fornita, certificata dal Progetto di Implementazione |
SR-CM-01/GEN-02 | Generale | Il servizio, in caso di rilascio di aggiornamenti, integrazioni e parti nuove, dei beni soggetti alla manutenzione, deve prevedere esclusivamente l'impiego di prodotti originali, certificati dal produttore del bene stesso manutenuto |
SR-CM-01/GEN-03 | Generale | Il servizio deve prevedere la possibilità di richiedere assistenza e manutenzione attraverso contatti sia di posta elettronica (e/o web) che telefonici, disponibili 24 ore al giorno per 365 giorni l’anno. In caso di richiesta avanzata dall’Ateneo fuori dalla finestra di servizio (si veda requisito SR-CM- 01/GEN-04), ai fini del computo del tempo di intervento, questa sarà da considerarsi aperta il primo minuto del primo giorno lavorativo utile successivo alla data della richiesta stessa. Il Fornitore deve inoltre appositamente prevedere un contatto telefonico dedicato a procedure di escalation |
Generale | Il servizio deve essere erogato con un livello di servizio di tipo Next Business Day (NBD), ossia con finestra di servizio giornaliera di almeno 9 ore (dalle 8:30 alle 17:30), dal lunedì al venerdì ed esclusi sabato, domenica e festivi, e tempo di intervento (come definito nel paragrafo 5.5.8.1 del Capitolato Tecnico) entro il giorno lavorativo successivo alla chiamata, per le richieste relative a guasti, malfunzionamenti e anomalie (anche presunte). Per le richieste di servizio il tempo di intervento deve essere di massimo 3 giorni lavorativi | |
SR-CM-01/GEN-05 | Generale | La manutenzione preventiva inclusa nel servizio deve prevedere interventi sistematici e periodici, con cadenza almeno semestrale, per l’intera durata del servizio |
Codice | Categoria | Descrizione |
SR-CM-01/GEN-06 | Generale | Il servizio deve garantire, durante il primo anno solare a decorrere dalla data di collaudo dell'infrastruttura fornita, la disponibilità di un monte di almeno 20 (venti) giorni/uomo, per servizi integrativi da dedicarsi appositamente alla risoluzione di problemi e ad un fine tuning della soluzione complessiva, su tutte le tecnologie ed i prodotti offerti, in base alle esigenze che verranno rilevate ed espresse dall’Ateneo in fase di esercizio della soluzione |
SR-CM-01/GEN-07 | Generale | Il Fornitore deve rappresentare il responsabile unico nella gestione dell’intero ciclo di vita di ogni richiesta / intervento nell’ambito del servizio di manutenzione e assistenza per l’intero periodo contrattuale. A tale scopo il Fornitore dovrà predisporre un punto unico di contatto. Il servizio deve in ogni caso garantire il supporto diretto del produttore dei beni HW e SW oggetto del servizio stesso. In particolare, in relazione alle risorse SW: • Per le componenti OA Engine e CSP, il servizio di manutenzione e assistenza non può essere erogato da fornitori di risorse HW in modalità OEM (Original Equipment Manufacturer) o analoghe; • Per tutte le componenti SW integrate nelle risorse HW, il servizio deve garantire il lecito trasferimento all’Ateneo del diritto di accesso / download / utilizzo delle licenze d’uso e degli aggiornamenti e/o patch correttive per tali componenti |
5.5.8.3. Criteri di valutazione tecnica
In sede di Offerta Tecnica, al Fornitore è richiesto di esplicitare tutte le informazioni della soluzione offerta per l’elemento della fornitura in oggetto che siano rilevanti ed adeguate per una corretta verifica del rispetto dei requisiti tecnici richiesti e per una corretta valutazione tecnica da parte dell’Ateneo.
In particolare sarà oggetto di valutazione il fattore migliorativo illustrato nella scheda seguente.
Criterio | Descrizione breve | Requisiti interessati | |
VT-30 | Tempi di intervento per manutenzione e assistenza | ||
Punteggio massimo | Modalità di valutazione | Punteggio minimo di soglia | |
12,0 | Tabellare SI-NO | Non applicabile | |
Note sulle modalità di valutazione | |||
Per l’assegnazione del punteggio (massimo), il servizio erogato deve garantire tempi di intervento entro le 4 ore lavorative successive alla chiamata, per le richieste relative a guasti, malfunzionamenti e anomalie (anche presunte) | |||
6. Collaudo
L’Ateneo sottoporrà a verifica di conformità (collaudo) ogni bene e servizio rilasciato dal Fornitore nell’ambito dell’appalto, secondo quanto previsto dall’art. 6 del Capitolato d’oneri.
La verifica comprenderà tutte le ispezioni, prove e misure che saranno ritenute opportune dal Centro Infosapienza per accertare che ogni componente rilasciata sia stata realizzata a regola d’arte e in completo accordo con le specifiche del presente Capitolato e con quanto dichiarato nell’Offerta Tecnica dal Fornitore.
In particolare saranno oggetto di verifica di conformità, anche a campione per quota parziale:
• i singoli beni HW e SW forniti;
• l’intera infrastruttura IT, in termini di effettiva integrazione e interoperabilità nell’ambito del Software- Defined Data Center, secondo i termini e l’approccio esposto nel paragrafo 5.5.6.
Il Fornitore darà il necessario supporto tecnico a tutte le attività di verifica di conformità.
Come indicato nel paragrafo 5.5, le attività di collaudo saranno parte integrante del Progetto di Implementazione, da pianificarsi e condursi nel rispetto dei requisiti ivi espressi. Al termine delle operazioni di verifica, in caso di esito positivo il Centro Infosapienza emetterà il conseguente certificato di verifica di conformità, con l’indicazione analitica delle attività svolte e delle risultanze delle ispezioni, prove e misure eseguite; copia del documento sarà consegnata al Fornitore.
Nel caso in cui la verifica non dia esito positivo, il Centro Infosapienza comunicherà al Fornitore, mediante una formale richiesta di adeguamento, tutte le carenze, le difformità o gli inconvenienti riscontrati. Il Fornitore dovrà realizzare – entro i termini fissati dall’Ateneo – gli adeguamenti o le sostituzioni richieste, darne comunicazione per iscritto al Centro Infosapienza e sottoporsi ad una nuova verifica di conformità. Tale procedura potrà essere ripetuta fino a due volte consecutive nel caso in cui la verifica non dia esito positivo; superato tale limite l’Ateneo procederà a mettere in atto le azioni più opportune previste dalle condizioni contrattuali a garanzia del rispetto dei requisiti di gara.
Tutti gli oneri e le spese di verifica sono a carico del Fornitore.
7. Penali
Nel presente capitolo si riportano le penali contrattuali applicabili al Fornitore in caso di rilevata e documentata inadempienza della fornitura rispetto a livelli di servizio fissati e condivisi. Ogni criterio presenta una natura numerica e misurabile.
Per ogni penale viene fornita una descrizione in forma tabellare riportante le seguenti informazioni:
• il codice identificativo composito della penale,
• una descrizione breve della penale,
• il periodo di riferimento usato come base di calcolo della penale,
• una descrizione estesa dell’importo della penale previsto e delle modalità di calcolo,
• eventuali note sulle modalità di calcolo o sul dominio di applicazione,
• il codice dei requisiti con fattori di qualità (uno o più) a cui è applicabile la penale.
Per le condizioni contrattuali relative alla disciplina delle penali, si rimanda all’art. 5 del Capitolato d’oneri.
Codice | Descrizione breve | Periodo | |
PN-01 | Mancato rispetto dei tempi limite delle principali milestone progettuali | Mensile | |
Descrizione di dettaglio | Note sulle modalità di calcolo | Requisiti interessati | |
Penale di euro 1.000,00 (mille/00) per ogni giorno solare di ritardo rispetto ai limiti di tempo imposti per il raggiungimento delle singole principali milestone del Progetto di Implementazione indicate nel paragrafo 5.5.2 del Capitolato Tecnico: • data di avvio delle attività progettuali, • consegna del Piano esecutivo di dettaglio delle attività, • consegna dei beni oggetto della fornitura, • data di conclusione del progetto | Il ritardo è riferibile al numero di giorni intercorsi fra la data di stipula del contratto e la data di effettivo raggiungimento (certificato dall’Ateneo) della milestone, confrontato con il numero di giorni limite fissato dal requisito interessato per le milestone considerate | ||
Codice | Descrizione breve | Periodo | |
PN-02 | Tempo di intervento per incidenti non conforme | Trimestrale | |
Descrizione di dettaglio | Note sulle modalità di calcolo | Requisiti interessati | |
Penale di euro 250,00 (duecentocinquan- ta/00) per ogni giorno lavorativo (9 ore) di ritardo nel tempo di intervento, per ogni singola richiesta relativa a guasti, malfunzionamenti e anomalie (anche presunte), che non rispetti i limiti garantiti dallo SLA offerto dal Fornitore (entro 9 o 4 ore lavorative dalla richiesta) | Per la definizione dello SLA e di tempo di intervento si veda la descrizione del requisito interessato. Il conteggio dei tempi è calcolato solo durante la finestra di servizio definita, mentre è sospeso al di fuori di essa | ||
Codice | Descrizione breve | Periodo | |
PN-03 | Tempo di intervento per richieste di servizio non conforme | Trimestrale | |
Descrizione di dettaglio | Note sulle modalità di calcolo | Requisiti interessati | |
Penale di euro 100,00 (cento/00) per ogni giorno lavorativo (9 ore) di ritardo nel tempo di intervento, per ogni singola richiesta di servizio, che non rispetti i limiti fissati dall’Ateneo (entro 3 giorni lavorativi dalla richiesta) | Per la definizione di tempo di intervento si veda la descrizione del requisito interessato. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa | ||