Panoramica dei gruppi di endpoint di rete a connettività ibrida

Cloud Load Balancing supporta il bilanciamento del carico del traffico verso endpoint che si estendono oltre il 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 ti consente di adattarti alle mutevoli esigenze del mercato e modernizzare in modo incrementale le tue applicazioni. Potrebbe essere un deployment ibrido temporaneo per consentire la migrazione a una soluzione moderna basata su cloud o un'installazione permanente dell'infrastruttura IT della tua organizzazione.

La configurazione del bilanciamento del carico ibrido consente anche di portare 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 nei seguenti bilanciatori del carico Google Cloud:

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

Il caso d'uso più semplice di questa funzionalità è il routing del traffico da un bilanciatore del carico Google Cloud a Google Cloud, una località on-premise o un altro cloud. I client possono provenire dal traffico Internet pubblico, dall'interno di Google Cloud o da un client on-premise.

Client pubblici

Puoi utilizzare il bilanciamento del carico HTTP(S) per instradare il traffico da client esterni a un backend in Google Cloud, on-premise o in un altro cloud. Con il bilanciamento del carico HTTP(S), puoi anche abilitare funzionalità di networking a valore aggiunto per i tuoi servizi on-prem. Puoi:

  • Utilizza l'infrastruttura perimetrale globale di Google per terminare le connessioni degli utenti più vicine all'utente e ridurre così la latenza.
  • Proteggi il tuo servizio con Google Cloud Armor, un prodotto per la difesa DDoS/sicurezza del perimetro disponibile per tutti i servizi a cui si accede tramite un bilanciatore del carico HTTP(S) esterno.
  • Attiva il tuo servizio per ottimizzare la distribuzione tramite Cloud CDN. Con Cloud CDN, puoi memorizzare nella cache i contenuti vicini agli utenti. Cloud CDN fornisce funzionalità come l'invalidazione della cache e gli URL firmati di 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. Ciò elimina la necessità di gestire certificati separati.

Il seguente diagramma mostra un deployment ibrido con un bilanciatore del carico HTTP(S) esterno.

Connettività ibrida con bilanciamento del carico HTTP(S) (fai clic per ingrandire)
Connettività ibrida con bilanciamento del carico HTTP(S) esterno (clic per ingrandire)

In questo diagramma, il traffico dai client sulla rete Internet pubblica entra nella tua rete privata on-premise o nel cloud tramite un bilanciatore del carico Google Cloud, ad esempio il bilanciatore del carico HTTP(S) esterno. Quando il traffico raggiunge il bilanciatore del carico, puoi applicare servizi di rete perimetrale come l'autenticazione utente di Google Cloud Armor DDoS o di Identity-Aware Proxy (IAP).

Il modo in cui la richiesta viene instradata (a un backend Google Cloud o a un endpoint on-premise/cloud) dipende dalla configurazione della mappa URL. A seconda della mappa dell'URL, il bilanciatore del carico seleziona un servizio di backend per la richiesta. Se il servizio di backend selezionato è stato configurato con un NEG ibrido di connettività (utilizzato solo per endpoint non Google Cloud), il bilanciatore del carico inoltra il traffico attraverso Cloud VPN o Cloud Interconnect alla destinazione 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 ha origine dalla rete VPC di Google Cloud, dalla tua rete on-premise o da un altro cloud, ed è instradato a endpoint che possono essere in Google Cloud, on-premise o in un altro cloud. Tieni presente che il bilanciamento del carico HTTP(S) interno è un bilanciatore del carico a livello di area geografica, il che significa che può indirizzare il traffico solo a endpoint all'interno della stessa zona o area geografica di GCP delle risorse del bilanciatore del carico.

Il seguente diagramma mostra un deployment ibrido con un bilanciatore del carico HTTP(S) interno.

Connettività ibrida con bilanciamento del carico HTTP(S) interno (clic per ingrandire)
Connettività ibrida con bilanciamento del carico HTTP(S) interno (clic per ingrandire)

Caso d'uso: migrazione a Cloud

La migrazione di un servizio esistente nel cloud ti consente di liberare la capacità on-prem e di ridurre i costi e il carico di lavoro per la manutenzione dell'infrastruttura on-prem. Puoi configurare temporaneamente un deployment ibrido che ti consenta di instradare il traffico sia al servizio on-premise attuale che a un endpoint di servizio Google Cloud corrispondente.

