Como funciona o failover gerenciado pelo cliente (não planejado)
O failover gerenciado pelo cliente (não planejado) 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 para a 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 failover 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 estágio 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 PREVIEW e tem suporte em todas as regiões públicas GRS/GZRS.
Para aceitar a visualização, consulte Configurar recursos de visualização na assinatura do Azure e especifique AllowHNSAccountFailover como o nome do recurso.
Importante
O failover gerenciado pelo cliente (não planejado) para contas que têm o SSH File Transfer Protocol (SFTP) habilitado está atualmente em PREVIEW e só é suportado nas seguintes regiões:
- (Ásia-Pacífico) Índia Central
- (Ásia-Pacífico) Sudeste Asiático
- (Europa) Europa do Norte
- (Europa) Suíça Norte
- (Europa) Suíça Oeste
- (Europa) Europa Ocidental
- (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 visualização, consulte Configurar recursos de visualização na assinatura do Azure e especifique AllowHNSAccountFailover como o nome do recurso.
Veja Termos de Utilização Complementares da Pré-visualizações do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão na versão beta, na pré-visualização ou que ainda não foram lançadas para disponibilidade geral.
No caso de um desastre significativo que afete a região primária, a Microsoft gerenciará o failover de contas com um namespace hierárquico. Para obter mais informações, veja Ativação pós-falha gerida pela Microsoft.
Gerenciamento de redundância durante failover e failback não planejados
Gorjeta
Para entender os vários estados de redundância durante o processo de failover e failback não planejado em detalhes, consulte Redundância do Armazenamento do Azure para obter definições de cada um.
Quando uma conta de armazenamento é configurada para redundância de armazenamento com redundância geográfica (GRS) ou de armazenamento com redundância geográfica de acesso de leitura (RA-GRS), os dados são replicados três vezes nas regiões primária e secundária do armazenamento com redundância local (LRS). Quando uma conta de armazenamento é configurada para replicação de armazenamento com redundância de zona geográfica (GZRS) ou armazenamento com redundância de zona de acesso de leitura (RA-GZRS), os dados são redundantes de zona na região primária de armazenamento redundante de zona (ZRS) e replicados três vezes na 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 (não planejado), as entradas DNS (Sistema de Nomes de Domínio) para os pontos de extremidade do serviço de armazenamento são alternadas. Os endpoints secundários da sua conta de armazenamento tornam-se os novos endpoints primários e os endpoints primários originais tornam-se os novos endpoints secundários. Após o failover, a cópia da conta de armazenamento na região primária original é excluída e a conta de armazenamento continua a ser replicada três vezes localmente na nova região primária. Nesse ponto, sua conta de armazenamento torna-se localmente redundante e utiliza o LRS.
As configurações de redundância originais e atuais são armazenadas nas propriedades da conta de armazenamento. Essa funcionalidade permite que você retorne à configuração original quando 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 um tempo significativo até que os dados existentes na nova região primária sejam totalmente copiados para o novo secundário.
Para evitar uma grande perda de dados, verifique o valor da propriedade Last Sync Time antes de fazer failback. Para avaliar a possível perda de dados, compare a última hora de sincronização com a última vez em que os dados foram gravados na nova primária.
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 de 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 mais opções, consulte Alterar a forma como uma conta de armazenamento é replicada.
Como iniciar um failover não planejado
Para saber como iniciar um failover não planejado, consulte Iniciar um failover de conta.
Atenção
O failover não planejado 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 esse tipo de failover.
Para obter detalhes sobre possíveis perdas e inconsistências de dados, consulte Antecipar perda e inconsistências de dados.
O processo de failover e failback não planejado
Esta seção resume o processo de failover para um failover gerenciado pelo cliente (não planejado).
Resumo da transição de failover não planejada
Após um failover gerenciado pelo cliente (não planejado):
- A região secundária torna-se a nova região 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 um failover e failback gerenciado pelo cliente (não planejado):
| Original configuração |
Após ativação pós-falha |
Após a reativação redundância geográfica |
Após 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 (não planejado) e deve ser reconfigurada manualmente.
Detalhes da transição de failover não planejada
Os diagramas a seguir mostram o processo de failover e failback gerenciado pelo cliente (não planejado) para uma conta de armazenamento configurada para redundância geográfica. Os detalhes de transição para GZRS e RA-GZRS são ligeiramente diferentes de GRS e RA-GRS.
Funcionamento normal (GRS/RA-GRS)
Em circunstâncias normais, um cliente grava dados em uma conta de armazenamento na região principal por meio de pontos de extremidade de 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 principal (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 ficam indisponíveis, mas antes que a recuperação ocorra:
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 gerenciado pelo cliente (não planejado) 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 retomar a gravação de dados na conta de armazenamento (3), como mostra esta imagem:
Para retomar a replicação para uma nova região secundária, reconfigure a conta para redundância geográfica.
Importante
Lembre-se de que converter uma conta de armazenamento com redundância local para usar redundância geográfica incorre em custos e tempo. Para obter mais informações, consulte O tempo e o custo do failover.
Depois de reconfigurar a conta para utilizar 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 estará disponível novamente até que o problema que causou a interrupção original seja 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 o novo secundário.
Para evitar uma grande perda de dados, verifique o valor da propriedade Last Sync Time 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 for resolvido, você poderá iniciar o failback para a região primária original. Este processo é descrito na imagem a seguir:
- A região primária atual torna-se somente leitura.
- Com failover e 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 failback.
- As entradas DNS para os pontos de extremidade do serviço de armazenamento são alternadas. Os endpoints dentro da região secundária tornam-se os novos endpoints primários para sua conta de armazenamento.
Após a conclusão do failback, a região primária original torna-se a atual novamente (1) e a cópia da conta de armazenamento no secundário original é 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 retomar a gravação de dados na conta de armazenamento (3), como mostra esta imagem:
Para retomar a replicação para a região secundária original, reconfigure a conta para redundância geográfica.
Importante
Lembre-se de que converter uma conta de armazenamento com redundância local para usar redundância geográfica incorre em custos 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:
