Teilen über

Verwaltetes virtuelles Netzwerk in Azure Data Factory

  • Artikel

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!

In diesem Artikel werden das verwaltete virtuelle Netzwerk und verwaltete private Endpunkte in Azure Data Factory erläutert.

Verwaltetes virtuelles Netzwerk

Wenn Sie eine Azure Integration Runtime in einem verwalteten virtuellen Azure Data Factory-Netzwerk erstellen, wird die Integration Runtime mit dem verwalteten virtuellen Netzwerk bereitgestellt. Sie verwendet private Endpunkte, um eine sichere Verbindung mit unterstützten Datenspeichern herzustellen.

Durch das Erstellen einer Integration Runtime in einem verwaltetem virtuellen Netzwerk wird sichergestellt, dass der Datenintegrationsprozess isoliert und sicher ist.

Vorteile der Verwendung eines verwalteten virtuellen Netzwerks:

  • Mit einem verwalteten virtuellen Netzwerk können Sie die Verwaltung des virtuellen Netzwerks an Data Factory auslagern. Es ist nicht erforderlich, ein Subnetz für die Integration Runtime zu erstellen, das letztendlich viele private IP-Adressen Ihres virtuellen Netzwerks verwenden könnte, sodass eine vorherige Planung der Netzwerkinfrastruktur erforderlich wäre.
  • Für sichere Datenintegrationen sind keine fundierten Azure-Netzwerkkenntnisse erforderlich. Die ersten Schritte mit sicherem ETL sind für Datentechniker im Vergleich viel einfacher.
  • Mit einem verwalteten virtuellen Netzwerk und verwalteten privaten Endpunkten verfügen Sie über einen Schutz vor Datenexfiltration.

Derzeit wird das verwaltete virtuelle Netzwerk nur in derselben Region wie Data Factory unterstützt.

Hinweis

Für eine vorhandene globale Integration Runtime-Instanz kann keine Umstellung auf eine Integration Runtime-Instanz in einem verwalteten virtuellen Data Factory-Netzwerk durchgeführt werden (und umgekehrt).

Das Diagramm zeigt die Architektur des verwalteten virtuellen Data Factory-Netzwerks.

Es gibt zwei Möglichkeiten, ein verwaltetes virtuelles Netzwerk in Data Factory zu aktivieren:

  1. Aktivieren eines verwalteten virtuellen Netzwerks beim Erstellen von Data Factory

Screenshot: Aktivieren des verwalteten virtuellen Netzwerks beim Erstellen der Data Factory.

  1. Aktivieren des verwalteten virtuellen Netzwerks in der Integrationslaufzeit

Screenshot: Aktivieren des verwalteten virtuellen Netzwerks in der Integrationslaufzeit

Verwaltete private Endpunkte

Verwaltete private Endpunkte sind private Endpunkte, die im verwalteten virtuellen Data Factory-Netzwerk erstellt werden, das eine private Verbindung zu Azure-Ressourcen herstellt. Data Factory verwaltet diese privaten Endpunkte für Sie.

Data Factory unterstützt private Verbindungen. Sie können die private Azure-Verbindung verwenden, um auf PaaS-Dienste (Platform as a Service) von Azure wie Azure Storage, Azure Cosmos DB und Azure Synapse Analytics zuzugreifen.

Bei der Verwendung eines privaten Links wird der Datenverkehr zwischen Ihrem Datenspeicher und dem verwalteten virtuellen Netzwerk vollständig über das Microsoft-Backbonenetzwerk übertragen. Eine private Verbindung schützt vor einer möglichen Datenexfiltration. Ein privater Link zu einer Ressource wird durch die Erstellung eines privaten Endpunkts eingerichtet.

Ein privater Endpunkt nutzt eine private IP-Adresse im verwalteten virtuellen Netzwerk, um den Dienst effektiv darin einzubinden. Private Endpunkte werden einer bestimmten Ressource in Azure und nicht dem gesamten Dienst zugeordnet. Kunden können die Konnektivität auf eine bestimmte Ressource beschränken, die von Ihrer Organisation genehmigt wurde. Weitere Informationen finden Sie unter Private Verbindungen und private Endpunkte.

Hinweis

Der Ressourcenanbieter „Microsoft.Network“ muss in Ihrem Abonnement registriert ist.

  1. Stellen Sie sicher, dass Sie in Ihrer Data Factory ein verwaltetes virtuelles Netzwerk aktivieren.
  2. Erstellen Sie unter Verwaltungshub einen neuen verwalteten privaten Endpunkt.

Screenshot: Die neuen verwalteten privaten Endpunkte.

  1. Wenn Sie einen verwalteten privaten Endpunkt in Data Factory erstellen, wird eine Verbindung mit einem privaten Endpunkt mit dem Status Ausstehend erstellt. Ein Genehmigungsworkflow wird ausgelöst. Der Besitzer der Ressource für private Verbindungen ist für die Genehmigung oder Ablehnung der Verbindung verantwortlich.

Screenshot: Option „Genehmigungen verwalten“ im Azure-Portal.

  1. Wenn der Besitzer die Verbindung genehmigt, wird der private Link eingerichtet. Andernfalls wird der private Link nicht eingerichtet. In beiden Fällen wird der verwaltete private Endpunkt mit dem Status der Verbindung aktualisiert.

Screenshot: Genehmigen eines verwalteten privaten Endpunkts.

Nur ein verwalteter privater Endpunkt im genehmigten Zustand kann Datenverkehr an eine angegebene Ressource für private Verbindungen senden.

Hinweis

Benutzerdefinierte DNS wird im verwalteten virtuellen Netzwerk nicht unterstützt.

Interaktive Erstellung

Interaktive Erstellungsfunktionen werden beispielsweise für Testverbindungen, das Durchsuchen von Ordner- und Tabellenlisten, das Abrufen von Schemas und die Vorschau von Daten verwendet. Sie können die interaktive Erstellung aktivieren, wenn Sie eine Azure Integration Runtime erstellen oder bearbeiten, die sich in einem verwalteten virtuellen Netzwerk in Azure Data Factory befindet. Der Back-End-Dienst weist vorab Computeressourcen für die interaktive Erstellung zu. Andernfalls werden Computeressourcen jedes Mal zugewiesen, wenn eine interaktive ausgeführt wird. Dies nimmt mehr Zeit in Anspruch. Die Gültigkeitsdauer (Time To Live, TTL) für das interaktive Authoring beträgt standardmäßig 60 Minuten. Das bedeutet, dass das Feature 60 Minuten nach dem letzten interaktiven Authoring-Vorgang deaktiviert wird. Sie können den TTL-Wert entsprechend Ihren tatsächlichen Bedürfnissen ändern.

Screenshot: Interaktive Erstellung.

Gültigkeitsdauer

Copy-Aktivität

Standardmäßig wird bei jeder Copy-Aktivität ein neuer Compute auf der Grundlage der Konfiguration in der Copy-Aktivität gestartet. Wenn das verwaltete virtuelle Netzwerk aktiviert ist, dauert der Kaltstart der Computeressourcen einige Minuten, und die Datenverschiebungen können erst beginnen, wenn der Start abgeschlossen ist. Wenn Ihre Pipelines mehrere sequenzielle Copy-Aktivitäten enthalten oder Sie viele Copy-Aktivitäten in der ForEach-Schleife haben und diese nicht alle parallel ausführen können, können Sie in der Azure Integration Runtime-Konfiguration den TTL-Wert (Time to Live) aktivieren. Die Angabe eines TTL-Werts und der DIU-Nummern, die für die Copy-Aktivität erforderlich sind, sorgt dafür, dass der entsprechende Compute nach Abschluss seiner Ausführung für eine bestimmte Zeitspanne erhalten bleibt. Wenn eine neue Copy-Aktivität während der TTL-Zeit beginnt, werden die vorhandenen Computeressourcen wiederverwendet und die Startzeit wird erheblich verkürzt. Nachdem die zweite Copy-Aktivität abgeschlossen ist, bleiben die Computes erneut für die angegebene TTL-Zeit aktiv. Sie haben die Flexibilität, aus den vordefinierten Computegrößen zu wählen, die von klein über mittel bis groß reichen. Alternativ haben Sie auch die Möglichkeit, die Computegröße auf der Grundlage Ihrer spezifischen Anforderungen und Echtzeitbedürfnisse anzupassen.

Hinweis

Die Neukonfiguration der DIU-Nummer hat keinen Einfluss auf die Ausführung der aktuellen Copy-Aktivität.

Hinweis

Das Measure für die Datenintegrationseinheit (DIU) von 2 DIU wird für die Copy-Aktivität in einem verwalteten virtuellen Netzwerk nicht unterstützt.

Die in TTL ausgewählte DIU wird zum Ausführen aller Copy-Aktivitäten verwendet, die Größe der DIU wird nicht automatisch für den aktuellen Bedarf skaliert. Sie müssen also genügend DIUs auswählen.

Warnung

Wenn Sie einige DIUs auswählen, um viele Aktivitäten auszuführen, befinden sich dadurch viele Aktivitäten in der Warteschlange, was die Gesamtleistung erheblich beeinträchtigt.

Pipeline und externe Aktivität

Ähnlich wie bei der Kopie haben Sie die Möglichkeit, die Computegröße und die TTL-Dauer an Ihre speziellen Anforderungen anzupassen. Bitte beachten Sie jedoch, dass im Gegensatz zur Kopie die Pipeline und die externe TTL nicht deaktiviert werden können.

Hinweis

Gültigkeitsdauer (TTL) ist nur auf verwaltete virtuelle Netzwerke anwendbar.

Screenshot: TTL-Konfiguration.

Sie können die folgende Tabelle als Referenz verwenden, um die optimale Anzahl von Knoten für die Ausführung von Pipelines und externen Aktivitäten zu bestimmen.

Activity Type Capacity
Pipelineaktivität Ungefähr 50 pro Knoten
Skriptaktivität und Lookup-Aktivität mit SQL alwaysEncrypted verbrauchen im Vergleich zu anderen Pipelineaktivitäten tendenziell mehr Ressourcen, wobei die vorgeschlagene Anzahl etwa 10 pro Knoten beträgt.
Externe Aktivität Ungefähr 800 pro Knoten

Vergleich der unterschiedlichen TTL-Arten

In der folgenden Tabelle sind die Unterschiede zwischen verschiedenen TTL-Arten aufgeführt:

Funktion Interaktive Erstellung Computeskalierung kopieren Pipeline und externe Computeskalierung
Zeitpunkt der Wirksamkeit Direkt nach Aktivierung Ausführung der ersten Aktivität Ausführung der ersten Aktivität
Kann deaktiviert sein J Y N
Reservierte Computeressourcen sind konfigurierbar N J J

Hinweis

In der standardmäßigen automatisch auflösenden Azure Integration Runtime können Sie TTL nicht aktivieren. Sie können eine neue Azure Integration Runtime dafür erstellen.

Hinweis

Wenn der Computestaffelungs-TTL für Kopie/Pipeline/Extern aktiviert wird, wird die Abrechnung von den reservierten Computeressourcen bestimmt. Daher enthält die Ausgabe der Aktivität nicht die billingReference, da dies ausschließlich in Nicht-TTL-Szenarien relevant ist.

Erstellen eines verwalteten virtuellen Netzwerks über Azure PowerShell

$subscriptionId = ""
$resourceGroupName = ""
$factoryName = ""
$managedPrivateEndpointName = ""
$integrationRuntimeName = ""
$apiVersion = "2018-06-01"
$privateLinkResourceId = ""

$vnetResourceId = "subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.DataFactory/factories/${factoryName}/managedVirtualNetworks/default"
$privateEndpointResourceId = "subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.DataFactory/factories/${factoryName}/managedVirtualNetworks/default/managedprivateendpoints/${managedPrivateEndpointName}"
$integrationRuntimeResourceId = "subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.DataFactory/factories/${factoryName}/integrationRuntimes/${integrationRuntimeName}"

# Create managed Virtual Network resource
New-AzResource -ApiVersion "${apiVersion}" -ResourceId "${vnetResourceId}" -Properties @{}

# Create managed private endpoint resource
New-AzResource -ApiVersion "${apiVersion}" -ResourceId "${privateEndpointResourceId}" -Properties @{
        privateLinkResourceId = "${privateLinkResourceId}"
        groupId = "blob"
    }

# Create integration runtime resource enabled with virtual network
New-AzResource -ApiVersion "${apiVersion}" -ResourceId "${integrationRuntimeResourceId}" -Properties @{
        type = "Managed"
        typeProperties = @{
            computeProperties = @{
                location = "AutoResolve"
                dataFlowProperties = @{
                    computeType = "General"
                    coreCount = 8
                    timeToLive = 0
                }
            }
        }
        managedVirtualNetwork = @{
            type = "ManagedVirtualNetworkReference"
            referenceName = "default"
        }
    }

Hinweis

Die groupId anderer Datenquellen erhalten Sie aus einer Private Link-Ressource.

Hinweis

Der Wert von referenceName sollte nur bei der Erstellung über einen PowerShell-Befehl als „default“ festgelegt werden.

Ausgehende Verbindung

Unterstützte Datenquellen und Dienste

Die folgenden Dienste verfügen über native Unterstützung für private Endpunkte. Sie können über eine private Verbindung mit einem virtuellen Data Factory-Netzwerk verbunden werden:

  • Azure Databricks
  • Azure Functions (Premium-Plan)
  • Azure-Schlüsseltresor
  • Azure Machine Learning
  • Azure Private Link
  • Microsoft Purview

Weitere Informationen zur Unterstützung von Datenquellen finden Sie in der Übersicht zu, Connector. Sie können über das öffentliche Netzwerk auf alle Datenquellen zugreifen, die von Data Factory unterstützt werden.

Lokale Datenquellen

Informationen zum Zugriff auf lokale Datenquellen aus dem verwalteten virtuellen Netzwerk mithilfe eines privaten Endpunkts finden Sie unter Zugreifen auf eine lokale SQL Server-Instanz über ein verwaltetes virtuelles Netzwerk in Azure Data Factory mithilfe eines privaten Endpunkts.

Ausgehende Kommunikation über einen öffentlichen Endpunkt von einem verwaltetem virtuellen Data Factory-Netzwerk

Alle Ports sind für die ausgehende Kommunikation geöffnet.

Einschränkungen und bekannte Probleme

Erstellung eines verknüpften Diensts für Key Vault

Wenn Sie einen verknüpften Dienst für Key Vault erstellen, gibt es keinen Verweis auf Integration Runtime. Daher können Sie während der Erstellung eines verknüpften Diensts von Key Vault keine privaten Endpunkte erstellen. Sie können aber einen privaten Endpunkt für Key Vault erstellen, wenn Sie einen verknüpften Dienst für Datenspeicher erstellen, der auf den verknüpften Dienst von Key Vault verweist, der wiederum auf die Integration Runtime mit aktiviertem verwaltetem virtuellem Netzwerk verweist.

  • Verbindung testen Bei diesem Vorgang für den verknüpften Dienst von Key Vault wird nur das URL-Format überprüft. Es werden dabei jedoch keine Netzwerkvorgänge ausgeführt.
  • Privater Endpunkt wird verwendet: Diese Spalte ist immer leer, selbst wenn Sie einen privaten Endpunkt für Key Vault erstellen.

Erstellung eines verknüpften Diensts von Azure HDInsight

Die Spalte Privaten Endpunkt verwenden wird immer als leer angezeigt, selbst wenn Sie einen privaten Endpunkt für HDInsight mithilfe eines Private Link-Diensts und Lastenausgleichs mit Portweiterleitung erstellen.

Screenshot: Privater Endpunkt für Key Vault.

Vollqualifizierter Domänenname (FQDN) von Azure HDInsight

Wenn Sie einen benutzerdefinierten Private Link-Dienst erstellt haben, sollte der FQDN beim Erstellen eines privaten Endpunkts mit azurehdinsight.net enden, ohne vorangestelltes privatelink im Domänennamen. Wenn Sie „privatelink“ im Domänennamen verwenden, stellen Sie sicher, dass er gültig ist und aufgelöst werden kann.

Zugriffseinschränkungen im verwalteten virtuellen Netzwerk mit privaten Endpunkten

Sie können nicht auf jede PaaS-Ressourcen zugreifen, wenn beide Seiten für eine private Verbindung und einen privaten Endpunkt verfügbar gemacht werden. Dieser Fehler ist eine bekannte Einschränkung privater Verbindungen und privater Endpunkte.

Sie verfügen beispielsweise über einen verwalteten privaten Endpunkt für Speicherkonto A. Sie können auch über das öffentliche Netzwerk im gleichen verwalteten virtuellen Netzwerk auf Speicherkonto B zugreifen. Wenn Speicherkonto B jedoch über eine private Endpunktverbindung aus einem anderen verwalteten virtuellen Netzwerk oder einem virtuellen Kundennetzwerk verfügt, können Sie nicht über ein öffentliches Netzwerk auf Speicherkonto B in Ihrem verwalteten virtuellen Netzwerk zugreifen.

Zugehöriger Inhalt

Arbeiten Sie die folgenden Tutorials durch: