Microsoft SQL Server-AlwaysOn-Verfügbarkeitsgruppe in Google Cloud

Last reviewed 2026-08-12 UTC

Dieses Dokument enthält eine Referenzarchitektur für die Bereitstellung von Microsoft SQL Server-Datenbanken mit hoher Verfügbarkeit (HA) in Google Cloud mit einer Always On-Verfügbarkeitsgruppe. Das Dokument enthält auch Designüberlegungen für Hochverfügbarkeit und Notfallwiederherstellung, Bereitstellungsoptionen, Automatisierungsempfehlungen und Anleitungen für Backup und DR-Vorgänge. Dieses Dokument richtet sich an technische Experten, die Google Cloud als Plattform für die Ausführung von SQL Server-Datenbanken in Betracht ziehen. Dabei werden Grundkenntnisse zu Compute Engine und SQL Server vorausgesetzt.

Google Cloud bietet kostengünstige, zuverlässige, sichere und leistungsstarke Lösungen für die Ausführung von SQL Server-Datenbanken. Eine Übersicht über die unterstützten SQL Server-Lösungen in Google Cloudfinden Sie unter SQL Server auf Google Cloud.

Wenn Sie eine Nicht-Entwicklungsbereitstellung von SQL Server in Google Cloudbetreiben möchten, verwenden Sie eine der folgenden Lizenzierungsoptionen:

  • Eigene Lizenzen verwenden (Bring Your Own License, BYOL): Sie können Ihre vorhandenen Microsoft SQL Server-Lizenzen in Google Cloudverwenden. Sie müssen entweder Knoten für einzelne Mandanten oder Software Assurance mit License Mobility verwenden.

  • On-Demand-Lizenzen verwenden: Verwenden Sie vordefinierte SQL Server-Images in Google Cloud und zahlen Sie eine Gebühr, die die Compute-Kosten und die Microsoft-Lizenzkosten umfasst. Google kümmert sich um die Microsoft-Lizenzvereinbarungen und die Abrechnung.

Im Abschnitt Bereitstellung dieses Dokuments finden Sie Ressourcen, die Ihnen bei der Bereitstellung dieser Referenzarchitektur helfen.

Architektur

Das folgende Diagramm zeigt eine Referenzarchitektur für eine SQL Server-Bereitstellung mit hoher Verfügbarkeit in Google Cloud:

Eine Architektur, die eine SQL Server-Bereitstellung mit einer Always On-Verfügbarkeitsgruppe zeigt, die Compute Engine-VMs in verschiedenen Zonen und Regionen umfasst.

Die vorherige Architektur zeigt eine Always On-Verfügbarkeitsgruppe mit drei Knoten in einem Windows Server-Failover-Cluster (WSFC). Jeder Knoten ist eine Compute Engine-VM, auf der SQL Server ausgeführt wird.

Eine Always On-Verfügbarkeitsgruppe ist ein branchenübliches Bereitstellungsmuster, mit dem Zuverlässigkeitsziele für unternehmenskritische SQL Server-Datenbanken erreicht werden können. AlwaysOn-Verfügbarkeitsgruppen bieten lokale Hochverfügbarkeit (Failover innerhalb einer Region) und regionsübergreifendes Failover für die Notfallwiederherstellung. Dieses Bereitstellungsmuster ist eine Alternative zur Datenbankspiegelung für Unternehmen. Eine Always On-Verfügbarkeitsgruppe bietet die folgenden Vorteile:

  • Keine speziellen Infrastrukturkomponenten erforderlich: SQL Server verwaltet die Replikation für alle konfigurierten Datenbankreplikate.
  • Konfiguration mit dem höchsten SLA für SQL Server: RTO (Recovery Time Objective) von weniger als einer Minute und RPO (Recovery Point Objective) von nahezu null.
  • Schreibgeschützte Arbeitslasten auf sekundäre Replikate auslagern: Sie können Ihre Bereitstellung effizient für Analysen und andere gängige Anwendungsfälle skalieren.
  • Knoten in zusätzlichen Regionen für die Notfallwiederherstellung: Stellen Sie ein primäres Replikat und bis zu acht sekundäre Replikate bereit.
  • Bereitstellung unter Windows und Linux möglich: Sie können ein Drittanbietertool wie Pacemaker als Clustermanager für Linux-Bereitstellungen verwenden.

