Panoramica del bilanciatore del carico di rete passthrough interno

Un bilanciatore del carico di rete passthrough interno è un bilanciatore del carico regionale creato sullo stack di virtualizzazione di rete Andromeda.

I bilanciatori del carico di rete passthrough interni distribuiscono il traffico tra le istanze di macchine virtuali (VM) interne nella stessa regione in una rete Virtual Private Cloud (VPC). Ti consente di eseguire e scalare i servizi utilizzando un indirizzo IP interno accessibile solo ai sistemi nella stessa rete VPC o ai sistemi connessi alla tua rete VPC.

Utilizza un bilanciatore del carico di rete passthrough interno nelle seguenti circostanze:

  • Hai bisogno di un bilanciatore del carico pass-through di livello 4 ad alte prestazioni per i protocolli TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE.
  • Se il traffico viene gestito tramite TLS (SSL), è accettabile che il traffico SSL venga terminato dai backend anziché dal bilanciatore del carico. Il bilanciatore del carico di rete passthrough interno non può terminare il traffico SSL.
  • Devi inoltrare i pacchetti originali senza proxy. Ad esempio, se devi conservare l'indirizzo IP di origine del client.
  • Hai una configurazione esistente che utilizza un bilanciatore del carico pass-through e vuoi eseguirne la migrazione senza modifiche.

I bilanciatori del carico di rete passthrough interni coprono molti casi d'uso. Per alcuni esempi di alto livello, consulta la panoramica del bilanciatore del carico di rete passthrough.

Come funzionano i bilanciatori del carico di rete passthrough interni

Un bilanciatore del carico di rete passthrough interno ha un frontend (la regola di forwarding) e un backend (il servizio di backend). Puoi utilizzare gruppi di istanze o NEG a livello di zona come backend nel servizio di backend.GCE_VM_IP Questo esempio mostra i backend di gruppi di istanze.

Esempio di bilanciatore del carico di rete passthrough interno di alto livello.
Esempio di bilanciatore del carico di rete passthrough interno di alto livello (fai clic per ingrandire).

A differenza di un bilanciatore del carico proxy, un bilanciatore del carico di rete passthrough interno non termina le connessioni dai client e poi apre nuove connessioni ai backend. Un bilanciatore del carico di rete passthrough interno instrada le connessioni direttamente dai client ai backend integri, senza interruzioni. Le risposte delle VM di backend integre vanno direttamente ai client, non di nuovo tramite il bilanciatore del carico. Le risposte TCP utilizzano il ritorno diretto del server. Per saperne di più, consulta Pacchetti di richiesta e risposta TCP e UDP.

Il bilanciatore del carico monitora l'integrità del backend utilizzando i probe del controllo di integrità. Per saperne di più, consulta la sezione Controllo di integrità.

L' Google Cloud ambiente guest Linux, l'ambiente guest Windows o un processo equivalente configura ogni VM di backend con l'indirizzo IP del bilanciatore del carico. Per le VM create da immagini Google Cloud , l'agente guest (in precedenza, l'ambiente guest Windows o l'ambiente guest Linux) installa la route locale per l'indirizzo IP del bilanciatore del carico. Le istanze Google Kubernetes Engine basate su Container-Optimized OS implementano questa funzionalità utilizzando iptables.

Il networking virtuale diGoogle Cloud gestisce la distribuzione del traffico e lo scaling in modo appropriato.

Protocolli, schema e ambito

Ogni bilanciatore del carico di rete passthrough interno supporta quanto segue:

  • Un servizio di backend con schema di bilanciamento del carico INTERNAL e un protocollo supportato. Per ulteriori informazioni, consulta Servizio di backend.
  • VM di backend specificate come una delle seguenti:
    • Gruppi di istanze gestite e non gestite che si trovano in una regione e in una rete VPC.
    • Gruppi di endpoint di rete (NEG) di backend zonali con endpoint di tipo GCE_VM_IP che si trovano nella stessa regione e nella stessa rete VPC. Gli endpoint nel NEG devono essere indirizzi IP interni principali nella stessa subnet e zona utilizzate dal NEG.
  • Supporto del traffico IPv4 e IPv6 quando si utilizzano backend di gruppi di istanze. I gruppi di endpoint di rete (NEG) a livello di zona con endpoint GCE_VM_IP supportano solo il traffico IPv4.
  • Una o più regole di forwarding, ciascuna delle quali utilizza il protocollo TCP, UDP o L3_DEFAULT corrispondente al protocollo del servizio di backend.
  • Ogni regola di forwarding con il proprio indirizzo IP univoco o più regole di forwarding che condividono un indirizzo IP comune.
  • Ogni regola di forwarding con un massimo di cinque porte o tutte le porte.
  • Se è abilitato l'accesso globale, i client in qualsiasi regione.
  • Se l'accesso globale è disabilitato, i client nella stessa regione del bilanciatore del carico.

Un bilanciatore del carico di rete passthrough interno non supporta quanto segue:

Accesso client

Per impostazione predefinita, il bilanciatore del carico supporta solo i client che si trovano nella stessa regione del bilanciatore del carico. I client possono trovarsi nella stessa rete del bilanciatore del carico o in una rete VPC connessa tramite peering di rete VPC. Puoi abilitare l'accesso globale per consentire ai client di qualsiasi regione di accedere al tuo bilanciatore del carico di rete passthrough interno.

Bilanciatore del carico di rete passthrough interno con accesso globale.
Bilanciatore del carico di rete passthrough interno con accesso globale (fai clic per ingrandire).

La tabella seguente riassume l'accesso client.

Accesso globale disattivato Accesso globale abilitato
I client devono trovarsi nella stessa regione del bilanciatore del carico. Devono inoltre trovarsi nella stessa rete VPC del bilanciamento del carico o in una rete VPC connessa alla rete VPC del bilanciamento del carico tramite il peering di rete VPC. I client possono trovarsi in qualsiasi regione. Devono comunque trovarsi nella stessa rete VPC del bilanciatore del carico o in una rete VPC connessa alla rete VPC del bilanciatore del carico tramite il peering di rete VPC.
I client on-premise possono accedere al bilanciatore del carico tramite tunnel VPN Cloud o collegamenti VLAN. Questi tunnel o allegati devono trovarsi nella stessa regione del bilanciatore del carico. I client on-premise possono accedere al bilanciatore del carico tramite tunnel Cloud VPN o collegamenti VLAN. Questi tunnel o allegati possono trovarsi in qualsiasi regione.

Indirizzi IP per i pacchetti di richiesta e di ritorno

Quando una VM di backend riceve un pacchetto con bilanciamento del carico da un client, l'origine e la destinazione del pacchetto sono le seguenti:

  • Origine:l'indirizzo IPv4, IPv6 o IPv4 interno del client da uno degli intervalli IPv4 alias del client.
  • Destinazione:l'indirizzo IP della regola di forwarding del bilanciatore del carico. La regola di forwarding utilizza un singolo indirizzo IPv4 interno o un intervallo IPv6 interno.

Poiché il bilanciatore del carico è un bilanciatore del carico passthrough (non un proxy), i pacchetti arrivano con l'indirizzo IP di destinazione della regola di forwarding del bilanciatore del carico. Configura il software in esecuzione sulle VM di backend in modo che:

  • Ascolta (collega) l'indirizzo IP della regola di forwarding del bilanciatore del carico o qualsiasi indirizzo IP (0.0.0.0 o ::)
  • Se il protocollo della regola di forwarding del bilanciatore del carico supporta le porte: ascolta (collega) una porta inclusa nella regola di forwarding del bilanciatore del carico

I pacchetti di ritorno vengono inviati direttamente dalle VM di backend del bilanciatore del carico al client. Gli indirizzi IP di origine e di destinazione del pacchetto di ritorno dipendono dal protocollo:

  • TCP è orientato alla connessione, quindi le VM di backend devono rispondere con pacchetti i cui indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding in modo che il client possa associare i pacchetti di risposta alla connessione TCP appropriata.
  • UDP è senza connessione, quindi le VM di backend possono inviare pacchetti di risposta i cui indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding o a qualsiasi indirizzo IP assegnato alla VM. In pratica, la maggior parte dei client si aspetta che la risposta provenga dallo stesso indirizzo IP a cui ha inviato i pacchetti.

La tabella seguente riepiloga le origini e le destinazioni dei pacchetti di risposta:

Tipo di traffico Origine Destinazione
TCP L'indirizzo IP della regola di forwarding del bilanciatore del carico L'origine del pacchetto di richiesta
UDP Per la maggior parte dei casi d'uso, l'indirizzo IP della regola di forwarding del bilanciatore del carico 1 L'origine del pacchetto di richiesta

1 È possibile impostare l'origine del pacchetto di risposta sull'indirizzo IPv4 interno principale della NIC della VM o su un intervallo di indirizzi IP alias. Se l'inoltro IP è abilitato per la VM, è possibile utilizzare anche origini di indirizzi IP arbitrarie. Il mancato utilizzo dell'indirizzo IP della regola di forwarding come origine è uno scenario avanzato perché il client riceve un pacchetto di risposta da un indirizzo IP interno che non corrisponde all'indirizzo IP a cui ha inviato un pacchetto di richiesta.

Architettura

Un bilanciatore del carico di rete passthrough interno con più backend distribuisce le connessioni tra tutti questi backend. Per informazioni sul metodo di distribuzione e sulle relative opzioni di configurazione, vedi distribuzione del traffico.

Puoi utilizzare gruppi di istanze o NEG di zona, ma non una combinazione di entrambi, come backend per un bilanciatore del carico di rete passthrough interno:

  • Se scegli i gruppi di istanze, puoi utilizzare gruppi di istanze non gestite, gruppi di istanze gestite a livello di zona, gruppi di istanze gestite a livello di regione o una combinazione di tipi di gruppi di istanze.
  • Se scegli i NEG a livello di zona, devi utilizzare i NEG a livello di zona GCE_VM_IP.

Alta affidabilità descrive come progettare un bilanciatore del carico interno che non dipende da una singola zona.

Le istanze che partecipano come VM di backend per i bilanciatori del carico di rete passthrough interni devono eseguire l'ambiente guest Linux o Windows appropriato o altri processi che forniscono funzionalità equivalenti. Questo ambiente guest deve essere in grado di contattare il server metadati (metadata.google.internal, 169.254.169.254) per leggere i metadati dell'istanza in modo da poter generare route locali per accettare il traffico inviato all'indirizzo IP interno del bilanciatore del carico.

Questo diagramma mostra la distribuzione del traffico tra le VM che si trovano in due gruppi di istanze separati. Il traffico inviato dall'istanza client all'indirizzo IP del bilanciatore del carico (10.10.10.9) viene distribuito tra le VM di backend in entrambi i gruppi di istanze. Le risposte inviate da una qualsiasi delle VM di backend di pubblicazione vengono recapitate direttamente alla VM client.

Puoi utilizzare un bilanciatore del carico di rete passthrough interno con una rete VPC in modalità personalizzata o automatica. Puoi anche creare bilanciatori del carico di rete passthrough interni con una rete legacy esistente.

Un bilanciatore del carico di rete passthrough interno non supporta quanto segue:

Indirizzo IP interno

I bilanciatori del carico di rete passthrough interni supportano subnet solo IPv4, a doppio stack e solo IPv6. Per maggiori informazioni su ciascuna, consulta Tipi di subnet.

Un bilanciatore del carico di rete passthrough interno richiede almeno una regola di forwarding. La regola di forwarding fa riferimento all'indirizzo IP interno:

  • Per il traffico IPv4, la regola di forwarding fa riferimento a un indirizzo IPv4 dell'intervallo di subnet IPv4 principale.

  • Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo /96 di indirizzi IPv6 interni dall'intervallo di indirizzi IPv6 interni /64 della subnet. La subnet deve essere una subnet a doppio stack o solo IPv6 a stack singolo (anteprima) con un intervallo di indirizzi IPv6 interni (ipv6-access-type impostato su INTERNAL). L'intervallo di indirizzi IPv6 può essere un indirizzo statico riservato o un indirizzo effimero.

    Per saperne di più sul supporto IPv6, consulta la documentazione di VPC su intervalli di subnet IPv6 e indirizzi IPv6.

Configurazione del firewall

I bilanciatori del carico di rete passthrough interni richiedono la seguente configurazione per i criteri firewall gerarchici e le regole firewall VPC:

Per ulteriori informazioni, vedi Configurazione delle regole firewall.

Regole di forwarding

Una regola di forwarding specifica il protocollo e le porte su cui il bilanciatore del carico accetta il traffico. Poiché i bilanciatori del carico di rete passthrough interni non sono proxy, trasmettono il traffico ai backend sullo stesso protocollo e sulla stessa porta.

Un bilanciatore del carico di rete passthrough interno richiede almeno una regola di forwarding interno. Puoi definire più regole di forwarding per lo stesso bilanciatore del carico.

Se vuoi che il bilanciatore del carico gestisca il traffico IPv4 e IPv6, crea due regole di forwarding: una regola per il traffico IPv4 che rimanda ai backend IPv4 (o a doppio stack) e una regola per il traffico IPv6 che rimanda solo ai backend a doppio stack. È possibile che una regola di forwarding IPv4 e una IPv6 facciano riferimento allo stesso servizio di backend, ma il servizio di backend deve fare riferimento a backend dual-stack.

La regola di forwarding deve fare riferimento a una subnet specifica nella stessa rete VPC e nella stessa regione dei componenti di backend del bilanciatore del carico. Questo requisito ha le seguenti implicazioni:

  • La subnet specificata per la regola di forwarding non deve essere la stessa di nessuna delle subnet utilizzate dalle VM di backend; tuttavia, la subnet deve trovarsi nella stessa regione della regola di forwarding.
  • Per il traffico IPv4, la regola di forwarding interno fa riferimento a un indirizzo IPv4 interno regionale dall'intervallo di indirizzi IPv4 principale della subnet che selezioni. Questo indirizzo IPv4 può essere selezionato automaticamente oppure puoi utilizzare un indirizzo IPv4 statico (riservato).
  • Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo /96 di indirizzi IPv6 dall'intervallo di indirizzi IPv6 interni /64 della subnet. La subnet deve essere una subnet a doppio stack con ipv6-access-type impostato su INTERNAL. L'intervallo di indirizzi IPv6 /96 viene assegnato automaticamente oppure puoi utilizzare un indirizzo IP interno riservato.

Protocolli delle regole di forwarding

I bilanciatori del carico di rete passthrough interni supportano le seguenti opzioni di protocollo IPv4 per ogni regola di forwarding: TCP, UDP o L3_DEFAULT.

I bilanciatori del carico di rete passthrough interni supportano le seguenti opzioni di protocollo IPv6 per ogni regola di forwarding: TCP o UDP.

L'opzione L3_DEFAULT ti consente di bilanciare il carico dei protocolli TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE.

Oltre a supportare protocolli diversi da TCP e UDP, l'opzione L3_DEFAULT consente a una singola regola di forwarding di inoltrare simultaneamente il traffico per più protocolli. Ad esempio, oltre a effettuare richieste HTTP, puoi anche inviare un ping all'indirizzo IP del bilanciatore del carico.

Le regole di forwarding che utilizzano i protocolli TCP o UDP possono fare riferimento a un servizio di backend utilizzando lo stesso protocollo della regola di forwarding o un servizio di backend che utilizza il protocollo UNSPECIFIED.

Se utilizzi il protocollo L3_DEFAULT, devi configurare la regola di forwarding in modo che accetti il traffico su tutte le porte. Per configurare tutte le porte, imposta --ports=ALL utilizzando Google Cloud CLI oppure imposta allPorts su True utilizzando l'API.

La seguente tabella riassume come utilizzare queste impostazioni per diversi protocolli:

Traffico da bilanciare Protocollo della regola di forwarding Protocollo del servizio di backend
TCP (IPv4 o IPv6) TCP TCP or UNSPECIFIED
UDP (IPv4 o IPv6) UDP UDP or UNSPECIFIED
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE L3_DEFAULT UNSPECIFIED

Regole di forwarding e accesso globale

Le regole di forwarding di un bilanciatore del carico di rete passthrough interno sono regionali, anche quando l'accesso globale è abilitato. Dopo aver abilitato l'accesso globale, il flag allowGlobalAccess della regola di forwarding interno regionale è impostato su true.

Regole di forwarding e specifiche delle porte

Quando crei una regola di forwarding interno, devi scegliere una delle seguenti specifiche della porta:

  • Specifica almeno una e fino a cinque porte, per numero.
  • Specifica ALL per inoltrare il traffico su tutte le porte.

Una regola di forwarding interna che supporta tutte le porte TCP o tutte le porte UDP consente alle VM di backend di eseguire più applicazioni, ognuna sulla propria porta. Il traffico inviato a una determinata porta viene recapitato all'applicazione corrispondente e tutte le applicazioni utilizzano lo stesso indirizzo IP.

Quando devi inoltrare il traffico su più di cinque porte specifiche, combina le regole firewall con le regole di forwarding. Quando crei la regola di forwarding, specifica tutte le porte, quindi crea regole firewall in entrata allow che consentano il traffico solo verso le porte desiderate. Applica le regole firewall alle VM di backend.

Non puoi modificare una regola di forwarding dopo averla creata. Se devi modificare le porte specificate o l'indirizzo IP interno per una regola di forwarding interno, devi eliminarla e ricrearla.

Più regole di forwarding per un singolo servizio di backend

Puoi configurare più regole di forwarding interno che fanno tutte riferimento allo stesso servizio di backend interno. Un bilanciatore del carico di rete passthrough interno richiede almeno una regola di forwarding interna.

La configurazione di più regole di forwarding per lo stesso servizio di backend ti consente di fare quanto segue:

  • Assegna più indirizzi IP al bilanciatore del carico. Puoi creare più regole di forwarding, ognuna delle quali utilizza un indirizzo IP univoco. Ogni regola di forwarding può specificare tutte le porte o un insieme di massimo cinque porte.

  • Assegna un insieme specifico di porte, utilizzando lo stesso indirizzo IP, al bilanciatore del carico. Puoi creare più regole di forwarding che condividono lo stesso indirizzo IP, dove ogni regola di forwarding utilizza un insieme specifico di massimo cinque porte. Si tratta di un'alternativa alla configurazione di una singola regola di forwarding che specifica tutte le porte.

Per saperne di più sugli scenari che coinvolgono due o più regole di forwarding interno che condividono un indirizzo IP interno comune, consulta Più regole di forwarding con lo stesso indirizzo IP.

Quando utilizzi più regole di forwarding interno, assicurati di configurare il software in esecuzione sulle VM di backend in modo che si associ a tutti gli indirizzi IP delle regola di forwarding o a qualsiasi indirizzo (0.0.0.0/0 per IPv4 o ::/0 per IPv6). L'indirizzo IP di destinazione per un pacchetto consegnato tramite il bilanciatore del carico è l'indirizzo IP interno associato alla regola di forwarding interna corrispondente. Per saperne di più, consulta Pacchetti di richiesta e risposta TCP e UDP.

Servizio di backend

Ogni bilanciatore del carico di rete passthrough interno ha un servizio di backend interno regionale che definisce i parametri e il comportamento del backend. Il nome del servizio di backend è il nome del bilanciatore del carico di rete passthrough interno mostrato nella console Google Cloud .

Ogni servizio di backend definisce i seguenti parametri di backend:

  • Protocollo. Un servizio di backend supporta il traffico IPv4 e IPv6. Se il protocollo ha un concetto di porta (come TCP o UDP), il servizio di backend invia i pacchetti alle VM di backend sulla stessa porta di destinazione a cui è stato inviato il traffico.

    I servizi di backend supportano le seguenti opzioni del protocollo IPv4: TCP, UDP o UNSPECIFIED.

    I servizi di backend supportano le seguenti opzioni del protocollo IPv6: TCP o UDP. Il protocollo del servizio di backend deve coordinarsi con il protocollo della regola di forwarding.

    Per una tabella con le possibili combinazioni di regole di forwarding e protocolli del servizio di backend, consulta Specifica del protocollo della regola di forwarding.

  • Distribuzione del traffico. Un servizio di backend consente di distribuire il traffico in base a un'affinità sessione configurabile.

  • Controllo di integrità. Un servizio di backend deve avere un controllo di integrità associato.

Ogni servizio di backend opera in una singola regione e distribuisce il traffico per le VM di backend in una singola rete VPC:

Backend di gruppi di istanze e interfacce di rete

All'interno di un determinato gruppo di istanze (gestito o non gestito), tutte le istanze VM devono avere le interfacce di rete nic0 nella stessa rete VPC.

  • Per i gruppi di istanze gestite (MIG), la rete VPC per il gruppo di istanze è definita nel modello di istanza.
  • Per i gruppi di istanze non gestite, la rete VPC per il gruppo di istanze è definita come la rete VPC utilizzata dall'interfaccia di rete nic0 della prima istanza VM che aggiungi al gruppo di istanze non gestite.
Ogni VM membro può avere facoltativamente interfacce di rete aggiuntive (vNIC o interfacce di rete dinamiche), ma ogni interfaccia di rete deve essere collegata a una rete VPC diversa. Queste reti devono anche essere diverse dalla rete VPC associata al gruppo di istanze.

Una NIC dinamica può essere eliminata se appartiene a una VM che fa parte di un gruppo di istanze con bilanciamento del carico.

Backend di NEG a livello di zona e interfacce di rete

Quando crei un nuovo NEG zonale con endpoint GCE_VM_IP, devi associare esplicitamente il NEG a una subnet di una rete VPC prima di poter aggiungere endpoint al NEG. Né la subnet né la rete VPC possono essere modificate dopo la creazione del NEG.

All'interno di un determinato NEG, ogni endpoint GCE_VM_IP rappresenta in realtà un'interfaccia di rete. L'interfaccia di rete deve trovarsi nella subnet associata al NEG. Dal punto di vista di un'istanza Compute Engine, l'interfaccia di rete può utilizzare qualsiasi identificatore. Dal punto di vista di un endpoint in un NEG, l'interfaccia di rete viene identificata utilizzando il suo indirizzo IPv4 interno principale.

Esistono due modi per aggiungere un endpoint GCE_VM_IP a un NEG:

  • Se specifichi solo un nome VM (senza alcun indirizzo IP) quando aggiungi un endpoint, Google Cloud richiede che la VM abbia un'interfaccia di rete nella subnet associata al NEG. L'indirizzo IP che Google Cloud sceglie per l'endpoint è l'indirizzo IPv4 interno principale dell'interfaccia di rete della VM nella subnet associata al NEG.
  • Se specifichi sia un nome VM sia un indirizzo IP quando aggiungi un endpoint, l'indirizzo IP che fornisci deve essere un indirizzo IPv4 interno principale per una delle interfacce di rete della VM. L'interfaccia di rete deve trovarsi nella subnet associata al NEG. Tieni presente che specificare un indirizzo IP è ridondante perché può esistere una sola interfaccia di rete nella subnet associata al NEG.

Una NIC dinamica non può essere eliminata se è un endpoint di un gruppo di endpoint di rete con bilanciamento del carico.

Specifica di rete del servizio di backend

Puoi associare esplicitamente una rete VPC a un servizio di backend utilizzando il flag --network quando crei il servizio di backend. Le regole di rete del servizio di backend entrano in vigore immediatamente.

Se ometti il flag --network quando crei un servizio di backend, Google Cloud utilizza uno dei seguenti eventi qualificati per impostare implicitamente la rete VPC associata del servizio di backend. Una volta impostata, la rete VPC associata al servizio di backend non può essere modificata:

  • Se il servizio di backend non ha ancora backend associati e configuri la prima regola di forwarding in modo che faccia riferimento al servizio di backend,Google Cloud imposta la rete VPC associata del servizio di backend sulla rete VPC che contiene la subnet utilizzata da questa regola di forwarding.

  • Se il servizio di backend non ha ancora una regola di forwarding che lo fa riferimento e aggiungi il primo backend del gruppo di istanze al servizio di backend, Google Cloud imposta la rete VPC del servizio di backend sulla rete VPC associata al primo backend del gruppo di istanze. Ciò significa che la rete VPC associata al servizio di backend è la rete utilizzata dall'interfaccia di rete nic0 di ogni VM nel primo backend del gruppo di istanze.

  • Se il servizio di backend non ha ancora una regola di forwarding che lo fa riferimento e aggiungi il primo backend NEG zonale (con endpoint GCE_VM_IP) al servizio di backend, Google Cloud imposta la rete VPC del servizio di backend sulla rete VPC associata al primo backend NEG.

Una volta impostata la rete VPC del servizio di backend da un evento idoneo, tutte le regole di forwarding, i gruppi di istanza di backend o i NEG di zona di backend aggiuntivi che aggiungi devono rispettare le regole di rete del servizio di backend.

Regole di rete del servizio di backend

Le seguenti regole si applicano dopo che un servizio di backend è associato a una rete VPC specifica:

  • Quando configuri una regola di forwarding per fare riferimento al servizio di backend, la regola di forwarding deve utilizzare una subnet della rete VPC del servizio di backend. La regola di forwarding e il servizio di backend non possono utilizzare reti VPC diverse, anche se queste reti sono connesse, ad esempio utilizzando il peering di rete VPC.

  • Quando aggiungi backend del gruppo di istanze, una delle seguenti condizioni deve essere vera:

    • La rete VPC associata al gruppo di istanze, ovvero la rete VPC utilizzata dall'interfaccia di rete nic0 di ogni VM nel gruppo di istanze, deve corrispondere alla rete VPC associata del servizio di backend.
    • Ogni VM di backend deve avere un'interfaccia nic0nella rete VPC associata al servizio di backend.

  • Quando aggiungi backend NEG zonali con endpoint GCE_VM_IP, la rete VPC associata al NEG deve corrispondere alla rete VPC associata al servizio di backend.

Backend a doppio stack (IPv4 e IPv6)

Se vuoi che il bilanciatore del carico utilizzi backend a doppio stack che gestiscono sia il traffico IPv4 che IPv6, tieni presente i seguenti requisiti:

  • I backend devono essere configurati in subnet dual-stack che si trovano nella stessa regione della regola di forwarding IPv6 del bilanciatore del carico. Per i backend, puoi utilizzare una subnet con ipv6-access-type impostato su INTERNAL o EXTERNAL. Se ipv6-access-type della subnet di backend è impostato su EXTERNAL, devi utilizzare una subnet a doppio stack o solo IPv6 diversa con ipv6-access-type impostato su INTERNAL per la regola di forwarding interno del bilanciatore del carico. Per saperne di più, consulta Aggiungere una subnet dual-stack.
  • I backend devono essere configurati per essere dual-stack con stack-type impostato su IPv4_IPv6. Se ipv6-access-type della subnet di backend è impostato su EXTERNAL, devi impostare anche --ipv6-network-tier su PREMIUM. Per saperne di più, vedi Creare un modello di istanza con indirizzi IPv6.

Backend solo IPv6

Se vuoi che il bilanciatore del carico utilizzi backend solo IPv6, tieni presente i seguenti requisiti:

  • Le istanze solo IPv6 sono supportate solo nei gruppi di istanze non gestite. Nessun altro tipo di backend è supportato.
  • I backend devono essere configurati in subnet dual stack o solo IPv6 che si trovano nella stessa regione della regola di forwarding IPv6 del bilanciatore del carico. Per i backend, puoi utilizzare una subnet con ipv6-access-type impostato su INTERNAL o EXTERNAL. Se ipv6-access-type della subnet di backend è impostato su EXTERNAL, devi utilizzare una subnet solo IPv6 diversa con ipv6-access-type impostato su INTERNAL per la regola di forwarding interno del bilanciatore del carico.
  • I backend devono essere configurati in modo che siano solo IPv6 con la VM stack-type impostata su IPv6_ONLY. Se ipv6-access-type della subnet di backend è impostato su EXTERNAL, devi impostare anche --ipv6-network-tier su PREMIUM. Per saperne di più, vedi Creare un modello di istanza con indirizzi IPv6.

Tieni presente che le VM solo IPv6 possono essere create sia in subnet a doppio stack che solo IPv6, ma le VM a doppio stack non possono essere create in subnet solo IPv6.

Sottoinsieme del backend

Il sottoinsieme di backend è una funzionalità facoltativa che migliora il rendimento limitando il numero di backend a cui viene distribuito il traffico.

Ti consigliamo di abilitare il sottoinsieme solo se devi supportare più di 250 VM di backend su un singolo bilanciatore del carico. Per ulteriori informazioni, consulta Impostazione secondaria dei backend per il bilanciatore del carico di rete passthrough interno.

Controllo di integrità

Il servizio di backend del bilanciatore del carico deve essere associato a un controllo di integrità globale o regionale. Le route speciali al di fuori della rete VPC facilitano la comunicazione tra i sistemicontrollo di integritàl'integrità e i backend.

Puoi utilizzare un controllo di integrità esistente o definirne uno nuovo. I bilanciatori del carico di rete passthrough interni utilizzano lo stato del controllo di integrità per determinare come instradare le nuove connessioni, come descritto in Distribuzione del traffico.

Puoi utilizzare uno qualsiasi dei seguenti protocolli di controllo di integrità; il protocollo del controllo di integrità non deve corrispondere al protocollo del bilanciatore del carico:

  • HTTP, HTTPS o HTTP/2. Se le VM di backend gestiscono il traffico utilizzando HTTP, HTTPS o HTTP/2, è consigliabile utilizzare un controllo di integrità che corrisponda a quel protocollo, perché i controlli di integrità basati su HTTP offrono opzioni appropriate per quel protocollo. L'invio di traffico di tipo HTTP tramite un bilanciatore del carico di rete passthrough interno significa che il protocollo del bilanciatore del carico è TCP.
  • SSL o TCP. Se le VM di backend non gestiscono il traffico di tipo HTTP, ti consigliamo di utilizzare un controllo di integrità SSL o TCP.

Indipendentemente dal tipo di controllo di integrità che crei, Google Cloud invia probe del controllo di integrità all'indirizzo IP della regola di forwarding del bilanciatore del carico di rete passthrough interno, all'interfaccia di rete nella rete VPC selezionata dal servizio di backend del bilanciatore del carico. Simula il modo in cui viene distribuito il traffico con bilanciamento del carico. Il software in esecuzione sulle VM di backend deve rispondere sia al traffico bilanciato del carico sia ai probe di controllo di integrità inviati all'indirizzo IP di ogni regola di forwarding (il software deve essere in ascolto su 0.0.0.0:_port_ e non su un indirizzo IP specifico assegnato a un'interfaccia di rete). Per saperne di più, consulta Destinazione dei pacchetti probe.

