Gestione del load balancer

Per implementare un load balancer di lavoro, sono necessari gli elementi riportati di seguito.

• Per un load balancer pubblico in un'area con diversi domini di disponibilità , devi disporre di una VCN con una subnet regionale pubblica o almeno due subnet pubbliche specifiche di AD. In quest'ultimo caso, ogni subnet specifica di AD deve risiedere in un dominio di disponibilità separato. Per ulteriori informazioni sulle subnet, vedere Gestione di VCN e subnet e Intervalli di indirizzi IP pubblici.
  Nota
  
  Non è possibile specificare una subnet privata per un load balancer pubblico.
• Per un load balancer pubblico in un'area con un solo dominio di disponibilità, devi disporre di una VCN con almeno una subnet pubblica.
• Per un load balancer privato in qualsiasi area, hai bisogno di una VCN con almeno una subnet privata.
• Due o più server backend (istanze di computazione) che eseguono applicazioni. Per ulteriori informazioni sulle istanze di computazione, vedere Creazione di un'istanza.

Ai fini del controllo dell'accesso, è necessario specificare il compartimento in cui si desidera che risieda il load balancer. Consultare un amministratore dell'organizzazione se non si è certi del compartimento da utilizzare. Per informazioni sui compartimenti e sul controllo dell'accesso, vedere Gestione dei compartimenti.

Quando crei un load balancer all'interno di una VCN, ottieni un indirizzo IP pubblico o privato e la larghezza di banda totale di cui è stato eseguito il provisioning. Se hai bisogno di un altro indirizzo IP, puoi creare un altro load balancer.

Un load balancer privato richiede una sola subnet per ospitare il load balancer primario e un database in standby. L'indirizzo IP privato è locale nella subnet. Il load balancer è accessibile solo dall'interno della VCN che contiene la subnet associata o come ulteriormente limitato dalle regole della lista di sicurezza. Il load balancer può instradare il traffico dati a qualsiasi server backend raggiungibile dalla VCN.

Un load balancer pubblico creato in una subnet regionale pubblica utilizza due indirizzi IPv4 privati dalla subnet host. I load balancer primario e secondario risiedono nella stessa subnet. Ogni load balancer richiede un indirizzo IPv4 privato da tale subnet. Il servizio Load Balancer assegna un indirizzo IPv4 pubblico mobile che non proviene dalla subnet host. Se il load balancer è abilitato per IPv6, riceve un indirizzo IPv6 dalla subnet host.

Un load balancer pubblico creato in due subnet pubbliche specifiche di AD utilizza due indirizzi IP privati, uno di ogni subnet host. I load balancer primario e secondario risiedono all'interno di subnet diverse. Ogni load balancer richiede un indirizzo IP privato dalla propria subnet host. Il servizio Load Balancer assegna un indirizzo IPv4 pubblico mobile che non proviene dalle subnet host. Se il load balancer è abilitato per IPv6, gli viene assegnato un indirizzo IPv6 dalla subnet host.

Un load balancer privato creato in una singola subnet utilizza tre indirizzi IP privati dalla subnet host. I load balancer primario e secondario risiedono nella stessa subnet. Ogni load balancer richiede un indirizzo IP privato da tale subnet. L'indirizzo IP privato mobile proviene anche dalla subnet host. La comunicazione Internet con un load balancer abilitato per IPv6 e creato in una subnet privata è vietata. Non è possibile creare un load balancer abilitato per IPv6 instradabile a livello globale in una subnet privata.

Per un load balancer in esecuzione, alcune modifiche alla configurazione determinano interruzioni del servizio. Le linee guida riportate di seguito consentono di comprendere l'effetto delle modifiche apportate al load balancer.

• Le operazioni che aggiungono, rimuovono o modificano un server backend non creano interruzioni al servizio del load balancer.
• Le operazioni che modificano un criterio di controllo dello stato esistente non creano interruzioni al servizio Load Balancer.
• Le operazioni che attivano la riconfigurazione di un load balancer possono produrre una breve interruzione del servizio con la possibilità di alcune connessioni interrotte.

I load balancer con listener basati su TCP possono utilizzare la funzione del protocollo proxy per inviare indirizzi IP e porte di origine e destinazione ai propri server backend in vari livelli di proxy NAT (Network Address Translation) o TCP. Utilizzare il protocollo proxy per supportare requisiti di rete quali le ACL (Application Security) e la registrazione della conformità.

Quando si seleziona l'opzione di protocollo proxy durante la creazione di un load balancer o l'aggiornamento di un load balancer esistente, viene richiesto di selezionare una delle seguenti opzioni:

• Versione 1: supporta un formato di intestazione (testo) leggibile dall'utente e in genere è una singola riga di una voce di log. Utilizzare questa opzione per eseguire il debug durante la fase di adozione iniziale quando esistono poche implementazioni.

• Versione 2: combina il supporto per l'intestazione leggibile dalla versione 1 con una codifica binaria dell'intestazione per una maggiore efficienza nella produzione e nell'analisi. Questa opzione può essere usata per gli indirizzi IPv6 difficili da generare ed analizzare in formato ASCII. La versione 2 supporta anche le estensioni personalizzate.

Entrambe le versioni implementano il protocollo come un'intestazione parsable che viene posizionata dal responsabile avvio della connessione all'inizio di ogni connessione. Il protocollo non prevede che il mittente attenda il destinatario prima di inviare l'intestazione. Inoltre, non aspetta che il ricevitore rispedisca nulla.

Il protocollo proxy per i load balancer supporta solo l'opzione PP2 Type Authority per il supporto SNI (Server Name Indication) TLS (Transport Layer Security). Questo supporto è utile quando il load balancer interrompe la connessione SSL anziché i server backend. Questa funzionalità è simile all'opzione X-Forwarded-Host per TCP.

Assicurarsi che le applicazioni backend prevedano e possano analizzare l'intestazione del protocollo proxy versione 2 prima di abilitare il protocollo proxy nel load balancer. Per ulteriori informazioni sul protocollo proxy versione 2, visitare il sito Web all'indirizzo HAProxy.

Se si dispone delle autorizzazioni per creare una risorsa, si dispone anche delle autorizzazioni per applicare tag in formato libero a tale risorsa. Per applicare una tag definita, è necessario disporre delle autorizzazioni per utilizzare lo spazio di nomi tag. Per ulteriori informazioni sull'applicazione di tag, vedere Tag risorsa. Se non sei sicuro di applicare i tag, salta questa opzione o chiedi a un amministratore. È possibile applicare le tag in un secondo momento.