Multiregionale Bereitstellung in Compute Engine

Last reviewed 2024-02-20 UTC

Dieses Dokument enthält eine Referenzarchitektur für eine mehrstufige Anwendung, die auf Compute Engine-VMs in mehreren Regionen in Google Cloud ausgeführt wird. Das Dokument enthält auch Anleitungen zum Erstellen einer Architektur, die andere Google Cloud-Infrastrukturdienste verwendet. Es werden die Designfaktoren beschrieben, die Sie beim Erstellen einer multiregionalen Architektur für Ihre Cloud-Anwendungen berücksichtigen sollten. Die Zielgruppe dieses Dokuments ist Cloud-Architekten.

Architektur

Abbildung 1 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. Die Anwendungen werden in jeder Region unabhängig in drei Zonen ausgeführt. Die Architektur ist auf den Architekturtyp des multiregionalen Deployments 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

Abbildung 1. Ein globaler Load-Balancer leitet Nutzeranfragen an regional isolierte Anwendungs-Stacks weiter.

Die Architektur basiert auf dem IaaS-Cloud-Modell (Infrastructure as a Service). Sie stellen die erforderlichen Infrastrukturressourcen (Computing, Netzwerk und Speicher) in Google Cloud bereit und behalten die volle Kontrolle und Verantwortung für das Betriebssystem, die Middleware und höhere Ebenen des Anwendungspakets. 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. Er wird jedoch 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.

Je nach Ihren Anforderungen können Sie einen globalen externen Anwendungs-Load-Balancer oder einen globalen externen Proxy-Netzwerk-Load-Balancer verwenden. Weitere Informationen finden Sie unter Load-Balancer auswählen.
Regionale verwaltete Instanzgruppen (Managed Instance Groups, MIGs) für die Webebene

Die Webebene der Anwendung wird auf Compute Engine-VMs bereitgestellt, die Teil regionaler MIGs sind. Diese MIGs sind die Back-Ends 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 Webstufe 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.

Je nach Ihren Anforderungen können Sie einen regionalen internen Anwendungs-Load-Balancer oder Netzwerk-Load-Balancer verwenden. Weitere Informationen finden Sie unter Load-Balancer auswählen.
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 Back-End 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 Anwendungsstufe.
Auf Compute Engine-VMs bereitgestellte Drittanbieterdatenbank

Auf VMs von Compute Engine in den beiden Regionen wird eine Drittanbieterdatenbank wie PostgreSQL bereitgestellt. Sie können für die Datenbanken eine regionenübergreifende Replikation 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.
Cloud Storage-Dual-Region-Buckets Sicherungen von Anwendungsdaten werden in dualregionalen Cloud Storage-Buckets gespeichert. Alternativ können Sie Sicherungs- und Notfallwiederherstellungsdienste zum Erstellen, Speichern und Verwalten der Datenbanksicherungen verwenden.

Anwendungsfälle

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

Effiziente Migration lokaler 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 Anwendungsebenen in dieser Referenzarchitektur werden auf Compute Engine-VMs gehostet. Mit diesem Ansatz können Sie lokale Anwendungen effizient zur Cloud migrieren und von den Kostenvorteilen, Zuverlässigkeit, Leistung und Nutzerfreundlichkeit von Google Cloud profitieren.

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 Ausfällen in der Region erfordern. Wenn eine Region aus irgendeinem Grund nicht mehr verfügbar ist (auch bei großflächigen Störungen aufgrund einer Naturkatastrophe), kommt es bei den Nutzern der Anwendung zu keinen Ausfallzeiten. Der Traffic wird an die Anwendung in den anderen verfügbaren Regionen weitergeleitet. Wenn Daten synchron repliziert werden, liegt das Recovery Time Objective (RTO) nahe null.

Niedrige Latenz für Anwendungsnutzer

