Panoramica dei gruppi di endpoint di rete con connettività ibrida

Cloud Load Balancing supporta il bilanciamento del carico del traffico verso gli endpoint che si estendono oltre Google Cloud, come data center on-premise e altri cloud pubblici, che puoi utilizzare per la connettività ibrida.

Una strategia ibrida è una soluzione pragmatica che consente di adattarsi alle mutevoli richieste del mercato e di modernizzare in modo incrementale le applicazioni. Potrebbe essere un deployment ibrido temporaneo per consentire la migrazione a una soluzione moderna basata su cloud o un elemento fisso dell'infrastruttura IT della tua organizzazione.

La configurazione del bilanciamento del carico ibrido consente inoltre di applicare i vantaggi delle funzionalità di networking di Cloud Load Balancing ai servizi in esecuzione sulla tua infrastruttura esistente al di fuori di Google Cloud.

Il bilanciamento del carico ibrido è supportato sui seguenti bilanciatori del carico Google Cloud:

I servizi on-premise e gli altri servizi cloud vengono trattati come qualsiasi altro backend di Cloud Load Balancing. La differenza principale è che utilizzi un NEG di connettività ibrida per configurare gli endpoint di questi backend. Gli endpoint devono essere combinazioni IP:port valide che il bilanciatore del carico può raggiungere utilizzando prodotti di connettività ibrida come Cloud VPN o Cloud Interconnect.

Caso d'uso: routing del traffico a una località on-premise o a un altro cloud

Il caso d'uso più semplice per l'utilizzo di NEG ibridi è instradare il traffico da un bilanciatore del carico Google Cloud a una località on-premise o a un altro ambiente cloud. I client possono provenire dal traffico sia dalla rete internet pubblica, dall'interno di Google Cloud che da un client on-premise.

Clienti pubblici

Puoi utilizzare un bilanciatore del carico delle applicazioni esterno con un backend NEG ibrido per instradare il traffico da client esterni a un backend on-premise o in un'altra rete cloud. Puoi anche abilitare le seguenti funzionalità di networking a valore aggiunto per i tuoi servizi on-premise o in altre reti cloud:

  • Con il bilanciatore del carico delle applicazioni esterno globale e il bilanciatore del carico delle applicazioni classico, puoi:

    • Utilizza l'infrastruttura perimetrale globale di Google per terminare le connessioni utente più vicine all'utente, diminuendo così la latenza.
    • Proteggi il tuo servizio con Google Cloud Armor, un prodotto di sicurezza WAF/per la difesa perimetrale dagli attacchi DDoS disponibile per tutti i servizi a cui si accede tramite un bilanciatore del carico delle applicazioni esterno.
    • Abilita il servizio per ottimizzare la distribuzione utilizzando Cloud CDN. Con Cloud CDN, puoi memorizzare nella cache i contenuti vicini ai tuoi utenti. Cloud CDN offre funzionalità come l'annullamento della convalida della cache e gli URL firmati da Cloud CDN.
    • Utilizza i certificati SSL gestiti da Google. Puoi riutilizzare i certificati e le chiavi private che già utilizzi per altri prodotti Google Cloud. In questo modo non sarà più necessario gestire certificati separati.

    Il seguente diagramma mostra un deployment ibrido con un bilanciatore del carico delle applicazioni esterno.

    Connettività ibrida con un bilanciatore del carico delle applicazioni esterno globale.
    Connettività ibrida con un bilanciatore del carico delle applicazioni esterno globale (fai clic per ingrandire).

    In questo diagramma, il traffico proveniente dai client sulla rete internet pubblica entra nella tua rete privata on-premise o cloud tramite un bilanciatore del carico di Google Cloud, come l'Application Load Balancer esterno. Quando il traffico raggiunge il bilanciatore del carico, puoi applicare servizi perimetrali di rete come la protezione DDoS di Google Cloud Armor o l'autenticazione utente Identity-Aware Proxy (IAP).

  • Con il bilanciatore del carico delle applicazioni esterno regionale, puoi instradare il traffico esterno a endpoint che si trovano all'interno della stessa regione Google Cloud delle risorse del bilanciatore del carico. Utilizza questo bilanciatore del carico se devi pubblicare contenuti da una sola geolocalizzazione (ad esempio per soddisfare le normative di conformità) o se è desiderato il Livello di servizio di rete Standard.

Il modo in cui la richiesta viene instradata (a un backend Google Cloud o a un endpoint on-premise/cloud) dipende dal modo in cui è configurata la mappa URL. A seconda della mappa URL, il bilanciatore del carico seleziona un servizio di backend per la richiesta. Se il servizio di backend selezionato è stato configurato con un NEG di connettività ibrida (utilizzato solo per endpoint non Google Cloud), il bilanciatore del carico inoltra il traffico attraverso Cloud VPN o Cloud Interconnect alla destinazione esterna prevista.

Client interni (in Google Cloud o on-premise)

Puoi anche configurare un deployment ibrido per i client interni a Google Cloud. In questo caso, il traffico client proviene dalla rete VPC di Google Cloud, dalla tua rete on-premise o da un altro cloud e viene instradato a endpoint on-premise o in altre reti cloud.

L'Application Load Balancer interno regionale è un bilanciatore del carico a livello di regione, il che significa che può instradare il traffico solo verso endpoint all'interno della stessa regione Google Cloud delle risorse del bilanciatore del carico. L'Application Load Balancer interno tra regioni è un bilanciatore del carico multiregionale in grado di bilanciare il carico del traffico verso i servizi di backend distribuiti a livello globale.

Il seguente diagramma mostra un deployment ibrido con un bilanciatore del carico delle applicazioni interno regionale.

Connettività ibrida con bilanciatori del carico delle applicazioni interni regionali.
Connettività ibrida con bilanciatori del carico delle applicazioni interni regionali (fai clic per ingrandire).

Caso d'uso: Migrate to Cloud

La migrazione di un servizio esistente al cloud consente di liberare capacità on-premise e di ridurre i costi e gli oneri del mantenimento dell'infrastruttura on-premise. Puoi configurare temporaneamente un deployment ibrido che ti consenta di instradare il traffico sia al servizio on-premise attuale sia a un endpoint di servizio Google Cloud corrispondente.

Il seguente diagramma illustra questa configurazione con un bilanciatore del carico delle applicazioni interno.

Esegui la migrazione a Google Cloud.
Esegui la migrazione a Google Cloud (fai clic per ingrandire).

Se utilizzi un bilanciatore del carico delle applicazioni interno per gestire i client interni, puoi configurare il bilanciatore del carico Google Cloud in modo che utilizzi la suddivisione del traffico basata sul peso per suddividere il traffico tra i due servizi. La suddivisione del traffico consente di iniziare inviando lo 0% del traffico al servizio Google Cloud e il 100% al servizio on-premise. Puoi quindi aumentare gradualmente la proporzione di traffico inviato al servizio Google Cloud. Alla fine, invierai il 100% del traffico al servizio Google Cloud e potrai ritirare il servizio on-premise.

Architettura ibrida

Questa sezione descrive l'architettura di bilanciamento del carico e le risorse necessarie per configurare un deployment di bilanciamento del carico ibrido.

I servizi on-premise e gli altri servizi cloud sono come qualsiasi altro backend di Cloud Load Balancing. La differenza principale è che utilizzi un NEG di connettività ibrida per configurare gli endpoint di questi backend. Gli endpoint devono essere combinazioni IP:port valide che i client possono raggiungere tramite la connettività ibrida, come Cloud VPN o Cloud Interconnect.

I seguenti diagrammi mostrano le risorse Google Cloud necessarie per abilitare il bilanciamento del carico ibrido per bilanciatori del carico delle applicazioni esterni e Application Load Balancer interni regionali.

HTTP(S) esterno globale

Risorse del bilanciatore del carico delle applicazioni esterno globale per la connettività ibrida.
Risorse del bilanciatore del carico delle applicazioni esterno globale per la connettività ibrida (fai clic per ingrandire).

HTTP(S) esterno regionale

Risorse dell'Application Load Balancer esterno regionale per la connettività ibrida.
Risorse del bilanciatore del carico delle applicazioni esterno regionale per la connettività ibrida (fai clic per ingrandire).

