Recuperação de desastres e failover para Arquivos do Azure
A Microsoft se empenha em garantir que os serviços do Azure estejam sempre disponíveis. No entanto, podem ocorrer interrupções de serviço não planejadas, portanto, 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 desastre é a preparação de um failover para o ponto de extremidade secundário caso o ponto de extremidade primário fique indisponível. Este artigo descreve os conceitos e os processos envolvidos na recuperação de desastres (DR) e no failover da conta de armazenamento.
Importante
A Sincronização de Arquivos do Azure só dá suporte ao failover da conta de armazenamento se tiver sido realizado failover também do Serviço de Sincronização de Armazenamento. 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 foi feito o failover apenas na conta de armazenamento, as operações de sincronização e camada de nuvem falharão até que se faça o failover do Serviço de Sincronização de Armazenamento para a região secundária. Se você quiser fazer failover de uma conta de armazenamento contendo compartilhamentos de arquivos do Azure que estão sendo usados como pontos de extremidade na nuvem na Sincronização de Arquivos do Azure, consulte as Melhores práticas de recuperação de desastre da Sincronização de Arquivos do Azure e a Recuperação do servidor de Sincronização de Arquivos do Azure.
Failover planejado gerenciado pelo cliente (versão prévia)
A recuperação panejada gerenciada pelo cliente também pode ser utilizada em vários cenários, incluindo testes de recuperação de desastre planejados, uma abordagem proativa para desastres em grande escala ou para se recuperar 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 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).
Importante
A recuperação planejada gerenciada pelo cliente está atualmente em PREVIEW e limitado às seguintes regiões:
- França Central
- Sul da França
- Centro da Índia
- Oeste da Índia
- Leste da Ásia
- Sudeste Asiático
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 uma recuperação planejada, 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 a recuperação planejada gerenciada 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 da recuperação planejada, fazendo com que o valor do LST geral da conta pareça desatualizado 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 a recuperação planejada 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 de LST até que a criação do instantâneo do sistema seja acionada.
Se necessário, execute uma das seguintes atividades para cada compartilhamento em uma conta de armazenamento para disparar a criação de instantâneo. Após a conclusão, sua conta deverá 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 de exemplo no compartilhamento.
Métrica e custos de recuperação
Para formular uma estratégia de DR eficaz, uma organização precisa entender:
- A quantidade de dados que ele pode perder em caso de interrupção (objetivo de ponto de recuperação ou RPO)
- Com que rapidez ele precisa ser capaz de restaurar as funções e os dados de negócios (objetivo de tempo de recuperação ou RTO)
O custo da DR geralmente aumenta com RPO/RTO menor ou nulo. As empresas que precisam estar em funcionamento em poucos segundos após um desastre e que não podem sofrer nenhuma perda de dados pagarão mais pela DR, enquanto aquelas com números mais altos de RPO/RTO pagarão menos. O Azure fornece soluções que podem trabalhar com vários requisitos de RPO e RTO.
Escolhendo a opção de redundância correta
O Arquivos do Azure oferece diferentes opções de redundância para proteger seus dados contra eventos planejados e não planejados, desde falhas de hardware transitórias, interrupções de rede e de energia até desastres naturais. Todos os compartilhamentos de arquivos do Azure podem usar o armazenamento com redundância local (LRS) ou com redundância de zona (ZRS). Para obter mais informações, confira Redundância do Arquivos do Azure.
O Arquivos do Azure tem suporte para failover de conta para contas de armazenamento padrão configuradas com armazenamento com redundância geográfica (GRS) e armazenamento com redundância de zona geográfica (GZRS) para proteção contra interrupções regionais. Com o failover de conta, é possível iniciar o processo de failover da conta de armazenamento, se o ponto de extremidade primário ficar indisponível. O failover atualiza o ponto de extremidade secundário para torná-lo um ponto de extremidade primário de sua conta de armazenamento. Quando o failover estiver concluído, os clientes poderão começar a gravar no novo ponto de extremidade primário.
O GRS e o 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
Não há suporte para o GRS/GZRS em compartilhamentos de arquivos premium do Azure. No entanto, você pode fazer a sincronização entre dois compartilhamentos de arquivos do Azure para obter redundância geográfica.
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 as diretrizes sobre como projetar seu aplicativo e planejar a recuperação de desastres:
- 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 em compartilhamentos de arquivos SMB.
Também recomendamos que você projete seu aplicativo para 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.
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 hora da última sincronização para determinar quais gravações não foram sincronizadas com o secundário.
Acompanhar interrupções
Você pode assinar o Painel de Integridade do Serviço do Azure para acompanhar a integridade e o status do Arquivos do Azure e de outros serviços do Azure.
Entendendo o processo de failover de conta
O failover de conta gerenciada pelo cliente permite fazer failover de toda a conta de armazenamento para a região secundária quando a primária fica indisponível por algum motivo. Quando você força um failover para a região secundária, os clientes podem começar a gravar os dados no ponto de extremidade secundário depois que o failover estiver concluído. O failover normalmente leva cerca de uma hora. Recomendamos suspender sua carga de trabalho o máximo possível antes de iniciar um failover da conta.
Para saber como iniciar um failover de conta, confira Iniciar um failover de conta.
Como um failover de conta funciona
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 algum motivo, o cliente não poderá mais gravar os dados na conta de armazenamento. A imagem a seguir mostra o cenário em que o ponto de extremidade primário ficou indisponível, mas nenhuma recuperação aconteceu ainda:
O cliente inicia o failover da conta no 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 de sua conta de armazenamento, conforme mostrado na imagem a seguir:
O acesso de gravação é restaurado para contas com redundância geográfica depois que a entrada DNS é atualizada e as solicitações são direcionadas para o novo ponto de extremidade primário. Os pontos de extremidade do serviço de armazenamento existentes permanecem os mesmos após o failover. As concessões e identificadores de arquivos não são retidos no failover e os clientes precisam desmontar e remontar os compartilhamentos de arquivos.
Importante
Depois que o failover estiver concluído, a conta de armazenamento é configurada para ser localmente redundante no novo ponto de extremidade/região primário(a). Para continuar a replicação no novo ponto de extremidade secundário, configure a conta para usar redundância geográfica novamente.
Tenha em mente que converter uma conta de armazenamento com redundância local para usar a redundância geográfica incorre em custo e tempo. Para obter mais informações, consulte O tempo e o custo do failover.
Prevendo a perda de dados
Cuidado
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, pois a região secundária se torna a nova região primária. A nova região primária é configurada para ser redundante localmente após o failover.
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 não tenham sido copiados para o secundário serão perdidos permanentemente.
Verificar a propriedade Horário da Última Sincronização
A propriedade Última hora de sincronização (LST) indica a hora mais recente em que os dados da região primária são garantidos como tendo sido gravados na região secundária. Todos os dados gravados antes do último horário de sincronização estão disponíveis no secundário, enquanto os dados gravados após o último horário 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 em 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 um failover ocorre na 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 ficará atrás da região primária, pois todas as gravações na região primária ainda não terão sido replicadas para a secundária. Devido ao atraso geográfico ou a outros problemas, o último instantâneo do sistema 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 na secundária. Todas as operações de gravação gravadas na região primária após o último período 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 Horário da Última Sincronização usando o Azure PowerShell, a CLI do Azure ou a biblioteca do cliente. A propriedade Horário da Última Sincronização é um valor de data/hora em GMT. Para saber mais, confira Verificar a propriedade Horário da Última Sincronização de uma conta de armazenamento.
Tendo cuidados ao realizar o fail back para a região primária original
Conforme mencionado anteriormente, após o failover da região primária para a secundária, sua conta de armazenamento é configurada para ser com redundância local 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 é novamente configurada para redundância geográfica após um failover, a nova região primária imediatamente começa a copiar os dados para a nova região secundária, que era a primária antes do failover original. No entanto, pode levar algum tempo para que os dados existentes na região primária sejam totalmente copiados para a nova região secundária.
Depois que a conta de armazenamento for reconfigurada para a redundância geográfica, será possível iniciar outro failback da nova região primária para a nova região secundária. Nesse caso, a região primária original antes do failover se torna a região primária novamente e é configurada para ser com redundância local ou com redundância de zona, dependendo do fato de a configuração primária original ser GRS ou GZRS. Todos os dados na região primária após o failover (a região secundária original) serão perdidos. Se a maioria dos dados na conta de armazenamento não tiver sido copiada para a nova secundária antes do failback, você poderá sofrer uma grande perda de dados.
Para evitar uma grande perda de dados, verifique o valor da propriedade Hora da última sincronização antes de realizar o fail back. Compare a hora da última sincronização com os momentos das últimas vezes que os dados foram gravados na nova região primária a fim de avaliar a perda de dados esperada.
Após uma operação de failback, você pode configurar a nova região primária para ser com redundância geográfica 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 como uma conta de armazenamento é replicada.
Iniciar um failover da conta
É possível iniciar um failover de conta do portal do Azure, no PowerShell, na CLI do Azure ou na API de provedor de recursos do Armazenamento do Azure. Para obter mais informações sobre como iniciar um failover, confira Iniciar um failover de conta.
Failover gerenciado pela Microsoft
Em circunstâncias extremas, quando uma região é perdida devido a um desastre significativo, a Microsoft pode iniciar um failover regional. Nesse caso, nenhuma ação de sua parte é necessária. Você não terá acesso para gravação na conta de armazenamento até que o failover gerenciado pela Microsoft seja concluído.