Planen der Verfügbarkeit (Search Server 2008)

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 Search Server 2008 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) (in englischer Sprache) herunterladen. Das Modell enthält auf Postergröße eine Zusammenfassung der Inhalte dieses Artikels.

Was versteht man unter Verfügbarkeit?

Die Verfügbarkeit gibt an, zu welchem Grad eine Umgebung mit SharePoint-Produkten und -Technologien von Benutzern als verfügbar wahrgenommen wird. Um die Verfügbarkeit sicherzustellen, muss dafür gesorgt werden, dass ein System robust ist, also dass den Betrieb beeinträchtigende Vorfälle selten auftreten und dass ggf. rechtzeitig geeignete Gegenmaßnahmen ergriffen werden. Verfügbarkeitsstrategien minimieren geplante und ungeplante Downtime für den Benutzer.

Eines der bekanntesten Verfügbarkeitsmaße ist die prozentuale Betriebszeit, angegeben als Anzahl der Neunen. Hiermit wird der prozentuale Anteil der Zeit bezeichnet, in der ein 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 wird die Anzahl von Neunen mit der entsprechenden Kalenderzeit in Beziehung gesetzt.

Annehmbare 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 eine fundierte Vermutung bezüglich der wahrscheinlichen Gesamtanzahl von Downtimestunden anstellen möchten, können Sie mithilfe der folgenden Formeln die prozentuale Betriebszeit für ein Jahr, einen Monat oder eine Woche berechnen:

% Uptime/year = 100 - (8760 - number of total hours down per year)/8760

% Uptime/month = 100 - ((24 * number of days in the month) - number of total hours down in that calendar month)/(24 * number of days in the month)

% Uptime/week = 100 - (168 - number of total hours down in that week)/168

Was man nicht unter Verfügbarkeit versteht

Die Verfügbarkeit ist weder Datenschutz und -wiederherstellung noch eine Notfallwiederherstellung, obwohl diese Konzepte damit in Beziehung stehen und in jedem hochverfügbaren System Pläne für den Datenschutz und die Notfallwiederherstellung vorhanden sein sollten. Das Schützen und Wiederherstellen von Daten ist eine allgemeine Unternehmensanforderung, der die folgenden speziellen Unternehmensanforderungen 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 im Fall von unerwarteten Hardware- oder Softwarefehlern

Ebenso ist Verfügbarkeit nicht gleichbedeutend mit Geschäftskontinuitätsmanagement. Geschäftskontinuitätsmanagement besteht aus den Unternehmensentscheidungen, Prozessen und Tools, die Sie vorab zur Bewältigung von Krisensituationen bereitstellen. Bei einer Krise kann es sich um ein lokales, regionales oder nationales Ereignis handeln. Eine Krise kann sich aber auch nur auf Ihr Unternehmen beziehen.

Strategien für die Verwaltung von Verfügbarkeit und Datenschutz von SharePoint-Produkten und -Technologien können Teil Ihres technischen BCM-Plans sein. Ihr BCM-Gesamtplan sollte jedoch wesentlich umfassender sein und folgende Bestandteile aufweisen:

• Klar dokumentierte Verfahren

• Offsitespeicherung von wichtigen Unternehmensunterlagen

• Eindeutig festgelegte Kontaktpersonen

• Ständiges Mitarbeitertraining

• Offsitewiederherstellungsmechanismen

Kosten der Verfügbarkeit

Die Verfügbarkeit zählt zu den teureren Anforderungen für ein System. Je höher der Verfügbarkeitsgrad und je mehr Systeme geschützt werden, desto komplexer und kostspieliger dürfte eine Verfügbarkeitslösung sein. Im Zusammenhang mit der Verfügbarkeit fallen die folgenden Investitionskosten an:

• Zusätzliche Hardware und Software, was häufig komplexe Operationen zwischen Software beinhaltet, wie z. B. benutzerdefinierte Skripts für Failover und Wiederherstellung.

• Zusätzliche operative Komplexität

Die Kosten für die Verfügbarkeit sollten basierend auf Ihren Unternehmensanforderungen bewertet werden, denn nicht für alle Lösungen in einem Unternehmen ist in der Regel derselbe Verfügbarkeitsgrad erforderlich. Sie können unterschiedliche Verfügbarkeitsgrade für verschiedene Websites und Dienste (z. B. Suche und Business Intelligence) oder für verschiedene Serverfarmen 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.

Herausforderungen bei der Verfügbarkeit in SharePoint-Produkten und Technologien

Eine Bereitstellung von SharePoint-Produkten und -Technologien beinhaltet die folgenden Herausforderungen im Hinblick auf die Verfügbarkeit:

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

• Die Indexserverredundanz kann nicht durch Installieren der Indexrolle auf mehreren Servern erreicht werden. Um den Verlust eines Indexservers zu überwinden, müssen Sie den Server neu installieren und entweder von einer Sicherung wiederherstellen oder etwas veraltete Ergebnisse beim erneuten Crawlen des Inhalts durch den Suchdienst in Kauf nehmen. Alternativ können Sie mithilfe einer der unter Verfügbarkeit der Suche nach einem Failover beschriebenen Techniken den Zeitaufwand zum Wiederherstellen der Suche reduzieren.

• Die SQL Server-Spiegelung wird von den SharePoint-Produkten und -Technologien nicht unterstützt. Die SQL Server-Spiegelung wird zwar als Verfügbarkeitstechnik empfohlen, aber dies erfordert zusätzliche Automatisierung.

Wann die Verfügbarkeit berücksichtigt werden sollte

Es wird empfohlen, Verfügbarkeitsanforderungen beim grundlegenden Entwurf der SharePoint-Lösung zu berücksichtigen. Sie können auch nach der Bereitstellung der Lösung eine verbesserte Verfügbarkeit anbieten. Sie sollten die Kernlösung innerhalb einer Serverfarm bereitstellen und optimieren und dann die Verfügbarkeitslösungen testen.

Bestimmen der Verfügbarkeitsanforderungen

Beantworten Sie die folgenden Fragen für die Website, den Dienst oder die Serverfarm, um die Toleranz der Organisation hinsichtlich der Downtime zu ermitteln.

• Führt die Nichtverfügbarkeit der Website, des Diensts oder der Serverfarm 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 Serverfarm zu einer Unterbrechung von Geschäfts- und Kundentransaktionen, und gehen damit Geschäfte und Kunden verloren?

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

Auswählen einer Verfügbarkeitsstrategie

Sie haben die Auswahl unter vielen verschiedenen Methoden zur Optimierung der Verfügbarkeit:

• Fehlertoleranz der Komponenten

• Redundanz und Failover zwischen Serverrollen in einer Serverfarm

• Redundanz und Failover zwischen Serverfarmen

Systemanforderungen hinsichtlich der Verfügbarkeit

Im Idealfall stimmen die Failoverkomponenten und Systeme mit den Hauptkomponenten und dem System in jeder Hinsicht überein: Plattform, Hardware, Anzahl der Server. Die Failoverumgebung muss mindestens den erwarteten Datenverkehr während eines Failovers bewältigen können. Denken Sie daran, dass die Failoverwebsite möglicherweise nur für einen Teil der Benutzer zuständig ist. Die Systeme müssen mindestens in folgenden Punkten übereinstimmen:

• Betriebssystemversion und alle Updates

• SQL Server-Versionen und alle Updates

• Versionen und alle Updates von SharePoint-Produkten und -Technologien

In diesem Artikel wird zwar in erster Linie die Verfügbarkeit von SharePoint-Produkten und -Technologien behandelt, aber die Systembetriebszeit wird auch durch die anderen Komponenten im System beeinflusst. Berücksichtigen Sie insbesondere Folgendes:

• Sie sollten sicherstellen, dass Infrastrukturabhängigkeiten, wie z. B. Stromversorgung, Kühlung, Netzwerk, Verzeichnis und SMTP, vollständig redundant sind.

• Wählen Sie für das System einen Umschaltmechanismus, egal ob DNS- oder Hardwarelastenausgleich, der Ihren Anforderungen entspricht. Bewährte Methoden für den Lastenausgleich von Webservern finden Sie in den folgenden Artikeln:

  • Enterprise Design for Load Balancing in englischer Sprache (https://go.microsoft.com/fwlink/?linkid=122194&clcid=0x407) (Unternehmensentwurf für den Lastenausgleich)

  • Enterprise Design for DNS in englischer Sprache (https://go.microsoft.com/fwlink/?linkid=122196&clcid=0x407) (Unternehmensentwurf für DNS)

  • Web Server Load Balancing and Redundancy in englischer Sprache (https://go.microsoft.com/fwlink/?linkid=122197&clcid=0x407) (Lastenausgleich und Redundanz für Webserver)

Komponentenfehlertoleranz

Für jedes System wird empfohlen, zusammen mit Hardwareherstellern nach fehlertoleranter Hardware zu suchen, die für das System geeignet ist, einschließlich RAID-Arrays (Redundant Array of Independent Disks). Empfehlungen hierzu finden Sie unter Planen der Leistung und Kapazität (Windows SharePoint Services).

Beachten Sie beim Planen der Komponentenfehlertoleranz Folgendes:

• Die vollständige Redundanz jeder Komponente auf einem Server ist unter Umständen nicht möglich oder nicht praktikabel. Verwenden Sie zusätzliche Server für eine höhere Redundanz.

• Berücksichtigen Sie die Komponentenredundanz für die Indexserverrolle, da die Indexserverrolle nicht als redundant festgelegt werden kann.

• Stellen Sie sicher, dass die Server mehrere Netzteile aufweisen, die an verschiedene Steckdosen angeschlossen sind, um eine optimale Redundanz zu erzielen.

Redundanz und Failover zwischen Serverrollen in einer Serverfarm

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 Serverfarm. Wenn die grundlegenden Anforderungen erfüllt sind, können Sie weitere Server hinzufügen, um die allgemeine Verfügbarkeit des Diensts zu steigern.

Verfügbarkeit in einer Serverfarm mit einem einzelnen Server

In der folgenden Tabelle werden die Server und Serverrollen in einer Umgebung mit SharePoint-Produkten und -Technologien, so wie sie auf der Seite Dienste auf dem Server auf der Website für die SharePoint-Zentraladministration aufgelistet sind, sowie die jeweils in einer Serverfarm verfügbaren grundlegenden Redundanzstrategien beschrieben.

Dienste auf dem Server	Bevorzugte grundlegende Redundanzstrategie in einer Serverfarm
SQL Server	Clusterunterstützung oder synchrone Spiegelung. Die Clusterunterstützung ist einfacher zu implementieren, aber möglicherweise teurer. Weitere Informationen zum Verwenden der synchronen Spiegelung finden Sie unter Verwenden der Datenbankspiegelung (Office SharePoint Server) (Whitepaper).
Webserver	Bereitstellen auf mehreren Servern und Lastenausgleich mithilfe des Software- oder Hardwarelastenausgleichs.
Webserver für mittelgroße Serverfarmen (Webanwendung und Suchabfragedienste)	Bereitstellen auf mehreren Servern.
Suchindizierung	Kann nicht auf mehreren Servern bereitgestellt werden und redundant sein. Sie müssen eine andere Verfügbarkeitsstrategie verwenden. Weitere Informationen finden Sie unter Verfügbarkeit der Suche nach einem Failover.
Excel-Berechnung	Bereitstellen auf mehreren Servern.
Project-Anwendung	Bereitstellen auf mehreren Servern.

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

Vergleich der Verfügbarkeitsstrategien für Datenbanken für eine einzelne Serverfarm: SQL Server-Failover-Clusterunterstützung und SQL Server-Hochverfügbarkeitsspiegelung

In der folgenden Tabelle wird die Failover-Clusterunterstützung mit der synchronen SQL Server-Hochverfügbarkeitsspiegelung verglichen.

SQL Server-Failover-Clusterunterstützung	SQL Server-Hochverfügbarkeitsspiegelung
Spiegelung übernimmt sofort bei einem Ausfall.	Spiegelung übernimmt sofort bei einem Ausfall.
In Bezug auf Transaktionen konsistent.	In Bezug auf Transaktionen konsistent.
In Bezug auf Transaktionen gleichzeitig.	In Bezug auf Transaktionen gleichzeitig.
Kürzeste Wiederherstellungszeit (Sekunden bis Minuten).	Geringfügig längere Wiederherstellungszeit (Sekunden bis Minuten).
Der Fehler wird automatisch von Datenbankknoten erkannt. SharePoint-Produkte und -Technologien verweisen auf den Cluster, sodass das Failover aus Sicht der SharePoint-Produkte und -Technologien nahtlos und automatisch erfolgt.	Erfordert Skripterstellung für das Failover von SharePoint-Produkten und -Technologien.
Bietet keinen Schutz vor fehlerhaftem Speicherplatz, da Speicherplatz von Knoten im Cluster gemeinsam genutzt wird.	Schützt vor fehlerhaftem Speicherplatz, da Haupt- und Spiegeldatenbankserver auf lokale Datenträger schreiben.
Erfordert teureren gemeinsam genutzten Speicherplatz.	Kostengünstigerer DAS (Direct-Attached Storage) kann verwendet werden.
Gleiches Subnetz.	Latenz von bis zu 1 Millisekunde (ms) zwischen SQL Server und Webservern.
Das einfache Wiederherstellungsmodell von SQL Server kann verwendet werden. Bei einem Verlust des Clusters ist allerdings die letzte verfügbare vollständige Sicherung die einzige Methode zum Wiederherstellen des Clusters.	Erfordert das vollständige Wiederherstellungsmodell von SQL Server.
Kein Leistungsmehraufwand.	Transaktionslatenz, Mehraufwand für Arbeitsspeicher und Prozessor.
Minimaler zusätzlicher Arbeitsaufwand.	Zusätzlicher Arbeitsaufwand, einschließlich der Skripterstellung und der Einrichtung von SQL Server-Aliasen.

Redundanz und Failover zwischen benachbarten Rechenzentren, die als einzelne Serverfarm konfiguriert sind (ausgedehnte Serverfarm)

In einigen Unternehmen gibt es Rechenzentren, die über Hochgeschwindigkeitsverbindungen eng miteinander verbunden sind, sodass sie als eine einzelne Serverfarm konfiguriert werden können. Dies wird als ausgedehnte Serverfarm bezeichnet. Eine ausgedehnte Serverfarm muss eine Latenz von weniger als 1 Millisekunde zwischen SQL Server und den Webservern in einer Richtung und mindestens 1 GB pro Sekunde an Bandbreite aufweisen, damit sie ordnungsgemäß ausgeführt wird.

• In diesem Szenario ist die Redundanz für Datenbanken mithilfe der synchronen Spiegelung möglich. Innerhalb einer ausgedehnten Serverfarm können Sie die Konfigurationsdatenbank und die Inhaltsdatenbanken spiegeln. Ein Fallbeispiel für die Verwendung einer ausgedehnten Serverfarm in einem Unternehmen finden Sie unter Fallstudie zu hoher Verfügbarkeit für SharePoint mithilfe von Datenbankspiegelung (Whitepaper).

• Wenden Sie sich an den SAN-Hersteller, um festzustellen, ob Sie die SAN-Replikation oder einen anderen unterstützten Mechanismus zur Bereitstellung der Verfügbarkeit in Rechenzentren verwenden können, wie z. B. SQL Server auf geografisch verteilten Serverclustern. Stellen Sie sicher, dass die SAN-Replikationslösung einen ausreichenden Grad an Gleichzeitigkeit und Transaktionskonsistenz bietet.

Innerhalb einer ausgedehnten Serverfarm können Sie mit folgenden Mitteln die Fehlertoleranz für Anwendungsserver, auf denen SSPs ausgeführt werden, ermöglichen:

• Mehrere Abfrageserver

• Mehrere Server mit Dienste für Excel-Berechnungen

Der Indexserver ist in diesem Szenario eine einzelne Fehlerquelle. Sie können entweder den Suchdienst sichern und wiederherstellen, oder falls die Gleichzeitigkeit der Suche bei der Wiederherstellung wichtig ist, eine Failover-SSP-Serverfarm verwenden. Weitere Informationen finden Sie unter Verfügbarkeit der Suche nach einem Failover.

Ausgedehnte Serverfarm

Redundanz und Failover zwischen Rechenzentren mit mehreren Serverfarmen

Sie können eine Failoverserverfarm einrichten, um die Verfügbarkeit in einem von der primären Serverfarm getrennten Rechenzentrum zu ermöglichen. Eine Umgebung mit einer separaten Failoverserverfarm weist die folgenden Merkmale auf:

• Eine separate Konfigurationsdatenbank und Inhaltsdatenbank der Zentraladministration müssen in der Failoverserverfarm verwaltet werden.

  Tipp

  Wenn Sie die alternative Zugriffszuordnung für die primäre Serverfarm konfiguriert haben, muss die Failoverserverfarm unbedingt identisch konfiguriert werden.

• Alle Anpassungen müssen in beiden Serverfarmen bereitgestellt werden.

• Patches müssen auf beide Serverfarmen einzeln angewendet werden.

• Nur Inhaltsdatenbanken können erfolgreich asynchron gespiegelt werden oder per Protokollversand an die Failoverserverfarm gesendet werden.

• Für gespiegelte oder per Protokollversand gesendete Datenbanken muss das vollständige Wiederherstellungsmodell festgelegt werden.

• SSP-Datenbanken können in der Failoverserverfarm gesichert und wiederhergestellt werden.

Wenden Sie sich an den SAN-Hersteller, um festzustellen, ob Sie die SAN-Replikation oder einen anderen unterstützten Mechanismus zur Bereitstellung der Verfügbarkeit in Rechenzentren verwenden können.

Diese Topologie kann in vielen Rechenzentren wiederholt werden, wenn Sie den SQL Server-Protokollversand für zusätzliche Rechenzentren konfigurieren.

Primäre Serverfarmen und Failoverserverfarmen vor dem Failover

In der folgenden Tabelle werden die Server und Serverrollen in einer Umgebung mit SharePoint-Produkten und -Technologien sowie die jeweils zwischen Serverfarmen verfügbaren grundlegenden Redundanzstrategien beschrieben.

Server oder Serverrolle	Bevorzugte grundlegende Redundanzstrategie zwischen Serverfarmen
SQL Server	Asynchrone SQL Server-Datenbankspiegelung, SQL Server-Protokollversand oder anderer asynchroner Replikationsmechanismus. Hinweis: Kann nicht für die SSP-Datenbanken verwendet werden, die Suchinformationen hosten.
Front-End-Webserver	Bereitstellen in beiden Serverfarmen, einschließlich Anpassungen.
Webserver für mittelgroße Serverfarmen (Webanwendung und Suchabfragedienste)	Bereitstellen in beiden Serverfarmen.
Suchindizierung	Bereitstellen in beiden Serverfarmen. Wiederherstellen von ursprünglicher Serverfarm für das Verschieben zur Failoverserverfarm.
Excel-Berechnung	Bereitstellen in beiden Serverfarmen. Wenn die Suche nicht von SSP gehostet wird, kann die asynchrone Datenbankspiegelung, der SQL Server-Protokollversand oder ein anderer asynchroner Replikationsmechanismus zum Verschieben von Daten zur Failoverserverfarm verwendet werden. Wenn auch der Suchdienst von SSP gehostet wird, muss die Sicherung von der ursprünglichen Serverfarm wiederhergestellt werden.
Project-Anwendung	Bereitstellen in beiden Serverfarmen. Wiederherstellen von ursprünglicher Serverfarm für das Verschieben zur Failoverserverfarm.

Asynchrone Replikation und Suche

Die Suche erfordert die vollständige Synchronisierung zwischen der Suchdatenbank, der SSP-Datenbank und dem Index. Deswegen kann die Suche nicht mithilfe eines asynchronen Replikationsmechanismus (asynchrone Datenbankspiegelung, Protokollversand oder asynchrone SAN-Replikation) zwischen Serverfarmen repliziert werden. Für die Suche in einer Failoverserverfarm muss der Such-SSP wiederhergestellt werden.

Verfügbarkeit der Suche nach einem Failover

Die Indexserverrolle kann innerhalb einer Serverfarm nicht redundant sein. Die Anforderungen des Unternehmens im Hinblick auf die Gleichzeitigkeit der Suche nach einem Failover können die logische Architektur der Lösung bestimmen.

• Wenn die unmittelbare Gleichzeitigkeit und Verfügbarkeit der Suche nach einem Failover für das Unternehmen nicht erforderlich sind, kann der Such-SSP für die Failoverwebsite gesichert und wiederhergestellt werden.

• Wenn das Unternehmen eine schnelle Gleichzeitigkeit und Verfügbarkeit der Suche erfordert, können Sie eine der folgenden Architekturen verwenden:

• Eine Architektur mit einer einzelnen Serverfarm und zwei identischen SSPs.

• Eine zentrale übergeordnete Serverfarm, von der die Suche und andere SSPs gehostet werden. Der Suchdienst in der zentralen Serverfarm führt einen Crawl der Inhalte aller anderen Serverfarmen aus. Mit dieser Architektur kann mindestens eine Serverfarm unterstützt werden.

Einzelne Serverfarm mit zwei SSPs

Die folgende Architektur schützt vor dem Ausfall eines Indexservers. In dieser Topologie crawlen beide SSPs denselben Inhalt und verwenden dabei die gleichen Regeln. Der Failover-SSP wird nur mit der primären Website verbunden, wenn ein Failover auftritt.

Einzelne Serverfarm mit zwei Anbietern für gemeinsame Dienste (SSPs)

Diese Topologie weist die folgenden Nachteile auf:

• Benötigt den doppelten Speicherplatz für Indizes auf jedem Abfrageserver

• Erfordert die manuelle Umstellung einer Webanwendung auf die Verwendung des Failover-SSP (hierfür kann ein Skript erstellt werden).

• Reduziert die Größe des Korpus, den Sie crawlen können, um die Hälfte.

• Wenn Profile aktiviert sind, werden die Profile auf den Failover-SSPs standardmäßig nicht mit den Profilen auf den primären SSPs synchronisiert. Stattdessen weisen sie den Status zu dem Zeitpunkt auf, als sie ursprünglich importiert wurden. Um die Profile auf allen SSPs synchron zu halten, müssen Sie das User Profile Replication Engine (Modul zur Replikation von Benutzerprofilen) verwenden, das im 32-Bit-SharePoint Administration Toolkit (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x407) bzw. im 64-Bit-SharePoint Administration Toolkit (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x407) (in englischer Sprache) enthalten ist. Weitere Informationen finden Sie unter User Profile Replication Engine (Office SharePoint Server).

Die Möglichkeit, große Datasets in einem angemessenen Zeitraum zu crawlen, wird durch mehrere Faktoren beeinflusst, einschließlich Latenz und Bandbreite zwischen Indexservern und Webservern.

In einer Umgebung mit begrenzter Bandbreite kann mit dieser Topologie die Leistung erheblich beeinträchtigt werden. Das zweimalige Crawlen von Inhalt bedeutet zusätzliche Belastung für die gecrawlten Inhaltsrepositorys. Dadurch kann die Leistung des Repositorys beeinträchtigt werden. Außerdem kann sich dies negativ auf die Aktualisierung des Indexes durch die Suchfunktion auswirken.

Zentralisierte SSP-Serverfarmen

Bei der folgenden Architektur schützt die Verwendung einer übergeordneten SSP-Serverfarm vor dem Ausfall eines Indexservers. Diese Lösung scheint zwar viele Hardwareressourcen zu erfordern, aber separate SSP-Serverfarmen können bestimmte Hardware, wie einen gruppierten oder gespiegelten Datenbankserver, gemeinsam nutzen, vorausgesetzt die Indexserver befinden sich auf separaten Servern. Weitere Informationen zum Planen und Konfigurieren von SSP-Serverfarmen finden Sie unter Planen der SSP-Architektur.

Diese Topologie weist die folgenden Vorteile auf:

• Die SSP-Verwaltung ist zentralisiert.

• Der Ausfall einer Serverfarm erfordert kein erneutes Crawlen.

Zentralisierte SSP-Serverfarmen

Diese Topologie weist die folgenden Nachteile auf:

• Das Crawlen von Inhalten über ein WAN benötigt Bandbreite.

• Die Aktualisierung von Indizes in Umgebungen mit großen Datenmengen und hohen Änderungsraten kann schwierig sein.

• Die Abfrageleistung kann durch die Leistung von WAN-Verbindungen beeinträchtigt werden.

• Wenn Profile aktiviert sind, werden die Profile in der Failover-SSP-Farm standardmäßig nicht mit den Profilen auf dem primären SSP synchronisiert. Stattdessen weisen sie den Status zu dem Zeitpunkt auf, als sie ursprünglich importiert wurden. Um die Profile auf allen SSPs synchron zu halten, müssen Sie das User Profile Replication Engine (Modul zur Replikation von Benutzerprofilen) verwenden, das im 32-Bit-SharePoint Administration Toolkit (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x407) bzw. im 64-Bit-SharePoint Administration Toolkit (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x407) (in englischer Sprache) enthalten ist. Weitere Informationen finden Sie unter User Profile Replication Engine (Office SharePoint Server).

Zusammenfassung

Überprüfen Sie Ihre Verfügbarkeitsanforderungen sorgfältig. Je höher der Verfügbarkeitsgrad und je mehr Systeme geschützt werden, desto komplexer und kostspieliger ist vermutlich eine Verfügbarkeitslösung.

Die Kosten für die Verfügbarkeit sollten basierend auf Ihren Unternehmensanforderungen bewertet werden, denn nicht für alle Lösungen in einem Unternehmen ist in der Regel derselbe Verfügbarkeitsgrad erforderlich. Sie können unterschiedliche Verfügbarkeitsgrade für verschiedene Websites und Dienste (z. B. Suche und Business Intelligence) oder für verschiedene Serverfarmen anbieten.

Danksagung

Das Inhaltsveröffentlichungsteam für Microsoft Office SharePoint Server möchte sich bei den folgenden technischen Redakteuren für diesen Artikel bedanken:

• Bill Baer, Microsoft Online Services, Hosted SharePoint, Technology Architect

• James Petrosky, Microsoft Consulting Services, Senior Consultant

• Steve Peschka, Microsoft Consulting Services, IW Senior Architect

• Dan Winter, Microsoft Customer Support Services, Escalation Engineer

• Sean Livingston, Microsoft SharePoint-Produkte und -Technologien, Program Manager

• Mike Watson, Technology Architect

• Todd Carter, Microsoft Premier Field Engineering, Principal Premier Field Engineer

• Mike Plumley, Microsoft Office Project Server, Writer

• Christophe Fiessinger, Microsoft Office Project, Senior Technical Product Manager

• Sid Shah, Microsoft Search, Program Manager

• Luca Bandinelli, Microsoft SharePoint-Produkte und -Technologien, Program Manager