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, interrupções de serviço não planejadas podem ocorrer ocasionalmente. 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 descreve as opções disponíveis para contas de armazenamento com redundância geográfica e fornece recomendações para desenvolver aplicativos altamente disponíveis e testar seu plano de recuperação de desastres.
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 que as metas de disponibilidade e durabilidade sejam atingidas, mesmo em caso de falhas. A forma como os dados são replicados proporciona diferentes níveis de proteção. Cada opção oferece os seus próprios benefícios, pelo que a opção escolhida depende do grau de resiliência que as suas aplicações exigem.
O LRS (Locally Redundant Storage, armazenamento com redundância local), a opção de redundância de menor custo, armazena e replica automaticamente três cópias da sua conta de armazenamento em um único datacenter. Embora o LRS proteja seus dados contra falhas de rack e drive do servidor, ele não leva em conta desastres como incêndio ou inundação dentro de um datacenter. Diante desses desastres, todas as réplicas de uma conta de armazenamento configurada para usar o LRS podem ser perdidas ou irrecuperáveis.
Em comparação, o ZRS (armazenamento com redundância de zona) retém uma cópia de uma conta de armazenamento e a replica 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.
Failover e armazenamento com redundância geográfica
O armazenamento com redundância geográfica (GRS), o armazenamento com redundância de zona geográfica (GZRS) e o armazenamento com redundância de zona geográfica de acesso de leitura (RA-GZRS) são exemplos de opções de armazenamento com redundância geográfica. Quando configurado para usar armazenamento com redundância geográfica (GRS, GZRS e RA-GZRS), o Azure copia seus dados de forma assíncrona para uma região geográfica secundária. Essas regiões estão localizadas a centenas, ou mesmo milhares de quilômetros de distância. Esse nível de redundância permite que você recupere seus dados se houver uma interrupção em toda a região principal.
Ao contrário do LRS e do ZRS, o armazenamento com redundância geográfica também fornece suporte para um failover não planejado para uma região secundária se houver uma interrupção na região primária. Durante o processo de failover, as entradas DNS (Sistema de Nomes de Domínio) para seus pontos de extremidade de serviço de conta de armazenamento são atualizadas automaticamente para que os pontos de extremidade da região secundária se tornem os novos pontos de extremidade primários. Quando o failover não planejado estiver concluído, os clientes poderão começar a gravar nos novos pontos de extremidade primários.
O armazenamento com redundância geográfica de acesso de leitura (RA-GRS) e o armazenamento com redundância de zona geográfica de acesso de leitura (RA-GZRS) também fornecem armazenamento com redundância geográfica, mas oferecem o benefício adicional do acesso de leitura ao ponto de extremidade secundário. Essas opções são ideais para aplicativos projetados para aplicativos críticos para os negócios de alta disponibilidade. Se o ponto de extremidade primário sofrer uma interrupção, os aplicativos configurados para acesso de leitura à região secundária poderão continuar a operar. 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 para o Armazenamento do Azure, consulte Redundância do Armazenamento do Azure.
Planejar failover
As contas de Armazenamento do Azure dão suporte a três tipos de failover:
- Failover planejado gerenciado pelo cliente (visualização) - Os clientes podem gerenciar o failover da conta de armazenamento para testar seu plano de recuperação de desastres.
- Failover gerenciado pelo cliente (não planejado) - 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 devido a 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 informações, veja Ativação pós-falha gerida pela Microsoft.
2 Use opções de failover gerenciadas pelo cliente para desenvolver, testar e implementar seus planos de recuperação de desastres. 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 (Armazenamento Azure Data Lake). Esta tabela resume os aspetos de cada tipo de failover:
| Type | Escopo de failover | Caso de utilização | Perda de dados esperada | Namespace hierárquico (HNS) suportado |
|---|---|---|---|---|
| Failover planejado gerenciado pelo cliente (visualização) | Conta de armazenamento | Os pontos de extremidade do serviço de armazenamento para as regiões primária e secundária estão disponíveis e você deseja executar testes de recuperação de desastres. Os pontos de extremidade do serviço de armazenamento para a região principal estão disponíveis, mas outro serviço está impedindo que suas cargas de trabalho funcionem corretamente. Preparar-se proativamente para desastres de grande escala, como um furacão, que possam afetar uma região. |
Não | Sim (Em pré-visualização) |
| Failover gerenciado pelo cliente (não planejado) | 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 | A região primária torna-se indisponível devido a um desastre significativo, mas a região secundária está disponível. | Sim | Sim |
A tabela a seguir compara o estado de redundância de uma conta de armazenamento após cada tipo de failover:
| Resultado do failover em... | Failover planejado gerenciado pelo cliente (visualização) | Failover gerenciado pelo cliente (não planejado) |
|---|---|---|
| ... a região secundária | A região secundária torna-se a nova região primária | A região secundária torna-se a nova região primária |
| ... a região primária original | A região primária original torna-se a nova região secundária | A cópia dos dados na região primária original é excluída |
| ... A configuração de redundância de conta | A conta de armazenamento é convertida em GRS | A conta de armazenamento é convertida em LRS |
| ... A configuração de redundância geográfica | A redundância geográfica é mantida | Perde-se a redundância geográfica |
A tabela a seguir resume a configuração de redundância resultante em cada estágio do processo de failover e failback para cada tipo de failover:
| Original configuração |
Após ativação pós-falha |
Após a reativação redundância geográfica |
Após Failback |
Após a reativação redundância geográfica |
|---|---|---|---|---|
| Failover planejado gerenciado pelo cliente | ||||
| GRS | GRS | n/a 1 | GRS | n/a 1 |
| GZRS | GRS | n/a 1 | GZRS | n/a 1 |
| Failover gerenciado pelo cliente (não planejado) | ||||
| GRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
1 A redundância geográfica é mantida durante um failover planejado e não precisa ser reconfigurada manualmente.
Failover planejado gerenciado pelo cliente (visualização)
O failover planejado pode ser utilizado em vários cenários, incluindo testes de recuperação de desastres planejados, uma abordagem proativa para desastres de grande escala ou para recuperação de interrupções não relacionadas ao armazenamento.
Durante o processo de failover planejado, as regiões primária e secundária são trocadas. A região primária original é rebaixada e torna-se a nova região secundária. Ao mesmo tempo, a região secundária original é promovida e torna-se a nova primária. Após a conclusão do failover, os usuários podem continuar a acessar os dados na nova região primária e os administradores podem validar seu plano de recuperação de desastres. A conta de armazenamento deve estar disponível nas regiões primária e secundária antes que um failover planejado possa ser iniciado.
A perda de dados não é esperada durante o processo de failover e failback planejado, desde que as regiões primária e secundária estejam disponíveis durante todo o processo. Para obter mais detalhes, consulte a seção Antecipando perda de dados e inconsistências .
Para entender o efeito desse tipo de failover em seus usuários e aplicativos, é útil saber o que acontece durante cada etapa dos processos de failover e failback planejados. Para obter detalhes sobre como esse processo funciona, consulte Como funciona o failover gerenciado pelo cliente (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.
Failover gerenciado pelo cliente (não planejado)
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á iniciar um failover não planejado 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 lá.
Para entender o efeito desse tipo de failover em seus usuários e aplicativos, é útil saber o que acontece durante cada etapa do processo de failover e failback não planejado. Para obter detalhes sobre como o processo funciona, consulte Como funciona o failover gerenciado pelo cliente (não planejado).
Failover gerenciado pela Microsoft
A Microsoft pode iniciar um failover regional em circunstâncias extremas, como um desastre catastrófico que afeta toda uma região geográfica. Durante estes eventos, nenhuma ação da sua parte é necessária. Se sua conta de armazenamento estiver configurada para RA-GRS ou RA-GZRS, seus aplicativos poderão ler a partir da região secundária durante um failover gerenciado pela Microsoft. No entanto, você não tem acesso de gravação à sua conta de armazenamento até que o processo de failover seja concluído.
Importante
Use opções de failover gerenciadas pelo cliente para desenvolver, testar e implementar seus planos de recuperação de desastres. 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 um datacenter. Não pode ser iniciado para contas de armazenamento individuais, subscrições ou inquilinos. Se você precisar da capacidade de fazer failover seletivamente de suas contas de armazenamento individuais, use o failover planejado gerenciado pelo cliente.
Antecipe a perda de dados e inconsistências
Atenção
O failover não planejado gerenciado pelo cliente geralmente envolve alguma quantidade de perda de dados e também pode potencialmente introduzir 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, é possível que as gravações mais recentes ainda não tenham sido copiadas para a secundária.
Quando ocorre um failover não planejado, 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 o failover acontece. No entanto, quaisquer dados gravados no primário que ainda não existam na 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:
- Espaço de nomes hierárquico (Armazenamento Azure Data Lake)
- 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 também foram 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 listas de controle de acesso (ACLs). Todos os dados e metadados gravados antes da última hora de sincronização estão disponíveis no secundário. Por outro lado, os dados e metadados gravados após o último tempo de sincronização podem ainda não ser copiados para o secundário e podem ser perdidos. Durante uma interrupção, use essa propriedade 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 Tempo de Última Sincronização para avaliar a perda de dados esperada. Por exemplo, registrar todas as operações de gravação permite comparar os tempos da última operação de gravação com o último tempo de sincronização. Esse método permite determinar quais gravações ainda não estão sincronizadas com o secundário e correm o risco de serem perdidas.
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 Armazenamento Azure Data Lake
A replicação para contas de armazenamento com um namespace hierárquico habilitado (Armazenamento Azure Data Lake) ocorre no nível do arquivo. Como a replicação ocorre nesse nível, uma interrupção na região primária pode impedir que alguns dos arquivos dentro de um contêiner ou diretório sejam replicados com êxito para a região secundária. A consistência de todos os arquivos dentro de 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 gerenciado pelo cliente (não planejado) de contas de armazenamento 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 do log de alterações e da replicação de dados entre as regiões primária e secundária. Pode evitar inconsistências tomando as seguintes precauções:
- Certifique-se de que todos os registros de log sejam liberados para os arquivos de log.
- Certifique-se de que todos os dados de armazenamento sejam replicados da região primária para a secundária.
Para obter mais informações sobre o feed de alterações, consulte Como funciona o feed de alterações.
Lembre-se de que outros recursos da conta de armazenamento também exigem que o feed de alterações seja habilitado. Esses recursos incluem 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.
O tempo e o custo do failover
O tempo necessário para que um failover gerenciado pelo cliente seja concluído após ser iniciado pode variar, embora normalmente leve menos de uma hora.
Um failover planejado gerenciado pelo cliente não perde sua redundância geográfica após um failover e um failback subsequente, mas um failover não planejado gerenciado pelo cliente perde.
Iniciar um failover não planejado gerenciado pelo cliente converte automaticamente sua conta de armazenamento em LRS (armazenamento com redundância local) em uma nova região primária e exclui a conta de armazenamento na região primária original.
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 a rereplicação de dados para a nova região secundária implica uma cobrança. Além disso, todos os blobs arquivados precisam ser reidratados para uma camada online antes que a conta possa ser reconfigurada para redundância geográfica. Esta reidratação também implica um custo adicional. 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 necessário para a conclusão da replicação depende de vários fatores. Esses fatores 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.
- O número de instantâneos por blob, se aplicável.
- A estratégia de particionamento de dados, se sua conta de armazenamento contiver tabelas. 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 planejado gerenciado pelo cliente (visualização) | 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 pelo cliente (não planejado) | 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 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 modelo 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.
Durante 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.
Espaço de nomes hierárquico (HNS)
Importante
O failover gerenciado pelo cliente (não planejado) para contas que têm o Azure Data Lake Storage Gen2 habilitado está atualmente em PREVIEW e tem suporte em todas as regiões públicas GRS/GZRS.
Para aceitar a visualização, consulte Configurar recursos de visualização na assinatura do Azure e especifique AllowHNSAccountFailover como o nome do recurso.
Importante
O failover gerenciado pelo cliente (não planejado) para contas que têm o SSH File Transfer Protocol (SFTP) habilitado está atualmente em PREVIEW e só é suportado 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.
No caso de 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 gerenciado pelo cliente:
- O Azure File Sync não oferece suporte ao failover de conta gerenciado pelo cliente. As contas de armazenamento usadas como pontos de extremidade de nuvem para o Azure File Sync não devem ser objeto de failover. O failover interrompe a sincronização de arquivos e pode causar a perda inesperada de dados de arquivos recém-hierarquizados. 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.
- 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 geográfica com NFSv3 habilitado.
A tabela a seguir pode ser usada para fazer referência ao suporte a recursos.
| Ativação pós-falha planeada | Ativação pós-falha não planeada | |
|---|---|---|
| Azure Data Lake Storage | Suportado (pré-visualização) | Suportado (pré-visualização) |
| Alterar feed | Não suportado | Suportado |
| Replicação de objetos | Não suportado | Não suportado |
| SFTP | Suportado (pré-visualização) | Suportado (pré-visualização) |
| NFSv3 | O GRS não é suportado | O GRS não é suportado |
| Ações de armazenamento | Suportado1 | Suportado1 |
| Restauração point-in-time (PITR) | Não suportado | Suportado |
1 Se você iniciar um failover planejado ou não planejado gerenciado pelo cliente, as tarefas de armazenamento não poderão operar na conta até que ela retorne à região primária original. Mais informações.
O failover não é para migração de conta
Os failovers de conta de armazenamento são uma solução temporária usada para desenvolver e testar seus planos de recuperação de desastres (DR) ou para se recuperar de uma interrupção de serviço. O failover não deve ser usado como parte da sua estratégia de migração de dados. 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 devem 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 de armazenamento. Todas as VMs que fizeram failover para uma região secundária em resposta a uma interrupção precisam ser recriadas após a conclusão do failover. O failover de conta pode potencialmente resultar na perda de dados armazenados em um disco temporário quando a máquina virtual (VM) é desligada. A Microsoft recomenda seguir as diretrizes de alta disponibilidade e recuperação de desastres específicas para máquinas virtuais no Azure.
Discos não gerenciados do Azure
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. Antes que um failover possa ser iniciado em uma conta que contenha discos não gerenciados anexados a VMs do Azure, os discos devem ser desligados. Por esse motivo, as práticas recomendadas pela Microsoft incluem a conversão de quaisquer discos não gerenciados em discos gerenciados.
Para executar um failover em uma conta que contém discos não gerenciados, execute 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 conectados. Isso facilitará a reconexão dos discos após o failover.
- Desligue a VM.
- Exclua a VM, mas mantenha os arquivos de disco rígido virtual (VHD) para os discos não gerenciados. Observe o momento em que você excluiu a VM.
- Aguarde até que o Último Tempo de Sincronização seja atualizado e verifique se é posterior ao momento em que você excluiu a VM. Esta etapa garante que o ponto de extremidade secundário seja totalmente atualizado com os arquivos VHD quando ocorrer o failover e que a VM funcione 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.
Copiando dados como uma alternativa de failover
Conforme discutido anteriormente, você pode manter a alta disponibilidade configurando aplicativos para usar uma conta de armazenamento configurada para acesso de leitura a uma região secundária. No entanto, se preferir não fazer failover durante uma interrupção na região principal, você pode copiar manualmente seus dados como alternativa. Ferramentas como AzCopy e Azure PowerShell permitem que você copie dados de sua conta de armazenamento na região afetada para outra conta de armazenamento em uma região não afetada. Após a conclusão da operação de cópia, você pode reconfigurar seus aplicativos para usar a conta de armazenamento na região não afetada 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 ao 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.
Consulte estas práticas recomendadas para manter a alta disponibilidade para 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 de 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 o 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.
Consulte também
- Use redundância geográfica para projetar aplicativos altamente disponíveis
- Tutorial: Crie um aplicativo altamente disponível com armazenamento de Blob
- Redundância do Armazenamento do Azure
- Como funciona o failover planejado gerenciado pelo cliente (visualização)
- Como funciona o failover gerenciado pelo cliente (não planejado)