Migrar cargas de trabalho do Servidor Flexível do MySQL e do AKS (Serviço de Kubernetes do Azure) para dar suporte à zona de disponibilidade

Este guia descreve como migrar uma carga de trabalho do Servidor Flexível do MySQL e do Serviço de Kubernetes do Azure 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 à zona de disponibilidade para essa carga de trabalho deverá ser habilitado durante a criação do Servidor Flexível do MySQL ou do cluster do AKS. Se você quiser ter suporte para a zona de disponibilidade de um Servidor Flexível do MySQL ou do cluster do AKS, será necessário reimplantar esses recursos.

Essas diretrizes de migração concentram-se principalmente nas considerações de infraestrutura e disponibilidade da execução da seguinte arquitetura no Azure:

Dependências de serviço de carga de trabalho

Para dar suporte total à carga de trabalho para zonas de disponibilidade, cada dependência de serviço na carga de trabalho deverá dar suporte às zonas de disponibilidade.

Há dois tipos de abordagens de serviços com suporte para zona de disponibilidade: zonal ou com redundância de zona. A maioria dos serviços dá suporta para um ou outro. No entanto, em alguns casos, há opções para escolher um recurso zonal ou com redundância de zona para o serviço. Nas recomendações abaixo, indicaremos quais serviços dão suporte a recursos zonais e com redundância de zona. Indicaremos também os serviços que são globais e regionais.

A arquitetura de carga de trabalho do AKS e do MySQL consiste nas seguintes dependências de componentes:

AKS (Serviço de Kubernetes do Azure)

• Zonal: o pool de nós de sistema e os pools de nós de usuário serão zonais quando você pré-selecionar as zonas em que os pools de nós serão implementados durante o tempo de criação. É recomendável pré-selecionar todas as três zonas para melhor resiliência. Mais pools de nós de usuário que dão suporte a zonas de disponibilidade poderão ser adicionados a um cluster AKS existente e fornecendo um valor para o parâmetro zones.

• Com redundância de zona: os componentes do plano de controle do Kubernetes como etcd, servidor de API, Agendador e Gerenciador do Controlador são replicados ou distribuídos automaticamente entre as zonas.

  Observação

  Para habilitar com redundância de zona dos componentes do plano de controle do cluster do AKS, será necessário definir o pool de nós de sistema padrão com zonas ao criar um cluster do AKS. Adicionar mais pools de nós zonais a um cluster do AKS não zonal existente não tornará o cluster do AKS redundante, porque essa ação não distribuirá os componentes do plano de controle entre as zonas posteriormente.

Servidor Flexível do Banco de Dados do Azure para MySQL

• Zonal: o modo de disponibilidade zonal significa que um servidor em espera está sempre disponível na mesma zona que o servidor primário. Embora essa opção reduza o tempo de failover e a latência da rede, é menos resiliente devido a uma interrupção de zona única que afeta tanto os servidores primários como os servidores em espera.

• Com redundância de zona: o modo de disponibilidade com redundância de zona significa que um servidor em espera está sempre disponível em 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ários e os servidores em espera. Essa configuração é recomendável para melhor resiliência.

Standard Load Balancer do Azure ou Gateway de Aplicativo do Azure

Standard Load Balancer

Para saber mais sobre as considerações relacionadas aos recursos do Standard Load Balancer, consulte Load Balancer e Zonas de Disponibilidade.

• Com redundância de zona: escolher com redundância de zona é a maneira recomendada para configurar o IP de front-end com o Load Balancer existente. O front-end com redundância de zona corresponde ao pool de back-end do cluster do AKS, que é distribuído em várias zonas.

• Zonal: se você estiver fixando os pools de nós em zonas específicas, como zona 1 e 2, poderá pré-selecionar as zonas 1 e 2 para o IP de front-end no Load Balancer existente. O motivo pelo qual é desejável fixar os pools de nós em zonas específicas pode ser devido à disponibilidade de séries especializadas de SKU de VM como, por exemplo, a série M.

Gateway de Aplicativo do Azure

