Alta disponibilidade e recuperação de desastre com o Azure Managed Redis (versão prévia)
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 dos negócios e recuperação de desastres para a implementação do Azure Managed Redis (versão prévia).
Opções de alta disponibilidade:
| Opção | Descrição | Disponibilidade |
|---|---|---|
| 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,99% (veja os detalhes) |
| Replicação geográfica | Instâncias de cache vinculadas em duas regiões, com failover controlado pelo usuário | Ativo (veja os detalhes) |
| 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) |
Replicação Standard para alta disponibilidade
Recomendado para: Alta disponibilidade
O Azure Managed Redis tem uma arquitetura de alta disponibilidade que garante que sua instância gerenciada esteja funcionando, mesmo quando as interrupções afetam as VMs (máquinas virtuais) subjacentes. Quer as interrupções sejam planejadas ou não, o Azure Managed Redis oferece taxas de disponibilidade de percentuais maiores do que as que podem ser alcançadas hospedando o Redis em uma única VM. Uma instalação do Azure Managed Redis é executada em um par de servidores Redis por padrão. Os dois servidores são hospedados em VMs dedicadas.
Com o Azure Managed Redis, um servidor é o nó primário, enquanto o outro é a réplica. Depois de provisionar os nós de servidor, o Azure Managed 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:
- 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 para Azure Managed Redis fornece uma explicação detalhada sobre os tipos de failovers. Um Azure Managed 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.
Redundância de zona
Recomendado para: Alta disponibilidade, Recuperação de desastre – Na mesma região
O Azure Managed Redis dá suporte à configuração com redundância de zona por padrão. Um cache com redundância de zona coloca automaticamente seus nós em diferentes Zonas de Disponibilidade do Azure na mesma região. Quando uma zona fica inoperante, os nós de cache em outras zonas ficam disponíveis para manter o cache funcionando normalmente. 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.
Experiência de zona inoperante
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 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 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 | ||||
| Brazil South |
Persistência
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ê tire instantâneos periódicos de dados na memória e armazene-os em um disco gerenciado anexado diretamente à instância de cache. No caso de uma perda de dados, os dados de cache são restaurados automaticamente usando o instantâneo no disco gerenciado. Para obter mais informações, consulte Configurar a persistência de dados para uma instância do Azure Managed Redis.
Importar/exportar
Recomendado para: recuperação de desastre
O Azure Managed Redis dá suporte à opção de importar e exportar arquivos de RDB (banco de dados do Redis) para fornecer portabilidade de dados. Ele permite que você importe dados para o Azure Managed Redis ou exporte dados do Azure Managed Redis usando um instantâneo do RDB. O instantâneo do RDB de um cache é 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 Azure Managed 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 ativa
Recomendado para: Alta disponibilidade, Recuperação de desastre – Entre diferentes regiões
A replicação geográfica é um mecanismo para vincular instâncias do Azure Managed Redis em várias regiões do Azure. O Azure Managed Redis dá suporte a uma forma avançada de replicação geográfica chamada replicação geográfica ativa que oferece maior disponibilidade e recuperação de desastre entre várias regiões. O software do Azure Managed Redis 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 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, confira Configurar a replicação geográfica ativa para instâncias do Azure Managed 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
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, a menos que você use a replicação geográfica ativa. O código do aplicativo deve ser resiliente à perda de dados.
Depois que a região afetada for restaurada, o Azure Managed 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, confira Mover instâncias do Azure Managed Redis para regiões diferentes.