Partager via

Créer et configurer un runtime d’intégration auto-hébergé

  • Article

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !

Le runtime d’intégration (IR) représente l’infrastructure de calcul utilisée par les pipelines Azure Data Factory et Synapse pour fournir des capacités d’intégration de données entre différents environnements réseau. Pour plus d’informations sur le runtime d’intégration (IR), consultez Runtime d’intégration dans Azure Data Factory.

Un runtime d’intégration auto-hébergé peut exécuter des activités de copie entre un magasin de données cloud et un magasin de données dans un réseau privé. Il peut aussi répartir les activités de transformation suivantes selon les ressources de calcul dans un réseau local ou un réseau virtuel Azure. L’installation d’un runtime d’intégration auto-hébergé nécessite une machine locale ou une machine virtuelle à l’intérieur d’un réseau privé.

Cet article décrit la façon dont vous pouvez créer et configurer un runtime d’intégration auto-hébergé.

Notes

Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour bien démarrer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.

Considérations relatives à l’utilisation du runtime d’intégration auto-hébergé

  • Vous pouvez utiliser un même runtime d’intégration auto-hébergé pour plusieurs sources de données locales. Vous pouvez également le partager avec une autre fabrique de données au sein du même locataire Microsoft Entra. Pour plus d’informations, consultez Partage du runtime d’intégration auto-hébergé avec plusieurs fabriques de données.
  • Vous ne pouvez installer qu’une seule instance d’un runtime d’intégration auto-hébergé sur une machine. En présence de deux fabriques de données devant accéder aux sources de données locales, utilisez la fonctionnalité de partage du runtime d’intégration auto-hébergé pour partager le runtime d’intégration auto-hébergé ou installez le runtime d’intégration auto-hébergé sur deux ordinateurs locaux, un pour chaque fabrique de données ou espace de travail Synapse. L'espace de travail Synapse ne prend pas en charge le partage d'exécution d'intégration.
  • Le runtime d’intégration auto-hébergé ne doit pas nécessairement se trouver sur la même machine que la source de données. Cela étant, la présence du runtime d’intégration auto-hébergé à proximité de la source de données réduit le temps de connexion du runtime d’intégration auto-hébergé à la source de données. Nous vous recommandons d’installer le runtime d’intégration auto-hébergé sur une machine différente de celle hébergeant la source de données locale. Lorsque le runtime d’intégration auto-hébergé et la source de données se trouvent sur des machines différentes, le runtime d’intégration auto-hébergé ne s'oppose pas à la source de données en termes de ressources.
  • Vous pouvez avoir plusieurs runtimes d’intégration auto-hébergés sur différentes machines connectées à la même source de données locale. Par exemple, si vous avez deux runtimes d’intégration auto-hébergés utilisés pour deux fabriques de données, la même source de données locale peut être inscrite auprès des deux fabriques de données.
  • Utilisez un runtime d’intégration auto-hébergé prendre en charge l’intégration des données au sein d’un réseau virtuel Azure.
  • Considérez votre source de données comme une source de données locale qui se trouve derrière un pare-feu, même lorsque vous utilisez Azure ExpressRoute. Utilisez le runtime d’intégration auto-hébergé pour connecter le service à la source de données.
  • Utiliser le runtime d’intégration auto-hébergé même si le magasin de données se trouve dans le cloud sur une infrastructure en tant que service (IaaS) Azure.
  • Les tâches peuvent échouer dans un runtime d’intégration auto-hébergé que vous avez installé sur un serveur Windows pour lequel le chiffrement compatible FIPS est activé. Pour contourner ce problème, vous avez deux options : stocker les informations d’identification/valeurs secrètes dans un Azure Key Vault ou désactiver le chiffrement conforme aux normes FIPS sur le serveur. Pour désactiver le chiffrement compatible FIPS, modifiez la valeur de la sous-clé du registre suivante de 1 (activé) à 0 (désactivé) : HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled. Si vous utilisez le runtime d’intégration auto-hébergé comme proxy pour le runtime d’intégration SSIS, le chiffrement conforme aux normes FIPS peut être activé et utilisé lors du déplacement de données de l’environnement local vers le stockage Blob Azure en tant que zone de transit.
  • Les détails complets relatifs à la licence sont fournis dans la première page de la configuration du runtime d’intégration autohébergé.

Notes

Actuellement, le runtime d’intégration auto-hébergé ne peut être partagé qu’avec plusieurs fabriques de données. Il ne peut pas être partagé entre des espaces de travail Synapse ou entre une fabrique de données et un espace de travail Synapse.

Flux de commandes et flux de données

Lorsque vous déplacez les données entre des machines locales et cloud, l’activité utilise un runtime d’intégration auto-hébergé pour transférer les données entre source de données locale au cloud.

Voici un résumé de haut niveau des étapes de flux de données pour la copie avec un IR auto-hébergé :

Vue d’ensemble du flux de données

  1. Un développeur de données crée d’abord un runtime d’intégration auto-hébergé dans une fabrique de données Azure ou dans un espace de travail Synapse à l’aide du portail Azure ou de la cmdlet PowerShell. Le développeur des données crée ensuite un service lié pour un magasin de données local en spécifiant l’instance de runtime d’intégration auto-hébergé que le service doit utiliser pour se connecter à des magasins de données.

  2. Le nœud du runtime d’intégration auto-hébergé chiffre les informations d’identification à l’aide de l’API de protection des données (DPAPI) Windows et les enregistre localement. Si plusieurs nœuds sont définis pour une haute disponibilité, les informations d’identification sont synchronisées sur les autres nœuds. Chaque nœud chiffre les informations d’identification à l’aide de DPAPI et les stocke localement. La synchronisation des informations d’identification est une opération transparente pour le développeur des données, et elle est gérée par le runtime d’intégration auto-hébergé.

  3. Azure Data Factory et les pipelines Synapse communiquent avec le runtime d’intégration auto-hébergé afin de planifier et de gérer les travaux. La communication s'effectue via un canal de contrôle qui utilise une connexion Azure Relay partagée. Lorsqu’une tâche de l’activité doit être lancée, le service place la requête en file d’attente, de même que les informations d’identification. Et ce au cas où les informations d'identification ne sont pas déjà stockées sur le runtime d’intégration auto-hébergé. Le runtime d’intégration auto-hébergé démarre le travail après interrogation de la file d’attente.

  4. Le runtime d’intégration auto-hébergé copie des données entre un magasin local et le stockage cloud. La direction de la copie dépend de la manière dont l’activité de copie est configurée dans le pipeline de données. Pour cette étape, le runtime d’intégration auto-hébergé communique directement avec les services de stockage cloud, comme le stockage Blob Azure, via un canal sécurisé (HTTPS).

Prérequis

  • Les versions de Windows Server prises en charge sont les suivantes :
    • Windows 10
    • Windows 11
    • Windows Server 2016
    • Windows Server 2019
    • Windows Server 2022

L’installation du runtime d’intégration auto-hébergé sur un contrôleur de domaine n’est pas prise en charge.

  • Le runtime d’intégration auto-hébergé nécessite un système d’exploitation 64 bits avec .NET Framework 4.7.2 ou ultérieur. Consultez Configuration système requise pour .NET Framework pour plus d’informations.
  • La configuration minimale recommandée pour la machine exécutant le runtime d’intégration auto-hébergé correspond à un processeur à 2 GHz avec 4 cœurs, 8 Go de RAM et 80 Go d’espace disponible sur le disque dur. Pour plus d'informations sur la configuration requise, consultez Télécharger.
  • Si la machine hôte est en veille prolongée, le runtime d’intégration auto-hébergé ne répond pas aux demandes de données. Configurez un plan d’alimentation approprié sur l’ordinateur avant d’installer le runtime d’intégration auto-hébergé. Si la machine est configurée pour se mettre en veille prolongée, le programme d'installation du runtime d’intégration auto-hébergé ouvre un message.
  • Vous devez disposer de droits d'administrateur sur la machine pour correctement installer et configurer le runtime d’intégration auto-hébergé.
  • L’activité de copie s’exécute selon une fréquence spécifique. L'utilisation du processeur et de la RAM sur la machine suit le même modèle avec des périodes de pointe et d’inactivité. L'utilisation des ressources dépend également en grande partie de la quantité de données déplacées. Lorsque plusieurs travaux sont en cours, vous constaterez une augmentation des ressources utilisées pendant les heures de pointe.
  • Les tâches peuvent échouer lors de l’extraction de données aux formats Parquet, ORC ou Avro. Pour plus d'informations sur Parquet, reportez-vous à Parquet format in Azure Data Factory. La création de fichiers s’exécute sur la machine d’intégration auto-hébergée. Pour fonctionner comme prévu, la création de fichiers requiert les conditions préalables suivantes :
    • Java Runtime (JRE) version 11 provenant d’un fournisseur JRE, comme Microsoft OpenJDK 11 ou Eclipse Temurin 11. Assurez-vous que la variable d’environnement du système JAVA_HOME est définie vers le dossier JDK (pas seulement le dossier JRE). Vous allez peut-être également devoir ajouter le dossier corbeille à la variable d’environnement PATH de votre système.

    Notes

    Il peut être nécessaire d’ajuster les paramètres Java si des erreurs de mémoire se produisent, comme décrit dans la documentation du format Parquet.

Notes

Si l’exécution a lieu dans un cloud gouvernemental, consultez Connexion au cloud gouvernemental.

Installation d’un runtime d’intégration auto-hébergé

Pour créer et installer un runtime d’intégration auto-hébergé, suivez les procédures ci-dessous.

Créer un runtime d’intégration auto-hébergé via Azure PowerShell

  1. Vous pouvez utiliser Azure PowerShell pour cette tâche. Voici un exemple :

    Set-AzDataFactoryV2IntegrationRuntime -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName -Type SelfHosted -Description "selfhosted IR description"

  2. Téléchargez et installez le runtime d’intégration auto-hébergé sur une machine locale.

  3. Récupérez la clé d’authentification et inscrivez le runtime d’intégration auto-hébergé à l’aide de la clé. Voici un exemple PowerShell :

    
Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName

Notes

Exécutez la commande PowerShell dans Azure Government, consultez Connexion à Azure Government avec PowerShell.

Créer un runtime d’intégration auto-hébergé via l’interface utilisateur

Suivez les étapes ci-dessous pour créer un runtime d’intégration auto-hébergé à l’aide de l’interface utilisateur Azure Data Factory ou Azure Synapse.

  1. Dans la page d’accueil de l’interface utilisateur d’Azure Data Factory, sélectionnez l’onglet Gérer dans le volet le plus à gauche.

    Bouton Gérer de la page d’accueil

  2. Sélectionnez Runtimes d’intégration dans le volet gauche, puis + Nouveau.

    Créer un runtime d’intégration

  3. Sur la page Configuration du runtime d’intégration, sélectionnez Azure, auto-hébergé, puis Continuer.

  4. Sur la page suivante, sélectionnez Auto-hébergé pour créer un runtime d’intégration auto-hébergé, puis sélectionnez Continuer. Créer un runtime d'intégration auto-hébergé

Configurer un runtime d’intégration auto-hébergé via l’interface utilisateur

  1. Entrez un nom pour votre runtime d’intégration, puis sélectionnez Créer.

  2. Sur la page Configuration du runtime d'intégration, sélectionnez le lien sous Option 1 pour ouvrir l'installation rapide sur votre ordinateur. Vous pouvez également suivre la procédure décrite sous Option 2 pour une installation manuelle. Les instructions suivantes sont basées sur l'installation manuelle :

    Installation du runtime d’intégration

    1. Copiez et collez la clé d’authentification. Sélectionnez Download and install integration runtime (Télécharger et installer le runtime d’intégration).

    2. Téléchargez le runtime d’intégration auto-hébergé sur un ordinateur Windows local. Exécutez le programme d’installation.

    3. Sur la page Inscrire le runtime d'intégration (auto-hébergé) , collez la clé que vous avez enregistrée précédemment, puis cliquez sur Inscrire.

      Inscrire le runtime d’intégration

    4. Dans la page Nouveau runtime d’intégration (auto-hébergé) , sélectionnez Terminer.

  3. Une fois le runtime d’intégration auto-hébergé correctement inscrit, la fenêtre suivante s'affiche :

    Inscription réussie

Installer un runtime d’intégration auto-hébergé sur une machine virtuelle Azure via un modèle Azure Resource Manager

Vous pouvez automatiser l'installation du runtime d’intégration auto-hébergé sur une machine virtuelle Azure à l’aide du modèle Créer un runtime d'intégration auto-hébergé. Le modèle permet de facilement disposer d'un runtime d’intégration auto-hébergé entièrement fonctionnel au sein d'un réseau virtuel Azure. Le runtime d'intégration offre des fonctionnalités de haute disponibilité et d’évolutivité, à condition de définir le nombre de nœuds sur 2 ou plus.

Installer un runtime d’intégration auto-hébergé existant via la version locale de PowerShell

Vous pouvez utiliser une ligne de commande pour configurer ou gérer un runtime d’intégration auto-hébergé existant. Cette utilisation contribue notamment à automatiser l’installation et l’inscription de nœuds de runtime d'intégration auto-hébergé.

Dmgcmd.exe est inclus dans le programme d'installation auto-hébergé. Cela se trouve généralement dans le dossier C:\Program Files\Microsoft Integration Runtime\5.0\Shared\. Cette application prend en charge différents paramètres et peut être appelé à l’aide d'une ligne de commande en utilisant des scripts de commandes par lot pour l’automatisation.

Utilisez l’application comme suit :

dmgcmd ACTION args...

Voici les détails relatifs aux actions et aux arguments de l'application :

ACTION args Description
-rn
-RegisterNewNode		 "<AuthenticationKey>" ["<NodeName>"] Inscrire un nœud de runtime d’intégration auto-hébergé avec la clé d’authentification et le nom de nœud spécifiés.
-era
-EnableRemoteAccess		 "<port>" ["<thumbprint>"] Activer l’accès à distance sur le nœud actuel pour configurer un cluster haute disponibilité. Il est également possible d'activer la définition des informations d’identification directement sur le runtime d’intégration auto-hébergé, sans passer par un espace de travail Azure Data Factory ou Azure Synapse. Pour ce faire, utilisez la cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential à partir d’une machine distante du même réseau.
-erac
-EnableRemoteAccessInContainer		 "<port>" ["<thumbprint>"] Activer l’accès à distance au nœud actif lorsque le nœud s’exécute dans le conteneur.
-dra
-DisableRemoteAccess		 Désactiver l’accès à distance au nœud actif. L’accès à distance est nécessaire pour une configuration à plusieurs nœuds. La cmdlet PowerShell New-AzDataFactoryV2LinkedServiceEncryptedCredential fonctionne toujours même lorsque l’accès à distance est désactivé. Ce comportement se vérifie tant que la cmdlet est exécutée sur le même ordinateur que le nœud du runtime d’intégration auto-hébergé.
-k
-Key		 "<AuthenticationKey>" Remplacer ou mettre à jour la clé d’authentification précédente. Utilisez cette action avec précaution. Elle peut entraîner la mise hors connexion de votre nœud du runtime d’intégration auto-hébergé précédent si la clé appartient à un nouveau runtime d’intégration.
-gbf
-GenerateBackupFile		 "<filePath>" "<password>" Générer un fichier de sauvegarde pour le nœud actif. Ce fichier inclut la clé du nœud et les informations d’identification du magasin de données.
-ibf
-ImportBackupFile		 "<filePath>" "<password>" Restaurer le nœud à partir d’un fichier de sauvegarde.
-r
-Restart		 Redémarrer le service hôte du runtime d'intégration auto-hébergé.
-s
-Start		 Démarrer le service hôte du runtime d'intégration auto-hébergé.
-t
-Stop		 Arrêter le service hôte du runtime d'intégration auto-hébergé.
-sus
-StartUpgradeService		 Démarrer le service hôte du runtime d'intégration auto-hébergé.
-tus
-StopUpgradeService		 Arrêter le service de mise à niveau du runtime d'intégration auto-hébergé.
-tonau
-TurnOnAutoUpdate		 Activer la mise à jour automatique du runtime d'intégration auto-hébergé. Cette commande concerne uniquement Azure Data Factory V1.
-toffau
-TurnOffAutoUpdate		 Désactiver la mise à jour automatique du runtime d'intégration auto-hébergé. Cette commande concerne uniquement Azure Data Factory V1.
-ssa
-SwitchServiceAccount		 "<domain\user>" ["<password>"] Définir DIAHostService de façon à ce qu’il s’exécute en tant que nouveau compte. Utilisez le mot de passe vide (« ») pour les comptes système et comptes virtuels.
-elma
-EnableLocalMachineAccess		 Activez l’accès de l’ordinateur local (localhost, adresse IP privée) sur le nœud IR auto-hébergé actuel. Dans le scénario de haute disponibilité IR auto-hébergé, l’action doit être appelée sur chaque nœud IR auto-hébergé.
-dlma
-DisableLocalMachineAccess		 Désactivez l’accès de l’ordinateur local (localhost, adresse IP privée) sur le nœud IR auto-hébergé actuel. Dans le scénario de haute disponibilité IR auto-hébergé, l’action doit être appelée sur chaque nœud IR auto-hébergé.
-DisableLocalFolderPathValidation Désactivez la validation de sécurité pour activer l’accès au système de fichiers de l’ordinateur local.
-EnableLocalFolderPathValidation Activez la validation de sécurité pour désactiver l’accès au système de fichiers de l’ordinateur local.
-eesp
-EnableExecuteSsisPackage		 Activez l’exécution de package SSIS sur le nœud IR auto-hébergé.
-desp
-DisableExecuteSsisPackage		 Désactivez l’exécution de package SSIS sur le nœud IR auto-hébergé.
-gesp
-GetExecuteSsisPackage		 Obtenez la valeur si l’option ExecuteSsisPackage est activée sur le nœud IR auto-hébergé.
Si la valeur retournée est true, ExecuteSSISPackage est activé ; si la valeur retournée est false ou nul, ExecuteSSISPackage est désactivé.

