Medidas e Implicaciones

En el artículo que describe VL2 [Gre+09b] se considera que, antes de comenzar su diseño, es necesario entender los entornos de centros de datos en los que se aplicará. Aunque ya se conocen las principales necesidades, desarrollar los mecanismos concretos en los que construir la red requiere entender de manera más cuantitativa la matriz de tráfico (quién manda cuánta cantidad de datos a quién y cuándo) y variabilidad (cómo de frecuentes son los cambios en el estado de la red debido a cambios en la demanda o fallos de enlace o switch, etc).

En los estudios de medida realizados, se encontraron dos resultados clave a la hora de diseñar la red. Primero, los modelos de tráfico en un centro de datos son muy divergentes (dado que ni con 50 matrices de tráfico representativas se cubrían mínimamente el total de matrices vistas), y cambian rápidamente y de manera impredecible. Segundo, las topologías jerárquicas son intrínsicamente poco fiables, incluso poniendo gran esfuerzo y gasto en aumentar la fiabilidad de los dispositivos de la red cercanos a la parte superior de la jerarquía, igualmente suceden fallos en los mismos, implicando significativos tiempos sin operación.

Análisis de Tráfico de Centros de Datos

El análisis de datos Netflow y SNMP (Simple Network Management Protocol) mostró las siguientes tendencias:

1. La proporción de volumen de tráfico entre servidores en comparación con el tráfico que entra y sale de los centros de datos es actualmente de 4:1 (excluyendo aplicaciones de entrega de contenidos en red).

2. La computación en centros de datos se centra donde los accesos a altas velocidades de datos, en memoria o disco, son rápidos y baratos.

3. La demanda de ancho de banda entre servidores dentro de un centro de datos, crece a mayor velocidad que la demanda de ancho de banda hacia hosts externos.

4. La red es un cuello de botella para la computación. A menudo se observan switches ToR (Top of Rack) con enlaces cuya utilización supera el 80%.

Análisis de la Distribución de Flujos

Distribución del tamaño de los flujos

La siguiente figura muestra la naturaleza de los flujos en los centros de datos monitorizados. En rojo y con ‘+’: número de flujos para cierto tamaño; en azul y con ‘o’: distribución de bytes en la red, es decir, probabilidad de que cierto byte al azar pertenezca a un flujo de cierto tamaño. La parte superior muestra dichos valores en porcentaje y la inferior en acumulado.

Figura 25. Estadísticos sobre flujos en los centros de datos monitorizados [Gre+09b]

Como se puede observar, los flujos “ratones” (como se denominan en el artículo, por ser pequeños) son numerosos: un 99% de los flujos son más pequeños de 100MB. Sin embargo, más del 90% de los bytes en la red pertenecen a flujos entre

100MB y 1GB, es decir, que casi todos los bytes en el centro de datos se transportan en flujos cuyas longitudes varían en ese rango. Además, es importante ver que son poco habituales los flujos con un tamaño mayor a unos pocos GB.

De manera similar a las características de los flujos en Internet [CBP95], existen muchos “ratones”. Por otro lado, la distribución es más sencilla y uniforme en el caso de los centros de datos. La razón es que en los centros de datos, los flujos internos surgen dentro de un entorno de ingeniería conducido por una serie de cuidadosas decisiones de diseño.

Número de flujos simultáneos

En este caso, se demuestra que más del 50% del tiempo, una máquina media en el centro de datos tendrá alrededor de 10 flujos simultáneos, pero al menos el 5% del tiempo tendrá más de 80 flujos simultáneos. Casi nunca se ven más de 100 flujos a la vez.

Análisis de la Matriz de Tráfico

En este caso la pregunta es: “¿Existe alguna regularidad en el tráfico que pueda ser aprovechada a través de medidas cuidadosas e ingeniería de tráfico?”. Sorprendentemente, el número de matrices de tráfico representativas en el análisis que se realizó es bastante grande. Por ejemplo, en una serie de 864 matrices analizadas indicando un día de tráfico en el centro de datos, incluso tomando 50 o 60 como referencia, el margen de error permanece con un valor mayor al 60%. Esto indica que la variabilidad en el tráfico de centros de datos no es fácilmente resumible en unos pocos modelos y, por lo tanto, la ingeniería de tráfico aplicada en base a unas pocas matrices de referencia no funcionaría correctamente en la práctica.

La siguiente pregunta sería: “¿Cómo de predecible es el tráfico en el siguiente intervalo de tiempo conocido el tráfico actual?”. Tampoco es previsible. Esta falta de previsibilidad parte del uso de aleatoriedad para mejorar el funcionamiento de aplicaciones de centros de datos. Por ejemplo, los sistemas de archivos distribuidos reparten los datos al azar entre todos los servidores para distribución de carga y redundancia.

Características de los fallos

Se recogieron logs de fallo durante más de un año de ocho centros de datos de producción que contenían cientos de miles de servidores, con cientos de servicios de la “nube” (cloud services) y servían a un millón de usuarios. Los fallos analizados fueron tanto hardware, como software, de switches, routers, cortafuegos, etc. Se define un fallo como el evento que ocurre cuando un sistema o componente es incapaz de realizar su función requerida por más de 30 segundos.

Como se esperaba, la mayoría de los fallos eran pequeños (es decir, el 50% de los fallos implicaban menos de 4 dispositivos y el 95% menos de 20). Sin embargo, los tiempos de caída pueden ser significativos: el 95% de los fallos se resuelve en 10 minutos, el 98% en menos de 1 hora, el 99,6% en menos de 1 día, pero el 0,09%

duraban más de 10 días. Además, las causas principales de las caídas fueron malas configuraciones de red, bugs de firmware y componentes defectuosos.

2.2.1.2Diseño

Los principios de diseño en VL2 son:

 Aleatorizar para sobrellevar la volatibilidad: Es decir, VL2 utiliza VLB

(para que la distribución del tráfico dependa del destino, es decir, sea aleatoria) para poder sobrellevar la gran divergencia e impredecibilidad del tráfico en centros de datos.

 Construir sobre una tecnología de red comprobada: VL2 se basa en el

encaminamiento de IP y otras tecnologías ya disponibles en switches

commodity como el encaminamiento con estado de enlace y ECMP. VL2 usa un protocolo de estado de enlace para mantener la topología de switches, pero no para conocer información de los hosts, lo que evita tener que aprender grandes cantidades de información de hosts en constante cambio. Además, el diseño de encaminamiento utiliza ECMP.

 Separar nombres de localizadores: El esquema de direccionamiento

de VL2 separa los nombres asignados a aplicaciones, de sus localizaciones, y utiliza un sistema de directorio fiable y escalable para mantener los mapeados entre nombres y localizaciones.

 Abarcar a los sistemas finales: Por ejemplo, el agente VL2 permite un

control fino de los caminos ajustando la aleatoriedad usada en VLB. Este agente también reemplaza la funcionalidad de los mensajes ARP con consultas al sistema de directorio de VL2.

En cuanto a la arquitectura escogida para VL2, ya se conoce que las topologías convencionales jerárquicas tienen un ancho de banda de bisección (bisection bandwidth) muy pobre y además se ven más afectadas por los fallos. Por lo tanto, para VL2 se construye una red amplia, ofreciendo enorme capacidad en base a usar un gran número de dispositivos sencillos y baratos, como muestra la Figura 26. Se trata de un ejemplo de red Clos plegada [DT04].

Envío de Paquetes y Resolución de Direcciones

VL2 utiliza dos familias diferentes de direcciones IP, como se ilustra en la Figura 27. La infraestructura de la red opera usando, por un lado, las direcciones significativas topológicamente, Locator Addresses (LAs) y, por otro, las de aplicación,

Application Addresses (AAs). Se asignan LAs a todos los switches e interfaces, y los switches corren un protocolo de encaminamiento de estado de enlace que sólo disemina estas LAs. Esto permite a los switches obtener toda la topología de switches y encaminar los paquetes a través de caminos mínimos en base a dichas LAs. Mientras que las AAs permanecen inalteradas al margen de la localización en cada momento del servidor. Cada AA está asociada a una LA y el sistema de directorio de VL2 almacena el mapeado de ambas, que se crea cuando un servidor comienza un servicio y se le asigna una AA.

Figura 27. VLB en un ejemplo de red VL2. El emisor S envía paquetes al destino D

mediante un switch intermedio escogido aleatoriamente y usando encapsulamiento IP-in-IP. AAs pertenecen a 20/8 y Las a 10/8. H(ft) es una function hash de la tupla

[Gre+09b]

Para encaminar tráfico entre servidores, que usarán direcciones AA, sobre una red que conoce las rutas para las direcciones LA, el agente VL2 en cada servidor captura los paquetes en el host y los encapsula con la dirección LA del ToR de destino tal y como se muestra en la figura anterior. Cuando el paquete llega al ToR destino, el switch desencapsula el paquete y lo reparte al destino AA que contiene la cabecera interna.

Los servidores que comparten servicio están configurados de manera que piensan que todos ellos pertenecen a la misma subred IP. Por lo tanto, cuando una aplicación manda un paquete a una AA por primera vez, se emite un ARP y el agente VL2 recoge ARP Request, broadcast, y lo convierte en una consulta unicast al sistema de directorio de VL2. El directorio responde con la LA del ToR destino y el agente guardará en caché el mapeado de AA a LA para evitar futuras consultas. Un servidor no puede enviar tráfico a una AA si el servicio de directorio no quiere proporcionarle la LA correspondiente. De esta manera se pueden aplicar políticas de control de acceso.

Reparto Aleatorio de Tráfico por Múltiple Caminos

Dado que las matrices de tráfico se conoce que son aleatorias, para evitar la generación de puntos calientes (hot spots), es decir, puntos con elevada carga de trabajo en comparación con el resto de la red, VL2 pone en práctica dos mecanismos relacionados: VLB y ECMP. Los objetivos de ambos son parecidos, pero se aplican los dos para que uno quite las limitaciones del otro.

En la figura anterior, se ve un ejemplo en el que VLB encapula para transmitir a través de un switch intermedio al azar (en verde), luego éste desencapsula y lo manda al ToR destino, que volverá a desencapsular para mandar al destino. Para evitar tener que actualizar todos los agentes cada vez que un switch intermedio no está disponible, en la práctica se asigna la misma dirección LA a todos los switches de este tipo. Mientras, ECMP se encarga de mandar los paquetes encapsulados a los switches intermedios y de hacer que los fallos de enlace o switch sean transparentes a los agentes VL2.

Compatibilidad “Hacia Atrás”

A los servidores que necesiten ser directamente alcanzables desde Internet (es decir, desde fuera del centro de datos) se les asignan dos direcciones: una LA aparte de la AA usada para comunicación dentro del centro de datos. Esta LA se escoge de un grupo anunciado a través de BGP. Así el tráfico puede comunicarse directamente con el servidor, y el tráfico del servidor saldrá a través de los switches intermedios, mientras que dentro de los enlaces del centro de datos se difundirá medianet ECMP.

Además VL2 proporciona semántica de capa 2 para que las aplicaciones tengan compatibilidad “hacia atrás”, y eso incluye soportar broadcast y multicast. VL2 elimina complementamente las fuentes más comunes de broadcast: ARP y DHCP. ARP se reemplaza por el directorio, y los mensajes DHCP se interceptan en el ToR usando agentes relay convencionales de DHCP y reenviando en unicast el tráfico a los servidores DHCP. Para manejar el resto de tráfico broadcast de capa 2, a cada servicio se le asigna una dirección IP multicast, y todo el tráfico broadcast en ese servicio se maneja vía IP multicast usando dicha dirección multicast. El agente VL2 limita el tráfico broadcast para prevenir tormentas.

El Sistema de Directorio de VL2

El directorio de VL2 proporciona tres funciones clave: búsqueda de mapeos de AA a LA, actualización de estos y un mecanismo de actualización de caché reactivo

de manera que las consultas y actualizaciones se realicen rápidamente. Los objetivos de diseño son facilitar la escalabilidad, fiabilidad y alto rendimiento. El directorio se compone para ello de un número modesto (50-100 servidores de cada 100.000) de servidores de directorio, y un pequeño número (5-10 servidores) de servidores para replicación asíncrona y almacenamiento fiable de mapeos.