Como funciona o failover planejado gerenciado pelo cliente (visualização)
O failover planejado gerenciado pelo cliente pode ser útil em cenários como planejamento e testes de desastres e recuperação, correção proativa de desastres previstos em grande escala 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 planejados gerenciados 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 o failover gerenciado pelo cliente (não planejado).
Importante
O failover planejado gerenciado pelo cliente está atualmente em PREVIEW e limitado às seguintes regiões:
- França Central
- Sul de França
- Índia Central
- Oeste da Índia
- Ásia Leste
- Sudeste Asiático
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.
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.
Importante
Após um failover planejado, o valor LST (Last Sync Time) de uma conta de armazenamento pode parecer obsoleto ou ser relatado como NULL quando os dados do Azure Files estiverem presentes.
Os instantâneos do sistema são criados periodicamente na região secundária de uma conta de armazenamento para manter pontos de recuperação consistentes usados durante failover e failback. Iniciar o failover planejado gerenciado pelo cliente faz com que a região primária original se torne a nova secundária. Em alguns casos, não há instantâneos do sistema disponíveis no novo secundário após a conclusão do failover planejado, fazendo com que o valor LST geral da conta pareça obsoleto ou seja exibido como Null.
Como as atividades do usuário, como criar, modificar ou excluir objetos, podem acionar a criação de instantâneos, qualquer conta na qual essas atividades ocorram após o failover planejado não exigirá atenção adicional. No entanto, contas sem instantâneos ou atividade do usuário podem continuar a exibir um Null valor LST até que a criação de instantâneos do sistema seja acionada.
Se necessário, execute uma das seguintes atividades para cada compartilhamento em uma conta de armazenamento para acionar a criação de instantâneos. Após a conclusão, sua conta deve exibir um valor de LST válido dentro de 30 minutos.
- Monte o compartilhamento e abra qualquer arquivo para leitura.
- Carregue um arquivo de teste ou exemplo para o compartilhamento.
Gerenciamento de redundância durante failover e failback planejados
Gorjeta
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 planejado, os pontos de extremidade do serviço de armazenamento da região primária tornam-se somente leitura enquanto as atualizações restantes terminam de ser replicadas para a região secundária. Em seguida, todas as entradas do serviço de nome de domínio (DNS) do ponto de extremidade 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. 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 planejado é essencialmente o mesmo que o processo de failover planejado, 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 sua conta de armazenamento foi originalmente configurada como GZRS, a conta de armazenamento será GZRS após failback.
Nota
Ao contrário do failover gerenciado pelo cliente (não planejado), durante o failover planejado, a replicação da região primária para a secundária deve ser concluída antes que as entradas DNS dos pontos de extremidade sejam alteradas para o novo secundário. Por isso, a perda de dados não é esperada durante o failover ou failback planejado, desde que as regiões primária e secundária estejam disponíveis durante todo o processo.
Como iniciar um failover
Para saber como iniciar um failover, consulte Iniciar um failover de conta.
O processo de failover e failback planejado
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 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:
O processo de failover planejado (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. As etapas a seguir descrevem o processo de failover e a imagem subsequente fornece ilustração:
- A região primária original torna-se somente leitura.
- A replicação de todos os dados da região primária para a região secundária é concluída.
- As entradas DNS para pontos de extremidade de serviço de armazenamento na região secundária são promovidas e se tornam os novos pontos de extremidade primários para 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 failback planejado (GRS/RA-GRS)
Após a conclusão do teste, execute outro failover para failback para a região primária original. Durante o processo de failover, conforme mostrado na imagem a seguir:
- A região primária original torna-se somente leitura.
- Todos os dados terminam 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 ser executado.
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:
