Hybrides Netzwerkmanagement mit Google NCC
Drehkreuz im Cloudnetz
Veröffentlicht in Ausgabe 07/2025 - SCHWERPUNKT
Für Cloud Computing werden immer wieder eine Reihe von Vorteilen genannt. Dazu gehören die Kosteneffizienz durch Pay-as-you-go-Modelle und reduzierte Anfangsinvestitionen, die Skalierbarkeit, die Zugänglichkeit über das Internet, aber auch der Innovationsaspekt. Gerade was letzteren Punkt angeht, konnten insbesondere die US-amerikanischen Hyperscaler wie AWS, Azure oder Google mit fortschrittlichen Diensten und Konzepten punkten.
Ausgangspunkt Virtual Private Cloud
Ein Beispiel dafür ist das Netzwerkkonzept Virtual Private Cloud (VPC), das AWS bereits im Jahr 2009 eingeführt hat und mit dem Unternehmen isolierte virtuelle Netzwerke innerhalb der Amazon-Cloud erstellen und konfigurieren können. In den Anfangstagen der Cloud stellten VPCs nur eine minimale Grundfunktionalität bereit. Dazu gehörte, IP-Adressbereiche zu definieren und damit Subnetze zu erzeugen, Routing-Tabellen zu konfigurieren und Sicherheitsgruppen sowie Netzwerk-ACLs (Access Control Lists) zu erzeugen und anzuwenden.
Schon bald stiegen aber die Wünsche der Kunden, sodass die Hyperscaler die Funktionalität von VPCs immer offensiver erweiterten. Auch hier war AWS in den Anfangsjahren Pionier. Im Jahr 2014 gab es mittels VPC Peering erstmals die Möglichkeit, VPCs miteinander zu verbinden. Allerdings stellte sich bald heraus, dass der Aufwand, Cloudumgebungen mit Hunderten VPCs mittels Peering zu verbinden doch recht beträchtlich ist und erhebliche Betriebsaufwände mit sich bringt.
Für Cloud Computing werden immer wieder eine Reihe von Vorteilen genannt. Dazu gehören die Kosteneffizienz durch Pay-as-you-go-Modelle und reduzierte Anfangsinvestitionen, die Skalierbarkeit, die Zugänglichkeit über das Internet, aber auch der Innovationsaspekt. Gerade was letzteren Punkt angeht, konnten insbesondere die US-amerikanischen Hyperscaler wie AWS, Azure oder Google mit fortschrittlichen Diensten und Konzepten punkten.
Ausgangspunkt Virtual Private Cloud
Ein Beispiel dafür ist das Netzwerkkonzept Virtual Private Cloud (VPC), das AWS bereits im Jahr 2009 eingeführt hat und mit dem Unternehmen isolierte virtuelle Netzwerke innerhalb der Amazon-Cloud erstellen und konfigurieren können. In den Anfangstagen der Cloud stellten VPCs nur eine minimale Grundfunktionalität bereit. Dazu gehörte, IP-Adressbereiche zu definieren und damit Subnetze zu erzeugen, Routing-Tabellen zu konfigurieren und Sicherheitsgruppen sowie Netzwerk-ACLs (Access Control Lists) zu erzeugen und anzuwenden.
Schon bald stiegen aber die Wünsche der Kunden, sodass die Hyperscaler die Funktionalität von VPCs immer offensiver erweiterten. Auch hier war AWS in den Anfangsjahren Pionier. Im Jahr 2014 gab es mittels VPC Peering erstmals die Möglichkeit, VPCs miteinander zu verbinden. Allerdings stellte sich bald heraus, dass der Aufwand, Cloudumgebungen mit Hunderten VPCs mittels Peering zu verbinden doch recht beträchtlich ist und erhebliche Betriebsaufwände mit sich bringt.
Kunden halfen sich mit Cloud-Appliances, mit deren Hilfe sie VPNs zwischen VPCs aufspannten und so ein VPC-Mesh aus Peerings mit einer Hub-and-Spoke-Architektur verbanden. Spätestens mit der Einführung des AWS-Transit-Gateways sind solche Ansätze Best Practices in Cloudlandschaften. Derselbe Ansatz findet sich auch in der Azure-Firewall. In der Google-Cloud sind in den meisten Nutzerumgebungen nur eine deutlich kleinere Anzahl von VPCs im Einsatz. Dies liegt daran, dass VPCs als globale Ressourcen erstellt werden und die darin enthaltenen Subnetze auf Ebene der Regionen definiert sind.
NCC als zentrale Verwaltungsinstanz
Um 2017 herum gelang Google mit der Einführung von Shared VPCs ein großer Schritt. Diese ermöglichten es, Netzwerkressourcen innerhalb einer Google-Organisation über Projektgrenzen zu verwalten. Dabei wird ein zentrales VPC-Netzwerk in einem Host-Projekt erzeugt und mit anderen Serviceprojekten innerhalb der Organisation geteilt. In vielen Unternehmen bilden seitdem Shared VPCs zusammen mit Peerings und VPN-Verbindungen die Komponenten, auf denen die Netzwerkinfrastruktur fußt.
Nichtdestotrotz kam auch in der Google-Welt der Wunsch auf, die Verwaltung der Netzwerkverbindungen übersichtlicher zu gestalten. Das Google Network Connectivity Center (NCC) soll deshalb als Orchestrierungs-Framework die Verwaltung komplexer Cloud- und Hybridumgebungen deutlich einfacher und von einem zentralen Punkt gestalten. In seiner Grundidee basiert NCC auf einem Hub-and-Spoke-Modell, bei dem ein zentraler Hub (Nabe) verschiedene Spokes (Speichen) anbinden und verwalten kann. Dabei bietet es eine Reihe von Funktionalitäten:
- Einer der Hauptfunktionen besteht in der zentralen Verwaltung. Dabei bietet NCC eine zentrale API zum Anbinden der Spokes sowie die Kontrolle über die Netzwerkkommunikation zwischen den Speichen.
- Das NCC abstrahiert von den zugrundeliegenden Netzwerktechnologien durch unterschiedliche Spoke-Arten. Dabei bietet das NCC neben reinen VPC-Spokes auch VPN-basierte oder reguläre Cloudkonnektivität, Interconnect-Spokes sowie Unterstützung für Appliances an.
- Es gibt eine Integration in bekannte SD-WAN-Produkte und Router-Appliances wie zum Beispiel von Palo Alto oder Cisco.
- NCC unterstützt zwei verschiedene Betriebsmodelle. In einer Mesh-Konfiguration wird ein Netz aufgebaut, in dem jeder Spoke miteinander kommunizieren kann. Dagegen bietet das Sternmodell feingranulare Kontrollmöglichkeiten, welche Speichen miteinander in Verbindung treten können.
Google positioniert NCC für eine Reihe von Use-Cases. Im einfachsten Szenario vereinfacht NCC die existierende Netzwerkkonnektivität und bildet so einen Rahmen, um eine hybride Anbindung mittels VPN oder Interconnect mit den VPCs innerhalb der Google Cloud zu schaffen.
In einem konkreten Anwendungsfall für SD-WAN ließen sich zum Beispiel Router-Appliances und SD-WAN-Komponenten an das NNC anbinden Dabei gibt es zwei Router-Appliances-Spokes. Die zugeordneten Geräte stellen die Kommunikation mit dem Data Center her. Mittels der Cloudrouter kann NCC Routingregeln auslesen und propagieren und somit eine SD-WAN-Funktionalität bereitstellen.
Als weiteren Hauptanwendungsfall nennt Google Multicloud-VPN-Konnektivität. So ist es möglich, mittels VPN-Gateways eine Kommunikation mit VPN-Endpunkten in anderen Clouds zu etablieren.
Anlegen eines NCC-Hubs
Die Inbetriebnahme eines NCC-Hubs verläuft über die grafische Benutzeroberfläche der Google Console sehr flüssig. Als Voraussetzung benötigen Sie ein Projekt, in dem sich der NCC-Hub erzeugen lässt. Anschließend müssen Sie dafür sorgen, über die notwendigen Berechtigungen zu verfügen. Am einfachsten geht dies, wenn Sie die IAM-Rolle "Hub and Spoke Admin" vergeben.
Wechseln Sie dazu innerhalb der Google Console links zum Menüpunkt "IAM & Admin / IAM" und vergeben Sie dort mit "Grant Access" die entsprechende Rolle. Anschließend navigieren Sie zu "Network Connectivity / Network Connectivity Center". Auf der Übersichtsseite klicken Sie auf "Create Hub", worauf ein Assistent startet (Bild 1). Für das Anlegen des Hubs müssen Sie dessen Namen und optional eine Beschreibung eintippen. Standardmäßig ist als Topologie der Mesh-Modus aktiviert.
Zudem empfiehlt sich, die Option "Private Service Connect connection propagation" zu aktivieren. Viele Google-Dienste wie beispielsweise die Google Kubernetes Engine oder Google Cloud SQL können private Endpunkte in VPCs erzeugen (früher wurde mittels Peering kommuniziert). Mit dieser Option werden die entsprechenden Endpunkte auch geroutet und sind so aus anderen Netzwerken und von lokaler Ebene aus erreichbar.
Anschließend fügen Sie nach Belieben Spokes hinzu und beenden den Assistenten. Ein schlichtes Szenario besteht aus einem Hub und zwei Spokes. Anschließend sollten Sie die Konnektivität einem Testlauf unterziehen. Dazu ordnen Sie jeder VPC eine VM zu – ein einfacher Ping-Test sorgt für den Verbindungscheck.
Die Wahl der richtigen Topologie
Wie schon erwähnt, lässt sich NCC entweder als Mesh- oder Sterntopologie konfigurieren. Beides hat seine Vor- und Nachteile. Für kleinere und mittlere Umgebungen empfiehlt sich die Mesh-Struktur, bei der alle VPC-Spokes zu einer Gruppe zusammengeschlossen werden und miteinander kommunizieren können – es sei denn, Sie schränken die Kommunikation mit Exclude-Export-Filtern ein.
Die Sterntopologie fällt dagegen komplexer aus und erlaubt, die Kommunikation feingranularer zu kontrollieren. Spokes sind entweder als Edge- oder als Center-Spoke konfigurierbar. Dabei kann die Edge-Variante nur die Spokes im Zentrum erreichen, aber keine anderen Edge-Spokes. Die Center-Spokes hingegen können mit allen Edge-Spokes in Kontakt treten.
Für diese Architektur gibt es verschiedene Anwendungsfälle. So realisieren Sie damit Szenarien, in denen nicht alle VPCs miteinander kommunizieren sollen, weil eine Trennung nach Workload gewünscht ist. Gleichzeitig sind aber gemeinsame Dienste für alle zugänglich – dies könnte zum Beispiel bei einer Trennung nach Stages (Dev, Test, QA, Prod) oder nach Anwendungen der Fall sein.
Darüber hinaus ist es mit dieser Architektur möglich, in zentralen VPC-Spokes Security-Appliances zu betreiben, die jeglicher Netzwerkverkehr durchfließen muss.
Bild 2 visualisiert eine beispielhafte Sterntopologie. Dabei existieren eine Edge-Gruppe mit den VPCs "edge-vpc-c" und "edge-vpc-d" auf der linken Seite und eine Center-Gruppe mit den VPCs "center-vpc-a" und "center-vpc-b" rechts. Die beiden Edge-VPCs exportieren dabei ihre Subnets und eine Kommunikation mit den Center-VPCs ist möglich – eine Verbindung zwischen den Edge-VPCs dagegen ist nicht gestattet.
Hybride Konnektivität umsetzen
Falls Sie eine Konnektivität mit lokalen Rechenzentren herstellen wollen, ist ein Hybrid-Spoke auszuwählen, mit dessen Hilfe Sie Router-Appliances, hochverfügbare VPN-Tunnel oder ein Cloud-Interconnect-VLAN an das NCC anbinden können – das Vorhandensein dieser Konfiguration ist entsprechend eine Voraussetzung für ein Hybrid Spoke. Bild 3 zeigt, wie die verschiedenen Hybrid-Spoke-Arten mit NCC zusammenspielen.
Um beispielsweise einen Hybrid Spoke für ein VPN zu konfigurieren, überprüfen Sie zuerst die Berechtigungen. Erstellen Sie das Spoke im gleichen Projekt wie den Hub, reichen die zuvor beschriebenen Berechtigungen. Im Fall eines separaten Projekts benötigen Sie die Rolle "Spoke Admin" Dabei kann sich ein Spoke auch in einer anderen Organisation als der Hub befinden.
Wechseln Sie auf der Hauptseite des Network Connectivity Center auf die Registrierkarte "Spoke". Mit einem Klick auf den Button "Add Spokes" starten Sie einen Assistenten. Hier wählen Sie als Erstes den Hub aus, zu dem Sie den Spoke hinzufügen wollen. Im nächsten Schritt wählen Sie den Spoke-Typ aus – in unserem Fall ein VPN-Tunnel.
Zur weiteren Konfiguration vergeben Sie einen Spoke-Namen, eine optionale Beschreibung, die Region, das entsprechende VPC-Netzwerk sowie die VPN-Tunnel. Anschließend klicken Sie auf "Done" und danach auf "Create", um den Assistenten abzuschließen.
Listing 1: Erzeugen einer Cloud-SQL-Instanz
gcloud config set project ${project}
gcloud sql instances create mysql-instance \
--project="${project}" \
--region=us-central1 \
--enable-private-service-connect \
--allowed-psc-projects="${project}" \
--availability-type=zonal \
--no-assign-ip \
--tier=db-f1-micro \
--database-version=MYSQL_8_0 \
--enable-bin-log
Dienste sicher bereitstellen mit Private Service Connect
Neben der Unterstützung von klassischen VPCs und Hybrid Spokes bietet NCC auch die Möglichkeit, Private-Service-Connect-Endpunkte (PSC) auf einfache Art und Weise in die eigene Architektur zu integrieren. PSV wurde zum einen dafür entwickelt, um Zugriff auf Google-APIs (zum Beispiel REST-basierte APIs wie die Google-Cloud-Storage-API) über private Verbindungen zu ermöglichen, anderseits, damit APIs auf Layer 7 über VPC-Grenzen hinweg unabhängig von einer Layer-3- oder Layer-4-Verbindung freigegeben oder konsumiert werden können. Damit sich derartige Services veröffentlichen lassen, muss für den Dienst ein Loadbalancer existieren und dieser mit einem sogenannten "Service Attachment" versehen werden.
Standardmäßig verhalten sich PSC-Verbindungen zwischen VPC-Spokes nicht-transitiv. Dies lässt sich aber ändern, indem Sie eine Propagation über den NCC-Hub erstellen, sodass dadurch die PSC-Endpunkte in der Routingtabelle jedes Spokes auftauchen und erreichbar sind. Dabei erlaubt NCC, die Propagation global und regional einzurichten. Letztere Option ist dann relevant, wenn Sie je nach Region einen unterschiedlichen Endpunkt ansprechen wollen.
Die Propagation von PSC-Endpunkten ist insbesondere für folgende Anwendungsfälle interessant:
- Es werden eine Reihe von gemeinsamen Services identifiziert, zum Beispiel die REST-API eines CMDB-Dienstes. Sie wollen diese allen VPC-Spokes zugänglich machen, aber dennoch zentral als Endpunkt verwalten. Damit entfällt die mehrfache Administration der Endpunkte in den Spokes.
- Falls Sie mittels hybriden Spokes eine Verbindung Richtung lokaler Strukturen hergestellt haben, ist es möglich, PSC-Endpunkte in einem VPC-Spoke aus dem lokalen Datacenter heraus anzusprechen.
Im Folgenden zeigen wir die Konfiguration von PSC-Endpunkten in einem NCC-Setup anhand eines Datenbankzugriffs. Dabei nehmen wir an, dass die abgebildeten VPCs und Subnetze bereits vorhanden sind. Die aufzubauende Architektur ist in Bild 4 gezeigt. Mit den Eingaben aus Listing 1 erzeugen Sie in einem ersten Schritt eine Cloud-SQL-Instanz. Anschließend rufen Sie mit
gcloud sql instances describe mysql-instance \
--format='value(pscServiceAttachmentLink)'
die Informationen zum Private-Service-Attachment ab. Nun ist es wie in Listing 2 noch notwendig, eine IP-Adresse für den PSC-Endpunkt zu reservieren und eine entsprechende Weiterleitungsregel zu konfigurieren. Danach gehen Sie die Konfiguration des NCC an. Mit
hub_name="ncc-hub"
gcloud network-connectivity hubs create "${hub_name}" \
--export-psc
aktivieren Sie die PSC-Propagation. Im Anschluss fügen Sie wie in Listing 3 die Spoke-VPCs hinzu.
Listing 2: IP-Adresse und Weiterleitungsregel
region="us-central1"
vpc_spoke_subnet_name="csql-psc-subnet"
# IP-Adresse reservieren
gcloud compute addresses create csql-psc-ip \
--subnet="${vpc_spoke_subnet_name}" \
--region="${region}" \
--addresses=192.168.0.253
#Namen abrufen
gcloud compute addresses list \
--filter="name=csql-psc-ip"
vpc_spoke_network_name="vpc1-spoke"
vpc_spoke_subnet_name="csql-psc-subnet"
region="us-central1"
#Abrufen der Service Attachment Informationen
csql_psc_ep_name="csql-psc-ep"
sa_uri=$(gcloud sql instances describe mysql-instance \
--format='value(pscServiceAttachmentLink)')
echo "$sa_uri"
#Erstellen der Weiterleitungsregel
gcloud compute forwarding-rules create "${csql_psc_ep_name}" \
--address=csql-psc-ip \
--region="${region}" \
--network="${vpc_spoke_network_name}" \
--target-service-attachment="${sa_uri}" \
--allow-psc-global-access
Listing 3: Spoke-VPCs hinzufügen
vpc_spoke_name="sql-vpc1-spoke"
vpc_spoke_network_name="vpc1-spoke"
gcloud network-connectivity spokes linked-vpc-network create "${vpc_spoke_name}" \
--hub="${hub_name}" \
--vpc-network="${vpc_spoke_network_name}" \
--global
vpc_spoke_name="sql-vpc3-spoke"
vpc_spoke_network_name="vpc3-spoke"
gcloud network-connectivity spokes linked-vpc-network create "${vpc_spoke_name}" \
--hub="${hub_name}" \
--vpc-network="${vpc_spoke_network_name}" \
--global
Automatisierung mit Terraform und Infrastructure-as-Code
In vielen Unternehmen gehört die größtmögliche Automatisierung sämtlicher Infrastrukturkomponenten mittlerweile zum guten Ton. In den letzten Jahren hat sich für Infrastructure-as-Code (IaC) Terraform als Standard etabliert. Wie alle Komponenten in der Google-Cloud wurde auch NCC API-first entwickelt und findet entsprechende Unterstützung in Terraform. Darüber hinaus bietet der Hyperscaler Unterstützung in Form von fertig nutzbaren Modulen. Für NCC finden sich beispielsweise derartige Module in der "Cloud Foundation Fabric".
Das Snippet aus Listing 4 zeigt, wie Sie einen NCC-Hub mit einem Spoke inklusive Anbindung einer Router-Appliance erzeugen. Dabei erstellen Sie zuerst mit der Resource "default" vom Typ "google_network_connectivity_hub" ein HCC-Hub. Anschließend gelingt mit dem Modulaufruf die Erzeugung eines Spokes. Dieser wird durch den Parameter "hub" an den oben definierten NCC-Hub angebunden und befindet sich im selben Projekt.
Listing 4: NCC mit Terraform automatisieren
resource "google_network_connectivity_hub" "default" {
Name = "Hub"
description = "Hub"
project = var.project_id
}
module "spoke-ra-a" {
source = "./fabric/modules/ncc-spoke-ra"
hub = { id = google_network_connectivity_hub.default.id }
name = "spoke-ra-a"
project_id = var.project_id
region = var.regions.primary
router_appliances = [
{
internal_ip = module.compute-vm- primary-b.internal_ip
vm_self_link = module.compute- vm-primary-b.self_link
}
]
router_config = {
asn = 65000
ip_interface0 = "10.0.16.14"
ip_interface1 = "10.0.16.15"
peer_asn = 65001
}
vpc_config = {
network_name = var.vpc.self_link
subnet_self_link = var.subnets.primary.self_link
}
}
Anschließend konfigurieren Sie die Router-Appliances. In unserem Beispiel wird dies durch die entsprechenden Modulaufrufe illustriert. Damit die Einrichtung gelingt, ist anschließend noch die Routerkonfiguration samt ASN-Parametern und IP-Adressen notwendig.
Fazit
Mit dem Network Connectivity Center vereinfacht Google die Verwaltung komplexer Netzwerkumgebungen erheblich – sei es bei der Anbindung lokaler Rechenzentren, beim Zugriff auf zentrale Services oder beim Aufbau sicherer, getrennter Cloudbereiche. Insbesondere in Kombination mit Private Service Connect und Terraform ergibt sich ein skalierbares, gut kontrollierbares Modell für moderne Multi- und Hybrid-Cloud-Architekturen.
(ln)
Link-Codes
[1] Google Network Connectivity Center: https://cloud.google.com/network-connectivity-center?hl=de