Panoramica dei gruppi di endpoint di rete con connettività ibrida

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

Una strategia ibrida è una soluzione pragmatica per adattarsi ai cambiamenti del mercato e modernizzare in modo incrementale le applicazioni. Potrebbe trattarsi di un caso per consentire la migrazione a un ambiente moderno basato su cloud o un impianto permanente dell'infrastruttura IT della tua organizzazione.

La configurazione del bilanciamento del carico ibrido ti consente inoltre di sfruttare i vantaggi le funzionalità di networking di Cloud Load Balancing nei servizi in esecuzione l'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 il backend di Cloud Load Balancing. La differenza principale è che utilizzi una NEG di connettività ibrida per configurare gli endpoint di questi backend. La gli endpoint devono essere combinazioni IP:port valide che il bilanciatore del carico può raggiungere utilizzando prodotti per la connettività ibrida come Cloud VPN e 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 è il routing del traffico da un Google Cloud a una località on-premise in un altro ambiente cloud. I client possono provenire dal traffico sulla rete internet pubblica da Google Cloud o da un client on-premise.

Client pubblici

Puoi utilizzare un bilanciatore del carico delle applicazioni esterno con un backend NEG ibrido per instradare il traffico da in un backend on-premise o in un'altra rete cloud. Puoi attivare anche 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 chiudere le connessioni degli utenti più vicino per l'utente, diminuendo così la latenza.
    • Proteggi il tuo servizio con Google Cloud Armor, una difesa DDoS/WAF perimetrale un prodotto per la sicurezza online di tutti i servizi a cui si accede tramite un bilanciatore del carico delle applicazioni esterno.
    • Abilita il tuo servizio per ottimizzare la distribuzione utilizzando Cloud CDN. Con Cloud CDN, puoi memorizzare i contenuti nella cache vicino agli utenti. Cloud CDN offre funzionalità come l'annullamento della convalida della cache URL firmati di Cloud CDN.
    • Utilizza SSL gestito da Google certificati. Tu può riutilizzare certificati e chiavi private che usi già per altri prodotti Google Cloud. In questo modo 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 dai client sulla rete internet pubblica entra alla tua rete on-premise o cloud privata mediante un carico Google Cloud ad esempio il bilanciatore del carico delle applicazioni esterno. Quando il traffico raggiunge il carico puoi applicare servizi perimetrali della rete come DDoS di Google Cloud Armor protezione avanzata o autenticazione utente di Identity-Aware Proxy (IAP).

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

Modalità di routing della richiesta (verso un backend Google Cloud o on-premise/cloud) dipende da come è configurata la mappa URL. A seconda Sulla 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 su Cloud VPN o Cloud Interconnect verso la destinazione esterna prevista.

