Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Trusted Cloud di S3NS.

Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica dei gruppi di endpoint di rete con connettività ibrida

Cloud Load Balancing supporta il bilanciamento del carico del traffico verso endpoint che si estendono oltre Trusted Cloud by S3NS, ad esempio data center on-premise e altri cloud pubblici che puoi utilizzare la connettività ibrida per raggiungere.

Una strategia ibrida è una soluzione pragmatica per adattarsi alle mutevoli richieste del mercato e modernizzare gradualmente le applicazioni. Potrebbe trattarsi di un deployment ibrido temporaneo per consentire la migrazione a una soluzione moderna basata sul cloud o di una funzionalità permanente dell'infrastruttura IT della tua organizzazione.

La configurazione del bilanciamento del carico ibrido ti consente anche di sfruttare i vantaggi delle funzionalità di networking di Cloud Load Balancing per i servizi in esecuzione sulla tua infrastruttura esistente al di fuori di Trusted Cloud.

Il bilanciamento del carico ibrido è supportato sui seguenti Trusted Cloud by S3NS bilanciatori del carico:

I servizi on-premise e altri servizi cloud vengono trattati come qualsiasi altro backend diCloud Load Balancingo. 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, Cloud Interconnect o VM appliance router.

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

Il caso d'uso più semplice per l'utilizzo dei NEG ibridi è il routing del traffico da un bilanciatore del caricoTrusted Cloud a una posizione on-premise o a un altro ambiente cloud. I client possono generare traffico da internet pubblico, dall'interno di Trusted Cloudo 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 dai client esterni a un backend on-premise o in un'altra rete cloud. Puoi anche attivare le seguenti funzionalità di rete a valore aggiunto per i tuoi servizi on-premise o in altre reti cloud:

Con il bilanciatore del carico delle applicazioni esterno regionale, puoi instradare il traffico esterno a endpoint che si trovano nella stessa regione Trusted 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 vuoi utilizzare il livello di servizio di rete Standard.

Il modo in cui la richiesta viene instradata (a un backend o a un endpoint on-premise/cloud) dipende dalla configurazione della mappa URL. Trusted Cloud 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 nonTrusted Cloud ), il bilanciatore del carico inoltra il traffico tramite Cloud VPN, Cloud Interconnect o VM appliance router alla destinazione esterna prevista.

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

Puoi anche configurare un deployment ibrido per i client interni a Trusted Cloud. In questo caso, il traffico client ha origine dalla rete VPCTrusted Cloud , dalla rete on-premise o da un altro cloud e viene indirizzato agli endpoint on-premise o in altre reti cloud.

Il bilanciatore del carico delle applicazioni interno regionale è un bilanciatore del carico regionale, il che significa che può instradare il traffico solo agli endpoint all'interno della stessa regione Trusted Cloud delle risorse del bilanciatore del carico.

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

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

Caso d'uso: esegui la migrazione al cloud

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

Se utilizzi un bilanciatore del carico delle applicazioni interno per gestire i client interni, puoi configurare il bilanciatore del carico Trusted Cloud per utilizzare la suddivisione del traffico basata sul peso per suddividere il traffico tra i due servizi. La suddivisione del traffico ti consente di iniziare inviando lo 0% del traffico al servizio Trusted Cloud e il 100% al servizio on-premise. Puoi quindi aumentare gradualmente la percentuale di traffico inviato al servizio Trusted Cloud . Alla fine, invii il 100% del traffico al servizio Trusted Cloud e puoi 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 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 tuoi client possono raggiungere tramite connettività ibrida, ad esempio Cloud VPN, Cloud Interconnect o una VM appliance router.

I seguenti diagrammi mostrano le risorse Trusted Cloud necessarie per attivare il bilanciamento del carico ibrido.

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 regionale

Routing di Cloud Load Balancing

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

Bilanciatore del carico delle applicazioni interno regionale e bilanciatore del carico di rete proxy interno regionale. Si tratta di bilanciatori del carico regionali. ovvero 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.

