Panoramica degli spoke VPC

Questa pagina fornisce una panoramica del supporto degli spoke Virtual Private Cloud (VPC) in Network Connectivity Center.

Spoke VPC

Network Connectivity Center fornisce connettività di rete tra VPC su larga scala con il supporto degli spoke VPC. Gli spoke VPC riducono la complessità operativa della gestione delle singole connessioni di peering di rete VPC a coppie tramite l'utilizzo di spoke VPC e un modello di gestione della connettività centralizzato. Gli spoke VPC possono esportare e importare tutte le route di subnet da altri VPC spoke in un hub Network Connectivity Center. In questo modo, viene garantita la connettività completa tra tutti i carichi di lavoro che risiedono in tutte queste reti VPC. Il traffico di rete tra VPC rimane all'interno della rete Google Cloud e non passa attraverso internet, il che contribuisce a garantire la privacy e la sicurezza.

Gli spoke VPC possono trovarsi nello stesso progetto e nella stessa organizzazione o in un progetto e un'organizzazione diversi dall'hub Network Connectivity Center. Uno spoke VPC può essere connesso a un solo hub alla volta.

Per informazioni su come creare uno spoke VPC, consulta Creare uno spoke VPC.

Confronto con il peering di rete VPC

Gli spoke VPC supportano i requisiti delle medie e grandi aziende fornendo connettività di route della subnet IPv4 e IPv6 e connettività di route dinamica IPv4 utilizzando gli spoke ibridi.

Una rete VPC può essere contemporaneamente uno spoke VPC di Network Connectivity Center e connessa a un'altra rete VPC utilizzando il peering di rete VPC, a condizione che la rete VPC in peering non sia essa stessa uno spoke VPC.

Tieni presente quanto segue quando utilizzi gli spoke VPC di Network Connectivity Center e il peering di rete VPC:

  • Le route subnet di peering in uno spoke VPC non vengono esportate nell'hub.

  • Network Connectivity Center non fornisce connettività alle risorse in una rete VPC connessa a uno spoke VPC tramite il peering di rete VPC, con la seguente eccezione:

Funzionalità Peering di rete VPC Spoke VPC
Reti VPC

Peering per rete VPC

VPC spoke attivi per hub

Intervalli di subnet (route di subnet)

Intervalli di subnet per gruppo di peering

Route per tabella route della subnet

Route statiche e dinamiche

Route statiche per gruppo di peering

Route dinamiche per regione per gruppo di peering

Prefissi di route dinamiche univoci per tabella di route hub per regione.

Lo scambio di route statiche non è supportato.

Esportare i filtri

I filtri specifici non sono supportati. Consulta Opzioni di scambio di route nella documentazione sul peering di rete VPC.

Sono supportati fino a 16 intervalli CIDR per spoke VPC.

Inter-VPC NAT

Non supportata

Supportato

Propagazione della connessione Private Service Connect

Non supportata

Supportato

Connettività dello spoke VPC producer da altre reti VPC

Non supportata

Supportato

Indirizzamento IP

Indirizzi IPv4 interni, inclusi indirizzi IPv4 privati e indirizzi IPv4 pubblici utilizzati privatamente. Vedi Intervalli IPv4 validi.

Indirizzi IPv6 interni ed esterni.

Solo indirizzi IPv4 interni privati, esclusi gli indirizzi IPv4 pubblici utilizzati privatamente. Vedi Intervalli IPv4 validi.

Indirizzi IPv6 interni ed esterni.
Famiglie di indirizzi IP Configurazioni supportate:
  • Scambia solo intervalli di subnet IPv4
  • Scambia intervalli di subnet IPv4 e IPv6
 Configurazioni supportate:
  • Scambia solo intervalli di subnet IPv4
  • Scambia intervalli di subnet IPv4 e IPv6
  • Scambia solo intervalli di subnet IPv6
Rendimento e velocità effettiva (rispetto ad altri meccanismi di connettività VPC)

Latenza più bassa, throughput più elevato (equivalente VM-VM).

Latenza più bassa, throughput più elevato (equivalente VM-VM).

Spoke VPC in un progetto diverso da un hub