In der vorherigen Architektur befinden sich die primären und sekundären SQL Server-Knoten in separaten Zonen innerhalb einer Region. Der DR-Knoten befindet sich in einer geografisch entfernten Region. Daten vom primären Knoten werden synchron auf den sekundären Knoten und asynchron auf den DR-Knoten repliziert.

Um Traffic von der Anwendungsschicht auf die primären und sekundären Datenbankknoten in einer Region zu verteilen, können Sie einen der folgenden Ansätze verwenden:

Verwendete Produkte

Die Architektur verwendet die folgenden Google Cloud und Microsoft-Produkte und -Komponenten.

Google Cloud Produkte

  • Compute Engine: Ein sicherer und anpassbarer Computing-Dienst, mit dem Sie virtuelle Maschinen in der Infrastruktur von Google erstellen und ausführen können.
  • Google Cloud Hyperdisk: Ein Netzwerkspeicherdienst, mit dem Sie Blockspeichervolumes mit konfigurierbarer und vorhersehbarer Leistung bereitstellen und dynamisch skalieren können.
  • 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.
  • Cloud Load Balancing: Ein Portfolio von leistungsstarken, skalierbaren, globalen und regionalen Load-Balancern

Microsoft-Produkte und ‑Komponenten

Die folgenden Komponenten sind auf den SQL Server-Knoten enthalten oder aktiviert:

  • Windows Server (Version 2019 oder höher).
  • WSFC: Eine Gruppe von SQL Server-Instanzen, die auf mehreren Windows Server-Clusterknoten oder in mehreren Subnetzen installiert sind.
  • Always On-Verfügbarkeitsgruppe: Eine HA- und DR-Alternative auf Unternehmensniveau zur Datenbankspiegelung.
  • Listener für Verfügbarkeitsgruppen: Ein virtueller Netzwerkname (Virtual Network Name, VNN), den Clients verwenden können, um auf eine Datenbank in einem primären oder sekundären Replikat einer Always On-Verfügbarkeitsgruppe zuzugreifen. Clients müssen den physischen Instanznamen der Replikate nicht kennen. Da der Listener den Traffic weiterleitet, muss der Clientverbindungsstring nach einem Failover nicht geändert werden.

Für die Bereitstellung dieser Architektur sind die folgenden zusätzlichen Komponenten erforderlich:

  • Active Directory Domain Services: Ein Windows Server-Verzeichnisdienst zum Verwalten von Ressourcen, die in einer Domain üblich sind, z. B. Computer, Rollen und Nutzer.
  • DNS: Ein Server, der Domainnamen in die entsprechenden IP-Adressen auflöst.
  • Quorum-Zeuge: Dies kann eine SMB-Dateifreigabe oder eine lokal angehängte freigegebene Festplatte sein.

Designaspekte

In diesem Abschnitt werden Designfaktoren, Best Practices und Designempfehlungen beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine Topologie zu entwickeln, die Ihren Anforderungen an Zuverlässigkeit, operative Effizienz, Sicherheit, Kosten und Leistung entspricht.

Zuverlässigkeit

In diesem Abschnitt werden Designüberlegungen und Empfehlungen zum Erstellen und Betreiben einer zuverlässigen Infrastruktur für Ihre SQL Server-Bereitstellung inGoogle Cloudbeschrieben.

Strategie für Hochverfügbarkeit und Notfallwiederherstellung auswählen

Wenn Sie zuverlässige SQL Server-Datenbanken in Google Cloudbereitstellen möchten, benötigen Sie eine Strategie, die die robuste Infrastruktur von Google Cloud mit den HA- und DR-Funktionen von SQL Server kombiniert. Diese Kombination schützt Ihre Datenbanken vor Fehlern, die von zonalen Ausfällen bis hin zu regionalen Katastrophen reichen.

