次の方法で共有

可用性を計画する (SharePoint Foundation 2010)

  • [アーティクル]

 

適用先: SharePoint Foundation 2010

この記事では、Microsoft SharePoint Foundation 2010 環境の可用性戦略の選択に関する重要な意思決定事項について説明します。

実際の可用性要件を慎重に検討してください。可用性のレベルが高く、保護する対象のシステムが多いほど、可用性ソリューションはより複雑になりコストがかかるのが普通です。

組織内のすべてのソリューションに必ずしも同じレベルの可用性が要求されるわけではありません。サイトごと、サービスごと、またはファームごとに異なるレベルの可用性を提供できます。

この記事の内容

  • 可用性の概要

  • 可用性の戦略とレベルの選択

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

可用性の概要

可用性とは、SharePoint Foundation 環境が使用可能であるとユーザーが認識する度合いです。使用可能なシステムとは、回復力があるシステムのことです。つまり、サービスに影響するインシデントがあまり発生せず、そのようなインシデントが発生しても、タイムリーで効果的な処置がとられることを意味します。

可用性はビジネス継続性管理 (BCM) の一部であり、バックアップと復元および障害復旧に関連しています。これらの関連プロセスの詳細については、「バックアップと復元を計画する (SharePoint Foundation 2010)」および「障害復旧の計画 (SharePoint Foundation 2010)」を参照してください。

注意

可用性の計算に際し、ほとんどの組織は、計画的なメンテナンス作業の時間を明示的に除外または追加します。

可用性の最も一般的な尺度の 1 つは、"9 の数" で表したアップタイムの割合、つまり、システムがアクティブで、なおかつ動作している時間の割合です。たとえば、アップタイムの割合が 99.999 のシステムは、可用性がファイブ ナイン (9 が 5 個) であると表現されます。

次の表は、稼働率とそれに対応する時間数を示しています。

許容される稼働率 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 週間の稼働率を計算できます。

  • *1 年あたりの稼動率 = 100 - (8760 - 1 年あたりのダウンタイムの合計時間数)/8760

  • *1 か月あたりの稼動率 = 100 - ((24 × その月の日数) - その月のダウンタイムの合計時間数)/(24 × その月の日数)

  • *1 週間あたりの稼働率 = 100 - (168 - その週のダウンタイムの合計時間数)/168

可用性のコスト

可用性は、システムに関する要件の中で比較的コストがかかるものの 1 つです。可用性のレベルが高く、保護する対象のシステムが多いほど、可用性ソリューションはより複雑になりコストがかかるのが普通です。可用性に投資する場合、以下のようなコストが含まれます。

  • ハードウェアおよびソフトウェアの追加。ソフトウェア アプリケーションおよび設定の間での相互作用の複雑さが増大する可能性があります。

  • 運用上の複雑さの増大。

可用性を向上させるコストは、ビジネス ニーズとの関連で評価する必要があります。組織内のすべてのソリューションに必ずしも同じレベルの可用性が要求されるわけではありません。サイトごと、サービスごと、またはファームごとに異なるレベルの可用性を提供できます。

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

可用性要件の決定

サイト、サービス、またはファームのダウンタイムに対する組織の許容度を調べるため、次の質問に答えてください。

  • サイト、サービス、またはファームが利用できなくなった場合、従業員は任務を十分に果たせなくなりますか。

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

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

可用性の戦略とレベルの選択

以下のものを含めて、数多くの手法の中から、SharePoint Foundation 環境で可用性を向上させる手法を選択できます。

  • サーバー ハードウェア コンポーネントのフォールト トレランスを向上させる。

  • ファーム内のサーバー ロールの冗長性を高める。

ハードウェア コンポーネントのフォールト トレランス

ハードウェア コンポーネントのフォールト トレランスとは、ハードウェア コンポーネントとインフラストラクチャ システム (サーバー レベルでの電源装置など) の冗長性です。ハードウェア コンポーネントのフォールト トレランスを計画するときは、次の点を考慮してください。

  • サーバー内のすべてのコンポーネントを完全に冗長にするのは、通常、不可能であるか、そうでなくても実際的ではありません。冗長性を高めるには、サーバーを追加します。

  • 冗長性を最大化するには、サーバーに複数の電源装置を用意し、それぞれを異なる電源に接続します。

