ASSESSORATO DELL’IGIENE E SANITÀ E DELL’ASSISTENZA SOCIALE DIREZIONE GENERALE DELLA SANITÀ

SERVIZIO SISTEMA INFORMATIVO, OSSERVATORIO EPIDEMIOLOGICO, CONTROLLO DI QUALITA’ E GESTIONE DEL RISCHIO

Progetto cofinanziato dall’Unione Europea Fondo Europeo di Sviluppo Regionale

POR FESR Sardegna 2007-2013 Linea di Azione 1.2.1.a

Integrazione di reti professionali al fine di agevolare i processi di continuità assistenziale e di migliorare l’efficienza e l’efficacia delle attività di prevenzione, diagnosi e cura

Progetto INFRAS ICT

Completamento dell’INFRAstruttura ICT del

intervento

procedura

Sistema Informativo Integrato della Sanità Regionale

Procedura aperta soprasoglia comunitaria per l’affidamento dell’appalto “INFRAS ICT – Completamento dell’INFRAStruttura ICT del Sistema Informativo Integrato della Sanità Regionale – Adeguamento hardware e software di base”

documento Allegato Tecnico

Stazione appaltante:

Regione Autonoma della Sardegna – Assessorato dell’igiene e sanità e dell’assistenza sociale – Servizio sistema informativo, osservatorio epidemiologico umano, controllo di qualità e gestione del rischio

sede: Xxx Xxxx, 000 – 00000 Xxxxxxxx

[INFRAS ICT]

Procedura aperta soprasoglia comunitaria per l’affidamento dell’appalto “INFRAS ICT – Completamento dell’INFRAStruttura ICT del Sistema Informativo Integrato della Sanità Regionale – Adeguamento hardware e software di base”

Allegato Tecnico (allegato al Capitolato Tecnico)

Acronimi e definizioni

Acronimo Descrizione

ANAGS Anagrafe Sanitaria Assistibili Regione Sardegna

AS Azienda Sanitaria

AOU Azienda Ospedaliero-Universitaria

AO Azienda Ospedaliera

ASL Azienda Sanitaria Locale

CO Centrale Operativa

CRESSAN Centro Regionale dei Servizi informatici e telematici per il sistema SANitario RAS Regione Autonoma della Sardegna

RTR Rete Telematica Regionale

SISaR Sistema Informativo della Sanità Regionale

SLA Service Level Agreement

SSN Servizio Sanitario Nazionale

ASHRAE American Society of Heating, Refrigerating, and Air-Conditioning Engineers

INFRAS-CED

Progetto “Adeguamento delle sale CED presso le Aziende Sanitarie Locali della Sardegna n. 3-8, l’Azienda Ospedaliera Brotzu di Cagliari e le Aziende Ospedaliere Universitarie di Cagliari e Sassari”

Altri termini usati e definizioni

Termine Descrizione

Disciplinare di gara

Si intende il documento che contiene tutte le informazioni relative alle condizioni ed alle modalità di redazione e presentazione delle offerte, alle cause di esclusione e di decadenza, ai criteri di aggiudicazione, nonché agli obblighi dell’aggiudicatario per la stipula del contratto

Capitolato tecnico

Si intende il documento che contiene le specifiche teniche dell’oggetto dell’appalto, integrate dall’Allegato Tecnico (presente documento).

Si intende Regione Autonoma della Sardegna - Assessorato dell’igiene e sanità e dell’assistenza

Stazione appaltante

Aggiudicatario ovvero Appaltatore

Amministrazione Regionale o RAS

Assessorato dell’Igiene e Sanità, ovvero Assessorato Sanità, ovvero Assessorato

sociale – Servizio Servizio sistema informativo, osservatorio epidemiologico umano, controllo di qualità e gestione del rischio

Si intende il soggetto aggiudicatario del presente appalto Si intende la Regione Autonoma della Sardegna

Si intende l’Assessorato dell’Igiene e Sanità e dell’Assistenza Sociale della Regione Autonoma della Sardegna

Sommario

Premessa 5

1 Progetto di adeguamento ASL n°1 di Sassari 6

1.1 Contesto di riferimento 6

1.2 Obiettivi 7

1.3 Interventi 7

1.3.1 Consolidamento e virtualizzazione 7

1.3.2 Estensione dello storage dei sistemi aziendali 8

1.3.3 Gestione centralizzata dei processi di backup-restore 9

1.4 Riepilogo della fornitura 9

2 Progetto di adeguamento ASL n°2 di Olbia 11

2.1 Contesto di riferimento 11

2.2 Obiettivi 12

2.3 Interventi 12

2.3.1 Consolidamento e virtualizzazione 12

2.3.2 Ridondanza del sistema Firewall di frontiera 14

2.4 Riepilogo della fornitura 15

3 Progetto di adeguamento ASL n°3 di Nuoro 16

3.1 Contesto di riferimento 16

3.2 Obiettivi 18

3.3 Interventi 18

3.3.1 Licenze VMware a completamento della virtualizzazione 19

3.3.2 Realizzazione tratta FO tra Ospedale Xxxxxxxxx (HZ) e Ospedale San Xxxxxxxxx (HSF) 22

3.4 Riepilogo della fornitura 24

4 Progetto di adeguamento ASL n°4 di Lanusei 25

4.1 Contesto di riferimento 25

4.2 Obiettivi 29

4.3 Interventi 30

4.3.1 Potenziamento infrastruttura virtuale del data center 30

4.3.2 Adeguamento sistema di connettività (firewall e intranet data center) 34

4.3.3 Sistema centralizzato di raccolta log e controllo accessi 41

4.3.4 Armadio ignifugo per conservazione di backup 43

5 Progetto di adeguamento ASL n°5 di Oristano 45

5.1 Contesto di riferimento 45

5.2 Obiettivi 46

5.3 Interventi 46

5.3.1 Consolidamento e virtualizzazione 46

5.3.2 Virtualizzazione postazioni di lavoro 48

6 Progetto adeguamento ASL n°7 di Carbonia 49

6.1 Contesto di riferimento 49

6.2 Obiettivi 49

6.3 Interventi 49

6.3.1 Sostituzione switch centro stella sala server 50

6.3.2 Collegamento radio CED – CTO - X. Xxxxxxx 50

6.3.3 Sostituzione apparati di sicurezza 51

7 Progetto adeguamento ASL n°8 di Cagliari 52

7.1 Contesto di riferimento 52

7.2 Obiettivi 53

7.3 Interventi 53

7.3.1 Potenziamento apparati di rete centro stella 53

7.3.2 Adeguamento della sicurezza della rete geografica 54

8 Progetto adeguamento AO X. Xxxxxx 56

8.1 Contesto di riferimento 56

8.2 Obiettivi 59

8.3 Interventi 59

8.3.1 Completamento dei processi di salvataggio dati 59

8.3.2 Sistema centralizzato di gestione dei Log 61

9 Progetto adeguamento AOU di Cagliari 63

9.1 Contesto di riferimento 63

9.2 Obiettivi 63

9.3 Interventi 64

9.3.1 Potenziamento infrastruttura di rete 64

9.3.2 Attivazione servizi di desktop management 67

10 Progetto adeguamento AOU di Sassari 69

10.1 Contesto di riferimento 69

10.2 Obiettivi 71

10.3 Interventi 71

10.3.1 Sistema di monitoraggio della rete 71

10.3.2 Sistema di Intrusion detection di rete 72

11 Progetto adeguamento Assessorato dell’Igiene e Sanità e dell’Assistenza Sociale 73

11.1 Contesto di riferimento 73

11.2 Obiettivi 74

11.3 Vincoli 74

11.4 Interventi 75

11.4.1 Consolidamento e virtualizzazione 75

11.4.2 Estensione dello storage e gestione backup 76

11.4.3 Attrezzature informatiche per la mobilità 77

11.5 Specifiche tecniche di riferimento 77

11.5.1 Moduli switch 77

11.5.2 Server blade per la virtualizzazione 78

11.5.3 Server blade per l’installazione del Virtual Center e del VCB 78

11.5.4 Sistema di storage 78

11.5.5 Attrezzature informatiche per il lavoro in mobilità 79

11.5.6 Licenze software 81

11.6 Riepilogo della fornitura 81

Premessa

Il presente allegato contiene le richieste di fornitura pervenute dalle Aziende Sanitarie, dall’Azienda Ospedaliera Brotzu, dalle Aziende Ospedaliero-Universitarie e dall’Assessorato dell’Igiene e Sanità e dell’Assistenza Sociale della Regione Sardegna - relative all’adeguamento della propria infrastruttura ICT nell’ambito degli interventi previsti dal progetto INFRAS ICT – ed ha lo scopo di illustrare all’Offerente i contesti aziendali e le motivazioni per cui le esigenze si sono manifestate, per meglio provvedere, unitamente ai previsti sopralluoghi obbligatori, alla redazione della propria Offerta.

Per ciascuna Azienda Sanitaria, Azienda Ospedaliero-Universitaria, Azienda Ospedaliera e per l’Assessorato viene di seguito dedicato un intero capitolo, nel quale è riportata in maniera integrale la proposta di soluzione progettuale da essi pervenuta.

Sebbene la descrizione delle soluzioni tecnologiche sia utile all’identificazione delle specifiche esigenze da soddisfare, essa è da intendersi in maniera puramente indicativa e non vincolante. Tali soluzioni tecnologiche potranno quindi essere variate, uniformate e migliorate da soluzioni equivalenti o superiori, ma sempre nel rispetto delle funzionalità attese ed eventualmente rappresentate dai prodotti hardware e software ove indicati a titolo esemplificativo e di riferimento.

Tuttavia, laddove esista un vincolo tecnologico tale per cui la fornitura dovrà prevedere esclusivamente quello e soltanto quello specifico prodotto, nel corso del presente documento ciò verrà esplicitamente segnalato con la notazione di requisito specifico del tipo [RsY].

Pertanto, qualora nel corso del documento dovessero comparire requisiti di tale tipologia, non presenti o diversamente espressi nel Capitolato tecnico, si tenga presente che i primi hanno valenza specifica e superiore e di maggior dettaglio.

Analogamente, laddove nel presente documento dovessero essere espresse funzionalità non conciliabili con i requisiti generali di cui al Capitolato tecnico e ciò non venga segnalato con la notazione di requisito specifico, deve essere considerato prevalente il requisito generale.

Infine, anche ciò che non è esplicitamente segnalato come requisito generale del Capitolato tecnico ovvero come requisito specifico del presente allegato, è comunque da considerarsi contenuto dell’appalto e concorre alla valutazione generale dell’Offerta da parte della commissione giudicatrice.

1 Progetto di adeguamento ASL n°1 di Sassari

In questo capitolo sono riportate le soluzioni tecnologiche e le specifiche tecniche e funzionali relative alla proposta progettuale di adeguamento delle infrastrutture hardware/software presentata dall’Azienda Sanitaria Locale n°1 di Sassari nell’ambito del Progetto INFRAS ICT.

Nella tabella seguente si riporta l’elenco degli interventi e la tipologia. Con la tipologia O (Obbligatorio) sono identificati gli interventi obbligatori nel bando di gara, con la tipologia IPX (Intervento premiante numero X) sono invece indicati quelli opzionali/premianti.

Interventi INFRAS ICT ASL 1 Sassari priorità

Consolidamento e virtualizzazione dei sistemi aziendali O

Estensione dello storage dei sistemi aziendali O

Gestione centralizzata dei processi di backup-restore O

Tabella 1 Riepilogo interventi e priorità ASL 1

1.1 Contesto di riferimento

In concomitanza alle iniziative condotte a livello regionale con i progetti SISaR, MEDIR, SILUS, RTP, etc. l’Azienda Sanitaria ASL 1 di Sassari ha intrapreso un processo di rimodernizzazione del Sistema Informativo Aziendale, consentendo il raggiungimento di un livello di qualità ed affidabilità che pone l’azienda non solo tra le prime a livello regionale, ma anche tra quelle che possono costituire “best practice” a livello nazionale, come testimoniano alcune indagini svolte da Istituti di ricerca sull’ e-Health (x.xx. l’Osservatorio di Sanità Elettronica del Politecnico di Milano).

Nonostante il superamento di molte delle criticità rilevate in passato, l’Azienda continua il percorso intrapreso manifestando la necessità di consolidare il lavoro svolto e realizzare altre azioni progettuali, soprattutto sul fronte dell’assistenza territoriale e della diffusione delle pratiche informatizzate nell’area clinica (x.xx. digitalizzazione dei referti, cartella clinica elettronica, etc.).

Relativamente a questa azienda, il progetto INFRAS ICT intende affrontare il tema del consolidamento dei sistemi informatici realizzando alcuni interventi ritenuti prioritari.

Il "parco sistemi" della ASL 1 è caratterizzato attualmente da un elevato numero di macchine, generalmente fornite e gestite dai produttori di applicazioni. Ogni applicazione serve aree funzionali distinte, molte delle quali ad alta criticità in termini di requisiti e di disponibilità dei servizi.

Per alcuni sottosistemi sono presenti ambienti di produzione clusterizzati e/o macchine aggiuntive attivabili in caso di fault delle principali.

Ogni produttore richiede inoltre un particolare ambiente dedicato: sistemi operativi differenti, diversi livelli di patch, sistemi di storage dedicati e salvataggio dati gestiti con software e metodologie diverse.

Il risultato è stato nel tempo un inevitabile proliferare di sistemi hardware generalmente sfruttati solo parzialmente, dall’alto costo di possesso. Questo perché tali sistemi necessitano, una volta fuori garanzia, di contratti di manutenzione specifici e costi di gestione e manutenzione che scaturiscono da un numero elevato di risorse in gioco sia umane che non.

1.2 Obiettivi

Obiettivo principale del progetto di consolidamento dei sistemi informatici della ASL 1 è:

▪ la riduzione dei costi di gestione della Server Farm aziendale, a partire dalla riduzione del numero di apparecchiature utilizzate.

In questo contesto si intendono risolvere sia problematiche legate ad aspetti strettamente “fisici” e logistici – primo tra tutti il consumo energetico, il quale è statisticamente generato per circa il 70% da server che utilizzano mediamente solo un 5-10% della capacità elaborativa disponibile – sia problematiche connesse alla gestione operativa dei sistemi.

Le tecnologie di supporto alle strategie di consolidamento sono volte ad ottimizzare l’uso delle risorse hardware attraverso l’implementazione di meccanismi di astrazione che consentono di “simulare” l’esecuzione di un sistema server completo – hardware e software – svincolandolo di fatto dalla macchina fisica che lo ospita.

Questa tecnica, nota come “virtualizzazione dei sistemi”, ha favorito inoltre un incremento di affidabilità dei sistemi e una semplificazione degli strumenti finalizzati all’erogazione in continuità dei servizi.

La diffusione e il successo della virtualizzazione sono risultati dell’evoluzione delle architetture dei sistemi di calcolo e delle tecnologie di storage che rappresentano un elemento chiave dell’infrastruttura di un sistema virtuale di classe “Enterprise”.

Si rende quindi necessario anche per la ASL 1 affrontare il tema del consolidamento dei propri server nel contesto di un progetto specifico che tenga conto dei mutamenti tecnologici in atto e degli interventi di revisione architetturale da effettuare.

1.3 Interventi

Gli interventi previsti nell’ambito del progetto INFRAS ICT saranno meglio dettagliati nei paragrafi successivi.

1.3.1 Consolidamento e virtualizzazione

La virtualizzazione rappresenta quindi una scelta strategica strettamente legata al consolidamento dei server che ben si adatta all’odierna evoluzione del mercato.

La soluzione individuabile per la ASL 1 non è omogenea perché esistono situazioni in cui i requisiti prestazionali o l’utilizzo di risorse e/o periferiche esterne è tale da richiedere hardware fisico dedicato, mentre in altri casi sarebbe possibile raggruppare più istanze applicative.

Il consolidamento di alcuni sistemi su macchine virtuali ospitate su un numero ridotto di macchine fisiche si è comunque dimostrata efficiente in un’ottica di garanzia delle prestazioni, nella semplificazione della gestione e soprattutto nella capacità di adattamento della struttura IT alle esigenze in continuo mutamento.

Considerata la gradualità nell’approccio alla virtualizzazione necessaria nel contesto della ASL 1, si ritiene preferibile optare per la soluzione basata su un’infrastruttura Blade.

La Asl 1 ha circa 45-50 server che possono essere consolidati e virtualizzati.

In base alle analisi di performance sui sistemi in produzione si considerano sufficienti N. 7 lame blade VMware + 1 aggiuntiva che consentirà di bilanciare il carico in caso di caduta di un nodo.

A corredo delle 8 lame previste per la gestione del carico applicativo è necessario destinare due ulteriori macchine al sistema di gestione (Virtual Center), e al salvataggio dati (backup delle VM). Una ulteriore macchina, già in dotazione alla ASL, sarà destinata alla gestione dei sistemi (System Management, gestione e configurazione dello storage).

1.3.2 Estensione dello storage dei sistemi aziendali

Le esigenze di un’organizzazione complessa come la ASL 1 relativamente agli strumenti di gestione dell’archiviazione dati sono molteplici:

▪ gestione dello spazio disco in alta affidabilità per i numerosi applicativi installati;

▪ disponibilità di storage meno pregiato per i dati utente;

▪ salvataggio dei dati da realizzarsi con un sistema di backup efficiente e veloce.

La scelta dello storage deve tener conto della necessità di soluzioni di continuità operativa e/o disaster recovery. Sarebbe auspicabile, per la ASL 1, una soluzione integrata costituita da uno storage multiservizio che consenta l’eliminazione dei file server e supporti l’accesso ai server in modalità FCP o ISCSI. Inoltre, è opportuno che la virtualizzazione dei server sia affiancata da soluzioni di virtualizzazione dello storage per ottenere una maggiore flessibilità nella gestione dei volumi.

Con il crescere delle applicazioni infatti, la gestione tradizionale delle unità di archiviazione, che prevede l’assegnazione dei volumi ad array specifici, portano ad un’elevata frammentazione e quindi a spreco elevato di risorse disco. Una soluzione virtualizzata in cui viene generato un pool di volumi gestibili dinamicamente consente, oltre ad un’elevata flessibilità, un considerevole risparmio di spazio disco.

Nell’ambito di un’infrastruttura virtualizzata per la ASL 1 lo storage deve soddisfare vari requisiti, con particolare riferimento a quelli necessari a garantire livelli di affidabilità elevatissimi:

▪ controller e storage adapter ridondati;

▪ path ridondati tra server e storage che garantiscano continuità di servizio trasparente in caso di rottura di adattatori e/o controller;

▪ schede di rete ridondate;

▪ alimentazioni ridondate;

▪ supporto RAID;

▪ supporto per ambienti eterogenei (sistemi operativi diversi);

▪ espandibilità.

Si ritiene inoltre importante la disponibilità di strumenti e tecnologie per:

▪ gestire efficientemente copie di salvataggio di interi volumi, file e dati applicativi (ad es. attraverso la tecnica delle “snapshot”)

▪ implementare, nel contesto di un eventuale soluzione di disaster recovery, la replica dei dati tra storage diversi (sincrona, semisincrona o asincrona, a seconda delle diverse esigenze applicative e funzionali) per mezzo di protocolli Fiber Channel o ISCSI su connessioni FC e TCP/IP.

Anche l’impiego di tecniche di compressione (dette di “deduplicazione”) che rimuovono dati ridondanti all’interno di un sistema può contribuire significativamente ad ottimizzare la gestione delle risorse di archiviazione. In particolare questa tecnica, ampiamente diffusa nei sistemi di backup, è utile per ridurre l’occupazione di spazio dei sistemi operativi che nei sistemi virtualizzati è significativa. I vantaggi sono poi rilevanti nel contesto del trasferimento di dati tra siti remoti tipico di soluzioni di distaster recovery e nei sistemi di backup/restore per ottenere operazioni di restore efficienti.

Per realizzare la gestione centralizzata dello storage aziendale si prevede di utilizzare un sistema dimensionato per 20 Tbyte di spazio lordo (comprensivo delle quote di spazio destinato all’infrastruttura virtuale).

Le specifiche richieste per il sistema di backup dovranno essere:

• supporto RAID;

• espandibilità massima del sistema maggiore o uguale a 100 TB;

• supporto dischi SAS e SATA;

• richiesti 20 Tbyte totali (spazio lordo) ripartiti tra volumi SAS per il boot delle VM/applicazioni e volumi SATA per la gestione dei files utenti (si rimanda al sopralluogo per la definizione delle ripartizioni);

• dual controller in modalità attivo-attivo;

• almeno due adattatori per controller per connettersi alla SAN ridondata in HA;

• protocolli FC e CIFS abilitati.

1.3.3 Gestione centralizzata dei processi di backup-restore

La soluzione virtualizzata e le funzionalità del sistema di storage rappresentano – ove disponibili meccanismi per la creazione di copie di salvataggio dei dati utente, dei dati applicativi e delle macchine virtuali sottoforma di “snapshot” – un supporto per la gestione omogenea e centralizzata dei backup.

L’infrastruttura delineata in precedenza deve essere completata con un sistema che consenta l’archiviazione delle copie di salvataggio dei dati su supporti rimovibili, in modo da consentire alla ASL 1 di provvedere a tutti gli adempimenti previsti dalla normativa sulla sicurezza in materia di protezione dei dati personali.

Per quanto riguarda il backup dei sistemi è sufficiente un server che, ad intervalli definiti, si occupi in automatico del salvataggio delle immagini delle macchine virtuali su una unità a nastro (tape library) da da collegare al server medesimo, eventualmente anche senza la necessità di software aggiuntivi.

Per tutte le macchine che ospitano database (o comunque per quelle per cui sono necessarie modalità di integrazione con software di terze parti che richiedono backup a caldo con frequenza elevata) è necessario l’impiego di un prodotto software specifico, il quale preveda un componente “media server” che gestisca le operazioni di backup attraverso un repository centralizzato e agenti installati sulle macchine applicative.

I dati raccolti dagli agenti distribuiti possono successivamente essere salvati su nastro attraverso il collegamento FC alla tape library. Eventuali funzionalità di deduplicazione dei dati a livello di media server sarebbero utili ad ottimizzare l’occupazione dello spazio su nastro e di conseguenza anche la velocità di ripristino.

In considerazione della realtà estremamente articolata e disomogenea - in termini di RDBMS e applicativi della ASL1 - la disponibilità di agenti per specifici prodotti (Oracle, MS SQL Server ecc.) e di modalità opzionali di backup e restore per diverse esigenze, costituisce un requisito fondamentale del sistema software atteso.

1.4 Riepilogo della fornitura

Nella tabella seguente sono riepilogate le previste forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Nei casi in cui, per vincoli tecnologici, sia attesa la fornitura di specifici prodotti, ciò viene segnalato mediante la notazione di requisito specifico, viceversa sono ammessi in fornitura prodotti equivalenti o superiori per caratteristiche tecniche e funzionali.

Rs. n° Descrizione sintetica forniture di componenti hardware e licenze software ASL 1

Blade server n.8 lame comprensivo di chassis

VMware 5 enterprise server per sito primario 16 processori + VC Estensione del sistema di storage

Software per gestione centralizzata dei backuo tramite media server inclusivo di agent specifici per i sistemi applicativi

[Rs1] Tape Library 2 Drive

Tabella 2 Riepilogo fornitura ASL 1

2 Progetto di adeguamento ASL n°2 di Olbia

Nella tabella seguente, si riporta l’elenco degli interventi e la tipologia. Con la tipologia O (Obbligatorio) sono identificati gli interventi obbligatori nel bando di gara, con la tipologia IPX (Intervento premiante numero X) sono invece indicati quelli opzionali/premianti.

Interventi INFRAS ICT ASL 2 Olbia priorità

Consolidamento e virtualizzazione dei sistemi aziendali O

Soluzione di backup O

Ridondanza del Sistema Firewall di frontiera O

Tabella 3 Riepilogo interventi e priorità ASL2

2.1 Contesto di riferimento

L’infrastruttura tecnologica dell’azienda, così come è emerso nella fase di assessment preliminare, è costituita dal seguenti sistemi:

▪ 9 Server Fujitsu Siemens RX300 S3/S4 (rack);

▪ 6 Server HP ProLiant DL 580 G5 (rack);

▪ 4 Fujitsu Siemens PRIMERGY (rack);

▪ 5 Fujitsu Siemens (rack);

▪ 2 Server HP ProLiant DL 380 (rack);

▪ 3 Server HP ProLiant ML 350 (rack);

▪ 2 Acer Altos G520 (rack);

▪ 1 IBM System x3650 (rack);

Alcuni di questi server vengono utilizzati per applicazioni gestionali ad uso interno dei reparti, DNS, intranet, sistemi amministrativi contabili e RIS/PACS; altri sono oramai stati dismessi.

I sistemi di storage sono locali alle macchine server (unità esterne SCSI per server in cluster MSCS), generalmente forniti dai produttori degli applicativi ed inutilizzabili in un ottica di sistema organico.

L’infrastruttura risulta ormai datata e con basse performance. I sistemi, in caso di fermo macchina, hanno dei tempi di ripristino elevati, dovuti a difficoltà di reperimento delle parti di ricambio e reinstallazioni software da parte dei produttori degli applicativi. Inoltre è mancata negli anni passati una visione generale del sistema informativo dell’intera ASL 2, per cui si hanno soluzioni non omogenee, spesso create dai fornitori delle applicazioni installate, i quali si sono preoccupati di fornire servizi all’utenza senza rispettare uno standard di configurazione (es. domini autonomi per gestione dei cluster MSCS). L’Azienda ritiene inopportuni investimenti di adeguamento, rispetto ad una sostituzione che consentirà una più efficace e sicura gestione dei servizi. Solamente alcune macchine server potranno essere reimpiegate in un futuro progetto di Disaster Recovery e destinate a servizi di supporto all’infrastruttura, ma non di produzione diretta di funzionalità per l’organizzazione.

Sebbene la ASL 2 faccia un pesante utilizzo degli applicativi SISaR, esistono numerose applicazioni interne oggi attive di cui non si prevede dismissione. Le principali sono le applicazioni dei Laboratori di Analisi (SILUS) e il sistema RIS-PACS per la radiologia. A queste si aggiungono altre applicazioni specifiche per servizio che oggi sono installate in ambiente server distribuito e che si vuole consolidare all’interno della server farm.

Il sistema di salvataggio dati (unità tape di scarsa capacità) richiede attività manuali per ogni server applicativo e tempi elevati sia per i salvataggi che per eventuali ripristini.

La sala Server dell’Ospedale Xxxxxxxx Xxxxx XX° è già attrezzata per ospitare i nuovi sistemi in corso di implementazione. Una seconda sala server è presente presso il sito dell’Ospedale S. Xxxxxxxx e potrebbe essere destinata ad ospitare un sito di backup in ottica Disaster Recovery.

Esula dagli scopi della proposta progettuale presentata dalla ASL l’implementazione del Disaster Recovery (DR) della attuale server farm, tuttavia si vorrebbe acquisire una adeguata dotazione di hardware e software che consenta, nel prossimo futuro e con minimi investimenti, di erogare i servizi dal sito del S. Xxxxxxxx in caso di disastro.

2.2 Obiettivi

La ASL ha previsto negli ultimi mesi un adeguamento dell’infrastruttura esistente in ottica virtualizzazione ed iniziato un processo di adeguamento della propria infrastruttura tecnologica. In questo scenario ha previsto di acquisire con fondi propri due sistemi di storage autonomi in grado di gestire l’allineamento dati via IP tra i volumi dei due sistemi, al fine di realizzare un progetto DR ready.

È necessario prevedere un sistema Blade per la realizzazione di una piattaforma VMware Enterprise con la quale avviare un intervento di consolidamento dell’infrastruttura applicativa esistente. Il sistema server sarà collegato all’esistente storage primario in tecnologia FC e ubicato nel sito principale (Ospedale Xxxxxxxx Xxxxx XX°). Il secondo storage verrà ubicato nel sito secondario (Ospedale S. Xxxxxxxx) e si prevede che ospiterà la replica asincrona dei volumi del sito primario. I server esistenti saranno reimpiegati per l’attivazione dei servizi di DR.

È in corso di implementazione la segmentazione della rete locale della server farm tramite un apparato firewall Fortinet F200B di recente acquisizione. L’apparato consente l’accesso controllato all’area server da parte degli utenti (Packet filtering IPS e Antivirus) e garantisce accesso regolamentato da parte dei fornitori della applicazioni esistenti per manutenzione: tuttavia esso costituisce un single point of failure.

2.3 Interventi

Gli interventi previsti nell’ambito del progetto INFRAS ICT saranno meglio dettagliati nei paragrafi successivi.

2.3.1 Consolidamento e virtualizzazione

La scelta è ricaduta su un sistema Blade, per i vantaggi che tale tecnologia offre in termini di:

▪ risparmio energetico;

▪ riduzione della complessità (cavi e infrastruttura);

▪ riduzione dello spazio occupato;

▪ espandibilità futura.

In dettaglio le seguenti caratteristiche sono punto di forza per l’azienda:

▪ gestione centralizzata e monitoraggio automatico delle macchine virtuali, semplicità nell’impiego e nella creazione di nuove;

▪ distribuzione dinamica delle risorse virtuali sulle macchine fisiche per ottimizzare i carichi, utilizzando al meglio le risorse presenti;

▪ elevata affidabilità e semplicità di utilizzo consentono di ottenere alti livelli di servizio per le applicazioni;

▪ possibilità di Live Migration, ossia di spostamento di macchine virtuali tra piattaforme fisiche senza interruzione del servizio per le applicazioni in esecuzione;

▪ sistemi di aggiornamento delle patch centralizzati per tutti gli host fisici e virtuali in modo da ottenere sempre le compatibilità aggiornate;

▪ gestione della continuità dei servizi tramite le funzionalità FT e HA.

Si dovranno prevedere licenze VMware 5 Enterprise per tutti i nodi fisici (lame) + Virtual Center.

In base alle analisi di performance dei sistemi in produzione prevediamo di consolidare circa 8 servizi per lama.

La ASL 2 mantiene al suo interno applicazioni di gestione dei sistemi RIS-PACS (Noemalife) e Laboratorio di Analisi (Noemalife). Il fornitore, nelle installazioni recenti, ha introdotto una soluzione virtualizzata per gli applicativi indicati e non ci sono controindicazioni alla soluzione proposta in ambiente VMware.

Si prevede, quindi, di virtualizzare i seguenti servizi:

▪ laboratori di analisi (4 server virtuali);

▪ RisPacs (6 server virtuali);

▪ database (2 server Virtuali);

▪ dominio Microsoft (2 server virtuali);

▪ portale WEB interno (1 server virtuale);

▪ applicazioni servizi vari (8 server virtuali), per un totale di 24 VM.

Di queste VM devono essere corredate di licenze software:

[Rs2] n. 8 Microsoft Windows Server 2008 Standard (necessario per la gestione dei database, servizi infrastruttura e backup).

[Rs3] Si dovrà inoltre prevedere la fornitura delle facility Disaster Recovery Manager per Vmware licenziato per 25 VM.

L’infrastruttura Blade da destinare alla virtualizzazione sarà dimensionata con n. 4 lame (3 per produzione + una lama hot spare per il bilanciamento del carico/failover).

[Rs4] Dovranno essere fornite ulteriori n. 2 lame/server per ospitare il database Oracle.

Specifiche per le lame da destinare al DB Oracle:

[Rs4.1] N. 1 processori Xeon 4C E5540 2.53GHz/1066MHz/8MB (equivalente o superiore)

[Rs4.2] 24 Gbyte RAM

[Rs4.3] almeno 4 porte Ethernet Gb con hardware TCP/IP Offload Engine (TOE)

[Rs4.4] 2 porte FC 4Gbps con gestione dual path verso lo storage

La connettività verso lo storage sarà in FC ridondata mediante due moduli switch FC alloggiati nel Blade chassis. Anche le connessioni LAN saranno ridondate con moduli switch GbE, sempre alloggiati nel Blade-chassis, al fine di ottenere un sistema interamente ridondato sia verso i server Blade che verso il mondo esterno.

2.3.1.1 Dotazione di storage

Poiché la ASL 2 ha disponibilità di n. 2 siti distinti, è stata prevista la dotazione di un sistema di storage primario e di uno secondario, equivalenti ed in grado di consentire l’allineamento dinamico dei dati tra le due unità mediante la funzionalità di mirror asincrono ottimizzato delle LUN e dei volumi NFS/CIFS.

Lo storage primario (ubicato nel sito primario Xxxxxxxx Xxxxx XX°) avrà funzioni di SAN Storage server per i server applicativi (VMware e Cluster applicativi), e funzionalità di NAS (NFS e CIFS) per i dati utente.

Una quota dello spazio disco di circa 3 TB sarà destinata al sistema virtualizzato (boot da San delle VM), mentre altro spazio sarà destinato alle funzionalità NAS per grossi volumi di dati (per esempio immagini RIS-PACS, files utente).

Tale soluzione è attualmente in corso di acquizione da parte della ASL 2 e non deve essere previsto dalla presente fornitura.

Ai fini delle attività e della fornitura del progetto INFRAS ICT, saranno quindi disponibili i 2 sistemi di storage, secondo le quote di spazio disco opportunamente dimensionate per la gestione dell’ambiente virtuale e applicativo, e saranno garantite le repliche consistenti dei dati e delle applicazioni sul sito secondario.

Pertanto, il sistema Blade server oggetto del presente appalto dovrà essere collegato all’unità di storage, di cui sopra, tramite switch FC da prevedersi in fornitura, e dovrà essere configurato come da specifiche che verranno fornite dal personale informatico della ASL.

2.3.1.2 Sistema di backup

Per la soluzione di backup viene proposto il salvataggio diretto su disco in quanto alla lunga risulta più economico, di minore impatto per la gestione e soprattutto garantisce ripristini immediati.

Nella configurazione a regime con i due storage, è possibile utilizzare il sistema secondario come destinatario del salvataggio dati. La soluzione è interamente gestita dalle funzionalità software del sistema di storage.

L’Azienda prevede comunque la possibilità di esportare su nastro sia le VM che i dati di backup applicativi dedicando una macchina con dischi locali, già in dotazione, alle funzionalità di VCB Vmware. Detto server avrà accesso alla tape library e potrà gestire, ove necessario, un’esportazione del dato su cassetta per il salvataggio legale.

Nell’ambito del presente appalto, è richiesta la fornitura di una tape library con autoloader e n. 1 drive LTO5 FC. La libreria sarà ubicata nel sito primario.

Per garantire la retention dei dati voluta, si richiede un apparato in grado di gestire on line circa 60 TByte.

[Rs5] Si richiede inoltre una soluzione per eventuale restore dei dati su sito secondario da realizzarsi mediante drive LTO 5 da collegare ad hardware esistente.

Il salvataggio su tape verrà gestito dalla macchina destinata alla funzioni di VCB.

Si prevede di posizionare il sistema di archiviazione a nastri sul sito primario, sempre presidiato, mantenendo la seconda copia su disco, sul sito secondario.

2.3.2 Ridondanza del sistema Firewall di frontiera

È in corso di implementazione la segmentazione della server farm attivata con un apparato firewall Fortinet F200B di recente acquisizione. L’apparato consente l’accesso controllato all’area server da parte degli utenti (Packet filtering e IPS) e garantisce accesso regolamentato da parte dei fornitori della applicazioni esistenti per manutenzione, ma è un single point of failure.

Si prevede, pertanto, l’inserimento di una macchina uguale, già attiva presso la farm di Olbia, in grado di gestire l’accesso ai server in bilanciamento di carico/failover. Le funzionalità di IPS e antivirus garantiranno una ulteriore barriera di sicurezza per una corretta fruibilità dei servizi.

Si riporta di seguito il modello esatto della macchina attuale:

[Rs6] ForFG-200B-BDL – Fortigate 200B Bundle da attivare in HA, licenza standard Bundle e maintenance per 3 anni.

2.4 Riepilogo della fornitura

Nella tabella seguente sono riepilogate le previste forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs. n° Descrizione sintetica forniture di componenti hardware e licenze software ASL 2

N. 1 Rack completo di Console switch con Video , tastiera e relative alimentazioni ridondate per soddisfare il posizionamento completo delle apparecchiature sopra richieste presso il CED

N. 1 blade center completo di moduli switch LAN e FC in HA con licenze attive e porte per gestire i collegamenti dei server/Tape previsti in fornitura con lo storage FC a doppia controller (4 collegamenti)

N. 4 server Biprocessore QC per la virtualizzazione collegati alla SAN in FC multipath (min 24 GbRAM+ n 2 dischi SAS in RAID1 per Hypervisor+ 4 GBE).

[Rs4]

N. 2 server QC per i servizi database oracle collegati alla SAN in FC multipath (24 Gb RAM + dischi SAS in RAID1 + 4 GBE)

[Rs6] N. 1 Firewall di Frontiera Fortinet F200B- Bundle

N. 1 Tape Library con autoloader equipaggiata con drive LTO5 FC collegato alla SAN [Rs5] N. 1 Drive LTO 5 da collegare ad hardware esistente

N. 8 Licenze software VMware vSphere 5 Enterprise edition per 1 socket

N. 1 Licenza software VMware VCenter Management server Standard per vSphere 5 [Rs3] N. 1 Licenza VMware vCenter Site Recovery Manager 25v VM

[Rs2] N. 8 Licenze software Microsoft Windows Server 2008 standard

Tabella 4 Riepilogo fornitura ASL 2

3 Progetto di adeguamento ASL n°3 di Nuoro

Interventi INFRAS ICT ASL 3 Nuoro priorità

Licenze VMware a completamento della virtualizzazione O Realizzazione tratta FO tra Ospedale Xxxxxxxxx (HZ) e Ospedale San Xxxxxxxxx (HSF) O

Tabella 5 Riepilogo interventi e priorità ASL3

3.1 Contesto di riferimento

L’avvio di diversi progetti regionali, sviluppati nell’ambito del Sistema Informativo Sanitario Integrato Regionale, ha comportato la necessità di un rapido adeguamento delle infrastrutture presenti nelle singole AS al fine di ospitare i sistemi necessari.

La rapidità con cui tali progetti sono evoluti e la conseguente necessità di approntare rapidamente locali e facilities, ha portato nel tempo al sovrapporsi di soluzioni parziali, legate alle esigenze del singolo progetto, senza che fosse presente un piano organico di infrastrutturazione scalabile nel tempo e omogenea.

Nel caso della ASL di Nuoro ciò ha portato alla predisposizione di numerose sale server, spesso individuate presso locali utilizzati per altri scopi e adattati per ospitare i rack contenenti le apparecchiature di diversi progetti. In diversi casi, inoltre, non si tratta di sale appositamente attrezzate ma di semplici uffici in cui i server vengono posizionati senza le necessarie misure di protezione e di continuità.

Di seguito si elencano i principali siti individuati:

Luogo Progetto o applicativi Note

Sala CED Sisar – HSF SISAR Non ampliabile – utilizzata per impianto telefonico e videosorveglianza

Sala CED Melograno – HSF

SILUS, Medir, Melograno, Screening oncologici (parte web), AP (Anatomia Patologica), Centro Stella rete aziendale, Intranet aziendale, Monitoraggio rete

Non ampliabile

Uffici Centro Epidemiologico – Viale Trieste

Servizi Vari aziendali – Via Demurtas

Screening oncologici (parte applicativa) Il server è disposto in un ufficio accessibile

Database per gli studi epidemiologici

senza particolari misure di protezione

Il server è disposto in un ufficio accessibile senza particolari misure di protezione

Pensioni – Personale

Il server è disposto in un ufficio accessibile senza particolari misure di protezione

Servizi Vari aziendali – Ex INAM Protesica - Veterinari Il server è disposto in un ufficio accessibile

senza particolari misure di protezione

Servizi Vari aziendali - Territorio Diabetologia – Altri applicativi Il server è disposto in un ufficio accessibile

senza particolari misure di protezione

Tabella 6 Dettaglio dei siti ASL3

Luogo Progetto o applicativi

Personale - via Demurtas Pensioni

Personale - via Demurtas Database Trattamenti Accessori (ms access)

Poliambulatorio - Ex INAM Application DB Protesica Integrativa

Poliambulatorio - Ex INAM Servizi Veterinari

Ospedale Xxxxxxxxx Cluster Lab Analisi Zonchello 1

Ospedale Xxxxxxxxx Cluster Lab Analisi Zonchello 2

Ospedale Xxxxxxxxx Diabetologia Nuoro

Ospedale X. Xxxxxxx Diabetologia Sorgono

Poliambulatorio Macomer Diabetologia Macomer

Poliambulatorio Orosei Diabetologia Orosei

Poliambulatorio Siniscola Diabetologia Siniscola

Ematologia - Ospedale S. Francesco Database Ematologia

Endoscopia - Ospedale S. Francesco Endoscopia Chirurgica

Farmacia - Ospedale S. Xxxxxxxxx Farmacia Application / Database

Sala 1 - Ospedale S. Francesco Intranet

Sala 1 - Ospedale X. Xxxxxxxxx Database Itaca

Sala 1 - Ospedale X. Xxxxxxxxx Application server Enco

Sala 1 - Ospedale X. Xxxxxxxxx Application server Melograno

Sala 1 - Ospedale S. Francesco webserver Melograno

Xxxx 0 - Xxxxxxxx X. Xxxxxxxxx Xxx0 Medir

Sala 1 - Ospedale X. Xxxxxxxxx Pdc2 Medir

Sala 1 - Ospedale S. Francesco Progetto TAO

Sala 1 - Ospedale X. Xxxxxxxxx Web Server screening onc

Xxxx 0 - Xxxxxxxx X. Xxxxxxxxx Application /Db Emodinamica 1

Sala 1 - Ospedale X. Xxxxxxxxx Application /Db Emodinamica 2

Sala 1 - Ospedale S. Francesco Serd

Sala 1 - Ospedale X. Xxxxxxxxx Cluster Lab Analisi San Xxxxxxxxx 1

Sala 1 - Ospedale X. Xxxxxxxxx Cluster Lab Analisi San Xxxxxxxxx 2

Sala 1 - Ospedale X. Xxxxxxxxx Cluster Lab Analisi San Xxxxxxxxx 3

Sala 1 - Ospedale X. Xxxxxxxxx Cluster Lab Analisi San Xxxxxxxxx 4

Sala 1 - Ospedale S. Francesco Nefrologia e Dialisi Application

Sala 1 - Ospedale S. Francesco Nefrologia e Dialisi Database 1

Sala 1 - Ospedale S. Francesco Nefrologia e Dialisi Database 2

Sala 1 - Ospedale X. Xxxxxxxxx Application /Db Anatomia Patologica

Sala 1 - Ospedale X. Xxxxxxxxx Application /Db Vaccinazioni

Sala 1 - Ospedale S. Francesco Armadio Rack Medir

Sala 2 - Ospedale S. Francesco DRG – 3M

Sala 2 - Ospedale S. Francesco Armadio Rack Sisar

Tabella 7 Dislocazione sistemi ASL 3

Nel corso del progressivo avvio del progetto SISaR sono emerse le carenze legate alla situazione descritta nel punto precedente, con episodi critici che hanno anche portato a interruzioni nell’erogazione dei servizi.

A questa debolezza intrinseca si aggiunge la sostanziale impossibilità di ampliare le strutture esistenti, ad esempio per accogliere nuovi sistemi. Questo comporterebbe infatti la necessità di dover reperire nuovi locali, da attrezzare singolarmente con costi ulteriori, aggravando la frammentazione di siti esistente. Esiste poi una criticità specifica legata alla progressiva dismissione dei vecchi gestionali, permanendo la necessità di garantire comunque la loro disponibilità ai fini di consultazione dei dati storici e di obblighi legali.

Le criticità nello specifico riguardano:

▪ disponibilità: a seguito dell’avvio dei nuovi sistemi vengono cessati i contratti di assistenza per i sistemi “storici” (Enco, Personale, Ospedaliero Melograno, etc…); deve comunque essere garantita la disponibilità dei dati ai fini di consultazione e obblighi legali, con la necessità di risolvere la problematica legata ai sistemi spesso obsoleti sui quali non si dispone di alcuna assistenza;

▪ eterogeneità: i vari sistemi poggiano su macchine fisiche e su sistemi operativi con caratteristiche molto varie, che richiedono un supporto multi specialistico per le attività di manutenzione e assistenza; in molti casi sono cessati i contratti di assistenza con chi ha fornito i sistemi.

La soluzione parte da un’ipotesi già approvata dalla Direzione Aziendale di concentrare tutte le strutture tecnologiche in un unico sito, lasciando eventualmente parte delle infrastrutture nei siti esistenti al solo fine di garantire ridondanza e backup, o meccanismi di Site Recovery.

Si è ritenuto di individuare la sede del nuovo centro tecnologico presso il Presidio Ospedaliero Zonchello (HZ), nel locale seminterrato del padiglione A.

L’area individuata, opportunamente dotata di tutte le facilities necessarie, servirà sia le infrastrutture tecnologiche che gli uffici del personale di presidio.

3.2 Obiettivi

Gli obiettivi relativi agli interventi ICT del progetto INFRAS ICT sono sostanzialmente:

▪ fornitrura di licenze software a completamento del processo di consolidamento già iniziato in proprio dalla azienda;

▪ realizzazione di tratta in fibra ottica tra FO tra Presidio Ospedaliero Zonchello (HZ) e Presidio Ospedaliero San Xxxxxxxxx (HSF).

3.3 Interventi

Gli interventi previsti nell’ambito del progetto INFRAS ICT saranno meglio dettagliati nei paragrafi successivi.

3.3.1 Licenze VMware a completamento della virtualizzazione

Le dotazioni hardware e software di singoli sistemi (SISaR, Medir, ecc.) garantiscono l’affidabilità e la continuità operativa dei servizi. Esiste però l’esigenza di predisporre un’infrastruttura di supporto ad altri sistemi che presentano criticità di diverso tipo. Tali sistemi sono stati realizzati attraverso progetti regionali o aziendali svolti in tempi diversi e utilizzando server e sistemi operativi eterogenei.

Si distinguono due tipi di sistemi di cui occorre garantire la disponibilità:

▪ sistemi in produzione che si poggiano su macchine obsolete o con caratteristiche non ottimali (ad es. server di tipo non rack-mountable, con ridondanza limitata, o di modello obsoleto);

▪ sistemi che saranno tenuti attivi per fini di consultazione dello storico o di ottemperanza a obblighi legali.

La soluzione che si propone, rispettando i più recenti paradigmi in tema di ottimizzazione delle architetture hardware e software, è quella di consolidare tutti questi sistemi attraverso la loro virtualizzazione. I vantaggi che si avrebbero sono molteplici, ad esempio:

▪ utilizzo ottimale delle capacità computazionali dei server e delle altre risorse;

▪ risparmio energetico e minore produzione di calore;

▪ flessibilità;

▪ scalabilità;

▪ Disaster Recovery;

▪ continuità operativa.

La migrazione può avvenire secondo un processo di conversione “Phisical to Virtual” (P2V), con la migrazione a macchine virtuali dell'intera infrastruttura harware/software dei sistemi, riutilizzando quanto possibile l'hardware esistente e dismettendo al contempo tutto ciò che è obsoleto, non affidabile o con costi di gestione elevati.

Quale sistema di virtualizzazione si è individuato il prodotto Vmware vSphere 5.0, che nella sua versione Enterprise Plus dispone di numerosi vantaggi e feature quali “HA, DRS, Vmotion e il virtual distributed switch”.

Si stima che in questa fase ci siano circa n. 40 sistemi che dovranno essere virtualizzati, includendo sistemi legati a progetti regionali realizzati ormai diversi anni fa che potrebbero trarre vantaggio dalla virtualizzazione (ad esempio Screening Oncologici, Diabetologia, Serd, ecc.). Anche sistemi più recenti, quali ad esempio il SILUS, possono avere vantaggi evidenti dalla virtualizzazione della parte Application.

Principalmente, la virtualizzazione riguarda due tipologie di applicativi:

▪ lo storico pregresso, ovvero la necessità di tenere disponibili in sola consultazione gli archivi storici di tutti gli applicativi sostituiti dal sistema Sisar e da altri progetti regionali, finora ospitati su hardware dedicato ormai obsoleto e soggetto a guasti difficilmente ripristinabili;

▪ i sistemi di vitale importanza per il lavoro di routine, finora non coinvolti in progetti regionali, quali ad esempio gli applicativi per la gestione dell'emodinamica, dei reni artificiali della dialisi, etc..

Si riporta di seguito l’elenco esaustivo dei servizi/applicativi e il metodo di virtualizzazione:

Sito	Applicativi	Tipo di intervento	Metodo
Personale - via Demurtas	Pensioni	Da definire	P2V

(ms Access)

Personale - via Demurtas Database Trattamenti Accessori

Server consolidation P2V

Integrativa

Poliambulatorio - Ex INAM Application DB Protesica

Server consolidation P2V

Poliambulatorio - Ex INAM Servizi Veterinari Server consolidation

Ospedale Xxxxxxxxx Cluster Lab Analisi Zonchello l Conservazione Storico P2V Ospedale Xxxxxxxxx Cluster Lab Analisi Xxxxxxxxx 2 Conservazione Storico P2V Ospedale Xxxxxxxxx Diabetologia Nuoro Server consolidation P2V

server di Nuoro

Ospedale X. Xxxxxxx Diabetologia Sorgono Server consolidation Compreso nel P2v del

Poliambulatorio Macomer Diabetologia Macomer Server consolidation Compreso nel P2v del

server di Nuoro

Poliambulatorio Orosei Diabetologia Orosei Server consolidation Compreso nel P2v del

server di Nuoro

Poliambulatorio Siniscola Diabetologia Siniscola Server consolidation Compreso nel P2v del

Ematologia - HSF Database Ematologia Server consolidation P2V Endoscopia - HSF Endoscopia Chirurgica Server consolidation P2V Farmacia - HSF Farmacia Application / Database Conservazione Storico P2V Sala l - HSF Intranet Server consolidation P2V

Sala l - HSF Database Itaca Server consolidation P2V Sala l - HSF Application server Enco Conservazione Storico P2V Sala l - HSF Application server Melograno Conservazione Storico P2V Sala l - HSF webserver Melograno Conservazione Storico P2V Sala l - HSF Pdcl Medir Server consolidation P2V

Sala l - HSF Pdc2 Medir Server consolidation P2V

Sala l - HSF Progetto TAO Server consolidation P2V Sala l - HSF Web Server screening onc Server consolidation P2V Sala l - HSF Application /Db Emodinamica1 Server consolidation P2V Sala l - HSF Application /Db Emodinamica 2 Server consolidation P2V Sala l - HSF Serd Server consolidation P2V

Sala l - HSF Cluster Lab Analisi HSF 1 Server consolidation P2V / Riconfigurazione Sala l - HSF Cluster Lab Analisi HSF 2 Server consolidation P2V / Riconfigurazione Sala l - HSF Cluster Lab Analisi HSF 3 Server consolidation P2V / Riconfigurazione Sala l - HSF Cluster Lab Analisi HSF 4 Server consolidation P2V / Riconfigurazione Sala l - HSF Nefrologia e Dialisi Application Server consolidation P2V

Sala l - HSF Nefrologia e Dialisi Database 1 Server consolidation P2V Sala l - HSF Nefrologia e Dialisi Database 2 Server consolidation P2V

Sala l - HSF Application /Db Anatomia Patologica

Server consolidation P2V

Sala l - HSF DRG-3M Server consolidation P2V Sala l - HSF Application /Db Vaccinazioni Server consolidation P2V Sala l - HSF Armadio Rack Medir

Sala l - HSF Armadio Rack Sisar

Tabella 8 Servizi e metodo di virtualizzazione ASL3

Al fine di utilizzare le risorse già disponibili e di prevedere un punto di backup presso l’HSF, che potrà all’occorrenza fungere da recovery in caso di indisponibilità del sito principale (Site Recovery), e considerando i server e gli storage già disponibili, l’azienda provvederà autonomamente a:

▪ acquisto di n. 2 server SUN in modo da predisporre un cluster VMware a 2+1 nodi su cui virtualizzare le macchine.

Su un nodo saranno installate le macchine non critiche, ad esempio quelle predisposte in sola consultazione, e si userà la versione ESXi di VMware, mentre gli altri due nodi saranno in HA e licenziati VSphere 5.0.

Tale sistema poggerà su uno storage totalmente ridondato con doppio processore e doppio controller. La connettività dai nodi VSphere verso lo storage sarà garantita da un doppio canale in fibra ottica, mentre verso la rete LAN il collegamento avverrà tramite un doppio canale Gigabit per le VLAN e Gigabit per la lan di servizio di VMkernel.

Nell’ambito del progetto INFRAS ICT, per effettuare l’operazione di virtualizzazione, è necessaria la fornitura della

[Rs7] licenza Vmware vSphere 5.0, nella sua versione Enterprise Plus per n. 4 processori.

Si schematizza nelle figure sotto riportate i dettagli sull’architettura attuale e successiva all’intervento.

Figura 1 Situazione architettura attuale

Figura 2 Situazione architettura dopo la virtualizzazione

Figura 3 Concept connessioni e HA sistema

Rs.n.. Descrizione sintetica forniture di componenti hardware e licenze software Asl3 Qtà

La nuova architettura avrà una Potenza assorbita di 3Kw e uno spazio occupato 7U. Di seguito si riassume la fornitura prevista nell’ambito del progetto INFRAS.

[Rs7] Vmware vSphere 5.0 Enterprise Plus Licenza per processore 4

Tabella 9 Dettaglio fornitura software ASL3

3.3.2 Realizzazione tratta FO tra Ospedale Xxxxxxxxx (HZ) e Ospedale San Xxxxxxxxx (HSF)

Precondizione per la realizzazione degli impianti presso il presidio Zonchello è la disponibilità di linee dati affidabili e veloci verso l’HSF, il quale attualmente ospita il centro stella della rete aziendale.

Tale precondizione verrà soddisfatta dalle seguenti linee:

▪ collegamento con ponte radio 54 Mbps, attualmente già utilizzato per il collegamento tra i presidi;

▪ collegamento in fibra ottica RTR, già realizzato;

▪ collegamento in fibra ottica (n. 24 fibre) tra HZ e HSF, oggetto del presente intervento.

I collegamenti permetteranno di garantire un adeguato throughput di dati e una sufficiente robustezza, in modo da consentire l’accesso ai sistemi anche in caso di interruzione di uno o più canali di comunicazione.

La soluzione desiderata, considerata la necessità di garantire massima robustezza e disponibilità del collegamento tramite una ridondanza completa server to switch è la seguente:

[Rs8] N. 2 link in FO ridondati 10Gb + 10Gb (metri circa 460)

Figura 4 Schematizzazione collegamento tra HZ e HSF

Il collegamento in fibra ottica tra i due presidi, oggetto del presente intervento, dovrà essere corredato degli apparati attivi, che dovranno essere perfettamente compatibili con gli apparati di rete e telefonici esistenti nella rete interna della ASL 3, tutti di marca 3Com, e con il sistema di gestione e monitoraggio, alert, configurazione QoS e amministrazione degli apparati utilizzato (Network Supervisor della 3Com).

In particolare dovrà essere garantito:

▪ gestione funzionalità di rete (ad es. spanning tree) in modalità compatibili con gli altri switch 3Com esistenti;

▪ utilizzo del protocollo IRF (stacking technology) di trasmissione/connessione (10GB) tra gli switch proposti, con incremento di banda di trasmissione utilizzata tra i due switch, alta affidabilità, ridondanza in caso di fail over di una delle connessioni;

▪ piena compatibilità di connessione con l’attuale centro stella (CORE) modello 3Com Switch 5500G-EI-SFP installato presso Ospedale San Xxxxxxxxx (Nr. 5 Switch) attraverso l’utilizzo del protocollo XRN (stacking Layer 2);

▪ piena compatibilità per le connessioni fibre to fibre tra gli switch HZ e quelli HSF tramite utilizzo del protocollo LACP (802.3ad) con la formazione di un singolo canale logico con più porte fisiche, con condivisione del carico dei dati trasmessi e ridondanza per garantire affidabilità in caso di fail over di una delle due tratte del singolo fascio.

Le caratteristiche minime di ciascun switch sono:

▪ switch 16 porte transceiver (SFP) + 8 porte dual personality (10/100/1000) rame (RJ) oppure

switch 24 porte transceiver (SFP);

▪ 2 moduli per slot posteriori;

▪ 2 moduli per alimentazione;

▪ supporto fino a 4 porte da 10GB;

▪ modulo 2 porte per 2 XSFP 10GB full duplex only (per fibra ottica);

▪ n. 6 SFP SX da 1 GB ;

▪ modulo per connessione cavo stacking XFP 10GB*2 full duplex only;

▪ performance: 100 Mb Latency < 10 µs;

▪ throughput: 107.2 million pps;

▪ routing/Switching capacity: 144 Gbps;

▪ routing table size: 12.000 entries;

▪ environment Operating temperature: 32°F to 113°F (0°C to 45°C);

▪ operating relative humidity: 10% to 90%, non-condensing;

▪ electrical characteristics: Voltage 100-240 VAC Frequency 50 / 60 Hz.

Standard e protocolli supportati:

RFC 1907 SNMPv2 MIB; RFC 2012 SNMPv2 MIB for TCP; RFC 2233 Interfaces MIB; RFC 2465 IPv6 MIB; RFC 2466 ICMPv6 MIB; RFC 2571 SNMP Framework MIB; RFC 2572 SNMP-MPD MIB; RFC 2573 SNMP-Notification MIB; RFC 2573 SNMP-Target MIB; RFC 2574 SNMP USM MIB; RFC 2618 RADIUS Client MIB; RFC 2620 RADIUS Accounting MIB; RFC 2819 RMON MIB; RFC 2925 Ping MIB; RFC 3414 SNMP-User based-SM MIB; RFC 3415 SNMP-View based-ACM MIB; RFC 4113 UDP MIB;

Network management; IEEE 802.1AB Link Layer Discovery Protocol (LLDP); IEEE 802.1D (STP); RFC 1157 SNMPv1; RFC 1215 SNMP Generic traps; RFC 1757 RMON 4 groups: Stats, History, Alarms; and Events; RFC 1901 SNMPv2 Introduction; RFC 1918 Private Internet Address Allocation; RFC 2575 VACM for SNMP; RFC 2576 Coexistence between SNMP versions; RFC 2578 SMIv2; RFC 2581 TCP6; OSPF; RFC 1253 OSPFv2 MIB; RFC 1587 OSPF NSSA; RFC 1850 OSPFv2 Management Information Base; (MIB), traps; RFC 2328 OSPFv2; QoS/CoS; IEEE 802.1P (CoS); RFC 2474 DSCP

DiffServ; RFC 2597 DiffServ Assured Forwarding (AF); RFC 2598 DiffServ Expedited Forwarding (EF);

Security; RFC 1492 TACACS+; IPsec; RFC 2401 IP Security Architecture; RFC 2402 IP Authentication Header; RFC 2406 IP Encapsulating Security Payload; RFC 2409 - The Internet Key Exchange; RFC 2865 - Remote Authentication Dial In User; Service (RADIUS);

Dovranno, in particolare, essere garantiti:

Layer 4 prioritization: abilita priorità basate su numeri di porta TCP/UDP; Traffic prioritization (IEEE 802.1p); Class of Service (CoS) configurando la priorità IEEE 802.1p, con tag basato su IP, IP TOS, Layer 3, porte TCP e UDP, porta sorgente, DiffServ; rate limiting; broadcast control; Auto-MDIX; IPv6; High-density: supporto in Layer 2/3/4 in un unico stack (IRF - Intelligent Resilient Framework); Spanning Tree Protocol (STP) e Multiple Spanning Tree (MSTP) compatibile con Switch 3Com esistenti in ASL 3; Virtual Router Redundancy Protocol (VRRP); Device Link Detection Protocol (DDLP); IRF (intelligent Resilient Framework) con gestione dei link (Fibra ottica) dello standard LACP (Link Aggregation Control Protocol); Automatic VLAN assignment; ACL; RADIUS/TACACS+; SSHv2; 802.1X e RADIUS network Login; Port security; MAC address lockout; FTP; Switch management logon security e secure management access; IP lockdown, dynamic IP lockdown; Dynamic ARP protection; STP Root Guard; IGMP V1, v2, v3; IPv6 tunneling; Port mirroring; Layer 2 switching: VLAN, GARP VLAN Registration Protocol (GVRP), Ip multicats snooping, jumbo packet, 80211 ad QinQ; Layer 3 servizi e routing : ARP, UDP Helper, DHCP, IPv4 e IPv6 Routing protocol, OSPF-ECMP, OSPF (IPv4 e IPv6), multicast routing PIM Dense e Sparse mode.

Dettaglio della fornitura:

Nr. 4 Switch 24 port SFP
XFP 10GBASE-LR	n.	8
2-Port 10-Gigabit Module (XFP)	n.	4
Cavo per modulo stacking (10GB)	n.	2
Modulo per connessione cavo stacking (10GB)	n.	4
SFP SX da 1GB	n.	24

3.4 Riepilogo della fornitura

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n. Descrizione u.m. Q.tà

[Rs7] VMware vSphere 5.0 Enterprise Plus Licenza per processore cad. 4

Collegamento in fibra ottica tra HSF e HZ:

[Rs8]

fornitura e posa in opera di cavo fibra ottica multimodale per esterni con n. 24 fibre tipo OM2 50/125 per frequenze 850 nm (banda 10Gbit), box ottici di terminazione, bussole e relative “bretelle” (zipcord tx-rx LC o SC to ST) di connessione

m 460

Switch 24 porte SFP (completo di moduli e accessori specificati) cad. 4

Tabella 10 Riepilogo fornitura ASL 3

4 Progetto di adeguamento ASL n°4 di Lanusei

In questo capitolo sono riportate le soluzioni tecnologiche e le specifiche tecniche e funzionali realtive alla proposta progettuale di adeguamento delle infrastrutture hardware/software presentata dall’Azienda Sanitaria Locale n°4 di Lanusei nell’ambito del Progetto INFRAS ICT.

Interventi INFRAS ICT ASL 4 Lanusei priorità

Potenziamento infrastruttura virtuale del data center O

Adeguamento sistema di connettività IP3

Sistema centralizzato di raccolta log IP4

Armadio ignifugo per cassette di backup IP5

Tabella 11 Riepilogo interventi e priorità ASL 4

4.1 Contesto di riferimento

Il CED dell’ASL4 è ubicato presso il piano terra dell’Ospedale Nostra Signora Della Mercede, in Via Ospedale a Lanusei.

La sala è di nuova costruzione e risulta in fase di valutazione, come sito di backup per il disaster recovery, l’utilizzo di in uno stabile a poche centinaia di metri dalla sala server.

Per quanto riguarda le informazioni architettoniche della sala:

▪ le misure dei varchi sono: porta blindata area CED (1 m), varco area server (90 cm);

▪ la dimensione area CED è di 26 mq totali, suddivisi in:

− area server: 17 mq;

− area backup: 4 mq;

− area pannello elettrico: 5 mq.

▪ Il pavimento è sopraelevato, costituito da pannelli 60x60 di spessore mm 30 in solfato di calcio tipo 30ka, rivestimento superiore PVC antistatico completo di struttura portante in acciaio regolabile. Altezza pavimento finito cm 20. Il carico ammissibile della pavimentazione flottante è di 700Kg a mq.

Nel corso degli ultimi tre anni anche la struttura della rete telematica aziendale ha subito una sostanziale evoluzione che ha determinato lo scaturire di due antitetiche necessità:

1) rapida messa in opera di un sistema stabile e funzionale per l'avvio dei nuovi progetti di informatizzazione aziendale e regionale nel rispetto dei crono programmi;

2) ottimizzazione degli investimenti, in considerazione della non definitiva configurazione della rete aziendale, a seguito delle attivazioni delle tratte in fibra ottica tra le principali sedi aziendali, nell'ambito del progetto RTR e MAN cittadina.

L’azienda ha quindi fatto ricorso all’utilizzo di soluzioni di firewalling open source (e gratuite) molto scalabili e sufficientemente stabili con il solo dispendio dei costi relativi alla configurazione e manutenzione delle stesse.

Di seguito viene riportato uno schema della struttura attuale con sotto riportato l'elenco delle strutture territoriali collegate alla VPN aziendale.

Figura 5 - Rete attuale ASL 4

Con l’attivazione delle tratte in fibra ottica e a seguito dell'accorpamento di alcune sedi presenti nel comune di Tortolì, la struttura della rete evolverà secondo lo schema di seguito riportato:

Figura 6 - Schema della futura rete ASL 4

Le interconnessioni dei presidi (sia in fibra sia in rame) sarebbero tutte centrate verso il centro stella della sede ospedaliera.

Attualmente l'azienda non è provvista di apparati di raccolta dei log centralizzati, seppure i sistemi di networking attualmente presenti siano impostati per la conservazione locale degli stessi. Inoltre non è installato alcun sistema idoneo alla registrazione degli accessi logici (autenticazione informatica) ai sistemi di elaborazione e agli archivi elettronici da parte degli amministratori di sistema.

A seguito della prioritaria necessità di messa in opera dei sistemi sopra indicati e, considerando quanto richiesto dalla normativa attuale, l'azienda si trovava già nella fase preliminare di acquisizione di un sistema di log centralizzato e registrazione degli accessi. Considerata la situazione attuale si ritiene opportuno che tali acquisizioni diventino oggetto di possibile finanziamento nell'ambito dell'intervento INFRAS ICT.

Nel data center aziendale sono giornalmente schedulate le operazioni di backup e replica dei dati. Tali operazioni, per i sistemi SISAR e per i sistemi aziendali (RIS – PACS etc.), si realizzano nella scrittura incrementale dei dati su opportuni nastri magnetici. Il personale del CED opera periodicamente procedure di sostituzione di tali nastri e deposito degli stessi nella sala backup affiancata al CED e realizzata (come la stessa area server) con muratura resistente al fuoco. Inoltre le cassette vengono depositate su due piccoli contenitori ignifughi per poter così garantire in modo più sicuro l'indistruttibilità degli stessi ad eventi di incendio. Considerato il numero di cassette magnetiche prodotto allo stato attuale dall'archiviazione delle immagini della radiologia e in generale da tutti i sistemi aziendali,

compresi i sistemi dipartimentali SISAR, si è rapidamente raggiunta la saturazione delle due cassette presenti generando la necessità di acquisizione di una nuova soluzione di archiviazione che risponda alla necessità di archiviazione attuale e futura.

Da più di tre mesi l'architettura dei sistemi informativi aziendali (non si fa riferimento ai sistemi dipartimentali installati nell'ambito del progetto SISaR) è basata sulla virtualizzazione.

L'architettura presente è composta fisicamente da 3 host, acquisiti per la realizzazione dell'infrastruttura, e da una SAN ISCSI che nello specifico è un server già in nostro possesso opportunamente configurato come sistema di storage.

L'infrastruttura virtuale in oggetto eroga attualmente i servizi informatici aziendali (si precisa sempre ad esclusione di quanto fornito nell'ambito del progetto SISaR) per i quali si vuole ricordare i sistemi maggiormente importanti come:

▪ il sistema SILUS (Gestione del laboratorio analisi);

▪ il server primario di dominio, il server antivirus;

▪ il sistema degli screening oncologici;

▪ il sistema SESIT. Di prossima installazione:

▪ il sistema RIS;

▪ il sistema di gestione delle vaccinazioni umane.

L'infrastruttura virtuale, attualmente, non eroga i servizi del sistema di gestione e archiviazione delle immagini radiologiche (sistema PACS) che allo stato attuale viene eseguito su hardware dedicato in configurazione pseudo attivo–passivo. Tale configurazione, nella sfortunata ipotesi di guasto del server primario, obbliga lo switch manuale alla macchina secondaria con un ovvio tempo di disservizio dei servizi PACS.

A seguito di uno studio di fattibilità operato con la ditta fornitrice del sistema PACS si è valutata la migrazione “certificata” dell'intero sistema nell'infrastruttura virtuale in nostro possesso a patto di garantire performance di trasferimento dati tra l'infrastruttura e storage superiori rispetto a quanto fornito dalla soluzione ISCSI attualmente in produzione. Si vuole precisare inoltre che con la virtualizzazione del sistema PACS si potrà garantire anche per questo servizio, come già per gli altri sistemi aziendali critici, l'alta affidabilità.

Attualmente la radiologia del P.O. è dotata di n. 42 punti rete a 100 Mbps che confluiscono in un armadio di rete dotato di patch panel e switch HP Procurve della serie 5300xl. Tale switch è collegato tramite una fibra al centro stella della rete aziendale. Da qui le immagini generate dalle varie modality (TAC, RM, Ecografi e CR) arrivano al PACS aziendale situata nel data center.

Da questa breve descrizione della situazione esistente si evidenziano le seguenti criticità e necessità:

1. lo switch HP attualmente installato non garantisce l'alta affidabilità del funzionamento della radiologia;

2. l'enorme flusso di dati generati dalle modality (alcune centinaia di mega per ogni esame e per quanto riguarda alcune tipologie di esami della TAC anche qualche migliaio di mega byte) soffre di un collo di bottiglia in quanto la rete interna è in categoria 5 e gli apparati attivi sono in tecnologia da 100 Mb/s.

L’azienda ha manifestato la necessità di realizzare:

▪ un cablaggio in categoria 6 in tutta l'area della Radiologia per consentire un più veloce trasferimento e ricezione di dati verso il sistema PACS;

▪ l’acquisto di un nuovo switch Gigabit dedicato e in alta affidabilità con lo switch presente;

▪ la posa di una tratta di fibra che colleghi direttamente l'armadio di rete della radiologia con il data center tramite il centro stella ospedaliero in modo che si crei un percorso alternativo e dedicato al pesante flusso di immagini.

La ASL 4 di Xxxxxxx in questi ultimi anni ha assistito ad una crescita esponenziale del rapporto tra personale dipendente in servizio e numero di personal computer necessari per la normale attività lavorativa. L'informatizzazione dell’attività ospedaliera, amministrativa e territoriale ha portato ad un notevole utilizzo di apparecchiature informatiche. Tutto questo si è tradotto in una forte dipendenza degli operatori dal sistema informatico aziendale anche per le attività più semplici e comuni. Sono sempre più comuni gli scenari in cui possibili problematiche software e procedurali vadano ad interferire con l'attività lavorativa dell'operatore aziendale, ripercuotendo tali disagi sulla qualità dei servizi offerti al cittadino.

Diventa fondamentale l'ottimizzazione dei processi che partano dalla segnalazione del guasto, alla ricezione, catalogazione, alla programmazione sino alla sua risoluzione nel minor tempo possibile. Questo contributo può essere fornito da un software dedicato e specializzato di help desk e di software e asset management.

Relativamente alla continuità di servizio e al disaster recovery, emerge un’ulteriore criticità dovuta al fatto che allo stato attuale il data center aziendale risulta essere, ad esclusione dei sistemi installati nell'ambito del progetto SISAR e dei servizi da esso erogati, l'unico centro di elaborazione dati per l'Azienda Sanitaria n° 4. Tra i servizi erogati localmente al data center aziendale possiamo ricordare i sistemi critici come il sistema RIS/PACS di radiologia e il sistema LIS per la gestione del laboratorio analisi. Si aggiungono a questi i sistemi di gestione del dominio aziendali, i servizi di backup ed i sistemi di gestione delle reti. A fronte di eventuali eventi di disastro che interessino il data center aziendale, allo stato attuale, non si ha alcuna area di ripristino che possa garantire il recupero, in tempi accettabili, dei servizi IT.

4.2 Obiettivi

La ASL 4 ha in programma la predisposizione di un'area di Disaster Recovery al fine di mantenere la continuità dei servizi IT anche nell'eventualità di fermo del data center. Si precisa che non è oggetto di questa proposta il tema del Disaster Recovery che, seppur importante, non è risolvibile nell’ambito degli interventi del progetto INFRAS ICT.

Si elencano di seguito le voci di intervento per la definizione del sito di Disaster Recovery per le necessarie valutazioni in relazione alla fornitura INFRAS ICT:

▪ Individuazione locale: il locale è stato individuato presso la direzione sanitaria ospedaliera che è uno stabile distante all'incirca 150- 200 metri rispetto al data center aziendale.

▪ Connettività area di disaster recovery: il locale individuato è già connesso con il centro stella ospedaliero (al quale fa capo il data center e l'accesso alla RTR) da due percorsi in fibra ottica indipendenti.

▪ Interventi strutturali: il locale necessita di installazione di un sistema di raffreddamento, di una porta blindata con un eventuale controllo di accessi e di una griglia per la protezione della finestra. (interventi finanziabili nell'ambito del progetto INFRAS ICT).

▪ Apparati hardware costituenti il sito di disaster recovery: considerata l'esistenza presso il data center dell'infrastruttura virtuale si propone l'estensione di tale infrastruttura al sito di disaster recovery. Nel dettaglio all'infrastruttura attualmente esistente (3 host dislocati nel data center) andrebbero aggiunti ulteriori 2 server dislocati presso il sito di Disaster Recovery. Per quanto riguarda il dispositivo di storage dell'infrastruttura si richiede l'acquisto di una SAN in fibra (considerato già l'acquisto della SAN in fibra come richiesto al paragrafo 4.3.1) da collocare nel sito di Disaster Recovery. L'infrastruttura virtuale sarebbe dunque composta da 5 host totali dislocati in due sedi geograficamente distanti ma tra loro connesse e da due SAN in fibra dislocate ognuna rispettivamente nel data center e nel sito di Disaster Recovery. Nello specifico

i meccanismi di gestione dell'alta affidabilità di VmWare andrebbero a gestire sia la replica delle macchine virtuali che dei dati mantenendo l'alta affidabilità applicativa distribuita tra il data center e il sito secondario. Lo storage presente nel sito di Disaster Recovery sarà anche sistema di archiviazione dei backup generati dai sistemi del data center centrale. Non è richiesta unità di backup a nastro.

▪ Apparati di networking: nel sito di DR sarà presente anche il secondo firewall centrale secondo quanto richiesto al paragrafo 4.3.2 in modo da poter garantire l'alta affidabilità dei servizi di networking. Si vuole ricordare che l'alta affidabilità dei servizi di networking potrà garantire la continuità di servizio anche per i sistemi presenti nei siti di DR regionali definiti nell'ambito del progetto SISAR.

4.3 Interventi

Gli interventi previsti nell’ambito del progetto INFRAS ICT saranno meglio dettagliati nei paragrafi successivi. Sono stati riportati anche gli interventi a priorità inferiore che potrebbero essere oggetto di fornitura quali interventi premianti

4.3.1 Potenziamento infrastruttura virtuale del data center

In questo paragrafo si descrive il potenziamento dell'infrastruttura virtuale esistente mediante la sostituzione e migrazione della SAN ISCSI con una SAN in tecnologia FC. Tale obiettivo andrà valutato non solo per rendere possibile la virtualizzazione del sistema PACS ma anche per il miglioramento della funzionalità dei sistemi attualmente in produzione e dei sistemi di futura installazione.

Acquisizione SAN

Anche se l’intervento di realizzazione del sito di DR xxxxxxxxx non verrà completamente terminato nell’immediato, l’azienda propone la realizzazione di una architettura basata su doppia SAN Fiber Channel (una delle quali per il sito secondario con la stessa identica configurazione di quella del sito primario), e funzionalità tipo “snap mirror” da realizzarsi tramite servizi della piattaforma VMware, per la quale si prevede un upgrade delle attuali licenze e supporto. Tale soluzione garantirebbe una maggiore affidabilità nell’erogazione dei servizi aziendali, rispetto all’attuale.

Nello specifico i requisiti tecnici che andranno rispettati della due SAN (che dovranno essere identiche tra loro come modello) sono:

▪ certificata compatibilità dello storage con i principali sistemi operativi (Windows® 2000, Windows Server 2003 e 2008, Windows XP, Linux®, Sun™ Solaris™, AIX, HP-UX, Mac® OS, VMware ESX) e software applicativi e per database (certificazione per il catalogo dei server Windows, compatibilità dei sistemi di storage Oracle);

▪ compatibilità con VMware, e presenza del prodotto nella HCL (hardware compatibility list) di Vmware. Certificazione per VMware vSphere 4 e 5;

▪ supporto protocollo SAN: Fibre Channel Protocol (FCP) per iSCSI (4/2/1 GB); system fabric- attached e direct-attached; IP SAN (iSCSI); Fibre channel over Ethernet (FCoE);

▪ supporto protocollo di rete: NFS V2/V3/V4 su UDP o TCP, PCNFSD V1/V2 per l'autenticazione client NFS (PC), Microsoft® CIFS, host virtuali HTTP 1.0 e HTTP 1.1;

▪ LUN: almeno 1024;

▪ affidabilità: controller hot-swap, ventole di raffreddamento e alimentatori;

▪ gestione: scheda 10/100 Base-T Ethernet full-duplex onboard, LED di diagnostica, Centro di manutenzione, SNMP, telnet, SSH, HTTP, Web (SSL), script di host, avvisi e-mail;

▪ Snap Mirror (incluse licenze sincronizzazione e replica dati tra SAN);

▪ porte Fibre Channel onboard (destinazione o iniziatore): almeno 4 porte da 1, 2 o 4 Gb (rilevazione automatica) per la configurazione active-active; almeno 2 porte da 1, 2 o 4 Gb(rilevazione automatica) per controller singolo;

▪ porte GbE onboard: almeno 4 per configurazione active-active, almeno 2 per controller singolo;

▪ alimentatori/ventole di raffreddamento: doppi alimentatori/ventole integrati hot-plug ridondanti (220 V/110 V);

▪ compatibilità rack 19”;

▪ scalabilità:

− minima non formattata (calcolata mediante il sistema aritmetico in base 10 (1 TB = 1012 byte)): 68 TB per configurazione active-active e controller singolo;

− minima di unità disco interne: 12 per configurazione active-active e controller singolo;

− minima di unità di espansione dinamica: 56 per configurazione active-active e controller singolo;

− minima di unità disco totali (interne + esterne): 68 per configurazione active-active e controller singolo.

▪ creazione di volumi virtuali gestibili e spostabili indipendentemente dallo storage fisico. Almeno 200 volumi gestibili per controller;

▪ copie Snapshot: almeno 50.000 per controller;

▪ dimensioni massime gruppi RAID e aggregati:

− RAID 6 (RAID-DP): FC o SAS5 -> 28 (26 dischi dati più 2 dischi parità), SATA -> 16 (14 dischi dati più 2 dischi parità)

− RAID 4: FC o SAS5 -> 8 (7 dischi dati più 1 disco parità), SATA: 14 (13 dischi dati più 1 disco di parità)

− RAID 1 a elevata affidabilità: (1) RAID-DP + RAID 1, (2) RAID 4 + RAID 1;

− dimensioni volume/aggregato: 8 TB (FC o SAS o sata).

▪ Dischi richiesti in fornitura: 24 dischi SAS 600GB o dimensione superiore compatibili con SAN fornita.

Si richiedono inoltre n. 3 switch FC con almeno 8 porte gigabit e compatibili con gli HBA FC port per host in uso (HP AP769A). Le specifiche tecniche da supportare sono:

▪ velocità porte: 8 Gbps;

▪ numero di porte: non inferiore a 8 porte Fibre Channel;

▪ throughput: non inferiore a 128 Gbps;

▪ larghezza di banda switch aggregata: non inferiore a 380 Gbps;

▪ protocolli supportati: Fibre Channel;

▪ caratteristiche di disponibilità: Hot code load. Porte on demand senza tempi di inattività;

▪ piattaforma di gestione : Ethernet 10/100 (RJ-45), porta seriale;

▪ possibilità di collegamento a più switch;

▪ possibilità di crescita per scalabilità senza interruzioni fino a un massimo di 24 porte abilitate;

▪ possibilità di installazione in rack standard EIA da 19” per telecomunicazioni (minuteria accessoria inclusa);

▪ gestione: web-tools;

▪ munita di cavi di alimentazione;

▪ compatibilità con gli HBA FC single port per host in uso (HP AP769A);

▪ compatibilità con SAN fornita.

Per l’infrastruttura virtuale sono inoltre richiesti 2 switch completi ciascuno di 4 mini-GBIC. Le specifiche tecniche da supportare sono:

▪ switch layer 2/3/4;

▪ almeno 20 porte 10/100/1000 rj45 (IEEE 802.3 Type 10Base-T, IEEE 802.3u Type 100Base- TX, IEEE 802.3ab Type 1000Base-T);

▪ numero 4 porte dual-personality per connettività 10/100/1000 con RJ-45 o in fibra ottica Gigabit con mini-GBIC;

▪ prestazioni:

− capacità di routing/switching: non inferiore a 48 Gbps;

− throughput: non inferiore 35 milioni di pps a 64 byte;

− dimensioni tabella di routine: non inferiore a 8000 voci.

▪ supporta fino a 24 trunk, ciascuno con 8 collegamenti (porte) per trunk;

▪ spanning tree multipli e supporto legacy per IEEE 802.1d e IEEE 802.1w;

▪ possibilità di installazione in rack standard EIA da 19” per telecomunicazioni (minuteria accessoria inclusa);

▪ alimentazione ridondata (interna o esterna);

▪ switching layer 2:

− supporto simultaneo per IEEE 802.1Q (4.096 ID VLAN) e 256 VLAN;

− rilevamento automatico e assegnazione dinamica delle VLAN.

▪ sicurezza:

− accesso consentito solo a indirizzi MAC specificati dall’amministratore;

− possibilità di isolamento di porte specifiche dalle altre porte dello switch con possibilità delle porte protette di comunicazione solo con l’uplink;

− funzionalità di blocco al collegamento alla rete di determinati indirizzi MAC configurati;

− metodi di autenticazione di utenti multipli:

▪ IEEE 802.1;

▪ autenticazione basata su Web;

▪ autenticazione basata su MAC.

− protezione BPDU: blocco del protocollo Bridge Protocol Data Units (BPDU) sulle porte che non richiedono BPDU, impedendone gli attacchi;

− FTP sicuro: trasferimento sicuro dei file da/allo switch; protezione da download indesiderati dei file o da copia non autorizzata del file di configurazione dello switch;

− filtro per porte sorgente: consente solo alle porte specificate di comunicare tra di loro;

− crittografia di tutti i dati trasmessi per accesso sicuro CLI (command line interface) in remoto su reti IP;

− crittografia di tutto il traffico HTTP per un accesso sicuro all’interfaccia di gestione basata su browser nello switch;

− possibilità di richiedere autenticazione RADIUS o TACACS+ per l’accesso alla CLI degli switch;

− Link Layer Discovery Protocol (LLDP) IEEE 802.1AB: protocollo di rilevamento automatico dei dispositivi, per la mappatura facilitata da parte delle applicazioni di gestione della rete.

▪ Quality of Service (QoS):

− prioritizzazione layer 4: prioritizzazione basata sul port number TCP/UDP;

− prioritizzazione del traffico (IEEE 802.1p);

− Class of Service (CoS).

▪ gestibilità:

− gestione del dispositivo HTML e telnet;

− funzionalità avanzate di monitoraggio e reporting per statistiche, cronologia, allarmi ed eventi.

▪ altre funzionalità:

− adeguamento automatico per cavi diritti o crossover su tutte le porte 10/100/1000;

− possibilità di assegnazione di nomi descrittivi alle porte.

▪ accessori da fornire:

− numero 4 Mini-GBIC Gigabit-SX-LC.

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n.	Descrizione potenziamento infrastruttura virtuale	U.m.	Q.tà
	Sistema di storage
	store processor - 12x 600 SAS - protocolli iSCSI FC- NFS CIFS, Snap Mirror (incluse licenze sincronizzazione e replica dati tra SAN)	cad.	2
	Switch FC connettività storage-VMWare	cad.	3
[Rs9]	HBA FC single port per host in uso HP AP769A	cad.	6
	VMware vSphere 5 Enterprise for 1 processor

[Rs10]

[Rs11]

(Max 12 cores per processor) (SNS is Required) cod: VS4-ADV-C

Basic Support/Subscription for VMware vSphere Enterprise for 1 processor for 1 year

(Technical Support, 12 Hours/Day, per published Business Hours, Mon. thru Fri. ) cod:VS4-ADV-G-SSS-C

Switch infrastruttura virtuale

(ciascuno completo di 4 Mini-GBIC Gigabit-SX-LC)

cad. 4

cad. 2

[Rs12]

Server HOST VMWare

HP DL380G6 DL380G6 doppio processore Intel® Xeon® Processor E5520 (2.26 GHz, 8MB X0 Xxxxx, 00X, XXX0-0000, HT, Turbo 1/1/2/2)

20 GB PC3-10600R (DDR3-1333)

Alimentatore ridondante, 6 schede di rete GigabitE, 2 hd 72GB SAS 10k +

2 HBA FC single port AP769A

Tabella 12 Dettaglio potenziamento infrastruttura virtuale ASL 4

cad. 2

4.3.2 Adeguamento sistema di connettività (firewall e intranet data center)

Facendo riferimento allo schema di rete sopra riportato (Figura 6), che potremmo considerare come “definitivo”, al fine di potersi affidare a soluzioni proprietarie di certificata affidabilità, si ipotizza l'acquisizione di apparati che implementino le seguenti funzionalità:

[Rs13] Specifiche funzionali firewall

▪ il traffico in ingresso ed in uscita contro worm, spyware, trojan e malware e funzionalità di stateful firewall;

▪ VPN IPSec;

▪ IPS, IDS;

▪ Antivirus (comprendente anche Anti-Spyware, Anti-Adware, Anti-Phishing);

▪ Anti-Spam;

▪ Web filtering.

L'abbandono delle soluzioni di tipo “open source” andrà a favore di uno scenario di installazione di prodotti e di attivazione di servizi di assistenza e supporto di indubbia professionalità e certificazione.

In aggiunta alla soluzione di firewalling suddetta, è necessaria l'acquisizione di un sistema di gestione client VPN (con possibilità di applicazione dei criteri e controllo dell'accesso alla rete) utile per la regolamentazione degli accessi esterni da parte delle aziende fornitrici di prodotti software e hardware per le quali si hanno in essere contratti di manutenzione e assistenza. Le medesime funzionalità possono comunque essere implementate anche dal firewall.

Per la connettività ridondata tra CED e ospedale sono richiesti due firewall con funzionalità di VPN-IDS- Content Filtering e con le seguenti specifiche tecniche:

▪ prestazioni del firewall (IMIX) : non inferiore a 300 Mbps;

▪ prestazioni del firewall (pacchetti di grandi dimensioni): 350+ Mbps

▪ pacchetti firewall al secondo: non inferiore a 100,000 PPS;

▪ prestazioni VPN 3DES+SHA-1 : non inferiore a 100 Mbps;

▪ numero massimo di sessioni simultanee: non inferiore a 48,000;

▪ tunnel VPN simultanei: non inferiori a 500;

▪ numero massimo di router virtuali : non inferiori a 6 ;

▪ numero massimo di LAN virtuali: non inferiori a 100;

▪ porte I/O fisse: non inferiori a 8x10/100, e 2x10/100/1000;

▪ slot di espansione per moduli di interfaccia fisica (PIM): 4 o superiore;

▪ 512 MB di memoria o superiore;

▪ funzionalità di VPN – IDS – Content Filtering incluse

▪ configurabile in alta affidabilità con modello uguale;

▪ High Availability (HA):

− active/active - L3 mode;

− active/passive - Transparent & L3 mode;

− configuration synchronization;

− session synchronization for firewall and VPN;

− device failure detection;

− link failure detection;

− authentication for new HA members;

− encryption of HA traffic.

▪ protocolli di gestione: SNMP 2, SNMP, Telnet, HTTP, HTTPS;

▪ protocolli di rete supportati: NetBEUI/NetBIOS, L2TP, IPSec, PPPoE;

▪ protocollo data link: Ethernet, Fast Ethernet, Gigabit Ethernet, HDLC, Frame Relay, PPP, MLPPP, FRF.15, FRF.16;

▪ protocollo di routing: OSPF, RIP-1, RIP-2, BGP, static IP routing, ECMP;

▪ algoritmi di sicurezza supportati: DES, Xxxxxx XXX, XXX, XX0, XXX, XXX, XXX-0, XXX;

▪ metodo di autenticazione: SSH, RADIUS, X.000, XXX0, XXXX;

▪ network attack detection;

▪ DoS and DDoS protection;

▪ TCP reassembly for fragmented packet protection;

▪ brute force attack mitigation;

▪ SYN cookie protection;

▪ Zone-based IP spoofing ;

▪ malformed packet protection;

▪ protocols scanned: POP3, HTTP, SMTP, IMAP, FTP, IM;

▪ antispyware;

▪ antiadware;

▪ anti-keylogger;

▪ instant message AV;

▪ antispam;

▪ integrated URL filtering;

▪ external URL filtering;

▪ IP Address Assignment:

− Static;

− Dynamic Host Configuration Protocol (DHCP);

− Point-to-Point Protocol over Ethernet (PPPoE) client;

− internal DHCP server;

− DHCP relay.

Per la connettività delle varie sedi del territorio della ASL sono richiesti sei firewall con le seguenti caratteristiche:

▪ prestazioni del firewall (IMIX) : non inferiore a 90 Mbps;

▪ prestazioni del firewall (pacchetti di grandi dimensioni): non inferiore a 160 Mbps;

▪ pacchetti firewall al secondo: non inferiore a 30,000 PPS;

▪ prestazioni VPN 3DES+SHA-1: non inferiore a 40 Mbps;

▪ numero massimo di sessioni simultanee: non inferiore a 10000;

▪ tunnel VPN simultanei: non inferiori a 40;

▪ numero di router virtuali: non inferiori a 4;

▪ numero di LAN virtuali: non inferiori a 40;

▪ porte I/O fisse: non inferiori a 5x10/100;

▪ slot di espansione per moduli di interfaccia fisica (PIM): 2 o superiore;

▪ 128 MB di memoria o superiore;

▪ funzionalità di VPN – IDS – Content Filtering incluse;

▪ configurabile in alta affidabilità con modello uguale;

▪ High Availability (HA):

− active/active - L3 mode;

− active/passive - Transparent & L3 mode;

− configuration synchronization;

− session synchronization for firewall and VPN;

− device failure detection;

− link failure detection;

− authentication for new HA members;

− encryption of HA traffic.

▪ protocolli di gestione: SNMP 2, SNMP, Telnet, HTTP, HTTPS;

▪ protocolli di rete supportati: NetBEUI/NetBIOS, L2TP, IPSec, PPPoE;

▪ protocollo data link: Ethernet, Fast Ethernet, Gigabit Ethernet, HDLC, Frame Relay, PPP, MLPPP, FRF.15, FRF.16;

▪ protocollo di routing: OSPF, RIP-1, RIP-2, BGP, static IP routing, ECMP;

▪ algoritmi di sicurezza supportati: DES, Xxxxxx XXX, XXX, XX0, XXX, XXX, XXX-0, XXX;

▪ metodo di autenticazione: SSH, RADIUS, X.000, XXX0, XXXX;

▪ network attack detection;

▪ DoS and DDoS protection;

▪ TCP reassembly for fragmented packet protection;

▪ brute force attack mitigation;

▪ SYN cookie protection;

▪ Zone-based IP spoofing ;

▪ malformed packet protection;

▪ protocols scanned: POP3, HTTP, SMTP, IMAP, FTP, IM;

▪ antispyware;

▪ antiadware;

▪ anti-keylogger;

▪ instant message AV;

▪ antispam;

▪ integrated URL filtering;

▪ external URL filtering;

▪ IP Address Assignment:

− Static;

− DHCP, PPPoE client;

− Internal DHCP server;

− DHCP relay.

Per la connettività LAN interna del nuovo poliambulatorio di Tortolì è richiesto uno switch con le seguenti caratteristiche:

▪ switch modulare layer 2/3/4;

▪ almeno 6 slot disponibili per moduli;

▪ supporto di almeno 16 porte 10 GbE oppure 144 porte 10/100/1000 autosensing o 96 mini- GBIC o una combinazione;

▪ almeno 48 porte 10/100/1000 rj45 (IEEE 802.3 Type 10BASE-T, IEEE 802.3u Type 100BASE- TX, IEEE 802.3ab Type 1000BASE-T) suddivise al massimo in 3 slot;

▪ munito di modulo con almeno 4 porte con mini-GBIC installati;

▪ prestazioni:

− capacità di routing/switching: non inferiore a 370 Gbps;

− throughput: non inferiore a 280 milioni di pps;

− dimensioni tabella di routing: non inferiore a 10000 voci.

▪ spanning tree multipli e supporto legacy per IEEE 802.1d e IEEE 802.1w;

▪ trunking distribuito da server a switch: consente il collegamento di un server a due switch con un trunk logico che consiste di connessioni fisiche multiple;

▪ prioritizzazione layer 4: prioritizzazione basata sul port number TCP/UDP;

▪ possibilità di limitazione di velocità basata sulla porta: larghezza di banda massima di ingresso/uscita per porta;

▪ possibilità di classificazione del traffico mediante più criteri di corrispondenza basati su dati Layer 2, 3 e 4;

▪ aggiunta o sostituzione di moduli, mini-GBIC e alimentatori in una configurazione con alimentatori ridondanti senza interruzione della rete;

▪ Connettività:

− IEEE 802.3af Power over Ethernet (PoE): fino a 15,4 W per porta per dispositivi di alimentazione PoE conformi a IEEE 802.3af quali telefoni IP, wireless access point e telecamere di sicurezza;

− IEEE 802.3at Power Over Ethernet Plus: fino a 30 W per porta per dispositivi di alimentazione PoE/PoE+ conformi a IEEE 802.3 quali video telefoni IP, wireless access point IEEE 802.11n e telecamere di sicurezza PTZ avanzate.

▪ switching layer 2:

− supporto simultaneo di standard IEEE 802.1Q e 2.048;

− VLAN rilevamento automatico e assegnazione dinamica delle VLAN.

▪ routing layer 3:

− routing IP statico: consente di configurare manualmente l'instradamento per reti IPv4 e IPv6.

▪ sicurezza:

− Access Control List (ACL): offre filtri basati sul campo IP, su sorgente/destinazione dell'indirizzo IP/sottorete e sorgente/destinazione del port number TCP/UDP per VLAN o per porta;

− metodi di autenticazione di utenti multipli:

▪ utenti IEEE 802.1X per porta;

▪ autenticazione basata su Web;

▪ autenticazione basata su MAC.

− rilevazione schemi di traffico tipici per le attività di virus di tipo worm e controllo o inibizione completa della capacità del virus di diffondersi nelle VLAN o nelle interfacce bridge, senza richiedere dispositivi esterni;

− protezione DHCP: blocco di pacchetti DHCP da server DHCP non autorizzati;

− accesso sicuro alla gestione;

− ACL basata su identità;

− accesso consentito solo a indirizzi MAC specificati dall’amministratore;

− possibilità di isolamento di porte specifiche dalle altre porte dello switch con possibilità delle porte protette di comunicazione solo con l’uplink;

− funzionalità di blocco al collegamento alla rete di determinati indirizzi MAC configurati;

− RADIUS/tACACS+: gestione della sicurezza degli switch utilizzando un server di autenticazione delle password;

− FTP sicuro: trasferimento sicuro dei file da/allo switch; protezione da download indesiderati dei file o da copia non autorizzata del file di configurazione dello switch;

− filtro per porte sorgente: consente solo alle porte specificate di comunicare tra di loro;

− crittografia di tutto il traffico HTTP per un accesso sicuro all’interfaccia di gestione basata su browser nello switch.

▪ Quality of Service (QoS):

− prioritizzazione layer 4: prioritizzazione basata sul port number TCP/UDP;

− prioritizzazione del traffico (IEEE 802.1p);

− Class of Service (CoS).

▪ gestibilità:

− gestione del dispositivo HTML e telnet;

− funzionalità avanzate di monitoraggio e reporting per statistiche, cronologia, allarmi ed eventi.

▪ altre caratteristiche:

− possibilità di installazione in rack standard EIA da 19” per telecomunicazioni (minuteria accessoria inclusa);

− alimentazione ridondata (interna o esterna);

− adeguamento automatico per cavi diritti o crossover su tutte le porte 10/100/1000;

− possibilità di assegnazione di nomi descrittivi alle porte.

Sempre per la connettività LAN interna del nuovo poliambulatorio di Tortolì è richiesto un altro switch con le seguenti specifiche:

▪ switch layer 2/3/4;

▪ almeno 20 porte 10/100 rj45 (IEEE 802.3 Type 10Base-T, IEEE 802.3u Type 100Base-TX, IEEE 802.3ab Type 1000Base-T);

▪ numero 4 porte dual-personality per connettività 10/100/1000 con RJ-45 o in fibra ottica Gigabit con mini-GBIC;

▪ prestazioni:

− capacità di routing/switching: non inferiore a 12 Gbps;

− throughput: non inferiore 8 milioni di pps a 64 byte;

− dimensioni tabella di routing: non inferiore a 10000 voci.

▪ fino 60 trunk, ciascuno con 8 collegamenti (porte) per trunk;

▪ spanning tree multipli e supporto legacy per IEEE 802.1d e IEEE 802.1w;

▪ possibilità di installazione. in rack standard EIA da 19” per telecomunicazioni (minuteria accessoria inclusa);

▪ switching layer 2:

− supporto simultaneo per IEEE 802.1Q (4.096 ID VLAN) e 0000 XXXX;

− rilevamento automatico e assegnazione dinamica delle VLAN.

▪ routing layer 3:

− routing IP statico: consente di configurare manualmente l'instradamento per reti IPv4 e IPv6.

▪ Sicurezza:

− accesso consentito solo a indirizzi MAC specificati dall’amministratore;

− possibilità di isolamento di porte specifiche dalle altre porte dello switch con possibilità delle porte protette di comunicazione solo con l’uplink;

− funzionalità di blocco al collegamento alla rete di determinati indirizzi MAC configurati;

− metodi di autenticazione di utenti multipli:

▪ IEEE 802.1;

▪ autenticazione basata su Web;

▪ autenticazione basata su MAC.

− protezione BPDU: blocco del protocollo Bridge Protocol Data Units (BPDU) sulle porte che non richiedono BPDU, impedendone gli attacchi;

− FTP sicuro: trasferimento sicuro dei file da/allo switch; protezione da download indesiderati dei file o da copia non autorizzata del file di configurazione dello switch;

− filtro per porte sorgente: consente solo alle porte specificate di comunicare tra di loro

− crittografia di tutti i dati trasmessi per accesso sicuro CLI (command line interface) in remoto su reti IP;

− crittografia di tutto il traffico HTTP per un accesso sicuro all’interfaccia di gestione basata su browser nello switch;

− possibilità di richiedere autenticazione RADIUS o TACACS+ per l’accesso alla CLI degli switch;

− Link Layer Discovery Protocol (LLDP) IEEE 802.1AB: protocollo di rilevamento automatico dei dispositivi, per la mappatura facilitata da parte delle applicazioni di gestione della rete.

▪ Quality of Service (QoS):

− prioritizzazione layer 4: prioritizzazione basata sul port number TCP/UDP;

− prioritizzazione del traffico (IEEE 802.1p);

− Class of Service (CoS).

▪ gestibilità:

− gestione del dispositivo HTML e telnet;

− funzionalità avanzate di monitoraggio e reporting per statistiche, cronologia, allarmi ed eventi.

▪ altre caratteristiche:

− adeguamento automatico per cavi diritti o crossover su tutte le porte 10/100/1000;

− possibilità di assegnazione di nomi descrittivi alle porte.

▪ accessori da fornire:

− numero 4 Mini-GBIC Gigabit-SX-LC.

Lo schema sotto riportato esemplifica la configurazione finale e gli apparati richiesti.

Figura 7 Schema semplificato infrastruttura di rete ASL 4

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n. Descrizione hw potenziamento lan aziendale U.m. Q.tà

Firewall per connettività ridondata CED Ospedale con funzionalità di VPN – IDS – Content cad. Firewall per connettività sedi territorio - IDS - WEB FILTERING ANNUALE + SUPPORTO cad.			2
	ANNUALE
	Firewall per connettività sedi territorio tramite rete MAN – VPN.	cad.	4
	Soluzione di gestione degli accessi VPN dinamici	cad.	1
	Potenziamento connettività lan interna al data center
[Rs14]	Hp Procurve Switch 16P Module Xl 10 100 1000 Mbps	cad.	2
	Connettività LAN interna nuovo poliambulatorio Tortolì
	Switch tipologia 1	cad.	1
	Switch tipologia 2	cad.	1

Filtering.

Tabella 13 Fornitura potenziamento LAN aziendale ASL 4

4.3.3 Sistema centralizzato di raccolta log e controllo accessi

L’intervento è costituito da due azioni:

1. Acquisizione di un sistema centralizzato di raccolta e conservazione dei LOG:

[Rs15] Specifiche funzionali:

▪ archiviazione di LOG;

▪ verifica integrità dei dati;

▪ log retention per almeno 6 mesi. I Log dovranno poter essere raccolti da:

▪ eventi di rete;

▪ log di sicurezza;

▪ log di applicazioni e host.

2. Acquisizione di un sistema di CA che dovrà assicurare le seguenti:

[Rs16] Specifiche funzionali:

▪ gestione centralizzata delle autenticazioni ed autorizzazioni degli utenti privilegiati;

▪ tracciabilità e auditing degli accessi nominali;

▪ gestione delle password di utenti privilegiati (per sistemi e applicazioni) senza installazione di agenti;

▪ rilascio controllato e nominale delle credeziali delle utenze amministrative;

▪ accesso d’emergenza in caso di fault;

▪ check-in (restituzione) forzato o schedulato delle credenziali;

▪ realizzazione della sicurezza a livello di kernel del S.O.;

▪ tracciabilità e auditing di tutto l'operato degli utenti privegiati (agent-based);

▪ limitazione dei privilegi degli amministratori di sistema;

▪ garanzia dell'integrità dei log sul sistema dove sono stati generati;

▪ generazione dei log degli accessi nominali anche in conseguenza a "surrogate user" (comando “su”);

▪ limitazione degli accessi a risorse come File/Cartelle, Processi/Servizi/Applicazioni, Registri e Log;

▪ definizione delle policy, degli account e delle password e distribuzione per tipologia di S.O., server o applicazione.

L’hardware fornito andrà dedicato esclusivamente per l’installazione del software di raccolta log e controllo accessi. In aggiunta alle specifiche tecniche minime da supportare dovrà essere garantito dal fornitore massima compatibilità tra l’hardware e il software di raccolta log e controllo accessi che verrà fornito.

L’hardware fornito dovrà in ogni caso supportare le seguenti specifiche operative:

▪ 2500 o superiore eventi per secondo;

▪ numero minimo di 750 devices esterni supportabili;

▪ numero minimo di flussi al minuto: 100.000. Requisiti minimi hardware:

▪ almeno 1 processore a sei core con frequenza non inferiore a 2400 MHz;

▪ RAM: non inferiore a 8 GB;

▪ L2 cache: non inferiore a 6 MB;

▪ spazio disco: non inferiore a 1,5 Terabyte in raid 5;

▪ tipologia HDD: SAS 10K 2.5in;

▪ unità ottica DVD;

▪ networking: non inferiore a numero 2 porte Gigabit;

▪ possibilità di installazione. in rack standard EIA da 19” (minuteria accessoria inclusa);

▪ massime unità occupabili a rack: 3;

▪ alimentazione ridondata;

▪ fornitura licenze ed installazione di eventuale sistema operativo sul quale installare il software di raccolta log e controllo accessi;

▪ inserimento apparato in Rack;

▪ installazione e start-up software di raccolta log e controllo accessi;

▪ verifica funzionalità e test.

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n. Descrizione sistema centralizzato log e controllo accessi	U.m.	Q.tà
Licenze software	cad.	1
Server per sistema centralizzato di raccolta log e controllo accessi Servizi:	cad.	1
- Assemblaggio HW presso LAB - Spedizione con consegna al piano - Installazione S.O. - Inserimento Apparato in Rack - Configurazione LAN - Verifica Funzionalità e Test - Ritiro Cartoni
Servizi Professionali controllo accessi e gestione log:
Installazione e Start-Up - Training On the Job

Tabella 14 Dettaglio Sistema centralizzato log e controllo accessi ASL 4

4.3.4 Armadio ignifugo per conservazione di backup

E’ necessario procedere alla acquisizione di un nuovo armadio ignifugo opportunamente capiente e che risponda alle certificazione di conformità alla norma EN 1047-1 che sancisce le caratteristiche tecniche degli armadi adibiti a contenitori di unità dati, con riferimento alla resistenza al fuoco, all’acqua, ai gas, ecc. e la norma EN 1143-1 che stabilisce le caratteristiche tecniche antiscasso per le cassaforti.

La soluzione proposta è un armadio per backup magneto-ottico con le seguenti caratteristiche:

▪ classificazione anti-scasso (in accordo con a EN 1047-1): S 120 DIS;

▪ capacità in litri: non inferiore a 500;

▪ almeno 3 ripiani estraibili e 2 divisori;

▪ serratura elettronica;

▪ trasporto e posizionamento incluso nell’offerta;

▪ dimensioni massime larghezza varco porta per accesso sala backup: 800 mm.

5 Progetto di adeguamento ASL n°5 di Oristano

In questo capitolo sono riportate le soluzioni tecnologiche e le specifiche tecniche e funzionali relative alla proposta progettuale di adeguamento delle infrastrutture hardware/software presentata dall’Azienda Sanitaria Locale n°5 di Oristano nell’ambito del Progetto INFRAS ICT.

Interventi INFRAS ICT ASL 5 Oristano priorità

Consolidamento e virtualizzazione dei sistemi aziendali IP1

Virtualizzazione deille postazioni di lavoro client IP2

Tabella 15 Interventi e priorità ASL5

5.1 Contesto di riferimento

I sistemi informativi aziendali dell’Azienda Sanitaria Locale n° 5 sono ubicati xxxxxx xx xxxx xx xxx Xxxxxxxx, 00 ad Oristano.

Attualmente i locali non sono idonei soprattutto dal punto di vista delle infrastrutture e degli impianti e, per tale ragione nell’ambito del progetto INFRAS-CED, si è data priorità agli interventi di adeguamento strutturale, relativi ai locali ma che non sono oggetto della presente gara d’appalto.

Una volta rinnovato il locale, troveranno collocazione:

▪ N. 1 armadio rack 19” 42 U di dimensione 205,7x60x100 cm, contenente il server del sistema SISaR;

▪ N. 3 armadi rack 19” contenenti server aziendali;

▪ N. 1 armadio rack 19” per networking;

▪ N. 20 application server.

Allo stato attuale, l’ASL di Oristano nel proprio CED dispone di quattro clusters Fujitsu sui quali sono installati diverse applicazioni ma queste macchine, oramai obsolete, non garantiscono livelli accettabili di affidabilità ed hanno costi di manutenzione elevati.

I servizi gestiti internamente, oltre quelli forniti dal SISaR, sono:

▪ Posta elettronica;

▪ DNS;

▪ Bacheca aziendale;

▪ Cartella Diabetologica;

▪ Emodinamica;

▪ Anatomia Patologica;

▪ software di acquisizione timbrature;

▪ cartella per Nefrologia e Dialisi;

▪ Ser.D;

▪ sistema esperto per i DRG e PARM per l’analisi dei DRG;

▪ il gestionale per i Centri TAO;

▪ Laboratorio Analisi (SILUS);

▪ Scelta/Revoca;

▪ una discreta quantità di piccoli pacchetti verticalizzati o open source.

La numerosità dei servizi erogati si traduce in una moltitudine di macchine: la ASL 5 di Oristano infatti ha un discreto numero di server fisici presenti all’interno della propria struttura (basati su processori Intel) caratterizzati da un ampio spettro di tecnologie e di configurazioni. Questi sistemi, finora in genere dedicati ciascuno ad un singolo servizio applicativo, presentano sicuramente la caratteristica di un limitato consumo di risorse elaborative e naturalmente generano conseguenti diseconomie di rapporto costi/utilizzo.

5.2 Obiettivi

Il consolidamento dei server permetterebbe alla ASL di passare da uno scenario costituito da un elevato numero di sistemi, spesso obsoleti e non scalabili, verso una architettura moderna e più performante costituita da un numero di sistemi molto minore ed adeguata a rispondere alle esigenze di crescita e flessibilità.

La realizzazione di un ambiente centralizzato e partizionato permetterebbe di sfruttare al meglio l’utilizzo delle risorse dei sistemi, condividendoli tra più istanze di servizi applicativi, rendendo più efficiente l’infrastruttura.

Inoltre si vuole avviare un processo che preveda la virtualizzazione delle postazioni di lavoro client, sia pur in una prima fase iniziale e parziale, al fine di ridurre l’alto costo di gestione derivante dal mantenimento in corretto stato di servizio del parco personal computer.

5.3 Interventi

Gli interventi previsti nell’ambito del progetto INFRAS ICT saranno meglio dettagliati nei paragrafi successivi. Si tratta di interventi premianti.

5.3.1 Consolidamento e virtualizzazione

Le motivazioni che hanno portato al proliferare dei server fisici sono molteplici:

▪ differenti livelli di Sistema Operativo quale requisito dei diversi applicativi in uso;

▪ garantire le prestazioni applicative: una macchina in produzione potrebbe degradare il suo livello di servizio se destinata a svolgere funzioni ulteriori,

▪ garantire ambienti separati tra i diversi fornitori di soluzioni applicative;

▪ evitare che un qualsiasi applicativo possa mandare in crash la macchina e di conseguenza bloccare gli altri servizi eventualmente co-ospitati;

▪ incompatibilità di ambiente tra applicativi.

Il risultato è stato quindi un inevitabile proliferare di hardware che tuttavia viene sfruttato generalmente intorno al 10-20% delle sue potenzialità.

Lo studio alla base di questo progetto evidenzia la necessità di consolidare il parco dei server esistenti ed al contempo garantire ed innalzare il livello di continuità di servizio anche in caso di malfunzionamento di una macchina.

Tuttavia, la soluzione tecnologica non adottabile per il 100% delle casistiche, poiché esistono situazioni in cui i requisiti applicativi richiedono sempre hardware dedicato (non virtualizzato), mentre nella maggioranza dei casi è possibile virtualizzare e/o consolidare diverse istanze applicative in un unico server, come nel caso di alcuni database.

La soluzione di consolidamento su macchine virtuali ospitate su un numero limitato di server di potenza adeguata è estremamente efficiente nell’ottica del mantenimento delle prestazioni, della semplificazione della gestione, e soprattutto nella capacità di adattamento della struttura IT alle evoluzioni richieste dalla Direzione Generale. Ai fini di ottenere il massimo risultato, tale processo si deve anche basare sull’acquisizione di nuove e potenti unità server, tecnologicamente avanzate, grazie alle quali è possibile diminuire:

▪ la probabilità statistica dei guasti hardware;

▪ le difficoltà di gestione del parco macchine;

▪ la complessità di cablaggio e le necessità di alimentazione elettrica;

▪ l’impegno delle risorse umane necessarie per le attività di gestione.

Il progetto prevede, quindi, di affrontare il tema del consolidamento tramite l’acquisizione di sistemi Blade e la piattaforma di virtualizzazione VMware vSphere quali soluzioni tecnologiche sinergiche per l’adeguamento e l’ammodernamento degli ambienti server di produzione, ed in funzione della rinnovata capacità elaborativa anche gli ambienti di sviluppo/collaudo.

L’adozione di una infrastruttura virtualizzata, al fine di garantire alta affidabilità e continuità di servizio, presuppone che il sistema sia collegato ad unità di memoria di massa (storage) anch’essa dotata di meccanismi per garatire la massima disponibilità delle risorse, e facente parte di un sottosistema di Storage Area Network (SAN). In tal modo, il processo di consolidamento incide anche sulle tematiche e problematiche relative alle risorse disco.

I benefici attesi dall’implementazione di tali politiche sono:

▪ ottimizzazione dello spazio disco utilizzato;

▪ maggiore flessibilità in termini di allocazione, ri-assegnazione e dimensionamento dinamico dello spazio disco per le singole applicazioni;

▪ possibilità di utilizzare livelli di protezione dei dati in maniera flessibile;

▪ migliore distribuzione dei dischi fisici tesa all’ottimizzazione delle prestazioni.

Le macchine virtuali, per esempio, potranno avviarsi direttamente dallo storage server in SAN, in modo che l’eventuale malfunzionamento del server fisico che le contiene consenta la ri-attivazione della relativa VM da un altro server fisico. Inoltre, tutti i sistemi VMware saranno in grado di accedere allo storage e di fruire di funzionalità come VMotion che consente di eseguire il failover delle VM tra i diversi nodi della piattaforma. Naturalmente, la SAN viene configurata con “multipath”.

Il dimensionamento dello spazio sulla SAN è stimato essere intorno ai 3 TB minimo.

Infine, per garantire la massima affidabilità agli applicativi maggiormente critici saranno realizzati, dove necessario, soluzioni di clustering tra VM distribuendole su sistemi VMware diversi: questa soluzione può utilizzare tecnologie standard di Microsoft Windows (MSCS) o di Linux, opportunamente combinate tra macchine virtuali e macchine fisiche.

La piattaforma virtuale sarà gestita tramite i tool di management vCenter cui sarà affiancato anche un sistema per il salvataggio delle immagine delle VM (VCB o simili).

A completamento del sistema, è prevista anche l’acquisizione di una unità di backup a nastro del tipo libreria in tecnologia LTO dotata di adeguato software per il backup canonico dei dati.

In base alle preliminari analisi di utilizzo e prestazione dei sistemi esistenti si stima che siano sufficienti n°3 lame Blade (+1 di hot spare per bilanciamento/failover), oltre ai sistemi vCenter e VCB.

5.3.2 Virtualizzazione postazioni di lavoro

Poiché il prodotto VMware View 5 utilizza la virtualizzazione data dalla base della struttura vSphere 5 per rimuovere i vincoli tra il desktop e l'hardware, il sistema operativo e le applicazioni correlate, raggruppando e distribuendo dinamicamente desktop e applicazioni in modo che gli utenti abbiano una visualizzazione personalizzata del proprio desktop, la ASL n° 5 intende avviare un processo di virtualizzazione parziale del mondo desktop ed inizialmente circoscritto ad una specifica classe di utenza.

Tale soluzione, in breve, consente di rendere disponibili i PC client come servizio gestito dalla piattaforma, e consente al SIA dell’azienda di gestire in modo indipendente sistemi operativi, applicazioni e utenti.

Si intende rendere disponibile il servizio per un numero iniziale di circa 30 desktop virtuali. A tal fine è necessario prevedere la fornitura di una ulteriore lama Blade.

6 Progetto adeguamento ASL n°7 di Carbonia

In questo capitolo sono riportate le soluzioni tecnologiche e le specifiche tecniche e funzionali relative alla proposta progettuale di adeguamento delle infrastrutture hardware/software presentata dall’Azienda Sanitaria Locale n°7 di Carbonia nell’ambito del Progetto INFRAS ICT.

Interventi INFRAS ICT ASL 7 Carbonia priorità

Sostituzione switch centro stella sala server O

Collegamento radio CED – CTO - X. Xxxxxxx X

Sostituzione apparati di sicurezza IP10

Tabella 16 Interventi e priorità ASL7

6.1 Contesto di riferimento

La sala CED aziendale è ubicata presso una sede relativamente nuova, in via Gorizia snc ad Iglesias. Dal punto di vista dell’infrastruttura di base sono state riscontrate alcune inefficienze operative degli ambienti oltre che carenze sulla sicurezza del locale; dovranno quindi essere oggetto di intervento sia alcune opere edili che gli adeguamenti degli impianti di climatizzazione, controllo accessi e sicurezza, rilevazione fumi e spegnimento della sala server.

Relativamente al networking, le maggiori criticità si sono rilevate relativamente alla obsolescenza degli apparati.

6.2 Obiettivi

Gli obiettivi relativi agli interventi ICT del progetto INFRAS sono i seguenti:

1. potenziamento della infrastruttura di rete interna alla server farm di via Gorizia;

2. realizzazione di collegamenti in rete geografica tra la server farm ed il CTO e Santa Barbara;

3. razionalizzazione e potenziamento della infrastruttura di sicurezza della server farm.

6.3 Interventi

6.3.1 Sostituzione switch centro stella sala server

Si prevedono n. 2 apparati per la server farm interconnessi agli switch di centro stella di palazzo in aggregazione di canali (Port-Channel) per la massima affidabilità del sistema. Eventuali espansioni dovranno poter essere implementate successivamente aggiungendo apparati alla matrice.

Gli apparati dovranno essere di classe enterprise di ultima generazione, fornire connettività 24 porte 10/100/1000 ed essere collegabili in stack, in modo tale da fornire all’utilizzatore una macchina unica con almeno 64 Gbps di throughtput.

La macchina dovrà essere equipaggiata con ridondanza di alimentazioni e ventole, avere funzionalità base di livello 3 con la gestione del routing dinamico; consentire espandibilità di interfacce di connettività in FO di almeno 2 interfacce SFP o 2 interfacce 10GBE per apparato.

La matrice risulterà interamente ridondata (i servizi di routing/Qos vengono garantiti con continuità anche in caso di caduta di uno switch), dovrà supportare servizi di connettività in alta affidabilità garantendo canali aggregati (Port channel/teaming) su switch differenti.

6.3.2 Collegamento radio CED – CTO - X. Xxxxxxx

Al fine di potenziare la rete geografica tra il CED e i presidi ospedalieri di Iglesias, anche in vista della prossima introduzione del sistema RIS – PACS, è necessario procedere alla realizzazione dei collegamenti radio tramite gli apparati come di seguito proposto:

▪ CED-CTO: una coppia di apparati completi di cablaggio al centro stella per la realizzazione del ponte radio tra il CED ed il presidio ospedaliero CTO;

▪ CED-X. Xxxxxxx: una coppia di apparati completi di cablaggio al centro stella per la realizzazione del ponte radio tra il CED ed il presidio ospedaliero X. Xxxxxxx.

Di seguito si forniscono le specifiche salienti degli apparati desiderati:

[Rs17] Specifiche tecniche apparati radio

▪ installabile con “autorizzazione generale”;

▪ sistema Punto-Punto 5 GHz (HIPERLAN);

▪ antenna Integrata 23dB oppure possibilità di antenna esterna;

▪ versione con antenna esterna: case metallico IP68 antivandalo in alluminio pressofuso con trattamento antiossidante Alodine 1200 e staffe di supporto al palo in acciaio inox;

▪ alimentazione Power Over Ethernet (P.O.E.) 48Vdc o 12Vdc;

▪ possibilita di aggiungere piu uscite radio RF;

▪ opzione: filtri RF passa-banda (5 GHz) per la miglior performance di collegamento e riduzione dei “battimenti” in banda RF;

▪ crittografia WPA2, WPA o WEP;

▪ radio type OFDM o DSSS;

▪ capacità NLOS;

▪ sistema di backup drag’n’drop;

▪ diagnostica di apparato “on board” o da remoto;

▪ upgrade software, monitoring e configurazione da remoto.

Sono ammessi in fornitura prodotti equivalenti o superiori per caratteristiche tecniche e funzionali.

6.3.3 Sostituzione apparati di sicurezza

Per quel che concerne la sicurezza IT della server farm, l’azienda intende procedere alla razionalizzazione della segmentazione della rete isolandola logicamente dalla LAN utenti. Per semplicità di gestione si preferisce mantenere un unico apparato di firewalling in configurazione cluster che gestisca il traffico tra i segmenti di Lan interna server farm, Internet, DMZ e Lan utenti.

Relativamente alla sicurezza informatica, ad oggi, la protezione perimetrale viene affidata ad un sistema firewall utilizzato come macchina di frontiera per l’accesso internet centralizzato. Tale macchina svolge funzioni di packet filtering, web filtering, IPS e antivirus. Le macchine sono al limite delle performance.

I due apparati attualmente in dotazione (n 2 Appliance Fortinet 200 in HA) eseguono la protezione perimetrale quale sistema firewall di frontiera per l’accesso internet centralizzato. Tale macchine svolgono funzioni di packet filtering, web filtering, IPS e antivirus e risultano al limite delle loro prestazioni e non sono adeguate alle esigenze di traffico, e per tale ragione è necessario sostituirli.

Al fine di preservare le competenze tecniche già acquisite dal personale operativo, la scelta degli apparati ricade su apparati Fortinet modello Fortigate 310B con funzionalità di HA, Load Balancing, IPS e antivirus che garantisce le prestazioni attese.

Attualmente per la gestione dei log, analisi e statistiche è in esercizio l’apparato Fortianalyzer 100B che non risulta certificato per gli apparati Fortigate 310B e, per tale ragione, va anch’esso sostituito dal modello Forti-analyser 100C, di caratteristiche decisamente superiori ed in grado di supportare il throughtput di traffico fornito dal nuovo sistema firewall.

[Rs18] Specifiche tecniche sistema firewall:

Maximum Firewall Throughput 8 Gbps (base) 12 Gbps w/AMC Maximum IPSec VPN Throughput 6 Gbps (base) 9 Gbps w/AMC Maximum Antivirus Throughput 160 Mbps

Maximum IPS Throughput 800 Mbps Maximum Concurrent Sessions 600,000

Network Interfaces 10 Copper GigE 10/100/1000 Base-T 4 GigE SFP w/AMC AMC expansion bays 1 single- width

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n.	Descrizione sintetica sistemi di sicurezza	U.m.	Q.tà
[Rs19]	FORFG-310B-BDL: NODO A Fortinet FortiGate 310B Bundle	cad.	1
[Rs20]	FORFG-310B-BDL: NODO B Fortinet FortiGate 310B Bundle	cad.	1
[Rs21]	FOR FORFAZ-100C: Fortinet FortiAnalyzer 100C	cad.	1

Tabella 17 Dettaglio apparati di sicurezza ASL7

7 Progetto adeguamento ASL n°8 di Cagliari

In questo capitolo sono riportate le soluzioni tecnologiche e le specifiche tecniche e funzionali relative alla proposta progettuale di adeguamento delle infrastrutture hardware/software presentata dall’Azienda Sanitaria Locale n°8 di Cagliari nell’ambito del Progetto INFRAS ICT.

Interventi INFRAS ICT ASL 8 Cagliari priorità

Potenziamento apparati di rete centro stella O

Adeguamento della sicurezza della rete geografica IP11

Tabella 18 Riepilogo interventi e priorità ASL8

7.1 Contesto di riferimento

Nell’Azienda Sanitaria n. 8 di Cagliari durante la fase di assessment preliminare sono emerse alcune forti criticità che riguardano:

▪ Aspetti ambientali e strutturali:

per aspetti ambientali e strutturali si intendono tutte le opere murarie ed edili, impianti elettrici, sistemi di climatizzazione, sistemi antincendio e antiallagamento, sistemi di controllo degli accessi, soluzioni per la continuità elettrica (UPS) atti a garantire un corretto funzionamento dell’intera sala server e degli apparati attivi installati in qualunque sede aziendale in caso di mancanza o sbalzi di corrente.

▪ Aspetti tecnici hardware/software:

per aspetti tecnici hardware e software si intendono le apparecchiature presenti quali: server, apparati attivi di rete (router, switch, firewall, ponti ottici e radio) ed i software di sistema: sistemi operativi, software di virtualizzazione, backup, monitoring, antivirus, antispam ed in generale di sicurezza informatica.

Inoltre, l’applicazione di nuove normative in termini di privacy e di sicurezza dei dati, il numero crescente di server e apparati di rete che in questi ultimi anni l’Azienda Sanitaria Locale N. 8 di Cagliari ha dovuto ospitare, hanno fatto sì che emergessero alcune criticità che limitano fortemente la sicurezza e il corretto funzionamento di tutto il software e l’hardware installato.

Criticità dell’infrastruttura tecnologica di networking

Da una analisi della situazione attuale relativamente alle criticità dell’attuale architettura networking emerge quanto segue:

▪ assenza di un sistema di firewalling nelle sedi collegate direttamente alla RTR:

− Sede Direzione Generale Selargius;

− PO SS Trinità;

− PO Businco;

− PO Microcitemico;

− PO Binaghi;

− PO Marino;

− Poliambulatorio Viale Trieste Cagliari;

− Sede Veterinari Via Nebida Cagliari;

− PO Muravera;

− PO Isili.

▪ assenza di uno switch di core per il centro stella aziendale adatto alle nuove esigenze.

7.2 Obiettivi

Gli obiettivi relativi agli interventi ICT del progetto INFRAS ICT sono sostanzialmente:

▪ potenziamento del centro stella della rete aziendale tramite l’aggiunta di un apparato di rete performante ed adeguato alle attuali esigenze di banda dei sistemi e della rete geografica;

▪ pdeguamento della sicurezza perimetrale della rete geografica relativa alle sedi periferiche, collegate tramite la rete telematica regionale tramite l’installazione di nuovi apparati di firewalling.

7.3 Interventi

7.3.1 Potenziamento apparati di rete centro stella

Si ritiene necessario procedere con il potenziamento e l’ammodernamento del centro stella aziendale mediante le acquisizioni di apparati di rete come di seguito dettagliato nella configurazione di dettaglio desiderata. Poiché l’intera piattaforma aziendale di livello 3 e 4 è di marca Cisco e si hanno in essere dei contratti per l’assistenza e manutenzione con ditte esterne specializzate in tali prodotti, gli apparati di networking di livello 3 e 4 dovranno essere di marca Cisco.

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n. Descrizione sintetica potenziamento centro stella aziendale u.m. Q.tà
Cisco cat6500 e series 9 slot chassis	Cad.	1
Unità processore centrale: supervisor 720 con 2 porte 10gbe e msfc3 pfc3c	Cad.	1
Unità processore centrale ridondata: supervisor 720 con 2 porte 10gbe e msfc3 pfc3c	Cad.	1
Alimentatore a 3000w ac	Cad.	1
Alimentatore ridondato a 3000w ac	Cad.	1
Cassetto ventole	Cad.	1
Scheda a 48 porte 10/100/1000baset (rj45)	Cad.	1
[Rs22] Scheda a 24 porte 1000basesx/lx connettori sc	Cad.	1

Modulo transceiver 1000base sx sfp per fibremultimodali (mmf), caratterizzato da lunghezza d’onda pari a 850 nm

Cad. 4

Scheda a 4 porte 10gbit xenpak Cad. 48

Modulo transceiver 10gbase lr xenpak per fibre multimodali (mmf), caratterizzato da lunghezza d’onda pari a 850 nm e connettore sc

Cad. 2

Catalyst 2960 24 10/100 + 2 uplink10/100/1000 o sfp Cad. 8

Catalyst 3560e 24 porte 10/100/1000 + uplink 1/10gb Cad. 2

Modulo transceiver 1000base sx sfp per fibre multimodali (mmf), caratterizzato da lunghezza d’onda pari a 850 nm

Ups da rack, 220V, 3kW , con scheda di rete e sw di spegnimento automatico apparecchiature

Tabella 19 Dettaglio potenziamento centro stella ASL8

Cad. 8

Cad. 2

7.3.2 Adeguamento della sicurezza della rete geografica

Dall’analisi delle criticità esposte nel contesto di riferimento della ASL 8, si renderebbe necessario, anche se con priorità inferiore, l’acquisto di apparati di firewalling a protezione delle sedi riportate nel medesimo contesto, al fine di portare il sistema di rete ad un livello di sicurezza adeguato alle norme vigenti in materia di sicurezza informatica.

Le caratteristiche minime firewall sono:

▪ prestazioni del firewall (pacchetti di grandi dimensioni): 350+ Mbps;

▪ prestazioni del firewall (IMIX): 300 Mbps;

▪ pacchetti firewall al secondo: 100,000 PPS;

▪ sessioni simultanee: 45,000;

▪ nuove sessioni al secondo: 8,000;

▪ aree di sicurezza: 40;

▪ router virtuali: 6;

▪ LAN virtuali: 100;

▪ porte I/O fisse: 8x10/100, 2x10/100/1000;

▪ slot di espansione per moduli di interfaccia fisica (PIM): 4.

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n.	Descrizione sintetica potenziamento sicurezza di rete	u.m.	Q.tà
	Firewall per adeguamento della sicurezza della rete geografica	cad.	10

Tabella 20 Dettaglio potenziamento sicurezza di rete ASL8

8 Progetto adeguamento AO X. Xxxxxx

In questo capitolo sono riportate le soluzioni tecnologiche e le specifiche tecniche e funzionali relative alla proposta progettuale di adeguamento delle infrastrutture hardware/software presentata dall’Azienda Ospedaliera “Brotzu” di Cagliari nell’ambito del Progetto INFRAS ICT.

Interventi INFRAS ICT AOB priorità

Completamento del processi di salvataggio dati IP6

Sistema centralizzato di gestione dei log IP7

Tabella 21 Riepilogo interventi e priorità AOB

8.1 Contesto di riferimento

L’applicazione di nuove normative in termini di privacy e di sicurezza dei dati, il numero crescente di server e apparati di rete che in questi ultimi anni l’Azienda Ospedaliera X.Xxxxxx ha dovuto ospitare, ha messo in rilievo alcune criticità che limitano fortemente la sicurezza ed il corretto funzionamento di tutto il software e l’hardware installato.

Gli aspetti che destano maggiore preoccupazione sono da distinguersi principalmente in due tipologie:

▪ Aspetti ambientali e strutturali. Per aspetti ambientali e strutturali si intendono tutte le opere murarie, edili, elettriche, i sistemi di climatizzazione, di antincendio e antiallagamento, di controllo degli accessi, di soluzioni per la continuità elettrica (Gruppo di continuità e UPS) atti a garantire un corretto funzionamento dei server e degli apparati attivi sia in sala server che nel resto dell’ospedale in caso di mancanza o sbalzi di corrente.

▪ Aspetti Tecnici (Hardware/Software).

Relativamente agli aspetti Tecnici (Hardware/Software), le maggiori criticità sono da distinguersi in due tipologie:

▪ Server

▪ Infrastruttura di Networking.

Nella sala server sono installati 7 rack di server composti dai seguenti server/storage:

MARCA	MODELLO	Q.TA’	RACK
SUN	FIRE X4100	7	1
OLIDATA	TEGEO	6	1
NETAPP	FIRE X4450	10	2
SUN	FIRE X4200	5	3
SUN	FIRE X2100	4	3

SUN	StorageTek SL24	1	3
SUN	StorageTek SL48	1	3
EMC	Celerra	8	4/5
HP	Proliant DL380	4	6/7
HP	Proliant DL380G5	1	6/7
HP	Proliant ML370	2	6/7
HP	Storagework MSA60	1	6/7
DELL	PowerEdge T710	1	6/7
HP	StorageWorks hsv100	2	6/7

Tabella 22 Dettaglio server/rack AO Brotzu

Di seguito i sistemi operativi utilizzati nei server fisici e virtuali gestiti dal personale dei Sistemi Informativi:

SISTEMA OPERATIVO	Q.TA’
WINDOWS XP PROFESSIONAL	5
WINDOWS 2003 SERVER	14
WINDOWS 2000 SERVER	2
WINDOWS 2008 SERVER ENTERPRISE	1
FEDORA	10
CENTOS 5.4/5.5	7
SUN SOLARIS 10	5
UBUNTU	1
VMWARE ESXi4.0 Update2	14
VMWARE ESXi 3.5	2

Tabella 23 Dettaglio SO

Il RACK1 è composto da 11 server e 1 storage in particolare 5 server fisici SUN, 5 server fisici Olidata, 1 storage NetApp e 1 Server fisico assemblato.

I 5 Server fisici Olidata sono dedicati alla virtualizzazione dei server fisici e hanno installato il sistema operativo VMWARE ESX 3.5/4.0 Update 2 (in via di dismissione e riutilizzo).

I 5 Server fisici modello SUN Fire X4100 con 8 GB di ram e 80 Gb disco fisso (2 dischi in RAID 1) dedicati a MAIL SERVER(1), DNS (1), Database Oracle 10.2 (3) N°1 NetApp FS270 composto da 28 dischi FC in raid 6, 5 TB netti di spazio disco utilizzabile, è usato come SAN per le VM (NFS), SAN Datafiles Database Oracle (NFS), SAN per server posta elettronica (NFS), Sincronizzazione Profili Microsoft Windows e File Sharing (CIFS).

N°1 Server Assemblato dedicato a servizi vari, quali file sharing e dati vari dei Sistemi Informativi. Il RACK2 è composto da:

▪ N° 10 Server SUN modello SUN FIRE x4450 con 32 Gb RAM e 3 dischi interni da 68 Gb in raid 1E;

▪ N°2 UPS RIELLO.

Il Sistema operativo installato nei 10 server è VMware ESXi 4.0 Update 2 dove risiedono oltre 40 Server virtuali che offrono i seguenti servizi principali:

▪ 2 Microsoft Active Directory Domain Controller (AD, DNS e DHCP);

▪ 1 DNS esterno;

▪ 1 Server Antispam;

▪ 1 Mail Relay;

▪ 1 FTP server;

▪ 3 Zimbra Collaboration Suite (di futuro utilizzo);

▪ 1 Zenoss (Sistema opensource di monitoraggio server e switch);

▪ 1 Sysaid (Sistema di gestione richieste helpdesk e inventario hardware e software);

▪ 2 Server Apache (Portale Intranet);

▪ 2 Application Server (Tomcat);

▪ 2 HL7 Server;

▪ 2 Server procedure Laboratorio Analisi;

▪ 2 Server MySql;

▪ 1 Console di Management dei Firewall;

▪ 3 Terminal Server;

▪ 1 Windows Update Service;

▪ 2 Server Eurotouch (Pediatria e Diabetologia);

▪ 1 Server Dosimetria;

▪ 1 Server Installazione sistemi operativo Windows (RIS);

▪ Altri.

Il RACK3 è dedicato alle applicazioni dipartimentali SISAR ed è composto da:

▪ N°2 Firewall FW-1050;

▪ Xx0 Xxxxxx XXX XXXX X0000;

▪ N°1 SUN StorageTek SL24;

▪ N°1 SUN StorageTek SL48;

▪ N°1 Batteria di 16 Dischi per lo storage. In sala server risiedono inoltre alcuni server fisici:

▪ N°3 Server fisici BULL EscalaT in via di dismissione con sistema operativo AIX 4.3.3;

▪ (vecchie procedure sanitarie e bilancio usate in consultazione per lo storico);

▪ N° 2 Server fisici IBM modello in via di dismissione con sistema operativo AIX 4.3.3 (storico magazzino , farmacia, centro trasfusionale);

▪ N°4 Server fisici modello vario con sistema operativo Windows Server.

Il RACK 4/5/6/7 ospita i server e lo storage per il programma di Diagnostica delle Immagini. I server sono elencati nel prospetto rack precedente.

I RACK 3/4/5/6/7 sono gestiti da personale esterno ad AOB.

Per quanto riguarda i server nei RACK 1, 2 e i server fisici, gestiti in prima persona dal personale dei Sistemi Informativi dell’Azienda Ospedaliera X.Xxxxxx, non è implementata nessuna politica centralizzata e consolidata di backup/recovery tranne che per le macchine virtuali per le quali i backup sono garantiti dagli snapshot eseguiti a caldo da parte della dello storage NetApp.

Le macchine virtuali non sono in cluster/failover (no VMotion) ma solo in ip failover in caso di rottura switch SAN/LAN.

L’azienda ha installato nei vari piani dell’ospedale diversi rack di rete che contengono in tutto circa 40 switch di rete.

Ogni rack è composto per la quasi totalità da switch di modello Linksys SRW2048 con porte gigabit ethernet. Ogni rack ha interconnesso almeno uno switch al centro stella tramite una bretella in fibra ottica sempre gigabit ethernet.

Il centro stella installato nel rack di rete in sala server è costituito da uno switch di core modello BlackDiamond 8800 a sua volta composto da uno switch 48 porte gigabit ethernet e 4 switch gigabit ethernet per connessioni in fibra ottica per un totale di 40 porte, scheda di management e alimentazione ridondata.

Il Rack di rete contiene inoltre 2 Firewall Clavister 4330b configurati in HA per tutte le connessioni INTERNET, RTR, server DMZ, accessi VPN, ecc. ,diversi switch linksys e l’attestazione della rete RTR Regionale.

La maggiore criticità riscontrata dell’infrastruttura di networking è la totale assenza di un sistema di protezione e continuità di corrente presente negli appositi rack ad eccezione del centro stella. Questa mancanza ha causato in questi anni diversi disservizi comportando, alcune volte, la rottura e quindi la sostituzione di diversi switch.

8.2 Obiettivi

Gli obiettivi relativi agli interventi ICT del progetto INFRAS ICT sono i seguenti:

▪ completamento dei processi di backup e restore;

▪ dotazione di strumenti di raccolta dei log per ottemperare ad obblighi di legge e migliore visibilità degli eventi di rete.

8.3 Interventi

Gli interventi previsti nell’ambito del progetto INFRAS ICT saranno meglio dettagliati nei paragrafi successivi. Si tratta di interventi premianti.

8.3.1 Completamento dei processi di salvataggio dati

È indispensabile, a fini della sicurezza dei dati acquisire, un sistema centralizzato hardware/software per eseguire i salvataggi in qualunque istante di tutti i server fisici e virtuali.

Il sistema di backup individuato è composto da diversi moduli:

Modulo 1: Tape Library Autoloader

[Rs23] Specifiche tecniche tape library

▪ Tape Library LTO-4 Ultrium;

▪ N°1 drive;

▪ Data Cartridge da 1,6 TB ciascuno;

▪ capacità totale di archiviazione di 12.8 TB con compressione 2:1 oppure 6,4 TB in modalità nativa;

▪ velocità di archiviazione è di 576 GB/ora;

▪ sistema di management web-based;

▪ lettore di barcode integrato;

▪ HBA SAS (per slot PCIe) da installare su un qualunque server tra quelli a disposizione.

Modulo 2: Software backup server Fisici

Software di backup per la protezione dei dati presenti nei sistemi fisici, con supporto completo delle operazioni di backup e recupero su disco e su nastro per ambienti basati su Windows/Linux

▪ Modulo server: è il modulo centrale che governa il funzionamento dell’intera piattaforma e va installato sul server, dotato di sistema operativo Windows, che governa la Tape Library. È sufficiente una sola licenza.

▪ Macchine fisiche: si utilizzano gli agenti specifici per il sistema operativo e per le diverse funzionalità, pertanto si avranno gli agenti per Windows, per Linux, per Active Directory etc. Si acquista una licenza per ciascuna macchina fisica. In particolare, l’agente per il mondo Linux /Unix è in grado di supportare anche il sistema operativo SUN Solaris.

Modulo 3: Software backup server Virtuali

Software backup per la protezione dei dati presenti nei sistemi virtuali in ambinte VmWare VSphere ESXi 4.x e 5.x.

Tale software deve avere le seguenti caratteristiche:

▪ backup di ogni singola macchina virtuale;

▪ replica: comprende il rollback della replica e la replica da e verso VmWare ESXi 5.0;

▪ Hot VM copy;

▪ vStorage API;

▪ Changed Block Tracking: backup incrementali che riducono le tempistiche di backup e consentono di aumentare la frequenza dei backup e delle repliche;

▪ backup direttamente da SAN, su LAN, mediante virtual appliance, o direttamente dal target;

▪ controllo centralizzato dell'implementazione distribuita: comprende Enterprise Manager, una web console che offre una visione consolidata dell'implementazione distribuita; include la federazione di più database di backup, il reporting centralizzato e le notifiche consolidate;

▪ backup completo sintetico: elimina la necessità di effettuare backup periodici completi consentendo così di risparmiare tempo e spazio;

▪ riserva temporanea: ripristina rapidamente il servizio per gli utenti riavviando le VM che hanno avuto dei problemi dal file di backup sul normale storage di backup;

▪ ripristino completo senza alcun momento di disservizio: completa il ripristino senza disservizi per gli utenti migrando la VM dallo storage di backup a quello di produzione grazie a Storage vMotion;

▪ ripristino completo durante la finestra di manutenzione: completa il ripristino e riduce al minimo il periodo di inattività replicando o copiando nella VM dallo storage di backup a quello di produzione;

▪ ripristino a livello degli oggetti per qualsiasi applicazione virtualizzata, su qualsiasi SO, utilizzando gli strumenti di gestione delle applicazioni esistenti;

▪ ripristino diretto dall'utente: disponibile per qualsiasi applicazione con front-end web, come SharePoint e Salesforce;

▪ supporto Microsoft Exchange: comprende una procedura guidata che può essere utilizzata dagli amministratori di Exchange per ripristinare i singoli oggetti (quali email e contatti);

▪ supporto Microsoft Active Directory: comprende una procedura guidata che può essere utilizzata dagli amministratori di Active Directory per ripristinare i singoli oggetti (quali utenti e gruppi) e i loro attributi;

▪ supporto Microsoft SQL Server: comprende una procedura guidata che può essere utilizzata dagli amministratori di SQL Server per ripristinare i singoli oggetti (quali tabelle e record);

▪ supporto di ogni tipo di file system: offre un ripristino immediato a livello di file per qualsiasi file system utilizzando gli strumenti esistenti di gestione dei file

▪ ripristino gestito dalla procedura guidata: comprende una procedura guidata ripristino immediato a livello di file dai 15 file system piu’ comunemente utilizzati di Windows, Linux, Solaris e BSD;

▪ indicizzazione del file system guest di Windows: crea un indice (catalogo) di tutti i file guest di Windows di cui è stato effettuato il backup;

▪ ricerca tra tutti i backup: Ricerca veloce dei file guest di Windows tra i backup;

▪ verifica automatica del ripristino;

▪ copia funzionante dell'ambiente di produzione: crea una copia funzionante dell'ambiente di produzione da qualsiasi momento temporale per la risoluzione dei problemi, test, training, etc., mediante l'esecuzione di una o più VM dai backup in un ambiente isolato, senza ulteriore storage e senza modificare il backup.

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n.	Descrizione sistema backup e recovery	Q.ta’
[Rs23]	Tape library autoloader hp 1760 completa di hba sas, 7 data tape, 1 cleaning cartridge, kit da rack	1
	Software backup server fisici; modulo server	1
[Rs24]	Agente per sistema windows	5
[Rs25]	Agente per sistema linux / unix /solaris	5
	Windows server standard 2008 r2 olp gov per server di gestione tape library	1
	Software backup server virtuali; modulo server	1

Tabella 24 Dettaglio sistema di backup AOB

8.3.2 Sistema centralizzato di gestione dei Log

L'enorme volume di eventi di sistema generato quotidianamente acquisisce un'importanza sempre maggiore per le organizzazioni la cui attività richiede di registrare informazioni a fini legali e ottemperare

al numero sempre crescente di conformità normative ed in particolare al D.P.R. 513/1997 e le leggi SOX, PCI DSS e HIPPA..

L'aumento delle minacce alla continuità operativa delle aziende richiede un approccio che permetta un monitoraggio in tempo reale della rete, nonché la facoltà di analizzare e produrre report sui dati degli eventi per poter far fronte a eventuali incidenti o rischi relativi alla sicurezza.

Il software dovrà:

▪ proteggere il sistema informatico e la rete, grazie al rilevamento di intrusi e di violazioni della sicurezza

▪ ottemperare a leggi e normative, fornendo un ausilio per rispettare le conformità;

▪ contribuire alla centralizzazione degli eventi Syslog, W3C, Windows e SNMP trap generati da firewall, server, router, commutatori, centralini telefonici, PC e altro

▪ contribuire al miglioramento del tempo di operatività (uptime) della rete e analisi di problemi attraverso gli avvisi in tempo reale;

▪ avere prestazioni di scansione degli eventi scalabili fino a oltre 6 milioni di eventi all'ora.

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n.	Descrizione sistema gestione log	Quantita’
Modulo server		50
Licenze client		800
	Tabella 25 Dettaglio sistema gestione log

9 Progetto adeguamento AOU di Cagliari

In questo capitolo sono riportate le soluzioni tecnologiche e le specifiche tecniche e funzionali relative alla proposta progettuale di adeguamento delle infrastrutture hardware/software presentata dall’Azienda Ospedaliero-Universitaria di Cagliari nell’ambito del Progetto INFRAS ICT.

Interventi INFRAS ICT AOU CA priorità

Potenziamento infrastruttura di rete O

Attivazione servizi di desktop management IP8

Tabella 26 Riepilogo interventi e priorità AOU CA

9.1 Contesto di riferimento

L’obiettivo principale del progetto INFRAS ICT relativamente all’Azienda Ospedaliero-Universitaria di Cagliari consiste nel rinnovare e consolidare l’infrastruttura di rete in modo da rendere sicura ed efficiente la gestione e la trasmissione dei dati all’interno del complesso ospedaliero di Monserrato.

Occorre precisare che la Server Room presenta delle criticità legate ai locali, ai sistemi di condizionamento e di controllo degli accessi, cui si aggiunge un necessario adeguamento di quanto esistente per quanto attiene il sistema UPS, da tempo non più idoneo in termini di potenza di carico supportato in seguito all’adeguamento dei sistemi ospitati presso il CED.

Attualmente l’azienda conta circa 500 pdl (postazioni di lavoro) connesse in rete e ulteriori 100 stand- alone. Le pdl sono dislocate presso le diverse sedi (P.O Monserrato; P.O. San Xxxxxxxx xx Xxx; Clinica Pediatrica Macciotta). Nel 2012 è inoltre prevista l’apertura del nuovo Blocco Q sempre a Monserrato, dove sono previste circa 400 nuove pdl.

In previsione del potenziamento e l’ampliamento della sede di Monserrato, la sostituzione e l'uniformazione degli apparati di networking permetterebbe di avere una infrastruttura di trasmissione dati solida e di facile gestione.

A breve si vorrebbe attivare un Dominio Microsoft Server (Active Directory) per 600 utenti.

9.2 Obiettivi

Gli obiettivi relativi agli interventi ICT del progetto INFRAS sono i seguenti:

▪ potenziamento infrastruttura di rete di capmpus e centro stella;

▪ realizzazione del Dominio di Active Directory.

9.3 Interventi

9.3.1 Potenziamento infrastruttura di rete

La soluzione di apparati switch attivi proposti garantisce la possibile implementazione in architetture di vario genere, dalle più semplici, a bassa ingegnerizzazione, alle più complesse, costituite da differenti livelli gerarchici, con funzioni di Fault Tollerance e prive di Single Point of Failure.

Il sistema di cablaggio strutturato esistente e lo sviluppo planimetrico del Campus dell’Azienda Ospedaliero-Universitaria presso il P.O. di Monserrato suggerisce un’architettura di tipo gerarchico a due livelli, con un nodo di centro stella (Core Distribution) con configurazione ad alta affidabilità e 20 nodi di accesso (Floor Distribution).

Figura 8 Layout di rete aziendale

Figura 9 Dettaglio collegamento corpo/centro stella

Per la realizzazione della nuova architettura di rete si propone una soluzione basata su prodotti di fascia ENTERPRISE.

Si ipotizza l'acquisizione di 2 apparati switch di categoria enterprise (famiglia modulare di fascia alta “ENTERPRISE di core”) per la Server Farm interconnessi a 4 nuovi apparati switch di pari categoria del Centro Stella di palazzo in aggregazione di canali (Port-Channel) per la massima affidabilità del sistema. Eventuali espansioni potranno essere implementate successivamente aggiungendo apparati alla matrice.

Per gli apparati switch di accesso si ipotizza l'acquisizione di una coppia di apparati di distribuzione in ogni armadio di rete.

Per il Centro Stella e la Server Farm potranno essere installati apparati switch di ultima generazione di classe enterprise, collegabili in stack fino a 9 unità, in modo tale da fornire all'utilizzatore una macchina unica e flessibile che fornisce espandibilità di interfacce per connettività in FC fino a 4 interfacce SFP o 2 interfacce 10GbE per apparato.

Le matrici risultanti potranno essere interamente ridondate ed eventuali servizi di routing/QoS saranno garantiti con continuità anche in caso di guasto di uno switch, e supporteranno servizi di connettività in alta affidabilità consentendo canali aggregati (Port channel / teaming) su switch differenti.

La struttura del cablaggio di accesso (cat 5E) sarà connessa ai nuovi apparati di distribuzione pari alle esigenze di reparto con una scorta minima del 30% per l'accesso degli utenti. Questi saranno collegati in FO (GbE) verso gli apparati di aggregazione ubicati presso il Centro Stella utilizzando due link per armadio. La soluzione garantirà la connettività degli armadi periferici in Gigabit Ethernet anche in caso di caduta di uno degli apparati di Centro Stella.

I due cavi provenienti da ciascun armadio periferico verranno attestati su due apparati distinti con collegamento a matrice. La funzionalità di stack può essere fornita tramite n° 4 apparati modulari di fascia alta.

[Rs26] Gli apparati dovranno essere equipaggiati con:

▪ porte SFP in FO shortwave per il collegamento delle dorsali, sufficienti alle connessioni in progetto;

▪ 2 porte SFP 1000BT per interconnettere la matrice switch dei server, in portchannel con aggregazione di canale, e i firewall di frontiera esistenti;

▪ bus di stacking ad alta velocità;

▪ ridondanza di alimentazioni e ventole;

▪ funzionalità base di livello 2 e 3 upgradabili via software ove fosse necessaria la gestione di protocolli di routing dinamici.

Piattaforma apparati di core

[Rs27] La piattaforma degli apparati di core dovrà prevedere:

▪ n. 4 apparati di fascia ENTERPRISE, equivalenti o superiori, 12 SFP STANDARD MULTILAYER IMAGE, equipaggiati con 40 GE SFP LC CONNECTOR SX TRANSCEIVER e 8 1000BASE-T SFP - bus di ridondanza di alimentazioni e ventole;

▪ funzionalità base di livello 3 upgradabile via software alla versione Enhanced per la gestione del routing dinamico;

▪ 12 alloggiamenti SFP per apparato;

▪ espandibilità ottenibile aggiungendo apparati omologhi alla matrice.

Server Farm

[Rs28] La stessa tecnologia utilizzata per gli apparati di CS verrà impiegata nella server farm. Si prevede una matrice di n 2 apparati interconnessi tra loro in tecnologia stack a costituire un unico switch L3 equivalenti o superiori. La matrice è caratterizzata da:

▪ bus di stacking ad alta velocità a 64 Gbps di throughtput;

▪ 24 porte 10/100/1000 per apparato;

▪ uno slot di espansione popolabile con n 2 interfacce 10GBE o 4 SFP di varia tipologia- espandibilità dello stack con l'aggiunta di nuove macchine.

Armadi di piano

Gli switch di accesso potranno essere sostituiti con apparati di fascia Distribution (equivalenti o superiori):

[Rs29] Caratteristiche apparati di raccolta:

▪ 48 porte GbE;

▪ 4 X SFP x lan BASE;

▪ N. 2 porte SFP nX per fibra multimodale per il collegamento al centro stella (come da progetto).

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n.	Descrizione forniture infrastruttura di rete	Q.ta'
	Switch fascia Entreprise x 24 porte 10/100/1000 mbs	2
	Switch fascia Entreprise 12 sfp standard multilayer image	4
	Ge sfp lc connector sx transceiver	40
	1000base-t sfp	8
	Switch fascia Distribution stack 48 GbE 4 x sfp lan base	42
	Ge sfp lc connector sx transceiver	40

Tabella 27 Dettaglio fornitura infrastruttura di rete AOU Cagliari

9.3.2 Attivazione servizi di desktop management

La gestione e la manutenzione delle postazioni di lavoro aziendali rappresentano una problematica importante. La gestione del parco macchine esistente, che conta circa 600 stazioni di lavoro distribuite nei Servizi aziendali e con la prospettiva di un notevole incremento durante l'anno in corso, richiedono un governo centralizzato e sistematico.

Ciò determina la contemporanea crescita di esigenze di Desktop Management, di gestione di configurazioni hardware e software delle postazioni di lavoro, di erogazione di servizi di Help-Desk agli utenti, nonché di gestione e controllo della sicurezza logica e fisica delle diverse configurazioni presenti. In quest’ottica, anche il progetto approntato ha subito delle evoluzioni per adattarlo ed ottimizzarlo alle esigenze aziendali in funzione soprattutto delle implementazioni tecnologiche e applicative.

Il progetto prevede una mappatura completa del parco installato attraverso il censimento iniziale di tutte le apparecchiature, l’accessibilità al parco macchine attraverso l’infrastruttura di rete, una precisa gestione della sicurezza in termini di permessi e accessi.

Gli obiettivi che dovranno essere soddisfatti sono principalmente:

▪ la gestione centralizzata della protezione;

▪ l'operatività dell’utente nell’ambito dei criteri di protezione definiti;

▪ la riduzione del numero di amministratori di sistema;

▪ la massima protezione e controllo delle postazioni di lavoro mediante installazione centralizzata del software di utilità aziendale;

▪ la riduzione del TCO (Total Cost Ownership) dell’infrastruttura ICT.

Nella tabella seguente sono riepilogate le forniture di componenti hardware e licenze software come espresso dalla azienda sanitaria che ha presentato la propria proposta progettuale.

Rs.n.	Descrizione dominio aziendale	u.m.
[Rs30]	Implementazione Dominio di Windows per 600 pdl	a corpo
[Rs31]	Licenze software per n.2 SO Windows 2008 Server + 600 Client	a corpo
	Censimento iniziale	a corpo
	Asset management (mantenimento inventario)	a corpo

Tabella 28 Dettaglio dominio aziendale AOU Cagliari

10 Progetto adeguamento AOU di Sassari

In questo capitolo sono riportate le soluzioni tecnologiche e le specifiche tecniche e funzionali realtive alla proposta progettuale di adeguamento delle infrastrutture hardware/software presentata dall’Azienda Ospedaliero-Universitaria di Sassari nell’ambito del Progetto INFRAS ICT.

Interventi INFRAS ICT AOU SS priorità

Sistema di monitoraggio di rete IP9

Sistema di intrusion detection IP12

Tabella 29 Riepilogo interventi e priorità AOU SS

10.1 Contesto di riferimento

Il Sistema Informativo dell’Azienda Ospedaliero-Universitaria di Sassari, oggi piuttosto carente, mostra i segni evidenti di una eccessiva frammentazione degli interventi che si sono succeduti negli ultimi anni, in totale assenza di una precisa strategia di sviluppo.

Come già evidenziato nel questionario di autovalutazione del progetto INFRAS, e in estrema sintesi, il

S.I. presenta le seguenti principali problematiche:

a) inadeguatezza strutturale: non si dispone di idonei locali per ospitare apparati server e di rete e questo causa, oltre a problematiche relative alla sicurezza, una forte dispersione dei sistemi aziendali dove sistemi critici sono spesso “sparsi” nel modo più disparato presso strutture e reparti;

b) scarsa sicurezza: la situazione sopra richiamata determina un basso livello di sicurezza – sia fisica che logica – del patrimonio informativo dell’Azienda, esponendo a seri rischi di violazione delle normative di legge (D. Lgs. 196/03), soprattutto a causa dell’assenza di una gestione centralizzata delle risorse di sistema, conforme allo stato dell’arte delle tecnologie ICT ed opportunamente ridondata.

Tenuto conto di quanto sopra delineato e delle risultanze dell’analisi della situazione attuale dei sistemi aziendali, occorre programmare ed imprimere una svolta significativa costruendo per la prima volta una strategia per lo sviluppo coerente e progressivo del Sistema Informativo dell’Azienda Ospedaliero- Universitaria di Sassari, che possa rapidamente raggiungere i principali obiettivi.

Come evidenziato nel questionario di autovalutazione, i locali destinati ai sistemi ICT presso l’Azienda Ospedaliero-Universitaria di Sassari sono:

1. locale ‘CED’: l’attuale locale destinato ad ospitare la maggioranza dei server aziendali, ubicato presso il palazzo denominato Corte Santa Xxxxx, è un locale ad uso ufficio convertito a tale funzione, che risulta inadeguato sia per dimensioni fisiche sia per l’assenza delle soluzioni impiantistiche necessarie per la realizzazione di una server farm a regola d’arte (assenza di meccanismi di controllo accessi, assenza di sistemi antincendio a norma, assenza di quadro elettrico dedicato e di sistemi ups adeguatamente dimensionati, …). Pertanto, non è possibile investire in opere di adeguamento ma è necessario allestire ex novo una nuova sala Server;

2. locale “Network”: si è proceduto in tempi recenti all’individuazione e all’avvio del trasferimento del Centro Stella Aziendale in un nuovo locale, di dimensioni adeguate e su cui si sta allestendo idonea pavimentazione flottante. Pertanto, risultano necessari investimenti per portare a termine l’adeguamento del suddetto e dei sistemi di controllo (controllo accessi, monitoraggio ambientale, antincendio, controllo continuità elettrica, ecc.), nonché l’esecuzione di opere edili ed impiantistiche accessorie a tali forniture e/o necessarie per l’adeguamento del locale.

Pertanto, per ovviare alle sostanziali carenze, è necessario operare un adeguamento dei locali attualmente adibiti a Sala Network ed allestire ex-novo i nuovi locali per la Sala CED.

La realizzazione di tali strutture, oggetto di un’altra gara, prevede la fornitura di tutte le opere edili e dei sistemi tecnologici necessari alla messa a norma degli ambienti prescelti.

L’infrastruttura tecnologica aziendale è costituita da 2 armadi – Armadio 12 U:

▪ 5 Server Fujitsu PRiMERGY tX300 s4;

▪ 2 Server HP ProLiant DL 360 G5. Server towers:

▪ 1 Fujitsu PRiMERGY tX150 s2;

▪ 1 IBM System x3200 M2;

▪ 1 IBM Xseries 226;

▪ 2 Hp Proliant ML 350.

Tutti questi server vengono utilizzati per applicazioni varie ad uso interno: DNS, intranet, sistemi amministrativi contabili e RIS/PACS.

L’infrastruttura risulta ormai datata, con basse performance e senza contratto di manutenzione hardware. Pertanto, sono opportuni invenstimenti di adeguamento. In funzione di questo, si ritiene necessaria la realizzazione di una nuova infrastruttura tecnologica hardware del sistema centrale per i servizi sopraindicati ma adeguata anche per la virtualizzazione di una buona parte dei desktop periferici.

Il sistema dovrà garantire requisiti di:

▪ scalabilità;

▪ disponibilità;

▪ sicurezza;

▪ gestibilità;

▪ affidabilità;

▪ standardizzazione.

Per soddisfare tali requisiti si dovrebbe attivare un processo di consolidamento e virtualizzazione della Server Farm, concentrata in un unico CED.

L’attuale Data Center è caratterizzato da un elevato numero di macchine, generalmente fornite e gestite da diversi produttori ciascuno dei quali richiede un proprio ambiente dedicato. In virtù di questo, col tempo, è stato generato un proliferare di hardware e sistemi dall’alto costo di possesso a fronte di uno sfruttamento minimo (10%).

A breve, l’azienda disporrà di spazi appositi per poter allestire ex novo la sala Server che consentiranno la realizzazione di soluzioni più performanti e scalabili nel tempo relativamente allì’architettura hardware.

Intendimento dell’azienda, è quello di realizzare un architettura ad Alta Disponibilità, ossia completamente ridondata, al fine di garantire la Continuità del Servizio necessaria. La soluzione ipotizzata prevede i seguenti moduli:

▪ una Storage Area Network;

▪ sistema virtualizzazione Server;

▪ sistema di virtualizzazione desktop.

Sebbene l’acquisizione della SAN e la virtualizzazione possano essere ritenute delle scelte strategiche, strettamente legate al miglioramento complessivo delle performance, al consolidamento dei server, al risparmio energetico ed all’utilizzo delle risorse IT, per motivi di priorità nel presente progetto non sono previsti interventi al riguardo.

10.2 Obiettivi

Gli obiettivi relativi agli interventi ICT del progetto INFRAS ICT sono i seguenti:

▪ acqusizione di un sistema di monitoraggio e gestione degli apparati e dei sistemi di rete;

▪ acquisizione di un sistema di controllo delle intrusioni informatiche.

10.3 Interventi

Gli interventi previsti nell’ambito del progetto INFRAS ICT saranno meglio dettagliati nei paragrafi successivi. Si tratta di interventi premianti.

10.3.1 Sistema di monitoraggio della rete

La rete deve prevedere un adeguato sistema di gestione, in grado di gestire e configurare in maniera centralizzata ogni singolo nodo della rete. A tale scopo deve essere inclusa una piattaforma hardware e/o software di network management, provvista di:

▪ interfaccia grafica;

▪ capacità di gestione remota e centralizzata via SNMP, compatibile almeno con le versioni 1 e 2 e con l’SNMP MIB II, in grado di estendere le proprie funzionalità anche alle varie tipologie di apparati presenti in azienda;

▪ accesso e gestione http e/o telnet e comunque dotata di interfaccia user frendly;

▪ toolset per l’analisi della rete;

▪ sistema di monitoraggio di traffico.

In dettaglio, il sistema di management delle apparecchiature attive di rete deve essere possibilmente integrato in un'unica interfaccia e soddisfare i seguenti requisiti minimi:

▪ applicazione per la configurazione, amministrazione, monitoraggio ed aggiornamento delle apparecchiature di rete del sistema;

▪ report e rappresentazione delle statistiche collezionate;

▪ gestione degli allarmi e configurazione di escalation;

▪ configurazione degli eventi sulla base dei MIB proprietari integrabili ad hoc nell’applicazione.

10.3.2 Sistema di Intrusion detection di rete

Per la protezione e la sicurezza logica della Server Farm e della rete, l’azienda non dispone attualmente di nessuno strumento.

Pertanto, dovrà essere previsto un sistema di rilevamento delle intrusioni (Network Intrusion Detection System, NIDS) che consenta di individuare tutte le sequenze di eventi, condotti da una o più entità non autorizzate, aventi come obiettivo la compromissione di un sistema, di un apparato o di una rete.

Il sistema NIDS sarà costituito dai seguenti componenti funzionali:

▪ sensore: raccoglie dati dalla rete (pacchetti dati) e li inoltra all’Analyzer. I sensori devono poter monitorare segmenti di rete con prestazioni pari a 10 Mb/s (Ethernet), 100 Mb/s (Fast Ethernet) e 1000 Mb/s (Gigabit Ethernet);

▪ analyzer: riceve input da uno o più sensori o da altri analyzer e determina l’occorrenza di una situazione di attacco. L’output di questo componente rappresenta un’indicazione dell’avvenuta intrusione da cui possono scaturire azioni automatiche configurabili (almeno definizione di policy su firewall, terminazione connessioni TCP, generazione trap SNMP);

▪ user interface (o manager): consente di controllare e monitorare il comportamento del sistema NIDS.

Il sistema NIDS dovrà possedere le seguenti caratteristiche tecniche:

▪ supporto dei protocolli IEEE Ethernet, Fast Ethernet, Gigabit Ethernet e tutti i protocolli specificati nello standard TCP/IP;

▪ analisi passiva di un protocollo tramite l’uso di sniffer;

▪ generazione di una notifica specifica a fronte dell’individuazione di un attacco;

▪ possibilità di definizione di regole personalizzate per:

− tener conto di eventuali vulnerabilità riscontrate in fase vulnerability assessment;

− registrazione delle attività sulla rete che rispondono a determinate condizioni;

− attivare notifiche a fronte di particolari sequenze di eventi sulla rete;

− attivare delle azioni specifiche di contrasto all’intrusione, personalizzabili.

Al fine di consentire non solo il rilevamento di eventuali attacchi o eventi minacciosi per i sistemi, si prevede l’impiego di un sistema con anche funzionalità di prevenzione.

L’IPS (Intrusion Prevention System) rappresenta la nuova frontiera della sicurezza nelle reti, basata sull’approccio proattivo piuttosto che reattivo. I sistemi IPS infatti consentono di proteggere le applicazioni e l’infrastruttura tramite analisi metodologiche complesse, governate da un potente motore di correlazione.

11 Progetto adeguamento Assessorato dell’Igiene e Sanità e dell’Assistenza Sociale

In questo capitolo sono riportate le soluzioni tecnologiche e le specifiche tecniche e funzionali relative alla proposta progettuale di adeguamento delle infrastrutture hardware/software presentata dall’Assessorato dell’Igiene e Sanità e dell’Assistenza Sociale nell’ambito del Progetto INFRAS ICT.

Interventi INFRAS ICT Assessorato priorità

Consolidamento e virtualizzazione O

Estensione dello storage e gestione backup O

Attrezzature informatiche per l’alta mobilità O

Tabella 30 Riepilogo interventi e priorità Assessorato dell’Igiene e Sanità

11.1 Contesto di riferimento

L’infrastruttura tecnologica dell’Assessorato, così come è emerso nella fase di assessment preliminare, è costituita dai seguenti sistemi:

▪ 5 server IBM x345 (rack);

▪ 1 server di storage SAN IBM FastT700 con 3 unità dischi FC IBM X710 (rack);

▪ 1 unità dischi esterna SCSI IBM EXP300 (rack);

▪ 1 libreria automatica IBM Ultrium2 con 2 drive LTO2 FC e 23 slot (rack);

▪ 2 SAN switch FC (rack);

▪ 2 toxxx xxxxxx (XXX x Xujitsu).

Il rack che contiene i server indicati è da 42U incluso di UPS, alcune unità di distribuzione dell'alimentazione (PDU), console KVM e commutatore.

Dei 5 server IBM, due producono i servizi Active Directory, due operano in cluster di alta disponibilità Microsoft e il quinto è dedicato al system management e alla protezione dei dati e dei servizi. I due SAN switch FC connettono, con percorsi ridondati, i server host al server di storage e alla libreria LTO. Il tower server IBM è dedicato ai servizi ISA server e quello Fujitsu all'applicativo Grouper 3M (DRG).

I servizi sono distribuiti agli utenti di circa 200 postazioni client di dominio, di cui circa 150 presso lo stabile dell'Assessorato, 20 presso il palazzo adiacente e 40 nel palazzo ex Pubblica Istruzione.

Il sistema informativo dell’Assessorato gestisce le seguenti applicazioni:

▪ Microsoft SQL Server in cluster di failover;

▪ Lotus Domino in cluster;

▪ Grouper 3M;

▪ CFO (Compendio Farmaceutico Ospedaliero).

Esso eroga inoltre i seguenti servizi:

▪ Active Directory (Windows 2000 nativo);

▪ Symantec Endpoint Protection;

▪ IBM Director.

L’Assessorato rappresenta un punto fondamentale del Sistema Informativo Sanitario, collettore di informazioni relativamente ai flussi sanitari del debito informativo, punto di raccolta delle informazioni e di monitoraggio e governo del sistema informativo sanitario, costituito dalle insieme delle Aziende Sanitarie.

L’infrastruttura esistente risale al 2004, risulta ormai datata, con basse performance e non è coperta da un contratto di manutenzione hardware.

Di seguito sono riportate le principali criticità individuate nel sistema:

▪ mancanza di copertura con contratti di assistenza sull’infrastruttura hw;

▪ obsolescenza dell’infrastruttura hw;

▪ l’obsolescenza della piattaforma win 2000 Server;

▪ mancanza di supporto sistemistico;

▪ carenza di spazio disco.

11.2 Obiettivi

L’Assessorato con questo progetto intende rafforzare e confermare la propria funzione di monitoraggio, governo e controllo del Sistema Informativo della Sanità nei suoi diversi livelli: regionale, delle aziende sanitarie e dei dipartimenti.

Per questo motivo si vuole garantire l’evoluzione, il mantenimento e il consolidamento della struttura logica del sistema informativo,attraverso il consolidamento dell’attuale struttura informatica.

Si ritene opportuno acquisire un sistema Server completamente ridondato e virtualizzato concentrato in un unico CED, con un Sistema Storage in alta affidabilità predisposto per Disaster Recovery (che potrà essere attivato in un secondo momento); tale sistema permetterà di garantire la sicurezza e la velocità di fruizione dei dati per i servizi dell’Assessorato.

Tutto il sistema dovrà essere dotato di una garanzia di 36 mesi on-site.

11.3 Vincoli

Trattandosi di un intervento di evoluzione di un sistema informatico già esistente esistono alcuni vincoli per garantire la naturale migrazione del sistema, la conservazione del know-how acquisito e la conservazione del patrimonio in termini di microcodice esistente in Assessorato.

Per queste ragioni è necessario vincolare i seguenti software lato server:

▪ S.O. Windows Server (con passaggio dalla versione 2000 alla versione 2008);

▪ RDBMS SQLServer;

▪ MS Xxxxxxxxx;

▪ MS Exchange.

Mentre sui portatili è richiesto:

▪ S.O. Windows 7 professional 64 bit;

▪ MS Office 2010 professional;

▪ migrazione da Windows Vista a windows 7 (n°3 licenze).

Quanto sopra è necessario per garantire la compatibilità con gli strumenti di produttività individuale.

Inoltre per la virtualizzazione si è scelto il prodotto VMware, già presente in alcune aziende sanitarie, per ragioni di compatibilità e di conservazione del know-how.

11.4 Interventi

Gli interventi previsti nell’ambito del progetto INFRAS ICT saranno meglio dettagliati nei paragrafi successivi.

11.4.1 Consolidamento e virtualizzazione

SI intende acquisire un sistema Blade, per i vantaggi che tale tecnologia offre in termini di:

▪ risparmio energetico;

▪ riduzione della complessità (cavi e infrastruttura);

▪ riduzione dello spazio occupato;

▪ espandibilità futura.

Il sistema prevede l’inserimento di una infrastruttura Blade server per la virtualizzazione ed il consolidamento delle applicazioni. In base alle analisi di performance dei sistemi in produzione si prevede di consolidare circa 8 servizi per lama.

I servizi da virtualizzare sono i seguenti:

▪ servizi Active Directory (4 server virtuali nel caso di implementazione su due domini);

▪ applicazioni SQL server per elaborazione dati utente (1 server virtuale);

▪ SQL server di back end (produzione circa 250 Gbyte/anno) (1 server virtuale);

▪ Grouper3M (1 server virtuale);

▪ Server Exchange (1 server virtuale);

▪ Lotus Domino (1 server virtuale);

▪ Forefront MS ISA server (1 server virtuale);

▪ servizio file (2 server virtuali);

▪ servizio stampa (2 server virtuali);

▪ IBM Director (1 server virtuale);

▪ server antivirus (1 server virtuale).

Si prevede un totale di 18 server virtuali (previa verifica sulla possibilità, nel rispetto della compatibilità software e di adeguati livelli prestazionali, di accorpare alcuni dei servizi sopra elencati su un’unica istanza di server virtuale), per gestire i quali si prevede l’uso di tre lame, di cui una per hotspare e/o bilanciamento del carico, e una ulteriore lama dedicata alla gestione dei sistemi virtuali e al backup. È richiesta la piattaforma Windows 2008 Server per server virtuali e fisici.

La connettività verso lo storage sarà in FC ridondata mediante due moduli switch FC alloggiati nel blade chassis. Anche le connessioni LAN saranno ridondate con 4 moduli switch GbE alloggiati nel blade

chassis al fine di ottenere un sistema interamente ridondato sia verso i server blade che verso il mondo esterno.

Si richiede inoltre:

▪ VMware Infrastructure per l’ottimizzazione e la gestione degli ambienti IT attraverso l’uso della virtualizzazione, dai desktop all’intero Data Center;

▪ VMware vSphere 5 per virtualizzare e aggregare i server industry standard, le connessioni di rete e lo storage ad essi connessi in un unico insieme di risorse.

Queste sono le caratteristiche che la soluzione dovrà possedere:

▪ gestione centralizzata e monitoraggio automatico delle macchine virtuali, semplicità nell’impiego e nella creazione di nuove;

▪ distribuzione dinamica delle risorse virtuali sulle macchine fisiche per ottimizzare i carichi, utilizzando al meglio le risorse presenti;

▪ elevata affidabilità, semplicità di utilizzo e possibilità di ottenere alti livelli di servizio per le applicazioni;

▪ possibilità di Live Migration, ossia di spostamento di macchine virtuali tra piattaforme fisiche senza interruzione del servizio per le applicazioni in esecuzione;

▪ sistemi di aggiornamento delle patch centralizzato per tutti gli host fisici e virtuali in modo da ottenere sempre le compatibilità aggiornate;

▪ gestione della continuità dei servizi tramite le funzionalità FT e HA.

11.4.2 Estensione dello storage e gestione backup

Le esigenze dell’Assessorato spaziano dalla gestione dello spazio disco in alta affidabilità per gli applicativi installati, alla disponibilità di storage per i dati utente, oltre alla salvaguardia di tali dati da realizzarsi con un sistema di backup efficiente e veloce. Allo storage si deve guardare in prospettiva futura anche per la gestione in alta affidabilità dei servizi per soluzioni di Disaster Recovery. Si propende quindi verso una soluzione integrata di storage multiservizio che nativamente consenta l’eliminazione dei file server (servizi nas nativi con gestione delle acl) e supporti l’accesso ai server in modalità FCP o ISCSI.

Il sistema di Storage richiesto, al fine di ottimizzare la gestione dello spazio disco, dovrà rendere possibile:

▪ la “virtualizzazione dello storage”, che consenta di generare pool di volumi da assegnare e ridimensionare dinamicamente;

▪ la deduplicazione dei dati in modo da ottimizzare l’occupazione degli spazi;

▪ la gestione dinamica delle snapshot finalizzate al backup e al Disaster Recovery.

Per il consolidamento dei server è di cruciale importanza che il sistema di storage garantisca livelli di affidabilità elevatissimi. Pertanto dovranno essere previsti:

▪ controller ridondati;

▪ path ridondati tra server e storage per garantire continuità di servizio trasparente in caso di rottura di adattatori e/o controller;

▪ reti ridondate;

▪ storage adapter ridondati;

▪ alimentazioni ridondate.

Il sistema proposto dovrà garantire tolleranza alla rottura di due dischi per raid group con adeguato numero di hot spare per il ripristino immediato dei volumi. Si prevedono volumi SAS per le applicazioni virtualizzate e SATA per i dati utente.

La soluzione progettuale dovrà prevedere l’implementazione di un sistema storage con lo scopo di fornire spazio disco in alta affidabilità ai sistemi server virtualizzati e non (volumi via FCP/iSCSI) e spazio per le cartelle utente (volumi NAS).

11.4.2.1 Backup

Per la soluzione di backup si prevede il salvataggio diretto su disco che risulta più economico, di minore impatto per la gestione e, soprattutto, garantisce ripristini immediati. Si prevede in questa fase il reimpiego dello storage esistente per il salvataggio dati.

Prevediamo comunque la possibilità di esportare su nastro sia le VM (Virtual Machine) che i dati di backup applicativi con le funzionalità di VCB VMware. Il server dedicato avrà collegata la tape library esistente in dotazione all’Assessorato, per la quale dovrà essere garantita la copertura manutentiva per almeno tre anni dal collaudo della fornitura (Libreria automatica IBM dotata di 2 drive Ultrium2 FC), e potrà gestire, ove necessario, una esportazione del dato su cassetta per il salvataggio legale.

In prospettiva futura si potrebbe utilizzare un sistema secondario di storage come destinatario del salvataggio dati. La soluzione dovrà essere interamente gestita dalle feature software prescelte.

11.4.3 Attrezzature informatiche per la mobilità

Per le esigenze dell’Assessorato di coordinamento dei progetti di sanità elettronica gestiti a livello regionale si richiede la fornitura di computer e periferiche portatili; a tale scopo si prevede l’acquisto di diverse tipologie (high end, mainstream e high mobility) e dei relativi accessori, stampanti e scanner portatili, access points Wi-Fi, hard disk portatili e videoproiettore.

11.5 Specifiche tecniche di riferimento

11.5.1 Moduli switch

11.5.1.1 Storage fabric

Per connettere il sistema blade allo storage si dovranno fornire degli switch FC (interni o esterni al Blade Chassis) in configurazione HA. L’architettura deve consentire l’inteconnessione di tutte le lame fornite con entrambi i controller dello storage.8 Gbps ridondati. Le caratteristiche degli switch saranno le seguenti:

▪ inserimento/disinserimento a caldo (hot-swap);

▪ 20 porte FC 2/4/8 Gbps di cui 6 esterne;

▪ 10 porte attive; le restanti 10 attivabili on-demand.

11.5.1.2 Ethernet fabric

Per le connessioni di rete sono previsti quattro moduli switch GbE livello 2 con le seguenti caratteristiche:

▪ inserimento/disinserimento a caldo (hot-swap);

▪ 14 porte interne full-duplex GbE;

▪ 2 porte interne full-duplex FastEthernet per i moduli di gestione;

▪ 6 porte esterne 10/100/1000 Mbps full-duplex con possibilità di aggregazione.

L’inserimento di 4 moduli switch consente la mappatura in HA di 4 schede GEthernet per LAMA per soluzioni di alto consolidamento applicativo o richieste di performances di I/O elevate.

11.5.2 Server blade per la virtualizzazione

Sono previste 3 unità così caratterizzate:

▪ N. 2 processori con le seguenti caratteristiche o superiori: quad core/otto thread, frequenza di clock 2.53GHz, cache 8MB, supporto alle istruzioni a 64bit, supporto alle memorie DDR3 1066MHz con tecnologia ECC, supporto alla Vitrualization Technology, consumo massimo 80W;

▪ 28 Gbyte RAM Dual Rank PC3-10600 CL9 ECC DDR3-1333 VLP RDIMM;

▪ almeno 4 porte Ethernet Gb;

▪ 2 porte FC 8Gbps con gestione dual path verso lo storage;

▪ 2 unità dischi SAS hot-swap da 146GB 6KBps in RAID 1.

11.5.3 Server blade per l’installazione del Virtual Center e del VCB

È prevista 1 unità con le seguenti caratteristiche:

▪ processore con le seguenti caratteristiche o superiori: quad core/quattro thread, frequenza di clock 2.13GHz, cache 4MB, supporto alle istruzioni a 64bit, supporto alle memorie DDR3 800MHz con tecnologia ECC, supporto alla Vitrualization Technology, consumo massimo 80W;

▪ 12 Gbyte PC3-10600 1333 MHz VLP ECC DDR3 SDRAM DIMM;

▪ 2 unità dischi 146 GB 2.5in SFF Slim-HS 10K 6Gbps SAS HDD in raid 1;

▪ 2 porte FC 8Gbps con gestione dual path;

▪ almeno 4 porte Ethernet Gb.

11.5.4 Sistema di storage

Lo storage dovrà avere funzioni di SAN Storage server per i server applicativi (Vmware e eventuali cluster applicativi) e funzionalità di NAS server per i dati utente. I dischi SAS dovranno essere destinati al sistema virtualizzato (boot da SAN delle macchine virtuali), mentre i dischi SATA verranno destinati alle funzionalità di NAS/storage per grossi volumi di dati (per esempio storage di immagini/file utente).

Il progetto prevede l’inserimento di un sistema di Storage equipaggiato con:

▪ 2 controller RAID sostituibile a caldo;

▪ 2 moduli di alimentazione sostituibili a caldo;

▪ 2 porte FC per controller per il collegamento ridondato dalla SAN;

▪ protocolli di SAN supportati: iSCSI, FCP;

▪ protocolli di rete supportati: NFS, CIFS, http;

▪ almeno 7,2 TB di spazio lordo su dischi SAS;

▪ almeno 7 TB di spazio lordo dati e snapshot su dischi.

Il sistema dovrà consentire salvataggi a caldo e consistenti delle macchi virtuali o dei sistemi attivi nello storage server, finalizzati al backup e il restore per gli ambienti applicativi sopra elencati. Si richiede inoltre che siano attivi perlomeno i protocolli FC e CIFS.

11.5.5 Attrezzature informatiche per il lavoro in mobilità

Portatile high end:

▪ processore con le seguenti caratteristiche o superiori: dual core/quattro thread, frequenza di clock 2.70GHz con possibilità di incrementare automaticamente la frequenza di clock fino a 3.40GHz, cache 4MB, supporto alle istruzioni a 64 bit, memoria supportata DDR3 a 1066/1333MHz, supporto alla virtualizzazione di più sistemi operativi tramite partizioni indipendenti, processore grafico integrato;

▪ scheda video: scheda video dedicata (non integrata nel chipset/processore) con tecnologia in grado di commutare tra scheda grafica discreta e scheda grafica integrata nella CPU in base alle esigenze computazionali/risparmio energetico, memoria video non condivisa da 1GB o superiore;

▪ memoria: 4GB RAM DDR3 a 1333MHz (singolo banco di memoria);

▪ monitor: pannello TFT 14’’ (pollici) HD (tecnologia IPS o equivalente), risoluzione 1600x900 pixels o superiore;

▪ unità di archiviazione: hard disk allo stato solido (SSD) da 128GB o superiore;

▪ batteria: 6 celle;

▪ peso: inferiore ai 2,4 kg.

Portatile mainstream:

▪ processore con le seguenti caratteristiche o superiori: dual core/quattro thread, frequenza di clock 2.60GHz con possibilità di incrementare automaticamente la frequenza di clock fino a 3.30GHz, cache 3MB, supporto alle istruzioni a 64 bit, memoria supportata DDR3 a 1066/1333MHz, supporto alla virtualizzazione di più sistemi operativi tramite partizioni indipendenti, processore grafico integrato;

▪ scheda video: Scheda video integrata o superiore;

▪ memoria: 4GB RAM DDR3 a 1333MHz (singolo banco di memoria);

▪ monitor: pannello TFT di dimensioni comprese tra i 14’’ e i 13’’ (pollici), risoluzione 1366x768 pixel o superiore;

▪ unità di archiviazione: hard disk 320GB 7200rpm o superiore;

▪ batteria: 6 celle;

▪ peso: inferiore ai 2,2 kg.

Portatile high mobility:

▪ processore con le seguenti caratteristiche o superiori: dual core/quattro thread, frequenza di clock 2.50GHz con possibilità di incrementare automaticamente la frequenza di clock fino a 3.20GHz, cache 3MB, supporto alle istruzioni a 64 bit, memoria supportata DDR3 a 1066/1333MHz, supporto alla virtualizzazione di più sistemi operativi tramite partizioni indipendenti, processore grafico integrato

▪ scheda video: scheda video integrata o superiore;

▪ memoria: 2GB RAM 1066MHz o superiore (singolo banco di memoria);

▪ monitor: pannello TFT di dimensioni comprese tra i 12.5’’ e i 12’’ (pollici), risoluzione 1280x800 pixel o superiore;

▪ unità di archiviazione: hard disk allo stato solido (SSD) da 128GB o superiore;

▪ batteria: 4 celle.

▪ peso: inferiore a 1,5kg.

Caratteristiche comuni alle tre tipologie di computer portatili:

▪ unità ottica: masterizzatore DVD DL o superiore;

▪ webcam: integrata;

▪ connettività: Bluetooth, Gigabit Ethernet, Centrino Wi-Fi 801.11n 2x2 AGN o equivalente;

▪ sistema operativo: Microsoft Windows 7 Professional 64bit o superiore;

▪ office automation: Microsoft Office 2010 Professional o superiore;

▪ software antivirus con licenza di durata triennale;

▪ accessori: batteria aggiuntiva 9 celle, borsa con tracolla compatibile con le dimensioni del portatile, docking station comprensiva di alimentazione autonoma (possibilità di collegare il notebook alla docking station e di caricare la batteria senza l’utilizzo dell’alimentatore fornito con il notebook stesso) e port replicator/expander (presenza delle porte più comuni quali VGA/DVI, USB, RJ45, etc.), mouse ottico wireless (no bluetooth), USB pen drive 16GB o superiore, garanzia notebook 3 (tre) anni o superiore la quale garanzia includa anche le batterie del relativo notebook.

Stampante:

Stampante portatile a getto di inchiostro a colori, formato A4 completa di cavi di connessione, batteria e cartucce (interfaccia di collegamento USB 2.0 o superiore), cartucce di ricambio (5 per il nero e 3 per i colori).

Scanner:

Scanner A4 portatile con profondità di colore 48bit, interfaccia USB 2.0 o superiore, completo di cavi di connessione e batteria.

Access Point:

Access point Wi-Fi 801.11n 300Mbps con switch quattro porte 100Mb o superiore integrato.

Hard disk portatile:

Hard disk da 2,5”, 1 TB di capacità o superiore, interfaccia di collegamento USB 3.0 o superiore.

Videoproiettore:

Videoproiettore risoluzione 1280X800 o superiore, 2700 lumen o superiore, ingressi VGA, HDMI, DVI e relativi cavi di connessione e/o adattatori, peso max 3,5 kg, uso scrivania.

11.5.6 Licenze software

Per i server e i servizi dettagliati in precedenza sono necessarie le seguenti licenze:

▪ sistemi operativi, n. 18 Microsoft Windows Server Standard 2008R2 OLP NL Gov;

▪ licenze CAL, n. 200 Microsoft WINDOWS SERVER CAL 2008 OLP NL GOVT DEVICE CAL;

▪ licenze ISA server, n. 1 FOXXXXXXX XXX 0000 XXX XX XXX 1PROC;

▪ licenze SQL, n. 1 SQL Svr Standard Edtn 2008 OLP NL GOVT 1 Proc;

▪ VMware vSphere 5 enterprise edition for 6 processors, Gold Support/Subscription 1 year;

▪ VMWARE VMware vCenter Server Standard for vSphere 5, Gold Support/Subscription 1 year;

▪ sistema di System Management Web-Based, comprensivo di: controllo completo dell'hardware e delle parti dei componenti; gestione degli oggetti di rete, sia fisici che virtuali; predizione guasti; gestione inventario hardware e software;

▪ licenza Microsoft Exchange Server 2010 e relative licenze per 200 utenti;

▪ N° 3 Upgrade da Windows Vista a Windows 7 Professional per computer portatili già in dotazione all’Assessorato.

11.6 Riepilogo della fornitura

Nella tabella seguente sono riepilogate le previste forniture di componenti hardware e licenze software come espresso dall’Assessorato.

Rs. n° Descrizione sintetica forniture di componenti hardware e licenze software Assessorato

N. 1 blade chassis completo di moduli switch LAN e FC in HA con licenze attive e porte per gestire i collegamenti dei server/Tape previsti in fornitura con lo storage FC a doppia controller (4 collegamenti)

N 3 blade server (virtualizzazione)

N 1 blade server (Virtual Center + VCB)

N.1 sistema di storage primario

[Rs32] N. 18 Microsoft Windows Server Standard 2008X0 XXX XX Xxx

[Rs33] N. 200 Microsoft Windows Servers CAL 2008 OLP NL GOVT DEVICE CAL [Rs34] N.1 Xxxxxxxxx XXX 0000 XXX XX XXX 1PROC

[Rs35] N.1 SQL Xxx Xxxxxxxx Xxxx 0000 XXX XX XXXT 1 Proc

N. 1 VMware vSphere MIDSIZE ACCELERATION KIT FOR 6 PROCESSORS

N. 1 Gold Support/Subscription VMware vSphere 5 Enterprise for 6 processors + vCenter Std

N.1 Sistema di System Management Web-Based

[Rs36] N. 1 Microsoft Exchange Server 2010 e relative 200 licenze utente [Rs37] N. 3 upgrade da Windows Vista a Windows 7 Professional

N. 3 Portatile high end completo di accessori

N.1 Portatile mainstream completo di accessori

N.1 Portatile high mobility completo di accessori

N.1 Stampante portatile con cartucce di ricambio

N.1 Scanner portatile

N. 2 Access point Wi-Fi

N. 5 Hard disk portatili

N. 1 Videoproiettore

Document Metadata

Table of Contents

ASSESSORATO DELL’IGIENE E SANITÀ E DELL’ASSISTENZA SOCIALE DIREZIONE GENERALE DELLA SANITÀ

Document Metadata