Coa axuda desta peza máxica do script Cisco ACI, podes configurar rapidamente unha rede.
A fábrica de rede para o centro de datos Cisco ACI existe desde hai cinco anos, pero Habré non dixo nada sobre iso, así que decidín solucionalo un pouco. Vouche dicir pola miña propia experiencia o que é, para que serve e onde ten un anciño.
Que é e de onde veu?
Cando se anunciou ACI (Application Centric Infrastructure) en 2013, os competidores avanzaban nos enfoques tradicionais das redes de centros de datos desde tres lados á vez.
Por unha banda, as solucións SDN de "primeira xeración" baseadas en OpenFlow prometían facer as redes máis flexibles e máis baratas ao mesmo tempo. A idea era trasladar a toma de decisións que tradicionalmente facía un software de conmutación propietario a un controlador central.
Este controlador tería unha única visión de todo o que acontece e, en función diso, programaría o hardware de todos os interruptores a nivel de regras para procesar fluxos específicos.
Por outra banda, as solucións de rede superpostas permitiron implementar as políticas de conectividade e seguridade necesarias sen ningún cambio na rede física, construíndo túneles de software entre hosts virtualizados. O exemplo máis coñecido deste enfoque foi Nicira, que para entón xa fora adquirida por VMWare por 1,26 millóns de dólares e deu orixe ao actual VMWare NSX. Un pouco de picantes á situación engadiuse polo feito de que os cofundadores de Nicira eran as mesmas persoas que antes estaban nas orixes de OpenFlow, agora dicindo que para construír unha fábrica de centros de datos .
E, finalmente, os chips de cambio dispoñibles no mercado aberto (o que se chama silicio comercial) alcanzaron unha etapa de madurez onde se converteron nunha ameaza real para os fabricantes de interruptores tradicionais. Se antes cada vendedor desenvolveu chips de forma independente para os seus interruptores, co paso do tempo, os chips de fabricantes de terceiros, principalmente de Broadcom, comezaron a reducir a distancia cos chips de provedores en termos de funcións e superáronos en termos de relación prezo / rendemento. Polo tanto, moitos crían que os días dos interruptores dos chips de deseño propio estaban contados.
ACI converteuse na "resposta asimétrica" de Cisco (máis precisamente, a súa empresa Insieme, fundada polos seus antigos empregados) a todo o anterior.
Cal é a diferenza con OpenFlow?
En termos de distribución de funcións, ACI é en realidade o contrario de OpenFlow.
Na arquitectura OpenFlow, o controlador é responsable de escribir regras detalladas (fluxos)
no hardware de todos os conmutadores, é dicir, nunha rede grande, pode ser o responsable de manter e, o máis importante, cambiar decenas de millóns de rexistros en centos de puntos da rede, polo que o seu rendemento e fiabilidade convértense nun pescozo de botella nun gran implementación.
ACI usa o enfoque inverso: por suposto, tamén hai un controlador, pero os interruptores reciben políticas declarativas de alto nivel e o propio interruptor realiza a súa representación en detalles de configuracións específicas do hardware. O controlador pódese reiniciar ou apagar por completo, e nada malo pasará coa rede, excepto, por suposto, a falta de control neste momento. Curiosamente, hai situacións en ACI nas que aínda se usa OpenFlow, pero localmente dentro do host para a programación Open vSwitch.
ACI está construído enteiramente sobre o transporte de superposición baseado en VXLAN, pero inclúe o transporte IP subxacente como parte dunha única solución. Cisco chamou a isto o termo "superposición integrada". Como punto de terminación para as superposicións en ACI, na maioría dos casos utilízanse interruptores de fábrica (fan isto á velocidade da ligazón). Non se require que os anfitrións saiban nada sobre a fábrica, a encapsulación, etc., non obstante, nalgúns casos (por exemplo, para conectar os anfitrións de OpenStack), pódeselles achegar tráfico VXLAN.
As superposicións úsanse en ACI non só para proporcionar conectividade flexible a través da rede de transporte, senón tamén para transferir metainformación (utilízase, por exemplo, para aplicar políticas de seguridade).
Os chips de Broadcom eran utilizados anteriormente por Cisco nos conmutadores da serie Nexus 3000. Na familia Nexus 9000, lanzada especialmente para admitir ACI, implementouse orixinalmente un modelo híbrido, que se chamaba Merchant +. O switch utilizou simultaneamente tanto o novo chip Broadcom Trident 2 como un chip complementario desenvolvido por Cisco, que implementa toda a maxia de ACI. Ao parecer, isto permitiu acelerar o lanzamento do produto e reducir o prezo do cambio a un nivel próximo aos modelos baseados simplemente en Trident 2. Este enfoque foi suficiente para os primeiros dous ou tres anos de entrega de ACI. Durante este tempo, Cisco desenvolveu e lanzou a próxima xeración Nexus 9000 nos seus propios chips con máis rendemento e conxunto de funcións, pero ao mesmo nivel de prezo. As especificacións externas en canto á interacción na fábrica consérvanse por completo. Ao mesmo tempo, o recheo interno cambiou por completo: algo así como refactorización, pero para hardware.
Como funciona a arquitectura Cisco ACI
No caso máis sinxelo, ACI está construído sobre a topoloxía da rede Klose ou, como se adoita dicir, Spine-Leaf. Os interruptores de nivel da columna vertebral poden ser de dous (ou un, se non nos importa a tolerancia a fallos) a seis. En consecuencia, cantos máis deles, maior será a tolerancia a fallos (menos ancho de banda e a redución da fiabilidade en caso de accidente ou mantemento dunha columna vertebral) e o rendemento xeral. Todas as conexións externas van a conmutadores de nivel de folla: estes son servidores, e acoplamento con redes externas a través de L2 ou L3, e de conexión de controladores APIC. En xeral, con ACI, non só a configuración, senón tamén a recollida de estatísticas, o seguimento de fallos, etc., todo faise a través da interface de controladores, dos cales hai tres en implementacións de tamaño estándar.
Nunca tes que conectarte aos interruptores coa consola, nin sequera para iniciar a rede: o propio controlador detecta os interruptores e ensambla unha fábrica a partir deles, incluíndo a configuración de todos os protocolos de servizo, polo que, por certo, é moi importante anote os números de serie dos equipos que se instalan durante a instalación, para que despois non teñas que adiviñar que interruptor está en que rack está situado. Para a resolución de problemas, se é necesario, pode conectarse aos switches a través de SSH: reproducen os comandos show habituais de Cisco con bastante coidado.
Internamente, a fábrica usa o transporte IP, polo que non hai ningún Spanning Tree e outros horrores do pasado: todos os enlaces están implicados, e a converxencia en caso de fallos é moi rápida. O tráfico no tecido transmítese a través de túneles baseados en VXLAN. Máis precisamente, o propio Cisco chama a encapsulación iVXLAN, e difiere do VXLAN normal en que os campos reservados na cabeceira da rede úsanse para transmitir información de servizo, principalmente sobre a relación do tráfico co grupo EPG. Isto permítelle implementar as regras de interacción entre grupos dos equipos, utilizando os seus números do mesmo xeito que os enderezos se utilizan nas listas de acceso ordinarias.
Os túneles permiten estirar tanto os segmentos L2 como os segmentos L3 (é dicir, VRF) a través do transporte IP interno. Neste caso, a pasarela predeterminada distribúese. Isto significa que cada conmutador é responsable de enrutar o tráfico que entra no tecido. En termos de lóxica de fluxo de tráfico, ACI é semellante a un tecido VXLAN/EVPN.
Se é así, cales son as diferenzas? Todo o demáis!
A diferenza número un que atopas con ACI é como se conectan os servidores á rede. Nas redes tradicionais, a inclusión tanto de servidores físicos como de máquinas virtuais vai para as VLAN, e delas baila todo o demais: conectividade, seguridade, etc. En ACI utilízase un deseño que Cisco denomina EPG (End-point Group), dende o cal non hai onde escapar. Se é posible equiparalo a VLAN? Si, pero neste caso hai unha posibilidade de perder a maior parte do que dá ACI.
No que respecta á EPG, formúlanse todas as regras de acceso, e en ACI utilízase por defecto o principio da "lista branca", é dicir, só se permite o tráfico, cuxo paso está explícitamente permitido. É dicir, podemos crear os grupos EPG "Web" e "MySQL" e definir unha regra que permita a comunicación entre eles só no porto 3306. Isto funcionará sen estar ligado a enderezos de rede e mesmo dentro da mesma subrede!
Temos clientes que elixiron ACI precisamente por esta función, xa que permite restrinxir o acceso entre servidores (virtuais ou físicos -non importa) sen arrastralos entre as subredes, é dicir, sen tocar o direccionamento. Si, si, sabemos que ninguén prescribe os enderezos IP nas configuracións das aplicacións a man, non?
As regras de tráfico en ACI chámanse contratos. Neste contrato, un ou máis grupos ou niveis nunha aplicación multinivel convértense nun provedor de servizos (por exemplo, un servizo de base de datos), outros convértense en consumidores. O contrato pode simplemente pasar tráfico, ou pode facer algo máis complicado, por exemplo, dirixilo a un firewall ou equilibrador e tamén cambiar o valor de QoS.
Como entran os servidores a estes grupos? Se estes son servidores físicos ou algo incluído nunha rede existente na que creamos un tronco de VLAN, entón para colocalos no EPG, terás que apuntar ao porto de conmutación e á VLAN utilizada nel. Como podes ver, as VLAN aparecen onde non podes prescindir delas.
Se os servidores son máquinas virtuais, abonda con referirse ao contorno de virtualización conectado, e entón todo sucederá por si só: crearase un grupo de portos (en termos de VMWare) para conectar a máquina virtual, as VLAN ou VXLAN necesarias. Así, aínda que ACI está construído arredor dunha rede física, as conexións para servidores virtuais parecen moito máis sinxelas que para os físicos. ACI xa ten conectividade integrada con VMWare e MS Hyper-V, así como soporte para OpenStack e RedHat Virtualization. A partir dalgún momento, tamén apareceu soporte integrado para plataformas de contedores: Kubernetes, OpenShift, Cloud Foundry, aínda que se refire tanto á aplicación de políticas como á supervisión, é dicir, o administrador de rede pode ver de inmediato en que hosts funcionan e en que pods. en que grupos pertencen.
Ademais de estar incluídos nun determinado grupo de portos, os servidores virtuais teñen propiedades adicionais: nome, atributos, etc., que poden usarse como criterios para transferilos a outro grupo, por exemplo, cando se renome a unha máquina virtual ou aparece unha etiqueta adicional en iso. Cisco chama a isto grupos de microsegmentación, aínda que, en xeral, o propio deseño coa capacidade de crear moitos segmentos de seguridade en forma de EPG na mesma subrede tamén é microsegmentación. Ben, o vendedor sabe mellor.
Os propios EPG son construcións puramente lóxicas, non están vinculadas a conmutadores, servidores, etc. específicos, polo que podes facer cousas con elas e construcións baseadas nelas (aplicacións e inquilinos) que son difíciles de facer en redes comúns, como a clonación. Como resultado, digamos que é moi sinxelo clonar un ambiente de produción para conseguir un ambiente de proba que se garanta que é idéntico ao ambiente de produción. Podes facelo manualmente, pero é mellor (e máis fácil) a través da API.
En xeral, a lóxica de control en ACI non é nada semellante á que adoita atopar
nas redes tradicionais do mesmo Cisco: a interface do software é primaria e a GUI ou CLI son secundarias, xa que funcionan a través da mesma API. Polo tanto, case todos os implicados en ACI, despois dun tempo, comezan a navegar polo modelo de obxectos usado para a xestión e a automatizar algo para satisfacer as súas necesidades. A forma máis sinxela de facelo é desde Python: hai ferramentas preparadas para iso.
Rastrillo prometido
O principal problema é que moitas cousas en ACI fanse de forma diferente. Para comezar a traballar con el normalmente, cómpre reciclar. Isto é especialmente certo para os equipos de operacións de rede en grandes clientes, onde os enxeñeiros levan anos "prescribindo VLAN" baixo petición. O feito de que agora as VLAN xa non sexan VLAN e que non necesites crear VLAN a man para establecer novas redes en hosts virtualizados, fai que se aferren aos redes tradicionais e fai que se aferren a enfoques familiares. Cómpre sinalar que Cisco intentou endulzar un pouco a pílula e engadiu unha CLI "como a NXOS" ao controlador, o que lle permite facer a configuración desde unha interface similar aos interruptores tradicionais. Pero aínda así, para comezar a usar ACI normalmente, tes que entender como funciona.
En termos de prezo, a gran e mediana escala, as redes ACI non se diferencian das redes tradicionais dos equipos Cisco, xa que se usan os mesmos switches para construílos (o Nexus 9000 pode funcionar en ACI e en modo tradicional e converteuse agora no principal "caballo de batalla" para novos proxectos de centros de datos). Pero para os centros de datos de dous interruptores, a presenza de controladores e a arquitectura Spine-Leaf, por suposto, fanse sentir. Recentemente, apareceu unha fábrica Mini ACI, na que dous dos tres controladores son substituídos por máquinas virtuais. Isto reduce a diferenza de custo, pero aínda permanece. Polo tanto, para o cliente, a elección vén ditada polo moito que lle interesen as funcións de seguridade, a integración coa virtualización, un único punto de control, etc.
Fonte: www.habr.com