Partilhar via

Failover e aplicação de patches para o Azure Managed Redis (visualização)

  • Artigo

Para criar aplicativos cliente resilientes e bem-sucedidos, é fundamental entender o failover no serviço Azure Managed Redis (visualização). Um failover pode fazer parte das operações de gerenciamento planejadas ou pode ser causado por falhas não planejadas de hardware ou rede. Um uso comum de failover de cache ocorre quando o serviço de gerenciamento corrige os binários do Azure Managed Redis.

Neste artigo, você encontra estas informações:

  • O que é um failover?
  • Como o failover ocorre durante a aplicação de patches.
  • Como criar um aplicativo cliente resiliente.

O que é um failover?

Vamos começar com uma visão geral do failover para o Azure Managed Redis.

Um resumo rápido da arquitetura de cache

Diagrama mostrando a arquitetura da oferta do Azure Managed Redis.

Um cache é construído de várias máquinas virtuais com endereços IP separados e privados. Cada máquina virtual (ou "nó") executa vários processos de servidor Redis (chamados "fragmentos") em paralelo. Vários fragmentos permitem uma utilização mais eficiente de vCPUs em cada máquina virtual e maior desempenho. Nem todos os fragmentos Redis primários estão na mesma VM/nó. Em vez disso, os fragmentos primários e de réplica são distribuídos em ambos os nós. Como os fragmentos primários usam mais recursos de CPU do que os fragmentos de réplica, essa abordagem permite que mais fragmentos primários sejam executados em paralelo. Cada nó tem um processo de proxy de alto desempenho para gerenciar os fragmentos, lidar com o gerenciamento de conexões e acionar a autorrecuperação. Um fragmento pode estar inativo, enquanto os outros permanecem disponíveis.

Detalhes detalhados da Arquitetura Redis Gerenciada do Azure podem ser encontrados aqui.

Explicação de um failover

Um failover ocorre quando um ou mais fragmentos de réplica se promovem para se tornarem fragmentos primários e os fragmentos primários antigos fecham conexões existentes. Um failover pode ser planejado ou não.

Um failover planejado ocorre durante dois momentos diferentes:

  • Atualizações do sistema, como patches Redis ou atualizações do sistema operacional.
  • Operações de gerenciamento, como dimensionamento e reinicialização.

Como os nós recebem aviso prévio da atualização, eles podem trocar funções cooperativamente e atualizar rapidamente o balanceador de carga da alteração. Um failover planejado normalmente termina em menos de 1 segundo.

Um failover não planejado pode acontecer devido a falha de hardware, falha de rede ou outras interrupções inesperadas para um ou mais nós no cluster. O(s) fragmento(s) de réplica no(s) nó(s) restante(s) promover-se-ão como primários para manter a disponibilidade, mas o processo demora mais tempo. Um fragmento de réplica deve primeiro detetar que seu fragmento principal não está disponível antes de iniciar o processo de failover. O fragmento de réplica também deve verificar se essa falha não planejada não é transitória ou local, para evitar um failover desnecessário. Esse atraso na deteção significa que um failover não planejado normalmente termina dentro de 10 a 15 segundos.

Como ocorre a aplicação de patches?

O serviço Redis Gerenciado do Azure atualiza regularmente seu cache com os recursos e correções mais recentes da plataforma. Para corrigir um cache, o serviço segue estas etapas:

  1. O serviço cria novas VMs atualizadas para substituir todas as VMs que estão sendo corrigidas.
  2. Em seguida, promove uma das novas VMs como líder do cluster.
  3. Um a um, todos os nós que estão sendo corrigidos são removidos do cluster. Todos os fragmentos nessas VMs serão rebaixados e migrados para uma das novas VMs.
  4. Finalmente, todas as VMs que foram substituídas são excluídas.

Cada fragmento de um cache clusterizado é corrigido separadamente e não fecha conexões com outro fragmento.

Vários caches no mesmo grupo de recursos e região também são corrigidos, um de cada vez. Os caches que estão em grupos de recursos diferentes ou regiões diferentes podem ser corrigidos simultaneamente.

Como a sincronização completa de dados acontece antes que o processo se repita, é improvável que ocorra perda de dados para o cache. Você pode se proteger ainda mais contra a perda de dados exportando dados e habilitando a persistência.

Carga de cache adicional

Sempre que ocorre um failover, os caches precisam replicar dados de um nó para o outro. Essa replicação causa algum aumento de carga na memória do servidor e na CPU. Se a instância de cache já estiver muito carregada, os aplicativos cliente poderão ter maior latência. Em casos extremos, os aplicativos cliente podem receber exceções de tempo limite.

Como é que uma ativação pós-falha afeta a minha aplicação cliente?

Os aplicativos cliente podem receber alguns erros de sua instância do Azure Managed Redis. O número de erros vistos por um aplicativo cliente depende de quantas operações estavam pendentes nessa conexão no momento do failover. Qualquer conexão roteada através do nó que fechou suas conexões vê erros.

Muitas bibliotecas de cliente podem lançar diferentes tipos de erros quando as conexões são interrompidas, incluindo:

  • Exceções de tempo limite
  • Exceções de conexão
  • Exceções de soquete

O número e o tipo de exceções dependem de onde a solicitação está no caminho do código quando o cache fecha suas conexões. Por exemplo, uma operação que envia uma solicitação, mas não recebeu uma resposta quando o failover ocorre, pode obter uma exceção de tempo limite. Novas solicitações no objeto de conexão fechado recebem exceções de conexão até que a reconexão aconteça com êxito.

A maioria das bibliotecas de cliente tenta se reconectar ao cache se estiver configurada para isso. No entanto, bugs imprevistos podem ocasionalmente colocar os objetos da biblioteca em um estado irrecuperável. Se os erros persistirem por mais tempo do que um período de tempo pré-configurado, o objeto de conexão deverá ser recriado. No Microsoft.NET e em outras linguagens orientadas a objetos, a recriação da conexão sem reiniciar o aplicativo pode ser realizada usando um padrão ForceReconnect.

Quais são as atualizações incluídas na manutenção?

A manutenção inclui estas atualizações:

  • Atualizações do Servidor Redis: Qualquer atualização ou patch dos binários do servidor Redis.
  • Atualizações de máquina virtual (VM): quaisquer atualizações da máquina virtual que hospeda o serviço Redis. As atualizações de VM incluem a aplicação de patches em componentes de software no ambiente de hospedagem para atualizar componentes de rede ou descomissionamento.

A manutenção aparece na integridade do serviço no portal do Azure antes de um patch?

Não, a manutenção não aparece em estado de funcionamento do serviço no portal ou em qualquer outro local.

Alterações na configuração da rede do cliente

Determinadas alterações na configuração da rede do lado do cliente podem desencadear erros sem conexão disponível . Essas alterações podem incluir:

  • Trocar o endereço IP virtual de um aplicativo cliente entre slots de preparação e produção.
  • Dimensionamento do tamanho ou número de instâncias do seu aplicativo.

Essas alterações podem causar um problema de conectividade que geralmente dura menos de um minuto. Seu aplicativo cliente provavelmente perde sua conexão com outros recursos de rede externa, mas também com o serviço Azure Managed Redis.

Construir resiliência

Você não pode evitar failovers completamente. Em vez disso, escreva seus aplicativos cliente para serem resilientes a quebras de conexão e solicitações com falha. A maioria das bibliotecas de cliente se reconecta automaticamente ao ponto de extremidade de cache, mas poucas delas tentam repetir solicitações com falha. Dependendo do cenário do aplicativo, pode fazer sentido usar a lógica de repetição com backoff.

Como faço para tornar meu aplicativo resiliente?

Consulte estes padrões de projeto para construir clientes resilientes, especialmente os padrões de disjuntor e repetição:

Conteúdos relacionados