Optimización de la RED para la transferencia masiva de datos en entornos GRID

Optimización de la RED para la transferencia masiva de datos en

entornos GRIDRafael Marco de LucasInstituto de Física de Cantabria (IFCA)Esther Robles, Laura SerranoRedIRIS (red.es)

TCP

Indice• RED en el IFCA

– Descripción general del IFCA– Proyectos, Experimentos, Colaboraciones. Centro GRID.– Necesidad de una Red de calidad para hacer Investigación de calidad.– Infraestructura de Red

• Uso de una Red de Alto Rendimiento– Ideas Generales– Experiencia: Transferencia de Datos de Delphi CERN-IFCA 36TB– Almacenamiento masivo. SRM. DPM,Castor,dCache.

• Protocolos de Transporte– ¿Cuáles son?– Funcionamiento TCP– Problemática de TCP– Posibles soluciones– Ejemplos comparativos– Líneas futuras

• Pruebas, Planes y perspectiva– LHC Service Challenge– Planificación de Pruebas IFCA-REDIRIS-CERN-?Fermilab?

• Conclusiones

UCUNIVERSIDADDE CANTABRIAhttp://www.ifca.unican.es

http://grid.ifca.unican.es

• Astrofísica– Astronomía de Rayos X : XMM-Newton, XEUS– Fondo Cósmico de Microondas : Planck– Instrumentación para grandes telescopios

• Estructura de la Materia– Física Estadística y no lineal: Láseres y Sistemas Complejos– Física de Partículas (Altas Energías) : DELPHI, CMS, CDF– Computación Distribuída. GRID.

Líneas de InvestigaciónProyectos, Experimentos, Colaboraciones. Centro GRID.

Computación Distribuida en el IFCA. GRID

• Surge de las necesidades de computación– Grupo de Física de Altas Energías (DELPHI en LEP, CMS en LHC)– La computación es un aspecto crítico en el análisis de datos– Gran salto de LEP a LHC .

• Vacío Intermedio. Periodo de preparación.• CMS producirá >1PB/año . Análisis distribuido.• Jerarquía de centros de cómputo. IFCA Tier2

– Varios aspectos con distintas implicaciones para la red• Simulación y Análisis OFFLINE• Análisis Final interactivo• Aplicaciones Distribuidas (Neural Network Trainning)

– Astrofísica: Misión Planck (EGEE2)

• Participación en Proyectos– Nacionales: IRISGrid, LCG-ES– Internacionales: DataGrid, CrossGrid, LCG, EGEE– Próximos Proyectos: EGEE2, INT.EU.GRID, EELA, …– Centro GRID, Coordinación, Testbeds, Aplicaciones, Seguridad, Tests, …

Necesidad de una RED de calidad para una INVESTIGACION de calidad

• Experimentos con enorme cantidad de datos– CMS, Planck

• Las previsiones no son sencillas de hacer– ¿Cuántos reprocesados de datos serán necesarios ?– La tendencia final es trabajar en régimen próximo a la saturación.– Cuanta simulación propia del grupo de trabajo será necesaria ?

• Grandes Colaboraciones Internacionales– Competencia entre experimentos.– Competencia entre grupos.– Preparación de resultados en tiempo corto.– Reuniones de Trabajo. Resultados conjuntos. Ej. CMS Week.– No se puede trabajar desfasado por limitación de recursos.

• El acceso a los recursos de computación y a los datos es fundamental– No es lo mismo copiar/procesar unos datos en unas horas que en unos días.– No es lo mismo copiar/procesar unos datos en un día que en una semana.– La calidad de la red y los recursos de computación jugarán un papel crítico.

• Calidad de servicio de red (QoS)– Priorizar tráfico de trabajo interactivo.– Transferencias estratégicas masivas con menos prioridad.

IN2P3GridKa

TRIUMF

ASCC

Fermilab

Brookhaven

Nordic

CNAF

SARA PIC

RAL

T2

T2

T2

T2

T2

T2T2

T2

T2

T2

T2

T2s and T1s are inter-connectedby the general purpose research

