Standardmethode zur Integration virtueller Netzwerke

GILT FÜR: Azure Data Factory Azure Synapse Analytics

Tipp

Data Factory in Microsoft Fabric ist die nächste Generation von Azure Data Factory mit einer einfacheren Architektur, integrierter KI und neuen Features. Wenn Sie mit der Datenintegration noch nicht vertraut sind, beginnen Sie mit Fabric Data Factory. Vorhandene ADF-Workloads können auf Fabric aktualisiert werden, um auf neue Funktionen in der Datenwissenschaft, Echtzeitanalysen und Berichterstellung zuzugreifen.

Wenn Sie SQL Server Integration Services (SSIS) in Azure Data Factory (ADF) oder Synapse Pipelines verwenden, gibt es zwei Methoden, um Ihre Azure-SSIS Integration Runtime (IR) mit einem virtuellen Netzwerk zu verbinden: Standard und Express. Wenn Sie die Standardmethode verwenden, müssen Sie Ihr virtuelles Netzwerk so konfigurieren, dass es die folgenden Anforderungen erfüllt:

  • Stellen Sie sicher, dass Microsoft.Batch ein registrierter Ressourcenanbieter im Azure-Abonnement ist, das das virtuelle Netzwerk für den Beitritt Ihres Azure-SSIS IR bereitstellt. Ausführliche Anweisungen finden Sie im Abschnitt Azure Batch als Ressourcenanbieter registrieren.

  • Stellen Sie sicher, dass der Benutzer, der Azure-SSIS IR erstellt, die erforderlichen Berechtigungen für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) erhält, um einem virtuellen Netzwerk/Subnetz beizutreten. Weitere Informationen finden Sie weiter unten im Abschnitt Auswählen von Berechtigungen für virtuelle Netzwerke.

  • Wählen Sie ein geeignetes Subnetz im virtuellen Netzwerk aus, dem Ihr Azure-SSIS IR beitreten soll. Weitere Informationen finden Sie weiter unten im Abschnitt Auswählen eines Subnetzes.

Je nach Ihrem spezifischen Szenario können Sie optional Folgendes konfigurieren:

  • Wenn Sie Ihre eigenen statischen öffentlichen IP-Adressen (BYOIP) für den ausgehenden Datenverkehr Ihrer Azure-SSIS IR verwenden möchten, lesen Sie den Abschnitt Konfigurieren statischer öffentlicher IP-Adressen weiter unten.

  • Wenn Sie Ihren eigenen DNS-Server (Domain Name System) im virtuellen Netzwerk verwenden möchten, lesen Sie den Abschnitt Konfigurieren eines benutzerdefinierten DNS-Servers weiter unten.

  • Wenn Sie eine Netzwerksicherheitsgruppe (NSG) verwenden möchten, um eingehenden/ausgehenden Datenverkehr im Subnetz einzuschränken, lesen Sie den Abschnitt Konfigurieren einer NSG weiter unten.

  • Wenn Sie benutzerdefinierte Routen (User-Defined Routes, UDRs) verwenden möchten, um ausgehenden Datenverkehr zu überwachen/zu überprüfen, lesen Sie den Abschnitt Konfigurieren von UDRs weiter unten.

  • Stellen Sie sicher, dass die Ressourcengruppe des virtuellen Netzwerks (oder die Ressourcengruppe der öffentlichen IP-Adressen, wenn Sie Ihre eigenen öffentlichen IP-Adressen verwenden) bestimmte Azure-Netzwerkressourcen erstellen und löschen kann. Weitere Informationen finden Sie unter Konfigurieren der relevanten Ressourcengruppe.

  • Wenn Sie Ihre Azure-SSIS IR wie im Artikel Benutzerdefiniertes Setup für Azure-SSIS IR beschrieben anpassen, nutzt unser interner Prozess zum Verwalten der Knoten private IP-Adressen aus einem vordefinierten Bereich von 172.16.0.0 bis 172.31.255.255. Daher sollten Sie sicherstellen, dass die privaten IP-Adressbereiche Ihrer virtuellen und lokalen Netzwerke nicht mit diesem Bereich kollidieren.

Dieses Diagramm veranschaulicht die für die Azure-SSIS IR erforderlichen Verbindungen:

Diagramm der für die Azure-SSIS IR erforderlichen Verbindungen

Auswählen von virtuellen Netzwerkberechtigungen

Um die standardmäßige Einschleusung virtueller Netzwerke zu aktivieren, müssen dem Benutzer, der Azure-SSIS IR erstellt, die erforderlichen RBAC-Berechtigungen zum Beitreten zum virtuellen Netzwerk/Subnetz erteilt werden.

  • Wenn Sie Ihre Azure SSIS IR in ein virtuelles Azure Resource Manager-Netzwerk einbinden, haben Sie zwei Möglichkeiten:

    • Verwenden Sie die integrierte Rolle Netzwerkmitwirkender. Diese Rolle umfasst die Berechtigung Microsoft.Network/*, die jedoch einen deutlich größeren Umfang als erforderlich hat.

    • Erstellen Sie eine benutzerdefinierte Rolle, die nur die erforderliche Berechtigung Microsoft.Network/virtualNetworks/*/join/action aufweist. Wenn Sie beim Verknüpfen der Azure-SSIS IR mit einem virtuellen Azure Resource Manager-Netzwerk auch Ihre eigenen statischen öffentlichen IP-Adressen für Azure-SSIS IR verwenden möchten, fügen Sie zudem die Berechtigung Microsoft.Network/publicIPAddresses/*/join/action mit in die Rolle ein.

    • Ausführliche Anweisungen finden Sie im Abschnitt Erteilen von Berechtigungen für virtuelle Netzwerke.

  • Wenn Sie Ihre Azure-SSIS IR mit einem klassischen virtuellen Netzwerk verknüpfen, empfiehlt es sich, die integrierte Rolle Mitwirkender für klassische virtuelle Computer zu verwenden. Andernfalls müssen Sie eine benutzerdefinierte Rolle definieren, welche die Berechtigung zum Einbinden in das virtuelle Netzwerk enthält. Außerdem müssen Sie dieser integrierten/benutzerdefinierten Rolle MicrosoftAzureBatch zuweisen.

Auswählen eines Subnetzes

Um die standardmäßige Einschleusung virtueller Netzwerke zu aktivieren, müssen Sie ein geeignetes Subnetz auswählen, damit Ihre Azure-SSIS IR beitreten kann:

  • Wählen Sie nicht das GatewaySubnet aus, da es virtuellen Netzwerken vorbehalten ist.

  • Stellen Sie sicher, dass das ausgewählte Subnetz über IP-Adressen für mindestens die doppelte Anzahl Ihrer Azure-SSIS IR-Knoten verfügt. Diese sind erforderlich, um Unterbrechungen beim Rollout von Patches/Upgrades für Ihre Azure-SSIS IR zu vermeiden. Azure reserviert auch einige IP-Adressen, die nicht in allen Subnetzen verwendet werden können. Die erste und letzte IP-Adresse werden für Protokollkonformität reserviert, während drei weitere Adressen für Azure-Dienste reserviert werden. Weitere Informationen finden Sie im Abschnitt Einschränkungen für Subnetz-IP-Adressen.

  • Verwenden Sie kein Subnetz, das ausschließlich von anderen Azure-Diensten genutzt wird (z. B. Azure SQL Managed Instance, App Service usw.).

Konfigurieren einer statischen öffentlichen IP-Adresse

Wenn Sie ihre eigenen statischen öffentlichen IP-Adressen für den ausgehenden Datenverkehr von Azure-SSIS IR beim Verknüpfen mit einem virtuellen Netzwerk verwenden möchten, damit Sie diese in Ihren Firewalls zulassen können, stellen Sie sicher, dass sie die folgenden Anforderungen erfüllen:

  • Es müssen genau zwei ungenutzte bereitgestellt werden, die noch nicht mit anderen Azure-Ressourcen verknüpft sind. Die zusätzliche Adresse wird bei der regelmäßigen Aktualisierung Ihrer Azure-SSIS IR verwendet. Beachten Sie, dass eine einzige öffentliche IP-Adresse nicht von Ihren aktiven Azure-SSIS-IRs gemeinsam genutzt werden kann.

  • Beide Adressen müssen statische Standardadressen sein. Weitere Details finden Sie unter SKUs der öffentlichen IP-Adresse.

  • Beide Adressen müssen einen DNS-Namen aufweisen. Wenn Sie bei der Erstellung noch keinen DNS-Namen angegeben haben, können Sie dies im Azure-Portal erledigen.

    Azure-SSIS-Integrationslaufzeit

  • Die Adressen und das virtuelle Netzwerk müssen sich im selben Abonnement und in derselben Region befinden.

Konfigurieren eines benutzerdefinierten DNS-Servers

Wenn Sie Ihren eigenen DNS-Server im virtuellen Netzwerk verwenden möchten, um Ihre privaten Hostnamen aufzulösen, stellen Sie sicher, dass er auch globale Azure-Hostnamen auflösen kann (z. B. Ihre Azure Blob Storage namens <your storage account>.blob.core.windows.).

Es wird empfohlen, ihren eigenen DNS-Server so zu konfigurieren, dass nicht aufgelöste DNS-Anforderungen an die IP-Adresse rekursiver Azure-Konfliktlöser weitergeleitet werden (168.63.129.16).

Weitere Informationen finden Sie im Abschnitt DNS-Servernamensauflösung.

Hinweis

Verwenden Sie bitte einen vollqualifizierten Domänennamen für Ihren privaten Hostnamen (verwenden Sie z. B. <your_private_server>.contoso.com anstelle von <your_private_server>). Alternativ können Sie ein benutzerdefiniertes Standardsetup in Ihrer Azure-SSIS IR verwenden, um automatisch Ihr eigenes DNS-Suffix (z. B. contoso.com) an einen nicht qualifizierten Domänennamen mit einer einzelnen Bezeichnung anfügen und in einen FQDN ändern, bevor Sie es in DNS-Abfragen verwenden. Weitere Informationen finden Sie im Abschnitt Beispiele für das benutzerdefinierte Standardsetup.

Konfigurieren einer Netzwerksicherheitsgruppe (NSG)

Wenn Sie eine NSG in dem Subnetz verwenden möchten, das mit Ihrer Azure-SSIS IR verknüpft ist, lassen Sie den folgenden ausgehenden Datenverkehr zu:

Richtung Transportprotokoll Quelle Quellports Ziel Zielports Kommentare
Eingehend TCP BatchNodeManagement * VirtualNetwork 29876, 29877 (wenn Sie die SSIS IR mit einem virtuellen Azure Resource Manager-Netzwerk verknüpfen)

10100, 20100, 30100 (wenn Sie Ihre SSIS IR mit einem klassischen virtuellen Netzwerk verbinden)
Der Data Factory-Dienst nutzt diese Ports für die Kommunikation mit den Knoten Ihrer Azure-SSIS IR im virtuellen Netzwerk.

Unabhängig davon, ob Sie eine NSG im Subnetz erstellen, konfiguriert Data Factory immer eine NSG auf der Netzwerkschnittstellenkarte (NIC), die an virtuelle Computer angefügt ist, die Ihre Azure-SSIS IR hosten.

Nur eingehender Datenverkehr von Data Factory-IP-Adressen für die angegebenen Ports wird durch diese NSG auf NIC-Ebene zugelassen.

Auch wenn Sie diese Ports für den Internetdatenverkehr auf Subnetzebene öffnen, wird Datenverkehr von anderen IP-Adressen als Data Factory-IP-Adressen auf NIC-Ebene blockiert.
Eingehend TCP CorpNetSaw * VirtualNetwork 3389 (Optional) Nur erforderlich, wenn Ein Microsoft-Supporttechniker Sie auffordert, Port 3389 für die erweiterte Problembehandlung zu öffnen.Gleich nach Abschluss der Problembehandlung kann der Port wieder geschlossen werden.

Mit dem Servicetag CorpNetSaw können nur SAW-Computer (Secure Access Workstation) im Microsoft-Unternehmensnetzwerk über Remotedesktopprotokoll (RDP) auf Ihre Azure-SSIS IR zugreifen.

Dieses Diensttag kann im Portal nicht ausgewählt werden und steht nur über Azure PowerShell/CLI zur Verfügung.

In der NSG auf NIC-Ebene ist Port 3389 standardmäßig geöffnet. Sie können ihn jedoch mit einer NSG auf Subnetzebene steuern, während ausgehender Datenverkehr auf ihren Azure-SSIS IR Knoten gemäß Windows Firewallregel standardmäßig nicht zulässig ist.
Richtung Transportprotokoll `Source` Quellports Ziel Zielports Kommentare
Ausgehend TCP VirtualNetwork * AzureCloud 443 Erforderlich, damit Ihre Azure-SSIS IR auf Azure-Dienste wie Azure Storage und Azure Event Hubs zugreifen kann.
Ausgehend TCP VirtualNetwork * Internet 80 (Optional) Ihr Azure-SSIS IR verwendet diesen Port, um eine Zertifikatsperrliste (Certificate Revocation List, CRL) aus dem Internet herunterzuladen.

Wenn Sie diesen Datenverkehr blockieren, kann es beim Starten ihrer Azure-SSIS IR zu einer Leistungsbeeinträchtigung kommen und die Möglichkeit zum Überprüfen von CRLs bei der Verwendung von Zertifikaten verloren gehen. Dies wird unter Sicherheitsgesichtspunkten nicht empfohlen.

Wenn Sie Ziele auf bestimmte FQDNs einengen möchten, lesen Sie den Abschnitt Konfigurieren von UDRs weiter unten
Ausgehend TCP VirtualNetwork * Sql/VirtualNetwork 1433, 11000–11999 (Optional) Nur erforderlich, wenn Sie Azure SQL-Datenbank-Server/Verwaltete Instanz zum Hosten des SSIS-Katalogs (SSISDB) verwenden.

Wenn Ihr(e) Azure SQL-Datenbank-Server/Verwaltete Instanz mit einem öffentlichen Endpunkt/VNET-Dienstendpunkt konfiguriert ist, verwenden Sie das Servicetag SQL als Ziel.

Wenn Ihr(e) Azure SQL-Datenbank-Server/Verwaltete Instanz mit einem privaten Endpunkt konfiguriert ist, verwenden Sie das Servicetag VirtualNetwork als Ziel.

Wenn die Verbindungsrichtlinie Ihres Servers auf Proxy statt auf Redirect festgelegt ist, wird nur Port 1433 benötigt.
Ausgehend TCP VirtualNetwork * Storage/VirtualNetwork 443 (Optional) Nur erforderlich, wenn Sie Azure Storage-Blobcontainer zum Speichern Ihrer standardmäßigen benutzerdefinierten Setupskripts/-dateien verwenden.

Wenn Ihr Azure Storage mit einem öffentlichen Endpunkt/VNET-Serviceendpunkt konfiguriert ist, verwenden Sie das Servicetag Storage als Ziel.

Wenn Ihr Azure Storage mit einem privaten Endpunkt konfiguriert ist, verwenden Sie das Servicetag VirtualNetwork als Ziel.
Ausgehend TCP VirtualNetwork * Storage/VirtualNetwork 445 (Optional) Nur erforderlich, wenn Sie auf Azure Files zugreifen müssen.

Wenn Ihr Azure Storage mit einem öffentlichen Endpunkt/VNET-Serviceendpunkt konfiguriert ist, verwenden Sie das Servicetag Storage als Ziel.

Wenn Ihr Azure Storage mit einem privaten Endpunkt konfiguriert ist, verwenden Sie das Servicetag VirtualNetwork als Ziel.

Konfigurieren von UDRs

Wenn Sie den ausgehenden Datenverkehr von Ihrer Azure-SSIS IR überwachen/überprüfen möchten, können Sie ihn mithilfe von benutzerdefinierten Routen (User-Defined Routes, UDRs) über Azure ExpressRoute-Tunnelerzwingung, die die BGP-Route (Border Gateway Protocol), 0.0.0.0/0 ankündigt, an das virtuelle Netzwerk, an ein virtuelles Netzwerkgerät (Network Virtual Appliance, NVA), das als Firewall konfiguriert ist, oder an den Azure Firewall-Dienst umleiten.

NVA-Szenario für Azure-SSIS IR

Damit dies funktioniert, müssen Sie Folgendes sicherstellen:

  • Der Datenverkehr zwischen Azure Batch Verwaltungsdienst und Ihrem Azure-SSIS IR sollte nicht an eine Firewall-Appliance/einen Firewalldienst weitergeleitet werden.

  • Die Firewall-Appliance bzw. der Dienst muss den ausgehenden Datenverkehr zulassen, der von Azure-SSIS IR benötigt wird.

Wenn der Datenverkehr zwischen dem Azure Batch-Verwaltungsdienst und Ihrem Azure-SSIS IR an ein Firewallgerät/einen Firewallservice geroutet wird, wird er aufgrund von asymmetrischem Routing unterbrochen. UDRs müssen für diesen Datenverkehr definiert werden, sodass er über dieselben Routen laufen kann, über die er hereingekommen ist. Sie können bestimmte UDRs definieren, um Datenverkehr zwischen Azure Batch-Verwaltungsdiensten und der Azure-SSIS IR mit Internet als dem nächsten Schritt weiterzuleiten.

Wenn sich Ihr Azure-SSIS IR beispielsweise im Vereinigtes Königreich, Süden befindet und Sie den ausgehenden Datenverkehr mithilfe von Azure Firewall überprüfen möchten, können Sie zuerst die IP-Adressbereiche für das Servicetag BatchNodeManagement.UKSouth über den Downloadlink Servicetag-IP-Bereich oder die Servicetag-Erkennungs-API abrufen. Sie können dann die folgenden UDRs für die relevanten IP-Bereichsrouten mit dem Typ des nächsten Hops als Internet und die Route 0.0.0.0/0 mit dem Typ des nächsten Hops als Virtuelles Gerät konfigurieren.

Azure Batch-UDR-Einstellungen

Hinweis

Dieser Ansatz führt zu zusätzlichen Wartungskosten, da Sie regelmäßig die relevanten IP-Adressbereiche überprüfen und UDRs für neue hinzufügen müssen, um zu vermeiden, dass Ihre Azure-SSIS IR unterbrochen wird. Es wird empfohlen, sie monatlich zu überprüfen, da es einen weiteren Monat dauert, bis ein neuer IP-Adressbereich für das entsprechende Servicetag in Kraft tritt.

Sie können das folgende PowerShell-Skript ausführen, um UDRs für den Azure Batch Verwaltungsdienst hinzuzufügen:

$Location = "[location of your Azure-SSIS IR]"
$RouteTableResourceGroupName = "[name of Azure resource group that contains your route table]"
$RouteTableResourceName = "[resource name of your route table]"
$RouteTable = Get-AzRouteTable -ResourceGroupName $RouteTableResourceGroupName -Name $RouteTableResourceName
$ServiceTags = Get-AzNetworkServiceTag -Location $Location
$BatchServiceTagName = "BatchNodeManagement." + $Location
$UdrRulePrefixForBatch = $BatchServiceTagName
if ($ServiceTags -ne $null)
{
    $BatchIPRanges = $ServiceTags.Values | Where-Object { $_.Name -ieq $BatchServiceTagName }
    if ($BatchIPRanges -ne $null)
    {
        Write-Host "Start adding UDRs to your route table..."
        for ($i = 0; $i -lt $BatchIPRanges.Properties.AddressPrefixes.Count; $i++)
        {
            $UdrRuleName = "$($UdrRulePrefixForBatch)_$($i)"
            Add-AzRouteConfig -Name $UdrRuleName `
                -AddressPrefix $BatchIPRanges.Properties.AddressPrefixes[$i] `
                -NextHopType "Internet" `
                -RouteTable $RouteTable `
                | Out-Null
            Write-Host "Add $UdrRuleName to your route table..."
        }
        Set-AzRouteTable -RouteTable $RouteTable
    }
}
else
{
    Write-Host "Failed to fetch Azure service tag, please confirm that your location is valid."
}

Entsprechend unserer Anleitung im Abschnitt Konfigurieren einer Netzwerksicherheitsgruppe (NSG) weiter oben müssen Sie ähnliche Regeln für die Firewallappliance/den Firewalldienst implementieren, um den ausgehenden Datenverkehr von Ihrer Azure-SSIS IR zuzulassen:

  • Wenn Sie die Azure Firewall verwenden, gilt Folgendes:

    • Sie müssen Port 443 für ausgehenden TCP-Datenverkehr mit dem Servicetag AzureCloud als Ziel öffnen.

    • Wenn Sie Azure SQL-Datenbank Server/Verwaltete Instanz zum Hosten von SSISDB verwenden, müssen Sie die Ports 1433, 11000-11999 für ausgehenden TCP-Datenverkehr mit dem Servicetag "Sql/VirtualNetwork" als Ziel öffnen.

    • Wenn Sie Azure Storage Blobcontainer zum Speichern Ihrer standardmäßigen benutzerdefinierten Setupskripts/-dateien verwenden, müssen Sie Port 443 für ausgehenden TCP-Datenverkehr mit dem Servicetag Storage/VirtualNetwork als Ziel öffnen.

    • Wenn Sie auf Azure Files zugreifen müssen, müssen Sie Port 445 für ausgehenden TCP-Datenverkehr mit dem Diensttag Storage/VirtualNetwork als Ziel öffnen.

  • Wenn Sie andere Firewall-Appliances/-Dienste verwenden:

    • Sie müssen Port 443 für ausgehenden TCP-Datenverkehr mit 0.0.0.0/0 oder dem folgenden Azure-umgebungsspezifischen FQDN als Ziel öffnen.

      Azure-Umgebung FQDN (vollständig qualifizierter Domainname)
      Azure Public
      • Azure Data Factory (Verwaltung)
        • *.frontend.clouddatahub.net
      • Azure Batch Node (Verwaltung)
        • BatchNodeManagement.<Region>
      • Azure Storage (Verwaltung)
        • *.blob.core.windows.net
        • *.table.core.windows.net
      • Azure Container Registry (Benutzerdefiniertes Setup)
        • *.azurecr.io
      • Event Hubs (Protokollierung)
        • *.servicebus.windows.net
      • Microsoft-Protokollierungsdienst (Interne Verwendung)
        • gcs.prod.monitoring.core.windows.net
        • prod.warmpath.msftcloudes.com
        • azurewatsonanalysis-prod.core.windows.net
      Azure Government
      • Azure Data Factory (Verwaltung)
        • *.frontend.datamovement.azure.us
      • Azure Batch Node (Verwaltung)
        • BatchNodeManagement.<Region>
      • Azure Storage (Verwaltung)
        • *.blob.core.usgovcloudapi.net
        • *.table.core.usgovcloudapi.net
      • Azure Container Registry (Benutzerdefiniertes Setup)
        • *.azurecr.us
      • Event Hubs (Protokollierung)
        • *.servicebus.usgovcloudapi.net
      • Microsoft-Protokollierungsdienst (Interne Verwendung)
        • fairfax.warmpath.usgovcloudapi.net
        • azurewatsonanalysis.usgovcloudapp.net
      Microsoft Azure, betrieben von 21Vianet
      • Azure Data Factory (Verwaltung)
        • *.frontend.datamovement.azure.cn
      • Azure Batch Node (Verwaltung)
        • BatchNodeManagement.<Region>
      • Azure Storage (Verwaltung)
        • *.blob.core.chinacloudapi.cn
        • *.table.core.chinacloudapi.cn
      • Azure Container Registry (Benutzerdefiniertes Setup)
        • *.azurecr.cn
      • Event Hubs (Protokollierung)
        • *.servicebus.chinacloudapi.cn
      • Microsoft-Protokollierungsdienst (Interne Verwendung)
        • mooncake.warmpath.chinacloudapi.cn
        • azurewatsonanalysis.chinacloudapp.cn
    • Wenn Sie Azure SQL-Datenbank server/Verwaltete Instanz zum Hosten von SSISDB verwenden, müssen Sie die Ports 1433, 11000-11999 für ausgehenden TCP-Datenverkehr mit 0.0.0.0/0 oder Ihren Azure SQL-Datenbank-Server/verwaltete Instanz-FQDN als Ziel öffnen.

    • Wenn Sie Azure Storage Blobcontainer zum Speichern Ihrer standardmäßigen benutzerdefinierten Setupskripts/-dateien verwenden, müssen Sie Port 443 für ausgehenden TCP-Datenverkehr mit dem Servicetag 0.0.0.0/0 oder Ihrem Azure Blob Storage-FQDN als Ziel öffnen.

    • Wenn Sie auf Azure Files zugreifen müssen, müssen Sie Port 445 für ausgehenden TCP-Datenverkehr mit 0.0.0.0/0 oder Ihrem Azure Files-FQDN als Ziel öffnen.

  • Wenn Sie einen VNET-Dienstendpunkt für Azure Storage/Container Registry/Event Hubs/SQL konfigurieren, indem Sie Microsoft.Storage/Microsoft.ContainerRegistry/Microsoft.EventHub/Microsoft.Sql-Ressourcen in Ihrem Subnetz aktivieren, wird der sämtliche Datenverkehr zwischen Ihrer Azure-SSIS IR und diesen Diensten in den gleichen/gekoppelten Regionen an das Azure-Backbonenetzwerk anstatt an Ihre Firewall appliance/service geroutet.

  • Sie sollten Port 80 für ausgehenden TCP-Datenverkehr mit der folgenden Zertifikatsperrliste (Certificate Revocation List, CRL) als Ziel öffnen:

    • crl.microsoft.com:80
    • mscrl.microsoft.com:80
    • crl3.digicert.com:80
    • crl4.digicert.com:80
    • ocsp.digicert.com:80
    • cacerts.digicert.com:80

    Wenn Sie Zertifikate mit unterschiedlichen CRLs verwenden, sollten Sie auch deren Downloadwebsites als Ziel hinzufügen. Weitere Informationen finden Sie im Artikel zur Zertifikatsperrliste.

    Wenn Sie diesen Datenverkehr blockieren, kann es beim Starten ihrer Azure-SSIS IR zu einer Leistungsbeeinträchtigung kommen und die Möglichkeit zum Überprüfen von CRLs bei der Verwendung von Zertifikaten verloren gehen. Dies wird unter Sicherheitsgesichtspunkten nicht empfohlen.

Wenn Sie den ausgehenden Datenverkehr aus Ihrem Azure-SSIS IR nicht überwachen/untersuchen müssen, können Sie UDRs verwenden, um den gesamten Datenverkehr mit dem Internet als dem nächsten Schritt zu erzwingen:

  • Wenn Sie Azure ExpressRoute verwenden, können Sie eine UDR für die Route 0.0.0.0/0 in Ihrem Subnetz mit dem nächsten Hop-Typ als Internet konfigurieren.

  • Wenn Sie eine NVA verwenden, können Sie den vorhandenen UDR der Route 0.0.0.0/0 in Ihrem Subnetz ändern, damit der nächster Hop-Typ von Virtuelle Appliance zu Internet wechselt.

Hinzufügen einer Route

Hinweis

Das Konfigurieren von UDRs mit dem Nächster-Hop-Typ als Internet bedeutet nicht, dass der gesamte Datenverkehr über das Internet geht. Solange die Zieladresse zu einem der Azure-Dienste gehört, wird der gesamte Datenverkehr von Azure über das Azure-Backbonenetzwerk statt über das Internet an diese Adresse weitergeleitet.

Konfigurieren der relevanten Ressourcengruppe

Um die Standard-Virtualnetzwerkeinspeisung zu ermöglichen, muss Ihr Azure-SSIS IR bestimmte Netzwerkressourcen in derselben Ressourcengruppe wie das virtuelle Netzwerk erstellen. Diese Ressourcen umfassen Folgendes:

  • Einen Azure-Lastenausgleich mit dem Namen <Guid>-azurebatch-cloudserviceloadbalancer.
  • Eine öffentliche Azure-IP-Adresse mit dem Namen <Guid>-azurebatch-cloudservicepublicip.
  • Eine Netzwerksicherheitsgruppe mit dem Namen <Guid>-azurebatch-cloudservicenetworksecuritygroup.

Hinweis

Sie können jetzt Ihre eigenen statischen öffentlichen IP-Adressen für die Azure-SSIS IR verwenden. In diesem Szenario erstellen wir nur den Azure-Lastenausgleich und die Netzwerksicherheitsgruppe in derselben Ressourcengruppe wie Ihre statischen öffentlichen IP-Adressen und nicht im virtuellen Netzwerk.

Diese Ressourcen werden beim Start Ihrer Azure-SSIS IR erstellt. Sie werden gelöscht, wenn die Azure-SSIS IR beendet wird. Wenn Sie Ihre eigenen statischen öffentlichen IP-Adressen für Azure-SSIS IR verwenden, werden diese beim Beenden der Azure-SSIS IR nicht gelöscht. Um zu verhindern, dass Ihre Azure-SSIS IR gestoppt wird, sollten Sie diese Ressourcen nicht für andere Zwecke wiederverwenden.

Stellen Sie sicher, dass weder in der Ressourcengruppe noch im Abonnement, zu denen das virtuelle Netzwerk oder Ihre statischen öffentlichen IP-Adressen gehören, eine Ressourcensperre existiert. Wenn Sie eine Schreibschutzsperre oder eine Löschsperre konfigurieren, kann beim Starten und Beenden Ihrer Azure-SSIS IR ein Fehler auftreten oder die IR nicht mehr reagieren.

Stellen Sie sicher, dass Sie keine Azure Policy-Zuweisung haben, die verhindert, dass die folgenden Ressourcen in der Ressourcengruppe oder im Abonnement erstellt werden, zu dem das virtuelle Netzwerk oder zu denen Ihre statischen öffentlichen IP-Adressen gehören.

  • Microsoft.Network/LoadBalancers
  • Microsoft.Network/NetworkSecurityGroups
  • Microsoft.Network/PublicIPAddresses

Stellen Sie sicher, dass das Ressourcenkontingent für Ihr Abonnement für diese Ressourcen ausreicht. Insbesondere müssen Sie für jede Azure-SSIS IR, die in einem virtuellen Netzwerk erstellt wurden, die doppelte Anzahl dieser Ressourcen reservieren, da die zusätzlichen Ressourcen verwendet werden, wenn wir ihr Azure-SSIS IR regelmäßig aktualisieren.

Häufig gestellte Fragen

  • Wie kann ich die öffentliche IP-Adresse schützen, die in meiner Azure-SSIS IR für eingehende Verbindungen verfügbar gemacht wird? Ist es möglich, die öffentliche IP-Adresse zu entfernen?

    Derzeit wird automatisch eine öffentliche IP-Adresse erstellt, wenn Ihre Azure-SSIS IR mit einem virtuellen Netzwerk verknüpft wird. Wir verfügen über eine NSG auf NIC-Ebene, die ausschließlich eingehende Verbindungen von Azure Batch-Verwaltungsdiensten mit Ihrer Azure-SSIS IR zulässt. Sie können auch eine NSG auf Subnetzebene festlegen, um eingehende Verbindungen zu schützen.

    Wenn Sie keine öffentliche IP-Adresse verfügbar machen möchten, sollten Sie erwägen, eine selbstgehostete IR als Proxy für Ihre Azure-SSIS IR zu konfigurieren, anstatt die Azure-SSIS IR in ein virtuelles Netzwerk einzubinden.

  • Kann ich die öffentliche IP-Adresse meines Azure-SSIS IR in die Positivliste der Firewall für meine Datenquellen aufnehmen?

    Sie können jetzt Ihre eigenen statischen öffentlichen IP-Adressen für die Azure-SSIS IR verwenden. In diesem Fall können Sie Ihre IP-Adressen in die Firewall-Zulassungsliste für Ihre Datenquellen aufnehmen. Sie können auch andere, unten aufgeführte Optionen in Erwägung ziehen, um den Datenzugriff ausgehend von Ihrer Azure-SSIS IR je nach Ihrem jeweiligen Szenario zu sichern:

    • Wenn Ihre Datenquelle lokal ist, können Sie, nachdem Sie ein virtuelles Netzwerk mit Ihrem lokalen Netzwerk verbunden haben und Ihre Azure-SSIS IR mit dem Subnetz des virtuellen Netzwerks verknüpft haben, den privaten IP-Adressbereich dieses Subnetzes zur Positivliste der Firewall für Ihre Datenquelle hinzufügen.

    • Wenn es sich bei der Datenquelle um einen Azure-Dienst handelt, der VNET-Dienstendpunkte unterstützt, können Sie in Ihrem virtuellen Netzwerk einen VNET-Dienstendpunkt konfigurieren und Ihre Azure-SSIS IR mit dem betreffenden Subnetz verknüpfen. Anschließend können Sie der Firewall für die Datenquelle eine VNET-Regel für dieses Subnetz hinzufügen.

    • Wenn Ihre Datenquelle ein Nicht-Azure-Clouddienst ist, können Sie eine UDR verwenden, um den ausgehenden Datenverkehr von Ihrem Azure-SSIS IR über eine NVA oder eine Azure Firewall zu seiner statischen öffentlichen IP-Adresse zu leiten. Anschließend können Sie die statische öffentliche IP-Adresse Ihrer NVA/Azure Firewall zur Positivliste der Firewall für Ihre Datenquelle hinzufügen.

    • Wenn keine der oben genannten Optionen Ihre Anforderungen erfüllt, können Sie die Konfiguration einer selbstgehosteten IR als Proxy für Ihre Azure-SSIS IR in Erwägung ziehen. Anschließend können Sie die statische öffentliche IP-Adresse des Rechners, der Ihre selbstgehostete IR hostet, der Zulassungsliste der Firewall für Ihre Datenquelle hinzufügen.

  • Warum muss ich zwei statische öffentliche Adressen angeben, wenn ich meine eigenen Adressen für die Azure-SSIS IR verwenden möchte?

    Die Azure-SSIS IR wird regelmäßig automatisch aktualisiert. Beim Upgrade werden neue Knoten erstellt und alte werden gelöscht. Um Ausfallzeiten zu vermeiden, werden die alten Knoten jedoch erst dann gelöscht, wenn die neuen einsatzbereit sind. Daher kann Ihre erste statische öffentliche IP-Adresse, die von den alten Knoten verwendet wird, nicht sofort freigegeben werden, sodass eine zweite statische öffentliche IP-Adresse zum Erstellen der neuen Knoten benötigt wird.

  • Ich verwende meine eigenen statischen öffentlichen IP-Adressen für die Azure-SSIS IR. Warum kann die IR immer noch nicht auf meine Datenquellen zugreifen?

    Vergewissern Sie sich, dass beide statischen öffentlichen IP-Adressen der Zulassungsliste der Firewall für Ihre Datenquellen hinzugefügt wurden. Bei jedem Upgrade Ihrer Azure-SSIS IR wird die statische öffentliche IP-Adresse zwischen den beiden von Ihnen bereitgestellten Adressen gewechselt. Wenn Sie nur eines davon zur Zulassungsliste hinzufügen, wird der Datenzugriff Ihres Azure-SSIS IR nach dem Upgrade gestört.

    Wenn es sich bei Ihrer Datenquelle um einen Azure-Dienst handelt, überprüfen Sie, ob sie mit VNET-Dienstendpunkten konfiguriert wurde. Wenn dies der Fall ist, wird der Datenverkehr von Azure-SSIS IR zu Ihrer Datenquelle auf die von Azure-Diensten verwalteten privaten IP-Adressen umgeleitet. Das Hinzufügen eigener statischer öffentlicher IP-Adressen zur Firewall-Freigabeliste für Ihre Datenquelle hat dann keine Wirkung.

Weitere Informationen zur Azure-SSIS IR finden Sie in den folgenden Artikeln:

  • Azure-SSIS IR. Dieser Artikel enthält allgemeine konzeptionelle Informationen zu IRs, einschließlich der Azure-SSIS IR.
  • Tutorial: Bereitstellen von SSIS-Paketen in Azure. Dieses Tutorial enthält Schritt-für-Schritt-Anweisungen zum Erstellen einer Azure-SSIS IR. Es verwendet den Azure SQL-Datenbank-Server, um SSISDB zu hosten.
  • Erstellen Sie eine Azure-SSIS IR. Dieser Artikel baut auf dem Tutorial auf. Er enthält Anweisungen zum Verwenden eines Azure SQL-Datenbank-Servers, der mit einem Endpunkt eines virtuellen Netzwerks/einer IP-Firewallregel/einem privaten Endpunkt oder einer Azure SQL Managed Instance-Instanz konfiguriert ist, die mit einem virtuellen Netzwerk zum Hosten von SSISDB verknüpft wird. Außerdem wird veranschaulicht, wie Sie Azure-SSIS IR mit einem virtuellen Netzwerk verknüpfen.
  • Überwachung von Azure-SSIS-IR In diesem Artikel erfahren Sie, wie Sie Informationen zur Azure-SSIS IR abrufen und verstehen.
  • Verwalten einer Azure-SSIS IR. In diesem Artikel wird beschrieben, wie Sie die Azure-SSIS IR beenden, starten oder löschen. Es wird zudem gezeigt, wie Sie Ihre Azure-SSIS Integration Runtime aufskalieren, indem Sie weitere Knoten hinzufügen.