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.

Wichtig

Vor der Bereitstellung von Always On-Verfügbarkeitsgruppenwird empfohlen, dieses Thema vollständig zu lesen.

.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. Sie können die Hotfixes in beliebiger Reihenfolge installieren.

Abhängige Funktion Hotfix Verknüpfung
Berichterstellungsdienste Der Hotfix für .NET 3.5 SP1 erweitert den SQL-Client um die Unterstützung für die Always On-Features „Read-intent“, „Read-only“ und „MultiSubnetFailover“. Der Hotfix muss auf allen Reporting Services -Berichtsservern installiert werden. KB 2654347: Hotfix für .NET 3.5 SP1 zum Hinzufügen von Unterstützung für Always On-Features

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:

Anforderung Verknüpfung
Stellen Sie sicher, dass es sich bei diesem System nicht um einen Domänencontroller handelt. Verfügbarkeitsgruppen werden nicht auf Domänencontrollern unterstützt.
Stellen Sie sicher, dass auf jedem Computer eine unterstützte Windows Server-Version läuft Hardware- und Softwareanforderungen für:

- SQL Server 2025
- SQL Server 2022
- SQL Server 2019
- SQL Server 2016 und SQL Server 2017
Stellen Sie sicher, das jeder Computer ein Knoten in WSFC ist. Windows Server-Failoverclustering mit SQL Server
Stellen Sie sicher, dass WSFC ausreichend Knoten enthält, um die Verfügbarkeitsgruppenkonfigurationen zu unterstützen. Ein Clusterknoten kann ein Replikat für eine Verfügbarkeitsgruppe hosten. Es können nicht zwei Replikate aus der gleichen Verfügbarkeitsgruppe auf ein und demselben Knoten gehostet werden. Der Clusterknoten kann zu mehreren Verfügbarkeitsgruppen gehören und ein Replikat jeder Gruppe hosten.

Fragen Sie die Datenbankadministratoren, wie viele Clusterknoten erforderlich sind, um die Verfügbarkeitsreplikate der geplanten Verfügbarkeitsgruppen zu unterstützen.

Was ist eine Always On-Verfügbarkeitsgruppe?

Wichtig

Stellen Sie zudem sicher, dass Ihre Umgebung ordnungsgemäß zum Herstellen einer Verbindung mit einer Verfügbarkeitsgruppe konfiguriert wird. Weitere Informationen finden Sie unter Unterstützung für Treiber- und Clientkonnektivität für Verfügbarkeitsgruppen.

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 die beste Leistung sollten Sie für Always On-Verfügbarkeitsgruppen einen dedizierten Netzwerkadapter (Netzwerkkarte) 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.

  • Identisches Datenträgerlayout: Jeder Computer, auf dem eine Serverinstanz ein Verfügbarkeitsreplikat hostet, sollte über ein identisches Datenträgerlayout verfügen (mit exakt denselben Laufwerkbuchstaben und -größen), damit die Dateipfade für Datenbankdateien (mdf, ldf) übereinstimmen und so Komplikationen bei der Initialisierung und Synchronisierung vermieden werden. Überprüfen Sie Einschränkungen (Verfügbarkeitsdatenbanken) für Datenträgerlayouts, die unterschiedlich sind.

  • Konfiguration der Ressourcenverwaltung: Wenn Sie die Ressourcenkontrolle verwenden, verwenden Sie die gleiche Ressourcengouverneurkonfiguration für alle Instanzen, die Verfügbarkeitsgruppenreplikate hosten.

Berechtigungen (Windows-System)

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

Weitere Informationen zu dem Konto für die Clusterverwaltung finden Sie unter Anhang A: Failovercluster-Anforderungen.

HostRecordTTL ändern (mit 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 "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

    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)

Verwandte Inhalte (Windows-System)

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 (Serverinstanz)

Voraussetzung Verknüpfungen
Dieser Hostcomputer muss ein WSFC-Knoten sein. Die Instanzen von SQL Server , die Verfügbarkeitsreplikate für eine angegebene Verfügbarkeitsgruppe hosten, befinden sich jeweils in einem separaten Knoten des Clusters. Eine Verfügbarkeitsgruppe kann sich während der Migration zu einem anderen Cluster vorübergehend über zwei Cluster erstrecken. SQL Server 2016 (13.x) führte verteilte Verfügbarkeitsgruppen ein. In einer verteilten Verfügbarkeitsgruppe befinden sich zwei Verfügbarkeitsgruppen auf verschiedenen Clustern. Windows Server-Failoverclustering mit SQL Server

Failovercluster und Always On-Verfügbarkeitsgruppen (SQL Server)

Verteilte Verfügbarkeitsgruppen
Wenn Sie möchten, dass eine Verfügbarkeitsgruppe mit Kerberos funktioniert:

Alle Serverinstanzen, die ein Verfügbarkeitsreplikat für die Verfügbarkeitsgruppe hosten, müssen das gleiche SQL Server-Dienstkonto verwenden.

Der Domänenadministrator muss manuell einen Dienstprinzipalnamen (SPN) für Active Directory auf dem SQL Server-Dienstkonto beim virtuellen Netzwerknamen (VNN) des Verfügbarkeitsgruppenlisteners registrieren. Wenn der SPN auf keinem SQL Server-Dienstkonto registriert wird, treten bei der Authentifizierung Fehler auf.

Um die Kerberos-Authentifizierung für die Kommunikation zwischen Verfügbarkeitsgruppenendpunkten zu verwenden, registrieren Sie manuell SPNs für die von der Verfügbarkeitsgruppe verwendeten Datenbankspiegelungsendpunkte.

Wichtig: Wenn Sie das SQL Server-Dienstkonto ändern, muss der Domänenadministrator den SPN erneut manuell registrieren.		 Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen

Hinweis:

Kerberos und SPNs erzwingen die gegenseitige Authentifizierung. Dem Windows-Konto, das die SQL Server-Dienste startet, wird der SPN zugeordnet. Wenn der SPN nicht korrekt registriert ist oder die Registrierung fehlschlägt, kann die Windows-Sicherheitsschicht das dem SPN zugeordnete Konto nicht ermitteln, und die Kerberos-Authentifizierung kann nicht verwendet werden.

Anmerkung:NTLM hat diese Anforderung nicht.
Wenn Sie planen, eine SQL Server -Failoverclusterinstanz (FCI) zu verwenden, um ein Verfügbarkeitsreplikat zu hosten, muss gewährleistet sein, dass Sie die FCI-Einschränkungen verstehen und dass die FCI-Anforderungen erfüllt werden. Voraussetzungen und Anforderungen für die Verwendung einer SQL Server-Failoverclusterinstanz (FCI) zum Hosten eines Verfügbarkeitsreplikats (weiter unten in diesem Artikel)
Auf jeder Serverinstanz muss die gleiche Version von SQL Server ausgeführt werden, um an einer Verfügbarkeitsgruppe teilzunehmen. Weitere Informationen finden Sie in der Liste der Editionen und unterstützten Features am Ende dieses Abschnitts.
Alle Serverinstanzen, die Verfügbarkeitsreplikate für eine Verfügbarkeitsgruppe hosten, müssen die gleiche SQL Server -Sortierung verwenden. Die Serverkollation festlegen oder ändern
Aktivieren Sie die Funktion Always On-Verfügbarkeitsgruppen auf jeder Serverinstanz, die ein Verfügbarkeitsreplikat für jede Verfügbarkeitsgruppe hostet. Auf einem angegebenen Computer können Sie so viele Serverinstanzen für Always On-Verfügbarkeitsgruppen aktivieren, wie Ihre SQL Server -Installation unterstützt. Aktivieren oder Deaktivieren des Features für Always On-Verfügbarkeitsgruppen

Wichtig: Wenn Sie einen WSFC löschen und neu erstellen, müssen Sie die Funktion Always On-Verfügbarkeitsgruppen auf jeder Serverinstanz, die auf dem ursprünglichen Cluster für Always On-Verfügbarkeitsgruppen aktiviert war, deaktivieren und erneut aktivieren.
Jede Serverinstanz erfordert einen Datenbankspiegelungs-Endpunkt. Dieser Endpunkt wird von allen Verfügbarkeitsreplikaten, Datenbankspiegelungspartnern und Zeugen auf der Serverinstanz gemeinsam genutzt.

Wenn eine Serverinstanz, die Sie zum Hosten eines Verfügbarkeitsreplikats auswählen, unter einem Domänenbenutzerkonto ausgeführt wird und noch nicht über einen Datenbankspiegelungsendpunkt verfügt, kann der Verfügbarkeitsgruppen-Assistent (SQL Server Management Studio) verwendet werden (oder mithilfe des Verfügbarkeitsgruppen-Assistenten in SQL Server Management Studio Ihrer Always On-Verfügbarkeitsgruppe ein Replikat hinzufügen), um den Endpunkt zu erstellen und dem Dienstkonto der Serverinstanz die Berechtigung CONNECT zu erteilen. Wenn der SQL Server -Dienst jedoch als integriertes Konto, z. B. Lokales System, Lokaler Dienst oder Netzwerkdienst, oder als Nichtdomänenkonto ausgeführt wird, müssen Sie Zertifikate zur Endpunktauthentifizierung verwenden, und der Assistent kann keinen Datenbankspiegelungs-Endpunkt auf der Serverinstanz erstellen. In diesem Fall empfiehlt es sich, dass Sie die Datenbankspiegelungs-Endpunkte manuell erstellen, bevor Sie den Assistenten starten.

Sicherheitshinweis: Die Transportsicherheit für Always On-Verfügbarkeitsgruppen entspricht derjenigen der Datenbankspiegelung.		 Der Datenbankspiegelungsendpunkt (SQL Server)

Transportsicherheit - Datenbankspiegelung - Always On-Verfügbarkeit
Bevor Datenbanken, die FILESTREAM verwenden, zu einer Verfügbarkeitsgruppe hinzugefügt werden, stellen Sie sicher, dass FILESTREAM auf jeder Serverinstanz, die ein Verfügbarkeitsreplikat für die Verfügbarkeitsgruppe hostet, aktiviert worden ist. Aktivieren und Konfigurieren von FILESTREAM
Wenn enthaltene Datenbanken zu einer Verfügbarkeitsgruppe hinzugefügt werden, stellen Sie sicher, dass contained database authentication (Serverkonfigurationsoption) auf 1 auf jeder Serverinstanz festgelegt ist, die ein Verfügbarkeitsreplikat für die Verfügbarkeitsgruppe beherbergt. Serverkonfiguration: enthaltene Datenbankauthentifizierung

Serverkonfigurationsoptionen

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

Threadverwendung durch Verfügbarkeitsgruppen

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

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

  • Die maximale Anzahl von Threads, die von Verfügbarkeitsgruppen verwendet werden, ist die konfigurierte Einstellung für die maximale Anzahl von Serverthreads (max worker threads) minus 40.

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

    Threads werden wie folgt nach Bedarf gemeinsam genutzt:

    • In der Regel gibt es 3 bis 10 gemeinsam genutzte Threads, aber diese Zahl kann sich je nach Auslastung 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. Je nach der letzten Aktivität kann ein inaktiver Thread jedoch länger beibehalten 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 Redo-Threads werden nach etwa 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, einen auf Instanzebene gemeinsamen Threadpool, der von allen Datenbanken gemeinsam genutzt wird, bei denen Redo-Arbeit anfällt. 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.

  • SQL Server 2019 (15.x) führte paralleles Redo für speicheroptimierte Verfügbarkeitsgruppendatenbanken ein. In SQL Server 2016 (13.x) und SQL Server 2017 (14.x) verwenden datenträgerbasierte Tabellen kein paralleles Redo, wenn eine Datenbank in einer Verfügbarkeitsgruppe ebenfalls speicheroptimiert ist.

Weitere Informationen finden Sie unter Always On - HADRON Learning Series: Worker pool usage for HADRON enabled databases (ein Blog der CSS SQL Server Engineers).

Berechtigungen (Serverinstanz)

Aufgabe Erforderliche Berechtigungen
Erstellen des Endpunktes für die Datenbankspiegelung Erfordert die Berechtigung CREATE ENDPOINT oder die Mitgliedschaft in der festen Serverrolle sysadmin. Erfordert auch die Berechtigung CONTROL ON ENDPOINT. Weitere Informationen finden Sie unter GRANT Endpunktberechtigungen.
Aktivieren von Always On-Verfügbarkeitsgruppen Erfordert auf dem lokalen Computer die Mitgliedschaft in der Gruppe Administrator und Vollzugriff auf den WSFC.

Aufgabe Artikel
Bestimmen, ob ein Datenbankspiegelungs-Endpunkt vorhanden ist sys.database_mirroring_endpoints
Erstellen des Datenbankspiegelungs-Endpunkts (falls noch nicht vorhanden) Erstellen eines Datenbankspiegelungsendpunkts für die Windows-Authentifizierung

Verwenden von Zertifikaten für einen Datenbankspiegelungsendpunkt

Erstellen eines Datenbankspiegelungsendpunkts für eine Verfügbarkeitsgruppe mithilfe von PowerShell
Aktivieren von Verfügbarkeitsgruppen Aktivieren oder Deaktivieren des Features für Always On-Verfügbarkeitsgruppen

Verwandte Inhalte (Serverinstanz)

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 (FCIs)

Hinweis

Failoverclusterinstanzen (FCIs) unterstützen gemeinsam genutzte Clustervolumes (CSV). Weitere Informationen zu CSV finden Sie unter Grundlegendes zu freigegebenen Clustervolumes in einem Failovercluster.

  • 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. Dadurch wird potenziell verhindert, dass ein einzelner WSFC versucht, zwei Verfügbarkeitsreplikate für dieselbe Verfügbarkeitsgruppe zu beherbergen.

    Darüber hinaus muss jedes weitere Replikat von einer SQL Server-Instanz gehostet werden, die sich auf einem anderen Clusterknoten im selben Windows Server-Failovercluster 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 es dazu kommt und wie Sie den Zustand wiederherstellen, finden Sie im Blogbeitrag Replikat wurde unerwartet aus der Verfügbarkeitsgruppe entfernt.

  • FCIs unterstützen kein automatisches Failover durch Verfügbarkeitsgruppen: FCIs unterstützen kein automatisches Failover durch Verfügbarkeitsgruppen, sodass jedes Verfügbarkeitsreplikat, das von einer FCI gehostet wird, nur für manuelles Failover konfiguriert werden kann.

  • Ä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)

Voraussetzung Verknüpfung
Stellen Sie sicher, dass jede SQL Server-Failoverclusterinstanz (FCI) den erforderlichen gemeinsam verwendeten Speicher laut Standardinstallation der SQL Server-Failoverclusterinstanz besitzt.

Aufgabe Artikel
Installieren eines SQL Server-FCI Erstellen einer neuen Always On-Failoverclusterinstanz (Setup)
Direktes Upgrade des vorhandenen SQL Server-FCI Aktualisieren einer Failoverclusterinstanz
Beibehalten des vorhandenen SQL Server-FCI Hinzufügen oder Entfernen von Knoten in einer Failoverclusterinstanz (Setup)

Verwandte Inhalte (FCIs)

Voraussetzungen und Einschränkungen für Verfügbarkeitsgruppen

In diesem Abschnitt:

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 AGs und 100 DBs pro physischem Computer getestet; Dies ist jedoch kein Bindungslimit. 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 überlastete Systeme können unter anderem die Erschöpfung der Workerthreads, lange Antwortzeiten bei Systemansichten und DMVs für Verfügbarkeitsgruppen und/oder blockierte Dispatcher-Systemdumps umfassen. 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.

Voraussetzung BESCHREIBUNG
Wenn Sie planen, eine SQL Server -Failoverclusterinstanz (FCI) zu verwenden, um ein Verfügbarkeitsreplikat zu hosten, muss gewährleistet sein, dass Sie die FCI-Einschränkungen verstehen und dass die FCI-Anforderungen erfüllt werden. Voraussetzungen und Einschränkungen für das Hosten eines Verfügbarkeitsreplikats mithilfe einer SQL Server-Failoverclusterinstanz (FCI) (weiter oben in diesem Artikel)

Sicherheit (Verfügbarkeitsgruppen)

  • Die Sicherheit wird vom WSFC vererbt. Windows Server-Failoverclustering bietet zwei Ebenen der Benutzersicherheit auf der Ebene des gesamten Clusters:

    • Nur-Lesezugriff

    • Vollzugriff

      AlwaysOn-Verfügbarkeitsgruppen benötigen vollzugriff, und das Aktivieren von AlwaysOn-Verfügbarkeitsgruppen in einer Instanz von SQL Server bietet ihnen vollständige Kontrolle über den Cluster (ü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)

Aufgabe Erforderliche Berechtigungen
Erstellen einer Verfügbarkeitsgruppe Erfordert die Mitgliedschaft in der festen Serverrolle sysadmin und entweder die Serverberechtigung CREATE AVAILABILITY GROUP, die Berechtigung ALTER ANY AVAILABILITY GROUP oder die Berechtigung CONTROL SERVER.
Ändern einer Verfügbarkeitsgruppe Erfordert ALTER AVAILABILITY GROUP Berechtigung für die Verfügbarkeitsgruppe, CONTROL AVAILABILITY GROUP Berechtigung, ALTER ANY AVAILABILITY GROUP Berechtigung oder CONTROL SERVER Berechtigung.

Außerdem erfordert das Verknüpfen einer Datenbank mit einer Verfügbarkeitsgruppe die Mitgliedschaft in der festen db_owner -Datenbankrolle.
Löschen/Entfernen einer Verfügbarkeitsgruppe Erfordert ALTER AVAILABILITY GROUP Berechtigung für die Verfügbarkeitsgruppe, CONTROL AVAILABILITY GROUP Berechtigung, ALTER ANY AVAILABILITY GROUP Berechtigung oder CONTROL SERVER Berechtigung. Um eine Verfügbarkeitsgruppe zu löschen, die nicht auf der lokalen Replikatinstanz gehostet wird, benötigen Sie für diese Verfügbarkeitsgruppe die Berechtigung CONTROL SERVER oder CONTROL.

Aufgabe Artikel
Erstellen einer Verfügbarkeitsgruppe Verwenden des Verfügbarkeitsgruppen-Assistenten (SQL Server Management Studio)

Erstellen einer Always On-Verfügbarkeitsgruppe mit Transact-SQL (T-SQL)

Erstellen einer Always On-Verfügbarkeitsgruppe mit PowerShell

Angeben der Endpunkt-URL: Hinzufügen oder Ändern von Verfügbarkeitsreplikaten
Ändern der Anzahl der Verfügbarkeitsreplikate Hinzufügen eines sekundären Replikats zu einer AlwaysOn-Verfügbarkeitsgruppe

Verknüpfen eines sekundären Replikats mit einer Always On-Verfügbarkeitsgruppe

Entfernen einer sekundären Replik aus einer Verfügbarkeitsgruppe (SQL Server)
Erstellen eines Verfügbarkeitsgruppenlisteners Konfigurieren eines Listeners für Always On-Verfügbarkeitsgruppen
Löschen einer Verfügbarkeitsgruppe Entfernen einer Verfügbarkeitsgruppe (SQL Server)

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:

Prüfliste: Anforderungen (Verfügbarkeitsdatenbanken)

Damit eine Datenbank zu einer Verfügbarkeitsgruppe hinzugefügt werden kann, muss sie:

Anforderungen Verknüpfung
Seien Sie eine Benutzerdatenbank. Systemdatenbanken können nicht zu einer Verfügbarkeitsgruppe gehören.
Sich auf der Instanz von SQL Server befinden, auf der Sie die Verfügbarkeitsgruppe erstellen, und für die Serverinstanz zugänglich sein.
Eine Datenbank mit Lese- und Schreibzugriff sein. Schreibgeschützte Datenbanken können nicht zu einer Verfügbarkeitsgruppe hinzugefügt werden. sys.databases (is_read_only = 0)
Die Datenbank muss eine Mehrbenutzerdatenbank sein. sys.databases (user_access = 0)
Nicht verwenden AUTO_CLOSE. sys.databases (is_auto_close_on = 0)
Verwenden Sie das vollständige Wiederherstellungsmodell. sys.Databases (recovery_model = 1)
Mindestens eine vollständige Sicherung der Datenbank besitzen.

Hinweis: Nachdem eine Datenbank auf das vollständige Wiederherstellungsmodell festgelegt wurde, ist eine vollständige Sicherung erforderlich, um die Protokollkette des vollständigen Wiederherstellungsmodells zu initiieren.		 Erstellen einer vollständigen Datenbanksicherung
Keiner bestehenden Verfügbarkeitsgruppe angehören. sys.databases (group_database_id = NULL)
Nicht für die Datenbankspiegelung konfiguriert sein. sys.database_mirroring (Wenn die Datenbank nicht an der Spiegelung beteiligt ist, haben alle Spalten mit dem Präfix „mirroring_“ den Wert NULL.)
Bevor Sie eine Datenbank, die FILESTREAM verwendet, zu einer Verfügbarkeitsgruppe hinzufügen, muss gewährleistet sein, dass FILESTREAM auf jeder Serverinstanz aktiviert ist, die ein Verfügbarkeitsreplikat für die Verfügbarkeitsgruppe hostet oder hosten wird. Aktivieren und Konfigurieren von FILESTREAM
Vor dem Hinzufügen einer enthaltenen Datenbank zu einer Verfügbarkeitsgruppe muss gewährleistet sein, dass die Serveroption eigenständige Datenbankauthentifizierung auf jeder Serverinstanz, die ein Verfügbarkeitsreplikat für die Verfügbarkeitsgruppe hostet oder hosten wird, auf 1 gesetzt ist. Serverkonfiguration: enthaltene Datenbankauthentifizierung

Serverkonfigurationsoptionen

Hinweis

Always On-Verfügbarkeitsgruppen funktionieren mit jeder unterstützten Datenbankkompatibilitätsstufe.

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/Datenbank zum Verfügbarkeitsgruppen-Assistenten hinzufügen: Die Option "Vollständig" wird nicht unterstützt (auf der Seite "Erste Datensynchronisierung auswählen" (Assistenten für AlwaysOn-Verfügbarkeitsgruppen)

    • RESTORE WITH MOVE: Zum Erstellen der sekundären Datenbanken müssen die Datenbankdateien für jede Instanz von SQL Server wiederhergestellt WITH MOVE werden, die ein sekundäres Replikat hosten.

    • 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 wiederum bewirkt, dass die sekundären Replikate in den NOT SYNCHRONIZING Zustand gelangen.

      Hinweis

      Informationen zum Reagieren auf einen fehlgeschlagenen Anzeigendateivorgang finden Sie unter Problembehandlung bei einem fehlgeschlagenen Add-File-Vorgang (AlwaysOn-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 in einen anderen SQL Server.

Berechtigungen (Verfügbarkeitsdatenbanken)

Erfordert die ALTER-Berechtigung für die Datenbank.

Aufgabe Artikel
Vorbereiten einer sekundären Datenbank (manuell) Eine sekundäre Datenbank für eine Always On-Verfügbarkeitsgruppe vorbereiten
Verknüpfen einer sekundären Datenbank mit einer Verfügbarkeitsgruppe (manuell) Verknüpfen einer sekundären Datenbank mit einer Always On-Verfügbarkeitsgruppe
Ändern der Anzahl der Verfügbarkeitsdatenbanken Hinzufügen einer Datenbank zu einer AlwaysOn-Verfügbarkeitsgruppe

Entfernen einer sekundären Datenbank aus einer Verfügbarkeitsgruppe (SQL Server)

Entfernen einer primären Datenbank aus einer Always On-Verfügbarkeitsgruppe

Zugehöriger Inhalt

  • Last updated on