Microsoft Azure stellt Platform as a Service (PaaS) Database Engine über die Azure SQL Database-Plattform bereit, sodass wir diese Datenbank für die Cloud-basierten Anwendungen verwenden können. Der Hauptvorteil der Azure SQL-Datenbank ist die einfache Skalierung ohne Ausfallzeiten und erfordert kein Versions-Upgrade oder Patching-Prozess. Außerdem müssen wir uns keine Sorgen um Hardwareprobleme machen.

Der wesentliche Aspekt der Azure SQL-Datenbank besteht jedoch darin, die Leistungsanforderungen der bereitgestellten Datenbank bei minimalen Kosten zu erfüllen. Zweifellos möchte niemand Geld für redundante Ressourcen oder Funktionen bezahlen, die er nicht nutzt oder zu nutzen beabsichtigt.

An dieser Stelle bietet Microsoft Azure zwei verschiedene Kaufmodelle an, um Kosteneffizienz zu bieten:

• Auf Database Transaction Units (DTU) basierendes Kaufmodell.
• Virtual Core (vCore)-basiertes Kaufmodell

Eine Kaufmodellentscheidung wirkt sich direkt auf die Datenbankleistung und die Gesamthöhe der Rechnungen aus. Meiner Meinung nach ist das DTU-basierte Kaufmodell besser geeignet, wenn die bereitgestellte Datenbank nicht zu viele Ressourcen verbraucht.

Nun werden wir die Details dieser beiden Kaufmodelle in den folgenden Abschnitten besprechen.

Auf Database Transaction Units (DTU) basierendes Kaufmodell

Um das DTU-basierte Kaufmodell besser zu verstehen, müssen wir klären, was eine DTU in Azure SQL-Datenbank sinnvoll macht. DTU ist eine Abkürzung für „Database Transaction Unit“ und beschreibt eine Leistungseinheitsmetrik für die Azure SQL-Datenbank. Wir können die DTU einfach mit der Pferdestärke eines Autos vergleichen, da sie sich direkt auf die Leistung der Datenbank auswirkt. DTU stellt eine Mischung aus den folgenden Leistungsmetriken als einzelne Leistungseinheit für Azure SQL-Datenbank dar:

• Prozessor
• Erinnerung
• Daten-E/A und Protokoll-E/A

Die Hauptidee des DTU-Konzepts besteht darin, Clients eine vorkonfigurierte Ressourcenkonfiguration anzubieten, um die Skalierung der Leistung über eine einzelne Metrik zu vereinfachen. Wenn wir beispielsweise mehr Leistung benötigen, können wir die Leiste verschieben und die Anzahl der DTU in Azure SQL-Datenbank erhöhen.

Das DTU-basierte Kaufmodell enthält drei verschiedene Serviceebenen, und diese Serviceebenen bieten unterschiedliche DTUs und Funktionsoptionen. Die folgende Tabelle zeigt die Dienstebenen, die am DTU-basierten Kaufmodell teilgenommen haben.

Wie wir sehen können, variieren die maximalen DTUs und Funktionen je nach Dienstebene. Außerdem wird das Preismodell in Bezug auf die Dienstebene geändert. Beispielsweise kostet die folgende Konfiguration für eine einzelne Datenbank im DTU-basierten Kaufmodell 584,00 $ pro Monat.

Elastischer Pool

Kurz gesagt, Elastic Pool hilft uns bei der automatischen Verwaltung und Skalierung mehrerer Datenbanken, die unvorhersehbare und unterschiedliche Ressourcenanforderungen an einen gemeinsam genutzten Ressourcenpool stellen. Durch den Elastic Pool müssen wir die Datenbanken nicht kontinuierlich gegen Schwankungen der Ressourcennachfrage skalieren. Die Datenbanken, die am Pool teilnehmen, verbrauchen die Ressourcen des Elastic Pools, wenn sie benötigt werden, aber sie können die Ressourcenbeschränkungen des Elastic Pools nicht überschreiten, sodass eine kostengünstige Lösung bereitgestellt wird.

Richtige Schätzung der DTU für Azure SQL-Datenbank

Nachdem wir uns entschieden haben, das DTU-basierte Kaufmodell zu verwenden, müssen wir die folgende Frage-Antwort mit logischen Gründen herausfinden:

• Welche Dienstebene und wie viele DTUs sind für meine Workload bei der Migration zu Azure SQL erforderlich?

Der DTU-Rechner wird die Hauptlösung zum Schätzen der DTU-Anforderungen sein, wenn wir lokale Datenbanken zu Azure SQL-Datenbank migrieren. Die Hauptidee dieses Tools besteht darin, die Nutzung verschiedener Metriken aus dem vorhandenen SQL Server zu erfassen, die sich auf die DTUs auswirken, und dann zu versuchen, die DTUs und die Dienstebene im Lichte der erfassten Leistungsnutzungen ungefähr zu schätzen. Der DTU-Rechner erfasst die folgenden Metriken entweder über das Befehlszeilendienstprogramm oder das PowerShell-Skript und speichert diese Metriken in einer CSV-Datei.

• Prozessor - % Prozessorzeit
• Logischer Datenträger – Datenträgerlesevorgänge/Sek.
• Logischer Datenträger – Schreibvorgänge/Sek.
• Datenbank - Gelöschte Protokollbytes/Sek.

In diesem Artikel lernen wir die Verwendung des Befehlszeilenprogramms kennen, da es sich um ein Open-Source-Projekt handelt und Codes auf GitHub gehostet werden. So können wir bei Bedarf problemlos Änderungen vornehmen. Nach dem Herunterladen und Entpacken des Befehlszeilenprogramms, zwei Dateien werden vor uns liegen.

SqlDtuPerfmon.exe.config hilft uns, einige Parameter des Command-Line Utility zu ermitteln:

CsvPath gibt den CSV-Dateipfad an, in dem die gesammelten Metriken gespeichert werden.

SampleInterval gibt an, in wie vielen Sekunden die Samples erfasst werden

MaxSamples gibt die maximale Anzahl von Samples an, die gesammelt werden.

An dieser Stelle müssen wir einige Überlegungen zum DTU-Rechner anstellen. Der DTU-Rechner erfasst die Gesamtauslastung der Metriken auf dem Computer. Aus diesem Grund müssen die anderen Prozesse, die sich auf die CPU-, Speicher- und Festplattennutzung auswirken, gestoppt werden, da es sonst schwierig wird, eine genaue DTU-Schätzung vorzunehmen. Ein weiteres Problem besteht darin, dass wir nach Möglichkeit die Nutzung der Metriken erfassen müssen, die Zeitintervalle mit Spitzenauslastung abdecken. Auf diese Weise bietet der DTU-Rechner die besten Empfehlungen und wir ermitteln den maximalen DTU-Bedarf mit einer ungefähreren Schätzung. Jetzt führen wir die SqlDtuPerfmon.exe aus und sie beginnt direkt mit der Erfassung der Ressourcennutzung und speichert die angegebene CSV-Datei.

Nach Abschluss der Erfassung der Ressourcennutzung geben wir die Anzahl der Kerne ein und laden die CSV-Datei auf die Website des DTU-Rechners hoch.

Wenn wir auf die Schaltfläche „Berechnen“ klicken, erscheint zunächst das Service-Tier-/Performance-Level-Kreisdiagramm auf dem Bildschirm und zeigt die geschätzten Service-Tier-Vorschläge in Segmente mit den prozentualen Details. Laut DTU-Rechner bietet Standard – S6-Tarif eine zufriedenstellende Leistung für diese Workload.

Direkt unter diesem Diagramm wird das Diagramm DTUs über Zeit angezeigt, und dieses Diagramm stellt die DTUs dar, die sich im Laufe des Zeitraums ändern. Bevor wir dieses Diagramm auswerten, können wir einige zusätzliche Informationen hinzufügen, um es einfacher zu interpretieren.

Wie Sie sehen können, stellt das Liniendiagramm eine instabile Arbeitslast dar, aber es war sinnvoller, als wir Informationshinweise hinzufügten. Meiner Meinung nach ist dieses Diagramm sehr nützlich, um die Wechselwirkung zwischen Workload-Änderungen und DTUs zu verstehen. Somit können wir eine genauere Schätzung der erforderlichen DTUs vornehmen. Wie wir am Anfang des Artikels erwähnt haben, sollte unser Hauptziel darin bestehen, eine kostengünstige Lösung für den Arbeitsaufwand zu finden.

Diese Vorschläge drücken jedoch nicht die genauen Anforderungen der DTU in Azure SQL aus. Aus diesem Grund müssen wir möglicherweise die Dienstebene oder das Kaufmodell nach der Bereitstellung der Datenbank in Azure SQL ändern.

Wenn wir auf „Weitere Details anzeigen“ klicken, werden einige zusätzliche Berichte angezeigt, und diese Berichte stellen die individuellen Empfehlungen für CPU-, IOPS- und Protokollressourcenauslastungen dar. Sie werden sehr hilfreich sein, um insbesondere diese Verwendungen zu verstehen.

Virtueller Kern (vCore)-basiertes Einkaufsmodell

Dieses Konzept ähnelt dem traditionellen Ansatz, da wir in der Lage sind, jede Ressource der Datenbank zu bestimmen. Wir können die VCores und die Optionen für die maximale Datengröße in diesem Modell manuell anordnen. Wir können jedoch die Speicherressource nicht bestimmen. Jeder VCore verfügt über dedizierten Speicher, und der dedizierte Wert des Speichers hängt von der Generation der VCores ab.

Als letztes können wir in diesem Modell die folgenden Dienstebenen auswählen:

• Allgemeiner Zweck.
• Geschäftskritisch.
• Hyperscale

Schlussfolgerung

In diesem Artikel haben wir die Kaufmodelle der Azure SQL-Datenbank untersucht und die Nutzungsanweisungen des DTU-Rechners aufgedeckt, um die erforderliche DTU in Azure SQL für lokale Datenbanken abzuschätzen.