Globale Bereitstellung mit Compute Engine und Spanner

Last reviewed 2024-05-12 UTC

In diesem Dokument wird eine Referenzarchitektur für eine mehrschichtige Anwendung bereitgestellt, die auf Compute Engine-VMs und Spanner in einer globalen Topologie in Google Cloud ausgeführt wird. Das Dokument enthält auch eine Anleitung zum Erstellen einer Architektur, die andere Google Cloud-Infrastrukturdienste verwendet. Es werden die Designfaktoren beschrieben, die Sie beim Erstellen einer globalen Architektur für Ihre Cloudanwendungen berücksichtigen sollten. Die Zielgruppe für dieses Dokument sind Cloud-Architekten.

Diese Architektur ist am Archetyp für globale Bereitstellungen ausgerichtet. Wir empfehlen diesen Archetyp für Anwendungen, die Nutzer auf der ganzen Welt ausführen und eine hohe Verfügbarkeit und Robustheit bei Ausfällen in mehreren Regionen benötigen. Diese Architektur unterstützt eine elastische Skalierung auf Netzwerk-, Anwendungs- und Datenbankebene. Sie können die Kosten an die Nutzung anpassen, ohne Kompromisse bei Leistung, Verfügbarkeit oder Skalierbarkeit einzugehen.

Architektur

Das folgende Diagramm zeigt eine Architektur für eine Anwendung, die auf einer Infrastruktur ausgeführt wird, die global auf mehrere Google Cloud-Regionen verteilt ist.

Architektur für globale Bereitstellungen mit Compute Engine und Spanner

In dieser Architektur verteilt ein globaler Load-Balancer eingehende Anfragen an Webserver in geeigneten Regionen abhängig von deren Verfügbarkeit, Kapazität und Nähe zur Quelle des Traffics. Eine regionenübergreifende interne Lastenausgleichsschicht übernimmt die Verteilung des Traffics von den Webservern zu den entsprechenden Anwendungsservern, basierend auf deren Verfügbarkeit und Kapazität. Die Anwendungsserver schreiben Daten in eine synchron replizierte Datenbank, die in allen Regionen verfügbar ist, und lesen daraus.

Die Architektur umfasst die folgenden Google Cloud-Ressourcen:

Komponente Zweck
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, aber der Load Balancer ist 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 Application Load Balancer oder einen globalen externen Proxy-Network Load Balancer verwenden. Weitere Informationen finden Sie unter Load Balancer auswählen.

Zum Schutz Ihrer Anwendung vor externen Bedrohungen wie DDoS-Angriffen (Distributed Denial-of-Service) und Cross-Site-Scripting (XSS) können Sie die Sicherheitsrichtlinien von Google Cloud Armor verwenden.
Regionale verwaltete Instanzgruppen (MIGs) für die Webebene

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

Regionsübergreifende interne Load-Balancing-Ebene

Interne Load Balancer mit regionenübergreifenden Backends verarbeiten die Verteilung des Traffics von den Webebenen-VMs in einer beliebigen Region zu den VMs der Anwendungsebene in allen Regionen.

Je nach Ihren Anforderungen können Sie einen regionenübergreifenden internen Application Load Balancer oder einen regionenübergreifenden internen Proxy Network 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. Diese MIGs sind die Backends für die Ebene des internen Load-Balancings.

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

Multiregionale Spanner-Instanz

Die Anwendung schreibt Daten in eine multiregionale Spanner-Instanz und liest daraus. Die multiregionale Konfiguration in dieser Architektur umfasst die folgenden Replikate:

  • Vier nicht schreibgeschützte Replikate in separaten Zonen in zwei Regionen.
  • Ein Zeugenreplikat in einer dritten Region.
Virtual Private Cloud (VPC)-Netzwerk und Subnetze

Alle Ressourcen in der Architektur verwenden ein einziges VPC-Netzwerk. Das VPC-Netzwerk hat die folgenden Subnetze:

  • Ein Subnetz in jeder Region für die Webserver-VMs.
  • Ein Subnetz in jeder Region für die Anwendungsserver-VMs.
  • (Nicht im Architekturdiagramm gezeigt) Ein Nur-Proxy-Subnetz in jeder Region für den regionenübergreifenden internen Load Balancer.

Anstatt ein einzelnes VPC-Netzwerk zu verwenden, können Sie in jeder Region ein separates VPC-Netzwerk erstellen und die Netzwerke über Network Connectivity Center verbinden.

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
  • Spanner: Ein hoch skalierbarer, global konsistenter, relationaler Datenbankdienst.

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, Kosten, operative Effizienz und Leistung erfüllt.

Systemdesign

Dieser Abschnitt enthält eine Anleitung zur Auswahl von Google Cloud-Regionen für Ihre globale 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:

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 Geografische Zonen und Regionen auswählen im Google Cloud-Architektur-Framework. #

Computing-Dienste

