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

O Azure é dividido física e logicamente em unidades chamadas regiões. Uma região consiste em um ou mais data centers próximos. Muitas regiões e serviços também oferecem suporte a zonas de disponibilidade, que podem ser usadas para fornecer mais resiliência contra interrupções em um único data center. Considere o uso de 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 se tornem inacessíveis, por exemplo, devido a falhas de rede. Ou as instalações podem ser totalmente perdidas, por exemplo, devido a um desastre natural. O Azure tem recursos para criar aplicativos 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 possa afetar outras zonas ou regiões.

Serviços cloud

Gestão de recursos

Você pode distribuir instâncias de computação entre regiões criando um serviço de nuvem separado em cada região de destino e, em seguida, publicando o pacote de implantação em cada serviço de nuvem. No entanto, a distribuição de tráfego entre 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 sobressalentes a serem implantadas com antecedência para recuperação de desastres é um aspeto importante do planejamento de capacidade. Ter uma implantação secundária em grande escala garante que a capacidade já esteja disponível quando necessário; no entanto, isso efetivamente dobra o custo. Um padrão comum é ter uma implantação secundária pequena, grande o suficiente para executar serviços críticos. Essa pequena implantação secundária é uma boa ideia, tanto para reservar capacidade quanto para testar a configuração do ambiente secundário.

Balanceamento de Carga

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

Estratégias

Muitas estratégias alternativas estão disponíveis para implementar computação distribuída entre regiões. Eles devem ser adaptados aos requisitos de negócios específicos e às circunstâncias do aplicativo. A 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 é apropriado para aplicativos não críticos que não exigem um tempo de recuperação garantido.

• Warm Spare (Ativo/Passivo): um serviço hospedado secundário é criado em uma região alternativa e as funções são implantadas para garantir 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 o tráfego entre regiões.

• Hot Spare (Ativo/Ativo): O aplicativo foi projetado para receber carga de produção em várias regiões. Os serviços de nuvem em cada região podem ser configurados para uma capacidade maior do que a necessária para fins de recuperação de desastres. Como alternativa, os serviços de nuvem podem ser dimensionados conforme necessário no momento de um desastre e failover. Essa abordagem requer investimentos substanciais no design de aplicativos, mas traz 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 desastres e alta disponibilidade para aplicativos 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 aspetos. No entanto, há diferenças importantes porque uma VM IaaS consiste na VM e no disco da VM.

• Use o Backup do Azure para criar backups entre regiões que sejam consistentes com aplicativos. O Backup do Azure permite que os clientes criem backups consistentes de aplicativos em vários discos de VM e ofereçam 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. Não pode ser definido mais tarde. Se uma região for perdida, a Microsoft disponibilizará os backups para os clientes. Os clientes podem restaurar para qualquer um dos seus pontos de restauração configurados.

• Separe o disco 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 é um problema se sua estratégia de recuperação for reimplantar após o desastre. No entanto, pode ser um problema se você estiver usando a abordagem Warm Spare para reservar capacidade. Para implementar isso corretamente, você deve ter o disco do sistema operacional correto implantado nos locais primário e secundário, e os dados do aplicativo devem ser armazenados em uma unidade separada. Se possível, use uma configuração padrão do sistema operacional que possa ser fornecida em ambos os locais. Após um failover, você deve anexar a unidade de dados às VMs IaaS existentes no DC secundário. Use o AzCopy para copiar instantâneos do(s) disco(s) de dados para um site remoto.

• Esteja ciente de 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á garantias de consistência entre discos, porque a replicação geográfica é assíncrona e replica independentemente. É garantido que os discos de VM individuais estejam em um estado consistente de falha após um failover geográfico, mas não consistentes entre discos. Isso pode causar problemas em alguns casos (por exemplo, no caso de striping de disco).

• Use o Azure Site Recovery para replicar aplicativos entre regiões. Com o Azure Site Recovery, os clientes não precisam se preocupar com a separação de 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 local 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 snapshots 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 várias VMs. Eles podem agrupar máquinas em um plano de recuperação e, opcionalmente, adicionar scripts e ações manuais. Os planos de recuperação podem ser integrados com runbooks de Automação do Azure.

Armazenamento

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

No Azure, blobs, tabelas, filas e discos de VM são todos replicados geograficamente por padrão. Isso é conhecido como armazenamento com redundância geográfica (GRS). O GRS replica dados de armazenamento para um datacenter emparelhado localizado a centenas de quilômetros de distância dentro de uma região geográfica específica. O GRS foi projetado para fornecer durabilidade adicional no caso de ocorrer um grande desastre no datacenter. A Microsoft controla quando ocorre failover e o failover é limitado a grandes desastres nos quais o local principal original é considerado irrecuperável em um período de tempo razoável. Em alguns cenários, isso pode levar vários dias. Normalmente, os dados são replicados em poucos minutos, embora o intervalo de sincronização ainda não esteja 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, a latência entre datacenters pode ser motivo convincente para mover o tráfego para a região de failover temporariamente. Isso pode contribuir para uma estratégia geral de recuperação de desastres.

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

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

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

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

Preços da georreplicação

A replicação geográfica está incluída nos preços atuais do Armazenamento do Azure. Isso é chamado de armazenamento com redundância geográfica (GRS). Se não quiser que os seus dados sejam replicados geograficamente, pode desativar a replicação geográfica para a sua conta. Isso é chamado de armazenamento localmente redundante (LRS) e é cobrado a um preço com desconto em comparação com o GRS.

Determinando se ocorreu um failover geográfico

Se ocorrer um failover geográfico, ele será postado no Painel de Integridade do Serviço do Azure. No entanto, os aplicativos podem implementar um meio automatizado de detetar isso, monitorando a geo-região de sua conta de armazenamento. Isso pode ser usado 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.

Base de Dados

Base 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.

Restauro geográfico

A restauração geográfica também está disponível com 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 onde o banco de dados está hospedado. Semelhante à restauração point-in-time, a restauração geográfica depende de backups de banco de dados no armazenamento do Azure com redundância geográfica. Ele restaura a partir da cópia de backup replicada geograficamente e, portanto, é resiliente às interrupções de armazenamento na região principal. Para obter mais informações, consulte Restaurar um Banco de Dados SQL do Azure ou failover para um secundário.

Georreplicação ativa

A replicação geográfica ativa está disponível para todas as camadas de banco de dados. Ele foi projetado para aplicativos que têm requisitos de recuperação mais agressivos do que a restauração geográfica pode oferecer. Usando a replicação geográfica ativa, você pode criar até quatro secundários legíveis em servidores em diferentes regiões. 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 aos cenários de upgrade ou realocação de aplicativos, bem como ao balanceamento de carga para cargas de trabalho somente leitura. Para obter detalhes, consulte Configurar a replicação geográfica ativa para o Banco de Dados SQL do Azure e iniciar o failover. Consulte Projetando serviços disponíveis globalmente usando o Banco de Dados SQL do Azure e Gerenciando atualizações contínuas de aplicativos em nuvem usando a replicação geográfica ativa do Banco de Dados SQL para obter detalhes sobre como projetar e implementar aplicativos e atualizações de aplicativos sem tempo de inatividade.

SQL Server nas Máquinas Virtuais do Azure

Uma variedade de opções está disponível para recuperação e alta disponibilidade para o SQL Server 2012 (e posterior) em execução nas Máquinas Virtuais do Azure. Para obter mais informações, consulte 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, a orientação específica do serviço pressupõe que você deve usar o mesmo serviço do Azure em um datacenter alternativo do Azure. Isso envolve tarefas de configuração e replicação de dados.

Service Bus

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 de barramento de serviço necessários na região alternativa. No entanto, também há considerações para a durabilidade das mensagens em 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 desastres, consulte Práticas recomendadas para isolar aplicativos contra interrupções e desastres do Service Bus.

Serviço de Aplicações

Para migrar um aplicativo do Serviço de Aplicativo do Azure, como Aplicativos Web ou Aplicativos Móveis, para uma região secundária do Azure, 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 reservar capacidade. Publique o site na nova região e faça as 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 da 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 reimplantada.

HDInsight

Os dados associados ao HDInsight são armazenados por padrão no Armazenamento de Blobs do Azure. O HDInsight exige que um cluster Hadoop que processa trabalhos MapReduce seja colocalizado na mesma região da conta de armazenamento que contém os dados que estão sendo analisados. Desde que você use o recurso de replicação geográfica disponível para o Armazenamento do Azure, poderá acessar seus 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 onde os dados foram replicados e continuar processando-os.

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. 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 Multimédia

Os Serviços de Mídia do Azure têm uma abordagem de recuperação diferente para codificação e streaming. Normalmente, o streaming é mais crítico 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 diferentes do Azure. 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ê deve estar preparado para enviar trabalhos para um datacenter alternativo durante 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. Depois de configurar a rede virtual na região principal 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 a partir do 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 com VNET que precisamos de ter 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 todas as vezes, e você pode implantar em uma nova região.

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

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

1. Consulte a secção Serviços na Nuvem deste documento.
2. Crie uma estratégia de recuperação de desastres entre regiões.
3. Compreender as compensações na reserva de capacidade em regiões alternativas.
4. Use ferramentas de roteamento de tráfego, como o Gerenciador de Tráfego do Azure.

Lista de verificação de Máquinas Virtuais

1. Analise a seção Máquinas Virtuais deste documento.
2. Use o Backup do Azure para criar backups consistentes de aplicativos entre regiões.

Lista de verificação de armazenamento

1. Analise a seção Armazenamento deste documento.
2. Não desative a replicação geográfica de recursos de armazenamento.
3. Entenda a região alternativa para replicação geográfica se ocorrer um failover.
4. Crie estratégias de backup personalizadas para estratégias de failover controladas pelo usuário.

Lista de verificação do Banco de dados SQL

1. Analise a seção Banco de dados SQL deste documento.
2. 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

1. Consulte a seção SQL Server em máquinas virtuais deste documento.
2. Use grupos de disponibilidade AlwaysOn entre regiões ou espelhamento de banco de dados.
3. Como alternativa, use backup e restauração para armazenamento de blob.

Lista de verificação do Service Bus

1. Analise a seção Service Bus deste documento.
2. Configure um namespace do Service Bus em uma região alternativa.
3. Considere estratégias de replicação personalizadas para mensagens entre regiões.

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

1. Analise a seção Serviço de Aplicativo deste documento.
2. Mantenha backups do site fora da região principal.
3. Se a interrupção for parcial, tente recuperar o site atual com FTP.
4. Planeje implantar o site em um site novo ou existente em uma região alternativa.
5. Planeje alterações de configuração para registros CNAME de aplicativo e DNS.

Lista de verificação do HDInsight

1. Analise a seção HDInsight deste documento.
2. Crie um novo cluster Hadoop na região com dados replicados.

Lista de verificação de Relatórios SQL

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

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

1. Analise a seção Serviços de Mídia deste documento.
2. Crie uma conta de Serviços de Mídia em uma região alternativa.
3. Codifique o mesmo conteúdo em ambas as regiões para oferecer suporte a failover de streaming.
4. Envie trabalhos de codificação para uma região alternativa se ocorrer uma interrupção do serviço.

Lista de verificação da Rede Virtual

1. Analise a seção Rede Virtual deste documento.
2. Use as configurações de rede virtual exportadas para recriá-lo em outra região.