Ad esempio, se il gateway Cloud VPN o il collegamento VLAN Cloud Interconnect è configurato in REGION_A, le risorse richieste dal bilanciatore del carico (ad esempio un servizio di backend, un NEG ibrido o una regola di forwarding) devono essere create nella regione REGION_A. Per impostazione predefinita, i client che accedono al bilanciatore del carico devono trovarsi anche nella regione REGION_A.

Requisiti per la connettività di rete

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

Trusted Cloud Rete VPC. Una rete VPC configurata all'interno di Trusted Cloud. Questa è la rete VPC utilizzata per configurare Cloud Interconnect/Cloud VPN e router Cloud. Si tratta anche della 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 on-premise, di altri cloud e di subnet non devono sovrapporsi. Trusted Cloud Quando gli indirizzi IP si sovrappongono, le route di subnet hanno la priorità sulla connettività remota.
Connettività ibrida. Il tuo Trusted Cloud e gli ambienti on-premise o altri cloud devono essere connessi tramite connettività ibrida, utilizzando i collegamenti VLAN di Cloud Interconnect, i tunnel Cloud VPN con router Cloud o le VM appliance router. Ti consigliamo di utilizzare una connessione ad alta disponibilità. Un router Cloud abilitato con il routing dinamico globale apprende l'endpoint specifico utilizzando BGP e lo programma nella tua rete VPCTrusted Cloud . Il routing dinamico regionale non è supportato. Anche le route statiche non sono supportate.

Cloud Interconnect/Cloud VPN/Router appliance deve essere configurato nella stessa rete VPC che intendi utilizzare per il deployment del bilanciamento del carico ibrido. Il router Cloud deve anche annunciare le seguenti route al tuo ambiente on-premise:
- Intervalli utilizzati dalle sonde di controllo di integrità di Google: 35.191.0.0/16 e 130.211.0.0/22.
- L'intervallo della subnet solo proxy della regione: per i bilanciatori del carico basati su Envoy: bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico delle applicazioni interni regionali, bilanciatori del carico di rete proxy esterni regionali, e bilanciatori del carico di rete proxy interni regionali.
  
  La subnet solo proxy della regione pubblicitaria è necessaria anche per il funzionamento dei controlli di integrità di Envoy distribuiti. Il controllo di integrità distribuito di Envoy è il meccanismo di controllo di integrità predefinito per i NEG di connettività ibrida a livello di zona (ovvero gli endpoint NON_GCP_PRIVATE_IP_PORT) dietro i bilanciatori del carico basati su Envoy.
Puoi utilizzare la stessa rete o una rete VPC diversa all'interno dello stesso progetto per configurare sia il networking ibrido (Cloud Interconnect o Cloud VPN) sia il bilanciatore del carico. Tieni presente quanto segue:
- Se utilizzi reti VPC diverse, le due reti devono essere connesse tramite il peering di rete VPC oppure devono essere spoke VPC nello stesso hub Network Connectivity Center.
- Se utilizzi la stessa rete VPC, assicurati che gli intervalli CIDR delle subnet della rete VPC non siano in conflitto con gli intervalli CIDR remoti. Quando gli indirizzi IP si sovrappongono, le route di subnet hanno la priorità sulla connettività remota.
Endpoint di rete (IP:Port) on-premise o in altri cloud. Uno o più endpoint di rete IP:Port configurati all'interno dei tuoi ambienti on-premise o di altri cloud, instradabili utilizzando Cloud Interconnect, Cloud VPN o una VM appliance router. Se esistono più percorsi per l'endpoint IP, il routing seguirà il comportamento descritto nella panoramica delle route VPC e nella panoramica di Cloud Router.
Regole firewall nel tuo cloud on-premise o in un altro cloud. Nel tuo ambiente on-premise o in un altro ambiente cloud devono essere create le seguenti regole firewall:
- Regole firewall di autorizzazione in entrata per consentire il traffico dai probe di controllo di integrità di Google ai tuoi endpoint. 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 router Cloudr alla tua rete on-premise. Per maggiori dettagli, vedi Intervalli IP probe e regole firewall.
- Regole firewall di autorizzazione in entrata per consentire al traffico bilanciato di raggiungere gli endpoint.
- Per i bilanciatori del carico basati su Envoy: bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico delle applicazioni interni regionali, bilanciatori del carico di rete proxy esterni regionali, e bilanciatori del carico di rete proxy interni regionali, devi anche creare una regola firewall per consentire al traffico dellasubnet solo proxy della regione di raggiungere gli endpoint on-premise o in altri ambienti cloud.