Die Referenzarchitektur in diesem Dokument verwendet Compute Engine-VMs für die Web- und Anwendungsstufe. Je nach 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 dargestellte Architektur verwendet regionale Persistent Disk-Volumes für die VMs. Regionale Persistent Disk-Volumes ermöglichen die synchrone Replikation von Daten über zwei Zonen innerhalb einer Region. Daten auf Persistent Disk-Volumes werden nicht über Regionen hinweg repliziert.

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 dualregionale Buckets können Sie die Turboreplikation verwenden, die eine schnellere Replikation über Regionen hinweg gewährleistet. 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 in einer Filestore Enterprise-Instanz gespeicherten Dateien 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.

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 Spanner, eine vollständig verwaltete, horizontal skalierbare, global verteilte und synchron replizierte Datenbank. Wir empfehlen eine multiregionale Spanner-Konfiguration für geschäftskritische Bereitstellungen, die eine strikte regionenübergreifende Konsistenz erfordern. Spanner unterstützt die synchrone regionenübergreifende Replikation ohne Ausfallzeiten für Failover, Wartung oder Größenanpassung.

Informationen zu anderen verwalteten Datenbankdiensten, die Sie je nach Ihren Anforderungen auswählen können, finden Sie unter Google Cloud-Datenbanken. Berücksichtigen Sie bei der Auswahl und Konfigurierung 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.

Optionen für externes Load Balancing

Eine Architektur, die einen globalen externen Load Balancer verwendet, wie die Architektur in diesem Dokument, unterstützt bestimmte Features, mit denen Sie die Zuverlässigkeit Ihrer Bereitstellungen verbessern können. Wenn Sie beispielsweise den globalen externen Application Load Balancer verwenden, können Sie das Edge-Caching mit Cloud CDN implementieren.

Wenn Ihre Anwendung erfordert, dass Transport Layer Security (TLS) in einer bestimmten Region beendet wird oder wenn Sie Inhalte aus bestimmten Regionen bereitstellen müssen, können Sie regionale Load Balancer mit Cloud DNS verwenden, um Traffic in verschiedene Regionen weiterzuleiten. Informationen zu den Unterschieden zwischen regionalen und globalen Load Balancern finden Sie in der folgenden Dokumentation:

Sicherheit und Compliance

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

Schutz vor Bedrohungen

Zum Schutz Ihrer Anwendung vor Bedrohungen wie DDoS-Angriffen und XSS können Sie die Google Cloud Armor-Sicherheitsrichtlinien 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 und die Webebene 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.

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

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. Für Google Cloud-Organisationen, die vor dem 3. Mai 2024 erstellt wurden, wird diesem Standarddienstkonto 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 mithilfe 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“.

Weitere Sicherheitsaspekte

Beachten Sie beim Erstellen der Architektur für Ihre Arbeitslast die Best Practices und Empfehlungen zur Sicherheit auf Plattformebene, die im Unternehmensgrundlagen-Blueprint 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 eine globale Bereitstellung in Google Cloud berücksichtigen sollten.

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

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 verfügbar ist, wenn dies für das MIG-Autoscaling 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.

Nichtflüchtiger Speicherstatus

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 zeitaufwendige Datenverschiebungen oder Vorbereitungsaktivitäten zu erledigen.

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:

  • Mit Standard-Snapshots können Sie den Zustand von Persistent Disk-Volumes zu einem bestimmten Zeitpunkt 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.

Mit dem Feature zum Sichern und Wiederherstellen in Spanner können Sie Daten vor Datenbeschädigungen durch Operatorfehler und Anwendungsprobleme schützen. Weitere Informationen finden Sie unter Sicherung und Wiederherstellung in Spanner – Übersicht.

Datenbankzuverlässigkeit

Daten, die in einer multiregionalen Spanner-Instanz gespeichert sind, werden synchron über mehrere Regionen hinweg repliziert. Die im vorherigen Architekturdiagramm gezeigte Spanner-Konfiguration enthält die folgenden Replikate:

  • Vier nicht schreibgeschützte Replikate in separaten Zonen in zwei Regionen.
  • Ein Zeugenreplikat in einer dritten Region.

Ein Schreibvorgang in eine multiregionale Spanner-Instanz wird bestätigt, wenn mindestens drei Replikate – in separaten Zonen in zwei Regionen – den Vorgang übergeben haben. Wenn eine Zone oder Region ausfällt, hat Spanner Zugriff auf alle Daten, einschließlich der Daten aus den letzten Schreibvorgängen, und verarbeitet weiterhin Lese- und Schreibanfragen.

Spanner verwendet nicht aggregierten Speicher, bei dem die Rechen- und Speicherressourcen entkoppelt sind. Sie müssen keine Daten verschieben, wenn Sie Rechenkapazität für Hochverfügbarkeit oder Skalierung hinzufügen. Die neuen Rechenressourcen erhalten bei Bedarf Daten vom nächstgelegenen Colossus-Knoten. Dadurch werden Failover und Skalierung schneller und weniger riskant.

Spanner verfügt mit externer Konsistenz, die eine strengere Eigenschaft als die Serialisierbarkeit für Transaktionsverarbeitungssysteme ist. Weitere Informationen nachstehend:

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 globalen Google Cloud-Topologie, die Sie mithilfe dieser Referenzarchitektur erstellen.

