Sparen Sie bei Azure SQL-Datenbanken / Sudo Null IT News

Hallo alle! In diesem Artikel werde ich darüber sprechen, wie unser Unternehmen durch die Implementierung Geld sparen konnte Azure SQL-Pool für elastische Datenbanken. Weitere Beispiele werden sein Azure-REST-API zur Aufzählung von SQL-Servern, zur Aufzählung von SQL-Datenbanken und zum Abrufen von Metriken.

Die Neugierigsten erfahren am Ende des Artikels, wie viel gespart wurde. Wer zu faul zum Lesen ist, kann sofort zuschauen Quellen

Azure SQL-Pool für elastische Datenbanken

Ich werde den Link zum wunderbaren duplizieren Dokumentation von Microsoft. Kurz gesagt, wie können wir Geld sparen? – indem mehrere Basen zu einem Pool zusammengefasst werden – während die Ressourcen des Basispools gemeinsam ausgegeben werden.

Wenn du schaust Preise, werden wir sehen, dass die Ressourcen für den eDTU-Pool teurer sind als die Ressourcen für eine einzelne DTU-Basis (z. B. kosten 100 DTUs 147 USD pro Monat und 100 eDTUs bereits 220 USD). Daraus folgt eine einfache Schlussfolgerung: Wenn Sie eine Datenbank mit einer mehr oder weniger gleichmäßigen Auslastung haben, macht es keinen Sinn, sie dem Pool hinzuzufügen. Und umgekehrt – wenn es viele Datenbanken mit ungleichmäßiger Auslastung und zeitlichen Spitzen gibt – dann sind sie ideal für das Pooling.

Es stellt sich die Frage: Wie kann die Gesamtlast für alle Datenbanken von einem Server ermittelt werden? Im Portal können Sie zu einem bestimmten Zeitpunkt das DTU-Diagramm für eine Basis sehen – aber leider gibt es keine Möglichkeit, das zusammenfassende Diagramm anzuzeigen, das wir so dringend benötigen. Hilferuf Azure-REST-API.

Aufzählung und Abrufen von Metriken

Um mit Azure zu arbeiten, benötigen wir Folgendes Optionen. Lassen Sie uns zuerst den Code für schreiben einen Token erhalten. Dann bekommen wir alles für unser Abo Server. Danach für das, was wir brauchen Server wir bekommen Basisliste. Wir schreiben auch Code für Metriken bekommen.

Lassen Sie uns hinzufügen Logikin dem die Metriken für gespeichert werden die letzen paar Tage einzulegen bildenzur nachträglichen Visualisierung geeignet.

Achtung: In unserem Fall alle Datenbanken verwenden DTU-Kaufmodellweshalb hier die Metrik subtrahiert wird dtu_used. Wenn Sie für Datenbanken verwenden vCore-Kaufmodell, dann sind andere Metriken (z. B. cpu_percent) erforderlich, um die Last zu schätzen. Sie können die Liste der verfügbaren Metriken für verschiedene Azure-Ressourcen anzeigen hier. Das Methode mehr oder weniger universell – für andere Ressourcen sollten Metriken auch funktionieren.

Datenvisualisierung in Power BI

Es ist einfach implementiert. Öffnen Sie diese in Power BI Probe. Wir füttern ihn json im vorigen Schritt erhalten und wir erhalten Graphen dieser Art (im Bild gibt es einen Server mit ~ 90 Basen). Das obere Bild zeigt den Durchschnitt Durchschnitt pro Stunde, im unteren Durchschnitt maximal in einer Stunde. Für die genauesten Ergebnisse beim Subtrahieren von Metriken habe ich das Minimum verwendet Intervall in einer Minute (jeweils wird jeder Stundenmittelwert aus 60 Werten berechnet)

Aus den Diagrammen können wir ersehen, dass diese Art von Last für einen Pool großartig ist – viele leicht belastete Datenbanken mit seltenen Spitzen (siehe ähnliche Bild in der Dokumentation).

Lassen Sie uns die Einsparungen schätzen – wir haben etwa 90 Datenbanken mit jeweils 10 DTU (insgesamt 1260 $ pro Monat) Wir können all diese Last auf einen Pool mit einer Größe von 50 eDTU umleiten (110 $ pro Monat).

Insgesamt auf einem Server – 1100 $ Einsparungen pro Monat – nicht schlecht. Aber bevor Sie in den Pool gehen, müssen Sie analysieren Grenzen (da die Datenbanken mit einer Wahrscheinlichkeit von 99,9% leicht geladen sind, werden sie mehr als genug sein) und vergessen Sie nicht das Wichtigste –

Testen

Wenn Sie die Belastung der Datenbanken zum Zeitpunkt der Arbeit mit Ressourcen nicht vollständig stoppen können, empfehle ich Ihnen dringend, in der DEV \ QA-Umgebung sicherzustellen, dass solche Vorgänge wie:

  • Hinzufügen einer Datenbank zum Pool

  • Entfernen einer Datenbank aus einem Pool

  • Den Pool vergrößern

  • Den Pool verkleinern

Führen Sie nicht zu negativen Folgen für das Produkt.

Migrationsprozess

Wenn der Test erfolgreich war, können Sie die Migration starten. Ich empfehle ein schrittweises Vorgehen. Zuerst warfen sie in der DEV-Umgebung einige der am wenigsten belasteten Datenbanken in den Pool, beobachteten mehrere Tage lang die Auslastung des Pools und das Verhalten des Systems. Dann können Sie die restlichen Basen hinzufügen, erneut ansehen. Wenn auf der DEV-Umgebung alles in Ordnung ist, führen wir nach dem gleichen Prinzip die Migration in die QA und erst dann in die Produktion durch.

Es ist auch sinnvoll, das DTU-Limit pro Datenbank auf mindestens das Doppelte der Poolgröße festzulegen. Es schadet nicht, Warnungen für den Pool zu erstellen – sie sollten ausgelöst werden, wenn die Belastung des Pools nahe am Maximum liegt.

Ergebnisse

Wir haben in unserem Unternehmen mehrere Server in unterschiedlichen Umgebungen (DEV\QA\STG\PRD\PRDWEU) mit einer Vielzahl von Datenbanken. Durch einen einfachen Übergang von Einzeldatenbanken zu Pools begannen wir, ~ 8.000 US-Dollar pro Monat einzusparen. Gleichzeitig ist mit der Leistung alles in Ordnung – zur Veranschaulichung im Bild unten ein Pool mit 86 Basen. Es ist eine Freude, die Auslastung des Pools zu überwachen – hier wird bereits die Gesamtgrafik für alle Basen angezeigt

Wenn Sie über eine ähnliche Infrastruktur verfügen – viele leicht belastete Datenbanken mit seltenen Spitzen – empfehle ich Ihnen dringend, sich mit dem Thema „Azure SQL Elastic Pool“ zu befassen.

Danke an alle!

Similar Posts

Leave a Reply

Your email address will not be published.