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 de nós for três ou mais), o sistema de alta disponibilidade (HA) prioriza o failover dentro da própria zona primária quando o nó master falha. Esse recurso evita o aumento de latência de acesso das aplicações causado por um failover para uma zona secundária.
Este recurso é ativado por padrão para instâncias cloud-native que utilizam arquitetura padrão ou cluster, sem necessidade de configuração manual. Este tópico usa a arquitetura de cluster como exemplo.
Informações básicas
Por padrão, uma implantação em múltiplas zonas de disponibilidade distribui os nós master e réplica de cada shard de uma instância cluster em zonas de disponibilidade diferentes dentro da mesma região. Essas zonas são locais fisicamente isolados, com energia e rede independentes, o que garante alta capacidade de recuperação de desastres à instância.
Quando o nó master de um shard falha, a instância aciona automaticamente um failover para minimizar o impacto. Os clientes geralmente são implantados na zona primária. Antes do failover, o cliente e o nó master estão na mesma zona de disponibilidade, resultando na menor latência de acesso possível. O diagrama a seguir ilustra uma arquitetura de cluster típica com três shards.
Quando o nó master de um shard falha, o sistema de alta disponibilidade (HA) promove um nó réplica na zona secundária para se tornar o novo nó master. Isso força o cliente a acessar a instância entre zonas de disponibilidade, aumentando significativamente a latência de acesso.
A latência de acesso entre zonas de disponibilidade distintas é muito maior do que dentro de uma única zona. Para detalhes sobre a latência média entre 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, uma alta latência de rede impacta diretamente os tempos de resposta do negócio. Por isso, recomendamos adicionar um nó réplica extra à zona primária da sua instância cluster. Essa abordagem equilibra alto desempenho e estabilidade com alta capacidade de recuperação de desastres.
Quando o nó master falha, a instância executa o failover preferencialmente para um nó réplica dentro da mesma zona de disponibilidade. Após o failover, o novo nó master permanece na zona primária, evitando o aumento da latência de acesso.
Em caso de falha no nível da zona primária, a instância realiza um failover entre zonas, garantindo alta capacidade de recuperação de desastres.
Como funciona
O Tair (Redis OSS-compatible) permite configure de 2 a 5 nós para cada shard de uma instância cluster.
Com 2 nós, um nó é implantado na zona primária e o outro na zona secundária por padrão.
Com 3 nós, dois nós são implantados na zona primária e um nó é implantado na zona secundária por padrão.
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 de cluster com três shards e três nós (dois nós na zona primária e um nó na zona secundária), conforme ilustrado na figura a seguir.
Se o nó master de um shard falhar, o sistema de alta disponibilidade (HA) promove preferencialmente o nó réplica na zona primária para se tornar o novo nó master. O cliente continua acessando a instância dentro da mesma zona de disponibilidade, evitando o aumento da latência de acesso, conforme mostrado na figura a seguir.
Procedimento
-
Caso ainda não tenha uma instância, crie uma instância cloud-native em 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, defina as seguintes configurações: na página de configurações, configure Intelligent Read/Write Splitting (selecione Disabled ou Enabled; esse recurso não está disponível para instâncias de arquitetura cluster no modo de conexão direta sem proxy). Selecione o Number of Nodes. Por exemplo, 3 Nodes fornece um nó master e dois nós réplica para cada shard em uma arquitetura cluster. Se o read/write splitting estiver ativado, os nós réplica também podem atender requisições de leitura. Defina a quantidade de nós em Node Allocation (Primary AZ). O número de nós na zona secundária é calculado como: Number of Nodes - Nodes in Primary AZ. Recomendamos configurar pelo menos dois nós tanto na zona primária quanto na secundária, totalizando no mínimo quatro nós.
Se você já tiver uma instância cloud-native em zona de disponibilidade única, primeiro migre a instância para uma implantação em múltiplas zonas de disponibilidade. Em seguida, na página Add or Remove Replica Nodes, aumente a contagem de nós na zona primária para pelo menos dois.
Se você já tiver uma instância cloud-native em múltiplas zonas de disponibilidade, aumente a contagem de nós na zona primária para pelo menos dois na página Add or Remove Replica Nodes. Na seção Node Distribution (Availability Zone), clique em Modifique na coluna Actions referente à zona primária.
Se você tiver uma instância que utiliza o modo de implantação Classic, crie uma nova instância que atenda aos requisitos descritos anteriormente e migre os dados para ela usando DTS para realizar sincronização unidirecional na mesma conta Alibaba Cloud.