Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O failover planejado gerido pelo cliente pode ser útil em cenários como planeamento e testes de desastres e recuperação, remediação proativa de desastres de grande escala previstos, e interrupções não relacionadas ao armazenamento.
Durante o processo de failover planejado, as regiões primária e secundária da sua conta de armazenamento são trocadas. A região primária original é rebaixada e torna-se a nova secundária, enquanto a região secundária original é promovida e torna-se a nova primária. A conta de armazenamento deve estar disponível nas regiões primária e secundária antes que um failover planejado possa ser iniciado.
Este artigo descreve o que acontece durante um failover e failback planificados geridos pelo cliente em cada estágio do processo. Para entender como funciona um failover devido a uma interrupção inesperada do ponto de extremidade de armazenamento, consulte Como funciona o failover gerido pelo cliente (não planeado).
Importante
O failover planejado gerenciado pelo cliente está atualmente em PREVIEW e é suportado em todas as regiões públicas GRS/GZRS. Para determinar se uma região dá suporte a GZRS, consulte a lista de regiões do Azure. Para dar suporte ao GZRS, uma região deve oferecer suporte a zonas de disponibilidade e ter uma região emparelhada.
Para aceitar a visualização, consulte Configurar recursos de visualização na assinatura do Azure e especifique AllowSoftFailover como o nome do recurso. O nome do provedor para esse recurso de visualização é Microsoft.Storage.
Consulte os Termos de Utilização Complementares das Visualizações Prévias do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão em beta, em pré-visualização ou que ainda não foram lançadas para disponibilidade geral.
Gestão de redundância durante o failover e failback planeados
Sugestão
Para entender os diferentes estados de redundância durante o processo de failover e failback gerenciado pelo cliente em detalhes, consulte Redundância do Armazenamento do Azure para obter definições de cada um.
Durante o processo de failover planeado, os pontos de extremidade do serviço de armazenamento da região primária ficam em modo de leitura apenas enquanto as atualizações restantes concluem a replicação para a região secundária. Em seguida, são alteradas todas as entradas do serviço de nomes de domínio (DNS) do ponto de extremidade do serviço de armazenamento. Os pontos finais secundários da sua conta de armazenamento tornam-se os novos pontos finais primários, enquanto os pontos finais primários originais tornam-se os novos secundários. A replicação de dados dentro de cada região permanece inalterada, mesmo que as regiões primária e secundária sejam alternadas.
O processo de failback planeado é essencialmente o mesmo que o processo de failover planeado, mas com uma exceção. Durante o failback planejado, o Azure armazena a configuração de redundância original da sua conta de armazenamento e a restaura ao seu estado original após o failback. Por exemplo, se a sua conta de armazenamento foi originalmente configurada como GZRS, a conta de armazenamento estará GZRS após a recuperação.
Nota
Ao contrário do failover gerido pelo cliente (não planeado), durante o failover planeado, a replicação da região primária para a região secundária deve ser concluída antes que os registos DNS dos endpoints sejam alterados para o novo secundário. Por este motivo, a perda de dados não é esperada durante o "failover" ou "failback" planeado, desde que as regiões primária e secundária estejam disponíveis durante todo o processo.
Como iniciar um failover
Para aprender como iniciar um failover, consulte Iniciar um failover de conta.
O processo planeado de failover e failback
Os diagramas a seguir mostram o que acontece durante um failover planejado gerenciado pelo cliente e failback de uma conta de armazenamento.
Em circunstâncias normais, um cliente grava dados numa conta de armazenamento na região principal através de endpoints 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:
O processo de alternância planejada (GRS/RA-GRS)
Inicie os testes de recuperação de desastres iniciando um failover da sua conta de armazenamento para a região secundária. A seguir descrevem-se as etapas dentro do processo de failover planejado, e a imagem subsequente fornece ilustração:
A conta de armazenamento na região primária e secundária sofrerá uma perda temporária de acesso de leitura e gravação.
A replicação de todos os dados da região primária para a região secundária é concluída.
As entradas de DNS para os pontos de extremidade do serviço de armazenamento na região secundária são promovidas e tornam-se os novos pontos de extremidade principais para a sua conta de armazenamento.
O failover normalmente leva cerca de uma hora.
Após a conclusão do failover, a região primária original torna-se a nova secundária (1) e a região secundária original torna-se a nova primária (2). Os URIs para os pontos 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 nova região primária (3). Os usuários podem continuar gravando dados na conta de armazenamento na nova região primária e, em seguida, os dados são copiados de forma assíncrona para o novo secundário (4), conforme mostrado na imagem a seguir:
Enquanto estiver no estado de failover, execute o teste de recuperação de desastres.
O processo de reversão planeada (GRS/RA-GRS)
Após a conclusão do teste, efetue outro failover para efetuar o failback para a região primária original. Durante o processo de failover, conforme mostrado na imagem a seguir:
A conta de armazenamento na região primária e secundária sofrerá uma perda temporária de acesso de leitura e gravação.
Todo o dado termina de replicar da região primária atual para a região secundária atual.
As entradas DNS para os pontos de extremidade do serviço de armazenamento são alteradas para apontar de volta para a região que era a principal antes do failover inicial ter sido realizado.
O failback normalmente leva cerca de uma hora.
Após a conclusão do failback, a conta de armazenamento é restaurada para sua configuração de redundância original. Os usuários podem retomar a gravação de dados na conta de armazenamento na região primária original (1) enquanto a replicação para a secundária original (2) continua como antes do failover:
