Udostępnij za pośrednictwem

Migrowanie bramy aplikacja systemu Azure i zapory aplikacji internetowej z wersji 1 do wersji 2

  • Artykuł

Ogłosiliśmy wycofanie jednostki SKU usługi Application Gateway w wersji 1 (Standardowa i WAF) 28 kwietnia 2023 r. Jednostka SKU w wersji 1 zostanie wycofana 28 kwietnia 2026 r. Aby uzyskać więcej informacji, zobacz Migrowanie bram aplikacji z jednostki SKU w wersji 1 do jednostki SKU w wersji 28 kwietnia 2026 r.

aplikacja systemu Azure Gateway i Zapora aplikacji internetowej (WAF) v2 oferują teraz dodatkowe funkcje, takie jak skalowanie automatyczne, dostępność, nadmiarowość strefy, wyższa wydajność, szybsze operacje i ulepszona przepływność w porównaniu z wersją 1. Ponadto wszystkie nowe funkcje są wydawane dla jednostki SKU w wersji 2. Zdecydowanie zaleca się utworzenie planu migracji.

Bramy w wersji 1 nie są automatycznie uaktualniane do wersji 2. Skorzystaj z tego przewodnika migracji, aby ułatwić planowanie i przeprowadzanie migracji.

Migracja obejmuje dwa etapy:

  1. Migrowanie konfiguracji
  2. Migrowanie ruchu klienta

Ten artykuł pomaga przede wszystkim w migracji konfiguracji. Migracja ruchu klienta różni się w zależności od środowiska. Niektóre ogólne zalecenia zostały przedstawione w tym artykule.

Wymagania wstępne

  • Konto platformy Azure z aktywną subskrypcją. Utwórz konto bezpłatnie.
  • Istniejąca usługa Application Gateway w wersji 1 Standardowa.
  • Upewnij się, że masz najnowsze moduły programu PowerShell lub możesz użyć usługi Azure Cloud Shell w portalu.
  • Jeśli używasz programu PowerShell lokalnie, musisz też uruchomić polecenie Connect-AzAccount, aby utworzyć połączenie z platformą Azure.
  • Upewnij się, że nie ma istniejącej bramy aplikacji z podaną nazwą appGW v2 i nazwą grupy zasobów w subskrypcji w wersji 1. Spowoduje to ponowne zapisywanie istniejących zasobów.
  • Jeśli podano publiczny adres IP, upewnij się, że jest w stanie powodzenia. Jeśli nie podano nazwy AppGWResourceGroupName, upewnij się, że zasób publicznego adresu IP o nazwie AppGWV2Name-IP nie istnieje w grupie zasobów o nazwie AppGWResourceGroupName w subskrypcji V1.
  • W przypadku jednostki SKU w wersji 1 certyfikaty uwierzytelniania są wymagane do skonfigurowania połączeń TLS z serwerami zaplecza. Jednostka SKU w wersji 2 wymaga przekazania zaufanych certyfikatów głównych w tym samym celu. Wersja 1 zezwala na używanie certyfikatów z podpisem własnym jako certyfikatów uwierzytelniania, natomiast program V2 nakazuje generowanie i przekazywanie certyfikatu głównego z podpisem własnym, jeśli certyfikaty z podpisem własnym są używane w zapleczu.
  • Upewnij się, że żadna inna operacja nie jest planowana na bramie w wersji 1 ani żadnych skojarzonych zasobów podczas migracji.

Azure Cloud Shell

Na platforma Azure hostowane jest Azure Cloud Shell, interaktywne środowisko powłoki, z którego można korzystać w przeglądarce. Do pracy z usługami platformy Azure można używać programu Bash lub PowerShell w środowisku Cloud Shell. Aby uruchomić kod w tym artykule, możesz użyć wstępnie zainstalowanych poleceń usługi Cloud Shell bez konieczności instalowania niczego w środowisku lokalnym.

Aby uruchomić środowisko Azure Cloud Shell:

Opcja Przykład/link
Wybierz pozycję Wypróbuj w prawym górnym rogu bloku kodu lub polecenia. Wybranie pozycji Wypróbuj nie powoduje automatycznego skopiowania kodu lub polecenia do usługi Cloud Shell. Zrzut ekranu przedstawiający przykład narzędzia Try It dla usługi Azure Cloud Shell.
Przejdź do witryny https://shell.azure.com lub wybierz przycisk Uruchom Cloud Shell, aby otworzyć środowisko Cloud Shell w przeglądarce. Przycisk uruchamiania usługi Azure Cloud Shell.
Wybierz przycisk Cloud Shell na pasku menu w prawym górnym rogu witryny Azure Portal. Zrzut ekranu przedstawiający przycisk usługi Cloud Shell w witrynie Azure Portal

Aby użyć usługi Azure Cloud Shell:

  1. Uruchom usługę Cloud Shell.

  2. Wybierz przycisk Kopiuj w bloku kodu (lub bloku poleceń), aby skopiować kod lub polecenie.

  3. Wklej kod lub polecenie do sesji usługi Cloud Shell, wybierając Ctrl+Shift V w systemach Windows i Linux lub wybierając pozycję Cmd+Shift++V w systemie macOS.

  4. Wybierz Enter, aby uruchomić kod lub polecenie.

Uwaga

Do interakcji z platformą Azure zalecamy używanie modułu Azure Az w programie PowerShell. Zobacz Instalowanie programu Azure PowerShell, aby rozpocząć. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.

Ważne

Set-AzContext -Subscription <V1 application gateway SubscriptionId> Uruchom polecenie cmdlet za każdym razem przed uruchomieniem skryptu migracji. Jest to konieczne, aby ustawić aktywny kontekst platformy Azure na poprawną subskrypcję, ponieważ skrypt migracji może wyczyścić istniejącą grupę zasobów, jeśli nie istnieje w bieżącym kontekście subskrypcji. Nie jest to obowiązkowy krok dla wersji 1.0.11 i nowszej skryptu migracji.

Ważne

Dostępna jest teraz nowa stabilna wersja skryptu migracji w wersji 1.0.11, która zawiera ważne poprawki błędów i aktualizacje. Użyj tej wersji, aby uniknąć potencjalnych problemów.

Migracja konfiguracji

Skrypt programu Azure PowerShell jest udostępniany w tym dokumencie. Wykonuje następujące operacje, aby ułatwić konfigurację:

  • Tworzy nową bramę Standard_V2 lub WAF_V2 w określonej podsieci sieci wirtualnej.
  • Bezproblemowo kopiuje konfigurację skojarzona z bramą Standardowa lub zapory aplikacji internetowej w wersji 1 do nowo utworzonej bramy Standard_V2 lub WAF_V2.

Pobieranie skryptu

Skrypt migracji można pobrać z Galeria programu PowerShell. Dostępna jest nowa stabilna wersja (wersja 1.0.11) skryptu migracji, która obejmuje główne aktualizacje i poprawki błędów. Zaleca się używanie tej stabilnej wersji.

Korzystanie ze skryptu

Uwaga

Set-AzContext -Subscription <V1 application gateway SubscriptionId> Uruchom polecenie cmdlet za każdym razem przed uruchomieniem skryptu migracji. Jest to konieczne, aby ustawić aktywny kontekst platformy Azure na poprawną subskrypcję, ponieważ skrypt migracji może wyczyścić istniejącą grupę zasobów, jeśli nie istnieje w bieżącym kontekście subskrypcji. Nie jest to obowiązkowy krok dla wersji 1.0.11 i nowszej skryptu migracji.

Dostępne są dwie opcje w zależności od konfiguracji i preferencji lokalnego środowiska programu PowerShell:

  • Jeśli nie masz zainstalowanych modułów Azure Az lub nie masz nic przeciwko odinstalowaniu modułów Azure Az, najlepszym rozwiązaniem jest użycie Install-Script opcji uruchamiania skryptu.
  • Jeśli chcesz zachować moduły Azure Az, najlepszym rozwiązaniem jest pobranie skryptu i uruchomienie go bezpośrednio.

Aby ustalić, czy masz zainstalowane moduły Azure Az, uruchom polecenie Get-InstalledModule -Name az. Jeśli nie widzisz żadnych zainstalowanych modułów Az, możesz użyć Install-Script metody .

Aby użyć tej opcji, nie można zainstalować modułów Azure Az na komputerze. Jeśli są zainstalowane, następujące polecenie wyświetla błąd. Możesz odinstalować moduły Azure Az lub użyć drugiej opcji, aby pobrać skrypt ręcznie i uruchomić go.

Uruchom skrypt za pomocą następującego polecenia, aby uzyskać najnowszą wersję:

Install-Script -Name AzureAppGWMigration -Force

To polecenie instaluje również wymagane moduły Az.

Instalowanie bezpośrednio przy użyciu skryptu

Jeśli masz zainstalowane moduły Azure Az i nie możesz ich odinstalować (lub nie chcesz ich odinstalować), możesz ręcznie pobrać skrypt przy użyciu karty Pobieranie ręczne w linku pobierania skryptu. Skrypt jest pobierany jako nieprzetworzony plik nupkg. Aby zainstalować skrypt z tego pliku nupkg, zobacz Ręczne pobieranie pakietów.

Wersja 1.0.11 to nowa wersja skryptu migracji, która zawiera główne poprawki błędów. Zaleca się używanie tej stabilnej wersji.

Jak sprawdzić wersję pobranego skryptu

Aby sprawdzić wersję pobranego skryptu, wykonaj następujące kroki:

  • Wyodrębnij zawartość pakietu NuGet.
  • .PS1 Otwórz plik w folderze i sprawdź .VERSION go u góry, aby potwierdzić wersję pobranego skryptu
<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

Jak uruchomić skrypt

Aby uruchomić skrypt:

  1. Użyj polecenia Connect-AzAccount , aby nawiązać połączenie z platformą Azure.

  2. Użyj polecenia Import-Module Az , aby zaimportować moduły Az.

  3. Set-AzContext Uruchom polecenie cmdlet , aby ustawić aktywny kontekst platformy Azure na poprawną subskrypcję. Jest to ważny krok, ponieważ skrypt migracji może wyczyścić istniejącą grupę zasobów, jeśli nie istnieje w bieżącym kontekście subskrypcji.

    Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'

  4. Uruchom polecenie Get-Help AzureAppGWMigration.ps1 , aby sprawdzić wymagane parametry:

    AzureAppGWMigration.ps1
 -resourceId <V1 application gateway Resource ID>
 -subnetAddressRange <subnet space you want to use>
 -appgwName <string to use to append>
 -AppGWResourceGroupName <resource group name you want to use>
 -sslCertificates <comma-separated SSLCert objects as above>
 -trustedRootCertificates <comma-separated Trusted Root Cert objects as above>
 -privateIpAddress <private IP string>
 -publicIpResourceId <public IP name string>
 -validateMigration -enableAutoScale

Uwaga

Podczas migracji nie są podejmowane żadne inne operacje na bramie w wersji 1 ani żadnych skojarzonych zasobów.

Parametry skryptu:

  • resourceId: [Ciąg]: Wymagany: ten parametr jest identyfikatorem zasobu platformy Azure dla istniejącej bramy Standardowa V1 lub zapory aplikacji internetowej w wersji 1. Aby znaleźć tę wartość ciągu, przejdź do witryny Azure Portal, wybierz bramę aplikacji lub zasób zapory aplikacji internetowej, a następnie kliknij link Właściwości dla bramy. Identyfikator zasobu znajduje się na tej stronie.

    Możesz również uruchomić następujące polecenia programu Azure PowerShell, aby uzyskać identyfikator zasobu:

    $appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
$appgw.Id

  • subnetAddressRange: [Ciąg]: Wymagany: ten parametr jest przestrzenią adresową IP przydzieloną (lub chcesz przydzielić) dla nowej podsieci zawierającej nową bramę w wersji 2. Przestrzeń adresowa musi być określona w notacji CIDR. Na przykład: 10.0.0.0/24. Nie musisz z wyprzedzeniem tworzyć tej podsieci, ale ciDR musi być częścią przestrzeni adresowej sieci wirtualnej. Skrypt tworzy go dla Ciebie, jeśli nie istnieje i jeśli istnieje, używa istniejącej (upewnij się, że podsieć jest albo pusta, zawiera tylko bramę w wersji 2, jeśli istnieje i ma wystarczającą liczbę dostępnych adresów IP).

  • appgwName: [Ciąg]: opcjonalne. Jest to ciąg, którego należy użyć jako nazwy nowej bramy Standard_V2 lub WAF_V2. Jeśli ten parametr nie zostanie podany, nazwa istniejącej bramy w wersji 1 jest używana z sufiksem _V2 dołączonym.

  • AppGWResourceGroupName: [String]: Opcjonalne. Nazwa grupy zasobów, w której mają zostać utworzone zasoby usługi Application Gateway w wersji 2 (wartość domyślna to <V1-app-gw-rgname>)

Uwaga

Upewnij się, że nie ma istniejącej bramy aplikacji z podaną nazwą appGW v2 i nazwą grupy zasobów w subskrypcji w wersji 1. Spowoduje to ponowne zapisywanie istniejących zasobów.

  • sslCertificates: [PSApplicationGatewaySslCertificate]: Opcjonalne. Rozdzielana przecinkami lista obiektów PSApplicationGatewaySslCertificate tworzonych do reprezentowania certyfikatów TLS/SSL z bramy w wersji 1 musi zostać przekazana do nowej bramy w wersji 2. Dla każdego certyfikatu TLS/SSL skonfigurowanego dla bramy Standardowa V1 lub WAF V1 można utworzyć nowy obiekt PSApplicationGatewaySslCertificate za pomocą New-AzApplicationGatewaySslCertificate pokazanego tutaj polecenia. Potrzebna jest ścieżka do pliku certyfikatu TLS/SSL i hasła.

    Ten parametr jest opcjonalny tylko wtedy, gdy nie masz odbiorników HTTPS skonfigurowanych dla bramy w wersji 1 lub zapory aplikacji internetowej. Jeśli masz co najmniej jedną konfigurację odbiornika HTTPS, musisz określić ten parametr.

    $password = ConvertTo-SecureString <cert-password> -AsPlainText -Force
$mySslCert1 = New-AzApplicationGatewaySslCertificate -Name "Cert01" `
  -CertificateFile <Cert-File-Path-1> `
  -Password $password
$mySslCert2 = New-AzApplicationGatewaySslCertificate -Name "Cert02" `
  -CertificateFile <Cert-File-Path-2> `
  -Password $password

    W poprzednim przykładzie można przekazać $mySslCert1, $mySslCert2 wartość (rozdzielaną przecinkami) jako wartości dla tego parametru w skrycie.

  • sslCertificates z usługi Keyvault: opcjonalnie. Możesz pobrać certyfikaty przechowywane w usłudze Azure Key Vault i przekazać je do skryptu migracji. Aby pobrać certyfikat jako plik PFX, uruchom następujące polecenie. Te polecenia uzyskują dostęp do identyfikatora SecretId, a następnie zapisują zawartość jako plik PFX.

     $vaultName = ConvertTo-SecureString <kv-name> -AsPlainText -Force
 $certificateName = ConvertTo-SecureString <cert-name> -AsPlainText -Force
 $password = ConvertTo-SecureString <password> -AsPlainText -Force

 $pfxSecret = Get-AzKeyVaultSecret -VaultName $vaultName -Name $certificateName -AsPlainText
 $secretByte = [Convert]::FromBase64String($pfxSecret)
 $x509Cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2
 $x509Cert.Import($secretByte, $null, [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
 $pfxFileByte = $x509Cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $password)

 # Write to a file
 [IO.File]::WriteAllBytes("KeyVaultcertificate.pfx", $pfxFileByte)

    Dla każdego certyfikatu pobranego z usługi Keyvault można utworzyć nowy obiekt PSApplicationGatewaySslCertificate za pomocą polecenia New-AzApplicationGatewaySslCertificate pokazanego tutaj. Potrzebna jest ścieżka do pliku certyfikatu TLS/SSL i hasła.

    //Convert the downloaded certificate to SSL object
$password = ConvertTo-SecureString  <password> -AsPlainText -Force 
$cert = New-AzApplicationGatewaySSLCertificate -Name <certname> -CertificateFile <Cert-File-Path-1> -Password $password

  • trustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: Opcjonalnie. Rozdzielana przecinkami lista obiektów PSApplicationGatewayTrustedRootCertificate tworzonych w celu reprezentowania zaufanych certyfikatów głównych na potrzeby uwierzytelniania wystąpień zaplecza z bramy w wersji 2.

    $certFilePath = ".\rootCA.cer"
$trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath

    Aby utworzyć listę obiektów PSApplicationGatewayTrustedRootCertificate, zobacz New-AzApplicationGatewayTrustedRootCertificate.

  • privateIpAddress: [Ciąg]: opcjonalne. Określony prywatny adres IP, który chcesz skojarzyć z nową bramą w wersji 2. Musi to być z tej samej sieci wirtualnej, która jest przydzielana dla nowej bramy w wersji 2. Jeśli nie zostanie określony, skrypt przydziela prywatny adres IP bramy w wersji 2.

  • publicIpResourceId: [Ciąg]: opcjonalne. ResourceId istniejącego zasobu publicznego adresu IP (standardowej jednostki SKU) w subskrypcji, który chcesz przydzielić do nowej bramy w wersji 2. Jeśli podano nazwę zasobu publicznego adresu IP, upewnij się, że istnieje on w stanie powodzenia. Jeśli nie zostanie określony, skrypt przydzieli nowy publiczny adres IP w tej samej grupie zasobów. Nazwa to nazwa bramy w wersji 2 z dołączonym -IP . Jeśli podano nazwę AppGWResourceGroupName i nie podano publicznego adresu IP, upewnij się, że zasób publicznego adresu IP o nazwie AppGWV2Name-IP nie istnieje w grupie zasobów o nazwie AppGWResourceGroupName w subskrypcji V1.

  • validateMigration: [switch]: Opcjonalne. Użyj tego parametru, aby umożliwić skryptowi wykonanie pewnych podstawowych weryfikacji porównania konfiguracji po utworzeniu bramy w wersji 2 i kopii konfiguracji. Domyślnie nie jest wykonywana walidacja.

  • enableAutoScale: [switch]: Opcjonalne. Użyj tego parametru, aby włączyć skrypt w celu włączenia skalowania automatycznego w nowej bramie w wersji 2 po jego utworzeniu. Domyślnie skalowanie automatyczne jest wyłączone. Zawsze możesz ręcznie włączyć ją później w nowo utworzonej bramie w wersji 2.

  1. Uruchom skrypt przy użyciu odpowiednich parametrów. Ukończenie może potrwać od pięciu do siedmiu minut.

    Przykład

    AzureAppGWMigration.ps1 `
   -resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
   -subnetAddressRange 10.0.0.0/24 `
   -appgwname "MynewV2gw" `
   -AppGWResourceGroupName "MyResourceGroup" `
   -sslCertificates $mySslCert1,$mySslCert2 `
   -trustedRootCertificates $trustedCert `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   -validateMigration -enableAutoScale

Zastrzeżenia\Ograniczenia

  • Nowa brama w wersji 2 ma nowe publiczne i prywatne adresy IP. Nie można bezproblemowo przenieść adresów IP skojarzonych z istniejącą bramą V1 do wersji 2. Można jednak przydzielić istniejący (nieprzydzielony) publiczny lub prywatny adres IP do nowej bramy w wersji 2.
  • Musisz podać przestrzeń adresową IP dla innej podsieci w sieci wirtualnej, w której znajduje się brama V1. Skrypt nie może utworzyć bramy w wersji 2 w podsieci, która ma już bramę w wersji 1. Jeśli podsieć ma już bramę w wersji 2, skrypt może nadal działać, pod warunkiem, że dostępna jest wystarczająca przestrzeń adresów IP.
  • Jeśli masz sieciową grupę zabezpieczeń lub trasy zdefiniowane przez użytkownika skojarzone z podsiecią bramy w wersji 2, upewnij się, że są one zgodne z wymaganiami sieciowej grupy zabezpieczeń i wymaganiami UDR dotyczącymi pomyślnej migracji
  • Zasady punktu końcowego usługi dla sieci wirtualnej nie są obecnie obsługiwane w podsieci usługi Application Gateway.
  • Aby przeprowadzić migrację konfiguracji protokołu TLS/SSL, należy określić wszystkie certyfikaty TLS/SSL używane w bramie w wersji 1.
  • Jeśli dla bramy w wersji 1 jest włączony tryb FIPS, nie jest on migrowany do nowej bramy w wersji 2. Tryb FIPS nie jest obsługiwany w wersji 2.
  • Jeśli masz bramę tylko prywatnego adresu IP w wersji 1, skrypt generuje prywatny i publiczny adres IP dla nowej bramy w wersji 2. Prywatna brama ip tylko w wersji 2 jest obecnie dostępna w publicznej wersji zapoznawczej. Gdy stanie się ogólnie dostępna, klienci mogą użyć skryptu, aby przenieść prywatną bramę ip tylko w wersji 1 do prywatnej bramy tylko w wersji 2.
  • Uwierzytelnianie NTLM i Kerberos nie jest obsługiwane przez usługę Application Gateway w wersji 2. Skrypt nie może wykryć, czy brama obsługuje ten typ ruchu i może stanowić niezgodną zmianę z wersji 1 na bramy w wersji 2 w przypadku uruchomienia.
  • WAFv2 jest tworzony w starym trybie konfiguracji zapory aplikacji internetowej; wymagana jest migracja do zasad zapory aplikacji internetowej.

Migracja ruchu

Najpierw dokładnie sprawdź, czy skrypt pomyślnie utworzył nową bramę w wersji 2 z dokładną konfiguracją zmigrową z bramy w wersji 1. Możesz to sprawdzić w witrynie Azure Portal.

Wyślij również niewielką ilość ruchu przez bramę w wersji 2 jako test ręczny.

Poniżej przedstawiono kilka scenariuszy, w których bieżąca brama aplikacji (Standardowa) może odbierać ruch klienta i nasze zalecenia dotyczące każdego z nich:

  • Niestandardowa strefa DNS (na przykład contoso.com), która wskazuje adres IP frontonu (przy użyciu rekordu A) skojarzonego z bramą Standard V1 lub WAF V1.

    Rekord DNS można zaktualizować tak, aby wskazywał adres IP frontonu lub etykietę DNS skojarzoną z bramą aplikacji Standard_V2. W zależności od czasu wygaśnięcia skonfigurowanego dla rekordu DNS może upłynąć trochę czasu, aby cały ruch klienta został zmigrowane do nowej bramy w wersji 2.

  • Niestandardowa strefa DNS (na przykład contoso.com), która wskazuje etykietę DNS (na przykład: myappgw.eastus.cloudapp.azure.com przy użyciu rekordu CNAME) skojarzonego z bramą V1.

    Dostępne są dwie opcje:

    • Jeśli używasz publicznych adresów IP w bramie aplikacji, możesz przeprowadzić kontrolowaną, szczegółową migrację przy użyciu profilu usługi Traffic Manager w celu przyrostowego kierowania ruchu (metody routingu ważonego ruchu) do nowej bramy w wersji 2.

      Można to zrobić, dodając etykiety DNS bram aplikacji w wersji 1 i 2 do profilu usługi Traffic Manager oraz CNAMEing niestandardowego rekordu DNS (na przykład www.contoso.com) do domeny usługi Traffic Manager (na przykład contoso.trafficmanager.net).

    • Możesz też zaktualizować rekord DNS domeny niestandardowej, aby wskazywał etykietę DNS nowej bramy aplikacji w wersji 2. W zależności od czasu wygaśnięcia skonfigurowanego dla rekordu DNS może upłynąć trochę czasu, aby cały ruch klienta został zmigrowane do nowej bramy w wersji 2.

  • Klienci łączą się z adresem IP frontonu bramy aplikacji.

    Zaktualizuj klientów, aby używali adresów IP skojarzonych z nowo utworzoną bramą aplikacji w wersji 2. Zalecamy, aby nie używać bezpośrednio adresów IP. Rozważ użycie etykiety nazwy DNS (na przykład yourgateway.eastus.cloudapp.azure.com) skojarzonej z bramą aplikacji, którą można nazwaĆ CNAME do własnej niestandardowej strefy DNS (na przykład contoso.com).

Zagadnienia do rozważenia dotyczące cennika

Modele cenowe różnią się w przypadku jednostek SKU usługi Application Gateway w wersji 1 i 2. Opłata za 2 jest naliczana na podstawie użycia. Zobacz Cennik usługi Application Gateway przed migracją, aby uzyskać informacje o cenach.

Wskazówki dotyczące wydajności kosztów

Jednostka SKU w wersji 2 oferuje szereg zalet, takich jak zwiększenie wydajności 5 razy, lepsze zabezpieczenia dzięki integracji z usługą Key Vault, szybsze aktualizacje reguł zabezpieczeń w WAF_V2, niestandardowe reguły zapory aplikacji internetowej, skojarzenia zasad i ochrona botów. Oferuje również wysoką skalowalność, zoptymalizowany routing ruchu i bezproblemową integrację z usługami platformy Azure. Te funkcje mogą poprawić ogólne środowisko użytkownika, zapobiec spowolnieniu w czasie dużego ruchu i uniknąć kosztownych naruszeń danych.

W jednostce SKU w wersji 1 dostępnych jest pięć wariantów opartych na warstwie i rozmiarze — Standard_Small, Standard_Medium, Standard_Large, WAF_Medium i WAF_Large.

SKU V1 Stała cena/mo Stała cena/mo w wersji 2 Zalecenie
Średni standardowy 102.2 179.8 Jednostka SKU w wersji 2 może obsługiwać większą liczbę żądań niż brama w wersji 1, dlatego zalecamy skonsolidowanie wielu bram w wersji 1 w jednej bramie w wersji 2, aby zoptymalizować koszt. Upewnij się, że konsolidacja nie przekracza limitów usługi Application Gateway. Zalecamy konsolidację 3:1.
Zapora aplikacji internetowej — średni rozmiar 183.96 262.8 Tak samo jak w przypadku średniego standardu
Standardowa — duża 467.2 179.58 W przypadku tych wariantów w większości przypadków przejście do bramy w wersji 2 może zapewnić lepszą korzyść cenową w porównaniu z wersją V1.
Zapora aplikacji internetowej — duża 654.08 262.8 Tak samo jak w przypadku standardowego dużego rozmiaru

Uwaga

Przedstawione tutaj obliczenia są oparte na regionie Wschodnie stany USA i bramy z 2 wystąpieniami w wersji 1. Koszt zmienny w wersji 2 jest oparty na jednym z 3 wymiarów o najwyższym użyciu: nowe połączenia (50/s), połączenia trwałe (2500 połączeń trwałych/min), przepływność (1 CU może obsłużyć 2,22 Mb/s).

Opisane tutaj scenariusze są przykładami i służą tylko do celów ilustracyjnych. Aby uzyskać informacje o cenach zgodnie z regionem, zobacz stronę Cennik.

Aby uzyskać dodatkowe obawy dotyczące cen, skontaktuj się z twoimi CSAM lub skontaktuj się z naszym zespołem pomocy technicznej w celu uzyskania pomocy.

Często zadawane pytania

Typowe pytania dotyczące migracji można znaleźć tutaj

Następne kroki

Dowiedz się więcej o usłudze Application Gateway w wersji 2