Multiregionale Bereitstellung in Compute Engine

In diesem Dokument wird eine Referenzarchitektur für eine mehrschichtige Anwendung bereitgestellt, die auf Compute Engine-VMs in mehreren Regionen in Google Cloudausgeführt wird. Sie können diese Referenzarchitektur verwenden, um lokale Anwendungen mit minimalen Änderungen an den Anwendungen effizient zu hosten (Lift-and-Shift). Das Dokument beschreibt auch die Designfaktoren, die Sie beim Erstellen einer multiregionalen Architektur für Ihre Cloud-Anwendungen berücksichtigen sollten. Dieses Dokument richtet sich an Cloud-Architekten.

Architektur

Das folgende Diagramm zeigt eine Architektur für eine Anwendung, die im Aktiv/Aktiv-Modus in isolierten Stacks ausgeführt wird, die in zwei Google Cloud Regionen bereitgestellt werden. In jeder Region wird die Anwendung unabhängig in drei Zonen ausgeführt. Die Architektur ist auf den Google Cloud Archetyp für multiregionale Bereitstellungen ausgerichtet. Dadurch wird sichergestellt, dass Ihre Google Cloud Topologie gegen Zonen- und Regionsausfälle resistent ist und einen niedrigen Wert bietet der Latenz für Anwendungsnutzer.

Multiregionale Architektur mit einem globalen Load Balancer

Die Architektur basiert auf dem Cloud-Modell Infrastructure as a Service (IaaS). Sie stellen die erforderlichen Infrastrukturressourcen (Computing, Netzwerk und Speicher) in Google Cloudbereit und behalten die volle Kontrolle über und die Verantwortung für das Betriebssystem, die Middleware und die höheren Ebenen des Anwendungs-Stacks. Weitere Informationen zu IaaS und anderen Cloud-Modellen finden Sie unter PaaS im Vergleich zu IaaS im Vergleich zu SaaS zu CaaS: Wie unterscheiden sie sich?

Das obige Diagramm enthält die folgenden Komponenten:

Komponente Purpose
Globaler externer Load Balancer

Der globale externe Load Balancer empfängt und verteilt Nutzeranfragen an die Anwendung. Der globale externe Load Balancer bewirbt eine einzelne Anycast-IP-Adresse, ist aber als eine große Anzahl von Proxys auf Google Front Ends (GFEs) implementiert. Clientanfragen werden an das GFE weitergeleitet, das dem Client am nächsten ist.
Regionale verwaltete Instanzgruppen (MIGs) für die Webebene

Die Webebene der Anwendung wird auf Compute Engine-VMs bereitgestellt, die Teil regionaler verwalteter Instanzgruppen sind. Diese MIGs sind die Backends für den globalen Load Balancer.

Jede MIG enthält Compute Engine-VMs in drei verschiedenen Zonen. Jede dieser VMs hostet eine unabhängige Instanz der Webebene der Anwendung.
Regionale interne Load Balancer

Der interne Load Balancer in jeder Region verteilt den Traffic von den VMs der Webebene auf die VMs der Anwendungsebene in dieser Region.
Regionale MIGs für die Anwendungsebene

Die Anwendungsebene wird auf Compute Engine-VMs bereitgestellt, die Teil regionaler MIGs sind. Die MIG in jeder Region ist das Backend für den internen Load Balancer in dieser Region.

Jede MIG enthält Compute Engine-VMs in drei verschiedenen Zonen. Jede VM hostet eine unabhängige Instanz der Anwendungsebene.
Auf Compute Engine-VMs bereitgestellte Datenbank eines Drittanbieters

Die Architektur in diesem Dokument zeigt eine Drittanbieterdatenbank wie PostgreSQL, die auf Compute Engine-VMs in den beiden Regionen bereitgestellt wird. Sie können eine regionenübergreifende Replikation für die Datenbanken einrichten und die Datenbank in jeder Region so konfigurieren, dass ein Failover auf die Datenbank in der anderen Region erfolgt. Die Replikations- und der Failover-Funktionen hängen von der verwendeten Datenbank ab.

Die Installation und Verwaltung einer Drittanbieter-Datenbank sind mit zusätzlichen Aufwand und Betriebskosten für die Anwendung von Aktualisierungen, Monitoring und Gewährleistung der Verfügbarkeit verbunden. Sie können den Aufwand für die Installation und Verwaltung einer Drittanbieter-Datenbank vermeiden und von integrierten Hochverfügbarkeitsfeatures (HA) profitieren, wenn Sie eine vollständig verwaltete Datenbank wie eine multiregionale Spanner-Instanz verwenden.
Virtual Private Cloud-Netzwerk und Subnetze

Alle Google Cloud Ressourcen in der Architektur verwenden ein einzelnes VPC-Netzwerk mit Subnetzen in zwei verschiedenen Regionen.

Je nach Ihren Anforderungen können Sie eine Architektur erstellen, die mehrere VPC-Netzwerke und Subnetze verwendet. Weitere Informationen finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen.
Cloud Storage-Buckets mit zwei Regionen

Datenbanksicherungen werden in Cloud Storage-Buckets mit Dual-Region gespeichert. Alternativ können Sie den Sicherungs- und Notfallwiederherstellungsdienst verwenden, um die Datenbanksicherungen zu erstellen, zu speichern und zu verwalten.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud Produkte verwendet:

  • Compute Engine: Ein sicherer und anpassbarer Computing-Dienst, mit dem Sie virtuelle Maschinen in der Infrastruktur von Google erstellen und ausführen können.
  • Cloud Load Balancing: Ein Portfolio von leistungsstarken, skalierbaren, globalen und regionalen Load-Balancern
  • Cloud Storage: Ein kostengünstiger, unbegrenzter Objektspeicher für verschiedene Datentypen. Auf Daten kann von innerhalb und außerhalb von Google Cloudzugegriffen werden. Sie werden zu Redundanzzwecken über Standorte hinweg repliziert.
  • Virtual Private Cloud (VPC): Ein virtuelles System, das globale, skalierbare Netzwerkfunktionen für Ihre Google Cloud Arbeitslasten bietet. VPC umfasst VPC-Netzwerk-Peering, Private Service Connect, Zugriff auf private Dienste und freigegebene VPCs.

