Planen der Verfügbarkeit (SharePoint Foundation 2010)

 

Gilt für: SharePoint Foundation 2010

Letztes Änderungsdatum des Themas: 2016-11-30

In diesem Artikel wird erläutert, welche wichtigen Entscheidungen Sie bei der Auswahl von Strategien zur Sicherstellung der Verfügbarkeit für eine Microsoft SharePoint Foundation 2010-Umgebung treffen müssen.

Denken Sie bei der Festlegung Ihrer Anforderungen hinsichtlich der Verfügbarkeit daran, dass die geplante Verfügbarkeitslösung umso komplexer und teuerer ist, je höher der Grad der Verfügbarkeit ist und je mehr Systeme geschützt werden sollen.

Wahrscheinlich wird nicht für alle Lösungen in einer Organisation eine gleich hohe Verfügbarkeit benötigt. Sie können für verschiedene Websites, Dienste oder Farmen unterschiedliche Verfügbarkeitsgrade anbieten.

Inhalt dieses Artikels

• Übersicht über Verfügbarkeit

• Auswählen einer Strategie für die Verfügbarkeit und eines Verfügbarkeitsgrads

• Redundanz und Failover zwischen nah beieinander befindlichen Rechenzentren, die als eine einzige Farm konfiguriert sind ("gestreckte" Farm)

Übersicht über Verfügbarkeit

Die Verfügbarkeit ist der Grad, zu dem eine SharePoint Foundation-Umgebung von den Benutzern als verfügbar wahrgenommen wird. Ein verfügbares System ist ein System, das robust ist, d. h. Zwischenfälle, die sich auf den Betrieb auswirken würden, treten selten auf, und wenn doch, dann werden zeitnah effektive Maßnahmen ergriffen.

Verfügbarkeit ist ein Bestandteil des Geschäftskontinuitätsmanagements und ist mit Verfahren zur Sicherung, Wiederherstellung und Notfallwiederherstellung verbunden. Weitere Informationen zu diesen zugehörigen Prozessen finden Sie unter Planen der Sicherung und der Wiederherstellung (SharePoint Foundation 2010) und Planen der Notfallwiederherstellung (SharePoint Foundation 2010).

Hinweis

Bei der Berechnung der Verfügbarkeit schließen die meisten Organisationen ausdrücklich geplante Wartungsaktivitäten aus oder addieren zusätzliche Stunden.

Eine der gängigsten Kennzahlen für die Verfügbarkeit ist die als Anzahl von Neunen angegebene prozentuale Betriebszeit, d. h. der Prozentsatz der Zeit, während der ein bestimmtes System aktiv und funktionsfähig ist. Ein System mit 99,999 % Betriebszeit wird beispielsweise als System mit einer Verfügbarkeit von fünf Neunen bezeichnet.

In der folgenden Tabelle werden die Werte für die prozentuale Betriebszeit den entsprechenden Werten in Kalenderzeit gegenübergestellt.

Akzeptable prozentuale Betriebszeit	Downtime pro Tag	Downtime pro Monat	Downtime pro Jahr
95	72,00 Minuten	36 Stunden	18,26 Tage
99 (zwei Neunen)	14,40 Minuten	7 Stunden	3,65 Tage
99,9 (drei Neunen)	86,40 Sekunden	43 Minuten	8,77 Stunden
99,99 (vier Neunen)	8,64 Sekunden	4 Minuten	52,60 Minuten
99,999 (fünf Neunen)	0,86 Sekunden	26 Sekunden	5,26 Minuten

Wenn Sie eine fundierte Schätzung der Gesamtzahl der Stunden Downtime abgeben können, die pro Jahr wahrscheinlich anfallen, können Sie mithilfe der folgenden Formeln die prozentuale Betriebszeit pro Jahr, pro Monat oder pro Woche berechnen:

% Betriebszeit/Jahr = 100 - (8760 - Gesamtzahl Stunden Downtime pro Jahr)/8760

% Betriebszeit/Monat = 100 - ((24 × Anzahl Tage in dem Monat) - Gesamtzahl Stunden Downtime in diesem Kalendermonat)/(24 × Anzahl Tage in dem Monat)

% Betriebszeit/Woche = 100 - (168 - Gesamtzahl Stunden Downtime in dieser Woche)/168

Kosten der Verfügbarkeit

Die Verfügbarkeit ist eine der kostenintensiveren Anforderungen in einem System. Je höher der Grad der Verfügbarkeit ist und je mehr Systeme geschützt werden sollen, desto komplexer und teuerer ist die geplante Verfügbarkeitslösung wahrscheinlich. Wenn Sie in Lösungen zur Sicherstellung der Verfügbarkeit investieren, umfassen die Kosten Folgendes:

• Zusätzliche Hardware und Software; dadurch werden die Interaktionen zwischen Softwareanwendungen und Einstellungen u. U. komplizierter.

• Zusätzliche Komplexität der Betriebsabläufe.

Die Kosten der Verbesserung der Verfügbarkeit sollten vor dem Hintergrund Ihrer geschäftlichen Anforderungen bewertet werden – wahrscheinlich wird nicht für alle Lösungen in einer Organisation eine gleich hohe Verfügbarkeit benötigt. Sie können für verschiedene Websites, Dienste oder Farmen unterschiedliche Verfügbarkeitsgrade anbieten.

Verfügbarkeit ist ein wichtiger Bereich, in dem IT-Gruppen Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) bereitstellen, in denen die Erwartungen der Kundengruppen festgelegt sind. Viele IT-Organisationen bieten unterschiedliche Vereinbarungen zum Servicelevel an, die jeweils unterschiedliche Leistungen umfassen.

Festlegen der Anforderungen hinsichtlich der Verfügbarkeit

Sie können die Toleranz Ihrer Organisation in Bezug auf Downtime für eine Website, einen Dienst oder eine Farm ermitteln, indem Sie die folgenden Fragen beantworten:

• Wenn die Website, der Dienst oder die Farm nicht mehr verfügbar ist, können die Mitarbeiter dann die Aufgaben gemäß ihrer Position nicht mehr erfüllen?

• Wenn die Website, der Dienst oder die Farm nicht mehr verfügbar ist, werden dann Geschäfts- und Kundentransaktionen gestoppt, was wiederum zu entgangenem Geschäft und Kundenverlust führt?

Wenn Sie eine dieser Fragen mit "Ja" beantwortet haben, sollten Sie in eine Verfügbarkeitslösung investieren.

Auswählen einer Strategie für die Verfügbarkeit und eines Verfügbarkeitsgrads

Sie können zwischen mehreren Möglichkeiten wählen, um die Verfügbarkeit in einer SharePoint Foundation-Umgebung zu verbessern. Einige Beispiele:

• Verbessern der Fehlertoleranz von Serverhardwarekomponenten.

• Erhöhen der Redundanz von Serverrollen innerhalb einer Farm.

Fehlertoleranz der Hardwarekomponenten

Die Fehlertoleranz der Hardwarekomponenten ist die Redundanz von Hardwarekomponenten und Infrastruktursystemen, z. B. der Stromversorgungen auf Serverebene. Berücksichtigen Sie beim Planen der Fehlertoleranz von Hardwarekomponenten Folgendes:

• Vollständige Redundanz aller Komponenten auf einem Server ist möglicherweise unmöglich oder nicht praktikabel. Verwenden Sie zusätzliche Server, um die Redundanz zu erhöhen.

• Stellen Sie sicher, dass die Server mehrere Stromversorgungen haben, die an unterschiedliche Stromquellen angeschlossen sind, um maximale Redundanz zu erreichen.

Es empfiehlt sich in jedem System, mit Hardwareherstellern zusammenzuarbeiten, um fehlertolerante Hardware zu erhalten, die für das System geeignet ist. Dazu gehören RAID-Arrays (Redundant Array of Independent Disks).

Redundanz innerhalb einer Farm

SharePoint Foundation 2010 unterstützt das Ausführen von Serverrollen auf redundanten Computern innerhalb einer Farm (horizontale Skalierung), um die Kapazität zu erhöhen und grundlegende Verfügbarkeit zu sicherzustellen.

Die benötigte Kapazität bestimmt sowohl die Anzahl der Server als auch die Größe der Server in einer Farm. Wenn die grundlegenden Kapazitätsanforderungen erfüllt sind, ist es vielleicht ratsam, weitere Server hinzuzufügen, um die allgemeine Verfügbarkeit zu erhöhen. Die folgende Abbildung veranschaulicht, wie Sie Redundanz für jede Serverrolle bereitstellen können.

Verfügbarkeit innerhalb einer Serverfarm

In der folgenden Tabelle werden die Serverrollen in einer SharePoint Foundation 2010-Umgebung und die Redundanzstrategien beschrieben, die sie in einer Farm für jede Serverrolle anwenden können.

Serverrolle	Bevorzugte Redundanzstrategie innerhalb einer Farm
Front-End-Webserver	Mehrere Front-End-Webserver in einer Farm bereitstellen und Netzwerklastenausgleich verwenden.
Anwendungsserver	Mehrere Anwendungsserver innerhalb einer Farm bereitstellen.
Datenbankserver	Datenbankserver mithilfe von Clustering oder Datenbankspiegelung für hohe Verfügbarkeit bereitstellen.

Strategien für die Verfügbarkeit von Datenbanken

Sie können Microsoft SQL Server-Failovercluster oder SQL Server-Datenbankspiegelung für hohe Verfügbarkeit verwenden, um die Verfügbarkeit von Datenbanken in einer SharePoint Foundation-Umgebung zu unterstützen.

SQL Server-Failovercluster

Mit Failoverclustern können Sie die Verfügbarkeit für eine Instanz von SQL Server unterstützen. Ein Failovercluster ist eine Kombination aus einem oder mehreren Knoten oder Servern und zwei oder mehreren freigegebenen Datenträgern. Eine Instanz eines Failoverclusters wird als ein einzelner Computer angezeigt, bietet jedoch die Möglichkeit eines Failovers von einem Knoten zum anderen, wenn der aktuelle Knoten nicht mehr verfügbar ist. SharePoint Foundation kann auf einer beliebigen Kombination aus aktiven und passiven Knoten in einem Cluster ausgeführt werden, die von SQL Server unterstützt wird.

SharePoint Foundation referenziert den Cluster als Ganzes. Daher erfolgt das Failover aus der Perspektive von SharePoint Foundation automatisch und nahtlos.

Ausführliche Informationen zu Failoverclustern finden Sie unter Erste Schritte mit der SQL Server 2008 R2-Failover-Clusterunterstützung (https://go.microsoft.com/fwlink/?linkid=102837&clcid=0x407) and Konfigurieren der Verfügbarkeit mithilfe von SQL Server-Clustern (SharePoint Foundation 2010).

SQL Server-Spiegelung für hohe Verfügbarkeit

Datenbankspiegelung ist eine SQL Server-Technologie, mit der Sie Datenbankredundanz für jede Datenbank einzeln herstellen können. Bei der Datenbankspiegelung werden Transaktionen direkt von einer Prinzipaldatenbank und einem Prinzipalserver zu einer Spiegeldatenbank und einem Spiegelserver gesendet, wenn der Transaktionsprotokollpuffer der Prinzipaldatenbank auf den Datenträger geschrieben wird. Durch diese Methode kann die Spiegeldatenbank fast auf dem gleichen Stand wie die Prinzipaldatenbank gehalten werden. SQL Server Enterprise Edition bietet zusätzliche Funktionen, mit der die Leistung der Datenbankspiegelung noch gesteigert werden kann.

Für die Spiegelung in einer SharePoint Foundation-Farm müssen Sie Spiegelung für hohe Verfügbarkeit verwenden, auch als Hochsicherheitsmodus mit automatischem Failover bezeichnet. Die Datenbankspiegelung für hohe Verfügbarkeit umfasst drei Serverinstanzen: einen Prinzipalserver, einen Spiegelserver und einen Zeugenserver. Durch den Zeugenserver wird es SQL Server ermöglicht, ein automatisches Failover vom Prinzipalserver zum Spiegelserver durchzuführen. Das Failover von der Prinzipaldatenbank zur Spiegeldatenbank dauert in der Regel einige Sekunden.

Eine Änderung gegenüber früheren Versionen besteht darin, dass SharePoint Foundation spiegelungsfähig ist. Nachdem Sie eine Datenbankspiegelungsinstanz von SQL Server konfiguriert haben, verwenden Sie die SharePoint-Zentraladministration oder Windows PowerShell-Cmdlets, um den Standort des Failover-Datenbankservers (Spiegel-Datenbankservers) für eine Konfigurationsdatenbank, eine Inhaltsdatenbank oder eine Dienstanwendungsdatenbank anzugeben. Durch das Festlegen eines Standorts für die Failoverdatenbank wird der Verbindungszeichenfolge, die SharePoint Foundation zum Herstellen einer Verbindung zu SQL Server verwendet, ein Parameter hinzugefügt. Bei einem SQL Server-Timeoutereignis geschieht Folgendes:

1. Der Zeugenserver, der für die SQL Server-Spiegelung konfiguriert ist, vertauscht automatisch die Rollen der primären Datenbank und der Spiegeldatenbank.

2. SharePoint Foundation versucht automatisch, den Server zu kontaktieren, der als Failoverdatenbank angegeben ist.

Weitere Informationen zum Konfigurieren der Datenbankspiegelung finden Sie unter Konfigurieren der Verfügbarkeit mithilfe der SQL Server-Datenbankspiegelung (SharePoint Foundation 2010).

Allgemeine Informationen zur Datenbankspiegelung finden Sie unter Datenbankspiegelung (https://go.microsoft.com/fwlink/?linkid=180597&clcid=0x407).

Hinweis

Datenbanken, die für die Verwendung des Remote-BLOB-Speicheranbieters FILESTREAM von SQL Server konfiguriert wurden, können nicht gespiegelt werden.

Vergleich der Strategien für Datenbankverfügbarkeit für eine einzelne Farm: SQL Server-Failovercluster oder SQL Server-Spiegelung für hohe Verfügbarkeit

In der folgenden Tabelle wird die Failovercluster-Strategie mit der synchronen SQL Server-Spiegelung für hohe Verfügbarkeit verglichen.

	SQL Server-Failovercluster	SQL Server-Spiegelung für hohe Verfügbarkeit
Zeit bis zum Failover	Clustermitglied übernimmt nach Ausfall sofort.	Spiegel übernimmt nach Ausfall sofort.
Konsistenz der Transaktionen?	Ja	Ja
Parallelität der Transaktionen?	Ja	Ja
Zeit bis zur Wiederherstellung	Kürzere Wiederherstellungsdauer (Millisekunden)	Etwas längere Wiederherstellungsdauer (Millisekunden).
Erforderliche Schritte für Failover?	Ein Fehler wird von den Datenbankknoten automatisch erkannt. Die Cluster werden in SharePoint Foundation 2010 referenziert, sodass das Failover nahtlos und automatisch erfolgt.	Ein Fehler wird von der Datenbank automatisch erkannt. SharePoint Foundation 2010 kennt den Spiegelstandort, sofern dieser korrekt konfiguriert wurde, daher erfolgt das Failover automatisch.
Schutz vor Speicherausfall?	Schützt nicht vor Speicherausfall, da Speicher von den Knoten im Cluster gemeinsam verwendet wird.	Schützt vor Speicherausfall, da sowohl der Prinzipal- als auch der Spiegeldatenbankserver auf lokale Datenträger schreiben.
Unterstützte Speichertypen	Gemeinsam genutzter Speicher (teuerer).	Kann kostengünstigeren DAS (Direct-Attached Storage) verwenden.
Standortvoraussetzungen	Clustermitglieder müssen sich im gleichen Subnetz befinden.	Prinzipal-, Spiegel- und Zeugenserver müssen sich im gleichen LAN befinden (Roundtrip-Latenz bis zu 1 ms).
Wiederherstellungsmodell	SQL Server-Modell der vollständigen Wiederherstellung empfohlen. Sie können auch das SQL Server-Modell der einfachen Wiederherstellung verwenden, dann ist aber die letzte vollständige Sicherung der einzige verfügbare Wiederherstellungspunkt, wenn der Cluster ausfällt.	Erfordert das SQL Server-Modell der vollständigen Wiederherstellung.
Leistungsverhalten	Während eines Failovers kann es zu gewissen Leistungseinbußen kommen.	Da die Spiegelung für hohe Verfügbarkeit synchron ist, tritt eine Latenz bei Transaktionen auf. Außerdem werden hierfür zusätzlicher Arbeitsspeicher und Prozessorleistung beansprucht.
Betriebsaufwand	Wird auf Serverebene eingerichtet und verwaltet.	Aufwand höher als beim Clustering; muss für alle Datenbanken eingerichtet und verwaltet werden; Neukonfiguration nach dem Failover erfolgt manuell.

Strategien für die Redundanz von Dienstanwendungen

Welche Redundanzstrategie Sie für den Schutz der in einer Farm ausgeführten Dienstanwendungen verwenden, hängt davon ab, wo die Dienstanwendungen Daten speichern.

Dienstanwendungen, die Daten in Datenbanken speichern

So schützen Sie Dienstanwendungen, die Daten in Datenbanken speichern

1. Installieren Sie den Dienst auf mehreren Anwendungsservern, um Redundanz innerhalb der Umgebung herzustellen.

2. Konfigurieren Sie SQL Server-Clustering oder -Spiegelung, um die Daten zu schützen.

Die folgenden Dienstanwendungen speichern Daten in Datenbanken:

• Business Data Connectivity Service-Anwendung

• Anwendungsregistrierungsdienst-Anwendung

  Von der Spiegelung der Anwendungsregistrierungsdatenbank wird abgeraten, da diese nur beim Upgraden von Windows SharePoint Services 3,0 Business Data Catolog-Informationen auf SharePoint Foundation 2010 verwendet wird.

• Dienstanwendung für die Erfassung von Verwendungs- und Integritätsdaten

  Hinweis

  Es wird davon abgeraten, die Protokollierungsdatenbank der Dienstanwendung für die Erfassung von Verwendungs- und Integritätsdaten zu spiegeln.

• Dienstanwendung Microsoft SharePoint Foundation-Abonnementeinstellungen

Redundanz und Failover zwischen nah beieinander befindlichen Rechenzentren, die als eine einzige Farm konfiguriert sind ("gestreckte" Farm)

Manche Unternehmen unterhalten Rechenzentren, die sich nah beieinander befinden und die über Verbindungen mit hoher Bandbreite miteinander vernetzt sind, sodass sie als eine einzige Farm konfiguriert werden können. Dies wird als "gestreckte" Farm bezeichnet. Damit eine gestreckte Farm funktioniert, muss die Latenz zwischen SQL Server und den Front-End-Webservern in einer Richtung unter 1 ms liegen, und die Bandbreite muss mindestens 1 Gbps betragen.

In diesem Szenario können Sie Fehlertoleranz sicherstellen, indem Sie die gängigen Verfahren für die Herstellung von Redundanz für Datenbanken und Dienstanwendungen ausführen.

Die folgende Abbildung zeigt eine gestreckte Farm.

Gestreckte Farm