Exportar (0) Imprimir
Expandir Tudo

Recuperação de desastres e alta disponibilidade para aplicativos do Azure

Atualizado: abril de 2014

Autores principais: Michael McKeown, arquiteto de soluções de nuvem (Aditi); Hanu Kommalapati, evangelista principal de tecnologia (Microsoft)

Autor de contribuição: Jason Roth

Revisores: Patrick Wickline, Dennis Mulder, Steve Howard, Tim Wieman, James Podgorski, Ryan Berry, Shweta Gupta, Harry Chen, Jim Blanchard, Andy Roberts, Christian Els

Este documento aborda a alta disponibilidade de aplicativos executados no Azure. Uma estratégia geral para a alta disponibilidade também inclui a área de recuperação de desastres (DR). O planejamento para falhas e desastres na nuvem requer que você reconheça as falhas rapidamente. Então você implementa uma estratégia que combine com a sua tolerância para a inatividade do aplicativo. Além disso, você deve considerar a extensão da perda de dados que o aplicativo pode tolerar sem causar consequências adversas para os negócios quando eles são restaurados.

Quando perguntamos a clientes se eles estão preparados para falhas temporárias e em grande escala, a maioria disse que sim. No entanto, antes de responder isso, pergunte a si mesmo se sua empresa ensaia essas falhas. Você testa a recuperação de bancos de dados para garantir que tem os processos adequados? Provavelmente não. Isso ocorre porque a recuperação de desastres (DR) com êxito começa com muito planejamento e arquitetura para implementar esses processos. Assim como em vários outros requisitos não funcionais, como a segurança, a recuperação de desastres raramente obtém a análise antecipada e a alocação de tempo necessária. Além disso, a maioria dos clientes não têm o orçamento para datacenters geograficamente distribuídos com capacidade redundante. Como consequência, mesmo os aplicativos essenciais são excluídos com frequência do planejamento de DR apropriado.

Plataformas de nuvem, como o Azure, fornecem datacenters geograficamente dispersos ao redor do mundo. Essas plataformas também fornecem os recursos que dão suporte à disponibilidade e a uma variedade de cenários de DR. Agora, cada aplicativo na Nuvem de missão crítica pode receber a devida atenção para a verificação de desastres do sistema. O Azure tem resiliência e DR incorporado a muitos de seus serviços. Você precisa analisar os recursos dessa plataforma cuidadosamente e complementados com as estratégias de aplicativo.

Este artigo descreve as etapas de arquitetura necessárias que você precisa a verificação de desastres em uma implantação do Azure. De forma que você possa implementar o processo de continuidade dos negócios como um todo. Um plano de continuidade dos negócios é um roteiro para continuar as operações sob condições adversas. Isso pode causar uma falha em tecnologia, como um serviço inoperante, ou um desastre natural, como uma tempestade ou a interrupção de energia. A resiliência do aplicativo para desastres é apenas um subconjunto do processo maior de DR, conforme descrito neste documento de NIST: Guia de planejamento de contingência para sistemas de tecnologia da informação

As seções a seguir definem níveis diferentes de falhas, técnicas para lidar com elas, e arquiteturas que dão suporte a essas técnicas. Essas informações fornecem a entrada em seus processos e procedimentos de DR para garantir que a estratégia de DR funcione de maneira correta e eficiente.

Um aplicativo bem projetado pode suportar falhas de recursos em nível tático e também pode tolerar falhas estratégicas em sistemas no nível do datacenter. As seções a seguir definem a terminologia referenciada em todo o documento para descrever os vários aspectos de serviços de nuvem resilientes.

Um aplicativo em nuvem altamente disponível implementa estratégias para absorver a interrupção das dependências, como os serviços gerenciados oferecidos pela plataforma em nuvem. Independentemente de possíveis falhas dos recursos da plataforma de nuvem, essa abordagem permite que o aplicativo continue a exibir as características sistêmicas funcionais e não funcionais esperadas. Isso é abordado em detalhes no documento À prova de falhas: orientação para arquiteturas resilientes na nuvem

Quando você implementa o aplicativo, é preciso considerar a probabilidade de uma interrupção de recursos. Adicionalmente, considere o impacto que uma interrupção terá sobre o aplicativo na perspectiva dos negócios antes de se aprofundar nas estratégias de implementação. Sem a devida consideração ao impacto sobre os negócios e à probabilidade de atingir a condição de risco, a implementação pode ser dispendiosa e potencialmente desnecessária.

Considere uma analogia automotiva para alta disponibilidade. Peças de qualidade e engenharia avançada não impedem falhas ocasionais. Por exemplo, quando o carro tem um pneu furado, ainda é possível movimentá-lo, mas ele opera com a funcionalidade prejudicada. Se você se planejou para essa ocorrência potencial, pode usar um dos pneus sobressalentes até alcançar uma oficina mecânica. Embora o pneu sobressalente não permita rodar em alta velocidade, pelo menos você consegue dirigir o veículo até você substituir o pneu. De forma similar, um serviço de nuvem preparado para uma eventual perda de recursos pode impedir que um problema de menor proporção interrompa o aplicativo inteiro. Isso é vale mesmo para quando o serviço de nuvem precisa ser executado com funcionalidade degradada.

Há algumas características principais de serviços de nuvem altamente disponíveis: disponibilidade, escalabilidade e tolerância a falhas. Embora essas características estejam correlacionadas, é importante compreender cada uma delas e como contribuem para a disponibilidade geral da solução.

Um aplicativo disponível considera a disponibilidade da infraestrutura subjacente e dos serviços dependentes. Os aplicativos disponíveis removem pontos únicos de falha através de redundância e de design flexível. Quando falamos em disponibilidade no Azure, é importante compreender o conceito da disponibilidade efetiva da plataforma. A disponibilidade efetiva considera os SLAs (contratos de nível de serviço) de cada serviço dependente e seu efeito cumulativo na disponibilidade geral do sistema.

A disponibilidade do sistema é a medida da porcentagem de uma janela de tempo de operação do sistema. Por exemplo, a disponibilidade do SLA de pelo menos duas instâncias de uma função Web ou de trabalho no Azure é de 99,95% (fora dos 100%). Não são medidos o desempenho ou a funcionalidade dos serviços executados nessas funções. No entanto, a disponibilidade efetiva do serviço de nuvem também é afetada pelos diversos SLAs dos outros serviços dependentes. Quanto mais partes móveis no sistema, maior cuidado você deverá tomar para garantir que o aplicativo atenda com flexibilidade aos requisitos de disponibilidade dos usuários finais.

Considere os seguintes SLAs para um serviço do Azure que usa os serviços do Azure: Computação, Banco de dados SQL do Azure e Armazenamento do Azure.

 

Serviço do Azure Contrato de Nível de Serviço Tempo de inatividade em potencial por minuto/mês (30 dias)

Computar

99.95%

21.6

Banco de Dados SQL

99.90%

43.2

Armazenamento

99.90%

43.2

Lembre-se de que todos os serviços podem ficar inativos em momentos distintos. Neste exemplo simplificado, o número total de minutos por mês de inatividade do aplicativo é de 108 minutos. Um mês de 30 dias tem um total de 43.200 minutos. 108 minutos equivalem a 0,25% do número total de minutos em um mês de 30 dias (43.200 minutos). Isso oferece uma disponibilidade efetiva de 99,75% para o serviço de nuvem.

Entretanto, o uso das técnicas de disponibilidade descritas neste documento pode aumentar esse valor. Por exemplo, se você projetar seu aplicativo para continuar em execução quando o Banco de dados SQL não estiver disponível, poderá remover isso da equação. Isso poderia significar que o aplicativo é executado com recursos reduzidos; então, deve-se considerar também os requisitos dos negócios. Para obter uma lista completa de SLAs do Azure, consulte Contratos de Nível de Serviço.

A escalabilidade afeta diretamente a disponibilidade - um aplicativo que falha com carga maior não está mais disponível. Os aplicativos escalonáveis podem atender à crescente demanda com resultados consistentes em janelas de tempo aceitáveis. Quando um sistema é escalonável, ele é dimensionado horizontal ou verticalmente para gerenciar o aumento de carga e manter o desempenho consistente. Em termos básicos, o escalonamento horizontal adiciona mais computadores do mesmo tamanho (processador, memória, largura de banda), enquanto o escalonamento vertical aumenta o tamanho dos computadores existentes. Para o Azure, você tem opções de escalonamento vertical para selecionar vários tamanhos de computador para a computação. Contudo, a alteração no tamanho do computador exige a reimplantação. Em virtude disso, as soluções mais flexíveis são criadas para o escalonamento horizontal. Isto é especialmente verdadeiro para a computação porque você pode facilmente incrementar o número de instâncias executadas de qualquer função web ou de trabalho. Essas instâncias adicionais tratam o aumento de tráfego no portal do Azure na Web, scripts PowerShell ou o código. Baseie essa decisão no aumento da métrica monitorada específica. Neste cenário, o desempenho do usuário ou a métrica não são tão afetados com a carga. Normalmente, as funções web e de trabalho armazenam qualquer estado externamente. Isto permite o balanceamento de carga flexível e o tratamento de forma normal para qualquer alteração em contagens da instância. O escalonamento horizontal também funciona bem com serviços, como o Armazenamento do Azure, que não fornecem opções em camadas para o escalonamento vertical.

