Planen der Verfügbarkeit (Office SharePoint Server)

  • Artikel

In diesem Artikel werden die allgemeinen Aspekte sowie die Kosten und Herausforderungen im Zusammenhang mit der Verfügbarkeit in einer Umgebung mit SharePoint-Produkten und -Technologien beschrieben. Zudem werden Strategien und Lösungen für diese Umgebung vorgestellt. Lesen Sie diesen Artikel, wenn in Ihrer Farm Microsoft Office SharePoint Server 2007 ausgeführt wird. Ergänzend zu diesem Artikel sollten Sie ggf. auch das Verfügbarkeitsmodell für Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=122369&clcid=0x407) herunterladen und drucken. Das Modell enthält auf Postergröße eine Zusammenfassung der Inhalte dieses Artikels.

Verfügbarkeit (Übersicht)

Verfügbarkeit ist der Grad, in dem eine Umgebung mit SharePoint-Produkten und -Technologien von Benutzern als verfügbar wahrgenommen wird. Verfügbarkeit bedeutet, sicherzustellen, dass ein System robust und flexibel ist – d. h., dass den Dienst beeinträchtigende Vorkommnisse selten auftreten und ggf. rechtzeitig effektive Abhilfemaßnahmen getroffen werden. Durch Verfügbarkeitsstrategien lässt sich die Wahrnehmung geplanter und ungeplanter Downtime beim Benutzer minimieren.

Eine der am häufigsten verwendeten Kennzahlen für die Verfügbarkeit ist die Betriebszeit in Prozent, ausgedrückt als Anzahl der Neuen – also der prozentuale Anteil der Zeit, die ein System aktiv und betriebsbereit ist. Ein System mit einer Betriebszeit von 99,999 % hat z. B. eine so genannte Verfügbarkeit von fünf Neunen.

In der folgenden Tabelle wird die Anzahl von Neunen mit der entsprechenden Kalenderzeit in Beziehung gesetzt.

Akzeptable Betriebszeit % Downtime/Tag Downtime/Monat Downtime/Jahr

95

72,00 Minuten

36 Stunden

18,26 Tage

99

14,40 Minuten

7 Stunden

3,65 Tage

99,9

86,40 Sekunden

43 Minuten

8,77 Stunden

99,99

8,64 Sekunden

4 Minuten

52,60 Minuten

99,999

0,86 Sekunden

26 Sekunden

5,26 Minuten

Wenn Sie die Gesamtstundenanzahl Ihrer Downtime realistisch abschätzen können, können Sie anhand der folgenden Formeln die prozentuale Betriebszeit für ein Jahr, einen Monat oder eine Woche berechnen:

% Betriebszeit/Jahr = 100 - (8760 - Gesamtanzahl der Downtimestunden pro Jahr)/8760

% Betriebszeit/Monat = 100 - ((24 * Anzahl der Tage im Monat) - Gesamtanzahl der Downtimestunden in diesem Kalendermonat)/(24 * Anzahl der Tage im Monat)

% Betriebszeit/Woche = 100 - (168 - Gesamtanzahl der Downtimestunden in dieser Woche)/168

Was bedeutet Verfügbarkeit nicht?

Verfügbarkeit betrifft weder Datenschutz und -wiederherstellung noch die Notfallwiederherstellung – obwohl diese Konzepte durchaus zusammenhängen und bei jedem hochverfügbaren System Datenschutz- und Notfallwiederherstellungspläne vorhanden sein sollten. Schutz und Wiederherstellung von Daten sind die allgemeinen Geschäftsanforderungen, die der folgenden spezifischen Geschäftsanforderungen zugrunde liegen:

  • Speichern und Überprüfen mehrerer Versionen eines Elements oder einer Website

  • Wiederherstellen versehentlich gelöschter Elemente oder Websites

  • Archivieren von Daten zu rechtlichen, behördlichen oder unternehmensbezogenen Zwecken

  • Wiederherstellen von Systemen bei unerwarteten Hardware- oder Softwarefehlern

