Como funciona o failover da conta de armazenamento gerenciada pelo cliente
O failover gerenciado pelo cliente de contas de Armazenamento do 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 se torna a nova primária e todos os pontos de extremidade do serviço de armazenamento para blobs, tabelas, filas e arquivos 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 failback para a região primária original.
Este artigo descreve o que acontece durante um failover e failback de conta de armazenamento gerenciado pelo cliente em cada estágio do processo.
Importante
O failover de conta gerenciada pelo cliente para contas que têm um namespace hierárquico (Azure Data Lake Storage Gen2) está atualmente em VERSÃO PRÉVIA e só tem suporte 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
Para aceitar a versão prévia, consulte Configurar versão prévia do recurso na assinatura do Azure e especifique AllowHNSAccountFailover como o nome do recurso.
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
Dica
Para entender os vários estados de redundância durante o processo de failover e failback da conta de armazenamento em detalhes, consulte Redundância de Armazenamento do Azure para obter definições de cada um.
Quando uma conta de armazenamento é configurada para redundância GRS ou RA-GRS, os dados são replicados três vezes localmente nas regiões primária e secundária (LRS). Quando uma conta de armazenamento é configurada para replicação GZRS ou RA-GZRS, os dados são redundantes por zona dentro da região primária (ZRS) e replicados três vezes localmente dentro da região secundária (LRS). Se a conta estiver configurada para acesso de leitura (RA), 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, as entradas DNS para os pontos de extremidade do serviço de armazenamento são alteradas de modo que as da região secundária se tornem os novos pontos de extremidade primários para sua conta de armazenamento. 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 região secundária original (a nova principal). Nesse ponto, sua conta de armazenamento se torna localmente redundante (LRS).
As configurações de redundância original e atual são armazenadas nas propriedades da conta de armazenamento para permitir que você eventualmente retorne à configuração original quando fizer failback.
Para recuperar a redundância geográfica após um failover, você precisará reconfigurar sua conta como GRS. (GZRS não é uma opção pós-failover, pois o novo primário será LRS após o failover). 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 (RA) à região secundária, esse acesso estará disponível, mas pode levar algum tempo para que a replicação do primário torne a corrente secundária.
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. 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.
O processo de failback é essencialmente o mesmo que o processo de failover, exceto que o Azure restaura a configuração de replicação para seu estado original antes de ser submetida a failover (a configuração de replicação, não os dados). Portanto, se sua conta de armazenamento foi originalmente configurada como GZRS, a região primária após o faillback se tornará ZRS.
Após o failback, você pode configurar sua conta de armazenamento para ser redundante geograficamente novamente. Se a região primária original foi configurada para LRS, você pode configurá-la para GRS ou RA-GRS. 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
Para saber como iniciar um failover, consulte Iniciar um failover de conta de armazenamento.
Cuidado
O failover da conta de armazenamento geralmente envolve alguma perda 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 um.
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
Esta seção resume o processo de failover para um failover gerenciado pelo cliente.
Resumo da transição de failover
Após um failover gerenciado pelo cliente:
- 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 estágio de failover e failback 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 gerenciado pelo cliente e deve ser reconfigurada manualmente.
Detalhes da transição de failover
Os diagramas a seguir mostram o que acontece durante o failover gerenciado pelo cliente e o failback de 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 imagem a seguir mostra o cenário em que os pontos de extremidade primários ficaram indisponíveis, mas nenhuma recuperação ocorreu ainda:
O processo de failover (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 os mesmos, mas suas entradas DNS são alteradas para apontar para a região secundária (1), conforme mostrado nesta imagem:
O failover 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 como 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 (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 causou a interrupção original tiver sido resolvido, você poderá iniciar outro failover para fazer failback para a região primária original, resultando no seguinte:
- 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 alteradas de modo que as da região secundária se tornem os 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 novamente.
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:
