Com a ajuda desta peça mágica do script Cisco ACI, você pode configurar uma rede rapidamente.
A fábrica de rede do data center Cisco ACI existe há cinco anos, mas Habré não falou nada sobre isso, então decidi consertar um pouco. Direi por experiência própria o que é, para que serve e onde tem ancinho.
O que é e de onde veio?
Quando a ACI (Application Centric Infrastructure) foi anunciada em 2013, os concorrentes estavam avançando em abordagens tradicionais para redes de data center de três lados ao mesmo tempo.
Por um lado, as soluções SDN de "primeira geração" baseadas em OpenFlow prometiam tornar as redes mais flexíveis e baratas ao mesmo tempo. A ideia era transferir a tomada de decisão tradicionalmente feita por um software de switch proprietário para um controlador central.
Este controlador teria uma visão única de tudo o que acontece e, com base nisso, programaria o hardware de todos os switches ao nível das regras de processamento de fluxos específicos.
Por outro lado, as soluções de rede overlay possibilitaram 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 conhecido dessa abordagem foi a Nicira, que até então já havia sido adquirida pela VMWare por US$ 1,26 bilhão e deu origem ao atual VMWare NSX. Alguma picância da situação foi adicionada pelo fato de que os co-fundadores da Nicira eram as mesmas pessoas que anteriormente estavam nas origens do OpenFlow, agora dizendo que para construir uma fábrica de data center .
E, finalmente, os chips de comutação disponíveis no mercado aberto (o que é chamado de silício comercial) atingiram um estágio de maturidade em que se tornaram uma ameaça real para os fabricantes tradicionais de comutadores. Se antes cada fornecedor desenvolvia chips de forma independente para seus switches, com o tempo, os chips de fabricantes terceirizados, principalmente da Broadcom, começaram a reduzir a distância com os chips dos fornecedores em termos de funções e os superaram em termos de relação preço / desempenho. Portanto, muitos acreditavam que os dias de interruptores em chips de seu próprio projeto estavam contados.
A ACI tornou-se a "resposta assimétrica" da Cisco (mais precisamente, sua empresa Insieme, fundada por seus ex-funcionários) a todos os itens acima.
Qual é a diferença com o OpenFlow?
Em termos de distribuição de funções, o ACI é na verdade o oposto do OpenFlow.
Na arquitetura OpenFlow, o controlador é responsável por escrever regras detalhadas (fluxos)
no hardware de todos os switches, ou seja, em uma grande rede, pode ser responsável por manter e, principalmente, alterar dezenas de milhões de registros em centenas de pontos da rede, de modo que seu desempenho e confiabilidade tornam-se um gargalo em uma grande implementação.
A ACI usa a abordagem inversa: claro, também há um controlador, mas os switches recebem dele políticas declarativas de alto nível, e o próprio switch executa sua renderização em detalhes de configurações específicas no hardware. O controlador pode ser reinicializado ou totalmente desligado, e nada de ruim acontecerá com a rede, exceto, é claro, a falta de controle neste momento. Curiosamente, existem situações no ACI em que o OpenFlow ainda é usado, mas localmente dentro do host para programação Open vSwitch.
A ACI é construída inteiramente em transporte de sobreposição baseado em VXLAN, mas 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 em ACI, na maioria dos casos, são usados switches de fábrica (eles fazem isso na velocidade do link). Os hosts não precisam saber nada sobre a fábrica, encapsulamento, etc., no entanto, em alguns casos (por exemplo, para conectar hosts OpenStack), o tráfego VXLAN pode ser levado a eles.
As sobreposições são usadas no ACI não apenas para fornecer conectividade flexível através da rede de transporte, mas também para transferir metainformações (é usado, por exemplo, para aplicar políticas de segurança).
Os chips da Broadcom foram usados anteriormente pela Cisco nos switches da série Nexus 3000. Na família Nexus 9000, lançada especialmente para oferecer suporte ao ACI, foi implementado originalmente um modelo híbrido, chamado Merchant +. O switch usava simultaneamente o novo chip Broadcom Trident 2 e um chip complementar desenvolvido pela Cisco, que implementa toda a magia do ACI. Aparentemente, isso permitiu acelerar o lançamento do produto e reduzir o preço do switch para um nível próximo aos modelos simplesmente baseados no Trident 2. Essa abordagem foi suficiente para os primeiros dois ou três anos de entrega do ACI. Durante esse tempo, a Cisco desenvolveu e lançou a próxima geração do Nexus 9000 em seus próprios chips com mais desempenho e conjunto de 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 hardware.
Como funciona a arquitetura Cisco ACI
No caso mais simples, o ACI é construído na topologia da rede Klose ou, como costumam dizer, Spine-Leaf. As chaves no nível da espinha podem ser de dois (ou um, se não nos importarmos com a tolerância a falhas) a seis. Assim, quanto mais deles, maior a tolerância a falhas (menor a redução de largura de banda e confiabilidade em caso de acidente ou manutenção de uma coluna) e o desempenho geral. Todas as conexões externas vão para switches de nível de folha: são servidores e se conectam a redes externas via L2 ou L3 e conectam controladores APIC. Em geral, com ACI, não apenas configuração, mas também coleta de estatísticas, monitoramento de falhas e assim por diante - tudo é feito por meio da interface de controladores, dos quais são três em implementações de tamanho padrão.
Você nunca precisa se conectar aos switches com o console, nem mesmo para iniciar a rede: o próprio controlador detecta os switches e monta uma fábrica a partir deles, incluindo as configurações de todos os protocolos de serviço, portanto, aliás, é muito importante anote os números de série do equipamento que está sendo instalado durante a instalação, para que posteriormente você não precise adivinhar qual switch está em qual rack está localizado. Para solucionar problemas, se necessário, você pode conectar-se aos switches via SSH: eles reproduzem os comandos usuais do Cisco show com bastante cuidado.
Internamente, a fábrica usa transporte IP, então 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 na malha é transmitido através de túneis baseados em VXLAN. Mais precisamente, a própria Cisco chama o encapsulamento iVXLAN, e difere do VXLAN regular porque os campos reservados no cabeçalho da rede são usados para transmitir informações de serviço, principalmente sobre o relacionamento do tráfego com o grupo EPG. Isso permite implementar as regras de interação entre os grupos no equipamento, usando seus números da mesma forma que os endereços são usados nas listas de acesso comuns.
Os túneis permitem que os segmentos L2 e L3 (ou seja, VRF) sejam estendidos através do transporte IP interno. Nesse caso, o gateway padrão é distribuído. Isso significa que cada switch é responsável por rotear o tráfego que entra na malha. Em termos de lógica de fluxo de tráfego, o ACI é semelhante a uma malha VXLAN/EVPN.
Se sim, quais são as diferenças? Todo o resto!
A principal diferença que você encontra com o ACI é como os servidores são conectados à rede. Nas redes tradicionais, a inclusão tanto de servidores físicos quanto de máquinas virtuais vai para as VLANs, e todo o resto dança a partir delas: conectividade, segurança etc. não há como fugir. Se é possível igualá-lo a VLAN? Sim, mas neste caso há uma chance de perder a maior parte do que o ACI oferece.
No que diz respeito ao EPG, todas as regras de acesso são formuladas, sendo que no ACI é utilizado por defeito o princípio da “lista branca”, ou seja, só é permitido o tráfego cuja passagem é expressamente permitida. Ou seja, podemos criar os grupos EPG "Web" e "MySQL" e definir uma regra que permita a comunicação entre eles apenas na porta 3306. Isso funcionará sem estar vinculado a endereços de rede e até mesmo dentro da mesma sub-rede!
Temos clientes que escolheram o ACI justamente por esse recurso, pois permite restringir o acesso entre servidores (virtuais ou físicos - não importa) sem arrastá-los entre sub-redes, ou seja, sem mexer no endereçamento. Sim, sim, sabemos que ninguém prescreve endereços IP nas configurações de aplicativos manualmente, certo?
As regras de tráfego no ACI são chamadas de contratos. Nesse contrato, um ou mais grupos ou níveis em um aplicativo multicamadas se tornam um provedor de serviços (digamos, um serviço de banco de dados), outros se tornam consumidores. O contrato pode simplesmente passar o tráfego ou pode fazer algo mais complicado, por exemplo, direcioná-lo para um firewall ou balanceador e também alterar o valor de QoS.
Como os servidores entram nesses grupos? Se forem servidores físicos ou algo incluído em uma rede existente na qual criamos um tronco 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: será criado um grupo de portas (em termos de VMWare) para conectar a VM, as VLANs ou VXLANs necessárias serão serão atribuídos, eles serão registrados 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 conectividade integrada com VMWare e MS Hyper-V, bem como suporte para OpenStack e RedHat Virtualization. A partir de algum momento, também apareceu o suporte integrado para plataformas de contêineres: Kubernetes, OpenShift, Cloud Foundry, embora diga respeito tanto à aplicação de políticas quanto ao monitoramento, ou seja, o administrador da rede pode ver imediatamente em quais hosts quais pods funcionam e em quais grupos eles se enquadram.
Além de estarem incluídos em um determinado grupo de portas, os servidores virtuais possuem propriedades adicionais: nome, atributos etc., que podem ser usados como critérios para transferi-los para outro grupo, digamos, quando uma VM é renomeada ou uma tag adicional aparece em isto. A Cisco chama isso de grupos de microssegmentação, embora, em geral, o próprio design com a capacidade de criar muitos segmentos de segurança na forma de EPGs na mesma sub-rede também seja uma microssegmentação. Bem, o vendedor sabe melhor.
Os próprios EPGs são construções puramente lógicas, não vinculadas a switches, servidores etc. específicos, portanto, você pode fazer coisas com eles e construções baseadas neles (aplicativos e inquilinos) que são difíceis de fazer em redes comuns, como a clonagem. Como resultado, digamos que seja muito fácil clonar um ambiente de produção para obter um ambiente de teste que seja idêntico ao ambiente de produção. Você pode fazer isso manualmente, mas é melhor (e mais fácil) por meio da API.
Em geral, a lógica de controle no ACI não é nada semelhante ao que você costuma encontrar
em redes tradicionais do mesmo Cisco: a interface do software é primária e a GUI ou CLI são secundárias, pois funcionam por meio da mesma API. Portanto, quase todos os envolvidos na ACI, depois de um tempo, começam a navegar no modelo de objeto usado para gerenciamento e automatizar algo para atender às suas necessidades. A maneira mais fácil de fazer isso é do Python: existem ferramentas convenientes 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 ele normalmente, você precisa treinar novamente. Isso é especialmente verdadeiro para equipes de operações de rede em grandes clientes, onde os engenheiros vêm “prescrevendo VLANs” há anos a pedido. O fato de que agora as VLANs não são mais VLANs, e você não precisa criar VLANs manualmente para estabelecer novas redes em hosts virtualizados, derruba completamente os networkers tradicionais e os faz aderir a abordagens familiares. Deve-se notar que a Cisco tentou adoçar um pouco a pílula e adicionou uma CLI “tipo NXOS” ao controlador, que permite fazer a configuração a partir de uma interface semelhante aos switches tradicionais. Mas ainda assim, para começar a usar o ACI normalmente, você precisa entender como ele funciona.
Em termos de preço, em grandes e médias escalas, as redes ACI na verdade não diferem das redes tradicionais em equipamentos Cisco, pois os mesmos switches são usados para construí-las (o Nexus 9000 pode funcionar em ACI e no modo tradicional e agora se tornou o principal "cavalo de batalha" para novos projetos de data center). Mas para data centers de dois switches, a presença de controladores e arquitetura Spine-Leaf, é claro, se faz sentir. Recentemente, surgiu uma fábrica Mini ACI, na qual dois dos três controladores são substituídos por máquinas virtuais. Isso reduz a diferença de custo, mas ainda permanece. Portanto, para o cliente, a escolha é ditada pelo quanto ele está interessado em recursos de segurança, integração com virtualização, um único ponto de controle e assim por diante.
Fonte: habr.com