(0) exportieren Drucken
Alle erweitern

Erstellen einer Hochverfügbarkeitsarchitektur und -strategie für SharePoint 2013

 

Gilt für: SharePoint Server 2013, SharePoint Foundation 2013

Letztes Änderungsdatum des Themas: 2013-12-18

Zusammenfassung: Erfahren Sie, wie Sie Farmarchitektur und -technologie kombinieren können, um in einer einzelnen SharePoint 2013-Farm eine Hochverfügbarkeitsumgebung zu erstellen.

Eine Hochverfügbarkeitsstrategie stellt eine wichtige Anforderung für eine SharePoint 2013-Produktionsumgebung dar. Eine End-to-End-Strategie umfasst Betriebsprozesse, Plattformsteuerung, Architektur sowie technische Lösungen. Dieser Artikel befasst sich mit den Architektur- und Technikaspekten der Hochverfügbarkeit. In dieser Anleitung werden spezifische SharePoint-Designelemente sowie die technischen Optionen erläutert, anhand derer Ihre Strategie für die Hochverfügbarkeit festgelegt ist.

HinweisHinweis:
Hochverfügbarkeit und Notfallwiederherstellung sind nicht das Gleiche. Obwohl es eine Überschneidung bei der Planung und den Lösungen gibt, handelt es sich bei beiden um Teilbereiche der Geschäftskontinuität. Der Zweck der Hochverfügbarkeit besteht darin, Stabilität im primären Rechenzentrum und eine geplante Ausfallzeit zu erreichen. Der Zweck der Notfallwiederherstellung besteht darin, dass eine Organisation in einem sekundären Rechenzentrum den Computerbetrieb fortsetzen kann, wenn die Infrastruktur im primären Rechenzentrum aufgrund eines Notfalls nicht mehr verwendet werden kann. Informationen zur Notfallwiederherstellung für SharePoint 2013 finden Sie im Abschnitt Wählen einer Notfallwiederherstellungsstrategie für SharePoint 2013.

Inhalt dieses Artikels:

Die hohe Verfügbarkeit wird normalerweise verwendet, um die Fähigkeit eines Systems zu beschreiben, den Betrieb fortzusetzen und Ressourcen für die Systembenutzer bereitzustellen, wenn ein Problem in mindestens einer der folgenden Kategorien in einer fehlerhaften Domäne auftritt: Hardware, Software oder Anwendung. Der Grad der Verfügbarkeit wird als Prozentwert der Zeit angegeben, die ein System kontinuierlich betriebsbereit ist, um die Geschäftsfunktionen zu unterstützen. Der erforderliche Grad der Verfügbarkeit variiert je nach Organisation. Diese Anforderung kann auch innerhalb von Geschäftseinheiten variieren – die Vereinbarung zum Servicelevel wird jedoch für die Organisation als Ganzes getroffen. Aus Sicht der Benutzer ist eine UNRESOLVED_TOKEN_VAL(SharePointAll_1st_NoVer)-Farm verfügbar, wenn Benutzer auf die Farm zugreifen und die Features und Dienste nutzen können, die sie zur Ausführung ihrer Tätigkeit benötigen.

Eine hochverfügbare SharePoint-Farm zeichnet sich durch die folgenden Ziele und Merkmale aus:

  • Das Farmdesign reduziert potenzielle Fehlerquellen. Da es kaum möglich ist, alle Fehlerquellen zu beseitigen, muss die Gesamtstrategie auf die Behandlung eines Fehlereignisses ausgerichtet sein.

  • Failoverereignisse erfolgen nahtlos und haben nur minimale Auswirkungen auf die Benutzeraktivitäten.

  • Die Farm wird weiterhin ausgeführt, wenn auch mit reduzierter Kapazität. Es gibt jedoch keinen vollständigen Ausfall.

  • Die Farm zeichnet sich durch Ausfallsicherheit aus. Vorgänge, die sich auf den Dienst auswirken, treten nur selten auf, und beim Eintreten solcher Vorgänge werden zeitnah effektive Maßnahmen ergriffen.

Bevor Sie eine realistische und wirtschaftliche Hochverfügbarkeitsarchitektur und -strategie für Ihre SharePoint-Umgebung erstellen können, müssen Sie Ihre Verfügbarkeitsziele definieren und quantifizieren. Diese Ziele spiegeln das Maß wider, in dem Ihre Organisation von SharePoint 2013 abhängt und wie sich ein Ausfall des Diensts auf den Betrieb der Organisation auswirken würde. Die Auswirkungen eines Dienstverlusts sind abhängig von der Art des Verlusts (vollständiger oder teilweiser Verlust) sowie der Dauer des Verlusts.

Verlorene Umsätze werden häufig als zentrales Ergebnis eines reduzierten Diensts oder eines vollständigen Dienstausfalls angeführt, insbesondere für Unternehmen, die ihre Geschäfte online ausführen. Andere, weniger offensichtliche Konsequenzen können jedoch gleichermaßen verheerend für ein Unternehmen sein. So kann ein Unternehmen beispielsweise das Vertrauen seiner Partner, Lieferanten oder Kunden verlieren, der Respekt gegenüber einer Unternehmensmarke kann sinken oder das Unternehmen ist von rechtlichen Problemen betroffen.

Eine erfolgreiche Hochverfügbarkeitsstrategie muss die spezifischen Anforderungen Ihrer Organisation widerspiegeln. Darüber hinaus muss Sie eine optimale Balance zwischen den Unternehmensanforderungen, IT-Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) und der Verfügbarkeit der technischen Lösungen, IT-Supportmöglichkeiten und Infrastrukturkosten darstellen.

Nachdem Sie die Verfügbarkeitsanforderungen für Ihre Organisation ermittelt haben, können Sie mit der Erstellung eines Hochverfügbarkeitsdesigns und einer Strategie zur Reduzierung des Ausfallrisikos und eines reduzierten Betriebs beginnen. IT-Fachleute, die hoch verfügbare Systeme entwickeln und bereitstellen, vertrauen bei der Umsetzung ihrer Ziele auf die folgenden Leitprinzipien:

  • Einzelne Fehlerquellen für jede fehlerhafte Domäne und das gesamte System auf jeder möglichen Ebene beheben (Betriebssystem, Software und SharePoint-Anwendung).

    HinweisHinweis:
    Eine fehlerhafte Domäne stellt den Bereich und die Beschränkung einer physischen Fehlerquelle dar. In der Märzausgabe 2011 des "IEEE Computer Magazine" findet sich die folgende Definition: "Eine fehlerhafte Domäne ist eine Gruppe von Hardwarekomponenten (Computer, Switches usw.), die eine gemeinsame Fehlerquelle haben."
    Weitere Informationen zu fehlerhaften Domänen und Upgrade-Domänen finden Sie im Abschnitt Windows Azure Fault Domain and Upgrade Domain Explained for IT Pros (Windows Azure – Fehlerhafte Domäne und Upgrade-Domäne für IT-Fachleute erklärt, nur in englischer Sprache verfügbar).
  • Eine sehr schnelle Fehlererkennung, -isolation und -behebung implementieren.

HinweisHinweis:
Bei einem SLA handelt es sich um eine Vereinbarung zwischen IT-Dienstanbietern (eine interne IT-Gruppe oder ein externer Anbieter) und Kundenvertretern. In einem SLA werden die erforderlichen Dienste festgelegt und quantifiziert. Darüber hinaus enthält das SLA Informationen zum Umfang des durch den Dienstanbieter bereitgestellten Supports. SLAs sind klar, spezifisch und präzise formuliert, um Missverständnisse hinsichtlich der Erwartungen von Seiten der Anbieter und der Benutzer zu vermeiden. Klarheit und Präzision sind wichtig, da SLAs typischerweise signifikante finanzielle Strafen definieren, falls externe Dienstanbieter (Drittanbieter) beauftragt werden müssen.

Hochverfügbarkeit und Fehlertoleranz sind nicht das Gleiche. Eine Definition der Hochverfügbarkeit ist wichtig, da der Begriff "Fehlertoleranz" häufig synonym verwendet wird, um zu beschreiben, wie Hochverfügbarkeit implementiert wird.

Hochverfügbarkeitslösungen sind breit angelegt und stellen eine Reihe systemweiter gemeinsam verwendbarer Ressourcen zur Verfügung, die integriert werden, um vordefinierte erforderliche Dienste bereitzustellen. Die Lösung nutzt verschiedene Kombinationen von Branchenstandardhardware und -software, um die Ausfallzeit zu minimieren und die Dienste wiederherzustellen, wenn das System oder Teile des Systems ausfallen.

Eine fehlertolerante Lösung ist hardwarebezogen und verwendet spezielle Hardware, um Fehler zu erkennen und umgehend auf eine redundante Hardwarekomponente umzuschalten. Bei dieser Komponente kann es sich um einen Prozessor, eine Speicherplatine, ein Netzteil, E/A-Subsystem oder Speichersubsystem handeln. Der Wechsel auf eine redundante Komponente gewährleistet eine hohe Dienstqualität.

Mit einer Kosten-Nutzen-Analyse für fehlertolerante Lösungen und Hochverfügbarkeitslösungen können Organisationen eine wirksame Strategie entwickeln, um die Verfügbarkeitsziele ihrer SharePoint-Farm zu erreichen. Normalerweise liegen für diese beiden Lösungen Kostenkompromisse vor. Weitere Informationen hierzu finden Sie unter Hohe Verfügbarkeit und Ausfallsicherheit von Standorten.

Die Verfügbarkeit wird im Verhältnis zur vollständigen Betriebsbereitschaft (100 %) bzw. Ausfallsicherheit in einer bestimmten Zeit gemessen. Eine der wichtigsten allgemeinen Messgrößen für die Verfügbarkeit ist die Anzahl der Neunen, die von einer einzelnen Neun (90 %) bis zu fünf Neunen (99,999 %), also der höchstmöglichen Verfügbarkeit, reicht. Der Messwert Anzahl der Neunen bezeichnet den Prozentsatz der Betriebszeit, in der ein System ausgeführt wird, funktionstüchtig ist und den Benutzern zur Verfügung steht.

HinweisHinweis:
Als Synonym zu "Verfügbarkeit" wird häufig auch der Begriff Uptime verwendet. Dies ist jedoch irreführend, da ein Computersystem auch ausgeführt werden kann und dabei dennoch nicht in der Lage ist, die von den Benutzern benötigten Dienste und Funktionen bereitzustellen.

Der Prozentsatz der Verfügbarkeit wird mithilfe der folgenden Formel berechnet: x = (n - j) * 100/n.

  • x ist der Prozentsatz

  • n ist die Gesamtzahl der Minuten in einem bestimmten Kalendermonat (30 Tage)

  • j ist die Gesamtzahl an Minuten, die ein System oder Dienst nicht verfügbar ist

Wie in der folgenden Tabelle veranschaulicht, in der das Verhältnis zwischen Prozentsatz der Verfügbarkeit und Kalenderzeitwerten dargestellt ist, ist der Verfügbarkeitswert von fünf Neunen nur schwer zu erreichen. Zudem ist diese Verfügbarkeitsstufe kostenintensiv, komplex und kann in Einzelfällen Risiken bergen. Für ausführlichere Informationen zu den fünf Neunen empfehlen wir Ihnen die Blogbeiträge von Vijay Gill, How many Nines? und Sean Hull, The myth of five nines - Why high availability is overrated.

HinweisHinweis:
Eine Verfügbarkeit von drei Neunen ist für die meisten Unternehmen Norm, die SharePoint-Farmen in ihren Rechenzentren betreiben. Diese Verfügbarkeitsstufe ist auch für eine SharePoint-Farm typisch, die in einer gehosteten Umgebung oder in der Cloud bereitgestellt wird.

Korrelation von Prozentsatz (%) der Verfügbarkeit zu Kalender-Downtime

Akzeptabler Prozentsatz der Betriebszeit Downtime pro Tag Downtime pro Monat Downtime pro Jahr

90 (eine Neun)

144,00 Minuten

72 Stunden

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

Obwohl dies nicht Bestandteil dieses Artikels ist, sollten sich einige der folgenden Aspekte eines SLAs in einem Hochverfügbarkeitsdesign widerspiegeln.

Definition und Bereich der Verfügbarkeit

Es ist nicht möglich, eine Verfügbarkeitsumgebung zu erstellen oder ein SLA zu vereinbaren, wenn Sie die Verfügbarkeit nicht definieren. Es muss sich um einen Messwert hinsichtlich der Fähigkeit der Benutzer handeln, die normalen Aufgaben auszuführen, die sie für ihre Tätigkeit benötigen, und die Funktionen und Dienste zu nutzen, die in UNRESOLVED_TOKEN_VAL(SharePointAll_1st_NoVer) bereitstehen. SharePoint-Verarbeitungslasten, die ein Unternehmen nutzt, bestimmen diese Definition und den Umfang der Verfügbarkeit. Verarbeitungslastanforderungen können je nach Kunden variieren und basieren auf spezifischen Anforderungen der einzelnen Unternehmen, den Funktionen, die die Farm bereitstellt, und dem Profil der Benutzer der Farm.

Ausnahmen für die Verfügbarkeitsberechnungen

Ausschlüsse für die Verfügbarkeit sind nicht nur für die Planung der Verfügbarkeit, sondern auch für das SLA wichtig. Für jedes System fallen routinemäßige Wartungsaufgaben an. Geplante Ausfallzeiten oder reduzierte Servicelevel sind nicht Bestandteil der Verfügbarkeitsberechnungen. Typische Ausschlüsse sind geplante Wartungszeiten sowie geplante Ausfallzeiten für Aktivitäten wie Quarantänemaßnahmen für einen Virus oder das Reagieren auf Sicherheitsbedrohungen.

Ausfallzeitenmetriken

In der oben angeführten Tabelle "Korrelation von Prozentsatz (%) der Verfügbarkeit zu Kalender-Downtime" wird die Ausfallzeit für die einzelnen Prozentsätze der Betriebszeit angegeben. Die folgenden Werte werden zur Berechnung der Verfügbarkeit verwendet:

  • Mean Time Between Failures (MTBF, die mittlere ausfallfreie Betriebszeit) – Die erwartete Zeit zwischen zwei aufeinanderfolgenden Ausfällen für ein reparierbares System.

  • Mean Time To Failure (MTTF, die mittlere Zeit bis zum Ausfall) – Die erwartete Zeit bis zum Ausfall eines Systems, das nicht repariert werden kann.

  • Mean Time To Repair or Replace (MTTR, die mittlere Zeit bis zur Wiederherstellung) – Die erwartete Zeit, um eine fehlerhafte Komponente zu reparieren oder auszutauschen.

Mit der folgenden Formel lässt sich die Verfügbarkeit berechnen: Verfügbarkeit = MTTF / (MTTF + MTTR). Sie können anhand dieser Formel die Gesamtverfügbarkeit berechnen und diese durch die Nutzung zuverlässigerer Hardware- und Softwarekomponenten verbessern und damit den MTTF-Wert steigern und den MTTR-Wert minimieren.

Beziehung zwischen Leistung und Verfügbarkeit

Die Leistung kann nicht von der Verfügbarkeit isoliert betrachtet werden. Dienstanbieter und Verbraucher definieren quantifizierbare Leistungsbenchmarks für Servicelevel, wenn ein System unter normalen Bedingungen ausgeführt wird. Es tritt jedoch eine reduzierte Verfügbarkeit auf, wenn die Leistung durch ein außergewöhnliches Ereignis erheblich beeinträchtigt wird, sodass das System im Grunde nicht mehr verwendbar ist – die Farm also per Definition nicht verfügbar ist. Nachfolgend finden Sie typische Beispiele solcher außergewöhnlichen Ereignisse:

  • Denial-of-Service-Angriffe auf für die Öffentlichkeit zugängliche Webserver

  • Schlecht formulierte Abfragen, die Datenbankserverressourcen verbrauchen, oder Datenbanktransaktionen, die Tabellen sperren

  • Fernnetzfehler (Wide-area network, WAN) oder hohe Wartezeiten im Netzwerk, die auf Ereignisse an anderen Standorten zurückzuführen sind

Da immer mehr Unternehmen auf geografisch verteilte SharePoint-Farmen oder gehostete Umgebungen umstellen, ist die Netzwerklatenz bei der Verfügbarkeitsplanung extrem wichtig.

Ein Prozess, der eine hohe Verfügbarkeit implementiert, ist eine der kostspieligeren Investitionen in Bezug auf eine SharePoint-Farm. Mit der zunehmenden Verfügbarkeit und der Anzahl der Systeme, für die die hohe Verfügbarkeit gewährleistet werden soll, steigen auch die Komplexität und die Kosten einer Verfügbarkeitslösung. Wenn Sie in die hohe Verfügbarkeit investieren möchten, fallen unter anderem folgende Kosten an:

  • Zusätzliche Infrastrukturkomponenten wie Netzwerkadapter, Switches und Stromversorgung für die Redundanz.

  • Zusätzliche Hardware und Software oder Softwarelizenzen zur Unterstützung der unterschiedlichen Farmrollen, die übergreifend über die Farmarchitektur für Redundanz bei der Arbeitsauslastung sorgen.

  • Ersatzhardware zum Austauschen fehlerhafter Komponenten.

    Obwohl es übliche Praxis ist, Ersatzcomputer in unterschiedlichen Bereitschaftsstadien zur Verwendung bei Routinewartungsaufgaben oder zum Austausch für einen fehlerhaften Server vorzubereiten, müssen Sie in Hardware investieren, die sich in "Leerlaufstellung" befindet.

    HinweisHinweis:
    Durch die Vorteile in der Virtualisierungstechnologie können Unternehmen virtuelle Computer als Hot-Spare-, Warm-Spare- oder Cold-Spare-Computer nutzen. Virtuelle Computer können möglicherweise dieselbe Funktionalität liefern. Die Virtualisierung ermöglicht dabei Flexibilität und Kosteneffizienz. Sie müssen jedoch immer sicherstellen, dass ein virtueller Computer die entsprechende Kapazität aufweist, um die Last des physischen Computers zu verarbeiten, der ersetzt werden soll.
  • Erhöhte Wartungs- und Supportkosten, die proportional zur Verfügbarkeitsstufe und den Lösungen ist, die zum Erreichen der Verfügbarkeitsanforderungen eingesetzt werden.

  • Antizipierte Änderungen an der Farm, z. B. horizontale Skalierung. Bei einer horizontalen Skalierung einer Farm muss die Verfügbarkeitslösung alle Änderungen an der Farmtopologie widerspiegeln können. Es fallen mit großer Wahrscheinlichkeit höhere Kosten an.

  • Ein zuverlässiges Erkennungs- und Warnsystem, das eine schnelle Fehlererkennung gewährleistet. Dieses System kann vorhandene Fehlererkennungstools verwenden und Systemüberwachungs- und Warntools wie System Center Operations Manager umfassen.

  • Integrations- der Anpassungskosten, die für die Implementierung der Hochverfügbarkeit für die Farm selbst anfallen bzw. um weitreichendere Rechenzentrumsanforderungen zu erfüllen.

Die Kosten für die Verbesserung der Verfügbarkeit sollten in Verbindung mit den geschäftlichen Kernanforderungen Ihres Unternehmens bewertet werden. In vielen Fällen benötigen die einzelnen Unternehmenseinheiten nicht alle das gleiche Maß an Verfügbarkeit. Sie können für verschiedene Websites, verschiedene Dienste oder verschiedene Farmen unterschiedliche Verfügbarkeitsstufen anbieten.

Gemäß den Angaben in der Tabelle "Korrelation von Prozentsatz (%) der Verfügbarkeit zu Kalender-Downtime" bedeutet eine Verfügbarkeit von fünf Neunen, dass für ein System im Laufe eines Jahres nur eine Ausfallzeit von 5,26 Minuten vorliegt! Obwohl es möglich ist, ein solches Maß an Verfügbarkeit zu erreichen, sind die dabei entstehenden Kosten für einen Großteil der Unternehmen untragbar. Eine zentrale Entscheidung besteht also darin, den Punkt zu ermitteln, an dem eine Investition in eine weitere Neun bei der Verfügbarkeit keinen Kostenvorteil im Hinblick auf die Auswirkungen eines Ausfalls mehr darstellt.

In der folgenden Abbildung wird gezeigt, wie Sie die verschiedenen Teile einer SharePoint-Umgebung verteilen und konfigurieren können, um die Verfügbarkeit innerhalb einer Farm zu erhöhen. Dieses Beispiel zeigt auch, wie Redundanz zur Behandlung von fehlerhaften Domänen genutzt werden kann.

HinweisHinweis:
Das hier gezeigte Beispiel ist nicht vollständig. Es werden z. B. nicht alle fehlerhaften Domänen und sämtliche fehlertolerante Hardware gezeigt.

Beispiele für Redundanz in einer Farmtopologie zur Behandlung von Fehlerquellen

Ein Beispiel, das zeigt, wie einzelne Fehlerquellen in einer Farm durch Einsatz redundanter Rollen und Dienste vermeiden werden.

In Bezug auf die Topologie in der vorherigen Abbildung ist Folgendes zu beachten:

  • Die Farmserver in diesem Beispiel können physische Computer oder virtuelle Computer sein, die auf Hyper-V-Host-Servern bereitgestellt werden. Das Prinzip der Identifizierung und Reaktion auf Fehlerquellen betrifft beide Arten von Umgebungen.

  • Vier Server (W1-W4) sind dafür vorgesehen, Inhalte bereitzustellen. Diese Redundanz erhöht die Verfügbarkeit, wenn auf einem oder mehreren Servern ein Fehler auftritt. Diese Redundanzstufe ermöglicht es darüber hinaus, dass die Farm ihren Betrieb fortsetzen kann, wenn Softwareupdates angewendet werden.

  • Vier Anwendungsserver (A1-A4) erhöhen die Verfügbarkeit für Farmdienste und spezifische Anwendungskomponenten wie die Suche. Suchrollen und Komponenten sind redundant. Weitere Informationen über die Suchverfügbarkeit finden Sie unter Skalieren der Suchfunktion für Internetwebsites in SharePoint Server 2013.

  • Die Datenbankserver der Farm sind redundant, und durch die Verwendung von Datenbankspiegelung oder Clustering kann eine Datenbank mit hoher Verfügbarkeit erreicht werden.

  • In einer virtuellen Umgebung werden die virtuellen Computer auf separaten Hyper-V-Hostservern platziert, um eine einzelne Fehlerquelle zu beseitigen. Dieser Ansatz zur Platzierung des virtuellen Computers entspricht den Best Practice-Richtlinien für die Verfügbarkeit und Leistung.

  • Der primäre Datenbankserver (mit 1 gekennzeichnet) und Rack 2 (mit 2 gekennzeichnet), das zwei der Hosts für virtuelle Maschinen enthält, werden als fehlerhafte Domänen identifiziert, um zu demonstrieren, wie die Farm und die Infrastruktur als eine Sammlung fehlerhafter Domänen betrachtet werden kann. Hier wird veranschaulicht, wie Sie eine eingehende Analyse Ihrer Umgebung vornehmen können, um eine Gesamtstrategie und eine Kosten-Nutzen-Analyse zu entwickeln.

Sonstige Farmrollen und -Dienste

Unser Beispiel enthält nicht alle Rollen, Dienste und Dienstanwendungen, die in einer bestimmten SharePoint-Farm ausgeführt werden könnten. Sie können in Bezug auf die hohe Verfügbarkeit keinen generischen Ansatz für alle in einer SharePoint-Farm vorhandenen Elemente verfolgen. Einige wichtige Ausschlüsse im Vergleich zur Verwendung eines Standardansatzes für hohe Verfügbarkeit sind folgende:

Nachdem Sie eine Architektur entworfen haben, die hochverfügbare Rollen und Workloads unterstützt, können Sie mithilfe fehlertoleranter Komponenten die Verfügbarkeit erhöhen. Fehlertolerante Lösungen sind innerhalb der gesamten Infrastruktur verfügbar, die die Datenbanken enthält.

Fehlertoleranz ist jederzeit für fast jede Hardwarekomponente in der Infrastruktur einer SharePoint-Farm verfügbar. Im Rahmen Ihres Hochverfügbarkeitsdesigns müssen Sie die Teile der Infrastruktur bestimmen, die aus operativer Sicht sowie aus Kostengründen fehlertolerant sein sollten. Auch wenn die Möglichkeit besteht, jede Komponente der Infrastruktur fehlertolerant zu machen, bedeutet dies nicht, dass dies auch sinnvoll ist.

Da die SharePoint-Plattform und ihre Anwendungs-Workloads von der Verfügbarkeit und Zuverlässigkeit aller SharePoint-Datenbanken abhängig sind, sind hochverfügbare Datenbanken ein äußerst wichtiger Aspekt Ihrer Hochverfügbarkeitsstrategie. Sie können die folgenden Funktionen, z. B. fehlertolerante Lösungen für UNRESOLVED_TOKEN_VAL(SharePointAll_2nd_NoVer)-Datenbankserver und Datenbanken verwenden:

  • SQL Server-Failoverclustering (AlwaysOn-Failoverclusterinstanzen) für SQL Server 2012)

  • SQL Server-Hochverfügbarkeits-Datenbankspiegelung

  • AlwaysOn-Verfügbarkeitsgruppen

WichtigWichtig:
SQL Server 2012 AlwaysOn ist nur für SQL Server Enterprise verfügbar.

Über AlwaysOn-Failoverclusterinstanzen und AlwaysOn-Verfügbarkeitsgruppen

Ein Failovercluster erfordert gemeinsamen Plattenspeicher zwischen zwei Computern. In einer Zwei-Knoten-Konfiguration sind die Computer als aktiv/passiv konfiguriert, sodass eine vollständig redundante Instanz des Primärknotens ermöglicht wird. Der passive Knoten wird im Fall eines Ausfalls des primären Knotens online gestellt. Die gemeinsam verwendete Festplatte wird jeweils nur für einen Computer zur Verfügung gestellt. Diese Konfiguration erfordert in der Regel den größten Teil an zusätzlicher Hardware. Unter SQL Server 2012 ist diese Art der Clusterkonfiguration eine AlwaysOn-Failoverclusterinstanz und stellt eine spezifische Möglichkeit dar, um SQL Server zu installieren. Aufgrund der Konfigurationsanforderungen kann nicht einfach eine Standardinstallation von SQL Server verwendet und diese in eine Failoverclusterinstanz geändert werden.

Eine AlwaysOn-Verfügbarkeitsgruppe ist eine andere Technologie in SQL Server 2012 (Sie können sich diese Technologie als untergeordnetes Objekt der Datenbankspiegelung vorstellen), die einige Features durch Windows-Clustering verfügbar macht. Allerdings ist hierfür kein gemeinsamer Festplattenspeicher erforderlich, und auf den Computern in einer Verfügbarkeitsgruppe muss keine spezielle Konfiguration von SQL Server installiert sein. Nachdem ein Datenbankserver zu einem Windows-Cluster hinzugefügt wird, ist es ziemlich einfach, AlwaysOn-Verfügbarkeitsgruppen zu aktivieren und dann die gewünschte Verfügbarkeitsgruppe zu konfigurieren.

Jeder Server, auf dem SQL Server 2012 Enterprise Edition ausgeführt wird, kann demnach AlwaysOn-Verfügbarkeitsgruppen verwenden, indem er einem Cluster beitritt und die Verfügbarkeitsgruppe konfiguriert wird. AlwaysOn-Failovercluster erfordern spezielle Hardware und Konfigurationsschritte zum Einrichten von Failoverclusterinstanzen. Jede dieser sich ebenbürtigen Technologien ist für eine Verwendung in bestimmten Umgebungen vorgesehen. Weitere Informationen zu diesen Features finden Sie unter Anleitung zu Microsoft SQL Server-AlwaysOn-Lösungen für hohe Verfügbarkeit und Notfallwiederherstellung.

WichtigWichtig:
Da jede Instanz von SQL Server mit Hochverfügbarkeitsoption eigene Merkmale, Stärken und Schwächen aufweist, ist eine Option nicht unbedingt besser als die jeweils andere. So ist beispielsweise in einem bestimmten Szenario mit AlwaysOn-Verfügbarkeitsgruppen die Minimierung des Datenverlusts wichtiger als eine Leistungssteigerung, die mit AlwaysOn-Failoverclusterinstanzen erreicht werden könnte. Sie müssen sich für eine Hochverfügbarkeitslösung entscheiden, die Ihren geschäftlichen Anforderungen und den Anforderungen an die IT-Infrastruktur entspricht.

Einen entscheidenden Faktor bei der Auswahl der zu verwendenden SQL Server-Option stellen die SharePoint-Datenbanken dar. Sie müssen die Eigenschaften der SharePoint 2013-Datenbanken verstehen. Jede Datenbank kann spezielle Anforderungen oder Einschränkungen aufweisen, anhand derer die fehlertolerante SQL Server-Lösung bestimmt wird, die für Ihre Produktionsumgebung geeignet ist und vollständig unterstützt wird. Wir empfehlen Ihnen, die folgenden Artikel zu lesen:

Failoverclustering bietet Verfügbarkeit für eine Instanz von SQL Server unter SQL Server 2008 R2 mit Service Pack 1 (SP1) oder SQL Server 2012.

HinweisHinweis:
SQL Server-Failoverclustering wird unter SQL Server 2012 in AlwaysOn-Failovercusterinstanzen umbenannt. Der Einfachheit halber gilt der Begriff "Failoverclustering" entweder für SQL Server-Failoverclustering unter SQL Server 2008 R2 mit Service Pack 1 (SP1) oder für AlwaysOn-Failoverclusterinstanzen unter SQL Server 2012.

Ein Failovercluster ist eine Kombination von einem oder mehreren Knoten oder Servern und zwei oder mehr gemeinsam verwendeten Datenträgern. Obwohl eine Instanz eines Failoverclusters als einzelner Computer dargestellt wird, ermöglicht die Instanz die Ausführung eines Failovers von einem Knoten auf einen anderen, wenn der aktuelle Knoten nicht mehr verfügbar ist. SharePoint 2013 kann unter einer beliebigen Kombination von aktiven und passiven Knoten in einem Cluster ausgeführt werden, das SQL Server unterstützt.

Unter SharePoint 2013 wird auf den Cluster als Ganzes verwiesen. Daher erfolgt das Failover aus der Perspektive von SharePoint 2013 automatisch und nahtlos.

HinweisHinweis:
Wenn entweder ein geplantes oder ungeplantes Failover erfolgt, werden die Verbindungen gelöscht und müssen beim Übergang von einem Cluster-Knoten auf einen anderen Clusterknoten wiederhergestellt werden.

Detaillierte Informationen zum SQL Server-Failoverclustering finden Sie in den folgenden Artikeln:

Der entscheidende Vorteil von SQL Server-AlwaysOn-Verfügbarkeitsgruppen und SQL Server-Datenbankspiegelung ist, dass beide eine vollständige bzw. fast vollständige Datenredundanz gewährleisten, je nachdem, wie Sie sie für die Transaktionsverarbeitung konfigurieren. Zusätzlich zur Minimierung des Datenverlusts wird durch das automatische Failover auch die Ausfallzeit für die Produktionsdatenbank minimiert.

WichtigWichtig:
Obwohl die Datenbankspiegelung in SQL Server 2012 unterstützt wird, ist dieses Feature veraltet. Wir empfehlen Ihnen daher, bei der Entwicklung neuer Anwendungen auf die Verwendung dieses Features zu verzichten. Verwenden Sie stattdessen AlwaysOn-Verfügbarkeitsgruppen.

AlwaysOn-Verfügbarkeitsgruppen

Das SQL Server-Feature AlwaysOn-Verfügbarkeitsgruppen umfasst sowohl eine Hochverfügbarkeits- als auch eine Notfallwiederherstellungslösung, die auf Unternehmensebene eine Alternative zur Datenbankspiegelung bietet. AlwaysOn-Verfügbarkeitsgruppen unterstützen eine Failoverumgebung für eine oder mehrere Benutzerdatenbanken, die in einer benutzerdefinierten Sammlung enthalten sind. Diese Sammlung, eine Verfügbarkeitsgruppe, besteht aus den folgenden Komponenten:

  • Replikate, die als Verfügbarkeitsdatenbanken bezeichnete eigenständige Benutzerdatenbanken darstellen und als eine Einheit behandelt werden. Eine Verfügbarkeitsgruppe unterstützt ein primäres Replikat und bis zu vier sekundäre Replikate.

  • Eine bestimmte Instanz von SQL Server zum Hosten jedes Replikats und zum Verwalten einer lokalen Kopie aller Datenbanken, die zu der Verfügbarkeitsgruppe gehören.

Wenn für eine Verfügbarkeitsgruppe ein Failover auf eine Zielinstanz oder einen Zielserver ausgeführt wird, werden auch alle Datenbanken in der Gruppe in das Failover einbezogen. SQL Server 2012 kann mehrere Verfügbarkeitsgruppen auf einem einzelnen Server hosten, weshalb Sie für AlwaysOn das Failover auf SQL Server-Instanzen auf anderen Servern konfigurieren können. Aus diesem Grund müssen nicht unbedingt leistungsfähige Standbyserver zur Bewältigung der kompletten Arbeitsauslastung des primären Servers vorhanden sein. Dies ist einer der vielen Vorteile der Verwendung von Verfügbarkeitsgruppen.

HinweisHinweis:
Ein Failover wird nicht durch Datenbankprobleme verursacht, z. B. wenn eine Datenbank aufgrund des Verlusts einer Datendatei, des Löschens einer Datenbank oder der Beschädigung eines Transaktionsprotokolls verdächtig ist.

Weitere Informationen zu den Vorteilen von AlwaysOn-Verfügbarkeitsgruppen und eine Übersicht über die Terminologie für AlwaysOn-Verfügbarkeitsgruppen finden Sie unter AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Datenbankspiegelung

Die Datenbankspiegelung bietet Datenbankredundanz, indem eine gespiegelte Kopie der Datenbanken auf dem primären Datenbankserver gespeichert wird. Die Spiegelung wird pro Datenbank implementiert und funktioniert nur mit Datenbanken, die das vollständige Wiederherstellungsmodell verwenden.

HinweisHinweis:
Es gibt zwei Spiegelungsmodi. Einer davon, der Hochsicherheitsmodus, unterstützt den synchronen Betrieb. Wenn im Hochsicherheitsmodus eine Sitzung gestartet wird, synchronisiert der Spiegelserver die Spiegeldatenbank und die Prinzipal-Datenbank so schnell wie möglich. Sobald die Datenbanken synchronisiert sind, wird eine Transaktion in die Protokolldatei auf dem sekundären Server geschrieben und dann wiedergegeben. (Die Steuerung wird an den Prinzipalserver zurückgegeben, sobald die Transaktion gefestigt ist.) Der andere Spiegelungsmodus ist die Hochleistungsspiegelung, bei der ein asynchroner Betrieb verwendet wird, um auf Kosten eines erhöhten Datenverlusts die Transaktionslatenz zu reduzieren.

Für eine hochverfügbare Spiegelung in einer SharePoint-Farm müssen Sie den Hochsicherheitsmodus mit automatischem Failover verwenden. Für eine Hochsicherheitsdatenbankspiegelung sind drei Serverinstanzen erforderlich: ein Prinzipalserver, ein Spiegelserver und ein Zeugenserver. Der Zeugenserver ermöglicht das automatische Failover von SQL Server vom Prinzipalserver auf den Spiegelserver. Das Failover von der Prinzipaldatenbank auf die Spiegeldatenbank dauert normalerweise mehrere Sekunden.

Allgemeine Informationen zur Datenbankspiegelung finden Sie unter Datenbankspiegelung.

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

Die Wahl einer SQL Server-Technologie für hohe Verfügbarkeit und Notfallwiederherstellung sollte auf die Geschäftsziele Ihres Unternehmens im Hinblick auf die Zielsetzung für den Wiederherstellungspunkt (Recovery Point Objective, RPO) und die Zielsetzung für die Wiederherstellungsdauer (Recovery Time Objective, RTO) ausgerichtet sein. Obwohl RPO und RTO normalerweise mit der Notfallwiederherstellung verbunden sind, liegen einige Fehlerereignisse außerhalb des Anwendungsbereichs eines Notfalls, erfordern jedoch die Wiederherstellung aus lokalen Sicherungsmedien im primären Datencenter.

WichtigWichtig:
Abhängig von der jeweiligen Datenbank unterstützen die verschiedenen SharePoint 2013-Datenbanken nur spezifische SQL Server-Hochverfügbarkeitsoptionen. Weitere Informationen finden Sie unter Unterstützte Hochverfügbarkeits- und Notfallwiederherstellungsoptionen für SharePoint-Datenbanken (SharePoint 2013).

In der folgenden Tabelle werden die RPO- und RTO-Ergebnisse verglichen, die mit verfügbaren SQL Server-Lösungen erzielt werden.

HinweisHinweis:
Die Zeiten in der folgenden Tabelle gelten für den Vergleich der Datenbankoptionen. In der Praxis hängen alle Zeiten von Arbeitsauslastung, Datenvolumen und Failoverprozedur ab.

Vergleich von RPO und RTO auf Grundlage der Datenbanktechnologie

SQL Server-Lösung Potenzieller Datenverlust (RPO) Potenzielle Wiederherstellungszeit (RTO) Automatisches Failover Lesbare sekundäre Rolle
WichtigWichtig:
In SharePoint 2013 wird diese Konfiguration nicht unterstützt.

AlwaysOn-Verfügbarkeitsgruppe (synchroner Commitmodus)

Null

Sekunden

Ja

0–2

AlwaysOn-Verfügbarkeitsgruppe (asynchroner Commitmodus)

Sekunden

Minuten

Nein

0–4

AlwaysOn-Failoverclusterinstanz

Nicht zutreffend

Eine Failoverclusterinstanz selbst bietet keine Datensicherheit. Der Umfang des Datenverlusts hängt von der Speichersystemimplementierung ab.

Sekunden bis Minuten

Ja

Nicht zutreffend

Datenbankspiegelung – Hochsicherheitsmodus (synchroner Modus + Zeugenserver)

Null

Sekunden

Ja

Nicht zutreffend

Datenbankspiegelung – Hochverfügbarkeitsmodus (asynchroner Modus)

Sekunden

Minuten

Nein

Nicht zutreffend

Sichern, Kopieren, Wiederherstellen

Stunden oder Null, wenn nach dem Fehler auf das Ende des Protokolls zugegriffen werden kann.

Stunden bis Tage

Nein

Nicht während einer Wiederherstellung

Vergleich zwischen SQL Server-Cluster, -AlwaysOn-Verfügbarkeitsgruppe und -Datenbankspiegel

SQL Server-Failovercluster SQL Server 2012-AlwaysOn-Verfügbarkeitsgruppe SQL Server-Hochverfügbarkeitsspiegel

Zeit bis zum Failover

Clustermitglied übernimmt sofort bei Auftreten eines Fehlers. Kurze Verzögerung beim Hochfahren des Clusterknotens.

Replikat übernimmt sofort bei Auftreten eines Fehlers. Kurze Verzögerung beim Hochfahren des sekundären Replikats.

Spiegelserver übernimmt sofort nach Verarbeitung der Wiederholungswarteschlange.

Transaktionskonsistenz

Ja

Ja

Ja

Transaktionsparallelität

Ja

Ja

Ja

Zeit bis zur Wiederherstellung

Kürzere Zeit bis zur Wiederherstellung als bei Verfügbarkeitsgruppe.

Längere Zeit bis zur Wiederherstellung als Failovercluster, aber kürzere Zeit bis zur Wiederherstellung als gespiegelte Lösung.

Geringfügig längere Zeit bis zur Wiederherstellung als bei Cluster oder Verfügbarkeitsgruppe.

Schritte für Failover erforderlich

Fehler wird automatisch von den Datenbankknoten erkannt.

Da von SharePoint 2013 auf den Cluster verwiesen wird, erfolgt das Failover nahtlos und automatisch.

Der Verfügbarkeitsgruppenlistener erkennt den Fehler automatisch, das Failover erfolgt nahtlos und automatisch.

Fehler wird automatisch von der Datenbank erkannt.

SharePoint 2013 verfügt über Informationen zum Speicherort des Spiegels. Wenn dieser richtig konfiguriert wurde, erfolgt das Failover automatisch.

Schutz vor Speicherfehlern

Das Failovercluster selbst bietet keinen Datenschutz. Der Umfang des Datenverlusts ist abhängig vom implementierten Speichersystem. So verfügt beispielsweise eine SAN-Umgebung über redundante Komponenten, z. B. mehrere Dateipfade, RAID und Hot-Spares.

Schützt vor Speicherfehlern, da das primäre Replikat auf die lokalen Datenträger auf den sekundären Replikaten schreibt.

Schützt vor Speicherfehlern, da sowohl vom Prinzipaldatenbankserver als auch vom Spiegeldatenbankserver auf lokale Datenträger geschrieben wird.

Unterstützte Speichertypen

Freigegebener Speicher erforderlich (kostspieliger als dedizierter Speicher).

Kann weniger kostspielige direkt angeschlossene Speicherlösungen (Direct-Attached Storage, DAS) verwenden.

Kann weniger kostspieligen direkt angeschlossenen Speicher (Direct-Attached Storage, DAS) verwenden.

Anforderungen an den Speicherort

Die Mitglieder des Clusters müssen sich im gleichen Subnetz befinden.

HinweisHinweis:
Mit SQL Server 2012 ist dies nicht der Fall.

Replikate können sich in unterschiedlichen Subnetzen befinden, solange keine Leistungsprobleme aufgrund von Latenz auftreten.

Prinzipal-, Spiegel- und Zeugenserver müssen sich im gleichen LAN (mit einer Roundtriplatenz von max. 1 Millisekunde) befinden.

Wiederherstellungsmodell

Empfohlen wird das vollständige Wiederherstellungsmodell von SQL Server. Sie können das einfache SQL Server-Wiederherstellungsmodell verwenden, dann ist jedoch bei Verlust des Clusters die letzte vollständige Sicherung der einzige verfügbare Wiederherstellungspunkt.

Das vollständige Wiederherstellungsmodell von SQL Server 2012 ist erforderlich.

Das vollständige Wiederherstellungsmodell von SQL Server ist erforderlich.

Beeinträchtigung der Systemleistung

Während eines Failovers kann eine gewisse Beeinträchtigung der Systemleistung auftreten. Der Server ist während des Failovers nicht verfügbar, und Verbindungen werden gelöscht und anschließend auf dem neuen aktiven Knoten wiederhergestellt.

In AlwaysOn-Verfügbarkeitsgruppen kann eine Transaktionslatenz auftreten, die auf den synchronen Commitmodus auf den sekundären Replikaten zurückzuführen ist. Das Ausmaß der Latenz ist abhängig von der Anzahl der sekundären Replikate, die synchronisiert werden müssen.

Die Beeinträchtigungen für Arbeitsspeicher und Prozessorleistung sind größer als beim Clustering, jedoch geringer als bei der Spiegelung.

Durch die Spiegelung mit hoher Verfügbarkeit entsteht eine Transaktionslatenz, da der Vorgang synchron ist. Außerdem werden zusätzlicher Arbeitsspeicher und Prozessorleistung benötigt.

Bedienungsaufwand

Wird auf Serverebene eingerichtet und gewartet.

Der Bedienungsaufwand ist höher als bei Clustering und Spiegelung. Durch AlwaysOn ist neben der Windows Server -Ebene ein Bedienungsaufwand auf der Ebene des SQL Server-Datenbankservers erforderlich.

HinweisHinweis:
Objekte auf Serverebene, z. B. Anmeldungen und Agentaufträge, müssen manuell verwaltet werden.

Wenn Sie Inhaltsdatenbanken hinzufügen, müssen Sie diese einer Verfügbarkeitsgruppe hinzufügen und anschließend das primäre Replikat mit den sekundären Replikaten synchronisieren.

Für eine SharePoint-Farmumgebung sind verschiedene Konfigurationsschritte erforderlich, um sicherzustellen, dass die SharePoint 2013-Verbindungszeichenfolge dem Namen des Verfügbarkeitsgruppenlisteners korrekt zugeordnet ist.

Der Bedienungsaufwand ist höher als beim Clustering. Muss für alle Datenbanken eingerichtet und gewartet werden. Die Neukonfiguration nach dem Failover erfolgt manuell.

HinweisHinweis:
Objekte auf Serverebene, z. B. Anmeldungen und Agentaufträge, müssen manuell verwaltet werden.

Wenn Sie Inhaltsdatenbanken hinzufügen, müssen Sie diese einem Prinzipalserver hinzufügen und anschließend den Prinzipalserver mit dem Spiegelserver synchronisieren.

Manche Unternehmen unterhalten Rechenzentren, die sich nah beieinander befinden und die über Glasfaserverbindungen mit hoher Bandbreite miteinander vernetzt sind. Wenn eine solche Umgebung verfügbar ist, besteht die Möglichkeit, die beiden Rechenzentren als eine einzige Farm zu konfigurieren. Diese verteilte Farmtopologie wird als "gestreckte" Farm bezeichnet.

Damit eine gestreckte Farm als Unterstützung für eine Hochverfügbarkeitslösung verwendet werden kann, müssen folgende Voraussetzungen erfüllt sein:

  • Es liegt eine hochkonsistente farminterne Latenz von unter 1 ms vor (in einer Richtung), d. h. 99,9 % der Zeit für einen Zeitraum von 10 Minuten. Als farminterne Latenz wird normalerweise die Latenz zwischen den Front-End-Webservern und den Datenbankservern bezeichnet.)

  • Die Bandbreitengeschwindigkeit muss mindestens 1 Gigabit pro Sekunde betragen.

Sie können die Fehlertoleranz in einer gestreckten Farm sicherstellen, indem Sie die gängigen Verfahren für die Konfiguration von redundanten Dienstanwendungen und Datenbanken ausführen.

Die folgende Abbildung zeigt eine gestreckte Farm.

Gestreckte Farm

Eine ausgedehnte Farmtopologie mit Hochverfügbarkeit durch Einsatz von zwei Rechenzentren.

Ihre Hochverfügbarkeitsstrategie muss die entsprechenden Sicherungs- und Wiederherstellungsvorgänge umfassen, um die Ausfallsicherheit der SharePoint-Farm sicherzustellen. Wenn ein Ereignis, z. B. ein Datenträgerfehler oder Benutzerfehler, auftritt, müssen Sie in der Lage sein, den betroffenen Teil der Farmumgebung oder der Farmdaten zeitnah widerherzustellen. Mithilfe einer wirksamen Sicherungs- und Wiederherstellungslösung sollten Sie die von Ihnen definierten Zielsetzungen für die Wiederherstellungsdauer (RTO) und für den für den Wiederherstellungspunkt (RPO) erfüllen können.

Weitere Informationen finden Sie unter Sicherung und Wiederherstellung von SharePoint 2013.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft