Standardowa metoda iniekcji sieci wirtualnej

DOTYCZY: Azure Data Factory Azure Synapse Analytics

Napiwek

Wypróbuj usługę Data Factory w usłudze Microsoft Fabric — rozwiązanie analityczne typu all-in-one dla przedsiębiorstw. Usługa Microsoft Fabric obejmuje wszystko, od przenoszenia danych do nauki o danych, analizy w czasie rzeczywistym, analizy biznesowej i raportowania. Dowiedz się, jak bezpłatnie rozpocząć nową wersję próbną !

W przypadku korzystania z usług SQL Server Integration Services (SSIS) w usłudze Azure Data Factory (ADF) lub potokach Synpase istnieją dwie metody dołączania środowiska Azure-SSIS Integration Runtime (IR) do sieci wirtualnej: standardowa i ekspresowa. Jeśli używasz standardowej metody, musisz skonfigurować sieć wirtualną tak, aby spełniała następujące wymagania:

• Upewnij się, że microsoft.Batch jest zarejestrowanym dostawcą zasobów w subskrypcji platformy Azure, która ma sieć wirtualną dla środowiska Azure-SSIS IR do przyłączenia. Aby uzyskać szczegółowe instrukcje, zobacz sekcję Rejestrowanie usługi Azure Batch jako dostawcy zasobów.

• Upewnij się, że użytkownik tworzący środowisko Azure-SSIS IR ma przyznane niezbędne uprawnienia kontroli dostępu opartej na rolach (RBAC), aby dołączyć do sieci wirtualnej/podsieci. Aby uzyskać więcej informacji, zobacz sekcję Wybieranie uprawnień sieci wirtualnej poniżej.

• Wybierz odpowiednią podsieć w sieci wirtualnej, aby dołączyć środowisko Azure-SSIS IR. Aby uzyskać więcej informacji, zobacz sekcję Wybierz podsieć poniżej.

W zależności od konkretnego scenariusza można opcjonalnie skonfigurować następujące elementy:

• Jeśli chcesz przenieść własne statyczne publiczne adresy IP (BYOIP) dla ruchu wychodzącego środowiska Azure-SSIS IR, zobacz sekcję Konfigurowanie statycznych publicznych adresów IP poniżej.

• Jeśli chcesz użyć własnego serwera systemu nazw domen (DNS) w sieci wirtualnej, zobacz sekcję Konfigurowanie niestandardowego serwera DNS poniżej.

• Jeśli chcesz użyć sieciowej grupy zabezpieczeń w celu ograniczenia ruchu przychodzącego/wychodzącego w podsieci, zobacz sekcję Konfigurowanie sieciowej grupy zabezpieczeń poniżej.

• Jeśli chcesz użyć tras zdefiniowanych przez użytkownika do inspekcji/inspekcji ruchu wychodzącego, zobacz sekcję Konfigurowanie tras zdefiniowanych przez użytkownika poniżej.

• Upewnij się, że grupa zasobów sieci wirtualnej (lub grupa zasobów publicznych adresów IP, jeśli korzystasz z własnych publicznych adresów IP), może utworzyć i usunąć niektóre zasoby sieciowe platformy Azure. Aby uzyskać więcej informacji, zobacz Konfigurowanie odpowiedniej grupy zasobów.

• Jeśli dostosujesz środowisko Azure-SSIS IR zgodnie z opisem w artykule Konfiguracja niestandardowa dla środowiska Azure-SSIS IR , nasz proces wewnętrzny do zarządzania jego węzłami będzie używać prywatnych adresów IP ze wstępnie zdefiniowanego zakresu od 172.16.0.0 do 172.31.255.255. W związku z tym upewnij się, że zakresy prywatnych adresów IP sieci wirtualnych i lokalnych nie zderzają się z tym zakresem.

Na tym diagramie przedstawiono wymagane połączenia środowiska Azure-SSIS IR:

Wybieranie uprawnień sieci wirtualnej

Aby włączyć standardową iniekcję sieci wirtualnej, użytkownik tworzący środowisko Azure-SSIS IR musi mieć przyznane niezbędne uprawnienia RBAC, aby dołączyć do sieci wirtualnej/podsieci.

• Jeśli dołączasz środowisko Azure-SSIS IR do sieci wirtualnej usługi Azure Resource Manager, masz dwie opcje:

  • Użyj wbudowanej roli Współautor sieci. Ta rola jest dostarczana z uprawnieniem Microsoft.Network/* , które ma znacznie większy zakres niż jest to konieczne.

  • Utwórz rolę niestandardową zawierającą tylko niezbędne uprawnienie Microsoft.Network/virtualNetworks/*/join/action . Jeśli chcesz również przenieść własne statyczne publiczne adresy IP dla środowiska Azure-SSIS IR podczas dołączania go do sieci wirtualnej usługi Azure Resource Manager, dołącz również uprawnienie Microsoft.Network/publicIPAddresses/*/join/action w roli.

  • Aby uzyskać szczegółowe instrukcje, zobacz sekcję Udzielanie uprawnień sieci wirtualnej.

• Jeśli dołączasz środowisko Azure-SSIS IR do klasycznej sieci wirtualnej, zalecamy użycie wbudowanej roli współautora klasycznej maszyny wirtualnej. W przeciwnym razie musisz utworzyć rolę niestandardową, która zawiera uprawnienie do dołączania do sieci wirtualnej. Należy również przypisać usługę MicrosoftAzureBatch do tej wbudowanej/niestandardowej roli.

Wybieranie podsieci

Aby włączyć standardową iniekcję sieci wirtualnej, należy wybrać odpowiednią podsieć dla środowiska Azure-SSIS IR, aby dołączyć:

• Nie wybieraj podsieci GatewaySubnet, ponieważ jest ona przeznaczona dla bram sieci wirtualnej.

• Upewnij się, że wybrana podsieć ma dostępne adresy IP przez co najmniej dwa razy więcej niż numer węzła środowiska Azure-SSIS IR. Są one wymagane, aby uniknąć zakłóceń podczas wdrażania poprawek/uaktualnień dla środowiska Azure-SSIS IR. Platforma Azure rezerwuje również niektóre adresy IP, których nie można używać w każdej podsieci. Pierwsze i ostatnie adresy IP są zarezerwowane na potrzeby zgodności protokołu, podczas gdy trzy kolejne adresy są zarezerwowane dla usług platformy Azure. Aby uzyskać więcej informacji, zobacz sekcję Ograniczenia adresów IP podsieci .

• Nie używaj podsieci, która jest zajęta wyłącznie przez inne usługi platformy Azure (na przykład Azure SQL Managed Instance, App Service itd.).

Konfigurowanie statycznych publicznych adresów IP

Jeśli chcesz przenieść własne statyczne publiczne adresy IP dla ruchu wychodzącego środowiska Azure-SSIS IR podczas dołączania do sieci wirtualnej, aby umożliwić im dostęp do zapór, upewnij się, że spełniają one następujące wymagania:

• Należy podać dokładnie dwa nieużywane te, które nie są jeszcze skojarzone z innymi zasobami platformy Azure. Dodatkowy będzie używany podczas okresowego uaktualniania środowiska Azure-SSIS IR. Należy pamiętać, że jeden publiczny adres IP nie może być współużytkowany między aktywnymi adresami IP usługi Azure-SSIS.

• Oba powinny być statyczne typu standardowego. Aby uzyskać więcej informacji, zobacz sekcję Jednostki SKU publicznego adresu IP.

• Oba powinny mieć nazwę DNS. Jeśli podczas tworzenia nie podano nazwy DNS, możesz to zrobić w witrynie Azure Portal.

  

• Sieci wirtualne powinny znajdować się w tej samej subskrypcji i w tym samym regionie.

Konfigurowanie niestandardowego serwera DNS

Jeśli chcesz użyć własnego serwera DNS w sieci wirtualnej, aby rozpoznać prywatne nazwy hostów, upewnij się, że może również rozpoznawać globalne nazwy hostów platformy Azure (na przykład usługę Azure Blob Storage o nazwie <your storage account>.blob.core.windows.).

Zalecamy skonfigurowanie własnego serwera DNS do przekazywania nierozwiązanych żądań DNS do adresu IP rekursywnych rozpoznawania nazw platformy Azure (168.63.129.16).

Aby uzyskać więcej informacji, zobacz sekcję rozpoznawania nazw serwera DNS.

Uwaga

Użyj w pełni kwalifikowanej nazwy domeny (FQDN) dla nazwy hosta prywatnego (na przykład użyj <your_private_server>.contoso.com zamiast <your_private_server>nazwy ). Alternatywnie możesz użyć standardowej konfiguracji niestandardowej w środowisku Azure-SSIS IR, aby automatycznie dołączyć własny sufiks DNS (na przykład contoso.com) do dowolnej niekwalifikowanej nazwy domeny z pojedynczą etykietą i przekształcić ją w nazwę FQDN przed użyciem jej w zapytaniach DNS, zobacz sekcję Przykłady konfiguracji niestandardowej w warstwie Standardowa.

Konfigurowanie sieciowej grupy zabezpieczeń

Jeśli chcesz użyć sieciowej grupy zabezpieczeń w podsieci przyłączonej przez środowisko Azure-SSIS IR, zezwól na następujący ruch przychodzący i wychodzący:

Kierunek	Protokół transportowy	Źródło	Porty źródłowe	Element docelowy	Porty docelowe	Komentarze
Przychodzący	TCP	BatchNodeManagement	*	Sieć wirtualna	29876, 29877 (jeśli przyłączysz środowisko SSIS IR do sieci wirtualnej usługi Azure Resource Manager) 10100, 20100, 30100 (jeśli przyłączysz środowisko SSIS IR do klasycznej sieci wirtualnej)	Usługa Data Factory używa tych portów do komunikowania się z węzłami środowiska Azure-SSIS IR w sieci wirtualnej. Niezależnie od tego, czy tworzysz sieciową grupę zabezpieczeń w podsieci, usługa Data Factory zawsze konfiguruje sieciową grupę zabezpieczeń na karcie interfejsu sieciowego dołączonej do maszyn wirtualnych hostujących środowisko Azure-SSIS IR. Tylko ruch przychodzący z adresów IP usługi Data Factory na określonych portach jest dozwolony przez sieciową grupę zabezpieczeń na poziomie karty sieciowej. Nawet jeśli otworzysz te porty do ruchu internetowego na poziomie podsieci, ruch z adresów IP, które nie są adresami IP usługi Data Factory, nadal jest blokowany na poziomie karty sieciowej.
Przychodzący	TCP	CorpNetSaw	*	Sieć wirtualna	3389	(Opcjonalnie) Wymagane tylko wtedy, gdy inżynier pomocy technicznej firmy Microsoft prosi o otwarcie portu 3389 na potrzeby zaawansowanego rozwiązywania problemów i można je zamknąć bezpośrednio po rozwiązaniu problemów. Tag usługi CorpNetSaw zezwala na dostęp tylko do maszyn stacji roboczej bezpiecznego dostępu (SAW) w sieci firmowej firmy Microsoft w celu uzyskania dostępu do środowiska Azure-SSIS IR za pośrednictwem protokołu RDP (Remote Desktop Protocol). Nie można wybrać tego tagu usługi w witrynie Azure Portal i jest dostępny tylko za pośrednictwem programu Azure PowerShell/interfejsu wiersza polecenia. W sieciowej grupie zabezpieczeń na poziomie karty sieciowej port 3389 jest domyślnie otwarty, ale możesz kontrolować ją za pomocą sieciowej grupy zabezpieczeń na poziomie podsieci, podczas gdy ruch wychodzący na nim jest domyślnie niedozwolony w węzłach środowiska Azure-SSIS IR przy użyciu reguły zapory systemu Windows.

Kierunek	Protokół transportowy	Źródło	Porty źródłowe	Element docelowy	Porty docelowe	Komentarze
Wychodzący	TCP	Sieć wirtualna	*	AzureCloud	443	Środowisko Azure-SSIS IR jest wymagane do uzyskiwania dostępu do usług platformy Azure, takich jak Azure Storage i Azure Event Hubs.
Wychodzący	TCP	Sieć wirtualna	*	Internet	80	(Opcjonalnie) Środowisko Azure-SSIS IR używa tego portu do pobierania listy odwołania certyfikatów (CRL) z Internetu. Jeśli zablokujesz ten ruch, może wystąpić spadek wydajności podczas uruchamiania środowiska Azure-SSIS IR i utracisz możliwość sprawdzania list CRL podczas korzystania z certyfikatów, co nie jest zalecane z punktu widzenia zabezpieczeń. Jeśli chcesz zawęzić lokalizacje docelowe do określonych nazw FQDN, zobacz sekcję Konfigurowanie tras zdefiniowanych przez użytkownika poniżej
Wychodzący	TCP	Sieć wirtualna	*	Sql/VirtualNetwork	1433, 11000-11999	(Opcjonalnie) Wymagane tylko w przypadku używania serwera/wystąpienia zarządzanego usługi Azure SQL Database do hostowania katalogu usług SSIS (SSISDB). Jeśli serwer/wystąpienie zarządzane usługi Azure SQL Database jest skonfigurowany z publicznym punktem końcowym/punktem końcowym usługi sieci wirtualnej, użyj tagu usługi Sql jako miejsca docelowego. Jeśli serwer/wystąpienie zarządzane usługi Azure SQL Database jest skonfigurowane z prywatnym punktem końcowym, użyj tagu usługi VirtualNetwork jako miejsca docelowego. Jeśli zasady połączenia serwera są ustawione na serwer proxy zamiast przekierowania, wymagany jest tylko port 1433 .
Wychodzący	TCP	Sieć wirtualna	*	Storage/VirtualNetwork	443	(Opcjonalnie) Wymagane tylko wtedy, gdy używasz kontenera obiektów blob usługi Azure Storage do przechowywania standardowych niestandardowych skryptów/plików konfiguracji. Jeśli usługa Azure Storage jest skonfigurowana z publicznym punktem końcowym/punktem końcowym usługi sieci wirtualnej, użyj tagu usługi Storage jako miejsca docelowego. Jeśli usługa Azure Storage jest skonfigurowana z prywatnym punktem końcowym, użyj tagu usługi VirtualNetwork jako miejsca docelowego.
Wychodzący	TCP	Sieć wirtualna	*	Storage/VirtualNetwork	445	(Opcjonalnie) Wymagane tylko w przypadku konieczności uzyskania dostępu do usługi Azure Files. Jeśli usługa Azure Storage jest skonfigurowana z publicznym punktem końcowym/punktem końcowym usługi sieci wirtualnej, użyj tagu usługi Storage jako miejsca docelowego. Jeśli usługa Azure Storage jest skonfigurowana z prywatnym punktem końcowym, użyj tagu usługi VirtualNetwork jako miejsca docelowego.

Konfigurowanie tras zdefiniowanych przez użytkownika

Jeśli chcesz przeprowadzić inspekcję/inspekcję ruchu wychodzącego z środowiska Azure-SSIS IR, możesz użyć tras zdefiniowanych przez użytkownika (UDR), aby przekierować go do lokalnego urządzenia zapory za pośrednictwem wymuszonego tunelowania usługi Azure ExpressRoute, który anonsuje trasę protokołu BGP (Border Gateway Protocol) 0.0.0.0/0 do sieci wirtualnej, do wirtualnego urządzenia sieciowego (NVA) skonfigurowanego jako zapora lub do usługi Azure Firewall.

Aby to działało, należy upewnić się, że:

• Ruch między usługą zarządzania usługą Azure Batch i środowiskiem Azure-SSIS IR nie powinien być kierowany do urządzenia/usługi zapory.

• Urządzenie/usługa zapory powinny zezwalać na ruch wychodzący wymagany przez środowisko Azure-SSIS IR.

Jeśli ruch między usługą zarządzania usługą Azure Batch i środowiskiem Azure-SSIS IR jest kierowany do urządzenia/usługi zapory, zostanie przerwany z powodu routingu asymetrycznego. Trasy zdefiniowane przez użytkownika muszą być zdefiniowane dla tego ruchu, tak aby mogły przechodzić przez te same trasy, w których się znalazł. Trasy zdefiniowane przez użytkownika można skonfigurować tak, aby kierować ruch między usługą zarządzania usługi Azure Batch i środowiskiem Azure-SSIS IR przy użyciu typu następnego przeskoku jako Internet.

Jeśli na przykład środowisko Azure-SSIS IR znajduje się w Południowej Wielkiej Brytanii i chcesz sprawdzić ruch wychodzący przy użyciu usługi Azure Firewall, możesz najpierw uzyskać zakresy adresów IP dla tagu usługi BatchNodeManagement.UKSouth z linku pobierania zakresu adresów IP tagu usługi lub interfejsu API odnajdywania tagów usługi. Następnie można skonfigurować następujące trasy zdefiniowane przez użytkownika dla odpowiednich tras zakresu adresów IP z typem następnego przeskoku jako Internet i 0.0.0.0/0 z typem następnego przeskoku jako Urządzenie wirtualne.

Uwaga

Takie podejście wiąże się z dodatkowymi kosztami konserwacji, ponieważ należy regularnie sprawdzać odpowiednie zakresy adresów IP i dodawać trasy zdefiniowane przez użytkownika dla nowych, aby uniknąć zerwania środowiska Azure-SSIS IR. Zalecamy sprawdzenie ich co miesiąc, ponieważ po wyświetleniu nowego zakresu adresów IP dla odpowiedniego tagu usługi wprowadzenie nowego miesiąca potrwa kolejny miesiąc.

Możesz uruchomić następujący skrypt programu PowerShell, aby dodać trasy zdefiniowane przez użytkownika dla usługi zarządzania usługą Azure Batch:

$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."
}

Zgodnie z naszymi wskazówkami w sekcji Konfigurowanie sieciowej grupy zabezpieczeń powyżej należy zaimplementować podobne reguły na urządzeniu/usłudze zapory, aby zezwolić na ruch wychodzący z środowiska Azure-SSIS IR:

• Jeśli używasz usługi Azure Firewall:

  • Musisz otworzyć port 443 dla ruchu wychodzącego TCP z tagiem usługi AzureCloud jako miejscem docelowym.

  • Jeśli używasz serwera/wystąpienia zarządzanego usługi Azure SQL Database do hostowania bazy danych SSISDB, musisz otworzyć porty 1433, 11000-11999 dla wychodzącego ruchu TCP z tagiem usługi Sql/VirtualNetwork jako miejscem docelowym.

  • Jeśli używasz kontenera obiektów blob usługi Azure Storage do przechowywania standardowego niestandardowego skryptu/plików konfiguracji, musisz otworzyć port 443 dla ruchu wychodzącego TCP z tagiem usługi Storage/VirtualNetwork jako lokalizacją docelową.

  • Jeśli chcesz uzyskać dostęp do usługi Azure Files, musisz otworzyć port 445 dla ruchu wychodzącego TCP z tagiem usługi Storage/VirtualNetwork jako lokalizacją docelową.

• Jeśli używasz innego urządzenia/usługi zapory:

  • Musisz otworzyć port 443 dla ruchu wychodzącego TCP z numerem 0.0.0.0/0 lub następującymi nazwami FQDN specyficznymi dla środowiska platformy Azure jako miejscem docelowym.

    Środowisko platformy Azure	Nazwa FQDN
    Publiczna platforma Azure	Azure Data Factory (zarządzanie) *.frontend.clouddatahub.net Azure Storage (zarządzanie) *.blob.core.windows.net *.table.core.windows.net Azure Container Registry (konfiguracja niestandardowa) *.azurecr.io Event Hubs (rejestrowanie) *.servicebus.windows.net Usługa rejestrowania firmy Microsoft (użycie wewnętrzne) gcs.prod.monitoring.core.windows.net prod.warmpath.msftcloudes.com azurewatsonanalysis-prod.core.windows.net
    Azure Government	Azure Data Factory (zarządzanie) *.frontend.datamovement.azure.us Azure Storage (zarządzanie) *.blob.core.usgovcloudapi.net *.table.core.usgovcloudapi.net Azure Container Registry (konfiguracja niestandardowa) *.azurecr.us Event Hubs (rejestrowanie) *.servicebus.usgovcloudapi.net Usługa rejestrowania firmy Microsoft (użycie wewnętrzne) fairfax.warmpath.usgovcloudapi.net azurewatsonanalysis.usgovcloudapp.net
    Platforma Microsoft Azure obsługiwana przez firmę 21Vianet	Azure Data Factory (zarządzanie) *.frontend.datamovement.azure.cn Azure Storage (zarządzanie) *.blob.core.chinacloudapi.cn *.table.core.chinacloudapi.cn Azure Container Registry (konfiguracja niestandardowa) *.azurecr.cn Event Hubs (rejestrowanie) *.servicebus.chinacloudapi.cn Usługa rejestrowania firmy Microsoft (użycie wewnętrzne) mooncake.warmpath.chinacloudapi.cn azurewatsonanalysis.chinacloudapp.cn

  • Jeśli używasz serwera/wystąpienia zarządzanego usługi Azure SQL Database do hostowania bazy danych SSISDB, musisz otworzyć porty 1433, 11000-11999 dla ruchu wychodzącego TCP z 0.0.0.0/0 lub nazwą FQDN serwera usługi Azure SQL Database/wystąpienia zarządzanego jako miejsce docelowe.

  • Jeśli używasz kontenera obiektów blob usługi Azure Storage do przechowywania standardowego niestandardowego skryptu konfiguracji/plików, musisz otworzyć port 443 dla ruchu wychodzącego TCP z 0.0.0.0/0 lub nazwą FQDN usługi Azure Blob Storage jako miejscem docelowym.

  • Jeśli potrzebujesz dostępu do usługi Azure Files, musisz otworzyć port 445 dla ruchu wychodzącego TCP z 0.0.0.0/0 lub nazwą FQDN usługi Azure Files jako lokalizacją docelową.

• Jeśli skonfigurujesz punkt końcowy usługi sieci wirtualnej dla usługi Azure Storage/Container Registry/Event Hubs/SQL, włączając odpowiednio microsoft.Storage/Microsoft.ContainerRegistry/Microsoft.EventHub/Microsoft.Sql zasobów, odpowiednio w podsieci, cały ruch między środowiskiem Azure-SSIS IR i tymi usługami w tych samych/sparowanych regionach zostanie przekierowany do sieci szkieletowej platformy Azure zamiast urządzenia/usługi zapory.

• Należy otworzyć port 80 dla ruchu wychodzącego TCP z następującymi witrynami pobierania listy odwołania certyfikatów (CRL) jako miejsca docelowego:

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

  Jeśli używasz certyfikatów z różnymi listami CRL, należy również dodać ich witryny pobierania jako miejsce docelowe. Aby uzyskać więcej informacji, zobacz artykuł Lista odwołania certyfikatów.

  Jeśli zablokujesz ten ruch, może wystąpić spadek wydajności podczas uruchamiania środowiska Azure-SSIS IR i utracisz możliwość sprawdzania list CRL podczas korzystania z certyfikatów, co nie jest zalecane z punktu widzenia zabezpieczeń.

Jeśli nie potrzebujesz inspekcji/inspekcji ruchu wychodzącego z środowiska Azure-SSIS IR, możesz użyć tras zdefiniowanych przez użytkownika, aby wymusić cały ruch z typem następnego przeskoku jako Internet:

• W przypadku korzystania z usługi Azure ExpressRoute możesz skonfigurować trasę zdefiniowaną przez użytkownika dla trasy 0.0.0.0/0 w podsieci z typem następnego przeskoku jako Internet.

• W przypadku korzystania z urządzenia WUS można zmodyfikować istniejącą trasę zdefiniowaną przez użytkownika dla trasy 0.0.0.0/0 w podsieci, aby przełączyć typ następnego przeskoku z urządzenia wirtualnego do Internetu.

Uwaga

Konfigurowanie tras zdefiniowanych przez użytkownika z typem następnego przeskoku, ponieważ Internet nie oznacza, że cały ruch będzie przechodził przez Internet. Jeśli adres docelowy należy do jednej z usług platformy Azure, platforma Azure będzie kierować cały ruch do tego adresu za pośrednictwem sieci szkieletowej platformy Azure zamiast Internetu.

Konfigurowanie odpowiedniej grupy zasobów

Aby włączyć standardową iniekcję sieci wirtualnej, środowisko Azure-SSIS IR musi utworzyć pewne zasoby sieciowe w tej samej grupie zasobów co sieć wirtualna. Te zasoby obejmują:

• Moduł równoważenia obciążenia platformy Azure o nazwie <Guid-azurebatch-cloudserviceloadbalancer>.
• Publiczny adres IP platformy Azure o nazwie Guid-azurebatch-cloudservicepublicip>.<
• Sieciowa grupa zabezpieczeń o nazwie Guid-azurebatch-cloudservicenetworksecuritygroup>.<

Uwaga

Teraz możesz przenieść własne statyczne publiczne adresy IP dla środowiska Azure-SSIS IR. W tym scenariuszu utworzymy moduł równoważenia obciążenia platformy Azure i sieciową grupę zabezpieczeń w tej samej grupie zasobów co statyczne publiczne adresy IP zamiast sieci wirtualnej.

Te zasoby zostaną utworzone podczas uruchamiania środowiska Azure-SSIS IR. Zostaną one usunięte po zatrzymaniu środowiska Azure-SSIS IR. Jeśli wprowadzisz własne statyczne publiczne adresy IP dla środowiska Azure-SSIS IR, nie zostaną one usunięte po zatrzymaniu środowiska Azure-SSIS IR. Aby uniknąć blokowania środowiska Azure-SSIS IR przed zatrzymywaniem, nie używaj tych zasobów do innych celów.

Upewnij się, że nie masz blokady zasobów w grupie zasobów/subskrypcji, do której należy sieć wirtualna/statyczne publiczne adresy IP. Jeśli skonfigurujesz blokadę tylko do odczytu/usuń, uruchomienie i zatrzymanie środowiska Azure-SSIS IR zakończy się niepowodzeniem lub przestanie odpowiadać.

Upewnij się, że nie masz przypisania usługi Azure Policy, które uniemożliwia utworzenie następujących zasobów w grupie zasobów/subskrypcji, do której należy sieć wirtualna/statyczne publiczne adresy IP:

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

Upewnij się, że limit przydziału zasobów dla subskrypcji jest wystarczający dla tych zasobów. W szczególności w przypadku każdego środowiska Azure-SSIS IR utworzonego w sieci wirtualnej należy zarezerwować dwukrotnie większą liczbę tych zasobów, ponieważ dodatkowe zasoby będą używane podczas okresowego uaktualniania środowiska Azure-SSIS IR.

Często zadawane pytania

• Jak mogę chronić publiczny adres IP uwidoczniony w środowisku Azure-SSIS IR na potrzeby połączenia przychodzącego? Czy można usunąć publiczny adres IP?

  W tej chwili publiczny adres IP zostanie automatycznie utworzony, gdy środowisko Azure-SSIS IR dołączy do sieci wirtualnej. Mamy sieciową grupę zabezpieczeń na poziomie karty sieciowej, aby zezwolić tylko usłudze zarządzania usługi Azure Batch na połączenie przychodzące z środowiskiem Azure-SSIS IR. Można również określić sieciową grupę zabezpieczeń na poziomie podsieci na potrzeby ochrony ruchu przychodzącego.

  Jeśli nie chcesz uwidocznić żadnego publicznego adresu IP, rozważ skonfigurowanie własnego środowiska IR jako serwera proxy dla środowiska Azure-SSIS IR zamiast dołączania środowiska Azure-SSIS IR do sieci wirtualnej.

• Czy mogę dodać publiczny adres IP środowiska Azure-SSIS IR do listy dozwolonych zapory dla moich źródeł danych?

  Teraz możesz przenieść własne statyczne publiczne adresy IP dla środowiska Azure-SSIS IR. W takim przypadku możesz dodać adresy IP do listy dozwolonych zapory dla źródeł danych. Alternatywnie możesz również rozważyć inne opcje poniżej, aby zabezpieczyć dostęp do danych z poziomu środowiska Azure-SSIS IR w zależności od scenariusza:

  • Jeśli źródło danych znajduje się lokalnie, po połączeniu sieci wirtualnej z siecią lokalną i dołączeniu środowiska Azure-SSIS IR do podsieci sieci wirtualnej możesz dodać zakres prywatnych adresów IP tej podsieci do listy dozwolonych zapory dla źródła danych.

  • Jeśli źródłem danych jest usługa platformy Azure, która obsługuje punkty końcowe usługi sieci wirtualnej, możesz skonfigurować punkt końcowy usługi sieci wirtualnej w podsieci sieci wirtualnej i dołączyć środowisko Azure-SSIS IR do tej podsieci. Następnie możesz dodać regułę sieci wirtualnej z tej podsieci do zapory dla źródła danych.

  • Jeśli źródłem danych jest usługa w chmurze spoza platformy Azure, możesz użyć trasy zdefiniowanej przez użytkownika do kierowania ruchu wychodzącego z środowiska Azure-SSIS IR do statycznego publicznego adresu IP za pośrednictwem urządzenia WUS/usługi Azure Firewall. Następnie możesz dodać statyczny publiczny adres IP urządzenia WUS/azure Firewall do listy dozwolonych zapory dla źródła danych.

  • Jeśli żadna z powyższych opcji nie spełnia Twoich potrzeb, rozważ skonfigurowanie własnego środowiska IR jako serwera proxy dla środowiska Azure-SSIS IR. Następnie możesz dodać statyczny publiczny adres IP maszyny, która hostuje własne środowisko IR, do listy dozwolonych zapory dla źródła danych.

• Dlaczego muszę podać dwa statyczne adresy publiczne, jeśli chcę korzystać z własnego środowiska Azure-SSIS IR?

  Środowisko Azure-SSIS IR jest regularnie aktualizowane automatycznie. Nowe węzły są tworzone podczas uaktualniania, a stare zostaną usunięte. Jednak aby uniknąć przestojów, stare węzły nie zostaną usunięte, dopóki nowe nie będą gotowe. W związku z tym pierwszy statyczny publiczny adres IP używany przez stare węzły nie może zostać natychmiast wydany i potrzebujemy drugiego statycznego publicznego adresu IP do utworzenia nowych węzłów.

• Mam własne statyczne publiczne adresy IP dla środowiska Azure-SSIS IR, ale dlaczego nadal nie mogę uzyskać dostępu do moich źródeł danych?

  Upewnij się, że oba statyczne publiczne adresy IP są dodawane do listy dozwolonych zapory dla źródeł danych. Za każdym razem, gdy środowisko Azure-SSIS IR jest uaktualniane, jego statyczny publiczny adres IP jest przełączany między tymi dwoma wprowadzonymi przez Ciebie. Jeśli do listy dozwolonych zostanie dodany tylko jeden z nich, dostęp do danych dla środowiska Azure-SSIS IR zostanie przerwany po uaktualnieniu.

  Jeśli źródło danych jest usługą platformy Azure, sprawdź, czy skonfigurowano ją za pomocą punktów końcowych usługi sieci wirtualnej. Jeśli tak jest, ruch z środowiska Azure-SSIS IR do źródła danych zmieni się na użycie prywatnych adresów IP zarządzanych przez usługi platformy Azure i dodanie własnych statycznych publicznych adresów IP do listy dozwolonych zapory dla źródła danych nie zostanie zastosowane.

Powiązana zawartość

• Dołączanie środowiska Azure-SSIS IR do sieci wirtualnej za pośrednictwem interfejsu użytkownika usługi ADF
• Dołączanie środowiska Azure-SSIS IR do sieci wirtualnej za pośrednictwem programu Azure PowerShell

Aby uzyskać więcej informacji na temat środowiska Azure-SSIS IR, zobacz następujące artykuły:

• Azure-SSIS IR. Ten artykuł zawiera ogólne informacje koncepcyjne dotyczące adresów IP, w tym środowiska Azure-SSIS IR.
• Samouczek: wdrażanie pakietów usług SSIS na platformie Azure. Ten samouczek zawiera instrukcje krok po kroku dotyczące tworzenia środowiska Azure-SSIS IR. Używa serwera usługi Azure SQL Database do hostowania bazy danych SSISDB.
• Tworzenie środowiska Azure-SSIS IR. Ten artykuł jest rozwijany w samouczku. Zawiera instrukcje dotyczące używania serwera usługi Azure SQL Database skonfigurowanego z punktem końcowym usługi sieci wirtualnej/regułą zapory IP/prywatnym punktem końcowym lub usługą Azure SQL Managed Instance przyłączającą sieć wirtualną do hostowania bazy danych SSISDB. Przedstawiono w nim sposób dołączania środowiska Azure-SSIS IR do sieci wirtualnej.
• Monitor an Azure-SSIS IR (Monitorowanie środowiska Azure-SSIS IR). W tym artykule przedstawiono, jak pobierać i interpretować informacje dotyczące środowiska Azure-SSIS IR.
• Manage an Azure-SSIS IR (Zarządzanie środowiskiem Azure-SSIS IR). W tym artykule przedstawiono sposób zatrzymywania, uruchamiania lub usuwania środowiska Azure-SSIS IR. Zawiera on również instrukcje skalowania środowiska Azure-SSIS IR w poziomie za pomocą dodawania węzłów.