Exportar (0) Imprimir
Expandir Tudo

Alta disponibilidade e recuperação de desastres para o SQL Server em máquinas virtuais do Azure

Atualizado: junho de 2014

As máquinas virtuais (VMs) do Microsoft Azure com SQL Server podem ajudar a reduzir o custo de uma solução de banco de dados de alta disponibilidade e recuperação de desastres (HADR). A maioria das soluções HADR do SQL Server é suportada em máquinas virtuais do Azure, tanto como soluções somente do Azure quanto como soluções híbridas. Em uma solução somente do Azure, todo o sistema HADR executa em Azure. Em uma configuração híbrida, parte da solução é executada no Azure e a outra parte é executada localmente em sua organização. A flexibilidade do ambiente do Azure permite que você mude parcial ou totalmente para o Azure de forma a atender aos requisitos de orçamento e HADR de seus sistemas de banco de dados do SQL Server.

Depende de você garantir que seu sistema de banco de dados possua as capacidades HADR que o contrato de nível de serviço (SLA) exige. O fato de o Azure fornecer mecanismos de alta disponibilidade, como a recuperação de serviço para serviços em nuvem e a detecção de recuperação de falhas para a função de Máquinas Virtuais, não é garantia de cumprimento do SLA desejado. Esses mecanismos protegem a alta disponibilidade das VMs, mas não a alta disponibilidade de SQL Server em execução dentro das VMs. É possível que haja falha na instância do SQL Server enquanto a VM permanece online e íntegra. Além disso, até mesmo os mecanismos de alta disponibilidade fornecidos pelo Azure podem apresentar tempo de inatividade ocasional e talvez longo das máquinas virtuais devido a eventos como a recuperação de falhas de software ou hardware e atualizações do sistema operacional.

Além disso, Armazenamento Redundante Geográfico (GRS) em Azure, o qual é implementado com um recurso chamado de réplica geográfica, pode não ser uma solução de recuperação de desastres para seus bancos de dados. Como a replicação geográfica envia dados de modo assíncrono, as atualizações recentes podem ser perdidas no caso de desastre. Mais informações referentes a limitações de replicação geográfica são cobertas na seção A replicação geográfica não tem suporte para arquivos de dados e de log em discos separados.

Entre as tecnologias HADR SQL Server suportadas no Azure estão:

É possível combinar as tecnologias para implementar uma solução SQL Server que tenha recursos de alta disponibilidade e de recuperação de desastres. Dependendo da tecnologia usada, uma implantação híbrida pode exigir um túnel VPN com a rede virtual do Azure. As seções a seguir mostram alguns exemplos das arquiteturas de implantação.

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.

 

Tecnologia Arquiteturas de exemplo

Grupos de Disponibilidade AlwaysOn

Todas as réplicas de disponibilidade executadas em VMs do Azure para alta disponibilidade na mesma região. Você precisa configurar um controlador de domínio além das máquinas virtuais do SQL Server, pois o Windows Server Failover Clustering (WSFC) requer um domínio do Ative Directory.

Para obter mais informações, consulte Tutorial: grupos de disponibilidade AlwaysOn no Azure (GUI).

Espelhamento de Banco de Dados

Os servidores principal, de espelho e testemunha, todos executados no mesmo data center do Azure para alta disponibilidade. Você pode implantar usando um controlador de domínio.

Você também pode implantar a mesma configuração de espelhamento de banco de dados sem um controlador de domínio usando certificados do servidor.

Para obter mais informações, consulte Tutorial: espelhamento de banco de dados para alta disponibilidade no Azure.

Você pode ter uma solução de recuperação de desastres para seus bancos de dados do SQL Server no Azure usando os Grupos de Disponibilidade AlwaysOn, o espelhamento de banco de dados ou o backup e a restauração com blobs de armazenamento.

 

Tecnologia Arquiteturas de exemplo

Grupos de Disponibilidade AlwaysOn

Réplicas de disponibilidade executando em múltiplos datacenters em VMs do Azure para recuperação de desastres. A solução de regiões cruzadas protege contra interrupção completa de site.

Em uma região, todas as réplicas deve estar dentro do mesmo serviço de nuvem e na mesma VNet. Como cada região terá uma VNet separada, essas soluções necessitam de conectividade VNet para VNet. Para obter mais informações, consulte Configurar conectividade VNet para VNet.

Espelhamento de Banco de Dados

Os servidores principal e de espelho executados em diferentes data centers para recuperação de desastres. Você deve implantar usando certificados de servidor pois um domínio de diretório ativo não pode abranger vários data centers.

Para obter mais informações, consulte Tutorial: espelhamento de banco de dados para a recuperação de desastres no Azure.

Backup e restauração com o serviço de armazenamento de blob do Azure

Os bancos de dados de produção que têm backup direto no armazenamento de blob em um data center diferente para a recuperação de desastres.

Para obter mais informações, consulte Backup e restauração para o SQL Server em máquinas virtuais 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.

 

Tecnologia Arquiteturas de exemplo

Grupos de Disponibilidade AlwaysOn

Algumas réplicas de disponibilidade executadas em máquinas virtuais do Azure e outras réplicas executadas no local para a recuperação de desastres em sites. O site de produção pode ser local ou estar em um datacenter do Azure.

Como todas as réplicas de disponibilidade devem estar no mesmo cluster WSFC, o cluster WSFC deve abranger as duas redes (um cluster WSFC de várias sub-redes). Esta configuração requer uma conexão VPN entre o Azure e a rede local

Para a recuperação de desastres com êxito de seus bancos de dados, você também deve instalar um controlador de domínio de réplica no site de recuperação de desastres.

Para obter mais informações, consulte Tutorial: AlwaysOn Availability Groups in Hybrid IT.

Espelhamento de Banco de Dados

  • Um parceiro executado em uma máquina virtual do Azure e outro executado no local para a recuperação de desastres em sites usando certificados de servidor. Os parceiros não precisam estar no mesmo domínio do Ative Directory, e nenhuma conexão VPN é necessária.



    Para obter mais informações, consulte Tutorial: espelhamento de banco de dados para a recuperação de desastres em TI híbrida.

  • Um parceiro executado em uma máquina virtual do Azure e outro executado no local no mesmo domínio do Active Directory para a recuperação de desastres em sites. É necessária uma conexão VPN entre a rede virtual do Azure e a rede local.

    Para a recuperação de desastres com êxito de seus bancos de dados, você também deve instalar um controlador de domínio de réplica no site de recuperação de desastres.

Envio de logs

Um servidor executado em uma máquina virtual do Azure e outro executado no local para a recuperação de desastres em sites. O envio de logs depende do compartilhamento de arquivos do Windows; assim, é necessária uma conexão VPN entre a rede virtual do Azure e a rede local.

Para a recuperação de desastres com êxito de seus bancos de dados, você também deve instalar um controlador de domínio de réplica no site de recuperação de desastres.

Para obter mais informações, consulte Tutorial: envio de logs para a recuperação de desastres em TI híbrida.

Backup e restauração com o serviço de armazenamento de blob do Azure

Os bancos de dados de produção locais que têm backup direto no armazenamento de blob do Azure para a recuperação de desastres.

Para obter mais informações, consulte Backup e restauração para o SQL Server em máquinas virtuais do Azure.

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.

Conjuntos de disponibilidade no Azure possibilitam que você coloque os nós de alta disponibilidade em Domínios de Falha (FDs) e Domínios de Atualização (UDs) separados. Para que VMs 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. Para obter mais informações, consulte Gerenciar a disponibilidade de máquinas virtuais.

O serviço DHCP não compatível com RFC no Azure pode levar à falha na criação de certas configurações de cluster WSFC, devido ao nome de rede de cluster que está sendo atribuído um endereço IP duplicado, como o mesmo endereço IP que um dos nós de cluster. Esse é um problema quando você implementa grupos de disponibilidade AlwaysOn, que dependem de recursos do WSFC.

Considere o cenário quando um cluster de dois nós é criado e colocado online:

  1. O cluster fica online; NODE1 solicita que um endereço IP seja atribuído dinamicamente ao nome de rede de cluster.

  2. Nenhum endereço IP, exceto o próprio endereço IP de NODE1, é fornecido pelo serviço DHCP, pois o serviço DHCP reconhece que a solicitação é obtida do próprio NODE1.

  3. O Windows detecta que um endereço duplicado é atribuído a NODE1 e ao nome de rede de cluster, e que o grupo de clusters padrão não fica online.

  4. O grupo de clusters padrão é movido para NODE2, que trata o endereço IP de NODE1 como o endereço IP do cluster e coloca o grupo de clusters padrão online.

  5. Quando NODE2 tenta estabelecer a conectividade com NODE1, os pacotes direcionados a NODE1 nunca deixam NODE2 pois ele toma o endereço IP de NODE1 para si. NODE2 não pode estabelecer conectividade com NODE1; assim, ele perde quorum e fecha o cluster.

  6. Enquanto isso, NODE1 pode enviar pacotes a NODE2, mas NODE2 não pode responder. NODE1 perde quorum e fecha o cluster.

Este cenário pode ser evitado atribuindo um endereço IP estático não usado, como um endereço IP de link local como 169.254.1.1, ao nome de rede de cluster para colocar o nome de rede de cluster online. Para simplificar esse processo, consulte Configurando o cluster de failover do Windows no Azure para grupos de disponibilidade AlwaysOn.

Os tutoriais a seguir para Grupos de Disponibilidade AlwaysOn demonstram como configurar um grupo de disponibilidade em cenários diferentes.

Ouvintes de grupo de disponibilidade têm suporte nas VMs do Azure executando no Windows Server 2008 R2, no Windows Server 2012 e no Windows Server 2012 R2. Esse suporte é possibilitado pelo uso de pontos de extremidade com balanceamento de carga com retorno de servidor direto (DSR) habilitados nas Máquinas Virtuais do Azure que são nós de grupo de disponibilidade. Você deverá seguir as etapas especiais de configuração para ouvintes para trabalhar com aplicativos clientes que estão sendo executados no Azure assim como os que são executados no local. Para obter instruções sobre como configurar um ouvinte, consulte Tutorial: Configuração de ouvinte para Grupos de Disponibilidade AlwaysOn.

Você ainda pode se conectar a cada réplica de disponibilidade separadamente, conectando-se diretamente à instância do serviço. Além disso, como os grupos de disponibilidade AlwaysOn são compatíveis com clientes anteriores de espelhamento de banco de dados, você pode até mesmo se conectar às réplicas de disponibilidade como parceiros de espelhamento de banco de dados, desde que a configuração das réplicas seja semelhante àquela do espelhamento de banco de dados:

  • Uma réplica primária e uma réplica secundária.

  • A réplica secundária está configurada como ilegível (a opção Secundária legível definida como Não)

Uma cadeia de conexão de cliente de exemplo que corresponde à configuração deste espelhamento de banco de dados usando ADO.NET ou o SQL Server Native Client está abaixo:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Para obter mais informações sobre a conectividade de clientes, consulte:

Você deve implantar sua solução HADR com a hipótese que podem haver períodos de tempo com alta latência de rede entre sua rede local e o Azure. Ao implantar réplicas ao Azure, você deve usar a confirmação assíncrona, em vez da confirmação síncrona, para o modo de sincronização. Ao implantar servidores de espelhamento de banco de dados no local e no Azure, use o modo de alto desempenho em vez de usar o modo de alta segurança.

A replicação geográfica em discos do Azure não dá suporte ao arquivo de dados e ao arquivo de log do mesmo banco de dados a ser armazenado em discos separados. O GRS replica as alterações em cada disco de forma independente e assíncrona. Esse mecanismo garante a ordem de gravação em um único disco na cópia replicada geograficamente, mas não em cópias replicadas geograficamente de vários discos. Se você configurar um banco de dados para armazenar o arquivo de dados e o arquivo de log em discos separados, os discos recuperados após um desastre poderão conter uma cópia do arquivo de dados mais recente que a do arquivo de log, interrompendo o log write-ahead no SQL Server e as propriedades ACID de transações. Se você não tiver a opção para desabilitar a replicação geográfica na conta de armazenamento, mantenha todos os dados e arquivos de log para determinado banco de dados no mesmo disco. Se você precisar usar mais de um disco devido ao tamanho do banco de dados, implante uma das soluções de recuperação de desastres listadas anteriormente para garantir a redundância de dados.

Consulte também

A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft