Recuperar-se de uma interrupção do serviço em toda a região

Artigo
03/21/2023

O Azure é dividido fisicamente e logicamente em unidades chamadas de regiões. Uma região é composta por um ou mais datacenters próximos uns dos outros. Muitas regiões e serviços também dão suporte a zonas de disponibilidade, que podem ser usadas para fornecer mais resiliência contra interrupções em um só datacenter. Considere usar regiões com zonas de disponibilidade para aprimorar a disponibilidade de sua solução.

Em raras circunstâncias, é possível que instalações em toda uma zona de disponibilidade ou região fiquem inacessíveis, por exemplo, devido a falhas de rede. Ou instalações podem ser inteiramente perdidas, por exemplo, devido a um desastre natural. O Azure tem recursos para criar aplicativos que são distribuídos entre zonas e regiões. Essa distribuição ajuda a minimizar a possibilidade de que uma falha em uma zona ou região afete outras zonas ou regiões.

Serviços de nuvem

Gerenciamento de recursos

Você pode distribuir as instâncias de computação entre regiões criando um serviço de nuvem separado em cada região de destino e publicando o pacote de implantação em cada serviço de nuvem. No entanto, a distribuição de tráfego pelos serviços de nuvem em diferentes regiões deve ser implementada pelo desenvolvedor do aplicativo ou com um serviço de gerenciamento de tráfego.

Determinar o número de instâncias de função de reposição a implantar com antecedência para recuperação de desastre é um aspecto importante do planejamento de capacidade. Ter uma implantação secundária completa garante que a capacidade esteja disponível quando necessário; no entanto, isso dobra efetivamente o custo. Um padrão comum é ter uma implantação secundária pequena, mas grande o suficiente para executar serviços críticos. Essa implantação secundária pequena é uma boa ideia, para reservar capacidade e para testar a configuração do ambiente secundário.

Observação

A cota da assinatura não é uma garantia de capacidade. A cota é simplesmente um limite de crédito. Para garantir a capacidade, o número necessário de funções deve ser definido no modelo de serviço, e as funções devem ser implantadas.

Balanceamento de carga

Balancear a carga de tráfego entre regiões requer uma solução de gerenciamento de tráfego. O Azure oferece o Gerenciador de Tráfego do Azure. Você também pode tirar proveito dos serviços de terceiros que fornecem recursos de gerenciamento de tráfego semelhantes.

Estratégias

Muitas estratégias alternativas estão disponíveis para implementação de computação distribuída entre regiões. Essas estratégias devem ser personalizadas segundo os requisitos específicos de negócios e as circunstâncias do aplicativo. Em um nível elevado, as abordagens podem ser divididas nas seguintes categorias:

Reimplantar em caso de desastre: nessa abordagem, o aplicativo é reimplantado do zero no momento do desastre. Isso é adequado para aplicativos não críticos, que não exigem um tempo de recuperação garantido.
Reposição morna (ativo/passivo): um serviço hospedado secundário é criado em uma região alternativa e funções são implantadas para garantir a capacidade mínima. No entanto, as funções não recebem tráfego de produção. Essa abordagem é útil para aplicativos que não foram projetados para distribuir tráfego entre regiões.
Reposição quente (ativo/ativo): o aplicativo foi projetado para receber a carga de produção em várias regiões. Os serviços de nuvem em cada região podem ser configurados para capacidade maior do que o necessário para fins de recuperação de desastre. Como alternativa, os serviços de nuvem podem escalar horizontalmente conforme o necessário no momento de um desastre e failover. Essa abordagem exige um investimento substancial no design do aplicativo, mas tem benefícios significativos. Isso inclui tempo de recuperação baixo e garantido, testes contínuos de todos os locais de recuperação e uso eficiente da capacidade.

Uma discussão completa sobre design distribuído está fora do escopo deste documento. Para obter mais informações, consulte Recuperação de Desastre e Alta Disponibilidade para Aplicativos do Azure.

Máquinas virtuais

A recuperação de VMs (máquinas virtuais) de IaaS (infraestrutura como um serviço) é semelhante à recuperação de computação de PaaS (plataforma como serviço) em muitos aspectos. No entanto, há diferenças importantes, pois uma VM IaaS consiste na VM e no disco de VM.

Use o Backup do Azure para criar backups entre regiões consistentes com aplicativos. Backup do Azure habilita os clientes a criar backups consistentes com aplicativos em vários discos de VM e dar suporte à replicação de backups entre regiões. Você pode fazer isso optando por replicar geograficamente o cofre de backup no momento da criação. A replicação do cofre de backup deve ser configurada no momento da criação. Ele não pode ser definido mais tarde. Se uma região for perdida, a Microsoft disponibilizará os backups para os clientes. Os clientes poderão restaurar para qualquer um dos seus pontos de restauração configurados.
Separar os discos de dados do disco do sistema operacional. Uma consideração importante para VMs IaaS é que você não pode alterar o disco do sistema operacional sem recriar a VM. Isso não será um problema se sua estratégia de recuperação for a de reimplantar após desastre. No entanto, poderá ser um problema se você estiver usando a abordagem de reposição morna para capacidade reserva. Para implementar isso adequadamente, você deve ter o disco de sistema operacional correto implantado nos locais primário e secundário, e os dados de aplicativos devem ser armazenados em uma unidade separada. Se possível, use uma configuração de sistema operacional padrão, que possa ser fornecida em ambos os locais. Após um failover, você deve anexar a unidade de dados às VMs IaaS existentes no controlador de domínio secundário. Use o AzCopy para copiar instantâneos dos discos de dados para um site remoto.
Estar ciente dos possíveis problemas de consistência após um failover geográfico de vários Discos de VM. Os Discos de VM são implementados como blobs de Armazenamento do Azure e têm a mesma característica de replicação geográfica. A menos que o Backup do Azure seja usado, não há garantia de consistência entre discos, pois a replicação geográfica é assíncrona e é replicada de maneira independente. Discos de VM individuais têm a garantia de estar em um estado com controle de falhas após um failover geográfico, mas não consistente entre discos. Isso pode causar problemas em alguns casos (por exemplo, no caso de divisão entre discos).
Use o Azure Site Recovery para replicar aplicativos entre regiões. Com o Azure Site Recovery, os clientes não precisam se preocupar em separar discos de dados de discos do sistema operacional ou com possíveis problemas de consistência. O Azure Site Recovery replica cargas de trabalho em execução em máquinas físicas e virtuais de um site primário (local ou no Azure) para um local secundário (no Azure). Quando ocorre uma interrupção no site principal do cliente, um failover pode ser acionado para retornar rapidamente o cliente a um estado operacional. Depois que o local principal for restaurado, os clientes poderão fazer failback. Eles podem replicar facilmente usando pontos de recuperação com instantâneos consistentes com aplicativos. Esses instantâneos capturam dados de disco, todos os dados na memória e todas as transações em processo. O Azure Site Recovery permite que os clientes mantenham os objetivos de tempo de recuperação (RTO) e os objetivos de ponto de recuperação (RPO) dentro dos limites organizacionais. Os clientes também podem executar facilmente exercícios de recuperação de desastres sem afetar os aplicativos em produção. Usando planos de recuperação, os clientes podem sequenciar o failover e a recuperação de aplicativos de várias camadas executados em diversas VMs. Eles podem agrupar computadores em um plano de recuperação e opcionalmente adicionar scripts e ações manuais. Planos de recuperação podem ser integrados aos runbooks de automação do Azure.

Armazenamento

Recuperação usando armazenamento com redundância geográfica de blob, tabela, fila e armazenamento em disco de VM

Em blobs do Azure, tabelas, filas e discos de VM são todos replicados geograficamente por padrão. Isso é conhecido como GRS (armazenamento com redundância geográfica). O GRS replica dados de armazenamento para um datacenter localizado a centenas de milhas de distância dentro de uma região geográfica específica. O GRS é destinado a fornecer durabilidade adicional caso ocorra um desastre de grandes proporções no datacenter. A Microsoft controla quando ocorre o failover, que se limita a grandes desastres em que o local principal de origem é considerado irrecuperável em um período de tempo razoável. Em alguns cenários, isso pode consistir em vários dias. Os dados normalmente são replicados em poucos minutos, embora o intervalo de sincronização ainda não seja coberto por um contrato de nível de serviço.

Se ocorrer um failover geográfico, não haverá alteração na forma como a conta é acessada (a URL e a chave da conta não serão alteradas). No entanto, a conta de armazenamento estará em uma região diferente após o failover. Isso pode afetar aplicativos que exigem afinidade regional com sua conta de armazenamento. Mesmo para serviços e aplicativos que não exigem uma conta de armazenamento no mesmo datacenter, os encargos de largura de banda e a latência entre datacenters podem ser motivos convincentes para mover temporariamente o tráfego para a região de failover. Isso pode influenciar uma estratégia geral de recuperação de desastre.

Além do failover automático fornecido pelo GRS, o Azure introduziu um serviço que fornece a você acesso de leitura à cópia dos dados no local de armazenamento secundário. Isso é chamado de RA-GRS (armazenamento com redundância geográfica com acesso de leitura).

Para saber mais sobre as opções de armazenamento GRS e RA-GRS, confira Replicação do Armazenamento do Azure.

Mapeamentos de região de replicação geográfica

É importante saber onde os dados são replicados geograficamente para saber onde implantar as outras instâncias de dados que exigem afinidade regional com o armazenamento. Para obter mais informações, consulte Regiões emparelhadas do Azure.

Preços da replicação geográfica

A replicação geográfica está incluída no preço atual do Armazenamento do Azure. Isso se chama GRS (armazenamento com redundância geográfica). Se não quiser que os dados sejam replicados geograficamente, você poderá desabilitar a replicação geográfica para sua conta. Isso é chamado de LRS (armazenamento com redundância local) e é cobrado com um preço com desconto em comparação com o GRS.

Determinando se um failover geográfico ocorreu

Se ocorrer um failover geográfico, isso será postado no Painel de Integridade de Serviço do Azure. No entanto, os aplicativos podem implementar um meio automatizado de detectar isso monitorando a região geográfica da conta de armazenamento. Isso pode ser usado para disparar outras operações de recuperação, como a ativação de recursos de computação na região geográfica para a qual o armazenamento foi movido. Você pode executar uma consulta para isso da API de gerenciamento de serviços, usando Obter Propriedades de Conta de Armazenamento. As propriedades relevantes são:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime>
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion>
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

Backup de banco de dados

Banco de Dados SQL

O Banco de Dados SQL do Azure fornece dois tipos de recuperação: restauração geográfica e replicação geográfica ativa.

Restauração geográfica

A restauração geográfica também está disponível para bancos de dados Basic, Standard e Premium. Ele fornece a opção de recuperação padrão quando o banco de dados está indisponível devido a um incidente na região em que o banco de dados está hospedado. De forma semelhante à restauração pontual, a restauração geográfica conta com backups de banco de dados no Armazenamento do Azure com redundância geográfica. Ele restaura da cópia de backup replicado geograficamente e, assim, é resistente a falhas de armazenamento na região primária. Para saber mais, veja Restaurar um Banco de Dados SQL do Azure ou fazer failover para um secundário.

Replicação geográfica ativa

A Replicação geográfica ativa está disponível para todas as camadas de banco de dados. Ela foi criada para aplicativos que têm requisitos de recuperação mais agressivos do que a restauração geográfica pode oferecer. Com a replicação geográfica ativa, você pode criar até quatro secundários legíveis nos servidores em regiões diferentes. Você pode iniciar o failover para qualquer um dos secundários. Além disso, a replicação geográfica ativa pode ser usada para dar suporte à atualização do aplicativo ou aos cenários de realocação, bem como o balanceamento de carga para cargas de trabalho somente leitura. Para detalhes, veja Configurar a replicação geográfica ativa para o Banco de Dados SQL do Azure e inicializar o failover. Confira Projetar serviços globalmente disponíveis usando o Banco de Dados SQL do Azure e Gerenciando as atualizações sem interrupção de aplicativos na nuvem usando a replicação geográfica ativa do Banco de Dados SQL para obter detalhes sobre como criar e implementar aplicativos e a atualização de aplicativos sem tempo de inatividade.

SQL Server em Máquinas Virtuais do Azure

Várias opções estão disponíveis para recuperação e alta disponibilidade para o SQL Server 2012 (e posterior) em execução em Máquinas Virtuais do Azure. Para saber mais, confira Alta disponibilidade e recuperação de desastres para o SQL Server em Máquinas Virtuais do Azure.

Outros serviços da plataforma Azure

Ao tentar executar seu serviço de nuvem em várias regiões do Azure, você deve considerar as implicações para cada uma de suas dependências. Nas seções a seguir, as diretrizes específicas do serviço pressupõem que você deve usar o mesmo serviço do Azure em um datacenter alternativo do Azure. Isso envolve tanto tarefas de configuração quanto de replicação de dados.

Observação

Em alguns casos, essas etapas podem ajudar a atenuar uma interrupção de serviço específico no lugar de um evento no datacenter inteiro. Da perspectiva do aplicativo, uma interrupção de serviço específico pode ser igualmente limitadora e exigiria a migração temporária do serviço para uma região alternativa do Azure.

Barramento de Serviço

O Barramento de Serviço do Azure usa um namespace exclusivo que não abrange regiões do Azure. Portanto, o primeiro requisito é configurar os namespaces do barramento de serviço necessários na região alternativa. No entanto, também há considerações sobre a durabilidade das mensagens na fila. Há várias estratégias para replicar mensagens entre regiões do Azure. Para obter detalhes sobre essas estratégias de replicação e outras estratégias de recuperação de desastre, confira Práticas recomendadas para isolar aplicativos contra interrupções e desastres do Barramento de Serviço.

Serviço de Aplicativo

Para migrar um aplicativo do Serviço de Aplicativo do Azure, como Aplicativos Web ou Aplicativos Móveis, para uma região do Azure secundária, você deve ter um backup do site disponível para publicação. Se a interrupção não envolver todo o datacenter do Azure, talvez seja possível usar o FTP para baixar um backup recente do conteúdo do site. Em seguida, crie um novo aplicativo na região alternativa, a menos que você tenha feito isso anteriormente para a capacidade reserva. Publique o site na nova região e faça quaisquer alterações de configuração necessárias. Essas alterações podem incluir cadeias de conexão de banco de dados ou outras configurações específicas de região. Se necessário, adicione o certificado SSL do site e altere o registro DNS CNAME para que o nome de domínio personalizado aponte para a URL do aplicativo Web do Azure reimplantado.

HDInsight

Os dados associados ao HDInsight são armazenados por padrão no armazenamento de Blobs do Azure. O HDInsight requer que um cluster Hadoop processando trabalhos de MapReduce esteja colocalizado na mesma região da conta de armazenamento que contém os dados sendo analisados. Desde que você use o recurso de replicação geográfica disponível para o Armazenamento do Azure, você poderá acessar os dados na região secundária onde os dados foram replicados se, por algum motivo, a região primária não estiver mais disponível. Você pode criar um novo cluster Hadoop na região em que os dados foram replicados e continuar processando-os.

Relatórios SQL

Neste momento, a recuperação da perda de uma região do Azure exige várias instâncias de Relatórios SQL em diferentes regiões do Azure. Essas instâncias de Relatórios SQL devem acessar os mesmos dados, e esses dados devem ter seu próprio plano de recuperação em caso de desastre. Você também pode manter cópias de backup externas do arquivo RDL para cada relatório.

Serviços de Mídia

Os Serviços de Mídia do Azure têm abordagens de recuperação diferentes para codificação e streaming. Normalmente, a transmissão é mais crítica durante uma interrupção regional. Para se preparar para isso, você deve ter uma conta de Serviços de Mídia em duas regiões do Azure diferentes. O conteúdo codificado deve estar localizado em ambas as regiões. Durante uma falha, você pode redirecionar o tráfego de streaming para a região alternativa. A codificação pode ser executada em qualquer região do Azure. Se a codificação for sensível ao tempo, por exemplo, durante o processamento de eventos ao vivo, você deverá estar preparado para enviar trabalhos para um datacenter alternativo durante eventuais falhas.

Rede virtual

Os arquivos de configuração fornecem a maneira mais rápida de configurar uma rede virtual em uma região alternativa do Azure. Após configurar a rede virtual na região primária do Azure, exporte as configurações de rede virtual da rede atual para um arquivo de configuração de rede. Se ocorrer uma interrupção na região primária, restaure a rede virtual usando o arquivo de configuração armazenado. Em seguida, configure outros serviços de nuvem, máquinas virtuais ou configurações entre locais para trabalhar com a nova rede virtual.
Existem recursos relacionados à VNET que precisamos levar em conta (Ex. NSG, DNS, Tabelas de Rotas). O método descrito em Infraestrutura como um código é uma maneira de gerar o mesmo ambiente sempre e você pode implantar em uma nova região.

Listas de verificação para recuperação de desastre

Lista de verificação de Serviços de Nuvem

Examinar a seção Serviços de Nuvem deste documento.
Criar uma estratégia de recuperação de desastre entre regiões.
Compreender as compensações em reservar capacidade em regiões alternativas.
Usar ferramentas de roteamento de tráfego, como o Gerenciador de Tráfego do Azure.

Lista de verificação de Máquinas Virtuais

Examinar a seção Máquinas Virtuais deste documento.
Usar Backup do Azure para criar backups consistentes com aplicativos em regiões.

Lista de verificação de armazenamento

Examinar a seção Armazenamento deste documento.
Não desabilitar a replicação geográfica dos recursos de armazenamento.
Compreenda a região alternativa para a replicação geográfica se ocorrer um failover.
Criar estratégias de backup personalizadas para estratégias de failover controlado pelo usuário.

Lista de verificação de Banco de Dados SQL

Examinar a seção Banco de Dados SQL deste documento.
Use a restauração geográfica ou a replicação geográfica conforme apropriado.

Lista de verificação do SQL Server em Máquinas Virtuais

Examinar a seção SQL Server em máquinas virtuais deste documento.
Usar Grupos de Disponibilidade AlwaysOn entre regiões ou o espelhamento de banco de dados.
Como alternativa, usar o backup e restauração para o armazenamento de blobs.

Lista de verificação do Barramento de Serviço

Examinar a seção Barramento de Serviço deste documento.
Configurar um namespace do Barramento de Serviço em uma região alternativa.
Considerar estratégias de replicação personalizadas para mensagens entre regiões.

Lista de verificação do Serviço de Aplicativo

Examinar a seção de Serviço de Aplicativo deste documento.
Manter os backups de sites fora da região primária.
Se a interrupção for parcial, tentar recuperar o site atual com FTP.
Planejar implantar o site em um site novo ou existente em uma região alternativa.
Planejar alterações de configuração tanto de aplicativo quanto dos registros DNS CNAME.

Lista de verificação do HDInsight

Examinar a seção HDInsight deste documento.
Criar um novo cluster Hadoop na região com dados replicados.

Lista de verificação de Relatórios SQL

Examinar a seção Relatórios SQL deste documento.
Manter uma instância de Relatórios SQL alternativa em uma região diferente.
Manter um plano separado para replicar o destino para essa região.

Lista de verificação de Serviços de Mídia

Examinar a seção Serviços de Mídia deste documento.
Criar uma conta de Serviços de Mídia em uma região alternativa.
Codificar o mesmo conteúdo em ambas as regiões para dar suporte a failover de streaming.
Envie trabalhos de codificação para uma região alternativa no caso de uma interrupção do serviço.

Lista de verificação de Rede Virtual

Examinar a seção Rede Virtual deste documento.
Usar as configurações da rede virtual exportadas para recriá-la em outra região.