Failover e aplicação de patches para o Cache do Azure para Redis

  • Artigo

Para criar aplicativos cliente resilientes e bem-sucedidos, é crítico entender o failover no serviço de Cache do Azure para Redis. Um failover pode fazer parte das operações de gerenciamento planejadas ou ser causado por falhas de hardware ou rede não planejadas. Um uso comum do failover de cache vem quando o serviço de gerenciamento aplica um patch aos binários do Cache do Azure para Redis.

Neste artigo, você encontrará estas informações:

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

O que é um failover?

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

Um resumo rápido da arquitetura de cache

Um cache é construído com várias máquinas virtuais com endereços IP privados e separados. Cada máquina virtual, também conhecida como nó, está conectada a um balanceador de carga compartilhado com um só endereço IP virtual. Cada nó executa o processo do servidor Redis e é acessível usando o nome do host e as portas Redis. Cada nó é considerado um nó primário ou de réplica. Quando um aplicativo cliente se conecta a um cache, seu tráfego passa por esse balanceador de carga e é roteado automaticamente para o nó primário.

Em um cache Básico, o único nó é sempre um primário. Em um cache Standard ou Premium, há dois nós: um é escolhido como o primário e o outro é a réplica. Como os caches Standard e Premium têm vários nós, um nó pode não estar disponível enquanto o outro continua a processar solicitações. Caches clusterizados são compostos por muitos fragmentos, cada um com nós primários e de réplica distintos. Um fragmento pode estar inativo enquanto os outros permanecem disponíveis.

Observação

Um cache básico não tem vários nós e não oferece um SLA (contrato de nível de serviço) para sua disponibilidade. Caches básicos são recomendados apenas para fins de desenvolvimento e teste. Use um cache Standard ou Premium para uma implantação de vários nós para aumentar a disponibilidade.

Explicação de um failover

Um failover ocorre quando um nó de réplica se promove a se tornar um nó primário, e o nó primário antigo fecha as conexões existentes. Depois que o nó primário volta, ele percebe a alteração nas funções e rebaixa a si mesmo para se tornar uma réplica. Em seguida, ele se conecta ao novo primário e sincroniza os dados. Um failover pode ser planejado ou não planejado.

Um failover planejado ocorre durante dois horários diferentes:

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

Como os nós recebem aviso antecipado da atualização, eles podem trocar funções de maneira cooperativa 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 ocorrer devido a falhas de hardware, falha de rede ou outras falhas inesperadas no nó primário. O nó de réplica se promove para primário, mas o processo leva mais tempo. Um nó de réplica deve primeiro detectar que seu nó primário não está disponível antes de iniciar o processo de failover. Para evitar um failover desnecessário, o nó de réplica também deve verificar se essa falha não planejada não é transitória ou local. Esse atraso na detecção significa que um failover não planejado normalmente termina dentro de 10 a 15 segundos.

Como a aplicação de patch ocorre?

O serviço Cache do Azure para Redis atualiza regularmente seu cache com os recursos e as correções mais recentes da plataforma. Para aplicar patch a um cache, o serviço segue estas etapas:

  1. O serviço aplica patch primeiro no nó de réplica.
  2. A réplica com patch se promove cooperativamente para primária. Essa promoção é considerada um failover planejado.
  3. O nó que era o primário anteriormente é reinicializado para realizar as novas alterações e retorna como um nó de réplica.
  4. O nó de réplica se conecta ao nó primário e sincroniza dados.
  5. Quando a sincronização de dados for concluída, o processo de a patch será repetido para os nós restantes.

Como a adoção de patch é um failover planejado, o nó de réplica se promove rapidamente para se tornar um primário. Em seguida, o nó começa a atender a solicitações e novas conexões. Os caches básicos não têm um nó de réplica e só ficam disponíveis quando a atualização é concluída. A aplicação de patch é feita separadamente a cada fragmento de um cache clusterizado, sem fechar conexões com outro fragmento.

Importante

O patch é aplicado a um nó por vez para evitar a perda de dados. Os caches básicos terão perda de dados. O patch é aplicado a um fragmento por vez em caches clusterizados.

Vários caches no mesmo grupo de recursos e região também recebem patch um por vez. Os caches que estão em diferentes grupos de recursos ou regiões diferentes podem receber patch simultaneamente.

Como a sincronização de dados completa ocorre antes que o processo se repita, é improvável que ocorra perda de dados quando você usa um cache Standard ou Premium. Você pode se proteger ainda mais contra a perda de dados exportando dados e habilitando a persistência.

Carga de cache adicional

Sempre que ocorrer um failover, os caches Standard e Premium precisarão replicar dados de um nó para 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 poderão receber exceções de tempo limite. Para ajudar a reduzir o efeito de mais carga, configure a definição maxmemory-reserved do cache.

Como um failover afeta meu aplicativo cliente?

Os aplicativos cliente podem receber alguns erros do Cache do Azure para Redis. O número de erros vistos por um aplicativo cliente depende de quantas operações estavam pendentes na conexão no momento do failover. Qualquer conexão roteada por meio do nó que fechou suas conexões verá erros.

Muitas bibliotecas de cliente podem mostrar 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 que ponto no caminho do código a solicitação está 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 ocorra com êxito.

A maioria das bibliotecas de cliente tenta se reconectar ao cache se elas estão configuradas para fazer isso. No entanto, bugs imprevistos ocasionalmente podem colocar os objetos de biblioteca em um estado irrecuperável. Se os erros persistirem por mais tempo do que uma quantidade de tempo pré-configurada, o objeto de conexão deverá ser recriado. No Microsoft.NET e em outras linguagens orientadas a objeto, é possível recriar a conexão sem reiniciar o aplicativo usando um padrão ForceReconnect.

Posso ser notificado antes de uma manutenção planejada?

O Cache do Azure para Redis publica notificações de manutenção de runtime em um canal de publicação/assinatura (pub/sub) chamado AzureRedisEvents. Muitas bibliotecas de clientes populares do Redis suportam a assinatura de canais pub/sub. Receber notificações do canal AzureRedisEvents geralmente é uma adição simples ao aplicativo cliente. Para obter mais informações sobre eventos de manutenção, consulte AzureRedisEvents.

Observação

O canal AzureRedisEvents não é um mecanismo que pode notificá-lo com dias ou horas de antecedência. O canal pode notificar os clientes sobre quaisquer eventos futuros de manutenção planejada do servidor que possam afetar a disponibilidade do servidor. AzureRedisEvents só está disponível para as camadas Básico, Standard e Premium.

Alterações de configuração de rede do cliente

Determinadas alterações de configuração de rede do lado do cliente podem disparar erros de "Nenhuma conexão disponível". Essas alterações podem incluir:

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

Essas alterações podem causar um problema de conectividade que dura menos de um minuto. Seu aplicativo cliente provavelmente perderá a conexão com outros recursos de rede externos, mas também com o serviço de Cache do Azure para Redis.

Resiliência de compilação

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

Como fazer tornar meu aplicativo resiliente?

Confira esses padrões de design para criar clientes resilientes, especialmente os padrões de disjuntor e de nova tentativa:

Para testar a resiliência de um aplicativo cliente, use uma reinicialização como um gatilho manual para quebras de conexão.

Além disso, recomendamos que você use atualizações agendadas para escolher um canal de atualização e uma janela de manutenção para seu cache a fim de aplicar patches de runtime do Redis durante janelas semanais específicas. Para evitar possíveis incidentes, normalmente essas janelas são períodos em que o tráfego do aplicativo cliente é baixo. Para obter mais informações, confira Atualizar um canal e agendar atualizações.

Para saber mais, confira Resiliência da conexão.

Conteúdo relacionado