Migrar cargas de trabalho do Serviço Kubernetes do Azure (AKS) e do Servidor Flexível MySQL para o suporte à zona de disponibilidade
Este guia descreve como migrar uma carga de trabalho do Serviço Kubernetes do Azure e do Servidor Flexível MySQL para concluir o suporte à zona de disponibilidade em todos os serviços dependentes. Para obter uma lista completa de todas as dependências de carga de trabalho, consulte Dependências de serviço de carga de trabalho.
O suporte da zona de disponibilidade para esta carga de trabalho deve ser ativado durante a criação do seu cluster AKS ou do MySQL Flexible Server. Se você quiser suporte à zona de disponibilidade para um cluster AKS existente e Servidor Flexível MySQL, precisará reimplantar esses recursos.
Estas diretrizes de migração se concentram principalmente nas considerações de infraestrutura e disponibilidade da execução da seguinte arquitetura no Azure:
Dependências do serviço de carga de trabalho
Para fornecer suporte total à carga de trabalho para zonas de disponibilidade, cada dependência de serviço na carga de trabalho deve oferecer suporte a zonas de disponibilidade.
Existem dois tipos de abordagem de serviços suportados por zona de disponibilidade: zonal ou redundante de zona. A maioria dos serviços suporta um ou outro. No entanto, em alguns casos, há opções para escolher um recurso zonal ou redundante de zona para esse serviço. Indicamos quais serviços oferecem suporte a recursos redundantes zonais e de zona nas recomendações a seguir. Também indicamos quais serviços são globais e regionais.
A arquitetura de carga de trabalho AKS e MySQL consiste nas seguintes dependências de componentes:
Azure Kubernetes Service (AKS)
Zonal : O pool de nós do sistema e os pools de nós de usuário são zonais quando você pré-seleciona as zonas nas quais os pools de nós são implantados durante o tempo de criação. Recomendamos que você pré-selecione as três zonas para melhor resiliência. Mais pools de nós de usuário que suportam zonas de disponibilidade podem ser adicionados a um cluster AKS existente e fornecendo um valor para o
zonesparâmetro.Redundante de zona: os componentes do plano de controle do Kubernetes, como etcd, servidor API, Scheduler e Controller Manager, são replicados ou distribuídos automaticamente entre zonas.
Nota
Para habilitar a redundância de zona dos componentes do plano de controle de cluster AKS, você deve definir seu pool de nós do sistema padrão com zonas ao criar um cluster AKS. Adicionar mais pools de nós zonais a um cluster AKS não zonal existente não tornará a zona do cluster AKS redundante, porque essa ação não distribui os componentes do plano de controle entre as zonas após o fato.
Base de Dados do Azure para MySQL – Servidor Flexível
Zonal: O modo de disponibilidade zonal significa que um servidor em espera está sempre disponível dentro da mesma zona que o servidor primário. Embora essa opção reduza o tempo de failover e a latência da rede, ela é menos resiliente devido a uma interrupção de zona única que afeta os servidores primário e em espera.
Zone-redundant: O modo de disponibilidade com redundância de zona significa que um servidor em espera está sempre disponível dentro de outra zona na mesma região que o servidor primário. Duas zonas serão habilitadas para redundância de zona para os servidores primário e em espera. Recomendamos esta configuração para uma melhor resiliência.
Azure Standard Load Balancer ou Azure Application Gateway
Balanceador de Carga Standard
Para entender as considerações relacionadas aos recursos do Balanceador de Carga Padrão, consulte Balanceador de carga e zonas de disponibilidade.
Redundante de zona: Escolher redundância de zona é a maneira recomendada de configurar seu IP Frontend com seu Load Balancer existente. O front-end com redundância de zona corresponde ao pool de back-end do cluster AKS, que é distribuído em várias zonas.
Zonal: Se você estiver fixando seus pools de nós em zonas específicas, como as zonas 1 e 2, poderá pré-selecionar as zonas 1 e 2 para seu IP Frontend no Load Balancer existente. A razão pela qual você pode querer fixar seus pools de nós em zonas específicas pode ser devido à disponibilidade de séries especializadas de VM SKU, como a série M.
Gateway de Aplicação do Azure
O uso do complemento Application Gateway Ingress Controller com seu cluster AKS é suportado apenas em SKUs do Application Gateway v2 (Standard e WAF). Para entender mais considerações relacionadas ao Gateway de Aplicativo do Azure, consulte Dimensionando o Gateway de Aplicativo v2 e o WAF v2.
Zonal: Para usar os benefícios das zonas de disponibilidade, recomendamos que o recurso do Application Gateway seja criado em várias zonas, como as zonas 1, 2 e 3. Selecione as três zonas para obter a melhor estratégia de resiliência intrarregião. No entanto, para corresponder aos pools de nós de back-end, você pode fixar os pools de nós em zonas específicas pré-selecionando as zonas 1 e 2 durante a criação do recurso do App Gateway. A razão pela qual você pode querer fixar seus pools de nós em zonas específicas pode ser devido à disponibilidade de séries especializadas de VM SKU, como M-series.
Armazenamento Redundante na Zona (ZRS)
Recomendamos que seu cluster AKS seja configurado com discos ZRS gerenciados porque eles são recursos redundantes de zona. Os volumes podem ser agendados em todas as zonas.
O Kubernetes está ciente das zonas de disponibilidade do Azure desde a versão 1.12. Você pode implantar um objeto fazendo referência a um Disco Gerenciado do Azure em um
PersistentVolumeClaimcluster AKS de várias zonas. O Kubernetes se encarregará de agendar qualquer pod que reivindique esse PVC na zona de disponibilidade correta.Para o Banco de Dados do Azure para SQL, recomendamos que os dados e os arquivos de log sejam hospedados no ZRS (armazenamento com redundância de zona). Esses arquivos são replicados para o servidor em espera por meio da replicação no nível de armazenamento disponível com o ZRS.
Azure Firewall
Zonal: Para usar os benefícios das zonas de disponibilidade, recomendamos que o recurso Firewall do Azure seja criado em várias zonas, como a zona 1, 2 e 3. Recomendamos que você selecione as três zonas para a melhor estratégia de resiliência intrarregião.
Azure Bastion
Regional: o Azure Bastion é implantado em VNets ou VNets emparelhadas e está associado a uma região do Azure. Para mais informações, se Bastion FAQ.
Azure Container Registry (ACR)
Redundante de zona: recomendamos que você crie um registro com redundância de zona na camada de serviço Premium. Você também pode criar uma réplica do Registro com redundância de zona definindo a propriedade para a zoneRedundancy réplica. Para saber como habilitar a redundância de zona para seu ACR, consulte Habilitar redundância de zona no Registro de Contêiner do Azure para resiliência e alta disponibilidade.
Cache do Azure para Redis
Zone-redundant: o Cache Redis do Azure dá suporte a configurações com redundância de zona nas camadas Premium e Enterprise. Um cache com redundância de zona coloca seus nós em diferentes zonas de disponibilidade na mesma região.
Microsoft Entra ID
Global: O Microsoft Entra ID é um serviço global com vários níveis de redundância interna e capacidade de recuperação automática. O Microsoft Entra ID é implantado em mais de 30 datacenters em todo o mundo que fornecem zonas de disponibilidade onde estiverem presentes. Este número está a crescer rapidamente à medida que mais regiões são implantadas.
Azure Key Vault
Regional: o Azure Key Vault é implantado em uma região. Para manter a alta durabilidade de suas chaves e segredos, o conteúdo do cofre de chaves é replicado dentro da região e para uma região secundária dentro da mesma geografia.
Zona redundante: para regiões do Azure com zonas de disponibilidade e sem par de regiões, o Cofre da Chave usa o armazenamento com redundância de zona (ZRS) para replicar o conteúdo do cofre de chaves três vezes dentro do único local/região.
Considerações sobre a carga de trabalho
Azure Kubernetes Service (AKS)
Os pods podem se comunicar com outros pods, independentemente de qual nó ou da zona de disponibilidade em que o pod pousa no nó. Seu aplicativo pode ter um tempo de resposta maior se os pods estiverem localizados em zonas de disponibilidade diferentes. Embora se espere que as latências extras de ida e volta entre pods fiquem dentro de um intervalo aceitável para a maioria dos aplicativos, há cenários de aplicativos que exigem baixa latência, especialmente para um padrão de comunicação tagarela entre pods.
Recomendamos que você teste seu aplicativo para garantir que ele tenha um bom desempenho em todas as zonas de disponibilidade.
Por motivos de desempenho, como baixa latência, os pods podem ser colocalizados no mesmo data center dentro da mesma zona de disponibilidade. Para colocalizar pods no mesmo data center dentro da mesma zona de disponibilidade, você pode criar pools de nós de usuário com uma zona exclusiva e um grupo de posicionamento de proximidade. Você pode adicionar um grupo de posicionamento de proximidade (PPG) a um cluster AKS existente criando um novo pool de nós de agente e especificando o PPG. Use as Restrições de Propagação de Topologia de Pod para controlar como os pods são distribuídos em seu cluster AKS em zonas de disponibilidade, nós e regiões.
Depois que os pods que exigem comunicação de baixa latência são colocalizados na mesma zona de disponibilidade, as comunicações entre os pods não são diretas. Em vez disso, as comunicações do pod são canalizadas através de um serviço que define um conjunto lógico de pods no seu cluster AKS. Os pods podem ser configurados para falar com o AKS e a comunicação com o serviço será automaticamente balanceada para todos os pods que são membros do serviço.
Para aproveitar as zonas de disponibilidade, os pools de nós contêm VMs subjacentes que são recursos zonais. Para dar suporte a aplicativos com diferentes demandas de computação ou armazenamento, você pode criar pools de nós de usuário com tamanhos de VM específicos ao criar o pool de nós de usuário.
Por exemplo, você pode decidir usar o sob o
Standard_M32msM-seriespara seus nós de usuário porque os microsserviços em seu aplicativo exigem alta taxa de transferência, baixa latência e tamanhos de VM otimizados para memória que fornecem altas contagens de vCPU e grandes quantidades de memória. Dependendo da região de implantação, quando você seleciona o tamanho da VM no portal do Azure, você pode ver que esse tamanho de VM é suportado apenas nas zonas 1 e 2. Você pode aceitar essa configuração de resiliência como uma compensação para alto desempenho.Não é possível alterar o tamanho da VM de um pool de nós depois de criá-lo. Para obter mais informações sobre limitações do pool de nós, consulte Limitações.
Base de Dados do Azure para MySQL – Servidor Flexível
A implicação da implantação de seus pools de nós em zonas específicas, como as zonas 1 e 2, é que todas as dependências de serviço do cluster AKS também devem suportar as zonas 1 e 2. Nesta arquitetura de carga de trabalho, seu cluster AKS tem uma dependência de serviço no Banco de Dados do Azure para Servidores Flexíveis MySQL com resiliência de zona. Você selecionaria a zona 1 para seu servidor primário e a zona 2 para seu servidor em espera para ser co-localizado com seus pools de nós de usuário AKS.
Cache do Azure para Redis
O Cache Redis do Azure distribui nós em um cache com redundância de zona de maneira round-robin nas zonas de disponibilidade selecionadas.
Não é possível atualizar um cache Premium existente para usar redundância de zona. Para usar a redundância de zona, você deve recriar o Cache do Azure para Redis.
Para obter a resiliência ideal, recomendamos que você crie seu Cache Redis do Azure com três ou mais réplicas para que possa distribuir as réplicas em três zonas de disponibilidade.
Considerações sobre a recuperação após desastre
As zonas de disponibilidade são usadas para melhor resiliência para alcançar alta disponibilidade de sua carga de trabalho na região principal de sua implantação.
A recuperação de desastres consiste em operações e práticas de recuperação definidas em seu plano de continuidade de negócios. Seu plano de continuidade de negócios aborda como sua carga de trabalho se recupera durante um evento disruptivo e como ela se recupera totalmente após o evento. Considere estender sua implantação para uma região alternativa.
Para sua camada de aplicativo, analise as considerações sobre continuidade de negócios e recuperação de desastres para o AKS neste artigo.
Considere a execução de vários clusters AKS em regiões alternativas. A região alternativa pode usar uma região secundária emparelhada. Ou, quando não houver emparelhamento de regiões para sua região principal, você pode selecionar uma região alternativa com base em sua consideração pelos serviços disponíveis, capacidade, proximidade geográfica e soberania de dados. Consulte o guia de decisão das regiões do Azure. Analise também o padrão de carimbo de implantação.
Você tem a opção de configurar active-active, active-standby, active-passive para seus clusters AKS.
Para a camada de banco de dados, os recursos de recuperação de desastres incluem backups com redundância geográfica com a capacidade de iniciar a restauração geográfica e implantar réplicas de leitura em uma região diferente.
Durante uma interrupção, você precisará decidir se deseja iniciar uma recuperação. Você precisará iniciar as operações de recuperação somente quando for provável que a interrupção dure mais do que o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) da carga de trabalho. Caso contrário, você aguardará a recuperação do serviço verificando o status do serviço no Painel de Integridade do Serviço do Azure. Na folha Estado de Funcionamento do Serviço do portal do Azure, pode ver quaisquer notificações associadas à sua subscrição.
Quando você inicia a recuperação com o recurso de restauração geográfica no Banco de Dados do Azure para MySQL, um novo servidor de banco de dados é criado usando dados de backup que são replicados de outra região.
Passos Seguintes
Saiba mais sobre: