Recuperação de desastres e failover para Arquivos 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 e você deve ter um plano de recuperação de desastres (DR) para lidar com uma interrupção de serviço regional. Uma parte importante de um plano de recuperação de desastres é preparar-se para fazer failover para o ponto de extremidade secundário no caso de o ponto de extremidade primário ficar indisponível. Este artigo descreve os conceitos e processos envolvidos com recuperação de desastres (DR) e failover de conta de armazenamento.
Importante
A Sincronização de Ficheiros do Azure apenas suporta o failover da conta de armazenamento se o Serviço de Sincronização de Armazenamento também tiver falhado. Isso ocorre porque a Sincronização de Arquivos do Azure exige que a conta de armazenamento e o Serviço de Sincronização de Armazenamento estejam na mesma região do Azure. Se apenas a conta de armazenamento for submetida a failover, as operações de sincronização e hierarquização na nuvem falharão até que o Serviço de Sincronização de Armazenamento faça failover para a região secundária. Se você quiser fazer failover de uma conta de armazenamento que contém compartilhamentos de arquivos do Azure que estão sendo usados como pontos de extremidade de nuvem no Azure File Sync, consulte Práticas recomendadas de recuperação de desastres do Azure File Sync e Recuperação do servidor do Azure File Sync.
Failover planejado gerenciado pelo cliente (visualização)
O failover planejado gerenciado pelo cliente também 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.
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.
Métricas e custos de recuperação
Para formular uma estratégia de DR eficaz, uma organização deve compreender:
- Quantos dados ele pode perder em caso de interrupção (objetivo de ponto de recuperação ou RPO)
- A rapidez com que ele precisa ser capaz de restaurar funções e dados de negócios (objetivo de tempo de recuperação ou RTO)
O custo da DR geralmente aumenta com RPO/RTO menor ou zero. As empresas que precisam estar prontas e funcionando em poucos segundos após um desastre e não podem sustentar nenhuma perda de dados pagarão mais pela DR, enquanto aquelas com números de RPO/RTO mais altos pagarão menos. O Azure fornece soluções que podem funcionar com vários requisitos de RPO e RTO.
Escolha a opção de redundância certa
Os Arquivos do Azure oferecem diferentes opções de redundância para proteger seus dados contra eventos planejados e não planejados, que vão desde falhas transitórias de hardware, quedas de rede e de energia até desastres naturais. Todos os compartilhamentos de arquivos do Azure podem usar LRS (localmente redundante) ou ZRS (armazenamento com redundância de zona). Para obter mais informações, consulte Redundância de arquivos do Azure.
O Azure Files dá suporte ao failover de conta para contas de armazenamento padrão configuradas com GRS (armazenamento com redundância geográfica) e GZRS (armazenamento redundante de zona geográfica) para proteção contra interrupções regionais. Com a ativação pós-falha da conta, pode iniciar o processo de ativação pós-falha para a sua conta de armazenamento se o ponto final principal ficar indisponível. A ativação pós-falha atualiza o ponto final secundário para se tornar o ponto final principal da conta de armazenamento. Após a conclusão da ativação pós-falha, os clientes podem começar a escrever no novo ponto final principal.
GRS e GZRS ainda apresentam um risco de perda de dados porque os dados são copiados para a região secundária de forma assíncrona, o que significa que há um atraso antes que uma gravação na região primária seja copiada para a região secundária. No caso de uma interrupção, as operações de gravação no ponto de extremidade primário que ainda não foram copiadas para o ponto de extremidade secundário serão perdidas. Isso significa que uma falha que afete a região primária pode resultar em perda de dados se a região primária não puder ser recuperada. O intervalo entre as gravações mais recentes na região primária e a última gravação na região secundária é o RPO. Os Arquivos do Azure normalmente têm um RPO de 15 minutos ou menos, embora atualmente não haja SLA sobre quanto tempo leva para replicar dados para a região secundária.
Importante
GRS/GZRS não são suportados para compartilhamentos de arquivos premium do Azure. No entanto, você pode sincronizar entre dois compartilhamentos de arquivos do Azure para obter redundância geográfica.
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 criar aplicativos para aproveitar o armazenamento com redundância geográfica para compartilhamentos de arquivos SMB.
Também recomendamos que você projete seu aplicativo para se preparar para a possibilidade de falhas de gravação. 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.
Como prática recomendada, projete seu aplicativo para verificar a propriedade Last Sync Time 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.
Acompanhe interrupções
Pode subscrever o Painel de Estado de Funcionamento do Serviço do Azure para controlar o estado de funcionamento e o estado de funcionamento dos Ficheiros do Azure e de outros serviços do Azure.
Compreender o processo de ativação pós-falha da conta
O failover de conta gerenciado pelo cliente permite que você faça failover de toda a sua conta de armazenamento para a região secundária se a principal ficar indisponível por qualquer motivo. Quando você força um failover para a região secundária, os clientes podem começar a gravar dados no ponto de extremidade secundário após a conclusão do failover. O failover normalmente leva cerca de uma hora. Recomendamos suspender sua carga de trabalho o máximo possível antes de iniciar um failover de conta.
Para saber como iniciar um failover de conta, consulte Iniciar um failover de conta.
Como funciona a ativação pós-falha de uma conta
Em circunstâncias normais, um cliente grava dados em uma conta de armazenamento na região primária e esses dados são copiados de forma assíncrona para a região secundária. A imagem a seguir mostra o cenário quando a região primária está disponível:
Se o ponto de extremidade primário ficar indisponível por qualquer motivo, o cliente não poderá mais gravar na conta de armazenamento. A imagem a seguir mostra o cenário em que o primário ficou indisponível, mas nenhuma recuperação aconteceu ainda:
O cliente inicia o failover de conta para o ponto de extremidade secundário. O processo de failover atualiza a entrada DNS fornecida pelo Armazenamento do Azure para que o ponto de extremidade secundário se torne o novo ponto de extremidade primário para sua conta de armazenamento, conforme mostrado na imagem a seguir:
O acesso de gravação é restaurado para contas com redundância geográfica assim que a entrada DNS for atualizada e as solicitações forem direcionadas para o novo ponto de extremidade primário. Os pontos de extremidade de serviço de armazenamento existentes permanecem os mesmos após o failover. Os identificadores e concessões de arquivos não são retidos no failover, portanto, os clientes devem desmontar e remontar os compartilhamentos de arquivos.
Importante
Após a conclusão do failover, a conta de armazenamento é configurada para ser localmente redundante no novo ponto de extremidade/região principal. Para retomar a replicação para o novo secundário, configure a conta para redundância geográfica novamente.
Lembre-se de que converter uma conta de armazenamento com redundância local para usar redundância geográfica incorre em custos e tempo. Para obter mais informações, consulte O tempo e o custo do failover.
Antecipe a perda de dados
Atenção
Um failover de conta geralmente envolve alguma perda de dados. É importante entender as implicações de iniciar um failover de conta.
Como os dados são gravados de forma assíncrona da região primária para a região 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 região secundária.
Quando você força um failover, todos os dados na região primária são perdidos à medida que a região secundária se torna a nova região primária. A nova região primária é configurada para ser localmente redundante após o failover.
Todos os dados já copiados para o secundário são mantidos quando o failover acontece. No entanto, quaisquer dados gravados no primário que também não tenham sido copiados para o secundário serão perdidos permanentemente.
Consulte a propriedade Last Sync Time
A propriedade Last Sync Time (LST) 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. Todos os dados gravados antes da última hora de sincronização estão disponíveis no secundário, enquanto os dados 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 no caso de uma interrupção para estimar a quantidade de perda de dados que você pode incorrer ao iniciar um failover de conta.
Para garantir que os compartilhamentos de arquivos estejam em um estado consistente quando ocorre um failover, um instantâneo do sistema é criado na região primária a cada 15 minutos e replicado para a região secundária. Quando ocorre um failover para a região secundária, o estado de compartilhamento será baseado no instantâneo do sistema mais recente na região secundária. Se ocorrer uma falha na região primária, a região secundária provavelmente estará atrás da região primária, pois todas as gravações na primária ainda não terão sido replicadas para a secundária. Devido ao atraso geográfico ou outros problemas, o instantâneo do sistema mais recente na região secundária pode ter mais de 15 minutos.
Todas as operações de gravação gravadas na região primária antes do LST foram replicadas com êxito para a região secundária, o que significa que elas estão disponíveis para serem lidas a partir da secundária. Quaisquer operações de gravação gravadas na região primária após o último tempo de sincronização podem ou não ter sido replicadas para a região secundária, o que significa que elas podem não estar disponíveis para operações de leitura.
Você pode consultar o valor da propriedade Last Sync Time usando o Azure PowerShell, a CLI do Azure ou a biblioteca do cliente. A propriedade Last Sync Time é um valor de data/hora GMT. Para obter mais informações, consulte Verifique a propriedade Last Sync Time de uma conta de armazenamento.
Tenha cuidado ao falhar de volta ao primário original
Como mencionado anteriormente, após o failover da região primária para a secundária, sua conta de armazenamento é configurada para ser localmente redundante na nova região primária. Em seguida, você pode configurar a conta na nova região primária para redundância geográfica. Quando a conta é configurada para redundância geográfica após um failover, a nova região primária começa imediatamente a copiar dados para a nova região secundária, que era a principal antes do failover original. No entanto, pode levar algum tempo até que os dados existentes no novo primário sejam totalmente copiados para o novo secundário.
Depois que a conta de armazenamento é reconfigurada para redundância geográfica, é possível iniciar um failback do novo primário para o novo secundário. Nesse caso, a região primária original antes do failover torna-se a região primária novamente e é configurada para ser localmente redundante ou de zona, dependendo se a configuração primária original era GRS ou GZRS. Todos os dados na região primária pós-failover (a secundária original) são perdidos durante o failback. Se a maioria dos dados na conta de armazenamento não tiver sido copiada para o novo secundário antes de fazer failback, você poderá sofrer uma grande perda de dados.
Para evitar uma grande perda de dados, verifique o valor da propriedade Last Sync Time antes de fazer failback. Compare o último tempo de sincronização com as últimas vezes em que os dados foram gravados no novo primário para avaliar a perda de dados esperada.
Após uma operação de failback, você pode configurar a nova região primária para ser redundante geograficamente novamente. Se o primário original foi configurado para LRS, você pode configurá-lo para ser GRS. Se o primário original foi configurado para ZRS, você pode configurá-lo para ser GZRS. Para obter opções adicionais, consulte Alterar a forma como uma conta de armazenamento é replicada.
Iniciar a ativação pós-falha de uma conta
Você pode iniciar um failover de conta a partir do portal do Azure, PowerShell, CLI do Azure ou da API do provedor de recursos de Armazenamento do Azure. Para obter mais informações sobre como iniciar um failover, consulte Iniciar um failover de conta.
Failover gerenciado pela Microsoft
Em circunstâncias extremas em que uma região é perdida devido a um desastre significativo, a Microsoft pode iniciar um failover regional. Neste caso, nenhuma ação é necessária da sua parte. Até que o failover gerenciado pela Microsoft seja concluído, você não terá acesso de gravação à sua conta de armazenamento.