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

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
Vor der Bereitstellung von AlwaysOn-Verfügbarkeitsgruppen wird empfohlen, dieses Thema vollständig zu lesen.

In diesem Thema:

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

• Windows-Systemanforderungen und -Empfehlungen

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

• Empfehlungen zur Netzwerkkonnektivität

• Unterstützung für Clientkonnektivität

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

• Voraussetzungen und Einschränkungen für Verfügbarkeitsdatenbanken

• Voraussetzungen und Einschränkungen für Verfügbarkeitsdatenbanken

• Verwandte Inhalte

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

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

Windows-Systemanforderungen und -Empfehlungen

In diesem Abschnitt:

• Prüfliste: Anforderungen

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

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

• Berechtigungen

• Verwandte Aufgaben

• Verwandte Inhalte

Prüfliste: Anforderungen (Windows-System)

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

	Anforderung	Link
	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 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 AlwaysOn-Verfügbarkeitsgruppen nicht.
	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
	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. In einem angegebenen WSFC-Knoten kann mindestens eine Instanz 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).
	Es müssen alle Windows-Hotfixes auf allen Knoten im WSFC-Cluster installiert sein.	Wichtig Einige Hotfixes sind für die Knoten eines WSFC-Clusters, auf dem AlwaysOn-Verfügbarkeitsgruppen bereitgestellt wird, erforderlich oder empfohlen. 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-Clientkonnektivität (SQL Server).

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

Abhängig von der Clustertopologie sind möglicherweise einige zusätzliche Windows Server 2008 Service Pack (SP2)- oder Windows Server R2-Hotfixes zur Unterstützung von AlwaysOn-Verfügbarkeitsgruppen anwendbar. In der folgenden Tabelle sind diese Hotfixes angegeben. Die Hotfixes können in beliebiger Reihenfolge installiert werden.

Nach oben

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 Arbeitslasten bewältigen können.

• **Dedizierte Netzwerkadapter. **Zur optimalen Leistung sollten Sie einen dedizierten Netzwerkadapter (NIC, Network Interface Card, Netzwerkschnittstellenkarte) für AlwaysOn-Verfügbarkeitsgruppen verwenden.

• **Ausreichender Speicherplatz: **Jeder Computer, auf dem eine Serverinstanz ein Verfügbarkeitsreplikat hostet, muss über ausreichend Speicherplatz 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 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 zu suchen. Verwenden Sie dann Set-ClusterParameter-Cmdlet, um den HostRecordTTL-Wert folgendermaßen 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 ClusterParameter HostRecordTTL 300
   

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

Verwandte Inhalte (PowerShell)

• 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

• Windows 2008 R2 Failover Multisite Clustering

[Nach oben]

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

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

In diesem Abschnitt:

• Prüfliste: Voraussetzungen

• Einschränkungen

• Threadverwendung durch Verfügbarkeitsgruppen

• Berechtigungen

• Verwandte Aufgaben

• Verwandte Inhalte

Prüfliste: Voraussetzungen (Serverinstanz)

	Voraussetzung	Links
	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 angegebene Verfügbarkeitsgruppe hosten, müssen sich jeweils in einem 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 AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
	Stellen Sie auf jedem WSFC-Knoten, der ein Verfügbarkeitsreplikat hostet, sicher, dass der in Knowledge Base-Artikel 2897554 beschriebene Hotfix installiert ist. Dieser Hotfix stellt sicher, dass der Synchronisierungsstatus jedes Verfügbarkeitsreplikats ordnungsgemäß aktualisiert wird, wodurch unerwartete Datenverluste bei einem automatischen Failover vermieden werden.	Knowledge Base-Artikel 2897554: FIX: Synchronisierungsstatus des Replikats einer AlwaysOn-Verfügbarkeitsgruppe kann nicht aktualisiert werden, wenn das primäre Replikat fehlerhaft ist
	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.
	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)
	Auf jeder Serverinstanz muss die Enterprise Edition von SQL Server 2012 ausgeführt werden.	Von den SQL Server 2012-Editionen unterstützte Funktionen
	Alle Serverinstanzen, die Verfügbarkeitsreplikate für eine Verfügbarkeitsgruppe hosten, müssen die gleiche SQL Server-Sortierung verwenden.	Festlegen oder Ändern der Serversortierung
	Aktivieren Sie die Funktion AlwaysOn-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 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 neu erstellen, müssen Sie die Funktion AlwaysOn-Verfügbarkeitsgruppen auf jeder Serverinstanz, die auf dem ursprünglichen WSFC-Cluster für AlwaysOn-Verfügbarkeitsgruppen aktiviert war, deaktivieren und erneut aktivieren.
	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 Die Transportsicherheit für AlwaysOn-Verfügbarkeitsgruppen entspricht derjenigen der Datenbankspiegelung.	Der Datenbankspiegelungs-Endpunkt (SQL Server) Transportsicherheit für Datenbankspiegelung und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
	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
	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

Threadverwendung durch Verfügbarkeitsgruppen

AlwaysOn-Verfügbarkeitsgruppen stellt die folgenden Anforderungen an Arbeitsthreads:

• Auf einer SQL Server-Instanz im Leerlauf 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, aber diese Zahl kann sich abhängig von der Arbeitslast 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-Lernreihe: Nutzung des Arbeitsthreadpools für HADRON-fähige Datenbanken (ein CSS SQL Server-Technikblog).

Berechtigungen (Serverinstanz)

Verwandte Aufgaben (Serverinstanz)

Verwandte Inhalte (Serverinstanz)

• AlwaysON - HADRON-Lernreihe: Nutzung des Arbeitsthreadpools für HADRON-fähige Datenbanken

[Nach oben]

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.

[Nach oben]

Unterstützung für Clientkonnektivität

Weitere Informationen zur AlwaysOn-Verfügbarkeitsgruppen-Unterstützung für Clientkonnektivität finden Sie unter AlwaysOn-Clientkonnektivität (SQL Server).

[Nach oben]

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

Verwandte Aufgaben (FCIs)

[Nach oben]

Verwandte Inhalte (FCIs)

• Failoverclustering und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

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

Voraussetzungen und Einschränkungen für Verfügbarkeitsdatenbanken

In diesem Abschnitt:

• Einschränkungen

• Anforderungen

• Sicherheit

• Verwandte Aufgaben

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 vier sekundäre Replikate. Alle Replikate können im Modus für asynchrone Commits bzw. bis zu drei Replikate können im Modus für synchrone Commits ausgeführt werden.

• Maximale Anzahl von Verfügbarkeitsgruppen und Verfügbarkeitsdatenbanken pro Computer: Die tatsächliche Anzahl der auf einem Computer (VM oder physischer Computer) ausführbaren Datenbanken und Verfügbarkeitsgruppen richtet sich nach der Hardware und Arbeitsauslastung, 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:

  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.

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ötigt Vollzugriff. Durch Aktivieren von AlwaysOn-Verfügbarkeitsgruppen auf einer Instanz von SQL Server wird der Vollzugriff auf den WSFC-Cluster erteilt (über Dienst-SID).

    Sie können im WSFC-Failovercluster-Manager die Sicherheit für eine Serverinstanz nicht direkt hinzufügen oder entfernen. Um WSFC-Sicherheitssitzungen 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 AlwaysOn-Verfügbarkeitsgruppen-Verfügbarkeitsreplikate hosten.

Berechtigungen (Verfügbarkeitsgruppen)

Verwandte Aufgaben (Verfügbarkeitsgruppen)

[Nach oben]

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:

	Anforderungen	Link
	Die Datenbank muss eine Benutzerdatenbank sein. Systemdatenbanken können nicht zu einer Verfügbarkeitsgruppe gehören.
	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.
	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)
	Die Datenbank muss eine Mehrbenutzerdatenbank sein.	sys.databases (user_access = 0)
	Verwenden Sie nicht AUTO_CLOSE.	sys.databases (is_auto_close_on = 0)
	Verwenden Sie das vollständige Wiederherstellungsmodell (auch bekannt als der vollständige Wiederherstellungsmodus).	sys.databases (recovery_model = 1)
	Die Datenbank muss mindestens über eine vollständige Datenbanksicherung verfügen. Hinweis Eine vollständige Sicherung ist erforderlich, um die volle-Wiederherstellungs-Protokollkette zu initiieren, nachdem seine Datenbank auf den vollständigen Wiederherstellungsmodus festgelegt wurde.	Erstellen einer vollständigen Datenbanksicherung (SQL Server)
	Sie darf zu keiner vorhandenen Verfügbarkeitsgruppe gehören.	sys.databases (group_database_id = NULL)
	Die Datenbank darf nicht für die Datenbankspiegelung konfiguriert sein.	sys.database_mirroring (Wenn die Datenbank nicht an der Spiegelung beteiligt ist, sind alle Spalten mit dem Präfix "mirroring_" 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 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

Hinweis
AlwaysOn-Verfügbarkeitsgruppen funktioniert mit jedem unterstützten Datenbank-Kompatibilitätsgrad.

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 gesetzt sein.

  • **Auswirkungen auf Dateihinzufügungsvorgänge: **Ein späterer Dateihinzufügungsvorgang auf dem primären Replikat schlägt auf den sekundären Datenbanken möglicherweise fehl. 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 Dateihinzufügevorgang finden Sie unter Problembehandlung bei einem fehlgeschlagenen Vorgang zum Hinzufügen einer Datei (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)

[Nach oben]

Verwandte Inhalte

• Microsoft SQL Server AlwaysOn-Lösungshandbuch zu hoher Verfügbarkeit und Notfallwiederherstellung

• SQL Server AlwaysOn-Teamblog: Der offizielle SQL Server AlwaysOn-Teamblog

• AlwaysON - HADRON-Lernreihe: Nutzung des Arbeitsthreadpools für HADRON-fähige Datenbanken

[Nach oben]

Siehe auch

Konzepte

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Failoverclustering und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

AlwaysOn-Clientkonnektivität (SQL Server)