(57)【特許請求の範囲】
【請求項１】
一組のコンピュータを有するネットワークにおいてコンピュータ・プログラムをインストールする方法であって、前記一組のコンピュータは、オペレーティング・ソフトウェアおよびインストール・ソフトウェアを有する第１のインストール・コンピュータと、前記ネットワークを介してのインストール要求のブロードキャストを動的に調整することが可能な少なくとも１つのクライアント・コンピュータとを有し、前記動的に調整することは、クライアント・コンピュータが、インストール要求を初期要求割合で最初にブロードキャストすること、前記ネットワーク上の前記インストール要求の合計ブロードキャスト割合をモニタすること、及び前記合計ブロードキャスト割合と目標インストール要求割合とを比較して、前記合計ブロードキャスト割合と前記目標インストール要求割合との差によって決まる調整量だけクライアント・コンピュータ自身の前記要求割合を調整することを含み、
前記方法は、
前記第１のインストール・コンピュータは前記クライアント・コンピュータからの第１のインストール要求に応答し、そして該第１のインストール要求を発したクライアント・コンピュータ（以下、第１のクライアント・コンピュータという）に前記オペレーティング・ソフトウェアおよびインストール・ソフトウェアの双方をインストールし、それによって前記第１のクライアント・コンピュータが他のクライアント・コンピュータからのインストール要求に応答できるようになり（以下、当該第１のクライアント・コンピュータを第２のインストール・コンピュータという）、該インストール操作の間、前記第１のインストール・コンピュータは前記第１のクライアント・コンピュータ以外の他のクライアント・コンピュータからのインストール要求を無視し、
前記第１のインストールが完了したら、前記第１のインストール・コンピュータおよび前記第２のインストール・コンピュータそれぞれが、引き続き前記オペレーティング・ソフトウェアおよびインストール・ソフトウェアの双方を、インストール要求を発したクライアント・コンピュータに先着順でインストールすることによってインストール要求をサービスする、
前記方法。
【請求項２】
前記調整量が前記合計ブロードキャスト割合と前記目標インストール要求割合との前記差に線形に比例している、請求項１に記載の方法。
【請求項３】
前記目標インストール要求割合が合計ネットワーク帯域幅割合に比例している、請求項１に記載の方法。
【請求項４】
一組のコンピュータを有するネットワークにおいてコンピュータ・プログラムをインストールするコンピュータ・システムであって、前記一組のコンピュータは、オペレーティング・ソフトウェアおよびインストール・ソフトウェアを有する第１のインストール・コンピュータと、前記ネットワークを介してのインストール要求のブロードキャストを動的に調整することが可能な少なくとも１つのクライアント・コンピュータとを有し、前記動的に調整することは、クライアント・コンピュータが、インストール要求を初期要求割合で最初にブロードキャストすること、前記ネットワーク上の前記インストール要求の合計ブロードキャスト割合をモニタすること、及び前記合計ブロードキャスト割合と目標インストール要求割合とを比較して、前記合計ブロードキャスト割合と前記目標インストール要求割合との差によって決まる調整量だけクライアント・コンピュータ自身の前記要求割合を調整することを含み、
前記第１のインストール・コンピュータは前記クライアント・コンピュータからの第１のインストール要求に応答し、そして該第１のインストール要求を発したクライアント・コンピュータ（以下、第１のクライアント・コンピュータという）に前記オペレーティング・ソフトウェアおよびインストール・ソフトウェアの双方をインストールし、それによって前記第１のクライアント・コンピュータが他のクライアント・コンピュータからのインストール要求に応答できるようになり（以下、当該第１のクライアント・コンピュータを第２のインストール・コンピュータという）、該インストール操作の間、前記第１のインストール・コンピュータは前記第１のクライアント・コンピュータ以外の他のクライアント・コンピュータからのインストール要求を無視し、
前記第１のインストールが完了したら、前記第１のインストール・コンピュータおよび前記第２のインストール・コンピュータそれぞれが、引き続き前記オペレーティング・ソフトウェアおよびインストール・ソフトウェアの双方を、インストール要求を発したクライアント・コンピュータに先着順でインストールすることによってインストール要求をサービスする、
コンピュータ・システム。
【請求項５】
前記調整量が前記合計ブロードキャスト割合と前記目標インストール要求割合との前記差に線形に比例している、請求項４に記載のコンピュータ・システム。
【請求項６】
前記目標インストール要求割合が合計ネットワーク帯域幅割合に比例している、請求項４に記載のコンピュータ・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＣＰＵ群から成るクラスタ群を有するコンピューティング・システムにおいてオペレーティング・システムをインストールする方法に関する。
【背景技術】
【０００２】
安価なコンピューティングを実現するクラスタ化の価値は、ウェブを提供する高性能コンピューティングなどの分野で広く知られている。しかし、クラスタの大きさは一般に約５１２ノードにとどまっている。それは主に、オペレーティング・システムの１つの版で大きなクラスタの初期セットアップをいかにして行うかという問題に起因している。現在、クラスタ群は、１つのクラスタをインストールするために単一サーバ手法または階層型サーバ手法を用いている。
単一サーバ手法では、インストール・サーバであるべき、インテリジェンスとソフトウェア（すなわち通常のＣＰＵ〔つまりシステム中のノード〕に共通のオペレーティング・システムのほかにインストールのために必要な余分なソフトウェア）をすべて有する単一のワークステーションからインストールされる。階層型手法では、第１のサーバが第２のインストール・サーバ群に対してインストールを行うから、オペレーティング・システムの伝搬が緊密に制御された「波」の形で生じる。すなわち、第１のサーバが第２のインストール・サーバ群に対してインストールを行い、これら第２のサーバ群が残りのクライアントに対してインストールを行う。これらの２つの方法には、「ブロードキャスト嵐（broadcast storm)」と呼ばれる現象が生じるという問題がある。ブロードキャスト嵐は、多数のノードが同時にパワーアップされ、それらのノード群が同時にネットワーク・パケットを規則正しく短い間隔でブロードキャストする結果生じるものであり、ネットワークを飽和させ最終的にはネットワーク上の通信をすべて不通にさせる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明が解決しようとする課題は、「嵐（storm)」を生じさせることなく時宜にかなった形態でクラスタのノード群全体にインストールを実行することである。
【課題を解決するための手段】
【０００４】
本発明は、割合制限的な特徴を有するプログラムをインストールする方法に関する。インストール・サーバはクライアントからのインストール要求に確率基準で応答する。これにより、ネットワークの帯域幅に過負荷がかかる機会を減少させる。
【０００５】
本発明の特徴はクライアントからの動的インストール要求割合であり、それは他の（すべての）クライアントによる要求の（合計）割合に基づく。
【０００６】
本発明の別の特徴はクライアントへのソフトウェアのインストールであり、それは当該クライアントが別のクライアントにプログラムをインストールするのを可能にするのに十分なものである。したがって、インストールを要求しているクライアントは少なくとも一時的にインストール・サーバになり、クライアントが出すインストール要求に確率基準に応答する。しかし、その応答割合は最初にインストールしたサーバより少ない。
【０００７】
本発明の別の特徴はクライアントによる自己調整要求割合であり、それは他のクライアントによる要求数に基づく。
【０００８】
本発明の別の特徴はインストール要求を出すクライアント用に限定されたアドレス範囲を各インストール・サーバが割り当てることである。新たに生成されたサーバはこの限定されたアドレス範囲内で応答することができる。
【発明を実施するための最良の形態】
【０００９】
図１を参照する。図１は本発明に係るコンピュータ・クラスタ１００の一部の概略を示す図である。ボックス１１０はＣＰＵ、ディスク駆動装置、メモリ、およびＣＰＵに物理的に近接して設けられた他の周辺機器を有するコンピュータを模式的に表している。ボックス１０５は、別のコンピュータに問題となるソフトウェアをインストールするために必要なソフトウェアを、それに付随するハードウェアおよびＬｉｎｕｘオペレーティング・システムの全イメージなどのファームウェア、ならびに新たなクライアント・ノードに接触してインストールを実行する本発明に係るインストール・プログラムと一緒にインストールするためのインストール・モジュールを表している。
【００１０】
線２０はクラスタ内のノード（すなわちＣＰＵ）間の通信リンクを表わしている。このリンクは無線、既存のバス、これら２つの組み合わせなどである。線２２−ｉはクラスタ内の他のノードへのリンクを表わしている。コンピュータのネットワークは、伝送されるデータの合計ネットワーク帯域幅、及びネットワークによって伝送されうる、単位時間当たりのインストール要求数である合計ネットワーク帯域幅割合を有しうる。
【００１１】
本発明が解決しようとする課題は、「嵐（storm）」を生じさせることなく時宜にかなった形態でクラスタのノード群全体にインストールを実行することである。嵐とは、通信リンクを覆うトランザクションが同時に多数発生し、ノードをまたぐ通信システムの能力に過負荷が課される状態のことである。現代のコンピューティング技術では数万のノードから成るアーキテクチャが企図されているが、現在は数万のノードから成るクラスタにソフトウェアをインストールしアップグレードすることは実際的でない。
【００１２】
本発明に係る「自己複製インストール法（Self-Replicating Installation Method: ＳＲＩＭ）」では、ノードを管理しておき選択したノード集合だけをインストール・サーバにするのではなく、すべてのノードをインストール・サーバにする。ＳＲＩＭを用いると、インストールは制御されず非決定的形態でクラスタ全体に広がり、それはクラスタ中のすべてのノードがインストールされるまで続く。
【００１３】
（ノード数が５１２超の）大きなクラスタではノード群をパワーオンし、それらにインストール要求をブロードキャストさせるだけですぐにブロードキャスト嵐を引き起こすから、ＳＲＩＭでは「クライアント・ブロードキャスト規制方法（Client Broadcast Regulation Method: ＣＢＲＭ）」を採用してクライアント・ノードからのインストール要求を制限し、ノードがブロードキャストしてサーバを探索する頻度を低減させてインストール要求間の間隔がどんどん延びるようにしている。同様に、多数のサーバにクライアントからのインストール要求に応答させると、類似の「応答嵐（response storm）」を引き起こす可能性がある。これを避けるために、ＳＲＩＭでは「サーバ応答規制方法（Server Response Regulation Method:ＳＲＲＭ）」を採用してサーバの応答数を低減している。
【００１４】
〔自己複製インストール法（ＳＲＩＭ）〕
ＳＲＩＭは第１のインストール・サーバである単一のノード１１０から開始する。ノード１１０には、オペレーティング・システムと、クライアント・ノードに対してインストール・サーバ自体としてのインストールを実行するために必要なすべてのソフトウェアとのコピー（図１でボックス１０５、１０５−ｉで表記されている）がインストールされている。オペレーティング・システムに特有の事項ではないが、Ｌｉｎｕｘの場合、第１のサーバにはＬｉｎｕｘの完全な版、および別のノードに対してインストールを実行するのに必要なすべてのＲＰＭ（インストール・パッケージ）、さらに実行するために必要なすべてのインストール・サービスを持たせる。様々なオペレーティング・システムによってインストールするために必要なソフトウェアは、コンピューティング産業においてよく知られている。サーバ１１０はメーカーが推奨する既存の任意の方法でインストールすることができる。
【００１５】
第１のサーバがインストール済みでありクライアントに対してインストールを開始しうる状態にある場合、クライアントの経験的に決められた部分がパワーアップし（後述する）ＣＢＲＭを用いてブロードキャストを開始する。好適な実施形態では、すべてのクライアントがパワーアップしブロードキャスト・プロセスを開始する。サーバはよく知られたプロトコルたとえばＤＨＣＰを備えている。ＤＨＣＰはコンピューティング・ノードの初期ブートの間にサーバとコンピューティング・ノードとの間で通信するのに使われるプロトコルである。ＤＨＣＰはサーバがノードにネットワーキング情報とスタートアップ情報、たとえばそのＩＰアドレスとゲートウェイを供給する際に依拠するプロトコルを規定するとともに、ノードに初期ブリングアップ・カーネルを供給する。
【００１６】
サーバは第１のインストール要求を受信すると、応答（answer）で応答（respond）する。この結果、自身を１つのクライアントに添付（attach）する。また、別のサーバが出す応答があっても、上記クライアントはそれを無視する。いったん添付したら、サーバはそのＤＨＣＰサービスをシャットダウンし、別のインストール要求を無視し、上記クライアントに対するインストールを開始する。そのＤＨＣＰをシャットダウンすることにより、サーバは別のＤＨＣＰ応答を排除する。これにより、ネットワーク通信量が低減する。次いで、サーバは上記クライアントにオペレーティング・システムの完全な版、および（ボックス１０５に格納されており）上記クライアントが自身を複製する際に必要になるサービスやインストール可能なイメージをすべてインストールする。上記クライアントはインストールが完了したら、自身を再ブートして自分自身（すなわち同位のサーバ）になる。「クライアント」および「インストール・サーバ」なる用語は時の経過とともに変化する。たとえば、クライアントは未インストールまたは未アップグレードのノードであるが、いったんアップグレードするとサーバになる。以上説明した事項は本発明に従って採用したピア・ツー・ピア手法を反映したものである。サーバはクライアントに対するインストールを完了すると、そのＤＨＣＰサービスを無視し、別のクライアントに対してサービスしうる状態、すなわち、インストール要求を受信しインストールを実行しうる状態になる。
【００１７】
サーバによるインストール応答は「確率的」である。すなわち、サーバは自分が聞いたインストール要求に確率に従って応答したりしなかったりする。たとえば、１〜１００のランダム数を算出し、問題の応答（すなわち当該ランダム数）が基準確率（たとえば２５％）によって設定された範囲（この場合０〜２５）の内または外のどちらに存在するかに従って応答したりしなかったりする。
【００１８】
基本インストール・フローを、図２を参照して以下にまとめる。
（１）  ＣＤ（またはディスケット、インターネット、またはＯＳをインストールするよく知られた任意の方法）によって主（第１の）ノードにオペレーティング・システム・イメージ、ソフトウェア・パッケージ、および自身を複製するのに必要なすべてのサービスをインストールする。
（２）主サーバ上で必要なサービスを開始する。
（３）クライアントをパワーアップする（一度にすべてのクライアントをパワーアップするのが望ましい）。
（４）クライアントはパワーアップしたら、ブロードキャストしてサーバの探索を開始する。
このプロセスにはＣＢＲＭを用いる。
（５）サーバはクライアントに応答し、自身を当該クライアント添付し、自身のＤＨＣＰサービスをシャットダウンする。
（６）サーバは、１つのノードにオペレーティング・システム・イメージ、インストール可能なイメージ、および必要なすべてのサービスをインストールする。
（７）新サーバは自身を同位のサーバとして再ブートし、旧サーバはＤＨＣＰを再開始して新たなクライアントに再添付する。
（８）新サーバは再ブートを完了したら、ブロードキャストしてクライアントの探索を開始する。
（９）新サーバはブロードキャストして添付すべきクライアントを探索する。これはクラスタ内のすべてのノードがインストールされるまで続ける。
【００１９】
現在の実務では、ノードはパワーオンするといわゆる「ダム（dumb）ブロードキャスト」を開始する。すなわち、ノードは一定の短い間隔でブロードキャストしてサーバを探索する。一度に多数のクライアントがパワーオンすると、すべてのクライアントがダム・ブロードキャスト・メソッドを呼び出すから、ネットワークを飽和させ通常すべてのネットワーク通信を不可能にするブロードキャスト嵐が始まる。一部のマシンのＢＩＯＳには、クライアントが少ない個数のブロードキャストののち（すなわち約６０秒のち）にそのブロードキャストに対するＤＨＣＰ応答を受信しない場合には、ノードを再ブートするように命令が組み込まれている。
【００２０】
ＣＢＲＭは、クライアントは適切なサーバを見いだすまでに多くの時間（またはきわめて大きなクラスタでは数日間）ブロードキャストし続けるものと仮定することにより、クライアントが賢明にブロードキャストを行いうるようにするものである。ＣＢＲＭによれば、ネットワーク通信量およびブロードキャスト嵐の可能性を大幅に低減することが可能になる。
【００２１】
〔クライアント・ブロードキャスト規制方法（ＣＢＲＭ）〕
ＣＢＲＭは動的であり、ネットワーク状態に対する感受性を基にして嵐の発生を抑止するものである。ノード上でＣＢＲＭを開始すると、ブロードキャストはゆるやかな割合（たとえば１分間当り６回）で行われるようになる。ブロードキャストしながら、ノードはネットワーク上で発生するブロードキャストの総数をモニタし、ネットワーク上のインストール要求の合計ブロードキャスト割合を求める。次いで、この合計ブロードキャスト割合と格納してある目標インストール要求割合とを比較する。上記合計ブロードキャスト割合が目標インストール要求割合よりも小さい場合、ノード自身のブロードキャスト割合を目標インストール要求割合と合計ブロードキャスト割合との差に比例する量だけ増加させる。逆に、合計ブロードキャスト割合が目標インストール要求割合よりも大きい場合、ノード自身のブロードキャスト割合を目標インストール要求割合と合計ブロードキャスト割合との差に比例する量だけ減少させる。こうして、各ノードのブロードキャスト割合は目標インストール要求割合に近い合計ブロードキャスト割合を維持しうる値に収束するようになる。あるクライアントのブロードキャスト総数と別のクライアントのブロードキャスト総数は単純に関連し、個々の応答割合を調整するという観点からは等価である。
【００２２】
合計ブロードキャスト割合は変動する傾向があり時として大きく変動するから、目標インストール要求割合は大きなゆらぎを許容する裕度を有するように選定する必要がある。また、目標インストール要求割合は総ネットワーク帯域幅の小さな部分（おそらく１％）に設定する。ＤＨＣＰブロードキャストはきわめて小さいから、きわめて大きな個数のブロードキャストが可能になるとともに、起こりうる割合スパイクを許容する余地がある。特定のネットワークの場合の経験によれば、合計ブロードキャスト割合はシステム管理者によって調整することができる。
【００２３】
留意点を挙げると、クライアントが迅速にブロードキャストできるようにして、サーバを数秒間早く見い出しうるようにすることは重要ではない。本発明の目的はブロードキャスト嵐を避けることである。ブロードキャスト嵐を引き起こす急速で非管理のブロードキャストこそ問題である。ブロードキャストの間隔を制御することにより、ＣＢＲＭは偽ネットワーク通信量の問題を軽減するものである。
【００２４】
再度、図２を参照してフローチャートを敷衍（ふえん）する。
【００２５】
まず、（集合全体であると想定する）クライアント群（６台）に含まれる、クライアントのそれぞれが、６回／分でブロードキャストを開始する。
【００２６】
各クライアントはネットワークからインストール要求の実際の合計ブロードキャスト割合を読み取り、それを目標インストール要求割合と比較する（目標インストール要求割合はネットワークのセットアップ中またはブロードキャスト・メッセージによって取得する）。
【００２７】
各クライアントは上記合計ブロードキャスト割合と目標インストール要求割合とを比較する。この例では、目標インストール要求割合を６０回／分、全てのクライアント（６台）に起因する現在の合計ブロードキャスト割合を３６回／分と想定する。
【００２８】
現在の合計ブロードキャスト割合３６回／分が目標インストール要求割合６０回／分よりも小さい。従って、クライアントの合計ブロードキャスト割合３６回／分を、目標インストール要求割合６０回／分に近い値に収束するようにさせる。そのために、上記目標インストール要求割合６０回／分と上記現在の合計ブロードキャスト割合３６回／分との差の比例分、たとえば上記差（６０回／分−３６回／分＝２４回分／分）の半分（２４回分÷２＝１２回／分）だけクライアントの合計ブロードキャスト割合が増加するように各クライアントのブロードキャスト割合を調整する。この例の場合、上記差の半分は上記１２回／分であるから、各クライアントのブロードキャスト割合を２回／分（１２回／分÷６台＝２回／分）だけ増加させて８回／分（６回／分＋２回／分＝８回／分）にする。残りのクライアント（５台分）のブロードキャスト割合もそれぞれ２回分増加させる。
【００２９】
応答しているサーバはないから、クライアントはこのブロードキャスト割合でブロードキャストを続け、所定期間後に合計ブロードキャスト割合を再評価する。この所定期間を決めるにはいくつかの方法がある。たとえば、ｘ秒±ｙ（ただしｙはｘの１０％の範囲のランダム数）のように決める。これにより、同時に、増加または減少させるクライアントからのスパイクを低減させることができる。
【００３０】
今度は、クライアントのブロードキャスト割合を増加させた結果、現在の合計ブロードキャスト割合が目標インストール要求割合よりも増加したと想定する。現在の合計ブロードキャスト割合が目標インストール要求割合よりも大きい。従って、クライアントの合計ブロードキャスト割合を、目標インストール要求割合に近い値に収束するようにさせるために、クライアントの合計ブロードキャスト割合を減少させる。すなわち、上記現在の合計ブロードキャスト割合と上記目標インストール要求割合との差の比例分、例えば上記差の半分だけクライアントの合計ブロードキャスト割合が減少するように各クライアントのブロードキャスト割合を調整する。
【００３１】
このプロセスはクライアントがサーバに応答されるまで続ける。
【００３２】
〔サーバ応答規制方法（ＳＲＲＭ）およびＩＰアドレス割り当て〕
プロセスがいったん大きなクラスタと折り合いを付けると、応答しうるサーバの数が多くなる。したがって、「応答嵐（response storm）」を避ける方法を有するのが有利になる。応答嵐とは個々のインストール要求に応答するサーバの数が多すぎる状態のことである。この応答嵐が発生するのを避けるために、サーバ応答規制方法（Server Response Regulation Method:ＳＲＲＭ）を採用する。ＳＲＲＭを用いると、任意のインストール要求に応答しうるマシンの平均個数は常にほぼ１になる。
【００３３】
クラスタはグローバルに一定に保たれている２つのリソースを有しているものと見ることができる。これら２つのリソースの一方は（１００％から始まる）応答確率であり、他方はネットワーク内のＩＰアドレス（ＴＣＰの慣例によるとたとえば１０．０．０．０．８）である。サーバはクライアントに対してインストールを行うときには常に、自身が保有するこれら２つのリソースを自身と当該クライアントとの間で平等に分割する。
【００３４】
図３を参照して一例を説明する。
【００３５】
最初のインストール期間中、第１のサーバはクライアントのインストール要求に対してたとえば２５％の確率で応答する。応答するか否かはランダム数発生器の結果に基づいて決める。
【００３６】
サーバは（最終的には）インストールすべきクライアントのインストール要求を受け入れる。サーバは（ＴＣＰの場合）よく知られたＩＰ範囲１０．６４．０．０〜１０．１２７．２５５．２５５のＩＰアドレスを保有している。サーバは（当該サーバのＩＰ範囲の１／２に当たる）１０．９６．０．１なるＩＰアドレスをクライアントに割り当てる。次いで、クライアントにオペレーティング・システムをインストールする。
【００３７】
クライアントはサーバとのコネクションを切断するまえに、自身がインストールすることになる新クライアントに割り当てるべきＩＰアドレスのブロックを要求する。サーバは自身のＩＰアドレス・ブロックの１／２に当たる範囲のＩＰアドレスをクライアントに与える。このようにＩＰアドレスを動的に割り当てることは好都合である。すなわち、ＩＰアドレスを管理していないから、ボトルネックが形成されない。アドレス範囲の半分を利用可能なアドレス・ブロックにする実際的な利点は、ＩＰアドレスの割り当てを動的かつ非管理に行える点である。このアルゴリズムの場合、ＩＰアドレスの完全なブロックは稀にしか使用されない。これはクラスタに悪影響を与えない。なぜなら、ＩＰアドレスのこのブロックはクラスタの外部には反映されないので、すべてのクラスタは同一のＩＰアドレスを使用しうるからである。
【００３８】
アドレスのブロックを受け取ったのちノードがインストールに失敗しても、それはクラスタの残りのノードのインストール動作に影響しない。失敗したノードはＩＰアドレスの一部を保持することになるが、それは問題ではない。可能なＩＰアドレスの個数は考えうるクラスタの個数よりも大きいから、実際にはＩＰアドレスが不足することはない。
【００３９】
クライアントは応答パーセンテージ（百分率）を要求する。サーバはその応答パーセンテージの１／２を譲渡する。いま、クライアントとサーバの双方がクライアントのインストール要求に対して同一の機会（１２．５％）を有し、サーバが自分と同一個数のＩＰアドレスをクライアントに譲渡するものと想定する。２５％という初期値と譲渡の際に生じる端数はシステム管理者が調整することができる。
【００４０】
次いで、プロセスは始めから繰り返す。
【００４１】
インストール・プロセスが終了するのは、システム管理者が定めた期間内にネットワークにインストール要求が発生しないときである。
【００４２】
以上説明した方法を用いると、インストールの仕事はクラスタ中に平等に分散される傾向がある。サーバがクライアントのインストール要求に応答する機会は確率的であるから、特定のインストール要求に複数のサーバが応答しうる。しかし、平均的な場合には、応答しうるサーバはほぼ１つである。クラスタが大きくなるのにつれて、サーバ群が応答する確率は指数関数的に小さくなる。この結果、応答嵐の可能性を回避することができるようになる。
【００４３】
本発明に係る方法（ＳＲＩＭとＣＢＲＭ）は多くの態様で実現することができる。１つの方法は各ノードで、あるいは各ノードのネットワーク通信カードでＣＢＲＭをサポートする専用のＢＩＯＳ（ファームウェア）を用いるものである。これにはインストールするオペレーティング・システムを変更する必要がないという利点がある。別の方法はインストール後の最初の再ブート時に呼び出し、インストール・プロセスが終了したら自動消滅する、インストール・パッケージの一部をなすプログラムを用いるものである。しかしながら、当業者は別の方法を容易に案出することができる。いずれにせよ、駆動プログラムによって、ブロードキャスト間の遅延時間（すなわちブロードキャスト間隔）の間にネットワーク通信カードがＣＢＲＭ法に従うようにさせることができる。別の実装として、ネットワーク・カード自体にＣＢＲＭソフトウェアを直接に搭載する方法が考えられる。この場合、ノードＢＩＯＳがネットワーク・インタフェース・カード用のデバイス・ドライバを始動し、同カードがＣＢＲＭ自体を実行することになる。そして、ＣＢＲＭがノードＢＩＯＳおよびネットワーク・インタフェース・カードＢＩＯＳのどちらに実装されているのかが、インストール・サーバに分かっている必要がある。
【００４４】
本発明は広い範囲のクラスタ・サイズに適用することを意図しているから、当業者が予期しうるように、インストール割合が一部の構成では一部の従来技術の方法よりも多いが、一部の特定の場合には一部の従来技術の方法の方がインストール割合が多い。本発明の狙いは特定の構成ではなく、柔軟性にある。柔軟性は特にクラスタの大きさが以前には非実際的であったほどに大きい場合、特定の構成に特化した方法より有益であると考えられる。伝統的なボトルネックは伝統的なブロードキャスト法ではなくＣＢＲＭを採用することにより除去することができる。また、従来の方法には任意的な制限があった。たとえば、１つのノードは他の１６個のノードに対してインストールすると、それで終了であった。
【００４５】
当業者が認識しうるように、本発明の範囲内で多くの変形を実行できる。たとえば、アドレス範囲を動的にし、インストール割合を少なくして潜在的なクライアントの数を増加させることができる。同様に、応答パーセンテージの数値を動的にすることができる。サーバはそのアドレス範囲を１／２ではなく１／４あるいは他の分数分だけ譲渡することができる。ネットワーク通信量の判断基準を単位時間当りのインストール要求個数ではなく（能力と比較した）単位時間当りのパケット数またはバイト数にすることができる。これにより、より大きな（より小さな）オペレーティング・システムおよびより早い（より遅い）ネットワークを用いることが可能になる。本発明に係る方法はオペレーティング・システム（たとえばＬｉｎｕｘ）の初期インストールに限定されない。本発明に係る方法は（適切なインストール・プログラムを付随させることにより）アプリケーション・プログラムに適用することができるし、アップグレードにも適用することができる。「オペレーティング・ソフトウェア」なる用語は問題となる機能を実行するソフトウェアを意味し、たとえばコンピュータの操作又は天気予報プログラムにおける計算を実行するソフトウェアを意味する。
【００４６】
以上、本発明を１つの好適な実施形態の観点から説明したが、当業者が理解しうるように、本発明は特許請求の範囲の本旨と範囲内で様々な態様で実施されうる。
【図面の簡単な説明】
【００４７】
【図１】本発明で用いるコンピュータ・クラスタの概略を示す図である。
【図２】本発明に係る手順を示す図である。
【図３】図２の手順の一部を示す図である。
【符号の説明】
【００４８】
２０  線
２２  線
１０５  インストール・モジュール
１１０  コンピュータ
【図１】
0004478417.tif 000002
【図２】
0004478417.tif 000003
【図３】
0004478417.tif 000004