Bilanciatori del carico di rete passthrough interni come hop successivi

Un bilanciatore del carico di rete passthrough interno è un bilanciatore del carico regionale che consente di eseguire scalare i servizi dietro un indirizzo IP interno. Puoi utilizzare un il bilanciatore del carico di rete passthrough interno come hop successivo a cui i pacchetti vengono inoltrati lungo per raggiungere la 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 già conoscere con concetti quali:

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

  • per bilanciare il carico del traffico su più VM funzionanti. come VM gateway o router.

  • Per utilizzare il gateway virtuale elettrodomestici come hop successivo per una route predefinita. Con questa configurazione, (VM) nella tua rete Virtual Private Cloud (VPC) inviano il traffico attraverso un insieme di VM gateway virtuali con bilanciamento del carico.

  • Per inviare il traffico attraverso più bilanciatori del carico in due o più utilizzando lo stesso insieme di VM gateway o router con più NIC delle di backend. Per farlo, creerai un bilanciatore del carico e lo userai come hop successivo per una route statica personalizzata in ogni rete VPC. Ciascuna il bilanciatore del carico di rete passthrough interno opera all'interno di una singola rete VPC, che distribuisce il traffico alle interfacce di rete delle VM di backend in quella rete.

Architettura

Nel diagramma seguente, un gruppo di istanze VM di VM router funge da per due diversi bilanciatori del carico. Il primo bilanciatore del carico di rete passthrough interno invia pacchetti a nic0 del backend Le VM e il secondo bilanciatore del carico di rete passthrough interno inviano pacchetti a nic1 sulla gli stessi backend.

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

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

Se il bilanciatore del carico è un hop successivo per una route statica, non vengono configurazione necessaria all'interno dei sistemi operativi guest delle VM client la rete VPC in cui è definita la route. Le VM client inviano pacchetti ai backend del bilanciatore del carico instradamento sulla rete VPC, bump-in-the-wire moda.

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 carico il controllo di integrità del bilanciatore del carico garantisce che le nuove connessioni siano instradate a stato integro di backend. Utilizzando un gruppo di istanze gestite come backend, puoi configurare la scalabilità automatica per aumentare o ridurre il set di VM in base al servizio domanda.

Specifiche

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

Route

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

Opzioni per specificare l'hop successivo

Puoi specificare l'hop successivo di un 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 l'hop successivo del bilanciatore del carico di rete passthrough interno può risiedere, vedi Hop successivi e funzionalità.

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

Affinità sessione IP client

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

  • IP client (CLIENT_IP): un hash a due tuple dell'indirizzo IP di origine di un pacchetto e l'indirizzo IP di destinazione. Quando un bilanciatore del carico di rete passthrough interno non è il successivo della route i pacchetti inviati all'indirizzo IP della regola di forwarding del bilanciatore del carico condividono l'indirizzo IP di destinazione comune, ovvero l'indirizzo IP della regola di forwarding. In questo , uno degli indirizzi utilizzati dall'hash a due tuple rimane costante. Pertanto, se il numero di backend configurati e integri non cambia pacchetti hanno indirizzi IP di origine identici, questa affinità sessione a due tuple seleziona lo stesso backend.
  • IP client, nessuna destinazione (CLIENT_IP_NO_DESTINATION): un hash a una tupla. 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 attributo destination. In questo caso, l'hash a due tuple L'affinità sessione IP client (CLIENT_IP) non può selezionare lo stesso backend anche quando il numero di backend configurati e integri non cambia pacchetti hanno indirizzi IP di origine identici. Un'eccezione a questa regola è quando configurato un solo backend). Se hai bisogno di pacchetti con origine identica per gli indirizzi IP da instradare allo stesso backend, devi usare la classe Client IP, nessuna opzione di affinità sessione (CLIENT_IP_NO_DESTINATION).

Intervallo di destinazione

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

Stessa rete VPC e stessa regione

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

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

  • Una o tutte le regioni. A meno che non configuri globale l'accesso, la route statica personalizzata è disponibile solo per le risorse che si trovano nella stessa regione del bilanciatore del carico. Questo la restrizione regionale viene applicata anche se la route stessa fa parte della di routing per l'intera rete VPC. Se attivi con 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 Annuncio personalizzato di router Cloud . L'ambito della route dipende dall'impostazione di accesso globale del bilanciatore del carico, come segue:

  • Quando 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, annuncio di route personalizzata per il prefisso di una route statica personalizzata ha solo senso se il router Cloud e il bilanciatore del carico si trovano nella stessa regione.

  • Quando l'accesso globale è abilitato, il bilanciatore del carico di rete passthrough interno è disponibile per le VM, Tunnel Cloud VPN e collegamenti di Cloud Interconnect (VLAN) che si trovano in qualsiasi regione. Con il routing dinamico globale, gli ambienti 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
Disabilitata Regionale Accessibile dai router nella stessa regione
Disabilitata Globale Accessibile dai 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 informazioni, vedi Bilanciatori del carico di rete passthrough interni e reti.

Ordine delle operazioni

Devi creare un bilanciatore del carico di rete passthrough interno prima di poter creare un una route statica personalizzata che la utilizza come hop successivo. Il bilanciatore del carico deve esistere prima di poter creare il percorso. Se provi a creare un percorso che fa riferimento a una con 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 protocollo della regola e la regione del bilanciatore del carico oppure usando l'indirizzo IP interno associate 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 percorso. Nello specifico, non puoi eliminare una regola di forwarding interno finché non una route statica personalizzata 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'IP forwarding (--can-ip-forward = True). Per ulteriori informazioni, consulta Considerazioni basate su istanze o basate su bilanciatore del carico di routing.

  • 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 un indirizzo IP gestito dal cluster, non una destinazione arbitraria.

Elaborazione del traffico TCP, UDP e di altro tipo

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 seguenti:

  • Il protocollo e la configurazione delle porte 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 perfettamente inoltrando tutto il traffico per i protocolli supportati da Google Cloud. Reti VPC (come TCP, UDP e ICMP).

Ulteriori considerazioni

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

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

    • Tramite il nome della regola di forwarding (--next-hop-ilb) e la regione (--next-hop-ilb-region): quando specifichi l'inoltro dell'hop successivo regola per nome e 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 (un progetto autonomo o un progetto host del VPC condiviso).

    • Tramite il link alle risorse della regola di forwarding: la risorsa della regola di forwarding utilizza il formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, dove PROJECT_ID è il 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 di forwarding. Quando specifichi una regola di forwarding per l'hop successivo tramite il relativo link della risorsa, la rete della regola di forwarding deve corrispondere al VPC della route in ogni rete. La regola di forwarding può trovarsi sia nel progetto che contiene la rete della regola di forwarding (un progetto autonomo o progetto host del VPC condiviso) o di un servizio VPC condiviso progetto.

    • Tramite un indirizzo IPv4 di una regola di forwarding: quando specifichi un hop successivo dalla regola di forwarding tramite il relativo indirizzo IPv4, la rete può essere la rete VPC della route oppure una rete VPC in peering. È possibile trovare la regola di forwarding nel progetto che contiene la rete della regola di forwarding o (un progetto autonomo o un progetto host del VPC condiviso) oppure una Progetto di servizio VPC condiviso.

  • Effetto dell'accesso globale. Route statiche personalizzate utilizzando il bilanciatore del carico di rete passthrough interno gli hop successivi sono programmati in tutte le regioni. Indica se l'hop successivo è utilizzabile dipende dalla dimensione globale del bilanciatore del carico di accesso. Con impostazioni globali abilitato, l'hop successivo del bilanciatore del carico è accessibile in tutte le regioni la rete VPC. Se l'accesso globale è disattivato, il carico l'hop successivo del bilanciatore è accessibile solo nella stessa regione del carico con il bilanciatore del carico di rete passthrough esterno regionale. Se l'accesso globale è disabilitato, i pacchetti inviati da un'altra regione che utilizza un hop successivo del bilanciatore del carico di rete passthrough interno.

  • Quando tutti i backend sono in stato non integro. Quando tutti i backend di un il bilanciatore del carico di rete passthrough interno non supera i controlli di integrità, le route che utilizzano quel bilanciatore del carico hop successivo sono ancora attivi. I pacchetti elaborati dalla rotta vengono inviati a uno dei backend del bilanciatore del carico dell'hop successivo in base al traffico la distribuzione dei contenuti.

  • Regole di forwarding che utilizzano un indirizzo IP interno comune (--purpose=SHARED_LOADBALANCER_VIP) non sono supportati. Hop successivo bilanciatori del carico di rete passthrough interni e regole di forwarding del bilanciatore del carico di rete passthrough interno con un IP comune indirizzo si escludono a vicenda. Un bilanciatore del carico di rete passthrough interno dell'hop successivo deve utilizzare un bilanciatore univoco per la regola di forwarding del bilanciatore del carico, in modo che viene fatto riferimento in modo inequivocabile a un solo servizio di backend (un bilanciatore del carico). È possibile che le regole di forwarding utilizzino un indirizzo IP interno comune fare riferimento a servizi di backend diversi (bilanciatori del carico di rete passthrough interni diversi).

  • Più percorsi con le stesse destinazioni e priorità, ma diverse bilanciatori del carico di rete passthrough interni con l'hop successivo. Google Cloud non distribuisce mai il traffico tra due o più bilanciatori del carico di rete passthrough interni per l'hop successivo utilizzando ECMP. Invece, Google Cloud seleziona solo un bilanciatore del carico di rete passthrough interno dell'hop successivo utilizzando una 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 diversi hop successivi del bilanciatore del carico di rete passthrough interno hanno lo stesso priorità e destinazione.

  • Più route con destinazioni, priorità e hop successivo uguali bilanciatori del carico di rete passthrough interni. Senza un tag di rete, Google Cloud non consentono di creare più route statiche che hanno la stessa combinazione destinazione, priorità e bilanciatore del carico di rete passthrough interno. Con i tag di rete, creare più route statiche con la stessa combinazione di destinazione, della 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 topologies.

Per ogni esempio, tieni presente le seguenti linee guida:

  • Ogni interfaccia della 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é non è possibile con override.

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

    routing, filtro dei pacchetti, proxying e traduzione degli indirizzi sono la responsabilità delle VM delle appliance virtuali che fungono da backend 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ù gateway NAT che instradano il traffico verso internet.

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

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

Oltre a scambiare le route delle subnet, puoi configurare Peering di rete VPC per esportare e importare route statiche e dinamiche. Route statiche personalizzate in presenza di un hop successivo del gateway internet predefinito. Personalizzate Sono incluse le route statiche che utilizzano i bilanciatori del carico di rete passthrough interni per l'hop successivo.

Puoi configurare una topologia hub e spoke con il firewall virtuale dell'hop successivo posizionate nella rete VPC hub mediante l'esecuzione seguenti:

  • 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 per essere il bilanciatore del carico di rete passthrough interno.
  • Connetti la rete VPC hub a ogni rete spoke tramite peering di rete VPC.
  • Per ogni peering, configura la rete hub per esportare le relative route personalizzate, e configurare la rete spoke corrispondente per importare route personalizzate. Il percorso con l'hop successivo del bilanciatore del carico è una delle route che la rete hub .

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

  • ai client nella stessa regione del bilanciatore del carico, se l'accesso globale è disattivato
  • ai client in tutte le regioni, se l'accesso globale è abilitato, in base ordine di routing.
. Hub e spoke.
Hub e spoke (fai clic per ingrandire).

Bilanciamento del carico su più NIC

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

Questo esempio mostra un singolo set di appliance virtuali di backend in una VM gestita gruppo di istanze 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 all'interfaccia nic0.

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

Traffico con bilanciamento del carico con più NIC.
Traffico con bilanciamento del carico a più NIC (fai clic per ingrandire).

Per una configurazione dettagliata della configurazione, consulta Bilanciamento del carico in più backend NIC.

Hash simmetrico

L'esempio precedente non utilizza la Network Address Translation di origine (SNAT). SNAT non è necessaria perché Google Cloud utilizza 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 l'indirizzo IP di origine:porta viene scambiato con l'IP di destinazione indirizzo:porta.

Note:

  • L'hashing simmetrico viene attivato automaticamente quando crei regola di forwarding del bilanciatore del carico di rete passthrough interno a partire dal 22 giugno 2021.

  • Per abilitare l'hashing simmetrico sui bilanciatori del carico di rete passthrough interni esistenti, devi ricreare la regola di forwarding e la route dell'hop successivo, come descritto in Attivazione della modalità simmetrica di hashing.

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

  • L'hashing simmetrico è supportato con i seguenti tipi di affinità sessione per 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 per qualche motivo il tuo caso d'uso lo richiede.

Passaggi successivi