Partilhar via

Ativação pós-falha e aplicação de patches para o Azure Managed Redis (pré-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 uma ativação pós-falha

Um ativação pós-falha ocorre quando um ou mais fragmentos de réplica se promovem para se tornarem fragmentos primários e os fragmentos primários antigos fecham as ligações existentes. Um failover pode ser planejado ou não.

Um failover planejado ocorre durante dois momentos diferentes:

  • Atualizações do sistema, como a aplicação de patches do Redis ou atualizações do SO.
  • Operações de gestão, tais como dimensionamento e reinicialização.

Uma vez que os nós recebem um aviso prévio da atualização, podem trocar de funções de forma cooperativa e atualizar rapidamente o balanceador de carga sobre a alteração. Uma ativação pós-falha planeada 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 a primário para manter a disponibilidade, mas o processo demora mais tempo. Um fragmento de réplica tem de detetar primeiro que o fragmento primário não está disponível antes de poder iniciar o processo de ativação pós-falha. O fragmento de réplica também deve verificar se esta falha não planeada não é transitória ou local, para evitar uma ativação pós-falha desnecessária. Este atraso na deteção significa que uma ativação pós-falha não planeada termina normalmente num período 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 uma ativação pós-falha ocorre, as caches precisam de replicar os dados de um nó para o outro. Esta 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, as aplicações cliente podem apresentar um aumento da latência. Em casos extremos, as aplicações cliente podem receber exceções de tempo limite.

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

As aplicações cliente podem receber alguns erros da sua instância do Azure Managed Redis. O número de erros registados por uma aplicação cliente depende de quantas operações estavam pendentes nessa ligação no momento da ativação pós-falha. Qualquer ligação encaminhada através do nó que fechou as respetivas ligações verá erros.

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

  • Exceções de tempo limite
  • Exceções de ligaçã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 envie um pedido mas não tenha recebido uma resposta quando a ativação pós-falha ocorre pode obter uma exceção de tempo limite. Os novos pedidos no objeto da ligação fechada recebem exceções de ligação até que o restabelecimento da ligação seja bem sucedido.

A maioria das bibliotecas de cliente tentam restabelecer a ligação à cache se estiverem configuradas para tal. No entanto, erros imprevistos podem ocasionalmente colocar os objetos da biblioteca num estado irrecuperável. Se os erros persistirem durante mais tempo do que um período de tempo pré-configurado, o objeto da ligação tem de ser recriado. No Microsoft.NET e noutras linguagens orientadas para objetos, a recriação da ligação sem reiniciar a aplicação pode ser realizada utilizando 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 . Estas alterações podem incluir:

  • Troca do endereço IP virtual de uma aplicação cliente entre os blocos de teste e produção.
  • Dimensionamento do tamanho ou do número de instâncias da sua aplicação.

Estas alterações podem causar um problema de conectividade que, normalmente, dura menos de um minuto. Provavelmente, a sua aplicação cliente perde a ligação a outros recursos de rede externos, mas também ao serviço do Azure Managed Redis.

Resiliência integrada

Não é possível evitar completamente as ativações pós-falha. Em vez disso, escreve as suas aplicações cliente para serem resistentes a quebras de ligação e pedidos falhados. A maioria das bibliotecas de cliente restabelece automaticamente a ligação ao ponto final da cache, mas poucas tentam repetir pedidos falhados. Dependendo do cenário da aplicação, pode fazer sentido utilizar a lógica de repetição com recuo.

Como posso tornar a minha aplicação resiliente?

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

Conteúdos relacionados