Alta disponibilidade e recuperação de desastre

Assim como acontece com qualquer sistema de nuvem, podem ocorrer paralisações não planejadas que resultam em uma instância de VM (máquinas virtuais), em uma Zona de Disponibilidade ou em uma região completa do Azure inoperante. Recomendamos que os clientes tenham um plano em uso para lidar com as interrupções de zona ou regionais.

Este artigo apresenta as informações para os clientes criarem um plano de continuidade de negócios e recuperação de desastre para a implementação do Cache do Azure para Redis ou Cache do Azure para Redis Enterprise.

Várias opções de alta disponibilidade estão disponíveis nas camadas Standard, Premium e Enterprise:

Replicação Standard para alta disponibilidade

Camadas aplicáveis: Standard, Premium, Enterprise, Enterprise Flash

Recomendado para: Alta disponibilidade

O Cache do Azure para Redis tem uma arquitetura de alta disponibilidade que garante que sua instância gerenciada está funcionando, mesmo quando as interrupções afetam as VMs (máquinas virtuais) subjacentes. Quer as interrupções sejam planejada ou não, o Cache do Azure para Redis oferece taxas de disponibilidade de percentuais maiores do que as que podem ser alcançadas hospedando o Redis em uma só VM.

Um Cache do Azure para Redis nas camadas aplicáveis em um par de servidores Redis por padrão. Os dois servidores são hospedados em VMs dedicadas. O Redis de código-fonte aberto permite que apenas um servidor manipule solicitações de gravação de dados.

Com Cache do Azure para Redis, um servidor é o nó primário, enquanto o outro é a réplica. Depois de provisionar os nós de servidor, o Cache do Azure para Redis atribui funções primárias e de réplica a eles. O nó primário geralmente é responsável por atender as solicitações de gravação e leitura de clientes. Em uma operação de gravação, ele confirma uma nova chave e uma atualização de chave para sua memória interna e responde imediatamente ao cliente. Ele encaminha a operação para a réplica de forma assíncrona.

Se o nó primário em um cache estiver indisponível, a réplica se promoverá automaticamente para se tornar o novo primário. Esse processo é chamado de failover. Um failover consiste apenas em dois nós, primário/réplica, trocando de funções, réplica/primário, e possivelmente um dos nós ficará offline por alguns minutos. Na maioria dos failovers, os nós primário e de réplica coordenam a transferência para que você tenha quase zero tempo sem o primário.

O primário anterior fica offline brevemente para receber atualizações do novo primário. Em seguida, a réplica fica online novamente e retorna ao cache totalmente sincronizada. O importante é que, quando um nó não estiver disponível, isso seja uma condição temporária e ele fique online novamente.

Uma sequência de failover típica é semelhante a esta, quando um primário precisa ficar inoperante para manutenção:

1. Os nós primário e de réplica negociam um failover coordenado e trocam de funções.
2. O nó de réplica (nó primário anterior) fica offline para uma reinicialização.
3. Alguns segundos ou minutos depois, a réplica fica online novamente.
4. O nó de réplica sincroniza os dados do primário.

Um nó primário pode ficar fora de serviço como parte de uma atividade de manutenção planejada, como uma atualização do software Redis ou do sistema operacional. Ele também pode parar de funcionar devido a eventos não planejados, como falhas em hardware, software ou rede subjacentes. Failover e aplicação de patch do Cache do Azure para Redis fornece uma explicação detalhada sobre os tipos de failovers. Um Cache do Azure para Redis passa por vários failovers durante seu tempo de vida. O design da arquitetura de alta disponibilidade torna essas alterações dentro de um cache tão transparente para seus clientes quanto possível.

Além disso, o Cache do Azure para Redis oferece mais nós de réplica na camada Premium. Um cache de várias réplicas pode ser configurado com até três nós de réplica. Ter mais réplicas geralmente melhora a resiliência devido aos nós adicionais que fazem backup do primário. Mesmo com mais réplicas, uma instância do Cache do Azure para Redis ainda pode ser seriamente afetada por uma interrupção no âmbito do data center ou da Zona de Disponibilidade. Você pode aumentar a disponibilidade do cache usando várias réplicas com a redundância de zona.

Redundância de zona

Camadas aplicáveis: Standard (versão prévia), Premium, Enterprise, Enterprise Flash

Recomendado para: Alta disponibilidade, Recuperação de desastre – Na mesma região

