Con la ayuda de esta parte mágica del script Cisco ACI, puede configurar rápidamente una red.
La fábrica de redes para el centro de datos de Cisco ACI existe desde hace cinco años, pero Habré realmente no contó nada al respecto, así que decidí arreglarlo un poco. Te diré desde mi propia experiencia qué es, para qué sirve y dónde tiene un rastrillo.
¿Qué es y de dónde vino?
Cuando se anunció ACI (Infraestructura centrada en aplicaciones) en 2013, los competidores avanzaban en los enfoques tradicionales de las redes de centros de datos desde tres lados a la vez.
Por un lado, las soluciones SDN de "primera generación" basadas en OpenFlow prometían flexibilizar y abaratar las redes al mismo tiempo. La idea era trasladar la toma de decisiones que tradicionalmente realizaba el software propietario del conmutador a un controlador central.
Este controlador tendría una visión única de todo lo que sucede y, en base a esto, programaría el hardware de todos los interruptores a nivel de reglas para el procesamiento de flujos específicos.
Por otro lado, las soluciones de redes superpuestas permitieron implementar las políticas de conectividad y seguridad necesarias sin ningún cambio en la red física, construyendo túneles de software entre hosts virtualizados. El ejemplo más conocido de este enfoque fue Nicira, que para entonces ya había sido adquirida por VMWare por 1,26 millones de dólares y dio origen al actual VMWare NSX. Se añadió algo picante a la situación por el hecho de que los cofundadores de Nicira eran las mismas personas que anteriormente estuvieron en los orígenes de OpenFlow, y ahora dicen que para construir una fábrica de centros de datos .
Y, por último, los chips de conmutación disponibles en el mercado abierto (lo que se denomina silicio comercial) han alcanzado una etapa de madurez en la que se han convertido en una amenaza real para los fabricantes de conmutadores tradicionales. Si antes, cada proveedor desarrolló chips de forma independiente para sus conmutadores, con el tiempo, los chips de terceros, principalmente de Broadcom, comenzaron a reducir la distancia con los chips de proveedores en términos de funciones y los superaron en términos de relación precio / rendimiento. Por lo tanto, muchos creían que los días de los interruptores en chips de diseño propio estaban contados.
ACI se ha convertido en la "respuesta asimétrica" de Cisco (más precisamente, su empresa Insieme, fundada por sus ex 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 opuesto a OpenFlow.
En la arquitectura OpenFlow, el controlador es responsable de escribir reglas detalladas (flujos)
en el hardware de todos los switches, 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 de la red, por lo que su rendimiento y confiabilidad se convierten en un cuello de botella en un gran implementación.
ACI utiliza el enfoque inverso: por supuesto, también hay un controlador, pero los conmutadores reciben políticas declarativas de alto nivel de él, y el propio conmutador realiza su representación en 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 todavía se usa OpenFlow, pero localmente dentro del host para la programación de Open vSwitch.
ACI se basa completamente en el transporte superpuesto basado en VXLAN, pero incluye el transporte IP subyacente como parte de una única solución. Cisco llamó a esto el término "superposición integrada". Como punto de terminación para superposiciones en ACI, en la mayoría de los casos, se utilizan conmutadores de fábrica (lo hacen a la velocidad del enlace). No se requiere que los hosts sepan nada sobre la fábrica, la encapsulación, etc. Sin embargo, en algunos casos (por ejemplo, para conectar hosts OpenStack), se les puede llevar tráfico VXLAN.
Las superposiciones se utilizan en ACI no solo para proporcionar una conectividad flexible a través de la red de transporte, sino también para transferir metainformación (se utiliza, por ejemplo, para aplicar políticas de seguridad).
Cisco utilizó anteriormente chips de Broadcom en los conmutadores de la serie Nexus 3000. En la familia Nexus 9000, lanzada especialmente para admitir ACI, se implementó originalmente un modelo híbrido, que se denominó Merchant +. El conmutador utilizó simultáneamente el nuevo chip Broadcom Trident 2 y un chip complementario desarrollado por Cisco, que implementa toda la magia de ACI. Aparentemente, esto hizo posible acelerar el lanzamiento del producto y reducir el precio del interruptor a un nivel cercano a los modelos basados simplemente en Trident 2. Este enfoque fue suficiente para los primeros dos o tres años de entregas de ACI. Durante este tiempo, Cisco ha desarrollado y lanzado la próxima generación de Nexus 9000 en sus propios chips con más rendimiento y conjunto de funciones, pero al mismo nivel de precio. 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 una refactorización, pero de hierro.
Cómo funciona la arquitectura Cisco ACI
En el caso más simple, ACI se basa en la topología de la red Klose o, como suele decirse, 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, cuantos más, mayor será la tolerancia a fallas (menor será el ancho de banda y la reducción de la confiabilidad en caso de accidente o mantenimiento de un Spine) y el rendimiento general. Todas las conexiones externas van a conmutadores de nivel de hoja: estos son servidores y se conectan con redes externas a través de L2 o L3 y conectan 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, de los cuales hay tres en implementaciones de tamaño estándar.
Nunca es necesario conectarse a los conmutadores con la consola, incluso para iniciar la red: el controlador mismo detecta los conmutadores y ensambla una fábrica a partir de ellos, incluida la configuración de todos los protocolos de servicio, por lo tanto, por cierto, es muy importante anote los números de serie del equipo que se está instalando durante la instalación, para que luego no tenga que adivinar qué interruptor está en qué bastidor está ubicado. Para solucionar problemas, si es necesario, puede conectarse a los conmutadores a través de SSH: reproducen los comandos show habituales de Cisco con bastante cuidado.
Internamente, la fábrica usa transporte IP, por lo que no hay á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 en la estructura se transmite a través de túneles basados en VXLAN. Más precisamente, Cisco mismo llama encapsulación iVXLAN y se diferencia de la VXLAN normal en que los campos reservados en el encabezado de la red se usan para transmitir información de servicio, 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 se usan las direcciones en las listas de acceso ordinarias.
Los túneles permiten que tanto los segmentos L2 como los segmentos L3 (es decir, VRF) se extiendan a través del transporte IP interno. En este caso, se distribuye la puerta de enlace predeterminada. Esto significa que cada conmutador es responsable de enrutar el tráfico que ingresa a la estructura. En términos de lógica de flujo de tráfico, ACI es similar a una estructura VXLAN/EVPN.
Si es así ¿Cuáles son las diferencias? ¡Todo lo demas!
La principal diferencia que encuentra con ACI es cómo se conectan los servidores a la red. En las redes tradicionales la inclusión tanto de servidores físicos como de máquinas virtuales va a las VLAN, y de ellas baila todo lo demás: conectividad, seguridad, etc. En ACI se utiliza un diseño que Cisco denomina EPG (End-point Group), del cual no hay ningún lugar para escapar. ¿Si es posible equipararlo a VLAN? Sí, pero en este caso existe la posibilidad de perder la mayor parte de lo que da ACI.
Con respecto a EPG, se formulan todas las reglas de acceso, y en ACI, se utiliza por defecto el principio de "lista blanca", es decir, solo se permite el tráfico cuyo paso se permite explícitamente. Es decir, podemos crear los grupos EPG "Web" y "MySQL" y definir una regla que permita la comunicación entre ellos solo en el puerto 3306. ¡Esto funcionará sin estar atado a direcciones de red e incluso dentro de la misma subred!
Tenemos clientes que han elegido ACI precisamente por esta función, ya que te permite restringir el acceso entre servidores (virtuales o físicos, no importa) sin arrastrarlos entre subredes, es decir, sin tocar el direccionamiento. Sí, sí, sabemos que nadie prescribe a mano las direcciones IP en las configuraciones de las aplicaciones, ¿no?
Las reglas de tráfico en ACI se denominan contratos. En dicho contrato, uno o más grupos o niveles en una aplicación de varios niveles se convierten en proveedores de servicios (por ejemplo, un servicio de base de datos), otros se convierten en consumidores. El contrato puede simplemente pasar el tráfico, o puede hacer algo más complicado, por ejemplo, dirigirlo a un firewall o balanceador, 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 incluido en una red existente en la que creamos un enlace troncal 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, entonces basta con 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 crearán las VLAN o VXLAN necesarias. se asignarán, se registrarán en los puertos de conmutación necesarios, etc. Por lo tanto, aunque ACI se construye alrededor de una red física, las conexiones para los servidores virtuales parecen mucho más simples que para los físicos. ACI ya tiene conectividad integrada con VMWare y MS Hyper-V, así como soporte para OpenStack y RedHat Virtualization. A partir de algún momento, también apareció el soporte incorporado para plataformas de contenedores: Kubernetes, OpenShift, Cloud Foundry, mientras que se trata tanto de la aplicación de políticas como de la supervisión, es decir, el administrador de la red puede ver de inmediato en qué hosts funcionan qué pods y en qué grupos se encuentran.
Además de estar incluidos en un grupo de puertos en particular, los servidores virtuales tienen propiedades adicionales: nombre, atributos, etc., que pueden usarse como criterio para transferirlos a otro grupo, por ejemplo, cuando se cambia el nombre de una VM o aparece una etiqueta adicional en él. Cisco llama a esto grupos de microsegmentación, aunque, en general, el diseño en sí mismo con la capacidad de crear muchos segmentos de seguridad en forma de EPG en la misma subred también es una microsegmentación. Bueno, el vendedor sabe mejor.
Los EPG en sí mismos son construcciones puramente lógicas, no vinculadas a conmutadores, servidores, etc. específicos, por lo que puede hacer cosas con ellos y construcciones basadas en ellos (aplicaciones e inquilinos) que son difíciles de hacer en redes comunes, como la clonación. Como resultado, digamos que es muy fácil clonar un entorno de producción para obtener un entorno de prueba que garantice que es idéntico al entorno de producción. Puede hacerlo manualmente, pero es mejor (y más fácil) a través de la API.
En general, la lógica de control en ACI no es para nada similar a lo que normalmente se encuentra
en redes tradicionales del mismo Cisco: la interfaz del software es primaria, y la GUI o CLI son secundarias, ya que funcionan a través de la misma API. Por lo tanto, casi todos los involucrados en ACI, después de un tiempo, comienzan a navegar por el modelo de objetos utilizado para la administración y automatizan algo para satisfacer sus necesidades. La forma más fácil de hacer esto es desde Python: hay herramientas convenientes preparadas para ello.
Rastrillo prometido
El principal problema es que muchas cosas en ACI se hacen de manera diferente. Para comenzar a trabajar con él normalmente, necesita volver a entrenar. Esto es especialmente cierto para los equipos de operaciones de red en grandes clientes, donde los ingenieros han estado "prescribiendo VLAN" durante años a pedido. El hecho de que ahora las VLAN ya no sean VLAN, y no es necesario crear VLAN a mano para colocar nuevas redes en hosts virtualizados, hace volar completamente el techo a los usuarios de redes tradicionales y hace que se aferren a enfoques familiares. Cabe señalar que Cisco intentó endulzar un poco la píldora y agregó una CLI "similar a NXOS" al controlador, que le permite realizar la configuración desde una interfaz similar a los conmutadores tradicionales. Pero aún así, para comenzar a usar ACI normalmente, debe comprender cómo funciona.
En términos de precio, en escalas grandes y medianas, las redes ACI en realidad no difieren de las redes tradicionales en equipos Cisco, ya que se utilizan los mismos conmutadores para construirlas (Nexus 9000 puede funcionar en ACI y en modo tradicional y se han convertido ahora en los principales "caballo de batalla" para nuevos proyectos de centros de datos). Pero para los centros de datos de dos conmutadores, la presencia de controladores y la arquitectura Spine-Leaf, por supuesto, se hacen sentir. Recientemente ha aparecido una fábrica Mini ACI, en la que se sustituyen dos de los tres controladores por máquinas virtuales. Esto reduce la diferencia en el costo, pero aún permanece. Entonces, para el cliente, la elección está dictada por cuánto le interesan las funciones de seguridad, la integración con la virtualización, un único punto de control, etc.
Fuente: habr.com