Meeting: Phase I Network planning

Date: 2016-04-05
People:

• MatiasAlejandroBonaventura
• Eukeni

Goals: Update de los planes para la red FELIX. Definir objectivo para la simulacion.

Decitions: Algunas ideas que se me ocurren para simular esto.

Summary

Me contó lo que estuvo hablando con Wainer y David sobre la nueva red para FELIX.

La semana que viene se vuelve a juntar para definir mas cosas y el 23/5 presenta ideas en la TDAQ week.

Sistemas para la red Felix

En el TDR sería esta la red que hay que diseñar (la caja que dice "COTS network"):

Acá se vé cuales serian los sistemas que se van a conectar a la red. Para la Phase I, unicamente para 2 subdetectores van a estar bajo FELIX (L1Calo y NewSmallWhell). El resto sigue con el mismo esquema que antes sin modificaciones (Detector -> FE -> ROD -> ROS)

FELIX
FELIX hace de "switch" entre protocolos específicos del detector (GBT links) y una red estandard (puede ser Ethernet, Inifiband, OMNIPATH). De esta manera FELIX permite tener todos los sistemas implementados en servidores estandard (COTS) en vez de hardware especifico como es ahora. FELIX entonces va a hacer de nexo entre el detector y los servicios.
La palabra "FELIX" (Front End LInk eXchange) esta un poco sobrecargada: por un lado es este sistema a nivel funcional, que va a estar implementado con muchos servidores "FELIX servers", los cuales van a tener unas placas específicas "FELIX cards" que entienden y hacen la interacción de todos los protocolos (PCIe Gen3, con FPGA con 24 GBT links y PCIe dual NICs para la red que corresponda).
El responsable de este sistema es Jim Long (o algo asi), pero esta en EEUU (para preguntarle por ejemplo cuales van a ser los rates esperados)

DCS (Detector Control System)
DCS controla, mide y regula parámetros de la infraestructura del detector para garantizar su seguridad (temperaturas, radiacion, configuraciones, voltajes, etc). También se encarga del control de las habitaciones de servidores USA15 (cooling, power, etc).

Control & Configuration
Para controlar y configurar los subdetectores y servidores. Ej: ssh, pmg, IPMF, etc

Monitoring & calibration
Calibration es la data que usan los subdetectores para calibrar (cosmic data). Siempre que no hay un beam estable estan calibrandose.
Monitoring es todo lo que tiene que ver con trackear las aplicaciones. Son los servicios de IS, Histogramming, etc

DAQ (Data Adquisition)
Esto es lo que conocemos: sistema para filtrar y almacenar los datos permanentemente. RODs, ROSes, HLT farm, etc.
Una diferencia es que los subdetectores que esten bajo FELIX, van a reemplazar los actuales ROD y ROS, por un único servidor que llaman Software ROD (SW ROD). Por lo que FELIX se va a comunicar con estos SW ROD: FELIX -> SW ROD -> TPUs

Sistemas desde el punto del dataFlow

System	Priority	Data* *Req (BW)	Latency Req	FlowDirection	Servers	Comment
FELIX	Depends	Depends	Depends	Todos	<64	Todo el trafico pasa por estos servidores. Los fragmentos van a salir en ráfagas de los servidores FLX, y ademas las ráfagas van a estar sincronizadas en todos los servidores FLX.
DCS	Super High	Low	High	DCS <--> FELIX	dentro de la red ATCN. 3 racks en USA15, mas en la superficie	Este sistema no puede fallar porque se rompe el detector. La información de control es poca.
Ctrl/Config	High	Low	Med	Ctrl/Conf <--> ????	>32 servers ONL	(PMG+SSH+NFS) Este sistema no deberia fallar porque se pierde acceso a los server y subdetectores. La información suele ser muy poca.
Monitoring	Low/Med	High	Low	Monitoring <-- Todos	>40 servers	(Histogramas) Puede utilizar mucho BW, pero no es problema limitarlo (baja la frecuencia de publicación, usan UDP). No tener monitoring no es aceptable
Calibration	Med	Med	Low	Calibration <-- FELIX	>64 servers	La calibración se da cuando no hay data taking y momentos de baja prioridad. Puede ir por el mismo canal de los datos y utiliza mucho menos BW.
DAQ (data)	High	High	Low	SW ROD <-- FELIX	<64 server (SW RODs)	Mucha data en bursts.

[update 27/52016]
Cada servidor Felix va a comunicarse con 1 SWROD, en algunos casos 2 Felix van a comunicarse el mismo SWROD. Para Phase II posiblemente sea al revez (1FLX --> 2 DataHandlers)

Diseño de la red

Para esto Eukeni pensó en 3 alternativas (detalles abajo):

1. Arquitectura leaf-spine con muchos routers pequeños
2. Basada en 2 core routers gigantes con 700 puertos c/u
3. Opción loca: la opcion 1) con 2 routers gigantes pero que también conecten todos los nodos del HTL.

Sea cual sea la arquitectura, un tema a resolver son las prioridades para cada flujo.

NOTA: Los diagramas posiblemente no sean correctos. La semana que viene Eukeni tiene que presentar esto y seguramente haga un diagramas mas completos.