networks

Dedicated10 Gbit links

T2

Any Tier-2 mayaccess data atany Tier-1 T2

T2

T2

LCG

Wide Area Network

Infraestructura de RED en el IFCA– Edificio cableado Gigabit Ethernet– 2 redes independientes :

• Dominio IFCA.UNICAN.ES (Red UNICAN)– Dentro de la Red de la Universidad de Cantabria– Protegido por el Firewall de UNICAN– Puestos de Trabajo– Servicios básicos (correo,web…)

• Dominio IFCA.ORG.ES (Red Computación IFCA)– Conexión propia a REDIRIS– Seguridad definida a medida– Centro de Computación GRID

• Redes con propósitos diferentes– Red de Datos– Conexión Nacional : 622 Mbps (doble/backup)– Conexión Internacional : Géant, …

RouterREDIRIS

(Cantabria)

RouterIFCA

(ifca.org.es)

Switch StackIFCA

(ifca.org.es)

Uso de red de alto rendimiento

– Estimación inicial del uso. Planificación.– Coordinación con los responsables de Red en ambos extremos.– Ancho de Banda coherente con los recursos de computación.– Procesado

• Cuando el objetivo sólo es el procesado el ancho de banda usado será proporcional a la capacidad de procesado del centro

• En el caso de los centros de almacenamiento deberá sumarse la capacidad de procesado de los centros que acceden de forma simultánea.

– Almacenamiento y acceso a los datos.• No es trivial almacenar y procesar de forma eficiente 1Gbps• Importancia del diseño de la red local. Red de datos.• Servidores de alto rendimiento. RAID. Jerarquía de almacenamiento. Persistencia.• Almacenamiento masivo en Cinta.

– LTO3 80MB/s. ( 2.5Gbps ~ 4 LTO3) (400GB)• Paralelización/Distribución de tareas. Alta disponibilidad.• Almacenamiento coherente. HSM. Herramientas compatibles.

– Storage Resource Manager (SRM). Uniform Access + Reservation + Scheduling– DPM.– CASTOR. CASTOR v2. – dCache.– Uso del disco local de los Worker Nodes

Transferencia de Datos del experimento DELPHICopia CERN-IFCA (1)

• Experimento Delphi en LEP. Participación fuerte del IFCA• Garantizar y preparar la reutilización de los datos • 36TB en el CERN almacenado en una librería de cintas

• 36TB, 300 cintas , 500K ficheros• CERN: castorgrid.cern.ch CASTOR + GridFTP• Thanks to the CastorGrid Team at CERN (Tony Osborne et al.)• IFCA: Esquema propio de almacenamiento LTO3 (400MB/tape)• Copia desde 15-30 nodos (10 threads/nodo)

Librería de cintas

Pool de disco duro

Copia a discoStorageManager

CERN

Librería de cintas

Pool de disco duro

Copia a cintaStorageManager

IFCA


Red Local Limitada100Mbps !!!

Estadísticas de RedIRIS

Weather Map de RedIRIS


• Estadística de datos almacenados en disco duro

2 horas

8 horas

Máximos : 68 MBytes/s = 544 Mbps

Promedio : 51 MBytes/s = 408 Mbps


• Máximos : 68 Mbytes/s = 544 Mbps• Promedio : 51 Mbytes/s = 408 Mbps• Continuos saltos de 60 a 30 Mbytes/s

– Problema: Saturación del Pool de disco• Coordinación entre Stage, Copia, Borrado• Escritura y lectura intensiva simultánea• Distribución balanceada automática de la carga

– Problemas de congestión de Red• Congestión de Red.

TCP poco eficiente (!?)• Uso de Protocolos TCP mejorados

Protocolos de Transporte.

• ¿Cuáles son?• Funcionamiento de TCP• Problemática de TCP• Posibles soluciones• Ejemplos comparativos• Líneas futuras DataTAG Project

http://www.datatag.org

Protocolos de Transporte

¿Cuáles son?• UDP (The User Datagram Protocol)

– No orientado a conexión– Sin garantías de recepción– Posibles errores– Sin orden

