Freigeben über

Speicher: Bewährte Methoden zur Leistung für SQL Server auf Azure-VMs

  • Artikel

Gilt für: SQL Server auf Azure-VMs

In diesem Artikel werden bewährte Methoden und Richtlinien zum Speicher bereitgestellt, um die Leistung für Ihre SQL Server-Instanz auf Azure Virtual Machines (VMs) zu optimieren.

In der Regel kommt es zu einem Kompromiss zwischen einer Kostenoptimierung und einer Leistungsoptimierung. Diese Folge von bewährten Methoden zur Leistung konzentriert sich darauf, die beste Leistung für SQL Server auf Azure Virtual Machines zu erzielen. Wenn Ihre Workload weniger anspruchsvoll ist, sind möglicherweise nicht alle empfohlenen Optimierungen erforderlich. Berücksichtigen Sie bei der Evaluierung dieser Empfehlungen Ihre Leistungsanforderungen und -kosten sowie Ihre Workloadmuster.

Weitere Informationen finden Sie in den anderen Artikeln dieser Reihe: Checkliste, VM-Größe, Sicherheit, HADR-Konfiguration und Baseline erfassen.

Checkliste

In der folgenden Prüfliste finden Sie eine kurze Übersicht über die bewährten Methoden zur Speicherung, die im weiteren Verlauf des Artikels ausführlicher behandelt werden:

  • Überwachen Sie die Anwendung, und bestimmen Sie die Anforderungen an die Speicherbandbreite und Wartezeit für SQL Server-Daten-, Protokoll- und tempdb-Dateien, bevor Sie den Datenträgertyp auswählen.
  • Wenn verfügbar, konfigurieren Sie die tempdb-Daten und -Protokolldateien auf dem lokalen SSD-Volume von Laufwerk D. Die SQL IaaS-Agent-Erweiterung verarbeitet den Ordner und die Berechtigungen, die bei der erneuten Bereitstellung erforderlich sind.
  • Um die Speicherleistung zu optimieren, planen Sie für die höchsten verfügbaren nicht zwischengespeicherten IOPS, und verwenden Sie Datenzwischenspeicherung als Leistungsmerkmal für Datenlesevorgänge, während Sie die Begrenzung virtueller Computer und Datenträger vermeiden.
  • Wenn Sie die SQL Server-VMs der Serien Ebdsv5 oder Ebsv5 verwenden, sollten Sie SSD Premium v2 einsetzen, um die beste Leistung zu erzielen. Sie können Ihre SQL Server-VM mit SSD Premium v2 über das Azure-Portal bereitstellen (derzeit in der Vorschau).
  • Platzieren Sie Daten- und Protokoll- und tempdb-Dateien auf separaten Laufwerken.
    • Verwenden Sie für das Datenlaufwerk Premium P30- und P40-Datenträger oder kleinere Datenträger, um die Verfügbarkeit der Cacheunterstützung sicherzustellen. Bei Verwendung der Ebdsv5-VM-Serie nutzen Sie Premium SSD v2, die eine bessere Preisleistung für Workloads bietet, die einen hohen IOPS- und E/A-Durchsatz erfordern.
    • Für das Protokolllaufwerk planen Sie die Kapazität und testen die Leistung im Verhältnis zu den Kosten, während Sie entweder die Premium SSD v2- oder Premium SSD-Datenträger P30-P80 bewerten
      • Wenn eine Speicherwartezeit von weniger als einer Millisekunde erforderlich ist, verwenden Sie entweder Premium SSD v2 oder Azure Ultra-Disks für das Transaktionsprotokoll.
      • Für Bereitstellungen von virtuellen Computern der M-Serie sollten Sie eine Schreibbeschleunigung der Verwendung von Azure-Ultra-Datenträgern vorziehen.
    • Platzieren Sie tempdb auf dem temporären SSD-Laufwerk (das temporäre Laufwerk ist kurzlebig und standardmäßig D:\) für die meisten SQL Server-Workloads, die nicht Teil der Failoverclusterinstanz (FCI) sind, nachdem Sie die optimale VM-Größe ausgewählt haben.
    • Für Failoverclusterinstanzen (FCI) platzieren Sie tempdb auf dem gemeinsamen Speicher.
      • Wenn die FCI-Workload stark von der tempdb-Datenträgerleistung abhängig ist, platzieren Sie tempdb als erweiterte Konfiguration auf dem lokalen kurzlebigen SSD-Laufwerk (standardmäßig D:\), das nicht Teil des FCI-Speichers ist. Für diese Konfiguration sind benutzerdefinierte Überwachung und Aktionen erforderlich, um sicherzustellen, dass das lokale kurzlebige SSD-Laufwerk (standardmäßig D:\) immer verfügbar ist, da Fehler dieses Laufwerks keine Aktion der FCI auslösen.
  • Erstellen Sie ein Stripeset mehrerer Azure-Datenträger mithilfe von Speicherplätzen, um die E/A-Bandbreite bis zum IOPS- und Durchsatzlimit des virtuellen Zielcomputers zu erhöhen.
  • Legen Sie Hostzwischenspeicherung für Datenträger mit Datendateien auf Schreibgeschützt fest.
  • Legen Sie Hostzwischenspeicherung für Protokolldateidatenträger auf Keine fest.
    • Aktivieren Sie kein Lese-/Schreib-Caching auf Festplatten, die SQL Server-Daten oder Protokolldateien enthalten.
    • Beenden Sie immer den SQL Server-Dienst, bevor Sie die Cache-Einstellungen Ihrer Festplatte ändern.
  • Bei der Migration mehrerer verschiedener Workloads in die Cloud kann Azure Elastic SAN eine kostengünstige konsolidierte Speicherlösung sein. Bei Verwendung von Azure Elastic SAN muss jedoch oft eine überhöhte Kapazität bereitgestellt werden, um den gewünschten IOPS/Durchsatz für SQL Server-Workloads zu erreichen. Wenn auch in der Regel für einzelne SQL Server-Workloads nicht geeignet, kann beim Zusammenlegen von Workloads mit geringer Leistung mit SQL Server dennoch eine kostengünstige Lösung erzielt werden.
  • Für Workloads in Entwicklungs- und Testumgebungen sowie für die langfristige Archivierung von Sicherungskopien sollten Sie Standardspeicher verwenden. Es wird nicht empfohlen, HDD/SSD Standard für Produktionsworkloads zu verwenden.
  • Auf Guthaben basierendes Datenträgerbursting (P1-P20) sollte nur für kleinere Dev-/Test-Workloads und Abteilungssysteme in Betracht gezogen werden.
  • Um die Speicherleistung zu optimieren, planen Sie für die höchsten verfügbaren nicht zwischengespeicherten IOPS, und verwenden Sie Datenzwischenspeicherung als Leistungsmerkmal für Datenlesevorgänge, während Sie Drosselung von VMs und Datenträgern vermeiden.
  • Formatieren Sie den Datenträger, um die Größe der Zuordnungseinheiten von 64 KB für alle Datendateien zu verwenden, die auf einem anderen Laufwerk als dem temporären Laufwerk D:\ abgelegt werden (Standardwert: 4 KB). SQL Server über Azure Marketplace bereitgestellten virtuellen Computer verfügen über Datenträger, die mit der Größe der Zuordnungseinheit formatiert sind, und Interleave für den Speicherpool auf 64 KB.
  • Konfigurieren Sie das Speicherkonto in derselben Region wie die SQL Server-VM.
  • Deaktivieren Sie den georedundanten Azure-Speicher (Georeplikation), und verwenden Sie LRS (lokal redundanter Speicher) für das Speicherkonto.
  • Aktivieren Sie die SQL-Best-Practices-Bewertung, um mögliche Leistungsprobleme zu identifizieren und zu ermitteln, ob Ihre SQL Server-VM so konfiguriert ist, dass bewährte Methoden befolgt werden.
  • Überprüfen und überwachen Sie Datenträger- und VM-Grenzwerte mithilfe von Speicher-E/A-Auslastungsmetriken.
  • Schließen Sie SQL Server-Dateien von der Antivirensoftwareüberprüfung aus, einschließlich Datendateien, Protokolldateien und Sicherungsdateien.

Informationen zum Vergleichen der Prüfliste für den Speicher mit den anderen bewährten Methoden finden Sie unter Prüfliste für bewährte Methoden für die Leistung.

Übersicht

Beginnen Sie mit der Messung der Speicherleistung Ihrer Geschäftsanwendung, um die effektivste Konfiguration für SQL Server-Workloads auf einer Azure-VM zu finden. Sobald die Speicheranforderungen bekannt sind, wählen Sie einen virtuellen Computer aus, der die erforderlichen IOPS und den Durchsatz mit dem entsprechenden Verhältnis von Arbeitsspeicher zu virtuellen Kernen unterstützt.

Wählen Sie eine VM-Größe mit ausreichender Speicherskalierbarkeit für Ihre Workload und eine Mischung aus Datenträgern (normalerweise in einem Speicherpool) aus, die den Kapazitäts- und Leistungsanforderungen Ihres Unternehmens entsprechen.

Der Typ des Datenträgers hängt sowohl von dem Dateityp ab, der auf dem Datenträger gehostet wird, als auch von Ihren Anforderungen an die Spitzenleistung.

Tipp

Die Bereitstellung einer SQL Server-VM über das Azure-Portal führt Sie durch den Speicherkonfigurationsprozess und implementiert die meisten bewährten Methoden, z. B. das Erstellen separater Speicherpools für Ihre Daten- und Protokolldateien, die Ausrichtung von tempdb auf das Laufwerk D:\ und die Aktivierung der optimalen Richtlinie für die Zwischenspeicherung. Weitere Informationen zum Bereitstellen und Konfigurieren von Speicher finden Sie unter SQL-VM-Speicherkonfiguration.

VM-Datenträgertypen

Sie haben die Wahl bei der Leistungsstufe für Ihre Datenträger. Die Typen der verwalteten Datenträger, die als zugrunde liegender Speicher verfügbar sind (aufgelistet nach aufsteigender Leistungsfähigkeit), sind Standard-Festplattenlaufwerke (HDD), SSD Standard-, SSD Premium-, SSD Premium v2-Datenträger (SSD) und Ultra Disks.

Für Standard HDD-, Standard SDD- und Premium SDD-Festplatten steigt die Leistung des Datenträgers mit der Kapazität, gruppiert nach Premium-Datenträgerbezeichnungen wie der P1 mit 4 GiB Speicherplatz und 120 IOPS bis zum P80 mit 32 TiB Speicherplatz und 20.000 IOPS. Premium-Speicher unterstützt einen Speichercache, der die Lese- und Schreibleistung für einige Workloads verbessert. Weitere Informationen finden Sie in der Übersicht über verwaltete Datenträger.

Die Leistung von Premium SSD v2 und Ultra Disks kann unabhängig von der Größe des Datenträgers geändert werden, ausführliche Informationen finden Sie unter Ultra Disk Leistung und Premium SSD v2 Leistung.

Es gibt auch drei hauptsächliche Datenträgertypen, die Sie für Ihre SQL Server auf Azure VM in Betracht ziehen sollten – eine Disk für das Betriebssystem, eine temporäre Disk und Ihre Datenträger. Wählen Sie sorgfältig aus, was auf dem Betriebssystemlaufwerk (C:\) und dem kurzlebigen temporären Laufwerk (D:\) gespeichert wird.

Betriebssystem-Datenträger

Ein Betriebssystemdatenträger ist eine virtuelle Festplatte, die als aktive Version eines Betriebssystems gestartet und eingebunden werden kann, und die als Laufwerk C:\ bezeichnet ist. Wenn Sie eine Azure-VM erstellen, wird von der Plattform mindestens ein Datenträger als Betriebssystemdatenträger an die VM angefügt. Das Laufwerk C:\ ist der Standardspeicherort für Anwendungsinstallationen und Dateikonfigurationen.

Verwenden Sie in SQL Server-Produktionsumgebungen nicht den Betriebssystemdatenträger für Datendateien, Protokolldateien und Fehlerprotokolle.

Temporärer Datenträger

