Konzepte für hohe Verfügbarkeit und Notfallwiederherstellung in SharePoint ServerHigh availability and disaster recovery concepts in SharePoint Server

gilt für: ja2013 ja2016 ja2019 NeinSharePoint OnlineAPPLIES TO: yes2013 yes2016 yes2019 noSharePoint Online

Die hohe Verfügbarkeit und die Notfallwiederherstellung haben beim Erstellen eines Plans und der Systemspezifikationen für eine SharePoint Server-Farm die höchste Priorität. Andere Aspekte des Plans, z. B. hohe Leistung und Kapazität, erübrigen sich, wenn die Farmserver keine hohe Verfügbarkeit aufweisen oder wenn eine Farm nicht wiederhergestellt werden kann.High availability and disaster recovery is the highest priority when you create a plan and system specifications for a SharePoint Server farm. Other aspects of the plan, such as high performance and capacity, are negated if farm servers are not highly available or a farm cannot be recovered.

Um eine effektive Strategie zur Aufrechterhaltung eines effizienten und unterbrechungsfreien Betriebs zu entwerfen und zu implementieren, sollten Sie mit den Grundlagen der hohen Verfügbarkeit und der Notfallwiederherstellung vertraut sein. Diese Begriffe sind auch wichtig in Bezug auf die Auswertung und Auswahl der besten technischen Lösungen für Ihre SharePoint-Umgebung.To design and implement an effective strategy that maintains efficient and uninterrupted operations, you should understand the basic concepts of high availability and disaster recovery. These concepts are also important to evaluate and pick the best technical solutions for your SharePoint environment.

Einführung in das GeschäftskontinuitätsmanagementIntroduction to business continuity management

Das Geschäftskontinuitätsmanagement ist ein Verwaltungsprozess oder -programm, mit dem die Risiken in Bezug auf den unterbrechungsfreien Betrieb einer Organisation definiert, bewertet und besser verwaltet werden können. Beim Geschäftskontinuitätsmanagement geht es hauptsächlich um die Erstellung und Pflege eines Geschäftskontinuitätsplans. Dabei handelt es sich um eine Roadmap zur Weiterführung des Betriebs, wenn die normalen Geschäftsvorgänge aufgrund widriger Umstände unterbrochen wurden. Dabei kann es sich um natürliche oder menschliche Faktoren oder um eine Kombination aus beidem handeln. Ein Kontinuitätsplan wird aus den folgenden Analysen und Eingaben abgeleitet:Business continuity management is a management process or program that defines, assesses, and helps manage the risks to the continued running of an organization. Business continuity management focuses on creating and maintaining a business continuity plan, which is a roadmap for continuing operations when normal business operations are interrupted by adverse conditions. These conditions can be natural, man-made, or a combination of both. A continuity plan is derived from the following analyses and inputs:

  • Analyse der geschäftlichen RelevanzA business impact analysis

  • Analyse der Bedrohungen und RisikenA threat and risk analysis

  • Definition der AuswirkungenA definition of the impact scenarios

  • Satz dokumentierter WiederherstellungsanforderungenA set of documented recovery requirements

Das Ergebnis ist ein Lösungsentwurf bzw. ermittelte Optionen, ein Implementierungsplan, ein Testplan oder Akzeptanzplan für die Organisation und ein Wartungsplan bzw. Zeitplan.The result is a solution design or identified options, an implementation plan, a testing and organization acceptance plan, and a maintenance plan or schedule.

Ein Beispiel für Geschäftskontinuitätsmanagement ist Notfallwiederherstellung und Schutz für Daten und Anwendungen, das eine Momentaufnahme des Geschäftskontinuitätsprogramms bei Microsoft bereitstellt.An example of business continuity management is Disaster recovery and protection for data and applications, which provides a snapshot of the business continuity program at Microsoft.

Für viele Organisationen ist die Informationstechnologie (IT) natürlich ein wichtiger Aspekt der Geschäftskontinuitätsplanung. Die Geschäftskontinuität reicht jedoch noch weiter. Sie umfasst alle erforderlichen Vorgänge, mit denen sichergestellt wird, dass eine Organisation während und unmittelbar nach einer Störung durch einen Ausfall weiterarbeiten kann. Ein Geschäftskontinuitätsplan umfasst die folgenden Elemente, ist jedoch nicht darauf beschränkt:Obviously Information Technology (IT) is a significant aspect of business continuity planning for many organizations. However, business continuity is more encompassing - it includes all the operations that are needed to make sure that an organization can continue to do business during and immediately after a major disruptive event. A business continuity plan includes, but is not limited to, the following elements:

  • Richtlinien, Prozesse und Verfahrenpolicies, processes and procedures

  • Mögliche Optionen und Zuständigkeit für die Entscheidungsfindungpossible options and decision-making responsibility

  • Personalwesen und Betriebsanlagenhuman resources and facilities

  • Informationstechnologieinformation technology

Obwohl die hohe Verfügbarkeit und Notfallwiederherstellung häufig mit dem Geschäftskontinuitätsmanagement gleichgesetzt wird, handelt es sich dabei eher um Teilbereiche des Geschäftskontinuitätsmanagements.Although high availability and disaster recovery are often equated to business continuity management; they are in fact, subsets of business continuity management.

Beschreibung der hohen VerfügbarkeitDescribing high availability

Für eine Softwareanwendung oder einen Dienst wird die hohe Verfügbarkeit letztendlich am Eindruck und den Erwartungen der Endbenutzer gemessen. Die tatsächlich messbaren und empfundenen geschäftlichen Auswirkungen von Ausfallzeiten lassen sich als Informationsverlust, Schäden an Betriebseinrichtungen, verringerte Produktivität, Kosten für entgangene Verkaufschancen, Vertragsverletzungen oder Vertrauensverlust beschreiben.For a given software application or service, high availability is ultimately measured in terms of the end user's experience and expectations. The tangible and perceived business impact of downtime may be expressed in terms of information loss, property damage, decreased productivity, opportunity costs, contractual damages, or the loss of goodwill.

Das Hauptziel einer Lösung für hohe Verfügbarkeit besteht darin, die Auswirkungen aufgrund von Ausfallzeiten zu verringern oder zu mindern. Bei einer guten Strategie besteht eine optimales Gleichgewicht zwischen Geschäftsprozessen und Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) und technischen Funktionen und Infrastrukturkosten.The principal goal of a high availability solution is to minimize or mitigate the impact of downtime. A sound strategy for this optimally balances business processes and Service Level Agreements (SLAs) with technical capabilities and infrastructure costs.

Ein Plattform wird gemäß der Vereinbarung zwischen Kunden und Beteiligten und deren Erwartungen als hoch verfügbar angesehen. Die Verfügbarkeit eines Systems kann mithilfe der folgenden Formel ausgedrückt werden:A platform is considered highly available per the agreement and expectations of customers and stakeholders. The availability of a system can be expressed as this calculation:

Ist-Betriebszeit/Soll-Betriebszeit X 100 %Actual uptime/Expected uptime X 100%

Das Ergebnis wird in der Branche häufig als Anzahl der Zahl 9 für eine Lösung ausgedrückt. So wird die mögliche jährliche Betriebszeit (bzw. die Ausfallzeit) in Minuten angegeben.The resulting value is often expressed by industry in terms of the number of 9's that the solution provides; meant to convey an annual number of minutes of possible uptime, or conversely, minutes of downtime.

Zahl 9Number of 9's Verfügbarkeit in ProzentAvailability Percentage Jährliche AusfallzeitTotal Annual Downtime
22
99 %99%
3 Tage, 15 Stunden3 days, 15 hours
33
99,9 %99.9%
8 Stunden, 45 Minuten8 hours, 45 minutes
44
99,99 %99.99%
52 Minuten, 34 Sekunden52 minutes, 34 seconds
55
99,999 %99.999%
5 Minuten, 15 Sekunden5 minutes, 15 seconds

Geplante und nicht geplante AusfallzeitenPlanned versus unplanned downtime

Systemausfälle sind entweder antizipiert oder geplant, oder sie sind das Ergebnis eines ungeplanten Ausfalls. Ausfallzeiten sind nicht unbedingt etwas Negatives, solange sie richtig gemanagt werden. Es gibt zwei Hauptarten vorhersehbarer Ausfallzeiten:System outages are either anticipated or planned for, or they are the result of an unplanned failure. Downtime need not be considered negatively if it is appropriately managed. There are two key types of foreseeable downtime:

  • Geplante Wartung: Ein Zeitfenster wird angekündigt und für geplante Wartungsaufgaben koordiniert, z. B. Softwarepatching, Hardwareupgrades, Kennwortupdates, Offline-Neuindizierung, Datenladevorgänge oder das Testen von Maßnahmen zur Notfallwiederherstellung. Wohlüberlegte und professionell verwaltete Betriebsabläufe sollten dazu führen, dass Ausfallzeiten möglichst gering gehalten und Datenverluste vermieden werden. Geplante Wartungsaktivitäten sollten als erforderliche Investition in die Verhinderung oder Minderung ungeplanter Ausfälle mit negativeren Auswirkungen angesehen werden.Planned maintenance. A time window is preannounced and coordinated for planned maintenance tasks such as software patching, hardware upgrades, password updates, offline re-indexing, data loading, or the rehearsal of disaster recovery procedures. Deliberate, well-managed operational procedures should minimize downtime and prevent any data loss. Planned maintenance activities can be seen as investments needed to prevent or mitigate other potentially more severe unplanned outage scenarios.

  • Ungeplanter Ausfall: Es können Ausfälle auf Systemebene oder in Bezug auf die Infrastruktur oder Prozesse auftreten, die ungeplant oder unkontrollierbar sind oder die entweder als zu unwahrscheinlich oder als Ausfall mit akzeptablen Auswirkungen eingestuft wurden. Eine solide Lösung zur Sicherstellung der hohen Verfügbarkeit erkennt diese Arten von Ausfällen, stellt die Betriebsfähigkeit automatisch wieder her und richtet die Fehlertoleranz wieder ein.Unplanned outage. System-level, infrastructure, or process failures may occur that are unplanned or uncontrollable, or that are foreseeable, but considered either too unlikely to occur, or are considered to have an acceptable impact. A robust high availability solution detects these types of failures, automatically recovers from the outage, and then reestablishes fault tolerance.

Beim Ausrichten von SLAs auf hohe Verfügbarkeit ist es ratsam, separate Key Performance Indicators (KPIs) für geplante Wartungsaktivitäten und ungeplante Ausfallzeiten zu berechnen. Bei diesem Ansatz können Sie Ihrer Investition in geplante Wartungsaktivitäten den Vorteil der Vermeidung von ungeplanten Ausfallzeiten gegenüberstellen.When establishing SLAs for high availability, you should calculate separate key performance indicators (KPIs) for planned maintenance activities and unplanned downtime. This approach allows you to contrast your investment in planned maintenance activities against the benefit of avoiding unplanned downtime.

Herabgesetzte VerfügbarkeitDegraded availability

Hohe Verfügbarkeit sollte nicht als Alles-oder-nichts-Service angesehen werden. Als Alternative zu einem vollständigen Ausfall ist es für Endbenutzer häufig akzeptabel, dass ein System teilweise verfügbar ist oder über einen eingeschränkten Funktionsumfang oder eine herabgesetzte Leistung verfügt. Zu diesen unterschiedlichen Verfügbarkeitsgraden gehört Folgendes:High availability should not be considered as an all-or-nothing proposition. As an alternative to a complete outage, it is often acceptable to the end user for a system to be partially available, or to have limited functionality or degraded performance. These varying degrees of availability include:

  • Schreibgeschützter und verzögerter Betrieb: Während eines Wartungszeitfensters oder einer Notfallwiederherstellung in Phasen ist das Abrufen von Daten weiterhin möglich, aber neue Workflows und die Hintergrundverarbeitungsschritte sind ggf. vorübergehend unterbrochen bzw. befinden sich in der Warteschlange.Read-only and deferred operations. During a maintenance window, or during a phased disaster recovery, data retrieval is still possible, but new workflows and background processing may be temporarily halted or queued.

  • Datenwartezeit und Anwendungsreaktionsfähigkeit: Aufgrund einer hohen Auslastung, einem Rückstand bei der Verarbeitung oder eines Teilausfalls der Plattform kann es dazu kommen, dass Hardwareressourcen mit eingeschränktem Umfang überlastet bzw. für die Auslastung nicht ausgelegt sind. Darunter kann die Benutzerfreundlichkeit leiden, aber die Nutzung ist ggf. weiter möglich, wenn auch mit geringerer Produktivität.Data latency and application responsiveness. Due to a heavy workload, a processing backlog, or a partial platform failure, limited hardware resources may be over-committed or under-sized. User experience may suffer, but work may still get done in a less productive manner.

  • Teilausfälle, vorübergehende Ausfälle oder drohende Ausfälle: Hierbei ist die Robustheit der Anwendungslogik bzw. des Hardwarestapels entscheidend, damit der Vorgang bei Auftreten eines Fehlers wiederholt wird oder selbständig Korrekturmaßnahmen eingeleitet werden können. Diese Art von Problem wirkt sich für Endbenutzer als Datenwartezeit oder schlechte Reaktionsfähigkeit der Anwendung aus.Partial, transient, or impending failures. Robustness in the application logic or hardware stack that retries or self-corrects upon encountering an error. These types of issues may appear to the end user as data latency or poor application responsiveness.

  • End-to-End-Teilausfall: Geplante oder ungeplante Ausfallzeiten können für die vertikalen Ebenen des Lösungsstapels (Infrastruktur, Plattform und Anwendung) oder auf horizontaler Ebene zwischen unterschiedlichen Funktionskomponenten auftreten. Je nach den betroffenen Funktionen oder Komponenten sind die Aktionen der Benutzer teilweise erfolgreich oder werden mit herabgesetzter Leistung ausgeführt.Partial end-to-end failure. Planned or unplanned outages may occur gracefully within vertical layers of the solution stack (infrastructure, platform, and application), or horizontally between different functional components. Users may experience partial success or degradation, depending upon the features or components that are affected.

Die Annehmbarkeit dieser suboptimalen Szenarien sollte als Teil eines Spektrums von herabgesetzter Verfügbarkeit, die zu einem vollständigen Ausfall führt, und in Bezug auf Zwischenschritte der Notfallwiederherstellung in Phasen überprüft werden.The acceptability of these suboptimal scenarios should be considered as part of a spectrum of degraded availability leading up to a complete outage, and as intermediate steps in a phased disaster recovery.

Quantifizierung der AusfallzeitenQuantifying downtime

Wenn Ausfallzeiten entweder geplant oder ungeplant auftreten, besteht das Hauptgeschäftsziel darin, das System wieder in den Onlinezustand zu versetzen und Datenverluste möglichst gering zu halten. Jede Minute der Ausfallzeit ist mit direkten und indirekten Kosten verbunden. Bei ungeplanten Ausfallzeiten müssen die Zeit und der Aufwand abgewogen werden, die bzw. der erforderlich ist, um Folgendes zu bestimmen: warum ist es zum Ausfall gekommen, in welchem Zustand befindet sich das System momentan und welche Schritte sind zur Wiederherstellung nötig.When downtime does occur, either planned, or unplanned, the primary business goal is to bring the system back online and minimize data loss. Every minute of downtime has direct and indirect costs. With unplanned downtime, you must balance the time and effort needed to determine why the outage occurred, what the current system state is, and what steps are needed to recover from the outage.

An einem vorab definierten Punkt jedes Ausfalls sollte die Geschäftsentscheidung getroffen werden, die Untersuchung des Ausfalls zu beenden oder Wartungsaufgaben durchzuführen, die Wiederherstellung durchzuführen, indem das System wieder in den Onlinezustand versetzt wird, und, falls erforderlich, die Fehlertoleranz wieder einzurichten.At a predetermined point in any outage, you should make or seek the business decision to stop investigating the outage or performing maintenance tasks, recover from the outage by bringing the system back online, and if needed, reestablish fault tolerance.

Ziele der WiederherstellungRecovery objectives

Die Datenredundanz ist eine wichtige Komponente der hohen Verfügbarkeit. Die Transaktionsaktivitäten der primären SQL Server-Instanz werden synchron oder asynchron auf eine oder mehrere sekundäre Instanzen angewendet. Wenn ein Ausfall auftritt, kann für aktive Transaktionen ein Rollback ausgeführt werden. So soll verhindert werden, dass die Transaktionen aufgrund von Verzögerungen bei der Datenpropagierung auf den sekundären Instanzen verloren gehen.Data redundancy is a key component of a high availability database solution. Transactional activity on your primary SQL Server instance is synchronously or asynchronously applied to one or more secondary instances. When an outage occurs, transactions that were in flight may be rolled back, or they may be lost on the secondary instances due to delays in data propagation.

Sie können sowohl die Auswirkungen messen und Wiederherstellungsziele für die Dauer bis zur Erreichung des normalen Betriebszustands festlegen als auch messen, welche Wartezeit für die zuletzt wiederhergestellte Transaktion gilt:You can both measure the impact, and set recovery goals in terms of how long it takes to get back in business, and how much time latency there is in the last transaction recovered:

  • Zielsetzung für die Wiederherstellungsdauer (Recovery Time Objective, RTO): Dies ist die Dauer des Ausfalls. Das erste Ziel besteht darin, das System mindestens im schreibgeschützten Modus wieder in den Onlinezustand zu versetzen, um die Untersuchung des Ausfalls zu ermöglichen. Hauptziel ist jedoch die Wiederherstellung des vollständigen Betriebs bis zu dem Punkt, an dem wieder neue Transaktionen durchgeführt werden können.Recovery Time Objective (RTO). This is the duration of the outage. The initial goal is to get the system back online in at least a read-only capacity to facilitate investigation of the failure. However, the primary goal is to restore full service to the point that new transactions can take place.

  • Zielsetzung für den Wiederherstellungspunkt (Recovery Point Objective, RPO): Dies wird häufig als das Maß für den akzeptablen Datenverlust bezeichnet. Es handelt sich dabei um den Zeitraum bzw. die Wartezeit zwischen der letzten abgeschlossenen Datentransaktion vor dem Ausfall und den neuesten wiederhergestellten Daten nach dem Ausfall. Der tatsächliche Datenverlust kann je nach Auslastung des Systems zum Zeitpunkt des Ausfalls, Art des Ausfalls und Art der verwendeten Lösung für hohe Verfügbarkeit variieren.Recovery Point Objective (RPO). This is often referred to as a measure of acceptable data loss. It is the time gap or latency between the last committed data transaction before the failure and the most recent data recovered after the failure. The actual data loss can vary depending upon the workload on the system at the time of the failure, the type of failure, and the type of high availability solution used.

    Hinweis

    Ein verwandtes Ziel ist Zielsetzung für die Wiederherstellungsstufe (Recovery Level Objective, RLO). Bei der Zielsetzung für die Wiederherstellungsstufe geht es um die Definition der Granularität, mit der Sie Daten wiederherstellen können müssen. Dabei geht es darum, ob Sie die gesamte Farm, die Webanwendung, die Websitesammlung, die Website, die Liste oder Bibliothek oder das Element wiederherstellen können. Weitere Informationen finden Sie unter Planen der Sicherung und der Wiederherstellung in SharePoint Server.A related objective is Recovery level objective (RLO). This objective defines the granularity with which you must be able to recover data — whether you must be able to recover the whole farm, Web application, site collection, site, list or library, or item. For more information, see Plan for backup and recovery in SharePoint Server.

Sie sollten RTO- und RPO-Werte als Ziele verwenden, mit denen die Geschäftstoleranz für Ausfallzeiten und den akzeptablen Datenverlust angegeben wird, sowie als Kennzahlen zur Überwachung der Verfügbarkeitsintegrität.You should use RTO and RPO values as goals that indicate business tolerance for downtime and acceptable data loss, and as metrics for monitoring availability health.

Rechtfertigung von ROI und Kosten für VerkaufschancenJustifying ROI or opportunity cost

