¿Está su Centro de Datos preparado para el futuro?

Bajo la perspectiva de las Soluciones de Datos (Networking), existen tres consideraciones clave que se deben tener en cuenta cuando se trata del futuro de los Data Centers: Network Fabric, Software Defined Networking (SDN) y Network Functions Virtualization (NFV). Con esta preparación, los cambios del universo de TI se abordarán de una mejor forma.

Network Fabric

Al inicio de las redes Ethernet, cuando el modelo de comunicaciones obedecía a una estructura “Cliente-Servidor”, florecieron varias topologías que finalmente resultaron en la muy conocida Topología de Árbol.   Ésta resultó muy apropiada cuando se agotaba la capacidad de puertos del switch modular para cubrir el tráfico entre el Mainframe y los usuarios quienes consultaban o accedían a la información desde la periferia.   Hoy día hay que hacerse la pregunta: ¿tiene mi red éste patrón de tráfico “Norte-Sur” (cliente-servidor)?

En la gran mayoría de los Data Center actuales la respuesta es no.   Es más, no solo el tráfico ha cambiado, llegando a ser hasta un 75% “Este-Oeste”, sino que además la topología heredada resulta ser ineficiente o incluso un obstáculo en sí mismas para el tráfico entre aplicaciones, entre servidores, o bien para las interacciones que se dan entre éstos para extraer/generar reportes requeridos por diferentes unidades del negocio.   Vivimos inmersos en la Virtualización y tenemos encima necesidades como el “Big Data”, que también afectará directa y fuertemente el comportamiento del tráfico de datos dentro del Data Center.   Como resultado lógico, la topología de la red debe cambiar para simplificar y dar eficiencia a la red; senda por la que algunos fabricantes han caminado durante años, mientras otros… otros apenas inician.

Hay diferentes maneras de formar el FABRIC: basados en SPB, basados TRILL o basados en comunicación propietaria. También hay diferentes soluciones según el tamaño del FABRIC: aproximaciones basadas en Stacking, MC-LAG, Chasis Virtual, L2-Fabric, L3-Fabric, SPINE&LEAF que son de las más comunes.   Para facilitar la comprensión, explicaremos acá una solución de FABRIC que se apega más fielmente en reproducir el switch modular.

El “NETWORK FABRIC” o Data Center de UNA sola capa, no es otra cosa que dispersar físicamente dentro del Data Center, los tres elementos/componentes básicos de un switch modular.   Esto también aplica en los casos donde el Data Center está disperso en uno o varios pisos, o bien en uno o varios edificios.    Dichos elementos básicos son:

 ELEMENTOS DEL SWITCH MODULAR MÓDULOS DEL NETWORK FABRIC
Tarjetas de red Nodos del FABRIC en forma de switches ToR.
Chasis o “back plane” Módulos de Interconexión por fibra (40/100 Gbps)
Procesadoras o “Routing Engine” Módulo Director que controla el tráfico entre nodos

Grafica de SW Modular vrs FABRIC Distribuido.png

SDN:   Software Defined Networking

Al igual que se siguen usando las topologías de red legadas y con menor eficiencia dentro del Data Center (Multi Capas o Topología de Árbol), también se siguen usando equipos de red “legados”, esto es, equipos cuyas arquitecturas internas son monolíticas (HW y SW son una sola pieza; si una falla, la otra también), los cuales no tienen separación entre el plano de datos (puertos entrada/salida) y el plano de control del equipo (inteligencia de la caja, cálculos de rutas, procesamiento puro).

En contraste, existen equipos con arquitecturas internas modulares (comerciales desde los 90s) que ofrecen estabilidad, aislamiento de fallas, redundancia.   El problema es que solo algunos fabricantes tienen separación de planos en el 100% de sus equipos.   Otros la ofrecen solo en algunos de sus equipos, con lo cual no es posible obtener una solución homogénea en toda la gama de opciones que esos fabricantes tienen, lo que afecta al usuario que se ve obligado a mezclar equipos “con” y “sin” separación de planos.

