Voraussetzungen, Einschränkungen und Empfehlungen für Always On-Verfügbarkeitsgruppen

Gilt für:SQL Server

In diesem Artikel werden Überlegungen zur Bereitstellung von Always On-Verfügbarkeitsgruppen beschrieben, einschließlich Voraussetzungen, Einschränkungen und Empfehlungen für Hostcomputer, Windows Server-Failovercluster (WSFC), Serverinstanzen und Verfügbarkeitsgruppen. Für alle Komponenten sind Überlegungen zur Sicherheit und ggf. erforderliche Berechtigungen angegeben.

.NET-Hotfixes mit Unterstützung für Verfügbarkeitsgruppen

Abhängig von den SQL Server-Komponenten und -Features, die Sie mit Always On-Verfügbarkeitsgruppenverwenden, müssen Sie möglicherweise zusätzliche in der folgenden Tabelle angegebene .NET-Hotfixes installieren. Die Hotfixes können in beliebiger Reihenfolge installiert werden.

Prüfliste: Anforderungen (Windows-System)

Zur Unterstützung der Funktion Always On-Verfügbarkeitsgruppen muss gewährleistet sein, dass jeder Computer, der an mindestens einer Verfügbarkeitsgruppe teilnehmen soll, die folgenden wesentlichen Anforderungen erfüllt:

Empfehlungen für Computer, die Verfügbarkeitsreplikate (Windows-System) hosten

• Vergleichbare Systeme: Für eine bestimmte Verfügbarkeitsgruppe sollten alle Verfügbarkeitsreplikate auf vergleichbaren Systemen ausgeführt werden, die identische Workloads bewältigen können.

• Dedizierte Netzwerkadapter: Für eine optimale Leistung sollten Sie einen dedizierten Netzwerkadapter (NIC, Network Interface Card, Netzwerkschnittstellenkarte) für Always On-Verfügbarkeitsgruppen verwenden.

• Ausreichender Speicherplatz auf dem Datenträger: Jeder Computer, auf dem eine Serverinstanz ein Verfügbarkeitsreplikat hostet, muss über ausreichend Speicherplatz auf dem Datenträger für alle Datenbanken in der Verfügbarkeitsgruppe verfügen. Bedenken Sie, dass sekundäre Datenbanken in gleichem Maße zunehmen wie ihre entsprechenden primären Datenbanken.

Berechtigungen (Windows-System)

Zur Verwaltung eines WSFC muss der Benutzer Systemadministrator auf jedem Clusterknoten sein.

Weitere Informationen über das Konto zum Verwalten des Clusters finden Sie unter Appendix A: Failover Cluster Requirements (Anhang A: Failoverclusteranforderungen).

Verwandte Aufgaben (Windows-System)

Ändern des HostRecordTTL (Verwenden von Windows PowerShell)

1. Öffnen Sie das PowerShell-Fenster über Als Administrator ausführen.

2. Importieren Sie das FailoverClusters-Modul.

3. Verwenden Sie das Get-ClusterResource -Cmdlet, um die Netzwerknamenressource anzuzeigen, und verwenden Sie das Set-ClusterParameter -Cmdlet, um den HostRecordTTL -Wert wie folgt festzulegen:

   Get-ClusterResource „<Netzwerkressourcenname>“ | Set-ClusterParameter-HostRecordTTL <Zeit_in_Sekunden>

   Im folgenden PowerShell-Beispiel wird der HostRecordTTL für eine Netzwerknamenressource mit dem Namen SQL Network Name (SQL35) auf 300 Sekunden festgelegt.

   Import-Module FailoverClusters
   
   $nameResource = "SQL Network Name (SQL35)"
   Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300
   

   Tipp

   Bei jedem Öffnen eines neuen PowerShell-Fensters müssen Sie das FailoverClusters -Modul importieren.

Verwandte Inhalte (PowerShell)

• Clustering and High-Availability (Clustering und hohe Verfügbarkeit) (Failoverclustering und Netzwerklastenausgleichs-Teamblog)

• Erste Schritte mit Windows PowerShell auf einem Failovercluster

• Clusterressourcenbefehle und entsprechende Windows PowerShell-Cmdlets

Verwandte Inhalte (Windows-System)