Há suporte para usar o complemento do Controlador de Entrada de Gateway de Aplicativo com o cluster do AKS apenas em SKUs do Gateway de Aplicativo v2 (Padrão e WAF). Para saber mais sobre as considerações relacionadas ao Gateway de Aplicativo do Azure, consulte Escala do Gateway de Aplicativo v2 e WAF v2.

Zonal: para usar os benefícios das zonas de disponibilidade, é recomendável que o recurso de Gateway de Aplicativo seja criado em várias zonas, como zonas 1, 2 e 3. Selecione todas as três zonas para obter a melhor estratégia de resiliência intra-regional. No entanto, para corresponder aos pools de nós de back-end, é possível fixar os pools de nós em zonas específicas pré-selecionando as zonas 1 e 2 durante a criação do recurso do Gateway de Aplicativo. O motivo pelo qual é desejável fixar os pools de nós em zonas específicas pode ser devido à disponibilidade de séries especializadas de SKU de VM como, por exemplo, M-series.

ZRS (Armazenamento com Redundância de Zona)

• É recomendável configurar o cluster do AKS com discos de ZRS gerenciados porque são recursos com redundância 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. É possível implantar um objeto PersistentVolumeClaim fazendo referência a um Disco Gerenciado do Azure em um cluster do AKS de várias zonas. O Kubernetes cuidará do agendamento de qualquer pod que declarar esse PVC na zona de disponibilidade correta.

• Para o Banco de Dados do Azure para SQL, é recomendável que os dados e os arquivos de log sejam hospedados no ARS (armazenamento com redundância de zona). Esses arquivos são replicados para o servidor em espera por meio da replicação no nível do armazenamento disponível com o ZRS.

Firewall do Azure

Zonal: para usar os benefícios das zonas de disponibilidade, é recomendável que o recurso de Firewall do Azure seja criado em várias zonas, como zonas 1, 2 e 3. É recomendável selecionar todas as três zonas para obter a melhor estratégia de resiliência intrarregional.

Azure Bastion

Regional: o Azure Bastion é implantado em VNets ou VNets emparelhadas e associado a uma região do Azure. Para obter mais informações, confira Confiabilidade do Azure Bastion.

Registro de Contêiner do Azure (ACR)

Com redundância de zona: é recomendável criar um registro com redundância de zona na camada de serviço Premium. Também é possível criar uma réplica de registro com redundância de zona definindo a propriedade zoneRedundancy para a réplica. Para saber como habilitar a redundância de zona para o ACR, consulte Habilitar a redundância de zona no Registro de Contêiner do Azure para resiliência e alta disponibilidade.

Cache Redis do Azure

Com redundância de zona: o Cache do Azure para Redis dá suporte a configurações com redundância de zona nas camadas Premium e Enterprise. Um cache com redundância de zona coloca os 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, quando presentes. Esse número está crescendo rapidamente à medida que mais regiões são implantadas.

Cofre de Chave do Azure

Regional: o Azure Key Vault é implantado em uma região. Para manter a alta durabilidade das chaves e dos segredos, o conteúdo do cofre de chaves é replicado dentro da região e para uma região secundária dentro da mesma geografia.

Com redundância de zona: para regiões do Azure com zonas de disponibilidade e sem par de regiões, o Key Vault usa o ZRS (armazenamento com redundância de zona) para replicar o conteúdo do cofre de chaves três vezes dentro de um único local/região.

Considerações sonre a carga de trabalho

AKS (Serviço de Kubernetes do Azure)

• Pods podem estabelecer comunicação com outros pods, independentemente de qual nó ou zona de disponibilidade em que o pod chega ao nó. O aplicativo poderá ter um tempo de resposta mais alto se os pods estiverem localizados em diferentes zonas de disponibilidade. Embora seja esperado que as latências de ida e volta adicionais entre os pods estejam 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 de conversas entre os pods.

• É recomendável testar o aplicativo para garantir que ele tenha um bom desempenho nas zonas de disponibilidade.

• Por motivos de desempenho como baixa latência, os pods poderão ser colocalizados no mesmo datacenter dentro da mesma zona de disponibilidade. Para colocalizar os pods no mesmo datacenter dentro da mesma zona de disponibilidade, é possível criar pools de nós de usuário com uma zona exclusiva e um grupo de posicionamento de proximidade. Você pode adicionar um PPG (grupo de posicionamento de proximidade) a um cluster do AKS existente criando um novo pool de nós de agente e especificando o PPG. Use as Restrições de Espalhamento de Topologia de Pod para controlar como os pods serão distribuídos no cluster do AKS entre as zonas de disponibilidade, os nós e as regiões.

• Após colocalizar os pods que exigem comunicação de baixa latência na mesma zona de disponibilidade, as comunicações entre os pods não serão diretas. Em vez disso, as comunicações de pods serão canalizadas por meio de um serviço que definirá um conjunto lógico de pods no cluster do AKS. Os pods podem ser configurados para conversar com o AKS e a comunicação com o serviço balanceará carga automaticamente para todos os pods que forem 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 demandas de computação ou armazenamento diferentes, é possível 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 Standard_M32ms sob M-series para os nós de usuário porque os microsserviços no 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, ao selecionar o tamanho da VM no portal do Azure será possível ver que há suporte para esse tamanho de VM apenas nas zonas 1 e 2. Você pode aceitar essa configuração de resiliência como uma compensação por alto desempenho.

• Você não pode alterar o tamanho da VM de um pool de nós depois de criá-la. Para obter mais informações sobre as limitações do pool de nós, consulte Limitações.

Servidor Flexível do Banco de Dados do Azure para MySQL

A implicação de implantar os pools de nós em zonas específicas, como zona 1 e 2, é que todas as dependências de serviço do cluster do AKS também deverão dar suporte às zonas 1 e 2. Nessa arquitetura de carga de trabalho, o cluster do AKS tem uma dependência de serviço em Servidores Flexíveis de Banco de Dados do Azure para MySQL com resiliência de zona. Você selecionaria a zona 1 para o servidor primário e a zona 2 para o servidor em espera a ser colocalizado com os pools de nós de usuário do AKS.

Cache Redis do Azure

• O Cache do Azure para Redis distribui os nós em um cache com redundância de zona de maneira round-robin nas zonas de disponibilidade que você selecionou.

• Não é possível atualizar um cache Premium existente para usar redundância de zona. Para usar a redundância de zona, será necessário recriar o Cache do Azure para Redis.

• Para obter a resiliência ideal, é recomendável criar o Cache do Azure para Redis com três ou mais réplicas para poder distribuir as réplicas em três zonas de disponibilidade.

Considerações de recuperação de desastres

Zonas de disponibilidade são usadas para melhorar a resiliência e obter alta disponibilidade da carga de trabalho na região primária da implantação.

Recuperação de Desastre consiste em operações e práticas de recuperação definidas no plano de continuidade dos negócios. O plano de continuidade dos negócios aborda como a carga de trabalho se recupera durante um evento disruptivo e como se recupera totalmente após o evento. Considere estender a implantação para uma região alternativa.

Para a camada de aplicativo, examine neste artigo as considerações sobre a continuidade dos negócios e recuperação de desastres para AKS.

• Considere executar vários clusters do AKS em regiões alternativas. A região alternativa poderá usar uma região secundária emparelhada. Ou, quando não houver emparelhamento de região para a região primária, você poderá selecionar uma região alternativa considerando os serviços, a capacidade, a proximidade geográfica e a soberania de dados disponíveis. Examine o guia de decisão de regiões do Azure. Examine também o padrão de selo de implantação.

• Há as opções de configuração ativo-ativo, ativo em espera, ativo-passivo para os clusters do AKS.

• Para a camada de banco de dados, os recursos de recuperação de desastre 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 desejará iniciar uma recuperação. As operações de recuperação somente serão necessárias quando a interrupção provavelmente durar mais do que o RTO (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 de Integridade do Serviço do portal do Azure, você poderá exibir todas as notificações associadas à assinatura.

• Ao iniciar 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 será criado usando os dados de backup replicados de outra região.

Próximas etapas

Saiba mais sobre: