Panoramica dell'amministrazione dell'hub

Questa pagina fornisce una panoramica del ruolo di amministratore dell'hub Network Connectivity Center (NCC) (roles/networkconnectivity.hubAdmin). Un'entità Identity and Access Management (IAM) con il ruolo di amministratore dell'hub può eseguire le seguenti operazioni:

È possibile utilizzare anche i ruoli personalizzati, purché includano almeno le stesse autorizzazioni del ruolo di amministratore dell'hub NCC.

In che modo gli spoke VPC si uniscono a un hub

Se una rete VPC e un hub NCC si trovano nello stesso progetto, la creazione di uno spoke VPC per la rete VPC stabilisce immediatamente la connettività all'hub senza passaggi aggiuntivi.

Se una rete VPC e un hub NCC si trovano in progetti diversi, la procedura per creare uno spoke VPC è la seguente:

  1. Un amministratore dell'hub stabilisce i binding dei criteri IAM che consentono agli amministratori degli spoke in altri progetti di creare proposte di spoke VPC. Nota: gli amministratori dell'hub possono modificare i binding dei criteri IAM in qualsiasi momento. Ad esempio, un amministratore dell'hub potrebbe revocare l'accesso in un secondo momento, impedendo a un amministratore degli spoke di creare ulteriori proposte di spoke. Questo vale quando l'accettazione automatica per gli spoke non è abilitata.
  2. Durante la creazione dell'hub, l'amministratore dell'hub sceglie la topologia di connettività tra la topologia mesh predefinita e la topologia a stella.
  3. Un amministratore degli spoke propone uno spoke VPC. Se la proposta di spoke riguarda un hub configurato per utilizzare la topologia a stella, l'amministratore degli spoke assegna lo spoke al gruppo centrale o perimetrale. Per la topologia mesh, tutti gli spoke appartengono al singolo gruppo predefinito.
  4. Un amministratore dell'hub esamina ogni proposta di spoke e poi la accetta o la rifiuta. Di seguito viene descritto il funzionamento della connettività dell'hub dopo l'accettazione o il rifiuto di una proposta:
    • Uno spoke diventa attivo solo dopo che un amministratore dell'hub accetta la proposta di spoke. NCC fornisce la connettività di rete solo agli spoke attivi.
    • Un amministratore dell'hub può rifiutare uno spoke VPC accettato in precedenza, rendendolo inattivo. Quando uno spoke VPC precedentemente attivo diventa inattivo, NCC non fornisce la connettività di rete allo spoke.

Come funzionano le proposte di aggiornamento degli spoke

Quando uno spoke VPC o uno spoke VPC del producer esiste in un progetto diverso dall'hub, un amministratore dell'hub deve accettare o rifiutare le proposte di aggiornamento, a meno che non sia abilitata l'accettazione automatica per gli spoke. Questi aggiornamenti degli spoke possono essere modifiche agli intervalli di subnet IPv4 inclusi o esclusi (anteprima).

Per saperne di più sull'aggiornamento degli spoke, consulta Aggiornare uno spoke.

Accetta automaticamente i progetti

Un amministratore dell'hub può abilitare l'accettazione automatica per i gruppi di spoke in un hub. Quando è abilitata, gli spoke VPC che si trovano nell'elenco dei progetti di accettazione automatica vengono aggiunti o aggiornati immediatamente dopo la proposta di creazione o aggiornamento dello spoke VPC. La revisione e l'approvazione manuali da parte di un amministratore dell'hub vengono saltate.

La tabella di route dell'hub

La tabella di route dell'hub mostra le route di subnet importate dagli spoke VPC. Quando viene creato un nuovo spoke VPC, tutte le route di subnet locali della rete VPC vengono esportate nell'hub a meno che l'amministratore dello spoke non utilizzi il exclude-export-ranges flag in Google Cloud CLI o il campo excludeExportRanges nell'API. Per saperne di più, consulta Unicità delle route di subnet.

Quando crei un nuovo spoke VPC, si verifica quanto segue:

  • Uno spoke appartiene a un solo gruppo.
  • Ogni gruppo ha una tabella di route corrispondente.
  • Gli spoke sono associati a quella tabella di route.
  • Le subnet degli spoke vengono propagate a una o più tabelle di route.

Poiché nella connettività della topologia mesh è presente un solo gruppo predefinito, le route di subnet vengono propagate a una singola tabella di route dell'hub. Gli spoke connessi a un hub che supporta la topologia a stella appartengono a uno dei due gruppi diversi, ovvero centrale e perimetrale. Vengono quindi generate due tabelle di route dell'hub, una associata a ogni gruppo di spoke. Le route di subnet degli spoke nel gruppo centrale vengono propagate alle tabelle di route centrale e perimetrale. Le route di subnet degli spoke nel gruppo perimetrale vengono propagate alla tabella di route centrale.

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

Google Cloud aggiorna automaticamente la tabella di route della rete VPC di ogni spoke VPC e la tabella di route dell'hub NCC quando si verifica una delle seguenti condizioni:

Per saperne di più, consulta Tabelle di route che mostrano le route di subnet e Route nella documentazione VPC.

Passaggi successivi