Condividi tramite

Esercitazione: Eseguire la migrazione da pool NAT in ingresso a regole NAT

  • Articolo

I pool NAT di Azure Load Balancer rappresentano l'approccio legacy per l'assegnazione automatica delle porte front-end di Load Balancer a ogni istanza in un set di scalabilità di macchine virtuali. Le regole NAT nei servizi di bilanciamento del carico con SKU Standard hanno sostituito questa funzionalità con un approccio più semplice da gestire e più veloce da configurare.

Perché eseguire la migrazione alle regole NAT?

Le regole NAT offrono la stessa funzionalità dei pool NAT, ma presentano i vantaggi seguenti:

  • Le regole NAT possono essere gestite tramite il portale
  • Le regole NAT possono sfruttare i pool back-end, semplificando la configurazione
  • Le modifiche alla configurazione delle regole NAT si applicano più rapidamente rispetto ai pool NAT
  • Non è possibile usare pool NAT insieme alle regole NAT configurate dall'utente

Processo di migrazione

Il processo di migrazione creerà un nuovo pool back-end per ogni pool NAT in ingresso esistente nel servizio di bilanciamento del carico di destinazione. Verrà creata una regola NAT corrispondente per ogni pool NAT e la regola verrà associata al nuovo pool back-end. L'appartenenza al pool back-end esistente verrà mantenuta.

Importante

Il processo di migrazione rimuove i set di scalabilità di macchine virtuali dai pool NAT prima di associare i set di scalabilità di macchine virtuali alle nuove regole NAT. Ciò richiede un aggiornamento al modello dei set di scalabilità di macchine virtuali, che può causare un breve tempo di inattività mentre le istanze vengono aggiornate con il modello.

Nota

Il mapping delle porte front-end alle istanze del set di scalabilità di macchine virtuali può cambiare con il passaggio alle regole NAT, in particolare nelle situazioni in cui un singolo pool NAT ha più set di scalabilità di macchine virtuali associati. La nuova assegnazione di porta verrà allineata in sequenza ai numeri di ID istanza. Quando sono presenti più set di scalabilità di macchine virtuali, le porte verranno assegnate a tutte le istanze di un set di scalabilità, quindi al successivo e così via.

Nota

I cluster di Service Fabric richiedono molto più tempo per aggiornare il modello del set di scalabilità di macchine virtuali (fino a un'ora).

Prerequisiti

Installare il modulo 'AzureLoadBalancerNATPoolMigration'

Installare il modulo da PowerShell Gallery

Install-Module -Name AzureLoadBalancerNATPoolMigration -Scope CurrentUser -Repository PSGallery -Force

Usare il modulo per aggiornare i pool NAT alle regole NAT

  1. Connessione ad Azure con Connect-AzAccount
  2. Trovare il servizio di bilanciamento del carico di destinazione per l'aggiornamento delle regole NAT e prendere nota del relativo nome e del nome del gruppo di risorse
  3. Eseguire il comando di migrazione

Esempio: specificare il nome del servizio di bilanciamento del carico e il nome del gruppo di risorse

Start-AzNATPoolMigration -ResourceGroupName <loadBalancerResourceGroupName> -LoadBalancerName <LoadBalancerName>

Esempio: passare un servizio di bilanciamento del carico dalla pipeline

Get-AzLoadBalancer -ResourceGroupName -ResourceGroupName <loadBalancerResourceGroupName> -Name <LoadBalancerName> | Start-AzNATPoolMigration

Domande frequenti

La migrazione causerà tempi di inattività per le porte NAT?

Sì. Poiché è prima di tutto necessario rimuovere i pool NAT prima di poter creare le regole NAT, ci sarà un breve periodo di tempo in cui non è presente alcun mapping della porta front-end a una porta back-end.

Nota

Il tempo di inattività per la porta NAT nei cluster di Service Fabric sarà notevolmente più lungo, fino a un'ora per un cluster Silver nei test.

È necessario mantenere i nuovi pool back-end creati durante la migrazione e i pool back-end esistenti se l'appartenenza è la stessa?

No, dopo la migrazione, è possibile esaminare i nuovi pool back-end. Se l'appartenenza è la stessa tra pool back-end, è possibile sostituire il nuovo pool back-end nella regola NAT con un pool back-end esistente, quindi rimuovere il nuovo pool back-end.

Passaggi successivi