Berücksichtigen Sie beim Entwerfen der HA- und DR-Strategie für Ihre SQL Server-Bereitstellung die folgenden Faktoren:

  • RPO: Wie viel Datenverlust ist im Falle eines Fehlers akzeptabel?
    • Um einen niedrigen RPO-Wert (nahezu kein Datenverlust) zu erreichen, verwenden Sie eine Always On-Verfügbarkeitsgruppe mit synchroner Replikation.
    • Wenn Sie einen gewissen Datenverlust in Kauf nehmen können, verwenden Sie einen der folgenden Ansätze: asynchrone Replikation, Backup- und DR-Dienst, Sicherung in einem Cloud Storage-Bucket oder Log Shipping.
  • RTO: Wie schnell muss die Datenbank nach einem Fehler wieder betriebsbereit sein?
    • Um ein niedriges RTO zu erreichen, verwenden Sie eine Always On-Verfügbarkeitsgruppe.
    • Wenn eine gewisse Ausfallzeit akzeptabel ist, stellen Sie die Datenbanken aus Sicherungen wieder her oder verwenden Sie die Protokollübertragung mit manuellem Failover.
  • Budget: Berücksichtigen Sie die Kompromisse zwischen Kosten und Zuverlässigkeit.
    • Hohe Kosten, aber zuverlässig: Verwenden Sie eine Always On-Verfügbarkeitsgruppe mit asynchroner Replikation auf zusätzliche Knoten in einer DR-Region. Planen Sie redundante Infrastruktur und Lizenzen ein.
    • Mittlere Kosten: Implementieren Sie die asynchrone Laufwerkreplikation in eine andere Region oder verwenden Sie den Backup and DR Service.
    • Niedrige Kosten, aber lange Wiederherstellungszeit: Sichern Sie die Datenbanken in einem multiregionalen Cloud Storage-Bucket.
  • Arten von Fehlern: Welche Arten von Fehlern müssen Sie behandeln?
    • Um Ausfälle auf Hardware-, Instanz- und Zonenebene zu beheben, können Sie Verfügbarkeitsgruppen verwenden.
    • Um sich von standortweiten Ausfällen oder Katastrophen zu erholen, benötigen Sie eine geografisch verteilte Lösung zur Notfallwiederherstellung wie den Versand von Protokollen oder Always On-Verfügbarkeitsgruppen mit asynchroner Datenbankreplikation.
  • Geschäftskritikalität: Wie wichtig ist die Anwendung für Ihr Unternehmen?
    • Für geschäftskritische Anwendungen ist eine Strategie erforderlich, die ein Höchstmaß an Verfügbarkeit, minimalen Datenverlust und eine schnelle Wiederherstellung bietet.
    • Für weniger kritische Systeme sollten Sie eine Strategie in Betracht ziehen, die von einer akzeptablen Ausfallzeit oder einem gewissen Datenverlust ausgeht.

Verwenden Sie den folgenden Entscheidungsbaum, um eine optimale Zuverlässigkeitsstrategie für Ihre SQL Server-Datenbank auszuwählen. Die Strategieoptionen reichen von einer AlwaysOn-Verfügbarkeitsgruppe, die einen Datenverlust von nahezu null bietet, bis hin zu kostengünstigen Offsite-Sicherungen.

  1. Entsprechen Offsite-Sicherungen Ihrem RPO und RTO?
    • Ja: Verwenden Sie Offsite-Sicherungen oder Log Shipping.
    • Nein: Fahren Sie mit der nächsten Frage fort.
  2. Ist Ihr RTO oder RPO kürzer als eine Minute?
    • Ja (RPO nahe null): Verwenden Sie eine SQL Server Always On-Verfügbarkeitsgruppe mit einem DR-Datenbankreplikat.
    • Nein: Fahren Sie mit der nächsten Frage fort.
  3. Welches RTO haben Sie?
    • Weniger als fünf Minuten: Verwenden Sie eine SQL Server AlwaysOn-Verfügbarkeitsgruppe mit einem asynchronen Festplattenreplikat.
    • Eine Stunde oder mehr: Fahren Sie mit der nächsten Frage fort.
  4. Welches RPO haben Sie?
    • Weniger als zwei Stunden: Verwenden Sie eine SQL Server-AlwaysOn-Verfügbarkeitsgruppe mit dem Backup- und DR-Dienst.
    • Acht Stunden oder mehr: Verwenden Sie Offsite-Sicherungen oder Log Shipping.

Geeignete Sicherungsoptionen auswählen

