Freigeben über

Planen der Verfügbarkeit (Windows SharePoint Services)

  • Artikel

Dieser Artikel beschreibt die Verfügbarkeit im Allgemeinen, Kosten und Herausforderungen im Hinblick auf die Verfügbarkeit in einer Umgebung mit SharePoint-Produkte und -Technologien sowie Strategien und Lösungen, die Sie in der Umgebung verwenden können. Sie sollten diesen Artikel lesen, wenn in Ihrer Serverfarm Windows SharePoint Services 3.0 ausgeführt wird oder wenn es sich um eine hochverfügbare Umgebung mit Microsoft Office SharePoint Server 2007, Microsoft Office Forms Server 2007 oder Microsoft Search Server 2008 handelt. Sie können das Office SharePoint Server 2007-Verfügbarkeitsmodell, das diesen Artikel begleitet, herunterladen und drucken (https://go.microsoft.com/fwlink/?linkid=122369&clcid=0x407 (in englischer Sprache)). Es enthält eine Zusammenfassung dieses Inhalts im Posterformat.

Hinweis

Einige Inhalte dieses Artikels beziehen sich auf Features, die nur in Microsoft Office SharePoint Server 2007 verfügbar sind. Diese Inhalte sind enthalten, da davon ausgegangen wird, dass Sie möglicherweise eine Umgebung verwalten, die sowohl Windows SharePoint Services 3.0 als auch Microsoft Office SharePoint Server 2007 enthält.

Was versteht man unter Verfügbarkeit?

Die Verfügbarkeit gibt an, zu welchem Grad eine Umgebung mit SharePoint-Produkte 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 rechtzeitig geeignete Gegenmaßnahmen ergriffen werden, falls doch solche Vorfälle vorkommen. Verfügbarkeitsstrategien minimieren geplante und ungeplante Downtime für den Benutzer.

Eine der bekanntesten Verfügbarkeitsmaßnahmen ist die prozentuale Betriebszeit, angegeben als Anzahl der Neunen. Hiermit wird die prozentuale Aktivität und Funktionsfähigkeit eines gegebenen Systems bezeichnet. 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.

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

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

Darüber hinaus versteht man unter Verfügbarkeit nicht Business Continuation Management (BCM). BCM 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-Produkte und -Technologien können Teil Ihres technischen BCM-Plans. 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.

Hinweis

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

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

Eine Bereitstellung von SharePoint-Produkte 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 des Suchdiensts nach einem Failover beschriebenen Techniken den Zeitaufwand zum Wiederherstellen der Suche reduzieren.

  • Die SQL Server-Spiegelung wird von SharePoint-Produkte 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-Produkte und -Technologien

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

Komponentenfehlertoleranz

Für jedes System wird empfohlen, zusammen mit Hardwareherstellern nach fehlertoleranter Hardware 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 eventuell 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

Verfügbarkeit einer einzelnen Farm

In der folgenden Tabelle werden die Server und Serverrollen in einer Umgebung mit SharePoint-Produkte 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

Clustering oder synchrone Spiegelung. Das Clustering ist einfacher zu implementieren, aber möglicherweise teurer.

Weitere Informationen zur Verwendung der synchronen Spiegelung finden Sie unter White paper: Using database mirroring.

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 des Suchdiensts nach einem Failover.

Excel-Berechnung

Bereitstellen auf mehreren Servern.

Project-Anwendung

Bereitstellen auf mehreren Servern.

Weitere Informationen finden Sie unter Planen der Redundanz (Windows SharePoint Services).

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 von SharePoint-Produkte und -Technologien nahtlos und automatisch erfolgt.

Erfordert Scripting für das Failover von SharePoint-Produkte 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 White paper: Case Study of High Availability for SharePoint using Database Mirroring.

  • 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 des Suchdiensts nach einem Failover.

Ausgedehnte Serverfarm

'Gestreckte' Farm

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.

    Hinweis

    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.

Hinweis

Die SQL Server-Spiegelung kann nur mit einem Spiegelserver verwendet werden. Der Protokollversand ist aber an mehrere sekundäre Servern möglich.

Primäre Serverfarmen und Failoverserverfarmen vor dem Failover

Primäre Farm und Failoverfarm vor dem Failover

In der folgenden Tabelle werden die Server und Serverrollen in einer Umgebung mit SharePoint-Produkte 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.

Hinweis

Wenn Sie SSP ohne Suche oder Projekt ausführen, kann ein asynchroner Replikationsmechanismus zum Verschieben der Daten verwendet 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 der Suche und die Verfügbarkeit 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 der Suche und Verfügbarkeit 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 auf der zentralen Serverfarm führt einen Crawl der Inhalte aller anderen Serverfarmen aus. Mit dieser Architektur kann mindestens eine Serverfarm unterstützt werden.

Wichtig

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 zur Verfügung, das zum Lieferumfang von 32-bit SharePoint Administration Toolkit (in englischer Sprache) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x407) oder von 64-bit SharePoint Administration Toolkit (in englischer Sprache) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x407) gehört. Weitere Informationen finden Sie unter User Profile Replication Engine (Office SharePoint Server).

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)

Farm mit zwei Anbietern für gemeinsame Dienste

Diese Topologie weist die folgenden Nachteile auf:

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 ein Inhaltsrepository, das gecrawlt wird. 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 Plan SSP architecture.

Diese Topologie weist die folgenden Vorteile auf:

  • Die SSP-Verwaltung ist zentralisiert.

  • Der Ausfall einer Serverfarm erfordert kein erneutes Crawlen.

Zentralisierte SSP-Serverfarmen

SSP-Failoverfarmen

Diese Topologie weist die folgenden Nachteile auf:

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