Google Cloud für Rechenzentrumsexperten: Netzwerk

In diesem Artikel werden die Netzwerkdienste von Google Cloud erläutert und mit klassischen Rechenzentrumstechnologien verglichen. Außerdem werden die Unterschiede zwischen den beiden Dienstmodellen untersucht und die VPC-Netzwerkfeatures der Cloud Platform im Detail beschrieben.

Dienstmodelle im Vergleich

In einem klassischen Rechenzentrum verwalten Sie eine komplexe Netzwerkeinrichtung, die aus Serverracks, Speichergeräten, mehreren Ebenen mit Switches, Routern, Load-Balancing-Modulen, Firewallgeräten und mehr besteht. Neben diesen Hardwarekomponenten müssen Sie die dem Netzwerk zugrunde liegende Software sowie detaillierte Gerätekonfigurationen für Ihre Umgebung einrichten, warten und überwachen. Der Verwaltungsaufwand hört an dieser Stelle nicht auf: Sie müssen sich auch um die Sicherheit und Verfügbarkeit Ihres Netzwerks kümmern. Und Sie müssen die Aktualisierungen und Erweiterungen Ihres Netzwerks planen – ein langer und zeitaufwändiger Vorgang.

Im Gegensatz dazu ist die VPC-Netzwerkinfrastruktur von Google Cloud auf einem SDN-Modell (Software-Defined Networking, softwarebasiertes Netzwerk) aufgebaut. Dieses Modell verkleinert den zuvor genannten Wartungs- und Verwaltungsaufwand beträchtlich. Sie können damit Dienste schneller anpassen und skalieren, um die Anforderungen Ihres wachsenden Kundenstamms zu erfüllen.

Grafik: Vergleich der VPC-Netzwerkarchitektur von Rechenzentren und Google Cloud
Abbildung 1: Vergleich der VPC-Netzwerkarchitektur von Rechenzentren und Google Cloud

Die VPC-Netzwerkdienste von Google Cloud wurden konzipiert für:

Obwohl Sie dank Google Cloud keine physischen Rechenzentrumskomponenten mehr verwalten müssen, bleiben viele bekannte Netzwerkkonzepte auch auf Google Cloud anwendbar. Hierzu gehören Subnetze, Routen, Firewallregeln, DNS, Load-Balancing, VPN, NAT und DHCP. Ihr vorhandenes Wissen in diesen Bereichen hilft Ihnen beim Einstieg in VPC-Netzwerke und beim optimalen Vorgehen in der Cloud-Umgebung.

VPC-Netzwerk

Ein VPC-Netzwerk umfasst die grundlegenden Netzwerktechnologien von Google Cloud, darunter Netzwerke, Subnetze, IP-Adressen, Routen, Firewalls, Cloud VPN und Cloud Router. Diese Grundlage ermöglicht Ihnen, Compute-Instanzen und Container zu erstellen, die sich ein einziges, globales VPC-Netzwerk teilen und regionalen Subnetzen hinzugefügt werden können. Mit Google Cloud haben Sie die Flexibilität, Dienste mit niedriger Latenz in Regionen und Zonen in der Nähe Ihrer Endnutzer anzubieten und Dienste über mehrere Domains zu verteilen, um bei Ausfällen Verfügbarkeit zu gewährleisten.

VPC-Netzwerke

In Google Cloud ist ein VPC-Netzwerk ein globaler, privater RFC 1918-IP-Bereich. Da die VPC-Netzwerke von Google Cloud standardmäßig global sind, müssen Sie nicht mehr mehrere private Netzwerke verbinden und separat verwalten, um eine globale Verfügbarkeit zu erreichen. Wenn Sie ein globales VPC-Netzwerk verwenden, können die Compute Engine-VM-Instanzen in Ihrem VPC-Netzwerk sowohl über die IP-Adresse als auch über den Namen angesprochen werden, da die VM-Instanznamen automatisch vom internen Compute Engine-DNS als Hostnamen nachverfolgt werden.

Subnetze

Subnetze im VPC-Netzwerk bieten Ihnen die Möglichkeit, Instanzen nach Region oder Zone zu gruppieren und die Segmentierung von IP-Adressbereichen zu steuern. Sie können Ihre eigenen Subnetze mithilfe eines beliebigen privaten RFC 1918-IP-Bereichs verwalten oder ein VPC-Netzwerk im automatischen Modus verwenden, das automatisch Subnetze in jeder Google Cloud-Region erstellt. IP-Bereiche zwischen Subnetzen müssen nicht fortlaufend sein und sind dynamisch erweiterbar.

Damit sich Subnetze besser voneinander abgrenzen lassen, können Sie Instanztags in individuelle VM-Instanzen oder Instanzvorlagen einfügen und dann beim Konfigurieren von Routen und Firewallregeln verwenden.

VPC-Netzwerke, Subnetze, Regionen und Zonen
Abbildung 2: VPC-Netzwerke, Subnetze, Regionen und Zonen

IP-Adressen

Instanzen unterstützen bis zu zwei IP-Adressen: eine sitzungsspezifische interne IP-Adresse für die Kommunikation innerhalb des VPC-Netzwerks und eine optionale externe IP-Adresse für die Kommunikation außerhalb des VPC-Netzwerks. Externe IP-Adressen sind standardmäßig sitzungsspezifisch, können aber auch statisch sein. Weitere Informationen zur Funktionsweise von IP-Adressen in Google Cloud finden Sie unter IP-Adressen.

Steuerung

Die robusten Steuerungsmechanismen von Google Cloud unterstützen Ihre organisationsweiten Netzwerk- und Sicherheitsadministratoren dabei, Ihre Ressourcen zu schützen, Ihre VPC-Netzwerke zu verwalten und den Zugriff auf Ihre externen Endpunkte zu autorisieren. In Google Cloud können Sie IAM-Rollen (Identity and Access Management), Firewalls und Routen für die Implementierung von Richtlinien und Mustern verwenden, um Ihre VPC-Netzwerke zu steuern und zu sichern.

Netzwerkspezifisches IAM

IAM bietet mehrere netzwerkbezogene Rollen, darunter Netzwerkadministrator, Netzwerkbetrachter, Sicherheitsadministrator und Compute-Instanzadministrator, um die Ressourcensteuerung klar zu trennen. Weitere Informationen zu IAM und zur Identitätsverwaltung in Google Cloud finden Sie im Artikel Verwaltung.

Firewalls

Ähnlich der DMZ in Ihrem Rechenzentrum hat jedes VPC-Netzwerk eine Firewall, die standardmäßig den gesamten eingehenden Traffic von außerhalb eines VPC-Netzwerks zu Instanzen blockiert. Sie können durch das Konfigurieren von Firewallregeln jedoch Zugriff gewähren. Anders als traditionelle DMZs sind die Firewalls von Google Cloud global verteilt, um Probleme mit der Skalierung bei wachsendem Traffic zu vermeiden.

Standardmäßig gelten Firewallregeln für das gesamte VPC-Netzwerk. Allerdings besteht die Möglichkeit, eine Firewallregel nur auf bestimmte Instanzen anzuwenden. Hierfür fügen Sie Instanzen ein bestimmtes Tag hinzu und wenden dann die Firewallregel auf Instanzen mit diesem Tag an. Sie können auch den internen Traffic zwischen Instanzen mit einer Firewallregel steuern. Zu diesem Zweck legen Sie einfach eine Reihe von zulässigen Quellmaschinen in der Regel fest.

Routen

Routen oder Regeln für die Weiterleitung von Traffic sind globale Ressourcen, die an ein einzelnes VPC-Netzwerk gebunden sind. Sie können Routen auf eine oder mehrere Instanzen in einem VPC-Netzwerk anwenden. Dafür weisen Sie Zielinstanztags zu, wenn Sie die Routen erstellen. Die Routen werden dann allen Instanzen hinzugefügt, die ebenfalls diese Instanztags verwenden.

Wenn Sie Compute Engine initialisieren oder ein neues VPC-Netzwerk erstellen, werden bestimmte Routen standardmäßig automatisch erstellt. Bei Bedarf können Sie einem VPC-Netzwerk auch Routen hinzufügen, die von Nutzern erstellt wurden. Sie können beispielsweise eine Route einfügen, die Traffic von einer Instanz zu einer anderen innerhalb desselben VPC-Netzwerks – sogar über Subnetze hinweg – weiterleitet, ohne eine externe IP-Adresse zu benötigen.

Wenn Sie Subnetze in einem VPC-Netzwerk einrichten, erstellt die GCP standardmäßig Routen zwischen den Subnetzen. Wenn Sie jedoch das VPC-Netzwerk default nicht verwenden, müssen Sie Firewallregeln erstellen, um Traffic zwischen Instanzen in Ihrem VPC-Netzwerk zuzulassen.

Mit Routen können Sie erweiterte Netzwerkfunktionen für VM-Instanzen implementieren, z. B. zum Einrichten einer NAT mit n:1-Regel oder transparenten Proxyservern. Die standardmäßigen Routen sind so konzipiert, dass das VPC-Netzwerk weiß, wie Traffic ins Internet und zu allen Ihren Instanzen zu senden ist.

Skalierung

In klassischen Rechenzentrumsumgebungen können Load-Balancer zur operativen Komplexität beitragen. Außerdem mangelt es ihnen oft an globaler Skalierbarkeit. Sie können mit Cloud Load Balancing die Skalierbarkeit und Verfügbarkeit Ihrer Dienste unterstützen. Damit verteilen Sie Ihre Computing-Ressourcen auf eine einzige globale Anycast-IP. Cloud Load Balancing unterstützt HTTP(S), TCP/SSL und UDP-Load-Balancing sowie SSL-Verschiebung, Sitzungsaffinität, Systemdiagnosen und Protokollierung.

Layer-7-Load-Balancing

Beim HTTP(S)-Load-Balancing (Layer 7) wird der Traffic automatisch über Regionen hinweg verteilt und zu nahe gelegenen Instanzen weitergeleitet bzw. von fehlerhaften Instanzen weggeleitet. Sie können auch ein inhaltsbasiertes Load-Balancing einrichten, um Traffic auf Instanzen zu verteilen, die für bestimmte Inhalte wie Videos optimiert sind. Außerdem haben Sie die Möglichkeit, Cloud CDN, den Content Delivery Network-Dienst von Google Cloud, mit dem HTTP(S)-Load-Balancing zu kombinieren und damit Ihren Nutzern eine geringere Latenz und bessere Leistung zu bieten.

Regionenübergreifendes Load-Balancing
Abbildung 3: Regionenübergreifendes Load-Balancing

Layer-4-Load-Balancing

Netzwerk-Load-Balancing (Layer 4) steht ebenfalls zur Verfügung, wenn TCP/UDP-Dienste zusätzliche Instanzen bei Trafficspitzen benötigen. Mit dem Netzwerk-Load-Balancing können Sie für weitere Protokolle (z. B. SMTP-Traffic) Lasten ausgleichen, Sitzungsaffinität hinzufügen und Pakete untersuchen. Der SSL-Proxy stellt SSL-Beendigung für Nicht-HTTPS-Traffic mit Load-Balancing bereit, während SSL-Offloading die zentrale Verwaltung von SSL-Zertifikaten und -Entschlüsselung ermöglicht, sodass diese prozessorintensive Arbeit nicht von Ihren Instanzen bewältigt werden muss.

Netzwerk-Load-Balancing
Abbildung 4: Netzwerk-Load-Balancing

Autoscaling

Das Load-Balancing wird vom Autoscaling in Compute Engine unterstützt, das gemäß einer Autoscaling-Richtlinie automatisch Instanzen in eine Instanzgruppe aufnimmt bzw. aus ihr entfernt. Sie können eine der vordefinierten Richtlinien des Autoscalings auswählen oder eine eigene Richtlinie auf Grundlage von Cloud Monitoring-Messwerten festlegen.

Cloud DNS

Sie können Cloud DNS verwenden, um Ihre Anwendungen und Dienste global mit hoher Verfügbarkeit und niedriger Latenz für Ihre Nutzer verfügbar zu machen. Cloud DNS skaliert auf große Zahlen von DNS-Zonen und -Datensätzen, sodass Sie zuverlässig Millionen von DNS-Datensätzen erstellen und aktualisieren können.

Verbindung

Wenn Sie eine Hybridarchitektur entwerfen, in der Sie einige Ressourcen in Google Cloud und andere Ressourcen an einer anderen Stelle nutzen, gibt es eine Vielzahl von Möglichkeiten, Google Cloud in die externe Umgebung einzubinden.

Cloud VPN

Der verwaltete Cloud VPN-Dienst ermöglicht es, Daten von einer privaten Cloud durch sichere IPSec-Tunnel an Ihre mit Google Cloud gehosteten Dienste zu leiten. Jedes Cloud VPN-Gateway kann dauerhaft Übertragungsraten von bis zu 1,5 GB/s im Tunnel gewährleisten. Eine Anleitung zur Konfiguration von Cloud VPN befindet sich in den Cloud VPN-Interoperabilitätsleitfäden.

Google Cloud Router

Wenn Sie Ihre Cloud-Subnetze erweitern, zusätzliche Cloud-Anwendungen erstellen oder Änderungen an Ihren privaten Cloud-Subnetzen vornehmen, können Sie Ihre Netzwerkänderungen mit Cloud Router automatisch ermitteln und bekanntgeben. Cloud Router unterstützt mehrere VPN-Tunnel entweder durch ECMP-Routing oder ein Primary-/Backup-Setup. Cloud Router-, BGP- und Routenereignisse werden in Cloud Logging angezeigt und Cloud Router gibt Messwerte an Cloud Monitoring aus.

Hybridnetzwerkarchitektur
Abbildung 5: Hybride Netzwerkarchitektur

Cloud Interconnect

Für Kunden, die eine Verbindung auf professionellem Niveau mit hoher Verfügbarkeit und niedriger Latenz benötigen, bietet Cloud Platform Cloud Interconnect. Der Traffic Ihres Netzwerks geht direkt zu Google Cloud und vermeidet unnötige Wege durch Netzwerke von Dritten. Cloud Interconnect stellt die folgenden Dienste zur Verfügung:

  • Carrier Peering-Dienste, welche durch eine Gruppe von Partnerdienstanbietern zur Verfügung gestellt werden.
  • Direct Peering-Dienste: Sie können mit Google an jeder der über 70 Peering-Positionen peeren, um einen hohen Durchsatz an Cloud-Traffic auszutauschen, wenn Sie Google an den Peering-Positionen erreichen und die Peering-Voraussetzungen von Google erfüllen.
  • CDN Interconnect erlaubt es ausgewählten Anbietern, direkte Interconnect-Verbindungen mit dem Edge-Netzwerk von Google aufzubauen. Durch diese Edge-Verbindung können Sie den Traffic optimieren, wodurch Sie große Dateien in der Nähe Ihrer Nutzer zwischenspeichern und die Latenz für häufig aktualisierte Inhalte verringern können.

Leistung

Der ausgehende Traffic von einer bestimmten VM-Instanz unterliegt einem Höchstdurchsatz für ausgehenden Traffic im Netzwerk. Diese Begrenzungen hängen von der Anzahl der vCPUs der VM-Instanz ab. Jede vCPU unterliegt einer Höchstgrenze von 2 Gbit/s. Jede zusätzliche vCPU erhöht die Netzwerkobergrenze um bis zu 32 Gbit/s pro Instanz. Die tatsächliche Leistung variiert abhängig von der Arbeitslast. Alle Grenzen sind als maximal mögliche Leistung zu verstehen, nicht als dauerhafte Leistung.

Sie können PerfKit Benchmarker, ein Open-Source-Tool zum Leistungsvergleich, verwenden, um die Leistung von Google Cloud und anderen Cloud-Diensten im Vergleich zu der Leistung einer herkömmlichen Rechenzentrumsumgebung zu messen. Zum Benchmarking von Google Cloud können Sie den benannten google_set-Satz ausführen, der die Benchmarks iperf, netperf und ping enthält. Ein einfaches Beispiel, in dem PerfKit Benchmarker genutzt wird, um den Netzwerkdurchsatz zu messen, finden Sie unter Netzwerkdurchsatz messen.

Kosten

Genaue Preisangaben für die einzelnen Produkte finden Sie auf den folgenden Seiten:

Sie können auch den Google Cloud-Preisrechner verwenden, um Kosten für bestimmte Szenarien zu modellieren.

Weitere Informationen

Als Nächstes: Computing in Google Cloud

Best Practices prüfen

Tipps zur Sicherheit Ihres VPC-Netzwerks und der virtuellen Ressourcen finden Sie unter Netzwerk und Sicherheit und im Artikel zu Best Practices bei DDoS-Attacken.

Praxisorientierte Anleitungen ausprobieren

Sind Sie bereit dazu, anzupacken? In den Codelabs Networking 101 und Networking 102 finden Sie einfache und mittelschwere Netzwerkaufgaben, die Sie mit den VPC-Netzwerkdiensten von Google Cloud lösen können.

Über Googles Netzwerk-Stack lesen

Seit über 10 Jahren investiert Google stark in softwaredefinierte Netzwerke in der Cloud für optimale Leistung bei niedrigen Kosten. Die folgenden Artikel und Forschungsarbeiten bieten einen Einblick in die verschiedenen Aspekte von Googles Netzwerk-Stack: