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:
| Opção | Descrição | Disponibilidade | Standard | Premium | Enterprise |
|---|---|---|---|---|---|
| Replicação Standard | Configuração replicada de nó duplo em um único data center com failover automático | 99,9% (veja os detalhes) | ✔ | ✔ | ✔ |
| Redundância de zona | Configuração replicada de vários nós em Zonas de Disponibilidade, com failover automático | 99,9% no Premium; 99,99% no Enterprise (confira os detalhes) | - | ✔ | ✔ |
| Replicação geográfica | Instâncias de cache vinculadas em duas regiões, com failover controlado pelo usuário | Premium; Enterprise (confira os detalhes) | - | Passivo | Ativo |
| Importar/exportar | Instantâneo point-in-time de dados no cache. | 99,9% (veja os detalhes) | - | ✔ | ✔ |
| Persistência | Economia periódica de dados na conta de armazenamento. | 99,9% (veja os detalhes) | - | ✔ | Visualização |
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.
Observação
Normalmente, um aplicativo cliente do Cache do Azure para Redis se comunica com o nó primário em um cache para todas as solicitações de leitura e gravação. Determinados clientes podem ser configurados para leitura a partir do nó de réplica.
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:
- Os nós primário e de réplica negociam um failover coordenado e trocam de funções.
- O nó de réplica (nó primário anterior) fica offline para uma reinicialização.
- Alguns segundos ou minutos depois, a réplica fica online novamente.
- 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: 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 nas camadas 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 AZ como um ponto único de falha e aumenta a disponibilidade geral do cache. Consulte este artigo para obter informações sobre como configurá-lo.
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.
O Cache do Azure para Redis dá suporte a configurações com redundância de zona nas camadas 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.
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:
| Américas | Europa | Oriente Médio | África | Pacífico Asiático |
|---|---|---|---|---|
| Brazil South | França Central | Catar Central | Norte da África do Sul | Leste da Austrália |
| Canadá Central | Centro-Oeste da Alemanha | Índia Central | ||
| Centro dos EUA | Norte da Europa | Leste do Japão | ||
| Leste dos EUA | Leste da Noruega | Coreia Central | ||
| Leste dos EUA 2 | Sul do Reino Unido | Sudeste Asiático | ||
| Centro-Sul dos Estados Unidos | Europa Ocidental | Leste da Ásia | ||
| Gov. dos EUA – Virgínia | Suécia Central | Norte da China 3 | ||
| Oeste dos EUA 2 | Norte da Suíça | |||
| Oeste dos EUA 3 |
Os caches da camada Enterprise e Enterprise Flash com redundância de zona estão disponíveis nas seguintes regiões:
| Américas | Europa | Oriente Médio | África | Pacífico Asiático |
|---|---|---|---|---|
| Canadá Central* | Norte da Europa | Leste da Austrália | ||
| EUA Central* | Sul do Reino Unido | Índia Central | ||
| Leste dos EUA | Europa Ocidental | Sudeste Asiático | ||
| Leste dos EUA 2 | Leste do Japão* | |||
| Centro-Sul dos Estados Unidos | Leste da Ásia* | |||
| Oeste dos EUA 2 | ||||
| Oeste dos EUA 3 | ||||
| Sul do Brasil |
* 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.