Failover e planejamento de recuperação de desastre do armazenamento do Azure

  • Artigo

A Microsoft se empenha em garantir que os serviços do Azure estejam sempre disponíveis. No entanto, podem ocorrer interrupções imprevistas do serviço. Os principais componentes de um bom plano de recuperação de desastre incluem estratégias para:

Este artigo se concentra no failover para contas de armazenamento com redundância global (GRS, GZRS e RA-GZRS) e como projetar seus aplicativos para estarem altamente disponíveis se houver uma interrupção e um failover subsequente.

Escolhendo a opção de redundância correta

O Armazenamento do Azure mantém várias cópias da conta de armazenamento para garantir durabilidade e alta disponibilidade. Qual opção de redundância você escolhe para sua conta depende do grau de resiliência necessário para seus aplicativos.

Com o LRS (armazenamento com redundância local), três cópias da sua conta de armazenamento são armazenadas e replicadas automaticamente em um único datacenter. Com o ZRS (armazenamento com redundância de zona), uma cópia é armazenada e replicada em cada uma das três zonas de disponibilidade separadas na mesma região. Para obter mais informações sobre zonas de disponibilidade, consulte Zonas de disponibilidade do Azure.

A recuperação de uma única cópia de uma conta de armazenamento ocorre automaticamente com LRS e ZRS.

Failover e armazenamento com redundância global

Com o armazenamento com redundância global (GRS, GZRS e RA-GZRS), o Azure copia seus dados de forma assíncrona para uma região geográfica secundária a pelo menos centenas de quilômetros de distância. Isso permite que você recupere seus dados se houver uma interrupção na região primária. Um recurso que distingue o armazenamento com redundância global de LRS e ZRS é a capacidade de fazer failover para a região secundária se houver uma interrupção na região primária. O processo de failover atualiza as entradas DNS para os pontos de extremidade de serviço da conta de armazenamento, de modo que os pontos de extremidade da região secundária se tornem os novos pontos de extremidade primários para sua conta de armazenamento. Depois que o failover for concluído, os clientes poderão começar a gravar nos novos pontos de extremidade primários.

As configurações de redundância RA-GRS e RA-GZRS fornecem armazenamento com redundância geográfica com o benefício adicional do acesso de leitura ao ponto de extremidade secundário se houver uma interrupção na região primária. Se ocorrer uma interrupção no ponto de extremidade primário, os aplicativos configurados para acesso de leitura à região secundária e projetados para alta disponibilidade poderão continuar a ser lidos do ponto de extremidade secundário. A Microsoft recomenda RA-GZRS para disponibilidade máxima e durabilidade de suas contas de armazenamento.

Para obter mais informações sobre redundância no Armazenamento do Azure, confira Redundância do Armazenamento do Azure.

Planejar o failover da conta de armazenamento

As contas de Armazenamento do Microsoft Azure dão suporte a dois tipos de failover:

1O failover gerenciado pela Microsoft não pode ser iniciado para contas de armazenamento individuais, assinaturas ou locatários. Para obter mais detalhes, consulte Failover gerenciado pela Microsoft.
2 Seu plano de recuperação de desastre deve ser baseado no failover gerenciado pelo cliente. Não confie no failover gerenciado pela Microsoft, que só seria usado em circunstâncias extremas.

Cada tipo de failover tem um conjunto exclusivo de casos de uso, expectativas correspondentes para perda de dados e suporte para contas com um namespace hierárquico habilitado (Azure Data Lake Storage Gen2). Esta tabela resume esses aspectos de cada tipo de failover:

Tipo Escopo de failover Caso de uso Perda de dados esperada HNS com suporte
Gerenciado pelo cliente Conta de armazenamento Os pontos de extremidade do serviço de armazenamento para a região primária ficam indisponíveis, mas a região secundária está disponível.

Você recebeu um Aviso do Azure no qual a Microsoft aconselha você a executar uma operação de failover de contas de armazenamento potencialmente afetadas por uma interrupção.		 Sim Sim (na versão prévia)
gerenciada pela Microsoft Região inteira ou unidade de escala A região primária fica completamente indisponível devido a um desastre significativo, mas a região secundária está disponível. Sim Sim

Failover gerenciado pelo cliente

Se os pontos de extremidade de dados dos serviços de armazenamento em sua conta de armazenamento ficarem indisponíveis na região primária, você poderá fazer failover para a região secundária. Depois que o failover for concluído, a região secundária se tornará a nova primária e os usuários poderão continuar a acessar dados na nova região primária.

Para entender completamente o impacto que o failover de conta gerenciada pelo cliente teria em seus usuários e aplicativos, é útil saber o que acontece durante cada etapa do processo de failover e failback. Para obter detalhes sobre como o processo funciona, consulte Como funciona o failover da conta de armazenamento gerenciada pelo cliente.

Failover gerenciado pela Microsoft

Em circunstâncias extremas em que a região primária original é considerada irrecuperável dentro de um período razoável devido a um grande desastre, a Microsoft pode iniciar um failover regional. Nesse caso, nenhuma ação sua é necessária. Você não terá acesso para gravação na conta de armazenamento até que o failover gerenciado pela Microsoft seja concluído. Os aplicativos poderão ler da região secundária se a sua conta de armazenamento estiver configurada para RA-GRS ou RA-GZRS.

Importante

Seu plano de recuperação de desastre deve ser baseado no failover gerenciado pelo cliente. Não confie no failover gerenciado pela Microsoft, que só pode ser usado em circunstâncias extremas. Um failover gerenciado pela Microsoft seria iniciado para uma unidade física inteira, como uma região ou uma unidade de escala. Ele não pode ser iniciado para contas de armazenamento individuais, assinaturas ou locatários. Para obter a capacidade de fazer failover seletivo de suas contas de armazenamento individuais, use o failover da conta gerenciada pelo cliente.

Prever perda de dados e inconsistências

Cuidado

O failover da conta de armazenamento geralmente envolve algumas perdas de dados e, potencialmente, inconsistências de arquivos e dados. Em seu plano de recuperação de desastre, é importante considerar o impacto que um failover de conta teria em seus dados antes de iniciar um.

Como os dados são gravados de forma assíncrona da região primária para a região secundária, sempre há um atraso antes que uma gravação na região primária seja copiada para a secundária. Se a região primária ficar indisponível, as gravações mais recentes ainda poderão não ter sido copiadas para o secundário.

Quando ocorre um failover, todos os dados na região primária são perdidos à medida que a região secundária se torna a nova primária. Todos os dados já copiados para a região secundária são mantidos quando ocorre o failover. No entanto, todos os dados gravados no primário que também não foram copiados para a região secundária são perdidos permanentemente.

A nova região primária está configurada para ser LRS (com redundância local) após o failover.

Você também poderá experimentar inconsistências de arquivos ou dados se suas contas de armazenamento tiverem uma ou mais das seguintes habilitadas:

Hora da última sincronização

A propriedade Hora da última sincronização indica o momento mais recente em que os dados da região primária foram certamente gravados na região secundária. Para contas que têm um namespace hierárquico, a mesma propriedade Last Sync Time também se aplica aos metadados gerenciados pelo namespace hierárquico, incluindo ACLs. Todos os dados e metadados gravados antes do último horário de sincronização estão disponíveis na região secundária, enquanto os dados e metadados gravados após o último horário de sincronização podem não ter sido gravados na região secundária e podem ser perdidos. Use essa propriedade se houver uma interrupção para estimar a quantidade de perda de dados que você pode incorrer iniciando um failover de conta.

Como prática recomendada, projete seu aplicativo de modo que seja possível usar a hora da última sincronização para avaliar a estimativa de perda de dados. Por exemplo, se você estiver registrando todas as operações de gravação, poderá comparar a hora das últimas operações de gravação com a hora da última sincronização para determinar quais gravações não foram sincronizadas com o secundário.

Para obter mais informações sobre como verificar a propriedade Horário da Última Sincronização, confira Verificar a propriedade Horário da Última Sincronização de uma conta de armazenamento.

Consistência de arquivo para Azure Data Lake Storage Gen2

A replicação para contas de armazenamento com um namespace hierárquico habilitado (Azure Data Lake Storage Gen2) ocorre no nível do arquivo. Isso significa que, se ocorrer uma interrupção na região primária, é possível que apenas alguns dos arquivos em um contêiner ou diretório possam ter sido replicados com êxito para a região secundária. A consistência de todos os arquivos em um contêiner ou diretório após um failover de conta de armazenamento não é garantida.

Inconsistências entre os dados de blob e o feed de alterações

