Como funciona o failover gerenciado pelo cliente (não planejado)
O failover gerido pelo cliente (não programado) permite realizar o failover de toda a sua conta de armazenamento com redundância geográfica para a região secundária caso os pontos de extremidade do serviço de armazenamento para a região primária fiquem 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 de resolvida a interrupção do ponto de extremidade do serviço de armazenamento, pode executar outra operação para reverter 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.
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 as definições de cada um.
Quando uma conta de armazenamento é configurada para armazenamento com redundância geográfica (GRS) ou 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 localmente redundante (LRS). Quando uma conta de armazenamento é configurada para replicação de Armazenamento Geo-Redundante de Zonas (GZRS) ou Armazenamento de Acesso de Leitura Geo-Redundante de Zonas (RA-GZRS), os dados são armazenados de forma redundante dentro da região primária do armazenamento de zona redundante (ZRS) e replicados três vezes na região secundária do armazenamento com redundância local (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 gerido pelo cliente (não planeado), as entradas do Sistema de Nomes de Domínio (DNS) para os pontos de extremidade do serviço de armazenamento são trocadas. 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 no novo servidor principal.
O processo de failback é essencialmente o mesmo que o processo de failover, exceto que a configuração de replicação é restaurada para o 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 planeado, 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 mudança automática após falha |
Após a reativação redundância geográfica |
Após Retorno |
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 numa conta de armazenamento na região principal através de interfaces 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 finais do serviço de armazenamento tornam-se 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 perda significativa de dados, verifique o valor da propriedade Last Sync Time antes de reverter ao estado original. Compare o último tempo de sincronização com as mais recentes gravações de dados no novo servidor primário para avaliar a eventual 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. O processo de failback é o mesmo que o processo de failover original, conforme explicado anteriormente.
Pontos importantes a considerar:
- 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 trocadas. 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:
