Condividi tramite

Affidabilità in Load Balancer

  • Articolo

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 sull'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 i requisiti di disponibilità e ripristino, i test, il monitoraggio, la 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:

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

Riepilogo delle raccomandazioni per l'affidabilità

Categoria 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 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 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 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 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 costituite da almeno tre gruppi fisicamente separati di data center all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di alimentazione, raffreddamento e infrastruttura di rete indipendenti. Le zone di disponibilità sono progettate in modo che, in caso di errore in una zona locale, i servizi regionali, la capacità e la disponibilità elevata della zona interessata siano supportati dalle altre due zone.

Gli errori possono essere di tipo hardware o software oppure correlati a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori viene conseguita mediante la ridondanza e l'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à sono progettati per fornire il livello adeguato di affidabilità e flessibilità. Tali servizi possono essere configurati in due modi. Possono essere con ridondanza della zona, che prevede la replica automatica tra le zone, o a zona, con istanze aggiunte in una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sulle architetture a zona e con ridondanza della zona, vedere Raccomandazioni per l'uso delle zone e delle 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 bilanciamento del carico è sinonimo della selezione della zona dell'IP front-end. Per il bilanciamento del carico pubblico, se l'indirizzo IP pubblico nel front-end del bilanciamento del carico ha una ridondanza della zona, anche il bilanciamento del carico ha una ridondanza della zona. Se l'indirizzo IP pubblico nel front-end del bilanciamento del carico è di zona, anche il bilanciamento del carico viene destinato alla stessa zona. Per configurare le proprietà correlate alla zona per il 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 una risorsa dopo la creazione.
  • Le risorse non possono essere aggiornate da tipologie di zona a tipologie con ridondanza della zona o vice versa 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. Una zona di disponibilità può avere esito negativo e il percorso dati non risente degli errori finché una zona dell'area rimane integra.

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.

Figura che illustra un servizio di bilanciamento del carico standard con ridondanza della zona che indirizza il traffico in tre zone diverse a tre subnet diverse in una configurazione con ridondanza della 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 bilanciamento del carico sono in genere associati a una singola zona, ad esempio a 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 dalle zone 1, 2 e 3 nel back-end di un 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 per una singola zona, noto come front-end di 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. Gli endpoint pubblici possono essere integrati con un prodotto di bilanciamento del carico DNS come Gestione traffico e usare un singolo nome DNS.

Figura che illustra tre servizi di bilanciamento del carico standard di zona ognuno che indirizza il traffico in una zona a tre subnet diverse in una configurazione di zona.

Per un front-end di bilanciamento del carico pubblico, è necessario 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 di bilanciamento del carico interno, è necessario aggiungere un parametro zone alla configurazione IP front-end del servizio di bilanciamento del carico. 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 Load Balancer possono essere creati anche in una configurazione non di zona usando un front-end "non di zona". In questi scenari, un bilanciamento del carico pubblico usa un prefisso IP pubblico o un IP pubblico, mentre un bilanciamento del carico interno usa un indirizzo IP privato. Questa opzione non garantisce la ridondanza.

Nota

Tutti gli indirizzi IP pubblici aggiornati da SKU Basic a SKU Standard saranno di tipo "non di zona". Informazioni su come Aggiornare un indirizzo IP pubblico nel 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 zone di disponibilità abilitate

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 una risorsa dopo la creazione.
  • Le risorse non possono essere aggiornate da tipologie di zona a tipologie con ridondanza della zona o vice versa 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 inattività della zona

La ridondanza della zona non implica un piano dati o un piano di controllo privo di passaggi. I flussi con ridondanza della zona possono usare qualsiasi zona e i flussi di un cliente useranno tutte le zone integre in un'area. I flussi di traffico che usano zone integre non sono interessati dagli errori di una zona.

I flussi di traffico che usano una zona al momento di un errore di zona possono essere interessati, ma le applicazioni possono essere ripristinate. Il traffico continua nelle zone integre all'interno dell'area al momento della ritrasmissione una volta completata la convergenza intorno alla zona di errore da parte di Azure.

Esaminare gli schemi progettuali su 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 con ridondanza 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. Non è necessario un bilanciamento del carico in ogni zona. Al contrario, ogni front-end di zona o set di front-end di zona può invece essere associato alle macchine virtuali nel pool back-end che fa parte di tale zona di disponibilità specifica.

Tecniche di distribuzione sicura

Esaminare gli schemi progettuali su 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 ampliata per avere zone di disponibilità, gli indirizzi IP esistenti rimarranno non di zona come gli indirizzi IP usati per i front-end del 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 e continuità aziendale tra aree

Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri 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 a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.

Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per tali servizi, l'utente ha la responsabilità di configurare un piano di ripristino di emergenza che funzioni per i propri carichi di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il 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:

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

Diagramma del servizio di bilanciamento del carico tra aree.

Nota

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

Ripristino di emergenza nella geografia in più aree

Ridondanza a livello di area

Configurare la ridondanza a livello di area collegando facilmente un bilanciamento del carico tra aree ai bilanciamenti 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 bilanciamento del carico tra aree raccoglie informazioni sulla disponibilità di ogni bilanciamento del carico a livello di area ogni 5 secondi. Se un bilanciamento del carico a livello di area riduce la disponibilità a 0, il bilanciamento del carico tra aree rileva l'errore. Il bilanciamento del carico a livello di area viene quindi estratto dalla rotazione.

Diagramma della visualizzazione del traffico dell'area globale.

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 bilanciamento del carico tra aree con bilanciamenti 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 più vicina da Seattle. Il traffico viene instradato al bilanciamento del carico dell'area più vicino, ovvero Stati Uniti occidentali.

Il 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 bilanciamenti del carico a livello di area viene usata per prendere la decisione finale di routing quando vengono usati più bilanciamenti 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 bilanciamenti del carico a livello di area.

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

Quando si espone l'endpoint globale di un 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 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 bilanciamento del carico tra aree è un bilanciamento del carico di rete pass-through 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 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 bilanciamenti del carico a livello di area back-end quando si decide dove distribuire il traffico. I controlli di integrità da parte del bilanciamento del carico tra aree vengono eseguiti automaticamente ogni 5 secondi, se un utente ha configurato probe di integrità nel bilanciamento del carico a livello di area.

Creare una soluzione tra aree in Azure Load Balancer esistente

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

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

Larea principale è la posizione in cui viene distribuito il 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 principale 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 bilanciamento del carico tra aree o l'indirizzo IP pubblico nel livello globale in una delle aree principali elencate.

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

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

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

Diagramma del traffico globale di più aree.

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 bilanciamenti 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 bilanciamento del carico privato o interno al pool back-end di un 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 regole in uscita nel bilanciamento del carico a livello di area o gateway NAT.

Prezzi e contratto di servizio

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

Passaggi successivi