Planejamento e failover de recuperação de desastres do armazenamento do Azure
A Microsoft se esforça para garantir que os serviços do Azure estejam sempre disponíveis. No entanto, podem ocorrer interrupções de serviço não planejadas. Os principais componentes de um bom plano de recuperação de desastres incluem estratégias para:
- Proteção de dados
- Backup e restauro
- Redundância de dados
- Ativação pós-falha
- Projetando aplicativos para alta disponibilidade
Este artigo se concentra em failover para contas de armazenamento globalmente redundantes (GRS, GZRS e RA-GZRS) e como projetar seus aplicativos para estarem altamente disponíveis se houver uma interrupção e failover subsequente.
Escolha a opção de redundância certa
O Armazenamento do Azure mantém várias cópias da sua conta de armazenamento para garantir durabilidade e alta disponibilidade. A opção de redundância que escolher para a sua conta depende do grau de resiliência de que necessita para as suas aplicações.
Com o LRS (armazenamento com redundância local), três cópias da sua conta de armazenamento são automaticamente armazenadas e replicadas 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 dentro da 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.
Armazenamento e failover globalmente redundantes
Com armazenamento globalmente redundante (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 principal. Um recurso que distingue o armazenamento globalmente redundante do LRS e do ZRS é a capacidade de 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 seus pontos de extremidade de serviço de conta de armazenamento de modo que os pontos de extremidade para a região secundária se tornem os novos pontos de extremidade primários para sua conta de armazenamento. Quando o failover estiver 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 de 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 ler a partir do ponto de extremidade secundário. A Microsoft recomenda o RA-GZRS para máxima disponibilidade e durabilidade de suas contas de armazenamento.
Para obter mais informações sobre redundância no Armazenamento do Azure, consulte Redundância do Armazenamento do Azure.
Planejar o failover da conta de armazenamento
As contas de Armazenamento do Azure dão suporte a dois tipos de failover:
- Failover gerenciado pelo cliente - Os clientes podem gerenciar o failover da conta de armazenamento se houver uma interrupção inesperada do serviço.
- Failover gerenciado pela Microsoft - Potencialmente iniciado pela Microsoft somente no caso de um desastre grave na região principal. 1,2
1 O failover gerenciado pela Microsoft não pode ser iniciado para contas de armazenamento, assinaturas ou locatários individuais. Para obter mais detalhes, consulte failover gerenciado pela Microsoft.
2 Seu plano de recuperação de desastres deve ser baseado em 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 os aspetos de cada tipo de failover:
| Type | Escopo de failover | Caso de utilização | Perda de dados esperada | HNS suportado |
|---|---|---|---|---|
| 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 Comunicado do Azure no qual a Microsoft o aconselha a executar uma operação de failover de contas de armazenamento potencialmente afetadas por uma interrupção. |
Sim | Sim (Em pré-visualização) |
| Gerenciado pela Microsoft | Toda a região ou unidade de escala | A região primária torna-se 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 para os 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. Após a conclusão do failover, a região secundária se torna a nova primária e os usuários podem continuar a acessar os dados na nova região primária.
Para entender completamente o impacto que o failover de conta gerenciado 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 de conta de armazenamento gerenciado 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 de tempo razoável devido a um desastre de grandes proporções, a Microsoft pode iniciar um failover regional. Neste caso, nenhuma ação da sua parte é necessária. Até que o failover gerenciado pela Microsoft seja concluído, você não terá acesso de gravação à sua conta de armazenamento. Seus aplicativos podem ler a partir da região secundária se sua conta de armazenamento estiver configurada para RA-GRS ou RA-GZRS.
Importante
Seu plano de recuperação de desastres 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 unidade de escala. Não pode ser iniciado para contas de armazenamento individuais, subscrições ou inquilinos. Para obter a capacidade de fazer failover seletivamente de suas contas de armazenamento individuais, use o failover de conta gerenciado pelo cliente.
Antecipe a perda de dados e inconsistências
Atenção
O failover de conta de armazenamento geralmente envolve alguma perda de dados e, potencialmente, inconsistências de arquivos e dados. Em seu plano de recuperação de desastres, é 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, há sempre 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 podem ainda não ter sido copiadas para a secundária.
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 o secundário são mantidos quando o failover acontece. 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 é configurada para ser localmente redundante (LRS) após o failover.
Você também pode enfrentar inconsistências de arquivos ou dados se suas contas de armazenamento tiverem uma ou mais das seguintes opções habilitadas:
- Namespace hierárquico (Azure Data Lake Storage Gen2)
- Alterar feed
- Restauração point-in-time para blobs de bloco
Hora da última sincronização
A propriedade Last Sync Time indica a hora mais recente em que os dados da região primária têm a garantia de ter sido 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 da última hora de sincronização estão disponíveis no secundário, enquanto os dados e metadados gravados após o último tempo de sincronização podem não ter sido gravados no secundário e podem ser perdidos. Use essa propriedade se houver uma interrupção para estimar a quantidade de perda de dados que você pode incorrer ao iniciar um failover de conta.
Como prática recomendada, projete seu aplicativo para que você possa usar o último tempo de sincronização para avaliar a perda de dados esperada. 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 última hora de sincronização para determinar quais gravações não foram sincronizadas com a secundária.
Para obter mais informações sobre como verificar a propriedade Last Sync Time , consulte Verifique a propriedade Last Sync Time para uma conta de armazenamento.
Consistência de arquivo para o 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 tenham 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.
Alterar inconsistências de dados de feed e blob
O failover de conta de armazenamento de contas de armazenamento com redundância geográfica com o feed de alterações habilitado pode resultar em inconsistências entre os logs do feed de alterações e os dados e/ou metadados de blob. Essas inconsistências podem resultar da natureza assíncrona das 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 o feed de alterações funciona, consulte Como funciona o feed de alterações.
Lembre-se de que outros recursos de conta de armazenamento exigem que o feed de alterações seja habilitado, como backup operacional do Armazenamento de Blobs do Azure, replicação de objetos e restauração point-in-time para blobs de bloco.
Inconsistências de restauração point-in-time
O failover gerenciado pelo cliente é suportado para contas de armazenamento de nível padrão v2 de uso geral que incluem blobs de bloco. No entanto, executar um failover gerenciado pelo cliente em uma conta de armazenamento redefine o ponto de restauração mais cedo possível para a conta. Os dados para restauração point-in-time para blobs de bloco só são consistentes até o tempo de conclusão do failover. Como resultado, você só pode restaurar blobs de bloco para um ponto no tempo não anterior ao tempo de conclusão do failover. Você pode verificar o tempo de conclusão do failover na guia redundância da sua conta de armazenamento no Portal do Azure.
Por exemplo, suponha que você tenha definido o período de retenção para 30 dias. Se tiverem decorrido mais de 30 dias desde o failover, você poderá 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 para um ponto anterior ao failover, independentemente do período de retenção. Por exemplo, se tiverem passado 10 dias desde o failover, o ponto de restauração mais cedo possível será 10 dias no passado, não 30 dias no passado.
O tempo e o custo do failover
O tempo que o failover leva para ser 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 reativar o armazenamento com redundância geográfica (GRS) ou o armazenamento com redundância geográfica de acesso de leitura (RA-GRS) para a conta, mas observe que a conversão de LRS para GRS ou RA-GRS incorre em um custo adicional. O custo deve-se às taxas de saída da rede para replicar novamente os dados para a nova região secundária. 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 reativar 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 o tamanho dos objetos na conta de armazenamento. Replicar muitos objetos pequenos pode levar mais tempo do que replicar menos objetos e maiores.
- Os recursos disponíveis para replicação em segundo plano, como CPU, memória, disco e capacidade 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 ser dimensionado 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 suportam failover gerenciado pela Microsoft. Além disso, alguns tipos de conta oferecem suporte ao failover de conta gerenciado pelo cliente, conforme mostrado na tabela a seguir:
| Tipo de failover | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|
| Failover gerenciado pelo cliente | Contas v2 de uso geral Contas v1 de uso geral Contas de armazenamento de Blob herdadas | Contas de armazenamento para fins gerais v2 |
| Failover gerenciado pela Microsoft | Todos os tipos de conta | Contas de armazenamento para fins gerais v2 |
Contas de armazenamento clássicas
Importante
O failover de conta gerenciado pelo cliente só é suportado para contas de armazenamento implantadas usando o modelo de implantação do Azure Resource Manager (ARM). O modelo de implantação do Azure Service Manager (ASM), também conhecido como clássico, não é suportado. Para tornar as contas de armazenamento clássicas qualificadas para failover de conta gerenciada pelo cliente, elas devem primeiro ser migradas para o modelo ARM. Sua conta de armazenamento deve estar acessível para executar a atualização, para que a região primária não possa estar atualmente em um estado de falha.
se houver um desastre que afete a região principal, a Microsoft gerenciará o failover para contas de armazenamento clássicas. Para obter mais informações, veja Ativação pós-falha gerida pela Microsoft.
Azure Data Lake Storage Gen2
Importante
O failover de conta gerenciado pelo cliente para contas que têm um namespace hierárquico (Azure Data Lake Storage Gen2) está atualmente em PREVIEW e só tem suporte 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.
se houver 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.
Funcionalidades e serviços não suportados
Os seguintes recursos e serviços não são suportados para failover de conta:
- O Azure File Sync não oferece suporte ao failover de conta de armazenamento iniciado pelo cliente. As contas de armazenamento que contêm compartilhamentos de arquivos do Azure sendo usadas como pontos de extremidade de nuvem na Sincronização de Arquivos do Azure não devem ser objeto de failover. Se a fizer, fará com que a sincronização deixe de funcionar e poderá também causar perdas de dados inesperadas em caso de ficheiros com novo escalão. Para obter mais informações, consulte Práticas recomendadas para recuperação de desastres com o Azure File Sync para obter detalhes.
- Não é possível fazer failover de uma conta de armazenamento que contenha blobs de bloco premium. Atualmente, as contas de armazenamento que suportam blobs de bloco premium não suportam redundância geográfica.
- Não há suporte para failover gerenciado pelo cliente para a conta de origem ou de destino em uma política de replicação de objetos.
- Para fazer failover de uma conta com o SSH File Transfer Protocol (SFTP) habilitado, você deve primeiro desabilitar o SFTP para a conta. Se você quiser continuar usando o SFTP após a conclusão do failover, basta reativá-lo.
- O Network File System (NFS) 3.0 (NFSv3) não é suportado para failover de conta de armazenamento. Não é possível criar uma conta de armazenamento configurada para redundância global com NFSv3 habilitado.
O failover não é para migração de conta
O failover de conta de armazenamento não deve ser usado como parte da 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 Visão geral da migração do Armazenamento do Azure.
Contas de armazenamento contendo blobs arquivados
Contas de armazenamento contendo blobs arquivados suportam failover de conta. No entanto, após a conclusão de um failover gerenciado pelo cliente, todos os blobs arquivados precisam ser reidratados para uma camada online antes que a conta possa ser configurada para redundância geográfica.
Fornecedor de recursos de armazenamento
A Microsoft fornece duas APIs REST para trabalhar com recursos de Armazenamento do Azure. Essas APIs formam a base de todas as ações que você pode executar no Armazenamento do Azure. A API REST do Armazenamento do Azure permite que você trabalhe com dados em sua conta de armazenamento, incluindo dados de blob, fila, arquivo e tabela. A API REST do provedor de recursos de Armazenamento do Azure permite gerenciar a conta de armazenamento e os recursos relacionados.
Após a conclusão de um failover, os clientes podem ler e gravar novamente os dados do Armazenamento do Azure na nova região primária. No entanto, o provedor de recursos de Armazenamento do Azure não faz failover, portanto, as operações de gerenciamento de recursos ainda devem ocorrer na região primária. Se a região principal não estiver disponível, você não poderá executar operações de gerenciamento na conta de armazenamento.
Como o provedor de recursos de Armazenamento do Azure não faz failover, a propriedade Location retornará o local primário original após a conclusão do failover.
Máquinas virtuais do Azure
As máquinas virtuais (VMs) 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 failover para a região secundária, será necessário 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 desastres específicas para máquinas virtuais no Azure.
Lembre-se de que todos os dados armazenados em um disco temporário são perdidos quando a VM é desligada.
Discos não gerenciados do Azure
Como prática recomendada, a Microsoft recomenda converter discos não gerenciados em discos gerenciados. No entanto, se você precisar fazer failover de 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 armazenados como blobs de página no Armazenamento do Azure. Quando uma VM está em execução no Azure, todos os discos não gerenciados anexados à VM são alugados. Um failover de conta não pode continuar quando há uma concessão em um blob. Para executar o failover, siga estas etapas:
- Antes de começar, observe os nomes de quaisquer discos não gerenciados, seus números de unidade lógica (LUN) e a VM à qual eles estão anexados. Isso facilitará a reconexão dos discos após o failover.
- Desligue a VM.
- Exclua a VM, mas mantenha os arquivos VHD para os discos não gerenciados. Observe o momento em que você excluiu a VM.
- Aguarde até que a Última Hora de Sincronização tenha sido atualizada e seja posterior à hora em que você excluiu a VM. Esta etapa é importante, porque se o ponto de extremidade secundário não tiver sido totalmente atualizado com os arquivos VHD quando o failover ocorrer, a VM pode não funcionar corretamente na nova região primária.
- Inicie o failover da conta.
- Aguarde até que o failover de conta seja concluído e a região secundária se torne a nova região primária.
- Crie uma VM na nova região primária e reconecte os VHDs.
- Inicie a nova VM.
Lembre-se de que todos os dados armazenados em um disco temporário são perdidos quando a VM é desligada.
Copiar dados como alternativa à ativação pós-falha
Se sua conta de armazenamento estiver configurada para acesso de leitura à região secundária, você poderá projetar seu aplicativo para leitura a partir do ponto de extremidade secundário. Se preferir não fazer failover se houver uma interrupção na região primária, você pode usar ferramentas como AzCopy ou 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. Em seguida, você pode apontar seus aplicativos para essa conta de armazenamento para disponibilidade de leitura e gravação.
Criar para elevada disponibilidade
É importante projetar seu aplicativo para alta disponibilidade desde o início. Consulte estes recursos do Azure para obter orientação sobre como projetar seu aplicativo e planejar a recuperação de desastres:
- Projetando aplicativos resilientes para o Azure: uma visão geral dos principais conceitos para arquitetar aplicativos altamente disponíveis no Azure.
- Lista de verificação de resiliência: uma lista de verificação para verificar se seu aplicativo implementa as práticas recomendadas de design para alta disponibilidade.
- Use a redundância geográfica para projetar aplicativos altamente disponíveis: Diretrizes de projeto para a criação de aplicativos para aproveitar o armazenamento com redundância geográfica.
- Tutorial: Crie um aplicativo altamente disponível com armazenamento de Blob: um tutorial que mostra como criar um aplicativo altamente disponível que alterna automaticamente entre pontos de extremidade à medida que falhas e recuperações são simuladas.
Lembre-se destas práticas recomendadas para manter a alta disponibilidade de seus dados de Armazenamento do Azure:
- Discos: use o Backup do Azure para fazer backup dos discos de VM usados por suas máquinas virtuais do Azure. Considere também usar o Azure Site Recovery para proteger suas VMs se houver um desastre regional.
- Blobs de bloco: ative a exclusão suave para proteger contra exclusões e substituições no nível do objeto ou copie blobs de bloco para outra conta de armazenamento em uma região diferente usando o AzCopy, o Azure PowerShell ou a biblioteca do Azure Data Movement.
- Arquivos: use o Backup do Azure para fazer backup de seus compartilhamentos de arquivos. Também habilite a exclusão suave para proteger contra exclusões acidentais de compartilhamento 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 AzCopy para exportar dados de tabela para outra conta de armazenamento em uma região diferente.
Acompanhe interrupções
Os clientes podem subscrever o Painel de Estado de Funcionamento do Serviço do Azure para controlar o estado de funcionamento e o estado do Armazenamento do Azure e de outros serviços do Azure.
A Microsoft também recomenda que crie a sua aplicação para a possibilidade de falhas de escrita. A aplicação deve expor as falhas de escrita de forma a alertá-lo para a possibilidade de uma interrupção na região primária.