Anwendungsfälle

In diesem Abschnitt werden Anwendungsfälle beschrieben, in denen sich eine multiregionale Bereitstellung in Compute Engine eignet.

Effiziente Migration von lokalen Anwendungen

Mit dieser Referenzarchitektur können Sie eine Google Cloud Topologie erstellen, um lokale Anwendungen mit minimalen Änderungen an den Anwendungen in die Cloud zu verschieben (Lift-and-Shift). Alle Ebenen der Anwendung in dieser Referenzarchitektur werden auf Compute Engine-VMs gehostet. Mit diesem Ansatz können Sie lokale Anwendungen effizient zur Cloud migrieren und die Kostenvorteile, der Zuverlässigkeit, Leistung und operativen Einfachheit von Google Cloudnutzen.

Hochverfügbarkeit für geografisch verteilte Nutzer

Wir empfehlen eine multiregionale Bereitstellung für Anwendungen, die geschäftskritisch sind und eine hohe Verfügbarkeit und Robustheit bei regionalen Ausfällen erfordern. Wenn eine Region aus irgendeinem Grund nicht verfügbar ist (auch bei einer groß angelegten Störung durch eine Naturkatastrophe), kommt es für die Nutzer der Anwendung zu keiner Ausfallzeit. Der Traffic wird an die Anwendung in den anderen verfügbaren Regionen weitergeleitet. Wenn Daten synchron repliziert werden, liegt das Ziel für die Wiederherstellungszeit (Recovery Time Objective, RTO) nahe bei null.

Niedrige Latenz für Anwendungsnutzer

Wenn sich Ihre Nutzer in einem bestimmten geografischen Gebiet befinden, z. B. auf einem Kontinent, können Sie eine multiregionale Bereitstellung verwenden, um ein optimales Gleichgewicht zwischen Verfügbarkeit und Leistung zu erreichen. Wenn eine der Regionen ausfällt, sendet der globale Load Balancer Anfragen, die in dieser Region stammen, an eine andere Region. Nutzer bemerken keine erheblichen Leistungseinbußen, da sich die Regionen innerhalb eines geografischen Gebiets befinden.

Designalternative

Die vorherige Architektur verwendet einen globalen Load Balancer, der bestimmte Funktionen unterstützt, um die Zuverlässigkeit Ihrer Bereitstellungen zu verbessern, z. B. Edge-Caching mit Cloud CDN. In diesem Abschnitt wird eine alternative Architektur mit regionalen Load Balancern und Cloud DNS vorgestellt. Diese alternative Architektur unterstützt die folgenden zusätzlichen Funktionen:

  • TLS-Beendigung (Transport Layer Security) in bestimmten Regionen
  • Möglichkeit, Inhalte aus der von Ihnen angegebenen Region bereitzustellen. Diese Region ist jedoch möglicherweise nicht zu einem bestimmten Zeitpunkt die leistungsstärkste Region.
  • Eine größere Auswahl an Verbindungsprotokollen, wenn Sie einen Passthrough-Network Load Balancer verwenden.

Weitere Informationen zu den Unterschieden zwischen regionalen und globalen Load Balancern finden Sie unter Globales oder regionales Load Balancing und Betriebsmodi.

Multiregionale Architektur mit regionalen Load Balancern und DNS

Die alternative Architektur im vorherigen Diagramm ist robust gegen Zonenausfälle und regionenweite Ausfälle. Eine öffentliche Cloud DNS-Zone leitet Nutzeranfragen an die entsprechende Region weiter. Regionale externe Load Balancer empfangen Nutzeranfragen und verteilen sie auf die Webebeneninstanzen der Anwendung innerhalb jeder Region. Die anderen Komponenten in dieser Architektur sind mit den Komponenten in der globalen Load Balancer-basierten Architektur identisch.

Designaspekte

Dieser Abschnitt enthält eine Anleitung zur Verwendung dieser Referenzarchitektur, um eine Architektur zu entwickeln, die Ihre spezifischen Anforderungen an Systemdesign, Sicherheit, Zuverlässigkeit, operative Effizienz, Kosten und Leistung erfüllt.

Berücksichtigen Sie beim Erstellen einer Architektur für Ihre Arbeitslast die Best Practices und Empfehlungen im Google Cloud Well-Architected Framework.

Systemdesign

Dieser Abschnitt enthält eine Anleitung zur Auswahl von Google Cloud Regionen für Ihre multiregionale Bereitstellung und zur Auswahl geeigneter Google Cloud Dienste.

Auswahl der Region

Berücksichtigen Sie bei der Auswahl der Google Cloud Regionen, in denen Ihre Anwendungen bereitgestellt werden müssen, die folgenden Faktoren und Anforderungen:

  • Verfügbarkeit von Google Cloud -Diensten in jeder Region Weitere Informationen finden Sie unter Produktverfügbarkeit nach Standort.
  • Verfügbarkeit von Compute Engine-Maschinentypen in jeder Region. Weitere Informationen finden Sie unter Regionen und Zonen.
  • Latenzanforderungen für den Endnutzer.
  • Kosten für Google Cloud Ressourcen.
  • Kosten für die regionenübergreifende Datenübertragung.
  • Gesetzliche Anforderungen.

Einige dieser Faktoren und Anforderungen können Kompromisse beinhalten. Beispielsweise hat die kostengünstigste Region möglicherweise nicht die niedrigste CO2-Bilanz. Weitere Informationen finden Sie unter Best Practices für die Auswahl der Region in Compute Engine.