• Konfigurieren von DNS-Einstellungen in einem Failovercluster für mehrere Standorte

• DNS-Registrierung mit Netzwerknamenressource

Voraussetzungen und Einschränkungen für SQL Server-Instanzen

Jede Verfügbarkeitsgruppe erfordert einen Satz Failoverpartner, die als Verfügbarkeitsreplikatebezeichnet und von Instanzen von SQL Servergehostet werden. Bei einer angegebenen Serverinstanz kann es sich um eine eigenständige Instanz oder eine SQL ServerFailovercluster-Instanz (FCI) handeln.

In diesem Abschnitt:

• Prüfliste: Voraussetzungen
• Threadverwendung durch Verfügbarkeitsgruppen
• Berechtigungen
• Verwandte Aufgaben
• Verwandte Inhalte

Prüfliste: Voraussetzungen (Serverinstanz)

Eine Liste der Features, die von den SQL Server-Editionen auf Windows unterstützt werden, finden Sie hier:

• Editionen und unterstützte Features von SQL Server 2022
• Editionen und unterstützten Features von SQL Server 2019
• Editionen und unterstützten Funktionen von SQL Server 2017
• Editionen und unterstützten Funktionen von SQL Server 2016

Threadverwendung durch Verfügbarkeitsgruppen

Always On-Verfügbarkeitsgruppen stellt die folgenden Anforderungen an Arbeitsthreads:

• Auf einer SQL Server-Instanz im Leerlauf verwendet Always On-Verfügbarkeitsgruppen 0 Threads.

• Die maximale Anzahl der von Verfügbarkeitsgruppen verwendeten Threads entspricht der Einstellung, die als maximale Anzahl von Serverthreads ('maximale Anzahl von Workerthreads') minus 40 konfiguriert wurde.

• Die auf einer bestimmten Serverinstanz gehosteten Verfügbarkeitsreplikate verwenden einen einzelnen Threadpool in SQL Server 2019 (15.x) und früheren Versionen.

  Threads werden bedarfsgesteuert wie folgt freigegeben:

  • In der Regel gibt es 3 bis 10 freigegebene Threads, diese Zahl kann sich jedoch abhängig von der Arbeitsauslastung des primären Replikats erhöhen.

  • Wenn ein bestimmter Thread eine Zeit lang im Leerlauf ist, wird er wieder im allgemeinen SQL Server -Threadpool freigegeben. Normalerweise wird ein inaktiver Thread nach ~ 15 Sekunden Inaktivität freigegeben. Abhängig von der letzten Aktivität kann ein Thread jedoch länger im Leerlauf gehalten werden.

  • Eine SQL Server-Instanz verwendet bis zu 100 Threads für parallele Wiederholung für sekundäre Replikate. Für jede Datenbank wird bis zur Hälfte der Gesamtzahl von CPU-Kernen, jedoch nicht mehr als 16 Threads pro Datenbank verwendet. Überschreitet die Gesamtzahl von erforderlichen Threads für eine einzelne Instanz den Wert 100, verwendet SQL Server einen einzelnes Wiederholungsthread für jede verbleibende Datenbank. Serielle Wiederholungsthreads werden nach ca. 15 Sekunden Inaktivität freigegeben.

• Darüber hinaus verwenden Verfügbarkeitsgruppen nicht freigegebene Threads wie folgt:

  • Jedes primäre Replikat verwendet einen Protokollaufzeichnungsthread für jede primäre Datenbank. Außerdem verwendet es einen Protokollsendethread für jede sekundäre Datenbank. Protokollsendethreads werden nach ~ 15 Sekunden Inaktivität freigegeben.

  • Von einer Sicherung auf einem sekundären Replikat wird ein Thread auf dem primären Replikat für die Dauer des Sicherungsvorgangs beibehalten.

• SQL Server 2022 (16.x) führte den parallelen Redo-Threadpool ein, der für alle Datenbanken freigegeben ist, die Redo-Arbeit haben. Mit diesem Pool können dieselben Threads die Protokolldatensätze für verschiedene Datenbanken gleichzeitig verarbeiten (parallel). In SQL Server 2019 (15.x) und früheren Versionen ist die Anzahl der verfügbaren Threads zum Wiederholen auf 100 beschränkt.

• In SQL Server 2019 (15.x) wurde eine parallele Rollforwardphase für arbeitsspeicheroptimierte Datenbanken in Verfügbarkeitsgruppen eingeführt. In SQL Server 2016 (13.x) und SQL Server 2017 (14.x) verwenden datenträgerbasierte Tabellen keine parallele Rollforwardphase, wenn eine Datenbank in einer Verfügbarkeitsgruppe ebenfalls arbeitsspeicheroptimiert ist.

Weitere Informationen finden Sie unter Always On – HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (Always On – HADRON-Lernreihe: Nutzung des Arbeitspools für HADRON-fähige Datenbanken) (ein CSS-SQL Server-Engineer-Blogbeitrag).

Berechtigungen (Serverinstanz)

Verwandte Aufgaben (Serverinstanz)

Verwandte Inhalte (Serverinstanz)

• Always On – HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (Always On – HADRON-Lernreihe: Nutzung des Arbeitspools für HADRON-fähige Datenbanken)

Empfehlungen zur Netzwerkkonnektivität

Es wird dringend empfohlen, für die Kommunikation zwischen WSFC-Knoten die gleichen Netzwerkverbindungen zu verwenden wie für die Kommunikation zwischen Verfügbarkeitsreplikaten. Bei Verwendung separater Netzwerkverbindungen kann ein unerwartetes Verhalten auftreten, wenn einige Verbindungen (wenn auch nur vorübergehend) ausfallen.

Damit eine Verfügbarkeitsgruppe automatisches Failover unterstützt, muss das sekundäre Replikat, das dem automatischen Failoverpartner entspricht, beispielsweise den Status SYNCHRONIZED aufweisen. Wenn bei der Netzwerkverbindung mit dem sekundären Replikat (wenn auch nur vorübergehend) ein Fehler auftritt, wechselt das Replikat in den Status UNSYNCHRONIZED und wird erst nach Wiederherstellen der Verbindung erneut synchronisiert. Wenn der WSFC ein automatisches Failover anfordert, während das sekundäre Replikat nicht synchronisiert ist, findet kein automatisches Failover statt.

Unterstützung für Clientkonnektivität

Informationen zur Unterstützung von Always-On-Verfügbarkeitsgruppen für die Clientkonnektivität finden Sie unter Treiber- und Clientkonnektivitätsunterstützung für Verfügbarkeitsgruppen.

Voraussetzungen und Einschränkungen zum Hosten eines Verfügbarkeitsreplikats mithilfe einer SQL Server-Failoverclusterinstanz (FCI)

In diesem Abschnitt:

• Einschränkungen
• Prüfliste: Voraussetzungen
• Verwandte Aufgaben
• Verwandte Inhalte

Einschränkungen (FCIs)

• Die Clusterknoten einer FCI können für eine angegebene Verfügbarkeitsgruppe nur ein Replikat hosten: Wenn Sie ein Verfügbarkeitsreplikat auf einer FCI hinzufügen, können die WSFC, die mögliche FCI-Besitzer sind, kein anderes Replikat für dieselbe Verfügbarkeitsgruppe hosten. Um potenzielle Konflikte zu vermeiden, empfiehlt es sich, mögliche Besitzer für die Failoverclusterinstanz zu konfigurieren. Damit kann verhindert werden, dass ein einzelner WSFC versucht, zwei Verfügbarkeitsreplikat für dieselbe Verfügbarkeitsgruppe zu hosten.

  Darüber hinaus muss jedes weitere Replikat von einer SQL Server-Instanz gehostet werden, die sich auf einem anderen Clusterknoten im selben WSFC befindet. Die einzige Ausnahme besteht darin, dass sich eine Verfügbarkeitsgruppe während der Migration zu einem anderen Cluster vorübergehend auf zwei Cluster erstrecken kann.

  Warnung

  Die Verwendung des Failovercluster-Managers zum Verschieben einer FCI, die eine Verfügbarkeitsgruppe hostet, auf einen Knoten, der bereits ein Replikat derselben Verfügbarkeitsgruppe hostet, kann zum Verlust des Verfügbarkeitsgruppenreplikats führen, sodass dieses auf dem Zielknoten nicht online geschaltet werden kann. Ein einzelner Knoten eines Failoverclusters kann nicht mehr als ein Replikat für dieselbe Verfügbarkeitsgruppe hosten. Weitere Informationen dazu, wie eine solche Situation eintritt und wie sie gelöst werden kann, finden Sie im Blog Replica unexpectedly dropped in availability group (Replikat in Verfügbarkeitsgruppe unerwartet gelöscht).

• Failoverclusterinstanzen (FCIs) unterstützen kein automatisches Failover durch Verfügbarkeitsgruppen: Da FCIs kein automatisches Failover durch Verfügbarkeitsgruppen unterstützen, können die Verfügbarkeitsreplikate, die von einer FCI gehostet werden, nur für manuelles Failover konfiguriert werden.

• Ändern des FCI-Netzwerknamens: Falls Sie den Netzwerknamen einer FCI ändern müssen, die ein Verfügbarkeitsreplikat hostet, müssen Sie das Replikat aus seiner Verfügbarkeitsgruppe entfernen und das Replikat dann wieder der Verfügbarkeitsgruppe hinzufügen. Sie können das primäre Replikat nicht entfernen. Wenn Sie daher eine FCI umbenennen, die das primäre Replikat hostet, sollten Sie ein Failover zu einem sekundären Replikat ausführen und dann das vorherige primäre Replikat entfernen und wieder hinzufügen. Beachten Sie, dass durch Umbenennen einer FCI möglicherweise die URL ihres Datenbankspiegelungs-Endpunkts geändert wird. Stellen Sie beim Hinzufügen des Replikats sicher, dass Sie die aktuelle Endpunkt-URL angeben.

Prüfliste: Voraussetzungen (FCIs)

Verwandte Aufgaben (FCIs)

Verwandte Inhalte (FCIs)

• Failoverclustering und Always On-Verfügbarkeitsgruppen (SQL Server)

• Always On-Architekturhandbuch: Erstellen einer Lösung für Hochverfügbarkeit und Notfallwiederherstellung unter Verwendung von Failoverclusterinstanzen und Verfügbarkeitsgruppen

Voraussetzungen und Einschränkungen für Verfügbarkeitsgruppen

In diesem Abschnitt:

• Einschränkungen
• Anforderungen
• Security
• Verwandte Aufgaben

Einschränkungen (Verfügbarkeitsgruppen)

• Verfügbarkeitsreplikate müssen von verschiedenen Knoten eines WSFC gehostet werden: Für eine angegebene Verfügbarkeitsgruppe müssen Verfügbarkeitsreplikate von Serverinstanzen gehostet werden, die auf verschiedenen Knoten desselben WSFC ausgeführt werden. Die einzige Ausnahme besteht darin, dass sich eine Verfügbarkeitsgruppe während der Migration zu einem anderen Cluster vorübergehend auf zwei Cluster erstrecken kann.

  Hinweis

  Virtuelle Computer können auf demselben physischen Computer jeweils ein Verfügbarkeitsreplikat für dieselbe Verfügbarkeitsgruppe hosten, da jeder virtuelle Computer als separater Computer fungiert.

• Eindeutiger Verfügbarkeitsgruppenname: Jeder Verfügbarkeitsgruppenname muss auf dem WSFC eindeutig sein. Die maximale Länge eines Verfügbarkeitsgruppennamens beträgt 128 Zeichen.

• Verfügbarkeitsreplikate: Jede Verfügbarkeitsgruppe unterstützt ein primäres Replikat und bis zu acht sekundäre Replikate. Alle Replikate können im Modus für asynchrone Commits ausgeführt werden. Alternativ können bis zu fünf Replikate im Modus für synchrone Commits ausgeführt werden (ein primäres Replikat mit zwei synchronen sekundären Replikaten). Jedes Replikat muss sowohl in Windows als auch in SQL Server über einen eindeutigen Servernamen verfügen. Die Servernamen müssen zwischen Windows und SQL Server übereinstimmen.

• Maximale Anzahl von Verfügbarkeitsgruppen und Verfügbarkeitsdatenbanken pro Computer: Die tatsächliche Anzahl der auf einem Computer (virtuell oder physisch) ausführbaren Datenbanken und Verfügbarkeitsgruppen richtet sich nach der Hardware und Workload, es gibt jedoch keine maximale Vorgabe. Microsoft hat bis zu 10 Verfügbarkeitsgruppen und 100 Datenbanken pro physischem Computer getestet, aber dies stellt keinen bindenden Grenzwert dar. Abhängig von der Hardwarespezifikation auf dem Server und dem Workload können Sie eine höhere Anzahl von Datenbanken und Verfügbarkeitsgruppen auf einer Instanz von SQL Server platzieren. Anzeichen für eine Systemüberlastung könnten u.a. zu wenige Arbeitsthreads, langsame Antwortzeiten für Verfügbarkeitsgruppen-Systemsichten und DMVs und/oder Systemspeicherabbilder bei angehaltenem Verteiler sein. Es wird empfohlen, die Umgebung unter produktionsähnlichen Bedingungen eingehend zu testen, um zu gewährleisten, dass das System maximale Arbeitsauslastungen im Rahmen Ihrer Anwendungs-SLAs bewältigen kann. Im Hinblick auf SLAs sollten sowohl die Auslastung unter Fehlerbedingungen als auch die erwarteten Antwortzeiten abgewogen werden.

• Verwenden Sie den Failovercluster-Manager nicht, um Verfügbarkeitsgruppen zu bearbeiten. Der Status einer SQL Server-FCI wird von SQL Server und dem Windows Server-Failovercluster (WSFC) gemeinsam verwendet, wobei SQL Server ausführlichere Zustandsinformationen zu den Instanzen verwaltet als für den Cluster von Interesse sind. Das Verwaltungsmodell sieht so aus, dass SQL Server die Transaktionen steuern muss und dafür zuständig ist, die Sicht des Status des Clusters synchron mit der Sicht des Status von SQL Server zu halten. Wenn der Status des Clusters außerhalb von SQL Server geändert wird, kann die Synchronisierung des Status zwischen WSFC und SQL Server verloren gehen, was zu nicht vorhersehbarem Verhalten führen kann.

  Zum Beispiel:

  • Ändern Sie keine Verfügbarkeitsgruppeneigenschaften, z. B. die möglichen Besitzer.

  • Verwenden Sie den Failovercluster-Manager nicht, um Failover für Verfügbarkeitsgruppen auszuführen. Sie müssen Transact-SQL oder SQL Server Management Studio verwenden.

• Fügen Sie keine Ressourcen hinzu, oder ändern Sie keine Abhängigkeiten, die der Verfügbarkeitsgruppenrolle zugeordnet sind. Es wird nicht empfohlen, zusätzliche Ressourcen (einschließlich Benutzer*innen oder Drittanbietern) in der Verfügbarkeitsgruppenrolle zu platzieren oder die Rollenabhängigkeiten zu ändern, da sich diese Änderungen negativ auf die Failoverleistung auswirken können.

Voraussetzungen (Verfügbarkeitsgruppen)

Beim Erstellen oder Neukonfigurieren einer Verfügbarkeitsgruppenkonfiguration müssen Sie folgende Anforderungen einhalten.

Sicherheit (Verfügbarkeitsgruppen)

• Die Sicherheit wird vom WSFC vererbt. WSFC bieten zwei Sicherheitsebenen mit der Granularität eines kompletten Clusters:

  • Schreibgeschützter Zugriff

  • Vollzugriff

    Always On-Verfügbarkeitsgruppen benötigt Vollzugriff. Durch Aktivieren von Always On-Verfügbarkeitsgruppen auf einer Instanz von SQL Server wird der Vollzugriff auf den Cluster erteilt (über Dienst-SID).

    Sie können im Cluster-Manager die Sicherheit für eine Serverinstanz nicht direkt hinzufügen oder entfernen. Um Clustersicherheitssitzungen zu verwalten, verwenden Sie den SQL Server-Konfigurations-Manager oder die WMI-Entsprechung von SQL Server.

• Jede Instanz von SQL Server muss über Berechtigungen zum Zugreifen auf die Registrierung, den Cluster usw. verfügen.

• Es wird empfohlen, dass Sie eine Verschlüsselung für Verbindungen zwischen Serverinstanzen verwenden, die Always On-Verfügbarkeitsgruppen -Verfügbarkeitsreplikate hosten.

Berechtigungen (Verfügbarkeitsgruppen)

Verwandte Aufgaben (Verfügbarkeitsgruppen)

Voraussetzungen und Einschränkungen für Verfügbarkeitsdatenbanken

Damit einer Verfügbarkeitsgruppe eine Datenbank hinzugefügt werden kann, muss sie folgenden Voraussetzungen und Einschränkungen entsprechen:

In diesem Abschnitt:

• Anforderungen
• Einschränkungen
• Empfehlungen für Computer, die Verfügbarkeitsreplikate (Windows-System) hosten
• Berechtigungen
• Verwandte Aufgaben

Prüfliste: Anforderungen (Verfügbarkeitsdatenbanken)

Damit eine Datenbank einer Verfügbarkeitsgruppe hinzugefügt zu werden, müssen folgende Bedingungen für die Datenbank zutreffen:

Einschränkungen (Verfügbarkeitsdatenbanken)

• Falls sich der Dateipfad (einschließlich des Laufwerkbuchstabens) einer sekundären Datenbank vom Pfad der entsprechenden primären Datenbank unterscheidet, gelten folgende Einschränkungen.

  • Assistent für neue Verfügbarkeitsgruppen/Assistent zum Hinzufügen von Datenbanken zu Verfügbarkeitsgruppen: Die Option Vollständig wird nicht unterstützt (auf der Seite Anfängliche Datensynchronisierung auswählen (Assistent für Always-On-Verfügbarkeitsgruppen)).

  • RESTORE WITH MOVE: Zum Erstellen der sekundären Datenbanken müssen die Datenbankdateien auf jeder Instanz von SQL Server, die ein sekundäres Replikat hostet, auf RESTORED WITH MOVE festgelegt sein.

  • Auswirkungen auf Dateihinzufügungsvorgänge: Bei einer späteren Dateihinzufügung auf dem primären Replikat tritt in den sekundären Datenbanken möglicherweise ein Fehler auf. Dieser Fehler kann bewirken, dass die sekundären Datenbanken angehalten werden. Dies bewirkt dann, dass die sekundären Replikate den Status NOT SYNCHRONIZING erhalten.

    Hinweis

    Informationen zum Reagieren auf einen Dateihinzufügungsvorgang, bei dem ein Fehler aufgetreten ist, finden Sie unter Problembehandlung bei einem nicht erfolgreichen Vorgang zum Hinzufügen einer Datei (Always On-Verfügbarkeitsgruppen).

• Sie können keine Datenbank löschen, die aktuell einer Verfügbarkeitsgruppe angehört.

Nachverfolgung für TDE-geschützte Datenbanken

Wenn Sie die transparente Datenverschlüsselung (TDE) verwenden, muss das Zertifikat oder der asymmetrische Schlüssel zum Erstellen und Entschlüsseln weiterer Schlüssel auf jeder Serverinstanz, die ein Verfügbarkeitsreplikat für die Verfügbarkeitsgruppe hostet, identisch sein. Weitere Informationen finden Sie unter Verschieben einer TDE-geschützten Datenbank auf einen anderen SQL-Server.

Berechtigungen (Verfügbarkeitsdatenbanken)

Erfordert die ALTER-Berechtigung für die Datenbank.

Verwandte Aufgaben (Verfügbarkeitsdatenbanken)

Zugehöriger Inhalt

• Microsoft SQL Server Always On-Lösungshandbuch zu hoher Verfügbarkeit und Notfallwiederherstellung
• SQL Server Always On Team Blog: The official SQL Server Always On Team Blog (SQL Server Always On-Teamblog: Der offizielle SQL Server Always On-Teamblog)
• Always On – HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (Always On – HADRON-Lernreihe: Nutzung des Arbeitspools für HADRON-fähige Datenbanken)
• Was ist eine Always On-Verfügbarkeitsgruppe?
• Failoverclustering und Always On-Verfügbarkeitsgruppen (SQL Server)
• Unterstützung für Treiber und Clientkonnektivität für Verfügbarkeitsgruppen