サーバー クラスタ : Windows 2000 および Windows Server 2003 に関するよく寄せられる質問

Microsoft Corporation

発行 : 2003 年 1 月

概要

この資料は、Microsoft Windows 2000 および Windows Server 2003 に関してよく寄せられる質問についての情報を記載しています。 これら 2 種類のオペレーティング システムの間で異なる点については、 特に明示的に示しています。

トピック

このドキュメントの構成

最もよく寄せられる質問

サーバー クラスタの概要

可用性

管理と展開

スケーラビリティ

サーバー クラスタの概念

サーバーの必要条件

相互接続

記憶域

可用性の高いファイル サーバー

可用性の高いプリント サーバー

単一障害点の排除

Active Directory、DNS、ドメイン コントローラ

セキュリティ上の考慮点

パッケージに含まれる高可用性サービス

地理的に分散したクラスタ

クォーラム

クラスタ対応アプリケーション

その他のトピック

このドキュメントの構成

概念から展開、運用上の手順まで、 サーバー クラスタに関するさまざまな情報を、 次のような多様なセクションに記載しています。

• サーバー クラスタの概要
• 可用性
• 管理と展開
• スケーラビリティ
• サーバー クラスタの概念
• サーバーの必要条件
• 相互接続
• 記憶域
• 可用性の高いファイル サーバー
• 可用性の高いプリント サーバー
• 単一障害点の排除
• Active Directory とドメイン コントローラ
• セキュリティの考慮点
• パッケージに含まれる高可用性サービス
• 地理的に分散したクラスタ
• クォーラム
• クラスタ対応アプリケーション
• その他のトピック

 ページのトップへ

最もよく寄せられる質問

• 使用しているサーバー クラスタが、サポート済みの構成であるかどうかを知るには?
• 1 つのクラスタには何台のサーバーを構成できますか?
• 1 つのクラスタに 3 つ以上のノードが存在することの利点は?
• クラスタでは、ダイナミック ディスクはサポートされますか?
• クラスタ ディスクは、コンピュータの再起動なしに拡張できますか?
• クラスタ内で障害が発生したディスクを交換する方法は?
• SAN ではサーバーの分離にゾーニングが必要になる理由は?
• クラスタ サーバーは SAN から起動できますか?
• クラスタでホストされるサービスに Kerberos 認証を使用できますか?
• IIS はクラスタに対応していますか?
• サーバー クラスタは複数のサイト間で構成できますか?
• マイクロソフトはクラスタ ファイル システムを提供する予定ですか?

 ページのトップへ

サーバー クラスタの概要

サーバークラスタとは何ですか?

サーバー クラスタは、 独立したサーバーの集合です。 この集合内のサーバーは、相互に連携して、 アプリケーションをホストするための 1 つの可用性の高いプラットフォームを提供します。

サーバークラスタの利点は何ですか?

サーバー クラスタの主な利点には、可用性、管理性、スケーラビリティの 3 つがあります。

可用性 :	サーバー クラスタは、 アプリケーションを展開するための可用性の高いプラットフォームを提供します。 サーバー クラスタを使用すると、 保守のために計画されたダウンタイムや、 障害による予期せぬダウンタイムが発生した場合に、 アプリケーションを継続して実行できます。 サーバー クラスタは、 ハードウェア障害や、Windows オペレーティング システム、 デバイス ドライバ、 アプリケーション ソフトウェアのエラーに対する保護を提供します。 サーバー クラスタでは、 オペレーティング システムやアプリケーション ソフトウェアを、 そのアプリケーションを停止させることなく、 クラスタ全体にまたがってアップグレードできます。
管理性 :	サーバー クラスタでは、 管理者が、すべてのクラスタ リソースの状態をすばやく検査し、 クラスタ内の別のサーバーにワークロードを移動できます。 これは、手動の負荷分散、 さらに、重要なデータやアプリケーションをオフラインにすることのない "ローリング アップデート" をサーバーに対して実行する場合に役に立ちます。
スケーラビリティ :	"パーティション分割" できるアプリケーションは、 クラスタ内の複数のサーバーに分散でき、 より多くの CPU とメモリを任意の問題に割り当てることができます。 問題が大きくなるに従い、クラスタにサーバーをさらに追加できます。 パーティション分割されたアプリケーションとは、 データ (または機能) を独立した単位に分割できるアプリケーションのことです。 たとえば、1 つの顧客データベースは、 名前が A から始まる顧客と L から始まる顧客までを格納したデータベースと、 M から始まる顧客と Z から始まる顧客までを格納したデータベースの 2 つの単位に分割できます。

サーバークラスタは何のために使用されるのですか?

サーバー クラスタは、 基幹業務アプリケーション向けに高可用性プラットフォームを提供します。 サーバー クラスタには、通常、 データベース サーバー (Microsoft SQL Server™ など)、 メール サーバーやコラボレーション サーバー (Exchange Server など)、 およびファイル サーバーやプリント サーバーなどのインフラストラクチャ サーバーが含まれます。

サーバークラスタは、Microsoft Cluster Server (MSCS) や "Wolfpack" と同じものですか?

最初のサーバー クラスタ プロジェクトのコード名が "Wolfpack" でした。 この製品が Microsoft Windows NT 4.0 Enterprise Edition の一部としてリリースされた際に付けられた名前が、Microsoft Cluster Server (MSCS) です。 Microsoft Windows 2000 では、 この製品の正式名称がサーバー クラスタになりました。

サーバークラスタは、より大規模な Windows の高可用性構想においては、どのような位置付けにあるのでしょうか?

サーバー クラスタは、Windows プラットフォーム上で実行される高可用性アプリケーション向けの、 より大規模な構想の一部をなすものです。Windows には、 サーバー クラスタ、ネットワーク負荷分散 (NLB)、 コンポーネント負荷分散 (CLB) の 3 つの異なるクラスタ テクノロジがあります。 サーバー クラスタは、 障害時にアプリケーションをサーバーからサーバーに "フェールオーバー" し、 データベース (たとえば、SQL Server) のような "状態を持つ" アプリケーションの高可用性を確実に維持できるようにするために使用されます。 NLB は、クライアント要求を同じ構成のサーバーのセットに分散します。 NLB は、Web サーバー (IIS など) のような "状態を持たない" アプリケーションの高可用性を確実に維持し、 負荷が増すに従ってサーバーを追加してスケールアウトできるようにするために使用されます。 CLB は、COM+ アプリケーションの高可用性を確実に維持し、 スケールアウトできるようにするために使用されるテクノロジです。 Windows プラットフォームのその他のインフラストラクチャは、 他の技法を使用して高可用性とスケーラビリティを保証します。 たとえば、Active Directory は、 ディレクトリの内容をドメイン コントローラのセットにレプリケートすることで、 高可用性を実現しています。

スケールアップとスケールアウトの違いは?

スケールアップは、 対規模な対称型マルチプロセッシング (SMP) システムによって提供されるスケーラビリティを表す場合に使用される用語です。 負荷の増加に伴い、プロセッサとメモリを各サーバーに追加して、 処理能力を高め、 アプリケーションが利用できるメモリを増加できます。 Windows 2000 Datacenter Server や Windows Server 2003 Datacenter Edition では、 多数の CPU および大容量の物理メモリが実装されている大型コンピュータへのスケールアップのサポートが提供されています。 スケールアウト環境では、 サーバー クラスタが展開され、 サーバーの障害がアプリケーションやサービスのエラーにつながらないようにします。 スケールアップは、通常、 パーティション分割できない大きなアプリケーションをホストするため、 またはいくつかのアプリケーションを 1 台のサーバー (サーバー クラスタの場合は、より少数のサーバー) に統合するために行われます。

スケールアウトは、 アプリケーションは、ワークロードをパーティション分割し、 それをいくつかの協調して動作するサーバーに分散することで拡張できるという考えを表す場合に使用される用語です。 負荷の増加に伴い、この協調して動作するサーバー群にサーバーを追加して、 処理能力とメモリ量を増加できます。

サーバー クラスタは、 フェールオーバーを利用してスケールアウト ソリューションの各部分やパーティションの高可用性を実現することで、 いくつかのノードにまたがってスケールアウトできるアプリケーションの利用可能性を高める場合に特に役立ちます。

サーバークラスタは、Windows オペレーティングシステム製品の標準機能ですか?

サーバー クラスタは、 すべての Windows オペレーティング システム製品で提供されているわけではありません。 サーバー クラスタは、次の製品で提供されています。

• Windows NT Server Enterprise Edition
• Windows 2000 Advanced Server および Datacenter Server
• Windows Server 2003 Enterprise Edition および Datacenter Edition
• Windows Server 2003 Enterprise Edition および Datacenter Edition (64 ビット)

サーバー クラスタは、Microsoft Server Appliance Kit にも含まれています。 また、Windows オペレーティング システム ベースの埋め込みソリューションの開発用に OEM にも提供されています。

使用しているサーバークラスタがサポート済み構成であるかどうかを知るには?

すべてのサーバー クラスタは、 マイクロソフトによってサポートされるための条件を満たしていると認定される必要があります。 認定済みの構成は、 マイクロソフトから提供されるハードウェア互換性テストを使用して、 広範なテストを実施されています。 認定済みのソリューションは、https://www.microsoft.com/japan/hwdq/hcl/で公開されている Microsoft ハードウェア互換性リスト (HCL) に記載されています。 マイクロソフトによってサポート済みのクラスタ ソリューションは、HCL に記載されているもののみです。

完全なクラスタ ソリューションは、HCL の 「Cluster」 の一覧に記載されている必要があります。 完全なクラスタ ソリューションには、 サーバー、ストレージ アダプタ、相互接続の種類、ストレージ コントローラ ファームウェアおよびドライバのバージョンが記載されています。 ソリューションが認定されるためには、 ソフトウェア、ドライバ、ファームウェアのバージョンも含め、 すべてのコンポーネントが正確に一致している必要があります。

HCL には、認定済みの一連のクラスタ コンポーネントが記載されています。 ただし、認定済みのコンポーネントを使用してソリューションを構築したとしても、 そのソリューションが認定されたものになるとは限りません。

クラスタコンポーネントの一覧は、これまで混乱の原因となってきました。したがって、Windows Server 2003 の HCL からクラスタコンポーネントの一覧 (Cluster/RAID など) は削除される予定です。

サポート済みの構成の一覧はどこで公開されていますか?

認定済みのソリューションは、https://www.microsoft.com/whdc/default.mspx(英語)で公開されている Microsoft ハードウェア互換性リスト (HCL) に記載されています。 マイクロソフトによってサポートされているクラスタ ソリューションは、HCL に記載されているもののみです。

サーバークラスタについてのその他のドキュメントはどこで公開されていますか?

サーバー クラスタについては、Windows 2000 および Windows Server 2003 のオンライン ヘルプに多くの情報が記載されています。 それ以外の情報については、 次のマイクロソフトの Web サイトで公開されています。

• https://www.microsoft.com/windows2000/ja/advanced/help/win_cluster.htm?id=426
• https://www.microsoft.com/technet/archive/winntas/default.mspx (英語)
• https://www.microsoft.com/japan/windowsserver2003/technologies/clustering/default.mspx

 ページのトップへ

可用性

サーバークラスタによって、アプリケーションのダウンタイムを 0 にできますか?

• いいえ、できません。 サーバー クラスタは、 計画されたダウンタイムや予期せぬダウンタイムを劇的に削減することはできます。 しかし、サーバー クラスタを使用したとしても、 次のような場合はサーバーでダウンタイムが発生する可能性があります。
• "フェールオーバー時" : サーバー クラスタがサーバーまたはアプリケーション エラーから回復した場合、 またはアプリケーションをサーバーからサーバーに移動するために使用されていた場合は、 アプリケーションはある程度の期間 (通常、1 分未満) のダウンタイムを余儀なくされます。
• "サーバー クラスタが回復できないエラーの発生時" : サーバー クラスタが対応できないエラーがあります。 たとえば、RAID により保護されていないディスクの喪失、UPS が使用されていない場合の電力の停止、 早期障害回復計画が設定されていない場合のサイトの停止などです。 これらのほとんどは、あらかじめ対策を講じている場合は、 最小限のダウンタイムで障害に対応できます。
• "ダウンタイムを必要とするサーバーの保守" : サーバー クラスタは、サーバーの保守でも多くの場合は、 アプリケーションやデータをオンラインにしておくことができますが、 例外もあります (たとえば、アプリケーションの新規バージョンをインストールするときに、 そのアプリケーションが、既存のデータの形式を変換する必要のある新しいディスク データ形式を使用する場合)。

マイクロソフトでは、 サーバー ベースの基幹データおよびアプリケーションの高い整合性および可用性を実現するために、 ユーザーの計画全体の中の 1 要素として、 クラスタを使用することをお勧めしています。

サーバークラスタが役に立つアプリケーションやサービスの種類は?

サーバー クラスタが役に立つサーバー アプリケーションには、次の 3 種類があります。

1. "Windows プラットフォームの「パッケージに含まれる」サービス" : たとえば、ファイル共有、印刷キュー、Microsoft メッセージ キュー サーバー (MSMQ) サービス、 Microsoft Transaction Server (MTS) サービス。
2. "汎用アプリケーション" : サーバー クラスタには、ポイント アンド クリック方式のウィザードが用意されていて、 このウィザードを使用すると、正しく機能するサーバー アプリケーションに対して基本的なエラー検出、 自動回復、オペレータによる管理 (サーバーからサーバーへの移動など) を実行するための設定が可能です。 "正しく機能する" サーバー アプリケーションとは、 クラスタ ディスク上に回復状態を保持するアプリケーションで、 アプリケーションが自動的に再起動するとそのクライアントによって処理中の一時停止状態が滞りなく処理されるアプリケーションのことです。
3. "クラスタ対応アプリケーション" : ソフトウェア ベンダのアプリケーション製品で、サーバー クラスタ上でテスト済みかつサポート済みのアプリケーションです。

 ページのトップへ

管理と展開

サーバークラスタには、管理用に 1 つに統合されたビューが用意されていますか?

はい。 サーバー クラスタには、 グラフィカル インターフェイス (クラスタ アドミニストレータ) とコマンド ライン ツール (Cluster.exe – Windows 2000 および Windows Server 2003 で提供) が用意されています。 管理者は、これらを使用して、 クラスタ内のすべてのリソースをまるで単一のシステムであるかのように監視、 管理できます。管理者は、次の操作を行うことができます。

• クラスタ内のすべてのサーバーおよびアプリケーションの状態の監視
• 高可用性を実現するための、新しいアプリケーション、ファイル共有、印刷キューなどの設定
• アプリケーションおよびリソースの回復ポリシーの管理
• アプリケーションのオフライン、オンラインの切り替え、およびサーバーからサーバーへの移動

サーバーからサーバーにほんのわずかな停止時間 (通常、1 分以下) でワークロードをグラフィカルに移動できるので、 管理者は計画された保守の間、 重要なデータやアプリケーションを長時間オフラインにすることなく、 サーバーを容易にアンロードできます。

サーバークラスタはリモートで管理できますか?

はい。 権限のあるクラスタの管理者は、 ネットワーク上のすべての Windows NT または Windows 2000 Workstation または Server、 すべての Windows XP コンピュータ、 またはすべての Windows Server 2003 からクラスタ アドミニストレータを実行できます。 Cluster.exe コマンド ライン ツールは、 ネットワーク上のすべての Windows 2000 Workstation または Server、 すべての Windows XP コンピュータ、 またはすべての Windows Server 2003 からリモートで実行できます。

サーバークラスタをリモートからセットアップおよび構成できますか?

はい。クラスタ アドミニストレータおよび Cluster.exe コマンド ライン ツールは、 Windows Server 2003 からリモートのセットアップおよび構成 (新しいクラスタの作成、既存のクラスタへの新しいサーバーの追加、クラスタからのサーバーの削除など) にも使用できます。

サーバークラスタソフトウェアは既定でインストールされますか?

Windows NT および Windows 2000 では、 サーバー クラスタ ソフトウェアは既定ではインストールされません。 Windows NT の場合は、Enterprise Edition CD-ROM を使用してインストールする必要があります。 Windows 2000 の場合は、 オプションのコンポーネント管理ツールを使用して、 サーバー クラスタ ソフトウェアをインストールする必要があります。

Windows Server 2003 の場合、Enterprise Edition および Datacenter Edition では、 サーバー クラスタ ソフトウェアは既定でインストールされます。 ただし、クラスタ ソフトウェアは既定では構成されないので、 サーバーが新しいクラスタの作成に使用されるか、 既存のクラスタに追加されるまでは、 クラスタ ソフトウェアは起動されません。 Windows Server 2003 では、 クラスタ アドミニストレータまたは Cluster.exe コマンド ライン ツールを使用してクラスタを構成する必要があります。

サーバークラスタは、自動インストールを使用してインストールおよび構成できますか?

はい。Windows 2000 クラスタの自動インストールを Uttend.txt ファイルを使用して実行するには、 Windows 2000 CD-ROM にある『Windows 2000 導入ガイド』 (%CDROM%\SUPPORT\TOOLS\DEPLOY.CAB\Unattend.doc) を参照してください。

それ以外の情報については、 サポート技術情報の文書、 「176507 Unattended Installation of MSCS Service」 (英語) を参照してください。

アプリケーションは、すべてのクラスタサーバーに個別にインストールする必要がありますか?

これは、アプリケーションによって異なります。 クラスタのサーバー間でフェールオーバーされる各アプリケーションは、 クラスタのすべてのサーバーにインストールされている必要があります。 慣例的に、アプリケーションのセットアップはクラスタ対応ではないので、 アプリケーションはサーバーごとに個別にインストールされる必要があります。

SQL Server 2000 など、 いくつかのアプリケーションの最近のバージョンでは、 アプリケーションのセットアップがサーバー クラスタ対応になっています。 Microsoft SQL Server 2000 セットアップの場合は、 該当するファイルがすべてのサーバーにコピーされ、 レジストリの設定やその他の SQL Server の構成が一度に完了します。

クラスタの管理操作はスクリプトにすることができますか?

はい。次のような、管理操作をスクリプトにするためのオプションがいくつかあります。

• Cluster.exe コマンド ライン ツールを使用すると、 クラスタ リソースの状態の変更や、 リソースの移動などを実行できるコマンド ファイルを作成できます。 このコマンド ライン ツールの詳細については、 オンライン ヘルプを参照するか、 サーバー クラスタまたは Windows Server 管理者パックがインストールされているサーバーで、 コマンド ラインに "cluster" と入力してください。
• Windows 2000 および Windows Server 2003 には、 サーバー クラスタ API へのスクリプト可能な COM インターフェイスが用意されています。 これにより、VBScript やその他の Windows がサポートするスクリプト言語を使用して、 クラスタ API を呼び出すことができます。 これらの API を使用すると、 クラスタの状態を変更するだけでなく、 クラスタ内のリソースやアプリケーションに関するデータを返すこともできます。 クラスタ サーバー API の詳細については、 プラットフォーム SDK を参照してください。 プラットフォーム SDK には、クラスタ API と COM (オートメーション サーバー) API についての総合的なドキュメントが用意されています。
• Windows Server 2003 には、WMI スクリプトを使用してサーバー クラスタを管理することができる、 サーバー クラスタ用の WMI プロバイダが用意されています。 クラスタ サーバー WMI スキーマの詳細については、 プラットフォーム SDK を参照してください。

コマンドラインツールを使用してクラスタを管理できますか?

はい。サーバー クラスタには、 クラスタの管理に使用できるコマンド ツール Cluster.exe が用意されています。 Windows Server 2003 では、 このコマンド ライン ツールを使用して、 新しいクラスタを作成したり、 既存のクラスタにサーバーを追加したり、 クラスタからサーバーを削除できます。 Windows Server 2003 では、 クラスタ アドミニストレータが提供する機能のほとんどは、Cluster.exe を利用して実現できます。

クラスタの管理に WMI はサポートされていますか?

はい。Windows Server 2003 には、 サーバー クラスタを管理することができる、WMI プロバイダが用意されています。 また、すべてのサーバー クラスタ イベント (サーバーの起動や停止、リソースのオンライン、オフライン、失敗など) は、 WMI イベントを利用して通知できます。

サーバークラスタは、WMI イベントをサポートしますか?

はい。Windows Server 2003 では、 すべてのサーバー クラスタ イベント (サーバーの起動や停止、リソースのオンライン、オフライン、失敗など) は、WMI イベントを利用して通知できます。

クラスタサーバーでグループポリシーを使用できますか?

クラスタ サーバーにグループ ポリシーを適用することはできます。 ただし、注意しておく必要のあることが、2、3 あります。 アプリケーションは、 クラスタ内のサーバーからサーバーにフェールオーバーされますが、 通常、どのサーバーにホストされるとしても、 同じポリシーが適用されているものとして、動作します。 確実に、すべてのクラスタ サーバーで同じグループ ポリシーが適用されるようにしてください。

Windows Server 2003 および Windows 2000 SP3 以降では、Active Directory で仮想サーバーを公開できます。 仮想サーバー コンピュータ オブジェクトには、 グループ ポリシーを適用しないでください。 ポリシーは、現在、仮想サーバーをホストしているサーバーにのみ適用され、 アプリケーションがフェールオーバーされた場合、 すべてのポリシー設定が失われる可能性があります。

サーバークラスタでのアプリケーションの展開に、Systems Management Server (SMS) はサポートされていますか?

いいえ。現時点では、クラスタでのアプリケーションの展開に、SMS はサポートされていません。

サーバークラスタで Application Center 2000 はサポートされますか?

いいえ。Application Center 2000 は、Web サーバーのフロントエンドと中間層のビジネス ロジックをホストするサーバーを管理するための一連の機能を提供しています。 サーバー クラスタは、通常、 バックエンドのデータベース エンジンの高可用性を確保するために導入されます。

MOM 管理パックは、サーバークラスタの管理に利用できますか?

いいえ。現時点では、サーバー対応の MOM 管理パックはありません。

サーバークラスタは、"ローリングアップグレード" の実行にどのように役立つのですか?

サーバー クラスタでは、 オンラインのユーザーが 1 人もいないというめったにない時間枠の中ですべての保守を行う必要はなくなりました。 代わりに、クラスタ内のサーバーのうちの 1 台を保守のために切り離し、 他のクラスタ サーバーにワークロードを分散できるほど混雑していない、 都合のよい時間帯になるまで待てばよいだけです。 クラスタ アドミニストレータでポイント アンド クリックして (または、スクリプトを使用して)、 ワークロードのすべてを他のサーバーに移行することで、 クラスタ内のサーバーのうち 1 台をアップグレードできます。 アップグレードが完了し、テストが終了したら、 このサーバーは再起動された時点で自動的にクラスタに再び参加し、 機能できるようになります。 必要に応じて、同様の手順を繰り返し、 クラスタ内の他のサーバーでも保守を実行します。 サーバー保守の実行中もアプリケーションとデータをオンラインにしておくことができるこの能力を、 サーバーに "ローリング アップグレード" を行うと表現することがよくあります。

サーバー クラスタでは、新規リリースおよび 1 つ前のバージョンのローリング アップグレードを行うことができます。

ローリングアップグレードをサポートする Windows のバージョンの組み合わせは?

サーバー クラスタでは、 新規リリースおよび 1 つ前のバージョンのローリング アップグレードを行うことができます。 次のローリング アップグレードがサポートされています。

• Windows NT Enterprise Edition から Windows 2000
• Windows 2000 から Windows Server 2003

1 つのクラスタアドミニストレータツールから、サーバークラスタの異なるバージョンを管理できますか?

はい。 サーバー クラスタ ツールを使用して、1 箇所から異なるバージョンのクラスタを管理できます。 ローリング アップグレード中は、 クラスタには異なるバージョンのオペレーティング システムが混在している場合があります。 たとえば、Windows 2000 と Windows Server 2003 が、 同じクラスタに混在している可能性があります。 Windows Server 2003 で提供されている管理ツールでは、 そのような異なるバージョンが混在するクラスタを管理できます。

サーバークラスタには、その他にも管理に関する利点はありますか?

サーバー クラスタでは、 管理者が、すべてのクラスタ リソースの状態をすばやく検査し、 クラスタ内の別のサーバーにワークロードを移動させることができます。 これは、手動の負荷分散、 および重要なデータやアプリケーションをオフラインにすることのない "ローリング アップデート" をサーバーに対して実行する場合に役に立ちます。

 ページのトップへ

スケーラビリティ

サーバークラスタを使用すると、サーバーのスケーラビリティを強化できますか?

サーバー クラスタの最大の目的は、 アプリケーションを展開するための可用性の高いプラットフォームを提供することです。

アプリケーションの中には、 コンピュータの集合を利用してスケールアウトできるものがあります。 より多くのコンピュータをこのコンピュータの集合に追加できれば、 これらのアプリケーションが利用できる CPU やメモリを増加できます。 このようなアプリケーションは、通常、 データ セットを分割することでスケール変換します。 たとえば、SQL Server データベースは、 データベースをパーティション分割したデータベース ビューを使用して、 クライアント アプリケーションにはあたかも単一のデータベースであるかのように見せることで、 スケールアウトすることもできます。

サーバー クラスタでは、 アプリケーションをパーティション分割したり、 スケールアウトする機能は提供されていませんが、 サーバー クラスタを使用すると、 そのようなアプリケーションを可用性の高い環境でスケールアウトできます。 パーティション分割された各部分は、 独立してコンピュータの集合内で (または、その他の予備ノードに) フェールオーバーできるので、 障害が発生した場合も、アプリケーションの一部は利用できます。

サーバークラスタでは、アプリケーションの負荷分散機能は提供されていますか?

サーバー クラスタには、 手動の負荷分散メカニズムが用意されています。 アプリケーションをクラスタのサーバー間で移動させて、 負荷を分散できます。

アプリケーションの負荷分散を自動的に行うツールで、 オペレーティング システムとともに提供されている自動ツールはありません。 また、負荷を計測してアプリケーションを配置する最適な場所を決めるような高度なフェールオーバー ポリシーもありません。

 ページのトップへ

サーバー クラスタの概念

サーバークラスタの構築には、どのようなハードウェアが必要ですか?

サーバー クラスタのハードウェアに対する最も重要な条件は、 Microsoft ハードウェア互換性リスト (HCL) に記載されている有効なクラスタ構成に含まれている、 つまり、Microsoft クラスタ ハードウェア互換性テスに合格していることです。 認定済みのソリューションは、https://www.microsoft.com/whdc/default.mspx(英語)で公開されている Microsoft HCL に記載されています。 マイクロソフトによってサポートされているクラスタ ソリューションは、HCL に記載されているもののみです。

一般に、サーバー クラスタを構築するための条件として、次のものがあります。

• サーバー : サーバー クラスタをサポートするオペレーティング システム リリース (下記参照) の 1 つが実行されている、2 台以上の PCI ベースのコンピュータ。 サーバー クラスタは、基礎となる Windows オペレーティング システムがサポートするすべてのハードウェア アーキテクチャ上で実行できますが、 1 つのクラスタに 32 ビットアーキテクチャと 64 ビット アーキテクチャを混在させることはできません。
• 記憶域 : 各サーバーには、システム ディスクやブート ディスク、ページファイル ディスクがあるバスとは別の、 共有の外部記憶域バスを取り付ける必要があります。 アプリケーションやデータは、このバスに取り付けられた 1 台以上のディスクに格納します。 共有クラスタ バスには、クラスタ環境で実行されるすべてのアプリケーションを格納するために十分な記憶容量がある必要があります。 この共有記憶域構成により、クラスタ内のサーバー間でアプリケーションをフェールオーバーできます。 すべてのクラスタ ディスクにハードウェア RAID (Redundant Array of Inexpensive Disks) を採用し、 単一障害点となる可能性のあるディスク ドライブを排除することをお勧めします。 したがって、RAID 記憶装置や "処理機能を持たない" ディスクにまたがり RAID を実装しているホストベースの RAID アダプタなどを使用してください。 SCSI は、2 ノード クラスタ構成でしかサポートされません。 FC-AL (Fibre Channel-Arbitrated Loop) も、2 ノード クラスタでしかサポートされません。 3 ノード以上のクラスタには、ファイバ チャネル スイッチ ファブリックの使用をお勧めします。
• ネットワーク : 各サーバーには、少なくとも 2 枚のネットワーク カードが必要です。 通常、1 枚はパブリック ネットワーク、 もう 1 枚は 2 ノード間のプライベート ネットワーク用です。 ノード間を 1 つの単位として移動するアプリケーション グループごとに、1 つの静的 IP アドレスが必要です。 サーバー クラスタでは、複数の IP アドレスとコンピュータ名を使用して、1 つのクラスタから複数のサーバーの ID を計画できます。 これは、"仮想サーバー" として知られています。

クラスタリソースとは何ですか?

クラスタ リソースは、 サーバー クラスタの最小レベルの管理単位です。 リソースは、物理オブジェクトや実行されているコードのインスタンスを表します。 たとえば、物理ディスク、IP アドレス、MSMQ キュー、COM オブジェクトなど、 これらはすべてリソースであると見なされます。 管理上の観点からは、リソースは、独立して起動および停止させることができ、 リソース 1 つ 1 つを監視して状態に問題がないことを確認できます。

サーバー クラスタは、 任意の種類のリソースを監視できます。 これは、サーバー クラスタによって、リソースの "プラグイン" モデルが定義されるためです。 リソースの種類ごとに、 関連付けられたリソースのプラグインまたは "リソース dll" があり、 これは関連付けられている種類のリソースの起動や停止、 そのリソース固有の状態情報の通知に使用されます。 たとえば、SQL Server の起動方法や停止方法は、 物理ディスクの起動方法や停止方法とは異なります。 この違いは、リソース dll によって処理されます。 アプリケーション開発者やシステム管理者は、 各自のアプリケーション用に新しいリソース dll を作成して、 これらのアプリケーションをクラスタ サービスに登録できます。

サーバー クラスタには、 既存のアプリケーションをすばやくクラスタ対応にするために使用できる汎用プラグインが用意されています。 これは、"汎用サービス" および "汎用アプリケーション" と呼ばれています。 Windows Server 2003 では、"汎用スクリプト" リソース プラグインが追加され、 これにより、リソース dll を Windows でサポートされるすべてのスクリプト言語で作成できるようになっています。

リソースの依存関係とは何ですか?

1 つの完全なアプリケーションは、 実際には複数の部分や複数のリソースで構成されていて、 ある部分はコードであったり、 また別の部分はアプリケーションが必要とする物理リソースであったりします。 これらのリソースは、 それぞれ異なる方法で関連しています。 たとえば、ディスクに書き込みを行うアプリケーションは、 ディスクがオンラインになるまで、オンラインになることができません。 また、ディスクで障害が発生した場合は、 当然、そのアプリケーションは、そのディスクに書き込みをしているため、実行できなくなります。 リソースの依存関係は、このような関係を把握するために、 アプリケーションの開発者やシステム管理者によって定義されます。 リソースの依存関係により、 リソースがオンラインになる順番が決まり、 アプリケーションの異なる構成部分にどのように障害を伝えるかが制御されます。

リソースグループとは何ですか?

リソース グループは、1 つの単位として管理および監視される 1 つ以上のリソースのコレクションのことです。 リソース グループは、 グループごとに起動および停止できます。 リソース グループが起動されると、 グループの各リソースが起動されます (このとき、グループのリソース間の依存関係によって決められた起動順序が考慮されます)。 リソース グループが停止されると、 グループ内のすべてのリソースが停止されます。 リソース間の依存関係が、 グループをまたがって適用されることはありません。 つまり、グループ内のリソースのコレクションは、 独立した単位であり、 他のいかなるグループてゃ無関係に起動および停止できます。 リソース グループは、 どの時点でもサーバー クラスタ内の 1 台のサーバーでホストされる、 分割できない 1 単位であり、 フェールオーバーされる単位になります。

グループの異なるリソース間で依存関係を設定できますか?

いいえ。リソースの依存関係は、1 グループ内に限られます。

仮想サーバーとは何ですか?

仮想サーバーは、IP アドレス リソースとネットワーク名リソースを持つリソース グループです。 アプリケーションが仮想サーバーでホストされている場合、 このアプリケーションには、 そのリソース グループの IP アドレスまたはネットワーク名を使用してクライアントからアクセスできます。 リソース グループはクラスタ内でフェールオーバーされるので、 同じ IP アドレスとネットワーク名を保持できます。 このため、クライアントはアプリケーションの物理的な場所を意識することなく、 クラスタ内のサーバーの 1 台で障害が発生したとしても、 実行し続けることができます。

フェールオーバーとは何ですか?

サーバー クラスタでは、 クラスタ内のノードの状態とクラスタ内のリソースが監視されます。 サーバーで障害が発生した場合は、 クラスタ ソフトウェアは、その障害が発生したサーバーのワークロードを、 クラスタ内の 1 台または複数のその他のサーバーで再び開始します。 リソースまたはアプリケーションの 1 つで障害が発生した場合 (ただし、サーバーは正常な場合) は、 サーバー クラスタは、通常、そのアプリケーションを同じサーバーで再起動します。 再起動できなかった場合は、 そのアプリケーションのリソースを移動し、 別のサーバーで再起動します。 障害を検出し、アプリケーションをクラスタ内の別のサーバーで再起動する処理を "フェールオーバー" と呼びます。

