Google Cloud Hybrid Networking-Muster - Teil 2

Einführung

In den ersten beiden Beiträgen dieser Serie haben wir die grundlegenden Netzwerkmuster für hybride Konnektivität zwischen lokalen Systemen und der Google Cloud untersucht. Teil 1 konzentrierte sich auf die Verbindung zu einer einzelnen oder gemeinsam genutzten VPC, während Teil 2 die hybride Konnektivität über mehrere VPC-Netzwerke hinweg behandelte. In dieser letzten Folge werden wir uns mit fortgeschritteneren Mustern befassen, insbesondere mit hybrider Konnektivität unter Verwendung von Appliances in Shared VPC-Netzwerken innerhalb einer Hub-Architektur auf Google Cloud.

Hybride Konnektivität mit Appliances (gemeinsam genutzte VPC-Netzwerke im Hub)

     1. Zusammenschaltung mit On-Premises

Stellen Sie sich einen Anwendungsfall vor, in dem Workloads in getrennten Shared VPC-Netzwerken für die Produktion (Prod) und die Nicht-Produktion (Non-Prod) organisiert sind. Der Interconnect (oder HA-VPN) von vor Ort (oder anderen Clouds) endet direkt in der externen VPC.

Dieses Muster bietet hybride Konnektivität zu:

1. IaaS-Ressourcen innerhalb der Arbeitslast Geteilte VPC-Netzwerke
2. Google-APIs und -Dienste (z. B. storage.googleapis.com, *.run.app) in den Workload-Projekten
3. Google Cloud Managed Services mit Private Services Access

Verwenden Sie dieses Muster, wenn:

1. Sie verfügen über mehrere Workload Shared VPC-Netzwerke, die eine Layer 7-Inspektion für den Datenverkehr zwischen VPC-Netzwerken und lokalen Standorten erfordern. Dieses Beispiel zeigt zwei Shared VPC-Netzwerke (Prod und Non-Prod), Sie können jedoch bis zu sieben VPC-Netzwerke unterstützen. Die Workload-VPC-Netzwerke kommunizieren über Network Virtual Appliances (NVA), die Netzwerksicherheitsrichtlinien anwenden, um Datenverkehr zuzulassen oder zu verweigern.
2. Sie haben mehrere Workload Shared VPC-Netzwerke, die eine gemeinsame Verbindung zu lokalen oder anderen Clouds nutzen müssen. In diesem Beispiel wird die Konnektivität zu lokalen und anderen Clouds über die NVA und die externe VPC geroutet.
3. Sie benötigen Netzwerkkonnektivität zu verwalteten Services, die Private Services Access innerhalb der Workload Shared VPC-Netzwerke verwenden. Dieses Muster ermöglicht den Zugang zu verwalteten Diensten vor Ort und zu jeder Workload Shared VPC.

Skalierung (Anzahl der gemeinsam genutzten VPCs für Workloads)

Die maximale Anzahl von Workload Shared VPC-Netzwerken beträgt sieben, begrenzt durch die maximale Anzahl von Netzwerkschnittstellen pro Instanz. Wenn eine zusätzliche Schnittstelle für den Verwaltungsverkehr zur NVA erforderlich ist, können nur sechs Workload Shared VPC-Netzwerke bereitgestellt werden.

1. Cloud-Zusammenschaltung Richten Sie eine dedizierte Zusammenschaltung oder eine Partner-Zusammenschaltung mit Google Cloud ein. Verbinden Sie sich mit zwei Edge Availability Domains (EAD) innerhalb desselben Metrobereichs, um ein SLA von 99,99 % zu erreichen. Ihre Cloud Interconnects können sich mit mehreren Regionen in derselben Shared VPC verbinden.
2. VLAN-Anbindung Eine VLAN-Anbindung verbindet Ihren Interconnect in einem Google Point of Presence (PoP) mit einem Cloud-Router in einer bestimmten Region.
3. Cloud Router Ein Cloud Router tauscht dynamische Routen zwischen Ihren VPC-Netzwerken und lokalen Routern aus. Sie können dynamisches Routing zwischen Ihren lokalen Routern und einem Cloud Router in einer bestimmten Region konfigurieren. Jeder Cloud Router wird durch zwei Software-Tasks implementiert, die zwei Schnittstellen für hohe Verfügbarkeit bereitstellen. Konfigurieren Sie das BGP-Routing zu jeder Cloud Router-Schnittstelle.
4. VPC Global Dynamic Routing Konfigurieren Sie das globale dynamische Routing im Shared VPC, um den Austausch von dynamischen Routen zwischen allen Regionen zu ermöglichen.

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

     1. Cloud   HA-VPN Das Cloud HA-VPN-Gateway baut IPsec-Tunnel zum lokalen VPN-Gateway über das Internet auf. HA-VPN bietet ein SLA von 99,99 %. Sie können mehrere HA-VPN-Tunnel in verschiedene Regionen in der externen VPC konfigurieren.

2Cloud   Router Konfigurieren Sie das dynamische Routing zwischen den lokalen Routern und einem Cloud Router in jeder Region. Jeder Cloud Router bietet zwei Schnittstellen für hohe Verfügbarkeit. Konfigurieren Sie BGP-Routing für beide Cloud Router-Schnittstellen.

3 %VPC   Global Dynamic Routing Konfigurieren Sie das globale dynamische Routing im externen VPC, um den Austausch von dynamischen Routen zwischen allen Regionen zu ermöglichen.

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

3 % Hybrid DNS Option 1 (Cloud DNS Weiterleitung und Peering)

In einer hybriden Umgebung kann die DNS-Auflösung entweder in der Google Cloud oder vor Ort erfolgen. Betrachten wir einen hybriden DNS-Anwendungsfall, bei dem lokale DNS-Server für lokale DNS-Zonen maßgeblich sind und Cloud DNS für Google Cloud-Zonen maßgeblich ist.

1. Konfigurieren Sie Ihre lokalen DNS-Server so, dass sie für lokale DNS-Zonen autorisierend sind. Richten Sie eine DNS-Weiterleitung (für Google Cloud DNS-Namen) ein, die auf die IP-Adresse der Cloud DNS-Eingangsweiterleitung abzielt, die über die Richtlinie für eingehende Server in der gemeinsam genutzten VPC Prod erstellt wird. Dies ermöglicht dem lokalen Netzwerk, Google Cloud DNS-Namen aufzulösen.
2. Machen Sie den Google DNS-Egress-Proxy-Bereich 35.199.192.0/19 über die Cloud-Router für das lokale Netzwerk bekannt. Ausgehende DNS-Anfragen von der Google Cloud an lokale Standorte werden von diesem IP-Adressbereich abgeleitet.
3. Externe VPC - Cloud DNS
a) Konfigurieren Sie eine Richtlinie für eingehende Server für DNS-Anfragen von vor Ort. b) Richten Sie eine Cloud DNS-Weiterleitungszone für vor Ort befindliche DNS-Namen ein, die auf vor Ort befindliche DNS-Auflöser abzielt.
4. Konfigurieren Sie eine DNS-Peering-Zone für firmeninterne DNS-Namen, die auf die gemeinsame VPC von Prod als Peer-Netzwerk abzielt. Diese Konfiguration ermöglicht es Nicht-Prod-Ressourcen, lokale DNS-Namen aufzulösen. b) Richten Sie private Nicht-Prod-DNS-Zonen im Hub-Host-Projekt ein und fügen Sie Nicht-Prod Shared VPC, Prod Shared VPC und External VPC der Zone zu. Dadurch können Hosts (vor Ort und alle Dienstprojekte) die Prod-DNS-Namen auflösen.
5. Konfigurieren Sie eine DNS-Peering-Zone für firmeninterne DNS-Namen, die auf die gemeinsame VPC von Prod als Peer-Netzwerk abzielt. Dadurch können Prod-Ressourcen lokale DNS-Namen auflösen. b) Richten Sie private Prod-DNS-Zonen im Hub-Host-Projekt ein und fügen Sie Prod Shared VPC, Non-Prod Shared VPC und External VPC zu der Zone hinzu. Dadurch können Hosts (vor Ort und alle Dienstprojekte) die Prod-DNS-Namen auflösen.

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

3 4. Private Service Connect (PSC) für Google APIs (Zugriff auf alle unterstützten APIs und Dienste)

Übersicht

Sie können Private Service Connect (PSC) verwenden, um von Google Compute Engine (GCE)-Hosts und lokalen Hosts über die interne IP-Adresse eines PSC-Endpunkts in einer gemeinsam genutzten VPC auf alle unterstützten Google-APIs und -Dienste zuzugreifen. Betrachten wir den PSC-Zugriff auf einen Dienst in Service Project 4 über die External VPC und Prod Shared VPC.

PSC-Endpunkte erstellen

1. Wählen Sie eine PSC-Endpunktadresse (z. B. 10.2.2.2) und erstellen Sie einen PSC-Endpunkt in der gemeinsam genutzten VPC Prod mit dem Ziel "all-apis", das den Zugriff auf alle unterstützten Google-APIs und -Dienste ermöglicht.
2. Wählen Sie eine PSC-Endpunktadresse (z. B. 10.2.2.2) und erstellen Sie einen PSC-Endpunkt in der gemeinsam genutzten VPC Prod mit dem Ziel "all-apis", das den Zugriff auf alle unterstützten Google-APIs und -Dienste ermöglicht. Service Directory erstellt automatisch einen DNS-Eintrag (mit dem DNS-Namen p.googleapis.com), der mit der IP-Adresse des PSC-Endpunkts verknüpft ist.

2) API-Zugang von GCE-Hosts

GCE-Hosts können auf alle unterstützten Google-APIs und -Dienste über den PSC-Endpunkt in der gemeinsam genutzten VPC Prod zugreifen.

1. 2. Aktivieren Sie Private Google Access auf allen Subnetzen mit Recheninstanzen, die Zugriff auf Google APIs über PSC benötigen.
2. 3. Wenn Ihre GCE-Clients benutzerdefinierte DNS-Namen verwenden können (z. B. storage-xyz.p.googleapis.com), können Sie den automatisch erstellten DNS-Namen p.googleapis.com verwenden.
3. 4. Wenn Ihre GCE-Clients keine benutzerdefinierten DNS-Namen verwenden können, können Sie Cloud-DNS-Einträge unter Verwendung der Standard-DNS-Namen erstellen (z. B. storage.googleapis.com).

Zugriff von lokalen Hosts aus

Lokale Hosts können auf alle unterstützten Google-APIs und -Dienste über den PSC-Endpunkt in der gemeinsam genutzten VPC Prodzugreifen.

• Geben Sie auf dem Cloud-Router die PSC-Endpunktadresse an das lokale Netzwerk weiter.
• 5. Wenn Ihre lokalen Clients benutzerdefinierte DNS-Namen verwenden können (z. B. storage-xyz.p.googleapis.com), können Sie A-Einträge erstellen, die die benutzerdefinierten DNS-Namen der PSC-Endpunktadresse zuordnen.
• 6. Wenn Ihre lokalen Clients keine benutzerdefinierten DNS-Namen verwenden können, können Sie A-Einträge erstellen, die die Standard-DNS-Namen (z. B. storage.googleapis.com) der PSC-Endpunktadresse zuordnen.

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

5Private Service Connect (PSC) für Google APIs (Zugriff auf APIs und Dienste, die unter VPC Service Control unterstützt werden)

Übersicht

Sie können Private Service Connect (PSC) verwenden, um von Google Compute Engine (GCE)-Hosts und lokalen Hosts über die interne IP-Adresse eines PSC-Endpunkts in einer gemeinsam genutzten VPC auf alle unterstützten Google-APIs und -Dienste zuzugreifen. Betrachten wir den PSC-Zugriff auf einen Dienst in Service Project 4 über die External VPC und Prod Shared VPC.

PSC-Endpunkte erstellen

1. Wählen Sie eine PSC-Endpunktadresse (z. B. 10.2.2.2) und erstellen Sie einen PSC-Endpunkt in der gemeinsam genutzten VPC Prod mit dem Ziel "all-apis", das den Zugriff auf alle unterstützten Google-APIs und -Dienste ermöglicht.
2. Wählen Sie eine PSC-Endpunktadresse (z. B. 10.2.2.2) und erstellen Sie einen PSC-Endpunkt in der Prod Shared VPC mit dem Ziel "vpc-sc" Service Directory erstellt automatisch einen DNS-Eintrag (mit dem DNS-Namen p.googleapis.com), der mit der IP-Adresse des PSC-Endpunkts verknüpft ist.

2) API-Zugang von GCE-Hosts

GCE-Hosts können auf alle unterstützten Google-APIs und -Dienste über den PSC-Endpunkt in der gemeinsam genutzten VPC Prod zugreifen.

     1. 2. Aktivieren Sie Private Google Access auf allen Subnetzen mit Recheninstanzen, die Zugriff auf Google APIs über PSC benötigen.

23. Wenn Ihre GCE-Clients benutzerdefinierte DNS-Namen verwenden können (z. B. storage-xyz.p.googleapis.com), können Sie den automatisch erstellten DNS-Namen p.googleapis.com verwenden.

3 %4. Wenn Ihre GCE-Clients keine benutzerdefinierten DNS-Namen verwenden können, können Sie Cloud-DNS-Einträge unter Verwendung der Standard-DNS-Namen erstellen (z. B. storage.googleapis.com).

Zugriff von lokalen Hosts aus

1. Lokale Hosts können auf alle unterstützten Google-APIs und -Dienste über den PSC-Endpunkt in der gemeinsam genutzten VPC Prodzugreifen.
2. Geben Sie auf dem Cloud-Router die PSC-Endpunktadresse an das lokale Netzwerk weiter.
3. 5. Wenn Ihre lokalen Clients benutzerdefinierte DNS-Namen verwenden können (z. B. storage-xyz.p.googleapis.com), können Sie A-Einträge erstellen, die die benutzerdefinierten DNS-Namen der PSC-Endpunktadresse zuordnen.
4. 6. Wenn Ihre lokalen Clients keine benutzerdefinierten DNS-Namen verwenden können, können Sie A-Einträge erstellen, die die Standard-DNS-Namen (z. B. storage.googleapis.com) der PSC-Endpunktadresse zuordnen.

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

6 VPC-Dienst-Steuerung

Übersicht

VPC Service Control verwendet Eingangs- und Ausgangsregeln, um den Zugang zu und von einem Perimeter zu kontrollieren. Die Regeln legen die Richtung des erlaubten Zugangs zu und von verschiedenen Identitäten und Ressourcen fest. 

Betrachten wir einen speziellen Anwendungsfall, bei dem der Zugriff auf einen geschützten Dienst in Service Project 4 über die gemeinsame VPC Prod erforderlich ist. Dies ist ein einfaches Beispiel und nicht erschöpfend.

VPC-Dienst-Steuerung

1. Service Project Perimeter Der Perimeter enthält Service Project 4 und umfasst Google APIs und Services, die im Service Project geschützt werden sollen.
2. Eine GCE-Instanz kann über einen PSC-Endpunkt in der gemeinsamen VPC auf gesicherte APIs zugreifen. Die Netzwerkschnittstelle der GCE-4-Instanz befindet sich in der Prod Shared VPC des Hub Host Project. API-Aufrufe von der GCE-4-Instanz zu einem Dienst (z. B. storage.googleapis.com) in Service Project 4 scheinen vom Prod-Host-Projekt zu stammen, wo sich die Instanzschnittstelle und der PSC-Endpunkt befinden.
3. Konfigurieren Sie eine Ingress-Regel, die Google API-Aufrufe vom Prod-Host-Projekt zu den geschützten Diensten innerhalb des Service Project 4-Perimeters erlaubt. Diese Regel erlaubt API-Aufrufe von den GCE-Instanzen (z. B. GCE-4) in den Perimeter.
4. 4) API-Zugriff für lokale Hosts Lokale Hosts können über den PSC-Endpunkt in der gemeinsam genutzten VPC Prod auf gesicherte APIs in Service Project 4 zugreifen. API-Aufrufe von vor Ort zu Diensten in Service Project 4 scheinen ihren Ursprung im Prod-Host-Projekt zu haben, wo sich der Interconnect (oder VPN) und der PSC-Endpunkt befinden. Die (in Schritt 3 erwähnte) Ingress-Regel erlaubt API-Aufrufe von On-Premises zum Perimeter des Service Project 4 über das Prod-Host-Projekt.

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Das volle Potenzial der Hybrid Cloud ausschöpfen

Hybride Konnektivität ist der Schlüssel zu mehr Flexibilität und Innovation in der Cloud. In dieser Serie haben wir eine Reihe von Netzwerkmustern untersucht, die Ihnen dabei helfen, lokale Systeme nahtlos mit Google Cloud zu verbinden, von grundlegenden VPC-Setups bis hin zu fortschrittlichen Appliance-basierten Architekturen. Wenn Sie die richtigen Muster für Ihre Arbeitslasten wählen, können Sie einen sicheren, effizienten und skalierbaren Cloud-Betrieb erreichen. Wir hoffen, dass diese Serie Ihnen die nötige Klarheit und Anleitung gegeben hat, um Ihre hybriden Netzwerklösungen sicher zu gestalten. Wenn Sie Fragen haben oder maßgeschneiderte Unterstützung benötigen, hilft Ihnen unser Team bei Rackspace Technology, das volle Potenzial Ihrer Cloud-Infrastruktur auszuschöpfen.