As implantações na nuvem devem ser consideradas uma coleção de unidades de escala. Isto confere elasticidade ao aplicativo para atender às necessidades de produção dos usuários finais. As unidades de escala são mais fáceis de visualizar na Web e no nível de servidor de aplicativo. Pois o Azure já fornece mais nós de computação sem monitoração de estado através das funções Web e de trabalho. Adicionar mais unidades de escala de computação à implantação não terá efeitos colaterais sobre o gerenciamento do estado do aplicativo porque as unidades de escala de computação não têm monitoração de estado. Uma unidade de escala de armazenamento é responsável por gerenciar uma partição de dados (estruturados ou não estruturados). Os exemplos de unidades de escala de armazenamento incluem a partição de tabela do Azure, o contêiner de blob e o Banco de dados SQL. Até mesmo o uso de várias contas de Armazenamento do Azure tem um impacto direto na escalabilidade do aplicativo. Você deve projetar um serviço de nuvem altamente escalonável para incorporar múltiplas unidades de escala de armazenamento. Por exemplo, se um aplicativo usar dados relacionais, particionar os dados em vários Bancos de dados SQL. Fazer isso permite que o armazenamento acompanhe o modelo elástico de unidade de escala de computação. Da mesma forma, o Armazenamento do Azure permite que esquemas de partição de dados que exigem designs deliberados atendam às necessidades de produção da camada de computação. Para obter uma lista de práticas recomendadas para criar serviços de nuvem escalonáveis, consulte Práticas recomendadas para o design de serviços em grande escala em serviços de nuvem do Azure.

Os aplicativos precisam considerar que cada recurso de nuvem dependente ficará inativo em algum momento. Um aplicativo tolerante a falhas detecta e corrige elementos com falha para prosseguir e retornar os resultados corretos em um período de tempo específico. Para condições de erro temporárias, um sistema tolerante a falhas empregará uma política de repetição. Para falhas mais graves, o aplicativo pode detectar problemas e recorre a planos alternativos de hardware ou de contingência até corrigir a falha. Um aplicativo confiável pode gerenciar adequadamente a falha de uma ou mais partes e prosseguir normalmente com a operação. Os aplicativos tolerantes a falhas podem usar uma ou mais estratégias de design, como a redundância, a replicação ou a funcionalidade degradada.

Uma implantação em nuvem pode parar de funcionar devido a uma interrupção sistêmica dos serviços dependentes ou da infraestrutura subjacente. Nessas circunstâncias, um plano de continuidade dos negócios dispara o processo DR (recuperação de desastres). Esse processo costuma envolver o pessoal de operações e procedimentos automatizados para reativar o aplicativo em um datacenter operacional. Isso exige a transferência de usuários, dados e serviços do aplicativo para o novo datacenter. Isso envolve o uso da mídia de backup ou de replicação contínua.

Considere a analogia anterior que comparou a alta disponibilidade com a capacidade de solucionar o problema de um pneu furado usando um sobressalente. Por outro lado, a recuperação de desastres envolve as etapas executadas após um acidente de carro onde o veículo fica inutilizável. Nesse caso, a melhor solução é encontrar uma forma eficiente de trocar de carro chamando um serviço de guincho ou um amigo. Nesse cenário, provavelmente existirá um atraso maior até voltar para a estrada. Também há uma maior complexidade no reparo e na entrega do veículo original. Da mesma forma, a recuperação de desastres em outro datacenter é uma tarefa complexa que costuma envolver um tempo de inatividade e a potencial perda de dados. Para compreender e avaliar melhor as estratégias de recuperação de desastres, é importante definir dois termos: RTO (objetivo de tempo de recuperação) e RPO (objetivo de ponto de recuperação).

O RTO (objetivo de tempo de recuperação) é a quantidade máxima de tempo alocada para restaurar a funcionalidade do aplicativo. Ele se baseia em requisitos dos negócios e está relacionado à importância do aplicativo. Os aplicativos de negócios críticos exigem um baixo RTO.

O RPO (objetivo de ponto de recuperação) é a janela de tempo aceitável de dados perdidos devido ao processo de recuperação. Por exemplo, se o RPO for de uma hora, você deve fazer um backup completo ou replicar os dados pelo menos a cada hora. Uma vez que você coloque o aplicativo em um datacenter alternativo, poderia faltar até uma hora de dados no backup de dados. Assim como no RTO, os aplicativos críticos visam um RPO bem menor.

Um aplicativo altamente disponível absorve flutuações em disponibilidade, carga e falhas temporárias nos serviços dependentes e no hardware. O aplicativo continua a operar em um nível aceitável de resposta sistêmico e do usuário conforme definido por requisitos de negócios ou contratos de nível de serviço do aplicativo.

O Azure tem muitos recursos internos da plataforma que oferecem suporte a aplicativos altamente disponíveis. Esta seção descreve alguns desses recursos principais. Para obter uma análise mais abrangente da plataforma, consulte Orientação técnica de continuidade de negócios do Azure.

O Controlador de Malha do Azure (FC) é responsável por provisionar e monitorar a condição das instâncias de computação do Azure. O Controlador de Malha verifica o status do hardware e do software das instâncias do computador host e convidado. Quando detectar uma falha, ele forçará SLAs, automaticamente realocando as instâncias de VM. O SLA de computação tem suporte adicional do conceito de domínios de falha e de atualização.

Quando várias instâncias da função são implantadas, o Azure implanta essas instâncias em diferentes domínios de falha. Um limite de domínio de falha é basicamente um rack diferente de hardware no mesmo datacenter. Os domínios de falha reduzem a probabilidade de que uma falha de hardware localizada interrompa o serviço de um aplicativo. Você não pode gerenciar o número de domínios de falha que são alocados às funções Web e de trabalho. O Controlador de Malha usa os recursos dedicados que são separados dos aplicativos hospedados pelo Azure. Ele tem 100% de tempo de ativo porque serve como o núcleo do sistema do Azure. Ele monitora e gerencia instâncias de função em domínios de falha. O diagrama a seguir mostra os recursos compartilhados do Azure que são implantados e gerenciados pelo FC em diferentes domínios de falha.

Figura 1 - Isolamento de domínio de falha (exibição simplificada)

Os domínios de atualização são semelhantes aos domínios de falha em termos de função, mas dão suporte a atualizações, e não a falhas. Um domínio de atualização é uma unidade lógica de separação da instância que determina quais instâncias em um serviço específico serão atualizadas em um momento determinado. Por padrão, são definidos cinco domínios de atualização para a implantação do serviço hospedado. No entanto, você pode alterar esse valor no arquivo de definição de serviço. Por exemplo, você tem oito instâncias na sua função web. Terá duas instâncias em três domínios de atualização e duas instâncias em um domínio de atualização. O Azure define a sequência de atualização, mas é baseada no número de domínios de atualização. Para obter mais informações sobre domínios de atualização, consulte Atualizar um Serviço do Azure.

Além desses recursos da plataforma que dão suporte à alta disponibilidade de computação, o Azure insere recursos de alta disponibilidade em outros serviços. Por exemplo, o Armazenamento do Azure mantém três réplicas de todos os dados blob, de tabela e de fila. Ele também permite a opção de replicação geográfica para armazenar backups de blobs e tabelas em um datacenter secundário. A CDN (Rede de Fornecimento de Conteúdo) permite o armazenamento de blobs em cache ao redor do mundo para fins de redundância e escalabilidade. O Banco de dados SQL do Azure também mantém várias réplicas. Além do documento Orientação técnica de continuidade de negócios do Azure, consulte o documento Práticas recomendadas para o design de serviços em grande escala nos Serviços de Nuvem do Azure. Eles fornecem uma discussão completa sobre os recursos de disponibilidade da plataforma.

Embora o Azure forneça vários recursos que dão suporte à alta disponibilidade, é importante compreender suas restrições. Para a computação, o Azure garante que as funções estão disponíveis e operacionais, mas ele não sabe se seu aplicativo está operacional ou sobrecarregado. Para o Banco de dados SQL do Azure, os dados são replicados de forma síncrona no datacenter. Essas réplicas de banco de dados não são backups pontuais. Para o Armazenamento do Azure, tabelas e dados blob são replicados, por padrão, para um datacenter alternativo. No entanto, você não pode acessar as replicas até que o Microsoft decida efetuar failover no site alternativo. Um failover de datacenter em geral ocorre apenas no caso de uma interrupção prolongada do datacenter, e não há SLA para o período de failover geográfico. Também é importante observar que qualquer corrupção de dados se espalha rapidamente nas réplicas. Por esses motivos, você deve complementar os recursos de disponibilidade da plataforma com recursos de disponibilidade específicos do aplicativo. Esses recursos de disponibilidade do aplicativo incluem o recurso de instantâneo blob para criar backups pontuais de dados blob.

A maior parte deste documento aborda serviços de nuvem, que usam um modelo PaaS (Plataforma como Serviço). No entanto, também há recursos de disponibilidade específicos para Máquinas Virtuais do Azure, que usam um modelo IaaS (Infraestrutura como Serviço). Para obter alta disponibilidade com máquinas virtuais, você deve usar conjuntos de disponibilidade. Um conjunto de disponibilidade funciona de forma semelhante a domínios de falha e de atualização. Em um conjunto de disponibilidade, o Azure posiciona as máquinas virtuais de forma que impeça falhas de hardware localizadas e atividades de manutenção de interromper todos os computadores desse grupo. Os conjuntos de disponibilidade são necessários para obter o SLA do Azure para a disponibilidade das máquinas virtuais. Para obter mais informações, consulte Gerenciar a disponibilidade de máquinas virtuais. O diagrama a seguir fornece uma representação de dois conjuntos de disponibilidade que agrupam máquinas virtuais Web e do SQL Server, respectivamente.

Figura 2 - Conjuntos de disponibilidade para Máquinas Virtuais do Azure

Observe que, no diagrama anterior, o SQL Server está instalado e é executado em máquinas virtuais. Isso é diferente da discussão anterior do Banco de dados SQL do Azure, que fornece o banco de dados como um serviço gerenciado.

A maioria das estratégias de aplicativo para alta disponibilidade envolvem a redundância ou a remoção de dependências de hardware entre componentes de aplicativo. A criação do aplicativo deve oferecer suporte à tolerância a falhas durante o tempo de inatividade esporádica do Azure ou de serviços de terceiros. As seções a seguir descrevem vários padrões do aplicativo para aumentar a disponibilidade dos serviços de nuvem.

Considere a comunicação assíncrona entre serviços acoplados livremente para aumentar a disponibilidade em aplicativos do Azure. Neste padrão, as mensagens são escritas nas filas de armazenamento ou nas filas do Service Bus para processamento posterior. Quando você escreve a mensagem na fila, o controle retorna imediatamente para o remetente da mensagem. Outro camada do aplicativo se encarrega do processamento de mensagens, geralmente implementado com uma função de trabalho. Se a função de trabalho for interrompida, as mensagens serão acumuladas na fila até que o serviço de processamento seja restaurado. Desde que a fila fique disponível, não haverá dependência direta entre o remetente front-end e o processador da mensagem. Isso elimina a necessidade de chamadas de serviço síncronas que podem representar um afunilamento na produção em aplicativos distribuídos.

Uma variação disso usa o Armazenamento do Azure (blobs, tabelas, filas) ou as filas do Service Bus como um local de failover para chamadas de banco de dados com falha. Por exemplo, uma chamada síncrona de um aplicativo para outro serviço (como um Banco de Dados SQL do Azure) falhar repetidamente. Você poderá serializar os dados no armazenamento durável. Em algum momento posterior, quando o serviço ou o banco de dados estiver novamente online, o aplicativo poderá reenviar a solicitação de armazenamento. A diferença neste modelo é que o local intermediário não é uma parte constante do fluxo de trabalho do aplicativo. Ele é usado somente em cenários de falha.

Em ambos os cenários, a comunicação assíncrona e o armazenamento intermediário impedem que um serviço de back-end inativo interrompa o aplicativo inteiro. As filas servem como um intermediário lógico. Para obter orientação sobre como escolher o serviço de enfileiramento correto, consulte Filas do Azure e filas do Azure Service Bus - semelhanças e diferenças.

Um ponto-chave na criação do aplicativo altamente disponível é utilizar a lógica da repetição no código para tratar normalmente um serviço que fica temporariamente inativo. O Bloco do aplicativo para tratamento de falhas temporárias, desenvolvido pela equipe de padrões e práticas da Microsoft, ajuda desenvolvedores de aplicativos neste processo. A palavra “temporário” significa uma condição temporária que se estende por um período relativamente curto. No contexto deste documento, tratar falhas temporárias faz parte do desenvolvimento de um aplicativo altamente disponível. Exemplos de condições temporárias incluem erros intermitentes de rede e conexões perdidas de bancos de dados.

O bloco do aplicativo para tratar falhas temporárias é uma forma simplificada de tratar falhas no seu código de forma simples. Ele permite aumentar a disponibilidade dos aplicativos, adicionando uma lógica avançada de tratamento de falhas temporárias. Na maioria dos casos, a lógica da repetição trata as breves interrupções, e reconecta o remetente e o destinatário depois de uma ou várias tentativas com falhas. Uma tentativa de repetição bem-sucedida costuma passar despercebida para usuários do aplicativo.

Há três opções para que os desenvolvedores gerenciem sua lógica de repetição: incremental, intervalo fixo, e exponencial. Na incremental, o tempo de espera é mais longo antes de cada repetição, aumentando linearmente (por exemplo, 1, 2, 3 e 4 segundos). No intervalo fixo, aguarda-se pelo mesmo período de tempo entre cada repetição (por exemplo, 2 segundos). Para uma opção mais aleatória, a retirada exponencial é mais longa entre repetições. No entanto, usa um comportamento exponencial (por exemplo, 2, 4, 8 e 16 segundos).

A estratégia de alto nível no seu código é:

  1. Defina sua estratégia e política de repetição

  2. Tente a operação que pode resultar em uma falha temporária

  3. Se a falha temporária ocorrer, a política de repetição será chamada

  4. Se todas as repetições falharem, obtenha uma exceção final

Teste sua lógica de repetição em falhas simuladas para garantir que as repetições em operações sucessivas não resultem em um longo atraso não previsto. Faça isto antes de decidir abandonar a tarefa.

Os dados de referência são os dados apenas de leitura de um aplicativo. Estes dados fornecem um contexto de negócios no qual o aplicativo gerencia dados transacionais durante uma operação de negócios. Os dados transacionais são uma função pontual dos dados de referência. Portanto, sua integridade depende do instantâneo dos dados de referência no momento de captura da transação. Essa é uma definição simples, mas talvez seja suficiente para nosso propósito aqui.

Os dados de referência no contexto de um aplicativo são necessários para a operação do aplicativo. Os aplicativos respectivos criam e mantêm os dados de referência. Os sistemas de Gerenciamento de Dados Mestre frequentemente executam essa função. Esses sistemas são responsáveis pelo ciclo de vida dos dados de referência. Exemplos de dados de referência incluem o catálogo de produtos, o mestre de funcionários, o mestre de peças e o mestre de equipamentos. Os dados de referência também podem ser obtidos fora da organização, por exemplo, códigos postais ou taxas de impostos. As estratégias para aumentar a disponibilidade de dados de referência normalmente são menos difíceis do que em dados transacionais. Os dados de referência têm a vantagem de serem na maior parte imutáveis.

Você pode fazer com que as funções Web e de trabalho do Azure que consomem dados de referência tornem-se autônomas em tempo de execução. Basta implantar os dados de referência no aplicativo. Se o tamanho do armazenamento local permitir essa implantação, esse será um estado ideal. Os bancos de dados inseridos (SQL, NOSQL) ou arquivos XML implantados no sistema de arquivos local ajudarão com a autonomia de unidades de escala de computação do Azure. Entretanto, você deve ter um mecanismo para atualizar os dados em cada função sem precisar de uma reimplantação. Para fazer isso, coloque as atualizações dos dados de referência em um ponto de extremidade de armazenamento na nuvem (por exemplo, armazenamento de blob do Azure ou Banco de dados SQL). Adicione o código a cada função que baixe as atualizações de dados nos nós de computação na inicialização da função. De forma alternativa, adicione o código que permita que um administrador execute um download forçado nas instâncias da função. Para aumentar a disponibilidade, as funções também deverão conter um conjunto de dados de referência, caso o armazenamento esteja inativo. Isso permite que as funções iniciem com um conjunto básico de dados de referência até que o recurso de armazenamento seja disponibilizado para as atualizações.

Figura 3 - Alta disponibilidade de aplicativo através de nós de computação autônomos

Uma consideração para esse padrão é a velocidade de implantação e inicialização para suas funções. Se você estiver implantando ou baixando grandes volumes de dados de referência na inicialização, isso poderá aumentar a quantidade de tempo necessário para ativar novas implantações ou instâncias da função. Isso pode ser uma compensação aceitável para a autonomia de ter dados de referência imediatamente disponíveis em cada função, em vez de depender de serviços externos de armazenamento.

Os dados transacionais são os dados gerados pelo aplicativo em um contexto de negócios. Os dados transacionais são uma combinação do conjunto de processos de negócios implementados pelo aplicativo e pelos dados de referência que dão suporte a esses processos. Exemplos de dados transacionais podem incluir pedidos, avisos prévios de envio, faturas e oportunidades de CRM. Os dados transacionais gerados serão alimentados em sistemas externos para manter um registro ou para processamento adicional.

Lembre-se de que os dados de referência podem mudar nos sistemas que são responsáveis por esses dados. Por esse motivo, os dados transacionais devem salvar o contexto de dados de referência pontuais, a fim de reduzir ao máximo as dependências externas e manter sua consistência semântica. Por exemplo, considere a remoção de um produto do catálogo alguns meses depois que um pedido foi atendido. A prática recomendada é inserir o máximo de contexto dos dados de referência na transação. Isso preserva a semântica associada à transação, mesmo quando os dados de referência são alterados após a captura da transação.

Conforme mencionado anteriormente, as arquiteturas que usam um acoplamento flexível e a comunicação assíncrona se prestam a níveis mais altos de disponibilidade. Isso também se aplica a dados transacionais, mas a implementação é mais complexa. As noções tradicionais de transacional costumam se basear no banco de dados para garantir a transação. Quando você apresenta as camadas intermediárias, o código do aplicativo deve tratar corretamente os dados em várias camadas para garantir consistência e durabilidade suficientes.

A seguinte sequência descreve um fluxo de trabalho que separa a captura de dados transacionais de seu processamento:

  1. Nó de computação na Web: Dados de referência apresentados.

  2. Armazenamento externo: Salvar dados transacionais intermediários.

  3. Nó de computação na Web: Completar as transações do usuário final.

  4. Nó de computação na Web: Enviar os dados transacionais concluídos junto com o contexto de dados de referência para um armazenamento durável temporário que com garantia oferece a resposta previsível.

  5. Nó de computação na Web: Indicar ao usuário final a conclusão da transação.

  6. Nó de computação em segundo plano: Extrai os dados transacionais, efetua um pós-processamento, se necessário, e envia os dados para o local de descanso final no sistema atual.

O diagrama a seguir mostra uma possível implementação desse projeto em um serviço de nuvem do Azure.

Figura 4 - Alta disponibilidade do aplicativo através de acoplamento flexível

As setas tracejadas no diagrama anterior indicam o processamento assíncrono. A função front-end da Web não está ciente deste processamento assíncrono. Isso resulta no armazenamento da transação em seu destino final com referência ao sistema atual. Devido à latência apresentada neste modelo assíncrono, os dados transacionais não estão imediatamente disponíveis para consulta. Portanto, cada unidade de dados transacionais precisa ser salva em um cache ou sessão de usuário para atender às necessidades imediatas de interface do usuário.

Como consequência, a função Web é autônoma do restante da infraestrutura. O perfil de disponibilidade é uma combinação de função Web e a fila do Azure, e não a infraestrutura inteira. Além de alta disponibilidade, essa abordagem permite que a função Web seja dimensionada horizontalmente, independentemente do modo de armazenamento back-end. Esse modelo de alta disponibilidade pode ter um impacto sobre a economia das operações. Em componentes adicionais como filas do Azure e funções de trabalho podem afetar despesas mensais com uso.

Observe que o diagrama anterior mostra uma implementação dessa abordagem desacoplado para dados transacionais. Há muitas outras implementações possíveis. A lista a seguir fornece algumas variações alternativas.

  • Uma função de trabalho deve ser colocada entre a função Web e a fila de armazenamento.

  • Uma fila do Service Bus pode ser usada em vez de uma fila de Armazenamento do Azure.

  • O destino final pode ser o Armazenamento do Azure ou outro provedor do banco de dados.

  • O armazenamento em cache do Azure pode ser usado na camada da Web para fornecer os requisitos imediatos de cache após a transação.

Além dos padrões abordados nesta seção, é importante observar que a escalabilidade do serviço de nuvem afeta diretamente a disponibilidade. Se a carga maior faz com que o serviço não responda, o usuário tem a impressão de que o aplicativo está inativo. Siga as práticas recomendadas para escalabilidade com base na carga esperada de aplicativo e em futuras expectativas. A escala mais alta envolve várias considerações, como o uso de valor único em comparação às várias contas de armazenamento, a fragmentação em vários bancos de dados e estratégias de armazenamento em cache. Para obter uma discussão profunda sobre esses padrões, consulte Práticas recomendadas para o design de serviços em grande escala em serviços de nuvem do Azure.

Embora a alta disponibilidade trata-se de gerenciamento de falhas temporárias, a recuperação de desastres (DR) se refere à perda catastrófica de funcionalidade do aplicativo. Por exemplo, considere o cenário em que um ou mais datacenters ficam inativos. Nesse caso, você precisa ter um plano para executar o aplicativo ou acessar os dados fora do datacenter. A execução desse plano envolve pessoas, processos e aplicativos de suporte que permitem ao sistema funcionar. O nível de funcionalidade do serviço durante um desastre é determinado pelos proprietários de negócios e de tecnologia que definem o modo operacional do desastre. Isso pode ter várias formas: totalmente indisponível, parcialmente disponível (funcionalidade degradada ou processamento adiado) ou totalmente disponível.

Assim como nas considerações sobre disponibilidade, o Azure tem a Orientação técnica de continuidade de negócios do Azure destinada a dar suporte à recuperação de desastres. Também há uma relação entre alguns dos recursos de disponibilidade do Azure e a recuperação de desastres. Por exemplo, o gerenciamento das funções em domínios de falha aumenta a disponibilidade de um aplicativo. Mas sem esse gerenciamento, uma falha de hardware não tratada pode se transformar em um cenário de “desastre”. Portanto, a aplicação correta de muitos dos recursos e estratégias de disponibilidade deve ser vista como uma parte importante da verificação de desastres no seu aplicativo. No entanto, esta seção vá além de questões gerais de disponibilidade e aborda eventos de desastre mais graves (e mais raros).

O Azure mantém datacenters em muitas regiões diferentes no mundo. Ele suporta vários cenários de recuperação de desastres, como replicação geográfica fornecida pelo sistema do Armazenamento do Azure e datacenters secundários. Também significa que você pode facilmente e com baixo custo implantar um serviço de nuvem em vários locais ao redor do mundo. Compare isso com os custos e a dificuldade em executar seus próprios datacenters em várias regiões. Implantar dados e serviços em vários datacenters protege o aplicativo das interrupções principais em um único datacenter.

Quando ocorrer uma falha específica de datacenter, você deverá redirecionar o tráfego para serviços ou implantações em outro datacenter. Este roteamento pode ser feito manualmente, mas é mais eficiente usar um processo automatizado. O Azure Traffic Manager (WATM) é destinado a essa tarefa. Ele permite gerenciar automaticamente o failover do tráfego de usuário para outro datacenter em caso de falha no datacenter principal. Como o gerenciamento de tráfego é uma parte importante da estratégia geral, é importante compreender os fundamentos de WATM.

No diagrama abaixo, os usuários se conectam a uma URL especificada para WATM (http://myATMURL.trafficmanager.net) que resume as URLs reais de site (http://app1URL.cloudapp.net e http://app2URL.cloudapp.net). Dependendo de como você configura os critérios para quando rotear usuários, eles serão enviados ao site real correto quando a política determinar isso. As opções de política são rodízio, desempenho ou failover. Neste white paper, trataremos somente da opção de failover.

Figura 5 - Roteamento usando o Azure Traffic Manager

Ao configurar WATM, você fornecerá um novo prefixo de DNS do Traffic Manager. Este é o prefixo de URL que você fornecerá aos usuários para acessarem o seu serviço. O WATM então coloca o balanceamento de carga em um nível acima e não mais no nível do datacenter. O DNS do Traffic Manager é mapeado para um CNAME para todas as implantações que ele gerencia.

No WATM, você especifica a prioridade das implantações para as quais os usuários serão roteados quando ocorrer uma falha. O WATM monitora os pontos de extremidade das implantações e observa quando a implantação primária falha. Quando ocorre uma falha, o WATM analisará a lista de implantações com prioridade e roteará usuários para a próxima da lista.

Enquanto o WATM decide onde ir em um failover, você pode decidir se seu domínio de failover fica inativo ou ativo quando NÃO está no modo de failover. Essa funcionalidade não tem relação com o Azure Traffic Manager. O WATM detecta uma falha no site primário e decide substituir pelo site de failover O WATM faz isso independentemente de esse site estar ativamente atendendo usuários ou não no momento. Você encontra mais informações sobre domínios inativos ou ativos de failover em seções posteriores deste documento.

Para obter mais informações sobre como o Azure Traffic Manager funciona, consulte os links a seguir.

As seções a seguir abrangem vários tipos diferentes dos cenários de desastre. A falha do Datacenter não é a única causa de falhas em aplicativos. Um design ruim ou erros de administração também podem resultar em problemas. É importante considerar as possíveis causas de uma falha durante as fases de design e testes do plano de recuperação. Um bom plano aproveita os recursos do Azure e os aperfeiçoa com estratégias específicas do aplicativo. A resposta escolhida é ditada pela importância do aplicativo, pelo RPO e pelo RTO.

Conforme mencionado anteriormente, o Controlador de Malha do Azure controla as falhas resultantes do hardware subjacente ou do software do sistema operacional na máquina virtual do host. O Azure cria uma nova instância da função em um servidor operacional e a adiciona à rotação do balanceador de carga. Se o número de instâncias de função for maior que um, o Azure mudará o processamento para as outras instâncias de função em execução, substituindo o nó com falha.

Há erros graves do aplicativo que ocorrem independentemente de qualquer falha de hardware ou do sistema operacional. O aplicativo pode falhar devido às exceções catastróficas causadas por problemas de lógica incorreta ou de integridade dos dados. Você deve incorporar telemetria suficiente no código para que um sistema de monitoramento possa detectar condições de falha e notificar um administrador do aplicativo. O administrador com total conhecimento dos processos de recuperação de desastres pode tomar uma decisão para chamar um processo de failover. Alternativamente, o administrador poderia simplesmente aceitar uma interrupção de disponibilidade para resolver os erros críticos.

O Azure armazena automaticamente o Banco de dados SQL do Azure e dados de Armazenamento do Azure três vezes de maneira redundante nos diferentes domínios de falha no mesmo datacenter. Se a replicação geográfica for usada, ela será armazenada mais três vezes em um datacenter diferente. No entanto, se os usuários ou seu aplicativo corromperem esses dados na cópia primária, eles serão rapidamente replicados nas outras cópias. Infelizmente, isso resulta em três cópias de dados corrompidos.

Para gerenciar a corrupção em potencial dos dados, você precisa gerenciar seus próprios backups para manter a consistência transacional. Você pode armazenar os backups no Azure ou no local, dependendo dos requisitos do seu negócio ou das normas governamentais. Para obter mais informações, consulte a seção sobre Estratégias de dados para a recuperação de desastres.

Quando partes da rede do Azure estiverem inativas, talvez você não consiga acessar seu aplicativo ou dados. Se uma ou mais instâncias da função não estão disponíveis devido a problemas na rede, o Azure aproveita as instâncias disponíveis restantes de seu aplicativo. Se seu aplicativo não pode acessar os dados devido a uma interrupção da rede do Azure, você pode potencialmente operar em um modo degradado localmente, usando dados armazenados em cache. Você precisa criar a estratégia de recuperação de desastres para execução no modo degradado em seu aplicativo. Para alguns aplicativos, isso pode não ser prático. Outra opção é armazenar dados em um local alternativo até que a conectividade seja restaurada. Se o modo degradado não for uma boa opção, restarão as opções de tempo de inatividade do aplicativo ou o failover para um datacenter alternativo. O design de um aplicativo executado no modo degradado é um decisão comercial e, ao mesmo tempo, técnica. Isso é discutido mais adiante na seção Funcionalidade degradada do aplicativo.

O Azure fornece muitos serviços que podem apresentar tempo de inatividade periódico. Considere o Azure Shared Caching como um exemplo. Esse serviço multilocatário fornece recursos de cache para seu aplicativo. É importante considerar o que acontece em seu aplicativo se o serviço dependente não está disponível. Em muitas maneiras, esse cenário é similar ao cenário de interrupção da rede. Entretanto, considerar cada serviço independentemente resulta em potenciais melhorias no plano geral.

Por exemplo, com o Caching, há uma alternativa relativamente nova ao modelo de Shared Caching multilocatário. O Caching do Azure permite o cache para seu aplicativo a partir da implantação do serviço de nuvem. (Essa também é a recomendação de uso do Caching daqui por diante.) Apesar da limitação de estar acessível somente em uma única implantação, existem benefícios em potencial na recuperação de desastres. Primeiro, o serviço agora é executado em funções que são locais para sua implantação. Portanto, você pode monitorar e gerenciar melhor o status do cache como parte dos processos de gerenciamento em geral do serviço de nuvem. No entanto, esse tipo de armazenamento em cache também apresenta novos recursos. Um dos novos recursos é a alta disponibilidade dos dados armazenados em cache. Isso ajuda a preservar dados armazenados em cache caso um único nó falhe, mantendo cópias duplicadas em outros nós. Observe que a alta disponibilidade diminui a produção e aumenta a latência devido à atualização da cópia secundária em gravações. Ela também dobra a quantidade de memória usada para cada item. Então, esteja preparado. Esse exemplo específico demonstra que cada serviço dependente pode ter os recursos que aumentam a disponibilidade geral e a resistência a falhas catastróficas.

Com cada serviço dependente, você deve compreender as implicações de uma interrupção total. No exemplo de Caching, talvez seja possível acessar os dados diretamente de um banco de dados até que os recursos de cache sejam restaurados. Isso seria um modo degradado em termos de desempenho, mas ofereceria a funcionalidade total em termos de dados.

As falhas anteriores eram basicamente falhas gerenciáveis no mesmo datacenter do Azure. No entanto, você também deve estar preparado para a possibilidade de interrupção do datacenter inteiro. Quando um datacenter é interrompido, as cópias localmente redundantes dos dados ficam indisponíveis. Se você habilitou a replicação geográfica, há três cópias adicionais de seus blobs e tabelas em um datacenter em uma região diferente. Quando a Microsoft declara a perda do datacenter, o Azure mapea novamente todas as entradas de DNS para o datacenter replicado geograficamente. Observe que você não tem controle sobre esse processo, e ele ocorrerá apenas para falhas do datacenter. Por isso, você também deve contar com outras estratégias de backup específicas do aplicativo para obter o nível mais alto de disponibilidade. Para obter mais informações, consulte a seção sobre Estratégias de dados para a recuperação de desastres.

No planejamento de desastre, você deve considerar o intervalo inteiro de possíveis desastres. Uma das interrupções mais graves envolveria todos os datacenters do Azure simultaneamente. Assim como em outras interrupções, você pode decidir que correrá o risco de enfrentar um tempo de inatividade temporário nesse evento. As falhas distribuídas que abrangem datacenters devem ser bem mais raras do que falhas isoladas que envolvem serviços dependentes ou datacenters únicos. No entanto, para alguns aplicativos essenciais, você pode decidir que também deve existir um plano de backup para este cenário. O plano para esse evento poderia incluir failover para serviços em um Nuvens alternativas ou um Soluções híbridas no local e de nuvem.

Um aplicativo bem projetado geralmente usa uma coleção de módulos que se comunicam entre si, embora a implementação de padrões acoplados de forma flexível troque informações. Um aplicativo DR amigável particularmente requer a separação de tarefas no nível de módulo. Isso ocorre para prevenir uma interrupção de um serviço dependente que interrompa o aplicativo inteiro. Por exemplo, considere um aplicativo de comércio da Web para a empresa Y; os seguintes módulos podem constituir o aplicativo:

  • Catálogo de produtos: permite que os usuários procurem produtos

  • Carrinho de compras: permite aos usuários adicionar/remover produtos no carrinho de compras

  • Status do pedido: mostra o status de envio de pedidos do usuário

  • Submissão de pedido: finalização da sessão de compras enviando o pedido com o pagamento

  • Processamento de pedido: valida o pedido para integridade de dados e executa a verificação da disponibilidade da quantidade

Quando um dependente de um módulo neste aplicativo é interrompido, como o módulo funciona até que essa parte seja recuperada? Um sistema bem projetado implementa limites de isolamento através da separação de tarefas em tempo de design e em tempo de execução. Você pode categorizar cada falha como recuperável e não recuperável. Os erros não recuperáveis desativaram o módulo, enquanto um erro recuperável pode ser mitigado com alternativas. Como discutido na seção de alta disponibilidade, você pode ocular alguns problemas dos usuários tratando falhas e adotando ações alternativas. Durante uma interrupção mais grave, o aplicativo pode ficar completamente indisponível. No entanto, uma terceira opção é continuar atendendo os usuários no modo degradado.

Por exemplo, se o banco de dados para hospedar pedidos ficar inativo, o módulo de processamento de pedidos perderá sua capacidade de processar transações de vendas. Dependendo da arquitetura, pode ser difícil ou impossível prosseguir com as partes do aplicativo Envio do pedido e Processamento do pedido. Se o aplicativo não se adequar a esse cenário, o aplicativo inteiro poderá ficar offline.

Porém, nesse mesmo cenário, é possível que os dados do produto estejam armazenados em um local diferente. Nesse caso, o módulo Catálogo de produto ainda poderá ser usado para exibir produtos. No modo degradado, o aplicativo continua disponível aos usuários para a funcionalidade disponível, como exibir o catálogo de produtos. Outras partes do aplicativo estão indisponíveis, porém, como a ordenação ou consultas ao estoque.

Outra variação do modo degradado se concentra no desempenho, e não em recursos. Por exemplo, considere um cenário onde o catálogo de produtos está sendo armazenado em cache com o Caching do Azure. Se o Caching se tornou indisponível, é possível que o aplicativo vá diretamente para o armazenamento do servidor para recuperar informações do catálogo de produtos. Mas esse acesso pode ser mais lento do que a versão em cache. Por isso, o desempenho do aplicativo estará degradado até que o serviço de Caching seja totalmente restaurado.

Decidir quanto de um aplicativo continuará funcionando em modo degradado é tanto uma decisão de negócios como uma decisão técnica. O aplicativo também deve decidir como informar aos usuários sobre os problemas temporários. Neste exemplo, o aplicativo pode permitir exibir produtos e até mesmo adicioná-los a um carrinho de compras. Entretanto, quando o usuário tenta fazer uma compra, o aplicativo notifica-o de que o módulo de vendas está desativado temporariamente. Não é o ideal para o cliente, mas isso impede uma interrupção do aplicativo inteiro.

Tratar dados corretamente é a área mais difícil de acertar em qualquer plano de recuperação de desastres. Restaurar dados também faz parte do processo de recuperação que costuma ocupar a maior parte do tempo. Opções diferentes nos modos de degradação resultam em desafios difíceis para a recuperação de dados após uma falha e a consistência depois da falha. Um dos fatores é a necessidade de restaurar ou manter uma copia dos dados do aplicativo. Você usará esses dados por motivos de referência e transacionais num site secundário. Uma configuração no local necessita de um processo de planejamento caro e longo para implementar uma estratégia de DR em vários datacenters. Para conveniência dos usuários, a maioria dos provedores na nuvem, inclusive o Azure, permitem prontamente a implantação de aplicativos em vários datacenters. Esses datacenters estão localizados geograficamente de modo que as interrupções de vários datacenters devam ser muito raras. A estratégia para tratar dados em datacenters é um dos fatores que contribuem para o êxito de qualquer plano de recuperação de desastres.

As seções a seguir discutem as técnicas de recuperação de desastres relacionadas a backups de dados, a dados de referência e a dados transacionais.

Backups regulares dos dados do aplicativo podem dar suporte a alguns cenários de recuperação de desastres. Recursos de armazenamento distintos exigem técnicas diferentes.

Para o Banco de dados SQL do Azure, você pode usar o comando DATABASE COPY para criar uma cópia do banco de dados. Você deve usar esse comando para obter um backup com consistência transacional. Você também pode aproveitar o serviço de importação/exportação do Banco de dados SQL do Azure. Isso oferece suporte à exportação de bancos de dados para arquivos BACPAC que são armazenados no armazenamento de blob do Azure. A redundância interna do Armazenamento do Azure cria duas réplicas do arquivo de backup no mesmo datacenter. No entanto, a frequência da execução do processo de backup determina o RPO, que é o volume de dados que você pode perder em cenários de desastre. Por exemplo, se você executar um backup na hora marcada e ocorrer um desastre dois minutos antes da hora marcada. Você perderá 58 minutos de dados que aconteceram depois que o último backup foi executado. Além disso, como proteção contra uma interrupção do datacenter, você deve copiar os arquivos BACPAC em um datacenter alternativo. Você tem a opção de restaurar esses backups no datacenter alternativo. Para obter mais detalhes, consulte Continuidade dos negócios no Banco de dados SQL do Azure.

Para o Armazenamento do Azure, você pode desenvolver seu próprio processo de backup personalizado ou usar uma das diversas ferramentas de backup de terceiros. Observe que há complexidades adicionais na maioria dos designs do aplicativo onde recursos de armazenamento referenciam uns aos outros. Por exemplo, considere um Banco de dados SQL que tem uma coluna que se vincula a um blob no Armazenamento do Azure. Se os backups não acontecem simultaneamente, o banco de dados pode ter o ponteiro para um blob do qual não foi feito backup antes da falha. O aplicativo ou o plano de recuperação de desastres deve implementar processos para tratar essa inconsistência após uma recuperação.

Conforme mencionado anteriormente, os dados de referência são dados somente leitura que dão suporte à funcionalidade do aplicativo. Eles não costumam ser alterados com frequência. Embora o backup e a restauração sejam um método para controlar interrupções do datacenter, o RTO é relativamente longo. Quando o aplicativo for implantado em um datacenter secundário, algumas estratégias poderão melhorar o RTO para dados de referência.

Como os dados de referência raramente são alterados, você pode melhorar o RTO para manter uma cópia permanente dos dados de referência no datacenter secundário. Isso elimina o tempo necessário para restaurar backups no caso de um desastre. Para atender aos requisitos de DR em vários datacenters, você deve implantar o aplicativo e os dados de referência juntos em vários datacenters. Como foi mencionado em Padrão dos dados de referência (alta disponibilidade), você pode implantar os dados de referência na própria função, no armazenamento externo ou em uma combinação de ambos. O modelo interno de implantação de dados de referência do nó de computação implicitamente atende aos requisitos de DR. A implantação de dados de referência no Banco de dados SQL requer que você implante uma cópia dos dados de referência em cada datacenter. A mesma estratégia se aplica ao Armazenamento do Azure. Você deve implantar uma copia de qualquer dado de referência armazenado no Armazenamento do Azure aos datacenters primário e secundário.

Figura 6 - Publicação de dados de referência em datacenters primário e secundário

Conforme mencionado anteriormente, você deve implementar suas próprias rotinas de backup específicas do aplicativo para todos os dados, incluindo dados de referência. As cópias replicadas geograficamente em datacenters são usadas somente em uma interrupção em datacenters. Para evitar o tempo de inatividade estendido, implante as partes essenciais de dados do aplicativo no datacenter secundário. Para obter um exemplo dessa topologia, consulte o modelo Ativo/Passivo.

A implementação de uma estratégia no modo de desastre totalmente funcional exige a replicação assíncrona dos dados transacionais para o datacenter secundário. As janelas de tempo práticas em que a replicação pode ocorrer determinam as características de RPO do aplicativo. Você ainda pode recuperar os dados perdidos do datacenter primário durante a janela de replicação. Você também será capaz de mesclar com o datacenter secundário depois.

Os exemplos a seguir da arquitetura fornecem algumas ideias sobre diferentes maneiras de tratar dados transacionais em um cenário de failover. É importante observar que esses exemplos não são exaustivos. Por exemplo, os locais de armazenamento intermediários, como filas, podem ser substituídos pelo Banco de dados SQL do Azure. As próprias filas podem ser filas do Armazenamento do Azure ou do Service Bus (consulte Filas do Azure e filas do Azure Service Bus - semelhanças e diferenças). Os destinos de armazenamento do servidor também podem variar, como tabelas do Azure em vez do Banco de dados SQL. Além disso, pode haver funções de trabalho que são inseridas como intermediários em várias etapas. O importante não é emular exatamente essas arquiteturas, mas considerar várias alternativas na recuperação de dados transacionais e módulos relacionados.

Considere um aplicativo que usa filas de Armazenamento do Azure para manter dados transacionais. Isso permite que as funções de trabalho processem os dados transacionais para o banco de dados do servidor em uma arquitetura desacoplada. Conforme já discutido, isso exige que transações usem alguma forma de cache temporário se as funções front-end exigem a consulta imediata desses dados. Dependendo do nível de tolerância da perda de dados, você pode optar por replicar as filas, o banco de dados ou todos os recursos de armazenamento. Apenas com a replicação de banco de dados, se o datacenter primário ficar inativo, você ainda poderá recuperar os dados nas filas quando o datacenter primário voltar a funcionar. O diagrama a seguir mostra uma arquitetura em que o banco de dados do servidor é sincronizado com datacenters.

Figura 7 - Replicar dados transacionais em preparação para DR

O maior desafio para implementar a arquitetura anterior é a estratégia de replicação entre datacenters. O Azure fornece um serviço de Sincronização de Dados do SQL para esse tipo de replicação. No entanto, o serviço ainda está em visualização e não é recomendado para ambientes de produção. Para obter mais informações, consulte Continuidade dos negócios no Banco de dados SQL do Azure. Para aplicativos de produção, você deve investir em uma solução de terceiros ou criar sua própria lógica de replicação no código. Dependendo da arquitetura, a replicação deve ser bidirecional, que também é mais complexa. Uma implementação potencial pode utilizar a fila intermediária no exemplo anterior. A função de trabalho que processa os dados no destino final de armazenamento pode fazer a alteração em datacenters primários e secundários. Essas tarefas não são triviais, e a orientação completa para o código de replicação está além do escopo deste documento. O ponto importante é que grande parte do tempo e dos testes devem focar como você replica os dados no datacenter secundário. O processamento e os testes adicionais devem ser realizados para garantir que os processos de failover e de recuperação tratem corretamente todas as possíveis inconsistências de dados ou transações duplicadas.

noteObservação
A maior parte deste documento tem como foco a plataforma como um serviço. No entanto, há opções adicionais de replicação e disponibilidade para aplicativos híbridos que usam Máquinas Virtuais do Azure. Esses aplicativos híbridos usam a IaaS (infraestrutura como um serviço) para hospedar o SQL Server em máquinas virtuais no Azure. Isso habilita abordagens tradicionais de disponibilidade no SQL Server, como grupos de disponibilidade AlwaysOn ou envio de logs. Algumas técnicas, como AlwaysOn, só funcionam em SQL Servers no local e em 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.

Considere uma segunda arquitetura que opera em modo degradado. O aplicativo no datacenter secundário desabilita toda a funcionalidade, como o relatório, o BI ou as filas de drenagem. Ele aceita apenas os tipos mais importantes de fluxos de trabalho transacionais, conforme definido por requisitos dos negócios. O sistema captura as transações e as grava nas filas. O sistema pode adiar o processamento de dados durante a fase inicial da interrupção. Se o sistema do datacenter primário for reativado na janela de tempo esperada, a função de trabalho no datacenter primário poderá drenar as filas. Este processo elimina a necessidade de mesclar o banco de dados. Se a interrupção do datacenter primário vá além da janela tolerável, o aplicativo pode iniciar o processamento das filas. Neste cenário, o banco de dados no datacenter secundário contém dados transacionais que devem ser mesclados após a reativação do datacenter primário. O diagrama a seguir mostra essa estratégia para armazenar temporariamente dados transacionais até que o datacenter primário seja restaurado.

Figura 8 - Modo de aplicação degradado somente para captura de transação

Para obter mais detalhes das técnicas de gerenciamento de dados para aplicativos resilientes do Azure, consulte À prova de falhas: orientação para arquiteturas resilientes na nuvem

Preparar aplicativos essenciais para a eventualidade do datacenter inteiro ficar inativo. Você faz isso incorporando uma estratégia de implantação de diversos datacenters no planejamento operacional. Implantações de vários datacenters podem envolver processos de profissional de TI para publicar dados do aplicativo e de referência no datacenter secundário depois de enfrentar um desastre. Se o aplicativo exigir o failover imediato, o processo de implantação talvez envolva uma configuração ativa/passiva ou ativa/ativa. Este tipo de implantação tem instâncias existentes do aplicativo executadas no datacenter alternativo. Conforme discutido, uma ferramenta de roteamento como o Azure Traffic Manager fornece serviços de balanceamento de carga no nível de DNS. Ela pode detectar problemas e rotear os usuários para datacenters diferentes, quando necessário.

Parte de uma recuperação de desastres com êxito do Azure é planejar essa recuperação na solução desde o inicio. A nuvem fornece opções adicionais para recuperação de falhas durante um desastre, que não estão disponíveis em um provedor de hospedagem tradicional. Especificamente, você pode de forma dinâmica e rápida alocar recursos a um datacenter diferente. Portanto, você não pagará muito por recursos inativos enquanto aguardar uma falha ocorrer.

As seções a seguir descrevem as diferentes topologias de implantação para a recuperação de desastres. Normalmente, existe uma compensação no aumento de custo ou complexidade para a disponibilidade adicional.

Uma implantação de região única não é realmente uma topologia de recuperação de desastres, mas visa contrastar as outras arquiteturas. Implantações de região única são comuns para aplicativos no Azure. Contudo, não se trata de um competidor serio para um plano de recuperação de desastres. O diagrama a seguir descreve um aplicativo executado em um único datacenter do Azure. Conforme descrito anteriormente, o Controlador de Malha do Azure, e o uso dos domínios de falha e de atualização, aumentam a disponibilidade do aplicativo no datacenter.

Figura 9 - Implantação de região única

Aqui fica aparente que o banco de dados é um ponto de falha único. Embora o Azure replique os dados nos diferentes domínios de falha em réplicas internas, isso tudo ocorre no mesmo datacenter. Ele não pode tolerar uma falha catastrófica. Se o datacenter ficar inativo, todos os domínios de falha ficarão inativos, inclusive todas as instâncias de serviço e recursos de armazenamento.

Para todos os aplicativos, exceto os menos críticos, você deve criar um plano para implantar o seu aplicativo em vários datacenters em regiões diferentes. Você também deve considerar o RTO e as restrições de custo ao escolher a topologia de implantação a ser usada.

Vamos verificar agora um padrões específicos para dar suporte ao failover em datacenters diferentes. Esses exemplos usam dois datacenters para descrever o processo.

Neste padrão, apenas o datacenter primário tem aplicativos e bancos de dados em execução. O datacenter secundário não está configurado para um failover automático. Então, quando ocorrer um desastre, você deverá reunir todas as partes do serviço no novo datacenter. Isso inclui carregar um serviço de nuvem no Azure, implantar os serviços de nuvem, restaurar os dados e modificar o DNS para redistribuir o tráfego.

Quando esta é a opção mais acessível entre as regiões, ela tem as piores características de RTO. Neste modelo, o pacote de serviço e os backups de banco de dados são armazenados no local ou no armazenamento de blob no datacenter secundário. No entanto, você deve implantar um novo serviço e restaurar os dados antes de retomar a operação. Ainda se você automatiza completamente a transferência de dados do armazenamento de backup, ativar ou desativar o novo ambiente de banco de dados consume bastante tempo. A parte mais cara da restauração é mover dados do armazenamento de disco de backup para o banco de dados vazio no datacenter secundário. No entanto, você deve fazer isto, para colocar o novo banco de dados em um estado operacional pois ele não é replicado.

A melhor abordagem é armazenar os pacotes de serviço do armazenamento de blob do Azure no datacenter secundário. Isso elimina a necessidade de carregar o pacote no Azure. É isso que ocorre quando você implanta de um computador de desenvolvimento no local. Você pode rapidamente implementar os pacotes de serviço em um novo serviço de nuvem de armazenamento blob usando scripts do PowerShell.

Esta opção só é prática para aplicativos não críticos que possam tolerar um RTO alto. Por exemplo, isso pode funcionar para um aplicativo que fique inativo por várias horas, mas que volte a operar dentro de 24 horas.

Figura 10 - Reimplantar em um datacenter secundário do Azure

O padrão Ativo/Passivo é a opção preferida por muitas empresas. Este padrão fornece melhorias ao RTO com um aumento relativamente pequeno em custos em relação ao padrão de reimplantação. Neste cenário, há novamente um datacenter primário e secundário do Azure. Todo o tráfego vai para a implantação ativa no datacenter primário. O datacenter secundário está melhor preparado para a recuperação de desastres, pois o banco de dados está em execução em ambos os datacenters. Adicionalmente, há um mecanismo de sincronização colocado entre eles. Esta abordagem de espera pode envolver duas variações: uma abordagem apenas de banco de dados ou uma implantação completa no datacenter secundário.

Na primeira variação do padrão ativo/passivo, somente o datacenter primário tem um aplicativo de serviço de nuvem implantado. No entanto, ao contrário do padrão de reimplantação, ambos os datacenters são sincronizados com o conteúdo do banco de dados (consulte a seção sobre Padrão dos dados transacionais (recuperação de desastre)). Quando ocorre um desastre, há menos requisitos de ativação. Você inicia o aplicativo no datacenter secundário, altera as cadeias de conexão para o novo banco de dados e altera as entradas de DNS para redirecionar o tráfego.

Como o padrão de reimplantação, você já deve ter os pacotes de serviço armazenados no armazenamento blob do Azure no datacenter secundário para agilizar a implantação. Diferente do padrão de reimplantação, não imponha a maioria da sobrecarga que é exigida pelas operações de restauração de banco de dados. O banco de dados está pronto e em execução. Isso economiza um tempo significativo, tornando esse padrão de DR acessível e, consequentemente, o mais popular.

Figura 11 - Ativo/Passivo (somente banco de dados)

Na segunda variação do padrão ativo/passivo, os datacenters primário e secundário têm uma implantação completa. Esta implementação inclui os serviços de nuvem e um banco de dados sincronizado. Entretanto, somente o datacenter primário está tratando ativamente solicitações de rede dos usuários. O datacenter secundário se tornará ativo somente quando o datacenter primário ficar inativo. Nesse caso, todas as novas solicitações de rede serão roteadas para a região secundária. O Azure Traffic Manager pode gerenciar esse failover automaticamente.

O failover ocorre mais rápido do que a variação apenas de banco de dados, pois os serviços já foram implantados. Esse padrão fornece um RTO muito baixo; o datacenter secundário de failover deve estar pronto para assumir imediatamente após a falha do datacenter primário.

Junto com uma resposta mais rápida, esse padrão também tem uma vantagem adicional de pré-alocar e implantar serviços de backup. Você não precisa se preocupar com o fato de um datacenter não ter espaço para alocar novas instâncias em um desastre. Isso é importante se o datacenter secundário do Azure está atingindo o limite de capacidade. Não há garantia (SLA) de que você possa imediatamente implantar um número de novos serviços de nuvem em qualquer datacenter.

Para obter o menor tempo de resposta com esse modelo, você deve ter uma escala similar (número de instâncias de função) nos datacenters, primário e secundário. Apesar das vantagens, pagar por instâncias de computação não usadas é caro e essa não costuma ser a opção financeira mais aconselhável. Por isso, é mais comum usar uma versão um pouco reduzida dos serviços de nuvem no datacenter secundário. É possível rapidamente fazer um failover e redimensionar a implantação secundária quando necessário. Você automatizaria o processo de failover de forma que, após o reconhecimento da falha do datacenter primário, incluiria instâncias adicionais dependendo da carga. Isso pode envolver um tipo de mecanismo de escalonamento automático, como a Pré-visualização de Autoescala ou o Bloco de aplicativos de dimensionamento automático. O diagrama a seguir mostra o modelo onde os datacenters primário e secundário contêm um serviço de nuvem totalmente implantado em um padrão ativo/passivo.

Figura 12 - Ativo/Passivo (réplica completa)

Agora provavelmente você está imaginando a evolução dos padrões – a redução no RTO leva ao aumento de custos e de complexidade. A solução ativo/ativo de fato interrompe essa tendência em relação ao custo. Em um padrão ativo/ativo, os serviços de nuvem e o banco de dados são totalmente implantados em ambos os datacenters. Diferente do modelo ativo/passivo, ambos os datacenters recebem tráfego do usuário. Esta opção gera o tempo de recuperação mais rápido. Os serviços já estão dimensionados para tratar de uma parte da carga em cada datacenter. O DNS já está habilitado para usar o datacenter secundário. Há uma complexidade adicional em determinar como rotear usuários para o datacenter apropriado. O agendamento em rodízio pode ser possível. É mais provável que determinados usuários usem um datacenter específico onde resida a cópia primária dos dados.

Em caso de failover, basta desabilitar o DNS para o datacenter primário, roteando todo o tráfego para o datacenter secundário. Mesmo neste modelo, há algumas variações. Por exemplo, o diagrama a seguir mostra um modelo onde o datacenter primário é proprietário da cópia mestre do banco de dados. Os serviços de nuvem em ambos os datacenters gravam no banco de dados primário. A implantação secundária pode ler do banco de dados primário ou replicado. A replicação neste exemplo ocorre de uma maneira.

Figura 13 - Ativo/Ativo

Há uma desvantagem na arquitetura ativo/ativo no diagrama anterior. O segundo datacenter deve acessar o banco de dados no primeiro datacenter, pois a cópia mestre reside ali. O desempenho cai significativamente quando você acessa dados fora de um datacenter. Em chamadas do banco de dados em datacenters, você deve considerar um tipo de estratégia de envio em lote para melhorar o desempenho dessas chamadas. Para obter mais informações, consulte Técnicas de envio em lote para aplicativos do Banco de dados SQL no Azure. Uma arquitetura alternativa pode envolver cada datacenter acessando diretamente o próprio banco de dados dele. Nesse modelo, um tipo de replicação bidirecional seria necessário para sincronizar os bancos de dados em cada datacenter.

No padrão Ativo/Ativo, você pode não precisar de tantas instâncias no datacenter primário quanto exigiria o padrão Ativo/Passivo. Se você tem dez instâncias no datacenter primário em uma arquitetura ativo/passivo, talvez seja necessário apenas cinco em cada datacenter na arquitetura ativo/ativo. As duas regiões agora compartilham a carga. Isso pode ser econômico em relação ao padrão ativo/passivo se você manteve uma espera passiva no datacenter passivo com dez instâncias aguardando o failover.

Note que, até que você restaure o datacenter primário, o datacenter secundário poderá receber um aumento repentino de novos usuários. Se existissem 10.000 usuários em cada servidor no momento em que o datacenter primário falhasse, o datacenter secundário precisaria subitamente tratar 20.000 usuários. Regras de monitoramento no datacenter secundário devem detectar esse aumento e dobrar as instâncias no datacenter secundário. Para obter mais informações sobre isso, consulte a seção sobre Detecção de falha.

Uma estratégia adicional para a recuperação de desastres é criar um aplicativo híbrido que seja executado no local e na nuvem. Dependendo do aplicativo, o datacenter primário pode ser um dos locais. Considere as arquiteturas anteriores e imagine o datacenter primário ou secundário como um ponto no local.

Há alguns desafios nas arquiteturas híbridas. Primeiro, a maior parte deste documento referencia a plataforma como um padrão de arquitetura de serviço (PaaS). Os aplicativos típicos de PaaS no Azure dependem de construções específicas do Azure, como funções, serviços de nuvem e o Controlador de Malha. Para criar uma solução no local para esse tipo de aplicativo PaaS, seria necessária uma arquitetura significativamente diferente. Isso pode não ser executável de uma perspectiva de gerenciamento ou de custo.

No entanto, uma solução híbrida para a recuperação de desastres tem menos desafios para as arquiteturas tradicionais que foram simplesmente movidas para a nuvem. Isso vale para arquiteturas que usam IaaS (Infraestrutura como um Serviço). Os aplicativos IaaS usam máquinas virtuais na nuvem que podem ter equivalentes diretos no local. O uso de redes virtuais também o habilita a conectar computadores na nuvem com recursos de rede no local. Isso abre várias possibilidades que não são possíveis com aplicativos somente PaaS. Por exemplo, o SQL Server pode aproveitar soluções de recuperação de desastres, como os grupos de disponibilidade AlwaysOn e o espelhamento do banco de dados. Para obter detalhes, consulte Alta disponibilidade e recuperação de desastres para o SQL Server em Máquinas Virtuais do Azure.

Soluções IaaS também oferecem um caminho mais fácil para aplicativos no local usarem o Azure como a opção de failover. Você pode ter um aplicativo totalmente operacional em um datacenter local existente. No entanto, e se faltarem recursos para manter um datacenter separado geograficamente para failover? Talvez você decida usar máquinas virtuais e redes virtuais para que seu aplicativo seja executado no Azure. Defina processos que sincronizem dados para a nuvem. A implantação do Azure se torna o datacenter secundário para uso em failover. O datacenter primário permanece o aplicativo no local. Para obter mais informações sobre arquiteturas e recursos de IaaS, consulte Máquinas Virtuais e Redes Virtuais.

Essas são situações em que até mesmo a potente nuvem da Microsoft talvez não seja suficiente para atender aos requisitos de disponibilidade. Nos últimos anos, houve graves interrupções de várias plataformas de nuvem. Isso inclui AWS (Amazon Web Services) e as plataformas do Azure. Até mesmo a melhor preparação e design para implementar sistemas de backup durante um desastre não bastam porque a nuvem inteira exige um dia inteiro.

Você irá comparar requisitos de disponibilidade com o custo e a complexidade da maior disponibilidade. Realizar um análises de risco e definir RTO e RPO para a sua solução. Se o seu aplicativo não pode tolerar tempo de inatividade, talvez faça sentido para você usar outra solução de nuvem. A menos que a Internet inteira fique inativa simultaneamente, outra solução de nuvem, como o Rackspace ou o Amazon Web Services ainda funcionarão no eventual caso de o Azure estar totalmente inoperante.

Assim como no cenário híbrido, as implantações de failover nas arquiteturas de DR anteriores também podem existir em outra solução de nuvem. Locais de DR de nuvem alternativos só devem ser usados para as soluções com um RTO que permitam um tempo mínimo de inatividade, ou nenhum. Observe que uma solução que usa um local de DR fora do Azure será mais trabalhosa para configurar, desenvolver, implantar e manter. Também é mais difícil implementar as práticas recomendadas em arquiteturas de nuvem. Embora plataformas de nuvem tenham conceitos semelhantes de alto nível, as APIs e arquiteturas são diferentes. Se você decidir dividir seu DR entre diferentes plataformas, fará sentido criar camadas de abstração no design da solução. Se você fizer isso, não precisará desenvolver e manter duas versões diferentes do mesmo aplicativo para diferentes plataformas de nuvem em caso de desastre. Assim como no cenário híbrido, o uso de máquinas virtuais pode ser mais fácil nesses casos do que em designs PaaS específicos de nuvem.

Alguns dos padrões que acabamos de discutir exigem a ativação rápida de implantações offline, bem como a restauração de partes específicas de um sistema. A automação, ou scripting, dá suporte à capacidade de ativar recursos sob demanda e implantar soluções rapidamente. Neste documento, a automação relativa ao DR equivale a PowerShell do Azure, mas a Referência da API REST do Gerenciamento de Serviços também é uma opção. O desenvolvimento de scripts ajuda a gerenciar as partes do DR que o Azure parece não tratar. Isso tem a vantagem de gerar resultados consistentes a cada vez, minimizando a chance de erro humano. A existência de scripts DR predefinidos também reduz o tempo de recriação de um sistema e de suas partes constituintes em meio a um desastre. Você não deseja tentar descobrir manualmente como restaurar seu site enquanto ele está inativo, correndo o risco de perder dinheiro a cada minuto.

Depois que você criar os scripts, teste-os diversas vezes do início ao fim. Depois que você verificar sua funcionalidade básica, assegure-se de testá-los em Simulação de desastre. Isso ajuda a revelar defeitos nos scripts ou processos.

Uma prática recomendada na automação é criar um repositório de scripts PowerShell DR do Azure. faça marcações neles e os categorize com clareza para facilitar a pesquisa. Designe uma pessoa para gerenciar o repositório e criar versões dos scripts. Documente-os bem com explicações de parâmetros e exemplos de uso de script. Também se certifique de manter esta documentação em sincronização com as implantações do Azure. Isso revela o propósito de ter uma pessoa responsável por todas as partes do repositório.

Para tratar problemas de maneira correta com disponibilidade e recuperação de desastres, você precisa ser capaz de detectar e diagnosticar falhas. Faça um monitoramento avançado de servidor e de implantação para saber rapidamente quando um sistema e suas partes ficam de repente inativos. As ferramentas de monitoramento que observam o estado geral do Serviço de nuvem em suas dependências podem fazer parte desse trabalho. Duas ferramentas da Microsoft são MetricsHub e System Center 2012 R2 (SCOM). Outras ferramentas de terceiros, como o AzureWatch, também podem oferecer a capacidade de monitoramento. O AzureWatch também permite que você automatize a escalabilidade. A maioria das soluções de monitoramento controlam contadores de desempenho principal e a disponibilidade do serviço.

Embora essas ferramentas sejam vitais, elas não dispensam a necessidade de planejamento para detecção de falhas e relatórios em um serviço de nuvem. Procure se planejar para usar adequadamente o diagnóstico do Azure. Os contadores personalizados de desempenho ou as entradas de log de eventos também podem fazer parte da estratégia geral. Isso fornece mais dados durantes falhas para diagnosticar rapidamente o problema e restaurar a capacidade total. Ele também oferece métrica adicional para as ferramentas de monitoramento determinarem a integridade do aplicativo. Para obter mais informações, consulte Coletar dados de log usando o Diagnóstico do Azure. Para obter uma discussão sobre como planejar um “modelo de integridade” geral, consulte À prova de falhas: orientação para arquiteturas resilientes na nuvem

Os testes de simulação envolvem a criação de situações simples da vida real no local de trabalho para observar como os membros da equipe reagem. As simulações também mostram a eficácia das soluções no plano de recuperação. As simulações devem ser realizadas de forma que os cenários criados não afetem os negócios existentes e, ao mesmo tempo, ainda pareçam situações “reais”.

Procure criar um tipo de “central” no aplicativo para simular manualmente problemas de disponibilidade. Por exemplo, através de um dispositivo, dispare exceções de acesso ao banco de dados para um módulo de pedidos, levando a um defeito. Abordagem de peso semelhante podem ser adotadas para outros módulos no nível de interface da rede.

Quaisquer problemas que tenham sido tratados de forma inadequada serão destacados durante a simulação. Os cenários simulados devem ser completamente controláveis. Isto quer dizer que, mesmo se o plano de recuperação parecer estar falhando, a situação pode voltar ao normal sem danos significativos. Também é importante que você informe ao gerenciamento em nível superior sobre quando e onde os exercícios de simulação serão executados. Esse plano inclui informações sobre o tempo ou recursos que podem se tornar improdutivos durante a execução do teste de simulação. Ao submeter um plano de recuperação de desastres a um teste, também é importante definir como o êxito será medido.

Há diversas outras técnicas que podem ser usadas para testar planos de recuperação de desastres. Mas, a maioria deles são simplesmente versões alteradas dessas técnicas básicas. O principal motivo para empregar estes testes é avaliar a viabilidade e a utilidade do plano de recuperação. Os testes de recuperação de desastres focam os detalhes para descobrir furos no plano básico de recuperação.

Vamos resumir os pontos-chaves que foram abordados neste documento. O resumo atuará como uma lista de verificação de itens a serem considerados no seu próprio planejamento de disponibilidade e recuperação de desastres. Estas são práticas recomendadas que têm sido úteis para clientes que buscam seriedade na implementação de uma solução bem-sucedida. Este tipo de solução realmente funciona, recuperando de modo oportuno e bem-sucedido quando há falha no sistema.

  1. Conduza uma avaliação de risco para cada aplicativo, pois cada um pode ter diferentes exigências. Alguns aplicativos são mais críticos e justificariam o custo extra para planejá-los para recuperação de desastres.

  2. Use essas informações para definir o RTO e o RPO para cada aplicativo.

  3. Planeje-se contando com falhas, começando pela arquitetura do aplicativo.

  4. Implemente práticas recomendadas para alta disponibilidade, equilibrando custo, complexidade e risco.

  5. Implemente planos e processos de recuperação de desastres.

    1. Considere falhas que abranjam o nível de módulo até uma interrupção total da nuvem.

    2. Estabeleça estratégias de backup para todos os dados de referência e transacionais.

    3. Escolha uma arquitetura de recuperação de desastres em vários sites.

  6. Defina um proprietário específico para processos, automação e testes de recuperação de desastres. O proprietário deve gerenciar e ser proprietário do processo inteiro.

  7. Documente os processos para que sejam repetidos com facilidade. Embora exista um proprietário, várias pessoas precisam ser capazes de compreender e seguir os processos em uma emergência.

  8. Treine a equipe para implementar o processo.

  9. Use regularmente simulações de desastres para treinamento e validação do processo.

Quando há falhas de hardware ou software no Azure, as técnicas e estratégias para gerenciá-las diferem daquelas usadas quando isso ocorre em sistemas no local. O motivo principal para isto é que soluções de nuvem em geral têm mais dependências na infraestrutura que é espalhada pelo datacenter e são gerenciadas como serviços separados. Você deve lidar com falhas parciais usando técnicas de alta disponibilidade. Para gerenciar falhas mais graves, possivelmente devido a um evento de desastre, use estratégias de recuperação de desastres.

O Azure detecta e trata muitas falhas, mas há vários tipos de falhas que exigem estratégias específicas do aplicativo. Você pode preparar-se ativamente e gerenciar as falhas de aplicativos, serviços e dados.

Quando você criar o seu plano de recuperação de desastres e disponibilidade, considere as consequências da falha no aplicativo para os negócios. A definição de processos, políticas e procedimentos para restaurar sistemas críticos após um evento catastrófico é uma tarefa que exige tempo, planejamento e confirmação. E uma vez que você estabeleça os planos, não pode parar. Procure analisar, testar e aperfeiçoar continuamente os planos com base no seu portfólio de aplicativos, nas necessidades dos negócios e nas tecnologias disponíveis. O Azure oferece novos recursos e novos desafios para criar aplicativos avançados resistentes a falhas.

Consulte também

Mostrar:
© 2014 Microsoft