Confiabilidade no Redis Gerenciado do Azure

O Redis Gerenciado do Azure fornece Redis Enterprise totalmente integrado e gerenciado no Azure, oferecendo armazenamento de dados na memória de alto desempenho para aplicativos. Esse serviço é criado para cargas de trabalho corporativas que exigem latência ultra baixa, alta taxa de transferência e estruturas de dados avançadas.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar 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 confiabilidade no Redis Gerenciado do Azure, incluindo resiliência a falhas transitórias, falhas de zona de disponibilidade e falhas em toda a região. O artigo também descreve as estratégias de backup e o SLA (contrato de nível de serviço).

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

Para garantir alta confiabilidade para suas instâncias redis gerenciadas do Azure de produção, recomendamos que você:

• Habilite a alta disponibilidade, que implanta vários nós para o cache.
• Habilite a redundância de zona implantando um cache altamente disponível em uma região com zonas de disponibilidade.
• Considere implementar a replicação geográfica ativa para cargas de trabalho críticas que exigem failover entre regiões.

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

O Redis Gerenciado do Azure é criado no Redis Enterprise e fornece confiabilidade por meio de configurações de alta disponibilidade e recursos de replicação.

Você implanta uma instância do Redis Gerenciado do Azure, que também é chamada de instância de cache ou cache. Seus aplicativos cliente armazenam e interagem com dados dentro do cache usando APIs Redis.

Arquitetura física

Há dois conceitos principais que você precisa entender ao planejar a resiliência para Redis Gerenciados do Azure: nós e fragmentos.

• 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 da instância, o monitoramento de integridade e a substituição de instâncias não íntegras. O conjunto de VMs, juntos, também é chamado de cluster.

  Você pode configurar sua instância para alta disponibilidade. Quando você faz isso, o Redis Gerenciado do Azure garante que haja pelo menos dois nós e replica os dados entre os nós automaticamente. Em regiões com zonas de disponibilidade, os nós são colocados em diferentes zonas de disponibilidade. Para obter mais informações, consulte Resiliência a falhas de zona de disponibilidade.

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

• Fragmentos: cada nó executa vários processos do servidor Redis chamados fragmentos, que gerenciam um subconjunto dos dados do seu cache. Quando o cache é configurado para alta disponibilidade, os fragmentos são automaticamente distribuídos e replicados entre os nós. Você especifica uma política de cluster, que determina como os fragmentos são distribuídos entre os nós.

Para obter mais informações, consulte Arquitetura do Azure Managed Redis e Failover e aplicação de patches para o Azure Managed Redis.

Resiliência a falhas transitórias

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

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

Siga estas recomendações para gerenciar falhas transitórias ao usar o Redis Gerenciado do Azure:

• Use configurações de SDK que repitam automaticamente quando ocorrem falhas transitórias e que usam períodos de retirada e tempo limite apropriados. Considere usar o padrão de tentativas e o padrão de Circuit Breaker em suas aplicações.
• Design para padrões de cache-aside onde seu aplicativo pode continuar operando com desempenho reduzido quando o Redis estiver temporariamente indisponível, recorrendo ao armazenamento de dados primário.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

As instâncias de cache Redis gerenciadas pelo Azure podem ser configuradas com redundância de zona, o que distribui automaticamente os nós de cache por várias zonas de disponibilidade dentro de uma região. A redundância de zona reduz o risco de que interrupções em data centers ou zonas de disponibilidade tornem o cache indisponível.

Para tornar um cache com redundância de zona, você deve implantá-lo em uma região com suporte e habilitar a 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 eles não estão em zonas separadas.

O diagrama a seguir mostra um cache com redundância de zona com dois nós, cada um em uma zona separada:

Requirements

• Suporte à região: Os caches Redis Gerenciados do Azure com redundância de zona podem ser implantados em qualquer região que dê suporte a zonas de disponibilidade e onde o serviço está disponível. Para obter a lista mais atual de regiões que dão suporte a zonas de disponibilidade, consulte as regiões do Azure com zonas de disponibilidade. Para obter a lista de regiões que dão suporte ao Redis Gerenciado do Azure, consulte a disponibilidade do produto por região.

