JP2005518016A - サーバシステムの再構成（ｒｅｃｏｎｆｉｇｕｒｉｎｇ）方法及び装置 - Google Patents

Abstract

サーバシステム（２００）を動的に再構成するための方法及び装置である。新しいサーバ構成が適用されると、以前のサーバ構成は保存される。サービス要求を受信すると、新しい構成に従った第１のスケジュールアルゴリズムを用いて、第１のサーバ（２０）が選択される。選択されたサーバが正しくなかった場合、保存された以前の構成に従った第２のスケジュールアルゴリズムを用い、第２のサーバ（２０４）が選択される。第２のサーバが正しければ、受信したサービス要求に関するユーザデータが第２のサーバから第１のサーバへ移される。このようにして、記憶されたデータは段階的かつ動的に古い構成から新しい構成に、比較的単純な方法によって再構成される。

Description

本発明は全体として、通信サービスを提供するための複数のサーバを有するサーバシステムを再構成するための方法及び装置に関する。より具体的には、このサーバシステムは１つ又はそれより多いサーバに対するシャットダウン期間を回避又は最小化できるよう、動的に再構成される。

従来の音声通話サービス及びショートテキストメッセージサービスに加え、多くの異なる固定又は移動の電気通信(telecommunication)／データ通信(datacommunication)サービスが生み出されてきている。例えば、インターネットブラウジングは急速に普及しているし、ここ数年無線分野はインターネットに収斂している。今や無線アクセスネットワークを介してインターネットに接続する機能を有する移動端末が入手可能であり、世界中至る所に存在するサイト又はサーバから情報及びサービスを得ることができる。

さらに、より多くのネットワーク容量とより高速な伝送ビットレートを提供する、移動通信のための新しい技術が開発されている。特に、ＧＰＲＳ（汎用パケット無線サービス:General Packet Radio Service）及びＷＣＤＭＡ（広帯域符号分割多元アクセス:Wideband Code Division Multiple Access）ネットワークが、広範囲の異なるデータレートを必要とする無線データサービスを可能にするために新たに出現してきている。多くの新サービスで通信されるデータは、様々な異なる形式及び組合せからなる音声、テキスト、画像、オーディオファイル及びビデオファイルを含みうる。

例えば、一般に”チャット”として知られるモバイルインスタントメッセージサービス及びプレゼンスサービスは急速に普及している。インスタントメッセージサービスは据え置き型ＰＣ（パーソナルコンピュータ）分野由来のものであり、メッセージステータスリポート及び様々なグループ及びアドレス帳機能が含まれる。プレゼンスサービスは移動端末の位置情報を用い、ユーザが自分のプロファイル及び有用性(availability)に応じてメッセージを受け取ることを可能にするものである。ユーザプロファイルは個人的なものであって良く、好み、興味、趣味をはじめ、ユーザが空き時間であるか及び現在の気分といったより一時的な要因によって定められても良い。メッセージサービス及びコンテンツサービスもまた、現在位置、入手可能性及び端末性能に応じて提供されうる。このようなサービスが、かなりの量の読み出し可能なユーザ固有データの記憶を必要とし、それらの動的な性質によって、多くの場合、頻繁な更新が必要であることは容易に理解されるところであろう。

通信サービスに対する要求は急速に増加しており、またこれら供給を満たすためのハードウェア並びにソフトウェアリソースを備えたサービスプロバイダが世界中に設立されている。特に、サービス要求及びデータを処理する手段のみならず、膨大な量のデータを記憶する手段が必要である。

従って、サービスプロバイダは、通常、サーバのような異なるサービス要素のシステムからなる処理手段及び記憶手段を効率よく制御できなければならない。以下、”サーバ”という表記は、データを記憶及び／又は処理するための任意のハードウェア及び／ソフトウェアを表すために用いる。サーバは１つ又はそれより多い特定のサービスを提供するように構成される。

複数のサーバを制御するインターネットサービスプロバイダ及びその種のものにとって、処理及び記憶負荷は複数のサーバに渡って分散せねばならない。これは利用可能な計算及び記憶リソースを効率よく使用したり、ホットスポットを取り扱ったり、ボトルネックを回避するために必要である。上述の通り、大量のデータを記憶せねばならず、かつこれらのデータは容易に探し出して読み出し可能であるべきである。

これまで説明した例から、異なる形式の記憶データは非常に動的であり、頻繁な更新が必要であろうことが分かる。さらに、処理及び記憶負荷の変動、例えば、サービス要求の需要変化、加入者の増加又は減少、サービスの導入、変更又は削除に応じ、時折サーバシステムを再構成する必要がある。人気のあるウェブサーバにおいては、少なくとも短期間、サーバの作業負荷が急激に増加するおそれがあり、その結果個々のサーバが容易に過負荷状態となる。サーバの過負荷問題を解決するため、基本的に２つの方法が利用可能である。

１つは、既存のサーバをアップグレードし、計算及び／又は記憶性能を向上させることである。しかし、サービス要求量及び／又はデータ記憶の必要性が引き続き増加した場合、そのサーバはまたすぐに過負荷状態になるであろう。そうすると更なるアップグレードが必要となり、実行するには複雑で、かつ高コストになりうる。

２つ目は、高負荷に適合する他のサーバを追加することが可能である。複数のサーバで負荷を分担するための仮想サーバという考え方が提案されている。仮想サーバは実際のサーバのクラスタ上に構築されるセラブルサーバ(salable server)であり、エンドユーザにはトランスペアレントで、ユーザからは１つの仮想サーバのみが見える。実サーバのフロントエンドは、「ロードバランサ」とも呼ばれるノードであり、異なる複数のサーバにサービス要求をスケジュールするように構成されている。入来サービス要求はこれら複数のサーバで処理すべき処理タスク及び記憶タスクを伴うであろう。クラスタに対してトランスペアレントにサーバを追加又は除去することで、スケーラビリティが達成できる。

しかし、記憶データの容易な読み出しを可能としつつ、処理及び記憶タスクを複数のサーバ間に効率よく分散させるためには問題がある。「処理タスク」はサービス要求の分析、データ処理及び、要求されたサービスを提供するための所定のアプリケーションの実行を含むであろう。「記憶タスク」は、新しい、クライアント固有データ、セッション固有データ又は設定データの記憶、既存データの更新及び、記憶データの読み出しを含むであろう。例えば、サービス要求は、特定の処理タスク又はサービスアプリケーションを実行するための入力として用いられる、所定のデータの読み出しを必要とするであろう。クライアントデータ及びセッションデータは以下まとめて「ユーザデータ」と呼ぶ。

処理及び記憶タスクの分散に係る現在の手法において、サーバはしばしばログイン要求時にクライアントへ割り当てられる。サーバを選択するために用いられるこの割り当て方法は、メモリリソース及び／又はＣＰＵ（中央処理装置）性能等に関して最も低い負荷を有するサーバがクライアント又はセッションに選択されるよう、通常、予め定められたサーバセットのその時点での負荷に基づいている。サーバ割り当ては通常中央負荷マネジャノード又は同等物を用いて実行される。そして、記憶されたユーザデータは読み出し可能でなくてはならない。つまり、サーチされたデータが記憶されているサーバを見いだすことが可能でなければならない。

サーバを選択するための方法として、現時点で最も簡単なものは「ラウンドロビン」割り当て方法である。より複雑な他の負荷分担手法として、「重み付けラウンドロビン」、「最小接続数」、「重み付け最小接続数」、「場所に基づく(locality-based)最小接続数」、「相手先(destination)ハッシング」及び「送信元(source)ハッシング」といった方法が知られている。

しかしながら、上述した方法は利用するのが比較的面倒であり、データがどこに分散、記憶されるかを予測することが難しいため、管理、運用及び維持に関して問題がある。さらに、データだけでなく、データに対するリファレンスやポインタを記憶しておかないと、１つ又はそれより多いサーバに記憶されたデータを見つけ、読み出すのが難しくなるであろう。ログインを実行するクライアントは、データへの適切なリファレンスを有するであろうが、その他のクライアント又はデバイスは、所謂「総当たりサーチ(brute force search)」をサーバセット内で用いない限り、リファレンス無しでそのデータを見つけ、読み出すことは出来ない。

処理タスクはそのタスクが処理されるサーバに影響を受けないので、「ラウンドロビン」スケジュール方法は処理負荷の分散にのみ適している。一方、１つ又はそれより多いサーバにおける記憶データの読み出しはラウンドロビン方式を用いて行うことは出来ず、上述したような特定のポインタ又はリファレンスの利用を必要とする。さらに、上述した他のスケジュール方法のいくつかに共通する問題として、スケジュールにＩＰ（インターネットプロトコル）アドレス指定(IP addressing)を用いることがある。単一のＩＰアドレスの後ろには複数のクライアントが存在しうる（プロキシ、ＮＡＴ等）ため、これらの方法はデータ分散にも、負荷分担にも利用することが出来ない。

従って、記憶タスクは、あるクライアント又はセッションＩＤを入力として用いるハッシュアルゴリズム(hashing algorithm)によってスケジュールされることが好ましい。そして、ハッシュアルゴリズムは選択されたサーバを特定する数値(number)を与える。同一クライアント又はセッションに対してその後発生するデータ読み出し時に同じハッシングアルゴリズムを用いた場合、サーチされたデータが記憶されて以来そのサーバが再構成されていない限り、同じサーバが選択される。このようにして、特定のポインタ又はリファレンスを使用する必要がなくなる。

しかし、サーバの数及び／又は個々のサーバのＩＤが再構成処理によって変化した場合、特定のクライアント又はセッションに対するユーザデータがその再構成が行われる前に記憶されていれば、もはやハッシングアルゴリズムは正しいサーバＩＤを提供しない可能性が非常に高い。現時点においてこの問題を回避するための方法は、サーバ選択が正しくなるようにハッシングアルゴリズムを変更し、記憶されたユーザデータをサーバ間で移動するため、サーバシステムをサービス要求からシャットダウンすることである。これは非常に面倒かつ時間がかかる処理であり、その間はサービス要求に対応することが出来ず、サービスプロバイダは利益を逸することになるため、望ましくない。さらに、再構成処理は比較的複雑であり、無視できないエラーリスクをはらんでいる。

本発明の目的は、上述した問題を減少又は取り除くこと、サービス要求の同時処理中における動的かつ効率的なサーバシステムの再構成を提供することである。それにより、１つ又はそれより多いサーバのシャットダウン期間を回避するか、少なくとも最小化することができる。

これらの目的は、サーバシステムの動的な再構成のための方法及び装置を提供することによって達成される。サーバシステムは少なくとも１つの共通した記憶タスクが可能な複数のサーバと、入来サービス要求を処理するためのサーバを選択するように構成されるスケジュール装置を有する。

本発明の方法及び装置において、新しいサーバ構成が適用され、以前のサーバ構成は保存される。サービス要求を受信すると、新しい構成に従った第１のスケジュールアルゴリズムを用い、あるサーバをその受信要求を処理するために選択する。選択されたサーバが正しくなかった場合、保存された以前の構成に従った第２のスケジュールアルゴリズムを用い、２回目の試行においてサーバが選択される。第２のスケジュールアルゴリズムによって正しいサーバが選択された場合、受信サービス要求に関するユーザデータを、選択されたサーバから第１のスケジュールアルゴリズムで選択されたサーバへ移動する。２回目の試行においても選択されたサーバが正しくなかった場合、保存されたさらに前の構成に従ったスケジュールアルゴリズムを用いてサーバを選択することができる。

好ましくは、これらのスケジュールアルゴリズムはハッシュアルゴリズムである。ハッシュアルゴリズムの利用は、ユーザＩＤからハッシュ数を得ること及び得られたハッシュ数からサーバＩＤを計算することを含みうる。そして、以下のアルゴリズムを用いることができる。
サーバＩＤ＝hash(ユーザＩＤ) modulo ｎ （１）
ここで、ｎは可能性のあるサーバ数であり、modulo演算子は０とｎ−１の間の整数を与える。新しい構成は数の変わったサーバを含み、その結果、第２のスケジュールアルゴリズムにおけるｎが第１のスケジュールアルゴリズムから変更される。サービス要求は新規データの記憶、既存データの更新及び記憶されたデータの読み出しといった記憶タスクを含みうる。

新規サーバ構成の適用はさらに、サーバからアクセス可能な中央アドミニストレータ又は同等のものに、新規構成データを記憶することを含みうる。各サーバは中央アドミニストレータから新規構成データを受信するように適合されたローカルアドミニストレータ又は同等物を有しうる。新規構成データは中央アドミニストレータからサーバへプッシュしても良いし、サーバから要求を送信して読み出しても良い。中央アドミニストレータは新規構成データを１つ又はそれより多いサーバにプッシュするための手段を有しうる。さらに、ローカルアドミニストレータは新規構成データの要求を中央アドミニストレータに送信するための手段を有しうる。

本発明の手順は、サーバシステムにおいて本方法を実施するように適合されたソフトウェアコードからなるコンピュータプログラムによっても実行されうる。

本発明はサーバシステムの２重構成(dual configuration)を同時に処理することができる。１つ又はそれより多いサーバの追加及び／又は除去によりシステムが再構成される状態になった際、以前の古い構成が保存される。
これにより、要求されたデータが新しい構成を用いて見つけられない場合には、古い構成を用いて読み出すことが可能である。

記憶されたデータは、システム運用上の影響を最小限にしながら、段階的かつ動的に古い構成から新しい構成に再編成(reorganize)される。新規ユーザ又はセッションに関するデータを新規に追加されたサーバのみならず、既存のサーバにも効率よく分散することが可能なため、サーバシステムの再構成時にはより良好なデータ分散も実現できる。
以下、添付図面を参照しながら、本発明をより詳細に説明する。

図１は、本発明を利用可能な通信シナリオの模式的な概要を示している。複数のクライアント端末１００がインターネットなどのバックボーンネットワーク１０２に接続されている。図に示すように、クライアント端末１００は、有線端末又はエアインタフェースを介して移動アクセスネットワーク１０４に接続される無線端末等の固定機器又は移動機器であってよい。同様に、複数のサービスプロバイダ１０６がバックボーンネットワーク１０２に接続され、各サービスプロバイダ１０６はクライアント端末１００用に要求された電気通信サービスを実行するための１つ又はそれより多いサーバを有している。簡単にするため図示しないが、実際には、他の様々なネットワーク及び／又はノードがクライアントとサービスプロバイダ間の通信経路中に含まれる。

クライアント端末１００はバックボーンネットワーク１０２を介してサービスプロバイダ１０６へサービス要求を送信することで、特定の電気通信サービスを開始することができる。そして、要求を送信されたサービスプロバイダは、要求に応答して１つ又はそれより多い適切なサービスアプリケーションを起動(activate)する。サービスアプリケーションの起動は、１つ又はそれより多いサーバで実行されるような、様々な処理タスク及び記憶タスクを含みうる。サービスアプリケーションはまた、前持った端末からの要求無しに、例えばＷＡＰ(Wireless Application Protocol)に関して用いられるような「プッシュ」メカニズムを通じて起動されうる。従って、サービス要求は、例えば所定のクライアント又は継続中のセッションに関するユーザデータを必要とする、他のサービスプロバイダやネットワークオペレータから発せられてもよい。例えば、あるサービスプロバイダは、移動機がある特定の領域に入るとその移動機に所定の情報を送信したいと考えるかも知れない。その場合、そのサービスプロバイダは、端末性能及びクライアントプロファイル（例えば予め登録された好みや興味を含む）等、必要とするユーザデータを要求するであろう。

上述したように、サービスプロバイダは通常、クライアント及び他のサービスプロバイダからのサービス要求を処理するために複数のサーバを備えている。従って、いくつかのサーバにおいて同一の機能性、タスクの処理又は記憶を多重化し、それによって同一又は類似のサービスタスクを複数のクライアントに対して同時に実行できるようにしている。本発明はいかなるシャットダウン期間も回避又は少なくとも最小化できるよう、複数のサーバを効率的に再構成することを可能にする方法及び装置に関する。

図２に、１つ又はそれより多い通信サービスをクライアント端末に提供するための、単純化されたサーバシステム２００を示す。サーバシステム２００は１つ又はそれより多い記憶タスクを含む入来サービス要求をスケジュールするスケジュール装置２０２を有する。スケジュール装置２０２は少なくとも１つの共通記憶タスクを実行可能なサーバセット２０４に接続される。サーバ２０４はさらに、他のタスク又は処理を実行可能であっても良いが、それは本発明の範囲外である。サーバ２０４はまた、異なるサービスアプリケーションに対して指定されていても良く、またセッションサーバ、インスタントメッセージサーバ、プレゼンスサーバ等を含んでいても良い。

サーバシステム２００はまた、アクセスノードや、異なる要求処理動作に指定された異なるサーバ等の他の構成要素を含んでも良い。しかし、これら他の構成要素の機能性は基本的に本発明の範囲外であるため、ここでは説明しない。

スケジュール装置２０２はサービスプロバイダのアクセスノード内に存在することができ、クライアント、サービスプロバイダ又はネットワークオペレータからのサービス要求を受信する。スケジュール装置２０２はまた、所定のサービス要求を更なる処理のために他のサーバへ転送するように構成された処理サーバ内に存在していても良い。

スケジュール装置２０２は、ある所定のクライアント又はセッションＩＤを入力として用いるスケジュールアルゴリズムを、入来サービス要求に対する特定のサーバ２０４の選択に用いるように構成されている。そして、スケジュールアルゴリズムは選択されたサーバを特定する数値を与える。スケジュールアルゴリズムは、クライアント又はセッションについて記憶されたデータが読み出された際、そのデータが記憶された時とサーバ２０４の数及びそのＩＤが同じであれば正しいサーバが選択されるようにする。さらに、記憶タスクが新規ユーザデータの記憶を含む場合、スケジュールアルゴリズムはその新規データが古いユーザデータが記憶されていたサーバと同じサーバに記憶されるようにする。好ましくは、スケジュールアルゴリズムはハッシュアルゴリズムである。ハッシュアルゴリズムとは、クライアント又はセッションの、予め定められたＩＤコード（以下まとめて「ユーザＩＤ」と呼ぶ）からハッシュ値が得られることを意味する。

サーバ識別子は、得られたハッシュ値に基づいて、所定のアルゴリズム又は数式を用いて対応するサーバＩＤを計算することにより決定することができる。例えば、ハッシュ値(hash number)はユーザＩＤのバイナリコードに対する単純なチェックサムやその同等物であって良い。一例によれば、記憶タスクを実行するためのサーバ２０４は以下のアルゴリズムから決定される。
サーバＩＤ＝hash(ユーザＩＤ) modulo ｎ （１）
ここで、ｎはセット内の可能性のあるサーバの数である。modulo演算子は０及びｎ−１の間の整数を与える。

例えば、４つの２次サーバ２０４：０〜２０４：３が利用可能であり（すなわち、ｎ＝４）、ある特定のクライアントがハッシュhash（ユーザＩＤ）＝１４を与えたとすると、サーバＩＤ＝２となる。従って、サーバ２０４：２が選択される。別のクライアントにいてhash（ユーザＩＤ）＝１６であれば、サーバＩＤ＝０となり、他の場合も同様である。同じユーザＩＤに対して常に同じサーバＩＤが得られさえすれば、任意の好適なハッシュ関数をユーザＩＤに適用することができる。このようにして、記憶負荷をサーバセット２０４内で分散させることが可能になる。

しかし、サーバシステムがサーバ数を変更して再構成を必要とする場合、新しい数のサーバ間で記憶負荷を分散させるためには、使用されるハッシュアルゴリズムもまた変更しなければならない。従って、例えばサービス要求のトレンドや、加入者数や提供されるサービスの変化に帰因して１つ又はそれより多いサーバを加除するには、ハッシュアルゴリズムの変更が必要となるであろう。

例えば、上述したハッシュアルゴリズム（１）が用いられるとすると、新しいサーバ数に従ってｎを変更しなければならない。そうすると、変更されたハッシュアルゴリズムにユーザＩＤを入力しても、十中八九以前とは異なるサーバＩＤが得られることになるであろう。

従前の方法において、ユーザデータのストレージを移動するため、又は関連するサーバにおいて影響を受ける各データエントリに対する相対的な記憶位置への特定のポインタ又はリファレンスを導入するための期間、再構成されたサーバシステムはシャットダウンされる。これが単調かつ時間のかかる手順であることは容易に理解されよう。

代わりに、本発明はサービス要求処理の同時操作を可能とする動的な手法を提供し、それにより好ましからざるシャットダウン期間を回避するものである。新たなサーバ構成を導入する際、ハッシュアルゴリズムはこの新たな構成に従って変更され、古い構成はスケジュール装置２０２のメモリ２０６へ保存される。古い構成の保存は、少なくとも古いハッシュアルゴリズムとそのパラメータ、さらに必要に応じて古い構成のサーバシステム構成の情報の保存を含む。

ユーザＩＤによって特定されるクライアント又はセッションに対する、記憶タスクを含むサービス要求を受信すると、スケジュール装置２０２は変更された新しいハッシュアルゴリズムを用いて正しいサーバを探そうとする第１の試みを行う。期待されたサーバ、つまりサーチされたデータ又は古いユーザデータが記憶されたサーバが見つからない場合、保存された古い構成に従った古いハッシュアルゴリズムが第２の試行において用いられる。

正しいサーバが見つかり、その記憶タスクに対して選択されたら、そのクライアント又はセッションに関連するデータは新しいハッシュアルゴリズムに対応する新しいサーバに移される。新しいハッシュアルゴリズムがたまたま古いハッシュアルゴリズムと同じサーバを選択した場合には、そのデータはもちろん移動させない。

このようにして、異なるクライアント又はセッションについてのサービス要求が受信されている限りは、既に記憶されているデータを徐々に新しいハッシュアルゴリズムに従った正しいサーバに移動させることができる。時間の経過に伴い、新しい構成に従った正しいサーバに存在するデータの、全データ量に占める割合が増加する。最終的に、まだ移動していない残りのユーザデータのストレージを変えるための限られた期間、サーバシステムをシャットダウンするのに適した状態になる。そして、古い構成をメモリ２０６から削除することができる。

本発明の範囲内で、１つのサーバシステムにおいて、２つより多いバージョンの構成を同時に用いることが可能であることに留意すべきである。従って、さらに前のバージョンの、より以前の構成をメモリ２０６へ保存することができる。この場合、正しいサーバを見つけるために、保存されたより古い構成バージョンを用いて２より多い試行を行うことが可能である。

図３に示すフローチャート及び必要に応じて図２をも参照しながら、サーバシステムを動的に再構成する例示的な手順について説明する。この例においては、サーバの数が変更され、また新しいハッシュアルゴリズムが従前のアルゴリズムを置き換えており、従前のアルゴリズムはメモリ２０６へ保存されているものとする。最初のステップ３００において、スケジュール装置２０２がサービス要求を受信する。そのサービス要求に対し、既に記憶されているユーザデータの読み出しといったような、サーバ２０４の１つで実行しなければならない記憶タスクが検出される。ステップ３０２において、サーチされたデータが記憶されている正しいサーバを見つけるため、第１の試行がなされる。そして、受信したサービス要求に対するサーバを選択するため、対応するユーザＩＤを入力として用いる新しいハッシュアルゴリズムが適用される。このユーザＩＤは、通常受信したサービス要求から抽出することが可能である。

次に、ステップ３０２で新しいハッシュアルゴリズムにより正しいサーバが見つかり、選択されたかどうかがステップ３０４において判定される。もしそうであれば、ステップ３０６において記憶タスクを実行することができ、その後手順は次のサービス要求を受信するために最初のステップ３００へ戻ることができる。ステップ３０４において、選択されたサーバが正しくないと判定された場合、正しいサーバを見つけるため第２の試行が、保存された以前のハッシュアルゴリズムを受信したサービス要求に適用することにより、ステップ３０８において実行される。

次に、ステップ３０８で以前のハッシュアルゴリズムにより正しいサーバが見つかり、選択されたかどうかがステップ３１０において判定される。もしそうであれば、ステップ３１２において、そのサービス要求に関連するユーザデータは古いサーバから、新しいハッシュアルゴリズムによってステップ３０２で選択された新しいサーバへ移される。その記憶タスクが、そのサービス要求が宛てられたクライアント又はセッションのユーザデータの一部のみに関連してなされるものであっても、移動されるデータは、全ユーザデータを包含して良い。

ステップ３１４において記憶タスクもまた実行され、その後手順は次のサービス要求を受信するために最初のステップ３００へ戻ることができる。なお、適合すれば、ステップ３１２と３１４は逆の順番で実行するようにしても良い。例えば、記憶タスクでサーチされたデータを、別のサーバに移す前にまず読み出すことは、おそらく効率的であろう。

ステップ３１０において、ステップ３０８で依然として正しいサーバが選択されていないと判定された場合、ステップ３１６で、正しいサーバを探すために新たな試行を行うべきか決定する。もしそうであれば、上述のように、別の過去のハッシュアルゴリズム、おそらくはより古い保存ハッシュアルゴリズムを適用するため、手順はステップ３０８へ戻る。ステップ３１６で、例えばタイムアウト又はカウントアウトにより新たな試行を行わないと判定された場合、受信したサービス要求に対する記憶タスクを実行することができない。そして、ステップ３００へ戻り、新しい要求を受信することができる。

上述したように、サーバシステムの再構成は提供されるサービスの変更を含みうる。例えば、新しいサービスが追加されたり、既存のサービスが変更又は廃止されたりするかもしれない。複数のサーバを有するシステムにおいて、そのような再構成は全サーバの新しい構成による更新を必要とする。従前の手法では、関連する新しい構成データは全てのサーバに記憶される。代わりに、本発明では、全ての構成データはサーバからアクセス可能な中央アドミニストレータ又は同等物に記憶される。

図４のブロック図は、構成データの集中管理を説明している。サーバ４００のグループが示されており、個々のサーバは図２のサーバ２０４と同様、少なくとも１つの共通したサービス要求を処理可能である。各サーバ４００は、中央アドミニストレータ４０４に接続され、そこから構成データをアクセスする機能を有するローカルアドミニストレータ４０２を有する。中央アドミニストレータ４０４は、サーバシステム内の独立したノードであってもよいし、例えば上述したスケジュール装置２０２と共にアクセスノード又はサーバ内に存在しても良い。

サーバ４００は要求されたサービスを起動するため、所定の構成データへアクセスする必要があるであろう。しかし、本実施形態によれば、そのような構成データはサーバ内で局所記憶されていない。代わりに、サーバ４００に対して有効な全ての構成データは中央アドミニストレータ４０４に記憶されている。従って、サーバ４００において要求されたサービスを起動するために必要ないかなる構成データも、サーバ４００のローカルアドミニストレータ４０２から構成データの要求を送信することにより、中央アドミニストレータ４０４から読み出すことができる。ローカルアドミニストレータ４０２において、中央アドミニストレータ４０４への参照のみが必要である。構成データはまた、中央アドミニストレータ４０４から１つ又はそれより多いローカルアドミニストレータ４０２に対して「プッシュ」する、即ち、ローカルアドミニストレータ４０２からの先立つ要求無しに送信することができる。

この構成によれば、構成データは複数のサーバ４００内で複製される代わりに、ただ１つの場所に効率的に記憶される。構成データのどのような更新も、中央アドミニストレータ４０４において容易に行うことが可能であり、中央アドミニストレータ４０４は現在のサービス及びサーバの正確な概要を有することとなる。従って、異なる構成バージョンを有するサーバ間でのエラーやコンフリクトを回避することができる。さらに、複数のサーバにおいて更新を同期させる必要もなくなる。

本発明は、「ワイヤレスビレッジサーバ(Wireless Village Server)」に照らして規定される、インスタントメッセージサービス、位置情報サービス及び共有コンテンツサービスといった電気通信サービスにおいて非常に有効に用いることができる。そのようなサービス要求を処理するサーバに本発明を適用することにより、それらサーバに対して動的かつ効率的な再構成が達成される。しかし、本発明はデータ分散のための任意のスケーラブルシステムに対して適用可能である。本発明を用いることで、サーバシステムを少なくとも長い間シャットダウンすることなく、サーバを動的に追加及び／又は除去することが可能である。このようにして、高レベルのサービスを維持することができる。

特に、本発明は、本出願人による同時継続中のＰＣＴ出願に記載される、データストレージ及び処理負荷を複数のサーバ間で分散するためのサーバシステムにおいて好適に利用することができる。この方法において、処理タスクを実行するためのプライマリサーバが、任意のプライマリサーバを選択可能な第１のスケジュールアルゴリズムを用いて割り当てられる。記憶タスクを実行するためのセカンダリサーバは、その記憶タスクに含まれるクライアントに対応する特定のセカンダリサーバを選択可能な第２のスケジュールアルゴリズムを用いて割り当てられる。

本発明を特定の実施形態に関して説明してきたが、この説明は発明の概念の例示のみを目的としたものであり、本発明の範囲を限定するものして解されるべきものではない。
特許請求の範囲に定義される本発明の精神を逸脱することなく、様々な代替物、変形物及び等価物を用いることが可能である。

本発明を利用可能な通信シナリオの模式的な概要を示す図である。 実施形態に係る例示的なサーバシステムのブロック図である。 サービス要求を処理するための手順を示すフローチャートである。 構成データの集中管理を説明するブロック図である。

Claims (21)

1. 入来サービス要求を処理するための複数のサーバを含むサーバシステムを動的に再構成する方法であって、
   Ａ）新しいサーバ構成を適用するステップと、
   Ｂ）過去のサーバ構成を保存するステップとを有し、
   サービス要求受信時に、
   Ｃ）前記新しい構成に従った第１のスケジュールアルゴリズムを用いて、受信したサービス要求を処理するためのサーバを選択するステップと、
   Ｄ）ステップＣ）で選択されたサーバが正しくない場合、ステップＢ）で保存された過去のサーバ構成に従った第２のスケジュールアルゴリズムを用いてサーバを選択するステップと、
   Ｅ）ステップＤ）において選択されたサーバが正しければ、前記受信したサービス要求に関するユーザデータを、前記ステップＤ）において選択されたサーバから、前記ステップＣ）において選択されたサーバへ移動するステップ、
   とを実行することを特徴とする方法。
2. 前記ステップＤ）において選択されたサーバがさらに正しくなかった場合、保存されたさらに古い構成に従ったスケジュールアルゴリズムを用いてサーバを選択するステップを更に有することを特徴とする請求項１記載の方法。
3. 前記スケジュールアルゴリズムがハッシュアルゴリズムであることを特徴とする請求項１又は請求項２記載の方法。
4. 前記ハッシュアルゴリズムの利用が、ユーザＩＤからのハッシュ値の取得及び前記取得したハッシュ値からのサーバＩＤの計算を含むことを特徴とする請求項３記載の方法。
5. 以下のアルゴリズム
   サーバＩＤ＝hash（ユーザＩＤ） modulo ｎ （１）
   （ここで、ｎは可能性のあるサーバの数であり、modulo演算子は０からｎ−１の間の整数を与える）
   を用いることを特徴とする請求項４記載の方法。
6. 前記新しい構成が変更された数のサーバを含み、前記第２のスケジュールアルゴリズムにおけるｎが、前記第１のスケジュールアルゴリズムから変更されていることを特徴とする請求項５記載の方法。
7. 前記サービス要求が記憶タスクを含むことを特徴とする請求項１乃至請求項６のいずれか１項に記載の方法。
8. 前記記憶タスクが、
   新しいデータの記憶、既存データの更新及び既存データの読み出しのいずれかを含むことを特徴とする請求項７記載の方法。
9. 前記新しいサーバ構成を適用するステップＡ）が、前記サーバからアクセス可能な中央アドミニストレータ又は同等のものに、新規構成データを記憶するステップを含むことを特徴とする請求項１乃至請求項８のいずれか１項に記載の方法。
10. 前記新規構成データが、前記中央アドミニストレータから１つ又はそれより多いサーバにプッシュされることを特徴とする請求項９記載の方法。
11. 前記新規構成データが、サーバから要求を送信することにより前記中央アドミニストレータから読み出されることを特徴とする請求項９記載の方法。
12. 少なくとも１つの共通した記憶タスクの実効が可能な複数のサーバと、入来サービス要求を処理するためのサーバを選択するように構成されるスケジュール装置とを有するサーバシステムを再構成するための装置であって、
    −新しいサーバ構成を適応する手段と、
    −過去のサーバ構成を保存する手段と、
    −前記新しい構成に従った第１のスケジュールアルゴリズムを用いて、受信したサービス要求を処理するための第１のサーバを選択する手段と、
    −前記第１のサーバが正しくない場合、前記過去のサーバ構成に従った第２のスケジュールアルゴリズムを用いて第２のサーバを選択する手段と、
    −前記第２のサーバが正しければ、前記受信したサービス要求に関するユーザデータを、前記第２のサーバから、前記第１のサーバへ移動する手段とを有することを特徴とする装置。
13. 前記第２のサーバがさらに正しくなかった場合、さらに古い構成に従ったスケジュールアルゴリズムを用いてサーバを選択する手段を更に有することを特徴とする請求項１２記載の装置。
14. スケジュールアルゴリズムとしてハッシュアルゴリズムを用いる手段を更に有することを特徴とする請求項１２又は請求項１３記載の装置。
15. ユーザＩＤからハッシュ値を得、このハッシュ値からサーバＩＤを計算する手段を更に有することを特徴とする請求項１４記載の装置。
16. 以下のアルゴリズム
    サーバＩＤ＝hash（ユーザＩＤ） modulo ｎ （１）
    （ここで、ｎは可能性のあるサーバの数であり、modulo演算子は０からｎ−１の間の整数を与える）
    を用いる手段を有することを特徴とする請求項１５記載の装置。
17. 新規構成データを記憶するための、前記サーバからアクセス可能な中央アドミニストレータ又は同等のものを有することを特徴とする請求項１２乃至請求項１６のいずれか１項に記載の装置。
18. 各サーバに、前記中央アドミニストレータから前記新規構成データを受信するためのローカルアドミニストレータ又は同等のものを有することを特徴とする請求項１７記載の装置。
19. 前記中央アドミニストレータが前記新規構成データを１つ又はそれより多いサーバにプッシュするための手段を有することを特徴とする請求項１７又は請求項１８記載の装置。
20. 前記ローカルアドミニストレータが、前記新規構成データの要求を前記中央アドミニストレータへ送信する手段を有することを特徴とする請求項１８記載の装置。
21. 請求項１乃至請求項１１のいずれか１項に記載の方法をサーバシステムにおいて実行させるように適合されたソフトウェアコードからなるコンピュータプログラム。

Images