O failover de contas de armazenamento com redundância geográfica com feed de alterações habilitado pode resultar em inconsistências entre os logs de feed de alterações e os dados de blob e/ou metadados. Essas inconsistências podem ser um resultado da natureza assíncrona das duas atualizações: dos logs de alterações e da replicação de dados de blob da região primária para a secundária. A única situação em que as inconsistências não seriam esperadas é quando todos os registros de log atuais foram liberados com êxito para os arquivos de log e todos os dados de armazenamento foram replicados com êxito da região primária para a secundária.

Para obter informações sobre como funciona o feed de alterações, confira Como funciona o feed de alterações.

Tenha em mente que outros recursos da conta de armazenamento — como o backup operacional de Armazenamento de Blobs do Azure, a replicação de objetos e a restauração pontual de blobs de blocos — requerem que o feed de alterações esteja habilitado.

Inconsistências de restauração pontual

O failover gerenciado pelo cliente é compatível com as contas de armazenamento de nível padrão v2 para uso geral que incluam blobs de blocos. No entanto, executar um failover gerenciado pelo cliente em uma conta de armazenamento reinicializa para o ponto de restauração mais distante no tempo possível disponível na conta. Os dados de restauração pontual para blobs de blocos são consistentes apenas até a hora da realização do failover. Como resultado, você só pode restaurar blobs de blocos para um ponto no tempo que não seja anterior à hora da realização do failover. Você pode verificar a hora da realização do failover na guia de redundância da sua conta de armazenamento no Portal do Azure.

Por exemplo, caso você tenha definido o período de retenção para 30 dias. Caso tenham se passado mais de 30 dias desde o failover, você pode restaurar para qualquer ponto dentro desses 30 dias. No entanto, se tiverem decorrido menos de 30 dias desde o failover, você não poderá restaurar até um ponto anterior ao failover, independentemente do período de retenção. Por exemplo, se fizer 10 dias desde o failover, o ponto de restauração mais antigo possível é 10 dias atrás, e não 30 dias atrás.

O tempo e o custo do failover

O tempo necessário para que o failover seja concluído após ser iniciado pode variar, embora normalmente leve menos de uma hora.

Um failover gerenciado pelo cliente perde sua redundância geográfica após um failover (e failback). Sua conta de armazenamento é convertida automaticamente em LRS (armazenamento com redundância local) na nova região primária durante um failover e a conta de armazenamento na região primária original é excluída.

Você pode reabilitar o GRS (armazenamento com redundância geográfica) ou o RA-GRS (armazenamento com redundância geográfica de acesso de leitura) para a conta, mas observe que a conversão de LRS em GRS ou RA-GRS gera um custo adicional. O custo se deve aos preços de saída de rede para replicar novamente os dados para a região secundária nova. Além disso, todos os blobs arquivados precisam ser reidratados para uma camada online antes que a conta possa ser configurada para redundância geográfica, o que incorrerá em um custo. Para obter mais informações sobre preços, consulte:

Depois de habilitar novamente o GRS para sua conta de armazenamento, a Microsoft começa a replicar os dados em sua conta para a nova região secundária. O tempo de replicação depende de muitos fatores, que incluem:

  • O número e tamanho dos objetos na conta de armazenamento. Replicar muitos objetos pequenos pode levar mais tempo do que replicar objetos cada vez maiores.
  • Os recursos disponíveis para replicação em segundo plano, como a capacidade de CPU, memória, disco e WAN. O tráfego em tempo real tem prioridade sobre a replicação geográfica.
  • Se sua conta de armazenamento contiver blobs, o número de instantâneos por blob.
  • Se sua conta de armazenamento contiver tabelas, a estratégia de particionamento de dados. O processo de replicação não pode escalar além do número de chaves de partição que você usa.

Tipos de conta de armazenamento suportados

Todas as ofertas com redundância geográfica dão suporte ao failover gerenciado pela Microsoft. Além disso, alguns tipos de conta dão suporte ao failover de conta gerenciada pelo cliente, conforme mostrado na tabela a seguir:

Tipo de failover GRS/RA-GRS GZRS/RA-GZRS
Failover gerenciado pelo cliente Contas v2 de finalidade geral
contas v1 de finalidade gera
contas herdadas de Armazenamento de Blobs		 Contas para uso geral v2
Failover gerenciado pela Microsoft Todos os tipos de conta Contas para uso geral v2

Conta de armazenamento clássicas

Importante

O failover de conta gerenciada pelo cliente só é compatível com contas de armazenamento implantadas por meio do modelo de implantação do Azure Resource Manager (ARM). O modelo de implantação do ASM (Azure Service Manager), também conhecido como clássico, não tem suporte. Para tornar as contas de armazenamento clássicas qualificadas para failover de conta gerenciada pelo cliente, elas devem primeiro ser migradas para o modelo do ARM. Sua conta de armazenamento deve estar acessível para executar a atualização, portanto, a região primária não pode estar em um estado com falha no momento.

se houver um desastre que afete a região primária, a Microsoft gerenciará o failover para contas de armazenamento clássicas. Para obter mais informações, consulte failover gerenciado pela Microsoft.

Azure Data Lake Storage Gen2

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.

se houver 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.

Recursos e serviços sem suporte

Não há suporte para os seguintes recursos e serviços para failover de conta:

  • A Sincronização de Arquivos do Azure não dá suporte ao failover de conta de armazenamento iniciado pelo cliente. Contas de armazenamento que contêm compartilhamentos de arquivos do Azure que estão sendo usados como pontos de extremidade de nuvem na Sincronização de Arquivos do Azure não devem ter failover. Se isso for feito, a sincronização deixará de funcionar e poderá causar a perda inesperada de dados no caso de arquivos recentes em camadas. Para saber mais, confira Melhores práticas para recuperação de desastres com a Sincronização de Arquivos do Azure.
  • Não é possível fazer failover de uma conta de armazenamento que contém blobs de blocos premium. As contas de armazenamento que dão suporte a blobs de blocos premium atualmente não dão suporte à redundância geográfica.
  • O failover gerenciado pelo cliente não é compatível com a conta de origem ou de destino de uma política de replicação de objeto.
  • Para fazer failover de uma conta com o Protocolo FTP de SSH (SFTP) habilitado, você deve primeiro desabilitar o SFTP para a conta. Se você quiser voltar a usar o SFTP após a conclusão do failover, habilite-o novamente.
  • O NFS 3.0 (Sistema de Arquivos de Rede) 3.0 (NFSv3) não tem suporte para failover da conta de armazenamento. Você não pode criar uma conta de armazenamento configurada para redundância global com o NFSv3 habilitado.

O failover não é para migração de conta

O failover da conta de armazenamento não deve ser usado como parte de sua estratégia de migração de dados. O failover é uma solução temporária para uma interrupção de serviço. Para obter informações sobre como migrar suas contas de armazenamento, consulte a visão geral da migração do Armazenamento do Microsoft Azure.

Contas de armazenamento que contêm blobs arquivados

As contas de armazenamento que contêm blobs arquivados dão suporte a failover de conta. No entanto, depois que um failover gerenciado pelo cliente for concluído, todos os blobs arquivados precisarão ser reidratados para uma camada online antes que a conta possa ser configurada para redundância geográfica.

Provedor de recursos de armazenamento

A Microsoft fornece duas APIs REST para trabalhar com recursos de Armazenamento do Microsoft Azure. Essas APIs formam a base de todas as ações que você pode executar no Armazenamento do Microsoft Azure. A API REST de Armazenamento do Microsoft Azure permite que você trabalhe com os dados em sua conta de armazenamento, incluindo dados de blobs, filas, arquivos e tabelas. A API REST do provedor de recursos do Armazenamento do Microsoft Azure permite que você trabalhe com a conta de armazenamento e os recursos relacionados.

Depois que um failover é concluído, os clientes voltam a poder ler e gravar dados do Armazenamento do Azure na nova região primária. No entanto, como o provedor de recursos do Armazenamento do Azure não realiza failover, as operações de gerenciamento de recursos ainda devem ocorrer na região primária. Se a região primária não estiver disponível, não será possível executar operações de gerenciamento na conta de armazenamento.

Como o provedor de recursos do Armazenamento do Azure não realiza failover, a propriedade Local retornará o local primário original após a conclusão do failover.

Máquinas virtuais do Azure

As VMs (máquinas virtuais) do Azure não fazem failover como parte de um failover de conta. Se a região primária ficar indisponível, e você fizer o failover para a região secundária, será preciso recriar todas as VMs após o failover. Além disso, há uma possível perda de dados associada ao failover da conta. A Microsoft recomenda seguir as diretrizes de alta disponibilidade e recuperação de desastre específicas para máquinas virtuais no Azure.

