Como funciona o failover gerenciado pelo cliente (não planejado)
O failover gerenciado pelo cliente (não planejado) de contas de Armazenamento do Microsoft Azure permite que você faça failover de toda a sua conta de armazenamento com redundância geográfica para a região secundária se os pontos de extremidade do serviço de armazenamento da região primária ficarem indisponíveis. Durante o failover, a região secundária original torna-se a nova região primária. Todos os pontos de extremidade do serviço de armazenamento são redirecionados para a nova região primária. Depois que a interrupção do ponto de extremidade do serviço de armazenamento for resolvida, você poderá executar outra operação de failover para fazer failback para a região primária original.
Este artigo descreve o que acontece durante um failover e failback gerenciado pelo cliente (não planejado) em cada fase do processo.
Importante
O failover gerenciado pelo cliente (não planejado) para contas que têm o Azure Data Lake Storage Gen2 habilitado está atualmente em VERSÃO PRÉVIA e tem suporte em todas as regiões públicas do GRS/GZRS.
Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.
Importante
O failover (não planejado) gerenciado pelo cliente para contas que têm o Protocolo de Transferência de Arquivos SSH (SFTP) habilitado está atualmente em VERSÃO PRÉVIA e tem suporte apenas nas seguintes regiões:
- (Pacífico Asiático) Índia Central
- (Pacífico Asiático) Sudeste da Ásia
- (Europa) Norte da Europa
- (Europa) Norte da Suíça
- (Europa) Oeste da Suíça
- (Europa) Oeste da Europa
- (América do Norte) Canadá Central
- (América do Norte) Leste dos EUA 2
- (América do Norte) Centro-Sul dos EUA
Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.
No caso de um desastre significativo que afete a região primária, a Microsoft gerenciará o failover para contas com um namespace hierárquico. Para obter mais informações, consulte failover gerenciado pela Microsoft.
Gerenciamento de redundância durante failover e failback não planejados
Dica
Para entender os vários estados de redundância durante o processo de failover e failback não planejado em detalhes, consulte Redundância de Armazenamento do Microsoft Azure para obter definições de cada um.
Quando uma conta de armazenamento é configurada para redundância de GRS (armazenamento com redundância geográfica) ou RA-GRS (armazenamento com redundância geográfica com acesso de leitura), os dados são replicados três vezes dentro das regiões primárias e secundárias do LRS (armazenamento com redundância local). Quando uma conta de armazenamento é configurada para replicação de GZRS (armazenamento com redundância de zona geográfica) ou RA-GZRS (armazenamento com redundância de zona geográfica com acesso de leitura), os dados são redundantes em zona dentro da região primária do ZRS (armazenamento com redundância de zona) e replicados três vezes dentro da região secundária do LRS. Se a conta estiver configurada para RA (acesso de leitura), você poderá ler dados da região secundária, desde que os pontos de extremidade do serviço de armazenamento para essa região estejam disponíveis.
Durante o processo de failover gerenciado pelo cliente (não planejado), as entradas do DNS (Sistema de Nomes de Domínio) para os pontos de extremidade do serviço de armazenamento são alternadas. Os pontos de extremidade secundários da conta de armazenamento tornam-se os novos pontos de extremidade primários e os pontos de extremidade primários originais tornam-se os novos secundários. Após o failover, a cópia da conta de armazenamento na região primária original é excluída e sua conta de armazenamento continua a ser replicada três vezes localmente na nova região primária. Nesse ponto, sua conta de armazenamento se torna localmente redundante e usa LRS.
As configurações de redundância original e atual são armazenadas nas propriedades da conta de armazenamento. Essa funcionalidade permite que você retorne à configuração original quando você fizer failback. Para obter uma lista completa das configurações de redundância resultantes, leia Planejamento de recuperação e failover.
Para recuperar a redundância geográfica após um failover, você precisa reconfigurar sua conta como GRS. Depois que a conta é reconfigurada para redundância geográfica, o Azure começa imediatamente a copiar dados da nova região primária para a nova secundária. Se você configurar sua conta de armazenamento para acesso de leitura à região secundária, esse acesso estará disponível. No entanto, a replicação da região primária para a secundária pode levar algum tempo para ser concluída.
Aviso
Depois que sua conta for reconfigurada para redundância geográfica, pode levar uma quantidade significativa de tempo até que os dados existentes na nova região primária sejam totalmente copiados para a nova secundária.
Para evitar uma grande perda de dados, verifique o valor da propriedade Hora da última sincronização antes de fazer failback. Para avaliar a possível perda de dados, compare a hora da última sincronização com a última vez em que os dados foram gravados no novo primário.
O processo de failback é essencialmente o mesmo que o processo de failover, exceto que a configuração de replicação é restaurada para seu estado original pré-failover.
Após o failback, você pode reconfigurar sua conta de armazenamento para aproveitar a redundância geográfica. Se o primário original foi configurado como ZRS, você pode configurá-lo para ser GZRS ou RA-GZRS. Para obter opções adicionais, consulte Alterar como uma conta de armazenamento é replicada.
Como iniciar um failover não planejado
Para saber como iniciar um failover não planejado, confira Iniciar um failover de conta.
Cuidado
O failover não planejado geralmente envolve algumas perdas de dados e, potencialmente, inconsistências de arquivos e dados. É importante entender o impacto que um failover de conta teria em seus dados antes de iniciar esse tipo de failover.
Para obter detalhes sobre possíveis perdas de dados e inconsistências, consulte Antecipar perda de dados e inconsistências.
O processo de failover e failback não planejados
Esta seção resume o processo de failover para um failover (não planejado) gerenciado pelo cliente.
Resumo da transição de failover não planejado
Após um failover gerenciado pelo cliente (não planejado):
- A região secundária torna-se a nova primária
- A cópia dos dados na região primária original é excluída
- A conta de armazenamento é convertida em LRS
- Perde-se a redundância geográfica
Esta tabela resume a configuração de redundância resultante em cada fase de failover e failback (não planejados) gerenciados pelo cliente:
| Original configuração |
Depois failover |
Após a reativação redundância geográfica |
Depois failback |
Após a reativação redundância geográfica |
|---|---|---|---|---|
| GRS | LRS | GRS 1 | LRS | GRS 1 |
| GZRS | LRS | GRS 1 | ZRS | GZRS 1 |
1 A redundância geográfica é perdida durante um failover (não planejado) gerenciado pelo cliente e precisa ser reconfigurada manualmente.
Detalhes da transição de failover não planejado
Os diagramas a seguir mostram o failover gerenciado pelo cliente (não planejado) e o processo de failback para uma conta de armazenamento configurada para redundância geográfica. Os detalhes de transição para GZRS e RA-GZRS são levemente diferentes de GRS e RA-GRS.
Operação normal (GRS/RA-GRS)
Em circunstâncias normais, um cliente grava dados em uma conta de armazenamento na região primária por meio de pontos de extremidade do serviço de armazenamento (1). Os dados são então copiados de forma assíncrona da região primária para a região secundária (2). A imagem a seguir mostra o estado normal de uma conta de armazenamento configurada como GRS quando os pontos de extremidade primários estão disponíveis:
Os pontos de extremidade do serviço de armazenamento ficam indisponíveis na região primária (GRS/RA-GRS)
Se os pontos de extremidade do serviço de armazenamento principal ficarem indisponíveis por qualquer motivo (1), o cliente não poderá mais gravar na conta de armazenamento. Dependendo da causa subjacente da interrupção, a replicação para a região secundária pode não estar mais funcionando (2), portanto, alguma perda de dados deve ser esperada. A seguinte imagem mostra o cenário em que os pontos de extremidade primários ficam indisponíveis, antes da recuperação ocorrer:
O processo de failover não planejado (GRS/RA-GRS)
Para restaurar o acesso de gravação aos seus dados, você pode iniciar um failover. Os URIs de ponto de extremidade do serviço de armazenamento para blobs, tabelas, filas e arquivos permanecem inalterados, mas suas entradas DNS são alteradas para apontar para a região secundária, conforme mostrado:
O failover (não planejado) gerenciado pelo cliente normalmente leva cerca de uma hora.
Após a conclusão do failover, o secundário original se torna o novo primário (1) e a cópia da conta de armazenamento no primário original é excluída (2). A conta de armazenamento é configurada como LRS na nova região primária e não é mais redundante geograficamente. Os usuários podem continuar gravando dados na conta de armazenamento (3), conforme mostrado nesta imagem:
Para retomar a replicação para uma nova região secundária, reconfigure a conta para redundância geográfica.
Importante
Tenha em mente que converter uma conta de armazenamento com redundância local para usar a redundância geográfica incorre em custo e tempo. Para obter mais informações, consulte O tempo e o custo do failover.
Depois de reconfigurar a conta para usar o GRS, o Azure começa a copiar seus dados de forma assíncrona para a nova região secundária (1), conforme mostrado nesta imagem:
O acesso de leitura à nova região secundária não ficará disponível novamente até que o problema que causou a interrupção original tenha sido resolvido.
O processo de failback não planejado (GRS/RA-GRS)
Aviso
Depois que sua conta for reconfigurada para redundância geográfica, pode levar um tempo significativo até que os dados na nova região primária sejam totalmente copiados para a nova secundária.
Para evitar uma grande perda de dados, verifique o valor da propriedade Hora da última sincronização antes de fazer failback. Compare a última hora de sincronização com as últimas vezes em que os dados foram gravados no novo primário para avaliar a possível perda de dados.
Depois que o problema que causa a interrupção original for resolvido, você poderá iniciar o failback para a região primária original. Cada atributo é descrito nas seguintes etapas:
- A região primária atual torna-se somente leitura.
- Com o failover e o failback iniciados pelo cliente, seus dados não podem concluir a replicação para a região secundária durante o processo de failback. Portanto, é importante verificar o valor da propriedade Last Sync Time antes de fazer failback.
- As entradas DNS para os pontos de extremidade do serviço de armazenamento são alternadas. Os pontos de extremidade da sua conta de armazenamento na região secundária tornam-se seus novos pontos de extremidade primários para sua conta de armazenamento.
Depois que o failback for concluído, a região primária original se tornará a atual novamente (1) e a cópia da conta de armazenamento na secundária original será excluída (2). A conta de armazenamento é configurada como localmente redundante na região primária e não é mais redundante geograficamente. Os usuários podem continuar gravando dados na conta de armazenamento (3), conforme mostrado nesta imagem:
Para retomar a replicação para a região secundária original, configure a conta para redundância geográfica.
Importante
Tenha em mente que converter uma conta de armazenamento com redundância local para usar a redundância geográfica incorre em custo e tempo. Para obter mais informações, consulte O tempo e o custo do failover.
Depois de reconfigurar a conta como GRS, a replicação para a região secundária original é retomada conforme mostrado nesta imagem:
