JP2003500742A - 作業グループサーバー実施の方法と装置 - Google Patents

Abstract

(57)【要約】 【解決手段】 ウェブ基イントラネット、エクストラネットおよびインターネットアプリケーションのために作業グループサーバーアレーの思想を実施する方法と装置である。該作業グループサーバーアレーは複数のチーム／作業グループコンピューター４０８を有しており、これにはグループ基直接アクセスサーバーおよびモジュラー制御装置１が装備されていて、作業グループ基故障許容およびフェイルオーバー機能が構成され、制御基モニターと管理サポートを提供し、高利用スケール可能ウェブ基アプリケーションを最適の挙動で提供する。作業グループサーバーアレーは基本ビルディングブロックとして使用できて、大型サーバークラスターを構成し、より多くのユーザーが同時にサービスされるようになる。作業グループサーバーアレー基構造が構成されて、種々の高利用スケール可能および使命臨界サーバーを構築する。これによりエネリス（ｅｎｅｒｒｉｓ）基イントラネット、エクストラネットおよびインターネットミッション臨界アプリケーションのための分配式計算サービスが可能となる。

Description

【発明の詳細な説明】

【０００１】 （発明の背景） （関連出願） この出願は、２０００年４月１１に特許されて現在は特許第６，０４９，８２
３号である「Ａ ＭＵＬＴＩ ＳＥＲＶＥＲ， ＩＮＴＥＲＡＣＴＩＶＥ， Ｖ
ＩＤＥＯ−ＯＮ−ＤＥＭＡＮＤ ＴＥＬＥＶＩＳＩＯＮ ＳＹＳＴＥＭ ＵＴＩ
ＬＩＺＩＮＧ Ａ ＤＩＲＥＣＴ−ＡＣＣＥＳＳ−ＯＮ−ＤＥＭＡＮＤ ＷＯＲ
ＫＧＲＯＵＰ ＳＥＶＥＲ（ダイレクト−アクセス−オン−デマンド・作業グル
ープサーバーを使用するマルチ・サーバー、インタラクティブ、ビデオ−オン−
デマンド・テレビジョン・システム）」と題された１９９６年１１月１日出願の
特許出願番号を第０８／７４２，７４１号とする特許出願の部分継続出願である
１９９９年５月２０日出願の暫定特許出願第６０／１３５，３１８号からの優先
権主張に基づく出願である。

【０００２】 （発明の分野） 本発明は、概してサーバークラスターに関し、より詳細に述べれば、スケーラ
ビリティのあるウェブ−ベースのイントラネット、エクストラネット、ならびに
インターネットのミッション・クリティカルなアプリケーションに適応する各種
サーバークラスターを構築するための作業グループサーバーアレーおよびそのア
ーキテクチャを実施する方法ならびに装置に関する。

【０００３】 発明性のサーバー・アレーは、本出願人による「ＤＩＲＥＣＴ−ＡＣＣＥＳＳ
ＴＥＡＭ／ＷＯＲＫＧＲＯＵＰ ＳＥＲＶＥＲ ＳＨＡＲＥＤ ＢＹ ＴＥＡ
Ｍ／ＷＯＲＫＧＲＯＵＰＥＤ ＣＯＭＰＵＴＥＲＳ ＷＩＴＨＯＵＴ ＵＳＩＮ
Ｇ Ａ ＮＥＴＷＯＲＫ ＯＰＥＲＡＴＩＮＧ ＳＹＳＴＥＭ（ネットワーク・
オペレーティング・システムを使用しないチーム／作業グループ化されたコンピ
ュータによって共有されるダイレクト−アクセス・チーム／作業グループサーバ
ー）」と題された特許第５，８０２，３９１に記述のあるような作業グループ−
ベースのダイレクト−アクセス・サーバーおよびコントロール装置を備えたチー
ム／作業グループコンピューターを包含する。さらに、この発明性のサーバー・
アレーは、作業グループ−サーバー−アレー−ベースのアーキテクチャを生み出
し、それを使用して各種の高いアベイラビリティならびにスケーラビリティを有
するミッション−クリティカルなサーバークラスターを構成することができる。

【０００４】 革新的なインターネット・テクノロジの爆発は、アプリケーションの記述なら
びに開発の方法に大きな影響を与えている。過去において一旦は静的な「ブロー
シャ・ウエア」であった数十万のインターネット・ウェブ・サイトも、トランザ
クション・ケイパビリティを伴った高度にインタラクティブなインターネットア
プリケーションに迅速に移行しつつある。大会社の内部では、開発者がエンター
プライズ・アプリケーションを大規模イントラネットに統合するためにウェブ・
テクノロジを使用している。会社間においては、ビジネス・パートナーが安全な
エクストラネットを構築して供給チェーンのストリームライニングおよび通信を
向上させている。

【０００５】 ウェブ−ベースのアプリケーションがインターネットおよびエンタープライズ
・イントラネットならびにエクストラネット上に広がるに従って、それらが行う
機能がますますミッション・クリティカルなものになって来ている。さらに、ビ
ジネスはミッション・クリティカルなタスクへのウェブ・ベースのテクノロジの
適用を続けていることから、そのアプリケーションに高度のアベイラビリティな
らびにスケーラビリティを持たせるために洗練されたアプローチを必要としてい
る。

【０００６】 高いスケーラビリティならびにアベイラビリティを達成するためのトレンドは
、多くの協働するサーバー、つまりエンド・ユーザの要求するアプリケーション
を届けるためのサーバークラスターを包含したシステムに向かっている。さらに
、大規模ウェブ−ベースのサービスにも、アベイラビリティ、スケーラビリティ
、信頼性、パフォーマンス、マネジメント、およびセキュリティ問題への適応を
可能にするためサーバークラスターを構築するアーキテクチャが必要とされてい
る。

【０００７】 しかしながら、複数の個別のサーバーを使用することによって高いスケーラビ
リティ、高いアベイラビリティおよびミッション・クリティカルなウェブ−アプ
リケーション−ベースのサーバークラスターを構築するために使用可能な現在の
テクノロジは、シングル−サーバー−ベースの３階層アーキテクチャ、つまりこ
れ以降においてＳＳ−３アーキテクチャと呼ぶアーキテクチャを生み出す傾向に
ある。このＳＳ−３アーキテクチャは、概して第１階層コンポーネント、すなわ
ち負荷バランサ；第２階層コンポーネント、すなわちアプリケーション・サーバ
ー；および、第３階層コンポーネント、すなわちデータベースサーバーおよびフ
ァイル・サーバーを必要とする。各個別のサーバーは、ＰＣベース、スーパー−
マイクロ−ベース、あるいはミニ−コンピュータ−ベースとすることが可能であ
り、ＷｉｎＮＴ（ウインドウズＮＴ）、Ｓｏｌａｒｉｓ（ソラリス）、Ｌｉｎｕ
ｘ（リナックス）およびＵｎｉｘ（ユニックス）等のオペレーティング・システ
ムを使用する並行処理能力を伴う複数のＣＰＵからなる。

【０００８】 このように、ＳＳ−３アーキテクチャに基づいて、ウェブ−ベースのアプリケ
ーションのためのアベイラビリティならびにスケーラビリティの高いサーバーク
ラスターを構築することは可能である。しかしながら、これらのアーキテクチャ
は、同時に次に示す不利益をもたらす。

【０００９】 １． 階層化されたそれぞれのコンポーネントに関連する問題 ａ） 負荷バランサ：すべての到来トラフィックを解析し、ウェブ−ベースの
個別の各クエリ／要求を、アタッチされている有効な第２階層のアプリケーショ
ン・サーバーの１つにリダイレクトする。負荷バランサは、要求の特性および負
荷バランスされたウェブ・アプリケーション・サーバーのアベイラビリティなら
びにスケーラビリティに基づいて、第２階層にある特定のウェブ−ベースのアプ
リケーション・サーバーに要求を分配する。この負荷バランサには、３つの基本
的なタイプがある：すなわち、スイッチ、ソフトウエア・バランサ、およびアプ
ライアンス・バランサである。しかしながら、上記の負荷バランサのいずれも、
ストレスが大きくなるとインターネット接続が遅滞させる可能性を有する。 ｂ） アプリケーション・サーバー：第１階層の負荷バランサから割り当てを
受け、ウェブ−ベースのアプリケーションを実行し、アプリケーション指向デー
タ検索のために第３階層のデータベースサーバーおよびファイル・サーバーとイ
ンターフェイスする。しかしながら、異なるハードウエアならびにソフトウエア
構成に基づく各アプリケーション・サーバーが互いに異なる可能性は否定できず
、負荷バランサのマネジメントの複雑化をもたらしている。それに加えて、各ア
プリケーション・サーバーがロイヤルティ−ベースおよび非ロイヤルティ−ベー
スのクエリをともに扱うため、セキュリティ基準のレベルが異なるコヒーレント
でないプログラム・グループが作られることになる。さらにまた、ネットワーク
−アクセス−ベースのセカンダリ・プロセッサーを含むときに限り、サーバーの
プライマリ・プロセッサーに故障した場合に、このセカンダリ・プロセッサーが
別のネットワーク−ベースのマネジメント・サーバーによってアクセスされ、ト
リガされてプライマリ・プロセッサーをリブートできるようになっていることを
別にすれば、各アプリケーション・サーバーにリモート・ブート能力が備わって
いない。 ｃ） データベース／ファイル・サーバー：クライアントと見なされる第２階
層にあるすべてのアプリケーション・サーバーからのデータベース／ファイル・
クエリを処理するクライアント−サーバー−ベースのサーバーである。ロイヤル
ティ−ベースのトラフィックと非ロイヤルティ−ベースのトラフィックの間の区
別がまったくないことから、ロイヤルティ−ベースならびに非ロイヤルティ−ベ
ースのアプリケーション指向データがすべて１つの中央ファイル・サーバーにス
トアされ、同時発生のクエリが増大したときの潜在的なデータベース／ファイル
検索のボトルネックをもたらしている。さらに、これらのファイル・サーバーな
らびにデータベースサーバーが、複数のＳＡＮ（ストレージ・エリア・ネットワ
ーク）によりイネーブルされるストレージ・デバイスにリンクされる複数の分散
型データベースサーバーおよびファイル・サーバーを含むデータ・センタとして
実施された場合には、その種のデータ・センタをマネージするための複雑性が高
くなる。これは、クライアント中心型サーバーならびにサーバー中心型サーバー
のいずれにおいても複雑なデータベース・ソフトウエア・プログラムが必要にな
るという事実による。しかしながら、アプリケーション指向データとビジネスに
敏感なデータを１つのデータ・センタにひとまとめにすることは、ファイアウォ
ールのフィルタリングといった過剰のセキュリティ基準を呈示して、ウェブ−ベ
ースのブラウジング・アクティビティによる破壊行為の潜在的なリスクから保護
する必要を生じるため、理想的であるとは言えない。

【００１０】 ｄ） 階層間通信スイッチ：第１階層の負荷バランサと第２階層のアプリケー
ション・サーバーの間、およびアプリケーション・サーバーと第３階層のファイ
ル・サーバーならびにデータベースサーバーの間において必要になる。すべての
コンポーネントがネットワーク−ベースであることから、サーバー間の通信はこ
れらの２つのスイッチを通じて処理され、不必要な階層間トラフィックのボトル
ネックならびにマネジメントのオーバーヘッドがもたらされている。

【００１１】 ｅ） 階層が多いことはコンポーネントが多いことを意味し、それがシングル
−ポイント故障を招く：ＳＳ−３アーキテクチャに基づいたすべての負荷バラン
サ、アプリケーション・サーバー、ファイル・サーバーならびにデータベースサ
ーバー、ルータおよびスイッチは、ミッション・クリティカルなアプリケーショ
ンが障害なく維持できるように障害迂回スキームを有する必要がある。包括的な
障害迂回スキームを開発することは可能であったとしても、関係するハードウエ
ア構成ならびにソフトウエア・プログラムが多すぎることから、その効率ならび
にコスト効果は高くない。

【００１２】 ２． サーバー・クラスタ・マネジメント： ａ） 階層間通信に関連する各コンポーネントの複雑性から、シングル−サー
バー−ベースのサーバークラスターのモニタリングおよびマネジメントが複雑に
なる。単一のソフトウエアのアップグレードがソフトウエアの非互換性をもたら
す傾向にあり、その背後には、関係するソフトウエアが多過ぎ、そのそれぞれも
また多様なベンダからのアップグレードを必要とするという事実がある。

【００１３】 ｂ）包括的なパフォーマンスは容易には最適化されない。ＳＳ−３アーキテク
チャに基づいてサーバークラスターが構築された後は、少なくとも安定状態のオ
ペレーションが円滑に扱われ、グリッチを招くことなくピーク時のオペレーショ
ンに適応できるという基準を満たすものとなっていなければならない。しかしな
がら、測定可能な分散型の小規模な最適ポイントがなく、その結果、安定状態の
オペレーションのコントロールに不確定要素が追加され、ピーク時のオペレーシ
ョンを扱う上で必要な測定を制限することになる。

【００１４】 ｃ）高速ウェブ・アクセスが一般に行われるようになり、同時に応じるべきデ
ータベース中心型の要求が過剰になると、アベイラビリティが高くコスト効果の
良好な線形スケーラビリティの維持が困難になる。現在のところ、ウェブ−ベー
スのクエリは５６ｋｂｐｓの狭帯域伝送レートに基づいて行われており、関連サ
ービスは、ウェブ−ページ配信に集中している。しかしながら、一般的なデータ
転送レートがケーブル・モデムないしはＡＤＳＬの使用によって１Ｍｂｐｓもし
くはそれ以上に跳ね上がり、優勢なサービスの中心がパーソナル・データベース
中心型のウェブ−ページ配信に移行すると、ＳＳ−３アーキテクチャでは高いア
ベイラビリティの維持が困難になる。これは、サーバークラスター内において２
０倍のトラフィックが生成されると、障害迂回負荷バランサの能力にストレスが
掛かって階層間通信の間にボトルネックを生じ、さらにＳＳ−３ベースのスケー
ラビリティにおけるリターンを過大に抑えるという事実による。

【００１５】 （発明の要約） シングル−サーバー−ベースのアーキテクチャに基づく上述したサーバークラ
スターは、大規模ウェブ−ベースのミッション・クリティカルなアプリケーショ
ンのためのアベイラビリティならびにスケーラビリティの高いソリューションを
、効率的に、かつ良好なコスト効果をもって適切に提供することができない。

【００１６】 本発明は、上記の欠点を解決するだけでなく、作業グループ−ベースのサーバ
ー−アレーおよびそのアーキテクチャの構築における技術的な突破口を案出し、
アベイラビリティならびにスケーラビリティの高いソリューションを効率的に、
かつ良好なコスト効果をもって大規模ウェブ−ベースのミッション・クリティカ
ルなアプリケーションに適応させることによってその目的を達成する。

【００１７】 本発明は、以下において「チームプロセッサー」と呼ぶ複数のチーム／作業グ
ループコンピューターを使用し、それが以下において「チームフレーム」と呼ぶ
作業グループ−コンピュータ・フレーム内に、本出願人の特許第５，８０２，３
９１号に記述されているように、以下において「チームサーバー」と呼ぶ複数の
作業グループ−ベースのダイレクト−アクセス・サーバーとともに収められる。
これらのビルディングブロックに基づいて、各種の作業グループサーバーアレー
構成が実施される。

【００１８】 本発明はさらに固有のモジュラー・作業グループ−ベースのコントロールおよ
びモニター装置を包含し、以下においてはそれを「チームパネル」と呼ぶが、そ
れがローカルならびにリモートのモニタリングおよびリブート・マネジメント、
タスク切り替え、負荷バランス、および障害迂回のコントロール機能を提供する
。それに加えて、個々に構成された作業グループサーバーアレーへの適応が、単
一の、もしくは互いにカスケード接続された複数の「チームパネル」によって得
られる。

【００１９】 さらに本発明は、複数の前述したチーム−ビルディング・ブロックを包含し、
その結果、各種構成のための好ましい作業グループサーバーアレーを構築して多
数の独特な根源的機能を提供することができる。好ましいデータ構造およびデー
タ・フローに基づけば、これらの根源的な機能には、限定する意図ではないが、
内部／外部コントロールされるタスク切り替え、作業グループ−ベースの装置共
有、負荷バランス、障害迂回、モニタリングならびにマネジメント、セキュリテ
ィならびにパフォーマンス測定が含まれる。

【００２０】 本発明ならびにそれに関連するアーキテクチャは、不必要なネットワーク−ア
クセス−ベースのコンポーネントを除去し、それらを作業グループ−ベースのダ
イレクト−アクセス・コンポーネントに置き換え、それによって不必要なネット
ワーク・トラフィックを抑え、かつシングル−ポイント故障を低減することによ
って、従来のシングル−サーバー−ベースのアーキテクチャに内在する欠点を解
決する。

【００２１】 さらに、固有のアプリケーションに基づく複数の作業グループサーバーアレー
を作業グループサーバークラスターとして形成可能であり、その結果、その特定
のアプリケーションに基づく、高いアベイラビリティならびにスケーラビリティ
を持ったミッション・クリティカルなウェブ・サービスへの適応が可能になる。
それに加えて、複数の各種アプリケーション−ベースの作業グループサーバーク
ラスターを、直列ならびに並列両方の態様において構成可能であり、広帯域のサ
ービスの質（ＱＯＳ）を損なうこともなく非常に多くのユーザーに同時に適応す
るための大規模マルチ−アプリケーション・ウェブ−ベースのソリューションを
提供することができる。

【００２２】 前述した本発明の特徴ならびに利点をはじめ、追加のその特徴ならびに利点は
、以下の図面を参照した好ましい実施態様の詳細な説明を通じて、より完全に理
解されることとなろう。

【００２３】 （好ましい実施態様の詳細な説明） 図１〜４に示した、作業グループサーバーアレー用の好ましいビルディングブ
ロックとして使用されるチーム／作業グループコンピューターをベースにする本
発明の好ましい実施態様を参照する。

【００２４】 チーム／作業グループコンピューターは、作業グループのピア−ツー−ピア・
リンクを介して互いに作業グループ化されたコンピュータのグループであり、す
べて作業グループサーバーリンクを介して多数のダイレクト−アクセス作業グル
ープサーバーに接続することができる。その詳細については、本出願人による「
ＳＩＮＧＬＥ ＣＨＡＳＳＩＳ ＭＵＬＴＩＰＬＥ ＣＯＭＰＵＴＥＲ ＳＹＳ
ＴＥＭ ＨＡＶＩＮＧ ＳＥＰＡＲＡＴＥ ＤＩＳＰＬＡＹＳ ＡＮＤ ＫＥＹ
ＢＯＡＲＤＳ ＷＩＴＨ ＣＲＯＳＳ ＩＮＴＥＲＣＯＮＮＥＣＴ ＳＷＩＴＣ
ＨＩＮＧ ＦＯＲ ＷＯＲＫ ＧＲＯＵＰ ＣＯＯＲＤＩＮＡＴＯＲ（作業グル
ープ・コーディネータのための相互接続切り替えを伴う分離されたディスプレイ
およびキーボードを有する単一フレーム複数コンピューターシステム）」と題さ
れた特許第５，５３０，８９２号および本出願人による「ＤＩＲＥＣＴ−ＡＣＣ
ＥＳＳ ＴＥＡＭ／ＷＯＲＫＧＲＯＵＰ ＳＥＲＶＥＲ ＳＨＡＲＥＤ ＢＹ
ＴＥＡＭ／ＷＯＲＫＧＲＯＵＰＥＤ ＣＯＭＰＵＴＥＲＳ ＷＩＴＨＯＵＴ Ｕ
ＳＩＮＧ Ａ ＮＥＴＷＯＲＫ ＯＰＥＲＡＴＩＮＧ ＳＹＳＴＥＭ（ネットワ
ーク・オペレーティング・システムを使用しないチーム／作業グループ化された
コンピュータによって共有されるダイレクト−アクセス・チーム／作業グループ
サーバー）」と題された特許第５，８０２，３９１号に記載されている。それに
加えて、上記特許のいずれにも記述されているように、それらが同一の物理レイ
ヤのケーブリングを使用し、修正ＳＣＳＩ（スカジー）等のストレージ−ベース
ならびに通信ベース両方のデータ・リンク・プロトコルを実行する能力を有する
場合には、作業グループのピア−ツー−ピア・リンクおよび作業グループのサー
バー・リンクを互いに接続することが可能である。これらの作業グループ化され
たコンピュータは、そのそれぞれを以下において「チームプロセッサー」と呼ぶ
が、同一もしくは異なるＣＰＵ／ＯＳプラットフォームを基礎とし、またそれら
のダイレクト−アクセス・サーバーは、そのそれぞれを以下において「チームサ
ーバー」と呼ぶが、異なるオペレーティング・システムによってサポートされた
同一のファイル・システムを用いてフォーマットすることができる。「チームサ
ーバー」は、ディスク−ベース、テープ−ベース、および光学ベースのドライブ
を用いて実施することが可能なだけでなく、故障許容ディスク−アレーを用いて
実施することができる。

【００２５】 特定のＯＳに基づく各「チームプロセッサー」は、その特定のＯＳ中心型の作
業グループサーバーリンクのインターフェース・カード、つまり「チームサーバ
ー」カードとともにインストールされ、すべての「チームサーバー」をダイレク
ト−アクセスのローカル・ドライブとして認識する。しかしながら、各「チーム
サーバー」は、ただ１つのプライマリ「チームプロセッサー」を有し、それが読
み出し、書き込みおよびファイル生成に関して絶対的な優先権を持つ。さらに、
１つの物理的ハードディスク・ドライブをはじめ、故障許容ディスクアレーは、
パーティションを作成して複数の論理ドライブとしてフォーマットすることが可
能であり、それぞれの論理ドライブを、それぞれ異なる「チームプロセッサー」
をプライマリ・プロセッサーとしてコントロールすることができる。これらの「
チームプロセッサー」がすべて内部ネットワークリンクに接続され、ネットワー
ク・オペレーティング・システムがインストールされている場合であっても、こ
れらの「チームサーバー」は、「チームプロセッサー」全体を通じてネットワー
ク−アクセスが可能なドライブとしてマップされることがない。

【００２６】 さらに、以下において「チームプロ」コンピュータと呼ぶところの高度に統合
されたチーム／作業グループコンピューターは、複数の「チームプロセッサー」
を包含し、そのすべてが本出願人による「ＣＨＡＳＳＩＳ ＦＯＲ Ａ ＭＵＬ
ＴＩＰＬＥ ＣＯＭＰＵＴＥＲ ＳＹＳＴＥＭ（複数コンピューターシステム用
のフレーム）」と題された特許第５，５７７，２０５号に説明のあるように、１
つの作業グループの「チームフレーム」内に収められている。「チームプロ」コ
ンピュータは、さらにモニタリングおよびマネジメント装置、すなわち「チーム
パネル」を、１つのコンソール・モニタおよび１つのＲＡＰ（リモート−アクセ
ス−ポート）ベースの装置を通じて各「チームプロセッサー」をコントロールし
、それとインターフェイスするための手段として備えており、ＲＡＰベースの装
置自体は、「ＳＩＮＧＬＥ ＣＨＡＳＳＩＳ ＭＵＬＴＩＰＬＥ ＣＯＭＰＵＴ
ＥＲ ＳＹＳＴＥＭ ＨＡＶＩＮＧ ＳＥＰＡＲＡＴＥ ＤＩＳＰＬＡＹＳ Ａ
ＮＤ ＫＥＹＢＯＡＲＤＳ ＷＩＴＨ ＣＲＯＳＳ ＩＮＴＥＲＣＯＮＮＥＣＴ
ＳＷＩＴＣＨＩＮＧ ＦＯＲ ＷＯＲＫ ＧＲＯＵＰ ＣＯＯＲＤＩＮＡＴＯ
Ｒ（作業グループ・コーディネータのための相互接続切り替えを伴う分離された
ディスプレイおよびキーボードを有する単一フレーム複数コンピューターシステ
ム）」と題された特許第５，５３０，８９２号に記載されているように、２つの
シリアル・ポート、１つのキーボード、１つのシステムＬＥＤ、１つのブザー、
および１つのリセット・ボタンを備える。

【００２７】 図１Ａに示されるように、ＰＣ計算プラットフォームに基づく好ましいチーム
／作業グループ・コンピュータ−ベースの「チームプロセッサー」は、概してワ
ン−ウェイ、ツー−ウェイ、またはフォー−ウェイいずれかのＩｎｔｅｌ Ｐｎ
ｅｔｉｕｍ（インテル・ペンティアム）ＣＰＵおよび１２８ＭＢのＲＡＭを実装
したＷｉｎＮＴ（ウインドウズＮＴ）用ＰＣＩベースのマザーボード、フロッピ
ー（登録商標）ディスク・インターフェース・モジュール、ＩＤＥインターフェ ース・モジュール、ＶＧＡカード・モジュール、サウンド・カード・モジュール 、ＵＳＢモジュール、パラレル・インターフェース・モジュール、ＲＡＰモジュ ール、イーサネットを使用するネットワークリンクＬＡＮモジュール、イーサネ ットを使用する作業グループ・ピア‐ツー−ピア・リンク・モジュール、ＳＣＳ Ｉを使用する作業グループ・ピア‐ツー−ピア・リンク・モジュール、およびＳ ＣＳＩを使用する作業グループサーバーリンク・モジュールを包含している。さ らに「チームプロセッサー」には、フロッピーディスク、ＩＤＥディスクおよび 光ドライブ、ＶＧＡモニター、ＵＳＢベースのディジタル・カメラ、マウス、ネ ットワーク・イーサネット−ベースのハブおよびスイッチ、ＳＣＳＩディスク・ ドライブおよびテープ・ドライブ、プリンターおよびスピーカーのセットといっ たモジュール−ベースの外部周辺ドライブおよび装置が備わっている。

【００２８】 図１Ｂに示すように、好ましい作業グループコンピューターのフレーム、つま
り「チームフレーム」は、４つのＣＰＵカード−ベースの「チームプロセッサー
」およびＩＤＥベースのディスクならびに光ドライブ、ＳＣＳＩドライブ等の多
数のモジュール−ベースのドライブならびに装置、および「チームパネル」を収
容する。同じ「チームフレーム」に、各種のモジュール−ベースのドライブおよ
び装置を伴う２つのマザーボード−ベースの「チームプロセッサー」を収容する
こともできる。さらに「チームフレーム」は、内部冗長電源、スマート電源マネ
ジメント、熱交換可能なディスクおよびファン、および外部ＵＰＳを備えること
ができる。

【００２９】 作業グループ化して作業グループサーバーアレーを構成できる個別の「チーム
プロセッサー」の最大数は、内部作業グループサーバーリンクによって制限され
る。作業グループサーバーリンクがＳＣＳＩ−ＩＩを使用している場合には、適
性なデータ転送が保証される有効長は６メートルであり、アタッチできるノード
の数は１６までである。ここに少なくとも２つの「チームプロセッサー」を収容
できる「チームフレーム」が使用されている理由があり、最初の「チームプロセ
ッサー」が外部からのケーブルを拡張し、２番目のそれが外部接続用にケーブル
を拡張することによって、より良好な作業グループ・ピア−ツー−ピア・リンク
−ベースのＳＣＳＩケーブル・スキームがサポートされる。同一の「チームフレ
ーム」に、ＳＣＳＩケーブルをさらに短くして４つのＣＰＵベースの「チームプ
ロセッサー」を収容することもできる。現在のところ４つの異なるＳＣＳＩ標準
が存在し、ＦＡＳＴ ＳＣＳＩ（ファースト・スカジー）から始まって、Ｕｌｔ
ｒａ ＳＣＳＩ（ウルトラ・スカジー）、Ｕｌｔｒａ２（ウルトラ・ツー）ＬＶ
Ｄ ＳＣＳＩおよびＵｌｔｒａ３（ウルトラ・スリー）ＬＶＤ ＳＣＳＩまでで
ある。それぞれの標準には、ナロー（８ビット）構成とワイド（１６ビット）構
成の２つがある。したがって、好ましいＳＣＳＩの実施は、ケーブルを最長で１
２メートルまで延ばすことができる最大データ・レートが１６０ＭＢ／秒のウル
トラ−ワイドＬＶＤ ＳＣＳＩとなる。

【００３０】 図１Ｃは、好ましい作業グループ・リンク統合を示しており、これを参照する
と８つの好ましい「チームプロセッサー」がＳＣＳＩを使用する作業グループ・
ピア−ツー−ピア・リンクによってリンクされ、４つのＳＣＳＩハードディスク
−ベースの「チームサーバー」がＳＣＳＩを使用する作業グループサーバーリン
クによってリンクされている。これらの「チームプロセッサー」および「チーム
サーバー」は、同一のＳＣＳＩケーブルの使用により互いに接続されている。こ
のようにすることによって、すべての「チームプロセッサー」が別の「チームプ
ロセッサー」、特に絶対優先権を有するプライマリ「チームプロセッサー」を巻
き込むことなくダイレクトに各「チームサーバー」にアクセスすることができる
。この図１Ｃに示されるように、各ＳＣＳＩディスク−ベースの「チームサーバ
ー」は、２つの論理ドライブを有し、各「チームプロセッサー」は、１つの論理
ドライブに割り当てられ、絶対優先権を伴ってイネーブルされている。「チーム
サーバー」に対する別の非プライマリ「チームプロセッサー」によるアクセスは
、読み出し専用の態様でのみ許可される。

【００３１】 さらに図１Ｃを参照すると、イーサネット・ハブを備える「チームリンク」カ
ードを介してイーサネットを使用する作業グループ・ピア−ツー−ピア・リンク
が示されており、ＳＣＳＩを使用する作業グループ・ピア−ツー−ピア・リンク
が故障したとき、イーサネットを使用する作業グループ・ピア−ツー−ピア・リ
ンクがそれに代わって通信を行い、あるいはその逆を行うことが可能になってい
る。イーサネットを使用する作業グループ・ピア−ツー−ピア・リンクを実施す
る主要な利点は、作業グループ内における「チームプロセッサー」間通信がネッ
トワーク・トラフィックをはじめ、他の作業グループの「チームプロセッサー」
間通信に悪影響を与えないことである。イーサネットを使用する作業グループ・
ピア−ツー−ピア・リンクは、マップ済みドライブ−ベース、ソケット−ベース
、およびセキュリティ暗号化／復号化ベースといった各種の「チームプロセッサ
ー」間通信に適応できる。ＳＣＳＩ以外の等価ペリフェラル・バスについても、
標準化されているかプロプラエタリであるかによらず、そのデータ−リンク・レ
イヤにストレージ−ベースのプロトコルおよび通信ベースのプロトコルを実施す
る能力がある限り、作業グループ・ピア−ツー−ピア・リンクおよび作業グルー
プサーバーリンクを併合させることが可能な事実上のリンクとして採用すること
ができる。しかしながら、構成によっては、作業グループサーバーリンクおよび
イーサネットを使用する作業グループ・ピア−ツー−ピア・リンクが開設されて
いる限り、適用可能なペリフェラル・バスのいずれかに基づく作業グループ・ピ
ア−ツー−ピア・リンクが必要なくなることがある。

【００３２】 図１Ｄは、好ましいバージョンの「チームパネル」を示しており、そこには４
つの基本コントロール・ユニットおよび１つのメイン・コントロール・ユニット
が備わり、ＲＡＰ、ＶＧＡ、ＵＳＢおよびオーディオ・ポートを経由して最大で
４つの「チームプロセッサー」が接続される。基本コントロール・ユニットは、
１つのマイクロプロセッサーおよび、マイクロプロセッサーによってコントロー
ルされて、別の基本コントロール・ユニットならびにメイン・コントロール・ユ
ニットとリンクする共通のＶＧＡバス、オーディオ・バス、ＵＳＢバス上におけ
るＶＧＡ信号、オーディオ信号、およびＵＳＢ信号のフローを可能にする３つの
スイッチが備わる。それに加えて、別の基本コントロール・ユニットおよびメイ
ン・コントロール・ユニットに接続されているＩ²Ｃを使用する「チームパネル
」ベースの通信リンクが備わり、また１０個のインターフェイス信号のセットが
フロント・パネルに供給されている。

【００３３】 好ましいメイン・コントロール・ユニットは、故障許容用にデュアル・マイク
ロプロセッサーを備え、グループ化された「チームプロセッサー」間の作業グル
ープ共有可能装置として分類されるキーボード、シリアル−ベースの装置および
プリンターを接続するための物理レイヤのインターフェイスを提供する。さらに
メイン・コントロール・ユニットは、各作業グループ化された「チームプロセッ
サー」のバイタル・サイン、ＣＰＵ負荷およびアクティビティを追跡するための
各種のステータス・テーブルをはじめ、共通バスおよびペリフェラル装置を監視
するための使用テーブルを維持しており、これらのテーブルをチェックして衝突
のある使用がないことを確認した後、「チームプロセッサー」からの要求の実行
をシーケンシャルに許可することができる。

【００３４】 好ましいフロント・パネルは、２つのインタラクティブな押しボタンを備え、
一方は、選択した「チームプロセッサー」による外部ＶＧＡベースのモニターの
表示および外部キーボードならびにマウスのコントロールを選択するため、他方
は選択した「チームプロセッサー」をリセットするために使用される。また、３
セットのＬＥＤが備わり、それぞれは電源オン／オフ、プライマリ・システム・
ディスクのアクティビティ、および選択のイネーブルを示す。「チームパネル」
機能ボードおよびフロント・パネルのいずれも、「チームフレーム」内に収容さ
れて、容易に配置できるケーブリング・スキームが工夫されている。

【００３５】 「チームパネル」をコントロールするデフォルトの「チームプロセッサー」を
「チームマネジャー」と呼ぶ。「チームマネジャー」に対する作業グループの通
信については、いずれの「チームプロセッサー」もまず、ＲＡＰのＣＯＭ２を介
してそれにアタッチされたコントロール・ユニットにメッセージを送り、続いて
当該コントロール・ユニットがＩ²Ｃプロトコル・ヘッダを用いてそのメッセー
ジの再パックを行い、「チームパネル」のＩ²Ｃを使用する内部リンクを介して
メイン・コントロール・ユニットに通知を行う。メイン・コントロール・ユニッ
トがリンケージの発生を許可した後は、基本コントロール・ユニットによる「チ
ームパネル」の内部Ｉ²Ｃリンクを介した「チームマネジャー」との直接的な通
信が可能になり、それにより、たとえば、それにアタッチされた「チームプロセ
ッサー」のカレント・ステータスをレポートすることができる。さらに、「チー
ムパネル」の内部リンクを、ＳＣＳＩおよびイーサネットを使用する作業グルー
プ・ピア−ツー−ピア・リンクに対する代替通信リンクとして使用することもで
きる。また障害迂回の目的を満たすときには、ＣＯＭ１ベースのマウス装置をＵ
ＳＢベースのマウスに置き換える。つまり、ＲＡＰのＣＯＭ２が故障した場合に
は、ＲＡＰのＣＯＭ１に引き継ぎ、「チームプロセッサー」とそれにアタッチさ
れた基本コントロール・ユニットの間のデータ通信を提供することができる。

