可用性を計画する (Windows SharePoint Services)
ここでは、SharePoint 製品とテクノロジ環境における可用性の概要、コスト、課題、および環境内で使用できる戦略とソリューションについて説明します。ファームで Windows SharePoint Services 3.0 を使用している場合、または Microsoft Office SharePoint Server 2007、Microsoft Office Project Server 2007、Microsoft Office Forms Server 2007、Microsoft Search Server 2008 のいずれかを使用する高可用性環境の場合は、この資料を読む必要があります。この資料に付属する Office SharePoint Server 2007 可用性モデルに関するドキュメント (英語) (https://go.microsoft.com/fwlink/?linkid=122369&clcid=0x411) をダウンロードして印刷できます。これは、この資料の内容をポスター サイズにまとめたものです。
注意
この記事の中には、Office SharePoint Server 2007 でのみ使用可能な機能についての説明があります。これは、Windows SharePoint Services 3.0 と Office SharePoint Server 2007 の両方を含む環境を管理する可能性があることを前提としているためです。
可用性とは
可用性とは、SharePoint 製品とテクノロジ環境をユーザーが利用可能と認識する程度を意味します。可用性の保証とは、システムの回復力が高いこと、つまり、サービスに影響を及ぼすインシデントがほとんど発生せず、発生したときにはタイムリーで効果的なアクションが必ず実行されることを意味します。可用性戦略は、ユーザーが認識する計画的および非計画的なダウンタイムを最小限にします。
可用性の最も一般的な尺度の 1 つは、9 の数で表したアップタイムの割合、つまり、システムがアクティブで、なおかつ動作している時間の割合です。たとえば、アップタイムの割合が 99.999 のシステムは、可用性がファイブ ナイン (9 が 5 個) であると表現されます。
次の表では、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 分 |
発生する可能性のあるダウンタイムの合計時間数を予測できる場合は、次の数式を使用して、年、月、週に対するアップタイムの割合を計算できます。
% アップタイム/年 = 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 製品とテクノロジは、SQL Server のミラーリングに対応していません。可用性の技法として SQL Server ミラーリングの使用を検討することをお勧めしますが、その場合は追加の自動化が必要になります。
可用性を考慮する状況
SharePoint ソリューションの中心的な設計の一部として、可用性の要件を検討することをお勧めします。また、ソリューションを展開した後で、可用性を強化することもできます。運用面からは、ファーム内にコア ソリューションを展開して調整した後、可用性ソリューションをテストすることをお勧めします。
可用性要件の決定
サイト、サービス、またはファームのダウンタイムに対する組織の許容度を調べるため、サイト、サービス、ファームに関する次の質問に答えてください。
サイト、サービス、またはファームが利用できなくなった場合、組織の従業員は任務を果たすことができなくなりますか。
サイト、サービス、またはファームが利用できなくなった場合、企業および顧客との取引が停止し、商談や顧客の喪失につながりますか。
どちらかの質問に「はい」と答えた場合、可用性ソリューションへの投資が必要です。
可用性戦略の選択
可用性を強化するために選択できる方法には、次のようなものがあります。
コンポーネントのフォールト トレランス。
ファーム内のサーバー役割間の冗長性とフェールオーバー。
サーバー ファーム間の冗長性とフェールオーバー。
可用性のシステム要件
理想的なシナリオでは、フェールオーバー用のコンポーネントおよびシステムを、プライマリのコンポーネントおよびシステムと、プラットフォーム、ハードウェア、サーバーの数などのすべての点で一致させます。少なくとも、フェールオーバー環境は、フェールオーバーの間に予想されるトラフィックを処理できる必要があります。フェールオーバー サイトのサービスを受けるのは一部のユーザーのみの可能性があることに留意してください。システムは、少なくとも次のことに関して一致している必要があります。
オペレーティング システムのバージョンとすべての更新プログラム
SQL Server のバージョンとすべての更新プログラム
SharePoint 製品とテクノロジのバージョンとすべての更新プログラム
この資料では主に SharePoint 製品とテクノロジの可用性について説明しますが、システムのアップタイムはシステム内の他のコンポーネントからも影響を受けます。特に、次の点に注意してください。
電源、冷却、ネットワーク、ディレクトリ、SMTP などのインフラストラクチャの依存性を、完全に冗長にする必要があります。
ニーズにあったシステムの切り替えメカニズム (DNS またはハードウェア負荷分散) を選択します。負荷分散 Web サーバーのベスト プラクティスについては、次の資料を参照してください。
コンポーネントのフォールト トレランス
どのようなシステムでも、ハードウェア ベンダと協力して、システムに適したフォールト トレラント ハードウェア (Redundant Array of Independent Disks (RAID) アレイなど) を調達することをお勧めします。推奨事項については、「パフォーマンスおよび容量を計画する (Windows SharePoint Services)」を参照してください。
コンポーネントのフォールト トレランスを計画するときは、以下のことを考慮します。
1 つのサーバー内のすべてのコンポーネントを完全に冗長にするのは、不可能または非現実的です。冗長性を増やすにはサーバーを追加します。
インデックス サーバーの役割は冗長にできないので、インデックス サーバーの役割用のコンポーネントを冗長にします。
最大限の冗長性が得られるように、サーバーに複数の電源装置を用意し、それぞれを異なる電源に接続します。
同じファーム内のサーバーの役割間の冗長性とフェールオーバー
SharePoint 製品とテクノロジでは、同じファーム内の冗長なコンピュータでサーバーの役割を実行し (スケール アウト)、処理能力の拡大とパフォーマンスの向上、および基本的な可用性を提供できます。処理能力とパフォーマンスにより、ファーム内のサーバーの数とサーバーのサイズが決まります。基本的な要件を満たした後、さらにサーバーを追加して、サービスの全体的な可用性を高めることができます。
単一のサーバー ファーム内での可用性
.gif "単一ファームの可用性")
次の表では、SharePoint サーバーの全体管理 Web サイトの [サーバーのサービス] ページに一覧表示される、SharePoint 製品とテクノロジ環境内のサーバーおよびサーバーの役割、およびファーム内で使用できる基本的な冗長性戦略について説明します。
| サーバーのサービス | ファーム内で推奨される基本的な冗長性戦略 |
|---|---|
SQL Server |
クラスタまたは同期ミラーリング。クラスタの方が実装は簡単ですが、コストがかかる場合があります。 同期ミラーリングの使用方法の詳細については、「White paper: Using database mirroring」を参照してください。 |
Web サーバー |
複数のサーバーへの展開、およびソフトウェアまたはハードウェアによる負荷分散。 |
中規模サーバー ファーム用の Web サーバー (Web アプリケーションおよび検索クエリ サービス) |
複数のサーバーに展開します。 |
検索インデックス |
複数のサーバーには展開できず、冗長化できません。別の可用性戦略を使用する必要があります。詳細については、「フェールオーバー後の検索の可用性」を参照してください。 |
Excel Calculation |
複数のサーバーに展開します。 |
Project アプリケーション |
複数のサーバーに展開します。 |
詳細については、「冗長性を計画する (Windows SharePoint Services)」を参照してください。
単一ファーム用のデータベース可用性戦略の比較 : SQL Server フェールオーバー クラスタと SQL Server 高可用性ミラーリング
次の表では、フェールオーバー クラスタと同期 SQL Server 高可用性ミラーリングを比較します。
| SQL Server フェールオーバー クラスタ | SQL Server 高可用性ミラーリング |
|---|---|
障害が発生すると、直ちにミラーに切り替わります。 |
障害が発生すると、直ちにミラーに切り替わります。 |
トランザクションの一貫性が保証されます。 |
トランザクションの一貫性が保証されます。 |
トランザクションの同時性が保証されます。 |
トランザクションの同時性が保証されます。 |
復旧時間が最短 (秒から分の単位) |
復旧時間が若干長い (秒から分の単位) |
障害は、データベース ノードによって自動的に検出されます。SharePoint 製品とテクノロジはクラスタを参照するので、SharePoint 製品とテクノロジから見たフェールオーバーは、シームレスかつ自動的です。 |
SharePoint 製品とテクノロジのフェールオーバーを実現するためにスクリプトの作成が必要。 |
記憶域はクラスタ内のノード間で共有されるので、記憶域の障害に対しては保護されません。 |
プリンシパルおよびミラーのデータベース サーバーはどちらもローカル ディスクに書き込むので、記憶域の障害に対して保護されます。 |
より高価な共有記憶域が必要です。 |
安価な DAS (Direct-attached Storage) を使用できます。 |
同じサブネットです。 |
SQL Server と Web サーバーの間で最大 1 ミリ秒の待ち時間が発生します。 |
SQL Server の単純復旧モデルを使用できますが、クラスタが失われた場合に利用できる復旧ポイントは、最後の完全バックアップだけです。 |
SQL Server の完全復旧モデルが必要です。 |
パフォーマンスのオーバーヘッドはありません。 |
トランザクションの待ち時間が発生します。メモリとプロセッサにオーバーヘッドがあります。 |
運用の負担は最低限です。 |
スクリプトの作成や SQL Server エイリアスの設定など、運用の負担が増えます。 |
単一のファームとして構成されている近接したデータ センター間の冗長性とフェールオーバー ("拡大" ファーム)
場合によっては、近い場所にある複数のデータ センターが高帯域幅で接続され、単一のファームとして構成できることがあります。これは "拡大" ファームと呼ばれるものです。拡大ファームが機能するためには、SQL Server と Web サーバーの間の 1 方向の待ち時間が 1 ミリ秒未満で、帯域幅が 1 ギガビット/秒以上である必要があります。
このような状況では、同期ミラーリングを使用してデータベースの冗長性を提供できます。拡大ファーム内で、構成データベースとコンテンツ データベースをミラー化できます。拡大ファームの使用方法に関するケース スタディについては、「White paper: Case Study of High Availability for SharePoint using Database Mirroring」を参照してください。
地理的に離れた場所にあるサーバー クラスタで稼働する SQL Server などのように、SAN レプリケーションまたは別のサポートされるメカニズムを使用してデータ センター間の可用性を提供できるかどうかについては、SAN のベンダに問い合わせてください。SAN レプリケーションのソリューションが十分なレベルの同時性およびトランザクションの一貫性を提供することを確認してください。
拡大ファーム内では、次のものを使用して、SSP を実行するアプリケーション サーバーのフォールト トレランスを実現できます。
複数のクエリ サーバー
Excel Calculation Services を実行する複数のサーバー
このシナリオでは、インデックス サーバーが単一障害点になります。検索のバックアップと復元、または復旧時の検索の現在性が重要である場合はフェールオーバー SSP ファームを使用できます。詳細については、「フェールオーバー後の検索の可用性」を参照してください。
"拡大" ファーム
.gif "\"ストレッチ\" ファーム")
複数ファームのデータ センター間の冗長性とフェールオーバー
フェールオーバー ファームを設定することで、プライマリ ファームとは独立したデータ センターで可用性を提供できます。独立したフェールオーバー ファームを使用する環境には、次のような特徴があります。
分かれた構成データベースおよびサーバーの全体管理コンテンツ データベースを、フェールオーバー ファームで維持する必要があります。
注意
プライマリ ファームに対して代替アクセス マッピングを構成している場合は、フェールオーバー ファームでもそれをまったく同じに構成することが特に重要です。
すべてのカスタマイズを両方のファームに展開する必要があります。
パッチを両方のファームに個別に適用する必要があります。
フェールオーバー ファームに対する非同期のミラーリングまたはログ配布が成功するのは、コンテンツ データベースだけです。
ミラー化されたデータベースまたはログ配布対象のデータベースは、完全復旧モデルを使用するように設定する必要があります。
SSP データベースをバックアップしてフェールオーバー ファームに復元できます。
SAN レプリケーションまたは別のサポートされるメカニズムを使用してデータ センター間の可用性を提供できるかどうかについては、SAN のベンダに問い合わせてください。
他のデータ センターに SQL Server ログ配布を構成した場合は、このトポロジを多数のデータ センターに対して繰り返すことができます。
注意
SQL Server ミラーリングは 1 つのミラー サーバーでしか使用できませんが、ログ配布は複数のセカンダリ サーバーに対して行うことができます。
フェールオーバー前のプライマリ ファームとフェールオーバー ファーム
.gif "フェールオーバー前のプライマリ フェールオーバー ファーム")
次の表では、SharePoint 製品とテクノロジ環境内のサーバーとサーバーの役割、および各サーバー ファーム間で使用できる基本的な冗長性戦略について説明します。
| サーバーまたはサーバーの役割 | ファーム間で推奨される基本的な冗長性戦略 |
|---|---|
SQL Server |
SQL Server 非同期データベース ミラーリング、SQL Server ログ配布、または他の非同期レプリケーション メカニズム。 注意 検索情報をホストする SSP データベースには使用できません。 |
フロントエンド Web サーバー |
カスタマイズも含めて、両方のファームに展開します。 |
中規模サーバー ファーム用の Web サーバー (Web アプリケーションおよび検索クエリ サービス) |
両方のファームに展開します。 |
検索インデックス |
両方のファームに展開します。元のファームのバックアップを復元して、フェールオーバー ファームに移動します。 |
Excel Calculation |
両方のファームに展開します。SSP が検索をホストしていない場合は、非同期データベース ミラーリング、SQL Server ログ配布など、非同期レプリケーション メカニズムを使用して、データをフェールオーバー ファームに移動できます。 SSP が検索もホストする場合は、移動する元のファームからバックアップを復旧する必要があります。 |
Project アプリケーション |
両方のファームに展開します。元のファームのバックアップを復元して、フェールオーバー ファームに移動します。 |
非同期レプリケーションおよび検索
検索には、検索データベース、SSP データベース、およびインデックスの間の完全な同期が必要です。このため、非同期レプリケーション メカニズム (非同期データベース ミラーリング、ログ配布、または非同期 SAN レプリケーション) を使用してファーム間で検索をレプリケートすることはできません。フェールオーバー ファームで検索を提供するには、検索 SSP を復旧する必要があります。
注意
検索またはプロジェクトを使用しないで SSP を実行している場合は、非同期レプリケーション メカニズムを使用してデータを移動できます。
フェールオーバー後の検索の可用性
同じファーム内でインデックス サーバーの役割を冗長にすることはできません。フェールオーバーの後で検索の現在性が必要な場合、それによってソリューションの論理的アーキテクチャが決まる場合があります。
フェールオーバーの直後に検索の現在性と可用性が必要ない場合は、検索 SSP をバックアップしてフェールオーバー サイトに復元できます。
検索の現在性と可用性がすぐに必要な場合は、次のどちらかを使用できます。
同一の SSP を 2 つ備えた単一ファームアーキテクチャ。
検索および他の SSP をホストする一元化された親ファーム。中央ファームの検索サービスが、他のすべてのファームのコンテンツをクロールします。このアーキテクチャは、1 つまたは複数のファームのサポートに使用できます。
重要
短時間で検索の現在性と可用性が必要になり、プロファイルを使用している場合、フェールオーバー SSP のプロファイルは、プライマリ SSP のプロファイルと同期化されません。最初にインポートされた時点での状態になります。すべての SSP 上のプロファイルの同期を保つには、32-bit SharePoint Administration Toolkit (英語) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x411) または 64-bit SharePoint Administration Toolkit (英語) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x411) に含まれている User Profile Replication Engine ツールを使用する必要があります。詳細については、「User Profile Replication Engine (Office SharePoint Server)」を参照してください。
2 つの SSP を含む単一ファーム
次のアーキテクチャは、インデックス サーバーの障害からシステムを保護します。このトポロジでは、両方の SSP が、同じルールを使用して、同じコンテンツをクロールします。フェールオーバーが発生しない限り、フェールオーバー SSP はプライマリ Web サイトに接続されません。
2 つの共有サービス プロバイダを使用する単一ファーム
.gif "2 つの SSP を持つファーム")
このトポロジには次の制限があります。
各クエリ サーバーでインデックス用に 2 倍の領域が必要です。
フェールオーバー SSP を使用するためには手動で Web アプリケーションを切り替える必要があります (スクリプト化可能)。
クロールできるコーパスのサイズが半分に減ります。
既定では、プロファイルを有効にしている場合、フェールオーバー SSP のプロファイルは、プライマリ SSP のプロファイルと同期化されません。代わりに、最初にインポートされた時点の状態になります。すべての SSP 上のプロファイルの同期を保つには、32-bit SharePoint Administration Toolkit (英語) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x411) または 64-bit SharePoint Administration Toolkit (英語) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x411) に含まれている User Profile Replication Engine ツールを使用する必要があります。詳細については、「User Profile Replication Engine (Office SharePoint Server)」を参照してください。
大きいデータ セットを遅延なくクロールできるかどうかは、インデックス サーバーと Web サーバーの間の待ち時間と帯域幅など、さまざまな要因によって影響を受けます。
帯域幅が限られている環境でこのトポロジを使用すると、パフォーマンスが大きく低下する可能性があります。コンテンツを 2 回クロールするので、クロール対象のコンテンツ リポジトリで余分な負荷が発生し、リポジトリのパフォーマンスに影響する場合があります。インデックスを最新の状態に維持する検索の機能も、悪影響を及ぼします。
集中型 SSP ファーム
次に示すアーキテクチャでは、親 SSP ファームを使用して、インデックス サーバーの障害からシステムを保護します。これは大量のハードウェアを必要とするソリューションのように見えますが、インデックス サーバーが別のサーバーに配置されている限り、異なる SSP ファームは、クラスタ化された、またはミラー化されたデータベース サーバーなどの一部のハードウェアを共有できます。SSP ファームの計画と構成の詳細については、「Plan SSP architecture」を参照してください。
このトポロジには次のようなメリットがあります。
SSP の管理が集中化されます。
ファームで障害が発生しても、再クロールは必要ありません。
集中型 SSP ファーム
.gif "SSP フェールオーバー ファーム")
このトポロジには次の制限があります。
ワイド エリア ネットワーク (WAN) 経由でのコンテンツ クロールは、帯域幅を使用します。
データ量が多く、変更頻度の高い環境では、インデックスを最新の状態に維持するのが困難な場合があります。
クエリのパフォーマンスが、WAN リンクのパフォーマンスの影響を受ける場合があります。
既定では、プロファイルを有効にしている場合、フェールオーバー SSP ファームのプロファイルは、プライマリ SSP のプロファイルと同期化されません。代わりに、最初にインポートされた時点の状態になります。すべての SSP 上のプロファイルの同期を保つには、32-bit SharePoint Administration Toolkit (英語) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x411) または 64-bit SharePoint Administration Toolkit (英語) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x411) に含まれている User Profile Replication Engine ツールを使用する必要があります。詳細については、「User Profile Replication Engine (Office SharePoint Server)」を参照してください。
まとめ
実際の可用性要件を慎重に検討してください。可用性のレベルが高く、保護する対象のシステムが多いほど、可用性ソリューションはより複雑になりコストがかかるのが普通です。
可用性を達成するためのコストは、ビジネス ニーズに基づいて評価する必要があります。通常、必要な可用性のレベルは、組織内のソリューションによって異なります。サイトごと、サービスごと (たとえば、検索とビジネス インテリジェンス)、またはファームごとに、異なるレベルの可用性を提供できます。
謝辞
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、プログラム マネージャ