Evalúe las conexiones en la parte media del esquema. Regresaremos a ellas más adelante.
En algún momento, puede que se enfrente a que las grandes y complejas redes basadas en L2 están irremediablemente enfermas. Primero, por problemas relacionados con el procesamiento del tráfico BUM y el funcionamiento del protocolo STP. En segundo lugar, por una arquitectura que en general ha quedado moralmente obsoleta. Esto provoca problemas desagradables en forma de tiempos de inactividad y dificultades en la gestión.
Tuvimos dos proyectos paralelos, donde los clientes evaluaron de manera objetiva todos los pros y contras de las opciones y eligieron dos soluciones de superred diferentes, y nosotros las implementamos.
Tuvimos la oportunidad de comparar precisamente la implementación. No la explotación, de eso hay que hablar dentro de dos o tres años.
Entonces, ¿qué es una fábrica de redes con redes superpuestas y SDN?
¿Qué hacer con los problemas acuciantes de la arquitectura clásica de red?
Cada año surgen nuevas tecnologías e ideas. En la práctica, la necesidad urgente de reconstruir redes no ha surgido durante bastante tiempo, porque también se puede hacer todo manualmente con los antiguos y buenos métodos tradicionales. ¿Y qué importa que estemos en el siglo veintiuno? Al final, el administrador debe trabajar, no quedarse sentado en su oficina.
Luego comenzó la fiebre de construcción de grandes centros de datos. Entonces quedó claro que se alcanzó el límite de desarrollo de la arquitectura clásica no solo en términos de funcionalidad, tolerancia a fallos y escalabilidad. Y una de las opciones para resolver estos desafíos fue la idea de construir redes superpuestas sobre un backbone enrutable.
Además, con el aumento de las escalas de las redes, surgió agudamente el problema de gestionar tales fábricas, lo que dio lugar a soluciones de redes definidas por software con la capacidad de gestionar toda la infraestructura de red como un todo. Y cuando la red se gestiona desde un único punto, es más fácil para otros componentes de la infraestructura de TI interactuar con ella, y tales procesos de interacción son más fáciles de automatizar.
Casi cada gran fabricante, no solo de equipos de red, sino también de virtualización, tiene en su cartera opciones de tales soluciones.
Solo queda averiguar qué se adapta a qué necesidades. Por ejemplo, para las grandes empresas que cuentan con un buen equipo de desarrolladores y operaciones, las soluciones empaquetadas de los proveedores no siempre satisfacen todas las necesidades, y recurren al desarrollo de sus propias soluciones SD (software defined). Por ejemplo, estos son los proveedores de la nube que constantemente amplían la gama de servicios ofrecidos a sus clientes, y las soluciones empaquetadas simplemente no pueden mantenerse al día con sus requerimientos.
Para las empresas medianas, la funcionalidad que ofrece el proveedor en forma de solución empaquetada es suficiente en el 99 por ciento de los casos.
¿Qué son las redes superpuestas?
¿En qué consiste la idea de las redes superpuestas? En esencia, tomas una red enrutada clásica y construyes otra red encima de ella para obtener más funciones. Frecuentemente se trata de una distribución eficiente de la carga en el equipo y en las líneas de comunicación, un aumento significativo del límite de escalabilidad, una mejor fiabilidad y un montón de ventajas en seguridad (gracias a la segmentación). Además, las soluciones SDN ofrecen la posibilidad de una administración muy, muy, muy flexible y hacen que la red sea más transparente para sus usuarios.
En general, si las redes locales se inventaran en los años 2010, no se parecerían en nada a lo que heredamos de los militares de los años 70.
Desde la perspectiva de las tecnologías para construir fábricas utilizando redes superpuestas, actualmente existen muchas implementaciones de fabricantes y proyectos de Internet RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve, y otros). Sí, existen estándares, pero la implementación de estos estándares por diferentes fabricantes puede variar, por lo que al crear tales fábricas, renunciar completamente a la dependencia del proveedor aún solo es posible en teoría sobre el papel.
La situación con la solución SD es aún más confusa, cada proveedor tiene su propia visión. Hay soluciones completamente abiertas que teóricamente puedes modificar tú mismo, y hay completamente cerradas.
Cisco ofrece su versión de SDN para centros de datos: ACI. Este es, por supuesto, un solución completamente específica del proveedor en términos de selección de hardware de red, pero se integra completamente con sistemas de virtualización, contenedorización, seguridad, orquestación, balanceadores de carga, y otros. Sin embargo, en esencia, sigue siendo una especie de caja negra, sin posibilidad de acceso total a todos los procesos internos. No todos los clientes aceptan esta opción, ya que dependes completamente de la calidad del código escrito de la solución y su implementación. Por otro lado, el fabricante cuenta con uno de los mejores soportes técnicos del mundo y tiene un equipo dedicado exclusivamente a esta solución. Para el primer proyecto, se eligió precisamente Cisco ACI.
Para el segundo proyecto, se eligió una solución de Juniper. El fabricante también tiene su propia SDN para centros de datos, pero el cliente decidió renunciar a la implementación de SDN. Como tecnología para construir la red, se eligió una fábrica EVPN VXLAN sin utilizar controladores centralizados.
¿Para qué se necesita?
La creación de una fábrica permite construir una red fácilmente escalable, tolerante a fallos y confiable. La arquitectura (leaf-spine) tiene en cuenta las características centros de procesamiento de datos (rutas de tráfico, minimización de latencias y cuellos de botella en la red). Las soluciones SD en los centros de datos permiten gestionar esta fábrica de manera conveniente, rápida y flexible, integrándola en el ecosistema del centro de datos.
Ambos clientes necesitaban construir centros de datos de respaldo para garantizar la tolerancia a fallos; además, el tráfico entre los centros de datos debía ser cifrado.
El primer cliente ya consideraba soluciones sin fábrica como posible estándar para sus redes, pero en las pruebas tuvieron problemas de compatibilidad con STP entre varios proveedores de hardware. Surgieron tiempos de inactividad que provocaron caídas de los servicios, lo cual era crítico para el cliente.
Cisco ya era el estándar corporativo del cliente, evaluaron ACI y otras opciones y decidieron que valía la pena optar por esta solución. Les gustó la automatización de la gestión con un solo botón a través de un controlador único. Los servicios se configuran más rápido y se gestionan con mayor eficiencia. Decidieron garantizar el cifrado del tráfico implementando MACSec entre los switches IPN y SPINE. De esta manera, lograron evitar un cuello de botella en forma de un dispositivo de cifrado, ahorrar en ellos y maximizar el ancho de banda.
El segundo cliente eligió una solución sin controlador de Juniper, ya que en su actual centro de datos ya había una pequeña instalación con la implementación de fábrica EVPN VXLAN. Pero allí no era redundante (se usaba un solo switch). Se decidió ampliar la infraestructura del centro de datos principal y construir una fábrica en un centro de datos de respaldo. El EVPN existente no se utilizó plenamente: la encapsulación VXLAN no se aplicó de hecho, ya que todos los hosts estaban conectados a un solo switch, y todas las direcciones MAC y /32 de los hosts eran locales, el gateway para ellos era el mismo switch, no había otros dispositivos donde se necesitara construir túneles VXLAN. Decidieron asegurar el cifrado del tráfico utilizando la tecnología IPSEC entre los firewalls (la capacidad de la MSS era suficiente).
También exploraron ACI, pero decidieron que debido al vendor-lock tendrían que comprar demasiado hardware, incluyendo reemplazar equipos nuevos que habían adquirido recientemente, y eso simplemente no tiene sentido económico. Sí, la fábrica de Cisco se integra con todo, pero dentro de la misma fábrica solo se pueden usar sus dispositivos.
Por otro lado, como se mencionó antes, la fábrica EVPN VXLAN no se puede mezclar simplemente con ningún vendedor vecino, porque las implementaciones del protocolo son diferentes. Es como cruzar Cisco y Huawei en la misma red: parece que los estándares son comunes, pero habrá que hacer malabares. Dado que es un banco y las pruebas de compatibilidad serían muy prolongadas, decidieron que era mejor adquirir los mismos equipos de un solo proveedor ahora y no dejarse llevar demasiado por funcionalidades más allá de lo básico.
Plan de migración
Dos centros de datos basados en ACI:
Organización de la interacción entre los centros de datos. Se eligió una solución Multi-Pod, donde cada centro de datos es un pod. Se han tenido en cuenta los requisitos de escalabilidad en el número de conmutadores y las latencias entre pods (RTT menor a 50 ms). Se decidió no construir una solución Multi-Site para facilitar la gestión (para la solución Multi-Pod se utiliza una única interfaz de gestión, mientras que para Multi-Site se requerirían dos interfaces, o un Orquestador Multi-Site), y dado que no era necesario un respaldo geográfico de los sitios.
Desde el punto de vista de la migración de servicios de la red Legacy, se eligió la opción más transparente, trasladando de manera gradual los VLAN correspondientes a determinados servicios.
Para la migración, a cada VLAN se le creó un EPG (grupo de puntos finales) correspondiente en la fábrica. Primero, la red se extendía entre la red antigua y la fábrica por L2, luego, tras la migración de todos los hosts, el gateway fue trasladado a la fábrica, y la interacción del EPG con la red existente se realizó a través de L3OUT, describiéndose la interacción entre L3OUT y EPG mediante contratos. Esquema aproximado:
Estructura aproximada de la mayoría de las políticas de la fábrica ACI en el diagrama a continuación. Toda la configuración se basa en políticas anidadas dentro de otras políticas, y así sucesivamente. Al principio es muy complicado entenderlo, pero, como muestra la práctica, los administradores de red se acostumbran a esta estructura en aproximadamente un mes, y luego se comprende cuán conveniente es.
Comparación
En la solución de Cisco ACI, se necesita comprar más equipo (conmutadores separados para la interacción Inter-Pod y controladores APIC), lo que resulta en un costo más alto. La solución de Juniper no requería la compra de controladores ni equipo adicional; se pudo utilizar parcialmente el equipo existente del cliente.
Esta es la arquitectura EVPN VXLAN de la fábrica para dos centros de datos del segundo proyecto:
En ACI obtienes una solución lista para usar: no necesitas modificar ni optimizar. Al presentar la fábrica al cliente por primera vez, no se requieren desarrolladores ni personal de soporte para el código y la automatización. Es suficiente con la explotación simple, muchas configuraciones se pueden hacer incluso a través de un asistente, lo cual no siempre es positivo, especialmente para personas acostumbradas a la línea de comandos. En cualquier caso, se necesita tiempo para ajustar la mente a nuevas formas, a la particularidad de las configuraciones a través de políticas y a la operación de múltiples políticas entrelazadas. Además, es muy recomendable tener una estructura clara para la nomenclatura de políticas y objetos. Ante cualquier problema en la lógica de funcionamiento del controlador, se puede resolver únicamente a través del soporte técnico.
En EVPN: la consola. Sufre o alégrate. Una interfaz familiar para la vieja guardia. Sí, hay configuraciones típicas y guías. Tendrás que estudiar los manuales. Diferentes configuraciones, todo claro y detallado.
Por supuesto, en ambos casos es mejor que al migrar, primero migres los servicios menos críticos, por ejemplo, entornos de prueba, y solo después, tras resolver todos los errores, proceder a la producción. Y no hacer configuraciones el viernes por la tarde. No debes confiar en el proveedor que todo estará bien, siempre es mejor tener una garantía adicional.
En ACI pagas más, aunque actualmente Cisco está promoviendo activamente esta solución y a menudo ofrece buenos descuentos, pero ahorras en el mantenimiento. La gestión y cualquier automatización de la fábrica EVPN sin controlador requieren inversiones y gastos regulares: monitorización, automatización, implementación de nuevos servicios. Además, el lanzamiento inicial en ACI toma un 30-40% más de tiempo. Esto ocurre porque se tarda más en crear todo el conjunto necesario de perfiles y políticas que luego se utilizarán. Pero a medida que la red crece, la cantidad de configuraciones necesarias disminuye. Utilizas políticas, perfiles y objetos ya creados con anterioridad. Puedes ajustar la segmentación y seguridad de forma flexible, gestionar de manera centralizada los contratos que rigen las interacciones entre EPG, reduciendo drásticamente la carga de trabajo.
En EVPN, es necesario configurar cada dispositivo en la fábrica, lo que incrementa la probabilidad de errores.
Si ACI se implementa más lentamente, entonces EVPN se depuró casi el doble de tiempo. En el caso de Cisco, siempre puedes llamar a un ingeniero de soporte y preguntar sobre la red en general (porque está cubierto como solución), pero en Juniper Networks compras solo el hardware, y eso es lo que está cubierto. ¿Los paquetes salieron del dispositivo? Bueno, está bien; sus problemas a partir de ahora. Pero puedes abrir una consulta sobre la elección de la solución o el diseño de la red, y entonces te recomendarán adquirir un servicio profesional, por un costo adicional.
El soporte de ACI es realmente genial, porque es separado: hay un equipo dedicado solo para esto. También hay especialistas que hablan ruso. La guía es detallada y las soluciones son predeterminadas. Observan y recomiendan. Validan rápidamente el diseño, lo cual es a menudo importante. Juniper Networks hace lo mismo, pero mucho más lento (así fue en nuestro caso, y ahora debería ser mejor, según rumores), lo que te obliga a hacer todo tú mismo donde podrías haber consultado a un ingeniero de soluciones.
Cisco ACI soporta la integración con sistemas de virtualización y contenedorización (VMware, Kubernetes, Hyper-V) y gestión centralizada. Hay servicios de red y de seguridad: balanceo, cortafuegos, WAF, IPS, y más... Buena microsegmentación lista para usar. En la segunda solución, la integración con los servicios de red se hace con muchas complicaciones, y es mejor investigar antes en los foros con aquellos que ya lo han hecho.
Summary
Para cada caso específico, es necesario seleccionar una solución, no solo basándose en el costo del equipo, sino también considerando los gastos adicionales en operación y los problemas principales que enfrenta actualmente el cliente, así como los planes de desarrollo de la infraestructura de TI.
ACI, debido a equipos adicionales, salió más caro, pero es una solución lista sin necesidad de ajustes, la segunda solución es más compleja y costosa en términos de operación, pero es más barata.
Si deseas discutir cuánto podría costar la implementación de una red de fabric en diferentes proveedores, y qué arquitectura se necesita, podemos reunirnos y conversar. Hasta un borrador preliminar de la arquitectura (con el que puedes considerar los presupuestos) te lo podemos sugerir gratis, el trabajo detallado, por supuesto, ya es de pago.
Vladimir Klepche, redes corporativas.
Fuente: habr.com