Installer et inscrire le runtime d’intégration auto-hébergé à partir du Centre de téléchargement Microsoft

  1. Rendez-vous sur la page de téléchargement du runtime d’intégration Microsoft.

  2. Sélectionnez Télécharger, la version 64 bits, puis Suivant. La version 32 bits n'est pas prise en charge.

  3. Exécutez le fichier MSI directement ou enregistrez-le sur votre disque dur avant de l’exécuter.

  4. Dans la fenêtre Bienvenue, sélectionnez une langue, puis Suivant.

  5. Acceptez les termes du contrat de licence du logiciel Microsoft et sélectionnez Suivant.

  6. Sélectionnez le dossier pour l’installation du runtime d’intégration auto-hébergé et sélectionnez Suivant.

  7. Sur la page Prêt pour l’installation, sélectionnez Installer.

  8. Cliquez sur Terminer pour terminer l’installation.

  9. Obtenez la clé d’authentification à l’aide PowerShell. Voici un exemple PowerShell pour récupérer la clé d’authentification :

    Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName

  10. Dans la fenêtre Inscrire un runtime d'intégration (auto-hébergé) du Gestionnaire de configuration de Microsoft Integration Runtime en cours d’exécution sur votre machine, procédez comme suit :

    1. Collez la clé d’authentification dans la zone de texte.

    2. Éventuellement, sélectionnez Afficher la clé d’authentification pour afficher le texte de la clé.

    3. Sélectionnez Inscription.

Notes

Les notes de publication sont disponibles sur la page de téléchargement du runtime d’intégration Microsoft.

Compte de service du runtime d'intégration auto-hébergé

Par défaut, le compte de service utilisé pour la connexion du runtime d'intégration auto-hébergé est NT SERVICE\DIAHostService. Celui-ci figure sous Services -> Runtime d’intégration -> Propriétés -> Connexion.

Compte de service du runtime d’intégration auto-hébergé

Assurez-vous que le compte dispose de l'autorisation Ouvrir une session en tant que service. À défaut, le démarrage du runtime d'intégration auto-hébergé échouera. Pour vérifier l’autorisation, accédez à Stratégie de sécurité locale -> Paramètres de sécurité -> Stratégies locales -> Attribution des droits utilisateur -> Ouvrir une session en tant que service

Capture d’écran du menu Stratégie de sécurité locale - Attribution des droits utilisateur

Capture d’écran de l’attribution de droits utilisateur Ouvrir une session en tant que service

Notifications et icônes de la zone de notification

Si vous déplacez votre curseur sur les icônes ou les messages de la zone de notification, vous pouvez consulter des informations supplémentaires sur l’état du runtime d’intégration auto-hébergé.

Notifications dans la zone de notification

Haute disponibilité et extensibilité

Vous pouvez associer un runtime d’intégration auto-hébergé à plusieurs machines locales ou machines virtuelles dans Azure. Ces ordinateurs sont appelés nœuds. Vous pouvez associer jusqu’à quatre nœuds à un runtime d’intégration auto-hébergé. La présence de plusieurs nœuds sur des machines locales avec une passerelle installée présente les avantages suivants pour une passerelle logique :

  • La haute disponibilité du runtime d’intégration auto-hébergé supprime le point de défaillance unique dans votre solution Big Data ou dans l’intégration de vos données cloud. Cette disponibilité contribue à garantir une continuité lorsque vous utilisez jusqu'à quatre nœuds.
  • Les performances et le débit lors du déplacement des données entre les magasins de données locaux et dans le cloud ont été améliorés. Plus d’informations sur les comparaisons des performances.

Vous pouvez associer plusieurs nœuds en installant le logiciel du runtime d’intégration auto-hébergé à partir du Centre de téléchargement. Ensuite, inscrivez-le à l’aide des clés d’authentification obtenues par le biais de la cmdlet New-AzDataFactoryV2IntegrationRuntimeKey, comme décrit dans le tutoriel.

Notes

Vous n'êtes pas tenu de créer un runtime d’intégration auto-hébergé pour associer chaque nœud. Vous pouvez installer le runtime d’intégration auto-hébergé sur une autre machine et l’inscrire à l’aide de la même clé d’authentification.

Notes

Avant d’ajouter un autre nœud de haute disponibilité et d’extensibilité, vérifiez que l’option Accès à distance à partir de l’intranet est activée sur le premier nœud. Pour ce faire, sélectionnez Gestionnaire de configuration Microsoft Integration Runtime>Paramètres>Accès à distance à l'intranet.

Considérations d’échelle

Scale-out

Si l'utilisation du processeur est élevé et la mémoire disponible faible sur le runtime d’intégration auto-hébergé, ajoutez un nouveau nœud pour permettre d’effectuer un scale-out de la charge sur les machines. Si des activités échouent parce qu’elles expirent ou que le nœud du runtime d’intégration auto-hébergé passe à l’état hors connexion, il est judicieux d’ajouter un nœud à la passerelle. Pour ajouter un nœud, procédez comme suit :

  1. Téléchargez la configuration du runtime d’intégration auto-hébergé (SHIR) à partir du portail Azure Data Factory.
  2. Exécutez le programme d’installation sur le nœud que vous souhaitez ajouter au cluster.
  3. Pendant l’installation, sélectionnez l’option pour joindre un runtime d’intégration existant et fournir la clé d’authentification à partir du SHIR existant afin de lier le nouveau nœud au cluster de SHIR existant.

Monter en puissance

Lorsque le processeur et la RAM disponible ne sont pas correctement utilisés, mais que l’exécution de travaux simultanés atteint les limites d’un nœud, procédez à une montée en puissance en augmentant le nombre de travaux simultanés qu'un nœud peut exécuter. Vous pouvez également procéder à une montée en puissance lorsque les activités expirent en raison d'une surcharge du runtime d’intégration auto-hébergé. Comme le montre l’image suivante, vous pouvez augmenter la capacité maximale d’un nœud :

Augmenter le nombre de travaux simultanés pouvant s’exécuter sur un nœud

Configuration requise des certificats TLS/SSL

Si vous souhaitez activer l’accès à distance à partir de l’intranet avec un certificat TLS/SSL (avancé) pour sécuriser la communication entre les nœuds du runtime d’intégration, vous pouvez suivre la procédure décrite dans Activation de l’accès à distance à partir de l’intranet avec un certificat TLS/SSL.

Notes

Ce certificat est utilisé :

  • Pour chiffrer les ports sur un nœud de runtime d'intégration auto-hébergé.
  • Pour la communication nœud à nœud à des fins de synchronisation d'état, ce qui comprend la synchronisation des informations d’identification des services liés entre les nœuds.
  • Lorsqu’une cmdlet PowerShell est utilisée pour les paramètres d’informations d’identification de service lié à partir d’un réseau local.

Nous vous conseillons d'utiliser ce certificat si votre environnement de réseau privé n'est pas sécurisé ou si vous souhaitez sécuriser la communication entre les nœuds de votre réseau privé.

Le déplacement des données en transit d'un runtime d'intégration auto-hébergé vers d'autres magasins de données se fait toujours au sein d'un canal chiffré, que ce certificat soit défini ou non.

Synchronisation des informations d’identification

Si vous ne stockez pas d’informations d’identification ou des valeurs secrètes dans un Azure Key Vault, les informations d’identification ou les valeurs secrètes sont stockées sur les ordinateurs où votre runtime d’intégration auto-hébergé se trouve. Chaque nœud aura une copie des informations d’identification avec une version spécifique. Pour que tous les nœuds fonctionnent ensemble, le numéro de version doit être le même pour tous les nœuds.

Considérations relatives aux serveurs proxy

Si votre environnement de réseau d’entreprise utilise un serveur proxy pour accéder à Internet, configurez le runtime d’intégration auto-hébergé pour utiliser les bons paramètres de proxy. Vous pouvez définir le proxy lors de la phase initiale de l’enregistrement.

Spécifiez le proxy.

Une fois configuré, le runtime d’intégration auto-hébergé utilise le serveur proxy pour se connecter à la source et à la destination du service cloud (à l'aide du protocole HTTP ou HTTPS). C'est la raison pour laquelle vous sélectionnez Changer le lien lors de la configuration initiale.

Configurer le proxy

Il existe trois options de configuration :

  • Ne pas utiliser de proxy : le runtime d’intégration auto-hébergé n’utilise pas explicitement de proxy pour se connecter aux services cloud.
  • Utiliser le proxy système : le runtime d’intégration autohébergé utilise le paramètre de proxy configuré dans diahost.exe.config et diawp.exe.config. Si ces fichiers ne spécifient aucune configuration de proxy, le runtime d’intégration auto-hébergé se connecte directement au service cloud sans passer par un proxy.
  • Utiliser un proxy personnalisé : configurez les paramètres du proxy HTTP à utiliser pour le runtime d’intégration auto-hébergé au lieu d’utiliser les configurations dans diahost.exe.config et diawp.exe.config. Les valeurs Adresse et Port sont requises. Les valeurs Nom d’utilisateur et Mot de passe sont facultatives, en fonction des paramètres d’authentification de votre proxy. Tous les paramètres sont chiffrés avec Windows DPAPI sur le runtime d’intégration autohébergé et stockés localement sur l’ordinateur.

Le service hôte du runtime d’intégration auto-hébergé redémarre automatiquement après avoir enregistré les paramètres de proxy mis à jour.

Une fois le runtime d’intégration auto-hébergé inscrit, si vous souhaitez afficher ou mettre à jour les paramètres de proxy, utilisez le Gestionnaire de configuration Microsoft Integration Runtime.

  1. Ouvrez le Gestionnaire de configuration de Microsoft Integration Runtime.
  2. Sélectionnez l’onglet Paramètres.
  3. Sous Proxy HTTP, sélectionnez le lien Modifier pour ouvrir la boîte de dialogue Définir le proxy HTTP.
  4. Sélectionnez Suivant. Vous pouvez voir un avertissement demandant l’autorisation d’enregistrer les paramètres de proxy et de redémarrer le service hôte du runtime d’intégration.

Vous pouvez utiliser l'outil Gestionnaire de configuration pour afficher et mettre à jour le proxy HTTP.

Afficher et mettre à jour le proxy

Notes

Si vous configurez un serveur proxy avec l’authentification NTLM, le service hôte du runtime d’intégration s’exécute sous le compte du domaine. Si vous modifiez ultérieurement le mot de passe du compte du domaine, veillez à mettre à jour les paramètres de configuration du service et à redémarrer ce dernier. En raison de cette exigence, nous vous conseillons d'accéder au serveur proxy à l'aide d'un compte de domaine dédié qui ne nécessite pas de mettre à jour le mot de passe fréquemment.

Configurer les paramètres du serveur proxy

Si vous sélectionnez l'option Utiliser le proxy système pour le proxy HTTP, le runtime d’intégration auto-hébergé utilise les paramètres du proxy dans diahost.exe.config et diawp.exe.config. Si ces fichiers ne spécifient aucun proxy, le runtime d’intégration auto-hébergé se connecte directement au service cloud sans passer par un proxy. La procédure suivante fournit des instructions pour mettre à jour le fichier diahost.exe.config :

  1. Dans l’Explorateur de fichiers, effectuez une copie de sauvegarde de C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config en tant que sauvegarde du fichier d’origine.

  2. Ouvrez le Bloc-notes en tant qu’administrateur.

  3. Dans le Bloc-notes, ouvrez le fichier texte C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

  4. Localisez la balise par défaut system.net comme indiqué dans le code suivant :

    <system.net>
    <defaultProxy useDefaultCredentials="true" />
</system.net>

    Vous pouvez ensuite ajouter les détails du serveur proxy comme illustré dans l’exemple suivant :

    <system.net>
    <defaultProxy enabled="true">
          <proxy bypassonlocal="true" proxyaddress="http://proxy.domain.org:8888/" />
    </defaultProxy>
</system.net>

    La balise de proxy permet des propriétés supplémentaires pour spécifier les paramètres requis comme scriptLocation. Reportez-vous <proxy> élément (paramètres réseau) pour connaître la syntaxe.

    <proxy autoDetect="true|false|unspecified" bypassonlocal="true|false|unspecified" proxyaddress="uriString" scriptLocation="uriString" usesystemdefault="true|false|unspecified "/>

  5. Enregistrez le fichier config dans son emplacement d’origine. Redémarrez ensuite le service hôte du runtime d’intégration auto-hébergé, qui relève les modifications.

    Pour redémarrer le service, utilisez l’applet des services dans le Panneau de configuration. Ou, dans le Gestionnaire de configuration Integration Runtime, sélectionnez le bouton Arrêter le service, puis Démarrer le service.

    Si le service ne démarre pas, il est probable que vous ayez ajouté une syntaxe de balise XML incorrecte au fichier de configuration de l’application modifié.

Important

N’oubliez pas de mettre à jour diahost.exe.config et diawp.exe.config.

Vous devez également vérifier que Microsoft Azure figure dans la liste d’autorisation de votre entreprise. Vous pouvez télécharger la liste des adresses IP Azure valides. Les plages d’adresses IP pour chaque cloud, réparties par région et par les services marqués dans ce cloud, sont désormais disponibles sur MS Download :

Configurer les paramètres du serveur proxy lors de l’utilisation d’un point de terminaison privé

Si l’architecture réseau de votre entreprise implique l’utilisation de points de terminaison privés et que, pour des raisons de sécurité, la stratégie de votre entreprise n’autorise pas une connexion Internet directe de la machine virtuelle hébergeant l’Integration Runtime auto-hébergé dans l’URL du service Azure Data Factory, vous devez alors autoriser le contournement de l’URL du service ADF pour une connectivité complète. La procédure suivante fournit des instructions pour mettre à jour le fichier de configuration diahost.exe.config. Vous devez également répéter ces étapes pour le fichier diawp.exe.config.

  1. Dans l’Explorateur de fichiers, effectuez une copie de sauvegarde de C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config en tant que sauvegarde du fichier d’origine.

  2. Ouvrez le Bloc-notes en tant qu’administrateur.

  3. Dans le Bloc-notes, ouvrez C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

  4. Localisez la balise par défaut system.net comme illustré ici :

    <system.net>
    <defaultProxy useDefaultCredentials="true" />
</system.net>

    Vous pouvez ensuite ajouter les détails de bypasslist comme illustré dans l’exemple suivant :

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

Si des messages d’erreur semblables aux suivants s’affichent, il est fort probable qu'ils soient dus à une mauvaise configuration du pare-feu ou du serveur proxy. Une telle configuration empêche le runtime d’intégration auto-hébergé de se connecter à des pipelines Data Factory ou Synapse à des fins d'authentification. Pour vous assurer que votre pare-feu et votre serveur proxy sont correctement configurés, reportez-vous à la section précédente.

  • Lorsque vous tentez d’inscrire le runtime d’intégration auto-hébergé, le message d'erreur suivant s'affiche : Échec d’inscription de ce nœud Runtime d’intégration ! Vérifiez que la clé d’authentification est valide et que le service hôte d’intégration est en cours d’exécution sur cette machine.

  • Lorsque vous ouvrez le Gestionnaire de configuration Integration Runtime, l’état indiqué est Déconnecté ou En cours de connexion. Lorsque vous affichez les journaux des événements Windows, sous Observateur d’événements>Journaux des applications et services>Microsoft Integration Runtime, des messages d’erreur tels que le suivant s’affichent :

    Unable to connect to the remote server
A component of Integration Runtime has become unresponsive and restarts automatically. Component name: Integration Runtime (self-hosted).

Activer l'accès à distance à partir d'un intranet

Si vous utilisez PowerShell pour chiffrer les informations d’identification à partir d’une machine en réseau autre que celle sur laquelle vous avez installé le runtime d’intégration auto-hébergé, vous pouvez activer l’option Accès à distance à partir de l’intranet. Si vous exécutez PowerShell pour chiffrer les informations d’identification sur la machine sur laquelle vous avez installé le runtime d’intégration auto-hébergé, vous ne pouvez pas activer l’option Accès à distance à partir de l’intranet.

Activer l’option Accès à distance à partir de l’intranet avant d’ajouter un autre nœud à des fins de haute disponibilité et d’extensibilité.

Lorsque vous exécutez la configuration du runtime d’intégration auto-hébergé version 3.3 ou ultérieure, par défaut, l’installation du runtime d’intégration auto-hébergé désactive l’option Accès à distance à partir de l’intranet sur la machine du runtime d’intégration auto-hébergé.

Lorsque vous utilisez le pare-feu d’un partenaire ou autres, vous pouvez manuellement ouvrir le port 8060 ou le port configuré par l’utilisateur. Si vous rencontrez des problèmes de pare-feu lors de la configuration du runtime intégration auto-hébergé, utilisez la commande suivante pour installer le runtime intégration auto-hébergé sans configurer le pare-feu :

msiexec /q /i IntegrationRuntime.msi NOFIREWALL=1

Si vous choisissez de ne pas ouvrir le port 8060 sur la machine du runtime intégration auto-hébergé, utilisez d’autres mécanismes que l’application Définition des informations d’identification pour configurer les informations d’identification du magasin de données. Vous pouvez, par exemple, utiliser l’applet de commande PowerShell New-AzDataFactoryV2LinkedServiceEncryptCredential.

Ports et pare-feu

Il existe deux pare-feu à prendre en compte :

  • Le pare-feu d’entreprise qui s’exécute sur le routeur central de l’organisation.
  • Le pare-feu Windows configuré en tant que démon sur l’ordinateur local sur lequel est installé le runtime d’intégration auto-hébergé.

Pare-feu

Au niveau du pare-feu d’entreprise, vous devez configurer les domaines et ports de sortie suivants :

Noms de domaine Ports sortants Description
Cloud public : *.servicebus.windows.net
Azure Government : *.servicebus.usgovcloudapi.net
Chine : *.servicebus.chinacloudapi.cn		 443 Requis par le runtime d’intégration auto-hébergé pour la création interactive. Non requis si la création interactive autonome est activée.
Cloud public : {datafactory}.{region}.datafactory.azure.net
ou *.frontend.clouddatahub.net
Azure Government : {datafactory}.{region}.datafactory.azure.us
Chine : {datafactory}.{region}.datafactory.azure.cn		 443 Requis par le runtime d’intégration auto-hébergé pour se connecter au service Data Factory.
Pour les Data Factory nouvellement créées dans le cloud public, recherchez le nom de domaine complet (FQDN) à partir de votre clé runtime d’intégration auto-hébergée, qui se présente sous le format {data factory}.{region}.datafactory.azure.net. Pour les anciennes Data Factory et toutes les versions d’Azure Synapse Analytics, si vous ne voyez pas le FQDN dans votre clé d’intégration auto-hébergée, utilisez plutôt *.frontend.clouddatahub.net.
download.microsoft.com 443 Exigé par le runtime d’intégration auto-hébergé pour télécharger les mises à jour. Si vous avez désactivé la mise à jour automatique, vous pouvez ignorer la configuration de ce domaine.
URL du coffre de clés 443 Requis par Azure Key Vault si vous stockez les informations d’identification dans Key Vault.

Au niveau du pare-feu Windows ou au niveau de la machine, ces ports de sortie sont normalement activés. Dans le cas contraire, vous pouvez configurer les domaines et les ports sur une machine du runtime d’intégration auto-hébergé.

Notes

Dans la mesure où Azure Relay ne prend actuellement pas en charge l'étiquette de service, vous devez utiliser l'étiquette de service AzureCloud ou Internet dans les règles de groupe de sécurité réseau pour la communication avec Azure Relay. Pour la communication avec des espaces de travails Azure Data Factory et Synapse, vous pouvez utiliser l'étiquette de service DataFactoryManagement dans la configuration des règles de groupe de sécurité réseau.

Selon votre source et vos récepteurs, vous devrez peut-être autoriser des domaines et des ports de sortie supplémentaires dans votre pare-feu d’entreprise ou Windows.

Noms de domaine Ports sortants Description
*.core.windows.net 443 Utilisé par le runtime d’intégration auto-hébergé pour se connecter au compte de stockage Azure lorsque vous utilisez la fonctionnalité copie intermédiaire.
*.database.windows.net 1433 Nécessaire seulement quand vous copiez depuis ou vers Azure SQL Database ou Azure Synapse Analytics ; sinon, facultatif. Utilisez la fonctionnalité de copie intermédiaire pour copier des données vers SQL Database ou Azure Synapse Analytics sans ouvrir le port 1433.
*.azuredatalakestore.net
login.microsoftonline.com/<tenant>/oauth2/token		 443 Nécessaire lorsque vous copiez depuis ou vers Azure Data Lake Store, sinon, facultatif.

Pour certaines bases de données cloud, comme Azure SQL Database et Azure Data Lake, vous devrez peut-être autoriser les adresses IP des machines du runtime d’intégration auto-hébergé dans la configuration du pare-feu.

Notes

Il n’est pas approprié d’installer Integration Runtime et la passerelle Power BI sur la même machine, car Integration Runtime utilise principalement le numéro de port 443, qui est également l’un des principaux ports utilisés par la passerelle Power BI.

Création interactive autonome (aperçu)

Afin d'effectuer des actions de création interactives telles que la prévisualisation des données et les tests de connexion, le runtime d'intégration auto-hébergé nécessite une connexion à Azure Relay. Si la connexion n'est pas établie, il existe deux solutions possibles pour assurer une fonctionnalité ininterrompue. La première option consiste à ajouter les points de terminaison Azure Relay à la liste d'autorisation de votre pare-feu Obtenir l'URL du relais Azure. Vous pouvez également activer la création interactive autonome.

Notes

Si le runtime d'intégration auto-hébergé ne parvient pas à établir une connexion à Azure Relay, son état sera marqué comme « limité ».

Capture d'écran de la création interactive autonome.

Notes

Lorsque la création interactive autonome est activée, tout le trafic de création interactive sera acheminé exclusivement via cette fonctionnalité, en contournant Azure Relay. Le trafic ne sera redirigé vers Azure Relay qu'une fois que vous aurez choisi de désactiver cette fonctionnalité.

Notes

"Obtenir l'IP" et "Envoyer le journal" ne sont pas pris en charge lorsque la création interactive autonome est activée.

Obtenir l'URL d'Azure Relay

Un domaine et un port requis doivent être placés dans la liste d’autorisation de votre pare-feu pour la communication avec Azure Relay. Le runtime d'intégration auto-hébergé les utilisera pour la création interactive, par exemple pour tester la connexion, parcourir la liste des dossiers et la liste des tables, obtenir le schéma et afficher un aperçu des données. Si vous ne souhaitez pas autoriser .servicebus.windows.net et tenez à bénéficier d'URL plus spécifiques, vous pouvez afficher tous les noms de domaine complets requis par le runtime d'intégration auto-hébergé à partir du portail du service.

Obtenir l'URL d'Azure Relay par le biais des IU :

Effectuez les étapes suivantes :

  1. Accédez au portail du service et sélectionnez votre runtime d'intégration auto-hébergé.

  2. Sur la page Modifier, sélectionnez Nœuds.

  3. Sélectionnez Afficher les URL de service pour obtenir tous les noms de domaine complets.

    URL d'Azure Relay

  4. Vous pouvez ajouter ces noms de domaine complets à la liste d’autorisation des règles de pare-feu.

Notes

Pour plus d’informations sur le protocole de connexions Azure Relay, consultez Protocole de connexions hybrides Azure Relay.

Obtenir l'URL d'Azure Relay par le biais du 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

Copier des données d’une source vers un récepteur

Assurez-vous de correctement activer les règles de pare-feu sur le pare-feu d’entreprise, le pare-feu Windows de la machine du runtime d’intégration auto-hébergé, ainsi le magasin de données lui-même. Activer ces règles permet au runtime d’intégration auto-hébergé de se connecter correctement à la source et au récepteur. Activez les règles pour chaque magasin de données impliqué dans l’opération de copie.

Par exemple, pour copier à partir d’une banque de données locale vers un récepteur SQL Database ou un récepteur Azure Synapse Analytics, effectuez les opérations suivantes :

  1. Autorisez le trafic TCP sortant sur le port 1433 pour le pare-feu Windows et le pare-feu d’entreprise.
  2. Configurez les paramètres de pare-feu de la base de données SQL pour ajouter l’adresse IP de la machine du runtime d’intégration auto-hébergé à la liste des adresses IP autorisées.

Notes

Si votre pare-feu n’autorise pas le port de sortie 1433, le runtime d’intégration auto-hébergé ne peut pas accéder directement à la base de données SQL. Dans ce cas, vous pouvez effectuer une copie intermédiaire vers SQL Database et Azure Synapse Analytics. Dans ce scénario, vous avez uniquement besoin du protocole HTTPS (port 443) pour le déplacement des données.

Si l’ensemble de votre source de données et de votre récepteur et du runtime d’intégration auto-hébergé se trouvent dans un environnement local, les données copiées ne sont pas dans le cloud, mais restent strictement dans un environnement local.

Stockage des informations d’identification

Il existe deux façons de stocker les informations d’identification lors de l’utilisation du runtime d’intégration auto-hébergé :

  1. Utiliser Azure Key Vault.

Il s’agit de la méthode recommandée pour stocker vos informations d’identification dans Azure. Le runtime d’intégration auto-hébergé peut récupérer directement les informations d’identification depuis Azure Key Vault qui peut véritablement éviter certains problèmes de sécurité potentiels ou des problèmes de synchronisation d’informations d’identification entre les nœuds du runtime d’intégration auto-hébergé. 2. Stocker des informations d’identification localement.

Les informations d’identification sont poussées vers l’ordinateur de votre runtime d’intégration auto-hébergé et chiffrées. Lorsque votre runtime d’intégration auto-hébergé est récupéré suite à un plantage, vous pouvez récupérer les informations d’identification à partir de celui que vous sauvegardez avant ou modifier le service lié et laisser les informations d’identification être de nouveau poussées vers le runtime d’intégration auto-hébergé. Sinon, le pipeline ne fonctionne pas en raison du manque d’informations d’identification lors de l’exécution via le runtime d’intégration auto-hébergé.

Notes

Si vous préférez stocker les informations d’identification localement, vous devez mettre le domaine pour la création interactive dans la liste d’autorisation de votre pare-feu et ouvrir le port. Ce canal est également destiné au runtime d’intégration auto-hébergé pour obtenir les informations d’identification. Pour connaître le domaine et le port nécessaires à la création interactive, reportez-vous à Ports et pare-feu.

Bonnes pratiques d’installation

Vous pouvez installer le runtime d’intégration auto-hébergé en téléchargeant un package de configuration d’identité gérée à partir du Centre de téléchargement Microsoft. Pour des instructions pas à pas, consultez l’article Déplacement de données entre des sources locales et le cloud.

  • Configurez un plan d’alimentation sur la machine hôte du runtime d’intégration auto-hébergé afin d’empêcher la mise en veille prolongée de la machine. Si cette dernière se met en veille prolongée, le runtime d’intégration auto-hébergé passe à l’état hors connexion.
  • Sauvegardez régulièrement les informations d’identification associées au runtime d’intégration auto-hébergé.
  • Pour automatiser les opérations d’installation du runtime d’intégration auto-hébergé, consultez Installer un runtime d’intégration auto-hébergé existant via PowerShell.

Considérations importantes

Lors de l’installation d’un runtime d’intégration auto-hébergé, tenez compte des éléments suivants

  • Gardez-la à proximité de votre source de données, mais pas nécessairement sur la même machine
  • Ne l’installez pas sur la même machine que la passerelle Power BI
  • Windows Server uniquement (les serveurs de chiffrement conformes à FIPS peuvent entraîner l’échec des travaux)
  • Partager entre plusieurs sources de données
  • Partager entre plusieurs fabriques de données

Contenu connexe

Pour obtenir des instructions pas à pas, consultez le Tutoriel : Copier des données locales dans le cloud.