• TCP (Transmission Control Protocol)– Orientado a conexión

• Transmisión Garantizada• Control de flujo• Control de Congestión : Ventana de Transmisión• PROTOCOLO USADO EN INTERNET !!!


Funcionamiento TCP• Establecimiento de conexión

• Transmisión: Ventana de Transmision (CWnd=2)

• Finalización de la Conexión

SYN

ACK

ACK

ESTABLECIDO

ESTABLECIDO

SEND 1

ACK

SEND 2W

W

W


Problemática de TCP (1)• Estudios recientes muestran un rendimiento muy bajo

– Enlaces de 622Mbps, flujos de al menos 10Mbyte• 90% flujos inyectados usan menos de 5Mbps• 99% flujos inyectados usan menos de 20Mbps

• Posibles justificaciones– Maquina extremo

• Procesamiento y velocidad del bus• Configuración de parámetros de TCP : tamaño de buffers, …

– TCP en si mismo• Robusto frente a problemas de congestión• AIMD (Additive Increase and Multiplicative Decrease)


Problemática de TCP (2)• Funcionamiento de TCP: 2 Fases (AIMD)

– Estabilización• Tasa de transferencia inicial baja• Incremento exponencial de la misma hasta observar pérdidas

– Control de congestión• Pequeño incremento de tasa de transferencia• Si congestión : ts → ts/2

• Por tanto …– Demasiado cauto en su estabilización

• Cwnd aumenta 1 paquete por RTT (Round Trip Time)• Pérdida = Congestión• Tiempo de recuperación muy alto


Problemática de TCP (3)• Demasiado radical en el control de congestión

– CWnd aumenta graduamente hasta llenar la cola– Pérdida implica descenso radical de la tasa de transferencia

– Ejemplo de Tiempo de recuperación de TCP frente a una pérdidas


Problemática de TCP (4)• Importancia (1)

– Antes• CWnd = 8 paquetes

– Ahora• 10 Gbps• 1500 bytes/paquete• RTT=100ms

22.1

w

pCWnd=83333 paquetes

Probabilidad de pérdidade paquetes= 2E-10Bit error = 2E-14DEMASIADO BAJO !

Y se precisa una probabilidadde pérdida de paquetes) :

Para llenar un ancho de banda Bse debe abrir una ventana de congestión:

pRBw 2.1

pRRwT 2.1

Transmisión TCP:

(al aumentar el ancho de banda la probabilidad de pérdida requerida es cada vez menor)

Westwood+ TCP in test: use the stream of ack packages to estimate available bandwidth and set CWnd


Problemática de TCP (5)• Importancia (2)

– Justificación pérdida de paquete• Saturación• Bits corruptos

– Porcentaje bajo– Tasa de bits corruptos en SDH/SONET= 1E-7 – 1E-11 (no muy alto)

pero …

– Aplicaciones Grid (LHC, …) proponen• Supercomputación: Procesamiento de Petabytes• Capacidades en torno a 100Gbps• Retardos en torno a 50-200ms


Posibles Soluciones (1)• High-Speed TCP (HSTPC)

– Propuesto por Sally Floyd– Modifica el mecanismo de control de congestión (AIMD)– Mejora el tiempo de respuesta de TCP (demasiado conservador)

ante una pérdida• Estabilización y decrecimiento no responden a un comportamiento

constante• Como función de CWnd• Mejora del tiempo de estabilización (mas rápido)• Disminuye el tiempo de decrecimiento

http://www.icir.org/floyd/hstcp.html


Posibles Soluciones (2)• Scalable TCP (S-TCP)

– Propuesto por Tom Kelly– Basado en HSTCP– Modifica el mecanismo de control de congestión (AIMD)

• Ajuste mas fino del tiempo de estabilización y decrecimiento• Se modifica el valor de CWnd en cada RTT

– Aumenta si paquete recibido correctamente– Disminuye si hay pérdidas

http://www.Ice.eng.cam.ac.uk/~ctk21/scalable


Posibles Soluciones (3)

