サービス提供システム、ファイル更新方法、および分散管理装置
【課題】サービスを中断することなくファイルの更新を行うサーバクラスタを構成するサーバに割り当てる資源の量を低減する。
【解決手段】分散処理管理装置４００の制御手段４１０は、サーバリソースプール８００から所定量の資源が割り当てられる新設クラスタのサーバ３００の一部に更新後ファイルを送信し、新設クラスタのサーバを起動させる。現用クラスタおよび新設クラスタを監視し、現用クラスタおよび新設クラスタでのトラフィック量と、稼動中のサーバ３００のＣＰＵ使用率とに基づいて算出されたリクエスト量を、稼動中の新設クラスタのサーバ３００に振り分けるという振り分けルールを作成し、ロードバランサ２００に設定させる。サーバリソースプール８００に所定量の資源を戻す現用クラスタのサーバ３００の一部を停止させる。これらの手順を繰り返し、現用クラスタから新設クラスタへの切り替えを完了する。
【解決手段】分散処理管理装置４００の制御手段４１０は、サーバリソースプール８００から所定量の資源が割り当てられる新設クラスタのサーバ３００の一部に更新後ファイルを送信し、新設クラスタのサーバを起動させる。現用クラスタおよび新設クラスタを監視し、現用クラスタおよび新設クラスタでのトラフィック量と、稼動中のサーバ３００のＣＰＵ使用率とに基づいて算出されたリクエスト量を、稼動中の新設クラスタのサーバ３００に振り分けるという振り分けルールを作成し、ロードバランサ２００に設定させる。サーバリソースプール８００に所定量の資源を戻す現用クラスタのサーバ３００の一部を停止させる。これらの手順を繰り返し、現用クラスタから新設クラスタへの切り替えを完了する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサーバからなるサーバクラスタが分散処理を行い、対向装置に所定のサービスを提供する技術に関する。
【背景技術】
【０００２】
従来、ＩＰ（Internet Protocol）電話などのサービスを提供する通信システムは、現用系のサーバと待機系のサーバの２系統を備えている。このシステムにおいて、現用系と待機系とを切り替えることで、サービスを中断することなく、各サーバのファイルを更新することができる。
【０００３】
また、複数のサーバからなるサーバクラスタを構成してＩＰ電話などのサービスを提供する形態がある。前記サーバクラスタを用いたシステムを「クラスタシステム」と称する場合がある。また、サーバクラスタを単に「クラスタ」と称する場合がある。クラスタシステムを用いることで、複数のサーバで１つのサービスを分散処理し、システムの可用性や処理性能を向上することができる。従来では、クラスタシステムにおいて、２系統分のクラスタを揃え、それぞれのクラスタを切り替えて、サービスを中断することなく、各クラスタを構成するサーバのファイルを更新する技術が存在する（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−９６１６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１の技術によれば、同程度の性能を持つ、例えば同数のサーバからなるクラスタを２系統分常備する必要があることを意味する。よって、２系統分のクラスタを構成するサーバに割り当てる資源（２倍の資源）を常に用意する必要がある。しかし、近年、サービスの提供に伴う通信のトラフィック量が増大傾向にあるなかで、それほどの資源を用意することは、システムの運用側にとって大きな負担となる。具体的には、クラスタを構成するサーバの購入コスト、および運用コストは増大し、また、サーバを設置する場所の確保が困難になる。
【０００６】
そこで、このような事情に鑑みて、本発明は、サービスを中断することなくファイルの更新を行うサーバクラスタを構成するサーバに割り当てる資源の量を低減することを目的とする。
【課題を解決するための手段】
【０００７】
前記課題を解決するため、請求項１に記載の発明は、分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと、前記第１のサーバと、前記第２のサーバと、前記ロードバランサと連携し、前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムであって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動制御と、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止制御と、前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とする。
【０００８】
請求項２に記載の発明は、請求項１に記載のサービス提供システムにおいて、前記分散処理管理装置の制御手段が、前記第２のサーバに送信した更新後ファイルのエラー監視を実行することを特徴とする。
【０００９】
請求項３に記載の発明は、分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと、前記第１のサーバと、前記第２のサーバと、前記ロードバランサと連携し、前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムにおけるファイル更新方法であって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動ステップと、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定ステップと、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止ステップと、前記起動ステップと、前記設定ステップと、前記停止ステップとを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とする。
【００１０】
請求項４に記載の発明は、分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと連携し、前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置であって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動制御と、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止制御と、前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とする。
【００１１】
請求項１、３、４に記載の発明によれば、リソースプールから新設クラスタの第２のサーバに割り当てる資源の量と、現用クラスタの第１のサーバからリソースプールへ回収する資源の量とを調整できるようにしたため、サービスを中断することなくファイルの更新を行うサーバクラスタを構成するサーバに割り当てる資源の量を低減することができる。
【００１２】
請求項２に記載の発明によれば、新設クラスタの第２のサーバを少し追加した段階で、ファイルの安全性や安定性に関するエラー監視を行うので、ファイルの更新に失敗したときの影響および対応に要する手間を低減することができる。
【発明の効果】
【００１３】
本発明によれば、サービスを中断することなくファイルの更新を行うサーバクラスタを構成するサーバに割り当てる資源の量を低減することができる。
【図面の簡単な説明】
【００１４】
【図１】本実施形態におけるサービス提供システムを含む全体図である。
【図２】現用クラスタおよび新設クラスタに対するリクエストの振り分けの例を示す図である。
【図３】分散処理管理装置における処理を示すフローチャートである。
【図４】現用クラスタおよび新設クラスタに対するリクエストの振り分けの他の例を示す図である。
【図５】現用クラスタおよび新設クラスタに対するリクエストの振り分けのさらに他の例を示す図である。
【発明を実施するための形態】
【００１５】
次に、本発明を実施するための形態（以下、「実施形態」という。）について、適宜図面を参照しながら説明する。
【００１６】
図１は、本実施形態におけるサービス提供システムを含む全体図である。サービス提供システムＳは、サーバクラスタ１００と、分散処理管理装置４００とを備える。
【００１７】
サーバクラスタ１００は、ネットワークの制御プロトコルとして、例えば、ＳＩＰ（Session Initiation Protocol）を使用するスケールアウト型のクラスタシステムである。ＳＩＰは、ＶｏＩＰ（Voice over Internet Protocol）を応用した、インターネット電話などで用いられる通話制御プロトコルの１つである。サーバクラスタ１００は、ＩＰネットワーク５００を介して接続された対向装置６００に対してサービスを提供する。本実施形態で対象とするサービスは、一般的に、呼処理制御サーバなどにおいてサービスを中断することなくファイルを更新することが期待されるサービスをいう。
【００１８】
対向装置６００は、主に、サーバ６１０や端末６２０を含む。サーバ６１０および端末６２０は、サービスを享受するために、サーバクラスタ１００に対してリクエストを送信するコンピュータである。
【００１９】
サーバクラスタ１００は、ロードバランサ２００と複数のサーバ３００とを備えて構成される。なお、本実施形態において、従来技術と比較して特徴的な構成は分散処理管理装置４００である。したがって、ロードバランサ２００とサーバ３００とについては、図示や説明を簡略化する。各サーバ３００は、例えば、ＳＩＰサーバやＨＴＴＰ（Hyper Text Transfer Protocol）サーバであり、対向装置６００に対してサービスを提供するためのアプリケーション３２０を有する。
【００２０】
ロードバランサ２００は、振り分け機能２１０を有する。振り分け機能２１０は、振り分け先制御機能２１１と状態管理機能２１２とを具備する。
【００２１】
振り分け先制御機能２１１とは、対向装置６００から受信したリクエストを各サーバ３００に振り分ける機能である。振り分け先の選択方法としては、ラウンドロビン、重み付けラウンドロビン、またはサーバ３００の負荷に応じた選択、などの方法がある。アプリケーション３２０には、１セッションにつき、複数のリクエスト（例：電話サービスに用いる継続リクエスト）を処理するものがあってもよい。ロードバランサ２００は、そのようなアプリケーション３２０を有するサーバ３００に対しては、２回目以降のリクエストも振り分けてもよい。
【００２２】
前記したアプリケーション３２０とは、例えば、ＳＩＰのＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ、またはＨＴＴＰのクッキーなどを用いたセッション管理を実現するアプリケーションである。なお、ＩＮＶＩＴＥとは、通話の開始要求を行い、セッションを開始する信号である。ＡＣＫとは、送信先コンピュータから送信元コンピュータへ送られる、データ送信が正常に終了したことを示す信号である。ＢＹＥとは、通話の終了要求を行い、セッションを終了する信号である。
【００２３】
状態管理機能２１２は、どのサーバ３００にどのリクエストを振り分けたかを表す情報を、例えばデータベースとして保持する機能である。サーバ３００に振り分けるリクエストには、そのリクエストを識別するリクエストＩＤ（IDentifier）が付されている。状態管理機能２１２は、このリクエストＩＤを保持する。前記リクエストＩＤとは、例えば、ＳＩＰ信号に含まれるセッションキーであることが好ましい。「セッションキー」とは、サービス提供システムＳが対向装置６００を認証するために発行する、ランダム値からなる鍵情報である。ロードバランサ２００は、２回目以降の信号については、この状態管理機能２１２を参照することで、適切な振り分け先のサーバ３００を特定することができる。
【００２４】
対向装置６００は、ロードバランサ２００の振り分け機能２１０が公開するＵＤＰ（User Datagram Protocol）やＴＣＰ（Transmission Control Protocol）のポートを、サーバクラスタ１００への宛先ポートとして認識する。ロードバランサ２００は、対向装置６００から送信されるＳＩＰのＩＮＶＩＴＥ、ＢＹＥなどのリクエストを受信する。そして、ロードバランサ２００の振り分け機能２１０は、そのリクエストを複数のサーバ３００に振り分ける。
【００２５】
サーバ３００は、クラスタ機能３１０によって、対向装置６００に対するサーバクラスタ１００の機能を実現する。クラスタ機能３１０は、アプリケーション３２０に対して、対向装置６００に信号を返すための手段やセッションデータへのアクセス手段を提供する。ここでの手段とは、例えば、ＨＴＴＰ ＳｅｒｖｌｅｔやＳＩＰ ＳｅｒｖｌｅｔのようなＡＰＩ(Application Program Interface)のことである。「セッションデータ」とは、複数のリクエストによって更新される状態データであり、対向装置６００のユーザのサービスの利用状況やリクエストＩＤなどを含む。前記状態データが示す状態とは、例えばＩＰ電話における通話状態などが該当する。
【００２６】
対向装置６００とサーバクラスタ１００とが信号を送受信する場合、実際にアプリケーション３２０の処理を実行しているのは分散されたサーバ３００である。しかし、対向装置６００からすると、ロードバランサ２００上の振り分け機能２１０と信号をやりとりしているように見える。つまり、サーバクラスタ１００において、内部サーバ構成が隠蔽される。クラスタ機能３１０は、そのような隠蔽を実現するために、トランスポート層転送機能３１１およびセッション管理機能３１２を有する。
【００２７】
トランスポート層転送機能３１１は、各サーバ３００上のアプリケーション３２０から対向装置６００宛てへの信号を、サーバクラスタ１００が実現するトランスポート層を経由して転送する機能である。各サーバ３００上のアプリケーション３２０から信号を直接的に対向装置６００へ送信するわけではないので、対向装置６００は、受信した信号の送信元を知り得ない。
【００２８】
セッション管理機能３１２は、アプリケーション３２０に、リクエストＩＤのみでセッションデータにアクセスさせる機能である。実際のセッションデータは、分散されたサーバ３００またはデータベースのような外部装置（不図示）で管理されている。セッション管理機能３１２は、（リクエストＩＤを除いて）そのようなセッションデータの所在やアクセス手段を、アプリケーション３２０に意識させない。なお、前記セッションデータの所在とは、例えば、ＩＰアドレスまたはメモリアドレスである。また、前記アクセス手段とは、例えば、ＳＱＬ（Structured Query Language）送信である。
【００２９】
これらのクラスタ機能３１０を実現するＡＰＩにより、アプリケーション３２０は、分散処理されていることを意識せずにアプリケーション処理を実行できる。また、複数のサーバ３００においてクラスタ機能３１０がクラスタメンバシップを構成し、ロードバランサ２００の振り分け機能２１０がそれらのサーバ３００にリクエストを振り分けることにより、サーバ３００を追加（増設）すれば、サーバクラスタ１００の処理能力を向上させることができる。
【００３０】
サーバリソースプール８００は、サーバ３００に動的に割り当てる資源を蓄えている。サーバリソースプール８００は、起動することが決定したサーバ３００に対して資源を割り当て、停止することが決定したサーバ３００に割り当てていた資源を回収する。サーバリソースプール８００は、例えば、サービス提供システムＳの設置場所とは離れたデータセンタなどに設置された計算機の処理により構成される。
【００３１】
分散処理管理装置４００は、ロードバランサ２００の振り分け機能２１０と、クラスタ機能３１０とを連携制御する。分散処理管理装置４００は、この連携制御により、サーバクラスタ１００が提供するサービスを中断することなく、サーバ３００のファイルを更新することができる。
【００３２】
分散処理管理装置４００は、コンピュータ装置であり、制御手段４１０、記憶手段４２０、通信手段４３０、入力手段４４０および出力手段４５０、といったハードウェアを備える。
【００３３】
制御手段４１０は、例えばＣＰＵ（Central Processing Unit）とメモリによって構成され、ファイル送信部４１１、サーバクラスタ起動部４１２、振り分けルール設定部４１３、通信状態監視部４１４、エラー監視部４１５およびサーバクラスタ停止部４１６といったソフトウェアを実現する。
【００３４】
記憶手段４２０は、ＨＤＤ（Hard Disk Drive）などから構成され、ロードバランサ２００の振り分け機能２１０とクラスタ機能３１０を連携制御するために必要な各種情報を記憶する。
【００３５】
通信手段４３０は、ロードバランサ２００やクラスタ機能３１０と通信するための通信インタフェースや通信ポートから構成される。
【００３６】
入力手段４４０は、分散処理管理装置４００を操作するオペレータが情報を入力する手段であり、例えばキーボードやマウスなどから構成される。
なお、オペレータは、分散処理管理装置４００が接続している保守ネットワーク７００と接続している管理コンソール（不図示）を用いて情報を入力することもできる。
【００３７】
出力手段４５０は、情報を出力する手段であり、例えば、液晶表示機やスピーカなどから構成される。
【００３８】
ファイル送信部４１１は、サーバ３００がサーバクラスタ１００を構成し、サービスを提供するために必要なデータがまとめられているファイルをサーバ３００に送信する。
【００３９】
サーバクラスタ起動部４１２は、ファイルを受信したサーバ３００に対し、そのサーバ３００が属するサーバクラスタ１００として起動するように指示する。サーバ３００は、その指示を受信すると、ファイルの読み込み処理を行い、起動する。
【００４０】
振り分けルール設定部４１３は、ロードバランサ２００に対して、振り分けルールを設定する。振り分けルールとは、ロードバランサ２００の振り分け機能２１０が、対向装置６００から受信したリクエストをどのサーバ３００にどの程度振り分けるかを定めた内容である。
【００４１】
通信状態監視部４１４は、サーバクラスタ１００の通信状態を監視する。具体的には、サーバクラスタ１００のトラフィック量（リクエスト量）を集計したり、サーバ３００のＣＰＵ使用率を計測したりなどする。振り分けルール設定部４１３は、その集計や計測の結果に基づいて、サーバ３００に振り分けるリクエストの種類または量などを決定し、振り分けルールを作成する。
【００４２】
エラー監視部４１５は、ファイル送信部４１１が送信したファイルの安全性や安定性を監視する。具体的には、そのファイルで起動したサーバ３００の処理動作を監視し、処理動作が正常であるか否かを判定する。分散処理管理装置４００は、処理動作にエラーがあると判定した場合は、そのサーバ３００に対して動作の停止を指示する。
【００４３】
サーバクラスタ停止部４１６は、対象となるサーバクラスタ１００を構成するサーバ３００に対して停止するように指示する。サーバ３００は、その指示を受信すると、停止に必要な処理を実行し、サーバ３００に割り当てられていた資源を、割り当てが不要になったため、サーバリソースプール８００に戻す。
【００４４】
ここで、対向装置６００にサービスを提供中のサーバクラスタ１００である現用クラスタを、新たなサーバクラスタ１００である新設クラスタに切り替える場合を考える。従来技術の方法によると、サービスを継続するためには、現用クラスタから新設クラスタへの処理の引き継ぎが完了した後に、現用クラスタを停止する必要があった。この引き継ぎには、例えば、新設クラスタのサーバへのファイルの送信、新設クラスタのサーバの起動、現用クラスタから新設クラスタへのセッションデータの移行などが含まれる。
また、一般的には、新設クラスタのサーバに送信したファイル（更新後ファイル）は、現用クラスタのサーバに送信したファイル（更新前ファイル）を更新したものである。このため、更新後のファイルに基づいてサービスを提供する新設クラスタのサーバにリクエストが振り分けられる傾向がある。しかし、サービスを継続するためには、現用クラスタのサーバを停止するわけにはいかない。よって、現用クラスタと新設クラスタとが同時に稼動している期間が存在する。
【００４５】
また、処理を引き継ぐため、新設クラスタには、現用クラスタと同程度の性能が求められる。よって、サーバリソースプール８００から新設クラスタのサーバ３００に割り当てる資源の量は、現用クラスタのサーバ３００に割り当てていた資源の量と同程度にする必要がある。したがって、現用クラスタと新設クラスタとが併存したサーバクラスタ１００に対して、現用クラスタのみでサービスを提供していたときと比べて２倍の資源を割り当てる必要がある期間が存在する。しかし、それほど多くの資源を確保することは、サービス提供システムＳの運用上大きな負担となる。
【００４６】
本実施形態は、新設クラスタのサーバ３００がサービスを提供しつつも、一時的ではあるが、現用クラスタのサーバ３００によるサービスの提供を許容する。このことにより、現用クラスタと新設クラスタとが併存したサーバクラスタ１００に対して、２倍の資源を割り当てないように済ませる。
【００４７】
図２は、現用クラスタおよび新設クラスタに対するリクエストの振り分けの例を示す図である。元々は、ロードバランサ２００は、現用クラスタのサーバ３００（第１のサーバ）に対向装置６００からのリクエストを振り分けていた。ここで、すでに所定台数分用意されている新設クラスタのサーバ３００（第２のサーバ）の一部に対し、ファイルを送信し、サーバリソースプール８００から資源を割り当て、そのサーバ３００を起動する。ロードバランサ２００は、起動した新設クラスタのサーバ３００に対してリクエストを振り分け始めるが、現用クラスタのサーバ３００へのリクエストの振り分けも継続する。
【００４８】
その後、所定の時間をかけて、起動する新設クラスタのサーバ３００の数を徐々に増やしつつ、停止する現用クラスタのサーバ３００の数も徐々に増やすという調整をおこなう。この調整中、徐々に増える稼動中の新設クラスタのサーバ３００には、より多くのリクエストが振り分けられる。この調整は、新設クラスタのすべてのサーバ３００を起動し、現用クラスタのすべてのサーバ３００を停止するまで続ける。このような手順を踏むことで、現用クラスタから新設クラスタへの切り替えに要する期間を含むいかなる期間においても、現用クラスタのサーバ３００に割り当てる資源の量と新設クラスタのサーバ３００に割り当てる資源の量との合計は、前記した２倍の資源の量を下回る。
【００４９】
次に、図２に示したリクエストの振り分けを実現するための分散処理管理装置４００の処理について説明する。
図３は、分散処理管理装置における処理を示すフローチャートである。この処理の主体は、制御手段４１０である。この処理は、ステップＳ０１から開始する。
【００５０】
ステップＳ０１において、制御手段４１０は、サーバクラスタ１００において、新設クラスタのサーバ３００を登録する。登録されるサーバ３００は、新設クラスタを構成するすべてのサーバ３００の一部ではあるが、一般的には複数である。新設クラスタのサーバ３００を登録する数は、オペレータによる入力手段４４０の操作により、決定してもよいし、分散処理管理装置４００が所定のアルゴリズムを用いて決定してもよい。記憶手段４２０が記憶するデータベースには、対象となる新設クラスタのサーバ３００に関するレコードが書き込まれる。また、この登録により、分散処理管理装置４００は、登録した新設クラスタのサーバ３００を、ロードバランサ２００によるリクエストの振り分け先として設定する。ステップＳ０１の後、ステップＳ０２に進む。
【００５１】
ステップＳ０２において、制御手段４１０は、ファイル送信部４１１を用いて、新設クラスタのサーバ３００に対してファイルを送信する。ここで、送信するファイルは、現用クラスタのサーバ３００に送信したファイルを更新したファイルである。ファイル送信部４１１によるファイルの送信は、例えば、オペレータによる入力手段４４０の操作があって行ってもよいし、ステップＳ０１の処理の完了後、自動的に行ってもよい。ステップＳ０２の後、ステップＳ０３に進む。
【００５２】
ステップＳ０３において、制御手段４１０は、サーバクラスタ起動部４１２を用いて、新設クラスタのサーバ３００に対して、送信したファイルを用いて起動するように指示する。新設クラスタのサーバ３００は、この指示により、サーバリソースプール８００から資源を取得して、起動する。ステップＳ０３の後、ステップＳ０４に進む。
【００５３】
ステップＳ０４において、制御手段４１０は、振り分けルール設定部４１３を用いて、ロードバランサ２００に対して、稼動中のサーバ３００のいずれかにどの程度の量のリクエストを振り分けるかを定めた振り分けルールを設定する。このとき、制御手段４１０は、通信状態監視部４１４を用いてサーバクラスタ１００の通信状態を監視しており、その通信状態に基づいて、起動した新設クラスタのサーバ３００に振り分ける最適な割合となるリクエスト量を算出する。
【００５４】
前記「最適な割合」とは、例えば、通信状態監視部４１４により集計したトラフィック量や、計測したすべての（稼動中の）サーバ３００のＣＰＵ使用率に基づいて算出することが好ましい。このとき、算出した最適な割合となるリクエストをサーバ３００に振り分けるといった振り分けルールを作成する。
【００５５】
また、前記「最適な割合」とは、例えば、新設クラスタのサーバ３００の処理能力で（所定時間を超える遅延が無く）処理できるリクエストの最大量であることが好ましい。例えば、１リクエストあたりの処理負荷が均一（例：５ＣＰＵ利用単位）であったと仮定し、新設クラスタのサーバ３００は、１００ＣＰＵ単位で処理を行う能力を有しているとする。このとき、２０（＝１００／５）リクエストをそのサーバ３００に振り分ける、といった振り分けルールを作成する。
【００５６】
この「最適な割合」は、オペレータが決定して、入力手段４４０の操作により入力してもよい。また、分散処理管理装置４００が専用のアルゴリズムを用いて自動的に算出してもよい。
【００５７】
振り分けルール設定部４１３は、少なくともリクエストＩＤと、そのリクエストＩＤで識別されるリクエストの振り分け先とを対応付けたリストの形式で振り分けルールを作成する。前記リストの振り分け先には、サーバ３００と、そのサーバ３００が属するクラスタとが登録される。記憶手段４２０は、作成した振り分けルールを記憶する。
【００５８】
ステップＳ０４では、振り分けルール設定部４１３が、現用クラスタのサーバ３００、およびそのサーバ３００に振り分けられるリクエストのリクエストＩＤを定めるだけでなく、ステップＳ０１で登録した新設クラスタのサーバ３００、およびそのサーバ３００に振り分けられるリクエストのリクエストＩＤも定めた振り分けルールを作成する。そして、作成した振り分けルールを、ロードバランサ２００に送信する。ロードバランサ２００はその振り分けルールに基づいてリクエストを振り分ける。ステップＳ０４の後、ステップＳ０５に進む。
【００５９】
ステップＳ０５において、制御手段４１０は、エラー監視部４１５を用いて、稼動中の新設クラスタのサーバ３００に送信したファイルの安全性や安定性に関するエラー監視を行う。エラー監視は所定の監視期間に亘って行う。もし、稼動中の新設クラスタのサーバ３００のエラー発生を検知した場合、新設クラスタでの処理を中止し、新設クラスタに振り分けていたリクエストは、現用クラスタに振り分ける。このような対応を行うため、監視期間中は、現用クラスタのサーバ３００は停止しない。エラー発生を検知しなかった場合、ステップＳ０５の後、ステップＳ０６に進む。
【００６０】
ステップＳ０６において、制御手段４１０は、サーバクラスタ１００において、新設クラスタのサーバ３００を追加登録する。ステップＳ０６の処理は、基本的には、ステップＳ０１の処理と同様である。ステップＳ０６の処理により、起動する新設クラスタのサーバ３００の数を徐々に増やす。ステップＳ０６の後、ステップＳ０７に進む。
【００６１】
ステップＳ０７において、制御手段４１０は、ファイル送信部４１１を用いて、追加分の新設クラスタのサーバ３００に対してファイルを送信する。ステップＳ０７の後、ステップＳ０８に進む。
【００６２】
ステップＳ０８において、制御手段４１０は、サーバクラスタ起動部４１２を用いて、追加分の新設クラスタのサーバ３００に対して、送信したファイルを用いて起動するように指示する。追加分の新設クラスタのサーバ３００は、この指示により、サーバリソースプール８００から資源を取得して、起動する。ステップＳ０８の後、ステップＳ０９に進む。
【００６３】
ステップＳ０９において、制御手段４１０は、振り分けルール設定部４１３を用いて、ロードバランサ２００に対して、稼動中のサーバ３００のいずれかにどの程度の量のリクエストを振り分けるかを定めた振り分けルールを設定する。ステップＳ０９の処理は、基本的には、ステップＳ０４の処理と同様であり、起動した新設クラスタのサーバ３００に振り分ける最適な割合となるリクエスト量を新たに算出する。
【００６４】
ステップＳ０９では、振り分けルール設定部４１３が、ステップＳ０６で追加登録した新設クラスタのサーバ３００、およびそのサーバ３００に振り分けられるリクエストのリクエストＩＤも定めた振り分けルールを作成する。そして、作成した振り分けルールを、ロードバランサ２００に送信する。ステップＳ０９の後、ステップＳ１０に進む。
【００６５】
ステップＳ１０において、制御手段４１０は、サーバクラスタ停止部４１６を用いて、現用クラスタのサーバ３００の一部に対して、停止するように指示する。停止することになる現用クラスタのサーバ３００は、この指示により、サーバリソースプール８００へ資源を戻し、最終的には停止する。なお、停止することになる現用クラスタのサーバ３００は、自身に振り分けられるリクエストに対応するセッションデータを、そのリクエストの新しい振り分け先となるサーバ３００に移行する。新しい振り分け先となるサーバ３００は、後記するステップＳ１１で設定した振り分けルールに従って決定される。新しい振り分け先となるサーバ３００は、まだ稼動中の現用クラスタのサーバ３００でもよいが、新設クラスタのサーバ３００であることが好ましい。ステップＳ１０の後、ステップＳ１１に進む。
【００６６】
ステップＳ１１において、制御手段４１０は、振り分けルール設定部４１３を用いて、ロードバランサ２００に対して、稼動中のサーバ３００のいずれかにどの程度の量のリクエストを振り分けるかを定めた振り分けルールを設定する。ステップＳ１１の処理は、基本的には、ステップＳ０４の処理と同様であり、起動した新設クラスタのサーバ３００に振り分ける最適な割合となるリクエスト量を新たに算出する。
【００６７】
ステップＳ１１では、振り分けルール設定部４１３が、ステップＳ１０で停止が決定した現用クラスタのサーバ３００を除外して、振り分けルールを作成する。また、除外したサーバ３００に対応付けられていたリクエストＩＤは、残りのサーバ３００に対応付けられる。そして、作成した振り分けルールを、ロードバランサ２００に送信する。ステップＳ１１の後、ステップＳ１２に進む。
【００６８】
ステップＳ１２において、制御手段４１０は、現用クラスタのすべてのサーバが停止したか否か判定する。すべて停止した場合は（ステップＳ１１でＹｅｓ）、図３の処理全体を終了する。このことは、現用クラスタから新設クラスタへの切り替えが完了したことを意味する。一方、すべて停止しない場合は（ステップＳ１１でＮｏ）、ステップＳ０６に戻る。このことは、稼動中の現用クラスタの残りのサーバ３００を徐々に停止していくことを意味する。
【００６９】
このような処理を実行することにより、サービスを中断することなくファイルの更新を行うサーバクラスタ１００を構成するサーバ３００に割り当てる資源の量を低減することができる。リソースプールから新設クラスタのサーバ３００に割り当てる資源の量と、現用クラスタのサーバ３００からリソースプールへ回収する資源の量とを調整できるようにしたためである。
【００７０】
また、サーバクラスタ１００に振り分けられるリクエストの量に関係なく、新設クラスタのサーバ３００に割り当てる資源の量を調整することができる。
【００７１】
また、新設クラスタのサーバ３００を少し追加した段階で、ファイルの安全性や安定性に関するエラー監視を行うので（図３のステップＳ０５）、ファイルの更新に失敗したときの影響および対応に要する手間を低減することができる。
【００７２】
ステップＳ０４で説明した「最適な割合」は、対向装置６００を用いるユーザのユーザＩＤを基準にして決定することもできる。つまり、ユーザＩＤについて、リクエストを振り分けるための所定のグループ（振り分け単位）を決定し、どのグループに対応するサーバ３００にどのリクエストを振り分けるかを決定することができる。ユーザＩＤは、サービス提供システムＳの利用に関する認証結果が正当であるユーザごとに固有のランダム値である。そして、前記グループは、前記ランダム値がとり得る全範囲の一部に相当する。
【００７３】
振り分けルール設定部４１３は、例えば、少なくともユーザＩＤと、そのユーザＩＤが属するグループとを対応付けたリストの形式で振り分けルールを作成する。もし、１度に大量のリクエストを新設クラスタのサーバ３００に振り分けることができる場合には、新設クラスタのサーバ３００に対応するグループを多数指定することで前記「最適な割合」を実現することができる。また、１度に少量のリクエストしか新設クラスタのサーバ３００に振り分けることができない場合には、新設クラスタのサーバ３００に対応するグループを少数指定することで前記「最適な割合」を実現することができる。
【００７４】
また、ユーザＩＤの代わりに、ランダム値をとるリクエストＩＤを基準にして、上記と同様のやり方で、「最適な割合」を決定することもできる。
【００７５】
（第１の変形例）
これまでの説明は、ロードバランサ２００が新設クラスタのサーバ３００と現用クラスタのサーバ３００とに所定の割合でリクエストを振り分ける技術に関するものであった（図２参照）。しかし、ロードバランサ２００がすべてのリクエストを新設クラスタのサーバ３００に振り分け、新設クラスタのサーバ３００から現用クラスタのサーバ３００にリクエストを振り分ける、という方法をとってもよい。
【００７６】
図４は、現用クラスタおよび新設クラスタに対するリクエストの振り分けの他の例を示す図である。現用クラスタのサーバ３００に対し、最小規模の新設クラスタのサーバ３００を導入し、サーバリソースプール８００から資源を割り当てる。この段階で、ロードバランサ２００は、対向装置６００からのリクエストをすべて新設クラスタのサーバ３００に振り分ける。新設クラスタのサーバ３００は、振り分けられたリクエストの一部を処理し、残りを現用クラスタのサーバ３００に振り分けて処理させる。新設クラスタのサーバ３００が処理するリクエスト量は、例えば、図２のステップＳ０４の処理に倣って、「最適な割合」となるリクエスト量とすることが好ましい。
【００７７】
分散処理管理装置４００は、振り分けルール設定部４１３を用いて、新設クラスタのサーバ３００が処理するリクエストのリクエストＩＤと、現用クラスタのサーバ３００が処理するリクエストのリクエストＩＤとをまとめた振り分けルールを作成する。この振り分けルールには、ロードバランサ２００がすべてのリクエストを新設クラスタのサーバ３００に振り分けるという内容も記述されている。作成した振り分けルールは、ロードバランサ２００および新設クラスタのサーバ３００に送信して、設定される。
【００７８】
その後、図３のステップＳ０６〜ステップＳ１２の処理に倣って、ロードバランサ２００が、すべてのリクエストを新設クラスタのサーバ３００に振り分けつつも、新設クラスタを徐々に追加し、現用クラスタを徐々に停止し、現用クラスタから新設クラスタへの切り替えを実現する。
【００７９】
このような方法を行うことで、図２で示した方法と比べて、ロードバランサ２００が行う解析の負荷を低減することができる。つまり、図２で示した方法によれば、ロードバランサ２００は、リクエストを振り分けるサーバ３００が属するクラスタが現用クラスタであるか新設クラスタであるかを解析する必要があった。しかし、図４で示した方法によれば、ロードバランサ２００からの振り分け先は新設クラスタだけであるため、クラスタを区別するための解析は不要となる。
【００８０】
（第２の変形例）
前記した方法とはさらに異なり、ロードバランサ２００がすべてのリクエストを現用クラスタのサーバ３００に振り分け、現用クラスタのサーバ３００から新設クラスタのサーバ３００にリクエストを振り分ける、という方法をとってもよい。
【００８１】
図５は、現用クラスタおよび新設クラスタに対するリクエストの振り分けのさらに他の例を示す図である。現用クラスタのサーバ３００に対し、最小規模の新設クラスタのサーバ３００を導入し、サーバリソースプール８００から資源を割り当てる。この段階で、ロードバランサ２００は、対向装置６００からのリクエストをすべて現用クラスタのサーバ３００に振り分ける。現用クラスタのサーバ３００は、振り分けられたリクエストの一部を処理し、残りを新設クラスタのサーバ３００に振り分けて処理させる。新設クラスタのサーバ３００が処理するリクエスト量は、例えば、図２のステップＳ０４の処理に倣って、「最適な割合」となるリクエスト量とすることが好ましい。
【００８２】
分散処理管理装置４００は、振り分けルール設定部４１３を用いて、新設クラスタのサーバ３００が処理するリクエストのリクエストＩＤと、現用クラスタのサーバ３００が処理するリクエストのリクエストＩＤとをまとめた振り分けルールを作成する。この振り分けルールには、ロードバランサ２００がすべてのリクエストを現用クラスタのサーバ３００に振り分けるという内容も記述されている。作成した振り分けルールは、ロードバランサ２００および現用クラスタのサーバ３００に送信して、設定される。
【００８３】
その後、図３のステップＳ０６〜ステップＳ１２の処理に倣って、ロードバランサ２００が、すべてのリクエストを現用クラスタのサーバ３００に振り分けつつも、新設クラスタを徐々に追加し、現用クラスタを徐々に停止し、現用クラスタから新設クラスタへの切り替えを実現する。
【００８４】
このような方法を行うことで、図４で示した方法と同様、ロードバランサ２００が行う解析の負荷を低減することができる。つまり、図５で示した方法によれば、ロードバランサ２００からの振り分け先は現用クラスタだけであるため、クラスタを区別するための解析は不要となる。
【００８５】
（その他）
前記実施形態は、本発明を実施するために好適のものであるが、その実施形式はこれらに限定されるものでなく、本発明の要旨を変更しない範囲内において種々変形することが可能である。
【００８６】
例えば、本実施形態では、ロードバランサ２００と分散処理管理装置４００は、別筐体としているが、同一筐体としてもよい。したがって、分散処理管理装置４００の通信状態監視部４１４が行ったトラフィック量の集計や、サーバ３００のＣＰＵ使用率の計測は、ロードバランサ２００が行ってもよい。
【００８７】
また、ロードバランサ２００が故障した場合に備えて、ホットスタンバイ状態の別のロードバランサを用意しておいてもよい。ロードバランサ２００の障害時には瞬時にその別のロードバランサに切り替えれば、ロードバランサ２００の障害による影響を最小限に抑えることができる。
【００８８】
また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
また、本実施形態で説明したソフトウェアは、ハードウェアとして実現することもでき、ハードウェアは、ソフトウェアとして実現することもできる。したがって、例えば、分散処理管理装置４００の通信状態監視部４１４が行ったトラフィック量の集計や、サーバ３００のＣＰＵ使用率の計測は、ハードウェアによる処理として実現することができる。
【００８９】
その他、ハードウェア、ソフトウェア、フローチャートなどの具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００９０】
１００ サーバクラスタ
２００ ロードバランサ
２１０ 振り分け機能
２１１ 振り分け先制御機能
２１２ 状態管理機能
３００ サーバ（第１のサーバ、第２のサーバ）
３１０ クラスタ機能
３１１ トランスポート層転送機能
３１２ セッション管理機能
３２０ アプリケーション
４００ 分散処理管理装置
４１０ 制御手段
４１１ ファイル送信部
４１２ サーバクラスタ起動部
４１３ 振り分けルール設定部
４１４ 通信状態監視部
４１５ エラー監視部
４１６ サーバクラスタ停止部
４２０ 記憶手段
４３０ 通信手段
４４０ 入力手段
４５０ 出力手段
５００ ＩＰネットワーク
６００ 対向装置
６１０ サーバ
６２０ 端末
７００ 保守ネットワーク
８００ サーバリソースプール
Ｓ サービス提供システム
【技術分野】
【０００１】
本発明は、複数のサーバからなるサーバクラスタが分散処理を行い、対向装置に所定のサービスを提供する技術に関する。
【背景技術】
【０００２】
従来、ＩＰ（Internet Protocol）電話などのサービスを提供する通信システムは、現用系のサーバと待機系のサーバの２系統を備えている。このシステムにおいて、現用系と待機系とを切り替えることで、サービスを中断することなく、各サーバのファイルを更新することができる。
【０００３】
また、複数のサーバからなるサーバクラスタを構成してＩＰ電話などのサービスを提供する形態がある。前記サーバクラスタを用いたシステムを「クラスタシステム」と称する場合がある。また、サーバクラスタを単に「クラスタ」と称する場合がある。クラスタシステムを用いることで、複数のサーバで１つのサービスを分散処理し、システムの可用性や処理性能を向上することができる。従来では、クラスタシステムにおいて、２系統分のクラスタを揃え、それぞれのクラスタを切り替えて、サービスを中断することなく、各クラスタを構成するサーバのファイルを更新する技術が存在する（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−９６１６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１の技術によれば、同程度の性能を持つ、例えば同数のサーバからなるクラスタを２系統分常備する必要があることを意味する。よって、２系統分のクラスタを構成するサーバに割り当てる資源（２倍の資源）を常に用意する必要がある。しかし、近年、サービスの提供に伴う通信のトラフィック量が増大傾向にあるなかで、それほどの資源を用意することは、システムの運用側にとって大きな負担となる。具体的には、クラスタを構成するサーバの購入コスト、および運用コストは増大し、また、サーバを設置する場所の確保が困難になる。
【０００６】
そこで、このような事情に鑑みて、本発明は、サービスを中断することなくファイルの更新を行うサーバクラスタを構成するサーバに割り当てる資源の量を低減することを目的とする。
【課題を解決するための手段】
【０００７】
前記課題を解決するため、請求項１に記載の発明は、分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと、前記第１のサーバと、前記第２のサーバと、前記ロードバランサと連携し、前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムであって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動制御と、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止制御と、前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とする。
【０００８】
請求項２に記載の発明は、請求項１に記載のサービス提供システムにおいて、前記分散処理管理装置の制御手段が、前記第２のサーバに送信した更新後ファイルのエラー監視を実行することを特徴とする。
【０００９】
請求項３に記載の発明は、分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと、前記第１のサーバと、前記第２のサーバと、前記ロードバランサと連携し、前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムにおけるファイル更新方法であって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動ステップと、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定ステップと、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止ステップと、前記起動ステップと、前記設定ステップと、前記停止ステップとを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とする。
【００１０】
請求項４に記載の発明は、分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと連携し、前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置であって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動制御と、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止制御と、前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とする。
【００１１】
請求項１、３、４に記載の発明によれば、リソースプールから新設クラスタの第２のサーバに割り当てる資源の量と、現用クラスタの第１のサーバからリソースプールへ回収する資源の量とを調整できるようにしたため、サービスを中断することなくファイルの更新を行うサーバクラスタを構成するサーバに割り当てる資源の量を低減することができる。
【００１２】
請求項２に記載の発明によれば、新設クラスタの第２のサーバを少し追加した段階で、ファイルの安全性や安定性に関するエラー監視を行うので、ファイルの更新に失敗したときの影響および対応に要する手間を低減することができる。
【発明の効果】
【００１３】
本発明によれば、サービスを中断することなくファイルの更新を行うサーバクラスタを構成するサーバに割り当てる資源の量を低減することができる。
【図面の簡単な説明】
【００１４】
【図１】本実施形態におけるサービス提供システムを含む全体図である。
【図２】現用クラスタおよび新設クラスタに対するリクエストの振り分けの例を示す図である。
【図３】分散処理管理装置における処理を示すフローチャートである。
【図４】現用クラスタおよび新設クラスタに対するリクエストの振り分けの他の例を示す図である。
【図５】現用クラスタおよび新設クラスタに対するリクエストの振り分けのさらに他の例を示す図である。
【発明を実施するための形態】
【００１５】
次に、本発明を実施するための形態（以下、「実施形態」という。）について、適宜図面を参照しながら説明する。
【００１６】
図１は、本実施形態におけるサービス提供システムを含む全体図である。サービス提供システムＳは、サーバクラスタ１００と、分散処理管理装置４００とを備える。
【００１７】
サーバクラスタ１００は、ネットワークの制御プロトコルとして、例えば、ＳＩＰ（Session Initiation Protocol）を使用するスケールアウト型のクラスタシステムである。ＳＩＰは、ＶｏＩＰ（Voice over Internet Protocol）を応用した、インターネット電話などで用いられる通話制御プロトコルの１つである。サーバクラスタ１００は、ＩＰネットワーク５００を介して接続された対向装置６００に対してサービスを提供する。本実施形態で対象とするサービスは、一般的に、呼処理制御サーバなどにおいてサービスを中断することなくファイルを更新することが期待されるサービスをいう。
【００１８】
対向装置６００は、主に、サーバ６１０や端末６２０を含む。サーバ６１０および端末６２０は、サービスを享受するために、サーバクラスタ１００に対してリクエストを送信するコンピュータである。
【００１９】
サーバクラスタ１００は、ロードバランサ２００と複数のサーバ３００とを備えて構成される。なお、本実施形態において、従来技術と比較して特徴的な構成は分散処理管理装置４００である。したがって、ロードバランサ２００とサーバ３００とについては、図示や説明を簡略化する。各サーバ３００は、例えば、ＳＩＰサーバやＨＴＴＰ（Hyper Text Transfer Protocol）サーバであり、対向装置６００に対してサービスを提供するためのアプリケーション３２０を有する。
【００２０】
ロードバランサ２００は、振り分け機能２１０を有する。振り分け機能２１０は、振り分け先制御機能２１１と状態管理機能２１２とを具備する。
【００２１】
振り分け先制御機能２１１とは、対向装置６００から受信したリクエストを各サーバ３００に振り分ける機能である。振り分け先の選択方法としては、ラウンドロビン、重み付けラウンドロビン、またはサーバ３００の負荷に応じた選択、などの方法がある。アプリケーション３２０には、１セッションにつき、複数のリクエスト（例：電話サービスに用いる継続リクエスト）を処理するものがあってもよい。ロードバランサ２００は、そのようなアプリケーション３２０を有するサーバ３００に対しては、２回目以降のリクエストも振り分けてもよい。
【００２２】
前記したアプリケーション３２０とは、例えば、ＳＩＰのＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ、またはＨＴＴＰのクッキーなどを用いたセッション管理を実現するアプリケーションである。なお、ＩＮＶＩＴＥとは、通話の開始要求を行い、セッションを開始する信号である。ＡＣＫとは、送信先コンピュータから送信元コンピュータへ送られる、データ送信が正常に終了したことを示す信号である。ＢＹＥとは、通話の終了要求を行い、セッションを終了する信号である。
【００２３】
状態管理機能２１２は、どのサーバ３００にどのリクエストを振り分けたかを表す情報を、例えばデータベースとして保持する機能である。サーバ３００に振り分けるリクエストには、そのリクエストを識別するリクエストＩＤ（IDentifier）が付されている。状態管理機能２１２は、このリクエストＩＤを保持する。前記リクエストＩＤとは、例えば、ＳＩＰ信号に含まれるセッションキーであることが好ましい。「セッションキー」とは、サービス提供システムＳが対向装置６００を認証するために発行する、ランダム値からなる鍵情報である。ロードバランサ２００は、２回目以降の信号については、この状態管理機能２１２を参照することで、適切な振り分け先のサーバ３００を特定することができる。
【００２４】
対向装置６００は、ロードバランサ２００の振り分け機能２１０が公開するＵＤＰ（User Datagram Protocol）やＴＣＰ（Transmission Control Protocol）のポートを、サーバクラスタ１００への宛先ポートとして認識する。ロードバランサ２００は、対向装置６００から送信されるＳＩＰのＩＮＶＩＴＥ、ＢＹＥなどのリクエストを受信する。そして、ロードバランサ２００の振り分け機能２１０は、そのリクエストを複数のサーバ３００に振り分ける。
【００２５】
サーバ３００は、クラスタ機能３１０によって、対向装置６００に対するサーバクラスタ１００の機能を実現する。クラスタ機能３１０は、アプリケーション３２０に対して、対向装置６００に信号を返すための手段やセッションデータへのアクセス手段を提供する。ここでの手段とは、例えば、ＨＴＴＰ ＳｅｒｖｌｅｔやＳＩＰ ＳｅｒｖｌｅｔのようなＡＰＩ(Application Program Interface)のことである。「セッションデータ」とは、複数のリクエストによって更新される状態データであり、対向装置６００のユーザのサービスの利用状況やリクエストＩＤなどを含む。前記状態データが示す状態とは、例えばＩＰ電話における通話状態などが該当する。
【００２６】
対向装置６００とサーバクラスタ１００とが信号を送受信する場合、実際にアプリケーション３２０の処理を実行しているのは分散されたサーバ３００である。しかし、対向装置６００からすると、ロードバランサ２００上の振り分け機能２１０と信号をやりとりしているように見える。つまり、サーバクラスタ１００において、内部サーバ構成が隠蔽される。クラスタ機能３１０は、そのような隠蔽を実現するために、トランスポート層転送機能３１１およびセッション管理機能３１２を有する。
【００２７】
トランスポート層転送機能３１１は、各サーバ３００上のアプリケーション３２０から対向装置６００宛てへの信号を、サーバクラスタ１００が実現するトランスポート層を経由して転送する機能である。各サーバ３００上のアプリケーション３２０から信号を直接的に対向装置６００へ送信するわけではないので、対向装置６００は、受信した信号の送信元を知り得ない。
【００２８】
セッション管理機能３１２は、アプリケーション３２０に、リクエストＩＤのみでセッションデータにアクセスさせる機能である。実際のセッションデータは、分散されたサーバ３００またはデータベースのような外部装置（不図示）で管理されている。セッション管理機能３１２は、（リクエストＩＤを除いて）そのようなセッションデータの所在やアクセス手段を、アプリケーション３２０に意識させない。なお、前記セッションデータの所在とは、例えば、ＩＰアドレスまたはメモリアドレスである。また、前記アクセス手段とは、例えば、ＳＱＬ（Structured Query Language）送信である。
【００２９】
これらのクラスタ機能３１０を実現するＡＰＩにより、アプリケーション３２０は、分散処理されていることを意識せずにアプリケーション処理を実行できる。また、複数のサーバ３００においてクラスタ機能３１０がクラスタメンバシップを構成し、ロードバランサ２００の振り分け機能２１０がそれらのサーバ３００にリクエストを振り分けることにより、サーバ３００を追加（増設）すれば、サーバクラスタ１００の処理能力を向上させることができる。
【００３０】
サーバリソースプール８００は、サーバ３００に動的に割り当てる資源を蓄えている。サーバリソースプール８００は、起動することが決定したサーバ３００に対して資源を割り当て、停止することが決定したサーバ３００に割り当てていた資源を回収する。サーバリソースプール８００は、例えば、サービス提供システムＳの設置場所とは離れたデータセンタなどに設置された計算機の処理により構成される。
【００３１】
分散処理管理装置４００は、ロードバランサ２００の振り分け機能２１０と、クラスタ機能３１０とを連携制御する。分散処理管理装置４００は、この連携制御により、サーバクラスタ１００が提供するサービスを中断することなく、サーバ３００のファイルを更新することができる。
【００３２】
分散処理管理装置４００は、コンピュータ装置であり、制御手段４１０、記憶手段４２０、通信手段４３０、入力手段４４０および出力手段４５０、といったハードウェアを備える。
【００３３】
制御手段４１０は、例えばＣＰＵ（Central Processing Unit）とメモリによって構成され、ファイル送信部４１１、サーバクラスタ起動部４１２、振り分けルール設定部４１３、通信状態監視部４１４、エラー監視部４１５およびサーバクラスタ停止部４１６といったソフトウェアを実現する。
【００３４】
記憶手段４２０は、ＨＤＤ（Hard Disk Drive）などから構成され、ロードバランサ２００の振り分け機能２１０とクラスタ機能３１０を連携制御するために必要な各種情報を記憶する。
【００３５】
通信手段４３０は、ロードバランサ２００やクラスタ機能３１０と通信するための通信インタフェースや通信ポートから構成される。
【００３６】
入力手段４４０は、分散処理管理装置４００を操作するオペレータが情報を入力する手段であり、例えばキーボードやマウスなどから構成される。
なお、オペレータは、分散処理管理装置４００が接続している保守ネットワーク７００と接続している管理コンソール（不図示）を用いて情報を入力することもできる。
【００３７】
出力手段４５０は、情報を出力する手段であり、例えば、液晶表示機やスピーカなどから構成される。
【００３８】
ファイル送信部４１１は、サーバ３００がサーバクラスタ１００を構成し、サービスを提供するために必要なデータがまとめられているファイルをサーバ３００に送信する。
【００３９】
サーバクラスタ起動部４１２は、ファイルを受信したサーバ３００に対し、そのサーバ３００が属するサーバクラスタ１００として起動するように指示する。サーバ３００は、その指示を受信すると、ファイルの読み込み処理を行い、起動する。
【００４０】
振り分けルール設定部４１３は、ロードバランサ２００に対して、振り分けルールを設定する。振り分けルールとは、ロードバランサ２００の振り分け機能２１０が、対向装置６００から受信したリクエストをどのサーバ３００にどの程度振り分けるかを定めた内容である。
【００４１】
通信状態監視部４１４は、サーバクラスタ１００の通信状態を監視する。具体的には、サーバクラスタ１００のトラフィック量（リクエスト量）を集計したり、サーバ３００のＣＰＵ使用率を計測したりなどする。振り分けルール設定部４１３は、その集計や計測の結果に基づいて、サーバ３００に振り分けるリクエストの種類または量などを決定し、振り分けルールを作成する。
【００４２】
エラー監視部４１５は、ファイル送信部４１１が送信したファイルの安全性や安定性を監視する。具体的には、そのファイルで起動したサーバ３００の処理動作を監視し、処理動作が正常であるか否かを判定する。分散処理管理装置４００は、処理動作にエラーがあると判定した場合は、そのサーバ３００に対して動作の停止を指示する。
【００４３】
サーバクラスタ停止部４１６は、対象となるサーバクラスタ１００を構成するサーバ３００に対して停止するように指示する。サーバ３００は、その指示を受信すると、停止に必要な処理を実行し、サーバ３００に割り当てられていた資源を、割り当てが不要になったため、サーバリソースプール８００に戻す。
【００４４】
ここで、対向装置６００にサービスを提供中のサーバクラスタ１００である現用クラスタを、新たなサーバクラスタ１００である新設クラスタに切り替える場合を考える。従来技術の方法によると、サービスを継続するためには、現用クラスタから新設クラスタへの処理の引き継ぎが完了した後に、現用クラスタを停止する必要があった。この引き継ぎには、例えば、新設クラスタのサーバへのファイルの送信、新設クラスタのサーバの起動、現用クラスタから新設クラスタへのセッションデータの移行などが含まれる。
また、一般的には、新設クラスタのサーバに送信したファイル（更新後ファイル）は、現用クラスタのサーバに送信したファイル（更新前ファイル）を更新したものである。このため、更新後のファイルに基づいてサービスを提供する新設クラスタのサーバにリクエストが振り分けられる傾向がある。しかし、サービスを継続するためには、現用クラスタのサーバを停止するわけにはいかない。よって、現用クラスタと新設クラスタとが同時に稼動している期間が存在する。
【００４５】
また、処理を引き継ぐため、新設クラスタには、現用クラスタと同程度の性能が求められる。よって、サーバリソースプール８００から新設クラスタのサーバ３００に割り当てる資源の量は、現用クラスタのサーバ３００に割り当てていた資源の量と同程度にする必要がある。したがって、現用クラスタと新設クラスタとが併存したサーバクラスタ１００に対して、現用クラスタのみでサービスを提供していたときと比べて２倍の資源を割り当てる必要がある期間が存在する。しかし、それほど多くの資源を確保することは、サービス提供システムＳの運用上大きな負担となる。
【００４６】
本実施形態は、新設クラスタのサーバ３００がサービスを提供しつつも、一時的ではあるが、現用クラスタのサーバ３００によるサービスの提供を許容する。このことにより、現用クラスタと新設クラスタとが併存したサーバクラスタ１００に対して、２倍の資源を割り当てないように済ませる。
【００４７】
図２は、現用クラスタおよび新設クラスタに対するリクエストの振り分けの例を示す図である。元々は、ロードバランサ２００は、現用クラスタのサーバ３００（第１のサーバ）に対向装置６００からのリクエストを振り分けていた。ここで、すでに所定台数分用意されている新設クラスタのサーバ３００（第２のサーバ）の一部に対し、ファイルを送信し、サーバリソースプール８００から資源を割り当て、そのサーバ３００を起動する。ロードバランサ２００は、起動した新設クラスタのサーバ３００に対してリクエストを振り分け始めるが、現用クラスタのサーバ３００へのリクエストの振り分けも継続する。
【００４８】
その後、所定の時間をかけて、起動する新設クラスタのサーバ３００の数を徐々に増やしつつ、停止する現用クラスタのサーバ３００の数も徐々に増やすという調整をおこなう。この調整中、徐々に増える稼動中の新設クラスタのサーバ３００には、より多くのリクエストが振り分けられる。この調整は、新設クラスタのすべてのサーバ３００を起動し、現用クラスタのすべてのサーバ３００を停止するまで続ける。このような手順を踏むことで、現用クラスタから新設クラスタへの切り替えに要する期間を含むいかなる期間においても、現用クラスタのサーバ３００に割り当てる資源の量と新設クラスタのサーバ３００に割り当てる資源の量との合計は、前記した２倍の資源の量を下回る。
【００４９】
次に、図２に示したリクエストの振り分けを実現するための分散処理管理装置４００の処理について説明する。
図３は、分散処理管理装置における処理を示すフローチャートである。この処理の主体は、制御手段４１０である。この処理は、ステップＳ０１から開始する。
【００５０】
ステップＳ０１において、制御手段４１０は、サーバクラスタ１００において、新設クラスタのサーバ３００を登録する。登録されるサーバ３００は、新設クラスタを構成するすべてのサーバ３００の一部ではあるが、一般的には複数である。新設クラスタのサーバ３００を登録する数は、オペレータによる入力手段４４０の操作により、決定してもよいし、分散処理管理装置４００が所定のアルゴリズムを用いて決定してもよい。記憶手段４２０が記憶するデータベースには、対象となる新設クラスタのサーバ３００に関するレコードが書き込まれる。また、この登録により、分散処理管理装置４００は、登録した新設クラスタのサーバ３００を、ロードバランサ２００によるリクエストの振り分け先として設定する。ステップＳ０１の後、ステップＳ０２に進む。
【００５１】
ステップＳ０２において、制御手段４１０は、ファイル送信部４１１を用いて、新設クラスタのサーバ３００に対してファイルを送信する。ここで、送信するファイルは、現用クラスタのサーバ３００に送信したファイルを更新したファイルである。ファイル送信部４１１によるファイルの送信は、例えば、オペレータによる入力手段４４０の操作があって行ってもよいし、ステップＳ０１の処理の完了後、自動的に行ってもよい。ステップＳ０２の後、ステップＳ０３に進む。
【００５２】
ステップＳ０３において、制御手段４１０は、サーバクラスタ起動部４１２を用いて、新設クラスタのサーバ３００に対して、送信したファイルを用いて起動するように指示する。新設クラスタのサーバ３００は、この指示により、サーバリソースプール８００から資源を取得して、起動する。ステップＳ０３の後、ステップＳ０４に進む。
【００５３】
ステップＳ０４において、制御手段４１０は、振り分けルール設定部４１３を用いて、ロードバランサ２００に対して、稼動中のサーバ３００のいずれかにどの程度の量のリクエストを振り分けるかを定めた振り分けルールを設定する。このとき、制御手段４１０は、通信状態監視部４１４を用いてサーバクラスタ１００の通信状態を監視しており、その通信状態に基づいて、起動した新設クラスタのサーバ３００に振り分ける最適な割合となるリクエスト量を算出する。
【００５４】
前記「最適な割合」とは、例えば、通信状態監視部４１４により集計したトラフィック量や、計測したすべての（稼動中の）サーバ３００のＣＰＵ使用率に基づいて算出することが好ましい。このとき、算出した最適な割合となるリクエストをサーバ３００に振り分けるといった振り分けルールを作成する。
【００５５】
また、前記「最適な割合」とは、例えば、新設クラスタのサーバ３００の処理能力で（所定時間を超える遅延が無く）処理できるリクエストの最大量であることが好ましい。例えば、１リクエストあたりの処理負荷が均一（例：５ＣＰＵ利用単位）であったと仮定し、新設クラスタのサーバ３００は、１００ＣＰＵ単位で処理を行う能力を有しているとする。このとき、２０（＝１００／５）リクエストをそのサーバ３００に振り分ける、といった振り分けルールを作成する。
【００５６】
この「最適な割合」は、オペレータが決定して、入力手段４４０の操作により入力してもよい。また、分散処理管理装置４００が専用のアルゴリズムを用いて自動的に算出してもよい。
【００５７】
振り分けルール設定部４１３は、少なくともリクエストＩＤと、そのリクエストＩＤで識別されるリクエストの振り分け先とを対応付けたリストの形式で振り分けルールを作成する。前記リストの振り分け先には、サーバ３００と、そのサーバ３００が属するクラスタとが登録される。記憶手段４２０は、作成した振り分けルールを記憶する。
【００５８】
ステップＳ０４では、振り分けルール設定部４１３が、現用クラスタのサーバ３００、およびそのサーバ３００に振り分けられるリクエストのリクエストＩＤを定めるだけでなく、ステップＳ０１で登録した新設クラスタのサーバ３００、およびそのサーバ３００に振り分けられるリクエストのリクエストＩＤも定めた振り分けルールを作成する。そして、作成した振り分けルールを、ロードバランサ２００に送信する。ロードバランサ２００はその振り分けルールに基づいてリクエストを振り分ける。ステップＳ０４の後、ステップＳ０５に進む。
【００５９】
ステップＳ０５において、制御手段４１０は、エラー監視部４１５を用いて、稼動中の新設クラスタのサーバ３００に送信したファイルの安全性や安定性に関するエラー監視を行う。エラー監視は所定の監視期間に亘って行う。もし、稼動中の新設クラスタのサーバ３００のエラー発生を検知した場合、新設クラスタでの処理を中止し、新設クラスタに振り分けていたリクエストは、現用クラスタに振り分ける。このような対応を行うため、監視期間中は、現用クラスタのサーバ３００は停止しない。エラー発生を検知しなかった場合、ステップＳ０５の後、ステップＳ０６に進む。
【００６０】
ステップＳ０６において、制御手段４１０は、サーバクラスタ１００において、新設クラスタのサーバ３００を追加登録する。ステップＳ０６の処理は、基本的には、ステップＳ０１の処理と同様である。ステップＳ０６の処理により、起動する新設クラスタのサーバ３００の数を徐々に増やす。ステップＳ０６の後、ステップＳ０７に進む。
【００６１】
ステップＳ０７において、制御手段４１０は、ファイル送信部４１１を用いて、追加分の新設クラスタのサーバ３００に対してファイルを送信する。ステップＳ０７の後、ステップＳ０８に進む。
【００６２】
ステップＳ０８において、制御手段４１０は、サーバクラスタ起動部４１２を用いて、追加分の新設クラスタのサーバ３００に対して、送信したファイルを用いて起動するように指示する。追加分の新設クラスタのサーバ３００は、この指示により、サーバリソースプール８００から資源を取得して、起動する。ステップＳ０８の後、ステップＳ０９に進む。
【００６３】
ステップＳ０９において、制御手段４１０は、振り分けルール設定部４１３を用いて、ロードバランサ２００に対して、稼動中のサーバ３００のいずれかにどの程度の量のリクエストを振り分けるかを定めた振り分けルールを設定する。ステップＳ０９の処理は、基本的には、ステップＳ０４の処理と同様であり、起動した新設クラスタのサーバ３００に振り分ける最適な割合となるリクエスト量を新たに算出する。
【００６４】
ステップＳ０９では、振り分けルール設定部４１３が、ステップＳ０６で追加登録した新設クラスタのサーバ３００、およびそのサーバ３００に振り分けられるリクエストのリクエストＩＤも定めた振り分けルールを作成する。そして、作成した振り分けルールを、ロードバランサ２００に送信する。ステップＳ０９の後、ステップＳ１０に進む。
【００６５】
ステップＳ１０において、制御手段４１０は、サーバクラスタ停止部４１６を用いて、現用クラスタのサーバ３００の一部に対して、停止するように指示する。停止することになる現用クラスタのサーバ３００は、この指示により、サーバリソースプール８００へ資源を戻し、最終的には停止する。なお、停止することになる現用クラスタのサーバ３００は、自身に振り分けられるリクエストに対応するセッションデータを、そのリクエストの新しい振り分け先となるサーバ３００に移行する。新しい振り分け先となるサーバ３００は、後記するステップＳ１１で設定した振り分けルールに従って決定される。新しい振り分け先となるサーバ３００は、まだ稼動中の現用クラスタのサーバ３００でもよいが、新設クラスタのサーバ３００であることが好ましい。ステップＳ１０の後、ステップＳ１１に進む。
【００６６】
ステップＳ１１において、制御手段４１０は、振り分けルール設定部４１３を用いて、ロードバランサ２００に対して、稼動中のサーバ３００のいずれかにどの程度の量のリクエストを振り分けるかを定めた振り分けルールを設定する。ステップＳ１１の処理は、基本的には、ステップＳ０４の処理と同様であり、起動した新設クラスタのサーバ３００に振り分ける最適な割合となるリクエスト量を新たに算出する。
【００６７】
ステップＳ１１では、振り分けルール設定部４１３が、ステップＳ１０で停止が決定した現用クラスタのサーバ３００を除外して、振り分けルールを作成する。また、除外したサーバ３００に対応付けられていたリクエストＩＤは、残りのサーバ３００に対応付けられる。そして、作成した振り分けルールを、ロードバランサ２００に送信する。ステップＳ１１の後、ステップＳ１２に進む。
【００６８】
ステップＳ１２において、制御手段４１０は、現用クラスタのすべてのサーバが停止したか否か判定する。すべて停止した場合は（ステップＳ１１でＹｅｓ）、図３の処理全体を終了する。このことは、現用クラスタから新設クラスタへの切り替えが完了したことを意味する。一方、すべて停止しない場合は（ステップＳ１１でＮｏ）、ステップＳ０６に戻る。このことは、稼動中の現用クラスタの残りのサーバ３００を徐々に停止していくことを意味する。
【００６９】
このような処理を実行することにより、サービスを中断することなくファイルの更新を行うサーバクラスタ１００を構成するサーバ３００に割り当てる資源の量を低減することができる。リソースプールから新設クラスタのサーバ３００に割り当てる資源の量と、現用クラスタのサーバ３００からリソースプールへ回収する資源の量とを調整できるようにしたためである。
【００７０】
また、サーバクラスタ１００に振り分けられるリクエストの量に関係なく、新設クラスタのサーバ３００に割り当てる資源の量を調整することができる。
【００７１】
また、新設クラスタのサーバ３００を少し追加した段階で、ファイルの安全性や安定性に関するエラー監視を行うので（図３のステップＳ０５）、ファイルの更新に失敗したときの影響および対応に要する手間を低減することができる。
【００７２】
ステップＳ０４で説明した「最適な割合」は、対向装置６００を用いるユーザのユーザＩＤを基準にして決定することもできる。つまり、ユーザＩＤについて、リクエストを振り分けるための所定のグループ（振り分け単位）を決定し、どのグループに対応するサーバ３００にどのリクエストを振り分けるかを決定することができる。ユーザＩＤは、サービス提供システムＳの利用に関する認証結果が正当であるユーザごとに固有のランダム値である。そして、前記グループは、前記ランダム値がとり得る全範囲の一部に相当する。
【００７３】
振り分けルール設定部４１３は、例えば、少なくともユーザＩＤと、そのユーザＩＤが属するグループとを対応付けたリストの形式で振り分けルールを作成する。もし、１度に大量のリクエストを新設クラスタのサーバ３００に振り分けることができる場合には、新設クラスタのサーバ３００に対応するグループを多数指定することで前記「最適な割合」を実現することができる。また、１度に少量のリクエストしか新設クラスタのサーバ３００に振り分けることができない場合には、新設クラスタのサーバ３００に対応するグループを少数指定することで前記「最適な割合」を実現することができる。
【００７４】
また、ユーザＩＤの代わりに、ランダム値をとるリクエストＩＤを基準にして、上記と同様のやり方で、「最適な割合」を決定することもできる。
【００７５】
（第１の変形例）
これまでの説明は、ロードバランサ２００が新設クラスタのサーバ３００と現用クラスタのサーバ３００とに所定の割合でリクエストを振り分ける技術に関するものであった（図２参照）。しかし、ロードバランサ２００がすべてのリクエストを新設クラスタのサーバ３００に振り分け、新設クラスタのサーバ３００から現用クラスタのサーバ３００にリクエストを振り分ける、という方法をとってもよい。
【００７６】
図４は、現用クラスタおよび新設クラスタに対するリクエストの振り分けの他の例を示す図である。現用クラスタのサーバ３００に対し、最小規模の新設クラスタのサーバ３００を導入し、サーバリソースプール８００から資源を割り当てる。この段階で、ロードバランサ２００は、対向装置６００からのリクエストをすべて新設クラスタのサーバ３００に振り分ける。新設クラスタのサーバ３００は、振り分けられたリクエストの一部を処理し、残りを現用クラスタのサーバ３００に振り分けて処理させる。新設クラスタのサーバ３００が処理するリクエスト量は、例えば、図２のステップＳ０４の処理に倣って、「最適な割合」となるリクエスト量とすることが好ましい。
【００７７】
分散処理管理装置４００は、振り分けルール設定部４１３を用いて、新設クラスタのサーバ３００が処理するリクエストのリクエストＩＤと、現用クラスタのサーバ３００が処理するリクエストのリクエストＩＤとをまとめた振り分けルールを作成する。この振り分けルールには、ロードバランサ２００がすべてのリクエストを新設クラスタのサーバ３００に振り分けるという内容も記述されている。作成した振り分けルールは、ロードバランサ２００および新設クラスタのサーバ３００に送信して、設定される。
【００７８】
その後、図３のステップＳ０６〜ステップＳ１２の処理に倣って、ロードバランサ２００が、すべてのリクエストを新設クラスタのサーバ３００に振り分けつつも、新設クラスタを徐々に追加し、現用クラスタを徐々に停止し、現用クラスタから新設クラスタへの切り替えを実現する。
【００７９】
このような方法を行うことで、図２で示した方法と比べて、ロードバランサ２００が行う解析の負荷を低減することができる。つまり、図２で示した方法によれば、ロードバランサ２００は、リクエストを振り分けるサーバ３００が属するクラスタが現用クラスタであるか新設クラスタであるかを解析する必要があった。しかし、図４で示した方法によれば、ロードバランサ２００からの振り分け先は新設クラスタだけであるため、クラスタを区別するための解析は不要となる。
【００８０】
（第２の変形例）
前記した方法とはさらに異なり、ロードバランサ２００がすべてのリクエストを現用クラスタのサーバ３００に振り分け、現用クラスタのサーバ３００から新設クラスタのサーバ３００にリクエストを振り分ける、という方法をとってもよい。
【００８１】
図５は、現用クラスタおよび新設クラスタに対するリクエストの振り分けのさらに他の例を示す図である。現用クラスタのサーバ３００に対し、最小規模の新設クラスタのサーバ３００を導入し、サーバリソースプール８００から資源を割り当てる。この段階で、ロードバランサ２００は、対向装置６００からのリクエストをすべて現用クラスタのサーバ３００に振り分ける。現用クラスタのサーバ３００は、振り分けられたリクエストの一部を処理し、残りを新設クラスタのサーバ３００に振り分けて処理させる。新設クラスタのサーバ３００が処理するリクエスト量は、例えば、図２のステップＳ０４の処理に倣って、「最適な割合」となるリクエスト量とすることが好ましい。
【００８２】
分散処理管理装置４００は、振り分けルール設定部４１３を用いて、新設クラスタのサーバ３００が処理するリクエストのリクエストＩＤと、現用クラスタのサーバ３００が処理するリクエストのリクエストＩＤとをまとめた振り分けルールを作成する。この振り分けルールには、ロードバランサ２００がすべてのリクエストを現用クラスタのサーバ３００に振り分けるという内容も記述されている。作成した振り分けルールは、ロードバランサ２００および現用クラスタのサーバ３００に送信して、設定される。
【００８３】
その後、図３のステップＳ０６〜ステップＳ１２の処理に倣って、ロードバランサ２００が、すべてのリクエストを現用クラスタのサーバ３００に振り分けつつも、新設クラスタを徐々に追加し、現用クラスタを徐々に停止し、現用クラスタから新設クラスタへの切り替えを実現する。
【００８４】
このような方法を行うことで、図４で示した方法と同様、ロードバランサ２００が行う解析の負荷を低減することができる。つまり、図５で示した方法によれば、ロードバランサ２００からの振り分け先は現用クラスタだけであるため、クラスタを区別するための解析は不要となる。
【００８５】
（その他）
前記実施形態は、本発明を実施するために好適のものであるが、その実施形式はこれらに限定されるものでなく、本発明の要旨を変更しない範囲内において種々変形することが可能である。
【００８６】
例えば、本実施形態では、ロードバランサ２００と分散処理管理装置４００は、別筐体としているが、同一筐体としてもよい。したがって、分散処理管理装置４００の通信状態監視部４１４が行ったトラフィック量の集計や、サーバ３００のＣＰＵ使用率の計測は、ロードバランサ２００が行ってもよい。
【００８７】
また、ロードバランサ２００が故障した場合に備えて、ホットスタンバイ状態の別のロードバランサを用意しておいてもよい。ロードバランサ２００の障害時には瞬時にその別のロードバランサに切り替えれば、ロードバランサ２００の障害による影響を最小限に抑えることができる。
【００８８】
また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
また、本実施形態で説明したソフトウェアは、ハードウェアとして実現することもでき、ハードウェアは、ソフトウェアとして実現することもできる。したがって、例えば、分散処理管理装置４００の通信状態監視部４１４が行ったトラフィック量の集計や、サーバ３００のＣＰＵ使用率の計測は、ハードウェアによる処理として実現することができる。
【００８９】
その他、ハードウェア、ソフトウェア、フローチャートなどの具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００９０】
１００ サーバクラスタ
２００ ロードバランサ
２１０ 振り分け機能
２１１ 振り分け先制御機能
２１２ 状態管理機能
３００ サーバ（第１のサーバ、第２のサーバ）
３１０ クラスタ機能
３１１ トランスポート層転送機能
３１２ セッション管理機能
３２０ アプリケーション
４００ 分散処理管理装置
４１０ 制御手段
４１１ ファイル送信部
４１２ サーバクラスタ起動部
４１３ 振り分けルール設定部
４１４ 通信状態監視部
４１５ エラー監視部
４１６ サーバクラスタ停止部
４２０ 記憶手段
４３０ 通信手段
４４０ 入力手段
４５０ 出力手段
５００ ＩＰネットワーク
６００ 対向装置
６１０ サーバ
６２０ 端末
７００ 保守ネットワーク
８００ サーバリソースプール
Ｓ サービス提供システム
【特許請求の範囲】
【請求項１】
分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、
分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、
対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと、
前記第１のサーバと、前記第２のサーバと、前記ロードバランサと連携し、前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムであって、
前記分散処理管理装置の制御手段が、
サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動制御と、
前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、
前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止制御と、
前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行する
ことを特徴とするサービス提供システム。
【請求項２】
前記分散処理管理装置の制御手段が、
前記第２のサーバに送信した更新後ファイルのエラー監視を実行する
ことを特徴とする請求項１に記載のサービス提供システム。
【請求項３】
分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、
分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、
対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと、
前記第１のサーバと、前記第２のサーバと、前記ロードバランサと連携し、前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムにおけるファイル更新方法であって、
前記分散処理管理装置の制御手段が、
サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動ステップと、
前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定ステップと、
前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止ステップと、
前記起動ステップと、前記設定ステップと、前記停止ステップとを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行する
ことを特徴とするファイル更新方法。
【請求項４】
分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、
分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、
対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと連携し、
前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置であって、
前記分散処理管理装置の制御手段が、
サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動制御と、
前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、
前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止制御と、
前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行する
ことを特徴とする分散処理管理装置。
【請求項１】
分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、
分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、
対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと、
前記第１のサーバと、前記第２のサーバと、前記ロードバランサと連携し、前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムであって、
前記分散処理管理装置の制御手段が、
サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動制御と、
前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、
前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止制御と、
前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行する
ことを特徴とするサービス提供システム。
【請求項２】
前記分散処理管理装置の制御手段が、
前記第２のサーバに送信した更新後ファイルのエラー監視を実行する
ことを特徴とする請求項１に記載のサービス提供システム。
【請求項３】
分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、
分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、
対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと、
前記第１のサーバと、前記第２のサーバと、前記ロードバランサと連携し、前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムにおけるファイル更新方法であって、
前記分散処理管理装置の制御手段が、
サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動ステップと、
前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定ステップと、
前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止ステップと、
前記起動ステップと、前記設定ステップと、前記停止ステップとを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行する
ことを特徴とするファイル更新方法。
【請求項４】
分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第１のサーバと、
分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第２のサーバと、
対向装置からのリクエストを前記第１のサーバおよび第２のサーバに振り分けるロードバランサと連携し、
前記第１のサーバおよび前記第２のサーバの分散処理を制御する分散処理管理装置であって、
前記分散処理管理装置の制御手段が、
サーバリソースプールから所定量の資源が割り当てられる前記複数の第２のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第２のサーバを起動させる起動制御と、
前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第１のサーバおよび前記第２のサーバのＣＰＵ使用率とにより、稼動中の前記第２のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第１のサーバおよび前記第２のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、
前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第１のサーバの一部を停止させる停止制御と、
前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行する
ことを特徴とする分散処理管理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１３−９２８６７（Ｐ２０１３−９２８６７Ａ）
【公開日】平成２５年５月１６日（２０１３．５．１６）
【国際特許分類】
【出願番号】特願２０１１−２３３８２８（Ｐ２０１１−２３３８２８）
【出願日】平成２３年１０月２５日（２０１１．１０．２５）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２５年５月１６日（２０１３．５．１６）
【国際特許分類】
【出願日】平成２３年１０月２５日（２０１１．１０．２５）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]