障害復旧の計画 (SharePoint Foundation 2010)
適用先: SharePoint Foundation 2010
この記事では、Microsoft SharePoint Foundation 2010 環境での障害復旧の戦略を選択する際に検討する主な内容について説明します。
この記事の内容
障害復旧の概要
この記事では、SharePoint Foundation をホストするデータ センターが使用不能な状況になった場合に、その状況から復旧できることを障害復旧と定義します。
SharePoint Foundation で使用する障害復旧の戦略は、Active Directory ドメイン、Exchange Server、Microsoft SQL Server などの関連インフラストラクチャの障害復旧の戦略と連携する必要があります。これらのインフラストラクチャの管理者も交えて、そうした障害復旧の戦略と計画を立ててください。
別の場所で別のファームを稼働させるために必要な時間と処理の違いによって、通常、ホット スタンバイ、ウォーム スタンバイ、またはコールド スタンバイと呼ばれます。ここでは、これらの用語を次のように定義します。
ホット スタンバイ 数秒から数分で再び利用可能になるセカンド データ センター。
ウォーム スタンバイ 数分から数時間で再び利用可能になるセカンド データ センター。
コールド スタンバイ 数時間から数日で再び利用可能になるセカンド データ センター。
障害復旧は、システムにとってコストのかかる要求の 1 つになることがあります。障害の発生から再び利用可能になるまでの間隔が短く、保護するシステム数が多いほど、障害復旧ソリューションは複雑で高コストになる傾向があります。ホット スタンバイまたはウォーム スタンバイのデータ センターに投資する場合、次のコストがかかります。
追加のハードウェアとソフトウェア。通常は、こうした要素により、ソフトウェア アプリケーション間での操作 (フェールオーバーと復旧用のカスタム スクリプトなど) がいっそう複雑になります。
追加操作の複雑さ。
ホット スタンバイまたはウォーム スタンバイのデータ センターを維持するコストは、ビジネス ニーズに基づいて評価する必要があります。組織内のすべてのソリューションで障害発生後に同じレベルの可用性が要求されることはまずありません。コンテンツ、サービス、またはファームの種類 (ビジネスに大きな影響を与えるコンテンツ、検索サービス、インターネット公開用のファームなど) によって異なるレベルの障害復旧を提供できます。
障害復旧は、情報技術 (IT) グループによりサービス レベル契約 (SLA) が提供され、顧客グループと共に予期される状況を設定する主要分野です。多くの IT 組織では、異なるチャージバック レベルと関連付けられたさまざまな SLA を提供しています。
サーバー ファーム間でのフェールオーバーを実装する場合は、最初に、ファームにコア ソリューションを展開して調整し、その後で、障害復旧を実装してテストすることをお勧めします。
障害復旧の戦略の選択
SharePoint Foundation 環境に障害復旧を提供するアプローチは、ビジネス ニーズに応じて、多くの中から選択できます。次の例に、企業が障害復旧の戦略として、コールド スタンバイ、ウォーム スタンバイ、またはホット スタンバイを選択する理由を示します。
コールド スタンバイの障害復旧の戦略: ベア メタル回復をサポートするバックアップをローカルおよび地域のオフサイト ストレージに定期的に提供し、緊急時には他の地域でサーバーをレンタルするための契約を結びます。
長所:
通常、運用上、メンテナンス コストが最も安価。
障害発生後、物理サーバーを正しく構成する必要があるため、通常は復旧コストが高価。
短所: 復旧するまでの時間が最長。
ウォーム スタンバイの障害復旧の戦略: ローカルおよび地域の障害復旧ファームに仮想サーバー イメージを提供します。
長所: 仮想サーバー ファームは、復旧時に構成をほとんど必要としないため、通常、復旧コストは比較的安価。
短所: メンテナンス コストが非常に高価で、かつ長時間を要する可能性がある。
ホット スタンバイの障害復旧の戦略: 複数のデータ センターを運用しますが、1 箇所のデータ センターのみを通じてコンテンツとサービスを提供します。
長所: 通常、比較的短時間で復旧できる。
短所: 構成コストとメンテナンス コストがきわめて高価。
重要
いずれの障害復旧ソリューションを環境に実装する場合でも、少なからず、データ消失が発生する可能性があります。
コールド スタンバイのデータ センターの計画
コールド スタンバイの障害復旧シナリオでは、新しいファームを新しい場所に設定し、(なるべくスクリプト化された展開を使用して)、バックアップを復元することで復旧が行えます。または、コンピューター レベルでデータを保護して各サーバーを個別に復元できる Microsoft System Center Data Protection Manager 2007 のようなバックアップ ソリューションからファームを復元することによって復旧を行うこともできます。この記事には、コールド スタンバイのシナリオでの作成および復旧方法の詳細な説明はありません。詳細については、以下を参照してください。
ウォーム スタンバイのデータ センターの計画
ウォーム スタンバイの障害復旧シナリオでは、予備の場所に配置するファーム内のサーバーの仮想イメージを一貫性を持って頻繁に作成することで、ウォーム スタンバイのソリューションを作成できます。予備の場所には、そうしたイメージを容易に構成および結合してファームの環境を再作成できる環境を利用可能な状態で用意しておく必要があります。
この記事では、ウォーム スタンバイのソリューションの作成方法について詳しく説明しません。仮想ソリューションを使用したファーム展開を計画する方法の詳細については、「仮想化を計画する (SharePoint Foundation 2010)」を参照してください。
ホット スタンバイのデータ センターの計画
ホット スタンバイの障害復旧シナリオでは、プライマリ ファームから分離されたデータ センターで障害復旧を提供するようにフェールオーバー ファームを設定できます。別個のフェールオーバー ファームを備えた環境には次の特徴があります。
別個の構成データベースとサーバーの全体管理コンテンツ データベースは、フェールオーバー ファームで保守する必要があります。
カスタマイズは、両方のファームにすべて展開する必要があります。
注意
スクリプト化された展開で同じ構成設定とカスタマイズを使用して、プライマリおよびフェールオーバー ファームを作成することをお勧めします。
更新プログラムは、両方のファームに個々に適用する必要があります。
SharePoint Foundation コンテンツ データベースは、フェールオーバー ファームへの非同期でのミラー化またはログ配布を正しく実行できます。
注意
SQL Server のミラーリングでは、データベースを単一のミラー サーバーにしかコピーできませんが、ログ配布は複数のセカンダリ サーバーに対して実行できます。
サービス アプリケーションは、ファームにログ配布できるかどうかが異なります。詳細については、後述の「データ センター全体でのサービス アプリケーションの冗長性」を参照してください。
1 つ以上の追加のデータ センターへの SQL Server のログ配布を構成すると、このトポロジを多数のデータ センター間で繰り返すことができます。
データ センター全体での可用性を提供するために、SAN のレプリケーションまたは他のサポートされているメカニズムのどちらを使用するかについては、SAN ベンダーに問い合わせてください。
次の図は、フェールオーバー前のプライマリ ファームとフェールオーバー ファームを示しています。
フェールオーバー前のプライマリ ファームとフェールオーバー ファーム
.gif "フェールオーバー前のプライマリ フェールオーバー ファーム")
データ センター全体でのサービス アプリケーションの冗長性
サービス アプリケーションに対してデータ センター全体での可用性を提供する場合、クロスファームで実行できるサービスについては、プライマリおよびセカンダリ データ センターの両方からアクセスできる別個のサービス ファームを実行することをお勧めします。
クロスファームで実行できないサービスがあり、サービス ファーム自体に可用性を提供する場合、データ センター全体での冗長性をサービス アプリケーションに提供する戦略にはさまざまなものがあります。どのような戦略を使用するかは、次の点によって異なります。
未使用のサービス アプリケーションを障害復旧ファームで実行することにビジネス価値があるかどうか。
サービス アプリケーションに関連付けられているデータベースのログ配布、または非同期でのミラー化を実行できるかどうか。
サービス アプリケーションを読み取り専用データベースに対して実行できるかどうか。
次のセクションでは、各サービス アプリケーションに推奨される障害復旧の戦略について説明します。サービス アプリケーションは戦略ごとにグループ化しています。
ログ配布または非同期でのミラー化を実行できるデータベース
最初に、サービス アプリケーションがセカンダリ ファームに展開された後、ファーム間で、次のサービス アプリケーションをサポートするデータベースの非同期でのミラー化またはログ配布を実行できます。
Application Registry Service アプリケーション
データベース: Application Registry Service
Business Data Connectivity Service アプリケーション
データベース: Business Data Connectivity
Usage and Health Data Collection Service アプリケーション
データベース: Logging
注意
Logging データベースは、ログ配布やミラー化を実行できます。ただし、Usage and Health Data Collection Service は、障害復旧ファームで実行しないことをお勧めします。また、Logging データベースのミラー化やログ配布を実行しないこともお勧めします。
ログ配布または非同期でのミラー化を実行できないサービス アプリケーションとデータベース
以下のサービス アプリケーションは、プライマリ ファームとフェールオーバー ファームの両方に展開する必要があり、ログ配布や非同期でのミラー化は行えません。これらのサービス アプリケーションのほとんどについては、それらを展開したうえでフェールオーバー ファームの設定がプライマリ ファームと同じであるか確認することをお勧めします。サービスに影響する構成変更がプライマリ ファームで行われた場合は、フェールオーバー ファームを更新する必要があります。
Microsoft SharePoint Foundation Subscription Settings Service アプリケーション
データベース: Subscription Settings
注意
Subscription Settings データベースのログ配布はサポートされていません。
障害復旧のためのシステム要件
理想的なシナリオでは、フェールオーバー側とプライマリ側のコンポーネントおよびシステムが、プラットフォーム、ハードウェア、サーバー数といったすべての点で一致します。少なくとも、フェールオーバー環境ではフェールオーバー時に想定されるトラフィックを処理できる必要があります。ただし、その場合は一部のユーザーしかフェールオーバー サイトによるサービスを利用できない可能性があることに注意してください。双方のシステムは、少なくとも次の点で一致している必要があります。
オペレーティング システムのバージョンとすべての更新プログラム
SQL Server のバージョンとすべての更新プログラム
SharePoint 2010 Productsのバージョンとすべての更新プログラム
この記事では、主に SharePoint 2010 Productsの可用性について説明しましたが、システムの稼働時間は、システムの他のコンポーネントの影響も受けます。特に、次のことを確実に行います。
電力装置、冷却装置、ネットワーク、ディレクトリ、SMTP などのインフラストラクチャの依存性が完全に冗長化されていることを確認します。
ニーズを満たす切り替えメカニズムとして、DNS またはハードウェア負荷分散のどちらかを選択します。