Google PCNE: Hybride Konnektivität, Cloud Router und BGP — Lernleitfaden
Teil des Google Professional Cloud Network Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
Überblick
Hybride Konnektivität in der Google Cloud ermöglicht private, kontrollierte Kommunikation zwischen VPC-Netzwerken und externen Netzwerken wie lokalen Rechenzentren oder anderen Clouds. Die Kernbausteine sind HA VPN- und Cloud VPN-Gateways, Cloud Router mit BGP für dynamisches Routing und Interconnect mit VLAN-Anhängen. Designs müssen Bandbreite, Latenz, Zuverlässigkeit, betriebliche Komplexität und Kosten abwägen und dabei deterministisches Routing-Verhalten und die Isolierung von Fehlerdomänen berücksichtigen. Dieser Abschnitt behandelt Design- und Betriebsaspekte, häufige Fehlermodi und die systematische Fehlerbehebung.
Hybride Konnektivität: HA VPN, Cloud Router und Interconnect
HA VPN und Cloud VPN
- HA VPN ist ein regionales, hochverfügbares IPsec-VPN, das IKEv2 unterstützt und Cloud Router für dynamisches Routing (eBGP) erfordert. Ein HA VPN-Gateway hat zwei Schnittstellen; für SLA und ECMP erstellen Sie zwei Tunnel pro Schnittstelle zu unterschiedlichen Peer-Endpunkten.
- Classic Cloud VPN unterstützt IKEv1 oder IKEv2 sowie statische oder routenbasierte Tunnel; es unterstützt nicht das HA VPN SLA. Verwenden Sie es nur, wenn Peers kein BGP unterstützen oder Sie richtlinienbasierte Selektoren verwenden müssen.
- Das Peer-Gateway ist das entfernte VPN-Gerät/die IP. Definieren Sie für HA VPN ein Peer-VPN-Gateway mit einer oder mehreren öffentlichen IPs, um separate Schnittstellen oder Geräte für Redundanz abzubilden.
- SLA-Design: Um für das HA VPN 99,99 % SLA berechtigt zu sein, stellen Sie redundante Tunnel über unabhängige On-Premises-Geräte oder -Schnittstellen bereit und verwenden Sie dynamisches Routing. Classic VPN wird nicht durch ein SLA unterstützt.
- Durchsatzskalierung: Ein einzelner IPsec-Tunnel hat einen begrenzten Durchsatz. Verwenden Sie ECMP über mehrere Tunnel, um den Gesamtdurchsatz zu erhöhen. Erreichen Sie dies, indem Sie zusätzliche Tunnel auf eindeutigen öffentlichen IPs des Peers terminieren.
Cloud Router und BGP
- Cloud Router ist ein regionaler Control-Plane-Dienst, der BGP-Sitzungen mit VPN-Tunneln oder Interconnect-VLAN-Anhängen aufbaut und Routen dynamisch austauscht.
- Der dynamische Routing-Modus (auf VPC-Ebene) steuert, wo gelernte dynamische Routen verwendet werden können und welche VPC-Subnetzrouten angekündigt werden:
- Regional: Dynamische Routen nur in derselben Region lernen und verwenden/importieren.
- Global: Dynamische Routen über alle Regionen hinweg lernen und verwenden/importieren; alle VPC-Subnetzrouten (global) an Peers ankündigen.
Dedicated Interconnect und Partner Interconnect
- Dedicated Interconnect bietet physische 10-Gbit/s- oder 100-Gbit/s-Leitungen direkt zu Google in einer Colocation-Einrichtung. Sie erhalten eine Letter of Authorization – Connecting Facility Assignment (LOA-CFA), um Cross-Connects zu ermöglichen. Erstellen Sie VLAN-Anhänge (Interconnect-Anhänge), die 802.1Q-Tags auf regionale L3-Konnektivität abbilden, die einem Cloud Router zugeordnet ist.
- Partner Interconnect bietet logische Konnektivität über einen Dienstanbieter. Sie fordern VLAN-Anhänge vom Partner an; die Bandbreite wird am Edge des Partners bereitgestellt. Ordnen Sie die Anhänge dennoch einem Cloud Router für BGP zu.
- Redundanz und SLA: Verwenden Sie zwei Anhänge in derselben Region, die in unterschiedlichen Edge-Verfügbarkeitsdomänen (und gegebenenfalls auf unterschiedlichen physischen Interconnects) platziert sind, um höhere SLAs (z. B. 99,99 %) zu erreichen. Ein einzelner Anhang oder Link reduziert das SLA. Bei Partner Interconnect hängt das Gesamt-SLA auch vom Partner ab.
Cross-Connects und VLAN-Anhänge
- Cross-Connects sind die physischen Glasfaserverbindungen zwischen Ihrem Cage/Ihrer Ausrüstung und dem Cage von Google in einem Meet-Me-Raum. Legen Sie Ihrem Anbieter die LOA-CFA vor, um diese fertigzustellen.
- VLAN-Anhänge sind die logische L2-Abgrenzung zu einer VPC-Region. Jeder Anhang:
- Ist über einen Cloud Router genau einem VPC und einer Region zugeordnet.
- Wird für Redundanz und ECMP paarweise konfiguriert.
- Überträgt nur L3-Verkehr; keine L2-Erweiterung.
Kurzes Beispiel:
- Cloud Router und BGP für einen Anhang oder HA VPN-Peer erstellen: gcloud compute routers create cr-us-east1 –region=us-east1 –network=my-vpc –asn=65010 gcloud compute routers add-bgp-peer cr-us-east1 –region=us-east1 –peer-name=onprem-peer1 –peer-asn=65020 –interface=if-1 –peer-ip-address=169.254.0.2 –advertise-mode=DEFAULT –enable-bfd
Routing und BGP-Verhalten
Dynamisches vs. statisches Routing
- Dynamisches Routing mit Cloud Router ermöglicht automatisches Routen-Lernen, Konvergenz und ECMP. Es skaliert und reduziert den Betriebsaufwand bei wachsenden Netzwerken.
- Statisches Routing eignet sich, wenn Peers kein BGP unterstützen oder für eng definierte, deterministische Pfade. In einer VPC haben statische Routen eine numerische Priorität; niedrigere Werte werden bei statischen Routen mit derselben Präfixlänge bevorzugt.
- Routenauswahl in einer VPC:
- Die längste Präfixübereinstimmung (Longest Prefix Match) gewinnt.
- Subnetz-Routen können nicht durch benutzerdefinierte Routen überschrieben werden.
- Bei gleicher Präfixlänge werden statische Routen nach der niedrigsten Priorität ausgewählt. Unter dynamischen Routen hat Cloud Router bereits die besten Pfade ermittelt, bevor er sie installiert. Die System-Standardroute hat die niedrigste Priorität.
BGP-Sitzungen, Advertisement und Import/Export
- Cloud Router exportiert standardmäßig VPC-Subnetze oder einen benutzerdefinierten Satz von Präfixen. Sie können bei Bedarf 0.0.0.0/0 oder aggregierte Präfixe ankündigen (advertisen), aber dies zieht On-Prem-Traffic in Richtung Cloud, wenn die Richtlinien dies zulassen; planen Sie dies bewusst.
- Cloud Router importiert alle zulässigen On-Premises-Präfixe und installiert sie als dynamische Routen gemäß dem dynamischen Routing-Modus der VPC.
- Die Priorität der pro Peer angekündigten Route (Advertised Route Priority) ermöglicht es Ihnen zu beeinflussen, wie On-Prem-Router einen Google-Pfad gegenüber einem anderen bevorzugen; ein niedrigerer Prioritätswert führt zu einem bevorzugteren MED gegenüber dem Peer.
ASNs, MED und Aktiv-Standby
- Verwenden Sie eine eindeutige private ASN pro administrativer Domäne, es sei denn, öffentliche ASNs sind erforderlich. Für mehrere On-Prem-Router, die für dieselben Präfixe ein Peering mit derselben VPC durchführen:
- Um ECMP oder einen konsistenten besten Pfad zu ermöglichen, verwenden Sie dieselbe Remote-ASN der On-Prem-Umgebung auf allen Routern, die dieselben Präfixe ankündigen. Unterschiedliche Remote-ASNs können die Installation von Routen mit gleichen Kosten (Equal-Cost) auf dem Cloud Router verhindern.
- Für Aktiv/Standby manipulieren Sie den MED (niedriger ist bevorzugter) von der On-Prem-Seite aus oder passen Sie die Priorität der pro Peer angekündigten Route des Cloud Routers an, sodass die On-Prem-Umgebung den primären Pfad bevorzugt. AS-Path Prepending ist ein alternatives, aber gröberes Werkzeug.
- Verwenden Sie eine eindeutige private ASN pro administrativer Domäne, es sei denn, öffentliche ASNs sind erforderlich. Für mehrere On-Prem-Router, die für dieselben Präfixe ein Peering mit derselben VPC durchführen:
Multipath-Design
- Cloud Router unterstützt ECMP über mehrere gleichwertige BGP-Pfade sowohl für HA VPN- als auch für Interconnect-Anhänge. Stellen Sie sicher, dass die Attribute (AS-Path-Länge, MED, local-pref) gleich sind und die Next Hops sich unterscheiden. Beenden Sie bei HA VPN die Tunnel auf unterschiedlichen Peer-IPs. Verwenden Sie bei Interconnect redundante Anhänge.
Resilienz, Erkennung und Egress-Dienste
BFD und Fehlererkennung
- BFD beschleunigt die Fehlererkennung für BGP-Sitzungen bei HA VPN und Interconnect. Aktivieren Sie BFD auf beiden Seiten mit kompatiblen Intervallen, um eine Erkennung im Sub-Sekunden- oder niedrigen Sekundenbereich zu erreichen, je nach Ihren Stabilitätsanforderungen. Kombinieren Sie dies mit IKE DPD bei IPsec-Tunneln. Stellen Sie sicher, dass Ihre Peer-Geräte den häufigeren Kontrollverkehr verarbeiten können.
- Vorsicht vor asymmetrischer Erkennung: Aggressives BFD in Verbindung mit überlasteten Verbindungen kann zu Sitzungs-Flapping führen; beginnen Sie mit konservativen Timern und überwachen Sie die Verbindung.
Redundante Topologie-Muster
- HA VPN: Verwenden Sie ein HA VPN-Gateway pro Region und beenden Sie die Tunnel auf zwei verschiedenen On-Prem-Geräten oder -Schnittstellen. Erstellen Sie mindestens vier Tunnel (zwei pro Schnittstelle) und einen Cloud Router pro Region. Halten Sie die Remote-ASNs konsistent, wenn Sie ECMP anbieten.
- Interconnect: Verwenden Sie mindestens zwei Anhänge in jeder Region über verschiedene Edge Availability Domains hinweg. Stellen Sie bei Dedicated Interconnect die Verbindungen nach Möglichkeit in unterschiedlichen Edge-Geräten und -Einrichtungen bereit.
Cloud NAT, externe Adressen und Egress für private Workloads
- Cloud NAT ist ein regionaler, verwalteter Egress-Dienst für Ressourcen ohne externe IPs. Es führt kein SNAT für Instanzen durch, die externe IPs haben; diese nutzen den Egress direkt. Wählen Sie Subnetze oder alle Subnetze in einer Region aus, um private Workloads abzudecken.
- Dimensionieren Sie die NAT-IP-Pools für gleichzeitige Verbindungen und ephemere Ports; wählen Sie eine manuelle oder automatische IP-Zuweisung. Aktivieren Sie das Logging für die Diagnose.
- Um Google APIs privat zu erreichen:
- Innerhalb der VPC: Aktivieren Sie Private Google Access für Subnetze, damit VMs ohne externe IPs die Google APIs über die virtuellen IPs von Google erreichen können.
- Von On-Prem: Verwenden Sie Private Service Connect-Endpunkte für Google APIs und hybrides DNS, damit On-Prem-Clients die APIs über private Hybrid-Verbindungen auflösen und erreichen können, ohne das Internet zu nutzen.
- Wenn eine Standardroute auf eine Firewall eines Drittanbieters verweist, Sie aber möchten, dass private Workloads diese für den Zugriff auf Google APIs umgehen, verwenden Sie entweder Private Service Connect oder installieren Sie statische Routen mit höherer Priorität für die veröffentlichten IP-Bereiche der Google APIs zum Standard-Internet-Gateway, kombiniert mit Private Google Access in den Subnetzen.
Integration von hybridem DNS
- Verwenden Sie private Zonen von Cloud DNS für die Namensauflösung innerhalb der VPC. Erweitern Sie dies auf die On-Prem-Umgebung mit:
- Inbound-Weiterleitung: On-Prem-Resolver leiten Anfragen für in der VPC gehostete private Zonen an Cloud DNS weiter.
- Outbound-Weiterleitung: VPC-Resolver leiten Anfragen für ausgewählte Domains an das On-Prem-DNS weiter.
- Peering-Zonen für die VPC-übergreifende Auflösung in Shared VPC- oder Multi-Projekt-Umgebungen.
- Für die private Erreichbarkeit von APIs erstellen Sie eine private Zone, die API-Hostnamen auf Private Service Connect-Endpunkte oder auf die entsprechenden privaten VIPs von Google bei Verwendung von Private Google Access abbildet. Stellen Sie sicher, dass diese Namen von der On-Prem-Umgebung aus über DNS-Weiterleitung aufgelöst werden können.
- Verwenden Sie private Zonen von Cloud DNS für die Namensauflösung innerhalb der VPC. Erweitern Sie dies auf die On-Prem-Umgebung mit:
← Firewall-Richtlinien · Alle Domänen · Load Balancing →
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →