Llegamos a ustedes gracias a:



Reportajes y análisis

El data center cambia de cara

[05/10/2009] Ha llegado el momento de la transformación para los data center. En los años venideros, el antiguo equipo de switches tendrá que ser reemplazado por alternativas más rápidas y flexibles.

Son tres los factores que marcan esta transformación: la virtualización del servidor, la conexión directa del almacenamiento del Fibre Channel al switching IP y el cloud computing en la empresa.
Todos ellos necesitan rapidez y una tasa de transferencia más alta pero, a diferencia de lo que ocurría antes, ahora no bastará solo con una interfase más veloz. En esta ocasión, la velocidad debe venir de la mano con una menor latencia, lo cual implica además abandonar la expansión en árbol y soportar nuevos protocolos de almacenamiento.
Sin estos cambios, el sueño de un data center más flexible y menos costoso no pasará de eso. El networking en el data center debe evolucionar hacia una estructura unificada de switching.
Los tiempos son difíciles, el dinero escasea; ¿tiene sentido apostar por una nueva estructura unificada? La respuesta es sí. Es enorme lo que se puede ahorrar soportando la virtualización del servidor y fusionando las redes separadas de almacenamiento e IP. Brindar soporte a estos cambios no sería posible sin la próxima evolución del switching. La buena noticia es que la transformación del switching no tomará meses sino años, así que todavía hay tiempo para planificar la transición.
Los conductores
La historia de cómo la virtualización del servidor puede ahorrar dinero es bien conocida. Correr una sola aplicación en un servidor generalmente resulta en una utilización de entre 10 y 30%. La virtualización permite que varias aplicaciones corran en el servidor dentro de su propia imagen, de manera que la utilización se incrementa hasta el rango de 70% a 90%. Además, se reduce el número de servidores físicos, se ahorra energía y se incrementa y mejora la flexibilidad operativa.
La historia del almacenamiento, en cambio, no es tan conocida, aunque el ahorro ligado a ella es tan interesante como el de la virtualización. Durante años, el almacenamiento ha estado en tránsito hacia el IP, de manera que ya hay una significativa cantidad de almacenamiento anexada a través de dispositivos NAS o iSCSI. El ahorro y el incremento de flexibilidad son evidentes.
Ahora la tendencia consiste en conectar directamente el almacenamiento Fibre Channel a los switches IP, eliminando así las redes de área de almacenamiento Fibre Channel separadas. Pasar del Fibre Channel a la infraestructura IP es una buena fuente de ahorros.
En principio, porque se reduce la cantidad de adaptadores del servidor. Los servidores actuales necesitan un adaptador Ethernet para el tráfico IP y un adaptador de almacenamiento separado para el tráfico del Fibre Channel.
Garantizar una alta disponibilidad significa que ambos adaptadores deben ser duplicados, obteniendo cuatro adaptadores por servidor. Una estructura unificada reduce esta cifra a solo dos, dado que tanto el tráfico IP como el Fibre Channel o iSCSI comparten el mismo adaptador. El ahorro es aun mayor pues al reducir a la mitad la cantidad de adaptadores se reduce también la cantidad de puertos switch y de cableado. Asimismo, los costos operacionales bajan, porque solo hay una red que mantener.
La tercera razón es la nube interna o corporativa. Anteriormente, cuando una solicitud llegaba a una aplicación, el trabajo permanecía dentro del servidor/aplicación. A lo largo de los años, esta manera de diseñar e implementar aplicaciones ha cambiado. Cada vez más a menudo, cuando una solicitud llega al servidor, la aplicación solo se ocupa de una pequeña parte del trabajo; y distribuye el resto a otras aplicaciones del data center, convirtiendo el data center en una gran nube interna.
Conectar el almacenamiento directamente a esta nube IP solo aumenta la cantidad de flujos críticos que pasan a través de la nube de switching. De esa manera, se vuelve imprescindible que la nube brinde una latencia muy baja sin pérdida de paquetes. Un ejemplo simple demuestra por qué la baja latencia es indispensable. Si la acción tiene lugar dentro del servidor, cada almacenamiento solo tardaría en ejecutarse algunos microsegundos o un nanosegundo. Con la mayoría de los switches instalados en las empresas, el envío puede tardar entre 50 y 100 microsegundos para atravesar la nube que, dependiendo de la cantidad de llamadas, puede agregar un significativo retraso al procesamiento. Si uno de los switches rechaza el paquete, la respuesta puede tardar aún más. La única manera de que funcione bien un cloud computing interno es con una latencia muy baja y una nube que no elimine paquetes. 
¿Cuál es el problema para la red? ¿Por qué cambiar los switches?
¿Por qué la infraestructura disponible de switching no puede manejar el almacenamiento y el cloud computing? Comparado con el resto de la red, los switches de data center que usamos actualmente proveen muy poca latencia, eliminan pocos paquetes y soportan interconexiones a 10 Gigabit Ethernet. El problema es que estos nuevos desafíos requieren una latencia aún más baja, mayor confiabilidad, una tasa de transferencia más elevada y soporte para Fibre Channel a través del protocolo Ethernet (FCoE).
El primer desafío es la latencia. El problema con los actuales switches consiste en que se basan en una arquitectura del tipo store-and-forward, que podría traducirse como almacenar-y enviar.
Por lo general, este modelo está asociado con aplicaciones como el correo electrónico, donde el servidor de correo recibe el mensaje, lo almacena en un disco y luego lo despacha a donde corresponde. Este enfoque resulta muy lento.
Entonces, ¿qué hay de los switches layer 2, que son dispositivos store-and-forward muy rápidos?
Los switches tienen colas largas. Cuando un switch recibe un paquete, lo coloca en una cola, y solo lo envía cuando el mensaje llega al inicio de la cola. Poner el paquete en una cola es una forma de store-and-forward. No es raro escuchar que una cola larga indica que el switch puede manejar grandes cantidades de data sin descartar nada.
El resultado de todas las colas es que pueden tomar 80 microsegundos o más para lograr que un paquete grande recorra un data center de tercer three-tier. El cálculo es el siguiente: Puede tardar 10 microsegundos en ir del servidor al switch. Cada paso de switch a switch suma 15 microsegundos más y puede agregar hasta 40 microsegundos. Por ejemplo, asumamos que dos servidores están en el otro extremo del data center. Un paquete que deja el servidor solicitante viaja hasta la parte superior de la pila de switches, luego hacia la última columna de switches y enseguida avanza hacia el switch central. En este punto, se repiten los reenvíos al server de destino. Esto significa cuatro reenvíos de switch a switch en un mínimo de 60 microsegundos. Si le agregamos los 10 microsegundos que toma alcanzar cada servidor, tenemos un total de 80 microsegundos. El retraso puede incrementarse hasta más de 100 microsegundos, y ya es un desastre si uno de los switches tiene que eliminar el paquete, lo cual implica solicitar a la consola TCP del servidor de partida un tiempo muerto para retransmitir el paquete.
Una latencia de 80 microsegundos para cada recorrido podía ser aceptable en el pasado, cuando el tiempo de respuesta se medía en segundos, pero si el objetivo es proveer tiempos de respuesta en subsegundos, cada microsegundo cuenta. Una aplicación que requiere una importante cantidad de data toma más tiempo cuando cada envío solo puede recuperar 1,564 bytes a la vez. Unos cientos de viajes de ida y vuelta tampoco ayudan. El impacto no solo es sobre el tiempo de respuesta. La aplicación tiene que esperar por la data, resultando en un incremento de la ventana de tiempo que toma procesar la transacción. Esto significa que mientras un servidor hace la misma cantidad de trabajo, hay un incremento en la cantidad de tareas simultáneas, reduciendo el rendimiento general del servidor. 
La nueva generación de switches corrige la larga latencia del pasado eliminando, o al menos reduciendo significativamente, las colas y acelerando su propio procesamiento.
Las palabras que se usan para describirlos son: transporte sin pérdidas; sin bloqueo; baja latencia; entrega garantizada; administración de congestiones y multirruta. Transporte sin pérdidas y entrega garantizada significan que no eliminan paquetes. Sin bloqueo quiere decir que no ponen el paquete en una cola, ni tampoco tienen colas de uno o dos elementos.
El primer gran cambio en el ámbito de los switches es el diseño de la forma en que el switch envía los paquetes. En lugar de un diseño store-and-forward, la mayoría opta por un diseño cut-through, que reduce sustancialmente e incluso elimina las colas en el switch. Un diseño de este tipo puede reducir el tiempo de switch de entre 15 y 50 microsegundos a entre dos y cuatro microsegundos. Este enfoque no es nuevo pero su implementación siempre ha sido más compleja y costosa. Solo ahora, debido a los requerimientos de baja latencia, los fabricantes de switches pueden justificar semejante gasto.
El segundo gran reto consiste en abandonar la expansión en árbol dentro de la estructura de switching del data center. La nueva generación de switches usa varias rutas a través de la estructura del switching para llegar a su destino. Monitorean constantemente los potenciales puntos de congestión, o las colas, y eligen la ruta más rápida y conveniente de acuerdo al momento en que se ha enviado el paquete. Actualmente, los switches layer 2 determinan la mejor ruta de un punto al otro usando el algoritmo de expansión en árbol. Solo se activa una ruta, el resto solamente se utiliza si la "mejor" falla. La expansión en árbol ha funcionado bien desde el inicio del networking  de layer 2 pero la "única ruta" no es lo bastante buena para un mundo sin colas ni eliminación de paquetes. 
Uno de los actuales problemas del enfoque multirruta es que no hay un estándar para la forma en que opera. Algunos grupos de estándares ya han empezado a trabajar para corregir este problema, pero cada proveedor tiene su propia solución para las primeras versiones. Una significativa cantidad del trabajo cae bajo un estándar referido como Data Center Bridging (DCB). La realidad es que en el futuro inmediato no es posible mezclar y reunir switches de diferentes proveedores al interior del data center. Aun cuando estándares como el DCB y otros ya estén terminados habrá muchos problemas de interoperabilidad, de manera que la mejor estrategia por ahora parece ser la solución de un solo proveedor.
La velocidad sigue siendo parte de la solución. Los nuevos switches están construidos para implantaciones muy densas de 10 Gigabit y preparados para 40/100 Gigabit. El resultado de todos estos cambios reduce el mencionado tiempo de trayecto de 80 microsegundos a menos de 10 microsegundos, proveyendo la latencia requerida y la tasa de referencia para que el canal de fibra y el cloud computing resulten prácticos.
El boomerang de la virtualización 
La virtualización del servidor crea problemas adicionales para el actual entorno de switching  en el data center. El primer problema es que cada servidor físico tiene varias imágenes virtuales, cada una de ellas con su propia dirección de control de acceso a medios (MAC). Esto produce complicaciones operativas y se convierte en un verdadero problema si dos servidores virtuales se comunican mutuamente. La respuesta más fácil es colocar un soft-switch en el VM, algo que todos los proveedores VM pueden suministrar. Esto permite que el servidor presente una sola dirección MAC al switch de la red y ejecute las funciones de un switch para los VM del servidor.
Hay varios problemas con este enfoque. El soft switch necesita aplicar parámetros y listas de control de acceso (ACL); asegurarse de que las VLAN tengan supervisión e implementen seguridad. Por ejemplo, si una imagen resulta comprometida, y los parámetros establecen que no debe comunicarse libremente con las otras imágenes del servidor, entonces esto no debe ocurrir. 
Si estuvieran en diferentes servidores físicos, la red se aseguraría de que se respeten los parámetros y los procedimientos de seguridad. La respuesta simple es que el grupo que mantiene el servidor y el soft switch debe asegurarse de que todos los controles de la red estén en orden. El problema práctico con este enfoque es la coordinación que se requiere entre los dos grupos y el nivel de conocimiento de networking que requiere el grupo del servidor. Si el grupo de red es el que mantiene el soft switch en el servidor, los problemas son los mismos. 
Hoy por hoy, la respuesta es aprender a lidiar con la confusión,  desarrollar procedimientos para sacarle el mejor partido a la situación y esperar que las cosas salgan bien. Una variación de esta alternativa consiste en usar un soft switch del mismo proveedor que los switches de la red. La idea es que la coordinación será más sencilla puesto que el proveedor la ha diseñado y, siendo optimistas, ha pensado en proponer una coordinación sencilla. Cisco ofrece este enfoque con VMware.
La tercera solución es que todas las comunicaciones desde el servidor virtual sean enviadas al switch de la red. Esto simplificaría el switch del VM puesto que no habría necesidad de cumplir los parámetros, etiquetar paquetes o preocuparse por la seguridad. El switch de red ejecutaría todas estas funciones como si los servidores virtuales estuvieran conectados directamente a los servidores y este fuera el primer reenvío hacia la red.
El atractivo de este enfoque radica en que mantiene todos los proyectos bien desarrollados y restablece claramente las tareas asignadas a cada integrante del equipo. El problema es que la expansión en árbol no permite que un puerto reciba un paquete y lo envíe de vuelta al mismo puerto. La respuesta es eliminar la restricción de la expansión en árbol que impide que un mensaje sea devuelto al puerto que lo envió. 
Expansión en árbol y virtualización 
Otra consecuencia de la virtualización es la necesidad de asegurarse de que haya suficiente tasa de transferencia hacia y desde el servidor, y de que el paquete toma la mejor ruta hacia el data center. Como la cantidad de procesadores del servidor físico sigue aumentando, la cantidad de imágenes se incrementan y, en consecuencia, cada vez un mayor volumen de información debe entrar y salir del servidor. La primera respuesta es usar 10 Gigabit y, eventualmente, 40 o 100 Gigabit. Es una buena respuesta, pero puede resultar insuficiente dado que el data center necesita creer una latencia muy baja, una estructura sin bloqueo con diversas rutas. Usar ambos adaptadores conectados a diferentes switches permite varias rutas a lo largo del trayecto, lo cual ayuda a garantizar una baja latencia.
Una vez más el problema es la expansión en árbol. La solución es eliminar la expansión en árbol, permitiendo que se usen ambos adaptadores. La realidad es que la nueva generación de switches layer 2 en el data center se comportará más como los routers, implementado su propia versión de OSPF en layer 2.
Almacenamiento
La última razón por la que se necesitan los nuevos switches es el almacenamiento Fibre Channel. Los switches necesitan soportar la capacidad de correr tráfico de almacenamiento sobre Ethernet/IP, como NAS, ISCSI o FCoE. Además de agregar soporte para el protocolo FCoE, también harán falta para abandonar la expansión en árbol y habilitar un mejor ancho de banda interseccional. Por ejemplo, Fibre Channel requiere que ambos adaptadores del servidor estén activos y transportando tráfico, algo que el algoritmo de la expansión en árbol del switch no soporta. Actualmente, el protocolo FCoE aún no está terminado y los proveedores están implementando una versión de borrador. La buena noticia es que pronto debe estar terminado. 
La situación actual del mercado
¿Cómo nos afectarán los próximos cambios en el data center? El primer paso es determinar cuánto de nuestro tráfico necesita una latencia muy baja en este momento. Si bien tanto el cloud computing, como la migración de almacenamiento o una nueva aplicación de baja latencia -como las transacciones bursátiles algorítmicas- están aún en borrador, lo más aconsejable es comenzar desde ya a pasarse a la nueva arquitectura. La mayoría de empresas todavía no pertenecen a ese grupo pero probablemente lo harán en el 2010 o en el 2011, de manera que tienen tiempo para planificar una transformación organizada. 
La transformación también puede producirse en pasos. Por ejemplo, un primer paso sería migrar el almacenamiento Fibre Channel a la estructura IP y reducir inmediatamente la cantidad de adaptadores de cada servidor. Esto se puede lograr reemplazando solo la parte superior de la consola de switch. El tráfico de almacenamiento fluye a través de los adaptadores IP de los servidores y hacia la parte superior de la consola que, a su vez, envía el tráfico Fibre Channel directamente a la SAN.
No hace falta reemplazar el centro y el final de la consola de switch. La parte superior de la consola de switch acepta tener activos ambos adaptadores IP para el tráfico de almacenamiento con el requerimiento de un único adaptador activo de la expansión en árbol aplicado solamente al tráfico de almacenamiento. Brocade y Cisco ofrecen actualmente esta opción.
Si se necesita baja latencia, entonces hay que reemplazar todos los switches del data center. La mayoría de proveedores aún no ha implementado el rango completo de atributos que se requiere para soportar el entorno de switching que acabamos de describir. Para comprender en qué etapa se encuentra determinado proveedor, lo mejor es considerar en dos partes. La primera parte es si el switch puede brindar una muy baja latencia. Muchos proveedores, como Arista Networks, Brocade, Cisco, Extreme, Force 10 y Voltaire, tienen switches que lo hacen.
La segunda parte es saber si el proveedor puede enfrentar el problema de la expansión en árbol, así como brindar soporte para dos adaptadores y diferentes rutas con monitoreo congestionado. Como suele ocurrir, los proveedores están divididos entre esperar hasta que los estándares estén terminados antes de ofrecer una solución, u proponer desde ya una implementación basada en sus mejores proyecciones de lo que será el estándar. Cisco y Arista Networks empezaron tempranamente y ofrecen las soluciones más completas. Otros proveedores están esperando a que los estándares estén listos el año próximo antes de lanzar productos.
¿Cuál es el mejor plan si la baja latencia es un futuro requerimiento? Puesto que de todas maneras los switches de data center deberán ser reemplazados, lo mejor será reemplazarlos con switches que puedan soportar la transición a la nueva arquitectura y proveer una latencia muy baja. Esto significa que es muy importante comprender los planes del proveedor y los esquemas de migración que nos llevarán a la próxima generación de estructura unificada.
Robin Layland, Network World (US)