Erstellen und Konfigurieren einer selbstgehosteten Integration Runtime

Artikel
09/03/2024

GILT FÜR: Azure Data Factory Azure Synapse Analytics

Tipp

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

Die Integrationslaufzeit (IR) ist die Berechnungsinfrastruktur, die Azure Data Factory und Synapse-Pipelines verwenden, um Datenintegrationsfunktionen über verschiedene Netzumgebungen hinweg bereitzustellen. Weitere Informationen zur Integration Runtime finden Sie unter Integrationslaufzeit in Azure Data Factory.

Mit einer selbstgehosteten Integration Runtime können Kopieraktivitäten zwischen einem Clouddatenspeicher und einem Datenspeicher in einem privaten Netzwerk ausgeführt werden. Darüber hinaus können Transformationsaktivitäten für Computeressourcen in einem lokalen Netzwerk oder einem virtuellen Azure-Netzwerk verteilt werden. Für die Installation einer selbstgehosteten Integration Runtime ist ein lokaler Computer oder ein virtueller Computer in einem privaten Netzwerk erforderlich.

In diesem Artikel wird beschrieben, wie Sie die selbstgehostete IR erstellen und konfigurieren 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 zum Az-Modul.

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 auf demselben Microsoft Entra-Mandanten freizugeben. Weitere Informationen finden Sie unter Freigeben der selbstgehosteten Integration Runtime (IR) für mehrere Data Factorys.
Sie können auf einem Computer nur jeweils eine Instanz der selbstgehosteten Integration Runtime installieren. Wenn Sie über zwei Data Factorys verfügen, die auf lokale Datenquellen zugreifen müssen, verwenden Sie entweder die Funktion für selbstgehostete IR-Freigabe, um die selbstgehostete IR freizugeben, oder Sie installieren die selbstgehostete IR auf zwei lokalen Computern (eine Instanz für jede Data Factory oder jeden 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 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-Instanz, 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 selbstgehostete Integration Runtime als Proxy für die SSIS Integration Runtime verwenden, kann die FIPS-konforme Verschlüsselung aktiviert werden. Dies wird dann verwendet, wenn Daten von einem lokalen Speicherort 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:

Allgemeine Übersicht über den Datenfluss

Ein Datenentwickler erstellt zunächst mit dem Azure-Portal oder dem PowerShell-Cmdlet eine selbstgehostete IR in einer Azure Data Factory oder einen Synapse-Arbeitsbereich. Anschließend erstellt der Datenentwickler einen verknüpften Dienst für einen lokalen Datenspeicher, indem er die Instanz der selbstgehosteten Integration Runtime angibt, die der Dienst zum Verbinden der Datenspeicher verwenden soll.
Ü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 den Datenentwickler transparent und wird von der selbstgehosteten IR verarbeitet.
Azure Data Factory und Synapse-Pipelines kommunizieren mit der selbst gehosteten IR, um Aufträge zu planen und zu verwalten. Die Kommunikation erfolgt über einen Steuerkanal, 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. Dies 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.
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

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ührlichere Informationen finden Sie unter Systemanforderungen für .NET Framework .
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. Details zu den Systemanforderungen finden Sie auf der Downloadseite.
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 der Administrator 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 Parquet finden Sie im Artikel Parquet-Format 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 (und nicht nur den JRE-Ordner) zeigt. Möglicherweise müssen Sie außerdem den Bin-Ordner der PATH-Umgebungsvariablen Ihres Systems hinzufügen.
Hinweis

Unter Umständen müssen Sie die Java-Einstellungen anpassen, wenn Speicherfehler auftreten, wie in der Dokumentation zum Parquet-Format beschrieben.

Hinweis

Wenn Sie in der Government-Cloud arbeiten, lesen Sie Verbinden zur 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

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

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

Laden Sie die selbstgehostete Integration Runtime herunter, und installieren Sie sie auf dem lokalen Computer.
Rufen Sie den Authentifizierungsschlüssel ab, und registrieren Sie die selbstgehostete Integration Runtime mit dem Schlüssel. Hier ist ein PowerShell-Beispiel angegeben:
```
Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName  
```

Hinweis

Führen Sie den PowerShell-Befehl in Azure Government aus. Mehr Informationen find Sie unter zum Azure Government mit PowerShell Verbinden.

Erstellen einer selbstgehosteten IR über Benutzeroberflache

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

Wählen Sie auf der Homepage der Azure Data Factory-Benutzeroberfläche im Bereich ganz links die Registerkarte Verwalten aus.
Wählen Sie im linken Bereich Integration Runtime und dann +Neu aus.
Wählen Sie auf der Seite Integration Runtime-Setup die Option Azure, Selbstgehostet und dann Weiter aus.
Wählen Sie auf der daraufhin angezeigten Seite Selbstgehostet aus, um eine selbstgehostete IR zu erstellen, und wählen Sie dann Weiteraus.

Konfigurieren einer selbstgehosteten IR über Benutzeroberflache

Geben Sie einen Namen für Ihre IR ein, und wählen Sie Erstellen aus.
Wählen Sie auf der Seite Integration Runtime-Setup 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 die Einrichtung manuell vorzunehmen. 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 einen lokalen Windows-Computer durch. Führen Sie das Installationsprogramm aus.
3. Fügen Sie auf der Seite Integration Runtime (selbstgehostet) registrieren den Schlüssel ein, den Sie zuvor gespeichert haben, und wählen Sie Registrieren aus.
4. Klicken Sie auf der Seite Neuer Knoten der Integrationslaufzeit (selbstgehostet) auf Fertig stellen.
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 das Setup der selbstgehosteten IR auf einem virtuellen Azure-Computer mit der Vorlage zum Erstellen einer selbstgehosteten Integration Runtime automatisieren. 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:

ACTION	args	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 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, 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>`"	Generiert eine Sicherungsdatei für den aktuellen Knoten. 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>`"]	Legen Sie fest, dass DIAHostService als neues Konto ausgeführt wird. Verwenden Sie ein leeres Kennwort („“) für Systemkonten und virtuelle Konten.
`-elma`, `-EnableLocalMachineAccess`		Aktivieren Sie den lokalen Computerzugriff (localhost, private IP-Adresse) auf dem aktuellen Knoten mit der selbstgehosteten IR. In einem Szenario mit einer selbstgehosteten Integration Runtime mit Hochverfügbarkeit muss die Aktion für jeden selbstgehosteten IR-Knoten aufgerufen werden.
`-dlma`, `-DisableLocalMachineAccess`		Deaktivieren Sie den lokalen Computerzugriff (localhost, private IP-Adresse) auf dem aktuellen Knoten mit der selbstgehosteten IR. In einem Szenario mit einer selbstgehosteten Integration Runtime mit Hochverfügbarkeit muss die Aktion für jeden selbstgehosteten IR-Knoten aufgerufen werden.
`-DisableLocalFolderPathValidation`		Deaktivieren Sie die Sicherheitsüberprüfung, um den Zugriff auf das Dateisystem des lokalen Computers zu aktivieren.
`-EnableLocalFolderPathValidation`		Aktivieren Sie die Sicherheitsüberprüfung, 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`		Rufen Sie den Wert ab, wenn die Option „ExecuteSsisPackage” auf einem selbstgehosteten IR-Knoten aktiviert ist. Wenn der zurückgegebene Wert WAHR ist, ist ExecuteSSISPackage aktiviert. Wenn der zurückgegebene Wert FALSCH oder NULL ist, ist ExecuteSSISPackage deaktiviert.

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

Navigieren Sie zur Downloadseite für die Microsoft-Integration Runtime.
Wählen Sie die Option Herunterladen, die 64-Bit-Version und dann Weiter aus. Die 32-Bit-Version wird nicht unterstützt.
Führen Sie die MSI-Datei direkt aus, oder speichern Sie sie zur späteren Ausführung auf Ihrer Festplatte.
Wählen Sie im Fenster Willkommen eine Sprache und dann Weiter aus.
Akzeptieren Sie die Microsoft-Software-Lizenzbedingungen, und wählen Sie Weiter aus.
Wählen Sie den Ordner für die Installation der selbstgehosteten Integration Runtime und dann Weiter aus.
Wählen Sie auf der Seite Bereit zur Installation die Option Installieren aus.
Wählen Sie Fertig stellen aus, um die Installation abzuschließen.

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

Führen Sie im Konfigurations-Manager für Microsoft Integration Runtime, der auf Ihrem Computer ausgeführt wird, im Fenster Integration Runtime (selbstgehostet) registrieren die folgenden Schritte aus:
1. Fügen Sie im Textbereich den Authentifizierungsschlüssel ein.
2. Optional: Wählen Sie Authentifizierungsschlüssel anzeigen, um den Schlüsseltext anzuzeigen.
3. Wählen Sie Registrieren.

Hinweis

Sie finden die Versionshinweise auf der Downloadseite der Microsoft Integration Runtime.

Dienstkonto für die selbstgehostete Integration Runtime

Das standardmäßige Anmeldedienstkonto für die selbstgehostete Integration Runtime lautet NT SERVICE\DIAHostService. Sie können es unter Dienste > Integration Runtime-Dienst >Eigenschaften > Anmelden anzeigen.

Dienstkonto für selbstgehostete Integration Runtime

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 unter Lokale Sicherheitsrichtlinie > Sicherheitseinstellungen > Lokale Richtlinien > Zuweisen von Benutzerrechten > Anmelden als Dienst prüfen.

Screenshot von „ Lokale Sicherheitsrichtlinie“ – „Zuweisen von Benutzerrechten“

Screenshot von „Anmelden als Dienst“ – „Zuweisen von Benutzerrechten“

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.

Benachrichtigungen im Benachrichtigungsbereichs

Hohe Verfü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 Clouddatenspeichern. Informieren Sie sich über Leistungsvergleiche.

Sie können mehrere Knoten zuordnen, indem Sie die Software für die selbstgehostete Integration Runtime aus dem Downloadcenter installieren. Registrieren Sie sie dann – wie im Tutorial beschrieben – mit einem der vom Cmdlet New-AzDataFactoryV2IntegrationRuntimeKey abgerufenen Authentifizierungsschlüssel.

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

Vergewissern Sie sich vor dem Hinzufügen eines weiteren Knotens zur Erzielung von Hochverfügbarkeit und Skalierbarkeit, dass die Option Remote access to intranet (Remotezugriff auf das Intranet) für den ersten Knoten aktiviert ist. Navigieren Sie hierzu zu Konfigurations-Manager für Microsoft Integration Runtime>Einstellungen>Remote access to intranet (Remotezugriff auf das Intranet).

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 das Zeitlimit erreicht ist 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:

Laden Sie das SHIR-Setup aus dem Azure Data Factory-Portalherunter.
Führen Sie den Installer auf dem Knoten aus, den Sie dem Cluster hinzufügen möchten.
Wählen Sie während der Installation die Option aus, einer vorhandenen Integrationslaufzeit 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 eine Zeitüberschreitung 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:

Erhöhen Sie die Anzahl von gleichzeitigen Aufträgen, die auf einem Knoten ausgeführt werden können.

TLS/SSL-Zertifikatanforderungen

Wenn Sie den Remotezugriff aus dem Intranet mit TLS/SSL-Zertifikat (Erweitert) aktivieren möchten, um die Kommunikation zwischen Integration Runtime-Knoten zu sichern, können Sie die Schritte unter Aktivieren des Remotezugriffs aus dem 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.

Wir empfehlen Ihnen, dieses Zertifikat zu verwenden, wenn Ihre private Netzwerkumgebung nicht sicher ist oder Sie die Kommunikation zwischen Knoten in Ihrem privaten Netzwerk schützen 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 Anmeldeinformationen oder Geheimniswerte nicht in einem Azure Key Vault speichern, werden die Anmeldeinformationen oder Geheimniswerte auf den Computern gespeichert, auf denen sich Ihre selbstgehostete IR befindet. Jeder Knoten wird über eine Kopie der Anmeldeinformationen mit einer bestimmten Version verfügen. Damit alle Knoten zusammenarbeiten, sollte die Versionsnummer für alle Knoten identisch sein.

Proxyserver-Aspekte

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.

Angeben des Proxys

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.

Festlegen des Proxys

Es gibt drei Konfigurationsoptionen:

Proxy nicht verwenden: Für die selbstgehostete IR wird nicht explizit ein Proxy verwendet, um eine Verbindung mit Clouddiensten herzustellen.
Systemproxy verwenden: Die selbstgehostete IR verwendet die in „diahost.exe.config“ und „diawp.exe.config“ konfigurierten Proxyeinstellungen. Wenn für diese Dateien keine Proxykonfiguration angegeben wird, stellt die selbstgehostete Integration Runtime eine direkte Verbindung mit dem Clouddienst her, ohne einen Proxy zu durchlaufen.
Benutzerdefinierten Proxy verwenden: Konfigurieren Sie hier die HTTP-Proxyeinstellungen, die für die selbstgehostete Integration Runtime verwendet werden sollen, anstatt die Konfigurationen in den Dateien „diahost.exe.config“ und „diawp.exe.config“ zu nutzen. Die Werte für Adresse und Port sind erforderlich. Die Werte für Benutzername und Kennwort sind je nach den Authentifizierungseinstellungen Ihres Proxys optional. Alle Einstellungen werden für die selbstgehostete Integrationslaufzeit 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 die Microsoft Integration Runtime verwenden.

Öffnen Sie den Konfigurations-Manager für Microsoft Integration Runtime.
Wählen Sie die Registerkarte Einstellungen aus.
Wählen Sie unter HTTP-Proxy den Link Ändern aus, um das Dialogfeld HTTP-Proxy festlegen zu öffnen.
Wählen Sie Weiter aus. Eine Warnung wird angezeigt, die Sie zur Bestätigung auffordert, dass die Proxyeinstellung gespeichert und der Hostdienst der Integration Runtime neu gestartet werden soll.

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

Anzeigen und Aktualisieren des Proxys

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 selbstgehostete Integration Runtime die Proxyeinstellungen in „diahost.exe.config“ und „diawp.exe.config“. Falls für diese Dateien kein Proxy angegeben wird, stellt die selbstgehostete Integration Runtime eine direkte Verbindung mit dem Clouddienst her, ohne einen Proxy zu durchlaufen. Das folgende Verfahren enthält Anweisungen für die Aktualisierung der Datei „diahost.exe.config“:

Erstellen Sie im Datei-Explorer eine sichere Kopie von C:\Programme\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config als Sicherung der Originaldatei.
Öffnen Sie den Editor als Administrator.
Öffnen Sie in Notepad die Textdatei C:\Programme\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

Suchen Sie wie im folgenden Code gezeigt nach dem Standardtag system.net:

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

Anschließend können Sie die Informationen zum Proxyserver 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. Informationen zur Syntax finden Sie unter dem <proxy>-Element (Netzwerkeinstellungen).

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

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 Dienste-Applet in der Systemsteuerung neu. Alternativ wählen Sie im Konfigurations-Manager für Integration Runtime die Schaltfläche Dienst beenden und dann Dienst starten aus.

Wenn der Dienst nicht gestartet wird, haben Sie wahrscheinlich in der von Ihnen bearbeiteten Konfigurationsdatei 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 Gov: 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 vorsieht und die Richtlinien Ihres Unternehmens aus Sicherheitsgründen keine direkte Internetverbindung von der VM, die die selbstgehostete Integration Runtime-Umgehung hostet, zur Azure Data Factory Service-URL zulassen, dann müssen Sie eine Umgehung der ADF Service-URL für eine vollständige Konnektivität zulassen. 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.

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

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

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

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 den Konfigurations-Manager für die Integration Runtime öffnen, wird der Status als Getrennt oder Verbindung wird hergestellt angezeigt. Beim Anzeigen der Windows-Ereignisprotokolle sehen Sie unter Ereignisanzeige>Anwendungs- und Dienstprotokolle>Microsoft Integration Runtime beispielsweise folgende Fehlermeldung:
```
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 verwenden, um Anmeldeinformationen eines anderen Computers im Netzwerk zu verschlüsseln, auf dem Sie die selbstgehostete Integration Runtime nicht installiert haben, können Sie die Option Remotezugriff über das Intranet aktivieren. Wenn Sie PowerShell verwenden, um Anmeldeinformationen auf dem Computer zu verschlüsseln, auf dem Sie die selbstgehostete Integration Runtime installiert haben, können Sie Remotezugriff über das Intranet nicht aktivieren.

Aktivieren Sie die Option Remotezugriff über das Intranet, bevor Sie einen weiteren Knoten für Hochverfügbarkeit und Skalierbarkeit hinzufügen.

Wenn Sie mindestens Version 3.3 der selbstgehosteten Integration Runtime ausführen, wird Remotezugriff über das Intranet durch das Installationsprogramm der selbstgehosteten Integration Runtime auf dem entsprechenden Computer deaktiviert.

Wenn Sie eine Firewall von einem Partner oder anderen Anbietern verwenden, können Sie manuell Port 8060 oder den vom Benutzer 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. Beispielsweise können Sie das New-AzDataFactoryV2LinkedServiceEncryptCredential-PowerShell-Cmdlet 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 selbstgehostete Integration Runtime installiert ist

Firewalls

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 zur interaktiven Erstellung Dies ist nicht erforderlich, wenn das eigenständige interaktive 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.
Schlüsseltresor-URL	443	Erforderlich für Azure Key Vault, wenn Sie die Anmeldeinformationen in Key Vault speichern.

Auf Ebene der Windows-Firewall bzw. auf 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 das Diensttag DataFactoryManagement in dem NSG-Regelsatz 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 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 die Integration Runtime als auch Power BI Gateway auf demselben Computer zu installieren, da die Integration Runtime hauptsächlich Portnummer 443 verwendet. Dies ist auch einer der Hauptports, die von Power BI Gateway verwendet werden.

Eigenständiges interaktives Authoring (Vorschau)

Um interaktive Authoringaktionen wie Datenvorschau und Verbindungstests ausführen zu können, benötigt die selbstgehostete Integration Runtime eine Verbindung mit Azure Relay. Wenn die Verbindung nicht zustande kommt, gibt es zwei mögliche Lösungen, um eine unterbrechungsfreie Funktion zu gewährleisten. Die erste Option besteht darin, die Azure Relay-Endpunkte der Zulassungsliste Get URL of Azure Relay ihrer Firewall hinzuzufügen. Stattdessen können Sie auch das eigenständige interaktive Authoring aktivieren.

Hinweis

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

Screenshot:Eigenständiges interaktives Authoring (Vorschau)

Hinweis

Während das eigenständige interaktive Authoring aktiviert ist, wird der gesamte interaktive Authoringdatenverkehr 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 „IP abrufen“ als auch „Protokoll senden“ werden nicht unterstützt, wenn das eigenständige interaktive Authoring 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 der interaktiven Erstellung, 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 und lieber spezifischere URLs verwenden möchten, können Sie alle FQDNs, die von Ihrer selbst gehosteten IR benötigt werden, im Serviceportal sehen.

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

Führen Sie folgende Schritte aus:

Wechseln Sie zumDienstportal, und wählen Sie Ihre selbstgehostete IR aus.
Wählen Sie auf der Seite „Bearbeiten“ die Option Knoten aus.
Wählen Sie Dienst-URLs anzeigen aus, um alle vollqualifizierten Domänennamen anzuzeigen.
Sie können diese vollqualifizierten Domänennamen der Positivliste Ihrer Firewallregeln hinzufügen.

Hinweis

Weitere Informationen zum Protokoll Azure Relay-Verbindungen finden Sie unter Azure Relay-Hybridverbindungsprotokoll.

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

Kopieren von Daten von einer Quelle in eine Senke

Stellen Sie sicher, dass Sie die Firewallregeln der Unternehmensfirewall, der Windows-Firewall auf dem Computer mit der selbstgehosteten Integration Runtime und des Datenspeichers selbst richtig 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:

Lassen Sie ausgehende TCP-Kommunikation an Port 1433 sowohl für die Windows-Firewall als auch für die Unternehmensfirewall zu.
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 die SQL Datenbank zugreifen. In diesem Fall können Sie das gestaffelte Kopieren in SQL-Datenbank und Azure Synapse Analytics verwenden. Sie benötigen bei einem Szenario dieser Art nur HTTPS (Port 443) für die Datenverschiebung.

Wenn sich Ihre gesamte Datenquelle und Senke sowie die selbstgehostete Integration Runtime in einer lokalen Umgebung befinden, werden die kopierten Daten nicht in die Cloud übertragen, sondern bleiben ausschließlich lokal.

Anmeldeinformationsspeicher

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

Verwenden von Azure Key Vault.

Dies ist die empfohlene Methode zum Speichern Ihrer Anmeldeinformationen in Azure. Die selbstgehostete Integration Runtime kann die Anmeldeinformationen direkt von Azure Key Vault abrufen. So können einige potenzielle Sicherheitsprobleme oder Probleme bei der Synchronisierung von Anmeldeinformationen zwischen Knoten der selbstgehosteten Integration Runtime vermieden werden. 2. Lokales Speichern von Anmeldeinformationen.

Die Anmeldeinformationen werden per Push auf den Computer Ihrer selbstgehosteten Integration Runtime übertragen und dort verschlüsselt. Wenn Ihre selbstgehostete Integration Runtime nach einem Absturz wiederhergestellt wird, können Sie entweder die zuvor gesicherten Anmeldeinformationen wiederherstellen oder den verknüpften Dienst bearbeiten und die Anmeldeinformationen erneut an die selbstgehostete Integration Runtime pushen lassen. Andernfalls funktioniert die Pipeline aufgrund fehlender Anmeldeinformationen bei der Ausführung über die selbstgehostete Integration Runtime nicht.

Hinweis

Wenn Sie die Anmeldeinformationen lieber lokal speichern möchten, müssen Sie die Domäne für das interaktive Authoring auf die Positivliste Ihrer Firewall setzen und den Port öffnen. Dieser Kanal ist auch für die selbstgehostete Integration Runtime zum Abrufen der Anmeldeinformationen verfügbar. Informationen zur Domäne und den für das interaktive Authoring erforderlichen Port finden Sie unter Ports und Firewalls.

Bewährte Methoden für die Installation

Sie können die selbstgehostete Integration Runtime installieren, indem Sie aus dem Microsoft Download Center ein Setuppaket des Typs „Verwaltete Identität“ herunterladen. Eine Schritt-für-Schritt-Anleitung finden Sie im Artikel Verschieben von Daten zwischen lokalen Quellen und der 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 zur Automatisierung der Einrichtungsvorgänge für die selbstgehostete IR finden Sie unter Einrichten einer vorhandenen selbstgehosteten IR über PowerShell.

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

Eine Schritt-für-Schritt-Anleitung finden Sie unter Tutorial: Kopieren von lokalen Daten in die Cloud.

Freigeben über

Erstellen und Konfigurieren einer selbstgehosteten Integration Runtime

Aspekte der Nutzung einer selbstgehosteten IR

Befehls- und Datenfluss

Voraussetzungen

Einrichten einer selbstgehosteten Integration Runtime

Erstellen einer selbstgehosteten IR mit Azure PowerShell

Erstellen einer selbstgehosteten IR über Benutzeroberflache

Konfigurieren einer selbstgehosteten IR über Benutzeroberflache

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

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

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

Dienstkonto für die selbstgehostete Integration Runtime

Symbole des Benachrichtigungsbereichs und Benachrichtigungen

Hohe Verfügbarkeit und Skalierbarkeit

Aspekte der Skalierung

Aufskalieren

Hochskalieren

TLS/SSL-Zertifikatanforderungen

Synchronisierung von Anmeldeinformationen

Proxyserver-Aspekte

Konfigurieren von Proxyservereinstellungen

Konfigurieren von Proxyservereinstellungen bei Verwendung eines privaten Endpunkts

Aktivieren des Remotezugriffs über ein Intranet

Ports und Firewalls

Eigenständiges interaktives Authoring (Vorschau)

Abrufen der URL für Azure Relay

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

Abrufen der URL von Azure Relay über ein Skript:

Kopieren von Daten von einer Quelle in eine Senke

Anmeldeinformationsspeicher

Bewährte Methoden für die Installation

Wichtige Hinweise

Feedback

Zusätzliche Ressourcen

Freigeben über

Erstellen und Konfigurieren einer selbstgehosteten Integration Runtime

Aspekte der Nutzung einer selbstgehosteten IR

Befehls- und Datenfluss

Voraussetzungen

Einrichten einer selbstgehosteten Integration Runtime

Erstellen einer selbstgehosteten IR mit Azure PowerShell

Erstellen einer selbstgehosteten IR über Benutzeroberflache

Konfigurieren einer selbstgehosteten IR über Benutzeroberflache

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

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

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

Dienstkonto für die selbstgehostete Integration Runtime

Symbole des Benachrichtigungsbereichs und Benachrichtigungen

Hohe Verfügbarkeit und Skalierbarkeit

Aspekte der Skalierung

Aufskalieren

Hochskalieren

TLS/SSL-Zertifikatanforderungen

Synchronisierung von Anmeldeinformationen

Proxyserver-Aspekte

Konfigurieren von Proxyservereinstellungen

Konfigurieren von Proxyservereinstellungen bei Verwendung eines privaten Endpunkts

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

Aktivieren des Remotezugriffs über ein Intranet

Ports und Firewalls

Eigenständiges interaktives Authoring (Vorschau)

Abrufen der URL für Azure Relay

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

Abrufen der URL von Azure Relay über ein Skript:

Kopieren von Daten von einer Quelle in eine Senke

Anmeldeinformationsspeicher

Bewährte Methoden für die Installation

Wichtige Hinweise

Zugehöriger Inhalt

Feedback

Zusätzliche Ressourcen