Windows クラスタリング テクノロジの概要: サーバー クラスタとネットワーク負荷分散

トピック

	はじめに
	クラスタ アーキテクチャの基本
	サーバー クラスタ アーキテクチャ
	ネットワーク負荷分散アーキテクチャ
	コンポーネント負荷分散アーキテクチャ
	まとめ
	関連リンク

はじめに

Microsoft® はユーザーの声に耳を傾け、 Windows® オペレーティング システムの元になるテクノロジ アーキテクチャを向上するために常に努力してきました。

Microsoft クラスタ テクノロジ

Windows 2000 は以前の製品と比べ、 全体的な稼働時間 (可用性)、 システム障害の削減 (信頼性) およびリソースやコンピュータの追加によるパフォーマンス向上機能 (スケーラビリティ) という点で画期的に進歩していますが、 それに対して、Windows Server 2003 は既存の機能を強化し、 新しいオプションを提供することで、Windows オペレーティング システムの可用性、 信頼性およびスケーラビリティをまったく新しいレベルに高めています。

クラスタ戦略の3 つの分野

Microsoft クラスタリング テクノロジは、 可用性、信頼性、およびスケーラビリティを強化するための鍵になります。 Windows 2000 と Windows Server 2003 で、 マイクロソフトは次の 3 つの分野のクラスタリング戦略を使用しています。

障害に対する保護

Microsoft クラスタ テクノロジは、特に以下の 3 種類の障害から保護します。

クラスタリング テクノロジ—目的と要件

各テクノロジは特定の目的を持っており、 それぞれ違った要件を満たすようにデザインされています。

組織は、Microsoft クラスタテクノロジを使用して、 全体的な可用性を向上できると同時に、 業界標準のハードウェアやソフトウェアを利用して、 障害が 1 か所で発生するのを最小限に抑え、 コストを削減できます。

E コマースの事例

包括的なサービス提供物を設計するために、 上記で概説したクラスタリング テクノロジを組み合わせて使用できます (通常は、組み合わせて使用します)。 最も一般的な事例は、3 つのソリューションをすべて組み合わせた E コマース サイトです。 このようなサイトでは、 フロントエンド Web サーバーでネットワーク負荷分散 (NLB) を、 中間層アプリケーション サーバーではコンポーネント負荷分散 (CLB) を、 バックエンド データベース サーバーではサーバー クラスタをそれぞれ使用します。

しかし、このようなテクノロジだけでは可用性を最高レベルまで確実に高めるには十分ではありません。 組織が基幹業務アプリケーションやミッション クリティカルなサービスで最高の可用性を確保するには、 運用や可用性に対してエンド ツー エンドのサービス アプローチを取る必要があります。 つまり、サービス提供物すべてを全体的にとらえ、 Microsoft Enterprise Services で使用されているような、 業界標準の推奨事例に基づいたサービス ソリューションをデザイン、実装、および運用します。

この資料のトピック

この資料で取り上げるトピックには、以下のものがあります。

ページのトップへ

クラスタ アーキテクチャの基本

ここでは、 クラスタリングの概念と、その利点および制限事項について説明します。 さらにクラスタ組織、インフラストラクチャのスケール変換、クラスタ運用モード、 および地理的に分散された複数サイトでのクラスタリングの使用方法について説明します。

クラスタの概念

クラスタの概念とは、2台以上のコンピュータを設置し、 それらが連携して機能するように組み合わせ、 単独のシステムを使用した場合に比べて高い可用性、信頼性およびスケーラビリティが得られるようにすることです。 あるクラスタで障害が発生したときは、 リソースをリダイレクトして、作業負荷を再分散できます。 通常、エンド ユーザーは限られた範囲の障害を被るだけなので、 ブラウザを最新情報に更新したり、 アプリケーションに再接続するだけで作業を再開できることもあります。

クラスタの利点と制限事項

サーバー クラスタは、 クラスタ構成で相互にリンクされる複数のサーバーでアプリケーション ソフトウェアやデータを利用できるようにすることにより、 高可用性を提供します。 1 台のサーバーの機能が停止した場合、 フェールオーバーというプロセスによって、 障害が発生したサーバーの作業負荷がクラスタ内の別のサーバーに自動的に移行されます。 フェールオーバーのプロセスは、 重要なアプリケーションやデータの可用性を継続的に確保するようにデザインされています。

クラスタを障害に対処できるようにデザインすることは可能ですが、 クラスタはユーザー データに関してはフォールト トレラントではありません。 クラスタそのものでは、ユーザーの作業内容の損失は防げません。 通常、失われた作業内容の復旧は、 アプリケーションソフトウェアで対応します。 つまり、アプリケーション ソフトウェアは、 ユーザーの作業内容を復旧するか、 ユーザーのセッション状態が障害発生時でも保持できるようにデザインされている必要があります。

3 つの代表的な問題点を解決する

データ センター環境でクラスタを使用して、次の 3 つの代表的な問題点を解決できます。

適切にデザインされたサービス ソリューションは、 冗長性のあるシステムやコンポーネントを使用するので、 個別のサーバーに障害が発生しても全体のサービスの可用性には影響を及ぼしません。

制限事項

適切にデザインされたソリューションは、 アプリケーション障害、システム障害およびサイト障害の発生を防ぐことはできますが、 クラスタ テクノロジには制限もあります。 クラスタ テクノロジが適切に運用されるかどうかは、 互換性のあるアプリケーションとサービスに依存します。 ソフトウェアは、 障害発生時に適切に応答する必要があります。 クラスタ テクノロジは、 ウィルス、ソフトウェアの破損や人為的なミスによって起きた障害を防ぐことはできません。 この種の問題を防ぐには、強固なデータ保護や復旧計画が必要になります。

クラスタ組織

クラスタは、通常、ファームまたはパックと呼ばれる疎結合グループで組織されます。 ほとんどの場合、下図 1 のように、 フロントエンド サービスと中間層サービスは複製を使用したファームとして組織されます。 それに対して、バックエンド サービスとコンポーネント ルーティングなど重要なサポート サービスはパックとして組織されます。

IT 担当者の考慮事項

IT 担当者がクラスタ ソリューションを設計する際、 使用予定のクラスタ組織を注意深く検証する必要があります。 サーバーの使用方法とアプリケーションの実行方法によって、 サーバーを組織することを目標とすべきです。 通常、Web サーバー、アプリケーション サーバーおよびデータベース サーバーはすべて別々に組織されます。

図 1: 組織されるクラスタとファームまたはパック

クラスタ ファーム

ファームは、同種のサービスを実行するサーバーのグループですが、 通常、データを共有しません。 ファームと呼ばれる理由は、 要求が渡されると必ずローカルに保存されているデータの同一コピーを使用して処理するためです。 ファームは共有データではなく、データの同一コピーを使用するので、 ファームのメンバは自立して運用され、 "複製" とも呼ばれます。

ファームの一例としては、 インターネット インフォメーション サービス (IIS) を実行し、 ネットワーク負荷分散 (NLB) を使用するフロントエンド Web サーバーが挙げられます。 Web ファームを使用すると、 同一データはファーム内のすべてのサーバーに複製され、 各サーバーはデータのローカル コピーを使用して、 渡される要求をすべて処理できます。 サーバーが同一で、データが Web ファームのすべてのサーバーに複製てされているので、 サーバーは "複製" とも呼ばれます。

例—負荷分散された Web ファーム

10 台のサーバーを備えた負荷分散される Web ファームは、次のようになります。

クラスタ パック

パックは、連携して運用され、 パーティション分割されたデータを共有するサーバーのグループです。 パックと呼ばれる理由は、 サービスの管理と保守を行うために連携して機能するためです。 パックのメンバは、パーティション分割されたデータへのアクセスを共有するので、 メンバは一意な運用モードを持ち、 通常、パックの全メンバが接続するディスク ドライブ上の共有データにアクセスします。

例 - 4 ノードの SQL Server™ クラスタ パック

パックの一例としては、SQL Server 2000 を実行するデータベース サーバー クラスタ、 およびパーティション分割されたデータベース ビューを持つサーバー クラスタがあります。 パックのメンバはデータへのアクセスを共有し、 すべてのデータ要求を処理するのではなく、 処理するデータやロジックの重複しないブロックを所有します。

4 ノードの SQL Server クラスタは、以下のようになります。

技法の組み合わせ— 大規模 E コマース サイト

上記の技法を組み合わせてサーバーを 1 つの層に整理できます。 このような組み合わせの例には、 Application Center 2000 とコンポーネント負荷分散 (CLB) を実行する中間層アプリケーション サーバーを持つ、 大規模 E コマース サイトがあります。

コンポーネント負荷分散 (CLB) を構成するクラスタとして次の 2 つを推奨します。

Component Routing Cluster は、 サーバーを追加する必要なしに Web 層を構成できますが、 大規模 E コマース サイトでは、 独立したクラスタが持つ高い可用性の利点が必要になるかもしれません。 この場合、サーバー クラスタを使用して、 クラスタ化される独立したサーバーでルーティングが実行されることになります。 このアプリケーション サーバーは、その後、コンポーネント負荷分散 (CLB) を使用して'クラスタ化されることになります。

インフラストラクチャのスケール変換

適切なアーキテクチャを使用することにより、 拡大されていくパフォーマンスやスループットのニーズを満たすように、 特定の層のサーバーをスケール アウトまたはスケール アップできます。 以下の図 2 は Windows クラスタリング テクノロジのスケーラビリティの概要を示しています。

IT 担当者の考慮事項

IT 担当者がスケーラビリティの要件を検証する際は、 常に、組織の現実のビジネス ニーズに対処する必要があります。 Windows オペレーティング システムの適切なエディションを選択して、 現在および将来のプロジェクトのニーズに適合できることを目標にすべきです。

必要なサーバー数は、 サーバーの予想負荷およびサーバーが処理する要求のサイズと種類によって異なります。 プロセッサとメモリは、サーバーが実行するアプリケーションとサービス、 およびユーザーの同時接続数に適したサイズにすべきです。

図 2: Windows クラスタ テクノロジはビジネス要件を満たす規模にできます

サーバーの追加によるスケール変換

クラスタへのサーバー追加によるスケール アウトを検討するときに、 どのクラスタ テクノロジとサーバー オペレーティング システムを使用するかが重要になります。 下記の表 1 で示すように、Advanced Server と Datacenter Server の外見的なスケール変換機能の重要な違いは、 サーバー クラスタで使用されるノード数です。

表 1 オペレーティングシステムとテクノロジでサポートされるクラスタノード数。

CPU と RAM の追加によるスケール変換

CPU や RAM 追加によるスケール アップを検討するときは、 サーバー オペレーティング システムのどのエディションを使用するかが非常に重要になります。

プロセッサとメモリ容量の両点から、Datacenter Server の拡張性は非常に高くなります。

そのため、組織は時間の経過と共に変化するニーズに応じて、 通常、 Advanced Server または Enterprise Edition から、 Datacenter Server または Datacenter Edition にスケール アップします。

クラスタ運用モード

ネットワーク負荷分散 (NLB) とコンポーネント負荷分散 (CLB) では、 通常、クラスタ ノードは相互の複製であり、まったく同一のものです。 このため、クラスタのすべてのメンバは要求の処理を積極的に、 また互いに独立して行うことができます。 しかし、クラスタのメンバがデータへのアクセスを共有する際は、 サーバー クラスタの場合と同様、それぞれ独特な運用要件があります。

IT 担当者の考慮事項

IT 担当者がクラスタ アーキテクチャでの運用モードの影響を考慮する際は、 ビジネス要件やサーバーの予想負荷を慎重に検討する必要があります。

ネットワーク負荷分散 (NLB) とコンポーネント負荷分散 (CLB) では、 すべてのサーバーはアクティブで、 アーキテクチャはサーバーの追加によりスケール アウトされます。 この追加したサーバーは、通常、 既存のネットワーク負荷分散 (NLB) またはコンポーネント負荷分散 (CLB) のノードとまったく同一に構成されます。

サーバー クラスタでは、 ノードをアクティブまたはパッシブのどちらにでもでき、 ノード構成は運用モード (アクティブまたはパッシブ） およびフェールオーバーの構成方法により決まります。 フェールオーバー処理に指定されるサーバーは、 障害が発生した作業負荷と現在の作業負荷 (存在する場合) を処理できるサイズにする必要があります。 さらに、平均作業負荷とピーク時の作業負荷の両方を考慮する必要があります。 サーバーには、ピーク時の負荷を処理するために新たな容量が必要になります。

サーバー クラスタ ノード

サーバー クラスタ ノードはアクティブまたはパッシブのいずれにもできます。

マルチノード クラスタは、アクティブ ノードとパッシブ ノードのさまざまな組み合わせを使用して構成できます。

マルチノード クラスタを設計する

マルチノード クラスタを設計する際、 ノードをアクティブに構成するか、パッシブに構成するかが非常に重要になります。 以下の点を検討すると、理由がわかります。

マルチノード構成で、アクティブノードごとにパッシブノードが 1 つ存在する場合、 平均的な作業負荷で、CPU リソースとメモリ リソースの約 50% を使用するように構成できます。

以下の図 3 で示す 4 ノード構成では、 フェールオーバーは任意のアクティブ ノードから特定のパッシブ ノードに移行します。 これは 2 つのアクティブ ノード (A1 と A2） と 2つのパッシブ ノード （P1 と P2) が、 それぞれ 4 つのプロセッサと 4GB の RAM を持っていると考えることができます。 この例では、ピーク時の作業負荷の対処に余裕のある容量を使用するために、 ノード A1 を ノード P1 に、ノード A2 をノード P2 にフェールオーバーします。

図 3: アクティブ/パッシブとアクティブ/アクティブの構成例

パッシブ ノードよりアクティブ ノードの方が多いマルチノード構成では、 平均的な負荷の場合、CPU リソース数とメモリ リソース数に比例した割合でノードを使用するように構成できます。

上図 3 で示した 4 ノード構成では、 ノード A、B、C および D はアクティブに構成されており、 フェールオーバーはノード A と B の間、 または ノード C と D の間で移行します。 これは平均的な作業負荷で、CPU リソースとメモリ リソースの約 25% 使うように、 サーバーを構成することだと考えられます。 この例では、ノード A を ノード B （あるいはその逆） にフェール オーバーするか、 ノード C を ノード D （あるいはその逆） にフェール オーバーします。

この例のサーバーは、 ノードの障害発生時に 2 つの作業負荷に対処する必要があるので、 CPU とメモリ構成は少なくとも 2 倍になります。 そのため、4 基のプロセッサと 4GB の RAM ではなく、8 基のプロセッサと 8 GB の RAM を使用することもあり得ます。

非共有 （Shared-Nothing）データベースの構成

サーバー クラスタが複数のアクティブ ノードを持つ場合、 クラスタ サーバーで実行されるアプリケーション間でデータを共有する必要があります。 ほとんどの場合、これは非共有 （Shared-Nothing）データベース構成で対処されます。

非共有 （Shared-Nothing）データベース構成では、 アプリケーションがパーティション分割され、 プライベートなデータベース セクションにアクセスします。 これは、 特定のノードは特定の種類の要求 (たとえば、文字 A-F で始まるアカウント名など) を処理できる、 データベースに特定のビューで構成されること、 そしてこれがデータベースの関連セクションを更新できる唯一のノードであることを意味します。 これにより、マルチノードでの同時書き込みによる破損の可能性が除去されます。

注意
Microsoft Exchange 2000 と Microsoft SQL Server 2000 はどちらも、 複数のアクティブ ノードと非共有 （Shared-Nothing）データベース構成をサポートします。

複数のサイトと地理的に分散されたクラスタ

ほとんどの組織では、 複数の物理サイトを使って、 災害復旧や高可用性をインフラストラクチャに組み込みます。 複数サイト アーキテクチャはさまざまな方法でデザインされます。 ほとんどの場合、 アーキテクチャはプライマリ サイトと 1 つ以上のリモート サイトがあります。 下図 4 は、E コマース運用ののプライマリ サイトとリモート サイトの例を示しています

リモート サイトのアーキテクチャは、 プライマリ サイトのアーキテクチャをそのままミラー化したものです。 複数のサイトをどの程度統合するか、 またサイト間でどの程度コンポーネントをミラー化するかは、 サービス レベル契約やビジネス要件によって異なります。

完全実装のデザイン

完全実装により、 プライマリ サイトの完全なインフラストラクチャをリモート サイトに再構成できます。 これにより、リモート サイトを独立して運用したり、 必要に応じてプライマリ サイトの全負荷に対処できます。 この場合、デザインにはデータベースとアプリケーションにリアルタイムの複製と同期を組み込む必要があります。

リアルタイムの複製は、 サイト間のデータとアプリケーション サービスが一貫性のある状態であることを保証します。 リアルタイムの更新が不可能な場合、 データベースとアプリケーションをできるだけ早く複製し、同期を取る必要があります。

図 4: 複数サイト アーキテクチャ

部分実装のデザイン

部分実装により、 次の基本的なコンポーネントのみがリモート サイトにインストールされます。

Web サイトの静的コンテンツとデータベースの読み取り専用データを複製する。 この部分実装技法により、 リモート サイトで静的コンテンツや変更頻度の低いその他の種類のデータ要求を処理するできます。 ユーザーはサイトを参照したり、アカウント情報、製品カタログおよび他のサービスにアクセスできます。 動的コンテンツへのアクセスや情報の修正 (追加、変更、削除など) が必要な場合、 サイトの地理的な負荷分散により、 ユーザーをプライマリ サイトにリダイレクトできます。

インフラストラクチャのすべての層を実装するが、アーキテクチャの冗長性をほとんど持たない、または主要コンポーネントのみを実装し、完全な機能はそれを持つプライマリサイトに依存する。これらの部分実装技法のいずれかを使用する場合、 データベースやアプリケーションにリアルタイムに近い複製や同期を組み込む必要が生じることがあります。 これにより、データやアプリケーション サービスが一貫性のある状態であることを保証します。

地理的に分散されるクラスタ

完全なデザインでも部分的なデザインでも、 サーバー クラスタを実行する地理的に分散されるクラスタを使用できます。 地理的に分散されるクラスタは仮想 LAN を使用してストレージ エリア ネットワーク (SAN) に長距離接続します。

地理的に分散されるクラスタは、 拡張されたクラスタも呼ばれ、Windows 2000 や Windows Server 2003 で利用できます。

マジョリティ ノード クラスタリング

Windows Server 2003 は、 地理的に分散されるクラスタの分野で大きく改善されており、 マジョリティ ノード セットという新しい種類のクォーラム リソースもその 1 つです。 マジョリティ ノード クラスタリングはクラスタ クォーラム リソースの使用方法を変えました。 この方法により、ノードで障害が発生したときに一貫性を維持しながら、 クラスタ サーバーを地理的に分散させることができます。

標準的なクラスタ構成では、 下図 5 に示すように、 クォーラム リソースはすべてのクラスタ データベースの変更に関する情報を復旧ログに書き込みます。 これにより、クラスタ構成と状態データを確実に復旧できます。 クォーラム リソースは共有ディスク ドライブに常駐しており、 クラスタ内の他のノードが機能しているかどうかを確認するために使用できます。

図 5: ローカル クラスタと地理的に分散されるクラスタの比較

Windows Server 2003 のマジョリティ ノード クラスタ構成では、 クォーラム リソースはマジョリティ ノード セット リソースとして構成されます。 この新しいクォーラム リソースによって、 クラスタ構成の変更と状態の情報を含むクォーラム データを、 クラスタの各ノードのシステム ディスクに保存できます。 データはローカライズされるので、 クラスタ自体が地理的に分散していても、 クラスタを一貫性のある状態に維持できます。

名前が示すとおり、 ノードの大部分はこのクラスタ構成で正常に実行できる状態である必要があります。 クラスタの状態の一貫性がなくなる場合、 IT 担当者はクォーラムを強制的に一貫性のある状態に戻すことができます。 また、クラスタ ノードで機能するアルゴリズムの一種も、 クラスタの状態を確実に保つために役立ちます。

ページのトップへ

サーバー クラスタ アーキテクチャ

ここは、サーバー クラスタについて、 およびサーバー クラスタでアプリケーションとサービス用にフェールオーバーをサポートする構成方法について説明します。 またリソース グループ、クラスタ記憶装置、ネットワーク構成と記憶域ネットワークについても説明します。

サーバー クラスタ

サーバー クラスタはアプリケーションとサービスをフェールオーバーするために使用されます。 サーバー クラスタは最大 8 ノードまで構成できます。 各ノードは 1 つ以上のクラスタ記憶装置に接続されます。 クラスタ記憶装置を使用すると、 異なるサーバーが同じデータを共有したり、 このデータを読み取ってリソースにフェールオーバーすることができます。

記憶装置を接続する

記憶装置を接続する技法としてファイバー チャネルをお勧めします。

サーバー クラスタを構成する

サーバー クラスタはさまざまな異なる構成を使用して設定できます。 サーバーはアクティブまたはパッシブのいずれでも利用可能で、 あるサーバーで障害が発生した場合、 別のサーバーがリソースを引き継ぐように複数サーバーを構成できます。 使用される構成やアプリケーションにより、 フェールオーバーには数分かかりますが、 エンドユーザーが意識する必要のないようにデザインされます。

サーバー クラスタとフェールオーバー

ノードがアクティブなとき、 リソースは使用可能になります。 クライアントはこれらのリソースに専用の仮想サーバーからアクセスします。

サーバー クラスタは仮想サーバーの概念を使用して、 同時にフェールオーバーするリソース グループを特定します。 サーバーで障害が発生すると、 クラスタリング用のサーバーとして構成されたリソース グループは、 別のサーバーにフェールオーバーされます。 フェールオーバーを処理するサーバーは作業負荷の増加への対応に必要な容量の余裕を持つ必要があります。 障害が発生したサーバーがオンラインに戻る際、 サーバー クラスタはフェールバックを元のサーバーに戻すか、 あるいは現行のサーバーが継続して要求を処理できるように構成できます。

図 6: すべてのノードがアクティブなマルチノード クラスタ

上図 6 はデータベース クラスタのすべてのノードがアクティブで、 各ノードが別のリソース グループを持つ場合の構成を示しています。 パーティション分割されたデータベース ビューでは、 各リソース グループは異なる種類の要求を処理できます。 処理される要求の種類はアカウントの名前や地理的な場所といった 1 つ以上の要因に基づきます。 障害が発生した場合、 各ノードは順番に次のノードにフェールオーバーするように構成されます。

リソース グループ

リソースで互いに関連したり依存する要素は、 リソース グループを使用して関連付けられます。 高可用性を必要とするアプリケーションのみがリソース グループの一部となります。 他のアプリケーションはサーバー クラスタで実行できますが、 リソース グループの一部となる必要はありません。 リソース グループにアプリケーションを追加する前に、 IT 担当者はアプリケーションがクラスタ環境で動作可能かどうか判断する必要があります。

クラスタ対応のアプリケーション。 クラスタ環境で動作し、 クラスタ イベントをサポートするアプリケーションをクラスタ対応と呼びます。 クラスタ対応のアプリケーションは、 サーバークラスタに登録することで、 状態と通知情報を受け取ることができます。

クラスタ非対応のアプリケーション。 クラスタ イベントをサポートしないアプリケーションを、 クラスタ非対応と呼びます。 一部のクラスタ非対応のアプリケーションは、 リソース グループへの割り当てとフェール オーバーが可能です。

次の基準に満たすアプリケーションは、リソース グループに割り当てることができます。

リソースとリソースの種類の新機能

Windows Server 2003 では、 リソースとリソースの種類に新しい機能が加わりました。 新しいリソースの種類では、VBScript および JScript を使用してアプリケーションをクラスタ対応にすることができます。 さらに Windows Management Instrumentation (WMI) をクラスタ管理やイベント通知に使用できます。

リソース グループを設計する

リソース グループを設計する際、 高可用性を必要とするかどうかに関わらず、 IT 担当者はクラスタ環境で実行するサーバー対応のアプリケーションとサービスをすべて一覧する必要があります。 その後、このリストを次の 3 つに分類します。

高可用性を必要とするアプリケーションとサービスはリソースグループに配置します。 他のアプリケーションは監視を行い、 クラスタ化されたアプリケーションやサービスとのやり取りが明確にわかるようにします。 リソース グループの一部ではないアプリケーションやサービスの障害が、 提供されるソリューションの基本機能に影響を及ぼさないようにします。 もし影響を及ぼす場合は、 アプリケーションやサービスのクラスタ化が必要になることがあります。

注意
クラスタをサポートしない依存関係を持つサービスの場合、 IT 担当者はこのようなサービスで障害が発生した場合のバックアップ計画を作成するか、 VBScript および JScript を使用してクラスタ対応のサービスを作成してください。 ただし、この機能は Windows Server 2003 のみでサポートされることに注意してください。

提供するサービスのニーズを満たすことに重点に置いて、適切なハードウェアを選択します。 リソースのフェールオーバーと可用性の要件を的確にサポートするクラスタ モデルを選択します。 選択したモデルに基づいて余裕のある容量を追加し、 リソースの障害発生時やサーバーへのフェールオーバーが負荷を大幅に増大させたときに、 記憶域やプロセッサ、およびメモリを確実に使用できるようにします。

クラスタ化された SQL Server 構成の場合、 IT 担当者は高性能 CPU、高速ハードドライブおよびメモリ追加を検討する必要があります。 SQL Server 2000 と標準的なサービスは合わせると標準で 100 MB 以上のメモリを使用します。 さらに各ユーザー接続も約 24KB 消費します。 クエリ実行の最小メモリは １MB の RAM ですが、 平均的なクエリは 2 〜 4 MB の RAM を必要とします。 他の SQL Server プロセスもメモリを使用します。

クラスタ記憶装置を最適化する

クラスタ記憶装置の最適化は、 パフォーマンスと可用性のニーズに基づいて行います。 Windows 2000 Datacenter ハードウェア互換性リストには、 クラスタ RAID (Redundant Array of Independent Disks) 構成の詳細な要件一覧が掲載されていますが、 以下の表 2 では一般的な RAID 構成の概要を示しています。 表の内容は最も高いレベルの RAID から順に低いものへと並べられています。

表 2 RAID 構成

ネットワーク構成を最適化する

クラスタのネットワーク構成も最適化できます。 クラスタのすべてのノードは、 同じドメインの一部である必要があります。 これらはドメイン コントローラまたはメンバ サーバーとして構成できます。 マルチノード クラスタでドメインとして機能し、 重要なドメイン サービスにフェールオーバーを提供するノードが少なくとも 2 つあることが理想的です。 それ以外の場合、 クラスタ リソースの可用性はドメイン コントローラの可用性に関連付けられます。

プライベート ネットワーク アドレスとパブリック ネットワーク アドレス

通常、クラスタのノードは、プライベート ネットワーク アドレスとパブリック ネットワーク アドレスの両方で構成されます。

クラスタによっては、 パブリック ネットワーク アドレスが不要で、 代わりにプライベート ネットワークを 2つ使用するように構成される場合があります。 この場合、 最初のプライベート ネットワークはノード間通信用で、 2 番目のプライベート ネットワークはサービス提供物の一部である他のサーバーとの通信用です。

記憶域ネットワーク

クラスタ化されたサーバーと記憶装置は SAN 上で接続されることが増えてきています。 SAN はサーバーと記憶装置間にセキュリティで保護された高パフォーマンスの相互接続を使用して、 従来の一般的なネットワークよりも広帯域で短い待機時間を提供します。 Windows 2000 Datacenter Server と Windows Server 2003 Datacenter Edition は SAN プロバイダを使用して SAN 経由で直接的な通信を可能にする Winsock Direct という機能を実装します。

SAN プロバイダには、ハードウェアトランスポートへのユーザーモードアクセスがあります。 ハードウェア レベルで直接通信するときは、 各トランスポート エンドポイントを、 ユーザー モードで実行するアプリケーション プロセスのアドレス空間に直接マップできます。 これにより、 アプリケーションは直接 SAN のハードウェア インターフェイスにメッセージ要求を渡すことができ、 不要なシステム呼び出しやデータのコピーをなくします。

SAN は通常 2 つの転送モードを使用します。 1 つは小規模の転送用で、 主に転送制御情報で構成されます。 大規模な転送では、 SAN はローカルまたはリモート システムの CPU を必要とすることなく、 SAN ハードウェア インターフェイスによりローカル システムとリモート システム間のデータを直接転送する一括モードを使用できます。 一括転送はすべて、転送制御メッセージの交換によりあらかじめスケジュールが設定されます。

その他の SAN の利点

強化された通信モード以外にも、SAN には次のような利点があります

ページのトップへ

ネットワーク負荷分散アーキテクチャ

ここでは、 ネットワーク負荷分散について取り上げるとともに、 高度なスケーラビリティと可用性を必要とする IP ベースのアプリケーションとサービスへのフェールオーバーのサポートで、 この負荷分散が果たす役割についても説明します。

ネットワーク負荷分散

ネットワーク負荷分散 (NLB) は、 高いスケーラビリティと可用性を必要とする IP ベースのアプリケーションやサービスのフェールオーバーをサポートします。 ネットワーク負荷分散 (NLB) を使用すると、 要求の増加に応じて徐々に 32 台のサーバーまでスケールアウトできます。 また、Web サーバー、メディア サーバー、ターミナル サーバーおよび E コマース サイトの可用性を強化するためにも理想的です。 これらのサービスの負荷分散により、単一点障害およびパフォーマンスのボトルネックを確実に削減できます。

サーバー クラスタに適用される概念の多くが、 ネットワーク負荷分散 (NLB) にも適用されます。 ネットワーク負荷分散 (NLB) のノードは協調して機能しており、 TCP、UDP および GRE トラフィック要求など、重要な IP ベースのリソースを使用できるようにします。

注意
GRE トラフィックは、Windows Server 2003 ではサポートされますが、Windows 2000 ではサポートされません。

仮想 IP アドレスを使用したフェールオーバーとフェールバック

図 7 で示すように、 ネットワーク負荷分散 (NLB) では仮想 IP アドレスを使用します。 クライアント要求はこの仮想 IP アドレスに対して行われ、 ユーザーが意識する必要のないフェールオーバーとフェールバックを可能にします。 あるサーバーで負荷分散されたリソースに障害が発生した場合、 グループの残りのサーバーが障害が発生したサーバーの負荷を引き受けます。 障害が発生したサーバーがオンラインに復旧すると、 サーバーは自動的にクラスタ グループに戻り、 ネットワーク負荷分散 (NLB) はこのサーバーへの負荷分散を自動的に開始します。 フェール オーバーはほとんどの場合 10 秒未満で行われます。

図 7: ネットワーク負荷分散の概要

クラスタ化された記憶装置を使用しない

ネットワーク負荷分散 (NLB) では、 クラスタ化された記憶装置を使用しません。 各サーバーは負荷分散された IP ベース アプリケーションまたはサービスのコピーを実行します。 またアプリケーションやサービスの実行に必要なデータはローカル ドライブに格納されます。

トラフィックを特定のサーバーに振り分ける

ネットワーク負荷分散 (NLB) は、通常、 アプリケーションやサービスへの負荷分散に使用されますが、 特定の種類のトラフィックを指定サーバーに振り分けることもできます。 たとえば、HTTP と FTP トラフィックの負荷をサーバー グループへ分散することもできますし、 メディア サービス トラフィックをある単一サーバーに処理させることもできます。 後者の場合、 ネットワーク負荷分散 (NLB) によってトラフィックは指定されたサーバーへ流れ、 障害の場合のみ別のサーバーにルーティングします。

ハードウェアの変更が不要

ネットワーク負荷分散 (NLB) はネットワーク ドライバとして実行されるので、 ハードウェアを変更せずにインストールし、実行できます。 その動作は IP ネットワーク スタックに透過的です。 ネットワーク負荷分散 (NLB) は IP ベースなので、 負荷分散されるコンピュータすべてにIP ネットワークをインストールする必要があります。

ネットワーク負荷分散 (NLB) 用ネットワーク アダプタ

高いパフォーマンスのスループットや応答性を実現するために、 ネットワーク負荷分散 (NLB) では、通常、次の 2 つのネットワーク アダプタを使用します。

ネットワーク負荷分散 (NLB) は、 ユニキャストまたはマルチキャスト ブロードキャストを使用して、 受信トラフィックをクラスタ内のすべてのサーバーに振り分けます。 各ホストのネットワーク負荷分散 (NLB) ドライバは、 受信する指定ホストにバインドされたトラフィックのみを許可するので、 クラスタ アダプタとTCP/IP スタック間のフィルタとして機能します。 ネットワーク負荷分散 (NLB) は指定したポート上の TCP、UDP および GRE トラフィックのフローのみを制御します。 指定していないポートでの TCP、UDP および GRE のトラフィック、 およびその他の受信 IP トラフィックのフローは制御しません。 制御されないすべてのトラフィックは、IP スタックへ変更なしでパススルーされます。

1 基のネットワーク負荷分散 (NLB) 用ネットワーク アダプタを使用する

ネットワーク負荷分散 (NLB) は、 ネットワーク アダプタ 1 基だけでも機能できます。 この場合、次のような制限事項があります。

ユニキャストモード。 ユニキャスト モードを 1 基のアダプタで使用する場合、 ノード間通信はできません。 つまり、そのクラスタ内のノードは相互通信できないことになります。 ただし、クラスタ サブネット外のサーバーとは通信できます。

マルチキャストモード。 マルチキャスト ノードを 1 基のアダプタで使用する場合、 ノード間通信はクラスタ サブネット外のサーバーとの通信なので可能です。 ただし、クラスタ サブネット外から特定のクラスタ ホストへの中規模から大規模の量のトラフィックの処理には、 この構成は最適とは言えません。

ノード間通信および中規模から大規模の量のトラフィックを処理するには、 アダプタを 2 基使用する必要があります。

ネットワーク負荷分散 (NLB) サーバーを最適化する

サーバー クラスタを使用するときは、 ネットワーク負荷分散 (NLB) を使うサーバーは最適化の利点を得ることができます。 サーバーはその役割、実行するアプリケーションの種類、および使用する予定のローカル記憶域に対し最適化する必要があります。

ネットワーク負荷分散 (NLB) サーバーのローカル ハード ドライブに冗長性を持たせることは可能ですが、 ほとんどの例では可用性にあまり効果がなく、 サーバーにかかる費用が増加するだけです。 このため、通常、ネットワーク負荷分散 (NLB) サーバーのドライブでは RAID を使用せず、 フォールト トレランスも提供しません。 これは、ドライブがサーバー障害を引き起こしても、 ネットワーク負荷分散 (NLB) クラスタの他のサーバーがすぐに障害が発生したサーバーの作業負荷を引き受けられるという考え方からです。

データの同期を取る

RAID を使用しないのはおかしいと思えるかもしれませんが、 ネットワーク負荷分散 (NLB) を使用するサーバーは、 各サーバーにデータの同一コピーを持つ複製として組織されるとことを思い出してください。 多数のサーバーが同じデータを持つので、RAID セットを使ったデータの維持は、 サーバー クラスタでの維持ほど重要ではありません。 ただし、ネットワーク負荷分散 (NLB) を使用する場合は、 IT 担当者はデータの同期を考慮する必要があります。 各サーバーのデータ状態を維持するために、 変更が行われたら必ず複製を更新する必要があります。 定期的なデータ同期の必要性は、 サーバー アーキテクチャのデザイン時にオーバーヘッドとして考慮する必要があります。

ページのトップへ

コンポーネント負荷分散アーキテクチャ

ここでは、 コンポーネント負荷分散 (CLB) とその主な構造を説明します。 また、ルーティング サーバー、 コンポーネント負荷分散 (CLB) クラスタのデザインと最適化、 さらに記憶域の要件とメモリの要件についても説明します。

コンポーネント負荷分散

Windows オペレーティング システムの Advanced Server Edition および Datacenter Server Edition に 組み込まれたサーバー クラスタやネットワーク負荷分散 (NLB) とは異なり、 コンポーネント負荷分散 (CLB) は、 Microsoft Application Center 2000 の機能の 1 つで、 トランザクション コンポーネントに高可用性とスケーラビリティを提供するようにデザインされています。 コンポーネント負荷分散 (CLB) は最大 8 サーバーまでスケール アップでき、 分散ソリューションの構築に非常に適しています。

コンポーネント負荷分散 (CLB) は、 Windows 2000 および Windows Server 2003 オペレーティングの一部として提供される COM + サービスを使用します。 COM+ サービスは以下の機能を提供します。

COM+ コンポーネントは、 コンポーネント オブジェクト モデル (COM) と COM+ サービスを使用して、 構成と属性を指定します。 協調動作して一般的な機能を処理する COM+ コンポーネントのグループを、COM+ アプリケーションと呼びます。

コンポーネント負荷分散 (CLB)—主な構造

以下の図 8 はコンポーネント負荷分散 (CLB) の概要を示したものです。 コンポーネント負荷分散 (CLB) は以下の主要構造を使用します。

•	コンポーネント負荷分散 (CLB) ソフトウェアは、 負荷分散を行い、クラスタ メンバがコンポーネントをアクティブにする順番を決定します。
•	ルーターは、 フロントエンド Web サーバーとアプリケーション サーバー間のメッセージ ルーティングを処理します。 フロントエンド Web サーバーに格納されたコンポーネント ルーティング リストか、 別のサーバーに構成されたコンポーネント ルーティング クラスタから実装できます。
•	アプリケーションサーバークラスタは、 COM+ コンポーネントをアクティブにして、実行します。 アプリケーション サーバー クラスタは Application Center 2000 によって管理されます。 図 8: コンポーネント負荷分散

ルーティング リスト

ルーターに使用可能なルーティング リストは、 Web サーバーから各アプリケーション サーバーへの応答時間を監視するために使用されます。 ルーティング リストが個別の Web サーバーに格納されている場合、 各サーバーは独自のルーティング リストを持っており、 これを使用して定期的にアプリケーション サーバーの応答時間を確認しています。 ルーティング リストが別のルーティング クラスタに格納されている場合、 ルーティング クラスタ サーバーがこの作業を処理します。

応答時間の監視は、 特定の Web サーバーからどのアプリケーション サーバーが最も早く応答するかを判断するために行われます。 応答時間はメモリ内テーブルで監視されます。 また、どのアプリケーションに受信要求を渡すべきかを判断するために、 ラウンド ロビン方式で使用されます。 最も速い応答時間を示す (理論的に最も混雑がなく、最も要求処理能力が高い) アプリケーション サーバーに次の要求が渡されます。 さらに、その次の要求はその次に速いアプリケーション サーバーに渡される、といった具合です。

コンポーネント負荷分散 (CLB) クラスタをデザインする

コンポーネント負荷分散 (CLB) クラスタのアーキテクチャは、 サービス提供物の可用性の要件を満たすようにデザインする必要があります。 小規模から中規模の実装では、 フロントエンド Web サーバーはアプリケーション サーバー クラスタにルーティング リストをホストできます。 大規模の実装では、 専用のルーティング クラスタが、高可用性の要件を満たすことを確認する方が好ましいといえます。

コンポーネント負荷分散 (CLB) サーバーを最適化する

ネットワーク負荷分散 (NLB) と同様、 コンポーネント負荷分散 (CLB) クラスタのサーバーは、 その役割、実行するアプリケーションの種類、および使用予定のローカル記憶域に合わせて最適化する必要があります。

高速接続

ルーティング サーバーは、 メモリにルーティング リストを保持し、 ネットワークに高速接続する必要があります。

記憶域の要件とメモリの要件

別々に構成されているか、フロントエンドの一部として構成されているかに関わらず、 コンポーネント負荷分散 (CLB) では記憶域はあまり必要ありませんが、 RAM の追加が必要になることがあります。 それに対して、アプリケーション サーバーは、通常、 大容量 RAM、高速 CPU およびドライブ アレイへの一定の冗長性が必要になります。 ドライブ アレイに冗長性を持たせる場合は、 RAID 1 または RAID 5 などの基本的な構成で、 必要な可用性のレベルを維持することは十分可能です。

ページのトップへ

まとめ

クラスタ テクノロジは、 企業の要求を満たすサービス提供物を確実に提供するためにますます重要になりつつあります。 Windows 2000 および Windows Server 2003 は 3つのクラスタ テクノロジをサポートして、 高可用性、信頼性およびスケーラビリティを提供します。 そのテクノロジとは、 ネットワーク負荷分散 (NLB)、コンポーネント負荷分散 (CLB)、およびサーバー クラスタです。 これらのテクノロジは特定の目的を持っており、 異なる要件を満たすようにデザインされています。

クラスタ テクノロジだけでは、 高可用性という目標を確実に達成するには不十分です。 自然災害やその他、サービスの完全停止を招く出来事を防ぐために、 複数の場所に物理的に分散することが必要な場合もあります。 優れたアーキテクチャに加え、 有効なプロセスと手順が高可用性にとって重要と言えます。

ページのトップへ

関連リンク

追加情報については、次のリソースを参照してください。

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

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

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

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

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

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

Microsoft Corporation. One Microsoft Way. Redmond, WA 98052-6399. USA

ページのトップへ