Compartilhar via

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

  • Aplica-se a: ✅ Azure Cache for Redis

Importante

O Cache do Azure para Redis anunciou a linha do tempo de desativação para todos os SKUs. Recomendamos migrar suas instâncias do Cache do Azure para Redis para o Redis Gerenciado pelo Azure assim que possível.

Para obter mais detalhes sobre a aposentadoria:

Para criar aplicativos cliente resilientes e bem-sucedidos, é fundamental entender o failover no serviço cache do Azure para Redis. Um failover pode fazer parte das operações de gerenciamento planejadas ou pode 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 ocorre o failover durante a atualizaçã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 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 separados e privados. Cada máquina virtual, também conhecida como nó, está conectada a um balanceador de carga compartilhado com um único 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 como um nó primário ou um nó 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 primário e o outro é a réplica. Como os caches Standard e Premium têm vários nós, um nó pode ficar indisponível enquanto o outro continua a processar solicitações. Os caches clusterizados são feitos de muitos fragmentos, cada um com nós primários e de réplica distintos. Um fragmento pode estar inoperante 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. Os 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 dados. Um failover pode ser planejado ou não planejado.

Um failover planejado ocorre durante dois horários diferentes:

  • Atualizações do sistema, como patch do 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 de forma cooperativa e atualizar rapidamente o balanceador de carga da alteração. Um failover planejado normalmente termina em menos de um segundo.

Um failover não planejado pode acontecer devido a falha de hardware, falha de rede ou outras interrupções 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 precisa 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 é concluído dentro de 10 a 15 segundos.

Como ocorre a aplicação de patch?

O serviço cache do Azure para Redis 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 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ó primário anterior é reinicializado para fazer as novas alterações e volta 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 é concluída, o processo de aplicação de patch se repete 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 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. Cada fragmento de um cache clusterizado é corrigido separadamente e não fecha 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. Os caches em cluster são corrigidos um fragmento de cada vez.

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

Como a sincronização completa de dados ocorre antes da repetição do processo, é improvável que a perda de dados ocorra quando você usa um cache Standard ou Premium. Você pode 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, aplicativos cliente podem receber exceções de timeout. Para ajudar a atenuar o efeito de mais carga, defina a configuração do maxmemory-reserved 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 nessa conexão no momento do failover. Qualquer conexão roteada por meio do nó que fechou suas conexões apresentará erros.

Muitas bibliotecas de clientes podem gerar 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 ocorra com êxito.

A maioria das bibliotecas de clientes tentará se reconectar ao cache se estiver configurada para fazer 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 pré-configurado, o objeto de conexão deverá ser recriado. Em Microsoft.NET e em outras linguagens orientadas a objetos, recriar a conexão sem reiniciar o aplicativo pode ser feito usando um padrão ForceReconnect.

Posso ser notificado antes da manutenção?

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

Observação

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

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 da VM (máquina virtual): todas as 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, a atualização de componentes de rede ou a desativação de recursos.

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 nenhum lugar sob a integridade do serviço no portal ou em qualquer outro local.

Quanto tempo posso receber a notificação antes da manutenção planejada?

Ao usar o AzureRedisEvents canal, você é notificado 15 minutos antes da manutenção.

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:

  • Alternando o endereço IP virtual de um aplicativo cliente entre slots de teste e produção.
  • Dimensionando o tamanho ou o 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 externos, mas também com o serviço cache do Azure para Redis.

Criar resiliência

Você não pode evitar os 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 clientes se reconecta automaticamente ao endpoint de cache, mas poucas delas tentam repetir solicitações que falharam. Dependendo do cenário de aplicativo, pode fazer sentido usar a lógica de repetição com o backoff.

Como faço para 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 que seu cache possa aplicar patches de runtime do Redis durante janelas semanais específicas. Normalmente, essas janelas são períodos em que o tráfego do aplicativo cliente é baixo, para evitar possíveis incidentes. Para obter mais informações, consulte Atualizar o canal e agendar atualizações.

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

Conteúdo relacionado

  • Last updated on