Tenha em mente que todos os dados armazenados em um disco temporário serão perdidos quando a VM for desligada.

Discos não gerenciados do Azure

Como prática recomendada, a Microsoft aconselha converter os discos não gerenciados em discos gerenciados. No entanto, se você precisar fazer o failover em uma conta que contenha discos não gerenciados anexados a VMs do Azure, será necessário desligar a VM antes de iniciar o failover.

Os discos não gerenciados são armazenadas como blobs de páginas no Armazenamento do Azure. Quando uma VM está em execução no Azure, todos os discos não gerenciados anexados à VM são concedidos. Um failover de conta não pode continuar quando há uma concessão em um blob. Para realizar o failover, siga estas etapas:

  1. Antes de começar, anote os nomes de todos os discos não gerenciados, seus números de unidade lógica (LUN) e a VM à qual eles estão anexados. Isso facilitará anexar os discos novamente após o failover.
  2. Desligue a VM.
  3. Exclua a VM, mas mantenha os arquivos VHD para os discos não gerenciados. Anote a hora que você excluiu a VM.
  4. Aguarde até que a Hora da última sincronização seja atualizada, ela deve posterior à hora em que você excluiu a VM. Essa etapa é importante, pois se o ponto de extremidade secundário não tiver sido totalmente atualizado com os arquivos VHD quando o failover ocorrer, a VM poderá não funcionar corretamente na nova região primária.
  5. Inicie o failover da conta.
  6. Aguarde até que o failover da conta esteja concluído e a região secundária tenha se tornado a nova região primária.
  7. Crie uma VM na nova região primária e anexe novamente os VHDs.
  8. Inicie a nova VM.

Tenha em mente que todos os dados armazenados em um disco temporário serão perdidos quando a VM for desligada.

Copiando dados como uma alternativa ao failover

Se sua conta de armazenamento estiver configurada para acesso de leitura à região secundária, você poderá projetar seu aplicativo para ler do ponto de extremidade secundário. Se você preferir não fazer failover se houver uma interrupção na região primária, poderá usar ferramentas como o AzCopy ou o Azure PowerShell para copiar dados de sua conta de armazenamento na região secundária para outra conta de armazenamento em uma região não afetada. Você poderá, então, direcionar os aplicativos para essa conta de armazenamento para a disponibilidade de leitura e de gravação.

Projetando para a alta disponibilidade

É importante projetar seu aplicativo para ter uma alta disponibilidade desde o início. Consulte estes recursos do Azure para obter orientações sobre como projetar seu aplicativo e sobre o planejamento para a recuperação de desastre:

Tenha em mente estas práticas recomendadas para manter a alta disponibilidade para seus dados do Armazenamento do Microsoft Azure:

  • Discos: use o Backup do Azure para fazer backup dos discos de VM usados pelas máquinas virtuais do Azure. Considere também usar o Azure Site Recovery para proteger suas VMs se houver um desastre regional.
  • Blobs de blocos: ative a exclusão reversível para proteger contra substituições e exclusões no nível de objeto ou copie blobs de blocos para outra conta de armazenamento em uma região diferente usando o AzCopy, o Azure PowerShell ou a Biblioteca de Movimentação de Dados do Azure.
  • Arquivos: use o Backup do Azure para fazer backup dos compartilhamentos de arquivos. Habilite também a exclusão reversível para proteger contra exclusões acidentais de compartilhamentos de arquivos. Para redundância geográfica quando o GRS não estiver disponível, use o AzCopy ou o Azure PowerShell para copiar seus arquivos para outra conta de armazenamento em uma região diferente.
  • Tabelas: use o AzCopy para exportar os dados de tabela para outra conta de armazenamento em uma região diferente.

Acompanhar interrupções

Os clientes podem assinar o Painel de Integridade do Serviço do Azure para acompanhar a integridade e o status do armazenamento do Azure e de outros serviços do Azure.

A Microsoft também recomenda que você projete seu aplicativo de forma a se preparar para a possibilidade de falhas de gravação. Seu aplicativo deve expor falhas de gravação de forma que o alerte para a possibilidade de uma interrupção na região primária.

Confira também