Die Geschäftskosten von Ausfallzeiten können entweder finanzieller Art sein oder die Kundenzufriedenheit betreffen. Diese Kosten können zeitabhängig sein oder zu einem bestimmten Punkt des Ausfallzeitfensters anfallen. Zusätzlich zur Projektierung der Kosten eines Ausfalls mit einer bestimmten Wiederherstellungszeit und einem Datenwiederherstellungspunkt können Sie auch die Geschäftsprozess- und Infrastrukturinvestitionen berechnen, die erforderlich sind, um die RTO- und RPO-Ziele zu erreichen oder den Ausfall ganz zu vermeiden. Diese Investitionsplanung sollte Folgendes umfassen:The business costs of downtime may be either financial or in the form of customer goodwill. These costs may accrue with time, or they may be incurred at a certain point in the outage window. In addition to projecting the cost of incurring an outage with a given recovery time and data recovery point, you can also calculate the business process and infrastructure investments needed to attain your RTO and RPO goals or to avoid the outage all together. These investment themes should include:

  • Verhindern von Ausfallzeiten: Kosten für die Wiederherstellung nach einem Ausfall können vollständig vermieden werden, wenn es gar nicht erst zu einem Ausfall kommt. Zu den Investitionen gehören die Kosten für fehlertolerante und redundante Hardware oder Infrastruktur, für die Verteilung von Arbeitslasten auf isolierte potenzielle Fehlerquellen und geplante Ausfallzeiten für Präventivmaßnahmen.Avoiding downtime. Outage recovery costs are avoided all together if an outage doesn't occur in the first place. Investments include the cost of fault-tolerant and redundant hardware or infrastructure, distributing workloads across isolated points of failure, and planned downtime for preventive maintenance.

  • Automatisieren der Wiederherstellung: Wenn ein Systemausfall auftritt, können Sie die Auswirkungen der Ausfallzeit auf die Kundenzufriedenheit erheblich minimieren, indem Sie für eine automatische und transparente Wiederherstellung sorgen.Automating recovery. If a system failure occurs, you can greatly mitigate the impact of downtime on the customer experience through automatic and transparent recovery.

  • Ressourcenverwendung: Die sekundäre oder Standby-Infrastruktur kann sich im Leerlauf befinden, während sie einen Ausfall erwartet. Außerdem kann sie für Arbeitslasten im schreibgeschützten Modus oder zum Verbessern der Gesamtleistung des Systems genutzt werden, indem Arbeitslasten auf die gesamte verfügbare Hardware verteilt werden.Resource utilization. Secondary or standby infrastructure can sit idle, awaiting an outage. It also can be leveraged for read-only workloads, or to improve overall system performance by distributing workloads across all available hardware.

Für die jeweiligen RTO- und RPO-Ziele können die erforderlichen Investitionen in Verfügbarkeit und Wiederherstellung (in Kombination mit den projizierten Kosten für Ausfallzeiten) als Zeitfunktion ausgedrückt und gerechtfertigt werden. Während eines Ausfalls können Sie so basierend auf der verstrichenen Ausfallzeit kostenabhängige Entscheidungen treffen.For given RTO and RPO goals, the needed availability and recovery investments, combined with the projected costs of downtime, can be expressed and justified as a function of time. During an actual outage, this allows you to make cost-based decisions based on the elapsed downtime.

Überwachen der VerfügbarkeitsintegritätMonitoring availability health

Aus betrieblicher Sicht sollten Sie während eines Ausfalls nicht versuchen, alle relevanten Variablen zu berücksichtigen und den ROI oder die Kosten für Verkaufschancen in Echtzeit zu berechnen. Stattdessen sollten Sie die Datenwartezeit auf Ihren Standby-Instanzen als Proxy für den erwarteten RPO-Wert überwachen.From an operational point of view, during an actual outage, you should not attempt to consider all relevant variables and calculate ROI or opportunity costs in real time. Instead, you should monitor data latency on your standby instances as a proxy for expected RPO.

Bei einem Ausfall sollten Sie auch die Zeit begrenzen, die direkt nach dem Auftreten zur Untersuchung der Hauptursache aufgewendet wird, und sich stattdessen auf die Überprüfung der Integrität Ihrer Wiederherstellungsumgebung konzentrieren und später dann ausführliche Systemprotokolle und Zweitkopien von Daten für eine genaue Analyse nutzen.In the event of an outage, you should also limit the initial time spent investigating the root cause during the outage, and instead focus on validating the health of your recovery environment, and then rely upon detailed system logs and secondary copies of data for subsequent forensic analysis.

Planen der NotfallwiederherstellungPlanning for disaster recovery

Während es bei der Sicherstellung der hohen Verfügbarkeit darum geht, was Sie zur Verhinderung eines Ausfalls tun können, geht es bei der Notfallwiederherstellung darum, welche Maßnahmen zum Wiederherstellen der hohen Verfügbarkeit nach einem Ausfall getroffen werden.While high availability efforts entail what you do to prevent an outage, disaster recovery efforts address what is done to re-establish high availability after the outage.

Die Verfahren und Zuständigkeiten für die Notfallwiederherstellung sollten so weit wie möglich festgelegt werden, bevor ein Ausfall auftritt. Mithilfe von aktiver Überwachung und Warnungen sollte die Entscheidung, einen automatisierten oder manuellen Failover- und Wiederherstellungsplan zu initiieren, an vorab definierte RTO- und RPO-Schwellenwerte gebunden sein. Ein guter Plan für die Notfallwiederherstellung sollte Folgendes umfassen:As much as possible, disaster recovery procedures and responsibilities should be formulated before an actual outage occurs. Based upon active monitoring and alerts, the decision to initiate an automated or manual failover and recovery plan should be tied to pre-established RTO and RPO thresholds. The scope of a sound disaster recovery plan should include:

  • Granularität für Ausfall und Wiederherstellung: Je nach Ort und Art des Ausfalls können Sie auf unterschiedlichen Ebenen Korrekturmaßnahmen einleiten, z. B. auf den Ebenen Rechenzentrum, Infrastruktur, Plattform, Anwendung oder Arbeitsauslastung.Granularity of failure and recovery. Depending upon the location and type of failure, you can take corrective action at different levels; that is, data center, infrastructure, platform, application, or workload.

  • Quellmaterial für Untersuchungen. Grundlegende und aktuelle Daten in Form von Überwachungsverläufen, Systemwarnungen, Ereignisprotokollen und Diagnoseabfragen sollten für alle wichtigen Stellen direkt verfügbar sein.Investigative source material. Baseline and recent monitoring history, system alerts, event logs, and diagnostic queries should all be readily accessible by appropriate parties.

  • Koordination von Abhängigkeiten: Welche System- und Geschäftsabhängigkeiten gelten im Anwendungsstapel und für die Beteiligten?Coordination of dependencies. Within the application stack, and across stakeholders, what are the system and business dependencies?

  • Entscheidungsstruktur: Dies ist eine vordefinierte, wiederholbare, überprüfte Entscheidungsstruktur, die Rollenzuständigkeiten, Fehlerselektierung, Failoverkriterien in Bezug auf RPO- und RTO-Ziele und vorgeschriebene Wiederherstellungsziele umfasst.Decision tree. A predetermined, repeatable, validated decision tree that includes role responsibilities, fault triage, failover criteria in terms of RPO and RTO goals, and prescribed recovery steps.

  • Überprüfung: Was muss nach dem Ausführen von Schritten zur Wiederherstellung bei einem Ausfall erfolgen, um sicherzustellen, dass das System zum normalen Betrieb zurückgekehrt ist?Validation. After taking steps to recover from the outage, what must be done to verify that the system has returned to normal operations?

  • Dokumentation: Erfassen Sie alle obigen Punkte in ausreichender Ausführlichkeit und Deutlichkeit in einer Dokumentation, damit auch Dritte den Wiederherstellungsplan mit minimaler Hilfestellung ausführen können. Diese Art von Dokumentation wird auf Englisch häufig als "Run Book" oder "Cook Book" bezeichnet.Documentation. Capture all of the above items in a set of documentation, with sufficient detail and clarity so that a third party team can execute the recovery plan with minimal assistance. This type of documentation is commonly called a 'run book' or a 'cook book'.

  • Testläufe der Wiederherstellung: Führen Sie regelmäßig Testläufe des Plans zur Notfallwiederherstellung durch, um in Bezug auf die RTO-Ziele grundlegende Erwartungen aufzustellen. Erwägen Sie außerdem, das Hosten der primären Produktionswebsite per Rotationssystem regelmäßig von der primären Website auf die einzelnen Websites für die Notfallwiederherstellung zu verlagern.Recovery rehearsals. Regularly exercise the disaster recovery plan to establish baseline expectations for RTO goals, and consider regular rotation of hosting the primary production site on the primary and each of the disaster recovery sites.

Siehe auchSee also

KonzepteConcepts

Wählen einer Notfallwiederherstellungsstrategie für SharePoint ServerChoose a disaster recovery strategy for SharePoint Server

Weitere RessourcenOther Resources

Welche Arbeitslasten können Sie mit der Azure Site Recovery schützen?What workloads can you protect with Azure Site Recovery?

Replizieren einer SharePoint-Anwendung mit mehreren Ebene für die Wiederherstellung mithilfe von Azure Site RecoveryReplicate a multi-tier SharePoint application for disaster recovery using Azure Site Recovery