Continuidade de negócios e HADR para SQL Server em Máquinas Virtuais do Azure
Aplica-se a:
SQL Server na VM do Azure
Continuidade de negócios significa continuar seus negócios no caso de um desastre, planejar a recuperação e garantir que seus dados estejam altamente disponíveis. O SQL Server em Máquinas Virtuais do Azure pode ajudar a reduzir o custo de uma solução de banco de dados HADR (recuperação de desastres e alta disponibilidade).
A maioria das soluções HADR do SQL Server tem suporte em máquinas virtuais (VMs), como soluções híbridas e somente do Azure. Em uma solução somente do Azure, todo o sistema HADR é executado no 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 completamente para o Azure para satisfazer os requisitos de orçamento e HADR de seus sistemas de banco de dados do SQL Server.
Este artigo compara e contrasta as soluções de continuidade de negócios disponíveis para o SQL Server em VMs do Azure.
Descrição geral
Cabe a você garantir que seu sistema de banco de dados tenha os recursos HADR exigidos pelo contrato de nível de serviço (SLA). O fato de o Azure fornecer mecanismos de alta disponibilidade, como recuperação de serviços para serviços de nuvem e deteção de recuperação de falhas para máquinas virtuais, por si só não garante que você possa atender ao SLA. Embora esses mecanismos ajudem a proteger a alta disponibilidade da máquina virtual, eles não protegem a disponibilidade do SQL Server em execução dentro da VM.
É possível que a instância do SQL Server falhe enquanto a VM estiver online e íntegra. Mesmo os mecanismos de alta disponibilidade fornecidos pelo Azure permitem o tempo de inatividade das VMs devido a eventos como recuperação de falhas de software ou hardware e atualizações do sistema operacional.
O armazenamento com redundância geográfica (GRS) no Azure é implementado com um recurso chamado replicação geográfica. O GRS pode não ser uma solução adequada de recuperação de desastres para seus bancos de dados. Como a replicação geográfica envia dados de forma assíncrona, as atualizações recentes podem ser perdidas em caso de desastre. Mais informações sobre limitações de replicação geográfica são abordadas na seção de suporte à replicação geográfica.
Nota
Agora é possível elevar e mudar sua instância de cluster de failover e a solução de grupo de disponibilidade para o SQL Server em VMs do Azure usando o Azure Migrate.
Arquiteturas de implantação
O Azure dá suporte a estas tecnologias do SQL Server para continuidade de negócios:
- Grupos de disponibilidade Always On
- Instâncias de cluster de failover (FCIs) Always On
- Envio de logs
- Backup e restauração do SQL Server com o armazenamento de Blob do Azure
- Espelhamento de banco de dados - Preterido no SQL Server 2016
- Azure Site Recovery
Você pode combinar as tecnologias para implementar uma solução do SQL Server que tenha recursos de alta disponibilidade e 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 de arquiteturas de implantação.
Somente Azure: soluções de alta disponibilidade
Você pode ter uma solução de alta disponibilidade para o SQL Server em um nível de banco de dados com grupos de disponibilidade Always On. Você também pode criar uma solução de alta disponibilidade em nível de instância com instâncias de cluster de failover Always On. Para obter proteção adicional, você pode criar redundância em ambos os níveis criando grupos de disponibilidade em instâncias de cluster de failover.
| Tecnologia | Arquiteturas de exemplo |
|---|---|
| Grupos de disponibilidade | As réplicas de disponibilidade em execução em VMs do Azure na mesma região fornecem alta disponibilidade. Você precisa configurar uma VM de controlador de domínio, porque o cluster de failover do Windows requer um domínio do Ative Directory. Para maior redundância e disponibilidade, as VMs do Azure podem ser implantadas em diferentes zonas de disponibilidade, conforme documentado na visão geral do grupo de disponibilidade.  Para começar, revise o tutorial do grupo de disponibilidade. |
| Instâncias de cluster de failover | Há suporte para instâncias de cluster de failover em VMs do SQL Server. Como o recurso FCI requer armazenamento compartilhado, cinco soluções funcionarão com o SQL Server em VMs do Azure: - Usando discos compartilhados do Azure para Windows Server 2019. Os discos gerenciados compartilhados são um produto do Azure que permite anexar um disco gerenciado a várias máquinas virtuais simultaneamente. As VMs no cluster podem ler ou gravar no disco anexado com base na reserva escolhida pelo aplicativo clusterizado por meio de Reservas Persistentes SCSI (SCSI PR). O SCSI PR é uma solução de armazenamento padrão do setor usada por aplicativos executados em uma SAN (Storage Area Network, rede de armazenamento de dados) local. Habilitar o SCSI PR em um disco gerenciado permite migrar esses aplicativos para o Azure como estão. - Usando o Storage Spaces Direct (S2D) para fornecer uma SAN virtual baseada em software para Windows Server 2016 e posterior. - Usando um compartilhamento de arquivos Premium para Windows Server 2012 e posterior. As partilhas de ficheiros Premium são suportadas por SSD, têm latência consistentemente baixa e são totalmente suportadas para utilização com FCI. - Utilização de armazenamento suportado por uma solução de parceiro para clustering. Para obter um exemplo específico que usa o SIOS DataKeeper, consulte a entrada de blog Failover clustering e SIOS DataKeeper. - Usando armazenamento de bloco compartilhado para um destino iSCSI remoto via Azure ExpressRoute. Por exemplo, o NPS (NetApp Private Storage) expõe um destino iSCSI via ExpressRoute com Equinix para VMs do Azure. Para soluções de armazenamento compartilhado e replicação de dados de parceiros da Microsoft, entre em contato com o fornecedor para quaisquer problemas relacionados ao acesso a dados em failover. Para começar, prepare sua VM para FCI |
Somente Azure: soluções de recuperação de desastres
Você pode ter uma solução de recuperação de desastres para seus bancos de dados do SQL Server no Azure usando grupos de disponibilidade, espelhamento de banco de dados ou backup e restauração com blobs de armazenamento.
| Tecnologia | Arquiteturas de exemplo |
|---|---|
| Grupos de disponibilidade | Réplicas de disponibilidade em execução em vários datacenters em VMs do Azure para recuperação de desastres. Esta solução entre regiões ajuda a proteger contra uma interrupção completa do local. Dentro de uma região, todas as réplicas devem estar dentro do mesmo serviço de nuvem e da mesma rede virtual. Como cada região terá uma rede virtual separada, essas soluções exigem conectividade de rede para rede. Para obter mais informações, consulte Configurar uma conexão de rede para rede usando o portal do Azure. Para obter instruções detalhadas, consulte Configurar um grupo de disponibilidade Always On do SQL Server em diferentes regiões do Azure. |
| Espelhamento de banco de dados | Principal e espelho e servidores em execução em diferentes datacenters para recuperação de desastres. Você deve implantá-los usando certificados de servidor.
|
| Backup e restauração com o armazenamento de Blob do Azure | Backup de bancos de dados de produção diretamente para o armazenamento de Blob em um datacenter diferente para recuperação de desastres.
Para obter mais informações, consulte Backup e restauração do SQL Server em VMs do Azure. |
| Replicar e fazer failover do SQL Server para o Azure com o Azure Site Recovery | Instância do SQL Server de produção em um datacenter do Azure replicada diretamente para o Armazenamento do Azure em um datacenter diferente do Azure para recuperação de desastres.
Para obter mais informações, consulte Proteger o SQL Server usando a recuperação de desastres do SQL Server e Azure Site Recovery. |
TI híbrida: soluções de recuperação de desastres
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íbrido usando grupos de disponibilidade, espelhamento de banco de dados, envio de logs e backup e restauração com o armazenamento de Blob do Azure.
| Tecnologia | Arquiteturas de exemplo |
|---|---|
| Grupos de disponibilidade | Algumas réplicas de disponibilidade em execução em VMs do Azure e outras réplicas em execução no local para recuperação de desastres entre sites. O site de produção pode ser local ou em um datacenter do Azure.
Como todas as réplicas de disponibilidade devem estar no mesmo cluster de failover, o cluster deve abranger ambas as redes (um cluster de failover de várias sub-redes). Essa configuração requer uma conexão VPN entre o Azure e a rede local. Para uma recuperação de desastres bem-sucedida de seus bancos de dados, você também deve instalar um controlador de domínio de réplica no local de recuperação de desastres. Para começar, revise o tutorial do grupo dedisponibilidade. |
| Espelhamento de banco de dados | Um parceiro em execução em uma VM do Azure e o outro executando no local para recuperação de desastres entre 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.
Outro cenário de espelhamento de banco de dados envolve um parceiro em execução em uma VM do Azure e o outro executando localmente no mesmo domínio do Ative Directory para recuperação de desastres entre sites. É necessária uma ligação VPN entre a rede virtual do Azure e a rede local. Para uma recuperação de desastres bem-sucedida de seus bancos de dados, você também deve instalar um controlador de domínio de réplica no local de recuperação de desastres. |
| Envio de logs | Um servidor em execução em uma VM do Azure e o outro em execução local para recuperação de desastres entre sites. O envio de logs depende do compartilhamento de arquivos do Windows, portanto, uma conexão VPN entre a rede virtual do Azure e a rede local é necessária.
Para uma recuperação de desastres bem-sucedida de seus bancos de dados, você também deve instalar um controlador de domínio de réplica no local de recuperação de desastres. |
| Backup e restauração com o armazenamento de Blob do Azure | Backup de bancos de dados de produção locais diretamente no armazenamento de Blob do Azure para recuperação de desastres.
Para obter mais informações, consulte Backup e restauração do SQL Server em máquinas virtuais do Azure. |
| Replicar e fazer failover do SQL Server para o Azure com o Azure Site Recovery | Instância do SQL Server de produção local replicada diretamente para o Armazenamento do Azure para recuperação de desastres.
Para obter mais informações, consulte Proteger o SQL Server usando a recuperação de desastres do SQL Server e Azure Site Recovery. |
Réplica de DR gratuita no Azure
Se você tiver o Software Assurance, poderá implementar planos híbridos de recuperação de desastres (DR) com o SQL Server sem incorrer em custos adicionais de licenciamento para a instância passiva de recuperação de desastres. Você também se qualifica para réplicas de DR sem licença com licenciamento pré-pago se todas as réplicas estiverem hospedadas no Azure.
Por exemplo, você pode ter dois secundários passivos gratuitos quando todas as três réplicas são hospedadas no Azure:
Ou você pode configurar um ambiente de failover híbrido, com um primário licenciado local, um passivo livre para HA, um passivo livre para DR local e um passivo livre para DR no Azure:
Para obter mais informações, consulte os termos de licenciamento do produto.
Para habilitar esse benefício, vá para o recurso de máquina virtual do SQL Server. Selecione Configurar em Configurações e escolha a opção HA/DR em Licença do SQL Server. Marque a caixa de seleção para confirmar se essa VM do SQL Server será usada como uma réplica passiva e selecione Aplicar para salvar suas configurações. Quando todas as três réplicas são hospedadas no Azure, os clientes pré-pagos também têm direito a usar o tipo de licença HA/DR .
Considerações importantes para o HADR do SQL Server no Azure
As VMs, o armazenamento e a rede do Azure têm características operacionais diferentes de uma infraestrutura de TI local não virtualizada. Uma implementação bem-sucedida de uma solução HADR SQL Server no Azure requer que você entenda essas diferenças e projete sua solução para acomodá-las.
Nós de alta disponibilidade em um conjunto de disponibilidade
Os conjuntos de disponibilidade no Azure permitem que você coloque os nós de alta disponibilidade em domínios de falha separados e atualize domínios. A plataforma Azure atribui um domínio de atualização e um domínio de falha a cada máquina virtual em seu conjunto de disponibilidade. Essa configuração em um datacenter garante que, durante um evento de manutenção planejado ou não planejado, pelo menos uma máquina virtual esteja disponível e atenda ao SLA do Azure de 99,95%.
Para configurar uma configuração de alta disponibilidade, coloque todas as máquinas virtuais participantes do SQL Server no mesmo conjunto de disponibilidade para evitar perda de aplicativos ou dados durante um evento de manutenção. Somente nós no mesmo serviço de nuvem podem participar do mesmo conjunto de disponibilidade. Para obter mais informações, veja Gerir a disponibilidade das máquinas virtuais.
Nós de alta disponibilidade em uma zona de disponibilidade
As zonas de disponibilidade são locais físicos exclusivos dentro de uma região do Azure. Cada zona consiste em um ou mais datacenters equipados com energia, resfriamento e rede independentes. A separação física de zonas de disponibilidade dentro de uma região ajuda a proteger aplicativos e dados contra falhas de datacenter, garantindo que pelo menos uma máquina virtual esteja disponível e atenda ao SLA do Azure de 99,99%.
Para configurar a alta disponibilidade, coloque as máquinas virtuais participantes do SQL Server espalhadas pelas zonas de disponibilidade na região. Haverá encargos adicionais para transferências de rede para rede entre zonas de disponibilidade. Para obter mais informações, consulte Zonas de disponibilidade.
Latência de rede em TI híbrida
Implante sua solução HADR com a suposição de que pode haver períodos de alta latência de rede entre sua rede local e o Azure. Ao implantar réplicas no Azure, use 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 do modo de alta segurança.
Consulte as práticas recomendadas de configuração do HADR para configurações de cluster e HADR que podem ajudar a acomodar o ambiente de nuvem.
Suporte à replicação geográfica
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 serem armazenados 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 seu arquivo de dados e seu arquivo de log em discos separados, os discos recuperados após um desastre podem conter uma cópia mais atualizada do arquivo de dados do que o arquivo de log, o que quebra o log write-ahead no SQL Server e as propriedades ACID (atomicidade, consistência, isolamento e durabilidade) das transações.
Se você não tiver a opção de desabilitar a replicação geográfica na conta de armazenamento, mantenha todos os dados e arquivos de log de um 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.
Próximos passos
Decida se um grupo de disponibilidade ou uma instância de cluster de failover é a melhor solução de continuidade de negócios para sua empresa. Em seguida, revise as práticas recomendadas para configurar seu ambiente para alta disponibilidade e recuperação de desastres.