Bereitstellung in einer Zone in Compute Engine

Last reviewed 2024-02-08 UTC

In diesem Dokument wird eine Referenzarchitektur für eine mehrschichtige Anwendung bereitgestellt, die auf Compute Engine-VMs in einer einzelnen Zone in Google Cloud ausgefü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 zonalen Architektur für Ihre Cloud-Anwendungen berücksichtigen sollten. Die Zielgruppe für dieses Dokument sind Cloud-Architekten.

Architektur

Das folgende Diagramm zeigt eine Architektur für eine Anwendung, die in einer einzelnen Google Cloud-Zone ausgeführt wird. Diese Architektur ist am Archetyp für zonale Bereitstellungen in Google Cloud ausgerichtet.

Architektur in einer einzelnen Zone mit Compute Engine

Die Architektur basiert auf dem Cloud-Modell Infrastructure as a Service (IaaS). Sie stellen die erforderlichen Infrastrukturressourcen (Computing, Netzwerk und Speicher) in Google Cloud bereit. Sie behalten die volle Kontrolle über die Infrastruktur 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 Zweck
Regionaler externer Load Balancer

Der regionale externe Load-Balancer empfängt und verteilt Nutzeranfragen an die Webstufen-VMs.

Verwenden Sie je nach Traffictyp und anderen Anforderungen einen geeigneten Load-Balancer-Typ. Wenn das Backend beispielsweise aus Webservern besteht (wie in der vorherigen Architektur dargestellt), verwenden Sie einen Application Load Balancer, um HTTP(S)-Traffic weiterzuleiten. Verwenden Sie für das Load-Balancing von TCP-Traffic einen Network Load Balancer. Weitere Informationen finden Sie unter Load-Balancer auswählen.

Zonale verwaltete Instanzgruppe (Managed Instance Group, MIG) für die Webebene Die Webebene der Anwendung wird auf Compute Engine-VMs bereitgestellt, die Teil einer zonalen MIG sind. Die MIG ist das Backend für den regionalen externen Load-Balancer. Jede VM in der MIG hostet eine unabhängige Instanz der Webebene der Anwendung.
Regionaler interner Load Balancer

Der regionale interne Load-Balancer verteilt den Traffic von den VMs der Webebene auf die VMs der Anwendungsebene.

Je nach Ihren Anforderungen können Sie einen regionalen internen Application Load Balancer oder einen Network Load Balancer verwenden. Weitere Informationen finden Sie unter Load-Balancer auswählen.

Zonale MIG für die Anwendungsebene Die Anwendungsebene wird auf Compute Engine-VMs bereitgestellt, die Teil einer zonale MIG sind, die das Backend für den internen Load-Balancer ist. Jede VM in der MIG hostet eine unabhängige Instanz der Anwendungsebene.
Auf einer Compute Engine-VM bereitgestellte Datenbank eines Drittanbieters

Die Architektur in diesem Dokument zeigt eine Datenbank eines Drittanbieters (z. B. PostgreSQL), die auf einer Compute Engine-VM bereitgestellt wird. Sie können eine Standby-Datenbank in einer anderen Zone bereitstellen. Die Datenbankreplikation 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 Drittanbieterdatenbank vermeiden und integrierte Hochverfügbarkeitsfeatures (HA) nutzen, indem Sie einen vollständig verwalteten Datenbankdienst wie Cloud SQL oder AlloyDB for PostgreSQL verwenden. Weitere Informationen zu Optionen für verwaltete Datenbanken finden Sie unter Datenbankdienste.

Virtual Private Cloud-Netzwerk und Subnetz

Alle Google Cloud-Ressourcen in der Architektur verwenden ein einzelnes VPC-Netzwerk und ein Subnetz.

Je nach Ihren Anforderungen können Sie eine Architektur erstellen, die mehrere VPC-Netzwerke oder mehrere Subnetze verwendet. Weitere Informationen finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen in „Best Practices und Referenzarchitekturen für das VPC-Design“.

Regionaler Cloud Storage-Bucket

Anwendungs- und Datenbanksicherungen werden in einem regionalen Cloud Storage-Bucket gespeichert. Wenn ein zonaler Ausfall auftritt, gehen Ihre Anwendung und Daten nicht verloren.

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 Cloud zugegriffen 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 VPC.

Anwendungsfälle

In diesem Abschnitt werden Anwendungsfälle beschrieben, in denen sich die Bereitstellung in einer einzelnen Zone in Compute Engine eignet.

  • Cloud-Entwicklung und -Tests: Sie können eine Bereitstellungsarchitektur für eine einzelne Zone verwenden, um eine kostengünstige Cloud-Umgebung für Entwicklung und Tests zu erstellen.
  • Anwendungen, die keine HA benötigen: Eine Architektur mit einer einzelnen Zone kann für Anwendungen ausreichend sein, die Ausfallzeiten aufgrund von Infrastrukturausfällen tolerieren können.
  • Kostengünstiges Netzwerk mit niedriger Latenz zwischen Anwendungskomponenten: Eine Einzelzonenarchitektur eignet sich möglicherweise gut für Anwendungen wie Batch-Computing, die Netzwerkverbindungen mit niedriger Latenz und hoher Bandbreite an ihren Rechenknoten benötigen. Bei einer Bereitstellung in einer einzelnen Zone gibt es keinen zonenübergreifenden Netzwerktraffic und keine Kosten für zonenübergreifenden Traffic.
  • Migration von Standardarbeitslasten: Die Architektur für zonale Bereitstellungen bietet einen einfachen Cloud-Migrationspfad für lokale Standardanwendungen, bei denen Sie keine Kontrolle über den Code haben oder die keine Architekturen unterstützen können, die über eine einfache Aktiv-Passiv-Topologie hinausgehen.
  • Software mit Lizenzbeschränkung ausführen: Eine Einzelzonenarchitektur eignet sich möglicherweise gut für lizenzbeschränkte Systeme, in denen das Ausführen mehrerer Instanzen gleichzeitig zu teuer oder nicht zu teuer ist. zulässig.

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 von Google Cloud-Regionen und -Zonen für Ihre zonale Bereitstellung sowie zur Auswahl geeigneter Google Cloud-Dienste.

Auswahl der Region

Berücksichtigen Sie bei der Auswahl einer Google Cloud-Region und -Zone für Ihre Anwendungen die folgenden Faktoren und Anforderungen:

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

Einige dieser Faktoren und Anforderungen können Kompromisse beinhalten. Beispielsweise hat die kostengünstigste Region möglicherweise nicht den geringsten CO2-Fußabdruck.

Computing-Dienste

In der Referenzarchitektur in diesem Dokument werden Compute Engine-VMs für alle Ebenen der Anwendung verwendet. Die Designanleitung in diesem Dokument gilt speziell für Compute Engine, sofern nicht anders angegeben.

Je nach Anforderungen Ihrer Anwendung können Sie aus den folgenden anderen Google Cloud-Computing-Diensten auswählen. Die Designanleitung für diese Dienste wird in diesem Dokument nicht behandelt.

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 Anwendungen in Google Cloud hosten.

Speicherdienste

Die in diesem Dokument dargestellte Architektur verwendet zonale Persistent Disk-Volumes für alle Stufen. Für einen langlebigeren nichtflüchtigen Speicher können Sie regionale Persistent Disk-Volumes verwenden, die eine synchrone Replikation von Daten über zwei Zonen innerhalb einer Region ermöglichen.

Für kostengünstigen Speicher, der in den Zonen einer Region redundant ist, können Sie regionale Cloud Storage-Buckets verwenden.

Sie können ein Filestore 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 Arbeitslasten die funktionalen Eigenschaften, Anforderungen an die Robustheit, 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 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.

Sicherheit und Compliance

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

Schutz vor externen Bedrohungen

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. Die Sicherheitsrichtlinien werden im Perimeter erzwungen, d. h. bevor der Traffic die Webebene erreicht. 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. 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, die nur interne IP-Adressen haben, wie die Compute Engine-VMs in dieser Referenzarchitektur, zu ermöglichen.

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

Netzwerksicherheit

Zur Steuerung des Netzwerk-Traffics zwischen den Ressourcen in der Architektur müssen Sie geeignete Cloud Next Generation-Firewallregeln einrichten. Mit jeder Firewallregel können Sie den Traffic anhand von Parametern wie Protokoll, IP-Adresse und Port steuern. Sie können beispielsweise eine Firewallregel konfigurieren, um TCP-Traffic von den Webserver-VMs zu einem bestimmten Port der Datenbank-VMs zuzulassen und den gesamten anderen Traffic zu blockieren.

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 Ihre zonale Bereitstellungen in Google Cloud berücksichtigen sollten.

Ausfälle der Infrastruktur

Wenn in einer Bereitstellungsarchitektur mit einer einzelnen Zone eine Komponente im Infrastrukturstack ausfällt, kann die Anwendung Anfragen verarbeiten, wenn jede Stufe mindestens eine funktionierende Komponente mit ausreichender Kapazität enthält. 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, erstellen die MIG die VM automatisch neu. Wenn die Datenbank abstürzt, müssen Sie die zweite Datenbank manuell aktivieren und die Anwendungsserverinstanzen aktualisieren, um eine Verbindung zur Datenbank herzustellen.

Ein Zonenausfall oder ein Ausfall der Region wirkt sich auf alle Compute Engine-VMs in einer Bereitstellung in einer einzelnen Zone aus. Ein Zonenausfall hat keinen Einfluss auf den Load-Balancer in dieser Architektur, da es sich um eine regionale Ressource handelt. Der Load-Balancer kann den Traffic jedoch nicht verteilen, da keine Back-Ends verfügbar sind. Wenn ein zonaler oder regionaler Ausfall auftritt, müssen Sie warten, bis Google den Ausfall behoben hat, und dann prüfen, ob die Anwendung wie erwartet funktioniert.

