Preparación del entorno para un vínculo: Azure SQL Managed Instance

Se aplica a: Azure SQL Managed Instance

Este artículo le enseñará cómo preparar el entorno para un vínculo de instancia administrada a fin de que pueda replicar entre SQL Server instalado en Windows o Linux y Azure SQL Managed Instance.

Nota:

Puede automatizar la preparación del entorno para el vínculo de Instancia administrada mediante un script descargable. Para más información, vea el blog de automatización de la configuración del vínculo.

Requisitos previos

Para crear un vínculo entre SQL Server y Azure SQL Managed Instance, necesita los siguientes requisitos previos:

• Una suscripción de Azure activa. En caso de no tener ninguna, cree una cuenta gratuita.
• Versión compatible de SQL Server con la actualización de servicio necesaria.
• Azure SQL Managed Instance. Inicio rápido: Creación de una instancia administrada de Azure SQL si aún no tiene una.
• Decida a qué servidor va a ser la principal inicial para determinar desde dónde debe crear el vínculo.
  • La configuración de un vínculo de SQL Managed Instance principal a la secundaria de SQL Server solo se admite a partir de SQL Server 2022 CU10 y por instancias configuradas con la directiva de actualización de SQL Server 2022.

Precaución

Al crear la instancia administrada de SQL para usarla con la característica de vínculo, tenga en cuenta los requisitos de memoria de las características OLTP en memoria que use SQL Server. Para más información, vea Introducción a los límites de recursos de Azure SQL Managed Instance.

Permisos

Para SQL Server, debe tener permisos sysadmin.

Para Azure SQL Managed Instance, debe ser miembro del Colaborador de SQL Managed Instance o tener los siguientes permisos para un rol personalizado:

Microsoft.Sql/ resource	Permisos necesarios
Microsoft.Sql/managedInstances	/lectura, /escritura
Microsoft.Sql/managedInstances/hybridCertificate	/action
Microsoft.Sql/managedInstances/databases	/read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups	/read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates	/lectura
Microsoft.Sql/managedInstances/hybridLink	/lectura, /escritura, /eliminación
Microsoft.Sql/managedInstances/serverTrustCertificates	/escritura, /eliminación, /lectura

Preparación de la instancia de SQL Server

Para preparar la instancia de SQL Server, debe validar que:

• Tiene la versión mínima admitida.
• Ha habilitado la característica de grupos de disponibilidad.
• Ha agregado las marcas de seguimiento adecuadas al inicio.
• Las bases de datos están en el modelo de recuperación completa y se ha hecho una copia de seguridad.

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 master

Cree una clave maestra de base de datos en la base de datos master, si aún no está presente. 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%';

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.

Nota:

Para SQL Server en Linux, consulte Habilitar 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'

Importante

Para SQL Server 2016 (13.x), si necesita habilitar la característica de grupos de disponibilidad, deberá completar los pasos adicionales documentados en Preparación de SQL Server 2016 requisitos previos: vínculo de Azure SQL Managed Instance. Estos pasos adicionales no son necesarios para SQL Server 2019 (15.x) y versiones posteriores compatibles con el vínculo.

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

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 Grupos de disponibilidad Always On.

5. Active la casilla Hablitar los grupos de disponibilidad Always On y, a continuación, seleccione Aceptar.

   

   • Si usa SQL Server 2016 (13.x) y si la opción Habilitar grupos de disponibilidad Always On está deshabilitada con el mensaje This computer is not a node in a failover cluster., siga los pasos adicionales descritos en Preparación de SQL Server 2016 requisitos previos: vínculo de Azure SQL Managed Instance. Una vez que haya completado estos otros pasos, vuelva a intentarlo 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 se recomienda habilitar las siguientes marcas de seguimiento en el inicio:

• -T1800: esta marca de seguimiento optimiza el rendimiento cuando los discos que hospedan los archivos de registro de la réplica principal y secundaria de un grupo de disponibilidad tienen tamaños de sector diferentes, por ejemplo, 512 bytes y 4 KB. Si la réplica principal y la secundaria tienen un tamaño de sector de disco de 4 KB, esta marca de seguimiento no es necesaria. 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.

Nota:

Para SQL Server en Linux, consulte Habilitación de marcas de seguimiento.

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