【００３６】 図１Ｅは、２つの「チームパネル」を互いにカスケード接続して８つの好まし
い作業グループ「チームプロセッサー」を接続した状態を示す。第１の「チーム
パネル」つまりＴＰ−４０８Ｍと第２の「チームパネル」つまりＴＰ−４０８Ｃ
は、共通ＶＧＡバス、オーディオ・バス、ＵＳＢバスおよびＩ²Ｃバスを介して
接続されているが、ＴＰ−４０８Ｃにはメイン・コントロール・ユニットがなく
、このためＴＰ−４０８Ｍ内に備わるメイン・コントロール・ユニットがＴＰ−
４０８Ｃ内のすべての基本コントロール・ユニットを監視することになる。また
第１の「チームパネル」をコントロールする「チームマネジャー」は、第２の「
チームパネル」の「チームマネジャー」を兼ねる。「チームマネジャー」に対す
る通信については、第２の「チームパネル」のいずれの「チームプロセッサー」
もまず、ＲＡＰのＣＯＭ２を介してそれにアタッチされたコントロール・ユニッ
トにメッセージを送り、続いて当該コントロール・ユニットがＩ²Ｃプロトコル
・ヘッダを用いてそのメッセージをパックしなおし、Ｉ²Ｃリンクを介して第１
の「チームパネル」内のメイン・コントロール・ユニットに通知を行う。メイン
・コントロール・ユニットがリンケージの発生を許可した後は、第２の「チーム
パネル」の基本コントロール・ユニットによる、「チームパネル」の内部Ｉ²Ｃ
リンクを介した第１の「チームパネル」の「チームマネジャー」との直接的な通
信が可能になる。まったく同じシナリオに基づいて、任意の個別に構成された作
業グループサーバーアレーへの適応が、単一「チームパネル」によって、あるい
は互いにカスケード接続した複数の「チームパネル」によって得られる。各「チ
ームパネル」のフロント・パネルは、各「チームフレーム」内に収容することも
可能であるが、外部ボックスまで延長することも可能であり、その場合は複数の
「チームパネル」のモニターおよびコントロールが容易になる。作業グループサ
ーバーアレーのすべての「チームプロセッサー」を収容する複数の「チームフレ
ーム」は、１つの「チームラック」内に収めることが可能であり、それにおいて
は、追加の「チームフレーム」内に追加の「チームサーバー」が収容可能であり
、さらに、すべての「チームフレーム」間ケーブルをはじめ、すべての入りおよ
び出のケーブルを収容するケーブル分配ボックスを備えることができる。

【００３７】 図２Ａは、本発明システムの一実施態様に従った好ましい作業グループサーバ
ーアレーを図示した機能ブロック図であり、８つの「チームプロセッサー」、４
つのＳＣＳＩディスク−ベースの「チームサーバー」および２つのカスケード接
続された「チームパネル」から構成され、それらが２つの「チームフレーム」に
収容されており、さらにそれを１つの「チームラック」に収容することもできる
。

【００３８】 図２Ｂは、本発明システムの一実施態様に従った好ましい作業グループサーバ
ーアレーを図示した機能ブロック図であり、４つの「チームプロセッサー」、２
つのＳＣＳＩディスク−ベースの「チームサーバー」および１つの「チームパネ
ル」から構成され、それらが１つの「チームフレーム」に収容されており、さら
にそれを１つの「チームラック」に収容することもできる。

【００３９】 図２Ｃは、本発明システムの一実施態様に従った好ましい作業グループサーバ
ーアレーを図示した機能ブロック図であり、１２の「チームプロセッサー」、デ
ュアルＳＣＳＩチャンネルを使用する作業グループサーバーリンクによってリン
クされた６つのＳＣＳＩディスク−ベースの「チームサーバー」、および３つの
カスケード接続された「チームパネル」から構成され、それらが３つの「チーム
フレーム」に収容されており、さらにそれを１つの「チームラック」に収容する
こともできる。

【００４０】 図３Ａは、図２Ａに示したような８つの「チームプロセッサー」を含む作業グ
ループサーバーアレーを使用して各種の根源的な機能を実行するために設計され
た定義済みデータ・フローを伴う好ましい構成を図示している。この好ましい構
成に基づけば、８つの「チームプロセッサー」を機能的に次の２つのグループに
分類することができる：すなわち（１）アプリケーション／ファイル・サービス
・プロセッサー（ＴＰ１〜ＴＰ４）；（２）データベース／ファイルサービス／
負荷バランス／ファイアウォール・プロセッサー（ＴＰ５〜ＴＰ８）である。各
「チームプロセッサー」は、ＳＣＳＩディスク‐ベースのプライマリ「チームサ
ーバー」を有しており、そのそれぞれは、残り７つの「チームプロセッサー」に
対して読み出し専用「チームサーバー」として動作させることが可能であり、以
下においては、その場合の「チームサーバー」をセカンダリ「チームサーバー」
と呼ぶ。つまり、ブート‐アップの間、各「チームプロセッサー」は１つのＩＤ
Ｅ−ベースのシステム・ドライブを認識するとともに、ＮＯＳマッピング・スキ
ームを用いることなく作業グループのダイレクト−アクセス・サーバーとして機
能する、１つのプライマリ「チームサーバー」および７つのセカンダリ「チーム
サーバー」を認識する。それに加えて、作業グループ化されたすべての「チーム
プロセッサー」によってアクセスされる上記のプライマリならびにセカンダリ「
チームサーバー」は、複数の故障許容ディスクアレーおよび、２つのＳＣＳＩチ
ャンネル上のトラフィックを分配するためのデュアル−チャンネル「チームサー
バー」カードを用いても実施することができる。

【００４１】 アプリケーション／ファイル・サービス−ベースの「チームプロセッサー」Ｔ
Ｐ１〜ＴＰ４は、それぞれインターネットからのＨＴＴＰ−ベースのアプリケー
ション指向ウェブ・クエリを処理してトランザクション・バッチ・ファイルを生
成する能力を有し、それがシステムＩＤＥドライブおよびそのプライマリ「チー
ムサーバー」の両方に書き込まれる。データベース／ファイル・サービス−ベー
スの「チームプロセッサー」ＴＰ５〜ＴＰ８は、それぞれイントラネットおよび
エクストラネットからのＦＴＰベースまたはプロプラエタリのリアルタイムのソ
ケット−ポート−ベースのデータベース指向ウェブ・クエリを取り扱い、システ
ムＩＤＥドライブおよびそのプライマリ「チームサーバー」の両方に書き込まれ
ることになるトランザクション・バッチ・ファイルを生成する能力を有する。

【００４２】 それとは別に、「チームプロセッサー」ＴＰ５およびＴＰ７は、それぞれのプ
ライマリ「チームサーバー」上にインストールされるアプリケーション固有作業
グループデータベースをそれぞれ維持している。これら２つのデータベースは、
基本的に、その日の最後には同一になる。ＴＰ５によってコントロールされるデ
ータベースは、その日の間において、所定の時間周期（ｔ）内に「チームサーバ
ー１」〜「チームサーバー４」から生成された各バッチ・トランザクション・フ
ァイルに基づいて更新される。ＴＰ７によってコントロールされるデータベース
は、その日の最後において、その日の間に「チームサーバー１」〜「チームサー
バー４」から生成されたすべてのバッチに基づいて更新される。ＴＰ６は、主と
してイントラネットからのＦＴＰベースのデータベース指向ウェブ・クエリを取
り扱い、その結果、ＴＰ５による「チームサーバー６」からの検索およびｔ時間
周期ごとのデータベースの更新が可能になる。またＴＰ５は、イントラネットか
らの、プロプラエタリのリアルタイムのソケット−ポート−ベースのデータベー
ス・クエリがあると、直ちにデータベースを更新する。ＴＰ８は、デフォルトの
「チームプロセッサー」、つまりこれら２つの「チームパネル」をコントロール
する「チームマネジャー」になる。

【００４３】 好ましいサーバー−ペア構成を基礎とすることによって、以下においてＷＳＡ
と呼ぶ、発明性の作業グループサーバーアレー用の多数の独特な機能的サービス
を生み出すことが可能になる。

【００４４】 ＷＳＡサーバーの調和およびスーパーバイザリ・サービスについての好ましい
方法の１つは、「チームマネジャー」（ＴＰ８）が作業グループ化されたすべて
の「チームプロセッサー」を調和させ、マネジメント−ベースのアクティビティ
を生成するという形で実施することができる。このアクティビティには、各「チ
ームプロセッサー」上にインストールされたＯＳによって生成することができる
各「チームプロセッサー」のインベントリ、ディスク・スペースおよびＣＰＵ使
用のモニターをはじめ、作業グループ化された「チームプロセッサー」のそれぞ
れにおいて生じ得る侵入、削除および故障の警告が含まれる。各「チームプロセ
ッサー」は、恒常的にマネジメント−ベースのステータス情報をパックし、それ
をＲＡＰのＣＯＭ２を介してそのコントロール・ユニットに渡し、コントロール
・ユニットは、メイン・コントロール・ユニットに通知を行った後、「チームパ
ネル」のＩ２Ｃリンクを介した、メイン・コントロール・ユニットからのインス
トラクションを送るためのＯＫを待機する。ＯＫ信号が受信されると、この特定
の「チームプロセッサー」による、そのコントロール・ユニットから「チームマ
ネジャー」のコントロール・ユニットへのダイレクト通信が可能になり、続いて
ＲＡＰのＣＯＭ２を介して「チームマネジャー」にステータス情報が送られる。
「チームマネジャー」は、常時、作業グループ化されたすべての「チームプロセ
ッサー」に関するマネジメント−ベースのステータス・テーブルを維持している
。

【００４５】 ＷＳＡの内部フロント・パネル切り替えサービスに関係する好ましい方法の１
つは、それ自体もしくは任意の「チームプロセッサー」からの、特定の「チーム
プロセッサー」がまだ機能しているか否かのチェックを求める要求があったとき
、「チームマネジャー」がメイン・コントロール・ユニットにその要求を送り、
それがさらに診断要求をその特定の「チームプロセッサー」に送るという形で実
施することができる。応答がなければ、メイン・コントロール・ユニットは「チ
ームマネジャー」のコントロール・ユニットに対して通知を送り、そこからＲＡ
ＰのＣＯＭ２を経由して「チームマネジャー」にその通知が送られる。その後「
チームマネジャー」は、ネットワークリンクを介してＬＡＮベースのマネジメン
ト・コンソールにアラーム・メッセージを送り、オペレータからの応答を待機す
る。オペレータは、「Ｃａｒｂｏｎ−Ｃｏｐｙ（カーボン−コピー）」または類
似のソフトウエアを起動することによってマネジメント・コンソール・コンピュ
ータを介して「チームマネジャー」のコントロールを引き継ぐことができる。そ
れとは別に、「チームマネジャー」にはビデオ・キャプチャ・カードが備わり、
共通ＶＧＡバスがＮＴＳＣコンバータに接続されているので、任意の「チームプ
ロセッサー」のＶＧＡ表示を「チームマネジャー」のＶＧＡ表示内に再取り込み
することができる。したがってメイン・コントロール・ユニットに対して「選択
」要求を送ることによって、「チームマネジャー」に、故障した「チームプロセ
ッサー」のスクリーン表示を取り込むべくインストラクションを与えることが可
能であり、それによって、続いて行われる「チームマネジャー」のコントロール
・ユニットから故障した「チームプロセッサー」のコントロール・ユニットへの
通信が可能になる。オペレータから故障した「チームプロセッサー」にキーボー
ド入力を送り、それに応じた動作を得て、その後の解析のために「チームマネジ
ャー」上に診断ファイルを保存することもできる。故障した「チームプロセッサ
ー」をリセットするべきであるとオペレータが判断した場合には、故障した「チ
ームプロセッサー」のコントロール・ユニットに「リセット」コマンドを送るよ
うに「チームマネジャー」に対してインストラクションを与える。その結果、こ
の特定のコントロール・ユニットは、故障した「チームプロセッサー」に直接リ
ンクされているリセット・ラインをトリガし、それをリセットする。ブート−ア
ップ・プロセスは、「チームマネジャー」上での取り込み、表示および保存が可
能であり、それによってオペレータは、リモート・マネジメント・コンソール・
コンピュータのある場所において、ステップごとにブート−アップ・プロセスを
監視し、インタラクションすることができる。それに加えて、技術要員は、保存
済みの診断ファイルに基づいてさらに解析を行い、問題箇所を判断して解決策を
引き出すができる。

【００４６】 ＷＳＡの現場フロント・パネル切り替えサービスに関係する好ましい方法の１
つは、ＶＧＡモニター、スピーカーのセット、キーボードおよびマウスといった
「チームパネル」ベースの作業グループ装置を使用したいずれかの「チームプロ
セッサー」の監視、コントロールおよびリセットのための、ローカルの現場オペ
レータによる「チームフレーム」上のフロント・パネルの使用を可能にする形で
実施することができる。パネル上の「選択」および「リセット」に関する押しボ
タン信号は、メイン・コントロール・ユニットに直接リンクされており、メイン
・コントロール・ユニットは、いずれかの押しボタン要求があると、該当すると
きにはまず、使用テーブルをチェックして衝突する使用がないことを確認し、関
連するＬＥＤを点滅させる。押しボタンによるアクティブ化の意図がある場合に
は、ローカルのオペレータがそのボタンをさらに１回押してアクションをトリガ
すればよく、それにより関連するＬＥＤがオンにセットされる。アクションが完
了した後は、関連するＬＥＤがオフにセットされる。

【００４７】 ＷＳＡのリモート・フロント・パネル切り替えサービスに関係する好ましい方
法の１つは、任意のリモート・コンピュータによって、暗号化されたプロプラエ
タリのアクセス・コードに基づく作業グループ−ベースのシリアル・リンクにア
タッチされた外部モデムを介して、「チームマネジャー」もしくはいずれかの「
チームプロセッサー」のコントロールを引き継ぐことを可能にする形で実施する
ことができる。この通信が開設された後は、リモート・コンピュータが、ＬＡＮ
ベースのマネジメント・コンソール・コンピュータとまったく同じに、すべての
機能を実行することができる。

【００４８】 ＷＳＡの装置共有サービスに関係する好ましい方法の１つは、「チームマネジ
ャー」ならびに他の任意の「チームプロセッサー」によるＷＳＡ内の周辺装置の
アクセスを可能にする形で実施することができる。特定の「チームプロセッサー
」がいずれかの周辺装置、たとえばプリンターへのアクセスを必要としていると
き、その「チームプロセッサー」が、ＲＡＰのＣＯＭ２を介して要求メッセージ
をそのコントロール・ユニットに送ると、そのコントロール・ユニットが内部Ｉ ² Ｃリンクを介してメイン・コントロール・ユニットに要求を送る。ステータス
・テーブルおよび使用テーブルのチェックの後、使用可能であればメイン・コン
トロール・ユニットは、続いて行われるその特定のコントロール・ユニットから
メイン・コントロール・ユニットへの通信を許可し、さらにメイン・コントロー
ル・ユニットは、ビルトインのパラレル・インターフェースを介してデータをア
タッチされたプリンターに中継する。別のシリアル・ポート装置用に同様のプロ
セスを実施することもできる。しかしながらＵＳＢ装置の場合は、特定の「チー
ムプロセッサー」が、そのコントロール・ユニットにＲＡＰのＣＯＭ２を介して
要求を送り、それをそのコントロール・ユニットがメイン・コントロール・ユニ
ットに送る。ＵＳＢ装置用の使用テーブルをチェックした後、使用可能であれば
、メイン・コントロール・ユニットからそのコントロール・ユニットにＯＫ信号
が返され、それがボード上のＵＳＢスイッチをオンにする。このようにすれば、
その特定の「チームプロセッサー」上のＵＳＢインターフェイスに、共通ＵＳＢ
バスを介してビデオ・カメラ等の作業グループ−ベースのＵＳＢ装置を直接接続
することが可能になる。

【００４９】 ＷＳＡの障害迂回スキーム−ベースのサービスに関係する好ましい方法の１つ
は、「チームフレーム」、「チームパネル」、「チームプロセッサー」、「チー
ムサーバー」等のＷＳＡ内のミッション・クリティカルなコンポーネントの故障
許容あるいは障害迂回を可能にしてミッション・クリティカルなアプリケーショ
ンが中断しない形で実施することができる。

【００５０】 「チームパネル」については、ミッション・クリティカルな機能がデュアル・
マイクロプロセッサーを備えるそのメイン・コントロール・ユニットに関係して
おり、そのため最初の１つが故障しても次のプロセッサーがそれを引き継いで「
チームマネジャー」にアラームを送ることが可能であり、さらにそれからマネジ
メント・コンソールに通知することができる。「チームフレーム」については、
デュアル電源および外部ＵＰＳを備えていることから故障許容である。「チーム
プロセッサー」については、４つの障害迂回用グループ、すなわちＴＰ１および
ＴＰ２、ＴＰ３およびＴＰ４、ＴＰ５およびＴＰ６、ＴＰ７およびＴＰ８があり
、各グループのメンバは他と同一のハードウエア構成を有している。つまり、各
グループ内において一方が故障しても、他方がそれを引き継ぐことができる。し
たがって、たとえば「チームマネジャー」ＴＰ８が故障した場合には、ＴＰ７が
それを引き継いで「チームマネジャー」として機能する。さらに、ＴＰ１および
ＴＰ２からなるペアとＴＰ３およびＴＰ４からなるペアは、ともに障害迂回用の
グループである。また、ＴＰ５およびＴＰ６からなるペアとＴＰ７およびＴＰ８
からなるペアも障害迂回用のグループである。したがって、ＴＰ１とＴＰ２のペ
アが故障した場合にはＴＰ３とＴＰ４のペアがそれを引き継ぎ、逆の場合には逆
の引き継ぎが行われる。ＴＰ５およびＴＰ６からなるペアとＴＰ７およびＴＰ８
からなるペアについてもまったく同じシナリオを適用できる。

【００５１】 ファイル−サービス−ベースの「チームサーバー」については、８つの障害迂
回用グループ、すなわち「チームプロセッサー１」のＩＤＥ１と「チームサーバ
ー１」、ＩＤＥ２と「チームサーバー２」、ＩＤＥ３と「チームサーバー３」、
ＩＤＥ４と「チームサーバー４」、ＩＤＥ５と「チームサーバー５」、ＩＤＥ６
と「チームサーバー６」、ＩＤＥ７と「チームサーバー７」、ＩＤＥ８と「チー
ムサーバー８」である。したがって、「チームサーバー１」が故障しても、他の
「チームプロセッサー」は「チームプロセッサー１」からＩＤＥ１の情報を取り
出すことができる。ＩＤＥ１が故障した場合に他の「チームプロセッサー」は、
「チームサーバー１」から情報を直接取り出すことができる。これと同じシナリ
オが、残り７つの障害迂回用グループにも適用される。データベース−サービス
−ベースの「チームサーバー」については、「チームサーバー５」上のデータベ
ースがＴＰ５によってコントロールされ、「チームサーバー７」上のデータベー
スがＴＰ７によってコントロールされており、前述したように、これらは基本的
に同じアプリケーション固有のデータベースである。しかしながら、データベー
スとＴＰ５のペアが故障すると、データベースとＴＰ７のペアが直ちに、「チー
ムサーバー１」から「チームサーバー８」に収集された関連するすべてのバッチ
ファイルに基づいて「チームプロセッサー７」によって更新され、瞬時にサービ
スの準備が整う。

【００５２】 ＷＳＡのアプリケーション−ベースの負荷バランス・サービスに関係する好ま
しい方法の１つは、「チームパネル」を使用することによってＷＳＡ内のアプリ
ケーション−ベースの「チームプロセッサー」の負荷バランスが得られるような
形で実施することができる。ウェブ−ベースの環境においては、アプリケーショ
ン−ベースであり、かつクエリ−ベースである要求がＨＴＴＰプロトコルを使用
するインターネットから到来する。到来したクエリ−ベースのトラフィックは、
まずルータを通る。続いてこのルータは、すべての要求を「チームマネジャー」
ＴＰ８に渡す。その後「チームマネジャー」は、到来するトラフィック負荷を内
部ＦＴＰポートまたはプロプラエタリ・ポートを通じ、イーサネットを使用する
作業グループ・ピア−ツー−ピア・リンクを介してＴＰ１、ＴＰ２、ＴＰ３、お
よびＴＰ４に分配することができる。ラウンド−ロビンの実施においては、各ア
プリケーション−ベースの「チームプロセッサー」のＣＰＵ使用および応答時間
に基づいて、「チームマネジャー」（ＴＰ８）がラウンド−ロビン−ベースの負
荷バランス・ステータス・テーブルを維持し、「チームパネル」のメイン・コン
トロール・ユニットが各種のバイタル・サイン・ステータス・テーブルを維持し
ている。

【００５３】 作業グループ化されたいずれの「チームプロセッサー」の場合にも、それにア
タッチされているコントロール・ユニットに対し、ＲＡＰのＣＯＭ２を介して恒
常的にバイタル・サインおよびそれに類似の信号が送られることから、コントロ
ール・ユニットは、そのデータをパックしなおしてメイン・コントロール・ユニ
ットに通知する。メイン・コントロール・ユニットがリンケージの発生を許可し
た後は、基本コントロール・ユニットがこのデータをメイン・コントロール・ユ
ニットのメモリ・バッファ内にダウンロードすることが可能になり、それを各種
のバイタル・サイン・ステータス・テーブルに割り当てることができる。これら
のリアルタイム・ステータス・テーブルに基づいて、メイン・コントロール・ユ
ニットは、故障が発生したか、あるいは過負荷となっている「チームプロセッサ
ー」を検出することができる。これらのいずれかの状況が発生すると、メイン・
コントロール・ユニットは、それを「チームマネジャー」にレポートする。過負
荷状態の場合には、「チームマネジャー」は、直ちにラウンド−ロビン・シーケ
ンスからの懸案の「チームプロセッサー」の除外を試み、メイン・コントロール
・ユニットから、その特定の「チームプロセッサー」を再度ラウンド−ロビン・
シーケンスに戻すことに関連した通知を再び受け取るまでそれを継続する。また
、故障状態の場合においては、「チームマネジャー」が、作業グループ・ピア−
ツー−ピア・リンクを介して懸案の「チームプロセッサー」との通信リンクの開
設を試みる。応答がなければ、「チームマネジャー」からメイン・コントロール
・ユニットに、ＲＡＰの「リセット」ラインを介した「チームプロセッサー」の
リセットを通知し、その結果、部分的もしくは完全な回復および、それに従った
動作がもたらされる。

【００５４】 ラウンド−ロビン方式に加えて、「最少オープン接続」、「最短測定時間また
は応答時間」、「コンテンツ・タイプ」、「オープン接続数」といった別のイン
テリジェントアルゴリズムおよびアプリケーション・サーバーから収集されるそ
の他の統計も利用することができる。「チームマネジャー」ＴＰ８は、作業グル
ープ・ピア−ツー−ピア・リンクを介してこれらのタイプの情報を１つずつ収集
し、故障した「チームプロセッサー」（１ないしは複数）を検出することが可能
であることから、１つの特定の「チームプロセッサー」における過負荷を招くこ
となく、また故障した「チームプロセッサー」に負荷を渡すことなく各種のアル
ゴリズムをインテリジェントに実施することが可能になる。しかしながら、すべ
ての「チームプロセッサー」の種類が同一であり、「チームマネジャー」が異常
状態に基づく「チームパネル」のメイン・コントロール・ユニットからのインス
トラクションに応答するだけでよいときには、ラウンド−ロビン・アルゴリズム
が最良の選択肢となり得る。

【００５５】 ＷＳＡのファイルサービスおよびデータベースサービスに関係する好ましい方
法の１つは、個々の「チームサーバー」上のファイルおよびデータベースに対し
て、「チームプロセッサー」から直接的にアクセスし、それらの間で共有できる
ようにする形で実施することができる。これは、ダイレクト−アクセス−ベース
のセカンダリ「チームサーバー」用の「チームプロセッサー」に、それと同数の
読み出し専用データベース・エンジンをインストールし、プライマリ「チームプ
ロセッサー」に完全なデータベース・エンジン、つまり、そのプライマリ「チー
ムサーバー」上のデータベースに対して適用される絶対的な優先権を有すること
ができるデータベース・エンジンをインストールすることによって達成される。
それに加えて、「チームマネジャー」（ＴＰ８）は、アタッチされたすべてのフ
ァシリティに関する一連のステータス・テーブルおよび使用テーブルを維持して
いる。これらのテーブルの１つは、すべての「チームサーバー」上において二重
書き込みによるデータの完全性の喪失が回避されるように、各「チームサーバー
」のプライマリ「チームプロセッサー」の同時発生リストを維持している。しか
しながら、個々の「チームサーバー」のプライマリ「チームプロセッサー」は、
いずれも、障害迂回、異なる時間ゾーンにおける異なるオペレーション・ニーズ
、アップグレードのための一時的なスーパーバイザリの変更等があったとき、別
の「チームプロセッサー」に変更することが可能である。「チームマネジャー」
は、常に、所定の時点において特定の「チームサーバー」を更新できる「チーム
プロセッサー」が１つだけとなることを保証する。

【００５６】 ＷＳＡのセキュリティ・サービスに関係する好ましい方法の１つは、ＷＳＡへ
の許可のない侵入を検出する形で実施することができる。「チームマネジャー」
ＴＰ８は、到来するすべての要求を受け取り、「チームプロセッサー」の間に負
荷を分配することから、「チームマネジャー」にセキュリティ強化をおよびファ
イアウォール機能をインストールし、潜在的な外からの攻撃を防ぐことが必須に
なる。基本的に「チームマネジャー」ＴＰ８は、ＳＳＬベースまたはＯＳベース
もしくはより高レベルのアプリケーション−ベースのアクセス暗号化セキュリテ
ィ測定を実施して、正当な要求を、イーサネットを使用する作業グループ・ピア
−ツー−ピア・リンクを介してアプリケーション−ベースの「チームプロセッサ
ー」にリダイレクトし、到来した要求を２つの異なるセキュリティ−ベースのゾ
ーンに分離することによって疑問のある要求をフィルタ・アウトすることができ
る。各アプリケーション−ベースの「チームプロセッサー」は、アプリケーショ
ン固有のデータベースに対するアクセスを包含することがある応答を見つけ出し
、コンテンツ暗号化のセキュリティ基準を用いて適正な内部ＩＰアドレスを含め
ることによって、それを要求元に返す。これにより「チームマネジャー」はコン
テンツを復号し、直前の要求を扱った適正な「チームプロセッサー」にそれをリ
ダイレクトすることができる。このタイプの粘着性のポート・アプローチは、ソ
ースＩＰアドレス等のファクタおよびユーザー認証装置の要求プロトコルまたは
返されたクッキーに含まれる特殊な情報に基づいた持続型セッションとして知ら
れ、安全に実施することが可能であり、ウェブ−ベースの電子商取引アプリケー
ション・サービスを効率的に行う上で欠くことができない。

【００５７】 ＷＳＡの障害迂回サービスに関係する好ましい方法の１つは、多数のエージェ
ント−ベースのマネジメント・ソフトウエア、つまり「チームソフト」を作成し
、好ましい構成の定義済みデータ構造ならびにデータ・フローに基づいた上記の
機能的サービスをすべて統合する形で実施することができる。現在の「チームマ
ネジャー」のみが「チームソフト」のサーバー部分にインストールされ、残りの
「チームプロセッサー」は「チームソフト」のクライアント部分にインストール
されることになる。アクティブになっている「チームプロセッサー」が１つある
間は、リモート・マネジメント・コンソール・コンピュータは、その「チームプ
ロセッサー」をコントロールし、それを「チームマネジャー」として機能させる
ことが可能であり、その結果、故障した「チームプロセッサー」があればそれを
リブートして、本発明の作業グループサーバーアレーを正常機能に戻すことがで
きる。「チームソフト」障害迂回機能に基づけば、各「チームプロセッサー」が
、「チームマネジャー」を介して障害迂回用ペアの他方が生きているか否かにつ
いての検出を起動することができる。生きていなければ「チームプロセッサー」
は、故障した他方がサービスを提供していたタスクを引き継ぐ。たとえば、ＴＰ
５が故障したとすると、ＴＰ６に対して「チームマネジャー」が、「チームサー
バー５」の優先権およびデータベースを更新するタスクを割り当てる。ＴＰ６が
故障した場合には、ＴＰ５に対して「チームマネジャー」が、「チームサーバー
６」の優先権を割り当て、ＴＰ６用のＩＰアドレスに代えてＴＰ５用のＩＰアド
レスを用いて到来した要求を通知することによって、ＴＰ６のトラフィックをＴ
Ｐ５にリダイレクトする。また「チームソフト」には、自動修正アクションが組
み込まれた作業グループ用の問題診断も含まれている。

【００５８】 ＷＳＡのパフォーマンス測定サービスに関係する好ましい方法の１つは、いく
つかの主要パラメータの値を調整することによってＷＳＡにおける最適パフォー
マンスの達成が可能になる形で実施することができる。本発明の作業グループサ
ーバーアレーのパフォーマンスは、次の３つのファクタに基づいて決定される：
すなわち（１）「チームマネジャー」のファイアウォール・オペレーション、（
２）アプリケーション‐ベース「チームプロセッサー」の数、および（３）アプ
リケーション固有データベースのサイズである。「チームマネジャー」ＴＰ８に
ファイアウォール・オペレーションがインストールされている場合には、コンテ
ンツ復号セキュリティおよび上位レイヤ・アクセス‐ベースのセキュリティを満
たすための時間が過大になり、１分当たりの到来要求の数が減少する。しかしな
がら、この問題は、ネットワーク・レイヤのフィルタリングおよび上位レイヤの
フィルタリングを実行することができるファイアウォール−ベースのルータをア
タッチすることによって解決される。

【００５９】 アプリケーション−ベースの「チームプロセッサー」の数が減少すると、１分
当たりに送り出される応答の数が減少する。データベースについての考察と同様
に、アプリケーション中心型のデータベースが非ロイヤルティ・トラフィックに
基づいて構築されている場合には、場合によっては非ロイヤルティ・ベースのト
ラフィックを満たすために増加することがあるレディメードの情報だけを供給す
る傾向が生じる。その逆に、ロイヤルティ・トラフィックに基づいて構築されて
いる場合には、データベースが格段に大きくなる。しかしながら、応答ページを
形成するためにデータベースからデータを検索するときに要する時間は、別の「
チームプロセッサー」に依存することなく「チームサーバー」上のデータベース
に容易にアクセスできることから問題とならない。

【００６０】 したがって、２つのシナリオが存在することになる：すなわち（１）非ロイヤ
ルティ・アプリケーション−ベース、および（２）ロイヤルティ・アプリケーシ
ョン−ベースである。非ロイヤルティ−ベース状況下においては、本発明の作業
グループサーバーアレーの最適パフォーマンスが、アプリケーション−ベースの
「チームプロセッサー」の数に依存する。計算パワーおよびサービスの複雑度に
基づき、１つの「チームプロセッサー」が、送出する応答を抑え、許容可能なサ
ービスの質（ＱＯＳ）と考えられるサービスを低下させることなく処理すること
ができる到来する要求の数はＸである。つまり、４つの「チームプロセッサー」
は、安定状態のオペレーションにおいて、到来する４Ｘ個の要求に適応すること
ができる。ピーク時の非ロイヤルティ・トラフィックが６Ｘに跳ね上がったとし
ても、本発明の作業グループサーバーアレーは、ＴＰ６およびＴＰ７をアプリケ
ーション−ベースの「チームプロセッサー」に割り当て、「チームマネジャー」
によって運用されるラウンド‐ロビン負荷バランス・アルゴリズムに加えること
によって、ピーク時のオペレーションに適応することができる。

【００６１】 さらに、図２Ｃに示した１２個の「チームプロセッサー」をベースにする作業
グループサーバーアレーにおいては、１２個のうち８個がアプリケーション−ベ
ースの「チームプロセッサー」であり、安定状態のオペレーションにおいて８Ｘ
個の非ロイヤルティ・トラフィックに適応し、ピーク時オペレーションにおいて
は１０Ｘ個のトラフィックに適応することができる。ただし到来するトラフィッ
クが１０Ｘ個を超える場合には、第２の作業グループサーバーアレーが必要にな
る。

【００６２】 ロイヤルティ−ベース状況下においては、本発明の作業グループサーバーアレ
ーの最適パフォーマンスが、アプリケーション−ベースの「チームプロセッサー
」の数およびロイヤルティ−ベースのデータベースのサイズに依存する。このデ
ータベースのサイズが過度に大きく、到来する要求がすべての「チームプロセッ
サー」が扱うことができる数を超えて生成された場合には、データベースのサイ
ズを縮小して安定状態のオペレーション要件を満たす必要があり、超過分につい
ては第２の作業グループサーバーアレーに移す必要がある。たとえば１２個の「
チームプロセッサー」をベースにする作業グループサーバーアレーは、８Ｘ個の
ロイヤルティ・トラフィックに適応できるが、それは、アプリケーション中心デ
ータベース上にインストール可能なロイヤルティ−ベースのユーザー数Ｙに転化
することができる。ピーク時の状況下において、Ｙ人のユーザーが１０Ｘ個のロ
イヤルティ−ベースのトラフィックを生成しても、許容可能なＱＯＳを満たすこ
とができる。

【００６３】 本発明の作業グループサーバーアレーは、常にＸおよびＹの数の再調整を行い
、「チームマネジャー」によって収集された情報に基づいて許容可能なサービス
の質を確保している。つまり、本発明の作業グループサーバーアレーに関するパ
フォーマンス測定値は、パラメータＸおよびＹとなり、最適動作ポイントをはじ
め、リソースの増加を必要とする問題の予測を導くことができる。

【００６４】 より高い帯域幅のアプリケーションについては、サービスの程度が高くなり、
それによってＸおよびＹの数が下がることが考えられる。しかしながら、本発明
の作業グループサーバーアレーのＱＯＳが損なわれることはない。

【００６５】 ロイヤルティ−ベースのシナリオにおいて、より多くの到来する同一アプリケ
ーションの要求に適応するため、図３Ｂに、それぞれが相互排他のデータベース
・セグメントを有する複数のシングル−アプリケーション−ベースの作業グルー
プサーバーアレーからなる作業グループサーバークラスターを示す。それぞれの
作業グループサーバーアレーがＱＯＳを満たすことから、全体的な作業グループ
サーバークラスターもまたＱＯＳ適合である。

【００６６】 このようにして、第１の作業グループサーバーアレーからｎ番目の作業グルー
プサーバーアレーまでを含む作業グループサーバークラスターによって、アベイ
ラビリティならびにスケーラビリティの高い、ミッション・クリティカルなアプ
リケーションに適応することが可能になる。これがロイヤルティ−ベースである
ことから、ルータは、適正なＩＰアドレスに基づいて適正な到来トラフィックを
適正な「チームマネジャー」に直ちに分配することが可能であり、この情報は、
それらのブラウザの「クッキー」内、あるいはネットワーク・アクセスおよびユ
ーザー認証に使用可能なチップ−ベースのスマート・カード内のいずれかにイン
ストールされている。

【００６７】 非ロイヤルティ−ベースの状況については、ルータは、ＵＲＬをＩＰアドレス
に変換するドメインネームサーバー（ＤＮＳ）とともに、組み込みラウンド−ロ
ビン機能を使用することによって、到来する負荷を非ロイヤルティ−ベースの作
業グループサーバークラスターの複数の「チームマネジャー」に分配することが
できる。これを行う間に、非ロイヤルティ−ベースのトラフィックのための負荷
バランスが実施され、この場合にもＱＯＳが損なわれることがない。作業グルー
プ・サーバー・クラスタ−ベースの負荷バランスだけでなくラウンド−ロビン−
ベースのＤＮＳに基づいたこの独特な方法は、すべてのウェブ・アプリケーショ
ンをマネージし、負荷バランスを得るだけの充分なパワーが要求され、階層間ネ
ットワーク・スイッチの過負荷を招く不必要なネットワーク・トラフィックを生
み出していたグローバルな負荷バランサを不要にするという明確な利点をもたら
す。さらに、いずれかの「チームマネジャー」が故障した場合には、ＤＮＳから
その「チームマネジャー」の障害迂回用ペアの他方にメッセージが送られ、ＤＮ
Ｓが、「チームマネジャー」のＩＰアドレスと障害迂回用の他方のＩＰアドレス
をともに通知することから、それに対する割り当てが自動的に行われて、ＤＮＳ
から到来するトラフィックの引き継ぎ、および処理が行われる。

【００６８】 ロイヤルティ−ベースおよび非ロイヤルティ−ベースのシナリオのいずれにつ
いても、ウェブ−ベースのアプリケーションが良好に定義されており、それに関
連付けされたデータベースもまた良好に定義されているはずであることから、デ
ータベース・サーバー・プログラムは、複雑なインテリジェンスを組み込む必要
がなく、高速かつ実行がシンプルである必要がある。データベース検索に要する
時間は、ＸおよびＹを大きな数とし、より良好なパフォーマンスを得るためにも
、可能な限り短くあるべきである。

【００６９】 ユーザー／サーファから到来する要求が多くの異なるウェブ−ベースのアプリ
ケーションに関係すると考えられることから、複数の異なるアプリケーション−
ベースの作業グループサーバークラスターをインストールする必要がある。図４
は、アベイラビリティならびにスケーラビリティの高いミッション・クリティカ
ルなイントラネット、エクストラネット、インターネットアプリケーションのた
めの包括的なウェブ−サーバーの実施態様であり、直列および並列に連鎖させた
複数の作業グループサーバークラスターが統合されて、理想的かつ安全な分散コ
ンピューティング環境が作られている。

【００７０】 ファイアウォール・ベースの作業グループサーバーアレーを使用するゾーン−
ベースのセキュリティに加えて、異なる作業グループサーバークラスターの間に
おける相互通信を、ＳＳＬベース、ＯＳベース、またはアプリケーション−ベー
スのコンテンツおよびアクセス・セキュリティを伴うプロプラエタリ・ポートを
使用することによって安全に実施することが可能であり、その結果、作業グルー
プサーバークラスターのいずれに対するアクセスが、いかなる外来通信にも許さ
れない。

【００７１】 さらに、ＦＣ−ＡＬまたは類似のリンクをすべての「チームマネジャー」のリ
ンクに使用することによって、各作業グループサーバーアレーの「チームサーバ
ー」を、ハードディスク−ベース、テープ−ベースあるいは光ディスク−ベース
であるかによらず、すべてＦＣデバイスに変換することが可能になり、続いてそ
れを、ＳＡＮ（ストレージ・エリア・ネットワーク）ベースのバックエンド・デ
ータベース・プロセッサーのいずれかを用いてアクセスし、維持することができ
る。このようにすると、バックエンド・データ中心のＳＡＮベースの高度なファ
イル・サーバーならびにデータベースサーバー用の、あらゆる作業グループサー
バーアレーのアプリケーション中心型ファイルおよびデータベースサーバーまた
はデータ・キャッシング・サーバーに、よりインテリジェントなデータベース・
エンジンが備えられることになる。

【００７２】 結論を述べれば、本発明は、次のような独特なコンポーネントを具体化する：
すなわち（１）「チームプロセッサー」、（２）「チームサーバー」および「チ
ームサーバー」カード、（３）「チームパネル」、（４）「チームリンク」カー
ド、（５）「チームフレーム」、および（６）「チームラック」である。これら
の独特なコンポーネントに基づき、本発明は、多くの独特な方法を採用して好ま
しい作業グループサーバーアレーを構成する。すなわちそれは、（１）ＷＳＡの
サーバー−ペア方法、（２）ＷＳＡのマルチ作業グループ・リンク方法、（３）
ＷＳＡのサーバー調整およびスーパーバイザリ方法、（４）ＷＳＡの内部、現場
およびリモート「フロント・パネル」切り替え方法、（５）ＷＳＡの装置共有方
法、（６）ＷＳＡのフェイル−セーフおよび回復方法、（７）ＷＳＡの負荷バラ
ンス方法、（８）ＷＳＡのファイル／データベース共有方法、（９）ＷＳＡのセ
キュリティ−ベースの方法、（１０）ＷＳＡの「チームソフト」ベースのマネジ
メント方法、および（１１）ＷＳＡの最適パフォーマンス測定方法である。さら
に、これらの発明性の作業グループサーバーアレーに基づいて、本発明は多数の
独特な方法を採用して好ましい作業グループサーバークラスター（ＷＳＣ）を構
築した。すなわちそれは（１）ＷＳＣの構成方法、（２）ＷＳＣの負荷バランス
方法、（３）ＷＳＣのキャッシュ中心型データベース方法、（４）ＷＳＣのユー
ザー認証ロイヤルティ中心型の作業グループデータベース方法である。最後に、
これらの発明性の作業グループサーバークラスターに基づき、本発明は、多数の
独特な方法を使用して好ましい「フロント−オフィス」ウェブ−ベースのサーバ
ー・ファームを構築した。すなわちそれは（１）複数ＷＳＣの直列連鎖方法、（
２）複数ＷＳＣの並列連鎖方法、（３）直列連鎖および並列連鎖による複数ＷＳ
Ｃをストレージ・エリア・ネットワーク（ＳＡＮ）を用いてリンクする方法であ
る。

【００７３】 以上から本発明が、作業グループサーバーアレーおよび、安全な分散コンピュ
ーティング環境において、アベイラビリティならびにスケーラビリティが高く、
ミッション・クリティカルなサーバークラスターを構築するための、その関連ア
ーキテクチャを提供することが理解されよう。

【００７４】 当業者であれば、追加の利点ならびに修正が容易に明らかなものとなろう。し
たがって、本発明のより広い側面が、ここに示し、説明した具体的な詳細、代表
として表した装置、および説明用の例に限定されることはない。換言すれば、出
願人の包括的な発明思想の真意ならびに範囲から逸脱することなく、この種の詳
細から離れることは可能である。本発明は、付随する特許請求の範囲によっての
み定義される。

【図面の簡単な説明】

【図１】 Ａ． 好ましい作業グループサーバーアレーを構築するための装置の１つとして
好ましい作業グループ・プロセッサー、すなわち「チームプロセッサー」を示し
た機能ブロック図である。 Ｂ． 好ましい作業グループサーバーアレーを構築するための装置の１つとして
好ましい作業グループコンピュータ・フレーム、すなわち複数の「チームプロセ
ッサー」を収容できる「チームフレーム」を示した機能ブロック図である。 Ｃ． 好ましい統合化構成の１つを示した機能ブロック図であり、それには本発
明の実施態様の１つとして、複数のリンクを介してネットワークされ作業グルー
プ化された８つの好ましい「チームプロセッサー」をはじめ、４つの「チームサ
ーバー」が包含される。 Ｄ． 好ましいモジュラー型の作業グループ−ベースのモニタリングおよびマネ
ジメント、すなわち「チームパネル」を示した機能ブロック図であり、それには
４つの基本コントロール・ユニット、デュアル・プロセッサーを伴う１つのメイ
ン・コントロール・ユニットが包含され、フロント・パネルが組み込まれた「チ
ームフレーム」に収容することができる「チームプロセッサー」を最大で４つま
で接続することができる。 Ｅ． プライマリ「チームパネル」およびセカンダリ「チームパネル」をカスケ
ード接続し８つの「チームプロセッサー」構成に適応するモジュラーを示した機
能ブロック図である。

【図２】 Ａ． 本発明システムの一実施態様に従った好ましい作業グループサーバーアレ
ーを示した機能ブロック図であり、８つの「チームプロセッサー」、４つのＳＣ
ＳＩディスク−ベースの「チームサーバー」および２つのカスケード接続された
「チームパネル」から構成され、それらすべてが２つの「チームフレーム」に収
容されている。 Ｂ． 本発明システムの一実施態様に従った好ましい作業グループサーバーアレ
ーを示した機能ブロック図であり、４つの「チームプロセッサー」、２つのＳＣ
ＳＩディスク−ベースの「チームサーバー」および１つの「チームパネル」から
構成され、それらすべてが１つの「チームフレーム」に収容されている。 Ｃ． 本発明システムの一実施態様に従った好ましい作業グループサーバーアレ
ーを示した機能ブロック図であり、１２の「チームプロセッサー」、デュアルＳ
ＣＳＩチャンネルを使用してリンクされる６つのＳＣＳＩディスク‐ベースの「
チームサーバー」、および３つのカスケード接続された「チームパネル」から構
成され、それらすべてが３つの「チームフレーム」に収容されている。

【図３】 Ａ． 内部オペレーション、障害迂回、負荷バランス、セキュリティ、マネジメ
ントおよび最適パフォーマンス測定とともに使用するための複数の根源的機能が
すべてインストールされた、好ましい８つの「チームプロセッサー」サーバー・
アレー上における好ましいデータ構造ならびにデータ・フローの方法の実施を示
した機能ブロック図である。 Ｂ． 複数のシングル‐アプリケーションの作業グループサーバーアレーからな
る作業グループサーバークラスターを示した機能ブロック図であり、それぞれは
最適パフォーマンス測定に基づく相互排他データベース・セグメントを提供し、
それにより高いアベイラビリティならびにスケーラビリといった相互作業グルー
プ−ベースの根源的機能がインストールされる。

【図４】 各種セキュリティ・ゾーン−ベースのアプリケーション指向作業グループサー
バークラスターおよび、ＦＣ−ＡＬハブまたはＦＣスイッチを使用するバックエ
ンド・データベース・サーバーの好ましい統合を示した機能ブロック図であり、
好ましいデータ中心／ウェアハウス構成がウェブ−ベースのミッション・クリテ
ィカルな分散コンピューティング環境において作られる。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＡＬ，ＡＭ，Ａ Ｕ，ＢＡ，ＢＧ，ＢＲ，ＣＡ，ＣＮ，ＣＺ，ＥＥ，ＧＥ ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＰ， ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＶ，ＭＤ，ＭＧ，Ｍ Ｋ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＲＯ，ＲＵ ，ＳＤ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＲ，ＵＡ，ＵＳ， ＵＺ，ＶＮ，ＹＵ，ＺＷ

Claims (50)

【特許請求の範囲】
1. 【請求項１】 それぞれマルチＣＰＵ計算プラットフォームを具えた複数の
   チームプロセッサーを有しており、各プラットフォームはＲＡＭとモニター、音
   響、スピーカー、アクセスポート、ＵＳＢ、ネットワークリンク、作業グループ
   ピア・ツー・ピアリンク、周辺ドライバーおよび作業グループサーバーリンクと
   接続されたそれぞれのモジュールを有しており、かつ各チームプロセッサーの作
   業グループサーバーリンクが複数の分担作業グループサーバーに接続されている
   ことを特徴とするマルチプロセッサー・コンピューターシステム。
2. 【請求項２】 各作業グループサーバーが故障許容ディスクアレーであるこ
   とを特徴とする請求項１に記載のシステム。
3. 【請求項３】 さらに少なくとも１個のフレームを有しており、これに少な
   くとも４個のチームプロセッサーと少なくとも２個の作業グループサーバーが収
   容されていることを特徴とする請求項１に記載のシステム。
4. 【請求項４】 少なくとも８個のチームプロセッサーと少なくとも４個の作
   業グループサーバーとを有しており、各チームプロセッサーが各作業グループサ
   ーバーと接続されていることを特徴とする請求項１に記載のシステム。
5. 【請求項５】 さらに複数の制御ＣＰＵを具えた少なくとも１個のチームパ
   ネルを有しており、各チームＣＰＵが対応するチームプロセッサーに接続され、
   各ＣＰＵが複数スイッチを有していて、これらスイッチが対応するチームプロセ
   ッサーをＵＳＢ装置、モニター、音響スピーカー、キーボード、マウス、モデム
   、プリンターおよびシリアル装置に選択的に接続することを特徴とする請求項１
   に記載のシステム。
6. 【請求項６】 さらに複数のチームパネルが互いに接続されて、より多数の
   チームプロセッサーを接続していることを特徴とする請求項５に記載のシステム
   。
7. 【請求項７】 少なくとも１個の追加的な制御ＣＰＵが第１の主制御ユニッ
   トと指定されており、分担バスへのアクセス、チームプロセッサーのための装置
   およびチームプロセッサー間の負荷バランスの管理を行うことを特徴とする請求
   項５に記載のシステム。
8. 【請求項８】 さらに第１の主制御ユニットの故障バックアップモードのた
   めの第２の主制御ユニットを有していることを特徴とする請求項７に記載のシス
   テム。
9. 【請求項９】 いずれかのチームプロセッサーがチームパネルを制御するチ
   ームマネジャーとされていることを特徴とする請求項７に記載のシステム。
10. 【請求項１０】 少なくとも１個の作業グループサーバーが主としてファイ
    ルサービスのアプリケーションに従事し、他の少なくとも１個の作業グループサ
    ーバーが主としてデータベースファイルサービスに従事していることを特徴とす
    る請求項１に記載のシステム。
11. 【請求項１１】 ファイルサービスアプリケーション従事作業グループサー
    バーがアプリケーション発要求にサービスする能力を提供することを特徴とする
    請求項１０に記載のシステム。
12. 【請求項１２】 データベースファイルサービス従事作業グループサーバー
    がデータベース発要求にサービスする能力を提供することを特徴とする請求項１
    ０に記載のシステム。
13. 【請求項１３】 各作業グループサーバーがフェイルセイフ動作のために周
    辺装置に書き込まれるバッチファイルを発生することを特徴とする請求項１０に
    記載のシステム。
14. 【請求項１４】 少なくとも他の作業グループサーバーがフェイルセイフ動
    作のためにアプリケーションファイルとデータベースファイルを提供することを
    特徴とする請求項１０に記載のシステム。
15. 【請求項１５】 各チームプロセッサーが１個の作業グループサーバーを主
    たるものとして、残りの全ての作業グループサーバーを第２のものとして認識す
    ることを特徴とする請求項１に記載のシステム。
16. 【請求項１６】 作業グループピア・ツー・ピアリンクがイーサネット（登 録商標）またはＳＣＳＩインターフェイスに基づいており、作業グループサーバ ーリンクがＳＣＳＩインターフェイスに基づいていることを特徴とする請求項１ に記載のシステム。
17. 【請求項１７】 いずれかのチームプロセッサーがチームマネジャーとして
    指定されて、残りのチームプロセッサーの状態をモニターすることを特徴とする
    請求項１に記載のシステム。
18. 【請求項１８】 各作業グループサーバーが少なくとも１個のチームプロセ
    ッサーに直接アクセスすることを特徴とする請求項１に記載のシステム。
19. 【請求項１９】 それぞれがマルチＣＰＵ計算プラットフォームを具えた複
    数グループのチームプロセッサーを有しており、各グループは複数のチームプロ
    セッサーを有してかつＶＧＡモニター、キーボード、音響スピーカーおよびシリ
    アルバスとの接続のためのチームパネルに接続されており、各グループは作業グ
    ループサーバーリンクに接続されており、複数の直接アクセス作業グループサー
    バーが作業グループサーバーリンクによりチームプロセッサーのグループに接続
    されており、該グループは作業グループピア・ツー・ピアリンクを介して作業グ
    ループイーサネットハブに接続され、該グループは作業グループイーサネットス
    イッチを介してローカルエリアネットワークに接続されていることを特徴とする
    作業グループサーバーアレーシステム。
20. 【請求項２０】 各作業グループサーバーが故障許容ディスクアレーである
    ことを特徴とする請求項１９に記載のシステム。
21. 【請求項２１】 さらに１個のフレームが設けられており、これが少なくと
    も４個のチームプロセッサーと少なくとも２個の作業グループサーバーを収容し
    ていることを特徴とする請求項１９に記載のシステム。
22. 【請求項２２】 少なくとも８個のチームプロセッサーと少なくとも４個の
    作業グループサーバーが含まれていて、各チームプロセッサーが各作業グループ
    サーバーと接続されていることを特徴とする請求項１９に記載のシステム。
23. 【請求項２３】 複数の制御ＣＰＵを具えた少なくとも１個のチームパネル
    が設けられており、各ＣＰＵが対応するチームプロセッサーと接続されており、
    各ＣＰＵが複数のスイッチと接続されており、これらのスイッチが対応するチー
    ムプロセッサーをＵＳＢ装置、モニター、音響スピーカー、キーボード、マウス
    、モデム、プリンターおよびシリアル装置に選択的に接続していることを特徴と
    する請求項１９に記載のシステム。
24. 【請求項２４】 複数のチームパネルが相互に接続されて、より多数のチー
    ムプロセッサーに接続されていることを特徴とする請求項２３に記載のシステム
    。
25. 【請求項２５】 制御ＣＰＵのうちの少なくとも１個が第１の主制御ユニッ
    トとして指定され、チームプロセッサーのための分担バスと装置へのアクセスお
    よびチームプロセッサー間の付加バランスの監視を行うことを特徴とする請求項
    ２３に記載のシステム。
26. 【請求項２６】 さらに第１の主制御ユニットの故障モードバックアップの
    ための第２の主制御ユニットが設けられていることを特徴とする請求項２５に記
    載のシステム。
27. 【請求項２７】 チームマネジャーとして指定されたいずれかのチームプロ
    セッサーがチームパネルを制御することを特徴とする請求項２５に記載のシステ
    ム。
28. 【請求項２８】 少なくとも１個の作業グループサーバーが主としてアプリ
    ケーションファイルサービスに従事し、他の少なくとも１個の作業グループサー
    バーが主としてデータベースファイルサービスに従事することを特徴とする請求
    項１９に記載のシステム。
29. 【請求項２９】 アプリケーションファイルサービスに従事する作業グルー
    プサーバーがアプリケーション発要求にサービスする機能を提供することを特徴
    とする請求項２８に記載のシステム。
30. 【請求項３０】 データベースファイルサービスに従事する作業グループサ
    ーバーがデータベース発要求にサービスする機能を提供することを特徴とする請
    求項２８に記載のシステム。
31. 【請求項３１】 各作業グループサーバーがフェイルセイフ動作のために周
    辺装置に書き込まれるバッチファイルを発生することを特徴とする請求項２８に
    記載のシステム。
32. 【請求項３２】 他の少なくとも１個の作業グループサーバーがフェイルセ
    イフ動作のためにアプリケーションファイルサービスおよびデータベースファイ
    ルサービスを提供することを特徴とする請求項２８に記載のシステム。
33. 【請求項３３】 各チームプロセッサーが１個の作業グループサーバーを主
    として残りの作業グループサーバーを第２のものとして認識することを特徴とす
    る請求項１９に記載のシステム。
34. 【請求項３４】 作業グループピア・ツー・ピアリンクがイーサネットまた
    はＳＣＳＩに基づいており、作業グループサーバーリンクがＳＣＳＩインターフ
    ェイスに基づいていることを特徴とする請求項１９に記載のシステム。
35. 【請求項３５】 １個のチームプロセッサーがチームマネジャーとして指定
    されて、残りの各チームプロセッサーの状態をモニターすることを特徴とする請
    求項１９に記載のシステム。
36. 【請求項３６】 各作業グループサーバーが少なくとも１個のチームプロセ
    ッサーに直接アクセス可能であることを特徴とする請求項１９に記載のシステム
    。
37. 【請求項３７】 複数のチームプロセッサーを有しており、各チームプロセ
    ッサーがマルチＣＰＵ計算プラットフォームとチームプロセッサーを複数の分担
    直接アクセスチームサーバーに接続する作業グループサーバーリンクとを有して
    いるマルチプロセッサーコンピューターシステムにおいて：第１のチームプロセ
    ッサーをチームマネジャーとして選択し、該チームマネジャーを用いて全ての残
    りのチームプロセッサーの状態をモニターし、各チームプロセッサーがその状態
    をチームマネジャーに送り、該チームマネジャーがチームプロセッサーから受け
    取った状態情報に対応する磁気ベース状態テーブルを有していることを特徴とす
    るチームサーバーの調整管理方法。
38. 【請求項３８】 各チームプロセッサーがＶＧＡリンクを介して共通のモニ
    ターに接続されており、さらにチームマネジャーを用いて各チームプロセッサー
    の診断をモニターし、チームマネジャーにより故障したチームプロセッサーのＶ
    ＧＡリンクを計算して、かつチームマネジャーによりチームプロセッサーをリセ
    ットすることを特徴とする請求項３７に記載の方法。
39. 【請求項３９】 負荷バランスのために少なくとも１個のチームプロセッサ
    ーを割り当て、データベースサービスのために少なくとも１個のチームプロセッ
    サーを割り当て、かつアプリケーション特定サービスのために少なくとも１個の
    チームプロセッサーを割り当てることを特徴とする請求項３７に記載の方法。
40. 【請求項４０】 チームプロセッサーを対にして、他の対のために１個のチ
    ームプロセッサーによる故障許容を提供することを特徴とする請求項３７に記載
    の方法。
41. 【請求項４１】 コンピューターシステムがチームプロセッサーの状態をモ
    ニターする追加の装置を有していて、さらに該装置を用いてチームプロセッサー
    の状態をモニターし、該装置がチームプロセッサー間の負荷バランスの最終的な
    調整器（ａｒｂｉｔｒａｔｏｒ）であって、かつチームマネジャーに指示してチ
    ームプロセッサー間の負荷分布を変更させて負荷バランスを行うことを特徴とす
    る請求項３７に記載の方法。
42. 【請求項４２】 各チームプロセッサーには主サーバーとして１個の作業グ
    ループサーバーが付加されており、残りの作業グループサーバーは第２のサーバ
    ーとして付加されていることを特徴とする請求項１９に記載のシステム。
43. 【請求項４３】 選択されたチームプロセッサーのための各主サーバーが該
    チームプロセッサーへのデータベースアクセスの全機能を提供し、他の全てのチ
    ームプロセッサーへのリードオンリーデータベースアクセス機能を提供すること
    を特徴とする請求項４２に記載のシステム。
44. 【請求項４４】 あるチームプロセッサーはアプリケーションに基づいてお
    りあるチームプロセッサーはデータベースに基づいており、かつある作業グルー
    プサーバーはアプリケーションに基づいたサーバーであり、あるものはデータベ
    ースサーバーであり、さらにアプリケーションに基づいたチームプロセッサーと
    サーバーとの数を調整する手段が設けられていて、入力交信のための挙動品質を
    最適なものとすることを特徴とする請求項１９に記載のシステム。
45. 【請求項４５】 複数の相互接続された作業グループサーバーアレーを有し
    ており、複数のチームプロセッサーのそれぞれがマルチＣＰＵ計算プラットフォ
    ームを具えており、各グループが複数のチームプロセッサーとＶＧＡモニター、
    キーボード、音響スピーカーおよびシリアルバスとの接続のためのチームパネル
    に接続されており、各グループが作業グループサーバーリンクに接続されており
    、複数の直接アクセス作業グループサーバーが作業グループサーバーリンクを介
    してチームプロセッサーのグループに接続されており、該グループは作業グルー
    プピア・ツー・ピアリンクを介して作業グループイーサネットハブに接続されて
    おり、グループはまた作業グループイーサネットスイッチを介してローカルエリ
    アネットワークに接続されていることを特徴とする作業グループサーバークラス
    ター。
46. 【請求項４６】 さらにラウンドロビンサーバーが設けられていて、複数の
    作業グループサーバーアレー間の付加をバランスさせることを特徴とする請求項
    ４５に記載のクラスター。
47. 【請求項４７】 入力交信を分配するドメインネームサーバーが設けられて
    いることを特徴とする請求項４６に記載のクラスター。
48. 【請求項４８】 各作業グループサーバーアレーが作業グループデータベー
    スを与えて、これが作業グループサーバークラスター中の他の各作業グループサ
    ーバーアレーの作業グループデータベースと重複していることを特徴とする請求
    項４５に記載のクラスター。
49. 【請求項４９】 各作業グループサーバーアレーが独特な作業グループデー
    タベースを提供することを特徴とする請求項４５に記載のクラスター。
50. 【請求項５０】 複数の追加的な作業グループサーバークラスターへの直列
    ／並列接続により上方にスケール可能であり、これにより高能力使命臨界アプリ
    ケーションが得られることを特徴とする請求項４５に記載のクラスター。