Più front-end per Azure Load Balancer
Azure Load Balancer consente di eseguire il bilanciamento del carico dei servizi su più porte, più indirizzi IP o entrambi. È possibile usare un servizio di bilanciamento del carico pubblico o interno per bilanciare il carico del traffico tra un set di servizi, ad esempio set di scalabilità di macchine virtuali o macchine virtuali.
Questo articolo descrive i concetti fondamentali del bilanciamento del carico tra più indirizzi IP usando la stessa porta e lo stesso protocollo. Se si intende esporre i servizi in un solo indirizzo IP, sono disponibili istruzioni semplificate per le configurazioni di servizi di bilanciamento del carico pubblici o interni. L'aggiunta di più front-end è un'operazione incrementale rispetto a una configurazione con un solo front-end. Usando i concetti illustrati in questo articolo è possibile espandere una configurazione semplificata in qualsiasi momento.
Quando si definisce un'istanza di Azure Load Balancer, viene connessa una configurazione di pool front-end e back-end con una regola di bilanciamento del carico. Il probe di integrità a cui fa riferimento la regola di bilanciamento del carico viene usato per determinare l'integrità di una macchina virtuale in una porta e un protocollo specifici. In base ai risultati del probe di integrità, vengono inviati nuovi flussi vengono alle macchine virtuali nel pool back-end. Il front-end è definito da una tupla di 3 elementi costituita da un indirizzo IP (pubblico o interno), un protocollo di trasporto (UDP o TCP) e un numero di porta della regola di bilanciamento del carico. Il pool back-end è una raccolta di configurazioni IP di macchine virtuali (parte della risorsa NIC) cui fa riferimento il pool back-end di bilanciamento del carico.
La tabella seguente contiene alcune configurazioni front-end di esempio:
Front-end | Indirizzo IP | protocollo | port |
---|---|---|---|
1 | 65.52.0.1 | TCP | 80 |
2 | 65.52.0.1 | TCP | 8080 |
3 | 65.52.0.1 | UDP | 80 |
4 | 65.52.0.2 | TCP | 80 |
La tabella descrive quattro configurazioni di front-end diverse. I front-end 1, 2 e 3 usano lo stesso indirizzo IP, ma la porta o il protocollo sono diversi per ogni front-end. I front-end 1 e 4 sono un esempio di più front-end, in cui lo stesso protocollo e la stessa porta front-end vengono riutilizzati in più indirizzi IP front-end.
Azure Load Balancer offre flessibilità nella definizione di regole del servizio di bilanciamento del carico. Una regola di bilanciamento del carico dichiara il modo in cui viene eseguito il mapping di un indirizzo e una porta nel front-end all'indirizzo e alla porta di destinazione nel back-end. L'eventuale riutilizzo delle porte back-end tra regole dipende dal tipo di regola. Ogni tipo di regola presenta requisiti specifici che possono influire sulla configurazione degli host e la progettazione dei probe. Esistono due tipi di regole:
- Regola predefinita senza riutilizzo delle porte back-end.
- Regola con indirizzo IP mobile che prevede il riutilizzo delle porte back-end.
Azure Load Balancer consente di combinare i due tipi di regole nella stessa configurazione del servizio di bilanciamento del carico. Il servizio di bilanciamento del carico può usare le regole contemporaneamente per una determinata macchina virtuale o una qualsiasi combinazione, purché siano rispettati i vincoli della regola. Il tipo di regola scelto dipende dai requisiti dell'applicazione e dalla complessità correlata al supporto della configurazione. È necessario valutare quali tipi di regole siano più adatti allo scenario. Questi scenari verranno approfonditi iniziando con il comportamento predefinito.
Regola di tipo 1: nessun riutilizzo delle porte back-end
In questo scenario i front-end sono configurati nel modo seguente:
Front-end | Indirizzo IP | protocollo | port |
---|---|---|---|
1 | 65.52.0.1 | TCP | 80 |
2 | 65.52.0.2 | TCP | 80 |
L'indirizzo IP dell'istanza back-end (BIP) è l'indirizzo IP del servizio back-end nel pool back-end e ogni macchina virtuale espone il servizio desiderato su una porta univoca nell'indirizzo IP dell'istanza back-end. Questo servizio è associato all'indirizzo IP front-end (FIP) tramite una definizione di regole.
Si definiscono due regole:
Regola | Mapping frontend | Al pool back-end |
---|---|---|
1 | FIP1:80 | BIP1:80, BIP2:80 |
2 | FIP2:80 | BIP1:81, BIP2:81 |
Il mapping completo in Azure Load Balancer sarà ora il seguente:
Regola | Indirizzo IP front-end IP | protocollo | port | Destinazione | port |
---|---|---|---|---|---|
1 | 65.52.0.1 | TCP | 80 | Indirizzo IP BIP | 80 |
2 | 65.52.0.2 | TCP | 80 | Indirizzo IP BIP | 81 |
Ogni regola deve produrre un flusso con una combinazione univoca di indirizzo IP di destinazione e porta di destinazione. Più regole di bilanciamento del carico possono recapitare flussi allo stesso indirizzo IP dell'istanza back-end su porte diverse variando la porta di destinazione del flusso.
I probe di integrità vengono sempre indirizzati all'indirizzo IP dell'istanza back-end di una macchina virtuale. È necessario assicurarsi che il probe rifletta l'integrità della macchina virtuale.
Regola di tipo 2: riutilizzo delle porte back-end tramite indirizzo IP mobile
Azure Load Balancer offre la flessibilità necessaria per riutilizzare la porta front-end tra più configurazioni front-end. Alcuni scenari di applicazione preferiscono o richiedono l'uso della stessa porta da parte di più istanze dell'applicazione in una singola macchina virtuale nel pool back-end. Esempi comuni di riutilizzo delle porte includono il clustering per la disponibilità elevata, le appliance virtuali di rete e l'esposizione di più endpoint TLS senza rieseguire la crittografia di rete.
Per riutilizzare la porta di back-end tra più regole, è necessario abilitare l'indirizzo IP mobile nella definizione della regola di bilanciamento del carico.
Il termine IP mobile appartiene alla terminologia di Azure e fa riferimento a una parte della cosiddetta configurazione Direct Server Return (DSR). Il DSR è costituito da due parti: una topologia di flussi e uno schema di mappatura degli indirizzi IP. A livello di piattaforma, Azure Load Balancer viene sempre eseguito in una topologia di flussi DSR indipendentemente dal fatto che l'indirizzo IP mobile sia abilitato o meno. Ciò significa che la parte in uscita di un flusso viene sempre correttamente riscritta in un flusso direttamente nell'origine.
Con il tipo di regola predefinito, Azure espone uno schema di mappatura degli indirizzi IP tradizionale per il servizio di bilanciamento del carico per semplificarne l'uso. L'abilitazione dell'indirizzo IP mobile modifica lo schema di mapping degli indirizzi IP per consentire una maggiore flessibilità.
Per questo scenario, ogni macchina virtuale nel pool back-end ha tre interfacce di rete:
- Indirizzo IP back-end: scheda di interfaccia di rete virtuale associata alla macchina virtuale (configurazione IP della risorsa interfaccia di rete di Azure).
- Front-end 1 (FIP1): interfaccia di loopback all'interno del sistema operativo guest configurato con l'indirizzo IP di FIP1.
- Front-end 2 (FIP2): interfaccia di loopback all'interno del sistema operativo guest configurato con l'indirizzo IP di FIP2.
Si supponga la stessa configurazione front-end dello scenario precedente:
Front-end | Indirizzo IP | protocollo | port |
---|---|---|---|
1 | 65.52.0.1 | TCP | 80 |
2 | 65.52.0.2 | TCP | 80 |
Vengono definite due regole per l'indirizzo IP mobile:
Regola | Front-end | Mapping al pool back-end |
---|---|---|
1 | FIP1:80 | FIP1:80 (in VM1 e VM2) |
2 | FIP2:80 | FIP2:80 (in VM1 e VM2) |
La tabella seguente illustra il mapping completo nel servizio di bilanciamento del carico:
Regola | Indirizzo IP front-end IP | protocollo | port | Destinazione | port |
---|---|---|---|---|---|
1 | 65.52.0.1 | TCP | 80 | uguale a front-end (65.52.0.1) | uguale a front-end (80) |
2 | 65.52.0.2 | TCP | 80 | uguale a front-end (65.52.0.2) | uguale a front-end (80) |
La destinazione del flusso in ingresso è ora l'indirizzo IP del front-end nell'interfaccia di loopback della macchina virtuale. Ogni regola deve produrre un flusso con una combinazione univoca di indirizzo IP di destinazione e porta di destinazione. Modificando l'indirizzo IP di destinazione del flusso, è possibile riutilizzare la porta nella stessa macchina virtuale. Il servizio viene esposto al servizio di bilanciamento del carico associandolo all'indirizzo IP del front-end e alla porta dell'interfaccia di loopback corrispondente.
Si noti che nell'esempio la porta di destinazione non cambia. Negli scenari con indirizzo IP mobile, Azure Load Balancer supporta anche la definizione di una regola di bilanciamento del carico per modificare la porta di destinazione back-end e per differenziarla dalla porta di destinazione front-end.
Il tipo di regola con indirizzo IP mobile è alla base di diversi modelli di configurazione del servizio di bilanciamento di carico. Un esempio attualmente disponibile è la configurazione Configurare uno o più listener del gruppo di disponibilità AlwaysOn. Altri scenari di questo tipo verranno documentati nel tempo.
Nota
Per informazioni più dettagliate sulle configurazioni specifiche del sistema operativo guest necessarie per abilitare l'indirizzo IP mobile, vedere Configurazione IP mobile di Azure Load Balancer.
Limiti
- Le configurazioni di più front-end sono supportate solo con le macchine virtuali e i set di scalabilità di macchine virtuali IaaS.
- Con la regola dell'indirizzo IP mobile, l'applicazione deve usare la configurazione IP primaria per i flussi SNAT in uscita. Se l'applicazione viene associata all'indirizzo IP front-end configurato nell'interfaccia di loopback del sistema operativo guest, il flusso SNAT di Azure non potrà riscrivere il flusso in uscita e il flusso avrà esito negativo. Esaminare gli scenari in uscita.
- L'indirizzo IP mobile non è attualmente supportato nelle configurazioni IP secondarie.
- Gli indirizzi IP pubblici hanno un effetto sulla fatturazione. Per altre informazioni, vedere Prezzi per gli indirizzi IP
- Si applicano i limiti delle sottoscrizioni. Per altre informazioni, vedere i limiti del servizio .
Passaggi successivi
- Verificare le connessioni in uscita per comprendere l'impatto di più server front-end sul comportamento delle connessioni in uscita.