SQL Server Always On auf Proxmox VE: Architektur und Tuning

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.

• 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.

Get-NetAdapterRss | Format-List *

• 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

Mehr Queues beschleunigen nicht automatisch einen einzelnen TCP-Datenstrom. Vergleichen Sie unter derselben Last CPU-Verteilung, Latenz und Replikationsrückstand vor und nach der Änderung.

SELECT
  SYSDATETIMEOFFSET() AS sampled_at,
  adc.database_name,
  ar.replica_server_name,
  drs.synchronization_state_desc,
  drs.is_suspended,
  drs.log_send_queue_size AS log_send_kb,
  drs.redo_queue_size AS redo_kb
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar
  ON ar.replica_id = drs.replica_id
JOIN sys.availability_databases_cluster AS adc
  ON adc.group_database_id = drs.group_database_id
WHERE drs.is_local = 0
ORDER BY adc.database_name, ar.replica_server_name;

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.