特集　Windows Server 2003完全ガイド エンタープライズ環境はこう変わる コラム：冗長性を用いて高可用性システムを構築する4つの方法 Peter Pawlak 2003/08/28 Copyright(C) 2003, Redmond Communications Inc. and Mediaselect Inc

　アプリケーションやOSで高可用性を実現するに当たり、システム設計者は分散サービスおよびアプリケーション、フォールトトレラント・サーバ、サーバ・ファーム、サーバ・クラスタの4種類の異なるアプローチを用いて冗長性を追加できる。

■分散サービスおよびアプリケーション
　Windowsシステム・サービスやほかのアプリケーションを設計する際に、それらが複数のサーバで稼働（分散）し、OSのサポートや特殊なハードウェア的配慮なしに冗長性とフォールトトレランスを実現できるようにすることが可能なこともある。分散サービスおよびアプリケーションの例としては、Active Directory（AD）、ドメイン・ネーム・サービス（DNS）、さらにWindows分散ファイル・システム（DFS）とファイル・レプリケーション・サービス（FRS）の組み合わせがある。この分散方式は共有データのアップデート頻度が比較的低い場合に最もうまく機能し、サーバが帯域幅の限られたWANで接続されたサイトにある場合でも通常うまく機能する。Oracleなどの一部のベンダは、分散方式を用いて高可用性トランザクショナル・データベースまでサポートしている。しかし大多数のアプリケーションにとってはこの方式は最良ではないか、アプリケーションはそのような使い方を前提に設計されていない。

■フォールトトレラント（FT）サーバ
　基本的に、2つの同期したOSインスタンスが別々のCPUとメモリ、ネットワーク・アダプタ、ディスク・ストレージで同時に稼働し、その上で稼働するアプリケーションには単一のサーバに見える特殊用途のサーバである。システムがハードウェア・コンポーネントやOSのソフトウェア・コンポーネントに問題を検出すると、フェイルオーバーはほぼ瞬時に実行される。

　OSとハードウェアの観点からすると、FTサーバは最高水準の可用性を実現し、通常はその上で稼働するアプリケーションを停止せずにアップグレードとメンテナンスが実行できる。しかし、アプリケーション自体の障害に対する特別な保護は提供せず、アプリケーションの稼働中にそのアプリケーションに対しメンテナンスを行うこともできない。FTサーバは一般に、通常のサーバよりはるかに高価である。

　FTサーバはMarathon Technologies、NEC、Stratus Technologiesの各社が提供している。これら各社の現行製品はWindows 2000 Serverベースだが、Stratusは2003年下半期にWindows Server 2003ベースのFTサーバを出荷する計画を発表している。

■サーバ・ファーム
　複数のサーバで同じアプリケーションのコピーを稼働する方式。DNSサーバとハードウェア負荷分散デバイス（CiscoやF5などのメーカー製）、Windowsネットワーク負荷分散（NLB）サービスなどのソフトウェア・テクノロジの一部との組み合わせは、受信したクライアントのリクエストをファーム内のサーバに分散させる。ファームの主要目的はスケーラビリティの提供である。しかしクライアント・ソフトウェアまたは負荷分散システムがアプリケーションやOSのインスタンス、またはハードウェアの障害を検出し、負荷分散システムがリクエストをファーム内のほかの正常なサーバに振り向けることができれば、冗長性は可用性の向上にもつながる。

　ファーム方式は通常、各クライアントからの接続が比較的短時間で、サーバが「ステート」データ（eコマースのショッピング・カートの内容など）をローカルで格納したり、トランザクショナル・データ（購入に関連するデータなど）を保管したりする必要のない場合に最もうまく機能する。ステートとトランザクショナル・データをファームから独立したデータベース・サーバに格納できるなら（Windows Server 2003のIISの場合のように）、ファーム上のアプリケーションに障害が発生した場合、ユーザーはリクエストを再試行でき、負荷分散システムによって別のサーバにルーティングされ、ユーザーが被る影響は最小限に抑えられる。Webサイトはしばしばこの方法で構築される。この方式はビジネス・ルールを処理するがデータを格納しないWebサービスやほかのアプリケーションをサポートするファームに拡張できる。

　Windows Server 2003のNLBサービスは、IISの改良とASP.NETの追加との組み合わせにより、サーバ・ファームの構築を容易にする。

　しかし、大多数のサーバ・ファームは別のデータベース・サーバに依存しており、一部のアプリケーションはファーム方式をまったく使えない。このためサーバ・クラスタは多くの場合、データベース・アプリケーションの高可用性を実現する最良の方式である。

■Windowsサーバ・クラスタ
　ネットワーク的には単一のサーバとして見える複数のサーバ（同一のメーカーやモデルである必要はない）であり、ストレージ・エリア・ネットワーク（SAN）上にホスティングされた共通のディスク・ストレージ・ボリュームに接続されていて、ステータス情報をネットワーク経由で常時共有している。アプリケーションの観点からすると、各アプリケーションはクラスタ内の2つ以上のサーバにインストールされている。しかし、アプリケーションの1つのインスタンスだけが「アクティブ」サーバで稼働しており、これがディスク・ストレージ・ボリュームに独占的にアクセスしてすべてのクライアント・リクエストにサービスを提供する。ほかのサーバはアプリケーションのそのインスタンスに関して「パッシブ」であり、従ってクラスタは本質的にはスケーラビリティを提供しない。しかし、クラスタ内のほかのサーバは、同じアプリケーションのほかのインスタンスや、別のアプリケーションに関してはアクティブで、各アクティブ・ノードは別のディスク・ボリュームに独占的にアクセスできる可能性もある。このコンフィギュレーションはしばしば「アクティブ−アクティブ」と呼ばれるが、同じディスク・ボリュームに接続する2台以上のサーバが負荷を共有することはない（次の図「典型的なクラスタ・コンフィギュレーション」を参照）。

典型的なクラスタ・コンフィギュレーション

この図は2台の「仮想」サーバをホスティングする3台の物理的サーバ（またはノード）で構成されたWindows Server 2003クラスタの論理ダイアグラムを示す。サーバ・ノード1とノード2は「仮想サーバA」をホスティングし、ノード2とノード3は「仮想サーバB」をホスティングする。各仮想サーバは1つ以上のサービス（例えばファイル、プリント、SQL Server、Exchange、そのほかのクラスタ対応アプリケーション）をクライアント・コンピュータ（ほかのサーバまたはユーザーのワークステーション）に提供する。ノード1、2、3はそれぞれ社内データ・ネットワークと、別の相互接続ネットワーク（図では「Cluster Interconnect」と表示）に接続されており、これによってほかのサーバの状態を監視できる。この例ではノード2は「パッシブ」な役割に徹しており、「アクティブ」なノード1またはノード3を引き継ぐことができる。 　3つのノードはすべてSANアダプタ（Fibre ChannelまたはiSCSIオーバーGigabit Ethernet）も備えており、SANストレージ・アレイに接続されている。各ノードはローカル・ディスク・ストレージを装備せず、代わりにSAN上の自身の専用ボリュームからブートする（Windows Server 2003のこの機能はSANベンダ側のサポートが必要）。ノード1とノード2（仮想サーバA）も共通データ・ボリュームにアクセスできるが、フェイルオーバーが発生しない限りアクセスできるのはノード1だけである。同様に、ノード2とノード3（仮想サーバB）は別の共通データ・ボリュームにアクセスできるが、フェイルオーバーが発生しないかぎりそれにアクセスできるのはノード3だけである。 　3つのノードはいずれも、総合的なクラスタ・コンフィギュレーションとステート情報を格納する特殊なクォーラム・ボリュームにアクセスできる。フェイルオーバー発生時（あるいは障害が発生したノードを正常な状態に復帰するときのフェイルバック実行時）には、残りの正常なノードはこのボリュームを用いて、どのノードをアクティブにしてデータ・ボリュームに独占的にアクセスさせるかを決定する。

　アクティブ・ノードに障害が発生した場合、パッシブ・ノード（サーバ）が自動的に引き継いで新しいアクティブ・ノードとなり、データを格納しているディスク・ボリュームにアクセス可能になる。この「フェイルオーバー」プロセスにかかる時間は通常1分以内で、特殊なクライアント・ソフトウェアは必要としない。しかし、このプロセスは完全にシームレスではない。アクティブ・サーバのCPUレジスタとメモリの内容はパッシブ・サーバに連続的にミラーリングされないため、アプリケーションやサービスはパッシブ・サーバ上で起動する必要があり、ディスクに書き込まれた最後のトランザクションについてのみ最新の状態となる。接続中のコンピュータの視点からするとフェイルオーバーは一時的なネットワーク切断に見え、アプリケーションに再度接続し直す必要があるかもしれない。

　Microsoftのクラスタリング方式にはもう1つの潜在的弱点がある。アクティブ・ノードとパッシブ・ノードが共通のディスク・ボリュームを共有するので、完全に冗長ではないのである。しかしこの弱点は、ボリュームをSAN上にホスティングすることで乗り越えられる。このSANはデータをRAIDアレイに格納し、冗長なストレージ・コントローラとネットワーク接続を使用する。

　Microsoftのクラスタリング方式の大きなメリットは、Windowsクラスタ・サービスAPIによって開発者が比較的簡単にアプリケーションを「クラスタ対応」にすることができ、完全な分散アプリケーションとして設計する手間がかからないことである。アクティブ・ノードのOSやハードウェアの障害がパッシブ・ノードへのフェイルオーバーを引き起こすのと同様に、クラスタ対応アプリケーションの障害もフェイルオーバーを引き起こすことがある。クラスタ方式は、複製上の記録が同期しなくなることが許されないトランザクショナル・データベースに理想的だ。Microsoft SQL ServerとExchangeのEnterpriseバージョンはクラスタ対応として設計されており、Windowsサーバ・クラスタ上で稼働しているときに何らかの障害が発生するとフェイルオーバーが引き起こされる。

　Windowsクラスタはサーバ・ファームよりも高価でSANを必要とするが、業界標準のサーバを使用するのでまだかなり経済的である。しかし、MicrosoftはMicrosoftハードウェア互換性リスト（HCL）に掲載された完全なクラスタ・ソリューションだけをサポートするので、顧客はクラスタをデバイス・レベルのコンポーネントから自由に構築してサポート対象のコンフィギュレーションに組み立てることはできない。

　多くの場合、総合的な高可用性ソリューションはこれらの方式をいくつか組み合わせて用いる（一般的な実現方法は、図「一般的な高可用性Windowsシステム・アーキテクチャ」を参照）。

INDEX
	［特集］Windows .NET Server 2003完全ガイド
	Windows Server 2003でエンタープライズ環境はこう変わる
	1．Windows Server 2003信頼性向上のポイント
	コラム：高可用性システムの3つの重要ポイント
	コラム：Windows 2003 Datacenterの新機能
	コラム：冗長性を用いて高可用性システムを構築する4つの方法
	2．新しいフォールトトレラント・ハードウェア・コンポーネントのサポート
	3．サーバ・ファーム全体のネットワーク負荷分散の改善

　

Windows Server 2003完全ガイド

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）