Arquitetura de conectividade de uma Instância Gerenciada de SQL

Aplica-se a:Instância Gerenciada de SQL do Azure

Este artigo descreve a arquitetura de conectividade da Instância Gerenciada de SQL do Azure e como os componentes direcionam o tráfego de comunicação para uma instância gerenciada de SQL.

Visão geral

Na Instância Gerenciada de SQL, uma instância é colocada dentro da rede virtual do Azure e dentro da sub-rede dedicada a instâncias gerenciadas de SQL. A implantação fornece:

• Um endereço IP local de rede virtual seguro (VNet-local).
• A possibilidade de conectar uma rede local a uma Instância Gerenciada de SQL.
• A possibilidade de conectar uma Instância Gerenciada de SQL a um servidor vinculado ou a outro armazenamento de dados local.
• A possibilidade de conectar uma Instância Gerenciada de SQL a recursos do Azure.

Arquitetura de alto nível de conectividade

A Instância Gerenciada de SQL é composta por componentes de serviço hospedados em um conjunto dedicado de máquinas virtuais isoladas agrupadas por atributos de configuração semelhantes e unidas a um cluster virtual. Alguns componentes de serviço são implantados dentro da sub-rede de rede virtual do cliente, enquanto outros serviços operam em um ambiente de rede seguro que a Microsoft gerencia.

Os aplicativos do cliente podem se conectar à Instância Gerenciada de SQL e consultar e atualizar bancos de dados na rede virtual, rede virtual emparelhada ou rede conectada por VPN ou Azure ExpressRoute.

O diagrama a seguir mostra entidades que se conectam a uma Instância Gerenciada de SQL. Ele também mostra os recursos que precisam se comunicar com uma instância gerenciada de SQL. O processo de comunicação descrito na parte inferior do diagrama representa os aplicativos e ferramentas do cliente que se conectam à Instância Gerenciada de SQL como fonte de dados.

A Instância Gerenciada de SQL é uma oferta de plataforma como serviço de locatário único que opera em dois planos: no plano de dados e no painel de controle.

O plano de dados é implantado na sub-rede do cliente para proporcionar compatibilidade, conectividade e isolamento de rede. O plano de dados depende de serviços do Azure, como o Armazenamento do Azure, a ID do Microsoft Entra (antigo Azure Active Directory) para autenticação e serviços de coleta de telemetria. Você verá o tráfego originado em sub-redes que contêm a Instância Gerenciada de SQL indo para esses serviços.

O painel de controle carrega as funções de implantação, gerenciamento e manutenção do serviço principal por meio de agentes automatizados. Esses agentes têm acesso exclusivo aos recursos de computação que operam o serviço. Você não pode usar o Protocolo SSH ou área de trabalho remota para acessar esses hosts. Todas as comunicações do painel de controle são criptografadas e assinadas por meio de certificados. Para verificar a confiabilidade dos participantes da comunicação, a Instância Gerenciada de SQL verifica constantemente esses certificados usando as listas de certificados revogados.

Visão geral da comunicação

Os aplicativos podem se conectar à Instância Gerenciada de SQL por meio de três tipos de pontos de extremidade: de ponto de extremidade local da VNet, de ponto de extremidade público e pontos de extremidade privados. Esses pontos de extremidade exibem propriedades e comportamentos distintos adequados para cenários diferentes.

Ponto de extremidade local da VNet

O ponto de extremidade local da VNet é o meio padrão para se conectar à Instância Gerenciada de SQL. O nome de domínio do ponto de extremidade local da VNet está na forma de <mi_name>.<dns_zone>.database.windows.net. Esse nome de domínio é resolvido para um endereço IP do intervalo de endereços da sub-rede. Use o ponto de extremidade local da VNet para se conectar a uma Instância Gerenciada de SQL em todos os cenários de conectividade padrão. O ponto de extremidade local da VNet aceita conexões na porta 1433.

O endpoint local da VNet dá suporte a tipos de conexão proxy e redirecionamento.

Ao se conectar ao ponto de extremidade local da VNet, sempre use seu nome de domínio e permita o tráfego de entrada nas portas necessárias em todo o intervalo de sub-rede, pois o endereço IP subjacente pode mudar ocasionalmente.

Para localizar o nome de domínio do endpoint local da VNet para uma instância:

• Portal do Azure: No painel Visão geral , na seção Essentials , o valor do host mostra o nome de domínio do ponto de extremidade local da VNet.
• PowerShell: Get-AzSqlInstance -ResourceGroupName <resource-group> -Name <mi-name> mostra o nome de domínio do ponto de extremidade local da VNet como a fullyQualifiedDomainName propriedade.
• CLI do Azure: az sql mi show -g <resource-group> -n <mi-name> mostra o nome de domínio do ponto de extremidade local da VNet como a fullyQualifiedDomainName propriedade.

Para melhorar a segurança, especifique uma conexão criptografada e não confie no certificado. Para obter mais informações, confira Visão geral de segurança.

Ponto de extremidade público

O ponto de extremidade público é um nome de domínio na forma de <mi_name>.public.<dns_zone>.database.windows.net. Esse nome de domínio é resolvido para um endereço IP público acessível da Internet. O ponto de extremidade público é adequado para cenários em que uma instância gerenciada de SQL precisa ser acessível por meio da Internet pública. Por exemplo, ao se conectar a ela de uma rede virtual diferente quando o emparelhamento ou pontos de extremidade privados não estiverem disponíveis. Os pontos de extremidade públicos transportam apenas o tráfego do cliente e não podem ser usados para replicação de dados entre duas instâncias, como grupos de failover ou link de Instância Gerenciada. O ponto de extremidade público aceita conexões na porta 3342.

O endpoint público sempre usa o tipo de conexão proxy, independentemente da configuração do tipo de conexão.

O nome de domínio do ponto de extremidade público de uma instância é igual ao nome do ponto de extremidade local da VNet com o rótulo public inserido entre o nome do host e o restante do domínio: <mi-name>.public.<dns-zone>.database.windows.net.

Ao se conectar ao ponto de extremidade público, sempre use seu nome de domínio e permita o tráfego de entrada na porta 3342 em toda a faixa da sub-rede, pois o endereço IP subjacente pode mudar ocasionalmente.

Saiba como configurar um ponto de extremidade público em Configurar ponto de extremidade público para Instância Gerenciada de SQL do Azure.

Pontos de extremidade privados

Um ponto de extremidade privado é um endereço IP fixo opcional em outra rede virtual que conduz o tráfego para a sua instância gerenciada de SQL. Uma Instância Gerenciada de SQL do Azure pode ter vários pontos de extremidade privados em várias redes virtuais. Os pontos de extremidade privados transportam apenas o tráfego do cliente e não podem ser utilizados para replicação de dados entre duas instâncias, como grupos de failover ou vínculo de Instância Gerenciada. O ponto de extremidade privado aceita conexões na porta 1433.

Os pontos de extremidade privados sempre usam o tipo de conexão proxy, independentemente da configuração de tipo de conexão.

O nome de domínio do ponto de extremidade privado de uma instância é igual ao nome de domínio local da VNet, a menos que o ponto de extremidade tenha sido configurado de forma diferente. Esse é o caso quando o ponto de extremidade privado e o ponto de extremidade local da VNet estão na mesma rede virtual. Para obter mais informações, consulte Configuração da resolução de nomes de domínio para o ponto de extremidade privado.

Ao se conectar a um ponto de extremidade privado, sempre use o nome de domínio, pois ainda não há suporte para a conexão com a Instância Gerenciada de SQL do Azure por meio do seu endereço IP. O endereço IP de um ponto de extremidade privado, no entanto, não é alterado.

Saiba mais sobre pontos de extremidade privados e como configurá-los em Link Privado do Azure para Instância Gerenciada de SQL do Azure.

Arquitetura de conectividade do cluster virtual

O diagrama a seguir mostra o layout conceitual da arquitetura do cluster virtual:

O nome de domínio do ponto de extremidade local VNet é resolvido para o endereço IP privado de um balanceador de carga interno. Embora esse nome de domínio esteja registrado em uma zona pública do Sistema de Nome de Domínio (DNS) e possa ser resolvido publicamente, seu endereço IP pertence ao intervalo de endereços da sub-rede e só pode ser acessado de dentro de sua rede virtual por padrão.

O balanceador de carga direciona o tráfego para um gateway da Instância Gerenciada de SQL. Como várias instâncias gerenciadas de SQL podem ser executadas dentro do mesmo cluster, o gateway usa o nome do host da Instância Gerenciada de SQL, conforme visto na cadeia de conexão, para redirecionar o tráfego para o serviço de mecanismo SQL correto.

O valor para dns-zone é gerado automaticamente quando você cria um cluster. Se um cluster recém-criado hospedar uma instância gerenciada de SQL secundária, ele compartilhará sua ID de zona com o cluster primário.

Requisitos de rede

A Instância Gerenciada de SQL do Azure exige que os aspectos da sub-rede delegada sejam configurados de maneiras específicas, o que você pode obter usando a configuração de sub-rede auxiliada pelo serviço. Além do que o serviço exige, os usuários têm controle total sobre a configuração de rede da sub-rede, como:

• Permitindo ou bloqueando o tráfego em algumas ou em todas as portas.
• Adicionando entradas à tabela de rotas para rotear o tráfego por meio de dispositivos de rede virtual ou um gateway.
• Configurando a resolução DNS personalizada.
• Configurando a interconexão ou uma VPN.

Para atender aos critérios de Configuração de Rede Compatível no Contrato de Nível de Serviço para Os Serviços Online da Microsoft, a rede virtual e a sub-rede na qual a Instância Gerenciada de SQL é implantada devem atender aos seguintes requisitos:

• Sub-rede dedicada: a sub-rede usada pela Instância Gerenciada de SQL só pode ser delegada ao serviço da Instância Gerenciada de SQL. Ela não pode ser uma sub-rede de gateway, e você só pode implantar os recursos da Instância Gerenciada de SQL nela.
• Delegação de sub-rede: A sub-rede da Instância Gerenciada de SQL deve ser delegada ao provedor de recursos de Microsoft.Sql/managedInstances.
• Grupo de segurança de rede: precisa ser associado à sub-rede da Instância Gerenciada de SQL. Você pode usar um grupo de segurança de rede para controlar o acesso ao ponto de extremidade de dados da Instância Gerenciada de SQL filtrando o tráfego de entrada na porta 1433. O serviço automaticamente provisiona as regras e as mantém atualizadas para permitir o fluxo ininterrupto do tráfego de gerenciamento.
• Tabela de rotas: uma tabela de rotas precisa estar associada à sub-rede da Instância Gerenciada de SQL. Você pode adicionar entradas a essa tabela de rotas, por exemplo, para encaminhar o tráfego para locais por meio de um gateway de rede virtual, ou para adicionar a rota 0.0.0.0/0 padrão direcionando todo o tráfego por meio de um dispositivo de rede virtual, como um firewall. A Instância Gerenciada de SQL do Azure provisiona e gerencia automaticamente suas entradas necessárias na tabela de rotas.
• Endereços IP suficientes: a sub-rede da Instância Gerenciada de SQL deve ter pelo menos 32 endereços IP. Para obter mais informações, consulte Determinar o tamanho da sub-rede para Instância Gerenciada de SQL. Você pode implantar instâncias gerenciadas de SQL em uma rede existente depois de configurá-la para atender aos requisitos de rede da Instância Gerenciada de SQL. Caso contrário, crie uma nova rede e sub-rede.
• Permitido pelas políticas do Azure: se você usa o Azure Policy para evitar a criação ou a modificação de recursos no escopo que inclui a sub-rede ou a rede virtual da Instância Gerenciada de SQL, essas políticas não devem impedir a Instância Gerenciada de SQL de gerenciar os recursos internos. Os seguintes recursos precisam ser excluídos dos efeitos de negação da política para operação normal:
  • Recursos do tipo Microsoft.Network/serviceEndpointPolicies, quando o nome do recurso começa com \_e41f87a2\_
  • Todos os recursos do tipo Microsoft.Network/networkIntentPolicies
  • Todos os recursos do tipo Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies
• Bloqueios na rede virtual: bloqueios na rede virtual da sub-rede dedicada, no grupo de recursos pai ou na assinatura podem ocasionalmente interferir nas operações de manutenção e gerenciamento da Instância Gerenciada de SQL. Tome cuidado especial ao usar esses bloqueios.
• registros DNS públicos resolvíveis: Se a rede virtual estiver configurada para usar um servidor DNS personalizado, o servidor DNS deverá ser capaz de resolver registros DNS públicos. Usar recursos como a autenticação do Microsoft Entra pode exigir a resolução de mais nomes de domínio totalmente qualificados (FQDNs). Para obter mais informações, confira Resolver nomes DNS privados na Instância Gerenciada de SQL do Azure.
• Registros DNS necessários: as instâncias gerenciadas por SQL dependem de ter determinados nomes de domínio resolvidos corretamente. Esses nomes de domínio não devem ser sobrescritos em suas redes virtuais, seja via zonas DNS privadas do Azure ou por um servidor DNS personalizado. Caso contrário, as instâncias gerenciadas de SQL não serão implantadas ou poderão ficar indisponíveis. Os domínios a seguir não devem ser substituídos: windows.net, database.windows.net, core.windows.net, blob.core.windows.net, table.core.windows.net, management.core.windows.net, monitoring.core.windows.net, queue.core.windows.net, graph.windows.net, login.microsoftonline.com, login.windows.net, servicebus.windows.nete vault.azure.net. Você ainda pode criar pontos de extremidade privados dentro da rede virtual de uma instância gerenciada de SQL, mesmo para recursos nos domínios mencionados acima. Os pontos de extremidade privados usam um mecanismo DNS que não exige que um servidor DNS local se torne autoritativo para uma zona inteira.
• AzurePlatformDNS: o uso da marca de serviço do AzurePlatformDNS para bloquear a resolução de DNS da plataforma pode tornar as Instâncias Gerenciadas de SQL indisponíveis. Embora a Instância Gerenciada de SQL dê suporte ao DNS definido pelo cliente para a resolução de DNS dentro do mecanismo, há uma dependência do DNS do Azure para operações da plataforma.

Configuração de sub-rede auxiliada por serviço

Para melhorar a segurança, a capacidade de gerenciamento e a disponibilidade do serviço, a Instância Gerenciada de SQL usa a configuração de sub-rede auxiliada pelo serviço e a política de intenção de rede na infraestrutura de rede virtual do Azure para configurar a rede, os componentes associados e a tabela de rotas, a fim de garantir que os requisitos mínimos da Instância Gerenciada de SQL sejam atendidos.

A segurança da rede e as regras da tabela de rotas configuradas automaticamente são visíveis para o cliente e anotadas com um destes prefixos:

• Microsoft.Sql-managedInstances_UseOnly_mi- para regras e rotas obrigatórias
• Microsoft.Sql-managedInstances_UseOnly_mi-optional- para regras e rotas opcionais

Para obter detalhes adicionais, examine a configuração de sub-rede auxiliada pelo serviço.

Para obter mais informações sobre a arquitetura de conectividade e o tráfego de gerenciamento, confira a seção Arquitetura de conectividade de alto nível.

Restrições de rede

As seguintes restrições em recursos de rede virtual e tráfego estão em vigor:

