Affidabilità in Load Balancer

Questo articolo contiene raccomandazioni specifiche sull'affidabilità per Load Balancer, nonché informazioni dettagliate sulla resilienza a livello di area di Load Balancer con zone di disponibilità e ripristino di emergenza tra aree e continuità aziendale.

Per una panoramica dell'architettura dell'affidabilità in Azure, vedere Affidabilità di Azure.

Raccomandazioni relative all'affidabilità

Questa sezione contiene raccomandazioni per ottenere resilienza e disponibilità. Ogni raccomandazione rientra in una delle due categorie seguenti:

• Gli elementi di integrità riguardano aree come gli elementi di configurazione e la corretta funzione dei componenti principali che costituiscono il carico di lavoro di Azure, ad esempio le impostazioni di configurazione delle risorse di Azure, le dipendenze da altri servizi e così via.

• Gli elementi di rischio riguardano aree quali requisiti di disponibilità e ripristino, test, monitoraggio, distribuzione e altri elementi che, se lasciati non risolti, aumentano le probabilità di problemi nell'ambiente.

Matrice di priorità delle raccomandazioni per l'affidabilità

Ogni raccomandazione è contrassegnata in base alla matrice di priorità seguente:

Image	Priorità	Descrizione
	Fortemente	Correzione immediata necessaria.
	Medio	Correzione entro 3-6 mesi.
	Bassa	Deve essere esaminato.

Riepilogo delle raccomandazioni per l'affidabilità

Category	Priorità	Elemento consigliato
Disponibilità		Assicurarsi che Load Balancer Standard sia con ridondanza della zona
		Verificare che il pool back-end contenga almeno due istanze
Efficienza del sistema		Usare il gateway NAT anziché le regole in uscita per i carichi di lavoro di produzione
		Usare Load Balancer Standard SKU

Disponibilità

Assicurarsi che Load Balancer Standard sia con ridondanza della zona

In un'area che supporta le zone di disponibilità, Load Balancer Standard deve essere distribuita con ridondanza della zona. Un servizio di bilanciamento del carico con ridondanza della zona consente di gestire il traffico da un singolo indirizzo IP front-end che può sopravvivere all'errore della zona. L'INDIRIZZO IP front-end può essere usato per raggiungere tutti i membri del pool back-end (non interessati) indipendentemente dalla zona. Se una zona di disponibilità ha esito negativo, il percorso dati può sopravvivere fino a quando le zone rimanenti nell'area rimangono integre. Per altre informazioni, vedere Bilanciamento del carico con ridondanza della zona.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

Verificare che il pool back-end contenga almeno due istanze

Distribuire Load Balancer con almeno due istanze nel back-end. Una singola istanza può causare un singolo punto di guasto. Per eseguire la compilazione per la scalabilità, è possibile associare il servizio di bilanciamento del carico a set di scalabilità di macchine virtuali.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

Efficienza del sistema

Usare il gateway NAT anziché le regole in uscita per i carichi di lavoro di produzione

Le regole in uscita allocano quantità fisse di porte SNAT a ogni istanza di macchina virtuale in un pool back-end. Questo metodo di allocazione può causare l'esaurimento delle porte SNAT, soprattutto se i modelli di traffico non uniformi comportano l'invio di un volume maggiore di connessioni in uscita in una macchina virtuale specifica. Per i carichi di lavoro di produzione, è consigliabile associare Load Balancer Standard o qualsiasi distribuzione di subnet con il gateway NAT di Azure. Il gateway NAT alloca in modo dinamico le porte SNAT in tutte le istanze di macchina virtuale in una subnet e a sua volta riduce il rischio di esaurimento delle porte SNAT.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

Usare Load Balancer Standard SKU

Load Balancer SKU Standard supporta le zone di disponibilità e la resilienza della zona, mentre lo SKU Basic non lo supporta. Quando una zona diventa inattiva, la Load Balancer Standard con ridondanza della zona non sarà interessata e le distribuzioni sono in grado di resistere agli errori di zona all'interno di un'area. Inoltre, Load Balancer Standard supporta il bilanciamento del carico tra aree per assicurarsi che l'applicazione non sia influenzata dagli errori dell'area.

Nota

I servizi di bilanciamento del carico basic non hanno un contratto di servizio.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

Supporto della zona di disponibilità

Le zone di disponibilità di Azure sono almeno tre gruppi di data center separati fisicamente all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di energia, raffreddamento e infrastruttura di rete indipendenti. In caso di errore della zona locale, le zone di disponibilità sono progettate in modo che se l'unica zona è interessata, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle due zone rimanenti.

Gli errori possono variare da errori software e hardware a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori si ottiene con ridondanza e isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.

I servizi abilitati per le zone di disponibilità di Azure sono progettati per offrire il giusto livello di affidabilità e flessibilità. Possono essere configurati in due modi. Possono essere ridondanti della zona, con replica automatica tra zone o zone, con istanze aggiunte a una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sull'architettura zonale e con ridondanza della zona, vedere Consigli per l'uso di zone e aree di disponibilità.

Azure Load Balancer supporta scenari di zone di disponibilità. È possibile usare Load Balancer Standard per aumentare la disponibilità in tutto lo scenario allineando le risorse e con la distribuzione tra zone. Leggere questo documento per comprendere questi concetti e le linee guida di progettazione degli scenari fondamentali.

Sebbene sia consigliabile distribuire Load Balancer con ridondanza della zona, un servizio di bilanciamento del carico può essere ridondante della zona, zonale o non di zona. La selezione della zona di disponibilità del servizio di bilanciamento del carico è sinonimo della selezione della zona ip front-end. Per i servizi di bilanciamento del carico pubblico, se l'indirizzo IP pubblico nel front-end del servizio di bilanciamento del carico è ridondante della zona, il servizio di bilanciamento del carico è anche con ridondanza della zona. Se l'indirizzo IP pubblico nel front-end del servizio di bilanciamento del carico è zonale, il servizio di bilanciamento del carico verrà designato anche nella stessa zona. Per configurare le proprietà correlate alla zona per il servizio di bilanciamento del carico, selezionare il tipo appropriato di front-end necessario.

Nota

Non è necessario avere un servizio di bilanciamento del carico per ogni zona, ma avere un singolo servizio di bilanciamento del carico con più front-end (zonali o ridondanti della zona) associati ai rispettivi pool back-end servirà allo scopo.

Prerequisiti

• Per usare le zone di disponibilità con Load Balancer, è necessario creare il servizio di bilanciamento del carico in un'area che supporta le zone di disponibilità. Per visualizzare le aree che supportano le zone di disponibilità, vedere l'elenco delle aree supportate.

• Usare lo SKU Standard per il servizio di bilanciamento del carico e l'indirizzo IP pubblico per il supporto delle zone di disponibilità.

• Il tipo di SKU basic non è supportato.

• Per creare la risorsa, è necessario avere il ruolo Collaboratore rete o versione successiva.

Limiti

• Le zone non possono essere modificate, aggiornate o create per la risorsa dopo la creazione.
• Le risorse non possono essere aggiornate da zona a con ridondanza della zona o viceversa dopo la creazione.

Bilanciamento del carico con ridondanza della zona

In un'area con zone di disponibilità, un Load Balancer Standard può essere con ridondanza della zona con il traffico gestito da un singolo indirizzo IP. Un singolo indirizzo IP front-end resiste agli errori della zona. L'indirizzo IP front-end può essere usato per raggiungere tutti i membri del pool back-end (non interessati), indipendentemente dalla zona. Fino a una zona di disponibilità può avere esito negativo e il percorso dati rimane integro finché le zone rimanenti nell'area rimangono integre.

L'indirizzo IP singolo del front-end è gestito contemporaneamente da più distribuzioni di infrastrutture indipendenti in più zone di disponibilità. Eventuali nuovi tentativi o ripristini riusciranno in altre zone non interessate dall'errore di zona.

Nota

Le macchine virtuali 1,2 e 3 possono appartenere alla stessa subnet e non devono necessariamente trovarsi in zone separate come i suggerimenti del diagramma.

I membri del pool back-end di un servizio di bilanciamento del carico sono in genere associati a una singola zona, ad esempio alle macchine virtuali di zona. Una progettazione comune per i carichi di lavoro di produzione sarebbe quella di avere più risorse di zona. Ad esempio, l'inserimento di macchine virtuali dalla zona 1, 2 e 3 nel back-end di un servizio di bilanciamento del carico con un front-end con ridondanza della zona soddisfa questo principio di progettazione.

Servizio di bilanciamento del carico di zona

È possibile scegliere di avere un front-end garantito a una singola zona, nota come zona. Con questo scenario, una singola zona in un'area serve tutto il flusso in ingresso o in uscita. La durata del front-end è legata all'integrità della zona. Il percorso dati non è interessato dagli errori in zone diverse da quelle in cui è stato garantito. È possibile usare front-end di zona per esporre un indirizzo IP per zona di disponibilità.

Inoltre, è supportato l'uso di front-end di zona direttamente per gli endpoint con carico bilanciato all'interno di ogni zona. È anche usare questa configurazione per esporre endpoint con carico bilanciato per zona, in modo da monitorare singolarmente ogni zona. Per gli endpoint pubblici, è possibile integrarli con un prodotto di bilanciamento del carico DNS come Gestione traffico e usare un singolo nome DNS.

Per un front-end del servizio di bilanciamento del carico pubblico, aggiungere un parametro zone all'indirizzo IP pubblico. A questo indirizzo IP pubblico fa riferimento la configurazione IP front-end usata dalla rispettiva regola.

Per un front-end del servizio di bilanciamento del carico interno, aggiungere un parametro zone alla configurazione IP front-end del servizio di bilanciamento del carico interno. Un front-end di zona garantisce un indirizzo IP in una subnet per una zona specifica.

Servizio di bilanciamento del carico non di zona

I servizi di bilanciamento del carico possono essere creati anche in una configurazione non di zona usando un front-end "no-zone". In questi scenari, un servizio di bilanciamento del carico pubblico usa un prefisso IP pubblico o ip pubblico, un servizio di bilanciamento del carico interno userà un indirizzo IP privato. Questa opzione non garantisce la ridondanza.

Nota

Tutti gli indirizzi IP pubblici aggiornati dallo SKU Basic allo SKU Standard saranno di tipo "no-zone". Informazioni su come aggiornare un indirizzo IP pubblico nella portale di Azure.

Miglioramenti del contratto di servizio

Poiché le zone di disponibilità sono fisicamente separate e forniscono fonti di alimentazione, rete e raffreddamento distinte, i contratti di servizio (contratti di servizio) possono aumentare. Per altre informazioni, vedere i contratti di servizio per i servizi online.

Creare una risorsa con la zona di disponibilità abilitata

Per informazioni su come bilanciare il carico delle macchine virtuali all'interno di una zona o su più zone usando un servizio di bilanciamento del carico, vedere Avvio rapido: Creare un servizio di bilanciamento del carico pubblico per bilanciare il carico delle macchine virtuali.

Nota

• Le zone non possono essere modificate, aggiornate o create per la risorsa dopo la creazione.
• Le risorse non possono essere aggiornate da zona a con ridondanza della zona o viceversa dopo la creazione.

Tolleranza di errore

Le macchine virtuali possono eseguire il failover in un altro server in un cluster, con il riavvio del sistema operativo della macchina virtuale nel nuovo server. È consigliabile fare riferimento al processo di failover per il ripristino di emergenza, la raccolta di macchine virtuali nella pianificazione del ripristino e l'esecuzione di esercitazioni sul ripristino di emergenza per assicurarsi che la soluzione di tolleranza di errore sia corretta.

