Auswählen der richtigen Integration Runtime-Konfiguration für Ihr Szenario

Die Integration Runtime ist ein wichtiger Teil der Infrastruktur für die von Azure Data Factory bereitgestellte Datenintegrationslösung. Dazu ist es erforderlich, dass Sie sich zu Beginn des Lösungsentwurfs Gedanken darüber machen, wie eine Anpassung an die vorhandene Netzwerkstruktur und Datenquelle erfolgen soll. Darüber hinaus sind Leistung, Sicherheit und Kosten zu berücksichtigen.

Vergleich verschiedener Integration Runtime-Typen

In Azure Data Factory gibt es drei Arten von Integration Runtimes: die Azure Integration Runtime, die selbstgehostete Integration Runtime und die Azure-SSIS Integration Runtime. Bei der Azure Integration Runtime können Sie auch ein verwaltetes virtuelles Netzwerk aktivieren, wodurch sich die Architektur von der globalen Azure Integration Runtime unterscheidet.

In dieser Tabelle sind die Unterschiede in Bezug auf einige Aspekten aller Integration Runtimes aufgeführt. Sie können die entsprechenden gemäß Ihrer tatsächlichen Anforderungen auswählen. Weitere Informationen zur Azure-SSIS Integration Runtime finden Sie im Artikel Erstellen einer Azure-SSIS Integration Runtime.

Funktion	Azure-Integrationslaufzeit	Azure Integration Runtime mit verwaltetem virtuellen Netzwerk	Selbstgehostete Integrationslaufzeit
Verwaltete Computeressourcen	J	J	N
Autoscale	J	J*	N
Datenfluss	J	J	N
Lokaler Datenzugriff	N	J**	J
Private Link/Privater Endpunkt	N	J***	J
Benutzerdefinierte Komponenten/Treiber	N	N	J

* Wenn die Gültigkeitsdauer (Time-to-Live, TTL) aktiviert ist, wird die Computegröße der Integration Runtime gemäß der Konfiguration reserviert und kann nicht automatisch skaliert werden.

** Lokale Umgebungen müssen über ExpressRoute oder VPN mit Azure verbunden sein. Benutzerdefinierte Komponenten und Treiber werden nicht unterstützt.

*** Die privaten Endpunkte werden vom Azure Data Factory-Dienst verwaltet.

Es ist sehr wichtig, einen geeigneten Integration Runtime-Typ auszuwählen. Dieser muss nicht nur für die vorhandene Architektur und die Anforderungen an die Datenintegration geeignet sein, sondern Sie müssen auch bedenken, wie Sie den wachsenden Geschäftsanforderungen und einem zukünftigen Anstieg der Workload gerecht werden können. Es gibt jedoch keine Einheitslösung. Die folgenden Überlegungen können Ihnen bei der Entscheidungsfindung helfen:

1. An welchen Standorten befinden sich Integration Runtime und Datenspeicher?
   Mit dem Integration Runtime-Standort wird der Standort der Back-End-Compute-Instanz und auch der Standort definiert, an dem die Datenverschiebung, Aktivitätsverteilung und Datentransformation durchgeführt werden. Um eine bessere Leistung und Übertragungseffizienz zu erzielen, sollte sich die Integration Runtime näher an der Datenquelle oder -senke befinden.

   • Die Azure Integration Runtime erkennt automatisch den am besten geeigneten Standort basierend auf einigen Regeln (auch als automatische Auflösung bezeichnet). Weitere Informationen finden Sie unter Azure Integration Runtime: Standort.
   • Die Azure Integration Runtime mit einem verwalteten virtuellen Netzwerk weist dieselbe Region wie Ihre Data Factory auf. Sie kann nicht wie die Azure Integration Runtime automatisch aufgelöst werden.
   • Die selbstgehostete Integration Runtime befindet sich in der Region Ihrer lokalen Computer oder virtuellen Azure-Computer.

2. Ist der Datenspeicher öffentlich zugänglich?
   Wenn der Datenspeicher öffentlich zugänglich ist, besteht zwischen den verschiedenen Integration Runtime-Typen kein großer Unterschied. Wenn sich der Speicher hinter einer Firewall oder in einem privaten Netzwerk wie z. B. einem lokalen oder virtuellen Netzwerk befindet, ist die Azure Integration Runtime mit einem verwalteten virtuellen Netzwerk oder die selbstgehostete Integration Runtime die bessere Wahl.

   • Es sind einige zusätzliche Einstellungen erforderlich, z. B. Private Link-Dienst und Load Balancer, wenn Sie die Azure Integration Runtime mit einem verwalteten virtuellen Netzwerk verwenden, um auf einen Datenspeicher hinter einer Firewall oder in einem privaten Netzwerk zuzugreifen. Ein Beispiel finden Sie im Tutorial Zugreifen auf eine lokale SQL Server-Instanz über ein verwaltetes Data Factory-VNet unter Verwendung eines privaten Endpunkts. Wenn sich der Datenspeicher in einer lokalen Umgebung befindet, muss der lokale Standort über ExpressRoute oder ein S2S-VPN mit Azure verbunden werden.
   • Die selbstgehostete Integration Runtime ist flexibler und erfordert keine zusätzlichen Einstellungen, ExpressRoute oder VPN. Sie müssen den Computer jedoch selbst bereitstellen und warten.
   • Sie können auch die öffentlichen IP-Adressen der Azure Integration Runtime zur Positivliste Ihrer Firewall hinzufügen und ihr den Zugriff auf den Datenspeicher gestatten. Dies ist jedoch in hochgradig sicheren Produktionsumgebungen keine wünschenswerte Lösung.

