JP2004508616A - 拡張可能コンピューティングシステムの制御方法および装置 - Google Patents
拡張可能コンピューティングシステムの制御方法および装置 Download PDFInfo
- Publication number
- JP2004508616A JP2004508616A JP2002508204A JP2002508204A JP2004508616A JP 2004508616 A JP2004508616 A JP 2004508616A JP 2002508204 A JP2002508204 A JP 2002508204A JP 2002508204 A JP2002508204 A JP 2002508204A JP 2004508616 A JP2004508616 A JP 2004508616A
- Authority
- JP
- Japan
- Prior art keywords
- subset
- slave
- resources
- processing resources
- control
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5072—Grid computing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/505—Clust
Abstract
動的に縮小拡大され、極めて拡張可能で利用可能なサーバファームを提供、制御、および管理する方法および装置が開示されている。仮想サーバファーム（ＶＳＦ）は、物理的に構成された後で、要求があり次第、様々な組織のためにＶＳＦに論理的に分割される大規模コンピューティング構造（「コンピューティンググリッド」）から生成される。各組織は、ＶＳＦの独立管理制御を維持する。ＶＳＦは、コンピューティンググリッド内で動的にファイアウォールされる。ＶＳＦにおける要素の割り当てと制御は、特殊制御ポートを介して、コンピューティンググリッド内の全てのコンピューティング、ネットワーキング、および記憶要素に接続された制御プレーンによって行われる。各ＶＳＦの内部トポロジーは、制御プレーンの制御下にある。単層ウェブサーバまたは多層ウェブサーバ、アプリケーションサーバ、データベースサーバの構成を含む多数の異なる構成においてＶＳＦを構成するために、物理的な配線のし直しは必要ない。
Description
【０００１】
【発明の属する技術分野】
本発明は一般に、データ処理に関する。本発明は、特にコンピューティンググリッドを制御する方法および装置に関する。
【０００２】
【発明が解決しようとする課題】
今日のウェブサイトおよび他のコンピュータシステムのビルダーは、多くの興味深いシステムプランニング問題を抱えている。これらの問題には、容量プランニング、サイト利用可能度およびサイトの安全性が含まれている。これらの目標を達成するには、潜在的に大きく複雑であるかもしれないサイトの設計および運営が可能なトレーニングを受けた人員を探し出して、雇用することが必要である。多くの組織にとって、大きなサイトの設計、構築、運営は主力事業でないことが多いため、このような人員を探し出して雇用することは難しいことが分かっている。
【０００３】
１つの方法として、他の企業の他のウェブサイト共に同じ場所に配置された、第三者サイトの企業ウェブサイトを採用した。このような外部委託施設は現在、Ｅｘｏｄｕｓ、ＡｂｏｖｅＮｅｔ、ＧｌｏｂａｌＣｅｎｔｅｒなどの企業から利用できる。これらの施設により、多数の顧客が共有する物理的スペース、冗長ネットワーク、発電施設が与えられる。
【０００４】
外部委託ウェブサイトの採用により、ウェブサイトの確立と維持の負担が大きく減るが、企業からウェブサイトの維持に関連する全ての問題を取り除くことにはならない。企業は、その施設の構築、運営、増大の間に、そのコンピューティング構造基盤に関する多くの仕事を行なわなければならない。このような施設で採用された企業の情報テクノロジー管理者は、施設でのその演算装置の手動選択、設置、構成、維持に関して責任がある。管理者は、リソースプランニングおよび取り扱いピーク容量などの困難な問題に取り組まなければならない。特に、管理者は、需要に対処するために外部委託企業からリソース需要および要求リソースを予測する必要がある。多くの管理者は、予期しないピーク需要に対する緩和策として、必要とする以上に実質的に多いリソースを要求することで十分な容量を確保する。残念ながら、これによって未使用の容量が多大なものになり、ウェブサイトを採用するための企業の諸経費が増加してしまう。
【０００５】
外部委託企業も、サーバ、ソフトウェア、電力施設を含む完全計算施設を提供しても、成長に伴って同一の手動の誤りやすい管理処置が必要となるので、外部委託企業にとって施設の拡大および成長は簡単ではない。さらに、予期しないピーク需要に対する容量プランニングと共に問題が残っている。この場合、外部委託企業は、かなりの量の未使用容量を維持することがある。
【０００６】
さらに、外部委託企業が管理するウェブサイトの必要条件は異なることがしばしばある。例えば、ある企業では、そのウェブサイトを独立して運営および制御するための能力が必要になる。他の企業では、そのウェブサイトを、外部委託企業で共に配置された他の全てのサイトから分離させる特定の種類またはレベルの安全確保が必要となる。別の例として、ある企業では、どこかに配置された企業イントラネットへの確実な接続が必要となる。
【０００７】
さらに、様々なウェブサイトは、内部トポロジーにおいて異なる。あるサイトは単に、ウェブロードバランサによってロードバランスの取れたウェブサーバ列から構成される。適切なロードバランサはＣｉｓｃｏ Ｓｙｓｔｅｍｓ， Ｉｎｃ．のＬｏｃａｌ Ｄｉｒｅｃｔｏｒ、Ｆ５ＬａｂｓのＢｉｇＩＰ、ＡｌｅｔｏｎのＷｅｂ Ｄｉｒｅｃｔｏｒなどである。他のサイトは多層構成されることもあり、これによってウェブサーバ列はハイパーテキストプロトコル（ＨＴＴＰ）要求に対処できるが、アプリケーションロジックの大半は別のアプリケーションサーバにおいて実施される。これらのアプリケーションサーバを、データベースサーバの層に再び接続しなければならないことがある。
【０００８】
このような異なる構造シナリオの幾つかを、図１Ａ、図１Ｂ、図１Ｃに示す。図１Ａは単純なウェブサイトのブロック図であり、ＣＰＵ１０２およびディスク１０４を含む単一のコンピューティング要素またはマシン１００から成る。マシン１００は、インターネットとして知られる世界規模のパケット交換式データネットワーク１０６、または他のネットワークに接続されている。マシン１００は、上述したタイプの同一位置サービス内に収容されていてもよい。
【０００９】
図１Ｂは、複数のウェブサーバＷＳＡ、ＷＳＢ、ＷＳＣを含む１層ウェブサーバファーム１１０のブロック図である。各ウェブサーバは、インターネット１０６に接続されたロードバランサ１１２に接続されている。ロードバランサはサーバ間のトラフィックを分割して、各サーバのバランスのとれた処理ロードを維持する。ロードバランサ１１２も、ウェブサーバを許可されていないトラフィックから保護するためのファイアウォールを含むか、あるいはこれに接続されていてもよい。
【００１０】
図１Ｃは、ウェブサーバＷ１、Ｗ２などの層、アプリケーションサーバＡ１、Ａ２などの層、およびデータベースサーバＤ１、Ｄ２などの層を含む３層サーバファーム１２０を示す。ウェブサーバは、ＨＴＴＰ要求に対処するために設けられる。アプリケーションサーバは、アプリケーションロジックの大部分を実行する。データベースサーバは、データベース管理システム（ＤＢＭＳ）ソフトウェアを実行する。
【００１１】
構成する必要のあるウェブサイトの種類のトポロジーが多様化され、該当する企業の必要条件が変化しているので、大規模ウェブサイトを構成する唯一の方法は、各サイトを物理的にカスタマイズすることであると考えられる。多くの組織はそれぞれ個別に同一問題に取り組んでおり、ゼロから各ウェブサイトをカスタマイズしている。これは非能率的であり、異なる企業で大量の同一の仕事が生じることになる。
【００１２】
従来の方法の別の問題は、リソースと容量プランニングである。ウェブサイトは、異なる日、またはその日の内の異なる時間で、非常に異なるレベルのトラフィックを受信する。ピークトラフィック時間では、ウェブサイトのハードウェアまたはソフトウェアは、オーバーロードのために適当な時間内で要求に応答することができないことがある。他の時間では、ウェブサイトのハードウェアまたはソフトウェアには過度の容量があり、十分に利用されていない。従来の方法では、過度のコストを負ったり過剰容量となることなく、ピークトラフィックに対処する十分なハードウェアおよびソフトウェアを有することにおけるバランスを見つけることは、困難な問題である。多くのウェブサイトは適切なバランスを見つけることができず、慢性的に過小容量または過剰容量に悩まされている。
【００１３】
別の問題は、ヒューマンエラーによって引き起こされる故障である。手動構成されたサーバファームを使用する現在の方法において存在する大きな潜在的災害は、新しいサーバをライブサーバ内に構成するときのヒューマンエラーにより、サーバファームが誤動作し、これによってウェブサイトのユーザへのサービスが失われてしまう可能性があることである。
【００１４】
上記に基づき、この分野において、カスタム構成を必要とすることなく、要求があり次第、直ちに簡単に拡張することのできるコンピューティングシステムを提供する改善された方法および装置が明確に必要である。
【００１５】
さらに、トラフィックスループットの変化を明らかにするためにそれぞれ必要に応じて拡張または縮小可能な多数の分離処理ノードの生成をサポートするコンピューティングシステムも必要である。
【００１６】
さらに、このような拡張可能コンピューティングシステムとその構成分離処理ノードを制御する方法および装置も必要である。他の必要性もここに示す開示内容から明らかとなるであろう。
【００１７】
【発明の開示】
本発明の１つの態様によれば、上記必要性、および以下の説明により明らかとなる他の必要性は、大規模なコンピューティング構造（「コンピューティンググリッド」）に基づき、非常に拡張性があり、非常に利用しやすくて確実なデータ処理サイトを制御および管理する方法および装置によって達せられる。コンピューティンググリッドは、物理的に構成され、その後要求に応じて様々な組織に対して論理的に分割される。コンピューティンググリッドは、一又は二以上のＶＬＡＮスイッチおよび一又は二以上の記憶領域ネットワーク（ＳＡＮ）スイッチに接続された非常に多数のコンピューティンググ要素を含んでいる。複数の記憶装置はＳＡＮスイッチに接続され、且つ適切な切り替えロジックおよびコマンドを介して、一又は二以上のコンピューティング要素に選択的に接続されてもよい。ＶＬＡＮスイッチの１つのポートは、インターネットなどの外部ネットワークに接続される。監視機構、層、マシンまたはプロセスは、ＶＬＡＮスイッチおよびＳＡＮスイッチに接続される。
【００１８】
初めに、全ての記憶装置およびコンピューティング要素は、アイドルプールに割り当てられる。プログラム制御の下、監視機構はＶＬＡＮスイッチおよびＳＡＮスイッチのポートを一又は二以上のコンピューティング要素および記憶装置に接続するように動的に構成する。その結果、このような要素および装置はアイドルプールから論理的に除去されて、一又は二以上の仮想サーバファーム（ＶＳＦ）またはインスタントデータセンタ（ＩＤＣ）の一部となる。各ＶＳＦコンピューティング要素は、ブートストラップ操作および生成実行を行なうためにコンピューティング要素が使用できるブートイメージを含む記憶装置に向けられるか、あるいは関連付けられる。
【００１９】
本発明の１つの態様によると、監視層は、一又は二以上のスレーブ制御プロセス機構に通信接続された一又は二以上のマスター制御プロセス機構を含む制御機構階層から成る制御プレーンである。一又は二以上のマスター制御プロセス機構は、スレーブ制御プロセス機構のローディングに基づいて、スレーブ制御プロセス機構を割り当ておよび割り当て解除する。一又は二以上のマスター制御プロセス機構は、処理および記憶リソースのサブセットを選択することによってＩＤＣを確立するようにスレーブ制御プロセス機構に支持する。一又は二以上のマスター制御プロセス機構は、スレーブ制御プロセス機構の周期的な検診を行なう。応答がなかったり、あるいは異常終了したスレーブ制御機構は再起動される。別のスレーブ制御機構は開始されて、再開できないスレーブ制御機構の代わりとなる。スレーブ制御機構は、マスター制御機構の周期的な検診を行なう。マスタースレーブ制御プロセス機構が異常終了すると、スレーブ制御プロセス機構が選択されて新たなマスター制御プロセス機構となり、以上終了したマスター制御プロセス機構の代わりとなる。
【００２０】
コンピューティンググリッドを一度物理的に構成し、且つ要求に応じてコンピューティンググリッドの部分を確実且つ動的に様々な組織に割り当てることにより、各サイトのカスタマイズのときには困難であったスケールメリットが得られる。
【００２１】
本発明は、添付の図面において、限定するのではなく、一例として図解されており、且つその中において同一の参照番号は同様の要素を示している。
【００２２】
【本発明の実施の形態】
以下の説明において、説明の目的で、本発明を完全に理解してもらうために多数の特定の細部が述べられている。しかしながら、本発明がこれらの特定の細部無しに実施されることは当業者に明らかとなるであろう。他の例では、本発明が不必要に分かりにくくなってしまうのを回避するために、既知の構造および装置がブロック図で示されている。
【００２３】
仮想サーバファーム（ＶＳＦ）
一実施例によると、大規模なコンピューティング構造（「コンピューティンググリッド」）が設けられる。コンピューティンググリッドは物理的に一度構成され、その後要求に応じて論理的に区画されてもよい。コンピューティンググリッドの一部は、複数の企業または組織のそれぞれに割り当てられる。各組織のコンピューティンググリッドのロジック部分は、仮想サーバファーム（ＶＳＦ）と呼ばれる。各組織はそのＶＳＦの独立した運営管理制御を維持する。各ＶＳＦは、サーバファームまたは他の要素に与えられたリアルタイム要求に基づいて、ＣＰＵの数、記憶容量およびディスク、ネットワーク帯域幅を動的に変更することができる。ＶＳＦは同一の物理的コンピューティンググリッドから全て論理的に生成されるが、各ＶＳＦは全てのほかの組織のＶＳＦから保護されている。ＶＳＦは、イントラネットを他の組織のＶＳＦにさらすことなく、個人専用回線または仮想プライベートネットワーク（ＶＰＮ）を使用することにより、イントラネットに逆に接続することができる。
【００２４】
組織は、コンピュータへの完全（例えば、スーパーユーザまたはルート）管理アクセスを実行し、これらのコンピュータが接続されたローカルエリアネットワーク（ＬＡＮ）の全てのトラフィックを観察することができるが、それに割り当てられたコンピューティンググリッドの部分、つまりＶＳＦにおけるデータおよびコンピューティング要素にのみアクセスできる。一実施例によると、これは、ＶＳＦの安全限界が動的に拡張および縮小する動的ファイアウォール方式を使用することによって可能となる。各ＶＳＦを使用して、インターネット、イントラネットまたはエキストラネットを介してアクセスできる組織の内容とアプリケーションを採用することができる。
【００２５】
コンピューティング要素およびその関連するネットワーキング、および記憶要素の構成と制御は、コンピューティンググリッドにおけるコンピューティング要素の何れかによって直接アクセスすることのできない監視機構によって行なわれる。便宜上、本文書では、監視機構は一般に制御プレーンと呼ばれ、一又は二以上のプロセッサまたはプロセッサのネットワークから構成されていてもよい。監視機構は、スーパバイザ、コントローラなどで構成されていてよい。ここに説明するように、他の方法を用いることもできる。
【００２６】
制御プレーンは、例えばネットワーク内または他の手段によって相互接続される一又は二以上のサーバなど、監視の目的用に割り当てられたコンピューティング要素の完全独立集合上で実施される。制御プレーンは、グリッドのネットワーキングおよび記憶要素の特殊制御ポートまたはインタフェースを介して、コンピューティンググリッドのコンピューティング、ネットワーキングおよび記憶要素に対して、制御動作を行なう。制御プレーンはシステムの切り替え要素に物理的インタフェースを与え、システムにおけるコンピューティング要素の負荷を監視し、グラフィカルユーザインタフェースまたは他の適切なユーザインタフェースを使用して運営管理機能を与える。
【００２７】
制御プレーンを実施するのに使用するコンピュータはコンピュータグリッド（および特定のＶＳＦ）におけるコンピュータには論理的には不可視であり、コンピュータグリッドにおける要素を介して、あるいは外部コンピュータから、決して攻撃されたり、破壊されることはない。制御プレーンのみがコンピュータグリッドにおける機器の制御ポートへの物理的接続部を有しており、これは特定のＶＳＦにおけるメンバーシップを制御する。コンピューティングにおける機器はこれらの特殊制御ポートを介してのみ構成できるので、コンピューティンググリッドにおけるコンピューティング要素はその安全限界を変更したり、認められていない記憶またはコンピューティング機器へのアクセスを行なうことはできない。
【００２８】
従って、ＶＳＦにより、組織は、大規模共有コンピューティングインフラストラクチャから動的に作られたプライベートサーバーファーム、すなわちコンピューティンググリッドから構成されたように見えるコンピューティング設備と連動することができる。ここに説明するコンピューティングアーキテクチャと接続された制御プレーンは、そのプライバシーと保全性がコンピューティンググリッドの機器のハードウェアにおいて実施されるアクセス制御機構によって保護されるプライベートサーバファームを与える。
【００２９】
制御プレーンは、各ＶＳＦの内部トポロジーを制御する。制御プレーンはここに説明するコンピュータ、ネットワークスイッチおよび記憶ネットワークスイッチの基本相互接続を取り、これらを使用して様々なサーバファーム構成を作成することが可能である。これらには、限定されるものではないが、ロードバランサによって前処理された単層ウェブサーバファーム、および多層構成が含まれており、ウェブサーバはアプリケーションサーバと通信し、且つアプリケーションサーバはデータベースサーバと通信を行なう。様々な負荷バランシング、多層化、ファイアウォール構成が可能である。
【００３０】
コンピューティンググリッド
コンピューティンググリッドは単一の場所に存在し、幅広い領域に分散させることができる。最初に、本書はローカルエリア技術でのみ構成される単一の建物のサイズのネットワークにおける、コンピュータグリッドについて説明する。次に、本書は、コンピュータグリッドを広域ネットワーク（ＷＡＮ）上で分散させる場合について説明する。
【００３１】
図２は、ローカルコンピューティンググリッド２０８を含む拡張可能コンピューティングシステム２００の１つの構成を示すブロック図である。本書において、「拡張可能」とは一般に、システムがフレキシブルで拡張性があり、要求があり次第特定の企業またはユーザに対して低下あるいは上昇させた計算力を与える能力を有していることを意味する。ローカルコンピューティンググリッド２０８は、多数のコンピューティング要素ＣＰＵ１、ＣＰＵ２、．．．ＣＰＵｎから成る。実施例において、１０，０００個以上のコンピューティング要素が存在している。これらのコンピューティング要素は長期の要素ごとの状態情報を含んでいたり、保存することはないので、ローカルディスクなどの永続性または不揮発性ストレージなしで構成してもよい。その代わり、全ての長期の状態情報は、コンピューティング要素とは別に、一又は二以上のＳＡＮスイッチ２０２を含む記憶領域ネットワーク（ＳＡＮ）を介してコンピューティング要素に接続される複数のディスク、ディスク１、ディスク２、．．．ディスクｎに保存される。適切なＳＡＮスイッチの例は、ＢｒｏｃａｄｅおよびＥｘｃｅｌから販売されている。
【００３２】
全てのコンピューティング要素は、仮想ＬＡＮ（ＶＬＡＮ）に分割される一又は二以上のＶＬＡＮスイッチ２０４を介して、相互接続される。ＶＬＡＮスイッチ２０４はインターネット１０６に接続されている。一般に、コンピューティング要素は、ＶＬＡＮスイッチに接続された１つまたは２つのネットワークインタフェースを含んでいる。便宜上、図２において、全てのノードが２つのネットワークインタフェースを有しているが、ネットワークインタフェースがこれよりも少ないまたは多いノードもある。多くの製造供給元は現在、ＶＬＡＮ機能をサポートするスイッチを提供している。例えば、適切なＶＬＡＮスイッチはＣｉｓｃｏ Ｓｙｓｔｅｍｓ， ＩｎｃおよびＸｔｒｅｍｅ Ｎｅｔｗｏｒｋｓより入手可能である。同様に、ＳＡＮを構成するための入手可能製品は多数あり、これにはファイバーチャネルスイッチ、ＳＣＳＩ対ファイバーチャネルブリッジング機器、ネットワークアタッチドストレージ（ＮＡＳ）機器が含まれる。
【００３３】
制御プレーン２０６は、ＳＡＮ制御経路、ＣＰＵ制御経路、およびＶＬＡＮ制御経路によって、ＳＡＮスイッチ２０２、ＣＰＵ１、ＣＰＵ２、．．．ＣＰＵｎおよびＶＬＡＮスイッチ２０４にそれぞれ接続される。
【００３４】
各ＶＳＦは、ＶＬＡＮの集合、ＶＬＡＮに取り付けられるコンピューティング要素の集合、およびコンピューティング要素の集合に接続されるＳＡＮ上で利用可能な記憶装置のサブセットから成る。ＳＡＮ上で利用可能なストレージのサブセットをＳＡＮゾーンと呼び、これはＳＡＮハードウェアによって他のＳＡＮゾーンの一部であるコンピューティング要素からのアクセスから保護されている。好適には、非可鍛性ポート識別子を与えるＶＬＡＮを使用して、一人の顧客またはエンドユーザが他の顧客またはエンドユーザのＶＳＦリソースにアクセスするのを防止する。
【００３５】
図３は、ＳＡＮゾーンを特色とする典型的な仮想サーバファームのブロック図である。複数のウェブサーバＷＳ１、ＷＳ２などは、第１ＶＬＡＮ（ＶＬＡＮ１）によってロードバランサ（ＬＢ）／ファイアウォール３０２に接続されている。第２ＶＬＡＮ（ＶＬＡＮ２）は、インターネット１０６をロードバランサ（ＬＢ）／ファイアウォール３０２に接続する。各ウェブサーバは、後に説明する機構を使用してＣＰＵ１、ＣＰＵ２などから選択することができる。ウェブサーバはＳＡＮゾーン３０４に接続されており、これは一又は二以上の記憶装置３０６ａ、３０６ｂに接続されている。
【００３６】
ある時点において、例えば図２のＣＰＵ１などのコンピューティンググリッドにおけるコンピューティング要素は、ＶＬＡＮの集合および単一のＶＳＦに関連するＳＡＮゾーンに接続されているだけである。通常、ＶＳＦは異なる組織間で共有されることはない。単一のＳＡＮゾーンに属するＳＡＮ上のストレージのサブセット、およびそれに関連するＶＬＡＮの集合、およびこれらのＶＬＡＮ上のコンピューティング要素が、ＶＳＦを規定する。
【００３７】
ＶＬＡＮのメンバーシップおよびＳＡＮゾーンのメンバーシップを制御することにより、制御プレーンはコンピューティンググリッドを多数のＶＳＦに論理分割する。１つのＶＳＦのメンバーは、他のＶＳＦのコンピューティングまたは記憶リソースにアクセスできない。このようなアクセス制限は、ＶＬＡＮスイッチによって、且つファイバーチャネルスイッチやＳＣＳＩ対ファイバーチャネルブリッジングハードウェアなどのエッジ機器といったＳＡＮハードウェアのポートレベルアクセス制御機構（例えばゾーニング）によって実行させる。コンピューティンググリッドの一部を形成するコンピューティング要素はＶＳＡＮスイッチおよびＳＡＮスイッチの制御ポートまたはインタフェースに物理的に接続されていないので、ＶＬＡＮまたはＳＡＮゾーンのメンバーシップを制御することはできない。従って、コンピューティンググリッドのコンピューティング要素は、これらを含むＶＳＦに配置されていないコンピューティング要素にアクセスできない。
【００３８】
制御プレーンを実行するコンピューティング要素のみが、グリッドにおける機器の制御ポートまたはインタフェースに物理的に接続される。コンピューティンググリッドの機器（コンピュータ、ＳＡＮスイッチ、およびＶＬＡＮスイッチ）は、これらの制御ポートまたはインタフェースによって構成されるだけである。これにより、コンピューティンググリッドを多数のＶＳＦに動的に分割する単純であるが非常に安定した手段が得られる。
【００３９】
ＶＳＦにおける各コンピューティング要素は、他のコンピューティング要素と交換可能である。あるＶＳＦに関連するコンピューティング要素、ＶＬＡＮおよびＳＡＮゾーンの数は、制御プレーンの制御の下で時間が経つと変化する。
【００４０】
一実施例において、コンピューティンググリッドは、予備の多数のコンピューティング要素から成るアイドルプールを含んでいる。アイドルプールからのコンピューティング要素は、ＣＰＵの増加、そのＶＳＦで利用可能なメモリ容量、あるいはＶＳＦにおける特定のコンピューティング要素の故障に対する対処などの理由で、特定のＶＳＦに割り当ててもよい。コンピューティング要素がウェブサーバとして構成されている場合、アイドルプールは、変化するあるいは「バースト状の」ウェブトラフィック負荷および関連するピーク処理負荷に対する大きな「ショックアブソーバ」として機能する。
【００４１】
アイドルプールは多数の異なる組織間で共有されるので、単一の組織がアイドルプール全体の費用を支払わなければならないということがないため、スケールメリットが得られる。異なる組織が必要に応じてその日の異なる時間でアイドルプールからコンピューティング要素を得ることができるので、各ＶＳＦは必要なときに拡大し、且つトラフィックが通常の状態に落ち着いたときに縮小することが可能となる。多数の異なる組織が同時にピークに達し続け、それによってアイドルプールの容量が使い果たされる可能性がある場合、アイドルプールはそれに更に多くのＣＰＵと記憶要素を追加することで増大させることが可能である（拡張性）。アイドルプールの容量は、通常の状態において、特定のＶＳＦが必要なときにアイドルプールから別のコンピューティング要素を得ることができない確率を大きく減らすよう設計されている。
【００４２】
図４Ａ、図４Ｂ、図４Ｃおよび図４Ｄは、アイドルプールからコンピューティング要素を出し入れするときの連続工程を示すブロック図である。最初に図４Ａを参照し、制御プレーンがコンピューティンググリッドの要素を、ＶＳＦ１およびＶＳＦ２というラベルの第１および第２ＶＳＦに論理的に接続させたものとする。アイドルプール４００は複数のＣＰＵ４０２から成り、そのうちの１つはＣＰＵＸとラベル付けされている。図４Ｂにおいて、ＶＳＦ１で別のコンピューティング要素が必要となった。従って、制御プレーンは、経路４０４で示すように、ＣＰＵＸをアイドルプール４００からＶＳＦ１に移動させる。
【００４３】
図４Ｃにおいて、ＶＳＦ１はもはやＣＰＵＸが必要ではないので、制御プレーンはＣＰＵＸをＶＳＦ１からアイドルプール４００に戻す。図４Ｄにおいて、ＶＳＦ２で別のコンピューティング要素が必要となった。従って、制御プレーンはＣＰＵＸをアイドルプール４００からＶＳＦ２に移動させる。従って、時間が経過して、トラフィックの状態が変化すると、単一のコンピューティング要素がアイドルプールに属し（図４）、特定のＶＳＦに割り当てられ（図４Ｂ）、アイドルプールに戻され（図４Ｃ）、そして別のＶＳＦに属することとなる（図４Ｄ）。
【００４４】
これらの各段階において、制御プレーンは、特定のＶＳＦ（またはアイドルプール）に関連するＶＬＡＮおよびＳＡＮゾーンの一部となるそのコンピューティング要素に関連するＬＡＮスイッチおよびＳＡＮスイッチを構成する。一実施例によると、各推移の間において、コンピューティング要素はパワーダウンまたは再起動される。コンピューティング要素の電源が再び投入されると、コンピューティング要素はＳＡＮの記憶ゾーンの異なる部分を見る。特に、コンピューティング要素は、オペレーティングシステム（例えば、Ｌｉｎｕｘ、ＮＴ、Ｓｏｌａｒｉｓなど）の起動可能イメージを含むＳＡＮ上の記憶ゾーンの部分を見る。記憶ゾーンはまた各組織に特有のデータ部分を含む（例えば、ウェブサーバに関連するファイル、データベースパーティションなど）。コンピューティング要素はまた別のＶＳＦのＶＬＡＮ集合の一部である別のＶＬＡＮの一部であるため、転送先のＶＳＦのＶＬＡＮに関連するＣＰＵ、ＳＡＮ記憶装置、ＮＡＳ機器にアクセスできる。
【００４５】
好適な実施例において、記憶ゾーンは、コンピューティング要素によって想定される役割に関連する複数の予め定義された論理詳細設計を含んでいる。初めに、何れのコンピューティング要素も、ウェブサーバ、アプリケーションサーバ、データベースサーバなどの特定の役割やタスクにあてがわれていない。コンピューティング要素の役割は複数の予め定義された保存された詳細設計の何れかから得られ、このような詳細設計のそれぞれはその役割に関連するコンピューティング要素のブートイメージを定義する。詳細設計は、ブートイメージ位置を役割に関連付けさせるファイル、データベーステーブル、または他の保存形式で保存される。
【００４６】
従って、図４Ａ、図４Ｂ、図４Ｃおよび図４ＤにおけるＣＰＵＸの移動は論理的であって、物理的ではなく、制御プレーンの制御の下でＶＬＡＮスイッチおよびＳＡＮゾーンを再構成することによって行なわれる。また、コンピューティンググリッドにおける各コンピューティング要素はまず本来代替可能であり、仮想サーバファームに接続されてブートイメージからソフトウェアをロードした後でのみ特定の処理役割を想定する。何れのコンピューティング要素も、ウェブサーバ、アプリケーションサーバ、データベースサーバなどの特定の役割またはタスクがあてがわれていない。コンピューティング要素の役割は、複数の予め定義された保存された詳細設計の何れかから得られ、これらの詳細設計のそれぞれは役割に関連しており、役割に関連するコンピュータ要素のブートイメージを定義する。
【００４７】
長期の状態情報は特定のコンピューティング要素（ローカルディスクなど）に保存されていないので、異なるＶＳＦ間でノードは簡単に移動でき、まったく異なるＯＳおよびアプリケーションソフトウェアを実行させることができる。これにより、計画された、あるいは計画されていないダウンタイムの場合に、コンピューティング要素はより交換しやすくなる。
【００４８】
特定のコンピューティング要素は、様々なＶＳＦから出し入れするときに、異なる役割を実行することができる。例えば、コンピューティング要素は、あるＶＳＦにおいてウェブサーバとして動作し、且つ別のＶＳＦに移動させると、データベースサーバ、ウェブロードバランサ、ファイアウォールなどになる。また、異なるＶＳＦにおいて、Ｌｉｎｕｘ、ＮＴ、Ｓｏｌａｒｉｓなどの異なるオペレーティングシステムを連続的に起動および実行することもできる。従って、コンピューティンググリッドにおける各コンピューティング要素は代替可能であり、それに割り当てられた固定的役割はない。従って、コンピューティンググリッドの予備容量全体を使用して、何れかのＶＳＦが必要とする何らかのサービスを提供することができる。これにより、特定のサービスを実行する各サーバが有する同一のサービスを提供することのできるバックアップサーバの数は数千になるので、単一のＶＳＦが提供するサービスの利用可能度および信頼性は非常に高くなる。
【００４９】
さらに、コンピューティンググリッドの高予備容量によって、動的負荷バランシング特性および高プロセッサ利用可能度が得られる。この能力は、ＶＬＡＮを介して相互接続され、ＳＡＮを介して記憶装置の構成可能ゾーンに接続され、また全て制御プレーンによってリアルタイムで制御されるディスクレスコンピューティング要素の一義的な組合せで可能となる。各コンピューティング要素はＶＳＦにおける何れかの必要サーバの役割において動作することができ、またＳＡＮにおける何れかのディスクの何れかの論理分割に接続可能である。グリッドで更なるコンピューティングパワーやディスク容量が必要な場合、コンピューティング要素またはディスクストレージはアイドルプールに手動で追加されるが、これは時間が経過して更に多くの組織にＶＳＦサービスが提供されると減少する。ＣＰＵの数、ネットワークおよびディスク処理能力、ＶＳＦで利用できる記憶装置を増大させるのに、手動で介入する必要はない。これらのリソース全ては、要求があるたびにＣＰＵ、アイドルプールで利用できるネットワークおよびディスクリソースから、制御プレーンによって割り当てられる。
【００５０】
特定のＶＳＦは、手動で再構成されない。アイドルプールのコンピューティング要素のみが、コンピューティンググリッドに手動で再構成される。その結果、現在手動で構成されたサーバファームに存在する大きな潜在的障害が除去される。新たなサーバをライブサーバファームに構成する際のヒューマンエラーによってサーバファームが誤動作し、その結果そのウェブサイトのユーザへのサービスが失われてしまう可能性は、殆どなくなる。
【００５１】
制御プレーンはまた、ＳＡＮに取り付けられた記憶装置に保存されたデータをコピーするので、特定の記憶要素の故障によって、システムの何れかの部分へのサービスが失われることはない。ＳＡＮを使用し、且つ冗長的な記憶およびコンピューティング要素を与えることで、コンピューティング装置から長期記憶装置を取り除くことにより、どのコンピューティング要素も何れかの記憶パーティションに取り付けることができるので、高い利用可能性が得られる。
【００５２】
仮想サーバファームの確立、それに対するプロセッサの追加、およびそれからのプロセッサの除去の詳細な例
図５は、実施例によるコンピューティンググリッドおよび制御プレーン機構のブロック図である。図５を参照し、以下においてＶＳＦを作成し、それにノードを追加し、且つそれからノードを除去するのに使用できる詳細な過程を説明する。
【００５３】
図５は、ＶＬＡＮケーパブルスイッチ５０４に接続されたコンピュータＡ〜Ｇを含むコンピューティング要素５０２を示す。ＶＬＡＮスイッチ５０４はインターネット１０６に接続されており、且つＶＬＡＮスイッチはポートＶ１、Ｖ２などを有している。コンピュータＡ〜Ｇは更にＳＡＮスイッチ５０６に接続され、これは複数の記憶装置またはディスクＤ１〜Ｄ５に接続されている。ＳＡＮスイッチ５０６はポートＳ１、Ｓ２などを有している。制御プレーン機構５０８は、制御経路およびデータ経路によって、ＳＡＮスイッチ５０６およびＶＬＡＮスイッチ５０４に通信接続されている。制御プレーンは、制御ポートを介してこれらの装置に制御コマンドを送信することができる。
【００５４】
便宜上、図５のコンピューティング要素の数は少なくなっている。実際には、多数のコンピュータ、例えば数千以上、および同数の記憶装置がコンピューティンググリッドを形成している。このような大きな構造において、多数のＳＡＮスイッチは相互接続されてメッシュを形成し、且つＶＬＡＮスイッチは相互接続されてＶＬＡＮメッシュを形成している。しかしながら、分かりやすくするため、図５では単一のＳＡＮスイッチと単一のＶＬＡＮスイッチを示している。
【００５５】
まず、全てのコンピュータＡ〜Ｇが、制御プレーンがＶＳＦの作成要求を受信するまで、アイドルプールに割り当てられている。ＶＬＡＮスイッチの全てのポートは、（アイドルゾーン用）ＶＬＡＮＩとラベル付けされる特定のＶＬＡＮに割り当てられている。制御プレーンがＶＳＦを構成するように要求され、ＳＡＮ上の記憶装置に接続された１つのロードバランサ／ファイアウォールおよび２つのウェブサーバを含むものとする。制御プレーンへの要求は、管理インタフェースまたは他のコンピューティング要素を介して受信される。
【００５６】
それに応じて、制御プレーンはＣＰＵＡをロードバランサ／ファイアウォールとして指定または割り当て、且つＣＰＵＢおよびＣＰＵＣをウェブサーバとして割り当てる。ＣＰＵＡは論理的にＳＡＮゾーン１に置かれ、専用のロードバランサ／ファイアウォールソフトウェアを含むディスク上の起動可能パーティションに向けられる。「向けられる」という語は便宜上使用され、いかなる手段によって、動作させる必要のある適切なソフトウェアをＣＰＵＡが入手あるいは探し出すのに十分な情報がＣＰＵＡに与えられることを意味する。ＳＡＮゾーン１にＣＰＵＡを配置することにより、ＣＰＵＡは、そのＳＡＮゾーンのＳＡＮによって制御されるディスクからリソースを得ることが可能になる。
【００５７】
ロードバランサは、負荷バランスすべき２つのウェブサーバとしてのＣＰＵＢおよびＣＰＵＣについて知るために、制御プレーンによって構成される。ファイアウォール構成は、インターネット１０６からの認められないアクセスから、ＣＰＵＢおよびＣＰＵＣを保護する。ＣＰＵＢおよびＣＰＵＣは、特定のオペレーティングシステム（例えば、Ｓｏｌａｒｉｓ、Ｌｉｎｕｘ、ＮＴなど）およびウェブサーバアプリケーションソフトウェア（例えばＡｐａｃｈｅ）のための起動用ＯＳイメージを含むＳＡＮ上のディスクパーティションに向けられる。ＶＬＡＮスイッチは、ＶＬＡＮ１にポートｖ１およびｖ２を配置し、且つＶＬＡＮ２にポートｖ３、ｖ４、ｖ５、ｖ６およびｖ７を配置するように構成される。制御プレーンはＳＡＮスイッチ５０６を構成して、ファイバーチャネルスイッチポートｓ１、ｓ２、ｓ３およびｓ８をＳＡＮゾーン１に配置する。
【００５８】
ＣＰＵがどのように特定のディスクドライブに向けられ、且つこれが起動とディスクデータへの共有アクセスにどのような意味があるのかをここに説明する。
【００５９】
図６は、まとめてＶＳＦ１と呼ばれるコンピューティング要素の論理接続の結果を示すブロック図である。ディスクドライブＤＤ１は記憶装置Ｄ１、Ｄ２などから選択される。図６に示す論理構造が得られると、ＣＰＵ Ａ， Ｂ， Ｃには起動コマンドが与えられる。それに応じて、ＣＰＵＡは専用ロードバランサ／ファイアウォールコンピューティング要素となり、且つＣＰＵＢおよびＣＰＵＣはウェブサーバとなる。
【００６０】
今、方針に基づく規則のために、制御プレーンが、ＶＳＦ１において別のウェブサーバが必要であると判断したものとする。これは、例えば、ウェブサーバへの要求の増加によって起こるものであり、且つ顧客の計画によって少なくとも３つのウェブサーバをＶＳＦ１に追加することが可能となる。あるいは、ＶＳＦを所有または運営する組織が別のサーバを欲し、そのＶＳＦに更にサーバを追加することの可能な特権的ウェブページなどの管理機構によって追加したためである。
【００６１】
それに応じて、制御プレーンはＶＳＦ１にＣＰＵＤを追加することを決定する。そのために、制御プレーンは、ポートｖ８およびｖ９をＶＬＡＮ２に追加することで、ＶＬＡＮ２にＣＰＵＤを追加する。また、ＣＰＵＤのＳＡＮポートｓ４はＳＡＮゾーン１に追加される。ＣＰＵＤは、ウェブサーバとして起動および実行されるＳＡＮ記憶装置の起動可能部分に向けられる。ＣＰＵＤはまたウェブページ内容、実行可能サーバスクリプトなどから成るＳＡＮ上の共有データに読み出し専用アクセスする。このように、ＣＰＵＢおよびＣＰＵＣが要求に対応するように、サーバファームに向けられたウェブ要求に対処することができる。制御プレーンは、ＣＰＵＤを負荷バランシングされているサーバセットの一部として含むようロードバランサ（ＣＰＵＡ）を構成する。
【００６２】
次にＣＰＵＤは起動され、ＶＳＦのサイズは３つのウェブサーバおよび１つのロードバランサに増大した。図７は、結果として得られた論理接続性を示している。
【００６３】
制御プレーンが、ＶＳＦ２という名前で、２つのウェブサーバと１つのロードバランサを必要とする別のＶＳＦを作成する要求を受信するものとする。制御プレーンはＣＰＵＥをロードバランサ／ファイアウォールとなるよう割り当て、且つＣＰＵＦおよびＣＰＵＧをウェブサーバとなるよう割り当てる。再び負荷バランシングする２つのコンピューティング要素としてのＣＰＵＦおよびＣＰＵＧについて知るため、ＣＰＵＥを構成する。
【００６４】
この構成を実施するため、制御プレーンは、ＶＬＡＮ１にポートｖ１０およびｖ１１が含まれ（つまり、インターネット１０６に接続）、且つＶＬＡＮ３にポートｖ１２、ｖ１３、ｖ１４、ｖ１５が含まれるようＶＬＡＮスイッチ５０４を構成する。同様に、ＳＡＮゾーン２にＳＡＮポートｓ６、ｓ７、ｓ９が含まれるようＳＡＮスイッチ５０６を構成する。このＳＡＮゾーンは、ＣＰＵＥをロードバランサとして、且つＣＰＵＦおよびＣＰＵＧをＳＡＮゾーンのディスクＤ２に含まれる共有読み取り専用ディスク部分を使用するウェブサーバとして実行させるのに必要なソフトウェアを含む記憶装置を含んでいる。
【００６５】
図８は、結果として得られる論理接続性のブロック図である。２つのＶＳＦ（ＶＳＦ１、ＶＳＦ２）が同一の物理ＶＬＡＮスイッチおよびＳＡＮスイッチを共有するが、２つのＶＳＦは論理的に分割されている。ＣＰＵ
Ｂ、Ｃ、ＤにアクセスするユーザまたはＶＳＦ１を所有または運営する企業は、ＶＳＦ１のＣＰＵおよびストレージにアクセスできるのみである。このようなユーザはＶＳＦ２のＣＰＵまたはストレージにアクセスできない。これは、唯一の共有セグメント（ＶＬＡＮ１）上の別個のＶＬＡＮおよび２つのファイアウォールの組合せ、および２つのＶＳＦが構成される異なるＳＡＮゾーンのために、このようなアクセスができない。
【００６６】
さらに、制御プレーンは、ＶＳＦ１を２つのウェブサーバに戻すことができると判断するものとする。これは、ＶＳＦ１の負荷の一時的上昇が低下し、あるいはその他の管理行為がとられたためである。それに応じて、制御プレーンは、ＣＰＵの電源オフを含む特殊コマンドによってＣＰＵＤをシャットダウンする。ＣＰＵがシャットダウンすると、制御プレーンはポートｖ８およびｖ９をＶＬＡＮ２から取外し、またはＳＡＮゾーン１からＳＡＮポートｓ４と取り外す。ポートｓ４はアイドルＳＡＮゾーンに配置される。アイドルＳＡＮゾーンは、例えば、（アイドル用）ＳＡＮゾーンＩまたはゾーン０に指定される。
【００６７】
その後、制御プレーンは別のノードをＶＳＦ２に追加することを決定する。これは、ＶＳＦ２におけるウェブサーバの負荷が一時的に上昇したり、あるいは他の理由によるためである。従って、制御プレーンは、破線経路８０２で示すように、ＣＰＵＤをＶＳＦ２に配置することを決定する。そのために、ＶＬＡＮ３にポートｖ８およびｖ９が含まれ、且つＳＡＮゾーン２にＳＡＮポートｓ４が含まれるようＶＬＡＮスイッチを構成する。ＣＰＵＤは、ＶＳＦ２のサーバに必要なＯＳおよびウェブサーバソフトウェアの起動用イメージを含むディスク装置２の記憶部分に向けられる。また、ＣＰＵＤは、ＶＳＦ２のほかのウェブサーバが共有するファイルシステムのデータへの読み取り専用アクセスが許可される。ＣＰＵＤは再び電源が投入され、ＶＳＦ２における負荷バランシングされたウェブサーバとして実行し、ＳＡＮゾーン１におけるデータまたはＶＬＡＮ２に取り付けられたＣＰＵへアクセスすることはない。特に、ＣＰＵＤは、ＶＳＦ１の一部であった初期の時点でも、ＶＳＦ１の要素にアクセスすることはできない。
【００６８】
さらに、この構成において、ＣＰＵＥによって実行される安全限界は、ＣＰＵＤを含むまで動的に拡張した。従って、実施例によって、ＶＳＦに追加または除去されるコンピューティング要素を適切に保護するように自動的に調整する動的ファイアウォールが提供される。
【００６９】
説明のため、実施例はポートに基づくＳＡＮゾーニングについて説明した。他の種類のＳＡＮゾーニングも用いることができる。例えば、ＬＵＮレベルＳＡＮゾーニングを使用し、ディスクアレイ内の論理量に基づいてＳＡＮゾーンを作成してもよい。ＬＵＮレベルＳＡＮゾーニングに適した実例製品は、ＥＭＣ ＣｏｒｐｏｒａｔｉｏｎのＶｏｌｕｍｅ Ｌｏｇｉｃｓ Ｐｒｏｄｕｃｔである。
【００７０】
ＳＡＮ上のディスク装置
起動、あるいは他の共有する必要のあるディスクストレージ、起動プログラムおよびデータをどこで見つけるのかに関する情報を有するディスクストレージへのアクセスという目的で、ＣＰＵをＳＡＮ上の特定の装置に向ける方法は幾つかある。
【００７１】
１つの方法では、コンピューティング要素に取り付けられたＳＣＳＩ対ファイバーチャネルブリッジング機器およびローカルディスクのＳＣＳＩインタフェースを設ける。そのＳＣＳＩポートからファイバーチャネルＳＡＮの適切な機器への経路を決定することにより、コンピュータは、ローカルに取り付けられたＳＣＳＩ機器にアクセスするようにファイバーチャネルＳＡＮ上の記憶装置にアクセスできる。従って、起動ソフトウェアなどのソフトウェアは、ローカルに取り付けられたＳＣＳＩ機器をブートオフするように、ＳＡＮ上のディスク装置を単純にブートオフする。
【００７２】
別の方法は、ノードのファイバーチャネルインタフェースおよび関連するデバイスドライバを有し、ファイバーチャネルインタフェースをブート機器として使用可能にするＲＯＭおよびＯＳソフトウェアをブートすることである。
【００７３】
他の方法では、ＳＣＳＩまたはＩＤＥ機器コントローラとなるが、ＳＡＮ上で通信を行なってディスクにアクセスするインタフェースカード（例えばＰＣＩバスまたはＳバス）を有する。Ｓｏｌａｒｉｓなどのオペレーティングシステムは、この方法で使用可能なディスクレスブート機能を完全提供する。
【００７４】
通常は、あるノードに関連するＳＡＮディスク機器は２種類ある。一方の種類は、他のコンピューティング要素と論理的に共有せず、起動可能ＯＳイメージ、ローカル構成ファイルなどを含む通常はノードごとのルートパーティションであるものを構成する。これは、Ｕｎｉｘ（登録商標）システム上のルートファイルシステムと同等である。
【００７５】
２番目の種類のディスクは、他のノードとの共有ストレージである。共有の種類は、ＣＰＵ上で実行するＯＳソフトウェアおよび共有ストレージにアクセスするノードのニーズによって異なる。ＯＳが多数のノード間で共有ディスクパーティションの読み取り／書き込みアクセスを可能にするクラスタファイルシステムを提供する場合、共有ディスクはこのようなクラスタファイルシステムとして実装される。同様に、システムは、共有ディスクへの同時読み取り／書き込みアクセスを行なうために、クラスタ内での多数のノードの実行を可能にするオラクルパラレルサーバなどのデータベースソフトウェアを使用してもよい。このような場合、共有ディスクは、基本ＯＳおよびアプリケーションソフトウェア内にすでに設計されている。
【００７６】
このような共有アクセスが不可能であるオペレーティングシステムの場合、ＯＳおよび関連アプリケーションが他のノードと共有するディスク機器を管理できないため、共有ディスクを読み出し専用機器として実装することができる。多数のウェブアプリケーションの場合、ウェブ関連ファイルへ読み出し専用アクセスすればよい。例えば、Ｕｎｉｘ（登録商標）システムの場合、特定のファイルシステムを読み出し専用として実装してもよい。
【００７７】
マルチスイッチコンピューティンググリッド
図５に関連して上記に説明した構成は、複数のＶＬＡＮスイッチを相互接続して大きな交換ＶＬＡＮ構造を形成することにより、且つ多数のＳＡＮスイッチを相互接続して大きな交換ＳＡＮメッシュを構成することにより、多数のコンピューティングおよび記憶ノードに拡張することができる。この場合、コンピューティンググリッドは、ＳＡＮ／ＶＬＡＮ交換メッシュがＣＰＵおよび記憶装置の非常に多数のポートを含むことを除いて、図５に一般に示すアーキテクチャを有している。制御プレーンを実行する多数のコンピューティング要素は、以下に説明するように、ＶＬＡＮ／ＳＡＮスイッチの制御ポートに物理的に接続可能である。多数のＶＬＡＮスイッチを相互接続して複雑な多構内データネットワークを生成することは、この分野において知られている。例えば、Ｇ． Ｈａｖｉｌａｎｄによる”Ｄｅｓｉｇｎｉｎｇ Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ Ｃａｍｐｕｓ Ｉｎｔｒａｎｅｔｓ ｗｉｔｈ Ｍｕｌｔｉｌａｙｅｒ Ｓｗｉｔｃｈｉｎｇ（多層切り替えを有する高性能構内イントラネットの設計）” Ｃｉｓｃｏ Ｓｙｓｔｅｍｓ， Ｉｎｃ．，およびＢｒｏｃａｄｅから入手可能な情報を参照すること。
【００７８】
ＳＡＮアーキテクチャ
説明では、ＳＡＮがファイバーチャネルスイッチおよびディスク機器、および潜在的にＳＣＳＩ対ファイバーチャネルブリッジなどのファイバーチャネルエッジ機器とから構成されることを前提としている。しかし、ＳＡＮはギガビットイーサネット（登録商標）スイッチなどのほかの技術、または他の物理層プロトコルを使用するスイッチを使用して構成されてもよい。特に、ＩＰ上でＳＣＳＩプロトコルを実行させることにより、ＩＰネットワーク上でＳＡＮを構築しようという試みが行なわれている。上述した方法およびアーキテクチャは、これらの他のＳＡＮ構築方法に適応できる。ＶＬＡＮ可能層２環境でＩＰ上でＳＣＳＩなどのプロトコルを実行させることによってＳＡＮを構築する場合、ＳＡＮゾーンはこれらを異なるＶＬＡＮにマッピングすることによって生成される。
【００７９】
さらに、高速イーサネット（登録商標）またはギガビットイーサネット（登録商標）などのＬＡＮ技術上で動作するネットワークアタッチドストレージ（ＮＡＳ）を使用してもよい。この選択肢により、保全性とコンピューティンググリッドの論理パーティショニングを強化するために、ＳＡＮゾーンの代わりに異なるＶＬＡＮを使用する。このようなＮＡＳ機器は通常、ＳｕｎのＮＳＦプロトコルやＭｉｃｒｏｓｏｆｔのＳＭＢなどのネットワークファイルシステムをサポートして、多数のノードが同一のストレージを共有できるようにする。
【００８０】
制御プレーンの実施
ここに述べるように、制御プレーンは、ＳＡＮおよびＶＬＡＮスイッチの制御およびデータポートに接続される一又は二以上の処理リソースとして実施してもよい。様々な制御プレーンの実施を行なうことができ、且つ本発明は特定の制御プレーンの実施に制限されるものではない。制御プレーン実施の様々な面を、以下の項１）制御プレーンアーキテクチャ、２）マスターセグメントマネジャー選択、３）管理機能、４）方針および保全に関する考察で詳細に説明する。
【００８１】
１．制御プレーンアーキテクチャ
一実施例によれば、制御プレーンは制御プロセス階層として実施される。制御プロセス階層は一般に、一又は二以上のスレーブセグメントマネジャー機構に通信接続されてこれらを制御する一又は二以上のマスターセグメントマネジャー機構を含んでいる。一又は二以上のスレーブセグメントマネジャー機構は、一又は二以上のファームマネジャーを制御する。一又は二以上のファームマネジャーは、一又は二以上のＶＳＦを管理する。マスターおよびスレーブセグメントマネジャー機構は、ハードウェア回路、コンピュータソフトウェア、または何れかの組合せにおいて実施されてもよい。
【００８２】
図９は、一実施例による制御プレーン９０２およびコンピューティンググリッド９０４との間の論理関係を示すブロック図９００である。制御プレーン９０２は、コンピューティンググリッド９０４におけるネットワーキングおよび記憶要素の特殊制御ポートまたはインタフェースを介して、コンピューティンググリッド９０４に含まれるコンピューティング、ネットワーキングおよび記憶要素を制御および管理する。コンピューティンググリッド９０４は、上述した実施例により生成された多数のＶＳＦ９０６または論理リソースグループを含む。
【００８３】
一実施例によると、制御プレーン９０２はマスターセグメントマネジャー９０８、一又は二以上のスレーブセグメントマネジャー９１０、および一又は二以上のファームマネジャー９１２を含んでいる。マスターセグメントマネジャー９０８、スレーブセグメントマネジャー９１０およびファームマネジャー９１２は、特定のコンピューティングプラットフォーム上の同一位置に配置されたり、あるいは多数のコンピューティングプラットフォーム上で分散されてもよい。便宜上、単一のマスターセグメントマネジャー９０８のみを図示および説明するが、多数のマスターセグメントマネジャー９０８を使用してもよい。
【００８４】
マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０に通信接続され、これを制御および管理している。各スレーブセグメントマネジャー９１０は、一又は二以上のファームマネジャー９１２に通信接続され、これを管理する。一実施例によれば、各ファームマネジャー９１２は、通信接続された対応するスレーブセグメントマネジャー９１０として同一のコンピューティングプラットフォーム上の同一位置に配置される。ファームマネジャー９１２は、コンピューティンググリッド９０４上でＶＳＦ９０６を確立、構成および維持する。一実施例によれば、各ファームマネジャー９１２は管理する単一のＶＳＦ９０６が割り当てられるが、ファームマネジャー９１２も多数のＶＳＦ９０６が割り当てられる。ファームマネジャー９１２はそれぞれ直接ではなく、各スレーブセグメントマネジャー９１０を介してのみ通信を行う。スレーブセグメントマネジャー９１０は、その割り当てられたファームマネジャー９１２の状態を監視する。スレーブセグメントマネジャー９１０は、機能停止や異常終了したそれぞれ割り当てられたファームマネジャー９１２を再開させる。
【００８５】
マスターセグメントマネジャー９０８はＶＳＦ９０６のローディングを監視して、各ＶＳＦ９０６に割り当てるリソースの量を決定する。マスターセグメントマネジャー９０８は、必要時応じてファームマネジャー９１２を介してＶＳＦのリソースを割り当ておよび割り当て解除するようにスレーブセグメントマネジャー９１０に指示する。特定のアプリケーションの必要条件に応じて様々な負荷バランシングアルゴリズムを実施してもよく、且つ本発明は特定の負荷バランシング方法に限定されるものではない。
【００８６】
マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０およびファームマネジャー９１２が実行されているコンピューティングプラットフォームのローディング情報を監視して、コンピューティンググリッド９０４は適切にサービスされているか否かを判断する。マスターセグメントマネジャー９０８はスレーブセグメントマネジャー９１０の割り当ておよび割り当て解除を行い、必要に応じてコンピューティンググリッド９０４を適切に管理するためにファームマネジャー９１２の割り当ておよび割り当て解除を行うようスレーブセグメントマネジャー９１０を指示する。一実施例によれば、マスターセグメントマネジャー９０８も、必要に応じてファームマネジャー９１２およびスレーブセグメントマネジャー９１０の間で負荷をバランスさせるために、ファームマネジャー９１２へのＶＳＦの割り当て、およびスレーブセグメントマネジャー９１０へのファームマネジャー９１２の割り当てを管理する。一実施例によれば、スレーブセグメントマネジャー９１０はマスターセグメントマネジャー９０８と活発に通信し、コンピューティンググリッド９０４への変更要求、および別のスレーブセグメントマネジャー９１０および／またはファームマネジャー９１２の要求を行う。一又は二以上のスレーブセグメントマネジャー９１０および一又は二以上のファームマネジャー９１２を実行している処理プラットフォームが機能しなくなった場合、マスターセグメントマネジャー９０８は、停止したコンピューティングプラットフォームのファームマネジャー９１２から他のファームマネジャー９１２へＶＳＦ９０６を再割り当てする。この場合、マスターセグメントマネジャー９０８も、ＶＳＦ９０６の再割り当てを行うために別のファームマネジャー９１２を開始するようにスレーブセグメントマネジャー９１０に指示することができる。ＶＳＦ９０６に割り当てられた多数のコンピューティングリソース、多数のアクティブなファームマネジャー９１２、およびスレーブセグメントマネジャー９１０をアクティブに管理することにより、全体的な電力消費量を制御できる。例えば、電力を節約するために、マスターセグメントマネジャー９０８は、アクティブなスレーブセグメントマネジャー９１０またはファームマネジャー９１２を有していないコンピューティングプラットフォームをシャットダウンしてもよい。節電は、大きなコンピューティンググリッド９０４および制御プレーン９０２で重要となる。
【００８７】
一実施例によれば、マスターセグメントマネジャー９０８は、レジストリを使用することでスレーブセグメントマネジャー９１０を管理する。レジストリは、その状態、割り当てられたファームマネジャー９１２、および割り当てられたＶＳＦ９０６などの現在のスレーブセグメントマネジャー９１０についての情報を含んでいる。スレーブセグメントマネジャー９１０が割り当ておよび割り当て解除されると、レジストリは更新されて、スレーブセグメントマネジャー９１０の変更が反映される。例えば、新しいスレーブセグメントマネジャー９１０がマスターセグメントマネジャー９０８および割り当てられた一又は二以上のＶＳＦ９０６によって例示化されると、レジストリが更新されて、新しいスレーブセグメントマネジャー９１０およびその割り当てられたファームマネジャー９１２とＶＳＦ９０６の生成が反映される。次に、マスターセグメントマネジャー９０８はレジストリを定期的に調べて、スレーブセグメントマネジャー９１０へどのようにＶＳＦ９０６を割り当てるのがよいのかを判断することができる。
【００８８】
一実施例によれば、レジストリは、マスターセグメントマネジャー９１０がアクセスできるマスターセグメントマネジャー９０８についての情報を含んでいる。例えば、レジストリは一又は二以上のアクティブなマスターセグメントマネジャー９０８を識別するデータを含んでいてもよいので、新しいスレーブセグメントマネジャー９１０が生成されると、新しいスレーブセグメントマネジャー９１０はレジストリをチェックして、一又は二以上のマスターセグメントマネジャー９０８の識別について確認することができる。
【００８９】
レジストリは様々な形で実施されてもよく、且つ本発明は特定の実施方法に限定されない。例えば、レジストリは制御プレーン９０２内のデータベース９１４に保存されるデータファイルであってもよい。レジストリは、制御プレーン９０２の外に保存されなくてもよい。例えば、レジストリはコンピューティンググリッド９０４の記憶装置に保存されてもよい。この例では、記憶装置は制御プレーン９０２専用となり、ＶＳＦ９０６に割り当てられない。
【００９０】
２．マスターセグメントマネジャー選出
一般に、マスターセグメントマネジャーは、制御プレーンが確立されたとき、あるいは既存のマスターセグメントマネジャーが故障した後に、選出される。一般に特定の制御プレーン対して単一のマスターセグメントマネジャーが存在するが、２つ以上のマスターセグメントマネジャーを選出して、制御プレーンのスレーブセグメントマネジャーを同時管理するほうが有利な場合もある。
【００９１】
一実施例によれば、制御プレーンにおけるスレーブセグメントマネジャーは、その制御プレーンのマスターセグメントマネジャーを選出する。マスターセグメントマネジャーがなく、単一のスレーブセグメントマネジャーのみが存在するという単純なケースでは、スレーブセグメントマネジャーがマスターセグメントマネジャーとなり、必要に応じて別のスレーブセグメントマネジャーを割り当てる。２つ以上のスレーブセグメントマネジャーが存在する場合、２つ以上のスレーブプロセスが例えば定足数などの採決によって新しいマスターセグメントマネジャーを選出する。
【００９２】
制御プレーンのスレーブセグメントマネジャーは必ずしも永続的ではないので、特定のスレーブセグメントマネジャーを選択して、採決に参加させてもよい。例えば、一実施例によれば、レジスタは、各スレーブセグメントマネジャーによって周期的に更新される各スレーブセグメントマネジャーのタイムスタンプを含んでいる。指定された選択基準に従って決定された、最も最近に更新されたタイムスタンプを有するスレーブセグメントマネジャーはいまだに実行されていると考えられ、新しいマスターセグメントマネジャーを選出するために選択される。例えば、指定数の最も新しいスレーブセグメントマネジャーを採決に選択してもよい。
【００９３】
一実施例によれば、選出シーケンス番号を全てのアクティブなスレーブセグメントマネジャーに割り当て、アクティブなスレーブセグメントマネジャーの選出シーケンス番号に基づいて新しいマスターセグメントマネジャーを決定する。例えば、最も低いあるいは最も高い選出シーケンス番号を使用して、特定のスレーブセグメントマネジャーを次の（または最初の）マスターセグメントマネジャーに選択してもよい。
【００９４】
マスターセグメントマネジャーが確立されると、マスターセグメントマネジャーとしての同一制御プレーンのスレーブセグメントマネジャーは、現在のマスターセグメントマネジャーにコンタクト（ピング）することによりマスターセグメントマネジャーの検診を周期的に行って、マスターセグメントマネジャーがまだアクティブであるか否かを判断する。現在のマスターセグメントマネジャーがアクティブでないと判断した場合、新しいマスターセグメントマネジャーを選出する。
【００９５】
図１０は、実施例によるマスターセグメントマネジャー選出の状態図１０００を示している。スレーブセグメントマネジャーのメインループである状態１００２において、スレーブセグメントマネジャーは、ピングタイマーの終了を待つ。ピングタイマーが終了すると、状態１００４となる。状態１００４において、スレーブセグメントマネジャーは、マスターセグメントマネジャーをピングする。さらに、状態１００４において、スレーブセグメントマネジャーのタイムスタンプ（ＴＳ）が更新される。マスターセグメントマネジャーがピングに応答した場合、マスターセグメントマネジャーはまだアクティブであり、状態１００２に戻る。特定時間後もマスターセグメントマネジャーから応答がなければ、状態１００６になる。
【００９６】
状態１００６において、アクティブなスレーブセグメントマネジャーのリストを得て、状態１００８になる。状態１００８において、他のスレーブセグメントマネジャーもマスターセグメントマネジャーからの応答を受信していないか確認する。この確認を行うためにスレーブセグメントマネジャーへメッセージを送る代わりに、この情報をデータベースから得る。マスターセグメントマネジャーがアクティブでないことにスレーブセグメントマネジャーが同意しない、すなわち一又は二以上のスレーブセグメントマネジャーがマスターセグメントマネジャーから適時の応答を受信した場合、現在のマスターセグメントマネジャーがまだアクティブであると推定され、状態１００２に戻る。特定の数のスレーブセグメントマネジャーが現在のマスターセグメントマネジャーから適時の応答を受信しなかった場合、現在のマスターセグメントマネジャーが「死んでいる」、すなわちアクティブでないと推定され、状態１０１０に進む。
【００９７】
状態１０１０において、プロセスを開始したスレーブセグメントマネジャーは選出テーブルから現在の選出番号、且つデータベースから次の選出番号を検索する。次に、スレーブセグメントマネジャーは選出テーブルを更新して、次の選出番号と一義的なアドレスを指定するエントリをマスター選出テーブルに書き込む。次に、スレーブセグメントマネジャーが現在の選出番号の最も低いシーケンス番号を読み出す状態１０１２に進む。状態１０１４において、特定のスレーブセグメントマネジャーが最も低いシーケンス番号を有しているか否か確認する。有していない場合、状態１００２に戻る。有している場合、特定のスレーブセグメントマネジャーがマスターセグメントマネジャーになる状態１０１６に進む。次に、状態１０１８に進み、選出番号をインクリメントする。
【００９８】
上述したように、スレーブセグメントマネジャーは一般に、その割り当てられたＶＳＦのサービスと、マスターセグメントマネジャーからの命令に応じての新たなＶＳＦの割り当てを行う。スレーブセグメントマネジャーはまたマスターセグメントマネジャーのチェックと、必要に応じて新たなマスターセグメントマネジャーの選出も行う。
【００９９】
図１１は、実施例によるスレーブセグメントマネジャーの様々な状態を示す状態図１１００である。処理は、スレーブセグメントマネジャー開始状態１１０２において始まる。状態１１０２から、現在のマスターセグメントマネジャーの状態を確認する要求に応じて、状態１１０４に進む。状態１１０４では、スレーブセグメントマネジャーは現在のマスターセグメントマネジャーにピングを送って、現在のマスターセグメントマネジャーがまだアクティブであるか否かを判断する。適時の応答が現在のマスターセグメントマネジャーからあれば、状態１１０６に進む。状態１１０６では、他のスレーブセグメントマネジャーにメッセージが同報通信され、マスターセグメントマネジャーがピングに応答したことを知らせる。状態１１０６から、開始状態１１０２に戻る。
【０１００】
状態１１０４で、適時のマスター応答がなければ、状態１１０８に進む。状態１１０８では、他のスレーブセグメントマネジャーにメッセージが同報通信され、マスターセグメントマネジャーがピングに応答しなかったことを知らせる。次に、開始状態１１０２に戻る。ちなみに、十分な数のスレーブセグメントマネジャーが現在のマスターセグメントマネジャーから応答を受信しなかった場合、新しいマスターセグメントマネジャーを上記のように選出する。
【０１０１】
状態１１０２から、マスターセグメントマネジャーからＶＳＦを再開する要求を受信したら、状態１１１０に進む。状態１１１０では、ＶＳＦが再開されて、開始状態１１０２に戻る。
【０１０２】
上述したように、マスターセグメントマネジャーは一般に、マスターセグメントマネジャーが制御するコンピューティンググリッドのＶＳＦが一又は二以上のスレーブセグメントマネジャーによって適切にサービスされるようにする。このために、マスターセグメントマネジャーは、マスターセグメントマネジャーとしての同一制御プレーンの全てのスレーブセグメントマネジャーの定期的検診を行う。一実施例によれば、マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０から状態情報を周期的に要求する。情報は例えば、どのＶＳＦ９０６がスレーブセグメントマネジャー９１０によってサービスされているかを含んでいる。特定のスレーブセグメントマネジャー９１０が特定時間内に応答しなければ、マスターセグメントマネジャー９０８は特定のスレーブセグメントマネジャー９１０の再開を試みる。特定のスレーブセグメントマネジャー９１０を再開できない場合、マスターセグメントマネジャー９０８は、異常のあるスレーブセグメントマネジャー９１０から別のスレーブセグメントマネジャー９１０にファームマネジャー９１２を再割り当てする。次に、マスターセグメントマネジャー９０８は一又は二以上の別のスレーブセグメントマネジャー９１０を例示化して、プロセスローディングの再バランシングを行うことができる。一実施例によれば、マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０を実行しているコンピューティングプラットフォームの状態を監視する。コンピューティングプラットフォームに異常があれば、マスターセグメントマネジャー９０８は、異常のあるコンピューティングプラットフォーム上のファームマネジャー９１２に割り当てられたＶＳＦを、別のコンピューティングプラットフォームに割り当てる。
【０１０３】
図１２は、マスターセグメントマネジャーの状態図１２００である。処理は、マスターセグメントマネジャー開始状態１２０２において開始する。状態１２０２から、マスターセグメントマネジャー９０８が制御面９０２のスレーブセグメントマネジャー９１０の周期的検診を行うかあるいはこれを要求したときに、状態１２０４に進む。状態１２０４から、全てのスレーブセグメントマネジャー９１０が予測したように応答した場合、状態１２０２に戻る。これは、全てのスレーブセグメントマネジャー９１０が、全てのスレーブセグメントマネジャー９１０が普通に動作していることを示す特定の情報をマスターセグメントマネジャー９０８に提供した場合に、生じる。一又は二以上のスレーブセグメントマネジャー９１０が応答しない、あるいは一又は二以上のスレーブセグメントマネジャー９１０に異常があったことを示す応答をした場合、状態１２０６に進む。
【０１０４】
状態１２０６において、マスターセグメントマネジャー９０８は異常のあったスレーブセグメントマネジャー９１０の再開を試みる。これはいくつかの方法で行なうことができる。例えば、マスターセグメントマネジャー９０８は、応答のないあるいは異常のあったスレーブセグメントマネジャー９１０に再開メッセージを送ることができる。状態１２０６から、全てのスレーブセグメントマネジャー９１０が予想したように応答、すなわち問題なく再開された場合、状態１２０２戻る。例えば、異常のあったスレーブセグメントマネジャー９１０が問題なく再開すると、スレーブセグメントマネジャー９１０はマスターセグメントマネジャー９０８に再開確認メッセージを送る。状態１２０６から、一又は二以上のスレーブセグメントマネジャーが再開できなかった場合、状態１２０８に進む。これは、マスターセグメントマネジャー９０８が特定のスレーブセグメントマネジャー９１０から再開確認メッセージを受信しない場合に生じる。
【０１０５】
状態１２０８において、マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０を実行するマシンの現在のローディングを決定する。スレーブセグメントマネジャー９０８のローディング情報を得るために、マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０を直接ポーリングするか、あるいは例えばデータベース９１４など別の場所からローディング情報を得る。本発明は、マスターセグメントマネジャー９０８がスレーブセグメントマネジャー９１０のローディング情報を得るための特定の方法に限定されない。
【０１０６】
次に状態１２１０に進み、異常のあったスレーブセグメントマネジャー９１０に割り当てられたＶＳＦ９０６を他のスレーブセグメントマネジャー９１０に再割り当てする。ＶＳＦ９０６が割り当てられているスレーブセグメントマネジャー９１０は、いつ再割り当てが完了したのかをマスターセグメントマネジャー９０８に知らせる。例えば、スレーブセグメントマネジャー９１０はマスターセグメントマネジャー９０８に再割り当て確認メッセージを送って、ＶＳＦ９０６の再割り当てが問題なく終了したことを知らせることができる。異常のあったスレーブセグメントマネジャー９１０に関連する全てのＶＳＦ９０６の再割り当てが確認されるまで、状態１２１０に留まる。確認されれば、状態１２０２に戻る。
【０１０７】
異常のあったスレーブセグメントマネジャー９１０に関連するＶＳＦ９０６を他のアクティブスレーブセグメントマネジャー９１０へ再割り当てする代わりに、マスターセグメントマネジャー９０８は別のスレーブセグメントマネジャー９１０を割り当て、新しいスレーブセグメントマネジャー９１０にこれらのＶＳＦ９０６を割り当ててもよい。既存のスレーブセグメントマネジャー９１０または新しいスレーブセグメントマネジャー９１０へＶＳＦ９０６を再割り当てするかどうかの選択は、少なくとも部分的に、新しいスレーブセグメントマネジャー９１０の割り当てに関連する待ち時間、および既存のスレーブセグメントマネジャー９１０へのＶＳＦ９０６の再割り当てに関連する待ち時間に依る。何れの方法も特定のアプリケーションの必要条件に応じて使用することができ、且つ本発明は何れの方法にも限定されることはない。
【０１０８】
３．管理機能
一実施例によれば、制御プレーン９０２は、グローバルグリッドマネジャーに通信接続されている。制御面９０２は、グローバルグリッドマネジャーに、課金、障害、容量、ローディング、および他のコンピューティンググリッド情報を提供する。図１３は、実施例によるグローバルグリッドマネジャーの使用を説明するブロック図である。
【０１０９】
図１３において、コンピューティンググリッド１３００は、グリッドセグメント１３０２と呼ばれる論理部分にパーティションされる。各グリッドセグメント１３０２は、データプレーン９０４を制御および管理する制御プレーン９０２を含んでいる。この例において、各データプレーン９０４は図９のコンピューティンググリッド９０４と同一であるが、多数の制御プレーン９０２およびデータプレーン９０４、すなわちグリッドセグメント１３０２を管理するグローバルグリッドマネジャーの使用を説明するため、「データプレーン」と呼ばれる。
【０１１０】
各グリッドセグメントは、グローバルグリッドマネジャー１３０４に通信接続される。グローバルグリッドマネジャー１３０４、制御プレーン９０２、およびコンピューティンググリッド９０４は、単一のコンピューティングプラットフォームに同時配置されたり、あるいは多数のコンピューティングプラットフォーム上で分散させてもよく、本発明は特定の実施方法に限定されることはない。
【０１１１】
グローバルグリッドマネジャー１３０４は、複数のグリッドセグメント１３０２の集中管理およびサービスを行う。グローバルグリッドマネジャー１３０４は、様々な管理タスクで使用される制御プレーン９０２からの課金、ローディング、および他の情報を集めることができる。例えば、課金情報を使用して、コンピューティンググリッド９０４が提供するサービスの課金を行う。
【０１１２】
４．方針および保全についての考察
上述したように、制御プレーンにおけるスレーブセグメントマネジャーは、コンピューティンググリッドにおける関連するＶＳＦと通信可能でなければならない。同様に、コンピューティンググリッドにおけるＶＳＦは、その関連するスレーブセグメントマネジャーと通信可能でなければならない。更に、コンピューティンググリッドにおけるＶＳＦは、あるＶＳＦが何らかの方法で他のＶＳＦの構造を変えてしまうのを防ぐために、互いに通信可能であってはならない。これらの方針を実施する様々な方法について説明する。
【０１１３】
図１４は、実施例によるコンピューティンググリッドへ制御プレーンを接続するアーキテクチャのブロック図１４００である。参照番号１４０２でまとめて識別されるＶＬＡＮスイッチ（ＶＬＡＮ ＳＷ１〜ＶＬＡＮ ＳＷｎ）および参照番号１４０４でまとめて識別されるＳＡＮスイッチ（ＳＡＮ ＳＷ１〜ＳＡＮ ＳＷｎ）の制御（「ＣＴＬ」）ポートは、イーサネット（登録商標）サブネット１４０６に接続される。イーサネット（登録商標）サブネット１４０６は、参照番号１４０８でまとめて識別される複数のコンピューティング要素（ＣＰＵ１、ＣＰＵ２〜ＣＰＵｎ）に接続される。従って、制御プレーン１４０８のコンピューティング要素のみが、ＶＬＡＮスイッチ１４０２およびＳＡＮスイッチ１４０４の制御ポート（ＣＴＬ）に通信接続される。この構造は、ＶＳＦ（図示せず）におけるコンピューティング要素が、それ自身または他のＶＳＦに関連するＶＬＡＮおよびＳＡＮゾーンのメンバーシップを変更してしまうのを防ぐ。この方法も、制御ポートがシリアルまたはパラレルポートである場合に適用可能である。この場合、ポートは制御プレーン１４０８のコンピューティング要素に接続される。
【０１１４】
図１５は、実施例による制御プレーンコンピューティング要素（ＣＰ ＣＰＵ１、ＣＰ ＣＰＵ２〜ＣＰ ＣＰＵｎ）１５０２をデータポートに接続する構造を示すブロック図１５００である。この構成において、制御プレーンコンピューティング要素５０２は、制御プレーンコンピューティング要素１５０２のために動作する制御プレーンエージェント１５０４に周期的にパケットを送る。制御プレーンエージェント１５０４は、リアルタイムデータのためにコンピューティング要素５０２を周期的にポーリングして、データを制御プレーンコンピューティング要素１５０２に送る。制御プレーン１５０２における各セグメントマネジャーは、制御プレーン（ＣＰ）ＬＡＮ１５０６に通信接続されている。ＣＰ ＬＡＮ１５０６は、ＣＰファイアウォール１５０８を介して、ＶＬＡＮスイッチ５０４の特殊ポートＶ１７に通信接続されている。この構造により、制御プレーンコンピューティング要素１５０２に拡張可能な確実な手段が与えられ、コンピューティング要素５０２からリアルタイム情報が集められる。
【０１１５】
図１６は、実施例によるコンピューティンググリッドへ制御プレーンを接続するアーキテクチャのブロック図１６００である。制御プレーン１６０２は、制御プレーンコンピューティング要素ＣＰ ＣＰＵ１、ＣＰ ＣＰＵ２〜ＣＰ ＣＰＵｎを含んでいる。制御プレーン１６０２における各制御プレーンコンピューティング要素ＣＰ ＣＰＵ１、ＣＰ ＣＰＵ２〜ＣＰ ＣＰＵｎは、全体でＳＡＮメッシュ１６０４を形成する複数のＳＡＮスイッチのポートＳ１、Ｓ２〜Ｓｎに通信接続される。
【０１１６】
ＳＡＮメッシュ１６０４は、制御プレーン１６０２に対してプライベートであるデータを含む記憶装置１６０６に通信接続されるＳＡＮポートＳｏ、Ｓｐを含んでいる。記憶装置１６０６は、便宜上、ディスクとして図１６に示されている。記憶装置１６０６は、いずれのタイプの記憶媒体で実施されてもよく、本発明は記憶装置１６０６の特定の種類の記憶媒体に限定されることはない。記憶装置１６０６は、制御プレーンプライベート記憶ゾーン１６０８に論理的に配置される。制御プレーンプライベート記憶ゾーン１６０８は、制御プレーン１６０２を実施するログファイル、統計データ、現在の制御プレーン構成情報を維持する。ＳＡＮポートＳｏ、Ｓｐは制御プレーンプライベート記憶ゾーンの唯一の部分であり、他のＳＡＮゾーンには配置されることはないため、制御プレーン１６０２におけるコンピューティング要素のみが記憶装置１６０６にアクセスできる。また、Ｓ１、Ｓ２〜Ｓｎ、ＳｏおよびＳｐは、制御プレーン１６０２におけるコンピューティング要素に通信接続されるのみの制御プレーンＳＡＮゾーンに存在する。これらのポートは、ＶＳＦにおけるコンピューティング要素（図示せず）がアクセスすることはできない。
【０１１７】
一実施例によれば、特定のコンピューティング要素ＣＰ ＣＰＵ１、ＣＰ ＣＰＵ２〜ＣＰ ＣＰＵｎが記憶装置またはその一部にアクセスする必要がある場合、それは特定のＶＳＦの一部であり、特定のコンピューティング要素は特定のＶＳＦのＳＡＮゾーン内に置かれる。例えば、コンピューティング要素ＣＰ ＣＰＵ２がＶＳＦｉディスク１６１０にアクセスする必要があるものとする。この場合、制御プレーンＣＰ ＣＰＵ２に関連するポートｓ２は、ポートＳｉを含むＶＳＦｉのＳＡＮゾーンに配置される。一度コンピューティング要素ＣＰ ＣＰＵ２がポートＳｉのＶＳＦｉディスク１６１０へアクセスすると、コンピューティング要素ＣＰ ＣＰＵ２はＶＳＦｉのＳＡＮゾーンから取り除かれる。
【０１１８】
同様に、コンピューティング要素ＣＰ ＣＰＵ１がＶＳＦｊディスク１６１２にアクセスする必要があるものとする。この場合、コンピューティング要素ＣＰ ＣＰＵ１はＶＳＦｊに関連するＳＡＮゾーン内に配置される。その結果、ポートＳ１は、ポートＳｊを含むゾーンを有するＶＳＦｊに関連するＳＡＮゾーン内に配置される。一度コンピューティング要素ＣＰ ＣＰＵ１がポートＳｊに接続されたＶＳＦｊディスク１６１２へアクセスすると、コンピューティング要素ＣＰ ＣＰＵ１はＶＳＦｊに関連するＳＡＮゾーンから除去される。この方法により、正確なＳＡＮゾーン制御を使用してリソースへのアクセスを正確に制御することによる、制御プレーンコンピューティング要素および制御プレーン記憶ゾーン１６０８の完全性が得られる。
【０１１９】
上述したように、単一の制御プレーンコンピューティング要素は複数のＶＳＦの管理を行うことができる。従って、単一の制御プレーンコンピューティング要素は、各制御プレーンに大して確立された方針規則に従ってＶＳＦ間のファイアウォールを実行しながら、多数のＶＳＦにおける自身を同時に明確にできなければならない。方針規則は、各制御プレーンのデータベース９１４（図９）に保存、あるいは中央セグメントマネジャー１３０２（図１３）によって実施してもよい。
【０１２０】
一実施例によれば、（物理的スイッチ）ポートに基づくＶＬＡＮタグはスプーフできないため、ＶＬＡＮタギングとＩＰアドレスとの間を強固に結合させて、ＶＳＦによるスプーフ攻撃を防いでいる。あるＶＬＡＮインタフェースで送られてくるＩＰパケットは、パケットが到着する論理インタフェースと同じＶＬＡＮタグおよびＩＰアドレスを有していなければならない。これにより、ＶＳＦにおける不正サーバが別のＶＳＦにおけるソースＩＰアドレスをスプーフし、別のＶＳＦの論理構造を潜在的に変更し、あるいはコンピューティンググリッド機能の保全を破壊するＩＰスプーフィング攻撃を防止する。このＶＬＡＮタギングを防止するほう方法では、高安全（クラスＡ）データセンターを使用して防止できるコンピューティンググリッドへの物理的アクセスが必要である。
【０１２１】
様々なネットワークフレームタギング形式を使用してデータパケットのタグを行ってもよく、且つ本発明は特定のタギング形式に限定されることはない。一実施例によれば、他の形式も適切であるが、ＩＥＥ８０２．１ｑのＶＬＡＮタグを使用している。この例では、ＶＬＡＮ／ＩＰアドレス一貫性チェックを、アクセスを制御するために８０２．１ｑタグ情報が存在するＩＰスタックのサブシステムで実行する。この例において、コンピューティング要素は、コンピューティング要素が多数のＶＬＡＮに同時に通信接続されるよう、ＶＬＡＮ可能ネットワークインタフェースカード（ＮＩＣ）で構成されている。
【０１２２】
図１７は、実施例によるＶＬＡＮタグとＩＰアドレスとの間を強固に結合する構成のブロック図１７００である。コンピューティング要素１７０２および１７０４は、ＮＩＣ１７０８および１７１０を介して、ＶＬＡＮスイッチ１７０６のポートｖ１およびｖ２にそれぞれ通信接続される。ＶＬＡＮスイッチ１７０６も、アクセススイッチ１７１２および１７１４に通信接続される。ポートｖ１およびｖ２は、タグ形式で構成される。一実施例によれば、ＩＥＥＥ８０２．１ｑのＶＬＡＮタグ情報は、ＶＬＡＮスイッチ１７０６によって提供される。
【０１２３】
広域コンピューティンググリッド
上述したＶＳＦは、様々な方法でＷＡＮ上に分散される。
【０１２４】
一つの方法では、広域バックボーンは、非同期転送モード（ＡＴＭ）切替に基づいていてもよい。この場合、各ローカルエリアＶＬＡＮは、ＡＴＭ ＬＡＮエミュレーション（ＬＡＮＥ）標準の一部であるエミュレーテッドＬＡＮ（ＥＬＡＮ）を使用して広域に拡張される。このように、単一のＶＳＦは、ＡＴＭ／ＳＯＮＥＴ／ＯＣ−１２リンクなどの幾つかの広域リンク全体に広がる。ＥＬＡＮは、ＡＴＭ ＷＡＮ全体に拡張するＶＬＡＮの一部となる。
【０１２５】
他の方法では、ＶＳＦをＶＰＮシステムを使用してＷＡＮ全体に拡張する。本実施例において、ネットワークの根本的特徴は不適切になり、ＶＰＮを使用して２つ以上のＶＳＦをＷＡＮ全体にわたって相互接続し、単一の分散ＶＳＦを生成する。
【０１２６】
分散ＶＳＦにおいてデータを論理コピーするために、データミラーリング技術を使用することができる。あるいは、ＳＡＮ対ＡＴＭブリッジングまたはＳＡＮ対ギガビットイーサネット（登録商標）ブリッジングなどの幾つかのＳＡＮ対ＷＡＮブリッジング技術のうちの１つを使用して、ＷＡＮ上にＳＡＮをブリッジさせる。ＩＰはこのようなネットワーク上で問題なく動作するので、ＩＰネットワーク上に構成されたＳＡＮはＷＡＮ上で自然に拡張する。
【０１２７】
図１８は、ＷＡＮ接続上で拡張した複数のＶＳＦのブロック図である。サンノゼセンター、ニューヨークセンター、およびロンドンセンターは、ＷＡＮ接続によって接続されている。各ＷＡＮ接続は、上述したようにＡＴＭ、ＥＬＡＮまたはＶＰＮ接続から構成される。各センターは、少なくとも１つのＶＳＦおよび少なくとも１つのアイドルプールから構成される。例えば、サンノゼセンターはＶＳＦ１ＡおよびアイドルプールＡを有している。この構成において、センターの各アイドルプールのコンピューティングリソースは、他のセンターにあるＶＳＦへの割り当てまたは指定に対して利用できる。このような割り当てまたは指定が行われると、ＶＳＦはＷＡＮ上で拡張する。
【０１２８】
ＶＳＦの使用例
上記例で説明したＶＳＦアーキテクチャは、ウェブサーバシステムのからみで使用してもよい。従って、上記例は、特定のＶＳＦにおけるＣＰＵから構成したウェブサーバ、アプリケーションサーバおよびデータベースサーバに関して説明した。しかし、ＶＳＦアーキテクチャを他の多くのコンピューティング状況で使用し、他の種類のサービスを提供してもよく、且つ本発明はウェブサーバシステムに限定されるものではない。
【０１２９】
−内容分散ネットワークの一部としての分散ＶＳＦ
一実施例において、ＶＳＦは、広域ＶＳＦを使用して内容分散ネットワーク（ＣＤＮ）を提供する。ＣＤＮは、データの分散キャッシングを行うキャッシングサーバのネットワークである。キャッシングサーバのネットワークは、例えば、Ｉｎｋｔｏｍｉ Ｃｏｒｐｏｒａｔｉｏｎ， Ｓａｎ Ｍａｔｅｏ， Ｃａｌｉｆｏｒｎｉａから販売されているＴｒａｆｆｉｃＳｅｒｖｅｒ（ＴＳ）ソフトウェアを使用して実施できる。ＴＳはクラスタアウェアシステムであり、システムは、更に多くのＣＰＵがキャッシングトラフィックサーバコンピューティング要素の集合に追加されると、拡張する。従って、ＣＰＵの追加が拡張の機構であるシステムに非常に適している。
【０１３０】
この構成において、システムは、ＴＳなどのキャッシングソフトウェアを実行するＶＳＦの部分に更に多くのＣＰＵを動的に追加できるので、バースト状のウェブトラフィックが生じるのに近い地点でキャッシュ容量を増大させることが可能である。その結果、ＣＤＮは、適法的方法でＣＰＵおよびＩ／Ｏ帯域幅において動的に拡張するように構成される。
【０１３１】
−ホステッドイントラネットアプリケーションのＶＳＦ
ホストおよび管理されたサービスとして、企業リソースプランニング（ＥＲＰ）、ＯＲＭおよびＣＲＭソフトウェアなどのイントラネットアプリケーションの提供への興味が増大している。Ｃｉｔｒｉｘ ＷｉｎＦｒａｍｅおよびＣｉｔｒｉｘ ＭｅｔａＦｒａｍｅなどの技術により、企業は、Ｗｉｎｄｏｗｓ（登録商標）ＣＥ機器またはウェブブラウザなどの小型軽量クライアント上でのサービスとしてＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）アプリケーションを提供することができる。ＶＳＦは拡張可能にこのようなアプリケーションをホストすることが可能である。
【０１３２】
例えば、ドイツのＳＡＰ Ａｋｔｉｅｎｇｅｓｅｌｌｓｃｈａｆｔより販売されているＳＡＰ Ｒ／３ ＥＲＰソフトウェアにより、企業は多数のアプリケーションおよびデータサーバを使用してバランスをロードさせることができる。ＶＳＦの場合、リアルタイムの要求または他の要因に基づいてＶＳＦを拡張するために、企業は更に多くのアプリケーションサーバ（例えば、ＳＡＰダイアログサーバ）をＶＳＦに動的に追加する。
【０１３３】
同様に、Ｃｉｔｒｉｘ Ｍｅｔａｆｒａｍｅにより、更に多くのＣｉｔｒｉｘサーバを追加することにより、ホステッドＷｉｎｄｏｗｓ（登録商標）アプリケーションを実行するサーバファーム上でＷｉｎｄｏｗｓ（登録商標）アプリーションユーザを拡張することができる。この場合、ＶＳＦに対し、Ｃｉｔｒｉｘ ＭｅｔａＦｒａｍｅ ＶＳＦは、更に多くのＭｅｔａｆｒａｍｅがホストするＷｉｎｄｏｗｓ（登録商標）アプリケーションのユーザを収容するために更に多くのＣｉｔｒｉｘサーバを動的に追加する。多くのほかのアプリケーションが上述した例と同様にホストされることが明らかとなる。
【０１３４】
−ＶＳＦとの顧客相互作用
ＶＳＦは求めに応じて生成されるため、ＶＳＦを「所有する」ＶＳＦ顧客または組織は、ＶＳＦをカスタマイズするために様々な方法でシステムと互いに影響し合うことができる。例えば、ＶＳＦは制御プレーンを介して即座に生成および変更されるので、ＶＳＦ顧客は特権アクセスが許されて、そのＶＳＦ自身を生成および変更してもよい。特権アクセスは、ウェブページおよび保全アプリケーション、トークンカード認証、ケルベロス交換、または他の適切な保全要素によって与えられたパスワード認証を使用して与えられる。
【０１３５】
一実施例において、一式のウェブページは、コンピューティング要素または別個のサーバによって供給される。ウェブページにより、顧客は、層の数、特定の層におけるコンピューティング要素の数、各要素に対して使用されるハードウェアおよびソフトウェアプラットフォーム、どの種類のウェブサーバ、アプリケーションサーバ、またはデータベースサーバソフトウェアこれらのコンピューティング要素上で事前に構成するかなどを指定することによって、カスタムＶＳＦを生成することができる。従って、顧客は仮想供給コンソールを備えている。
【０１３６】
顧客またはユーザがこのような供給情報を入力した後、制御プレーンはオーダーを解析および評価し、それを実行するために待ち行列に入れる。オーダーは人間の管理者が再検討して、適切であることを確認することができる。企業のクレジット確認を実行させて、要求されたサービスに対して支払いを行う適切なクレジットを有していることを確認できる。供給オーダーが承認されると、制御プレーンは順序に適合するＶＳＦを構成し、ＶＳＦにおける一又は二以上のコンピューティング要素へのルートアクセスを与えるパスワードを顧客に返す。次に、顧客はアプリケーションのマスターコピーをアップロードして、ＶＳＦで実行することができる。
【０１３７】
コンピューティンググリッドを採用する企業が営利目的の企業である場合、ウェブページから、クレジットカード、ＰＯ番号、電子小切手、または他の支払方法などの支払いに関する情報も受信することができる。
【０１３８】
別の実施例において、ウェブページにより、顧客は、リアルタイムロードに基づいて、要素の最小数と最大数との間のＶＳＦの自動拡大縮小など、幾つかのＶＳＦサービスプランのうちの１つを選択することができる。顧客は、ウェブサーバなどの特定の層におけるコンピューティング要素の最小数、またはＶＳＦ最小サーバ容量を有していなければならない期間などのパラメータの変更を可能にする制御値を有することができる。パラメータは、顧客の為替手形割引率を自動的に調整し、且つ課金ログファイル項目を生成する課金ソフトウェアにリンクしていてもよい。
【０１３９】
特権アクセス機構により、顧客は報告書を得て、使用、ロード、毎秒のヒット数またはトランザクション数に関するリアルタイム情報を監視し、リアルタイム情報に基づくＶＳＦの特徴を調整することができる。上記特色により、サーバファームの構築に対する従来の手動による方法よりも優れた利点が得られる。従来の方法では、ユーザは、様々な方法でサーバを追加し、サーバファームを構成する面倒な手動手順を介さずに、サーバファームの特性を自動的に変更することはできない。
【０１４０】
−ＶＳＦに対する課金モデル
ＶＳＦの動的性質を考えると、コンピューティンググリッドおよびＶＳＦを採用する企業は、ＶＳＦのコンピューティング要素および記憶要素の実際の使用に基づくＶＳＦの課金モデルを使用して、ＶＳＦを所有する顧客に対してサービス料金を請求することができる。ここに開示するＶＳＦアーキテクチャおよび方法は、あるＶＳＦのリソースは静的に指定されないので、「即金払い」課金モデルを可能にする。従って、そのサーバファームの使用負荷が極めて変わりやすい特定の顧客は、一定のピークサーバ容量に関連する料金は課金されず、使用、瞬間使用などの実行平均を反映する料金が課金されるので、料金を節約することができる。
【０１４１】
例えば、企業は、１０台のサーバなどのコンピューティング要素の最小数に対する均一料金を規定し、且つリアルタイムの負荷が１０以上の要素を必要としたときを規定する課金モデルを使用して運営するので、ユーザは、何台の追加サーバが必要であり、且つそれらが必要であった時間に基づいて、追加サーバの追加料金で課金される。このような課金の単位は、請求されるリソースを反映してもよい。例えば、課金は、ＭＩＰＳ時間、ＣＰＵ時間、ＣＰＵ千秒などの単位で表してもよい。
【０１４２】
−顧客可視制御プレーンＡＰＩ
他の方法では、ＶＳＦの容量は、リソース変更のための制御プレーンの呼び出しを規定するアプリケーションプログラミングインタフェース（ＡＰＩ）を顧客に与えることで、制御されてもよい。従って、顧客が用意したアプリケーションプログラムは、ＡＰＩを使用して呼び出しまたは要求を発し、更に多くのサーバ、更に多くのストレージ、更に高い処理能力などを要求することができる。この方法は、顧客がコンピューティンググリッド環境について知り、制御プレーンが与える能力を利用するためにアプリケーションプログラムを必要とするときに使用してもよい。
【０１４３】
上記アーキテクチャにおいて、何れの部分も、顧客がコンピューティンググリッドとの使用でそのアプリケーションを変更する必要はない。既存のアプリケーションは、手動構成したサーバファームで動作するのと同様に動作する。しかしながら、制御プレーンによって与えられるリアルタイム負荷監視機能に基づいて必要とするコンピューティングリソースをよりよく理解するのであれば、アプリケーションはコンピューティンググリッドで可能なダイナミズムを利用することができる。アプリケーションプログラムによるサーバファームのコンピューティング容量の変更を可能にする上記性質のＡＰＩは、サーバファームの構築に対する既存の手動方法を用いては可能ではない。
【０１４４】
−自動更新およびバージョニング
ここに開示する方法および機構を使用し、制御プレーンは、ＶＳＦのコンピューティング要素で実行されるオペレーティングシステムソフトウェアの自動更新およびバージョニングを行うことができる。従って、エンドユーザまたは顧客は、新たなパッチ、バグフィックスなどでオペレーティングシステムを更新することについて心配する必要はない。制御プレーンは、このようなソフトウェア要素が受信されるとそのライブラリを維持し、影響のあった全てのＶＳＦのコンピューティング要素にこれらを自動的に分散およびインストールすることができる。
【０１４５】
実施機構
コンピューティング要素および制御プレーンは幾つかの形式で実施されてもよく、且つ本発明は特定の形式に限定されることはない。一実施例において、各コンピューティング要素は、不揮発性記憶装置１９１０を除き、図１９に示す要素を有する汎用デジタルコンピュータであり、また制御プレーンは、上記プロセスを実施するプログラム命令の制御の下で動作する図１９に示す種類の汎用デジタルコンピュータである。
【０１４６】
図１９は、本発明の実施例が実施されうるコンピュータシステム１９００を示すブロック図である。コンピュータシステム１９００は、情報を伝達するバス１９０２または他の通信機構、および情報を処理するためにバス１９０２に接続されたプロセッサ１９０４を含んでいる。コンピュータシステム１９００はまた情報とプロセッサ１９０４が実行する命令を保存するためにバス１９０２に接続されたランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置などのメインメモリ１９０６を含んでいる。メインメモリ１９０６も、プロセッサ１９０４が実行する命令の実行中に、一時的数値変数や他の中間情報を保存するのに使用することができる。コンピュータシステム１９００は更に、静的情報およびプロセッサ１９０４の命令を保存するために、バス１９０２に接続されたリードオンリメモリ（ＲＯＭ）１９０８や他の静的記憶装置を含んでいる。磁気ディスクや光ディスクなどの記憶装置１９１０が設けられ、情報および命令を保存するためにバス１９０２に接続されている。
【０１４７】
コンピュータシステム１９００は、情報をコンピュータユーザに表示するために、陰極線管（ＣＲＴ）などのディスプレイ１９１２にバス１９０２を介して接続されていてもよい。英数字および他のキーを含む入力機器１９１４は、情報および命令の選択をプロセッサ１９０４に伝達するために、バス１９０２に接続されている。他の種類のユーザ入力機器は、方向情報および命令の選択をプロセッサ１９０４に伝達し、且つカーソルの動きをディスプレイ１９１２上で制御するためのマウス、トラックボール、カーソル方向キーなどのカーソルコントロール１９１６である。この入力機器は一般に、機器が平面における位置を指定することを可能にする２つの軸、すなわち第１軸（例えばｘ）および第２軸（例えばｙ）における２つの自由度を有している。
【０１４８】
本発明は、拡張可能コンピューティングシステムを制御するための、コンピュータシステム１９００の使用に関連している。本発明の一実施例によれば、拡張可能コンピューティングシステムの制御は、メインメモリ１９０６に含まれる一又は二以上の命令の一又は二以上のシーケンスを実行するプロセッサ１９０４に応じて、コンピュータシステム１９００によって行われる。このような命令は、記憶装置１９１０などの別のコンピュータで読み取り可能な媒体からメインメモリ１９０６に読み込まれる。メインメモリ１９０６に含まれる命令のシーケンスを実行することにより、プロセッサ１９０４は、上記のプロセス工程を実行する。マルチ処理構成において一又は二以上のプロセッサを使用し、メインメモリ１９０６に含まれる命令のシーケンスを実行してもよい。別の実施例においては、配線接続された回路を、ソフトウェア命令の代わりに、あるいはこれと組み合わせて使用し、本発明を実施してもよい。従って、本発明の実施例は、ハードウェア回路およびソフトウェアの特定の組合せに限定されない。
【０１４９】
ここで使用する用語「コンピュータで読み取り可能な媒体」は、プロセッサ１９０４に命令を与えて実行することに関連する媒体を意味する。このような媒体は、不揮発性媒体、揮発性媒体および伝送媒体を含むがこれらに限定されない多くの形式を取ることができる。不揮発性媒体は例えば、記憶装置１９１０などの光または磁気ディスクを含む。揮発性媒体は、メインメモリ１９０６などの動的メモリを含む。伝送媒体は、バス１９０２を構成する配線を含む同軸ケーブル、銅線および光ファイバーを含む。伝送媒体も、無線および赤外線データ通信の間に生成されるような音波や光波の形式を取ることができる。
【０１５０】
コンピュータで読み取り可能な媒体の一般的形式は、例えば、以下に説明するようなフロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、ほかの磁気媒体、ＣＤ−ＲＯＭ、他の光媒体、パンチカード、紙テープ、穴のパターンを有する他の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、他のメモリチップまたはカートリッジ、搬送波、またはコンピュータが読み取り可能なほかの媒体を含む。
【０１５１】
コンピュータが読み取り可能な媒体の様々な形式は、プロセッサ１９０４に一又は二以上の命令の一又は二以上のシーケンスを送って実行させることに関連していてもよい。例えば、命令はまず、遠隔コンピュータの磁気ディスクに送られる。遠隔コンピュータはその動的メモリに命令をロードして、モデムを使用して電話回線上で命令を送る。コンピュータシステム１９００に対して遠隔にあるモデムは、電話回線上のデータを受信し、赤外線トランスミッタを使用してデータを赤外線信号に変換することができる。バス１９０２に接続された赤外線ディテクタは、赤外線信号で運ばれるデータを受信して、バス１９０２にデータを出す。バス１９０２はデータをメインメモリ１９０６に送り、ここからプロセッサ１９０４は命令の検索と実行を行う。メインメモリ１９０６が受信した命令は、プロセッサ１９０４の実行の前または後で記憶装置１９１０に随意に保存することができる。
【０１５２】
コンピュータシステム１９００は、バス１９０２に接続された通信インタフェース１９１８も含んでいる。通信インタフェース１９１８は、ローカルネットワーク１９２２に接続されたネットワークリンク１９２０へ接続する双方向データ通信を行う。例えば、通信インタフェース１９１８は、対応する種類の電話回線へのデータ通信接続を行うためのデジタル総合サービスネットワーク（ＩＳＤＮ）カードまたはモデムであってもよい。他の例とでは、通信インタフェース１９１８は、互換性のあるＬＡＮへのデータ通信接続を行うためのローカルエリアネットワーク（ＬＡＮ）であってもよい。無線リンクも実施することができる。このような実施において、通信インタフェース１９１８は、様々な種類の情報を表すデジタルデータストリームを伝える電気、電磁または光信号を送受信する。
【０１５３】
ネットワークリンク１９２０は一般に、一又は二以上のネットワークを介して、他のデータ機器へのデータ通信を行う。例えば、ネットワークリンク１９２０は、ローカルネットワーク１９２２を介して、インターネットサービスプロバイダ（ＩＳＰ）１９２６によって運営されるホストコンピュータ１９２４またはデータ機器への接続を提供する。ＩＳＰ１９２６は、一般に「インターネット」と現在呼ばれている世界規模パケットデータ通信ネットワーク１９２８を介してデータ通信サービスを提供する。ローカルネットワーク１９２２およびインターネット１９２８は共に、デジタルデータストリームを伝える電気、電磁または光信号を使用する。様々なネットワークおよびネットワークリンク１９２０上の信号、および通信インタフェース１９１８を介して、コンピュータシステム１９００に対してデジタルデータを送受する信号は、情報を運ぶ搬送波の典型的な形である。
【０１５４】
コンピュータシステム１９００は、ネットワーク、ネットワークリンク１９２０および通信インタフェース１９１８を介して、メッセージを送信し、且つプログラムコードを含むデータを受信することができる。インターネットの例では、サーバ１９３０は、インターネット１９２８、ＩＳＰ１９２６、ローカルネットワーク１９２２、および通信インタフェース１９１８を介して、アプリケーションプログラムの要求コードを送信する。本発明によれば、このようなダウンロードしたアプリケーションは、ここに説明する拡張可能コンピューティングシステムの制御を規定する。
【０１５５】
受信コードは、受信されるとプロセッサ１９０４により実行、および／または後で実行するために記憶装置１９１０あるいは他の不揮発性ストレージに保存しておいてもよい。このように、コンピュータシステム１９００は、搬送波という形でアプリケーションコードを得ることができる。
【０１５６】
ここに開示したコンピューティンググリッドは、時にパワーグリッドと呼ばれる公共電力ネットワークと概念的に比較される。パワーグリッドは、単一の大規模電力インフラストラクチャを介して電力サービスを得るために、多数の関係者に拡張可能手段を提供する。同様に、ここに開示したコンピューティンググリッドは、単一の大規模コンピューティングインフラストラクチャを使用することによって、多数の組織にコンピューティングサービスを提供する。パワーグリッドを使用するので、電力消費者はその個人電力設備を自主的に管理することはない。例えば、ユーティリティ消費者がその設備または共有設備において個人用発電機を運転させ、個人でその容量および増加を管理する理由はない。その代わりに、パワーグリッドは人口の大部分へ広範囲に電力を供給することができるので、大きなスケールメリットが得られる。同様に、ここに開示するコンピューティンググリッドは、単一の大規模なコンピューティングインフラストラクチャを使用して、人口の大部分にコンピューティングサービスを提供することができる。
【０１５７】
上記の詳述において、具体的な実施例に関連して本発明を説明した。しかしながら、本発明の広大な精神および範囲から逸脱することなく、様々な改良および変更を本発明に加えることが可能であることは明白となろう。従って、説明および図面は、限定的意味ではなく例証において考慮される。
【図面の簡単な説明】
【図１Ａ】
図１Ａは、単一のコンピューティング要素トポロジーを使用する単純なウェブサイトのブロック図である。
【図１Ｂ】
図１Ｂは、１層ウェブサーバファームのブロック図である。
【図１Ｃ】
図１Ｃは、３層ウエブサーバファームのブロック図である。
【図２】
図２は、ローカルコンピューティンググリッドを含む拡張可能コンピューティングシステム２００の１つの構成を示すブロック図である。
【図３】
図３は、ＳＡＮゾーンを特徴付ける典型的な仮想サーバファームのブロック図である。
【図４Ａ】
図４Ａは、コンピューティング要素の追加および仮想サーバファームからの要素の除去に関連する連続工程を示すブロック図である。
【図４Ｂ】
図４Ｂは、コンピューティング要素の追加および仮想サーバファームからの要素の除去に関連する連続工程を示すブロック図である。
【図４Ｃ】
図４Ｃは、コンピューティング要素の追加および仮想サーバファームからの要素の除去に関連する連続工程を示すブロック図である。
【図４Ｄ】
図４Ｄは、コンピューティング要素の追加および仮想サーバファームからの要素の除去に関連する連続工程を示すブロック図である。
【図５】
図５は、仮想サーバファームシステム、コンピューティンググリッド、監視機構の実施例のブロック図である。
【図６】
図６は、仮想サーバファームの論理接続のブロック図である。
【図７】
図７は、仮想サーバファームの論理接続のブロック図である。
【図８】
図８は、仮想サーバファームの論理接続のブロック図である。
【図９】
図９は、制御プレーンおよびデータプレーンの論理関係のブロック図である。
【図１０】
図１０は、マスター制御選択プロセスの状態図である。
【図１１】
図１１は、スレーブ制御プロセスの状態図である。
【図１２】
図１２は、マスター制御プロセスの状態図である。
【図１３】
図１３は、中央制御プロセッサおよび多数の制御プレーンおよびコンピューティンググリッドのブロック図である。
【図１４】
図１４は、制御プレーンおよびコンピューティンググリッドの部分を実施するアーキテクチャのブロック図である。
【図１５】
図１５は、ファイアウォールによって保護されるコンピューティンググリッドを有するシステムのブロック図である。
【図１６】
図１６は、制御プレーンをコンピューティンググリッドに接続するアーキテクチャのブロック図である。
【図１７】
図１７は、ＶＬＡＮタグとＩＰアドレスを密に結合する配置のブロック図である。
【図１８】
図１８は、ＷＡＮ接続上で拡張した複数のＶＳＦのブロック図である。
【図１９】
図１９は、実施例が実施されるコンピュータシステムのブロック図である。
【発明の属する技術分野】
本発明は一般に、データ処理に関する。本発明は、特にコンピューティンググリッドを制御する方法および装置に関する。
【０００２】
【発明が解決しようとする課題】
今日のウェブサイトおよび他のコンピュータシステムのビルダーは、多くの興味深いシステムプランニング問題を抱えている。これらの問題には、容量プランニング、サイト利用可能度およびサイトの安全性が含まれている。これらの目標を達成するには、潜在的に大きく複雑であるかもしれないサイトの設計および運営が可能なトレーニングを受けた人員を探し出して、雇用することが必要である。多くの組織にとって、大きなサイトの設計、構築、運営は主力事業でないことが多いため、このような人員を探し出して雇用することは難しいことが分かっている。
【０００３】
１つの方法として、他の企業の他のウェブサイト共に同じ場所に配置された、第三者サイトの企業ウェブサイトを採用した。このような外部委託施設は現在、Ｅｘｏｄｕｓ、ＡｂｏｖｅＮｅｔ、ＧｌｏｂａｌＣｅｎｔｅｒなどの企業から利用できる。これらの施設により、多数の顧客が共有する物理的スペース、冗長ネットワーク、発電施設が与えられる。
【０００４】
外部委託ウェブサイトの採用により、ウェブサイトの確立と維持の負担が大きく減るが、企業からウェブサイトの維持に関連する全ての問題を取り除くことにはならない。企業は、その施設の構築、運営、増大の間に、そのコンピューティング構造基盤に関する多くの仕事を行なわなければならない。このような施設で採用された企業の情報テクノロジー管理者は、施設でのその演算装置の手動選択、設置、構成、維持に関して責任がある。管理者は、リソースプランニングおよび取り扱いピーク容量などの困難な問題に取り組まなければならない。特に、管理者は、需要に対処するために外部委託企業からリソース需要および要求リソースを予測する必要がある。多くの管理者は、予期しないピーク需要に対する緩和策として、必要とする以上に実質的に多いリソースを要求することで十分な容量を確保する。残念ながら、これによって未使用の容量が多大なものになり、ウェブサイトを採用するための企業の諸経費が増加してしまう。
【０００５】
外部委託企業も、サーバ、ソフトウェア、電力施設を含む完全計算施設を提供しても、成長に伴って同一の手動の誤りやすい管理処置が必要となるので、外部委託企業にとって施設の拡大および成長は簡単ではない。さらに、予期しないピーク需要に対する容量プランニングと共に問題が残っている。この場合、外部委託企業は、かなりの量の未使用容量を維持することがある。
【０００６】
さらに、外部委託企業が管理するウェブサイトの必要条件は異なることがしばしばある。例えば、ある企業では、そのウェブサイトを独立して運営および制御するための能力が必要になる。他の企業では、そのウェブサイトを、外部委託企業で共に配置された他の全てのサイトから分離させる特定の種類またはレベルの安全確保が必要となる。別の例として、ある企業では、どこかに配置された企業イントラネットへの確実な接続が必要となる。
【０００７】
さらに、様々なウェブサイトは、内部トポロジーにおいて異なる。あるサイトは単に、ウェブロードバランサによってロードバランスの取れたウェブサーバ列から構成される。適切なロードバランサはＣｉｓｃｏ Ｓｙｓｔｅｍｓ， Ｉｎｃ．のＬｏｃａｌ Ｄｉｒｅｃｔｏｒ、Ｆ５ＬａｂｓのＢｉｇＩＰ、ＡｌｅｔｏｎのＷｅｂ Ｄｉｒｅｃｔｏｒなどである。他のサイトは多層構成されることもあり、これによってウェブサーバ列はハイパーテキストプロトコル（ＨＴＴＰ）要求に対処できるが、アプリケーションロジックの大半は別のアプリケーションサーバにおいて実施される。これらのアプリケーションサーバを、データベースサーバの層に再び接続しなければならないことがある。
【０００８】
このような異なる構造シナリオの幾つかを、図１Ａ、図１Ｂ、図１Ｃに示す。図１Ａは単純なウェブサイトのブロック図であり、ＣＰＵ１０２およびディスク１０４を含む単一のコンピューティング要素またはマシン１００から成る。マシン１００は、インターネットとして知られる世界規模のパケット交換式データネットワーク１０６、または他のネットワークに接続されている。マシン１００は、上述したタイプの同一位置サービス内に収容されていてもよい。
【０００９】
図１Ｂは、複数のウェブサーバＷＳＡ、ＷＳＢ、ＷＳＣを含む１層ウェブサーバファーム１１０のブロック図である。各ウェブサーバは、インターネット１０６に接続されたロードバランサ１１２に接続されている。ロードバランサはサーバ間のトラフィックを分割して、各サーバのバランスのとれた処理ロードを維持する。ロードバランサ１１２も、ウェブサーバを許可されていないトラフィックから保護するためのファイアウォールを含むか、あるいはこれに接続されていてもよい。
【００１０】
図１Ｃは、ウェブサーバＷ１、Ｗ２などの層、アプリケーションサーバＡ１、Ａ２などの層、およびデータベースサーバＤ１、Ｄ２などの層を含む３層サーバファーム１２０を示す。ウェブサーバは、ＨＴＴＰ要求に対処するために設けられる。アプリケーションサーバは、アプリケーションロジックの大部分を実行する。データベースサーバは、データベース管理システム（ＤＢＭＳ）ソフトウェアを実行する。
【００１１】
構成する必要のあるウェブサイトの種類のトポロジーが多様化され、該当する企業の必要条件が変化しているので、大規模ウェブサイトを構成する唯一の方法は、各サイトを物理的にカスタマイズすることであると考えられる。多くの組織はそれぞれ個別に同一問題に取り組んでおり、ゼロから各ウェブサイトをカスタマイズしている。これは非能率的であり、異なる企業で大量の同一の仕事が生じることになる。
【００１２】
従来の方法の別の問題は、リソースと容量プランニングである。ウェブサイトは、異なる日、またはその日の内の異なる時間で、非常に異なるレベルのトラフィックを受信する。ピークトラフィック時間では、ウェブサイトのハードウェアまたはソフトウェアは、オーバーロードのために適当な時間内で要求に応答することができないことがある。他の時間では、ウェブサイトのハードウェアまたはソフトウェアには過度の容量があり、十分に利用されていない。従来の方法では、過度のコストを負ったり過剰容量となることなく、ピークトラフィックに対処する十分なハードウェアおよびソフトウェアを有することにおけるバランスを見つけることは、困難な問題である。多くのウェブサイトは適切なバランスを見つけることができず、慢性的に過小容量または過剰容量に悩まされている。
【００１３】
別の問題は、ヒューマンエラーによって引き起こされる故障である。手動構成されたサーバファームを使用する現在の方法において存在する大きな潜在的災害は、新しいサーバをライブサーバ内に構成するときのヒューマンエラーにより、サーバファームが誤動作し、これによってウェブサイトのユーザへのサービスが失われてしまう可能性があることである。
【００１４】
上記に基づき、この分野において、カスタム構成を必要とすることなく、要求があり次第、直ちに簡単に拡張することのできるコンピューティングシステムを提供する改善された方法および装置が明確に必要である。
【００１５】
さらに、トラフィックスループットの変化を明らかにするためにそれぞれ必要に応じて拡張または縮小可能な多数の分離処理ノードの生成をサポートするコンピューティングシステムも必要である。
【００１６】
さらに、このような拡張可能コンピューティングシステムとその構成分離処理ノードを制御する方法および装置も必要である。他の必要性もここに示す開示内容から明らかとなるであろう。
【００１７】
【発明の開示】
本発明の１つの態様によれば、上記必要性、および以下の説明により明らかとなる他の必要性は、大規模なコンピューティング構造（「コンピューティンググリッド」）に基づき、非常に拡張性があり、非常に利用しやすくて確実なデータ処理サイトを制御および管理する方法および装置によって達せられる。コンピューティンググリッドは、物理的に構成され、その後要求に応じて様々な組織に対して論理的に分割される。コンピューティンググリッドは、一又は二以上のＶＬＡＮスイッチおよび一又は二以上の記憶領域ネットワーク（ＳＡＮ）スイッチに接続された非常に多数のコンピューティンググ要素を含んでいる。複数の記憶装置はＳＡＮスイッチに接続され、且つ適切な切り替えロジックおよびコマンドを介して、一又は二以上のコンピューティング要素に選択的に接続されてもよい。ＶＬＡＮスイッチの１つのポートは、インターネットなどの外部ネットワークに接続される。監視機構、層、マシンまたはプロセスは、ＶＬＡＮスイッチおよびＳＡＮスイッチに接続される。
【００１８】
初めに、全ての記憶装置およびコンピューティング要素は、アイドルプールに割り当てられる。プログラム制御の下、監視機構はＶＬＡＮスイッチおよびＳＡＮスイッチのポートを一又は二以上のコンピューティング要素および記憶装置に接続するように動的に構成する。その結果、このような要素および装置はアイドルプールから論理的に除去されて、一又は二以上の仮想サーバファーム（ＶＳＦ）またはインスタントデータセンタ（ＩＤＣ）の一部となる。各ＶＳＦコンピューティング要素は、ブートストラップ操作および生成実行を行なうためにコンピューティング要素が使用できるブートイメージを含む記憶装置に向けられるか、あるいは関連付けられる。
【００１９】
本発明の１つの態様によると、監視層は、一又は二以上のスレーブ制御プロセス機構に通信接続された一又は二以上のマスター制御プロセス機構を含む制御機構階層から成る制御プレーンである。一又は二以上のマスター制御プロセス機構は、スレーブ制御プロセス機構のローディングに基づいて、スレーブ制御プロセス機構を割り当ておよび割り当て解除する。一又は二以上のマスター制御プロセス機構は、処理および記憶リソースのサブセットを選択することによってＩＤＣを確立するようにスレーブ制御プロセス機構に支持する。一又は二以上のマスター制御プロセス機構は、スレーブ制御プロセス機構の周期的な検診を行なう。応答がなかったり、あるいは異常終了したスレーブ制御機構は再起動される。別のスレーブ制御機構は開始されて、再開できないスレーブ制御機構の代わりとなる。スレーブ制御機構は、マスター制御機構の周期的な検診を行なう。マスタースレーブ制御プロセス機構が異常終了すると、スレーブ制御プロセス機構が選択されて新たなマスター制御プロセス機構となり、以上終了したマスター制御プロセス機構の代わりとなる。
【００２０】
コンピューティンググリッドを一度物理的に構成し、且つ要求に応じてコンピューティンググリッドの部分を確実且つ動的に様々な組織に割り当てることにより、各サイトのカスタマイズのときには困難であったスケールメリットが得られる。
【００２１】
本発明は、添付の図面において、限定するのではなく、一例として図解されており、且つその中において同一の参照番号は同様の要素を示している。
【００２２】
【本発明の実施の形態】
以下の説明において、説明の目的で、本発明を完全に理解してもらうために多数の特定の細部が述べられている。しかしながら、本発明がこれらの特定の細部無しに実施されることは当業者に明らかとなるであろう。他の例では、本発明が不必要に分かりにくくなってしまうのを回避するために、既知の構造および装置がブロック図で示されている。
【００２３】
仮想サーバファーム（ＶＳＦ）
一実施例によると、大規模なコンピューティング構造（「コンピューティンググリッド」）が設けられる。コンピューティンググリッドは物理的に一度構成され、その後要求に応じて論理的に区画されてもよい。コンピューティンググリッドの一部は、複数の企業または組織のそれぞれに割り当てられる。各組織のコンピューティンググリッドのロジック部分は、仮想サーバファーム（ＶＳＦ）と呼ばれる。各組織はそのＶＳＦの独立した運営管理制御を維持する。各ＶＳＦは、サーバファームまたは他の要素に与えられたリアルタイム要求に基づいて、ＣＰＵの数、記憶容量およびディスク、ネットワーク帯域幅を動的に変更することができる。ＶＳＦは同一の物理的コンピューティンググリッドから全て論理的に生成されるが、各ＶＳＦは全てのほかの組織のＶＳＦから保護されている。ＶＳＦは、イントラネットを他の組織のＶＳＦにさらすことなく、個人専用回線または仮想プライベートネットワーク（ＶＰＮ）を使用することにより、イントラネットに逆に接続することができる。
【００２４】
組織は、コンピュータへの完全（例えば、スーパーユーザまたはルート）管理アクセスを実行し、これらのコンピュータが接続されたローカルエリアネットワーク（ＬＡＮ）の全てのトラフィックを観察することができるが、それに割り当てられたコンピューティンググリッドの部分、つまりＶＳＦにおけるデータおよびコンピューティング要素にのみアクセスできる。一実施例によると、これは、ＶＳＦの安全限界が動的に拡張および縮小する動的ファイアウォール方式を使用することによって可能となる。各ＶＳＦを使用して、インターネット、イントラネットまたはエキストラネットを介してアクセスできる組織の内容とアプリケーションを採用することができる。
【００２５】
コンピューティング要素およびその関連するネットワーキング、および記憶要素の構成と制御は、コンピューティンググリッドにおけるコンピューティング要素の何れかによって直接アクセスすることのできない監視機構によって行なわれる。便宜上、本文書では、監視機構は一般に制御プレーンと呼ばれ、一又は二以上のプロセッサまたはプロセッサのネットワークから構成されていてもよい。監視機構は、スーパバイザ、コントローラなどで構成されていてよい。ここに説明するように、他の方法を用いることもできる。
【００２６】
制御プレーンは、例えばネットワーク内または他の手段によって相互接続される一又は二以上のサーバなど、監視の目的用に割り当てられたコンピューティング要素の完全独立集合上で実施される。制御プレーンは、グリッドのネットワーキングおよび記憶要素の特殊制御ポートまたはインタフェースを介して、コンピューティンググリッドのコンピューティング、ネットワーキングおよび記憶要素に対して、制御動作を行なう。制御プレーンはシステムの切り替え要素に物理的インタフェースを与え、システムにおけるコンピューティング要素の負荷を監視し、グラフィカルユーザインタフェースまたは他の適切なユーザインタフェースを使用して運営管理機能を与える。
【００２７】
制御プレーンを実施するのに使用するコンピュータはコンピュータグリッド（および特定のＶＳＦ）におけるコンピュータには論理的には不可視であり、コンピュータグリッドにおける要素を介して、あるいは外部コンピュータから、決して攻撃されたり、破壊されることはない。制御プレーンのみがコンピュータグリッドにおける機器の制御ポートへの物理的接続部を有しており、これは特定のＶＳＦにおけるメンバーシップを制御する。コンピューティングにおける機器はこれらの特殊制御ポートを介してのみ構成できるので、コンピューティンググリッドにおけるコンピューティング要素はその安全限界を変更したり、認められていない記憶またはコンピューティング機器へのアクセスを行なうことはできない。
【００２８】
従って、ＶＳＦにより、組織は、大規模共有コンピューティングインフラストラクチャから動的に作られたプライベートサーバーファーム、すなわちコンピューティンググリッドから構成されたように見えるコンピューティング設備と連動することができる。ここに説明するコンピューティングアーキテクチャと接続された制御プレーンは、そのプライバシーと保全性がコンピューティンググリッドの機器のハードウェアにおいて実施されるアクセス制御機構によって保護されるプライベートサーバファームを与える。
【００２９】
制御プレーンは、各ＶＳＦの内部トポロジーを制御する。制御プレーンはここに説明するコンピュータ、ネットワークスイッチおよび記憶ネットワークスイッチの基本相互接続を取り、これらを使用して様々なサーバファーム構成を作成することが可能である。これらには、限定されるものではないが、ロードバランサによって前処理された単層ウェブサーバファーム、および多層構成が含まれており、ウェブサーバはアプリケーションサーバと通信し、且つアプリケーションサーバはデータベースサーバと通信を行なう。様々な負荷バランシング、多層化、ファイアウォール構成が可能である。
【００３０】
コンピューティンググリッド
コンピューティンググリッドは単一の場所に存在し、幅広い領域に分散させることができる。最初に、本書はローカルエリア技術でのみ構成される単一の建物のサイズのネットワークにおける、コンピュータグリッドについて説明する。次に、本書は、コンピュータグリッドを広域ネットワーク（ＷＡＮ）上で分散させる場合について説明する。
【００３１】
図２は、ローカルコンピューティンググリッド２０８を含む拡張可能コンピューティングシステム２００の１つの構成を示すブロック図である。本書において、「拡張可能」とは一般に、システムがフレキシブルで拡張性があり、要求があり次第特定の企業またはユーザに対して低下あるいは上昇させた計算力を与える能力を有していることを意味する。ローカルコンピューティンググリッド２０８は、多数のコンピューティング要素ＣＰＵ１、ＣＰＵ２、．．．ＣＰＵｎから成る。実施例において、１０，０００個以上のコンピューティング要素が存在している。これらのコンピューティング要素は長期の要素ごとの状態情報を含んでいたり、保存することはないので、ローカルディスクなどの永続性または不揮発性ストレージなしで構成してもよい。その代わり、全ての長期の状態情報は、コンピューティング要素とは別に、一又は二以上のＳＡＮスイッチ２０２を含む記憶領域ネットワーク（ＳＡＮ）を介してコンピューティング要素に接続される複数のディスク、ディスク１、ディスク２、．．．ディスクｎに保存される。適切なＳＡＮスイッチの例は、ＢｒｏｃａｄｅおよびＥｘｃｅｌから販売されている。
【００３２】
全てのコンピューティング要素は、仮想ＬＡＮ（ＶＬＡＮ）に分割される一又は二以上のＶＬＡＮスイッチ２０４を介して、相互接続される。ＶＬＡＮスイッチ２０４はインターネット１０６に接続されている。一般に、コンピューティング要素は、ＶＬＡＮスイッチに接続された１つまたは２つのネットワークインタフェースを含んでいる。便宜上、図２において、全てのノードが２つのネットワークインタフェースを有しているが、ネットワークインタフェースがこれよりも少ないまたは多いノードもある。多くの製造供給元は現在、ＶＬＡＮ機能をサポートするスイッチを提供している。例えば、適切なＶＬＡＮスイッチはＣｉｓｃｏ Ｓｙｓｔｅｍｓ， ＩｎｃおよびＸｔｒｅｍｅ Ｎｅｔｗｏｒｋｓより入手可能である。同様に、ＳＡＮを構成するための入手可能製品は多数あり、これにはファイバーチャネルスイッチ、ＳＣＳＩ対ファイバーチャネルブリッジング機器、ネットワークアタッチドストレージ（ＮＡＳ）機器が含まれる。
【００３３】
制御プレーン２０６は、ＳＡＮ制御経路、ＣＰＵ制御経路、およびＶＬＡＮ制御経路によって、ＳＡＮスイッチ２０２、ＣＰＵ１、ＣＰＵ２、．．．ＣＰＵｎおよびＶＬＡＮスイッチ２０４にそれぞれ接続される。
【００３４】
各ＶＳＦは、ＶＬＡＮの集合、ＶＬＡＮに取り付けられるコンピューティング要素の集合、およびコンピューティング要素の集合に接続されるＳＡＮ上で利用可能な記憶装置のサブセットから成る。ＳＡＮ上で利用可能なストレージのサブセットをＳＡＮゾーンと呼び、これはＳＡＮハードウェアによって他のＳＡＮゾーンの一部であるコンピューティング要素からのアクセスから保護されている。好適には、非可鍛性ポート識別子を与えるＶＬＡＮを使用して、一人の顧客またはエンドユーザが他の顧客またはエンドユーザのＶＳＦリソースにアクセスするのを防止する。
【００３５】
図３は、ＳＡＮゾーンを特色とする典型的な仮想サーバファームのブロック図である。複数のウェブサーバＷＳ１、ＷＳ２などは、第１ＶＬＡＮ（ＶＬＡＮ１）によってロードバランサ（ＬＢ）／ファイアウォール３０２に接続されている。第２ＶＬＡＮ（ＶＬＡＮ２）は、インターネット１０６をロードバランサ（ＬＢ）／ファイアウォール３０２に接続する。各ウェブサーバは、後に説明する機構を使用してＣＰＵ１、ＣＰＵ２などから選択することができる。ウェブサーバはＳＡＮゾーン３０４に接続されており、これは一又は二以上の記憶装置３０６ａ、３０６ｂに接続されている。
【００３６】
ある時点において、例えば図２のＣＰＵ１などのコンピューティンググリッドにおけるコンピューティング要素は、ＶＬＡＮの集合および単一のＶＳＦに関連するＳＡＮゾーンに接続されているだけである。通常、ＶＳＦは異なる組織間で共有されることはない。単一のＳＡＮゾーンに属するＳＡＮ上のストレージのサブセット、およびそれに関連するＶＬＡＮの集合、およびこれらのＶＬＡＮ上のコンピューティング要素が、ＶＳＦを規定する。
【００３７】
ＶＬＡＮのメンバーシップおよびＳＡＮゾーンのメンバーシップを制御することにより、制御プレーンはコンピューティンググリッドを多数のＶＳＦに論理分割する。１つのＶＳＦのメンバーは、他のＶＳＦのコンピューティングまたは記憶リソースにアクセスできない。このようなアクセス制限は、ＶＬＡＮスイッチによって、且つファイバーチャネルスイッチやＳＣＳＩ対ファイバーチャネルブリッジングハードウェアなどのエッジ機器といったＳＡＮハードウェアのポートレベルアクセス制御機構（例えばゾーニング）によって実行させる。コンピューティンググリッドの一部を形成するコンピューティング要素はＶＳＡＮスイッチおよびＳＡＮスイッチの制御ポートまたはインタフェースに物理的に接続されていないので、ＶＬＡＮまたはＳＡＮゾーンのメンバーシップを制御することはできない。従って、コンピューティンググリッドのコンピューティング要素は、これらを含むＶＳＦに配置されていないコンピューティング要素にアクセスできない。
【００３８】
制御プレーンを実行するコンピューティング要素のみが、グリッドにおける機器の制御ポートまたはインタフェースに物理的に接続される。コンピューティンググリッドの機器（コンピュータ、ＳＡＮスイッチ、およびＶＬＡＮスイッチ）は、これらの制御ポートまたはインタフェースによって構成されるだけである。これにより、コンピューティンググリッドを多数のＶＳＦに動的に分割する単純であるが非常に安定した手段が得られる。
【００３９】
ＶＳＦにおける各コンピューティング要素は、他のコンピューティング要素と交換可能である。あるＶＳＦに関連するコンピューティング要素、ＶＬＡＮおよびＳＡＮゾーンの数は、制御プレーンの制御の下で時間が経つと変化する。
【００４０】
一実施例において、コンピューティンググリッドは、予備の多数のコンピューティング要素から成るアイドルプールを含んでいる。アイドルプールからのコンピューティング要素は、ＣＰＵの増加、そのＶＳＦで利用可能なメモリ容量、あるいはＶＳＦにおける特定のコンピューティング要素の故障に対する対処などの理由で、特定のＶＳＦに割り当ててもよい。コンピューティング要素がウェブサーバとして構成されている場合、アイドルプールは、変化するあるいは「バースト状の」ウェブトラフィック負荷および関連するピーク処理負荷に対する大きな「ショックアブソーバ」として機能する。
【００４１】
アイドルプールは多数の異なる組織間で共有されるので、単一の組織がアイドルプール全体の費用を支払わなければならないということがないため、スケールメリットが得られる。異なる組織が必要に応じてその日の異なる時間でアイドルプールからコンピューティング要素を得ることができるので、各ＶＳＦは必要なときに拡大し、且つトラフィックが通常の状態に落ち着いたときに縮小することが可能となる。多数の異なる組織が同時にピークに達し続け、それによってアイドルプールの容量が使い果たされる可能性がある場合、アイドルプールはそれに更に多くのＣＰＵと記憶要素を追加することで増大させることが可能である（拡張性）。アイドルプールの容量は、通常の状態において、特定のＶＳＦが必要なときにアイドルプールから別のコンピューティング要素を得ることができない確率を大きく減らすよう設計されている。
【００４２】
図４Ａ、図４Ｂ、図４Ｃおよび図４Ｄは、アイドルプールからコンピューティング要素を出し入れするときの連続工程を示すブロック図である。最初に図４Ａを参照し、制御プレーンがコンピューティンググリッドの要素を、ＶＳＦ１およびＶＳＦ２というラベルの第１および第２ＶＳＦに論理的に接続させたものとする。アイドルプール４００は複数のＣＰＵ４０２から成り、そのうちの１つはＣＰＵＸとラベル付けされている。図４Ｂにおいて、ＶＳＦ１で別のコンピューティング要素が必要となった。従って、制御プレーンは、経路４０４で示すように、ＣＰＵＸをアイドルプール４００からＶＳＦ１に移動させる。
【００４３】
図４Ｃにおいて、ＶＳＦ１はもはやＣＰＵＸが必要ではないので、制御プレーンはＣＰＵＸをＶＳＦ１からアイドルプール４００に戻す。図４Ｄにおいて、ＶＳＦ２で別のコンピューティング要素が必要となった。従って、制御プレーンはＣＰＵＸをアイドルプール４００からＶＳＦ２に移動させる。従って、時間が経過して、トラフィックの状態が変化すると、単一のコンピューティング要素がアイドルプールに属し（図４）、特定のＶＳＦに割り当てられ（図４Ｂ）、アイドルプールに戻され（図４Ｃ）、そして別のＶＳＦに属することとなる（図４Ｄ）。
【００４４】
これらの各段階において、制御プレーンは、特定のＶＳＦ（またはアイドルプール）に関連するＶＬＡＮおよびＳＡＮゾーンの一部となるそのコンピューティング要素に関連するＬＡＮスイッチおよびＳＡＮスイッチを構成する。一実施例によると、各推移の間において、コンピューティング要素はパワーダウンまたは再起動される。コンピューティング要素の電源が再び投入されると、コンピューティング要素はＳＡＮの記憶ゾーンの異なる部分を見る。特に、コンピューティング要素は、オペレーティングシステム（例えば、Ｌｉｎｕｘ、ＮＴ、Ｓｏｌａｒｉｓなど）の起動可能イメージを含むＳＡＮ上の記憶ゾーンの部分を見る。記憶ゾーンはまた各組織に特有のデータ部分を含む（例えば、ウェブサーバに関連するファイル、データベースパーティションなど）。コンピューティング要素はまた別のＶＳＦのＶＬＡＮ集合の一部である別のＶＬＡＮの一部であるため、転送先のＶＳＦのＶＬＡＮに関連するＣＰＵ、ＳＡＮ記憶装置、ＮＡＳ機器にアクセスできる。
【００４５】
好適な実施例において、記憶ゾーンは、コンピューティング要素によって想定される役割に関連する複数の予め定義された論理詳細設計を含んでいる。初めに、何れのコンピューティング要素も、ウェブサーバ、アプリケーションサーバ、データベースサーバなどの特定の役割やタスクにあてがわれていない。コンピューティング要素の役割は複数の予め定義された保存された詳細設計の何れかから得られ、このような詳細設計のそれぞれはその役割に関連するコンピューティング要素のブートイメージを定義する。詳細設計は、ブートイメージ位置を役割に関連付けさせるファイル、データベーステーブル、または他の保存形式で保存される。
【００４６】
従って、図４Ａ、図４Ｂ、図４Ｃおよび図４ＤにおけるＣＰＵＸの移動は論理的であって、物理的ではなく、制御プレーンの制御の下でＶＬＡＮスイッチおよびＳＡＮゾーンを再構成することによって行なわれる。また、コンピューティンググリッドにおける各コンピューティング要素はまず本来代替可能であり、仮想サーバファームに接続されてブートイメージからソフトウェアをロードした後でのみ特定の処理役割を想定する。何れのコンピューティング要素も、ウェブサーバ、アプリケーションサーバ、データベースサーバなどの特定の役割またはタスクがあてがわれていない。コンピューティング要素の役割は、複数の予め定義された保存された詳細設計の何れかから得られ、これらの詳細設計のそれぞれは役割に関連しており、役割に関連するコンピュータ要素のブートイメージを定義する。
【００４７】
長期の状態情報は特定のコンピューティング要素（ローカルディスクなど）に保存されていないので、異なるＶＳＦ間でノードは簡単に移動でき、まったく異なるＯＳおよびアプリケーションソフトウェアを実行させることができる。これにより、計画された、あるいは計画されていないダウンタイムの場合に、コンピューティング要素はより交換しやすくなる。
【００４８】
特定のコンピューティング要素は、様々なＶＳＦから出し入れするときに、異なる役割を実行することができる。例えば、コンピューティング要素は、あるＶＳＦにおいてウェブサーバとして動作し、且つ別のＶＳＦに移動させると、データベースサーバ、ウェブロードバランサ、ファイアウォールなどになる。また、異なるＶＳＦにおいて、Ｌｉｎｕｘ、ＮＴ、Ｓｏｌａｒｉｓなどの異なるオペレーティングシステムを連続的に起動および実行することもできる。従って、コンピューティンググリッドにおける各コンピューティング要素は代替可能であり、それに割り当てられた固定的役割はない。従って、コンピューティンググリッドの予備容量全体を使用して、何れかのＶＳＦが必要とする何らかのサービスを提供することができる。これにより、特定のサービスを実行する各サーバが有する同一のサービスを提供することのできるバックアップサーバの数は数千になるので、単一のＶＳＦが提供するサービスの利用可能度および信頼性は非常に高くなる。
【００４９】
さらに、コンピューティンググリッドの高予備容量によって、動的負荷バランシング特性および高プロセッサ利用可能度が得られる。この能力は、ＶＬＡＮを介して相互接続され、ＳＡＮを介して記憶装置の構成可能ゾーンに接続され、また全て制御プレーンによってリアルタイムで制御されるディスクレスコンピューティング要素の一義的な組合せで可能となる。各コンピューティング要素はＶＳＦにおける何れかの必要サーバの役割において動作することができ、またＳＡＮにおける何れかのディスクの何れかの論理分割に接続可能である。グリッドで更なるコンピューティングパワーやディスク容量が必要な場合、コンピューティング要素またはディスクストレージはアイドルプールに手動で追加されるが、これは時間が経過して更に多くの組織にＶＳＦサービスが提供されると減少する。ＣＰＵの数、ネットワークおよびディスク処理能力、ＶＳＦで利用できる記憶装置を増大させるのに、手動で介入する必要はない。これらのリソース全ては、要求があるたびにＣＰＵ、アイドルプールで利用できるネットワークおよびディスクリソースから、制御プレーンによって割り当てられる。
【００５０】
特定のＶＳＦは、手動で再構成されない。アイドルプールのコンピューティング要素のみが、コンピューティンググリッドに手動で再構成される。その結果、現在手動で構成されたサーバファームに存在する大きな潜在的障害が除去される。新たなサーバをライブサーバファームに構成する際のヒューマンエラーによってサーバファームが誤動作し、その結果そのウェブサイトのユーザへのサービスが失われてしまう可能性は、殆どなくなる。
【００５１】
制御プレーンはまた、ＳＡＮに取り付けられた記憶装置に保存されたデータをコピーするので、特定の記憶要素の故障によって、システムの何れかの部分へのサービスが失われることはない。ＳＡＮを使用し、且つ冗長的な記憶およびコンピューティング要素を与えることで、コンピューティング装置から長期記憶装置を取り除くことにより、どのコンピューティング要素も何れかの記憶パーティションに取り付けることができるので、高い利用可能性が得られる。
【００５２】
仮想サーバファームの確立、それに対するプロセッサの追加、およびそれからのプロセッサの除去の詳細な例
図５は、実施例によるコンピューティンググリッドおよび制御プレーン機構のブロック図である。図５を参照し、以下においてＶＳＦを作成し、それにノードを追加し、且つそれからノードを除去するのに使用できる詳細な過程を説明する。
【００５３】
図５は、ＶＬＡＮケーパブルスイッチ５０４に接続されたコンピュータＡ〜Ｇを含むコンピューティング要素５０２を示す。ＶＬＡＮスイッチ５０４はインターネット１０６に接続されており、且つＶＬＡＮスイッチはポートＶ１、Ｖ２などを有している。コンピュータＡ〜Ｇは更にＳＡＮスイッチ５０６に接続され、これは複数の記憶装置またはディスクＤ１〜Ｄ５に接続されている。ＳＡＮスイッチ５０６はポートＳ１、Ｓ２などを有している。制御プレーン機構５０８は、制御経路およびデータ経路によって、ＳＡＮスイッチ５０６およびＶＬＡＮスイッチ５０４に通信接続されている。制御プレーンは、制御ポートを介してこれらの装置に制御コマンドを送信することができる。
【００５４】
便宜上、図５のコンピューティング要素の数は少なくなっている。実際には、多数のコンピュータ、例えば数千以上、および同数の記憶装置がコンピューティンググリッドを形成している。このような大きな構造において、多数のＳＡＮスイッチは相互接続されてメッシュを形成し、且つＶＬＡＮスイッチは相互接続されてＶＬＡＮメッシュを形成している。しかしながら、分かりやすくするため、図５では単一のＳＡＮスイッチと単一のＶＬＡＮスイッチを示している。
【００５５】
まず、全てのコンピュータＡ〜Ｇが、制御プレーンがＶＳＦの作成要求を受信するまで、アイドルプールに割り当てられている。ＶＬＡＮスイッチの全てのポートは、（アイドルゾーン用）ＶＬＡＮＩとラベル付けされる特定のＶＬＡＮに割り当てられている。制御プレーンがＶＳＦを構成するように要求され、ＳＡＮ上の記憶装置に接続された１つのロードバランサ／ファイアウォールおよび２つのウェブサーバを含むものとする。制御プレーンへの要求は、管理インタフェースまたは他のコンピューティング要素を介して受信される。
【００５６】
それに応じて、制御プレーンはＣＰＵＡをロードバランサ／ファイアウォールとして指定または割り当て、且つＣＰＵＢおよびＣＰＵＣをウェブサーバとして割り当てる。ＣＰＵＡは論理的にＳＡＮゾーン１に置かれ、専用のロードバランサ／ファイアウォールソフトウェアを含むディスク上の起動可能パーティションに向けられる。「向けられる」という語は便宜上使用され、いかなる手段によって、動作させる必要のある適切なソフトウェアをＣＰＵＡが入手あるいは探し出すのに十分な情報がＣＰＵＡに与えられることを意味する。ＳＡＮゾーン１にＣＰＵＡを配置することにより、ＣＰＵＡは、そのＳＡＮゾーンのＳＡＮによって制御されるディスクからリソースを得ることが可能になる。
【００５７】
ロードバランサは、負荷バランスすべき２つのウェブサーバとしてのＣＰＵＢおよびＣＰＵＣについて知るために、制御プレーンによって構成される。ファイアウォール構成は、インターネット１０６からの認められないアクセスから、ＣＰＵＢおよびＣＰＵＣを保護する。ＣＰＵＢおよびＣＰＵＣは、特定のオペレーティングシステム（例えば、Ｓｏｌａｒｉｓ、Ｌｉｎｕｘ、ＮＴなど）およびウェブサーバアプリケーションソフトウェア（例えばＡｐａｃｈｅ）のための起動用ＯＳイメージを含むＳＡＮ上のディスクパーティションに向けられる。ＶＬＡＮスイッチは、ＶＬＡＮ１にポートｖ１およびｖ２を配置し、且つＶＬＡＮ２にポートｖ３、ｖ４、ｖ５、ｖ６およびｖ７を配置するように構成される。制御プレーンはＳＡＮスイッチ５０６を構成して、ファイバーチャネルスイッチポートｓ１、ｓ２、ｓ３およびｓ８をＳＡＮゾーン１に配置する。
【００５８】
ＣＰＵがどのように特定のディスクドライブに向けられ、且つこれが起動とディスクデータへの共有アクセスにどのような意味があるのかをここに説明する。
【００５９】
図６は、まとめてＶＳＦ１と呼ばれるコンピューティング要素の論理接続の結果を示すブロック図である。ディスクドライブＤＤ１は記憶装置Ｄ１、Ｄ２などから選択される。図６に示す論理構造が得られると、ＣＰＵ Ａ， Ｂ， Ｃには起動コマンドが与えられる。それに応じて、ＣＰＵＡは専用ロードバランサ／ファイアウォールコンピューティング要素となり、且つＣＰＵＢおよびＣＰＵＣはウェブサーバとなる。
【００６０】
今、方針に基づく規則のために、制御プレーンが、ＶＳＦ１において別のウェブサーバが必要であると判断したものとする。これは、例えば、ウェブサーバへの要求の増加によって起こるものであり、且つ顧客の計画によって少なくとも３つのウェブサーバをＶＳＦ１に追加することが可能となる。あるいは、ＶＳＦを所有または運営する組織が別のサーバを欲し、そのＶＳＦに更にサーバを追加することの可能な特権的ウェブページなどの管理機構によって追加したためである。
【００６１】
それに応じて、制御プレーンはＶＳＦ１にＣＰＵＤを追加することを決定する。そのために、制御プレーンは、ポートｖ８およびｖ９をＶＬＡＮ２に追加することで、ＶＬＡＮ２にＣＰＵＤを追加する。また、ＣＰＵＤのＳＡＮポートｓ４はＳＡＮゾーン１に追加される。ＣＰＵＤは、ウェブサーバとして起動および実行されるＳＡＮ記憶装置の起動可能部分に向けられる。ＣＰＵＤはまたウェブページ内容、実行可能サーバスクリプトなどから成るＳＡＮ上の共有データに読み出し専用アクセスする。このように、ＣＰＵＢおよびＣＰＵＣが要求に対応するように、サーバファームに向けられたウェブ要求に対処することができる。制御プレーンは、ＣＰＵＤを負荷バランシングされているサーバセットの一部として含むようロードバランサ（ＣＰＵＡ）を構成する。
【００６２】
次にＣＰＵＤは起動され、ＶＳＦのサイズは３つのウェブサーバおよび１つのロードバランサに増大した。図７は、結果として得られた論理接続性を示している。
【００６３】
制御プレーンが、ＶＳＦ２という名前で、２つのウェブサーバと１つのロードバランサを必要とする別のＶＳＦを作成する要求を受信するものとする。制御プレーンはＣＰＵＥをロードバランサ／ファイアウォールとなるよう割り当て、且つＣＰＵＦおよびＣＰＵＧをウェブサーバとなるよう割り当てる。再び負荷バランシングする２つのコンピューティング要素としてのＣＰＵＦおよびＣＰＵＧについて知るため、ＣＰＵＥを構成する。
【００６４】
この構成を実施するため、制御プレーンは、ＶＬＡＮ１にポートｖ１０およびｖ１１が含まれ（つまり、インターネット１０６に接続）、且つＶＬＡＮ３にポートｖ１２、ｖ１３、ｖ１４、ｖ１５が含まれるようＶＬＡＮスイッチ５０４を構成する。同様に、ＳＡＮゾーン２にＳＡＮポートｓ６、ｓ７、ｓ９が含まれるようＳＡＮスイッチ５０６を構成する。このＳＡＮゾーンは、ＣＰＵＥをロードバランサとして、且つＣＰＵＦおよびＣＰＵＧをＳＡＮゾーンのディスクＤ２に含まれる共有読み取り専用ディスク部分を使用するウェブサーバとして実行させるのに必要なソフトウェアを含む記憶装置を含んでいる。
【００６５】
図８は、結果として得られる論理接続性のブロック図である。２つのＶＳＦ（ＶＳＦ１、ＶＳＦ２）が同一の物理ＶＬＡＮスイッチおよびＳＡＮスイッチを共有するが、２つのＶＳＦは論理的に分割されている。ＣＰＵ
Ｂ、Ｃ、ＤにアクセスするユーザまたはＶＳＦ１を所有または運営する企業は、ＶＳＦ１のＣＰＵおよびストレージにアクセスできるのみである。このようなユーザはＶＳＦ２のＣＰＵまたはストレージにアクセスできない。これは、唯一の共有セグメント（ＶＬＡＮ１）上の別個のＶＬＡＮおよび２つのファイアウォールの組合せ、および２つのＶＳＦが構成される異なるＳＡＮゾーンのために、このようなアクセスができない。
【００６６】
さらに、制御プレーンは、ＶＳＦ１を２つのウェブサーバに戻すことができると判断するものとする。これは、ＶＳＦ１の負荷の一時的上昇が低下し、あるいはその他の管理行為がとられたためである。それに応じて、制御プレーンは、ＣＰＵの電源オフを含む特殊コマンドによってＣＰＵＤをシャットダウンする。ＣＰＵがシャットダウンすると、制御プレーンはポートｖ８およびｖ９をＶＬＡＮ２から取外し、またはＳＡＮゾーン１からＳＡＮポートｓ４と取り外す。ポートｓ４はアイドルＳＡＮゾーンに配置される。アイドルＳＡＮゾーンは、例えば、（アイドル用）ＳＡＮゾーンＩまたはゾーン０に指定される。
【００６７】
その後、制御プレーンは別のノードをＶＳＦ２に追加することを決定する。これは、ＶＳＦ２におけるウェブサーバの負荷が一時的に上昇したり、あるいは他の理由によるためである。従って、制御プレーンは、破線経路８０２で示すように、ＣＰＵＤをＶＳＦ２に配置することを決定する。そのために、ＶＬＡＮ３にポートｖ８およびｖ９が含まれ、且つＳＡＮゾーン２にＳＡＮポートｓ４が含まれるようＶＬＡＮスイッチを構成する。ＣＰＵＤは、ＶＳＦ２のサーバに必要なＯＳおよびウェブサーバソフトウェアの起動用イメージを含むディスク装置２の記憶部分に向けられる。また、ＣＰＵＤは、ＶＳＦ２のほかのウェブサーバが共有するファイルシステムのデータへの読み取り専用アクセスが許可される。ＣＰＵＤは再び電源が投入され、ＶＳＦ２における負荷バランシングされたウェブサーバとして実行し、ＳＡＮゾーン１におけるデータまたはＶＬＡＮ２に取り付けられたＣＰＵへアクセスすることはない。特に、ＣＰＵＤは、ＶＳＦ１の一部であった初期の時点でも、ＶＳＦ１の要素にアクセスすることはできない。
【００６８】
さらに、この構成において、ＣＰＵＥによって実行される安全限界は、ＣＰＵＤを含むまで動的に拡張した。従って、実施例によって、ＶＳＦに追加または除去されるコンピューティング要素を適切に保護するように自動的に調整する動的ファイアウォールが提供される。
【００６９】
説明のため、実施例はポートに基づくＳＡＮゾーニングについて説明した。他の種類のＳＡＮゾーニングも用いることができる。例えば、ＬＵＮレベルＳＡＮゾーニングを使用し、ディスクアレイ内の論理量に基づいてＳＡＮゾーンを作成してもよい。ＬＵＮレベルＳＡＮゾーニングに適した実例製品は、ＥＭＣ ＣｏｒｐｏｒａｔｉｏｎのＶｏｌｕｍｅ Ｌｏｇｉｃｓ Ｐｒｏｄｕｃｔである。
【００７０】
ＳＡＮ上のディスク装置
起動、あるいは他の共有する必要のあるディスクストレージ、起動プログラムおよびデータをどこで見つけるのかに関する情報を有するディスクストレージへのアクセスという目的で、ＣＰＵをＳＡＮ上の特定の装置に向ける方法は幾つかある。
【００７１】
１つの方法では、コンピューティング要素に取り付けられたＳＣＳＩ対ファイバーチャネルブリッジング機器およびローカルディスクのＳＣＳＩインタフェースを設ける。そのＳＣＳＩポートからファイバーチャネルＳＡＮの適切な機器への経路を決定することにより、コンピュータは、ローカルに取り付けられたＳＣＳＩ機器にアクセスするようにファイバーチャネルＳＡＮ上の記憶装置にアクセスできる。従って、起動ソフトウェアなどのソフトウェアは、ローカルに取り付けられたＳＣＳＩ機器をブートオフするように、ＳＡＮ上のディスク装置を単純にブートオフする。
【００７２】
別の方法は、ノードのファイバーチャネルインタフェースおよび関連するデバイスドライバを有し、ファイバーチャネルインタフェースをブート機器として使用可能にするＲＯＭおよびＯＳソフトウェアをブートすることである。
【００７３】
他の方法では、ＳＣＳＩまたはＩＤＥ機器コントローラとなるが、ＳＡＮ上で通信を行なってディスクにアクセスするインタフェースカード（例えばＰＣＩバスまたはＳバス）を有する。Ｓｏｌａｒｉｓなどのオペレーティングシステムは、この方法で使用可能なディスクレスブート機能を完全提供する。
【００７４】
通常は、あるノードに関連するＳＡＮディスク機器は２種類ある。一方の種類は、他のコンピューティング要素と論理的に共有せず、起動可能ＯＳイメージ、ローカル構成ファイルなどを含む通常はノードごとのルートパーティションであるものを構成する。これは、Ｕｎｉｘ（登録商標）システム上のルートファイルシステムと同等である。
【００７５】
２番目の種類のディスクは、他のノードとの共有ストレージである。共有の種類は、ＣＰＵ上で実行するＯＳソフトウェアおよび共有ストレージにアクセスするノードのニーズによって異なる。ＯＳが多数のノード間で共有ディスクパーティションの読み取り／書き込みアクセスを可能にするクラスタファイルシステムを提供する場合、共有ディスクはこのようなクラスタファイルシステムとして実装される。同様に、システムは、共有ディスクへの同時読み取り／書き込みアクセスを行なうために、クラスタ内での多数のノードの実行を可能にするオラクルパラレルサーバなどのデータベースソフトウェアを使用してもよい。このような場合、共有ディスクは、基本ＯＳおよびアプリケーションソフトウェア内にすでに設計されている。
【００７６】
このような共有アクセスが不可能であるオペレーティングシステムの場合、ＯＳおよび関連アプリケーションが他のノードと共有するディスク機器を管理できないため、共有ディスクを読み出し専用機器として実装することができる。多数のウェブアプリケーションの場合、ウェブ関連ファイルへ読み出し専用アクセスすればよい。例えば、Ｕｎｉｘ（登録商標）システムの場合、特定のファイルシステムを読み出し専用として実装してもよい。
【００７７】
マルチスイッチコンピューティンググリッド
図５に関連して上記に説明した構成は、複数のＶＬＡＮスイッチを相互接続して大きな交換ＶＬＡＮ構造を形成することにより、且つ多数のＳＡＮスイッチを相互接続して大きな交換ＳＡＮメッシュを構成することにより、多数のコンピューティングおよび記憶ノードに拡張することができる。この場合、コンピューティンググリッドは、ＳＡＮ／ＶＬＡＮ交換メッシュがＣＰＵおよび記憶装置の非常に多数のポートを含むことを除いて、図５に一般に示すアーキテクチャを有している。制御プレーンを実行する多数のコンピューティング要素は、以下に説明するように、ＶＬＡＮ／ＳＡＮスイッチの制御ポートに物理的に接続可能である。多数のＶＬＡＮスイッチを相互接続して複雑な多構内データネットワークを生成することは、この分野において知られている。例えば、Ｇ． Ｈａｖｉｌａｎｄによる”Ｄｅｓｉｇｎｉｎｇ Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ Ｃａｍｐｕｓ Ｉｎｔｒａｎｅｔｓ ｗｉｔｈ Ｍｕｌｔｉｌａｙｅｒ Ｓｗｉｔｃｈｉｎｇ（多層切り替えを有する高性能構内イントラネットの設計）” Ｃｉｓｃｏ Ｓｙｓｔｅｍｓ， Ｉｎｃ．，およびＢｒｏｃａｄｅから入手可能な情報を参照すること。
【００７８】
ＳＡＮアーキテクチャ
説明では、ＳＡＮがファイバーチャネルスイッチおよびディスク機器、および潜在的にＳＣＳＩ対ファイバーチャネルブリッジなどのファイバーチャネルエッジ機器とから構成されることを前提としている。しかし、ＳＡＮはギガビットイーサネット（登録商標）スイッチなどのほかの技術、または他の物理層プロトコルを使用するスイッチを使用して構成されてもよい。特に、ＩＰ上でＳＣＳＩプロトコルを実行させることにより、ＩＰネットワーク上でＳＡＮを構築しようという試みが行なわれている。上述した方法およびアーキテクチャは、これらの他のＳＡＮ構築方法に適応できる。ＶＬＡＮ可能層２環境でＩＰ上でＳＣＳＩなどのプロトコルを実行させることによってＳＡＮを構築する場合、ＳＡＮゾーンはこれらを異なるＶＬＡＮにマッピングすることによって生成される。
【００７９】
さらに、高速イーサネット（登録商標）またはギガビットイーサネット（登録商標）などのＬＡＮ技術上で動作するネットワークアタッチドストレージ（ＮＡＳ）を使用してもよい。この選択肢により、保全性とコンピューティンググリッドの論理パーティショニングを強化するために、ＳＡＮゾーンの代わりに異なるＶＬＡＮを使用する。このようなＮＡＳ機器は通常、ＳｕｎのＮＳＦプロトコルやＭｉｃｒｏｓｏｆｔのＳＭＢなどのネットワークファイルシステムをサポートして、多数のノードが同一のストレージを共有できるようにする。
【００８０】
制御プレーンの実施
ここに述べるように、制御プレーンは、ＳＡＮおよびＶＬＡＮスイッチの制御およびデータポートに接続される一又は二以上の処理リソースとして実施してもよい。様々な制御プレーンの実施を行なうことができ、且つ本発明は特定の制御プレーンの実施に制限されるものではない。制御プレーン実施の様々な面を、以下の項１）制御プレーンアーキテクチャ、２）マスターセグメントマネジャー選択、３）管理機能、４）方針および保全に関する考察で詳細に説明する。
【００８１】
１．制御プレーンアーキテクチャ
一実施例によれば、制御プレーンは制御プロセス階層として実施される。制御プロセス階層は一般に、一又は二以上のスレーブセグメントマネジャー機構に通信接続されてこれらを制御する一又は二以上のマスターセグメントマネジャー機構を含んでいる。一又は二以上のスレーブセグメントマネジャー機構は、一又は二以上のファームマネジャーを制御する。一又は二以上のファームマネジャーは、一又は二以上のＶＳＦを管理する。マスターおよびスレーブセグメントマネジャー機構は、ハードウェア回路、コンピュータソフトウェア、または何れかの組合せにおいて実施されてもよい。
【００８２】
図９は、一実施例による制御プレーン９０２およびコンピューティンググリッド９０４との間の論理関係を示すブロック図９００である。制御プレーン９０２は、コンピューティンググリッド９０４におけるネットワーキングおよび記憶要素の特殊制御ポートまたはインタフェースを介して、コンピューティンググリッド９０４に含まれるコンピューティング、ネットワーキングおよび記憶要素を制御および管理する。コンピューティンググリッド９０４は、上述した実施例により生成された多数のＶＳＦ９０６または論理リソースグループを含む。
【００８３】
一実施例によると、制御プレーン９０２はマスターセグメントマネジャー９０８、一又は二以上のスレーブセグメントマネジャー９１０、および一又は二以上のファームマネジャー９１２を含んでいる。マスターセグメントマネジャー９０８、スレーブセグメントマネジャー９１０およびファームマネジャー９１２は、特定のコンピューティングプラットフォーム上の同一位置に配置されたり、あるいは多数のコンピューティングプラットフォーム上で分散されてもよい。便宜上、単一のマスターセグメントマネジャー９０８のみを図示および説明するが、多数のマスターセグメントマネジャー９０８を使用してもよい。
【００８４】
マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０に通信接続され、これを制御および管理している。各スレーブセグメントマネジャー９１０は、一又は二以上のファームマネジャー９１２に通信接続され、これを管理する。一実施例によれば、各ファームマネジャー９１２は、通信接続された対応するスレーブセグメントマネジャー９１０として同一のコンピューティングプラットフォーム上の同一位置に配置される。ファームマネジャー９１２は、コンピューティンググリッド９０４上でＶＳＦ９０６を確立、構成および維持する。一実施例によれば、各ファームマネジャー９１２は管理する単一のＶＳＦ９０６が割り当てられるが、ファームマネジャー９１２も多数のＶＳＦ９０６が割り当てられる。ファームマネジャー９１２はそれぞれ直接ではなく、各スレーブセグメントマネジャー９１０を介してのみ通信を行う。スレーブセグメントマネジャー９１０は、その割り当てられたファームマネジャー９１２の状態を監視する。スレーブセグメントマネジャー９１０は、機能停止や異常終了したそれぞれ割り当てられたファームマネジャー９１２を再開させる。
【００８５】
マスターセグメントマネジャー９０８はＶＳＦ９０６のローディングを監視して、各ＶＳＦ９０６に割り当てるリソースの量を決定する。マスターセグメントマネジャー９０８は、必要時応じてファームマネジャー９１２を介してＶＳＦのリソースを割り当ておよび割り当て解除するようにスレーブセグメントマネジャー９１０に指示する。特定のアプリケーションの必要条件に応じて様々な負荷バランシングアルゴリズムを実施してもよく、且つ本発明は特定の負荷バランシング方法に限定されるものではない。
【００８６】
マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０およびファームマネジャー９１２が実行されているコンピューティングプラットフォームのローディング情報を監視して、コンピューティンググリッド９０４は適切にサービスされているか否かを判断する。マスターセグメントマネジャー９０８はスレーブセグメントマネジャー９１０の割り当ておよび割り当て解除を行い、必要に応じてコンピューティンググリッド９０４を適切に管理するためにファームマネジャー９１２の割り当ておよび割り当て解除を行うようスレーブセグメントマネジャー９１０を指示する。一実施例によれば、マスターセグメントマネジャー９０８も、必要に応じてファームマネジャー９１２およびスレーブセグメントマネジャー９１０の間で負荷をバランスさせるために、ファームマネジャー９１２へのＶＳＦの割り当て、およびスレーブセグメントマネジャー９１０へのファームマネジャー９１２の割り当てを管理する。一実施例によれば、スレーブセグメントマネジャー９１０はマスターセグメントマネジャー９０８と活発に通信し、コンピューティンググリッド９０４への変更要求、および別のスレーブセグメントマネジャー９１０および／またはファームマネジャー９１２の要求を行う。一又は二以上のスレーブセグメントマネジャー９１０および一又は二以上のファームマネジャー９１２を実行している処理プラットフォームが機能しなくなった場合、マスターセグメントマネジャー９０８は、停止したコンピューティングプラットフォームのファームマネジャー９１２から他のファームマネジャー９１２へＶＳＦ９０６を再割り当てする。この場合、マスターセグメントマネジャー９０８も、ＶＳＦ９０６の再割り当てを行うために別のファームマネジャー９１２を開始するようにスレーブセグメントマネジャー９１０に指示することができる。ＶＳＦ９０６に割り当てられた多数のコンピューティングリソース、多数のアクティブなファームマネジャー９１２、およびスレーブセグメントマネジャー９１０をアクティブに管理することにより、全体的な電力消費量を制御できる。例えば、電力を節約するために、マスターセグメントマネジャー９０８は、アクティブなスレーブセグメントマネジャー９１０またはファームマネジャー９１２を有していないコンピューティングプラットフォームをシャットダウンしてもよい。節電は、大きなコンピューティンググリッド９０４および制御プレーン９０２で重要となる。
【００８７】
一実施例によれば、マスターセグメントマネジャー９０８は、レジストリを使用することでスレーブセグメントマネジャー９１０を管理する。レジストリは、その状態、割り当てられたファームマネジャー９１２、および割り当てられたＶＳＦ９０６などの現在のスレーブセグメントマネジャー９１０についての情報を含んでいる。スレーブセグメントマネジャー９１０が割り当ておよび割り当て解除されると、レジストリは更新されて、スレーブセグメントマネジャー９１０の変更が反映される。例えば、新しいスレーブセグメントマネジャー９１０がマスターセグメントマネジャー９０８および割り当てられた一又は二以上のＶＳＦ９０６によって例示化されると、レジストリが更新されて、新しいスレーブセグメントマネジャー９１０およびその割り当てられたファームマネジャー９１２とＶＳＦ９０６の生成が反映される。次に、マスターセグメントマネジャー９０８はレジストリを定期的に調べて、スレーブセグメントマネジャー９１０へどのようにＶＳＦ９０６を割り当てるのがよいのかを判断することができる。
【００８８】
一実施例によれば、レジストリは、マスターセグメントマネジャー９１０がアクセスできるマスターセグメントマネジャー９０８についての情報を含んでいる。例えば、レジストリは一又は二以上のアクティブなマスターセグメントマネジャー９０８を識別するデータを含んでいてもよいので、新しいスレーブセグメントマネジャー９１０が生成されると、新しいスレーブセグメントマネジャー９１０はレジストリをチェックして、一又は二以上のマスターセグメントマネジャー９０８の識別について確認することができる。
【００８９】
レジストリは様々な形で実施されてもよく、且つ本発明は特定の実施方法に限定されない。例えば、レジストリは制御プレーン９０２内のデータベース９１４に保存されるデータファイルであってもよい。レジストリは、制御プレーン９０２の外に保存されなくてもよい。例えば、レジストリはコンピューティンググリッド９０４の記憶装置に保存されてもよい。この例では、記憶装置は制御プレーン９０２専用となり、ＶＳＦ９０６に割り当てられない。
【００９０】
２．マスターセグメントマネジャー選出
一般に、マスターセグメントマネジャーは、制御プレーンが確立されたとき、あるいは既存のマスターセグメントマネジャーが故障した後に、選出される。一般に特定の制御プレーン対して単一のマスターセグメントマネジャーが存在するが、２つ以上のマスターセグメントマネジャーを選出して、制御プレーンのスレーブセグメントマネジャーを同時管理するほうが有利な場合もある。
【００９１】
一実施例によれば、制御プレーンにおけるスレーブセグメントマネジャーは、その制御プレーンのマスターセグメントマネジャーを選出する。マスターセグメントマネジャーがなく、単一のスレーブセグメントマネジャーのみが存在するという単純なケースでは、スレーブセグメントマネジャーがマスターセグメントマネジャーとなり、必要に応じて別のスレーブセグメントマネジャーを割り当てる。２つ以上のスレーブセグメントマネジャーが存在する場合、２つ以上のスレーブプロセスが例えば定足数などの採決によって新しいマスターセグメントマネジャーを選出する。
【００９２】
制御プレーンのスレーブセグメントマネジャーは必ずしも永続的ではないので、特定のスレーブセグメントマネジャーを選択して、採決に参加させてもよい。例えば、一実施例によれば、レジスタは、各スレーブセグメントマネジャーによって周期的に更新される各スレーブセグメントマネジャーのタイムスタンプを含んでいる。指定された選択基準に従って決定された、最も最近に更新されたタイムスタンプを有するスレーブセグメントマネジャーはいまだに実行されていると考えられ、新しいマスターセグメントマネジャーを選出するために選択される。例えば、指定数の最も新しいスレーブセグメントマネジャーを採決に選択してもよい。
【００９３】
一実施例によれば、選出シーケンス番号を全てのアクティブなスレーブセグメントマネジャーに割り当て、アクティブなスレーブセグメントマネジャーの選出シーケンス番号に基づいて新しいマスターセグメントマネジャーを決定する。例えば、最も低いあるいは最も高い選出シーケンス番号を使用して、特定のスレーブセグメントマネジャーを次の（または最初の）マスターセグメントマネジャーに選択してもよい。
【００９４】
マスターセグメントマネジャーが確立されると、マスターセグメントマネジャーとしての同一制御プレーンのスレーブセグメントマネジャーは、現在のマスターセグメントマネジャーにコンタクト（ピング）することによりマスターセグメントマネジャーの検診を周期的に行って、マスターセグメントマネジャーがまだアクティブであるか否かを判断する。現在のマスターセグメントマネジャーがアクティブでないと判断した場合、新しいマスターセグメントマネジャーを選出する。
【００９５】
図１０は、実施例によるマスターセグメントマネジャー選出の状態図１０００を示している。スレーブセグメントマネジャーのメインループである状態１００２において、スレーブセグメントマネジャーは、ピングタイマーの終了を待つ。ピングタイマーが終了すると、状態１００４となる。状態１００４において、スレーブセグメントマネジャーは、マスターセグメントマネジャーをピングする。さらに、状態１００４において、スレーブセグメントマネジャーのタイムスタンプ（ＴＳ）が更新される。マスターセグメントマネジャーがピングに応答した場合、マスターセグメントマネジャーはまだアクティブであり、状態１００２に戻る。特定時間後もマスターセグメントマネジャーから応答がなければ、状態１００６になる。
【００９６】
状態１００６において、アクティブなスレーブセグメントマネジャーのリストを得て、状態１００８になる。状態１００８において、他のスレーブセグメントマネジャーもマスターセグメントマネジャーからの応答を受信していないか確認する。この確認を行うためにスレーブセグメントマネジャーへメッセージを送る代わりに、この情報をデータベースから得る。マスターセグメントマネジャーがアクティブでないことにスレーブセグメントマネジャーが同意しない、すなわち一又は二以上のスレーブセグメントマネジャーがマスターセグメントマネジャーから適時の応答を受信した場合、現在のマスターセグメントマネジャーがまだアクティブであると推定され、状態１００２に戻る。特定の数のスレーブセグメントマネジャーが現在のマスターセグメントマネジャーから適時の応答を受信しなかった場合、現在のマスターセグメントマネジャーが「死んでいる」、すなわちアクティブでないと推定され、状態１０１０に進む。
【００９７】
状態１０１０において、プロセスを開始したスレーブセグメントマネジャーは選出テーブルから現在の選出番号、且つデータベースから次の選出番号を検索する。次に、スレーブセグメントマネジャーは選出テーブルを更新して、次の選出番号と一義的なアドレスを指定するエントリをマスター選出テーブルに書き込む。次に、スレーブセグメントマネジャーが現在の選出番号の最も低いシーケンス番号を読み出す状態１０１２に進む。状態１０１４において、特定のスレーブセグメントマネジャーが最も低いシーケンス番号を有しているか否か確認する。有していない場合、状態１００２に戻る。有している場合、特定のスレーブセグメントマネジャーがマスターセグメントマネジャーになる状態１０１６に進む。次に、状態１０１８に進み、選出番号をインクリメントする。
【００９８】
上述したように、スレーブセグメントマネジャーは一般に、その割り当てられたＶＳＦのサービスと、マスターセグメントマネジャーからの命令に応じての新たなＶＳＦの割り当てを行う。スレーブセグメントマネジャーはまたマスターセグメントマネジャーのチェックと、必要に応じて新たなマスターセグメントマネジャーの選出も行う。
【００９９】
図１１は、実施例によるスレーブセグメントマネジャーの様々な状態を示す状態図１１００である。処理は、スレーブセグメントマネジャー開始状態１１０２において始まる。状態１１０２から、現在のマスターセグメントマネジャーの状態を確認する要求に応じて、状態１１０４に進む。状態１１０４では、スレーブセグメントマネジャーは現在のマスターセグメントマネジャーにピングを送って、現在のマスターセグメントマネジャーがまだアクティブであるか否かを判断する。適時の応答が現在のマスターセグメントマネジャーからあれば、状態１１０６に進む。状態１１０６では、他のスレーブセグメントマネジャーにメッセージが同報通信され、マスターセグメントマネジャーがピングに応答したことを知らせる。状態１１０６から、開始状態１１０２に戻る。
【０１００】
状態１１０４で、適時のマスター応答がなければ、状態１１０８に進む。状態１１０８では、他のスレーブセグメントマネジャーにメッセージが同報通信され、マスターセグメントマネジャーがピングに応答しなかったことを知らせる。次に、開始状態１１０２に戻る。ちなみに、十分な数のスレーブセグメントマネジャーが現在のマスターセグメントマネジャーから応答を受信しなかった場合、新しいマスターセグメントマネジャーを上記のように選出する。
【０１０１】
状態１１０２から、マスターセグメントマネジャーからＶＳＦを再開する要求を受信したら、状態１１１０に進む。状態１１１０では、ＶＳＦが再開されて、開始状態１１０２に戻る。
【０１０２】
上述したように、マスターセグメントマネジャーは一般に、マスターセグメントマネジャーが制御するコンピューティンググリッドのＶＳＦが一又は二以上のスレーブセグメントマネジャーによって適切にサービスされるようにする。このために、マスターセグメントマネジャーは、マスターセグメントマネジャーとしての同一制御プレーンの全てのスレーブセグメントマネジャーの定期的検診を行う。一実施例によれば、マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０から状態情報を周期的に要求する。情報は例えば、どのＶＳＦ９０６がスレーブセグメントマネジャー９１０によってサービスされているかを含んでいる。特定のスレーブセグメントマネジャー９１０が特定時間内に応答しなければ、マスターセグメントマネジャー９０８は特定のスレーブセグメントマネジャー９１０の再開を試みる。特定のスレーブセグメントマネジャー９１０を再開できない場合、マスターセグメントマネジャー９０８は、異常のあるスレーブセグメントマネジャー９１０から別のスレーブセグメントマネジャー９１０にファームマネジャー９１２を再割り当てする。次に、マスターセグメントマネジャー９０８は一又は二以上の別のスレーブセグメントマネジャー９１０を例示化して、プロセスローディングの再バランシングを行うことができる。一実施例によれば、マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０を実行しているコンピューティングプラットフォームの状態を監視する。コンピューティングプラットフォームに異常があれば、マスターセグメントマネジャー９０８は、異常のあるコンピューティングプラットフォーム上のファームマネジャー９１２に割り当てられたＶＳＦを、別のコンピューティングプラットフォームに割り当てる。
【０１０３】
図１２は、マスターセグメントマネジャーの状態図１２００である。処理は、マスターセグメントマネジャー開始状態１２０２において開始する。状態１２０２から、マスターセグメントマネジャー９０８が制御面９０２のスレーブセグメントマネジャー９１０の周期的検診を行うかあるいはこれを要求したときに、状態１２０４に進む。状態１２０４から、全てのスレーブセグメントマネジャー９１０が予測したように応答した場合、状態１２０２に戻る。これは、全てのスレーブセグメントマネジャー９１０が、全てのスレーブセグメントマネジャー９１０が普通に動作していることを示す特定の情報をマスターセグメントマネジャー９０８に提供した場合に、生じる。一又は二以上のスレーブセグメントマネジャー９１０が応答しない、あるいは一又は二以上のスレーブセグメントマネジャー９１０に異常があったことを示す応答をした場合、状態１２０６に進む。
【０１０４】
状態１２０６において、マスターセグメントマネジャー９０８は異常のあったスレーブセグメントマネジャー９１０の再開を試みる。これはいくつかの方法で行なうことができる。例えば、マスターセグメントマネジャー９０８は、応答のないあるいは異常のあったスレーブセグメントマネジャー９１０に再開メッセージを送ることができる。状態１２０６から、全てのスレーブセグメントマネジャー９１０が予想したように応答、すなわち問題なく再開された場合、状態１２０２戻る。例えば、異常のあったスレーブセグメントマネジャー９１０が問題なく再開すると、スレーブセグメントマネジャー９１０はマスターセグメントマネジャー９０８に再開確認メッセージを送る。状態１２０６から、一又は二以上のスレーブセグメントマネジャーが再開できなかった場合、状態１２０８に進む。これは、マスターセグメントマネジャー９０８が特定のスレーブセグメントマネジャー９１０から再開確認メッセージを受信しない場合に生じる。
【０１０５】
状態１２０８において、マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０を実行するマシンの現在のローディングを決定する。スレーブセグメントマネジャー９０８のローディング情報を得るために、マスターセグメントマネジャー９０８は、スレーブセグメントマネジャー９１０を直接ポーリングするか、あるいは例えばデータベース９１４など別の場所からローディング情報を得る。本発明は、マスターセグメントマネジャー９０８がスレーブセグメントマネジャー９１０のローディング情報を得るための特定の方法に限定されない。
【０１０６】
次に状態１２１０に進み、異常のあったスレーブセグメントマネジャー９１０に割り当てられたＶＳＦ９０６を他のスレーブセグメントマネジャー９１０に再割り当てする。ＶＳＦ９０６が割り当てられているスレーブセグメントマネジャー９１０は、いつ再割り当てが完了したのかをマスターセグメントマネジャー９０８に知らせる。例えば、スレーブセグメントマネジャー９１０はマスターセグメントマネジャー９０８に再割り当て確認メッセージを送って、ＶＳＦ９０６の再割り当てが問題なく終了したことを知らせることができる。異常のあったスレーブセグメントマネジャー９１０に関連する全てのＶＳＦ９０６の再割り当てが確認されるまで、状態１２１０に留まる。確認されれば、状態１２０２に戻る。
【０１０７】
異常のあったスレーブセグメントマネジャー９１０に関連するＶＳＦ９０６を他のアクティブスレーブセグメントマネジャー９１０へ再割り当てする代わりに、マスターセグメントマネジャー９０８は別のスレーブセグメントマネジャー９１０を割り当て、新しいスレーブセグメントマネジャー９１０にこれらのＶＳＦ９０６を割り当ててもよい。既存のスレーブセグメントマネジャー９１０または新しいスレーブセグメントマネジャー９１０へＶＳＦ９０６を再割り当てするかどうかの選択は、少なくとも部分的に、新しいスレーブセグメントマネジャー９１０の割り当てに関連する待ち時間、および既存のスレーブセグメントマネジャー９１０へのＶＳＦ９０６の再割り当てに関連する待ち時間に依る。何れの方法も特定のアプリケーションの必要条件に応じて使用することができ、且つ本発明は何れの方法にも限定されることはない。
【０１０８】
３．管理機能
一実施例によれば、制御プレーン９０２は、グローバルグリッドマネジャーに通信接続されている。制御面９０２は、グローバルグリッドマネジャーに、課金、障害、容量、ローディング、および他のコンピューティンググリッド情報を提供する。図１３は、実施例によるグローバルグリッドマネジャーの使用を説明するブロック図である。
【０１０９】
図１３において、コンピューティンググリッド１３００は、グリッドセグメント１３０２と呼ばれる論理部分にパーティションされる。各グリッドセグメント１３０２は、データプレーン９０４を制御および管理する制御プレーン９０２を含んでいる。この例において、各データプレーン９０４は図９のコンピューティンググリッド９０４と同一であるが、多数の制御プレーン９０２およびデータプレーン９０４、すなわちグリッドセグメント１３０２を管理するグローバルグリッドマネジャーの使用を説明するため、「データプレーン」と呼ばれる。
【０１１０】
各グリッドセグメントは、グローバルグリッドマネジャー１３０４に通信接続される。グローバルグリッドマネジャー１３０４、制御プレーン９０２、およびコンピューティンググリッド９０４は、単一のコンピューティングプラットフォームに同時配置されたり、あるいは多数のコンピューティングプラットフォーム上で分散させてもよく、本発明は特定の実施方法に限定されることはない。
【０１１１】
グローバルグリッドマネジャー１３０４は、複数のグリッドセグメント１３０２の集中管理およびサービスを行う。グローバルグリッドマネジャー１３０４は、様々な管理タスクで使用される制御プレーン９０２からの課金、ローディング、および他の情報を集めることができる。例えば、課金情報を使用して、コンピューティンググリッド９０４が提供するサービスの課金を行う。
【０１１２】
４．方針および保全についての考察
上述したように、制御プレーンにおけるスレーブセグメントマネジャーは、コンピューティンググリッドにおける関連するＶＳＦと通信可能でなければならない。同様に、コンピューティンググリッドにおけるＶＳＦは、その関連するスレーブセグメントマネジャーと通信可能でなければならない。更に、コンピューティンググリッドにおけるＶＳＦは、あるＶＳＦが何らかの方法で他のＶＳＦの構造を変えてしまうのを防ぐために、互いに通信可能であってはならない。これらの方針を実施する様々な方法について説明する。
【０１１３】
図１４は、実施例によるコンピューティンググリッドへ制御プレーンを接続するアーキテクチャのブロック図１４００である。参照番号１４０２でまとめて識別されるＶＬＡＮスイッチ（ＶＬＡＮ ＳＷ１〜ＶＬＡＮ ＳＷｎ）および参照番号１４０４でまとめて識別されるＳＡＮスイッチ（ＳＡＮ ＳＷ１〜ＳＡＮ ＳＷｎ）の制御（「ＣＴＬ」）ポートは、イーサネット（登録商標）サブネット１４０６に接続される。イーサネット（登録商標）サブネット１４０６は、参照番号１４０８でまとめて識別される複数のコンピューティング要素（ＣＰＵ１、ＣＰＵ２〜ＣＰＵｎ）に接続される。従って、制御プレーン１４０８のコンピューティング要素のみが、ＶＬＡＮスイッチ１４０２およびＳＡＮスイッチ１４０４の制御ポート（ＣＴＬ）に通信接続される。この構造は、ＶＳＦ（図示せず）におけるコンピューティング要素が、それ自身または他のＶＳＦに関連するＶＬＡＮおよびＳＡＮゾーンのメンバーシップを変更してしまうのを防ぐ。この方法も、制御ポートがシリアルまたはパラレルポートである場合に適用可能である。この場合、ポートは制御プレーン１４０８のコンピューティング要素に接続される。
【０１１４】
図１５は、実施例による制御プレーンコンピューティング要素（ＣＰ ＣＰＵ１、ＣＰ ＣＰＵ２〜ＣＰ ＣＰＵｎ）１５０２をデータポートに接続する構造を示すブロック図１５００である。この構成において、制御プレーンコンピューティング要素５０２は、制御プレーンコンピューティング要素１５０２のために動作する制御プレーンエージェント１５０４に周期的にパケットを送る。制御プレーンエージェント１５０４は、リアルタイムデータのためにコンピューティング要素５０２を周期的にポーリングして、データを制御プレーンコンピューティング要素１５０２に送る。制御プレーン１５０２における各セグメントマネジャーは、制御プレーン（ＣＰ）ＬＡＮ１５０６に通信接続されている。ＣＰ ＬＡＮ１５０６は、ＣＰファイアウォール１５０８を介して、ＶＬＡＮスイッチ５０４の特殊ポートＶ１７に通信接続されている。この構造により、制御プレーンコンピューティング要素１５０２に拡張可能な確実な手段が与えられ、コンピューティング要素５０２からリアルタイム情報が集められる。
【０１１５】
図１６は、実施例によるコンピューティンググリッドへ制御プレーンを接続するアーキテクチャのブロック図１６００である。制御プレーン１６０２は、制御プレーンコンピューティング要素ＣＰ ＣＰＵ１、ＣＰ ＣＰＵ２〜ＣＰ ＣＰＵｎを含んでいる。制御プレーン１６０２における各制御プレーンコンピューティング要素ＣＰ ＣＰＵ１、ＣＰ ＣＰＵ２〜ＣＰ ＣＰＵｎは、全体でＳＡＮメッシュ１６０４を形成する複数のＳＡＮスイッチのポートＳ１、Ｓ２〜Ｓｎに通信接続される。
【０１１６】
ＳＡＮメッシュ１６０４は、制御プレーン１６０２に対してプライベートであるデータを含む記憶装置１６０６に通信接続されるＳＡＮポートＳｏ、Ｓｐを含んでいる。記憶装置１６０６は、便宜上、ディスクとして図１６に示されている。記憶装置１６０６は、いずれのタイプの記憶媒体で実施されてもよく、本発明は記憶装置１６０６の特定の種類の記憶媒体に限定されることはない。記憶装置１６０６は、制御プレーンプライベート記憶ゾーン１６０８に論理的に配置される。制御プレーンプライベート記憶ゾーン１６０８は、制御プレーン１６０２を実施するログファイル、統計データ、現在の制御プレーン構成情報を維持する。ＳＡＮポートＳｏ、Ｓｐは制御プレーンプライベート記憶ゾーンの唯一の部分であり、他のＳＡＮゾーンには配置されることはないため、制御プレーン１６０２におけるコンピューティング要素のみが記憶装置１６０６にアクセスできる。また、Ｓ１、Ｓ２〜Ｓｎ、ＳｏおよびＳｐは、制御プレーン１６０２におけるコンピューティング要素に通信接続されるのみの制御プレーンＳＡＮゾーンに存在する。これらのポートは、ＶＳＦにおけるコンピューティング要素（図示せず）がアクセスすることはできない。
【０１１７】
一実施例によれば、特定のコンピューティング要素ＣＰ ＣＰＵ１、ＣＰ ＣＰＵ２〜ＣＰ ＣＰＵｎが記憶装置またはその一部にアクセスする必要がある場合、それは特定のＶＳＦの一部であり、特定のコンピューティング要素は特定のＶＳＦのＳＡＮゾーン内に置かれる。例えば、コンピューティング要素ＣＰ ＣＰＵ２がＶＳＦｉディスク１６１０にアクセスする必要があるものとする。この場合、制御プレーンＣＰ ＣＰＵ２に関連するポートｓ２は、ポートＳｉを含むＶＳＦｉのＳＡＮゾーンに配置される。一度コンピューティング要素ＣＰ ＣＰＵ２がポートＳｉのＶＳＦｉディスク１６１０へアクセスすると、コンピューティング要素ＣＰ ＣＰＵ２はＶＳＦｉのＳＡＮゾーンから取り除かれる。
【０１１８】
同様に、コンピューティング要素ＣＰ ＣＰＵ１がＶＳＦｊディスク１６１２にアクセスする必要があるものとする。この場合、コンピューティング要素ＣＰ ＣＰＵ１はＶＳＦｊに関連するＳＡＮゾーン内に配置される。その結果、ポートＳ１は、ポートＳｊを含むゾーンを有するＶＳＦｊに関連するＳＡＮゾーン内に配置される。一度コンピューティング要素ＣＰ ＣＰＵ１がポートＳｊに接続されたＶＳＦｊディスク１６１２へアクセスすると、コンピューティング要素ＣＰ ＣＰＵ１はＶＳＦｊに関連するＳＡＮゾーンから除去される。この方法により、正確なＳＡＮゾーン制御を使用してリソースへのアクセスを正確に制御することによる、制御プレーンコンピューティング要素および制御プレーン記憶ゾーン１６０８の完全性が得られる。
【０１１９】
上述したように、単一の制御プレーンコンピューティング要素は複数のＶＳＦの管理を行うことができる。従って、単一の制御プレーンコンピューティング要素は、各制御プレーンに大して確立された方針規則に従ってＶＳＦ間のファイアウォールを実行しながら、多数のＶＳＦにおける自身を同時に明確にできなければならない。方針規則は、各制御プレーンのデータベース９１４（図９）に保存、あるいは中央セグメントマネジャー１３０２（図１３）によって実施してもよい。
【０１２０】
一実施例によれば、（物理的スイッチ）ポートに基づくＶＬＡＮタグはスプーフできないため、ＶＬＡＮタギングとＩＰアドレスとの間を強固に結合させて、ＶＳＦによるスプーフ攻撃を防いでいる。あるＶＬＡＮインタフェースで送られてくるＩＰパケットは、パケットが到着する論理インタフェースと同じＶＬＡＮタグおよびＩＰアドレスを有していなければならない。これにより、ＶＳＦにおける不正サーバが別のＶＳＦにおけるソースＩＰアドレスをスプーフし、別のＶＳＦの論理構造を潜在的に変更し、あるいはコンピューティンググリッド機能の保全を破壊するＩＰスプーフィング攻撃を防止する。このＶＬＡＮタギングを防止するほう方法では、高安全（クラスＡ）データセンターを使用して防止できるコンピューティンググリッドへの物理的アクセスが必要である。
【０１２１】
様々なネットワークフレームタギング形式を使用してデータパケットのタグを行ってもよく、且つ本発明は特定のタギング形式に限定されることはない。一実施例によれば、他の形式も適切であるが、ＩＥＥ８０２．１ｑのＶＬＡＮタグを使用している。この例では、ＶＬＡＮ／ＩＰアドレス一貫性チェックを、アクセスを制御するために８０２．１ｑタグ情報が存在するＩＰスタックのサブシステムで実行する。この例において、コンピューティング要素は、コンピューティング要素が多数のＶＬＡＮに同時に通信接続されるよう、ＶＬＡＮ可能ネットワークインタフェースカード（ＮＩＣ）で構成されている。
【０１２２】
図１７は、実施例によるＶＬＡＮタグとＩＰアドレスとの間を強固に結合する構成のブロック図１７００である。コンピューティング要素１７０２および１７０４は、ＮＩＣ１７０８および１７１０を介して、ＶＬＡＮスイッチ１７０６のポートｖ１およびｖ２にそれぞれ通信接続される。ＶＬＡＮスイッチ１７０６も、アクセススイッチ１７１２および１７１４に通信接続される。ポートｖ１およびｖ２は、タグ形式で構成される。一実施例によれば、ＩＥＥＥ８０２．１ｑのＶＬＡＮタグ情報は、ＶＬＡＮスイッチ１７０６によって提供される。
【０１２３】
広域コンピューティンググリッド
上述したＶＳＦは、様々な方法でＷＡＮ上に分散される。
【０１２４】
一つの方法では、広域バックボーンは、非同期転送モード（ＡＴＭ）切替に基づいていてもよい。この場合、各ローカルエリアＶＬＡＮは、ＡＴＭ ＬＡＮエミュレーション（ＬＡＮＥ）標準の一部であるエミュレーテッドＬＡＮ（ＥＬＡＮ）を使用して広域に拡張される。このように、単一のＶＳＦは、ＡＴＭ／ＳＯＮＥＴ／ＯＣ−１２リンクなどの幾つかの広域リンク全体に広がる。ＥＬＡＮは、ＡＴＭ ＷＡＮ全体に拡張するＶＬＡＮの一部となる。
【０１２５】
他の方法では、ＶＳＦをＶＰＮシステムを使用してＷＡＮ全体に拡張する。本実施例において、ネットワークの根本的特徴は不適切になり、ＶＰＮを使用して２つ以上のＶＳＦをＷＡＮ全体にわたって相互接続し、単一の分散ＶＳＦを生成する。
【０１２６】
分散ＶＳＦにおいてデータを論理コピーするために、データミラーリング技術を使用することができる。あるいは、ＳＡＮ対ＡＴＭブリッジングまたはＳＡＮ対ギガビットイーサネット（登録商標）ブリッジングなどの幾つかのＳＡＮ対ＷＡＮブリッジング技術のうちの１つを使用して、ＷＡＮ上にＳＡＮをブリッジさせる。ＩＰはこのようなネットワーク上で問題なく動作するので、ＩＰネットワーク上に構成されたＳＡＮはＷＡＮ上で自然に拡張する。
【０１２７】
図１８は、ＷＡＮ接続上で拡張した複数のＶＳＦのブロック図である。サンノゼセンター、ニューヨークセンター、およびロンドンセンターは、ＷＡＮ接続によって接続されている。各ＷＡＮ接続は、上述したようにＡＴＭ、ＥＬＡＮまたはＶＰＮ接続から構成される。各センターは、少なくとも１つのＶＳＦおよび少なくとも１つのアイドルプールから構成される。例えば、サンノゼセンターはＶＳＦ１ＡおよびアイドルプールＡを有している。この構成において、センターの各アイドルプールのコンピューティングリソースは、他のセンターにあるＶＳＦへの割り当てまたは指定に対して利用できる。このような割り当てまたは指定が行われると、ＶＳＦはＷＡＮ上で拡張する。
【０１２８】
ＶＳＦの使用例
上記例で説明したＶＳＦアーキテクチャは、ウェブサーバシステムのからみで使用してもよい。従って、上記例は、特定のＶＳＦにおけるＣＰＵから構成したウェブサーバ、アプリケーションサーバおよびデータベースサーバに関して説明した。しかし、ＶＳＦアーキテクチャを他の多くのコンピューティング状況で使用し、他の種類のサービスを提供してもよく、且つ本発明はウェブサーバシステムに限定されるものではない。
【０１２９】
−内容分散ネットワークの一部としての分散ＶＳＦ
一実施例において、ＶＳＦは、広域ＶＳＦを使用して内容分散ネットワーク（ＣＤＮ）を提供する。ＣＤＮは、データの分散キャッシングを行うキャッシングサーバのネットワークである。キャッシングサーバのネットワークは、例えば、Ｉｎｋｔｏｍｉ Ｃｏｒｐｏｒａｔｉｏｎ， Ｓａｎ Ｍａｔｅｏ， Ｃａｌｉｆｏｒｎｉａから販売されているＴｒａｆｆｉｃＳｅｒｖｅｒ（ＴＳ）ソフトウェアを使用して実施できる。ＴＳはクラスタアウェアシステムであり、システムは、更に多くのＣＰＵがキャッシングトラフィックサーバコンピューティング要素の集合に追加されると、拡張する。従って、ＣＰＵの追加が拡張の機構であるシステムに非常に適している。
【０１３０】
この構成において、システムは、ＴＳなどのキャッシングソフトウェアを実行するＶＳＦの部分に更に多くのＣＰＵを動的に追加できるので、バースト状のウェブトラフィックが生じるのに近い地点でキャッシュ容量を増大させることが可能である。その結果、ＣＤＮは、適法的方法でＣＰＵおよびＩ／Ｏ帯域幅において動的に拡張するように構成される。
【０１３１】
−ホステッドイントラネットアプリケーションのＶＳＦ
ホストおよび管理されたサービスとして、企業リソースプランニング（ＥＲＰ）、ＯＲＭおよびＣＲＭソフトウェアなどのイントラネットアプリケーションの提供への興味が増大している。Ｃｉｔｒｉｘ ＷｉｎＦｒａｍｅおよびＣｉｔｒｉｘ ＭｅｔａＦｒａｍｅなどの技術により、企業は、Ｗｉｎｄｏｗｓ（登録商標）ＣＥ機器またはウェブブラウザなどの小型軽量クライアント上でのサービスとしてＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）アプリケーションを提供することができる。ＶＳＦは拡張可能にこのようなアプリケーションをホストすることが可能である。
【０１３２】
例えば、ドイツのＳＡＰ Ａｋｔｉｅｎｇｅｓｅｌｌｓｃｈａｆｔより販売されているＳＡＰ Ｒ／３ ＥＲＰソフトウェアにより、企業は多数のアプリケーションおよびデータサーバを使用してバランスをロードさせることができる。ＶＳＦの場合、リアルタイムの要求または他の要因に基づいてＶＳＦを拡張するために、企業は更に多くのアプリケーションサーバ（例えば、ＳＡＰダイアログサーバ）をＶＳＦに動的に追加する。
【０１３３】
同様に、Ｃｉｔｒｉｘ Ｍｅｔａｆｒａｍｅにより、更に多くのＣｉｔｒｉｘサーバを追加することにより、ホステッドＷｉｎｄｏｗｓ（登録商標）アプリケーションを実行するサーバファーム上でＷｉｎｄｏｗｓ（登録商標）アプリーションユーザを拡張することができる。この場合、ＶＳＦに対し、Ｃｉｔｒｉｘ ＭｅｔａＦｒａｍｅ ＶＳＦは、更に多くのＭｅｔａｆｒａｍｅがホストするＷｉｎｄｏｗｓ（登録商標）アプリケーションのユーザを収容するために更に多くのＣｉｔｒｉｘサーバを動的に追加する。多くのほかのアプリケーションが上述した例と同様にホストされることが明らかとなる。
【０１３４】
−ＶＳＦとの顧客相互作用
ＶＳＦは求めに応じて生成されるため、ＶＳＦを「所有する」ＶＳＦ顧客または組織は、ＶＳＦをカスタマイズするために様々な方法でシステムと互いに影響し合うことができる。例えば、ＶＳＦは制御プレーンを介して即座に生成および変更されるので、ＶＳＦ顧客は特権アクセスが許されて、そのＶＳＦ自身を生成および変更してもよい。特権アクセスは、ウェブページおよび保全アプリケーション、トークンカード認証、ケルベロス交換、または他の適切な保全要素によって与えられたパスワード認証を使用して与えられる。
【０１３５】
一実施例において、一式のウェブページは、コンピューティング要素または別個のサーバによって供給される。ウェブページにより、顧客は、層の数、特定の層におけるコンピューティング要素の数、各要素に対して使用されるハードウェアおよびソフトウェアプラットフォーム、どの種類のウェブサーバ、アプリケーションサーバ、またはデータベースサーバソフトウェアこれらのコンピューティング要素上で事前に構成するかなどを指定することによって、カスタムＶＳＦを生成することができる。従って、顧客は仮想供給コンソールを備えている。
【０１３６】
顧客またはユーザがこのような供給情報を入力した後、制御プレーンはオーダーを解析および評価し、それを実行するために待ち行列に入れる。オーダーは人間の管理者が再検討して、適切であることを確認することができる。企業のクレジット確認を実行させて、要求されたサービスに対して支払いを行う適切なクレジットを有していることを確認できる。供給オーダーが承認されると、制御プレーンは順序に適合するＶＳＦを構成し、ＶＳＦにおける一又は二以上のコンピューティング要素へのルートアクセスを与えるパスワードを顧客に返す。次に、顧客はアプリケーションのマスターコピーをアップロードして、ＶＳＦで実行することができる。
【０１３７】
コンピューティンググリッドを採用する企業が営利目的の企業である場合、ウェブページから、クレジットカード、ＰＯ番号、電子小切手、または他の支払方法などの支払いに関する情報も受信することができる。
【０１３８】
別の実施例において、ウェブページにより、顧客は、リアルタイムロードに基づいて、要素の最小数と最大数との間のＶＳＦの自動拡大縮小など、幾つかのＶＳＦサービスプランのうちの１つを選択することができる。顧客は、ウェブサーバなどの特定の層におけるコンピューティング要素の最小数、またはＶＳＦ最小サーバ容量を有していなければならない期間などのパラメータの変更を可能にする制御値を有することができる。パラメータは、顧客の為替手形割引率を自動的に調整し、且つ課金ログファイル項目を生成する課金ソフトウェアにリンクしていてもよい。
【０１３９】
特権アクセス機構により、顧客は報告書を得て、使用、ロード、毎秒のヒット数またはトランザクション数に関するリアルタイム情報を監視し、リアルタイム情報に基づくＶＳＦの特徴を調整することができる。上記特色により、サーバファームの構築に対する従来の手動による方法よりも優れた利点が得られる。従来の方法では、ユーザは、様々な方法でサーバを追加し、サーバファームを構成する面倒な手動手順を介さずに、サーバファームの特性を自動的に変更することはできない。
【０１４０】
−ＶＳＦに対する課金モデル
ＶＳＦの動的性質を考えると、コンピューティンググリッドおよびＶＳＦを採用する企業は、ＶＳＦのコンピューティング要素および記憶要素の実際の使用に基づくＶＳＦの課金モデルを使用して、ＶＳＦを所有する顧客に対してサービス料金を請求することができる。ここに開示するＶＳＦアーキテクチャおよび方法は、あるＶＳＦのリソースは静的に指定されないので、「即金払い」課金モデルを可能にする。従って、そのサーバファームの使用負荷が極めて変わりやすい特定の顧客は、一定のピークサーバ容量に関連する料金は課金されず、使用、瞬間使用などの実行平均を反映する料金が課金されるので、料金を節約することができる。
【０１４１】
例えば、企業は、１０台のサーバなどのコンピューティング要素の最小数に対する均一料金を規定し、且つリアルタイムの負荷が１０以上の要素を必要としたときを規定する課金モデルを使用して運営するので、ユーザは、何台の追加サーバが必要であり、且つそれらが必要であった時間に基づいて、追加サーバの追加料金で課金される。このような課金の単位は、請求されるリソースを反映してもよい。例えば、課金は、ＭＩＰＳ時間、ＣＰＵ時間、ＣＰＵ千秒などの単位で表してもよい。
【０１４２】
−顧客可視制御プレーンＡＰＩ
他の方法では、ＶＳＦの容量は、リソース変更のための制御プレーンの呼び出しを規定するアプリケーションプログラミングインタフェース（ＡＰＩ）を顧客に与えることで、制御されてもよい。従って、顧客が用意したアプリケーションプログラムは、ＡＰＩを使用して呼び出しまたは要求を発し、更に多くのサーバ、更に多くのストレージ、更に高い処理能力などを要求することができる。この方法は、顧客がコンピューティンググリッド環境について知り、制御プレーンが与える能力を利用するためにアプリケーションプログラムを必要とするときに使用してもよい。
【０１４３】
上記アーキテクチャにおいて、何れの部分も、顧客がコンピューティンググリッドとの使用でそのアプリケーションを変更する必要はない。既存のアプリケーションは、手動構成したサーバファームで動作するのと同様に動作する。しかしながら、制御プレーンによって与えられるリアルタイム負荷監視機能に基づいて必要とするコンピューティングリソースをよりよく理解するのであれば、アプリケーションはコンピューティンググリッドで可能なダイナミズムを利用することができる。アプリケーションプログラムによるサーバファームのコンピューティング容量の変更を可能にする上記性質のＡＰＩは、サーバファームの構築に対する既存の手動方法を用いては可能ではない。
【０１４４】
−自動更新およびバージョニング
ここに開示する方法および機構を使用し、制御プレーンは、ＶＳＦのコンピューティング要素で実行されるオペレーティングシステムソフトウェアの自動更新およびバージョニングを行うことができる。従って、エンドユーザまたは顧客は、新たなパッチ、バグフィックスなどでオペレーティングシステムを更新することについて心配する必要はない。制御プレーンは、このようなソフトウェア要素が受信されるとそのライブラリを維持し、影響のあった全てのＶＳＦのコンピューティング要素にこれらを自動的に分散およびインストールすることができる。
【０１４５】
実施機構
コンピューティング要素および制御プレーンは幾つかの形式で実施されてもよく、且つ本発明は特定の形式に限定されることはない。一実施例において、各コンピューティング要素は、不揮発性記憶装置１９１０を除き、図１９に示す要素を有する汎用デジタルコンピュータであり、また制御プレーンは、上記プロセスを実施するプログラム命令の制御の下で動作する図１９に示す種類の汎用デジタルコンピュータである。
【０１４６】
図１９は、本発明の実施例が実施されうるコンピュータシステム１９００を示すブロック図である。コンピュータシステム１９００は、情報を伝達するバス１９０２または他の通信機構、および情報を処理するためにバス１９０２に接続されたプロセッサ１９０４を含んでいる。コンピュータシステム１９００はまた情報とプロセッサ１９０４が実行する命令を保存するためにバス１９０２に接続されたランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置などのメインメモリ１９０６を含んでいる。メインメモリ１９０６も、プロセッサ１９０４が実行する命令の実行中に、一時的数値変数や他の中間情報を保存するのに使用することができる。コンピュータシステム１９００は更に、静的情報およびプロセッサ１９０４の命令を保存するために、バス１９０２に接続されたリードオンリメモリ（ＲＯＭ）１９０８や他の静的記憶装置を含んでいる。磁気ディスクや光ディスクなどの記憶装置１９１０が設けられ、情報および命令を保存するためにバス１９０２に接続されている。
【０１４７】
コンピュータシステム１９００は、情報をコンピュータユーザに表示するために、陰極線管（ＣＲＴ）などのディスプレイ１９１２にバス１９０２を介して接続されていてもよい。英数字および他のキーを含む入力機器１９１４は、情報および命令の選択をプロセッサ１９０４に伝達するために、バス１９０２に接続されている。他の種類のユーザ入力機器は、方向情報および命令の選択をプロセッサ１９０４に伝達し、且つカーソルの動きをディスプレイ１９１２上で制御するためのマウス、トラックボール、カーソル方向キーなどのカーソルコントロール１９１６である。この入力機器は一般に、機器が平面における位置を指定することを可能にする２つの軸、すなわち第１軸（例えばｘ）および第２軸（例えばｙ）における２つの自由度を有している。
【０１４８】
本発明は、拡張可能コンピューティングシステムを制御するための、コンピュータシステム１９００の使用に関連している。本発明の一実施例によれば、拡張可能コンピューティングシステムの制御は、メインメモリ１９０６に含まれる一又は二以上の命令の一又は二以上のシーケンスを実行するプロセッサ１９０４に応じて、コンピュータシステム１９００によって行われる。このような命令は、記憶装置１９１０などの別のコンピュータで読み取り可能な媒体からメインメモリ１９０６に読み込まれる。メインメモリ１９０６に含まれる命令のシーケンスを実行することにより、プロセッサ１９０４は、上記のプロセス工程を実行する。マルチ処理構成において一又は二以上のプロセッサを使用し、メインメモリ１９０６に含まれる命令のシーケンスを実行してもよい。別の実施例においては、配線接続された回路を、ソフトウェア命令の代わりに、あるいはこれと組み合わせて使用し、本発明を実施してもよい。従って、本発明の実施例は、ハードウェア回路およびソフトウェアの特定の組合せに限定されない。
【０１４９】
ここで使用する用語「コンピュータで読み取り可能な媒体」は、プロセッサ１９０４に命令を与えて実行することに関連する媒体を意味する。このような媒体は、不揮発性媒体、揮発性媒体および伝送媒体を含むがこれらに限定されない多くの形式を取ることができる。不揮発性媒体は例えば、記憶装置１９１０などの光または磁気ディスクを含む。揮発性媒体は、メインメモリ１９０６などの動的メモリを含む。伝送媒体は、バス１９０２を構成する配線を含む同軸ケーブル、銅線および光ファイバーを含む。伝送媒体も、無線および赤外線データ通信の間に生成されるような音波や光波の形式を取ることができる。
【０１５０】
コンピュータで読み取り可能な媒体の一般的形式は、例えば、以下に説明するようなフロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、ほかの磁気媒体、ＣＤ−ＲＯＭ、他の光媒体、パンチカード、紙テープ、穴のパターンを有する他の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、他のメモリチップまたはカートリッジ、搬送波、またはコンピュータが読み取り可能なほかの媒体を含む。
【０１５１】
コンピュータが読み取り可能な媒体の様々な形式は、プロセッサ１９０４に一又は二以上の命令の一又は二以上のシーケンスを送って実行させることに関連していてもよい。例えば、命令はまず、遠隔コンピュータの磁気ディスクに送られる。遠隔コンピュータはその動的メモリに命令をロードして、モデムを使用して電話回線上で命令を送る。コンピュータシステム１９００に対して遠隔にあるモデムは、電話回線上のデータを受信し、赤外線トランスミッタを使用してデータを赤外線信号に変換することができる。バス１９０２に接続された赤外線ディテクタは、赤外線信号で運ばれるデータを受信して、バス１９０２にデータを出す。バス１９０２はデータをメインメモリ１９０６に送り、ここからプロセッサ１９０４は命令の検索と実行を行う。メインメモリ１９０６が受信した命令は、プロセッサ１９０４の実行の前または後で記憶装置１９１０に随意に保存することができる。
【０１５２】
コンピュータシステム１９００は、バス１９０２に接続された通信インタフェース１９１８も含んでいる。通信インタフェース１９１８は、ローカルネットワーク１９２２に接続されたネットワークリンク１９２０へ接続する双方向データ通信を行う。例えば、通信インタフェース１９１８は、対応する種類の電話回線へのデータ通信接続を行うためのデジタル総合サービスネットワーク（ＩＳＤＮ）カードまたはモデムであってもよい。他の例とでは、通信インタフェース１９１８は、互換性のあるＬＡＮへのデータ通信接続を行うためのローカルエリアネットワーク（ＬＡＮ）であってもよい。無線リンクも実施することができる。このような実施において、通信インタフェース１９１８は、様々な種類の情報を表すデジタルデータストリームを伝える電気、電磁または光信号を送受信する。
【０１５３】
ネットワークリンク１９２０は一般に、一又は二以上のネットワークを介して、他のデータ機器へのデータ通信を行う。例えば、ネットワークリンク１９２０は、ローカルネットワーク１９２２を介して、インターネットサービスプロバイダ（ＩＳＰ）１９２６によって運営されるホストコンピュータ１９２４またはデータ機器への接続を提供する。ＩＳＰ１９２６は、一般に「インターネット」と現在呼ばれている世界規模パケットデータ通信ネットワーク１９２８を介してデータ通信サービスを提供する。ローカルネットワーク１９２２およびインターネット１９２８は共に、デジタルデータストリームを伝える電気、電磁または光信号を使用する。様々なネットワークおよびネットワークリンク１９２０上の信号、および通信インタフェース１９１８を介して、コンピュータシステム１９００に対してデジタルデータを送受する信号は、情報を運ぶ搬送波の典型的な形である。
【０１５４】
コンピュータシステム１９００は、ネットワーク、ネットワークリンク１９２０および通信インタフェース１９１８を介して、メッセージを送信し、且つプログラムコードを含むデータを受信することができる。インターネットの例では、サーバ１９３０は、インターネット１９２８、ＩＳＰ１９２６、ローカルネットワーク１９２２、および通信インタフェース１９１８を介して、アプリケーションプログラムの要求コードを送信する。本発明によれば、このようなダウンロードしたアプリケーションは、ここに説明する拡張可能コンピューティングシステムの制御を規定する。
【０１５５】
受信コードは、受信されるとプロセッサ１９０４により実行、および／または後で実行するために記憶装置１９１０あるいは他の不揮発性ストレージに保存しておいてもよい。このように、コンピュータシステム１９００は、搬送波という形でアプリケーションコードを得ることができる。
【０１５６】
ここに開示したコンピューティンググリッドは、時にパワーグリッドと呼ばれる公共電力ネットワークと概念的に比較される。パワーグリッドは、単一の大規模電力インフラストラクチャを介して電力サービスを得るために、多数の関係者に拡張可能手段を提供する。同様に、ここに開示したコンピューティンググリッドは、単一の大規模コンピューティングインフラストラクチャを使用することによって、多数の組織にコンピューティングサービスを提供する。パワーグリッドを使用するので、電力消費者はその個人電力設備を自主的に管理することはない。例えば、ユーティリティ消費者がその設備または共有設備において個人用発電機を運転させ、個人でその容量および増加を管理する理由はない。その代わりに、パワーグリッドは人口の大部分へ広範囲に電力を供給することができるので、大きなスケールメリットが得られる。同様に、ここに開示するコンピューティンググリッドは、単一の大規模なコンピューティングインフラストラクチャを使用して、人口の大部分にコンピューティングサービスを提供することができる。
【０１５７】
上記の詳述において、具体的な実施例に関連して本発明を説明した。しかしながら、本発明の広大な精神および範囲から逸脱することなく、様々な改良および変更を本発明に加えることが可能であることは明白となろう。従って、説明および図面は、限定的意味ではなく例証において考慮される。
【図面の簡単な説明】
【図１Ａ】
図１Ａは、単一のコンピューティング要素トポロジーを使用する単純なウェブサイトのブロック図である。
【図１Ｂ】
図１Ｂは、１層ウェブサーバファームのブロック図である。
【図１Ｃ】
図１Ｃは、３層ウエブサーバファームのブロック図である。
【図２】
図２は、ローカルコンピューティンググリッドを含む拡張可能コンピューティングシステム２００の１つの構成を示すブロック図である。
【図３】
図３は、ＳＡＮゾーンを特徴付ける典型的な仮想サーバファームのブロック図である。
【図４Ａ】
図４Ａは、コンピューティング要素の追加および仮想サーバファームからの要素の除去に関連する連続工程を示すブロック図である。
【図４Ｂ】
図４Ｂは、コンピューティング要素の追加および仮想サーバファームからの要素の除去に関連する連続工程を示すブロック図である。
【図４Ｃ】
図４Ｃは、コンピューティング要素の追加および仮想サーバファームからの要素の除去に関連する連続工程を示すブロック図である。
【図４Ｄ】
図４Ｄは、コンピューティング要素の追加および仮想サーバファームからの要素の除去に関連する連続工程を示すブロック図である。
【図５】
図５は、仮想サーバファームシステム、コンピューティンググリッド、監視機構の実施例のブロック図である。
【図６】
図６は、仮想サーバファームの論理接続のブロック図である。
【図７】
図７は、仮想サーバファームの論理接続のブロック図である。
【図８】
図８は、仮想サーバファームの論理接続のブロック図である。
【図９】
図９は、制御プレーンおよびデータプレーンの論理関係のブロック図である。
【図１０】
図１０は、マスター制御選択プロセスの状態図である。
【図１１】
図１１は、スレーブ制御プロセスの状態図である。
【図１２】
図１２は、マスター制御プロセスの状態図である。
【図１３】
図１３は、中央制御プロセッサおよび多数の制御プレーンおよびコンピューティンググリッドのブロック図である。
【図１４】
図１４は、制御プレーンおよびコンピューティンググリッドの部分を実施するアーキテクチャのブロック図である。
【図１５】
図１５は、ファイアウォールによって保護されるコンピューティンググリッドを有するシステムのブロック図である。
【図１６】
図１６は、制御プレーンをコンピューティンググリッドに接続するアーキテクチャのブロック図である。
【図１７】
図１７は、ＶＬＡＮタグとＩＰアドレスを密に結合する配置のブロック図である。
【図１８】
図１８は、ＷＡＮ接続上で拡張した複数のＶＳＦのブロック図である。
【図１９】
図１９は、実施例が実施されるコンピュータシステムのブロック図である。
Claims (31)
- マスター制御機構と、
マスター制御機構に通信接続され、且つマスター制御機構からの一又は二以上の命令に応じて、
処理リソースの集合から処理リソースの第１サブセットを選択し、
記憶リソースの集合から記憶リソースの第１サブセットを選択し、且つ
処理リソースの第１サブセットを記憶リソースの第１サブセットに通信接続させることにより、
処理リソースの第１サブセットおよび記憶リソースの第１サブセットを含む第１論理リソースグループを確立するように構成された、一又は二以上のスレーブ制御機構とを具備して成る制御装置。 - マスター制御機構が一又は二以上のプロセッサ上で実行されるマスター制御プロセスであり、且つ一又は二以上のスレーブ制御機構が一又は二以上のプロセッサ上で実行される一又は二以上のスレーブプロセスである、請求項１に記載の制御装置。
- マスター制御機構が一又は二以上のマスタープロセッサであり、且つ一又は二以上のスレーブ制御機構が一又は二以上のスレーブプロセッサである、請求項１に記載の制御装置。
- マスター制御機構が、スレーブ制御プロセス機構のローディングに基づいて、一又は二以上のスレーブ制御機構間で、処理リソースのサブセットからの一又は二以上の処理リソースおよび記憶リソースのサブセットからの一又は二以上の記憶リソースの制御を、動的に再割り当てするように構成されている、請求項１に記載の制御装置。
- マスター制御機構が、スレーブ制御プロセス機構のローディングに基づいて、一又は二以上の追加のスレーブ制御機構を動的に割り当て、且つ処理リソースのサブセットからの一又は二以上の処理リソースおよび記憶リソースのサブセットからの一又は二以上の記憶リソースの制御を、追加された一又は二以上のスレーブ制御機構に割り当てるよう構成されている、請求項１に記載の制御装置。
- マスター制御機構が、スレーブ制御プロセス機構のローディングに基づいて、一又は二以上のスレーブ制御機構から一又は二以上の特定のスレーブ制御機構にすでに割り当てられている、処理リソースのサブセットからの一又は二以上の特定の処理リソースおよび記憶リソースのサブセットからの一又は二以上の特定の記憶リソースの制御を、一又は二以上のスレーブ制御機構からの一又は二以上の他のスレーブ制御機構に再割り当てし、且つ
一又は二以上の特定のスレーブ制御機構の割り当て解除を動的に行なうよう構成されている、請求項１に記載の制御装置。 - マスター制御機構が、
一又は二以上のスレーブ制御機構の状態を決定し、
一又は二以上のスレーブ制御機構からの一又は二以上の特定のスレーブ制御機構が正しく応答しない、または機能していない場合に、一又は二以上の特定のスレーブ制御機構の再起動を試み、且つ
一又は二以上の特定のスレーブ制御機構が再起動できない場合に、
一又は二以上の新たなスレーブ制御機構を開始し、且つ
一又は二以上の特定のスレーブ制御機構から、一又は二以上の新たなスレーブ制御機構へ処理リソースおよび記憶リソースの制御を再割り当てするように構成されている、請求項１に記載の制御装置。 - 一又は二以上のスレーブ制御機構が、
マスター制御機構の状態を決定し、且つ
マスター制御機構が異常終了したり、もはや適切に機能していない場合に、
一又は二以上のスレーブ制御機構から新たなマスター制御機構を選択するように構成されている、請求項１に記載の制御装置。 - マスター制御機構からの一又は二以上の命令が、第１論理リソースグループの予想された処理および記憶必要条件に基づいて生成される、請求項１に記載の制御装置。
- 一又は二以上のスレーブ制御機構が更に、マスター制御機構からの一又は二以上の命令に応じて、
処理リソースの第１サブセットの処理リソース数の動的変更と、
記憶リソースの第１サブセットの記憶リソース数の動的変更と、
処理リソースの第１サブセットの処理リソース数および記憶リソースの第１サブセットの記憶リソース数の変更を反映させるための、処理リソースの第１サブセットと記憶リソースの第１サブセットとの間の通信接続の動的変更を行なうよう構成されている、請求項１に記載の制御装置。 - 処理リソースの第１サブセットの処理リソース数および記憶リソースの第１サブセットの記憶リソース数の変更が、処理リソースの第１サブセットおよび記憶リソースの第１サブセットの実際のローディングに基づいて、マスター制御機構によって指示される、請求項１０に記載の制御装置。
- 一又は二以上のスレーブ制御機構が更に、マスター制御機構からの一又は二以上の命令に応じて、処理リソースの第２サブセットおよび記憶リソースの第２サブセットを含む第２論理リソースグループを確立するように構成されており、第２論理リソースグループは、
処理リソースの集合から処理リソースの第２サブセットを選択し、
処理リソースの集合から記憶リソースの第２サブセットを選択し、且つ
処理リソースの第２サブセットを記憶リソースの第２サブセットに通信接続させることにより、第１論理リソースグループから通信分離される、請求項１に記載の制御装置。 - 処理リソースの第１サブセットが、一又は二以上の記憶領域ネットワーク（ＳＡＮ）スイッチを使用することにより、記憶リソースの第１サブセットに通信接続され、
処理リソースの第２サブセットが、一又は二以上のＳＡＮスイッチを使用することにより、記憶リソースの第２サブセットに通信接続され、
第２論理リソースグループが、タギングおよびＳＡＮゾーニングを使用することにより、第１論理リソースグループから通信分離される、請求項１２に記載の制御装置。 - ＳＡＮゾーニングが、ポートレベルＳＡＮゾーニングまたはＬＵＮレベルＳＡＮゾーニングを使用することにより実行される、請求項１３に記載の制御装置。
- マスター制御機構が中央制御機構に通信接続され、
マスター制御機構が、第１論理リソースグループへのローディング情報を中央制御機構に与えるよう構成され、且つ
マスター制御機構が、中央制御機構から受信した一又は二以上の中央制御命令に基づいて、一又は二以上のスレーブ制御機構への一又は二以上の命令を生成するように構成されている、請求項１に記載の制御装置。 - マスター制御機構を開始する工程と、
マスター制御機構に通信接続され、且つマスター制御機構からの一又は二以上の命令に応じて、
処理リソースの集合から処理リソースの第１サブセットを選択し、
記憶リソースの集合から記憶リソースの第１サブセットを選択し、且つ
処理リソースの第１サブセットを記憶リソースの第１サブセットに通信接続させることにより、
処理リソースの第１サブセットおよび記憶リソースの第１サブセットを含む第１論理リソースグループを確立するように構成された一又は二以上のスレーブ制御機構を開始する工程とを具備して成る処理リソースを管理する方法。 - マスター制御機構を開始する工程が、一又は二以上のプロセッサ上で実行されるマスター制御プロセスを開始する工程を含み、且つ
一又は二以上のスレーブ制御機構を開始する工程が、一又は二以上のプロセッサ上で実行される一又は二以上のスレーブプロセスを開始する工程を含む、請求項１６に記載の方法。 - マスター制御機構を開始する工程が、一又は二以上のマスター制御プロセッサを開始する工程を含み、且つ
一又は二以上のスレーブ制御機構を開始する工程が、一又は二以上のスレーブプロセッサを開始する工程を含む、請求項１６に記載の方法。 - スレーブ制御プロセス機構のローディングに基づいて、処理リソースのサブセットからの一又は二以上の処理リソースおよび記憶リソースのサブセットからの一又は二以上の記憶リソースの制御を、一又は二以上のスレーブ制御機構の間で、動的に再割り当てするマスター制御機構を更に含む、請求項１６に記載の方法。
- スレーブ制御プロセス機構のローディングに基づいて、一又は二以上の追加のスレーブ制御機構を動的に割り当て、且つ処理リソースのサブセットからの一又は二以上の処理リソースおよび記憶リソースのサブセットからの一又は二以上の記憶リソースの制御を、追加された一又は二以上のスレーブ制御機構に割り当てるマスター制御機構を更に含む、請求項１６に記載の方法。
- スレーブ制御プロセス機構のローディングに基づいて、一又は二以上のスレーブ制御機構からの一又は二以上の特定のスレーブ制御機構にすでに割り当てられている、処理リソースのサブセットからの一又は二以上の特定の処理リソースおよび記憶リソースのサブセットからの一又は二以上の特定の記憶リソースの制御を、一又は二以上のスレーブ制御機構からの一又は二以上の他のスレーブ制御機構に再割り当てするマスター制御機構を更に含む、請求項１６に記載の方法。
- 一又は二以上のスレーブ制御機構の状態を決定し、
一又は二以上のスレーブ制御機構からの一又は二以上の特定のスレーブ制御機構が応答しないあるいは適切に機能していない場合に、一又は二以上の特定のスレーブ制御機構を再起動させるよう試み、且つ
一又は二以上の特定のスレーブ制御機構が再起動できない場合に、一又は二以上の新たな制御機構を開始し、且つ一又は二以上の特定のスレーブ制御機構から一又は二以上の新たなスレーブ制御機構に、処理リソースおよび記憶リソースの制御を再割り当てするマスター制御機構を更に含む、請求項１６に記載の方法。 - マスター制御機構の状態を決定し、且つ
マスター制御機構が異常終了したり、もはや適切に機能していない場合に、一又は二以上のスレーブ制御機構から新たなマスター制御機構を選択する一又は二以上のスレーブ制御機構を更に含む、請求項１６に記載の方法。 - マスター制御機構からの一又は二以上の命令が、第１論理リソースグループの予測された処理および記憶必要条件に基づいて生成される、請求項１６に記載の方法。
- マスター制御機構からの一又は二以上の命令に応じて、
処理リソースの第１サブセットにおける処理リソースの数の動的変更と、
記憶リソースの第１サブセットにおける記憶リソースの数の動的変更と、
処理リソースの第１サブセットにおける処理リソースの数と記憶リソースの第１サブセットにおける記憶リソースの数の変更を反映させるための、処理リソースの第１サブセットおよび記憶リソースの第１サブセットとの間の通信接続の動的変更とを行なう一又は二以上のスレーブ制御機構を更に含む、請求項１６に記載の方法。 - 処理リソースの第１サブセットにおける処理リソースの数および記憶リソースの第１サブセットにおける記憶リソースの数の変更が、処理リソースの第１サブセットおよび記憶リソースの第１サブセットの実際のローディングに基づいて、マスター制御機構によって指示される、請求項２５に記載の方法。
- マスター制御機構からの一又は二以上の命令に応じて、処理リソースの第２サブセットおよび記憶リソースの第２サブセットを含む第２論理リソースグループを確立する一又は二以上のスレーブ制御機構を更に含み、第２論理リソースグループが、
処理リソースの集合からの処理リソースの第２サブセットの選択、
処理リソースの集合からの記憶リソースの第２サブセットの選択、且つ
記憶リソースの第２サブセットへの処理リソースの第２サブセットの通信接続によって、第１論理リソースグループから情報伝達分離されている、請求項１６に記載の方法。 - 処理リソースの第１サブセットが、一又は二以上の記憶領域ネットワーク（ＳＡＮ）スイッチを使用することによって記憶リソースの第１サブセットに通信接続され、
処理リソースの第２サブセットが、一又は二以上のＳＡＮスイッチを使用することによって記憶リソースの第２サブセットに通信接続され、且つ
第２論理リソースグループが、タギングおよびＳＡＮゾーニングすることによって第１論理リソースグループから通信分離されている、請求項２７に記載の方法。 - ＳＡＮゾーニングが、ポートレベルＳＡＮゾーニングまたはＬＵＮレベルＳＡＮゾーニングを使用することにより実行される、請求項２８に記載の方法。
- マスター制御機構が中央制御機構に通信接続され、
マスター制御機構が、第１論理リソースグループのローディング情報を中央制御機構に与えるよう構成され、
マスター制御機構がさらに、中央制御機構から受信した一又は二以上の中央制御命令に基づいて、一又は二以上のスレーブ制御機構の一又は二以上の命令を生成するように構成されている、請求項１６に記載の方法。 - 処理リソースを管理するための一又は二以上の命令の一又は二以上のシーケンスを伝えるコンピュータで読み取り可能な媒体であって、一又は二以上のプロセッサで一又は二以上の命令の一又は二以上のシーケンスを実行すると、一又は二以上のプロセッサが、
マスター制御機構を開始させる工程と、
マスター制御機構に通信接続され、且つマスター制御機構からの一又は二以上の命令に応じて、処理リソースの第１サブセットおよび記憶リソースの第１サブセットを含む第１論理リソースグループを確立するように構成されている一又は二以上のスレーブ制御機構を開始させる工程とを、
処理リソースの集合から処理リソースの第１サブセットを選択し、
記憶リソースの集合から記憶リソースの第１サブセットを選択し、且つ
記憶リソースの第１サブセットに処理リソースの第１サブセットを通信接続させることによって行なう、コンピュータで読み取り可能な媒体。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US21309000P | 2000-06-20 | 2000-06-20 | |
| US60/213,090 | 2000-06-20 | ||
| US09/630,440 | 2000-08-02 | ||
| US09/630,440 US6597956B1 (en) | 1999-08-23 | 2000-08-02 | Method and apparatus for controlling an extensible computing system |
| PCT/US2001/019053 WO2002003203A2 (en) | 2000-06-20 | 2001-06-13 | Method and apparatus for controlling an extensible computing system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004508616A true JP2004508616A (ja) | 2004-03-18 |
| JP4712279B2 JP4712279B2 (ja) | 2011-06-29 |
Family
ID=44292692
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002508204A Expired - Lifetime JP4712279B2 (ja) | 2000-06-20 | 2001-06-13 | 拡張可能コンピューティングシステムの制御方法および装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4712279B2 (ja) |
Cited By (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005056408A (ja) * | 2003-07-23 | 2005-03-03 | Semiconductor Energy Lab Co Ltd | マイクロプロセッサ及びグリッドコンピューティングシステム |
| WO2006040811A1 (ja) * | 2004-10-12 | 2006-04-20 | Fujitsu Limited | リソース交換処理プログラムおよびリソース交換処理方法 |
| WO2006043307A1 (ja) * | 2004-10-18 | 2006-04-27 | Fujitsu Limited | 運用管理プログラム、運用管理方法および運用管理装置 |
| WO2006043309A1 (ja) * | 2004-10-18 | 2006-04-27 | Fujitsu Limited | 運用管理プログラム、運用管理方法および運用管理装置 |
| WO2006043308A1 (ja) * | 2004-10-18 | 2006-04-27 | Fujitsu Limited | 運用管理プログラム、運用管理方法および運用管理装置 |
| JP2006260433A (ja) * | 2005-03-18 | 2006-09-28 | Hitachi Ltd | リソース貸借方法、および、リソース貸借システム |
| JP2007500386A (ja) * | 2003-07-28 | 2007-01-11 | エスアーペー アーゲー | グリッド組織 |
| JP2007500888A (ja) * | 2003-07-28 | 2007-01-18 | エスアーペー アーゲー | グリッド管理可能なアプリケーションプロセス管理方式 |
| WO2007077600A1 (ja) * | 2005-12-28 | 2007-07-12 | Fujitsu Limited | 運用管理プログラム、運用管理方法および運用管理装置 |
| JP2007520814A (ja) * | 2004-01-27 | 2007-07-26 | インターナショナル・ビジネス・マシーンズ・コーポレーション | プロビジョニングデータ処理システムにおいてリソースを識別、予約、および論理的にプロビジョニングする方法、システム、およびプログラム |
| JP2007526557A (ja) * | 2004-01-30 | 2007-09-13 | インターナショナル・ビジネス・マシーンズ・コーポレーション | コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理 |
| WO2008004275A1 (fr) * | 2006-07-04 | 2008-01-10 | Fujitsu Limited | Programme, procédé et dispositif de reprise sur sinistre |
| JP2008527521A (ja) * | 2005-01-12 | 2008-07-24 | インターナショナル・ビジネス・マシーンズ・コーポレーション | グリッド・ジョブに関するグリッド・プロバイダの選択を自動的に制御するための方法、システム、およびコンピュータ・プログラム |
| JP2009500717A (ja) * | 2005-06-30 | 2009-01-08 | マイクロソフト コーポレーション | サーバファームにおけるソリューションの配備 |
| US7703029B2 (en) | 2003-07-28 | 2010-04-20 | Sap Ag | Grid browser component |
| JPWO2008096390A1 (ja) * | 2007-02-02 | 2010-05-20 | 株式会社ソニー・コンピュータエンタテインメント | 仲介サーバ、端末、及び分散処理方法 |
| US7793290B2 (en) | 2004-12-20 | 2010-09-07 | Sap Ag | Grip application acceleration by executing grid application based on application usage history prior to user request for application execution |
| US7810090B2 (en) | 2003-12-17 | 2010-10-05 | Sap Ag | Grid compute node software application deployment |
| JP2010250778A (ja) * | 2009-04-20 | 2010-11-04 | Ntt Data Corp | コンピュータリソース提供システム、コンピュータリソース提供方法およびリソース取引プログラム |
| JP2010282667A (ja) * | 2010-09-24 | 2010-12-16 | Hitachi Ltd | リソース貸借方法、および、リソース貸借システム |
| JP2011060317A (ja) * | 2010-11-15 | 2011-03-24 | Fujitsu Ltd | 運用管理プログラム、運用管理方法および運用管理装置 |
| JP2012043445A (ja) * | 2011-09-16 | 2012-03-01 | Hitachi Ltd | 業務引き継ぎ方法、計算機システム、及び管理サーバ |
| US8176408B2 (en) | 2005-09-12 | 2012-05-08 | Microsoft Corporation | Modularized web provisioning |
| US8352724B2 (en) | 2003-07-23 | 2013-01-08 | Semiconductor Energy Laboratory Co., Ltd. | Microprocessor and grid computing system |
| JP2013161252A (ja) * | 2012-02-03 | 2013-08-19 | Fujitsu Ltd | 冗長コンピュータ制御プログラム、方法、及び装置 |
| KR20140122240A (ko) * | 2012-02-03 | 2014-10-17 | 마이크로소프트 코포레이션 | 확장 가능한 환경에서의 파티션 관리 기법 |
| US10635500B2 (en) | 2012-02-03 | 2020-04-28 | Microsoft Technology Licensing, Llc | Decoupling partitioning for scalability |
| CN112988532A (zh) * | 2021-01-27 | 2021-06-18 | 腾讯科技（深圳）有限公司 | 埋点事件的上报方法、装置、服务器及存储介质 |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06103092A (ja) * | 1992-09-18 | 1994-04-15 | Hitachi Ltd | 仮想計算機システム |
| JPH07219913A (ja) * | 1994-01-28 | 1995-08-18 | Fujitsu Ltd | マルチプロセッサシステムの制御方法及び装置 |
| JPH07295841A (ja) * | 1992-10-19 | 1995-11-10 | Internatl Business Mach Corp <Ibm> | 動的に資源を再構成するための方法及びシステム |
| JPH0926889A (ja) * | 1995-07-13 | 1997-01-28 | Hitachi Ltd | 仮想計算機システム |
| JPH0981401A (ja) * | 1995-09-19 | 1997-03-28 | Hitachi Ltd | 大域的なリソースキャッピング方法 |
| JP2792649B2 (ja) * | 1986-08-29 | 1998-09-03 | スインキング マシーンズ コーポレーション | 並列コンピュータシステム |
| JPH11328135A (ja) * | 1998-02-06 | 1999-11-30 | Ncr Internatl Inc | 並列処理コンピュ―タ・システム |
| JP2000132530A (ja) * | 1997-11-04 | 2000-05-12 | Digital Equip Corp <Dec> | マルチプロセッサコンピュ―タシステム及びその動作方法 |
-
2001
- 2001-06-13 JP JP2002508204A patent/JP4712279B2/ja not_active Expired - Lifetime
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2792649B2 (ja) * | 1986-08-29 | 1998-09-03 | スインキング マシーンズ コーポレーション | 並列コンピュータシステム |
| JPH06103092A (ja) * | 1992-09-18 | 1994-04-15 | Hitachi Ltd | 仮想計算機システム |
| JPH07295841A (ja) * | 1992-10-19 | 1995-11-10 | Internatl Business Mach Corp <Ibm> | 動的に資源を再構成するための方法及びシステム |
| JPH07219913A (ja) * | 1994-01-28 | 1995-08-18 | Fujitsu Ltd | マルチプロセッサシステムの制御方法及び装置 |
| JPH0926889A (ja) * | 1995-07-13 | 1997-01-28 | Hitachi Ltd | 仮想計算機システム |
| JPH0981401A (ja) * | 1995-09-19 | 1997-03-28 | Hitachi Ltd | 大域的なリソースキャッピング方法 |
| JP2000132530A (ja) * | 1997-11-04 | 2000-05-12 | Digital Equip Corp <Dec> | マルチプロセッサコンピュ―タシステム及びその動作方法 |
| JPH11328135A (ja) * | 1998-02-06 | 1999-11-30 | Ncr Internatl Inc | 並列処理コンピュ―タ・システム |
Non-Patent Citations (2)
| Title |
|---|
| 堀本徹、山本政行: "デジタル・エコノミーを支えるストレージ管理：ＳＡＮ (Storage Area Network)", OPEN MIDDLEWARE REPORT, vol. 第12巻, JPN6010038773, 1 April 2000 (2000-04-01), pages 18 - 19, ISSN: 0001671729 * |
| 稲津利司基: "サーバー機を論理的に分割するパーティショニング技術「Galaxy」", 日経コンピュータ, vol. 第467号, JPN6010038772, 12 April 1999 (1999-04-12), JP, pages 156 - 162, ISSN: 0001671728 * |
Cited By (46)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005056408A (ja) * | 2003-07-23 | 2005-03-03 | Semiconductor Energy Lab Co Ltd | マイクロプロセッサ及びグリッドコンピューティングシステム |
| US8352724B2 (en) | 2003-07-23 | 2013-01-08 | Semiconductor Energy Laboratory Co., Ltd. | Microprocessor and grid computing system |
| US7703029B2 (en) | 2003-07-28 | 2010-04-20 | Sap Ag | Grid browser component |
| US7673054B2 (en) | 2003-07-28 | 2010-03-02 | Sap Ag. | Grid manageable application process management scheme |
| US8135841B2 (en) | 2003-07-28 | 2012-03-13 | Sap Ag | Method and system for maintaining a grid computing environment having hierarchical relations |
| JP2007500386A (ja) * | 2003-07-28 | 2007-01-11 | エスアーペー アーゲー | グリッド組織 |
| JP2007500888A (ja) * | 2003-07-28 | 2007-01-18 | エスアーペー アーゲー | グリッド管理可能なアプリケーションプロセス管理方式 |
| US7810090B2 (en) | 2003-12-17 | 2010-10-05 | Sap Ag | Grid compute node software application deployment |
| JP4806357B2 (ja) * | 2004-01-27 | 2011-11-02 | インターナショナル・ビジネス・マシーンズ・コーポレーション | プロビジョニングデータ処理システムにおいてリソースを識別、予約、および論理的にプロビジョニングする方法、システム、およびプログラム |
| JP2007520814A (ja) * | 2004-01-27 | 2007-07-26 | インターナショナル・ビジネス・マシーンズ・コーポレーション | プロビジョニングデータ処理システムにおいてリソースを識別、予約、および論理的にプロビジョニングする方法、システム、およびプログラム |
| JP2007526557A (ja) * | 2004-01-30 | 2007-09-13 | インターナショナル・ビジネス・マシーンズ・コーポレーション | コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理 |
| JP4867660B2 (ja) * | 2004-01-30 | 2012-02-01 | インターナショナル・ビジネス・マシーンズ・コーポレーション | コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理 |
| WO2006040811A1 (ja) * | 2004-10-12 | 2006-04-20 | Fujitsu Limited | リソース交換処理プログラムおよびリソース交換処理方法 |
| US8224941B2 (en) | 2004-10-18 | 2012-07-17 | Fujitsu Limited | Method, apparatus, and computer product for managing operation |
| US7971089B2 (en) | 2004-10-18 | 2011-06-28 | Fujitsu Limited | Switching connection of a boot disk to a substitute server and moving the failed server to a server domain pool |
| WO2006043307A1 (ja) * | 2004-10-18 | 2006-04-27 | Fujitsu Limited | 運用管理プログラム、運用管理方法および運用管理装置 |
| JPWO2006043309A1 (ja) * | 2004-10-18 | 2008-05-22 | 富士通株式会社 | 運用管理プログラム、運用管理方法および運用管理装置 |
| JPWO2006043307A1 (ja) * | 2004-10-18 | 2008-05-22 | 富士通株式会社 | 運用管理プログラム、運用管理方法および運用管理装置 |
| WO2006043309A1 (ja) * | 2004-10-18 | 2006-04-27 | Fujitsu Limited | 運用管理プログラム、運用管理方法および運用管理装置 |
| US8387013B2 (en) | 2004-10-18 | 2013-02-26 | Fujitsu Limited | Method, apparatus, and computer product for managing operation |
| JP4734258B2 (ja) * | 2004-10-18 | 2011-07-27 | 富士通株式会社 | 運用管理プログラム、運用管理方法および運用管理装置 |
| JP4734259B2 (ja) * | 2004-10-18 | 2011-07-27 | 富士通株式会社 | 運用管理プログラム、運用管理方法および運用管理装置 |
| WO2006043308A1 (ja) * | 2004-10-18 | 2006-04-27 | Fujitsu Limited | 運用管理プログラム、運用管理方法および運用管理装置 |
| US7793290B2 (en) | 2004-12-20 | 2010-09-07 | Sap Ag | Grip application acceleration by executing grid application based on application usage history prior to user request for application execution |
| JP2008527521A (ja) * | 2005-01-12 | 2008-07-24 | インターナショナル・ビジネス・マシーンズ・コーポレーション | グリッド・ジョブに関するグリッド・プロバイダの選択を自動的に制御するための方法、システム、およびコンピュータ・プログラム |
| US8688484B2 (en) | 2005-03-18 | 2014-04-01 | Hitachi, Ltd. | Method and system for managing computer resource in system |
| JP4616674B2 (ja) * | 2005-03-18 | 2011-01-19 | 株式会社日立製作所 | リソース貸借方法、および、リソース貸借システム |
| JP2006260433A (ja) * | 2005-03-18 | 2006-09-28 | Hitachi Ltd | リソース貸借方法、および、リソース貸借システム |
| JP2009500717A (ja) * | 2005-06-30 | 2009-01-08 | マイクロソフト コーポレーション | サーバファームにおけるソリューションの配備 |
| US8176408B2 (en) | 2005-09-12 | 2012-05-08 | Microsoft Corporation | Modularized web provisioning |
| US8015275B2 (en) | 2005-12-28 | 2011-09-06 | Fujitsu Limited | Computer product, method, and apparatus for managing operations of servers |
| WO2007077600A1 (ja) * | 2005-12-28 | 2007-07-12 | Fujitsu Limited | 運用管理プログラム、運用管理方法および運用管理装置 |
| WO2008004275A1 (fr) * | 2006-07-04 | 2008-01-10 | Fujitsu Limited | Programme, procédé et dispositif de reprise sur sinistre |
| JP4885871B2 (ja) * | 2007-02-02 | 2012-02-29 | 株式会社ソニー・コンピュータエンタテインメント | 仲介サーバ、端末、及び分散処理方法 |
| JPWO2008096390A1 (ja) * | 2007-02-02 | 2010-05-20 | 株式会社ソニー・コンピュータエンタテインメント | 仲介サーバ、端末、及び分散処理方法 |
| JP2010250778A (ja) * | 2009-04-20 | 2010-11-04 | Ntt Data Corp | コンピュータリソース提供システム、コンピュータリソース提供方法およびリソース取引プログラム |
| JP2010282667A (ja) * | 2010-09-24 | 2010-12-16 | Hitachi Ltd | リソース貸借方法、および、リソース貸借システム |
| JP2011060317A (ja) * | 2010-11-15 | 2011-03-24 | Fujitsu Ltd | 運用管理プログラム、運用管理方法および運用管理装置 |
| JP2012043445A (ja) * | 2011-09-16 | 2012-03-01 | Hitachi Ltd | 業務引き継ぎ方法、計算機システム、及び管理サーバ |
| JP2013161252A (ja) * | 2012-02-03 | 2013-08-19 | Fujitsu Ltd | 冗長コンピュータ制御プログラム、方法、及び装置 |
| KR20140122240A (ko) * | 2012-02-03 | 2014-10-17 | 마이크로소프트 코포레이션 | 확장 가능한 환경에서의 파티션 관리 기법 |
| KR102013005B1 (ko) | 2012-02-03 | 2019-08-21 | 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 | 확장 가능한 환경에서의 파티션 관리 기법 |
| US10635500B2 (en) | 2012-02-03 | 2020-04-28 | Microsoft Technology Licensing, Llc | Decoupling partitioning for scalability |
| US10860384B2 (en) | 2012-02-03 | 2020-12-08 | Microsoft Technology Licensing, Llc | Managing partitions in a scalable environment |
| CN112988532A (zh) * | 2021-01-27 | 2021-06-18 | 腾讯科技（深圳）有限公司 | 埋点事件的上报方法、装置、服务器及存储介质 |
| CN112988532B (zh) * | 2021-01-27 | 2022-07-29 | 腾讯科技（深圳）有限公司 | 埋点事件的上报方法、装置、服务器及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4712279B2 (ja) | 2011-06-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1323037B1 (en) | Method and apparatus for controlling an extensible computing system | |
| JP4712279B2 (ja) | 拡張可能コンピューティングシステムの制御方法および装置 | |
| JP3948957B2 (ja) | 拡張可能なコンピューティング・システム | |
| US7146233B2 (en) | Request queue management | |
| US11500670B2 (en) | Computing service with configurable virtualization control levels and accelerated launches | |
| US10142226B1 (en) | Direct network connectivity with scalable forwarding and routing fleets | |
| US11218364B2 (en) | Network-accessible computing service for micro virtual machines | |
| US9712386B1 (en) | Grouping routing resources for isolated virtual network traffic management | |
| US8874749B1 (en) | Network fragmentation and virtual machine migration in a scalable cloud computing environment | |
| US9692729B1 (en) | Graceful migration of isolated virtual network traffic | |
| Kallahalla et al. | SoftUDC: A software-based data center for utility computing | |
| US8307362B1 (en) | Resource allocation in a virtualized environment | |
| US7213065B2 (en) | System and method for dynamic server allocation and provisioning | |
| US7463648B1 (en) | Approach for allocating resources to an apparatus based on optional resource requirements | |
| US7703102B1 (en) | Approach for allocating resources to an apparatus based on preemptable resource requirements | |
| US8234650B1 (en) | Approach for allocating resources to an apparatus | |
| US8032634B1 (en) | Approach for allocating resources to an apparatus based on resource requirements | |
| US8179809B1 (en) | Approach for allocating resources to an apparatus based on suspendable resource requirements | |
| US11669360B2 (en) | Seamless virtual standard switch to virtual distributed switch migration for hyper-converged infrastructure | |
| Tate et al. | IBM SAN and SVC Stretched Cluster and VMware Solution Implementation | |
| CN114785762A (zh) | 云计算系统的实现方法、装置、终端设备以及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080612 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100713 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101007 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20101102 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101108 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20101130 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110204 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110301 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110323 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4712279 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |