特許 6696927 クラスタシステム、クラスタシステムのアップデート管理装置、アップデート振分装置、アップデート管理方法、アップデート振分方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6696927

(24)【登録日】2020年4月27日

(45)【発行日】2020年5月20日

(54)【発明の名称】クラスタシステム、クラスタシステムのアップデート管理装置、アップデート振分装置、アップデート管理方法、アップデート振分方法及びプログラム

(51)【国際特許分類】

   G06F 8/65 20180101AFI20200511BHJP

   G06F 8/60 20180101ALI20200511BHJP

   G06F 9/50 20060101ALI20200511BHJP

   G06F 13/00 20060101ALI20200511BHJP

【ＦＩ】

   G06F8/65

   G06F8/60

   G06F9/50 150A

   G06F13/00 530B

【請求項の数】3

【全頁数】15

(21)【出願番号】特願2017-54564(P2017-54564)

(22)【出願日】2017年3月21日

(65)【公開番号】特開2018-156555(P2018-156555A)

(43)【公開日】2018年10月4日

【審査請求日】2017年3月21日

【審判番号】不服2019-1219(P2019-1219/J1)

【審判請求日】2019年1月30日

(73)【特許権者】

【識別番号】399041158

【氏名又は名称】西日本電信電話株式会社

(74)【代理人】

【識別番号】110001634

【氏名又は名称】特許業務法人 志賀国際特許事務所

(72)【発明者】

【氏名】横井 正俊

(72)【発明者】

【氏名】齋藤 健

(72)【発明者】

【氏名】本多 悠真

【合議体】

【審判長】 仲間 晃

【審判官】 山崎 慎一

【審判官】 松平 英

(56)【参考文献】

【文献】 特開２００４−１６４２３６（ＪＰ，Ａ）

【文献】 特開２０１５−５５９１６（ＪＰ，Ａ）

【文献】 特開２０１２−１９４８９２（ＪＰ，Ａ）

【文献】 金子 雅志 他，「高可用サーバクラスタにおけるシステム更新方式の検討」，電子情報通信学会技術研究報告，社団法人電子情報通信学会，２００９年１１月１３日，第１０９巻 第２７６号，ｐｐ．５−１０

(58)【調査した分野】（Int.Cl.，ＤＢ名）

G06F8/65

G06F8/60

G06F9/50

G06F13/00

(57)【特許請求の範囲】

【請求項1】

サーバ間でセッション維持に必要なデータを共有しているＮ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と、前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムであって、
前記アップデート管理装置は、
前記ソフトウェアのアップデートの指示がなされた場合に、前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて、前記サーバが用いているソフトウェアをアップデートするサーバ管理部、
を備え、
前記アップデート振分装置は、
前記ソフトウェアのアップデート中のサーバに対する処理要求を、前記処理要求に基づいて、ソフトウェアのアップデートがなされた新サーバ、又は、ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し、いずれかのサーバに振り分ける振分部、
を備え、
前記振分部は、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分けるクラスタシステム。

【請求項2】

サーバ間でセッション維持に必要なデータを共有しているＮ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と、前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムが行うアップデート方法であって、
前記アップデート管理装置が、前記ソフトウェアのアップデートの指示がなされた場合に、前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて、前記サーバが用いているソフトウェアをアップデートするサーバ管理ステップ、
前記アップデート振分装置が、前記ソフトウェアのアップデート中のサーバに対する処理要求を、前記処理要求に基づいて、ソフトウェアのアップデートがなされた新サーバ、又は、ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し、いずれかのサーバに振り分ける振分ステップを有し、
前記振分ステップにおいて、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分けるアップデート管理方法。

【請求項3】

請求項１に記載の装置としてコンピュータを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ソフトウェアのアップデートの技術に関する。

【背景技術】

【0002】

従来、Ｗｅｂサーバホスティング等の分野では、データセンタのようなサーバ管理事業者が一括して複数のサーバを管理し、サービス提供事業者をホスティングするＩａａＳ（Infrastructure as a Service）等と呼ばれる形態が知られている（例えば、非特許文献１参照）。一方、電話のようなライフラインサービスでは、二重化により高可用性を実現していた。電話サービスをＩａａＳ上で実現するために、サーバをＮ台クラスタリングしたＮ−Ａｃｔｉｖｅ構成により可用性及び設備利用効率を高める技術が利用されている。（例えば、非特許文献２、特許文献１及び特許文献２参照）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１２−２３０６３８号公報

【特許文献2】特開２０１１−０９６１６１号公報

【非特許文献】

【0004】

【非特許文献1】“Amazon EC2”、［online］、［平成２９年２月２１日検索］、インターネット<URL：http://aws.amazon.com/ec2/>

【非特許文献2】“Infinispan”、［online］、［平成２９年２月２１日検索］、インターネット<URL：http://infinispan.org/>

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、サービス無停止でソフトウェアのアップデートを行う場合、通常はアップデート先へのデータ引き継ぎ処理が必要となる。データ引継処理を行うためには、アップデート先へデータの同期に加えて、アップデート前のデータ形式をアップデート後のデータ形式に変換をする必要がある。