Il seguente diagramma illustra questa configurazione con il bilanciamento del carico HTTP(S) interno.

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

Se utilizzi il bilanciamento del carico HTTP(S) interno per gestire i client interni, puoi configurare il bilanciatore del carico Google Cloud in modo da utilizzare la suddivisione del traffico basata sul peso per suddividere il traffico tra i due servizi. La suddivisione del traffico consente di inviare lo 0% del traffico al servizio Google Cloud e il 100% al servizio on-premise. Potrai quindi aumentare gradualmente la proporzione di traffico inviato al servizio Google Cloud. Infine, invii il 100% del traffico al servizio Google Cloud e puoi ritirare il servizio on-premise.

Architettura ibrida

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

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

I seguenti diagrammi mostrano le risorse Google Cloud richieste per abilitare il bilanciamento del carico ibrido per bilanciamento del carico HTTP(S) e bilanciamento del carico HTTP(S) interno.

HTTP(S) esterni

Risorse del bilanciatore del carico HTTP(S) esterno per la connettività ibrida (fai clic per ingrandire)
Risorse del bilanciatore del carico HTTP(S) esterno per la connettività ibrida (fai clic per ingrandire)

HTTP(S) interni

Risorse interne del bilanciatore del carico HTTP(S) per la connettività ibrida (fai clic per ingrandire)
Risorse del bilanciatore del carico HTTP(S) interno per connettività ibrida (fai clic per ingrandire)

Globali e globali

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

Bilanciamento del carico HTTP(S) esterno. Per il traffico Internet, il bilanciatore del carico HTTP(S) esterno può essere configurato per il routing globale o a livello di area geografica, a seconda del livello di rete utilizzato. Devi creare il backend NEG ibrido del bilanciatore del carico nella stessa area geografica in cui è stata configurata la connettività ibrida. Anche gli endpoint non Google Cloud devono essere configurati in modo da sfruttare il bilanciamento del carico basato su prossimità.

Bilanciamento del carico HTTP(S) interno. Per il traffico proveniente da client interni, il bilanciatore del carico HTTP(S) interno è un bilanciatore del carico a livello di area geografica. In altre parole, può indirizzare il traffico solo a endpoint all'interno della stessa area geografica del bilanciatore del carico. I componenti del bilanciatore del carico HTTP(S) interno devono essere configurati nella stessa area geografica in cui è stata configurata la connettività ibrida. Poiché il bilanciamento del carico HTTP(S) interno non supporta l'accesso globale, anche i client che accedono al bilanciatore del carico devono trovarsi nella stessa area geografica.

Ad esempio, se il gateway Cloud VPN o il collegamento VLAN Cloud Interconnect sono stati configurati in us-central1, le risorse richieste dal bilanciatore del carico HTTP(S) interno (servizio di backend, NEG ibrido, regola di forwarding e così via) devono essere create nell'area geografica us-central1. I client che accedono al bilanciatore del carico devono trovarsi anche nell'area geografica us-central1.

Requisiti per la connettività di rete

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

  • Rete VPC di Google Cloud. Una rete VPC configurata in Google Cloud. Si tratta della rete in cui verranno create le risorse di bilanciamento del carico ibrido (regola di forwarding, proxy di destinazione, servizio di backend e così via). Gli indirizzi IP e gli intervalli di indirizzi IP delle subnet on-premise, del cloud e di Google Cloud non devono sovrapporsi. Quando gli indirizzi IP si sovrappongono, le route delle subnet hanno la priorità sulla connettività remota.
  • Connettività ibrida. Il tuo Google Cloud e i tuoi ambienti on-premise o altri cloud devono essere connessi tramite connettività ibrida, utilizzando il collegamento VLAN di Cloud Interconnect o i 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 acquisisce informazioni sull'endpoint specifico tramite BGP e lo programma nella tua rete VPC di Google Cloud. Il routing dinamico a livello di area geografica non è supportato. Inoltre, 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 di bilanciamento del carico ibrido. Il router Cloud deve inoltre pubblicizzare i 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.
    • Solo per il bilanciamento del carico HTTP(S) interno, l'intervallo della subnet solo proxy della regione.
  • Endpoint di rete (IP:Port) sul tuo on-prem o su un altro cloud. Uno o più endpoint di rete IP:Port configurati all'interno dei tuoi ambienti on-premise o in altri ambienti cloud, instradabili tramite Cloud Interconnect o Cloud VPN. Se sono presenti più percorsi all'endpoint IP, il routing seguirà il comportamento descritto nella panoramica dei percorsi VPC e nella panoramica dei router Cloud.
  • Regole firewall sul tuo on-prem o su un altro cloud. Le seguenti regole firewall devono essere create nell'ambiente on-prem o in un altro ambiente cloud:
    • Le regole firewall allow consentono al traffico dai probe di controllo di integrità di Google verso i tuoi endpoint. Per il bilanciatore del carico HTTP(S) esterno, il bilanciatore del carico HTTP(S) interno, il bilanciatore del carico del proxy TCP e il proxy SSL, gli intervalli da consentire sono: 35.191.0.0/16 e 130.211.0.0/22. Tieni presente che questi intervalli devono essere pubblicizzati anche da Cloud Router nella tua rete on-premise. Per maggiori dettagli, vedi Intervalli di indirizzi IP e regole firewall.
    • Le regole firewall allow consentono al traffico in fase di bilanciamento del carico di raggiungere gli endpoint.
    • Per il bilanciamento del carico HTTP(S) interno, devi anche creare una regola firewall per consentire al traffico dalla subnet solo proxy dell'area geografica di raggiungere gli endpoint.

Componenti del bilanciatore del carico

A seconda del tipo di bilanciatore del carico, puoi configurare un deployment di bilanciamento del carico ibrido utilizzando i livelli Standard o Premium Service Service.

Un bilanciatore del carico ibrido richiede una configurazione speciale solo per il servizio di backend. La configurazione frontend è la stessa di qualsiasi altro bilanciatore del carico. Inoltre, i bilanciatori del carico HTTP(S) interni richiedono una subnet solo proxy per eseguire i proxy proxy per tuo conto.

Configurazione frontend

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

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

Per ulteriori 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 configurare un deployment di bilanciamento del carico ibrido, devi configurare il bilanciatore del carico con backend sia all'interno di Google Cloud che all'esterno di Google Cloud.

  • Backend non Google Cloud (on-prem o altro cloud)

    Qualsiasi destinazione che puoi raggiungere utilizzando i prodotti di connessione ibrida di Google (Cloud VPN o Cloud Interconnect) e che può essere raggiunta con una combinazione di IP:Port valida, può essere configurata come endpoint per il bilanciatore del carico.

    Configura i tuoi backend non Google Cloud come segue:

    1. Aggiungi ogni combinazione di endpoint di rete non Google Cloud IP:Porta un gruppo di endpoint di rete ibrido (NEG). Assicurati che l'indirizzo IP e la porta siano raggiungibili da Google Cloud utilizzando la connettività ibrida (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 riduca al minimo la distanza geografica tra Google Cloud e il tuo ambiente on-premise o in 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 al momento della creazione del NEG.
    3. Aggiungi questo NEG di connettività ibrida come backend per il servizio di backend.

      Un NEG di connettività ibrido deve includere solo endpoint non Google Cloud. Il traffico potrebbe andare perso se un NEG ibrido include endpoint per le risorse all'interno di una rete VPC di Google Cloud, ad esempio gli indirizzi IP delle regole di forwarding per i bilanciatori del carico TCP/UDP interni. Configura gli endpoint Google Cloud come indicato nella sezione successiva.

  • Backend di Google Cloud

    Configura i tuoi endpoint Google Cloud come segue:

    1. Crea un servizio di backend separato per i backend di Google Cloud.
    2. Configura più backend (o GCE_VM_IP_PORT NEG di zona o gruppi di istanze) nella stessa area geografica in cui hai configurato la connettività ibrida.

Ulteriori aspetti da considerare:

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

  • Combinazioni di backend supportate:

    • Per i bilanciatori del carico HTTP(S) esterni globali, puoi utilizzare un singolo servizio di backend per fare riferimento sia ai backend basati su Google Cloud (tramite NEG di zona con endpoint GCE_VM_IP_PORT) sia a quelli on-premise o ad altri backend cloud (tramite NEG di connettività ibrida con NON_GCP_PRIVATE_IP_PORT endpoint). Non è consentita nessun'altra combinazione di tipi di backend misti.
    • Per i bilanciatori del carico HTTP(S) interni, tutti i NEG associati a un servizio di backend devono essere dello stesso tipo. Se hai backend su Google Cloud, devi creare un servizio di backend separato. Questo perché i backend basati su Google Cloud utilizzeranno un tipo di backend diverso (ad esempio, gruppo di istanze o NEG di zona).
  • Lo schema di bilanciamento del carico del servizio di backend deve essere EXTERNAL_MANAGED per il bilanciatore del carico HTTP(S) esterno globale, EXTERNAL per il bilanciatore del carico HTTP(S) esterno globale (classico), il bilanciatore del carico del proxy TCP e il bilanciatore del carico proxy SSL o INTERNAL_MANAGED per i bilanciatori del carico HTTP(S) interni. Sono supportati INTERNAL_SELF_MANAGED per i deployment multi-environment di Traffic Director con NEG di connettività ibrida.

  • Il protocollo del servizio di backend deve essere uno dei seguenti: HTTP, HTTPS o HTTP2 per i bilanciatori del carico HTTP(S) e TCP o SSL per il bilanciatore del carico del proxy TCP e il bilanciatore del carico del proxy SSL. Per l'elenco dei protocolli di servizio di backend supportati da ciascun bilanciatore del carico, consulta la sezione Protocolli dal bilanciatore del carico al backend.

  • La modalità di bilanciamento per il backend deve essere RATE per il bilanciamento del carico HTTP(S) esterno e interno e CONNECTION per il bilanciamento del carico del proxy TCP/SSL. 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.

Controlli di integrità

Ogni servizio di backend deve essere associato a un controllo di integrità che verifica l'integrità dei backend. Affinché i probe del controllo di integrità funzionino correttamente, devi creare regole firewall che consentano al traffico proveniente dagli intervalli IP dei probe di Google (130.211.0.0/22 e 35.191.0.0/16) di raggiungere i tuoi endpoint.

Per i backend esterni a Google Cloud, crea regole firewall sulle tue reti on-premise e su altre reti cloud. Contatta l'amministratore di rete per richiedere informazioni a riguardo. Il router Cloud utilizzato per la connettività ibrida deve inoltre pubblicizzare gli intervalli utilizzati dai probe del controllo di integrità di Google. Gli intervalli da pubblicizzare sono: 35.191.0.0/16 e 130.211.0.0/22.

Per i backend all'interno di Google Cloud, crea regole firewall su Google Cloud come dimostrato in questo esempio.

Limitazioni

  • I NEG di connettività ibrida non sono supportati in Google Cloud Console. Per creare, eliminare o gestire i NEG di connettività ibrida, devi utilizzare l'interfaccia a riga di comando di Google Cloud o l'API REST.
  • Il router Cloud utilizzato per la connettività ibrida deve essere abilitato con il routing dinamico globale. Il routing dinamico a livello di area geografica e le route statiche non sono supportati.
  • Il bilanciamento del carico HTTP(S) interno e la connettività ibrida devono essere configurati nella stessa area geografica. Se sono configurati in diverse aree geografiche, potresti visualizzare i backend in stato integro, ma le richieste dei client non verranno inoltrate al backend.
  • Le considerazioni per le connessioni criptate dal bilanciatore del carico ai backend documentati qui si applicano anche agli endpoint di backend non Google Cloud configurati nel NEG di connettività ibrida.

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

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 gli altri backend di bilanciamento del carico HTTP(S). Per ulteriori informazioni, consulta la sezione Logging e monitoraggio del bilanciamento del carico HTTP(S).

Se abiliti Cloud CDN per il tuo bilanciatore del carico, vengono registrati anche gli hit della cache.

Quota

Puoi configurare tutti i NEG ibridi con endpoint di rete consentiti dalla quota del tuo gruppo di endpoint di rete esistente. Per ulteriori informazioni, consulta i backend NEG e gli endpoint per NEG.

Passaggi successivi