No coração da infraestrutura Cisco ACI (Application Centric Infrastructure), reside um componente essencial conhecido como APIC (Application Policy Infrastructure Controller). Este elemento-chave é implementado em um cluster que forma a espinha dorsal do gerenciamento de políticas e configuração da rede. Entre os elementos fundamentais dessa arquitetura, encontra-se o conceito crucial de "Database Sharding", uma prática que merece a atenção dos profissionais de TI para compreender plenamente o funcionamento dessa poderosa tecnologia.
Neste artigo, exploraremos a arquitetura do Cluster do Cisco APIC e a tecnologia de banco de dados inovadora que o impulsiona.
O Cluster do Cisco APIC:
O Cisco APIC opera em um cluster composto por, no mínimo, três controladores. A escalabilidade do cluster é diretamente proporcional às necessidades da implantação ACI e é dimensionada com base nos requisitos de taxa de transação. A beleza desse modelo reside na flexibilidade, onde qualquer controlador no cluster pode atender a qualquer usuário para qualquer operação. Além disso, a adição ou remoção de controladores pode ocorrer de maneira transparente, garantindo uma gestão dinâmica e adaptável. Os APICs formam um cluster e se comunicam entre si usando a rede fornecida por leaf e spine. Essa abordagem eficiente permite a sincronização contínua de políticas e configurações em todo o cluster, garantindo um ambiente coeso e integrado.
Figura 1
Para um ambiente de produção robusto, é imprescindível implantar um mínimo de três nós APIC redundantes, mas a escalabilidade é flexível, permitindo a expansão do cluster para até sete nós. Em ambientes de laboratório, é viável gerenciar a malha da ACI até mesmo com um único nó, desde que configurado adequadamente. A relação direta entre a quantidade de nós APIC e o número de switches gerenciados é crucial para alcançar o desempenho desejado na taxa de transação entre eles. Conforme as diretrizes gerais de escalabilidade da Cisco, as seguintes recomendações devem ser seguidas:
- Cluster de três nós: até 80 switches leaf.
- Cluster de quatro nós: até 200 switches leaf.
- Cluster de cinco ou seis nós: até 400 switches leaf.
- Cluster de sete nós: 400-500 switches leaf.
- Para implementações que exigem um número ainda maior de switches, é aconselhável considerar a implementação da arquitetura Multi-Site, utilizando vários clusters APIC.
A descoberta e agrupamento do APIC constituem um processo automatizado, fundamentado na configuração inicial consistente e nas informações do LLDP. Como ilustrado na Figura 2, um cluster da APIC, crucial para otimização de desempenho, emprega a técnica de dimensionamento horizontal do banco de dados denominada sharding. Um "shard" é, essencialmente, uma unidade de dados, um subconjunto de banco de dados, ou um grupo de linhas de banco de dados distribuídos pelos nós do cluster para permitir processamento paralelo e proteção de dados em casos de falha. Cada fragmento de banco de dados APIC possui exatamente três réplicas, distribuídas pelo cluster com base em layouts de fragmentos definidos para cada tamanho de cluster.
Os dados em si são posicionados nos fragmentos como resultado de uma função de hash. Um APIC assume o papel de mestre (ou líder do fragmento) em um fragmento específico e detém direitos de leitura e gravação para editá-lo; os outros dois são utilizados como réplicas de leitura. Quando um mestre fica inativo, os APICs remanescentes negociam entre si para determinar quem se tornará o novo mestre. Agora, podemos compreender a origem do quorum APIC. Somente os fragmentos que possuem pelo menos uma réplica de backup são graváveis, justificando a necessidade de no mínimo dois dos três APICs disponíveis para configurar a malha da ACI.
Figure 2 APIC sharding
Mas esteja ciente! Ao expandir o número de nós no cluster APIC para mais de três, é importante ressaltar que ainda manteremos três réplicas para cada fragmento. Portanto, mais nós não equivale necessariamente a mais confiabilidade e redundância. Cada APIC adicional contribui, principalmente, para uma maior escalabilidade e a capacidade de gerenciar um maior número de switches na malha.
Vamos analisar um cenário com um cluster APIC maior, composto por cinco nós, durante uma eventual falha. Se perdermos dois nós, tecnicamente ainda manteremos um quórum. No entanto, observe a Figura 3. Com esse layout de fragmentos, alguns ficarão em estado somente de leitura, enquanto outros ainda poderão ser gravados. Recomenda-se fortemente evitar quaisquer alterações nessa situação e priorizar a restauração do cluster o mais rápido possível. Se mais de dois nós forem perdidos, há uma alta probabilidade de que algumas informações sejam irreversivelmente perdidas.
Figure 3 APIC Three+ node cluster failure
Seu objetivo deve ser sempre distribuir os APICs pela estrutura da ACI de modo a garantir sua proteção contra falhas de mais de dois nós por vez. de mais de dois nós ao mesmo tempo. É claro que, dentro de uma única malha, você não tem muito espaço de manobra. Nesse caso, tente distribuir os nós os nós APIC em diferentes racks (ou fileiras) e conecte cada um deles a tomadas elétricas independentes.
Na arquitetura Multi-Pod, é recomendável conectar dois APICs no Pod 1 e o terceiro APIC em um dos outros Pods. Em situações adversas, existe a possibilidade de perder dois nós, o que resultaria na ausência de um quorum e em uma malha ACI operando apenas em modo de leitura. Para contornar esse desafio, há uma alternativa que envolve a preparação e implantação antecipada de um APIC em espera, conforme ilustrado na Figura 4. Este dispositivo de hardware é idêntico ao principal em termos de configuração inicial, sendo instruído a não formar um cluster com outros APICs. Em vez disso, permanece em segundo plano, pronto para entrar em ação em caso de falha. Enquanto estiver em modo de espera, o APIC não replica dados nem participa de operações da ACI.
Entretanto, o cluster principal está ciente da presença do APIC em espera e permite a substituição de qualquer nó com falha por ele, quando necessário. O APIC ativo replica seu banco de dados para o APIC em espera, restabelecendo um cluster de leitura e gravação para garantir a continuidade do quorum.
Figure 4 Multi-Pod Standby APIC node
Se você planeja implantar entre 80 e 200 leaves no ambiente Multi-Pod, o melhor desempenho e a melhor redundância podem ser obtidos com o uso de quatro clusters de quatro nós, distribuídos o máximo possível em torno dos pods. Em um projeto com apenas dois pods, coloque um APIC de espera adicional em cada pod.
Para um cluster de cinco nós no MultiPOD, consulte a distribuição recomendada mostrada na Tabela 5.
Tabela 5 Five-Node APIC Cluster in ACI Multi-Pod
*Nota: Quando você perde completamente alguns shards durante a interrupção do POD1, ainda há uma chance de recuperação de dados usando um procedimento chamado ID Recovery. Ele usa instantâneos de configuração e deve ser executado pela unidade de negócios ou pelo suporte técnico da Cisco.
Para uma implantação de ACI altamente dimensionada que consiste em mais de 400 switches, uma distribuição de cluster APIC de sete nós se deveria implementar conforme mostrado na Tabela 6. O especialista, ao analisar essa abordagem, não implementaria esse número de switches e APICs em apenas dois pods. Você acabaria com quatro nós no primeiro pod e, em caso de falha, não há garantia de que a configuração possa ser recuperada. Para mim, um mínimo seguro seria pelo menos quatro pods.
Tabela 6 Seven-Node APIC Cluster in ACI Multi-Pod
*Nota: o mesmo procedimento de recuperação de ID também é aplicável aqui
O APIC como um Banco de Dados:
Cada serviço da ACI é organizado e armazenado como parte de um banco de dados. Esses serviços são encapsulados em fragmentos, sendo que cada fragmento é replicado três vezes para garantir alta disponibilidade. Para cada fragmento, há um líder e dois seguidores, contribuindo para uma arquitetura robusta e tolerante a falhas.
O estado do cluster do APIC deve permanecer sempre "Fully Fit", indicando a integridade de todos os APICs, conforme ilustrado na figura 2. Se o status de integridade de um ou mais controladores APIC no cluster não estiver completamente adequado, como "Camada de Dados Parcialmente Divergente", pode haver problemas na comunicação da infraestrutura do APIC ou nos processos do APIC. Nesse caso, é recomendável evitar qualquer modificação na configuração até que o problema seja devidamente diagnosticado e resolvido.
Ao administrar o cluster de APICs da Cisco, diversas tarefas podem ser realizadas, cada uma exigindo um procedimento específico:
- Expansão do tamanho do cluster APIC:
- Operação que aumenta o número configurado de APICs no cluster, passando de um tamanho N para N+1, dentro dos limites legais.
- Durante a expansão, a descoberta e a ampliação ocorrem sequencialmente com base nos números de ID do APIC. Inicialmente, o APIC1 é expandido, seguido por APIC2, APIC3, e assim por diante.
- Redução do tamanho do cluster APIC:
- Operação que diminui o número configurado de APICs, passando de um tamanho N para N-1, dentro dos limites legais.
- Durante a contração, é necessário desativar o último APIC do cluster primeiro, seguindo o caminho sequencial inverso. Inicia-se com o desligamento do APIC4 (se for a última ID de APIC), seguido por APIC3, APIC2 e, finalmente, APIC1.
- Substituição de um APIC no cluster:
- Desative o APIC que deseja substituir e comissione o APIC de substituição utilizando a mesma configuração e imagem do APIC que está sendo substituído.
- Preparação de um APIC em espera a frio no cluster:
- Um APIC em modo de espera oferece uma opção de espera a frio, recomendada em implementações do Cisco ACI Stretched Fabric ou Multipod, onde a possibilidade de uma situação de cérebro dividido do APIC é maior.
- Recomenda-se ter pelo menos três APICs ativos no cluster e um ou mais APICs em espera.
- Desligamento e reinicialização de APICs no cluster:
- Quando necessário, é possível desligar os APICs no cluster, por exemplo, ao movê-los para outro local.
- Certifique-se de colocar o APIC online assim que possível e verifique se todos os controladores do cluster retornam a um estado totalmente adequado.
Conclusão:
Em resumo, o Cluster do Cisco APIC na infraestrutura ACI representa a espinha dorsal do gerenciamento de políticas, configuração e serviços. A combinação da arquitetura de cluster dinâmica com a tecnologia de banco de dados sharding oferece uma solução robusta, escalável e confiável para atender às demandas crescentes das redes modernas. Ao compreender o funcionamento interno desse ecossistema, os profissionais de redes podem otimizar o desempenho e a eficácia de suas infraestruturas. O Cisco APIC Clustering não é apenas uma resposta às necessidades atuais, mas também uma preparação para os desafios futuros na evolução das infraestruturas de rede.
E se 3 APICs ainda não tiverem sido instalados?
Ao ativar a malha da Cisco ACI, você pode ter um único APIC ou dois APICs antes de ter um cluster totalmente funcional. Esse não é o estado final desejado, mas a Cisco ACI permite que você configure a malha com um APIC ou com dois APICs porque o bootstrap é considerado uma exceção.
- Quando você inicia uma malha com um único APIC, os shards não estão em minoria porque o cluster ainda não foi totalmente ajustado.
- Esse é um caso especial projetado para dar suporte ao Zero Touch Provisioning .
- Há apenas uma réplica de cada fragmento.
- O APIC criará novas réplicas assim que um novo APIC for adicionado.
- Isso explica por que, ao instalar a malha da ACI na primeira vez, você pode operar a malha mesmo com um único APIC
E se todos os APICs estiverem inativos?
O encaminhamento de tráfego persiste para sessões existentes e novas. Algumas considerações importantes incluem:
- Os Leafs operam de forma totalmente autossuficiente no encaminhamento de tráfego e na aplicação de políticas.
- As falhas de link são automaticamente recuperadas para garantir a continuidade do serviço.
- A adição de novos pontos de extremidade pode ou não ser bem-sucedida, dependendo da resolução e do timing da implementação.
- A eficácia do Vmotion também está sujeita à resolução e timing da implementação.
- No caso de problemas, como a necessidade de recuperação do Fabric ID, a existência de um snapshot pode ser crucial. Nesses casos, o suporte técnico (TAC) ou a unidade de negócios (BU) da Cisco podem fornecer assistência para facilitar a recuperação.
Se você gostou do artigo, não se esqueça de deixar seu like ou seu kudos!
Refêrencia:
https://www.ciscolive.com/on-demand/learning-maps/data-center/aci.html