【0006】

上記事情に鑑み、本発明は、クラスタシステムにおいて、ソフトウェアのアップデートを行う際に要する開発コストを削減することができる技術の提供を目的としている。

【課題を解決するための手段】

【0007】

本発明の一態様は、Ｎ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と、前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムであって、前記アップデート管理装置は、前記ソフトウェアのアップデートの指示がなされた場合に、前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて、前記サーバが用いているソフトウェアをアップデートするサーバ管理部、を備え、前記アップデート振分装置は、前記ソフトウェアのアップデート中のサーバに対する処理要求を、前記処理要求に基づいて、ソフトウェアのアップデートがなされた新サーバ、又は、ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し、いずれかのサーバに振り分ける振分部を、を備えるクラスタシステムである。

【0008】

本発明の一態様は、Ｎ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートの指示がなされた場合に、前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて、前記サーバが用いているソフトウェアをアップデートするサーバ管理部、を備え、前記サーバ管理部は、前記サーバの負荷を監視し、前記サーバの負荷が所定の閾値以下になったサーバのサービス提供を停止し、停止したサーバが用いているソフトウェアをアップデートするアップデート管理装置である。

【0009】

本発明の一態様は、Ｎ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と、前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムにおけるアップデート振分装置であって、前記ソフトウェアのアップデート中のサーバに対する処理要求を、前記処理要求に基づいて、ソフトウェアのアップデートがなされた新サーバ、又は、ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し、いずれかのサーバに振り分ける振分部、を備え、前記振分部は、前記処理要求が、一貫性が必要な一連の処理のうち最初の要求である場合には、前記処理要求を、新サーバで処理すべきと判定し、前記新サーバに振り分けるアップデート振分装置である。

【0010】

本発明の一態様は、上記のアップデート振分装置であって、前記振分部は、前記処理要求が、セッション維持が不要な処理要求ではなく、かつ、破棄してよい要求である場合、前記処理要求を新サーバで処理すべきと判定し、前記新サーバに振り分ける。

【0011】

本発明の一態様は、Ｎ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と、前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムが行うアップデート方法であって、前記アップデート管理装置が、前記ソフトウェアのアップデートの指示がなされた場合に、前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて、前記サーバが用いているソフトウェアをアップデートするサーバ管理ステップ、前記アップデート振分装置が、前記ソフトウェアのアップデート中のサーバに対する処理要求を、前記処理要求に基づいて、ソフトウェアのアップデートがなされた新サーバ、又は、ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し、いずれかのサーバに振り分ける振分ステップを有するアップデート管理方法である。

【0012】

本発明の一態様は、Ｎ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートの指示がなされた場合に、前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて、前記サーバが用いているソフトウェアをアップデートするサーバ管理ステップ、を有し、前記サーバ管理ステップにおいて、前記サーバの負荷を監視し、前記サーバの負荷が所定の閾値以下になったサーバのサービス提供を停止し、停止したサーバが用いているソフトウェアをアップデートするアップデート管理方法である。

【0013】

本発明の一態様は、Ｎ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と、前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムにおけるアップデート振分装置が行うアップデート振分方法であって、前記ソフトウェアのアップデート中のサーバに対する処理要求を、前記処理要求に基づいて、ソフトウェアのアップデートがなされた新サーバ、又は、ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し、いずれかのサーバに振り分ける振分ステップを、を有し、前記振分ステップにおいて、前記処理要求が、一貫性が必要な一連の処理のうち最初の要求である場合には、前記処理要求を、新サーバで処理すべきと判定し、前記新サーバに振り分けるアップデート振分方法である。

【0014】

本発明の一態様は、上記の装置としてコンピュータを機能させるためのプログラムである。

【発明の効果】

【0015】

本発明により、クラスタシステムにおいて、ソフトウェアのアップデートを行う際に要する開発コストを削減することが可能となる。

【図面の簡単な説明】

【0016】

【図1】本発明におけるクラスタシステム１００のシステム構成を表す構成図である。

【図2】アップデート振分装置２０の機能構成を表す概略ブロック図である。

【図3】アップデート管理装置４０の機能構成を表す概略ブロック図である。

【図4】サーバ情報ファイルの具体例を示す図である。

【図5】本実施形態におけるソフトウェアのアップデートの方法について説明するための図である。

【図6】本実施形態におけるアップデート振分装置２０の振分処理の流れを示すフローチャートである。

【図7】本実施形態におけるアップデート振分装置２０の振分処理の流れを示すフローチャートである。

【図8】本実施形態におけるアップデート振分装置２０の振分処理の流れを示すフローチャートである。

【図9】本実施形態におけるアップデート振分装置２０の振分処理の流れを示すフローチャートである。

【図10】追加でＮ台のサーバを用意した場合のアップデート方法の方法について説明するための図である。

【発明を実施するための形態】

【0017】

以下、本発明の一実施形態を、図面を参照しながら説明する。
図１は、本発明におけるクラスタシステム１００のシステム構成を表す構成図である。クラスタシステム１００には、外部ネットワーク１を介してクライアント装置１０が接続される。外部ネットワーク１は、例えば、インターネットを用いて構成されてもよい。クライアント装置１０は、パーソナルコンピュータ等の情報処理装置を用いて構成される。クライアント装置１０は、クラスタシステム１００が提供するサービスを利用するユーザが所有する通信装置である。クライアント装置１０は、クラスタシステム１００に対してサービスに対する処理要求を送信する。

【0018】

クラスタシステム１００は、複数のアップデート振分装置２０−１〜２０−Ｍ（Ｍは２以上の整数）、複数のサーバ３０−１〜３０−Ｎ（Ｎは２以上の整数）及びアップデート管理装置４０を備える。クラスタシステム１００は、いわゆるＮ−Ａｃｔｉｖｅ構成のサーバである。以下の説明において、アップデート振分装置２０−１〜２０−Ｍを区別しない場合にはアップデート振分装置２０と記載する。また、以下の説明において、サーバ３０−１〜３０−Ｎを区別しない場合にはサーバ３０と記載する。アップデート振分装置２０と、サーバ３０は、内部ネットワーク５０を介して通信可能に接続される。

【0019】

また、アップデート振分装置２０及びサーバ３０と、アップデート管理装置４０とは、ネットワーク６０を介して通信可能に接続される。内部ネットワーク５０及びネットワーク６０は、どのようなネットワークを用いて構成されてもよい。例えば、内部ネットワーク５０及びネットワーク６０は、ＬＡＮ（Local Area Network）を用いて構成されてもよい。

【0020】

アップデート振分装置２０は、クライアント装置１０からの処理要求を該当するサーバ３０に振り分ける。例えば、アップデート振分装置２０は、処理要求を、ソフトウェアアップデート前のサーバ３０（以下「旧サーバ」という。）、又は、ソフトウェアアップデート後のサーバ３０（以下「新サーバ」という。）に振り分ける。アップデート振分装置２０による処理要求の振分処理についての具体的な方法については後述する。

【0021】

サーバ３０は、パーソナルコンピュータ等の情報処理装置を用いて構成される。サーバ３０は、クライアント装置１０に対してサービスを提供する。サービスとは、例えば、電話のようなライフラインサービス等である。本実施形態では、全てのサーバ３０が同一のサービス（例えば、ライフラインサービス）を提供するサーバである場合を例に説明するが、クラスタ毎に異なるサービスを提供するサーバ３０であってもよい。なお、Ｎ−Ａｃｔｉｖｅ構成のサーバは、セッション維持に必要なデータがサーバ間で共有されている。

【0022】

アップデート管理装置４０は、パーソナルコンピュータ等の情報処理装置を用いて構成される。アップデート管理装置４０は、アップデート振分装置２０及びサーバ３０を管理する。例えば、アップデート管理装置４０は、サーバ３０で用いるソフトウェアのアップデート指示が入力されると、ソフトウェアのアップデートを行う。この際、アップデート管理装置４０は、アップデートの対象となるサーバ３０で処理中のサービスが終了した時点で、該当サーバ３０で用いるソフトウェアをアップデートする。アップデートの具体的な方法については後述する。

【0023】

図２は、アップデート振分装置２０の機能構成を表す概略ブロック図である。
アップデート振分装置２０は、バスで接続されたＣＰＵ（Central Processing Unit）やメモリや補助記憶装置などを備え、負荷分散処理プログラムを実行する。負荷分散処理プログラムの実行によって、アップデート振分装置２０は、振分情報記憶部２０１、更新部２０２、振分部２０３を備える装置として機能する。なお、アップデート振分装置２０の各機能の全て又は一部は、ＡＳＩＣ（Application Specific Integrated Circuit）やＰＬＤ（Programmable Logic Device）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを用いて実現されてもよい。また、負荷分散処理プログラムは、コンピュータ読み取り可能な記録媒体に記録されてもよい。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。また、負荷分散処理プログラムは、電気通信回線を介して送受信されてもよい。

【0024】

振分情報記憶部２０１は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。振分情報記憶部２０１は、振分情報ファイルを記憶する。振分情報ファイルとは、クライアント装置１０からの処理要求を振り分ける際に用いられるファイルである。振分情報ファイルには、サーバ名と、ファイル新旧表示とが対応付けられている。サーバ名は、サーバ３０を特定するための情報である。ファイル新旧表示は、ソフトウェアのアップデートが必要となった場合において、サーバ３０が新サーバであるか旧サーバであるかを示す情報が登録される。振分情報ファイルにおいて、サーバ３０が新サーバである場合にはファイル新旧表示の項目に“新”が登録され、サーバ３０が旧サーバである場合にはファイル新旧表示の項目に“旧”が登録される。なお、ソフトウェアのアップデートが必要ない場合には、ファイル新旧表示の項目には“−”が登録される。

【0025】

更新部２０２は、アップデート管理装置４０からの指示に従って振分情報ファイルを更新する。例えば、更新部２０２は、振分情報ファイル内へのサーバ３０の登録、削除及びファイル新旧表示の項目内の変更を行う。
振分部２０３は、クライアント装置１０から処理要求が受信された場合に、振分情報ファイルを参照して、処理要求を該当するサーバ３０に振り分ける。

【0026】

図３は、アップデート管理装置４０の機能構成を表す概略ブロック図である。
アップデート管理装置４０は、バスで接続されたＣＰＵやメモリや補助記憶装置などを備え、管理プログラムを実行する。管理プログラムの実行によって、アップデート管理装置４０は、コマンド処理部４０１、サーバ情報記憶部４０２、サーバ管理部４０３を備える装置として機能する。なお、アップデート管理装置４０の各機能の全て又は一部は、ＡＳＩＣやＰＬＤやＦＰＧＡ等のハードウェアを用いて実現されてもよい。また、管理プログラムは、コンピュータ読み取り可能な記録媒体に記録されてもよい。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。また、管理プログラムは、電気通信回線を介して送受信されてもよい。

【0027】

コマンド処理部４０１は、クラスタシステム１００に対するサーバの追加又は削除のコマンド、ソフトウェアのアップデートのコマンド及びサーバ３０のサービス開始又はサービス終了のコマンドを受け付け、受け付けたコマンドに応じた処理を行う。
サーバ情報記憶部４０２は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。サーバ情報記憶部４０２は、サーバ情報ファイルを記憶する。サーバ情報ファイルとは、クラスタシステム１００に備えられるサーバ３０に関する情報が登録されたファイルである。

【0028】

図４は、サーバ情報ファイルの具体例を示す図である。
サーバ情報ファイルは、複数のレコードを複数有する。レコードは、サーバ名、サービス及びサーバ負荷の各値を有する。サーバ名の値は、サーバ３０を特定するための情報である。サービスの値は、サーバ３０が提供しているサービス名を表す。サーバ負荷の値は、サーバ３０の負荷の状況を表す。

【0029】

図４に示される例では、サーバ情報ファイルには４つのサーバ名が登録されている。これらのサーバ名は、“サーバＡ”、“サーバＢ”、“サーバＣ”及び“サーバＤ”である。図４において、サーバ情報ファイルの最上段に記録されているレコードは、サーバ名の値が“サーバＡ”、サービスの値が“ライフラインサービス”、サーバ負荷の値が“○○”である。すなわち、サーバ名“サーバＡ”が、“ライフラインサービス”を提供していて、現在のサーバの負荷が“○○”であることが表されている。なお、サーバ情報ファイルの構成は、図４に示す構成に限られず、適宜必要な情報が追加されてもよい。

【0030】

図３に戻って、アップデート管理装置４０の説明を続ける。
サーバ管理部４０３は、サーバ３０を管理する。例えば、サーバ管理部４０３は、コマンド処理部４０１に入力されたコマンドに従って、サーバ３０の追加又は削除、サーバ３０のサービス開始又はサービス終了、サーバ３０が提供するサービスの変更等を行う。また、サーバ管理部４０３は、所定のタイミングで、サーバ３０の稼働状態を監視し、サーバ３０の負荷を取得する。サーバ管理部４０３は、取得した負荷を、サーバ情報ファイルに登録する。所定のタイミングとは、予め設定されたタイミングであってもよいし、コマンドが入力されたタイミングであってもよいし、その他のタイミングであってもよい。

【0031】

次に、図５を用いて、本実施形態におけるソフトウェアのアップデートの方法について説明する。図５は、本実施形態におけるソフトウェアのアップデートの方法について説明するための図である。なお、図５では、ソフトウェアのアップデートの方法について、振分情報ファイルを用いて説明する。図５において、振分情報ファイルには４台のサーバ３０（サーバ名：“Ａ”サーバ、“Ｂ”サーバ、“Ｃ”サーバ及び“Ｄ”サーバ）を示す情報が登録されている。

【0032】

図５（Ａ）は、振分情報ファイルのソフトウェアのアップデート前の状態を示す。例えば、図５（Ａ）の状態を初期状態とする。図５（Ａ）に示す例では、ソフトウェアのアップデートが必要となってしない状態であるため、４台全てのサーバ３０に対してファイル新旧表示の項目には“−”が登録されている。

【0033】