Client interni (all'interno di Google Cloud o on-premise)

Puoi anche configurare un deployment ibrido per i client interni in Google Cloud. In questo caso, il traffico dei clienti proviene dalla dalla rete VPC di Google Cloud, dalla rete on-premise in un altro cloud, ed è instradato verso endpoint on-premise o in un altro cloud reti.

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

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: eseguire la migrazione a Cloud

La migrazione di un servizio esistente nel cloud consente di liberare spazio on-premise capacità di archiviazione, nonché di ridurre i costi e l'onere del mantenimento in loco dell'infrastruttura. Puoi configurare temporaneamente un deployment ibrido che ti consenta per instradare il traffico sia al servizio on-premise attuale sia a dell'endpoint di servizio Google Cloud.

Il seguente diagramma mostra 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 per utilizzare il traffico basato sul peso per suddividere il traffico tra i due servizi. La suddivisione del traffico ti consente inizia inviando lo 0% del traffico al servizio Google Cloud e il 100% alla on-premise. Puoi quindi aumentare gradualmente la proporzione di traffico inviate al servizio Google Cloud. Alla fine, invii il 100% del traffico a il 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 tutti il backend di Cloud Load Balancing. La differenza principale è che utilizzi una NEG di connettività ibrida per configurare gli endpoint di questi backend. La gli endpoint devono essere combinazioni IP:port valide che i clienti possono raggiungere tramite connettività ibrida, come Cloud VPN e Cloud Interconnect.

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

HTTP(S) esterno globale

Risorse del bilanciatore del carico delle applicazioni esterno globali 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 del bilanciatore del carico delle applicazioni 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 regionale

Risorse del bilanciatore del carico delle applicazioni 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 carico configurato bilanciatore del carico:

Bilanciatore del carico delle applicazioni esterno e bilanciatore del carico di rete proxy esterno. Questi bilanciatori del carico possono configurato per il routing globale o regionale a seconda del livello di rete viene utilizzato. Creerai il backend NEG ibrido del bilanciatore del carico nello stesso e la regione in cui è stata configurata la connettività ibrida. Anche gli endpoint non Google Cloud devono essere configurati di conseguenza il vantaggio del bilanciamento del carico basato sulla 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 multiregionale in grado di bilanciare il carico del traffico verso i servizi di backend che sono distribuiti a livello globale. Creerai il backend NEG ibrido del bilanciatore del carico in la stessa rete e la stessa regione in cui è stata configurata la connettività ibrida. Anche gli endpoint non Google Cloud devono essere configurati di conseguenza il vantaggio del bilanciamento del carico basato sulla prossimità.

Bilanciatore del carico delle applicazioni interno regionale e bilanciatore del carico di rete proxy interno regionale. Si tratta di di bilanciatori del carico regionali. Ciò significa che possono solo instradare il traffico agli endpoint della stessa regione del bilanciatore del carico. I componenti del bilanciatore del carico devono 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 potranno accedere con il bilanciatore del carico di rete passthrough esterno regionale.

Ad esempio, se il gateway Cloud VPN o Cloud Interconnect Il collegamento VLAN è configurato in us-central1, le risorse richieste da il bilanciatore del carico (come un servizio di backend, un NEG ibrido o una regola di forwarding) deve nella regione us-central1. Per impostazione predefinita, i client che accedono al carico Il bilanciatore del carico deve inoltre trovarsi nella regione us-central1. Se invece attivi le impostazioni globali i client di ogni regione possono accedere al bilanciatore del carico.

Requisiti per la connettività di rete

Prima di configurare un deployment con bilanciamento del carico ibrido, devi disporre le seguenti risorse:

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

  • Connettività ibrida. Google Cloud e l'infrastruttura on-premise Gli ambienti cloud devono essere connessi tramite ibridi per la connettività, utilizzando Collegamenti VLAN Cloud Interconnect o tunnel Cloud VPN con router Cloud. Ti consigliamo di utilizzare una connessione ad alta disponibilità. Un router Cloud con funzionalità dinamiche globali calcolo itinerario apprende l'endpoint specifico tramite BGP e lo programma nel rete VPC di Google Cloud. Il routing dinamico a livello di regione è non supportati. Anche le route statiche non sono supportate.

    Cloud Interconnect/Cloud VPN e il router Cloud devono essere configurate nella stessa rete VPC che intendi utilizzare il deployment del bilanciamento del carico ibrido. Il router Cloud deve inoltre pubblicizza quanto segue route per dell'ambiente on-premise:

    • Intervalli utilizzati dai probe del controllo di integrità di Google: 35.191.0.0/16 e 130.211.0.0/22. È obbligatorio per i bilanciatori del carico delle applicazioni esterni globali, bilanciatori del carico delle applicazioni classici, bilanciatori del carico di rete con proxy esterno globali e bilanciatori del carico di rete proxy classici.

    • L'intervallo della subnet solo proxy della regione: per il carico basato su Envoy bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico di rete proxy esterni regionali, bilanciatori del carico di rete proxy interni regionali e bilanciatori del carico delle applicazioni interni.

      Affinché i controlli di integrità di Envoy distribuiti funzionino, è necessaria anche la subnet solo proxy della regione pubblicitaria. Il controllo di integrità di Envoy distribuito è il meccanismo di controllo di integrità predefinito per i NEGS di connettività ibrida a livello di zona (ossia NON_GCP_PRIVATE_IP_PORT endpoint) dietro i bilanciatori del carico basati su Envoy.

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

  • Regole firewall sul tuo ambiente on-premise o su un altro cloud. Il firewall che segue le regole devono essere create nell'ambiente on-premise o in un altro ambiente cloud:

    • Regole firewall di autorizzazione in entrata per consentire il traffico proveniente dal controllo di integrità di Google verso i 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 anche il router Cloud alla tua rete on-premise. Per ulteriori dettagli, consulta Probe IP intervalli e regole firewall.
    • Regole firewall di autorizzazione in entrata per consentire il traffico in fase di bilanciamento del carico per raggiungere gli endpoint.
    • Per il caricamento basato su Envoy bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico di rete proxy esterni regionali, bilanciatori del carico di rete proxy interni regionali, bilanciatori del carico di rete proxy interni tra regioni e dei bilanciatori del carico delle applicazioni interni, devi anche creare una regola firewall per consentire il traffico una subnet solo proxy a 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 un bilanciamento del carico ibrido il deployment utilizzando il livello Standard o Premium di Network Service Tiers.

Un bilanciatore del carico ibrido richiede una configurazione speciale solo per il backend Google Cloud. La configurazione del frontend è la stessa di qualsiasi altra con il bilanciatore del carico di rete passthrough esterno regionale. Il carico basato su Envoy bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico di rete proxy esterni regionali, bilanciatori del carico di rete proxy interni regionali, bilanciatori del carico di rete proxy interni tra regioni e Application Load Balancer interni: richiedono una subnet solo proxy aggiuntiva di eseguire 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 indirizzare il traffico per indirizzo IP, porta e protocollo a un proxy di destinazione. Il target proxy termina le connessioni clienti.

Le mappe URL vengono utilizzate dal caricamento HTTP(S) per configurare il routing basato su URL delle richieste al backend appropriato i servizi di machine learning.

Per ulteriori dettagli su ciascuno di questi componenti, fai riferimento alle sezioni relative all'architettura le panoramiche specifiche dei bilanciatori del carico:

Servizio di backend

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

Per configurare un deployment del bilanciamento del carico ibrido, devi configurare il bilanciatore del carico con backend che si trovano sia all'interno di Google Cloud, al di fuori di Google Cloud.

  • Backend non Google Cloud (on-premise o altri cloud)

    Qualsiasi destinazione raggiungibile con lo strumento ibrido di Google per la connettività (Cloud VPN Cloud Interconnect) e può essere raggiunto con un indirizzo IP:Port valido 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 (NEG) con connettività ibrida. Assicurati che questo IP e la porta siano raggiungibili da Google Cloud la connettività ibrida (tramite Cloud VPN o Cloud Interconnect). Per la connettività ibrida NEG, devi impostare il tipo di endpoint di rete su NON_GCP_PRIVATE_IP_PORT.
    2. Durante la creazione del NEG, specifica un indirizzo Google Cloud zona che riduce al minimo la distanza geografica tra Google Cloud e in un ambiente on-premise o in un altro ambiente cloud. Ad esempio, se ospiti un in un ambiente on-premise a Francoforte, in Germania, e specificare la zona Google Cloud europe-west3-a quando crei NEG.

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

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

  • Backend 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 a livello di zona o gruppi di istanze) all'interno della stessa regione in cui hai configurato e la connettività privata.

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 a Backend basati su Google Cloud (che utilizzano NEG a livello di zona con GCE_VM_IP_PORT endpoint) e backend on-premise o altri cloud (utilizzando la connettività ibrida) NEG con NON_GCP_PRIVATE_IP_PORT endpoint). Nessun'altra combinazione di combinazioni miste di backend sono consentiti. Cloud Service Mesh non supporta backend misti di backend in un singolo 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, bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico di rete proxy esterni globali e bilanciatori del carico di rete proxy esterni regionali
    • EXTERNAL per i bilanciatori del carico delle applicazioni classici e i bilanciatori del carico di rete proxy classici
    • INTERNAL_MANAGED per i bilanciatori del carico delle applicazioni interni, il bilanciatore del carico di rete proxy interno tra regioni, bilanciatori del carico di rete proxy interni tra regioni e bilanciatori del carico di rete proxy interni regionali

    INTERNAL_SELF_MANAGED è supportato per i deployment multi-ambiente di Cloud Service Mesh con connettività ibrida NEG.

  • Il protocollo del servizio di backend deve essere HTTP, HTTPS o HTTP2 per i bilanciatori del carico delle applicazioni e TCP o SSL per i bilanciatori del carico di rete proxy esterni e i bilanciatori del carico di rete proxy interni regionali. Per l'elenco dei servizio di backend Protocolli supportati da ciascun bilanciatore del carico, consulta Protocolli dal bilanciatore del carico di backend.

  • La modalità di bilanciamento per il backend NEG ibrido deve essere RATE per bilanciatori del carico delle applicazioni interni e CONNECTION per il bilanciatore del carico di rete proxy interno regionale e bilanciatori del carico di rete proxy esterni. Per maggiori dettagli sulle modalità di bilanciamento, consulta Panoramica dei servizi di backend.

  • Per aggiungere altri endpoint di rete, aggiorna i backend collegati al backend completamente gestito di Google Cloud.

  • Se utilizzi controlli di integrità di Envoy distribuiti con NEGS di connettività ibrida a livello di zona (ossia NON_GCP_PRIVATE_IP_PORT) in ritardo dai bilanciatori del carico basati su Envoy, non configurare lo stesso endpoint di rete più NEG collegati a un servizio di backend. Ciò porta alla mancata definizione comportamento degli utenti.

Controlli di integrità centralizzati

Quando si utilizzano NEG ibridi, sono richiesti controlli di integrità centralizzati per gli Application Load Balancer esterni globali, bilanciatori del carico delle applicazioni classici, bilanciatori del carico di rete con proxy esterno globali e bilanciatori del carico di rete proxy classici. Altri bilanciatori del carico basati su Envoy utilizzano controlli di integrità di Envoy distribuiti come descritto nella sezione che segue.

Per NON_GCP_PRIVATE_IP_PORT endpoint al di fuori di Google Cloud, e creare regole firewall sulle tue reti on-premise e su altre reti cloud. Contatta il tuo amministratore di rete. Il router Cloud utilizzato per l'ibrido la connettività deve pubblicizzare anche gli intervalli utilizzati dal controllo di integrità di Google e i sonde. Gli intervalli da pubblicizzare sono 35.191.0.0/16 e 130.211.0.0/22.

Per altri tipi di backend all'interno di Google Cloud, crea regole firewall Google Cloud come dimostrato in questa esempio.

Documentazione correlata:

Controlli di integrità di 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 proxy esterno globale e il bilanciatore del carico di rete proxy classico. Questi bilanciatori del carico non supportano Controlli di integrità di Envoy. Usano il controllo di integrità centralizzato di Google meccanismo come descritto nella sezione Integrità centralizzata controlli.

  • Bilanciatore del carico delle applicazioni esterno regionale, bilanciatore del carico delle applicazioni interno (tra regioni e regioni), Network Load Balancer proxy esterno regionale, Network Load Balancer proxy interno tra regioni e Network Load Balancer proxy esterno regionale Network Load Balancer proxy interno regionale. Questi vengono caricati i bilanciatori utilizzano i controlli di integrità di Envoy distribuiti per controllare l'integrità dei NEG ibridi. I probe del controllo di integrità provengono da Envoy software proxy stesso. Ciascuna servizio di backend deve essere associato a un controllo di integrità che dei backend. I probe del controllo di integrità provengono dai proxy Envoy nel una subnet solo proxy nella regione. Affinché i probe del controllo di integrità funzionino correttamente, devi creare un firewall nell'ambiente esterno che consentono il traffico solo per raggiungere i backend esterni.

    Per NON_GCP_PRIVATE_IP_PORT endpoint al di fuori di Google Cloud, devi creare queste regole firewall sia on-premise che su altri reti. Contatta il tuo amministratore di rete. La Il router Cloud che utilizzi per la connettività ibrida deve anche pubblicizzare la di subnet solo proxy della regione.

I controlli di integrità di Envoy distribuiti vengono creati utilizzando lo stesso Console Google Cloud, gcloud CLI e API processi come controlli di integrità centralizzati. Non sono richieste altre configurazioni.

Aspetti da considerare:

  • I controlli di integrità gRPC non sono supportati.
  • I controlli di integrità con protocollo PROXY v1 abilitato non sono supportati.
  • Se utilizzi NEG misti in cui 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 al di fuori di Google Cloud), devi configurare le regole firewall per consentire il traffico dall'IP del probe di controllo di integrità di Google intervalli (130.211.0.0/22 e 35.191.0.0/16) agli endpoint NEG a livello di zona in Google Cloud. Il motivo è che i NEG a livello di zona utilizzano di controllo dell'integrità.

  • Poiché il piano dati Envoy gestisce i controlli di integrità, non possono 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 nella La 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à. La dipende dal numero di proxy Envoy assegnati al tuo rete VPC in una regione, la quantità di traffico ricevuta questi proxy e il numero di endpoint necessari per ciascun proxy Envoy controllo di integrità. Nel peggiore dei casi, il traffico di rete è dovuto all'integrità aumenta con una percentuale quadratica del (O(n^2)).

  • I log dei controlli di integrità per i controlli di integrità di Envoy distribuiti non includono stati di integrità dettagliati. Per maggiori dettagli sui dati registrati, vedi Controllo di integrità il logging. Per andare oltre risolvere i problemi di connettività dai proxy Envoy agli endpoint NEG, e devi controllare anche i rispettivi log del bilanciatore del carico.

Documentazione correlata:

Limitazioni

  • Il router Cloud utilizzato per la connettività ibrida deve essere abilitato con l'impostazione globale dinamico di routing. Il routing dinamico a livello di regione e le route statiche non sono supportati.
  • Per il carico regionale basato su Envoy bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico di rete proxy esterni regionali, bilanciatori del carico di rete proxy interni regionali e Application Load Balancer interni regionali: la connettività ibrida deve essere configurato nella stessa regione del bilanciatore del carico. Se sono configurate in in regioni diverse, potresti vedere i backend in stato integro, ma le richieste del client non vengano inoltrati ai backend.

  • Le considerazioni per le connessioni criptate dal bilanciatore del carico i backend documentati qui si applicano anche agli endpoint di backend non Google Cloud configurati nel e il NEG di connettività ibrida.

    Assicurati di rivedere anche le impostazioni di sicurezza sulla connettività ibrida configurazione. Attualmente, le connessioni VPN ad alta disponibilità sono criptate predefinito (IPsec). Le connessioni Cloud Interconnect non sono criptate predefinito. Per ulteriori dettagli, consulta White paper sulla 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 attivi Cloud CDN per il bilanciatore del carico delle applicazioni esterno globale, vengono registrati anche gli hit della cache.

Per ulteriori informazioni, vedi:

Quota

Puoi configurare tutti i NEG ibridi con endpoint di rete, come consentito la quota esistente del gruppo di endpoint di rete. Per ulteriori informazioni, vedi Backend NEG e Endpoint per NEG.

Passaggi successivi