• FAST TCP (FAST-TCP)– Propuesto por Steven Low– Basado en Vegas– Considera TCP como un sistema de control de congestión

• RTT primer parámetro para detectar alguna posible señal de congestión

• Retardo y ACKs de cada paquete, como información para determinar una posible congestión

– Mejores resultados que otras aplicaciones

http://www.netlab.caltech.edu/FAST/


Posibles Soluciones (4)

• Otras implementaciones– HSTP-LP

• Mezcla entre HSTP y LP (Low Priority)– BIC-TCP

• AI (Additative Increase) para CWnd altas• Búsqueda binaria para Cend baja

– HTCP• Similar a HS-TCP• AIMD algoritmo heterogéneo


Ejemplos Comparativos (1)

• TCP frente a S-TCP

Comportamiento de TCPen enlaces de gran capacidad

Comportamiento de S-TCPen enlaces de gran capacidad


Ejemplos Comparativos (2)

• TCP frente a FAST-TCP

Ejemplo comparativo de la utilización del enlace de FAST-TCP frente a TCP en función de la capacidad

Full physics

run

First physics

First beams

cosmics

2007

2005

2008

2006

Building the ServiceSC1 - Nov04-Jan05 - data transfer between CERN and three Tier-1s (FNAL, NIKHEF, FZK)

DRC1 – Mar05 - data recording at CERN sustained at 450 MB/sec for one week

SC2 – Apr05 - data distribution from CERN to 7 Tier-1s – 600 MB/sec sustained for 10 days (one third of final nominal rate)

SC3 – Sep-Dec05 - demonstrate reliable basic service – most Tier-1s, some Tier-2s; push up Tier-1 data rates to 150 MB/sec (60 MB/sec to tape)

SC4 – May-Aug06 - demonstrate full service – all Tier-1s, major Tier-2s; full set of baseline services; data distribution and recording at nominal LHC rate (1.6 GB/sec)

LHC Service in operation – Sep06 – over following six months ramp up to full operational capacity & performanceLHC service commissioned – Apr07

DRC2 – Dec05 - data recording sustained at 750 MB/sec for one weekDRC3 – Apr06 - data recording sustained at 1 GB/sec for one week

today

LCG

DRC4 – Sep06 - data recording sustained at 1.6 GB/sec

Key dates for Service Preparation

SC3

LHC Service OperationFull physics run

2005 20072006 2008

First physicsFirst beams

cosmics

Sep05 - SC3 Service PhaseMay06 –SC4 Service Phase

Sep06 – Initial LHC Service in stable operation

SC4

• SC3 – Reliable base service – most Tier-1s, some Tier-2s – basic experiment software chain – grid data throughput 150 MB/sec (60 MB/sec to tape) at Tier-1s• SC4 – All Tier-1s, major Tier-2s – capable of supporting full experiment software chain inc. analysis – sustain nominal final grid data throughput (aggregate 1.6 GB/sec to tape)• LHC Service in Operation – September 2006 – ramp up to full operational capacity by April 2007 – capable of handling twice the nominal data throughput

Apr07 – LHC Service commissioned


Líneas Futuras

• FASTNESS– Propuesta al 6º programa marco de la comisión europea– RedIRIS es partner del proyecto– Objetivo:

• Recopilar, estudiar y evaluar implementaciones de TCP• Estudio comparativo, pruebas en redes reales• Diseminación

– Dentro de RedIRIS• Pruebas en colaboración IFCA y CERN

– Familiarización con las implementaciones, algoritmos, …– Transferencias para evaluar el rendimiento de algunas implementaciones

Conclusiones• La red jugará un papel fundamental• Estamos en un periodo de preparación• ¿Transición LEP-LHC traumática?• Optimización de los recursos de RED• No sólo cuenta la red, tambien el almacenamiento,…• TCP tiene grandes limitaciones• Comparativa TCP mejorados

– IFCA-RedIRIS-CERN

Optimización de la RED para la transferencia masiva de datos en entornos GRID

Documents

Transcript of Optimización de la RED para la transferencia masiva de datos en entornos GRID