Preparar seu ambiente para um link - Instância Gerenciada SQL do Azure

Aplica-se a:Azure SQL Managed Instance

Este artigo ensina como preparar o seu ambiente para um link de Instância Gerenciada , para que você possa replicar entre o SQL Server instalado no Windows ou Linux e a Azure SQL Managed Instance.

Pré-requisitos

Para criar um link entre o SQL Server e a Instância Gerenciada SQL do Azure, você precisa dos seguintes pré-requisitos:

• Uma assinatura ativa do Azure. Se tu não tiveres uma, cria uma conta gratuita.
• Uma versão com suporte do SQL Server com a atualização de serviço necessária.
• Instância Gerenciada SQL do Azure. Comece agora se não tiver um.
• Um servidor que você pretende que seja o primário inicial. Essa escolha determina de onde você deve criar o link.
  • A configuração de um link de uma instância gerenciada do SQL primária para uma secundária do SQL Server 2025 só é suportada se as instâncias gerenciadas do SQL estiverem configuradas com a política de atualização do SQL Server 2025.
  • A configuração de um link de uma Instância Gerenciada do SQL primária para uma secundária do SQL Server 2022 só é suportada a partir do SQL Server 2022 CU10 e das instâncias gerenciadas do SQL configuradas com a política de atualização do SQL Server 2022.

Permissões

Para o SQL Server, você deve ter permissões de sysadmin.

Para a Instância Gerida SQL do Azure, deve ser membro do Colaborador da Instância Gerida SQLou ter as seguintes permissões para uma função personalizada:

Preparar sua instância do SQL Server

Para preparar sua instância do SQL Server, você precisa validar que:

• Estás na versão mínima suportada.
• Criaste uma chave mestra da base de dados na master base de dados.
• Ativaste a funcionalidade de grupos de disponibilidade.
• Adicionaste as bandeiras de rastreamento corretas no arranque.

Você precisa reiniciar o SQL Server para que essas alterações entrem em vigor.

Instalar atualizações de serviço

Verifique se sua versão do SQL Server tem a atualização de serviço apropriada instalada, conforme listado na tabela de suporte da versão . Se precisar instalar atualizações, reinicie a instância do SQL Server durante a atualização.

Para verificar sua versão do SQL Server, execute o seguinte script Transact-SQL (T-SQL) no SQL Server:

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

Criar uma chave mestra de banco de dados no banco de dados mestre

A ligação utiliza certificados para encriptar autenticação e comunicação entre SQL Server e SQL Managed Instance. A chave mestra da base de dados protege os certificados usados pela ligação. Se já tiveres uma chave mestra de base de dados, podes saltar este passo.

Crie a chave mestra na base de dados master. Insira sua senha no lugar de <strong_password> no script a seguir e mantenha-a em um local confidencial e seguro. Execute este script T-SQL no SQL Server:

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

Para certificar-se de que você tem a chave mestra do banco de dados, use o seguinte script T-SQL no SQL Server:

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

Habilitar grupos de disponibilidade

O recurso de link depende do recurso de grupos de disponibilidade Always On, que é desabilitado por padrão. Para obter mais informações, consulte Habilitar o recurso de grupos de disponibilidade Always On.

Para confirmar se o recurso de grupos de disponibilidade está habilitado, execute o seguinte script T-SQL no SQL Server:

-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
    @IsHadrEnabled as 'Is HADR enabled',
    CASE @IsHadrEnabled
        WHEN 0 THEN 'Availability groups DISABLED.'
        WHEN 1 THEN 'Availability groups ENABLED.'
        ELSE 'Unknown status.'
    END
    as 'HADR status'

Se o recurso de grupos de disponibilidade não estiver habilitado, siga estas etapas para habilitá-lo:

1. Abra SQL Server Configuration Manager.

2. Selecione Serviços do SQL Server no painel esquerdo.

3. Clique com o botão direito do mouse no serviço SQL Server e selecione Propriedades.

   

4. Vá para a aba Always On Availability Groups.

5. Marque a caixa de seleção Ativar grupos de disponibilidade Always On e selecione OK.

   

   • Se estiver usando o SQL Server 2016 (13.x) e se a opção Habilitar Grupos de Disponibilidade Sempre Ativos estiver desabilitada com a mensagem This computer is not a node in a failover cluster, siga as etapas adicionais descritas no link Preparar pré-requisitos do SQL Server 2016 - Instância Gerenciada do Azure SQL. Depois de concluir essas outras etapas, volte e tente novamente esta etapa.

6. Selecione OK na caixa de diálogo.

7. Reinicie o serviço SQL Server.

Ativar sinalizadores de rastreamento de inicialização

Para otimizar o desempenho do seu link, recomendamos ativar os seguintes sinalizadores de rastreamento na inicialização:

• -T1800: Esse sinalizador de rastreamento otimiza o desempenho quando os arquivos de log das réplicas primária e secundária em um grupo de disponibilidade são hospedados em discos com tamanhos de setor diferentes, como 512 bytes e 4 KB. Se as réplicas primária e secundária tiverem um tamanho de setor de disco de 4 KB, esse sinalizador de rastreamento não será necessário. Para obter mais informações, consulte KB3009974.
• -T9567: Este sinalizador de rastreamento permite a compactação do fluxo de dados para grupos de disponibilidade durante a propagação automática. A compressão aumenta a carga no processador, mas pode reduzir significativamente o tempo de transferência durante o seeding.

Para habilitar esses sinalizadores de rastreamento na inicialização, use as seguintes etapas:

1. Abra o SQL Server Configuration Manager.

2. Selecione Serviços do SQL Server no painel esquerdo.

3. Clique com o botão direito do mouse no serviço SQL Server e selecione Propriedades.

   

4. Vá para a guia Parâmetros de inicialização. Em Especifique um parâmetro de inicialização, digite e selecione Adicionar para adicionar o parâmetro de inicialização. Em seguida, digite -T9567 e selecione Adicionar para adicionar o outro sinalizador de rastreamento. Selecione Aplicar para salvar as alterações.

   

5. Selecione OK para fechar a janela Propriedades.

Para obter mais informações, consulte a sintaxe para habilitar sinalizadores de rastreamento.

Reinicie o SQL Server e valide a configuração

Depois de garantir que você está em uma versão com suporte do SQL Server, habilitar o recurso Grupos de disponibilidade Always On e adicionar seus sinalizadores de rastreamento de inicialização, reinicie a instância do SQL Server para aplicar todas estas alterações:

1. Abra SQL Server Configuration Manager.

2. Selecione Serviços do SQL Server no painel esquerdo.

3. Clique com o botão direito do mouse no serviço SQL Server e selecione Reiniciar.

   

Após a reinicialização, execute o seguinte script T-SQL no SQL Server para validar a configuração da sua instância do SQL Server:

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

Sua versão do SQL Server deve ser uma das versões com suporte aplicadas com as atualizações de serviço apropriadas, o recurso de grupos de disponibilidade Always On deve estar habilitado e você deve ter os sinalizadores de rastreamento -T1800 e -T9567 habilitados. A captura de tela a seguir é um exemplo do resultado esperado para uma instância do SQL Server configurada corretamente:

Configurar a conectividade de rede

Para que o link funcione, você deve ter conectividade de rede entre o SQL Server e a Instância Gerenciada do SQL. A opção de rede escolhida depende se sua instância do SQL Server está ou não em uma rede do Azure.

SQL Server em Máquinas Virtuais do Azure

Implementar SQL Server em Máquinas Virtuais Azure na mesma rede virtual Azure que aloja a Instância Gerida SQL é o método mais simples, porque a conectividade de rede existe automaticamente entre as duas instâncias. Para obter mais informações, consulte Guia de início rápido: configurar uma VM do Azure para se conectar à Instância Gerenciada SQL do Azure.

Se a sua instância SQL Server no Azure Virtual Machines estiver numa rede virtual diferente da sua instância gerida por SQL, precisa de ligar as duas redes virtuais. As redes virtuais não precisam de estar na mesma subscrição para que este cenário funcione.

Existem duas opções para ligar redes virtuais:

• Emparelhamento de Rede Virtual do Azure
• Gateway VPN VNet-para-VNet (portal do Azure, PowerShell, Azure CLI)

O peering é preferível porque utiliza a rede de backbone da Microsoft. Assim, do ponto de vista da conectividade, não há diferença notória na latência entre máquinas virtuais numa rede virtual peered e na mesma rede virtual. O peering de redes virtuais é permitido entre redes na mesma região. O emparelhamento de rede virtual global é suportado para instâncias hospedadas em sub-redes que foram criadas após 22 de setembro de 2020. Para obter mais informações, consulte Perguntas frequentes (FAQ).

SQL Server fora do Azure

Se sua instância do SQL Server estiver hospedada fora do Azure, estabeleça uma conexão VPN entre o SQL Server e a Instância Gerenciada do SQL usando uma destas opções:

• Conexão VPN site a site
• conexão do Azure ExpressRoute

Portas de rede entre os ambientes

Independentemente do mecanismo de conectividade, há requisitos que devem ser atendidos para que o tráfego de rede flua entre os ambientes:

As regras do NSG (Grupo de Segurança de Rede) na sub-rede que hospeda a Instância Gerenciada SQL precisam permitir:

• Porta de entrada 5022 e intervalo de portas 11000-11999 para receber tráfego do IP de origem do SQL Server
• Porta de saída 5022 para enviar tráfego para o IP de destino do SQL Server

Todos os firewalls na rede que hospeda o SQL Server e o sistema operacional host precisam permitir:

• Porta de entrada 5022 aberta para receber tráfego do intervalo de IP de origem da sub-rede MI /24 (por exemplo, 10.0.0.0/24)
• As portas de saída 5022 e o intervalo de portas 11000-11999 foram abertos para enviar tráfego para o intervalo IP de destino da sub-rede MI (exemplo 10.0.0.0/24)

A tabela a seguir descreve as ações de porta para cada ambiente:

Para abrir portas no Firewall do Windows, use o seguinte script do PowerShell no sistema operacional host Windows da instância do SQL Server:

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

O diagrama a seguir mostra um exemplo de um ambiente de rede local, indicando que todos os firewalls no ambiente precisam ter portas abertas, incluindo o firewall do sistema operacional que hospeda o SQL Server e quaisquer firewalls e/ou gateways corporativos:

Adicionar URLs à lista de permissões

Dependendo das configurações de segurança da rede, pode ser necessário adicionar URLs à sua lista de permissões para o FQDN da Instância Gerenciada SQL e alguns dos pontos de extremidade de Gerenciamento de Recursos usados pelo Azure.

A lista a seguir lista os recursos que devem ser adicionados à sua lista de permissões:

• O nome de domínio totalmente qualificado (FQDN) da sua Instância Gerenciada SQL. Por exemplo: managedinstance.a1b2c3d4e5f6.database.windows.net.
• Autoridade Microsoft Entra
• ID de recurso do Microsoft Entra Endpoint
• Ponto de extremidade do Gestor de Recursos
• Endereço de Serviço

Siga os passos na seção Configurar o SSMS para nuvens governamentais para aceder à interface Ferramentas no SQL Server Management Studio (SSMS) e identificar as URLs específicas dos recursos na sua nuvem que precisa adicionar à sua lista de permissões.

Testar a conectividade de rede

A conectividade de rede bidirecional entre o SQL Server e a Instância Gerenciada do SQL é necessária para que o link funcione. Depois de abrir portas no lado do SQL Server e configurar uma regra NSG no lado da Instância Gerenciada SQL, teste a conectividade usando o SQL Server Management Studio (SSMS) ou o Transact-SQL.

Teste a rede criando um trabalho temporário do SQL Agent no SQL Server e na Instância Gerenciada do SQL para verificar a conexão entre as duas instâncias. Quando se utiliza a Ferramenta Verificadora de Rede no SSMS, a tarefa é criada automaticamente para si e eliminada após a conclusão do teste. Você precisará excluir manualmente o trabalho do SQL Agent se testar sua rede usando T-SQL.

Para usar o SQL Agent para testar a conectividade de rede, você precisa dos seguintes requisitos:

• O utilizador que realiza o teste deve ter permissões para criar uma tarefa (seja como sysadmin ou pertencer à função SQLAgentOperator para ) tanto para o SQL Server como para a Instância Gerenciada do SQL.
• O serviço SQL Server Agent deve estar executando no SQL Server. Como o Agente está ativado por padrão na Instância Gerenciada SQL, nenhuma ação adicional é necessária.

Considere o seguinte:

• Para evitar falsos negativos, todos os firewalls ao longo do caminho da rede devem permitir o tráfego do Protocolo de Mensagens de Controlo da Internet (ICMP).
• Para evitar falsos positivos, todos os firewalls ao longo do caminho de rede devem permitir o tráfego no protocolo proprietário SQL Server UCS. Bloquear o protocolo pode levar a um teste de ligação bem-sucedido, mas a ligação não se cria.
• Configurações avançadas de firewall com guardas ao nível de pacotes precisam de ser devidamente configuradas para permitir o tráfego entre SQL Server e SQL Managed Instance.

-- Run on SQL Server
-- Create the certificate needed for the test endpoint
USE MASTER
CREATE CERTIFICATE TEST_CERT
WITH SUBJECT = N'Certificate for SQL Server',
EXPIRY_DATE = N'3/30/2051'
GO

-- Create the test endpoint on SQL Server
USE MASTER
CREATE ENDPOINT TEST_ENDPOINT
    STATE=STARTED
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE TEST_CERT,
        ENCRYPTION = REQUIRED ALGORITHM AES
    )

tnc localhost -port 5022

-- Run on SQL managed instance
-- SQL_SERVER_IP_ADDRESS should be an IP address that could be accessed from the SQL Managed Instance host machine.
DECLARE @SQLServerIpAddress NVARCHAR(MAX) = '<SQL_SERVER_IP_ADDRESS>'; -- insert your SQL Server IP address in here
DECLARE @tncCommand NVARCHAR(MAX) = 'tnc ' + @SQLServerIpAddress + ' -port 5022 -InformationLevel Quiet';
DECLARE @jobId BINARY(16);

IF EXISTS (
        SELECT *
        FROM msdb.dbo.sysjobs
        WHERE name = 'NetHelper'
        ) THROW 70000,
    'Agent job NetHelper already exists. Please rename the job, or drop the existing job before creating it again.',
    1
    -- To delete NetHelper job run: EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'
    EXEC msdb.dbo.sp_add_job @job_name = N'NetHelper',
        @enabled = 1,
        @description = N'Test SQL Managed Instance to SQL Server network connectivity on port 5022.',
        @category_name = N'[Uncategorized (Local)]',
        @owner_login_name = N'sa',
        @job_id = @jobId OUTPUT;

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'TNC network probe from SQL MI to SQL Server',
    @step_id = 1,
    @os_run_priority = 0,
    @subsystem = N'PowerShell',
    @command = @tncCommand,
    @database_name = N'master',
    @flags = 40;

EXEC msdb.dbo.sp_update_job @job_id = @jobId,
    @start_step_id = 1;

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)';

-- Run on managed instance
IF EXISTS(SELECT * FROM sys.objects WHERE name = 'ExecuteNetHelper')
    THROW 70001, 'Stored procedure ExecuteNetHelper already exists. Rename or drop the existing procedure before creating it again.', 1
GO
CREATE PROCEDURE ExecuteNetHelper AS
-- To delete the procedure run: DROP PROCEDURE ExecuteNetHelper
BEGIN
    -- Start the job.
    DECLARE @NetHelperstartTimeUtc DATETIME = GETUTCDATE();
    DECLARE @stop_exec_date DATETIME = NULL;

    EXEC msdb.dbo.sp_start_job @job_name = N'NetHelper';

    -- Wait for job to complete and then see the outcome.
    WHILE (@stop_exec_date IS NULL)
    BEGIN
        -- Wait and see if the job has completed.
        WAITFOR DELAY '00:00:01'

        SELECT @stop_exec_date = sja.stop_execution_date
        FROM msdb.dbo.sysjobs sj
        INNER JOIN msdb.dbo.sysjobactivity sja
            ON sj.job_id = sja.job_id
        WHERE sj.name = 'NetHelper'

        -- If job has completed, get the outcome of the network test.
        IF (@stop_exec_date IS NOT NULL)
        BEGIN
            SELECT sj.name JobName,
                sjsl.date_modified AS 'Date executed',
                sjs.step_name AS 'Step executed',
                sjsl.log AS 'Connectivity status'
            FROM msdb.dbo.sysjobs sj
            LEFT JOIN msdb.dbo.sysjobsteps sjs
                ON sj.job_id = sjs.job_id
            LEFT JOIN msdb.dbo.sysjobstepslogs sjsl
                ON sjs.step_uid = sjsl.step_uid
            WHERE sj.name = 'NetHelper'
        END

        -- In case of operation timeout (90 seconds), print timeout message.
        IF (datediff(second, @NetHelperstartTimeUtc, getutcdate()) > 90)
        BEGIN
            SELECT 'NetHelper timed out during the network check. Please investigate SQL Agent logs for more information.'

            BREAK;
        END
    END
END;

-- Run on managed instance
EXEC ExecuteNetHelper;

-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO

Migrar um certificado de um banco de dados protegido por TDE (opcional)

Se você estiver vinculando um banco de dados do SQL Server protegido pela TDE (Transparent Data Encryption) a uma instância gerenciada do SQL, deverá migrar o certificado de criptografia correspondente da instância local ou do SQL Server da VM do Azure para a instância gerenciada do SQL antes de usar o link. Para obter etapas detalhadas, consulte Migrar um certificado de um banco de dados protegido por TDE para a Instância Gerida do SQL do Azure.

Os bancos de dados da Instância Gerenciada SQL criptografados com chaves TDE gerenciadas por serviço não podem ser vinculados ao SQL Server. Você só pode vincular um banco de dados criptografado ao SQL Server se ele tiver sido criptografado com uma chave gerenciada pelo cliente e o servidor de destino tiver acesso à mesma chave usada para criptografar o banco de dados. Para obter mais informações, consulte Configurar o SQL Server TDE com o Azure Key Vault.

Instalar o SSMS

O SQL Server Management Studio (SSMS) é a maneira mais fácil de usar o link Instância Gerenciada. Instale a versão mais recente do SQL Server Management Studio (SSMS) na sua máquina cliente.

Após a conclusão da instalação, abra o SSMS e conecte-se à sua instância do SQL Server com suporte. Clique com o botão direito do mouse em um banco de dados de usuário e valide se a opção de link da Instância Gerenciada SQL do Azure aparece no menu.

Configurar o SSMS para nuvens governamentais

Se quiser implantar sua Instância Gerenciada SQL em uma nuvem governamental, você precisará modificar suas configurações do SQL Server Management Studio (SSMS) para usar a nuvem correta. Se você não estiver implantando sua Instância Gerenciada SQL em uma nuvem governamental, ignore esta etapa.

Para atualizar as configurações do SSMS, siga estas etapas:

1. Abra o SSMS.
2. No menu, selecione Ferramentas e, em seguida, escolha Opções .
3. Expanda Serviços do Azure e selecione Azure Cloud.
4. Em Selecionar uma Nuvem do Azure, use a lista suspensa para escolher entre AzureUSGovernmentou outra nuvem governamental, como AzureChinaCloud:

Se quiser voltar à nuvem pública, escolha AzureCloud na lista suspensa.

Conteúdo relacionado

Para usar o link:

• Configurar ligação entre o SQL Server e a instância gerida do SQL com o SSMS
• Configurar o link entre o SQL Server e a instância gerenciada do SQL com scripts
• Falha no link
• Migrar com o link
• Práticas recomendadas para manter o link

Para saber mais sobre o link:

• Visão geral do link de Instância Gerenciada
• Recuperação de desastres com link de instância gerenciada

Para outros cenários de replicação e migração, considere:

• Replicação transacional com Instância Gerida do SQL
• Serviço de Reprodução de Log (LRS)