Análisis del soporte a QoS en Infiniband

1. Análisis del soporte a QoS en Infiniband Carlos Miguel Tavares Calafate Clusters de Computadores Personales, 2002

2. Estándar abierto con participación de la indústria Definida en el ámbito de una SAN Armoniza la comunicación con dispositivos (PCI, SCSI, etc.) y la comunicación en red (Ethernet, Fibre Channel, etc.) Son definidos los niveles 1,2,3 y 4 del modelo OSI La arquitectura Infiniband

3. Nivel 1: se definen características eléctricas y mecánicas; canal básico es bidireccional a 2 Gbps Nivel 2: paquetes de gestión y de datos; tamaño máximo de 4 Kbytes; 15 canales de datos + 1 gestión; red conmutada Nivel 3: utilización del IPv6; escalable y flexíble Nivel 4: conexiones y datagramas; servicios fiable y no fiables La arquitectura Infiniband

4. Ejemplo de la estructura de una red Infiniband La arquitectura Infiniband HCA: Host Channel Adapter TCA: Target Channel Adapter

5. Las particiones Aspectos relacionados con la QoS • El Nivel de Servicio (SL) • Los Canales Virtuales (VL) • El mapeo SL-VL • El arbítrio de VL

6. El nivel de servicio (SL) • IBA define 16 niveles de servicio • sin características definidas • interpretados en una subred • transmitidos entre fuente y destino • el valor es colocado en el Local Route Header (Nivel 2) • independiente del canal virtual que le esté asociado

7. Suporte a QoS El nivel de servicio (SL) • Esto va a permitir: • tráfico repartido por categorías • implementación del modelo de servicios diferenciados

8. Los Canales Virtuales (VL) • Permiten múltiples conexiones en cada canal físico • Cada VL tiene asociado un buffer de entrada y otro de salida en cada puerto • Cada puerto puede tener hasta 15 canales virtuales Son obligatórios: • VL15: Gestión de la subred • VL0: Transmisión de datos

9. La elección del VL puede tener en cuenta requisitos de QoS El mapeo SL-VL • Decisión del Subnet Manager (SM) • inicialmente se utiliza el VL0 • cuando el SM determine los VLs soportados por los extremos de un canal, programa la tabla de mapeo SL-VL • distintos dispositivos pueden soportar un número diferente de VLs

10. VL Weight 0 - 15 0 - 255 Máximo de 64 entradas . . . . . . Arbítrio Round-Robin VL Weight Número máximo de paquetes de alta prioridad enviados en secuencia 0 - 15 0 - 255 . . . . . . El arbítrio de VL Tabla de arbítrio de VL Alta prioridad Baja prioridad Limit_of_High_Priority

11. Aislamento de flujos de tráfico entre particiones Garantía de ancho de banda para cada partición Las particiones • Conjunto de puertos dentro de una SAN a los que es permitida intercomunicación • cada puerto pertenece a una o más particiones • la asignación de particiones se hace con la entrega de llaves de partición a los puertos • el SM puede asignar niveles de servicio (SLs) a determinadas particiones

12. Una estratégia para calcular las tablas de arbítrio de VL

13. Modelado del tráfico • DBTS (Dedicated Bandwidth Time Sensitive) • DB (Dedicated Bandwidth) • PBE (Preferential Best Effort) • BE (Best Effort) • CH (Challenged)

14. Mapeo entre tráfico y SL

15. VL Weight 0 - 15 0 - 255 Tráfico con requisitos de tiempo real (DBTS) . . . . . . VL Weight 0 - 15 0 - 255 Tráfico sin requisitos de tiempo real (DB, PBE, BE, CH) . . . . . . Asignación de la tablas de arbítrio a los distintos tráficos Tabla de alta prioridad Tabla de baja prioridad

16. Cálculo de la tabla de arbítrio para tráfico sin requisitos de tiempo real • Se considera que no existe tráfico DBTS • Tamaño máximo de una frame = 64 x 255 slots • 64: número de entradas en la tabla • 255: valor máximo de cada entrada • cada slot tiene 64 bytes según la IBA • Se calcula el peso de cada entrada relativamente a ese límite

17. Se permite agrupar distintas conexiones con un mismo SL en una misma entrada de la tabla A cada conexión o grupo de conexiones se le puede asignar más de una entrada Cálculo de la tabla de arbítrio para tráfico sin requisitos de tiempo real Una entrada por conexión limitiria a 64 el número de conexiones simultaneas posibles

18. 256 bytes 4096 bytes Cálculo de la tabla de arbítrio para tráfico con requisitos de tiempo real • Existe una dependencia muy fuerte entre latencia y la estructura interna de los switches • Swicthes de: • 8 puertos • 4 VLs de datos • Conexiones de 2,5 Gbps Latencia (ms)

19. Estratégia: agregar todos los SLs relativos a tráfico con requisitos de tiempo real en un único VL Se utiliza apenas una entrada de la tabla de alta prioridad Cálculo de la tabla de arbítrio para tráfico con requisitos de tiempo real Existe una dependencia con la separación entre entradas en la tabla relativas a un mismo VL Mecanismo Round-Robin

20. Problemas: Ya no se puede garantizar el ancho de banda al tráfico de menor prioridad Cálculo de la tabla de arbítrio para tráfico con requisitos de tiempo real El peso de esa entrada corresponderá a la proporción requerida entre el tráfico de alta y baja prioridad

21. Resultados

22. Modelo de la red • Switches de 8 puertos (4 terminales + 4 interconexión) • Crossbar del tipo Full-Crossbar (8x8) • Tamaños de paquete - 256 bytes (mínimo) y 4096 bytes (máximo) • Buffers con tamaño igual a 4 paquetes • Red con 16 switches y canales físicos de 2,5 Gbps

23. Resultados para tráfico de baja prioridad Tráfico best-effort: Ancho de banda del 20% Tráfico DBTS: inexistente Tráfico DB:

24. Resultados para tráfico de baja prioridad • Jitter calculado en relación al IAT (Inter Arrival Time)

25. Resultados para tráfico de baja prioridad • Prestaciones de la mejor y peor conexiones en los SLs 2 y 3  El valor de IAT nunca es superado, tal como deseado

26. Resultados para tráfico de alta prioridad Tráfico best-effort: Ancho de banda del 20% Tráfico DBTS: Ancho de banda del 60% Tráfico DB: Ancho de banda del 20%  98% de los paquetes DBTS llegan antes de D/10 (D = Deadline)

27. Resultados para tráfico de alta prioridad • Jitter calculado en relación al IAT (Inter Arrival Time) DBTS DB

28. Resultados para tráfico de alta prioridad • Prestaciones de la mejor y peor conexiones

29. Conclusiones • El algorítmo alcanza los resultados deseados: • El tráfico con requisitos de tiempo real ve cumplida sus restricciones de latencia • Se hace un tratamiento adecuado del ancho de banda, cumplindo con las reservas efectuadas • El tráfico best-effort no es comprometido • En la ausencia de tráfico preferente, todo el ancho de banda es utilizado por tráfico menos prioritário.