ソフトウェアのアップデートが必要になった場合、すなわちソフトウェアのアップデートのコマンドがアップデート管理装置４０に入力された場合、コマンド処理部４０１はソフトウェアのアップデートが必要である旨を示す通知（以下「アップデート要求」という。）をアップデート振分装置２０に送信する。また、コマンド処理部４０１は、ソフトウェアのアップデートを実行する旨を示す通知（以下「アップデート実行要求」という。）をサーバ管理部４０３に送信する。アップデート要求には、アップデートの対象となるソフトウェアを用いているサーバ３０のサーバ名が含まれる。図５では、アップデート要求に、４台のサーバ３０（サーバ名：“Ａ”サーバ、“Ｂ”サーバ、“Ｃ”サーバ及び“Ｄ”サーバ）のサーバ名が含まれているとする。アップデート実行要求には、アップデートの対象となるソフトウェアを用いているサーバ３０のサーバ名と、アップデートするためのソフトウェアが含まれる。
更新部２０２は、アップデート管理装置４０からアップデート要求を受信すると、振分情報ファイルを参照し、アップデート要求に含まれるサーバ名に該当するサーバ３０のファイル新旧表示の項目を“旧”に更新する。この処理後の振分情報ファイルの一例が図５（Ｂ）である。

【0034】

次に、サーバ管理部４０３は、アップデート実行要求に含まれるサーバ名に該当するサーバ３０の負荷を監視し、負荷が所定の閾値以下になったサーバ３０を停止する。ここでは、“Ｄ”サーバが閾値以下であったとする。この場合、サーバ管理部４０３は、“Ｄ”サーバを停止する。その後、サーバ管理部４０３は、コマンド処理部４０１を介して、サーバ３０を停止したことを示す通知（以下「停止要求」という。）をアップデート振分装置２０に送信する。停止要求には、停止したサーバ３０のサーバ名が含まれる。図５では、停止要求に、“Ｄ”サーバを示す情報が含まれているとする。
更新部２０２は、アップデート管理装置４０から停止要求を受信すると、振分情報ファイルを参照し、停止要求に含まれるサーバ名に該当するサーバ３０を振分情報ファイルから削除する。例えば、更新部２０２は、“Ｄ”サーバに関する情報を含むレコードを振分情報ファイルから削除する。この処理後の振分情報ファイルの一例が図５（Ｃ）である。

【0035】

次に、サーバ管理部４０３は、アップデート実行要求に含まれるソフトウェアを用いて、停止したサーバが用いているソフトウェアをアップデートする。例えば、サーバ管理部４０３は、“Ｄ”サーバが用いているソフトウェアをアップデートする。アップデートが完了した後、サーバ管理部４０３は、コマンド処理部４０１を介して、サーバ３０が用いているソフトウェアのアップデートが完了したことを示す通知（以下「完了通知」という。）をアップデート振分装置２０に送信する。完了通知には、アップデートが完了したサーバ３０のサーバ名が含まれる。図５では、完了通知に、“Ｄ”サーバを示す情報が含まれているとする。

【0036】

更新部２０２は、アップデート管理装置４０から完了通知を受信すると、振分情報ファイルに、完了通知に含まれるサーバ名を新たに登録する。この際、更新部２０２は、新たに登録したサーバ３０のファイル新旧表示の項目に“新”を登録する。この処理では、更新部２０２は、振分情報ファイルのサーバ名に“Ｄ”サーバ、ファイル新旧表示の項目に“新”を登録する。この処理後の振分情報ファイルの一例が図５（Ｄ）である。このとき以降にアップデート振分装置２０で受信したクライアントからの処理要求は、後述する振り分け方法に従いサーバ３０に処理を振り分ける。

【0037】

サーバ管理部４０３は、上記のように、サーバ３０の負荷の低下に伴い順次サーバ３０を停止したのち、ソフトウェアのアップデートを行う。この処理を繰り返すことによって、最後に最低１台以上のサーバ３０のファイル新旧表示の項目が“旧”の状態となる。図５（Ｅ）の例では、“Ａ”サーバのみがファイル新旧表示の項目が“旧”である。ファイル新旧表示の項目が“旧”のサーバでの処理が終了した時点、もしくは、手動等により強制的にファイル新旧表示の項目が“旧”のサーバでの処理を終了させた時点で、サーバ管理部４０３は最後に残った“Ａ”サーバを停止する。その後、サーバ管理部４０３は、コマンド処理部４０１を介して、停止要求をアップデート振分装置２０に送信する。この処理における停止要求には、“Ａ”サーバを示す情報が含まれている。
更新部２０２は、アップデート管理装置４０から停止要求を受信すると、振分情報ファイルを参照し、停止要求に含まれるサーバ名に該当するサーバ３０を振分情報ファイルから削除する。例えば、更新部２０２は、“Ａ”サーバに関する情報を含むレコードを振分情報ファイルから削除する。この処理後の振分情報ファイルの一例が図５（Ｆ）である。

【0038】

次に、サーバ管理部４０３は、アップデート実行要求に含まれるソフトウェアを用いて、停止したサーバが用いているソフトウェアをアップデートする。例えば、サーバ管理部４０３は、“Ａ”サーバが用いているソフトウェアをアップデートする。アップデートが完了した後、サーバ管理部４０３は、コマンド処理部４０１を介して、完了通知をアップデート振分装置２０に送信する。この処理における完了通知には、“Ａ”サーバを示す情報が含まれているとする。
更新部２０２は、アップデート管理装置４０から完了通知を受信すると、振分情報ファイルに、完了通知に含まれるサーバ名を新たに登録する。この際、更新部２０２は、新たに登録したサーバ３０のファイル新旧表示の項目に“新”を登録する。この処理では、更新部２０２は、振分情報ファイルのサーバ名に“Ａ”サーバ、ファイル新旧表示の項目に“新”を登録する。この処理後の振分情報ファイルの一例が図５（Ｇ）である。
以上の処理により、振分情報ファイルのファイル新旧表示の項目が全て“新”となる。これでアップロードが終了する。その後、振分情報記憶部２０１は、振分情報ファイルを初期状態に更新する。この処理後の振分情報ファイルの一例が図５（Ｈ）である。

【0039】

図６〜９は、本実施形態におけるアップデート振分装置２０の振分処理の流れを示すフローチャートである。
振分部２０３は、クライアント装置１０から処理要求が受信されると、振分情報ファイルを参照し、ファイル新旧表示の項目が“−”もしくは全て“旧”であるか否か判定する（ステップＳ１０１）。ファイル新旧表示の項目が“−”もしくは全て“旧”である場合（ステップＳ１０１−ＹＥＳ）、振分部２０３は通常の負荷分散処理（ラウンドロビン等）を行う（ステップＳ１０２）。その後、アップデート振分装置２０は図６の処理を終了する。

【0040】

一方、ファイル新旧表示の項目が“−”、又は、一部が“旧”、又は、全てが“新”である場合（ステップＳ１０１−ＮＯ）、振分部２０３は処理要求が、一貫性が必要な一連の処理（例えば、セッション維持が必要な処理要求）のうち最初の要求（例えば、ＳＩＰ（Session Initiation Protocol）プロトコルのinvite）であるか否か判定する（ステップＳ１０３）。処理要求が最初の要求である場合（ステップＳ１０３−ＹＥＳ）、振分部２０３はファイル新旧表示の項目が“新”のサーバ３０（新サーバ）に対して通常の負荷分散処理を行う（ステップＳ１０４）。

【0041】

一方、処理要求が最初の要求ではない場合（ステップＳ１０３−ＮＯ）、振分部２０３は処理要求が、セッション維持が不要な処理の要求であるか否か判定する（ステップＳ１０５）。セッション維持が不要な処理の要求である場合（ステップＳ１０５−ＹＥＳ）、振分部２０３はステップＳ１０４の処理を行う。
一方、セッション維持が不要な処理の要求ではない場合、すなわちセッション維持が必要な処理の要求である場合（ステップＳ１０５−ＮＯ）、振分部２０３は処理要求を破棄してよい場合か否かを判定する（ステップＳ１０６）処理要求を破棄してよい場合（ステップＳ１０６−ＹＥＳ）、振分部２０３は処理要求を新サーバに負荷分散処理を行う（ステップＳ１０７）。ここで、セッション維持が必要な処理の要求だが、処理要求を破棄してよい場合とは、例えばＳＩＰプロトコルのConfirmed Daialogを呼救済とした場合でのＡＣＫ以前の処理要求である。

【0042】

また、ステップＳ１０６の処理において、処理要求を破棄してはならない場合（ステップＳ１０６−ＮＯ）、振分部２０３は前回の処理要求時に処理したサーバ３０の情報（例えば、ＳＩＰプロトコルのRecord-Routeヘッダ）と一致するサーバ３０があるか否か判定する（ステップＳ１０８）。前回の処理要求時に処理したサーバ３０がある場合（ステップＳ１０８−ＹＥＳ）、振分部２０３は前回処理したサーバ３０に処理要求を振り分ける（ステップＳ１０９）。その後、振分部２０３は、前回処理したサーバ３０に前回処理した情報があるか否か判定する（ステップＳ１１０）。前回処理したサーバ３０に前回処理した情報がある場合（ステップＳ１１０−ＹＥＳ）、アップデート振分装置２０は振分処理を終了する。例えば、振分部２０３は、前回処理したサーバ３０から処理要求を処理することができない旨の通知を取得しなかった場合に前回処理したサーバ３０に前回処理した情報があると判定する。
一方、前回処理したサーバ３０に前回処理した情報がない場合（ステップＳ１１０−ＮＯ）、振分部２０３はファイル新旧表示の項目が異なる内容のサーバ３０に負荷分散処理する（ステップＳ１１１）。例えば、振分部２０３は、前回処理したサーバ３０から処理要求を処理することができない旨の通知を取得した場合に前回処理したサーバ３０に前回処理した情報がないと判定する。

【0043】

次に、振分部２０３は、ファイル新旧表示の項目が異なる内容のサーバ３０に前回処理した情報があるか否か判定する（ステップＳ１１２）。ファイル新旧表示の項目が異なる内容のサーバ３０に前回処理した情報がある場合（ステップＳ１１２−ＹＥＳ）、アップデート振分装置２０は振分処理を終了する。
一方、ファイル新旧表示の項目が異なる内容のサーバ３０に前回処理した情報がない場合（ステップＳ１１２−ＮＯ）、振分部２０３は処理要求を破棄する（ステップＳ１１３）。その後、アップデート振分装置２０は振分処理を終了する。

【0044】

また、ステップＳ１０８の処理において、前回の処理要求時に処理したサーバ３０がない場合（ステップＳ１０８−ＮＯ）、振分部２０３は旧サーバに負荷分散処理を行う（ステップＳ１１４）。その後、振分部２０３は、ファイル新旧表示の項目が“旧”のサーバ３０に前回処理した情報があるか否か判定する（ステップＳ１１５）。ファイル新旧表示の項目が“旧”のサーバ３０に前回処理した情報がある場合（ステップＳ１１５−ＹＥＳ）、アップデート振分装置２０は振分処理を終了する。
一方、ファイル新旧表示の項目が“旧”のサーバ３０に前回処理した情報がない場合（ステップＳ１１５−ＮＯ）、振分部２０３は新サーバ３０に負荷分散処理する（ステップＳ１１６）。

【0045】

その後、振分部２０３は、ファイル新旧表示の項目が“新”のサーバ３０に前回処理した情報があるか否か判定する（ステップＳ１１７）。ファイル新旧表示の項目が“新”のサーバ３０に前回処理した情報がある場合（ステップＳ１１７−ＹＥＳ）、アップデート振分装置２０は振分処理を終了する。
一方、ファイル新旧表示の項目が“新”のサーバ３０に前回処理した情報がない場合（ステップＳ１１７−ＮＯ）、振分部２０３は処理要求を破棄する（ステップＳ１１８）。その後、アップデート振分装置２０は振分処理を終了する。

【0046】

以上のように構成されたクラスタシステム１００では、アップデート管理装置４０が、アップデート前のサーバ３０で処理中のサービスが終了した時点で、該当サーバ３０をアップデートする。これにより、データ引継処理を削減することができる。また、アップデート振分装置２０が、アップデート中のサーバ３０に対する処理要求を新サーバ又は旧サーバのいずれで処理すべきかを判断し、該当するサーバ３０に振り分ける。したがって、データ引継処理に要するコストを削減することができる。そのため、クラスタシステムにおいて、ソフトウェアのアップデートを行う際に要する開発コストを削減することが可能となる。

【0047】

振分部２０３は、処理要求が破棄してよい要求ではなく、処理要求を処理したサーバ３０がある場合には、処理要求を処理したサーバ３０に処理要求を振り分け、処理要求が破棄してよい要求ではなく、処理要求を処理したサーバ３０がない場合には、処理要求を旧サーバに振り分ける。

【0048】

＜変形例＞
本実施形態におけるクラスタシステム１００において、ＩａａＳ等でサーバプールにリソースの余裕がある場合は、ソフトウェアのアップデートを行う際に別のサーバリソースを用いてもよい。その場合は、運用中のサーバ台数をＮ台とした場合、アップデート用として追加で１〜Ｎ台のサーバ３０が必要となる。アップデート用として追加でＮ台のサーバを用意した場合のアップデート方法について図１０を用いて説明する。なお、図１０では、ソフトウェアのアップデートの方法について、振分情報ファイルを用いて説明する。図１０において、処理開始時には振分情報ファイルには４台のサーバ３０（サーバ名：“Ａ”サーバ、“Ｂ”サーバ、“Ｃ”サーバ及び“Ｄ”サーバ）を示す情報が登録されている。

【0049】

図１０（Ａ）は、振分情報ファイルのソフトウェアのアップデート前の状態を示す。例えば、図１０（Ａ）の状態を初期状態とする。図１０（Ａ）に示す例では、ソフトウェアのアップデートが必要となってしない状態であるため、４台全てのサーバ３０に対してファイル新旧表示の項目には“−”が登録されている。

【0050】

ソフトウェアのアップデートが必要になった場合、すなわちソフトウェアのアップデートのコマンドがアップデート管理装置４０に入力された場合、コマンド処理部４０１はアップデート要求をアップデート振分装置２０に送信する。また、コマンド処理部４０１は、アップデート実行要求をサーバ管理部４０３に送信する。アップデート要求には、アップデートの対象となるソフトウェアを用いているサーバ３０のサーバ名が含まれる。図１０では、アップデート要求に、４台のサーバ３０（サーバ名：“Ａ”サーバ、“Ｂ”サーバ、“Ｃ”サーバ及び“Ｄ”サーバ）のサーバ名が含まれているとする。アップデート実行要求には、アップデートの対象となるソフトウェアを用いているサーバ３０のサーバ名と、アップデートするためのソフトウェアが含まれる。
更新部２０２は、アップデート管理装置４０からアップデート要求を受信すると、振分情報ファイルを参照し、アップデート要求に含まれるサーバ名に該当するサーバ３０のファイル新旧表示の項目を“旧”に更新する。この処理後の振分情報ファイルの一例が図１０（Ｂ）である。

【0051】

次に、サーバ管理部４０３は、サーバプールから新しいサーバ（例えば、“Ｅ”サーバ）を用意し、新しいサーバ（例えば、“Ｅ”サーバ）に新しいソフトウェアをインストールする。サーバ管理部４０３は、コマンド処理部４０１を介して、新たなサーバ３０にソフトウェアをインストールしたことを示す通知（以下「追加要求」という。）をアップデート振分装置２０に送信する。追加要求には、新たにソフトウェアをインストールしたサーバ３０のサーバ名（例えば、“Ｅ”サーバ）が含まれる。

【0052】

更新部２０２は、アップデート管理装置４０から追加要求を受信すると、振分情報ファイルを参照し、追加要求に含まれるサーバ名を振分情報ファイルに新たに登録する。この際、更新部２０２は、新たに登録したサーバ３０のファイル新旧表示の項目に“新”を登録する。この処理では、更新部２０２は、振分情報ファイルのサーバ名に“Ｅ”サーバ、ファイル新旧表示の項目に“新”を登録する。この処理後の振分情報ファイルの一例が図１０（Ｃ）である。アップデート振分装置２０及びアップデート管理装置４０は、上記の処理を旧のソフトウェアの運用台数分（図１０では、４台分）行う。この処理後の振分情報ファイルの一例が図１０（Ｄ）である。このとき以降にアップデート振分装置２０で受信したクライアントからの処理要求は、後述する振り分け方法に従いサーバ３０に処理を振り分ける。

【0053】

次に、サーバ管理部４０３は、アップデート実行要求に含まれるサーバ名に該当するサーバ３０の負荷を監視し、負荷が所定の閾値以下になったサーバ３０を停止する。ここでは、“Ｄ”サーバが閾値以下であったとする。この場合、サーバ管理部４０３は、“Ｄ”サーバを停止する。その後、サーバ管理部４０３は、コマンド処理部４０１を介して、停止要求をアップデート振分装置２０に送信する。停止要求には、停止したサーバ３０のサーバ名が含まれる。この処理では、停止要求に、“Ｄ”サーバを示す情報が含まれているとする。
更新部２０２は、アップデート管理装置４０から停止要求を受信すると、振分情報ファイルを参照し、停止要求に含まれるサーバ名に該当するサーバ３０を振分情報ファイルから削除する。例えば、更新部２０２は、“Ｄ”サーバに関する情報を含むレコードを振分情報ファイルから削除する。この処理後の振分情報ファイルの一例が図１０（Ｅ）である。

【0054】

サーバ管理部４０３は、上記のように、サーバ３０の負荷の低下に伴い順次サーバ３０を停止したのち、ソフトウェアのアップデートを行う。この処理を繰り返すことによって、最後に最低１台以上のサーバ３０のファイル新旧表示の項目が“旧”の状態となる。図１０（Ｆ）の例では、“Ａ”サーバのみがファイル新旧表示の項目が“旧”である。ファイル新旧表示の項目が“旧”のサーバでの処理が終了した時点、もしくは、手動等により強制的にファイル新旧表示の項目が“旧”のサーバでの処理を終了させた時点で、サーバ管理部４０３は最後に残った“Ａ”サーバを停止する。その後、サーバ管理部４０３は、コマンド処理部４０１を介して、停止要求をアップデート振分装置２０に送信する。この処理における停止要求には、“Ａ”サーバを示す情報が含まれている。
更新部２０２は、アップデート管理装置４０から停止要求を受信すると、振分情報ファイルを参照し、停止要求に含まれるサーバ名に該当するサーバ３０を振分情報ファイルから削除する。例えば、更新部２０２は、“Ａ”サーバに関する情報を含むレコードを振分情報ファイルから削除する。この処理後の振分情報ファイルの一例が図１０（Ｇ）である。
以上の処理により、振分情報ファイルのファイル新旧表示の項目が新たに追加されたサーバ３０となり、全て“新”となる。これでアップロードが終了する。その後、振分情報記憶部２０１は、振分情報ファイルを初期状態に更新する。この処理後の振分情報ファイルの一例が図１０（Ｈ）である。

【0055】

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

【符号の説明】

【0056】

１０…クライアント装置， ２０、２０−１〜２０−Ｍ…アップデート振分装置， ３０、３０−１〜３０−Ｎ…サーバ， ４０…アップデート管理装置， ５０…内部ネットワーク， ６０…ネットワーク， ２０１…振分情報記憶部， ２０２…更新部， ２０３…振分部， ４０１…コマンド処理部， ４０２…サーバ情報記憶部， ４０３…サーバ管理部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】