JP2002163241A

JP2002163241A - クライアントサーバシステム

Info

Publication number: JP2002163241A
Application number: JP2000362847A
Authority: JP
Inventors: Takayoshi Kusaka; 貴義日下; Katsufumi Fukunishi; 克文福西; Hideaki Tsukamoto; 英昭塚本; Atsushi Konosu; 淳鴻巣
Original assignee: NTT Data Corp
Current assignee: NTT Data Group Corp
Priority date: 2000-11-29
Filing date: 2000-11-29
Publication date: 2002-06-07

Abstract

(57)【要約】【課題】需要変動に応じて、サービス提供側の資源を
動的に再構成する。【解決手段】各クライアント１からのアクセス要求
（サービス要求）は、負荷分散装置２により、サーバク
ラスタ４で稼働中のいずれかのサーバ５に振り分けられ
る。アクセスが増大又は減少すると、管理モジュール１
０は、サーバクラスタ４の構成変更を指示し、サーバク
ラスタ４へのサーバ６の追加又はサーバクラスタ４から
のサーバ５の削除等を行わせる。サーバクラスタ４の構
成変更は、管理モジュール１０により負荷分散装置２の
アクセス振り分け先リスト３に反映される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、いわゆるインター
ネット上のウェブシステムや電子商取引等に好適に用い
ることが可能なクライアントサーバシステムに関する。

【０００２】

【従来の技術】例えば、インターネット上のウェブシス
テムに代表されるクライアントサーバシステムでは、ク
ライアントが所定のサーバにアクセスしてサービスを要
求すると、サーバはこの要求を処理し、結果をクライア
ントに返す。例えば、ユーザーは、ウェブブラウザ（ク
ライアント）を介して、ネットニュースや音楽、映像等
の種々のコンテンツを閲覧することができる。あるい
は、コンサートや航空機のチケット予約、商品の注文等
も行うことができる。

【０００３】特定のサーバに多量のアクセスが集中する
と、サーバの負荷が増大するため、応答時間が著しく長
くなったり、あるいは処理不能となる場合がある。そこ
で、従来のクライアントサーバシステムでは、例えば、
複数のサーバをクラスタリング（疎結合）させて見かけ
上単一のサーバを構成すると共に、各クライアントから
のサービス要求を負荷分散装置によって各サーバに振り
分けることにより、多量のサービス要求を処理できるよ
うにしている。

【０００４】

【発明が解決しようとする課題】上述の通り、従来のク
ライアントサーバシステムでは、予め複数のサーバを用
意してクライアントからのサービス要求を処理している
が、需要を正しく予測するのは困難である。従って、予
想以上のアクセスが発生したり、新しいサービスの追加
によって既存サーバ群の処理能力を超過しそうになった
場合には、サーバ群へ新たなサーバを追加することによ
り、超過分のサービス要求を処理することになる。これ
とは逆に、見込みよりも少ないアクセスしか発生しなく
なったり、あるいは、システムの縮小やサービスの削減
等により現状の処理能力が過大になった場合には、サー
バ群からサーバを縮退させることにより、余剰分の処理
能力を削除することが可能である。

【０００５】しかし、このようなサーバの追加又は縮退
には、熟練オペレータによる煩雑な作業が必要である。
例えば、熟練オペレータは、サーバ追加又は縮退のタイ
ミングを判断し、予備サーバに必要なコンテンツやロジ
ック等を移植し、仕掛かり中のデータ処理が円滑に行わ
れるように注意しながらサーバを追加等しなければなら
ない。一般的には、システムを停止させてサーバ構成を
変更する場合が多いが、サービスを中断させないように
サーバ構成を変更する場合も熟練オペレータによる作業
を必要とする。

【０００６】従って、比較的長い作業時間を必要とし、
判断ミスや作業ミス等の人為的エラーを完全に排除し得
ないという不都合がある。

【０００７】本発明は、上記の課題に鑑みなされたもの
であり、その目的は、需要変動に応じて適切なサービス
処理能力を再構成可能なクライアントサーバシステムを
提供することにある。

【０００８】

【課題を解決するための手段】上記課題を解決するた
め、本発明では、サーバ結合体の構成を動的に再構成す
ることにより、需要変動に応じた適切な資源配置を可能
としている。

