障害復旧を計画する (SharePoint Server 2010)
適用先: SharePoint Foundation 2010, SharePoint Server 2010
トピックの最終更新日: 2016-11-30
ここでは、Microsoft SharePoint Server 2010 環境の障害復旧戦略の選択における重要な決定事項について説明します。
この記事の内容
障害復旧の概要
障害復旧戦略を選択する
コールド スタンバイの計画
ウォーム スタンバイの計画
ホット スタンバイ データ センターの計画
障害復旧のシステム要件
障害復旧の概要
この記事では、障害復旧を、SharePoint Server をホストするデータ センターが使用できなくなった状況から復旧する機能と定義します。
SharePoint Server に使用する障害復旧戦略は、Active Directory ドメイン、Exchange Server、Microsoft SQL Server などの関連するインフラストラクチャの障害復旧戦略と協調している必要があります。協調した障害復旧戦略および計画を設計するために依存するインフラストラクチャの管理者と協力してください。
異なる場所にある別のファームを起動して稼働させる時間と緊急作業は、一般に、ホット スタンバイ、ウォーム スタンバイ、またはコールド スタンバイと呼ばれます。ここでは、これらの用語を次のように定義します。
ホット スタンバイ: 秒または分の単位で可用性を提供できる第 2 のデータ センター。
ウォーム スタンバイ: 分または時間の単位で可用性を提供できる第 2 のデータ センター。
コールド スタンバイ: 時間または日の単位で可用性を提供できる第 2 のデータ センター。
障害復旧は、システムにとって比較的コストのかかる要件の 1 つである場合があります。障害から使用可能になるまでの間隔が短いほど、また保護するシステムが多いほど、障害復旧ソリューションは複雑でコストがかかるようになります。ホットまたはウォーム スタンバイのデータ センターへの投資には、以下のコストが含まれます。
追加のハードウェアおよびソフトウェア。フェールオーバーおよび回復のためのカスタム スクリプトなど、通常、ソフトウェア アプリケーション間の運用の複雑さが増します。
運用面での複雑さの増加。
ホットまたはウォーム スタンバイのデータ センターを維持するコストを、ビジネス ニーズに基づいて評価する必要があります。障害後の可用性のレベルが、組織内のすべてのソリューションについて同じではない場合があります。異なるコンテンツ、サービス、またはファームに対して、異なるレベルの障害復旧を提供できます。たとえば、業務に対する影響が大きいコンテンツ、検索サービス、インターネット発行ファームなどです。
障害復旧は、情報技術 (IT) グループによりサービス レベル契約 (SLA) が提供され、顧客グループと共に予期される状況を設定する主要分野です。多くの IT 組織では、異なるチャージバック レベルと関連付けられたさまざまな SLA を提供しています。
サーバー ファーム間のフェールオーバーを実装するときは、最初にファーム内のコア ソリューションを展開して調整してから、障害復旧を実装してテストすることをお勧めします。
障害復旧戦略を選択する
ビジネス ニーズに応じて、SharePoint Server 環境の障害復旧を提供するさまざまな方法から選択できます。以下の例では、企業がコールド、ウォーム、またはホット スタンバイ障害復旧線戦略を選択する理由を示します。
コールド スタンバイ障害復旧戦略: ローカルおよび地域のオフサイト ストレージに定期的にベア メタル復旧をサポートするバックアップを送り、別の地域では緊急サーバー レンタルの契約を結んでいる。
利点:
通常、運用上の維持コストが最もかからないオプションです。
通常、障害が発生した後で物理サーバーを正しく構成する必要があるため、復旧コストのかかるオプションです。
欠点: 復旧に最も時間のかかるオプションです。
ウォーム スタンバイ障害復旧戦略: ローカルおよび地域の障害復旧ファームに仮想サーバー イメージを送ります。
利点: 通常、障害時に仮想サーバー ファームで必要な構成が少ないので、比較的コストのかからない復旧です。
欠点: 維持のためのコストと時間は非常に大きくなる場合があります。
ホットスタンバイ障害復旧戦略: 複数のデータ センターを運用しますが、コンテンツとサービスの提供は 1 つのデータ センターだけで行います。
利点: 普通、復旧が比較的高速です。
欠点: 構成と維持に非常にコストがかかる場合があります。
重要
どの障害復旧ソリューションを環境に実装したとしても、何らかのデータ損失が発生する可能性があります。
コールド スタンバイ データ センターの計画
コールド スタンバイ障害復旧シナリオでは、新しい場所に新しいファームをセットアップし (できれば、スクリプト化された展開を使用して)、バックアップを復元することで、復旧できます。または、コンピューター レベルでデータを保護し、各サーバーを個別に復元できる、Microsoft System Center Data Protection Manager 2007 などのバックアップ ソリューションからファームを復元することで復旧できます。ここでは、コールド スタンバイのシナリオで作成および復旧する方法の詳細な手順は説明しません。詳細については以下を参照してください。
ウォーム スタンバイ データ センターの計画
ウォーム スタンバイ障害復旧シナリオでは、定期的かつ頻繁にファームのサーバーの仮想イメージを作成し、それを第 2 の場所に送ることで、ウォーム スタンバイ ソリューションを作成できます。第 2 の場所では、イメージを簡単に構成および接続してファーム環境を再作成できる環境が必要です。
ここでは、ウォーム スタンバイ ソリューションの詳細な作成方法は説明しません。仮想ソリューションを使用してファームを展開する計画方法の詳細については、「仮想化を計画する (SharePoint Server 2010)」を参照してください。
ホット スタンバイ データ センターの計画
ホット スタンバイ障害復旧シナリオでは、フェールオーバー ファームをセットアップして、主ファームとは別のデータ センターで障害復旧を提供できます。別のフェールオーバー ファームを使用する環境には次のような特徴があります。
別の構成データベースおよびサーバーの全体管理コンテンツ データベースをフェールオーバー ファームで維持する必要があります。
すべてのカスタマイズを両方のファームに展開する必要があります。
注意
展開をスクリプト化し、同じ構成設定とカスタマイズを使用して主ファームとフェールオーバー ファームを作成することをおすすめします。詳細については、「Windows PowerShell を使用して SharePoint Server 2010 をインストールする」を参照してください。
更新を両方のファームに個別に適用する必要があります。
SharePoint Server のコンテンツ データベースは、問題なくフェールオーバー ファームに非同期にミラー化またはログ配布できます。
注意
SQL Server のミラーリングは単一のミラー サーバーにデータベースをコピーするためにしか使用できませんが、ログ配布は複数の 2 次サーバーに対して使用できます。
サービス アプリケーションは、ファームにログ配布できるかどうかが異なります。詳細については、後の「データ センター間でのサービス アプリケーションの冗長性」を参照してください。
SQL Server ログ配布を 1 つ以上の追加データ センターに構成する場合、このトポロジを多くのデータ センターで繰り返すことができます。
データ センター間の可用性を提供するために SAN レプリケーションまたは別のサポートされるメカニズムを使用できるかどうかは、SAN のベンダーに問い合わせてください。
次の図は、フェールオーバーの前のプライマリ ファームとフェールオーバー ファームを示しています。
フェールオーバー前のプライマリ ファームとフェールオーバー ファーム
.gif "フェールオーバー前のプライマリ フェールオーバー ファーム")
データ センター間でのサービス アプリケーションの冗長性
サービス アプリケーションをデータ センター間で使用できるようにするため、ファーム間で実行できるサービスについては、プライマリとセカンダリの両方のデータ センターからアクセスできる別のサービス ファームを用意することをお勧めします。
ファーム間で実行できないサービスについては、サービス ファーム自体の可用性を提供するには、サービス アプリケーションのデータ センター間の冗長性を提供する戦略はさまざまです。使用する戦略は以下に依存します。
使用されていない障害復旧ファームでサービス アプリケーションを実行することにビジネス価値があるかどうか。
サービス アプリケーションと関連付けられているデータベースをログ配布または非同期にミラー化できるかどうか。
サービス アプリケーションを読み取り専用データベースに対して実行できるかどうか。
以下では、各サービス アプリケーションに対して推奨される障害復旧戦略を説明します。サービス アプリケーションは戦略別のグループになっています。
ログ配布または非同期ミラー化を使用できるデータベース
サービス アプリケーションをセカンダリ ファームで最初に展開した後、以下のサービス アプリケーションをサポートするデータベースは非同期にミラー化するか、またはファーム間でログ配布ができます。
Managed Metadata Service アプリケーション
データベース: Managed Metadata Service
注意
タグ付けを使用している場合、障害復旧ファームで Managed Metadata Service アプリケーションを正常に使用するには、SharePoint Administration Toolkit に含まれる User Profile Replication Engine を実行する必要があります。詳細については、「User Profile Replication Engine の概要 (SharePoint Server 2010)」を参照してください。
PerformancePoint Services
データベース: PerformancePoint Service アプリケーション
Project Server Service アプリケーション
データベース: Draft、Published、Archive、Reporting
Project Server 2010 では、データベース間の同期が必要です。Project Server は、非同期レプリケーション メカニズム (非同期データベース ミラーリング、ログ配布、または非同期 SAN レプリケーション) を使用してファーム間で複製できますが、復旧の場合は、Project データベースが復元時に同期していることを確認する必要があります。
注意
Project Server データベースを障害復旧ファームにログ配布またはミラー化することをお勧めしますが、Project Server Service アプリケーションは読み取り専用データベースでは実行できません。したがって、フェールオーバーが済むまでは、Project Server Service アプリケーションを障害復旧ファームで実行しないことをお勧めします。障害復旧ファームで Project Server データベースを正常に同期するには、データベースに対してタイムスタンプまたはログ作成を構成する必要があります。
Secure Store Service アプリケーション
データベース: Secure Store
Usage and Health Data Collection Service アプリケーション
データベース: Logging
注意
Logging データベースはログ配布またはミラー化できます。ただし、障害復旧ファームでは Usage and Health Data Collection Service を実行しないこと、および Logging データベースをミラー化またはログ配布しないことをお勧めします。
Web Analytics Service アプリケーション
データベース: Staging、Reporting
注意
Web Analytics の Staging および Reporting データベースをログ配布またはミラー化することをお勧めします。ただし、フェールオーバーが済むまでは、Web Analytics Service アプリケーションを障害復旧ファームで実行しないことをお勧めします。
ログ配布または非同期にミラー化できないサービス アプリケーションとデータベース
以下のサービス アプリケーションはプライマリとフェールオーバーの両方のファームに展開する必要があり、ログ配布または非同期にミラー化することはできません。これらのサービス アプリケーションのほとんどについては、展開した後、フェールオーバー ファームがプライマリ ファームと同じ構成設定であることを確認することをお勧めします。プライマリ ファームでサービスに影響のある構成変更を行った場合は、フェールオーバー ファームを更新する必要があります。
Application Registry Service アプリケーション
データベース: Application Registry Service
Application Registry Service のデータベースのログ配布はサポートされません。
Business Data Connectivity Service アプリケーション
データベース: Business Data Connectivity
User Profile Service アプリケーション
データベース: Profile、Synchronization、Social Tagging
Profile、Synchronization、および Social Tagging データベースはログ配布できません。
User Profile Service アプリケーションの冗長性を提供するには、最初にプライマリとセカンダリの両方のデータ センターにサービス アプリケーションを展開する必要があります。
Profile および Synchronization データベースをセットアップするには、データベースのバックアップをセカンダリ データ センターに復元し、データ センターの User Profile Service アプリケーションに接続することをお勧めします。
プロファイルを同期するには、プライマリ ファームでプロファイル データを更新した後、SharePoint Administration Toolkit に含まれる User Profile Replication Engine を実行する必要があります。詳細については、「User Profile Replication Engine の概要 (SharePoint Server 2010)」を参照してください。
Microsoft SharePoint Foundation Subscription Settings Service アプリケーション
データベース: Subscription
注意
Subscription Settings データベースのログ配布はサポートされていません。
Access Services
データベース: なし
Excel Services
データベース: なし
Search
データベース: Crawl、Property、Search Administration
Search では、データベースとインデックスの完全な同期が必要です。この要件のため、Search は、非同期レプリケーション メカニズム (非同期データベース ミラーリング、ログ配布、または非同期 SAN レプリケーション) を使用してファーム間で複製することはできません。
フェールオーバー ファームで最新の検索を提供するには、セカンダリ ファームで検索を実行する必要があります。
重要
フェールオーバー ファームの Search Service アプリケーションは、セカンダリ ファームをアクティブにクロールするように設定する必要があります。フェールオーバー時には、フェールオーバーの Search Service アプリケーションを使用するように Web アプリケーションを構成する必要があります。
State Service
データベース: State
注意
State データベースのログ配布はサポートされません。
Visio Services
データベース: なし
Word Automation Services
データベース: Word Automation Services
Word Automation Services データベースのログ配布はサポートされません。
障害復旧のシステム要件
理想的なシナリオでは、フェールオーバー コンポーネントとシステムは、プライマリ コンポーネントとシステムに、すべての点で (プラットフォーム、ハードウェア、サーバー数) 一致します。少なくとも、フェールオーバー環境はフェールオーバーの間に予想されるトラフィックを処理できる必要があります。フェールオーバー サイトで対応できるのはユーザーの一部だけであることに注意してください。システムは少なくとも以下の点が一致している必要があります。
オペレーティング システムのバージョンとすべての更新プログラム
SQL Server のバージョンとすべての更新プログラム
SharePoint 2010 Products のバージョンとすべての更新プログラム
この記事では主に SharePoint 2010 Products の可用性について説明しましたが、システムのアップタイムはシステムの他のコンポーネントによっても影響を受けます。特に、次のことを行うようにしてください。
電源、冷却、ネットワーク、ディレクトリ、SMTP などのインフラストラクチャの依存性が完全に冗長であることを確認します。
ニーズに合った切り替えメカニズム (DNS かハードウェア負荷分散か) を選択します。