• Configuração de alta disponibilidade: Você deve habilitar a configuração de alta disponibilidade em seu cache para que ela seja com redundância de zona.

• Camadas: todas as camadas do Redis Gerenciado do Azure dão suporte a zonas de disponibilidade.

Custo

A redundância de zona requer que o cache esteja configurado para alta disponibilidade, o que implanta um mínimo de dois nós para o cache. A configuração de alta disponibilidade é cobrada a uma taxa mais alta do que a configuração de disponibilidade não alta. Para obter mais informações, consulte os preços do Redis Gerenciado do Azure

Configurar o suporte à zona de disponibilidade

• Crie uma nova instância com redundância de zona: Ao criar uma nova instância do Redis Gerenciado do Azure, habilite a configuração de alta disponibilidade e implante-a em uma região com zonas de disponibilidade. Em seguida, ele inclui automaticamente a redundância de zona por padrão. Não é necessário executar mais nenhuma configuração.

  Para obter etapas detalhadas, consulte Início Rápido: Criar uma Instância Redis Gerenciada do Azure.

• Habilite a redundância de zona em uma instância existente: Para configurar uma instância redis gerenciada do Azure existente para ser com redundância de zona, verifique se ela está implantada em uma região que dá suporte a zonas de disponibilidade e habilite a alta disponibilidade no cache.

• Desabilitar redundância de zona: A redundância de zona não pode ser desabilitada em instâncias existentes, pois você não pode desabilitar a alta disponibilidade depois que ela estiver habilitada em uma instância de cache.

Planejamento e gerenciamento de capacidade

Durante um evento de redução de zona, sua instância pode ter menos recursos disponíveis para suprir suas necessidades de trabalho. Se sua instância estiver frequentemente sob pressão de recursos e você precisar se preparar para uma falha na zona de disponibilidade, considere uma das seguintes abordagens:

• Superprovisionar sua instância: O excesso de provisionamento envolve a seleção de uma camada de desempenho mais alta do que você pode exigir. Ele permite que sua instância tolere alguma perda de capacidade e continue funcionando sem desempenho degradado. Para obter mais informações sobre o princípio do excesso de provisionamento, consulte Gerenciar capacidade por excesso de provisionamento. Para saber como dimensionar sua instância, consulte Dimensionar uma instância do Redis Gerenciado do Azure.

• Use a replicação geográfica ativa: Você pode implantar várias instâncias em regiões diferentes e configurar a replicação geográfica ativa para espalhar sua carga entre essas instâncias separadas.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando um cache Redis gerenciado tem redundância de zona e todas as zonas de disponibilidade estão operacionais.

• Roteamento de tráfego entre zonas: os fragmentos são distribuídos entre os nós com base na política de cluster. Sua política de cluster também determina como o tráfego é roteado para cada nó. A redundância de zona não altera a forma como o tráfego é roteado.

• Replicação de dados entre zonas: os fragmentos são replicados entre nós automaticamente e usam replicação assíncrona. Normalmente, o atraso de replicação entre fragmentos é medido em segundos, mas isso pode variar dependendo da carga de trabalho do cache, com cenários pesados de gravação e de rede normalmente vendo um atraso de replicação maior.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando um cache Redis gerenciado é redundante em termos de zona e uma ou mais zonas de disponibilidade não estão operacionais:

• Detecção e resposta: O Redis Gerenciado do Azure é responsável por detectar uma falha em uma zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.

• Notificação: a Microsoft não notifica você 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 de problemas.

• Solicitações ativas: As solicitações em voo podem ser descartadas e devem ser repetidas. Os aplicativos devem implementar a lógica de repetição para lidar com essas interrupções temporárias.

• Perda de dados esperada: Todos os dados que não foram replicados em fragmentos em outra zona podem ser perdidos 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 esperado: uma pequena quantidade de tempo de inatividade, normalmente de 10 a 15 segundos, pode ocorrer enquanto fragmentos fazem failover para nós em zonas saudáveis. Para obter informações sobre o processo de failover não planejado, consulte Explicação de um failover Ao projetar aplicativos, siga as práticas de tratamento transitório de falhas.

• Redirecionamento de tráfego: o Redis Gerenciado do Azure redireciona automaticamente o tráfego para nós em zonas íntegras.

Recuperação de zona

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

Testar falhas em zonas

Como o Redis Gerenciado do Azure gerencia totalmente o roteamento de tráfego, o failover e o failback em caso de falhas em zonas de disponibilidade, você não precisa validar processos de falha em zonas de disponibilidade ou fornecer qualquer informação adicional.

Resiliência a falhas em toda a região

O Redis Gerenciado do Azure fornece suporte nativo de várias regiões por meio da replicação geográfica ativa, o que permite vincular várias instâncias redis gerenciadas do Azure em diferentes regiões do Azure em um único grupo de replicação. Em seguida, você pode configurar sua própria abordagem de failover entre as instâncias.

Replicação geográfica ativa

Quando você usa a replicação geográfica ativa, os aplicativos podem ler e gravar em qualquer instância de cache no grupo, com alterações sincronizadas automaticamente em todas as regiões. O serviço dá suporte a padrões de replicação ativo-ativos em que cada região pode lidar com operações de leitura e gravação simultaneamente. Quando ocorrem conflitos devido a gravações simultâneas em regiões diferentes, o serviço os resolve automaticamente usando algoritmos de resolução de conflitos predeterminados sem a necessidade de intervenção manual. Essa abordagem fornece resiliência a falhas de região, mantendo o acesso de baixa latência para aplicativos distribuídos globalmente.

O diagrama a seguir mostra duas instâncias de cache em regiões diferentes dentro do mesmo grupo de replicação geográfica ativa, com aplicativos cliente que se conectam a cada instância de cache:

Você é responsável por configurar seus aplicativos cliente para que, se qualquer instância regional falhar, eles possam redirecionar suas solicitações para uma instância íntegra. O diagrama a seguir mostra como um aplicativo pode redirecionar suas solicitações para uma instância de cache íntegra quando a instância que eles normalmente usam falhar:

Requirements

• Suporte à região A replicação geográfica ativa do Redis Gerenciado do Azure pode ser configurada entre qualquer região do Azure em que o serviço esteja disponível.

• Configuração da instância: A replicação geográfica ativa requer instâncias redis gerenciadas do Azure da mesma camada e tamanho em todas as regiões participantes. Todas as instâncias de cache em um grupo de replicação devem ser configuradas com configurações idênticas, incluindo opções de persistência, módulos e políticas de clustering.

• Outros requisitos: Suas instâncias de cache devem atender a outros requisitos, incluindo os módulos que você usa, e isso afeta como suas instâncias de cache podem ser dimensionadas. Para obter mais informações, consulte pré-requisitos de replicação geográfica ativa.

Considerações

• Responsabilidade de failover: Ao usar a replicação geográfica ativa, a responsabilidade pelo processo de failover entre as instâncias de cache é sua. Você deve preparar e configurar seu aplicativo para lidar com o failover. O failover envolve preparação e pode exigir a conclusão de várias etapas. Para obter mais informações, consulte Forçar-desvincular se houver uma interrupção de região.

• Consistência eventual: Os aplicativos devem ser projetados para lidar com cenários de consistência eventual, pois as alterações podem levar tempo para serem propagadas em todas as regiões, dependendo das condições de rede e da distância geográfica. Durante interrupções de região, você poderá experimentar mais inconsistências de dados até que a conectividade seja restaurada e a sincronização seja concluída.

Custo

Ao habilitar a replicação geográfica ativa, você é cobrado por cada instância do Redis Gerenciado do Azure em todas as regiões do grupo de replicação. Além disso, você pode incorrer em custos de transferência de dados para o tráfego de replicação entre regiões. Para obter mais informações sobre preços, consulte os preços do Redis Gerenciado do Azure e os detalhes de preços da largura de banda.

Configurar o suporte a várias regiões

• Crie uma nova instância de cache replicada geograficamente: configure a replicação geográfica ativa durante o provisionamento de cache especificando um grupo de replicação e vinculando várias instâncias. Para obter mais informações, consulte Criar ou ingressar em um grupo de replicação geográfica ativo.

• Habilitar uma instância de cache existente para replicação geográfica: você pode adicionar uma instância de cache existente a um grupo de replicação geográfica ativo.

  No entanto, quando uma instância existente é adicionada a um grupo de replicação geográfica ativa, os dados na instância precisam ser liberados e há uma pequena quantidade de tempo de inatividade. Se possível, planeje habilitar a replicação geográfica ativa ao criar instâncias de cache.

  Para obter mais informações, consulte Adicionar uma instância existente a um grupo de replicação geográfica ativo.

• Desabilite a replicação geográfica em uma instância de cache: remova uma instância de um grupo de replicação geográfica excluindo a instância de cache. As instâncias restantes se reconfiguram automaticamente.

Planejamento e gerenciamento de capacidade

Durante um evento de instabilidade regional, as outras instâncias podem ficar sob maior pressão. Se uma instância geralmente já estiver sob pressão de recursos e você precisar se preparar para o aumento dos requisitos de capacidade durante uma falha na região, considere o excesso de provisionamento da instância. Para saber como dimensionar uma instância, consulte Dimensionar uma instância do Redis Gerenciado do Azure.

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

Esta seção descreve o que esperar quando as instâncias são configuradas para usar a replicação geográfica ativa e todas as regiões estão operacionais.

• Roteamento de tráfego entre regiões: você é responsável por configurar seus aplicativos para se conectar a uma instância de cache específica. Os aplicativos podem se conectar a qualquer instância de cache no grupo de replicação e executar operações de leitura e gravação. O roteamento de tráfego é tratado pelo aplicativo, permitindo que você direcione os clientes para a região mais próxima para latência mínima. O Redis Gerenciado do Azure não fornece roteamento automático de tráfego entre regiões.

• Replicação de dados entre regiões: o serviço usa a replicação assíncrona entre regiões para manter a consistência eventual. As operações de gravação são confirmadas imediatamente na região local e, em seguida, propagadas para outras regiões em segundo plano. Os CRDTs (tipos de dados replicados sem conflito) garantem que as gravações simultâneas em regiões diferentes sejam mescladas automaticamente.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando as instâncias são configuradas para usar a replicação geográfica ativa e há uma interrupção em uma região:

• Detecção e resposta: você é responsável por detectar a falha de uma instância de cache e decidir quando fazer failover. Você pode monitorar a integridade de um cluster replicado geograficamente, o que pode ajudá-lo a decidir quando iniciar o failover. Para obter mais informações, consulte a métrica de replicação geográfica.

  O failover exige que você complete várias etapas. Para obter mais detalhes, consulte Desvinculação Forçada se houver uma falha na região.

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

  Você também pode monitorar a integridade de cada instância.

  Para monitorar a integridade da relação de replicação geográfica, você pode usar a métrica replicação geográfica saudável. A métrica sempre tem um valor de 1 (saudável) ou 0 (não saudável). Você pode configurar alertas do Azure Monitor nessa métrica para entender quando as instâncias podem estar fora de sincronia.

• Solicitações ativas: as solicitações para a região com falha são encerradas e devem ser tratadas pela lógica de failover do aplicativo. Os aplicativos devem implementar políticas de repetição que podem redirecionar o tráfego para caches íntegros.

• Perda de dados esperada: devido à replicação assíncrona entre regiões, algumas gravações recentes na região com falha poderão ser perdidas se ainda não tivessem sido replicadas para outras regiões. A quantidade de perda de dados potencial depende do atraso de replicação no momento da falha. Para obter mais informações, consulte Active-Active Redis distribuído geograficamente e considerações sobre consistência e perda de dados em uma falha regional do CRDB.

• Tempo de inatividade esperado: os aplicativos experimentam tempo de inatividade apenas pela duração necessária para detectar a falha e redirecionar o tráfego para regiões íntegras. Isso normalmente varia de segundos a alguns minutos, dependendo de como você configurou a configuração de failover e verificação de integridade do aplicativo.

• Redirecionamento de tráfego: você é responsável por implementar a lógica em seus aplicativos para detectar falhas na região e rotear o tráfego para regiões íntegras. Isso pode ser feito por meio de verificações de saúde do circuito, configurações de disjuntores ou soluções externas de balanceamento de carga.

Recuperação de região

Quando uma região com falha é recuperada, o Redis Gerenciado do Azure reintegra automaticamente instâncias nessa região no grupo de replicação geográfica ativo sem a necessidade de intervenção. O serviço sincroniza automaticamente dados de instâncias saudáveis. Durante esse processo, a instância recuperada gradualmente se atualiza em relação às alterações ocorridas durante a interrupção. Depois que a sincronização for concluída, as instâncias recuperadas se tornarão totalmente ativas e poderão lidar com operações de leitura e gravação.

Você é responsável por reconfigurar seu aplicativo para rotear o tráfego de volta para a instância de região recuperada.

Teste de falhas na região

Você deve testar regularmente os procedimentos de failover do aplicativo. É importante que seu aplicativo possa realizar failover entre instâncias e que o tempo de inatividade durante esse processo permaneça dentro dos requisitos de negócios. Também é importante que você teste seus processos gerais de resposta, incluindo qualquer reconfiguração de firewalls e outras infraestruturas, e seu processo de recuperação.

Resiliência à manutenção do serviço

O Redis Gerenciado do Azure executa atualizações de serviço regulares e outras tarefas de manutenção.

Quando a manutenção está em andamento, o Redis Gerenciado do Azure cria novos nós e realiza o failover automaticamente. Os aplicativos cliente podem ver interrupções de conexã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 Redis Gerenciado do Azure, consulte Failover e aplicação de patches para o Azure Managed Redis.

Backup e restauração

O Redis Gerenciado do Azure fornece recursos de persistência de dados e backup para proteger contra cenários de perda de dados que outros recursos de confiabilidade podem não resolver. Os backups podem fornecer proteção contra cenários como corrupção de dados, exclusão acidental ou erros de configuração.

• Persistência de dados: Por padrão, o Redis Gerenciado do Azure armazena todos os dados de cache na memória. Opcionalmente, ele pode gravar instantâneos de seus dados no disco usando persistência de dados. Se ocorrer uma falha de hardware que afete o nó, o Azure Managed Redis restaura os dados automaticamente. Existem diferentes tipos de persistência de dados que você pode selecionar, os quais oferecem diferentes equilíbrios entre a frequência de criação de snapshots e os efeitos no desempenho do seu cache.

  No entanto, os arquivos de dados não podem ser restaurados para outra instância e você não pode acessar os arquivos. A persistência de dados não o protege contra corrupção de dados ou exclusão acidental.

• Importar e exportar: O Redis Gerenciado do Azure dá suporte ao backup de seus dados usando a funcionalidade de importação e exportação, que salva arquivos de backup no Armazenamento de Blobs do Azure. Você pode configurar o armazenamento com redundância geográfica em sua conta de Armazenamento do Azure ou copiar ou mover os blobs de backup para outros locais para proteção adicional.

  Os arquivos exportados podem ser restaurados para a mesma instância de cache ou uma instância de cache diferente.

  Não há um agendador de importação ou exportação interno, mas você pode desenvolver 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 acordo de nível de serviço (SLA) dos serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para alcançar essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

O SLA para o Azure Managed Redis cobre a conectividade com os pontos de extremidade de cache. O SLA não abrange a proteção contra perda de dados.

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

• Você deve habilitar a configuração de alta disponibilidade.
• Você não deve iniciar nenhum recurso de produto ou ações de gerenciamento documentadas para produzir indisponibilidade temporária.

SLAs de maior disponibilidade se aplicam quando sua instância é redundante entre zonas. Em algumas camadas, você pode ser qualificado para um SLA de maior disponibilidade quando tiver implantado instâncias com redundância de zona em pelo menos três regiões usando a replicação geográfica ativa.