Com esta parte mágica do script Cisco ACI, você pode configurar rapidamente sua rede.A fábrica de rede do data center Cisco ACI existe há cinco anos, mas nada foi dito sobre isso na Habr, então decidi corrigi-lo um pouco. Por experiência própria, vou contar a você o que é, o que é bom e onde é o rake.
O que é e de onde veio?
Na época do anúncio da ACI (Application Centric Infrastructure) em 2013, os concorrentes estavam atacando as abordagens tradicionais das redes de data center em três lados ao mesmo tempo.
Por um lado, as soluções SDN de “primeira geração” baseadas no OpenFlow prometiam tornar as redes mais flexíveis e baratas ao mesmo tempo. A idéia era tomar decisões, tradicionalmente executadas pelo software proprietário dos switches, no controlador central.
Esse controlador teria uma visão única de tudo o que estava acontecendo e, com base nisso, programaria o hardware de todos os comutadores no nível das regras para processar fluxos específicos.
Por outro lado, as soluções de rede de sobreposição tornaram possível implementar as políticas de conectividade e segurança necessárias sem nenhuma alteração na rede física, construindo túneis de software entre hosts virtualizados. O exemplo mais famoso dessa abordagem foi a decisão da Nicira, que já havia sido adquirida pela VMWare por US $ 1,26 bilhão e deu origem ao atual VMWare NSX. Para alguma observação da situação, Nicira foi cofundado pelas mesmas pessoas que estavam anteriormente nas origens do OpenFlow, agora dizendo que o
OpenFlow não é adequado para a construção de uma fábrica de data center.
E, finalmente, os chips de comutação disponíveis no mercado aberto (o que é chamado silício comercial) atingiram um grau de maturidade em que se tornaram uma ameaça real aos fabricantes tradicionais de comutadores. Anteriormente, cada fornecedor desenvolvia chips para seus comutadores, mas, com o tempo, os chips de fabricantes terceirizados, principalmente da Br®adcom, começaram a reduzir a distância com os chips dos fornecedores em termos de funções e em relação preço / desempenho que excederam. Portanto, muitos acreditavam que os dias de troca de chips de seu próprio design são numerados.
A ACI foi a "resposta assimétrica" da Cisco (ou melhor, a Insieme, fundada por seus ex-funcionários), a todas as opções acima.
Qual é a diferença com o OpenFlow?
Em termos de distribuição de funções, o ACI é realmente o oposto do OpenFlow.
Na arquitetura OpenFlow, o controlador é responsável por prescrever regras detalhadas (fluxos)
no hardware de todos os comutadores, ou seja, em uma rede grande, ele pode ser responsável por manter e, o mais importante, alterar dezenas de milhões de registros em centenas de pontos na rede; portanto, seu desempenho e confiabilidade na implementação em larga escala tornam-se um gargalo.
A ACI usa a abordagem oposta: é claro, também há um controlador, mas os comutadores recebem políticas declarativas de alto nível dele, e o próprio comutador os renderiza nos detalhes de configurações específicas no hardware. O controlador pode ser reiniciado ou desligado completamente e nada de ruim acontecerá à rede, exceto, é claro, a falta de controle no momento. Curiosamente, há situações no ACI em que o OpenFlow ainda é usado, mas localmente no host para programar o Open vSwitch.
O ACI é totalmente construído sobre o transporte de sobreposição baseado em VXLAN, mas ao mesmo tempo inclui o transporte IP subjacente como parte de uma única solução. A Cisco chamou isso de termo "sobreposição integrada". Como ponto de terminação para sobreposições na ACI, na maioria dos casos, os switches de fábrica são usados (eles fazem isso na velocidade do canal). Os hosts não precisam saber nada sobre a fábrica, encapsulamentos etc., no entanto, em alguns casos (por exemplo, para conectar hosts OpenStack), o tráfego VXLAN também pode ser trazido a eles.
As sobreposições são usadas na ACI não apenas para fornecer conectividade flexível através da rede de transporte, mas também para transmitir meta-informações (é usada, por exemplo, para aplicar políticas de segurança).
Os chips da Broadcom foram usados anteriormente pela Cisco na série de switches Nexus 3000. A família Nexus 9000, lançada especialmente para oferecer suporte à ACI, implementou inicialmente um modelo híbrido chamado Merchant +. O switch usou simultaneamente o novo chip Broadcom Trident 2 e o chip de desenvolvimento da Cisco que o complementa, realizando toda a magia da ACI. Aparentemente, isso tornou possível acelerar a saída do produto e reduzir o preço do switch para um nível próximo aos modelos apenas para o Trident 2. Essa abordagem foi suficiente nos primeiros dois a três anos de suprimentos da ACI. Durante esse período, a Cisco desenvolveu e lançou a próxima geração do Nexus 9000 em seus próprios chips, com mais desempenho e recursos, mas com o mesmo nível de preço. As especificações externas em termos de interação na fábrica são totalmente preservadas. Ao mesmo tempo, o preenchimento interno mudou completamente: algo como refatoração, mas para o ferro.
Como a arquitetura Cisco ACI funciona
No caso mais simples, o ACI é construído sobre a topologia da rede Clos ou, como costumam dizer, Spine-Leaf. Os comutadores no nível da coluna vertebral podem variar de dois (ou um, se não nos importamos com tolerância a falhas) a seis. Assim, quanto mais houver, maior será a tolerância a falhas (menos redução na largura de banda e confiabilidade no caso de um acidente ou manutenção de uma coluna) e o desempenho geral. Todas as conexões externas vão para comutadores de nível folha: estes são os servidores, conectando-se a redes externas via L2 ou L3 e conectando controladores APIC. Em geral, com o ACI, não apenas a configuração, mas também a coleta de estatísticas, o monitoramento de falhas e assim por diante - tudo é feito através da interface dos controladores, que são três em implementações de tamanho padrão.
Você não precisa se conectar aos comutadores com o console, nem mesmo para iniciar a rede: o próprio controlador detecta os comutadores e coleta a fábrica deles, incluindo as configurações de todos os protocolos de serviço; portanto, a propósito, é muito importante registrar os números de série do equipamento instalado durante a instalação, para que você não precise adivinhar qual comutador qual rack está localizado. Para solucionar problemas, você pode conectar-se aos switches via SSH, se necessário: eles usam os comandos habituais da Cisco show com bastante cuidado.
Por dentro, a fábrica usa transporte IP, portanto não há Spanning Tree e outros horrores do passado: todos os links estão envolvidos e a convergência em caso de falhas é muito rápida. O tráfego de fábrica é transmitido através de túneis VXLAN. Mais precisamente, a própria Cisco chama o encapsulamento iVXLAN e difere do VXLAN usual, pois os campos reservados no cabeçalho da rede são usados para transmitir informações gerais, principalmente sobre a relação de tráfego com o grupo EPG. Isso permite implementar as regras de interação entre grupos no equipamento, usando seus números da mesma maneira que os endereços são usados nas listas de acesso comuns.
Os túneis permitem que você se estenda pelo transporte IP interno e pelos segmentos L2 e L3 (ou seja, VRF). Nesse caso, o gateway padrão é distribuído. Isso significa que cada switch está envolvido no roteamento do tráfego que entra na fábrica. Em termos de lógica de transferência de tráfego, o ACI é semelhante a uma fábrica baseada em VXLAN / EVPN.
Se sim, quais são as diferenças? Para o resto!
A diferença número um que você encontra na ACI é como os servidores estão conectados à rede. Nas redes tradicionais, a inclusão de servidores físicos e máquinas virtuais vai para as VLANs, e tudo o mais dança delas: conectividade, segurança etc. A ACI usa um design que a Cisco chama de EPG (End-point Group), do qual não há lugar nenhum. para fugir. É possível equiparar a uma VLAN? Sim, mas neste caso há uma chance de perder a maior parte do que a ACI oferece.
Em relação ao EPG, todas as regras de acesso são formuladas e a ACI usa o princípio de "lista branca" por padrão, ou seja, somente o tráfego é permitido, cuja transmissão é explicitamente permitida. Ou seja, podemos criar grupos de EPG “Web” e “MySQL” e definir uma regra que permita a interação entre eles apenas na porta 3306. Isso funcionará sem referência aos endereços de rede e até dentro da mesma sub-rede!
Temos clientes que escolheram a ACI precisamente por causa desse recurso, pois ele permite restringir o acesso entre servidores (virtuais ou físicos - não importa) sem arrastá-los entre sub-redes e, portanto, sem tocar no endereçamento. Sim, sim, sabemos que ninguém prescreve endereços IP nas configurações de aplicativos com as mãos, certo?
As regras de tráfego da ACI são chamadas de contratos. Nesse contrato, um ou mais grupos ou níveis em um aplicativo de várias camadas tornam-se um provedor de serviços (por exemplo, um serviço de banco de dados), outros se tornam consumidores. Um contrato pode simplesmente pular o tráfego ou fazer algo mais complicado, por exemplo, direcioná-lo para um firewall ou um balanceador e também alterar o valor de QoS.
Como os servidores entram nesses grupos? Se forem servidores físicos ou algo conectado à rede existente na qual criamos o tronco da VLAN, para colocá-los no EPG, você precisará apontar para a porta do switch e a VLAN usada nela. Como você pode ver, as VLANs aparecem onde você não pode ficar sem elas.
Se os servidores forem máquinas virtuais, basta referir-se ao ambiente de virtualização conectado e tudo acontecerá por si só: um grupo de portas (em termos de VMWare) será criado para conectar a VM, as VLANs ou VXLANs necessárias serão atribuídas, elas serão registradas nas portas de switch necessárias etc. Portanto, embora o ACI seja construído em torno de uma rede física, as conexões para servidores virtuais parecem muito mais simples do que para os físicos. A ACI já possui um pacote com VMWare e MS Hyper-V, além de suporte para OpenStack e RedHat Virtualization. Em algum momento, o suporte interno para plataformas de contêiner apareceu: Kubernetes, OpenShift, Cloud Foundry e se aplica tanto à aplicação de políticas quanto ao monitoramento, ou seja, o administrador da rede pode ver imediatamente quais hosts funcionam em quais hosts e a quais grupos eles pertencem.
Além de serem incluídos em um grupo de portas específico, os servidores virtuais possuem propriedades adicionais: nome, atributos etc., que podem ser usados como critérios para transferi-los para outro grupo, por exemplo, ao renomear uma VM ou quando ela possui uma tag adicional. A Cisco chama esses grupos de microssegmentação, embora em geral o próprio design com a capacidade de criar muitos segmentos de segurança como o EPG na mesma sub-rede também seja microssegmentação. Bem, o fornecedor sabe melhor.
Os próprios EPGs são construções puramente lógicas que não estão vinculadas a comutadores, servidores, etc. específicos, de modo que, com eles e construções baseadas neles (aplicativos e inquilinos), você pode fazer coisas difíceis de executar em redes regulares, por exemplo, para clonar. Como resultado, digamos que é muito fácil criar um clone de um ambiente produtivo para obter um ambiente de teste que seja idêntico ao produtivo. Isso pode ser feito manualmente, mas melhor (e mais fácil) - através da API.
Em geral, a lógica de controle no ACI é completamente diferente do que você normalmente encontra
em redes tradicionais da mesma Cisco: a interface do software é primária e a GUI ou a CLI são secundárias, porque funcionam através da mesma API. Portanto, quase todo mundo que lida com a ACI, depois de um tempo, começa a navegar no modelo de objeto usado para controle e a automatizar algo para suas necessidades. A maneira mais fácil de fazer isso é no Python: existem ferramentas práticas prontas para isso.
Ancinho Prometido
O principal problema é que muitas coisas no ACI são feitas de maneira diferente. Para começar a trabalhar com ela normalmente, você precisa reaprender. Isso é especialmente verdadeiro para equipes de operação de rede em grandes clientes, onde os engenheiros estão envolvidos na “prescrição de VLANs” para aplicativos há anos. O fato de que agora as VLANs não são mais VLANs e, para colocar novas redes em hosts virtualizados, você não precisa criar VLANs com as mãos, "afasta completamente" os operadores de rede tradicionais e faz com que você se apegue às abordagens usuais. Deve-se notar que a Cisco tentou suavizar um pouco a pílula e adicionou uma CLI "semelhante a NXOS" ao controlador, o que permite configurar a partir de uma interface semelhante aos comutadores tradicionais. Mas ainda assim, para começar a usar o ACI normalmente, você precisará entender como ele funciona.
Do ponto de vista do preço em redes ACI de grande e médio porte, praticamente não difere das redes tradicionais nos equipamentos Cisco, porque os mesmos comutadores são usados para construí-las (o Nexus 9000 pode funcionar tanto na ACI quanto no modo tradicional, e agora o principal "cavalo de batalha" para novos projetos de data center). Mas para os datacenters de dois switches, a disponibilidade dos controladores e a arquitetura Spine-Leaf, é claro, se fazem sentir. Uma fábrica Mini ACI apareceu recentemente, na qual dois dos três controladores são substituídos por máquinas virtuais. Isso permite reduzir a diferença de custo, mas ainda permanece. Portanto, para o cliente, a escolha é ditada pelo quanto ele está interessado em funções de segurança, integração com virtualização, um único ponto de gerenciamento e muito mais.