Confiabilidade no Redis Gerido do Azure

O Azure Managed Redis oferece o Redis Enterprise totalmente integrado e gerido no Azure, oferecendo armazenamento de dados em memória de alto desempenho para aplicações. Este serviço foi concebido para cargas de trabalho empresariais que requerem latência ultra-baixa, alto débito e estruturas de dados avançadas.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve a fiabilidade no Azure Managed Redis, incluindo a resiliência a falhas transitórias, falhas em zonas de disponibilidade e falhas regionais. O artigo também descreve estratégias de backup e o acordo de nível de serviço (SLA).

Recomendações de implantação de produção

Para garantir uma elevada fiabilidade para as suas instâncias Azure Managed Redis de produção, recomendamos que:

Visão geral da arquitetura de confiabilidade

Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.

Arquitetura lógica

O Azure Managed Redis é construído sobre o Redis Enterprise e oferece fiabilidade através de configurações de alta disponibilidade e capacidades de replicação.

Implementas uma instância do Azure Managed Redis, que também é chamada de instância de cache ou de cache. As suas aplicações clientes armazenam e interagem com dados dentro da cache usando APIs Redis.

Arquitetura física

Existem dois conceitos-chave que precisa de compreender ao planear a resiliência do Azure Managed Redis: nós e partições.

• Nós: Cada instância de cache consiste em nós, que são máquinas virtuais (VMs). Cada VM serve como uma unidade de computação independente no cluster. Você não vê nem gerencia as VMs diretamente. A plataforma gerencia automaticamente a criação de instâncias, o monitoramento de integridade e a substituição de instâncias não íntegras. O conjunto de VMs, em conjunto, também é chamado de cluster.

  Podes configurar a tua instância para alta disponibilidade. Quando o fazes, o Azure Managed Redis garante que existem pelo menos dois nós e replica automaticamente os dados entre os nós. Em regiões com zonas de disponibilidade, os nós são colocados em diferentes zonas de disponibilidade. Para mais informações, veja Resiliência a falhas em zonas de disponibilidade.

  O serviço abstrai o número específico de nós usados em cada configuração para evitar complexidade e garantir configurações ótimas.

• Shards: Cada nó executa múltiplos processos de servidor Redis chamados shards, que gerem um subconjunto dos dados da sua cache. Quando a sua cache está configurada para alta disponibilidade, os fragmentos são automaticamente distribuídos e replicados entre nós. Especificas uma política de cluster, que determina como os shards são distribuídos entre nós.

Para mais informações, consulte Arquitetura do Azure Managed Redis e Failover e Patching do Azure Managed Redis.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Siga estas recomendações para gerir falhas transitórias ao utilizar o Azure Managed Redis:

• Use configurações de SDK que tentem automaticamente quando ocorrem falhas transitórias e que utilizem períodos de backoff e timeout apropriados. Considere usar o padrão Retry e o padrão Circuit Breaker nas suas aplicações.
• Projete padrões de cache-aside, onde a sua aplicação possa continuar a operar com desempenho degradado quando o Redis estiver temporariamente indisponível, recorrendo à base de dados principal.

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

As instâncias de cache Azure Managed Redis podem ser tornadas redundantes por zona, o que distribui automaticamente os nós de cache por múltiplas zonas de disponibilidade dentro de uma região. A redundância de zonas reduz o risco de falhas em centros de dados ou zonas de disponibilidade que tornem a sua cache indisponível.

Para tornar uma zona de cache redundante, deve implementá-la numa região suportada e ativar uma configuração de alta disponibilidade. Em regiões sem zonas de disponibilidade, a configuração de alta disponibilidade ainda cria pelo menos dois nós, mas não estão em zonas separadas.

O diagrama seguinte mostra uma cache redundante de zona com dois nós, cada um numa zona separada:

Requerimentos

• Apoio regional: Caches Azure Managed Redis redundantes de zona podem ser implementadas em qualquer região que suporte zonas de disponibilidade e onde o serviço esteja disponível. Para a lista mais recente de regiões que suportam zonas de disponibilidade, consulte regiões Azure com zonas de disponibilidade. Para a lista de regiões que suportam Azure Managed Redis, consulte disponibilidade de produtos por região.

• Configuração de alta disponibilidade: Tens de ativar a configuração de alta disponibilidade na tua cache para que fique redundante em zona.

• Níveis: Todos os níveis Azure Managed Redis suportam zonas de disponibilidade.

Custo

A redundância de zonas exige que a cache esteja configurada para alta disponibilidade, o que implementa pelo menos dois nós para a cache. A configuração de alta disponibilidade é faturada a uma taxa superior à configuração sem alta disponibilidade. Para mais informações, consulte preços Azure Managed Redis

Configurar o suporte à zona de disponibilidade

• Crie uma nova instância redundante de zona: Quando criar uma nova instância Azure Managed Redis, ative a configuração de alta disponibilidade e implemente-a numa região com zonas de disponibilidade. Depois, inclui automaticamente redundância de zonas por padrão. Não há necessidade de realizar mais nenhuma configuração.

  Para passos detalhados, consulte Quickstart: Criar uma Instância Redis Gerida Azure.

• Ative a redundância de zona numa instância existente: Para configurar uma instância Azure Managed Redis existente para ser redundante em zona, certifique-se de que está implementada numa região que suporta zonas de disponibilidade e ative alta disponibilidade na cache.

• Desativar a redundância de zonas: A redundância de zonas não pode ser desativada nas instâncias existentes, porque não se pode desativar a alta disponibilidade depois de estar ativada numa instância de cache.

Planejamento e gerenciamento de capacidade

Durante um evento zone-down, a sua instância pode ter menos recursos disponíveis para satisfazer a sua carga de trabalho. Se a sua instância está frequentemente sob pressão de recursos e precisa de se preparar para falhas na zona de disponibilidade, considere uma das seguintes abordagens:

• Sobreaprovisionamento da sua instância: O sobreabastecimento envolve a seleção de um nível de desempenho superior ao que pode ser necessário. Permite que a sua instância tolere alguma perda de capacidade e continue a funcionar sem desempenho degradado. Para mais informações sobre o princípio do sobreprovisionamento, veja Gerir capacidade por sobreprovisionamento. Para saber como escalar a sua instância, consulte Escalar uma instância Azure Managed Redis.

• Use geo-replicação ativa: Pode implementar múltiplas instâncias em diferentes regiões e configurar a geo-replicação ativa para distribuir a sua carga entre essas instâncias separadas.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando um cache Redis gerido é redundante em zona e todas as zonas de disponibilidade estão operacionais:

• Encaminhamento do tráfego entre zonas: Os fragmentos são distribuídos entre nós com base na sua política de cluster. A sua política de cluster também determina como o tráfego é encaminhado para cada nó. A redundância de zonas não altera a forma como o tráfego é encaminhado.

• Replicação de dados entre zonas: Os fragmentos são replicados automaticamente entre nós e utilizam replicação assíncrona. Normalmente, o atraso de replicação entre shards é medido em segundos, mas isso pode variar consoante a carga de trabalho da cache, sendo que cenários com maior escrita e rede apresentam um atraso de replicação mais elevado.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando uma cache Redis gerida é redundante em zona e uma ou mais zonas de disponibilidade não estão disponíveis:

• Deteção e resposta: O Azure Managed Redis é responsável por detetar uma falha numa zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.

• Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Integridade do Serviço para notificá-lo sobre problemas.

• Pedidos ativos: Pedidos em curso podem ser descartados e devem ser reiniciados. Os aplicativos devem implementar a lógica de repetição para lidar com essas interrupções temporárias.

• Perda de dados esperada: Qualquer dado que não tenha sido replicado para fragmentos noutra zona pode ser perdido durante uma falha de zona. Normalmente, a quantidade de perda de dados é medida em segundos, mas depende do atraso de replicação.

• Tempo de inatividade previsto: Pode ocorrer um pequeno período de inatividade, tipicamente 10-15 segundos, enquanto os fragmentos passam para nós em zonas saudáveis. Para informações sobre o processo de failover imprevisto, veja Explicação de um failover. Quando projeta aplicações, siga práticas para o tratamento de falhas transitórias.

• Redirecionamento de tráfego: O Azure Managed Redis redireciona automaticamente o tráfego para nós em zonas funcionais.

Recuperação de zona

Quando a zona de disponibilidade afetada recupera, o Azure Managed Redis restaura automaticamente as operações nessa zona. A plataforma Azure gerencia totalmente esse processo e não requer nenhuma intervenção do cliente.

Teste de falhas de zona

Como o Azure Managed Redis gere totalmente o encaminhamento de tráfego, o failover e o failback para falhas de zona, não precisa de validar os processos de falha de zonas de disponibilidade nem fornecer qualquer input adicional.

Resiliência a falhas em toda a região

O Azure Managed Redis oferece suporte nativo multi-região através de geo-replicação ativa, o que permite ligar múltiplas instâncias Azure Managed Redis entre diferentes regiões Azure num único grupo de replicação. Pode então configurar a sua própria abordagem de failover entre as instâncias.

Replicação geográfica ativa

Quando se usa geo-replicação ativa, as aplicações podem ler e escrever em qualquer instância de cache do grupo, com alterações sincronizadas automaticamente em todas as regiões. O serviço suporta padrões de replicação ativo-ativo, nos quais cada região pode executar simultaneamente operações de leitura e escrita. Quando ocorrem conflitos devido a escritas concorrentes em diferentes regiões, o serviço resolve-os automaticamente usando algoritmos pré-determinados de resolução de conflitos, sem necessidade de intervenção manual. Esta abordagem proporciona resiliência a falhas regionais, mantendo ao mesmo tempo um acesso de baixa latência para aplicações distribuídas globalmente.

O diagrama seguinte mostra duas instâncias de cache em diferentes regiões dentro do mesmo grupo ativo de geo-replicação, com aplicações clientes que se ligam a cada instância de cache:

És responsável por configurar as tuas aplicações clientes para que, se alguma instância regional falhar, possam redirecionar os seus pedidos para uma instância saudável. O diagrama seguinte mostra como uma aplicação pode redirecionar os seus pedidos para uma instância de cache saudável quando a instância que normalmente utiliza falha:

Requerimentos

• Apoio regional A geo-replicação ativa do Azure Managed Redis pode ser configurada entre quaisquer regiões Azure onde o serviço esteja disponível.

• Configuração da instância: A geo-replicação ativa requer instâncias Azure Managed Redis do mesmo nível e tamanho em todas as regiões participantes. Todas as instâncias de cache num grupo de replicação devem ser configuradas com definições idênticas, incluindo opções de persistência, módulos e políticas de clustering.

• Outros requisitos: As suas instâncias de cache devem cumprir outros requisitos, incluindo os módulos que utiliza, e isso afeta a forma como as suas instâncias de cache podem ser escaladas. Para mais informações, consulte Pré-requisitos de Geo-replicação Ativa.

Considerações

• Responsabilidade por falha automática: Quando usas geo-replicação ativa, és responsável pela falha automática entre instâncias de cache. Deves preparar e configurar a tua aplicação para lidar com failover. O failover envolve preparação e pode exigir que complete várias etapas. Para mais informações, consulte Force-unlink se houver uma falha de região.

• Consistência eventual: As aplicações devem ser concebidas para lidar com cenários de consistência eventuales, pois as alterações podem demorar tempo a propagar-se por todas as regiões, dependendo das condições da rede e da distância geográfica. Durante interrupções regionais, pode experienciar mais inconsistências de dados até que a conectividade seja restabelecida e a sincronização conclua.

Custo

Ao ativar a geo-replicação, é cobrado por cada instância do Azure Managed Redis em todas as regiões do grupo de replicação. Além disso, pode incorrer em custos de transferência de dados pelo tráfego de replicação entre regiões. Para mais informações sobre preços, veja os preços de Azure Managed Redis e os detalhes dos preços de largura de banda.

Configurar suporte a várias regiões

• Crie uma nova instância de cache geo-replicada: Configure a geo-replicação ativa durante o provisionamento da cache, especificando um grupo de replicação e ligando múltiplas instâncias. Para mais informações, consulte Criar ou juntar-se a um grupo ativo de geo-replicação.

• Ativar uma instância de cache existente para geo-replicação: Pode adicionar uma instância de cache existente a um grupo ativo de geo-replicação.

  No entanto, quando uma instância existente é adicionada a um grupo ativo de geo-replicação, os dados da instância precisam de ser esvaziados e há um pequeno período de inatividade. Se possível, planeie ativar a geo-replicação ativa ao criar instâncias de cache.

  Para mais informações, consulte Adicionar uma instância existente a um grupo ativo de geo-replicação.

• Desativar a geo-replicação numa instância de cache: Remover uma instância de um grupo de geo-replicação eliminando a instância de cache. As restantes instâncias reconfiguram-se automaticamente.

Planejamento e gerenciamento de capacidade

Durante um evento region-down, as outras situações podem estar sob maior pressão. Se uma instância já estiver frequentemente sob pressão de recursos e precisar de se preparar para o aumento das necessidades de capacidade durante uma falha de região, considere sobreabastecer a instância. Para aprender a escalar uma instância, consulte Escalar uma instância Azure Managed Redis.

Comportamento quando todas as regiões estão saudáveis

Esta secção descreve o que esperar quando as instâncias são configuradas para usar geo-replicação ativa e todas as regiões estão operacionais.

• Encaminhamento de tráfego entre regiões: És responsável por configurar as tuas aplicações para se ligarem a uma instância de cache específica. As aplicações podem ligar-se a qualquer instância de cache no grupo de replicação e realizar tanto operações de leitura como de escrita. O encaminhamento do tráfego é gerido pela aplicação, permitindo-lhe direcionar os clientes para a região mais próxima com latência mínima. O Azure Managed Redis não fornece encaminhamento automático de tráfego entre regiões.

• Replicação de dados entre regiões: O serviço utiliza replicação assíncrona entre regiões para manter a consistência eventual. As operações de escrita são aplicadas imediatamente na região local e depois são disseminadas para outras regiões em segundo plano. Os tipos de dados replicados sem conflito (CRDTs) garantem que as escritas concorrentes em diferentes regiões são automaticamente fundidas.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando as instâncias são configuradas para usar geo-replicação ativa e há uma falha numa região:

• Deteção e resposta: És responsável por detetar a falha de uma instância de cache e decidir quando fazer failover. Pode monitorizar a saúde de um cluster geo-replicado, o que pode ajudá-lo a decidir quando iniciar o failover. Para mais informações, veja Métrica de Geo-replicação.

  O failover exige que realize vários passos. Para mais detalhes, consulte Force-unlink se houver uma falha de região.

• Notificação: A Microsoft não notifica automaticamente quando uma região está fora de serviço. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

  Também pode monitorizar a saúde de cada instância.

  Para monitorizar a saúde da relação de geo-replicação, pode usar a métrica Geo-replication healthy. A métrica tem sempre um valor de 1 (saudável) ou 0 (não saudável). Pode configurar alertas do Azure Monitor nesta métrica para perceber quando as instâncias podem estar fora de sincronização.

• Pedidos ativos: Os pedidos para a região falhada são terminados e devem ser tratados pela lógica de failover da sua aplicação. As aplicações devem implementar políticas de tentativas que possam redirecionar o tráfego para caches funcionais.

• Perda de dados esperada: Devido à replicação assíncrona entre regiões, algumas escritas recentes na região falhada podem ser perdidas se ainda não tivessem sido replicadas para outras regiões. A quantidade potencial de perda de dados depende do atraso de replicação no momento da falha. Para mais informações, consulte Active-Active Redis geo-distribuído e Considerações sobre Consistência e Perda de Dados em caso de Falha Regional no CRDB.

• Tempo de inatividade esperado: As aplicações experienciam apenas o tempo de inatividade necessário para detetar a falha e redirecionar o tráfego para regiões saudáveis. Isto normalmente varia entre segundos e alguns minutos, dependendo de como configurou a verificação de saúde e a configuração de failover da sua aplicação.

• Redirecionamento de tráfego: É responsável por implementar lógica nas suas aplicações para detetar falhas de região e encaminhar o tráfego para regiões saudáveis. Isto pode ser conseguido através de verificações de saúde, padrões de disjuntores ou soluções externas de balanceamento de carga.

Recuperação da região

Quando uma região falhada recupera, o Azure Managed Redis reintegra automaticamente as instâncias dessa região no grupo ativo de geo-replicação sem necessidade da sua intervenção. O serviço sincroniza automaticamente dados de instâncias saudáveis. Durante este processo, a instância recuperada vai gradualmente acompanhando as alterações ocorridas durante a interrupção. Uma vez concluída a sincronização, as instâncias recuperadas tornam-se totalmente ativas e podem gerir tanto operações de leitura como de escrita.

És responsável por reconfigurar a tua aplicação para encaminhar o tráfego de volta para a instância da região recuperada.

Teste para falhas regionais

Deve testar regularmente os procedimentos de failover da sua aplicação. É importante que a sua aplicação possa fazer failover entre instâncias e que se mantenha dentro dos requisitos do seu negócio para o tempo de inatividade enquanto o faz. Também é importante que teste os seus processos gerais de resposta, incluindo qualquer reconfiguração de firewalls e outras infraestruturas, bem como o seu processo de recuperação.

Resiliência à manutenção de serviços

O Azure Managed Redis realiza atualizações regulares de serviço e outras tarefas de manutenção.

Quando a manutenção está em curso, o Azure Managed Redis executa automaticamente a criação de novos nós e faz o failover automaticamente. As aplicações cliente podem registar interrupções de ligação e outras falhas transitórias. Os aplicativos devem implementar a lógica de repetição para lidar com essas interrupções temporárias.

Para saber mais sobre os processos de manutenção do Azure Managed Redis, consulte Failover e correção para Azure Managed Redis.

Backup e restauração

O Azure Managed Redis oferece tanto persistência de dados como capacidades de backup para proteger contra cenários de perda de dados que outras funcionalidades de fiabilidade podem não resolver. Os backups podem fornecer proteção contra cenários como corrupção de dados, eliminação acidental ou erros de configuração.

• Persistência dos dados: Por defeito, o Azure Managed Redis armazena todos os dados de cache na memória. Pode, opcionalmente, gravar snapshots dos seus dados em disco usando persistência de dados. Se houver uma falha de hardware que afete o nó, o Azure Managed Redis restaura automaticamente os dados. Existem diferentes tipos de persistência de dados que pode escolher, que oferecem diferentes compensações entre a frequência dos snapshots e os efeitos de desempenho na sua cache.

  No entanto, os ficheiros de dados não podem ser restaurados para outra instância, e não se pode aceder aos ficheiros. A persistência de dados não o protege contra corrupção de dados ou eliminação acidental.

• Importação e exportação: O Azure Managed Redis suporta backup dos seus dados utilizando a funcionalidade de importação e exportação, que guarda ficheiros de backup para o Azure Blob Storage. Pode configurar armazenamento geo-redundante na sua conta Azure Storage, ou pode copiar ou mover os blobs de backup para outros locais para maior proteção.

  Os ficheiros exportados podem ser restaurados na mesma instância de cache ou numa instância de cache diferente.

  Não existe um agendador de importação ou exportação incorporado, mas pode desenvolver os seus próprios processos de automação que usam a CLI do Azure ou o Azure PowerShell para iniciar operações de exportação.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.

O SLA para o Azure Managed Redis cobre a conectividade aos endpoints de cache. O SLA não cobre a proteção contra perda de dados.

Para ser elegível para SLAs de disponibilidade para Azure Managed Redis:

• Deve ativar a configuração de alta disponibilidade.
• Não deve iniciar quaisquer funcionalidades do produto ou ações de gestão que estejam documentadas para causar indisponibilidade temporária.

SLAs de maior disponibilidade aplicam-se quando a sua instância é redundante por zona. Em alguns níveis, pode ser elegível para um SLA de disponibilidade mais elevada quando tiver implementado instâncias redundantes entre zonas em pelo menos três regiões usando geo-replicação ativa.