どのようなシステムでも、ハードウェア ベンダーと協力して、RAID (Redundant Array of Independent Disks) アレイなど、システムに適したフォールト トレラントなハードウェアを調達することをお勧めします。

ファーム内の冗長性

SharePoint Foundation 2010 は、ファーム内の冗長なコンピューター上でのサーバー ロールの実行 (つまり、スケール アウト) をサポートしており、これにより容量を増やしたり、基本的な可用性を提供できます。

必要とする容量によって、ファーム内のサーバーの数とサーバーのサイズの両方が決まります。基本的な容量要件を満たした後、さらにサーバーを追加して、全体的な可用性を高めることができます。次の図に、各サーバー ロールに冗長性を与える方法を示します。

サーバー ファーム内の可用性

単一ファームの可用性

次の表に、SharePoint Foundation 2010 環境でのサーバー ロールと、ファーム内でそれぞれに使用できる冗長性戦略を示します。

サーバー ロール ファーム内での望ましい冗長性戦略

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

ファーム内に複数のフロントエンド Web サーバーを展開し、ネットワーク負荷分散 (NLB) を使用します。

アプリケーション サーバー

ファーム内に複数のアプリケーション サーバーを展開します。

データベース サーバー

クラスタリングまたは高可用性データベース ミラーリングを使用して、データベース サーバーを展開します。

データベース可用性戦略

Microsoft SQL Server フェールオーバー クラスタリングまたは SQL Server 高可用性データベース ミラーリングを使用して、SharePoint Foundation 環境でのデータベースの可用性をサポートできます。

SQL Server フェールオーバー クラスタリング

フェールオーバー クラスタリングは、SQL Server のインスタンスに対する可用性をサポートします。フェールオーバー クラスターは、1 つ以上のノードまたはサーバーと 2 つ以上の共有ディスクを組み合わせたものです。フェールオーバー クラスターのインスタンスは、単一のコンピューターとして表示されますが、現在のノードが使用できなくなった場合に別のノードにフェールオーバーできる機能を備えています。SharePoint Foundation は、SQL Server でサポートされる 1 つのクラスター内のアクティブ ノードとパッシブ ノードの任意の組み合わせで実行できます。

SharePoint Foundation はクラスターを全体として参照するため、フェールオーバーは SharePoint Foundation から見ると自動的かつシームレスに実行されます。

フェールオーバー クラスタリングの詳細については、「SQL Server 2008 R2 フェールオーバー クラスタリングの概要」 (https://go.microsoft.com/fwlink/?linkid=102837&clcid=0x411) および「SQL Server クラスタリングを使用して可用性を構成する (SharePoint Foundation 2010)」を参照してください。

SQL Server 高可用性ミラーリング

データベース ミラーリングは、データベース単位でデータベースの冗長性を実現できる、SQL Server のテクノロジです。データベース ミラーリングでは、プリンシパル データベースのトランザクション ログ バッファーがディスクに書き込まれるたびに、プリンシパル データベースおよびプリンシパル サーバーからミラー データベースおよびミラー サーバーに直接トランザクションが送信されます。この技法により、ミラー データベースをプリンシパル データベースとほぼ同じ最新の状態に同期することができます。SQL Server Enterprise Edition には、データベース ミラーリングのパフォーマンスを向上させる追加的な機能があります。

SharePoint Foundation ファーム内のミラーリングでは、自動フェールオーバー機能付き高安全性モードとも呼ばれる高可用性ミラーリングを使用する必要があります。高可用性データベース ミラーリングには、プリンシパル、ミラー、および監視という 3 つのサーバー インスタンスが関与します。監視サーバーは、SQL Server によるプリンシパル サーバーからミラー サーバーへの自動的なフェール オーバーを可能にします。通常、プリンシパル データベースからミラー データベースへのフェールオーバーには数秒かかります。

以前のバージョンからの変更点の 1 つは、SharePoint Foundation がミラーリングに対応したことです。SQL Server のデータベース ミラー インスタンスを構成した後は、SharePoint サーバーの全体管理または Windows PowerShell コマンドレットを使用して、構成データベース、コンテンツ データベース、またはサービス アプリケーション データベースのフェールオーバー (ミラー) データベース サーバーの場所を特定します。フェールオーバー データベースの場所を設定すると、SharePoint Foundation が SQL Server への接続に使用する接続文字列にパラメーターが 1 つ追加されます。SQL Server のタイムアウト イベントが発生した場合は、以下の処理が行われます。

  1. SQL Server ミラーリング用に構成されたミラーリング監視サーバーが、プライマリ データベースとミラー データベースのロールを自動的に入れ替えます。

  2. SharePoint Foundation が、フェールオーバー データベースとして指定されたサーバーとの接続を自動的に試みます。

データベース ミラーリングを構成する方法の詳細については、「SQL Server データベース ミラーリングを使用して可用性を構成する (SharePoint Foundation 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 Foundation 2010 はクラスターを参照するので、フェールオーバーはシームレスかつ自動的です。

障害はデータベースによって自動的に検出されます。SharePoint Foundation 2010 は、適切に構成されていればミラーの場所を知っているので、フェールオーバーは自動的です。

記憶域の障害に対する保護

記憶域はクラスター内のノード間で共有されるので、記憶域の障害に対する保護はありません。

プリンシパルとミラーのデータベース サーバーはどちらもローカル ディスクに書き込むので、記憶域の障害に対する保護があります。

サポートされる記憶域の種類

共有ストレージ (高価)。

安価な DAS (Direct-attached Storage) を使用できます。

場所の要件

クラスターのメンバーが同じサブネット上にあることが必要です。

プリンシパル サーバーとミラー サーバーとミラーリング監視サーバーが同じ LAN 上にあることが必要です (最高で 1 ミリ秒の待機時間ラウンドトリップ)。

復旧モデル

SQL Server の完全復旧モデルが推奨です。SQL Server の単純復旧モデルも使用できますが、クラスターが失われた場合に使用できる復旧ポイントは、最後の完全バックアップだけになります。

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

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

フェールオーバーの最中はパフォーマンスがいくらか低下することがあります。

高可用性ミラーリングは同期により、トランザクションの待機時間を発生させます。また、メモリとプロセッサの追加的なオーバーヘッドも必要になります。

運用上の負担

セットアップとメンテナンスがサーバー レベルで行われます。

運用上の負担はクラスタリングより大きくなります。すべてのデータベースについてセットアップとメンテナンスが必要です。フェールオーバー後の再構成は手動です。

サービス アプリケーション冗長性戦略

ファーム内で実行されるサービス アプリケーションを保護するための冗長性戦略は、それぞれのサービス アプリケーションがデータをどこに格納するかに応じて異なったものになります。

データをデータベースに格納するサービス アプリケーション

データをデータベースに格納するサービス アプリケーションを保護するには、以下の手順を実行する必要があります。

  1. サービスを複数のアプリケーション サーバーにインストールして、環境内で冗長性を持たせます。

  2. SQL Server のクラスタリングまたはミラーリングを構成して、データを保護します。

以下のサービス アプリケーションは、データをデータベースに格納します。

  • Business Data Connectivity Service アプリケーション

  • Application Registry Service アプリケーション

    Application Registry データベースのミラーリングはお勧めしません。これは Windows SharePoint Services 3.0 のビジネス データ カタログ情報を SharePoint Foundation 2010 にアップグレードするときにのみ使用されます。

  • Usage and Health Data Collection Service アプリケーション

    注意

    Usage and Health Data Collection Service アプリケーションのログ データベースをミラー化しないことをお勧めします。

  • Microsoft SharePoint Foundation Subscription Settings Service

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

一部の企業では、複数のデータ センターを単一のファームとして構成できるように各データ センターを高帯域幅の接続によって近接配置しています。これを "ストレッチド" ファームと呼びます。ストレッチド ファームが機能するためには、SQL Server とフロントエンド Web サーバーとの間の一方向での遅延が 1 ミリ秒未満で、帯域幅が 1 ギガビット/秒以上である必要があります。

このシナリオでは、データベースとサービス アプリケーションを冗長にするための次の標準ガイドラインに従うことで、フォールト トレランスを提供できます。

次の図に、ストレッチド ファームを示します。

ストレッチド ファーム

"ストレッチ" ファーム