プロフェッショナル Application Center 2000

「 プロフェッショナル Application Center 2000 」 ( 発行 : 株式会社インプレス ) より抜粋

現在のオペレーティングシステムやソフトウェアを使えば、Web サイトを構築するのは比較的簡単だ。Microsoft 社の製品に関して言えば、Windows 2000 Server をインストールするだけで、実際に動作する Web サイトや Web アプリケーションを構築するのに必要なものがすべて組み込まれるので、アクセスしてくる人がそれほど多くなければ、十分実用に耐えるサービスが提供できる。

だが、いずれ Web サイトがビジネスの中心になるだろうし、その時点で、考慮しなければならない問題点がいくつか出てくる。たとえば、現状の Web サイトでアクセスしてくる人が増えても問題なく対処できるのだろうか ? サーバーに技術的な問題が発生した場合も 9 時～ 17 時の勤務体系できちんとサポートできるのだろうか ? Web サイトをサポートするデータベースアクセスやトランザクションサービスなどのバックエンドサービスがさらに複雑になった場合も、どうすればクライアントのアクセスを快適であり続けるように処理できるのだろうか ?

本書は、Windows 2000 で動作する Web サイトと Web アプリケーションの新しいソリューション、すなわち Microsoft Application Center 2000 について詳しく解説する (単に Application Center と呼ぶこともあり、AC2K や MSAC と省略する場合も多い)。

AppCenter とも呼ぶ人もいるが、本来、AppCenter は Microsoft 社ではない別の企業の製品名なので注意してほしい (http://www.borland.com/index.html)。

まず本章では、スケーラブルな Web サイトの構築に関連した、さまざまな問題点を見てみることにしよう。そして以降の章では、そのような Web サイトやアプリケーションをインプリメントするために AC2K をどのように利用できるのか、具体的な点を述べる。本章では以下の点を取り上げて解説する。

• スケーラビリティ、信頼性、利用性
• Web 上のスケーラビリティと信頼性
• AC2K の機能
• AC2K の設定

では、この「スケーラビリティ」と「信頼性」がどういう意味で使われているのかを考えてみよう。

トピック

 スケーラビリティ、信頼性、利用性
 堅牢なハードウェア
 堅牢なソフトウェア
 Web 上のスケーラビリティと信頼性
 Application Center の機能
 Application Center の設定
 まとめ

スケーラビリティ、信頼性、利用性

一般に「コンピュータ」と「信頼性」という 2 つの言葉は、互いに相容れないものだと考えている人が多い。どうしてもコンピュータを使わなければならないとしても、電気料金の合計金額が間違っていたり、オンラインショップで何か注文してもまったく処理されていなかったり、電話代が間違って請求されたり・・・、こういったトラブルがあまりにも頻繁に起こるので、コンピュータが諸悪の根源のような気がしてならないのだろう。

もちろん、ソフトウェアの誤動作や人的ミスで間違いが発生する場合も多いが、ディスククラッシュのようなハードウェアが原因の場合もよくある。問題は単純で、近代的な IT 環境のインフラ全体が本当の物理的な装置を基にしているからだ --- いつでも 100% 完璧に機器が動作し、絶対に誤動作しないとは考えられない。形あるものが壊れるのは自然のことで、信頼性 というのは、自分たちが期待していることをシステムがどれくらいの頻度でこなしているのか計測しただけにすぎない。

 

堅牢なハードウェア

現在のコンピュータは、これまでよりもずっと信頼性が高くなっており、コンピュータメーカーはいずれも新しい技術を駆使して信頼性の改善に努めている。たとえば、最新のサーバーシステムには、ホットスワップ型のディスクパックが取り付けられたり、バックアップ用に電源システムが二重に備え付けられていたり、ハードウェアを診断する機能がビルトインされるなど、マシンをずっと動作させ続けるための仕組みがいろいろと搭載されている。こういった連続動作を表す指針としてよく使われるのが、堅牢性 という言葉だ。

いま述べた 2 つの考え方の違いに注意してほしい。信頼性の保証は、システムにダメージを与えたり、停止させてしまうような不具合を最小限に抑えることを意味する --- わかりやすく日ごろ通勤に使っている自動車にたとえれば、油圧の警告ランプが点灯するようなものだ。これに対して、堅牢性というのは、システムが停止しないようにあらゆる手立てを尽くし、崩壊している状態を最短に抑えて短期間で復旧できるようにしておくことを意味している。つまり、自動車に搭載され常に作動している緩衝器と同じで、パンクしたときに自動的に穴がふさがる圧着封式のタイヤだとも言える。

 

堅牢なソフトウェア

この堅牢性という考え方は、近代的なソフトウェアにも取り入れられている。たとえば、Microsoft 社は、DLL のようなシステムレベルのファイルが別のバージョンで上書きされたり、うっかり削除されてしまわないよう、自動的に保護する機能を Windows 2000 に組み込んでいる --- 予期せぬ DLL の上書きはソフトウェアが誤動作してしまう一般的な原因である。また、デバイスドライバファイルに対してデジタル署名も施しており、デバイスドライバが完全に動作チェックされていて、オペレーティングシステムと完璧に互換性があるよう保証されている。Windows NT でブルースクリーンが表示されてしまう最も一般的な原因は、このデバイスドライバ中にエラーが発生したせいだと言われている。

だがそれでも、まったくエラーがないか、もしくはシステム全体を停止させてしまうような互換性など微塵もないオペレーティングシステム (もしくは普段から当然のように利用している重要なアプリケーション) を構築するのは、ほとんど不可能だ。

システムをよりスケーラブルにする

ハードウェアとソフトウェアのどちらも完璧な堅牢性と信頼性を絶対に保てないという考えの上には、さらに考慮しなければならない別の問題点がある。そのほとんどがスケーラビリティというくくりに収まる。別の言い方をすると、ハードウェアやソフトウェアが問題なく動作し続けるとしても、本当に課せられた負荷をサポートできるのだろうか。

スケーラビリティの追求は、Web だけでなく、あらゆる種類のアプリケーションにとって、分散コンピューティングの世界にある聖杯の 1 つを探し求めるのと同じだ。企業が成長して社員が増えるのにともなって、ドメインコントローラや電子メールサーバー、またネットワークのインフラ全体など、既存のリソースにかかる負荷も増えてしまう。そして、そのせいでパフォーマンスが落ち、関連システムがうまく動作しない原因にもなる。

ポイントは、企業のネットワーク、つまりイントラネットのような閉じた環境でなら、少なくとも成長予想の計画を立てられるが、インターネットのような全世界に自分のサイトやアプリケーションが公開されている環境だと、来月どのくらいのアクセスがあるのか正確に見積もるのはほとんど不可能で、自分の Web サーバーやバックエンドシステムにどのくらい負荷がかかるのかは判断できない。

システムのモニタリングとパフォーマンスの測定

また、自分のサイトやアプリケーションもモニタリングできなければならない。Web サイトや Web アプリケーションが動作しなくなってしまった場合、いつどのようにしてそれがわかるのだろう ? 顧客がいつ苦情の電話をかけてくるのだろう ? サーバーが火を噴いてサーバールームに煙が充満するのはいつだろう ? 自分の勤めている企業がいつ傾いてしまうのだろう ? 笑うかもしれないが、こういった例はありそうもない話ではないのだ。同じような事態が発生している Web サイトにおそらく毎週毎週アクセスしているはずだ。

システムのパフォーマンスをモニタリングするのは、スケーラビリティを実装するのと同じように重要なポイントだ。そもそも、システムにどのくらい負荷がかかっているのか知らなければ、負荷への対応計画をどうやって立てたらよいのだろう ? 今日は快調に動作していても、来月も本当に動いてくれるのだろうか ? 将来的に問題を発生させたくないのであれば、負荷がどのように変わったのか理解でき、またシステム上の負荷にどのように対処するのか計画しておくことが本当に重要なポイントなのだ。

将来のアプリケーション開発

本書では、Web サイトとN層アプリケーションを中心に話を進めることにしよう。企業内ネットワークで稼働させているような、従来のクライアント/サーバー型アプリケーションに関しては触れない。COM+ コンポーネントの負荷分散機能は、Web ベースではない N 層アプリケーションでも利用できるが、現在のおもなアプリケーション開発がどのようになっているのか調べてみれば、実際にはほとんどが Web ベースのアプリケーションであることがすぐにわかるはずだ。

事実、かなり有名な人が、ネットワークはコンピュータであると述べている。インターネットへの無線ネットワークやブロードバンドアクセスが急速に発展すると同時に、当然のものと考えているネットワークの世界が、このような将来の方向性にアプリケーション開発を追い立てているのは必然的なことだ。企業のイントラネットとグローバルなインターネットの両方で、あらゆる種類の新しいアプリケーションが動作するようになるだろう。

すでに、従来のものと非常によく似た Web ベースのアプリケーションもある。端的な例が Microsoft Exchange Server のOutlook Web Access 機能だろう。この Web アプリケーションは、見た目も機能もほとんど同じ Outlook 2000 メールクライアントのブラウザベースのインプリメントを生成する (図 1 を参照)。

図 1: Microsoft Outlook Web Access

この種の機能を実現するには、普通、サーバーベースのアプリケーションはサーバーサイドのバックエンドサービスを利用しており、そのためのカスタムコンポーネントを用意している場合も多い。だが一般に、Web ベースのアプリケーションが複雑になると、それにともなってサーバーの負荷も高まることになる。

アプリケーション サービス プロバイダ

突然登場した新しいビジネス分野の 1 つに、ASP (アプリケーションサービスプロバイダ) がある。最近の雑誌や書籍を読むと目に付く ASP という略語は、以前のもっと一般的な「Active Server Pages」という用語ではなく、いま述べた意味で使っていることが多い。

ASP というのは、この名称からもわかるように、ほかの人にアプリケーションサービスを提供しているだけにすぎない --- いろいろな意味で、自社の IT 部門をアウトソーシングしているのと似ている。自分のアプリケーションを誰かに構築・管理してもらい、データのバックアップを作成するなど、関連するすべての問題の面倒をみてもらうことになる。自分は Web ブラウザ (またはカスタムインターフェイス) を起動して、Web 経由でアプリケーションにアクセスするだけでよい。

本書では、この分散型コンピューティングへの新しい手法が持つ具体的な長所や欠点に言及するつもりはない。だが、Web アプリケーション用の堅牢性・信頼性・スケーラビリティを最大限に高める必要性が増していることを表した端的な例だという点は、ここではっきりさせておいた方がよいだろう。

 

Web 上のスケーラビリティと信頼性

さて、スケーラビリティと信頼性を改善するには、よりスケーラブルで堅牢な単一のマシンを構築する方法がすぐに思い浮かぶだろう。当然、メインフレームのハードウェアや「企業レベル」のソフトウェアの開発メーカーは、多くがその方向性に突き進んでいる。

従来のネットワーク型アプリケーションは単一のマシンで稼働させてきており、その方式でこれまでずっとうまく動作してきた。近代的なメインフレームやミニコンピュータの利用可能時間は 99.9% 以上である。したがって、同じ高性能のマシンを Web アプリケーションサーバーとして使えばよい、というのがその理論だ。

利用しているソフトウェアがハードウェアと同じくらい堅牢で信頼性が高いと仮定すれば、これは非常にうまく動作する。事実、折り紙付きのソリューションである場合も多い。利用性が高く、スケーラブルな Web サイトや Web アプリケーションの向かうべき方向のこともある。負荷が高まれば、CPU やメモリを増やしたり、ホットスワップ型ディスクを搭載するといった対処を続ければ済む。

これがスケールアップという用語の意味するところだ。アプリケーションが「ディスクに書き出す」処理 (バッチ処理やデータベース管理など) を高い頻度で行っている場合には優れたソリューションだと言える。たとえば、効率的なディスクアレイ方式を採用しておけば、利用可能なディスクとヘッドの数だけ読み込み・書き出し処理を分散させることができ、一定のアクセススピードが維持できる。また、単一のマシンにリソースを集中させておくと、サーバー同士のネットワークトラフィックがなくなるので、結果として全体の効率性も高まることになる。

しかしながら、いま述べた以外のアプリケーションにとっては、おそらく最適なソリューションではないだろう。そういった大型マシンを購入して運営し、さらに維持管理するとなると、かなりの額の経費がかかってしまう。また専門チームも必要となる場合が多い。長期的な成長計画を立てておくことが必須となり、購入するマシンがスケーラビリティの必要条件に合致していなければならない。おまけに、こういった準備をしておいても「それでも十分ではなかったらどうするのか ?」という問題がいつもつきまとってしまう。

従来から提唱されているように、アプリケーションのスケーラビリティと信頼性を高める最も一般的な方法は、複数のシステムに分散させること、つまり複数のサーバーを利用することだ。こういった構成で Web サイトや Web アプリケーションを提供するようになったものは、一般に Web ファーム と呼ばれている。

最近では Web ガーデンという言葉もよく使われる。これはスケーラビリティを高めるのに、複数の個別のマシンではなく、1 台のマシンで複数のプロセッサを利用することを意味する。

複数のマシンを利用した信頼性

クライアントのリクエストを処理するために平行して複数のサーバーを稼働させる (サーバークラスタ と呼ばれる) 手法は、信頼性を高める非常に優れた 1 つの方法だ。構成要素のどれか 1 つ (ハードウェアやソフトウェア) がダウンしても、システム全体の停止に至ることはほとんどない。アプリケーションの各種のパーツは設置した個別のハードウェアにミラーリングされていて、サーバーが1台ダウンしても、ほかのサーバーがそのサーバーの代行を務ることができる。また、ソフトウェアがうまく動作しなくなった場合には、アプリケーションの別のインスタンスで既存のリクエストと新しいリクエストの両方を処理することが可能だ。一般に、こういった仕組みはフェールオーバー と呼ばれている。理想的な状況では、不具合が検出された際に、ハードウェアやソフトウェアのシステム同士で負荷を自動的に切り替えるようになっている。

このフェールオーバーの手法は、データベースや電子メールサーバーのようなアプリケーションでよく利用されている。アプリケーションソフトウェアそのものが具体的にクラスタで動作するよう設計されており、1 つのサーバーから別のサーバーへと処理の切り替えを管理できるようになっている。もちろん、状況によっては、ハードウェアやソフトウェアの組み合わせに応じて、処理が問題なく即座に切り替わるとは限らないが、通常は、ダウンタイムを最小限に抑えてすばやく復旧できるようになっている。

複数のマシンを利用したスケーラビリティ

一般に、Web サイトや Web アプリケーションの許容負荷の計画を立てる際、統計値、過去の実績値、推量値が混在していても大丈夫だ --- 過去の数値と推量の方が、統計値よりも信頼性があると言われている。したがって、コスト効率の高い方法で需要の変動幅を処理するには、ほとんどオンデマンドでシステムのスケーラビリティを高められるようになっている必要がある。

複数のマシンを利用した手法であれば、この柔軟性が生み出せる。必要なものは、同じクライアント処理ソフトウェア (つまり、Web アプリケーションや Web サイト) をインストールした補足マシンをいくつかまとめて、リクエストを新しいマシンを含めた複数のサーバーに分散し直すことだ。この手法はスケールアウト と呼ばれており、本書で詳しく解説する。

もちろん、最近のオペレーティングシステムやソフトウェアには、スケールアップとスケールアウトの両方の原理を基にして設計されているものが多い。特に、Microsoft 社の技術で言えば、Windows 2000 、COM+、.NET には、ハードウェアでスケールアップ (より多くのトラフィックのハンドリング) とスケールアウト (より多くのサーバーへの負荷分散) の両方を実現できる機能が用意されている。

どちらが優れているのか

一般的に言うと、スケールアウトのソリューションはコスト効率が高く、最終的により優れたスケーラビリティを期待できる。サイトの成長にともなってサポートも複雑になってしまうという問題点はあるが、通常、増加した負荷にうまく対処するようにマシンを追加することが比較的簡単だ。こういったマシンは、メインフレームやミニコンピュータシステムを購入して管理するよりもはるかにコストが安く済む。大規模な Web ファームでマシンがどれか 1 台欠けても、ほんの少ししか全体の性能に影響を及ぼさないし、不可抗力でダウンしても、マシンそのものを効率的にホットスワップできる。

しかしながら、これまで Web ファームにはいくつか不便な点もあった。おもな原因は、マシンを複数台利用したソリューションの構築・運営が行える専門的なソフトウェアが欠けていたせいだ。こういった問題にうまく処理できるよう、新規に設計されたのが AC2K だ。単一のマシンの場合と同じように、Web ファーム全体を簡単に動作させることが可能だ。次に、こういった問題点を解決できるように Application Center がどのように設計されているのか、もっと詳しく解説する。

 

Application Center の機能

Application Center 2000 (AC2K) には、複数のサーバーを利用した Web サイトや Web アプリケーションのプラットフォームを簡単に構築・管理・モニタリングできるように設計されたツールと機能が組み合わされている。AC2K のおもな機能としては、次のようなものが用意されている。

• 複数サーバーでスケールアウトさせた、インプリメントの簡単なスケーラビリティ
• 負荷共有と自動フェールオーバーによる高度な利用性の自動化
• クラスタ同士の自動的なコンテンツ同期とマシン設定
• Windows 2000 COM+ アプリケーションとコンポーネントの簡単な展開
• 個別マシンやクラスタ全体の一括モニタリング

次に、これらを順番に解説して、AC2K がどのように動作するのかもっと詳しく紹介しよう。だがその前に、本書の解説を理解する上で役立つように、Application Center の用語をいくつか述べておく。これまでの説明からおわかりだと思うが、1つのアプリケーションや Web サイトを提供するために複数のマシンを集めたものはクラスタ と呼ばれている。そして、当然のことだが、クラスタを管理するマシンはクラスタコントローラ と呼ばれている。

図 2 に、AC2K のメインとなる管理コンソールの画面を示す --- MMC (Microsoft 管理コンソール) のプラグインになっている。これはクラスタを 1 つも作成していない状態の画面だ。インターネットインフォメーションサービスや COM+ コンポーネントサービスといった、Web サイトや Web アプリケーションを管理する際に便利なスナップインがいくつも組み合わさっているのがわかるだろう。

図 2: AC2K の管理コンソール画面

インプリメントの簡単なスケーラビリティ

先に、どのようにして「スケールアップ」または「スケールアウト」すれば、全体のスケーラビリティを高めることができるのか解説した。スケールアップ技術は、OLTP (Online Transaction Processing) のようなデータベース指向のアプリケーションにとって便利な場合が多い。しかしながら、増加し続ける (変動が激しい場合が多い) 負荷を処理するために、高額のお金をかけて大容量のディスクアレイを搭載したマルチプロセッサのマシンを構築するのは正当だとは評価しづらい。

その代わりに、Web サイトの性能を高めるために用いられている手法としては、スケールアウトの方が一般的だ。これが複数のマシンで構成された「Web ファーム」のモデルで、現在、主要サイトのほとんどは何らかの形態でこの仕組みをインプリメントしている。たとえば、Microsoft 社の Hotmail サイトにログインすると、ブラウザのアドレスバー には http://lw10fd.law10.hotmail.msn.com/といったような URL が表示される。同時に数百～数千人ものユーザーをハンドリングするために、複数のサーバーが稼働しているのがよくわかるだろう。

AC2K は、この種のスケーラビリティを提供するために新規に設計されたものだ。ユーザーから受信したリクエストを複数のマシンに分散させるのに、Windows 独自のネットワーク負荷分散システムか、もしくは他社製のソリューションを利用するようになっている。ユーザーは「共通」の IP アドレス (と関連した URL) でクラスタにアクセスでき、ネットワーク負荷分散システムによって自動的にクラスタ中のいずれかのマシンにリダイレクトされる。

Windows ネットワーク負荷分散

NLB (Windows Network Load Balancing：Windows ネットワーク負荷分散) は、クラスタ中の各マシンに搭載したネットワークアダプタカード --- NIC (ネットワークインターフェイスカード) と呼ばれることもある --- と結び付けられたソフトウェア技術で、クライアントから受信したリクエストをクラスタを構成しているメンバに分散させるためのものだ。TCP (HTTP を含む) と UDP のどちらのプロトコルでも動作する。

NLB クラスタの各メンバは、届いたリクエストをすべて受信する。NLBはリクエストをどのメンバで処理するのか優れた分散アルゴリズムを使って決めており、処理しないマシンはどれもリクエストを破棄する。非効率的な技術のように思うかもしれないが、実際には、従来の負荷分散装置を使うよりもずっと効率的に動作する --- 不必要なリクエストをフィルタリングする方が、ルーティングするよりも高速に行えるからだ (図 3 を参照)。

図 3: Windows ネットワーク負荷分散

クラスタの各メンバは、負荷分散させたネットワークカードに対して NLB 交換メッセージを定期的に送信している (規定値は 1 秒ごと)。このメッセージは、たとえば、メンバが追加されたり、取り外されたり、オンラインやオフラインに設定されたりなどのクラスタの状態の変更に対して、メンバ同士でアクションを調整するために利用される。あるメンバが特定の数の NLB メッセージに応答しなかった --- つまり、オフラインになっていたり、クラスタから取り外された --- 場合 (規定値は 5 つ)、クラスタで適切に負荷分散できるように、NLB はクラスタの現在の状態を判断するためのプロセスを動作させ、アクティブな残りのメンバでリクエストを自動的に分散させる。

ハートビート ネットワークでのクラスタ管理

こうした NLB の同期メッセージはパブリックな負荷分散ネットワークに転送されるのだが、クラスタ中の全部のマシンを結ぶ「ハートビート」ネットワーク、つまり「バックエンド」ネットワークを構築しておくとパフォーマンスを高めることができる。このネットワークは、クラスタの各メンバにネットワークカードを2枚搭載して、メインの「パブリック」な、つまり「フロントエンド」ネットワークとは物理的に切り離しておく。こうしたネットワークを構築しておけば、パブリックなネットワークインターフェイスの性能に影響を与えずに、あらゆる種類のクラスタ管理情報をマシン同士で交換し合えることになる。

バックエンドネットワーク上に転送される管理情報のトラフィックには、コンテンツの複製や同期、設定情報のチェック、パフォーマンスやイベントのログ、パフォーマンスのモニタリングといった情報が含まれる。このバックエンドネットワークを、Windows NLB やサードパーティ製の負荷分散ソリューションと併用することが可能だ。

バックエンドネットワークを構築しておかない (各マシンにネットワークカードを 1 枚ずつしか搭載しておかない) 場合には、この管理情報のトラフィックはすべてパブリックなフロントエンドネットワーク上で転送されるため、パフォーマンスに影響が出てしまう。

また AC2K は、ASP のユーザーセッションのような「自動状態管理」を行う必要のある Web アプリケーションを扱えるようにも設定できる。通常、この機能はクライアントアフィニティ と呼ばれている。このプロセスの一部には、Web リクエストを 1 つのサーバーからほかのサーバーにリダイレクトする処理が関係しており、ハートビートネットワーク上でもリダイレクトコマンドが実行される。アフィニティとリクエストのフォワードに関しては、以降の章でもっと詳しく解説する。

高い利用性の自動化

自分の Web サイトが 1 台のサーバーで構成されている場合、そのマシンがダウンすると、Web サイト全体が稼働しなくなってしまう。だが、サーバーが 2 台ある場合には、1 台がダウンしても、サイト全体の性能は半分にしかならない。利用するサーバーの台数をもっと増やせば、増えた台数に比例してサーバーが1台ダウンしても、それほどの影響を及ぼさなくなる。

もちろん、利用しているシステムがユーザーのリクエストを処理するよりも Web ファームの管理にもっと多くのプロセス性能を必要としてしまうのであれば、スケーラビリティに対してマイナス効果が少し出てしまう。一般に、Windows NLB などのサービスによって奪われてしまうマシンのパフォーマンスは 10% 以下だ。また、中央集中型の統合化された (パフォーマンスやイベント情報の) ログ機能を利用する場合も、パフォーマンスに影響を及ぼしてしまう。

ある程度のレベルで、マシンを追加してもスケーラビリティは高められなくなる。しかしながら、これは 1 台のサーバーがダウンしてもサイトのスケーラビリティ全体に非常に限られた影響しか出ないほど十分に多くのマシンを設置してからずっと後になってのことだ。

現在の AC2K バージョン 1.0 では、クラスタサイズは最大で 12 台にするように推奨されている。もちろん、必要ならマルチプロセッサのマシンであってもかまわない --- この制限は内部マシンの通信とリダイレクト条件でしかない。1 つのクラスタを 12 台のマシンで構成した場合、1 台がダウンした場合の影響は、全体の性能が 10% 以下しか落ちない。AC2K バージョン 2.0 になれば、クラスタをさらにクラスタリングできるようになり、はるかに大規模なクラスタが作成できるようになるだろう。

言うまでもなく、1 台のマシンがダウンした場合に、ほかのマシンがその負荷を引き継ぐ点が重要なポイントだ。Application Center が利用する (Windows ネットワーク負荷分散を利用している場合の) 独立したハートビートネットワークでは、クラスタ中の各マシンがほかの全部のマシンの状態を知ることができるようになっている。したがって、各マシンはほかのマシンが利用可能かどうかわかり、どのマシンが現在最適な応答時間を提供しているのかも判断できる。

クラスタを構成しているマシンの中で、1 台はクラスタコントローラとして定義されている。しかしながら、必要であればどのマシンでも、そのタスクを行えるよう設定できる。実際、ちょうど Windows NT のプライマリドメインコントローラとバックアップドメインコントローラと同じように、クラスタ中の任意のマシンをクラスタコントローラに昇格させることも、元の単なるサーバーに降格させることもできる。違いは、クラスタのどのメンバも実質的にバックアップクラスタコントローラであるという点だ。設定や現在のパフォーマンス、クラスタの負荷に関する情報は各マシンが記録している。

クラスタコントローラがダウンしたとしても、クラスタ中の残りのマシンは、これまでどおりクライアントに対してサービスを提供し続けることができる。いわゆる「シングルポイント障害」というものはない。管理者は残った任意のマシンから 1 台をクラスタコントローラに昇格させることができ、そのマシンはコンテンツの同期処理を自動的に受け継ぐことになる。ダウンしていた以前のクラスタコントローラが利用可能になりオンラインに復旧すると、自動的に普通のクラスタメンバとなる。元の役割、つまりクラスタコントローラの役割を回復させる必要があれば、クラスタコントローラにもう一度昇格させることが可能だ。

クラスタコントローラの役割は、おもにコンテンツの同期を管理することと、各マシンからパフォーマンス情報を集めて記録し、全部を 1 つのプレゼンテーションに組み合わせることだ。また、AC2K 管理ツールを使った場合に、クラスタ用のメイン接続ポイントにもなる。クラスタコントローラからしか行えない管理作業もいくつかある。

コンテンツと設定の自動同期

スケーラビリティと利用性の問題をソフトウェアに自動的に処理させるという考え方は、非常に優れている。だが、Application Center は、それ以上のことを行えるようになっている。Web ファームをインプリメントするということは、コンテンツやアプリケーションコンポーネントなどに関して、各マシンがほかとまったく同じコピーを持つということを暗に意味する。つまり、Web ファームを管理する上で最も厄介な点は、すべてのファイルを適切に同期させることだ。

だが幸いなことに、この面倒な作業を Application Center が引き受けてくれる。マシンをクラスタに参加させるだけで、自動的にコンテンツと設定が同期化される。言い換えると、クラスタコントローラ上にあるのとまったく同じコンテンツのコピーを持つことになる。また、時刻や日付の設定も含め、クラスタコントローラと同じ設定データも取得することになる。この同期化は、次のような形態で行える。

• 1 回のみ --- マシンをクラスタに最初に参加させたときに同期化する
• オンデマンド --- 管理ツールのメニューオプションを利用して同期化する
• 自動 --- クラスタを利用している最中に一定の間隔で同期化する

クラスタコントローラがコンテンツと設定情報の唯一のソースである点に注意してほしい。つまり、複製は必ず一方向からしか行われない。したがって、クラスタメンバのどれか1つがクラスタコントローラ上にないファイルを持っている場合、もしくはもっと新しいものがある場合には、同期化した際に削除されるか置き換えられてしまう。クラスタに追加されたマシン上の既存の (おそらく無効な) コンテンツがほかのマシン上の適切なコンテンツを置き換えてしまわないようにするために、意図的にそういう仕様になっている。この方式の最も大きな効果は、1 つには必ずクラスタコントローラ上でコンテンツを追加したり編集しなければならなくなる点だ。クラスタの各マシンの個別のコンテンツではない。

また、Application Center は、クラスタコントローラ上のインターネットサービスマネージャで行った設定を、クラスタ中の全部のマシンに自動的に同期化するようにもなっている。ログや認証、ディレクトリのパーミッションなどの設定も同期化の対象となる。このように同期化することで、Web クラスタリングのような複数マシンの環境での作業を大幅に節約できる。

どういったものがいつ同期化されるのかは第 3 章で詳しく解説し、Application Center のクラスタにコンテンツを追加する考え方全般を紹介しよう。

簡単な COM+ アプリケーションの展開

一般に Web アプリケーションは、プレゼンテーションを作成したり、ビジネスルールをインプリメントするといった処理のために、ソフトウェアコンポーネントを利用する必要がある。したがって Web ファームには、普通の Web ページ用のスケーラビリティと歩調を合わせて、そういったコンポーネントをスケーラブルにサポートする機能が用意されていなければならない。Application Center は、COM+ アプリケーションをクラスタ中の全部のマシンに --- 後からクラスタに追加したマシンにも --- 自動的に配置するのにも利用できる。

COM+ コンポーネントだけでなく、ISAPI DLL といったファイルも配置できる。Microsoft 社の新しい .NET Framework では、ASP+ (つまり ASP.NET) アプリケーションの一部である新しい種類のコンポーネントファイルも対象とすることができる。Application Center は、通常のファイルだけでなく、COM+ アプリケーション設定や必要な任意のレジストリ設定、またほかのすべての周辺機器情報も複製するようになっている。

当然、これは HTML や ASP ページのようなコンテンツファイルを自動的に同期化するといった単純な処理ではなく、サービスやほかのアプリケーションを一時的にシャットダウンして正しく同期化させることになる。しかしながら、Application Center はほとんどのルーチン作業を行い、アプリケーションにとって本当の意味でのスケーラビリティをより簡単に提供できるようになっている。

また、Application Center を利用して COM+ アプリケーションクラスタ も作成できる。個別の負荷分散クラスタを提供するよう具体的に設計されている点が通常の Web クラスタと違い、コンポーネントを実行して、Web クラスタ内で動作させているページに結果を返すようになっている。1 つのマシンは、Web クラスタと COM+ アプリケーションクラスタのどちらかに所属させることができるが、同時に両方へ参加させることはできない (図 4 を参照)。

図 4: COM+ アプリケーションクラスタの展開

この機能のおかげで、Web ページの処理をバックエンドのコンポーネント処理から分離できるため、別のレベルのスケーラビリティが生み出されている。Web クラスタ中の任意のマシンは、必要なコンポーネントをアプリケーションクラスタ中の任意のマシンで実行できる。AC2K は、COM+ アプリケーションクラスタ中の各マシンの応答時間に関するデータを自動的に管理して、最適なパフォーマンスを提供できるマシンに新しいリクエストをリダイレクトするようになっている。

この方式は、極端に複雑なコンポーネントを利用しているような環境だと、必ずしもパフォーマンスが大幅に高まるとは限らないが (リクエストされているコンポーネントの種類にばらつきがあるため)、非常に役に立つソリューションを提供している。

一括モニタリング

スケーラブルな Web ファームの構築に必要な最後の条件は、本章の最初の方で述べたように、Web サイトや Web アプリケーションのパフォーマンスを簡単かつ正確に計測できることだ。AC2K では、各マシンのパフォーマンスデータ --- Web クラスタと COM+ アプリケーションの両方 --- を管理して、この機能を提供している。もっと端的に言えば、クラスタコントローラはこのデータを定期的に収集しており、クラスタ全体用のパフォーマンスデータセットとしてまとめている。この情報はすべてメインの AC2K 管理ツールからアクセスして表示できる (図 5 を参照)。

図 5: パフォーマンス データの表示

パフォーマンスのグラフはもちろん、Windows Performance Monitor ユーティリティと同じように、ウィンドウの右側には、各クラスタメンバの状態 --- オンラインかどうか、負荷がかかっているかどうか、同期ループ中でアイドリング状態かどうかなど --- も表示される。

また AC2K では、各マシンのイベントログの内容も表示できるようになっており、それらのエントリをまとめてクラスタ全体の表示に組み合わせることが可能だ。つまり、各マシンが定期的に書き出しているイベントログを順番にチェックする必要はない。

パフォーマンスのモニタリングとイベントログ中のエラーチェックのほかにも、AC2K のヘルスモニタ ツールを使うと、オンデマンドや指定したスケジュールで自動的に特定のテストを行うことができる。これらはモニタ と呼ばれており、これらのテスト結果はログに記録され、管理コンソールで表示させることができる (図 6 を参照)。

図 6: 自動的に行ったテストの結果

さらに、テストに失敗した場合には、自動的に管理者に電子メールやほかの種類のレポートを送信させることもできる。たとえば、図 7 に示した電子メールのメッセージは、クラスタ中の 1 つのサーバーにアクセスできなかった結果、自動的に送信されたものだ。

図 7: テストに失敗した場合のメッセージ

事前に定義されている多くのモニタが利用できるし、また自分で独自のものを作成できる。AC2K には Windows の WMI (Windows Management Instrumentation) 技術が統合されており、テストを実行して、サービスやサーバーの再起動などの自動「ヒーリング」も可能ならば行うようになっている。さらに優れている点として、必要なタスクを指示したとおりに行う独自のカスタムモニタも作成できる。

なお、モニタリングとパフォーマンスのログはサーバーのリソースを消耗するので、リクエストを処理するクラスタの性能が下がる点に注意してほしい。ただし、最大限のスケーラビリティが必要であれば、パフォーマンスのログ機能をオフにしてモニタを削除することも可能だ。

サードパーティ製の負荷分散ソリューション

すでにハードウェアベースの負荷分散ソリューションを導入していたり、これからインストールする予定である場合もあるだろう。そうした状況で、Application Center を利用する意義があるのだろうか ? 実際には、AC2K は、Windows NLB だけでなく、ハードウェアの負荷分散システムとも動作するよう設計されている (ただし当然のことながら、同時には利用できない)。負荷分散ソリューション機能を備えたハードウェアはさまざまな種類があるので、ここでは深く触れないが、どのようにインストールして管理するのかは自分の選んだソリューションに依存する。

しかしながら、AC2K は、サードパーティ製の負荷分散ソリューションを直接サポートする機能は備えていない。言い換えると、負荷分散を行うソフトウェアやハードウェアを、Windows 独自の NLB ソフトウェアを利用する場合と同じように自動的に設定することはできない。ただし、自分でサードパーティ製の負荷分散ソリューションを設定するのであれば、そういった製品とも AC2K は問題なく動作するようになっている。

ハードウェアで負荷分散を行う高度なパフォーマンスの高い例としては、Cisco Systems 社の CSS 11000 シリーズのスイッチがある。これは Web NS (Web Network Services) を利用しており、IP アドレスと SSL (Secure Sockets Layer) セッション ID とクッキーを基にして「スティッキー」接続をサポートした負荷分散ソリューションになっている。本書の後半で解説するが、スティッキーセッションがサポートできることは、多くの種類の Web アプリケーションで必須とされている。このスティッキーセッションをサポートしていないハードウェアベースの負荷分散ソリューションもあるが、その場合でも、うまく動作する Web アプリケーションが構築できる。

別の種類の負荷分散として、利用可能な全部のサーバーにリクエストを固定パターンで分散させる「ラウンドロビン」方式の技術を使ったものもある。これは (wrox.com などの) ホスト名に対応したIPアドレスのリストを管理している DNS サーバーで行うことができる。DNS ファイルに複数のエントリを追加する --- つまり、A (Address) レコードを複数記述する --- ことで、DNS サーバーはリクエストを順番に各マシンに分散できる。

もちろん、どの方法でもうまく動作するが、リクエストを分散するのに利用しているアルゴリズムが違っている。さらに、AC2K で自動的に負荷分散の管理 --- サーバーの追加・削除や、各マシンの負荷を調整するなどの処理 --- を行わせないようになっている。しかしながら、それでも AC2K は、コンテンツの複製・同期やパフォーマンスのモニタリング、またリモートでの中央管理用インターフェイスの提供といった、毎日のタスクの面倒はみてくれる。

これらの機能を利用するだけでも、サーバーファームの管理はずっと楽になる。また、各サーバーへの負荷が減るおかげで (Windows NLB が動作していないから)、同じ数のサーバーでパフォーマンスが高くなるのがよくわかるだろう。各プロセッサの負荷は少なくなるので、各サーバーはより多くのリクエストをサービスできることになるはずだ。

本当に実用的なのか

本章の後半では、普通のデスクトップマシンを使って構築したテスト用クラスタを紹介する。このテスト用クラスタで WAST (Microsoft Web Application Stress Tool) を使って、AC2K の基礎テストを行った結果を次に示しておこう。ターゲットは 1 つの ASP ページで、100 の階乗の値を計算して、途中の計算結果をすべて表示するようにしてある (返されたページの合計サイズは 3K バイト前後になる)。つまり、サーバーのおもな負荷は CPU という意味だ。Web ストレスツールを使って、まず最初に単一サーバーの最大性能を計測した。続いて、サーバーが 4 台のクラスタで徐々に 1 分間に送信されるリクエスト数を増やした。結果を以下に示す。

表 1: AC2K の基礎テストの結果

1 分間の合計リクエスト数	サーバー数	サーバーごとに送信された 1 分間のパケット数	全部のサーバーの平均データ送信レート (KB/秒)	サーバーごとの最大 CPU 負荷 (%) /クラスタ平均 (%)	最初のバイトの平均時間 (ミリ秒)	最後のバイトの平均時間 (ミリ秒)
1,295	1	11,875	86.61	100	12.5	228.0
1,205	4	2,750	81.93	40/20	9.75	67.5
1,960	4	4,350	184.23	55/35	8.0	86.7
2,750	4	5,360	255.40	80/45	10.8	139.5
3,230	4	6,790	219.66	90/65	28.5	259.5

最初のテストでは、CPU の利用率が 100% でピークに達していることがわかる。1 分間にほぼ 1,300 ページ処理するのが限界で、平均応答時間 (最後のバイトが到達した時間) は 228 ミリ秒となっている。2 行目からは、同じテストページを AC2K のクラスタ --- 4 台の同一マシン --- で動作させた際の結果だ。クラスタでもほぼ同じ数のリクエストを処理しているが、CPU の最大利用率はどのサーバーでも 40% でしかなく、クラスタ全体の平均 CPU 利用率はたったの 20% で、しかも応答時間が平均で 67.5 ミリ秒と劇的に速くなっている。図 8 に、これを AC2K の管理コンソールで表示した画面結果を示す。

図 8: テスト用クラスタの実行結果

応答時間が速くなることはわかったので、次の段階として、今度はリクエストの数を増やしてもっと負荷をかけてみる。その結果、どのサーバーの CPU 最大負荷も 55% 以上に高めないで、リクエストの数を 1,219 から 1,960 に増やすことができた。しかも、平均応答時間は単一サーバーの約 1/3 だった。

表の最後の 2 行は、リクエスト数を増やし続けた場合にどういったことが起こるかを示している。表の最後の行は、クラスタ中の 1 台のサーバーの CPU 利用率が 90% に達して、クラスタ全体の平均が 65% 前後であることを意味している。この時点で、クラスタでのパフォーマンスが限界に近づき始めたことがわかる。しかしながら、Web サイトのパフォーマンスが負荷分散でどのように改善されるのかも示している。4 台のサーバーを設置したからといって、実際の性能は 4 倍になっていないけれども (テストの場合には、負荷分散とモニタリングとログのオーバーヘッドが原因だ)、平均すると約 3 倍のパフォーマンスが得られている。

おそらくもっと重要なポイントは、クライアントが気がつく実際のサイトのパフォーマンスだろう。このテスト用の 4 台のサーバーのクラスタでは (表の下から 2 番目の行)、1 分間にリクエスト数を 2 倍以上も処理できている (1,295 から 2,750)。それと同時に応答時間が約半分になり (228ms から 139.5ms)、クラスタの CPU の平均負荷は 45 %以下に留まっている。

当然のことだが、この基本的なテストは、AC2K を使った Web サーバーのクラスタリングの潜在的な利点を単に示しただけにすぎない。現実の環境では、ページはそれほど CPU の処理を必要としないだろうし、結果も SCSI ハードディスクからブロードバンドネットワーク接続へと送り返すことになる。

 

Application Center の設定

これまで、実際に AC2K でどんなことが行えるのか簡単に紹介したので、以降では、AC2K のセットアップ方法について述べておこう。

最初のステップは、まず利用するマシンが AC2K と互換性があるかどうか確認することだ (もちろん、Windows 2000 にも対応していなければならない。ハードウェアの互換性リストに関しては https://www.microsoft.com/japan/hwdq/hcl/を参照してほしい)。その後に、AC2K ソフトウェアをインストールして、自分の選んだ負荷分散ソリューションを設定することになる。AC2K では、次の 3 種類の負荷分散をサポートしている。

• Windows ネットワーク負荷分散 (NLB) --- Windows 2000 Server や Workstation には用意されていない機能で、Windows 2000 Advanced Server と Datacenter Server に搭載されている。ただし、AC2K の配布キット CD-ROM にも収録されているので、Windows 2000 Server に AC2K をインストールすると自動的に組み込まれる。
• コンポーネント負荷分散 (CLB) --- Web アプリケーションで利用する COM コンポーネントをサーバーにインストールしておくと、Windows CLB 技術を使って、コンポーネントへのリクエストをクラスタ中のサーバーで分散処理させることが可能だ。つまり、コンポーネントを動作させるクラスタを個別に作成して、AC2K で管理したりモニタリングできる。
• サードパーティ製の負荷分散ソリューション --- (先に説明したように) すでに負荷分散ソリューションのハードウェアやソフトウェアを稼動させていても、それと併用して AC2K を動作させることが可能だ。ただし、その場合には、AC2K の中央管理機能とコンテンツ複製機能とモニタリング機能しか利用できない。

必要となるハードウェア

AC2K でクラスタのメンバにするマシンは、どれも同じ設計と構成になっていなければならない。言い換えると、同じ性能のディスクシステムを備えている必要があり、CPU も同じメーカー製のものでなければならない。また負荷を均等に分散させるには、可能であればパフォーマンスも同程度のものにしておくべきだ。さらに、オペレーティングシステムも全部のマシンで同じ設定にしておく必要がある。つまり、データファイルやサービスディレクトリ (Inetpub など) の位置、ユーザー名、パスワードもまったく同じに設定しておく。AC2K では各マシンのアプリケーションとデータを複製する点を忘れないでほしい。したがって、それぞれのマシンをほかと同じ設定にしておかなければならない。

マシンは最低でも Pentium 400MHz クラス以上のもので、256M バイト以上のメモリを搭載していなければならない。またディスク容量も、オペレーティングシステムと AC2K をインストールするのに、少なくとも 2G バイト以上必要となる。これに加えて、データファイルとアプリケーションファイル用のディスク容量も必要となる (ただし、AC2K そのものは 110M バイト前後しか必要としない)。なお、メモリ容量が多いほどパフォーマンスも当然高くなる点を忘れないでほしい。パフォーマンスの用語で言えば「コスト効率が高い」だ。

サポートしているオペレーティングシステムは、Windows 2000 Server、Advanced Server、Datacenter Server である。

また、Internet Information Server 5.0 をインストールして動作させておかなければならない。この IIS は Windows 2000 をインストールした際に既定で組み込まれる。必要に応じてほかの Web サーバーソフトウェアをインストールしてもかまわないが、やはり IIS 5.0 も利用できなければならない。一般的には、標準外のポートが利用されてしまう問題点を避けるために、IIS 5.0 だけを利用した方がよいだろう。なお、ドメインコントローラとして動作させているマシンに AC2K をインストールするべきではない 点に注意してほしい。

Windows ネットワーク負荷分散

AC2K で Windows ネットワーク負荷分散を利用する場合には (後で詳しく解説する)、Windows 2000 が対応しているネットワークカードを各マシンに最低 2 枚は搭載しておく必要がある。

古いネットワークカード (特に一部の ISA カード) だと、ソフトウェアでネットワークカード上の MAC アドレスを操作できないものもあり、クラスタの設定が難しくなってしまうので、できれば最近の PCI 型のネットワークカードを利用した方がよいだろう。

もちろん、マシンを物理的につなげるハブやケーブルといったネットワーク機器も必要となる。Windows NLB を利用するように AC2K を設定するのであれば、「外部」接続はクラスタをネットワークの残りとリンクする通常のハブとなる --- サーバーファーム用の負荷分散させた外部接続を形成する。そして、各マシンに搭載したもう 1 枚のネットワークカードはハートビートネットワークに接続して、クラスタのメンバ同士で AC2K 関連の情報をコミュニケーションするのに利用する (図 9 を参照)。

図 9: Windows NLB 利用するための AC2K の設定

サードパーティ製の負荷分散ソリューション

ハードウェアベースの負荷分散ソリューションの場合には、先に述べたように、特殊な負荷分散スイッチやルーターを使って各マシンを外部ネットワークと接続することになる。その場合には、ハートビートネットワーク用の 2 枚目のネットワークカードも、Windows NLB ソフトウェアも必要ない (図 10 を参照)。

図 10: ハードウェアベースの負荷分散ソリューション

しかしながら、AC2K 管理トラフィック用のバックエンドネットワーク、つまりハートビートネットワークを用意しておけば、クラスタのパフォーマンスを高めることができる。このハートビートネットワークは各マシンに 2 枚目のネットワークカードを装着し、適切なハブを使ってケーブル接続すれば構築できる (図 11 を参照)。

図 11: ハートビート ネットワークによる負荷分散ソリューション

安価なテスト用プラットフォーム

本書を執筆する際に、AC2K を利用して 4 台のサーバーでテスト用クラスタを作成した。それぞれのマシンは 500MHz の Intel Celeron チップをベースとした標準的なデスクトップシステムで、256M バイトのメモリと、10G バイトの IDE ディスクを搭載してある。全部のマシンに PCI 型のネットワークカードを 2 枚装着し、各マシンを接続するのには 10Mbps のハブを 2 つ利用した。クラスタを既存のテスト用イントラネットに接続するのに片方のハブのアップリンク接続を使い、別のリモートマシンからクラスタ全体を管理できるようにした。

このシステム全体にかかった費用は合計しても 4,000 US ドル以下で、AC2K を使って実験するのにそれほど出費をかける必要がないことを表している。もちろん、本格的に稼働させるのであれば、当然、もっと高速な CPU に置き換え、メモリも増やし、ワイド SCSI のディスクにするなど、システムの構成を選び直す必要がある。しかしながら、実験にはこのテスト用クラスタで十分で、開発システムとしても非常に役に立つ。

もう 1 つの方法として、Microsoft 社の AC2K 開発チームが行っているように、ラップトップマシンをクラスタリングさせることも可能だ。AC2K 開発チームでは、8 台のラップトップと 2 つのハブ、それに接続用の機材を全部まとめて小さな車輪付きのスーツケースに収めた「モバイルクラスタ」を用意している。これは、世界中のカンファレンスでデモンストレーションを行うためのものだ。

Application Center ソフトウェアのインストール

Application Center には総合的なインストールルーチンが用意されているので、インストールそのものは比較的簡単だが、実際のインストールを始める前に、サーバー側の設定を少し準備しておかなければならない。つまり、AC2K をインストールするサーバーには Windows 2000 Service Pack 1 (SP1) を組み込んでおく必要があり、また「Pre-Service Pack 2」と呼ばれる「修正版」もいくつか必要となる (または、Service Pack 2)。これらを AC2K のインストール前に組み込んでおかなければならない。ただし、どれも AC2K の配布キットCD-ROMに収録されているので、セットアッププログラムから簡単に選んでインストールできる。SP1 と追加修整版のインストールに失敗してしまった場合には、AC2K そのもののインストールもうまく行えない点に注意してほしい。

またインストールを始める前に、いわゆる「readme」ファイルをよく読んでおいた方がよい。AC2K の場合だと、配布キット CD-ROM のルートディレクトリに readme.htm という名前のファイルが保存されている。また、AC2K のインストール処理をすべて自動的に実行することも可能だ。readme.htm ファイルには、利用可能なオプションやコマンドラインのスイッチに関して詳しく記述されている。

なお、セットアップに関して問題点が1つ判明しており、Windows 2000 のセキュリティカタログが壊れてしまう場合がある。「デジタル署名が見つかりませんでした」というエラーメッセージが表示されてセットアップが失敗した場合には、コンピュータを再起動し、問題を修復するために AC2K を最初からインストールし直さなければならない点に注意してほしい。

セットアップの実行

セットアッププログラムを実行すると、セットアップを開始するリンクのほかに、ヘルプファイルやリリースノートを表示するオプションが示された画面が表示される (図 12 を参照)。

図 12: セットアップ画面

図 12 のダイアログはHTA (Internet Explorer Hypertext Application) になっている。この画面が AC2K 配布キット CD-ROM をドライブに入れても表示されない場合には、AC2K CD のルートディレクトリにある setup.hta ファイルをダブルクリックすればよい。

オープニングのダイアログに表示されている「setup」のリンク (Microsoft Application Center 2000 のインストール) をクリックすると、配布キット CD-ROM から必須コンポーネントをインストールするための別のダイアログが表示される (図 13 を参照)。このダイアログに表示される順番にインストールを実行しなければならない。ステップ 1 とステップ 2 の終了時に、サーバーは自動的に再起動して、メインのセットアップ画面がもう一度表示されるはずだ。表示されない場合には、AC2K 配布キット CD-ROM (もしくは挿入しているメディア) のルートディレクトリに移動して、setup.hta ファイルをダブルクリックしてから「 Microsoft Application Center 2000 のインストール」をクリックすれば、いまのインストール処理を続けることができる。

図 13: AC2K のインストール画面

3 番目のステップ 3 のオプションが実際の Application Center の設定だ。設定処理をガイドしてくれるウィザードが起動される。最初のステージはウェルカムページで、続いて利用許諾が表示されてから、自分の名前と会社名を入力する画面が表示される。その次のページには、どのコンポーネントをインストールするか 2 つのオプションが表示される (図 14 を参照)。

図 14: セットアップ タイプの選択

普通は [標準] オプションボタンをクリックして、AC2K の全部のコンポーネントとファイルをインストールすればよいが、インストールするコンポーネントを自分で選択する場合は [カスタム] オプションボタンをクリックする。[カスタム] オプションボタンをクリックした場合には、ヘルスモニタのサンプルを省略するか、もしくは AC2K クライアントだけをインストールして、そのマシンをリモートクラスタの管理に使うこともできる (図 15 を参照)。

図 15: カスタム セットアップ画面

後は、次のページの [インストール] ボタンをクリックしてファイルのコピーを開始すれば、Application Center のインストールは完了だ (図 16 を参照)。

図 16: AC2K インストール中の画面

インストール処理がすべて終わると、[管理ツール] メニューに [Application Center] と [ヘルスモニタ] の 2 つの項目が新しく追加される (図 17 を参照)。

図 17: AC2K インストール後に追加された項目

ネットワーク接続の設定

ここでのテスト用クラスタでは、NLB (Windowsネットワーク負荷分散) を利用した。別の負荷分散ソリューション (ハードウェアかソフトウェア) をインストールしていないのであれば、Windows NLB で始めてみるのが最も簡単な方法だろう。

クラスタを作成したり修正する際に、AC2K が Windows NLB の設定を (ある程度) 面倒見てくれるが、少なくとも AC2K で Windows NLB を利用できるように、いくつか設定しておかなければならない。これは比較的簡単だ。Windows 2000 Advanced Server と Datacenter Server には、既定でネットワーク負荷分散機能が組み込まれている。Windows 2000 Server で AC2K を動作させる場合には、NLB コンポーネントを AC2K 配布キット CD-ROM からインストールしておかなければならない。これは AC2K のメインのセットアップルーチンの一部として自動的に行われる。

NLB をインストールしたら、オプションの「バインド可能」なコンポーネントとして、各ネットワーク接続で自動的に利用できるようになる。つまり、自分のシステムに搭載したネットワークカードの 1 つに NLB をバインドできるという意味だ。これがどのように動作するのかは、もう少し後で見てみよう。

Windows NLB の設定オプション

Windows NLB を使ってクラスタを作成できるように AC2K 用のネットワーク接続を準備するには、実質的には 3 とおりの方法がある。

• 最小 --- クラスタのメンバとするマシン用の適切な IP アドレスなどの設定を AC2K で自動的に割り当てさせる。パブリックな IP アドレスを 1 つだけ指定して、その IP アドレスでクライアントがクラスタにリクエストを送信できるようにする。
• 固有 --- 自分で全体のネットワークトポロジを設計して、クラスタを構築する前に各マシンで使う IP アドレスを設定する (この方法を以下で解説する)。
• フル --- ネットワーク接続のすべての情報を自分で設定する。NLB の設定も自分で行うことになるので、AC2K が適用する既定の設定を利用できない場合にしか便利ではない。おそらく、利用しているネットワークカードがユニキャストモードをサポートしていない古い設計のような場合だろう。

サードパーティ製の負荷分散設定

サードパーティ製の負荷分散ソリューションを利用している場合には、クラスタリングさせる各マシン用にパブリックな IP アドレスを 1 つ指定しておけばよい。それぞれの IP アドレスが、自分の選択したルーター (もしくはハードウェア/ソフトウェアベースのソリューション) の負荷分散パラメータを設定するのに使われる。

自分のマシンにネットワークカードを2枚利用しているのであれば、バックエンドのハートビートネットワーク用に固定のIPアドレスを指定することもできる。もしくは、クラスタを作成して管理する際に、AC2K の自動設定機能がこれらを適切な値に設定してくれる。

ネットワーク トポロジの計画

クラスタのネットワーク設定を最も細かく制御したい場合は、関連した全部の IP アドレスを直接指定するよう選ぶことになる。特に、クラスタをサポートした Web サイトにクライアントがアクセスするための HTTP ではなく、ローカルのドメインの一部としてほかのマシンに接続する必要がある場合には便利だ。具体的に言うと、専用の IP アドレスをクラスタメンバの各マシンに指定でき、どれも個別にアクセスできるようになる。

Windows NLB を利用した Application Center では、各マシンにネットワークカードが最低でも 2 枚必要で、負荷分散クラスタの一部として設定しておく。

• 1 枚は、各マシンをリンクしたバックエンドのハートビートネットワークを構築するのに利用する
• もう 1 枚は、外部の世界とのフロントエンドのパブリック接続用に利用する

NLB は、各マシンで一度に 1 つのネットワークカードにしかバインドできない。もう 1 つのネットワークカードにバインドしようとすると、先のバインドが自動的に解除される。したがって、分散負荷の利点を活かすには、NLB をインストールして、パブリック接続用のネットワークカードにだけ設定しておかなければならない。

AC2K では、パブリック接続用のネットワークカードに静的 IP アドレスを少なくとも1つはバインドしておくよう推奨している。だが、ハートビート用ネットワークカードの IP アドレスは自動的に設定でき、2 つのネットワークが独立したサブネット となるよう保証できる (別のいい方をすれば、どちらも互換性のない IP アドレスを持つことになる)。

このようにしておかないと、サーバーの生成した応答が間違ったネットワーク接続に送り出されてしまう可能性がある。また、同じサブネットのアドレスを利用していると、クラスタを作成したり管理する際に面倒な結果になってしまうので注意してほしい。

ここでのテスト用クラスタでは、ハートビートネットワークの範囲として、192.168.0.x のプライベート IP アドレスを利用した。また、内部のイントラネットに接続しているので、パブリックネットワーク接続に使う IP アドレスをイントラネットのネットワーク範囲から選び、10.0.0.x. にした。当然、実際の環境では、自分のネットワーク環境用のパブリックなIPアドレスの範囲からアドレスを選ばなければならない。

パブリック接続の場合、クラスタ全体に対して、つまり全部のマシンに共通した IP アドレスを 1 つ割り当てておく必要がある。ここでは 10.0.0.105 を利用した。また、クラスタ中の各マシンに対して専用の IP アドレスを個別に指定することも可能だ。図 18 に、テスト環境で利用したネットワークトポロジのダイアグラムを示しておこう。

図 18: ネットワーク トポロジのダイアグラム

ハートビート ネットワーク接続の設定

それぞれのハートビート接続に、スタティックな固定 IP アドレスを指定したいと仮定しよう。[ネットワークとダイヤルアップ接続] フォルダを開き、各マシン上の適切な接続のプロパティダイアログで [インターネットプロトコル (TCP/IP)] のエントリをダブルクリックする。

図 19 のようなダイアログが表示されるはずだ。[次の IP アドレスを使う] オプションボタンをクリックして、目的の IP アドレスとサブネットマスクの値を入力する。

図 19: インターネット プロトコル (TCP/IP) のプロパティ

各マシンにネットワークカードを2枚搭載して、サードパーティ製の負荷分散ソリューションを利用している場合には、いま述べたのと同じ方法でバックエンド用のネットワークカードを設定できる。AC2K が生成した管理トラフィック用に利用可能となる。

DNS サーバーのアドレスは空のままにしておいてかまわない。ハートビートネットワークには DNS が必要ないからだ --- Application Center は、hosts と呼ばれるファイルを利用して、各マシンのバックエンドハートビート用ネットワークカードの場所を見つけ出すようになっている。このファイルは %WINNT%\system32\drivers\etc\hosts にあり、クラスタ中の各マシンのエントリを記述しておかなければならない。ただし、クラスタを作成して管理する際に AC2K が自動的に登録してくるので、自分で編集する必要はないが、通信エラーが発生した場合には、このファイルをチェックして問題を調べるとよいだろう。たとえば、テスト用の4台のサーバーは、このファイルに次のように記述されている。

127.0.0.1 localhost
192.168.0.1 MSAC01
192.168.0.1 MSAC01.ourdomain.com
192.168.0.2 MSAC02
192.168.0.2 MSAC02.ourdomain.com
192.168.0.3 MSAC03
192.168.0.3 MSAC03.ourdomain.com
192.168.0.4 MSAC04
192.168.0.4 MSAC04.ourdomain.com

localhost のエントリ (必須) と、さらに FQDN (Fully Qualified Domain Name：完全修飾ドメイン名) 形式で各マシンのハートビート接続アドレスのエントリも記述されている点に注意してほしい。

パブリック ネットワーク接続の設定

さて、いまと同じ処理をパブリック用の各ネットワークカードに対して繰り返す。ただし今回は、個別のサーバーが応答する専用の IP アドレスを適切なサブネットマスクと一緒に入力しなければならない。このサンプルでは、最初のサーバーの IP アドレスを 10.0.0.101 に、サブネットマスクを 255.0.0.0 に設定した。

また、ネットワークのデフォルトゲートウェイ も指定する必要がある。普通は、外部のネットワークと接続しているルーターのアドレスを指定する。このアダプタはパブリックな外部ネットワークとのインターフェイスなので、適切な DNS サーバーの IP アドレスを指定しておけば、クラスタが動作中に DNS を参照できるようになる (図 20 を参照)。

図 20: DNS サーバーの IP アドレスの指定

現時点では、このアダプタでNLBが利用できるようにはなっていない。まだクラスタを作成していないからだ。このマシン用のクラスタを作成したり修正する段階で、AC2K は NLB を有効にして、適切な設定を適宜行ってくれる。

各マシンにネットワークカードを 1 枚か 2 枚搭載してサードパーティ製の負荷分散ソリューションを利用している場合には、同じやり方でフロントエンド用のネットワークカードを設定しておく必要がある。設定しておかなければならないのはそれだけだ。そのほかの設定は、自分の選んだ特定のソリューションに依存する。

また、コマンドプロンプトウィンドウで ipconfig ユーティリティを使えば、接続の設定をいつでも自分で確認できる (図 21 を参照)。いちいちネットワークの[プロパティ]ダイアログボックスを全部開いて確認するよりもずっと便利だろう。

図 21: ipconfig ユーティリティの使用

Windows NLB 用に共通したパブリック IP アドレスの設定

Windows NLB を利用している場合には、もう 1 つ設定ステップがある。クラスタのコントローラとなるマシン (つまり最初にクラスタを作成するマシン) に、共通のパブリック IP アドレスを指定しておかなければならない。まずプロパティダイアログボックスの [詳細設定] ボタンをクリックして、[TCP/IP 詳細設定] ダイアログボックスを表示する。続いて [IP 設定] タブで [追加] ボタンをクリックして、クラスタ用の共通IPアドレスを入力する (図 22 に示すサンプルには 10.0.0.105 と入力している)。]

図 22: クラスタ用の IP アドレスの入力

先に述べたように、別のサブネット上に位置する各マシンにネットワークカードを 2 枚搭載して、パケットが正しくルーティングされるよう保証するのが1番確実だ。両方のネットワークカードに同じサブネットを利用するのであれば、[詳細設定]ボタンをクリックして [TCP/IP詳細設定] ダイアログボックスを開き (図 22 を参照)、[インターフェイスメトリック] テキストボックスに値を設定しておく。フロントエンドのパブリック接続には 2 を、バックエンドのハートビート接続には 1 を設定しておけばよい。

この共通 IP アドレスをほかのマシンに追加してはならない。マシンをクラスタに追加する際に、AC2K が自動的に設定してくれる。

1 つ以上の個別のクラスタがある場合には、ハートビートネットワークが物理的に分かれている限りは (そうでなければならないのだが)、ほかのクラスタに対しても同じ IP アドレスを再利用できる。ネットワークの設定を行った後で各マシンを再起動して、適切に適用されているかどうか確認する。

ネットワーク設定の自動化

先に述べたように、クラスタを作成して管理する際に、AC2K がマシンのネットワーク設定を調整してくれる。ほんの少し自分で調整しなければならない部分もあるが、基本的には、実際に自分で設定しなければならないのは、クラスタコントローラのネットワークカードの 1 つにスタティックな IP アドレス --- 自分のドメインのパブリックな IP アドレス --- を 1 つ割り当てることだけだ。そうしておけば、ほかに必要な静的 IP アドレスを AC2K がすべて割り当て、hosts ファイルを更新して、ほかにも設定しなければならない情報があればすべて設定してくれる。

この場合、バックエンドのハートビート接続には何も設定する必要がない。[IP アドレスを自動的に取得する] オプションボタンをオンにしておくだけで、DNS サーバーのアドレスは指定しないでおく。AC2K がクラスタを作成して修正する際に、自動的にハートビートのアドレスを指定して (ローカルマシンの hosts ファイルに記録して) 管理してくれる。

以上で終わりだ。後はクラスタを作成するだけである。このテスト用クラスタでは、クラスタを作成してメンバに追加すると、AC2K が自動的に 169.254.x.x の範囲から IP アドレスをハートビートのアダプタに割り当ててくれる。

ここで、現在 Microsoft 社のホームページで公開している Application Center 2000 のネットワーク負荷分散 (NLB) を使用する場合の推奨構成について説明する。

Application Center 2000 でのプライベート アダプタに対する推奨設定

1. [スタート]ボタンをクリックし、[設定] をポイントする。次に、[コントロールパネル] をポイントし、[ネットワークとダイヤルアップ接続] をダブルクリックする。
2. [詳細設定] メニューで、[詳細設定] をクリックする。
3. [接続] ボックスで、バインドが次の順序になっていることを確認して、[OK] をクリックする。 管理トラフィックアダプタ (管理トラフィックネットワーク) に対応するネットワーク接続 負荷分散アダプタに対応するネットワーク接続 [リモートアクセス接続]
4. 負荷分散アダプタに対応するネットワーク接続を右クリックして、[プロパティ]をクリックする。

この接続名は、簡単なもの (たとえば「フロントエンド」など) に変更することができる。

1. [インターネットプロトコル (TCP/IP)] をクリックして、[プロパティ] をクリックする。
2. [全般] タブで、静的 IP アドレスが選択されていて、その IP アドレスがもう一方の管理トラフィックアダプタと同じサブネットやネットワーク上にないことを確認する。負荷分散アダプタは、管理トラフィックアダプタとは異なるサブネットになければならない。 管理トラフィックアダプタと負荷分散アダプタが同一サブネットに存在する場合、受信接続 (Active Server Pages (ASP) ページへのリクエストなど) は負荷分散アダプタで受信され、送信接続 (ASP ページへのリクエストのレスポンス) が管理トラフィックアダプタから送信される可能性がある。
3. ネットワークの信頼性を向上させるには、[デフォルトゲートウェイ] ボックスに、値を設定する。

負荷分散アダプタと管理トラフィックアダプタが同一のサブネットに存在する場合、デフォルトゲートウェイを使用してネットワークトラフィックを分離する。

1. [詳細設定] をクリックする。
2. クラスタコントローラに設定する場合には、[IP 設定]タブで、IP アドレスが 2 つ (仮想 IP アドレス (VIP) 用の静的IP アドレスと、マシン固有の IP アドレス) 設定されていることを確認する。
3. [WINS] タブで、[NetBIOS over TCP/IP を無効にする] をクリックする。
4. ダイアログボックスを閉じるときに、次のプロンプトが表示される場合がある。このプロンプトが表示されたら、[はい] をクリックする。

この接続のプライマリ アドレスが空です。続行しますか ?

1. メディア検出の TCP/IP スタック破棄機能を無効にする。 各ノードに次のレジストリ値を追加する。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
値の名前 :	DisableDHCPMediaSense
データ型 :	REG_DWORD
データ :	1

1. 前述の手順をクラスタ内のほかのすべてのノードに対して行う。
2. Application Center のクラスタを作成する。

NLB の各種の設定

通常、NLB の接続プロパティを自分で管理する必要はない。ただし、AC2K が自動的に NLB を設定してくれるが、設定を自分でチェックしたり、手動で更新しなければならない場合のために、実際にはどういった処理が行われているのか理解しておくことは大切だ。たとえば、ユニキャストモードをサポートしていない旧式のネットワークカードを利用する場合など (すぐ後で解説する)、プロセス全体をもっと細かく制御したい場合は、自分で設定することもできる。

NLB を利用している場合 (つまりクラスタを作成した後)、パブリック接続のプロパティダイアログボックスで [ネットワーク負荷分散] のチェックボックスをオンにしておく。NLB は、マシンに搭載した複数のネットワークカードのどれか 1 つにしか一度にはバインドできない点を忘れないよう注意してほしい。図 23 に示す [NLB 接続のプロパティ] ダイアログボックスで、[ネットワーク負荷分散] のエントリを選択し、[プロパティ] ボタンをクリックすると、[ネットワーク負荷分散のプロパティ] ダイアログボックスが表示される。

図 23: NLB 接続のプロパティ

[ クラスタ パラメータ ] タブ

クラスタのパブリックアドレスと適切なサブネットマスクは、[ネットワーク負荷分散のプロパティ] ダイアログボックスの[クラスタパラメータ]タブで指定できる。図 24 から、このサンプルのパブリック IP アドレスは10.0.0.105 で、このマシンのインターネット用フルネームは「Cluster」という単語が付いたマシン名であるのがわかるだろう。

図 24: クラスタ パラメータの詳細

[マルチキャスト サポート] チェックボックスがオンになっている点に注意してほしい。AC2K で正しく動作させるには、一部のネットワークカードだとこのオプションを設定しておかなければならないこともあるので、その場合には、後からこのタグを表示させて有効にしなければならない。クラスタを追加した際に、AC2K が生成した共通アドレスでデフォルトの MAC アドレスを書き換えられないネットワークカードの場合であればこの操作をしなければならない。

現在のほとんどのネットワークカードは、起動時にカード上の ROM から MAC アドレスを読み込んで揮発性 RAM に記録するため、ソフトウェアで書き換えられるようになっている。ROM から常時読み込むようになった単純なカードの場合には、AC2K で利用するには [マルチキャストサポート] を有効にしておく必要がある。

[ ホスト パラメータ ] タブ

クラスタを構成する各マシンは、ネットワーク上のそのマシンを一意に識別するための専用の IP アドレスを持つ。この値は、いまと同じダイアログボックスの[ホストパラメータ]タブで確認できる。4 台のテスト用クラスタには 10.0.0.101 ～10.0.0.104 の IP アドレスを利用した。最初のマシンの設定を 図 25 に示しておこう。]

図 25: ホスト パラメータの詳細

また [優先順位 (一意のホスト ID)] 設定の値にも、クラスタ中の各マシンで一意になるように 1～32 の番号が割り当てられているのがわかるだろう。クラスタの設定を変更すると、この値も AC2K が調整してくれる。

クラスタを作成した際に、AC2K で自動的にネットワーク接続のプロパティを設定させるようにした場合、専用の IP アドレスには 0.0.0.0 が設定されるため、ネットワーク上のほかのマシンは、このマシンに直接アクセスできなくなる。つまり、共通の「パブリック IP アドレス」を介さないとアクセスできない。しかしながら、クラスタを作成する前にフロントエンド接続用の IP アドレスを 2 つ指定しておくと、AC2K は自動的にそのアドレスを専用 IP アドレスとして設定してくれる。

[ ポートの規則 ] タブ

[ネットワーク負荷分散のプロパティ] ダイアログボックスの3番目のタブには、クラスタ中のこのマシンの負荷分散設定が表示される (図 26 を参照)。[フィルタのモード] の設定には [アフィニティ] と [負荷配分] の 2 つの設定値がある点に注意してほしい。この 2 つは、クラスタから受信したリクエストをどのようにルーティングするのか制御するための方法だ。ただし、どちらも AC2K ですべて管理されるので、この設定は変更しない方がよいだろう。これについて詳しくは次章で解説する。

図 26: クラスタ中の負荷分散の設定

 

まとめ

Application Center (AC2K) は、Web ファームを利用したスケーラブルな Web サイトや Web アプリケーションを構築する際に出会う、5 種類の問題点を解決することを目的としている。そのための機能として、本章では以下の点に関して述べた。

• 複数のサーバーでスケールアウトさせた、インプリメントの簡単なスケーラビリティ
• 負荷共有と自動フェールオーバーによる高度な利用性の自動化
• クラスタ同士の自動的なコンテンツ同期とマシン設定
• Windows 2000 COM+ アプリケーションとコンポーネントの簡単な展開
• 個別マシンやクラスタ全体の一括モニタリング

本章では、まず最初に「スケーラビリティ」と「信頼性」が正確にはどういったことを意味するのか述べてから、これらの機能を実現するのに AC2K がどのように役立つのか紹介した。また、AC2K の仕組みと、AC2K を使うことで管理者の仕事がどのように簡素化されるのかも解説した。さらに、AC2K を利用するようにサーバーを設定する方法と、実際の AC2K の設定手順に関して説明した。

本章の解説で読者の環境にも Application Center がインストールできたと思うので、次章では、Web クラスタの作成方法と管理方法について詳しく述べることにしよう。