O Cache do Azure para Redis dá suporte a configurações com redundância de zona nos níveis Standard (versão prévia), Premium e Enterprise. Um cache com redundância de zona pode colocar seus nós entre diferentes Zonas de Disponibilidade do Azure na mesma região. Ele elimina uma interrupção de data center ou Zonas de Disponibilidade como um ponto único de falha e aumenta a disponibilidade geral do cache.

Se um cache estiver configurado para usar duas ou mais zonas, conforme descrito anteriormente neste artigo, os nós de cache serão criados em zonas diferentes. Quando uma zona fica inoperante, os nós de cache em outras zonas ficam disponíveis para manter o cache funcionando normalmente.

Camada premium

O diagrama a seguir ilustra a configuração de zona redundante para a camada Premium:

O Cache do Azure para Redis distribui os nós em um cache com redundância de zona em um modo Round Robin sobre as Zonas de Disponibilidade selecionadas. Ele também determina o nó que serve como o principal inicialmente.

Experiência de zona para baixo para a camada Premium

Um cache com redundância de zona fornece failover automático. Quando o nó primário atual não estiver disponível, uma das réplicas assumirá. Seu aplicativo poderá apresentar um tempo de resposta de cache maior se o novo nó primário estiver localizado em um AZ diferente. Zonas de Disponibilidade são geograficamente separados. Alternar de um AZ para outro altera a distância física entre onde o aplicativo e o cache estão hospedados. Essa alteração afeta as latências de rede de ida e volta de seu aplicativo para o cache. Espera-se que a latência extra se enquadrasse em um intervalo aceitável para a maioria dos aplicativos. Recomendamos testar seu aplicativo para garantir que ele funcione bem com um cache com redundância de zona.

Camadas Enterprise e Enterprise Flash

Um cache em uma camada Enterprise é executado em um cluster do Redis Enterprise. Sempre requer um número ímpar de nós de servidor para formar um quorum. Por padrão, ele é composto por três nós, cada um hospedado em uma VM dedicada.

• Um cache corporativo tem dois nós de dados de mesmo tamanho e um nó de quorum menor.
• Um cache Enterprise Flash tem três nós de dados de tamanho igual.

O cluster Enterprise divide os dados do Cache do Azure para Redis em partições internamente. Cada partição tem um primário e pelo menos uma réplica. Cada nó de dados contém uma ou mais partições. O cluster Enterprise garante que as réplicas e os primários de qualquer partição nunca sejam colocalizadas no mesmo nó de dados. As partições replicam dados de forma assíncrona de primárias para suas réplicas correspondentes.

Experiência de zona para baixo para camadas Enterprise

Quando um nó de dados fica indisponível ou ocorre uma divisão de rede, um failover semelhante ao descrito na replicação Standard ocorre. O cluster corporativo usa um modelo baseado em quorum para determinar quais nós sobreviventes participam de um novo quorum. Ele também promove partições de réplica dentro desses nós para os primários, conforme necessário.

Disponibilidade regional

Os caches de camada Premium com redundância de zona estão disponíveis nas seguintes regiões:

Os caches da camada Enterprise e Enterprise Flash com redundância de zona estão disponíveis nas seguintes regiões:

* Camada Enterprise Flash não disponível nesta região.

Reimplantação e migração da zona de disponibilidade

Atualmente, a única maneira de converter um cache da configuração não AZ para uma configuração AZ é reimplantando-o. Para saber como reimplantar seu cache atual, confira Migrar uma instância do Cache do Azure para Redis para o suporte à zona de disponibilidade.

Persistência

Camadas aplicáveis: Premium, Enterprise (versão prévia), Enterprise Flash (versão prévia)

Recomendado para: durabilidade de dados

Como os dados de cache são armazenados na memória, uma falha rara e não planejada de vários nós pode fazer com que todos os dados sejam descartados. Para evitar a perda completa de dados, a persistência de Redis permite que você faça instantâneos periódicos de dados na memória e armazene-os em sua conta de armazenamento. Se você tiver uma falha em vários nós causando perda de dados, o cache carregará o instantâneo da conta de armazenamento. Para obter mais informações, consulte Configurar persistência de dados para uma instância Premium do Cache do Azure para Redis.

Armazenamento conta para persistência

Considere a escolha de uma conta de armazenamento com redundância geográfica para garantir a alta disponibilidade dos dados persistentes. Para mais informações, confira Redundância do Armazenamento do Microsoft Azure.

Importar/Exportar

Camadas aplicáveis: Premium, Enterprise, Enterprise Flash

Recomendado para: recuperação de desastre

O cache do Azure para Redis dá suporte à opção de importar e exportar arquivos de RDB (banco de dados do Redis) para fornecer portabilidade de dado. Ele permite que você importe dados para o Cache do Azure para Redis ou exporte dados do Cache do Azure para Redis usando um instantâneo do RDB. O instantâneo do RDB de um cache Premium é exportado para um blob em uma conta de Armazenamento do Microsoft Azure. Você pode criar um script para disparar a exportação periodicamente para sua conta de armazenamento. Para obter mais informações, confira Importar e exportar dados no Cache do Azure para Redis.

Armazenamento conta para exportação

Considere a escolha de uma conta de armazenamento com redundância geográfica para garantir a alta disponibilidade de seus dados exportados. Para mais informações, confira Redundância do Armazenamento do Microsoft Azure.

Replicação geográfica passiva

Camadas aplicáveis: Premium

Recomendado para: recuperação de desastre – região única

A Replicação geográfica é um mecanismo para vincular dois ou mais instância do Cache do Azure para Redis, normalmente abrangendo duas regiões do Azure. A replicação geográfica foi projetada principalmente para a recuperação de desastre entre regiões. Duas instâncias de cache de camada Premium são conectadas por meio da replicação geográfica, que fornece leituras e gravações em seu cache primário, e esses dados são replicados para o cache secundário.

Para obter mais informações sobre como configurá-lo, consulte Configurar a replicação geográfica para instâncias Premium do Cache do Azure para Redis.

Se a região que hospeda o cache primário falhar, você precisará iniciar o failover: primeiro, desvincular o cache secundário e, em seguida, atualizar seu aplicativo para apontar para o cache secundário para leituras e gravações.

Replicação geográfica ativa

Camadas aplicáveis: Enterprise, Enterprise Flash

Recomendado para: Alta disponibilidade, Recuperação de desastre – Entre diferentes regiões

As camadas Enterprise dão suporte a um modo mais avançado de replicação geográfica chamado replicação geográfica ativa que oferece maior disponibilidade e recuperação de desastre entre várias regiões distintas. O software do Cache do Azure para Redis Enterprise usa tipos de dados replicados sem conflitos para dar suporte a gravações em várias instâncias de cache, mescla alterações e resolve conflitos. É possível unir até cinco instâncias de cache de camada de Enterprise em diferentes regiões do Azure para formar um grupo de replicação geográfica.

Um aplicativo que usa esse cache pode ler e gravar em qualquer uma das instâncias de cache distribuídas geograficamente por meio de seus pontos de extremidade correspondentes. O aplicativo deve usar o que estiver mais próximo de cada instância do aplicativo, oferecendo a menor latência. Para obter mais informações, consulte Configurar a replicação geográfica ativa para instâncias Enterprise do Cache do Azure para Redis.

Se uma região de um dos caches em seu grupo de replicação ficar inativa, seu aplicativo precisará alternar para outra região disponível.

Quando um cache em seu grupo de replicação está indisponível, é recomendável monitorar o uso de memória para outros caches no mesmo grupo de replicação. Enquanto um dos caches está inativo, todos os outros caches no grupo de replicação começam a salvar os metadados que não poderiam compartilhar com o cache que está inativo. Se o uso de memória para os caches disponíveis começar a crescer com uma taxa alta depois que um dos caches ficar inativo, considere desvincular o cache que não está disponível no grupo de replicação.

Para obter mais informações sobre forçar a desvinculação, consulte Forçar-desvincular se houver interrupção de região.

Excluir e recriar o cache

Camadas aplicáveis: Standard, Premium, Enterprise, Enterprise Flash

Se você tiver uma interrupção regional, considere recriar o cache em uma região diferente e atualizar seu aplicativo para se conectar ao novo cache. É importante entender que os dados serão perdidos durante uma interrupção regional. O código do aplicativo deve ser resiliente à perda de dados.

Após a região afetada for restaurada, o Cache do Azure para Redis indisponível será automaticamente restaurado e estará disponível para uso novamente. Para obter mais estratégias para mover o cache para uma região diferente, consulte Mover instâncias de Cache do Azure para Redis para regiões diferentes.

Próximas etapas

Saiba mais sobre como configurar as opções de alta disponibilidade de Cache do Azure para Redis.

• Camadas de serviço Premium do Cache do Azure para Redis
• Adicionar réplicas ao Cache do Azure para Redis (versão prévia)
• Habilitar a redundância de zona para o Cache do Azure para Redis
• Configurar a replicação geográfica para o Cache do Azure para Redis