Después de asegurarse de que tiene una versión compatible de SQL Server, de que ha habilitado la característica Grupos de disponibilidad Always On y de que ha agregado las marcas de seguimiento de inicio, reinicie la instancia de SQL Server para aplicar todos estos cambios:

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 de SQL Server y, a continuación, 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 su servidor SQL Server debe ser una de las versiones compatibles aplicadas con las actualizaciones de servicio adecuadas, la función de grupos de disponibilidad Always On debe estar activada y debe tener las marcas de seguimiento -T1800 y -T9567 habilitadas. La captura de pantalla siguiente es un ejemplo del resultado esperado para una instancia de SQL Server que se ha configurado correctamente:

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 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 automáticamente habrá conectividad de red 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 su instancia de SQL Server en Azure Virtual Machines está en una red virtual diferente de la instancia administrada, debe establecer una conexión entre ambas redes virtuales. Las redes virtuales no tienen por qué estar en la misma suscripción para que este escenario funcione.

Para conectar redes virtuales hay dos opciones:

• 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 la opción preferida porque se usa la red troncal de Microsoft y, por lo tanto, desde la perspectiva de la conectividad, no hay diferencias notables de latencia entre las máquinas virtuales de la red virtual emparejada y la propia. El emparejamiento de red virtual se admite entre las 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).

SQL Server fuera de Azure

Si la instancia de SQL Server se hospeda fuera de Azure, establezca una conexión VPN entre SQL Server y SQL Managed Instance con cualquiera de estas opciones:

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

Sugerencia

Se recomienda ExpressRoute para obtener el mejor rendimiento de red al replicar los datos. Aprovisione una puerta de enlace con el ancho de banda suficiente para su caso de uso.

Puertos de red entre los entornos

Independientemente del mecanismo de conectividad, hay requisitos que deben cumplirse para que el tráfico de red fluya entre los entornos:

Las reglas del grupo de seguridad de red (NSG) en la subred que hospeda la instancia gestionada permiten lo siguiente:

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

Todos los firewalls de la red que hospeda SQL Server y el sistema operativo del 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)

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

Entorno	Qué hacer
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 del sistema operativo (Windows o Linux) 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.
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 del sistema operativo (Windows o Linux) del host de SQL Server.
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 la red que aloja SQL Server en el puerto 5022 y el rango de puertos 11000-11999.

Use el siguiente script de PowerShell en el SO del host Windows de la instancia de SQL Server para abrir los puertos en el firewall de Windows:

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 SQL Server, así como los firewalls corporativos o las puertas de enlace:

Importante

• Los puertos deben estar abiertos en todos los firewalls del entorno de red, incluido el servidor host, así como los firewalls corporativos o las puertas de enlace 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, los números de puerto de SQL Managed Instance no se pueden cambiar ni personalizar.
• 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 sea necesario agregar direcciones URL para el FQDN de SQL Managed Instance y algunos de los puntos de conexión de Resource Management usados por Azure a la lista de permitidos.

A continuación se enumeran los recursos que se deben agregar a la lista de permitidos:

• Nombre de dominio completo (FQDN) de la instancia SQL Managed Instance. Por ejemplo, managedinstance1.6d710bcf372b.database.windows.net.
• La autoridad de Microsoft Entra
• Identificador de recurso del punto de conexión de Microsoft Entra
• Punto de conexión de Resource Manager
• Punto de conexión de 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 las direcciones URL específicas de los recursos de la nube que debe agregar a la lista de permitidos.

Comprobar la conectividad de red

La conectividad de red bidireccional entre SQL Server y SQL Managed Instance es necesaria para que el vínculo funcione. Después de abrir los puertos en el lado de SQL Server y configurar una regla NSG en el lado de SQL Managed Instance, pruebe la conectividad utilizando SQL Server Management Studio (SSMS) o Transact-SQL.

Pruebe la red mediante la creación de un trabajo temporal del Agente SQL en SQL Server y SQL Managed Instance para comprobar la conexión entre las dos instancias. Cuando se usa Network Checker en SSMS, el trabajo se crea automáticamente y se elimina una vez completada la prueba. Debe eliminar manualmente el trabajo del Agente SQL si prueba la red mediante T-SQL.

Nota:

Actualmente no se admite la ejecución de scripts de PowerShell mediante el Agente SQL Server en SQL Server en Linux, por lo que actualmente no es posible ejecutar Test-NetConnection desde el trabajo de Agente SQL Server en SQL Server en Linux.

Para usar el Agente SQL a fin de probar la conectividad de red, necesita los siguientes requisitos:

• El usuario que realiza la prueba debe tener permisos para crear un trabajo (ya sea como sysadmin o perteneciente al rol SQLAgentOperator para msdb) para SQL Server y SQL Managed Instance.
• Se debe ejecutar el servicio Agente SQL Server en SQL Server. Puesto que el Agente está activado de forma predeterminada en SQL Managed Instance, no es necesario realizar ninguna acción adicional.

