Preparar o ambiente para uma migração de ligações 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 Managed Instance da sua instância de SQL Server habilitada por Azure Arc para Azure SQL Managed Instance no portal Azure.

Com o link, pode migrar as suas bases de dados SQL Server para o 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 o Azure SQL Managed Instance através do portal Azure, precisa dos seguintes pré-requisitos:

• Uma subscrição ativa do Azure. Se não tiver uma, crie uma conta gratuita.
• Uma instância suportada de SQL Server habilitada por Azure Arc com a extensão Azure para SQL Server versão 1.1.3238.349, que suporta migrar uma base de dados de cada vez. Azure Extensão para SQL Server versão 1.1.3348.364 ou posterior é necessária para migrar até 10 bases de dados ao mesmo tempo. Pode atualizar a sua extensão usando o portal Azure ou o CLI do Azure.

Versões suportadas para SQL Server

Tanto os níveis de serviço General Purpose como Business Critical do Azure SQL Managed Instance suportam a ligação Managed Instance. 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 até SQL Server 2025 e SQL Server 2022 a partir de instâncias geridas SQL com a correspondente política 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 secção descreve as permissões necessárias para migrar a sua instância do SQL Server para a SQL Managed Instance através do portal Azure.

Na instância do SQL Server de origem, 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 sysadmin na instância SQL Server fonte. 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 Managed Instance, precisa de uma das seguintes permissões no SQL Managed Instance target:

• Função de Contribuidor de Instância Gerida do SQL
• Função de Colaborador ou Proprietário no nível de assinatura

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

Combine a capacidade de desempenho entre réplicas

Quando utiliza a funcionalidade de ligação, é importante ajustar a capacidade de desempenho entre o SQL Server e o SQL Managed Instance. Esta correspondência ajuda a evitar problemas de desempenho se a réplica secundária não conseguir acompanhar a replicação a partir da réplica primária, ou após o failover. A capacidade de desempenho inclui núcleos de CPU (ou vCores no Azure), memória e largura de banda de I/O.

Prepare a sua instância de SQL Server

Para preparar a sua instância do 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.
• Reiniciar SQL Server e validar a configuração.
• Defina a base de dados para modelo de recuperação completa.
• Importar chaves de autoridades certificadoras raiz confiáveis no Azure para SQL Server.
• Ativa a recuperação acelerada da base de dados se estiveres em SQL Server 2019 ou posterior, e planeias usá-lo na instância SQL gerida de destino.
• Ativa o Service Broker se planeias usá-lo na instância SQL gerida de destino.

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

Instalar atualizações de serviço

Certifique-se de que a sua versão SQL Server tem a atualização de manutenção adequada instalada, conforme indicado na tabela de suporte version. Se precisar de instalar alguma atualização, deve reiniciar a sua instância do SQL Server durante a atualização.

Para verificar a 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 o SQL Server e o 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 garantir que tem a chave mestra da base de dados, utilize o seguinte script T-SQL no SQL Server:

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

Preparar instâncias do SQL Server 2016

Para SQL Server 2016 (13.x), deve completar os passos extra documentados em Prepare os pré-requisitos do 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 que a funcionalidade de grupos de disponibilidade está ativada, 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. Abrir Gestor de Configuração do SQL Server.

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

3. Clique com o botão direito no serviço SQL Server e depois selecione Properties:

   

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 SQL Server 2016 (13.x), e a opção Ativar Grupos de Disponibilidade Sempre Ligados estiver desativada com a mensagem This computer is not a node in a failover cluster, siga os passos descritos em Prepare os 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. Abrir o Gestor de Configuração do SQL Server.

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

3. Clique com o botão direito no serviço SQL Server e depois selecione Properties.

   

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 traço 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 rastreamento inicial, reinicie a sua instância do SQL Server para aplicar todas estas alterações:

1. Abrir Gestor de Configuração do SQL Server.

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

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

   

Após o reinício, 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 adequadas 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 ecrã seguinte é um exemplo do resultado esperado para uma instância do SQL Server devidamente configurada:

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 no Azure para o SQL Server

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

Pode fazer download das chaves raiz da CA em detalhes da Autoridade Certificadora Azure. No mínimo, descarregue os certificados DigiCert Global Root G2 e Microsoft RSA Root Certificate Authority 2017 e importe-os para a sua instância SQL Server.

Guarde os certificados localmente na instância SQL Server, como no caminho de amostra 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 obrigatórios 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

Permitir a recuperação acelerada da base de dados

Para SQL Server versões de 2019 e posteriores, ative recuperação acelerada da base de dados e certifique-se de que o armazenamento de versões persistentes (PVS) está definido para PRIMARY. Se a recuperação acelerada da base de dados não estiver ativada na base de dados do SQL Server de origem, não pode ser ativada na instância gerida SQL de destino depois da migração da base de dados. Se o armazenamento de versões persistentes (PVS) não estiver definido para PRIMARY, pode ter problemas com operações de restauro na instância SQL gerida de destino.

Para o SQL Server 2017 e versões anteriores, a recuperação acelerada da base de dados não é suportada, por isso este passo não é necessário.

Para configurar corretamente a recuperação acelerada da base de dados no SQL Server de origem, siga estes passos:

1. Permita a recuperação acelerada da base de dados executando o seguinte script Transact-SQL no SQL Server:

   ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
   

2. O armazenamento persistente de versões (PVS) deve ser definido como PRIMARY na base de dados de origem, que é a configuração predefinida. Se isto foi alterado anteriormente, deve voltar a ser PRIMARY antes de iniciar a migração.

Ativar o Corretor de Serviços

Service Broker está ativado por defeito para todas as versões do SQL Server. Se o Service Broker estava desativado e planeias usá-lo no SQL Managed Instance, ativa o Service Broker na base de dados do SQL Server de origem antes de migrar para o SQL Managed Instance. Se o Service Broker não estiver ativado na base de dados SQL Server de origem, não pode usá-lo na instância SQL gerida de destino.

Para verificar se o Service Broker está ativado, execute o seguinte script Transact-SQL na instância do SQL Server:

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Se o Service Broker estiver desativado, ative-o executando o seguinte script Transact-SQL na base de dados SQL Server de origem:

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

Configurar a conectividade de rede

Para o link funcionar, é necessário ter conectividade de rede entre o SQL Server e o SQL Managed Instance. A opção de rede que escolhes depende de a tua instância do SQL Server estar ou não numa rede Azure.

SQL Server fora do Azure

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

• Conexão VPN site a site
• A ligação Azure ExpressRoute

Servidor SQL em Máquinas Virtuais do Azure

Implementar o SQL Server nas Máquinas Virtuais do Azure na mesma rede virtual Azure que aloja o SQL Managed Instance é o método mais simples, porque a conectividade de rede existe automaticamente entre as duas instâncias. Para mais informações, consulte Quickstart: Configure uma VM Azure para se ligar ao Azure SQL Managed Instance.

Se a sua instância SQL Server nas Máquinas Virtuais do Azure 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:

• Azure pareamento de rede virtual
• Gateway VPN de VNet para VNet (portal Azure, PowerShell, CLI do Azure)

O peering é preferível porque utiliza a rede 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 o SQL Managed Instance 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 aloja 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 Windows Firewall, utilize o seguinte script PowerShell no sistema operativo anfitrião 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 SO que aloja a instância SQL Server, e quaisquer firewalls e gateways corporativos:

Adicionar URLs à lista de permitir

Dependendo das suas definições de segurança de rede, pode ser necessário adicionar URLs à sua lista de permissões para o SQL Managed Instance FQDN e alguns dos endpoints de Gestão de Recursos usados pelo Azure.

Adicione os seguintes recursos à sua lista de autorizações:

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

Siga os passos na secção Configure 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 autorizações.

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

Se estiver a ligar uma base de dados SQL Server protegida por Encriptação de Dados Transparente (TDE) a uma instância gerida SQL, deve migrar o certificado de encriptação correspondente da instância SQL Server on-premises ou Azure VM para a instância gerida SQL antes de usar a ligação. Para passos detalhados, consulte Migrar um certificado de uma base de dados protegida por TDE para Azure SQL Managed Instance.

Bases de dados SQL Managed Instance encriptadas com chaves TDE geridas por serviços não podem ser ligadas 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 mais informações, consulte Configurar SQL Server TDE com 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 SQL Managed Instance. Pode testar a conectividade diretamente a partir do portal do 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 Migração de 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 Conexão de Teste para validar a conectividade de rede entre SQL Server e SQL Managed Instance:

   

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 da 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 às migrações através do portal Azure.
• Extensão Azure para SQL Server versão 1.1.3238.349 e versões anteriores suporta apenas a migração de uma base de dados de cada vez através do link. Para migrar várias bases de dados ao mesmo tempo, atualize para Azure Extensão para SQL Server versão 1.1.3348.364 ou posterior.
• Cancelar uma migração requer permissões sysadmin na instância de origem SQL Server. Se a sua instância de SQL Server não estiver a usar o menor privilégio, atribua manualmente permissões sysadmin à conta NT AUTHORITY\SYSTEM.
• Configurar um link através do portal do Azure para fins de migração não é compatível com links criados manualmente, seja através do SQL Server Management Studio (SSMS) ou do Transact-SQL (T-SQL). Consulte o problema conhecido para saber mais.
• A monitorização da migração através do portal Azure está disponível apenas para instâncias de SQL Server que cumpram os requisitos de licenciamento.

Resolver problemas comuns

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

Conteúdo relacionado

• Melhores práticas para o link de Managed Instance
• Visão Geral da Migração do SQL Server no Azure Arc
• Preparar ambiente para migração LRS - migração SQL Server em Azure Arc
• SQL Server ativado por 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 SQL Server em Azure Arc