Utilizzando Network Connectivity Center, puoi collegare reti VPC, rappresentate come spoke VPC, a un singolo hub in un progetto diverso, incluso un progetto in un'organizzazione diversa. In questo modo puoi connettere le tue reti VPC in più progetti e organizzazioni su larga scala.

Puoi essere uno dei seguenti tipi di utenti:

  • Un amministratore hub proprietario di un hub in un progetto
  • Un amministratore spoke di rete VPC o un amministratore di rete che vuole aggiungere la propria rete VPC in un progetto diverso come spoke all'hub

L'amministratore dell'hub controlla chi può creare uno spoke VPC in un progetto diverso associato al proprio hub utilizzando le autorizzazioni Identity and Access Management (IAM). L'amministratore dello spoke di rete VPC crea uno spoke in un progetto diverso dall'hub. Questi raggi sono inattivi al momento della creazione. L'amministratore dell'hub deve esaminarli e può accettare o rifiutare lo spoke. Se l'amministratore hub accetta lo spoke, questo diventa attivo.

Network Connectivity Center accetta sempre automaticamente gli spoke creati nello stesso progetto dell'hub.

Per informazioni dettagliate su come gestire gli hub che hanno spoke VPC in un progetto diverso dall'hub, consulta la panoramica dell'amministrazione dell'hub. Per informazioni dettagliate per gli amministratori spoke, vedi Panoramica dell'amministrazione spoke.

Interazione dello spoke con i Controlli di servizio VPC

Network Connectivity Center supporta i Controlli di servizio VPC per gli spoke tra progetti e organizzazioni. Per uno spoke in un progetto diverso dall'hub, quando viene aggiunto un nuovo perimetro di Controlli di servizio VPC, non puoi aggiungere nuovi spoke che violano il perimetro. Tuttavia, gli spoke esistenti che hai aggiunto prima di aggiungere il perimetro diControlli di servizio VPCs continuano a funzionare.

Connettività VPC con filtri di esportazione

Network Connectivity Center ti consente di limitare la connettività di tutte le reti VPC spoke a solo un sottoinsieme di subnet nella rete VPC spoke. Puoi limitare la connettività nel seguente modo:

  • Puoi configurare lo spoke in modo che pubblicizzi tutti gli intervalli di subnet o nessuno.
  • Puoi modificare gli intervalli di indirizzi delle subnet esportate (anteprima).
  • Puoi specificare intervalli di indirizzi per impedire che vengano pubblicizzati e creare un elenco di intervalli CIDR che possono essere pubblicizzati dalla rete VPC. In alternativa, puoi specificare solo un elenco di intervalli CIDR consentiti, bloccando tutti gli intervalli tranne quelli consentiti.

Puoi utilizzare i filtri di esportazione per configurare gli spoke VPC in modo che scambino solo intervalli di subnet IPv4, solo intervalli di subnet IPv6 o entrambi. Considera uno spoke la cui rete VPC ha un mix di tipi di stack di subnet. Se configuri lo spoke per esportare solo intervalli di subnet IPv6, vengono scambiati gli intervalli IPv6 dalle subnet dual-stack e solo IPv6, ma non gli intervalli di subnet IPv4 dalle subnet solo IPv4 e dual-stack.

Escludi intervalli di esportazione

Puoi impedire la pubblicità di un intervallo di indirizzi IP utilizzando il flag --exclude-export-ranges in Google Cloud CLI o il campo excludeExportRanges nell'API. Tutti gli intervalli di indirizzi IP che corrispondono all'intervallo specificato vengono esclusi dall'esportazione nell'hub. Questo filtro è utile quando hai subnet che devono essere private all'interno della rete VPC o potrebbero sovrapporsi ad altre subnet nella tabella di routing hub.

Includi intervalli di esportazione

Puoi stabilire quali intervalli di indirizzi IP sono autorizzati a essere pubblicizzati da un VPC spoke utilizzando il flag --include-export-ranges o il campo includeExportRanges nell'API. Puoi specificare quanto segue:

  • Per annunciare tutti gli intervalli di subnet IPv4, puoi specificare ALL_PRIVATE_IPV4_RANGES.
  • Per pubblicizzare solo intervalli di subnet specifici, puoi specificare un elenco di intervalli CIDR.
  • Per annunciare tutti gli intervalli di subnet IPv6, puoi specificare ALL_IPV6_RANGES.

Stabilisci una connettività più precisa utilizzando un filtro di esportazione di inclusione insieme al filtro di esportazione di esclusione. Questo filtro determina se un intervallo di subnet specifico può essere <x0A>pubblicizzato dalla rete VPC.

Considerazioni

Tieni presente quanto segue quando utilizzi i filtri per intervalli di esportazione da escludere e includere:

  • Gli intervalli di inclusione devono essere esclusivi l'uno dell'altro, il che significa che non devono sovrapporsi. Ad esempio, supponiamo che esistano tre intervalli di indirizzi IPv4:

    Intervallo 1: 10.100.64.0/18

    Intervallo 2: 10.100.250.0/21

    Intervallo 3: 10.100.100.0/22

    L'intervallo 1 e l'intervallo 2 sono intervalli di inclusione validi perché non si sovrappongono. Tuttavia, l'intervallo 3 è contenuto nell'intervallo 1, quindi l'intervallo 3 non è valido.

    Se utilizzi IPv6, supponiamo di avere questi tre intervalli di indirizzi IPv6:

    Intervallo 1: 2001:db8::/32

    Intervallo 2: 2001:db9::/32

    Intervallo 3: 2001:db8:1000::/48

    L'intervallo 1 e l'intervallo 2 sono intervalli di inclusione validi perché non si sovrappongono. Tuttavia, l'intervallo 3 è contenuto nell'intervallo 1, quindi l'intervallo 3 non è valido.

  • Poiché Network Connectivity Center dispone già di filtri di esclusione dell'esportazione disponibili nelle norme di configurazione di rete, sia i filtri di inclusione che di esclusione dell'esportazione influiscono sugli intervalli CIDR di configurazione di rete validi. Quando vengono utilizzati sia i filtri di inclusione che quelli di esclusione per l'esportazione, gli intervalli di indirizzi IP di inclusione devono essere un superset degli intervalli di indirizzi IP di esclusione.

  • Se non specifichi il filtro di inclusione durante la creazione dello spoke VPC, Network Connectivity Center imposta l'intervallo di inclusione predefinito su tutti gli indirizzi IPv4 privati validi, come definito in Intervalli IPv4 validi.

  • Per perfezionare un intervallo di inclusione, puoi aggiungere più intervalli di esclusione. Ad esempio, se specifichi 10.1.0.0/16 come intervallo di inclusione e 10.1.100.0/24 e 10.1.200.0/24 come intervalli di esclusione, il risultato è una connettività perfezionata con la combinazione di filtri di inclusione ed esclusione. Questo intervallo include tutto da 10.1.0.0/24 a 10.1.99.0/24, da 10.1.101.0/24 a 10.1.199.0/24 e da 10.1.201.0/24 a 10.1.255.0/24.

  • Gli intervalli di subnet esistenti continuano a funzionare come previsto. Le sovrapposizioni con gli intervalli di inclusione ed esclusione durante la creazione di nuovi intervalli di subnet generano un errore.

Esempi di intervalli di subnet non validi

I seguenti esempi mostrano intervalli di subnet non validi:

  • Sovrapposizione con l'intervallo di esclusione

    In questo caso, l'intervallo di inclusione seguente contiene l'intervallo di subnet 4, che è un sovrainsieme dell'intervallo di esclusione 4. Ciò significa che l'intervallo di subnet 4 non è valido.

    Includi intervallo: 10.0.0.0/8

    Escludi intervallo 4: 10.1.1.0/24

    Intervallo di subnet 4: 10.1.0.0/16

  • Sovrapposizione con l'intervallo di inclusione

    L'intervallo di subnet 5 si sovrappone all'intervallo di inclusione, pertanto non è valido.

    Intervallo incluso: 10.1.1.0/24

    Intervallo di subnet 5: 10.1.0.0/16

    Quando inserisci un intervallo di subnet non valido durante la procedura di creazione della subnet, viene visualizzato un errore Invalid IPCidrRange simile al seguente:

    Invalid IPCidrRange: CIDR_RANGE conflicts with existing subnetwork SUBNET_RANGE in region REGION

Topologie preimpostate

Network Connectivity Center ti consente di specificare la configurazione di connettività desiderata in tutti gli spoke VPC. Puoi scegliere una delle seguenti due topologie preimpostate:

Per informazioni dettagliate sulle topologie di connettività, vedi Topologie di connettività preimpostate.

Per informazioni dettagliate su come configurare la topologia mesh o a stella per i VPC spoke, vedi Configurare un hub.

Limitazioni

Questa sezione descrive le limitazioni degli spoke VPC in generale e quando sono collegati a un hub in un progetto diverso. Queste limitazioni si applicano anche agli spoke VPC del producer.

Limitazioni degli spoke VPC

  • Le reti VPC possono connettersi tra loro in modo esclusivo tramite l'hub Network Connectivity Center o tramite il peering di rete VPC.
  • Non puoi utilizzare il peering di rete VPC tra due spoke VPC connessi allo stesso hub Network Connectivity Center. Tuttavia, tieni presente quanto segue:
    • Uno spoke VPC producer richiede una connessione di peering a uno spoke VPC sullo stesso hub. La connettività tramite Network Connectivity Center non è stabilita tra lo spoke VPC producer e lo spoke VPC in peering.
    • Puoi avere uno spoke VPC connesso a Network Connectivity Center che è in peering tramite peering di rete VPC con un VPC separato che non fa parte di Network Connectivity Center.
  • Le VPC connesse tra loro utilizzando Network Connectivity Center e il peering di rete VPC in qualsiasi combinazione non sono transitive.
  • Lo scambio di route statiche tra gli spoke VPC non è supportato.
  • Le route che puntano agli indirizzi IP virtuali del bilanciatore del carico di rete passthrough interno in altri spoke VPC non sono supportate.
  • I bilanciatori del carico di rete passthrough interni basati su IPv6 non sono raggiungibili tra i VPC spoke.
  • Lo scambio di route dinamiche IPv6 non è supportato.
  • Le reti VPC in modalità automatica non sono supportate come VPC spoke. Puoi passare dalla modalità automatica alla modalità personalizzata della rete VPC, che ti consente di definire manualmente i prefissi della subnet per ogni regione della tua rete VPC. Una volta aggiornato, non puoi annullare questa azione.

Limitazioni dello scambio di itinerari dinamici

  • Solo IPv4: Network Connectivity Center supporta solo lo scambio di route dinamici IPv4. Lo scambio di route dinamiche IPv6 non è supportato.

  • Compatibilità degli spoke ibridi con la topologia a stella: un hub configurato per utilizzare la topologia a stella impone le seguenti limitazioni ai suoi spoke ibridi:

    • Gli spoke ibridi con trasferimento di dati site-to-site abilitato sono supportati solo nel gruppo di spoke centrale.
    • Gli spoke ibridi senza il trasferimento di dati da sito a sito abilitato possono trovarsi nel gruppo di spoke centrale o nel gruppo di spoke periferico.

  • Reti VPC di routing che sono anche spoke VPC: Network Connectivity Center supporta due o più reti VPC di routing sullo stesso hub solo se tutte le reti VPC di routing non sono anche spoke VPC. Se un hub di Network Connectivity Center ha una sola rete VPC di routing, questa può essere facoltativamente anche uno spoke VPC:

    • Se devi rendere disponibili le connessioni Private Service Connect propagate alle reti on-premise tramite gli spoke ibridi dell'hub, anche la singola rete VPC di routing dell'hub deve essere connessa come spoke VPC.

    • Se non devi rendere disponibili le connessioni Private Service Connect propagate alle reti on-premise tramite gli spoke ibridi dell'hub, ti consigliamo di non configurare una rete VPC di routing come spoke VPC in modo che l'hub possa supportare due o più reti VPC di routing.

  • Regole di interazione delle route dinamiche: all'interno di una rete VPC di routing, per ogni destinazione di route dinamica univoca con un hop successivo in uno spoke ibrido, devi assicurarti che tutte le altre route dinamiche, indipendentemente dalla priorità, le cui destinazioni corrispondono esattamente o rientrano nella destinazione di route dinamica univoca, abbiano anche tunnel Cloud VPN o collegamenti VLAN di hop successivo in uno spoke ibrido. Inoltre, devi assicurarti che questi spoke ibridi utilizzino la stessa impostazione di trasferimento dei dati da sito a sito (attivata o disattivata).

    • Se solo alcuni hop successivi per le route dinamiche con una destinazione comune si trovano negli spoke ibridi, Network Connectivity Center non può scambiare in modo affidabile le route dinamiche che utilizzano quella destinazione con gli spoke VPC sull'hub. Di conseguenza, gli spoke VPC potrebbero non ricevere queste route dinamiche.

    • Network Connectivity Center non esegue ECMP tra tutti gli hop successivi delle route dinamiche spoke ibride se alcuni spoke ibridi hanno il trasferimento di dati da sito a sito attivato, mentre altri lo hanno disattivato. Se le route dinamiche con una destinazione comune si trovano in spoke ibridi senza impostazioni di trasferimento di dati da sito a sito corrispondenti, gli hop successivi per il trasferimento di dati da sito a sito o per la connettività tra gli spoke VPC e le reti on-premise potrebbero non essere quelli che ti aspetti.

  • Regole di interazione tra route dinamiche e statiche: all'interno di una rete VPC di routing, per ogni destinazione di route dinamica univoca che ha un hop successivo in uno spoke ibrido, devi assicurarti che non esistano route statiche locali, indipendentemente dalla priorità, le cui destinazioni corrispondano esattamente o rientrino nella destinazione della route dinamica.

    • Se una route statica locale nella rete VPC di routing ha la stessa destinazione di una route dinamica spoke ibrida, gli spoke VPC potrebbero perdere la connettività alla destinazione della route dinamica.

    • Se una route statica locale in una rete VPC di routing ha una destinazione che rientra nella destinazione di una route dinamica dello spoke ibrido, gli spoke VPC perdono la connettività alla destinazione della route statica.

Periodo di raffreddamento dopo l'eliminazione di uno spoke VPC

Per un nuovo spoke per la stessa rete VPC collegata a un hub diverso, devi attendere il periodo di raffreddamento di almeno 10 minuti. Se non viene concesso un periodo di raffreddamento adeguato, la nuova configurazione potrebbe non essere applicata. Questo periodo di raffreddamento non è necessario se la rete VPC viene aggiunta come spoke allo stesso hub.

Quote e limiti

Quando utilizzi lo scambio di route dinamiche, monitora attentamente l'utilizzo del numero di route dinamiche per hub. Questa quota conteggia l'utilizzo per destinazione (prefisso) solo, senza considerare la priorità o l'hop successivo di una route dinamica. Quando l'utilizzo di questa quota supera il limite, Network Connectivity Center elimina le route per destinazione. Se una destinazione viene eliminata, tutte le route dinamiche con quella destinazione, indipendentemente dalla priorità o dall'hop successivo, non vengono più inviate all'hub.

Per informazioni dettagliate sulle quote, consulta Quote e limiti.

Fatturazione

Ore di spoke

Le ore di spoke vengono addebitate al progetto in cui si trova la risorsa spoke e seguono i prezzi standard delle ore di spoke. Le ore di utilizzo del satellite vengono addebitate solo quando il satellite è nello stato ACTIVE.

Traffico in uscita

Il traffico in uscita viene addebitato al progetto della risorsa spoke da cui ha origine il traffico. Il prezzo è lo stesso indipendentemente dal fatto che il traffico superi i confini del progetto.

Accordo sul livello del servizio

Per informazioni sull'accordo sul livello del servizio di Network Connectivity Center, consulta Accordo sul livello del servizio (SLA) di Network Connectivity Center.

Prezzi

Per informazioni sui prezzi, consulta la pagina relativa ai prezzi di Network Connectivity Center.

Passaggi successivi