Componenti del bilanciatore del carico

Un bilanciatore del carico ibrido richiede una configurazione speciale solo per il servizio di backend. La configurazione del frontend è la stessa di qualsiasi altro bilanciatore del carico. I bilanciatori del carico basati su Envoy, ovvero i bilanciatori del carico delle applicazioni esterni regionali, i bilanciatori del carico delle applicazioni interni regionali, i bilanciatori del carico di rete proxy esterni regionali, e i bilanciatori del carico di rete proxy interni regionali, richiedono una subnet solo proxy aggiuntiva per eseguire i proxy Envoy per tuo conto.

Configurazione frontend

Per il bilanciamento del carico ibrido non è necessaria alcuna configurazione speciale del frontend. Le regole di forwarding vengono utilizzate per instradare il traffico verso 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 ulteriori dettagli su ciascuno di questi componenti, consulta le sezioni sull'architettura delle panoramiche dei bilanciatori del carico specifici:

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, configura il bilanciatore del carico con backend sia all'interno di Trusted Cloudsia all'esterno di Trusted Cloud.

Backend non-Trusted Cloud (on-premise o altro cloud)

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

Configura i backend nonTrusted Cloud nel seguente modo:
1. Aggiungi ogni combinazione di IP:Port dell'endpoint di rete nonTrusted Cloud a un gruppo di endpoint di rete (NEG) con connettività ibrida. Assicurati che questo indirizzo IP e questa porta siano raggiungibili da Trusted Cloud utilizzando la connettività ibrida (tramite Cloud VPN, Cloud Interconnect o VM appliance router). 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 Trusted Cloud zona che riduca al minimo la distanza geografica tra Trusted 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 europe-west3-a Trusted Cloud quando crei il gruppo di elenchi di esclusione.
3. Aggiungi questo NEG di connettività ibrida come backend per il servizio di backend.
  
  Un NEG di connettività ibrida deve includere solo endpoint nonTrusted Cloud. Il traffico potrebbe essere eliminato se un NEG ibrido include endpoint per risorse all'interno di una rete VPC, ad esempio indirizzi IP di regola di forwarding per bilanciatori del carico di rete passthrough interni. Trusted Cloud Configura gli endpoint Trusted Cloud come indicato nella sezione successiva.
Trusted Cloud backend

Configura i tuoi Trusted Cloud endpoint nel seguente modo:
1. Crea un servizio di backend separato per i backend Trusted Cloud .
2. Configura più backend (NEG zonali GCE_VM_IP_PORT o gruppi di istanze) all'interno della stessa regione in cui hai configurato la connettività ibrida.

Altri punti 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 suTrusted Cloud(utilizzando i NEG zonali con endpoint GCE_VM_IP_PORT) sia ai backend on-premise o di altri cloud (utilizzando i NEG di connettività ibrida con endpoint NON_GCP_PRIVATE_IP_PORT). Non è consentita nessun'altra combinazione di tipi di backend misti.

Nota: per i deployment GKE, i backend NEG misti sono supportati solo con i NEG autonomi.

Lo schema di bilanciamento del carico del servizio di backend è INTERNAL_MANAGED per i bilanciatori del carico delle applicazioni interni a livello di regione e i bilanciatori del carico di rete proxy interni a livello di regione.

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. Per l'elenco dei protocolli del 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 i bilanciatori del carico delle applicazioni e CONNECTION per i bilanciatori del carico di rete proxy. Per informazioni dettagliate sulle modalità di bilanciamento, vedi Panoramica dei servizi di backend.
Per aggiungere altri endpoint di rete, aggiorna i backend collegati al servizio di backend.
Se utilizzi i controlli di integrità Envoy distribuiti con i backend NEG di connettività ibrida (supportati solo per i bilanciatori del carico basati su Envoy), assicurati di configurare endpoint di rete unici per tutti i NEG collegati allo stesso servizio di backend. L'aggiunta dello stesso endpoint di rete a più NEG comporta un comportamento indefinito.

Controlli di integrità di Envoy distribuiti

La configurazione del controllo di integrità varia a seconda del tipo di bilanciatore del carico:

Bilanciatore del carico delle applicazioni esterno regionale, bilanciatore del carico delle applicazioni interno regionale, bilanciatore del carico di rete proxy esterno regionale, bilanciatore del carico di rete proxy interno regionale . Questi bilanciatori del carico utilizzano controlli di integrità Envoy distribuiti per verificare l'integrità dei NEG ibridi. I probe del controllo di integrità provengono dal software proxy Envoy stesso. Ogni servizio di backend deve essere associato a un controllo di integrità che verifichi l'integrità dei backend. I probe del controllo di integrità hanno origine dai proxy Envoy nella subnet solo proxy nella regione. Affinché i probe di 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 Trusted Cloud, devi creare queste regole firewall nelle tue reti on-premise e in altri cloud. Contatta l'amministratore di rete per questa operazione. Il router Cloud che utilizzi per la connettività ibrida deve anche annunciare l'intervallo di subnet solo proxy della regione.

I controlli di integrità Envoy distribuiti vengono creati utilizzando gli stessi processi di consoleTrusted Cloud , gcloud CLI e API dei controlli di integrità centralizzati. Non è necessaria alcuna altra configurazione.

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 in cui un singolo servizio di backend ha una combinazione di NEG di zona (endpoint GCE_VM_IP_PORT all'interno diTrusted Cloud) e NEG ibridi (endpoint NON_GCP_PRIVATE_IP_PORT all'esterno di Trusted Cloud), devi configurare regole firewall per consentire il traffico dagli intervalli IP di probe di controllo di integrità dell'integrità di Google (130.211.0.0/22 e 35.191.0.0/16) agli endpoint NEG di zona suTrusted 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 consoleTrusted 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 Trusted Cloud mostra lo stato del controllo di integrità comeN/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 tua rete VPC in una regione, dalla quantità di traffico ricevuto da questi proxy e dal numero di endpoint che ogni proxy Envoy deve controllare. Nel peggiore dei casi, il traffico di rete dovuto ai controlli di integrità aumenta a una velocità quadratica (O(n^2)).
I log dei controlli di integrità per i controlli di integrità Envoy distribuiti non includono stati di integrità dettagliati. Per informazioni dettagliate su cosa viene registrato, vedi Registrazione dei controlli di integrità. Per risolvere ulteriormente i problemi di connettività dai proxy Envoy agli endpoint NEG, devi controllare anche i log del bilanciatore del carico corrispondente.

Documentazione correlata:

Limitazioni

Il router Cloud utilizzato per la connettività ibrida deve essere abilitato con il routing dinamico globale. Il routing dinamico regionale e le route statiche non sono supportati.
Per i bilanciatori del carico regionali basati 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 regionali), la connettività ibrida deve essere configurata nella stessa regione del bilanciatore del carico. Se sono configurati in regioni diverse, potresti vedere i backend come integri, ma le richieste client non verranno inoltrate ai backend.
Le considerazioni per le connessioni criptate dal bilanciatore del carico ai backend documentate qui si applicano anche agli endpoint di backend nonTrusted Cloud configurati nel NEG di connettività ibrida.

Assicurati di controllare anche le impostazioni di sicurezza nella configurazione della connettività ibrida. 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 in transito.

Logging

Le richieste sottoposte a 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.

Per ulteriori informazioni, vedi:

Quota

Puoi configurare tutti i NEG ibridi con endpoint di rete consentiti dalla quota esistente del gruppo di endpoint di rete. Per saperne di più, consulta le sezioni Backend NEG ed Endpoint per NEG.