Computing-Dienste

In der Referenzarchitektur in diesem Dokument werden Compute Engine-VMs für alle Ebenen der Anwendung verwendet. Je nach Anforderungen Ihrer Anwendung können Sie aus anderen Google Cloud -Computing-Diensten auswählen:

  • Container: Sie können containerisierte Anwendungen in Google Kubernetes Engine (GKE)-Clustern ausführen. GKE ist eine Engine zur Containerorchestrierung, die die Bereitstellung, Skalierung und Verwaltung von Containeranwendungen automatisiert.
  • Serverlos: Wenn Sie sich bei Ihren IT-Maßnahmen auf Ihre Daten und Anwendungen konzentrieren möchten, anstatt Infrastrukturressourcen einzurichten und zu betreiben, können Sie serverlose Dienste wie Cloud Run verwenden.

Die Entscheidung, ob VMs, Container oder serverlose Dienste verwendet werden sollen, erfordert einen Kompromiss zwischen Konfigurationsflexibilität und Verwaltungsaufwand. VMs und Container bieten mehr Konfigurationsflexibilität, aber Sie sind für die Verwaltung der Ressourcen verantwortlich. In einer serverlosen Architektur stellen Sie Arbeitslasten auf einer vorkonfigurierten Plattform bereit, die minimalen Verwaltungsaufwand erfordern. Weitere Informationen zur Auswahl geeigneter Computing-Dienste für Ihre Arbeitslasten inGoogle Cloudfinden Sie unter Anwendungen in Google Cloudhosten.

Speicherdienste

Die in diesem Dokument dargestellten Architekturen verwenden regionale Persistent Disk-Volumes für alle Stufen. Nichtflüchtige Speicher ermöglichen die synchrone Replikation von Daten über zwei Zonen innerhalb einer Region.

Weitere Speicheroptionen für multiregionale Bereitstellungen sind Cloud Storage-Buckets mit zwei oder mehreren Regionen. In einem biregionalen oder multiregionalen Bucket gespeicherte Objekte werden redundant an mindestens zwei separaten geografischen Orten gespeichert. Metadaten werden synchron über Regionen hinweg geschrieben und Daten asynchron repliziert. Für biregionale Buckets können Sie die Turboreplikation verwenden, die dafür sorgt, dass Objekte über Regionspaare hinweg repliziert werden, mit einem RPO (Recovery Point Objective) von 15 Minuten. Weitere Informationen finden Sie unter Datenverfügbarkeit und Langlebigkeit.

Sie können eine Filestore-Regionalinstanz nutzen, um Daten zu speichern, die von mehreren VMs in einer Region gemeinsam genutzt werden, z. B. für alle VMs in der Web- oder Anwendungsebene. Die Daten, die Sie in einer Filestore Enterprise-Instanz speichern, werden synchron über drei Zonen innerhalb der Region repliziert. Die Replikation sorgt für hohe Verfügbarkeit und Robustheit bei zonalen Ausfällen. Sie können freigegebene Konfigurationsdateien, gängige Tools und Dienstprogramme sowie zentralisierte Logs in der Filestore-Instanz speichern und die Instanz auf mehreren VMs bereitstellen.

Wenn Ihre Datenbank Microsoft SQL Server ist, empfehlen wir die Verwendung von Cloud SQL for SQL Server. In Szenarien, in denen Cloud SQL Ihre Konfigurationsanforderungen nicht unterstützt oder Sie Zugriff auf das Betriebssystem benötigen, können Sie eine Failovercluster-Instanz (FCI) bereitstellen. In diesem Szenario können Sie die vollständig verwalteten Google Cloud NetApp Volumes verwenden, um CA-Speicher (Continuous Availability, CA) für die Datenbank bereitzustellen.

Berücksichtigen Sie beim Entwerfen des Speichers für Ihre multiregionalen Arbeitslasten die funktionalen Eigenschaften der Arbeitslasten, Anforderungen an die Ausfallsicherheit, Leistungserwartungen und Kostenziele. Weitere Informationen finden Sie unter Optimale Speicherstrategie für Ihre Cloudarbeitslast entwerfen.

Datenbankdienste

Die Referenzarchitektur in diesem Dokument verwendet eine Drittanbieter-Datenbank wie PostgreSQL, die auf Compute Engine-VMs bereitgestellt wird. Die Installation und Verwaltung einer Drittanbieter-Datenbank erfordert Aufwand und Kosten für Vorgänge wie das Anwenden von Updates, das Überwachen und Sicherstellen der Verfügbarkeit, das Sicherungen erstellen und Wiederherstellen nach Fehlern.

Sie können Aufwand und Kosten für die Installation und Verwaltung einer Drittanbieterdatenbank vermeiden, indem Sie einen vollständig verwalteten Datenbankdienst wie Cloud SQL, AlloyDB für PostgreSQL, Bigtable, Spanner oder Firestore nutzen. Diese Google Cloud Datenbankdienste bieten Service Level Agreements (SLAs) für die Betriebszeit und enthalten Standardfunktionen für Skalierbarkeit und Beobachtbarkeit.

Wenn für Ihre Arbeitslast eine Oracle-Datenbank erforderlich ist, können Sie die Datenbank auf einer Compute Engine-VM bereitstellen oder Oracle Database@Google Cloud verwenden. Weitere Informationen finden Sie unter Oracle-Arbeitslasten in Google Cloud.

Berücksichtigen Sie bei der Auswahl und Einrichtung der Datenbank für eine multiregionale Bereitstellung die Anforderungen Ihrer Anwendung für die regionsübergreifende Datenkonsistenz und beachten Sie die Kompromisse zwischen Leistung und Kosten.

  • Wenn die Anwendung eine starke Konsistenz erfordert (alle Nutzer müssen jederzeit dieselben Daten lesen), müssen die Daten synchron über alle Regionen in der Architektur hinweg repliziert werden. Die synchrone Replikation kann jedoch zu höheren Kosten und einer geringeren Leistung führen, da alle geschriebenen Daten in Echtzeit in den Regionen repliziert werden müssen, bevor sie für Lesevorgänge verfügbar sind.
  • Wenn Ihre Anwendung eine eventuale Konsistenz toleriert, können Sie Daten asynchron replizieren. Dies kann die Leistung verbessern, da die Daten nicht synchron über die Regionen hinweg repliziert werden müssen. Nutzer in verschiedenen Regionen können jedoch unterschiedliche Daten sehen, da die Daten zum Zeitpunkt der Anfrage möglicherweise nicht vollständig repliziert wurden.

Sicherheit, Datenschutz und Compliance

In diesem Abschnitt werden Faktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur berücksichtigen sollten, um eine multiregionale Topologie inGoogle Cloud zu entwerfen und zu erstellen, die die Sicherheits-, Datenschutz- und Compliance-Anforderungen Ihrer Arbeitslasten erfüllt.

Schutz vor externen Bedrohungen

Zum Schutz Ihrer Anwendung vor Bedrohungen wie DDoS-Angriffen (Distributed Denial of Service) und Cross-Site-Scripting (XSS) können Sie die Sicherheitsrichtlinien von Google Cloud Armor verwenden. Jede Richtlinie besteht aus Regeln, die bestimmte Bedingungen festlegen, die ausgewertet werden sollen, und Aktionen, die ausgeführt werden sollen, wenn die Bedingungen erfüllt sind. Eine Regel könnte beispielsweise festlegen, dass der Traffic abgelehnt werden muss, wenn die Quell-IP-Adresse des eingehenden Traffics mit einer bestimmten IP-Adresse oder einem CIDR-Bereich übereinstimmt. Sie können auch vorkonfigurierte WAF-Regeln (Web Application Firewall) anwenden. Weitere Informationen finden Sie unter Sicherheitsrichtlinien – Übersicht.

Externer Zugriff für VMs

In der Referenzarchitektur, die in diesem Dokument beschrieben wird, benötigen die VMs, auf denen die Anwendungsebene, die Webebene und die Datenbanken gehostet werden, keinen eingehenden Zugriff aus dem Internet. Weisen Sie diesen VMs keine externen IP-Adressen zu. Google Cloud Ressourcen, die nur eine private, interne IP-Adresse haben, können über Private Service Connect oder den privaten Google-Zugriff dennoch auf bestimmte Google APIs und Google-Dienste zugreifen. Weitere Informationen finden Sie unter Private Zugriffsoptionen für Dienste.

Sie können Secure Web Proxy oder Cloud NAT verwenden, um sichere ausgehende Verbindungen von Ressourcen zu ermöglichen, die nur private IP-Adressen haben, wie die Compute Engine-VMs in dieser Referenzarchitektur. Google Cloud

VM-Image-Sicherheit

Sie können vertrauenswürdige Images verwenden, um die Sicherheit von VM-Images zu erhöhen. Zuverlässige Images sind Images mit Software, die Ihren Richtlinien- oder Sicherheitsanforderungen entspricht. Wenn Sie möchten, dass Ihre VMs nur vertrauenswürdige Images verwenden, können Sie eine Organisationsrichtlinie definieren, die die Verwendung von Images in bestimmten öffentlichen Image-Projekten einschränkt. Weitere Informationen finden Sie unter Trusted Image-Richtlinien einrichten.

Dienstkontoberechtigungen

Wir empfehlen, anstelle der Standarddienstkonten für die Compute Engine-VMs in der Architektur spezielle Dienstkonten zu erstellen und die Ressourcen anzugeben, auf die das Dienstkonto zugreifen kann. Das Standarddienstkonto umfasst eine breite Palette von Berechtigungen, die in diesem Szenario nicht erforderlich sind. Sie können spezielle Dienstkonten so anpassen, dass sie nur die erforderlichen Berechtigungen haben. Weitere Informationen finden Sie unter Dienstkontoberechtigungen einschränken.

SSH-Sicherheit

Um die Sicherheit von SSH-Verbindungen zu den Compute Engine-VMs in dieser Architektur zu erhöhen, implementieren Sie die IAP-Weiterleitung (Identity-Aware Proxy) mit der Cloud OS Login API. Mit IAP können Sie den Netzwerkzugriff basierend auf der Nutzeridentität und IAM-Richtlinien (Identity and Access Management) steuern. Mit der Cloud OS Login API können Sie den Linux-SSH-Zugriff basierend auf Nutzeridentität und IAM-Richtlinien steuern. Weitere Informationen zum Verwalten des Netzwerkzugriffs finden Sie unter Best Practices für die Steuerung des SSH-Anmeldezugriffs.

Laufwerksverschlüsselung

Standardmäßig werden die in Persistent Disk-Volumes gespeicherten Daten mitGoogle-owned and Google-managed encryption keysverschlüsselt. Als zusätzliche Schutzebene können Sie die Google-owned and managed key mithilfe von Schlüsseln verschlüsseln, die Ihnen gehören und die Sie im Cloud Key Management Service (Cloud KMS) verwalten. Weitere Informationen finden Sie unter Laufwerksverschlüsselung für Hyperdisk-Volumes und Daten mit vom Kunden verwalteten Verschlüsselungsschlüsseln verschlüsseln.

Netzwerksicherheit

Zur Steuerung des Netzwerk-Traffics zwischen den Ressourcen in der Architektur müssen Sie geeignete Cloud Next Generation Firewall-Richtlinien (NGFW) konfigurieren.

Überlegungen zum Datenstandort

