Evalúe las conexiones en la parte media del diagrama. Volveremos sobre ellos a continuación.
En algún momento, es posible que descubra que las redes grandes y complejas basadas en L2 tienen enfermedades terminales. En primer lugar, los problemas asociados con el procesamiento del tráfico BUM y el funcionamiento del protocolo STP. En segundo lugar, la arquitectura es generalmente obsoleta. Esto provoca problemas desagradables en forma de tiempos de inactividad y un manejo incómodo.
Tuvimos dos proyectos paralelos, donde los clientes evaluaron con seriedad todos los pros y los contras de las opciones, eligieron dos soluciones de superposición diferentes y las implementamos.
Hubo una oportunidad de comparar la implementación. Explotación no; deberíamos hablar de ello dentro de dos o tres años.
Entonces, ¿qué es una estructura de red con redes superpuestas y SDN?
¿Qué hacer con los problemas acuciantes de la arquitectura de red clásica?
Cada año aparecen nuevas tecnologías e ideas. En la práctica, la urgente necesidad de reconstruir las redes no surgió hasta hace mucho tiempo, porque también es posible hacerlo todo a mano utilizando los métodos tradicionales. ¿Y qué si estamos en el siglo XXI? Después de todo, un administrador debería trabajar y no sentarse en su oficina.
Entonces comenzó un auge en la construcción de centros de datos a gran escala. Entonces quedó claro que se había alcanzado el límite de desarrollo de la arquitectura clásica, no sólo en términos de rendimiento, tolerancia a fallos y escalabilidad. Y una de las opciones para resolver estos problemas fue la idea de construir redes superpuestas sobre una red troncal enrutada.
Además, con el aumento de la escala de las redes, el problema de gestionar dichas fábricas se agudizó, como resultado de lo cual comenzaron a aparecer soluciones de red definidas por software con la capacidad de gestionar toda la infraestructura de la 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 dichos procesos de interacción son más fáciles de automatizar.
Casi todos los principales fabricantes no sólo de equipos de red, sino también de virtualización, tienen opciones para este tipo de soluciones en su cartera.
Todo lo que queda es descubrir qué es adecuado para qué necesidades. Por ejemplo, para empresas particularmente grandes con un buen equipo de desarrollo y operación, las soluciones empaquetadas de los proveedores no siempre satisfacen todas las necesidades y recurren al desarrollo de sus propias soluciones SD (definidas por software). Por ejemplo, se trata de proveedores de nube que amplían constantemente la gama de servicios que ofrecen a sus clientes y las soluciones empaquetadas simplemente no pueden satisfacer sus necesidades.
Para las medianas empresas, la funcionalidad que ofrece el proveedor en forma de solución en caja es suficiente en el 99 por ciento de los casos.
¿Qué son las redes superpuestas?
¿Cuál es la idea detrás de las redes superpuestas? Básicamente, se toma una red enrutada clásica y se construye otra red encima para obtener más funciones. La mayoría de las veces, estamos hablando de distribuir efectivamente la carga en equipos y líneas de comunicación, aumentar significativamente el límite de escalabilidad, aumentar la confiabilidad y un montón de ventajas de seguridad (debido a la segmentación). Y las soluciones SDN, además, brindan la oportunidad de una administración flexible muy, muy, muy conveniente y hacen que la red sea más transparente para sus consumidores.
En general, si las redes locales se hubieran inventado en la década de 2010, habrían tenido un aspecto muy diferente de lo que heredamos de los militares en la década de 1970.
En términos de tecnologías para construir estructuras utilizando redes superpuestas, actualmente existen muchas implementaciones de proveedores y proyectos RFC de Internet (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve y otros). Sí, existen estándares, pero la implementación de estos estándares por parte de diferentes fabricantes puede diferir, por lo que al crear dichas fábricas, aún es posible abandonar por completo el bloqueo del proveedor solo en teoría sobre el papel.
Con una solución SD, las cosas son aún más confusas: cada proveedor tiene su propia visión. Hay soluciones completamente abiertas que, en teoría, puedes completar tú mismo, y las hay completamente cerradas.
Cisco ofrece su versión de SDN para centros de datos: ACI. Naturalmente, esta es una solución 100% bloqueada por el proveedor en términos de elección de equipos de red, pero al mismo tiempo está completamente integrada con sistemas de virtualización, contenedorización, seguridad, orquestación, balanceadores de carga, etc. Pero, en esencia, sigue siendo una una especie de caja negra, sin posibilidad de acceso total a todos los procesos internos. No todos los clientes están de acuerdo con esta opción, ya que usted depende completamente de la calidad del código de solución escrito y su implementación, pero por otro lado, el fabricante tiene uno de los mejores soporte técnico del mundo y cuenta con un equipo dedicado dedicado únicamente a esta solución. Se eligió Cisco ACI como solución para el primer proyecto.
Para el segundo proyecto se eligió una solución de Juniper. El fabricante también tiene su propio SDN para el centro de datos, pero el cliente decidió no implementar SDN. Se eligió una estructura EVPN VXLAN sin el uso de controladores centralizados como tecnología de construcción de red.
Para qué sirve
La creación de una fábrica le permite construir una red confiable, fácilmente escalable y tolerante a fallas. La arquitectura (leaf-spine) tiene en cuenta las características de los centros de datos (rutas de tráfico, minimización de retrasos y cuellos de botella en la red). Las soluciones SD en los centros de datos le permiten gestionar de forma muy cómoda, rápida y flexible dicha fábrica e integrarla en el ecosistema del centro de datos.
Ambos clientes necesitaban construir centros de datos redundantes para garantizar la tolerancia a fallos y, además, el tráfico entre los centros de datos debía estar cifrado.
El primer cliente ya estaba considerando soluciones sin tejido como un posible estándar para sus redes, pero en las pruebas tuvo problemas con la compatibilidad STP entre varios proveedores de hardware. Hubo tiempos de inactividad que provocaron la caída de los servicios. Y para el cliente esto era fundamental.
Cisco ya era el estándar corporativo del cliente, examinaron ACI y otras opciones y decidieron que valía la pena adoptar esta solución. Me gustó la automatización del control desde un botón a través de un único controlador. Los servicios se configuran y administran más rápido. Decidimos garantizar el cifrado del tráfico ejecutando MACSec entre los conmutadores IPN y SPINE. De esta manera, logramos evitar el cuello de botella en forma de puerta de enlace criptográfica, ahorrar en ellos y utilizar el máximo ancho de banda.
El segundo cliente eligió una solución sin controlador de Juniper porque su centro de datos existente ya contaba con una pequeña instalación que implementaba una estructura EVPN VXLAN. Pero allí no era tolerante a fallos (se utilizó un interruptor). Decidimos ampliar la infraestructura del centro de datos principal y construir una fábrica en el centro de datos de respaldo. El EVPN existente no se utilizó por completo: la encapsulación VXLAN en realidad no se usó, ya que todos los hosts estaban conectados a un conmutador y todas las direcciones MAC y las direcciones de host /32 eran locales, la puerta de enlace para ellos era el mismo conmutador, no había otros dispositivos , donde fue necesario construir túneles VXLAN. Decidieron garantizar el cifrado del tráfico mediante tecnología IPSEC entre firewalls (el rendimiento del firewall era suficiente).
También probaron ACI, pero decidieron que debido al bloqueo del proveedor, tendrían que comprar demasiado hardware, incluido el reemplazo de equipos nuevos adquiridos recientemente, y simplemente no tenía sentido económico. Sí, la estructura de Cisco se integra con todo, pero solo sus dispositivos son posibles dentro de la propia estructura.
Por otro lado, como dijimos anteriormente, no se puede simplemente mezclar una estructura EVPN VXLAN con cualquier proveedor vecino, porque las implementaciones de protocolos son diferentes. Es como cruzar Cisco y Huawei en una red: parece que los estándares son comunes, pero tendrás que bailar con una pandereta. Como se trata de un banco y las pruebas de compatibilidad serían muy largas, decidimos que era mejor comprar ahora al mismo proveedor y no dejarnos llevar por funcionalidades más allá de las básicas.
Plan de migración
Dos centros de datos basados en ACI:
Organización de la interacción entre centros de datos. Se eligió la solución Multi-Pod: cada centro de datos es un pod. Se tienen en cuenta los requisitos de escalado por el número de conmutadores y retrasos entre pods (RTT inferior a 50 ms). Se decidió no crear una solución Multi-Site para facilitar la administración (una solución Multi-Pod utiliza una única interfaz de administración, una Multi-Site tendría dos interfaces o requeriría un Multi-Site Orchestrator) y, dado que no hay ubicación geográfica, Se requirió reserva de sitios.
Desde el punto de vista de la migración de servicios desde la red Legacy, se optó por la opción más transparente, transfiriendo gradualmente las VLAN correspondientes a determinados servicios.
Para la migración, se creó un EPG (grupo de puntos finales) correspondiente para cada VLAN en la fábrica. Primero, la red se estiró entre la red antigua y la estructura sobre L2, luego, después de que se migraron todos los hosts, la puerta de enlace se movió a la estructura y la EPG interactuó con la red existente a través de L3OUT, mientras que la interacción entre L3OUT y EPG se describió mediante contratos. Diagrama aproximado:
En la siguiente figura se muestra un ejemplo de estructura de la mayoría de las políticas de fábrica de ACI. Toda la configuración se basa en políticas anidadas dentro de otras políticas, etc. Al principio es muy difícil entenderlo, pero poco a poco, como muestra la práctica, los administradores de red se acostumbran a esta estructura en aproximadamente un mes y luego empiezan a comprender lo conveniente que es.
Comparación
En la solución Cisco ACI, es necesario comprar más equipos (conmutadores separados para la interacción Inter-Pod y controladores APIC), lo que la encarece. La solución de Juniper no requería la compra de controladores ni accesorios; Fue posible utilizar parcialmente el equipo existente del cliente.
Aquí está la arquitectura de estructura EVPN VXLAN para dos centros de datos del segundo proyecto:
Con ACI obtiene una solución lista para usar: no es necesario retocar ni optimizar. Durante el conocimiento inicial del cliente de la fábrica, no se necesitan desarrolladores ni personal de apoyo para el código y la automatización. Es bastante fácil de usar; muchas configuraciones se pueden realizar a través del asistente, lo que no siempre es una ventaja, especialmente para las personas acostumbradas a la línea de comandos. En cualquier caso, se necesita tiempo para reconstruir el cerebro sobre nuevas vías, a las peculiaridades de los entornos a través de políticas y operando con muchas políticas anidadas. Además de esto, es muy deseable tener una estructura clara para nombrar políticas y objetos. Si surge algún problema en la lógica del controlador, sólo podrá solucionarse a través del soporte técnico.
En EVPN - consola. Sufre o regocíjate. Una interfaz familiar para la vieja guardia. Sí, hay una configuración y guías estándar. Tendrás que fumar maná. Diferentes diseños, todo claro y detallado.
Naturalmente, en ambos casos, al migrar, es mejor no migrar primero los servicios más críticos, por ejemplo, los entornos de prueba, y solo entonces, después de detectar todos los errores, pasar a la producción. Y no sintonices el viernes por la noche. No debes confiar en que todo estará bien en el proveedor, siempre es mejor ir a lo seguro.
Paga más por ACI, aunque Cisco actualmente está promocionando activamente esta solución y, a menudo, ofrece buenos descuentos, pero ahorra en mantenimiento. La gestión y cualquier automatización de una fábrica EVPN sin controlador requiere inversiones y costes regulares: seguimiento, automatización e implementación de nuevos servicios. Al mismo tiempo, el lanzamiento inicial en ACI tarda entre un 30 y un 40 por ciento más. Esto sucede porque lleva más tiempo crear todo el conjunto de perfiles y políticas necesarios que luego se utilizarán. Pero a medida que la red crece, la cantidad de configuraciones requeridas disminuye. Utiliza políticas, perfiles y objetos creados previamente. Puede configurar de manera flexible la segmentación y la seguridad, administrar de manera centralizada los contratos que son responsables de permitir ciertas interacciones entre EPG: la cantidad de trabajo disminuye drásticamente.
En EVPN, es necesario configurar cada dispositivo en fábrica, la probabilidad de errores es mayor.
Si bien la implementación de ACI fue más lenta, la depuración de EVPN tardó casi el doble. Si en el caso de Cisco siempre puedes llamar a un ingeniero de soporte y preguntar sobre la red en su conjunto (porque está cubierta como solución), entonces desde Juniper Networks solo compras hardware, y eso es lo que está cubierta. ¿Han salido los paquetes del dispositivo? Bueno, está bien, entonces tus problemas. Pero puede abrir una pregunta sobre la elección de la solución o el diseño de la red y luego le aconsejarán que contrate un servicio profesional por una tarifa adicional.
El soporte de ACI es genial porque está separado: un equipo separado se sienta solo para esto. También hay especialistas de habla rusa. La guía es detallada, las soluciones están predeterminadas. Ellos miran y aconsejan. Validan rápidamente el diseño, lo que suele ser importante. Juniper Networks hace lo mismo, pero mucho más lento (teníamos esto, ahora debería ser mejor según los rumores), lo que te obliga a hacer todo tú mismo donde un ingeniero de soluciones pueda asesorarte.
Cisco ACI admite la integración con sistemas de virtualización y contenerización (VMware, Kubernetes, Hyper-V) y la gestión centralizada. Disponible con servicios de red y seguridad: equilibrio, firewalls, WAF, IPS, etc... Buena microsegmentación lista para usar. En la segunda solución, la integración con los servicios de red es muy sencilla y es mejor discutir los foros con antelación con quienes ya lo han hecho.
Total
Para cada caso específico, es necesario seleccionar una solución, no solo en función del costo del equipo, sino que también es necesario tener en cuenta los costos operativos adicionales y los principales problemas que enfrenta el cliente actualmente, y qué planes existen. son para el desarrollo de la infraestructura TI.
ACI, debido al equipo adicional, resultó más caro, pero la solución está lista para usar sin necesidad de acabados adicionales, la segunda solución es más compleja y costosa en términos de operación, pero más económica.
Si desea analizar cuánto podría costar implementar una estructura de red en diferentes proveedores y qué tipo de arquitectura se necesita, puede reunirse y charlar. Te asesoraremos gratuitamente hasta conseguir un boceto de la arquitectura (con el que podrás calcular presupuestos), la elaboración detallada, por supuesto, ya está pagada.
Vladimir Klepche, redes corporativas.
Fuente: habr.com