Exportar (0) Imprimir
Expandir Tudo

Orientação técnica de continuidade de negócios do Azure

Atualizado: junho de 2014

Última atualização: Maio de 2014

Publicado originalmente: Março de 2012

Autores: Patrick Wickline, Jason Roth

Revisores & colaboradores: Luis Carlos Vargas Herring, Drew McDaniel, David Magar, Ganesh Srinivasan, Milan Gada, Nir Mashkowski, Harsh Mittal, Sasha Nosov, Selcin Turkarslan, Cephas Lin, Cheryl McGuire, Bill Mathers, Mandi Ohlinger, Sidney Higa, Michael Green, Heidi Steen, Matt Winkler, Shayne Burgess, Larry Franks, Brad Severtson, Yavor Georgiev, Glenn Gailey, Tim Ammann, Ruppert Koch, Seth Manheim, Abhinav Gupta, Steve Danielson, Corey Sanders, John Deutscher

Satisfazer a alta disponibilidade e requisitos de recuperação de desastres requer dois tipos de conhecimento: 1) compreensão técnica detalhada dos recursos de uma plataforma de nuvem e 2) como arquitetar corretamente um serviço distribuído. Este documento abrange o primeiro, os recursos e as limitações da plataforma do Azure em relação à continuidade de negócios. Embora ele também mencione padrões de arquitetura e design, não é o foco. O leitor deve consultar o material na outra seção Recursos adicionais para obter orientação de design.

As informações estão organizadas nas seguintes seções:

  • 1. Recuperação de falhas locais : o hardware físico (por exemplo, unidades, servidores e dispositivos de rede) pode falhar e os recursos podem ser esgotados quando houver picos de carga. Esta seção descreve os recursos que o Azure fornece para manter a alta disponibilidade nestas condições.

  • 2. Recuperação de perda de uma região do Azure: falhas generalizadas são raras, mas possíveis. Regiões inteiras podem se tornar isoladas devido a falhas de rede, ou serem corrompidas fisicamente devido a desastres naturais. Esta seção explica como usar os recursos do Azure para criar aplicativos que abrangem várias regiões geograficamente.

  • 3. Recuperação de sistema local para Azure: a nuvem altera significativamente a economia da recuperação de desastres, tornando possível para as organizações usarem o Azure para estabelecer um segundo site para recuperação. Isso pode ser feito em uma fração do custo de compilar e manter um datacenter secundário. Esta seção explica os recursos que o Azure fornece para estender um datacenter local para a nuvem.

  • 4. Recuperação de corrupção de dados ou exclusão acidental: os aplicativos podem ter vários bugs que corrompem os dados e os operadores podem excluir incorretamente dados importantes. Esta seção explica o que o Azure fornece para fazer backup dos dados e restaurar para um ponto no tempo anterior.

  • 5. Recursos adicionais: outros recursos importantes que abrangem a disponibilidade e a recuperação de desastres no Azure.

Há dois encadeamentos principais para disponibilidade de aplicativo: a falha dos dispositivos, como unidade e servidores, e a exaustão de recursos importantes, como, por exemplo, o cálculo em condições de carga de pico. O Azure fornece uma combinação de gerenciamento de recursos, elasticidade, balanceamento de carga e particionamento para permitir a alta disponibilidade nessas circunstâncias. Alguns desses recursos são executados automaticamente para todos os serviços de nuvem; no entanto, em alguns casos, o desenvolvedor de aplicativos deve realizar algum trabalho adicional para se beneficiar deles.

Todos os serviços de nuvem hospedados pelo Azure são coleções de uma ou mais funções Web ou de trabalho. Uma ou mais instâncias de uma determinada função podem ser executadas simultaneamente. O número de instâncias é determinado pela configuração. As instâncias de função são monitoradas e gerenciadas com um componente denominado Controlador de Malha (FC). O FC detecta e responde a falhas de software e hardware automaticamente.

  • Cada função da instância é executada em sua própria máquina virtual (VM) e se comunica com seu FC por meio de um agente convidado (GA). O GA coleta métricas de recursos e nó, inclusive o uso de VM, o status, os logs, o uso de recursos, as exceções e as condições de falha. O FC consulta o GA em intervalos configuráveis e reinicializa a VM se o GA não responder.

  • No caso de uma falha de hardware, o FC associado move todas as instâncias de função afetadas para um novo nó de hardware e reconfigura a rede para rotear o tráfego lá.

Para se beneficiar desses recursos, os desenvolvedores devem garantir que todas as funções de serviço evitem armazenar o estado nas instâncias de função. Em vez disso, todos os dados persistentes devem ser acessados de armazenamento durável, como Serviços de Armazenamento do Azure ou Banco de dados SQL do Azure. Isso permite que as solicitações sejam tratadas por todas as funções. Isso também significa que as instâncias de função podem ficar indisponíveis a qualquer momento sem criar inconsistências no estado transiente ou persistente do serviço.

O requisito para armazenar o estado externo para as funções tem várias implicações. Implica, por exemplo, que todas as alterações relacionadas a uma tabela de Armazenamento do Azure devem ser modificadas em uma única transação do Grupo de Entidades, se possível. Naturalmente, nem sempre é possível fazer todas as alterações em uma única transação. Deve haver um cuidado especial para garantir que as falhas da instância de função não causem problemas quando interromperem operações de execução demorada que abrangem duas ou mais atualizações no estado persistente do serviço. Se outra função tentar repetir uma operação, ela deverá prever e controlar o caso em que o trabalho tiver sido concluído parcialmente.

Por exemplo, em um serviço que particiona dados em vários repositórios, se uma função de trabalho ficar indisponível ao realocar um fragmento, a realocação do fragmento não poderá ser concluída, ou poderá ser repetida do início por uma função de trabalho diferente, potencialmente causando dados órfãos ou corrupção de dados. Para evitar problemas, as operações de execução demorada devem ser idempotentes (ou seja, repetíveis sem efeitos colaterais) e/ou reinicializáveis incrementalmente (ou seja, capazes de continuar do ponto de falha mais recente).

  • Para ser idempotente, uma operação de execução demorada deve ter o mesmo efeito não importa quantas vezes seja executada, mesmo quando for interrompida durante a execução.

  • Para ser reinicializável incrementalmente, uma operação de execução demorada deve consistir em uma sequência de operações atômicas menores e deve registrar seu andamento em armazenamento durável, para que cada invocação subsequente retome onde seu antecessor foi interrompido.

Finalmente, todas as operações de execução demorada devem ser invocadas repetidamente até que tenham êxito. Por exemplo, uma operação de provisionamento pode ser colocada em uma fila do Azure e ser removida da fila por uma função de trabalho somente quando for bem-sucedida. A coleta de lixo poderá ser necessária para limpar os dados criados por operações interrompidas.

O número inicial de instâncias executadas para cada função é determinado na configuração de cada função. Os administradores devem configurar inicialmente cada uma das funções para serem executadas com duas ou mais instâncias com base na carga esperada. Mas as instâncias de função podem ser facilmente dimensionadas para cima ou para baixo de acordo com a mudança nos padrões de uso. Isso pode ser feito com o Portal do Azure, Windows PowerShell, API de Gerenciamento de Serviço ou ferramentas de terceiros. O FC automaticamente provisiona todas as novas instâncias e as insere no balanceador de carga para essa função.

Com o Dimensionamento automático do Azure (visualização), você pode habilitar o Azure para dimensionar automaticamente suas funções com base na carga. O dimensionamento automático também pode ser programaticamente interno e configurado para um serviço de nuvem usando uma estrutura como o Bloco de aplicativos de dimensionamento automático (WASABi).

FCs usam dois tipos de partições: domínios de atualização e domínios de falha.

  • Um domínio de atualização é usado para atualizar as instâncias de função de um serviço em grupos. O Azure implanta instâncias do serviço em vários domínios de atualização. Para obter uma atualização in-loco, o FC interrompe todas as instâncias em um domínio de atualização, atualiza essas instâncias e, em seguida, as reinicia antes de passar para o próximo domínio de atualização. Essa abordagem impede que o serviço inteiro fique indisponível durante o processo de atualização.

  • Um domínio de falha define potenciais pontos de falha de hardware ou rede. Para qualquer função com mais de uma instância, o FC garante que as instâncias sejam distribuídas entre vários domínios de falha, a fim de evitar que falhas de hardware isoladas interrompam o serviço. Todas as exposições a falhas de servidor e cluster no Azure são governadas por domínios de falha.

De acordo com o Contrato de Nível de Serviço do Azure, a Microsoft garante que, quando duas ou mais instâncias de função Web são implantadas em diferentes domínios de falha e atualização, elas terão conectividade externa em pelo menos 99,95% do tempo Diferentemente dos domínios da atualização, não há nenhuma maneira de controlar o número de domínios de falha. O Azure automaticamente aloca domínios da falha e distribui as instâncias de função sobre eles. Pelo menos as primeiras duas instâncias de cada função serão colocadas em diferentes domínios de falha e atualização para garantir que as funções com pelo menos duas instâncias atenderão o Contrato de Nível de Serviço. Isso é representado no diagrama a seguir.

Todo o tráfego de entrada para uma função Web transmite um balanceador de carga sem monitoração estado, que distribui solicitações de cliente entre as instâncias de função. As instâncias de função individual não têm endereços IP públicos e não são diretamente endereçáveis da Internet. As funções Web são sem monitoração de estado, de modo que as solicitações de cliente podem ser encaminhadas para qualquer instância de função. Um evento StatusCheck é gerado a cada 15 segundos. Isso pode ser usado para indicar se a função está pronta para receber o tráfego ou se está ocupada e deve ser retirada da rotação do balanceador de carga.

As Máquinas Virtuais do Azure diferem das funções de computação de PaaS em vários aspectos com relação à alta disponibilidade. Em alguma instâncias, você deve fazer o trabalho adicional para garantir a alta disponibilidade.

Ao contrário das instâncias de função de PaaS, os dados armazenados em unidades de máquina virtual são persistentes mesmo quando a máquina virtual é realocada. As Máquinas Virtuais do Azure usam discos de VM que existem como blobs no Armazenamento do Azure. Devido às características de disponibilidade do Armazenamento do Azure, os dados armazenados em unidades de uma máquina virtual também são altamente disponíveis. Observe que a unidade D: é a exceção a essa regra. A unidade D: é realmente o armazenamento físico no servidor de rack que hospeda a VM e seus dados serão perdidos se a VM for reciclada. A unidade D: é destinada somente para armazenamento temporário.

O Azure nativamente compreende as camadas em um aplicativo de PaaS (função Web e de trabalho) e, assim, pode distribuí-las entre domínios de falha e atualização. Em contraste, as camadas em aplicativos de IaaS devem ser definidas manualmente usando conjuntos de disponibilidade. Os conjuntos de disponibilidade são necessários para um Contrato de Nível de Serviço de IaaS.

No diagrama acima, as camadas do IIS e do SQL são atribuídas a diferentes conjuntos de disponibilidade. Isso garante que todas as instâncias de cada camada tenham redundância de hardware distribuindo-as pelos domínios de falha e não sejam interrompidas durante uma atualização. Para obter mais informações sobre como configurar conjuntos de disponibilidade, consulte Gerenciar a disponibilidade de máquinas virtuais.

Se as máquinas virtuais precisarem absorver tráfego distribuído, você deverá agrupar as máquinas virtuais em um serviço de nuvem e balancear a carga em um ponto de extremidade TCP ou UDP específico. Para obter mais informações, consulte Balanceando a carga de máquinas virtuais. Se as máquinas virtuais receberem entrada de outra origem (por exemplo, um mecanismo de fila), um balanceador de carga não será necessário. O balanceador de carga usará uma verificação básica de integridade se o tráfego precisar ser enviado para o nó. Também é possível criar suas próprias investigações para implementar a métrica de integridade específica do aplicativo que determina se a VM deve receber tráfego.

O Armazenamento do Azure é o serviço de dados durável de linha de base para o Azure, fornecendo o armazenamento de blob, tabela, fila e armazenamento em disco de VM. Ele usa uma combinação de replicação e gerenciamento de recurso para fornecer alta disponibilidade dentro de um único data center. O SLA de disponibilidade do Armazenamento do Azure garante que pelo menos em 99,9% do tempo, as solicitações formatadas corretamente para adicionar, atualizar, ler e excluir dados serão bem-sucedidas e processadas corretamente e que as contas de armazenamento terão conectividade com o gateway da Internet.

A durabilidade dos dados para o Armazenamento do Azure é viabilizada pela manutenção de várias cópias de todos os dados em unidades diferentes localizadas em subsistemas de armazenamento físico totalmente independentes dentro da região. Os dados são replicados de forma síncrona e todas as cópias são confirmadas antes de a gravação ser confirmada. O Armazenamento do Azure é altamente consistente, o que significa que as leituras têm garantia de refletir as gravações mais recentes. Além disso, as cópias dos dados são verificadas continuamente para detectar e repare bits corrompidos, uma ameaça à integridade dos dados armazenados que é frequentemente desconsiderada. Os serviços se beneficiam da replicação usando apenas o Armazenamento do Azure. Nenhum trabalho adicional é exigido pelo desenvolvedor do serviço para a recuperação de uma falha local.

As contas de armazenamento criadas depois de 7 de junho de 2012 podem crescer até 200TB (o máximo anterior era 100 TB.) Se o espaço adicional for necessário, os aplicativos deverão ser criados para aproveitar várias contas de armazenamento.

O disco de VM de uma máquina virtual é armazenado como um blob de página no Armazenamento do Azure, permitindo que você tenha as mesmas propriedades de durabilidade e escalabilidade que o armazenamento de blob. Esse design torna persistentes os dados no disco de uma máquina virtual mesmo se o servidor que executar a VM falhar e a VM precisar ser reiniciada em outro servidor.

O Banco de dados SQL do Microsoft Azure fornece banco de dados como serviço, permitindo que os aplicativos provisionem, insiram dados e consultem bancos de dados relacionais rapidamente. Ele apresenta muitos dos recursos e funcionalidades conhecidos do SQL Server, ao mesmo tempo que abstrai a carga do hardware, da configuração, da aplicação de patches e da resiliência.

noteObservação
O Banco de dados SQL do Azure não fornece paridade de recursos 1:1 com o SQL Server e foi desenvolvido para atender a um conjunto diferente de requisitos, exclusivamente adequados para aplicativos em nuvem (escala elástica, banco de dados como serviço para reduzir os custos de manutenção e assim por diante). Para obter mais informações, consulte Séries de dados: SQL Server na máquina virtual do Azure ou no Banco de dados SQL.

O Banco de dados SQL do Azure fornece resiliência interna a falhas no nível de nó. Todas as gravações em um banco de dados são replicadas automaticamente em dois ou mais nós em segundo plano usando uma técnica de confirmação de quorum (o primário e, pelo menos, um secundário devem confirmar que a atividade foi gravada no log de transações antes que a transação seja considerada bem-sucedida e retorne). Em caso de falha do nó, o banco de dados faz failover automaticamente em uma das réplicas secundárias Isso causa uma interrupção de conexão transitória para aplicativos cliente. Por esse motivo, todos os clientes do Banco de dados SQL do Microsoft Azure devem implementar alguma forma de tratamento de conexão transitória. Para obter mais informações, consulte Usando o bloco de aplicativo de tratamento de falhas transitórias com o SQL Azure.

Cada banco de dados, quando criado, é configurado com um limite de tamanho superior. O tamanho máximo disponível atualmente é 150GB. Quando um banco de dados atinge o limite de tamanho superior, ele rejeita os comandos adicionais INSERT ou UPDATE (mas ainda é possível consultar e excluir dados).

Dentro de um banco de dados, o Banco de dados SQL do Microsoft Azure usa uma malha para gerenciar recursos. No entanto, em vez de um controlador de malha, ele usa uma topologia de anel para detectar falhas. Cada réplica em um cluster tem dois vizinhos e é responsável por detectar quando eles são interrompidos. Quando uma réplica é interrompida, seus vizinhos acionam um Agente de Reconfiguração (RA) para recriá-la em outro computador. A limitação de mecanismo é fornecida para garantir que um servidor lógico não use muitos recursos em um computador ou exceda os limites físicos do computador.

Se o aplicativo precisar de mais do que o limite de banco de dados de 150GB, ele deverá implementar uma abordagem de dimensionamento. O dimensionamento com o Banco de dados SQL do Microsoft Azure é feito por particionamento manual, também conhecido como fragmentação, de dados em vários Banco de dados SQL do Azure. Essa abordagem de expansão fornece a oportunidade de atingir o crescimento de custo quase linear com a escala. O crescimento ou a capacidade elástica sob demanda pode crescer com custos incrementais conforme o necessário, porque os bancos de dados são faturados com base no tamanho real médio usado por dia, não com base no tamanho máximo possível.

Ao instalar o SQL Server 2012 em Máquinas Virtuais do Azure (IaaS), você poderá se beneficiar dos recursos de disponibilidade tradicionais do SQL Server, como Grupos de Disponibilidade AlwaysOn ou espelhamento de banco de dados. Observe que as máquinas virtuais, armazenamento e redes do Azure têm características operacionais diferentes de uma infraestrutura de TI local, não virtualizada. Uma implementação com êxito de uma solução HADR do SQL Server no Azure exige que você compreenda essas diferenças e crie sua solução para acomodá-las.

Quando você implementa uma solução de alta disponibilidade no Azure, o conjunto de disponibilidade no Azure o habilita a colocar os nós de alta disponibilidade em domínios de falha diferentes e a atualizar domínios. Na verdade, o conjunto de disponibilidade é um conceito do Azure. Para obter mais informações, consulte Gerenciar a disponibilidade de máquinas virtuais. É uma prática recomendada verificar se seus bancos de dados estão de fato altamente disponíveis, se você está usando ou não grupos de disponibilidade AlwaysOn e o espelhamento de banco de dados. Se você não segue esta prática recomendada, você pode estar na suposição false se o sistema é altamente disponível, mas na verdade seus nós podem qualquer falha porque simultaneamente acontecem ser colocados no mesmo domínio de falha do datacenter do Azure. Essa recomendação não é tão aplicável no envio de logs pois, assim como um recurso de recuperação de desastres, você deve certificar-se de que os servidores estejam em execução em locais de datacenter separados no Azure (regiões). Por definição, esses locais do datacenter são domínios de falha separados.

Para que máquinas virtuais do Azure sejam colocadas no mesmo conjunto de disponibilidade, é necessário implantá-las no mesmo serviço de nuvem. Apenas os nós no mesmo serviço de nuvem podem participar do mesmo conjunto de disponibilidade. Além disso, as máquinas virtuais devem estar no mesmo VNet para assegurar que mantenham os IPs mesmo depois que o serviço for recuperado, evitando tempos de atualização de DNS.

Você pode ter uma solução de alta disponibilidade para bancos de dados do SQL Server no Azure usando grupos de disponibilidade AlwaysOn ou o espelhamento de banco de dados.

O diagrama a seguir mostra a arquitetura de Grupos de Disponibilidade AlwaysOn que são executados em Máquinas Virtuais do Azure. Este diagrama foi retirado do artigo detalhado sobre este assunto, Alta disponibilidade e recuperação de desastres para o SQL Server em Máquinas Virtuais do Azure.

O diagrama a seguir demonstra o uso de espelhamento de banco de dados em Máquinas Virtuais do Azure. Ele também foi retirado do tópico detalhado Alta disponibilidade e recuperação de desastres para o SQL Server em Máquinas Virtuais do Azure.

noteObservação
Observe que, em ambas as arquiteturas, um controlador de domínio é necessário. No entanto, com o espelhamento de banco de dados, é possível usar certificados de servidor para eliminar a necessidade de um controlador de domínio.

Os Serviços de Nuvem do Azure são criados no Azure e, portanto, se beneficiam de recursos da plataforma descritos anteriormente para se recuperar de falhas locais. Em alguns casos, há ações específicas que você pode realizar para aumentar a disponibilidade para seu cenário específico.