Darüber hinaus ist Verfügbarkeit auch nicht mit betrieblichem Kontinuitätsmanagement (Business Continuity Management, BCM) gleichzusetzen. Das betriebliche Kontinuitätsmanagement umfasst die Geschäftsentscheidungen, Prozesse und Tools, die im Voraus zur Krisenbewältigung eingerichtet werden. Eine Krise kann ein lokales, regionales oder nationales Ereignis sein oder ausschließlich Ihr Unternehmen betreffen.

Die in den SharePoint-Produkten und -Technologien enthaltenen Verwaltungsstrategien für Verfügbarkeit und Datenschutz sind möglicherweise Bestandteil Ihres technischen BCM-Plans. Der übergeordnete BCM-Plan sollte allerdings wesentlich umfangreicher sein und die folgenden Elemente umfassen:

  • Klar dokumentierte Verfahren

  • Externe Speicherung der wichtigsten geschäftlichen Datensätze

  • Eindeutig festgelegte Ansprechpartner

  • Laufende Mitarbeiterschulungen

  • Externe Wiederherstellungsmechanismen

Kosten der Verfügbarkeit

Verfügbarkeit gehört zu den kostspieligeren Anforderungen an ein System. Je höher der Grad der Verfügbarkeit und je mehr Systeme eingebunden werden, umso komplexer und kostspieliger wird eine Verfügbarkeitslösung. Investitionen in Verfügbarkeit sind ggf. in den folgenden Bereichen erforderlich:

  • Zusätzliche Hardware und Software, häufig mit komplexen Vorgängen zwischen verschiedenen Softwareanwendungen, z. B. benutzerdefinierte Skripts für Failover und Wiederherstellung

  • Zusätzliche Komplexität beim Betrieb

Die Kosten für das Erreichen von Verfügbarkeit sollten auf Grundlage Ihrer Unternehmensanforderungen bewertet werden – in der Regel erfordern nicht alle Lösungen innerhalb eines Unternehmens dieselbe Verfügbarkeit. Sie können unterschiedliche Grade an Verfügbarkeit für verschiedene Standorte, Dienste (z. B. für Suche und Business Intelligence) oder Farmen anbieten.

Die Verfügbarkeit ist ein Schlüsselbereich, in dem IT-Gruppen Vereinbarungen zum Servicelevel bereitstellen, um Erwartungen seitens der Kundengruppen festzulegen. Viele IT-Organisationen bieten eine Reihe von Vereinbarungen zum Servicelevel an, die jeweils verschiedene Leistungen umfassen.

Hinweis

Beim Berechnen der Verfügbarkeit schließen die meisten Organisationen ausdrücklich Stunden für geplante Wartungsaktivitäten aus oder addieren diese hinzu.

Herausforderungen bezüglich der Verfügbarkeit in SharePoint-Produkten und -Technologien

Eine Bereitstellung von SharePoint-Produkten und -Technologien birgt die folgenden Herausforderungen bezüglich der Verfügbarkeit:

  • Beim Anwenden von Patches oder Aktualisieren der Farm ist die Farm nicht verfügbar.

  • Indexserverredundanz kann nicht durch Installieren der Indexrolle auf mehreren Servern erreicht werden. Beim Verlust eines Indexservers müssen Sie den Server erneut installieren und die Daten entweder von einer Sicherung wiederherstellen oder etwas veraltete Ergebnisse in Kauf nehmen, während die Inhalte vom Suchmodul erneut gecrawlt werden. Alternativ können Sie mithilfe einer der in den Abschnitten Verfügbarkeit der Suche innerhalb einer Farm und Verfügbarkeit der Suche in mehreren Farmen beschriebenen Techniken den Zeitaufwand für die Wiederherstellung der Suche reduzieren.

  • In SharePoint-Produkten und -Technologien wird die Microsoft SQL Server 2005-Datenbankspiegelung nicht erkannt. Es wird zwar empfohlen, die SQL Server-Spiegelung als Verfügbarkeitstechnik für SharePoint einzusetzen, dies erfordert jedoch zusätzliche Automatisierung.

Zeitpunkt der Verfügbarkeitsplanung

Verfügbarkeitsanforderungen sollten bereits im Rahmen des Kernentwurfs der SharePoint-Lösung berücksichtigt werden. Sie können auch nach der Bereitstellung der Lösung erweiterte Verfügbarkeit bereitstellen. Aus betrieblicher Sicht wird empfohlen, die Kernlösung innerhalb einer Farm bereitzustellen und zu optimieren und dann die Verfügbarkeitslösungen zu testen.

Bestimmen der Verfügbarkeitsanforderungen

Beantworten Sie die folgenden Fragen zur Website, zum Dienst oder zur Farm, um die Fehlertoleranz der Organisation gegenüber Downtime der Website, des Diensts oder der Farm abzuschätzen.

  • Führt die Nichtverfügbarkeit der Website, des Diensts oder der Farm dazu, dass die Mitarbeiter in der Organisation die ihnen zugewiesenen Aufgaben nicht mehr ausführen können?

  • Führt die Nichtverfügbarkeit der Website, des Diensts oder der Farm zu einer Unterbrechung von Geschäfts- und Kundentransaktionen, und gehen damit Geschäfte und/oder Kunden verloren?

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

Auswählen einer Verfügbarkeitsstrategie

Es gibt zahlreiche verschiedene Ansätze, um die Verfügbarkeit zu verbessern, u. a.:

  • Fehlertoleranz der Komponenten

  • Redundanz und Failover zwischen Serverrollen und Datenbanken innerhalb einer Farm

  • Redundanz und Failover zwischen Serverfarmen

Systemanforderungen für Verfügbarkeit

Im Idealfall sind die Failoverkomponenten und -systeme in allen Aspekten mit den Hauptkomponenten und dem Hauptsystem identisch: Plattform, Hardware und Anzahl der Server. Zumindest aber muss die Failoverumgebung in der Lage sein, den erwarteten Datenverkehr während eines Failovers zu verarbeiten. Beachten Sie, dass nur eine Teilmenge der Benutzer durch den Failoverstandort bedient werden kann. Die Systeme müssen mindestens in folgenden Aspekten übereinstimmen:

  • Betriebssystemversion und alle Updates

  • SQL Server-Versionen und alle Updates

  • Versionen der SharePoint-Produkte und -Technologien und alle Updates

In diesem Artikel wird zwar hauptsächlich die Verfügbarkeit der SharePoint-Produkte und -Technologien behandelt, die Systembetriebszeit wird jedoch auch von anderen Komponenten im System beeinflusst. Achten Sie daher insbesondere auf Folgendes:

Verfügbarkeit in einer Farm

Zur Unterstützung der Verfügbarkeit innerhalb einer Farm sehen Sie fehlertolerante Komponenten, redundante Serverrollen und Unterstützung der Datenbankverfügbarkeit (durch Clustering, Datenbankspiegelung oder beides) vor.

Komponentenfehlertoleranz

Unabhängig vom System wird empfohlen, fehlertolerante Hardware zu beschaffen, die für das System geeignet ist. Hierzu gehören auch RAID-Arrays (Redundant Array of Independent Disks). Empfehlungen hierzu finden Sie unter Planen von Leistung und Kapazität (Office SharePoint Server).

Beim Planen der Komponentenfehlertoleranz müssen Sie die folgenden Faktoren berücksichtigen:

  • Vollständige Redundanz jeder Komponente innerhalb eines Servers ist möglicherweise nicht möglich oder nicht praktikabel. Verwenden Sie zusätzliche Server für zusätzliche Redundanz.

  • Achten Sie besonders auf die Komponentenredundanz für die Indexserverrolle, da die Indexserverrolle selbst nicht redundant sein kann.

  • Stellen Sie sicher, dass Server für maximale Redundanz an mehrere Stromversorgungen mit verschiedenen Stromquellen angeschlossen sind.

Redundanz und Failover zwischen Serverrollen innerhalb einer Farm

SharePoint-Produkte und -Technologien unterstützen die Ausführung von Serverrollen auf redundanten Computern (d. h. horizontale Skalierung) innerhalb einer Serverfarm, um die Kapazität zu steigern, die Leistung zu verbessern und die grundlegende Verfügbarkeit zu ermöglichen. Kapazität und Leistung bestimmen die Anzahl von Servern sowie die Größe der Server in einer Farm. Nachdem die Grundanforderungen erfüllt sind, können Sie zur Verbesserung der allgemeinen Verfügbarkeit des Diensts weitere Server hinzufügen.

Redundanz in einer Farm mit einem einzigen Server

Verfügbarkeit einer einzelnen Farm

In der folgenden Tabelle werden die Serverrollen und Dienste in einer Umgebung mit SharePoint-Produkten und -Technologien beschrieben, wie sie auf der Seite Dienste auf dem Server auf der Website für die SharePoint-Zentraladministration aufgelistet sind, sowie die grundlegenden Redundanzstrategien, die für die einzelnen Serverrollen und Dienste innerhalb einer Farm verwendet werden können.

Dienste auf dem Server Bevorzugte grundlegende Redundanzstrategie innerhalb einer Farm

Webserver

Bereitstellung auf mehreren Servern und Lastenausgleich mithilfe von Software- oder Hardwarelastenausgleich

Webserver für mittlere Serverfarmen (Webanwendung und Sucheabfragedienste)

Bereitstellung auf mehreren Servern

Suchindizierung

Keine Bereitstellung auf mehreren Servern und keine Redundanz möglich. Sie müssen eine andere Verfügbarkeitsstrategie verwenden. Weitere Informationen finden Sie unter Verfügbarkeit der Suche innerhalb einer Farm.

Excel-Berechnungen

Bereitstellung auf mehreren Servern

Project-Anwendung

Bereitstellung auf mehreren Servern

Weitere Informationen finden Sie unter Planen von Redundanz (Office SharePoint Server).

Datenbankverfügbarkeitsstrategien für eine einzelne Farm

Datenbankverfügbarkeit innerhalb einer Farm kann mithilfe von SQL Server-Clustern oder SQL Server-Spiegelung mit hoher Verfügbarkeit (auch als synchrone Spiegelung bezeichnet) erreicht werden.

Clustering Failovercluster unterstützen die Verfügbarkeit einer vollständigen SQL Server-Instanz. Bei einem Failovercluster handelt es sich um eine Kombination von mindestens einem Knoten oder Server mit mindestens zwei freigegebenen Datenträgern. Eine Failovercluster-Instanz verhält sich nach außen hin wie ein einziger Computer, verfügt aber über Funktionen, die ein Failover auf einen anderen Knoten ermöglichen, wenn der aktuelle Knoten ausfällt.

Microsoft Office SharePoint Server 2007 verweist auf den Cluster als Ganzes, sodass der Failover aus der Sicht der SharePoint-Produkte und -Technologien automatisch und nahtlos erfolgt.

Synchrone Datenbankspiegelung Die Datenbankspiegelung unterstützt die Verfügbarkeit, indem Transaktionen direkt aus einer Prinzipaldatenbank und einem Prinzipalserver jedes Mal an eine Spiegeldatenbank und einen Spiegelserver gesendet werden, wenn der Transaktionsprotokollpuffer der Prinzipaldatenbank auf die Festplatte geschrieben wird. Es wird empfohlen, die Datenbankspiegelung mit hoher Verfügbarkeit zu verwenden, die auch als Hochsicherheitsmodus mit automatischem Failover bezeichnet wird. Die Datenbankspiegelung mit hoher Verfügbarkeit umfasst drei Serverinstanzen: einen Prinzipal, einen Spiegel und einen Zeugen. Der Zeugenserver ermöglicht SQL Server einen automatischen Failover vom Prinzipalserver auf den Spiegelserver. Der Failover der Prinzipaldatenbank zur Spiegeldatenbank dauert normalerweise einige Sekunden.

Jede Technologie hat ihre Vor- und Nachteile. Clustering ist einfacher zu implementieren, kann aber teurer sein. Die SQL Server-Spiegelung wird für Microsoft Office Project Server 2007-Datenbanken nicht unterstützt.

In der folgenden Tabelle werden Failovercluster und SQL Server-Spiegelung für hohe Verfügbarkeit verglichen.

SQL Server-Failovercluster SQL Server-Spiegelung für hohe Verfügbarkeit

Spiegelung übernimmt bei einem Ausfall sofort.

Spiegelung übernimmt bei einem Ausfall sofort.

Transaktionskonsistent

Transaktionskonsistent

Transaktionsparallel

Transaktionsparallel

Kürzeste Zeit bis zur Wiederherstellung (Sekunden bis wenige Minuten)

Etwas längere Zeit bis zur Wiederherstellung (Sekunden bis wenige Minuten)

Ausfall wird automatisch von Datenbankknoten erkannt; SharePoint-Produkte und -Technologien verweisen auf den Cluster, sodass der Failover aus der Sicht der SharePoint-Produkte und -Technologien nahtlos und automatisch erfolgt.

Skripterstellung für Failover für SharePoint-Produkte und -Technologien erforderlich.

Kein Schutz vor fehlerhafter Speicherung, weil der Speicherplatz von den Knoten im Cluster gemeinsam genutzt wird.

Schutz vor fehlerhafter Speicherung, da sowohl der Haupt- als auch der Spiegelungsdatenbankserver auf lokale Datenträger schreiben

Teurer freigegebener Speicher erforderlich

Verwendung von kostengünstigerem DAS (Direct-Attached Storage) möglich

Gleiches Subnetz

Wartezeit von bis zu 1 Millisekunde (ms) zwischen SQL Server und Webserver

Verwendung des einfachen Wiederherstellungsmodells von SQL Server möglich, allerdings ist bei einem Verlust des Clusters die letzte vollständige Sicherung der einzige verfügbare Wiederherstellungspunkt

Vollständiges Wiederherstellungsmodell von SQL Server erforderlich

Keine Beeinträchtigung der Systemleistung

Entstehung von Transaktionswartezeit, zusätzliche Speicher- und Prozessorbelastung

Minimaler Administrationsaufwand

Zusätzlicher Administrationsaufwand, einschließlich Skripterstellung und Einrichten von SQL Server-Aliasen

Weitere Informationen zur Verwendung von Clustering finden Sie unter Konfigurieren der Verfügbarkeit in einer einzelnen Farm mithilfe von SQL Server-Clustern.

Weitere Informationen zur Verwendung der synchronen Spiegelung finden Sie unter Konfigurieren der Verfügbarkeit in einer einzelnen Farm mithilfe von SQL Server-Datenbankspiegelung und Verwenden der Datenbankspiegelung (Office SharePoint Server) (Whitepaper).

Redundanz und Failover zwischen Rechenzentren in enger räumlicher Nähe, die als einzelne Farm konfiguriert sind ("ausgedehnte" Farm)

Einige Unternehmen verfügen über Rechenzentren in enger räumlicher Nähe und mit Verbindungen mit hoher Bandbreite, sodass diese als eine einzelne Farm konfiguriert werden können. Dies wird als "ausgedehnte" Farm bezeichnet. Für eine ausgedehnte Farm darf die Wartezeit zwischen SQL Server und Webserver in einer Richtung höchstens 1 Millisekunde betragen. Die Bandbreite muss mindestens 1 Gigabit pro Sekunde betragen.

  • In diesem Szenario können Sie Redundanz für SharePoint-Datenbanken mithilfe von synchroner Spiegelung bereitstellen. Innerhalb einer ausgedehnten Farm können Sie die Konfigurationsdatenbank und die Inhaltsdatenbanken spiegeln. Ein Fallbeispiel zur Verwendung einer ausgedehnten Farm in einem Unternehmen finden Sie unter Fallstudie zu hoher Verfügbarkeit für SharePoint mithilfe von Datenbankspiegelung (Whitepaper).

  • Wenden Sie sich an Ihren SAN-Hersteller, um festzustellen, ob Sie SAN-Replikation oder einen anderen unterstützten Mechanismus zur Bereitstellung von Verfügbarkeit für mehrere Rechenzentren verwenden können, z. B. SQL Server auf geografisch verteilten Serverclustern. Stellen Sie sicher, dass die SAN-Replikationslösung einen ausreichenden Grad an Parallelität und Transaktionskonsistenz bietet.

Innerhalb einer ausgedehnten Farm können Sie durch folgende Maßnahmen Fehlertoleranz für Anwendungsserver bereitstellen, auf denen SSPs ausgeführt werden:

  • Mehrere Abfrageserver

  • Mehrere Server mit Dienste für Excel-Berechnungen

Der Indexserver ist in diesem Szenario eine einzelne Fehlerquelle. Sie können die Suche entweder sichern und wiederherstellen oder, wenn die zeitnahe Suche bei der Wiederherstellung entscheidend ist, eine Failover-SSP-Farm verwenden. Weitere Informationen finden Sie unter Verfügbarkeit der Suche innerhalb einer Farm.

Project Server ist in diesem Szenario eine weitere einzelne Fehlerquelle. Planen Sie die Sicherung und Wiederherstellung Ihrer Project Server-Datenbanken.

Ausgedehnte Farm

'Gestreckte' Farm

Verfügbarkeit der Suche in einer Farm

Der Indexserverrolle kann innerhalb einer Farm nicht redundant sein. Die Anforderungen des Unternehmens an die zeitnahe Suche nach einem Failover beeinflussen die logische Architektur der Lösung.

Wenn vom Unternehmen die zeitnahe Suche und Verfügbarkeit nicht unmittelbar nach einem Failover benötigt werden, können Sie den Such-SSP sichern und am Failoverstandort wiederherstellen.

Wenn das Unternehmen die zeitnahe Suche und Verfügbarkeit schnell benötigt, können Sie eine der folgenden Methoden verwenden:

  • Eine Architektur mit einer einzelnen Farm und zwei identischen SSPs

    Hinweis

    Wenn das Unternehmen eine schnelle Gleichzeitigkeit der Suche und Verfügbarkeit erfordert und Profile verwendet werden, werden die Profile auf den Failover-SSPs nicht mit den Profilen auf den primären SSPs synchronisiert. Sie weisen vielmehr den Status zu dem Zeitpunkt auf, zu dem sie ursprünglich importiert wurden. Damit die Profile aller SSPs synchronisiert bleiben, steht Ihnen das User Profile Replication Engine-Tool zur Verfügung, das zum Lieferumfang von 32-Bit SharePoint Administration Toolkit (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x407) oder von 64-Bit SharePoint Administration Toolkit (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x407) gehört. Weitere Informationen finden Sie unter User Profile Replication Engine (Office SharePoint Server).

  • Eine zentrale übergeordnete Farm, auf der die Suche und andere SSPs gehostet werden. Der Suchdienst in der zentralen Farm crawlt Inhalt in allen anderen Farmen. Mit dieser Architektur können eine oder mehrere Farmen unterstützen werden.

Einzelne Farm mit zwei SSPs

Die folgende Architektur schützt vor Ausfällen eines Indexservers. In dieser Topologie crawlen beide SSPs denselben Inhalt und mithilfe der gleichen Regeln. Der Failover-SSP ist nur bei einem Failover mit der primären Website verbunden.

Einzelne Farm mit zwei Anbietern für gemeinsame Dienste

Farm mit zwei Anbietern für gemeinsame Dienste

Diese Topologie weist die folgenden Einschränkungen auf:

Die Möglichkeit, große Datenmengen in kurzer Zeit zu crawlen, wird durch mehrere Faktoren beeinflusst, unter anderem von der Wartezeit und Bandbreite zwischen Indexservern und Webservern.

In einer Umgebung mit begrenzter Bandbreite kann bei dieser Topologie die Leistung erheblich reduziert sein. Durch das zweimalige Crawlen des Inhalts werden die gecrawlten Inhaltsrepositorys zusätzlich belastet, wodurch die Repositoryleistung beeinträchtigt werden kann. Zudem kann die Fähigkeit, den Suchindex stets aktuell zu erhalten, beeinträchtigt werden.

Zentralisierte SSP-Farmen

In der folgenden Architektur schützt die Verwendung einer übergeordneten SSP-Farm vor Ausfällen eines Indexservers. Diese Lösung ist zwar auf den ersten Blick äußerst hardwareintensiv, separate SSP-Farmen können jedoch einige Hardware wie einen geclusterten oder gespiegelten Datenbankserver gemeinsam nutzen, sofern sich die Indexserver auf separaten Servern befinden. Weitere Informationen zum Planen und Konfigurieren von SSP-Farmen finden Sie unter Planen der SSP-Architektur.

Diese Topologie bietet die folgenden Vorteile:

  • Zentralisierte SSP-Verwaltung

  • Beim Ausfall einer Webfarm ist kein erneutes Crawlen erforderlich.

Zentralisierte SSP-Farmen

SSP-Failoverfarmen

Diese Topologie weist die folgenden Einschränkungen auf:

Redundanz und Failover zwischen Rechenzentren mit mehreren Farmen

Sie können eine Failoverfarm in einem von der primären Farm getrennten Datenzentrum einrichten, um Verfügbarkeit bereitzustellen. Eine Umgebung mit einer separaten Failoverfarm weist die folgenden Merkmale auf:

  • Auf der Failoverfarm müssen eine separate Konfigurationsdatenbank und Inhaltsdatenbank für die Zentraladministration verwaltet werden.

    Hinweis

    Wenn Sie alternative Zugriffszuordnungen für die primäre Farm konfiguriert haben, ist es besonders wichtig, diese auf der Failoverfarm genauso zu konfigurieren.

  • Alle Anpassungen müssen auf beiden Farmen bereitgestellt werden.

  • Patches müssen einzeln auf beiden Farmen angewendet werden.

  • Nur Inhaltsdatenbanken können erfolgreich asynchron gespiegelt oder mittels Protokollversand an die Failoverfarm geliefert werden.

  • Gespiegelte oder mittels Protokollversand gelieferte Datenbanken müssen das vollständige Wiederherstellungsmodell verwenden.

  • SSP-Datenbanken, einschließlich Office Project 2007-Datenbanken, können gesichert und auf der Failoverfarm wiederhergestellt werden.

Wenden Sie sich an Ihren SAN-Hersteller, um feststellen, ob Sie SAN-Replikation oder einen anderen unterstützten Mechanismus zur Bereitstellung von Verfügbarkeit für mehrere Rechenzentren verwenden können.

Diese Topologie kann über viele Rechenzentren wiederholt werden, wenn Sie den SQL Server-Protokollversand an mindestens ein zusätzliches Rechenzentrum konfigurieren.

Hinweis

Die SQL Server-Spiegelung kann nur mit einem einzigen Spiegelserver verwendet werden, Sie können aber den Protokollversand an mehrere sekundäre Server konfigurieren.

Primäre Farmen und Failoverfarmen vor dem Failover

Primäre Farm und Failoverfarm vor dem Failover

In der folgenden Tabelle sind die Serverrollen und Dienste in einer Umgebung mit SharePoint-Produkten und -Technologien sowie die grundlegenden Redundanzstrategien beschrieben, die für die einzelnen Serverrollen und Dienste zwischen Serverfarmen verwendet werden können.

Server oder Serverrolle Bevorzugte grundlegende Redundanzstrategie zwischen Farmen

SQL Server

Asynchrone SQL Server-Datenbankspiegelung, SQL Server-Protokollversand oder anderer asynchroner Replikationsmechanismus

Hinweis

Keine Verwendung für SSP-Datenbanken mit Suchinformationen sowie für Project Server-Datenbanken möglich.

Front-End-Webserver

Bereitstellung auf beiden Farmen, einschließlich aller Anpassungen

Webserver für mittelgroße Serverfarmen (Webanwendung und Suchabfragedienste)

Bereitstellung auf beiden Farmen

Suchindizierung

Bereitstellung auf beiden Farmen; Wechsel zur Failoverfarm durch Wiederherstellung der Sicherung von der ursprünglichen Farm

Excel-Berechnungen

Bereitstellung auf beiden Farmen; wenn der SSP nicht die Suche hostet, Möglichkeit zur Verschiebung der Daten auf die Failoverfarm mithilfe von asynchroner Datenbankspiegelung, SQL Server-Protokollversand oder einem anderen asynchronen Replikationsmechanismus

Wenn auch der Suchdienst vom SSP gehostet wird, muss die Sicherung von der ursprünglichen Serverfarm wiederhergestellt werden.

Project-Anwendung

Bereitstellung auf beiden Farmen; Wechsel zur Failoverfarm durch Wiederherstellung der Sicherung von der ursprünglichen Farm

Verfügbarkeit der Suche zwischen Farmen

Die Suche erfordert eine vollständige Synchronisierung zwischen der Suchdatenbank, der SSP-Datenbank und dem Index. Aufgrund dieser Anforderung kann die Suche nicht mithilfe eines asynchronen Replikationsmechanismus (asynchrone Datenbankspiegelung, Protokollversand oder asynchrone SAN-Replikation) zwischen Farmen repliziert werden.

Hinweis

Wenn ein SSP ohne Suche oder Project ausgeführt wird, kann ein asynchroner Replikationsmechanismus zum Verschieben von Daten verwendet werden.

Sie müssen eine der folgenden Methoden verwenden, um die Suche in einer Failoverfarm bereitzustellen:

  • Wiederherstellen einer Sicherung des Such-SSP auf der Failoverfarm

  • Verwenden einer zentralisierten übergeordneten Farm, die Suche und andere SSPs hostet. Der Suchdienst in der zentralen Farm crawlt Inhalt in allen anderen Farmen.

Zusammenfassung

Prüfen Sie Ihre Verfügbarkeitsanforderungen sorgfältig. Je höher der Grad der Verfügbarkeit und je mehr Systeme eingebunden werden, umso komplexer und kostspieliger wird eine Verfügbarkeitslösung.

Die Kosten für das Erreichen von Verfügbarkeit sollten auf Grundlage der Unternehmensanforderungen bewertet werden. In der Regel erfordern nicht alle Lösungen innerhalb eines Unternehmens dieselbe Verfügbarkeit. Sie können unterschiedliche Grade an Verfügbarkeit für verschiedene Standorte, Dienste (z. B. für Suche und Business Intelligence) oder Farmen anbieten.

Danksagungen

Das Content Publishing-Team für Microsoft Office SharePoint Server dankt den folgenden Experten für die Mitarbeit an diesem Whitepaper:

  • Bill Baer, Microsoft Online Services, Hosted SharePoint, Technologiearchitekt

  • James Petrosky, Microsoft Consulting Services, Leitender Berater

  • Steve Peschka, Microsoft Consulting Services, Leitender Architekt für die Informationsbeschaffung

  • Dan Winter, Microsoft-Kundendienst, Eskalationsingenieur

  • Sean Livingston, Microsoft SharePoint-Produkte und -Technologien, Programmmanager

  • Michael Watson, Technologiearchitekt

  • Todd Carter, Microsoft Premier Field Engineering, Leitender Techniker

  • Mike Plumley, Microsoft Office Project Server, Autor

  • Christophe Fiessinger, Microsoft Office Project, Leitender technischer Produktmanager

  • Sid Shah, Microsoft Search, Programmmanager

  • Luca Bandinelli, Microsoft SharePoint-Produkte und -Technologien, Programmmanager

Herunterladen dieses Buchs

Dieses Thema wurde zum leichteren Lesen und Ausdrucken in das folgende Buch zum Herunterladen aufgenommen:

Siehe auch

Konzepte

Konfigurieren von hoher Verfügbarkeit (Office SharePoint Server)