Recupere de uma interrupção de serviço ao nível da região

Artigo
03/21/2023

O Azure é dividido física e logicamente em unidades chamadas regiões. Uma região é constituída por um ou mais datacenters próximos. Muitas regiões e serviços também suportam zonas de disponibilidade, que podem ser utilizadas para proporcionar mais resiliência contra falhas num único datacenter. Considere utilizar regiões com zonas de disponibilidade para melhorar a disponibilidade da sua solução.

Em circunstâncias raras, é possível que as instalações em toda uma zona ou região de disponibilidade possam ficar inacessíveis, por exemplo, devido a falhas de rede. Em alternativa, as instalações podem ser totalmente perdidas, por exemplo, devido a um desastre natural. O Azure tem capacidades para criar aplicações distribuídas entre zonas e regiões. Essa distribuição ajuda a minimizar a possibilidade de uma falha numa zona ou região poder afetar outras zonas ou regiões.

Serviços em nuvem

Gestão de recursos

Pode distribuir instâncias de computação entre regiões ao criar um serviço cloud separado em cada região de destino e, em seguida, publicar o pacote de implementação em cada serviço cloud. No entanto, a distribuição do tráfego pelos serviços cloud em diferentes regiões tem de ser implementada pelo programador da aplicação ou por um serviço de gestão de tráfego.

Determinar o número de instâncias de função sobressalente a implementar antecipadamente para a recuperação após desastre é um aspeto importante do planeamento da capacidade. Ter uma implementação secundária em larga escala garante que a capacidade já está disponível quando necessário; no entanto, isto efetivamente duplica o custo. Um padrão comum é ter uma implementação pequena e secundária, suficientemente grande para executar serviços críticos. Esta pequena implementação secundária é uma boa ideia, tanto para reservar capacidade, como para testar a configuração do ambiente secundário.

Nota

A quota de subscrição não é uma garantia de capacidade. A quota é simplesmente um limite de crédito. Para garantir a capacidade, o número necessário de funções tem de ser definido no modelo de serviço e as funções têm de ser implementadas.

Balanceamento de Carga

Para fazer o balanceamento de carga do tráfego entre regiões, é necessária uma solução de gestão de tráfego. O Azure fornece o Gestor de Tráfego do Azure. Também pode tirar partido de serviços de terceiros que fornecem capacidades de gestão de tráfego semelhantes.

Estratégias

Estão disponíveis muitas estratégias alternativas para implementar computação distribuída entre regiões. Estes têm de ser adaptados aos requisitos e circunstâncias empresariais específicos da aplicação. A um nível elevado, as abordagens podem ser divididas nas seguintes categorias:

Reimplementar em desastre: nesta abordagem, a aplicação é reimplementada do zero no momento do desastre. Isto é adequado para aplicações não críticas que não necessitam de um tempo de recuperação garantido.
Sobressalente Quente (Ativo/Passivo): é criado um serviço alojado secundário numa região alternativa e as funções são implementadas para garantir uma capacidade mínima; no entanto, as funções não recebem tráfego de produção. Esta abordagem é útil para aplicações que não foram concebidas para distribuir o tráfego por regiões.
Sobressalente (Ativo/Ativo): a aplicação foi concebida para receber carga de produção em várias regiões. Os serviços cloud em cada região podem ser configurados para uma capacidade superior à necessária para fins de recuperação após desastre. Em alternativa, os serviços cloud podem aumentar horizontalmente conforme necessário no momento de um desastre e ativação pós-falha. Esta abordagem requer um investimento substancial na conceção de aplicações, mas tem benefícios significativos. Estes incluem tempo de recuperação baixo e garantido, testes contínuos de todas as localizações de recuperação e utilização eficiente da capacidade.

Uma discussão completa sobre a estrutura distribuída está fora do âmbito deste documento. Para obter mais informações, veja Recuperação Após Desastre e Elevada Disponibilidade para Aplicações do Azure.

Máquinas virtuais

A recuperação de máquinas virtuais (VMs) de infraestrutura como serviço (IaaS) é semelhante à recuperação de computação de plataforma como serviço (PaaS) em muitos aspectos. No entanto, existem diferenças importantes devido ao facto de uma VM IaaS ser constituída pela VM e pelo disco da VM.

Utilize Azure Backup para criar cópias de segurança entre regiões que sejam consistentes com a aplicação. Azure Backup permite que os clientes criem cópias de segurança consistentes com aplicações em vários discos de VM e suportem a replicação de cópias de segurança entre regiões. Pode fazê-lo ao optar por replicar georreplicar o cofre de cópias de segurança no momento da criação. A replicação do cofre de cópias de segurança tem de ser configurada no momento da criação. Não pode ser definido mais tarde. Se uma região for perdida, a Microsoft disponibilizará as cópias de segurança aos clientes. Os clientes poderão restaurar para qualquer um dos pontos de restauro configurados.
Separe o disco de dados do disco do sistema operativo. Uma consideração importante para as VMs IaaS é que não pode alterar o disco do sistema operativo sem recriar a VM. Isto não é um problema se a sua estratégia de recuperação for reimplementar após desastre. No entanto, poderá ser um problema se estiver a utilizar a abordagem Warm Spare para reservar a capacidade. Para implementar isto corretamente, tem de ter o disco do sistema operativo correto implementado nas localizações primária e secundária e os dados da aplicação têm de ser armazenados numa unidade separada. Se possível, utilize uma configuração padrão do sistema operativo que possa ser fornecida em ambas as localizações. Após uma ativação pós-falha, tem de anexar a unidade de dados às VMs IaaS existentes no DC secundário. Utilize o AzCopy para copiar instantâneos dos discos de dados para um site remoto.
Tenha em atenção potenciais problemas de consistência após uma ativação pós-falha geográfica 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 georreplicação. A menos Azure Backup seja utilizada, não existem garantias de consistência entre discos, uma vez que a georreplicação é assíncrona e replica de forma independente. É garantido que os discos de VM individuais estão num estado consistente com falhas após uma ativação pós-falha geográfica, mas não são consistentes entre discos. Isto pode causar problemas em alguns casos (por exemplo, no caso da despojamento do disco).
Utilize o Azure Site Recovery para replicar aplicações entre regiões. Com o Azure Site Recovery, os clientes não precisam de se preocupar com a separação dos discos de dados dos discos do sistema operativo ou com potenciais problemas de consistência. O Azure Site Recovery replica cargas de trabalho em execução em máquinas físicas e virtuais a partir de um site primário (no local ou no Azure) para uma localização secundária (no Azure). Quando ocorre uma falha no site primário do cliente, pode ser acionada uma ativação pós-falha para devolver rapidamente o cliente a um estado operacional. Depois de a localização primária ser restaurada, os clientes podem efetuar a reativação pós-falha. Podem replicar facilmente com pontos de recuperação com instantâneos consistentes com a aplicação. Estes instantâneos capturam dados de disco, todos os dados dentro da memória e todas as transações em processo. O Azure Site Recovery permite que os clientes mantenham objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO) dentro dos limites organizacionais. Os clientes também podem executar facilmente testes de recuperação após desastre sem afetar as aplicações na produção. Com os planos de recuperação, os clientes podem sequenciar a ativação pós-falha e a recuperação de aplicações multicamada em execução em várias VMs. Podem agrupar máquinas num plano de recuperação e, opcionalmente, adicionar scripts e ações manuais. Os planos de recuperação podem ser integrados com Automatização do Azure runbooks.

Armazenamento

Recuperação através do armazenamento georredundante de armazenamento de blobs, tabelas, filas e discos de VM

No Azure, os blobs, as tabelas, as filas e os discos de VM são todos georreplicados por predefinição. Isto é referido como armazenamento georredundante (GRS). O GRS replica dados de armazenamento para um datacenter emparelhado localizado a centenas de quilómetros de distância numa região geográfica específica. O GRS foi concebido para proporcionar durabilidade adicional no caso de ocorrer um grande desastre de datacenter. A Microsoft controla quando ocorre a ativação pós-falha e a ativação pós-falha está limitada a grandes desastres em que a localização primária original é considerada irrecuperável num período de tempo razoável. Em alguns cenários, pode demorar vários dias. Normalmente, os dados são replicados dentro de alguns minutos, embora o intervalo de sincronização ainda não esteja abrangido por um contrato de nível de serviço.

Se ocorrer uma ativação pós-falha geográfica, não haverá alterações na forma como a conta é acedida (o URL e a chave de conta não serão alterados). No entanto, a conta de armazenamento estará numa região diferente após a ativação pós-falha. Isto pode afetar as aplicações que necessitam de afinidade regional com a respetiva conta de armazenamento. Mesmo para serviços e aplicações que não necessitam de uma conta de armazenamento no mesmo datacenter, a latência entre datacenters e os custos de largura de banda podem ser motivos apelativos para mover temporariamente o tráfego para a região de ativação pós-falha. Isto pode ter em conta uma estratégia global de recuperação após desastre.

Além da ativação pós-falha automática fornecida pelo GRS, o Azure introduziu um serviço que lhe dá acesso de leitura à cópia dos seus dados na localização de armazenamento secundária. Isto chama-se armazenamento georredundante com acesso de leitura (RA-GRS).

Para obter mais informações sobre o armazenamento GRS e RA-GRS, veja Replicação do Armazenamento do Azure.

Mapeamentos de regiões de georreplicação

É importante saber onde os seus dados são georreplicados, para saber onde implementar as outras instâncias dos seus dados que requerem afinidade regional com o seu armazenamento. Para obter mais informações, veja Regiões Emparelhadas do Azure.

Preços da georreplicação

A georreplicação está incluída nos preços atuais do Armazenamento do Azure. Isto chama-se armazenamento georredundante (GRS). Se não quiser que os seus dados sejam georreplicados, pode desativar a georreplicação para a sua conta. Isto é denominado armazenamento localmente redundante (LRS) e é cobrado a um preço com desconto em comparação com GRS.

Determinar se ocorreu uma ativação pós-falha geográfica

Se ocorrer uma ativação pós-falha geográfica, esta ação será publicada no Dashboard do Azure Service Health. No entanto, as aplicações podem implementar uma forma automatizada de detetar esta opção ao monitorizar a região geográfica da conta de armazenamento. Isto pode ser utilizado para acionar outras operações de recuperação, como a ativação de recursos de computação na região geográfica para onde o armazenamento foi movido. Pode efetuar uma consulta a partir da API de gestão de serviços com Obter Propriedades da 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>

Base de Dados

Base de Dados SQL

SQL do Azure Base de Dados fornece dois tipos de recuperação: georrestauro e georreplicação ativa.

Georrestauro

O restauro geográfico também está disponível com bases de dados Básica, Standard e Premium. Fornece a opção de recuperação predefinida quando a base de dados está indisponível devido a um incidente na região onde a base de dados está alojada. Semelhante ao restauro para um ponto anterior no tempo, o restauro geográfico depende de cópias de segurança de bases de dados no armazenamento georredundante do Azure. Restaura a partir da cópia de segurança georreplicada e, por conseguinte, é resiliente às falhas de armazenamento na região primária. Para obter mais informações, veja Restaurar uma Base de Dados do SQL do Azure ou a ativação pós-falha para uma secundária.

Georreplicação ativa

A georreplicação ativa está disponível para todas as camadas da base de dados. Foi concebido para aplicações que têm requisitos de recuperação mais agressivos do que o restauro geográfico pode oferecer. Com a georreplicação ativa, pode criar até quatro secundárias legíveis em servidores em regiões diferentes. Pode iniciar a ativação pós-falha para qualquer uma das secundárias. Além disso, a georreplicação ativa pode ser utilizada para suportar os cenários de atualização ou reposicionamento de aplicações, bem como o balanceamento de cargas de trabalho só de leitura. Para obter detalhes, veja Configurar a georreplicação ativa para a Base de Dados SQL do Azure e iniciar a ativação pós-falha. Veja Conceber serviços disponíveis globalmente com a Base de Dados do SQL do Azure e Gerir atualizações sem interrupção de aplicações na cloud com Base de Dados SQL georreplicação ativa para obter detalhes sobre como conceber e implementar aplicações e atualizações de aplicações sem tempo de inatividade.

SQL Server nas Máquinas Virtuais do Azure

Estão disponíveis várias opções para recuperação e elevada disponibilidade para SQL Server 2012 (e posterior) em execução no Azure Máquinas Virtuais. Para obter mais informações, veja Elevada disponibilidade e recuperação após desastre para SQL Server no Azure Máquinas Virtuais.

Outros serviços de plataforma do Azure

Ao tentar executar o seu serviço cloud em várias regiões do Azure, tem de considerar as implicações para cada uma das suas dependências. Nas secções seguintes, a documentação de orientação específica do serviço pressupõe que tem de utilizar o mesmo serviço do Azure num datacenter alternativo do Azure. Isto envolve tarefas de configuração e replicação de dados.

Nota

Em alguns casos, estes passos podem ajudar a mitigar uma indisponibilidade específica do serviço em vez de um evento de datacenter completo. Do ponto de vista da aplicação, uma indisponibilidade específica do serviço pode ser igualmente limitativa e exigiria a migração temporária do serviço para uma região alternativa do Azure.

Service Bus

Azure Service Bus utiliza um espaço de nomes exclusivo que não abrange regiões do Azure. Assim, o primeiro requisito é configurar os espaços de nomes do service bus necessários na região alternativa. No entanto, também existem considerações sobre a durabilidade das mensagens em fila. Existem várias estratégias para replicar mensagens nas regiões do Azure. Para obter detalhes sobre estas estratégias de replicação e outras estratégias de recuperação após desastre, veja Melhores práticas para isolar aplicações contra falhas e desastres do Service Bus.

Serviço de Aplicações

Para migrar uma aplicação Serviço de Aplicações do Azure, como Aplicações Web ou Aplicações Móveis, para uma região secundária do Azure, tem de ter uma cópia de segurança do site disponível para publicação. Se a falha não envolver todo o datacenter do Azure, poderá ser possível utilizar o FTP para transferir uma cópia de segurança recente do conteúdo do site. Em seguida, crie uma nova aplicação na região alternativa, a menos que o tenha feito anteriormente para reservar capacidade. Publique o site na nova região e faça as alterações de configuração necessárias. Estas alterações podem incluir cadeias de ligação de base de dados ou outras definições específicas da região. Se necessário, adicione o certificado SSL do site e altere o registo CNAME DNS para que o nome de domínio personalizado aponte para o URL da Aplicação Web do Azure reimplementado.

HDInsight

Os dados associados ao HDInsight são armazenados por predefinição no Armazenamento de Blobs do Azure. O HDInsight requer que um cluster do Hadoop que processe tarefas do MapReduce esteja colocalizado na mesma região que a conta de armazenamento que contém os dados que estão a ser analisados. Desde que utilize a funcionalidade de georreplicação disponível para o Armazenamento do Azure, pode aceder aos seus dados na região secundária onde os dados foram replicados se, por algum motivo, a região primária já não estiver disponível. Pode criar um novo cluster do Hadoop na região onde os dados foram replicados e continuar a processá-lo.

Relatórios SQL

Neste momento, a recuperação da perda de uma região do Azure requer várias instâncias de Relatórios SQL em diferentes regiões do Azure. Estas Relatórios SQL instâncias devem aceder aos mesmos dados e que os dados devem ter o seu próprio plano de recuperação em caso de desastre. Também pode manter cópias de segurança externas do ficheiro RDL para cada relatório.

Serviços de Multimédia

Os Serviços de Multimédia do Azure têm uma abordagem de recuperação diferente para codificação e transmissão em fluxo. Normalmente, a transmissão em fluxo é mais crítica durante uma indisponibilidade regional. Para se preparar, deve ter uma conta dos Serviços de Multimédia em duas regiões do Azure diferentes. O conteúdo codificado deve estar localizado em ambas as regiões. Durante uma falha, pode redirecionar o tráfego de transmissão em fluxo para a região alternativa. A codificação pode ser efetuada em qualquer região do Azure. Se a codificação for sensível ao tempo, por exemplo, durante o processamento de eventos em direto, tem de estar preparado para submeter tarefas a um datacenter alternativo durante as falhas.

Rede virtual

Os ficheiros de configuração fornecem a forma mais rápida de configurar uma rede virtual numa região alternativa do Azure. Depois de configurar a rede virtual na região primária do Azure, exporte as definições de rede virtual da rede atual para um ficheiro de configuração de rede. Se ocorrer uma falha na região primária, restaure a rede virtual a partir do ficheiro de configuração armazenado. Em seguida, configure outros serviços cloud, máquinas virtuais ou definições em vários locais para trabalhar com a nova rede virtual.
Existem recursos relacionados com a VNET que temos de ter em conta (por exemplo, NSG, DNS, Tabelas de Rotas). O método descrito em Infraestrutura como um código é uma forma de gerar sempre o mesmo ambiente e pode implementar numa nova região.

Listas de verificação para recuperação após desastre

Serviços Cloud lista de verificação

Reveja a secção Serviços Cloud deste documento.
Crie uma estratégia de recuperação após desastre entre regiões.
Compreender as compensações na reserva de capacidade em regiões alternativas.
Utilize ferramentas de encaminhamento de tráfego, como o Gestor de Tráfego do Azure.

Máquinas Virtuais lista de verificação

Reveja a secção Máquinas Virtuais deste documento.
Utilize Azure Backup para criar cópias de segurança consistentes da aplicação entre regiões.

Lista de verificação de armazenamento

Reveja a secção Armazenamento deste documento.
Não desative a georreplicação de recursos de armazenamento.
Compreenda a região alternativa para georreplicação se ocorrer uma ativação pós-falha.
Crie estratégias de cópia de segurança personalizadas para estratégias de ativação pós-falha controladas pelo utilizador.

Base de Dados SQL lista de verificação

Reveja a secção Base de Dados SQL deste documento.
Utilize Georrestauro ou georreplicação conforme adequado.

SQL Server na lista de verificação Máquinas Virtuais

Reveja a SQL Server na secção Máquinas Virtuais deste documento.
Utilize Grupos de Disponibilidade AlwaysOn entre regiões ou espelhamento de base de dados.
Em alternativa, utilize a cópia de segurança e o restauro para o armazenamento de blobs.

Lista de verificação do Service Bus

Reveja a secção Service Bus deste documento.
Configurar um espaço de nomes do Service Bus numa região alternativa.
Considere estratégias de replicação personalizadas para mensagens entre regiões.

Serviço de Aplicações lista de verificação

Reveja a secção Serviço de Aplicações deste documento.
Manter cópias de segurança do site fora da região primária.
Se a indisponibilidade for parcial, tente obter o site atual com FTP.
Planeie implementar o site num site novo ou existente numa região alternativa.
Planear alterações de configuração para registos CNAME de Aplicação e DNS.

Lista de verificação do HDInsight

Reveja a secção do HDInsight deste documento.
Crie um novo cluster do Hadoop na região com dados replicados.

Relatórios SQL lista de verificação

Reveja a secção Relatórios SQL deste documento.
Manter uma instância de Relatórios SQL alternativa numa região diferente.
Mantenha um plano separado para replicar o destino para essa região.

Lista de verificação dos Serviços de Multimédia

Reveja a secção Serviços de Multimédia deste documento.
Crie uma conta dos Serviços de Multimédia numa região alternativa.
Codifigue o mesmo conteúdo em ambas as regiões para suportar a ativação pós-falha de transmissão em fluxo.
Submeta tarefas de codificação para uma região alternativa se ocorrer uma interrupção do serviço.

Rede Virtual lista de verificação

Reveja a secção Rede Virtual deste documento.
Utilize as definições de rede virtual exportadas para voltar a criá-la noutra região.