Failover e planejamento de recuperação de desastre do armazenamento do Azure
A Microsoft se empenha em garantir que os serviços do Azure estejam sempre disponíveis. No entanto, interrupções de serviço não planejadas podem ocorrer às vezes. Os principais componentes de um bom plano de recuperação de desastre incluem estratégias para:
- Proteção de dados
- Backup e restauração
- Redundância de dados
- Failover
- Criando aplicativos para alta disponibilidade
Este artigo descreve as opções disponíveis para contas de armazenamento com redundância global e fornece recomendações para desenvolver aplicativos altamente disponíveis e testar o plano de recuperação de desastre.
Escolhendo a opção de redundância correta
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 atendidas, mesmo diante de falhas. A maneira como os dados são replicados fornece diferentes níveis de proteção. Cada opção oferece os próprios benefícios, portanto, a opção escolhida depende do grau de resiliência que os aplicativos exigem.
O LRS (armazenamento com redundância local), a opção de redundância de menor custo, armazena e replica automaticamente três cópias da conta de armazenamento em um único datacenter. Embora o LRS proteja os dados contra falhas de rack de servidor e unidade, ele não percebe desastres como incêndio ou inundações em um datacenter. Diante desses desastres, todas as réplicas de uma conta de armazenamento configurada para usar 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 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 tanto na LRS quanto na ZRS.
Armazenamento e failover com redundância geográfica
O GRS (armazenamento com redundância geográfica), o GZRS (armazenamento com redundância de zona geográfica) e o RA-GZRS (armazenamento com redundância de zona geográfica com de acesso de leitura) são exemplos de opções de armazenamento com redundância global. Quando configurado para utilizar armazenamento globalmente redundante (GRS, GZRS e RA-GZRS), o Azure copia os 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 recuperar os dados caso ocorra uma interrupção em toda a região primária.
Ao contrário do LRS e do ZRS, o armazenamento globalmente redundante 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 os pontos de extremidade do serviço da 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. Depois que o failover não planejado for concluído, os clientes poderão começar a gravar nos novos pontos de extremidade primários.
Os RA-GRS e RA-GZRS também fornecem armazenamento com redundância geográfica, mas oferecem o benefício adicional de acesso de leitura ao ponto de extremidade secundário. Essas opções são ideais para aplicativos criados para aplicativos comercialmente críticos 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 operando. A Microsoft recomenda RA-GZRS para disponibilidade máxima e durabilidade de suas contas de armazenamento.
Para obter mais informações sobre redundância para o Armazenamento do Azure, confira Redundância do Armazenamento do Azure.
Planejar o failover
As contas de Armazenamento do Microsoft Azure dão suporte a três tipos de failover:
- Recuperação planejada gerenciada pelo cliente (versão prévia) – os clientes podem gerenciar o failover da conta de armazenamento para testar o plano de recuperação de desastre.
- 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 primária. 1,2
1 O failover gerenciado pela Microsoft não pode ser iniciado para contas de armazenamento individuais, assinaturas ou locatários. Para obter mais informações, consulte failover gerenciado 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 (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 | Namespace hierárquico (HNS) suportado |
|---|---|---|---|---|
| Failover planejado gerenciado pelo cliente (versão prévia) | 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 desastre. Os pontos de extremidade do serviço de armazenamento para a região primária estão disponíveis, mas outro serviço da Microsoft ou de terceiros está a impedir que as suas cargas de trabalho funcionem corretamente. Preparar-se proativamente para desastres de grande escala, como um furacão, que possam impactar uma região. |
Não | Sim (Em versão prévia) |
| 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 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 (Em versão prévia) |
| gerenciada pela Microsoft | Região inteira | A região primária fica 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 (versão prévia) | Failover gerenciado pelo cliente (não planejado) |
|---|---|---|
| ... na região secundária | A região secundária torna-se a nova primária | A região secundária torna-se a nova primária |
| ... na região primária original | A região primária original torna-se a nova secundária | A cópia dos dados na região primária original é excluída |
| ... na configuração de redundância de conta | A conta de armazenamento é convertida para GRS | A conta de armazenamento é convertida em LRS |
| ... na 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 |
Depois failover |
Após a reativação redundância geográfica |
Depois failback |
Após a reativação redundância geográfica |
|---|---|---|---|---|
| Recuperação planejada gerenciada pelo cliente | ||||
| GRS | GRS | n/a 2 | GRS | n/a 2 |
| GZRS | GRS | n/a 2 | GZRS | n/a 2 |
| Failover gerenciado pelo cliente (não planejado) | ||||
| GRS | LRS | GRS 1 | LRS | GRS 1 |
| GZRS | LRS | GRS 1 | ZRS | GZRS 1 |
1 A redundância geográfica é perdida durante o failover não planejado e deve ser reconfigurada manualmente.
2 A redundância geográfica é mantida durante um failover não planejado e não precisa ser reconfigurada manualmente.
Recuperação planejada gerenciada pelo cliente (versão prévia)
Importante
O failover planejado gerenciado pelo cliente está atualmente em PREVIEW e limitado às seguintes regiões:
- Leste da Austrália
- Centro dos EUA
- Leste da Ásia
- Leste dos EUA 2
- França Central
- Centro da Índia
- Oeste da Índia
- Sudeste Asiático
- Norte da Suíça
- Oeste da Suíça
- Sul do Reino Unido
- Europa Ocidental
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.
Para aceitar a versão prévia, consulte Configurar versão prévia do recurso na assinatura do Azure e especifique AllowSoftFailover como o nome do recurso. O nome do provedor para essa versão prévia do recurso é Microsoft.Storage.
Importante
Após um failover planejado, o valor LST (última hora de sincronização) de uma conta de armazenamento pode parecer obsoleto ou ser relatado como NULL quando os dados dos Arquivos do Azure 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 o failover e o 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, as contas que não têm instantâneos ou atividade do usuário podem continuar exibindo um valor Null LST até que a criação do instantâneo do sistema seja acionada.
Se necessário, execute uma das atividades a seguir para acionar a criação do snapshot. Após a conclusão, sua conta deverá exibir um valor LST válido dentro de 30 minutos.
- Monte o compartilhamento e abra qualquer arquivo para leitura.
- Carregue um arquivo de teste ou de amostra no compartilhamento.
- Crie um instantâneo de compartilhamento no portal do Azure.
Existem muitos cenários para os quais o failover planejado é ideal. Esses cenários incluem:
- Planejamento e testes de recuperação de desastres (DR).
- Recuperação durante uma interrupção que não afeta os pontos de extremidade do serviço de armazenamento da sua região primária, mas impede que outro serviço da Microsoft ou de terceiros forneça acesso às suas cargas de trabalho.
- Preparar-se proativamente para desastres de grande escala, como um furacão, que possam impactar uma região.
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 se torna 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 poderão acessar os dados na nova região primária e os administradores poderão 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 planejado de failover e failback, desde que as regiões primária e secundária estejam disponíveis durante todo o processo. Para obter mais detalhes, veja a seção Antecipando perda e inconsistências de dados.
Para compreender o efeito desse tipo de failover nos seus utilizadores e aplicações, é útil saber o que acontece durante cada passo dos processos planeados de failover e failback. Para obter detalhes sobre como esse processo funciona, veja Como funciona o failover gerenciado pelo cliente (planejado).
Failover gerenciado pelo cliente (não planejado)
Se os pontos finais de dados para os serviços de armazenamento na sua conta de armazenamento ficarem indisponíveis na região primária, pode iniciar uma falha não planeada para a região secundária. Após a conclusão do failover, a região secundária se torna a nova região primária e os usuários podem prosseguir para acessar os dados lá.
Para compreender o efeito desse tipo de failover nos seus utilizadores e aplicações, é útil saber o que acontece durante cada passo do processo de failover e failback não planeado. Para obter detalhes sobre como o processo funciona, veja 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 afete uma região geográfica inteira. Durante esses eventos, não é necessária ação da sua parte. Se a conta de armazenamento estiver configurada para RA-GRS ou RA-GZRS, seus aplicativos poderão ler da região secundária durante um failover gerenciado pela Microsoft. No entanto, você não terá acesso de gravação à a 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 datacenter. Ele não pode ser iniciado para contas de armazenamento individuais, assinaturas ou locatários. Caso necessite da capacidade de fazer failover seletivo das contas de armazenamento individuais, use o Recuperação planejada gerenciada pelo cliente.
Prever perda de dados e inconsistências
Cuidado
O failover gerenciado pelo cliente (não planejado) geralmente envolve alguma perda de dados e também pode potencialmente introduzir inconsistências em 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, é 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 ocorre o failover. No entanto, todos os dados gravados no primário que ainda não existem na 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:
- Namespace hierárquico (Azure Data Lake Storage Gen2)
- Feed de alterações
- Restauração pontual para blobs de blocos
Hora da última sincronização
A propriedade Hora da última sincronização indica o horário mais recente em que os dados da região primária também foram gravados na região secundária. Para contas que possuem um namespace hierárquico, a mesma propriedade Hora da Última Sincronização 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 do último horário de sincronização estão disponíveis no secundário. Por outro lado, dados e metadados gravados após horário da última sincronização ainda podem não ser copiados para a secundária e podem potencialmente ser perdidos. Durante uma interrupção, use essa propriedade para estimar a quantidade de perda de dados que poderá ocorrer ao iniciar um failover de conta.
Como melhor prática, crie o aplicativo de modo que seja possível usar a Hora da última sincronização para avaliar a estimativa de perda de dados. Por exemplo, registrar todas as operações de gravação permite que comparar a hora da última operação de gravação com a hora da última sincronização. Esse método permite determinar quais gravações ainda não foram sincronizadas com a secundária e correm o risco de serem perdidas.
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. 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 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 (não planejado) gerenciado pelo cliente de contas de armazenamento com feed de alteração habilitado pode resultar em inconsistências entre os logs de feed de alteração e os dados e/ou metadados de blob. Essas inconsistências podem resultar da natureza assíncrona das atualizações de log de alterações e da replicação de dados entre as regiões primária e secundária. Você pode evitar inconsistências tomando as seguintes precauções:
- Certifique-se de que todos os registros de log sejam descarregados nos 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 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 pontual para blobs de blocos.
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.
O tempo e o custo do failover
O tempo que leva para um failover gerenciado pelo cliente ser concluído após ser iniciado pode variar, embora normalmente demore 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 armazenamento localmente redundante (LRS) em uma nova região primária e exclui a conta de armazenamento na região primária original.
Você pode reativar o GRS ou o RA-GRS para a conta, mas replicar novamente os dados para a nova região secundária gera uma cobrança. Além disso, quaisquer blobs arquivados precisam ser reidratados para um nível online antes que a conta possa ser reconfigurada para redundância geográfica. Essa reidratação também gera uma cobrança adicional. 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 necessário para a conclusão da replicação depende de vários fatores. Esses fatores 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.
- O número de instantâneos por blob, se aplicável.
- A estratégia de particionamento de dados, se a sua conta de armazenamento contiver tabelas. 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 (não planejado) | Contas v2 de finalidade geral contas v1 de finalidade gera contas herdadas de Armazenamento de Blobs |
Contas para uso geral v2 |
| Failover planejado gerenciado pelo cliente (versão prévia) | 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 gerenciado pelo cliente só tem suporte para contas de armazenamento implantadas usando o modelo de implantação do Azure Resource Manager (ARM). O modelo de implantação do ASM (Service Manager do Azure), também conhecido como modelo 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.
Durante um desastre que afete a região primária, a Microsoft gerenciará o failover em contas de armazenamento clássicas. Para obter mais informações, consulte failover gerenciado pela Microsoft.
Namespace hierárquico (HNS)
Importante
O failover gerenciado pelo cliente (não planejado) para contas que têm um namespace hierárquico (Azure Data Lake Storage Gen2) ou SFTP (protocolo de transferência de arquivos SSH) está atualmente em PREVIEW e tem suporte apenas 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.
No caso de 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
Os seguintes recursos e serviços não têm suporte para failover gerenciado pelo cliente:
- O Sincronização de Arquivos do Azure não dá suporte ao failover de conta gerenciada pelo cliente. As contas de armazenamento utilizadas como pontos de extremidade na nuvem para o Sincronização de Arquivos do Azure não devem sofrer falha. O failover interrompe a sincronização de arquivos e pode causar perda inesperada de dados de arquivos recém-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.
- 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.
A tabela a seguir pode ser usada para fazer referência ao suporte de recursos.
| Failover planejado | Failover não planejado | |
|---|---|---|
| ADLS Gen2 | Com suporte (versão prévia) | Com suporte (versão prévia) |
| Feed de Alterações | Sem suporte | Com suporte |
| Replicação de objetos | Sem suporte | Sem suporte |
| SFTP | Com suporte (versão prévia) | Com suporte (versão prévia) |
| NFSv3 | GRS não é compatível | GRS não é compatível |
| Leilões de armazenamento | Sem suporte | Sem suporte |
| Restauração pontual (PITR) | Sem suporte | Com suporte |
O failover não serve para migração de conta
Os failovers de conta de armazenamento são uma solução temporária que pode ser usada para ajudar a planejar e testar seus planos de 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 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 deverã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 de armazenamento. Todas as VMs que fizeram failover em uma região secundária em resposta a uma interrupção precisam ser recriadas após a conclusão do failover. O failover da conta pode resultar potencialmente na perda de dados armazenados em um disco temporário quando a máquina virtual (VM) for desligada. A Microsoft recomenda seguir as diretrizes de alta disponibilidade e recuperação de desastre específicas para máquinas virtuais no Azure.
Discos não gerenciados do Azure
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. Antes que um failover possa ser iniciado em uma conta que contém discos não gerenciados anexados a VMs do Azure, os discos devem ser desligados. Por esse motivo, as melhores práticas da Microsoft incluem a conversão de discos não gerenciados em discos gerenciados.
Para executar um failover em uma conta que contém discos não gerenciados, siga estas etapas:
- 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.
- Desligue a VM.
- Exclua a VM, mas mantenha os arquivos do disco rígido virtual (VHD) dos discos não gerenciados. Anote a hora que você excluiu a VM.
- Aguarde até que a Horário da Última Sincronização seja atualizada e verifique se ela é posterior à hora em que você excluiu a VM. Esta etapa garante que o ponto de extremidade secundário seja totalmente atualizado com os arquivos VHD quando o failover ocorrer e que a VM funcione corretamente na nova região primária.
- Inicie o failover da conta.
- Aguarde até que o failover da 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 anexe novamente os VHDs.
- 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 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 você preferir não fazer failover durante uma interrupção na região primária, poderá copiar manualmente seus dados como uma alternativa. Ferramentas como o AzCopy e o Azure PowerShell permitem copiar dados da conta de armazenamento na região afetada para outra conta de armazenamento em uma região não afetada. Depois que a operação de cópia for concluída, você poderá reconfigurar os aplicativos para usar a conta de armazenamento na região não afetada para disponibilidade de leitura e 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:
- Design de 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 analisar se o aplicativo implementa as práticas de design recomendadas para alta disponibilidade.
- Uso da redundância geográfica para criar aplicativos altamente disponíveis: diretrizes de design para criar aplicativos que aproveitem o armazenamento com redundância geográfica.
- Tutorial – Criar um aplicativo altamente disponível com o Armazenamento de blobs: um tutorial que mostra como criar um aplicativo altamente disponível que alterne automaticamente entre os pontos de extremidade quando falhas e recuperações forem simuladas.
Consulte estas melhores práticas para manter alta disponibilidade para os dados do Armazenamento do 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 as VMs em caso de 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 AzCopy para exportar dados de tabela para outra conta de armazenamento numa 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
- Uso da redundância geográfica para criar aplicativos altamente disponíveis
- Tutorial: Criar um aplicativo altamente disponível com o armazenamento de Blobs
- Redundância do Armazenamento do Azure
- Como funciona o failover planejado gerenciado pelo cliente (versão prévia)
- Como funciona o failover gerenciado pelo cliente (não planejado)
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de