Erläutern, wie Azure-Speicher für SQL Server-VMs optimiert werden
Die Speicherleistung ist ein kritischer Aspekt von E/A-intensiven Anwendungen wie beispielsweise einer Datenbank-Engine. Azure bietet eine Vielzahl von Speicheroptionen und kann sogar eine Speicherlösung für Sie erstellen, um Ihre Arbeitsauslastungsanforderungen zu erfüllen.
Azure Storage ist eine robuste und sichere Plattform, die für die vielfältigen Anforderungen verschiedener Anwendungen entwickelt wurde. Es bietet eine breite Palette skalierbarer Lösungen, die sicherstellen, dass alle Arten von Speichermedien die Verschlüsselung im Ruhezustand unterstützen. Benutzende können zwischen einem von Microsoft verwalteten Verschlüsselungsschlüssel und einem benutzerdefinierten Verschlüsselungsschlüssel wählen, um zusätzliche Sicherheit zu gewährleisten.
Blob Storage – Blob-Speicher ist eine als objektbasierter Speicher bekannte Technologie und umfasst kalte, heiße und Archivspeicherklassen. In einer SQL Server-Umgebung wird Blobspeicher typischerweise für Datenbanksicherungen verwendet. Dabei kommt die SQL Server-Funktion zur Sicherung per URL zum Einsatz.
Dateispeicher: Ein Dateispeicher ist im Grunde nichts anderes als eine Dateifreigabe, die in einem virtuellen Computer eingebunden werden kann, ohne dass Hardware eingerichtet werden muss. SQL Server kann einen Dateispeicher als Speicherziel für eine Failoverclusterinstanz verwenden.
Datenträgerspeicher – Von Azure verwaltete Datenträger bieten Blockspeicher, der einem virtuellen Computer angezeigt wird. Diese Datenträger werden genau wie physische Datenträger in einem lokalen Server verwaltet. Der einzige Unterschied besteht darin, dass sie virtualisiert sind. Bei verwalteten Datenträgern gibt es verschiedene Leistungsstufen, je nach Arbeitsauslastung. Dieser Speicher ist der gängigste Speichertyp für SQL Server-Daten- und Transaktionsprotokolldateien.
Azure Managed Disks
Verwaltete Azure-Datenträger sind Speichervolumes auf Blockebene, die Azure-VMs präsentiert werden. Als „Speicher auf Blockebene“ werden unformatierte Speichervolumes bezeichnet, die erstellt werden und als einzelne Festplatte behandelt werden können. Diese Blockgeräte können im Betriebssystem verwaltet werden, und die Speicherebene erhält keine Informationen zu den Inhalten des Datenträgers. Die Alternative zur Blockspeicherung ist die Objektspeicherung, bei der Dateien und ihre Metadaten im zugrunde liegenden Speichersystem gespeichert werden. Azure Blob Storage ist ein Beispiel für ein Objektspeichermodell. Objektspeicher funktionieren gut für viele moderne Entwicklungslösungen, die meisten Arbeitsauslastungen auf VMs dagegen verwenden Blockspeicher.
Die Konfiguration Ihrer verwalteten Datenträger ist wichtig für die Leistung Ihrer SQL Server-Arbeitsauslastungen. Wenn Sie von einer lokalen Umgebung wechseln, ist es wichtig, Metriken wie durchschnittliche Datenträger sekunden/lese - und durchschnittliche Datenträger-Sekunden/Schreibvorgänge von Performance Monitor zu erfassen, wie zuvor beschrieben. Eine weitere Metrik zur Erfassung ist die Anzahl der E/A-Vorgänge pro Sekunde, die mithilfe der Zähler SQL Server: Resource Pool Stats Disk Read and Write IO/sec erfasst werden können, welche aufzeigen, wie viele IOPs SQL Server auf seinem Höhepunkt bedient. Sie müssen Ihre Arbeitsauslastungen unbedingt genau verstehen. Ihr Ziel ist es, Speicher und VMs so zu entwerfen, dass die Anforderungen dieser Arbeitsauslastungsspitzen ohne erhebliche Latenzen erfüllt werden. Für jeden Azure-VM-Typ gilt eine bestimmte Obergrenze für IOPS.
Es gibt vier Arten von verwalteten Azure-Datenträgern:
Ultra-Datenträger: Ultra-Datenträger unterstützen Arbeitsauslastungen, die eine hohe Anzahl von E/A-Vorgängen aufweisen, für unternehmenskritische Datenbanken mit geringer Latenz.
Premium-SSD - Premium-SSD-Datenträger sind hochdurchsatz- und niedrige Latenz und können die Anforderungen der meisten Datenbankworkloads erfüllen, die in der Cloud ausgeführt werden.
Standard-SSD – Standard-SSDs sind für leicht verwendete Entwicklungs-/Testarbeitslasten oder Webserver ausgelegt, die eine kleine Menge E/A ausführen und vorhersehbare Latenz erfordern.
Standard-HDD - Standard-HDDs eignen sich für Sicherungen und Dateispeicher, auf die selten zugegriffen wird.
In der Regel verwenden SQL Server-Arbeitsauslastungen entweder Ultra Disks oder SSD Premium oder eine Kombination der beiden Typen. Ultra Disks kommen üblicherweise zum Einsatz, wenn bei der Antwortzeit eine Latenz von weniger als einer Millisekunde erforderlich ist. Datenträger vom Typ „SSD Premium“ weisen in der Regel eine Antwortzeit im einstelligen Millisekundenbereich auf, sind jedoch kostengünstiger und flexibler im Entwurf. Diese Datenträger unterstützen auch Lesecaches, die leseintensiven Datenbank-Arbeitsauslastungen zugute kommen, da die Anzahl von Datenträgerzugriffen reduziert wird. Der Lesecache wird auf dem lokalen SSD-Datenträger (Laufwerk D:\ unter Windows oder /dev/sdb1/ unter Linux) gespeichert, womit die Anzahl von Roundtrips auf dem tatsächlichen Datenträger reduziert wird.
Datenträgerstriping für maximalen Durchsatz
Eine der Möglichkeiten, um mehr Leistung und Volumes auf Azure-Datenträgern zu erzielen, ist das Striping der Daten auf mehreren Datenträgern. Diese Technik wird bei Ultra Disks nicht angewendet, da Sie IOPS, Durchsatz und maximale Größe auf einem einzelnen Datenträger unabhängig skalieren können. Bei SSD Premium-Datenträger kann es jedoch von Vorteil sein, sowohl IOPS als auch Speichervolume zu skalieren. Zum Datenträgerstriping unter Windows fügen Sie der VM die gewünschte Anzahl von Datenträgern hinzu und erstellen dann über das Subsystem „Speicherplätze“ unter Windows einen Pool. Konfigurieren Sie keine Redundanz für diesen Pool (dies würde die Leistung begrenzen). Redundanz wird über das Azure-Framework bereitgestellt, das zum Schutz vor einem Datenträgerausfall drei Kopien aller Datenträger in der synchronen Replikation verwaltet. Wenn Sie einen Pool erstellen, umfasst dieser die Summe der IOPS-Werte und die Summe der Volumes aller Datenträger im Pool. Ein Beispiel: Wenn Sie 10 P30-Datenträger mit jeweils 1 TB und 5.000 IOPS verwenden, steht im Pool ein 10-TB-Volume mit 50.000 IOPS zur Verfügung.
Best Practices für die SQL Server-Speicherkonfiguration
Es gibt einige Empfehlungen zu den Best Practices für SQL Server auf Azure-VMs und der entsprechenden Speicherkonfiguration:
- Erstellen Sie ein separates Volume für Daten- und Transaktionsprotokolldateien.
- Aktivieren Sie den Lesecache auf dem Datendateivolume.
- Aktivieren Sie keine Zwischenspeicherung auf dem Protokolldateivolume.
- Planen Sie beim Entwerfen des Speichers zusätzlich 20 % für IOPS und Durchsatz, damit Ihre VM Arbeitsauslastungsspitzen verarbeiten kann.
- Verwenden Sie für tempdb-Dateien das Laufwerk D: (die lokal angeschlossene SSD), da tempdb beim Neustart des Servers neu erstellt wird und daher kein Risiko eines Datenverlusts besteht.
- Aktivieren Sie die schnelle Dateiinitialisierung, um die Auswirkungen von Aktivitäten zu reduzieren, bei denen die Dateigröße wächst.
- Verschieben Sie die Verzeichnisse für Ablaufverfolgungsdatei und Fehlerprotokoll auf Datenträger für Daten.
- Bei Arbeitsauslastungen, die eine Speicherlatenz unter 1 Millisekunde erfordern, verwenden Sie Ultra Disk statt SSD Premium.
Azure-VM-Ressourcenanbieter
Eine Möglichkeit, die Komplexität der Speichererstellung für Ihre SQL Server-Instanz auf einer Azure-VM zu reduzieren, ist die Verwendung der SQL Server-Vorlagen im Azure Marketplace. Mit diesen Vorlagen können Sie den Speicher im Rahmen Ihrer Bereitstellung konfigurieren. Sie können die erforderlichen IOPS-Werte konfigurieren, und die Vorlage erstellt die Pools in Windows im Subsystem „Speicherplätze“.
Dieser Ressourcenanbieter unterstützt auch das Hinzufügen von tempdb zum lokalen SSD und erstellt eine geplante Aufgabe zum Erstellen des Ordners beim Start.