SharePoint Server での高可用性および障害回復の概念High availability and disaster recovery concepts in SharePoint Server

適用対象:はい2013 yes2016 yes2019 SharePointOnline なしAPPLIES TO: yes2013 yes2016 yes2019 noSharePoint Online

SharePoint Server ファームの計画とシステム仕様を作成するとき、高可用性と障害復旧は最優先になります。ファーム サーバーが高可用性ではなく、またファームが復旧できない場合は、高性能と十分な容量といった、計画のその他の側面は無意味になります。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.

効率的で中断のない運用を維持する効果的な戦略を設計、実装するには、高可用性と障害復旧の基本的な概念を理解する必要があります。また、これらの概念は、SharePoint 環境での最良の技術ソリューションを評価し、選ぶ際に重要です。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.

ビジネス継続性管理の概要Introduction to business continuity management

ビジネス継続性管理とは、継続的な組織運営でのリスクを定義、評価、管理するのに役立つ、管理過程あるいはプログラムです。ビジネス継続性管理では、ビジネス継続性計画の作成と管理に焦点を合わせます。ビジネス継続性計画とは、通常の業務が問題によって中断されたときに、業務を継続するロードマップです。これらの状況は、自然発生的、人為的、またはこれら両方の組み合わせであることがあります。継続性計画は、以下の分析と入力から作成されます。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:

  • ビジネス影響分析A business impact analysis

  • 脅威およびリスク分析A threat and risk analysis

  • 影響シナリオの定義A definition of the impact scenarios

  • 一連の文書化された復旧要件A set of documented recovery requirements

この結果は、ソリューション設計または識別された選択肢、実装計画、テストおよび組織受領計画、保守計画または予定となります。The result is a solution design or identified options, an implementation plan, a testing and organization acceptance plan, and a maintenance plan or schedule.

ビジネス継続性管理の一例として、障害復旧およびデータとアプリケーションの保護は、Microsoft のビジネス継続性プログラムの一端を示しています。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.

情報技術 (IT) は、多くの組織のビジネス継続性計画で明らかに重大な側面です。しかし、ビジネス継続性にはより多くのものが含まれます。これには、重大な中断の原因となる事故、発生中と発生直後に、組織がビジネスを継続する目的で必要とするすべての活動が含まれます。ビジネス継続性計画には、主に以下の要素が含まれます。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:

  • ポリシー、過程、および手順policies, processes and procedures

  • 選択肢と意志決定責任possible options and decision-making responsibility

  • 人的資源と施設human resources and facilities

  • 情報技術information technology

高可用性および障害復旧は、しばしばビジネス継続性管理と同一視されますが、これらは、実際には、ビジネス継続性管理の一部でしかありません。Although high availability and disaster recovery are often equated to business continuity management; they are in fact, subsets of business continuity management.

高可用性とはDescribing high availability

特定のソフトウェア アプリケーションまたはサービスで、高可用性は、最終的には、エンド ユーザーの体験と予測事項として測定されます。ダウンタイムの、具体的で認知されるビジネス影響は、情報損失、物品の損害、生産性の減少、機会費用、契約上の損害、または信用の損失として表れることがあります。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.

高可用性ソリューションの主要な目的は、ダウンタイムの影響を最小化または軽減することです。ここでの適切な戦略とは、技術能力とインフラストラクチャ費用に対して、ビジネス プロセスおよびサービス レベル契約 (SLA) の最適なバランスをとることです。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.

プラットフォームは、顧客および関係者の期待に応え、合意を得てはじめて高可用性であるとみなされます。システムの利用可能時間は、以下の計算で表せます。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:

実際の稼働時間/予期された稼働時間 X 100%Actual uptime/Expected uptime X 100%

一般的に、結果の値は、ソリューションが実現する 9 の数で示されます。ここから、年間の稼働時間、または逆に、ダウンタイムの時間が導かれます。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.

9 の数Number of 9's 利用可能時間の割合Availability Percentage 年間ダウンタイムの合計Total Annual Downtime
pbm-22
99%99%
3 日、15 時間3 days, 15 hours
1/33
99.9%99.9%
8 時間 45 分8 hours, 45 minutes
2/44
99.99%99.99%
52 分 34 秒52 minutes, 34 seconds
55
99.999%99.999%
5 分 15 秒5 minutes, 15 seconds

計画されたダウンタイムと予定外のダウンタイムPlanned versus unplanned downtime

システムの機能停止は、予定または計画されている場合と、予定外の障害の結果であることがあります。適切に管理されている場合、ダウンタイムは問題とみなす必要はありません。予測可能なダウンタイムには、主な種類が 2 つあります。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:

  • 計画された保守。 期間が前もって告知され、調整されている、計画された保守タスクです。ソフトウェアへの更新プログラム適用、ハードウェアのアップグレード、パスワード更新、オフライン再インデックス作成、データ読み込み、障害復旧手順のリハーサルなどです。運用手順が、計画的で、よく管理されていれば、ダウンタイムを最小限にして、データ損失を防げます。計画された保守作業は、より重大な、予定外の機能停止シナリオを防ぐ、または軽減する目的の、必要な投資とみなせます。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.

  • 予定外の停止。 予定外または制御不可、あるいは予測可能だが発生の可能性が低いか影響が許容可能と見なされる、システムレベル、インフラストラクチャ、またはプロセス障害が発生することがあります。信頼性の高い高可用性ソリューションは、これらの種類の障害を検出して、機能停止から自動的に回復して、次にフォールト トレランスを再確立します。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.

高可用性の SLA を設定するとき、計画された保守作業と予定外のダウンタイムについて、個別の主要業績評価指標 (KPI) を計算する必要があります。この手法により、予定外のダウンタイムを回避する利点に対する、計画された保守作業への投資を比較できます。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.

利用可能時間の減少Degraded availability

高可用性は、妥協を許さない提案とみなすべきではありません。エンド ユーザーにとっては、完全な機能停止を避けられる場合は、システムが一部のみ使用可能であることや、機能やパフォーマンスに制限が出ることは、一般的に許容範囲内です。利用可能時間の程度には、以下のものがあります。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:

  • 読み取り専用および延期された作業。 メンテナンス時間中、または段階的に実行される障害復旧中に、データ取得はできますが、新しいワークフローまたはバックグラウンド処理が一時的に停止されるか、またはキューに入れられることがあります。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.

  • データ遅延とアプリケーション反応性。 重い負荷、処理中のバックログ、または部分的なプラットフォーム障害によって、一部のハードウェア リソースに過度に負荷がかかることや、容量不足になることがあります。ユーザー エクスペリエンスの質が低下し、生産性は下がりますが、作業は行うことができます。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.

  • 部分的障害、一時的障害、または発生が予測される障害。 安定性の機能として、アプリケーション ロジックまたはハードウェアスタックで、エラー発生時に再試行や自己修正を繰り返すことがあります。これは、エンド ユーザーには、データ遅延またはアプリケーションの反応性の低下として表れることがあります。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.

  • 部分的なエンド トゥ エンドの障害。 機能停止は、計画されたものと予定外のものにかかわらず、ソリューション スタック (インフラストラクチャ、プラットフォーム、およびアプリケーション) の垂直レイヤーで、または、さまざまな機能コンポーネントの間で水平的に、正規の手順に沿って行うことができます。影響を受ける機能またはコンポーネントによって、ユーザーは、部分的に正常な機能を使えるか、機能低下を感じることがあります。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.

これらの次善のシナリオが受け入れられるものかどうかは、完全な機能停止に至る、利用可能時間の低下の連続体の一部として、また、段階的に実行する障害復旧の中間の手順として考える必要があります。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.

ダウンタイムを数値化するQuantifying downtime

計画されたものか予定外のものかにかかわらず、ダウンタイムが発生したとき、主なビジネス目標は、システムをオンライン状態に復帰し、データ損失を最小限にすることです。ダウンタイムには、分刻みで、直接および間接的な費用が発生します。予定外のダウンタイムが発生したとき、機能停止が発生した理由、現在のシステム状態、機能停止からの回復に必要な手順を判定するのに必要な時間と作業を調整する必要があります。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.

機能停止後の一定の時点で、機能停止の原因調査または保守タスクの中止をする、または、システムを再度オンラインにして機能停止から回復し、必要に応じて、フォールト トレランスを再確立するビジネス判断を、自分で行うか、または他者に依頼する必要があります。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.

復旧の目標Recovery objectives

データ冗長性は高可用性データベース ソリューションの主要な構成要素です。プライマリ SQL Server インスタンスのトランザクション操作は、同期的または非同期に、1 つまたは複数のセカンダリ インスタンスに適用されます。機能停止が発生したとき、実行中のトランザクションはロール バックされるか、データ伝達の遅延があればセカンダリ インスタンスで失われることがあります。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.

業務再開までに掛かる時間と、復旧された最後のトランザクションの待機時間がどれだけかについて、影響の測定と、復旧目標の設定の両方を実行できます。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:

  • 目標復旧時間 (RTO)。 これは機能停止の継続時間です。初期の目標は、障害の調査が容易になるように、少なくとも読み取り専用となるようにシステムをオンラインに戻すことです。しかし、主要な目的は、新しいトランザクションが行えるようになるまで、完全なサービスを復旧することです。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.

  • 目標復旧時点 (RPO)。 これは、一般的に許容範囲内のデータ損失の基準と呼ばれます。これは、障害前に最後に確定されたデータ トランザクションと、障害後に復旧された最新のデータ間の時間差または遅延です。実際のデータ損失は、障害時のシステムのワークロード、障害の種類、使用された高可用性ソリューションの種類によって変わることがあります。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.

    注意

    関係する目標として、 復旧レベル目標 (RLO) があります。この目標は、データを復旧するときの復旧範囲の単位 (ファーム全体、Web アプリケーション、サイト コレクション、サイト、リストまたはライブラリ、あるいはアイテム) を定義します。詳細については、「 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.

RTO 値と RPO 値は、ダウンタイムおよび許容範囲内のデータ損失の、ビジネス許容範囲を指定する目標として、また、可用性正常性を監視する測定基準として使用する必要があります。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.

ROI または機会費用を正当化するJustifying ROI or opportunity cost

ダウンタイムのビジネス費用は、財務への影響か、顧客信用の低下として表れることがあります。これらのコストは、時間と共に蓄積するか、機能停止での特定の時点で発生します。特定の復旧時間およびデータ復元ポイントでの、機能停止の費用予測に加えて、RTO および RPO 目標を達成するか、機能停止を完全に回避する目的で必要なビジネス プロセスおよびインフラストラクチャ投資を計算できます。これらの投資テーマには、以下を含める必要があります。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:

  • ダウンタイムの回避。 機能停止がそもそも発生しなければ、機能停止復旧にかかる費用は発生しません。投資には、フォールト トレラントで冗長なハードウェアまたはインフラストラクチャの費用、分離された障害ポイント間でのワークロードの分散、予防的保守による計画されたダウンタイムが含まれます。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.

  • 復旧の自動化。 システム障害が発生したとき、自動的で透過的な復旧を使用すれば、ダウンタイムが顧客体験に悪影響を及ぼすことを大幅に軽減できます。Automating recovery. If a system failure occurs, you can greatly mitigate the impact of downtime on the customer experience through automatic and transparent recovery.

  • リソース利用率。 セカンダリまたはスタンバイ インフラストラクチャは、機能停止に備えて、アイドル状態のまま待機します。読み取り専用のワークロードに使用するか、すべての使用可能なハードウェア間でワークロードを分散することによって全体的なシステム パフォーマンスを向上することに活用できます。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.

特定の RTO および RPO の目標で、ダウンタイムの推定費用と組み合わせた、必要とされる利用可能時間および復旧投資は、時間の関数として示し、正当化できます。これにより、実際の機能停止中に、ダウンタイム経過時間に基づいてコストベースの判断ができます。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.

可用性正常性を監視するMonitoring availability health

運用上の観点からは、実際の機能停止中に、すべての関連する変数を検討して、ROI または機会費用をリアルタイムで計算するべきではありません。むしろ、スタンバイ インスタンスのデータ遅延を、予測される RPO のプロキシとして監視する必要があります。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.

また、機能停止が起こったときに、機能停止中に、根本原因を初期調査するのに時間をかけすぎないようにする必要があります。むしろ、復旧環境の正常性を確認することに重点を置き、以後の精密分析用には、詳細なシステム ログと、データの 2 次的なコピーを使用する必要があります。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.

障害復旧の計画Planning for disaster recovery

高可用性の取り組みには、機能停止を防ぐことが必要ですが、障害復旧の取り組みでは、機能停止後に高可用性を、再度、確立する目的で行う作業が重要です。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.

実際の機能停止が発生する前に、できる限り、障害復旧の手順と責任を確立する必要があります。アクティブな監視および通知に基づいて、自動化または手動のフェールオーバーおよび復旧計画を開始する判断は、事前に確立された RTO および RPO しきい値と結び付けられる必要があります。適切な障害復旧計画の範囲には、以下を含める必要があります。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:

  • 障害と復旧の詳細さ。 障害の場所と種類によって、データ センター、インフラストラクチャ、プラットフォーム、アプリケーション、ワークロードなどの、さまざまなレベルで修正処置を行うことができます。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.

  • 調査用資料。 ベースラインと最近の監視履歴、システム通知、イベント ログ、診断クエリは、すべて、適切な関係者が容易に入手可能である必要があります。Investigative source material. Baseline and recent monitoring history, system alerts, event logs, and diagnostic queries should all be readily accessible by appropriate parties.

  • 依存関係の調整。 アプリケーション スタック内で、また関係者間で、システムおよびビジネス上の依存関係は何でしょうか。Coordination of dependencies. Within the application stack, and across stakeholders, what are the system and business dependencies?

  • 決定樹。 事前設定され、繰り返し可能で、検証された決定樹。役割責任、障害振り分け、RPO および RTO 目標に関するフェールオーバー条件、および規定された復旧手順が含まれます。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.

  • 検証。 機能停止から回復する手順を行った後で、システムが通常動作に戻ったことを確認する目的で行う必要があることはなんでしょうか。Validation. After taking steps to recover from the outage, what must be done to verify that the system has returned to normal operations?

  • 文書化。 上記のすべての項目を、一連の文書に記録します。サード パーティ チームが、最小限の支援で復旧計画を実行できるように、十分に詳細かつ明快である必要があります。この種類の文書は、一般的には "操作指示書" と呼ばれます。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'.

  • 復旧リハーサル。 RTO 目標のベースライン予測を設定する目的で、頻繁に障害復旧計画を実施します。また、プライマリ実稼働サイトを、プライマリ サイトと各障害復旧サイトで、定期的に交替してホストすることを検討してください。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.

関連項目See also

概念Concepts

SharePoint Server 用の障害回復戦略を選ぶChoose a disaster recovery strategy for SharePoint Server

その他のリソースOther Resources

Azure Site Recovery で保護できるワークロードとはWhat workloads can you protect with Azure Site Recovery?

Azure Site Recovery を使用して障害復旧の多層 SharePoint アプリケーションをレプリケートするReplicate a multi-tier SharePoint application for disaster recovery using Azure Site Recovery