Partilhar via

Ativação pós-falha e aplicação de patches – Cache de Redis do Azure

  • Artigo

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 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 Cache do Azure para 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 do Cache do Azure para Redis.

Um resumo rápido da arquitetura de cache

Um cache é construído de várias máquinas virtuais com endereços IP separados e privados. Cada máquina virtual, também conhecida como nó, é 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 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 é automaticamente roteado para o nó primário.

Em um cache Básico, o nó único é sempre um principal. Em um cache Standard ou Premium, há dois nós: um é escolhido como o principal e o outro é a réplica. Como os caches Standard e Premium têm vários nós, um nó pode estar indisponível enquanto o outro continua a processar solicitações. Os caches agrupados são feitos de 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.

Nota

Um cache básico não tem vários nós e não oferece um contrato de nível de serviço (SLA) 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 para se tornar um nó primário e o nó primário antigo fecha conexões existentes. Depois que o nó primário volta a subir, ele percebe a mudança nas funções e se rebaixa 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.

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 no nó principal. O nó de réplica se promove como primário, mas o processo leva mais tempo. Um nó de réplica deve primeiro detetar que seu nó primário não está disponível antes de iniciar o processo de failover. O nó 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 Cache Redis 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 corrige o nó da réplica primeiro.
  2. A réplica remendada cooperativamente se promove a primária. Esta promoção é considerada um failover planejado.
  3. O nó primário anterior é reinicializado para receber 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 os dados.
  5. Quando a sincronização de dados estiver concluída, o processo de aplicação de patches se repete para os nós restantes.

Como a aplicação de patches é um failover planejado, o nó da réplica rapidamente se promove para se tornar um principal. 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 não estão disponíveis até que a atualização seja concluída. Cada fragmento de um cache clusterizado é corrigido separadamente e não fecha conexões com outro fragmento.

Importante

Os nós são corrigidos um de cada vez para evitar a perda de dados. Os caches básicos terão perda de dados. Os caches clusterizados 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. 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 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 ocorre um failover, os caches Standard e Premium 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. Para ajudar a atenuar o efeito de mais carga, defina a configuração do maxmemory-reserved cache.

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

Os aplicativos cliente podem receber alguns erros de seu 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 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.

Posso ser notificado com antecedência da manutenção?

O Cache Redis do Azure publica notificações de manutenção de tempo de execução em um canal de publicação/assinatura (pub/sub) chamado AzureRedisEvents. Muitas bibliotecas de clientes Redis populares suportam a 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.

Nota

O AzureRedisEvents canal 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 do servidor que possam afetar a disponibilidade do servidor. AzureRedisEvents está disponível apenas para os níveis 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 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 nenhum lugar sob a integridade do serviço no portal ou em qualquer outro lugar.

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

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

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 Cache do Azure para 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:

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 para aplicar patches de tempo de execução do Redis durante janelas semanais específicas. Essas janelas geralmente 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 canal e Agendar atualizações.

Para obter mais informações, consulte Resiliência de conexão.

Conteúdos relacionados