可用性を計画する (SharePoint Server 2010)
適用先: SharePoint Foundation 2010, SharePoint Server 2010
トピックの最終更新日: 2016-11-30
この記事では、Microsoft SharePoint Server 2010 環境の可用性戦略を選択する際の重要な判断項目について説明します。
可用性要件は慎重に検討すると同時に、可用性のレベルが高いほど、また、保護するシステムが多いほど、可用性ソリューションは複雑でコストのかかるものになることに注意してください。
組織内のすべてのソリューションに同じレベルの可用性が必要というわけではありません。サイトごと、サービスごと、またはファームごとに異なるレベルの可用性を提供できます。
この記事の内容
可用性の概要
可用性の戦略とレベルの選択
単一ファーム ("ストレッチド” ファーム) として近接配置されているデータ センター間の冗長性とフェールオーバー
可用性の概要
可用性とは、SharePoint Server 環境が使用可能であるとユーザーが認識する度合いです。使用可能なシステムとは、システムの回復力が高いこと、つまり、サービスに影響を及ぼすインシデントがあまり発生せず、そのようなインシデントが発生しても、迅速で効果的な処置が取られることを意味します。
可用性はビジネス継続性管理 (BCM) の一部であり、バックアップと復元および障害復旧に関係します。関係するこれらの処理の詳細については、「SharePoint Server 2010 でのバックアップと復元を計画する」および「障害復旧を計画する (SharePoint Server 2010)」を参照してください。
注意
可用性の計算に際し、ほとんどの組織は、計画的なメンテナンス作業の時間を明示的に除外または追加します。
可用性の最も一般的な評価基準の 1 つとして、稼働率を "9 の個数" で表したものがあります。つまり、ある特定のシステムがアクティブで稼働している時間の割合です。たとえば、稼働率が 99.999% のシステムは、可用性が "ファイブ ナイン" であると言います。
次の表は、稼働率とそれに対応するカレンダー時間の相互関係を示しています。
| 許容される稼働率 | 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 か月、または 1 週間の稼働率を計算できます。
% 稼働時間/年 = 100 - (8760 - 1 年あたりのダウンタイムの合計値)/8760
% 稼働時間/月 = 100 - ((24 × その月の日数) - そのカレンダー月のダウンタイムの合計値)/(24 × その月の日数)
% 稼働時間/週 = 100 - (168 - その週のダウンタイムの合計値)/168
可用性のコスト
可用性は、システムにとってコストのかかる要件の 1 つです。可用性のレベルが高いほど、また、保護するシステムが多いほど、可用性ソリューションは複雑でコストのかかるものになります。可用性に投資するときには、次のようなコストが含まれます。
追加のハードウェアおよびソフトウェア。ソフトウェア アプリケーションや設定の間のやり取りの複雑さが増します。
操作の複雑さの増加。
可用性を向上するためのコストは、ビジネス ニーズに基づいて評価する必要があります。組織内のすべてのソリューションに同じレベルの可用性が必要というわけではありません。サイトごと、サービスごと、またはファームごとに異なるレベルの可用性を提供できます。
可用性は、情報技術 (IT) グループがサービス レベル契約 (SLA) を提供して、顧客グループの期待を設定する主要分野です。多くの IT 組織は、異なるチャージバック レベルと関連付けられたさまざまな SLA を提供しています。
可用性要件の決定
サイト、サービス、またはファームのダウンタイムに対する組織の許容度を判断するには、次の質問に対する答えが必要です。
サイト、サービス、またはファームが使用できなくなった場合、従業員は担当する仕事を実行できなくなりますか。
サイト、サービス、またはファームが使用できなくなった場合、業務および顧客のトランザクションが停止し、業務および顧客の損失が発生しますか。
どちらかの質問の答えが「はい」の場合、可用性ソリューションに投資する必要があります。
可用性戦略およびレベルの選択
以下を含む多くの手法の中から、SharePoint Server 環境の可用性を向上する手法を選択できます。
サーバー ハードウェア コンポーネントのフォールト トレランスを向上する。
ファーム内のサーバー ロールの冗長性を高める。
ハードウェア コンポーネントのフォールト トレランス
ハードウェア コンポーネントのフォールト トレランスとは、サーバー レベルでの電源装置など、ハードウェア コンポーネントおよびインフラストラクチャ システムの冗長性のことです。ハードウェア コンポーネントのフォールト トレランスを計画する場合は、次の点を考慮します。
サーバー内のすべてのコンポーネントについて完全な冗長性を実現することは、不可能な場合や現実的ではない場合があります。冗長性を高めるには、追加のサーバーを使用します。
最大限の冗長性が得られるように、サーバーに複数の電源装置を用意し、それぞれを異なる電源に接続します。
どのようなシステムでも、ハードウェア ベンダーと協力して、RAID (Redundant Array of Independent Disks) 配列など、システムに適したフォールト トラレントなハードウェアを入手することをお勧めします。推奨事項については、「パフォーマンスと容量の管理 (SharePoint Server 2010)」および「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。
ファーム内での冗長性
SharePoint Server 2010 は、処理能力の増加および基本的な可用性の提供を目的として、ファーム内の冗長コンピューター上でのサーバー ロールの実行 (つまり、スケール アウト) をサポートします。
要求される処理能力によって、ファーム内のサーバーの数とサイズの両方が決まります。基本となる処理能力の要件を満たした後で、サーバーを追加して全体の可用性を向上させる場合があります。以下に、各サーバー ロールに冗長性を与える方法を示します。
サーバー ファーム内での可用性
.gif "単一ファームの可用性")
次の表は、SharePoint Server 2010 環境でのサーバー ロールと、ファーム内のそれぞれで使用できる冗長性戦略を示しています。
| サーバー ロール | ファーム内で優先される冗長戦略 |
|---|---|
フロントエンド Web サーバー |
ファーム内で複数のフロントエンド Web サーバーを展開し、ネットワーク負荷分散 (NLB) を使用します。 |
アプリケーション サーバー |
ファーム内で複数のアプリケーション サーバーを展開します。 |
データベース サーバー |
クラスタリングまたは高可用性データベース ミラーリングを使用して、データベース サーバーを展開します。 |
データベースの可用性戦略
Microsoft SQL Server フェールオーバー クラスタリングまたは SQL Server 高可用性データベース ミラーリングを使用することで、SharePoint Server 環境内でのデータベースの可用性をサポートできます。
SQL Server フェールオーバー クラスタリング
フェールオーバー クラスタリングは、SQL Server のインスタンスに対する可用性をサポートします。フェールオーバー クラスターは、1 つ以上のノードまたはサーバーと 2 つ以上の共有ディスクを組み合わせたものです。フェールオーバー クラスターのインスタンスは、単一のコンピューターとして表示されますが、現在のノードが使用できなくなった場合に別のノードにフェールオーバーできる機能を備えています。SharePoint Server は、SQL Server でサポートされる 1 つのクラスター内のアクティブ ノードとパッシブ ノードの任意の組み合わせで実行できます。
SharePoint Server はクラスター全体を参照するため、SharePoint Server から見てフェールオーバーは自動的かつシームレスに実行されます。
フェールオーバー クラスタリングの詳細については、「SQL Server 2008 フェールオーバー クラスタリングの概要」(https://go.microsoft.com/fwlink/?linkid=102837&clcid=0x411) および「SQL Server クラスタリングを使用して可用性を構成する (SharePoint Server 2010)」を参照してください。
SQL Server 高可用性ミラーリング
データベース ミラーリングは、データベース単位でデータベースの冗長性を実現する SQL Server テクノロジーです。データベース ミラーリングでは、プリンシパル データベースのトランザクション ログ バッファーがディスクに書き込まれるときに、プリンシパル データベースおよびサーバーからミラー データベースおよびサーバーにトランザクションが直接送信されます。この方法の場合、ミラー データベースはプリンシパル データベースのほぼ最新の内容を反映できます。SQL Server Enterprise Edition は、データベース ミラーリングのパフォーマンスを向上する追加の機能を備えています。詳細については、「SQL Server 2008 R2 と SharePoint 2010 製品: よりよい統合 (ホワイト ペーパー) (SharePoint Server 2010)」を参照してください。
SharePoint Server ファーム内のミラーリングでは、自動フェールオーバー機能付き高安全性モードとも呼ばれる高可用性ミラーリングを使用する必要があります。高可用性データベース ミラーリングには、プリンシパル、ミラー、および監視という 3 つのサーバー インスタンスが関与します。監視サーバーは、SQL Server によるプリンシパル サーバーからミラー サーバーへの自動的なフェール オーバーを可能にします。通常、プリンシパル データベースからミラー データベースへのフェールオーバーには数秒かかります。
以前のバージョンからの変更点の 1 つは、SharePoint Server がミラーリングに対応したことです。SQL Server のデータベース ミラー インスタンスを構成した後は、SharePoint サーバーの全体管理または Windows PowerShell コマンドレットを使用して、構成データベース、コンテンツ データベース、またはサービス アプリケーション データベースのフェールオーバー (ミラー) データベース サーバーの場所を特定します。フェールオーバー データベースの場所を設定すると、SharePoint Server が SQL Server への接続に使用する接続文字列にパラメーターが 1 つ追加されます。SQL Server のタイムアウト イベントが発生した場合は、以下の処理が行われます。
SQL Server ミラーリング用に構成された監視サーバーは、プライマリ データベースとミラー データベースのロールを自動的に交換します。
SharePoint Server は、フェールオーバー データベースとして指定されているサーバーへの接続を自動的に試みます。
データベース ミラーリングの構成方法の詳細については、「SQL Server データベース ミラーリングを使用して可用性を構成する (SharePoint Server 2010)」を参照してください。
データベース ミラーリングの概要については、「データベース ミラーリング」(https://go.microsoft.com/fwlink/?linkid=180597&clcid=0x411) を参照してください。
注意
SQL Server FILESTREAM リモート BLOB ストア プロバイダーを使用するように構成されているデータベースはミラーリングできません。
単一ファームにおけるデータベース可用性戦略の比較: SQL Server フェールオーバー クラスタリングおよび SQL Server 高可用性ミラーリング
次の表は、フェールオーバー クラスタリングと SQL Server の同期高可用性ミラーリングの比較を示しています。
| SQL Server フェールオーバー クラスタリング | SQL Server 高可用性ミラーリング | |
|---|---|---|
フェールオーバーのタイミング |
障害が発生すると、直ちにクラスター メンバーに切り替わります。 |
障害が発生すると、直ちにミラーに切り替わります。 |
トランザクションの一貫性 |
あり |
あり |
トランザクションの同時性 |
あり |
あり |
復元時間 |
短い時間で復元 (ミリ秒)。 |
わずかに長い時間で復元 (ミリ秒)。 |
フェールオーバーに必要な手順 |
障害はデータベース ノードによって自動的に検出されます。SharePoint Server 2010 はクラスターを参照するため、フェールオーバーはシームレスかつ自動的に行われます。 |
障害はデータベースによって自動的に検出されます。SharePoint Server 2010 はミラー位置を理解しており、それが正しく構成されている場合、そのフェールオーバーは自動的に行われます。 |
記憶域の障害に対する保護 |
記憶域はクラスター内のノード間で共有されるため、記憶域の障害は保護されません。 |
プリンシパル データベースとミラー データベースの両方がローカル ディスクに書き込むため、記憶域の障害は保護されます。 |
サポートされる記憶域の種類 |
共有記憶域 (高価)。 |
廉価な直接接続ストレージ (DAS) を使用可能。 |
場所の要件 |
クラスターのメンバーは同じサブネット上にいる必要があります。 |
プリンシパル サーバー、ミラー サーバー、および監視サーバーは同じ LAN 上にある必要があります (最大 1 ミリ秒の待機時間)。 |
復旧モデル |
SQL Server の完全復旧モデルを推奨。SQL Server の単純復旧モデルを使用できますが、クラスターが失われた場合に唯一使用可能な復旧ポイントは、最後の完全バックアップです。詳細については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」および「Plan for SQL Server, storage and BLOB configuration (SharePoint Foundation 2010)」を参照してください。 |
SQL Server の完全復旧モデルが必要です。 |
パフォーマンスのオーバーヘッド |
フェールオーバーの発生時にパフォーマンスの多少の減少が生じる可能性があります。 |
高可用性ミラーリングでは、同期処理が行われるため、トランザクションの待機時間が発生します。メモリとプロセッサのオーバーヘッドも増加します。 |
運用上の負担 |
サーバー レベルでのセットアップとメンテナンス。 |
運用上の負担はクラスタリングより重く、すべてのデータベースのセットアップおよびメンテナンスが必要です。フェールオーバー上の再構成は手動で行います。 |
サービス アプリケーションの冗長性戦略
ファーム内で実行するサービス アプリケーションを保護するために従う冗長性戦略は、サービス アプリケーションがデータを格納する場所によってそれぞれ異なります。
データベースの外部にデータを格納するサービス アプリケーション
データベースの外部にデータを格納するサービス アプリケーションを保護するには、複数のアプリケーション サーバー上にサービス アプリケーションをインストールして、環境内での冗長性を実現します。
このリリースの SharePoint Server では、複数のアプリケーション サーバー上にサービス アプリケーションをインストールすると、そのサービス アプリケーションに関連付けられているサービス インスタンスを実行しているすべてのアプリケーション サーバー、または、最初に使用可能なサーバー上で、タイマー ジョブが実行します。アプリケーション サーバーに障害が発生すると、そのサーバー上で実行しているタイマー ジョブは、タイマー ジョブの次の実行がスケジュールされたときに別のサーバー上で再起動します。
複数のアプリケーション サーバーにサービス アプリケーションをインストールすると、サービス アプリケーションは実行し続けますが、データの損失が保証されるわけではありません。アプリケーション サーバーに障害が発生した場合、そのアプリケーション サーバーへのアクティブな接続が失われ、ユーザーはデータを失います。
以下のサービス アプリケーションは、データベースの外部にデータを格納します。
Access Services
Excel Services アプリケーション
データベースにデータを格納するサービス アプリケーション
データベースにデータを格納するサービス アプリケーションを保護するには、次の手順を実行する必要があります。
複数のアプリケーション サーバーにサービスをインストールして、環境内での冗長性を実現します。
SQL Server クラスタリングまたはミラーリングを構成して、データを保護します。
以下のサービス アプリケーションは、データベースにデータを格納します。
以下のデータベースを含む Search Service アプリケーション
検索管理
クロール
プロパティ
注意
検索データベースのミラーリングはサポートされていますが、検索の冗長性を実現するには、追加の作業が必要です。詳細については、「ファーム内での検索の冗長性戦略」を参照してください。
以下のデータベースを含む User Profile Service
プロファイル
ソーシャル
同期
注意
同期データベースのミラーリングはサポートされていません。
Business Data Connectivity Service アプリケーション
Application Registry Service アプリケーション
アプリケーション レジストリ データベースは、Microsoft Office SharePoint Server 2007 ビジネス データ カタログ情報を SharePoint Server 2010 にアップグレードするときにのみ使用されるため、そのミラーリングは推奨されません。
Usage and Health Data Collection Service アプリケーション
注意
Usage and Health Data Collection Service アプリケーションのログ データベースはミラーリングしないことをお勧めします。
Managed Metadata Service アプリケーション
Secure Store Service アプリケーション
State Service アプリケーション
以下のデータベースを含む Web Analytics Service アプリケーション
レポート
ステージング
注意
ステージング データベースのミラーリングはサポートされていません。
Word Automation Services Service アプリケーション
Microsoft SharePoint Foundation Subscription Settings Service
PerformancePoint Services
ファーム内での検索の冗長性戦略
サーバーのみ
Search Service アプリケーションは、ファーム内の冗長性に関して特殊なケースです。次の図は、およそ 4000 万個をクロールする中規模な専用の Search Service アプリケーションに対して、冗長性とフェールオーバーを構成する方法を示しています。Search Service アプリケーションのアーキテクチャの詳細については、技術ダイアグラム (SharePoint Server 2010)」の「Microsoft SharePoint Server 2010 の検索アーキテクチャ」を参照してください。
冗長な Search Service アプリケーション
.gif "高可用性検索アーキテクチャ")
クエリ サーバー。クエリ サーバーは、クエリー コンポーネントとインデックス パーティションをホストします。
クエリ コンポーネントが検索結果を返します。各クエリ コンポーネントはインデックス パーティションの一部であり、これは、クロールされた特定のコンテンツ セットに関連するメタデータが格納されている、特定のプロパティ データベースに関連付けられています。インデックス パーティションに "ミラー" クエリ コンポーネントを追加し、それを異なるファーム サーバーに配置することで、インデックス パーティションの冗長性を実現できます。
注意
ミラー クエリ コンポーネントという用語は、SQL Server データベースのミラーリングではなく、同一のファイル コピーを表します。
インデックス パーティションはクエリ コンポーネントのグループです。各クエリ コンポーネントはフル テキスト インデックスのサブセットを保持し、検索結果をクエリ発行者に返します。それぞれのインデックス パーティションは、クロールされた特定のコンテンツ セットに関連するメタデータが格納されている、特定のプロパティ データベースに関連付けられています。ファーム内のどのサーバーがクエリを処理するかは、クエリ コンポーネントをどのサーバー上に作成するかによって決定できます。クエリ処理の負荷を複数のファーム サーバー間で分散させるには、クエリ コンポーネントをインデックス パーティションに追加し、クエリを処理するサーバーにそのクエリ コンポーネントを関連付けます。詳細については、「クエリ コンポーネントを追加または削除する」を参照してください。インデックス パーティションにミラー クエリ コンポーネントを追加し、それを異なるファーム サーバーに配置することで、インデックス パーティションの冗長性を実現できます。
クロール サーバー。クロール サーバーは、クロール コンポーネントと検索管理コンポーネントをホストします。
クロール コンポーネントは、コンテンツ ソースのクロールの処理、作成されたインデックス ファイルをクエリ コンポーネントに伝達する処理、およびコンテンツ ソースの場所とクロールのスケジュールの情報を対応するクロール データベースに追加する処理を行います。クロール コンポーネントは単一の Search Service アプリケーションと関連付けられています。別のクロール サーバーにクロール コンポーネントを追加することで、クロールの負荷を分散できます。リソースが許す限り、特定のクロール サーバー上で持つことができるクロール コンポーネントの数に制限はありません。コンテンツの場所が多数ある場合は、クロール コンポーネントとクロール データベースを追加して、それらを特定のコンテンツ専用にできます。特定のクロール サーバー上の各クロール コンポーネントは、別々のクロール データベースに関連付ける必要があります。冗長性を目的とした場合、クロール コンポーネントは少なくとも 2 つ必要です。各クロール コンポーネントは、両方のクロール データベースをクロールするように設定する必要があります。データベースのアイテム数が 25 万個を超える場合は、新しいクロール データベースおよびクロール コンポーネントを追加することをお勧めします。
検索管理コンポーネントは、受信するユーザーのアクションを監視し、検索管理データベースを更新します。検索管理データベースは、各 Search Service アプリケーションに 1 つのみ存在します。検索管理コンポーネントはどのサーバー上でも実行できますが、クロール サーバーまたはクエリ サーバーで実行するのが適当です。
データベース サーバー。データベース サーバーは、クロール データベース、プロパティ データベース、検索管理データベース、およびその他の SharePoint Server 2010 データベースをホストします。
クロール データベース
クロール データベースには、コンテンツ ソースの場所、クロール スケジュール、および特定の Search Service アプリケーションのクロール操作固有の他の情報に関するデータが格納されます。SQL Server を実行している別のコンピューターにクロール データベースを追加することによって、データベース負荷を分散できます。クロール データベースはクロール コンポーネントに関連付けられており、ホストの割り当てルールを作成することによって、特定のホスト専用にできます。クロール コンポーネントの詳細については、「クロール コンポーネントを追加または削除する」を参照してください。ホストの割り当てルールの詳細については、「ホストの割り当てルールを追加または削除する」を参照してください。クロール データベースは、これがミラーリングされているか、SQL Server フェールオーバー クラスターに展開されている場合、冗長です。
プロパティ データベース
プロパティ データベースには、クロールされたコンテンツに関連付けられたメタデータが格納されています。SQL Server を実行している別のコンピューターにプロパティ データベースを追加することで、クエリによるデータベースの負荷を分散させることができます。プロパティ データベースは、インデックス パーティションと関連付けられており、コンテンツに関連付けられたメタデータがあればクエリ結果に含めて返します。
プロパティ データベースは、これがミラーリングされているか、SQL Server フェールオーバー クラスターに展開されている場合、冗長です。
検索管理データベース
検索管理データベースは、ファーム内の各 Search Service アプリケーション インスタンスに 1 つのみ存在します。
検索管理データベースは、これがミラーリングされている場合、または SQL Server フェールオーバー クラスターに展開されている場合のみ冗長です。
検索の冗長性の詳細については、「検索トポロジを管理する」を参照してください。
単一ファーム ("ストレッチド” ファーム) として近接配置されているデータ センター間の冗長性とフェールオーバー
一部の企業では、複数のデータ センターを単一のファームとして構成できるように各データ センターを高帯域幅の接続によって近接配置しています。これを "ストレッチド" ファームと呼びます。ストレッチド ファームが機能するためには、SQL Server とフロントエンド Web サーバーとの間の一方向での遅延が 1 ミリ秒未満で、帯域幅が 1 ギガビット/秒以上である必要があります。
このシナリオでは、データベースおよびサービス アプリケーションを冗長するための標準のガイダンスに従うことで、フォールト トレランスを提供できます。
次の図は、ストレッチド ファームを示しています。
ストレッチド ファーム
.gif "\"ストレッチ\" ファーム")