Con esta maravillosa pieza de script de Cisco ACI, se puede configurar rápidamente la red.
La fábrica de red para centros de datos Cisco ACI existe desde hace cinco años, pero en Habr no se ha hablado mucho de ella, así que decidí corregir eso un poco. Compartiré mi experiencia sobre qué es, cuál es su utilidad y qué problemas puede tener.
¿Qué es y de dónde proviene?
En el momento del anuncio de ACI (Infraestructura Centrada en Aplicaciones) en 2013, enfoques tradicionales para redes de centros de datos enfrentaban competidores por tres flancos.
Por un lado, las soluciones SDN de 'primera generación' basadas en OpenFlow prometían hacer que las redes fueran más flexibles y económicas al mismo tiempo. La idea era trasladar la toma de decisiones, tradicionalmente realizada por software propietario de los conmutadores, a un controlador central.
Este controlador tendría una visión única de todo lo que ocurre y, a partir de eso, programaría el hardware de todos los switches a nivel de reglas para el procesamiento de flujos específicos.
Por otro lado, las soluciones de redes de superposición permitían implementar la conectividad y políticas de seguridad necesarias sin modificar la red física, creando túneles de software entre hosts virtualizados. Un ejemplo conocido de este enfoque fue la solución de Nicira, que en ese momento ya había sido adquirida por VMWare por 1.26 mil millones de dólares y dio origen al actual VMWare NSX. La situación se tornaba un poco pícara, ya que los cofundadores de Nicira eran las mismas personas que anteriormente estaban detrás de OpenFlow, quienes ahora decían que para construir una fábrica de centro de datos, .
Y, por último, los chips de conmutación disponibles en el mercado abierto (lo que se llama silicio comercial) alcanzaron un grado de madurez que los hizo una amenaza real para los fabricantes tradicionales de conmutadores. Si anteriormente cada proveedor desarrollaba sus propios chips para sus conmutadores, con el tiempo, los chips de terceros, principalmente de Broadcom, comenzaron a cerrar la brecha con los chips de los proveedores en funcionalidad, y en términos de relación calidad/precio los superaron. Por lo tanto, muchos consideraban que los días de los conmutadores con chips de desarrollo propio estaban contados.
ACI se convirtió en la "respuesta asimétrica" de Cisco (más precisamente, de la empresa Insieme, formada por sus ex empleados) a todo lo mencionado.
¿Cuál es la diferencia con OpenFlow?
Desde el punto de vista de la distribución de funciones, ACI es prácticamente lo opuesto a OpenFlow.
En la arquitectura OpenFlow, el controlador se encarga de escribir reglas detalladas (flujos) en el hardware de todos los conmutadores, lo que significa que, en una gran red, puede ser responsable del mantenimiento y, lo más importante, de la modificación de decenas de millones de registros en cientos de puntos en la red. Por lo tanto, su rendimiento y fiabilidad en una implementación a gran escala se convierten en un cuello de botella.
En ACI se utiliza un enfoque inverso: también hay un controlador, por supuesto, pero los conmutadores reciben de él políticas declarativas de alto nivel, y su renderizado en detalles de configuraciones específicas en el hardware lo realiza el propio conmutador. El controlador puede reiniciarse o incluso apagarse, y con la red no sucederá nada malo, excepto, por supuesto, la falta de la capacidad de gestión en ese momento. Es interesante que en ACI hay situaciones en las que OpenFlow todavía se utiliza, pero localmente dentro del host para programar Open vSwitch.
ACI está completamente construido sobre el transporte de superposición basado en VXLAN, pero al mismo tiempo incluye, dentro de una única solución, el transporte IP subyacente. Cisco denominó a esto "superposición integrada". Como punto de terminación de superposiciones en ACI, en la mayoría de los casos se utilizan los conmutadores del centro de datos (lo hacen a la velocidad del canal). Los hosts no tienen que saber nada sobre el centro de datos, la encapsulación, etc., sin embargo, en ciertos casos (digamos, para conectar hosts OpenStack), el tráfico VXLAN puede llegar a ellos.
Las superposiciones se utilizan en ACI no solo para garantizar una conectividad flexible a través de la red de transporte, sino también para transmitir metainformación (que se utiliza, por ejemplo, para aplicar políticas de seguridad).
Los overlays se utilizan en ACI no solo para proporcionar conectividad flexible a través de la red de transporte, sino también para transmitir metainformación (que se utiliza, por ejemplo, para aplicar políticas de seguridad).
Los chips de Broadcom ya se utilizaban anteriormente en los conmutadores de la serie Nexus 3000 de Cisco. En la familia Nexus 9000, lanzada específicamente para soportar ACI, se implementó inicialmente un modelo híbrido llamado Merchant+. En el conmutador se utilizaban simultáneamente un nuevo chip Broadcom Trident 2 y un chip complementario diseñado por Cisco, que ejecutaba toda la magia de ACI. Al parecer, esto permitió acelerar la salida del producto y reducir el precio del conmutador a un nivel cercano al de los modelos que utilizan únicamente el Trident 2. Este enfoque fue suficiente para los primeros dos o tres años de suministro de ACI. Durante ese tiempo, Cisco desarrolló y lanzó al mercado la siguiente generación del Nexus 9000, ya basada en sus propios chips con mayor rendimiento y un conjunto de funciones ampliado, pero al mismo nivel de precios. Las especificaciones externas en términos de interacción dentro de la fábrica se mantuvieron completamente. Sin embargo, el hardware interno cambió por completo: algo así como un refactorizado, pero para el hardware.
Cómo está estructurada la arquitectura de Cisco ACI
En el caso más simple, ACI se construye sobre una topología de red Clos, o, como también se dice a menudo, Spine-Leaf. Puede haber entre dos (o uno, si la tolerancia a fallos no es una preocupación) y seis conmutadores de nivel Spine. En consecuencia, cuántos más sean, mayor será la tolerancia a fallos (menor disminución de ancho de banda y fiabilidad en caso de fallo o mantenimiento de un Spine) y el rendimiento general. Todas las conexiones externas se realizan en los conmutadores de nivel Leaf: esto incluye los servidores, la conexión con redes externas a través de L2 o L3 y la conexión con controladores APIC. De hecho, con ACI, no solo la configuración, sino también la recopilación de estadísticas, la supervisión de fallos y otros aspectos se gestionan a través de la interfaz de los controladores, que en implementaciones de tamaño normal son tres.
No es necesario conectarse a los conmutadores a través de la consola, ni siquiera para iniciar la red: el controlador descubre por sí mismo los conmutadores y los integra en la infraestructura, incluyendo la configuración de todos los protocolos de servicio; por eso, es muy importante anotar los números de serie del equipo instalado durante el montaje, para no tener que adivinar qué conmutador se encuentra en qué rack. Para la resolución de problemas, si es necesario, se puede conectar a los conmutadores a través de SSH: en ellos se han reproducido cuidadosamente los comandos habituales de show de Cisco.
Dentro de la fábrica se utiliza transporte IP, por lo que no hay Spanning Tree ni otros horrores del pasado: todos los enlaces están activos, y la convergencia en caso de fallos es muy rápida. El tráfico en la fábrica se transmite a través de túneles basados en VXLAN. Más precisamente, Cisco llama a esta encapsulación iVXLAN, y se diferencia de VXLAN común en que los campos reservados en el encabezado de red se utilizan para transmitir información administrativa, principalmente sobre la relación del tráfico con el grupo EPG. Esto permite implementar reglas de interacción entre grupos en el hardware, utilizando sus números de la misma manera en que se utilizan las direcciones en listas de acceso comunes.
Los túneles permiten extender tanto segmentos L2 como L3 (es decir, VRF) a través del transporte IP interno. En este caso, la puerta de enlace por defecto es distribuida. Esto significa que cada conmutador se encarga de la ruta del tráfico entrante en la fábrica. En términos de lógica de transmisión de tráfico, ACI es similar a una fábrica basada en VXLAN/EVPN.
Si es así, ¿cuáles son las diferencias? ¡En todo lo demás!
La primera diferencia con la que te encuentras en ACI es cómo se conectan los servidores a la red. En redes tradicionales, la conexión de servidores físicos y virtuales se realiza a través de VLAN, de las cuales derivan el resto: conectividad, seguridad, etc. En ACI, sin embargo, se utiliza una construcción que Cisco llama EPG (Grupo de Puntos Finales), de la cual no se puede escapar. ¿Se puede equiparar a una VLAN? Sí, pero en este caso hay un riesgo de perder gran parte de lo que ofrece ACI.
Todas las reglas de acceso se formulan en relación con EPG, y en ACI por defecto se utiliza el principio de ‘lista blanca’, es decir, solo se permite el tráfico que ha sido explícitamente autorizado. Esto significa que podemos crear grupos EPG ‘Web’ y ‘MySQL’ y definir una regla que permita la interacción entre ellos solo a través del puerto 3306. ¡Esto funcionará sin vinculación a direcciones de red e incluso dentro de una misma subred!
Tenemos clientes que eligieron ACI precisamente por esta característica, ya que permite restringir accesos entre servidores (virtuales o físicos, no importa), sin moverlos entre subredes, y por lo tanto, sin tocar la direccionamiento. Sí, sabemos que nadie configura manualmente IP en las configuraciones de las aplicaciones, ¿verdad?
Las reglas de paso del tráfico en ACI se denominan contratos. En dicho contrato, uno o varios grupos o niveles en una aplicación de múltiples capas se convierten en proveedores de servicio (por ejemplo, servicio de base de datos), y otros, en consumidores. El contrato puede simplemente permitir el tráfico o hacer algo más complejo, como dirigirlo a un firewall o a un balanceador, así como cambiar el valor de QoS.
¿Cómo llegan los servidores a estos grupos? Si son servidores físicos o algo incluido en una red existente, donde hemos creado un tronco VLAN, necesitaríamos indicar el puerto del switch y la VLAN que se utiliza. Como podemos ver, las VLAN aparecen donde son imprescindibles.
Si se trata de máquinas virtuales, basta con referirse al entorno de virtualización conectado, y entonces todo sucederá automáticamente: se creará un grupo de puertos (hablando en términos de VMWare) para conectar las VM, se asignarán las VLAN o VXLAN necesarias, se registrarán en los puertos pertinentes de los switches, etc. Así que, aunque ACI está construido alrededor de una red física, las conexiones para servidores virtuales son mucho más simples que para físicos. ACI ya incluye integración con VMWare y MS Hyper-V, así como soporte para OpenStack y RedHat Virtualization. Desde cierto momento, también ha surgido soporte incorporado para plataformas de contenedores: Kubernetes, OpenShift, Cloud Foundry, tocando tanto la aplicación de políticas como la monitorización, es decir, el administrador de red puede ver de inmediato en qué hosts están funcionando qué pods y en qué grupos han quedado.
Además de la inclusión en un grupo de puertos, los servidores virtuales tienen propiedades adicionales: nombre, atributos, etc., que se pueden utilizar como criterios para su traslado a otro grupo, por ejemplo, al renombrar una VM o al obtener una etiqueta adicional. Cisco denomina a esto grupos de microsegmentación, aunque, en realidad, la propia estructura que permite crear múltiples segmentos de seguridad en forma de EPG en la misma subred también se puede considerar microsegmentación. Bueno, eso lo sabe el proveedor.
Los EPG son construcciones puramente lógicas, no vinculadas a conmutadores específicos, servidores, etc., por lo que se pueden realizar operaciones con ellos y con las construcciones basadas en ellos (aplicaciones y tenants) que son difíciles de hacer en redes convencionales, como la clonación. Como resultado, digamos que es muy fácil crear un clon de un entorno de producción para obtener un entorno de prueba que sea garantizado idéntico al de producción. Se puede hacer manualmente, pero es mejor (y más simple) a través de la API.
En general, la lógica de gestión en ACI es muy diferente de lo que normalmente se encuentra
en redes tradicionales de Cisco: la interfaz de programación es primordial, y la GUI o CLI son secundarias, ya que operan a través de la misma API. Por lo tanto, casi todos los que trabajan con ACI, después de un tiempo, comienzan a familiarizarse con el modelo de objetos utilizado para la gestión y a automatizar algo según sus necesidades. Es más fácil hacerlo desde Python: hay herramientas convenientes ya hechas para ello.
Las trampas prometidas
El principal problema es que muchas cosas en ACI están hechas de manera diferente. Para empezar a trabajar adecuadamente con ella, es necesario reeducarse. Esto es especialmente relevante para los equipos de operación de red en grandes clientes, donde los ingenieros llevan años "configurando VLANs" según solicitudes. Lo que ahora es VLAN ya no es solo eso, y para implementar nuevas redes en hosts virtualizados no es necesario crear VLANs manualmente, lo que deja perplejos a los antiguos profesionales de redes y los lleva a aferrarse a sus enfoques tradicionales. Cabe señalar que Cisco ha intentado suavizar un poco la situación y ha añadido un CLI "similar a NXOS" en el controlador, que permite la configuración desde una interfaz parecida a los conmutadores tradicionales. Pero aun así, para empezar a usar ACI correctamente, será necesario entender cómo funciona.
Desde el punto de vista del precio en grandes y medianas escalas, la red ACI de los equipos Cisco prácticamente no se diferencia de las redes tradicionales, ya que se utilizan los mismos conmutadores para su construcción (los Nexus 9000 pueden funcionar tanto en ACI como en modo tradicional y se han convertido en el caballo de batalla principal para nuevos proyectos de centros de datos). Sin embargo, en los centros de datos con dos conmutadores, la presencia de controladores y la arquitectura Spine-Leaf ciertamente se hacen notar. Recientemente se introdujo una Mini ACI-Fabric, donde dos de los tres controladores fueron reemplazados por máquinas virtuales. Esto ayuda a reducir la diferencia de costo, aunque esta sigue existiendo. Por lo tanto, la elección del cliente se determina por su interés en las funciones de seguridad, integración con la virtualización, punto único de gestión y más.
Fuente: habr.com
