Recuperação de elevada disponibilidade e após desastre
Tal como acontece com todos os sistemas cloud, podem ocorrer interrupções não planeadas que podem levar à inatividade de uma instância de máquinas virtuais (VMs), uma Zona de Disponibilidade ou uma região completa do Azure. Recomendamos que os clientes tenham um plano para lidar com interrupções regionais ou de zona.
Este artigo apresenta as informações para os clientes criarem um plano de continuidade de negócios e recuperação de desastres para o Cache do Azure para Redis ou a implementação do 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 | Description | Disponibilidade | Standard | Premium | Grandes Empresas |
|---|---|---|---|---|---|
| Replicação padrão | Configuração replicada de nó duplo em um único data center com failover automático | 99,9% (ver detalhes) | Sim | Sim | Sim |
| Redundância de zona | Configuração replicada de vários nós em zonas de disponibilidade, com failover automático | 99,9% em Premium; 99,99% em Empresas (ver detalhes) | Sim | Sim | Sim |
| Georreplicação | Instâncias de cache vinculadas em duas regiões, com failover controlado pelo usuário | Prémio; Empresa (ver detalhes) | Não | Passivo | Activo |
| Importação/Exportação | Instantâneo point-in-time de dados em cache. | 99,9% (ver detalhes) | Não | Sim | Sim |
| Persistência | Poupança periódica de dados na conta de armazenamento. | 99,9% (ver detalhes) | Não | Sim | Pré-visualizar |
Replicação padrão para alta disponibilidade
Níveis aplicáveis: Standard, Premium, Enterprise, Enterprise Flash
Recomendado para: Alta disponibilidade
O Cache Redis do Azure tem uma arquitetura de alta disponibilidade que garante que sua instância gerenciada esteja funcionando, mesmo quando interrupções afetam as máquinas virtuais (VMs) subjacentes. Independentemente de a interrupção ser planejada ou não planejada, o Cache Redis do Azure oferece taxas de disponibilidade percentuais maiores do que as possíveis hospedando o Redis em uma única VM.
Um Cache Redis do Azure nas camadas aplicáveis é executado em um par de servidores Redis por padrão. Os dois servidores são hospedados em VMs dedicadas. O Redis de código aberto permite que apenas um servidor lide com solicitações de gravação de dados.
Com o Cache do Azure para Redis, um servidor é o nó primário , enquanto o outro é a réplica. Depois de provisionar os nós do servidor, o Cache Redis do Azure atribui funções primárias e de réplica a eles. O nó primário geralmente é responsável pelo atendimento de 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 em sua memória interna e responde imediatamente ao cliente. Ele encaminha a operação para a réplica de forma assíncrona.
Nota
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 ler a partir do nó da réplica.
Se o nó primário em um cache não estiver disponível, a réplica se promoverá automaticamente para se tornar a nova principal. Esse processo é chamado de failover. Um failover é apenas dois nós, principal/réplica, funções de negociação, réplica/principal, com um dos nós possivelmente ficando offline por alguns minutos. Na maioria dos failovers, os nós primário e de réplica coordenam a entrega para que você tenha quase zero tempo sem um principal.
A antiga primária fica offline brevemente para receber atualizações da nova primária. Em seguida, a réplica agora volta a ficar online e volta ao cache totalmente sincronizada. A chave é que, quando um nó está indisponível, é uma condição temporária e volta a ficar online.
Uma sequência de failover típica tem esta aparência, quando um primário precisa ser desativado para manutenção:
- Os nós primários e de réplica negociam um failover coordenado e funções comerciais.
- A réplica (anteriormente primária) fica offline para uma reinicialização.
- Alguns segundos ou minutos depois, a réplica volta a ficar online.
- A réplica sincroniza os dados do primário.
Um nó primário pode sair 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 no hardware, software ou rede subjacentes. Failover e aplicação de patches para o Cache Redis do Azure fornece uma explicação detalhada sobre os tipos de failovers. Um Cache do Azure para Redis passa por muitos failovers durante seu tempo de vida. O design da arquitetura de alta disponibilidade torna essas alterações dentro de um cache o mais transparentes possível para seus clientes.
Além disso, o Cache Redis do Azure fornece 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 porque você tem nós fazendo backup do primário. Mesmo com mais réplicas, uma instância do Cache do Azure para Redis ainda pode ser gravemente afetada por uma interrupção do data center ou da Zona de Disponibilidade. Você pode aumentar a disponibilidade do cache usando várias réplicas com redundância de zona.
Redundância entre zonas
Níveis aplicáveis: Standard, Premium, Enterprise, Enterprise Flash
Recomendado para: Alta disponibilidade, Recuperação de desastres - intrarregião
O Cache Redis do Azure dá suporte a configurações redundantes de zona nas camadas Standard, Premium e Enterprise. Um cache redundante de zona pode colocar seus nós em diferentes Zonas de Disponibilidade do Azure na mesma região. Elimina a indisponibilidade do centro de dados ou da Zona de Disponibilidade como um ponto único de falha e aumenta a disponibilidade geral da sua cache.
Se um cache estiver configurado para usar duas ou mais zonas, conforme descrito anteriormente no artigo, os nós de cache serão criados em zonas diferentes. Quando uma zona fica inativa, os nós da cache noutras zonas estão disponíveis para manter a cache a funcionar normalmente.
Importante
Por padrão, o Cache Redis do Azure cria caches redundantes de zona para Camadas Premium e Standard usando Automatic_Zonal_Allocation em regiões que oferecem suporte a zonas. Para obter mais informações, consulte Habilitar redundância de zona para o Cache do Azure para Redis.
Escalão Premium
O diagrama a seguir ilustra a configuração redundante de zona para a camada Premium:
O Cache Redis do Azure distribui nós em um cache redundante de zona de forma round-robin nas Zonas de Disponibilidade selecionadas. Ele também determina o nó que serve como o principal inicialmente.
Experiência Zone Down para nível Premium
Um cache redundante de zona fornece failover automático. Quando o nó primário atual não está disponível, uma das réplicas assume o controle. Seu aplicativo pode enfrentar um tempo de resposta de cache mais alto se o novo nó primário estiver localizado em um AZ diferente. As zonas de disponibilidade são separadas geograficamente. Alternar de um AZ para outro altera a distância física entre onde seu aplicativo e o cache estão hospedados. Essa alteração afeta as latências de rede de ida e volta do seu aplicativo para o cache. Espera-se que a latência extra fique dentro de um intervalo aceitável para a maioria dos aplicativos. Recomendamos que você teste seu aplicativo para garantir que ele se saia bem com um cache redundante de zona.
Níveis Enterprise e Enterprise Flash
Um cache em qualquer camada Enterprise é executado em um cluster Redis Enterprise. Ele sempre requer um número ímpar de nós de servidor para formar um quórum. Por padrão, ele tem três nós, cada um hospedado em uma VM dedicada.
- Um cache corporativo tem dois nós de dados do mesmo tamanho e um nó de quorum menor.
- Um cache Enterprise Flash tem três nós de dados do mesmo tamanho.
O cluster Enterprise divide o Cache do Azure para dados Redis em partições internamente. Cada partição tem uma primária e pelo menos uma réplica. Cada nó de dados contém uma ou mais partições. O cluster Enterprise garante que o primário e a(s) réplica(s) de qualquer partição nunca sejam colocados no mesmo nó de dados. As partições replicam dados de forma assíncrona de primárias para réplicas correspondentes.
Experiência de Zone Down para níveis Enterprise
Quando um nó de dados fica indisponível ou ocorre uma divisão de rede, ocorre um failover semelhante ao descrito na replicação padrão. O cluster Enterprise usa um modelo baseado em quórum para determinar quais nós sobreviventes participam de um novo quórum. Também promove partições de réplicas dentro destes nós para primárias, conforme necessário.
Disponibilidade regional
Os caches de camada Premium e Standard com redundância de zona estão disponíveis nas seguintes regiões:
| Américas | Europa | Médio Oriente | África | Ásia-Pacífico |
|---|---|---|---|---|
| Sul do Brasil | França Central | Catar Central | Norte da África do Sul | Leste da Austrália |
| Canadá Central | Norte da Itália | Norte dos E.A.U. | Índia Central | |
| E.U.A. Central | Alemanha Centro-Oeste | Israel Central | Leste do Japão | |
| E.U.A. Leste | Leste da Noruega | |||
| E.U.A. Leste 2 | Europa do Norte | Sudeste Asiático | ||
| E.U.A. Centro-Sul | Sul do Reino Unido | Ásia Leste | ||
| US Gov - Virginia | Europa Ocidental | Norte da China 3 | ||
| E.U.A. Oeste 2 | Suécia Central | Coreia do Sul Central | ||
| EUA Oeste 3 | Norte da Suíça | Norte da Nova Zelândia | ||
| México Central | Polónia Central | |||
| Espanha Central |
Os caches de camada Enterprise e Enterprise Flash com redundância de zona estão disponíveis nas seguintes regiões:
| Américas | Europa | Médio Oriente | África | Ásia-Pacífico |
|---|---|---|---|---|
| Canadá Central* | Europa do Norte | Leste da Austrália | ||
| Centro dos EUA* | Sul do Reino Unido | Índia Central | ||
| E.U.A. Leste | Europa Ocidental | Sudeste Asiático | ||
| E.U.A. Leste 2 | Leste do Japão* | |||
| E.U.A. Centro-Sul | Ásia Leste | |||
| E.U.A. Oeste 2 | ||||
| EUA Oeste 3 | ||||
| Sul do Brasil |
* A camada Enterprise Flash não está disponível nesta região.
Reimplantação e migração da zona de disponibilidade
Atualmente, a única maneira de converter o cache de uma configuração não-AZ para uma configuração AZ é reimplantar o cache. Para saber como reimplantar seu cache atual, consulte Migrar uma instância do Cache do Azure para Redis para o suporte à zona de disponibilidade.
Persistência
Níveis aplicáveis: Premium, Enterprise (pré-visualização), Enterprise Flash (pré-visualização)
Recomendado para: Durabilidade dos dados
Como os dados do 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 do Redis permite que você tire instantâneos periódicos dos dados na memória e os armazene em sua conta de armazenamento. Se ocorrer 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 do Cache Premium do Azure para Redis.
Conta de armazenamento para persistência
Considere escolher uma conta de armazenamento com redundância geográfica para garantir a alta disponibilidade de dados persistentes. Para obter mais informações, veja Redundância do Armazenamento do Microsoft Azure.
Importação/Exportação
Níveis aplicáveis: Premium, Enterprise, Enterprise Flash
Recomendado para: Recuperação de desastres
O cache do Azure para Redis dá suporte à opção de importar e exportar arquivos do Banco de Dados Redis (RDB) para fornecer portabilidade de dados. 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 RDB. O instantâneo RDB de um cache premium é exportado para um blob em uma Conta de Armazenamento do Azure. Você pode criar um script para acionar a exportação periodicamente para sua conta de armazenamento. Para obter mais informações, consulte Importar e exportar dados no Cache do Azure para Redis.
Conta de armazenamento para exportação
Considere escolher uma conta de armazenamento com redundância geográfica para garantir a alta disponibilidade dos dados exportados. Para obter mais informações, veja Redundância do Armazenamento do Microsoft Azure.
Replicação geográfica passiva
Níveis aplicáveis: Premium
Recomendado para: Recuperação de desastres - região única
A replicação geográfica é um mecanismo para vincular duas ou mais instâncias do Cache do Azure para Redis, normalmente abrangendo duas regiões do Azure. A replicação geográfica foi projetada principalmente para recuperação de desastres entre regiões. Duas instâncias de cache de camada Premium são conectadas por meio de replicação geográfica de uma forma que fornece leituras e gravações no cache primário e que os 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 do Cache Premium do Azure para Redis.
Se a região que hospeda o cache primário ficar inativa, você precisará iniciar o failover da seguinte forma: primeiro, desvinculando o cache secundário e, em seguida, atualizando seu aplicativo para apontar para o cache secundário para leituras e gravações.
Georreplicação ativa
Níveis aplicáveis: Enterprise, Enterprise Flash
Recomendado para: Alta disponibilidade, recuperação de desastres - multi-região
As camadas Enterprise oferecem suporte a uma forma mais avançada de replicação geográfica chamada replicação geográfica ativa, que oferece maior disponibilidade e recuperação de desastres entre regiões em várias regiões. O software 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. Você pode unir até cinco instâncias de cache de camada 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 é 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 do Enterprise Azure Cache for Redis.
Se uma região de um dos caches no grupo de replicação ficar inativa, seu aplicativo precisará alternar para outra região disponível.
Quando um cache no grupo de replicação não estiver disponível, recomendamos 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 metadados que não puderam compartilhar com o cache inativo. Se o uso de memória para os caches disponíveis começar a crescer a uma taxa alta depois que um dos caches ficar inativo, considere desvincular o cache que não está disponível do grupo de replicação.
Para obter mais informações sobre a desvinculação forçada, consulte Forçar-desvincular se houver interrupção de região.
Excluir e recriar cache
Níveis aplicáveis: Standard, Premium, Enterprise, Enterprise Flash
Se você enfrentar 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 são perdidos durante uma interrupção regional. O código do aplicativo deve ser resiliente à perda de dados.
Depois que a região afetada for restaurada, o Cache Redis do Azure indisponível será restaurado automaticamente 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 do Cache do Azure para Redis para regiões diferentes.
Próximos passos
Saiba mais sobre como configurar o Cache do Azure para opções de alta disponibilidade Redis.