Wenn sich Ihre Nutzer in einem bestimmten geografischen Gebiet befinden, z. B. auf einem Kontinent, können Sie ein multiregionales Deployment verwenden, um ein optimales Gleichgewicht zwischen Verfügbarkeit und Leistung zu erzielen. Wenn eine der Regionen ausfällt, sendet der globale Load-Balancer Anfragen, die aus dieser Region stammen, an eine andere Region. Nutzer nehmen keine erheblichen Auswirkungen auf die Leistung wahr, da sich die Regionen innerhalb eines geografischen Bereichs befinden.

Design alternative

Eine Architektur, die einen globalen Load-Balancer (Abbildung 1) verwendet, unterstützt bestimmte Features, mit denen Sie die Zuverlässigkeit Ihrer Bereitstellungen verbessern können, z. B. Edge-Caching mit Cloud CDN In diesem Abschnitt wird eine alternative Architektur vorgestellt, die regionale Load-Balancer und Cloud DNS verwendet, wie in Abbildung 2 dargestellt. Diese alternative Architektur unterstützt die folgenden zusätzlichen Features:

  • TLS-Beendigung (Transport Layer Security) in bestimmten Regionen.
  • Bereitstellung von Inhalten aus der von Ihnen angegebenen Region. Diese Region ist jedoch möglicherweise zu einem bestimmten Zeitpunkt nicht die beste Leistung.
  • Eine größere Bandbreite an Verbindungsprotokollen, wenn Sie einen Passthrough-Netzwerk-Load-Balancer verwenden.

Weitere Informationen zu den Unterschieden zwischen regionalen und globalen Load-Balancern finden Sie in der folgenden Dokumentation:

Multiregionale Architektur mit regionalen Load-Balancern und DNS

Abbildung 2. Cloud DNS leitet Nutzeranfragen an regionale Load-Balancer weiter.

Wie die Architektur in Abbildung 1 ist die Architektur in Abbildung 2 robust vor Zonenausfällen und regionen-. Eine öffentliche Zone in Cloud DNS leitet Nutzeranfragen an die entsprechende Region weiter. Regionale externe Load-Balancer empfangen Nutzeranfragen und verteilen diese auf die Instanzen der Webstufe der Anwendung innerhalb jeder Region. Die anderen Komponenten in dieser Architektur sind mit den Komponenten in der Architektur des globalen Load-Balancers identisch.

Weitere Informationen zum Erstellen einer multiregionalen Architektur mit mehreren regionalen Load-Balancern und Cloud DNS finden Sie unter Globale Load-Balancing-Architekturen mit DNS-Routingrichtlinien.

Designaspekte

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

Systemdesign

Dieser Abschnitt enthält Anleitungen zur Auswahl der 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 den einzelnen Regionen. Weitere Informationen finden Sie unter Produktverfügbarkeit nach Standort.
  • Verfügbarkeit von Compute Engine-Maschinentypen in den einzelnen Regionen Weitere Informationen finden Sie unter Regionen und Zonen.
  • Latenzanforderungen für Endnutzer
  • Kosten für Google Cloud-Ressourcen
  • Kosten für regionenübergreifende Datenübertragung
  • Gesetzliche Anforderungen

Einige dieser Faktoren und Anforderungen können Kompromisse enthalten. Beispielsweise hat die kostengünstigste Region möglicherweise nicht die niedrigste CO2-Bilanz. Weitere Informationen finden Sie unter Geografische Zonen und Regionen auswählen im Google Cloud-Architektur-Framework.

Computing-Dienste

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

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 in Google Cloud finden Sie im Google Cloud-Architektur-Framework unter Computing auswählen und verwalten.

Speicherdienste

Die in diesem Dokument dargestellten Architekturen verwenden für alle Ebenen regionale nichtflüchtige Speicher-Volumes. 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 regionenübergreifend synchron geschrieben und Daten werden asynchron repliziert. Für dualregionale Buckets können Sie die Turboreplikation verwenden. Damit wird sichergestellt, dass Objekte über Regionspaare hinweg mit einem Recovery Point Objective (RPO) von 15 Minuten repliziert werden. Weitere Informationen finden Sie unter Datenverfügbarkeit und Langlebigkeit.

Sie können eine Filestore Enterprise-Instanz 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 in 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, können Sie eine Failover-Clusterinstanz (FCI) bereitstellen und die vollständig verwalteten Google Cloud NetApp-Volumes verwenden. um KMU-Speicher für kontinuierliche Verfügbarkeit für die Datenbank bereitzustellen.

Berücksichtigen Sie beim Entwerfen des Speichers für Ihre multiregionalen Arbeitslasten die funktionalen Eigenschaften der Arbeitslasten, der Ausfallsicherheitsanforderungen, der Leistungserwartungen und der 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 Ihre Arbeitslasten eine Oracle-Datenbank erfordern, können Sie die Bare-Metal-Lösung von Google Cloud verwenden. Eine Übersicht über die Anwendungsfälle, für die jeder Google Cloud-Datenbankdienst geeignet ist, finden Sie unter Google Cloud-Datenbanken.

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 strikte Konsistenz erfordert (alle Nutzer müssen immer dieselben Daten lesen), müssen die Daten in allen Regionen der Architektur synchron repliziert werden. Die synchrone Replikation kann jedoch zu höheren Kosten und einer geringeren Leistung führen, da alle geschriebenen Daten in Echtzeit über die Regionen hinweg repliziert werden müssen, bevor die Daten für Lesevorgänge verfügbar sind.
  • Wenn Ihre Anwendung Eventual Consistency tolerieren kann, können Sie Daten asynchron replizieren. Dies kann die Leistung verbessern, da die Daten nicht regionsübergreifend synchron repliziert werden müssen. Nutzer in verschiedenen Regionen lesen jedoch möglicherweise unterschiedliche Daten, da die Daten zum Zeitpunkt der Anfrage möglicherweise nicht vollständig repliziert wurden.

Sicherheit und Compliance

In diesem Abschnitt werden Faktoren beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine multiregionale Topologie in Google Cloud zu entwerfen und zu erstellen, die den Sicherheits- und Compliance-Anforderungen Ihrer Arbeitslasten entspricht.

Schutz vor 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 ist ein Satz von Regeln, die bestimmte Bedingungen angeben, die ausgewertet werden sollen, sowie Aktionen, die ausgeführt werden sollen, wenn die Bedingungen erfüllt sind. Durch eine Regel kann beispielsweise angegeben werden, dass der Traffic abgelehnt werden muss, wenn die Quell-IP-Adresse des eingehenden Traffics mit einer bestimmten IP-Adresse oder einem CIDR-Bereich übereinstimmt. Außerdem können Sie 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 Optionen für den privaten Zugriff.

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

VM-Image-Sicherheit

Wenn Sie möchten, dass Ihre VMs nur genehmigte Images verwenden, also Images mit Software, die Ihren Richtlinien- oder Sicherheitsanforderungen entspricht, 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

In Google Cloud-Projekten, in denen die Compute Engine API aktiviert ist, wird automatisch ein Standarddienstkonto erstellt. Dem Standarddienstkonto wird die IAM-Rolle „Bearbeiter“ (roles/editor) zugewiesen, sofern dieses Verhalten nicht deaktiviert ist. Standardmäßig wird das Standarddienstkonto an alle VMs angehängt, die Sie mit der Google Cloud CLI oder der Google Cloud Console erstellen. Die Rolle "Bearbeiter" umfasst eine Vielzahl von Berechtigungen. Das Anhängen des Standarddienstkontos an VMs stellt also ein Sicherheitsrisiko dar. Um dieses Risiko zu vermeiden, können Sie für jede Anwendung dedizierte Dienstkonten erstellen und verwenden. Verwenden Sie detaillierte Richtlinien, um die Ressourcen anzugeben, auf die das Dienstkonto zugreifen kann. Weitere Informationen finden Sie unter Dienstkontoberechtigungen einschränken in "Best Practices für die Verwendung von Dienstkonten".

Ü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. Zur Erfüllung dieser Anforderung können Sie die regionale Load-Balancer-Architektur in Abbildung 2 verwenden. In dieser Architektur wird die Anwendung in Google Cloud-Regionen in Europa ausgeführt. Sie verwenden Cloud DNS mit einer Geofencing-Routingrichtlinie, um Traffic über regionale Load-Balancer weiterleiten Verwenden Sie eine fragmentierte Architektur anstelle einer regionenübergreifenden Replikation, um die Datenstandortanforderungen für die Datenbankstufe zu erfüllen. Bei diesem Ansatz sind die Daten in jeder Region isoliert, aber Sie können keine regionsübergreifende Hochverfügbarkeit und 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 Sicherheitsgrundlagen-Blueprint enthalten sind.

Zuverlässigkeit

In diesem Abschnitt werden Designfaktoren beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine zuverlässige Infrastruktur für Ihre multiregionalen Bereitstellungen in Google Cloud zu erstellen und zu betreiben.

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. Wenn Sie das Autoscaling-Verhalten Ihrer zustandslosen MIGs steuern möchten, können Sie Messwerte zur Zielauslastung 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.

Automatische Reparatur von VMs

Manchmal werden die VMs, auf denen Ihre Anwendung gehostet wird, ausgeführt und verfügbar gemacht. Es können jedoch Probleme mit der Anwendung selbst auftreten. Dieser kann einfrieren, abstürzen oder nicht genügend Arbeitsspeicher haben. Wenn Sie prüfen möchten, ob eine Anwendung wie erwartet reagiert, können Sie anwendungsbasierte Systemdiagnosen als Teil der Richtlinie für die automatische Reparatur Ihrer MIGs konfigurieren. 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 Systemdiagnose und automatische Reparatur einer Anwendung einrichten.

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 bei Bedarf verfügbar 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.

Nichtflüchtiger Speicher-status

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 Sicherung und Notfallwiederherstellung 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 für die Produktion wiederherstellen, indem Sie Daten direkt aus dem langfristigen Sicherungsspeicher verwenden, ohne dass zeitaufwändige Datenverschiebungen oder Vorbereitungsaktivitäten erforderlich sind.

Zum Speichern von Datenbanksicherungen und Transaktionslogs können Sie regionale Cloud Storage-Buckets verwenden. Diese bieten kostengünstigen Sicherungsspeicher, der zonenübergreifend redundant ist.

Compute Engine bietet die folgenden Optionen, um die Langlebigkeit von Daten zu gewährleisten, die in nichtflüchtigen Volumes gespeichert sind:

  • Sie können Standard-Snapshots verwenden, um den Status nichtflüchtiger Speicher-Volumes zu einem bestimmten Zeitpunkt zu erfassen. Die Snapshots werden redundant in mehreren Regionen gespeichert, und zwar mit automatischen Prüfsummen, um die Integrität der Daten zu gewährleisten. Snapshots werden standardmäßig inkrementell erstellt, sodass sie weniger Speicherplatz benötigen und 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 Einzelheiten des Failover-Mechanismus hängen von der verwendeten Datenbank ab. Sie können eine Beobachterinstanz einrichten, um Ausfälle 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, die Sie für die Implementierung eines Failovers für PostgreSQL-Datenbanken verwenden 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 zum Optimieren der Kosten für die Einrichtung und den Betrieb einer multiregionalen Google Cloud-Topologie, die Sie mit 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ät freizugeben. 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 horizontal auf die angegebene Zielgröße hochskalieren (d. h. VMs erstellen), bis die erforderliche Kapazität wieder verfügbar ist.

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 Cloud migrieren, 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 Cloud verwenden. 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 Überlegungen zu Kosten

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

Operative Effizienz

In diesem Abschnitt werden die Faktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur berücksichtigen sollten, um eine multiregionale Google Cloud-Topologie zu entwerfen und zu erstellen, die Sie effizient verwenden können.

Aktualisierungen der VM-Konfiguration

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

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-Architektur-Framework: Operative Exzellenz beschrieben werden.

Leistungsoptimierung

In diesem Abschnitt werden die Faktoren beschrieben, die Sie beim Verwenden dieser Referenzarchitektur berücksichtigen sollten, um eine multiregionale Topologie in Google Cloud zu entwerfen und zu erstellen, die den Leistungsanforderungen Ihrer Arbeitslasten entspricht.

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.

VM-Maschinentypen

Compute Engine bietet eine breite Palette vordefinierter und anpassbarer Maschinentypen, aus denen Sie abhängig von Ihren Kosten- und Leistungsanforderungen auswählen können. Die Maschinentypen sind in Maschinenserien und Familien gruppiert. Die folgende Tabelle enthält eine Zusammenfassung der empfohlenen Maschinenfamilien und -serien für verschiedene Arbeitslasttypen:

Anforderung Empfohlene Maschinenfamilie Beispielmaschinenserie
Bestes Preis-Leistungs-Verhältnis für eine Vielzahl von Arbeitslasten Maschinenfamilie für allgemeine Zwecke C3, C3D, E2, N2, N2D, Tau T2D, Tau T2A
Höchste Leistung pro Kern und für rechenintensive Arbeitslasten optimiert Computing-optimierte Maschinenfamilie C2, C2D, H3
Hohes Verhältnis von Arbeitsspeicher zu vCPUs für arbeitsspeicherintensive Arbeitslasten Speicheroptimierte Maschinenfamilie M3, M2, M1
GPUs für massiv parallelisierte Arbeitslasten Beschleunigungsoptimierte Maschinenfamilie A2, G2

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 Leistung Ihrer Arbeitslasten optimieren. Sie können zwischen den folgenden Stufen wählen:

  • Die Premium-Stufe verwendet das äußerst zuverlässige globale Backbone von Google, um einen minimalen Paketverlust und eine minimale Latenz zu erreichen. Der Traffic betritt und verlässt das Google-Netzwerk an einem globalen Edge-Point of Presence (PoP), der dem ISP Ihres Endnutzers am nächsten ist. Wir empfehlen die Premiumstufe als Standardstufe, um eine optimale Leistung zu erzielen. Die Premium-Stufe unterstützt sowohl regionale externe als auch globale externe IP-Adressen für VMs und Load-Balancer.
  • Die Standardstufe ist nur für Ressourcen verfügbar, die regionale externe IP-Adressen verwenden. Der Traffic betritt und verlässt das Google-Netzwerk an einem Edge-PoP, der der Region am nächsten ist, in der Ihre Google Cloud-Arbeitslast ausgeführt wird. Die Preise für die Standardstufe sind niedriger als die Premiumstufe. Die Standardstufe eignet sich für Traffic, der nicht empfindlich auf Paketverluste reagiert und keine niedrigen Latenzanforderungen hat.

Caching

Wenn Ihre Anwendung statische Website-Assets bereitstellt und Ihre Architektur einen globalen externen Anwendungs-Load-Balancer enthält (wie in Abbildung 1 gezeigt), können Sie Cloud CDN verwenden, um statische Inhalten, auf die regelmäßig zugegriffen wird, näher an Ihren Nutzern zu speichern. Mit Cloud CDN können Sie die Leistung für die Nutzer verbessern, die Nutzung der Infrastrukturressource im Back-End reduzieren und die Kosten für die Netzwerkbereitstellung 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-Architektur-Framework: Leistungsoptimierung bereitgestellt werden.

Wie geht es weiter?

Beitragende

Autor: Kumar Dhanagopal | Cross-product Solution Developer

Weitere Beitragende: