Erstellen und Konfigurieren einer selbstgehosteten Integration Runtime

GILT FÜR: Azure Data Factory Azure Synapse Analytics

Tipp

Testen Sie Data Factory in Microsoft Fabric, einer All-in-One-Analyselösung für Unternehmen. Microsoft Fabric deckt alles von der Datenverschiebung bis hin zu Data Science, Echtzeitanalysen, Business Intelligence und Berichterstellung ab. Erfahren Sie, wie Sie eine neue Testversion kostenlos starten können!

Die Integrationslaufzeit (IR) ist die Computeinfrastruktur, die Azure Data Factory- und Synapse-Pipelines verwenden, um Datenintegrationsfunktionen in verschiedenen Netzwerkumgebungen bereitzustellen.

Eine selbst gehostete Integrationslaufzeit bietet diese Funktionen zwischen einem Clouddatenspeicher und einem Datenspeicher in einem privaten Netzwerk, z. B. einem lokalen Netzwerk oder einem virtuellen Azure-Netzwerk. In diesem Artikel wird beschrieben, wie Sie eine selbst gehostete IR auf einem Computer innerhalb Ihres privaten Netzwerks erstellen und konfigurieren können, damit Sie Ihre Datenquelle mit Ihren Datenintegrationsressourcen verbinden können.

Hinweis

Es wird empfohlen, das Azure Az PowerShell-Modul für die Interaktion mit Azure zu verwenden. Informationen zu den ersten Schritten finden Sie unter Installieren von Azure PowerShell. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zu Az.

Aspekte der Nutzung einer selbstgehosteten IR

• Sie können eine einzelne selbstgehostete Integration Runtime für mehrere lokale Datenquellen verwenden. Außerdem haben Sie die Möglichkeit, sie für eine andere Data Factory im selben Microsoft Entra-Mandanten freizugeben. Weitere Informationen finden Sie unter Freigeben einer selbst gehosteten Integrationslaufzeit.
• Sie können auf einem Computer nur jeweils eine Instanz der selbstgehosteten Integration Runtime installieren. Wenn Sie über zwei Datenfabriken verfügen, die auf lokale Datenquellen zugreifen müssen, verwenden Sie entweder das selbst gehostete IR-Freigabefeature , um die selbst gehostete IR freizugeben, oder installieren Sie die selbst gehostete IR auf zwei lokalen Computern, eine für jede Datenfabrik oder einen Synapse-Arbeitsbereich. Die Integration Runtime-Freigabe wird vom Synapse-Arbeitsbereich nicht unterstützt.
• Die selbstgehostete Integration Runtime muss sich nicht auf demselben Computer wie die Datenquelle befinden. Wenn sich die selbstgehostete Integration Runtime jedoch in der Nähe der Datenquelle befindet, dauert es weniger lange, bis die selbstgehostete Integration Runtime eine Verbindung mit der Datenquelle hergestellt hat. Wir empfehlen Ihnen, die selbstgehostete Integration Runtime nicht auf dem Computer zu installieren, auf dem die lokale Datenquelle gehostet wird. Wenn sich die selbstgehostete Integration Runtime und die Datenquelle auf unterschiedlichen Computern befinden, steht die selbstgehostete Integration Runtime mit der Datenquelle nicht im Wettbewerb um Ressourcen.
• Sie können über mehrere selbstgehostete Integration Runtimes auf verschiedenen Computern verfügen, die eine Verbindung mit der gleichen lokalen Datenquelle herstellen. Wenn Sie beispielsweise über zwei selbstgehostete Integration Runtimes verfügen, die zwei Data Factorys mit Daten versorgen, kann dieselbe lokale Datenquelle für beide Data Factorys registriert werden.
• Verwenden Sie eine selbstgehostete Integration Runtime, um die Datenintegration in einem virtuellen Azure-Netzwerk zu unterstützen.
• Behandeln Sie Ihre Datenquelle wie eine lokale Datenquelle, die sich hinter einer Firewall befindet, selbst wenn Sie Azure ExpressRoute verwenden. Verwenden Sie die selbstgehostete Integration Runtime, um den Dienst mit der Datenquelle zu verbinden.
• Verwenden Sie die selbstgehostete Integration Runtime auch, wenn sich der Datenspeicher in der Cloud auf einem virtuellen Azure IaaS-Computer (Infrastructure-as-a-Service) befindet.
• Bei einer selbstgehosteten Integration Runtime, die Sie auf einem Windows Server-Computer mit aktivierter FIPS-konformer Verschlüsselung installiert haben, treten für Aufgaben unter Umständen Fehler auf. Um dieses Problem zu umgehen, stehen Ihnen zwei Möglichkeiten zur Verfügung: Speichern von Anmeldeinformationen oder Geheimnissen in einer Azure Key Vault-Instanz oder Deaktivieren der FIPS-konformen Verschlüsselung auf dem Server. Zum Deaktivieren der FIPS-konformen Verschlüsselung ändern Sie den folgenden Wert des Registrierungsschlüssels „1“ (aktiviert) in „0“ (deaktiviert): HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled. Wenn Sie die selbst gehostete Integrationslaufzeit als Proxy für die SSIS-Integrationslaufzeit verwenden, kann die FIPS-kompatible Verschlüsselung aktiviert werden und verwendet werden, wenn Daten von lokal in Azure Blob Storage als Stagingbereich verschoben werden.
• Die vollständigen Angaben zur Lizenzierung finden Sie auf der ersten Seite des Setups der selbstgehosteten Integration Runtime.

Hinweis

Derzeit kann die selbstgehostete Integration Runtime nur für mehrere Data Factorys freigegeben werden. Sie kann nicht für Synapse-Arbeitsbereiche oder zwischen Data Factory und Synapse-Arbeitsbereichen freigegeben werden.

Befehls- und Datenfluss

Wenn Sie Daten zwischen der lokalen Umgebung und der Cloud verschieben, wird für die Aktivität eine selbstgehostete Integration Runtime verwendet, um die Daten zwischen einer lokalen Datenquelle und der Cloud zu übertragen.

Es folgt eine allgemeine Zusammenfassung der Datenflussschritte zum Kopieren per selbstgehosteter IR:

1. Eine für die Datenentwicklung zuständige Person erstellt zunächst mit dem Azure-Portal oder dem PowerShell-Cmdlet eine selbstgehostete IR in einer Azure Data Factory oder einem Synapse-Arbeitsbereich. Anschließend erstellt diese Person einen verknüpften Dienst für einen lokalen Datenspeicher, indem sie die Instanz der selbstgehosteten Integration Runtime angibt, die der Dienst zum Verbinden der Datenspeicher verwenden soll.

2. Über den Knoten der selbstgehosteten Integration Runtime werden die Anmeldeinformationen per DPAPI (Windows Data Protection Application Programming Interface) verschlüsselt und lokal gespeichert. Falls mehrere Knoten festgelegt sind, um Hochverfügbarkeit zu erzielen, werden die Anmeldeinformationen für andere Knoten weiter synchronisiert. Jeder Knoten verschlüsselt die Anmeldeinformationen mithilfe von DPAPI und speichert sie lokal. Die Synchronisierung der Anmeldeinformationen ist für die für die Datenentwicklung zuständige Person transparent und wird von der selbstgehosteten IR verarbeitet.

3. Azure Data Factory- und Synapse-Pipelines kommunizieren mit der selbstgehosteten IR, um Aufträge zu planen und zu verwalten. Die Kommunikation erfolgt über einen Kontrollkanal, der eine freigegebene Azure Relay-Verbindung verwendet. Wenn ein Aktivitätsauftrag ausgeführt werden muss, stellt der Dienst die Anforderung zusammen mit allen Anmeldeinformationen in die Warteschlange. Dieser Schritt wird durchgeführt, falls die Anmeldeinformationen nicht bereits unter der selbstgehosteten Integration Runtime gespeichert sind. Die selbstgehostete Integration Runtime startet den Auftrag, nachdem die Warteschlange abgefragt wurde.

4. Die selbstgehostete Integration Runtime kopiert Daten zwischen einem lokalen Speicher und Cloudspeicher. Die Richtung des Kopiervorgangs hängt davon ab, wie die Kopieraktivität in der Datenpipeline konfiguriert ist. Für diesen Schritt kommuniziert die selbstgehostete Integration Runtime über einen sicheren HTTPS-Kanal direkt mit einem cloudbasierten Speicherdienst, z. B. Azure Blob Storage.

Voraussetzungen

• Die unterstützten Versionen von Windows lauten:
  • Windows 10
  • Windows 11
  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2022
  • Windows Server 2025

Die Installation der selbstgehosteten Integration Runtime auf einem Domänencontroller wird nicht unterstützt.

• Die selbstgehostete Integration Runtime erfordert ein 64-Bit-Betriebssystem mit .NET Framework 4.7.2 oder höher. Ausführliche Informationen finden Sie unter .NET Framework-Systemanforderungen .
• Die empfohlene Mindestkonfiguration für den Computer mit der selbstgehosteten Integration Runtime ist ein 2-GHz-Prozessor mit 4 Kernen, 8 GB RAM und 80 GB verfügbarem Speicherplatz auf dem Datenträger. Einzelheiten zu den Systemanforderungen finden Sie unter "Herunterladen".
• Wenn sich der Hostcomputer im Ruhezustand befindet, reagiert die selbstgehostete Integration Runtime nicht auf Datenanforderungen. Konfigurieren Sie vor der Installation der selbstgehosteten Integration Runtime einen entsprechenden Energiesparplan auf dem Computer. Wenn für den Computer der Ruhezustand konfiguriert ist, wird im Installationsprogramm für die selbstgehostete Integration Runtime eine Meldung angezeigt.
• Sie müssen die administrierende Person des Computers sein, um die selbstgehostete Integration Runtime erfolgreich installieren und konfigurieren zu können.
• Ausführungen der Kopieraktivität werden mit einer bestimmten Häufigkeit durchgeführt. Die Prozessor- und RAM-Nutzung auf dem Computer folgt dem gleichen Muster mit Spitzen- und Leerlaufzeiten. Außerdem ist die Ressourcenverwendung auch stark von der Menge der Daten abhängig, die verschoben werden. Wenn mehrere Kopieraufträge in Bearbeitung sind, steigt die Ressourcenverwendung zu Spitzenzeiten an.
• Unter Umständen tritt für Aufgaben während der Extraktion von Daten in den Formaten Parquet, ORC oder Avro ein Fehler auf. Weitere Informationen zu Parkett finden Sie im Parkettformat in Azure Data Factory. Die Dateierstellung wird auf dem Computer mit der selbstgehosteten Integration Runtime ausgeführt. Damit die Dateierstellung wie erwartet funktioniert, müssen die folgenden Voraussetzungen erfüllt sein:
  • Java Runtime (JRE) Version 11 von einem JRE-Anbieter wie Microsoft OpenJDK 11 oder Eclipse Temurin 11. Stellen Sie sicher, dass die JAVA_HOME Systemumgebungsvariable auf den JDK-Ordner (nicht nur den JRE-Ordner) festgelegt ist, müssen Sie möglicherweise auch den Bin-Ordner zur PATH-Umgebungsvariablen Ihres Systems hinzufügen.

  Hinweis

  Es kann erforderlich sein, die Java-Einstellungen anzupassen, wenn Speicherfehler auftreten, wie in der Dokumentation zum Parkettformat beschrieben.

Hinweis

Wenn Sie in der Regierungs-Cloud arbeiten, überprüfen Sie "Connect to Government Cloud".

Einrichten einer selbstgehosteten Integration Runtime

Verwenden Sie die folgenden Verfahren, um eine selbstgehostete Integration Runtime zu erstellen und einzurichten.

Erstellen einer selbstgehosteten IR mit Azure PowerShell

1. Sie können Azure PowerShell für diese Aufgabe verwenden. Ein Beispiel:

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

2. Laden Sie die selbst gehostete Integrationslaufzeit auf einem lokalen Computer herunter, und installieren Sie sie.

3. Rufen Sie den Authentifizierungsschlüssel ab, und registrieren Sie die selbstgehostete Integration Runtime mit dem Schlüssel. Hier ist ein PowerShell-Beispiel:

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

Hinweis

Wenn Sie in der Regierungs-Cloud arbeiten, überprüfen Sie "Connect to Government Cloud".

Erstellen einer selbstgehosteten IR über die Benutzeroberfläche

Führen Sie die unten angegebenen Schritte aus, um über die Azure Data Factory- oder Azure Synapse-Benutzeroberfläche eine selbstgehostete IR zu erstellen.

Azure Data Factory

1. Wählen Sie auf der Startseite der Azure Data Factory-Benutzeroberfläche die Registerkarte "Verwalten" im äußerst linken Bereich aus.

   

2. Wählen Sie im linken Bereich Integrationslaufzeiten und dann +Neu aus.

   

3. Wählen Sie auf der Seite zum Einrichten der IntegrationslaufzeitAzure, Self-Hosted und dann "Continue" aus.

4. Wählen Sie auf der folgenden Seite "Self-Hosted" aus, um eine Self-Hosted IR zu erstellen, und wählen Sie dann "Weiter" aus.

Azure Synapse

1. Wählen Sie auf der Startseite der Azure Synapse-Benutzeroberfläche im Bereich ganz links die Registerkarte „Verwalten“ aus.

   

2. Wählen Sie im linken Bereich Integrationslaufzeiten und dann +Neu aus.

   

3. Wählen Sie auf der folgenden Seite "Self-Hosted" aus, um eine Self-Hosted IR zu erstellen, und wählen Sie dann "Weiter" aus.

Konfigurieren einer selbstgehosteten IR über die Benutzeroberfläche

1. Geben Sie einen Namen für Ihre IR ein, und wählen Sie "Erstellen" aus.

2. Wählen Sie auf der Seite zum Einrichten der Integrationslaufzeit den Link unter Option 1 aus, um das Express-Setup auf Ihrem Computer zu öffnen. Oder führen Sie die Schritte unter Option 2 aus, um manuell einzurichten. Die folgende Anleitung basiert auf dem manuellen Setup:

   

   1. Kopieren Sie den Authentifizierungsschlüssel, und fügen Sie ihn ein. Wählen Sie die Option Integration Runtime herunterladen und installieren aus.

   2. Führen Sie den Download der selbstgehosteten Integration Runtime auf einem lokalen Windows-Computer durch. Führen Sie das Installationsprogramm aus.

   3. Fügen Sie auf der Seite "Integrationslaufzeit registrieren" (selbst gehostet) den zuvor gespeicherten Schlüssel ein, und wählen Sie "Registrieren" aus.

      

   4. Wählen Sie auf der Seite Neuer Knoten von Integration Runtime (selbstgehostet) die Option Fertig stellen aus.

3. Nachdem die selbstgehostete Integration Runtime erfolgreich registriert wurde, wird das folgende Fenster angezeigt:

   

Einrichten einer selbstgehosteten IR auf einer Azure-VM über eine Azure Resource Manager-Vorlage

Sie können die Einrichtung der selbstgehosteten Integration Runtime (IR) auf einer Azure-VM automatisieren, indem Sie die Vorlage Selbst gehostete Integration Runtime erstellen verwenden. Die Vorlage ist eine einfache Möglichkeit, um eine voll funktionsfähige selbstgehostete Integration Runtime in einem virtuellen Azure-Netzwerk zu erstellen. Die IR verfügt über Features für Hochverfügbarkeit und Skalierbarkeit, sofern Sie die Knotenanzahl mindestens auf „2“ festlegen.

Einrichten einer vorhandenen selbstgehosteten IR über eine lokale PowerShell-Instanz

Sie können eine Befehlszeile verwenden, um eine vorhandene selbstgehostete IR einzurichten oder zu verwalten. Dies kann besonders hilfreich sein, um die Installation und Registrierung von Knoten für die selbstgehostete IR zu automatisieren.

Die Datei „dmgcmd.exe“ ist im selbstgehosteten Installationsprogramm enthalten. Normalerweise befindet sie sich im Ordner „C:\Programme\Microsoft Integration Runtime\5.0\Shared\“. Diese Anwendung unterstützt verschiedene Parameter und kann über eine Befehlszeile mithilfe von Batchskripts für die Automatisierung aufgerufen werden.

Nutzen Sie die Anwendung wie folgt:

dmgcmd ACTION args...

Hier finden Sie Details zu den Aktionen und Argumenten der Anwendung:

AKTION	Argumente	Beschreibung
-rn, -RegisterNewNode	"<AuthenticationKey>" ["<NodeName>"]	Knoten einer selbstgehosteten Integration Runtime mit dem angegebenen Authentifizierungsschlüssel und Knotennamen registrieren
-era, -EnableRemoteAccess	"<port>" ["<thumbprint>"]	Remotezugriff auf den aktuellen Knoten zum Einrichten eines Hochverfügbarkeitsclusters aktivieren. Oder Aktivierung des direkten Festlegens von Anmeldeinformationen für die selbstgehostete IR ohne Umweg über Azure Data Factory oder den Azure Synapse-Arbeitsbereich. Für Letzteres verwenden Sie das Cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential auf einem Remotecomputer in demselben Netzwerk.
-erac, -EnableRemoteAccessInContainer	"<port>" ["<thumbprint>"]	Remotezugriff auf den aktuellen Knoten aktivieren, wenn der Knoten in einem Container ausgeführt wird
-dra, -DisableRemoteAccess		Remotezugriff auf den aktuellen Knoten deaktivieren. Der Remotezugriff ist zum Einrichten von mehreren Knoten erforderlich. Das PowerShell-Cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential funktioniert auch dann noch, wenn der Remotezugriff deaktiviert ist. Dies ist der Fall, sofern das Cmdlet auf demselben Computer ausgeführt wird, auf dem sich auch der Knoten für die selbstgehostete IR befindet.
-k, -Key	"<AuthenticationKey>"	Vorherigen Authentifizierungsschlüssel überschreiben oder aktualisieren. Verwenden Sie diese Aktion mit Bedacht. Ihr Knoten der selbstgehostete IR wird ggf. in den Offlinezustand versetzt, wenn der Schlüssel von einer neuen Integration Runtime stammt.
-gbf, -GenerateBackupFile	"<filePath>" "<password>"	Eine Sicherungsdatei für den aktuellen Knoten generieren. Die Sicherungsdatei enthält den Knotenschlüssel und die Anmeldeinformationen für den Datenspeicher.
-ibf, -ImportBackupFile	"<filePath>" "<password>"	Knoten aus einer Sicherungsdatei wiederherstellen
-r, -Restart		Hostdienst der selbstgehosteten Integration Runtime neu starten
-s, -Start		Hostdienst der selbstgehosteten Integration Runtime starten
-t, -Stop		Hostdienst der selbstgehosteten Integration Runtime beenden
-sus, -StartUpgradeService		Upgradedienst der selbstgehosteten Integration Runtime starten
-tus, -StopUpgradeService		Upgradedienst der selbstgehosteten Integration Runtime beenden
-tonau, -TurnOnAutoUpdate		Automatische Aktualisierung der selbstgehosteten Integration Runtime aktivieren. Dieser Befehl gilt nur für Azure Data Factory V1.
-toffau, -TurnOffAutoUpdate		Automatische Aktualisierung der selbstgehosteten Integration Runtime deaktivieren. Dieser Befehl gilt nur für Azure Data Factory V1.
-ssa, -SwitchServiceAccount	"<domain\user>" ["<password>"]	DIAHostService für die Ausführung als neues Konto festlegen. Verwenden Sie ein leeres Kennwort („“) für Systemkonten und virtuelle Konten.
-elma, -EnableLocalMachineAccess		Lokalen Computerzugriff (Localhost, private IP-Adresse) auf dem aktuellen Knoten mit der selbstgehosteten IR aktivieren. In einem Szenario mit einer selbstgehosteten Integration Runtime mit Hochverfügbarkeit muss die Aktion für jeden Knoten mit der selbstgehosteten IR aufgerufen werden.
-dlma, -DisableLocalMachineAccess		Lokalen Computerzugriff (Localhost, private IP-Adresse) auf dem aktuellen Knoten mit der selbstgehosteten IR deaktivieren. In einem Szenario mit einer selbstgehosteten Integration Runtime mit Hochverfügbarkeit muss die Aktion für jeden Knoten mit der selbstgehosteten IR aufgerufen werden.
-DisableLocalFolderPathValidation		Sicherheitsüberprüfung deaktivieren, um den Zugriff auf das Dateisystem des lokalen Computers zu aktivieren
-EnableLocalFolderPathValidation		Sicherheitsüberprüfung aktivieren, um den Zugriff auf das Dateisystem des lokalen Computers zu deaktivieren
-eesp, -EnableExecuteSsisPackage		Die Ausführung des SSIS-Pakets auf einem selbstgehosteten IR-Knoten aktivieren
-desp, -DisableExecuteSsisPackage		Die Ausführung des SSIS-Pakets auf einem selbstgehosteten IR-Knoten deaktivieren
-gesp, -GetExecuteSsisPackage		Den Wert abrufen, wenn die Option „ExecuteSsisPackage” auf einem Knoten mit selbstgehosteter IR aktiviert ist. Wenn der zurückgegebene Wert „true“ ist, ist „ExecuteSSISPackage“ aktiviert. Wenn der zurückgegebene Wert „false“ oder NULL ist, ist „ExecuteSSISPackage“ deaktiviert.

Installieren und Registrieren einer selbstgehosteten IR über das Microsoft Download Center

1. Navigieren Sie zur Downloadseite für die Microsoft Integration Runtime.

2. Wählen Sie "Herunterladen", dann die 64-Bit-Version und dann "Weiter" aus. Die 32-Bit-Version wird nicht unterstützt.

3. Führen Sie die MSI-Datei direkt aus, oder speichern Sie sie zur späteren Ausführung auf Ihrer Festplatte.

4. Wählen Sie im Willkommensfenster eine Sprache und dann "Weiter" aus.

5. Akzeptieren Sie die Microsoft-Software-Lizenzbedingungen, und wählen Sie "Weiter" aus.

6. Wählen Sie einen Ordner aus, um die selbst gehostete Integrationslaufzeit zu installieren, und wählen Sie "Weiter" aus.

7. Wählen Sie auf der Seite "Bereit zum Installieren " die Option "Installieren" aus.

8. Wählen Sie "Fertig stellen " aus, um die Installation abzuschließen.

9. Rufen Sie den Authentifizierungsschlüssel über PowerShell ab. Hier ist ein PowerShell-Beispiel zum Abrufen des Authentifizierungsschlüssels:

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

10. Führen Sie im Fenster "Integrationslaufzeit registrieren" (selbst gehostet) von Microsoft Integration Runtime Configuration Manager, das auf Ihrem Computer ausgeführt wird, die folgenden Schritte aus:

    1. Fügen Sie im Textbereich den Authentifizierungsschlüssel ein.

    2. Wählen Sie optional " Authentifizierungsschlüssel anzeigen " aus, um den Schlüsseltext anzuzeigen.

    3. Wählen Sie "Registrieren" aus.

Hinweis

Versionshinweise sind auf derselben Downloadseite zur Microsoft-Integrations-Runtime verfügbar.

Dienstkonto für die selbstgehostete Integration Runtime

Das Standardmäßige Anmeldedienstkonto der selbst gehosteten Integrationslaufzeit ist NT SERVICE\DIAHostService. Sie können ihn in Services -> Integration Runtime Service -> Eigenschaften -> Anmelden sehen.

Stellen Sie sicher, dass das Konto über die Berechtigung „Anmelden als Dienst“ verfügt. Andernfalls kann die selbstgehostete Integration Runtime nicht erfolgreich gestartet werden. Sie können die Berechtigung in der lokalen Sicherheitsrichtlinie> – Sicherheitseinstellungen –> lokale Richtlinien – Benutzerrechtezuweisung –>> Anmelden als Dienst überprüfen.

Symbole des Benachrichtigungsbereichs und Benachrichtigungen

Wenn Sie Ihren Cursor auf das Symbol bzw. die Nachricht im Benachrichtigungsbereich bewegen, können Sie die Details zum Status der selbstgehosteten Integration Runtime anzeigen.

Hochverfügbarkeit und Skalierbarkeit

Sie können eine selbstgehostete Integration Runtime mehreren lokalen Computern oder virtuellen Computern in Azure zuordnen. Diese Computer werden als Knoten bezeichnet. Einer selbstgehosteten Integration Runtime können bis zu vier Knoten zugeordnet sein. Die Vorteile der Nutzung mehrerer Knoten auf lokalen Computern mit installiertem Gateway für ein logisches Gateway sind:

• Höhere Verfügbarkeit der selbstgehosteten IR, damit es nicht mehr die einzige Fehlerquelle (Single Point of Failure) in Ihrer Big Data-Lösung oder Clouddatenintegration mit Data Factory ist. Auf diese Weise wird die Kontinuität mit bis zu vier Knoten sichergestellt.
• Verbesserung in Bezug auf die Leistung und den Durchsatz während der Datenverschiebung zwischen lokalen und cloudbasierten Datenspeichern. Erhalten Sie weitere Informationen zu Leistungsvergleichen.

Sie können mehrere Knoten zuordnen, indem Sie die selbst gehostete Integrationslaufzeitsoftware aus dem Download Center installieren. Registrieren Sie sie dann mithilfe eines der Authentifizierungsschlüssel, die aus dem New-AzDataFactoryV2IntegrationRuntimeKey-Cmdlet abgerufen wurden, wie im Lernprogramm beschrieben.

Hinweis

Für die Zuordnung zu den einzelnen Knoten müssen Sie nicht jeweils eine neue selbstgehostete Integration Runtime erstellen. Sie können die selbstgehostete Integration Runtime auf einem anderen Computer installieren und mit dem gleichen Authentifizierungsschlüssel registrieren.

Hinweis

Bevor Sie einen weiteren Knoten für hohe Verfügbarkeit und Skalierbarkeit hinzufügen, stellen Sie sicher, dass die Option "Remotezugriff auf Intranet " auf dem ersten Knoten aktiviert ist. Wählen Sie dazu die Einstellungen des Konfigurations-Managers>> für Microsoft Integration Runtimefür den Remotezugriff auf das Intranet aus.

Aspekte der Skalierung

Aufskalieren

Wenn die Prozessorauslastung hoch und für die selbstgehostete Integration Runtime nur wenig Arbeitsspeicher verfügbar ist, sollten Sie einen neuen Knoten hinzufügen, um das Aufskalieren für die Computer zu unterstützen. Falls für Aktivitäten ein Fehler auftritt, weil ein Timeout auftritt oder die selbstgehostete IR offline ist, ist es hilfreich, wenn Sie dem Gateway einen Knoten hinzufügen. Führen Sie zum Hinzufügen eines Knotens folgende Schritte aus:

1. Laden Sie das SHIR-Setup aus dem Azure Data Factory-Portal herunter.
2. Führen Sie den Installer auf dem Knoten aus, den Sie dem Cluster hinzufügen möchten.
3. Wählen Sie während der Installation die Option aus, einer vorhandenen Integration Runtime beizutreten, und stellen Sie den Authentifizierungsschlüssel aus dem vorhandenen SHIR bereit, um den neuen Knoten mit dem vorhandenen SHIR-Cluster zu verknüpfen.

Hochskalieren

Wenn der Prozessor und der verfügbare RAM keine gute Auslastung aufweisen, die Ausführung von gleichzeitigen Aufträgen aber in die Nähe des Grenzwerts eines Knotens kommt, sollten Sie hochskalieren. Erhöhen Sie hierzu die Anzahl von gleichzeitigen Aufträgen, die von einem Knoten ausgeführt werden können. Es kann auch hilfreich sein, hochzuskalieren, wenn für Aktivitäten ein Timeout auftritt, weil die selbstgehostete IR überlastet ist. Wie in der folgenden Abbildung gezeigt, können Sie die maximale Kapazität für einen Knoten erhöhen:

TLS/SSL-Zertifikatanforderungen

Wenn Sie den Remotezugriff über das Intranet mit TLS/SSL-Zertifikat (Erweitert) aktivieren möchten, um die Kommunikation zwischen Integrationslaufzeitknoten zu sichern, können Sie die Schritte unter Aktivieren des Remotezugriffs über das Intranet mit TLS/SSL-Zertifikat ausführen.

Hinweis

Dieses Zertifikat wird für folgende Zwecke verwendet:

• Zum Verschlüsseln von Ports auf dem Knoten einer selbstgehosteten IR
• Für die Knoten-zu-Knoten-Kommunikation bei der Statussynchronisierung, einschließlich der knotenübergreifenden Synchronisierung der Anmeldeinformationen von verknüpften Diensten
• Bei Verwendung eines PowerShell-Cmdlets für die Einstellungen für die Anmeldeinformationen von verknüpften Diensten in einem lokalen Netzwerk

Es wird empfohlen, dieses Zertifikat zu verwenden, wenn Ihre private Netzwerkumgebung nicht sicher ist oder wenn Sie die Kommunikation zwischen Knoten in Ihrem privaten Netzwerk sichern möchten.

Die Datenverschiebung während der Übertragung von einer selbstgehosteten IR in andere Datenspeicher erfolgt immer über einen verschlüsselten Kanal – unabhängig davon, ob dieses Zertifikat festgelegt ist.

Synchronisierung von Anmeldeinformationen

Wenn Sie keine Anmeldeinformationen oder geheimen Werte in einem Azure Key Vault speichern, werden die Anmeldeinformationen oder geheimen Werte auf den Computern gespeichert, auf denen sich Ihre selbst gehostete Integrationslaufzeit befindet. Jeder Knoten verfügt über eine Kopie der Anmeldeinformationen mit einer bestimmten Version. Damit alle Knoten zusammenarbeiten, sollte die Versionsnummer für alle Knoten identisch sein.

Aspekte bei Proxyservern

Konfigurieren Sie die selbstgehostete Integration Runtime mit den geeigneten Proxyeinstellungen, wenn die Netzwerkumgebung Ihres Unternehmens einen Proxyserver für den Internetzugriff verwendet. Sie können den Proxy während der anfänglichen Registrierungsphase festlegen.

Wenn die selbstgehostete Integration Runtime konfiguriert ist, verwendet sie den Proxyserver zum Herstellen der Verbindung mit der Quelle und dem Ziel des Clouddiensts (für die das HTTP- oder HTTPS-Protokoll verwendet wird). Aus diesem Grund wählen Sie beim anfänglichen Setup die Option Verknüpfung ändern aus.

Es gibt drei Konfigurationsoptionen:

• Verwenden Sie keinen Proxy: Die selbst gehostete Integrationslaufzeit verwendet keinen Proxy, um eine Verbindung mit Clouddiensten herzustellen.
• Verwenden Sie den Systemproxy: Die selbst gehostete Integrationslaufzeit verwendet die Proxyeinstellung, die in diahost.exe.config und diawp.exe.configkonfiguriert ist. Wenn diese Dateien keine Proxykonfiguration angeben, stellt die selbst gehostete Integrationslaufzeit eine direkte Verbindung mit dem Clouddienst bereit, ohne einen Proxy durchzugehen.
• Verwenden Sie benutzerdefinierten Proxy: Konfigurieren Sie die HTTP-Proxyeinstellung für die selbst gehostete Integrationslaufzeit, anstatt Konfigurationen in diahost.exe.config und diawp.exe.configzu verwenden. Adress - und Portwerte sind erforderlich. Die Werte für Benutzername und Kennwort sind je nach Authentifizierungseinstellung des Proxys optional. Alle Einstellungen werden für die selbstgehostete Integration Runtime per Windows DPAPI verschlüsselt und lokal auf dem Computer gespeichert.

Der Hostdienst der Integration Runtime wird automatisch neu gestartet, nachdem Sie die aktualisierten Proxyeinstellungen gespeichert haben.

Wenn Sie nach der Registrierung der selbstgehosteten Integration Runtime die Proxyeinstellungen anzeigen oder aktualisieren möchten, können Sie den Konfigurations-Manager für Microsoft Integration Runtime verwenden.

1. Öffnen Sie Microsoft Integration Runtime Configuration Manager.
2. Wählen Sie die Registerkarte "Einstellungen " aus.
3. Wählen Sie unter HTTP-Proxy den Link "Ändern " aus, um das Dialogfeld "HTTP-Proxy festlegen " zu öffnen.
4. Wählen Sie "Weiter" aus. Eine Warnung wird angezeigt, in der Sie um Zustimmung gebeten werden, die Proxyeinstellung zu speichern und den Hostdienst der Integration Runtime neu zu starten.

Sie können das Konfigurations-Manager-Tool verwenden, um den HTTP-Proxy anzuzeigen und zu aktualisieren.

Hinweis

Wenn Sie einen Proxyserver mit NTLM-Authentifizierung einrichten, wird der Hostdienst der Integration Runtime unter dem Domänenkonto ausgeführt. Wenn Sie später das Kennwort für das Domänenkonto ändern, sollten Sie daran denken, die Konfigurationseinstellungen für den Dienst entsprechend zu aktualisieren und den Dienst neu zu starten. Aufgrund dieser Anforderung empfehlen wir Ihnen, mit einem dedizierten Domänenkonto auf den Proxyserver zuzugreifen, für das das Kennwort nicht regelmäßig aktualisiert werden muss.

Konfigurieren von Proxyservereinstellungen

Wenn Sie die Option "Systemproxy verwenden" für den HTTP-Proxy auswählen, verwendet die selbst gehostete Integrationslaufzeit die Proxyeinstellungen in diahost.exe.config und diawp.exe.config. Wenn diese Dateien keinen Proxy angeben, stellt die selbst gehostete Integrationslaufzeit eine direkte Verbindung mit dem Clouddienst bereit, ohne einen Proxy durchzugehen. Das folgende Verfahren enthält Anweisungen für die Aktualisierung der Datei „diahost.exe.config“:

1. Erstellen Sie im Datei-Explorer eine sichere Kopie von C:\Programme\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config als Sicherung der Originaldatei.

2. Öffnen Sie Editor als Admin.

3. Öffnen Sie in Editor die Textdatei „C:\Programme\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config“.

4. Suchen Sie das Standardtag system.net wie im folgenden Code dargestellt:

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

   Anschließend können Sie die Proxyserverdetails wie im folgenden Beispiel gezeigt hinzufügen:

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

   Mit dem Proxytag können zusätzliche Eigenschaften verwendet werden, um erforderliche Einstellungen wie scriptLocation anzugeben. Syntax finden Sie unter <Proxyelement> (Netzwerkeinstellungen ).

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

5. Speichern Sie die Konfigurationsdatei am ursprünglichen Speicherort. Starten Sie dann den Hostdienst für die selbstgehostete Integration Runtime, der die Änderungen übernimmt.

   Starten Sie den Dienst mit dem Applet „Dienste“ in der Systemsteuerung neu. Oder wählen Sie in Integration Runtime Configuration Manager die Schaltfläche " Dienst beenden " und dann " Dienst starten" aus.

   Wenn der Dienst nicht gestartet wird, haben Sie wahrscheinlich in der von Ihnen bearbeiteten Anwendungskonfigurationsdatei eine fehlerhafte XML-Tagsyntax hinzugefügt.

Wichtig

Vergessen Sie nicht, beide Dateien – „diahost.exe.config“ und „diawp.exe.config“ – zu aktualisieren.

Sie müssen auch sicherstellen, dass Microsoft Azure in der Positivliste Ihres Unternehmens enthalten ist. Sie können die Liste mit den gültigen Azure-IP-Adressen herunterladen. IP-Adressbereiche für jede Cloud, unterteilt nach Region und den markierten Diensten in dieser Cloud, sind jetzt unter MS Download verfügbar:

• Öffentlich: https://www.microsoft.com/download/details.aspx?id=56519
• US-Regierung: https://www.microsoft.com/download/details.aspx?id=57063
• Deutschland: https://www.microsoft.com/download/details.aspx?id=57064
• China: https://www.microsoft.com/download/details.aspx?id=57062

Konfigurieren von Proxyservereinstellungen bei Verwendung eines privaten Endpunkts

Wenn die Netzwerkarchitektur Ihres Unternehmens die Verwendung privater Endpunkte und aus Sicherheitsgründen umfasst und die Richtlinie Ihres Unternehmens keine direkte Internetverbindung von der VM zulässt, die die Self Hosted Integration Runtime mit der Azure Data Factory-Dienst-URL hostet, müssen Sie die ADF-Dienst-URL für die vollständige Konnektivität umgehen. Das folgende Verfahren enthält Anweisungen für die Aktualisierung der Datei „diahost.exe.config“. Sie sollten diese Schritte auch für die Datei „diawp.exe.config“ wiederholen.

1. Erstellen Sie im Datei-Explorer eine sichere Kopie von C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config als Sicherung der Originaldatei.

2. Öffnen Sie Editor als Admin.

3. Öffnen Sie in Notepad C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

4. Suchen Sie das Standard-Tag system.net, wie es hier gezeigt wird:

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

   Anschließend können Sie die Details der Bypassliste hinzufügen, wie im folgenden Beispiel gezeigt:

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

Mögliche Symptome für Probleme im Zusammenhang mit der Firewall und dem Proxyserver

Falls Fehlermeldungen wie in der Liste unten angezeigt werden, ist die Ursache wahrscheinlich eine falsche Konfiguration der Firewall oder des Proxyservers. Eine solche Konfiguration verhindert, dass die selbstgehostete IR eine Verbindung mit Data Factory oder Synapse Pipelines herstellen kann, um sich zu authentifizieren. Um sicherzustellen, dass die Firewall und der Proxyserver richtig konfiguriert sind, überprüfen Sie den vorherigen Abschnitt.

• Wenn Sie versuchen, die selbstgehostete Integration Runtime zu registrieren, erhalten Sie die folgende Fehlermeldung: „Fehler beim Registrieren dieses Knotens der Integrationslaufzeit. Stellen Sie sicher, dass der Authentifizierungsschlüssel gültig ist und der Hostdienst des Integrationsdiensts auf diesem Computer ausgeführt wird.“

• Wenn Sie Integration Runtime Configuration Manager öffnen, wird der Status " Getrennt" oder "Verbinden" angezeigt. Wenn Sie Windows-Ereignisprotokolle anzeigen, sehen Sie unter "Ereignisanzeige>Anwendungs- und Dienstprotokolle>Microsoft Integration Runtime" Fehlermeldungen wie diese.

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

Aktivieren des Remotezugriffs über ein Intranet

Wenn Sie PowerShell zum Verschlüsseln von Anmeldeinformationen von einem anderen Netzwerkcomputer als dem Ort verwenden, an dem Sie die selbst gehostete Integrationslaufzeit installiert haben, können Sie die Option "Remotezugriff über Intranet " aktivieren. Wenn Sie PowerShell ausführen, um Anmeldeinformationen auf dem Computer zu verschlüsseln, auf dem Sie die selbst gehostete Integrationslaufzeit installiert haben, können Sie den Remotezugriff nicht über das Intranet aktivieren.

Aktivieren Sie den Remotezugriff aus dem Intranet, bevor Sie einen weiteren Knoten für hohe Verfügbarkeit und Skalierbarkeit hinzufügen.

Wenn Sie das selbst gehostete Integrations-Laufzeitsetup Version 3.3 oder höher ausführen, deaktiviert das selbst gehostete Integrationslaufzeit-Installationsprogramm standardmäßig den Remotezugriff vom Intranet auf dem selbst gehosteten Integrationslaufzeitcomputer.

Wenn Sie eine Firewall von einem Partner oder anderen Anbietern verwenden, können Sie manuell Port 8060 oder den von Benutzenden konfigurierten Port öffnen. Falls beim Einrichten der selbstgehosteten Integration Runtime Firewallprobleme auftreten, sollten Sie den folgenden Befehl verwenden, um die selbstgehostete Integration Runtime zu installieren, ohne die Firewall zu konfigurieren:

msiexec /q /i IntegrationRuntime.msi NOFIREWALL=1

Falls Sie Port 8060 auf dem Computer für die selbstgehostete Integration Runtime nicht öffnen, sollten Sie andere Verfahren als die Anwendung „Anmeldeinformationen festlegen“ nutzen, um Anmeldeinformationen für den Datenspeicher zu konfigurieren. Sie können beispielsweise das PowerShell-Cmdlet "New-AzDataFactoryV2LinkedServiceEncryptCredential" verwenden.

Ports und Firewalls

Zwei Firewalls müssen berücksichtigt werden:

• Die Unternehmensfirewall , die auf dem zentralen Router der Organisation ausgeführt wird
• Die Windows-Firewall , die als Daemon auf dem lokalen Computer konfiguriert ist, auf dem die selbst gehostete Integrationslaufzeit installiert ist

Auf Ebene der Unternehmensfirewall müssen Sie die folgenden Domänen und ausgehenden Ports konfigurieren:

Domänennamen	Ausgehende Ports	Beschreibung
Öffentliche Cloud: *.servicebus.windows.net Azure Government: *.servicebus.usgovcloudapi.net China: *.servicebus.chinacloudapi.cn	443	Erforderlich für die selbstgehostete Integration Runtime für interaktives Authoring. Dies ist nicht erforderlich, wenn eigenständiges interaktives Authoring aktiviert ist.
Öffentliche Cloud: {datafactory}.{region}.datafactory.azure.net oder *.frontend.clouddatahub.net Azure Government: {datafactory}.{region}.datafactory.azure.us China: {datafactory}.{region}.datafactory.azure.cn	443	Erforderlich für die selbstgehostete Integration Runtime, um Verbindungen mit dem Azure Data Factory-Dienst herzustellen. Bei einer neu erstellten Data Factory in der öffentlichen Cloud finden Sie den vollqualifizierten Domänennamen (FQDN) im Schlüssel der selbstgehosteten Integration Runtime, der folgendes Format hat: „{Data Factory}.{Region}.datafactory.azure.net“. Kann für eine alte Data Factory und jede Version von Azure Synapse Analytics der FQDN nicht über den Schlüssel der selbstgehosteten Integration Runtime ermittelt werden, verwenden Sie stattdessen „*.frontend.clouddatahub.net“.
download.microsoft.com	443	Erforderlich für die selbstgehostete Integration Runtime zum Herunterladen der Aktualisierungen. Falls Sie automatische Updates deaktiviert haben, können Sie die Konfiguration dieser Domäne überspringen.
Key Vault-URL	443	Erforderlich für Azure Key Vault, wenn Sie die Anmeldeinformationen in Key Vault speichern.

Auf Windows-Firewall- oder Computerebene sind diese ausgehenden Ports normalerweise aktiviert. Falls nicht, können Sie die Domänen und Ports auf dem Computer mit der selbstgehosteten Integration Runtime konfigurieren.

Hinweis

Da azure Relay derzeit keine Diensttags unterstützt, müssen Sie Das Diensttag AzureCloud oder Internet in NSG-Regeln für die Kommunikation mit Azure Relay verwenden. Für die Kommunikation mit Azure Data Factory- und Synapse-Arbeitsbereichen können Sie den Dienst-Tag DataFactoryManagement in der NSG-Regelkonfiguration verwenden.

Basierend auf Ihren Quellen und Senken müssen Sie unter Umständen zusätzliche Domänen und ausgehende Ports in Ihrer Unternehmens- oder Windows-Firewall zulassen.

Domänennamen	Ausgehende Ports	Beschreibung
*.core.windows.net	443	Wird von der selbstgehosteten Integration Runtime verwendet, um Verbindungen mit dem Azure Storage-Konto herzustellen, wenn Sie das Feature für gestaffeltes Kopieren verwenden.
*.database.windows.net	1433	Nur erforderlich, wenn Sie von bzw. nach Azure SQL-Datenbank oder Azure Synapse Analytics kopieren, andernfalls optional. Verwenden Sie das Feature für gestaffeltes Kopieren, um Daten nach SQL-Datenbank oder Azure Synapse Analytics zu kopieren, ohne Port 1433 zu öffnen.
*.azuredatalakestore.net login.microsoftonline.com/<tenant>/oauth2/token	443	Nur erforderlich, wenn Sie von bzw. nach Azure Data Lake Store kopieren, andernfalls optional.

Für einige Clouddatenbanken, z. B. Azure SQL-Datenbank und Azure Data Lake, müssen Sie ggf. IP-Adressen der Computer mit der selbstgehosteten Integration Runtime für die Firewallkonfiguration zulassen.

Hinweis

Es ist nicht richtig, sowohl Integration Runtime als auch Power BI-Gateway auf demselben Computer zu installieren, da in erster Linie Integration Runtime Portnummer 443 verwendet wird, was auch eines der wichtigsten Ports ist, die vom Power BI-Gateway verwendet werden.

Eigenständiges interaktives Authoring

Um Aktionen für interaktives Authoring wie Datenvorschau und Verbindungstests ausführen zu können, benötigt die selbstgehostete Integration Runtime eine Verbindung mit Azure Relay. Wenn die Verbindung nicht hergestellt wird, gibt es zwei mögliche Lösungen, um eine unterbrechungsfreie Funktionalität sicherzustellen. Die erste Option besteht darin, die Azure Relay-Endpunkte zur Zulassungsliste " Get URL" von Azure Relay ihrer Firewall hinzuzufügen. Stattdessen können Sie auch eigenständiges interaktives Authoring aktivieren.

Hinweis

Wenn die selbstgehostete Integration Runtime keine Verbindung mit Azure Relay herstellt, wird ihr Status als „eingeschränkt“ gekennzeichnet.

Hinweis

Während eigenständiges interaktives Authoring aktiviert ist, wird der gesamte Datenverkehr für interaktives Authoring ausschließlich über diese Funktionalität weitergeleitet, wobei Azure Relay umgangen wird. Der Datenverkehr wird nur dann zurück an Azure Relay weitergeleitet, wenn Sie dieses Feature deaktivieren.

Hinweis

Sowohl "Get IP" als auch "Send log" werden nicht unterstützt, wenn eigenständige interaktive Dokumenterstellung aktiviert ist.

Abrufen der URL für Azure Relay

Für die Kommunikation mit Azure Relay müssen Sie eine Domäne und einen Port in die Positivliste Ihrer Firewall eintragen. Die selbstgehostete Integration Runtime verwendet sie bei Aktivitäten für interaktives Authoring, wie z. B. zum Testen der Verbindung, zum Durchsuchen von Ordner- und Tabellenlisten, zum Abrufen eines Schemas und zum Anzeigen einer Datenvorschau. Wenn Sie .servicebus.windows.net nicht zulassen möchten und spezifischere URLs haben möchten, können Sie alle FQDNs sehen, die von Ihrer selbst gehosteten Integrationslaufzeit über das Serviceportal benötigt werden.

Abrufen der URL für Azure Relay über die Benutzeroberfläche:

Führen Sie die folgenden Schritte aus:

1. Wechseln Sie zum Dienstportal, und wählen Sie Ihre selbstgehostete IR aus.

2. Wählen Sie auf der Seite "Bearbeiten" die Option "Knoten" aus.

3. Wählen Sie "Dienst-URLs anzeigen" aus, um alle FQDNs abzurufen.

   

4. Sie können diese vollqualifizierten Domänennamen der Positivliste Ihrer Firewallregeln hinzufügen.

Hinweis

Ausführliche Informationen zum Azure Relay Connections-Protokoll finden Sie im Azure Relay Hybrid Connections-Protokoll.

Abrufen der URL von Azure Relay über ein Skript:

# 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]$synapseResourceGroupName = "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

Kopieren von Daten von einer Quelle in eine Senke

Stellen Sie sicher, dass Sie Firewallregeln für die Unternehmensfirewall, die Windows-Firewall des selbst gehosteten Integrationslaufzeitcomputers und den Datenspeicher selbst ordnungsgemäß aktivieren. Bei Aktivierung dieser Regeln kann die selbstgehostete Integration Runtime erfolgreich eine Verbindung mit der Quelle und der Senke herstellen. Aktivieren Sie die Regeln für jeden Datenspeicher, der am Kopiervorgang beteiligt ist.

Führen Sie beispielsweise die folgenden Schritte aus, um Daten aus einem lokalen Datenspeicher in eine SQL-Datenbank-Senke oder eine Azure Synapse Analytics-Senke zu kopieren:

1. Ausgehende TCP-Kommunikation an Port 1433 sowohl für die Windows-Firewall als auch für die Unternehmensfirewall zulassen.
2. Konfigurieren Sie die Firewalleinstellungen der SQL-Datenbank-Instanz, um die IP-Adresse des Computers mit der selbstgehosteten Integration Runtime der Liste mit den zulässigen IP-Adressen hinzuzufügen.

Hinweis

Falls Ihre Firewall den ausgehenden Port 1433 nicht zulässt, kann die selbstgehostete Integration Runtime nicht direkt auf SQL-Datenbank zugreifen. In diesem Fall können Sie eine mehrstufige Kopie für SQL-Datenbanken und Azure Synapse Analytics verwenden. Sie benötigen bei einem Szenario dieser Art nur HTTPS (Port 443) für die Datenverschiebung.

Wenn sich alle Ihre Datenquellen und -senken sowie die selbst gehostete Integrationslaufzeit in einer On-Premises-Umgebung befinden, werden die kopierten Daten nicht in die Cloud geleitet, sondern verbleiben lokal.

Anmeldeinformationen speichern

Es gibt zwei Möglichkeiten, die Anmeldeinformationen zu speichern, wenn Sie die selbstgehostete Integration Runtime verwenden:

1. Verwenden Sie Azure Key Vault (empfohlen) – Die selbst gehostete Integrationslaufzeitumgebung kann die Anmeldeinformationen direkt aus Azure Key Vault abrufen, wodurch potenzielle Sicherheitsprobleme oder Synchronisierungsprobleme mit Anmeldeinformationen zwischen selbst gehosteten Integrationslaufzeitknoten weitgehend vermieden werden können.

2. Lokales Speichern von Anmeldeinformationen – Die Anmeldeinformationen werden an den Computer übertragen, auf dem Ihre selbst gehostete Integrationslaufzeit installiert und verschlüsselt wird.

   Hinweis

   Wenn Sie die Anmeldeinformationen lieber lokal speichern möchten, müssen Sie die Domäne für interaktives Authoring auf die Positivliste Ihrer Firewall setzen und den Port öffnen. Dieser Kanal lässt auch zu, dass die selbstgehostete Integration Runtime die Anmeldeinformationen abruft. Informationen zu der Domäne und den Ports, die für die interaktive Dokumenterstellung erforderlich sind, finden Sie unter Ports und Firewalls

Wenn Sie Ihre selbstgehostete Integrationslaufzeit nach einem Absturz wiederherstellen, können Sie entweder die Anmeldeinformationen von der, die Sie als Sicherung gespeichert haben, wiederherstellen oder den verknüpften Dienst bearbeiten, damit die Anmeldeinformationen erneut zur selbstgehosteten Integrationslaufzeit übertragen werden. Andernfalls funktioniert eine Pipeline, die die selbstgehostete Integration Runtime verwendet, aufgrund fehlender Anmeldeinformationen nicht.

Bewährte Methoden für die Installation

Sie können die selbst gehostete Integrationslaufzeit installieren, indem Sie ein Setuppaket für verwaltete Identitäten aus dem Microsoft Download Center herunterladen. Eine schrittweise Anleitung finden Sie im Artikel "Verschieben von Daten zwischen lokal und Cloud ".

• Konfigurieren Sie den Energiesparplan auf dem Hostcomputer für die selbstgehostete Integration Runtime, damit der Computer nicht in den Ruhezustand versetzt wird. Wenn der Hostcomputer in den Ruhezustand versetzt wird, wechselt die selbstgehostete Integration Runtime in den Offlinemodus.
• Sichern Sie regelmäßig die Anmeldeinformationen, die der selbstgehosteten Integration Runtime zugeordnet sind.
• Informationen zum Automatisieren von selbst gehosteten IR-Setupvorgängen finden Sie unter Einrichten einer vorhandenen selbst gehosteten IR über PowerShell.
• Installieren Sie die selbst gehostete Integrationslaufzeit auf dedizierten Computern, um die Ressourcenisolation und Leistung zu verbessern.

Wichtige Hinweise

Berücksichtigen Sie beim Installieren einer selbstgehosteten Integration Runtime Folgendes:

• Installieren Sie sie in der Nähe Ihrer Datenquelle, aber nicht unbedingt auf demselben Computer.
• Installieren Sie sie nicht auf demselben Computer wie Power BI Gateway.
• Nur Windows Server (FIPS-konforme Verschlüsselungsserver können zu Auftragsfehlern führen.)
• Freigeben über mehrere Datenquellen hinweg
• Freigeben über mehrere Data Factorys hinweg

Verwandte Inhalte

Schrittweise Anleitungen finden Sie im Lernprogramm: Kopieren lokaler Daten in die Cloud.