Em uma instância cloud-native com múltiplas zonas de disponibilidade, se a zona primária tiver dois ou mais nós (e o total for três ou superior), o sistema de alta disponibilidade (HA) prioriza o failover dentro da própria zona primária quando o nó mestre falha. Esse comportamento evita o aumento na latência de acesso à aplicação causado por um failover para uma zona secundária.
Esse recurso é ativado por padrão em instâncias cloud-native com arquitetura standard ou cluster, sem necessidade de configuração manual. Este tópico usa a arquitetura cluster como exemplo.
Informações básicas
Por padrão, uma implantação em múltiplas zonas de disponibilidade distribui os nós mestre e réplica de cada shard de uma instância cluster em zonas diferentes dentro da mesma região. Essas zonas são locais fisicamente isolados, com infraestrutura elétrica e de rede independentes, o que confere à instância alta capacidade de recuperação de desastres.
Quando o nó mestre de um shard falha, a instância aciona automaticamente um failover para minimizar o impacto. Como os clientes geralmente residem na zona primária, antes do failover tanto o cliente quanto o nó mestre estão na mesma zona de disponibilidade, garantindo a menor latência de acesso possível. O diagrama a seguir ilustra uma arquitetura cluster típica com três shards.
Se o nó mestre de um shard falhar, o sistema de alta disponibilidade (HA) promove um nó réplica da zona secundária para assumir como novo nó mestre. Isso força o cliente a acessar a instância entre zonas de disponibilidade distintas, elevando significativamente a latência de acesso.
A latência de acesso entre zonas de disponibilidade diferentes é consideravelmente maior do que dentro de uma única zona. Para obter detalhes sobre a latência média entre as zonas de disponibilidade da Alibaba Cloud, consulte Cloud Network Performance.
Como o Tair (Redis OSS-compatible) é um banco de dados em memória de alto desempenho e baixa latência, qualquer elevação na latência de rede impacta diretamente os tempos de resposta da sua aplicação. Por isso, recomendamos adicionar um nó réplica extra à zona primária da sua instância cluster. Essa estratégia equilibra alto desempenho e estabilidade com uma sólida capacidade de recuperação de desastres.
Diante de uma falha no nó mestre, a instância executa preferencialmente o failover para um nó réplica na mesma zona de disponibilidade. Após o failover, o novo nó mestre permanece na zona primária, evitando o aumento da latência de acesso.
Caso ocorra uma falha no nível da zona primária, a instância realiza um failover entre zonas, assegurando alta resiliência contra desastres.
Funcionamento
O Tair (Redis OSS-compatible) permite configurar de 2 a 5 nós para cada shard de uma instância cluster.
Com 2 nós, o sistema implanta por padrão um nó na zona primária e outro na zona secundária.
Com 3 nós, a distribuição padrão aloca dois nós na zona primária e um na zona secundária.
Com 4 ou 5 nós, distribua os nós restantes entre as zonas primária e secundária conforme necessário.
Este tópico usa como exemplo uma arquitetura cluster com três shards e três nós (dois nós na zona primária e um na zona secundária), conforme ilustrado na figura a seguir.
Se o nó mestre de um shard falhar, o sistema de alta disponibilidade (HA) promove prioritariamente o nó réplica da zona primária para assumir como novo nó mestre. Dessa forma, o cliente continua acessando a instância dentro da mesma zona de disponibilidade, prevenindo qualquer aumento na latência de acesso, como mostra a figura abaixo.
Procedimento
-
Caso ainda não tenha uma instância, crie uma instância cloud-native com múltiplas zonas de disponibilidade. Para mais informações, consulte Criar uma instância.
Para garantir que a zona primária tenha pelo menos dois nós, ajuste as seguintes configurações: Na página de definições, configure a opção Read/Write Splitting (selecione Disable ou Enable. Esse recurso não está disponível para instâncias com arquitetura cluster em modo de conexão direta sem proxy). Em seguida, selecione Nodes. Por exemplo, a opção 3 Nodes fornece um nó mestre e dois nós réplica para cada shard na arquitetura cluster. Se a divisão de leitura e escrita estiver ativada, os nós réplica também poderão atender requisições de leitura. Defina a quantidade de nós no campo Node Allocation (Primary AZ). O sistema calcula automaticamente o número de nós na zona secundária pela fórmula: Total de Nós - Nós na Zona Primária. Recomendamos configurar no mínimo dois nós tanto na zona primária quanto na secundária, totalizando pelo menos quatro nós.
Se você já tem uma instância cloud-native em zona única, primeiro migre a instância para uma implantação em múltiplas zonas de disponibilidade. Depois, acesse a página Add or Remove Replica Nodes e aumente a quantidade de nós na zona primária para no mínimo dois.
Para instâncias cloud-native existentes em múltiplas zonas, aumente o número de nós na zona primária para pelo menos dois na página Add or Remove Replica Nodes. Na seção Node Distribution (Zone), clique em Modify na coluna Actions correspondente à zona primária.
Se sua instância opera no modo de implantação Classic, crie uma nova instância que atenda aos requisitos mencionados anteriormente e migre os dados usando o DTS para realizar sincronização unidirecional na mesma conta Alibaba Cloud.