Ahora bien, ¿por qué es importante contar con equipos que tengan separación de planos de control y datos?   Veamos un ejemplo simple:

  • Si hay una falla en un equipo “monolítico”, vamos a decir que hay problemas con el proceso que maneja ICMP (o bien un ataque tipo DoS con un “ping of death”), lo que sucederá con dicho equipo es que “se pegará” y deberá ser reiniciado (apagar y enceder); el equipo no puede ser accedido ni por puerto de consola, ni por IP, ni por HTML… “SE CONGELÓ”.
  • Si se da el mismo fallo en un equipo de arquitectura modular, éste sí podrá accederse por otro protocolo, puerto de consola, serial, u otro medio.   La razón es que la modularidad del SW permite separar/aislar las fallas y además permite que el equipo de soporte técnico pueda re-iniciar únicamente el módulo de ICMP… o el de TCP… o los servicios L3 (de ruteo)… o el módulo de TELNET, etc.   ¡El equipo de red ya no es en sí mismo, un único punto de falla!    Es más, aún con la falla o colapso total del software del equipo, no se altera/afecta el procesamiento de paquetes, porque el plano de datos tiene una copia de las tablas de rutas que se calcularon en dicho plano de control: son “máquinas independientes” la que procesa el SW respecto de la que procesa paquetes (HW de los puertos de red).

SDN, para operar, parte del principio fundamental de que los equipos de red tienen separación de planos de control y de datos: el “cerebro” del equipo está desacoplado de los puertos de datos del equipo; son máquinas independientes.

SDN aprovecha precisamente esa independencia para mover el plano de control a un punto centralizado de la red, y agrega beneficios adicionales como es la “programabilidad” del plano de control de la red.    En palabras sencillas y simplificando, al usar un controlador de SDN se ofrece a las redes de datos un equivalente a lo que tenemos con la virtualización de servidores, esto es:

  • Automatización de tareas de programación/configuración de los equipos de red.
  • Reducción del “tiempo de implementación” de la red a minutos (vrs semanas como sucede hoy).
  • El personal de soporte ahora solo debe “Decir lo que quiere, no como configurarlo”.
  • La complejidad se traslada al fabricante del controlador, no al equipo de TI local.
  • SDN es Multi Marca (OpenFlow); el Data Center no queda atado a una única marca de equipos de red

 

NFV:   Network Functions Virtualization

NFV es una tendencia complementaria a SDN, y el concepto detrás de ello es virtualizar las “aplicaciones de la red” como una solución de “SW + Licencias”; libre de HW.   Tanto SDN, como NFV buscan simplificar la red y acelerar tiempos de implementación.    SDN nace en el Data Center mientras NFV nace en el mundo de los operadores de servicios, y es por lo anterior que fácilmente podríamos creer que NFV no aplica al mundo empresarial, cuando la verdad es que solo se trata de un tema de escalas.

La necesidad detrás de NFV es reducir los tiempos requeridos para la puesta en marcha de dichas aplicaciones de red, tiempos que están asociados al aprovisionamiento de HWs específicos/propietarios.   En contraste, la habilitación de servidores regulares es muy expedita y hasta casi podemos decir que la virutalización es una norma desde hace ya algún tiempo en muchos Data Center (a nivel de servidores).

Ahora bien, independientemente de si hablamos del ambiente Empresarial o “Carrier”, podremos ver los beneficios que ofrece NFV ante el escenario en el que debemos habilitar una nueva aplicación de red, como por ejemplo: Firewall, VPN, Soluciones de UTM, Controladores de APs, Telefonía IP, entre otras.   Si en lugar de usar HW propietario o específico, utilizamos servidores industriales de mercado, la implementación de dicha aplicación de red se reduce a virtualizar el servidor requerido y comprar el SW junto con el licenciamiento a implementar en el sitio: evitamos los tiempos de “transporte de cajas” y los procesos de “instalación física”: validar espacio en Rack, disponibilidad de alimentación eléctrica, validar capacidad de enfriamiento, nuevo cableado, etc.

Al final, las tendencias actuales tienen en común la reducción de la complejidad de la red, así como de los tiempos de implementación.   Cada una de estas tres tendencias ofrecen características que pueden representar una ventaja  competitiva para la empresa/institución.

Podría ser que se necesite considerar las tres en el diseño, o solo una de ellas, pero lo que sí es un hecho, es que estamos en una etapa de fuertes cambios en el universo de TI, con marcada evolución en la forma en que se diseñan, actúan y se manejan las redes de datos.

Es por lo anterior que las empresas no pueden darse el lujo de seguir diseñando el Data Center de forma tradicional; deben prepararse para el futuro y en ANIXTER podemos ayudarle con el diseño conceptual de manera holística incluyendo la infraestructura física, la infraestructura de red de datos, las soluciones de Power&Cooling, seguridad física y otros muchos sub-sistemas.   Busque a su representante ANIXTER, contáctenos y con gusto trabajaremos con usted para ayudarle, así como para darle más información y detalles respecto de los temas revisados en este artículo.

 Por José Leyva, Business Developer Data Solutions for DC, Anixter Inc. CALA Region