Aca los modelos posibles switches/routers que tiene disponible ARISTA: Arista_Switch_Models.pdf (velocidades: 1,10,40 y 100GbE. #puertos: desde 4 hasta 768, memoria: de 4MB a 144GB )

1- Topología leaf-spine

Una opcion es usar una topología leaf-spine | leaf-spine usando muchos switches pequeños.

(El diagrama posiblemente este mal. Es solo un esquema que dibujamos rapido en papel).

https://www.draw.io/#G0B0Spz4YE9z7_TWMyQ0R3aGpZOXM

Algunas de las cosas que trae aparejada esta topologia:

1. Tiene ciclos y los algoritmos clásicos no se pueden usar (SpanningTree cancela los ciclos, pero anula los links que se quieren para redundancia).
   Se suele usar Trill o SDN. Con Omnipath se usaria SDN y un host central que arbitra el trafico.
   ver: Trill vs SPB
2. Hay que garantizar que no haya drops.
   Una opcion es DCB (que usa QCN), una especie traffic shaping (TS) que envia señales del nodo receptor al emisor para que baje el BW.
   Por simulación ver la necesidad de los buffers, que mecanismos de TS es mejor, en que nodos hacer buffering, etc.
3. Por simulación, ¿Cuántos links de 100Gbps son necesarios para agregar los 32 links de 40Gbps? ¿cuanto buffer en los switches?

Muchas cosas todavia no estan definidas completamente:

1. La red de control puede que sea una red separada. Lo que es seguro es que en la red va a incluir DAQ/Mon/Calib. Tal vez Ctrl/Config se conected directo con SDX1. Idem DCS.
2. #NICs per Felix. En principio cada Felix va a tener una salida de 40Gbps, pero seria deseable tener 2 por Redundancia y mayor capacidad.
   Pero tiene sus problemas: 1) Las PCIe llegan a un maximo de 60Gbps, asique no podrian usarse ambos links al 100%. 2) No pareceria haber una tecnologia de ruteo que use eficientemente los 2 links: hashes no servirian porque la mayoria del trafico va hacia el mismo host (algun SWROD). RRobin complica el trancing. Active backup es solo por redundancia pero no utiliza los 2 links.
3. La cantidad de leaf-switches y spine-switches. Va a depender de trafico, buffer necesario, cantidad de puertos, dispositivos y precio que se consiga en el mercado.
   Para tener una referencia ver los Arista_Switch_Models.pdf

2- Topología con Core routers

Existen unos routers con capacidad de hasta 700 puertos (de 40Gbps y 100Gbps). Ver Arista_Switch_Models.pdf (modelos 7300 y 7504/7508E con 144GB de buffer)
La idea de esta topología es tener 2 de estos mega routers y conectar todo directamente a ambos (para redundancia).

https://www.draw.io/#G0B0Spz4YE9z7_UWVzNnF4dmRjajA

Algunas cosas de esta topologia:

1. Es simple, facil de monitorear, rastrear, mantener, etc
2. Si falla algo dentro de USA15 es mas dificil de acceder. No todos tienen permisos
3. USA15 le queda poco espacio. Tener 700x2 links es bastante engorroso y hay que luchar por espacio.
4. ¿Que pasa si un router se cae? Hay redundancia, pero baja el BW a la mitad. Eukeni dice que es muy poco probable que eso pase.

3- Topología unificando FELIX Network con HLT network

En la red del HTL no va a haber muchos cambios para Phase I. Sin embargo, la garantia de los Brocade se va a expirar. Opciones:

1. Renovar la garantia, pero Brocade deberia firmar que le va a seguir dando soporte hasta 2028 cosa que es poco probable.Sin cambios
2. Reemplazar los 2 core routers por los ultima generación del mismo modelo. Sin grandes cambios.
3. La opcion loca es la topologia de 2) pero con todos los nodos del HLT tambien conectados a esos 2 mega core routers. Con 700 puertos deberia alcanzar para conectar todo

Algunos problemas de esta opcion:

1. Los mega core routers deberian estar en la caberna, en USA15. El HTL esta afuera, por lo que los cables deberian ser bastante largos (y caros)
2. los mismos que la opcion 2)
3. Todo depende de estos routers

cosas buenas:

1. aun mas simple. Todo en una unica red
2. Los links de los SW ROD se utilizarian bi-direccionalmente. Son todos los links son full-duplex, pero se utilizan mayormente en una sola direccion. En este caso los links de los SW RODs se usarian para ambos lados (bueno porque se aprovechan mejor la inversion en los links, puede traer problemas de dataflow?)

Simulación

Lo que le gustaria a Eukeni resolver con simulación

1. Como asignar las prioridades a cada flujo de datos. Que porcentajes de cada link a cada flujo? Requerimientos minimos de BW de cada flujo?
2. Sizing de la red (servidores, links, etc). En particular, cuandto links de 100Gbps son necesarios para agregar los de 40Gbps?
3. Cuanto buffering seria necesario en cada nodo.
4. potenciales cuellos de botella
5. Mas adelante: evaluar diferentes opciones de "Traffic shaping" para evitar descartes (en caso de usar Ethernet).

Algunas ideas que se me ocurren para simular esto.

-- MatiasAlejandroBonaventura - 2016-05-10