【０００９】即ち、本発明に係るクライアントサーバシ
ステムは、クライアントからのサービス要求を処理する
ための複数のサーバを結合させてなるサーバ結合体と、
前記クライアントからのサービス要求を前記サーバ結合
体のいずれかのサーバに振り分けるための振り分け手段
と、前記サーバ結合体の構成を変更させるための構成変
更手段と、前記構成変更手段による構成変更を前記振り
分け手段に通知し、該振り分け手段の設定を変更させる
ための設定変更手段と、を備えることを特徴としてい
る。

【００１０】ここで、「クライアント」としては、例え
ば、ウェブブラウザ等を挙げることができる。「サー
バ」としては、例えば、ウェブサーバやアプリケーショ
ンサーバ等を挙げることができる。「サーバ結合体」と
は、複数のサーバを疎結合させて見かけ上単一のサーバ
システムとしたものである。各クライアントからのサー
ビス要求は、振り分け手段によって、サーバ結合体のい
ずれかのサーバに振り分けられる。

【００１１】もしも、クライアントからのサービス要求
が増大して現状の処理能力を上回ったり、逆に、サービ
ス要求が少なくなって現状の処理能力に余剰分を生じた
りした場合には、構成変更手段は、サーバ結合体の構成
を変更させる。即ち、構成変更手段は、サーバ結合体に
予備のサーバを追加したり、サーバ結合体から余剰サー
バを縮退させる等の構成変更を行う。サーバ結合体の構
成変更は、振り分け手段に通知され、これにより振り分
け手段の設定も変更される。そして、新たに生じたサー
ビス要求は、設定変更された振り分け手段により、再構
成されたサーバ結合体のいずれかのサーバによって処理
される。

【００１２】サーバ結合体へのアクセス状態を監視する
ためのアクセス状態監視手段と、該アクセス状態監視手
段からの通知に基づいて、構成変更手段による構成変更
の内容を決定する判定手段を更に備えてもよい。

【００１３】アクセス状態監視手段は、例えば、過剰ア
クセス又は過小アクセスの発生を監視し、判定手段は、
この監視通知に基づいてサーバ結合体の構成変更につい
て判断する。判定手段は、例えば、サーバ結合体に追加
又は縮減すべきサービス（サーバ、コンテンツ、ロジッ
ク等）の内容を判定する。この判定結果に従って、構成
変更手段は、サーバ結合体の構成を変更させる。

【００１４】サーバ結合体は、少なくとも機能層及びプ
レゼンテーション層を備えており、構成変更手段は、前
記機能層及び前記プレゼンテーション層の各層毎に構成
変更が可能であることが好ましい。

【００１５】例えば、データ層（RDBMS：Relational Da
taBase Management System）、機能層（アプリケーショ
ンサーバ）、プレゼンテーション層（ウェブサーバ／ア
プリケーションサーバ）、ネットワーク層（ネットワー
ク機器）に階層化されたシステムにおいて、機能層及び
プレゼンテーション層のそれぞれについて、各層に適し
た資源の再配置を行うことが好ましい。

【００１６】なお、機能層及びプレゼンテーション層
は、同一のサーバ内に存在しても良いし、異なるサーバ
内に存在してもよい。

【００１７】構成変更手段によりサーバ結合体の構成を
縮退させる場合には、ａ．サーバ結合体から除去予定の
サーバに対する新規なサービス要求を拒否又は他のサー
バに依頼し、ｂ．除去予定のサーバで仕掛かり中の処理
が終了するのを待機し、ｃ．仕掛かり中の処理終了を確
認した後に、除去予定のサーバをサーバ結合体から除去
させることが好ましい。

【００１８】これにより、仕掛かり中のサービスが中断
されるのを防止しつつサーバ結合体の構成を縮退させる
ことができる。

【００１９】また、本発明は、クライアントサーバシス
テムに用いられる管理装置としても把握することができ
る。

【００２０】即ち、本発明に係る管理装置は、クライア
ントと、該クライアントからのサービス要求を処理する
ための複数のサーバを結合させてなるサーバ結合体と、
前記クライアントからのサービス要求を前記サーバ結合
体のいずれかのサーバに振り分けるための振り分け手段
とを備えたクライアントサーバシステムに用いられる管
理装置であって、前記管理装置は、前記サーバ結合体の
構成を監視するためのサーバ構成監視手段と、前記サー
バ結合体の構成を変更させるための構成変更手段と、前
記構成変更手段による前記サーバ結合体の構成変更が完
了したことを前記サーバ構成監視手段により確認した場
合には、前記振り分け手段に前記サーバ結合体の構成変
更を通知して、該振り分け手段の設定を変更させるため
の設定変更手段と、を備えていることを特徴とする。

【００２１】

【発明の実施の形態】以下、図１〜図８に基づき本発明
の実施の形態について詳述する。

【００２２】図１は、本実施の形態に係るクライアント
サーバシステムの全体構成を概略的に示すブロック図で
ある。本クライアントサーバシステムは、後述するよう
に、クライアント１，負荷分散装置２，サーバクラスタ
４，管理モジュール１０を備えている。

【００２３】クライアント１は、ウェブブラウザ又はウ
ェブサーバからなり、インターネット等のネットワーク
を介してサーバクラスタ４にアクセスし、サービスを要
求するものである。クライアント１が要求するサービス
としては、例えば、テキストや画像又は音楽等の各種コ
ンテンツの閲覧、商品の注文やチケットの予約、銀行口
座残高の移動等を挙げることができる。

【００２４】「振り分け手段」としての負荷分散装置
（例えば、ネットワークロードバランサ）２は、アクセ
ス振り分け先リスト３を有している。アクセス振り分け
先リスト３には、利用可能なサーバのアドレス等が記録
されている。負荷分散装置２は、各クライアント１から
のアクセス要求を、アクセス振り分け先リスト３に基づ
いて、サーバクラスタ４のいずれかのサーバ５に振り分
けるようになっている。後述のように、機能層の構成を
変更する場合には、例えば、ＪＮＤＩ（Java Naming an
d Directory Interface）によるアクセス先検索を利用
してアクセス先を振り分けることができる。また、ラウ
ンドロビンアクセスを併用してもよい。

【００２５】「サーバ結合体」としてのサーバクラスタ
４は、複数のサーバ５を疎結合させてなるものである。
サーバクラスタ４は、現在稼働中のサーバ５と、必要に
応じて追加される予備サーバ６とを備えている。予備サ
ーバ６には、サーバ拡張に必要な各種モジュール及びコ
ンテンツが予め記録されている。

【００２６】「管理装置」としての管理モジュール１０
は、需要に応じてサーバクラスタ４の構成を動的に変更
させるものである。管理モジュール１０は、管理モジュ
ール単独の装置として構成することができるほか、サー
バクラスタ４やサービス依頼側の負荷分散装置２の一部
としても構成でき、搭載場所を選ばない。

【００２７】管理モジュール１０は、「判定手段」とし
ての判定部１１，「設定変更手段」としての設定変更部
１２，「構成変更手段」としての構成変更部１３及び
「サーバ構成監視手段」としてのサーバ構成監視部１４
とを備えている。

【００２８】「アクセス状態監視手段」としてのアクセ
ス監視部１５は、サーバクラスタ４に向けて発生したア
クセス要求（サービス要求）の状態を監視し、サーバク
ラスタ４が提供する各サービスへの需要が所定の上限値
又は下限値に達したか否かを検出するものである。な
お、アクセス監視部１５は、各サービスへの需要をモニ
タリングできれば足り、需要が所定の上限値又は下限値
に達したか否かまで判定する必要は必ずしもない。需要
変動に対する評価は判定部１１によって行うことができ
るためである。

【００２９】判定部１１は、アクセス監視部１５からの
通知に基づいて、サーバクラスタ４の各サーバ５が提供
するサービスについて、サービスを提供するサーバを追
加すべきか、又は削除すべきかを判定する。構成変更部
１３は、判定部１１による判定結果に基づいて、サーバ
クラスタ４の構成を変化させる。ウェブサーバやアプリ
ケーションサーバの追加が必要と判断された場合は、構
成変更部１３は、予め各モジュール等が実装されている
予備サーバ６をリモートコントロールにより起動して現
用サーバ群に追加する。逆に、サーバの削減が必要と判
断された場合には、構成変更部１３は、現在仕掛かり中
のサービスを中断させることなく、削減対象となるサー
バ５を現用サーバ群から外すようになっている。

【００３０】構成変更部１３によるサーバクラスタ４の
構成変更は、サーバ構成監視部１４により検出される。
サーバ構成監視部１４は、例えば、ポーリングによる問
い合わせやＳＮＭＰ（Simple Network Management Prot
ocol）トラップ（障害通知）等を利用することにより、
サーバクラスタ４の構成情報を取得する。設定変更部１
２は、構成変更部１３によるサーバクラスタ４の構成変
更をサーバ構成監視部１４からの通知によって確認する
と、負荷分散装置２が参照するアクセス振り分け先リス
トを更新させる。これにより、新たに現用サーバ群に追
加されたサーバにもクライアント１からのアクセスが振
り分けられ、一方、現用サーバ群から削除されたサーバ
へのアクセスが禁止される。

【００３１】図２は、ウェブサイトの構成の一例を示す
ブロック図である。ウェブサイトは、例えば、ネットワ
ーク層２０，プレゼンテーション層３０，機能層４０及
びデータ層５０から階層化されて構成されている。ネッ
トワーク層２０には、負荷分散装置２を含めることがで
き、管理モジュール１０はウェブサイト内に設けること
ができる。

【００３２】ウェブサーバは、プレゼンテーション層３
０を受け持つ。ウェブサーバでは、HTTPD（HTTP Daemo
n）３１が稼働する。管理モジュール１０からの指示に
より、プレゼンテーション層３０で稼働するウェブサー
バの構成は動的に変化する。符号３２で示すものは予備
のウェブサーバである。

【００３３】アプリケーションサーバは、機能層４０を
担当する。アプリケーションサーバとしては、例えば、
米国サンマイクロシステムズ社が開発し提供しているJa
vaベースのサーバ側コンポーネントモデル「Enterprise
JavaBeans（EJB）」をサポートするEJBサーバ４１を挙
げることができる。以下、アプリケーションサーバとし
てEJBサーバを例に挙げる。管理モジュール１０からの
指示によって、機能層４０で稼働するEJBサーバ４１の
台数は動的に変化する。符号４２で示すものは予備のEJ
Bサーバである。

【００３４】データ層５０には、データベースマネジメ
ントシステム（DBMS）が設けられている。データ層５０
は、プレゼンテーション層３０（ウェブサーバ）又は機
能層４０（アプリケーションサーバ）からの要求に応じ
て、外部記憶装置に蓄積されたデータベースを検索し、
その検索結果を返すようになっている。

【００３５】次に、図３は、サーバクラスタ４の資源配
置を動的に変化させる場合の概略処理を示すフローチャ
ートである。本フローチャートは、処理の流れを説明す
るためのものである。以下、ステップを「Ｓ」と略記す
る。

【００３６】まず、アクセス監視部１５の監視結果に基
づいて、サーバクラスタ４の構成変更を要求するような
状態が生じたか否かを判定する（Ｓ１）。例えば、アク
セス監視部１５が検出したアクセス状態が所定の上限値
又は下限値に達すると、Ｓ１では「ＹＥＳ」と判定され
る。そして、判定部１１は、サーバクラスタ４の構成変
更が必要か否かを判定し、必要な場合は、どのサービス
（ウェブサーバかアプリケーションサーバか）を追加又
は削除すべきかを判断する（Ｓ２）。追加又は削除のみ
を例示しているが、コンテンツの変更等も含まれる。

【００３７】構成判定部１３は、判定部１１による判定
結果に基づいて、サーバクラスタ４に対し構成の変更を
指示する（Ｓ３）。次に、サーバの縮退（削減）を伴う
構成変更であるか否かを判定し（Ｓ４）、サーバの縮退
を伴う場合は予閉塞処理を行う（Ｓ５）。なお、予閉塞
処理については別図と共に後述する。サーバ縮退を伴わ
ない場合は（S4:NO）、Ｓ５をスキップし、サーバ構成
監視部１４によるサーバクラスタ４の構成変更完了を確
認する（Ｓ６）。例えば、サーバ構成監視部１４は、自
らサーバクラスタ４に構成情報の送信を要求することも
できるし（ポーリング）、サーバクラスタ４側で自己の
構成情報の変化をサーバ構成監視部１４に通知すること
もできる（ＳＮＭＰトラップ）。

【００３８】サーバクラスタ４の構成変更が完了したか
否かを監視し（Ｓ７）、構成変更が確認された場合に
は、負荷分散装置２に通知して、アクセス振り分け先リ
スト３の内容を更新させる（Ｓ８）。これにより、サー
バクラスタ４の構成変更が負荷分散装置２に反映され、
追加されたサーバにもアクセスが行われる。

【００３９】以上が需要変動に対する資源の動的再構成
の概略であるが、各層別の構成変更を図４〜図６に基づ
いて説明する。

【００４０】図４は、プレゼンテーション層を担当する
ウェブサーバクラスタの構成変更の様子を示す説明図で
ある。構成変更の必要が発生すると、管理モジュール１
０は、ウェブサーバクラスタの構成変更を指示する。構
成変更とは、例えば、ウェブサーバクラスタへのウェブ
サーバ３１の追加、現在稼働中のウェブサーバ３１の削
除、コンテンツの追加又は変更あるいは削除である。

【００４１】ウェブサーバクラスタの構成変更は、サー
バ構成情報として、例えば、ＳＮＭＰトラップより管理
モジュール１０に通知される。サーバ構成情報には、例
えば、サーバＩＰアドレス、サービスポート番号、参加
クラスタグループ名等を含めることができる。管理モジ
ュール１０は、ウェブサーバクラスタから取得した構成
情報に基づいて、負荷分散装置２の設定を変更させる。
負荷分散装置２の設定変更は、例えば、telnetやＳＮＭ
Ｐセットを利用したリモート操作により行われる。ま
た、負荷分散装置２に限らず、サーバの構成変更に関係
する各種装置、例えば、内外のキャッシュサーバに対し
ても、ウェブサーバクラスタの構成変更が反映される。

【００４２】図５及び図６には、機能層４０を担当する
アプリケーションサーバ（EJBサーバと表示）クラスタ
の動的構成変更の様子が示されている。

【００４３】起動したEJBサーバ４２は、「振り分け
手段」としてのＪＮＤＩ（符号２Ａ）に登録される。
クライアント１は、サーバリストファイルに基づいて、
問い合わせるべきＪＮＤＩを決定する。クライアント
１は、ＪＮＤＩに対して利用可能なEJBサーバ４１を問
い合わせる。ＪＮＤＩは、クライアント１からの問い合
わせ要求に応じて登録内容を検索し、検索結果をクライ
アント１に返す。クライアント１は、ＪＮＤＩからの
検索結果に基づいて、呼び出すべきEJBサーバ４１を決
定する。Ａあるいは、サーバリストファイルを利用
し、振り分け先決定機構により呼び出すべきEJBサーバ
４１を決定することもできる。

【００４４】図６には、上述の流れがフローチャートと
して示されている。アプリケーションサーバクラスタに
EJBサーバ４１が追加又は削除された場合、この構成変
更は、サーバリストに反映される（Ｓ１０）。クライア
ント１は、サーバリストに基づいて問い合わせるべきＪ
ＮＤＩを決定する（Ｓ１１）。ＪＮＤＩにアクセスする
ためには、EJBサーバ経由で行う必要があるためであ
る。ＪＮＤＩは、クライアント１からの問い合わせ要求
に応じて、クラスタ内におけるEJBサーバの検索結果を
クライアント１に返す（Ｓ１２）。クライアント１は、
検索結果に基づいて呼び出すべきEJBサーバ４１を決定
し（Ｓ１３）、この選択されたEJBサーバ４１を呼び出
す（Ｓ１４）。

【００４５】次に、図７及び図８に基づいて、図３中で
Ｓ５として示された予閉塞処理の概略を説明する。図７
は、ウェブサーバ（図中「Web」と略記）における予閉
塞処理を示す。

【００４６】まず、図７（ａ）に示すように、現在仕掛
かり中のコネクションを正常に終了させる。即ち、負荷
分散装置２のアクセス振り分け先リストから、除去予定
のウェブサーバを削除した後に、この除去予定のウェブ
サーバで処理中のコネクションのレスポンスをクライア
ント「１」に返す。アクセス振り分け先リストの内容を
先に更新するため、除去予定のウェブサーバ「１」が除
去される前にクライアント「２」から新たに発生したア
クセス要求は、除去予定のウェブサーバ「１」に振り分
けられることがなく、他のウェブサーバ「２」で処理さ
れる。

【００４７】図７（ｂ）に示すように、除去予定のウェ
ブサーバ「１」で仕掛かり中のコネクションのレスポン
スを終了させ、仕掛かり中のコネクションが全て開放さ
れたことを確認した後に、該ウェブサーバ「１」を閉塞
し、サーバクラスタから削除する。除去されるウェブサ
ーバ「１」が保持しているセッション情報は、例えば、
Fail-Over機能等を利用して、他のウェブサーバ「２」
に譲渡される。なお、これに限らず、セッション情報を
メモリに格納してウェブサーバ「２」に引き継がせても
よいし、ファイル共有（NFS：Network File System）や
データベース等を利用して、除去されるウェブサーバ
「１」のセッション情報を他の稼働中のウェブサーバ
「２」に譲渡させることもできる。

【００４８】これにより、図７（ｃ）に示すように、ク
ライアント「１」で発生した新たなアクセス要求は、ウ
ェブサーバ「１」の後を引き継いだウェブサーバ「２」
により処理される。

【００４９】図８は、アプリケーションサーバ（EJBサ
ーバ）における予閉塞処理の一例を示す説明図である。
図８には、「振り分け手段」として、振り分け先決定機
構を用いた場合が示されている。

【００５０】（ａ）まず、EJBサーバ４１を呼び出すク
ライアント側「svlt：」の振り分け先決定機構の設定を
変更することにより、除去予定のEJBサーバ「１」の入
り口を閉塞し、新規なサービス要求の受け入れを停止さ
せる。新規な要求は他の稼働中のEJBサーバ「２」に振
り分けられる。なお、実行中または実行待機中の処理に
対して、それぞれ「仕掛かり中の処理待ち」を行う必要
がある。

【００５１】（ｂ）除去予定のEJBサーバ「１」で仕掛
かり中の処理、即ち、ユーザセッション継続中の処理に
ついて、全てのセッションが終了するまで、サービスを
続行させる。仕掛かり中の処理が終了するまでの間に生
じた新規なサービス要求は、除去予定のEJBサーバ
「１」では受け付けない。具体的には、管理モジュール
１０により、処理続行を保証するユーザーのリストを作
成し、保持させる。このユーザーリストにあがっている
ユーザー以外へのサービスは、除去予定のEJBサーバ
「１」では行われず、他のEJBサーバ「２」に回され
る。ユーザーリストにあがっているユーザーの仕掛かり
中の処理が全て終了するか、又はタイムアウトするまで
除去予定のEJBサーバ「１」を稼働させて待機する。

【００５２】（ｃ）必要な待機フェーズが終了した場合
は、EJBサーバを呼び出す振り分け先決定機構の設定を
変更し、閉塞されたEJBサーバ「１」の登録を削除す
る。

【００５３】このように構成される本実施の形態によれ
ば、以下の効果を奏する。

【００５４】第１に、熟練オペレータによる煩雑な手作
業を介さずに、サーバへの需要変動に応じて速やかにサ
ーバクラスタ４の構成を動的に変更することができる。
特に、サーバクラスタの構成変更の判断を自動的に行う
ため、突発的瞬間的なアクセス増大にも速やかに対応す
ることができる。

【００５５】第２に、サービスを縮小する場合には、閉
塞予定のサーバへのアクセスを予め停止させてから、仕
掛かり中の処理の完了を保証しているため、構成縮退に
伴ってサービスが一時的に中断するのを未然に防止する
ことができ、円滑に構成変更を行うことができる。

【００５６】第３に、機能層及びプレゼンテーション層
の各層毎に構成を変更可能であるため、各層毎の需要変
動に対応することができる。

【００５７】第４に、サーバ縮退時の予閉塞処理を障害
発生サーバに適用することにより、仕掛かり中のサービ
スを中断させることなく、障害が発生したサーバをクラ
スタから除去することができる。

【００５８】なお、本発明は、上述した実施の形態に限
定されない。当業者であれば、前記実施の形態に構成要
素を追加したり、削除したり、変更等したりして種々の
変形を行うことができる。

【００５９】

【発明の効果】以上説明した通り、本発明に係るクライ
アントサーバシステムによれば、需要変動に応じて、サ
ーバ側の資源配置を動的に再構成することができる。

【図面の簡単な説明】

【図１】本発明の実施の形態に係るクライアントサーバ
システムの全体構成を示すブロック図である。

【図２】ウェブサイトの階層構造を示す説明図である。

【図３】サーバクラスタの構成を動的に変化させる処理
の概略を示すフローチャートである。

【図４】プレゼンテーション層におけるウェブサーバク
ラスタの構成変更を示す説明図である。

【図５】機能層におけるアプリケーションサーバクラス
タの構成変更を示す説明図である。

【図６】アプリケーションサーバクラスタの構成変更の
概略を示すフローチャートである。

【図７】ウェブサーバの予閉塞処理を示す説明図であ
る。

【図８】アプリケーションサーバの予閉塞処理を示す説
明図である。

【符号の説明】

１クライアント２負荷分散装置３アクセス振り分け先リスト４サーバクラスタ５サーバ６予備サーバ１０管理モジュール１１判定部１２設定変更部１３構成変更部１４サーバ構成監視部１５アクセス監視部２０ネットワーク層３０プレゼンテーション層３１ウェブサーバ４０機能層４１アプリケーションサーバ

───────────────────────────────────────────────────── フロントページの続き (72)発明者塚本英昭東京都江東区豊洲三丁目３番３号株式会社エヌ・ティ・ティ・データ内 (72)発明者鴻巣淳東京都江東区豊洲三丁目３番３号株式会社エヌ・ティ・ティ・データ内Ｆターム(参考） 5B045 BB12 BB19 BB28 BB48 GG02 JJ46 5B089 GA11 GB09 JA11 KA06 MA03 MA07

Claims

【特許請求の範囲】

【請求項１】クライアントからのサービス要求を処理
するための複数のサーバを結合させてなるサーバ結合体
と、前記クライアントからのサービス要求を前記サーバ結合
体のいずれかのサーバに振り分けるための振り分け手段
と、前記サーバ結合体の構成を変更させるための構成変更手
段と、前記構成変更手段による構成変更を前記振り分け手段に
通知し、該振り分け手段の設定を変更させるための設定
変更手段と、を備えたことを特徴とするクライアントサ
ーバシステム。
【請求項２】前記サーバ結合体へのアクセス状態を監
視するためのアクセス状態監視手段と、該アクセス状態
監視手段からの通知に基づいて、前記構成変更手段によ
る構成変更の内容を決定する判定手段を更に備えた請求
項１に記載のクライアントサーバシステム。
【請求項３】前記サーバ結合体は、少なくとも機能層
及びプレゼンテーション層を備えており、前記構成変更
手段は、前記機能層及び前記プレゼンテーション層の各
層毎に構成変更が可能である請求項１または請求項２の
いずれかに記載のクライアントサーバシステム。
【請求項４】前記構成変更手段により前記サーバ結合
体の構成を縮退させる場合には、ａ．前記サーバ結合体から除去予定のサーバに対する新
規なサービス要求を拒否又は他のサーバに依頼し、ｂ．前記除去予定のサーバで仕掛かり中の処理が終了す
るのを待機し、ｃ．前記仕掛かり中の処理終了を確認した後に、前記除
去予定のサーバを前記サーバ結合体から除去させる、こ
とを特徴とする請求項１〜請求項３のいずれかに記載の
クライアントサーバシステム。
【請求項５】クライアントと、該クライアントからの
サービス要求を処理するための複数のサーバを結合させ
てなるサーバ結合体と、前記クライアントからのサービ
ス要求を前記サーバ結合体のいずれかのサーバに振り分
けるための振り分け手段とを備えたクライアントサーバ
システムに用いられる管理装置であって、前記管理装置は、前記サーバ結合体の構成を監視するためのサーバ構成監
視手段と、前記サーバ結合体の構成を変更させるための構成変更手
段と、前記構成変更手段による前記サーバ結合体の構成変更が
完了したことを前記サーバ構成監視手段により確認した
場合には、前記振り分け手段に前記サーバ結合体の構成
変更を通知して、該振り分け手段の設定を変更させるた
めの設定変更手段と、を備えていることを特徴とするク
ライアントサーバシステム用管理装置。