Dieser Strategieleitfaden enthält technische Anleitungen und Best Practices für das Entwerfen und Bereitstellen von hochverfügbaren (HA) Arbeitslasten in einem Multi-Zone-Universum von Google Distributed Cloud (GDC) mit Air Gap, das mit mehreren Zonen konfiguriert ist. In diesem Leitfaden werden wichtige Architekturmuster, Dienstkonfigurationen und betriebliche Überlegungen beschrieben, die erforderlich sind, um Ausfallzeiten zu minimieren und die Geschäftskontinuität für Anwendungen zu gewährleisten, die auf GDC ausgeführt werden.
Strategien für Hochverfügbarkeit sind für technische Fachkräfte gedacht, die an der Entwicklung, Bereitstellung und Verwaltung von Anwendungen auf GDC beteiligt sind, darunter:
Cloud-Architekten in der Gruppe der Plattformadministratoren: Entwerfen von resilienten Infrastruktur- und Anwendungsarchitekturen auf GDC.
DevOps-Entwickler und Site Reliability Engineers (SREs) in der Gruppe der Anwendungsoperatoren: Bereitstellungsstrategien, Automatisierung, Monitoring und Reaktion auf Vorfälle für HA-Arbeitslasten implementieren.
Anwendungsentwickler in der Gruppe der Anwendungsoperatoren: Entwicklung von Anwendungen, die fehlertolerant sind und sich nahtlos in HA-Infrastrukturmuster einfügen.
Weitere Informationen finden Sie unter Zielgruppen für die GDC-Dokumentation für Air-Gap-Umgebungen.
Bedeutung der Hochverfügbarkeit
In modernen verteilten Systemen ist die Planung für Hochverfügbarkeit von entscheidender Bedeutung. Ausfallzeiten, ob geplant oder ungeplant, können zu erheblichen Betriebsunterbrechungen, Umsatzeinbußen, Reputationsschäden und einer schlechten Nutzererfahrung führen. Bei Arbeitslasten, die am Edge oder in privaten Rechenzentren mit GDC ausgeführt werden, hängt die Verfügbarkeit oft direkt mit dem operativen Erfolg zusammen, insbesondere bei latenzsensiblen oder unternehmenskritischen Anwendungen. Es ist wichtig, von Anfang an auf Hochverfügbarkeit zu achten, um robuste und zuverlässige Dienste zu entwickeln.
Hyperscale-Funktionen, lokal bereitgestellt
GDC erweitert die Google Cloud Infrastruktur und ‑Dienste auf das Edge-Netzwerk und Ihre Rechenzentren. GDC bietet eine vollständig verwaltete Hardware- und Softwarelösung, mit der Sie Google Kubernetes Engine (GKE) in GDC-Clustern und anderenGoogle Cloud -Diensten näher am Ort der Datenerstellung und -nutzung ausführen können.
In diesem Leitfaden geht es speziell um GDC-Universen, die in einer Topologie mit mehreren Zonen konfiguriert sind. Bei der Multi-Zone-Konfiguration umfasst ein einzelnes GDC-Universum mehrere physisch isolierte Zonen am selben Standort, z. B. auf einem Rechenzentrumscampus oder in einer Metropolregion. Diese Zonen haben eine unabhängige Stromversorgung, Kühlung und ein unabhängiges Netzwerk, was Schutz vor lokalen Ausfällen der physischen Infrastruktur bietet. Die Netzwerkverbindung mit niedriger Latenz und hoher Bandbreite zwischen Zonen in einem GDC-Universum ermöglicht synchrone Replikation und schnelles Failover und bildet so die Grundlage für die Entwicklung hochverfügbarer Anwendungen.
Skalierbarkeit und Load-Balancing
Neben der grundlegenden Komponentenredundanz sind die effektive Verwaltung des Traffics und die nahtlose Skalierung entscheidend für die Aufrechterhaltung einer hohen Verfügbarkeit, insbesondere bei unterschiedlichen Lastbedingungen. GDC bietet verschiedene Mechanismen für Load-Balancing und anspruchsvolle Trafficverwaltung.
Externer Load-Balancer für Nord-Süd-Traffic
Wenn Sie Ihre Anwendungen für Nutzer oder Systeme außerhalb eines GKE on GDC-Clusters (North-South-Traffic) bereitstellen möchten, verwenden Sie die verwalteten externen Load-Balancing-Funktionen von GDC. Der ELB-Dienst (External Load Balancer) bietet diese Funktionen und lässt sich nahtlos in Kubernetes einbinden.
Die wichtigsten Merkmale des ELB-Dienstes, der für hohe Verfügbarkeit und Skalierbarkeit sorgt, sind die folgenden:
Verwalteter Dienst: ELB wird von GDC verwaltet und ist auf hohe Verfügbarkeit und Stabilität ausgelegt.
Externer Zugriff: Stellt stabile externe IP-Adressen aus von GDC verwalteten Pools bereit und bietet so einen konsistenten Einstiegspunkt für externe Clients.
Load-Balancer-Integration mit Kubernetes: Der Load-Balancer wird automatisch bereitgestellt und konfiguriert, wenn Sie ein Kubernetes-
Servicevom Typtype: LoadBalancerohne bestimmte interne Anmerkungen erstellen.Zonenbewusstsein: Der eingehende Traffic wird auf fehlerfreie Anwendungspods verteilt, die in allen verfügbaren Zonen im GDC-Universum ausgeführt werden. Der ELB stützt sich auf Pod-Bereitschaftsprüfungen, um den Zustand des Back-Ends zu bestimmen.
Skalierbarkeit: Verteilung von externem Traffic, wenn Ihre Anwendung horizontal über Knoten und Zonen hinweg skaliert wird.
Die Verwendung eines externen Load Balancers ist die Standardmethode und wird empfohlen, um HA für eingehenden externen Traffic zu erreichen. Clientanfragen werden also automatisch von fehlerhaften Zonen oder Instanzen weggeleitet.
Weitere Informationen finden Sie unter Externe Load-Balancer konfigurieren.
Interner Load Balancer für Ost-West-Traffic
Für die Kommunikation zwischen Diensten, die im selben GKE on GDC-Cluster ausgeführt werden (Ost-West-Traffic), stellt GDC einen internen Load-Balancer (ILB) bereit. Dies ist entscheidend, um interne Dienste zu entkoppeln und interne Kommunikationspfade bereitzustellen, die ebenfalls hochverfügbar und skalierbar sind.
Die wichtigsten Merkmale des ILB-Dienstes, der für hohe Verfügbarkeit und Skalierbarkeit sorgt, sind die folgenden:
Interner Zugriff: Stellt eine stabile interne IP-Adresse bereit, auf die nur innerhalb des GDC-Netzwerks zugegriffen werden kann, z. B. über Clusterknoten oder andere interne Dienste.
Load-Balancer-Integration in Kubernetes: Wird in der Regel durch Erstellen eines Kubernetes-
Servicevom Typtype: LoadBalancermit einer bestimmten Annotation bereitgestellt, um anzugeben, dass er intern sein muss. Beispiel:networking.gke.io/load-balancer-type: "Internal".Zonenbewusstsein: Der Traffic wird auf fehlerfreie Backend-Pods verteilt, die mit Bereitschaftstests identifiziert werden und sich in allen verfügbaren Zonen befinden. Diese Verteilung verhindert interne Kommunikationsfehler, wenn in einer Zone Probleme auftreten.
Diensterkennung und Entkopplung: Bietet eine stabile interne IP-Adresse und einen DNS-Namen mit kube-dns- und CoreDNS-Integration. Dienste können sich gegenseitig erkennen und miteinander kommunizieren. Clients müssen daher nicht die IP-Adressen einzelner Pods kennen.
Skalierbarkeit: Ermöglicht die Skalierung interner Backend-Dienste, indem Traffic auf alle verfügbaren fehlerfreien Replikate verteilt wird.
Wenn Sie einen ILB für die interne Kommunikation zwischen Diensten verwenden, ist der interne Trafficfluss widerstandsfähiger gegen Zonenausfälle und bietet eine effektive Skalierung. Dies ergänzt die HA, die durch den externen ELB und die zugrunde liegende Compute-Verteilung bereitgestellt wird. Dies wird häufig für mehrschichtige Anwendungen verwendet, bei denen Front-Ends mit Backend-APIs oder Datenbanken innerhalb des Kubernetes-Clusters kommunizieren müssen.
Weitere Informationen finden Sie unter Interne Load-Balancer konfigurieren.
HA-App-Bereitstellung zonenübergreifend mit asynchronem Speicher
Mit GDC können Sie Infrastruktur und Anwendungen näher an Ihren Datenquellen oder Endnutzern ausführen. Hochverfügbarkeit in Ihrem GDC-Universum ist für kritische Arbeitslasten von entscheidender Bedeutung. Sie können HA-Anwendungen in mehreren Zonen in Ihrem GDC-Universum bereitstellen und die asynchrone Speicherreplikation für die Datenpersistenz und Notfallwiederherstellung implementieren.
Zonen stellen unterschiedliche Fehlerdomains in einem einzelnen Universum dar. Durch die Verteilung von Anwendungskomponenten und die Replikation von Daten über Zonen hinweg können Sie die Ausfallsicherheit gegenüber lokalen Hardwarefehlern oder Wartungsereignissen erheblich verbessern.
Nächste Schritte
Informationen zum Bereitstellen eines Dienstes als Sammlung von VMs, die über Zonen verteilt sind und asynchron replizierten Blockspeicher verwenden, finden Sie unter HA-VM-App bereitstellen.
Informationen zum Bereitstellen eines Dienstes als containerisierte Anwendung in Kubernetes über Zonen hinweg mit asynchron replizierten nichtflüchtigen Speichern finden Sie unter HA-Containeranwendung bereitstellen.