Eseguire la migrazione di Azure Application Gateway e Web Application Firewall da V1 a V2

Microsoft ha annunciato la deprecazione di Application Gateway V1 (Standard e Web Application Firewall) il 28 aprile 2023. Il gateway applicativo V1 verrà ritirato il 28 aprile 2026.

Questo articolo illustra come eseguire la migrazione del gateway applicazione di Azure e di Web application firewall di Azure dalla versione 1 alla versione 2 usando gli script di Azure PowerShell. La migrazione ha due fasi: migrazione della configurazione e migrazione del traffico. È possibile usare lo script di clonazione avanzato (scelta consigliata) o lo script di clonazione legacy per clonare la configurazione del gateway V1 in un nuovo gateway V2 e quindi reindirizzare il traffico client con tempi di inattività minimi.

Per altre informazioni sul ritiro del Gateway Applicazione V1, vedere Eseguire la migrazione dal Gateway Applicazione V1 a V2 entro il 28 aprile 2026.

Perché eseguire la migrazione alla versione 2?

Il Gateway Applicativo V2 e il Firewall per Applicazioni Web V2 offrono i seguenti vantaggi rispetto alla versione 1:

• Resilienza. Ridondanza delle zone di disponibilità e scalabilità automatica.
• Security. Integrazione di Azure Key Vault, funzionalità migliorate di Web Application Firewall e protezione bot.
• Monitoraggio. Monitoraggio completo per l'utilizzo di CPU, memoria e disco. V1 supporta solo la CPU.
• Rilevamento e mitigazione. Rilevamento avanzato e mitigazione automatizzata che identificano e risolvono i problemi senza intervento manuale.
• Nuove funzionalità. Rilascio di nuove funzionalità solo per V2.

I gateway V1 non vengono aggiornati automaticamente alla versione 2. Usare questa guida per pianificare ed eseguire la migrazione.

Questo articolo è incentrato sulla fase di configurazione della migrazione. La migrazione del traffico client varia in base all'ambiente. Questo articolo fornisce solo raccomandazioni generali per la migrazione del traffico.

Prerequisiti

• È necessario un account Azure con una sottoscrizione attiva. Creare un account gratuito.

• È necessaria una distribuzione esistente di Gateway Applicativo V1 Standard.

• Usare i moduli di PowerShell più recenti oppure è possibile usare Azure Cloud Shell nel portale di Azure.

• Se si esegue PowerShell in locale, eseguire Connect-AzAccount per creare una connessione con Azure.

• Non è possibile avere un gateway esistente con i parametri AppGWV2Name e AppGWResourceGroupName forniti in una sottoscrizione V1. Questa condizione impedisce la riscrittura delle risorse esistenti.

• Non è possibile eseguire altre operazioni pianificate nel gateway V1 o in risorse associate durante la migrazione.

• Se si specifica un indirizzo IP pubblico, assicurarsi che si trovi in uno stato completato. Se non si specifica un indirizzo IP pubblico ma si specifica AppGWResourceGroupName, assicurarsi che una risorsa IP pubblica con il nome AppGWV2Name-IP non esista in un gruppo di risorse con il nome AppGWResourceGroupName nella sottoscrizione V1.

• Per V1, i certificati di autenticazione sono necessari per configurare le connessioni TLS con i server back-end. V2 richiede il caricamento di certificati radice attendibili per lo stesso scopo. Mentre V1 consente l'uso di certificati autofirmati come certificati di autenticazione, V2 impone la generazione e il caricamento di un certificato radice autofirmato se vengono usati certificati autofirmati nel back-end.

• Se si abilita l'isolamento di rete nella sottoscrizione, tutte le distribuzioni solo pubblico o solo privato del Gateway applicazione V2 devono trovarsi in una subnet delegata a Microsoft.Network/applicationGateways. Usare i passaggi per configurare la delega della subnet.

Azure Cloud Shell

Azure host Azure Cloud Shell, un ambiente shell interattivo che è possibile usare tramite il browser. È possibile usare Bash o PowerShell con Cloud Shell per usare i servizi di Azure. È possibile usare i comandi Cloud Shell preinstallati per eseguire il codice in questo articolo, senza dover installare alcun elemento nell'ambiente locale.

Per avviare Azure Cloud Shell:

Opzione	Esempio/Collegamento
Selezionare Prova nell'angolo superiore destro di un codice o di un blocco di comandi. Se si seleziona Try It non viene copiato automaticamente il codice o il comando in Cloud Shell.
Passare a https://shell.azure.com oppure selezionare il pulsante Launch Cloud Shell per aprire Cloud Shell nel browser.
Selezionare il pulsante Cloud Shell nella barra dei menu in alto a destra nel portale Azure.

Per usare Azure Cloud Shell:

1. Avviare Cloud Shell.

2. Selezionare il pulsante Copia in un blocco di codice (o blocco di comandi) per copiare il codice o il comando.

3. Incollare il codice o il comando nella sessione di Cloud Shell selezionando Ctrl+Shift+V in Windows e Linux oppure selezionando Cmd+Shift+V in macOS.

4. Selezionare Invio per eseguire il codice o il comando.

Migrazione della configurazione

La migrazione della configurazione è incentrata sulla configurazione del nuovo gateway V2 con le impostazioni dell'ambiente V1 esistente. Due script di Azure PowerShell facilitano la migrazione delle configurazioni (Standard o Web Application Firewall) da V1 a gateway V2. Questi script consentono di semplificare il processo di transizione automatizzando le attività di distribuzione e configurazione delle chiavi.

Le distribuzioni del gateway applicazione private devono avere la delega della sottorete configurata per Microsoft.Network/applicationGateways. Usare i passaggi per configurare la delega della subnet.

Script di clonazione avanzata (scelta consigliata)

Lo script di clonazione avanzato è l'opzione consigliata. Offre un'esperienza di migrazione migliorata grazie a:

• Eliminare la necessità di immettere manualmente i certificati SSL front-end e i certificati radice back-end attendibili.
• Supportare la distribuzione di gateway V2 solo privati.

È possibile scaricare lo script di clonazione avanzato da PowerShell Gallery.

Considerazioni

Se la distribuzione V1 di Application Gateway esistente è configurata con un front-end solo privato, è necessario registrare la EnableApplicationGatewayNetworkIsolation funzionalità nella sottoscrizione per la distribuzione privata precedente l'esecuzione dello script di migrazione. Questo passaggio è necessario per evitare errori di distribuzione.

Le distribuzioni del gateway applicazione private devono avere la delega della sottorete configurata per Microsoft.Network/applicationGateways. Usare i passaggi per configurare la delega della subnet.

Parametri per lo script

• AppGw V1 ResourceId -Required. ID risorsa di Azure per il gateway Standard V1 o il firewall per applicazioni Web V1 esistente. Per trovare questo valore stringa, passare al portale di Azure, selezionare la risorsa Gateway applicazione o il web application firewall e quindi selezionare il collegamento Proprietà per il gateway. L'ID risorsa si trova in tale riquadro.

  È anche possibile eseguire i comandi di Azure PowerShell seguenti per ottenere l'ID risorsa:

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

• SubnetAddressRange -Required. Indirizzo della subnet nella notazione CIDR, in cui verrà distribuito il gateway applicativo V2.

• AppGwName -Optional. Nome del gateway dell'applicazione V2. Il valore predefinito è {AppGwV1 Name}_migrated.

• AppGwResourceGroupName -Optional. Nome del gruppo di risorse in cui verrà creato il gateway applicazione V2. Se non viene fornito, viene usato il gruppo di risorse del gateway applicazione V1.

• PrivateIPAddress -Optional. Indirizzo IP privato da assegnare al gateway applicazione V2. Se non viene specificato, viene assegnato un indirizzo IP privato casuale.

• ValidateBackendHealth -Optional. Convalida post-migrazione confrontando le risposte ApplicationGatewayBackendHealth. Se non viene impostata, la convalida viene ignorata.

• PublicIpResourceId -Optional. ID risorsa dell'indirizzo IP pubblico (se già esistente) da collegare al gateway applicazione. Se non viene specificato, il nome IP pubblico è {AppGwName}-IP.

• DisableAutoscale -Optional. Opzione per disabilitare la configurazione della scalabilità automatica per le istanze del gateway delle applicazioni V2. false È per impostazione predefinita.

• WafPolicyName -Optional. Nome della policy del Web Application Firewall che verrà creata dalla configurazione Web Application Firewall V1 e collegata al gateway Web Application Firewall V2.

Passaggi per eseguire lo script

1. Usare Connect-AzAccount per connettersi a Azure.

2. Usare Import-Module Az per importare i moduli Az.

3. Eseguire il Set-AzContext cmdlet per impostare il contesto di Azure attivo sulla sottoscrizione corretta. Questo passaggio è importante perché lo script di migrazione potrebbe pulire il gruppo di risorse esistente se il gruppo non esiste nel contesto della sottoscrizione corrente.

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

4. Installare lo script seguendo la procedura descritta in Installazione dello script più avanti in questo articolo.

5. Eseguire lo script usando i parametri appropriati. Il completamento dello script potrebbe richiedere da cinque a sette minuti.

   ./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>
   

   Ecco un esempio:

   ./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" `
   

Recommendations

• Al termine dello script, esaminare la configurazione del gateway V2 nel portale di Azure e testare la connettività inviando il traffico direttamente all'INDIRIZZO IP del gateway V2.

• Lo script riduce la convalida TLS back-end per impostazione predefinita (nessuna catena di certificati, scadenza o convalida SNI) durante la clonazione. Se sono necessari certificati di autenticazione o convalida TLS più rigorosi, è possibile aggiornare la distribuzione del gateway applicazione V2 dopo la creazione per aggiungere certificati radice attendibili e abilitare questa funzionalità.

• Per il pass-through NTLM e Kerberos, impostare la connessione back-end dedicata su true nelle impostazioni HTTP dopo la clonazione.

Avvertenze

• È necessario fornire uno spazio indirizzi IP per un'altra subnet all'interno della rete virtuale che contiene il gateway V1. Lo script non può creare il gateway V2 in una subnet che dispone già di un gateway V1. Se la subnet dispone già di un gateway V2, lo script potrebbe comunque funzionare se è disponibile spazio di indirizzi IP sufficiente.

• Se si dispone di un gruppo di sicurezza di rete (NSG) o di route definite dall'utente associate alla subnet del gateway V2, assicurarsi che rispettino i requisiti del gruppo di sicurezza di rete e la route definita dall'utente per una corretta migrazione.

• Se la modalità FIPS è abilitata per il gateway V1, non viene eseguita la migrazione al nuovo gateway V2.

• Web Application Firewall V2 è configurato per utilizzare Core Rule Set (CRS) 3.0 per impostazione predefinita. Poiché CRS 3.0 si trova nel percorso di deprecazione, eseguire l'aggiornamento al set di regole più recente dopo la migrazione: Set di regole predefinito (DRS) 2.2. Per altre informazioni, vedere il gruppo di regole e le regole del Web Application Firewall DRS e CRS.

Script di clonazione legacy

Lo script di clonazione legacy facilita la transizione tramite:

• Creazione di un nuovo gateway applicazione V2 Standard o Web application firewall V2 in una subnet di rete virtuale specificata dall'utente.
• Copia automatica della configurazione da un gateway V1 Standard o Web Application Firewall esistente al gateway V2 appena creato.
• Richiedere di fornire i certificati TLS/SSL e di autenticazione come input. Questo script non supporta gateway V2 esclusivamente privati. È possibile scaricare questo script di clonazione da PowerShell Gallery.

Parametri per lo script

Lo script legacy accetta i parametri seguenti:

• resourceId. Questo parametro obbligatorio è l'ID risorsa Azure per il gateway di rete Standard V1 o Web Application Firewall V1 esistente. Per trovare questo valore stringa, vai al portale di Azure, seleziona la risorsa Application Gateway o Web Application Firewall, e seleziona il collegamento Proprietà per il gateway. L'ID risorsa si trova in tale riquadro.

  È anche possibile eseguire i comandi di Azure PowerShell seguenti per ottenere l'ID risorsa:

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

• subnetAddressRange. Questo parametro obbligatorio di tipo stringa è l'intervallo di indirizzi IP che hai allocato (o che intendi allocare) per una nuova subnet che contiene il nuovo gateway V2. Lo spazio indirizzi deve essere specificato nella notazione CIDR. Un esempio è 10.0.0.0/24.

  Non è necessario creare questa subnet in anticipo, ma il CIDR deve far parte dello spazio indirizzi per la rete virtuale. Lo script lo crea automaticamente se non esiste. Se esiste, lo script usa quello esistente. Assicurarsi che la subnet sia vuota o contenga solo il gateway V2 e che disponga di indirizzi IP disponibili sufficienti.

• appgwName. È necessario specificare questa stringa facoltativa come nome per il nuovo gateway Standard V2 o Web Application Firewall V2. Se non si specifica questo parametro, il nome del gateway V1 esistente viene usato con il suffisso _V2 aggiunto.

• AppGWResourceGroupName. Questa stringa facoltativa è il nome del gruppo di risorse in cui si desidera creare le risorse del gateway applicazione V2. Il valore predefinito è <V1-app-gw-rgname>.

  Assicurarsi che nella sottoscrizione V1 non sia presente alcun gateway applicativo con i valori specificati AppGWV2Name e AppGWResourceGroupName. Questo parametro riscrive le risorse esistenti.

• sslCertificates. Questo parametro fornisce un elenco delimitato da virgole di PSApplicationGatewaySslCertificate oggetti creati per rappresentare i certificati TLS/SSL dal gateway V1 che devono essere caricati nel nuovo gateway V2.

  Per ognuno dei certificati TLS/SSL configurati per il gateway V1 Standard o Web Application Firewall V1, è possibile creare un nuovo PSApplicationGatewaySslCertificate oggetto tramite il New-AzApplicationGatewaySslCertificate comando illustrato nel codice seguente. È necessario il percorso del file di certificato TLS/SSL e della password.

  Questo parametro è facoltativo solo se non sono configurati listener HTTPS per il gateway V1 o per Web Application Firewall. Se è configurato almeno un listener HTTPS, è necessario specificare questo parametro.

       $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
  

  È possibile passare $mySslCert1, $mySslCert2 (delimitato da virgole) nell'esempio precedente come valori per questo parametro nello script.

• sslCertificates. Questo parametro facoltativo viene usato per scaricare i certificati archiviati in Azure Key Vault e passarlo allo script di migrazione. Per scaricare il certificato come file PFX, eseguire il comando seguente. Questi comandi accedono SecretId e quindi salvano il contenuto come file 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)
  

  Per ognuno dei certificati scaricati da Key Vault, è possibile creare un nuovo PSApplicationGatewaySslCertificate oggetto tramite il New-AzApplicationGatewaySslCertificate comando illustrato nel codice seguente. È necessario il percorso del file di certificato TLS/SSL e della password.

  //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. Usa questo parametro facoltativo per creare un elenco di oggetti separati da virgole per rappresentare i PSApplicationGatewayTrustedRootCertificate necessari all'autenticazione delle istanze back-end dal gateway V2.

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

  Per creare un elenco di PSApplicationGatewayTrustedRootCertificate oggetti, vedere New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress. Usare questa stringa facoltativa per specificare un indirizzo IP privato specifico da associare al nuovo gateway V2. Deve trovarsi della stessa rete virtuale assegnata per il nuovo gateway V2. Se non si specifica questo parametro, lo script alloca un indirizzo IP privato per il gateway V2.

• publicIpResourceId. Usare questa stringa facoltativa per specificare l'ID risorsa di una risorsa indirizzo IP pubblico (livello Standard) esistente nella sottoscrizione da allocare al nuovo gateway V2. Se si specifica il nome della risorsa IP pubblico, verificare che esista in uno stato riuscito.

  Se non si specifica questo parametro, lo script alloca un nuovo indirizzo IP pubblico nello stesso gruppo di risorse. Il nome è il nome del gateway V2 con -IP aggiunto. Se si fornisce AppGWResourceGroupName senza fornire un indirizzo IP pubblico, assicurarsi che una risorsa IP pubblica con il nome AppGWV2Name-IP non esista in un gruppo di risorse con il nome AppGWResourceGroupName nella sottoscrizione V1.

• validateMigration. Usare questo parametro facoltativo switch per consentire allo script di eseguire alcune convalide di confronto di configurazione di base dopo la creazione del gateway V2 e la copia della configurazione. Per impostazione predefinita, non viene eseguita alcuna convalida.

• enableAutoScale. Usare questo parametro facoltativo di switch per abilitare lo script che consente la scalabilità automatica sul nuovo gateway V2 dopo la sua creazione. Per impostazione predefinita, la scalabilità automatica è disabilitata. È sempre possibile abilitarlo manualmente in un secondo momento nel gateway V2 appena creato.

Passaggi per eseguire lo script

1. Usare Connect-AzAccount per connettersi a Azure.

2. Usare Import-Module Az per importare i moduli Az.

3. Eseguire il Set-AzContext cmdlet per impostare il contesto di Azure attivo sulla sottoscrizione corretta. Questo passaggio è importante perché lo script di migrazione potrebbe pulire il gruppo di risorse esistente se non esiste nel contesto della sottoscrizione corrente.

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

4. Installare lo script seguendo la procedura descritta in Installazione dello script più avanti in questo articolo.

5. Eseguire Get-Help AzureAppGWMigration.ps1 per esaminare i parametri necessari.

6. Eseguire lo script usando i parametri appropriati. Il completamento dello script potrebbe richiedere da cinque a sette minuti.

      ./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
   

   Ecco un esempio:

      ./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
   

Avvertenze e limitazioni

• Il nuovo gateway V2 ha nuovi indirizzi IP pubblici e privati. Non è possibile spostare facilmente gli indirizzi IP associati al gateway V1 esistente in V2. Tuttavia, è possibile assegnare un indirizzo IP pubblico (non allocato) esistente o privato al nuovo gateway V2.

• È necessario fornire uno spazio indirizzi IP per un'altra subnet all'interno della rete virtuale che contiene il gateway V1. Lo script non può creare il gateway V2 in una subnet che dispone già di un gateway V1. Se la subnet dispone già di un gateway V2, lo script potrebbe comunque funzionare se è disponibile spazio di indirizzi IP sufficiente.

• Se si dispone di un gruppo di sicurezza di rete o di route definite dall'utente associato alla subnet del gateway V2, assicurarsi che siano conformi ai requisiti del gruppo di sicurezza di rete e ai requisiti della ruote definita dall'utente per una migrazione corretta.

• I criteri dell'endpoint servizio di rete virtuale non sono attualmente supportati in una subnet del gateway applicazione.

• Per eseguire la migrazione di una configurazione TLS/SSL, è necessario specificare tutti i certificati TLS/SSL usati nel gateway V1.

• Se la modalità FIPS è abilitata per il gateway V1, non viene eseguita la migrazione al nuovo gateway V2.

• L'istanza di Web Application Firewall V2 viene creata nella modalità di configurazione precedente di Web Application Firewall. È necessaria la migrazione al criterio di Web Application Firewall.

• Web Application Firewall V2 è configurato per l'uso di CRS 3.0 per impostazione predefinita. Poiché CRS 3.0 si trova nel percorso di deprecazione, eseguire l'aggiornamento al set di regole più recente (DRS 2.2) dopo la migrazione. Per altre informazioni, vedere Regole e gruppi di regole CRS e DRS.

Installazione dello script

Sono disponibili due opzioni, a seconda della configurazione e delle preferenze dell'ambiente PowerShell locale:

• Se non si hanno i moduli Az di Azure installati o non è consigliabile disinstallare i moduli Az di Azure, l'opzione migliore consiste nell'usare l'opzione Install-Script per eseguire lo script.
• Se è necessario mantenere i moduli az Azure, scaricare lo script ed eseguirlo direttamente.

Per determinare se sono installati i moduli az di Azure, eseguire Get-InstalledModule -Name az. Se non vengono visualizzati moduli Az installati, è possibile usare il Install-Script metodo .

Eseguire l'installazione usando il metodo Install-Script (scelta consigliata)

Per usare questa opzione, non è necessario che nel computer siano installati i moduli Az Azure. Se sono installati, il comando seguente genererà un errore. È possibile disinstallare i moduli Az di Azure o usare l'altra opzione per scaricare manualmente lo script ed eseguirlo.

Eseguire lo script con uno dei comandi seguenti per ottenere la versione più recente:

• Per lo script di clonazione avanzato con conservazione dell'IP pubblico, usare Install-Script -Name AzureAppGWIPMigrate -Force.
• Per lo script di clonazione avanzato, usare Install-Script -Name AzureAppGWClone -Force.
• Per lo script di clonazione legacy, usare Install-Script -Name AzureAppGWMigration -Force.

Il comando installa anche i moduli Az necessari.

Eseguire l'installazione usando direttamente lo script

Se sono installati alcuni moduli Az di Azure e non è possibile disinstallarli (o non si vuole disinstallarli), è possibile scaricare manualmente lo script usando la scheda Download manuale nel collegamento per il download dello script.

Lo script viene scaricato come file .nupkg non elaborato. Per installare lo script da questo file .nupkg, vedere Download manuale del pacchetto.

Per lo script di clonazione legacy, la versione 1.0.11 è la nuova versione dello script di migrazione. Include importanti correzioni di bug. Assicurarsi di usare la versione stabile più recente di PowerShell Gallery.

Controllare la versione dello script scaricato

1. Estrarre il contenuto del pacchetto NuGet.

2. Aprire il .PS1 file nella cartella e controllare il .VERSION valore per confermare la versione dello script scaricato.

   <#PSScriptInfo
   .VERSION 1.0.10
   .GUID aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb
   .AUTHOR Microsoft Corporation
   .COMPANYNAME Microsoft Corporation
   .COPYRIGHT Microsoft Corporation. All rights reserved.
   

Migrazione del traffico

Prerequisiti

• Nel portale di Azure verificare che lo script abbia creato correttamente un nuovo gateway V2 con la configurazione esatta migrata dal gateway V1.
• Inviare una piccola quantità di traffico attraverso il gateway V2 come test manuale.

Script di mantenimento IP pubblico

Dopo aver eseguito correttamente la migrazione della configurazione e aver testato accuratamente il nuovo gateway V2, questo passaggio è incentrato sul reindirizzamento del traffico in tempo reale.

• Lo script riserva l'indirizzo IP pubblico Basic dalla versione 1, lo converte in Standard e lo collega al gateway V2. Questa azione reindirizza efficacemente tutto il traffico in ingresso al gateway V2.
• Questa operazione di scambio IP comporta in genere un breve tempo di inattività di circa 1-cinque minuti. Pianificare di conseguenza.
• Dopo l'esecuzione di uno script, l'indirizzo IP pubblico viene spostato dal gateway applicazione V1 al gateway applicazione V2. Il gateway applicazione V1 riceve un nuovo indirizzo IP pubblico.
• Durante la migrazione IP, non tentare altre operazioni sui gateway V1 e V2 o sulle risorse associate.
• Lo scambio ip pubblico eseguito da questo script è irreversibile. Dopo l'avvio, non è possibile ripristinare l'indirizzo IP nel gateway V1 usando lo script.

È possibile scaricare questo script di conservazione ip pubblico da PowerShell Gallery.

Parametri per lo script

Questo script richiede i parametri obbligatori seguenti:

• v1resourceId. L'ID risorsa del gateway V1 il cui indirizzo IP pubblico sarà riservato e associato al gateway V2.
• v2resourceId. L'ID risorsa del gateway V2 al quale verrà assegnato l'indirizzo IP pubblico V1. È possibile creare il gateway V2 manualmente o usando uno degli script di clonazione.

Dopo aver scaricato e installato lo script, eseguire AzureAppGWIPMigrate.ps1 con i parametri obbligatori:

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

Ecco un esempio:

   ./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 `

Al termine dello scambio IP, verificare le operazioni del piano di controllo e del piano dati nel gateway V2. Tutte le azioni del piano di controllo, ad eccezione dell'eliminazione, sono disabilitate nel gateway V1.

Raccomandazioni sulla migrazione del traffico

Gli elementi seguenti sono alcuni scenari in cui il gateway applicativo corrente (Standard) può ricevere traffico client e i nostri suggerimenti per ognuno di essi:

• Una zona DNS personalizzata (ad esempio, contoso.com) punta all'indirizzo IP front-end (usando un record A) associato al gateway V1 Standard o Web Application Firewall V1.

  È possibile aggiornare il record DNS in modo che punti all'indirizzo IP front-end o all'etichetta DNS associata al gateway applicativo di tipo Standard V2. A seconda del tempo di esecuzione (TTL) configurato nel record DNS, la migrazione del traffico client al nuovo gateway V2 può richiedere del tempo.

• Una zona DNS personalizzata,ad esempio contoso.com, punta all'etichetta DNS (ad esempio, myappgw.eastus.cloudapp.azure.com usando un record CNAME) associato al gateway V1.

  Sono disponibili due opzioni:

  • Se si usano indirizzi IP pubblici nel gateway applicazione, è possibile eseguire una migrazione controllata e granulare usando un profilo di Gestione traffico di Azure per instradare in modo incrementale il traffico al nuovo gateway V2.

    È possibile usare questo metodo di routing del traffico ponderato aggiungendo le etichette DNS dei gateway applicazione V1 e V2 al profilo di Gestione traffico. Applicare quindi CNAME al record DNS personalizzato ( ad esempio , www.contoso.com) al dominio di Gestione traffico (ad esempio, contoso.trafficmanager.net).

  • È possibile aggiornare il record DNS di dominio personalizzato in modo che punti all'etichetta DNS del nuovo gateway di applicazione V2. A seconda della durata (TTL) configurata nel record DNS, la migrazione del traffico client al nuovo gateway V2 può richiedere del tempo.

• I client si connettono all'indirizzo IP front-end del gateway applicazione.

  Aggiorna i client per utilizzare l'indirizzo IP associato al gateway di applicazione V2 di nuova creazione. Si consiglia di non usare direttamente gli indirizzi IP. Prendere in considerazione l'uso dell'etichetta del nome DNS (ad esempio, yourgateway.eastus.cloudapp.azure.com) associata al gateway applicazione che è possibile applicare alla zona DNS personalizzata tramite CNAME (ad esempio, contoso.com).

Attività post-migrazione

Dopo che la migrazione del traffico ha esito positivo e si verifica completamente che l'applicazione viene eseguita correttamente tramite il gateway V2, è possibile rimuovere ed eliminare in modo sicuro la risorsa V1 del gateway applicazione precedente per evitare costi non necessari.

Considerazioni sui prezzi

I modelli di determinazione dei prezzi sono diversi per il gateway applicazione V1 e V2. La versione 2 viene addebitata in base al consumo. Per informazioni sui prezzi, vedere Prezzi del gateway applicativo prima di eseguire la migrazione.

Linee guida per l'efficienza dei costi

Il gateway applicazioni V2 offre una serie di vantaggi, ad esempio:

• Un aumento delle prestazioni di 5x.
• Maggiore sicurezza con l'integrazione di Key Vault.
• Aggiornamenti più rapidi delle regole di sicurezza in Web Application Firewall V2.
• Regole personalizzate di Web Application Firewall.
• Associazioni di politiche.
• Protezione dai bot.

Il gateway applicazione V2 offre anche scalabilità elevata, routing del traffico ottimizzato e integrazione senza problemi con i servizi di Azure. Queste funzionalità possono migliorare l'esperienza utente complessiva, prevenire rallentamenti durante i periodi di traffico elevato e contribuire a evitare violazioni dei dati costose.

Cinque varianti sono disponibili in V1, in base al livello e alle dimensioni: Standard Small, Standard Medium, Standard Large, Web Application Firewall Medium e Web Application Firewall Large. Per informazioni sui prezzi in base all'area geografica, vedere la pagina dei prezzi.

Gli scenari nella tabella seguente sono esempi solo a scopo illustrativo. I calcoli sono basati su Stati Uniti orientali e per un gateway con due istanze nella versione 1. Il costo della variabile nella versione 2 si basa su una delle tre dimensioni con utilizzo più elevato: nuove connessioni (50 al secondo), connessioni persistenti (2.500 al minuto) e velocità effettiva (2,22 Mbps per unità di capacità).

Per ulteriori dubbi sui prezzi, puoi collaborare con il responsabile del successo dei clienti (CSAM) o contattare il team di supporto per assistenza.

Domande frequenti

Per risposte alle domande comuni sulla migrazione, vedere Domande frequenti sulla disattivazione del Gateway di Applicazione V1.

Contenuti correlati

• Informazioni sul gateway applicazione V2