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

Para construir aplicações de cliente resilientes e bem-sucedidas, é fundamental compreender o failover no Azure Managed Redisservice. Um failover pode fazer parte das operações de gerenciamento planejadas ou pode ser causado por falhas não planejadas de hardware ou rede. Uma utilização comum do failover de cache surge quando o serviço de gestão atualiza 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?

Comecemos com uma visão geral sobre o failover do Azure Managed 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 (ou "nó") executa vários processos de servidor Redis (chamados "shards") 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 aprofundados sobre a Arquitetura Azure Redis Gerida podem ser encontrados aqui.

Explicação de uma comutação por falha

Um failover ocorre quando um ou mais fragmentos de réplica são promovidos a fragmentos primários, e os fragmentos primários antigos fecham as conexõ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. Um failover planeado 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. Os fragmentos de réplica nos nós restantes serão promovidos a primários para manter a disponibilidade, mas o processo leva mais tempo. Primeiro, um fragmento de réplica deve detetar que o seu fragmento primário não está disponível antes de poder iniciar o processo de failover. 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 um processo de failover não planeado normalmente termina em 10 a 15 segundos.

Como ocorre a aplicação de patches?

O serviço Azure Managed Redis atualiza regularmente a sua cache com as funcionalidades 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. Todos os nós que estão a ser corrigidos são, um a um, 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.

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, as caches precisam replicar 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 um failover afeta a minha aplicação cliente?

As aplicações cliente podem receber alguns erros da sua instância 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 falha. Qualquer conexão encaminhada através do nó que fechou suas conexões apresentará 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 ocorre a ocorrência de failover pode obter uma exceção de timeout. 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. Na Microsoft.NET e noutras linguagens orientadas a objetos, recriar a ligação sem reiniciar a aplicação pode ser feito 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 alojamento e a atualização ou descomissionamento de componentes de rede.

O histórico de manutenção aparece no portal do Azure?

Para saber mais sobre o histórico de manutenção no portal Azure, consulte o Azure Activity log da sua instância de cache. O evento "healthevent" é emitido quando a manutenção começa.

Para receber notificações automaticamente, configure um alerta no registro de atividades.

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

Determinadas alterações na configuração da rede do lado do cliente podem desencadear erros de 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.
• Dimensionar o tamanho ou o 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. A tua aplicação cliente provavelmente perde a ligação a outros recursos de rede externos, mas também ao serviço Azure Managed Redis.

Incorporar resiliência

Não é possível evitar totalmente as comutações por erro. 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:

• Padrões de confiabilidade - Cloud Design Patterns
• Orientação para repetição de serviços Azure - Melhores práticas para aplicações na nuvem
• Implementar novas tentativas com backoff exponencial

Conteúdo relacionado

• Resiliência da ligação