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

Description

【０００１】
（発明の背景）
（関連出願）
この出願は、２０００年４月１１に特許されて現在は特許第６，０４９，８２３号である「Ａ ＭＵＬＴＩ ＳＥＲＶＥＲ， ＩＮＴＥＲＡＣＴＩＶＥ， ＶＩＤＥＯ−ＯＮ−ＤＥＭＡＮＤ ＴＥＬＥＶＩＳＩＯＮ ＳＹＳＴＥＭ ＵＴＩＬＩＺＩＮＧ Ａ ＤＩＲＥＣＴ−ＡＣＣＥＳＳ−ＯＮ−ＤＥＭＡＮＤ ＷＯＲＫＧＲＯＵＰ ＳＥＶＥＲ（ダイレクト−アクセス−オン−デマンド・作業グループサーバーを使用するマルチ・サーバー、インタラクティブ、ビデオ−オン−デマンド・テレビジョン・システム）」と題された１９９６年１１月１日出願の特許出願番号を第０８／７４２，７４１号とする特許出願の部分継続出願である１９９９年５月２０日出願の暫定特許出願第６０／１３５，３１８号からの優先権主張に基づく出願である。
【０００２】
（発明の分野）
本発明は、概してサーバークラスターに関し、より詳細に述べれば、スケーラビリティのあるウェブ−ベースのイントラネット、エクストラネット、ならびにインターネットのミッション・クリティカルなアプリケーションに適応する各種サーバークラスターを構築するための作業グループサーバーアレーおよびそのアーキテクチャを実施する方法ならびに装置に関する。
【０００３】
発明性のサーバー・アレーは、本出願人による「ＤＩＲＥＣＴ−ＡＣＣＥＳＳ ＴＥＡＭ／ＷＯＲＫＧＲＯＵＰ ＳＥＲＶＥＲ ＳＨＡＲＥＤ ＢＹ ＴＥＡＭ／ＷＯＲＫＧＲＯＵＰＥＤ ＣＯＭＰＵＴＥＲＳ ＷＩＴＨＯＵＴ ＵＳＩＮＧ Ａ ＮＥＴＷＯＲＫ ＯＰＥＲＡＴＩＮＧ ＳＹＳＴＥＭ（ネットワーク・オペレーティング・システムを使用しないチーム／作業グループ化されたコンピュータによって共有されるダイレクト−アクセス・チーム／作業グループサーバー）」と題された特許第５，８０２，３９１に記述のあるような作業グループ−ベースのダイレクト−アクセス・サーバーおよびコントロール装置を備えたチーム／作業グループコンピューターを包含する。さらに、この発明性のサーバー・アレーは、作業グループ−サーバー−アレー−ベースのアーキテクチャを生み出し、それを使用して各種の高いアベイラビリティならびにスケーラビリティを有するミッション−クリティカルなサーバークラスターを構成することができる。
【０００４】
革新的なインターネット・テクノロジの爆発は、アプリケーションの記述ならびに開発の方法に大きな影響を与えている。過去において一旦は静的な「ブローシャ・ウエア」であった数十万のインターネット・ウェブ・サイトも、トランザクション・ケイパビリティを伴った高度にインタラクティブなインターネットアプリケーションに迅速に移行しつつある。大会社の内部では、開発者がエンタープライズ・アプリケーションを大規模イントラネットに統合するためにウェブ・テクノロジを使用している。会社間においては、ビジネス・パートナーが安全なエクストラネットを構築して供給チェーンのストリームライニングおよび通信を向上させている。
【０００５】
ウェブ−ベースのアプリケーションがインターネットおよびエンタープライズ・イントラネットならびにエクストラネット上に広がるに従って、それらが行う機能がますますミッション・クリティカルなものになって来ている。さらに、ビジネスはミッション・クリティカルなタスクへのウェブ・ベースのテクノロジの適用を続けていることから、そのアプリケーションに高度のアベイラビリティならびにスケーラビリティを持たせるために洗練されたアプローチを必要としている。
【０００６】
高いスケーラビリティならびにアベイラビリティを達成するためのトレンドは、多くの協働するサーバー、つまりエンド・ユーザの要求するアプリケーションを届けるためのサーバークラスターを包含したシステムに向かっている。さらに、大規模ウェブ−ベースのサービスにも、アベイラビリティ、スケーラビリティ、信頼性、パフォーマンス、マネジメント、およびセキュリティ問題への適応を可能にするためサーバークラスターを構築するアーキテクチャが必要とされている。
【０００７】
しかしながら、複数の個別のサーバーを使用することによって高いスケーラビリティ、高いアベイラビリティおよびミッション・クリティカルなウェブ−アプリケーション−ベースのサーバークラスターを構築するために使用可能な現在のテクノロジは、シングル−サーバー−ベースの３階層アーキテクチャ、つまりこれ以降においてＳＳ−３アーキテクチャと呼ぶアーキテクチャを生み出す傾向にある。このＳＳ−３アーキテクチャは、概して第１階層コンポーネント、すなわち負荷バランサ；第２階層コンポーネント、すなわちアプリケーション・サーバー；および、第３階層コンポーネント、すなわちデータベースサーバーおよびファイル・サーバーを必要とする。各個別のサーバーは、ＰＣベース、スーパー−マイクロ−ベース、あるいはミニ−コンピュータ−ベースとすることが可能であり、ＷｉｎＮＴ（ウインドウズＮＴ）、Ｓｏｌａｒｉｓ（ソラリス）、Ｌｉｎｕｘ（リナックス）およびＵｎｉｘ（ユニックス）等のオペレーティング・システムを使用する並行処理能力を伴う複数のＣＰＵからなる。
【０００８】
このように、ＳＳ−３アーキテクチャに基づいて、ウェブ−ベースのアプリケーションのためのアベイラビリティならびにスケーラビリティの高いサーバークラスターを構築することは可能である。しかしながら、これらのアーキテクチャは、同時に次に示す不利益をもたらす。
【０００９】
１． 階層化されたそれぞれのコンポーネントに関連する問題
ａ） 負荷バランサ：すべての到来トラフィックを解析し、ウェブ−ベースの個別の各クエリ／要求を、アタッチされている有効な第２階層のアプリケーション・サーバーの１つにリダイレクトする。負荷バランサは、要求の特性および負荷バランスされたウェブ・アプリケーション・サーバーのアベイラビリティならびにスケーラビリティに基づいて、第２階層にある特定のウェブ−ベースのアプリケーション・サーバーに要求を分配する。この負荷バランサには、３つの基本的なタイプがある：すなわち、スイッチ、ソフトウエア・バランサ、およびアプライアンス・バランサである。しかしながら、上記の負荷バランサのいずれも、ストレスが大きくなるとインターネット接続が遅滞させる可能性を有する。
ｂ） アプリケーション・サーバー：第１階層の負荷バランサから割り当てを受け、ウェブ−ベースのアプリケーションを実行し、アプリケーション指向データ検索のために第３階層のデータベースサーバーおよびファイル・サーバーとインターフェイスする。しかしながら、異なるハードウエアならびにソフトウエア構成に基づく各アプリケーション・サーバーが互いに異なる可能性は否定できず、負荷バランサのマネジメントの複雑化をもたらしている。それに加えて、各アプリケーション・サーバーがロイヤルティ−ベースおよび非ロイヤルティ−ベースのクエリをともに扱うため、セキュリティ基準のレベルが異なるコヒーレントでないプログラム・グループが作られることになる。さらにまた、ネットワーク−アクセス−ベースのセカンダリ・プロセッサーを含むときに限り、サーバーのプライマリ・プロセッサーに故障した場合に、このセカンダリ・プロセッサーが別のネットワーク−ベースのマネジメント・サーバーによってアクセスされ、トリガされてプライマリ・プロセッサーをリブートできるようになっていることを別にすれば、各アプリケーション・サーバーにリモート・ブート能力が備わっていない。
ｃ） データベース／ファイル・サーバー：クライアントと見なされる第２階層にあるすべてのアプリケーション・サーバーからのデータベース／ファイル・クエリを処理するクライアント−サーバー−ベースのサーバーである。ロイヤルティ−ベースのトラフィックと非ロイヤルティ−ベースのトラフィックの間の区別がまったくないことから、ロイヤルティ−ベースならびに非ロイヤルティ−ベースのアプリケーション指向データがすべて１つの中央ファイル・サーバーにストアされ、同時発生のクエリが増大したときの潜在的なデータベース／ファイル検索のボトルネックをもたらしている。さらに、これらのファイル・サーバーならびにデータベースサーバーが、複数のＳＡＮ（ストレージ・エリア・ネットワーク）によりイネーブルされるストレージ・デバイスにリンクされる複数の分散型データベースサーバーおよびファイル・サーバーを含むデータ・センタとして実施された場合には、その種のデータ・センタをマネージするための複雑性が高くなる。これは、クライアント中心型サーバーならびにサーバー中心型サーバーのいずれにおいても複雑なデータベース・ソフトウエア・プログラムが必要になるという事実による。しかしながら、アプリケーション指向データとビジネスに敏感なデータを１つのデータ・センタにひとまとめにすることは、ファイアウォールのフィルタリングといった過剰のセキュリティ基準を呈示して、ウェブ−ベースのブラウジング・アクティビティによる破壊行為の潜在的なリスクから保護する必要を生じるため、理想的であるとは言えない。
【００１０】
ｄ） 階層間通信スイッチ：第１階層の負荷バランサと第２階層のアプリケーション・サーバーの間、およびアプリケーション・サーバーと第３階層のファイル・サーバーならびにデータベースサーバーの間において必要になる。すべてのコンポーネントがネットワーク−ベースであることから、サーバー間の通信はこれらの２つのスイッチを通じて処理され、不必要な階層間トラフィックのボトルネックならびにマネジメントのオーバーヘッドがもたらされている。
【００１１】
ｅ） 階層が多いことはコンポーネントが多いことを意味し、それがシングル−ポイント故障を招く：ＳＳ−３アーキテクチャに基づいたすべての負荷バランサ、アプリケーション・サーバー、ファイル・サーバーならびにデータベースサーバー、ルータおよびスイッチは、ミッション・クリティカルなアプリケーションが障害なく維持できるように障害迂回スキームを有する必要がある。包括的な障害迂回スキームを開発することは可能であったとしても、関係するハードウエア構成ならびにソフトウエア・プログラムが多すぎることから、その効率ならびにコスト効果は高くない。
【００１２】
２． サーバー・クラスタ・マネジメント：
ａ） 階層間通信に関連する各コンポーネントの複雑性から、シングル−サーバー−ベースのサーバークラスターのモニタリングおよびマネジメントが複雑になる。単一のソフトウエアのアップグレードがソフトウエアの非互換性をもたらす傾向にあり、その背後には、関係するソフトウエアが多過ぎ、そのそれぞれもまた多様なベンダからのアップグレードを必要とするという事実がある。
【００１３】
ｂ）包括的なパフォーマンスは容易には最適化されない。ＳＳ−３アーキテクチャに基づいてサーバークラスターが構築された後は、少なくとも安定状態のオペレーションが円滑に扱われ、グリッチを招くことなくピーク時のオペレーションに適応できるという基準を満たすものとなっていなければならない。しかしながら、測定可能な分散型の小規模な最適ポイントがなく、その結果、安定状態のオペレーションのコントロールに不確定要素が追加され、ピーク時のオペレーションを扱う上で必要な測定を制限することになる。
【００１４】
ｃ）高速ウェブ・アクセスが一般に行われるようになり、同時に応じるべきデータベース中心型の要求が過剰になると、アベイラビリティが高くコスト効果の良好な線形スケーラビリティの維持が困難になる。現在のところ、ウェブ−ベースのクエリは５６ｋｂｐｓの狭帯域伝送レートに基づいて行われており、関連サービスは、ウェブ−ページ配信に集中している。しかしながら、一般的なデータ転送レートがケーブル・モデムないしはＡＤＳＬの使用によって１Ｍｂｐｓもしくはそれ以上に跳ね上がり、優勢なサービスの中心がパーソナル・データベース中心型のウェブ−ページ配信に移行すると、ＳＳ−３アーキテクチャでは高いアベイラビリティの維持が困難になる。これは、サーバークラスター内において２０倍のトラフィックが生成されると、障害迂回負荷バランサの能力にストレスが掛かって階層間通信の間にボトルネックを生じ、さらにＳＳ−３ベースのスケーラビリティにおけるリターンを過大に抑えるという事実による。
【００１５】
（発明の要約）
シングル−サーバー−ベースのアーキテクチャに基づく上述したサーバークラスターは、大規模ウェブ−ベースのミッション・クリティカルなアプリケーションのためのアベイラビリティならびにスケーラビリティの高いソリューションを、効率的に、かつ良好なコスト効果をもって適切に提供することができない。
【００１６】
本発明は、上記の欠点を解決するだけでなく、作業グループ−ベースのサーバー−アレーおよびそのアーキテクチャの構築における技術的な突破口を案出し、アベイラビリティならびにスケーラビリティの高いソリューションを効率的に、かつ良好なコスト効果をもって大規模ウェブ−ベースのミッション・クリティカルなアプリケーションに適応させることによってその目的を達成する。
【００１７】
本発明は、以下において「チームプロセッサー」と呼ぶ複数のチーム／作業グループコンピューターを使用し、それが以下において「チームフレーム」と呼ぶ作業グループ−コンピュータ・フレーム内に、本出願人の特許第５，８０２，３９１号に記述されているように、以下において「チームサーバー」と呼ぶ複数の作業グループ−ベースのダイレクト−アクセス・サーバーとともに収められる。これらのビルディングブロックに基づいて、各種の作業グループサーバーアレー構成が実施される。
【００１８】
本発明はさらに固有のモジュラー・作業グループ−ベースのコントロールおよびモニター装置を包含し、以下においてはそれを「チームパネル」と呼ぶが、それがローカルならびにリモートのモニタリングおよびリブート・マネジメント、タスク切り替え、負荷バランス、および障害迂回のコントロール機能を提供する。それに加えて、個々に構成された作業グループサーバーアレーへの適応が、単一の、もしくは互いにカスケード接続された複数の「チームパネル」によって得られる。
【００１９】
さらに本発明は、複数の前述したチーム−ビルディング・ブロックを包含し、その結果、各種構成のための好ましい作業グループサーバーアレーを構築して多数の独特な根源的機能を提供することができる。好ましいデータ構造およびデータ・フローに基づけば、これらの根源的な機能には、限定する意図ではないが、内部／外部コントロールされるタスク切り替え、作業グループ−ベースの装置共有、負荷バランス、障害迂回、モニタリングならびにマネジメント、セキュリティならびにパフォーマンス測定が含まれる。
【００２０】
本発明ならびにそれに関連するアーキテクチャは、不必要なネットワーク−アクセス−ベースのコンポーネントを除去し、それらを作業グループ−ベースのダイレクト−アクセス・コンポーネントに置き換え、それによって不必要なネットワーク・トラフィックを抑え、かつシングル−ポイント故障を低減することによって、従来のシングル−サーバー−ベースのアーキテクチャに内在する欠点を解決する。
【００２１】
さらに、固有のアプリケーションに基づく複数の作業グループサーバーアレーを作業グループサーバークラスターとして形成可能であり、その結果、その特定のアプリケーションに基づく、高いアベイラビリティならびにスケーラビリティを持ったミッション・クリティカルなウェブ・サービスへの適応が可能になる。それに加えて、複数の各種アプリケーション−ベースの作業グループサーバークラスターを、直列ならびに並列両方の態様において構成可能であり、広帯域のサービスの質（ＱＯＳ）を損なうこともなく非常に多くのユーザーに同時に適応するための大規模マルチ−アプリケーション・ウェブ−ベースのソリューションを提供することができる。
【００２２】
前述した本発明の特徴ならびに利点をはじめ、追加のその特徴ならびに利点は、以下の図面を参照した好ましい実施態様の詳細な説明を通じて、より完全に理解されることとなろう。
【００２３】
（好ましい実施態様の詳細な説明）
図１〜４に示した、作業グループサーバーアレー用の好ましいビルディングブロックとして使用されるチーム／作業グループコンピューターをベースにする本発明の好ましい実施態様を参照する。
【００２４】
チーム／作業グループコンピューターは、作業グループのピア−ツー−ピア・リンクを介して互いに作業グループ化されたコンピュータのグループであり、すべて作業グループサーバーリンクを介して多数のダイレクト−アクセス作業グループサーバーに接続することができる。その詳細については、本出願人による「ＳＩＮＧＬＥ ＣＨＡＳＳＩＳ ＭＵＬＴＩＰＬＥ ＣＯＭＰＵＴＥＲ ＳＹＳＴＥＭ ＨＡＶＩＮＧ ＳＥＰＡＲＡＴＥ ＤＩＳＰＬＡＹＳ ＡＮＤ ＫＥＹＢＯＡＲＤＳ ＷＩＴＨ ＣＲＯＳＳ ＩＮＴＥＲＣＯＮＮＥＣＴ ＳＷＩＴＣＨＩＮＧ ＦＯＲ ＷＯＲＫ ＧＲＯＵＰ ＣＯＯＲＤＩＮＡＴＯＲ（作業グループ・コーディネータのための相互接続切り替えを伴う分離されたディスプレイおよびキーボードを有する単一フレーム複数コンピューターシステム）」と題された特許第５，５３０，８９２号および本出願人による「ＤＩＲＥＣＴ−ＡＣＣＥＳＳ ＴＥＡＭ／ＷＯＲＫＧＲＯＵＰ ＳＥＲＶＥＲ ＳＨＡＲＥＤ ＢＹ ＴＥＡＭ／ＷＯＲＫＧＲＯＵＰＥＤ ＣＯＭＰＵＴＥＲＳ ＷＩＴＨＯＵＴ ＵＳＩＮＧ Ａ ＮＥＴＷＯＲＫ ＯＰＥＲＡＴＩＮＧ ＳＹＳＴＥＭ（ネットワーク・オペレーティング・システムを使用しないチーム／作業グループ化されたコンピュータによって共有されるダイレクト−アクセス・チーム／作業グループサーバー）」と題された特許第５，８０２，３９１号に記載されている。それに加えて、上記特許のいずれにも記述されているように、それらが同一の物理レイヤのケーブリングを使用し、修正ＳＣＳＩ（スカジー）等のストレージ−ベースならびに通信ベース両方のデータ・リンク・プロトコルを実行する能力を有する場合には、作業グループのピア−ツー−ピア・リンクおよび作業グループのサーバー・リンクを互いに接続することが可能である。これらの作業グループ化されたコンピュータは、そのそれぞれを以下において「チームプロセッサー」と呼ぶが、同一もしくは異なるＣＰＵ／ＯＳプラットフォームを基礎とし、またそれらのダイレクト−アクセス・サーバーは、そのそれぞれを以下において「チームサーバー」と呼ぶが、異なるオペレーティング・システムによってサポートされた同一のファイル・システムを用いてフォーマットすることができる。「チームサーバー」は、ディスク−ベース、テープ−ベース、および光学ベースのドライブを用いて実施することが可能なだけでなく、故障許容ディスク−アレーを用いて実施することができる。
【００２５】
特定のＯＳに基づく各「チームプロセッサー」は、その特定のＯＳ中心型の作業グループサーバーリンクのインターフェース・カード、つまり「チームサーバー」カードとともにインストールされ、すべての「チームサーバー」をダイレクト−アクセスのローカル・ドライブとして認識する。しかしながら、各「チームサーバー」は、ただ１つのプライマリ「チームプロセッサー」を有し、それが読み出し、書き込みおよびファイル生成に関して絶対的な優先権を持つ。さらに、１つの物理的ハードディスク・ドライブをはじめ、故障許容ディスクアレーは、パーティションを作成して複数の論理ドライブとしてフォーマットすることが可能であり、それぞれの論理ドライブを、それぞれ異なる「チームプロセッサー」をプライマリ・プロセッサーとしてコントロールすることができる。これらの「チームプロセッサー」がすべて内部ネットワークリンクに接続され、ネットワーク・オペレーティング・システムがインストールされている場合であっても、これらの「チームサーバー」は、「チームプロセッサー」全体を通じてネットワーク−アクセスが可能なドライブとしてマップされることがない。
【００２６】
さらに、以下において「チームプロ」コンピュータと呼ぶところの高度に統合されたチーム／作業グループコンピューターは、複数の「チームプロセッサー」を包含し、そのすべてが本出願人による「ＣＨＡＳＳＩＳ ＦＯＲ Ａ ＭＵＬＴＩＰＬＥ ＣＯＭＰＵＴＥＲ ＳＹＳＴＥＭ（複数コンピューターシステム用のフレーム）」と題された特許第５，５７７，２０５号に説明のあるように、１つの作業グループの「チームフレーム」内に収められている。「チームプロ」コンピュータは、さらにモニタリングおよびマネジメント装置、すなわち「チームパネル」を、１つのコンソール・モニタおよび１つのＲＡＰ（リモート−アクセス−ポート）ベースの装置を通じて各「チームプロセッサー」をコントロールし、それとインターフェイスするための手段として備えており、ＲＡＰベースの装置自体は、「ＳＩＮＧＬＥ ＣＨＡＳＳＩＳ ＭＵＬＴＩＰＬＥ ＣＯＭＰＵＴＥＲ ＳＹＳＴＥＭ ＨＡＶＩＮＧ ＳＥＰＡＲＡＴＥ ＤＩＳＰＬＡＹＳ ＡＮＤ ＫＥＹＢＯＡＲＤＳ ＷＩＴＨ ＣＲＯＳＳ ＩＮＴＥＲＣＯＮＮＥＣＴ ＳＷＩＴＣＨＩＮＧ ＦＯＲ ＷＯＲＫ ＧＲＯＵＰ ＣＯＯＲＤＩＮＡＴＯＲ（作業グループ・コーディネータのための相互接続切り替えを伴う分離されたディスプレイおよびキーボードを有する単一フレーム複数コンピューターシステム）」と題された特許第５，５３０，８９２号に記載されているように、２つのシリアル・ポート、１つのキーボード、１つのシステムＬＥＤ、１つのブザー、および１つのリセット・ボタンを備える。
【００２７】
図１Ａに示されるように、ＰＣ計算プラットフォームに基づく好ましいチーム／作業グループ・コンピュータ−ベースの「チームプロセッサー」は、概してワン−ウェイ、ツー−ウェイ、またはフォー−ウェイいずれかのＩｎｔｅｌ Ｐｎｅｔｉｕｍ（インテル・ペンティアム）ＣＰＵおよび１２８ＭＢのＲＡＭを実装したＷｉｎＮＴ（ウインドウズＮＴ）用ＰＣＩベースのマザーボード、フロッピーディスク・インターフェース・モジュール、ＩＤＥインターフェース・モジュール、ＶＧＡカード・モジュール、サウンド・カード・モジュール、ＵＳＢモジュール、パラレル・インターフェース・モジュール、ＲＡＰモジュール、イーサネットを使用するネットワークリンクＬＡＮモジュール、イーサネットを使用する作業グループ・ピア‐ツー−ピア・リンク・モジュール、ＳＣＳＩを使用する作業グループ・ピア‐ツー−ピア・リンク・モジュール、およびＳＣＳＩを使用する作業グループサーバーリンク・モジュールを包含している。さらに「チームプロセッサー」には、フロッピーディスク、ＩＤＥディスクおよび光ドライブ、ＶＧＡモニター、ＵＳＢベースのディジタル・カメラ、マウス、ネットワーク・イーサネット−ベースのハブおよびスイッチ、ＳＣＳＩディスク・ドライブおよびテープ・ドライブ、プリンターおよびスピーカーのセットといったモジュール−ベースの外部周辺ドライブおよび装置が備わっている。
【００２８】
図１Ｂに示すように、好ましい作業グループコンピューターのフレーム、つまり「チームフレーム」は、４つのＣＰＵカード−ベースの「チームプロセッサー」およびＩＤＥベースのディスクならびに光ドライブ、ＳＣＳＩドライブ等の多数のモジュール−ベースのドライブならびに装置、および「チームパネル」を収容する。同じ「チームフレーム」に、各種のモジュール−ベースのドライブおよび装置を伴う２つのマザーボード−ベースの「チームプロセッサー」を収容することもできる。さらに「チームフレーム」は、内部冗長電源、スマート電源マネジメント、熱交換可能なディスクおよびファン、および外部ＵＰＳを備えることができる。
【００２９】
作業グループ化して作業グループサーバーアレーを構成できる個別の「チームプロセッサー」の最大数は、内部作業グループサーバーリンクによって制限される。作業グループサーバーリンクがＳＣＳＩ−ＩＩを使用している場合には、適性なデータ転送が保証される有効長は６メートルであり、アタッチできるノードの数は１６までである。ここに少なくとも２つの「チームプロセッサー」を収容できる「チームフレーム」が使用されている理由があり、最初の「チームプロセッサー」が外部からのケーブルを拡張し、２番目のそれが外部接続用にケーブルを拡張することによって、より良好な作業グループ・ピア−ツー−ピア・リンク−ベースのＳＣＳＩケーブル・スキームがサポートされる。同一の「チームフレーム」に、ＳＣＳＩケーブルをさらに短くして４つのＣＰＵベースの「チームプロセッサー」を収容することもできる。現在のところ４つの異なるＳＣＳＩ標準が存在し、ＦＡＳＴ ＳＣＳＩ（ファースト・スカジー）から始まって、Ｕｌｔｒａ ＳＣＳＩ（ウルトラ・スカジー）、Ｕｌｔｒａ２（ウルトラ・ツー）ＬＶＤ ＳＣＳＩおよびＵｌｔｒａ３（ウルトラ・スリー）ＬＶＤ ＳＣＳＩまでである。それぞれの標準には、ナロー（８ビット）構成とワイド（１６ビット）構成の２つがある。したがって、好ましいＳＣＳＩの実施は、ケーブルを最長で１２メートルまで延ばすことができる最大データ・レートが１６０ＭＢ／秒のウルトラ−ワイドＬＶＤ ＳＣＳＩとなる。
【００３０】
図１Ｃは、好ましい作業グループ・リンク統合を示しており、これを参照すると８つの好ましい「チームプロセッサー」がＳＣＳＩを使用する作業グループ・ピア−ツー−ピア・リンクによってリンクされ、４つのＳＣＳＩハードディスク−ベースの「チームサーバー」がＳＣＳＩを使用する作業グループサーバーリンクによってリンクされている。これらの「チームプロセッサー」および「チームサーバー」は、同一のＳＣＳＩケーブルの使用により互いに接続されている。このようにすることによって、すべての「チームプロセッサー」が別の「チームプロセッサー」、特に絶対優先権を有するプライマリ「チームプロセッサー」を巻き込むことなくダイレクトに各「チームサーバー」にアクセスすることができる。この図１Ｃに示されるように、各ＳＣＳＩディスク−ベースの「チームサーバー」は、２つの論理ドライブを有し、各「チームプロセッサー」は、１つの論理ドライブに割り当てられ、絶対優先権を伴ってイネーブルされている。「チームサーバー」に対する別の非プライマリ「チームプロセッサー」によるアクセスは、読み出し専用の態様でのみ許可される。
【００３１】
さらに図１Ｃを参照すると、イーサネット・ハブを備える「チームリンク」カードを介してイーサネットを使用する作業グループ・ピア−ツー−ピア・リンクが示されており、ＳＣＳＩを使用する作業グループ・ピア−ツー−ピア・リンクが故障したとき、イーサネットを使用する作業グループ・ピア−ツー−ピア・リンクがそれに代わって通信を行い、あるいはその逆を行うことが可能になっている。イーサネットを使用する作業グループ・ピア−ツー−ピア・リンクを実施する主要な利点は、作業グループ内における「チームプロセッサー」間通信がネットワーク・トラフィックをはじめ、他の作業グループの「チームプロセッサー」間通信に悪影響を与えないことである。イーサネットを使用する作業グループ・ピア−ツー−ピア・リンクは、マップ済みドライブ−ベース、ソケット−ベース、およびセキュリティ暗号化／復号化ベースといった各種の「チームプロセッサー」間通信に適応できる。ＳＣＳＩ以外の等価ペリフェラル・バスについても、標準化されているかプロプラエタリであるかによらず、そのデータ−リンク・レイヤにストレージ−ベースのプロトコルおよび通信ベースのプロトコルを実施する能力がある限り、作業グループ・ピア−ツー−ピア・リンクおよび作業グループサーバーリンクを併合させることが可能な事実上のリンクとして採用することができる。しかしながら、構成によっては、作業グループサーバーリンクおよびイーサネットを使用する作業グループ・ピア−ツー−ピア・リンクが開設されている限り、適用可能なペリフェラル・バスのいずれかに基づく作業グループ・ピア−ツー−ピア・リンクが必要なくなることがある。
【００３２】
図１Ｄは、好ましいバージョンの「チームパネル」を示しており、そこには４つの基本コントロール・ユニットおよび１つのメイン・コントロール・ユニットが備わり、ＲＡＰ、ＶＧＡ、ＵＳＢおよびオーディオ・ポートを経由して最大で４つの「チームプロセッサー」が接続される。基本コントロール・ユニットは、１つのマイクロプロセッサーおよび、マイクロプロセッサーによってコントロールされて、別の基本コントロール・ユニットならびにメイン・コントロール・ユニットとリンクする共通のＶＧＡバス、オーディオ・バス、ＵＳＢバス上におけるＶＧＡ信号、オーディオ信号、およびＵＳＢ信号のフローを可能にする３つのスイッチが備わる。それに加えて、別の基本コントロール・ユニットおよびメイン・コントロール・ユニットに接続されているＩ²Ｃを使用する「チームパネル」ベースの通信リンクが備わり、また１０個のインターフェイス信号のセットがフロント・パネルに供給されている。
【００３３】
好ましいメイン・コントロール・ユニットは、故障許容用にデュアル・マイクロプロセッサーを備え、グループ化された「チームプロセッサー」間の作業グループ共有可能装置として分類されるキーボード、シリアル−ベースの装置およびプリンターを接続するための物理レイヤのインターフェイスを提供する。さらにメイン・コントロール・ユニットは、各作業グループ化された「チームプロセッサー」のバイタル・サイン、ＣＰＵ負荷およびアクティビティを追跡するための各種のステータス・テーブルをはじめ、共通バスおよびペリフェラル装置を監視するための使用テーブルを維持しており、これらのテーブルをチェックして衝突のある使用がないことを確認した後、「チームプロセッサー」からの要求の実行をシーケンシャルに許可することができる。
【００３４】
好ましいフロント・パネルは、２つのインタラクティブな押しボタンを備え、一方は、選択した「チームプロセッサー」による外部ＶＧＡベースのモニターの表示および外部キーボードならびにマウスのコントロールを選択するため、他方は選択した「チームプロセッサー」をリセットするために使用される。また、３セットのＬＥＤが備わり、それぞれは電源オン／オフ、プライマリ・システム・ディスクのアクティビティ、および選択のイネーブルを示す。「チームパネル」機能ボードおよびフロント・パネルのいずれも、「チームフレーム」内に収容されて、容易に配置できるケーブリング・スキームが工夫されている。
【００３５】
「チームパネル」をコントロールするデフォルトの「チームプロセッサー」を「チームマネジャー」と呼ぶ。「チームマネジャー」に対する作業グループの通信については、いずれの「チームプロセッサー」もまず、ＲＡＰのＣＯＭ２を介してそれにアタッチされたコントロール・ユニットにメッセージを送り、続いて当該コントロール・ユニットがＩ²Ｃプロトコル・ヘッダを用いてそのメッセージの再パックを行い、「チームパネル」のＩ²Ｃを使用する内部リンクを介してメイン・コントロール・ユニットに通知を行う。メイン・コントロール・ユニットがリンケージの発生を許可した後は、基本コントロール・ユニットによる「チームパネル」の内部Ｉ²Ｃリンクを介した「チームマネジャー」との直接的な通信が可能になり、それにより、たとえば、それにアタッチされた「チームプロセッサー」のカレント・ステータスをレポートすることができる。さらに、「チームパネル」の内部リンクを、ＳＣＳＩおよびイーサネットを使用する作業グループ・ピア−ツー−ピア・リンクに対する代替通信リンクとして使用することもできる。また障害迂回の目的を満たすときには、ＣＯＭ１ベースのマウス装置をＵＳＢベースのマウスに置き換える。つまり、ＲＡＰのＣＯＭ２が故障した場合には、ＲＡＰのＣＯＭ１に引き継ぎ、「チームプロセッサー」とそれにアタッチされた基本コントロール・ユニットの間のデータ通信を提供することができる。
【００３６】
図１Ｅは、２つの「チームパネル」を互いにカスケード接続して８つの好ましい作業グループ「チームプロセッサー」を接続した状態を示す。第１の「チームパネル」つまりＴＰ−４０８Ｍと第２の「チームパネル」つまりＴＰ−４０８Ｃは、共通ＶＧＡバス、オーディオ・バス、ＵＳＢバスおよびＩ²Ｃバスを介して接続されているが、ＴＰ−４０８Ｃにはメイン・コントロール・ユニットがなく、このためＴＰ−４０８Ｍ内に備わるメイン・コントロール・ユニットがＴＰ−４０８Ｃ内のすべての基本コントロール・ユニットを監視することになる。また第１の「チームパネル」をコントロールする「チームマネジャー」は、第２の「チームパネル」の「チームマネジャー」を兼ねる。「チームマネジャー」に対する通信については、第２の「チームパネル」のいずれの「チームプロセッサー」もまず、ＲＡＰのＣＯＭ２を介してそれにアタッチされたコントロール・ユニットにメッセージを送り、続いて当該コントロール・ユニットがＩ²Ｃプロトコル・ヘッダを用いてそのメッセージをパックしなおし、Ｉ²Ｃリンクを介して第１の「チームパネル」内のメイン・コントロール・ユニットに通知を行う。メイン・コントロール・ユニットがリンケージの発生を許可した後は、第２の「チームパネル」の基本コントロール・ユニットによる、「チームパネル」の内部Ｉ²Ｃリンクを介した第１の「チームパネル」の「チームマネジャー」との直接的な通信が可能になる。まったく同じシナリオに基づいて、任意の個別に構成された作業グループサーバーアレーへの適応が、単一「チームパネル」によって、あるいは互いにカスケード接続した複数の「チームパネル」によって得られる。各「チームパネル」のフロント・パネルは、各「チームフレーム」内に収容することも可能であるが、外部ボックスまで延長することも可能であり、その場合は複数の「チームパネル」のモニターおよびコントロールが容易になる。作業グループサーバーアレーのすべての「チームプロセッサー」を収容する複数の「チームフレーム」は、１つの「チームラック」内に収めることが可能であり、それにおいては、追加の「チームフレーム」内に追加の「チームサーバー」が収容可能であり、さらに、すべての「チームフレーム」間ケーブルをはじめ、すべての入りおよび出のケーブルを収容するケーブル分配ボックスを備えることができる。
【００３７】
図２Ａは、本発明システムの一実施態様に従った好ましい作業グループサーバーアレーを図示した機能ブロック図であり、８つの「チームプロセッサー」、４つのＳＣＳＩディスク−ベースの「チームサーバー」および２つのカスケード接続された「チームパネル」から構成され、それらが２つの「チームフレーム」に収容されており、さらにそれを１つの「チームラック」に収容することもできる。
【００３８】
図２Ｂは、本発明システムの一実施態様に従った好ましい作業グループサーバーアレーを図示した機能ブロック図であり、４つの「チームプロセッサー」、２つのＳＣＳＩディスク−ベースの「チームサーバー」および１つの「チームパネル」から構成され、それらが１つの「チームフレーム」に収容されており、さらにそれを１つの「チームラック」に収容することもできる。
【００３９】
図２Ｃは、本発明システムの一実施態様に従った好ましい作業グループサーバーアレーを図示した機能ブロック図であり、１２の「チームプロセッサー」、デュアルＳＣＳＩチャンネルを使用する作業グループサーバーリンクによってリンクされた６つのＳＣＳＩディスク−ベースの「チームサーバー」、および３つのカスケード接続された「チームパネル」から構成され、それらが３つの「チームフレーム」に収容されており、さらにそれを１つの「チームラック」に収容することもできる。
【００４０】
図３Ａは、図２Ａに示したような８つの「チームプロセッサー」を含む作業グループサーバーアレーを使用して各種の根源的な機能を実行するために設計された定義済みデータ・フローを伴う好ましい構成を図示している。この好ましい構成に基づけば、８つの「チームプロセッサー」を機能的に次の２つのグループに分類することができる：すなわち（１）アプリケーション／ファイル・サービス・プロセッサー（ＴＰ１〜ＴＰ４）；（２）データベース／ファイルサービス／負荷バランス／ファイアウォール・プロセッサー（ＴＰ５〜ＴＰ８）である。各「チームプロセッサー」は、ＳＣＳＩディスク‐ベースのプライマリ「チームサーバー」を有しており、そのそれぞれは、残り７つの「チームプロセッサー」に対して読み出し専用「チームサーバー」として動作させることが可能であり、以下においては、その場合の「チームサーバー」をセカンダリ「チームサーバー」と呼ぶ。つまり、ブート‐アップの間、各「チームプロセッサー」は１つのＩＤＥ−ベースのシステム・ドライブを認識するとともに、ＮＯＳマッピング・スキームを用いることなく作業グループのダイレクト−アクセス・サーバーとして機能する、１つのプライマリ「チームサーバー」および７つのセカンダリ「チームサーバー」を認識する。それに加えて、作業グループ化されたすべての「チームプロセッサー」によってアクセスされる上記のプライマリならびにセカンダリ「チームサーバー」は、複数の故障許容ディスクアレーおよび、２つのＳＣＳＩチャンネル上のトラフィックを分配するためのデュアル−チャンネル「チームサーバー」カードを用いても実施することができる。
【００４１】
アプリケーション／ファイル・サービス−ベースの「チームプロセッサー」ＴＰ１〜ＴＰ４は、それぞれインターネットからのＨＴＴＰ−ベースのアプリケーション指向ウェブ・クエリを処理してトランザクション・バッチ・ファイルを生成する能力を有し、それがシステムＩＤＥドライブおよびそのプライマリ「チームサーバー」の両方に書き込まれる。データベース／ファイル・サービス−ベースの「チームプロセッサー」ＴＰ５〜ＴＰ８は、それぞれイントラネットおよびエクストラネットからのＦＴＰベースまたはプロプラエタリのリアルタイムのソケット−ポート−ベースのデータベース指向ウェブ・クエリを取り扱い、システムＩＤＥドライブおよびそのプライマリ「チームサーバー」の両方に書き込まれることになるトランザクション・バッチ・ファイルを生成する能力を有する。
【００４２】
それとは別に、「チームプロセッサー」ＴＰ５およびＴＰ７は、それぞれのプライマリ「チームサーバー」上にインストールされるアプリケーション固有作業グループデータベースをそれぞれ維持している。これら２つのデータベースは、基本的に、その日の最後には同一になる。ＴＰ５によってコントロールされるデータベースは、その日の間において、所定の時間周期（ｔ）内に「チームサーバー１」〜「チームサーバー４」から生成された各バッチ・トランザクション・ファイルに基づいて更新される。ＴＰ７によってコントロールされるデータベースは、その日の最後において、その日の間に「チームサーバー１」〜「チームサーバー４」から生成されたすべてのバッチに基づいて更新される。ＴＰ６は、主としてイントラネットからのＦＴＰベースのデータベース指向ウェブ・クエリを取り扱い、その結果、ＴＰ５による「チームサーバー６」からの検索およびｔ時間周期ごとのデータベースの更新が可能になる。またＴＰ５は、イントラネットからの、プロプラエタリのリアルタイムのソケット−ポート−ベースのデータベース・クエリがあると、直ちにデータベースを更新する。ＴＰ８は、デフォルトの「チームプロセッサー」、つまりこれら２つの「チームパネル」をコントロールする「チームマネジャー」になる。
【００４３】
好ましいサーバー−ペア構成を基礎とすることによって、以下においてＷＳＡと呼ぶ、発明性の作業グループサーバーアレー用の多数の独特な機能的サービスを生み出すことが可能になる。
【００４４】
ＷＳＡサーバーの調和およびスーパーバイザリ・サービスについての好ましい方法の１つは、「チームマネジャー」（ＴＰ８）が作業グループ化されたすべての「チームプロセッサー」を調和させ、マネジメント−ベースのアクティビティを生成するという形で実施することができる。このアクティビティには、各「チームプロセッサー」上にインストールされたＯＳによって生成することができる各「チームプロセッサー」のインベントリ、ディスク・スペースおよびＣＰＵ使用のモニターをはじめ、作業グループ化された「チームプロセッサー」のそれぞれにおいて生じ得る侵入、削除および故障の警告が含まれる。各「チームプロセッサー」は、恒常的にマネジメント−ベースのステータス情報をパックし、それをＲＡＰのＣＯＭ２を介してそのコントロール・ユニットに渡し、コントロール・ユニットは、メイン・コントロール・ユニットに通知を行った後、「チームパネル」のＩ２Ｃリンクを介した、メイン・コントロール・ユニットからのインストラクションを送るためのＯＫを待機する。ＯＫ信号が受信されると、この特定の「チームプロセッサー」による、そのコントロール・ユニットから「チームマネジャー」のコントロール・ユニットへのダイレクト通信が可能になり、続いてＲＡＰのＣＯＭ２を介して「チームマネジャー」にステータス情報が送られる。「チームマネジャー」は、常時、作業グループ化されたすべての「チームプロセッサー」に関するマネジメント−ベースのステータス・テーブルを維持している。
【００４５】
ＷＳＡの内部フロント・パネル切り替えサービスに関係する好ましい方法の１つは、それ自体もしくは任意の「チームプロセッサー」からの、特定の「チームプロセッサー」がまだ機能しているか否かのチェックを求める要求があったとき、「チームマネジャー」がメイン・コントロール・ユニットにその要求を送り、それがさらに診断要求をその特定の「チームプロセッサー」に送るという形で実施することができる。応答がなければ、メイン・コントロール・ユニットは「チームマネジャー」のコントロール・ユニットに対して通知を送り、そこからＲＡＰのＣＯＭ２を経由して「チームマネジャー」にその通知が送られる。その後「チームマネジャー」は、ネットワークリンクを介してＬＡＮベースのマネジメント・コンソールにアラーム・メッセージを送り、オペレータからの応答を待機する。オペレータは、「Ｃａｒｂｏｎ−Ｃｏｐｙ（カーボン−コピー）」または類似のソフトウエアを起動することによってマネジメント・コンソール・コンピュータを介して「チームマネジャー」のコントロールを引き継ぐことができる。それとは別に、「チームマネジャー」にはビデオ・キャプチャ・カードが備わり、共通ＶＧＡバスがＮＴＳＣコンバータに接続されているので、任意の「チームプロセッサー」のＶＧＡ表示を「チームマネジャー」のＶＧＡ表示内に再取り込みすることができる。したがってメイン・コントロール・ユニットに対して「選択」要求を送ることによって、「チームマネジャー」に、故障した「チームプロセッサー」のスクリーン表示を取り込むべくインストラクションを与えることが可能であり、それによって、続いて行われる「チームマネジャー」のコントロール・ユニットから故障した「チームプロセッサー」のコントロール・ユニットへの通信が可能になる。オペレータから故障した「チームプロセッサー」にキーボード入力を送り、それに応じた動作を得て、その後の解析のために「チームマネジャー」上に診断ファイルを保存することもできる。故障した「チームプロセッサー」をリセットするべきであるとオペレータが判断した場合には、故障した「チームプロセッサー」のコントロール・ユニットに「リセット」コマンドを送るように「チームマネジャー」に対してインストラクションを与える。その結果、この特定のコントロール・ユニットは、故障した「チームプロセッサー」に直接リンクされているリセット・ラインをトリガし、それをリセットする。ブート−アップ・プロセスは、「チームマネジャー」上での取り込み、表示および保存が可能であり、それによってオペレータは、リモート・マネジメント・コンソール・コンピュータのある場所において、ステップごとにブート−アップ・プロセスを監視し、インタラクションすることができる。それに加えて、技術要員は、保存済みの診断ファイルに基づいてさらに解析を行い、問題箇所を判断して解決策を引き出すができる。
【００４６】
ＷＳＡの現場フロント・パネル切り替えサービスに関係する好ましい方法の１つは、ＶＧＡモニター、スピーカーのセット、キーボードおよびマウスといった「チームパネル」ベースの作業グループ装置を使用したいずれかの「チームプロセッサー」の監視、コントロールおよびリセットのための、ローカルの現場オペレータによる「チームフレーム」上のフロント・パネルの使用を可能にする形で実施することができる。パネル上の「選択」および「リセット」に関する押しボタン信号は、メイン・コントロール・ユニットに直接リンクされており、メイン・コントロール・ユニットは、いずれかの押しボタン要求があると、該当するときにはまず、使用テーブルをチェックして衝突する使用がないことを確認し、関連するＬＥＤを点滅させる。押しボタンによるアクティブ化の意図がある場合には、ローカルのオペレータがそのボタンをさらに１回押してアクションをトリガすればよく、それにより関連するＬＥＤがオンにセットされる。アクションが完了した後は、関連するＬＥＤがオフにセットされる。
【００４７】
ＷＳＡのリモート・フロント・パネル切り替えサービスに関係する好ましい方法の１つは、任意のリモート・コンピュータによって、暗号化されたプロプラエタリのアクセス・コードに基づく作業グループ−ベースのシリアル・リンクにアタッチされた外部モデムを介して、「チームマネジャー」もしくはいずれかの「チームプロセッサー」のコントロールを引き継ぐことを可能にする形で実施することができる。この通信が開設された後は、リモート・コンピュータが、ＬＡＮベースのマネジメント・コンソール・コンピュータとまったく同じに、すべての機能を実行することができる。
【００４８】
ＷＳＡの装置共有サービスに関係する好ましい方法の１つは、「チームマネジャー」ならびに他の任意の「チームプロセッサー」によるＷＳＡ内の周辺装置のアクセスを可能にする形で実施することができる。特定の「チームプロセッサー」がいずれかの周辺装置、たとえばプリンターへのアクセスを必要としているとき、その「チームプロセッサー」が、ＲＡＰのＣＯＭ２を介して要求メッセージをそのコントロール・ユニットに送ると、そのコントロール・ユニットが内部Ｉ²Ｃリンクを介してメイン・コントロール・ユニットに要求を送る。ステータス・テーブルおよび使用テーブルのチェックの後、使用可能であればメイン・コントロール・ユニットは、続いて行われるその特定のコントロール・ユニットからメイン・コントロール・ユニットへの通信を許可し、さらにメイン・コントロール・ユニットは、ビルトインのパラレル・インターフェースを介してデータをアタッチされたプリンターに中継する。別のシリアル・ポート装置用に同様のプロセスを実施することもできる。しかしながらＵＳＢ装置の場合は、特定の「チームプロセッサー」が、そのコントロール・ユニットにＲＡＰのＣＯＭ２を介して要求を送り、それをそのコントロール・ユニットがメイン・コントロール・ユニットに送る。ＵＳＢ装置用の使用テーブルをチェックした後、使用可能であれば、メイン・コントロール・ユニットからそのコントロール・ユニットにＯＫ信号が返され、それがボード上のＵＳＢスイッチをオンにする。このようにすれば、その特定の「チームプロセッサー」上のＵＳＢインターフェイスに、共通ＵＳＢバスを介してビデオ・カメラ等の作業グループ−ベースのＵＳＢ装置を直接接続することが可能になる。
【００４９】
ＷＳＡの障害迂回スキーム−ベースのサービスに関係する好ましい方法の１つは、「チームフレーム」、「チームパネル」、「チームプロセッサー」、「チームサーバー」等のＷＳＡ内のミッション・クリティカルなコンポーネントの故障許容あるいは障害迂回を可能にしてミッション・クリティカルなアプリケーションが中断しない形で実施することができる。
【００５０】
「チームパネル」については、ミッション・クリティカルな機能がデュアル・マイクロプロセッサーを備えるそのメイン・コントロール・ユニットに関係しており、そのため最初の１つが故障しても次のプロセッサーがそれを引き継いで「チームマネジャー」にアラームを送ることが可能であり、さらにそれからマネジメント・コンソールに通知することができる。「チームフレーム」については、デュアル電源および外部ＵＰＳを備えていることから故障許容である。「チームプロセッサー」については、４つの障害迂回用グループ、すなわちＴＰ１およびＴＰ２、ＴＰ３およびＴＰ４、ＴＰ５およびＴＰ６、ＴＰ７およびＴＰ８があり、各グループのメンバは他と同一のハードウエア構成を有している。つまり、各グループ内において一方が故障しても、他方がそれを引き継ぐことができる。したがって、たとえば「チームマネジャー」ＴＰ８が故障した場合には、ＴＰ７がそれを引き継いで「チームマネジャー」として機能する。さらに、ＴＰ１およびＴＰ２からなるペアとＴＰ３およびＴＰ４からなるペアは、ともに障害迂回用のグループである。また、ＴＰ５およびＴＰ６からなるペアとＴＰ７およびＴＰ８からなるペアも障害迂回用のグループである。したがって、ＴＰ１とＴＰ２のペアが故障した場合にはＴＰ３とＴＰ４のペアがそれを引き継ぎ、逆の場合には逆の引き継ぎが行われる。ＴＰ５およびＴＰ６からなるペアとＴＰ７およびＴＰ８からなるペアについてもまったく同じシナリオを適用できる。
【００５１】
ファイル−サービス−ベースの「チームサーバー」については、８つの障害迂回用グループ、すなわち「チームプロセッサー１」のＩＤＥ１と「チームサーバー１」、ＩＤＥ２と「チームサーバー２」、ＩＤＥ３と「チームサーバー３」、ＩＤＥ４と「チームサーバー４」、ＩＤＥ５と「チームサーバー５」、ＩＤＥ６と「チームサーバー６」、ＩＤＥ７と「チームサーバー７」、ＩＤＥ８と「チームサーバー８」である。したがって、「チームサーバー１」が故障しても、他の「チームプロセッサー」は「チームプロセッサー１」からＩＤＥ１の情報を取り出すことができる。ＩＤＥ１が故障した場合に他の「チームプロセッサー」は、「チームサーバー１」から情報を直接取り出すことができる。これと同じシナリオが、残り７つの障害迂回用グループにも適用される。データベース−サービス−ベースの「チームサーバー」については、「チームサーバー５」上のデータベースがＴＰ５によってコントロールされ、「チームサーバー７」上のデータベースがＴＰ７によってコントロールされており、前述したように、これらは基本的に同じアプリケーション固有のデータベースである。しかしながら、データベースとＴＰ５のペアが故障すると、データベースとＴＰ７のペアが直ちに、「チームサーバー１」から「チームサーバー８」に収集された関連するすべてのバッチファイルに基づいて「チームプロセッサー７」によって更新され、瞬時にサービスの準備が整う。
【００５２】
ＷＳＡのアプリケーション−ベースの負荷バランス・サービスに関係する好ましい方法の１つは、「チームパネル」を使用することによってＷＳＡ内のアプリケーション−ベースの「チームプロセッサー」の負荷バランスが得られるような形で実施することができる。ウェブ−ベースの環境においては、アプリケーション−ベースであり、かつクエリ−ベースである要求がＨＴＴＰプロトコルを使用するインターネットから到来する。到来したクエリ−ベースのトラフィックは、まずルータを通る。続いてこのルータは、すべての要求を「チームマネジャー」ＴＰ８に渡す。その後「チームマネジャー」は、到来するトラフィック負荷を内部ＦＴＰポートまたはプロプラエタリ・ポートを通じ、イーサネットを使用する作業グループ・ピア−ツー−ピア・リンクを介してＴＰ１、ＴＰ２、ＴＰ３、およびＴＰ４に分配することができる。ラウンド−ロビンの実施においては、各アプリケーション−ベースの「チームプロセッサー」のＣＰＵ使用および応答時間に基づいて、「チームマネジャー」（ＴＰ８）がラウンド−ロビン−ベースの負荷バランス・ステータス・テーブルを維持し、「チームパネル」のメイン・コントロール・ユニットが各種のバイタル・サイン・ステータス・テーブルを維持している。
【００５３】
作業グループ化されたいずれの「チームプロセッサー」の場合にも、それにアタッチされているコントロール・ユニットに対し、ＲＡＰのＣＯＭ２を介して恒常的にバイタル・サインおよびそれに類似の信号が送られることから、コントロール・ユニットは、そのデータをパックしなおしてメイン・コントロール・ユニットに通知する。メイン・コントロール・ユニットがリンケージの発生を許可した後は、基本コントロール・ユニットがこのデータをメイン・コントロール・ユニットのメモリ・バッファ内にダウンロードすることが可能になり、それを各種のバイタル・サイン・ステータス・テーブルに割り当てることができる。これらのリアルタイム・ステータス・テーブルに基づいて、メイン・コントロール・ユニットは、故障が発生したか、あるいは過負荷となっている「チームプロセッサー」を検出することができる。これらのいずれかの状況が発生すると、メイン・コントロール・ユニットは、それを「チームマネジャー」にレポートする。過負荷状態の場合には、「チームマネジャー」は、直ちにラウンド−ロビン・シーケンスからの懸案の「チームプロセッサー」の除外を試み、メイン・コントロール・ユニットから、その特定の「チームプロセッサー」を再度ラウンド−ロビン・シーケンスに戻すことに関連した通知を再び受け取るまでそれを継続する。また、故障状態の場合においては、「チームマネジャー」が、作業グループ・ピア−ツー−ピア・リンクを介して懸案の「チームプロセッサー」との通信リンクの開設を試みる。応答がなければ、「チームマネジャー」からメイン・コントロール・ユニットに、ＲＡＰの「リセット」ラインを介した「チームプロセッサー」のリセットを通知し、その結果、部分的もしくは完全な回復および、それに従った動作がもたらされる。
【００５４】
ラウンド−ロビン方式に加えて、「最少オープン接続」、「最短測定時間または応答時間」、「コンテンツ・タイプ」、「オープン接続数」といった別のインテリジェントアルゴリズムおよびアプリケーション・サーバーから収集されるその他の統計も利用することができる。「チームマネジャー」ＴＰ８は、作業グループ・ピア−ツー−ピア・リンクを介してこれらのタイプの情報を１つずつ収集し、故障した「チームプロセッサー」（１ないしは複数）を検出することが可能であることから、１つの特定の「チームプロセッサー」における過負荷を招くことなく、また故障した「チームプロセッサー」に負荷を渡すことなく各種のアルゴリズムをインテリジェントに実施することが可能になる。しかしながら、すべての「チームプロセッサー」の種類が同一であり、「チームマネジャー」が異常状態に基づく「チームパネル」のメイン・コントロール・ユニットからのインストラクションに応答するだけでよいときには、ラウンド−ロビン・アルゴリズムが最良の選択肢となり得る。
【００５５】
ＷＳＡのファイルサービスおよびデータベースサービスに関係する好ましい方法の１つは、個々の「チームサーバー」上のファイルおよびデータベースに対して、「チームプロセッサー」から直接的にアクセスし、それらの間で共有できるようにする形で実施することができる。これは、ダイレクト−アクセス−ベースのセカンダリ「チームサーバー」用の「チームプロセッサー」に、それと同数の読み出し専用データベース・エンジンをインストールし、プライマリ「チームプロセッサー」に完全なデータベース・エンジン、つまり、そのプライマリ「チームサーバー」上のデータベースに対して適用される絶対的な優先権を有することができるデータベース・エンジンをインストールすることによって達成される。それに加えて、「チームマネジャー」（ＴＰ８）は、アタッチされたすべてのファシリティに関する一連のステータス・テーブルおよび使用テーブルを維持している。これらのテーブルの１つは、すべての「チームサーバー」上において二重書き込みによるデータの完全性の喪失が回避されるように、各「チームサーバー」のプライマリ「チームプロセッサー」の同時発生リストを維持している。しかしながら、個々の「チームサーバー」のプライマリ「チームプロセッサー」は、いずれも、障害迂回、異なる時間ゾーンにおける異なるオペレーション・ニーズ、アップグレードのための一時的なスーパーバイザリの変更等があったとき、別の「チームプロセッサー」に変更することが可能である。「チームマネジャー」は、常に、所定の時点において特定の「チームサーバー」を更新できる「チームプロセッサー」が１つだけとなることを保証する。
【００５６】
ＷＳＡのセキュリティ・サービスに関係する好ましい方法の１つは、ＷＳＡへの許可のない侵入を検出する形で実施することができる。「チームマネジャー」ＴＰ８は、到来するすべての要求を受け取り、「チームプロセッサー」の間に負荷を分配することから、「チームマネジャー」にセキュリティ強化をおよびファイアウォール機能をインストールし、潜在的な外からの攻撃を防ぐことが必須になる。基本的に「チームマネジャー」ＴＰ８は、ＳＳＬベースまたはＯＳベースもしくはより高レベルのアプリケーション−ベースのアクセス暗号化セキュリティ測定を実施して、正当な要求を、イーサネットを使用する作業グループ・ピア−ツー−ピア・リンクを介してアプリケーション−ベースの「チームプロセッサー」にリダイレクトし、到来した要求を２つの異なるセキュリティ−ベースのゾーンに分離することによって疑問のある要求をフィルタ・アウトすることができる。各アプリケーション−ベースの「チームプロセッサー」は、アプリケーション固有のデータベースに対するアクセスを包含することがある応答を見つけ出し、コンテンツ暗号化のセキュリティ基準を用いて適正な内部ＩＰアドレスを含めることによって、それを要求元に返す。これにより「チームマネジャー」はコンテンツを復号し、直前の要求を扱った適正な「チームプロセッサー」にそれをリダイレクトすることができる。このタイプの粘着性のポート・アプローチは、ソースＩＰアドレス等のファクタおよびユーザー認証装置の要求プロトコルまたは返されたクッキーに含まれる特殊な情報に基づいた持続型セッションとして知られ、安全に実施することが可能であり、ウェブ−ベースの電子商取引アプリケーション・サービスを効率的に行う上で欠くことができない。
【００５７】
ＷＳＡの障害迂回サービスに関係する好ましい方法の１つは、多数のエージェント−ベースのマネジメント・ソフトウエア、つまり「チームソフト」を作成し、好ましい構成の定義済みデータ構造ならびにデータ・フローに基づいた上記の機能的サービスをすべて統合する形で実施することができる。現在の「チームマネジャー」のみが「チームソフト」のサーバー部分にインストールされ、残りの「チームプロセッサー」は「チームソフト」のクライアント部分にインストールされることになる。アクティブになっている「チームプロセッサー」が１つある間は、リモート・マネジメント・コンソール・コンピュータは、その「チームプロセッサー」をコントロールし、それを「チームマネジャー」として機能させることが可能であり、その結果、故障した「チームプロセッサー」があればそれをリブートして、本発明の作業グループサーバーアレーを正常機能に戻すことができる。「チームソフト」障害迂回機能に基づけば、各「チームプロセッサー」が、「チームマネジャー」を介して障害迂回用ペアの他方が生きているか否かについての検出を起動することができる。生きていなければ「チームプロセッサー」は、故障した他方がサービスを提供していたタスクを引き継ぐ。たとえば、ＴＰ５が故障したとすると、ＴＰ６に対して「チームマネジャー」が、「チームサーバー５」の優先権およびデータベースを更新するタスクを割り当てる。ＴＰ６が故障した場合には、ＴＰ５に対して「チームマネジャー」が、「チームサーバー６」の優先権を割り当て、ＴＰ６用のＩＰアドレスに代えてＴＰ５用のＩＰアドレスを用いて到来した要求を通知することによって、ＴＰ６のトラフィックをＴＰ５にリダイレクトする。また「チームソフト」には、自動修正アクションが組み込まれた作業グループ用の問題診断も含まれている。
【００５８】
ＷＳＡのパフォーマンス測定サービスに関係する好ましい方法の１つは、いくつかの主要パラメータの値を調整することによってＷＳＡにおける最適パフォーマンスの達成が可能になる形で実施することができる。本発明の作業グループサーバーアレーのパフォーマンスは、次の３つのファクタに基づいて決定される：すなわち（１）「チームマネジャー」のファイアウォール・オペレーション、（２）アプリケーション‐ベース「チームプロセッサー」の数、および（３）アプリケーション固有データベースのサイズである。「チームマネジャー」ＴＰ８にファイアウォール・オペレーションがインストールされている場合には、コンテンツ復号セキュリティおよび上位レイヤ・アクセス‐ベースのセキュリティを満たすための時間が過大になり、１分当たりの到来要求の数が減少する。しかしながら、この問題は、ネットワーク・レイヤのフィルタリングおよび上位レイヤのフィルタリングを実行することができるファイアウォール−ベースのルータをアタッチすることによって解決される。
【００５９】
アプリケーション−ベースの「チームプロセッサー」の数が減少すると、１分当たりに送り出される応答の数が減少する。データベースについての考察と同様に、アプリケーション中心型のデータベースが非ロイヤルティ・トラフィックに基づいて構築されている場合には、場合によっては非ロイヤルティ・ベースのトラフィックを満たすために増加することがあるレディメードの情報だけを供給する傾向が生じる。その逆に、ロイヤルティ・トラフィックに基づいて構築されている場合には、データベースが格段に大きくなる。しかしながら、応答ページを形成するためにデータベースからデータを検索するときに要する時間は、別の「チームプロセッサー」に依存することなく「チームサーバー」上のデータベースに容易にアクセスできることから問題とならない。
【００６０】
したがって、２つのシナリオが存在することになる：すなわち（１）非ロイヤルティ・アプリケーション−ベース、および（２）ロイヤルティ・アプリケーション−ベースである。非ロイヤルティ−ベース状況下においては、本発明の作業グループサーバーアレーの最適パフォーマンスが、アプリケーション−ベースの「チームプロセッサー」の数に依存する。計算パワーおよびサービスの複雑度に基づき、１つの「チームプロセッサー」が、送出する応答を抑え、許容可能なサービスの質（ＱＯＳ）と考えられるサービスを低下させることなく処理することができる到来する要求の数はＸである。つまり、４つの「チームプロセッサー」は、安定状態のオペレーションにおいて、到来する４Ｘ個の要求に適応することができる。ピーク時の非ロイヤルティ・トラフィックが６Ｘに跳ね上がったとしても、本発明の作業グループサーバーアレーは、ＴＰ６およびＴＰ７をアプリケーション−ベースの「チームプロセッサー」に割り当て、「チームマネジャー」によって運用されるラウンド‐ロビン負荷バランス・アルゴリズムに加えることによって、ピーク時のオペレーションに適応することができる。
【００６１】
さらに、図２Ｃに示した１２個の「チームプロセッサー」をベースにする作業グループサーバーアレーにおいては、１２個のうち８個がアプリケーション−ベースの「チームプロセッサー」であり、安定状態のオペレーションにおいて８Ｘ個の非ロイヤルティ・トラフィックに適応し、ピーク時オペレーションにおいては１０Ｘ個のトラフィックに適応することができる。ただし到来するトラフィックが１０Ｘ個を超える場合には、第２の作業グループサーバーアレーが必要になる。
【００６２】
ロイヤルティ−ベース状況下においては、本発明の作業グループサーバーアレーの最適パフォーマンスが、アプリケーション−ベースの「チームプロセッサー」の数およびロイヤルティ−ベースのデータベースのサイズに依存する。このデータベースのサイズが過度に大きく、到来する要求がすべての「チームプロセッサー」が扱うことができる数を超えて生成された場合には、データベースのサイズを縮小して安定状態のオペレーション要件を満たす必要があり、超過分については第２の作業グループサーバーアレーに移す必要がある。たとえば１２個の「チームプロセッサー」をベースにする作業グループサーバーアレーは、８Ｘ個のロイヤルティ・トラフィックに適応できるが、それは、アプリケーション中心データベース上にインストール可能なロイヤルティ−ベースのユーザー数Ｙに転化することができる。ピーク時の状況下において、Ｙ人のユーザーが１０Ｘ個のロイヤルティ−ベースのトラフィックを生成しても、許容可能なＱＯＳを満たすことができる。
【００６３】
本発明の作業グループサーバーアレーは、常にＸおよびＹの数の再調整を行い、「チームマネジャー」によって収集された情報に基づいて許容可能なサービスの質を確保している。つまり、本発明の作業グループサーバーアレーに関するパフォーマンス測定値は、パラメータＸおよびＹとなり、最適動作ポイントをはじめ、リソースの増加を必要とする問題の予測を導くことができる。
【００６４】
より高い帯域幅のアプリケーションについては、サービスの程度が高くなり、それによってＸおよびＹの数が下がることが考えられる。しかしながら、本発明の作業グループサーバーアレーのＱＯＳが損なわれることはない。
【００６５】
ロイヤルティ−ベースのシナリオにおいて、より多くの到来する同一アプリケーションの要求に適応するため、図３Ｂに、それぞれが相互排他のデータベース・セグメントを有する複数のシングル−アプリケーション−ベースの作業グループサーバーアレーからなる作業グループサーバークラスターを示す。それぞれの作業グループサーバーアレーがＱＯＳを満たすことから、全体的な作業グループサーバークラスターもまたＱＯＳ適合である。
【００６６】
このようにして、第１の作業グループサーバーアレーからｎ番目の作業グループサーバーアレーまでを含む作業グループサーバークラスターによって、アベイラビリティならびにスケーラビリティの高い、ミッション・クリティカルなアプリケーションに適応することが可能になる。これがロイヤルティ−ベースであることから、ルータは、適正なＩＰアドレスに基づいて適正な到来トラフィックを適正な「チームマネジャー」に直ちに分配することが可能であり、この情報は、それらのブラウザの「クッキー」内、あるいはネットワーク・アクセスおよびユーザー認証に使用可能なチップ−ベースのスマート・カード内のいずれかにインストールされている。
【００６７】
非ロイヤルティ−ベースの状況については、ルータは、ＵＲＬをＩＰアドレスに変換するドメインネームサーバー（ＤＮＳ）とともに、組み込みラウンド−ロビン機能を使用することによって、到来する負荷を非ロイヤルティ−ベースの作業グループサーバークラスターの複数の「チームマネジャー」に分配することができる。これを行う間に、非ロイヤルティ−ベースのトラフィックのための負荷バランスが実施され、この場合にもＱＯＳが損なわれることがない。作業グループ・サーバー・クラスタ−ベースの負荷バランスだけでなくラウンド−ロビン−ベースのＤＮＳに基づいたこの独特な方法は、すべてのウェブ・アプリケーションをマネージし、負荷バランスを得るだけの充分なパワーが要求され、階層間ネットワーク・スイッチの過負荷を招く不必要なネットワーク・トラフィックを生み出していたグローバルな負荷バランサを不要にするという明確な利点をもたらす。さらに、いずれかの「チームマネジャー」が故障した場合には、ＤＮＳからその「チームマネジャー」の障害迂回用ペアの他方にメッセージが送られ、ＤＮＳが、「チームマネジャー」のＩＰアドレスと障害迂回用の他方のＩＰアドレスをともに通知することから、それに対する割り当てが自動的に行われて、ＤＮＳから到来するトラフィックの引き継ぎ、および処理が行われる。
【００６８】
ロイヤルティ−ベースおよび非ロイヤルティ−ベースのシナリオのいずれについても、ウェブ−ベースのアプリケーションが良好に定義されており、それに関連付けされたデータベースもまた良好に定義されているはずであることから、データベース・サーバー・プログラムは、複雑なインテリジェンスを組み込む必要がなく、高速かつ実行がシンプルである必要がある。データベース検索に要する時間は、ＸおよびＹを大きな数とし、より良好なパフォーマンスを得るためにも、可能な限り短くあるべきである。
【００６９】
ユーザー／サーファから到来する要求が多くの異なるウェブ−ベースのアプリケーションに関係すると考えられることから、複数の異なるアプリケーション−ベースの作業グループサーバークラスターをインストールする必要がある。図４は、アベイラビリティならびにスケーラビリティの高いミッション・クリティカルなイントラネット、エクストラネット、インターネットアプリケーションのための包括的なウェブ−サーバーの実施態様であり、直列および並列に連鎖させた複数の作業グループサーバークラスターが統合されて、理想的かつ安全な分散コンピューティング環境が作られている。
【００７０】
ファイアウォール・ベースの作業グループサーバーアレーを使用するゾーン−ベースのセキュリティに加えて、異なる作業グループサーバークラスターの間における相互通信を、ＳＳＬベース、ＯＳベース、またはアプリケーション−ベースのコンテンツおよびアクセス・セキュリティを伴うプロプラエタリ・ポートを使用することによって安全に実施することが可能であり、その結果、作業グループサーバークラスターのいずれに対するアクセスが、いかなる外来通信にも許されない。
【００７１】
さらに、ＦＣ−ＡＬまたは類似のリンクをすべての「チームマネジャー」のリンクに使用することによって、各作業グループサーバーアレーの「チームサーバー」を、ハードディスク−ベース、テープ−ベースあるいは光ディスク−ベースであるかによらず、すべてＦＣデバイスに変換することが可能になり、続いてそれを、ＳＡＮ（ストレージ・エリア・ネットワーク）ベースのバックエンド・データベース・プロセッサーのいずれかを用いてアクセスし、維持することができる。このようにすると、バックエンド・データ中心のＳＡＮベースの高度なファイル・サーバーならびにデータベースサーバー用の、あらゆる作業グループサーバーアレーのアプリケーション中心型ファイルおよびデータベースサーバーまたはデータ・キャッシング・サーバーに、よりインテリジェントなデータベース・エンジンが備えられることになる。
【００７２】
結論を述べれば、本発明は、次のような独特なコンポーネントを具体化する：すなわち（１）「チームプロセッサー」、（２）「チームサーバー」および「チームサーバー」カード、（３）「チームパネル」、（４）「チームリンク」カード、（５）「チームフレーム」、および（６）「チームラック」である。これらの独特なコンポーネントに基づき、本発明は、多くの独特な方法を採用して好ましい作業グループサーバーアレーを構成する。すなわちそれは、（１）ＷＳＡのサーバー−ペア方法、（２）ＷＳＡのマルチ作業グループ・リンク方法、（３）ＷＳＡのサーバー調整およびスーパーバイザリ方法、（４）ＷＳＡの内部、現場およびリモート「フロント・パネル」切り替え方法、（５）ＷＳＡの装置共有方法、（６）ＷＳＡのフェイル−セーフおよび回復方法、（７）ＷＳＡの負荷バランス方法、（８）ＷＳＡのファイル／データベース共有方法、（９）ＷＳＡのセキュリティ−ベースの方法、（１０）ＷＳＡの「チームソフト」ベースのマネジメント方法、および（１１）ＷＳＡの最適パフォーマンス測定方法である。さらに、これらの発明性の作業グループサーバーアレーに基づいて、本発明は多数の独特な方法を採用して好ましい作業グループサーバークラスター（ＷＳＣ）を構築した。すなわちそれは（１）ＷＳＣの構成方法、（２）ＷＳＣの負荷バランス方法、（３）ＷＳＣのキャッシュ中心型データベース方法、（４）ＷＳＣのユーザー認証ロイヤルティ中心型の作業グループデータベース方法である。最後に、これらの発明性の作業グループサーバークラスターに基づき、本発明は、多数の独特な方法を使用して好ましい「フロント−オフィス」ウェブ−ベースのサーバー・ファームを構築した。すなわちそれは（１）複数ＷＳＣの直列連鎖方法、（２）複数ＷＳＣの並列連鎖方法、（３）直列連鎖および並列連鎖による複数ＷＳＣをストレージ・エリア・ネットワーク（ＳＡＮ）を用いてリンクする方法である。
【００７３】
以上から本発明が、作業グループサーバーアレーおよび、安全な分散コンピューティング環境において、アベイラビリティならびにスケーラビリティが高く、ミッション・クリティカルなサーバークラスターを構築するための、その関連アーキテクチャを提供することが理解されよう。
【００７４】
当業者であれば、追加の利点ならびに修正が容易に明らかなものとなろう。したがって、本発明のより広い側面が、ここに示し、説明した具体的な詳細、代表として表した装置、および説明用の例に限定されることはない。換言すれば、出願人の包括的な発明思想の真意ならびに範囲から逸脱することなく、この種の詳細から離れることは可能である。本発明は、付随する特許請求の範囲によってのみ定義される。
【図面の簡単な説明】
【図１】Ａ． 好ましい作業グループサーバーアレーを構築するための装置の１つとして好ましい作業グループ・プロセッサー、すなわち「チームプロセッサー」を示した機能ブロック図である。
Ｂ． 好ましい作業グループサーバーアレーを構築するための装置の１つとして好ましい作業グループコンピュータ・フレーム、すなわち複数の「チームプロセッサー」を収容できる「チームフレーム」を示した機能ブロック図である。
Ｃ． 好ましい統合化構成の１つを示した機能ブロック図であり、それには本発明の実施態様の１つとして、複数のリンクを介してネットワークされ作業グループ化された８つの好ましい「チームプロセッサー」をはじめ、４つの「チームサーバー」が包含される。
Ｄ． 好ましいモジュラー型の作業グループ−ベースのモニタリングおよびマネジメント、すなわち「チームパネル」を示した機能ブロック図であり、それには４つの基本コントロール・ユニット、デュアル・プロセッサーを伴う１つのメイン・コントロール・ユニットが包含され、フロント・パネルが組み込まれた「チームフレーム」に収容することができる「チームプロセッサー」を最大で４つまで接続することができる。
Ｅ． プライマリ「チームパネル」およびセカンダリ「チームパネル」をカスケード接続し８つの「チームプロセッサー」構成に適応するモジュラーを示した機能ブロック図である。
【図２】Ａ． 本発明システムの一実施態様に従った好ましい作業グループサーバーアレーを示した機能ブロック図であり、８つの「チームプロセッサー」、４つのＳＣＳＩディスク−ベースの「チームサーバー」および２つのカスケード接続された「チームパネル」から構成され、それらすべてが２つの「チームフレーム」に収容されている。
Ｂ． 本発明システムの一実施態様に従った好ましい作業グループサーバーアレーを示した機能ブロック図であり、４つの「チームプロセッサー」、２つのＳＣＳＩディスク−ベースの「チームサーバー」および１つの「チームパネル」から構成され、それらすべてが１つの「チームフレーム」に収容されている。
Ｃ． 本発明システムの一実施態様に従った好ましい作業グループサーバーアレーを示した機能ブロック図であり、１２の「チームプロセッサー」、デュアルＳＣＳＩチャンネルを使用してリンクされる６つのＳＣＳＩディスク‐ベースの「チームサーバー」、および３つのカスケード接続された「チームパネル」から構成され、それらすべてが３つの「チームフレーム」に収容されている。
【図３】Ａ． 内部オペレーション、障害迂回、負荷バランス、セキュリティ、マネジメントおよび最適パフォーマンス測定とともに使用するための複数の根源的機能がすべてインストールされた、好ましい８つの「チームプロセッサー」サーバー・アレー上における好ましいデータ構造ならびにデータ・フローの方法の実施を示した機能ブロック図である。
Ｂ． 複数のシングル‐アプリケーションの作業グループサーバーアレーからなる作業グループサーバークラスターを示した機能ブロック図であり、それぞれは最適パフォーマンス測定に基づく相互排他データベース・セグメントを提供し、それにより高いアベイラビリティならびにスケーラビリといった相互作業グループ−ベースの根源的機能がインストールされる。
【図４】 各種セキュリティ・ゾーン−ベースのアプリケーション指向作業グループサーバークラスターおよび、ＦＣ−ＡＬハブまたはＦＣスイッチを使用するバックエンド・データベース・サーバーの好ましい統合を示した機能ブロック図であり、好ましいデータ中心／ウェアハウス構成がウェブ−ベースのミッション・クリティカルな分散コンピューティング環境において作られる。

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. 複数の追加的な作業グループサーバークラスターへの直列／並列接続により上方にスケール可能であり、これにより高いアベイラビリティかつミッション・クリティカルなアプリケーションが得られることを特徴とする請求項４５に記載のクラスター。

Images