Creación y configuración de un entorno de ejecución de integración autohospedado
SE APLICA A: Azure Data Factory Azure Synapse Analytics
Sugerencia
Pruebe Data Factory en Microsoft Fabric, una solución de análisis todo en uno para empresas. Microsoft Fabric abarca todo, desde el movimiento de datos hasta la ciencia de datos, el análisis en tiempo real, la inteligencia empresarial y los informes. ¡Obtenga más información sobre cómo iniciar una nueva evaluación gratuita!
El entorno de ejecución de integración (IR) es la infraestructura de proceso que usan las canalizaciones de Azure Data Factory y Synapse para proporcionar funcionalidades de integración de datos en distintos entornos de red. Para más información acerca del entorno de ejecución de integración, consulte Introducción al entorno de ejecución de integración.
Un entorno de ejecución de integración autohospedado puede ejecutar actividades de copia entre un almacén de datos en la nube y un almacén de datos en una red privada. También puede distribuir las siguientes actividades de transformación frente a los recursos de proceso en una red local o en Azure Virtual Network. La instalación de un entorno de ejecución de integración autohospedado debe realizarse en una máquina local o en una máquina virtual dentro de una red privada.
En este artículo se describe cómo crear y configurar un IR autohospedado.
Nota:
Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure. Para comenzar, consulte Instalación de Azure PowerShell. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.
Consideraciones a la hora de usar un IR autohospedado
- Puede utilizar un solo entorno de ejecución de integración autohospedado para varios orígenes de datos locales. También puede compartirla con otra factoría de datos dentro del mismo inquilino de Microsoft Entra. Para más información, consulte Uso compartido de un entorno de ejecución de integración autohospedado.
- En cada máquina solo puede instalar una instancia del entorno de ejecución de integración autohospedado. Si tiene dos factorías de datos que necesitan acceder a los orígenes de datos locales, use la característica de uso compartido del IR autohospedado para compartir el IR autohospedado, o bien instale el IR autohospedado en dos equipos locales, uno para cada fábrica de datos o área de trabajo de Synapse. El área de trabajo de Synapse no admite el uso compartido de Integration Runtime.
- No es preciso que el entorno de ejecución de integración autohospedado se encuentre en la misma máquina que el origen de datos. Sin embargo, cuanto más cerca estén ambos, menos tiempo necesitará el primero para conectarse al segundo. Le recomendamos que instale el entorno de ejecución de integración autohospedado en una máquina diferente de la que hospeda el origen de datos local. Si el entorno de ejecución de integración autohospedado y el origen de datos están en máquinas diferentes, el primero no compite con el segundo por recursos.
- Puede tener varios entornos de ejecución de integración autohospedados en diferentes equipos que se conecten al mismo origen de datos local. Por ejemplo, si tiene dos entornos de ejecución de integración autohospedados que sirven a dos factorías de datos el mismo origen de datos local puede estar registrado en ambas factorías de datos.
- Use un entorno de ejecución de integración autohospedado para admitir la integración de datos en Azure Virtual Network.
- Considere el origen de datos como un origen de datos local, que está detrás de un firewall, incluso cuando use Azure ExpressRoute. Use el entorno de ejecución de integración autohospedado para conectarse al origen de datos.
- Use el entorno de ejecución de integración autohospedado aunque el almacén de datos esté en la nube en una máquina virtual de infraestructura como servicio (IaaS) de Azure.
- Las tareas pueden generar error en un entorno de ejecución de integración autohospedado que esté instalado en un equipo con Windows Server para el que está habilitado el cifrado compatible con FIPS. Para solucionar este problema, tiene dos opciones: almacenar los valores de las credenciales y los secretos en una instancia de Azure Key Vault o deshabilitar el cifrado compatible con FIPS en el servidor. Para deshabilitar el cifrado compatible con FIPS, cambie el valor de la subclave del registro siguiente de 1 (habilitado) a 0 (deshabilitado):
HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled
. Si usa el entorno de ejecución de integración autohospedado como proxy en el entorno de integración de SSIS, se puede habilitar el cifrado conforme a FIPS y se usará al mover datos de un entorno local a Azure Blob Storage como área de almacenamiento temporal. - Los detalles completos de las licencias se proporcionan en la primera página de la configuración del entorno de ejecución de integración autohospedado.
Nota
Actualmente, el entorno de ejecución de integración autohospedado solo se puede compartir con varias factorías de datos. No es posible compartirlo entre áreas de trabajo de Synapse o entre una factoría de datos y un área de trabajo de Synapse.
Flujo de comandos y flujo de datos
Cuando mueve datos entre un entorno local y la nube, la actividad utiliza un entorno de ejecución de integración autohospedado para transferir los datos entre un origen de datos local y la nube.
A continuación se muestra un resumen de alto nivel de los pasos del flujo de datos para copiar con un IR autohospedado:
Un desarrollador de datos crea primero un entorno de ejecución de integración autohospedado en una instancia de Azure Data Factory o en un área de trabajo de Synapse mediante Azure Portal o el cmdlet de PowerShell. A continuación, el desarrollador de datos crea un servicio vinculado para un almacén de datos local mediante la especificación de la instancia del entorno de ejecución de integración autohospedado que debe usar el servicio para conectarse a los almacenes de datos.
El nodo del entorno de ejecución de integración autohospedado cifra las credenciales mediante la interfaz de programación de aplicaciones de protección de datos de Windows (DPAPI) y las guarda localmente. Si se establecen varios nodos para la alta disponibilidad, las credenciales se sincronizan de nuevo en otros nodos. Cada nodo cifra las credenciales mediante DPAPI y las almacena localmente. La sincronización de credenciales es transparente para el desarrollador de datos y la controla el IR autohospedado.
Las canalizaciones de Azure Data Factory y Azure Synapse se comunican con el entorno de ejecución de integración autohospedado para programar y administrar trabajos. La comunicación se realiza a través de un canal de control que usa una conexión compartida de Azure Relay. Cuando es necesario ejecutar un trabajo de actividad, el servicio pone en cola la solicitud junto con la información de credenciales. Sucede esto en caso de que las credenciales aún no estén almacenadas en el entorno de ejecución de integración autohospedado. El entorno de ejecución de integración autohospedado inicia el trabajo después de sondear la cola.
El entorno de ejecución de integración autohospedado copia datos entre un almacenamiento local y un almacenamiento en la nube. La dirección de la copia depende de la configuración de la actividad de copia en la canalización de los datos. En este paso, el entorno de ejecución de integración autohospedado se comunica directamente con servicios de almacenamiento basados en la nube, como Azure Blob Storage, a través de un canal HTTPS seguro.
Requisitos previos
- Las versiones compatibles de Windows son:
- Windows 10
- Windows 11
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
No se admite la instalación del entorno de ejecución de integración autohospedado en un controlador de dominio.
- El entorno de ejecución de integración autohospedado requiere un sistema operativo de 64 bits con .NET Framework 4.7.2 o posterior. Consulte Requisitos de sistema de .NET Framework para más información.
- La configuración mínima recomendada para la máquina del entorno de ejecución de integración autohospedado es un procesador de 2 GHz con 4 núcleos, 8 GB de RAM y 80 GB de espacio disponible en disco duro. Para obtener información detallada sobre los requisitos del sistema, consulte la descarga.
- Si el equipo host está en hibernación, el entorno de ejecución de integración autohospedado no responde a las solicitudes de datos. Configure un plan de energía adecuado en el equipo antes de instalar el entorno de ejecución de integración autohospedado. Si la máquina está configurada para hibernar, se mostrará un mensaje en el instalador del entorno de ejecución de integración autohospedado.
- Debe ser administrador de la máquina para instalar y configurar correctamente el entorno de ejecución de integración autohospedado.
- Las ejecuciones de la actividad de copia se producen con una frecuencia concreta. El uso del procesador y la RAM en la máquina sigue el mismo patrón en los momentos de máxima actividad y en los de inactividad. El uso de recursos también depende en gran medida de la cantidad de datos que se mueven. Cuando hay varios trabajos de copia en curso, puede ver que el uso de los recursos aumenta durante las horas pico.
- Puede que las tareas produzcan errores durante la extracción de datos en formatos Parquet, ORC o Avro. Para obtener más información sobre Parquet, consulte Formato Parquet en Azure Data Factory. La creación del archivo se ejecuta en la máquina de integración autohospedada. Para que funcione según lo esperado, la creación del archivo requiere los siguientes requisitos previos:
- Versión 11 de Java Runtime (JRE) de un proveedor de JRE, como Microsoft OpenJDK 11 o Eclipse Temurin 11. Asegúrese de que la variable de entorno del sistema JAVA_HOME esté establecida en la carpeta JDK (no solo en la carpeta JRE). Es posible que también tenga que agregar la carpeta Bin a la variable de entorno PATH del sistema.
Nota
Puede ser necesario ajustar la configuración de Java si se producen errores de memoria, como se describe en la documentación del formato Parquet.
Nota
Si va a ejecutarlo en una nube gubernamental, consulte Conexión a una nube gubernamental.
Configuración de un entorno de ejecución de integración autohospedado
Para crear y configurar un entorno de ejecución de integración autohospedado, use los procedimientos siguientes.
Creación de un IR autohospedado mediante Azure PowerShell
Puede usar Azure PowerShell para esta tarea. Este es un ejemplo:
Set-AzDataFactoryV2IntegrationRuntime -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName -Type SelfHosted -Description "selfhosted IR description"
Descargue e instale el entorno de ejecución de integración autohospedado en un equipo.
Recupere la clave de autenticación y registre el entorno de ejecución de integración autohospedado con la clave. Este es un ejemplo con PowerShell:
Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName
Nota
Para ejecutar el comando de PowerShell en Azure Government, consulte Conexión a Azure Government con PowerShell.
Creación de un entorno de ejecución de integración autohospedado mediante la interfaz de usuario
Use los siguientes pasos para crear un entorno de ejecución de integración autohospedado mediante la interfaz de usuario de Azure Data Factory o Azure Synapse.
En la página principal de la interfaz de usuario de Azure Data Factory, seleccione la pestaña "Administrar" en el panel izquierdo.
Seleccione Entornos de ejecución de integración en el panel izquierdo y, a continuación, seleccione + Nuevo.
En la página Configuración de Integration Runtime, seleccione Azure, Self-Hosted (Azure, autohospedado) y, luego, seleccione Continuar.
En la página siguiente, seleccione Self-Hosted (Autohospedado) para crear un IR autohospedado y, luego, seleccione Continuar.
Configuración de un entorno de ejecución de integración autohospedado mediante la interfaz de usuario
Escriba un nombre para el entorno de ejecución de integración y seleccione Create (Crear).
En la página Configuración de Integration Runtime, seleccione el vínculo bajo la Opción 1 para abrir la configuración rápida en el equipo. O siga los pasos descritos en Opción 2 para realizar la configuración manualmente. Las siguientes instrucciones se basan en el método de configuración manual:
Copie y pegue la clave de autenticación. Seleccione Download and install integration runtime (Descargar e instalar Integration Runtime).
Descargue el entorno de ejecución de integración autohospedado en una máquina Windows local. Ejecute al programa de instalación.
En la página Registro de Integration Runtime (autohospedado) , pegue la clave guardada anteriormente y seleccione Registrar.
En la página Nuevo nodo de Integration Runtime (autohospedado) , seleccione Finalizar.
Verá la siguiente ventana cuando el entorno de ejecución de integración autohospedado se haya registrado correctamente:
Configuración de un IR autohospedado en una VM de Azure mediante una plantilla de Azure Resource Manager
Puede automatizar la configuración del IR autohospedado en una máquina virtual de Azure mediante la plantilla Crear IR autohospedado. La plantilla proporciona una forma fácil de tener un IR autohospedado totalmente funcional dentro de Azure Virtual Network. El IR tiene características de escalabilidad y alta disponibilidad siempre que configure el número de nodos en dos o más.
Configuración de un IR autohospedado existente mediante PowerShell local
Puede usar la línea de comandos para configurar o administrar un IR autohospedado. Este uso puede resultar especialmente útil para automatizar la instalación y el registro de nodos de IR autohospedado.
Dmgcmd.exe se incluye en la instalación autohospedada. Normalmente se ubica en la carpeta C:\Archivos de programa\Microsoft Integration Runtime\5.0\Shared\. Esta aplicación admite varios parámetros y puede invocarse a través de una línea de comandos mediante scripts por lotes para la automatización.
Use la aplicación de la manera siguiente:
dmgcmd ACTION args...
Estos son los detalles de las acciones y los argumentos de la aplicación:
ACTION | args | Descripción |
---|---|---|
-rn ,-RegisterNewNode |
"<AuthenticationKey> " ["<NodeName> "] |
Registre un nodo del entorno de ejecución de integración autohospedado con la clave de autenticación y el nombre de nodo especificados. |
-era ,-EnableRemoteAccess |
"<port> " ["<thumbprint> "] |
Permite habilitar el acceso remoto al nodo actual para configurar un clúster de alta disponibilidad. También puede habilitar la configuración de credenciales directamente en el IR autohospedado sin necesidad de acceder a través de una instancia de Azure Data Factory o un área de trabajo de Azure Synapse. Para ello, use el cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential desde una máquina remota en la misma red. |
-erac ,-EnableRemoteAccessInContainer |
"<port> " ["<thumbprint> "] |
Permite habilitar el acceso remoto al nodo actual cuando el nodo se ejecuta en un contenedor. |
-dra ,-DisableRemoteAccess |
Permite deshabilitar el acceso remoto al nodo actual. Es necesario obtener acceso remoto para realizar la configuración de varios nodos. El cmdlet de PowerShell New-AzDataFactoryV2LinkedServiceEncryptedCredential funcionará incluso cuando el acceso remoto esté deshabilitado. Este comportamiento se produce siempre y cuando el cmdlet se ejecute en la misma máquina que el nodo de IR autohospedado. | |
-k ,-Key |
"<AuthenticationKey> " |
Permite sobrescribir o actualizar la clave de autenticación anterior. Debe tener cuidado con esta acción. El nodo de IR autohospedado anterior puede desconectarse si la clave es un nuevo entorno de ejecución de integración. |
-gbf ,-GenerateBackupFile |
"<filePath> " "<password> " |
Permite generar un archivo de copia de seguridad del nodo actual. El archivo de copia de seguridad incluye la clave del nodo y las credenciales del almacén de datos. |
-ibf ,-ImportBackupFile |
"<filePath> " "<password> " |
Permite restaurar el nodo desde un archivo de copia de seguridad. |
-r ,-Restart |
Permite reiniciar el servicio de host del entorno de ejecución de integración autohospedado. | |
-s ,-Start |
Permite iniciar el servicio de host del entorno de ejecución de integración autohospedado. | |
-t ,-Stop |
Permite detener el servicio de host del entorno de ejecución de integración autohospedado. | |
-sus ,-StartUpgradeService |
Permite iniciar el servicio de actualización del entorno de ejecución de integración autohospedado. | |
-tus ,-StopUpgradeService |
Permite detener el servicio de actualización del entorno de ejecución de integración autohospedado. | |
-tonau ,-TurnOnAutoUpdate |
Permite activar la actualización automática del entorno de ejecución de integración autohospedado. Este comando es solo para Azure Data Factory V1. | |
-toffau ,-TurnOffAutoUpdate |
Permite desactivar la actualización automática del entorno de ejecución de integración autohospedado. Este comando es solo para Azure Data Factory V1. | |
-ssa ,-SwitchServiceAccount |
"<domain\user> " ["<password> "] |
Permite configurar DIAHostService para que se ejecute como una cuenta nueva. Use la contraseña vacía "" para cuentas del sistema o cuentas virtuales. |
-elma ,-EnableLocalMachineAccess |
Habilite el acceso a la máquina local (localhost, IP privada) en el nodo de IR autohospedado. En el escenario de alta disponibilidad de IR autohospedado, la acción debe invocarse en cada nodo de IR autohospedado. | |
-dlma ,-DisableLocalMachineAccess |
Deshabilite el acceso a la máquina local (localhost, IP privada) en el nodo de IR autohospedado. En el escenario de alta disponibilidad de IR autohospedado, la acción debe invocarse en cada nodo de IR autohospedado. | |
-DisableLocalFolderPathValidation |
Deshabilite la validación de seguridad para habilitar el acceso al sistema de archivos de la máquina local. | |
-EnableLocalFolderPathValidation |
Habilite la validación de seguridad para deshabilitar el acceso al sistema de archivos de la máquina local. | |
-eesp ,-EnableExecuteSsisPackage |
Habilite la ejecución de paquetes SSIS en el nodo IR autohospedado. | |
-desp ,-DisableExecuteSsisPackage |
Deshabilite la ejecución de paquetes SSIS en el nodo IR autohospedado. | |
-gesp ,-GetExecuteSsisPackage |
Obtenga el valor si la opción ExecuteSsisPackage estuviera habilitada en el nodo IR autohospedado. Si el valor devuelto fuera verdadero, ExecuteSSISPackage estará habilitado. Si el valor devuelto fuera false o null, ExecuteSSISPackage estará deshabilitado. |
Instalación y registro de un IR autohospedado desde el Centro de descarga de Microsoft
Vaya a la página de descarga del entorno de ejecución de integración Microsoft.
Seleccione Descargar, haga clic en la versión de 64 bits y seleccione Siguiente. La versión de 32 bits no se admite.
Ejecute el archivo MSI directamente o guárdelo en el disco duro para ejecutarlo más adelante.
En la ventana principal, seleccione un idioma y, después, seleccione Siguiente.
Acepte los términos de licencia del software de Microsoft y seleccione Siguiente.
Seleccione la carpeta en la que se va a instalar el entorno de ejecución de integración autohospedado y seleccione Siguiente.
En la página Preparado para instalar, seleccione Instalar.
Seleccione Finalizar para completar la instalación.
Para obtener la clave de autenticación, use PowerShell. Este es un ejemplo de PowerShell para recuperar la clave de autenticación:
Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName
En la ventana Registro de Integration Runtime (autohospedado) de Microsoft Integration Runtime Configuration Manager que se ejecuta en la máquina, siga estos pasos:
Pegue la clave de autenticación en el área de texto.
Si lo desea, seleccione Show authentication key (Mostrar clave de autenticación) para ver el texto de la clave.
Seleccione Registrar.
Nota
Hay notas de la versión disponibles en la misma página de descarga del entorno de ejecución de integración de Microsoft.
Cuenta de servicio para el entorno de ejecución de integración autohospedado
La cuenta de servicio de inicio de sesión predeterminada para el entorno de ejecución de integración autohospedado es NT SERVICE\DIAHostService. Puede verla en Servicios -> Servicio del entorno de ejecución -> Propiedades -> Inicio de sesión.
Asegúrese de que la cuenta tenga permiso de inicio de sesión como servicio. De lo contrario, el entorno de ejecución de integración autohospedado no puede iniciarse correctamente. Puede comprobar el permiso en Directiva de seguridad local -> Configuración de seguridad -> Directivas locales-> Asignación de permisos de usuario-> Iniciar sesión como servicio.
Iconos y notificaciones del área de notificación
Si mueve el cursor sobre el icono o el mensaje en el área de notificación, podrá ver los detalles del estado del entorno de ejecución de integración autohospedado.
Alta disponibilidad y escalabilidad
Puede asociar un entorno de ejecución de integración autohospedado con varias máquinas locales o máquinas virtuales en Azure. Estas máquinas se llaman nodos. Puede tener hasta cuatro nodos asociados con un entorno de ejecución de integración autohospedado. Las ventajas de tener varios nodos en máquinas locales que tienen una puerta de enlace instalada para una puerta de enlace lógica son:
- Mayor disponibilidad del entorno de ejecución de integración autohospedado, para que deje de ser el único punto de error de la solución de macrodatos o la integración de datos en la nube. Esta disponibilidad garantiza la continuidad al usar un máximo de cuatro nodos.
- Rendimiento mejorado durante el movimiento de datos entre almacenes de datos locales y en la nube. Obtenga más información sobre las comparaciones de rendimiento.
Puede asociar varios nodos mediante la instalación del software del entorno de ejecución de integración autohospedado desde el Centro de descarga. A continuación, regístrelo mediante cualquiera de las claves de autenticación obtenidas del cmdlet New-AzDataFactoryV2IntegrationRuntimeKey, tal como se describe en el tutorial.
Nota
No es preciso crear un nuevo entorno de ejecución de integración autohospedado para asociar cada nodo. Puede instalar el entorno de ejecución de integración autohospedado en otro equipo y registrarlo con la misma clave de autenticación.
Nota
Antes de agregar otro nodo para aumentar la disponibilidad y escalabilidad, asegúrese de que la opción Remote access to intranet (Acceso remoto a la intranet) está habilitada en el primer nodo. Para ello, seleccione Microsoft Integration Runtime Configuration Manager>Configuración>Remote access to intranet (Acceso remoto a la intranet).
Consideraciones de escala
Escalado horizontal
Cuando el uso del procesador sea alto y quede poca memoria disponible en el IR autohospedado, agregue un nuevo nodo para ayudar a escalar horizontalmente la carga en las máquinas. Si se producen errores en las actividades porque se agota su tiempo de espera o el nodo del IR autohospedado está sin conexión, será útil agregar un nodo a la puerta de enlace. Para agregar un nodo, complete los siguientes pasos:
- Descargue la configuración de SHIR del portal de Azure Data Factory.
- Ejecute el Instalador en el nodo que desea agregar al clúster.
- Durante la instalación, seleccione la opción de unirse a un runtime de integración existente y proporcione la clave de autenticación de SHIR existente para vincular el nuevo nodo al clúster de SHIR existente.
Escalado vertical
Cuando el procesador y la memoria RAM disponible no se usan correctamente, pero la ejecución de trabajos simultáneos alcanza los límites de un nodo, aumente el número de trabajos simultáneos que puede ejecutar un nodo para escalar verticalmente. También puede realizar el escalado verticalmente cuando se agota el tiempo de espera de las actividades porque el IR autohospedado está sobrecargado. Como se muestra en la siguiente imagen, puede aumentar la capacidad máxima de los nodos:
Requisitos del certificado TLS/SSL
Si desea habilitar el acceso remoto desde la intranet con certificado TLS/SSL (avanzado) para proteger la comunicación entre los nodos del entorno de ejecución de integración, puede seguir los pasos descritos en Habilitación del acceso remoto desde la intranet con certificado TLS/SSL.
Nota
Usos del certificado:
- Para cifrar puertos en un nodo de IR autohospedado.
- Para la comunicación de nodo a nodo para la sincronización de estado, que incluye la sincronización de credenciales de servicios vinculados entre nodos.
- Cuando se usa un cmdlet de PowerShell para la configuración de credenciales del servicio vinculado desde una red local.
Es conveniente usar este certificado si el entorno de la red privada no es seguro o si quiere proteger la comunicación entre nodos en la red privada.
El movimiento de datos en tránsito desde un IR autohospedado y otros almacenes de datos siempre tiene lugar en un canal cifrado, independientemente de si este certificado está configurado o no.
Sincronización de credenciales
Si no almacena credenciales o valores secretos en una instancia de Azure Key Vault, las credenciales o los valores secretos se almacenarán en las máquinas donde se encuentre el entorno de ejecución de integración autohospedado. Cada nodo tendrá una copia de credencial con una versión determinada. Para que todos los nodos funcionen juntos, el número de versión debe ser el mismo para todos.
Consideraciones acerca del servidor proxy
Si en su entorno de red corporativo se usa un servidor proxy para acceder a Internet, configure el entorno de ejecución de integración autohospedado para utilizar la configuración del proxy adecuada. Puede establecer el proxy durante la fase de registro inicial.
Cuando se configura, el entorno de ejecución de integración autohospedado usa el servidor proxy para conectarse al origen y destino del servicio en la nube (que usan el protocolo HTTP o HTTPS). Por este motivo, debe seleccionar Cambiar vínculo durante la configuración inicial.
Hay tres opciones de configuración:
- No utilizar proxy: el entorno de ejecución de integración autohospedado no usa expresamente ningún proxy para conectarse a servicios en la nube.
- Usar proxy del sistema: el entorno Integration Runtime autohospedado utiliza la configuración de proxy de diahost.exe.config y diawp.exe.config. Si estos archivos no especifican ninguna configuración de proxy, el entorno de ejecución de integración autohospedado se conecta al servicio en la nube directamente sin pasar por ningún proxy.
- Usar proxy personalizado: establezca la configuración del proxy HTTP que se utilizará para el entorno de ejecución de integración autohospedado, en lugar de usar las configuraciones de diahost.exe.config y diawp.exe.config. Se requieren los valores de Dirección y Puerto. Los valores de Nombre de usuario y Contraseña son opcionales, y dependen de la configuración de la autenticación del proxy. Todas las configuraciones se cifran con DPAPI de Windows en el entorno de ejecución de integración autohospedado y se almacenan localmente en el equipo.
El servicio host del entorno de ejecución de integración se reinicia automáticamente después de guardar la configuración de proxy actualizada.
Tras registrar correctamente el entorno de ejecución de integración autohospedado, si quiere ver o actualizar la configuración de proxy, utilice Microsoft Integration Runtime Configuration Manager.
- Inicie el Administrador de configuración de Microsoft Integration Runtime.
- Seleccione la pestaña Configuración.
- En Proxy HTTP, seleccione el vínculo Cambiar para abrir el cuadro de diálogo Establecer proxy HTTP.
- Seleccione Next (Siguiente). En ese momento ve una advertencia en la que se le pide permiso para guardar la configuración del proxy y reiniciar el servicio de host del entorno de ejecución de integración.
Puede usar la herramienta Configuration Manager para ver y actualizar el proxy HTTP.
Nota
Si configura un servidor proxy con la autenticación NTLM, el servicio de host del entorno de ejecución de integración se ejecutará en la cuenta del dominio. Si más adelante cambia la contraseña de dicha cuenta, no olvide actualizar la configuración del servicio y reiniciarlo. Debido a este requisito, se recomienda acceder al servidor proxy con una cuenta de dominio dedicada que no requiera que se actualice la contraseña con frecuencia.
Configuración de un servidor proxy
Si selecciona la opción Usar proxy del sistema para el proxy HTTP, el entorno de ejecución de integración autohospedado utilizará la configuración de proxy de diahost.exe.config y diawp.exe.config. Cuando estos archivos no especifican ningún proxy, el entorno de ejecución de integración autohospedado se conecta al servicio en la nube directamente sin pasar por ningún proxy. En el procedimiento siguiente se proporcionan instrucciones para actualizar el archivo diahost.exe.config:
En el Explorador de archivos, cree una copia segura de C:\Archivos de programa\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config como copia de seguridad del archivo original.
Abra el Bloc de notas ejecutándolo como administrador.
En el Bloc de notas, abra el archivo de texto C:\Archivos de programa\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.
Encuentre la etiqueta predeterminada de system.net como se muestra en el siguiente código:
<system.net> <defaultProxy useDefaultCredentials="true" /> </system.net>
Después, puede agregar los detalles del servidor proxy tal y como se muestran en el ejemplo siguiente:
<system.net> <defaultProxy enabled="true"> <proxy bypassonlocal="true" proxyaddress="http://proxy.domain.org:8888/" /> </defaultProxy> </system.net>
La etiqueta de proxy permite propiedades adicionales para especificar la configuración requerida, como
scriptLocation
. Consulte <proxy> Elemento (Configuración de red) para ver la sintaxis.<proxy autoDetect="true|false|unspecified" bypassonlocal="true|false|unspecified" proxyaddress="uriString" scriptLocation="uriString" usesystemdefault="true|false|unspecified "/>
Guarde el archivo de configuración en su ubicación original. Luego reinicie el servicio de host del entorno de ejecución de integración autohospedado, lo que aplica los cambios.
Para reiniciar el servicio, use el applet de servicios del panel de control. O bien en Integration Runtime Configuration Manager, seleccione el botón Detener servicio y, después, seleccione Iniciar servicio.
Si el servicio no se inicia, es probable que se deba a que se ha agregado una sintaxis de etiqueta XML incorrecta en el archivo de configuración de la aplicación que se ha editado.
Importante
No olvide actualizar tanto diahost.exe.config como diawp.exe.config.
También tiene que asegurarse de que Microsoft Azure se encuentra en la lista de permitidos de su empresa. Puede descargar la lista de direcciones IP válidas de Azure. Los intervalos IP para cada nube, desglosados por región y servicios etiquetados en la nube en cuestión, ya están disponibles en el Centro de descarga de Microsoft:
- Pública: https://www.microsoft.com/download/details.aspx?id=56519
- Gobierno estadounidense: https://www.microsoft.com/download/details.aspx?id=57063
- Alemania: https://www.microsoft.com/download/details.aspx?id=57064
- China: https://www.microsoft.com/download/details.aspx?id=57062
Configurar el servidor proxy al usar un punto de conexión privado
Si la arquitectura de red de su empresa implica el uso de puntos de conexión privados y, por motivos de seguridad, la directiva de su empresa no permite una conexión directa a Internet desde la máquina virtual que hospeda Integration Runtime autohospedado a la dirección URL del servicio de Azure Data Factory, deberá permitir que se omita la dirección URL del servicio de ADF para obtener una conectividad completa. En el procedimiento siguiente se proporcionan instrucciones para actualizar el archivo diahost.exe.config. También debe repetir estos pasos para el archivo diawp.exe.config.
En el Explorador de archivos, cree una copia segura de C:\Archivos de programa\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config como copia de seguridad del archivo original.
Abra el Bloc de notas ejecutándolo como administrador.
En el Bloc de notas, abra C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.
Encuentre la etiqueta predeterminada de system.net como se muestra aquí:
<system.net> <defaultProxy useDefaultCredentials="true" /> </system.net>
Después, puede agregar los detalles de bypasslist tal y como se muestran en el ejemplo siguiente:
<system.net> <defaultProxy> <bypasslist> <add address = "[adfresourcename].[adfresourcelocation].datafactory.azure.net" /> </bypasslist> <proxy usesystemdefault="True" proxyaddress="http://proxy.domain.org:8888/" bypassonlocal="True" /> </defaultProxy> </system.net>
Posibles síntomas de problemas relacionados con el firewall y el servidor proxy
Si ve mensajes de error como los siguientes, lo más probable es que se deba a una configuración incorrecta del firewall o el servidor proxy. Dicha configuración impide que el entorno de ejecución de integración autohospedado se conecte a canalizaciones de Data Factory o Synapse para autenticarse. Para asegurarse de que tanto el firewall como el servidor proxy están configurados correctamente, consulte la sección anterior.
Al intentar registrar el entorno de ejecución de integración autohospedado, recibe el siguiente mensaje de error: "No se pudo registrar este nodo de Integration Runtime. Confirme que la clave de autenticación es válida y que el servicio host del servicio de integración se ejecuta en este equipo".
Al abrir Integration Runtime Configuration Manager, se ve uno de estos dos estados, Desconectado o Conectando. Al ver los registros de eventos de Windows, en Visor de eventos>Registros de aplicaciones y servicios>Microsoft Integration Runtime aparecen mensajes de error como este:
Unable to connect to the remote server A component of Integration Runtime has become unresponsive and restarts automatically. Component name: Integration Runtime (self-hosted).
Activación del acceso remoto desde una intranet
Si usa PowerShell para cifrar credenciales desde una máquina de la red que no sea la que tiene instalado el entorno de ejecución de integración autohospedado, puede habilitar la opción Acceso remoto desde la intranet. Si usa PowerShell para cifrar credenciales en la máquina en la que esté instalado el entorno de ejecución de integración autohospedado, no podrá habilitar el Acceso remoto desde la intranet.
Habilite el Acceso remoto desde la intranet para agregar otro nodo para que tanto la disponibilidad como la escalabilidad sean altas.
Al ejecutar el entorno de ejecución de integración autohospedado versión 3.3 o posterior, el instalador del entorno de ejecución de integración autohospedado deshabilita de manera predeterminada la opción Acceso remoto desde la intranet en la máquina de dicho entorno.
Al usar un firewall de un asociado comercial u otros, puede abrir manualmente el puerto 8060 o el puerto configurado por el usuario. Si se presenta un problema de firewall durante la configuración del entorno de ejecución de integración autohospedado, use el comando siguiente para instalarlo sin configurar el firewall:
msiexec /q /i IntegrationRuntime.msi NOFIREWALL=1
Si elige no abrir el puerto 8060 en la máquina del entorno de ejecución de integración autohospedado, use mecanismos que no sean la aplicación de Establecer credenciales para configurar las credenciales del almacén de datos. Por ejemplo, puede usar el cmdlet de PowerShell New-AzDataFactoryV2LinkedServiceEncryptCredential.
Puertos y firewalls
Estos son dos firewalls a considerar:
- El firewall corporativo que se ejecuta en el enrutador central de la organización.
- El firewall de Windows que está configurado como demonio en la máquina local en la que está instalado el entorno de ejecución de integración autohospedado.
A nivel de firewall corporativo, es preciso configurar los siguientes dominios y puertos de salida:
Nombres de dominio | Puertos de salida | Descripción |
---|---|---|
Nube pública: *.servicebus.windows.net Azure Government: *.servicebus.usgovcloudapi.net China: *.servicebus.chinacloudapi.cn |
443 | Lo necesita el entorno de ejecución de integración autohospedado para la creación interactiva. No es necesario si la creación interactiva autocontenida está habilitada. |
Nube pública: {datafactory}.{region}.datafactory.azure.net o bien *.frontend.clouddatahub.net Azure Government: {datafactory}.{region}.datafactory.azure.us China: {datafactory}.{region}.datafactory.azure.cn |
443 | El entorno de ejecución de integración autohospedado lo necesita para conectarse al servicio Data Factory. Para la nueva instancia de Data Factory creada en la nube pública, busque el nombre de dominio completo (FQDN) desde la clave de entorno de ejecución de integración autohospedado, que tiene el formato {data factory}. {region}.datafactory.azure.net. Para factoría de datos anterior y cualquier versión de Azure Synapse Analytics, si no ve el FQDN en la clave de integración autohospedada, use *.frontend.clouddatahub.net en su lugar. |
download.microsoft.com |
443 | Lo necesita el entorno de ejecución de integración autohospedado para descargar las actualizaciones. Si ha deshabilitado la actualización automática, puede omitir la configuración de este dominio. |
Dirección URL de Key Vault | 443 | Requerido por Azure Key Vault si almacena la credencial en Key Vault. |
En el nivel del firewall de Windows o nivel de máquina, normalmente estos puertos de salida están habilitados. Si no lo están, puede configurar los puertos y los dominios en la máquina del entorno de ejecución de integración autohospedado.
Nota
Ya que actualmente Azure Relay no admite la etiqueta de servicio, debe usar la etiqueta de servicio AzureCloud o Internet en las reglas de NSG para la comunicación con Azure Relay. Para comunicarse con Azure Data Factory y áreas de trabajo de Azure Synapse, puede usar la etiqueta de servicio DataFactoryManagement en la configuración de la regla de NSG.
En función del origen y de los receptores, es posible que tenga que permitir más dominios y puertos de salida al firewall corporativo o al firewall de Windows.
Nombres de dominio | Puertos de salida | Descripción |
---|---|---|
*.core.windows.net |
443 | Lo usa el entorno de ejecución de integración autohospedado para conectarse a la cuenta de Azure Storage cuando se utiliza la característica Copia almacenada provisionalmente. |
*.database.windows.net |
1433 | Solo es obligatorio cuando se copia desde o en Azure SQL Database o Azure Synapse Analytics. En caso contrario, es opcional. Use la característica de copia almacenada provisionalmente para copiar datos en SQL Database o Azure Synapse Analytics sin abrir el puerto 1433. |
*.azuredatalakestore.net login.microsoftonline.com/<tenant>/oauth2/token |
443 | Solo es necesario cuando se copia desde o en Azure Data Lake Store, sino es opcional. |
En algunas bases de datos en la nube, como Azure SQL Database y Azure Data Lake, es posible que tenga que permitir las direcciones IP de las máquinas del entorno de ejecución de integración autohospedado en la configuración de su firewall.
Nota
No deben instalarse Integration Runtime y la puerta de enlace de Power BI en la misma máquina, porque Integration Runtime usa principalmente el puerto 443, que es también uno de los puertos principales que usa la puerta de enlace de Power BI.
Creación interactiva independiente (versión preliminar)
Para realizar acciones de creación interactivas, como la vista previa de datos y las pruebas de conexión, el entorno de ejecución de integración autohospedado requiere una conexión a Azure Relay. Si no se establece la conexión, hay dos soluciones posibles para garantizar la funcionalidad ininterrumpida. La primera opción es agregar los puntos de conexión de Azure Relay a la lista de permitidos del firewall Obtener la dirección URL de Azure Relay. Como alternativa, puede habilitar la creación interactiva independiente.
Nota:
Si el entorno de ejecución de integración autohospedado no puede establecer una conexión a Azure Relay, su estado se marcará como "limitado".
Nota:
Aunque la creación interactiva independiente está habilitada, todo el tráfico de creación interactivo se enrutará exclusivamente a través de esta funcionalidad, omitiendo Azure Relay. El tráfico solo se redirigirá a Azure Relay una vez que decida deshabilitar esta característica.
Nota:
No se admiten "Obtener IP" ni "Enviar registro" cuando está habilitada la creación interactiva independiente.
Obtención de la URL de Azure Relay
Debe incluirse un dominio y puerto obligatorios en la lista de permitidos del firewall para la comunicación con Azure Relay. El entorno de ejecución de integración autohospedado usa estos elementos para la creación interactiva, como, por ejemplo, las conexiones de prueba, el examen de la lista de carpetas y tablas, la obtención de esquemas y la vista previa de los datos. Si no quiere permitir .servicebus.windows.net y desea tener direcciones URL más específicas, puede ver todos los nombres de dominio completo necesarios para el entorno de ejecución de integración autohospedado desde el portal del servicio.
Obtenga la dirección URL de Azure Relay a través de la interfaz de usuario:
Siga estos pasos:
Vaya al portal del servicio y seleccione su entorno de ejecución de integración autohospedado.
En la página Editar, seleccione Nodos.
Haga clic en View Service URL (Ver direcciones URL de servicio) para obtener todos los nombres de dominio completos.
Puede agregar estos nombres de dominio completos en la lista de permitidos de las reglas de firewall.
Nota
Para obtener más información relacionada con el protocolo de conexiones Azure Relay, consulte Protocolo de conexiones híbridas Azure Relay.
Obtenga la dirección URL de Azure Relay mediante script:
# The documentation of Synapse self hosted integration runtime (SHIR) mentions that the SHIR requires access to the Azure Service Bus IP addresses
# https://learn.microsoft.com/en-us/azure/data-factory/create-self-hosted-integration-runtime
# It is a requirement to use a wildcard (*.servicebus.windows.net) in your firewalls.
# While this is the easiest way to clear the firewall, it also opens the firewall to all Azure Service Bus IP addresses, including malicious_actor.servicebus.windows.net.
# This might be restricted by your security policies.
# This script resolves the Azure Service Bus IP addresses used by an integration runtime and adds them to the network security group (NSG) rule for the Synapse self-hosted integration runtime (SHIR).
# As the mapping of IP addresses to Domain Names might change, we recommend to run at least once a day to keep the NSG up to date.
# An alternative to running this script is to use the "Self-contained interactive authoring" feature of the self hosted integration runtime.
# Prerequisites:
# - PowerShell installed
# - Azure CLI (az) installed and logged in (https://learn.microsoft.com/en-us/cli/azure/)
# - signed in user needs rights to modify NSG (e.g. Network contributor) and to read status of the SHIR (e.g. reader), plus reader on the subscription
param (
[string]$synapseRresourceGroupName = "synapse_test",
[string]$nsgResourceGroupName = "adf_shir_rg",
[string]$synapseWorkspaceName = "synapse-test-jugi2",
[string]$integrationRuntimeName = "IntegrationRuntime2",
[string]$networkSecurityGroupName = "jugis-shir-nsg",
[string]$securityRuleName = "AllowSynapseServiceBusIPs",
[int]$priority = 100
)
# Check if the user is already logged in
$azAccount = az account show 2>$null
if (-not $azAccount) {
# Run az login with managed identity if not logged in
az login --identity
}
# Retrieve the URLs of the connections from the Synapse self-hosted integration runtime
$urls = az synapse integration-runtime get-status `
--resource-group $synapseResourceGroupName `
--workspace-name $synapseWorkspaceName `
--name $integrationRuntimeName `
--query "properties.serviceUrls" -o tsv
# Initialize an empty array to hold the IP addresses
$ipAddresses = @()
# Iterate over the URLs to resolve and collect the IP addresses
# The proper DNS resolution might only work within Azure, not locally
foreach ($url in $urls) {
Write-Output "Processing URL: $url"
$ip = [System.Net.Dns]::GetHostAddresses($url) | Where-Object { $_.AddressFamily -eq 'InterNetwork' } | Select-Object -ExpandProperty IPAddressToString
if ($ip) {
$ipAddresses += $ip
}
}
# Remove duplicate IP addresses from the array
$ipAddresses = $ipAddresses | Sort-Object -Unique
# Convert the array of IP addresses to a space-separated string
$ipAddressesString = $ipAddresses -join ' '
# Create or update the network security group rule to allow outbound traffic for the collected IP addresses
# Using Invoke-Expression to handle the command string
$az_cmd = "az network nsg rule create --resource-group $nsgResourceGroupName --nsg-name $networkSecurityGroupName --name $securityRuleName --priority $priority --destination-address-prefixes $ipAddressesString --destination-port-ranges '443' --direction Outbound --access Allow --protocol '*' --description 'Allow outbound access to Synapse servicebus IPs'"
Invoke-Expression $az_cmd
Copia de datos desde un origen a un receptor
Asegúrese de habilitar correctamente las reglas del firewall en el firewall corporativo, en el firewall de Windows de la máquina del entorno de ejecución de integración autohospedado y en el propio almacén de datos. De este modo, el entorno de ejecución de integración autohospedado podrá conectarse al origen y al receptor. Habilite las reglas de cada almacén de datos que participe en la operación de copia.
Por ejemplo, para copiar información de un almacén de datos local en un receptor de SQL Database o un receptor de Azure Synapse Analytics, debe realizar los siguientes pasos:
- Permita la comunicación TCP saliente en el puerto 1433 tanto para el firewall corporativo como para el firewall de Windows.
- Configure los valores del firewall de SQL Database para agregar la dirección IP de la máquina del entorno de ejecución de integración autohospedado a la lista de direcciones IP permitidas.
Nota
Si el firewall no permite el puerto de salida 1433, el entorno de ejecución de integración autohospedado no podrá acceder directamente a SQL Database. En este caso, puede usar una copia de almacenamiento temporal en SQL Database y Azure Synapse Analytics. En este escenario, se requiere solo HTTPS (puerto 443) para el movimiento de datos.
Si toda el origen de datos, el receptor y el entorno de ejecución de integración autohospedado están en un entorno local, entonces los datos copiados no irán a la nube sino que permanecerán estrictamente dentro del entorno local.
Almacén de credenciales
Hay dos maneras de almacenar las credenciales cuando se usa el entorno de ejecución de integración autohospedado:
- Usar Azure Key Vault.
Es la manera recomendada de almacenar las credenciales en Azure. El entorno de ejecución de integración autohospedado puede obtener las credenciales directamente de Azure Key Vault, lo que puede evitar considerablemente ciertos posibles problemas de seguridad o cualquier problema de sincronización de credenciales entre los nodos del entorno de ejecución de integración autohospedado. 2. Almacenar credenciales localmente.
Las credenciales se insertarán en la máquina del entorno de ejecución de integración auto-hospedado y se cifrarán. Cuando el entorno de ejecución de integración autohospedado se recupera de un bloqueo, puede recuperar la credencial de la copia de seguridad anterior o editar el servicio vinculado y permitir que se vuelva a insertar la credencial en el entorno de ejecución de integración autohospedado. De lo contrario, la canalización no funciona debido a la falta de credenciales al ejecutarse a través del entorno de ejecución de integración autohospedado.
Nota:
Si prefiere almacenar la credencial localmente, debe colocar el dominio para la creación interactiva en la lista de permitidos del firewall y abrir el puerto. Este canal también es para que el entorno de ejecución de integración auto-hospedado obtenga las credenciales. Para conocer el dominio y el puerto que se necesitan para la creación interactiva, consulte Puertos y firewalls.
Procedimientos recomendados de instalación
Para instalar el entorno de ejecución de integración autohospedado, descargue un paquete de instalación de identidad administrada del Centro de descarga de Microsoft. Consulte el artículo Movimiento de datos entre orígenes locales y la nube para obtener instrucciones detalladas.
- Configure un plan de energía en el equipo host para el entorno de ejecución de integración autohospedado con el fin de que el equipo no hiberne. Si el equipo host hiberna, el entorno de ejecución de integración autohospedado se pone en modo sin conexión.
- Realice regularmente una copia de las credenciales asociadas con el entorno de ejecución de integración autohospedado.
- Para automatizar las operaciones de configuración del entorno de ejecución de integración autohospedado, consulte Configuración de un entorno de ejecución de integración autohospedado existente mediante PowerShell.
Consideraciones importantes
Al instalar un entorno de ejecución de integración autohospedado, tenga en cuenta lo siguiente:
- Manténgalo cerca del origen de datos, pero no necesariamente en la misma máquina.
- No lo instale en la misma máquina que la puerta de enlace de Power BI.
- Solo Windows Server (los servidores de cifrado conformes con FIPS pueden provocar errores en los trabajos).
- Compártalo entre varios orígenes de datos.
- Compártalo entre varias factorías de datos.
Contenido relacionado
Para obtener instrucciones paso a paso, consulte Tutorial: Copia de datos locales en la nube.