VM-Maschinentypen

Damit Sie die Auslastung Ihrer VM-Ressourcen 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.

Datenbankkosten

Spanner sorgt dafür, dass die Datenbankkosten vorhersehbar sind. Die von Ihnen angegebene Rechenkapazität (Anzahl der Knoten oder Verarbeitungseinheiten) bestimmt die Speicherkapazität. Der Lese- und Schreibdurchsatz wird linear mit der Rechenkapazität skaliert. Sie zahlen nur für die tatsächliche Nutzung. Wenn Sie die Kosten an die Anforderungen Ihrer Arbeitslast anpassen müssen, können Sie die Größe der Spanner-Instanz anpassen.

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 Kostengesichtspunkte

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 zum Entwerfen und Erstellen einer globalen 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 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.

Migration zu Spanner

Sie können Ihre Daten aus anderen Datenbanken wie MySQL, SQL Server und Oracle Database zu Spanner migrieren. Der Migrationsprozess hängt von Faktoren wie der Quelldatenbank, der Größe Ihrer Daten, Einschränkungen für Ausfallzeiten und der Komplexität des Anwendungscodes ab. Damit Sie die Migration zu Spanner effizient planen und implementieren können, stellen wir Ihnen eine Reihe von Tools von Google Cloud und Drittanbietern zur Verfügung. Weitere Informationen finden Sie unter Übersicht über die Migration.

Datenbankverwaltung

Mit Spanner müssen Sie keine Replikation oder ein Failover konfigurieren oder überwachen. Synchrone Replikation und automatisches Failover sind integriert. Bei Ihrer Anwendung treten keine Ausfallzeiten für Datenbankwartung und Failover auf. Zur weiteren Reduzierung der operativen Komplexität können Sie Autoscaling konfigurieren. Wenn das Autoscaling aktiviert ist, müssen Sie die Instanzgröße nicht manuell überwachen und skalieren.

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 berücksichtigen sollten, wenn Sie diese Referenzarchitektur zum Entwerfen und Erstellen einer globalen Topologie in Google 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.

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 für verschiedene Arbeitslasttypen:

Anforderung Empfohlene Maschinenfamilie
Bestes Preis-Leistungs-Verhältnis für eine Vielzahl von Arbeitslasten Maschinenfamilie für allgemeine Zwecke
Höchste Leistung pro Kern und für rechenintensive Arbeitslasten optimiert Computing-optimierte Maschinenfamilie
Hohes Verhältnis von Arbeitsspeicher zu vCPUs für arbeitsspeicherintensive Arbeitslasten Speicheroptimierte Maschinenfamilie
GPUs für extrem parallelisierte Arbeitslasten Beschleunigungsoptimierte Maschinenfamilie
Geringe Kernauslastung und hohe Speicherdichte Speicheroptimierte Maschinenfamilie

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. Je nach Ihren Anforderungen können Sie die Premium- oder die Standardstufe auswählen.

Die Architektur in diesem Dokument verwendet einen globalen externen Load-Balancer mit einer externen IP-Adresse und Back-Ends in mehreren Regionen. Für diese Architektur müssen Sie die Premium-Stufe verwenden, die den zuverlässigen globalen Backbone von Google verwendet, um einen minimalen Paketverlust und eine minimale Latenz zu erreichen.

Wenn Sie regionale externe Load-Balancer verwenden und Traffic über Cloud DNS an Regionen weiterleiten, können Sie je nach Ihren Anforderungen Premium- oder Standardstufe auswählen. 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.

Spanner-Leistung

Wenn Sie eine Spanner-Instanz bereitstellen, geben Sie die Rechenkapazität der Instanz in Bezug auf die Anzahl der Knoten oder Verarbeitungseinheiten an. Überwachen Sie die Ressourcennutzung Ihrer Spanner-Instanz und skalieren Sie die Kapazität basierend auf der erwarteten Last und den Leistungsanforderungen Ihrer Anwendung. Sie können die Kapazität einer Spanner-Instanz manuell oder automatisch skalieren. Weitere Informationen finden Sie unter Autoscaling.

Bei einer multiregionalen Konfiguration repliziert Spanner Daten synchron über mehrere Regionen hinweg. Diese Replikation ermöglicht Lesevorgänge mit niedriger Latenz von mehreren Standorten aus. Dabei muss die Latenz bei Schreibvorgängen höher sein, da die Quorumreplikate auf mehrere Regionen verteilt sind. Spanner verwendet Leader-fähiges Routing (standardmäßig aktiviert), um die Latenz für Lese-Schreib-Transaktionen in einer multiregionalen Konfiguration zu minimieren.

Empfehlungen zur Optimierung der Leistung Ihrer Spanner-Instanz und -Datenbanken finden Sie in der folgenden Dokumentation:

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 häufig aufgerufene statische Inhalte näher an Ihren Nutzern im Cache 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-Architektur-Framework: Leistungsoptimierung bereitgestellt werden.

Wie geht es weiter?

Beitragende

Autor: Kumar Dhanagopal | Cross-product Solution Developer

Weitere Beitragende: