Bilanciatori del carico di rete passthrough interni come hop successivi

Un bilanciatore del carico di rete passthrough interno è un bilanciatore del carico regionale che ti consente di eseguire e scalare i servizi dietro un indirizzo IP interno. Puoi utilizzare un bilanciatore del carico di rete passthrough interno come hop successivo a cui i pacchetti vengono inoltrati lungo il percorso verso la loro destinazione finale. Per farlo, imposta il bilanciatore del carico come hop successivo in una route statica personalizzata.

Prima di esaminare le informazioni in questa pagina, dovresti conoscere già i seguenti concetti:

• Panoramica delle route
• Panoramica del bilanciatore del carico di rete passthrough interno

Un hop successivo del bilanciatore del carico di rete passthrough interno è utile nei seguenti casi:

• Per bilanciare il carico del traffico tra più VM che funzionano come VM gateway o router.

• Utilizzare le appliance virtuali del gateway come hop successivo per una route predefinita. Con questa configurazione, le istanze di macchine virtuali (VM) nella rete Virtual Private Cloud (VPC) inviano il traffico a internet attraverso un insieme di VM gateway virtuali con bilanciamento del carico.

• Per inviare il traffico attraverso più bilanciatori del carico in due o più direzioni utilizzando lo stesso set di VM router o gateway multi-NIC dei backend. Per farlo, puoi creare un bilanciatore del carico e utilizzarlo come hop successivo per una route statica personalizzata in ogni rete VPC. Ogni bilanciatore del carico di rete passthrough interno opera all'interno di una singola rete VPC, distribuendo il traffico alle interfacce di rete delle VM di backend in quella rete.

Nota: questa funzionalità non supporta gli indirizzi IPv6.

Architettura

Nel diagramma seguente, un gruppo di istanze VM di VM router funge da backend per due bilanciatori del carico diversi. Il primo bilanciatore del carico di rete passthrough interno invia pacchetti a nic0 delle VM di backend, mentre il secondo bilanciatore del carico di rete passthrough interno invia i pacchetti a nic1 sugli stessi backend.

Bilanciamento del carico su più NIC (fai clic per ingrandire).

Vantaggi dell'utilizzo del bilanciatore del carico di rete passthrough interno come hop successivo

Quando il bilanciatore del carico è l'hop successivo per una route statica, non è necessaria alcuna configurazione speciale all'interno dei sistemi operativi guest delle VM client nella rete VPC in cui è definita la route. Le VM client inviano i pacchetti ai backend del bilanciatore del carico attraverso il routing di rete VPC, in modo da bump-in-the-wire.

L'utilizzo di un bilanciatore del carico di rete passthrough interno come hop successivo per una route statica offre gli stessi vantaggi di un bilanciatore del carico di rete passthrough interno autonomo. Il controllo di integrità del bilanciatore del carico garantisce che le nuove connessioni vengano instradate a VM di backend in stato integro. Utilizzando un gruppo di istanze gestite come backend, puoi configurare la scalabilità automatica per aumentare o ridurre il set di VM in base alla domanda del servizio.

Specifiche

Di seguito sono riportate le specifiche per l'utilizzo di bilanciatori del carico di rete passthrough interni come hop successivi.

Route

Puoi creare una route statica personalizzata per passare TCP, UDP e altro traffico di protocolli a un bilanciatore del carico di rete passthrough interno, dove il bilanciatore del carico è l'hop successivo per la route statica. La route può essere un prefisso CIDR esterno (instradabile pubblicamente) o un prefisso CIDR interno, se non è in conflitto con una route subnet. Ad esempio, puoi sostituire la route predefinita (0.0.0.0/0) con una route che indirizza il traffico alle VM di backend di terze parti per l'elaborazione dei pacchetti.

Attenzione: quando invii il traffico alle API e ai servizi Google, non instradare il traffico attraverso una VM dell'hop successivo o attraverso un bilanciatore del carico di rete passthrough interno dell'hop successivo. In alternativa, instrada questo traffico attraverso un gateway internet predefinito dell'hop successivo. Questo include il traffico alle API e ai servizi Google inviati tramite l'accesso privato Google.

Opzioni per specificare l'hop successivo

Puoi specificare l'hop successivo del bilanciatore del carico di rete passthrough interno in uno dei due modi seguenti:

• utilizzando il nome e la regione della regola di forwarding
• utilizzando l'indirizzo IP della regola di forwarding

Per maggiori dettagli sul progetto e sulla rete VPC in cui può risiedere un hop successivo di un bilanciatore del carico di rete passthrough interno, consulta Hop e funzionalità successivi.

Puoi scambiare route statiche con hop successivi del bilanciatore del carico di rete passthrough interno utilizzando il peering di rete VPC. Per maggiori dettagli, vedi Opzioni per lo scambio di percorsi statici.

Nota: un bilanciatore del carico la cui regola di forwarding utilizza il protocollo L3_DEFAULT non può essere l'hop successivo per una route statica. Se viene creata questa route statica, il traffico viene interrotto automaticamente.

Affinità sessione IP client

I bilanciatori del carico di rete passthrough interni offrono due opzioni di affinità della sessione di "indirizzo IP client" simili:

• IP client (CLIENT_IP): un hash a due tuple dell'indirizzo IP di origine e dell'indirizzo IP di destinazione di un pacchetto. Quando un bilanciatore del carico di rete passthrough interno non è l'hop successivo di una route, i pacchetti inviati all'indirizzo IP della regola di forwarding del bilanciatore del carico condividono un indirizzo IP di destinazione comune, ovvero l'indirizzo IP della regola di forwarding. In questa situazione, uno degli indirizzi utilizzati dall'hash a due tuple rimane costante. Pertanto, se il numero di backend configurati e integri non cambia e i pacchetti hanno indirizzi IP di origine identici, questa opzione di affinità sessione a due tuple seleziona lo stesso backend.
• IP client, nessuna destinazione (CLIENT_IP_NO_DESTINATION): un hash a una tuple dell'indirizzo IP di origine di un pacchetto. Quando utilizzi un bilanciatore del carico di rete passthrough interno come hop successivo, l'indirizzo IP di destinazione spesso varia perché gli indirizzi IP di destinazione sono quelli specificati dall'attributo di destinazione della route. In questo caso, l'affinità sessione IP client (CLIENT_IP) dell'hash a due tuple non può selezionare lo stesso backend anche se il numero di backend configurati e integri non cambia e i pacchetti hanno indirizzi IP di origine identici. (Un'eccezione a questa regola si verifica quando è configurato un solo backend). Se richiedi che i pacchetti con indirizzi IP di origine identici vengano instradati allo stesso backend, devi utilizzare l'opzione di affinità sessione IP client, nessuna destinazione (CLIENT_IP_NO_DESTINATION).

Intervallo di destinazione

La destinazione di una route statica personalizzata non può essere uguale o più specifica di una route di subnet. Tieni presente che più specifica significa che la subnet mask è più lunga. Questa regola si applica a tutte le route statiche personalizzate, incluso quando l'hop successivo è un bilanciatore del carico di rete passthrough interno. Ad esempio, supponiamo che la route della subnet sia 10.140.0.0/20. La destinazione di una route statica personalizzata non può essere la stessa (10.140.0.0/20) e non può essere più specifica, come in 10.140.0.0/22.

Stessa rete VPC e regione

Le route statiche personalizzate che utilizzano bilanciatori del carico di rete passthrough interni come hop successivi sono limitate a quanto segue:

• Una singola rete VPC. Il bilanciatore del carico e la route statica personalizzata devono trovarsi nella stessa rete VPC.

• Una o tutte le regioni. A meno che non configuri l'accesso globale, la route statica personalizzata è disponibile solo per le risorse nella stessa regione del bilanciatore del carico. Questa limitazione a livello di regione viene applicata anche se la route stessa fa parte della tabella di routing per l'intera rete VPC. Se abiliti l'accesso globale, la route statica personalizzata è disponibile per le risorse in qualsiasi regione.

Pubblicizzazione della route statica personalizzata

Per pubblicizzare il prefisso (destinazione) per la route statica personalizzata, puoi utilizzare una pubblicità personalizzata del router Cloud. L'ambito della annuncio di route dipende dall'impostazione di accesso globale del bilanciatore del carico, come segue:

• Se l'accesso globale è disabilitato, il bilanciatore del carico di rete passthrough interno è disponibile solo per VM, tunnel Cloud VPN e collegamenti Cloud Interconnect (VLAN) che si trovano nella stessa regione del bilanciatore del carico. Di conseguenza, un annuncio di route personalizzata per il prefisso di una route statica personalizzata ha senso solo se il router Cloud e il bilanciatore del carico si trovano nella stessa regione.

• Se l'accesso globale è abilitato, il bilanciatore del carico di rete passthrough interno è disponibile per le VM, i tunnel Cloud VPN e i collegamenti Cloud Interconnect (VLAN) che si trovano in qualsiasi regione. Con il routing dinamico globale, i sistemi on-premise possono utilizzare la route statica personalizzata da qualsiasi regione connessa.

La tabella seguente riassume l'accessibilità del bilanciatore del carico.

Accesso globale	Modalità di routing dinamico della rete VPC	Accesso al bilanciatore del carico
Disabilitato	Regionale	Accessibile da router nella stessa regione
Disabilitato	Globale	Accessibile da router nella stessa regione
Abilitato	Regionale	Accessibile da tutti i router in qualsiasi regione
Abilitato	Globale	Accessibile da tutti i router in qualsiasi regione

Per ulteriori informazioni, consulta Bilanciatori del carico di rete passthrough interni e reti connesse.

Ordine delle operazioni

Devi creare un bilanciatore del carico di rete passthrough interno prima di poter creare una route statica personalizzata che lo utilizzi come hop successivo. Il bilanciatore del carico deve esistere prima di poter creare la route. Se provi a creare una route che fa riferimento a un bilanciatore del carico inesistente, Google Cloud restituisce un errore.

Puoi specificare un hop successivo del bilanciatore del carico di rete passthrough interno utilizzando il nome della regola di forwarding e la regione del bilanciatore del carico oppure l'indirizzo IP interno associato alla regola di forwarding.

Dopo aver creato una route con un hop successivo che fa riferimento a un bilanciatore del carico di rete passthrough interno, non puoi eliminare il bilanciatore del carico se prima non elimini la route. In particolare, non puoi eliminare una regola di forwarding interno finché nessuna route statica personalizzata non utilizza il bilanciatore del carico come hop successivo.

Requisiti di backend

• Devi configurare tutte le VM di backend del bilanciatore del carico di rete passthrough interno per consentire l'inoltro IP (--can-ip-forward = True). Per ulteriori informazioni, consulta Considerazioni per il routing basato su istanze o bilanciatore del carico.

• Non puoi utilizzare un bilanciatore del carico di rete passthrough interno i cui backend sono nodi Google Kubernetes Engine (GKE) come hop successivo per una route statica personalizzata. Il software sui nodi può instradare il traffico ai pod solo se la destinazione corrisponde a un indirizzo IP gestito dal cluster, non a una destinazione arbitraria.

Elaborazione di traffico TCP, UDP e di altro protocollo

Importante: le informazioni in questa sezione si applicano solo alle route personalizzate create prima del 15 maggio 2021.

Se prima del 15 maggio 2021 è stato creato un bilanciatore del carico di rete passthrough interno come route dell'hop successivo, il bilanciatore del carico inoltra solo il traffico TCP e UDP su tutte le porte alle VM di backend, indipendentemente dalla regola di forwarding o dalla configurazione del servizio di backend. Tutto il resto del traffico, come i ping ICMP, verrà gestito dalla successiva route più specifica nella tua rete VPC.

Se una route creata prima del 15 maggio 2021 era ancora in funzione il 16 agosto 2021, ne è stata eseguita la migrazione automatica in modo da inoltrare tutto il traffico dei protocolli a partire dal 16 agosto 2021.

Quando viene eseguito il deployment di un bilanciatore del carico di rete passthrough interno come hop successivo, Google Cloud inoltra tutto il traffico su tutte le porte alle VM di backend, indipendentemente da quanto segue:

• Il protocollo e la configurazione della porta della regola di forwarding
• La configurazione del protocollo del servizio di backend

Il bilanciatore del carico di rete passthrough interno, che è l'hop successivo della route, supporta senza problemi l'inoltro di tutto il traffico per i protocolli supportati dalle reti VPC Google Cloud (come TCP, UDP e ICMP).

Ulteriori considerazioni

• Regole di forwarding supportate. Google Cloud supporta solo le regole di forwarding del bilanciatore del carico di rete passthrough interno per l'hop successivo. Google Cloud non supporta le regole di forwarding dell'hop successivo utilizzate da altri bilanciatori del carico, forwarding del protocollo o come endpoint Private Service Connect.

• Metodi di specifica e rete e progetto di regola di forwarding forwarding. Puoi specificare una regola di forwarding per l'hop successivo utilizzando uno dei tre metodi seguenti. Il metodo di specifica utilizzato determina se la rete della regola di forwarding deve corrispondere alla rete della route e in quale progetto può essere collocata la regola di forwarding:

  • In base al nome della regola di forwarding (--next-hop-ilb) e alla regione (--next-hop-ilb-region): quando specifichi una regola di forwarding per l'hop successivo in base al nome e alla regione, la rete della regola di forwarding deve corrispondere alla rete VPC della route. La regola di forwarding deve trovarsi nello stesso progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host del VPC condiviso).

  • Tramite link alla risorsa della regola di forwarding: il link alla risorsa di una regola di forwarding utilizza il formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, dove PROJECT_ID è l'ID del progetto che contiene la regola di forwarding, REGION è la regione della regola di forwarding e FORWARDING_RULE_NAME è il nome della regola. Quando specifichi una regola di forwarding per l'hop successivo tramite il relativo link alle risorse, la rete della regola di forwarding deve corrispondere alla rete VPC della route. La regola di forwarding può essere situata nel progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host del VPC condiviso) oppure in un progetto di servizio VPC condiviso.

  • In base a un indirizzo IPv4 di una regola di forwarding: quando specifichi una regola di forwarding dell'hop successivo in base al relativo indirizzo IPv4, la rete della regola di forwarding può essere o la rete VPC della route o una rete VPC in peering. La regola di forwarding può essere situata nel progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host del VPC condiviso) oppure in un progetto di servizio VPC condiviso.

• Effetto dell'accesso globale. Le route statiche personalizzate che utilizzano gli hop successivi del bilanciatore del carico di rete passthrough interno sono programmate in tutte le regioni. L'utilizzo dell'hop successivo dipende dall'impostazione di accesso globale del bilanciatore del carico. Con l'accesso globale abilitato, l'hop successivo del bilanciatore del carico è accessibile in tutte le regioni della rete VPC. Se l'accesso globale è disabilitato, l'hop successivo del bilanciatore del carico è accessibile solo nella stessa regione del bilanciatore del carico. Se l'accesso globale è disabilitato, i pacchetti inviati da un'altra regione a una route utilizzando un bilanciatore del carico di rete passthrough interno vengono eliminati.

• Quando tutti i backend sono in stato non integro. Quando tutti i backend di un bilanciatore del carico di rete passthrough interno non superano i controlli di integrità, le route che utilizzano l'hop successivo del bilanciatore del carico sono ancora attive. I pacchetti elaborati dalla route vengono inviati a uno dei backend del bilanciatore del carico dell'hop successivo in base alla distribuzione del traffico.

• Le regole di forwarding che utilizzano un indirizzo IP interno comune (--purpose=SHARED_LOADBALANCER_VIP) non sono supportate. I bilanciatori del carico di rete passthrough interni e le regole di forwarding del bilanciatore del carico di rete passthrough interno con un indirizzo IP comune sono funzionalità che si escludono a vicenda. Un bilanciatore del carico di rete passthrough interno per l'hop successivo deve utilizzare un indirizzo IP univoco per la regola di forwarding del bilanciatore del carico in modo che venga fatto riferimento in modo univoco a un solo servizio di backend (un bilanciatore del carico). È possibile che le regole di forwarding utilizzano un indirizzo IP interno comune per fare riferimento a diversi servizi di backend (bilanciatori del carico di rete passthrough interni diversi).

• Più route con le stesse destinazioni e priorità, ma bilanciatori del carico di rete passthrough interni diversi dell'hop successivo. Google Cloud distribuisce mai il traffico tra due o più bilanciatori del carico di rete passthrough interni di hop successivo utilizzando ECMP. Google Cloud seleziona invece un solo bilanciatore del carico di rete passthrough interno per l'hop successivo utilizzando un algoritmo interno deterministico. Per evitare questa ambiguità, puoi utilizzare tag di rete univoci per ogni route.

  

  Google Cloud seleziona un singolo hop successivo quando le route statiche con un bilanciatore del carico di rete passthrough interno diverso hanno la stessa priorità e destinazione.

• Più route con le stesse destinazioni, priorità e bilanciatori del carico di rete passthrough interni per l'hop successivo. Senza un tag di rete, Google Cloud non consente di creare più route statiche con la stessa combinazione di destinazione, priorità e hop successivo del bilanciatore del carico di rete passthrough interno. Con i tag di rete, puoi creare più route statiche con la stessa combinazione di destinazione, priorità e hop successivo del bilanciatore del carico di rete passthrough interno.

Casi d'uso

Puoi utilizzare un bilanciatore del carico di rete passthrough interno come hop successivo in più deployment e topologie.

Per ogni esempio, tieni presente le seguenti linee guida:

• Ogni interfaccia VM deve trovarsi in una rete VPC separata.

• Non puoi utilizzare VM di backend o bilanciatori del carico per instradare il traffico tra subnet nella stessa rete VPC perché le route di subnet non possono essere sostituite.

• Il bilanciatore del carico di rete passthrough interno è un bilanciatore del carico passthrough software-defined. I pacchetti vengono consegnati alle VM di backend senza modifiche alle informazioni di origine o destinazione (indirizzi o indirizzi e porte).

  Routing, filtro dei pacchetti, proxy e traduzione degli indirizzi sono responsabilità delle VM dell'appliance virtuale che fungono da backend per il bilanciatore del carico di rete passthrough interno.

Utilizzo di un bilanciatore del carico di rete passthrough interno come hop successivo verso un gateway NAT

Questo caso d'uso bilancia il carico del traffico dalle VM interne a più istanze del gateway NAT che instradano il traffico a internet.

Caso d'uso NAT (fai clic per ingrandire).

Hub e spoke: scambio di route di hop successivo tramite peering di rete VPC

Oltre a scambiare route di subnet, puoi configurare il peering di rete VPC per esportare e importare route statiche e dinamiche personalizzate. Le route statiche personalizzate che hanno un hop successivo del gateway internet predefinito sono escluse. Sono incluse le route statiche personalizzate che utilizzano bilanciatori del carico di rete passthrough interni dell'hop successivo.

Puoi configurare una topologia hub e spoke con le appliance virtuali del firewall dell'hop successivo situate nella rete VPC hub seguendo questi passaggi:

• Nella rete VPC hub, crea un bilanciatore del carico di rete passthrough interno con appliance virtuali firewall come backend.
• Nella rete VPC hub, crea una route statica personalizzata e imposta l'hop successivo come bilanciatore del carico di rete passthrough interno.
• Connetti la rete VPC hub a ciascuna delle reti VPC spoke utilizzando il peering di rete VPC.
• Per ogni peering, configura la rete hub per esportare le relative route personalizzate e configura la rete spoke corrispondente per importare le route personalizzate. La route con l'hop successivo del bilanciatore del carico è una delle route esportate dalla rete hub.

In base all'ordine di routing, è disponibile il bilanciatore del carico dell'appliance firewall dell'hop successivo nella rete VPC hub nelle reti spoke:

• ai client nella stessa regione del bilanciatore del carico, se l'accesso globale è disabilitato
• ai client in tutte le regioni, se è abilitato l'accesso globale, in base all'ordine di routing.

Hub e spoke (fai clic per ingrandire).

Bilanciamento del carico su più NIC

Nel caso d'uso seguente, le VM di backend sono istanze di appliance virtuali (ad esempio, ispezione di pacchetti, routing o VM gateway) con NIC in più reti VPC. Le istanze virtuali di appliance possono essere soluzioni commerciali di terze parti o soluzioni create da te. Le appliance virtuali sono VM di Compute Engine con più NIC.

Questo esempio mostra un singolo insieme di appliance virtuali di backend in un gruppo di istanze VM gestite.

Nella rete VPC denominata testing, il bilanciatore del carico di rete passthrough interno ha una regola di forwarding denominata fr-ilb1. Nell'esempio, questo bilanciatore del carico distribuisce il traffico nell'interfaccia nic0.

Nella rete VPC denominata production, un bilanciatore del carico di rete passthrough interno diverso ha una regola di forwarding denominata fr-ilb2. Questo bilanciatore del carico distribuisce il traffico su un'interfaccia diversa, nic1 in questo esempio.

Traffico con bilanciamento del carico multi-NIC (fai clic per ingrandire).

Per una configurazione dettagliata della configurazione, vedi Bilanciamento del carico su più NIC di backend.

Hashing simmetrico

L'esempio precedente non utilizza la traduzione dell'indirizzo di rete di origine (SNAT). SNAT non è necessaria perché Google Cloud utilizza l'hashing simmetrico. Ciò significa che quando i pacchetti appartengono allo stesso flusso, Google Cloud calcola lo stesso hash. In altre parole, l'hash non cambia quando indirizzo IP di origine:porta viene scambiato con indirizzo IP di destinazione:porta.

Note

• L'hashing simmetrico viene abilitato automaticamente quando crei la regola di forwarding del bilanciatore del carico di rete passthrough interno il 22 giugno 2021 o in una data successiva.

• Per abilitare l'hashing simmetrico su bilanciatori del carico di rete passthrough interni esistenti, devi ricreare la regola di forwarding e la route dell'hop successivo, come descritto in Abilitare l'hashing simmetrico.

• L'hashing simmetrico è supportato solo con bilanciatori del carico di rete passthrough interni.

• L'hashing simmetrico è supportato con i seguenti tipi di affinità sessione per i protocolli TCP e UDP:

  • IP client (2 tuple)
  • IP client e protocollo (3 tuple)
  • IP client, protocollo e porta (5 tuple)

• Facoltativamente, puoi utilizzare SNAT se il tuo caso d'uso lo richiede per qualche motivo.

Passaggi successivi

• Per configurare un bilanciatore del carico di rete passthrough interno come hop successivo, vedi Configurare un bilanciatore del carico di rete passthrough interno per appliance di terze parti o Eseguire il deployment di una rete hub e spoke utilizzando un bilanciatore del carico come hop successivo.
• Per configurare e testare un bilanciatore del carico di rete passthrough interno, vedi Configurare un bilanciatore del carico di rete passthrough interno con backend di gruppi di istanze VM.
• Per risolvere i problemi relativi all'hop successivo con il bilanciatore del carico di rete passthrough interno, vedi Risolvere i problemi dei bilanciatori del carico di rete passthrough interni.