Azure a Nuvem da Microsoft

Quando você migra sua propriedade de dados do SQL Server para a instância gerenciada do Banco de Dados SQL do Azure aderindo a nuvem da Microsoft, o que você obtém não é apenas um bom e antigo SQL Server, protegido e enriquecido com os recursos mais recentes, e sem o ônus de gerenciar backups, aplicar patches e manter a alta disponibilidade.

Você também abre enormes oportunidades para a criação de valor extra a partir dos dados existentes, combinando-os com outras fontes de dados, alavancando ativos somente na nuvem e envolvendo-os em cenários novos e modernos, tudo isso com serviços de nuvem da Microsoft que se integram facilmente e com segurança com instância gerenciada.

Este artigo fornece uma visão geral detalhada das opções disponíveis para integração da instância gerenciada do Banco de Dados SQL do Azure com outros serviços em nuvem da Microsoft e fornece uma visão geral dos cenários comuns habilitados pela integração.

Muitos serviços podem ser integrados à instância gerenciada de várias maneiras, conforme resumido no final do artigo. A descrição detalhada de cada um dos métodos de integração deve ajudá-lo a escolher o ideal para o seu cenário.

Quais são as opções para conectar o serviço de nuvem da Microsoft à instância gerenciada do Banco de Dados SQL?

A instância gerenciada do banco de dados SQL Azure é sempre implantada na rede virtual (VNet) do cliente do Azure e, por padrão, não é acessível de fora da VNet. Isso significa que a conexão à instância gerenciada dos serviços em nuvem da Microsoft pode exigir a execução de etapas específicas que variam dependendo do serviço concreto.

Existem três maneiras de conectar o serviço de nuvem da Microsoft a uma instância gerenciada:

Implantação de serviço na instância gerenciada de hospedagem da VNet ou em uma VNet conectada – ambas as opções reservadas para serviços que podem ser implantados em uma VNet
Gateway de dados local. Não use o atributo “local” aqui literalmente
Aproveitar o endpoint público da instância gerenciada

Vamos examinar os detalhes das três opções e usar os casos que melhor se adequam a cada uma delas.

Implantando serviço na mesma ou VNet conectada

Esta opção está reservada para serviços do Azure que podem ser implantados em uma rede virtual. Ambientes de Serviço de Aplicativo (ASE), Serviço de Kubernetes do Azure (AKS), Cache Redis, Conjuntos de Escala de Máquina Virtual, Tempo de Integração (IR) de SSIS do Azure Data Factory são exemplos desses serviços.

As coisas são simples se tudo for implantado na mesma VNet. Apenas deixe espaço de endereço IP suficiente na VNet para criar uma sub-rede separada para implantar o serviço – a instância gerenciada, necessita de uma sub-rede homogênea e pode compartilhar uma sub-rede apenas com outras instâncias gerenciadas. Obviamente, você precisa definir as regras NSG nas duas sub-redes para permitir o tráfego na porta 1433 entre elas.

Se você planeja implantar o serviço em uma VNet diferente, as duas VNets precisam estar conectadas. Você pode conectar duas VNets por meio do peering da VNet ou gateways VPN.

É importante frizar que o emparelhamento da VNet não pode ser usado para integração com instância gerenciada se as VNets estiverem em diferentes regiões do Azure, devido a uma restrição relacionada ao emparelhamento e ao tipo de balanceador de carga usado para instância gerenciada.

Quando escolher a integração VNet?

Esta é a maneira recomendada de integração. Ela deve ser usada sempre que os serviços envolvidos suportarem a implantação em uma VNet, como a opção de implantação mais segura.

Usando o gateway de dados local

O gateway de dados local atua como uma ponte para fornecer transferência de dados rápida e segura entre suas fontes de dados roteáveis que não são da Internet e vários serviços em nuvem da Microsoft. Esses serviços em nuvem incluem Plataforma de Energia (Power BI, Power Automate, PowerApps), Serviços de Análise do Azure e Aplicativos de Lógica do Azure.

O gateway de dados “local” é um nome um pouco enganador, pois atualmente os serviços em nuvem da Microsoft podem usá-lo para transferência de dados não apenas das fontes de dados locais, mas também dos serviços do Azure implantados na rede virtual, incluindo a instância gerenciada do Banco de Dados SQL Azure.

Azure a Nuvem da Microsoft

Instalando e configurando o gateway de dados local

Para instalar o gateway de dados local em uma máquina virtual no Azure, siga estas instruções passo a passo. Não escolha o modo pessoal, a menos que seja usado apenas para o Power BI e somente por você.

Depois que o gateway de dados local estiver instalado, você precisará configurar o NSG (Network Security Group) na sub-rede que contém a máquina virtual que hospeda o gateway de dados local, para que o gateway possa se comunicar fora da sub-rede.

Você notará que não há tráfego de entrada necessário para o gateway de dados local. Ele se baseia no Barramento de Serviço do Azure para conectividade em nuvem e estabelece conexões de saída para a região do serviço em nuvem da Microsoft.

Obviamente, as regras do Network Security Group (NSG) também precisam habilitar o tráfego de saída para a sub-rede da instância gerenciada. Por conseguinte, as regras NSG na sub-rede da instância gerenciada precisam permitir o tráfego de entrada do gateway de dados local.

Quando escolher o gateway de dados local?

O gateway de dados local é uma solução disponível para o subconjunto de serviços em nuvem da Microsoft. Use-o se você estiver em dia com alguns detalhes:

Você pode usar apenas a autenticação SQL ao conectar-se a instância gerenciada dessa maneira, com credenciais criptografadas e armazenadas no gateway de dados local. As credenciais do usuário do serviço de nuvem da Microsoft não podem ser transmitidas para a instância ou banco de dados por meio do gateway. Isso significa que recursos de banco de dados, como segurança no nível da linha, não podem ser aproveitados com o gateway de dados local.
Você precisa provisionar e manter a máquina virtual para hospedar o gateway de dados local. É prática recomendada atualizar regularmente o gateway de dados local para a versão mais recente.
Pode ser necessário monitorar e otimizar o desempenho do gateway de dados local, dependendo da intensidade da carga de trabalho e da quantidade de dados transferidos.
Existe certa latência introduzida ao consultar a instância gerenciada via gateway de dados local, devido a componentes adicionais no fluxo de dados.

Alavancando o acesso do terminal público à instância gerenciada

Existem muitos serviços em nuvem simplesmente não suportados pelo gateway de dados local.

Também existem cenários em que a criação e a manutenção de gateway de dados local para permitir o acesso de fora da rede virtual consideram muito caro e uma espécie de exagero.

Embora possa parecer contraintuitivo, também existem casos em que as empresas impõem o uso do endpoint público por razões de segurança.

O ponto de extremidade público é um recurso de aceitação da instância gerenciada do Banco de Dados SQL do Azure que permite o acesso a dados da instância gerenciada de fora da VNet.

É um ótimo exemplo da Microsoft ouvindo a voz dos clientes e facilitando o trabalho diário.
Aqui estão alguns dos casos de uso do terminal público:

Integração com serviços em nuvem – o artigo que você está lendo é sobre isso.
Maior taxa de transferência de dados é necessária do que o possível ao usar uma conexão VPN.
As políticas da empresa proíbem o acesso ao serviço PaaS de dentro da rede corporativa.

Acessando instância gerenciada por meio do terminal público

A primeira etapa é ativar o terminal público para a instância gerenciada, pois ela é desativada por padrão.

O acesso a uma instância gerenciada através do terminal público requer o uso de formato de nome de host específico <mi_name> .public. <dns_zone> .database.windows.net e porta fixa 3342.

É necessário um formato de nome de host específico para que possa ser resolvido para o endereço IP público e não o endereço IP privado da instância na VNet.

Segue um exemplo de como fornecer esse nome de host e porta ao usar o SSMS (SQL Server Management Studio) para conectar-se a uma instância gerenciada, usando a autenticação do Azure Active Directory:

Azure a Nuvem da Microsoft

O portal do Azure fornece uma maneira fácil de copiar a cadeia de conexão com destino ao ponto de extremidade público, além da cadeia de conexão de ponto de extremidade privado padrão, para vários drivers de cliente.

Você pode encontrá-lo na guia Strings de conexão do painel do portal do Azure da instância gerenciada:

Se você estiver usando a camada de serviço Crítico de Negócios para sua instância gerenciada, poderá usar o terminal público para conectar-se a uma réplica somente leitura gratuita, simplesmente adicionando a propriedade ApplicationIntent = ReadOnly à sua cadeia de conexão.

Isso é muito útil em cenários em que o serviço de nuvem emite apenas consultas de leitura, pois a carga de trabalho de leitura gerada será descarregada da réplica primária e deixará mais recursos para outras cargas de trabalho de leitura e gravação.

Obviamente, para poder conectar-se a uma instância gerenciada por meio do terminal público ativado, é necessário permitir o tráfego de entrada na porta de destino 3342, através das regras do Network Security Group (NSG) da instância gerenciada de hospedagem de sub-rede.

Mantenha o escopo do intervalo de endereços IP de origem o mais estreito possível. Certifique-se de seguir as instruções detalhadas para proteger o endpoint público.

Quando escolher um endpoint público?

Quando ativado, o terminal público pode ser acessado por qualquer aplicativo ou serviço de nuvem de fora do seu espaço de endereço IP privado que geralmente pode se conectar ao SQL Server, desde que ele use o formato de nome de host e a porta 3342 corretos e se o tráfego de entrada do seu IP público endereço é permitido no NSG.

Ao escolher entre o gateway de dados local (se ele suportar serviço de nuvem concreto) e o terminal público, considere os seguintes aspectos do terminal público:

Terminal público oferece suporte à autenticação do Azure Active Directory, diferentemente do gateway de dados local, limitado à autenticação SQL.
O tipo de conexão redirecionada, que oferece melhorias no desempenho da latência e da taxa de transferência em relação ao tipo de conexão Proxy, não é suportado com o terminal público. Você ainda pode definir o tipo de conexão “Redirecionar” para sua instância, e ele será usado para conexões por meio de terminal privado, mas as conexões públicas de terminal voltarão ao tipo de conexão Proxy.
Não há ouvinte de grupo de failover automático para terminal público. Se você estiver usando grupos de failover automático como um recurso de recuperação de desastre da instância gerenciada, provavelmente também usará o ouvinte de grupo de failover automático para se reconectar com transparência a um novo primário após o failover. No momento, está disponível apenas para o ponto de extremidade privado da instância gerenciada.
Embora a recomendação geral seja bloquear a conectividade de entrada e definir o escopo da faixa de endereços IP de origem o máximo possível, preferencialmente ao nível de endereço IP concreto, nem sempre é possível, pois alguns serviços em nuvem usam uma faixa de endereços mais ampla. Nesse caso, tente reduzir o alcance do intervalo de IP de origem, atualizá-lo sempre e minimizar a complexidade das regras de segurança, aproveitando as etiquetas de serviço.

Sumário

Agora que examinamos os detalhes de todas as três opções para integrar os serviços de nuvem da Microsoft à instância gerenciada do Banco de Dados SQL do Azure, esperamos que você possa escolher a correta para o seu cenário específico.

Existem mais de cem serviços diferentes de nuvem da Microsoft, e novos estão sendo introduzidos de tempos em tempos. Embora a integração com o banco de dados não seja aplicável a todos eles, a manutenção de uma matriz completa de opções de integração iria muito além do escopo de uma postagem de blog. Aqui está o resumo de um subconjunto limitado de serviços comumente usado com instância gerenciada:

Service	Integração VNet	Data Gateway	Terminal Publico
Azure Serviço de aplicativos	Sim*		Sim
Azure Funções	Sim**		Sim
PowerBI		Sim	Sim
Azure Analysis Services		Sim	Sim
Aplicativos de energia		Sim	Sim
Automate de energia		Sim	Sim
Azure Aplicativos lógicos		Sim	Sim
Azure Análise de fluxo			Sim
Dynamics 365 – Serviço de Exportação de Dados			Sim

*Com ambientes de serviço de aplicativos(ASE)

**Plano premium para Funções Azure requerido

Gostou do conteúdo? Compartilhe!