Preparación del entorno para una migración de enlace de Instancia Administrada: migración de SQL Server en Azure Arc

Se aplica a:SQL Server

Este artículo le ayuda a preparar su entorno para una migración de enlace de Instancia Administrada de su instancia de SQL Server habilitada por Azure Arc a Azure SQL Managed Instance en el portal de Azure.

Con el vínculo, puede migrar las bases de datos de SQL Server a Azure SQL Managed Instance mediante la replicación en tiempo real con un grupo de disponibilidad distribuido (migración en línea):

Nota:

Puede proporcionar comentarios sobre la experiencia de migración directamente al grupo de productos.

Prerrequisitos

Para migrar las bases de datos de SQL Server a Azure SQL Managed Instance a través de Azure Portal, necesita los siguientes requisitos previos:

• Una suscripción de Azure activa. En caso de no tener ninguna, cree una cuenta gratuita.
• Una instancia admitida de SQL Server habilitada por Azure Arc con la extensión de Azure para la versión 1.1.3238.349 de SQL Server o posterior. Puede actualizar la extensión mediante Azure Portal o la CLI de Azure.

Versiones admitidas de SQL Server

Los niveles de servicio Uso general y Crítico para la empresa de Azure SQL Managed Instance admiten el vínculo Instancia administrada. La migración con la característica de vínculo funciona con las ediciones Enterprise, Developer y Standard de SQL Server en Windows Server.

En la tabla siguiente se enumeran las versiones mínimas admitidas de SQL Server para el vínculo:

Versión de SQL Server	Actualización de mantenimiento mínima necesaria
SQL Server 2025 (17.x)	SQL Server 2025 RTM (17.0.1000.7)
SQL Server 2022 (16.x)	SQL Server 2022 RTM (16.0.1000.6)
SQL Server 2019 (15.x)	SQL Server 2019 CU20 (15.0.4312.2)
SQL Server 2017 (14.x)	Compilación de SQL Server 2017 CU31 (14.0.3456.2) o posterior y el paquete de Azure Connect de SQL Server 2017 correspondiente (14.0.3490.10)
SQL Server 2016 (13.x)	SQL Server 2016 SP3 (13.0.6300.2) y el paquete correspondiente de SQL Server 2016 Azure Connect (13.0.7000.253)
SQL Server 2014 (12.x) y versiones anteriores	Las versiones anteriores a SQL Server 2016 no son compatibles.

La migración inversa solo se admite en SQL Server 2025 y SQL Server 2022 desde instancias administradas de SQL con la directiva de actualización correspondiente. Puede revertir manualmente una migración utilizando otras herramientas, como copias de seguridad y restauración nativas o configurando manualmente un vínculo en SSMS.

Permissions

En esta sección se describen los permisos necesarios para migrar la instancia de SQL Server a SQL Managed Instance a través de Azure Portal.

En la instancia de SQL Server de origen, necesita los permisos siguientes:

• Si habilita privilegios mínimos, se conceden los permisos necesarios, como sysadmin, según sea necesario durante el proceso de migración de la base de datos.
• Si no puede usar privilegios mínimos, la persona que realiza la migración necesita permisos sysadmin en la instancia de SQL Server de origen. Además, si necesita cancelar una migración, asigne también manualmente permisos sysadmin a la NT AUTHORITY\SYSTEM cuenta.

Para migrar con el vínculo Instancia administrada, necesita uno de los permisos siguientes en el destino de INSTANCIA administrada de SQL:

• Rol Colaborador de instancia administrada de SQL
• Rol de colaborador o propietario de nivel de suscripción

Para obtener permisos mínimos, consulte Permisos personalizados.

Nota:

Los usuarios con los permisos SqlServerAvailabilityGroups_CreateManagedInstanceLink, SqlServerAvailabilityGroups_failoverMiLink y SqlServerAvailabilityGroups_deleteMiLink en Azure pueden realizar acciones en el panel de Migración de Base de Datos durante el proceso de migración que eleva los permisos de SQL Server de la cuenta usada por la extensión, incluido el rol sysadmin.

Preparación de la instancia de SQL Server

Para preparar la instancia de SQL Server, complete los pasos siguientes:

• Valide que está en la versión admitida.
• Cree una clave maestra de base de datos en la master base de datos.
• Habilite la característica grupos de disponibilidad.
• Agregue las marcas de seguimiento adecuadas al inicio.
• Reinicie SQL Server y valide la configuración.
• Establezca la base de datos en modelo de recuperación completa.
• Importe las claves de entidad de certificación raíz de confianza de Azure en SQL Server.

Debe reiniciar SQL Server para que estos cambios surtan efecto.

Instalación de actualizaciones de servicio

Asegúrese de que su versión de SQL Server tiene instalada la actualización de mantenimiento adecuada, tal y como se indica en la tabla de compatibilidad de versiones. Si necesita instalar actualizaciones, debe reiniciar la instancia de SQL Server durante la actualización.

Para comprobar la versión de SQL Server, ejecute el siguiente script de Transact-SQL (T-SQL) en SQL Server:

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

Creación de una clave maestra de base de datos en la base de datos maestra

El vínculo usa certificados para cifrar la autenticación y la comunicación entre SQL Server e Instancia administrada de SQL. La clave maestra de base de datos protege los certificados usados por el vínculo. Si ya tiene una clave maestra de base de datos, puede omitir este paso.

Cree una clave maestra de base de datos en la master base de datos. Inserte la contraseña en lugar de <strong_password> en el script siguiente y manténgala en un lugar confidencial y seguro. Ejecute este script de T-SQL en SQL Server:

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

Para asegurarse de que tiene la clave maestra de base de datos, use el siguiente script de T-SQL en SQL Server:

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

Preparación de instancias de SQL Server 2016

Para SQL Server 2016 (13.x), debe completar los pasos adicionales documentados en Preparación de los requisitos previos de SQL Server 2016 para el vínculo. Estos pasos adicionales no son necesarios para SQL Server 2017 (14.x) y versiones posteriores compatibles con el vínculo.

Habilitación de grupos de disponibilidad

La característica de vínculo se basa en la característica de grupos de disponibilidad Always On, que está desactivada de manera predeterminada. Para más información, vea Habilitación de la característica Grupos de disponibilidad Always On.

Para confirmar que la característica de grupos de disponibilidad está habilitada, ejecute el siguiente script de T-SQL en 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'

Si la característica de grupos de disponibilidad no está habilitada, siga estos pasos para habilitarla:

1. Abra Administrador de configuración de SQL Server.

2. En el panel izquierdo, seleccione Servicios de SQL Server.

3. Haga clic con el botón derecho en el servicio SQL Server y seleccione Propiedades:

   

4. Vaya a la pestaña Grupos de disponibilidad Always On.

5. Active la casilla Habilitar grupos de disponibilidad AlwaysOn y, a continuación, seleccione Aceptar.

   

   • Si usa SQL Server 2016 (13.x) y la opción Habilitar grupos de disponibilidad AlwaysOn está deshabilitada con el mensaje This computer is not a node in a failover cluster, siga los pasos descritos en Preparación de los requisitos previos de SQL Server 2016 para el vínculo. Después de completar estos pasos, vuelva a este paso e inténtelo de nuevo.

6. Seleccione Aceptar en el cuadro de diálogo.

7. Reinicie el servicio SQL Server.

Habilitación de marcas de seguimiento de inicio

Para optimizar el rendimiento del vínculo, habilite las siguientes marcas de seguimiento en el inicio:

• -T1800: esta marca de seguimiento optimiza el rendimiento cuando los archivos de registro de las réplicas principales y secundarias de un grupo de disponibilidad están en discos con diferentes tamaños de sector, como 512 bytes y 4 KB. Si las réplicas principales y secundarias usan un tamaño de sector de disco de 4 KB, no necesita esta marca de seguimiento. Para más información, consulte KB3009974.
• -T9567: esta marca de seguimiento habilita la compresión del flujo de datos para los grupos de disponibilidad durante la inicialización automática. La compresión aumenta la carga en el procesador, pero puede reducir significativamente el tiempo de transferencia durante la inicialización.

Para habilitar estas marcas de seguimiento en el inicio, siga estos pasos:

1. Abra el Administrador de configuración de SQL Server.

2. En el panel izquierdo, seleccione Servicios de SQL Server.

3. Haga clic con el botón derecho en el servicio SQL Server y seleccione Propiedades.

   

4. Vaya a la pestaña Parámetros de inicio. En Especificar un parámetro de inicio, escriba -T1800 y seleccione Agregar para agregar el parámetro de inicio. A continuación, escriba -T9567 y seleccione Agregar para agregar otra marca de seguimiento. Seleccione Aplicar para guardar los cambios.

   

5. Seleccione Aceptar para cerrar la ventana Propiedades.

Para más información, consulte la sintaxis para habilitar marcas de seguimiento.

Reinicio de SQL Server y validación de la configuración

Si no necesita actualizar la versión de SQL Server, habilite la característica del grupo de disponibilidad o agregue marcas de seguimiento de inicio, puede omitir esta sección.

Después de asegurarse de que está en una versión compatible de SQL Server, habilite la característica Grupos de disponibilidad AlwaysOn y agregue las marcas de seguimiento de inicio, reinicie la instancia de SQL Server para aplicar todos estos cambios:

1. Abra Administrador de configuración de SQL Server.

2. En el panel izquierdo, seleccione Servicios de SQL Server.

3. Haga clic con el botón derecho en el servicio SQL Server y seleccione Reiniciar.

   

Después del reinicio, ejecute el siguiente script de T-SQL en SQL Server para validar la configuración de la instancia de 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;

La versión de SQL Server debe ser una de las versiones admitidas con las actualizaciones de servicio adecuadas aplicadas. La característica Grupos de disponibilidad Always On debe estar habilitada, y debe tener habilitadas las marcas de seguimiento -T1800 y -T9567. La captura de pantalla siguiente es un ejemplo del resultado esperado para una instancia de SQL Server configurada correctamente:

Establecimiento de la base de datos en el modelo de recuperación completa

Las bases de datos migradas a través del vínculo deben estar en el modelo de recuperación completa y tener al menos una copia de seguridad.

Ejecute el código siguiente en SQL Server para todas las bases de datos que desea migrar. Reemplace <DatabaseName> por el nombre real de la base de datos.

-- 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

Importación de claves de entidad de certificación raíz de confianza de Azure en SQL Server

Para confiar en los certificados de clave pública de las instancias administradas de SQL que emite Azure, debe importar los certificados de autoridad de certificación raíz de Azure a SQL Server.

Puedes descargar las claves de CA raíz desde los detalles de la entidad de certificación de Azure. Como mínimo, descargue los certificados DigiCert Global Root G2 y Microsoft RSA Root Certificate Authority 2017 e impórtelos a la instancia de SQL Server.

Nota:

El certificado raíz en la cadena de certificación para un certificado de clave pública de una Instancia administrada de SQL es emitido por una entidad de certificación (CA) raíz de confianza de Azure. La entidad de certificación raíz específica puede cambiar con el tiempo a medida que Azure actualiza su lista de CA de confianza. Para una configuración simplificada, instale todos los certificados raíz de la CA enumerados en Autoridades de Certificación Raíz de Azure. Puede instalar solo la clave de CA necesaria mediante la identificación del emisor de una clave pública de Instancia Administrada de SQL anteriormente importada.

Guarde los certificados locales en la instancia de SQL Server, como en la C:\certs\<name of certificate>.crt ruta de acceso de ejemplo y, a continuación, importe los certificados de esa ruta de acceso mediante el siguiente script de Transact-SQL. Reemplace por <name of certificate> el nombre del certificado real: DigiCert Global Root G2 y Microsoft RSA Root Certificate Authority 2017, que son los nombres necesarios para estos dos 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

Sugerencia

Si falta el procedimiento almacenado en el sp_certificate_add_issuer entorno de SQL Server, es probable que la instancia de SQL Server no tenga instalada la actualización de servicio adecuada.

Por último, compruebe todos los certificados creados mediante la siguiente vista de administración dinámica (DMV):

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

Configuración de la conectividad de red

Para que el vínculo funcione, debe tener conectividad de red entre SQL Server y SQL Managed Instance. La opción de red que elija depende de si la instancia de SQL Server está o no en una red de Azure.

SQL Server fuera de Azure

Si hospeda la instancia de SQL Server fuera de Azure, puede establecer una conexión VPN entre SQL Server y SQL Managed Instance mediante cualquiera de estas opciones:

• Conexión VPN de sitio a sitio
• Conexión de Azure ExpressRoute

Sugerencia

Para obtener el mejor rendimiento de red al replicar datos, use ExpressRoute. Aprovisione una puerta de enlace con el ancho de banda suficiente para su caso de uso.

SQL Server en Azure Virtual Machines

La implementación de SQL Server en Azure Virtual Machines en la misma red virtual de Azure que hospeda SQL Managed Instance es el método más sencillo, ya que la conectividad de red existe automáticamente entre las dos instancias. Para más información, vea Inicio rápido: Configuración de una VM de Azure para la conexión a Azure SQL Managed Instance.

Si la instancia de SQL Server en Azure Virtual Machines se encuentra en una red virtual diferente de la instancia administrada de SQL, debe conectar las dos redes virtuales. Las redes virtuales no tienen que estar en la misma suscripción para que este escenario funcione.

Tiene dos opciones para conectar redes virtuales:

• Emparejamiento de redes virtuales de Azure
• Puerta de enlace VPN de red virtual a red virtual (Azure Portal, PowerShell, CLI de Azure)

El emparejamiento es preferible porque usa la red troncal de Microsoft. Por lo tanto, desde una perspectiva de conectividad, no hay ninguna diferencia notable en la latencia entre las máquinas virtuales de una red virtual emparejada y en la misma red virtual. El emparejamiento de redes virtuales se admite entre redes de la misma región. El emparejamiento de red virtual global es compatible con instancias hospedadas en subredes creadas desde el 22 de septiembre de 2020. Para más información, vea Preguntas más frecuentes (P+F).

Puertos de red entre los entornos

Independientemente del mecanismo de conectividad, debe cumplir los siguientes requisitos para que el tráfico de red fluya entre los entornos:

Las reglas del grupo de seguridad de red (NSG) de la subred que hospeda sql Managed Instance deben permitir:

• Puerto de entrada 5022 y intervalo de puertos 11000-11999 para recibir tráfico de la dirección IP de SQL Server de origen
• Puerto de salida 5022 para enviar tráfico a la dirección IP de SQL Server de destino

El puerto 5022 no se puede cambiar en Instancia administrada de SQL.

Todos los firewalls de la red que hospedan SQL Server y el sistema operativo host deben permitir:

• Puerto de entrada 5022 abierto para recibir tráfico del intervalo IP de origen de la subred MI /24 (por ejemplo, 10.0.0.0/24)
• Puertos de salida 5022 y el intervalo de puertos 11000-11999 abierto para enviar tráfico al intervalo IP de destino de la subred MI (ejemplo 10.0.0.0/24)

El puerto 5022 se puede personalizar en el lado de SQL Server, pero el intervalo de puertos 11000-11999 debe abrirse tal como está.

En la tabla siguiente se describen las acciones de puerto para cada entorno:

Medio ambiente	Qué hacer
SQL Server (fuera de Azure)	Abra el tráfico entrante y saliente en el puerto 5022 para el firewall de red para todo el intervalo IP de la subred de SQL Managed Instance. Si es necesario, haga lo mismo en el firewall de Windows del host de SQL Server.
SQL Server (en Azure)	Abra el tráfico entrante y saliente en el puerto 5022 para el firewall de red para todo el intervalo IP de la subred de SQL Managed Instance. Si es necesario, haga lo mismo en el firewall de Windows del host de SQL Server. Para permitir la comunicación en el puerto 5022, cree una regla de grupo de seguridad de red (NSG) en la red virtual que hospeda la máquina virtual (VM).
Instancia administrada de SQL	Cree una regla de NSG en Azure Portal para permitir el tráfico entrante y saliente desde la dirección IP y las redes que hospedan SQL Server en el puerto 5022 y el intervalo de puertos 11000-11999.

Para abrir puertos en Firewall de Windows, use el siguiente script de PowerShell en el sistema operativo host de Windows de la instancia de 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

En el diagrama siguiente se muestra un ejemplo de un entorno de red local, que indica que todos los firewalls del entorno deben tener puertos abiertos, incluido el firewall del sistema operativo que hospeda la instancia de SQL Server y los firewalls y puertas de enlace corporativos:

Importante

• Debe abrir puertos en todos los firewalls del entorno de red, incluido el servidor host, y los firewalls o puertas de enlace corporativos de la red. En entornos corporativos, es posible que tenga que mostrar a su administrador de red la información de esta sección para ayudar a abrir puertos adicionales en la capa de redes corporativas.
• Aunque puede elegir personalizar el punto de conexión en el lado de SQL Server, no puede cambiar ni personalizar números de puerto para SQL Managed Instance.
• Los intervalos de direcciones IP de subredes que hospedan instancias administradas y SQL Server no deben superponerse.

Añadir URL a la lista permitida

En función de la configuración de seguridad de red, es posible que tenga que agregar direcciones URL a la lista de permitidos para la Instancia administrada de SQL y algunos de los puntos de conexión de Administración de recursos usados por Azure.

Agregue los siguientes recursos a la lista de permitidos:

• Nombre de dominio completo (FQDN) de la instancia SQL Managed Instance. Por ejemplo: managedinstance.a1b2c3d4e5f6.database.windows.net.
• Autoridad de Microsoft Entra
• Identificador de recurso del punto de conexión de Microsoft Entra
• Punto de conexión del Administrador de Recursos
• Punto de conexión del servicio

Siga los pasos descritos en la sección Configurar SSMS para nubes gubernamentales para acceder a la interfaz herramientas de SQL Server Management Studio (SSMS) e identificar direcciones URL específicas para los recursos de la nube que necesita agregar a la lista de permitidos.

Migración de certificados de una base de datos protegida por TDE (opcional)

Si va a vincular una base de datos de SQL Server protegida por cifrado de datos transparente (TDE) a una instancia administrada de SQL, debe migrar el certificado de cifrado correspondiente de la instancia de SQL Server local o de máquina virtual de Azure a la instancia administrada de SQL antes de usar el vínculo. Para obtener pasos detallados, vea Migración de un certificado de una base de datos protegida por TDE a Azure SQL Managed Instance.

Las bases de datos de SQL Managed Instance cifradas con claves TDE administradas por el servicio no pueden vincularse a SQL Server. Solo puede vincular una base de datos cifrada a SQL Server si la cifró con una clave administrada por el cliente y el servidor de destino tiene acceso a la misma clave que se usa para cifrar la base de datos. Para más información, consulte Configuración de TDE de SQL Server con Azure Key Vault.

Nota:

SQL Server en Linux admite Azure Key Vault a partir de la actualización acumulativa 14 para SQL Server 2022.

Prueba de la conectividad de red

Antes de iniciar la migración, pruebe la conectividad de red entre la instancia de SQL Server y SQL Managed Instance. Puede probar la conectividad directamente desde Azure Portal como parte del proceso de migración. Sin embargo, también puede probar la conectividad manualmente mediante Transact-SQL y el Agente SQL Server. Para más información, consulte Probar la conectividad de red.

Para probar la conectividad a través de Azure Portal, siga estos pasos:

1. Seleccione Migrar datos en el panel Migración de base de datos para el recurso de instancia de SQL Server.

2. Seleccione la opción vínculo MI.

3. Seleccione las bases de datos de destino que desea migrar y, a continuación, use Siguiente: Configuración para ir a la pestaña siguiente.

4. En la pestaña Configuración , proporcione el nombre del vínculo y el grupo de disponibilidad de origen. A continuación, use Probar conexión para validar la conectividad de red entre SQL Server y la Instancia Administrada de SQL:

   

Considere los siguientes puntos:

• Para evitar falsos negativos, todos los firewalls en toda la ruta de acceso de la red deben permitir el tráfico del Protocolo de mensajes de control de Internet (ICMP).
• Para evitar falsos positivos, todos los firewalls a lo largo de la ruta de acceso de red deben permitir el tráfico en el protocolo UCS de SQL Server propietario. Bloquear el protocolo puede producir una prueba de conexión exitosa, pero el enlace no se puede crear.
• Las configuraciones avanzadas del firewall con límites de protección de nivel de paquete deben configurarse correctamente para permitir el tráfico entre SQL Server y SQL Managed Instance.

Limitaciones

Tenga en cuenta las limitaciones siguientes:

• Las limitaciones del vínculo instancia administrada se aplican a las migraciones a través de Azure Portal.
• La cancelación de una migración requiere permisos sysadmin en la instancia de SQL Server de origen. Si la instancia de SQL Server no usa privilegios mínimos, asigne manualmente permisos sysadmin a la NT AUTHORITY\SYSTEM cuenta.
• La configuración de un vínculo a través de Azure Portal para la migración no es compatible con los vínculos creados manualmente, ya sea a través de SQL Server Management Studio (SSMS) o Transact-SQL (T-SQL). Revise el problema conocido para obtener más información.
• La supervisión de la migración a través de Azure Portal solo está disponible para las instancias de SQL Server que cumplen los requisitos de licencia de supervisión.

Solución de problemas comunes

Para solucionar problemas comunes al migrar a Azure SQL Managed Instance, consulte Solución de problemas de migración.

Contenido relacionado

• Mejores prácticas de enlace de instancia administrada
• Migración de SQL Server en Azure Arc
• Preparación del entorno para una migración de LRS
• Introducción a SQL Server habilitado por Azure Arc
• Comentarios de la experiencia de migración directamente al grupo de productos
• Migración a Azure SQL Managed Instance: migración de SQL Server en Azure Arc