JP4772854B2 - 計算機システムの構成管理方法、計算機システム及び構成管理プログラム - Google Patents

計算機システムの構成管理方法、計算機システム及び構成管理プログラム Download PDF

Info

Publication number
JP4772854B2
JP4772854B2 JP2008307203A JP2008307203A JP4772854B2 JP 4772854 B2 JP4772854 B2 JP 4772854B2 JP 2008307203 A JP2008307203 A JP 2008307203A JP 2008307203 A JP2008307203 A JP 2008307203A JP 4772854 B2 JP4772854 B2 JP 4772854B2
Authority
JP
Japan
Prior art keywords
server
service
services
processing
servers
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.)
Expired - Fee Related
Application number
JP2008307203A
Other languages
English (en)
Other versions
JP2010134518A (ja
Inventor
一穂 田中
恒彦 馬場
高広 横山
裕之 大崎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2008307203A priority Critical patent/JP4772854B2/ja
Priority to US12/457,578 priority patent/US20100138540A1/en
Publication of JP2010134518A publication Critical patent/JP2010134518A/ja
Application granted granted Critical
Publication of JP4772854B2 publication Critical patent/JP4772854B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Description

本発明は、複数の計算機を含む計算機システムの構成を管理する技術に関する。
クライアントからの要求に応じて、決済などの業務処理を実行するサーバシステムでは、リアルタイム性が重要である。リアルタイム性は、サーバシステムによって実行される業務処理を短時間で実行し、応答する性質である。
リアルタイム性を実現するためには、計算機の処理能力の向上に加え、負荷分散などによって処理効率を向上させる処理方式が必要となる。具体的には、複数のサーバでクラスタを構成し、クライアントからの要求を、複数のサーバが分担して並列処理することによって、各サーバの処理負荷を軽減するとともに、処理可能な要求量を増加させる。
さらに、クライアントからの要求が短時間に集中する場合にリアルタイム性を実現するためには、サーバの負荷の変動に応じて、要求を処理するサーバの割り当てを動的に変更するなどの処理が必要となる。
ただし、クライアントからの要求には、個別のサーバで保持されているデータにアクセスする要求が含まれる場合がある。要求を処理するサーバの割り当てを変更するためには、サーバで保持されるデータの管理、及びクライアントとサーバとの関係の管理が複雑となり、通常のクライアント及びサーバでは実現することが困難である。
そこで、クラスタを構成する各サーバが、クラスタ全体に割り当てられた論理ネットワークアドレスに送信されたパケットを受信し、受信したパケットのパラメータに基づいて、当該パケットの有効又は無効と選別する技術が開示されている(特許文献1参照)。特許文献1に開示された技術によれば、クライアントの改造又はネームサーバの設定を必要とせずに、論理ネットワーク宛のパケットを実際に受信するサーバを変更することができる。
また、クライアントがサーバに対してサービスの要求を送信する場合に、クラスタに割り当てられた仮想ネットワークアドレスに対して物理アドレス要求を送信する技術が開示されている(特許文献2参照)。特許文献2に開示された技術によれば、サーバは、各サーバの負荷情報からサーバの優先度を決定し、決定された優先度に基づいて物理アドレス要求に応答するか否かを判定する。クライアントは、物理アドレスを受信すると、受信した物理アドレスに対してサービス要求を送信する。こうすることによって、ネームサーバの設定を必要とせずに、サービスを提供するサーバを変更することが可能となる。
特開2000−187632号公報 特開2001−216282号公報
特許文献1に開示された技術では、パケットを受信するサーバにおいて、サーバの状態を表すパラメータ、論理ネットワークアドレス、及び送信元であるクライアントのアドレスに基づいて、パケットを破棄するか否かを選択する。しかし、個別のサーバで保持されているデータにアクセスする処理が要求された場合、パケットを受信するサーバを変更しても、変更先サーバが処理に必要なデータを保持していないため、要求を処理することができない。
また、特許文献2に開示された技術では、各サーバは処理負荷に基づいて決定されるサーバの優先度によってサービス要求の処理を実行するサーバを変更する。ここで、サーバが大量のデータを保有し、それらにアクセスする複数のサービスを実行する場合を考える。このとき、一部のサービスを他のサーバが処理するように変更することによって負荷分散するためには、サービスに必要なデータが変更先のサーバに格納されていなければならない。しかし、特許文献2に開示された技術では、要求を処理するために必要なデータを特定する情報を持たないため、変更先サーバにすべてのデータが格納されていなければならない。しかし、変更先サーバにすべてのデータをコピーすると、データコピーに必要な処理時間及び処理負荷が膨大になるため、この間に受信するクライアントからの要求を処理する性能が低下し、リアルタイム性を維持することが困難になる。
本発明の一態様は、要求されたサービスを実行可能な複数のサーバを含む計算機システムの構成を管理する方法である。前記サーバは、各サーバ間を接続するインタフェースと、前記インタフェースに接続されたプロセッサと、前記サービスを提供するために必要なデータを格納する記憶部とを備える。同じデータを参照するサービスは、前記複数のサーバにおける同じサーバに割り当てられる。前記サーバは、前記サーバの負荷が所定の上限値を超えた場合には、前記負荷が上限値を超えたサーバで実行されるサービスの一部を実行させる転送先サーバを選択し、前記負荷が上限値を超えたサーバに割り当てられたサービスから一以上のサービスを選択し、前記転送先サーバに前記選択されたサービスを割り当て、前記選択されたサービスの実行に必要なデータを前記負荷が上限値を超えたサーバから前記転送先サーバに転送する。前記サービスの実行要求は、前記複数のサーバにマルチキャストで送信される。前記サービスの実行要求を受信した各サーバは、要求されたサービスを実行しない場合は、前記受信したサービスの実行要求を破棄する。前記サーバには、サービスの集合単位でサービスが割り当てられる。同じデータを参照するサービスは、同じサービスの集合に含まれる。前記サーバは、前記負荷が上限値を超えた前記サーバに割り当てられたサービスから、サービスの集合単位で前記転送先サーバに前記サービスを割り当てる。前記サービスには、前記サービスが必要とするサーバ数を表す信頼性レベルが予め設定されている。前記サーバは、前記負荷が下限値以下のサーバに割り当てられているサービス、及び前記集約先サーバに割り当てられているすべてのサービスを、前記負荷が下限値以下のサーバ及び前記集約先サーバのうち、前記信頼性レベルの高いサービスが割り当てられていたサーバに、前記すべてのサービスを割り当てる。前記サーバは、前記サービスが割り当てられなかったサーバに対するサービスの割り当てを解除する。前記サーバは、前記サービスの割り当てが解除されたサーバに格納されたデータを、前記すべてのサービスが割り当てられたサーバに転送する
本発明の一形態によれば、リアルタイム性を維持しながら負荷を分散させることができる。
以下、本発明の実施の形態について図面を参照しながら説明する。
<第1の実施の形態>
図1は、本発明の第1の実施の形態の計算機システムの構成の一例を示すブロック図である。
本発明の第1の実施の形態の計算機システムは、1台以上のクライアント101と、1台以上のサーバ110によって構成される。図1には、1以上の数字であるmとnを用いて、クライアント101をm台、サーバ110をn台使用して構成した例を示す。
クライアント101及びサーバ110は、互いに通信可能な計算機である。サーバ110は、クライアント101から要求された処理を実行する。
各クライアント101は、処理要求送信部102を備える。処理要求送信部102は、利用者によって入力された処理要求をサーバに送信する。処理要求送信部102は、クライアント101で実行されるプログラム、又は同じ機能を提供する専用ハードウェアとして実現される。
クライアント101及びサーバ110は、ネットワーク103によって接続される。ネットワーク103は、クライアント101が複数のサーバ110に対して送信するマルチキャスト通信を行い、さらに、複数のサーバ110間でデータを送受信する。
サーバ110には、状態が「実行系」であるサーバと状態が「待機系」であるサーバとが含まれる。また、状態が「実行系」であるサーバと状態が「待機系」であるサーバは同じ構成である。状態が「実行系」であるサーバは、クライアントから要求された処理を実行する。状態が「待機系」であるサーバは、状態が「実行系」であるサーバに障害が発生した場合に、状態が「実行系」であるサーバに替わって要求された処理を実行する。
各サーバ110は、処理データ管理部111、クラスタ情報管理部118及びサービス情報管理部121を格納する。処理データ管理部111、クラスタ情報管理部118及びサービス情報管理部121は、それぞれサーバ110上で実行されるプログラム、又は同じ機能を提供する専用ハードウェアとして実現される。
処理データ管理部111は、要求受信部112、処理実行部113、データ転送部114、処理データ115、処理要求キュー116、及び処理結果情報バッファ117を含む。
要求受信部112は、クライアント101から送信された処理要求電文を受信し、処理実行部113に処理要求電文を送信する。
処理実行部113は、要求受信部112から送信された処理要求電文に基づいて、要求された処理を実行する。
データ転送部114は、処理データ115及び処理結果情報バッファ117に格納された処理結果情報を他のサーバ110に転送する。
処理データ115は、処理実行部113によって実行される処理に必要なデータを格納する。また、処理データ115は、高速にアクセス可能な揮発性の記憶媒体(メモリ)に記憶されている。
処理要求キュー116は、クライアント101から送信された処理要求電文に含まれる情報を格納する。
処理結果情報バッファ117は、処理実行部113によって実行された処理結果を一時的に格納する。
クラスタ情報管理部118は、クラスタ情報処理部119及びクラスタ情報テーブル120を含む。
クラスタ情報処理部119は、クラスタ情報テーブル120を更新し、クラスタ情報テーブル120に格納された情報を送受信する。また、他のサーバに処理データ転送要求を送受信することによって、サーバ間のデータをコピーする。さらに、追加サーバ応答要求電文及び追加サーバ応答要求電文に対する応答を送受信する。
クラスタ情報テーブル120は、サーバ110が属するマルチキャストアドレス、各サーバ110のアドレス、及び各サーバ110の状態を保持する。
サービス情報管理部121は、サービス情報判断部122、サービス情報転送部123、サービス情報テーブル124、サービスグループ情報テーブル125、及び処理サービスグループID126及び負荷量閾値テーブル127を格納する。
サービス情報判断部122は、サーバの負荷の増減を検知する。
サービス情報転送部123は、サービス情報テーブル124、サービスグループ情報テーブル125及び処理サービスグループID126を更新し、他のサーバ110に情報を送受信する。
サービス情報テーブル124は、各サービスの識別子、各サービスで使用されるデータを格納するテーブルの識別子、及び各サービスの負荷量を含む。サービスグループ情報テーブル125は、各サービスグループの識別子、各サービスグループに属するサービスの識別子、及び各サービスグループに属するサービスの負荷量の合計を格納する。
処理サービスグループID126は、各サーバ110が処理するサービスグループを識別する識別子である。負荷量閾値テーブル127は、サービスグループの構成を変更する基準となる負荷量の閾値を格納する。
図2は、本発明の第1の実施の形態のサーバ110のハードウェア構成を示すブロック図である。
サーバ110は、前述したように、状態が「実行系」であっても「待機系」であっても同じ構成となっている。各サーバ110は、CPU21、ディスプレイ装置22、キーボード23、マウス24、ネットワークインタフェースカード(NIC)25、ハードディスク装置26及びメモリ27を備える。CPU21、ディスプレイ装置22、キーボード23、マウス24、NIC25、ハードディスク装置26及びメモリ27は、バス28によって接続される。
状態が「実行系」及び「待機系」の各サーバ110は、NIC25を介してネットワークに接続し、他のサーバ110と相互に通信する。
CPU21は、メモリ27に記憶されたプログラムを実行する。メモリ27は、CPU21によって実行されるプログラム及び当該プログラムの実行に必要なデータを記憶する。本発明の第1の実施の形態では、メモリ27は、揮発性記録媒体によって構成されている。
メモリ27は、処理管理部100、オペレーティングシステム30、処理データ管理部111、クラスタ情報管理部118、サービス情報管理部121、処理データ115、処理要求キュー116、処理結果情報バッファ117、及びクラスタ情報テーブル120、サービス情報テーブル124、サービスグループ情報テーブル125、処理サービスグループID126を記憶する。
処理管理部100は、オペレーティングシステム30で実行されるプログラムである。処理データ管理部111、クラスタ情報管理部118及びサービス情報管理部121は、処理管理部100によって実行されるプログラムである。処理データ管理部111、クラスタ情報管理部118及びサービス情報管理部121については、図1にて説明した処理を実行する。
処理データ115は、各種サービスで使用されるデータである。処理データ115は、データベース管理システムのような処理データ管理部111とは異なるアプリケーションによって管理されてもよい。この場合、データベース管理システムは、メモリ27に記憶される。
処理要求キュー116は、図1にて説明したように、処理要求電文200に含まれていた処理内容が格納される領域である。処理結果情報バッファ117は、図1にて説明したように、要求された処理の結果を一時的に格納する領域である。具体的には、待機系のサーバ110において、実行系のサーバ110から送信された処理結果を、処理データ115に反映させるまでの間、一時的に格納する。
クラスタ情報テーブル120は、図1にて説明したように、マルチキャストで通信する場合の送信先のサーバ110及び各サーバ110の稼働状態を格納する。サービス情報テーブル124は、図1にて説明したように、各サービスで使用されるテーブル及び負荷量を格納する。サービスグループ情報テーブル125は、図1にて説明したように、サービスグループに属するサービスを格納する。処理サービスグループID126は、図1にて説明したように、各サーバ110に割り当てられたサービスグループの識別子を保持する。
ディスプレイ装置22は、サービスの処理結果などの各種情報を表示する。キーボード23及びマウス24は、利用者からの入力を受け付ける。NIC25は、ネットワークに接続するインタフェースである。ハードディスク装置26は、メモリ27に格納される処理データ115、及びメモリ27にロードされる各種プログラムを格納する。
また、クライアント101のハードウェア構成は、図2に示したサーバ110のハードウェア構成と同様であって、CPU、メモリ、NIC及び入出力装置などを備える。なお、クライアント101は、仮想計算機上で実行されるプログラムによって実現されてもよい。
次に、本発明の第1の実施の形態における処理の概要について説明する。
図3は、本発明の第1の実施の形態の計算機システムの構成を変更する手順の概要を説明する図である。
本発明の第1の実施の形態では、サーバ110の負荷が増大した場合に、サービスグループ単位でサービスを分離し、他のサーバに振り分けることによって負荷を分散させる。このようにシステムを分離することによって負荷を分散させることをスケールアウトという。
まず、スケールアウトを実行する前の通常の処理について説明する。
サーバ110は、クライアント101からマルチキャストで送信されたサービス要求を受け付けると(S3401)、状態が「実行系」であるサーバ110が受け付けたサービス要求を処理する。要求されたサービスの処理が完了すると、処理されたサービスの負荷量をサービス情報テーブル124に記録する。要求されたサービスを処理するたびに、処理したサーバ110に割り当てられたサービスの負荷量の合計が負荷量閾値の上限を超えているか否かを判定する(S3402)。
サーバ110は、S3402の処理で負荷の合計が負荷量閾値の上限を超えたことを検知すると、スケールアウトを開始する。
サーバ110は、まず、使用するデータが互いに干渉しないサービスを分類し、当該サービスを分離する(S3403)。例えば、図3では、サービスS1及びS2と、サービスS3及びS4とでサービスを分類することができる。また、複数のサービスグループが定義されている場合には、サービスグループを選択するようにしてもよい。
サーバ110は、計算機システムに含まれているサーバからをS3403の処理で分離されたサービスを処理するための複数のサーバ110を選択する。このとき、選択されたサーバを状態が「追加系」であるサーバとする。さらに、分離されたサービス(S3及びS4)で使用されるデータを状態が「追加系」であるサーバにコピーする(S3404)。このとき、状態が「実行系」であるサーバ110でさらにサービスの処理要求を受け付ける可能性があるため、状態が「実行系」であるサーバ110の負荷を増大させないように、状態が「待機系」であるサーバ110からデータをコピーする。
なお、分離されたデータのコピーを実行している間に、当該分離されたデータを使用するサービスを処理した場合には、処理結果情報をマルチキャストで送信する。このとき、受信したサーバ110に割り当てられたサービスであれば処理結果を反映させ、そうでない場合には、受信した処理結果を破棄する。また、状態が「追加系」であるサーバ110でデータがコピー中の場合にはコピーが完了してから処理結果を反映させる。以上の処理によってデータの整合性を保つことができる。
S3404の処理におけるデータのコピーが完了すると(S3405)、状態が「追加系」である複数のサーバ110のうち1つを実行系に、残りを待機系とする。そして、状態が「実行系」である追加されたサーバ110(サーバ4)は、分離されたサービスの受け付けを開始する(S3406)。また、サービスが分離されたサーバ110(サーバ1)では、分離されたサービスS3及びS4の処理を停止する。以上の処理によって、スケールアウトが完了する。
次に、スケールアウト後の処理について説明する。
S3401からS3406の処理によってスケールアウトされ、システムが分離された後、クライアント101は、スケールアウト前と同様に、サービス要求をマルチキャストで送信する(S3407)。サービス要求がマルチキャストで送信されるため、クライアント101はサーバ110のスケールアウトによる影響を受けることはない。本発明の第1の実施の形態では、すべてのサーバ110がサービス要求を受信し、状態が「実行系」であるサーバ110が処理を担当するサービスの要求を受け付けた場合には当該サービスを処理し、その他の場合には受信したサービス要求を破棄する。
続いて、本発明の第1の実施の形態の詳細を説明する。まず、本発明の第1の実施の形態におけるテーブル及びキューの内容を、図4から図13を参照しながら説明する。
図4は、本発明の第1の実施の形態の処理要求電文200の一例を示す図である。
処理要求電文200は、クライアント101からサーバ110にサービスの処理を要求する際に送信される情報である。処理要求電文200は、サービスID201及び処理内容202を含む。
サービスID201は、クライアント101に処理を要求されるサービスを一意に識別する識別子である。処理内容202は、サービスID201によって識別されるサービスの処理内容を示す情報である。具体的には、サービスを処理するために必要なパラメータなどが格納される。
処理要求電文200に含まれるサービスID201及び処理内容202は、受信したサーバ110の処理要求キュー116に登録される。
図5は、本発明の第1の実施の形態の処理要求キュー116の構成の一例を示す図である。
処理要求キュー116は、サーバ110に受信された処理要求電文200に含まれる情報が格納される。処理要求キュー116は、サービスID301及び処理内容302を格納する。
サービスID301は、処理要求電文200に含まれるサービスID201の値が格納される。処理内容302は、処理要求電文200に含まれる処理内容202の値が格納される。
図6は、本発明の第1の実施の形態の処理結果情報400の構成の一例を示す図である。
処理結果情報400は、処理要求キュー116に格納された処理要求が、サーバ110によって処理された結果である。処理結果情報400は、処理通番401、サービスID404、テーブルID402及び処理結果403を含む。
処理通番401は、処理要求キュー116に格納された処理要求が処理された場合に付与され、完了した処理を一意に識別するための識別子である。
サービスID404は、処理されたサービスの識別子である。サービスID404は、処理要求キュー116のサービスID301に対応する。テーブルID402は、サービスID404によって識別されるサービスを処理する際に使用されたテーブルの識別子である。
処理結果403は、サービスの処理結果が格納される。具体的には、サービスID404に対応するサービスで、テーブルID402に対応するテーブルに格納されたデータが処理された結果である。サービスによる処理では、例えば、「テーブルの更新」「テーブルの一部削除」「テーブルの一部追加」などが実行される。
図7は、本発明の第1の実施の形態の処理通番500の一例を示す図である。
処理通番500は、サーバ110でサービスが処理されるたびに加算され、実行された処理を一意に識別するために用いられる。処理通番500は、図4に示した処理結果情報400の処理通番401に格納される。
図8は、本発明の第1の実施の形態のクラスタ情報テーブル120の構成の一例を示す図である。
クラスタ情報テーブル120は、クラスタとサーバ110との関係を保持する。クラスタ情報テーブル120は、マルチキャストアドレス601、サーバアドレス602及び状態603を含む。
マルチキャストアドレス601は、サーバ110を含むクラスタで共有されるマルチキャストアドレスである。クラスタ内の複数のサーバ110は、マルチキャストアドレスのメンバーシップに参加していることを意味する。
サーバアドレス602は、サーバ110に情報を送信する際に使用されるアドレスである。サーバアドレス602には、各サーバ110で一意のアドレスが割り当てられており、例えば、IPアドレスが割り当てられている。
状態603は、サーバ110の状態を表す。具体的には、「実行系」「待機系」「追加系」などの値が設定される。
図9は、本発明の第1の実施の形態のサービスグループ情報テーブル125の構成の一例を示す図である。
サービスグループ情報テーブル125は、サービスグループと、当該サービスグループを構成するサービスとの関連を保持する。サービスグループとは、共通のテーブルを利用して処理するサービスを負荷合計が均等になるようにグループ化したものである。なお、本発明の第1の実施の形態では、共通のテーブルを利用して処理するサービスをサービスグループと定義し、各サーバにサービスグループを割り当てるようにしているが、サービスグループとしてではなく、個々のサービスを直接各サーバに割り当てるようにしてもよい。
サービスグループ情報テーブル125は、サービスグループID701、サービスID702及び負荷合計703を含む。
サービスグループID701は、サービスグループを一意に識別する識別子である。サービスID702は、当該サービスグループを構成するサービスである。負荷合計703は、当該サービスグループを構成する各サービスの負荷量を合計した値である。
図10は、本発明の第1の実施の形態のサービス情報テーブル124の構成の一例を示す図である。
サービス情報テーブル124は、サービスと当該サービスで使用されるテーブルとの関連を保持する。サービス情報テーブル124は、サービスID801、使用テーブルID802及び負荷量803を含む。
サービスID801は、サービスを一意に識別する識別子である。使用テーブルID802は、当該サービスによって使用されるデータを格納するテーブルの識別子である。
負荷量803は、当該サービスの処理による負荷を示す情報である。負荷量803は、例えば、サービス処理時のCPU利用率、メモリ使用量、入出力処理の頻度及びロック処理の頻度など、サーバ110から取得可能な情報に基づいて算出される。
図11は、本発明の第1の実施の形態の処理サービスグループID126の一例を示す図である。
処理サービスグループID126は、サーバ110によって処理されるサービスグループの一覧である。
図12は、本発明の第1の実施の形態の追加サーバ応答要求電文1000の構成の一例を示す図である。
追加サーバ応答要求電文1000は、電文種別1001及び電文内容1002を含む。電文種別1001は、当該電文が「応答要求」又は「応答」のいずれかを示す情報である。電文内容1002は、当該電文が「応答」である場合に、当該電文を送信するサーバのアドレスを格納する。
図13は、本発明の第1の実施の形態の負荷量閾値テーブル127の構成の一例を示す図である。
負荷量閾値テーブル127は、閾値名2901及び負荷量2902を含む。
閾値名2901は、「上限値」及び「下限値」などの負荷量閾値の種類を表す。
負荷量2902は、閾値名2901に対応する負荷量を表す。図13には、負荷量の「上限値」は80、負荷量の「下限値」は10であることを示している。
次に、本発明の第1の実施の形態の処理の手順について、図14から図20を参照しながら説明する。
図14は、本発明の第1の実施の形態のクライアント101からの処理要求に応じてサーバ110で処理を実行する手順を説明する図である。
図14には、クライアント101が、サーバ110A及びサーバ110Bによって構成されるクラスタに処理を要求する手順が示されている。また、要求された処理では、サービスグループIDがSG_Aであるサービスグループに属し、サービスIDがS1であるサービスが実行される。
クライアント101は、サービスIDがS1であるサービスが実行される処理要求電文211Aをサーバ110に送信する(S1101)。処理要求電文211Aは、サービスID301に「S1」の値を格納する。処理要求電文211Aの送信先は、サーバ110A及びサーバ110Bを含むクラスタに割り当てられたマルチキャストアドレスである。
サーバ110Aの処理要求受信部112Aは、処理要求電文211Aを受信し、処理要求を処理実行部113Aに送信する(S1102A)。
処理実行部113Aは、処理要求受信部112Aから送信された処理要求に格納されたサービスID301及び処理内容302を参照する(S1103A)。さらに、処理実行部113Aは、図20にて後述するように、受信した処理要求電文200が処理対象である場合には要求された処理を実行し、処理対象でない場合には受信した処理要求電文200を破棄する。
図14に示す例では、サーバ110AにはサービスグループIDがSG_Aのサービスグループが割り当てられ、さらに、サービスIDがS1のサービスはサービスグループSG_Aに属しているため、受信した処理要求電文200に基づいてサービスを処理する。処理実行部113Aは、S1103Aの処理において、処理要求電文200に含まれる処理内容302に基づいてサービスS1を実行し、処理結果情報400を作成する。
処理実行部113Aは、処理結果情報400をデータ転送部114Aに送信する。データ転送部114Aは、クラスタ情報テーブル120のマルチキャストアドレス601を参照し、処理実行部113Aによって送信された処理結果情報400をマルチキャスト送信する。
また、サーバ110Bの処理要求受信部112Bは、S1101の処理によって処理要求電文200をクライアント101から受信すると、サーバ110Aの処理要求受信部112AのS1102Aの処理と同様に処理を実行する(S1102B)。なお、サーバ110Bの状態が「待機系」であるため、S1103Bの処理では、サーバ110Bによって受信された処理要求電文200は破棄される。
サーバ110Bのデータ転送部114Bは、S1105の処理によってサーバ110Aのデータ転送部114Aによって送信された処理結果情報400を受信する(S1106)。そして、データ転送部114Bは、図18にて後述するように、受信した処理結果情報400に基づいて処理データ115を更新するか否かを判定する。処理データ115を更新する場合には、処理結果情報400に含まれる処理結果403に基づいて処理データ115を更新し、サーバ110Aの処理データ115と内容を同一にする。処理データ115を更新しない場合には、受信した処理結果情報400を破棄する。
図14に示す例では、サーバ110Bはサーバ110Aの待機系であり、同一のデータを格納するため、処理結果403に基づいて処理データ115を更新する。
次に、サービスグループIDがSG_Aのサービスグループに属さないサービスIDがS3のサービスの実行を含む処理要求電文200を受信した場合について説明する。
クライアント101は、S1101の処理と同様に、処理要求電文200を送信する(S1107)。このとき送信された処理要求電文200のサービスID301には、「S3」が設定されている。
サーバ110Aの処理要求受信部112Aは、クライアント101によって送信された処理要求を受信する(S1108A)。このとき、処理要求に含まれるサービスIDにS3が設定されており、サーバ110Aに割り当てられているサービスグループSG_Aには当該サービスが含まれていないため、受信した処理要求電文200を破棄する。
サーバ110Bの処理要求受信部112Bは、S1108A及びS1109Aと同様に、処理要求電文200を受信し(S1108B)、S1103Bの処理と同様に、受信した処理要求電文200を破棄する(S1109B)。
次に、状態が「実行系」であるサーバ110の負荷が上限を超えたために、状態が「実行系」であるサーバ110を追加するスケールアウトを実行することによって、負荷分散を図る手順について説明する。
図15は、本発明の第1の実施の形態の実行系のサーバ110をクラスタに追加する(スケールアウト)手順を説明する図である。
まず、図15に示す処理手順を説明する前に、対象となるクラスタの構成について説明する。図15に示すクラスタでは、状態が「実行系」であるサーバ110A、状態が「待機系」であるサーバ110Cが同一クラスタ内に含まれ、いずれのサーバもサービスグループSG_Aを処理する。なお、この時点ではサーバ110Aで処理されるすべてのサービスがサービスグループSG_Aに属している。
続いて、状態が「実行系」であるサーバ110Aにおける負荷が増加した場合に、サービスグループSG_Aを分割してサービスグループSG_Bを生成し、サービスグループSG_Bに含まれるサービスをサーバ110Bで処理するように構成を変更する手順を説明する。
状態が「実行系」であるサーバ110Aのサービス情報判断部122Aは、サーバ110Aの負荷があらかじめ設定された閾値(上限値)を超えたことを検知すると、クラスタ情報処理部119Aに通知する(S1201)。具体的には、サーバ110Aのシステムログなどに含まれるCPU使用率、メモリ使用率及び入出力処理量などに基づいて負荷量を算出し、負荷量閾値テーブル127に設定されている閾値(この場合は上限値)と比較する。
クラスタ情報処理部119Aは、サービス情報判断部122Aからの負荷が上限を超えた旨の通知を受け付けると、追加サーバ応答要求電文1000をクラスタ内の全サーバにマルチキャストで送信する(S1202)。
サーバ110Cは、この時点で、状態が「待機系」であって、かつ、分離前のサービスグループSG_Aを処理する。したがって、サーバ110Cの処理サービスグループID126には、サービスグループSG_Aが含まれている。
サーバ110Cのクラスタ情報管理部118Cに含まれるクラスタ情報処理部119Cは、サーバ110Aからマルチキャストにて送信された追加サーバ応答要求電文1000を受信する(S1203)。クラスタ情報処理部119Cは、自サーバの状態が「追加系」であるサーバではないため、電文を破棄する。
サーバ110Bは、マルチキャストによって送信された情報の受信が開始されている(S1200)。また、この時点では、サービスグループSG_A及びSG_Bを処理しない。すなわち、サーバ110Bの処理サービスグループID126にはサービスグループSG_Aが含まれていない。なお、マルチキャスト通信の開始は、例えば、S1201の処理で負荷が閾値を超えた時点で、サーバ110Bをマルチキャストアドレスのメンバーシップに追加するようにしてもよい。このとき、計算機システムに追加用のサーバ110をあらかじめプールしておき、スケールアウト実行時にクラスタに追加するようにしてもよい。
サーバ110Bは、サーバ110Aからマルチキャストにて送信された追加サーバ応答要求電文1000を受信する(S1204)。クラスタ情報処理部119Bは、S1204の処理において、追加サーバ応答要求電文1000の送信元であるサーバ110Aに応答を送信する。このとき、送信される応答には、自サーバ(サーバ110B)のアドレスが格納される。
サーバ110Aは、サーバ110Bから送信された応答を受信すると、受信した応答に基づいてクラスタ情報テーブル120を更新し、更新された情報をクラスタ内の全サーバに送信する(S1205)。具体的には、応答に含まれるサーバ110Bのアドレスをクラスタ情報テーブル120に追加し、追加されたサーバ110Bの状態を「追加系」とする。
クラスタ情報を受信したサーバのクラスタ情報処理部119は、自サーバのクラスタ情報テーブル120の内容を送信されたクラスタ情報に基づいて、サーバ110Aのクラスタ情報テーブル120と同一になるように更新する(S1206B及びS1206C)。クラスタ情報テーブル120の更新後、クラスタ情報処理部119は、サーバ110Aにクラスタ情報更新完了を通知する。
サーバ110Aは、クラスタ情報を送信したすべてのサーバからクラスタ情報更新完了を通知された後、自サーバ110Aのサービス情報転送部123Aにサービス変更要求を送信する。
このとき、図20にて後述するように、サービス情報テーブル124に基づいて、サービスの実行に使用されるテーブルごとに、サービスをグループ分けする。このとき、負荷量の合計ができるだけ均等になるようにグループ分けする。そして、新たなサービスグループを定義し、サービスグループ情報テーブル125を更新する。本発明の第1の実施の形態では、サービスグループSG_AからサービスグループSG_Bを生成し、サービスグループ情報テーブル125にサービスグループSG_A及びSG_Bに対応するレコードを登録する。
なお、あらかじめサービスグループSG_A及びSG_Bが分割された状態でサーバ110Aに登録されており、サービスグループSG_Aの負荷合計703とサービスグループSG_Bの負荷合計703の差が小さい場合には、新たにサービスグループを生成せずに以降の処理を実行することができる。
サービス情報転送部123Aは、クラスタ情報処理部119Aからサービス変更要求を受信すると、サービス変更処理を実行し(S1207)、完了通知をクラスタ情報処理部119Aに送信する。
S1207のサービス変更処理については、図16にて後述する。サービス変更処理が実行されると、サーバ110A及びサーバ110Cの各処理サービスグループID126にはSG_A及びSG_Bが格納され、サーバ110Bの処理サービスグループID126にはSG_Bが格納される。さらに、各サーバ110のサービス情報テーブル124には、処理サービスグループID126に属するサービスID801が格納されるように変更される。
したがって、S1207の処理によって、サーバ110A及びサーバ110Cのサービスグループ情報テーブル125、サービス情報テーブル124及び処理サービスグループID126はそれぞれ図9、図10及び図11に示す状態になる。また、サーバ110Bについては、それぞれ図26、図24及び図28に示す状態になる。クラスタ情報処理部119Aは、サービス情報転送部123Aから完了通知を受信し、サーバ追加が完了する(S1208)。
ここで、サーバ110Aは、前述したサーバ追加処理(S1202からS1208)をあらかじめ設定された追加サーバの数だけ繰り返す。追加されるサーバの数は1つでもよいし、複数であってもよい。本発明の第1の実施の形態では、追加するサーバ数を3とし、以降の説明では3台のサーバが追加系として追加される。
図16は、本発明の第1の実施の形態のサービス変更処理(S1207)の手順を説明する図である。
サービス変更処理は、前述のように、サービス情報管理部121Aのサービス情報転送部123Aによって実行される。
サービス情報転送部123Aは、受信したサービス変更要求に基づいて、サービス情報テーブル124、サービスグループ情報テーブル125、及び処理サービスグループID126を変更する(S1301)。
次に、サービス情報転送部123Aは、クラスタ内の全サーバにサービス情報テーブル124、サービスグループ情報テーブル125、処理サービスグループID126を送信する。このとき、同一の内容を送信してもよいし、各サーバで更新が必要な情報を選択して送信してもよい。
サーバ110Bのサービス情報管理部121Bに含まれるサービス情報転送部123Bは、サービス情報転送部123Aから送信されたサービス情報テーブル124、サービスグループ情報テーブル125及び処理サービスグループID126を受信する。そして、受信した情報に基づいて、自サーバの各テーブルを更新し、サービス情報転送部123Aに完了を通知する(S1302B)。
サーバ110Cのサービス情報管理部121Cに含まれるサービス情報転送部123Cは、S1302Bの処理と同様に自サーバの各テーブルを更新し、サービス情報転送部123Aに完了を通知する(S1302C)。
サービス情報転送部123Aは、各サーバから完了通知を受信すると、サービス変更を終了する。
次に、図17を参照しながら、状態が「追加系」であるサーバに処理データを転送する手順と、処理データ転送中にサービスを処理した場合に処理結果を転送する手順について説明する。
図17は、本発明の第1の実施の形態の状態が「追加系」であるサーバに処理データを転送する手順を説明する図である。
図17に示す処理が実行される前に、前提として、図15にて説明したサーバ追加処理が完了しており、同一クラスタ内には、状態が「実行系」であるサーバ110A、状態が「追加系」であるサーバ110B及び状態が「待機系」であるサーバ110Cが含まれている。図17では、サーバ110A又はサーバ110Cから、サービスグループSG_Bに属するサービスで使用される処理データが転送される場合について説明する。
サーバ110Aのクラスタ情報管理部118Aは、まず、状態が「待機系」であるサーバ110Cのうち1つに対し、サーバ110Bに処理データを転送させるための処理データ転送要求を送信する。なお、状態が「実行系」であるサーバ110Aが処理データをサーバ110Bに転送するようにしてもよい。ただし、この場合には、サーバ110Aは処理データ転送要求をサーバ110Cに送信せずに、S1401以降の処理はサーバ110Aによって実行される。
サーバ110Cのクラスタ情報管理部118Cは、クラスタ情報管理部118Aによって送信された処理データ転送要求を受信し、サーバ110Cの処理データ管理部111Cに処理データ転送を指示する。
サーバ110Cの処理データ管理部111Cは、処理データ転送指示を受け付けると、サーバ110Bに処理データ115の送信を開始する(S1401)。この後、サーバ110Cのステータスは、「処理データ転送中」に設定される。
サーバ110Bの処理データ管理部111Bは、サーバ110Cから送信された処理データ115の受信を開始する(S1402)。この後、サーバ110Bのステータスは、「処理データ転送中」に設定される。
サーバ110Aの処理データ管理部111Aは、クライアント101から送信された処理要求電文200を受信すると、図14のS1103Aの処理と同様に、要求された処理を実行する。サーバ110Aのクラスタ情報管理部118Aは、処理結果情報400をマルチキャストで同一クラスタ内のサーバに送信する。
サーバ110B及びサーバ110Cは、「処理データ転送中」のステータスの場合に、処理結果情報400をサーバ110Aから受信すると、受信した処理結果情報400を処理結果情報バッファ117に格納し、処理結果の反映を保留する(S1403)。
サーバ110Bの処理データ管理部111Bは、サーバ110Cの処理データ管理部111Cから送信された処理データの受信を完了すると、サーバ110Cに処理データの受信完了を通知する(S1404)。
サーバ110Cの処理データ管理部111Cは、処理データ管理部111Bから処理データ受信完了の通知を受信すると、処理データの送信を終了する(S1405)。ここで、送信した処理データをメモリ27から削除することによって使用メモリリソースを削減するようにしてもよい。
処理データ管理部111B及び処理データ管理部111Cは、処理データの転送が完了すると、「処理データ転送中」ステータスを解除する。「処理データ転送中」ステータスが解除されると、サーバ110Bの状態が「追加系」に、サーバ110Cの状態が「待機系」になる。さらに、図14のS1106の処理と同様に、処理結果情報バッファ117に格納されている処理結果情報400を処理データ115に反映させ、処理データ管理部111Aに通知する(S1406B、S1406C)。
サーバ110Aの処理データ管理部111Aは、状態が「追加系」であるサーバ110B、及び処理データ転送要求の送信先であるサーバ110Cから処理結果情報反映の完了通知を受信し、処理データの転送及び処理結果の反映が終了したことを確認する(S1408)。
サーバ110Aのクラスタ情報管理部118Aは、クラスタ情報テーブル120を作成及び更新する(S1409)。具体的には、クラスタ情報テーブルの状態603を参照し、追加系とそれ以外の状態(既存の系)について、それぞれクラスタ情報テーブル120を作成する。作成されたクラスタ情報テーブル120は、既存の系については図21、追加系については図22に示すようになる。また、追加系のクラスタ情報テーブル120を作成する場合には、いずれか1つを実行系に、他を待機系に設定する。
サーバ110Aのクラスタ情報管理部118Aは、図21に示すようにクラスタ情報テーブル120を更新し、さらに作成されたクラスタ情報テーブル120をサーバ110B及びサーバ110Cに転送する。サーバ110Bは、図22に示すようにクラスタ情報テーブル120を更新する(S1410B)。サーバ110Cは、図21に示すようにクラスタ情報テーブル120に更新する(S1410C)。
サーバ110Aのクラスタ情報管理部118Aは、サービス情報管理部121Aのサービス情報転送部123Aにサービス変更要求を送信する。
サービス情報転送部123Aは、図16に示したサービス変更処理を実行し、クラスタ情報管理部118Aに完了を通知する(S1411)。
サービス変更処理では、サーバ110A及びサーバ110CがサービスグループSG_Aに属するサービスのみを処理するように処理サービスグループID126、サービス情報テーブル124及びサービスグループ情報テーブル125が変更される。
具体的には、サーバ110A及びサーバ110Cの処理サービスグループID126にはSG_A(図27)、サービス情報テーブル124にはサービスグループSG_Aに属するサービス(図23)、さらに、サービスグループ情報テーブル125にはSG_A(図25)が、それぞれ設定される。
なお、サーバ110Bについては、処理サービスグループID126、サービス情報テーブル124及びサービスグループ情報テーブル125を変更する必要はない。このとき、サーバ110Bの処理サービスグループIDにはSG_B(図28)、サービス情報テーブル124にはサービスグループSG_Bに属するサービス(図24)、サービスグループ情報テーブル125にはSB_B(図26)が設定されている。
最後に、クラスタ情報管理部118Aは、サービス変更の完了の通知を受信すると、サーバ110BへのサービスグループSG_Bの移行が完了する。
ここで、以上の処理によってサービスグループSG_Bの移行が完了した後の処理について説明する。
スケールアウト後は、クラスタ情報テーブル120に基づいて、各サーバ110は実行系及び待機系のサーバとして稼働する。実行系のサーバ110がクライアント101からの処理要求電文200を受信すると、図14のS1103Aの処理で説明したように、処理対象のサービスであれば処理を実行し、処理結果情報400をマルチキャストで他のサーバ110に転送する。待機系のサーバ110は、マルチキャスト送信された処理結果情報400を受信すると、図14のS1106の処理で説明したように、処理データ115に反映させる必要があれば、受信した処理結果情報400に基づいて処理データ115を更新する。処理結果情報400を処理データ115に反映させる必要がなければ、受信した処理結果情報400を破棄する。また、実行系のサーバ110が受信した処理要求電文200が処理対象のサービスでない場合には、図14のS1108Aの処理で説明したように、受信した処理要求電文200を破棄する。
図18は、本発明の第1の実施の形態の処理結果情報を処理データに反映させる手順を示すフローチャートである。本処理は、図14に示したS1106の処理に対応する。
サーバ110のデータ転送部114は、処理結果情報400を受信すると、サービス情報管理部121のサービス情報転送部123にサービスグループ情報テーブル125の取得を要求する(S1601)。S1601の処理で取得されたサービスグループ情報テーブル125を参照することによって、処理結果情報400を受信したサーバ110が処理するサービスグループを特定することができる。
次に、サーバ110の処理実行部113は、サービスグループ情報テーブル125を検索し、処理結果情報400に含まれるサービスID404がサービスグループ情報テーブル125に含まれるサービスID702に一致するか否かを判定する(S1602)。処理結果情報400に含まれるサービスID404がサービスグループ情報テーブル125に含まれるサービスID702に一致する場合には(S1602の結果が「Yes」)、処理結果情報400に含まれる処理結果403を処理データ115に反映させる(S1603)。処理結果情報400に含まれるサービスID404がサービスグループ情報テーブル125に含まれるサービスID702に一致しない場合には(S1602の結果が「No」)、受信した処理結果情報400を破棄する(S1604)。
図19は、本発明の第1の実施の形態の処理要求電文を受信する手順を示すフローチャートである。本処理は、図14に示したS1103Aの処理に対応する。
サーバ110のデータ転送部114は、処理要求電文200を受信すると、サービス情報管理部121のサービス情報転送部123にサービスグループ情報テーブル125の取得を要求する(S1701)。S1701の処理で取得されたサービスグループ情報テーブル125を参照することによって、処理要求電文200を受信したサーバ110が処理するサービスグループを特定することができる。
次に、サーバ110の処理実行部113は、サービスグループ情報テーブル125を検索し、処理を要求されたサービスがサービスグループ情報テーブル125に含まれるか否かを判定する(S1702)。処理を要求されたサービスがサービスグループ情報テーブル125に含まれる場合には(S1702の結果が「Yes」)、受信した処理要求電文200に基づいて要求された処理を実行する(S1703)。処理を要求されたサービスがサービスグループ情報テーブル125に含まれていない場合には(S1702の結果が「No」)、受信した処理要求電文200を破棄する(S1704)。
図20は、本発明の第1の実施の形態のサービスグループ情報テーブル125を作成する手順を示すフローチャートである。本処理は、図15に示したS1201の処理に対応する。
サーバ110のサービス情報判断部122は、サーバ110の負荷が閾値を超えたことを検知すると、サービスグループ情報テーブル125の作成処理を実行する。まず、サービス情報テーブル124の使用テーブルID802の値が一致するサービスIDをまとめる(S1801)。S1801の処理によって、使用テーブルが干渉するサービス、すなわち、共通のテーブルを利用するサービスを複数のグループにまとめることができる。
次に、サーバ110のサービス情報判断部122は、新たに作成するサービスグループの数だけサービスグループID701を作成する。作成するサービスグループIDの数はあらかじめ設定しておく。さらに、S1801の処理でまとめられたサービスを、サービスグループごとに負荷の合計が可能な限り均等になるように振り分ける(S1802)。例えば、まとめられたサービスの負荷量の合計が大きい順に、負荷合計703の小さいサービスグループに振り分ける。このようにして、サービスで使用されるテーブルが互いに干渉せず、かつ、各負荷合計703がより均等になるようにサービスグループ情報テーブル125を作成することができる。
図21は、本発明の第1の実施の形態のスケールアウト後の既存の系のクラスタ情報テーブル120の内容を示す図である。
図21に示すクラスタ情報テーブル120の構成は、図8に示したクラスタ情報テーブル120と同じである。また、図21に示すクラスタ情報テーブル120に格納されたデータについては、図17のS1409の処理で説明したとおりである。
図22は、本発明の第1の実施の形態のスケールアウト後の追加系のクラスタ情報テーブル120の内容を示す図である。
図22に示すクラスタ情報テーブル120の構成は、図8に示したクラスタ情報テーブル120と同じである。また、図22に示すクラスタ情報テーブル120に格納されたデータについては、図17のS1409の処理で説明したとおりである。
図23は、本発明の第1の実施の形態のスケールアウト後の既存の系のサービス情報テーブル124の内容を示す図である。
図23に示すサービス情報テーブル124の構成は、図10に示したサービス情報テーブル124と同じである。また、図23に示すサービス情報テーブル124に格納されたデータについては、図17のS1411の処理で説明したとおりである。
図24は、本発明の第1の実施の形態のスケールアウト後の追加系のサービス情報テーブル124の内容を示す図である。
図24に示すサービス情報テーブル124の構成は、図10に示したサービス情報テーブル124と同じである。また、図24に示すサービス情報テーブル124に格納されたデータについては、図17のS1411の処理で説明したとおりである。
図25は、本発明の第1の実施の形態のスケールアウト後の既存の系のサービスグループ情報テーブル125の内容を示す図である。
図25に示すサービスグループ情報テーブル125の構成は、図9に示したサービスグループ情報テーブル125と同じである。また、図25に示すサービスグループ情報テーブル125に格納されたデータについては、図17のS1411の処理で説明したとおりである。
図26は、本発明の第1の実施の形態のスケールアウト後の追加系のサービスグループ情報テーブル125の内容を示す図である。
図26に示すサービスグループ情報テーブル125の構成は、図9に示したサービスグループ情報テーブル125と同じである。また、図26に示すサービスグループ情報テーブル125に格納されたデータについては、図17のS1411の処理で説明したとおりである。
図27は、本発明の第1の実施の形態のスケールアウト後の既存の系の処理サービスグループID126の内容を示す図である。
図27に示す処理サービスグループID126の構成は、図11に示した処理サービスグループID126と同じである。また、図27に示す処理サービスグループID126に格納されたデータについては、図17のS1411の処理で説明したとおりである。
図28は、本発明の第1の実施の形態のスケールアウト後の追加系の処理サービスグループID126の内容を示す図である。
図28に示す処理サービスグループID126の構成は、図11に示した処理サービスグループID126と同じである。また、図28に示す処理サービスグループID126に格納されたデータについては、図17のS1411の処理で説明したとおりである。
本発明の第1の実施の形態によれば、サーバ110が保持されるデータを引き継ぎながら、サービスを処理するサーバを分離することによって負荷分散を図ることができる。
また、本発明の第1の実施の形態によれば、データを引き継ぐ際にコピーされるデータ量を最小限に抑えることでサーバの負荷の増大を抑制することによって、クライアントから要求されたサービスを、リアルタイム性を維持しながら処理することができる。
さらに、本発明の第1の実施の形態によれば、クライアント101からサービスの処理要求がマルチキャストで送信されるため、サーバの構成が変更されてもクライアント側の設定を変更せずにサービスの処理要求を継続することができる。
<第2の実施の形態>
本発明の第1の実施の形態では、負荷量が所定の上限値を超えたサーバ110で実行されるサービスを他のサーバ110に振り分けることによって負荷分散を図っていたが、第2の実施の形態では、負荷の少ないサーバを集約(マージ)することによって、計算機資源を有効に利用する。このようにサーバを集約することをスケールインという。
なお、第2の実施の形態において、第1の実施の形態と共通する内容については適宜説明を省略する。
第2の実施の形態のシステム構成は、図1及び図2に示した第1の実施の形態と同じである。また、テーブル及び電文の構成についても図4から図12に示した第1の実施の形態と同じである。
第2の実施の形態における処理の手順について説明する。なお、クライアント101から送信された処理要求に基づいて、サーバ110がサービスを実行する手順については、第1の実施の形態の図14に示した手順と同じである。
ここで、処理手順の説明する前に、第2の実施の形態の計算機システムの構成について説明すると、計算機システムには、実行系のサーバ110D及び待機系のサーバ110Fが同一クラスタ内に含まれ、いずれもサービスグループSG_Aを処理する。また、同一マルチキャストアドレスを受信する実行系のサーバ110Eが当該計算機システムに含まれ、サービスグループSG_Bを処理する。以下、サーバ110Dの負荷が減少し、サービスグループSG_Aの処理主体をサーバ110Eに移行する手順を、図29を参照しながら説明する。
図29は、本発明の第2の実施の形態のスケールインを実行するための準備処理の手順を説明する図である。
状態が「実行系」であるサーバ110Dのサービス情報判断部122Dは、サーバ110Dの負荷量があらかじめ設定された閾値(下限値)を下回ったことを検知すると、クラスタ情報処理部119Dに通知する(S30101)。具体的には、サーバ110Dのシステムログなどに含まれるCPU使用率、メモリ使用率及び入出力処理量などに基づいて負荷量を算出し、負荷量閾値テーブル127に設定されている閾値(この場合は下限値)と比較する。
クラスタ情報処理部119Dは、サービス情報判断部122Dから負荷量が下限値を下回った旨の通知を受信すると、マージ可否応答電文要求をマルチキャストによって送信する(S30102)。マージ可否応答電文要求は、図12の追加サーバ応答要求電文1000と同様の構成であり、電文種別1001を「マージ可否応答要求」とし、電文内容1002には、自サーバ(サーバ110D)のアドレスが格納される。
サーバ110Fは、状態が「待機系」であり、かつ、サービスグループSG_Aを処理する。すなわち、サーバ110Fの処理サービスグループID126には、SG_Aが含まれている。
サーバ110Fのクラスタ情報管理部118F内のクラスタ情報処理部119Fは、サーバ110Dからマルチキャストにて送信されたマージ可否応答要求電文を受信する(S30103)。クラスタ情報処理部119Fは、自サーバの状態が「待機系」であるため、マージ可否応答要求電文を破棄する。
また、サーバ110Eは、同一マルチキャストを受信し、かつ、サービスグループSG_Bを処理する。サーバ110Eの処理サービスグループID126には、サービスグループSG_Bが含まれているが、SG_Aは含まれていない。
サーバ110Eのクラスタ情報処理部119Eは、サーバ110Dからマルチキャストにて送信されたマージ可否応答要求電文を受信すると、自サーバの状態が「実行系」であるため、マージ可否応答要求電文を送信したサーバ110Dに応答を送信する(S30104)。この応答は、図12の追加サーバ応答要求電文1000と同様の構成であり、電文種別1001を「マージ可能応答」とし、電文内容1002には、自サーバの全サービスの負荷の合計量と、クラスタ情報テーブル120Eを格納する。格納されるクラスタ情報テーブル120Eは図31に示すようになっている。
図31は、本発明の第2の実施の形態の集約先となるサーバ110Eのクラスタ情報テーブル120の内容を示す図である。図31に示すクラスタ情報テーブル120の構成は、図8に示した第1の実施の形態のクラスタ情報テーブル120と同じである。
サーバ110Dは、サーバ110Eから送信された応答を受信する。サーバ110Dは、複数のサーバから同様の応答を受信した場合には、応答に格納された負荷の合計が最も小さいサーバを選択する。ここでは、サーバ110Dはサーバ110Eの応答を選択した場合を想定し、以降の手順を以下に説明する。
サーバ110Dは、応答に含まれるクラスタ情報テーブル120Eに基づいて、サーバ110Dのクラスタ情報テーブル120Dを更新し、更新後のクラスタ情報テーブル120Dをマルチキャストアドレスに送信する(S30105)。具体的には、クラスタ情報テーブル120Dに、クラスタ情報テーブル120Eに含まれるすべてのサーバアドレス602及び状態603を追加する。また、追加されたサーバ110Eの状態を「SG_A追加系かつSG_B実行系」に、それ以外の追加されたサーバの状態を「SG_A追加系かつSG_B待機系」に更新する。更新前のクラスタ情報テーブル120Dを図30に、更新後のクラスタ情報テーブル120Eを図32に示す。
図30は、本発明の第2の実施の形態の集約されるサーバ110Dの更新前のクラスタ情報テーブル120Dの内容を示す図である。図30に示すクラスタ情報テーブル120の構成は、図8に示した第1の実施の形態のクラスタ情報テーブル120と同じである。
図32は、本発明の第2の実施の形態の集約されるサーバ110Eの更新前のクラスタ情報テーブル120Eの内容を示す図である。図32に示すクラスタ情報テーブル120の構成は、図8に示した第1の実施の形態のクラスタ情報テーブル120と同じである。
「SG_A追加系かつSG_B実行系」は、サービスグループSG_Aの処理主体が当該サーバに移動中であり、かつ、当該サーバは状態が「実行系」であるサービスグループSG_Bの処理主体であることを意味する。また、「SG_A追加系かつSG_B待機系」は、サービスグループSG_Aの処理主体が当該サーバに移動中であり、かつ、当該サーバは状態が「待機系」のサービスグループSG_Bの処理主体であることを意味する。
更新後のクラスタ情報テーブル120Dを受信したサーバのクラスタ情報処理部119は、自サーバのクラスタ情報テーブル120の内容を受信したクラスタ情報テーブル120Dと同一になるように更新する(S30106E、S30106F)。更新後、クラスタ情報処理部119は、サーバ110Dにクラスタ情報更新完了を通知する。
サーバ110Dは、クラスタ情報を送信したすべてのサーバからクラスタ情報更新完了を通知された後、サービス情報転送部123Dにサービス変更要求を通知する。
サービス情報転送部123Dは、クラスタ情報処理部119Dからのサービス変更要求を受け付けて、サービス変更処理を実行する(S30107)。サービス変更処理が完了すると、クラスタ情報処理部119Dにその旨を通知する。ここで、サービス変更処理S30107では、図16にて説明した処理に基づいて、サーバ110D、サーバ110E及びサーバ110Fの各処理サービスグループIDがSG_A及びSG_Bに変更される。
クラスタ情報処理部119Dは、サービス情報転送部123Dからサービス変更処理の完了を受け付けると、マージ準備処理を完了する(S30108)。
次に、マージ準備が終了した後に実際にサービスグループをマージする処理について説明する。マージ処理は、図17と同様の手順であるが、クラスタを構成するサーバが相違する。この場合、同一クラスタ内に、実行系のサーバ110D、SG_A追加系かつSG_B実行系のサーバ110E、及び待機系のサーバ110Fが含まれ、サーバ110D又はサーバ110Fからサーバ110Eに、サービスグループSG_Aに関連する処理データを転送する。具体的には、以下の処理が相違する。
サーバ110Dのクラスタ情報管理部118Dは、S1409の処理で、クラスタ情報テーブル120Dを以下のように更新する。クラスタ情報テーブル120Dの状態603を参照し、「SG_A追加系かつSG_B実行系」又は「SG_A追加系かつSG_B待機系」のみを含むテーブルを作成する。そして、いずれか1つのサーバを実行系に、他のサーバを待機系に設定する。例えば、「SG_A追加系かつSG_B実行系」のサーバを実行系に、「SG_A追加系かつSG_B待機系」のサーバを待機系に設定すればよい。なお、クラスタ情報テーブル120Dの状態603が「SG_A追加系かつSG_B実行系」であって、クライアント101からサービスの処理要求を受け付けた場合には、サービスグループSG_Bに属するサービスのみを処理する。
また、サービス情報転送部123Dは、図16に示したサービス変更処理を実行し、完了を通知する。このとき、サービス変更処理では、サーバ110D及びサーバ110Fの各処理サービスグループID126を「なし」、サービス情報テーブル124を空行列に変更する。また、サーバ110Eの処理サービスグループIDにはSG_A及びSG_B、サービス情報テーブル124にはサービスグループSG_A及びSG_Bに属するサービスを格納するように変更する。以上の処理によって、サーバ110Dで処理されていたサービスグループSG_Aに属するサービスのサーバ110Eへの移行が完了する。
本発明の第2の実施の形態によれば、サーバ110の負荷が所定の下限値を下回った場合には、スケールインを実行して必要なサーバを削減することによって限られた計算機資源を有効に活用することができる。
また、本発明の第2の実施の形態によれば、クライアント101からサービスの処理要求がマルチキャストで送信されるため、第1の実施の形態と同様に、サーバの構成が変更されてもクライアント側の設定を変更せずにサービスの処理要求を継続することができる。
さらに、本発明の第2の実施の形態を第1の実施の形態とともに計算機システムに適用することによって、サーバの負荷の状態に応じて動的に構成を変更することができる。
<第3の実施の形態>
本発明の第3の実施の形態では、サービスごとに信頼性レベルをあらかじめ設定し、設定された信頼性レベルに基づいて、スケールアウト又はスケールインの実行時のサーバの増減数を決定する。
なお、第3の実施の形態において、第1の実施の形態又は第2の実施の形態と共通する内容については適宜説明を省略する。
第3の実施の形態のシステム構成は、図1及び図2に示した第1の実施の形態と同じである。
以下、第1の実施の形態との相違点を中心に第3の実施の形態について説明する。
図33は、本発明の第3の実施の形態のサービスグループ情報テーブル125の構成の一例を示す図である。
サービスグループ情報テーブル125は、第1の実施の形態の構成に加え、最大信頼性レベル2704を含む。
最大信頼性レベル2704は、サービスグループID701によって識別されるサービスグループに属するサービスに設定された信頼性レベルの最大値が格納される。すなわち、サービスグループごとに設定されているスケールアウト時に必要なサーバの数となる。
図34は、本発明の第3の実施の形態のサービス情報テーブル124の構成の一例を示す図である。
サービス情報テーブル124は、第1の実施の形態の構成に加え、信頼性レベル2804を含む。信頼性レベルが1のサービスは1つの実行系のみを、信頼性レベルが2のサービスは1つの実行系と1つの待機系を、信頼性レベルが3のサービスは1つの実行系と2つの待機系をそれぞれ必要とする。
次に、サーバ110の負荷が上限値を超えたためにシステムをスケールアウトする場合に、信頼性レベル2804に基づいて実行される処理について説明する。
まず、図15のS1201の処理で最大信頼性レベル2704ができるだけ小さくなるようにサービスをグループ分けする点である。最大信頼性レベル2704を小さくすることによって、追加するサーバの数を少なくすることができる。
最大信頼性レベル2704を小さくする方法は、例えば、図20のS1802の処理でまとめられたサービスを複数のサービスグループ情報テーブル125に振り分ける場合に、各サービスグループの負荷合計が同じ場合、まとめられたサービスの中で最大の信頼性レベル以上の最大信頼性レベル2704のサービスグループに振り分ける。
さらに、図12のS1208の処理で追加されるサーバの数は、第1の実施の形態ではあらかじめ設定されていたが、第3の実施の形態ではS1201の処理で作成したサービスグループ情報テーブル125の中で、一番小さい最大信頼性レベルの値分になる。第3の実施の形態では、図33のサービスグループ情報テーブル125では、サービスグループID701、SG_Bの最大信頼性レベルが一番小さく、値は2である。したがって、追加される系の数は2となる。
以降、スケールアウト処理では、最大信頼性レベル2704が最も小さいサービスグループを、追加された系が処理するようにシステムをスケールアウトする。
さらに、第2の実施の形態との相違点について説明する。
データを転送する際に、マージ可否応答要求電文の応答に自サーバのサービスグループ情報テーブル125の最大信頼性レベル2704の最大値を付加する。マージ可否応答要求電文の送信元のサーバ110Dは、集約先を決定した後、さらに自サーバと決定した集約先サーバの最大信頼性レベルとを比較し、最大信頼性レベルがより小さい方をデータの転送元とする。このように処理することによって、最大信頼性レベルの大きい方にサービス及びデータが集約される。
本発明の第3の実施の形態によれば、サービスごとに要求される信頼性に基づいて、追加又は削減するサーバの数を決定し、負荷状況に加えて処理されるサービスの信頼性に基づいて計算機システムの構成を変更することができる。
本発明の第1の実施の形態の計算機システムの構成の一例を示すブロック図である。 本発明の第1の実施の形態のサーバのハードウェア構成を示すブロック図である。 本発明の第1の実施の形態の計算機システムの構成を管理する手順の概要を説明する図である。 本発明の第1の実施の形態の処理要求電文の一例を示す図である。 本発明の第1の実施の形態の処理要求キューの構成の一例を示す図である。 本発明の第1の実施の形態の処理結果情報の構成の一例を示す図である。 本発明の第1の実施の形態の処理通番の一例を示す図である。 本発明の第1の実施の形態のクラスタ情報テーブルの構成の一例を示す図である。 本発明の第1の実施の形態のサービスグループ情報テーブルの構成の一例を示す図である。 本発明の第1の実施の形態のサービス情報テーブルの構成の一例を示す図である。 本発明の第1の実施の形態の処理サービスグループIDの一例を示す図である。 本発明の第1の実施の形態の追加サーバ応答要求電文の構成の一例を示す図である。 本発明の第1の実施の形態の負荷量閾値テーブルの構成の一例を示す図である。 本発明の第1の実施の形態のクライアントからの処理要求に応じてサーバで処理を実行する手順を説明する図である。 本発明の第1の実施の形態の実行系のサーバをクラスタに追加する手順を説明する図である。 本発明の第1の実施の形態のサービス変更処理の手順を説明する図である。 本発明の第1の実施の形態の状態が「追加系」であるサーバに処理データを転送する手順を説明する図である。 本発明の第1の実施の形態の処理結果情報を処理データに反映させる手順を示すフローチャートである。 本発明の第1の実施の形態の処理要求電文を受信する手順を示すフローチャートである。 本発明の第1の実施の形態のサービスグループ情報テーブルを作成する手順を示すフローチャートである。 本発明の第1の実施の形態のスケールアウト後の既存の系のクラスタ情報テーブルの内容を示す図である。 本発明の第1の実施の形態のスケールアウト後の追加系のクラスタ情報テーブルの内容を示す図である。 本発明の第1の実施の形態のスケールアウト後の既存の系のサービス情報テーブルの内容を示す図である。 本発明の第1の実施の形態のスケールアウト後の追加系のサービス情報テーブルの内容を示す図である。 本発明の第1の実施の形態のスケールアウト後の既存の系のサービスグループ情報テーブルの内容を示す図である。 本発明の第1の実施の形態のスケールアウト後の追加系のサービスグループ情報テーブルの内容を示す図である。 本発明の第1の実施の形態のスケールアウト後の既存の系の処理サービスグループIDの内容を示す図である。 本発明の第1の実施の形態のスケールアウト後の追加系の処理サービスグループIDの内容を示す図である。 本発明の第2の実施の形態のスケールインを実行するための準備処理の手順を説明する図である。 本発明の第2の実施の形態の集約されるサーバの更新前のクラスタ情報テーブルの内容を示す図である。 本発明の第2の実施の形態の集約先となるサーバのクラスタ情報テーブルの内容を示す図である。 本発明の第2の実施の形態の集約されるサーバの更新前のクラスタ情報テーブルの内容を示す図である。 本発明の第3の実施の形態のサービスグループ情報テーブルの構成の一例を示す図である。 本発明の第3の実施の形態のサービス情報テーブルの構成の一例を示す図である。
符号の説明
21 CPU
25 ネットワークインタフェースカード
27 メモリ
100 処理管理部
102 要求送信管理部
110 サーバ
111 処理データ管理部
112 処理要求受信部
113 処理実行部
114 データ転送部
115 処理データ
116 処理要求キュー
117 処理結果情報バッファ
118 クラスタ情報管理部
119 クラスタ情報処理部
120 クラスタ情報テーブル
121 サービス情報管理部
122 サービス情報判断部
123 サービス情報転送部
124 サービス情報テーブル
125 サービスグループ情報テーブル
126 処理サービスグループID
127 負荷量閾値テーブル
200 処理要求電文
400 処理結果情報

Claims (10)

  1. 要求されたサービスを実行可能な複数のサーバを含む計算機システムの構成を管理する方法であって、
    前記サーバは、各サーバ間を接続するインタフェースと、前記インタフェースに接続されたプロセッサと、前記サービスを提供するために必要なデータを格納する記憶部と、を備え、
    同じデータを参照するサービスは、前記複数のサーバにおける同じサーバに割り当てられ、
    前記サーバは、
    前記サーバの負荷が所定の上限値を超えた場合には、前記負荷が上限値を超えたサーバで実行されるサービスの一部を実行させる転送先サーバを選択し、
    前記負荷が上限値を超えたサーバに割り当てられたサービスから一以上のサービスを選択し、
    前記転送先サーバに前記選択されたサービスを割り当て、
    前記選択されたサービスの実行に必要なデータを前記負荷が上限値を超えたサーバから前記転送先サーバに転送し、
    前記サービスの実行要求は、前記複数のサーバにマルチキャストで送信され、
    前記サービスの実行要求を受信した各サーバは、要求されたサービスを実行しない場合は、前記受信したサービスの実行要求を破棄し、
    前記サーバには、サービスの集合単位でサービスが割り当てられ、
    同じデータを参照するサービスは、同じサービスの集合に含まれ、
    前記サーバは、前記負荷が上限値を超えた前記サーバに割り当てられたサービスから、サービスの集合単位で前記転送先サーバに前記サービスを割り当て、
    前記サービスには、前記サービスが必要とするサーバ数を表す信頼性レベルが予め設定されており、
    前記サーバは、前記負荷が下限値以下のサーバに割り当てられているサービス、及び前記集約先サーバに割り当てられているすべてのサービスを、前記負荷が下限値以下のサーバ及び前記集約先サーバのうち、前記信頼性レベルの高いサービスが割り当てられていたサーバに割り当て、
    前記サーバは、前記サービスが割り当てられなかったサーバに対するサービスの割り当てを解除し、
    前記サーバは、前記サービスの割り当てが解除されたサーバに格納されたデータを、前記すべてのサービスが割り当てられたサーバに転送することを特徴とする構成管理方法。
  2. 前記サーバは、前記負荷が上限値を超えた前記サーバに割り当てられたサービスの集合から選択した一部のサービスからなるサービスの集合を分離し、
    前記一部のサービスが参照するデータは、前記サービスの集合における他のサービスが参照するデータと異なり、
    前記サーバは、前記分離されたサービスの集合を前記転送先サーバに割り当てることを特徴とする請求項1に記載の構成管理方法。
  3. 前記複数のサーバには、前記サービスを実行する第1のサーバ、及び前記第1のサーバに障害が発生した場合に前記サービスを実行する第2のサーバが含まれ、
    前記第1のサーバは、前記第1のサーバに格納されたデータが更新された場合には、前記更新されたデータの差分情報を前記第2のサーバに転送し、
    前記第1のサーバ又は前記第2のサーバは、前記第1のサーバの負荷が前記所定の上限値を超えたことによって、前記第1のサーバに格納されたデータを前記転 送先サーバに転送する場合には、前記転送先サーバに前記差分情報をさらに転送することを特徴とする請求項1に記載の構成管理方法。
  4. 前記第1のサーバは、
    前記複数のサーバから、複数の転送先サーバを選択し、
    前記選択された複数の転送先サーバから、前記サービスを実行する第3のサーバを選択し、
    前記選択された複数の転送先サーバに含まれ、かつ、前記第3のサーバとして選択されたサーバ以外のサーバを第4のサーバとし、
    前記第1のサーバ又は前記第2のサーバは、前記第3のサーバ及び第4のサーバに前記差分情報を転送することを特徴とする請求項3に記載の構成管理方法。
  5. 前記サービスには、前記サービスの信頼性を示す信頼性レベルが設定され、
    前記第1のサーバは、前記選択されたサービスに設定された信頼性レベルに基づいて、前記選択される複数の転送先サーバの数を決定することを特徴とする請求項4に記載の構成管理方法。
  6. 前記差分情報は、前記複数のサーバにマルチキャストで送信され、
    前記差分情報を受信した各サーバは、前記受信した差分情報を適用するデータを格納していない場合には、前記受信した差分情報を破棄することを特徴とする請求項3に記載の構成管理方法。
  7. 前記サーバは、前記サービスが割り当てられていないサーバを前記転送先サーバとして選択することを特徴とする請求項1に記載の構成管理方法。
  8. 前記サーバは、前記所定の上限値の設定を受け付けることを特徴とする請求項1に記載の構成管理方法。
  9. 要求されたサービスを実行可能な複数のサーバを含む計算機システムであって、
    前記サーバは、各サーバ間を接続するインタフェースと、前記インタフェースに接続されたプロセッサと、前記サービスを提供するために必要なデータを格納する記憶部と、を備え、
    同じデータを参照するサービスは、前記複数のサーバにおける同じサーバに割り当てられ、
    前記サーバは、
    前記サーバの負荷が所定の上限値を超えた場合には、前記負荷が上限値を超えたサーバで実行されるサービスの一部を実行させる転送先サーバを選択し、
    前記負荷が上限値を超えたサーバに割り当てられたサービスから一以上のサービスを選択し、
    前記転送先サーバに前記選択されたサービスを割り当て、
    前記選択されたサービスの実行に必要なデータを前記負荷が上限値を超えたサーバから前記転送先サーバに転送し、
    前記サービスの実行要求は、前記複数のサーバにマルチキャストで送信され、
    前記サービスの実行要求を受信した各サーバは、要求されたサービスを実行しない場合は、前記受信したサービスの実行要求を破棄し、
    前記各サーバには、サービスの集合単位でサービスが割り当てられ、
    同じデータを参照するサービスは、同じサービスの集合に含まれ、
    前記サーバは、前記負荷が上限値を超えた前記サーバに割り当てられたサービスから、サービスの集合単位で前記転送先サーバに前記サービスを割り当て、
    前記サービスには、前記サービスが必要とするサーバ数を表す信頼性レベルが予め設定されており、
    前記サーバは、前記負荷が下限値以下のサーバに割り当てられているサービス、及び前記集約先サーバに割り当てられているすべてのサービスを、前記負荷が下限値以下のサーバ及び前記集約先サーバのうち、前記信頼性レベルの高いサービスが割り当てられていたサーバに割り当て、
    前記サーバは、前記サービスが割り当てられなかったサーバに対するサービスの割り当てを解除し、
    前記サーバは、前記サービスの割り当てが解除されたサーバに格納されたデータを、前記すべてのサービスが割り当てられたサーバに転送することを特徴とする計算機システム。
  10. 要求されたサービスを実行可能な複数のサーバを含む計算機システムに含まれるサーバで実行される構成管理プログラムであって、
    同じデータを参照するサービスは、前記複数のサーバにおける同じサーバに割り当てられ、
    前記プログラムは、
    前記サーバの負荷が所定の上限値を超えた場合には、前記負荷が上限値を超えたサーバで実行されるサービスの一部を実行させる転送先サーバを選択する手順と、
    前記負荷が上限値を超えたサーバに割り当てられたサービスから一以上のサービスを選択する手順と、
    前記転送先サーバに前記選択されたサービスを割り当てる手順と、
    前記選択されたサービスの実行に必要なデータを前記負荷が上限値を超えたサーバから前記転送先サーバに転送する手順と、を含み、
    前記サービスの実行要求は、前記複数のサーバにマルチキャストで送信され、
    前記プログラムは、受信した前記サービスの実行要求が要求するサービスを実行しない場合は、前記受信したサービスの実行要求を破棄する手順を含み、
    前記サーバには、サービスの集合単位でサービスが割り当てられ、
    同じデータを参照するサービスは、同じサービスの集合に含まれ、
    前記プログラムは、前記負荷が上限値を超えた前記サーバに割り当てられたサービスから、サービスの集合単位で前記転送先サーバに前記サービスを割り当る手順を含み、
    前記サービスには、前記サービスが必要とするサーバ数を表す信頼性レベルが予め設定されており、
    前記プログラムは、
    前記負荷が下限値以下のサーバに割り当てられているサービス、及び前記集約先サーバに割り当てられているすべてのサービスを、前記負荷が下限値以下のサーバ及び前記集約先サーバのうち、前記信頼性レベルの高いサービスが割り当てられていたサーバに割り当る手順と、
    前記サービスが割り当てられなかったサーバに対するサービスの割り当てを解除する手順と、
    前記サービスの割り当てが解除されたサーバに格納されたデータを、前記すべてのサービスが割り当てられたサーバに転送する手順と、を含むことを特徴とする構成管理プログラム。
JP2008307203A 2008-12-02 2008-12-02 計算機システムの構成管理方法、計算機システム及び構成管理プログラム Expired - Fee Related JP4772854B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008307203A JP4772854B2 (ja) 2008-12-02 2008-12-02 計算機システムの構成管理方法、計算機システム及び構成管理プログラム
US12/457,578 US20100138540A1 (en) 2008-12-02 2009-06-16 Method of managing organization of a computer system, computer system, and program for managing organization

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008307203A JP4772854B2 (ja) 2008-12-02 2008-12-02 計算機システムの構成管理方法、計算機システム及び構成管理プログラム

Publications (2)

Publication Number Publication Date
JP2010134518A JP2010134518A (ja) 2010-06-17
JP4772854B2 true JP4772854B2 (ja) 2011-09-14

Family

ID=42223794

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008307203A Expired - Fee Related JP4772854B2 (ja) 2008-12-02 2008-12-02 計算機システムの構成管理方法、計算機システム及び構成管理プログラム

Country Status (2)

Country Link
US (1) US20100138540A1 (ja)
JP (1) JP4772854B2 (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5653151B2 (ja) * 2010-09-17 2015-01-14 キヤノン株式会社 クラウドコンピューティングシステム、クラウドコンピューティングシステムの制御方法、および管理アプリケーション
US8725913B2 (en) 2010-09-17 2014-05-13 Oracle International Corporation Numa I/O framework
US20120102185A1 (en) * 2010-10-20 2012-04-26 Sony Computer Entertainment America Inc. Resource management of server hosts in online game environment
JP5414663B2 (ja) * 2010-12-24 2014-02-12 株式会社東芝 サービス提供システム、装置及びプログラム
JP5775359B2 (ja) * 2011-05-11 2015-09-09 キヤノン株式会社 システム管理サーバ、管理方法及びプログラム
JP5927871B2 (ja) * 2011-11-30 2016-06-01 富士通株式会社 管理装置、情報処理装置、管理プログラム、管理方法、プログラムおよび処理方法
KR20140060637A (ko) * 2012-11-12 2014-05-21 인포뱅크 주식회사 부하 분산 방법, 시스템 및 장치
US8879718B2 (en) * 2012-12-04 2014-11-04 Genesys Telecommunications Laboratories, Inc. Distributed event delivery
US20140337472A1 (en) 2012-12-13 2014-11-13 Level 3 Communications, Llc Beacon Services in a Content Delivery Framework
US10652087B2 (en) 2012-12-13 2020-05-12 Level 3 Communications, Llc Content delivery framework having fill services
US9628346B2 (en) 2012-12-13 2017-04-18 Level 3 Communications, Llc Devices and methods supporting content delivery with reducer services
US9634918B2 (en) 2012-12-13 2017-04-25 Level 3 Communications, Llc Invalidation sequencing in a content delivery framework
US10701148B2 (en) 2012-12-13 2020-06-30 Level 3 Communications, Llc Content delivery framework having storage services
US10701149B2 (en) 2012-12-13 2020-06-30 Level 3 Communications, Llc Content delivery framework having origin services
US10791050B2 (en) 2012-12-13 2020-09-29 Level 3 Communications, Llc Geographic location determination in a content delivery framework
JP6754115B2 (ja) 2017-03-08 2020-09-09 日本電気株式会社 選択装置、装置選択方法、プログラム
CN110769040B (zh) * 2019-10-10 2022-07-29 北京达佳互联信息技术有限公司 一种访问请求的处理方法、装置、设备及存储介质
WO2021131782A1 (ja) * 2019-12-26 2021-07-01 ソニーグループ株式会社 情報処理システムおよび情報処理方法、並びにプログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07334468A (ja) * 1994-06-07 1995-12-22 Toshiba Corp 負荷分散方式
JPH10171673A (ja) * 1996-12-13 1998-06-26 Hitachi Ltd ネットワーク利用方法
US7574499B1 (en) * 2000-07-19 2009-08-11 Akamai Technologies, Inc. Global traffic management system using IP anycast routing and dynamic load-balancing
JP4524523B2 (ja) * 2000-11-10 2010-08-18 ソニー株式会社 記憶媒体、ダウンロード方法及び端末装置
US7216154B1 (en) * 2000-11-28 2007-05-08 Intel Corporation Apparatus and method for facilitating access to network resources
JP2005004676A (ja) * 2003-06-16 2005-01-06 Fujitsu Ltd 適応型分散処理システム
US7454503B2 (en) * 2004-04-08 2008-11-18 International Business Machines Corporation Method to identify transactions and manage the capacity to support the transaction
JP5050854B2 (ja) * 2005-09-20 2012-10-17 日本電気株式会社 資源量計算システム、方法およびプログラム
US8260924B2 (en) * 2006-05-03 2012-09-04 Bluetie, Inc. User load balancing systems and methods thereof
JP4905120B2 (ja) * 2006-12-27 2012-03-28 富士通株式会社 負荷集約プログラム、該プログラムを記録した記録媒体、負荷集約装置および負荷集約方法
JP5112709B2 (ja) * 2007-01-29 2013-01-09 日特エンジニアリング株式会社 コイル巻線装置及び方法
JP2008197907A (ja) * 2007-02-13 2008-08-28 Toshiba Corp 監視ネットワークシステムおよびデータバックアップ方法

Also Published As

Publication number Publication date
US20100138540A1 (en) 2010-06-03
JP2010134518A (ja) 2010-06-17

Similar Documents

Publication Publication Date Title
JP4772854B2 (ja) 計算機システムの構成管理方法、計算機システム及び構成管理プログラム
US10652319B2 (en) Method and system for forming compute clusters using block chains
US7680848B2 (en) Reliable and scalable multi-tenant asynchronous processing
JP4455137B2 (ja) 記憶サブシステム管理方法
US20060048157A1 (en) Dynamic grid job distribution from any resource within a grid environment
US20220318071A1 (en) Load balancing method and related device
US11055142B1 (en) Flexible computing
JP2015537307A (ja) コンポーネント指向ハイブリッドクラウドオペレーティングシステムのアーキテクチャ及びその通信方法
WO2014183531A1 (zh) 一种分配远程内存的方法及装置
Garala et al. A performance analysis of load Balancing algorithms in Cloud environment
KR102247249B1 (ko) 데이터베이스 관리 시스템에서 비동기적 데이터 처리를 위한 컴퓨터 프로그램
CN115408100A (zh) 容器集群调度的方法、装置、设备及存储介质
CN110569302A (zh) 一种基于lucene的分布式集群的物理隔离的方法及装置
WO2002065230A2 (en) Non-hierarchical collaborative computing platform
CN111432006A (zh) 一种轻量级资源虚拟化与分配方法
CN109005071B (zh) 一种决策部署方法和调度设备
CN114911602A (zh) 一种服务器集群的负载均衡方法、装置、设备和存储介质
CN109298949B (zh) 一种分布式文件系统的资源调度系统
CN116954816A (zh) 容器集群控制方法、装置、设备及计算机存储介质
US20230155958A1 (en) Method for optimal resource selection based on available gpu resource analysis in large-scale container platform
US8918555B1 (en) Adaptive and prioritized replication scheduling in storage clusters
CN112001800B (zh) 在区块链系统中进行业务处理的方法和装置
CN114064317A (zh) 分布式系统中的节点调用方法及相关装置
US20170118082A1 (en) Systems and methods for an intelligent, distributed, autonomous, and scalable resource discovery, management, and stitching
Tasneem et al. An insight into load balancing in cloud computing

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20101014

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101019

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101217

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110222

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110421

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: 20110524

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110622

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140701

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4772854

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees