Migrera Azure Application Gateway och brandväggen för webbprogram från V1 till V2

Vi meddelade utfasningen av Application Gateway V1 SKU (Standard och WAF) den 28 april 2023. V1 SKU går i pension den 28 april 2026. Mer information finns i Migrera dina Application Gateways från V1 SKU till V2 SKU senast den 28 april 2026.

Migrering till Azure Application Gateway och Web Application Firewall (WAF) V2 medför flera fördelar:

• Bättre återhämtning: AZ-redundans, automatisk skalning
• Bättre säkerhet: Azure Keyvault-integrering, förbättrade WAF-funktioner, Bot Protection
• Förbättrade övervakningsfunktioner: Till skillnad från V1, som bara hade CPU-övervakning, ger V2 omfattande övervakning för processor-, minnes- och diskanvändning.
• Förbättrad identifiering och automatisk minskning: V2-gatewayer har avancerade identifieringsmekanismer och automatiserade minskningsprocesser som snabbt och korrekt kan identifiera och lösa problem utan att behöva vidta manuella åtgärder.
• Alla nya funktioner släpps för V2 SKU.

Vi rekommenderar starkt att du skapar en migreringsplan nu. V1-gatewayer uppgraderas inte automatiskt till V2. Använd den här migreringsguiden för att planera och utföra migreringarna.

Det finns två steg i en migrering:

1. Migrera konfigurationen
2. Migrera klienttrafiken

Den här artikeln hjälper främst till med konfigurationsmigreringen. Klienttrafikmigrering varierar beroende på miljö. Vissa allmänna rekommendationer finns i den här artikeln.

Förutsättningar

• Ett Azure-konto med en aktiv prenumeration. Skapa ett konto utan kostnad.
• Den befintliga Application Gateway V1 Standard.
• Kontrollera att du har de senaste PowerShell-modulerna, eller så kan du använda Azure Cloud Shell i portalen.
• Om du kör PowerShell lokalt måste du också köra Connect-AzAccount för att skapa en anslutning till Azure.
• Kontrollera att det inte finns någon befintlig Programgateway med det angivna AppGW V2-namnet och resursgruppens namn i V1-prenumerationen. Detta återskriver de befintliga resurserna.
• Om en offentlig IP-adress anges, kontrollera att den fungerar. Om det inte tillhandahålls och AppGWResourceGroupName tillhandahålls kontrollerar du att den offentliga IP-resursen med namnet AppGWV2Name-IP inte finns i en resursgrupp med namnet AppGWResourceGroupName i V1-prenumerationen.
• För V1 SKU krävs autentiseringscertifikat för att konfigurera TLS-anslutningar med backend-servrar. V2-SKU:n kräver att betrodda rotcertifikat laddas upp för samma ändamål. V1 tillåter användning av självsignerade certifikat som autentiseringscertifikat, men V2 kräver att ett självsignerat rotcertifikat genereras och laddas upp om självsignerade certifikat används i serverdelen.
• Kontrollera att ingen annan åtgärd planeras för V1-gatewayen eller associerade resurser under migreringen.

Azure Cloud Shell

Azure är värd för Azure Cloud Shell, en interaktiv gränssnittsmiljö som du kan använda via webbläsaren. Du kan använda antingen Bash eller PowerShell med Cloud Shell för att arbeta med Azure-tjänster. Du kan använda förinstallerade Cloud Shell-kommandon för att köra koden i den här artikeln, utan att behöva installera något i din lokala miljö.

Så här startar du Azure Cloud Shell:

Alternativ	Exempel/länk
Välj Prova på det i övre högra hörnet av ett kod- eller kommandoblock. Om du väljer Prova kopieras inte koden eller kommandot automatiskt till Cloud Shell.
Gå till https://shell.azure.com eller Välj knappen Starta Cloud Shell för att öppna Cloud Shell i webbläsaren.
Välj knappen Cloud Shell på menyn längst upp till höger i Azure-portalen.

Så här använder du Azure Cloud Shell:

1. Starta Cloud Shell.

2. Välj knappen Kopiera i ett kodblock (eller kommandoblock) för att kopiera koden eller kommandot.

3. Klistra in koden eller kommandot i Cloud Shell-sessionen genom att välja Ctrl+Skift+V i Windows och Linux, eller genom att välja Cmd+Shift+V på macOS.

4. Välj Retur för att köra koden eller kommandot.

Konfigurationsmigrering

Konfigurationsmigreringen fokuserar på att konfigurera den nya V2-gatewayen med inställningarna från din befintliga V1-miljö. Vi tillhandahåller två Azure PowerShell-skript som är utformade för att underlätta migreringen av konfigurationer från V1-gatewayer (Standard eller WAF) till V2 (Standard_V2 eller WAF_V2). Dessa skript hjälper till att effektivisera övergångsprocessen genom att automatisera nyckeldistributions- och konfigurationsuppgifter.

1. Utökat kloningsskript

Det här är den nya upplevelsen som ger en förbättrad migreringsupplevelse genom att:

• Eliminerar behovet av manuell inmatning av SSL-certifikat för klientsidan och betrodda rotcertifikat på serversidan.
• Stöd för distribution av privata V2-gatewayer.

Du kan ladda ned skriptet Förbättrad kloning från PowerShell-galleriet.

Parametrar för skriptet: Det här skriptet tar nedanstående parametrar:

• AppGw V1 ResourceId – Obligatoriskt: Den här parametern är Azure-resurs-ID:t för din befintliga Standard V1- eller WAF V1-gateway. Om du vill hitta det här strängvärdet går du till Azure Portal, väljer din programgateway eller WAF-resurs och klickar på länken Egenskaper för gatewayen. Resurs-ID:t finns på den sidan. Du kan också köra följande Azure PowerShell-kommandon för att hämta resurs-ID:t:

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

• SubnetAddressRange -Required: Undernätsadressen i CIDR-notation, där Application Gateway V2 ska distribueras
• AppGwName –Valfritt: Namnet på v2-appgatewayen. Standardvärde = {AppGwV1 Name}_migrated
• AppGwResourceGroupName -Optional: Namnet på resursgruppen där V2 Application Gateway skapas. Om den inte tillhandahålls används Application Gateway V1-resursgruppen.
• PrivateIPAddress –Valfritt: Privat IP-adress som ska tilldelas till Application Gateway V2. Om det inte tillhandahålls tilldelas slumpmässig privat IP-adress.
• ValidateBackendHealth –Valfritt: Validering efter migrering genom att jämföra ApplicationGatewayBackendHealth-svar. Om det inte ställs in kommer denna validering att hoppas över.
• PublicIpResourceId -Optional: Public IP Address resourceId (om det redan finns) kan kopplas till programgatewayen. Om det inte anges blir det offentliga IP-namnet {AppGwName}-IP.
• DisableAutoscale -Optional: Inaktivera autoskalningskonfiguration för Application Gateway V2-instanser, falskt som standard
• WafPolicyName - Valfritt: Namnet på WAF-principen som skapas från WAF V1-konfigurationen och kommer att kopplas till WAF v2-gatewayen.

Så här kör du skriptet

Kör skriptet så här:

1. Använd Connect-AzAccount för att ansluta till Azure.
2. Använd Import-Module Az för att importera Az-modulerna.
3. Kör cmdleten Set-AzContext för att ange den aktiva Azure-kontexten till rätt prenumeration. Det här är ett viktigt steg eftersom migreringsskriptet kan rensa den befintliga resursgruppen om den inte finns i den aktuella prenumerationskontexten.

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

4. Installera skriptet genom att följa stegen–Installera skript
5. Kör skriptet med lämpliga parametrar. Det kan ta fem till sju minuter att slutföra.

   AzureAppGWClone.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>
   -privateIpAddress <private IP string>
   -publicIpResourceId <public IP name string>
   - disableAutoscale
   -wafpolicyname <wafpolicyname>
   

   Exempel

   AzureAppGWClone.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" `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   -enableAutoScale
   

Recommendations

• När skriptet har slutförts granskar du V2-gatewaykonfigurationen i Azure-portalen och testar anslutningen genom att skicka trafik direkt till V2-gatewayens IP-adress.
• Skriptet kopplar av serverdelens TLS-validering som standard (ingen certifikatkedja, förfallodatum eller SNI-validering) under kloningen. Om striktare TLS-validerings- eller autentiseringscertifikat krävs kan kunden uppdatera sin Application Gateway V2 efter skapandet för att lägga till betrodda rotcertifikat och aktivera den här funktionen enligt deras behov.
• För NTLM/Kerberos-passering, ställ in bakgrundsanslutningen till "true" i HTTP-inställningar efter kloning.

Varningar

• Du måste ange ett IP-adressutrymme för ett annat undernät i ditt virtuella nätverk där V1-gatewayen finns. Skriptet kan inte skapa V2-gatewayen i ett undernät som redan har en V1-gateway. Om undernätet redan har en V2-gateway kan skriptet fortfarande fungera, förutsatt att tillräckligt med IP-adressutrymme är tillgängligt.
• Om du har en nätverkssäkerhetsgrupp eller användardefinierade vägar kopplade till V2-gatewayundernätet kontrollerar du att de följer NSG-kraven och UDR-kraven för en lyckad migrering
• Om fips-läget är aktiverat för din V1-gateway migreras det inte till din nya V2-gateway.
• Den nya WAFV2 är konfigurerad att använda CRS 3.0 som standard. Eftersom CRS 3.0 är på väg mot utfasning rekommenderar vi dock att du uppgraderar till den senaste regeluppsättningen, DRS 2.1 efter migreringen. Mer information finns i CRS- och DRS-regelgrupper och regler som har en nätverkssäkerhetsgrupp eller användardefinierade vägar som är associerade till V2-gatewayundernätet, se till att de följer NSG-kraven och UDR-kraven för en lyckad migrering.

2. Äldre kloningsskript

Det här är det äldre kloningsskriptet som underlättar övergången genom att:

• Skapa en ny Standard_V2 eller WAF_V2 Application Gateway i ett användarangivet virtuellt nätverksundernät.
• Kopiera konfigurationen automatiskt från en befintlig Standard- eller WAF V1-gateway till den nyligen skapade V2-gatewayen.
• Kräver att kunden tillhandahåller SSL- och autentiseringscertifikat som indata och inte bara stöder privata V2-gatewayer Du kan ladda ned det här kloningsskriptet från PowerShell-galleriet

Parametrar för skriptet: Det äldre skriptet tar nedanstående parametrar:

• resourceId: [String]: Krävs: Den här parametern är Azure-resurs-ID:t för din befintliga Standard V1- eller WAF V1-gateway. Om du vill hitta det här strängvärdet går du till Azure Portal, väljer din programgateway eller WAF-resurs och klickar på länken Egenskaper för gatewayen. Resurs-ID:t finns på den sidan. Du kan också köra följande Azure PowerShell-kommandon för att hämta resurs-ID:t:

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

• subnetAddressRange: [String]: Krävs: Den här parametern är det IP-adressutrymme som du har allokerat (eller vill allokera) för ett nytt undernät som innehåller din nya V2-gateway. Adressutrymmet måste anges i CIDR-notationen. Exempel: 10.0.0.0/24. Du behöver inte skapa det här undernätet i förväg, men CIDR måste vara en del av VNET-adressutrymmet. Skriptet skapar det åt dig om det inte finns och om det finns använder det det befintliga (se till att undernätet antingen är tomt, endast innehåller V2 Gateway om det finns och har tillräckligt med tillgängliga IP-adresser).
• appgwName: [String]: Valfritt. Det här är en sträng som du anger som namn på den nya Standard_V2 eller WAF_V2 gatewayen. Om den här parametern inte anges används namnet på din befintliga V1-gateway med suffixet _V2 läggs till.
• AppGWResourceGroupName: [String]: Valfritt. Namnet på resursgruppen där du vill att V2 Application Gateway-resurser ska skapas (standardvärdet är <V1-app-gw-rgname>)

• sslCertificates: [PSApplicationGatewaySslCertificate]: Valfritt. En kommaavgränsad lista över PSApplicationGatewaySslCertificate-objekt som du skapar för att representera TLS/SSL-certifikaten från din V1-gateway måste laddas upp till den nya V2-gatewayen. För vart och ett av dina TLS/SSL-certifikat som konfigurerats för din Standard V1- eller WAF V1-gateway kan du skapa ett nytt PSApplicationGatewaySslCertificate-objekt via New-AzApplicationGatewaySslCertificate kommandot som visas här. Du behöver sökvägen till TLS/SSL Cert-filen och lösenordet.

  Den här parametern är bara valfri om du inte har HTTPS-lyssnare konfigurerade för din V1-gateway eller WAF. Om du har minst en HTTPS-lyssnarkonfiguration måste du ange den här parametern.

       $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
  

  Du kan skicka in $mySslCert1, $mySslCert2 (kommaavgränsade) i föregående exempel som värden för den här parametern i skriptet.

• ssl-certifikat från Keyvault: Valfritt Du kan ladda ned certifikaten som lagras i Azure Key Vault och skicka dem till migreringsskriptet. Om du vill ladda ned certifikatet som en PFX-fil kör du följande kommando. Dessa kommandon kommer åt SecretId och sparar sedan innehållet som en PFX-fil.

      $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)
  

  För vart och ett av certifikatet som hämtats från Keyvault kan du skapa ett nytt PSApplicationGatewaySslCertificate-objekt via kommandot New-AzApplicationGatewaySslCertificate som visas här. Du behöver sökvägen till TLS/SSL Cert-filen och lösenordet.

  //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]: Valfritt. En kommaavgränsad lista över PSApplicationGatewayTrustedRootCertificate-objekt som du skapar för att representera betrodda rotcertifikat för autentisering av dina serverdelsinstanser från din v2-gateway.

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

  Information om hur du skapar en lista över PSApplicationGatewayTrustedRootCertificate-objekt finns i New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress: [String]: Valfritt. En specifik privat IP-adress som du vill associera med din nya V2-gateway. Detta måste vara från samma virtuella nätverk som du allokerar för din nya V2-gateway. Om detta inte anges allokerar skriptet en privat IP-adress för din V2-gateway.

• publicIpResourceId: [String]: Valfritt. ResourceId för befintlig offentlig IP-adressresurs (standard-SKU) i din prenumeration som du vill allokera till den nya V2-gatewayen. Om ett offentligt IP-resursnamn anges, se till att det finns i tillståndet 'lyckad'. Om detta inte anges allokerar skriptet en ny offentlig IP-adress i samma resursgrupp. Namnet är V2-gatewayens namn med -IP tillagt. Om AppGWResourceGroupName har angetts och en offentlig IP-adress inte har angetts kontrollerar du att den offentliga IP-resursen med namnet AppGWV2Name-IP inte finns i en resursgrupp med namnet AppGWResourceGroupName i V1-prenumerationen.

• validateMigration: [switch]: Valfritt. Använd den här parametern för att aktivera skriptet för att utföra vissa grundläggande konfigurationsjämförelsevalideringar efter att V2-gatewayen har skapats och konfigurationskopian. Som standard görs ingen validering.

• enableAutoScale: [switch]: Valfritt. Använd den här parametern för att aktivera skriptet för att aktivera automatisk skalning på den nya V2-gatewayen när den har skapats. Som standard inaktiveras automatisk skalning. Du kan alltid aktivera den manuellt senare på den nyligen skapade V2-gatewayen.

Så här kör du skriptet

Kör skriptet så här:

1. Använd Connect-AzAccount för att ansluta till Azure.
2. Använd Import-Module Az för att importera Az-modulerna.
3. Kör cmdleten Set-AzContext för att ange den aktiva Azure-kontexten till rätt prenumeration. Det här är ett viktigt steg eftersom migreringsskriptet kan rensa den befintliga resursgruppen om den inte finns i den aktuella prenumerationskontexten.

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

4. Installera skriptet genom att följa stegen–Installera skript
5. Kör Get-Help AzureAppGWMigration.ps1 för att undersöka de obligatoriska parametrarna:
6. Kör skriptet med lämpliga parametrar. Det kan ta fem till sju minuter att slutföra.

   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
   

   Exempel

      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
   

Varningar\Begränsningar

• Den nya V2-gatewayen har nya offentliga och privata IP-adresser. Det går inte att flytta IP-adresserna som är associerade med den befintliga V1-gatewayen sömlöst till V2. Du kan dock allokera en befintlig (oallokerad) offentlig eller privat IP-adress till den nya V2-gatewayen.
• Du måste ange ett IP-adressutrymme för ett annat undernät i ditt virtuella nätverk där V1-gatewayen finns. Skriptet kan inte skapa V2-gatewayen i ett undernät som redan har en V1-gateway. Om undernätet redan har en V2-gateway kan skriptet fortfarande fungera, förutsatt att tillräckligt med IP-adressutrymme är tillgängligt.
• Om du har en nätverkssäkerhetsgrupp eller användardefinierade vägar som är associerade med V2-gatewayundernätet kontrollerar du att de följer NSG-kraven och UDR-kraven för en lyckad migrering.
• Policyer för tjänstslutpunkter för virtuella nätverk stöds för närvarande inte i något undernät för Application Gateway.
• Om du vill migrera en TLS/SSL-konfiguration måste du ange alla TLS/SSL-certifikat som används i din V1-gateway.
• Om fips-läget är aktiverat för din V1-gateway migreras det inte till din nya V2-gateway.
• Om du bara har en privat IP-gateway genererar skriptet en privat och offentlig IP-adress för den nya V2-gatewayen. V2-gatewayen, som endast stödjer privata IP-adresser, är just nu tillgänglig i en offentlig förhandsversion. När det blir allmänt tillgängligt kan kunderna använda skriptet för att överföra sin privata IP-endast V1-gateway till en privat IP endast V2-gateway.
• WAFv2 skapas i gammalt WAF-konfigurationsläge. migrering till WAF-princip krävs.
• Den nya WAFv2 är konfigurerad att använda CRS 3.0 som standard. Eftersom CRS 3.0 är på väg mot utfasning rekommenderar vi dock att du uppgraderar till den senaste regeluppsättningen, DRS 2.1 efter migreringen. Mer information finns i CRS- och DRS-regelgrupper och regler

Installera skriptet

Det finns två alternativ för dig beroende på din lokala Installation och inställningar för PowerShell-miljön:

• Om du inte har installerat Azure Az-modulerna eller inte har något emot att avinstallera Azure Az-modulerna är det bästa alternativet att använda Install-Script alternativet för att köra skriptet.
• Om du behöver behålla Azure Az-modulerna är det bästa valet att ladda ned skriptet och köra det direkt. För att avgöra om du har Azure Az-modulerna installerade, kör Get-InstalledModule -Name az. Om du inte ser några installerade Az-moduler kan du använda Install-Script metoden.

Installera med metoden Install-Script (rekommenderas)

Om du vill använda det här alternativet får du inte ha Azure Az-modulerna installerade på datorn. Om de är installerade visas ett fel i följande kommando. Du kan antingen avinstallera Azure Az-modulerna eller använda det andra alternativet för att ladda ned skriptet manuellt och köra det.

Kör skriptet med följande kommando för att hämta den senaste versionen:

• För förbättrat kloningsskript – Install-Script -Name AzureAppGWClone -Force

• För det äldre kloningsskriptet – Install-Script -Name AzureAppGWMigration -Force

Det här kommandot installerar också de nödvändiga Az-modulerna.

Installera med skriptet direkt

Om du har installerat vissa Azure Az-moduler och inte kan avinstallera dem (eller inte vill avinstallera dem) kan du manuellt ladda ned skriptet med hjälp av fliken Manuell nedladdning i länken för skriptnedladdning.

Skriptet laddas ned som en rå nupkg-fil. Information om hur du installerar skriptet från den här nupkg-filen finns i Manuell pakethämtning.

För det äldre kloningsskriptet är version 1.0.11 den nya versionen av migreringsskriptet som innehåller större felkorrigeringar. Se till att använda den senaste stabila versionen från PowerShell-galleriet

Så här kontrollerar du versionen av det nedladdade skriptet

Så här kontrollerar du versionen av det nedladdade skriptet:

1. Extrahera innehållet i NuGet-paketet.
2. .PS1 Öppna filen i mappen och kontrollera .VERSION längst upp för att bekräfta versionen av det nedladdade skriptet

<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

Trafikmigrering

Förutsättningar

• Kontrollera först att skriptet har skapat en ny V2-gateway med den exakta konfigurationen som migrerats från V1-gatewayen. Du kan kontrollera detta från Azure Portal.
• Skicka också en liten mängd trafik via V2-gatewayen som ett manuellt test.

Offentligt IP-kvarhållningsskript

När du har migrerat konfigurationen och testat din nya V2-gateway noggrant fokuserar det här steget på att omdirigera livetrafik. Vi tillhandahåller ett Azure PowerShell-skript som är utformat för att behålla den offentliga IP-adressen från V1.

• Växlar offentlig IP-adress: Det här skriptet reserverar den offentliga IP-adressen Basic från V1, konverterar den till Standard och kopplar den till V2-gatewayen. Detta omdirigerar effektivt all inkommande trafik till V2-gatewayen.
• Förväntad stilleståndstid: Den här IP-växlingsåtgärden resulterar vanligtvis i en kort stilleståndstid på cirka 1–5 minuter. Planera utifrån detta.
• Efter en lyckad skriptkörning flyttas den offentliga IP-adressen från Application Gateway V1 till Application Gateway V2, där Application Gateway V1 får en ny offentlig IP-adress.

Du kan ladda ned det här offentliga IP-kvarhållningsskriptet från PowerShell-galleriet

Parametrar för skriptet:

Det här skriptet kräver följande obligatoriska parametrar:

• V1 ResourceId – resurs-ID för V1 Application Gateway vars offentliga IP kommer att reserveras och associeras med V2.
• V2 ResourceId – resurs-ID för V2 Application Gateway som den offentliga V1-IP-adressen tilldelas till. V2-gatewayen kan skapas manuellt eller med något av kloningsskripten.

När du har laddat ned och installerat skriptet

Kör AzureAppGWClone.ps1 med de obligatoriska parametrarna:

AzureAppGWIPMigrate.ps1
-v1resourceId <V1 application gateway Resource ID>
-v2resourceId <V2 application gateway Resource ID>

Exempel

./AzureAppGWIPMigrate.ps1 `
-v1resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
-v2resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv2appgateway `

När IP-växlingen är klar bör kunderna kontrollera kontroll- och dataplansåtgärder på V2-gatewayen. Alla kontrollplansåtgärder utom Ta bort inaktiveras på V1-gatewayen.

Rekommendationer för trafikmigrering

Följande är några scenarier där din aktuella programgateway (Standard) kan ta emot klienttrafik och våra rekommendationer för var och en:

• En anpassad DNS-zon (till exempel contoso.com) som pekar på klientdelens IP-adress (med hjälp av en A-post) som är associerad med din Standard V1- eller WAF V1-gateway. Du kan uppdatera DNS-posten så att den pekar på klientdelens IP- eller DNS-etikett som är associerad med din Standard_V2 programgateway. Beroende på vilken TTL som konfigurerats på DNS-posten kan det ta ett tag innan all klienttrafik migreras till din nya V2-gateway.
• En anpassad DNS-zon (till exempel contoso.com) som pekar på DNS-etiketten (till exempel myappgw.eastus.cloudapp.azure.com med hjälp av en CNAME-post) som är associerad med din V1-gateway. Du har två alternativ:
  • Om du använder offentliga IP-adresser på din programgateway kan du utföra en kontrollerad, detaljerad migrering med hjälp av en Traffic Manager-profil för att stegvis dirigera trafik (viktad trafikroutningsmetod) till den nya V2-gatewayen. Du kan göra detta genom att lägga till DNS-etiketterna för både V1- och V2-programgatewayerna i Traffic Manager-profilen , och CNAME:a din anpassade DNS-post (till exempel www.contoso.com) till Traffic Manager-domänen (till exempel contoso.trafficmanager.net).
  • Eller så kan du uppdatera dns-posten för den anpassade domänen så att den pekar på DNS-etiketten för den nya V2-programgatewayen. Beroende på vilken TTL som konfigurerats på DNS-posten kan det ta ett tag innan all klienttrafik migreras till din nya V2-gateway.
• Dina klienter ansluter till klientdels-IP-adressen för din programgateway. Uppdatera dina klienter så att de använder DEN IP-adress som är associerad med den nyligen skapade V2-programgatewayen. Vi rekommenderar att du inte använder IP-adresser direkt. Överväg att använda DNS-namnetiketten (till exempel yourgateway.eastus.cloudapp.azure.com) som är associerad med din programgateway som du kan CNAME till din egen anpassade DNS-zon (till exempel contoso.com).

Efter migrationen

När trafikmigreringen har slutförts och du har verifierat att programmet körs korrekt via V2-gatewayen kan du på ett säkert sätt planera att inaktivera och ta bort den gamla V1 Application Gateway-resursen för att undvika onödiga kostnader.

Överväganden för prissättning

Prismodellerna skiljer sig åt för Application Gateway V1- och V2-SKU:er. V2 debiteras baserat på förbrukning. Se Priser för Application Gateway innan du migrerar för prisinformation.

Vägledning för kostnadseffektivitet

V2 SKU har en rad fördelar, till exempel en prestandaökning på 5x, förbättrad säkerhet med Key Vault-integrering, snabbare uppdateringar av säkerhetsregler i WAF_V2, ANPASSADE WAF-regler, principassociationer och botskydd. Det erbjuder också hög skalbarhet, optimerad trafikroutning och sömlös integrering med Azure-tjänster. Dessa funktioner kan förbättra den övergripande användarupplevelsen, förhindra långsammare tider med tung trafik och undvika dyra dataintrång.

Det finns fem tillgängliga varianter i V1 SKU baserat på nivå och storlek – Standard_Small, Standard_Medium, Standard_Large, WAF_Medium och WAF_Large.

För ytterligare frågor rörande prissättningen, samarbeta med din CSAM eller kontakta vårt supportteam för hjälp.

Vanliga frågor

Vanliga frågor om migrering finns här

Nästa steg

Läs mer om Application Gateway V2