Sie können regionale Load Balancer verwenden, um eine multiregionale Architektur zu erstellen, mit der Sie die Anforderungen an den Datenstandort erfüllen können. Beispiel: In einem Land in Europa müssen alle Nutzerdaten in Rechenzentren gespeichert und abgerufen werden, die sich physisch innerhalb des Europa befinden. Um diese Anforderung zu erfüllen, können Sie die regionale Load Balancer-basierte Architektur verwenden. In dieser Architektur wird die Anwendung in Google Cloud Regionen in Europa ausgeführt und Sie verwenden Cloud DNS mit einer Geofencing-Routingrichtlinie, um Traffic über regionale Load Balancer zu leiten. Verwenden Sie anstelle der regionenübergreifenden Replikation eine shardbasierte Architektur, um die Anforderungen an die Datenspeicherung für die Datenbankebene zu erfüllen. Bei diesem Ansatz sind die Daten in jeder Region isoliert, aber Sie können keine regionsübergreifende Hochverfügbarkeit und keinen Failover für die Datenbank implementieren.

Weitere Sicherheitsaspekte

Beachten Sie beim Erstellen der Architektur für Ihre Arbeitslast die Best Practices und Empfehlungen zur Sicherheit auf Plattformebene, die im Sicherheits-Enterprise-Grundlagen-Blueprint und im Google Cloud Well-Architected Framework: Sicherheit, Datenschutz und Compliance enthalten sind.

Zuverlässigkeit

In diesem Abschnitt werden Designfaktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur zum Erstellen und Betreiben einer zuverlässigen Infrastruktur für Ihre multiregionalen Bereitstellungen in Google Cloudberücksichtigen sollten.

Robustheit bei Infrastrukturausfällen

Wenn in einer multiregionalen Bereitstellungsarchitektur eine einzelne Komponente im Infrastruktur-Stack ausfällt, kann die Anwendung Anfragen verarbeiten, wenn mindestens eine funktionierende Komponente mit ausreichender Kapazität in jeder Stufe vorhanden ist. Wenn beispielsweise eine Webserverinstanz ausfällt, leitet der Load Balancer Nutzeranfragen an die anderen verfügbaren Webserverinstanzen weiter. Wenn eine VM, die einen Webserver oder eine Anwendungsserverinstanz hostet, abstürzt, erstellt die MIG die VM automatisch neu.

Wenn ein zonaler Ausfall auftritt, ist der Load Balancer nicht betroffen, da es sich um eine regionale Ressource handelt. Ein Zonenausfall kann sich auf einzelne Compute Engine-VMs auswirken. Die Anwendung bleibt jedoch verfügbar und reaktionsfähig, da sich die VMs in einer regionalen MIG befinden. Eine regionale MIG sorgt dafür, dass neue VMs automatisch erstellt werden, um die konfigurierte Mindestanzahl von VMs aufrechtzuerhalten. Nachdem Google den Ausfall behoben hat, müssen Sie prüfen, ob die Anwendung in allen Zonen, in denen sie bereitgestellt wird, wie erwartet ausgeführt wird.

Wenn alle Zonen in einer der Regionen ausfallen oder es zu einem regionsweiten Ausfall kommt, bleibt die Anwendung in der anderen Region verfügbar und reagiert weiterhin. Der globale externe Load Balancer leitet den Traffic an die Region weiter, die nicht vom Ausfall betroffen ist. Nachdem Google den regionalen Ausfall behoben hat, müssen Sie prüfen, ob die Anwendung in der Region, in der der Ausfall aufgetreten ist, wie erwartet ausgeführt wird.

Wenn beide Regionen in dieser Architektur Ausfälle haben, ist die Anwendung nicht verfügbar. Sie müssen warten, bis Google den Ausfall behoben hat, und dann prüfen, ob die Anwendung wie erwartet funktioniert.

MIG-Autoscaling

Wenn Sie Ihre Anwendung in mehreren regionalen MIGs ausführen, bleibt die Anwendung bei isolierten Ausfällen der Zone oder Regionsausfällen verfügbar. Mit der Autoscaling-Funktion zustandsloser MIGs können Sie die Verfügbarkeit und Leistung von Anwendungen auf vorhersehbaren Leveln aufrechterhalten. Zum Steuern des Autoscaling-Verhaltens Ihrer zustandslosen MIGs können Sie Zielauslastungsmesswerte angeben, z. B. die durchschnittliche CPU-Auslastung. Sie können auch das zeitplanabgestimmtes Autoscaling für zustandslose MIGs konfigurieren. Zustandsorientierte MIGs können nicht automatisch skaliert werden. Weitere Informationen finden Sie unter Autoscaling von Instanzgruppen.

MIG-Größenlimit

Berücksichtigen Sie beim Festlegen der Größe Ihrer verwalteten Instanzgruppen die Standard- und Höchstgrenzen für die Anzahl der VMs, die in einer verwalteten Instanzgruppe erstellt werden können. Weitere Informationen finden Sie unter VMs zu einer MIG hinzufügen und daraus entfernen.

Automatische Reparatur von VMs

Manchmal werden die VMs, auf denen Ihre Web- und Anwendungsebene gehostet wird, ausgeführt und verfügbar gemacht. Es können jedoch Probleme mit der Anwendung selbst auftreten. Die Anwendung kann einfrieren, abstürzen oder nicht genügend Arbeitsspeicher haben. In diesem Szenario reagieren die VMs nicht auf die Systemdiagnosen des Load Balancer und der Load Balancer leitet den Traffic nicht an die nicht reagierenden VMs weiter. Sie können anwendungsbasierte Systemdiagnosen als Teil der Richtlinie für die automatische Reparatur Ihrer MIGs konfigurieren, um dafür zu sorgen, dass Anwendungen wie erwartet reagieren. Wenn die Anwendung auf einer bestimmten VM nicht reagiert, wird die VM von der MIG automatisch repariert. Weitere Informationen zur Konfiguration der automatischen Reparatur finden Sie unter VMs für Hochverfügbarkeit reparieren.

VM-Platzierung

In der in diesem Dokument beschriebenen Architektur werden die Anwendungsebene und die Webebene auf Compute Engine-VMs ausgeführt, die über mehrere Zonen verteilt sind. Diese Verteilung sorgt dafür, dass Ihre Anwendung gegen Zonenausfälle resistent ist. Zur weiteren Verbesserung dieser Robustheit können Sie eine Richtlinie für gestreute Platzierungen erstellen und auf die MIG-Vorlage anwenden. Wenn die MIG VMs erstellt, werden die VMs in jeder Zone auf verschiedenen physischen Servern (Hosts) platziert. Dadurch sind Ihre VMs gegen Ausfälle einzelner Hosts geschützt. Weitere Informationen finden Sie unter Richtlinien für gestreute Platzierungsrichtlinien auf VMs anwenden.

VM-Kapazitätsplanung

Damit die Kapazität für Compute Engine-VMs verfügbar ist, wenn dies erforderlich ist, können Sie Reservierungen erstellen. Eine Reservierung bietet zugesicherte Kapazität in einer bestimmten Zone für eine bestimmte Anzahl von VMs eines von Ihnen ausgewählten Maschinentyps. Eine Reservierung kann für ein Projekt spezifisch sein oder für mehrere Projekte freigegeben sein. Weitere Informationen zu Reservierungen, einschließlich Aspekten der Abrechnung, finden Sie unter Reservierungen von zonalen Compute Engine-Ressourcen.

Zustandsorientierter Speicher

Eine Best Practice beim Anwendungsdesign besteht darin, die Notwendigkeit von zustandsorientierten lokalen Laufwerken zu vermeiden. Wenn dies jedoch erforderlich ist, können Sie Ihre nichtflüchtigen Speicher so konfigurieren, dass sie zustandsorientiert sind, damit die Daten erhalten bleiben, wenn die VMs repariert oder neu erstellt werden. Es empfiehlt sich jedoch, die Bootlaufwerke zustandslos zu lassen, damit Sie sie problemlos auf die neuesten Images mit neuen Versionen und Sicherheitspatches aktualisieren können. Weitere Informationen finden Sie unter Zustandsorientierte nichtflüchtige Speicher in MIGs konfigurieren.

Datenhaltbarkeit

Sie können Sicherungen und Notfallwiederherstellungen verwenden, um Sicherungen der Compute Engine-VMs zu erstellen, zu speichern und zu verwalten. Bei Sicherung und Notfallwiederherstellung werden Sicherungsdaten in ihrem ursprünglichen, für Anwendungen lesbaren Format gespeichert. Bei Bedarf können Sie Ihre Arbeitslasten in der Produktion wiederherstellen, indem Sie Daten aus dem langfristigen Sicherungsspeicher direkt verwenden, ohne Daten vorbereiten oder verschieben zu müssen.

Compute Engine bietet die folgenden Optionen, mit denen Sie für die Langlebigkeit von Daten sorgen können, die auf Persistent Disk-Volumes gespeichert sind:

  • Sie können Snapshots verwenden, um den Status von Persistent Disk-Volumes zu einem bestimmten Zeitpunkt zu erfassen. Die Snapshots werden redundant in mehreren Regionen mit automatischen Prüfsummen gespeichert, um die Integrität der Daten zu gewährleisten. Snapshots sind standardmäßig inkrementell, sodass weniger Speicherplatz belegt wird und Sie Geld sparen. Snapshots werden an einem Cloud Storage-Speicherort gespeichert, den Sie konfigurieren können. Weitere Empfehlungen zur Verwendung und Verwaltung von Snapshots finden Sie unter Best Practices für Compute Engine-Laufwerk-Snapshots.
  • Mit regionalen Persistent Disk-Volumes können Sie hochverfügbare Anwendungen ausführen, die nicht von Ausfällen in nichtflüchtigen Speichern betroffen sind. Wenn Sie einen regionalen nichtflüchtigen Speicher-Volume erstellen, verwaltet Compute Engine ein Replikat des Laufwerks in einer anderen Zone derselben Region. Die Daten werden synchron auf die Laufwerke in beiden Zonen repliziert. Wenn eine der beiden Zonen ausfällt, bleiben die Daten verfügbar.

Datenbankverfügbarkeit

Sie benötigen einen Mechanismus, um Ausfälle der primären Datenbank zu identifizieren und einen Failover auf die Standby-Datenbank, um zonenübergreifendes Failover für die Datenbank in jeder Region zu implementieren. Die Details des Failover-Mechanismus hängen von der verwendeten Datenbank ab. Sie können eine Beobachterinstanz einrichten, um Fehler der primären Datenbank zu erkennen und das Failover zu orchestrieren. Sie müssen die Failover-Regeln entsprechend konfigurieren, um eine Split-Brain-Situation zu vermeiden und unnötiges Failover zu vermeiden. Beispielarchitekturen, mit denen Sie Failover für PostgreSQL-Datenbanken implementieren können, finden Sie unter Architekturen für Hochverfügbarkeit von PostgreSQL-Clustern in Compute Engine.

Weitere Überlegungen zur Zuverlässigkeit

Lesen Sie beim Erstellen der Cloud-Architektur für Ihre Arbeitslast die zuverlässigsten Best Practices und Empfehlungen in der folgenden Dokumentation:

Kostenoptimierung

Dieser Abschnitt enthält Anleitungen zur Optimierung der Kosten für die Einrichtung und den Betrieb einer multiregionalen Google Cloud Topologie, die Sie mithilfe dieser Referenzarchitektur erstellen.

VM-Maschinentypen

Damit Sie die Ressourcennutzung Ihrer VM-Instanzen optimieren können, bietet Compute Engine Empfehlungen für Maschinentypen. Wählen Sie anhand der Empfehlungen Maschinentypen aus, die den Computing-Anforderungen Ihrer Arbeitslast entsprechen. Bei Arbeitslasten mit vorhersehbaren Ressourcenanforderungen können Sie den Maschinentyp mithilfe von benutzerdefinierten Maschinentypen an Ihre Anforderungen anpassen und Kosten sparen.

VM-Bereitstellungsmodell

Wenn Ihre Anwendung fehlertolerant ist, können Sie mit Spot-VMs die Compute Engine-Kosten für die VMs in der Anwendungs- und der Webstufe reduzieren. Die Kosten für Spot-VMs sind deutlich niedriger als für normale VMs. Compute Engine kann Spot-VMs jedoch vorzeitig beenden oder löschen, um Kapazitäten zurückzugewinnen. Spot-VMs sind für Batchjobs geeignet, die ein vorzeitiges Beenden tolerieren können und keine Hochverfügbarkeitsanforderungen haben. Spot-VMs bieten die gleichen Maschinentypen, Optionen und Leistungsoptionen wie reguläre VMs. Wenn die Ressourcenkapazität in einer Zone jedoch begrenzt ist, können MIGs möglicherweise nicht automatisch auf die angegebene Zielgröße horizontal skaliert werden (d. h. VMs erstellen), bis die erforderliche Kapazität wieder verfügbar ist.

VM-Ressourcennutzung

Die Autoscaling-Funktion zustandsloser MIGs ermöglicht es Ihrer Anwendung, zunehmenden Traffic reibungslos zu bewältigen. Außerdem können Sie bei einem geringen Ressourcenbedarf die Kosten senken. Zustandsorientierte MIGs können nicht automatisch skaliert werden.

Lizenzierung durch Drittanbieter

Wenn Sie Arbeitslasten von Drittanbietern zu Google Cloudmigrieren, können Sie die Kosten senken, indem Sie Ihre eigenen Lizenzen (BYOL) verwenden. Wenn Sie beispielsweise Microsoft Windows Server-VMs bereitstellen möchten, können Sie anstelle eines Premium-Images, das zusätzliche Kosten für die Drittanbieterlizenz verursacht, ein benutzerdefiniertes Windows-BYOL-Image erstellen und verwenden. Sie zahlen dann nur für die VM-Infrastruktur, die Sie in Google Cloudverwenden. Mit dieser Strategie können Sie Ihre bestehenden Investitionen in Drittanbieterlizenzen weiter nutzen. Wenn Sie sich für einen BYOL-Ansatz entscheiden, empfehlen wir Folgendes:

  • Stellen Sie die erforderliche Anzahl von Rechen-CPU-Kernen unabhängig vom Arbeitsspeicher mithilfe von benutzerdefinierten Maschinentypen bereit. Dadurch beschränken Sie die Lizenzkosten von Drittanbietern auf die Anzahl der benötigten CPU-Kerne.
  • Reduzieren Sie die Anzahl der vCPUs pro Kern von 2 auf 1, indem Sie das gleichzeitige Multithreading (SMT) deaktivieren und Ihre Lizenzkosten um 50 % reduzieren.

Weitere Kostengesichtspunkte

Berücksichtigen Sie beim Erstellen der Architektur für Ihre Arbeitslast auch die allgemeinen Best Practices und Empfehlungen, die unter Google Cloud Well-Architected Framework: Kostenoptimierung bereitgestellt werden.

Operative Effizienz

In diesem Abschnitt werden die Faktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur zum Entwerfen und Erstellen einer mehrregionalen Google Cloud Topologie berücksichtigen sollten und mit der Sie effizient arbeiten können.

Aktualisierungen von VM-Konfigurationen

Erstellen Sie eine neue Instanzvorlage mit der erforderlichen Konfiguration und wenden Sie die neue Vorlage auf die MIG an, um die Konfiguration der VMs in einer MIG zu aktualisieren (z. B. Maschinentyp oder Bootlaufwerk-Image). Die MIG aktualisiert die VMs mit der von Ihnen ausgewählten Aktualisierungsmethode: automatisch oder selektiv. Wählen Sie je nach Ihren Anforderungen an Verfügbarkeit und betriebliche Effizienz eine geeignete Methode aus. Weitere Informationen zu diesen MIG-Aktualisierungsmethoden finden Sie unter Neue VM-Konfigurationen in einer MIG anwenden.

VM-Images

Für Ihre MIG-Instanzvorlagen empfehlen wir, anstelle der von Google bereitgestellten öffentlichen Images benutzerdefinierte Betriebssystem-Images zu erstellen und zu verwenden, die die Konfigurationen und Software enthalten, die Ihre Anwendungen benötigen. Sie können Ihre benutzerdefinierten Images in einer benutzerdefinierten Image-Familie zusammenfassen. Die Imagefamilie verweist immer auf das neueste Image in dieser Familie. Ihre Instanzvorlagen und -skripte können dieses Image daher verwenden, ohne dass Verweise auf eine bestimmte Image-Version aktualisiert werden müssen. Sie müssen Ihre benutzerdefinierten Images regelmäßig aktualisieren, um die Sicherheitsupdates und Patches des Betriebssystemanbieters zu berücksichtigen.

Deterministische Instanzvorlagen

Wenn die Instanzvorlagen, die Sie für Ihre MIGs verwenden, Startskripts für die Installation von Drittanbietersoftware enthalten, achten Sie darauf, dass in den Skripts explizit Softwareinstallationsparameter wie die Softwareversion angegeben werden. Andernfalls ist die auf den VMs installierte Software möglicherweise nicht konsistent, wenn die MIG die VMs erstellt. Wenn Ihre Instanzvorlage beispielsweise ein Startskript zum Installieren von Apache HTTP Server 2.0 (das Paket apache2) enthält, achten Sie darauf, dass das Skript die genaue apache2-Version angibt, die installiert werden soll, z. B. Version 2.4.53. Weitere Informationen finden Sie unter Deterministische Instanzvorlagen.

Weitere operative Aspekte

Berücksichtigen Sie beim Erstellen der Architektur für Ihre Arbeitslast die allgemeinen Best Practices und Empfehlungen für die betriebliche Effizienz, die unter Google Cloud Well-Architected Framework: Operative Exzellenz beschrieben werden.

Leistungsoptimierung

In diesem Abschnitt werden die Faktoren beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur zum Entwerfen und Erstellen einer multiregionalen Topologie inGoogle Cloud verwenden, die die Leistungsanforderungen Ihrer Arbeitslasten erfüllt.

VM-Platzierung

Für Arbeitslasten, die eine niedrige Netzwerklatenz zwischen VMs erfordern, können Sie eine Richtlinie für kompakte Platzierung erstellen und auf die MIG-Vorlage anwenden. Wenn die MIG VMs erstellt, werden die VMs auf physischen Servern platziert, die sich nahe beieinander befinden. Weitere Informationen finden Sie unter Latenz mithilfe von Richtlinien für kompakte Platzierung reduzieren.

Rechenleistung

Compute Engine bietet eine breite Palette vordefinierter und anpassbarer Maschinentypen für die Arbeitslasten, die Sie auf den VMs ausführen. Wählen Sie einen geeigneten Maschinentyp basierend auf Ihren Leistungsanforderungen aus. Weitere Informationen finden Sie im Leitfaden zu Ressourcen und Vergleichen für Maschinenfamilien.

VM-Multithreading

Jede virtuelle CPU (vCPU), die Sie einer Compute Engine-VM zuweisen, wird als einzelner Hardware-Multithread implementiert. Standardmäßig teilen sich zwei vCPUs einen physischen CPU-Kern. Bei Arbeitslasten, die sehr parallel sind oder Gleitkommaberechnungen durchführen (z. B. genetische Sequenzanalyse und Finanzrisikomodellierung), können Sie die Leistung verbessern, indem Sie die Anzahl der Threads reduzieren, die auf jeder physischen CPU-Kern ausgeführt werden. Core. Weitere Informationen finden Sie unter Anzahl der Threads pro Kern festlegen.

Netzwerkdienststufen

Mit Netzwerkdienststufen können Sie die Netzwerkkosten und die Leistung Ihrer Arbeitslasten optimieren. Sie können zwischen der Premium- und der Standardstufe wählen. Bei der Premium-Stufe wird der Traffic über das globale Backbone von Google geleitet, um einen minimalen Paketverlust und eine niedrige Latenz zu erreichen. Bei der Standardstufe wird Traffic über Peering, Internetanbieter oder Transitnetzwerke an einem Edge Point of Presence (PoP) bereitgestellt, der der Region am nächsten ist, in der Ihre Google Cloud Arbeitslast ausgeführt wird. Für eine optimale Leistung empfehlen wir die Premium-Stufe. Zur Kostenoptimierung empfehlen wir die Standardstufe.

Netzwerkleistung

Für Arbeitslasten, die eine niedrige Netzwerklatenz zwischen VMs innerhalb der Anwendungs- und Webebene erfordern, können Sie eine Richtlinie für kompakte Platzierung erstellen und auf die MIG-Vorlage anwenden, die für diese Ebenen verwendet wird. Wenn die MIG VMs erstellt, werden die VMs auf physischen Servern platziert, die sich nahe beieinander befinden. Mit einer Richtlinie für kompakte Platzierung lässt sich die Netzwerkleistung zwischen VMs verbessern. Mit einer Richtlinie für verteilte Platzierung lässt sich hingegen die VM-Verfügbarkeit verbessern, wie bereits beschrieben. Um ein optimales Gleichgewicht zwischen Netzwerkleistung und Verfügbarkeit zu erreichen, können Sie beim Erstellen einer Richtlinie für kompakte Platzierung angeben, wie weit die VMs voneinander entfernt platziert werden müssen. Weitere Informationen finden Sie unter Platzierungsrichtlinien – Übersicht.

Die Compute Engine hat ein pro VM festgelegtes Limit für die Netzwerkbandbreite für ausgehenden Traffic. Dieses Limit hängt vom Maschinentyp der VM und davon ab, ob der Traffic über dasselbe VPC-Netzwerk wie die Quell-VM geleitet wird. Bei VMs mit bestimmten Maschinentypen können Sie die Netzwerkleistung verbessern, indem Sie Tier_1-Netzwerke aktivieren. Dadurch wird die maximale Bandbreite für ausgehenden Traffic erhöht.

Caching

Wenn Ihre Anwendung statische Website-Assets bereitstellt und Ihre Architektur einen globalen externen Application Load Balancer enthält, können Sie Cloud CDN verwenden, um statische Inhalte, auf die regelmäßig zugegriffen wird, näher an Ihren Nutzern zu speichern. Sie können Cloud CDN dabei unterstützen, die Leistung für Ihre Nutzer zu verbessern, die Nutzung von Infrastrukturressourcen im Backend zu reduzieren und die Kosten für die Netzwerkbereitstellung zu senken. Weitere Informationen finden Sie unter Schnellere Webleistung und verbesserter Webschutz für Load Balancing.

Weitere Hinweise zur Leistung

Berücksichtigen Sie beim Erstellen der Architektur für Ihre Arbeitslast die allgemeinen Best Practices und Empfehlungen, die unter Google Cloud Well-Architected Framework: Leistungsoptimierung bereitgestellt werden.

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende: