可用性を計画する (Office SharePoint Server)

  • [アーティクル]

この記事では、SharePoint 製品およびテクノロジ環境での一般的な可用性、コスト、および可用性に関する課題と、この環境で使用できる戦略およびソリューションについて説明します。ファームで Microsoft Office SharePoint Server 2007 を実行している場合は、このペーパーをお読みください。この記事に付属の「Model: Office SharePoint Server 2007 Availability (英語)」(https://go.microsoft.com/fwlink/?linkid=122369&clcid=0x411) をダウンロードして印刷することもできます。これは、この記事の内容をポスターサイズにまとめた要約です。

可用性の概要

可用性とは、SharePoint 製品およびテクノロジ環境が使用可能であるとユーザーが認識する度合いです。可用性を確保するとは、システムに回復力があること、つまり、サービスに影響するインシデントがあまり発生せず、そのようなインシデントが発生しても、迅速で効果的な処置が取られることを意味します。 可用性戦略は、ユーザーが認識する予定および予定外のダウンタイムを最小化します。

可用性の最も一般的な評価基準の 1 つとして、アップタイプのパーセンテージを **9 の個数で表したものがあります。つまり、ある特定のシステムが稼働している時間の割合です。たとえば、稼働率が 99.999% のシステムは、可用性が "ファイブ ナイン" であると言います。

以下の表は、9 の数と、それに対応する時間数を示しています。

許容される稼働率 1 日あたりの停止時間 1 か月あたりの停止時間 1 年あたりの停止時間

95

72.00 分

36 時間

18.26 日

99

14.40 分

7 時間

3.65 日

99.9

86.40 秒

43 分

8.77 時間

99.99

8.64 秒

4 分

52.60 分

99.999

0.86 秒

26 秒

5.26 分

発生する可能制があるダウンタイムの合計時間に関して、経験に基づいて推測できる場合は、次の数式を使用して、1 年、1 か月、または 1 週間の稼働率を計算することができます。

% 稼働率/年 = 100 - (8760 - 1 年あたりの停止時間の合計値)/8760

% 稼働率/月 = 100 - ((24 X その月の日数) - そのカレンダー月の停止時間の合計値)/(24 X その月の日数)

% 稼働率/週 = 100 - (168 - その週の停止時間の合計値)/168

可用性ではないもの

可用性は、データの保護および復元ではなく、災害復旧でもありませんが、これらは関連する概念であり、高可用性システムにはデータ保護および災害復旧計画が必要です。データの保護および復元は、次のような特定のビジネス ニーズに基づく一般的なビジネス ニーズです。

  • 複数のバージョンのアイテムまたはサイトを維持し、表示できるようにする。

  • 誤って削除したアイテムまたはサイトを復旧できるようにする。

  • 法律、規制、またはビジネス上の理由により、データをアーカイブする。

  • 予期しないハードウェアまたはソフトウェア障害が発生した際に、システムを復元する。

さらに、可用性はビジネス継続性管理 (BCM) ではありません。BCM は、危機を管理するためにあらかじめ設定しておくビジネスの意思決定、プロセス、およびツールから成ります。危機には、地方、地域、または全国的な事象などがあり、特定のビジネスだけに関連する危機もあります。

SharePoint 製品およびテクノロジの可用性およびデータ保護管理戦略を技術的な BCM プランの一部とすることもできますが、全体的な BCM プランは、次のような要素を含んだ、はるかに包括的なものでなければなりません。

  • 明確に文書化された手順。

  • 主要なビジネス記録のオフサイトでの保管。

  • 明確に指定された連絡先。

  • 継続的なスタッフ トレーニング。

  • オフサイト回復メカニズム。

可用性のコスト

可用性は、よりコストの高いシステム要件の 1 つです。可用性のレベルが高いほど、また、保護するシステムが多いほど、可用性ソリューションは複雑でコストのかかるものになります。可用性に投資するときには、次のようなコストが含まれます。

  • 追加のハードウェアおよびソフトウェア。多くの場合、フェイルオーバーと復元のためのカスタム スクリプトなど、ソフトウェア間の複雑な操作が伴います。

  • 操作の複雑さの増加。

可用性を確保するためのコストは、ビジネス ニーズに基づいて評価する必要があります。組織内のすべてのソリューションに同じレベルの可用性が必要というわけではありません。サイトごと、サービスごと (検索、ビジネス インテリジェンスなど)、またはファームごとに異なるレベルの可用性を提供できます。

可用性は、情報技術 (IT) グループがサービス レベル契約 (SLA) を提供して、顧客グループの期待を設定する主要分野です。多くの IT 組織は、さまざまなチャージバック レベルと関連付けられたさまざまな SLA を提供しています。

注意

可用性を計算する際、ほとんどの組織は、計画的な保守活動の時間を除外または追加します。

SharePoint 製品およびテクノロジにおける可用性の課題

SharePoint 製品およびテクノロジを導入する際、可用性を提供するために次のような点が課題となります。

  • パッチを適用するときや、ファームをアップグレードする間、ファームを使用できません。

  • 複数のサーバーにインデックス ロールをインストールしても、インデックス サーバーの冗長性は確保できません。インデックス サーバーの損失から復旧するには、サーバーを再インストールして、バックアップから復元するか、コンテンツを再クロールしてわずかに古い結果を利用する必要があります。または、「ファーム内部での検索の可用性」と「ファーム間での検索の可用性」で説明されている技法のいずれかを使用して、検索の復旧にかかる所要時間を短縮することができます。

  • SharePoint 製品とテクノロジは、Microsoft SQL Server 2005 データベースのミラーリングに対応していません。SQL Server のミラーリングを SharePoint の可用性の技法として使用することをお勧めしますが、その場合は追加の自動化が必要になります。

可用性を考慮すべきとき

可用性要件は、SharePoint ソリューションのコア設計の一部として考慮することを推奨します。ソリューションの導入後に、強化された可用性を提供することもできます。実施面では、ファームにコア ソリューションを導入して調整した後、可用性ソリューションをテストすることを推奨します。

可用性要件の決定

サイト、サービス、またはファームの停止時間に対する組織の許容度を判断するには、サイト、サービス、またはファームに関する以下の質問に答えてください。

  • サイト、サービス、またはファームが利用できなくなった場合、組織の従業員は任務を果たすことができなくなりますか。

  • サイト、サービス、またはファームが利用できなくなった場合、業務および顧客トランザクションが停止し、業務および顧客の損失が発生しますか。

どちらかの質問に「はい」と答えた場合は、可用性ソリューションに投資する必要があります。

可用性戦略の選択

可用性を強化するためのさまざまなアプローチから選ぶことができます。

  • コンポーネントのフォールト トレランス。

  • ファーム内のサーバー ロールとデータベースとの間の冗長性とフェイルオーバー。

  • サーバー ファーム間の冗長性とフェイルオーバー。

可用性のシステム要件

フェイルオーバー コンポーネントおよびシステムが、プラットフォーム、ハードウェア、サーバー数など、あらゆる点でプライマリ コンポーネントおよびシステムと一致しているのが理想的なシナリオです。少なくとも、フェイルオーバー環境では、フェイルオーバー中の予想されるトラフィックを処理できる必要があります。フェイルオーバー サイトで処理できるのはユーザーの一部にすぎません。2 つのシステムは、少なくとも以下の点で一致している必要があります。

  • オペレーティング システムのバージョンとすべてのアップデート

  • SQL Server のバージョンとすべてのアップデート

  • SharePoint 製品およびテクノロジのバージョンとすべてのアップデート

この記事では、主に SharePoint 製品およびテクノロジの可用性について説明しますが、システムの稼働時間はシステム内のその他のコンポーネントによって影響されます。特に、以下の点を考慮してください。

ファーム内部での可用性

ファーム内部での可用性をサポートするには、フォールト トレラントなコンポーネント、冗長サーバー ロール、およびクラスタリング、データベース ミラーリング、またはその両方によるデータベース可用性のサポートを導入することを計画します。

コンポーネントのフォールト トレランス

どのようなシステムでも、ハードウェア ベンダーと協力して、RAID (Redundant Array of Independent Disks) 配列など、システムに適したフォールトトレラントなハードウェアを調達することを推奨します。推奨事項については、「パフォーマンスと容量を計画する (Office SharePoint Server)」を参照してください。

コンポーネントのフォールト トレランスを計画するときは、以下の点を考慮してください。

  • サーバー内のすべてのコンポーネントの完全な冗長性が可能でない場合や現実的でない場合があります。冗長性を高めるには、追加のサーバーを使用してください。

  • インデックス サーバー ロールを冗長にすることはできないので、インデックス サーバー ロールについてはコンポーネントの冗長性を考慮してください。

  • 冗長性を最大化するには、サーバーに複数の電源装置があり、複数の電源に接続されていることを確認してください。

ファーム内のサーバー ロール間の冗長性とフェイルオーバー。

SharePoint 製品およびテクノロジは、容量を増加してパフォーマンスを向上させたり、基本的な可用性を提供したりする目的で、ファーム内の冗長コンピュータでのサーバー ロールの実行 (つまり、スケールアウト) をサポートします。容量とパフォーマンスにより、ファーム内のサーバー数とサーバーのサイズの両方が決まります。基本的な要件を満たした後、サーバーを追加して、サービスの全体的な可用性を高めることもできます。

単一サーバー ファーム内の冗長性

単一ファームの可用性

次の表に、SharePoint サーバーの全体管理 Web サイトの [サーバーのサービス] ページにリストされている、SharePoint 製品とテクノロジ環境でのサーバー ロールおよびサービスと、ファーム内のそれぞれで使用できる基本的な冗長性戦略について示します。

サーバー上のサービス ファーム内の基本的冗長性戦略

Web サーバー

複数のサーバーに導入して、ソフトウェアまたはハードウェア ロード バランシングを使用してロード バランスします。

中規模サーバー ファームの Web サーバー (Web アプリケーションおよび検索クエリ サービス)

複数のサーバーに導入します。

検索インデックス

複数のサーバーに導入して、冗長にすることはできません。別の可用性戦略を使用する必要があります。詳細については、「ファーム内部での検索の可用性」を参照してください。

Excel 計算

複数のサーバーに導入します。

Project アプリケーション

複数のサーバーに導入します。

詳細については、「冗長性を計画する (Office SharePoint Server)」を参照してください。

単一ファームのデータベース可用性戦略

ファーム内でのデータベース可用性は、SQL Server クラスタリングまたは SQL Server 高可用性ミラーリング (同期ミラーリングとも呼ばれる) を使用することで確保できます。

クラスタリング フェイルオーバー クラスタリングは、SQL Server の完全なインスタンスの可用性をサポートします。フェイルオーバー クラスタは、1 基以上のノードまたはサーバーと、2 基以上の共有ディスクの組み合わせです。フェイルオーバー クラスタのインスタンスは、単一のコンピュータと見なされますが、現在のノードが使用できなくなった場合に、1 つのノードから別のノードにフェイルオーバーする機能を備えています。

Office SharePoint Server 2007 はクラスタを全体として参照するため、フェイルオーバーは SharePoint 製品とテクノロジの側から見て自動的に、かつシームレスに実行されます。

同期データベース ミラーリング データベース ミラーリングは、プリンシパル データベースのトランザクション ログ バッファがディスクに書き込まれるたびに、トランザクションをプリンシパル データベースおよびサーバーからミラー データベースおよびサーバーに直接送信することで、可用性をサポートします。高可用性データベース ミラーリング (自動フェイルオーバー付き高安全性モードとも呼ばれる) の使用をお勧めします。高可用性データベース ミラーリングには、プリンシパル、ミラー、およびミラーリング監視、という 3 つのサーバー インスタンスが関与します。ミラーリング監視サーバーを使用することで、SQL Server はプリンシパル サーバーからミラー サーバーに自動的にフェイルオーバーできます。プリンシパル データベースからミラー データベースへのフェイルオーバーには、通常、数秒かかります。

それぞれのテクノロジには利点と欠点があります。クラスタリングの方が実装は簡単ですが、コストがかかる場合があります。SQL Server のミラーリングは、Microsoft Office Project Server 2007 データベースではサポートされていません。

次の表に、フェイルオーバー クラスタリングと SQL Server 高可用性ミラーリングの比較を示します。

SQL Server フェイルオーバー クラスタリング SQL Server 高可用性ミラーリング

障害時、ミラーが直ちに引き継ぎます。

障害時、ミラーが直ちに引き継ぎます。

トランザクションの一貫性。

トランザクションの一貫性。

トランザクションの同時性。

トランザクションの同時性。

最短時間で回復 (数秒から数分)。

回復時間がわずかに長い (数秒から数分)。

障害は、データベース ノードによって自動的に検出されます。SharePoint 製品とテクノロジはクラスタを参照するので、SharePoint 製品とテクノロジから見ると、フェイルオーバーはシームレスかつ自動的に行われます。

SharePoint 製品およびテクノロジのフェイルオーバーを達成するには、スクリプティングが必要。

ストレージはクラスタ内の複数のノードで共有されるので、ストレージの障害は保護されません。

プリンシパルとミラーの両方のデータベース サーバーがローカル ディスクに書き込むので、ストレージの障害を保護します。

より高価な共有ストレージが必要。

安価な直接接続ストレージ (DAS) を使用可能。

同じサブネット。

SQL Server および Web サーバー間で最大 1 ミリ秒 (ms) の待ち時間。

SQL Server の単純復旧モデルを使用できますが、クラスタが失われた場合に唯一使用可能な回復ポイントは、最後の完全バックアップになります。

SQL Server の完全復旧モデルが必要。

パフォーマンスのオーバーヘッドなし。

トランザクション待ち時間が発生します。メモリとプロセッサのオーバーヘッドが増加します。

運用上の負担は最小限。

スクリプティングや SQL Server のエイリアスのセットアップなど、運用上の負担が増加。

クラスタリングの使用方法の詳細については、「SQL Server のクラスタ化を使用して単一のファーム内での可用性を構成する」を参照してください。

同期ミラーリングの使用方法の詳細については、「SQL Server のデータベース ミラーリングを使用して単一のファーム内で可用性を構成する」と「データベース ミラーリングを使用する (Office SharePoint Server) (ホワイト ペーパー)」を参照してください。

単一のファームとして構成された、近距離のデータ センター間の冗長性とフェイルオーバー ("ストレッチド" ファーム)

一部の企業では、高帯域幅で接続された複数のデータ センターが近距離にあり、それらを単一のファームとして構成することができます。これを "ストレッチド" ファームといいます。ストレッチド ファームの場合、SQL Server と Web サーバー間の待ち時間は片道 1 ミリ秒未満でなければならず、少なくとも 1 ギガビット/秒の帯域幅が必要です。

  • このシナリオでは、同期ミラーリングを使用することによって、SharePoint データベースの冗長性を提供することができます。ストレッチド ファーム内では、構成データベースとコンテンツ データベースをミラー化できます。一社でのストレッチド ファームの使用のケース スタディについては、「データベース ミラーリングを使用した SharePoint の高可用性に関するケース スタディ (ホワイト ペーパー)」を参照してください。

  • SAN ベンダーと協議して、SAN レプリケーションまたは別のサポートされるメカニズムを使用して、地理的に分散しているサーバー クラスタ上で実行している SQL Server など、データ センター間の可用性を提供できるかどうかを判断してください。SAN レプリケーション ソリューションによって柔軟なレベルの同時性とトランザクションの一貫性を実現できることを確認してください。

ストレッチド ファーム内では、SSP を実行しているアプリケーション サーバーのフォールト トレランスを以下の方法によって提供することができます。

  • 複数のクエリ サーバー

  • Excel Calculation Services を実行している複数のサーバー

インデックス サーバーは、このシナリオでの単一障害点です。検索をバックアップして復元できるほか、回復時の検索の流れがきわめて重要な場合は、フェイルオーバー SSP ファームを使用することもできます。詳細については、「ファーム内部での検索の可用性」を参照してください。

Project Server は、このシナリオでのもう 1 つの単一障害点です。Project Server データベースのバックアップと復元を計画してください。

"ストレッチド" ファーム

"ストレッチ" ファーム

ファーム内部での検索の可用性

インデックス サーバー ロールをファーム内で冗長にすることはできません。フェイルオーバー後の検索の流れに対する業務上のニーズは、ソリューションの論理的アーキテクチャを決定するために役立ちます。

フェイルオーバー後、直ちに検索の流れと可用性が必要でない場合は、検索 SSP をフェイルオーバー サイトにバックアップして復元できます。

迅速な検索の流れと可用性が必要な場合は、次のどちらかの方法を使用できます。

  • 2 つの同一の SSP を持つ単一ファーム アーキテクチャ。

    注意

    迅速な検索の流れと可用性が必要となり、プロファイルを使用している場合、フェールオーバー SSP のプロファイルは、プライマリ SSP のプロファイルと同期されません。最初にインポートされた時点での状態になります。すべての SSP 上のプロファイルの同期を維持するには、SharePoint Administration Toolkit x86 (英語) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x411) または SharePoint Administration Toolkit x64 (英語) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x411) に含まれている User Profile Replication Engine ツールを使用する必要があります。詳細については、「User Profile Replication Engine (Office SharePoint Server)」を参照してください。

  • 検索とその他の SSP をホストする集中ペアレント ファーム。中央ファームの検索サービスが、他のすべてのファームのコンテンツをクロールします。このアーキテクチャを使用して、1 つまたは複数のファームをサポートできます。

2 つの SSP を持つ単一ファーム

次のアーキテクチャは、インデックス サーバーの障害を保護します。このトポロジでは、両方の SSP が同じルールを使用して、同じコンテンツをクロールします。フェイルオーバー SSP は、フェイルオーバーが発生するまで、プライマリ Web サイトに接続されません。

2 つの共有サービス プロバイダを持つ単一ファーム

2 つの SSP を持つファーム

このトポロジには、以下の制限があります。

大きなデータ セットを適切なタイミングでクロールできるかどうかは、インデックス サーバーと Web サーバー間の待ち時間と帯域幅など、いくつかの要素に左右されます。

帯域幅が限られた環境では、このトポロジによってパフォーマンスが大幅に低下することがあります。2 倍のコンテンツをクロールすることで、クロール対象のコンテンツ リポジトリの負荷が増えて、リポジトリのパフォーマンスに影響することがあります。また、インデックスを最新に保つ検索機能にも悪影響を及ぼす可能性があります。

集中 SSP ファーム

次のアーキテクチャでは、ペアレント SSP ファームを使用することで、インデックス サーバーの障害に対する保護を提供しています。ハードウェアが多数必要なソリューションに見える可能性がありますが、インデックス サーバーが個別のサーバーにある限り、個別の SSP ファームは、クラスタ化、またはミラー化されたデータベース サーバーなど、いくつかのハードウェアを共有できます。SSP ファームの計画方法と構成の詳細については、「SSP のアーキテクチャを計画する」を参照してください。

このトポロジには、以下の利点があります。

  • SSP の管理が集中化されます。

  • ファームに障害が発生しても、再クロールは不要です。

集中 SSP ファーム

SSP フェールオーバー ファーム

このトポロジには、以下の制限があります。

複数のファームがあるデータ センター間の冗長性とフェイルオーバー

プライマリ ファームとは別のフェイルオーバー ファームをセットアップして、データ センターの可用性を提供することができます。個別のフェイルオーバー ファームがある環境には、以下の特性があります。

  • 個別の構成データベースと [サーバーの管理] コンテンツ データベースをフェイルオーバー ファームで維持する必要があります。

    注意

    プライマリ ファームの代替アクセス マッピングを構成した場合は、フェイルオーバー ファームでも同じように構成することが特に重要です。

  • すべてのカスタマイズを両方のファームに導入する必要があります。

  • パッチは、両方のファームに個別に適用する必要があります。

  • フェイルオーバー ファームへの非同期ミラー化、またはログ配布ができるのは、コンテンツ データベースだけです。

  • ミラー化またはログ配布されたデータベースは、完全復旧モデルを使用するように設定する必要があります。

  • Office Project 2007 データベースを含む SSP データベースは、フェイルオーバー ファームにバックアップして復元することができます。

SAN ベンダーと協議して、SAN レプリケーションまたは別のサポートされるメカニズムを使用して、データ センター間の可用性を提供できるかどうかを判断してください。

SQL Server から 1 つ以上の追加のデータ センターへのログ配布を構成した場合、このトポロジを複数のデータ センターで繰り返すことができます。

注意

SQL Server のミラーリングは 1 つのミラー サーバーでのみ使用できますが、ログ配布は複数のセカンダリ サーバーに対して行うことができます。

フェイルオーバー前のプライマリおよびフェイルオーバー ファーム

フェールオーバー前のプライマリ フェールオーバー ファーム

次の表に、SharePoint 製品とテクノロジ環境でのサーバー ロールおよびサービスと、サーバー ファーム間で使用できる基本的な冗長性戦略を示します。

サーバーまたはサーバー ロール ファーム間の基本的冗長性戦略

SQL Server

SQL Server 非同期データベース ミラーリング、SQL Server ログ配布、またはその他の非同期レプリケーション メカニズム。

注意

検索情報をホストする SSP データベースや Project Server データベースには使用できません。

フロントエンド Web サーバー

カスタマイズを含む、両方のファームに導入します。

中規模サーバー ファームの Web サーバー (Web アプリケーションおよび検索クエリ サービス)

両方のファームに導入します。

検索インデックス

両方のファームに導入します。元のファームからのバックアップを回復して、フェイルオーバー ファームに移動します。

Excel 計算

両方のファームに導入します。SSP が検索をホストしない場合は、非同期データベース ミラーリング、SQL Server ログ配布、またはその他の非同期レプリケーション メカニズムを使用して、データをフェイルオーバー ファームに移動できます。

SSP が検索もホストする場合は、元のファームからのバックアップを回復して移動する必要があります。

Project アプリケーション

両方のファームに導入します。元のファームからのバックアップを回復して、フェイルオーバー ファームに移動します。

ファーム間での検索の可用性

検索には、検索データベース、SSP データベース、およびインデックス間の完全な同期が必要です。この要件のため、非同期レプリケーション メカニズム (非同期データベース ミラーリング、ログ配布、または非同期 SAN レプリケーション) を使用してファーム間で検索を複製することはできません。

注意

検索または Project なしで SSP を実行している場合は、非同期レプリケーション メカニズムを使用してデータを移動できます。

フェイルオーバー ファームで検索を提供するには、次のどちらかの方法を使用する必要があります。

  • 検索 SSP のバックアップをフェイルオーバー ファームに回復します。

  • 検索および他の SSP をホストする一元化された親ファームを使用します。中央ファームの検索サービスが、他のすべてのファームのコンテンツをクロールします。

要約

可用性要件を慎重に評価してください。可用性のレベルが高いほど、また、保護するシステムが多いほど、可用性ソリューションは複雑で、コストがかかります。

可用性を確保するためのコストは、ビジネス ニーズに基づいて評価する必要があります。組織内のすべてのソリューションに同じレベルの可用性が必要というわけではありません。サイトごと、サービスごと (検索、ビジネス インテリジェンスなど)、またはファームごとに異なるレベルの可用性を提供できます。

謝辞

Microsoft Office SharePoint Server Content Publishing チームは、このペーパーをレビューしていただいた以下のテクニカル レビュアに謝意を表します。

  • Bill Baer、Microsoft Online Services、Hosted SharePoint、テクノロジ アーキテクト

  • James Petrosky、Microsoft Consulting Services、シニア コンサルタント

  • Steve Peschka、Microsoft Consulting Services、IW シニア アーキテクト

  • Dan Winter、Microsoft Customer Support Services、エスカレーション エンジニア

  • Sean Livingston、Microsoft SharePoint Products and Technologies、プログラム マネージャ

  • Mike Watson、テクノロジ アーキテクト

  • Todd Carter、Microsoft Premier Field Engineering、プリンシパル プレミア フィールド エンジニア

  • Mike Plumley、Microsoft Office Project Server、ライタ

  • Christophe Fiessinger、Microsoft Office Project、シニア テクニカル プロダクト マネージャ

  • Sid Shah、Microsoft Search、プログラム マネージャ

  • Luca Bandinelli、Microsoft SharePoint Products and Technologies、プログラム マネージャ

このブックのダウンロード

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。

関連項目

概念

高可用性を構成する (Office SharePoint Server)