Per altre informazioni, vedere i processi di site recovery.

Esperienza di riduzione della zona

La ridondanza della zona non implica un piano dati o un piano di controllo senza colpi. I flussi con ridondanza della zona possono usare qualsiasi zona e i flussi useranno tutte le zone integre in un'area. In un errore di zona, i flussi di traffico che usano zone integre non sono interessati.

I flussi di traffico che usano un fuso orario di errore possono essere interessati, ma le applicazioni possono eseguire il ripristino. Il traffico continua nelle zone integre all'interno dell'area al momento della ritrasmissione quando Azure è convergente intorno all'errore della zona.

Esaminare i modelli di progettazione cloud di Azure per migliorare la resilienza dell'applicazione in scenari di errore.

Più front-end

L'uso di più front-end consente di bilanciare il carico del traffico su più porte e/o indirizzi IP. Quando si progetta l'architettura, assicurarsi di tenere conto del modo in cui la ridondanza della zona interagisce con più front-end. Se l'obiettivo è quello di avere sempre ogni front-end resiliente all'errore, tutti gli indirizzi IP assegnati come front-end devono essere ridondanti della zona. Se un set di front-end deve essere associato a una singola zona, ogni indirizzo IP per tale set deve essere associato a tale zona specifica. Un servizio di bilanciamento del carico non è necessario in ogni zona. Ogni front-end di zona o set di front-end di zona può invece essere associato alle macchine virtuali nel pool back-end che fanno parte di tale zona di disponibilità specifica.

Cassaforte tecniche di distribuzione

Esaminare i modelli di progettazione cloud di Azure per migliorare la resilienza dell'applicazione in scenari di errore.

Eseguire la migrazione al supporto della zona di disponibilità

Nel caso in cui un'area sia aumentata per avere zone di disponibilità, gli indirizzi IP esistenti rimarranno non di zona come gli INDIRIZZI IP usati per i front-end del servizio di bilanciamento del carico. Per garantire che l'architettura possa sfruttare i vantaggi delle nuove zone, è consigliabile creare un nuovo indirizzo IP front-end. Dopo la creazione, è possibile sostituire il front-end non di zona esistente con un nuovo front-end con ridondanza della zona. Per informazioni su come eseguire la migrazione di una macchina virtuale al supporto della zona di disponibilità, vedere Eseguire la migrazione del servizio di bilanciamento del carico al supporto della zona di disponibilità.

Ripristino di emergenza tra aree e continuità aziendale

Il ripristino di emergenza riguarda il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare alla creazione del piano di ripristino di emergenza, vedere Consigli per la progettazione di una strategia di ripristino di emergenza.

Per quanto riguarda il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello di responsabilità condivisa, Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente è responsabile della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per lo sviluppo del piano di ripristino di emergenza.

Azure Load Balancer Standard supporta il bilanciamento del carico tra aree abilitando scenari di disponibilità elevata con ridondanza geografica, ad esempio:

• Traffico in ingresso proveniente da più aree.
• Failover globale immediato alla successiva distribuzione ottimale a livello di area.
• Distribuzione del carico tra aree nell'area di Azure più vicina con latenza ultra bassa.
• Possibilità di aumentare o ridurre le prestazioni dietro un singolo endpoint.
• Indirizzo IP globale anycast statico
• Conservazione ip client
• Creare una soluzione di bilanciamento del carico esistente senza curva di apprendimento

La configurazione IP front-end del servizio di bilanciamento del carico tra aree è statica e pubblicizzata nella maggior parte delle aree di Azure.

Nota

La porta back-end della regola di bilanciamento del carico nel servizio di bilanciamento del carico tra aree deve corrispondere alla porta front-end della regola di bilanciamento del carico/regola nat in ingresso nel servizio di bilanciamento del carico standard a livello di area.

Ripristino di emergenza nell'area geografica in più aree

Ridondanza a livello di area

Configurare la ridondanza a livello di area collegando facilmente un servizio di bilanciamento del carico tra aree ai servizi di bilanciamento del carico a livello di area esistenti.

Se si verifica un errore in un'area, il traffico viene indirizzato al servizio di bilanciamento del carico a livello di area integro più vicino.

Il probe di integrità del servizio di bilanciamento del carico tra aree raccoglie informazioni sulla disponibilità di ogni servizio di bilanciamento del carico a livello di area ogni 5 secondi. Se un servizio di bilanciamento del carico a livello di area riduce la disponibilità a 0, il servizio di bilanciamento del carico tra aree rileva l'errore. Il servizio di bilanciamento del carico a livello di area viene quindi estratto dalla rotazione.

Latenza ultra bassa

L'algoritmo di bilanciamento del carico di prossimità geografica si basa sulla posizione geografica degli utenti e delle distribuzioni a livello di area.

Il traffico avviato da un client raggiunge l'area più vicina e attraversa il backbone della rete globale Microsoft per arrivare alla distribuzione regionale più vicina.

Ad esempio, si dispone di un servizio di bilanciamento del carico tra aree con servizi di bilanciamento del carico standard nelle aree di Azure:

• Stati Uniti occidentali
• Europa settentrionale

Se un flusso viene avviato da Seattle, il traffico entra negli Stati Uniti occidentali. Questa area è la regione più vicina di Seattle. Il traffico viene instradato al servizio di bilanciamento del carico dell'area più vicino, ovvero Stati Uniti occidentali.

Il servizio di bilanciamento del carico tra aree di Azure usa l'algoritmo di bilanciamento del carico di prossimità geografica per la decisione di routing.

La modalità di distribuzione del carico configurata dei servizi di bilanciamento del carico a livello di area viene usata per prendere la decisione finale di routing quando vengono usati più servizi di bilanciamento del carico a livello di area per la prossimità geografica.

Per altre informazioni, vedere Configurare la modalità di distribuzione per Azure Load Balancer.

Il traffico in uscita segue la preferenza di routing impostata nei servizi di bilanciamento del carico a livello di area.

Possibilità di aumentare o ridurre le prestazioni dietro un singolo endpoint

Quando si espone l'endpoint globale di un servizio di bilanciamento del carico tra aree ai clienti, è possibile aggiungere o rimuovere distribuzioni a livello di area dietro l'endpoint globale senza interruzioni.

Indirizzo IP globale anycast statico

Il servizio di bilanciamento del carico tra aree include un indirizzo IP pubblico statico, che garantisce che l'indirizzo IP rimanga invariato. Per altre informazioni sull'INDIRIZZO IP statico, leggere altre informazioni qui

Conservazione IP client

Il servizio di bilanciamento del carico tra aree è un servizio di bilanciamento del carico di rete di livello 4. Questo pass-through mantiene l'INDIRIZZO IP originale del pacchetto. L'INDIRIZZO IP originale è disponibile per il codice in esecuzione nella macchina virtuale. Questa conservazione consente di applicare la logica specifica di un indirizzo IP.

IP mobile

L'indirizzo IP mobile può essere configurato sia a livello IP globale che a livello di IP a livello di area. Per altre informazioni, vedere Più front-end per Azure Load Balancer

È importante notare che l'indirizzo IP mobile configurato nel servizio di bilanciamento del carico tra aree di Azure funziona indipendentemente dalle configurazioni IP mobili nei servizi di bilanciamento del carico a livello di area back-end. Se l'indirizzo IP mobile è abilitato nel servizio di bilanciamento del carico tra aree, è necessario aggiungere l'interfaccia di loopback appropriata alle macchine virtuali back-end.

Probe di integrità

Load Balancer tra aree di Azure usa l'integrità dei servizi di bilanciamento del carico a livello di area back-end quando si decide dove distribuire il traffico. I controlli di integrità da parte del servizio di bilanciamento del carico tra aree vengono eseguiti automaticamente ogni 5 secondi, dato che un utente ha configurato probe di integrità nel servizio di bilanciamento del carico a livello di area.

Creare una soluzione tra aree in Azure Load Balancer esistente

Il pool back-end del servizio di bilanciamento del carico tra aree contiene uno o più servizi di bilanciamento del carico a livello di area.

Aggiungere le distribuzioni del servizio di bilanciamento del carico esistenti a un servizio di bilanciamento del carico tra aree per una distribuzione multi-area a disponibilità elevata.

L'area principale è la posizione in cui viene distribuito il servizio di bilanciamento del carico tra aree o l'indirizzo IP pubblico del livello globale. Questa area non influisce sul modo in cui viene instradato il traffico. Se un'area domestica diventa inattiva, il flusso del traffico non è interessato.

Aree home

• Stati Uniti centrali
• Asia orientale
• Stati Uniti orientali 2
• Europa settentrionale
• Asia sud-orientale
• Regno Unito meridionale
• US Gov Virginia
• Europa occidentale
• Stati Uniti occidentali

Nota

È possibile distribuire solo il servizio di bilanciamento del carico tra aree o l'indirizzo IP pubblico nel livello globale in una delle aree Home elencate.

Un'area partecipante è la posizione in cui viene annunciato l'indirizzo IP pubblico globale del servizio di bilanciamento del carico.

Il traffico avviato dall'utente passa all'area più vicina che partecipa attraverso la rete principale Microsoft.

Il servizio di bilanciamento del carico tra aree indirizza il traffico al servizio di bilanciamento del carico a livello di area appropriato.

Aree partecipanti

• Australia orientale
• Australia sud-orientale
• India centrale
• Stati Uniti centrali
• Asia orientale
• Stati Uniti orientali
• Stati Uniti orientali 2
• Giappone orientale
• Stati Uniti centro-settentrionali
• Europa settentrionale
• Stati Uniti centro-meridionali
• Asia sud-orientale
• Regno Unito meridionale
• US DoD Central
• US DoD East
• US Gov Arizona
• US Gov Texas
• US Gov Virginia
• Stati Uniti centro-occidentali
• Europa occidentale
• Stati Uniti occidentali
• West US 2

Nota

I servizi di bilanciamento del carico a livello di area back-end possono essere distribuiti in qualsiasi area di Azure disponibile pubblicamente e non si limitano solo alle aree partecipanti.

Limiti

• Le configurazioni IP front-end tra aree sono solo pubbliche. Un front-end interno non è attualmente supportato.

• Non è possibile aggiungere un servizio di bilanciamento del carico privato o interno al pool back-end di un servizio di bilanciamento del carico tra aree

• La traduzione NAT64 non è attualmente supportata. Gli indirizzi IP front-end e back-end devono essere dello stesso tipo (v4 o v6).

• Il traffico UDP non è supportato in Load Balancer tra aree per IPv6.

• Il traffico UDP sulla porta 3 non è supportato in Load Balancer tra aree

• Le regole in uscita non sono supportate in Load Balancer tra aree. Per le connessioni in uscita, usare le regole in uscita nel servizio di bilanciamento del carico a livello di area o nel gateway NAT.

Prezzi e contratto di servizio

Il servizio di bilanciamento del carico tra aree condivide il contratto di servizio di bilanciamento del carico standard.

Passaggi successivi

• Affidabilità in Azure
• Vedere Esercitazione: Creare un servizio di bilanciamento del carico tra aree usando il portale di Azure per creare un servizio di bilanciamento del carico tra aree.
• Altre informazioni sul servizio di bilanciamento del carico tra aree.
• Altre informazioni su Azure Load Balancer.