SharePoint Server 用の障害回復戦略を選ぶ
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
この記事での障害復旧とは、SharePoint Server ファームをホストするプライマリ データ センターが機能しなくなった場合に、その状況から復旧することです。 発生したイベントやその原因にかかわらず、データ センターの停止は、組織の障害復旧計画に定義された処置を実行に移すべき重大な事態です。 これはイベントの影響を受けていないデータ センターのコンピューター リソースを使って、完全に機能するファームを運用に移すことを意味します。
SharePoint Server 2019、2016、2013、およびそれらをサポートする SQL Server には、障害が発生した場合にビジネスに必要な復旧時間目標 (RTO) と復旧ポイント目標 (RPO) を満たす構成とコンテンツの回復オプションが用意されています。 これらの概念およびその他の障害復旧の概念については、「SharePoint Server での高可用性および障害回復の概念」をご覧ください。
概要
SharePoint Server ファームの効果的なディザスター リカバリー戦略は、組織のビジネス要件を満たすのに十分である必要があります。通常は、復旧時間目標 (RTO) と復旧ポイント目標 (RPO) の 2 つの手段を使用して表されます。 RTO と RPO の要件は、障害が発生した場合の組織のダウンタイム コストを決定することによって導き出されます。
重要
ベスト プラクティスとして、復旧戦略を策定して技術ソリューションを実装する前に、組織の RTO と RPO を明確にし、数値化することをお勧めします。 要件を達成する方法ではなく、要件の内容に焦点を当ててください。
ダウンタイムが与える影響はさまざまであるため、ダウンタイムのコストは業種ごとおよび業種内でも大きなばらつきがあります。 ビジネスの規模は、最も顕著な要素です。 しかし、原因はビジネス規模だけではありません。 測定値を設定すると、障害の性質と影響が明確になります。 大まかに言うと、重要なアプリケーションで障害が起きた場合は次のような損失が生じます。
アプリケーション サービスの損失。 ダウンタイムの影響は、アプリケーションおよびビジネスごとに異なります。
データの損失。 システムの停止によって起こり得るデータの損失は、法的および財務的に大きな影響を与える場合があります。
ほとんどの組織では、以前の種類の両方の損失からダウンタイム コストが発生しますが、ビジネスの性質によって、どの種類の損失が最大の影響を受けるかが決まります。 次の記事は、eWEEK の Chris Preimesberger によって作成された、データ センターのダウンタイムの財務効果を示しています。 計画外の IT ダウンタイムは、1 分あたり $5,000 のコストがかかる場合があります: レポート。
障害と見なされるデータ センターのシャットダウンが発生したとき、ほとんどの場合、回復しなければならないアプリケーションの 1 つは SharePoint 製品 です。 このため、ディザスター リカバリー計画に関する情報は含まれていませんが、別の場所で SharePoint Server ファームを復旧できるようにするオプションに重点を置いています。
障害の種類とその規模にかかわらず、ファームの復旧はスタンバイ データ センターの使用を伴います。
スタンバイ データ センターの復旧オプション
プライマリ データ センターでローカルの冗長なシステムおよびバックアップを障害から回復できない場合、スタンバイ データ センターが必要になります。 別の場所にある代替ファームを稼働させるための方策は、時間および緊急度別に、ホット スタンバイ、ウォーム スタンバイ、コールド スタンバイと呼ばれています。 この記事では、これらのファーム復旧データ センターを次のように定義します。
コールド スタンバイ 。 数時間から数日で可用性を提供できるセカンダリ データ センター。
ウォーム スタンバイ 。 数分から数時間で可用性を提供できるセカンダリ データ センター。
ホット スタンバイ 。 数秒から数分で可用性を提供できるセカンダリ データ センター。
これらのスタンバイ データ センターには、固有の特質および要件があり、関連する運用費や維持費が異なります。
コールド スタンバイの障害復旧戦略: ベア メタル回復を行うためのバックアップをローカルおよび地域のオフサイト ストレージに定期的に提供し、他の地域で緊急用のサーバーをレンタルする契約を締結している。
Pros: 通常、運用の観点から見ると、維持費が最も安価。 障害の発生後に物理サーバーを適切に構成する必要があるため、通常は復旧コストが高価。
Cons: 復旧に最も時間がかかる。
Azure Site Recovery のウォーム スタンバイの障害復旧戦略。
Pros: 復旧の際に仮想サーバー ファームを構成する必要がほとんどないため、通常は復旧コストが比較的安価。
Cons: 維持費が高価で、時間がかかる可能性がある。
ホット スタンバイの障害復旧戦略: 複数のデータ センターを運用しているが、1 箇所のデータ センターのみでコンテンツとサービスを提供している。
Pros: 通常、比較的短時間で復旧できる。
Cons: 構成コストおよび維持費が高価。
重要
上記のどの障害復旧ソリューションを適用する場合でも、いくらかのデータ損失が発生する可能性があります。
コールド スタンバイの復旧
コールド スタンバイのディザスター リカバリー シナリオでは、新しい場所に新しいファームを設定し (できればスクリプト化されたデプロイを使用して) バックアップを復元することで復旧します。 または、System Center - Data Protection Manager (DPM) などのバックアップ ソリューションを使用してファームを復元することで回復することもできます。 DPM では、コンピューターのオペレーティング システム レベルでデータを保護し、各サーバーを個別に復元できます。 この記事では、コールド スタンバイ シナリオについて、スタンバイ環境の作成方法や復旧方法などの詳細は扱っていません。 詳しくは、以下を参照してください。
ウォーム スタンバイの復旧
ウォーム スタンバイの障害復旧シナリオでは、代替データ センターにファームの複製を作成することによりウォーム スタンバイ環境を作成し、プライマリ ファームの完全バックアップと増分バックアップを使ってそれを定期的に更新します。
仮想ウォーム スタンバイ環境
仮想化は、有効でコスト効果の高いウォーム スタンバイ復旧 ソリューションを提供します。 Hyper-V をインハウス ソリューションとして使用するか、Azure をホストされたソリューションとして使用して、復旧に必要なインフラストラクチャを提供できます。 詳細については、「Azure でのSQL Server Always On可用性グループを使用した SharePoint Server のデプロイ」を参照してください。
ホット スタンバイの復旧
ホット スタンバイの障害復旧シナリオでは、スタンバイ データ センターにフェールオーバー ファームを設定して、プライマリ ファームがオフラインになったら、ほとんど間髪を入れずに処理を引き継ぐことができるようにします。 別個のフェールオーバー ファームがある環境には、次の特徴があります。
別個の構成データベースとSharePoint サーバーの全体管理 Web サイトのコンテンツ データベースをフェールオーバー ファームで管理する必要があります。
両方のファームにカスタマイズをすべて展開する必要があります。
ヒント
2 箇所のファーム間の整合性を維持し、エラーの発生を削減するため、スクリプト化された展開を使用して、同じ構成設定とカスタマイズを適用してプライマリとフェールオーバー ファームを作成することをお勧めします。
オペレーティング システム、SQL Server、SharePoint Serverのソフトウェア更新プログラムを両方のファームに適用して、ファーム間で一貫した構成を維持する必要があります。
SharePoint Server のコンテンツ データベースをフェールオーバー ファームにコピーするには、非同期ミラーリング、可用性グループのレプリカでの非同期コミット、またはログ配布を使用できます。
注:
SQL Server のミラーリングでは、データベースを単一のミラー サーバーにしかコピーできませんが、ログ配布は複数のセカンダリ サーバーに対して実行できます。
SQL Server データベース ミラーリング機能は将来のバージョンで削除されます。 新しいデプロイでは、この機能を使用しないことをお勧めします。 現在この機能を使用しているアプリケーションを変更するようにご計画ください。 代わりにAlways On可用性グループを使用します。
サービス アプリケーションは、ファームにログ配布できる場合とそうでない場合があります。 詳細については、後述の「サービス アプリケーションの冗長性」を参照してください。
1 つ以上の追加のデータ センターへの SQL Server のログ配布を構成する場合は、ホットスタンバイのファーム トポロジを複数のデータ センターで繰り返すことができます。
重要
障害復旧でフェールオーバー アプローチを使用する場合は、使用可能なネットワーク帯域幅と待機時間が重要な検討事項になります。 SQL データベースに SAN レプリケーションを使用できるかどうか、または他のサポートされているメカニズムを使用して、データ センター間でホット スタンバイ レベルの可用性を提供できるかどうかを、SAN ベンダーに問い合わせて判断することをお勧めします。 SharePoint サーバーに SAN レプリケーションを使用することはサポートされていないことに注意してください。
サービス アプリケーションの冗長性
サービス アプリケーションに対するデータ センターでの可用性を実現するには、ファーム間で実行できるサービスについては、プライマリおよびセカンダリのどちらのデータ センターからでもアクセスできる別個のサービス ファームを運用することをお勧めします。
ファーム間で実行できないサービスについて、サービス ファーム自体の可用性を実現する場合、データ センターでサービス アプリケーションの冗長性を実現する戦略にはさまざまなものがあります。 使用する戦略は、次の事項によって左右されます。
サービス アプリケーションが使用されていないとき、障害復旧ファームでそれを実行することにビジネス価値があるかどうか。
サービス アプリケーションに関連付けられているデータベースをログ配布、非同期ミラーリング、または非同期コミットを使用してレプリケートできるかどうか。
サービス アプリケーションを読み取り専用データベースに対して実行できるかどうか。
ウォームまたはホット スタンバイ データ センターを使用する障害復旧ソリューションを設計する前に、「サポートされている SharePoint データベース用の高可用性と障害回復のオプション」の記事を参照してください。
復旧のためのシステム要件
理想的なシナリオでは、フェールオーーバーとプライマリのコンポーネントおよびシステムは、プラットフォーム、ハードウェア、サーバー数などのあらゆる点で一致します。 少なくとも、フェールオーバー環境では、フェールオーバーの実行時に予想されるトラフィックを処理できる必要があります。 ただし、フェールオーバー サイトは、必ずしもすべてのユーザーにサービスを提供する必要がない点に注意してください。 フェールオーバーとプライマリのシステムは、少なくとも次の点で一致している必要があります。
オペレーティング システムのバージョンとすべての更新プログラム
SQL Server バージョンとすべての更新プログラム
SharePoint Server バージョンとすべての更新プログラム
上記の要件に加えて、ファームの復旧時間は、設備およびインフラストラクチャ コンポーネントの可用性の影響も受けます。 次の要件が満たされていることを確認してください。
電源、冷却、ネットワーク、ディレクトリ、および SMTP が完全に冗長化されている。
ニーズに合った切り替えメカニズム (DNS またはハードウェア負荷分散) の選択。
関連項目
概念
SharePoint Server での高可用性および障害回復の概念
その他のリソース
Azure Site Recovery で保護できるワークロードとは
Azure Site Recovery を使用して障害復旧の多層 SharePoint アプリケーションをレプリケートする