Controlli di integrità e traffico UDP

Google Cloud non offre un controllo di integrità che utilizza il protocollo UDP. Quando utilizzi un bilanciatore del carico di rete passthrough interno con traffico UDP, devi eseguire un servizio basato su TCP sulle VM di backend per fornire informazioni sul controllo di integrità.

In questa configurazione, le richieste client vengono bilanciate utilizzando il protocollo UDP e un servizio TCP viene utilizzato per fornire informazioni ai probe di controllo dell'integrità. Google Cloud Ad esempio, puoi eseguire un semplice server HTTP su ogni VM di backend che restituisce un codice di stato HTTP 200 a Google Cloud. In questo esempio, ti consigliamo di utilizzare la tua logica in esecuzione sulla VM di backend per assicurarti che il server HTTP restituisca 200 solo se il servizio UDP è configurato e in esecuzione correttamente.

Architettura ad alta disponibilità

Il bilanciatore del carico di rete passthrough interno è progettato per essere a disponibilità elevata. Non sono previsti passaggi speciali per rendere il bilanciatore del carico ad alta disponibilità, perché il meccanismo non si basa su un singolo dispositivo o istanza VM.

Per eseguire il deployment delle istanze VM di backend in più zone, segui questi suggerimenti per il deployment:

Architettura VPC condiviso

La tabella seguente riassume i requisiti dei componenti per i bilanciatori del carico di rete pass-through interni utilizzati con le reti VPC condiviso. Per un esempio, vedi creazione di un bilanciatore del carico di rete passthrough interno nella pagina Provisioning di VPC condiviso.

Indirizzo IP Regola di forwarding Componenti di backend
Un indirizzo IP interno deve essere definito nello stesso progetto delle VM di backend.

Affinché il bilanciatore del carico sia disponibile in una rete VPC condiviso, l' Google Cloud indirizzo IP interno deve essere definito nello stesso progetto di servizio in cui si trovano le VM di backend e deve fare riferimento a una subnet nella rete VPC condiviso desiderata nel progetto host. L'indirizzo stesso proviene dall'intervallo IP principale della subnet a cui viene fatto riferimento.

Se crei un indirizzo IP interno in un progetto di servizio e la subnet dell'indirizzo IP si trova nella rete VPC del progetto di servizio, il bilanciatore del carico di rete pass-through interno è locale per il progetto di servizio. Il bilanciatore del carico di rete pass-through interno non è locale a nessun progetto host VPC condiviso.		 Una regola di forwarding interna deve essere definita nello stesso progetto delle VM di backend.

Affinché il bilanciatore del carico sia disponibile in una rete VPC condiviso, la regola di forwarding interno deve essere definita nello stesso progetto di servizio in cui si trovano le VM di backend e deve fare riferimento alla stessa subnet (nella rete VPC condiviso) a cui fa riferimento l'indirizzo IP interno associato.

Se crei una regola di forwarding interno in un progetto di servizio e la subnet della regola di forwarding si trova nella rete VPC del progetto di servizio, il bilanciatore del carico di rete passthrough interno è locale al progetto di servizio. Il bilanciatore del carico di rete pass-through interno non è locale a nessun progetto host VPC condiviso.		 In uno scenario VPC condiviso, le VM di backend si trovano in un progetto di servizio. Un servizio di backend interno regionale e un controllo di integrità devono essere definiti nel progetto di servizio.

Distribuzione del traffico

I bilanciatori del carico di rete passthrough interni supportano una serie di opzioni di personalizzazione della distribuzione del traffico, tra cui affinità sessione, monitoraggio delle connessioni e failover. Per informazioni dettagliate su come i bilanciatori del carico di rete passthrough interni distribuiscono il traffico e su come queste opzioni interagiscono tra loro, consulta Distribuzione del traffico per i bilanciatori del carico di rete passthrough interni.

Quote e limiti

Per informazioni su quote e limiti, consulta Quote delle risorse di bilanciamento del carico.

Limitazioni

  • Non puoi utilizzare la console Google Cloud per creare un bilanciatore del carico di rete passthrough interno con backend NEG di zona.

Passaggi successivi