HTTP(S) interno a livello di regione

Risorse dell'Application Load Balancer interno regionale per la connettività ibrida.
Risorse del bilanciatore del carico delle applicazioni interno regionale per la connettività ibrida (fai clic per ingrandire).

Proxy interno a livello di regione

Risorse del bilanciatore del carico di rete proxy interno regionale per la connettività ibrida.
Risorse del bilanciatore del carico di rete proxy interno regionale per la connettività ibrida (fai clic per ingrandire).

Regionale e globale

Il routing di Cloud Load Balancing dipende dall'ambito del bilanciatore del carico configurato:

Bilanciatore del carico delle applicazioni esterno e bilanciatore del carico di rete proxy esterno. Questi bilanciatori del carico possono essere configurati per il routing globale o a livello di regione in base al livello di rete utilizzato. Il backend NEG ibrido del bilanciatore del carico viene creato nella stessa rete e nella stessa regione in cui è stata configurata la connettività ibrida. Anche gli endpoint non Google Cloud devono essere configurati di conseguenza per sfruttare il bilanciamento del carico basato su prossimità.

Bilanciatore del carico delle applicazioni interno tra regioni e bilanciatore del carico di rete proxy interno tra regioni. Si tratta di un bilanciatore del carico su più regioni in grado di bilanciare il carico del traffico verso i servizi di backend distribuiti a livello globale. Il backend NEG ibrido del bilanciatore del carico viene creato nella stessa rete e nella stessa regione in cui è stata configurata la connettività ibrida. Anche gli endpoint non Google Cloud devono essere configurati di conseguenza per sfruttare il bilanciamento del carico basato su prossimità.

Bilanciatore del carico delle applicazioni interno regionale e bilanciatore del carico di rete proxy interno regionale. Questi sono bilanciatori del carico a livello di regione. Possono instradare il traffico solo verso endpoint all'interno della stessa regione del bilanciatore del carico. I componenti del bilanciatore del carico devono essere configurati nella stessa regione in cui è stata configurata la connettività ibrida. Per impostazione predefinita, anche i client che accedono al bilanciatore del carico devono trovarsi nella stessa regione. Tuttavia, se abiliti l'accesso globale, i client di qualsiasi regione possono accedere al bilanciatore del carico.

Ad esempio, se il gateway Cloud VPN o il collegamento VLAN di Cloud Interconnect è configurato in us-central1, le risorse richieste dal bilanciatore del carico (come un servizio di backend, un NEG ibrido o una regola di forwarding) devono essere create nella regione us-central1. Per impostazione predefinita, anche i client che accedono al bilanciatore del carico devono trovarsi nella regione us-central1. Tuttavia, se abiliti l'accesso globale, i client di qualsiasi regione possono accedere al bilanciatore del carico.

Requisiti per la connettività di rete

Prima di configurare un deployment del bilanciamento del carico ibrido, devi aver configurato le seguenti risorse:

  • Rete VPC Google Cloud. Una rete VPC configurata all'interno di Google Cloud. Questa è la rete VPC utilizzata per configurare Cloud Interconnect/Cloud VPN e il router Cloud. È anche la stessa rete in cui creerai le risorse di bilanciamento del carico (regola di forwarding, proxy di destinazione, servizio di backend e così via). Gli indirizzi IP e gli intervalli di indirizzi IP di subnet on-premise, di altri cloud e Google Cloud non devono sovrapporsi. Quando gli indirizzi IP si sovrappongono, le route di subnet hanno la priorità sulla connettività remota.

  • Connettività ibrida. Google Cloud e gli ambienti on-premise o altri ambienti cloud devono essere connessi tramite connettività ibrida, utilizzando collegamenti VLAN per Cloud Interconnect o tunnel Cloud VPN con il router Cloud. Ti consigliamo di utilizzare una connessione ad alta disponibilità. Un router Cloud abilitato con il routing dinamico globale apprende l'endpoint specifico tramite BGP e lo programma nella tua rete VPC Google Cloud. Il routing dinamico a livello di regione non è supportato. Anche le route statiche non sono supportate.

    Cloud Interconnect/Cloud VPN e il router Cloud devono essere configurati nella stessa rete VPC che intendi utilizzare per il deployment del bilanciamento del carico ibrido. Il router Cloud deve anche pubblicizzare le seguenti route verso il tuo ambiente on-premise:

    • Intervalli utilizzati dai probe del controllo di integrità di Google: 35.191.0.0/16 e 130.211.0.0/22. Questo attributo è obbligatorio per i bilanciatori del carico delle applicazioni esterni globali, gli Application Load Balancer classici, i bilanciatori del carico di rete con proxy esterno globale e i bilanciatori del carico di rete proxy classici.

    • L'intervallo della subnet solo proxy della regione: per bilanciatori del carico basati su Envoy: Application Load Balancer esterni regionali, bilanciatori del carico di rete con proxy esterno regionale, bilanciatori del carico di rete proxy interni regionali e Application Load Balancer interni.

      Per il corretto funzionamento dei controlli di integrità Envoy distribuiti, è necessaria anche la subnet solo proxy della regione pubblicitaria. Il controllo di integrità distribuito Envoy è il meccanismo di controllo di integrità predefinito per i NEGS di connettività ibrida di zona (ovvero, NON_GCP_PRIVATE_IP_PORT endpoint) dietro bilanciatori del carico basati su Envoy.

  • Endpoint di rete (IP:Port) on-premise o in altri cloud. Uno o più endpoint di rete IP:Port configurati all'interno di ambienti on-premise o cloud, instradabili tramite Cloud Interconnect o Cloud VPN. Se sono presenti più percorsi per l'endpoint IP, il routing seguirà il comportamento descritto nella panoramica delle route VPC e nella panoramica del router Cloud.

  • Regole firewall on-premise o in altri cloud. Le seguenti regole firewall devono essere create nell'ambiente on-premise o in un altro ambiente cloud:

    • In entrata, le regole firewall consentono il traffico dai probe di controllo di integrità di Google ai tuoi endpoint. Gli intervalli consentiti sono: 35.191.0.0/16 e 130.211.0.0/22. Tieni presente che questi intervalli devono essere pubblicizzati dal router Cloud sulla tua rete on-premise. Per maggiori dettagli, consulta Eseguire indagini su intervalli IP e regole firewall.
    • In entrata, le regole firewall consentono al traffico con bilanciamento del carico di raggiungere gli endpoint.
    • Per bilanciatori del carico basati su Envoy: Application Load Balancer esterni regionali, bilanciatori del carico di rete con proxy esterno regionale, bilanciatori del carico di rete con proxy interno regionale e Application Load Balancer interni, devi anche creare una regola firewall per consentire al traffico dalla subnet solo proxy dell'area di raggiungere gli endpoint on-premise o in altri ambienti cloud.

Componenti del bilanciatore del carico

A seconda del tipo di bilanciatore del carico, puoi configurare il deployment di un bilanciamento del carico ibrido utilizzando il livello Standard o Premium di Network Service Tiers.

Un bilanciatore del carico ibrido richiede una configurazione speciale solo per il servizio di backend. La configurazione frontend è uguale a quella di qualsiasi altro bilanciatore del carico. I bilanciatori del carico basati su Envoy, come Application Load Balancer esterni regionali, bilanciatori del carico di rete con proxy esterno regionale, bilanciatori del carico di rete con proxy interno regionale, bilanciatori del carico di rete interni tra regioni e Application Load Balancer interni, richiedono un'ulteriore subnet solo proxy per eseguire i proxy Envoy per tuo conto.

Configurazione frontend

Non è richiesta alcuna configurazione frontend speciale per il bilanciamento del carico ibrido. Le regole di forwarding vengono utilizzate per instradare il traffico a un proxy di destinazione in base a indirizzo IP, porta e protocollo. Il proxy di destinazione termina quindi le connessioni dai client.

Le mappe URL vengono utilizzate dai bilanciatori del carico HTTP(S) per configurare il routing basato su URL delle richieste ai servizi di backend appropriati.

Per maggiori dettagli su ciascuno di questi componenti, consulta le sezioni sull'architettura delle panoramiche specifiche del bilanciatore del carico:

Servizio di backend

I servizi di backend forniscono informazioni di configurazione al bilanciatore del carico. I bilanciatori del carico utilizzano le informazioni in un servizio di backend per indirizzare il traffico in entrata a uno o più backend collegati.

Per impostare un deployment del bilanciamento del carico ibrido, devi configurare il bilanciatore del carico con backend che siano sia all'interno di Google Cloud che all'esterno di Google Cloud.

  • Backend non Google Cloud (on-premise o di altro tipo su cloud)

    Qualsiasi destinazione raggiungibile con i prodotti per la connettività ibrida di Google (Cloud VPN o Cloud Interconnect) e raggiungibile con una combinazione IP:Port valida può essere configurata come endpoint per il bilanciatore del carico.

    Configura i backend non Google Cloud come segue:

    1. Aggiungi la combinazione IP:Port di ogni endpoint di rete non Google Cloud a un gruppo di endpoint di rete con connettività ibrida (NEG). Assicurati che l'indirizzo IP e la porta siano raggiungibili da Google Cloud utilizzando la connettività ibrida (tramite Cloud VPN o Cloud Interconnect). Per i NEG di connettività ibrida, imposta il tipo di endpoint di rete su NON_GCP_PRIVATE_IP_PORT.
    2. Durante la creazione del NEG, specifica una zona Google Cloud che riduce al minimo la distanza geografica tra Google Cloud e il tuo ambiente on-premise o un altro ambiente cloud. Ad esempio, se ospiti un servizio in un ambiente on-premise a Francoforte, in Germania, puoi specificare la zona Google Cloud europe-west3-a quando crei il NEG.

    3. Aggiungi questo NEG di connettività ibrida come backend per il servizio di backend.

      Un NEG di connettività ibrida deve includere solo endpoint non Google Cloud. Il traffico potrebbe essere ignorato se un NEG ibrido include endpoint per le risorse all'interno di una rete VPC di Google Cloud, ad esempio gli indirizzi IP regola di forwarding per i bilanciatori del carico di rete passthrough interni. Configura gli endpoint Google Cloud come indicato nella prossima sezione.

  • Backend di Google Cloud

    Configura gli endpoint Google Cloud come segue:

    1. Creare un servizio di backend separato per i backend di Google Cloud.
    2. Configura più backend (GCE_VM_IP_PORT NEG di zona o gruppi di istanze) all'interno della stessa regione in cui hai configurato la connettività ibrida.

Punti aggiuntivi da considerare:

  • Ogni NEG di connettività ibrida può contenere solo endpoint di rete dello stesso tipo (NON_GCP_PRIVATE_IP_PORT).

  • Puoi utilizzare un singolo servizio di backend per fare riferimento sia ai backend basati su Google Cloud (utilizzando NEG a livello di zona con GCE_VM_IP_PORT endpoint) che a backend on-premise o altri backend cloud (utilizzando NEG di connettività ibrida con endpoint NON_GCP_PRIVATE_IP_PORT). Non è consentita nessun'altra combinazione di tipi di backend misti. Traffic Director non supporta i tipi di backend misti in un unico servizio di backend.

  • Lo schema di bilanciamento del carico del servizio di backend deve essere uno dei seguenti:

    • EXTERNAL_MANAGED per bilanciatori del carico delle applicazioni esterni globali, Application Load Balancer esterni regionali, bilanciatori del carico di rete con proxy esterno globale e bilanciatori del carico di rete con proxy esterno regionale
    • EXTERNAL per bilanciatori del carico delle applicazioni classici e bilanciatori del carico di rete proxy classici
    • INTERNAL_MANAGED per bilanciatori del carico delle applicazioni interni, bilanciatore del carico di rete proxy interno tra regioni, bilanciatori del carico di rete proxy interni regionali e bilanciatori del carico di rete proxy interni regionali

    INTERNAL_SELF_MANAGED è supportato per i deployment multi-ambiente di Traffic Director con NEG di connettività ibrida.

  • Il protocollo del servizio di backend deve essere HTTP, HTTPS o HTTP2 per gli Application Load Balancer e TCP o SSL per i bilanciatori del carico di rete del proxy esterno e i bilanciatori del carico di rete del proxy interno regionale. Per l'elenco dei protocolli dei servizio di backend supportati da ciascun bilanciatore del carico, consulta Protocolli dal bilanciatore del carico al backend.

  • La modalità di bilanciamento per il backend NEG ibrido deve essere RATE per gli Application Load Balancer esterni ed interni e CONNECTION per il bilanciatore del carico di rete proxy interno regionale e i bilanciatori del carico di rete proxy esterni. Per maggiori dettagli sulle modalità di bilanciamento, consulta la panoramica dei servizi di backend.

  • Per aggiungere altri endpoint di rete, aggiorna i backend collegati al tuo servizio di backend.

  • Se utilizzi controlli di integrità Envoy distribuiti con NEG di connettività ibrida di zona (ovvero NON_GCP_PRIVATE_IP_PORT) dietro bilanciatori del carico basati su Envoy, non configurare lo stesso endpoint di rete in più NEG collegati a un servizio di backend. Ciò porta a un comportamento indefinito.

Controlli di integrità centralizzati

I controlli di integrità centralizzati, se si utilizzano NEG ibridi, sono obbligatori per bilanciatori del carico delle applicazioni esterni globali, bilanciatori del carico delle applicazioni classici, bilanciatori del carico di rete con proxy esterno globale e bilanciatori del carico di rete proxy classici. Altri bilanciatori del carico basati su Envoy utilizzano controlli di integrità Envoy distribuiti come descritto nella sezione seguente.

Per gli endpoint NON_GCP_PRIVATE_IP_PORT esterni a Google Cloud, crea regole firewall sulle tue reti on-premise e su altre reti cloud. Contatta l'amministratore di rete per questa richiesta. Il router Cloud utilizzato per la connettività ibrida deve pubblicizzare anche gli intervalli utilizzati dai probe di controllo di integrità di Google. Gli intervalli da pubblicizzare sono 35.191.0.0/16 e 130.211.0.0/22.

Per altri tipi di backend in Google Cloud, crea regole firewall su Google Cloud come mostrato in questo esempio.

Documentazione correlata:

Controlli di integrità Envoy distribuiti

La configurazione del controllo di integrità varia in base al tipo di bilanciatore del carico:

  • Bilanciatore del carico delle applicazioni esterno globale, bilanciatore del carico delle applicazioni classico, bilanciatore del carico di rete con proxy esterno globale e bilanciatore del carico di rete proxy classico. Questi bilanciatori del carico non supportano i controlli di integrità di Envoy distribuiti. Utilizzano il meccanismo di controllo di integrità centralizzato di Google, come descritto nella sezione Controlli di integrità centralizzati.

  • Bilanciatore del carico delle applicazioni esterno regionale, bilanciatore del carico delle applicazioni interno (tra regioni e regioni), bilanciatore del carico di rete proxy esterno regionale, bilanciatore del carico di rete proxy interno tra regioni e bilanciatore del carico di rete proxy interno regionale. Questi bilanciatori del carico utilizzano i controlli di integrità di Envoy distribuiti per controllare l'integrità dei NEG ibridi. I probe del controllo di integrità provengono dallo stesso software proxy Envoy. Ogni servizio di backend deve essere associato a un controllo di integrità che verifica l'integrità dei backend. I probe del controllo di integrità hanno origine dai proxy Envoy nella subnet solo proxy della regione. Affinché i probe del controllo di integrità funzionino correttamente, devi creare regole firewall nell'ambiente esterno che consentano al traffico dalla subnet solo proxy di raggiungere i backend esterni.

    Per gli endpoint NON_GCP_PRIVATE_IP_PORT esterni a Google Cloud, devi creare queste regole firewall sulle tue reti on-premise e su altre reti cloud. Contatta l'amministratore di rete per questa richiesta. Il router Cloud che utilizzi per la connettività ibrida deve pubblicizzare anche l'intervallo di subnet solo proxy della regione.

I controlli di integrità distribuiti da Envoy vengono creati utilizzando la stessa console Google Cloud, gcloud CLI e gli stessi processi API dei controlli di integrità centralizzati. Non sono necessarie altre configurazioni.

Aspetti da considerare:

  • I controlli di integrità gRPC non sono supportati.
  • I controlli di integrità con il protocollo PROXY v1 abilitato non sono supportati.
  • Se utilizzi NEG misti dove un singolo servizio di backend ha una combinazione di NEG a livello di zona (GCE_VM_IP_PORT endpoint in Google Cloud) e NEG ibridi (NON_GCP_PRIVATE_IP_PORT endpoint esterni a Google Cloud), devi configurare regole firewall per consentire il traffico dagli intervalli IP dei probe del controllo di integrità di Google (130.211.0.0/22 e 35.191.0.0/16) verso gli endpoint NEG di zona su Google Cloud. Questo perché i NEG di zona utilizzano il sistema di controllo di integrità centralizzato di Google.

  • Poiché il piano dati Envoy gestisce i controlli di integrità, non puoi utilizzare la console Google Cloud, l'API o gcloud CLI per controllare lo stato di integrità di questi endpoint esterni. Per i NEG ibridi con bilanciatori del carico basati su Envoy, la console Google Cloud mostra lo stato del controllo di integrità come N/A. È previsto.

  • Ogni proxy Envoy assegnato alla subnet solo proxy nella regione della rete VPC avvia i controlli di integrità in modo indipendente. Pertanto, potresti notare un aumento del traffico di rete a causa del controllo di integrità. L'aumento dipende dal numero di proxy Envoy assegnati alla rete VPC in una regione, dalla quantità di traffico ricevuto da questi proxy e dal numero di endpoint di cui ogni proxy Envoy ha bisogno per il controllo di integrità. Nel peggiore dei casi, il traffico di rete a causa dei controlli di integrità aumenta con una frequenza quadratica di (O(n^2)).

  • I log dei controlli di integrità per i controlli di integrità Envoy distribuiti non includono stati di integrità dettagliati. Per maggiori dettagli su cosa viene registrato, vedi Registrazione del controllo di integrità. Per risolvere ulteriormente i problemi di connettività dai proxy Envoy ai tuoi endpoint NEG, devi anche controllare i rispettivi log del bilanciatore del carico.

Documentazione correlata:

Limitazioni

  • Il router Cloud utilizzato per la connettività ibrida deve essere abilitato con il routing dinamico globale. Il routing dinamico a livello di regione e le route statiche non sono supportati.
  • Per i bilanciatori del carico a livello di regione basati su Envoy, come Application Load Balancer esterni regionali, i bilanciatori del carico di rete con proxy esterno regionale, i bilanciatori del carico di rete del proxy interno regionale e gli Application Load Balancer interni regionali, la connettività ibrida deve essere configurata nella stessa regione del bilanciatore del carico. Se sono configurati in regioni diverse, potresti vedere i backend in stato integro, ma le richieste del client non verranno inoltrate ai backend.

  • Le considerazioni sulle connessioni criptate dal bilanciatore del carico ai backend documentate qui si applicano anche agli endpoint di backend non Google Cloud configurati nel NEG di connettività ibrida.

    Assicurati di rivedere anche le impostazioni di sicurezza della configurazione della connettività ibrida. Attualmente, le connessioni VPN ad alta disponibilità sono criptate per impostazione predefinita (IPsec). Le connessioni Cloud Interconnect non sono criptate per impostazione predefinita. Per maggiori dettagli, consulta il white paper Crittografia dei dati in transito.

Logging

Le richieste inviate tramite proxy a un endpoint in un NEG ibrido vengono registrate in Cloud Logging nello stesso modo in cui vengono registrate le richieste per altri backend. Se abiliti Cloud CDN per il tuo bilanciatore del carico delle applicazioni esterno globale, vengono registrati anche gli hit della cache.

Per ulteriori informazioni, vedi:

Quota

Puoi configurare il numero di NEG ibridi con endpoint di rete consentito dalla quota di gruppi di endpoint di rete esistente. Per ulteriori informazioni, consulta Backend NEG ed Endpoint per NEG.

Passaggi successivi