SQL Server Availability Groups lassen sich technisch in Windows-VMs auf Proxmox VE aufbauen. Jede Replik hat eine eigene Datenkopie; SQL Server übernimmt die Replikation. Damit ist für die AG-Datenbanken kein gemeinsames Gast-Storage nötig. Für den produktiven Einsatz stimmen Sie Architektur, Edition, Lizenzen und Herstellersupport aufeinander ab. Dieser Beitrag betrachtet klassische Availability Groups unter Windows Server mit WSFC, nicht Linux- oder Read-Scale-Konfigurationen.
Getrennte Repliken
Eigene Datenkopien auf getrennten Hosts
Abgestimmtes Netzwerk
VirtIO, Multiqueue und RSS gemeinsam prüfen
Geprüfter Wechsel
Die Anwendung über den Listener wieder verbinden
Availability Group oder Failover Cluster Instance?
Always On ist ein Oberbegriff. Eine Availability Group (AG) repliziert ausgewählte Datenbanken zwischen SQL-Instanzen. Eine Failover Cluster Instance (FCI) schützt eine SQL-Instanz und benötigt eine geeignete gemeinsame beziehungsweise gemeinsam bereitgestellte Speicherlösung. Die beiden Ansätze haben unterschiedliche Anforderungen. Für diesen Entwurf verwenden wir eine AG mit zwei Windows-VMs.
Ein Zugang zum jeweils primären Replikat
Primäre SQL-Instanz
Sekundäre SQL-Instanz
Synchron oder asynchron nach Schutzziel
Unabhängige Fehlerdomäne. Keine dritte Datenbankkopie.
- SQL-Edition und Version bestimmen den Funktionsumfang. Basic Availability Groups der Standard Edition sind nicht mit vollständigen Enterprise-AGs gleichzusetzen.
- Auch bei getrennten virtuellen Disks kann darunter dasselbe SAN liegen. Prüfen Sie, welche gemeinsamen Ausfallpunkte tatsächlich entfallen.
Hosts, Quorum und Listener zusammen planen
Verteilen Sie die Repliken auf getrennte physische Hosts und prüfen Sie die Platzierung auch nach Wartung und Wiederanlauf. Der verbleibende Host muss die benötigte Last tragen können. Windows-Cluster und Proxmox-Cluster haben jeweils ein eigenes Quorum; ein Proxmox-Quorum ersetzt keine WSFC-Planung.
- WSFC validieren und ein passendes Witness-Konzept außerhalb der gemeinsam zu schützenden Fehlerdomäne vorsehen. Ein Witness ist keine zusätzliche Datenbankkopie.
- Listener, DNS, IP-Adressen, Firewall und SQL-Endpunkte gemeinsam konfigurieren. Die Anwendung soll nicht an einem festen VM-Namen hängen.
- Synchronous Commit für die gewünschte lokale Verfügbarkeit prüfen. Automatisches Failover erfordert unter anderem den passenden Modus, eine synchronisierte Zielreplik und WSFC-Quorum. Asynchrone Replikation kann bei erzwungenem Failover Daten verlieren.
Multiqueue in Proxmox und RSS in Windows abstimmen
Wenn die Paketverarbeitung einzelne vCPUs auslastet, kann VirtIO-Multiqueue helfen. Dafür müssen VM-Konfiguration und Gasttreiber zusammenpassen. Mehr Queues sind kein pauschaler Beschleuniger und erhöhen den CPU-Aufwand. Testen Sie die Änderung im Wartungsfenster, da Treiber- und Adapteränderungen die Verbindung unterbrechen können.
- 01
Proxmox-VM
VirtIO-NIC · Beispiel: 4 vCPUs
Q1Q2Q3Q4Multiqueue = 4 als Testkonfiguration - 02
Windows-Gast
VirtIO-Treiber · RSS aktiviert
RSS 1RSS 2RSS 3RSS 4Queue-Anzahl und wirksame CPU-Zuordnung prüfen - 03
Unter Last vergleichen
CPU-Verteilung, Latenz und SQL-Rückstände messen.
Mehr Queues sind kein garantierter Leistungsgewinn.
Get-NetAdapterRss | Format-List *Den betreffenden Adapter identifizieren. Enabled, NumberOfReceiveQueues und RssProcessorArray prüfen. Angezeigte Eigenschaften hängen von Treiber und Windows-Version ab.
- In Proxmox den VirtIO-Netzwerkadapter bearbeiten, die erweiterten Einstellungen öffnen und Multiqueue setzen. Die Dokumentation nennt die vCPU-Anzahl als Ausgangswert.
- Im Windows-Gerätemanager beim Red Hat VirtIO Ethernet Adapter unter „Erweitert“ Receive Side Scaling aktivieren und Maximum number of RSS Queues passend einstellen. Treiberversion und angebotene Werte beachten.
- Beispiel für einen Test: vier vCPUs, vier Proxmox-Queues und bis zu vier vom Gasttreiber unterstützte RSS-Queues. Anschließend den wirksamen Zustand prüfen, nicht nur den eingetragenen Wert.
Den Engpass messen, bevor Sie weiter tunen
RSS verteilt empfangene Datenströme auf mehrere Prozessoren. Ein einzelner TCP-Datenstrom wird dabei üblicherweise nicht beliebig über alle Kerne verteilt. Eine einzelne Replikationsverbindung muss deshalb durch mehr Queues nicht schneller werden. Vergleichen Sie dieselbe Last vor und nach der Änderung und betrachten Sie neben Durchsatz auch CPU-Verteilung, Latenz und Fehler.
- Eine wachsende Log Send Queue weist auf einen Rückstand beim Versand hin. Netzwerk, Log-Erzeugung und die Empfängerseite gemeinsam untersuchen.
- Eine wachsende Redo Queue zeigt Rückstand beim Anwenden bereits empfangener Log-Daten. Hier sind unter anderem CPU, Storage und blockierte Redo-Arbeit zu prüfen.
- Bei synchroner Replikation zählen Netzlatenz und das Schreiben des Logs auf der Gegenseite. HADR_SYNC_COMMIT-Wartezeiten sind ein Anlass zur Analyse, kein Beweis für zu wenige NIC-Queues.
Arbeitsspeicher und Storage verlässlich bereitstellen
Die SQL-VM braucht nicht möglichst viele vCPUs, sondern ausreichend verfügbare Ressourcen. Dimensionieren Sie nach gemessener Last und vermeiden Sie Speicherdruck auf dem Host. Reservieren Sie innerhalb der VM genügend Speicher für Windows und weitere Dienste, wenn Sie SQL Server max server memory festlegen.
- Daten, Transaktionslog und tempdb nach ihrem I/O-Verhalten betrachten. Getrennte virtuelle Disks schaffen allein noch keine getrennte physische Leistung.
- CPU-Modell und NUMA-Auslegung mit der Host-Hardware und den geplanten Migrationszielen abstimmen. Einstellungen nur mit einem reproduzierbaren Vorher-Nachher-Test ändern.
- Offloads, Jumbo Frames und Cache-Modi nicht gesammelt auf Verdacht ändern. Insbesondere Schreibbestätigungen und Flush-Verhalten müssen über den gesamten Storage-Pfad zuverlässig bleiben.
Failover aus Sicht der Anwendung abnehmen
Testen Sie geplanten Rollenwechsel, Ausfall eines Hosts und die Wiederkehr der Replik getrennt. Entscheidend ist, wann ein Nutzer wieder arbeiten kann und ob seine Transaktionen korrekt verarbeitet werden. Legen Sie Freigaben und Abbruchkriterien fest, bevor Sie Fehler auslösen.
- Über den Listener verbinden, laufende Transaktionen prüfen und Wiederverbindungszeit der Anwendung messen.
- Bei klassischen, nicht enthaltenen AGs Logins, SQL-Agent-Jobs und weitere instanzbezogene Objekte separat auf den Repliken bereitstellen und synchron halten.
- Nach Wartung Synchronisationszustand und Rückstände prüfen. Den nächsten Knoten erst bearbeiten, wenn die vereinbarte Redundanz wiederhergestellt ist.
- SQL-taugliche Sicherungen und Wiederherstellung unabhängig von der AG testen. Replikation ersetzt kein Backup.
Den produktiven Einsatz vollständig freigeben
Technische Machbarkeit und Herstellersupport sind getrennte Fragen. Microsoft knüpft den regulären Virtualisierungssupport unter anderem an validierte Konfigurationen. Prüfen Sie die konkrete Plattformkombination im SVVP-Kontext sowie die Anforderungen an Gast-Clustering. Für nicht validierte Umgebungen kann der Support eingeschränkt sein oder eine Fehlernachstellung außerhalb der Virtualisierung verlangen.
- Windows-, SQL- und VirtIO-Versionen sowie den Supportweg vor dem produktiven Einsatz dokumentieren. Dieser Beitrag behauptet keine SVVP-Zertifizierung von Proxmox.
- SQL- und Windows-Lizenzen einschließlich Sekundärreplik, Testbetrieb und Verschiebung zwischen Hosts anhand der geltenden Verträge prüfen. Passive Repliken sind nicht pauschal lizenzfrei.
Diese Fragen sollten geklärt sein
- Ist klar, ob eine AG oder eine FCI gebraucht wird?
- Sind Repliken, Quorum und Witness gegen die relevanten Ausfälle ausgelegt?
- Passen VirtIO-Queues und die wirksamen RSS-Einstellungen im Gast zusammen?
- Zeigen Lasttests einen messbaren Nutzen der Änderungen?
- Sind Anwendungsfailover, Restore, Lizenzierung und Support geklärt?