Wenn Ihre Zuverlässigkeitsstrategie Datenbankbackups umfasst, wählen Sie eine Backupmethode aus, die Ihren Anforderungen entspricht. Google Cloud bietet die folgenden flexiblen und unternehmenstauglichen Optionen zum Sichern von SQL Server-Datenbanken:

  • Direkte Sicherung in einem Cloud Storage-Bucket: Datenbanken können direkt in Cloud Storage gesichert werden. Verwenden Sie dazu den Befehl BACKUP TO URL und den S3-Connector in SQL Server (Version 2022 oder höher). In Produktionsumgebungen können Sie einen HMAC-Zugriffsschlüssel (Hash-based Message Authentication Code) verwenden. Diese Sicherungsoption bietet kostengünstigen Schutz für Datenbanken und Protokolle, ohne dass ein lokaler Zwischenspeicher erforderlich ist.
  • Compute Engine-Sofortsnapshots: Mit Transact-SQL-Freeze-Thaw-Vorgängen (T-SQL) in Kombination mit Compute Engine-Konsistenzgruppen können Sie in weniger als einer Sekunde gleichzeitige Snapshots auf mehreren Laufwerken (z. B. auf Hyperdisk Balanced-Laufwerken) erstellen. Diese Option ermöglicht leistungsstarke Back-ups auf VM-Ebene für Datenbanken mit mehreren Laufwerken und erfordert nur eine minimale Schreibsperre.
  • Backup and DR: Mit Microsoft VSS-Anbietern und Konsistenzgruppen können Sie anwendungskonsistente Snapshots erstellen. Diese Sicherungsoption eignet sich, wenn Sie eine detaillierte PITR (Wiederherstellung zu einem bestimmten Zeitpunkt) für mehrere Datenbanken und die Möglichkeit benötigen, Datenbanken mithilfe von Logs vorwärts zu rollen.
  • Google Cloud NetApp Volumes: Mit der ONTAP-Speicher-Engine können Sie sofortige Snapshots und asynchrone Sicherungen in Remote-Vaults erstellen. Wir empfehlen NetApp Volumes für latenzempfindliche Unternehmensanwendungen, die eine schnelle Ransomware-Abwehr und speichereffiziente Klone erfordern.

Für Multi-Cloud- und Hybridbereitstellungen, die einheitliche Datenschutzrichtlinien erfordern, können Sie ein Drittanbieter-Sicherungsprodukt wie Veeam, Veritas NetBackup oder Cohesity auswählen.

Vorgänge

Um für Hochverfügbarkeit und optimale Leistung von SQL Server-Datenbanken zu sorgen, die auf Compute Engine-VMs bereitgestellt werden, richten Sie mit Cloud Monitoring und Cloud Logging ein umfassendes Monitoring- und Benachrichtigungssystem ein.

  • Messwerte für wichtige Ressourcen wie CPU-Auslastung und Arbeitsspeicherlast kontinuierlich im Blick behalten. Richten Sie Referenzbenachrichtigungen ein, um Engpässe bei Ressourcen zu erkennen, bevor sich die Leistung von Anfragen verschlechtert.
  • Um zu verhindern, dass Datenbankschreibvorgänge angehalten werden, sollten Sie die Festplattenauslastung kontinuierlich beobachten. Überwachen Sie den allgemeinen Dienststatus und richten Sie Benachrichtigungen ein, damit Sie informiert werden, wenn Datenbanken unerwartet beendet werden.
  • Bei Bereitstellungen mit Hochverfügbarkeit sollten Sie alle ungeplanten Failovers im Blick behalten und für vollständige Transparenz bei automatischen Notfallwiederherstellungsereignissen sorgen.
  • Neben der Telemetrie auf Systemebene bietet Google Cloud eine umfangreiche Suite datenbankspezifischer Messwerte wie Grenzwerte für aktive Nutzerverbindungen, Replikationsverzögerung und Transaktionsraten. Anhand dieser Messwerte können Sie die Verfügbarkeit und Leistung Ihrer SQL Server-Datenbanken überwachen.
  • Wenn Sie anwendungsbezogene Fehler wie Deadlocks, Datenbankbeschädigungen und Fehler bei Agent-Jobs direkt aus den SQL Server-Fehlerlogs erfassen möchten, richten Sie benutzerdefinierte logbasierte Benachrichtigungen in Logging ein.

Sicherheit

In diesem Abschnitt werden Designüberlegungen und Empfehlungen zum Entwerfen einer SQL Server-Bereitstellung in Google Cloud beschrieben, die die Sicherheitsanforderungen Ihrer Arbeitslast erfüllt.

Netzwerksicherheit und ‑isolation

  • Um zu verhindern, dass die Datenbanken extern zugänglich sind, stellen Sie die SQL Server-Instanzen mit privaten IP-Adressen in einer VPC bereit. Verwenden Sie den Zugriff auf private Dienste, um Traffic intern weiterzuleiten. So wird sichergestellt, dass Ihr Datenbanktraffic niemals über das öffentliche Internet übertragen wird.
  • Beschränken Sie den Zugriff auf die Datenbanken weiter, indem Sie strenge VPC-Firewallregeln konfigurieren, die Traffic nur von autorisierten Anwendungs-Subnetzen oder bestimmten CIDR-Blöcken zulassen.
  • Um Daten bei der Übertragung vor Abhören und Abfangen zu schützen, sollten Sie verschlüsselte Verbindungen implementieren, indem Sie TLS/SSL für alle Datenbankverbindungen erzwingen.

Verschlüsselung und Schlüsselverwaltung

  • Standardmäßig verwendet Google Cloud von Google verwaltete AES-256-Schlüssel, um alle Daten im Ruhezustand auf Datenbanklaufwerken, in temporären Dateien und in Back-ups automatisch zu verschlüsseln. Um Compliance-Anforderungen zu erfüllen, können Sie die Verschlüsselung auf Datenbankebene mit der Transparent Data Encryption (TDE)-Funktion von SQL Server implementieren.
  • Um die Datenhoheit zu gewährleisten, können Sie kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) im Cloud Key Management Service verwenden. Mit CMEKs haben Sie die vollständige kryptografische Kontrolle. Sie verwalten den Lebenszyklus von Schlüsseln, legen automatische Rotationszeitpläne fest und können den Zugriff auf die Datenbank und ihre Sicherungen bei Bedarf sofort widerrufen.

Authentifizierung und Autorisierung

  • Binden Sie Ihre Datenbank in Microsoft Active Directory ein oder zentralisieren Sie die Identitätsverwaltung für Ihre SQL Server-Datenbanken und andereGoogle Cloud -Ressourcen mit Identity and Access Management (IAM).
  • Nachdem Identitäten eingerichtet wurden, wenden Sie das Prinzip der geringsten Berechtigung an, damit Nutzer und Anwendungsdienstkonten nur die Berechtigungen haben, die für die Ausführung ihrer Funktionen erforderlich sind. Identitäten detaillierten SQL Server-Datenbankrollen zuordnen

Kostenoptimierung

Dieser Abschnitt enthält Anleitungen zur Optimierung der Kosten für die Einrichtung und den Betrieb einer SQL Server-Bereitstellung, die Sie mithilfe dieser Referenzarchitektur erstellen. Die Kostenoptimierung trägt dazu bei, dass die Bereitstellung die Zuverlässigkeits- und Leistungsanforderungen Ihrer Arbeitslast innerhalb Ihres Budgets erfüllt.

Beachten Sie die folgenden Empfehlungen:

  • Gleichzeitiges Multithreading (SMT) deaktivieren: Wenn Sie SMT deaktivieren, können Sie die Anzahl der Kerne, die für Lizenzierungszwecke gemeldet werden, um 50 % reduzieren. Wenn Sie Ihre CPUs um 20% überdimensionieren und dann SMT deaktivieren, können Sie die Lizenzkosten erheblich senken, ohne dass die Leistung darunter leidet. Weitere Informationen finden Sie unter Anzahl der Threads pro Kern festlegen.
  • SQL Server Standard Edition verwenden: Je nach Ihren Anforderungen an Hochverfügbarkeit und Notfallwiederherstellung können Sie die Lizenzkosten senken, indem Sie SQL Server Standard Edition anstelle von Enterprise Edition verwenden. Weitere Informationen finden Sie unter Versionen und unterstützte Funktionen von SQL Server.
  • Speicher optimieren: Hyperdisk bietet verschiedene Laufwerkoptionen, die Sie je nach den Anforderungen Ihrer SQL Server-Bereitstellung auswählen können. Hyperdisk Balanced bietet ein ausgewogenes Verhältnis zwischen Kosten und Leistung. Sie können Durchsatz und Ein-/Ausgabevorgänge pro Sekunde (IOPS) unabhängig voneinander skalieren, sodass Ihre Infrastrukturausgaben genau den Anforderungen der Arbeitslast entsprechen. Weitere Informationen finden Sie im Abschnitt Geeigneten Speichertyp auswählen.

Leistungsoptimierung

In diesem Abschnitt werden Designüberlegungen und Empfehlungen für eine SQL Server-Bereitstellung beschrieben, die Ihren Leistungsanforderungen entspricht.

Wenn Sie SQL Server auf Compute Engine-VMs bereitstellen, haben Sie die volle Kontrolle über die Datenbank und die zugrunde liegende Infrastruktur. Die Leistung Ihrer Arbeitslast hängt von der gewählten Infrastruktur ab. Um Leistung, Kosten und Zuverlässigkeit in Einklang zu bringen, müssen Sie fundierte Entscheidungen über die VM-Maschinenfamilie und den Festplattentyp für die Datenbankknoten treffen.

Geeignete VM-Maschinenfamilie auswählen

Die Maschinenfamilie, die Sie für die Compute Engine-VMs auswählen, bestimmt die Rechenleistung (vCPU) und den Arbeitsspeicher (RAM), die für Ihre SQL Server-Knoten verfügbar sind. Diese Ressourcen wirken sich auf die Leistung Ihrer Datenbanken aus.

Wählen Sie eine VM-Maschinenfamilie aus, die Ihren primären Leistungsengpass behebt. Wenn Ihre SQL Server-Datenbank beispielsweise ständig eine hohe CPU-Auslastung aufweist, wählen Sie einen Maschinentyp aus der computing-optimierten Maschinenfamilie aus. Wenn Ihre SQL Server-Datenbank langsame Lesevorgänge von der Festplatte aufweist, wählen Sie einen speicheroptimierten Maschinentyp aus.

In der folgenden Tabelle werden die von Compute Engine bereitgestellten VM-Maschinenfamilien, der primäre Anwendungsfall für jede Maschinenfamilie und die Auswirkungen auf die Leistung von SQL Server-Datenbanken verglichen:

Maschinenfamilie und -serie Primärer Anwendungsfall Auswirkungen auf die SQL Server-Leistung
Für allgemeine Zwecke (N4-Maschinenreihe) Ausgewogenes Preis-Leistungs-Verhältnis Verwenden Sie diese Maschinenfamilie als Ausgangspunkt für die meisten Arbeitslasten. Die N4-Maschinenserie bietet ein optimales Gleichgewicht zwischen CPU und Arbeitsspeicher für Datenbanken mit gemischter Nutzung, Webanwendungen sowie Entwicklungs- oder Testumgebungen.
Computing-optimiert (C3- oder C4-Maschinenreihe) Höchste Leistung pro Kern Verwenden Sie diese Maschinenfamilie für CPU-intensive Arbeitslasten. Für Datenbanken, die komplexe Abfragen ausführen, große Datenmengen verarbeiten oder eine hohe Anzahl von OLTP-Vorgängen (Online Transaction Processing) ausführen, verwenden Sie die Maschinenserien C3 und C4. Mit Maschinentypen aus diesen Serien lässt sich die Ausführungszeit von Abfragen erheblich verkürzen.
Speicheroptimiert (M3- oder M4-Maschinenreihe) Hohe Verhältnisse von Arbeitsspeicher zu vCPU Diese Maschinenfamilie eignet sich ideal für speicherintensive Anwendungen. SQL Server speichert Daten und Ausführungspläne im Arbeitsspeicher, was eine höhere Leistung als das Lesen von Festplatten ermöglicht. Bei sehr großen Datenbanken oder Data Warehouses für die Online Analytical Processing (OLAP) werden bei den Abfragen in der Regel große Tabellen und Datasets gescannt. Für solche Anwendungsfälle kann ein größerer Arbeitsspeicher die Leistung verbessern.

Weitere Informationen finden Sie im Leitfaden zu Ressourcen und Vergleichen für Maschinenfamilien.

Geeigneten Speichertyp auswählen

Die Festplattenleistung ist ein wichtiger Faktor für die Reaktionsfähigkeit der Datenbank, die für die Anwendungsleistung entscheidend ist. Für die von Google Cloudangebotenen Speichertypen werden die Leistungsmerkmale anhand der folgenden Messwerte angegeben:

  • IOPS: Die Anzahl der Lese- und Schreibanfragen, die ein Laufwerk pro Sekunde verarbeiten kann. IOPS sind für OLTP-Arbeitslasten, die viele kleine, zufällige Lese- und Schreibvorgänge umfassen, wie das Aktualisieren von Kundendatensätzen oder das Verarbeiten von Bestellungen, von entscheidender Bedeutung.
  • Durchsatz: Die Gesamtmenge an Daten, die pro Sekunde auf das Laufwerk oder vom Laufwerk übertragen werden kann. Der Durchsatz ist für OLAP-Arbeitslasten, bei denen große Datenmengen gescannt werden müssen, wie z. B. beim Ausführen von Berichten, beim Data Warehousing oder beim Ausführen von Back-ups, von entscheidender Bedeutung.

In der folgenden Tabelle werden die Google Cloud Laufwerkstypen verglichen, aus denen Sie auswählen können:

Laufwerkstyp Leistungsmerkmale Eignung für Arbeitslasten
Nichtflüchtiger SSD-Speicher (pd-ssd) Mittlere bis hohe Leistung je nach VM-Maschinentyp und Laufwerksgröße Arbeitslasten, bei denen die Leistung mit der Größe des Laufwerks und den vCPUs der VM skaliert werden muss. Weitere Informationen finden Sie unter Leistungsübersicht für Persistent Disk.
Hyperdisk abgestimmt Hohe Leistung mit konfigurierbaren IOPS und Durchsatz SQL Server-Daten- und Logdateien für die Produktion. Mit Hyperdisk Balanced können Sie IOPS und Durchsatz unabhängig von der Laufwerksgröße und basierend auf den Anforderungen der Arbeitslast konfigurieren.
Hyperdisk Extrem Sehr hohe Leistung mit konfigurierbaren IOPS High-End-OLTP-Arbeitslasten, die geschäftskritisch sind und maximale IOPS und die niedrigste Latenz erfordern, z. B. Finanz- oder E-Commerce-Systeme im großen Maßstab.
Lokale SSD Höchste IOPS und höchster Durchsatz im Vergleich zu den anderen Laufwerkstypen Temporäre Daten, für die die Langlebigkeit nichtflüchtiger Speicher nicht erforderlich ist. Für Daten wie die tempdb-Systemdatenbank und die Windows-Auslagerungsdatei bieten lokale SSDs die niedrigste Latenz, da sie physisch mit den VMs verbunden sind.

Infrastruktur an Leistungsanforderungen anpassen

Wählen Sie VM-Maschinentypen und Laufwerkstypen basierend auf den Leistungsanforderungen Ihrer Arbeitslast aus. In der folgenden Tabelle werden Infrastrukturkonfigurationen für verschiedene Arbeitslastszenarien empfohlen:

Szenario Leistungsanforderungen Empfohlener Maschinentyp und empfohlene Laufwerkskonfiguration
E-Commerce-Datenbank mit hohem Transaktionsvolumen für OLTP Hohe IOPS für die Verarbeitung von Tausenden von kleinen, gleichzeitigen Lese- und Schreibvorgängen

VM-Maschinentyp: Wählen Sie einen computing-optimierten Maschinentyp aus (z. B. aus der C4-Maschinenserie), um Transaktionen effizient zu verarbeiten.

Daten- und Protokolllaufwerke: Verwenden Sie Hyperdisk Balanced-Laufwerke. Stellen Sie ein hohes IOPS-Niveau bereit, um den Transaktionsanforderungen gerecht zu werden. Verwenden Sie separate Festplatten für Daten und Logs.

tempdb: Verwenden Sie lokale SSD-Laufwerke, um temporäre Vorgänge auszulagern und die Leistung zu maximieren.
Data Warehouse des Unternehmens für OLAP Hoher Durchsatz zum Scannen und Aggregieren von Terabytes an Daten für die Berichterstellung

VM-Maschinentyp: Wählen Sie einen speicheroptimierten Maschinentyp aus, z. B. aus der M4-Maschinenserie, damit Sie so viele Daten wie möglich aus dem großen Datensatz im Cache speichern können.

Datenlaufwerk: Verwenden Sie Hyperdisk Balanced-Laufwerke. Stellen Sie einen hohen Durchsatz bereit, um umfangreiche Datenscans zu beschleunigen.
Entwicklungs- oder Staging-Server Kosteneffizienz statt Spitzenleistung

VM-Maschinentyp: Wählen Sie einen Maschinentyp für allgemeine Zwecke mit einer kleinen Maschinengröße aus der E2- oder N4-Maschinenserie aus.

Laufwerke: Verwenden Sie für alle Datenbankdateien einen abgestimmten nichtflüchtigen Speicher (pd-balanced), um eine akzeptable Leistung zu geringen Kosten zu erzielen.

Bereitstellung

Verwenden Sie eine der folgenden Ressourcen, um diese Referenzarchitektur bereitzustellen:

Nächste Schritte

Beitragende

Autor*innen:

Weiterer Beitragender: Kumar Dhanagopal | Cross-Product Solution Developer