Preparar o ambiente para uma migração de links de Instância Gerida - Migração do SQL Server no Azure Arc

Aplica-se a:SQL Server

Este artigo ajuda-o a preparar o seu ambiente para uma migração de links de Instância Gerida da sua instância SQL Server habilitada pelo Azure Arc para Azure SQL Managed Instance no portal Azure.

Com o link, pode migrar as suas bases de dados SQL Server para a Azure SQL Managed Instance usando replicação em tempo real com um grupo de disponibilidade distribuído (migração online):

Pré-requisitos

Para migrar as suas bases de dados SQL Server para Azure SQL Managed Instance através do portal Azure, precisa dos seguintes pré-requisitos:

• Uma assinatura ativa do Azure. Se não tiver uma, crie uma conta gratuita.
• Uma instância suportada do SQL Server habilitada pelo Azure Arc com a extensão Azure para a versão 1.1.3238.349 SQL Server ou posterior. Pode atualizar a sua extensão usando o portal Azure ou a CLI do Azure.

Versões suportadas do SQL Server

As camadas de serviço de Finalidade Geral e Crítica para Negócios da Instância Gerenciada SQL do Azure dão suporte ao link de Instância Gerenciada. A migração com a funcionalidade de ligação funciona com as edições Enterprise, Developer e Standard do SQL Server no Windows Server.

A tabela seguinte lista as versões mínimas suportadas do SQL Server para o link:

A migração reversa é suportada apenas para SQL Server 2025 e SQL Server 2022 a partir de instâncias geridas por SQL com a respetiva política de atualização. Pode reverter manualmente uma migração através de outras ferramentas, como backup e restauro nativos, ou configurar manualmente um link no SSMS.

Permissions

Esta seção descreve as permissões necessárias para migrar sua instância do SQL Server para a Instância Gerenciada do SQL por meio do portal do Azure.

Na instância do SQL Server de origem, você precisa das seguintes permissões:

• Se ativar o privilégio mínimo, as permissões necessárias, como administrador de sistemas , são concedidas conforme necessário durante o processo de migração da base de dados.
• Se não conseguires usar o privilégio mínimo, a pessoa que faz a migração precisa de permissões de administrador de sistemas na instância SQL Server de origem. Além disso, se precisares de cancelar uma migração, atribui também manualmente permissões de administrador de sistemas à NT AUTHORITY\SYSTEM conta.

Para migrar com o link Instância Gerenciada, você precisa de uma das seguintes permissões no destino da Instância Gerenciada SQL:

• função de Colaborador de SQL Managed Instance
• Função de Colaborador ou Proprietário no nível de assinatura

Para obter permissões mínimas, consulte Permissões personalizadas.

Preparar sua instância do SQL Server

Para preparar a sua instância de SQL Server, complete os seguintes passos:

• Valida que estás na versão suportada.
• Crie uma chave mestra de base de dados na master base de dados.
• Ativa a funcionalidade de grupos de disponibilidade.
• Adicione as flags de rastreamento corretas no arranque.
• Reinicie o SQL Server e valide a configuração.
• Defina a base de dados para modelo de recuperação completa.
• Importar chaves de autoridade de certificação raiz confiáveis no Azure para o SQL Server.

Tens de reiniciar o SQL Server para que estas alterações tenham efeito.

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 uma chave mestra de base de dados na master base de dados. 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%';

Prepare instâncias SQL Server 2016

Para o SQL Server 2016 (13.x), deve completar os passos extra documentados nos pré-requisitos do Prepare SQL Server 2016 para o link. Estes passos extra não são necessários para o SQL Server 2017 (14.x) e versões posteriores suportadas pelo link.

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 no serviço SQL Server, depois selecione Propriedades:

   

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

5. Seleciona a opção Ativar Grupos de Disponibilidade Sempre Ativados e depois seleciona OK.

   

   • Se estiver a usar o SQL Server 2016 (13.x) e a opção Ativar Grupos de Disponibilidade Sempre Ativos estiver desativada com a mensagem This computer is not a node in a failover cluster, siga os passos descritos nos pré-requisitos do SQL Server 2016 para o link. Depois de completares estes passos, volta a este passo e tenta novamente.

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, ative as seguintes bandeiras de rastreio no arranque:

• -T1800: Esta bandeira de traço otimiza o desempenho quando os ficheiros de registo das réplicas primária e secundária num grupo de disponibilidade estão em discos com diferentes tamanhos de setor, como 512 bytes e 4 KB. Se tanto as réplicas primárias como secundárias usarem um segmento de disco de 4 KB, não precisas desta bandeira de traço. 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 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

Se não precisou de atualizar a versão do SQL Server, ativar a funcionalidade de grupo de disponibilidade ou adicionar flags de rastreio de arranque, pode saltar esta secção.

Depois de garantir que está numa versão suportada do SQL Server, ativar a funcionalidade Always On availability groups e adicionar as suas flags de rastreio de arranque, reinicie a sua 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 no serviço SQL Server, depois 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;

A sua versão do SQL Server deve ser uma das versões suportadas com as atualizações de serviço apropriadas aplicadas. A funcionalidade de grupos de disponibilidade Always On deve estar ativada, e deves ter os trace flags -T1800 e -T9567 ativados. A captura de tela a seguir é um exemplo do resultado esperado para uma instância do SQL Server configurada corretamente:

Definir a base de dados para modelo de recuperação total

As bases de dados migradas através do link devem estar no modelo completo de recuperação e ter pelo menos uma cópia de segurança.

Execute o seguinte código no SQL Server para todas as bases de dados que pretende migrar. Substitua <DatabaseName> pelo nome real do banco de dados.

-- Run on SQL Server
-- Set full recovery model for all databases you want to migrate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to migrate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Importar chaves de autoridade de certificação raiz confiáveis do Azure para o SQL Server

Para confiar nos certificados de chave pública SQL Managed Instance que o Azure emite, precisa de importar chaves de autoridade certificadora raiz (CA) confiáveis no Azure para o SQL Server.

Pode descarregar as chaves de CA raiz a partir dos detalhes da Azure Certificate Authority. No mínimo, descarregue os certificados DigiCert Global Root G2 e Microsoft RSA Root Root Certificate Authority 2017 e importe-os para a sua instância SQL Server.

Guarde os certificados localmente para a instância do SQL Server, como para o caminho de exemplo C:\certs\<name of certificate>.crt , e depois importe os certificados desse caminho usando o script Transact-SQL seguinte. Substitua <name of certificate> pelo nome real do certificado: DigiCert Global Root G2 e Microsoft RSA Root Certificate Authority 2017, que são os nomes exigidos para estes dois certificados.

-- Run on SQL Server-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
CREATE CERTIFICATE [DigiCertPKI] FROM FILE = 'C:\certs\DigiCertGlobalRootG2.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('DigiCertPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO
CREATE CERTIFICATE [MicrosoftPKI] FROM FILE = 'C:\certs\Microsoft RSA Root Certificate Authority 2017.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('MicrosoftPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO

Por fim, verifique todos os certificados criados usando a seguinte exibição de gerenciamento dinâmico (DMV):

-- Run on SQL Server
USE master
SELECT * FROM sys.certificates

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 fora do Azure

Se hospedar a sua instância SQL Server fora do Azure, pode estabelecer uma ligação VPN entre o SQL Server e a Instância Gerida SQL usando uma destas opções:

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

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.

Tem 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).

Portas de rede entre os ambientes

Independentemente do mecanismo de conectividade, deve cumprir os seguintes requisitos para que o tráfego de rede flua entre os ambientes:

As regras do Network Security Group (NSG) na sub-rede que aloja a Instância Gerida SQL devem permitir:

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

A porta 5022 não pode ser alterada no SQL Managed Instance.

Todos os firewalls na rede que hospeda o SQL Server e no sistema operativo anfitrião devem 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 porta 5022 pode ser personalizada do lado do SQL Server, mas o intervalo de portas 11000-11999 deve ser aberto tal qual está.

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 seguinte mostra um exemplo de ambiente de rede local, indicando que todos os firewalls no ambiente precisam de ter portas abertas, incluindo o firewall do sistema operativo que hospeda a instância SQL Server, e quaisquer firewalls e gateways corporativos:

Adicionar URLs à lista de permissões

Dependendo das suas definições de segurança de rede, poderá precisar de adicionar URLs à sua lista de permisos para a Instância Gerida SQL FQDN e alguns dos endpoints de Gestão de Recursos usados pelo Azure.

Adicione os seguintes recursos à 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 secção Configurar SSMS para clouds governamentais para aceder à interface Tools no SQL Server Management Studio (SSMS) e identificar URLs específicas para os recursos dentro da sua cloud que precisa de adicionar à sua lista de permissões.

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 as etapas detalhadas, consulte Migrar um certificado de um banco de dados protegido por TDE para a Instância Gerida 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. Só pode ligar uma base de dados encriptada ao SQL Server se a encriptar com uma chave gerida pelo cliente e o servidor de destino tiver acesso à mesma chave usada para encriptar a base de dados. Para obter mais informações, consulte Configurar o SQL Server TDE com o Azure Key Vault.

Testar a conectividade de rede

Antes de iniciar a migração, teste a conectividade da rede entre a sua instância SQL Server e a Instância Gerida SQL. Pode testar a conectividade diretamente a partir do portal Azure como parte do processo de migração. No entanto, também pode testar a conectividade manualmente usando o Transact-SQL e o SQL Server Agent. Para mais informações, consulte Testar conectividade de rede.

Para testar a conectividade através do portal Azure, siga estes passos:

1. Selecione Migrar dados no painel de migração da base de dados para o seu recurso de instância SQL Server.

2. Seleciona a opção MI link.

3. Seleciona as bases de dados de destino que queres migrar e depois usa Próximo: Definições para ir para o separador seguinte.

4. No separador Definições, indique o nome do link e o grupo de origem de disponibilidade. Depois, use a Conexão de Teste para validar a conectividade de rede entre o SQL Server e a Instância Gerida SQL:

   

Considere os seguintes pontos:

• 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 guardrails ao nível de pacotes precisam de ser devidamente configuradas para permitir o tráfego entre SQL Server e SQL Managed Instance.

Limitações

Considere as seguintes limitações:

• As limitações do link Managed Instance aplicam-se a migrações através do portal Azure.
• Cancelar uma migração requer permissões de administrador de sistemas na instância SQL Server de origem. Se a sua instância SQL Server não estiver a usar o privilégio mínimo, atribua manualmente permissões de administrador de sistemas à NT AUTHORITY\SYSTEM conta.
• Configurar um link através do portal Azure para fins de migração não é compatível com links criados manualmente, seja através do SQL Server Management Studio (SSMS) ou Transact-SQL (T-SQL). Consulte o problema conhecido para saber mais.
• O monitoramento da migração por meio do portal do Azure está disponível apenas para instâncias do SQL Server que atendem aos requisitos de licenciamento de monitoramento.

Resolver problemas comuns

Para resolver problemas comuns ao migrar para Azure SQL Managed Instance, consulte Resolução de problemas de migração.

Conteúdo relacionado

• Melhores práticas para ligação de Managed Instance
• Migração do SQL Server em Azure Arc
• Preparar ambiente para uma migração LRS
• SQL Server ativado pela visão geral do Azure Arc
• Comentários sobre a experiência de migração diretamente para a equipa de produto
• Migração para Azure SQL Managed Instance - Migração do SQL Server no Azure Arc