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 vengono inoltrati i pacchetti lungo il percorso verso la destinazione finale. Per farlo, imposta il bilanciatore del carico come hop successivo in una route statica.
Prima di esaminare le informazioni in questa pagina, dovresti già avere familiarità con i concetti dei seguenti argomenti:
Un hop successivo del bilanciatore del carico di rete passthrough interno è utile nei seguenti casi:
Per bilanciare il carico del traffico su più VM che fungono da VM gateway o router.
Per utilizzare le virtual appliances 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 traffico a internet tramite 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 insieme di VM gateway o router con più NIC come backend. Per farlo, crea un bilanciatore del carico e utilizzalo come hop successivo per una route statica 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.
Architettura
Nel seguente diagramma, un gruppo di istanze VM di VM router funge da
backend per due diversi bilanciatori del carico.
Il primo bilanciatore del carico di rete passthrough interno invia i 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.
Vantaggi dell'utilizzo del bilanciatore del carico di rete passthrough interno come hop successivo
Quando il bilanciatore del carico è un hop successivo per una route statica, non è necessaria alcuna configurazione speciale nei sistemi operativi guest delle VM client nella rete VPC in cui è definita la route. Le VM client inviano pacchetti ai backend del bilanciatore del carico tramite il routing della rete VPC, in modalità 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 assicura che le nuove connessioni vengano instradate alle VM di backend integre. 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 di servizio.
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 per trasmettere il traffico TCP, UDP e di altri protocolli a un bilanciatore del carico di rete passthrough interno in cui il bilanciatore del carico è l'hop successivo per la route statica. La route può essere un prefisso CIDR esterno (instradabile pubblicamente) o interno, se non è in conflitto con una route di 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.
Opzioni per specificare l'hop successivo
Puoi specificare un 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 informazioni dettagliate sul progetto e sulla rete VPC in cui può risiedere un hop successivo del bilanciatore del carico di rete passthrough interno, consulta Hop successivi e funzionalità.
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 route statici.
Affinità sessione IP client
I bilanciatori del carico di rete passthrough interni offrono due opzioni di affinità di sessione "indirizzo IP client" simili:
- IP client (
CLIENT_IP): hash di una tupla di due elementi 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: 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à di sessione a due tuple seleziona lo stesso backend. - IP client, nessuna destinazione (
CLIENT_IP_NO_DESTINATION): hash di 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 dall'attributo di destinazione della route. In questa situazione, l'affinità di sessione dell'hash a due tuple IP client (CLIENT_IP) 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 vuoi che i pacchetti con indirizzi IP di origine identici vengano instradati allo stesso backend, devi utilizzare l'opzione di affinità di sessione IP client, nessuna destinazione (CLIENT_IP_NO_DESTINATION).
Intervallo di destinazione
La destinazione di una route statica
non può essere uguale o più specifica di una route
subnet. Tieni presente che più specifico significa che la
maschera di sottorete è più lunga. Questa regola si applica a tutte le route statiche, anche
quando l'hop successivo è un bilanciatore del carico di rete passthrough interno. Ad esempio, supponiamo che la tua
route di sottorete sia 10.140.0.0/20. La destinazione di una route statica 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 che utilizzano i 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 devono trovarsi nella stessa rete VPC.
Una singola regione o tutte le regioni. A meno che tu non configuri l'accesso globale, la route statica è disponibile solo per le risorse nella stessa regione del bilanciatore del carico. Questa limitazione regionale 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 è disponibile per le risorse in qualsiasi regione.
Pubblicizzare la route statica
Per annunciare il prefisso (destinazione) per la route statica, puoi utilizzare la modalità annuncio personalizzato del router Cloud. L'ambito della pubblicità 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 le VM, i tunnel Cloud VPN e i collegamenti Cloud Interconnect (VLAN) che si trovano nella stessa regione del bilanciatore del carico. Di conseguenza, una pubblicità di route personalizzata per il prefisso di una route statica ha senso solo 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, 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 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 dai router nella stessa regione |
| Disabilitato | Globale | Accessibile dai router nella stessa regione |
| Attivato | Regionale | Accessibile da tutti i router in qualsiasi regione |
| Attivato | Globale | Accessibile da tutti i router in qualsiasi regione |
Per saperne di più, 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 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 bilanciamento del carico inesistente, Google Cloud viene restituito un errore.
Specifichi 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 utilizzando 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 a meno che tu non elimini prima la route. Nello specifico, non puoi eliminare una regola di forwarding interno finché nessuna route statica 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 saperne di più, consulta Considerazioni comuni agli hop successivi del bilanciatore del carico di rete passthrough interno e delle istanze.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. 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 del traffico TCP, UDP e di altri protocolli
Quando un bilanciatore del carico di rete passthrough interno viene implementato come hop successivo, Google Cloud inoltra tutto il traffico su tutte le porte alle VM di backend, indipendentemente da quanto segue:
- La configurazione del protocollo e 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 (come TCP, UDP e ICMP). Google Cloud
Considerazioni aggiuntive
Regole di forwarding supportate: Google Cloud supporta solo le regole di forwarding del bilanciatore del carico di rete passthrough interno dell'hop successivo. Google Cloud Non supporta le regole di forwarding dell'hop successivo utilizzate da altri bilanciatori del carico, l'inoltro di protocollo o come endpoint Private Service Connect.
Metodi di specifica e rete e progetto della regola di forwarding. Puoi specificare una regola di forwarding del next hop utilizzando uno dei tre metodi seguenti. Il metodo di specifica che utilizzi determina se la rete della regola di forwarding deve corrispondere alla rete della route e in quale progetto può trovarsi la regola di forwarding.
Scegli uno dei seguenti metodi e assicurati che la versione IP della regola di forwarding corrisponda alla versione IP della route statica che crei:
Per nome della regola di forwarding (
--next-hop-ilb) e regione (--next-hop-ilb-region): quando specifichi una regola di forwarding di hop successivo 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 la rete della regola di forwarding (un progetto autonomo o un progetto host VPC condiviso).Per 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, dovePROJECT_IDè l'ID progetto del progetto che contiene la regola di forwarding,REGIONè la regione della regola di forwarding eFORWARDING_RULE_NAMEè il nome della regola di forwarding. Quando specifichi una regola di forwarding dell'hop successivo tramite il relativo link alla risorsa, la rete della regola di forwarding deve corrispondere alla rete VPC della route. La regola di forwarding può trovarsi nel progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host VPC condiviso) o in un progetto di servizio VPC condiviso.Tramite un indirizzo IP della regola di forwarding: quando specifichi una regola di forwarding di hop successivo in base al relativo indirizzo IPv4 o IPv6, la rete della regola di forwarding può essere la rete VPC della route o una rete VPC connessa alla rete VPC della route utilizzando il peering di rete VPC o Network Connectivity Center. Network Connectivity Center supporta un bilanciatore del carico di rete passthrough interno dell'hop successivo in un VPC spoke soggetto ai requisiti di connettività di Network Connectivity Center. La regola di forwarding può trovarsi nel progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host VPC condiviso) o 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'utilizzabilità dell'hop successivo dipende dall'impostazione 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. Con l'accesso globale disabilitato, l'hop successivo del bilanciatore del carico è accessibile solo nella stessa regione del bilanciatore del carico. Con l'accesso globale disattivato, i pacchetti inviati da un'altra regione a una route che utilizza un hop successivo del 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 di quel 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. Gli hop successivi dei 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à reciprocamente esclusive. Un bilanciatore del carico di rete passthrough interno dell'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 solo bilanciatore del carico). È possibile che le regole di forwarding che utilizzano un indirizzo IP interno comune facciano riferimento a servizi di backend diversi (bilanciatori del carico di rete passthrough interni diversi).Più route con le stesse destinazioni e priorità, ma bilanciatori del carico di rete passthrough interni con hop successivi diversi. Google Cloud Non distribuisce mai il traffico tra due o più bilanciatori del carico di rete passthrough interni con hop successivi diversi utilizzando ECMP.Google Cloud seleziona un solo bilanciatore del carico di rete passthrough interno dell'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 hop successivi del bilanciatore del carico di rete passthrough interno diversi hanno la stessa priorità e destinazione. Più route con le stesse destinazioni, priorità e bilanciatori del carico di rete passthrough interni con hop successivi. Senza un tag di rete, Google Cloud non ti 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 o bilanciatori del carico di backend per instradare il traffico tra le 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 definito dal software. I pacchetti vengono inviati alle VM di backend senza modifiche alle informazioni di origine o di destinazione (indirizzi o indirizzi e porte).
Il routing, il filtraggio dei pacchetti, il proxy e la conversione degli indirizzi sono responsabilità delle VM delle appliance virtuali 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 a 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.
Hub e spoke: scambio di route di hop successivo utilizzando il 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 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 con hop successivo.
Puoi configurare una topologia hub-and-spoke con le tue appliance virtuali firewall di hop successivo
che si trovano nella rete VPC hub procedendo nel seguente modo:
- 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 e imposta l'hop successivo in modo che sia il bilanciatore del carico di rete passthrough interno. - Connetti la rete VPC
huba ciascuna delle reti VPCspokeutilizzando il peering di rete VPC. - Per ogni peering, configura la rete
hubper esportare le route personalizzate e la retespokecorrispondente per importarle. La route con l'hop successivo del bilanciatore del carico è una delle route esportate dalla retehub.
In base all'ordine di routing, il bilanciatore del carico dell'appliance firewall dell'hop successivo nella rete VPC hub è disponibile nelle reti spoke:
- ai client nella stessa regione del bilanciatore del carico, se l'accesso globale è disabilitato
- ai client di tutte le regioni, se l'accesso globale è abilitato, in base all'ordine di routing.
Bilanciamento del carico su più NIC
Nel seguente caso d'uso, le VM di backend sono istanze di appliance virtuali (ad esempio, VM di ispezione dei pacchetti, routing o gateway) con NIC in più reti VPC. Queste istanze di appliance virtuali possono essere soluzioni commerciali di terze parti o soluzioni che crei tu stesso. Le appliance virtuali sono VM 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 all'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 a un'interfaccia diversa, nic1 in questo esempio.
Per una configurazione dettagliata, consulta Bilanciamento del carico su più NIC di backend.
Hashing simmetrico
L'esempio precedente non utilizza la conversione dell'indirizzo di rete di origine (SNAT). SNAT non è richiesto 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 l'indirizzo IP di origine:porta viene scambiato con l'indirizzo IP di destinazione:porta.
Note:
L'hashing simmetrico viene attivato automaticamente quando crei la 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 Abilitare l'hashing simmetrico.
L'hashing simmetrico è supportato solo con i bilanciatori del carico di rete passthrough interni.
L'hashing simmetrico è supportato con i seguenti tipi di affinità di sessione per i protocolli TCP e UDP:
- IP client (
CLIENT_IP) - IP client e protocollo (
CLIENT_IP_PROTO) - IP client, protocollo e porta (
CLIENT_IP_PORT_PROTO)
Per ulteriori informazioni su queste impostazioni, consulta Opzioni di affinità di sessione.
- IP client (
Se il tuo caso d'uso lo richiede per qualche motivo, puoi utilizzare SNAT.
Passaggi successivi
- Per configurare un bilanciatore del carico di rete passthrough interno come hop successivo, consulta 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, consulta Configura 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, consulta la pagina Risolvere i problemi relativi ai bilanciatori del carico di rete passthrough interni.