La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Esigenze di rete per il calcolo LHC Workshop CCR LNL, 16-18 Febbraio 2011 Stefano Zani INFN CNAF 1S.Zani INFN CNAF.

Presentazioni simili


Presentazione sul tema: "Esigenze di rete per il calcolo LHC Workshop CCR LNL, 16-18 Febbraio 2011 Stefano Zani INFN CNAF 1S.Zani INFN CNAF."— Transcript della presentazione:

1 Esigenze di rete per il calcolo LHC Workshop CCR LNL, 16-18 Febbraio 2011 Stefano Zani INFN CNAF 1S.Zani INFN CNAF

2 Contenuti della presentazione Descrizione della connettività Geografica T0-T1 e T1-T1 (LHC-OPN) Stato di utilizzo dei principali link utilizzati per il collegamento dei Tier2 di LHC Prospettive di evoluzione della connettività geografica in relazione al mutamento dei modelli di distribuzione dei dati di LHC. 2S.Zani INFN CNAF

3 3

4 … T1 Stato dei collegamenti di rete per il traffico LHC GARR General IP Backbone NA T2 NA T2 RM T2 RM T2 PI T2 PI T2 LNL T2 LNL T2 MI T2 MI T2 CNAF T1 CNAF T1 CERN T0 CERN T0 LNF T2 LNF T2 2x1Gb/s 10Gb/s 1Gb/s 2x10Gb/s OPN Via GARR 1Gb/s 2x1Gb/s 3x1Gb/s T1 LHC OPN T0-T1 T1-T1 T1-T2 + General Purpose TO T2 TO T2 1Gb/s GEANT 2,5Gb/s 2x10Gb/s 4S.Zani INFN CNAF BA T2 BA T2 CT T2 CT T2

5 Uso dei Link OPN CNAF (T1) : 2x10Gb/s (T0-T1, T1-T1) - BNL,FNAL,TW,NDGF General Purpose CNAF 1x10Gb/s (General) T1-T2 + BNL,FNAL,TW,NDGF (T1-T1) Con il raddoppio del link con il CERN su LHC-OPN, tutto il traffico T1-T1 passerà dal Link OPN. Il link “General Internet” verrà utilizzato principalmente per traffico T1-T2. 5S.Zani INFN CNAF

6 Uso dei link MI :1x1Gb/s  10gb/s (Garr-X) LNL :2x1Gb/s  10gb/s (Garr-X) PI :1x1Gb/s  2x1Gb/s(in corso)  10Gb/s(Garr-X) 6S.Zani INFN CNAF

7 RM :3x1Gb/s  10gb/s (Garr-X) LNF :1Gb/s  10gb/s (Garr-X) NA:2x1Gb/s  10gb/s (Garr-X) Uso dei link 7S.Zani INFN CNAF

8 CT:1Gb/s  10gb/s (Garr-X) BA:2x1Gb/s  10gb/s (Garr-X) Uso dei link TO:1Gb/s  10gb/s (Garr-X) 8S.Zani INFN CNAF

9 In questo momento anche se i valori di utilizzo medio integrato in un anno sono relativamente bassi, si registrano frequenti picchi di saturazione dei link. Con la realizzazione di GARR-X ci si aspetta che tutti i T2 vengano collegati a 10 Gb/s (al pari dei più grandi T2 mondiali). Uso dei link 9S.Zani INFN CNAF

10 Connessioni di rete dei T2 Le reti, per come sono state realizzate fino ad oggi non sono state pensate per veicolare questo tipo di traffico. I link transatlantici per il trasporto di dati a scopo R&E (research and education) non sono dimensionati opportunamente per sopportare il carico potenziale dei trasferimenti T2-T1 T2-T2 fra Europa e Stati Uniti. Situazioni di congestione si possono facilmente verificare anche all’interno delle reti nazionali. Il mutamento dei modelli di calcolo degli esperimenti e l’abbandono dell’approccio “Monarc”, produce flussi di traffico sostenuti potenzialmente da ogni T2 ad ogni T1 o T2 nel mondo. 10S.Zani INFN CNAF

11 Tier-2 Connectivity Categories (Kors Boss) Un gruppo coordinato da Cors Boss (Atlas) con con il coinvolgimento dei 4 esperimenti LHC ha effettuato una stima delle esigenze di banda per T2 ed ha classificato i tier2 in tre categorie in base alle dimensioni. Minimal  1Gb/s Nominal  5Gb/s Leadership  10Gb/s L‘uso della banda sarà legato agli update dei dati ed ai burst di analisi per cui il backbone non dovrà sopportare flussi full rate verso tutti i T2 contemporaneamente, ma il “Backbone” deve sopportare trasferimenti a full rate verso tutti i T2 di categoria “Leadership”. http://indico.cern.ch/getFile.py/access?contribId=5&resId=3&materialId=0&confId=102716 11S.Zani INFN CNAF

12 LHC ONE ed il Modello di connettività per i T2 Attualmente i T2 (ed i T3) sono collegati via “general internet” Il nodo cruciale è come interconnettere tutti i T2 ed i T1 a livello mondiale in modo più efficiente. Sul nuovo modello di collegamento si è cominciato a lavorare all’interno di LHC-OPN in un gruppo che vede NRENs (National Research and Education Network) e “utenti HEP”. Si sta profilando una rete dedicata al trasporto del traffico T3- T2-T1 a cui ogni TIER chiamato per convenzione “Connector” potrà collegarsi. II nome proposto è LHC ONE (LHC Open Network Environment) LHCONE sarà basata su Exchange Point collocati in posizioni “Carrier-neutral” e ben connessi a livello internazionale. Ogni TIER potrà connettersi ad uno o più Exchange Point direttamente o tramite una “Aggregation Network” come per esempio DFN, GARR, RENATER, GEANT... 12S.Zani INFN CNAF

13 LHCONE Schema del modello Aggregation Network Aggregation Network Aggregation Network Aggregation Network T2T1T2 T1T2 LHCONE continent T2 distributed exchange point single node exchange point 13S.Zani INFN CNAF

14 Non sono ancora state identificate precisamente le sedi degli exchange point. Per l’Europa molto probabilmente uno si troverà ad Amsterdam (Per via della ottima connettività continentale e transatlantica), negli Stati Uniti verosimilmente saranno a NY (ManLan) e Chicago (Starlight). 14S.Zani INFN CNAF

15 LHC ONE Governance In maniera simile alla gestione di LHC OPN, sarà una gestione federata con la partecipazione di tutti i soggetti coinvolti: I “Connectors”, gli “Exchange Point operators”, Il CERN e gli esperimenti. La Governance è responsabile della definizione dei requirement per la partecipazione ad LHC ONE oltre alla definizione delle Policy e della allocazione delle risorse all’interno di LHC ONE. La Governance definirà la distribuzione dei costi fra i vari componenti. Verosimilmente i “Connectors” dovranno pagare la connettività verso gli exchange points, ma per il resto della struttura ed i link ad alta velocità fra gli exchange point ancora non è chiaramente definito “Chi paga cosa” http://indico.cern.ch/getFile.py/access?contribId=4&resId=1&materialId=slides&confId=110149 15S.Zani INFN CNAF

16 Aggregation Network Aggregation Network Aggregation Network Aggregation Network T2 T1 T2 T1 T2 LHCONE continent T1 T2 distributed exchange pointsingle node exchange point LHC ONE e LHCOPN CERN LHC OPN L‘unico punto di contatto fra LHC ONE ed LHC OPN sono i T1 che avranno un link con entrambe le reti ma non ci sarà transito fra una rete e l‘altra 16S.Zani INFN CNAF

17 Connettività IP su backbone di livello 2 (Shared VLAN) – LHCONE propagherà vlan fra i centri connessi e fornirà indirizzi IP da utilizzare all’interno del dominio di broadcast condiviso (Come indirizzi di punto punto) – Il routing IP viene demandato ai Tiers che si connetteranno (BGP peering) – Verrà comunqe fornito almeno un Route Server per continente per consentire a chi lo volesse, di ricevere gli annunci di tutte le reti dei TIER collegati stabilendo una unica sessione BGP. LightPath / Circuiti punto-punto di livello 2 a banda non garantita – VLAN end to end senza banda garantita possono essere create fra coppie di TIER Lightpath / Circuiti dinamici con banda garantita – Possono essere creati Lightpath fra coppie di TIER soggetti a politiche di allocazione di banda concordate con la comunità HEP. – LHCONE dovrà essere aperto a sistemi di gestione dei circuiti compatibili con DICE IDCP (Dante, Internet2, CANARIE, and Esnet) Inter Domain Control Protocol) 1 per consentire la creazione dinamica dei light path. LHCONE: Metodi di collegamento supportati 1 http://www.controlplane.net/ 17S.Zani INFN CNAF

18 CERN RT1MI1RT1BO1 CNAF switch Shared VLAN (L2) Link fisico IP B IP A IP CIP D Traffico Route server Connettività IP (Peering BGP su backbone di livello 2) Lo “use case” del secondo link CNAF-CERN può essere utilizzato come esempio di collegamento su shared VLAN Sessioni BGP I router vengono usati solo per annunciare le reti degli utenti ed il next hop è sempre la destinazione del traffico ed è raggiungibile a livello2 ( il traffico non attraversa nessun Router intermedio). Questa è la modalità con la quale i nostri T2 potranno collegarsi anche dalle prime fasi. 18S.Zani INFN CNAF

19 Lightpath e Circuiti dinamici Il concetto di base è quello di avere un piano di controllo che si occupi di configurare dinamicamente gli apparati trasmissivi (o gli switch) in modo da creare i lightpath fra gli end point. DYNES (Dynamic Network System): è un progetto che si pone l’obiettivo di creare circuiti dinamici a banda garantita. Ogni “Connector” che vuole usare DYNES, deve utilizzare un “Dynes Instrument” costituito da uno switch ed un IDC interdomain controller. L’IDC crea su questi switch una VLAN che verrà propagata END to END su tutta la struttura geografica e grazie a meccanismi di QoS alla vlan si riserverà una certa quantità di banda. Dynes nello specifico permette di collegare sedi utente alle infrastrutture di Lighpath realizzate dalle due principali reti della ricerca statunitensi Internet2 ed ESnet. In realtà funge anche da pilota per altre iniziative simili fuori dagli Stati Uniti. (http://www.internet2.edu/ion/docs/DYNES-Overview.pdf) 19S.Zani INFN CNAF

20 Considerazioni sull’oversubscription della banda di accesso geografico. In ogni TIER2 sono collegati alla rete numerosi server con interfacce a 10Gb/s (oggi un server con scheda 10Gb/s costa cifre dell’ordine dei 3 K€). Uno solo di questi server, se opportunamente configurato può generare flussi in grado di saturare il link geografico della propria sede. Dobbiamo fare crescere la disponibilità di banda passante verso i nostri TIER (Garr-X) La struttura ottica e di switching di GARR-X dovrà consentire ai nostri TIER2 ed anche al TIER1 di connettersi agli Exchange Point di LHCONE con le modalità più funzionali alla movimentazione dei dati sperimentali. A livello geografico, un accesso caotico a dati distribuiti fra Europa e Stati Uniti, comporterebbe una richiesta molto elevata di banda transatlantica i cui costi sono decisamente elevati. Sarebbe auspicabile avere una copia consistente di tutti i dati su entrambi i continenti (Non banale avere ed organizzare la quantità di storage necessario… Anche quella costa..). Occorre individuare strumenti di network monitoring in grado di dirci in ogni sede istante per istante quali sono i flussi di dati (organizzati per sorgente e destinazione) che stanno impegnando la banda di accesso alla rete geografica (NetFlow, Sflow, Jflow). Questa informazione se disponibile ed accurata, può diventare uno strumento importante per una migliore pianificazione della movimentazione dei dati da parte degli esperimenti. 20S.Zani INFN CNAF

21 Credo che ci siano almeno due temi interessanti da sviluppare nel corso dell’anno all’interno dei gruppi di lavoro di CCR possibilmente in collaborazione con il GARR 1)Monitoring ed analisi di flusso Garr sta configurando un sistema di monitoring e di analisi di flusso della rete che può essere utilissimo all’INFN. http://ginsdr.dir.garr.it/Weathermap/slice.php?slice=lhc_tier Al CNAF da più di un anno è iniziata una attività di analisi di flusso Netflow ed S-Flow per quantificare I flussi T0-T1, T1-T1 e T1-T2 che ha portato a riusltati (Presentati in Netgroup) ma c’è ancora molto da fare… 2) Light path dinamici Sarebbe interessante iniziare una sperimentazione in collaborazione con GARR GEANT e US-LHC Network per una estensione di circuiti dinamici fino a qualche nostro TIER. Riflessioni conclusive 21S.Zani INFN CNAF

22 FINE S.Zani INFN CNAF22


Scaricare ppt "Esigenze di rete per il calcolo LHC Workshop CCR LNL, 16-18 Febbraio 2011 Stefano Zani INFN CNAF 1S.Zani INFN CNAF."

Presentazioni simili


Annunci Google