O Access Control Service (ACS) 2.0 faz backup de todos os namespaces uma vez por dia e os armazena em um local seguro externo. Quando o pessoal de operação do ACS determina houve uma perda de dados irrecuperável em uma dos data centers regionais do ACS, o ACS tentará recuperar as assinaturas dos clientes restaurando o backup mais recente. Devido à frequência dos backups, pode ocorrer perda de dados de até 24 horas. Para obter mais informações, consulte Access Control Service (recuperação de desastre).

Para atenuar uma interrupção temporária do Azure Service Bus, crie uma fila durável do lado do cliente. Isso usa temporariamente um mecanismo de armazenamento local alternativo para armazenar as mensagens que não podem ser adicionadas à fila do Service Bus. O aplicativo pode decidir como controlar as mensagens armazenadas temporariamente depois que o serviço é restaurado. Para obter mais informações, consulte Isolando aplicativos do Service Bus contra interrupções e desastres. Para obter mais informações, consulte Service Bus (recuperação de desastres).

Há duas considerações de disponibilidade para os Serviços Móveis do Azure. Primeiro, faça backup regularmente do Banco de dados SQL do Azure associado ao serviço móvel. Além disso, faça backup dos scripts de serviço móvel. Para obter mais informações, consulte Recupere seu serviço móvel em caso de desastre. Se os Serviços Móveis apresentarem uma interrupção temporária, talvez seja necessário temporariamente usar um datacenter alternativo do Azure. Para obter mais informações, consulte Serviços Móveis (recuperação de desastres).

Os dados associados ao HDInsight são armazenados por padrão no armazenamento de blob do Azure, que tem as propriedades de alta disponibilidade e durabilidade especificadas pelo Armazenamento do Azure. O processamento de vários nós associado aos trabalhos do Hadoop MapReduce é feito em um sistema de arquivos distribuído Hadoop transitório (HDFS) que é provisionado conforme a necessidade pelo HDInsight. Os resultados de um trabalho de MapReduce também são armazenados por padrão no Armazenamento de blob do Azure, de forma que os dados processados sejam duráveis e permaneçam altamente disponíveis depois que o cluster de Hadoop tiver o provisionamento cancelado. Para obter mais informações, consulte HDInsight (recuperação de desastres).

 

Serviço/área Lista de Verificação

Computação (PaaS)

  • Configurar pelo menos duas instâncias para cada função.

  • Persistir estado em armazenamento durável, não em instâncias de função.

  • Processar corretamente o evento de StatusCheck.

  • Encapsular alterações relacionadas em transações quando for possível.

  • Verificar se as tarefas de função de trabalho são idempotentes e reinicializáveis.

  • Continuar para invocar operações até que tenham êxito.

  • Considerar estratégias de dimensionamento automático.

Máquinas virtuais (IaaS)

  • Não usar a unidade D: para armazenamento persistente.

  • Agrupar computadores em uma camada de serviço em um conjunto de disponibilidade.

  • Configurar o balanceamento de carga e investigações opcionais.

Armazenamento

  • Usar várias contas de armazenamento quando os dados ou a largura de banda exceder as cotas.

Banco de Dados SQL

  • Implementar uma política de repetição para tratar erros temporários.

  • Usar particionamento/fragmentação como uma estratégia de expansão.

SQL Server 2012 em máquinas virtuais (IaaS)

  • Siga as recomendações anteriores para máquinas virtuais.

  • Use os recursos de alta disponibilidade do SQL Server, como AlwaysOn.

Access Control Service (disponibilidade)

  • Nenhuma etapa adicional de disponibilidade necessária para falhas locais.

Service Bus (disponibilidade)

  • Considere a criação de uma fila durável do lado do cliente como um backup.

Serviços Móveis (disponibilidade)

  • Faça backup regularmente do Banco de dados SQL do Azure associado aos serviços móveis.

  • Faça backup dos scripts de serviços móveis.

HDInsight (disponibilidade)

  • Nenhuma etapa adicional de disponibilidade necessária para falhas locais.

O Azure é dividido fisicamente e logicamente em unidades chamadas de regiões. Uma região consiste em um ou mais datacenters em grande proximidade. No momento desse artigo, o Azure tem oito regiões (4 na América do Norte, 2 na Ásia e 2 na Europa).

Em circunstâncias raras, as instalações em uma região inteira podem se tornar inacessíveis, por exemplo, devido a falhas de rede ou perda completa, por exemplo, devido a desastres naturais. Esta seção explica os recursos do Azure para criar aplicativos que são distribuídos entre regiões. As regiões são criadas para minimizar a possibilidade de uma falha em uma região afetar outras regiões.

A distribuição de instâncias de computação entre regiões é feita criando um serviço de nuvem separado em cada região de destino e publicando o pacote de implantação em cada serviço de nuvem. No entanto, observe que a distribuição de tráfego pelos serviços de nuvem em diferentes regiões deve ser implementada pelo desenvolvedor de aplicativos ou com um serviço de gerenciamento de tráfego.

Determinar o número de instâncias de função de reposição para implantar com antecedência para a recuperação de desastres é um aspecto importante do planejamento de capacidade. Ter uma implantação secundária completa garante que a capacidade já esteja disponível quando for 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 essenciais. Recomendamos criar pelo menos uma implantação secundária pequena, tanto para reservar a capacidade como para testar a configuração do ambiente secundário.

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

Para balancear a carga do tráfego entre regiões, é necessário usar uma solução de gerenciamento de tráfego. O Azure fornece o Azure Traffic Manager (agora em CTP). Você também pode aproveitar os serviços de terceiros que fornecem recursos semelhantes de gerenciamento de tráfego.

Muitas estratégias alternativas estão disponíveis para implementar a computação distribuída entre regiões. Elas devem ser personalizadas para os requisitos de negócios e as circunstâncias específicas do aplicativo. Em um nível alto, as abordagens podem ser divididas em 3 categorias:

  • Reimplantação em caso de desastre: nessa abordagem, o aplicativo é reimplantado do zero na hora do desastre.. Isso é apropriado para os aplicativos não críticos que não exigem um tempo de recuperação garantido.

  • Reposição morna (ativa/passiva): um serviço hospedado secundário é criado em uma região alternativa e as funções são implantadas para garantir a capacidade mínima; porém, as funções não recebem o tráfego de produção. Essa abordagem é útil para aplicativos que não foram criados para distribuir o tráfego entre regiões.

  • Reposição a quente (ativa/ativa): o aplicativo é criado para receber a carga de produção em várias regiões. Os serviços de nuvem em cada região podem ser configurados para uma capacidade mais alta do que a necessária para fins de recuperação de desastres. Alternativamente, os serviços de nuvem podem ser expandidos conforme o necessário no momento de um desastre e um failover. Esta abordagem requer o investimento significativo na criação de aplicativo, mas tem benefícios significativos que incluem tempo de recuperação baixo e garantido, testes contínuos de todos os locais de recuperação e uso eficiente de capacidade.

Uma análise completa de design distribuído está fora do escopo deste documento. Os artigos a seguir fornecem orientação detalhada sobre esses cenários.

A recuperação de VMs de IaaS é semelhante à recuperação de computação de PaaS em vários aspectos. No entanto, há diferenças importantes devido ao fato de que uma VM de IaaS consiste em VM e no disco de VM.

  • Use a API de cópia blob para duplicar discos da VM: para criar VMs em várias regiões, o disco de VM deve ser copiado para a região alternativa. Como os discos de VM são apenas blobs, isso pode ser feito usando a API de cópia blob.

  • Separe o disco de dados do disco do sistema operacional. uma consideração importante para VMs de IaaS é que você não pode alterar o disco do sistema operacional sem recriar a VM. Isso não será um problema se sua estratégia de recuperação for reimplantar depois do desastre. No entanto, pode ser um problema se você estiver usando a abordagem de Reposição Morna para reservar capacidade. Para implementar isso corretamente, você deve ter o disco correto do sistema operacional implantado nos locais primários e secundários e os dados do aplicativo devem ser armazenados em uma unidade separada. Se for possível, use uma configuração padrão do sistema operacional que pode ser fornecida em ambos os locais. Depois de um failover, você deve anexar a unidade de dados a suas VMs de IaaS existentes no datacenter secundário. Use a API CopyBlob para copiar instantâneos dos discos de dados para um site remoto.

  • Problemas potenciais 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 as mesmas características de replicação geográfica (veja abaixo). Os discos de VM são garantidos para estarem em um estado consistente de falha depois de um failover geográfico, mas não há garantias de consistência entre discos porque a replicação geográfica é assíncrona e replica de maneira independente. Isso pode causar problemas em alguns casos (por exemplo, no caso de segmentação de disco). Pode ser necessário realizar um trabalho adicional para restaurar a consistência depois de um failover geográfico. Para garantir a exatidão de backups, um produto de backup como o Data Protection Manager deverá ser usado para fazer backup de dados e restaurar os dados de aplicativo.

No Azure, os blobs, as tabelas, as filas e os discos de VM são todos replicados geograficamente por padrão. Isso é referido como GRS (armazenamento geograficamente redundante). O GRS reproduz os dados de armazenamento em um datacenter emparelhado a centenas de milhas de distância dentro de uma região geográfica específica. A GRS é destinada a fornecer durabilidade adicional em caso de haver um desastre de data center de maiores proporções. A Microsoft controla quando um failover ocorre e o failover é limitado a desastres maiores, nos quais o local primário original é negado de maneira irrecuperável em um período de tempo considerável. Em alguns cenários, isso pode levar vários dias. Os dados são normalmente replicados em alguns minutos, embora o intervalo de sincronização ainda não esteja coberto por um SLA.

No caso de um failover geográfico, não haverá nenhuma alteração ao modo 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 depois do failover, o que pode afetar os aplicativos que exigem afinidade regional com sua conta de armazenamento. Mesmo para os serviços e os aplicativos que não exigem uma conta de armazenamento no mesmo data center, a latência entre datacenters e os encargos de largura de banda poderão ser um motivo convincente para mover temporariamente o tráfego para a região de failover. Isso pode influenciar 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 a você acesso de leitura à cópia de seus dados em um segundo local de armazenamento. Isso é chamado de armazenamento geograficamente redundante de acesso de leitura (RA-GRS).

Para obter mais informações sobre visualização GRS e RA-GRS, consulte Opções de redundância de armazenamento do Windows Azure e armazenamento geograficamente redundante de acesso de leitura.

É importante saber onde os seus dados são replicados geograficamente para saber onde implantar as outras instâncias dos dados que exigem afinidade regional com seu armazenamento. A tabela a seguir mostra os emparelhamentos de locais primários e secundários:

 

Primária Secundária

Centro-Norte dos EUA

Estados Unidos Central Sul

Estados Unidos Central Sul

Centro-Norte dos EUA

Leste dos EUA

Oeste dos EUA

Oeste dos EUA

Leste dos EUA

Norte da Europa

Europa Ocidental

Europa Ocidental

Norte da Europa

Sudeste Asiático

Ásia Oriental

Ásia Oriental

Sudeste Asiático

China oriental

Norte da China

Norte da China

China oriental

Sul do Brasil

Estados Unidos Central Sul

A replicação geográfica está incluída na composição de preços atual para o Armazenamento do Azure. Isso é chamado de armazenamento geograficamente redundante. Se você não quiser que seus dados sejam replicados geograficamente, poderá desabilitar a replicação geográfica para sua conta. Isso é chamado de armazenamento localmente redundante, e é cobrado com desconto sobre o armazenamento replicado geograficamente. Veja aqui para obter mais detalhes sobre o armazenamento localmente redundante (LRS).

Se um failover geográfico ocorrer, ele será postado no Painel de integridade de serviço do Azure; no entanto, os aplicativos podem implementar um meio automatizado de detectar isso monitorando a região geográfica para sua conta de armazenamento. Isso pode ser usado para disparar outras operações de recuperação como a ativação de recursos de computação na região geográfica para onde seu armazenamento foi movido. Isso é consultável pela API de gerenciamento do serviço usando Obter propriedades da conta de armazenamento. As propriedades relevantes são:

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

  • Conforme foi discutido na seção sobre discos de VM, não há nenhuma garantia para a consistência de dados entre discos de VM depois de um failover. Para garantir a exatidão de backups, um produto de backup como o Data Protection Manager deverá ser usado para fazer backup de dados e restaurar os dados de aplicativo.

A recuperação do Banco de dados SQL do Azure do Azure pode ser obtida por meio da exportação do banco de dados para um blob de armazenamento do Azure usando o serviço de importação/exportação do Banco de dados SQL do Azure do Azure. Isso pode ser implementado de três maneiras:

  • Exportar para um blob usando a conta de armazenamento em um data center diferente

  • Exportar para um blob usando a conta de armazenamento no mesmo data center (e confiar na replicação geográfica do Armazenamento do Azure no data center separado).

  • Importar seu SQL Server local.

Para obter detalhes sobre a implementação, consulte o artigo do MSDN Continuidade dos negócios no Banco de dados SQL do Azure.

Há duas opções para recuperar um banco de dados do SQL Server que está sendo executado em um IaaS para um datacenter alternativo do Azure: espelhamento de banco de dados ou backup e restauração com blobs de armazenamento. Observe que, neste momento, os Grupos de Disponibilidade do SQL Server 2012 não têm suporte em datacenters do Azure, pois as redes virtuais em datacenters não têm suporte no momento no Azure, e um domínio de diretório ativo não pode abranger vários datacenters do Azure.

Ao usar o espelhamento de banco de dados para recuperação de desastres, você verá ter os servidores principal e espelho sendo executados em datacenter do Azure diferentes. Isso significa que você deve implantar usando certificados de servidor, porque um domínio do Ative Directory não pode abranger vários datacenters do Azure sem roteamento do tráfego por uma rede local. O diagrama a seguir ilustra essa instalação.

A outra opção é usar backup e restauração padrão com blobs de armazenamento 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.

Ao tentar executar o serviço de nuvem em várias regiões do Azure, você deverá considerar as implicações para cada uma de suas dependências. Nas seções a seguir, a orientação específica do serviço supõe que você use o mesmo serviço do Azure em um datacenter alternativo do Azure. Isso envolve tarefas de configuração e de replicação de dados.

Observe que, em alguns casos, estas etapas podem ajudar a reduzir uma interrupção específica de serviço em vez de um evento de datacenter inteiro. Da perspectiva do aplicativo, uma interrupção específica de serviço pode limitar da mesma forma e exigiria a migração temporária do serviço para uma região alternativa do Azure.

O Access Control Service (ACS) usa um nome de namespace exclusivo que não abrange regiões do Azure. O ACS 2.0 faça backup de todos os namespaces uma vez por dia e os armazena em um local seguro externo. Em caso de desastre, a equipe da operação do ACS pode tentar recuperar as assinaturas de clientes em uma região remota do Azure usando o backup mais recente. Devido à frequência dos backups, pode ocorrer perda de dados de até 24 horas. Não há SLA para failover regional e o tempo de recuperação pode ser vários dias dependendo do cenário.

Para usar o ACS em uma região alternativa, os clientes devem configurar um namespace de ACS nessa região. Os clientes do ACS 2.0 que estiverem preocupados com o potencial para perda de dados são incentivados a analisar o Serviço de gerenciamento do ACS 2.0. Essa interface permite que os administradores gerenciem seus namespaces e importem e extraiam todos os dados relevantes. Com o uso dessa interface, os clientes do ACS podem desenvolver soluções personalizadas de backup e restauração para um nível mais elevado de consistência de dados do que é fornecido no momento pelo ACS. Para obter outras considerações sobre disponibilidade, consulte Access Control Service (disponibilidade).

Da mesma forma que com o ACS, o Service Bus usa um namespace exclusivo que não abrange regiões do Azure. Portanto, o primeiro requisito é instalar os namespaces do service bus necessários na região alternativa. No entanto, também há considerações para a durabilidade das mensagens enfileiradas. Há várias estratégias para replicar mensagens entre as regiões do Azure. Para obter os detalhes dessas estratégias de replicação e outras estratégias de recuperação de desastres, consulte Isolando aplicativos do Service Bus contra interrupções e desastres. Para obter outras considerações sobre disponibilidade, consulte Service Bus (disponibilidade).

Para migrar um Site do Azure para uma região secundária do Azure, você deverá ter um backup do site disponível para publicação. Se a interrupção não envolver o datacenter inteiro do Azure, poderá ser possível usar o FTP para baixar um backup recente do conteúdo do site. Crie um novo site 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 de região. Se for necessário, adicione o certificado SSL do site e altere o registro de DNS CNAME de forma que os pontos personalizados de nome de domínio sejam reimplantados na URL do Site do Azure

Na região secundária do Azure, crie um serviço móvel de backup para seu aplicativo. Restaure o Banco de dados SQL do Azure para a região alternativa também. Use as ferramentas de linha de comando do Azure para mover o serviço móvel para a região alternativa. Configure o serviço móvel para usar o banco de dados restaurado. Para obter mais informações sobre esse processo, consulte Recupere seu serviço móvel em caso de desastre. Para obter outras considerações sobre disponibilidade, consulte Serviços Móveis (disponibilidade).

Os dados associados ao HDInsight são armazenados por padrão no armazenamento de blob do Azure. O HDInsight exige que um cluster de Hadoop que processa trabalhos de MapReduce deve ser colocado na mesma região que a conta de armazenamento que contém os dados que estão sendo analisados. Contanto que você use o recurso de replicação geográfica disponível para o armazenamento do Azure, você pode acessar seus dados na região secundária onde os dados foram replicados se, por alguma razão, a região primária não estiver mais disponível. Você pode criar um novo cluster de Hadoop na região onde os dados foram replicados e continuar o processamento. Para obter outras considerações sobre disponibilidade, consulte HDInsight (disponibilidade).

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

Os Serviços de Mídia do Azure têm uma abordagem diferente de recuperação para codificar e transmitir. Normalmente, a transmissão é mais crítica durante uma interrupção regional. Para se preparar para isso, você deverá 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 realizada em qualquer região do Azure. Se a codificação for sensível ao tempo, por exemplo, durante o processamento ativo de evento, você deverá estar preparado para enviar trabalhos para um datacenter alternativo durante falhas.

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 primária do Azure, exporte as configurações de rede virtual para a rede atual para um arquivo de configuração de rede. No caso de uma interrupção na região primária, restaure a rede virtual do arquivo de configuração armazenado. Em seguida, configure outros serviços de nuvem, máquinas virtuais ou configurações entre os locais para trabalhar com a nova rede virtual.

 

Serviço/área Lista de Verificação

Computação (PaaS)

  • Criar uma estratégia de recuperação de desastres entre regiões.

  • Entender as compensações em reservar capacidade em regiões alternativas.

  • Usar ferramentas de roteamento de tráfego, como o Azure Traffic Manager (CTP).

Máquinas virtuais (IaaS)

  • Copiar os recursos de disco de VM de blob para o datacenter alternativo.

  • Executar backups regulares do disco de VM ou do conteúdo do disco.

Armazenamento

  • Não desabilitar a replicação geográfica de recursos de armazenamento.

  • Compreender a região alternativa para a replicação geográfica no caso de failover.

  • Criar estratégias de backup personalizadas para estratégias de failover controladas pelo usuário.

Banco de dados SQL (recuperação de desastres)

  • Exportar o Banco de dados SQL do Azure para o armazenamento de blob.

  • Criar um plano de recuperação de desastres com base nas considerações de armazenamento anteriores.

SQL Server em máquinas virtuais (recuperação de desastres)

  • Usar o espelhamento de banco de dados entre regiões.

  • Como alternativa, usar backup e restauração para o armazenamento de blob.

Access Control Service (recuperação de desastre)

  • Configurar um namespace de ACS em uma região alternativa.

  • Use o Serviço de Gerenciamento ACS 2.0 para criar soluções de backup personalizadas.

Service Bus (recuperação de desastres)

  • Configurar um namespace de Service Bus em uma região alternativa.

  • Considerar estratégias de replicação personalizadas para mensagens entre regiões.

Sites (recuperação de desastres)

  • Manter backup do site fora da região primária.

  • Se a interrupção for parcial, tente recuperar o site atual com FTP.

  • Planejar para implantar o site em um novo site ou um existente em uma região alternativa.

  • Planejar as alterações de configuração para os registros do aplicativo e de DNS CNAME.

Serviços Móveis (recuperação de desastres)

  • Criar um serviço móvel de backup em uma região alternativa.

  • Gerenciar backups do Banco de dados SQL do Azure associado para restaurar durante o failover.

  • Usar as ferramentas de linha de comando do Azure para mover o serviço móvel.

HDInsight (recuperação de desastres)

  • Criar um novo cluster de Hadoop na região com dados replicados.

Relatórios SQL (recuperação de desastres)

  • Manter uma instância de Relatórios SQL alternativa em uma região diferente.

  • Mantenha um plano separado para replicar o destino para essa região.

Serviços de Mídia (recuperação de desastres)

  • Criar uma conta de Serviços de Mídia em uma região alternativa.

  • Codificar o mesmo conteúdo em ambas as regiões para dar suporte ao failover de streaming.

  • Enviar trabalhos de codificação para uma região alternativa no caso de uma interrupção.

Rede virtual (recuperação de desastres)

  • Usar configurações exportadas de rede virtual para recriá-la em outra região.

O Azure fornece um conjunto abrangente de serviços para habilitar a extensão de um datacenter local para o Azure para fins de alta disponibilidade e recuperação de desastres:

  • Rede: com a rede virtual privada, você estende com segurança sua rede local para a nuvem.

  • Computar: os clientes que usam o Hyper-V local podem "comparar e deslocar“ máquinas virtuais existentes para o Azure

  • Armazenamento: o StorSimple estende o sistema de arquivos para o Armazenamento do Azure. O serviço de backup do Azure fornece o backup para arquivos e Banco de dados SQL do Azures para o Armazenamento do Azure

  • Replicação de banco de dados: com os Grupos de Disponibilidade do SQL 2012, você pode implementar alta disponibilidade e recuperação de desastres para os dados locais

A Rede Virtual do Azure permite a você criar uma seção isolada logicamente no Azure e conectá-la com segurança ao seu datacenter local ou a uma única máquina de cliente por meio de uma conexão IPsec. A Rede Virtual facilita o aproveitamento da infraestrutura dimensionável sob demanda do Azure enquanto fornece conectividade aos dados e aplicações no local, incluindo sistemas sendo executados no Windows Server, mainframes e UNIX. Consulte aqui para obter mais informações.

Os clientes que usam Hyper-V local podem "comparar e deslocar" VMs existentes para os provedores de serviços e o Azure que executam o Windows Server 2012, sem fazer alterações na VM ou converter formatos de VM.& Para obter mais informações, consulte Gerenciar discos e imagens.

Há várias opções para usar o Azure como um site de backup para dados locais.

O StorSimple integra com segurança e transparência o armazenamento em nuvem para aplicativos locais e oferece um único dispositivo que fornece o armazenamento em camadas de alto desempenho local e na nuvem, arquivamento ativo, proteção de dados baseada em nuvem e recuperação de desastres. Para obter mais informações, consulte StorSimple -- Cloud-integrated Storage -- What & Why.

Os Serviços de backup do Azure permitem backups na nuvem usando as ferramentas de backup familiares no Windows Server 2012, no Windows Server 2012 Essentials e no System Center 2012 Data Protection Manager. Essas ferramentas fornecem um fluxo de trabalho para gerenciamento de backup que é independente do local de armazenamento dos backups, seja um disco local ou um armazenamento do Azure. Após a realização do backup dos dados na nuvem, os usuários autorizados poderão recuperar facilmente os backups em qualquer servidor.

Com os backups incrementais, somente as alterações feitas nos arquivos são transferidas para a nuvem. Isso ajuda a usar com eficiência o espaço de armazenamento, reduzir o consumo da largura de banda e dar suporte à recuperação pontual de várias versões dos dados. Você também pode usar recursos adicionais, como políticas de retenção de dados, compactação de dados e limitação da transferência de dados. Usar o Azure como o local de backup tem a vantagem óbvia de que os backups são automaticamente “fora do local”. Isso elimina os requisitos adicionais para garantir a segurança e proteger a mídia de backup no local. Para obter mais informações, consulte Visão geral de backup do Azure e Usando o DPM com o backup do Azure.

Você pode ter uma solução de recuperação de desastres para seus bancos de dados do SQL Server em um ambiente de TI híbrida usando grupos de disponibilidade AlwaysOn, espelhamento de banco de dados, envio de logs, e backup e restauração com o armazenamento de blog do Azure. Todas essas soluções usam o SQL Server executado em Máquinas Virtuais do Azure.

Os Grupos de Disponibilidade AlwaysOn podem ser usados em um ambiente de TI híbrido onde as réplicas de banco de dados existem no local e na nuvem. Isso é mostrado no diagrama a seguir, retirado do tópico detalhado Alta disponibilidade e recuperação de desastres para o SQL Server em Máquinas Virtuais do Azure.

O espelhamento de banco de dados também pode abranger servidores locais e a nuvem em uma instalação baseada em certificado. O diagrama a seguir ilustra esse conceito.

O envio de logs pode ser usado para sincronizar um banco de dados local com um banco de dados do SQL Server em uma Máquina Virtual do Azure.

Finalmente, você pode fazer backup em um banco de dados local diretamente no Armazenamento de blob 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 e Backup e restauração para o SQL Server em Máquinas Virtuais do Azure.

 

Serviço/área Lista de Verificação

Rede

  • Usar a rede virtual para conectar com segurança o local à nuvem.

Computar

  • Realocar máquinas virtuais entre o Hyper-V e o Azure.

Armazenamento

  • Aproveitar os serviços de StorSimple para usar o armazenamento em nuvem.

  • Usar os Serviços de backup do Azure.

Banco de dados

  • Usar o SQL Server nas VMs do Azure como o backup.

  • Configurar Grupos de Disponibilidade AlwaysOn.

  • Configurar o espelhamento de banco de dados baseado em certificados.

  • Usar envio de logs.

  • Fazer backup de banco de dados local para o armazenamento de blob do Azure.

Este cenário é sobre recuperação de dados corrompidos ou excluídos acidentalmente devido a erros do aplicativo ou erro do operador.

Observe que embora o Armazenamento do Azure forneça resiliência de dados por meio de réplicas automáticas, isso não impede que o código do seu aplicativo (ou desenvolvedores/usuários) corrompa dados por exclusão acidental ou involuntária, atualização, etc. Manter a fidelidade dos dados frente a um erro do usuário ou aplicativo requer técnicas mais avançadas, como copiar os dados em um local de armazenamento secundário com um log de auditoria. Os desenvolvedores podem aproveitar o recurso instantâneo do blob, o que pode criar instantâneos pontuais somente leitura do conteúdo do blob. Isso pode ser usado como a base de uma solução de fidelidade de dados para blobs.

Quando os blobs e as tabelas são altamente duráveis, eles sempre representam o estado atual dos dados. A recuperação da modificação ou exclusão indesejada de dados pode exigir a restauração dos dados para um estado anterior. Isso pode ser feito aproveitando os recursos fornecidos pelo Azure para armazenar e manter cópias pontuais.

Para blobs do Azure, você pode executar backups pontuais usando recurso de instantâneo de blob. Para cada instantâneo, você é cobrado apenas pelo armazenamento necessário armazenar as diferenças no blob desde o último estado de instantâneo. Os instantâneos dependem da existência do blob original em que são baseados. Portanto, é recomendável uma operação de cópia para outra conta de blob ou de armazenamento para garantir que os dados de backup sejam devidamente protegidos contra a exclusão acidental. Para tabelas do Azure, você pode fazer cópias pontuais em uma tabela diferente ou em blobs do Azure. Mais diretrizes detalhadas e exemplos de execução de backups de tabelas e blobs no nível de aplicativo podem ser encontradas aqui:

Há várias opções de continuidade de negócios (backup, restauração) disponíveis para o Banco de dados SQL do Azure. Os bancos de dados podem ser copiados por meio da funcionalidade Cópia de Banco de Dados ou pelo Serviço de Importação/Exportação do DAC. A Cópia de Banco de Dados fornece resultados transacionais e consistentes, enquanto um bacpac (por meio do serviço de importação/exportação), não. Essas duas opções são executadas como serviços baseados em fila no data center e, atualmente, não fornecem um SLA de tempo para conclusão.

noteObservação
Observe que o serviço de cópia e de importação/exportação do banco de dados impõe um grau significativo de carga no banco de dados de origem, podendo disparar a contenção de recursos ou eventos de limitação (descritos na seção abaixo em Recursos compartilhados e limitação).

Os backups pontuais para o Banco de dados SQL do Microsoft Azure são obtidos com o comando de cópia do Banco de dados SQL do Azure. Você pode usar esse comando para criar uma cópia transacionalmente consistente de um banco de dados no mesmo servidor de banco de dados lógico ou em um servidor diferente. Em ambos os casos, a cópia do banco de dados é totalmente funcional e completamente independente do banco de dados de origem. Cada cópia que você cria representa uma opção de recuperação pontual. É possível recuperar o estado do banco de dados completamente renomeando o novo banco de dados com o nome do banco de dados de origem. Como alternativa, você pode recuperar um subconjunto específico de dados do novo banco de dados usando consultas Transact-SQL. Para obter mais detalhes sobre o Banco de Dados SQL, consulte Continuidade dos negócios no Banco de dados SQL do Azure.

Para o SQL Server no IaaS, há duas opções: backups e envio de logs tradicionais. Usar backups tradicionais permite restaurar para um momento determinado específico, mas o processo de recuperação é lento. Restaurar backups tradicionais exige iniciar com um backup completo e, em seguida, aplicar todos os backups feitos depois disso. A segunda opção é configurar uma sessão de envio de logs para atrasar a restauração de backups de log (por exemplo, em duas horas). Isso fornece uma janela para a recuperação de erros feita no primário.

Alguns serviços da plataforma do Azure armazenam informações em uma conta de armazenamento controlada pelo usuário ou Banco de dados SQL do Azure. Se o recurso de conta ou armazenamento for excluído ou corrompido, isso poderá causar erros graves com o serviço. Nesses casos, é importante manter os backups que permitiriam recriar esses recursos se eles foram excluídos ou corrompidos.

Para Sites do Azure e Serviços Móveis do Azure, você deverá fazer backup e manter os bancos de dados associados. Para o Serviço de Mídia e as Máquinas Virtuais do Azure, você deve manter a conta associada de armazenamento do Azure e todos os recursos nessa conta. Por exemplo, para Máquinas Virtuais, você deve fazer backup e gerenciar os discos de VM no armazenamento de blob do Azure.

 

Serviço/área Lista de Verificação

Armazenamento

  • Regularmente fazer backup de recursos críticos de armazenamento.

  • Usar o recurso de instantâneo para blobs.

Banco de dados

  • Criar backups pontuais usando o comando Cópia de Banco de Dados.

SQL Server no backup de máquinas virtuais (IaaS)

  • Usar técnicas tradicionais de backup e restauração.

  • Criar uma sessão de envio de logs atrasado

Sites da Web

  • Fazer backup e manutenção do banco de dados associado, se houver.

Serviços Móveis

  • Fazer backup e manutenção do banco de dados associado.

Serviços de Mídia

  • Fazer backup e manutenção dos recursos de armazenamento associados.

Máquinas virtuais

  • Fazer backup e manutenção dos discos de VM no armazenamento de blob.

À prova de falhas: diretrizes para arquiteturas resilientes na nuvem diretrizes para criar arquiteturas de nuvem resilientes, diretrizes para implementar essas arquiteturas em tecnologias da Microsoft e receitas para implementar essas arquiteturas para cenários específicos.

Recuperação de desastres e alta disponibilidade para aplicativos do Azure: Uma visão geral detalhada de disponibilidade e recuperação de desastres. Abrange o desafio da replicação manual para dados de referência e transacionais. As seções finais fornecem resumos de tipos diferentes de topologias de recuperação de desastres que abrangem os datacenters do Azure para o nível mais alto de disponibilidade.

Continuidade dos negócios no Banco de dados SQL do Azure: Aborda exclusivamente as técnicas do Azure Banco de dados SQL do Azure para disponibilidade, que são centralizadas primeiro em estratégias de backup e restauração. Se você usar o Banco de dados SQL do Azure em seu serviço de nuvem, deverá examinar este documento e seus recursos relacionados.

Alta disponibilidade e recuperação de desastres para o SQL Server em máquinas virtuais do Azure: aborda as opções de disponibilidade abertas para você quando usa a Infraestrutura como um serviço (IaaS) para hospedar os serviços do banco de dados. Ele discute grupos de disponibilidade AlwaysOn, espelhamento de banco de dados, envio de logs e backup/restauração. Observe que há vários tutoriais na mesma seção que mostram como usar essas técnicas.

Práticas recomendadas para o design de serviços em grande escala em Serviços de Nuvem do Azure: Enfoca o desenvolvimento de arquiteturas de nuvem altamente escaláveis. Muitas das técnicas que você emprega para melhorar a escalabilidade também melhoram a disponibilidade. Além disso, se o aplicativo não puder ser dimensionado em uma carga maior, a escalabilidade se tornará um problema de disponibilidade.

Backup e restauração para o SQL Server em máquinas virtuais do Azure

Mostrar:
© 2014 Microsoft