クラスタの管理者は、 アプリケーションを同じサーバーで再起動するかどうかや、 障害が発生したサーバーがオンラインに戻ったときに、 自動的に "フェールバック" する (再び負荷分散を行う) かどうかといった、 さまざまな回復ポリシーを設定できます。

フェールオーバーはユーザーが意識しないで行われますか?

サーバー クラスタでは、 クライアント コンピュータに特別なソフトウェアは必要とされません。 したがって、フェールオーバー中のユーザー エクスペリエンスは、 使用しているクライアント/サーバー アプリケーションのクライアント側の性質により異なります。 クライアントの再接続は、ユーザーが意識しないで行うこともできます。 これは、サーバー クラスタ ソフトウェアによって、 アプリケーション、ファイル共有などがまったく同じ IP アドレスを使用して再起動されるためです。

クライアントが標準的なブラウザ接続など "状態を持たない" 接続を使用している場合は、 サーバー要求の間にフェールオーバーが発生した場合、 クライアントはこれに気付かないと考えられます。 クライアントがその障害の発生したリソースに接続している間に障害が発生した場合は、 サーバー側が利用できなくなった時点で、 アプリケーションのクライアント側から提供される標準的な通知をクライアントは受け取ります。 これは、たとえば、サーバーやネットワークがダウンしているときに、Windows エクスプローラを使用してファイルをダウンロードした場合に受け取る、 標準的な "中止、再試行、キャンセル" のいずれかの選択を求めるメッセージなどです。 この場合、クライアントの再接続は自動的には行われません (ユーザーが "再試行" を選択する必要があります)。 ただし、ユーザーには、発生していることについての情報が十分に与えられ、 簡単で、分かりやすい方法でサーバーへの接続を再確立する方法が提供されます。 もちろん、その間、クラスタ サービスによってサービスまたはアプリケーションの再起動が休まず行われているので、 ユーザーが "再試行" を選択した時点では、 まるで利用できない期間などなかったかのように、 サービスまたはアプリケーションが再び利用可能になります。

フェールバックとは何ですか?

クラスタ内のサーバーで障害が発生した場合、 アプリケーションやリソースは、 そのクラスタ内の他のノードにフェールオーバーされます。 障害が発生したノードがクラスタに再び参加したとき (たとえば、再起動後)、 このノードはアプリケーションによって問題なく使用できる状態にあります。 クラスタの管理者は、リソースやリソース グループにポリシーを設定して、 アプリケーションが、ノードが再び利用可能になった場合に、 自動的にそのノードに戻るようにして、 クラスタに再び参加するノードを自動的に利用できるようにすることができます。 このようなポリシーを "フェールバック" ポリシーと呼びます。 自動フェールバック ポリシーを定義する場合は、 アプリケーションによって、 自動的に (問題なく動作していた) アプリケーションを移動すると、 このアプリケーションを使用していたクライアントに好ましくない影響を与える可能性があるので、注意してください。

アプリケーションがフェールオーバー後再起動する時点はいつですか? 障害発生時のアプリケーションの "状態" は復元されますか?

いいえ、 サーバー クラスタでは、高速クラッシュ再起動メカニズムが提供されています。 アプリケーションがフェールオーバーされて再起動する場合、 このアプリケーションは最初から起動プロセスを開始して再起動されます。 データベースやファイルに書き込まれた保存データは、アプリケーションで利用できますが、 フェールオーバー前のアプリケーションのメモリ内の状態は、失われます。

フェールオーバーの粒度 (単位) は何ですか?

フェールオーバーの粒度は、リソース グループです。

"クォーラムリソース" とは何ですか? また、これは、サーバークラスタでの高可用性の実現にどう役立つのですか?

サーバー クラスタが機能するためには、クォーラム リソースが必要です。 クォーラム リソースは、 他のリソースと同様に、一度に 1 台のサーバーしか所有できないリソースで、 サーバー同士はその所有権をめぐりネゴシエートします。 サーバー クラスタは、クォーラム リソースの所有権をネゴシエートすることにより、 サーバーがアクティブなのに、 他のサーバーはダウンしていると見なしてしまう "ネットワークパーティション (スプリット・ブレイン: Split-brain）" 問題を回避できます。 これは、たとえば、クラスタの相互接続が失われ、 ネットワークの応答時間に問題がある場合に発生する可能性があります。 クォーラム リソースは、クラスタ構成の最終的なコピーを保存し、 どのような障害の影響があったとしても、 クラスタ構成が常に一貫性が保たれているようにするために使用されます。

アクティブ/アクティブとアクティブ/パッシブの違いは何ですか?

アクティブ/アクティブとアクティブ/パッシブは、 クラスタ内でどのようにアプリケーションが展開されているかを表すときに使用される用語です。 残念ながら、これらの用語は人によって意味が異なるので、 混乱を招く傾向があります。

1 つのアプリケーションまたはデータベースの場合 :

• アクティブ/アクティブは、 同じアプリケーションまたは同じサービスの一部が、 クラスタ内の異なるノード上で同時に実行できることを言います。 たとえば、SQL Server 2000 は、データベースをパーティション分割して、 各ノードでそのデータベースの 1 つのインスタンスを実行するように構成できます。 SQL Server は、データベース全体を 1 つのイメージにまとめて表示できるビューの概念を採用しています。
• アクティブ/パッシブは、 クラスタ内の 1 つのノードしかその特定のアプリケーションをホストできないことを言います。 たとえば、1 つのファイル共有はアクティブ/パッシブです。 どのようなファイル共有であっても、一度に 1 つのノードでしかホストできません。

複数のアプリケーションまたはデータベースのインスタンスの場合 :

• アクティブ/アクティブは、 同じアプリケーションの異なるインスタンスが、 異なるクラスタ ノード上で同時に実行できることを言います。 たとえば、クラスタ内の各ノードでは、 それぞれ異なるデータベースとして SQL Server を実行できます。 また、1 つのクラスタ内の各ノード上で同時に多数のファイル共有をホストできます。
• アクティブ/パッシブは、 あるサービスのインスタンスは 1 つしかクラスタ内で実行できないことを言います。 たとえば、どんな時であっても、 クラスタ内で実行されている DHCP サービスのインスタンスは、1 つである必要があります。

クラスタの場合 :

• アクティブ/アクティブは、 クラスタのすべてのノードでアプリケーションが実行されていることを言います。 これらは、同じアプリケーションの複数のインスタンスである場合も、 異なるアプリケーションである場合もあります (たとえば、2 ノードのクラスタの場合、WINS が一方のノードで実行されていて、 もう一方のノードでは DHCP が実行されている場合など)。
• アクティブ/パッシブは、 クラスタ ノードの 1 つが予備であり、 アプリケーションのホストに使用されていないことを言います。

サーバー クラスタでは、 上記のあらゆる組み合わせをサポートします。 この 2 つの用語は、特定のアプリケーションやアプリケーションのセットをどのように展開するかを表すために使用されます。

Windows 2000 Datacenter を皮切りに、1 つのクラスタ内で 2 台を超えるサーバーを構成できるようになってから、 アクティブ/アクティブは紛らわしい用語になりました。 なぜなら、サーバーが 4 台存在する可能性もあるためです。 複数のサーバーがある場合、 展開におけるオプションの組み合わせはより柔軟になり、N+1 などの異なる構成を実現できるようになります。

1 つのクラスタに 3 つ以上のノードがあることの利点は?

フェールオーバーは、通常、 インスタンス化されたアプリケーションやパーティション分割されたアプリケーションの各部分を、 高可用性を実現するために展開するメカニズムです (可用性の高い、単一インスタンス アプリケーションやパーティションを表す、パック (Pack) という新しい用語が作られています)。

2 ノードのクラスタでは、 フェールオーバー ポリシーの定義は非常に簡単です。 一方のノードで障害が発生した場合は、残りのノードにフェールオーバーする以外に方法はありません。 クラスタが大きくなるに連れて、さまざまなフェール オーバー ポリシーが可能になり、 クラスタごとにさまざまな特性があります。

フェールオーバーの組

大規模クラスタでは、 各アプリケーションが 2 ノード間でフェイルオーバーされるように、 フェールオーバー ポリシーを定義できます。 以下の簡単な例では、2 つのアプリケーション App1 および App2 が 4 ノードのクラスタ内に展開されていることを示しています。

図 1: フェールオーバーの組

構成の長所と短所

	データベースなどの負荷の高い 1 アプリケーションをサポートするクラスタには有効です。 この構成を使用すると、障害発生時に 2 つのアプリケーションが同じノードでホストされることがないようにできます。
	容量の見積もりが非常に簡単です。 各ノードのサイズは、(2 ノードのクラスタで 1 つのアプリケーションをホストする場合とまったく同じように) ホストする必要があるアプリケーションを基にして決まります。
	システムの可用性やパフォーマンスに対する障害の影響を非常に容易に判断できます。
	より大規模なクラスタの持つ柔軟性が得られます。 保守のためにノードが切り離された場合に、 任意のアプリケーションを "もう一方のノード" に、動的に変更できます (次のスタンバイ ポリシーを適用することになる可能性もあります)。
	上記のような単純な構成では、 使用状態にあるのは、クラスタの全容量の 50 % しかありません。
	障害が複数発生した場合は、管理者による介入が必要になる可能性があります。

1. 負荷の高いアプリケーションは、CPU やメモリ、入出力、帯域幅などのシステム リソースを非常に多く消費するアプリケーションのことです。

フェールオーバーの組は、 任意のノードの組に割り当てる各リソースの "実行可能な所有者の一覧" を制限することによって、 Windows のすべてのバージョンのサーバー クラスタでサポートされます。

ホットスタンバイサーバー

フェイルオーバーの組のオーバーヘッドを削減するため、 各組の "予備" ノードを 1 つのノードと見なし、 障害発生時の作業を処理できるホットスタンバイ サーバーを用意します。

図 2: スタンバイサーバー

構成の長所と短所

	データベースなどの負荷の高いアプリケーションをサポートするクラスタには有効です。 この構成を使用すると、1 つの障害の発生時に 2 つのアプリケーションが同じノードでホストされることがないようにできます。
	容量の見積もりが非常に簡単です。 各ノードのサイズは、ホストする必要があるアプリケーションを基にして決まります。 予備ノードのサイズは、その他のノードの最大容量になります。
	システムの可用性やパフォーマンスに対する障害の影響を非常に容易に判断できます。
	障害が 1 か所で発生する可能性のある構成です。
	必ずしも複数の障害を適切に処理できるわけではありません。 これは、計画された保守の実行中に、予備ノードが使用されている場合、 問題になる可能性があります。

サーバー クラスタでは、 現在、実行可能な所有者の一覧と優先所有者の一覧を組み合わせて使用することで、 スタンドバイ サーバーをサポートしています。 優先所有者ノードにはアプリケーションが既定で実行されるノードを、 任意のリソースの実行可能な所有者には優先所有者ノードと予備ノードを設定するようにします。

N+I

構成によっては 4 ノードのクラスタでスタンバイ サーバーが有効な場合もありますが、 この場合、複数の障害を処理する能力は限られています。N+I 構成はスタンバイ サーバーの概念を拡張したもので、 この場合、アプリケーションをホストする N 個のノードと I 個の予備ノードで構成されます。

図 3: N+I 予備ノード構成

構成の長所と短所

	データベースや Exchange などの負荷の高いアプリケーションをサポートするクラスタには有効です。 この構成を使用すると、1 つの障害の発生時に、 アプリケーション インスタンスが使用されていない予備ノードにフェールオーバーされます。
	容量の見積もりが非常に簡単です。 各ノードのサイズは、ホストする必要があるアプリケーションを基にして決まります。
	システムの可用性やパフォーマンスに対する障害の影響を非常に容易に判断できます。
	複数の障害の処理に有効な構成です。
	必ずしも同一クラスタ内で実行される複数のアプリケーションを適切に処理できるわけではありません。 このポリシーは、専用のクラスタで実行されるアプリケーションに最適なポリシーです。

サーバー クラスタでは、 クラスタ グループ パブリック プロパティ AntiAffinityClassNames を使用して、 Windows Server 2003 リリースでの N+I 事例をサポートしています。 このプロパティは、任意の文字列を保持できます。 フェールオーバー時に、 フェールオーバーされるグループの AntiAffinityClassNames プロパティに何かしら文字列が設定されていた場合、 フェールオーバー マネージャは他のすべてのノードを検査します。 リソースの実行可能な所有者の一覧にあるノードが、AntiAffinityClassNames に同じ値が設定されているグループをホストしていない場合、 これらのノードはフェールオーバー先として十分適している見なされます。 クラスタ内のすべてのノードが、AntiAffinityClassNames プロパティに同じ値が設定されているグループをホストしている場合は、 優先所有者ノードの一覧を使用してフェールオーバー先のノードが決められます。

フェールオーバーリング

フェールオーバー リングを使用すると、 クラスタの各ノードでアプリケーション インスタンスを実行できます。 障害発生時には、障害の発生したノードのアプリケーションが、順番に次のノードに移動されます。

図 4: フェールオーバーリング

構成の長所と短所

	複数の小さなアプリケーション インスタンスをサポートするクラスタで、 どのノードも複数のインスタンスを同時にサポートするだけの容量があるクラスタに有効です。
	パフォーマンスに対するノード障害の影響を容易に予測できます。
	単一障害の対処に必要な容量の見積もりが簡単です。
	複数の障害の処理に常に有効な構成ではありません。 Node 1 で障害が発生した場合、Node 2 が 2 つのアプリケーション インスタンスをホストし、 Node 3 と 4 は 1 つのアプリケーション インスタンスをホストすることになります。 Node 2 で障害が発生した場合は、Node 3 が 3 つのアプリケーション インスタンスをホストし、 Node 4 は 1 つのインスタンスだけをホストすることになります。
	他に負荷の少ないノードがあったとしても、 複数のインスタンスが 1 つのノードでホストされることになる可能性があるので、 負荷の高いアプリケーションには適していません。

フェールオーバー リングは、Windows Server 2003 リリースのサーバー クラスタでサポートされます。 これは、任意のグループのフェールオーバーの順序を優先所有者の一覧を使用して定義することで、実現されます。 ノードの順序を選択し、 優先所有者ノードの一覧を異なるノードで起動されるグループごとに設定する必要があります。

ランダム

大型のクラスタや 4 ノードのクラスタであっても複数のアプリケーションを実行している場合、 各アプリケーション インスタンスに特定のフェールオーバー先やポリシーを定義することは、 非常に困難で問題を発生させやすくなる可能性があります。 場合によっては、障害発生時にクラスタ内で負荷を分散できるような統計的な確率に基づいて、 フェールオーバー先がランダムに選択されるようにすることが最適なポリシーになります。

構成の長所と短所

	複数の小さなアプリケーション インスタンスをサポートするクラスタで、 どのノードも複数のインスタンスを同時にサポートするだけの容量があるクラスタに有効です。
	任意のアプリケーションのフェールオーバー先を管理者が決定する必要がありません。
	十分なアプリケーションが確保されるように、 またはアプリケーションが適切にパーティション分割されるようになります。 障害発生時に、クラスタ内でアプリケーションが統計的に負荷分散される優れたメカニズムが提供されます。
	複数の障害の処理に有効な構成です。
	同じクラスタ内で実行される複数のアプリケーションや同じアプリケーションの多数のインスタンスの処理に非常に適しています。
	容量の見積もりは困難になる可能性があります。 クラスタ内で負荷が一様に分散される確実な保証はありません。
	パフォーマンスに対するノード障害の影響を容易に予測できません。
	他に負荷の少ないノードがあったとしても、 複数のインスタンスが 1 つのノードでホストされることになる可能性があるので、 負荷の高いアプリケーションには適していません。

Windows Server 2003 リリースのサーバー クラスタでは、 障害発生時のフェールオーバー先をランダムに選択できます。 優先所有者の一覧にエントリがない各リソース グループは、 ホストされているノードに障害が発生した場合、 クラスタ内のランダム ノードにフェールオーバーされます。

カスタム制御

特定のアプリケーション インスタンスに特定のノードを指定した方がよい場合もあります。

構成の長所と短所

	障害の発生時に、管理者が事態を完全に制御できます。
	障害事例が予測できるので、 容量の見積もりが簡単です。
	クラスタ内で実行されているアプリケーションが多数ある場合、 優れた障害時のポリシーを定義することが非常に困難になる可能性があります。
	連続的に発生する複数の障害に対する計画を立てるのは非常に困難です。

サーバー クラスタでは、 優先所有者ノードの一覧機能を使用して、 フェールオーバーの順序を完全に制御できます。 優先所有者ノードの一覧の完全な意味合いを、次のように定義できます。

