Automatisieren Sie die SQL Server DR-Lizenzierung in Azure für maximale Kosteneinsparungen

Ein tiefer Einblick in den Aufbau eines kostenoptimierten, stabilen und vollständig automatisierten Lizenzierungsworkflows für Ihre SQL Server-Disaster-Recovery-Umgebung.

Erfahren Sie mehr:So lösen Sie Probleme mit der maximalen Anzahl an Worker-Threads in SQL Server

1. Das Lizenzierungsrahmenwerk

Ein effektives Lizenzmanagement ist eine strategische Notwendigkeit zur Kostenoptimierung. Im DR-Kontext ist das Verständnis der Lizenztypen „DR“ und „AHUB“ von entscheidender Bedeutung. Das Beste daran? Der Wechsel zwischen ihnen ist ein unterbrechungsfreier, reiner Metadatenvorgang ohne Ausfallzeiten, der durch die SQL IaaS Agent Extension ermöglicht wird.

Interaktiver Lizenzvergleich

Kostenauswirkungen

Erfordernis

Automatisierungsflagge

Snippets zur Programmsteuerung

Verwenden Sie diese unterbrechungsfreien Befehle in Ihren Automatisierungsskripten, um den Lizenztyp im Handumdrehen umzuschalten.

2. Architektonischer Entwurf

Ein einfaches Skript reicht für einen 30-tägigen Stateful-Prozess nicht aus. Wir benötigen eine belastbare Architektur, die mehrere Azure-Dienste zur Erkennung, Orchestrierung, Aktion und Zustandsverwaltung kombiniert.

Infografik zu Lösungskomponenten

Azure-Automatisierung
(Erkennungs-Runbook)

Logik-Apps
(Orchestrierung)

Automatisierung
(Action Runbooks)

Tischaufbewahrung
(Staatsverwaltung)

Schreibt Staat
Liest den Status

3. Die Erkennungsmaschine

Ein Failover in einer IaaS-VM ist ein In-Guest-Ereignis, das für das Azure-Aktivitätsprotokoll unsichtbar ist. Das bedeutet, dass wir keine einfachen ereignisbasierten Warnungen verwenden können. Wir müssen den Status der VM aktiv mithilfe eines geplanten Runbooks und des leistungsstarken „Invoke-AzVMRunCommand“ abfragen.

Profi-Tipp:Die größte Herausforderung besteht darin, dass ein IaaS-Failover kein ARM-Ereignis generiert. Unsere Erkennungslogik muss die SQL-Instanz *innerhalb* der VM abfragen, um ihre wahre Rolle zu ermitteln.

Erkennungs-Runbook

Dieses PowerShell-Runbook authentifiziert sich mithilfe einer verwalteten Identität, fragt die SQL-Rolle der VM ab, vergleicht sie mit dem Status im Tabellenspeicher und löst die entsprechende Logik-App aus.

4 und 5. Failover- und Failback-Workflows

Wir verwenden zwei unterschiedliche Logik-Apps, um den Prozess zu orchestrieren. Die Failover-App verwaltet die 30-tägige Verzögerung, während die Failback-App eine sofortige Wiederherstellung ermöglicht und, was entscheidend ist, den laufenden Failover-Prozess abbricht.

Failover-Workflow (30-Tage-Verzögerung)

1. Von der Erkennung empfangener HTTP-Trigger.
2. Statustabelle aktualisieren: Status auf „FailoverDetected“ setzen, „LogicAppRunID“ speichern.
3. Aktion „30-Tage-Verzögerung“ starten.
4. Überprüfen Sie nach der Verzögerung den Status erneut anhand der Tabelle.
5. Wenn der Status immer noch „FailoverDetected“ lautet:
   • Rufen Sie das Runbook „Set-LicenseToAHUB“ auf.
   • Statustabelle aktualisieren: Status auf „Primär“ setzen.

Failback-Workflow (sofortige Aktion)

1. Von der Erkennung empfangener HTTP-Trigger.
2. Rufen Sie sofort das Runbook „Set-LicenseToDR“ auf.
3. Holen Sie sich „LogicAppRunID“ aus der Statustabelle.
4. Verwenden Sie die Aktion „Ausführung abbrechen“, um die In-Flight-Failover-Logik-App zu beenden.
5. Statustabelle aktualisieren: Status auf „Passiv“ setzen, Lauf-ID löschen.

6. Bereitstellung und Kostenauswirkungen

Die Bereitstellung mit IaC (Bicep/ARM) gewährleistet Konsistenz. Die Überwachung von Fehlern in der Automatisierung selbst ist von entscheidender Bedeutung. Aber die wahre Geschichte sind die Kosteneinsparungen.

Interaktive Kosteneinsparungsanalyse

Passen Sie den Schieberegler an, um die geschätzten monatlichen Einsparungen anzuzeigen, indem Sie den „DR“-Lizenzvorteil anstelle von „PAYG“ für eine passive Replik verwenden.

SQL-VM-Größe (vCPUs)

4 vCPUs
16 vCPUs
32 vCPUs
64 vCPUs