Bilanciatori del carico delle applicazioni interni e reti connesse

In questa pagina vengono descritti gli scenari per l'accesso a un bilanciatore del carico interno nella rete VPC (Virtual Private Cloud) da una rete connessa. Prima di esaminare le informazioni in questa pagina, dovresti avere già familiarità con i concetti della seguente guida:

Utilizzo del peering di rete VPC

Quando utilizzi il peering di rete VPC per connettere la tua rete VPC a un'altra rete, Google Cloud condivide le route di subnet tra le reti. Le route di subnet consentono al traffico della rete peer di raggiungere i bilanciatori del carico interni nella tua rete. L'accesso è consentito se si verifica quanto segue:

  • Puoi creare regole firewall in entrata per consentire il traffico dalle VM client nella rete peer. Le regole firewall di Google Cloud non vengono condivise tra le reti quando si utilizza il peering di rete VPC.
  • Per gli Application Load Balancer interni regionali, le istanze di macchine virtuali (VM) client nella rete peer devono trovarsi nella stessa regione del bilanciatore del carico interno. Questa limitazione viene revocata se configuri l'accesso globale.

Non puoi condividere selettivamente solo alcuni bilanciatori del carico di rete passthrough interni, bilanciatori del carico di rete con proxy interno regionale o Application Load Balancer interni utilizzando il peering di rete VPC. Tutti i bilanciatori del carico interni vengono condivisi automaticamente. Puoi limitare l'accesso ai backend del bilanciatore del carico configurando le VM o gli endpoint di backend per il controllo dell'accesso tramite le intestazioni HTTP (ad esempio, X-Forwarded-For).

Utilizza Cloud VPN e Cloud Interconnect

Puoi accedere a un bilanciatore del carico interno da una rete peer connessa tramite un tunnel Cloud VPN o un collegamento VLAN per una connessione Dedicated Interconnect o Partner Interconnect. La rete peer può essere una rete on-premise, un'altra rete VPC Google Cloud o una rete virtuale ospitata da un cloud provider diverso.

Accesso tramite tunnel Cloud VPN

Puoi accedere a un bilanciatore del carico interno tramite un tunnel Cloud VPN quando sono soddisfatte tutte le seguenti condizioni.

Nella rete del bilanciatore del carico interno

  • Sia il gateway che i tunnel Cloud VPN devono trovarsi nella stessa regione del bilanciatore del carico quando l'accesso globale è disabilitato. Se l'accesso globale è abilitato nella regola di forwarding del bilanciatore del carico, questa limitazione viene revocata.
  • Le route devono fornire percorsi di risposta dai sistemi proxy alla rete on-premise o peer in cui si trova il client. Se utilizzi tunnel Cloud VPN con routing dinamico, considera la modalità di routing dinamico della rete Cloud VPN del bilanciatore del carico. La modalità di routing dinamico determina quali route dinamiche personalizzate sono disponibili per i proxy nella subnet solo proxy.

Nella rete peer

La rete peer deve avere almeno un tunnel Cloud VPN con route alla subnet in cui è definito il bilanciatore del carico interno.

Se la rete peer è un'altra rete VPC di Google Cloud:

  • Il gateway e i tunnel Cloud VPN della rete peer possono trovarsi in qualsiasi regione.

  • Per i tunnel Cloud VPN che utilizzano il routing dinamico, la modalità di routing dinamico della rete VPC determina quali route sono disponibili per i client in ogni regione. Per fornire un set coerente di route dinamiche personalizzate ai client in tutte le regioni, utilizza la modalità di routing dinamico globale.

  • Assicurati che i firewall di rete on-premise o peer consentano i pacchetti inviati all'indirizzo IP della regola di forwarding del bilanciatore del carico. Assicurati che i firewall di rete on-premise o peer consentano i pacchetti di risposta ricevuti dall'indirizzo IP della regola di forwarding del bilanciatore del carico.

Il seguente diagramma evidenzia i concetti chiave dell'accesso a un bilanciatore del carico interno tramite un gateway Cloud VPN e il tunnel associato. Cloud VPN connette in modo sicuro la rete on-premise alla rete VPC di Google Cloud utilizzando i tunnel Cloud VPN.

Bilanciamento del carico interno e Cloud VPN.
Bilanciamento del carico interno e Cloud VPN (fai clic per ingrandire).

Tieni presente i seguenti elementi di configurazione associati a questo esempio:

  • In lb-network è stato configurato un tunnel Cloud VPN che utilizza il routing dinamico. Il tunnel VPN, il gateway e il router Cloud si trovano tutti in REGION_A, la stessa regione in cui si trovano i componenti del bilanciatore del carico interno.
  • Le regole firewall di autorizzazione in entrata sono state configurate per essere applicate alle VM di backend nei gruppi di istanze A e B, in modo che possano ricevere il traffico dagli indirizzi IP nella rete VPC e dalla rete on-premise, 10.1.2.0/24 e 192.168.1.0/24. Non sono state create regole firewall di negazione in uscita, pertanto si applica la regola di autorizzazione in uscita implicita.
  • I pacchetti inviati dai client nelle reti on-premise, tra cui 192.168.1.0/24, all'indirizzo IP del bilanciatore del carico interno, 10.1.2.99, vengono recapitati direttamente a una VM di backend integro, ad esempio vm-a2, in base all'affinità sessione configurata.
  • Le risposte inviate dalle VM di backend (ad esempio vm-a2) vengono consegnate ai client on-premise attraverso il tunnel VPN.

Per risolvere i problemi di Cloud VPN, consulta la pagina relativa alla risoluzione dei problemi di Cloud VPN.

Accesso tramite Cloud Interconnect

Puoi accedere a un bilanciatore del carico interno da una rete peer on-premise connessa alla rete VPC del bilanciatore del carico quando tutte le seguenti condizioni sono soddisfatte nella rete del bilanciatore del carico interno:

  • Sia il collegamento VLAN sia il router Cloud devono trovarsi nella stessa regione del bilanciatore del carico quando l'accesso globale è disabilitato. Se l'accesso globale è abilitato nella regola di forwarding del bilanciatore del carico, questa limitazione viene rimossa.

  • I router on-premise devono fornire percorsi di risposta dai backend del bilanciatore del carico alla rete on-premise. I collegamenti VLAN sia per Dedicated Interconnect che per Partner Interconnect devono utilizzare router Cloud. Di conseguenza, le route dinamiche personalizzate forniscono percorsi di risposta. L'insieme di route dinamiche personalizzate che apprendo dipende dalla modalità di routing dinamico della rete del bilanciatore del carico.

  • Assicurati che i firewall on-premise consentano i pacchetti inviati all'indirizzo IP della regola di forwarding del bilanciatore del carico. Assicurati che i firewall on-premise consentano i pacchetti di risposta ricevuti dall'indirizzo IP della regola di forwarding del bilanciatore del carico.

Utilizza l'accesso globale con Cloud VPN e Cloud Interconnect

Per impostazione predefinita, i client devono trovarsi nella stessa rete o in una rete VPC connessa tramite il peering di rete VPC. Puoi abilitare l'accesso globale per consentire ai client di qualsiasi regione di accedere al tuo bilanciatore del carico.

Quando abiliti l'accesso globale, le seguenti risorse possono trovarsi in qualsiasi regione:
  • Router Cloud
  • Gateway e tunnel Cloud VPN
  • Collegamenti VLAN

Nel diagramma:

  • Il frontend e i backend del bilanciatore del carico si trovano nella regione REGION_A.
  • Il router Cloud si trova nella regione REGION_B.
  • Il router Cloud è in peering con il router VPN on-premise.
  • La sessione di peering BGP (Border Gateway Protocol) può avvenire tramite Cloud VPN o Cloud Interconnect con peering diretto o Partner Interconnect.
Bilanciamento del carico interno con accesso globale.
Bilanciamento del carico interno con accesso globale (fai clic per ingrandire).

La modalità di routing dinamico della rete VPC è impostata su global per consentire al router Cloud in REGION_B di pubblicizzare le route di subnet per le subnet in qualsiasi regione della rete VPC del bilanciatore del carico.

Più percorsi in uscita

Negli ambienti di produzione, conviene utilizzare più tunnel Cloud VPN o collegamenti VLAN per la ridondanza. Questa sezione illustra i requisiti quando si utilizzano più tunnel o collegamenti VLAN.

Nel diagramma seguente, due tunnel Cloud VPN connettono lb-network a una rete on-premise. Anche se qui vengono utilizzati i tunnel Cloud VPN, a Cloud Interconnect si applicano gli stessi principi.

Bilanciamento del carico interno e più tunnel Cloud VPN.
Bilanciamento del carico interno e più tunnel Cloud VPN (fai clic per ingrandire).

Devi configurare ogni tunnel o ciascun collegamento VLAN nella stessa regione del bilanciatore del carico interno. Questo requisito viene rimosso se hai abilitato l'accesso globale.

Più tunnel o collegamenti VLAN possono fornire una larghezza di banda aggiuntiva o fungere da percorsi di standby per la ridondanza.

Tieni presente quanto segue:

  • Se la rete on-premise ha due route con le stesse priorità, ciascuna con una destinazione 10.1.2.0/24 e un hop successivo corrispondente a un tunnel VPN diverso nella stessa regione del bilanciatore del carico interno, il traffico può essere inviato dalla rete on-premise (192.168.1.0/24) al bilanciatore del carico utilizzando equal-cost multipath (ECMP).
  • Dopo che i pacchetti sono stati consegnati alla rete VPC, il bilanciatore del carico interno li distribuisce nelle VM di backend in base all'affinità sessione configurata.
  • Se lb-network ha due route, ciascuna con la destinazione 192.168.1.0/24 e un hop successivo corrispondente a diversi tunnel VPN, le risposte delle VM di backend possono essere inviate su ciascun tunnel in base alla priorità delle route nella rete. Se vengono utilizzate priorità di route diverse, un tunnel può fungere da backup per l'altro. Se vengono utilizzate le stesse priorità, le risposte vengono fornite tramite ECMP.
  • Le risposte inviate dalle VM di backend (ad esempio vm-a2) vengono consegnate direttamente ai client on-premise attraverso il tunnel appropriato. Dal punto di vista di lb-network, se le route o i tunnel VPN cambiano, il traffico potrebbe uscire utilizzando un tunnel diverso. Ciò potrebbe comportare la reimpostazione della sessione TCP in caso di interruzione di una connessione in corso.

Passaggi successivi