3. Welche Sicherheitsstufe benötigen Sie bei der Datenübertragung?
   Wenn Sie streng vertrauliche Daten verarbeiten müssen, möchten Sie sich beispielsweise vor Man-in-the-Middle-Angriffen während der Datenübertragung schützen. Dann können Sie einen privaten Endpunkt und Private Link verwenden, um die Datensicherheit zu gewährleisten.

   • Sie können verwaltete private Endpunkte für Ihre Datenspeicher erstellen, wenn Sie die Azure Integration Runtime mit einem verwalteten virtuellen Netzwerk verwenden. Die privaten Endpunkte werden vom Azure Data Factory-Dienst innerhalb des verwalteten virtuellen Netzwerks verwaltet.
   • Sie können auch private Endpunkte in Ihrem virtuellen Netzwerk erstellen, und die selbstgehostete Integration Runtime kann diese für den Zugriff auf Datenspeicher nutzen.
   • Die Azure Integration Runtime unterstützt keine privaten Endpunkte und kein Private Link.

4. Welches Maß an Wartung können Sie bereitstellen?
   Die Wartung von Infrastruktur, Servern und Geräten ist eine der wichtigen Aufgaben der IT-Abteilung eines Unternehmens. Dies erfordert in der Regel viel Zeit und Mühe.

   • Bei der Azure Integration Runtime und der Azure Integration Runtime mit einem verwalteten virtuellen Netzwerk müssen Sie sich nicht um die Wartung (z. B. Update, Patch und Version) kümmern. Der Azure Data Factory-Dienst übernimmt alle Wartungsaufgaben.
   • Da die selbstgehostete Integration Runtime auf Kundencomputern installiert ist, muss die Wartung von den Endbenutzern übernommen werden. Sie können jedoch die automatische Aktualisierung aktivieren, um automatisch die neueste Version der selbstgehosteten Integration Runtime zu erhalten, sobald es ein Update gibt. Informationen zum Aktivieren der automatischen Aktualisierung und zum Verwalten der Versionskontrolle der selbstgehosteten Integration Runtime finden Sie im Artikel Benachrichtigung zur automatischen Aktualisierung und zum Ablauf der selbstgehosteten Integration Runtime. Wir stellen auch ein Diagnosetool für die selbstgehostete Integration Runtime bereit, um einige häufige Probleme zu überprüfen. Weitere Informationen zum Diagnosetool finden Sie im Artikel Diagnosetool für die selbstgehostete Integration Runtime. Außerdem wird empfohlen, Azure Monitor und Azure Log Analytics zu verwenden, um diese Daten zu sammeln und eine zentrale Überwachung für Ihre selbstgehosteten Integration Runtimes zu ermöglichen. Weitere Informationen und Anleitungen zur Konfiguration finden Sie im Artikel Konfigurieren der selbstgehosteten Integration Runtime für die Log Analytics-Sammlung.

5. Welche Anforderungen an die Parallelität bestehen?
   Bei der Verarbeitung großer Datenmengen, z. B. bei der Migration umfangreicher Daten, möchten wir die Effizienz und Geschwindigkeit der Verarbeitung so weit wie möglich verbessern. Parallelität ist häufig eine wichtige Voraussetzung für die Datenintegration.

   • Die Azure Integration Runtime bietet den höchsten Grad an Parallelitätsunterstützung unter allen Integration Runtime-Typen. Die Datenintegrationseinheit (Data Integration Unit, DIU) ist die Einheit für die Ausführbarkeit in Azure Data Factory. Sie können die gewünschte Anzahl von DIUs z. B. für die Kopieraktivität auswählen. Innerhalb des Umfangs einer DIU können Sie mehrere Aktivitäten gleichzeitig ausführen. Für verschiedene Regionsgruppen gelten unterschiedliche Obergrenzen. Weitere Informationen zu diesen Grenzwerten finden Sie im Artikel Data Factory-Grenzwerte.
   • Die Azure Integration Runtime mit einem verwalteten virtuellen Netzwerk verfügt über einen ähnlichen Mechanismus wie die Azure Integration Runtime, doch aufgrund einiger Architektureinschränkungen ist die unterstützte Parallelität geringer als bei der Azure Integration Runtime.
   • Die gleichzeitigen Aktivitäten, die von der selbstgehosteten Integration Runtime ausgeführt werden können, hängen von der Computergröße und Clustergröße ab. Sie können einen größeren Computer auswählen oder mehr Knoten der selbstgehosteten Integration Runtime im Cluster verwenden, wenn Sie größere Parallelität benötigen.

6. Benötigen Sie bestimmte Features?
   Es gibt einige funktionale Unterschiede zwischen den Integration Runtime-Typen.

   • Dataflow wird von der Azure Integration Runtime und der Azure Integration Runtime mit einem verwalteten virtuellen Netzwerk unterstützt. Sie können Dataflow jedoch nicht mithilfe der selbstgehosteten Integration Runtime ausführen.
   • Wenn Sie benutzerdefinierte Komponenten wie ODBC-Treiber, eine JVM oder ein SQL Server-Zertifikat installieren müssen, ist die selbstgehostete Integration Runtime Ihre einzige Option. Benutzerdefinierte Komponenten werden von der Azure Integration Runtime oder der Azure Integration Runtime mit einem verwalteten virtuellen Netzwerk nicht unterstützt.

Architektur für Integration Runtime

Je nach Merkmalen der einzelnen Integration Runtimes sind unterschiedliche Architekturen erforderlich, um die geschäftlichen Anforderungen der Datenintegration zu erfüllen. Nachfolgend sind einige typische Architekturen aufgeführt, die als Referenz verwendet werden können.

Azure-Integrationslaufzeit

Die Azure Integration Runtime ist eine vollständig verwaltete, automatisch skalierte Computeressource, mit der Sie Daten aus Azure- oder Azure-fremden Datenquellen verschieben können.

1. Der Datenverkehr von der Azure Integration Runtime zu Datenspeichern erfolgt über ein öffentliches Netzwerk.
2. Wir stellen einen Bereich von statischen öffentlichen IP-Adressen für die Azure Integration Runtime bereit, und diese IP-Adressen können zur Positivliste der Firewall des Zieldatenspeichers hinzugefügt werden. Weitere Informationen zum Abrufen öffentlicher IP-Adressen der Azure Integration Runtime finden Sie im Artikel IP-Adressen von Azure Integration Runtime.
3. Die Azure Integration Runtime kann automatisch entsprechend der Region der Datenquelle und Datensenke aufgelöst werden. Sie können aber auch eine bestimmte Region auswählen. Es wird empfohlen, die Region auszuwählen, die Ihrer Datenquelle oder -senke am nächsten liegt, um eine bessere Ausführungsleistung zu erzielen. Weitere Informationen zu Leistungsüberlegungen finden Sie im Artikel Problembehandlung für die Kopieraktivität bei Azure IR.

Azure Integration Runtime mit verwaltetem virtuellen Netzwerk

Wenn Sie die Azure Integration Runtime mit einem verwalteten virtuellen Netzwerk verwenden, sollten Sie verwaltete private Endpunkte zur Verbindung Ihrer Datenquellen nutzen, um die Datensicherheit während der Übertragung zu gewährleisten. Mit einigen zusätzlichen Einstellungen wie dem Private Link-Dienst und Load Balancer können verwaltete private Endpunkte auch für den Zugriff auf lokale Datenquellen verwendet werden.

1. Ein verwalteter privater Endpunkt kann nicht in verschiedenen Umgebungen wiederverwendet werden. Sie müssen eine Reihe verwalteter privater Endpunkte für jede Umgebung erstellen. Informationen zu allen Datenquellen, die von verwalteten privaten Endpunkten unterstützt werden, finden Sie im Artikel Unterstützte Datenquellen und Dienste.
2. Sie können verwaltete private Endpunkte auch für Verbindungen mit externen Computeressourcen verwenden, die Sie orchestrieren möchten, z. B. Azure Databricks und Azure Functions. Die vollständige Liste der unterstützten externen Computeressourcen finden Sie im Artikel Unterstützte Datenquellen und Dienste.
3. Das verwaltete virtuelle Netzwerk wird vom Azure Data Factory-Dienst verwaltet. VNET-Peering zwischen einem verwalteten virtuellen Netzwerk und einem virtuellen Kundennetzwerk wird nicht unterstützt.
4. Kunden können Konfigurationen wie die NSG-Regel in einem verwalteten virtuellen Netzwerk nicht direkt ändern.
5. Wenn eine Eigenschaft eines verwalteten privaten Endpunkts in den Umgebungen unterschiedlich ist, können Sie diese überschreiben, indem Sie die Eigenschaft parametrisieren und den entsprechenden Wert während der Bereitstellung angeben. Weitere Informationen finden Sie im Artikel Bewährte Methoden für CI/CD.

Selbstgehostete Integrationslaufzeit

Um zu verhindern, dass sich Daten aus verschiedenen Umgebungen gegenseitig beeinträchtigen, und um die Sicherheit der Produktionsumgebung zu gewährleisten, muss für jede Umgebung eine entsprechende selbstgehostete Integration Runtime erstellt werden. Dies gewährleistet eine ausreichende Isolation zwischen verschiedenen Umgebungen.

Da die selbstgehostete Integration Runtime auf einem kundenseitig verwalteten Computer ausgeführt wird, können die freigegebenen Funktionen der selbstgehosteten Integration Runtime für verschiedene Projekte in derselben Umgebung genutzt werden, um Kosten, Wartungs- und Aktualisierungsaufwand so weit wie möglich zu reduzieren. Ausführliche Informationen zur Freigabe einer selbstgehosteten Integration Runtime finden Sie im Artikel Erstellen einer freigegebenen selbstgehosteten Integration Runtime in Azure Data Factory. Um die Sicherheit der Daten während der Übertragung zu erhöhen, kann gleichzeitig eine private Verbindung verwendet werden, um die Datenquellen und den Schlüsseltresor zu verbinden und die Kommunikation zwischen der selbstgehosteten Integration Runtime und dem Azure Data Factory-Dienst zu ermöglichen.

1. ExpressRoute ist nicht zwingend erforderlich. Ohne ExpressRoute erreichen die Daten die Senke nicht über private Netzwerke wie z. B. ein virtuelles Netzwerk oder eine private Verbindung, sondern über das öffentliche Netzwerk.
2. Wenn das lokale Netzwerk über ExpressRoute oder VPN mit dem virtuellen Azure-Netzwerk verbunden ist, kann die selbstgehostete Integration Runtime auf virtuellen Computern in einem Hub-VNET installiert werden.
3. Die Architektur des virtuellen Hub-Spoke-Netzwerks kann nicht nur für verschiedene Projekte, sondern auch für verschiedene Umgebungen (Produktion, QA und Entwicklung) verwendet werden.
4. Die selbstgehostete Integration Runtime kann für mehrere Data Factorys freigegeben werden. Die primäre Data Factory verweist darauf als freigegebene selbstgehostete Integration Runtime, andere als verknüpfte selbstgehostete Integration Runtime. Eine physische selbstgehostete Integration Runtime kann mehrere Knoten in einem Cluster aufweisen. Die Kommunikation erfolgt nur zwischen der primären selbstgehosteten Integration Runtime und dem primären Knoten, wobei die Arbeit vom primären Knoten an sekundäre Knoten verteilt wird.
5. Anmeldeinformationen lokaler Datenspeicher können entweder auf dem lokalen Computer oder in einer Azure Key Vault-Instanz gespeichert werden. Azure Key Vault wird dringend empfohlen.
6. Die Kommunikation zwischen der selbstgehosteten Integration Runtime und der Data Factory kann über eine private Verbindung erfolgen. Derzeit unterstützen das interaktive Authoring über Azure Relay und die automatische Aktualisierung auf die neueste Version aus dem Download Center jedoch keine private Verbindung. Der Datenverkehr durchläuft die Firewall der lokalen Umgebung. Weitere Informationen finden Sie im Artikel Azure Private Link für Azure Data Factory.
7. Die private Verbindung ist nur für die primäre Data Factory erforderlich. Der gesamte Datenverkehr wird über die primäre Data Factory und dann an anderen Data Factorys weitergeleitet.
8. Es wird in allen Phasen von CI/CD derselbe Name der selbstgehosteten Integration Runtime erwartet. Sie können die Verwendung einer ternären Factory in Betracht ziehen, die nur die freigegebenen selbstgehosteten Integration Runtimes enthält, und die verknüpfte selbstgehostete Integration Runtime in den verschiedenen Produktionsphasen verwenden. Weitere Informationen finden Sie im Artikel Continuous Integration und Continuous Delivery.
9. Durch Konfigurieren Ihres lokalen Netzwerks oder von ExpressRoute können Sie steuern, wie der Datenverkehr an das Download Center und Azure Relay weitergeleitet wird, entweder über einen lokalen Proxy oder ein virtuelles Hubnetzwerk. Stellen Sie sicher, dass der Datenverkehr durch Proxy- oder NSG-Regeln zugelassen ist.
10. Wenn Sie die Kommunikation zwischen Knoten der selbstgehosteten Integration Runtime sichern wollen, können Sie den Remotezugriff aus dem Intranet mit einem TLS/SSL-Zertifikat aktivieren. Weitere Informationen finden Sie im Artikel Aktivieren des Remotezugriffs über das Intranet mit TLS-/SSL-Zertifikat (Erweitert).