SSMS

Para probar la conectividad de red entre SQL Server y SQL Managed Instance en SSMS, siga estos pasos:

1. Conéctese a la instancia que será la réplica principal en SSMS.

2. En Explorador de objetos, expanda bases de datos y haga clic con el botón derecho en la base de datos que quiere vincular con la base de datos secundaria. Seleccione el vínculo Tareas>Azure SQL Managed Instance>Prueba de conexión para abrir el asistente Comprobador de red:

   

3. Seleccione Siguiente en la página Introducción del asistente de Network Checker.

4. Si se cumplen todos los requisitos en la página Requisitos previos, seleccione Siguiente. De lo contrario, resuelva los requisitos previos no satisfechos y, a continuación, seleccione Volver a ejecutar validación.

5. En la página Inicio de sesión, seleccione Iniciar sesión para conectarse a la otra instancia que será la réplica secundaria. Seleccione Siguiente.

6. Compruebe los detalles de la página Especificar opciones de red y proporcione una dirección IP, si es necesario. Seleccione Siguiente.

7. En la página Resumen, revise las acciones que realiza el asistente y, a continuación, seleccione Finalizar para probar la conexión entre las dos réplicas.

8. Revise la página Resultados para validar que existe conectividad entre las dos réplicas y, a continuación, seleccione Cerrar para finalizar.

T-SQL

Para usar T-SQL para probar la conectividad, debe comprobar la conexión en ambas direcciones. En primer lugar, pruebe la conexión de SQL Server a SQL Managed Instance y, a continuación, pruebe la conexión de SQL Managed Instance a SQL Server.

Prueba de conexión desde SQL Server a SQL Managed Instance

Use el Agente SQL Server en SQL Server para ejecutar pruebas de conectividad de SQL Server a SQL Managed Instance.

1. Conéctese a SQL Managed Instance y ejecute el siguiente script para generar algunos parámetros que necesitaremos más adelante:

   SELECT 'DECLARE @serverName NVARCHAR(512) = N''' + value + ''''
   FROM sys.dm_hadr_fabric_config_parameters
   WHERE parameter_name = 'DnsRecordName'
   
   UNION
   
   SELECT 'DECLARE @node NVARCHAR(512) = N''' + NodeName + '.' + Cluster + ''''
   FROM (
       SELECT SUBSTRING(replica_address, 0, CHARINDEX('\', replica_address)) AS NodeName,
           RIGHT(service_name, CHARINDEX('/', REVERSE(service_name)) - 1) AppName,
           JoinCol = 1
       FROM sys.dm_hadr_fabric_partitions fp
       INNER JOIN sys.dm_hadr_fabric_replicas fr
           ON fp.partition_id = fr.partition_id
       INNER JOIN sys.dm_hadr_fabric_nodes fn
           ON fr.node_name = fn.node_name
       WHERE service_name LIKE '%ManagedServer%'
           AND replica_role = 2
   ) t1
   LEFT JOIN (
       SELECT value AS Cluster,
           JoinCol = 1
       FROM sys.dm_hadr_fabric_config_parameters
       WHERE parameter_name = 'ClusterName'
       ) t2
       ON (t1.JoinCol = t2.JoinCol)
   INNER JOIN (
       SELECT [value] AS AppName
       FROM sys.dm_hadr_fabric_config_parameters
       WHERE section_name = 'SQL'
           AND parameter_name = 'InstanceName'
       ) t3
       ON (t1.AppName = t3.AppName)
   
   UNION
   
   SELECT 'DECLARE @port NVARCHAR(512) = N''' + value + ''''
   FROM sys.dm_hadr_fabric_config_parameters
   WHERE parameter_name = 'HadrPort';
   

   Los resultados deberían parecerse a lo siguiente:

   

   Guarde los resultados para utilizarlos en los pasos siguientes. Dado que estos parámetros pueden cambiar después de cualquier conmutación por error, asegúrese de generarlos de nuevo, si es necesario.

2. Conéctese a SQL Server.

3. Abra una ventana de consulta nueva y pegue el script siguiente:

   --START
   -- Parameters section
   DECLARE @node NVARCHAR(512) = N''
   DECLARE @port NVARCHAR(512) = N''
   DECLARE @serverName NVARCHAR(512) = N''
   
   --Script section
   IF EXISTS (
           SELECT job_id
           FROM msdb.dbo.sysjobs_view
           WHERE name = N'TestMILinkConnection'
           )
       EXEC msdb.dbo.sp_delete_job @job_name = N'TestMILinkConnection',
           @delete_unused_schedule = 1
   
   DECLARE @jobId BINARY (16),
       @cmd NVARCHAR(MAX)
   
   EXEC msdb.dbo.sp_add_job @job_name = N'TestMILinkConnection',
       @enabled = 1,
       @job_id = @jobId OUTPUT
   
   SET @cmd = (N'tnc ' + @serverName + N' -port 5022 | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')
   
   EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
       @step_name = N'Test Port 5022',
       @step_id = 1,
       @cmdexec_success_code = 0,
       @on_success_action = 3,
       @on_fail_action = 3,
       @subsystem = N'PowerShell',
       @command = @cmd,
       @database_name = N'master'
   
   SET @cmd = (N'tnc ' + @node + N' -port ' + @port + ' | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')
   
   EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
       @step_name = N'Test HADR Port',
       @step_id = 2,
       @cmdexec_success_code = 0,
       @subsystem = N'PowerShell',
       @command = @cmd,
       @database_name = N'master'
   
   EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
       @server_name = N'(local)'
   GO
   
   EXEC msdb.dbo.sp_start_job @job_name = N'TestMILinkConnection'
   GO
   
   --Check status every 5 seconds
   DECLARE @RunStatus INT
   
   SET @RunStatus = 10
   
   WHILE (@RunStatus >= 4)
   BEGIN
       SELECT DISTINCT @RunStatus = run_status
       FROM [msdb].[dbo].[sysjobhistory] JH
       INNER JOIN [msdb].[dbo].[sysjobs] J
           ON JH.job_id = J.job_id
       WHERE J.name = N'TestMILinkConnection'
           AND step_id = 0
   
       WAITFOR DELAY '00:00:05';
   END
   
   --Get logs once job completes
   SELECT [step_name],
       SUBSTRING([message], CHARINDEX('TcpTestSucceeded', [message]), CHARINDEX('Process Exit', [message]) - CHARINDEX('TcpTestSucceeded', [message])) AS    TcpTestResult,
       SUBSTRING([message], CHARINDEX('RemoteAddress', [message]), CHARINDEX('TcpTestSucceeded', [message]) - CHARINDEX('RemoteAddress', [message])) AS    RemoteAddressResult,
       [run_status],
       [run_duration],
       [message]
   FROM [msdb].[dbo].[sysjobhistory] JH
   INNER JOIN [msdb].[dbo].[sysjobs] J
       ON JH.job_id = J.job_id
   WHERE J.name = N'TestMILinkConnection'
       AND step_id <> 0
       --END
   

4. Reemplace los parámetros @node, @port y @serverName por los valores que obtuvo del primer paso.

5. Ejecute el script y compruebe los resultados. Debería ver resultados parecidos a este ejemplo:

   

6. Compruebe los resultados:

   • El resultado de cada prueba en TcpTestSucceededed debe ser TcpTestSucceeded : True.
   • RemoteAddresses debe pertenecer al intervalo IP de la subred SQL Managed Instance.

   Si la respuesta no es correcta, compruebe la siguiente configuración de red:

   • Hay reglas en el firewall de red y en el firewall del sistema operativo (Windows o Linux) del host de SQL Server que permiten el tráfico a todo el intervalo IP de la subred de SQL Managed Instance.
   • Hay una regla de NSG que permite la comunicación en el puerto 5022 para la red virtual que hospeda SQL Managed Instance.

Prueba de conexión desde SQL Managed Instance a SQL Server

Para comprobar que SQL Managed Instance puede acceder a SQL Server, primero debe crear un punto de conexión de prueba. A continuación, use el Agente SQL Server para ejecutar un script de PowerShell con el comando tnc que haga ping a SQL Server en el puerto 5022 desde la instancia administrada de SQL.

Para crear un punto de conexión de prueba, conéctese a SQL Server y ejecute el siguiente script de T-SQL:

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

Para comprobar que el punto de conexión de SQL Server está recibiendo conexiones en el puerto 5022, ejecute el siguiente comando de PowerShell en el sistema operativo del host de la instancia de SQL Server:

tnc localhost -port 5022

Una prueba correcta muestra TcpTestSucceeded : True. A continuación, podemos continuar con la creación de un trabajo del Agente SQL Server en una instancia administrada de SQL para intentar probar el punto de conexión de prueba de SQL Server en el puerto 5022 desde la instancia administrada de SQL.

A continuación, cree un trabajo del Agente SQL Server en la instancia administrada de SQL llamada NetHelper mediante la ejecución del siguiente script de T-SQL en la instancia administrada de SQL. Sustituya:

• <SQL_SERVER_IP_ADDRESS> con la dirección IP de SQL Server a la que se puede acceder desde la instancia administrada de SQL.

-- 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)';

Sugerencia

Si tiene que modificar la dirección IP de la instancia de SQL Server para el sondeo de conectividad desde SQL Managed Instance, elimine el trabajo de NetHelper mediante la ejecución de EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' y vuelva a crear el trabajo de NetHelper con el script anterior.

Después, cree un procedimiento almacenado ExecuteNetHelper que ayude a ejecutar el trabajo y obtener resultados del sondeo de red. Ejecute el siguiente script de T-SQL en la instancia administrada de SQL:

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

Ejecute la siguiente consulta en la instancia administrada de SQL para ejecutar el procedimiento almacenado que ejecutará el trabajo del agente de NetHelper y mostrará el registro resultante:

-- Run on managed instance
EXEC ExecuteNetHelper;

Si la conexión ha sido correcta, el registro muestra True. Si la conexión no ha sido correcta, el registro muestra False.

Si la conexión no fue correcta, compruebe los siguientes elementos:

• El firewall del host de la instancia de SQL Server permite la comunicación entrante y saliente en el puerto 5022.
• Hay una regla de NSG para la red virtual que hospeda SQL Managed Instance que permite la comunicación en el puerto 5022.
• Si la instancia de SQL Server está en una máquina virtual de Azure, una regla de NSG permite la comunicación en el puerto 5022 en la red virtual que hospeda la máquina virtual.
• SQL Server se está ejecutando.
• Existe un punto de conexión de prueba en SQL Server.

Después de resolver problemas, vuelva a ejecutar el sondeo de red netHelper mediante la ejecución EXEC ExecuteNetHelper en la instancia administrada.

Por último, después de que la prueba de red re haya realizado correctamente, elimine el punto de conexión de prueba y el certificado de SQL Server con los siguientes comandos de T-SQL:

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

Precaución

Continúe con los pasos siguientes solo si ha validado la conectividad de red entre los entornos de origen y de destino. De lo contrario, solucione los problemas de conectividad de red antes de continuar.

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 el Cifrado de datos transparente (TDE) a una instancia administrada, debe migrar el certificado de cifrado correspondiente de la máquina virtual de Azure o local de la instancia de SQL Server a la instancia administrada 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 en SQL Server si se 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:

Azure Key Vault es compatible con SQL Server en Linux a partir de SQL Server 2022 CU 14.

Instalación de SSMS

SQL Server Management Studio (SSMS) es la manera más fácil de usar el vínculo de Instancia administrada. Descargue SSMS versión 19.0 o posterior e instálelo en la máquina cliente.

Una vez finalizada la instalación, abra SSMS y conéctese a la instancia de SQL Server compatible. Haga clic con el botón derecho en una base de datos de usuario y compruebe que se muestre la opción Azure SQL Managed Instance link (Vínculo de Azure SQL Managed Instance) en el menú.

Configuración de SSMS para nubes de administración pública

Si quiere implementar SQL Managed Instance en una nube de administración pública, debe modificar la configuración de SQL Server Management Studio (SSMS) para usar la nube correcta. Si no va a implementar SQL Managed Instance en una nube de administración pública, omita este paso.

Para actualizar la configuración de SSMS, siga estos pasos:

1. Abra SSMS.
2. En el menú, elija Herramientas y, después, Opciones.
3. Expanda Servicios de Azure y seleccione Nube de Azure.
4. En Seleccionar nube de Azure, use la lista desplegable para elegir AzureUSGovernment u otra nube de administración pública, como AzureChinaCloud:

Si quiere volver a la nube pública, elija AzureCloud en la lista desplegable.

Contenido relacionado

Para usar el vínculo:

• Configuración del vínculo entre SQL Server y SQL Managed instance con SSMS
• Configuración del vínculo entre SQL Server y SQL Managed Instance con scripts
• Conmutación por error de un vínculo
• Migración con el vínculo
• Procedimientos recomendados para el mantenimiento del vínculo

Para más información sobre el vínculo:

• Vínculo de Instancia administrada: información general
• Recuperación ante desastres con vínculo de instancia administrada

Para otros escenarios de replicación y migración, considere lo siguiente:

• Replicación transaccional con SQL Managed Instance
• Servicio de reproducción de registros (LRS)