優先所有者ノードの一覧	管理者による "最適な" グループの移動	ノードまたはグループ障害が原因のフェールオーバー
クラスタ内のすべてのノード	グループは、クラスタ内でオンラインで実行されているノードで、 優先所有者ノードの一覧にある最初のノードに移動されます。	グループは、優先所有者ノードの一覧で次に設定されているノードに移動されます。
クラスタのノードのサブセット	グループは、クラスタ内でオンラインで実行されているノードで、 優先所有者ノードの一覧にある最初のノードに移動されます。 優先所有者ノードの一覧にあるノードがオンランで実行されていなかった場合は、 グループはランダム ノードに移動されます。	グループは、優先所有者ノードの一覧で次に設定されているノードに移動されます。 グループをホストしているノードが一覧の最後にある場合や、優先所有者ノードの一覧に指定されていない場合、グループはランダムノードに移動されます。
エントリなし	グループはランダムノードに移動されます。	グループはランダムノードに移動されます。

1 つのクラスタではいくつのリソースをホストできますか?

クラスタ内のリソースの理論上の制限数は、1,674 です。 ただし、クラスタ サービスでは、 リソースがオンラインであることを確認するために、 定期的にポーリングすることに注意してください。 リソースの数が増えるにつれて、このポーリングのオーバーヘッドも増加します。

 ページのトップへ

サーバーの必要条件

何台のサーバーをクラスタ化できますか?

1 つのサーバー クラスタに構成できるサーバーの数は、Windows の製品と Windows のリリースによって異なります。 構成できるサーバーの台数は次表の通りです。

Windows オペレーティング システム	サーバーの最大数
Windows NT Enterprise Edition	2
Windows 2000 Advanced Server	2
Windows 2000 Datacenter Server	4
Windows Server 2003 Enterprise Edition	8
Windows Server 2003 Datacenter Edition	8

サーバークラスタ内のサーバーには、まったく同じものを使用する必要がありますか?

クラスタ ハードウェア互換性テストでは、 認定済みのクラスタ内のすべてのサーバーを同じものにすることを必要条件にはしていません。 クラスタのサイズが大きくなり、 ハードウェアへの投資が増えるに従って、1 つのクラスタ内には異なる種類のサーバーが使用されるようになるでしょう。

認定プロセスおよび一覧作成プロセスは、異種ソリューションがより容易に定義および認定されるように、改良が進められています。これは、"サーバーファミリ" を比較的頻繁に変更し、現在のプロセスで必要となる追加の認定パスが劇的に増加してしまう OEM にとっては特に重要です。認定の際、サーバー自体が問題となることはありません。通常、問題になるのは、HBA やその他のストレージサブシステムであり、ある認定ソリューションでまったく同じサーバーを必須とする理由はありません。

32 ビットサーバーと 64 ビットサーバーを同じサーバークラスタに混在できますか?

いいえ。 同一サーバー クラスタ内のサーバーは、 すべて 32 ビット サーバーにするか、64 ビット サーバーにする必要があります。

サーバークラスタの構築には、使用しているどのサーバーを使用しても構いませんか?

認定済みソリューションは、https://www.microsoft.com/whdc/default.mspx(英語)で公開されている Microsoft ハードウェア互換性リスト (HCL) に記載されています。 マイクロソフトによってサポートされているクラスタ ソリューションは、HCL に記載されているもののみです。 完全なソリューション構築の構成の一部として記載されているサーバーであれば、どのサーバーを使用しても構いません。

 ページのトップへ

相互接続

クラスタの相互接続には、どのようなネットワークが必要ですか?

コンポーネント ネットワーク インターフェイス コントローラ (NIC) も、 認定済みのクラスタ構成で使用されるそ他のコンポーネントと同様に、Windows ロゴが添付されていて、 Microsoft ハードウェア互換性リストに記載されている必要があります。 相互接続自体は、TCP/IP トラフィックや UDP トラフィックをサポートし、 単一のルートなしの LAN セグメントまたはサブネットとして扱われる必要があります。

サーバークラスタでは、WinSock Direct を利用した高帯域幅、低遅延相互接続がサポートされますか?

サーバー クラスタ コード自体は、 クラスタ内の通信に Winsock Direct パスを使用しません。 クラスタ ノード間の通信はすべて、TCP/IP または UDP 上で行われます。 サーバー クラスタは、NDIS ネットワーク アダプタ (NIC) のようなノード間の高帯域幅、低遅延接続を使用することはできますが、 それによる利点はない可能性があります。

1 台のクラスタサーバーには、何基のネットワークアダプタが必要ですか?

クラスタ ノードは、1 か所での障害の発生を防ぐために、 2 つ以上の独立したネットワークに接続されている必要があります。 2 つのローカル エリア ネットワーク (LAN) が使用されている必要があります。 ネットワークが 1 つしかないクラスタ構成は、 サポートされません。 少なくとも 2 つのネットワークが、クラスタ通信のために構成されている必要があります。 通常、ネットワークの 1 つは、クラスタ通信のためだけに構成された "プライベート ネットワーク" になり、 もう一方は、クライアント アクセスとクラスタ通信の両方に使用されるように構成された "パブリック ネットワーク" になります。

1 つのクラスタで、パブリックとして構成されたアダプタを複数サポートできますか?

はい。ただし、次の 2、3 の点について、注意が必要です。

• 各ネットワーク アダプタは、それぞれ異なるサブネット上に配置されている必要があります。
• 異なる IP アドレス リソースを作成し、 異なるアダプタに関連付けることができますが、 リソースまたはアプリケーションを 2 つのネットワークに依存させ、 アプリケーションが常に利用可能な状態であるようにする方法はありません。 サーバー クラスタでは、 依存するアプリケーションがオンラインであるためには、 依存関係が完全にオンラインである必要があります。

今後のクラスタ テクノロジでは、 リソースをオンラインにするためにどちらにも依存できるような、 より柔軟な依存関係を実現する機能を提供できるように、現在開発が進められています。

1 つのクラスタで、複数のプライベートネットワークをサポートできますか?

はい。

クライアントのみとマークされたハートビートパケットがネットワーク上を流れているのはなぜですか?

Windows 2000 以降では、 サーバー クラスタ ソフトウェアによって、 パブリック ネットワークの構成にかかわらず、 プライベート ネットワークだけでなくパブリック ネットワークにもハートビートが送られます。 これは、クラスタ サービスがパブリック ネットワーク アダプタの障害を検出し、 これを現在ホストしているノードが外部と通信できない場合は、 アプリケーションをフェールオーバーできるようにするためです。

異なるネットワークはどのように構成すべきですか?

クラスタ ノードは、1 か所で障害が発生するのを防ぐために、 2 つ以上の独立したネットワークに接続されている必要があります。 通常は、2 つのローカル エリア ネットワーク (LAN) を使用します。 ノードが 1 つのネットワークにしか接続していないクラスタ構成は、サポートされません。

プライベート ネットワークは "クラスタ内通信のみ" 用に、 パブリック ネットワークは "すべての通信" 用に構成してください。

クラスタネットワークではどのような情報が送信されますか?

クラスタ サービスは、次のクラスタ内トラフィックにクラスタ ネットワークを使用します。

• サーバー クラスタのクエリ情報、管理情報、および制御情報。
• 障害検出のためのハートビート。
• クラスタ構成の一貫性を厳密に保つためのクラスタ内通信。
• ノードの再起動または障害からの回復時に送られるクラスタ参加要求。

サーバークラスタ内のアプリケーションにはどのようなプロトコルがサポートされていますか?

クラスタ対応アプリケーションは、TCP/IP ベースのプロトコルを使用する必要があります。 クラスタ ソフトウェアは、提供されている状態のままではフェールオーバーに TCP/IP プロトコルのみをサポートします。

あるサーバーのパブリックネットワークで障害が発生した場合、フェールオーバーは行われますか?

はい。Windows 2000 以降では、 新たにハートビートがパブリック ネットワーク経由でも送られるようになり、 パブリック ネットワークの障害や NIC の障害を検出し、 アプリケーションがホストされているノードが他のノードと通信できない場合は、 アプリケーションのフェールオーバーを行います。

サーバークラスタでは NIC チーム構成はサポートされますか?

はい。ただし、注意が必要な点があります。NIC チーム構成のすべてのクラスタ ネットワークでの同時使用は、 サポートされていません。 少なくとも、クラスタ ノード間の内部通信が有効になっているクラスタ ネットワークの 1 つは、 チーム構成にしないでおく必要があります。 通常、チーム構成されないネットワークは、 そのような通信専用のプライベート相互接続です。NIC チーム構成を他のクラスタネットワークで使用することもできますが、 チーム構成にされたネットワークで通信エラーが発生した場合、 マイクロソフト サポート サービスによってチーム構成を無効にするよう求められることがあります。 これによりエラーや問題が解決された場合は、 使用していたチーム構成ソリューションの製造元から、さらにサポートを受ける必要があります。

サーバークラスタの仮想サーバーで DHCP はサポートされますか?

いいえ。仮想サーバーには、静的 IP アドレスが必要です。

サーバークラスタのノードでは DHCP はサポートされますか?

はい。アドレスは、DHCP によって動的に物理ノードに割り当てることもできます。 ただし、静的アドレスを手動で構成することをお勧めします。

サーバークラスタの実行には、NetBIOS が必要ですか?

Windows NT および Windows 2000 では、 サーバー クラスタが正常に機能するためには、NetBIOS が必要です。

Windows Server 2003 では、クラスタ サービスには NetBIOS は必要ありません。 ただし、NetBIOS が無効な場合、影響を受けるサービスがあります。次の点に注意してください。

• 既定では、クラスタが構成されると、NetBIOS がクラスタの IP アドレスで有効になります。 クラスタが作成されたら、クラスタ IP アドレス リソースのパラメータを設定するプロパティ ページで、 チェック ボックスをオフにし、NetBIOS を無効にしてください。
• 新たに IP アドレス リソースを作成した場合は、 そのアドレスの NetBIOS のチェック ボックスをオフにしてください。
• NetBIOS が無効な場合、 クラスタ アドミニストレータの [参照] 機能が使用できなくなります。 クラスタ アドミニストレータでは、 任意のドメイン内のすべてのクラスの列挙に、NetBIOS を使用しています。
• プリント サービスおよびファイル サービスが無効になります。 これは、リダイレクタのエンドポイントとして仮想名が追加されないためです。
• クラスタ名が指定されている場合、 クラスタ アドミニストレータは機能しません。 クラスタ アドミニストレータは、 リモート レジストリ API を使用する GetNodeClusterState を呼び出します。 この API は次に仮想名に基づいて名前付きパイプを使用します。

サーバークラスタでは IPSec はサポートされますか?

サーバー クラスタ内でフェールオーバーされるアプリケーションにインターネット プロトコル セキュリティ (IPSec) を使用することはできますが、 IPSec はフェールオーバー時に使用されるようデザインされていないので、 サーバー クラスタ内のアプリケーションに IPSec は使用しないことをお勧めします。

IP フェールオーバーの処理中、サーバークラスタはどのようにルーティングテーブルを更新しますか?

自動回復手順の一環として、 クラスタ サービスは IETF 標準の ARP "flush" コマンドをルーターに発行して、 別のサーバーに移動される IP アドレスに関連付けられているコンピュータ アドレス (MAC) を更新します。

アドレス解決プロトコル (ARP) は、どのようにして、LAN 上のシステムが IP アドレスを物理的なコンピュータ (MAC) アドレスに変換するテーブルを更新するようにするのですか?

ARP 仕様では、ARP 要求を受信したすべてのシステムが、 要求の送信元の物理アドレス マッピングを更新するように定めています。 要求送信元の IP アドレスと物理ネットワーク アドレスは、 要求内に格納されています。IP アドレスの登録処理の一環として、Windows TCP/IP ドライバは、 該当する LAN に ARP 要求を数回にわたりブロードキャストします。 この要求では、指定した IP アドレスの所有者に、 その所有者の物理ネットワーク アドレスを格納した応答を返すように要求します。 登録される IP アドレスの要求を発行することによって、Windows は IP アドレスの競合を検出できます。 つまり、もし、応答を受け取れなければ、 このアドレスは安全に使用できません。 ただし、Windows がこの要求を発行する場合、Windows は登録される IP アドレスを要求の送信元として指定します。 したがって、ネットワーク上のすべてのシステムが、 この指定されたアドレスの ARP キャッシュ エントリを更新し、 アドレスを登録するシステムが、 このアドレスの新しい所有者になります。

アドレスの競合が発生した場合は、 応答するシステムが同じアドレスに対するまた別の ARP 要求を送信し、 サブネット上の他のシステムに ARP キャッシュを再び更新させる可能性があることに注意してください。 Windows は、既に正常に登録されているアドレスとの競合を検出した場合、 これを実行します。

サーバークラスタは、MAC アドレスの再設定に ARP ブロードキャストを使用しますが、ARP はルーターを通過しません。その場合、ルーターの背後にあるクライアントについてはどうしますか?

クライアントがルーターの背後にある場合、 クライアントはルーターを使用してクラスタ サーバーがあるサブネットにアクセスすることが考えられます。 したがって、これらのクライアントは、 ルーティング プロトコルの種類 (OSPF、RIP など) が何であれ、 そのプロトコル経由で、 各自のルーター (ゲートウェイ) を使用してパケットをルーターに渡します。 最終的に、クライアントのパケットはクラスタと同じサブネット上のルーターに転送されます。 このルーターの ARP キャッシュは、 フェールオーバー中に変更された MAC アドレスと一致しています。 したがって、リモート クライアントが元の ARP ブロードキャストを受信することがなくても、 パケットは正しい仮想サーバーに到着します。

 ページのトップへ

記憶域

記憶域に関する質問は数多く寄せられます。 これらの質問は、一般的な質問、SAN (Storage Area Network) へのサーバー クラスタの展開に関する質問、 NAS (Network Attached Storage) に関する質問に分類されます。

記憶域に関する一般的な質問

サーバークラスタでサポートされるストレージ相互接続は何ですか?

クラスタ サーバーでは、サポートするストレージ相互接続の種類に制限はありません。 ただし、ストレージ サブシステムの必要条件によっては、 実用的な観点から、種類が制限されます。 たとえば、すべてのクラスタ ノードが記憶装置にアクセスできる必要があります。 通常、このことは、 複数のイニシエータ (すなわち、ノード) を利用できる相互接続しか使用することができなくなるため、 相互接続に影響します。 現在認定済みの構成の一部として HCL に記載されている相互接続には、SCSI (各種)、FC-AL (Fibre Channel-Arbitrated Loop)、 ファイバ チャネル スイッチ ファブリックがあります。

マイクロソフトによってサポートされるのは、 クラスタ HCL に記載されている完全な構成で構成されているクラスタのみであることに注意してください。

SCSI クラスタ上のノードおよび記憶域はどのように構成すればよいですか?

SCSI バス上のすべてのデバイスに異なる SCSI ID が割り当てられていることを確認します。 既定では、通常、SCSI アダプタには ID 7 が割り当てられます。 各ノードのアダプタには異なる ID が割り当てられていることを確認してください。 同様に、バス上のディスクにも一意の SCSI ID が割り当てられるようにします。

SCSI バスが正常に動作するためには、 これをターミネートする必要があります。 バスをターミネートさせる方法は、 内部的な方法 (ホスト アダプタから) と外部的な方法 (Y ケーブルを使用) を合わせて、 多数あります。 クラスタが異なる種類の障害に対処できるように (特に、ノードのうちの 1 台の電源を落とすことができるように)、SCSI バスは Y ケーブルのような受動部品を使用してターミネートしてください。 アダプタの電源を入れる必要がある内部的なターミネータはお勧めしません。

注意 : マイクロソフトでは、2 ノード クラスタでのみ、SCSI ストレージ相互接続を使用したクラスタ構築をサポートしています。

サーバークラスタでは、FC-AL (Fibre Channel-Arbitrated Loop) はサポートされますか?

はい。マイクロソフトでは、2 ノード クラスタでのみ、FC-AL ストレージ相互接続を使用したクラスタ構築をサポートしています。 単一のファイバ チャネル ループ上での複数クラスタは、サポートされていません。

複数のクラスタを同じストレージコントローラに接続できますか?

はい。同じストレージ コントローラに複数のクラスタが接続されている場合に、 コントローラが適切に応答を返すことを保証する、 特別なストレージ コントローラ用のデバイス認定テストがあります。 同一のコントローラに接続された複数のクラスタの場合、 このストレージ コントローラが必ずマルチクラスタ デバイス ハードウェア互換性リスト (HCL) に存在し、 各エンドツーエンド クラスタ ソリューションがそれぞれクラスタ ハードウェア互換性リストに存在する必要があります。 たとえば、EMC Symmetrix 5.0 は、 マルチクラスタ デバイス HCL リストに記載されています。 また、複数クラスタ (Dell PowerEdge クラスタや Compaq Proliant クラスタなど) は、 Dell PowerEdge + EMC Symmetrix と Compaq Proliant + EMC Symmetrix の両方の構成がクラスタ HCL に記載されているので、EMC Symmetrix ストレージ コントローラに接続できます。

ストレージケーブルがホストバスアダプタ (HBA) から外された場合、フェールオーバーが行われますか?

ストレージ ケーブルがホスト バス アダプタ (HBA) から外された場合、 接続が失われたことに対してアダプタが反応するまで少し時間がかかる可能性がありますが、HBA が通信障害を検出すると、 その HBA を使用しているクラスタ内のディスク リソースは失敗します。 これにより、フェールオーバーが実行され、 リソースはクラスタ内の別のノード上でオンラインに戻されます。

ストレージ ケーブルが再び接続された場合、Windows オペレーティング システムによって、 自動的に新しいハードウェアの検出が再度行われない可能性があります (これは、アダプタに使用されているドライバによって異なります)。 新しいデバイスの再検出を手動で開始する必要があるかもしれません。 再検出が完了すると、 ノードで物理ディスク リソースをホストできるようになります。 フェールバック ポリシーが設定されている場合は、 ケーブルが取り外された際にフェールオーバーされたリソースは、 ケーブルが元に戻されると、元のノードにフェールバックされます。

注意 : HBA は、サーバーに配置されるストレージ インターフェイスです。 通常、これはサーバーとストレージ ファブリックを接続する PCI カードになります。

サーバークラスタによって、ハードウェア障害からディスクは保護されますか?

いいえ。クラスタ サーバーによる保護は、 サーバー障害、オペレーティング システムまたはアプリケーション エラー、 保守のための計画されたダウンタイムに対するものです。 アプリケーションおよびユーザー データは、 ミラーリングや RAID、レプリケーションなどハードウェアまたはソフトウェアによる冗長技術を使用して、 ディスク障害から保護することを強くお勧めします。

サーバークラスタは、RAID またはミラーディスクをサポートしますか?

はい。アプリケーションおよびユーザー データは、ミラーリングや RAID、 レプリケーションなどハードウェアまたはソフトウェアによる冗長技術を使用して、 ディスク障害から保護することを強くお勧めします。

クラスタでは、ダイナミックディスクはサポートされますか?

マイクロソフトから提供されている Windows サーバー製品では、 サーバー クラスタ環境でのダイナミック ディスクはサポートされていません。 サーバー クラスタにダイナミック ディスク機能を追加するには、 ベリタスソフトウェアのアドオン製品 VERITAS Volume Manager for Windows 2000 を使用できます。 Veritas Volume Manager がクラスタにインストールされている場合は、 クラスタの問題についてのサポートを受ける場合、 最初の問合せ先はベリタスソフトウェアになります。

クラスタディスクは、コンピュータの再起動なしに拡張できますか?

はい。クラスタ ディスクは、ストレージ コントローラが元になる物理ディスクの動的拡張をサポートしている場合は、 コンピュータの再起動なしに拡張できます。 新型のストレージ コントローラの多くは、"論理ユニット" (LUN) を仮想化してオペレーティング システムに提供しています。 これらのコントローラを使用している場合、 ストレージ コントローラの管理コンソールから LUN をオンラインで拡張できます。 マイクロソフトでは、"DiskPart" というツールを提供しています。 このツールを使用すると、 ディスク上に新しく作成された領域を利用して、 ボリュームまたはパーティションをオンラインのまま、 アプリケーションやユーザーによるこのディスクの使用を妨げることなく、 拡張できます。DiskPart には、Windows 2000 バージョンと Windows Server 2003 バージョンの異なるバージョンがあります。 Windows 2000 バージョンは、Web から無償でダウンロードできます。 Windows Server 2003 バージョンは、Windows Server 2003 の配布メディアに含まれています。

注意 : LUN とディスク アドミニストレータで表示されるディスク デバイスは同じものです。

追加のディスクは、コンピュータを再起動しないでクラスタに追加できますか?

はい。 新しいディスクを取り付けたり、 新しい LUN を作成して、 これをクラスタ ノードから認識できるようにすることができます。 まず、ディスクをクラスタ内の 1 つのノードからだけ認識できるようにして、 このディスクを保護するクラスタ リソースを作成してください。 ディスクが保護されたら、 この LUN をクラスタ内の他のノードからも認識できるようにします。 場合によっては、デバイス マネージャを使用してこの新しいディスクの検出を再度行う必要がある可能性があります。 それ以外の場合 (特にファイバ チャネルを使用している場合) は、 ディスクは自動的に検出される可能性があります。

コンピュータの再起動なしに、クラスタからディスクを取り外すことはできますか?

はい。

クラスタディスクには、どのようなディスクを使用できますか?

クラスタ ディスクのパーティションはすべて NTFS ファイル システムを使用してフォーマットすることをお勧めします。 これには、2 つの理由があります。1 つは、NTFS により、 ディスク上のデータのセキュリティによる保護に使用できるアクセス制御が提供されます。 2 つ目は、NTFS は、強制的にマウント解除されたボリュームから回復できます。 他のファイル システムは、 強制的にマウント解除された場合、 破損する可能性があります。

サーバー クラスタでは、 マスタ ブート レコード (MBR) フォーマットのディスクのみがサポートされます。 クラスタ ディスクには、GPT フォーマットのディスクは使用できません。

テープデバイスまたはその他のディスク以外のデバイスを、クラスタディスクと同じストレージバスに接続できますか?

これは、ストレージ相互接続によって異なります。 サーバー クラスタは、クラスタ ディスクの調整に SCSI の RESERVE ＆ RESET を使用します。 Windows NT および Windows 2000 では、クラスタ サーバーは不特定のバスのリセット実行します。 Windows Server 2003 では、 リセットを特定できますが、 不特定のリセットが代わりに使用される場合もあります。 テープ デバイスに対してリセットが行われると、通常、テープの巻き戻しが開始されます。

サーバー クラスタには、 複数のサーバーから認識されるテープ デバイスのための調整メカニズムはありません。 したがって、テープ デバイスは、複数のサーバーによる同時アクセスから保護されません。

マイクロソフトは、SCSI クラスタまたは FC-AL (Fibre Channel-Arbitrated Loop) のループの場合、 クラスタ ディスクのある SCSI バスへのテープ デバイスの接続はサポートしていません。

テープ デバイスは、 クラスタ ディスクと同じアダプタ経由で認識されない限り、 スイッチ型ファブリックに接続できます。 これは、テープ デバイスをクラスタ ディスクとは異なるゾーンに配置するか、LUN のマスキング技術を利用して行います。

サーバークラスタでは、ソフトウェアによるフォールトトレラントディスク (ソフトウェアによる RAID またはミラーリング) はサポートされますか?

マイクロソフトの Windows サーバー製品では、 ソフトウェアによる RAID またはミラーリング サポートは提供されていませんが、 クラスタ環境においてこの機能を提供するサードパーティ製品があります。

サーバークラスタでは、VSS (Virtual Snapshot Service) はサポートされますか?

はい。VSS (Virtual Snapshot Service) は、Windows Server 2003 の新機能で、 一貫性が保たれた、日時指定によるバックアップを作成する際に、 バックアップ アプリケーションによって使用される基本的なスナップショット機能を提供します。 クラスタ サービスには、VSS プロバイダが用意されていて、 そのようなバックアップ アプリケーションによって、 クラスタ サービス構成のスナップショットを作成し、 システム状態の一部として保存できるようになっています。

サーバークラスタでは Timewarp スナップショットは利用できますか?

いいえ。Timewarp は Windows Server 2003 の新機能で、 一貫性が保たれたスナップショットを作成し、 これをクライアントに公開できる機能です。Timewarp はクラスタ対応ではない機能を利用するため、 現時点では、 クラスタでは Timewarp はサポートされていません。

サーバークラスタでは、ハードウェアスナップショットまたは "ビジネスリカバリボリューム" はサポートされますか?

はい。最新のストレージ コントローラで提供されている機能を使用して、 既存のボリュームのスナップショットを作成できます。 ただし、ディスクのスナップショットを作成する場合、 スナップショット元のディスクと同じクラスタにスナップショット作成しないように注意してください。 クラスタ サービスは、 ディスク署名を使用して個別のディスクを識別します。 スナップショットが存在すると、 ディスクとスナップショットに、同じディスク署名が使用されます。

クラスタ ディスクのハードウェア スナップショットまたはビジネス リカバリ ボリュームを作成する場合は、 他のサーバーまたはクラスタ (通常は専用のバックアップ サーバー) にスナップショットを作成してください。

クラスタディスクの作成時に他に考慮すべきことは何ですか?

最近のストレージ コントローラでは、 ストレージ自体の仮想ビューを作成できます。 物理 RAID セットを、 複数の論理ユニットとして扱い、 個別のディスクや LUN としてオペレーティング システムに公開できます。 物理ディスクをこのような方法で扱い、 個別の LUN としてホストに公開する場合は、 入出力や障害の特性を十分に考慮してください。 ビューからそれぞれのスピンドルまでには限られた帯域幅しかないことに注意してください。

アプリケーションに使用するディスクと同じ元になる物理ディスクから、 クォーラム ディスクとして使用するための LUN を作成しないことをお勧めします。 クラスタの可用性は、 クォーラム ディスクの可用性と直結しています。 クォーラム ディスクへの入出力に時間がかかった場合、 クラスタ サーバーは、このクォーラム ディスクで障害が発生したものとして、 クォーラム デバイスのフェールオーバーを開始します。 この時、他のすべてのクラスタ関連の操作は、 クォーラム デバイスがオンラインに戻るまで、中断されます。

クラスタ内で障害が発生したディスクを交換する方法は?

この回答は、Windows のリリースによって異なります。

• Windows NT Enterprise Edition
  • レジストリを多少変更すると同時に、FTEdit ツールを使用します。 これについては、サポート技術情報の文書、 「243195」に記載されています。
• Windows 2000
  • DumpCfg。
  • ClusterRecovery リソース キット ツール。Windows Server 2003 リソース キットで提供されています。
• Windows Server 2003
  • 自動システム回復。
  • ConfDisk。これについては、 サポート技術情報の文書、 「280425」に記載されています。
  • ClusterRecovery リソース キット ツール。Windows Server 2003 リソース キットで提供されています。

SAN (Storage Area Networks) に関する質問

SAN (Storage Area Networks) とは何ですか?

SAN (Storage Area Networks) は、 相互接続された "デバイス" (ディスクやテープなど) と、 ファイバ チャネルなどの共通の通信およびデータ転送インフラストラクチャに接続された "サーバー" のセットであると定義されます。 任意の展開に利用される共通の通信およびデータ転送メカニズムは、 一般に、"ストレージ ファブリック" と呼ばれています。 SAN の目的は、 あらゆるサーバーがあらゆる記憶域ユニットにアクセスすることができる記憶域プールに、 複数のサーバーがアクセスできるようにすることです。 この環境では明らかに、 セキュリティを保証し (どのデバイスに誰がアクセスできるか)、 順序付けまたはシリアル化を保証する (誰がどのデバイスにどの時点でアクセスできるか) 上で、 管理が大きな役割を果たします。

SAN を使用する理由は何ですか?

SAN を使用すると、 ローカルに接続されたデバイスに対してさまざまな利点があります。 SAN では、処理ユニットを記憶域ユニットから切り離すことができます。 その結果、ある特定のサーバーのために適切なデバイスの購入を検討したり、 任意のサーバーに記憶域を取り付けるためにデータセンターの配線をし直したりすることなく、 現在のビジネス ニーズに合うようにサーバーと記憶域の両方を柔軟に展開したり、 動的に再設計できます。

クラスタを SAN に接続できますか?

はい。 マイクロソフトでは、基礎となる Windows プラットフォームの一環としても、 完全な Windows クラスタリング高可用性ソリューションの一環としても、SAN をサポートしています。

クラスタと他のサーバーを同じ SAN 上に共存させることはできますか?

スタンドアロンの Windows サーバーや他の Windows 以外のプラットフォームと、 1 つまたは複数のサーバー クラスタを単一の SAN 環境に展開できます。

クラスタを共有 SAN に展開する場合、他にどんな SAN 構成が必要になりますか?

• SAN 上の各クラスタのクラスタ ディスクは、 それぞれ別のゾーンに展開される必要があります。 1 つのクラスタ内のホスト バス アダプタ (HBA) はすべて、同じ種類で、 ファームウェア リビジョンのレベルも同じである必要があります。 ストレージ ベンダやスイッチ ベンダの多くは、 同じゾーン、または場合により同じファブリックにあるすべての HBA が、 同じ種類で、同じファームウェア リビジョン番号のものであることを必要条件としています。
• 同一クラスタ内のストレージ デバイス ドライバおよび HBA デバイス ドライバは、 すべて、同じソフトウェア バージョンのものである必要があります。
• 新しいサーバーを SAN に追加する場合は、 そのトポロジに HBA が適していることを確認してください。 構成によっては、アービトレート型ループ HBA をスイッチ型ファイバ ファブリックに追加した場合、 ストレージ ファブリックで広範囲にわたる障害が引き起こされる可能性があります。 実際に、これまで、このために重大なダウンタイムが発生した例があります。

注意 : HBA は、サーバーに配置されるストレージ インターフェイスです。 通常、これはサーバーとストレージ ファブリックを接続する PCI カードになります。

LUN マスキングまたは選択的提示とは何ですか?

LUN マスキング (選択的提示としても実装) を使用すると、 ユーザーがコントローラ レベルで、LUN とホスト間の特定の関係を表現できるようになります。 この LUN にアクセスするように構成されたホストのみが、 これを表示できます。

ハードウェアによるゾーニングとソフトウェアによるゾーニングの違いは何ですか?

ゾーニングは、 コントローラ上のハードウェアやファームウェア、 またはホストのソフトウェアに実装できます。 マイクロソフトでは、 コントローラ ベースの (ハードウェアによる) ゾーニングを使用することをお勧めします。 これにより、ノードの障害やソフトウェア コンポーネントの障害により中断されたり、 影響されることなく、 一貫性を保ってアクセス ポリシーを実装できます。

SAN ではサーバーの分離にゾーニングが必要になる理由は?

クラスタは、 同じゾーンに存在する他のクラスタに悪影響を与える可能性のあるディスクへのアクセスを保護するメカニズムを使用しています。 ゾーニングを使用してクラスタのトラフィックを他のクラスタやクラスタ以外のトラフィックから分離することで、 影響を受ける可能性はまったくなくなります。

この図では、2 つのクラスタが 1 台のストレージ コントローラを共有しています。 各クラスタは、 それぞれ独自のゾーン内に存在します。 ストレージ コントローラによって提供される LUN は、 ストレージ コントローラ自体によって提供される適切な粒度のセキュリティを使用して、 各クラスタに割り当てられる必要があります。LUN を設定して、 特定のクラスタに割り当てられた各 LUN が、 そのクラスタのすべてのノードから認識およびアクセスできるようにする必要があります。 LUN は、一度に 1 つのクラスタからしか認識できないようにします。 クラスタ ソフトウェア自体によって、LUN がすべてのクラスタ ノードから認識されても、 一度にディスクにアクセスおよびマウントするのはクラスタ内の 1 台のノードだけになるように処理されます。

マルチクラスタ HCL リストに記載する記憶域構成の認定に使用されるマルチクラスタ デバイス テストでは、 このような方法で複数のクラスタが 1 台のストレージデバイスに接続された場合、 確実に分離処理が行われるかどうかが検証されます。

クラスタサーバーは SAN から起動できますか?

はい。 ただし、SAN から Windows を起動する方法については、 いくつかの構成上の制限事項があります。 サポート技術情報の文書、 「305547」を参照してください。

サーバー クラスタでは、 ブート ディスク、ページ ファイル ディスク、 およびシステム ディスクをクラスタ サーバー ディスクとは別のストレージ バスに配置する必要があります。 SAN から起動する場合、 クラスタ ディスクとは別の HBA をブート ディスク、システム ディスク、 およびページ ファイル ディスク用に用意する必要があります。 クラスタ ディスクを独自のゾーンに配置して、 クラスタ ディスクが、ブート ディスク、システム ディスク、 およびページ ファイル ディスクから必ず分離されるようにしてください。

高可用性を確保するため、SAN ストレージに複数のパスを使用できますか?

マイクロソフトからは、 高可用性を目的とするストレージ インフラストラクチャへの複数パスを可能にする汎用ドライバは提供されていません。 ただし、いくつかのベンダによって、 高可用性のストレージ インフラストラクチャとして複数の HBA および SAN ファブリックの使用を可能にする独自のドライバが作成されています。 マルチパス ドライバを持つサーバー クラスタがサポートされると見なされるためには、 そのクラスタ内のマルチパス ドライバが、 クラスタ ハードウェア互換性リスト (HCL) の完全なくラスタ ソリューションの一部として記載されている必要があります。 注意 : ドライバのバージョンは非常に重要です。 これは、HCL にある認定済みのバージョンと必ず一致している必要があります。

ブートディスク、ページファイルディスク、およびクラスタディスクを同じ SAN ファブリック上に配置できますか?

いいえ。 ただし、Windows Server 2003 では、ブート ディスク、ページ ファイル ディスク、 およびクラスタ ディスクを同じバス上に配置できるようにするレジストリ スイッチが用意されています。 この機能は、次のレジストリ キーを設定すると有効にできます。

HKLM\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters\ManageDisksOnSystemBuses   0x01  

この機能は、 この構成の意味を理解していないユーザーによって誤って有効にされることのないよう、 レジストリ キーにより有効にするようになっています。 これは、認定済みおよびテスト済みの構成を提供する OEM 向けに用意された機能であり、 一般のエンドユーザーや管理者により適宜設定される機能ではありません。

クラスタディスクに対して、サーバーレスバックアップを実行できますか?

いいえ。クラスタ ディスクの調整メカニズムは、SCSI の RESERVE ＆ RESET 操作を使用しています。 あるサーバーがクラスタ ディスクの調整を行うと、 このディスクには記憶域ネットワーク上のその他のサーバーからはアクセスできなくなります。

NAS (Network Attached Storage) に関する質問

NAS (Network Attached Storage) とは何ですか?

NAS (Network Attached Storage) は、 イーサネットやその他の LAN テクノロジなど、 標準のネットワーク コンポーネントを使用して構築される、記憶域をサーバーに接続するための別の方法です。 アプリケーション サーバーは、 ファイルを開く、ファイルを読み取る、ファイルに書き込む、 ファイルを閉じるといった、ファイル システムの機能を使用して記憶域にアクセスします。 これらの高度な機能は、CIFS や NFS、AppleShare などのプロトコルにカプセル化されていて、 標準の IP ベース接続上で実行できます。

サーバークラスタでは、NAS を共有記憶域として使用できますか?

はい。 サーバー クラスタ アプリケーションを提供することで、 データをファイル共有に保存することができ、 またファイル共有は、クラスタ内でフェールオーバーされることから分かるように、 サーバー クラスタ アプリケーションからアクセスできます。 NAS をクラスタ内のストレージ ソリューションとして使用できない理由はありません。

現在、Windows では NAS をクォーラム リソースとしては使用できません。

Windows Server 2003 では、 新しいクォーラム リソース "マジョリティ ノード セット" を提供しています。 これを使用すると、共有ディスクをクォーラム リソースとして使用する必要性をなくすことができます。 NAS ストレージとマジョリティ ノード セット クォーラムを組み合わせて使用すると、 SCSI や SAN の従来の意味での共有ディスクを必要としない、 フェールオーバー クラスタを構築できます。

 ページのトップへ

可用性の高いファイル サーバー

アクティブ/アクティブ型ファイルサーバーを構成できますか?

はい。サーバー クラスタは、 多数のファイル共有をホストでき、 各ファイル共有は、専用の仮想サーバーでホストでき、 仮想サーバーは、クラスタ全体に分散できます。 したがって、クラスタ内の各ノードは、複数の共有に対するファイル サーバー要求をサービスできます。

ある 1 台のサーバーからクラスタへ共有の構成を移行するにはどうしたらよいでしょうか?

Windows 2000 リソース キットには、"ClusTool" という、 ある 1 台のノードからクラスタ環境への、 ファイル共有設定の移行に使用できるツールが用意されています。

クラスタ化されたファイル共有のレプリケーションに FRS を使用できますか?

いいえ。Windows が提供しているファイル レプリケーション サービス (FRS) は、 クラスタ化されたファイル共有のレプリケーションには使用できません。 つまり、クラスタ化されたファイル共有は、DFS ツリーで冗長リンクのリンク元やリンク先に指定できません。 詳細については、オンライン ドキュメントで DFS に関する情報を参照してください。

クラスタでサポートされるファイルシステムの種類は何ですか?

クラスタ ディスク上のパーティションはすべて、NTFS でフォーマットされる必要があります。

サーバークラスタでは、クライアント側のキャッシュ (オフラインフォルダ) は利用できますか?

はい。Windows Server 2003 では、 クラスタ化されたファイル共有のクライアント側のキャッシュ (または、オフライン フォルダとも呼ばれます) を設定できます。

クラスタディスクでは、暗号化ファイルシステム (EFS) はサポートされますか?

Windows Server 2003では、クラスタ化されたファイル共有での暗号化ファイルシステム (EFS) はサポートされます。クラスタ化されたファイル共有で EFS を有効にするには、環境を正しく構成するために、いくつかの操作を実行する必要があります。

• EFS は、仮想サーバーで Kerberos 認証が有効の場合にのみ、 ファイル共有で有効にできます。 既定では、Kerberos 認証は仮想サーバーでは有効にされません。 Kerberos 認証を有効にするには、 クラスタ化されたファイル共有への接続に使用するネットワーク名リソースの [Kerberos 認証を有効にする] チェック ボックスをオンにしてください。 注意 : ネットワーク名リソースの Kerberos 認証を有効にする場合、 このチェック ボックスをオンにする前に、十分に理解しておく必要がある影響がいくつかあります。
• すべてのクラスタ ノード コンピュータ アカウントは、 仮想サーバー コンピュータ アカウントと同様に、 委任に対して信頼されている必要があります。 この方法については、オンライン ヘルプを参照してください。
• ユーザーの秘密キーがクラスタ内のすべてのノードで利用できるようにするには、 EFS を使用してデータを保存するユーザーに対して移動プロファイルを有効にする必要があります。 移動プロファイルを有効にする方法については、オンライン ヘルプを参照してください。

クラスタ ファイル共有が作成され、 上記の構成作業が実行されると、 ユーザーのデータを暗号化ファイルに保存して、 さらにセキュリティを強化できます。

1 つのクラスタではいくつのファイル共有をホストできますか?

クラスタ内のファイル共有の数は、 クラスタ内のノードの数と、 どのような障害に対する保護を設定するかによって異なります。 1 台のサーバーでサポートできるファイル共有の数には制限があるので、 クラスタを計画する際には、このことを考慮する必要があります。

2 ノードのクラスタでは、1 台のノードで障害が発生した場合、 残りの 1 台のノードがすべてのファイル共有をホストする必要があります。 したがって、可用性を最大限確保するためには、1 台のノードによってホストできる限りの共有をクラスタによってサポートします。

注意 : 2 ノードのサーバー クラスタは、スケールアウトではなく、高可用性を確保することを目的とするものです。 したがって、2 ノード クラスタでは、1 台のノードで保持できる数よりも多くの共有を保持するような計画は立てないようにしてください。

4 ノードのクラスタでは、どのような障害に対する保護を設定するかによって、 より適していると思われる他の方法を採用できます。 たとえば、どの時点でもノード 1 台の障害に対処する場合、 共有を構成してノードの 1 台で障害が発生した場合に、 そのノードの作業が残りの 3 台のノードに分散されるようにできます。 これは、各ノードがホスト可能な数の 66 % まで共有を負担でき、 また 1 つの障害が発生した場合も 1 台のノードでホストできる制限内であることを意味します。 この場合、 クラスタは 1 台のサーバーが負担できる数の 3 倍の共有を負担できます。 ノード 2 台の障害に対処する場合は、4 ノードのクラスタで負担できる共有は 2 倍になります (2 台のノードで障害が発生すると、残りの 2 台のノードがこの障害の発生したサーバーの作業を処理する必要があるため)。 このように、障害台数に反比例して負担できる共有数も変化します。

一般に、クラスタ内のノード数が増えると、 対処法方も増え、可用性の高いインフラストラクチャのスケールアウトにサーバー クラスタをさらに利用できます。

クラスタディスクの最大容量は?

サーバー クラスタでは、サポートするボリュームのサイズに制限はありません。

サーバークラスタでは、何台のディスクをサポートできますか?

Windows 2000 では、 クラスタ ディスク 1 台ずつに、ドライブ文字を割り当てる必要があったので、 1 つのクラスタが保持できるクラスタ ディスクの最大数は 23 ボリューム (アルファベット 26 文字から、A、B [フロッピー ドライブ]、C [システム/ブート ドライブ] 分を引いた数) でした。

Windows Server 2003 では、 クラスタ ディスクにドライブ文字を割り当てる必要がなくなったので、 ディスクの数は、物理的に取り付けられるディスクの数と元になるオペレーティング システムによってサポートされる数によって制限されます。

注意 : アプリケーションは、ドライブ文字が割り当てられていないディスクには、 次の 2 つのうちいずれかの方法でアクセスできます。a) ディスクに関連付けられているオブジェクト名を直接使用する。 または、より一般的に、b) 1 つのドライブ文字を使用してアクセスできる、 複数のディスクをまとめてリンクするマウント ポイントを使用する。

クラスタはどのようにして使用できるドライブ文字数よりも多くのディスクをサポートしますか?

ファイル システムのマウント ポイントを使用します。 マウント ポイントをクラスタ ディスクで使用する方法の詳細については、Windows Server 2003 のオンライン ヘルプを参照してください。

他の仮想サーバーが所有する共有を参照できるのはなぜですか?

ファイル共有はホストされる仮想サーバー名によってスコープが設定されません。 参照ツール (NET VIEW コマンドなど) を使用した場合、 現在、物理ノードでホストされているすべての共有が表示されます。

 ページのトップへ

可用性の高いプリント サーバー

プリンタをクラスタ化するにはどのようにすればよいですか?

プリンタは、"印刷スプーラ" クラスタ リソースを使用してクラスタ化できます。 Windows 2000 および Windows Server 2003 オンライン ヘルプの両方で、 具体例と可用性の高いプリント サーバーを作成するために必要な手順が記載されています。

アクティブ/アクティブ型プリントサーバーを構成できますか?

はい。 複数の印刷スプーラを 1 つのサーバー クラスタでホストすることは可能です。 印刷スプーラを個別にフェールオーバーでき、 クラスタ内の複数のノードで同時に実行できます。

ある 1 台のサーバーからクラスタへプリンタの設定を移行するにはどうしたらよいでしょうか?

マイクロソフトでは、 リソース キットの一部としてツール (Print Migrator) を提供しています。 これは、プリンタの設定をノードの 1 台から別のノードへ、 またはノードの 1 台からサーバー クラスタへ移行する際に使用できます。

1 つのクラスタでは何台のプリンタをホストできますか?

プリンタの数は、クラスタがサポートできるリソースの数によって制限されますが、 プリンタ数が増えれば、フェールオーバーできる数も増えることになります。

 ページのトップへ

単一障害点の排除

サーバークラスタは他にどのようなサービスに依存していますか?

クラスタ サービス自体は、 クラスタ ノード間のトラフィックを認証および署名できる機能に依存しています。 クラスタ サービスは、 クラスタ サービス アカウントを使用して、 ドメイン インフラストラクチャを認証に使用します。 サーバー クラスタがインストールされている環境では、 ドメイン インフラストラクチャの可用性が高いことを確認してください。 このインフラストラクチャに障害が発生した場合、 クラスタが利用できなくなる可能性があります。

その他に考慮すべきサービスは何ですか?

クラスタ環境でアプリケーションの高可用性を維持するには、 クラスタ外部のサービスでアプリケーションが必要とするサービスも高可用性を維持している必要があります。 これらのサービスの多くは、 レプリケーションやクラスタ対応になることによって、 障害から保護されるメカニズムを実装しています。 考慮すべきサービスの例としては、WINS、DNS、DHCP、ドメイン インフラストラクチャ、ファイアウォールなどが挙げられます。

他に対処すべき単一障害点は何ですか?

サーバー クラスタは、 アプリケーションをハードウェア障害、OS障害、およびアプリケーション障害から保護するためのメカニズムです。 次のような考慮すべきハードウェア障害がいくつかあります。

• ディスク障害 – ディスク障害に対する保護には、RAID やミラーリングを使用します。
• ハードウェア障害 – サーバーに複数のホット スワップ ファンを実装したり、冗長電源を確保したりします。
• ネットワーク障害 – 共有コンポーネントを持たない冗長ネットワークを用意します。
• サイト障害 – 障害回復計画を設定します。

 ページのトップへ

Active Directory、DNS、ドメイン コントローラ

クラスタでホストされるサービスに Kerberos 認証を使用できますか?

はい。Windows 2000 SP3 以降および Windows Server 2003 では、 クラスタ サービスにより Active Directory にコンピュータ オブジェクトが公開されます。 これにより、インフラストラクチャが仮想サーバーでホストされるアプリケーションやサービスに対して Kerberos 認証を使用するための十分な条件が整います。

Kerberos 認証およびその仕組みの詳細については、 次の TechNet Web サイトを参照してください。 https://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx (英語)

クラスタサーバーをドメインコントローラにすることはできますか?

はい。ただし、 この方法をとる前に、十分に理解しておく必要があるいくつかの注意点があります。 サーバー クラスタ ノードはドメイン コントローラとして使用されないこと、 またサバー クラスタ パブリックと同じサブネットにドメイン コントローラを配置されることをお勧めします。

クラスタ ノードをドメイン コントローラにする必要がある場合は、 次の重要な点について考慮してください。

• 2 ノード クラスタの 1 台のノードがドメイン コントローラである場合は、 すべてのノードをドメイン コントローラにする必要があります。 4 ノードのデータセンター クラスタの場合は、 最低でも 2 台のノードをドメイン コントローラとして構成することをお勧めします。

• ドメイン コントローラの実行にかかるオーバーヘッドがあります。 アイドル状態にあるドメイン コントローラは、Windows クラスタリングの実行も含めて、130 ～ 140 メガバイト (MB) の RAM を使用します。 また、ドメイン コントローラが、 ドメイン内およびドメイン間で他のドメイン コントローラと相互にレプリケートする必要がある場合は、 レプリケーション トラフィックも発生します。 企業でのクラスタ展開ではほとんどの場合、 ノードには数ギガバイト (GB) のメモリが実装されているので、 これが問題になることは通常ありません。

• ドメイン コントローラにクラスタ ノードしか使用されていない場合は、 各ノードには DNS サーバーも必要です。 また、プライマリ DNS 解決には別のノードを互い指し、 セカンダリ DNS 解決には自分自身を指すようにします。 クロスオーバー ケーブル経由で接続している場合、 DNS にプライベート インターフェイスを登録しない機能についての問題に対処する必要があります (2 ノードの場合のみ)。 ハートビート インターフェイスの構成方法については、 サポート技術情報の文書、 「258750」を参照してください。 ただし、サポート技術情報の文書、「258750」の手順 12 を完了する前に、 まず、サポート技術情報の文書、 「275554」で説明されているその他の構成設定を変更する必要があります。

• ドメイン コントローラにクラスタ ノードしか使用されていない場合は、 各ノードをグローバル カタログ サーバーにするか、domainlet を実装する必要があります。

• フォレストの 1 台目のドメイン コントローラが、 すべての FSMO (Flexible Single Master Operation) を獲得します (サポート技術情報の文書、 「192132」参照)。 これらの役割は各ノードに再分配できます。 ただし、ノードがフェールオーバーされた場合は、 そのノードが獲得した FSMO (Flexible Single Master Operation) は使用できなくなります。 その場合、Ntdsutil を使用して、 役割を取り上げ、 実行を続けているノードにこれを割り当てることができます (サポート技術情報の文書、 「223787」参照)。 ドメイン全体にわたる FSMO (Flexible Single Master Operation) の配置については、 サポート技術情報の文書、 「223346」を参照してください。

• ドメイン コントローラがビジーで、 クラスタ サービスがクォーラム ドライブへのアクセスを必要なだけ得られない場合、 クラスタ サービスはこれをリソース障害であると解釈し、 クラスタ グループを他のノードにフェールオーバーする可能性があります。 クォーラム ドライブが他のグループに存在し (ただし、これは推奨されない構成です)、 グループに影響を与える構成になっている場合、1 障害によりすべてのグループ リソースが他のノードに移動される可能性があり、 これは望ましくない場合があります。 クォーラム構成の詳細については、 サポート技術情報の文書、 「280345」を参照してください。

• ノードがドメイン コントローラでもある場合に、SQL Server や Exchange Server などの他のプログラムをクラスタ化すると、 リソースの制約により、最高のパフォーマンスを得られない可能性があります。 この構成は、展開前にラボ環境で十分にテストを行ってください。

• クラスタ ノードをドメイン コントローラにもできますが (詳細については、サポート技術情報の文書、 「171390」を参照)、 ドメイン コントローラが既にローカルである場合、 またはドメイン コントローラへの信頼できる高速接続が確保されている場合は、 ドメイン コントローラをクラスタ ノードに実装することはお勧めしません。

  注意 :
  Windows クラスタリングをインストールする前に Dcpromo ツールを使用して、 クラスタ ノードをドメイン コントローラに昇格する必要があります (詳細については、 サポート技術情報の文書、 「247720」を参照してください)。

• クラスタ ノードでもあるドメイン コントローラを降格する場合は、 特別な注意が必要です。 ノードがドメイン コントローラから降格されると、 セキュリティ設定およびユーザー アカウントが完全に変更されます (たとえば、ユーザー アカウントは、 ローカル アカウントに降格されます)。 クラスタ ノードでもあるドメイン コントローラを降格する場合は、 サポート技術情報の文書、 「247720」を参照してください。

仮想サーバーを Active Directory に公開できますか?

はい。Windows 2000 SP3 以降および Windows Server 2003 では、Active Directory に仮想サーバーを公開できます。

ネットワーク名サーバー クラスタ リソースによって、 コンピュータ オブジェクトが Active Directory に公開されますが、 グループ ポリシーの割り当てなどの管理作業にはこのコンピュータ オブジェクトを使用しないようにしてください。 Windows 2000 および Windows Server 2003 での仮想サーバー コンピュータ オブジェクトの役割は、 Kerberos 認証および委任を可能にし、 クラスタと Active Directory の両方に対応しているサービス (MSMQ など) がサービス プロバイダ情報を公開できるようにすることだけです。

クラスタ構成を Active Directory に保存できますか?

いいえ。現時点では、仮想サーバーのコンピュータ オブジェクト以外のクラスタ情報は、Active Directory に公開されません。

サーバークラスタによって、ドメインコントローラの高可用性は実現されますか?

いいえ。ドメイン コントローラは、複数のサーバー間でのレプリケーションを使用して高可用性を実現します。

DNS サーバーをサーバークラスタで利用できるようにするには、どのように構成したらよいですか?

クラスタ サービス アカウントが、 レコードを公開できる必要があります。 セキュリティで保護されている、DNS 対応のゾーンでは、 ユーザーのアクセス権を制限できます。 クラスタ サービス アカウントに、レコードを作成するためのアクセス許可が付与されているか、 レコードを事前に作成できる必要があります。 レコードが事前に作成されている場合は、ゾーンで動的更新を行うように設定しないでください。

 ページのトップへ

セキュリティ上の考慮点

クラスタサービスアカウントのパスワードを更新するには、どのようにしたらよいでしょう?

クラスタ内のすべてのノードのクラスタ サービス アカウントは、 クラスタ内通信が適切に認証されるようにするため、一致している必要があります。 クラスタ サービス自体は、さまざまな状況において、クラスタ ノード間でメッセージを送ります。 もし、それらの通信のいずれかが失敗した場合は、 クラスタ ノードがクラスタから分離されます (つまり、クラスタ サービスが停止されます)。 クラスタ サービスが通信を確立する時点を特定することはできないので、 クラスタが継続して実行されるようにしながら、 クラスタ サービス アカウントを信頼できる方法で変更できる明確な時間帯はありません。

Windows 2000

Windows 2000 では、次の手順を使用して、 クラスタ サービス アカウントのパスワードを確実に変更できます。

1. クラスタ内のすべてのノードでクラスタ サービスを停止します。
2. ドメイン コントローラで、クラスタ サービス アカウントのパスワードを変更します。
3. すべてのクラスタ ノードで、サービス コントロール マネージャのパスワードを更新します。
4. すべてのクラスタ ノードでクラスタ サービスを再開します。

Windows Server 2003

Windows Server 2003 では、cluster.exe コマンドを使用して、 ノードのクラスタ サービスをシャットダウンすることなく、 動的にクラスタ アカウントのパスワードを変更できます。cluster.exe コマンドによって、 ドメイン アカウントのパスワードが変更され、 クラスタ内のすべてのノードのサービス コントロール マネージャのアカウント情報が更新されます。

Cluster /cluster:cluster_name1[,cluster_name2,...]/changepassword*[:new_password[,old_password]] [*/skipdc] [/force] [**/**options]

詳細については、Windows Server 2003 のオンライン ヘルプを参照してください。

サーバークラスタで他に考慮する必要があるセキュリティ上の考慮点と推奨事例は何でしょうか?

セキュリティに関する推奨事例については、Windows Server 2003 のオンライン ヘルプを参照してください。

 ページのトップへ

パッケージに含まれる高可用性サービス

Windows リリースでは、高可用性 OS サービスは提供されていますか?

Windows オペレーティング システムのサーバーには、既定で、 次のような高可用性サービスが用意されています。

• IP アドレスおよびネットワーク名 – クライアントに独立した場所を与え、 フェールオーバーを意識させない、高可用性ネットワーク構成。
• DHCP – 高可用性 DHCP サーバー。
• MSDTC – 高可用性分散トランザクション コーディネータ。
• IIS – 高可用性 Web および FTP サーバー*。
• ファイル共有 – 高可用性ファイル共有サービスおよび DFS。
• メッセージ キュー – 高可用性 MSMQ サービス。
• MSMQ トリガ – 高可用性 MSMQ トリガ サービス (Windows Server 2003 新機能)
• 印刷スプーラ – 高可用性プリンタ サービス
• WINS – 高可用性 WINS サービス

* Windows Server 2003 では、Windows によって提供されている汎用スクリプト リソースとスクリプトを使用して、 IIS がクラスタ対応になっています。IIS 固有のリソースの種類はありません。

サーバークラスタでは MSMQ トリガはサポートされますか?

はい。Windows Server 2003 では、サーバー クラスタを使用して MSMQ トリガの高可用性を実現できます。

IIS はクラスタに対応していますか?

はい。Windows 2000 では、"IIS サーバー インスタンス" という種類のリソースを使用して、 IIS Web サイトと FTP サービスの高可用性を実現できます。 Windows Server 2003 では、IIS サーバー インスタンス リソース タイプに代わって、 Windows Server 2003 に用意されている汎用スクリプトが使用されます (IIS Web サーバーおよび FTP サーバーの Windows 2000 から Windows Server 2003 への変換方法の詳細については、 オンライン ヘルプを参照してください)。

サーバー クラスタを使用したフェールオーバーによって、IIS Web サーバーの高可用性を実現できますが、 IIS の高可用性の実現および Web サービスまたは Web ファームのスケールアウトには、 Windows オペレーティング システムが提供しているもう 1 つのクラスタ メカニズムである、 ネットワーク負荷分散 (NLB) によって提供されるような負荷分散クラスタを使用することをお勧めします。

FTP サーバーの高可用性の実現については、 アクセス上の特性によって、サーバー クラスタかネットワーク負荷分散クラスタのいずれかを選択できます。 サーバー クラスタは、 頻繁に更新が行われる FTP サイト、 または FTP コンテンツのコピーを 1 つだけ保持するサイトに適しています。 ネットワーク負荷分散は、主に読み取り専用の FTP サーバーに適しています。

クラスタ内で IIS メタベースの整合性はどのようにして保たれますか?

Windows オペレーティング システムには、IIS メタベースの整合性がクラスタのノード間で保たれるようにするツール (IISSync) が用意されています。 詳細については、オンライン ヘルプを参照してください。

 ページのトップへ

地理的に分散したクラスタ

サーバークラスタを複数のサイトにまたがって構成できますか?

はい。サーバー クラスタでは、複数のサイトにまたがる単一クラスタがサポートされています。 これは、地理的に分散したクラスタとして知られています。 認定済みの地理的に分散したクラスタ ソリューションは、 https://www.microsoft.com/whdc/default.mspx(英語) で公開されている Microsoft ハードウェア互換性リスト (HCL) に記載されています。 マイクロソフトによってサポートされているクラスタ ソリューションは、HCL に記載されているもののみです。

地理的に分散したクラスタはどのように定義されますか?

地理的に分散したクラスタは、次の属性を持つサーバー クラスタです。

1. 複数の記憶域配列を持ち、 各サイトに少なくとも 1 つの配列が配置されています。 これにより、いずれか 1 つのサイトでエラ－が発生した場合に、 他のサイト (1 つまたは複数) がサ－ビスおよびアプリケ－ションを継続して提供するために使用できるデ－タのロ－カル コピ－を持つことになります。
2. ノ－ドは、1 つのサイトまたは複数のサイト間での通信リンクでエラ－が生じた場合に、 任意のサイトのノ－ドがそのサイトの記憶域にアクセスできるように、記憶域に接続されています。 つまり、2 つのサイト構成では、サイト A のノ－ドはサイト A の記憶域に直接接続されており、 サイト B のノ－ドはサイト B の記憶域に直接接続されています。 サイト A のノ－ドはサイト B の記憶域にアクセスすることなく継続でき、 その逆も同様です。
3. 記憶域ファブリックまたはホストベ－スのソフトウェアは、 各サイトがデ－タのコピ－を持つように、 複数のサイト間でデ－タをミラ－化または複製する方法を提供しています。 異なるレベルの一貫性を適用することが可能です。

この図は、単純な 2 サイトのクラスタ構成を表しています。

地理的に分散したクラスタにより、障害耐性または障害回復能力を得ることはできますか?

複数サイトを使用したサーバー クラスタ構成の目的は、 ソリューション内のサイトの 1 つが失われた場合でも、 完全にアプリケーションが利用できなくなる状態にならないようにして、 ビジネスを継続し、 障害から回復することにあります。 通常、サイトは最高で 300 ～ 500 km ほど離れて配置されているので、 完全に電源は異なり、 通信インフラストラクチャのプロバイダや配置場所も異なるので、 自然災害 (地震など) によって複数のサイトが破壊される可能性はまずありません。

地理的に分散したクラスタによって、 障害耐性は提供されません。 これは、場合により、アプリケーションの再起動を手動で行う必要があるためです。

地理的に分散したクラスタでは、サイト間の非同期レプリケーションが使用されますか?

はい。ただし、次の 2、3 の点について、注意が必要です。

• クォーラム データは、 サイト間で同期を取ってレプリケートされる必要があります。 サーバー クラスタの一貫性が保証されるように、 すべてのノード間でクラスタ データベースの整合性が保たれている必要があります。 クォーラム ディスクがサイト間でレプリケートされる場合は、 同期を取ってレプリケートされる必要があります。

  Windows Server 2003 で提供されている新しいクォーラム リソース "マジョリティ ノード セット" は、 このような構成において、クォーラム ディスクのレプリケーションの代わりに使用できます。

• データが非同期にレプリケートされる場合、 サイト障害が発生すると、 セカンダリ サイトの整合性は保たれますが、 古い時点の状態になります。 アプリケーションが "前の時点への後退処理" を処理できること、 および業務を進める上でクライアント側に問題がないことを確認してください。 SQL Server などのアプリケーションは、 非同期レプリケーションで処理することもできますが、 認識しておく必要のある制限事項や注意点があります (SQL Server データの複数サイト間でのレプリケーションに関する規則については、 SQL Server の高可用性についてのドキュメントを参照してください)。

• データがブロック レベルでレプリケートされる場合、 レプリケーションはセカンダリ サイトへの書き込みの順序を保持する必要があります。 書き込み順序が保持されない場合は、データの破損につながります。

マイクロソフトは、完全なエンドツーエンドの地理的に分散したクラスタソリューションを提供していますか?

いいえ。マイクロソフトからは、 地理的に分散したクラスタ内の 1 つのサイトから別のサイトへアプリケーション データをレプリケートするためのソフトウェア メカニズムは提供されていません。 マイクロソフトは、 ハードウェア ベンダおよびソフトウェア ベンダと協力して、 完全なソリューションを提供できるよう取り組んでいます。 認定済みの地理的に分散したクラスタ ソリューションは、 https://www.microsoft.com/whdc/default.mspx(英語) で公開されている Microsoft ハードウェア互換性リスト (HCL) に記載されています。 マイクロソフトによってサポートされているクラスタ ソリューションは、HCL に記載されているもののみです。

サーバークラスタで複数のサイトをサポートするためのその他の必要条件には、何があるでしょうか?

マイクロソフトのサーバー クラスタリング ソフトウェア自体は、 地理的に分散したクラスタのその他の特性については認識することはありません。 Windows 2000 または Windows Server 2003 のサーバークラスタには、 このような構成に固有の特殊機能はありません。 地理的に分散したクラスタを構築するために使用したネットワ－クおよび記憶域ア－キテクチャは、 サ－バ－ クラスタ テクノロジが期待する意味合いを維持する必要があります。 基本的に、地理的に分散したクラスタの構築のネットワーク アーキテクチャおよび記憶域アーキテクチャは、 次の必要条件を満たす必要があります。

1. クラスタ ノード間のプライベート ネットワークおよびパブリック ネットワークは、 単一の、ルーティングなしの LAN として扱われる必要があります (たとえば、VLAN などのテクノロジを使用して、 クラスタ内のすべてのノードが同じ IP サブネット上に存在するようにします)。
2. ネットワ－ク接続は、500 ミリ秒以下で "最大限保証された" ノ－ド間の往復の待ち時間を提供できる必要があります。 クラスタはハ－トビ－トを使用して、 ノ－ドが機能しているか、応答していないかを検知します。 これらのハ－トビ－トは定期的に送られます。 ノ－ドがハ－トビ－ト パケットに応答するまでの時間が長すぎた場合、 クラスタ サービスはどのノ－ドが実際に機能していて、 どのノ－ドが機能していないかを特定するために、 複雑なプロトコルを開始します。 これをクラスタの再グル－プ化と呼びます。 ハ－トビ－トの間隔は、 クラスタ サ－ビスの構成可能なパラメ－タではありません (これには多くの理由がありますが、 結論としては、 このパラメ－タの変更はクラスタの安定性およびフェ－ルオ－バ－時間に、 重大な影響を及ぼす可能性があるためです)。 人工的な再グル－プ化が行われないようにするために、 往復 500 ミリ秒はいかなるしきい値よりも大幅に低い値です。
3. Windows 2000 では、 クラスタには、クォ－ラム ディスクとして知られている単一の共有ディスクを配置する必要があります。 記憶域インフラストラクチャは、 クラスタ ディスクでディスクのセットが単一のディスクのように扱われるよう、 サイトにまたがるミラーリングを提供できますが、 物理ディスク リソ－スが必要とする基本的な意味合いは維持する必要があります。
   • クラスタ サ－ビスは、SCSI の RESERVE コマンドおよび BUS RESET を使用して、 共有ディスクの調整や保護を行います。 これらのコマンドの意味合いは、 サイト間で完全な通信エラ－が発生した場合でも、 サイト間で維持される必要があります。 サイト A のノ－ドがディスクを予約した場合、 サイト B のノ－ドからこのディスクのコンテンツにアクセスできてはいけません。 これらの意味合いは、 クラスタ デ－タおよびアプリケ－ション デ－タの破損を防ぐ上で必要不可欠です。
   • クォ－ラム ディスクはリアルタイムで、 すべてのサイト間で、同期モ－ドでレプリケートされる必要があります。 ミラ－化されたクォ－ラム ディスクのメンバにはそれぞれ、 同じデ－タが含まれている必要があります。

Windows Server 2003 では、 ミラー化またはレプリケートされたクォ－ラム ディスクか、 新しいリソース、"マジョリティ ノード セット" を複数サイトを使用したクラスタに使用できます。

アプリケーションに関するその他の必要条件は何でしょうか?

サーバー クラスタと同様、 アプリケーションも地理的に分散したクラスタのその他の特性については認識することはありません。 アプリケーションによって異なるサイトが認識できるようになるトポロジ情報や構成情報は、 アプリケーションには提供されません。

通常、地理的に分散したクラスタでは、 予想されるとおり、 アプリケーションを実行するために必要になる変更はありません。 ただし、アプリケーション ベンダに確認をとる必要があります。 場合によっては、 障害タイムアウト期間の変更が必要になることがあります。 これは、クラスタ間の距離があり、 またサイト間でデータのミラーリングやレプリケーションが必要になるので、 ディスク アクセスやフェールオーバーにより時間がかかる場合があるためです。

 ページのトップへ

クォーラム

クォーラムは何のために使用されるのですか?

サーバー クラスタが機能するためには、 クォーラム リソースが必要です。 クォーラム リソースは他のリソースと同様に、 一度に 1 台のサーバーしか所有できないリソースで、 サーバー同士はその所有権をめぐりネゴシエートします。 クォーラム リソースの所有権をネゴシエートすることにより、 サーバー クラスタは、サーバーはアクティブなのに、 他のサーバーはダウンしていると見なしてしまう "ネットワーク パーティション (スプリット ブレイン: Split-brain）" 問題を回避できます。 これは、たとえば、クラスタの相互接続が失われ、 ネットワークの応答時間に問題がある場合に発生する可能性があります。 クォーラム リソースは、クラスタ構成の最終的なコピーを保存し、 どのような障害の影響があったとしても、 クラスタ構成が常に一貫性が保たれているようにするために使用されます。

**クォーラムリソースに使用できるリソースには何がありますか?**Windows 2000 では、クォーラムに使用可能なリソースには次の 2 種類があります。

• 物理ディスクリソ－ス
  共有クラスタ ストレージ バスにあるディスクをクォーラム リソースとして使用できるようにします。 クラスタ コードは、SCSI コマンドを使用してクォーラム ディスクを調整し、 一度に 1 台のノードしかクォーラム ディスクを "所有" できないようにします。 これは、すべての実稼動 Windows 2000 クラスタに対して推奨される標準のクォーラム リソースです。

  注意 : ストレージ ベンダの中には、 特定のハードウェア ソリューション (IBM Shark Storage など) やソフトウェア ソリューション (Veritas Volume Manager など) 用に、 独自のクォーラム対応リソースを提供しているベンダもあります。 使用している環境に必要な場合は、これらを使用してください。

• ローカルクォーラム
  2 台目のストレージ バスを構成せずに、1 台のノードのクラスタを設定できます。 この種のクラスタは、 複数ノードのクラスタを必要とせずに、 クラスタ対応ソフトウェアを開発する際に便利です。
  単一ノードでサーバー クラスタによって提供されるリソースの状態監視機能やローカルの再起動機能を利用する場合は、ローカル クォーラムを実働環境で使用できます。

Windows Server 2003 では、また 1 つ新たにクォーラム対応リソースを導入ました。

マジョリティノードセット

マジョリティ ノード セットは、 サーバー クラスタからは単一のクォーラム リソースに見えますが、 実際にはデータはクラスタ上の複数のディスクに格納されます。 マジョリティ ノード セット リソースは、 マジョリティ ノード セットに格納されたクラスタ構成データの一貫性が、 異なるディスク間で確実に保たれるようにします。

詳細については、「マジョリティ ノード セットとは何ですか?」を参照してください。

他のアプリケーションがクォーラムディスクを共有できますか?

クラスタのクォーラム ディスクを他のアプリケーションで使用しないようにすること、 またクォーラム ディスクはクラスタ サービス自体によってのみ使用されるようにすることをお勧めします。 クォーラム ディスクを他のアプリケーションで使用する場合は、 次の点に注意してください。

• クォーラム ディスクの状態によって、 クラスタ全体の状態が判断されます。 クォーラム ディスクで障害が発生した場合、 クラスタ サービスはすべてのクラスタ ノードで利用できなくなります。 クラスタ サービスは、クォーラム ディスクの状態を確認し、 標準の入出力操作を使用して物理ドライブへの排他アクセスを調整します。 これらの操作は、このデバイスへのその他の入出力と共に、 デバイスのキューに格納されます。 クラスタ サービスの入出力操作が、 かなり激しいトラフィックによって遅延された場合、 クラスタ サービスは、クォーラム ディスクが失敗したものと宣言し、 再グル－プ化を強制して、 クラスタの別の場所でクォーラムをオンラインに戻します。 悪意のあるアプリケーションによる入出力を利用したクォーラム ディスクへのフラッディング攻撃を防ぐよう、 クォーラム ディスクを保護する必要があります。 クォーラム ディスクへのアクセスは、 ローカル管理者グループとクラスタ サービス アカウントに制限されるようにしてください。
• クォーラム ディスクの空き容量がなくなった場合、 クラスタ サービスは必要なデータをログに記録できなくなる可能性があります。 この場合、クラスタ サービスは、 すべてのクラスタ ノードで失敗する可能性があります。 悪意のあるアプリケーションによりクォーラム ディスクがいっぱいにされることを防ぐため、 アクセスは、ローカル管理者グループとクラスタ サービス アカウントに制限されるようにしてください。
• クラスタ サービス自体は、 常にクォーラム ディスクをオンラインに戻そうとします。 その際、クラスタ サービスは、 同じグループ内のアプリケーションに設定されたフェールオーバーやフェールバック ポリシーに違反することがあります。

NAS デバイスを共有クォーラムディスクとして使用できますか?

いいえ。提供されている状態のままではクラスタ サービスがサポートするのは、 共有クラスタ バスまたは Windows Server 2003 "マジョリティ ノード セット" クォーラム リソースです。

マジョリティノードセットとは何ですか?

マジョリティ ノード セットは、 サーバー クラスタからは単一のクォーラム リソースに見えますが、 実際にはデータはクラスタ上の複数のディスクに格納されます。 マジョリティ ノード セット リソースは、 マジョリティ ノード セットに格納されたクラスタ構成データの一貫性が、 異なるディスク間で確実に保たれるようにします。 これにより、以下のクラスタ トポロジが可能になります。

原則として、マジョリティ ノード セットを構成するディスクは、 ノード自体に物理的に接続されたローカル ディスクか共有ストレージ ファブリック上のディスクであることが考えられます。 Windows Server 2003 でサーバー クラスタの一部として提供されているマジョリティ ノード セットの実装では、 クラスタの各ノードはそれぞれのローカル システム ディスクにあるディレクトリを使用して、 クォーラム データを格納します。 クラスタの構成を変更する場合、 変更は異なるすべてのディスクに反映されます。 変更が次のような構成に対して行われる場合のみ、 その変更はコミットされたものと見なされます。

(<クラスタで構成されるノード数>/2) + 1

これにより、 マジョリティ ノードはデータの最新のコピーを確実に所有します。 クラスタの一部として構成されたマジョリティ ノードが起動されてクラスタ サービスを実行する場合、 クラスタ サービス自体は起動だけを行い、 リソースをオンラインにします。 ノードが少ない場合、クラスタはクォーラムを持たないように指示されます。 このためクラスタ サービスは他のノードが参加を試みるまで （再開の試みを） 待機します。 マジョリティまたはクォーラムのノードが使用可能な場合にのみ、 クラスタ サービスが開始され、リソースをオンラインにします。 このようにして、ノードの障害に関わらず、 最新の構成がマジョリティのノードに書き込まれているので、 クラスタは常に最新の構成で起動されます。

 ページのトップへ

クラスタ対応アプリケーション

クラスタ対応アプリケーションとは何ですか?

クラスタ対応アプリケーションとは、 クラスタ API を呼び出して実行されているコンテキスト (仮想サーバー名など) を特定し、 ノード間でフェールオーバーして高可用性を確保できるアプリケーションのことです。

クラスタ用に作成されていないアプリケーションの高可用性を実現できますか?

はい。サーバー クラスタには、 リソース dll が必要な制御機能と状態監視機能を提供し、 既存のアプリケーションの高可用性を実現できるプラグイン環境が用意されています。

サーバー クラスタには、 既存のアプリケーションのクラスタ内でのフェールオーバーを可能にするために使用できる汎用的なリソースの種類が提供されています。 Windows 2000 では、次の 2 つの汎用リソースの種類があります。

汎用アプリケーション	あらゆるアプリケーションをクラスタサービスによって開始、停止、監視できるようにします。
汎用サービス	既存の Windows サービスを開始、停止、監視できるようにします。

これらの汎用サービスにより、 非常に基本的な状態監視機能 (たとえば、開始されたプロセスがシステム上でまだ有効なプロセスであるかどうか) が提供されます。 これは、あるアプリケーションが要求をサービスしているかどうかは、 そのアプリケーションに固有の知識が必要になるため、確認しません。 汎用リソースは、 アプリケーションのフェールオーバーが比較的迅速に行われるようにするために使用できますが、 より適切な状態確認をするためには、 アプリケーション固有のリソース dll を作成することをお勧めします。

Windows Server 2003 では、 また別の新しいリソースの種類 (汎用スクリプト) が導入されています。 これは、C や C++ ではなく、 スクリプトとして開始/停止機能や状態監視機能が実装されるようにします。 これにより、アプリケーション固有のリソース プラグインの作成が、 非常に対処しやすい簡単な作業になりました。

クラスタ対応アプリケーションを作成するにはどのようにすればよいですか?

サーバー クラスタには豊富な API セットが用意されています。 これを使用すると、 アプリケーションがクラスタ環境を認識し、 利用できるようになります。 これらの API については、プラットフォーム SDK に詳細が記載されています。

アプリケーションの高可用性を実現するには、汎用サービスまたは汎用アプリケーションリソースを使用する必要がありますか?

汎用サービスにより、 非常に基本的な状態監視機能 (たとえば、開始されたプロセスがシステム上でまだ有効なプロセスであるかどうか) が提供されます。 これは、あるアプリケーションが要求をサービスしているかどうかは、 そのアプリケーションに固有の知識が必要になるため、確認されません。 汎用リソースは、 アプリケーションのフェールオーバーが比較的迅速に行われるようにするために使用できますが、 より適切な状態確認をするためには、 アプリケーション固有のリソース dll を作成することをお勧めします。

マイクロソフトは、サーバークラスタで利用できるソフトウェア製品の検証やロゴ認定を行っていますか?

はい。サーバー クラスタリングは、Windows Advanced Server ロゴ プログラムのオプション コンポーネントです。 アプリケーションは、サーバー クラスタ上で動作する場合、ロゴ認定を受けることができます。

マイクロソフトのアプリケーションはクラスタ対応アプリケーションですか?

次の Windows オペレーティング システムの一部として提供されているサービスは、クラスタに対応しています。

• DHCP – 高可用性 DHCP サーバー
• MSDTC – 高可用性分散トランザクション コーディネータ
• IIS – 高可用性 Web および FTP サーバー*
• ファイル共有 – 高可用性ファイル共有サービスおよび DFS
• メッセージ キュー – 高可用性 MSMQ サービス
• MSMQ トリガ – 高可用性 MSMQ トリガ サービス (Windows Server 2003 新機能)
• 印刷スプーラ – 高可用性プリンタ サービス
• WINS – 高可用性 WINS サービス

その他に、次のマイクロソフト製品はクラスタに対応しています。

• SQL Server 6.5、7.0、2000 およびそれ以降
• Exchange Server 5.5 およびそれ以降
• Services for Unix 3.0 およびそれ以降

Exchange 2000 は、アクティブ/アクティブ型クラスタをサポートしますか?

はい。ただし、アクティブ/アクティブ型構成で Exchange 2000 をサポートする場合、 いくつか注意が必要な点があります。

SQLServer は、アクティブ/アクティブ型クラスタをサポートしますか?

はい。SQLServer では、次の構成が可能です。

• 単一クラスタ内の複数ノードによる異なるデータベースのホスト。 各データベースは、個別にフェールオーバーできます。
• 単一クラスタ内の複数ノードによる単一データベースのパーティションのホスト。 クライアントからは、データベース ビューを使用して別々のインスタンスを 1 つの論理データベースにまとめて扱うことができます。

クラスタ対応アプリケーションの作成方法についての情報はどこから入手できますか?

クラスタの概念および API については、 プラットフォーム SDK に詳細が記載されています。 また、プラットフォーム SDK には、 サーバー クラスタ統合のデモとして使用できるいくつかの例も記載されています。

サーバークラスタでは Services for Macintosh (SFM) はサポートされますか?

いいえ。サーバー クラスタでは Services for Macintosh はサポートされません。

サーバークラスタでは Services for Unix (SFU) はサポートされますか?

はい。Services for Unix は、SFU 3.0 で高可用性 NFS 共有をサポートしています。

 ページのトップへ

その他のトピック

サーバークラスタとネットワーク負荷分散を同じサーバーセット上で使用できますか?

いいえ。Microsoft サーバー クラスタ (MSCS) とネットワーク負荷分散 (NLB) は同じノード セット上ではサポートされません。 サーバー クラスタもネットワーク負荷分散クラスタも、 ネットワーク アダプタを制御および構成します。 サーバー クラスタとネットワーク負荷分散は互いを認識しないので、 一方を構成した場合、他方に影響が出る可能性があります。

サーバークラスタでアンチウィルスソフトウェアを使用できますか?

はい。その場合、ベンダによってサーバー クラスタ環境でソリューションがテストされていることを確認してください。 ウィルス対策ソフトウェアは、 通常、ストレージ スタックにディスク ドライバとして組み込まれます。 このため、このドライバが必要な機能をサポートしていない場合、 ディスクをフェールオーバーするクラスタの機能が影響を受ける場合があります。

マイクロソフトは、Distributed Lock Manager (DLM) を提供しますか?

いいえ。現時点では、Distributed Lock Manager (DLM) をリリースする予定はありません。 ただし、ユーザーからの DML サービスに対する要望が数多く寄せられる場合は、 計画を変更する可能性があります。

注意 : Distributed Lock Manager (DLM) と "クラスタ ファイル システム" を混同しないようしにしてください。 クラスタ ファイル システムは、さまざまな方法で構築でき、 ロック マネージャを使用するのもその方法の 1 つです。 ただし、ロック マネージャを使用するだけでは、 クラスタ ファイル システムの問題を解決できません。

マイクロソフトは共有ディスククラスタファイルシステムを提供する予定ですか?

マイクロソフトでは、 継続的に Windows オペレーティング システムで提供されるサービスを改良する方法を検討しています。 共有ディスク クラスタ ファイル システムは、 次のようなクラスタ属性を提供するための 1 つの方法です。

• 単一のファイル システム名前空間– クラスタ内のすべてのノード上のアプリケーションから認識できます。
• クラスタ内のあらゆるノードからのディスクへの高速アクセス。

サーバークラスタとフォールトトレラントサーバーはどのように関係していますか?

サーバー クラスタは、次のような可用性の問題に対処します。

• ハードウェア障害
• OS 障害
• アプリケーション障害
• サイト障害
• OS およびアプリケーションのアップグレード

フォールトトレラント サーバーは、 サーバー レベルでの冗長性を提供することによりハードウェア障害に対処する、 非常に信頼のおけるサーバー プラットフォームを提供します。 場合によっては、フォールトトレラント "サーバー" をサイト障害の対処に使用することもできます。

フォールトトレラント サーバー自体は、OS やアプリケーションの監視や障害回復に関する問題は処理しません。 また、サービスの停止を必要としない OS やアプリケーションのアップグレードを実現することもできません。

要約すれば、 サーバー クラスタは高可用性を提供するものであり、 フォールトトレラント サーバーは高い信頼性を提供するためのものです。 高い信頼性を備えたフォールトトレラント サーバーとサーバー クラスタを組み合わせることで、 両方の最も優れている点を利用でき、OS やアプリケーションの障害やアップグレードの際に、 信頼性の高いサーバー セットで高可用性を実現できます。

サーバークラスタ関連のサポート技術情報はどこで入手できますか?

すべてのクラスタ関連のサポート技術情報はの文書は https://support.microsoft.com/ で公開されています。

• NT 4.0 関連の技術情報には、すべて、キーワード "MSCS" が指定されています。
• Windows 2000 関連の技術情報には、すべて、キーワード "W2000MSCS" が指定されています。

これを利用すると、サーバー クラスタ関連の技術情報を簡単に検索できます。

このドキュメントに記載されている情報は、 このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。 変化する市場状況に対応する必要があるため、 このドキュメントは、 記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。 また、発行以降に発表される情報の正確性に関して、 マイクロソフトはいかなる保証もいたしません。

このドキュメントに記載された内容は情報提供のみを目的としており、 明示または黙示に関わらず、 これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

お客様ご自身の責任において、 適用されるすべての著作権関連法規に従ったご使用を願います。 このドキュメントのいかなる部分も、 米国 Microsoft Corporation の書面による許諾を受けることなく、 その目的を問わず、 どのような形態であっても、 複製または譲渡、 あるいは検索システムに格納または公開することは禁じられています。 ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。 ただしこれは、著作権法上のお客様の権利を制限するものではありません。

マイクロソフトは、 このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、 またはその他の無体財産権を有する場合があります。 別途マイクロソフトのライセンス契約上に明示の規定のない限り、 このドキュメントはこれらの特許、商標、著作権、 またはその他の無体財産権に関する権利をお客様に許諾するものではありません。

© 2002. Microsoft Corporation. All rights reserved. Microsoft、Active Directory、Visual Studio、Windows、 および Windows NT は米国 Microsoft Corporation の米国またはその他の国における登録商標または商標です。

このドキュメントに記載されている会社名、製品名には、各社の商標のものもあります。

ページのトップへ