Hochverfügbarkeitslösungen: Übersicht

In diesem Abschnitt werden mehrere Hochverfügbarkeitslösungen von SQL Server vorgestellt, die die Verfügbarkeit von Servern oder Datenbanken verbessern. Eine Lösung mit hoher Verfügbarkeit unterdrückt die Auswirkungen eines Hardware- oder Softwarefehlers und hält die Verfügbarkeit von Anwendungen aufrecht, damit die Ausfallzeiten für Benutzer so gering wie möglich gehalten werden.

SQL Server enthält mehrere Optionen zum Erstellen der hohen Verfügbarkeit für einen Server oder eine Datenbank. Es gibt die folgenden Optionen für hohe Verfügbarkeit:

• Failover-Clusterunterstützung

  Die Failover-Clusterunterstützung bietet Unterstützung für hohe Verfügbarkeit für eine gesamte Instanz von SQL Server. Ein Failovercluster ist eine Kombination aus mindestens einem Knoten oder Server mit mindestens zwei freigegebenen Datenträgern. Anwendungen werden jeweils in einer Clustergruppe für Microsoft Clusterdienste (MSCS, Microsoft Cluster Service) installiert, die als Ressourcengruppe bezeichnet wird. Zu jedem Zeitpunkt befindet sich jede Ressourcengruppe im Besitz genau eines Knotens im Cluster. Der Anwendungsdienst hat einen virtuellen Namen, der von den Knotennamen unabhängig ist und der aus diesem Grund als Name der Failoverclusterinstanz bezeichnet wird. Eine Anwendung kann die Verbindung mit der Failoverclusterinstanz nicht durch Verweisen auf den Namen der Failoverclusterinstanz herstellen. Die Anwendung muss nicht wissen, welcher Knoten die Failoverclusterinstanz hostet.

  Eine SQL Server-Failoverclusterinstanz wird wie ein einzelner Computer im Netzwerk angezeigt, verfügt jedoch über Funktionalität, die ein Failover von einem Knoten zu einem anderen Knoten ermöglichen, wenn der aktuelle Knoten nicht mehr verfügbar ist. Beispielsweise können Sie eine Instanz von SQL Server auf einem Knoten eines Failoverclusters konfigurieren, um im Falle eines Hardwarefehlers (nicht im Zusammenhang mit dem Datenträger), Betriebssystemfehlers oder eines geplanten Updates des Betriebssystems ein Failover zu einem anderen Knoten in der Datenträgergruppe auszuführen.

  Ein Failovercluster schützt nicht vor Datenträgerfehlern. Mit der Failover-Clusterunterstützung können Sie die Systemdowntime reduzieren und eine höhere Anwendungsverfügbarkeit bieten. Die Failover-Clusterunterstützung wird in SQL Server Enterprise, SQL Server Developer und, mit einigen Einschränkungen, in SQL Server Standard unterstützt. Weitere Informationen zur Failover-Clusterunterstützung finden Sie unter Erste Schritte mit der SQL Server 2008-Failover-Clusterunterstützung und Installieren eines SQL Server 2008-Failoverclusters.

• Datenbankspiegelung

  Die Datenbankspiegelung stellt in erster Linie eine Softwarelösung dar, mit der die Verfügbarkeit einer Datenbank erhöht wird, indem ein fast sofortiges Failover unterstützt wird. Mit der Datenbankspiegelung kann eine einzelne Datenbank, die sich im Standbymodus befindet, eine so genannte Spiegeldatenbank, für eine entsprechende Produktionsdatenbank, eine so genannte Prinzipaldatenbank, verwaltet werden.

  Zum Erstellen der Spiegeldatenbank wird eine vollständige Datenbanksicherung der Prinzipaldatenbank ohne Wiederherstellung wiederhergestellt. Daher haben Clients keinen Zugriff auf die Spiegeldatenbank. Sie kann jedoch indirekt für die Berichterstellung verwendet werden, indem in der Spiegeldatenbank ein Datenbanksnapshot erstellt wird. Der Datenbanksnapshot ermöglicht den Clients den schreibgeschützten Zugriff auf die Daten in der Datenbank, und zwar so wie sie zum Zeitpunkt der Snapshoterstellung vorlagen.

  Jede Datenbank-Spiegelungskonfiguration umfasst einen Prinzipalserver, der die Prinzipaldatenbank enthält, und einen Spiegelserver, der die Spiegeldatenbank enthält. Der Spiegelserver aktualisiert die Spiegeldatenbank ständig mit der Prinzipaldatenbank.

  Die Datenbankspiegelung kann entweder synchron im Modus für hohe Sicherheit oder asynchron im Modus für hohe Leistung ausgeführt werden. Im Modus für hohe Leistung wird für die Transaktionen ein Commit ausgeführt, ohne darauf zu warten, dass der Spiegelserver das Protokoll auf den Datenträger schreibt, wodurch die Leistung maximiert wird. Im Modus für hohe Sicherheit wird für eine Transaktion, für die ein Commit ausgeführt wird, auf beiden Partnern ein Commit ausgeführt wird, jedoch mit dem Risiko erhöhter Transaktionslatenzzeit.

  In der einfachsten Konfiguration umfasst die Datenbankspiegelung nur den Prinzipalserver und den Spiegelserver. In dieser Konfiguration kann bei Ausfall des Prinzipalservers der Spiegelserver als betriebsbereiter Standbyserver verwendet werden, mit möglichem Datenverlust. Im Modus für hohe Sicherheit wird eine alternative Konfiguration unterstützt, der Modus für hohe Sicherheit mit automatischem Failover. Diese Konfiguration umfasst eine dritte Serverinstanz, den Zeugen, die das Verwenden des Spiegelservers als unmittelbar betriebsbereiten Server ermöglicht. Ein Failover von der Prinzipaldatenbank zur Spiegeldatenbank nimmt i. d. R. einige Sekunden in Anspruch.

  Seit SQL Server 2005 Service Pack 1 (SP1) werden Partner und Zeugen für Datenbankspiegelungen von SQL Server Standard und SQL Server Enterprise unterstützt. Die Partner müssen jedoch die gleiche Version verwenden; die asynchrone Datenbankspiegelung (Modus für hohe Leistung) wird nur von SQL Server Enterprise unterstützt. Zeugen werden auch von SQL Server Workgroup und SQL Server Express unterstützt.

  Weitere Informationen zur Datenbankspiegelung finden Sie unter Datenbankspiegelung.

• Protokollversand

  Wie die Datenbankspiegelung arbeitet auch der Protokollversand auf Datenbankebene. Mit dem Protokollversand kann mindestens eine Datenbank, die sich im betriebsbereiten Standbymodus befindet, für eine entsprechende Produktionsdatenbank, die so genannte primäre Datenbank, verwaltet werden. Standbydatenbanken wird auch als sekundäre Datenbanken bezeichnet. Jede sekundäre Datenbank wird durch das Wiederherstellen einer Datenbanksicherung der primären Datenbank ohne Wiederherstellung oder mit Standbymodus erstellt. Bei der Wiederherstellung mit dem Standbymodus kann die resultierende sekundäre Datenbank für eine eingeschränkte Berichterstellung verwendet werden.

  Eine Protokollversandkonfiguration enthält einen einzelnen primären Server, der die primäre Datenbank enthält, mindestens einen sekundären Server mit je einer sekundären Datenbank und einen Überwachungsserver. Jeder sekundäre Server aktualisiert seine sekundäre Datenbank in festgelegten Abständen von den Protokollsicherungen der primären Datenbank. Der Protokollversand beinhaltet eine vom Benutzer änderbare Verzögerung zwischen dem Zeitpunkt, zu dem der primäre Server eine Protokollsicherung der primären Datenbank erstellt und dem Zeitpunkt, zu dem der sekundäre Server die Protokollsicherung wiederherstellt. Bevor ein Failover auftreten kann, muss eine sekundäre Datenbank vollständig auf den neuesten Stand gebracht werden, indem nicht wiederhergestellte Protokollsicherungen manuell angewendet werden.

  Der Protokollversand ist flexibel und unterstützt mehrere Standbydatenbanken. Wenn mehrere Standbydatenbanken erforderlich sind, können Sie den Protokollversand alleine oder als Ergänzung zur Datenbankspiegelung verwenden. Wenn diese Lösungen gemeinsam verwendet werden, ist die aktuelle Prinzipaldatenbank der Datenbank-Spiegelungskonfiguration gleichzeitig die aktuelle primäre Datenbank der Protokollversandkonfiguration.

  Der Protokollversand wird in den Editionen SQL Server Enterprise, Standard und Workgroup unterstützt. Weitere Informationen zum Protokollversand finden Sie unter Übersicht über den Protokollversand und Protokollversandverwaltung.

• Replikation

  Die Replikation verwendet ein Modell zum Veröffentlichen und Abonnieren. Damit kann ein primärer Server, der so genannte "Verleger", Daten an mindestens einen sekundären Server oder Abonnenten verteilen. Die Replikation ermöglicht zwischen diesen Servern die Verfügbarkeit und Skalierbarkeit in Echtzeit. Sie unterstützt das Filtern von Daten, damit eine Teilmenge der Daten auf Abonnenten abgestellt werden kann, und ermöglicht außerdem partitionierte Updates. Abonnenten sind online und für die Berichterstellung oder andere Funktionen verfügbar, ohne die Wiederherstellung von Abfragen. SQL Server bietet drei Replikationstypen: Snapshot-, Transaktions- und Mergereplikation. Die Transaktionsreplikation weist die geringste Latenzzeit auf und wird in der Regel für eine hohe Verfügbarkeit verwendet. Weitere Informationen finden Sie unter Verbesserung der Skalierbarkeit und Verfügbarkeit.

  Die Replikation wird in allen Editionen von SQL Server unterstützt. Die Replikationsveröffentlichung ist in SQL Server Express oder SQL Server Compact 3.5 SP1 nicht verfügbar.

  Wichtig
  Eine sorgfältig durchdachte und implementierte Sicherungs- und Wiederherstellungsstrategie ist für jede Hochverfügbarkeitslösung von entscheidender Bedeutung. Weitere Informationen finden Sie unter Sichern und Wiederherstellen von Datenbanken in SQL Server und Sichern und Wiederherstellen replizierter Datenbanken.

• Skalierbare, freigegebene Datenbanken

  Anhand des Features für skalierbare, freigegebene Datenbanken kann eine schreibgeschützte, ausschließlich für Berichtszwecke erstellte Datenbank (eine so genannte Berichtsdatenbank) dezentral skaliert werden. Die Berichtsdatenbank muss sich auf einer Gruppe von dedizierten, schreibgeschützten Volumes befinden, deren Zweck in erster Linie das Hosten der Datenbank ist. Mithilfe von Standardhardware für Server und Volumes können Sie eine Berichtsdatenbank dezentral skalieren, die eine identische Sicht der Berichtsdaten auf mehreren Berichtsservern bereitstellt. Dieses Feature ermöglicht zudem einen einfachen Updatepfad für die Berichtsdatenbank. Weitere Informationen finden Sie unter Übersicht über skalierbare freigegebene Datenbanken.