Sie können Ausfallzeiten durch zonale oder regionale Ausfälle reduzieren, indem Sie ein passives (Failover-)Replikat des Infrastruktur-Stacks in einer anderen Google Cloud-Zone oder -Region verwalten. Wenn ein Ausfall in der primären Zone auftritt, können Sie den Stack in der Failover-Zone oder -Region aktivieren und DNS-Routingrichtlinien verwenden, um den Traffic an den Load Balancer in Die Failover-Zone oder -Region zu leiten.

Für Anwendungen, die gegen zonale oder regionale Ausfälle resistent sein müssen, sollten Sie eine regionale oder multiregionale Architektur verwenden. Sehen Sie sich die folgenden Referenzarchitekturen an:

MIG-Autoscaling

Mit der Autoscaling-Funktion zustandsloser MIGs können Sie die Verfügbarkeit und Leistung von Anwendungen auf vorhersehbaren Leveln aufrechterhalten. Zustandsorientierte MIGs können nicht automatisch skaliert werden.

Zum Steuern des Autoscaling-Verhaltens Ihrer MIGs können Sie Zielauslastungsmesswerte angeben, z. B. die durchschnittliche CPU-Auslastung. Sie können auch zeitplanbasiertes Autoscaling konfigurieren. Weitere Informationen finden Sie unter Autoscaling von Instanzgruppen.

MIG-Größenlimit

Standardmäßig kann eine zonale MIG bis zu 1.000 VMs haben. Sie können die Größenbeschränkung einer MIG auf 2.000 VMs erhöhen.

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 Architektur, die in diesem Dokument beschrieben wird, werden die Anwendungsebene und die Webebene auf Compute Engine-VMs in einer einzelnen Zone ausgeführt. Sie können eine Richtlinie für gestreute Platzierung erstellen und auf die MIG-Vorlage anwenden, um die Stabilität der Architektur zu verbessern. Wenn die MIG VMs erstellt, werden die VMs auf verschiedenen physischen Servern (Hosts) platziert, sodass Ihre VMs gegen Ausfälle einzelner Hosts geschützt sind. 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. Für reservierte Ressourcen fallen auch dann Gebühren an, wenn die Ressourcen nicht bereitgestellt oder verwendet werden. 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 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.

Wenn Sie einen verwalteten Datenbankdienst wie Cloud SQL verwenden, werden Sicherungen automatisch basierend auf der von Ihnen definierten Aufbewahrungsrichtlinie erstellt. Sie können die Sicherungsstrategie durch zusätzliche logische Sicherungen ergänzen, um rechtliche, Workflow- oder geschäftliche Anforderungen zu erfüllen.

Wenn Sie die Datenbank eines Drittanbieters verwenden und Datenbanksicherungen und Transaktionslogs speichern müssen, können Sie regionale Cloud Storage-Buckets verwenden. Regionale Cloud Storage-Buckets bieten kostengünstigen Sicherungsspeicher, der zonenübergreifend redundant ist.

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

Wenn Sie einen verwalteten Datenbankdienst wie Cloud SQL in einer Konfiguration für Hochverfügbarkeit verwenden, wechselt Cloud SQL bei einem Ausfall der primären Datenbank automatisch in die Standby-Datenbank. Sie müssen die IP-Adresse für den Datenbankendpunkt nicht ändern. Wenn Sie eine selbstverwaltete Datenbank eines Drittanbieters verwenden, die auf einer Compute Engine-VM bereitgestellt wird, müssen Sie einen internen Load-Balancer oder einen anderen Mechanismus verwenden, damit die Anwendung eine Verbindung zu einer anderen Datenbank herstellen kann, wenn die primäre Datenbank nicht verfügbar ist.

Zum Implementieren des zonenübergreifenden Failovers für eine Datenbank, die auf einer Compute Engine-VM bereitgestellt wird, benötigen Sie einen Mechanismus, der Fehler der primären Datenbank identifiziert, und einen Prozess für das Failover auf die Standby-Datenbank. 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 zonale 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 HA-Anforderungen 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.

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.

Wenn Sie eine Drittanbieterdatenbank wie Microsoft SQL Server auf Compute Engine-VMs bereitstellen, müssen Sie die Lizenzkosten für die Drittanbietersoftware berücksichtigen. Wenn Sie einen verwalteten Datenbankdienst wie Cloud SQL verwenden, sind die Datenbanklizenzkosten in den Gebühren für den Dienst enthalten.

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

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

Anforderung Empfohlene Maschinenfamilie Beispiel für Maschinenserie
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 extrem 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.

VM-Multithreading kann Auswirkungen auf die Lizenzierung für manche Drittanbieter-Software wie Datenbanken haben. Weitere Informationen finden Sie in der Lizenzierungsdokumentation für die Drittanbieter-Software.

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.

  • Die Premium-Stufe verwendet den äußerst zuverlässigen globalen 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 sich in der Nähe Ihres Endnutzers befindet. Wir empfehlen die Verwendung der Premium-Stufe als Standardstufe für eine optimale Leistung.
  • Bei der Standardstufe betritt und verlässt der Traffic das Google-Netzwerk an einem Edge-PoP, der dem Google Cloud-Standort am nächsten ist, an dem Ihre 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.

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: