Skip to main content
INFN: il data center è distribuito
INFN: il data center è distribuitoa rete d'eccellenzati pazzi per le VPN

INFN: il data center è distribuito

| Federica Tanlongo | Osservatorio della rete

Articolo letto 7028 volte

Ecco come "azzerare" virtualmente lo spazio e far interagire risorse di calcolo su scala geografica come se fossero su una LAN, grazie alle tecnologie ottiche di ultima generazione

In questo numero ci allontaniamo dalle “solite” reti metropolitane e regionali per parlare di un tipo piuttosto nuovo di rete geografica, verso la quale sta crescendo un forte interesse: la rete per il data center distribuito.

Le tecnologie disponibili sulla rete GARR-X, insieme alla banda ultralarga, a Gigabit al secondo, permettono ormai di interconnettere risorse su sedi geograficamente distinte come se fossero su una rete locale: una possibilità molto interessante per gli enti della comunità GARR, che possono così mettere a fattor comune risorse localizzate in sedi diverse per rispondere alle esigenze di calcolo sempre più elevate di tanti esperimenti. É quello che è successo con i siti Tier 2 dell’esperimento LHC situati presso le sezioni INFN di Roma 1 e Napoli, integrati in un “super-Tier2” attraverso l’infrastruttura di GARR-X per rispondere a esigenze di calcolo sempre più elevate.

La tecnologia

Con GARR-X, la comunità dell’Università e delle Ricerca italiana dispone di una rete ottica ad alta capacità diffusa a livello nazionale, il cui livello trasmissivo, permette la multiplazione di 80 canali a capacità di 10 o 40 Gbps su 32 nodi dislocati sul territorio nazionale sfruttando la tecnologia DWDM (Dense Wavelength Division Multiplexing). Su questa infrastruttura sono realizzati i collegamenti di dorsale geografica e possono essere configurati servizi end-to-end dedicati. È così possibile disegnare interconnessioni geografiche a banda garantita e ritardo minimo, abilitando il trasporto trasparente di traffico Ethernet, particolarmente adatto alla realizzazione di collegamenti LAN to LAN tra data center.

La sperimentazione ha cercato di rispondere all'esigenza di alta affidabilità utilizzando tecniche di cloud computing su una connessione dedicata a livello geografico

In questo modo, la banda è completamente dedicata all’interconnessione, poiché la tecnologia utilizzata elimina a priori elementi di congestione o contesa all’interno della banda allocata. La rete trasmissiva è basata su tre elementi tecnologici: Apparati DWDM in grado di multiplare fino a 80 canali; una rete di trasporto OTN ITU-T G.709 che consente di erogare una molteplicità di servizi, oltre a fornire meccanismi di protezione, monitoraggio e allarmistica, e infine apparati ROADM (Reconfigurable Optical Add/Drop Multiplexer) grazie ai quali è possibile sfruttare dinamicamente la magliatura dei nodi della rete implementata per l’instradamento delle lambda. In particolare, grazie alla gerarchia numerica OTN è possibile veicolare servizi a diversi Bit rate, rendendo possibile l’allocazione di slot dedicati all’interno delle lambda a 10Gbps e 40Gbps in modo flessibile ed efficiente e quindi anche l’erogazione di servizi trasmissivi direttamente agli utenti. Il disegno di GARR-X prevede la presenza di canali ottici dedicati al trasporto di servizi a 1Gbps tra tutti i nodi ROADM immediatamente adiacenti, quindi è possibile interconnettere qualsiasi coppia di PoP trasmissivi della rete GARR-X con servizi utente su interfacce Gigabit Ethernet Standard: una soluzione particolarmente adatta alle esigenze di interconnessione tra data center, perché non richiede apparati di routing e offre banda completamente dedicata e latenze contenute (nel nostro caso, la latenza misurata in fase di attivazione per il circuito è 5 ms Round Trip Time). Abbiamo parlato del progetto di un Tier2 distribuito con Alessandro De Salvo, coordinatore nazionale del calcolo per l'esperimento ATLAS a LHC e del progetto per il Tier2 distribuito.

Alessandro De SalvoAlessandro De Salvo
INFN
Coordinatore nazionale del calcolo per l'esperimento ATLAS a LHC
Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.

Già allora convenivano sulla necessità di condividere gli investimenti tecnici e professionali necessari a implementare e gestire infrastrutture tecnologiche avanzate che rispondessero alle crescenti esigenze di comunicazione ad alte prestazioni. Questa consapevolezza nasceva da esperienze significative fatte negli anni ‘80 in questo settore, quali la realizzazione di una LAN estesa satellitare tra SISSA, CIRA, Università di Trento e CINECA per applicazioni di scientific visualization; la creazione di una rete urbana basata sulla tecnologia ATM che aveva permesso la convergenza delle reti fonia e dati tra le sedi cittadine; ma anche l’avvento dei primi esempi di cluster di calcolo distribuito su LAN Ethernet. Si iniziava a parlare di CWIS, Campus Wide Information System, portando l’ICT fuori dai laboratori e gettando le basi per quella trasversalità e pervasività delle tecnologie informatiche in ogni aspetto del funzionamento delle nostre organizzazioni complesse che oggi diamo per scontata.

Come e perché è nata l'esigenza di un Tier2 distribuito?

L’idea nasce a partire dall’esperienza dei Tier2. Dal momento che i sistemi grid, di cui questi centri sono dotati per il calcolo, non hanno una ridondanza intrinseca, il Tier2 singolo non nasce in alta affidabilità, che si può introdurre in seguito solo per alcune funzioni, perlopiù all’interno di un singolo sito. Così, se un certo sito cessa di essere raggiungibile, lo stesso accade ai servizi e ai dati da esso ospitati: un evento particolarmente grave se si tratta di servizi critici centralizzati e non replicati altrove. Così, quando abbiamo cominciato a lavorare al progetto PRIN LHC-STOA, che raccoglie tutte le attività PRIN relative a LHC, abbiamo pensato di inserirvi lo studio di una soluzione a questo problema e siamo partiti dai siti di Roma e Napoli, che avevano specializzazioni complementari per quello che avevamo in mente, Napoli sulle overlay network e Roma sul cloud. La sperimentazione ha combinato le due cose per rispondere all’esigenza di alta affidabilità, utilizzando tecniche di cloud computing su una connessione dedicata a livello geografico. Grazie alla connessione geografica a bassissima latenza possiamo mettere insieme le risorse dei due siti come se fossero sulla stessa LAN, riuscendo a riusare l’equipaggiamento e sfruttando al meglio le competenze dello staff presente in ciascuno.

Quali sfide e difficoltà avete dovuto affrontare?

La prima sfida che ci siamo trovati a fronteggiare era ottenere e sfruttare a livello di servizi la bassissima latenza di rete (non ci sono invece a livello di sistemi meccanismi di codifica/decodifica che introducano una latenza apprezzabile), per utilizzare lo storage condiviso tra i 2 siti in modo sincrono: la vera alta affidabilità non si fa nell’ordine dei minuti, ma dei secondi o dei millisecondi, quindi è cruciale che lo switchover tra i due siti possa essere fatto in tempo reale e lo stesso vale per i dati, che devono mantenersi consistenti.

La vera alta affidabilità non si fa nell’ordine dei minuti ma dei secondi o dei millisecondi

Oggi già possiamo spostare macchine da un sito all’altro nell’ordine dei secondi: questa operazione comporta lo spostamento di memoria e disco, ma dato che i dischi, con il nostro sistema, sono già sincroni, siamo totalmente trasparenti nello spostare interi servizi: una cosa già fattibile a livello locale ma tutt’altro che scontata a quello geografico. Altra sfida è stata il passare da un paradigma grid a uno cloud, più flessibile ed evoluto: oggi siamo in una situazione ibrida, che dal nostro punto di vista è sicuramente il momento più complicato dovendo garantire l’interoperabilità tra le due architetture, con tutta la rigidità del grid su aspetti come l’identificazione dei server, ancora gestita attraverso certificati.

Cosa avete fatto per realizzare la sperimentazione al vostro interno e come si è sviluppata la collaborazione con GARR?

ATLAS 2D - Alla scoperta dei segreti dell'Universo

ATLAS è uno dei due esperimenti che ha osservato l’esistenza del bosone di HIggs e punta a scoprire altri fenomeni di nuova fisica. Si tratta del più imponente dei rivelatori di LHC. Può ottenere molte informazioni sulle particelle prodotte nell’acceleratore registrandone la traiettoria con la precisione di pochi millesimi di millimetro. Vanta il più grande magnete superconduttore mai realizzato al mondo lungo ben 26 metri. Le sue bobine sono state costruite in Italia. Rivela l’energia, la direzione e il tipo di particelle prodotte nello scontro tra i due fasci di protoni accelerati in Lhc a energie di 14 Tev (14 mila miliardi di elettronvolt) I computer elaborano i dati ad altissima velocità per selezionare tra le decine di miliardi di interazioni prodotte ogni secondo, solo quelle interessanti registrandone circa un centinaio al secondo. L'apparato consiste in diversi tipi di rivelatori, ognuno in grado di dare una parte delle informazioni sul tipo di particella, l’energia e la direzione lungo cui si muove. Le sue dimensioni sono: lunghezza: 46 m - altezza 25 m - peso: 7.000 t

La parte di rete, realizzata a livello 2, è stata messa su velocemente e con costi minimi. GARR è riuscito a fornire il canale trasmissivo in tempi brevissimi sfruttando hardware già disponibile e sistemi di provisioning comandati da remoto dal NOC. Per quanto riguarda il setup interno ai data center, il collegamento puntopunto a 1 Gbps fornito da GARR è attestato sugli gli stessi apparati di LAN utilizzati per LHC, quindi abbiamo dovuto semplicemente modificare la configurazione. Con lo stesso hardware potremmo altrettanto facilmente aumentare la banda del servizio fino ai 10 Gbps e in futuro anche oltre, visto che prevediamo nel giro di un quinquennio di upgradare i collegamenti dei siti LHC a 40 e anche 100 Gbps. Ciò che è stato del tutto nuovo è stata la sperimentazione per capire fino a dove si poteva spingere il sistema.

Che genere di sperimentazione?

L’infrastruttura di rete è stata portata a termine nella prima metà del 2014. Parallelamente, abbiamo iniziato lo studio su storage e cloud. Completata la parte di storage, abbiamo cominciato degli stress test, con l’obiettivo di comprendere fino a che punto il sistema tollerasse un aumento di latenza, mantenendo consistenti i dati. In collaborazione con lo staff GARR, è stata aumentata la latenza ad arte, come se i siti si trovassero a quasi 10 volte la loro distanza reale, pari a circa di 350 km. Ne è emerso è che il sistema è comunque molto più veloce del vecchio servizio grid, penalizzato dagli overhead a livello di autenticazione e orchestrazione del sistema. Inoltre si è dimostrato che funzionerebbe anche con latenze maggiori e quindi anche per siti molto più distanti, aprendo quindi alla possibilità di integrarne virtualmente qualunque sito in Italia nel data center. Quando la situazione dei due siti sarà stabile e il pilota completamente operativo, potremo andare in questa direzione, sperimentando soluzioni su trasporto IP/ MPLS invece che punto-punto su rete trasmissiva, anche se in questo caso bisognerà eseguire nuove misurazioni, in quanto questa tecnologia introdurreà una latenza maggiore.

A che punto siete?

Stiamo ancora studiando come utilizzare la cloud sui due siti, in particolare un tema ancora aperto è come far coesistere tecnologie tradizionali e Open- Stack, ad esempio nel caso di servizi speciali che debbano necessariamente restare locali per motivi di sicurezza o perché non ha senso ridondarli e stiamo valutando di mettere in piedi un testbed segregato dall’infrastruttura di produzione, su cui sperimentare le varie soluzioni. In totale abbiamo lavorato a questo progetto per un anno e mezzo, con i primi 2-3 mesi impiegati tra idea e implementazione iniziale e circa un anno di test. In altri 8 mesi circa potremo ragionare sull’estensione ad altri siti attraverso MPLS, e averla operativa al completamento del progetto a fine 2015, anche se a con la ripresa della raccolta dati di LHC prevista a maggio 2015, le nostre priorità cambieranno, essendo uno dei siti di produzione, e la sperimentazione potrebbe procedere a ritmo più lento.

Quali sono le prospettive di questa esperienza per la comunità LHC? Credi sia esportabile ad altri contesti?

Il nostro non è l’unico approccio possibile all’alta affidabilità, ma ha alcuni vantaggi che lo rendono molto interessante: è poco invasivo e non comporta l’introduzione di servizi aggiuntivi, è più semplice dal punto di vista dell’implementazione e usa tecnologie consolidate – quindi è più stabile e ha costi contenuti, permettendo di ottimizzare le risorse che già si abbiano. Questa sperimentazione, i cui dati sono stati recentemente pubblicati e presentati alla conferenza internazionale su Intelligent Networking and Collaborative Systems (INCoS 2014), ha destato molto interesse anche al di fuori dei confini nazionali, non solo perché è la prima nel suo genere, ma anche perché pone le basi per un modello di data center distribuito replicabile non solo a livello di altri siti LHC o di altri esperimenti di fisica delle alte energie, ma in comunità molto differenti - ad esempio siamo stati contattati da gruppi nell’ambito dell’ingegneria industriale.

www.infn.it

 

 

Ti è piaciuto questo articolo? Faccelo sapere!
Dai un voto da 1 a 5, ne terremo conto per scrivere i prossimi articoli.

Voto attuale: