Freigeben über

Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

  • Artikel

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

Wichtig

Bevor Sie AlwaysOn-Verfügbarkeitsgruppen bereitstellen, wird dringend empfohlen, jeden Abschnitt dieses Themas zu lesen.

.NET Hotfixes, die AlwaysOn-Verfügbarkeitsgruppen unterstützen

Je nach den SQL Server 2014-Komponenten und -Features, die Sie mit AlwaysOn-Verfügbarkeitsgruppen verwenden, müssen Sie möglicherweise zusätzliche .NET-Hotfixes installieren, die in der folgenden Tabelle angegeben sind. Die Hotfixes können in beliebiger Reihenfolge installiert werden.

Abhängige Funktion Hotfix Verknüpfung
Kontrollkästchen Reporting Services Hotfix für .NET 3.5 SP1 bietet Unterstützung für SQL Client for AlwaysOn-Features von Read-Intent, Readonly und Multisubnetfailover. Der Hotfix muss auf allen Reporting Services -Berichtsservern installiert werden. KB-2654347: Hotfix für .NET 3.5 SP1, um Unterstützung für AlwaysOn-Features hinzuzufügen

Windows-Systemanforderungen und -Empfehlungen

Prüfliste: Anforderungen (Windows-System)

Um das Feature "Always On Availability Groups" zu unterstützen, stellen Sie sicher, dass jeder Computer, der an einer oder mehreren Verfügbarkeitsgruppen teilnimmt, die folgenden grundlegenden Anforderungen erfüllt:

Anforderung Verknüpfung
Kontrollkästchen Stellen Sie sicher, dass es sich bei diesem System nicht um einen Domänencontroller handelt. Verfügbarkeitsgruppen werden nicht auf Domänencontrollern unterstützt.
Kontrollkästchen Stellen Sie sicher, dass auf jedem Computer x86 (Nicht-WOW64) oder x64 Windows Server 2008 oder höhere Versionen ausgeführt werden. WOW64 (Windows 32-Bit unter Windows 64-Bit) unterstützt keine AlwaysOn-Verfügbarkeitsgruppen.
Kontrollkästchen Stellen Sie sicher, dass es sich bei jedem Computer um einen Knoten in einem Windows Server Failover Clustering (WSFC)-Cluster handelt. Windows Server-Failoverclustering (WSFC), mit SQL Server
Kontrollkästchen Stellen Sie sicher, dass der WSFC-Cluster ausreichend Knoten enthält, um die Verfügbarkeitsgruppenkonfigurationen zu unterstützen. Ein WSF-Knoten kann nur ein Verfügbarkeitsreplikat für eine bestimmte Verfügbarkeitsgruppe hosten. Auf einem bestimmten WSFC-Knoten kann eine oder mehrere Instanzen von SQL Server Verfügbarkeitsreplikate für viele Verfügbarkeitsgruppen hosten.

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

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
Kontrollkästchen Es müssen alle Windows-Hotfixes auf allen Knoten im WSFC-Cluster installiert sein. ** Wichtig ** Eine Reihe von Hotfixes ist erforderlich oder wird für die Knoten eines WSFC-Clusters empfohlen, auf dem Always On-Verfügbarkeitsgruppen bereitgestellt werden. Weitere Informationen finden Sie weiter unten in diesem Abschnitt unter Windows-Hotfixes, die AlwaysOn-Verfügbarkeitsgruppen unterstützen (Windows-System).

Wichtig

Stellen Sie zudem sicher, dass Ihre Umgebung ordnungsgemäß zum Herstellen einer Verbindung mit einer Verfügbarkeitsgruppe konfiguriert wird. Weitere Informationen finden Sie unter AlwaysOn Client Connectivity (SQL Server).For more information, see AlwaysOn Client Connectivity (SQL Server).

Windows-Hotfixes, die AlwaysOn-Verfügbarkeitsgruppen unterstützen (Windows-System)

Je nach Clustertopologie können mehrere zusätzliche Windows Server 2008 Service Pack 2 (SP2) oder Windows Server 2008 R2-Hotfixes für die Unterstützung von Always On-Verfügbarkeitsgruppen gelten. In der folgenden Tabelle sind diese Hotfixes angegeben. Die Hotfixes können in beliebiger Reihenfolge installiert werden.

Gilt für Windows 2008 SP2 Gilt für Windows 2008 R2 SP1 Im Lieferumfang von Windows 2012 enthalten Zur Unterstützung... Hotfix Verknüpfung
Kontrollkästchen Ja Ja Ja Konfigurieren des optimalen WSFC-Quorums Stellen Sie in jedem WSFC-Knoten sicher, dass der im Knowledge Base-Artikel 2494036 beschriebene Hotfix installiert ist.

Dieser Hotfix unterstützt das Konfigurieren eines optimalen Quorums mit nicht automatischen Failoverzielen. Diese Funktionalität verbessert Cluster mit mehreren Standorten, indem sie Ihnen die Auswahl der Abstimmungsknoten ermöglicht.		 KB 2494036: Ein Hotfix ist verfügbar, mit dem sich ein Clusterknoten konfigurieren lässt, der keine Quorumabstimmung in Windows Server 2008 und in Windows Server 2008 R2 enthält.

Informationen zur Quorumabstimmung finden Sie unter WSFC Quorum Modes and Voting Configuration (SQL Server)
Kontrollkästchen Ja Ja Ja Effizientere Nutzung der Netzwerkbandbreite Stellen Sie in jedem WSFC-Knoten sicher, dass der im Knowledge Base-Artikel 2616514 beschriebene Hotfix installiert ist.

Ohne diesen Hotfix sendet der Cluster unnötige Registrierungsbenachrichtigungen an die Clusterknoten. Dieses Verhalten schränkt die Netzwerkbandbreite ein, was ein schwerwiegendes Problem für Always On-Verfügbarkeitsgruppen darstellt.		 KB 2616514: Der Clusterdienst sendet unnötige Änderungsbenachrichtigungen zu Registrierungsschlüsseln an die Clusterknoten in Windows Server 2008 oder Windows Server 2008 R2
Kontrollkästchen Ja Nicht zutreffend VPD-Speichertests auf Datenträgern, die nicht für alle WSFC-Knoten verfügbar sind Falls auf einem WSFC-Knoten Windows Server 2008 R2 Service Pack 1 (SP1) ausgeführt wird und der Speichertest "VPD (Vital Product Data) des SCSI-Geräts überprüfen" einen Fehler verursacht, nachdem er fälschlicherweise auf Datenträgern ausgeführt wurde, die online sind und nicht für alle Knoten im WSFC-Cluster verfügbar sind, installieren Sie den im Knowledge Base-Artikel 2531907 beschriebenen Hotfix.

Dieser Hotfix verhindert falsche Warnungen oder Fehler im Überprüfungsbericht, wenn Datenträger online sind.		 KB 2531907: Der Test "VPD (Vital Product Data) des SCSI-Geräts überprüfen" schlägt fehl, nachdem Sie Windows Server 2008 R2 SP1 installieren
Kontrollkästchen Ja Ja Schnelleres Failover zu lokalen Replikaten Wenn in einem WSFC-Knoten Windows Server 2008 R2 Service Pack 1 (SP1) ausgeführt wird, stellen Sie sicher, dass der in Knowledge Base-Artikel 2687741 beschriebene Hotfix installiert ist.

Dieser Hotfix verbessert die Leistung von AlwaysOn-Verfügbarkeitsgruppen-Failover auf lokale Replikate.		 KB 2687741: Für Windows Server 2008 R2 ist ein Hotfix verfügbar, der die Leistung der "AlwaysOn-Verfügbarkeitsgruppen"-Funktion in SQL Server 2012 verbessert
Kontrollkästchen Ja Ja Ja Asymmetrischer Speicher für Failoverclusterinstanzen (FCIs) Wenn eine Failoverclusterinstanz (Failover Cluster Instance, FCI) für AlwaysOn-Verfügbarkeitsgruppen aktiviert ist, installieren Sie den Windows Server 2008-Hotfix 976097.

Dieser Hotfix ermöglicht das MmC-Snap-In (Failover Cluster Management Management) zur Unterstützung asymmetrischer freigegebener Datenträger, die nur auf einigen der WSFC-Knoten verfügbar sind.		 KB 976097: Hotfix zum Hinzufügen der Unterstützung für asymmetrische Speicher zum MMC-Failovercluster-Verwaltungs-Snap-in für ein Failovercluster, das unter Windows Server 2008 oder Windows Server 2008 R2 ausgeführt wird

AlwaysOn-Architekturhandbuch: Erstellen einer Hochverfügbarkeits- und Notfallwiederherstellungslösung mithilfe von Failoverclusterinstanzen und Verfügbarkeitsgruppen
Kontrollkästchen Ja Ja Nicht zutreffend Internetprotokollsicherheit (Internet Protocol Security, IPsec) Wenn in Ihrer Umgebung IPsec-Verbindungen verwendet werden, kann eine lange Verzögerung (von ca. zwei oder drei Minuten) eintreten, wenn ein Clientcomputer die IPsec-Verbindung mit dem Namen eines virtuellen Netzwerks erneut herstellt (in diesem Kontext, um eine Verbindung mit dem Verfügbarkeitsgruppenlistener herzustellen). Wenn Sie IPsec-Verbindungen verwenden, wird empfohlen, dass Sie sich über die im Knowledge Base-Artikel (KB 980915) aufgeführten speziellen Szenarien informieren. KB 980915: Eine lange Verzögerung tritt auf, wenn eine IPSec-Verbindung von einem Computer wiederhergestellt wird, auf dem Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 oder Windows Server 2008 R2 ausgeführt wird
Kontrollkästchen Ja Ja Ja IPv6 Bei Verwendung von IPv6 wird empfohlen, die zum jeweiligen Windows Server-Betriebssystem passenden Informationen zu spezifischen Szenarien in Knowledge Base-Artikel 2578103 oder 2578113 zu lesen.

Wenn für die Windows Server-Topologie IPv6 (IP Version 6) verwendet wird, benötigt der WSFC-Clusterdienst ungefähr 30 Sekunden, um ein Failover auf die IPv6-IP-Adresse auszuführen. Dies führt dazu, dass Clients ungefähr 30 Sekunden warten müssen, um erneut eine Verbindung mit der IPv6-IP-Adresse herzustellen.		 KB 2578103 (Windows Server 2008): Der Clusterdienst benötigt ungefähr 30 Sekunden für ein Failover auf IPv6-IP-Adressen in Windows Server 2008

KB 2578113 (Windows Server 2008 R2): Windows Server 2008 R2: Der Clusterdienst dauert ca. 30 Sekunden, um IPv6-IP-Adressen in Windows Server 2008 R2 fehlzuschlagen.
Kontrollkästchen Ja Ja Ja Kein Router zwischen Cluster und Anwendungsserver Falls zwischen dem Failovercluster und dem Anwendungsserver kein Router vorhanden ist, führt der Clusterdienst ein Failover der netzwerkbezogenen Ressourcen langsam aus. Dadurch werden erneute Clientverbindungen nach dem Failover einer Verfügbarkeitsgruppe verzögert. Wenn kein Router vorhanden ist, wird empfohlen, die spezifischen Szenarien in Knowledge Base-Artikel 2582281 zu lesen und den Hotfix zu installieren, sofern dieser für Ihre Umgebung geeignet ist. KB 2582281: Langsamer Failovervorgang, wenn kein Router zwischen dem Cluster und einem Anwendungsserver vorhanden ist

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: Verwenden Sie für AlwaysOn-Verfügbarkeitsgruppen einen dedizierten Netzwerkadapter (Netzwerkschnittstellenkarte).

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

Aufgabe Link
Legen Sie den HostRecordTTL-Wert fest. Ändern des HostRecordTTL (Verwenden von Windows PowerShell)

Ä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 zu suchen. Verwenden Sie dann Set-ClusterParameter-Cmdlet, um den HostRecordTTL-Wert folgendermaßen 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 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.

Prüfliste: Voraussetzungen (Serverinstanz)

Voraussetzung Links
Kontrollkästchen Beim Hostcomputer muss es sich um einen WSFC-Knoten (Windows Server Failover Clustering) handeln. Die Instanzen von SQL Server, die Verfügbarkeitsreplikate für eine bestimmte Verfügbarkeitsgruppe hosten, müssen sich auf separaten Knoten eines einzelnen WSFC-Clusters befinden. Die einzige Ausnahme besteht darin, dass sich eine Verfügbarkeitsgruppe während der Migration zu einem anderen WSFC-Cluster vorübergehend auf zwei Cluster erstrecken kann. Windows Server-Failoverclustering (WSFC), mit SQL Server

Failoverclustering und Always On-Verfügbarkeitsgruppen (SQL Server)
Kontrollkästchen Wenn eine Verfügbarkeitsgruppe mit Kerberos verwendet werden soll:

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.

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

Kurze Erklärung:

Kerberos und SPNs erzwingen die gegenseitige Authentifizierung. Dem Windows-Konto, das die SQL Server-Dienste startet, wird der SPN zugeordnet. Wenn die Registrierung des SPNs nicht richtig erfolgt oder dabei ein Fehler aufgetreten ist, kann die Windows-Sicherheitsschicht nicht das Konto bestimmen, das dem Dienstprinzipalname zugewiesen ist. Das bedeutet, die Kerberos-Authentifizierung kann nicht verwendet werden.

Hinweis: Bei NTLM gibt es diese Anforderung nicht.
Kontrollkästchen 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 zum Hosten eines Verfügbarkeitsreplikats mithilfe einer SQL Server-Failoverclusterinstanz (FCI) (später in diesem Thema)
Kontrollkästchen Jede Serverinstanz muss die Enterprise Edition von SQL Server 2014 ausführen. Von den Editionen von SQL Server 2014 unterstützte Features
Kontrollkästchen Alle Serverinstanzen, die Verfügbarkeitsreplikate für eine Verfügbarkeitsgruppe hosten, müssen die gleiche SQL Server -Sortierung verwenden. Festlegen oder Ändern der Serversortierung
Kontrollkästchen Aktivieren Sie das Feature "AlwaysOn-Verfügbarkeitsgruppen" auf jeder Serverinstanz, die ein Verfügbarkeitsreplikat für jede Verfügbarkeitsgruppe hosten soll. Auf einem bestimmten Computer können Sie so viele Serverinstanzen für AlwaysOn-Verfügbarkeitsgruppen aktivieren, wie ihre SQL Server-Installation unterstützt. Aktivieren und Deaktivieren von AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

** Wichtig ** Wenn Sie einen WSFC-Cluster löschen und erneut erstellen, müssen Sie das Feature "Always On Availability Groups" auf jeder Serverinstanz deaktivieren und erneut aktivieren, die für Always On-Verfügbarkeitsgruppen im ursprünglichen WSFC-Cluster aktiviert war.
Kontrollkästchen Jede Serverinstanz erfordert einen Datenbankspiegelungs-Endpunkt. Beachten Sie, dass dieser Endpunkt von allen Verfügbarkeitsreplikaten, Datenbank-Spiegelungspartnern und Zeugen auf der Serverinstanz gemeinsam verwendet wird.

Wenn eine Serverinstanz, die Sie zum Hosten eines Verfügbarkeitsreplikats auswählen, unter einem Domänenbenutzerkonto ausgeführt wird und noch keinen Datenbankspiegelungs-Endpunkt aufweist, kann der Assistent für neue Verfügbarkeitsgruppen (oder Assistent zum Hinzufügen von Replikaten zu Verfügbarkeitsgruppen) den Endpunkt erstellen und dem Dienstkonto der Serverinstanz die CONNECT-Berechtigung 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 ** Transportsicherheit für Always On-Verfügbarkeitsgruppen ist identisch mit der Datenbankspiegelung.		 Der Datenbankspiegelungs-Endpunkt (SQL Server)

Transportsicherheit für Datenbankspiegelung und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
Kontrollkästchen 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
Kontrollkästchen Bevor eigenständige Datenbanken einer Verfügbarkeitsgruppe hinzugefügt werden, muss gewährleistet sein, dass die Serveroption contained database authentication auf jeder Serverinstanz, die ein Verfügbarkeitsreplikat für die Verfügbarkeitsgruppe hostet, auf 1 festgelegt wurde. Contained Database Authentication (Serverkonfigurationsoption)

Serverkonfigurationsoptionen (SQL Server)

Threadverwendung durch Verfügbarkeitsgruppen

Always On Availability Groups hat die folgenden Anforderungen für Arbeitsthreads:

  • In einer Leerlaufinstanz von SQL Server verwendet AlwaysOn-Verfügbarkeitsgruppen 0 Threads.

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

  • Die auf einer bestimmten Serverinstanz gehosteten Verfügbarkeitsreplikate verwenden einen gemeinsamen Threadpool.

    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.

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

    • Jedes sekundäre Replikat verwendet einen Wiederholungsthread für jede sekundäre Datenbank. Wiederholungsthreads 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.

Weitere Informationen finden Sie unter AlwaysON - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (a CSS SQL Server Engineers Blog).

Berechtigungen (Serverinstanz)

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

Verwandte Aufgaben (Serverinstanz)

Aufgabe Thema
Bestimmen, ob ein Datenbankspiegelungs-Endpunkt vorhanden ist sys.database_mirroring_endpoints (Transact-SQL)
Erstellen des Datenbankspiegelungs-Endpunkts (falls noch nicht vorhanden) Erstellen eines Endpunkts der Datenbankspiegelung für Windows-Authentifizierung (Transact-SQL)

Verwenden von Zertifikaten für einen Datenbankspiegelungs-Endpunkt (Transact-SQL)

Erstellen eines Datenbankspiegelungs-Endpunkts für Always On-Verfügbarkeitsgruppen (SQL Server PowerShell)
Aktivieren der AlwaysOn-Verfügbarkeitsgruppen Aktivieren und Deaktivieren von AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Verwandte Inhalte (Serverinstanz)

Empfehlungen zur Netzwerkkonnektivität

Es wird dringend empfohlen, für die Kommunikation zwischen WSFC-Clusterelementen 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-Cluster 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 AlwaysOn Client Connectivity (SQL Server).For information about Always On Availability Groups support for client connectivity, see AlwaysOn Client Connectivity (SQL Server).

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

Einschränkungen (FCIs)

Hinweis

Ab SQL Server 2014 unterstützt AlwaysOn-Failoverclusterinstanzen gruppierte freigegebene Volumes (CSV) in Windows Server 2008 R2 und Windows Server 2012. Weitere Informationen über CSV finden Sie in Aktivieren von 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-Clusterknoten, die mögliche FCI-Besitzer sind, kein anderes Replikat für dieselbe Verfügbarkeitsgruppe hosten.

    Weiter muss jedes andere Replikat von einer SQL Server 2012-Instanz gehostet werden, die sich unter einem anderen WSFC-Knoten desselben WSFC-Clusters befindet. Die einzige Ausnahme besteht darin, dass sich eine Verfügbarkeitsgruppe während der Migration zu einem anderen WSFC-Cluster vorübergehend auf zwei Cluster erstrecken kann.

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

Voraussetzung Verknüpfung
Kontrollkästchen Bevor Sie ein Verfügbarkeitsreplikat mithilfe einer FCI hosten, muss gewährleistet sein, dass der Systemadministrator das im Knowledge Base-Artikel KB 976097 beschriebene Windows Server 2008-Hotfix installiert hat. Dieser Hotfix ermöglicht das MmC-Snap-In (Failover Cluster Management Management) zur Unterstützung asymmetrischer freigegebener Datenträger, die nur auf einigen der WSFC-Knoten verfügbar sind. KB 976097: Hotfix zum Hinzufügen der Unterstützung für asymmetrische Speicher zum MMC-Failovercluster-Verwaltungs-Snap-in für ein Failovercluster, das unter Windows Server 2008 oder Windows Server 2008 R2 ausgeführt wird
Kontrollkästchen Stellen Sie sicher, dass jede SQL Server-Failoverclusterinstanz (FCI) den erforderlichen gemeinsam verwendeten Speicher laut Standardinstallation der SQL Server-Failoverclusterinstanz besitzt.

Verwandte Aufgaben (FCIs)

Aufgabe Thema
Installieren eines SQL Server-Failoverclusters Erstellen eines neuen SQL Server-Failoverclusters (Setup)
Direktes Upgrade des vorhandenen SQL Server-Failoverclusters Aktualisieren einer SQL Server-Failoverclusterinstanz (Setup)
Beibehalten des vorhandenen SQL Server-Failoverclusters Hinzufügen oder Entfernen von Knoten in einem SQL Server-Failovercluster (Setup)

Verwandte Inhalte (FCIs)

Voraussetzungen und Einschränkungen für Verfügbarkeitsdatenbanken

Einschränkungen (Verfügbarkeitsgruppen)

  • Verfügbarkeitsreplikate müssen von verschiedenen Knoten eines WSFC-Clusters gehostet werden: Für eine angegebene Verfügbarkeitsgruppe müssen Verfügbarkeitsreplikate von Serverinstanzen gehostet werden, die auf verschiedenen Knoten desselben WSFC-Clusters ausgeführt werden. Die einzige Ausnahme besteht darin, dass sich eine Verfügbarkeitsgruppe während der Migration zu einem anderen WSFC-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-Failovercluster 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 drei Replikate im Modus für synchrone Commits ausgeführt werden (ein primäres Replikat mit zwei synchronen sekundären Replikaten).

  • 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 umfangreiche Testreihen mit 10 Verfügbarkeitsgruppen und 100 Datenbanken pro physischem Computer durchgeführt. Anzeichen für eine Systemüberlastung könnten u. a. zu wenige Arbeitsthreads, langsame Antwortzeiten für AlwaysOn-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:

    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.

Voraussetzungen (Verfügbarkeitsgruppen)

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

Voraussetzung Beschreibung
Kontrollkästchen 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 zum Hosten eines Verfügbarkeitsreplikats mithilfe einer SQL Server-Failoverclusterinstanz (FCI) (früher in diesem Thema)

Sicherheit (Verfügbarkeitsgruppen)

  • Die Sicherheit wird vom Windows Server-Failoverclustering (WSFC)-Cluster geerbt. WSFC stellt zwei Benutzersicherheitsebenen mit der Granularität gesamter WSFC-Cluster-APIs bereit:

    • Schreibgeschützter Zugriff

    • Vollzugriff

      AlwaysOn-Verfügbarkeitsgruppen benötigen voll kontrolle, und das Aktivieren von AlwaysOn-Verfügbarkeitsgruppen auf einer Instanz von SQL Server bietet ihnen vollständige Kontrolle über den WSFC-Cluster (über Die Dienst-SID).

      Sie können im WSFC-Failovercluster-Manager die Sicherheit für eine Serverinstanz nicht direkt hinzufügen oder entfernen. Verwenden Sie zum Verwalten von WSFC-Sicherheitssitzungen die SQL Server-Konfigurations-Manager oder das WMI-Äquivalent von SQL Server.

  • Jede Instanz von SQL Server muss über Berechtigungen für den Zugriff auf die Registrierung, den Cluster und soforth verfügen.

  • Es wird empfohlen, die Verschlüsselung für Verbindungen zwischen Serverinstanzen zu verwenden, die AlwaysOn-Verfügbarkeitsgruppen-Verfügbarkeitsgruppen-Verfügbarkeitsreplikate hosten.

Berechtigungen (Verfügbarkeitsgruppen)

Aufgabe Erforderliche Berechtigungen
Erstellen einer Verfügbarkeitsgruppe Erfordert die Mitgliedschaft in der festen Serverrolle sysadmin und die CREATE AVAILABILITY GROUP-Serverberechtigung, ALTER ANY AVAILABILITY GROUP-Berechtigung oder CONTROL SERVER-Berechtigung.
Ändern einer Verfügbarkeitsgruppe Erfordert die ALTER AVAILABILITY GROUP-Berechtigung für die Verfügbarkeitsgruppe, die CONTROL AVAILABILITY GROUP-Berechtigung, die ALTER ANY AVAILABILITY GROUP-Berechtigung oder die 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 einer Verfügbarkeitsgruppe Erfordert die ALTER AVAILABILITY GROUP-Berechtigung für die Verfügbarkeitsgruppe, die CONTROL AVAILABILITY GROUP-Berechtigung, die ALTER ANY AVAILABILITY GROUP-Berechtigung oder die CONTROL SERVER-Berechtigung. Um eine Verfügbarkeitsgruppe zu löschen, die nicht am lokalen Replikatspeicherort gehostet wird, benötigen Sie die CONTROL SERVER-Berechtigung oder die CONTROL-Berechtigung für diese Verfügbarkeitsgruppe.

Verwandte Aufgaben (Verfügbarkeitsgruppen)

Aufgabe Thema
Erstellen einer Verfügbarkeitsgruppe Verwenden der Verfügbarkeitsgruppe (Assistent für neue Verfügbarkeitsgruppen)

Erstellen einer Verfügbarkeitsgruppe (Transact-SQL)

Erstellen einer Verfügbarkeitsgruppe (SQL Server PowerShell)

Angeben der Endpunkt-URL beim Hinzufügen oder Ändern eines Verfügbarkeitsreplikats (SQL Server)
Ändern der Anzahl der Verfügbarkeitsreplikate Hinzufügen eines sekundären Replikats zu einer Verfügbarkeitsgruppe (SQL Server)

Verknüpfen eines sekundären Replikats mit einer Verfügbarkeitsgruppe (SQL Server)

Entfernen einer sekundären Replikats aus einer Verfügbarkeitsgruppe (SQL Server)
Erstellen eines Verfügbarkeitsgruppenlisteners Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server)
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:

Prüfliste: Anforderungen (Verfügbarkeitsdatenbanken)

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

Requirements (Anforderungen) Verknüpfung
Kontrollkästchen Die Datenbank muss eine Benutzerdatenbank sein. Systemdatenbanken können nicht zu einer Verfügbarkeitsgruppe gehören.
Kontrollkästchen Die Datenbank muss sich auf der Instanz von SQL Server , auf der Sie die Verfügbarkeitsgruppe erstellen, und die Serverinstanz muss darauf zugreifen können.
Kontrollkästchen Die Datenbank muss eine Datenbank mit Lese-/Schreibzugriff sein. Schreibgeschützte Datenbanken können nicht zu einer Verfügbarkeitsgruppe hinzugefügt werden. sys.databases (is_read_only = 0)
Kontrollkästchen Die Datenbank muss eine Mehrbenutzerdatenbank sein. sys.databases (user_access = 0)
Kontrollkästchen Verwenden Sie nicht AUTO_CLOSE. sys.Databases (is_auto_close_on = 0)
Kontrollkästchen Verwenden Sie das vollständige Wiederherstellungsmodell (auch bekannt als der vollständige Wiederherstellungsmodus). sys.Databases (recovery_model = 1)
Kontrollkästchen Die Datenbank muss mindestens über eine vollständige Datenbanksicherung verfügen.

Hinweis: Eine vollständige Sicherung ist erforderlich, um die volle Protokollkette für eine vollständige Wiederherstellung auszulösen, nachdem eine Datenbank auf den vollständigen Wiederherstellungsmodus festgelegt wurde.		 Erstellen einer vollständigen Datenbanksicherung (SQL Server)
Kontrollkästchen Sie darf zu keiner vorhandenen Verfügbarkeitsgruppe gehören. sys.Databases (group_database_id = NULL)
Kontrollkästchen Die Datenbank darf 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.)
Kontrollkästchen 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
Kontrollkästchen Vor dem Hinzufügen einer eigenständigen Datenbank zu einer Verfügbarkeitsgruppe muss gewährleistet sein, dass die Serveroption contained database authentication auf jeder Serverinstanz, die ein Verfügbarkeitsreplikat für die Verfügbarkeitsgruppe hostet oder hosten wird, auf 1 gesetzt ist. Contained Database Authentication (Serverkonfigurationsoption)

Serverkonfigurationsoptionen (SQL Server)

Hinweis

AlwaysOn-Verfügbarkeitsgruppen funktionieren mit allen unterstützten Datenbankkompatibilitätsstufen.

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

    • 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 fehlgeschlagenen Anzeigendateivorgang finden Sie unter Problembehandlung für einen 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 auf einen anderen SQL-Server.

Berechtigungen (Verfügbarkeitsdatenbanken)

Erfordert die ALTER-Berechtigung für die Datenbank.

Verwandte Aufgaben (Verfügbarkeitsdatenbanken)

Aufgabe Thema
Vorbereiten einer sekundären Datenbank (manuell) Manuelles Vorbereiten einer sekundären Datenbank auf eine Verfügbarkeitsgruppe (SQL Server)
Verknüpfen einer sekundären Datenbank mit einer Verfügbarkeitsgruppe (manuell) Verknüpfen einer sekundären Datenbank mit einer Verfügbarkeitsgruppe (SQL Server)
Ändern der Anzahl der Verfügbarkeitsdatenbanken Hinzufügen einer Datenbank zu einer Verfügbarkeitsgruppe (SQL Server)

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

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

Verwandte Inhalte

Weitere Informationen

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
Failoverclustering und Always On-Verfügbarkeitsgruppen (SQL Server)
AlwaysOn-Clientkonnektivität (SQL Server)