NCC Cross-Cloud Network con NVA e failover regionale

Last reviewed 2026-08-24 UTC

Questo documento fornisce un'architettura di riferimento che puoi utilizzare per fare il deployment di una topologia di rete hub-and-spoke ibrida o Cross-Cloud Network che utilizza appliance virtuali di rete (NVA) per instradare il traffico all'interno di Google Cloud o con reti esterne aGoogle Cloud.

Il pubblico di destinazione di questo documento è costituito da amministratori di rete che creano la connettività di rete e da architetti cloud che pianificano la modalità di deployment dei workload. Il documento presuppone una conoscenza di base del routing, del protocollo BGP, della connettività a internet e del software NVA che vuoi implementare.

La progettazione supporta più connessioni remote a posizioni on-premise o del provider di servizi cloud (CSP) e più reti Virtual Private Cloud (VPC) del workload. Si concentra sulla creazione di un deployment multiregionale resiliente e ad alte prestazioni che fornisca affinità regionale e failover tra regioni tramite l'utilizzo del routing dinamico. Il routing dinamico è basato su BGP per il rilevamento e il ripristino completamente automatizzati delle interruzioni delle NVA. La progettazione inserisce le NVA in tutti i flussi da Google Cloud a on-premise o ad altri CSP e le posiziona tra le reti VPC del carico di lavoro.

Se includi NVA nella tua rete, questa architettura è adatta ai seguenti requisiti di progettazione:

1. Supporta il failover NVA tra regioni: fornisce il rilevamento automatico degli errori di routing NVA in una regione e reindirizza il traffico alle NVA in una regioneGoogle Cloud vicina, se necessario.
2. Mantieni l'affinità regionale: mantieni il routing all'interno delle regioni Google Cloud per ridurre la latenza e i costi di trasferimento dei dati, a meno che non si verifichi un errore. Il traffico viene instradato a regioni remote o connessioni ibride solo in caso di errore.

Questo progetto non prevede il routing simmetrico tra le NVA, a meno che tu non lo configuri utilizzando le opzioni descritte più avanti nella sezione Scalabilità. Se il routing simmetrico è più importante per la tua progettazione rispetto al failover regionale e all'affinità del traffico locale, consulta Peering di rete VPC Cross-Cloud Network con NVA e affinità regionale.

Architettura

Il seguente diagramma mostra i componenti utilizzati in questa architettura. Il diagramma mostra solo due regioni, ma la progettazione può essere estesa ad altre regioni.

Componenti dell'architettura

L'architettura di esempio precedente contiene i seguenti componenti:

Rete esterna (on-premise o altra rete CSP)

La rete esterna può essere on-premise o in un altro CSP. Ospita i client delle applicazioni eseguite nelle reti VPC del workload. La rete esterna può anche ospitare applicazioni, ma le NVA elaborano solo il traffico che va a o proviene da una rete VPC del carico di lavoro.

Nel diagramma, Cloud Interconnect connette la rete esterna alla rete VPC di routing. Questa architettura supporta anche l'utilizzo di Cloud VPN anziché Cloud Interconnect. La rete esterna utilizza i collegamenti VLAN di Cloud Interconnect o i tunnel Cloud VPN per connettersi all'hub 1 di Network Connectivity Center (NCC) come spoke ibridi.

Rete VPC di routing

La rete VPC di routing si connette a reti esterne utilizzando Cloud Interconnect o Cloud VPN. Si connette alla rete VPC di transito tramite NVA multi-NIC.

Il traffico che passa tra la rete VPC di routing e la rete VPC di transito deve passare attraverso le NVA. I router Cloud nella rete VPC di routing scambiano le route con i router di rete esterni e con le NIC NVA connesse alla rete VPC di routing.

Rete VPC di transito

La rete VPC di transito si connette alla rete VPC di routing tramite NVA multi-NIC. Questa rete trasmette il traffico tra la rete VPC di routing e le reti VPC del workload.

La rete VPC di transito trasmette anche il traffico dalle reti VPC del workload alle NVA e poi di nuovo alle reti VPC del workload per il traffico da workload a workload.

I router Cloud nella rete scambiano le route con le NIC NVA connesse alla rete di transito.

NVA

Le NVA multi-NIC vengono implementate in coppie in più Google Cloud regioni. Ogni NVA ha una NIC connessa alla rete VPC di routing e un'altra NIC connessa alla rete VPC di transito. Le NVA trasferiscono il traffico tra le due reti e possono fornire altre funzioni, come l'ispezione del traffico.

Nell'architettura, il traffico tra le reti VPC del carico di lavoro deve passare attraverso le NVA. In questa architettura, le NVA hanno almeno due NIC: una NIC è collegata alla rete VPC di routing e l'altra alla rete VPC di transito. L'architettura può supportare facoltativamente NIC aggiuntive per la gestione o per la connessione a reti aggiuntive.

Hub NCC 1

Questo hub NCC fornisce connettività tra le connessioni ibride di rete esterna e le NIC NVA connesse alla rete VPC di routing.

L'hub è configurato nella topologia mesh che include i seguenti tipi di spoke ibridi: spoke appliance router, spoke Cloud VPN e spoke di collegamento VLAN Cloud Interconnect.

Le NIC NVA collegate alla rete VPC di routing vengono aggiunte all'hub come spoke dell'appliance router. È possibile aggiungere fino a otto NVA come singolo raggio.

Reti VPC del workload

Le reti VPC dei workload ospitano applicazioni a cui è possibile accedere da client nella rete esterna o da client in altre reti VPC dei workload. Le reti VPC del workload possono anche ospitare endpoint Private Service Connect a cui è possibile accedere da altre reti.

Le reti VPC del workload sono configurate come spoke VPC nell'hub NCC 2. Le reti VPC del carico di lavoro sono connesse alle NIC NVA nella rete VPC di transito tramite l'hub NCC 2. Il traffico che esce da una rete VPC del carico di lavoro viene instradato alle NVA indipendentemente dalla destinazione finale del traffico.

Hub NCC 2

Questo hub NCC fornisce connettività tra le reti VPC del workload e le interfacce NVA dell'appliance router nella rete VPC di transito.

L'hub è configurato con topologia a stella e gli spoke collegati nel seguente modo:

• Le interfacce NVA nella rete VPC di transito sono configurate come spoke dell'appliance router in un gruppo spoke hub.
• Le reti VPC del workload sono configurate come spoke VPC in un gruppo di spoke edge.

Il traffico verso e da reti VPC del workload deve passare attraverso le NVA.

Flussi di traffico

Le sezioni seguenti mostrano i flussi di traffico normali quando tutte le NVA e le connessioni alle reti esterne sono funzionanti e i flussi di traffico di failover quando le connessioni o le NVA in una regione hanno avuto esito negativo.

Flussi di traffico normali

Il seguente diagramma mostra i flussi di traffico quando le NVA e le connessioni alle reti esterne sono attive e funzionanti:

Quando tutto funziona correttamente, il traffico regionale rimane nella sua regione:

1. Le metriche BGP mantengono il traffico locale (dalla regione A alla regione A o alla località A) all'interno della regione, eliminando la necessità di taggare risorse o route.
2. Questa architettura posiziona le NVA per elaborare il traffico tra le reti VPC del workload e tra le reti VPC del workload e la rete esterna.

Il seguente elenco descrive i flussi di traffico mostrati nel diagramma:

Dalla rete esterna alla rete VPC del workload

Il traffico segue le route attraverso le connessioni Cloud Interconnect alla rete VPC di routing. Le route vengono annunciate dal router Cloud alla NVA tramite l'hub Network Connectivity Center.

Nella rete VPC di routing, il traffico viene instradato alla NIC della NVA attiva utilizzando le route dinamiche apprese dalla NVA. Il traffico segue le route attraverso la NVA fino all'altra NIC, che lo trasmette alla rete VPC di transito. Il traffico segue le route tramite i peering NCC alla rete VPC del workload di destinazione.

Dalla rete VPC del workload alla rete esterna

Il traffico segue le route apprese dall'hub NCC 2 tramite il peering NCC alla NVA. Entra nell'NVA attivo tramite la NIC.

Il traffico segue le route attraverso la NVA fino all'altra NIC, che lo trasmette alla rete VPC di routing. Il traffico segue le route programmate nella rete VPC di routing ai collegamenti VLAN e alla rete remota.

Dalla rete VPC del workload alla rete VPC del workload

Il traffico segue le route apprese dall'hub NCC 2 tramite il peering NCC alla NVA. Entra nella NVA tramite la NIC nel VPC di transito.

Se è presente più di un NVA attivo, le metriche BGP controllano quale NVA è l'hop successivo. Il traffico segue le route apprese dall'hub NCC 2 di nuovo attraverso la stessa NIC e il peering NCC all'altra rete VPC del carico di lavoro.

Flussi di traffico di failover

Il seguente diagramma mostra i flussi di traffico quando tutte le NVA in una regione hanno avuto esito negativo:

In caso di errore totale di tutte le NVA in una regione, il sistema reindirizza automaticamente il traffico tramite le NVA integre nella regione remota più vicina. Questa architettura è anche resiliente agli errori di connessioni ibride in una regione.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti Google Cloud :

• Virtual Private Cloud (VPC): un sistema virtuale che fornisce funzionalità di rete globali e scalabili per i tuoi Google Cloud carichi di lavoro. VPC include il peering di rete VPC, Private Service Connect, l'accesso privato ai servizi e VPC condiviso.
• Network Connectivity Center: un framework di orchestrazione che semplifica la connettività di rete tra le risorse spoke connesse a una risorsa di gestione centrale chiamata hub.
• Cloud Interconnect: un servizio che estende la tua rete esterna alla rete Google tramite una connessione a disponibilità elevata e a bassa latenza.
• Cloud VPN: un servizio che estende in modo sicuro la tua rete peer alla rete di Google tramite un tunnel VPN IPsec.
• Cloud Router: un'offerta distribuita e completamente gestita che fornisce funzionalità di speaker e responder Border Gateway Protocol (BGP). Router Cloud funziona con Cloud Interconnect, Cloud VPN e appliance router per creare route dinamiche nelle reti VPC in base alle route ricevute da BGP e apprese personalizzate.
• Compute Engine: un servizio di calcolo sicuro e personalizzabile che ti consente di creare ed eseguire VM sull'infrastruttura di Google.

Alternative di progettazione

A seconda dei tuoi requisiti, puoi scegliere tra le seguenti alternative di design:

• Questa architettura non fornisce un accesso centralizzato per applicazioni specifiche. Se vuoi aggiungere l'accesso centralizzato, puoi configurare una rete VPC di accesso ai servizi come descritto in Cross-Cloud Network per applicazioni distribuite.
• Questo design presuppone che le reti VPC siano distribuite tra più di un Google Cloud progetto. Tuttavia, a seconda della strategia di allocazione dei progetti, puoi eseguire il provisioning delle reti VPC in un unico progetto.

Considerazioni sulla progettazione

Questa sezione descrive i fattori di progettazione, le best practice e i consigli di progettazione da prendere in considerazione quando utilizzi questa architettura di riferimento per sviluppare una topologia che soddisfi i tuoi requisiti specifici di sicurezza, affidabilità, scalabilità e prestazioni.

Sicurezza e conformità

Di seguito sono riportate considerazioni e consigli di progettazione per progettare una topologia in Google Cloud che soddisfi i requisiti di sicurezza e conformità del tuo workload:

• Il software NVA potrebbe offrire funzionalità di ispezione del traffico. Tuttavia, per garantire una base di qualità coerente in tutto il deployment, ti consigliamo di utilizzare Cloud NGFW:
  • Google Threat Intelligence per le regole delle policy firewall per consentire o bloccare le connessioni in base ai dati di Google Threat Intelligence.
  • Oggetti di geolocalizzazione per le policy del firewall per consentire il traffico solo dai paesi consentiti e bloccare i paesi soggetti a embargo.
  • Il filtro dei nomi di dominio completi (FQDN) utilizza gli oggetti FQDN come origini per le regole in entrata o come destinazioni per le regole in uscita nelle policy firewall.
  • Il sistema di rilevamento e prevenzione delle intrusioni (IPS) monitora le attività dannose e adotta misure preventive per evitarle.
  • Intercettazione TLS per ispezionare il traffico criptato e non criptato alla ricerca di attacchi e interruzioni di rete.
• Per ottenere informazioni sui pattern di traffico, puoi utilizzare i log di flusso VPC.
• Per monitorare la conformità della rete, utilizza Cloud Logging e Cloud Monitoring.

Affidabilità

Di seguito sono riportate considerazioni e consigli di progettazione per progettare una topologia in Google Cloud che soddisfi i requisiti di affidabilità del tuo workload:

• Aumenta l'affidabilità distribuendo le NVA in una regione inGoogle Cloud zone. In questo modo, viene eliminata la dipendenza dalle singole zone, il che aumenta la resilienza contro le interruzioni delle zone.
• Per ottenere una disponibilità del 99,99% per Cloud Interconnect, in genere devi connetterti a due regioni Google Cloud diverse anche se hai VM in una sola regione. Se utilizzi Dedicated Interconnect, alcune regioni supportano una disponibilità del 99,99% in una singola regione.

Scalabilità

Questa sezione descrive le considerazioni e i consigli di progettazione per progettare una topologia in Google Cloud che soddisfi i requisiti di scalabilità del tuo workload.

Se la tua progettazione non dipende dal routing simmetrico, puoi scalare aggiungendo altri nodi NVA.

Se la tua progettazione richiede un routing simmetrico, puoi prendere in considerazione le seguenti opzioni a seconda delle funzionalità offerte dal software NVA:

• Utilizza gli attributi BGP per mantenere un singolo nodo NVA attivo per regione, ma dimensiona la VM in modo che gestisca il traffico.
• Utilizza le funzionalità del fornitore per configurare NAT di origine sulle NVA.
• Se il tuo fornitore lo supporta, puoi configurare la sincronizzazione delle sessioni tra i nodi.
• Sfrutta le opzioni di ingegneria del traffico BGP (come le policy di routing BGP) per configurare la configurazione attiva/standby per flusso. Ad esempio, puoi configurare determinate reti in modo che preferiscano NVA-A a NVA-B e invertire le preferenze per altre reti.

Ottimizzazione delle prestazioni

Di seguito sono riportate considerazioni e consigli di progettazione per progettare una topologia in Google Cloud che soddisfi i requisiti di rendimento del tuo workload:

• Potresti migliorare le prestazioni della rete aumentando l'unità massima di trasmissione (MTU) delle reti e delle connessioni. Per saperne di più, consulta Unità massima di trasmissione.
• Per migliorare il tempo di convergenza, valuta la possibilità di utilizzare BGP BFD, se applicabile, per accelerare il rilevamento e la mitigazione delle interruzioni degli eventi BGP. BFD non è supportato nelle sessioni BGP configurate per i tunnel Cloud VPN o per le NVA configurate come spoke di appliance router.

Deployment

Per eseguire il deployment di questa architettura di riferimento, completa i seguenti passaggi:

1. Identifica Google Cloud le regioni.
2. Progettare e creare la struttura del progetto.
3. Pianifica l'allocazione degli indirizzi IP.
4. Crea la rete VPC di routing.
5. Crea connessioni alla rete esterna.
6. Crea le reti VPC di transito e del workload.
7. Crea gli NVA.
8. Crea l'hub NCC 1.
9. Crea l'hub NCC 2.
10. Aggiungi l'accesso privato alle API di Google.
11. Configura l'ingresso e l'uscita centralizzati da internet.
12. Verifica la connettività ai carichi di lavoro.

Identificare Google Cloud regioni

In generale, posiziona la connettività, le subnet VPC e i carichi di lavoroGoogle Cloud nelle vicinanze delle reti on-premise o di altri client cloud. Per saperne di più sul posizionamento dei carichi di lavoro, consulta Google Cloud Selettore di regioni e Best practice per la scelta delle regioni di Compute Engine.

Ti consigliamo di selezionare almeno due regioni per ospitare le NVA e usufruire del supporto per il failover tra regioni di questa architettura.

Progettare e creare la struttura del progetto

Crea o identifica i progetti in cui creerai le reti VPC. Avrai bisogno dei seguenti progetti:

• Un progetto per ospitare la rete di routing, in cui connetti la connettività esterna. Questo progetto ospita anche l'hub Network Connectivity Center che collega le tue connessioni ibride alle NIC esterne delle tue NVA.
• Progetti per ospitare la rete di transito e le reti VPC del workload. Per indicazioni, vedi Segmentazione della rete e struttura del progetto. Se intendi utilizzare reti VPC condiviso, provisiona i tuoi progetti come progetti host VPC condiviso.

Pianificare l'allocazione degli indirizzi IP

Crea un piano di allocazione degli indirizzi IP per le reti necessarie. Per semplificare l'aggregazione degli indirizzi di rete VPC del workload, scegli gli intervalli di indirizzi da un unico intervallo più ampio. Ti consigliamo di allocare un intervallo supernet di grandi dimensioni (ad esempio /12) da utilizzare per le assegnazioni di rete VPC del workload.

Il tuo piano deve includere intervalli IP per le seguenti reti:

• Reti esterne
• Rete VPC di routing
• Rete VPC di transito
• Un intervallo aggregato per tutte le reti VPC del workload

Crea la rete VPC di routing

La rete VPC di routing ospita i seguenti componenti:

• Connessioni ibride a reti esterne.
• Una NIC da ogni NVA. Nei diagrammi, questa NIC è etichettata come nic 0.
• Un router Cloud per regione.

Quando crei la rete VPC di routing, esegui le seguenti operazioni:

1. Nel progetto in cui vuoi la rete VPC di routing, crea la rete di routing come rete VPC in modalità personalizzata globale con il routing dinamico globale abilitato. Il routing dinamico globale è necessario per il routing tra regioni.
2. Nella rete di routing, crea una singola subnet per regione. Queste subnet ospitano le interfacce NVA utilizzate per il routing privato verso reti esterne e, facoltativamente, la comunicazione con internet.
3. Crea un router Cloud in ogni regione. Il router Cloud gestisce BGP tra la rete VPC e la rete esterna per quella regione. Ti consigliamo di creare NVA e reti VPC dei carichi di lavoro nella stessa regione della connessione ibrida per abilitare il routing locale tra le connessioni ibride e i carichi di lavoro tramite le NVA.
   • Se crei NVA e reti di workload nella stessa regione, ti serve un solo router Cloud di cui è stato eseguito il deployment in quella regione.
   • Se crei NVA in una regione e reti VPC del carico di lavoro in un'altra regione, hai bisogno di un router Cloud in ciascuna di queste regioni.

Crea connessioni alla rete esterna

Questa progettazione consiglia di utilizzare Cloud Interconnect per connettere la rete esterna alla rete VPC di routing Google Cloud . Tuttavia, puoi scegliere un altro prodotto di connettività. Per saperne di più, consulta Scelta di una Connettività di rete Connectivity.

Configura la connettività tra le reti esterne (on-premise e altri cloud) e la rete VPC di routing. Ti consigliamo di scegliere uno SLA del 99, 99% per i carichi di lavoro di produzione e di seguire le best practice di Google quando stabilisci la connessione.

Quando configuri le connessioni ibride alla rete esterna, se altre reti del cliente richiedono il routing da e verso località remote, annuncia le relative subnet come annunci di route personalizzati.

Crea le reti VPC di transito e del workload

Il ruolo della rete VPC di transito è quello di connettere le NVA alle reti VPC del workload.

1. Nel progetto in cui vuoi la rete di transito, crea la rete di transito come rete VPC in modalità personalizzata globale con il routing dinamico globale abilitato. Il routing dinamico globale è necessario per il routing tra regioni.
2. Crea una singola subnet per regione per ospitare le interfacce NVA utilizzate per il routing privato alle reti VPC dei carichi di lavoro.
3. Configura un router Cloud in ogni regione in cui prevedi di eseguire il provisioning delle NVA.
4. Crea le reti VPC del workload in base alle esigenze.

Crea le NVA

Per informazioni su come eseguire il provisioning di una NVA elencata in Google Cloud Marketplace, consulta la documentazione del fornitore di NVA. Quando configuri le NVA per questo progetto, segui queste linee guida:

1. Esegui il deployment delle NVA in coppie in almeno due regioni per fornire resilienza multiregionale. Poiché le NVA vengono aggiunte come spoke dell'appliance router Network Connectivity Center, non è necessario configurarle nei gruppi di istanze.
2. Le VM NVA richiedono almeno due NIC, ma alcuni fornitori richiedono una NIC dedicata per la gestione. Aggiungi le schede di interfaccia di rete necessarie per supportare i requisiti del fornitore.
3. Per garantire il routing simmetrico tramite una singola NVA attiva, le NVA devono impostare metriche BGP, come MED, per fornire preferenze di routing tra le NVA all'interno della regione. Ti consigliamo di utilizzare valori MED bassi, ad esempio 10 per il primario e 20 per il secondario. Poiché Google Cloud aggiunge un peso regionale per le reti remote, non è necessario impostare MED per la preferenza cross-regionale. Per saperne di più su come garantire la simmetria del routing, consulta la sezione Scalabilità riportata in precedenza in questo documento.
4. Per annunciare gli intervalli di subnet VPC del workload come route supernet aggregata o riepilogata, configura BGP sulla NIC NVA collegata alla rete di transito. Questa route è necessaria per abilitare la comunicazione VPC da workload a workload tramite le NVA. Configura le NVA in modo che annuncino tutte le subnet visibili al router Cloud.

Crea hub NCC 1

Il ruolo del primo hub NCC in questa progettazione è quello di abilitare la pubblicità della route dinamica tra le connessioni ibride e le NVA. Quando configuri l'hub NCC, segui queste linee guida:

1. Configura l'hub NCC nella topologia mesh in modo che consenta a tutti gli spoke di comunicare direttamente tra loro.
2. Aggiungi connessioni ibride (collegamenti VLAN o VPN) all'hub come spoke ibridi.
   • Attiva il trasferimento dei dati site-to-site. Per le località supportate, consulta Località supportate per il trasferimento dei dati.
   • Attiva l'opzione Includi gli intervalli di subnet IPv4 per l'esportazione dallo spoke all'hub.
   • Attiva l'opzione Includi tutti gli intervalli IPv4 dall'hub allo spoke.
3. Identifica le NIC NVA collegate alla rete VPC di routing e poi aggiungile all'hub NCC 1 come spoke dell'appliance router.
   • Attiva il trasferimento dei dati site-to-site.
   • Attiva l'opzione Includi gli intervalli di subnet IPv4 per l'esportazione dallo spoke all'hub.
   • Attiva l'opzione Includi tutti gli intervalli IPv4 dall'hub allo spoke.
4. Per garantire la resilienza, quando configuri le appliance router, crea sessioni BGP per entrambe le interfacce del router Cloud.

Crea hub NCC 2

Il secondo hub NCC consente l'annuncio di route dinamico tra le NVA e le reti VPC del workload. A questo scopo, aggiungi le NIC NVA come spoke appliance router e le reti VPC del carico di lavoro come spoke VPC.

1. Configura l'hub NCC nella topologia a stella in modo che il traffico tra gli spoke VPC del workload debba passare attraverso la rete VPC di transito (l'hub).
2. Aggiungi le NVA come spoke dell'appliance router al gruppo centrale dell'hub.
   1. Attiva i trasferimenti di dati site-to-site.
   2. Attiva l'opzione Includi tutti gli intervalli IPv4 per l'esportazione dallo spoke all'hub.
   3. Attiva l'opzione Includi gli intervalli IPv4 per l'importazione dall'hub allo spoke.
3. Aggiungi gli spoke VPC del carico di lavoro al gruppo edge.
4. Per garantire la resilienza, quando configuri gli spoke dell'appliance router, crea sessioni BGP per entrambe le interfacce del router Cloud.

Aggiungi l'accesso privato alle API di Google e ai servizi Google

Se le tue applicazioni non devono raggiungere le API di Google, puoi saltare questa sezione nella distribuzione iniziale e procedere con la configurazione dell'ingresso e dell'uscita centralizzati di internet.

Esistono due opzioni per abilitare l'accesso privato alle API di Google e ai servizi in base ai requisiti di logging e visibilità. Per ulteriori informazioni su questi servizi, vedi Tipi di servizi Google Cloud.

Routing diretto ai servizi Private Service Connect (non tramite le NVA)

1. Crea un endpoint Private Service Connect per le API di Google in ogni rete VPC.
2. Crea un endpoint Private Service Connect per i servizi pubblicati da Google in ogni rete VPC del workload che richiede l'accesso al servizio.
3. Per abilitare l'accesso dalla rete esterna, esegui il provisioning degli endpoint Private Service Connect nella rete VPC di routing. Per informazioni su come abilitare l'accesso privato da on-premise alle API di Google, consulta la documentazione di Private Service Connect.

Routing indiretto tramite la NVA

1. Nella rete VPC di routing, crea un endpoint Private Service Connect per le API di Google.
2. Nella rete VPC di transito, crea un endpoint Private Service Connect per le API di Google.

3. Configura il DNS nel seguente modo:

   1. Reti VPC del workload: configura il DNS per risolvere le chiamate API all'indirizzo IP dell'endpoint Private Service Connect nel VPC di routing.
   2. Reti esterne: configura il DNS per risolvere le chiamate API all'indirizzo IP dell'endpoint Private Service Connect che hai creato nella rete VPC di transito.

   Questo approccio consente alle NVA di inoltrare il traffico delle API di Google.

4. Crea un endpoint Private Service Connect per i servizi pubblicati da Google solo nel VPC del workload associato al servizio.

5. Per abilitare l'accesso tra reti VPC agli endpoint Private Service Connect per i servizi pubblicati da Google, attiva la propagazione di Private Service Connect su NCC hub 2.

Configura il traffico in entrata e in uscita da internet centralizzato

Se le tue applicazioni non devono raggiungere internet tramite le NVA, puoi saltare questa sezione nella tua implementazione iniziale e procedere con Test di connettività ai workload.

Traffico internet in entrata centralizzato

Per l'ingresso da internet, le NVA devono eseguire DNAT per il traffico quando viene instradato alla risorsa di destinazione nel VPC spoke. Per informazioni su come configurare Ingress, consulta Come configurare i bilanciatori del carico Google con le appliance virtuali di rete (NVA) in Google Cloud. In questa configurazione, assegni l'indirizzo di destinazione originale al bilanciatore del carico Google posizionato davanti alle NVA. Il tipo di bilanciatore del carico che selezioni influisce sulla natura globale del servizio di Ingress.

Traffico in uscita da internet centralizzato

Se vuoi centralizzare l'uscita a internet, le NVA devono eseguire SNAT per il traffico quando viene indirizzato alla risorsa di destinazione su internet. Per instradare il traffico dall'origine Google Cloud , le NVA devono pubblicizzare una route predefinita ai VPC spoke. Questo routing non richiede bilanciatori del carico.

Test della connettività ai carichi di lavoro

Per assicurarti di avere visibilità sui flussi di traffico, utilizza traceroute. Per testare la connettività per i diversi flussi, puoi creare VM di test in VPC diversi.

Passaggi successivi

• Per configurare il monitoraggio e la registrazione per la tua implementazione, consulta Osservabilità in Google Cloud.
• Per ulteriori strumenti di monitoraggio e risoluzione dei problemi, consulta la panoramica di Network Intelligence Center.
• Per ulteriori architetture di riferimento, diagrammi e best practice, esplora Cloud Architecture Center.

Collaboratori

Autore: Haider Witwit | Specialista di networking

Altri collaboratori:

• Jonathan Almaleh | Staff Technical Solutions Consultant
• Ghaleb Al-habian | Network Specialist
• Mark Schlagenhauf | Technical Writer, Networking
• Ammett Williams | Developer Relations Engineer
• Osvaldo Costa | Networking Specialist Customer Engineer