Viele virtuelle Azure-Computer enthalten einen weiteren Datenträgertyp, der als temporärer Datenträger bezeichnet wird (Bezeichnung als Laufwerk D:\). Abhängig von der Serie und Größe des virtuellen Computers variiert die Kapazität dieses Datenträgers. Der temporäre Datenträger ist kurzlebig. Dies bedeutet, dass der Datenträgerspeicher neu erstellt wird (d. h. er wird freigegeben und erneut zugeordnet), wenn der virtuelle Computer neu gestartet oder auf einen anderen Host verschoben wird (z. B. für die Dienstreparatur).

Das temporäre Speicherlaufwerk wird in Remotespeicher nicht persistent gespeichert und sollte daher keine Benutzerdatenbankdateien, Transaktionsprotokolldateien oder anderen Daten speichern, die beibehalten werden müssen. Sie können sie beispielsweise für Pufferpoolerweiterungen die Seitendatei und tempdb nutzen.

Platzieren Sie tempdb auf dem lokalen temporären SSD-Laufwerk D:\ für SQL Server-Workloads, es sei denn, die Verwendung des lokalen Cache ist ein Problem. Wenn Sie eine VM verwenden, die keinen temporären Datenträger aufweist, sollten Sie tempdb auf einem eigenen isolierten Datenträger oder in einem Speicherpool platzieren, bei dem die Zwischenspeicherung schreibgeschützt erfolgt. Weitere Informationen finden Sie unter Richtlinien zum Zwischenspeichern von tempdb-Daten.

Datenträger

Bei Datenträgern für Daten handelt es sich um Remotespeicherdatenträger, die häufig in Speicherpools erstellt werden, um die Kapazitäts- und Leistungsdiagnose zu übertreffen, die ein einzelner Datenträger dem virtuellen Computer bieten könnte.

Fügen Sie die Mindestanzahl von Datenträgern an, die den IOPS-, Durchsatz- und Kapazitätsanforderungen Ihrer Workload entsprechen. Überschreiten Sie nicht die maximale Anzahl der Datenträger für Daten der kleinsten VM, deren Größe Sie ändern möchten.

Legen Sie Daten und Protokolldateien auf Datenträgern für Daten ab, die den Leistungsanforderungen am besten entsprechen.

Formatieren Sie den Datenträger, um die Größe der Zuordnungseinheiten von 64 KB für alle Datendateien zu verwenden, die auf einem anderen Laufwerk als dem temporären Laufwerk D:\ abgelegt werden (Standardwert: 4 KB). SQL Server über Azure Marketplace bereitgestellten virtuellen Computer verfügen über Datenträger, die mit der Größe der Zuordnungseinheit formatiert sind, und Interleave für den Speicherpool auf 64 KB.

Hinweis

Es ist auch möglich, Ihre SQL Server-Datenbankdateien direkt in Azure Blob Storage oder im SMB-Speicher (z. B. Azure Premium-Dateifreigaben) zu hosten. Es wird jedoch empfohlen, verwaltete Azure-Datenträger zu verwenden, um die beste Leistung, Zuverlässigkeit und Funktionsverfügbarkeit zu erzielen.

SSD Premium v2

Sie sollten SSD Premium v2-Datenträger verwenden, wenn SQL Server-Workloads in unterstützten Regionen ausgeführt werden, wenn die aktuellen Einschränkungen für Ihre Umgebung geeignet sind. Je nach Konfiguration kann SSD Premium v2 günstiger als SSD Premium sein und gleichzeitig verbesserte Leistung bieten. Mit SSD Premium v2 können Sie ihren Durchsatz oder IOPS unabhängig von der Größe Ihres Datenträgers anpassen. Durch die Individuelle Anpassung der Leistungsoptionen können Sie diese größeren Kosteneinsparungen erzielen und Skriptänderungen vornehmen, um Leistungsanforderungen während der erwarteten oder bekannten Bedarfszeiträume zu erfüllen.

Wir empfehlen die Verwendung von SSD Premium v2, wenn die virtuellen Computerserien Ebdsv5 oder Ebsv5 genutzt werden, da es sich um eine kostengünstigere Lösung für diese hohen E/A-Durchsatzcomputer handelt.

Sie können Ihre SQL Server-VM mit SSD Premium v2 über das Azure-Portal bereitstellen (derzeit in der Vorschau).

Wenn Sie Ihre SQL Server-VM über das Azure-Portal bereitstellen und SSD Premium v2 verwenden möchten, sind Sie derzeit auf die virtuellen Computer der Serien Ebdsv5 oder Ebsv5 beschränkt. Wenn Sie Ihre VM jedoch manuell mit SSD-Premium-v2-Speicher erstellen und SQL Server dann manuell auf der VM installieren, können Sie jede VM-Serie verwenden, die SSD Premium v2 unterstützt. Registrieren Sie Ihre SQL Server-VM mit der SQL IaaS-Agent-Erweiterung, damit Sie alle Vorteile der Erweiterung nutzen können.

Azure Elastic SAN

Azure Elastic SAN ist ein Network Attached Storage-Angebot für eine flexible und skalierbare Lösung, mit der Kunden durch Speicherkonsolidierung Kosten senken können. Azure Elastic SAN bietet eine kostengünstige, leistungsfähige und zuverlässige Blockspeicherlösung, die eine Verbindung mit einer Vielzahl von Azure-Compute-Diensten über das iSCSI-Protokoll herstellt. Elastic SAN ermöglicht einen nahtlosen Übergang von einer vorhandenen SAN-Speicherfläche zur Cloud, ohne die Kundenanwendungsarchitektur umgestalten zu müssen.

Diese Lösung ermöglicht die Hochskalierung auf Millionen von IOPS, zweistellige GB/s an Durchsatz und niedrige Millisekundenlatenzen mit integrierter Ausfallsicherheit, um Ausfallzeiten zu minimieren. Verwenden Sie Azure Elastic SAN, wenn Sie Speicher konsolidieren und mit mehreren Computediensten arbeiten müssen oder Workloads haben, die einen hohen Durchsatz erfordern, wenn der Speicher über die Netzwerkbandbreite gesteigert wird. Da jedoch oft eine überhöhte Kapazität bereitgestellt werden muss, um den gewünschten IOPS/Durchsatz für SQL Server-Workloads zu erreichen, ist es in der Regel nicht für einzelne SQL Server-Workloads geeignet. Es kann eine Zusammenlegung anderer Workloads mit geringer Leistung mit SQL Server erforderlich sein, um die kostengünstigste Lösung zu erzielen.

Beim Erwägen der Dimensionierung und Leistung von virtuellen Computern für Azure Elastic SAN ist es wichtig zu wissen, dass die Speicherkommunikation über das Netzwerk erfolgt. Die VM-Größe E4d_v5 unterstützt z. B. Azure Storage Premium nicht, funktioniert aber gut mit Azure Elastic SAN, da ein Netzwerkdurchsatz von bis zu 12.500 Mbps unterstützt wird. Wenn Sie Azure Elastic SAN mit dieser VM-Größe verwenden, müssen Sie sicherstellen, dass die Netzwerk- und Speicherdurchsatzanforderungen für Ihre Workload unter dem Grenzwert von 12.500 MBit/s für den Netzwerkdurchsatz liegen.

Ermitteln Sie Ihre Netzwerk- und Speicheranforderungen, bevor Sie Ihre SQL Server-VM mit einem Azure Elastic SAN bereitstellen, und überwachen Sie dann sorgfältig die Netzwerk- und Speicherauslastung, um sicherzustellen, dass die ausgewählte VM die Workload bewältigen kann. Weitere Informationen finden Sie unter VM-Leistung mit elastischen SAN-Volumes und Elastic SAN-Metriken.

Achtung

  • VM-Größenanpassungen mit Elastic SAN müssen neben dem Speicherdurchsatz auch die Anforderungen an den Netzwerkdurchsatz (VM zu VM) erfüllen. Bei Verwendung von Elastic SAN sind VM-Größen, die den E/A-Durchsatz optimieren, gegebenenfalls nicht so kostengünstig wie VM-Größen, die für die Netzwerkbandbreite optimiert sind.

Erwägen Sie die Platzierung von SQL Server-Workloads auf Elastic SAN für eine bessere Kosteneffizienz, da:

  • Speicherkonsolidierung und dynamische Leistungsfreigabe: Normalerweise wird für SQL Server auf Azure VM-Workloads Datenträgerspeicher pro VM basierend auf Ihren Kapazitäts- und Höchstleistungsanforderungen für diesen virtuellen Computer bereitgestellt. Diese überdimensionierte Leistung ist bei Bedarf verfügbar, aber die nicht verwendete Leistung kann nicht für Workloads auf anderen VMs freigegeben werden. Elastic SAN, ähnlich wie lokales SAN, ermöglicht das Konsolidieren von Speicheranforderungen mehrerer SQL- und Nicht-SQL-Workloads, um eine bessere Kosteneffizienz zu erzielen, mit der Möglichkeit, die bereitgestellte Leistung dynamisch über die Volumes zu teilen, die für diese verschiedenen Workloads basierend auf E/A-Anforderungen bereitgestellt werden. Beispiel: Wenn Sie in der Region „USA, Osten“ beispielsweise über 10 Workloads verfügen, die jeweils 2 TiB Kapazität und 10.000 IOPS erfordern, benötigen sie jedoch zusammen nicht mehr als 60.000 IOPS zu einem bestimmten Zeitpunkt. Sie können ein Elastic SAN mit 12 Basiseinheiten (1 Basiseinheit = $0,08 pro GiB/Monat) konfigurieren, was Ihnen 12 TiB Kapazität und die benötigten 60.000 IOPS und 8 Kapazitätseinheiten (nur 1 Kapazitätseinheit = $0,06 pro GiB/Monat) bietet, wodurch Sie wiederum die verbleibenden 8 TiB Kapazität zu günstigeren Kosten erhalten. Diese optimale Speicherkonfiguration bietet eine bessere Kosteneffizienz bei gleichzeitiger Bereitstellung der erforderlichen Leistung (10K IOPS) für jede dieser Workloads. Weitere Informationen zu Elastic SAN-Basiseinheiten und Bereitstellungseinheiten für Kapazität finden Sie unter Planung von Azure Elastic SAN, und Preise finden Sie unter Azure Elastic SAN – Preise.
  • Um einen höheren Speicherdurchsatz zu steuern: SQL Server auf Azure-VM-Bereitstellungen erfordern gelegentlich die Überbereitstellung der Datenträgerdurchsatzbeschränkungen von virtuellen Computern für diesen virtuellen Computer. Sie können dies mit Elastic SAN vermeiden, da Sie einen höheren Speicherdurchsatz über die Compute-Netzwerkbandbreite mit dem iSCSI-Protokoll steuern. Beispielsweise ist eine Standard_E32bds_v5-VM auf 51.200 IOPS und 865 MBps für den Datenträger-/Speicherdurchsatz begrenzt, kann aber bis ein Maximum 2000 MBIT-Netzwerkdurchsatz erreichen. Wenn die Speicherdurchsatzanforderung für Ihre Workload größer als 865 MBps ist, müssen Sie die VM nicht auf eine höhere SKU aktualisieren, da sie jetzt bis zu 2000 MBps mithilfe von Elastic SAN unterstützen kann.

SSD Premium

Verwenden Sie SSD Premium-Datenträger für Daten und Protokolldateien für SQL Server-Workloads in der Produktionsumgebung. IOPS und Bandbreite für SSD Premium-Datenträger variieren je nach Datenträgergröße und -typ.

Verwenden Sie für Produktionsworkloads die Datenträger P30 und/oder P40 für SQL Server-Datendateien, um die Unterstützung der Zwischenspeicherung sicherzustellen, und verwenden Sie die Datenträger P30 bis P80 für SQL Server-Transaktionsprotokolldateien. Um die optimalen Gesamtkosten zu erzielen, beginnen Sie mit P30-Datenträgern (5000 IOPS/200 MBit/s) für Daten und Protokolldateien, und wählen Sie nur dann höhere Kapazitäten aus, wenn Sie die Anzahl der Datenträger des virtuellen Computers steuern müssen. Bei Dev/Test oder kleinen Systemen können Sie Größen verwenden, die kleiner als P30 sind, da dies die Zwischenspeicherung unterstützt, aber sie bieten keine reservierten Preise.

Stimmen Sie bei OLTP-Workloads die Ziel-IOPS pro Datenträger (oder Speicherpool) mit Ihren Leistungsanforderungen ab, indem Sie Workloads zu Spitzenzeiten und die Leistungsindikatoren Disk Reads/sec + Disk Writes/sec verwenden. Stimmen Sie bei Data Warehouse- und Berichtsworkloads den Zieldurchsatz anhand von Workloads zu Spitzenzeiten und den Leistungsindikatoren Disk Read Bytes/sec + Disk Write Bytes/sec ab.

Verwenden Sie Speicherplätze, um eine optimale Leistung zu erreichen, konfigurieren Sie zwei Pools, einen für die Protokolldatei(en) und den anderen für die Datendateien. Wenn Sie kein Datenträgerstriping verwenden, sollten Sie zwei Datenträger vom Typ SSD Premium verwenden, die separaten Datenträgern zugeordnet sind, wobei sich auf einem Laufwerk die Protokolldatei und auf dem anderen die Daten befinden.

Die bereitgestellten IOPS und der Durchsatz pro Datenträger, die als Teil Ihres Speicherpools verwendet werden. Die kombinierte IOPS- und Durchsatzleistung der Datenträger ist die maximale Leistung bis zu den Durchsatzgrenzwerten des virtuellen Computers.

Die bewährte Methode besteht darin, die geringstmögliche Anzahl von Datenträgern zu verwenden und gleichzeitig die Mindestanforderungen an IOPS (und Durchsatz) und Kapazität zu erfüllen. Das Verhältnis von Preis und Leistung ist jedoch tendenziell besser bei einer großen Anzahl kleiner Datenträger als bei einer kleinen Anzahl großer Datenträger.

Skalieren von Premium-Datenträgern

Die Größe Ihrer SSD Premium bestimmt die anfängliche Leistungsstufe Ihres Datenträgers. Bestimmen Sie die Leistungsstufe bei der Bereitstellung oder ändern Sie sie nachträglich, ohne die Größe des Datenträgers zu ändern. Wenn die Nachfrage steigt, können Sie die Leistungsstufe erhöhen, um Ihre Geschäftsanforderungen zu erfüllen.

Das Ändern der Leistungsstufe ermöglicht es Administratoren, sich auf höhere Anforderungen vorzubereiten und diese zu erfüllen, ohne sich auf das Datenträgerbursting zu verlassen.

Verwenden Sie die höhere Leistung so lange wie nötig, wenn die Abrechnung auf die Speicherleistungsstufe ausgelegt ist. Führen Sie ein Upgrade der Leistungsstufe durch, um die Leistungsanforderungen zu erfüllen, ohne die Kapazität zu erhöhen. Kehren Sie zur ursprünglichen Stufe zurück, wenn die zusätzliche Leistung nicht mehr benötigt wird.

Diese kostengünstige und zeitlich begrenzte Leistungserweiterung ist ein starker Anwendungsfall für gezielte Ereignisse wie Einkaufen, Leistungstests, Schulungsveranstaltungen und andere kurze Zeitfenster, in denen nur kurzfristig mehr Leistung benötigt wird.

Weitere Informationen finden Sie unter Leistungsstufen für verwaltete Datenträger.

Azure Ultra-Datenträger

Wenn Antwortzeiten unterhalb des Millisekundenbereichs mit reduzierter Latenz erforderlich sind, ist die Verwendung von Azure Ultra-Datenträgern für das SQL Server-Protokolllaufwerk oder sogar das Datenlaufwerk für Anwendungen, die extrem empfindlich auf die E/A-Latenz reagieren, zu erwägen.

Ultra Disk kann so konfiguriert werden, dass Kapazität und IOPS unabhängig voneinander skaliert werden können. Mit Ultra Disk können Administratoren einen Datenträger mit den Anforderungen an Kapazität, IOPS und Durchsatz basierend auf den Anwendungsanforderungen bereitstellen.

Ultra Disk wird nicht von allen VM-Serien unterstützt und weist weitere Einschränkungen wie Regionsverfügbarkeit, Redundanz und Unterstützung für Azure Backup auf. Eine vollständige Liste der Einschränkungen finden Sie unter Verwendung von Azure Ultra-Datenträgern.

Datenträger vom Typ „HDD Standard“ und „SSD Standard“

Datenträger vom Typ HDD Standard und SSD Standard verfügen über unterschiedliche Latenzen und Bandbreiten und sollten nur für Dev/Test-Workloads verwendet werden. Für Produktionsworkloads sollte SSD Premium v2 oder SSD Premium verwendet werden. Wenn Sie einen SSD Standard-Datenträger verwenden (Dev/Test-Szenarien), sollten Sie die maximale Anzahl von Datenträgern für Daten hinzufügen, die von Ihrer VM-Größe unterstützt wird, und Datenträgerstriping mit Speicherplätzen verwenden, um die beste Leistung zu erzielen.

Caching

Virtuelle Computer, die die Storage Premium-Zwischenspeicherung unterstützen, können ein zusätzliches Feature namens Azure BlobCache oder gehosteter Cache nutzen, um die IOPS- und Durchsatzleistungen eines virtuellen Computers zu erweitern. Virtuelle Computer, die sowohl für Storage Premium als auch für Storage Premium-Zwischenspeicherung aktiviert sind, verfügen über diese beiden unterschiedlichen Bandwidth-Grenzwerte für die Speicherbandbreite, die zusammen verwendet werden können, um die Speicherleistung zu verbessern.

Der IOPS- und MBit/s-Durchsatz ohne Zwischenspeichern wird auf die Grenzwerte des Datenträgerdurchsatzes eines virtuellen Computers ohne Zwischenspeicherung angerechnet. Die maximalen Grenzwerte mit Zwischenspeicherung bieten einen zusätzlichen Puffer für Lesevorgänge, der bei Wachstum und unerwarteten Spitzenwerten hilft.

Aktivieren Sie die Premium-Zwischenspeicherung, wenn die Option unterstützt wird, um die Leistung für Lesevorgänge auf dem Datenlaufwerk ohne zusätzliche Kosten deutlich zu verbessern.

Lese- und Schreibvorgänge in den Azure BlobCache (zwischengespeicherte IOPS und Durchsatz) werden nicht auf die nicht zwischengespeicherten IOPS- und Durchsatzgrenzwerte der VM angerechnet.

Hinweis

Die Zwischenspeicherung von Datenträgern wird nicht für Datenträger mit einer Größe von 4 TiB und höher unterstützt (P50 und höher). Wenn mehrere Datenträger an Ihre VM angefügt sind, unterstützt jeder Datenträger mit 4 TiB oder weniger das Zwischenspeichern. Weitere Informationen finden Sie unter Nutzung des Datenträgercaches.

Nicht zwischengespeicherter Durchsatz

Die maximale IOPS- und Durchsatzrate für Datenträger ohne Zwischenspeicherung ist das maximale Remotespeicherlimit, die der virtuelle Computer verarbeiten kann. Dieser Grenzwert wird auf der VM definiert und ist kein Grenzwert des zugrunde liegenden Datenträgerspeicher. Diese Begrenzung gilt nur für E/A bei Datenlaufwerken, die remote an den virtuellen Computer angefügt sind, nicht für die lokale E/A für das temporäre Laufwerk (Laufwerk D:\) oder das Betriebssystemlaufwerk.

Die für einen virtuellen Computer zur Verfügung stehende Menge der IOPS und des Durchsatzes ohne Zwischenspeicherung können Sie in der Dokumentation zu Ihrem virtuellen Computer überprüfen.

Die Dokumentation der M-Serie zeigt z. B., dass der maximale Durchsatz ohne Zwischenspeicherung für den virtuellen Computer vom Typ „Standard_M8ms“ 5000 IOPS und 125 MBit/s Datenträgerdurchsatz ohne Zwischenspeicherung beträgt.

Screenshot: Dokumentation zum Datenträgerdurchsatz ohne Zwischenspeicherung der M-Serie

Ebenso können Sie sehen, dass der Typ „Standard_M32ts“ 20.000 Datenträger-IOPS ohne Zwischenspeicherung und 500 MBit/s Datenträgerdurchsatz ohne Zwischenspeicherung unterstützt. Diese Begrenzung wird auf der Ebene des virtuellen Computers geregelt, unabhängig von dem zugrunde liegenden Premium-Datenträgerspeicher.

Weitere Informationen finden Sie unter Nicht zwischengespeicherte und zwischengespeicherte Grenzwerte.

Zwischengespeicherter und temporärer Speicherdurchsatz

Der Grenzwert für den maximalen Durchsatz von zwischengespeichertem und temporärem Speicher ist ein von dem Grenzwert für den nicht zwischengespeicherten Durchsatz des virtuellen Computers getrennter Grenzwert. Der Azure BlobCache besteht aus einer Kombination aus dem Arbeitsspeicher (RAM) des Hosts des virtuellen Computers und einer lokal angefügten SSD. Das temporäre Laufwerk (Laufwerk D:\) innerhalb des virtuellen Computers wird ebenfalls auf dieser lokalen SSD gehostet.

Die maximale zwischengespeicherte und temporäre Speicherdurchsatzgrenze regelt die E/A für das lokale temporäre Laufwerk (Laufwerk D:\) und den Azure BlobCache nur, wenn die Hostzwischenspeicherung aktiviert ist.

Wenn die Zwischenspeicherung auf Storage Premium aktiviert ist, können virtuelle Computer über die Grenzen des nicht zwischengespeicherten VM-IOPS und -Durchsatzes des Remotespeichers hinaus skalieren.

Nur bestimmte virtuelle Computer unterstützen sowohl Storage Premium als auch Storage Premium-Zwischenspeicherung (dies muss in der Dokumentation des virtuellen Computers überprüft werden). Die Dokumentation der M-Serie gibt z. B. an, dass sowohl Storage Premium als auch Storage Premium-Zwischenspeicherung unterstützt werden:

Screenshot: Storage Premium-Unterstützung der M-Serie

Die Grenzwerte des Caches hängen von der Größe der VM ab. Die VM vom Typ „Standard_M8ms“ unterstützt z. B. 10.000 Datenträger-IOPS mit Zwischenspeicherung und 1.000 MBit/s Datenträgerdurchsatz mit Zwischenspeicherung bei einer Gesamtgröße des Caches von 793 GiB. In ähnlicher Weise unterstützt die VM vom Typ „Standard_M32ts“ 40.000 Datenträger-IOPS mit Zwischenspeicherung und 400 MBit/s Datenträgerdurchsatz mit Zwischenspeicherung bei einer Gesamtgröße des Caches von 3.174 GiB.

Screenshot: Dokumentation zum Datenträgerdurchsatz mit Zwischenspeicherung der M-Serie

Sie können die Hostzwischenspeicherung auf einem vorhandenen virtuellen Computer manuell aktivieren. Beenden Sie alle Anwendungsworkloads und die SQL Server-Dienste, bevor Sie Änderungen an der Richtlinie für die Zwischenspeicherung des virtuellen Computers vornehmen. Wenn Sie eine der Cacheeinstellungen des virtuellen Computers ändern, wird der Zieldatenträger getrennt und nach der Anwendung der Einstellungen wieder angefügt.

Richtlinien für die Zwischenspeicherung von Datendateien

Die Richtlinie für die Zwischenspeicherung hängt von der Art der SQL Server-Datendateien ab, die auf dem Laufwerk gehostet werden.

Die folgende Tabelle enthält eine Zusammenfassung der empfohlenen Richtlinien für die Zwischenspeicherung basierend auf dem Typ der SQL Server-Daten:

SQL Server-Datenträger Empfehlung
Datenträger für Daten Aktivieren Sie die Read-only-Zwischenspeicherung für die Datenträger, die SQL Server-Datendateien hosten.
Die Lesevorgänge aus dem Cache sind schneller als die nicht zwischengespeicherten Lesevorgänge von dem Datenträger für Daten.
IOPS und Durchsatz ohne Zwischenspeicherung sowie IOPS und Durchsatz mit Zwischenspeicherung ergeben die gesamte mögliche Leistung, die von der VM innerhalb der VM-Grenzwerte zur Verfügung steht, aber die tatsächliche Leistung variiert je nach der Fähigkeit der Workload, den Cache zu nutzen (Cachetrefferquote).
Transaktionsprotokolldatenträger Legen Sie die Richtlinie für die Zwischenspeicherung für Datenträger, die das Transaktionsprotokoll hosten, auf None fest. Das Aktivieren der Zwischenspeicherung für den Transaktionsprotokolldatenträger bringt keinen Leistungsvorteil, und tatsächlich kann das Aktivieren der Read-only- oder Read/Write-Zwischenspeicherung auf dem Protokolllaufwerk die Leistung der Schreibvorgänge auf dem Laufwerk verschlechtern und den Umfang des für Lesevorgänge auf dem Datenlaufwerk verfügbaren Caches verringern.
Betriebssystemdatenträger Die Standardrichtlinie für die Zwischenspeicherung für das Betriebssystemlaufwerk ist Read/write.
Es wird nicht empfohlen, den Grad der Zwischenspeicherung für das Betriebssystemlaufwerk zu ändern.
tempdb Wenn tempdb aus Kapazitätsgründen nicht auf dem kurzlebigen Laufwerk D:\ platziert werden kann, ändern Sie entweder die Größe der VM, um ein größeres kurzlebiges Laufwerk zu erhalten, oder platzieren Sie tempdb auf einem separaten Datenlaufwerk mit konfigurierter Read-only-Zwischenspeicherung.
Der Cache der VM und das kurzlebige Laufwerk verwenden beide die lokale SSD. Beachten Sie dies bei der Dimensionierung, da die E/A von tempdb auf die Grenzwerte der VM für IOPS und den Durchsatz mit Zwischenspeicherung angerechnet werden, wenn das Hosting auf dem kurzlebigen Laufwerk erfolgt.

Wichtig

Durch Ändern der Cacheeinstellung eines Azure-Datenträgers wird der Zieldatenträger getrennt und erneut angefügt. Wenn Sie die Cacheeinstellung für einen Datenträger ändern, der Daten-, Protokoll- oder Anwendungsdateien für SQL Server hostet, müssen Sie unbedingt den SQL Server-Dienst sowie alle anderen verwandten Diensten beenden, um Datenbeschädigungen zu vermeiden.

Weitere Informationen finden Sie unter Nutzung des Datenträgercaches.

Datenträgerstriping

Analysieren Sie den Durchsatz und die Bandbreite, die für Ihre SQL-Datendateien erforderlich sind, um die Anzahl der Datenträger für Daten, einschließlich der Protokolldatei und tempdb, zu bestimmen. Die Grenzwerte für Durchsatz und Bandbreite variieren je nach VM-Größe. Weitere Informationen finden Sie unter VM-Größen.

Fügen Sie zusätzliche Datenträger für Daten hinzu, und verwenden Sie das Datenträgerstriping für einen höheren Durchsatz. Eine Anwendung, die 12.000 IOPS und 180 MBit/s Durchsatz erfordert, kann z. B. drei P30-Stripesetdatenträger verwenden, um 15.000 IOPS und 600 MBit/s Durchsatz zu liefern.

Informationen zum Konfigurieren des Datenträgerstripings finden Sie unter Datenträgerstriping.

Datenträgerbegrenzung

Es gibt Durchsatzgrenzwerte sowohl auf Datenträgerebene als auch auf der Ebene des virtuellen Computers. Die maximalen IOPS-Grenzwerte pro virtuellem Computer und pro Datenträger sind unterschiedlich und unabhängig voneinander.

Anwendungen, die über diese Grenzwerte hinaus Ressourcen verwenden, werden gedrosselt (auch als „begrenzt“ bezeichnet). Wählen Sie eine VM und eine Datenträgergröße in einem Datenträgerstripeset aus, die den Anforderungen der Anwendung entspricht und keiner Begrenzung unterliegt. Um der Begrenzung entgegenzuwirken, verwenden Sie die Zwischenspeicherung, oder stimmen Sie die Anwendung so ab, dass weniger Durchsatz erforderlich ist.

Eine Anwendung, die 12.000 IOPS und 180 MB/s benötigt, kann z. B. wie folgt vorgehen:

  • Verwenden des Typs Standard_M32ms, der einen maximalen Datenträgerdurchsatz ohne Zwischenspeicherung von 20.000 IOPS und 500 MBit/s aufweist.
  • Stripeset von drei P30-Datenträgern, um 15.000 IOPS und 600 MBit/s Durchsatz zu erreichen.
  • Verwenden Sie einen virtuellen Computer vom Typ Standard_M16ms, und verwenden Sie den gehosteten Cache, um den lokalen Cache zu nutzen, anstatt den Durchsatz zu verbrauchen.

Virtuelle Computer, die so konfiguriert sind, dass sie in Zeiten hoher Auslastung hochskaliert werden, sollten Speicher mit genügend IOPS und Durchsatz bereitstellen, um die maximale VM-Größe zu unterstützen, während die Gesamtzahl der Datenträger kleiner oder gleich der maximalen Anzahl ist, die von der kleinsten VM-SKU unterstützt wird, die verwendet werden soll.

Weitere Informationen zu den Einschränkungen der Datenträgerbegrenzung und zur Verwendung der Zwischenspeicherung zum Vermeiden der Begrenzung finden Sie unter Obergrenzen der Datenträger-E/A.

Hinweis

Eine gewisse Datenträgerbegrenzung kann immer noch zu einer zufriedenstellenden Leistung für die Benutzer führen. Stimmen Sie die Workloads ab und behalten Sie sie bei, anstatt die Größe der VM zu erhöhen, um ein Gleichgewicht zwischen Kosten und Leistung für das Unternehmen zu erreichen.

Schreibbeschleunigung

Die Schreibbeschleunigung ist ein Datenträgerfeature, das nur für die virtuellen Computer (VMs) der M-Serie verfügbar ist. Der Zweck der Schreibbeschleunigung besteht darin, die E/A-Wartezeit von Schreibvorgängen für Azure Storage Premium zu verbessern, wenn Sie aufgrund von unternehmenskritischen OLTP-Workloads mit hohem Volumen oder Data Warehouse-Umgebungen eine einstellige E/A-Wartezeit benötigen.

Verwenden Sie die Schreibbeschleunigung, um die Schreibwartezeit für das Laufwerk zu verbessern, auf dem die Protokolldateien gespeichert sind. Verwenden Sie die Schreibbeschleunigung nicht für SQL Server-Datendateien.

Alle Datenträger mit Schreibbeschleunigung verwenden denselben IOPS-Grenzwert wie die VM. Angefügte Datenträger dürfen den IOPS-Grenzwert der Schreibbeschleunigung für eine VM nicht überschreiten.

Die folgende Tabelle bietet eine Übersicht über die pro VM unterstützte Anzahl der Datenträger für Daten und IOPS:

VM-SKU Anzahl der Datenträger mit Schreibbeschleunigung Datenträger-IOPS der Schreibbeschleunigung pro VM
M416ms_v2, M416s_v2 16 20000
M128ms, M128s 16 20000
M208ms_v2, M208s_v2 8 10000
M64ms, M64ls, M64s 8 10000
M32ms, M32ls, M32ts, M32s 4 5.000
M16ms, M16s 2 2500
M8ms, M8s 1 1250

Bei der Verwendung der Schreibbeschleunigung gibt es eine Reihe von Einschränkungen. Weitere Informationen finden Sie unter Einschränkungen bei der Verwendung der Schreibbeschleunigung.

Vergleich mit Azure Ultra-Datenträgern

Der größte Unterschied zwischen der Schreibbeschleunigung und Azure Ultra Disks ist, dass die Schreibbeschleunigung ein Feature für virtuelle Computer ist, das nur für die M-Serie verfügbar ist, während Azure Ultra Disks eine Speicheroption darstellt. Die Schreibbeschleunigung ist ein schreiboptimierter Cache mit eigenen Einschränkungen, die auf der Größe des virtuellen Computers basieren. Azure Ultra Disks sind eine latenzarme Speicheroption für Datenträger für Azure Virtual Machines.

Verwenden Sie nach Möglichkeit die Schreibbeschleunigung anstelle von Ultra-Datenträgern für den Transaktionsprotokolldatenträger. Für VMs, die keine Schreibbeschleunigung unterstützen, aber eine geringe Wartezeit für das Transaktionsprotokoll erfordern, verwenden Sie Azure Ultra Disks.

Überwachen der Speicherleistung

Um die Speicheranforderungen und die Leistung des Speichers zu ermitteln, müssen Sie wissen, was zu messen ist und was diese Indikatoren bedeuten.

IOPS (Eingabe/Ausgabe pro Sekunde) entspricht der Anzahl der Anforderungen, die die Anwendung pro Sekunde an den Speicher stellt. Messen Sie die IOPS mit den Leistungsmonitorindikatoren Disk Reads/sec und Disk Writes/sec. OLTP-Anwendungen (Onlinetransaktionsverarbeitung) müssen höhere IOPS aufweisen, um eine optimale Leistung zu erzielen. Anwendungen wie Zahlungsverarbeitungssysteme, Online-Shopping und Points of Sale im Einzelhandel sind alles Beispiele für OLTP-Anwendungen.

Der Durchsatz ist die Datenmenge, die an den zugrunde liegenden Speicher gesendet wird, oft gemessen in Megabyte pro Sekunde. Messen Sie den Durchsatz mit den Leistungsmonitorindikatoren Disk Read Bytes/sec und Disk Write Bytes/sec. Data Warehousing ist hinsichtlich der Maximierung des Durchsatzes gegenüber IOPS optimiert. Anwendungen wie Datenspeicher für Analysen, Berichterstellung, ETL-Workstreams und andere Business Intelligence-Ziele sind alles Beispiele für Data Warehousing-Anwendungen.

Die Größe der E/A-Einheiten beeinflusst die IOPS- und Durchsatzleistung, da kleinere E/A-Größen höhere IOPS und höhere E/A-Größen einen höheren Durchsatz ergeben. SQL Server wählt automatisch die optimale E/A-Größe aus. Weitere Informationen finden Sie unter Optimieren von IOPS, Durchsatz und Wartezeit für Ihre Anwendungen.

Es gibt bestimmte Azure Monitor-Metriken, die von großem Nutzen sind, um die Begrenzung auf der Ebene des virtuellen Computers und der Datenträgerebene sowie den Verbrauch und die Integrität des AzureBlob-Caches zu entdecken. Informationen zum Identifizieren von wichtigen Indikatoren, die Sie zu Ihrer Überwachungslösung und dem Dashboard des Azure-Portals hinzufügen sollten, finden Sie unter Metriken zur Speicherauslastung.

Hinweis

Azure Monitor bietet derzeit keine Metriken auf Datenträgerebene für das kurzlebige temporäre Laufwerk (D:\). „Verbrauchte von der VM zwischengespeicherte IOPS in Prozent“ und „Prozentsatz der von der VM beanspruchten zwischengespeicherten Bandbreite“ spiegeln die IOPS und den Durchsatz vom kurzlebigen temporären Laufwerk (D:\) und der Hostzwischenspeicherung zusammen wider.

Überwachen des Wachstums von Transaktionsprotokollen

Da ein volles Transaktionsprotokoll zu Leistungsproblemen und Ausfällen führen kann, ist es wichtig, den verfügbaren Speicherplatz in Ihrem Transaktionsprotokoll zu überwachen und den genutzten Speicherplatz auf dem Datenträger, auf dem sich Ihr Transaktionsprotokoll befindet. Beheben Sie Probleme mit Transaktionsprotokollen, bevor sie sich auf Ihre Workload auswirken.

Siehe Problembehandlung bei vollen Transaktionsprotokollen, wenn Ihr Protokoll voll ist.

Wenn Sie Ihren Datenträger erweitern müssen, ist dies im Bereich „Speicher“ der Ressource für virtuelle SQL-Computer möglich, wenn Sie ein SQL Server-Image vom Azure Marketplace bereitgestellt haben, bzw. im Bereich „Datenträger“ für Ihren virtuellen Azure-Computer und selbst installierten SQL Server.

Nächste Schritte

Weitere Informationen finden Sie in auch in anderen Artikeln dieser Reihe zu den bewährten Methoden: