Confiabilidade no Operador Nexus do Azure
Importante
Esse recurso está atualmente na visualização. As versões prévias são disponibilizadas com a condição de que você concorde com os termos de uso complementares.
Este artigo descreve o suporte para confiabilidade no Operador Nexus do Azure e aborda a resiliência intrarregional com zonas de disponibilidade. Para obter uma visão geral mais detalhada da confiabilidade no Azure, confira Confiabilidade do Azure.
Suporte à zona de disponibilidade
As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas duas zonas restantes.
As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre a arquitetura zonal versus com redundância de zona, confira Recomendações para usar zonas e regiões de disponibilidade.
O Operador Nexus do Azure oferece implantações com redundância de zona de disponibilidade por padrão. Os componentes do Operador Nexus, como o Gerenciador de Cluster e o Controlador de Malha de Rede, são todos implantados em um cluster do Serviço de Kubernetes do Azure (AKS) habilitado com zonas de disponibilidade. Outras dependências de serviço, como o Serviço de Conta de Armazenamento e o KeyVault, também são configuradas com redundância de zona de disponibilidade.
Observação
A Instância local do Operador Nexus implementam um design de vários racks que fornece redundância física em todos os níveis da pilha. Cada rack é projetado como um domínio de falha ou zona Nexus. As cargas de trabalho do cliente podem ser implantadas em vários racks/nós, essencialmente fornecendo uma experiência de zona de várias disponibilidades semelhante.
Experiência de zona de disponibilidade do Azure inoperante
Em um cenário de zona de disponibilidade inoperante, as chamadas à API no cluster e nos provedores de recursos continuariam a funcionar sem interrupção. Não haveria nenhum impacto nas cargas de trabalho de locatário locais em execução no momento ou na capacidade de criar novas cargas de trabalho de locatário. Além disso, nenhuma perda de dados deve ocorrer, pois a resiliência do Operador Nexus e de outros tipos de recursos está garantida.
Suporte a failover de zona de disponibilidade do Azure
No caso de uma falha de zona de disponibilidade, a reconexão a outra zona de disponibilidade do Azure é automática e não requer nenhuma interação do usuário.
Disponibilidade em implantações de instância do Operador Nexus
Garantir a disponibilidade nas implantações de carga de trabalho do Operador Nexus do Azure é uma responsabilidade dividida. Conforme mencionado na seção anterior, os recursos com base no Operator Nexus do AKS são implantados com redundância de zona de disponibilidade. Nesta seção, consideramos as melhores práticas para disponibilidade de carga de trabalho local.
Em geral, as metas de disponibilidade são alcançadas por meio de implantações locais e com redundância geográfica.
Zona Nexus: um mecanismo para redundância de carga de trabalho local
As instâncias locais do Operador Nexus consistem em um design de vários racks que fornece redundância física em todos os níveis da pilha. Cada rack é designado como um domínio de falha e, portanto, pode ser configurado como uma zona Nexus em que essas zonas podem e, preferencialmente, devem ser usadas para implantações de carga de trabalho com redundância local.
Instância Nexus: um mecanismo para redundância de carga de trabalho geográfica
As instâncias locais Nexus são hospedados em uma região específica do Azure. Conforme mencionado anteriormente, os serviços usados do Azure e os recursos Nexus são implantados em várias zonas de disponibilidade dessa região do Azure.
Instâncias do Nexus que são distribuídas geograficamente, ou seja, não estão no mesmo data center do operador (possivelmente nem mesmo na mesma região geográfica) e que são hospedadas em diferentes regiões do Azure devem ser utilizadas para implantar cargas de trabalho com redundância geográfica.
Aviso
Implantar cargas de trabalho em, digamos, duas instâncias Nexus geograficamente distribuídas é insuficiente para obter redundância geográfica verdadeira, a menos que as instâncias Nexus com redundância geográfica estejam hospedadas em diferentes regiões do Azure.
No caso improvável de uma região do Azure ficar indisponível, os serviços do Azure, bem como os recursos Nexus nessa região, também ficarão indisponíveis. Embora isso não afete a execução de cargas de trabalho, ela impede recursos como o de iniciar novas cargas de trabalho, análises, etc.
Várias instâncias Nexus na mesma localização geográfica
Há cenários em que várias instâncias Nexus precisam ser implantadas na mesma localização geográfica. A redundância geográfica da carga de trabalho obviamente não é obtida implantando cargas de trabalho em instâncias Nexus na mesma localização geográfica.
Uma consideração na criação de confiabilidade, além da disponibilidade, é a resiliência e a capacidade de se recuperar de falhas. A recuperação de falhas e a capacidade de atender aos objetivos de tempo de recuperação exigem que limitemos o raio de "explosão" ou impacto de falhas. No cenário em que várias instâncias Nexus são implantadas na mesma localização geográfica, o design resiliente exige que essas instâncias Nexus sejam hospedadas em diferentes regiões do Azure. Assim, quando uma região do Azure falha, seu impacto é limitado a uma instância Nexus.