Con esta pieza mágica del script Cisco ACI, puede configurar rápidamente su red.La fábrica de redes para el centro de datos Cisco ACI ha existido durante cinco años, pero en Habr no se dijo nada al respecto, así que decidí arreglarlo un poco. Te diré por experiencia propia lo que es, lo bueno que es y dónde tiene un rastrillo.
¿Qué es y de dónde vino?
En el momento del anuncio de ACI (Application Centric Infrastructure) en 2013, los competidores estaban atacando los enfoques tradicionales de las redes de centros de datos en tres lados a la vez.
Por un lado, las soluciones SDN de "primera generación" basadas en OpenFlow prometieron hacer las redes más flexibles y más baratas al mismo tiempo. La idea era tomar decisiones, tradicionalmente realizadas por el software propietario de los conmutadores, en el controlador central.
Este controlador tendría una visión única de todo lo que estaba sucediendo y, en base a esto, programaría el hardware de todos los conmutadores al nivel de las reglas para procesar flujos específicos.
Por otro lado, las soluciones de red superpuestas permitieron implementar las políticas de conectividad y seguridad necesarias sin ningún cambio en la red física, creando túneles de software entre hosts virtualizados. El ejemplo más famoso de este enfoque fue la decisión de Nicira, que en ese momento ya había sido adquirida por VMWare por $ 1.26 mil millones y dio lugar al actual VMWare NSX. Para un poco picante de la situación, Nicira fue cofundada por las mismas personas que anteriormente se encontraban en los orígenes de OpenFlow, y ahora dicen que
OpenFlow no es adecuado para construir una fábrica de centro de datos.
Y finalmente, los chips de conmutación disponibles en el mercado abierto (lo que se llama silicio comercial) han alcanzado un grado de madurez en el que se han convertido en una amenaza real para los fabricantes de conmutadores tradicionales. Anteriormente, cada proveedor mismo desarrollaba chips para sus conmutadores, pero con el tiempo, los chips de terceros fabricantes, principalmente de Br®adcom, comenzaron a reducir la distancia con los chips del vendedor en términos de funciones y en términos de relación precio / rendimiento que excedieron. Por lo tanto, muchos creían que los días de interruptores en chips de su propio diseño están contados.
ACI fue la "respuesta asimétrica" de Cisco (o más bien, Insieme, que fue fundada por sus antiguos empleados), a todo lo anterior.
¿Cuál es la diferencia con OpenFlow?
En términos de distribución de funciones, ACI es en realidad lo contrario de OpenFlow.
En la arquitectura OpenFlow, el controlador es responsable de prescribir reglas detalladas (flujos)
en el hardware de todos los conmutadores, es decir, en una red grande, puede ser responsable de mantener y, lo más importante, cambiar decenas de millones de registros en cientos de puntos en la red, por lo tanto, su rendimiento y confiabilidad en la implementación a gran escala se convierten en un cuello de botella.
ACI utiliza el enfoque opuesto: el controlador, por supuesto, también existe, pero los conmutadores reciben políticas declarativas de alto nivel, y el conmutador en sí mismo los representa en los detalles de configuraciones específicas en el hardware. El controlador se puede reiniciar o apagar por completo, y nada malo le sucederá a la red, excepto, por supuesto, la falta de control en este momento. Curiosamente, hay situaciones en ACI en las que OpenFlow todavía se usa, pero localmente dentro del host para programar Open vSwitch.
ACI se basa completamente en el transporte de superposición basado en VXLAN, pero al mismo tiempo incluye el transporte IP subyacente como parte de una solución única. Cisco llamó a esto el término "superposición integrada". Como punto de terminación para las superposiciones en ACI, en la mayoría de los casos se usan interruptores de fábrica (lo hacen a la velocidad del canal). No se requiere que los hosts sepan nada sobre la fábrica, las encapsulaciones, etc. Sin embargo, en algunos casos (por ejemplo, para conectar hosts OpenStack), el tráfico de VXLAN puede llegar a ellos.
Las superposiciones se usan en ACI no solo para proporcionar conectividad flexible a través de la red de transporte, sino también para transmitir metainformación (se usa, por ejemplo, para aplicar políticas de seguridad).
Los chips de Broadcom fueron utilizados previamente por Cisco en la serie de conmutadores Nexus 3000. La familia Nexus 9000, lanzada especialmente para admitir ACI, implementó inicialmente un modelo híbrido llamado Merchant +. El conmutador utilizó simultáneamente el nuevo chip Broadcom Trident 2 y el chip de desarrollo de Cisco que lo complementa, realizando toda la magia de ACI. Aparentemente, esto hizo posible acelerar la salida del producto y reducir el precio del interruptor a un nivel cercano a los modelos solo para Trident 2. Este enfoque fue suficiente para los primeros dos o tres años de suministros de ACI. Durante este tiempo, Cisco desarrolló y lanzó la próxima generación de Nexus 9000 en sus propios chips con más rendimiento y características, pero al mismo nivel de precios. Las especificaciones externas en términos de interacción en la fábrica se conservan por completo. Al mismo tiempo, el relleno interno ha cambiado por completo: algo así como la refactorización, pero para el hierro.
Cómo funciona la arquitectura Cisco ACI
En el caso más simple, ACI se basa en la topología de la red Clos o, como se suele decir, Spine-Leaf. Los interruptores de nivel de columna pueden ser de dos (o uno, si no nos importa la tolerancia a fallas) a seis. En consecuencia, cuanto más haya, mayor será la tolerancia a fallas (menos reducción en el ancho de banda y la confiabilidad en caso de accidente o mantenimiento de una columna vertebral) y el rendimiento general. Todas las conexiones externas van a conmutadores de nivel de hoja: estos son los servidores y se conectan a redes externas a través de L2 o L3, y conectan los controladores APIC. En general, con ACI, no solo la configuración, sino también la recopilación de estadísticas, el monitoreo de fallas, etc., todo se hace a través de la interfaz de los controladores, que son tres en implementaciones de tamaño estándar.
No es necesario que se conecte nunca a los conmutadores con la consola, ni siquiera para iniciar la red: el controlador en sí mismo detecta los conmutadores y recoge la fábrica de ellos, incluida la configuración de todos los protocolos de servicio, por lo tanto, es muy importante registrar los números de serie del equipo instalado durante la instalación para que no tenga que adivinar qué conmutador cuál estante está ubicado. Para solucionar problemas, puede conectarse a los conmutadores a través de SSH si es necesario: utilizan los comandos show habituales de Cisco con bastante cuidado.
En el interior, la fábrica utiliza el transporte IP, por lo que no hay ningún árbol de expansión y otros horrores del pasado: todos los enlaces están involucrados y la convergencia en caso de fallas es muy rápida. El tráfico de fábrica se transmite a través de túneles VXLAN. Más precisamente, Cisco mismo llama a la encapsulación iVXLAN, y difiere de la VXLAN habitual en que los campos reservados en el encabezado de la red se utilizan para transmitir información general, principalmente sobre la relación del tráfico con el grupo EPG. Esto le permite implementar las reglas de interacción entre grupos en el equipo, usando sus números de la misma manera que las direcciones se usan en las listas de acceso ordinarias.
Los túneles le permiten estirarse a través del transporte interno IP y los segmentos L2 y L3 (es decir, VRF). En este caso, se distribuye la puerta de enlace predeterminada. Esto significa que cada interruptor está involucrado en el enrutamiento del tráfico que ingresa a la fábrica. En términos de lógica de transferencia de tráfico, ACI es similar a una fábrica basada en VXLAN / EVPN.
Si es así, ¿cuáles son las diferencias? Por lo demás!
La diferencia número uno que encuentra en ACI es cómo se conectan los servidores a la red. En las redes tradicionales, la inclusión de servidores físicos y máquinas virtuales va a las VLAN, y todo lo demás se deriva de ellas: conectividad, seguridad, etc. El ACI utiliza un diseño que Cisco llama EPG (Grupo de punto final), del cual no hay ningún lugar para escapar ¿Es posible equipararlo a una VLAN? Sí, pero en este caso existe la posibilidad de perder la mayor parte de lo que ACI brinda.
Con respecto a EPG, todas las reglas de acceso están formuladas, y el ACI utiliza el principio de "lista blanca" de forma predeterminada, es decir, solo se permite el tráfico, cuya transmisión está explícitamente permitida. Es decir, podemos crear grupos EPG "Web" y "MySQL" y definir una regla que permita la interacción entre ellos solo en el puerto 3306. ¡Esto funcionará sin referencia a las direcciones de red e incluso dentro de la misma subred!
Tenemos clientes que eligieron ACI precisamente por esta característica, ya que le permite restringir el acceso entre servidores (virtuales o físicos, no importa) sin arrastrarlos entre subredes y, por lo tanto, sin tocar el direccionamiento. Sí, sí, sabemos que nadie prescribe direcciones IP en configuraciones de aplicaciones con sus manos, ¿verdad?
Las reglas de tráfico ACI se denominan contratos. En dicho contrato, uno o más grupos o niveles en una aplicación de varios niveles se convierten en un proveedor de servicios (por ejemplo, un servicio de base de datos), otros se convierten en consumidores. Un contrato puede simplemente omitir el tráfico, o puede hacer algo más complicado, por ejemplo, dirigirlo a un firewall o un equilibrador, y también cambiar el valor de QoS.
¿Cómo entran los servidores en estos grupos? Si se trata de servidores físicos o algo conectado a la red existente en la que creamos el enlace troncal de la VLAN, para colocarlos en la EPG deberá señalar el puerto del conmutador y la VLAN utilizada en él. Como puede ver, las VLAN aparecen donde no puede prescindir de ellas.
Si los servidores son máquinas virtuales, es suficiente referirse al entorno de virtualización conectado, y luego todo sucederá por sí solo: se creará un grupo de puertos (en términos de VMWare) para conectar la VM, se asignarán las VLAN o VXLAN necesarias, se registrarán en los puertos de conmutador necesarios, etc. e. Entonces, aunque ACI se construye alrededor de una red física, las conexiones para servidores virtuales parecen mucho más simples que las físicas. ACI ya tiene un paquete con VMWare y MS Hyper-V, así como soporte para OpenStack y RedHat Virtualization. En algún momento, también había soporte incorporado para plataformas de contenedores: Kubernetes, OpenShift, Cloud Foundry, y también se aplica a políticas y monitoreo, es decir, el administrador de la red puede ver de inmediato qué hosts funcionan y a qué grupos pertenecen.
Además de estar incluidos en un grupo de puertos en particular, los servidores virtuales tienen propiedades adicionales: nombre, atributos, etc., que se pueden usar como criterios para transferirlos a otro grupo, por ejemplo, al cambiar el nombre de una VM o cuando tiene una etiqueta adicional. Cisco llama a esto grupos de microsegmentación, aunque en general, el diseño en sí con la capacidad de crear muchos segmentos de seguridad como EPG en la misma subred también es microsegmentación. Bueno, el vendedor lo sabe mejor.
Las EPG en sí mismas son construcciones puramente lógicas que no están vinculadas a conmutadores, servidores, etc. específicos, de modo que con ellas y construcciones basadas en ellas (aplicaciones e inquilinos) puede hacer cosas que son difíciles de hacer en redes regulares, por ejemplo, clonar. Como resultado, digamos que es muy fácil crear un clon de un entorno productivo para obtener un entorno de prueba que sea idéntico al productivo. Se puede hacer manualmente, pero mejor (y más fácil) a través de la API.
En general, la lógica de control en ACI es completamente diferente de lo que normalmente encuentra
en redes tradicionales del mismo Cisco: la interfaz del software es primaria y la GUI o CLI son secundarias porque funcionan a través de la misma API. Por lo tanto, casi todos los que tratan con ACI, después de un tiempo, comienzan a navegar por el modelo de objeto utilizado para el control y a automatizar algo para sus necesidades. La forma más fácil de hacer esto es desde Python: hay herramientas convenientes listas para usar.
Rastrillo prometido
El principal problema es que muchas cosas en ACI se hacen de manera diferente. Para comenzar a trabajar con ella normalmente, debes volver a aprender. Esto es especialmente cierto para los equipos de operación de red en grandes clientes, donde los ingenieros se han dedicado a "prescribir VLAN" para aplicaciones durante años. El hecho de que ahora las VLAN ya no sean VLAN, y para colocar nuevas redes en hosts virtualizados, no es necesario crear VLAN con las manos, "destruye" completamente a los networkers tradicionales y lo obliga a aferrarse a enfoques familiares. Cabe señalar que Cisco intentó endulzar ligeramente la píldora y agregó una CLI "similar a NXOS" al controlador, que le permite configurar desde una interfaz similar a los conmutadores tradicionales. Pero aún así, para comenzar a usar ACI normalmente, deberá comprender cómo funciona.
Desde el punto de vista del precio en redes ACI grandes y medianas, prácticamente no es diferente de las redes tradicionales en los equipos Cisco, ya que se utilizan los mismos conmutadores para construirlos (Nexus 9000 puede funcionar tanto en ACI como en modo tradicional y ahora el "caballo de batalla" principal para proyectos de nuevos centros de datos). Pero para los centros de datos de dos conmutadores, la disponibilidad de controladores y la arquitectura de Spine-Leaf, por supuesto, se hacen sentir. Recientemente apareció una fábrica de Mini ACI, en la que dos de los tres controladores son reemplazados por máquinas virtuales. Esto le permite reducir la diferencia en el costo, pero aún permanece. Entonces, para el cliente, la elección depende de cuánto esté interesado en las funciones de seguridad, la integración con la virtualización, un único punto de administración y más.