spoke VPC
Network Connectivity Center fornisce connettività tra reti VPC su larga scala con il supporto degli spoke VPC. VPC gli spoke riducono la complessità operativa della gestione per le connessioni di peering di rete VPC a coppie attraverso l'uso spoke VPC e connettività centralizzata completamente gestito di Google. Gli spoke VPC esportano e importano tutte le route di subnet IPv4 da altri spoke VPC in un hub di Network Connectivity Center. Ciò garantisce connettività IPv4 completa tra tutti i carichi di lavoro che risiedono in tutte queste reti VPC. Rete tra VPC il traffico rimane all'interno della rete Google Cloud e non passa attraverso Internet, il che contribuisce a garantire privacy e sicurezza.
Gli spoke VPC possono trovarsi nello stesso progetto e nella stessa organizzazione o in una un progetto e un'organizzazione diversi dall'hub di Network Connectivity Center. Gli spoke VPC possono essere connessi a un solo hub alla volta.
Per informazioni su come creare uno spoke VPC, consulta Crea uno spoke VPC.
Confronto con il peering di rete VPC
Gli spoke VPC sono progettati per supportare i requisiti dei carichi di lavoro delle aziende di medie e grandi dimensioni per la connettività con routing tra intervalli di subnet IPv4 situati in molte reti VPC distinte.
Una rete VPC può essere sia uno spoke VPC di Network Connectivity Center sia connessa ad altre reti VPC tramite il peering di rete VPC. Tuttavia, le subnet delle route importate dalla rete VPC dello spoke Il peering di rete VPC non è condiviso con altri spoke VPC collegate all'hub di Network Connectivity Center. Di conseguenza, gestito che dispongono dell'accesso privato ai servizi non sono raggiungibili in modo transitivo per impostazione predefinita utilizzando altri spoke VPC di un Hub Network Connectivity Center. In questo caso, puoi rendere raggiungibile il servizio gestito mediante uno spoke VPC producer (anteprima).
Funzionalità | Peering di rete VPC | spoke VPC |
---|---|---|
Reti VPC |
Fino a 25 (è necessario ridurre altre quote VPC). |
Fino a 250 spoke VPC attivi per hub. |
Istanze VM |
Network Connectivity Center supporta fino al limite massimo per rete VPC (non sono necessarie quote separate per i gruppi di peering). |
|
Intervalli di subnet (route subnet) | ||
Route statiche e dinamiche |
500 route dinamiche per hub. Lo scambio di route statiche non è supportato. |
|
Esportare i filtri |
Filtri specifici non supportati. vedi Opzioni di scambio route nella documentazione sul peering di rete VPC. |
Fino a 16 intervalli CIDR supportati per spoke VPC. |
Indirizzi IP |
Indirizzi IP interni, inclusi indirizzi IP privati e privati utilizzati indirizzi IPv4 pubblici. Consulta: Intervalli IPv4 validi. |
Indirizzi IPv4 interni, inclusi indirizzi IP privati e esclusi gli indirizzi IPv4 pubblici utilizzati privatamente. Consulta: Intervalli IPv4 validi. |
Famiglie di indirizzi IP |
Indirizzi a doppio stack IPv4 e IPv6/IPv4 |
Solo indirizzi IPv4. |
Rendimento e throughput (rispetto ad altri meccanismi di connettività VPC) |
Latenza minima, velocità effettiva massima (equivalente VM-VM). |
Latenza più bassa, velocità effettiva più elevata (equivalente VM-VM). |
spoke VPC in un progetto diverso da un hub
Con Network Connectivity Center, puoi collegare reti VPC, rappresentate come spoke VPC, a un singolo hub in un altro progetto, incluso un progetto in un'altra organizzazione. Ciò ti consente di connettere le tue reti VPC tra più di progetti e organizzazioni su larga scala.
Gli utenti possono rientrare in uno dei seguenti tipi:
- Un amministratore dell'hub che possiede un hub in un progetto
- Un amministratore di spoke 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 a un progetto associato al rispettivo hub utilizzando Identity and Access Management (IAM). autorizzazioni aggiuntive. L'amministratore dello spoke della rete VPC crea uno spoke in un progetto diverso dall'hub. Questi spoke non sono attivi al momento della creazione. La l'amministratore dell'hub deve esaminarli e può accettare o rifiutare lo spoke. Se l'amministratore dell'hub accetta lo spoke, questo diventa attivo.
Network Connectivity Center accetta sempre automaticamente gli spoke creati nello stesso progetto come hub.
Per informazioni dettagliate su come gestire gli hub con spoke VPC in un progetto diverso dall'hub, consulta la Panoramica della gestione degli hub. Per dettagli informazioni per gli amministratori dello spoke, consulta Panoramica dell'amministrazione dello spoke.
Connettività VPC con filtri di esportazione
Network Connectivity Center consente di limitare la connettività di tutti gli spoke reti VPC solo a un sottoinsieme di subnet nello spoke in un VPC. Puoi limitare la connettività specificando gli intervalli di indirizzi IP da pubblicizzare e creando un elenco di intervalli CIDR che possono essere pubblicizzati dalla rete VPC. Puoi anche limitare la connettività specificando un elenco di intervalli CIDR consentiti, bloccando così tutti ma gli intervalli consentiti.
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. Le sottoreti corrispondenti all'intervallo specificato vengono escluse dall'esportazione nell'hub. Questo filtro
è utile quando hai subnet che devono essere private all'interno
rete VPC o sovrapporsi ad altre subnet nella
tabella di route hub.
Includi intervalli di esportazione
Puoi stabilire un elenco di intervalli CIDR che possono essere pubblicizzati
da uno spoke VPC utilizzando il flag include-export-ranges
o il campo includeExportRanges
nell'API. Viene stabilita una connettività più precisa se la utilizzi insieme all'intervallo di indirizzi IP del filtro di esclusione dell'esportazione. Questo filtro determina se un particolare intervallo di subnet può essere
pubblicizzato dalla rete VPC.
Considerazioni
Tieni presente quanto segue quando utilizzi i filtri di esclusione e inclusione degli intervalli di esportazione:
Gli intervalli di inclusione devono essere esclusivi tra loro, il che significa che non devono sovrapporsi. Ad esempio, supponiamo che esistano tre intervalli di indirizzi IP:
Range 1
:10.100.64.0/18
Range 2
:10.100.250.0/21
Range 3
:10.100.100.0/22
Range 1
erange 2
sono intervalli di inclusione validi perché non si sovrappongono. Tuttavia,range 3
è inferiore arange 1
, il che può causare sovrapposizioni, pertantorange 3
non è valido.Poiché Network Connectivity Center dispone già di filtri di esclusione di esportazione disponibili in il criterio di configurazione di rete, sia i filtri di inclusione che i filtri di esclusione dell'esportazione degli intervalli CIDR validi della configurazione di rete. Quando sono entrambi inclusi e Escludi filtri di esportazione, gli intervalli di indirizzi IP di inclusione devono essere un sovrainsieme degli intervalli di indirizzi IP di esclusione.
Per impostazione predefinita, tutti i criteri di connettività VPC includi l'intervallo CIDR di
0.0.0.0/0
, ciò significa che se non specifichi il filtro di inclusione durante la creazione dello spoke VPC; Network Connectivity Center imposta l'intervallo di inclusione predefinito su tutti i valori privati validi Indirizzi IPv4 come definiti 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 e10.1.100.0/24
e10.1.200.0/24
come intervalli di esclusione, il risultato è una connettività perfezionata con la combinazione di filtri di inclusione ed esclusione. Questi includono l'intervallo include tutti i valori da10.1.0.0/24
a10.1.99.0/24
,10.1.101.0/24
a10.1.199.0/24
e Da10.1.201.0/24
a10.1.255.0/24
.Gli intervalli di sottoreti esistenti continuano a funzionare come previsto. Gli intervalli che si sovrappongono a quelli inclusi e esclusi durante la creazione di nuovi intervalli di subnet generano un errore.
Esempi di nuovi intervalli di subnet non validi
Gli esempi seguenti mostrano intervalli di sottoreti non validi:
Sovrapposizione con intervallo di esclusione: supponiamo che esistano i seguenti intervalli di indirizzi IP.
Intervallo incluso:
10.0.0.0/8
Exclude range 4
:10.1.1.0/24
Subnet range 4
:10.1.0.0/16
In questo caso, l'intervallo di inclusione contiene
subnet range 4
. Tuttavia, è un superinsieme diexclude range 4
. Di conseguenza,subnet range 4
non è valido.Sovrapposizione con l'intervallo di inclusione: supponiamo che esistano i seguenti intervalli di indirizzi IP.
Includi intervallo:
10.1.1.0/24
Subnet range 5
:10.1.0.0/16
Subnet range 5
si sovrappone all'intervallo di inclusione, quindi non è valido.
Se inserisci un intervallo di subnet non valido durante la procedura di creazione della subnet, viene visualizzato un errore Invalid IPCiderRange
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 su tutti gli spoke VPC. Puoi scegliere una delle due preimpostazioni seguenti di classificazione:
- Topologia mesh
- Topologia a stella
Quando crei un hub utilizzando
Comando gcloud network-connectivity hubs create
,
scegli la topologia mesh o a stella preimpostata. Se la topologia non è specificata, viene applicata la topologia mesh. Dopo l'impostazione durante la creazione dell'hub, non puoi modificare la topologia
di un dato hub.
Per modificare le impostazioni di topologia di uno spoke, puoi eliminarlo e crearne uno nuovo con un nuovo hub che utilizza una topologia diversa.
Topologia mesh
La topologia mesh fornisce connettività di rete su larga scala tra gli spoke VPC.
Questa topologia consente a tutti gli spoke di connettersi e comunicare con
tra loro. Le subnet all'interno di questi spoke VPC sono completamente raggiungibili, a meno che non specifichi exclude export filters
.
Per impostazione predefinita, quando due o più reti VPC per i carichi di lavoro
sono configurate per partecipare a un hub di Network Connectivity Center come spoke,
Network Connectivity Center crea automaticamente una rete mesh completa tra
ogni spoke.
Tutti i raggi all'interno della topologia mesh appartengono a un unico gruppo predefinito. La topologia mesh è supportata sui tipi di spoke VPC e ibridi.
Il seguente diagramma mostra la connettività della topologia mesh in Network Connectivity Center.
Topologia a stella
La topologia a stella è supportata solo con gli spoke VPC. Quando utilizzi la topologia a stella per la connettività, i raggi di bordo e le relative sottoreti associate raggiungono solo i raggi centrali designati, mentre i raggi centrali possono raggiungere tutti gli altri raggi. In questo modo, viene garantita la segmentazione e la separazione della connettività tra le reti VPC perimetrali.
Poiché gli spoke VPC possono essere collegati a un hub di un progetto diverso, Gli spoke VPC possono provenire da diversi domini amministrativi. Questi spoke che si trovano in un progetto diverso dall'hub potrebbero non devono comunicare con ogni altro spoke dell'hub di Network Connectivity Center.
Puoi scegliere la topologia a stella per il seguente caso d'uso:
Carichi di lavoro in esecuzione su reti VPC diverse che non richiedono la connettività tra loro ma richiedono l'accesso solo le reti VPC tramite i servizi condivisi centrali rete VPC.
Controllo della sicurezza della comunicazione su più reti VPC che richiede che il traffico passi attraverso un insieme di appliance virtuali di rete (NVA) centralizzate.
Il seguente diagramma mostra la connettività di topologia a stella nel Network Connectivity Center.
center-vpc-a
e center-vpc-b
sono associati al gruppo centrale e
edge-vpc-c
e edge-vpc-d
sono associati al gruppo perimetrale. In questo caso,
l'utilizzo della topologia a stella consente a edge-vpc-c
e edge-vpc-d
di
connesso a center-vpc-a
e center-vpc-b
e per propagare le relative subnet
al gruppo centrale, ma non essere connessi tra loro (nessuna connettività diretta
tra edge-vpc-c
e edge-vpc-d
). Nel frattempo center-vpc-a
e center-vpc-b
sono collegati tra loro e sia a edge-vpc-c
che
edge-vpc-d
, consentendo così la piena raggiungibilità dal gruppo centrale
dai VPC ai VPC del gruppo perimetrale.
Gruppi di spoke
Un gruppo di spoke è un sottoinsieme di spoke collegati a un hub. Per configurare Network Connectivity Center utilizzando una topologia a stella, devi separare tutti gli spoke VPC in due diversi gruppi, denominati anche domini di routing:
- Un gruppo centro di spoke, che comunicano con ogni altro spoke connesso all'hub
- Un gruppo di raggi esterni, che comunicano solo con i raggi appartenenti al gruppo centrale
Uno spoke VPC può appartenere a un solo gruppo alla volta. I gruppi vengono creati automaticamente quando crei un hub.
Un amministratore dell'hub può aggiornare un gruppo di spoke utilizzando il comando gcloud network-connectivity hubs groups update
. L'amministratore dell'hub può aggiungere un elenco di ID progetto
numeri di progetto per attivare l'accettazione automatica per gli spoke. Se l'accettazione automatica è
viene attivato, lo spoke del progetto con accettazione automatica viene automaticamente connesso
l'hub senza la necessità di una revisione delle singole proposte di spoke.
Puoi elencare i gruppi center e edge come risorse nidificate per un
un hub specifico utilizzando
Comando gcloud network-connectivity hubs groups list --hub
.
Per gli hub creati con una topologia mesh, l'output restituisce il gruppo predefinito.
Per gli hub creati con topologia a stella, l'output restituisce gruppi centrali e periferici.
Per informazioni dettagliate su come configurare la topologia mesh o a stella per i tuoi spoke VPC, consulta Configurare un hub.
Limitazioni
Questa sezione descrive le limitazioni degli spoke VPC in generale e quando sono collegati a un hub in un altro progetto. Queste limitazioni si applicano anche agli spoke VPC del producer (anteprima).
Limitazioni degli spoke VPC
- Le reti VPC possono connettersi tra loro in modo esclusivo tramite l'hub di 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 di Network Connectivity Center. Tuttavia, considera
le seguenti:
- 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 IPv4 tra gli spoke VPC non è supportato.
- Le route che rimandano agli indirizzi IP virtuali dei bilanciatori del carico di rete passthrough interni in altri spoke VPC non sono supportate.
- Le subnet sovrapposte devono essere mascherate dai filtri di esclusione dell'esportazione.
- L'aggiornamento di
export range filters
dopo la creazione dello spoke VPC non è supportato. - Per uno spoke in un progetto diverso dall'hub, quando un nuovo Controlli di servizio VPC viene aggiunto il perimetro, non puoi aggiungere nuovi spoke violano il perimetro, ma gli spoke esistenti continuano a funzionare.
- La connettività di topologia a stella non supporta spoke ibridi o lo scambio dinamico di route.
Requisiti del periodo di attesa dopo l'eliminazione di uno spoke VPC
Per un nuovo spoke per la stessa rete VPC collegato a un hub diverso, devi attendere il periodo di attesa di almeno 10 minuti. Se il periodo di attesa adeguato non è consentito, il nuovo potrebbe non essere applicata. Questo periodo di attesa non è necessario se la rete VPC viene aggiunta come spoke allo stesso hub.
Quote e limiti
Per informazioni dettagliate sulle quote, consulta Quote e limiti.
Fatturazione
Ore di spoke
Le ore spoke vengono addebitate al progetto in cui si trova la risorsa spoke e
segue i prezzi standard per le ore di parlato. Le ore spoke vengono addebitate solo quando
lo spoke è 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 oltre 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, vedi Prezzi di Network Connectivity Center.
Passaggi successivi
- Per creare hub e spoke, consulta Utilizzare hub e spoke.
- Per visualizzare un elenco di partner le cui soluzioni sono integrate con Network Connectivity Center, consulta Partner di Network Connectivity Center.
- Per trovare soluzioni ai problemi comuni, consulta la sezione Risoluzione dei problemi.
- Per informazioni dettagliate sull'API e sui comandi
gcloud
, consulta API e riferimenti.