• Sub-redes privadas: atualmente, não há suporte para a implantação de instâncias gerenciadas de SQL em sub-redes privadas (em que o acesso de saída padrão está desabilitado).
• Criptografia VNet: Atualmente, não há suporte para a implantação e operação de instâncias gerenciadas de SQL em redes virtuais em que a criptografia de Rede Virtual do Azure está habilitada.
• Database Mail para retransmissões SMTP externas na porta 25: o envio de Database Mail pela porta 25 para serviços de hospedagem de email externos só está disponível para determinados tipos de assinatura no Microsoft Azure. Instâncias em outros tipos de assinatura devem usar uma porta diferente (por exemplo, 587) para contatar retransmissões SMTP externas. Caso contrário, as instâncias podem falhar ao entregar Database Mail. Para saber mais, confira Solucionar problemas de conectividade de SMTP de saída no Azure.
• Emparelhamento da Microsoft: habilitar o Emparelhamento da Microsoft em circuitos do ExpressRoute emparelhados direta ou transitivamente com a rede virtual em que a Instância Gerenciada de SQL reside afeta o fluxo de tráfego entre componentes da Instância Gerenciada de SQL na rede virtual e os serviços dos quais ela depende. Pode resultar em problemas de disponibilidade. É esperado que haja falha em implantações da Instância Gerenciada de SQL na rede virtual que já tenham o emparelhamento da Microsoft habilitado.
• Emparelhamento de rede virtual global: a conectividade de emparelhamento de rede virtual entre regiões do Azure não funciona para instâncias gerenciadas de SQL que são colocadas em sub-redes que foram criadas antes de 9 de setembro de 2020.
• Emparelhamento de rede virtual – configuração: ao estabelecer o emparelhamento de rede virtual entre redes virtuais que contêm sub-redes com instâncias gerenciadas de SQL, essas sub-redes devem usar tabelas de rotas diferentes e NSG (grupos de segurança de rede). A reutilização da tabela de rotas e do NSG em duas ou mais sub-redes participantes do emparelhamento de rede virtual causará problemas de conectividade em todas as sub-redes que usam essas tabelas de rotas ou NSG, além de levar à falha das operações de gerenciamento da Instância Gerenciada de SQL.
• Gateway nat: no momento, não há suporte para o uso da NAT de Rede Virtual do Azure para controlar a conectividade de saída com um endereço IP público específico.
• IPv6 para rede virtual do Azure: é esperado que haja falha em implantações de Instância Gerenciada de SQL em redes virtuais IPv4/IPv6 de pilha dupla. Associar um grupo de segurança de rede ou uma tabela de rotas a UDRs (rotas definidas pelo usuário) que contenham prefixos de endereço IPv6 para uma sub-rede da Instância Gerenciada de SQL torna a Instância Gerenciada de SQL indisponível. Além disso, adicionar prefixos de endereço IPv6 a um grupo de segurança de rede ou UDR que já está associado a uma sub-rede de Instância Gerenciada de SQL torna a Instância Gerenciada de SQL indisponível. É esperado que haja falha em implantações de uma Instância Gerenciada de SQL em sub-redes com um grupo de segurança de rede e UDR que já tenham prefixos IPv6.
• TLS 1.2 é imposta em conexões de saída: a partir de janeiro de 2020, a Microsoft impôs o TLS 1.2 para tráfego interno de todos os serviços do Azure. Na Instância Gerenciada de SQL, isso causava a imposição do TLS 1.2 nas conexões de saída usadas para replicação e nas conexões de servidor vinculado com o SQL Server. Se você usar uma versão do SQL Server anterior a 2016 com a Instância Gerenciada de SQL, certifique-se de aplicar as atualizações específicas do TLS 1.2.
• Fallback interno para o DNS do Azure: as instâncias gerenciadas de SQL dependem do funcionamento da resolução DNS em suas redes virtuais. Se a rede virtual de uma instância gerenciada de SQL estiver configurada para usar servidores DNS personalizados e uma solicitação DNS emitida para servidores DNS personalizados não for concluída em um determinado intervalo (de 1 a 2 segundos), a instância gerenciada de SQL repetirá a solicitação contra o DNS do Azure nessa rede virtual.

Conteúdo relacionado

• Confira O que é a Instância Gerenciada de SQL do Azure? para ter uma visão geral.
• Para saber mais, consulte:
  • Arquitetura de cluster virtual.
  • Configuração de sub-rede auxiliada pelo serviço.
  • Configurar uma nova rede virtual do Azure ou uma rede virtual existente do Azure na qual você possa implantar uma Instância Gerenciada de SQL.
  • Calcule o tamanho da sub-rede na qual você deseja implantar uma Instância Gerenciada de SQL.
• Saiba como criar uma instância gerenciada de SQL:
  • No portal do Azure.
  • Usando o PowerShell.
  • Usando um modelo do Azure Resource Manager.
  • Ao usar um modelo do Azure Resource Manager com um jumpbox e o SQL Server Management Studio.