Com este pedaço mágico de script Cisco ACI, é possível configurar a rede rapidamente.
A fábrica de rede para data centers Cisco ACI existe há cinco anos, mas mal foi discutida no Habr, então decidi corrigir isso um pouco. Vou compartilhar minha experiência sobre o que é isso, quais são seus benefícios e onde estão as armadilhas.
O que é isso e de onde surgiu?
No momento do anúncio do ACI (Infrastructure Centric Infrastructure) em 2013, as abordagens tradicionais para redes de data centers estavam sendo desafiadas por concorrentes de três lados.
Por um lado, as soluções SDN de "primeira geração" baseadas em OpenFlow prometiam tornar as redes mais flexíveis e baratas simultaneamente. A ideia era transferir as decisões, tradicionalmente feitas pelo software proprietário dos switches, para um controlador central.
Esse controlador teria uma visão única de tudo o que acontece e, com base nisso, programaria os dispositivos de todos os switches em nível de regras de processamento de fluxos específicos.
Por outro lado, as soluções de rede em overlay permitiam implementar a conectividade desejada e políticas de segurança sem mudanças na rede física, construindo túneis de software entre hosts virtualizados. O exemplo mais conhecido dessa abordagem foi a solução da Nicira, que já havia sido adquirida pela VMWare por 1,26 bilhões de dólares e deu início ao atual VMWare NSX. Um pouco de picante na situação era que os co-fundadores da Nicira eram as mesmas pessoas que anteriormente estavam envolvidas na criação do OpenFlow, agora afirmando que para construir a fábrica de data centers, .
E, finalmente, os chips de comutação disponíveis no mercado (o que chamamos de merchant silicon) atingiram um nível de maturidade que os tornaram uma ameaça real para os fabricantes tradicionais de switches. Se antes cada fornecedor desenvolvia chips para seus próprios switches, com o passar do tempo, os chips de fabricantes terceiros, principalmente da Broadcom, começaram a reduzir a distância em termos de funcionalidades e, em relação ao custo/desempenho, superaram os chips dos próprios fornecedores. Portanto, muitos acreditavam que os dias dos switches com chips desenvolvidos internamente estavam contados.
O ACI tornou-se a "resposta assimétrica" da Cisco (mais especificamente, da empresa Insieme, que entrou em seu grupo, fundada por ex-funcionários) a tudo isso.
Qual é a diferença para o OpenFlow?
Do ponto de vista da distribuição de funções, o ACI é, na prática, o oposto do OpenFlow.
Na arquitetura OpenFlow, o controlador é responsável por escrever regras detalhadas (fluxos)
na hardware de todos os switches, ou seja, em uma grande rede, ele pode ser responsável pela manutenção e, o mais importante, pela alteração de dezenas de milhões de registros em centenas de pontos na rede, portanto, seu desempenho e confiabilidade em uma grande implementação tornam-se um gargalo.
No ACI, usa-se uma abordagem reversa: o controlador, claro, existe, mas os switches recebem dele políticas declarativas de alto nível, e sua renderização em detalhes de configurações específicas na hardware é realizada pelo próprio switch. O controlador pode ser reiniciado ou até mesmo desligado, e nada de ruim acontecerá à rede, exceto, é claro, a ausência no momento da capacidade de gerenciamento. Curiosamente, existem situações no ACI em que o OpenFlow ainda é utilizado, mas localmente dentro do host para programar o Open vSwitch.
O ACI é construído inteiramente sobre transporte de sobreposição baseado em VXLAN, mas inclui, dentro de uma única solução, o transporte IP subjacente. A Cisco chamou isso de 'sobreposição integrada'. O ponto de terminação das sobreposições no ACI é, na maioria dos casos, feito por switches de data center (fazendo isso na velocidade da conexão). Os hosts não precisam saber nada sobre o data center, encapsulações, etc., porém em alguns casos (digamos, para conectar hosts OpenStack) o tráfego VXLAN pode chegar a eles.
As sobreposições são utilizadas no ACI não apenas para garantir conectividade flexível através da rede de transporte, mas também para transmitir metainformações (que são utilizadas, por exemplo, para aplicar políticas de segurança).
Os chips da Broadcom já eram usados pela Cisco em switches da série Nexus 3000. Na família Nexus 9000, especificamente lançada para suportar o ACI, foi inicialmente implementado um modelo híbrido, chamado Merchant+. No switch, foram usados ao mesmo tempo o novo chip Broadcom Trident 2 e um chip complementar desenvolvido pela Cisco, que realizava toda a mágica do ACI. Isso aparentemente permitiu acelerar o lançamento do produto e reduzir o preço do switch para um nível próximo ao dos modelos que usam apenas o Trident 2. Essa abordagem foi suficiente para os primeiros dois a três anos de fornecimento do ACI. Durante esse tempo, a Cisco desenvolveu e lançou o próximo geração do Nexus 9000 com seus próprios chips, que oferecem maior desempenho e um conjunto de recursos, mas com o mesmo nível de preço. As especificações externas em termos de interação na fábrica permaneceram totalmente inalteradas. No entanto, por dentro, toda a estrutura mudou: algo como uma refatoração, mas para hardware.
Como funciona a arquitetura da Cisco ACI
No caso mais simples, o ACI é construído com uma topologia de rede Clos, ou, como é frequentemente chamado, Spine-Leaf. Pode haver de dois (ou um, se não nos preocuparmos com a tolerância a falhas) a seis switches de nível Spine. Portanto, quanto mais switches, maior a tolerância a falhas (menor perda de largura de banda e confiabilidade em caso de falha ou manutenção de um Spine) e a performance geral. Todas as conexões externas vão para os switches de nível Leaf: isso inclui servidores, interconexões com redes externas por L2 ou L3 e conexão com controladores APIC. No geral, com o ACI, não só a configuração, mas também a coleta de estatísticas, monitoramento de falhas e outros processos — tudo é feito através da interface dos controladores, que em implementações de tamanho normal são três.
Nunca é necessário conectar-se aos switches pela console, nem mesmo para iniciar a rede: o controlador descobre automaticamente os switches e forma a fábrica, incluindo as configurações de todos os protocolos de serviço. Por isso, é muito importante registrar os números de série do equipamento instalado durante a montagem, para depois não ficar adivinhando qual switch está em qual rack. Para solução de problemas, é possível conectar-se aos switches via SSH, onde as tradicionais show-commands da Cisco são reproduzidas cuidadosamente.
Dentro da fábrica, utiliza-se transporte IP, então não há Spanning Tree e outras atrocidades do passado: todas as conexões estão ativas, e a convergência em caso de falhas é muito rápida. O tráfego na fábrica é transmitido através de túneis baseados em VXLAN. Especificamente, a própria Cisco chama a encapsulação de iVXLAN, e se diferencia do VXLAN comum pelo uso de campos reservados no cabeçalho da rede para transmitir informações de controle, principalmente sobre a relação do tráfego com o grupo EPG. Isso permite implementar regras de interação entre grupos no hardware, utilizando seus números, assim como endereços são utilizados em listas de acesso habituais.
Os túneis permitem estender tanto segmentos L2 quanto L3 (ou seja, VRF) através do transporte IP interno. Nesse caso, o gateway padrão é distribuído. Isso significa que cada comutador lida com a roteabilidade do tráfego que entra na fábrica. Em termos de lógica de transmissão de tráfego, o ACI se assemelha a uma fábrica baseada em VXLAN/EVPN.
Se sim, quais são as diferenças? Em tudo o mais!
A primeira diferença que se encontra no ACI é como os servidores são conectados à rede. Em redes tradicionais, a conexão de servidores físicos e virtuais ocorre em VLANs, e a partir delas tudo o mais se desenvolve: conectividade, segurança, etc. No ACI, utiliza-se uma estrutura que a Cisco chama de EPG (End-point Group), da qual não se pode escapar. Pode-se equiparar isso a uma VLAN? Sim, mas nesse caso corre-se o risco de perder grande parte do que o ACI oferece.
Em relação à EPG, todas as regras de acesso são formuladas, e no ACI, por padrão, utiliza-se o princípio da "lista branca", ou seja, apenas o tráfego cujo encaminhamento é explicitamente permitido é autorizado. Isso significa que podemos criar grupos EPG "Web" e "MySQL" e definir uma regra que permita a interação entre eles apenas na porta 3306. Isso funcionará sem estar vinculado a endereços de rede, mesmo dentro da mesma sub-rede!
Temos clientes que escolheram o ACI exatamente devido a esse recurso, pois ele permite restringir acessos entre servidores (virtuais ou físicos - não importa) sem movê-los entre sub-redes, o que significa não alterar a endereçamento. Sim, sabemos, ninguém escreve isso manualmente endereços IP nas configurações de aplicativos, certo?
As regras de passagem de tráfego no ACI são chamadas de contratos. Em um contrato, um ou mais grupos ou níveis em um aplicativo em múltiplas camadas se tornam provedores de serviço (digamos, serviço de banco de dados), enquanto outros se tornam consumidores. O contrato pode apenas permitir o tráfego ou pode fazer algo mais elaborado, como direcionar para um firewall ou balanceador, além de alterar o valor do QoS.
Como os servidores entram nesses grupos? Se forem servidores físicos ou algo incluído em uma rede existente, na qual criamos um trunk VLAN, então para colocá-los em EPG, é necessário especificar a porta do switch e a VLAN utilizada. Como podemos ver, as VLANs aparecem onde são imprescindíveis.
Se os servidores forem máquinas virtuais, basta referenciar o ambiente de virtualização conectado, e então tudo acontecerá automaticamente: será criada um grupo de portas (falando em termos da VMWare) para conectar as VMs, as VLANs ou VXLANs necessárias serão atribuídas, e serão configuradas nas portas apropriadas dos switches, etc. Portanto, embora o ACI esteja construído em torno de uma rede física, para servidores virtuais, as conexões parecem muito mais simples do que para os físicos. O ACI já possui integração com VMWare e MS Hyper-V, bem como suporte para OpenStack e RedHat Virtualization. Desde um certo momento, também há suporte embutido para plataformas de contêiner: Kubernetes, OpenShift, Cloud Foundry, abrangendo a aplicação de políticas e monitoramento, permitindo que o administrador de rede veja imediatamente em quais hosts estão funcionando quais pods e em quais grupos eles foram alocados.
Além da inclusão em um ou outro grupo de portas, os servidores virtuais têm propriedades adicionais: nome, atributos, etc., que podem ser utilizados como critérios para sua transferência para outro grupo, por exemplo, ao renomear uma VM ou ao adicionar uma nova tag a ela. A Cisco chama isso de grupos de microsegmentação, embora, em essência, a própria estrutura com a possibilidade de criar vários segmentos de segurança na forma de EPG na mesma sub-rede também se configure como uma microsegmentação. Bem, o fornecedor que sabe.
Os EPGs são puramente construções lógicas, não vinculadas a comutadores ou servidores específicos, etc., então com eles e construções baseadas neles (aplicações e tenants), é possível fazer coisas que são difíceis de realizar em redes comuns, como clonar. Como resultado, é muito fácil criar um clone de um ambiente produtivo, para obter um ambiente de teste que seja garantidamente idêntico ao ambiente produtivo. Isso pode ser feito manualmente, mas é melhor (e mais simples) por meio de uma API.
A lógica de gerenciamento no ACI é completamente diferente do que você normalmente encontra
em redes tradicionais da mesma Cisco: a interface programática é primária, enquanto o GUI ou CLI são secundários, uma vez que operam através da mesma API. Portanto, quase todos que trabalham com ACI, após algum tempo, começam a se familiarizar com o modelo de objeto usado para gerenciamento e a automatizar algo de acordo com suas necessidades. É mais fácil fazer isso em Python: existem ferramentas prontas e convenientes para isso.
As armadilhas prometidas
O principal problema é que muitas coisas no ACI são feitas de forma diferente. Para começar a trabalhar corretamente com isso, é necessário reaprender. Isso é especialmente verdadeiro para as equipes de operações de rede em grandes clientes, onde os engenheiros lidam por anos com 'a configuração de VLANs' por meio de solicitações. O que agora é VLAN não é mais apenas uma VLAN, e para criar novas redes em hosts virtualizados, não é necessário criar VLANs manualmente, o que realmente 'desestabiliza' os profissionais de rede tradicionais e os força a se apegar a abordagens familiares. Vale mencionar que a Cisco tentou suavizar um pouco a transição e adicionou ao controlador uma CLI 'semelhante ao NXOS', permitindo a configuração a partir de uma interface parecida com os comutadores tradicionais. Mas ainda assim, para começar a usar o ACI de forma adequada, será preciso entender como ele funciona.
Em termos de custo, as redes ACI em grande e médio escala não diferem fundamentalmente das redes tradicionais com equipamentos Cisco, pois utilizam os mesmos switches (os Nexus 9000 podem operar tanto em ACI quanto em modo tradicional e tornaram-se a principal "mula de trabalho" para novos projetos de data center). No entanto, em data centers que utilizam a arquitetura Spine-Leaf com dois switches, a presença de controladores realmente faz a diferença. Recentemente, uma Mini ACI-fábrica foi introduzida, substituindo dois dos três controladores por máquinas virtuais. Isso ajuda a reduzir a diferença de custo, mas ela ainda persiste. Assim, para o cliente, a escolha é ditada pelo interesse nas funções de segurança, integração com virtualização, ponto único de controle e outros aspectos.
Fonte: habr.com
