Google Cloud Hybrid Networking-Muster - Teil 2

Einführung

Unternehmen werden nicht ihre gesamten lokalen Workloads auf einen Schlag in die Cloud migrieren. Es ist sinnvoller, Teile von Arbeitslasten auf einmal in die Cloud zu migrieren, wo immer die maximalen Vorteile der Migration in die Cloud genutzt werden können. Sie benötigen also immer noch eine Möglichkeit für Ihre lokalen Systeme, mit den neu bereitgestellten Cloud-Ressourcen zu kommunizieren.

Es gibt mehrere Netzwerkmuster, die für die Entwicklung hybrider Konnektivität in der Google Cloud genutzt werden können. Die Gestaltung der hybriden Konnektivität hängt unter anderem von folgenden Faktoren ab:

• Die Anzahl der VPC-Netzwerke, die für die Workloads verwendet werden
• Die Notwendigkeit einer Layer-7-Datenverkehrsprüfung unter Verwendung virtueller Netzwerkgeräte (NVAs)
• Zugriff auf von Google verwaltete Dienste, die Private Services Access verwenden

Dies wird eine mehrteilige Blogserie sein, in der ich verschiedene in der Google Cloud verfügbare Netzwerktopologien behandeln werde, die verschiedene Anwendungsfälle für hybride Konnektivität abdecken. In diesem ersten Blog geht es um die hybride Konnektivität zu einer einzelnen oder gemeinsam genutzten VPC auf Google Cloud. In den folgenden Blogs werde ich die hybride Konnektivität zu mehreren VPC-Netzwerken (oder gemeinsam genutzten VPC-Netzwerken) in der Google Cloud und die hybride Konnektivität mithilfe von Appliances behandeln.

Wenn Sie eine große Anzahl von Workload-VPC-Netzwerken haben, benötigen Sie möglicherweise eine Hub-and-Spoke-Architektur, die eine große Anzahl von VPC-Netzwerken unterstützt. Dabei werden mehrere Workload-VPC-Netzwerke mit einer Transit-Hub-VPC verbunden, die über Konnektivität zu lokalen Umgebungen und anderen Clouds verfügt. Ich werde Hub-and-Spoke mit VPC Peering zu Spokes, Hub-and-Spoke mit HA-VPN zu Spokes und hybride Konnektivität mit Appliances und VPC Peering zu Spokes behandeln.

 

Hybride Konnektivität zu einer einzelnen VPC (oder gemeinsamen VPC)

     1. Zusammenschaltung mit On-Premises

a) Cloud-Zusammenschaltung

Richten Sie eine Dedicated Interconnect oder Partner Interconnect zu Google Cloud ein. Verbindung zu zwei Edge Availability Domains (EAD) in derselben Metro, um ein SLA von 99,99 % zu erreichen. Sie können Ihre Cloud Interconnects mit mehreren Regionen innerhalb der gleichen Shared VPC verbinden.

2) VLAN-Zuordnung

Ein VLAN-Attachment verbindet Ihren Interconnect in einem Google Point of Presence (PoP) mit einem Cloud-Router in einer bestimmten Google Cloud-Region.

3) Cloud-Router

Ein Cloud-Router tauscht dynamische (BGP-)Routen zwischen Ihren VPC-Netzwerken und den Routern vor Ort 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 für jede der Schnittstellen des Cloud Routers.

4) Globales dynamisches VPC-Routing

Konfigurieren Sie globales dynamisches 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>

2 HA-VPN zu On-Premises

     1. Wolke HA-VPN

Das Cloud HA-VPN-Gateway wird zum Aufbau von IPsec-Tunneln zum lokalen VPN-Gateway über das Internet verwendet. HA-VPN bietet ein SLA von 99,99 %. Sie können mehrere HA-VPN-Tunnel in verschiedene Regionen innerhalb der Shared VPC haben.

2 Cloud-Router

Konfigurieren Sie das dynamische Routing zwischen den lokalen Routern und einem Cloud-Router in jeder Region. Jeder Cloud Router wird durch zwei Software-Tasks implementiert, die zwei Schnittstellen für hohe Verfügbarkeit bereitstellen. Konfigurieren Sie das BGP-Routing für jede der Schnittstellen des Cloud Routers.

3 % VPC globales dynamisches Routing

Konfigurieren Sie globales dynamisches 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>

3 % DNS

Übersicht

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) Lokales DNS

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) Prod shared VPC - DNS egress proxy

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) Prod-Host-Projekt - Cloud DNS

• Konfigurieren Sie eine Richtlinie für eingehende Server für eingehende DNS-Anfragen von lokalen Standorten.
• b. Richten Sie eine Cloud-DNS-Weiterleitungszone (für firmeninterne DNS-Namen) ein, die auf firmeninterne DNS-Auflöser ausgerichtet ist.

 

< 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>

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 Shared VPC.

Erstellen eines PSC-Endpunkts

     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. 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.

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

3 % 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.

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.

 

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.

5 Geben Sie auf dem Cloud-Router die PSC-Endpunktadresse an das lokale Netzwerk weiter.

6 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.

7 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>

Private 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 Shared VPC.

Erstellen eines PSC-Endpunkts

     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 "vpc-sc", das den Zugriff auf Google-APIs und -Dienste ermöglicht, die unter VPC Service Control unterstützt werden. 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 über den PSC-Endpunkt im gemeinsam genutzten VPC Prod auf die von der VPC Service Control unterstützten Google-APIs und -Dienste zugreifen.

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

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.

4 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 über den PSC-Endpunkt in der gemeinsam genutzten VPC von Prod auf alle sicheren Google-APIs und -Dienste zugreifen.

5 Geben Sie auf dem Cloud-Router die PSC-Endpunktadresse an das lokale Netzwerk weiter.

6 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.

7 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. Nachfolgend finden Sie eine Beschreibung der VPC Service Control-Aktionen für dieses Szenario.

     1. Perimeter - Dienstleistungsprojekt

Der Perimeter enthält ein Dienstprojekt (Dienstprojekt 4) und umfasst Google APIs und Dienste, die im Dienstprojekt geschützt werden sollen.

2 2) API-Zugang von GCE-Hosts

Eine GCE-Instanz kann über einen PSC-Endpunkt in der gemeinsamen VPC auf gesicherte APIs zugreifen. Unter Berücksichtigung des Perimeters um Serviceprojekt 4 befindet sich die Netzwerkschnittstelle der Recheninstanz GCE-4 in der gemeinsamen VPC Prod des Hostprojekts Prod. 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 %3) Ingress-Regel - Prod-Host-Projekt in Perimeter

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.

Hier ist eine detaillierte Konfiguration:

     1. Zugriff auf die Perimeter-Firewall-Richtlinie:

• Navigieren Sie zum Service Project 4 in der Google Cloud Console.
• Gehen Sie zu VPC-Netzwerk > Firewall-Richtlinien.
• Klicken Sie auf die Standard-Firewall-Richtlinie.

2 Erstellen Sie eine neue Ingress-Regel:

• Klicken Sie auf die Schaltfläche Regel hinzufügen.
• Setzen Sie die Aktion auf Zulassen.
• Wählen Sie TCP als Protokoll.
• Wählen Sie für die Quelle den IP-Bereich.
• Geben Sie den IP-Bereich Ihrer GCE-Instanzen in Host Project ein. Diese Informationen finden Sie in den Details der GCE-Instanz. Wenn der IP-Bereich zum Beispiel 10.0.0.0/8 lautet, geben Sie ihn hier ein.
• Wählen Sie für das Ziel IP-Bereich und geben Sie den IP-Bereich der geschützten Dienste in Service Project 4 ein. Dies kann der interne IP-Bereich Ihres VPC-Netzwerks oder bestimmte IP-Adressen der Dienste sein.
• Wählen Sie im Abschnitt Ziel die Option Alle.
• Wählen Sie für die Priorität einen geeigneten Wert (z. B. 1000).
• Klicken Sie auf Regel hinzufügen.

3 % Überprüfen Sie die Regel:

• Sobald die Regel erstellt ist, überprüfen Sie ihre Details, um sicherzustellen, dass sie richtig konfiguriert ist.
• Testen Sie die Regel, indem Sie einen API-Aufruf von einer GCE-Instanz im Host-Projekt zu einem geschützten Dienst im Service-Projekt 4 durchführen.
• Zusätzliche Überlegungen:
• Wenn Sie mehrere GCE-Instanzen haben oder Datenverkehr aus bestimmten Subnetzen zulassen möchten, passen Sie den Quell-IP-Bereich entsprechend an.
• Wenn Sie eine genauere Kontrolle wünschen, können Sie Quellkennzeichnungen oder Firewall-Regeln auf der Grundlage bestimmter Ports oder Protokolle verwenden.
• Wenn Sie Datenverkehr von anderen Projekten oder externen IP-Adressen zulassen müssen, ändern Sie die Quelle entsprechend.

4 Zugriff von lokalen Hosts aus

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. Das folgende Diagramm ist ein Beispiel.

< 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>

 

Wenn Unternehmen Workloads in die Cloud migrieren, müssen sie die verschiedenen hybriden Netzwerkmuster verstehen, um eine nahtlose Konnektivität zwischen lokalen und Cloud-Umgebungen sicherzustellen. In diesem Blog werden die wichtigsten Konfigurationen vorgestellt, mit denen Sie dieses Ziel erreichen können. In zukünftigen Beiträgen werden wir tiefer in fortgeschrittene Muster eintauchen, um Sie bei der Optimierung Ihrer Hybrid-Cloud-Strategie auf Google Cloud zu unterstützen. Bleiben Sie dran für die nächste Folge, in der wir uns mit Multi-VPC und Appliance-basierten Konnektivitätslösungen beschäftigen.