JP2017004502A - 情報システムおよびアップデート方法 - Google Patents

Abstract

【課題】システムを稼働させた状態でアップデートを行うことができる情報システムおよびアップデート方法を提供する。【解決手段】監視サーバ装置は、監視対象システムが正常に稼働しているか否かを確認する確認手段と、その結果を示す第１状態情報を送信する第１通信手段と、を備え、ホストは、第２通信手段と、第１状態情報を受信する第１受信手段と、同一のクラスタ内の他のホストから、他のホストの動作状態を示す第２状態情報を受信する第２受信手段と、アップデート動作の開始が指定された場合、アップデート動作を実行するアップデート手段と、第１状態情報が正常である場合、第２受信手段により受信された第２状態情報が、アップデート動作を実行することが可能な状態を示す他のホストのいずれかに対して、アップデート開始指令を通知する通知手段と、を備える。【選択図】図３

Description

本発明は、情報システムおよびアップデート方法に関する。

システム環境に、無停止状態でソフトウェアおよびデータベース等をデプロイまたはアップデート（以下、まとめて「アップデート」と称するものとする）する場合、システムに含まれるクラスタ間の依存関係、または、システムが複数の場合、システム間の依存関係を考慮して行う必要がある。

このような、システム環境に対して、無停止状態でソフトウェアおよびデータベース等をアップデートする技術として、運用系モジュール（システム）および待機系モジュール（システム）のように、システムを二重化してアップデートを行う技術が提案されている（特許文献１参照）。この技術では、まず、待機系モジュールに対して最新レビジョンのデータでアップデートを行う。次に、運用系モジュールを待機系モジュールに切り替え、アップデートが終了した元々の待機系モジュールを運用系モジュールに切り替え、運用を再開する。そして、運用系モジュールから切り替えられた待機系モジュールに対して最新レビジョンのデータでアップデートを行う。

しかしながら、特許文献１に記載された技術は、アップデートを行う場合、起動はさせているものの運用には通常利用しない待機系モジュール（システム）が必要となる構成であり、運用系モジュール（システム）のみである場合、アップデートを行うことができないという問題がある。また、上述のように、稼働システムである運用系モジュールの他に、冗長化のために待機状態にある待機系モジュール、すなわち、運用系モジュールのコピーが必要となるため、コストが嵩むという問題点もある。

本発明は、上述の問題点を鑑みてなされたものであって、システムを稼働させた状態でアップデートを行うことができる情報システムおよびアップデート方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、複数のホストを含むクラスタを有する監視対象システムと、前記監視対象システムの状態を監視する監視サーバ装置と、を有する情報システムであって、前記監視サーバ装置は、前記監視対象システムが正常に稼働しているか否かを確認する確認手段と、前記確認手段により確認された結果を示す第１状態情報を送信する第１通信手段と、を備え、前記ホストは、第２通信手段と、前記第１通信手段から送信された前記第１状態情報を、前記第２通信手段を介して受信する第１受信手段と、同一のクラスタ内の他のホストから、前記第２通信手段を介して、前記他のホストの動作状態を示す第２状態情報を受信する第２受信手段と、アップデート動作の開始が指定された場合、外部から前記第２通信手段を介してアップデート情報を取得し、前記アップデート情報に基づいて前記アップデート動作を実行するアップデート手段と、前記アップデート手段により前記アップデート動作が完了した後、前記第１受信手段により受信された前記第１状態情報が正常である場合、前記第２受信手段により受信された前記第２状態情報が、前記アップデート動作を実行することが可能な状態を示す前記他のホストのいずれかに対して、前記第２通信手段を介してアップデート開始指令を通知する通知手段と、を備えたことを特徴とする。

本発明によれば、システムを稼働させた状態でアップデートを行うことができる。

図１は、第１の実施の形態に係る情報システムの全体構成の一例を示す図である。 図２は、第１の実施の形態のホストおよびサーバのハードウェア構成の一例を示す図である。 図３は、第１の実施の形態に係る情報システムの機能ブロックの構成の一例を示す図である。 図４は、クラスタ内でステータス情報を共有することを説明する図である。 図５は、ホストの状態遷移図である。 図６は、第１の実施の形態のクラスタ内のホストのアップデート動作の一例を説明する図である。 図７は、ホストのアップデート動作時におけるアップデート情報の受信動作を説明する図である。 図８は、アップデート完了時のステータス情報の取得の動作を説明する図である。 図９は、アップデートするモジュールのバージョンの例を示す図である。 図１０は、第１の実施の形態でのシステム停止時のアップデート動作の一例を説明する図である。 図１１は、クラスタ間でステータス情報を共有することを説明する図である。 図１２は、第２の実施の形態のクラスタ間でのホストのアップデート動作の一例を示す図である。 図１３は、第２の実施の形態でのクラスタのアップデートの実行順序の類型を説明する図である。 図１４は、第２の実施の形態でのシステム停止時のアップデート動作の一例を説明する図である。 図１５は、第３の実施の形態のシステム間でホストのアップデート動作の一例を示す図である。 図１６は、第４の実施形態のクラスタにリクエストが送られたときの動作を説明する図である。 図１７は、第４の実施形態のクラスタに送られたリクエストがリダイレクトされる動作を説明する図である。 図１８は、第５の実施形態のリクエストを受信したアプリクラスタのホストが適切な共通サービスクラスタのホストにアクセスする動作を説明する図である。

以下に、図１〜１５を参照しながら、本発明に係る情報システムおよびアップデート方法の実施の形態を詳細に説明する。また、以下の実施の形態によって本発明が限定されるものではなく、以下の実施の形態における構成要素には、当業者が容易に想到できるもの、実質的に同一のもの、およびいわゆる均等の範囲のものが含まれる。さらに、以下の実施の形態の要旨を逸脱しない範囲で構成要素の種々の省略、置換、変更および組み合わせを行うことができる。

［第１の実施の形態］
（情報システムの全体構成）
図１は、第１の実施の形態に係る情報システムの全体構成の一例を示す図である。図１を参照しながら、情報システム１の全体構成の概略を説明する。

図１に示すように、情報システム１は、ステージング環境システム１０ａ（監視対象システム）と、本番環境システム１０ｂ（監視対象システム）と、サービス監視サーバ２０ａ、２０ｂ（監視サーバ装置）と、構成管理サーバ３０（外部装置の一例）と、を有する。

なお、サービス監視サーバ２０ａ、２０ｂのうち任意のサーバを示す場合、または総称する場合、単に「サービス監視サーバ２０」と称する。

ステージング環境システム１０ａは、後述する本番環境である本番環境システム１０ｂで発生した不具合等の事象を再現するための環境が形成されたシステムである。本番環境システム１０ｂは、ユーザに特定のサービスを提供するための環境が形成されたシステムである。ここで、ステージング環境とは、本番環境において発生した現象を再現して検証するためのシステム環境である。また、本番環境とは、サービスを実際に提供するために稼働している状態のシステム環境である。ステージング環境システム１０ａおよび本番環境システム１０ｂは、例えば、クラウド内のシステムとして構成される。また、ステージング環境システム１０ａおよび本番環境システム１０ｂは、いずれも独立して稼働することが可能なシステムであり、いずれかのシステムで不具合が発生した場合に、サービスの提供を代行するための冗長化を目的としたものではない。

なお、図１では、情報システム１が有するシステムとして、ステージング環境システム１０ａおよび本番環境システム１０ｂの２つのシステムが示されているが、これに限定されるものではなく、１つまたは３つ以上のシステムを有するものとしてもよい。また、情報システム１が有するシステムとして、ステージング環境システム１０ａおよび本番環境システム１０ｂの２種類のシステム環境が示されているが、これに限定されるものではなく、情報システム１は、他のシステム環境を有するものとしてもよい。例えば、他のシステム環境としては、開発環境および評価環境等が挙げられる。ここで、開発環境とは、ソフトウェアおよびデータベース等の開発等行うためのシステム環境である。また、評価環境とは、システム環境で開発されたシステムをリリースする前に、そのシステムに対する評価テストを行うためのシステム環境である。

サービス監視サーバ２０ａは、ステージング環境システム１０ａが提供する印刷機能等のサービスが正常に稼働しているか否かを監視するサーバ装置またはサーバシステムである。サービス監視サーバ２０ｂは、同様に、本番環境システム１０ｂが提供するサービスが正常に稼働しているか否かを監視するサーバ装置またはサーバシステムである。

構成管理サーバ３０は、ステージング環境システム１０ａおよび本番環境システム１０ｂが含む各ホストにインストールされているモジュールのバージョンを管理するサーバ装置またはサーバシステムである。また、構成管理サーバ３０は、情報システム１のアップデート動作時に、各ホストにアップデートすべき最新のモジュールおよびデータ等の情報（以下、アップデート情報と称する場合がある）を提供する。

図１に示すように、ステージング環境システム１０ａは、アプリクラスタ１１ａと、共通サービスクラスタ１２ａと、データベースクラスタ１３ａと、を有する。ここで、クラスタとは、複数のサーバ（ホスト）によって、特定機能を有する単一のシステムとして振る舞うように動作させるシステム形態をいう。

アプリクラスタ１１ａは、プラットフォームとなる共通サービスクラスタ１２ａの機能を利用するアプリケーション機能を提供するクラスタである。例えば、アプリクラスタ１１ａがウェブアプリの機能を提供する場合、例えば、ユーザ側のブラウザに表示されるユーザインターフェースである印刷画面情報を提供する。アプリクラスタ１１ａは、ホスト１１０ａ、１１１ａ、１１２ａを有する。

ホスト１１０ａ、１１１ａ、１１２ａは、それぞれ、アプリケーション機能を提供するアプリクラスタ１１ａの実体となるサーバ装置またはサーバシステムであり、いずれも同一の、または代替可能な機能を提供する。

共通サービスクラスタ１２ａは、アプリクラスタ１１ａの各ホストに共通する機能（共通サービス）を提供するプラットフォームとして機能するクラスタである。例えば、共通サービスクラスタ１２ａは、アプリクラスタ１１ａの各ホストが共通して利用するファイル変換、認証機能、ライセンス管理およびＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）機能等の機能を提供する。共通サービスクラスタ１２ａは、ホスト１２０ａ、１２１ａを有する。

ホスト１２０ａ、１２１ａは、それぞれ、プラットフォームとしての機能を提供する共通サービスクラスタ１２ａの実体となるサーバ装置またはサーバシステムであり、いずれも同一の、または代替可能な機能を提供する。

データベースクラスタ１３ａは、アプリクラスタ１１ａおよび共通サービスクラスタ１２ａが利用する設定情報および認証情報等のデータを記憶および管理するクラスタである。データベースクラスタ１３ａは、ホスト１３０ａ、１３１ａを有する。

ホスト１３０ａ、１３１ａは、それぞれ、設定情報等のデータベースとしての機能を提供するデータベースクラスタ１３ａの実体となるサーバ装置またはサーバシステムであり、いずれも同一の、または代替可能な機能を提供する。

図１に示すように、本番環境システム１０ｂは、アプリクラスタ１１ｂと、共通サービスクラスタ１２ｂと、データベースクラスタ１３ｂと、を有する。アプリクラスタ１１ｂ、共通サービスクラスタ１２ｂおよびデータベースクラスタ１３ｂは、それぞれ、上述したアプリクラスタ１１ａ、共通サービスクラスタ１２ａおよびデータベースクラスタ１３ａと同様の機能を有する。

アプリクラスタ１１ｂは、ホスト１１０ｂ、１１１ｂ、１１２ｂ、１１３ｂを有する。共通サービスクラスタ１２ｂは、ホスト１２０ｂ、１２１ｂ、１２２ｂ、１２３ｂを有する。データベースクラスタ１３ｂは、ホスト１３０ｂ、１３１ｂ、１３２ｂ、１３３ｂを有する。

なお、図１に示すステージング環境システム１０ａおよび本番環境システム１０ｂが有するクラスタは例を示すものであり、異なる機能のクラスタを有するものとしてもよい。

また、図１に示す各クラスタが有するホストの数は一例であり、図１に示す台数に限定されるものではない。すなわち、各クラスタにおいては、そのクラスタが提供する機能の負荷によって自動的にホストが追加されたり、削除されたりするオートスケールの仕組みが実現されているものとする。このオートスケールの機能は、上述の構成管理サーバ３０の構成管理によって実現される。

また、図１に示す各クラスタが有するホストのうち任意のホストを示す場合、または総称する場合、単に「ホスト１００」と称する場合がある。

（情報システムハードウェア構成）
図２は、第１の実施の形態のホストおよびサーバのハードウェア構成の一例を示す図である。図２を参照しながら、サービス監視サーバ２０、構成管理サーバ３０、およびホスト１００のハードウェア構成の詳細について説明する。

まず、図２を参照しながらサービス監視サーバ２０のハードウェア構成について説明する。図２に示すように、サービス監視サーバ２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５０１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）５０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）５０３と、補助記憶装置５０５と、メディアドライブ５０７と、ディスプレイ５０８と、ネットワークＩ／Ｆ５０９と、キーボード５１１（入力手段の一例）と、マウス５１２（入力手段の一例）と、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）ドライブ５１４と、を備えている。

ＣＰＵ５０１は、サービス監視サーバ２０全体の動作を制御する装置である。ＲＯＭ５０２は、サービス監視サーバ２０用のプログラムを記憶している不揮発性記憶装置である。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される揮発性記憶装置である。補助記憶装置５０５は、各種データを記憶するＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）またはＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置である。

メディアドライブ５０７は、ＣＰＵ５０１の制御に従って、フラッシュメモリ等の記録メディア５０６に対するデータの読み出しおよび書き込みを制御する装置である。ディスプレイ５０８は、カーソル、メニュー、ウィンドウ、文字または画像等の各種情報を表示する表示装置である。ネットワークＩ／Ｆ５０９は、ネットワークを介してデータを通信するためのインターフェースである。キーボード５１１は、文字、数字、各種指示の選択、およびカーソルの移動等を行う入力装置である。マウス５１２は、各種指示の選択および実行、処理対象の選択、ならびにカーソルの移動等を行うための入力装置である。ＣＤ−ＲＯＭドライブ５１４は、着脱自在な記憶媒体の一例としてのＣＤ−ＲＯＭ５１３に対するデータの読み出しおよび書き込みを制御する装置である。

上述のＣＰＵ５０１、ＲＯＭ５０２、ＲＡＭ５０３、補助記憶装置５０５、メディアドライブ５０７、ディスプレイ５０８、ネットワークＩ／Ｆ５０９、キーボード５１１、マウス５１２およびＣＤ−ＲＯＭドライブ５１４は、アドレスバスおよびデータバス等のバスライン５１０によって互いに通信可能に接続されている。

なお、上述のサービス監視サーバ２０用のプログラムは、インストール可能な形式または実行可能な形式のファイルによって、記録メディア５０６またはＣＤ−ＲＯＭ５１３等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。

また、構成管理サーバ３０は、上述のサービス監視サーバ２０と同様のハードウェア構成を有しているため、その説明を省略する。ただし、ＲＯＭ５０２には、構成管理サーバ３０を制御するための構成管理サーバ３０用のプログラムが記録されている。この場合も、構成管理サーバ３０用のプログラムは、インストール可能な形式または実行可能な形式のファイルで、記録メディア５０６またはＣＤ−ＲＯＭ５１３等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。

また、ホスト１００は、上述のサービス監視サーバ２０と同様のハードウェア構成を有しているため、その説明を省略する。ただし、ＲＯＭ５０２には、ホスト１００を制御するためのホスト１００用のプログラムが記録されている。この場合も、ホスト１００用のプログラムは、インストール可能な形式または実行可能な形式のファイルで、記録メディア５０６またはＣＤ−ＲＯＭ５１３等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。

なお、図２に示したサービス監視サーバ２０、構成管理サーバ３０およびホスト１００のハードウェア構成は一例を示すものであり、図２に示した構成要素を全て含む必要はなく、または、その他の構成要素を含むものとしてもよい。また、サービス監視サーバ２０、構成管理サーバ３０およびホスト１００それぞれが、同一のハードウェア構成を有する必要もないのは言うまでもない。

（情報システムの機能ブロック構成）
図３は、第１の実施の形態に係る情報システムの機能ブロックの構成の一例を示す図である。図３を参照しながら、情報システム１に含まれるサービス監視サーバ２０、構成管理サーバ３０およびホスト１００の機能ブロックの構成について説明する。

図３に示すように、情報システム１では、ホスト１００が、サービス監視サーバ２０および構成管理サーバ３０それぞれと通信可能なように接続されている。なお、図３に示す接続関係に限定されるものではなく、サービス監視サーバ２０、構成管理サーバ３０およびホスト１００それぞれが、任意のネットワーク（例えば、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）または専用回線等）を介して、互いに通信可能なように接続されているものとしてもよい。

図３に示すように、サービス監視サーバ２０は、通信部２０１（第１通信手段）と、システム確認部２０２（確認手段）と、を有する。

通信部２０１は、ネットワークを介して、ホスト１００とデータを通信する機能部である。例えば、通信部２０１は、ホスト１００が正常に稼働しているか否か等を示す情報であるステータス情報を受信し、ホスト１００で構成される特定のシステム（ステージング環境システム１０ａ、本番環境システム１０ｂ）が正常に稼働しているか否かを示す情報であるシステムのステータス情報（以下、システム状態情報と称する場合がある）を送信する。通信部２０１は、図２示すネットワークＩ／Ｆ５０９によって実現される。

システム確認部２０２は、通信部２０１を介して受け取った各ホスト１００のステータス情報に基づいて、サービス監視サーバ２０が監視対象とするシステム（図１に示すステージング環境システム１０ａまたは本番環境システム１０ｂ）が正常に稼働しているか否かを確認する機能部である。システム確認部２０２は、確認した結果を含むシステム状態情報を、通信部２０１を介して監視対象のシステムが有する各ホスト１００に送信する。システム確認部２０２は、図２に示すＲＯＭ５０２、補助記憶装置５０５またはＣＤ−ＲＯＭ５１３に記憶されているプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される。

なお、システム確認部２０２は、ソフトウェアであるプログラムではなく、例えば、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）またはその他の集積回路等のハードウェア回路によって実現されるものとしてもよい。

また、通信部２０１およびシステム確認部２０２は、機能を概念的に示したものであって、このような構成に限定されるものではない。例えば、図３に示すサービス監視サーバ２０において、独立した機能部として図示された複数の機能部を、１つの機能部として構成してもよい。一方、図３に示すサービス監視サーバ２０において、１つの機能部が有する機能を複数に分割し、複数の機能部として構成するものとしてもよい。

図３に示すように、構成管理サーバ３０は、通信部３０１と、提供部３０２と、記憶部３０３と、を有する。

通信部３０１は、ネットワークを介して、ホスト１００とデータを通信する機能部である。例えば、通信部３０１は、情報システム１がアップデート動作を実行する場合に、提供部３０２による構成管理に基づいて提供されるアップデート情報を、アップデートの対象となるホスト１００に送信する。通信部３０１は、図２に示すネットワークＩ／Ｆ５０９によって実現される。

提供部３０２は、情報システム１がアップデート動作を実行する場合に、各システム（図１ではステージング環境システム１０ａおよび本番環境システム１０ｂ）に含まれる各ホスト１００のアップデートに必要なアップデート情報を、通信部３０１を介して各ホスト１００に提供する機能部である。提供部３０２は、図２に示すＲＯＭ５０２、補助記憶装置５０５またはＣＤ−ＲＯＭ５１３に記憶されているプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される。

記憶部３０３は、各ホスト１００のアップデートに必要なアップデート情報を記憶する機能部である。また、記憶部３０３は、各ホスト１００にインストールされているモジュールのバージョンを管理するための管理情報も記憶している。記憶部３０３は、図２に示す補助記憶装置５０５によって実現される。なお、記憶部３０３は、図２に示す構成管理サーバ３０に内蔵された補助記憶装置５０５によって実現されることに限定されるものではなく、構成管理サーバ３０の外部に設置された他の補助記憶装置（例えば、外付けのＨＤＤ等）によって実現されるものとしてもよい。

なお、提供部３０２は、ソフトウェアであるプログラムではなく、例えば、ＡＳＩＣ、ＦＰＧＡまたはその他の集積回路等のハードウェア回路によって実現されるものとしてもよい。

また、通信部３０１、提供部３０２および記憶部３０３は、機能を概念的に示したものであって、このような構成に限定されるものではない。例えば、図３に示す構成管理サーバ３０において、独立した機能部として図示された複数の機能部を、１つの機能部として構成してもよい。一方、図３に示す構成管理サーバ３０において、１つの機能部が有する機能を複数に分割し、複数の機能部として構成するものとしてもよい。

図３に示すように、ホスト１００は、通信部１０１（第２通信手段、通信手段）と、第１管理部１０２（第１受信手段）と、第２管理部１０３（第２受信手段）と、第３管理部１０４と、アップデート部１０５（アップデート手段）と、イベント発行部１０６（通知手段）と、ロールバック部１０７（ロールバック手段）と、記憶部１０８と、を有する。

通信部１０１は、ネットワークを介して、サービス監視サーバ２０および構成管理サーバ３０とデータを通信する機能部である。また、通信部１０１は、他のホスト１００ともデータを通信する。通信部１０１がサービス監視サーバ２０および構成管理サーバ３０と通信するデータの内容は、上述の通りである。通信部１０１は、図２に示すネットワークＩ／Ｆ５０９によって実現される。

第１管理部１０２は、通信部１０１を介して、サービス監視サーバ２０から受け取った自身が属するシステムのシステム状態情報（第１状態情報）を取得して管理する機能部である。第２管理部１０３は、通信部１０１を介して、他のホスト１００から受け取った他のホスト１００のステータス情報（第２状態情報）を取得して管理する機能部である。第３管理部１０４は、自身が含まれるホスト１００のステータス情報を取得して管理する機能部である。

アップデート部１０５は、図２に示すキーボード５１１またはマウス５１２等の入力手段から受け付けたアップデートの操作の情報であるアップデート操作情報を受け取った場合、または、他のホスト１００からの後述するアップデート開始イベントを受信した場合に、アップデート動作を実行する機能部である。アップデート部１０５によるアップデート動作の詳細は、後述する。

イベント発行部１０６は、アップデート動作において、他のホスト１００に対して、アップデート開始イベントまたはアップデート完了イベントを発行する機能部である。各イベントの発行タイミングについての詳細は、後述する。

ロールバック部１０７は、アップデート動作中において、第１管理部１０２が所定間隔で取得および管理している自身が属するシステムのシステム状態情報が異常を示した場合、アップデート動作を中断させ、自身が含まれるホスト１００をアップデート動作前の状態に戻す機能部である。

記憶部１０８は、ホスト１００がサービスを種々のサービスを提供するための情報、および設定情報等を記憶する機能部である。また、記憶部１０８は、第１管理部１０２により取得されたシステム状態情報、ならびに、第２管理部１０３および第３管理部１０４により取得された各ホスト１００のステータス情報を記憶する。記憶部１０８は、図２に示す補助記憶装置５０５によって実現される。なお、記憶部１０８は、図２に示すホスト１００に内蔵された補助記憶装置５０５によって実現されることに限定されるものではなく、ホスト１００の外部に設置された他の補助記憶装置（例えば、外付けのＨＤＤ等）によって実現されるものとしてもよい。

なお、第１管理部１０２、第２管理部１０３、第３管理部１０４、アップデート部１０５、イベント発行部１０６およびロールバック部１０７は、ソフトウェアであるプログラムではなく、例えば、ＡＳＩＣ、ＦＰＧＡまたはその他の集積回路等のハードウェア回路によって実現されるものとしてもよい。

また、通信部１０１、第１管理部１０２、第２管理部１０３、第３管理部１０４、アップデート部１０５、イベント発行部１０６、ロールバック部１０７および記憶部１０８は、機能を概念的に示したものであって、このような構成に限定されるものではない。例えば、図３に示すホスト１００において、独立した機能部として図示された複数の機能部を、１つの機能部として構成してもよい。一方、図３に示すホスト１００において、１つの機能部が有する機能を複数に分割し、複数の機能部として構成するものとしてもよい。

（ステータス情報の共有）
図４は、クラスタ内でステータス情報を共有することを説明する図である。図４を参照しながら、情報システム１の各クラスタ内のホスト同士でステータス情報を共有する動作について説明する。なお、ここでは、ホスト同士でステータス情報を共有するクラスタとして、アプリクラスタ１１ａを例にして説明する。

図４（ａ）に示すアプリクラスタ１１ａのホスト１１０ａ〜１１２ａは、それぞれ、状態を示す情報であるステータス情報をお互いに共有するためのステータス情報テーブル１０００を記憶部１０８に記憶している。

ステータス情報テーブル１０００では、図４（ｂ）に示すように、クラスタ名と、ホスト名と、ＩＰ（Ｉｎｅｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスと、ステータスとが関連付けられて管理される。ここで、クラスタ名は、ステータス情報テーブル１０００を有するホストを含むクラスタの名称である。また、ホスト名は、ステータス情報テーブル１０００を有するホストの名称である。また、ＩＰアドレスは、インターネットまたはイントラネット等のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰネットワークに接続された通信機器ごとに割り振られた識別番号である。なお、図４（ｂ）に示したＩＰアドレスは、３２ビットの情報で表されるＩＰｖ４を示しているが、これに限定されるものではなく、ＩＰｖ６を用いていもよい。ステータスは、クラスタ名およびホスト名で特定されるホストの状態（ステータス情報）を示す。

例えば、図４（ｂ）に示すステータス情報テーブル１０００においては、クラスタ名が「ｐｏｒｔａｌ」で、ホスト名が「ｐｏｒｔａｌ−００２」であるホストのＩＰアドレスは「ｘｘ．ｘｘ．ｘｘ．１０４」であり、ステータスは「ジョブ処理中」であることが示されている。なお、図４（ｂ）に示すＩＰアドレスは、表記を簡略化して示している。また、各ステータスの内容については、図５で後述する。

アプリクラスタ１１ａの各ホスト（ホスト１１０ａ〜１１２ａ）の第２管理部１０３は、定期的、または特定の条件に従う間隔で、互いのステータス情報を送受信し、取得したステータス情報を、ステータス情報テーブル１０００に更新することによって、互いのステータスを管理している。また、アプリクラスタ１１ａの各ホストの第３管理部１０４は、定期的、または特定の条件に従う間隔で、自身のステータス情報を取得し、取得した自身のステータス情報を、ステータス情報テーブル１０００に更新することによって、自身のステータスも管理する。

（ステータスの遷移について）
図５は、ホストの状態遷移図である。図５を参照しながら、ホストの状態（ステータス）の遷移関係について説明する。

図５に示す「正常」のステータスは、正常にジョブリクエスト、またはアップデートを開始するためのイベントであるアップデート開始イベントを受け付け可能な状態である。「ジョブ処理中」のステータスは、ジョブリクエストを受け付けて、ジョブを処理している状態である。この「ジョブ処理中」のステータスでは、アップデート開始イベントを受け付けることは可能であるが、この場合、ジョブの処理が終了してステータスが「正常」に戻った後、「アップデート中」に遷移する。「アップデート中」のステータスは、上述したように、アップデート部１０５によって、アップデート操作情報またはアップデータ開始イベントが受け取られた場合に、アップデート動作が開始された状態を示す。「アップデート完了」のステータスは、アップデート部１０５によってアップデート動作が完了した状態を示す。「退避中」のステータスは、不具合の発生等によってクラスタから切り離されている状態を示す。

（クラスタ内のホストのアップデート動作）
図６は、第１の実施の形態のクラスタ内のホストのアップデート動作の一例を説明する図である。図７は、ホストのアップデート動作時におけるアップデート情報の受信動作を説明する図である。図８は、アップデート完了時のステータス情報の取得の動作を説明する図である。図９は、アップデートするモジュールのバージョンの例を示す図である。図６〜９を参照しながら、本実施の形態の情報システム１のクラスタ内でのホストのアップデート動作について説明する。なお、ここでは、ステージング環境システム１０ａにおけるホスト１１０ａ〜１１２ａを有するアプリクラスタ１１ａ内でのアップデート動作について説明する。

まず、管理者５０は、アップデート動作の対象とするクラスタとして、ステージング環境システム１０ａのアプリクラスタ１１ａを特定し、アプリクラスタ１１ａ内のホスト１１０ａ〜１１２ａのいずれかに対して、アップデート操作を行う。例えば、図６に示すように、管理者５０は、アプリクラスタ１１ａのホスト１１０ａに対して、図２に示すキーボード５１１およびマウス５１２等の入力手段を介してアップデートの操作を行ったものとする。

次に、ホスト１１０ａのアップデート部１０５は、管理者５０により入力手段を介して入力されたアップデートの操作の情報であるアップデート操作情報を受け取ると、ホスト１１０ａにおけるアップデート動作を開始する。アップデート部１０５は、アップデート動作を開始すると、図６に示すように、ホスト１１０ａの記憶部１０８に記憶されているステータス情報テーブル１０００の自己のホスト（ホスト１１０ａ）に関連付けられているステータスを「アップデート中」に更新する。

また、アップデート部１０５は、アップデート動作を開始すると、まず、図７（ａ）および（ｂ）に示すように、構成管理サーバ３０からアップデート情報を要求して取得する。アップデート部１０５は、取得したアップデート情報に基づいて、アプリクラスタ１１ａの機能を実現するためのプログラムおよびデータ等をアップデートする。アップデート部１０５は、アップデート動作が完了すると、ステータス情報テーブル１０００の自己のホスト（ホスト１１０ａ）に関連付けられているステータスを「アップデート完了」に更新する。

アップデート部１０５によりアップデート動作が完了すると、ホスト１１０ａの第１管理部１０２は、図８に示すように、ホスト１１０ａの通信部１０１を介して、サービス監視サーバ２０ａから、アプリクラスタ１１ａが属するステージング環境システム１０ａのその時点のシステム状態情報を取得する。また、ホスト１１０ａの第２管理部１０３は、図８に示すように、通信部１０１を介して、アプリクラスタ１１ａの他のホスト（ホスト１１１ａ、１１２ａ）からその時点のステータス情報を取得する。そして、ホスト１１０ａのイベント発行部１０６は、システム状態情報が「正常」であり、かつ、ホスト１１１ａおよびホスト１１２ａのステータス情報が「正常」である場合、ステータス情報が「正常」であるホスト１１１ａおよびホスト１１２ａのいずれかに対して、通信部１０１を介して、アップデート開始イベントを発行（送信）する。図６の例では、イベント発行部１０６は、ホスト１１１ａに対してアップデート開始イベントを発行したものとする。

次に、ホスト１１１ａのアップデート部１０５は、ホスト１１０ａのイベント発行部１０６からアップデート開始イベントを受信した場合、ホスト１１１ａにおけるアップデート動作を開始する。アップデート部１０５は、アップデート動作を開始すると、図６に示すように、ホスト１１１ａの記憶部１０８に記憶されているステータス情報テーブル１０００の自己のホスト（ホスト１１１ａ）に関連付けられているステータスを「アップデート中」に更新する。

また、アップデート部１０５は、アップデート動作を開始すると、図７（ａ）および（ｂ）に示すように、構成管理サーバ３０からアップデート情報を要求して取得する。アップデート部１０５は、取得したアップデート情報に基づいて、アプリクラスタ１１ａの機能を実現するためのプログラムおよびデータ等をアップデートする。アップデート部１０５は、アップデート動作が完了すると、ステータス情報テーブル１０００の自己のホスト（ホスト１１１ａ）に関連付けられているステータスを「アップデート完了」に更新する。

アップデート部１０５によりアップデート動作が完了すると、ホスト１１１ａの第１管理部１０２は、ホスト１１１ａの通信部１０１を介して、アプリクラスタ１１ａが属するステージング環境システム１０ａのその時点のシステム状態情報を、サービス監視サーバ２０ａから取得する。また、ホスト１１１ａの第２管理部１０３は、通信部１０１を介して、ステージング環境システム１０ａの他のホスト（ホスト１１０ａ、１１２ａ）からその時点のステータス情報を取得する。そして、ホスト１１１ａのイベント発行部１０６は、システム状態情報が「正常」であり、かつ、ホスト１１２ａのステータス情報が「正常」である場合、ステータス情報が「正常」であるホスト１１２ａに対して、通信部１０１を介して、アップデート開始イベントを発行（送信）する。この場合、ホスト１１０ａは既にアップデートが完了しておりステータス情報が「アップデート完了」であるので、ホスト１１１ａは、ホスト１１０ａに対してアップデート開始イベントを発行しない。

ここで、下記の（表１）を参照しながら、アップデート開始イベントをどのホストに発行するかについての類型について説明する。下記の（表１）は、ホスト１１０ａがアップデート動作を完了し、ステータス情報が「アップデート完了」となった状態を示している。なお、アップデート開始イベントを送る時点で、システム状態情報は「正常」であるものとする。

上述のように、ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａおよびホスト１１２ａのステータス情報が共に「正常」である場合、ステータス情報が「正常」であるホスト１１１ａおよびホスト１１２ａのいずれかに対して、アップデート開始イベントを発行する。また、ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａのステータス情報が「正常」であり、ホスト１１２ａのステータス情報が「アップデート完了」である場合、ホスト１１０ａ、１１２ａでのアップデート動作は既に完了しているので、ホスト１１１ａにアップデート開始イベントを発行する。また、ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａのステータス情報が「正常」であり、ホスト１１２ａのステータス情報が「ジョブ処理中」である場合、ステータス情報が「正常」であるホストを優先し、ホスト１１１ａにアップデート開始イベントを発行する。

また、ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａのステータス情報が「正常」であり、ホスト１１２ａのステータス情報が「退避中」である場合、ホスト１１２ａでのアップデート動作は実行できない状態なので、ホスト１１１ａにアップデート開始イベントを発行する。ただし、イベント発行部１０６は、ホスト１１２ａのステータス情報が「退避中」である旨を、管理者５０等に通知するものとしてもよい。例えば、通知する方法として、イベント発行部１０６は、ディスプレイ５０８にホスト１１２ａのステータス情報が「退避中」である旨を表示させたり、または、特定のアドレスにその旨をメールで通知するものとしてもよい。

また、ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａのステータス情報が「アップデート完了」であり、ホスト１１２ａのステータス情報が「ジョブ処理中」である場合、ホスト１１０ａ、１１１ａでのアップデート動作は既に完了しているので、ホスト１１２ａにアップデート開始イベントを発行する。この場合、ホスト１１２ａのアップデート部１０５は、ホスト１１２ａにおけるジョブの処理が終了してステータス情報が「正常」になった後に、アップデート動作を開始し、ステータス情報を「アップデート中」に更新する。

すなわち、上述のように、ホストのステータス情報が「正常中」または「ジョブ処理中」である場合、そのホストがアップデート動作を実行することが可能な状態を示す。

また、ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａおよびホスト１１２ａのステータス情報が共に「ジョブ処理中」である場合、ステータス情報が「ジョブ処理中」であるホスト１１１ａおよびホスト１１２ａのいずれかに対して、アップデート開始イベントを発行する。この場合、アップデート開始イベントを受信したホスト（ホスト１１１ａまたはホスト１１２ａ）のアップデート部１０５は、アップデート開始イベントを受信したホストにおけるジョブの処理が終了してステータス情報が「正常」になった後に、アップデート動作を開始し、ステータス情報を「アップデート中」に更新する。

また、ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａのステータス情報が「ジョブ処理中」であり、ホスト１１２ａのステータス情報が「退避中」である場合、ホスト１１２ａでのアップデート動作は実行できない状態なので、ホスト１１１ａにアップデート開始イベントを発行する。この場合、ホスト１１１ａのアップデート部１０５は、ホスト１１１ａにおけるジョブの処理が終了してステータス情報が「正常」になった後に、アップデート動作を開始し、ステータス情報を「アップデート中」に更新する。また、ホスト１１０ａのイベント発行部１０６は、ホスト１１２ａのステータス情報が「退避中」である旨を、管理者５０等に通知するものとしてもよい。通知する方法は、上述した通りである。

ここで、図６のアップデート動作の説明に戻る。ホスト１１２ａのアップデート部１０５は、ホスト１１１ａのイベント発行部１０６からアップデート開始イベントを受信した場合、ホスト１１２ａにおけるアップデート動作を開始する。アップデート部１０５は、アップデート動作を開始すると、図６に示すように、ホスト１１２ａの記憶部１０８に記憶されているステータス情報テーブル１０００の自己のホスト（ホスト１１２ａ）に関連付けられているステータスを「アップデート中」に更新する。

また、アップデート部１０５は、アップデート動作を開始すると、図７（ａ）および（ｂ）に示すように、構成管理サーバ３０からアップデート情報を要求して取得する。アップデート部１０５は、取得したアップデート情報に基づいて、アプリクラスタ１１ａの機能を実現するためのプログラムおよびデータ等をアップデートする。アップデート部１０５は、アップデート動作が完了すると、ステータス情報テーブル１０００の自己のホスト（ホスト１１２ａ）に関連付けられているステータスを「アップデート完了」に更新する。

アップデート部１０５によりアップデート動作が完了すると、ホスト１１２ａの第１管理部１０２は、ホスト１１２ａの通信部１０１を介して、アプリクラスタ１１ａが属するステージング環境システム１０ａのその時点のシステム状態情報を取得する。また、ホスト１１２ａの第２管理部１０３は、通信部１０１を介して、アプリクラスタ１１ａの他のホスト（ホスト１１０ａ、１１１ａ）からその時点のステータス情報を取得する。そして、ホスト１１２ａのイベント発行部１０６は、自身のステータス情報が「アップデート完了」であることを前提として、システム状態情報が「正常」であり、かつ、ホスト１１０ａ、１１１ａのステータス情報が「アップデート完了」である場合、アプリクラスタ１１ａのすべてのホストに対して、通信部１０１を介して、アップデート完了イベントを発行（送信）する。アップデート完了イベントを受信したホスト１１０ａ〜１１２ａは、それぞれのステータス情報テーブル１０００の自己のホストに関連付けられているステータスを「正常」に更新する。

以上のように、クラスタ内のホストが互いにステータス情報を共有し、アップデート動作が完了したホストが、他のホストのステータス情報に応じて、次にアップデート動作を行うべきホストを特定してアップデート開始イベントを発行していくことにより、クラスタ内でのホストのアップデート動作が行われる。すなわち、アップデート動作を行っていないホストによって、クラスタの機能を提供することができる。したがって、システム（図６の例ではステージング環境システム１０ａ）を稼働させた状態で、各クラスタの各ホストをアップデートすることができる。よって、システム全体をアップデートするために、システムを冗長化（例えば、システムのコピー）させる必要がないため、冗長化によるコストを軽減することができる。

また、クラスタ内のホストのアップデート動作が完了すると、構成管理サーバ３０は、どのホストがどのバージョンのアップデート情報によってアップデートされたかを記憶して管理する。例えば、図９に示すように、アップデート動作が実行される前のホスト１１０ａにインストールされているモジュールのバージョンのうち、システムバージョンが「２．０．１」、および、アプリクラスタのバージョンが「２．０．１」となっている場合に、ホスト１１０ａでアップデート動作が完了すると、構成管理サーバ３０は、ホスト１１０ａにアップデートされたモジュールのバージョンのうち、システムバージョンを「２．０．２」、および、アプリクラスタのバージョンを「２．０．２」として管理する。

なお、上述のように、それぞれのクラスタ内のホストは、互いのステータス情報に応じて、順にアップデート動作を行うので、アップデート後のホストが提供する機能は、アップデート前のホストが提供する機能に対して互換性（後方互換性）を有することが望ましい。

ここで、上述の（表１）を参照しながら、アップデート完了イベントをどのホストに発行するかについての類型について説明する。上述したように（表１）は、ホスト１１０ａがアップデート動作を完了し、ステータス情報が「アップデート完了」となった状態を示している。なお、アップデート完了イベントを送る時点で、システム状態情報は「正常」であるものとする。

ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａおよびホスト１１２ａのステータス情報が共に「アップデート完了」である場合、ホスト１１０ａ〜１１２ａいずれもアップデート動作が既に完了しているので、アプリクラスタ１１ａのすべてのホスト（実質的にはホスト１１０ａ〜１１２ａ）に対して、アップデート完了イベントを発行する。

また、ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａのステータス情報が「アップデート完了」であり、ホスト１１２ａのステータス情報が「退避中」である場合、ホスト１１０ａ、１１１ａでのアップデート動作が既に完了しており、ホスト１１２ａでのアップデート動作は実行できない状態なので、ステータス情報が「アップデート完了」のすべてのホスト（ホスト１１０ａ、１１１ａ）に対して、アップデート完了イベントを発行する。また、ホスト１１０ａのイベント発行部１０６は、ホスト１１２ａのステータス情報が「退避中」である旨を、管理者５０等に通知するものとしてもよい。通知する方法は、上述した通りである。

また、ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａおよびホスト１１２ａのステータス情報が共に「退避中」である場合、ステータス情報が「アップデート完了」である自ホスト（ホスト１１０ａ）に対して、アップデート完了イベントを発行する。また、ホスト１１０ａのイベント発行部１０６は、ホスト１１１ａおよびホスト１１２ａのステータス情報が「退避中」である旨を、管理者５０等に通知するものとしてもよい。通知する方法は、上述した通りである。

また、アップデート中であるか否かに関わらず、ホスト１１０ａ〜１１２ａの第１管理部１０２は、通信部１０１を介して、サービス監視サーバ２０ａからステージング環境システム１０ａのシステム状態情報を取得し、そのシステム状態情報が「異常」を示す場合、ステージング環境システム１０ａの状態が異常である旨を、管理者５０等に通知する。例えば、通知する方法として、第１管理部１０２は、ディスプレイ５０８にステージング環境システム１０ａのシステム状態情報が「異常」である旨を表示させたり、または、特定のアドレスにその旨をメールで通知するものとしてもよい。なお、ステージング環境システム１０ａの状態を監視しているサービス監視サーバ２０ａが、ステージング環境システム１０ａの異常を検出した場合に、その旨を、管理者５０等に通知するものとしてもよい。

また、各ホストのロールバック部１０７は、上述のアップデート動作中に、ホスト自身の異常、または、システム状態情報を通じてステージング環境システム１０ａに異常が発生したことを認識した場合は、アップデート動作を中断させ、アップデート動作前の状態に戻すロールバックを実行する。

（システムが停止中でのホストのアップデート動作）
図１０は、第１の実施の形態でのシステム停止時のアップデート動作の一例を説明する図である。図１０を参照しながら、本実施の形態の情報システム１の特定のシステムの動作が停止中におけるクラスタ内でのホストのアップデート動作について説明する。なお、ここでは、ホスト１１０ａ〜１１２ａを有するステージング環境システム１０ａの動作が停止中におけるアプリクラスタ１１ａ内でのアップデート動作について説明する。

ステージング環境システム１０ａの動作が停止中である場合、アプリクラスタ１１ａ内の各ホストは、互いのステータス情報に応じて、アップデート動作の順番を考慮する必要がない。したがって、図１０に示すように、例えば、管理者５０のアップデート操作を受け付けた順に、各ホストが独立してアップデート動作を実行するものとすればよい。各ホストのアップデート動作の内容は、図６で上述した動作に準じる。ただし、各ホストのイベント発行部１０６は、アップデート動作が完了しても、他のホストの動作を考慮する必要がないので、アップデート開始イベントおよびアップデート完了イベントのいずれも発行する必要はない。また、各ホストの第１管理部１０２は、システム状態情報を取得する必要もなく、第２管理部１０３および第３管理部１０４は、ステータス情報を取得する必要もない。

以上のように、システムが停止している場合は、システムのクラスタ内のホストのアップデート動作の順番を考慮する必要がないので、管理者５０は、任意のタイミングで各ホストのアップデート動作を実行することができる。

なお、上述の図６および１０において、ステージング環境システム１０ａのアプリクラスタ１１ａ内のホストのアップデート動作について説明したが、他のクラスタ（共通サービスクラスタ１２ａ、データベースクラスタ１３ａ）内のアップデート動作、および、本番環境システム１０ｂの各クラスタ内のアップデート動作も、上述のアップデート動作と同様である。

［第２の実施の形態］
第２の実施の形態に係る情報システムについて、第１の実施の形態に係る情報システム１と相違する点を中心に説明する。第１の実施の形態では、クラスタ内の各ホストについて、互いのステータス情報に応じて、次にアップデート動作を実行するホストを決定する動作について説明した。本実施の形態では、特に、異なるクラスタ間でステータス情報を共有し、クラスタの依存関係に基づいて、アップデート動作を実行するクラスタを決定する動作について説明する。なお、本実施の形態の情報システム、サービス監視サーバ２０、構成管理サーバ３０およびホスト１００の構成は、図１〜３で示した構成と同様である。

（ステータス情報の共有）
図１１は、クラスタ間でステータス情報を共有することを説明する図である。図１１を参照しながら、本実施の形態の情報システムの各クラスタ内、およびクラスタ間でステータス情報を共有する動作について説明する。なお、ここでは、ホスト同士でステータス情報を共有するクラスタとして、ステージング環境システム１０ａのアプリクラスタ１１ａおよび共通サービスクラスタ１２ａを例にして説明する。また、説明を簡潔にするため、図１１では、アプリクラスタ１１ａが有するホストとして、ホスト１１０ａおよびホスト１１１ａのみを図示している。

図１１（ａ）に示すアプリクラスタ１１ａのホスト１１０ａ、１１１ａ、および共通サービスクラスタ１２ａのホスト１２０ａ、１２１ａは、それぞれ、状態を示す情報であるステータス情報をお互いに共有するためのステータス情報テーブル１００１を記憶部１０８に記憶している。

ステータス情報テーブル１００１では、図１１（ｂ）に示すように、クラスタ名と、ホスト名と、ＩＰアドレスと、ステータスとが関連付けられて管理される。ここで、クラスタ名は、ステータス情報テーブル１００１を有するホストを含むクラスタの名称である。また、ホスト名は、ステータス情報テーブル１００１を有するホストの名称である。また、ＩＰアドレスおよびステータスは、第１の実施の形態で上述した通りである。

アプリクラスタ１１ａおよび共通サービスクラスタ１２ａの各ホスト（ホスト１１０ａ、１１１ａ、１２０ａ、１２１ａ）の第２管理部１０３は、定期的、または特定の条件に従う間隔で、互いのステータス情報を、通信部１０１を介して送受信し、取得したステータス情報を、ステータス情報テーブル１００１に更新することによって、互いのステータスを管理している。すなわち、各クラスタのホストは、自身が属するクラスタだけではなく、異なるクラスタのホストともステータス情報を送受信して交換する。また、アプリクラスタ１１ａおよび共通サービスクラスタ１２ａの各ホストの第３管理部１０４は、定期的、または特定の条件に従う間隔で、自身のステータス情報を取得し、取得した自身のステータス情報を、ステータス情報テーブル１００１に更新することによって、自身のステータスも管理する。

（クラスタ間の協調に基づくホストのアップデート動作）
図１２は、第２の実施の形態のクラスタ間でのホストのアップデート動作の一例を示す図である。図１３は、第２の実施の形態でのクラスタのアップデートの実行順序の類型を説明する図である。図１２および１３を参照しながら、本実施の形態の情報システムのクラスタ間の協調に基づくホストのアップデート動作について説明する。なお、ここでは、ステージング環境システム１０ａにおけるホスト１１０ａ、１１１ａを有するアプリクラスタ１１ａと、ホスト１２０ａ、１２１ａを有する共通サービスクラスタ１２ａとの間の協調に基づくアップデート動作について説明する。

システム（図１に示すステージング環境システム１０ａ、本番環境システム１０ｂ）内の各クラスタ間にはアップデート動作についての依存関係がある。例えば、図１に示すステージング環境システム１０ａは、クラスタとして、上述のように、アプリクラスタ１１ａ、共通サービスクラスタ１２ａ、およびデータベースクラスタ１３ａを有する。このうちデータベースクラスタ１３ａは、アプリクラスタ１１ａおよび共通サービスクラスタ１２ａとの関係を考慮すると、先にアプリクラスタ１１ａまたは共通サービスクラスタ１２ａがアップデートされた場合、アップデートされたクラスタが、古いクラスタであるデータベースクラスタ１３ａには無いデータを要求する可能性があるため、最も先にアップデートする必要がある。また、共通サービスクラスタ１２ａは、アプリクラスタ１１ａとの関係を考慮すると、先にアプリクラスタ１１ａがアップデートされた場合、アップデートされたアプリクラスタ１１ａが、古いクラスタである共通サービスクラスタ１２ａには無い共通サービスを要求する場合があるため、アプリクラスタ１１ａよりも優先してアップデートする必要がある。そこで、本実施の形態の構成管理サーバ３０は、上述のようなアップデート動作についての依存関係、すなわち、アップデート動作の優先順位の関係を規定する依存関係情報を有する。例えば、依存関係情報は、データベースクラスタ１３ａ、共通サービスクラスタ１２ａ、アプリクラスタ１１ａの順で優先的にアップデートを行うことを規定する情報とする。

また、依存関係情報は、例えば、図１３に示すようなコードによって、アップデート動作の優先順位の関係を規定するようにすればよい。図１のステージング環境システム１０ａおよび本番環境システム１０ｂに相当するシステムが、クラスタとして、共通サービスクラスタｃｓおよびアプリクラスタａｐｌｉを有する場合、依存関係情報として、図１３（ａ）に示す［ｃｓ，ａｐｌｉ］で表記されるコードで規定する。ここで、［Ａ，Ｂ］は、クラスタＡ→クラスタＢのように直列の順序でアップデートを行う意味を表す。

また、システムが、図１に示すステージング環境システム１０ａおよび本番環境システム１０ｂと同様のクラスタを有する場合、すなわち、データベースクラスタｄｂ、共通サービスクラスタｃｓおよびアプリクラスタａｐｌｉを有する場合、依存関係情報として、図１３（ｂ）に示す［ｄｂ，ｃｓ，ａｐｌｉ］で表記されるコードを規定する。すなわち、この依存関係情報は、データベースクラスタｄｂ→共通サービスクラスタｃｓ→アプリクラスタａｐｌｉのように直列の順序でアップデートを行うことを規定する。

また、図１では、ステージング環境システム１０ａおよび本番環境システム１０ｂのいずれも、アプリクラスタ、共通サービスクラスタおよびデータベースクラスタをそれぞれ１ずつ有するものとしているが、上述のように、クラスタの種類および個数は限定されるものではないので、例えば、２種類のアプリクラスタを有する場合も想定される。この２種類のアプリクラスタが、互いに機能が独立である場合、アップデート動作の順序については優劣がないので、並行してアップデート動作を実行させることが可能である。ここで、（Ａ，Ｂ）を、クラスタＡおよびクラスタＢを並行してアップデートを行う意味を表すものとする。ここで、システムが、データベースクラスタｄｂ、共通サービスクラスタｃｓ、ならびに、互いに機能が独立なアプリクラスタｋ−ａｐｌｉおよびアプリクラスタＩ−ａｐｌｉを有する場合、依存関係情報としては、図１３（ｃ）に示す［ｄｂ，ｃｓ，（ｋ−ａｐｌｉ，Ｉ−ａｐｌｉ）］のようなコードで規定すればよい。すなわち、この依存関係情報は、データベースクラスタｄｂ→共通サービスクラスタｃｓ→（アプリクラスタｋ−ａｐｌｉ、Ｉ−ａｐｌｉを並列にアップデート）の順序でアップデートを行うことを規定する。

さらに、システムが、データベースクラスタｄｂ１、ｄｂ２、共通サービスクラスタｃｓ１、ｃｓ２、および、アプリクラスタｋ−ａｐｌｉ１、ｋ−ａｐｌｉ２、Ｉ−ａｐｌｉ１、Ｉ−ａｐｌｉ２を有するものとする。そして、データベースクラスタｄｂ１とデータベースクラスタｄｂ２とは、互いに機能が独立しており、共通サービスクラスタｃｓ１と共通サービスクラスタｃｓ２とは、互いに機能が独立しているものとする。また、アプリクラスタｋ−ａｐｌｉ１とアプリクラスタｋ−ａｐｌｉ２とは、機能に依存関係があり、アプリクラスタｋ−ａｐｌｉ１→アプリクラスタｋ−ａｐｌｉ２の順序でアップデートする必要があるものとする。また、アプリクラスタＩ−ａｐｌｉ１とアプリクラスタＩ−ａｐｌｉ２とについても、機能に依存関係があり、アプリクラスタＩ−ａｐｌｉ１→アプリクラスタＩ−ａｐｌｉ２の順序でアップデートする必要があるものとする。ただし、アプリクラスタｋ−ａｐｌｉ１、ｋ−ａｐｌｉ２の組み合わせと、アプリクラスタＩ−ａｐｌｉ１、Ｉ−ａｐｌｉ２の組み合わせとは、互いに機能が独立しているものとする。この場合、依存関係情報としては、図１３（ｄ）に示す［（ｄｂ１，ｄｂ２），（ｃｓ１，ｃｓ２），（［ｋ−ａｐｌｉ１，ｋ−ａｐｌｉ２］，［Ｉ−ａｐｌｉ１，Ｉ−ａｐｌｉ２］）］のようなコードで規定すればよい。すなわち、この依存関係情報は、（データベースクラスタｄｂ１、ｄｂ２を並列にアップデート）→（共通サービスクラスタｃｓ１、ｃｓ２を並列にアップデート）→（（アプリクラスタｋ−ａｐｌｉ１→アプリクラスタｋ−ａｐｌｉ２）、（アプリクラスタＩ−ａｐｌｉ１→アプリクラスタＩ−ａｐｌｉ２）を並列にアップデート）の順序でアップデートを行うことを規定する。

次に、図１２を参照しながら、クラスタ間の協調に基づくホストのアップデート動作の説明に移る。まず、管理者５０は、構成管理サーバ３０が有する依存関係情報を参照し、アップデート動作の対象とするクラスタとして、アプリクラスタ１１ａよりもアップデートの優先順位が高い共通サービスクラスタ１２ａを特定し、共通サービスクラスタ１２ａ内のホスト１２０ａ、１２１ａのいずれかに対して、アップデート操作を行う。例えば、図１２に示すように、管理者５０は、共通サービスクラスタ１２ａのホスト１２０ａに対して、図２に示すキーボード５１１およびマウス５１２等の入力手段を介してアップデートの操作を行う。

なお、上述のように、管理者５０が、依存関係情報を参照して、アップデート動作の対象とするクラスタを特定するものとしたが、これに限定されるものではない。例えば、管理者５０が、構成管理サーバ３０に対してアップデート操作を行い、アップデート操作を受け付けた構成管理サーバ３０は、保有する依存関係情報に基づいて、優先的にアップデート動作の対象とすべきクラスタに対してアップデート開始イベントを送信するものとしてもよい。また、例えば、管理者５０によるアップデート操作ではなく、構成管理サーバ３０が、ステージング環境システム１０ａに対するアップデート動作を実行するための何らかのトリガを検出した場合に、保有する依存関係情報に基づいて、優先的にアップデート動作の対象とすべきクラスタに対してアップデート開始イベントを送信するものとしてもよい。

まず、共通サービスクラスタ１２ａのホスト１２０ａが、管理者５０から、アップデート操作を受け付けたものとする。次に、ホスト１２０ａの第１管理部１０２は、ホスト１２０ａの通信部１０１を介して、構成管理サーバ３０が有する依存関係情報を参照し、アップデート動作の対象が共通サービスクラスタ１２ａ（第１クラスタの一例）で正しいことを確認する。ここで、管理者５０からアップデート操作を受け付けたホストが、依存関係情報に基づくアップデート動作の対象となるクラスタに属するものではない場合、その旨を管理者５０に対して通知する。通知する方法は、上述した通りである。

また、ホスト１２０ａのアップデート部１０５は、ホスト１２０ａの記憶部１０８に記憶されているステータス情報テーブル１００１を参照し、各クラスタの各ホストのステータスが「正常」、すなわち、アップデート動作が実行されていないことを確認する。アップデート部１０５は、各クラスタの各ホストのステータスが「正常」の場合、ホスト１２０ａにおけるアップデート動作を開始する。アップデート部１０５は、アップデート動作を開始すると、図１２に示すように、記憶部１０８に記憶されているステータス情報テーブル１００１の自己のホスト（ホスト１２０ａ）に関連付けられているステータスを「アップデート中」に更新する。

また、アップデート部１０５は、アップデート動作を開始すると、まず、構成管理サーバ３０からアップデート情報を要求して取得する。アップデート部１０５は、取得したアップデート情報に基づいて、共通サービスクラスタ１２ａの機能を実現するためのプログラムおよびデータ等をアップデートする。アップデート部１０５は、アップデート動作が完了すると、ステータス情報テーブル１００１の自己のホスト（ホスト１２０ａ）に関連付けられているステータスを「アップデート完了」に更新する。

アップデート部１０５によりアップデート動作が完了すると、ホスト１２０ａの第１管理部１０２は、ホスト１２０ａの通信部１０１を介して、サービス監視サーバ２０ａから、共通サービスクラスタ１２ａが属するステージング環境システム１０ａのその時点のシステム状態情報を取得する。また、ホスト１２０ａの第２管理部１０３は、通信部１０１を介して、共通サービスクラスタ１２ａの他のホスト（ホスト１２１ａ）からその時点のステータス情報を取得する。そして、ホスト１２０ａのイベント発行部１０６は、システム状態情報が「正常」であり、かつ、ホスト１２１ａのステータス情報が「正常」である場合、ステータス情報が「正常」であるホスト１２１ａに対して、通信部１０１を介して、アップデート開始イベントを発行（送信）する。

次に、ホスト１２１ａのアップデート部１０５は、ホスト１２０ａのイベント発行部１０６からアップデート開始イベントを受信した場合、ホスト１２１ａにおけるアップデート動作を開始する。アップデート部１０５は、アップデート動作を開始すると、図１２に示すように、ホスト１２１ａの記憶部１０８に記憶されているステータス情報テーブル１００１の自己のホスト（ホスト１２１ａ）に関連付けられているステータスを「アップデート中」に更新する。

また、アップデート部１０５は、アップデート動作を開始すると、構成管理サーバ３０からアップデート情報を要求して取得する。アップデート部１０５は、取得したアップデート情報に基づいて、共通サービスクラスタ１２ａの機能を実現するためのプログラムおよびデータ等をアップデートする。アップデート部１０５は、アップデート動作が完了すると、ステータス情報テーブル１００１の自己のホスト（ホスト１２１ａ）に関連付けられているステータスを「アップデート完了」に更新する。

アップデート部１０５によりアップデート動作が完了すると、ホスト１２１ａの第１管理部１０２は、ホスト１２１ａの通信部１０１を介して、共通サービスクラスタ１２ａが属するステージング環境システム１０ａのその時点のシステム状態情報を取得する。また、ホスト１２１ａの第２管理部１０３は、通信部１０１を介して、共通サービスクラスタ１２ａの他のホスト（ホスト１２０ａ）からその時点のステータス情報を取得する。そして、ホスト１２１ａのイベント発行部１０６は、自身のステータス情報が「アップデート完了」であることを前提として、システム状態情報が「正常」であり、かつ、ホスト１２０ａのステータス情報が「アップデート完了」である場合、共通サービスクラスタ１２ａのすべてのホストに対して、通信部１０１を介して、アップデート完了イベントを発行（送信）する。アップデート完了イベントを受信したホスト１２０ａ、１２１ａは、それぞれのステータス情報テーブル１００１の自己のホストに関連付けられているステータスを「正常」に更新する。

さらに、ホスト１２１ａの第１管理部１０２は、ホスト１２１ａの通信部１０１を介して、構成管理サーバ３０が有する依存関係情報を参照し、次のアップデート動作の対象がアプリクラスタ１１ａ（第２クラスタの一例）であることを確認する。また、ホスト１２１ａの第２管理部１０３は、通信部１０１を介して、アプリクラスタ１１ａの各ホスト（ホスト１１０ａ、１１１ａ）からその時点のステータス情報を取得する。そして、ホスト１２１ａのイベント発行部１０６は、システム状態情報が「正常」であり、かつ、ホスト１１０ａ、１１１ａのステータス情報が「正常」である場合、ホスト１１０ａ、１１１ａのいずれかに対して、通信部１０１を介して、アップデート開始イベントを発行（送信）する。ここでは、イベント発行部１０６は、ホスト１１０ａに対してアップデート開始イベントを発行したものとする。

次に、ホスト１１０ａの第１管理部１０２は、ホスト１２１ａのイベント発行部１０６からアップデート開始イベントを受信した場合、ホスト１１０ａの通信部１０１を介して、構成管理サーバ３０が有する依存関係情報を参照し、アップデート動作の対象がアプリクラスタ１１ａで正しいことを確認する。そして、ホスト１１０ａのアップデート部１０５は、ホスト１１０ａにおけるアップデート動作を開始する。アップデート部１０５は、アップデート動作を開始すると、図１２に示すように、ホスト１１０ａの記憶部１０８に記憶されているステータス情報テーブル１００１の自己のホスト（ホスト１１０ａ）に関連付けられているステータスを「アップデート中」に更新する。

また、アップデート部１０５は、アップデート動作を開始すると、構成管理サーバ３０からアップデート情報を要求して取得する。アップデート部１０５は、取得したアップデート情報に基づいて、アプリクラスタ１１ａの機能を実現するためのプログラムおよびデータ等をアップデートする。アップデート部１０５は、アップデート動作が完了すると、ステータス情報テーブル１００１の自己のホスト（ホスト１１０ａ）に関連付けられているステータスを「アップデート完了」に更新する。

アップデート部１０５によりアップデート動作が完了すると、ホスト１１０ａの第１管理部１０２は、ホスト１１０ａの通信部１０１を介して、サービス監視サーバ２０ａから、共通サービスクラスタ１２ａが属するステージング環境システム１０ａのその時点のシステム状態情報を取得する。また、ホスト１１０ａの第２管理部１０３は、通信部１０１を介して、アプリクラスタ１１ａの他のホスト（ホスト１１１ａ）からその時点のステータス情報を取得する。そして、ホスト１１０ａのイベント発行部１０６は、システム状態情報が「正常」であり、かつ、ホスト１１１ａのステータス情報が「正常」である場合、ステータス情報が「正常」であるホスト１１１ａに対して、通信部１０１を介して、アップデート開始イベントを発行（送信）する。

次に、ホスト１１１ａのアップデート部１０５は、ホスト１１０ａのイベント発行部１０６からアップデート開始イベントを受信した場合、ホスト１１１ａにおけるアップデート動作を開始する。アップデート部１０５は、アップデート動作を開始すると、図１２に示すように、ホスト１１１ａの記憶部１０８に記憶されているステータス情報テーブル１００１の自己のホスト（ホスト１１１ａ）に関連付けられているステータスを「アップデート中」に更新する。

また、アップデート部１０５は、アップデート動作を開始すると、構成管理サーバ３０からアップデート情報を要求して取得する。アップデート部１０５は、取得したアップデート情報に基づいて、アプリクラスタ１１ａの機能を実現するためのプログラムおよびデータ等をアップデートする。アップデート部１０５は、アップデート動作が完了すると、ステータス情報テーブル１００１の自己のホスト（ホスト１１１ａ）に関連付けられているステータスを「アップデート完了」に更新する。

アップデート部１０５によりアップデート動作が完了すると、ホスト１１１ａの第１管理部１０２は、ホスト１１１ａの通信部１０１を介して、アプリクラスタ１１ａが属するステージング環境システム１０ａのその時点のシステム状態情報を取得する。また、ホスト１１１ａの第２管理部１０３は、通信部１０１を介して、アプリクラスタ１１ａの他のホスト（ホスト１１０ａ）からその時点のステータス情報を取得する。そして、ホスト１１１ａのイベント発行部１０６は、自身のステータス情報が「アップデート完了」であることを前提として、システム状態情報が「正常」であり、かつ、ホスト１１０ａのステータス情報が「アップデート完了」である場合、アプリクラスタ１１ａのすべてのホストに対して、通信部１０１を介して、アップデート完了イベントを発行（送信）する。アップデート完了イベントを受信したホスト１１０ａ、１１１ａは、それぞれのステータス情報テーブル１００１の自己のホストに関連付けられているステータスを「正常」に更新する。

さらに、ホスト１１１ａの第１管理部１０２は、ホスト１１１ａの通信部１０１を介して、構成管理サーバ３０が有する依存関係情報を参照し、次のアップデート動作の対象がないことを確認する。

以上のように、システム（図１の例ではステージング環境システム１０ａまたは本番環境システム１０ｂ）内の各クラスタの各ホストが互いにステータス情報を共有し、かつ、クラスタ間でアップデート動作の優先順位の関係を規定する依存関係情報に基づいて、クラスタ間で協調してアップデート動作を実行するものとしている。これによって、システムにおいて、クラスタ間でのアップデート動作の順番不良による不具合が生じないように、システムを稼働させた状態で、各クラスタの各ホストをアップデートすることができる。よって、第１の実施の形態の効果を有すると共に、システムに対して、１回のトリガ（例えば、管理者５０のアップデート操作、または、構成管理サーバ３０による特定のタイミングでのアップデート開始イベント）によって、システムの稼働に支障を来さないように自動的にアップデート動作を実行することができ、人手による作業を大幅に軽減することができる。

なお、図１２のアップデート動作の説明では、各ホストは、適切なタイミングで、構成管理サーバ３０が有する依存関係情報を参照するものとしているが、これに限定するものではなく、適切なタイミングに構成管理サーバ３０から依存関係情報を取得して、取得した依存関係情報を参照するものとしてもよい。

また、構成管理サーバ３０の依存関係情報を参照するタイミングは、図１２で上述したタイミングに限定されるものではない。すなわち、共通サービスクラスタ１２ａの次にアプリクラスタ１１ａの順番でアップデート動作を行うことができれば、どのようなタイミングで参照するものとしてもよい。

（システムが停止中でのホストのアップデート動作）
図１４は、第２の実施の形態でのシステム停止時のアップデート動作の一例を説明する図である。図１４を参照しながら、本実施の形態の情報システムの特定のシステムの動作が停止中におけるそのシステム内でのホストのアップデート動作について説明する。なお、ここでは、ホスト１１０ａ、１１１ａを有するアプリクラスタ１１ａと、ホスト１２０ａ、１２１ａを有する共通サービスクラスタ１２ａとを有するステージング環境システム１０ａの動作が停止中におけるアップデート動作について説明する。

ステージング環境システム１０ａの動作が停止中である場合、アプリクラスタ１１ａおよび共通サービスクラスタ１２ａ内の各ホストは、互いのステータス情報に応じて、アップデート動作の順番を考慮する必要がない。したがって、図１４に示すように、例えば、管理者５０のアップデート操作を受け付けた順に、各ホストが独立してアップデート動作を実行するものとすればよい。各ホストのアップデート動作の内容は、図１２で上述した動作に準じる。ただし、各ホストのイベント発行部１０６は、アップデート動作が完了しても、他のホストの動作を考慮する必要がないので、アップデート開始イベントおよびアップデート完了イベントのいずれも発行する必要はない。また、各ホストの第１管理部１０２は、システム状態情報を取得する必要もなく、第２管理部１０３および第３管理部１０４は、ステータス情報を取得する必要もない。

以上のように、システムが停止している場合は、システムの複数のクラスタにおける各ホストのアップデート動作の順番を考慮する必要がないので、管理者５０は、任意のタイミングで各ホストのアップデート動作を実行することができる。

なお、上述の図１２および１４において、ステージング環境システム１０ａでのホストのアップデート動作について説明したが、他のシステム（図１の例では本番環境システム１０ｂ）の各クラスタ内のアップデート動作も、上述のアップデート動作と同様である。

［第３の実施の形態］
第３の実施の形態に係る情報システムについて、第２の実施の形態に係る情報システムと相違する点を中心に説明する。第２の実施の形態では、異なるクラスタ間でステータス情報を共有し、クラスタの依存関係に基づいて、アップデート動作を実行するクラスタを決定する動作について説明した。本実施の形態においては、特に、情報システムに含まれる複数のシステムのアップデート動作について説明する。なお、本実施の形態の情報システム、サービス監視サーバ２０、構成管理サーバ３０およびホスト１００の構成は、図１〜３で示した構成と同様である。

（ステータス情報の共有）
図１５は、第３の実施の形態のシステム間でホストのアップデート動作の一例を示す図である。図１５を参照しながら、本実施の形態の情報システムが含むステージング環境システム１０ａおよび本番環境システム１０ｂでの各クラスタ内、およびクラスタ間でステータス情報を共有する動作について説明する。なお、ステージング環境システム１０ａでのホスト同士でステータス情報を共有クラスタとして、アプリクラスタ１１ａおよび共通サービスクラスタ１２ａを例にし、本番環境システム１０ｂでのホスト同士でのステータス情報を共有するクラスタとして、アプリクラスタ１１ｂおよび共通サービスクラスタ１２ｂを例にして説明する。

図１５に示すステージング環境システム１０ａにおいて、アプリクラスタ１１ａのホスト１１０ａ、１１１ａ、および共通サービスクラスタ１２ａのホスト１２０ａ、１２１ａは、それぞれ、状態を示す情報であるステータス情報をお互いに共有するためのステータス情報テーブル１００１（図１１（ｂ）参照）を記憶部１０８に記憶している。また、図１５に示す本番環境システム１０ｂにおいて、アプリクラスタ１１ｂのホスト１１０ｂ、１１１ｂ、および共通サービスクラスタ１２ｂのホスト１２０ｂ、１２１ｂも、それぞれ、ステータス情報をお互いに共有するためのステータス情報テーブル１００１を記憶部１０８に記憶している。

ステージング環境システム１０ａのアプリクラスタ１１ａおよび共通サービスクラスタ１２ａの各ホスト（ホスト１１０ａ、１１１ａ、１２０ａ、１２１ａ）の第２管理部１０３は、定期的、または特定の条件に従う間隔で、互いのステータス情報を、通信部１０１を介して送受信し、取得したステータス情報を、ステータス情報テーブル１００１に更新することによって、互いのステータスを管理している。すなわち、ステージング環境システム１０ａの各クラスタのホストは、自身が属するクラスタだけではなく、異なるクラスタのホストともステータス情報を送受信して交換する。また、ステージング環境システム１０ａのアプリクラスタ１１ａおよび共通サービスクラスタ１２ａの各ホストの第３管理部１０４は、定期的、または特定の条件に従う間隔で、自身のステータス情報を取得し、取得した自身のステータス情報を、ステータス情報テーブル１００１に更新することによって、自身のステータスも管理する。

本番環境システム１０ｂのアプリクラスタ１１ｂおよび共通サービスクラスタ１２ｂの各ホスト（ホスト１１０ｂ、１１１ｂ、１２０ｂ、１２１ｂ）の第２管理部１０３は、定期的、または特定の条件に従う間隔で、互いのステータス情報を、通信部１０１を介して送受信し、取得したステータス情報を、ステータス情報テーブル１００１に更新することによって、互いのステータスを管理している。すなわち、本番環境システム１０ｂの各クラスタのホストは、自身が属するクラスタだけではなく、異なるクラスタのホストともステータス情報を送受信して交換する。また、本番環境システム１０ｂのアプリクラスタ１１ｂおよび共通サービスクラスタ１２ｂの各ホストの第３管理部１０４は、定期的、または特定の条件に従う間隔で、自身のステータス情報を取得し、取得した自身のステータス情報を、ステータス情報テーブル１００１に更新することによって、自身のステータスも管理する。

ここで、異なるシステム、すなわち、ステージング環境システム１０ａおよび本番環境システム１０ｂに属するそれぞれのホスト同士は、図１５に示すように、ステータス情報の共有、およびメッセージ等の通信はしない。

（情報システムに含まれる複数のシステムのアップデート動作）
図１５を参照しながら、本実施の形態の情報システムに含まれる複数のシステムのアップデート動作について説明する。

図１５に示すように、管理者５０は、ステージング環境システム１０ａおよび本番環境システム１０ｂそれぞれに対して、アップデート操作を行う。具体的には、ステージング環境システム１０ａに対してアップデートを行う場合、管理者５０は、構成管理サーバ３０が有するステージング環境システム１０ａについての依存関係情報を参照し、アップデート動作の対象とするクラスタを特定し、そのクラスタ内のホストのいずれかに対して、アップデート操作を行う。また、ステージング環境システム１０ａ内で最後にアップデート動作を完了したホストが、完了した旨を、管理者５０に通知する。例えば、通知する方法として、最後にアップデート動作を完了したホストが、ディスプレイ５０８に完了した旨を表示させたり、または、特定のアドレスにその旨をメールで通知するものとしてもよい。

また、本番環境システム１０ｂに対してアップデートを行う場合、管理者５０は、構成管理サーバ３０が有する本番環境システム１０ｂについての依存関係情報を参照し、アップデート動作の対象とするクラスタを特定し、そのクラスタ内のホストのいずれかに対して、アップデート操作を行う。また、本番環境システム１０ｂ内で最後にアップデート動作を完了したホストが、完了した旨を、管理者５０に通知する。通知する方法は、上述と同様である。

ステージング環境システム１０ａおよび本番環境システム１０ｂにおけるアップデート動作の内容は、第２の実施の形態のアップデート動作の内容と同様である。

以上のように、複数のシステムを有する情報システムにおいては、各システム間で、ステータス情報の共有、およびメッセージ等の通信はしないので、各システムに対して別個にアップデート動作を実行することができる。すなわち、各システムを稼働させた状態で、別個にアップデート動作を実行することができる。

なお、情報システムが有する複数のシステム（図１５の例では、ステージング環境システム１０ａおよび本番環境システム１０ｂ）のアップデート動作に優先順位がある場合、管理者５０は、優先順位に従ってアップデート操作を行うものとすればよい。

また、上述のように、管理者５０が、ステージング環境システム１０ａおよび本番環境システム１０ｂに対して、アップデート操作を行うものとしたが、これに限定されるものではない。例えば、管理者５０が、構成管理サーバ３０に対してアップデート操作を行い、アップデート操作を受け付けた構成管理サーバ３０が、各システムにおけるクラスタ間の依存関係情報に基づいて、各システムに対してアップデート開始イベントを送信するものとしてもよい。

［第４の実施の形態］
第４の実施の形態に係る情報システムについて、第１の実施の形態に係る情報システム１と相違する点を中心に説明する。第１の実施の形態では、クラスタ内の各ホストについて、互いのステータス情報に応じて、次にアップデート動作を実行するホストを決定する動作について説明した。本実施の形態では、外部からのリクエストに対し、互いのステータス情報に応じて、他のホストにリダイレクトする動作について説明する。なお、本実施の形態の情報システム、サービス監視サーバ２０、構成管理サーバ３０、およびホスト１００の構成は、図１〜３で示した構成と同様である。

（ステータス情報の共有）
図１６は、第４の実施形態のクラスタにリクエストが送られたときの動作を説明する図である。図４で上述したように、情報システムの各クラスタ内のホスト同士間では、ステータス情報を共有する。なお、ここでは、ホスト同士でステータス情報を共有するクラスタとして、アプリクラスタ１１ｂを例にして説明する。

図１６（ａ）に示すアプリクラスタ１１ｂのホスト１１０ｂ〜１１２ｂは、それぞれ、状態を示す情報であるステータス情報をお互いに共有するために、図１６（ｂ）に示すようなステータス情報テーブル１００２を記憶部１０８（図３参照）に記憶している。

ステータス情報テーブル１００２では、図１６（ｂ）に示すように、クラスタ名と、ホスト名と、ＩＰアドレスと、ステータスとが関連付けられて管理される。例えば、図１６（ｂ）に示すステータス情報テーブル１００２においては、クラスタ名が「ｐｏｒｔａｌ」で、ホスト名が「ｐｏｒｔａｌ−０１１」であるホストのＩＰアドレスは「ｘｘ．ｘｘ．ｘｘ．１２３」であり、ステータスは「アップデート中」であることが示されている。なお、図１６（ｂ）に示すＩＰアドレスは、表記を簡略化して示している。また、本実施の形態では、ステータス情報テーブル１００２のホスト名「ｐｏｒｔａｌ−０１１」がホスト１１０ｂに対応し、ホスト名「ｐｏｒｔａｌ−０１２」がホスト１１１ｂに対応し、ホスト名「ｐｏｒｔａｌ−０１３」がホスト１１２ｂに対応しているものとして説明する。

アプリクラスタ１１ｂの各ホスト（ホスト１１０ｂ〜１１２ｂ）の第２管理部１０３（図３参照）は、定期的、または特定の条件に従う間隔で、互いのステータス情報を送受信し、取得したステータス情報を、ステータス情報テーブル１００２に更新することによって、互いのステータスを管理している。また、アプリクラスタ１１ｂの各ホストの第３管理部１０４（図３参照）は、定期的、または特定の条件に従う間隔で、自身のステータス情報を取得し、取得した自身のステータス情報をステータス情報テーブル１００２に更新することによって、自身のステータスも管理する。

図１６に示す本番環境システム１０ｂのアプリクラスタ１１ｂの各ホスト（ホスト１１０ｂ〜１１２ｂ）は、第１の実施の形態のステージング環境システム１０ａのアプリクラスタ１１ａを例にして説明した動作と同様に、アプリクラスタ１１ｂ内でアップデート動作を行うことが可能である。また、アプリクラスタ１１ｂは、第２の実施の形態で説明したように、異なるクラスタ（例えば、共通サービスクラスタ１２ｂ等）との間で、ステータス情報を共有し、クラスタの依存関係に基づいて、アップデート動作を行うことが可能であるものとしてもよい。すなわち、アプリクラスタ１１ｂの各ホストは、ステータスとして、図５に示すように、「正常」、「ジョブ処理中」、「退避中」、「アップデート中」および「アップデート完了」等の各ステータスを取り得る。

（外部からのリクエストに対する応答動作）
本番環境システム１０ｂのアプリクラスタ１１ｂの各ホスト（ホスト１１０ｂ〜１１２ｂ）は、図１６（ａ）に示すように、外部からインターネット２を介して、アプリクラスタ１１ｂの機能の提供を要求するためのリクエストをランダムに受信する。図１６（ａ）に示す例では、外部からインターネット２を介して送信されたリクエストを、アプリクラスタ１１ｂのホスト１１２ｂが、通信部１０１を介して受信した例を示している。

ホスト１１２ｂの第３管理部１０４（確認手段の一例）は、ステータス情報テーブル１００２で管理している自身のステータス情報を確認する。第３管理部１０４は、図１６（ｂ）のステータス情報テーブル１００２に示すように、自身のステータス情報が「正常」であることを確認する。したがって、第３管理部１０４は、自身のステータス情報が「正常」であることから、外部からのリクエストに対する応答として、機能の提供を行う。例えば、ホスト１１２ｂが、ウェブサーバである場合、リクエストとしてページ要求を受信した場合、そのページ要求に応じたページ情報を、リクエストに対する応答として送信する。

また、図１６（ｂ）のステータス情報テーブル１００２の例では、ホスト１１２ｂのステータス情報が「正常」となっているが、例えば、ステータス情報が「アップデート完了」である場合でも、リクエストに対する応答処理は可能であるので、ホスト１１２ｂの第３管理部１０４は、自身のステータス情報が「アップデート完了」である場合でも、外部からのリクエストに対する応答として、機能の提供を行う。

なお、図１６（ａ）に示すように、アプリクラスタ１１ｂのホストは、外部からインターネット２を介してリクエストを受信するものとしたが、これに限定されるものではなく、インターネット２以外のネットワーク、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ ネットワーク）、イントラネット、または専用線のネットワーク等であってもよい。

図１７は、第４の実施形態のクラスタに送られたリクエストがリダイレクトされる動作を説明する図である。次に、図１７を参照しながら、リクエストを受信したホストが、リクエストに対する応答処理を実行できない状態である場合、他のホストにリダイレクトする動作について説明する。

図１７に示すように、例えば、本番環境システム１０ｂのアプリクラスタ１１ｂのホスト１１０ｂが、外部からインターネット２を介して、アプリクラスタ１１ｂの機能の提供を要求するためのリクエストを通信部１０１により受信したものとする。通信部１０１によりリクエストが受信されると、ホスト１１０ｂの第３管理部１０４は、記憶部１０８に記憶されたステータス情報テーブル１００２を参照し、自身のステータス情報を確認する。図１６（ｂ）に示すように、第３管理部１０４は、ステータス情報テーブル１００２において自身のステータスが「アップデート中」であることを確認し、リクエストに対する応答処理が実行できないと判断する。

次に、ホスト１１０ｂの第２管理部１０３は、ステータス情報テーブル１００２を参照し、アプリクラスタ１１ｂ内の他のホスト（ホスト１１１ｂ、１１２ｂ）のステータス情報を参照する。第２管理部１０３（リダイレクト手段の一例）は、他のホストであるホスト１１１ｂ、１１２ｂの各ステータス情報に基づいて、通信部１０１により受信されたリクエストをリダイレクトするホストを決定する。具体的には、第２管理部１０３は、他のホストのうち、ステータス情報が「正常」または「アップデート完了」であるホストが存在する場合、そのホストによって、通信部１０１により受信されたリクエストに対する応答処理が可能であると判断し、そのリクエストを、ステータス情報が「正常」または「アップデート完了」であるホストにリダイレクトする。リクエストを他のホストにリダイレクトする方法としては、例えば、受信したリクエストを、通信部１０１を介して他のホストに対してそのまま転送するものとしてもよく、または、リクエストを受信したホストが新たにリクエストを生成して、通信部１０１を介して他のホストに対して送信するものとしてもよい。また、ステータス情報が「アップデート完了」であるホストは、本番環境システム１０ｂの異常等によりロールバックを実行する可能性があるので、第２管理部１０３は、ステータス情報が「アップデート完了」であるホストよりも、ステータス情報が「正常」であるホストを優先してリダイレクトすることが望ましい。

また、第２管理部１０３は、他のホストのうちステータス情報が「ジョブ処理中」のホストは特定のジョブの処理を実行中であるため、通信部１０１により受信されたリクエストを、そのホストにリダイレクトしない。また、第２管理部１０３は、他のホストのうちステータス情報が「退避中」のホストは不具合の発生等によってアプリクラスタ１１ｂから切り離されている状態であるため、通信部１０１により受信されたリクエストを、そのホストにリダイレクトしない。また、第２管理部１０３は、他のホストのうちステータス情報が「アップデート中」のホストはアップデート情報によるアップデート動作中であるため、通信部１０１により受信されたリクエストを、そのホストにリダイレクトしない。

なお、ステータス情報が「ジョブ処理中」のホストにはリダイレクトしないものとしたが、これに限定されるものではなく、「ジョブ処理中」である場合、特定のジョブの処理が終了すれば、リクエストに対する応答処理の実行が可能になるので、ステータス情報が「ジョブ処理中」のホストは、リダイレクトの受け付けが可能であるものとしてもよい。この場合、リダイレクトを受け付けたステータス情報が「ジョブ処理中」のホストは、そのジョブの処理が終了次第、リダイレクトされたリクエストに対する応答処理を実行するものとすればよい。また、ステータス情報が「ジョブ処理中」であっても、そのジョブ、およびリダイレクトされたリクエストに対する応答処理の並列処理が可能であれば、そのジョブと並列してリクエストに対する応答処理を実行するものとしてもよい。また、リダイレクト先の候補となる複数のホストのうち、ステータス情報が「正常」（または「アップデート完了」）であるホストと、ステータス情報が「ジョブ処理中」であるホストとが存在する場合、リダイレクト先として、ステータス情報が「ジョブ処理中」であるホストよりも、ステータス情報が「正常」（または「アップデート完了」）であるホストを優先させること望ましいのは言うまでもない。

図１６（ｂ）に示すステータス情報テーブル１００２の例では、ホスト名が「ｐｏｒｔａｌ−０１２」であるホスト１１１ｂのステータス情報が「ジョブ処理中」であり、ホスト名が「ｐｏｒｔａｌ−０１３」であるホスト１１２ｂのステータス情報が「正常」である。したがって、ホスト１１０ｂの第２管理部１０３は、図１７に示すように、ステータス情報が「正常」であるホスト１１２ｂに対してリクエストをリダイレクトする。そして、ホスト１１２ｂが、ホスト１１０ｂに代わって、リクエストに対する応答処理を実行する。

以上のように、本実施の形態では、外部からのリクエストを、インターネット２を介して受信したホストが、自身のステータスにより、そのリクエストに対応する応答処理の実行ができない場合、同一クラスタ内の他のホストのステータス情報を確認し、そのステータス情報に基づいてリクエストに対応する応答処理の実行が可能な他のホストを決定し、決定したホストにリクエストをリダイレクトするものとしている。リクエストのリダイレクトを受けたホストは、元々、外部からリクエストを受信したホストに代わって、リクエストに対応する応答処理を実行する。これによって、クラスタ内の複数のホストがアップデート動作中であっても、クラスタ内の他のホストにリクエストをリダイレクトして、リクエストに対する応答処理を実行することができるので、リクエストを送ったユーザ側から見て、リクエストに対する応答を受けつつ、クラスタが無停止の状態でアップデート動作を行うことができる。

［第５の実施の形態］
第５の実施の形態に係る情報システムについて、第４の実施の形態に係る情報システムと相違する点を中心に説明する。第４の実施の形態では、外部からのリクエストに対し、アプリクラスタのホストが、他のホストのステータス情報に応じてリダイレクトする動作について説明した。本実施の形態では、リクエストに対する応答処理をするアプリクラスタのホストが、他のクラスタの機能を利用する場合において、そのクラスタのホストのステータス情報に応じて、機能の利用先を決定する動作について説明する。なお、本実施の形態の情報システム、サービス監視サーバ２０、構成管理サーバ３０、およびホスト１００の構成は、図１〜３で示した構成と同様である。

（ステータス情報の共有）
図１８は、第５の実施形態のリクエストを受信したアプリクラスタのホストが適切な共通サービスクラスタのホストにアクセスする動作を説明する図である。まず、図１８を参照しながら、本実施の形態の情報システムの各クラスタ内、およびクラスタ間でステータス情報を共有する動作について説明する。なお、ここでは、ホスト同士でステータス情報を共有するクラスタとして、本番環境システム１０ｂのアプリクラスタ１１ｂおよび共通サービスクラスタ１２ｂを例にして説明する。また、説明を簡潔にするため、図１８（ａ）では、アプリクラスタ１１ｂが有するホストとして、ホスト１１０ｂおよびホスト１１１ｂのみを図示し、共通サービスクラスタ１２ｂが有するホストとして、ホスト１２０ｂおよびホスト１２１ｂのみを図示している。

図１８（ａ）に示すアプリクラスタ１１ｂのホスト１１０ｂ、１１１ｂ、および共通サービスクラスタ１２ｂのホスト１２０ｂ、１２１ｂは、それぞれ、状態を示す情報であるステータス情報をお互いに共有するためのステータス情報テーブル１００３を記憶部１０８に記憶している。

ステータス情報テーブル１００３では、図１８（ｂ）に示すように、クラスタ名と、ホスト名と、ＩＰアドレスと、ステータスとが関連付けられて管理される。例えば、図１８（ｂ）に示すステータス情報テーブル１００３においては、クラスタ名が「ａｐｐ」で、ホスト名が「ａｐｐ−０１１」であるホストのＩＰアドレスは「ｘｘ．ｘｘ．ｘｘ．１３３」であり、ステータスは「アップデート中」であることが示されている。なお、図１８（ｂ）に示すＩＰアドレスは、表記を簡略化して示している。また、本実施の形態では、ステータス情報テーブル１００３のホスト名「ｐｏｒｔａｌ−０１１」がホスト１１０ｂに対応し、ホスト名「ｐｏｒｔａｌ−０１２」がホスト１１１ｂに対応し、ホスト名「ａｐｐ−０１１」がホスト１２０ｂに対応し、ホスト名「ａｐｐ−０１２」がホスト１２１ｂに対応しているものとして説明する。

アプリクラスタ１１ｂおよび共通サービスクラスタ１２ｂの各ホスト（ホスト１１０ｂ、１１１ｂ、１２０ｂ、１２１ｂ）の第２管理部１０３は、定期的、または特定の条件に従う間隔で、互いのステータス情報を、通信部１０１を介して送受信し、取得したステータス情報を、ステータス情報テーブル１００３に更新することによって、互いのステータスを管理している。すなわち、各クラスタのホストは、自身が属するクラスタだけではなく、異なるクラスタのホストともステータス情報を送受信して交換する。また、アプリクラスタ１１ｂおよび共通サービスクラスタ１２ｂの各ホストの第３管理部１０４は、定期的、または特定の条件に従う間隔で、自身のステータス情報を取得し、取得した自身のステータス情報を、ステータス情報テーブル１００３に更新することによって、自身のステータスも管理する。

図１８に示す本番環境システム１０ｂのアプリクラスタ１１ｂおよび共通サービスクラスタ１２ｂの各ホスト（ホスト１１０ｂ、１１１ｂ、１２０ｂ、１２１ｂ）は、第２の実施の形態で説明した動作と同様に、上述のように、異なるクラスタとの間でステータス情報を共有し、クラスタの依存関係に基づいて、アップデート動作を行うことが可能である。すなわち、アプリクラスタ１１ｂおよび共通サービスクラスタ１２ｂの各ホストは、ステータスとして、図５に示すように、「正常」、「ジョブ処理中」、「退避中」、「アップデート中」および「アップデート完了」等の各ステータスを取り得る。

（外部からのリクエストに対する応答動作）
次に、図１８を参照しながら、アプリクラスタ１１ｂのホストが外部からリクエストを受信した場合に、そのリクエストに対して応答する動作について説明する。外部のインターネット２と通信することが可能な本番環境システム１０ｂのアプリクラスタ１１ｂの各ホストは、図１８（ａ）に示すように、外部からインターネット２を介して、アプリクラスタ１１ｂの機能の提供を要求するためのリクエストをランダムに受信する。図１８（ａ）に示す例では、外部からインターネット２を介して送信されたリクエストを、アプリクラスタ１１ｂのホスト１１０ｂが、通信部１０１を介して受信した例を示している。

ホスト１１０ｂの第３管理部１０４は、ステータス情報テーブル１００３で管理している自身のステータス情報を確認する。第３管理部１０４は、図１８（ｂ）のステータス情報テーブル１００３に示すように、自身のステータス情報が「正常」であることを確認する。したがって、第３管理部１０４は、自身のステータス情報が「正常」であることから、外部からのリクエストに対する応答として、機能の提供を行う。また、図１８（ｂ）のステータス情報テーブル１００３の例では、ホスト１１０ｂのステータス情報が「正常」となっているが、例えば、ステータス情報が「アップデート完了」である場合でも、リクエストに対する応答処理は可能であるので、ホスト１１０ｂの第３管理部１０４は、自身のステータス情報が「アップデート完了」である場合でも、外部からのリクエストに対する応答として、機能の提供を行う。

ここで、ホスト１１０ｂがリクエストに対する応答処理を実行するために、他のクラスタである共通サービスクラスタ１２ｂの共通サービスの利用が必要な場合がある。この場合、ホスト１１０ｂは、共通サービスを利用するために、共通サービスクラスタ１２ｂのいずれかのホストにアクセスする必要がある。そこで、ホスト１１０ｂの第２管理部１０３は、ステータス情報テーブル１００３を参照し、共通サービスクラスタ１２ｂ内のホスト（図１８（ａ）の例ではホスト１２０ｂ、１２１ｂ）のステータス情報を参照する。第２管理部１０３は、共通サービスクラスタ１２ｂ内のホスト１２０ｂ、１２１ｂの各ステータス情報に基づいて、リクエストに対する応答処理を実行するために、共通サービスを利用する共通サービスクラスタ１２ｂ内のホストを決定する。具体的には、第２管理部１０３は、共通サービスクラスタ１２ｂのホストのうち、ステータス情報が「正常」または「アップデート完了」であるホストが存在する場合、そのホストから共通サービスの利用が可能であると判断し、そのホストにアクセスする。また、ステータス情報が「アップデート完了」であるホストは、本番環境システム１０ｂの異常等によりロールバックを実行する可能性があるので、第２管理部１０３は、ステータス情報が「アップデート完了」であるホストよりも、ステータス情報が「正常」であるホストを優先してアクセスすることが望ましい。

また、第２管理部１０３は、共通サービスクラスタ１２ｂ内のホストのうち、ステータス情報が「ジョブ処理中」のホストは特定のジョブの処理を実行中であるため、アクセスしない。また、第２管理部１０３は、共通サービスクラスタ１２ｂ内のホストのうち、ステータス情報が「退避中」のホストは不具合の発生等によって共通サービスクラスタ１２ｂから切り離されている状態であるため、アクセスしない。また、第２管理部１０３は、共通サービスクラスタ１２ｂ内のホストのうち、ステータス情報が「アップデート中」のホストはアップデート情報によるアップデート動作中であるため、アクセスしない。

なお、ステータス情報が「ジョブ処理中」のホストにはアクセスしないものとしたが、これに限定されるものではなく、「ジョブ処理中」である場合、特定のジョブの処理が終了すれば、アクセスしたホスト１１０ｂに対して共通サービスの提供が可能になるので、ステータス情報が「ジョブ処理中」のホストは、アクセスの受け付けが可能であるものとしてもよい。この場合、アクセスを受け付けたステータス情報が「ジョブ処理中」のホストは、そのジョブの処理が終了次第、アクセスされたホスト１１０ｂに対して、共通サービスの提供を行うものとすればよい。また、ステータス情報が「ジョブ処理中」であっても、そのジョブ、およびアクセスされたホスト１１０ｂに対する共通サービスの提供の処理の並列処理が可能であれば、そのジョブと並列してリクエストに対する応答処理を実行するものとしてもよい。また、アクセス先の候補となる複数のホストのうち、ステータス情報が「正常」（または「アップデート完了」）であるホストと、ステータス情報が「ジョブ処理中」であるホストとが存在する場合、アクセス先として、ステータス情報が「ジョブ処理中」であるホストよりも、ステータス情報が「正常」（または「アップデート完了」）であるホストを優先させること望ましいのは言うまでもない。

図１８（ｂ）に示すステータス情報テーブル１００３の例では、ホスト名が「ａｐｐ−０１１」であるホスト１２０ｂのステータス情報が「アップデート中」であり、ホスト名が「ａｐｐ−０１２」であるホスト１２１ｂのステータス情報が「アップデート完了」である。したがって、ホスト１１０ｂの第２管理部１０３は、図１８（ａ）に示すように、ステータス情報が「アップデート完了」であるホスト１２１ｂに対して、共通サービスを利用するためにアクセスする。そして、ホスト１１０ｂの第３管理部１０４（提供手段の一例）は、第２管理部１０３によるホスト１２１ｂへのアクセスによって利用可能となった共通サービスを用いて、外部からのリクエストに対する応答処理を実行する。

なお、図１８（ａ）の例では、外部からのリクエストがインターネット２を介して、アプリクラスタ１１ｂのホスト１１０ｂにより受信され、そのホスト１１０ｂのステータス情報が「正常」であるため、ホスト１１０ｂがリクエストに対する応答処理を実行する例を示したが、これに限定されるものではない。例えば、リクエストを受信したアプリクラスタ１１ｂのホストが、リクエストに対する応答処理を実行できないステータスである場合、上述の第４の実施の形態で上述したように、応答処理の実行が可能なアプリクラスタ１１ｂ内の他のホストにリダイレクトし、そのホストが、共通サービスクラスタ１２ｂ内のホストのステータス情報に応じて、特定のホストにアクセスし、共通サービスの提供を受けるものとしてもよい。

以上のように、本実施の形態では、外部からのリクエストを、インターネット２を介して受信したホスト、または、そのホストからリダイレクトを受けたホストが、リクエストに対する応答処理を実行するために、他のクラスタの機能（共通サービスクラスタ１２ｂである場合は、共通サービス）を利用する際、他のクラスタ内のホストのステータス情報を確認し、そのステータス情報に基づいて、機能（例えば、共通サービス）を利用することが可能なホストを決定し、決定したホストにアクセスして機能を利用するものとしている。これによって、外部からのリクエストに応答するための機能（例えば、共通サービス）を提供するクラスタ内の複数のホストがアップデート動作中であっても、そのクラスタ内のホストのうち機能の提供が可能なステータスを有するホストにアクセスすることによって、リクエストに対する応答処理を実行することができる。これによって、リクエストを送ったユーザ側から見て、リクエストに対する応答を受けつつ、クラスタが無停止の状態でアップデート動作を行うことができる。

なお、上述の図１８の例では、アプリクラスタ１１ｂのホストが、共通サービスクラスタ１２ｂのホストの共通サービスの提供を受けるためにアクセスする動作について説明したが、これに限定されるものではない。例えば、アプリクラスタ１１ｂのホストが、データベースクラスタ１３ｂ（図１参照）のホストの機能の提供を受けるためにアクセスする動作、および、共通サービスクラスタ１２ｂのホストが、さらにデータベースクラスタ１３ｂのホストにアクセスする場合の動作等にも、上述の図１８を例にして説明した動作を適用することが可能である。

また、上述の各実施の形態において、ホスト１００の第１管理部１０２、第２管理部１０３、第３管理部１０４、アップデート部１０５、イベント発行部１０６およびロールバック部１０７、サービス監視サーバ２０のシステム確認部２０２、ならびに、構成管理サーバ３０の提供部３０２の少なくともいずれかがプログラムの実行によって実現される場合、そのプログラムは、ＲＯＭ５０２等に予め組み込まれて提供されるものとしてもよい。また、上述の各実施の形態の情報システムで実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。また、上述の各実施の形態の情報システムで実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上述の各実施の形態の情報システムで実行されるプログラムを、インターネット等のネットワーク経由で提供または配布するように構成してもよい。上述の各実施の形態の情報システムで実行されるプログラムは、上述したホスト１００の第１管理部１０２、第２管理部１０３、第３管理部１０４、アップデート部１０５、イベント発行部１０６およびロールバック部１０７、サービス監視サーバ２０のシステム確認部２０２、ならびに、構成管理サーバ３０の提供部３０２の少なくともいずれかを含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５０１が上述のＲＯＭ５０２からプログラムを読み出して実行することにより、上述の各部が主記憶装置上にロードされて生成されるようになっている。

１ 情報システム
２ インターネット
１０ａ ステージング環境システム
１０ｂ 本番環境システム
１１ａ、１１ｂ アプリクラスタ
１２ａ、１２ｂ 共通サービスクラスタ
１３ａ、１３ｂ データベースクラスタ
２０、２０ａ、２０ｂ サービス監視サーバ
３０ 構成管理サーバ
５０ 管理者
１００ ホスト
１０１ 通信部
１０２ 第１管理部
１０３ 第２管理部
１０４ 第３管理部
１０５ アップデート部
１０６ イベント発行部
１０７ ロールバック部
１０８ 記憶部
１１０ａ、１１１ａ、１１２ａ、１２０ａ、１２１ａ、１３０ａ、１３１ａ ホスト
１１０ｂ〜１１３ｂ、１２０ｂ〜１２３ｂ、１３０ｂ〜１３３ｂ ホスト
２０１ 通信部
２０２ システム確認部
３０１ 通信部
３０２ 提供部
３０３ 記憶部
５０１ ＣＰＵ
５０２ ＲＯＭ
５０３ ＲＡＭ
５０５ 補助記憶装置
５０６ 記録メディア
５０７ メディアドライブ
５０８ ディスプレイ
５０９ ネットワークＩ／Ｆ
５１０ バスライン
５１１ キーボード
５１２ マウス
５１３ ＣＤ−ＲＯＭ
５１４ ＣＤ−ＲＯＭドライブ
１０００〜１００３ ステータス情報テーブル

特開２０１３−２０６０２４号公報

Claims (13)

1. 複数のホストを含むクラスタを有する監視対象システムと、前記監視対象システムの状態を監視する監視サーバ装置と、を有する情報システムであって、
   前記監視サーバ装置は、
   前記監視対象システムが正常に稼働しているか否かを確認する確認手段と、
   前記確認手段により確認された結果を示す第１状態情報を送信する第１通信手段と、
   を備え、
   前記ホストは、
   第２通信手段と、
   前記第１通信手段から送信された前記第１状態情報を、前記第２通信手段を介して受信する第１受信手段と、
   同一のクラスタ内の他のホストから、前記第２通信手段を介して、前記他のホストの動作状態を示す第２状態情報を受信する第２受信手段と、
   アップデート動作の開始が指定された場合、外部から前記第２通信手段を介してアップデート情報を取得し、前記アップデート情報に基づいて前記アップデート動作を実行するアップデート手段と、
   前記アップデート手段により前記アップデート動作が完了した後、前記第１受信手段により受信された前記第１状態情報が正常である場合、前記第２受信手段により受信された前記第２状態情報が、前記アップデート動作を実行することが可能な状態を示す前記他のホストのいずれかに対して、前記第２通信手段を介してアップデート開始指令を通知する通知手段と、
   を備えた情報システム。
2. 前記監視対象システムは、複数のクラスタを有し、
   前記ホストの前記通知手段は、前記複数のクラスタのうち該ホストを含む第１クラスタが有する全てのホストの前記アップデート動作が終了した場合、前記複数のクラスタの前記アップデート動作の順序を規定する依存関係に基づいて、前記複数のクラスタのうち次に前記アップデート動作を行う第２クラスタを特定し、前記第２クラスタに含まれるホストのいずれかに、前記第２通信手段を介して、前記アップデート開始指令を通知する請求項１に記載の情報システム。
3. 前記ホストの前記通知手段は、前記第１クラスタが有する全てのホストの前記アップデート動作が終了した場合、前記第２通信手段を介して、外部装置が有する前記依存関係を規定する依存関係情報を参照し、前記依存関係情報に基づいて前記第２クラスタを特定する請求項２に記載の情報システム。
4. 前記外部装置によって、前記依存関係情報に基づいて前記複数のクラスタのうち最初に前記アップデート動作を行う前記第１クラスタが特定され、
   前記第１クラスタが含む前記ホストの前記アップデート手段は、さらに、前記外部装置によって通知されたアップデート開始指令に従って、前記アップデート動作を実行する請求項３に記載の情報システム。
5. 前記ホストは、
   前記アップデート動作が実行中に、前記第１受信手段により受信された前記第１状態情報が、前記監視対象システムの稼働状態が異常であることを示す場合、該アップデート動作を中断させ、該ホストの状態を該アップデート動作前の状態に戻すロールバック手段を、さらに備えた請求項１に記載の情報システム。
6. 前記アップデート手段は、前記監視対象システムの稼働が停止中の場合、前記第１状態情報および前記第２状態情報が示す内容に関わらず、入力手段により受け付けたアップデート操作の情報を受け取った時点で前記アップデート動作を実行する請求項１に記載の情報システム。
7. 前記アップデート手段は、前記監視対象システムの稼働が停止中の場合、前記第１状態情報および前記第２状態情報が示す内容、ならびに前記依存関係に関わらず、入力手段により受け付けたアップデート操作の情報を受け取った時点で前記アップデート動作を実行する請求項２に記載の情報システム。
8. 前記アップデート手段は、前記アップデート動作とは異なる処理を実行中に前記アップデート動作の開始が指定された場合、前記アップデート動作とは異なる処理が終了した時点で、前記アップデート動作を開始する請求項１に記載の情報システム。
9. 前記ホストは、
   前記第２通信手段によって外部から特定の機能の提供を要求するリクエストが受信された場合、該ホスト自身の動作状態を示す第３状態情報を確認する確認手段と、
   前記確認手段により前記第３状態情報が前記特定の機能の提供が不可であることを示すことが確認された場合、前記第２受信手段により受信された前記第２状態情報が、前記特定の機能の提供を行うことが可能な状態を示す前記他のホストのいずれかに対して、前記第２通信手段を介して前記リクエストをリダイレクトするリダイレクト手段と、
   をさらに備えた請求項１〜８のいずれか一項に記載の情報システム。
10. 前記リダイレクト手段は、前記第２状態情報が前記アップデート動作の完了を示す前記他のホストよりも優先して、前記第２状態情報が正常を示す前記他のホストに対して、前記リクエストをリダイレクトする請求項９に記載の情報システム。
11. 前記ホストは、前記リクエストを受信し、かつ、該ホストの前記第３状態情報が前記特定の機能を提供することが可能な状態を示す場合、または、前記他のホストからリダイレクトされた場合、前記特定の機能の提供のために、該ホストを含むクラスタとは別のクラスタに含まれるホストのうち、該ホストの前記第２状態情報がサービスの提供を行うことが可能な状態を示すホストのいずれかからの前記サービスを利用して前記特定の機能を提供する提供手段を、さらに備えた請求項９または１０に記載の情報システム。
12. 前記提供手段は、前記第２状態情報が前記アップデート動作の完了を示す前記別のクラスタのホストよりも優先して、前記第２状態情報が正常を示す前記別のクラスタのホストからの前記サービスを利用して前記特定の機能を提供する請求項１１に記載の情報システム。
13. 複数のホストを含むクラスタを有する監視対象システムと、前記監視対象システムの状態を監視する監視サーバ装置と、を有する情報システムのアップデート方法であって、
    前記監視対象システムが正常に稼働しているか否かを確認する確認ステップと、
    確認した結果を示す第１状態情報を前記監視サーバ装置から送信する送信ステップと、
    前記監視サーバ装置から送信された前記第１状態情報を、通信手段を介して受信する第１受信ステップと、
    同一のクラスタ内の他のホストから、前記通信手段を介して、前記他のホストの動作状態を示す第２状態情報を受信する第２受信ステップと、
    前記ホストが、アップデート動作の開始が指定された場合、外部から前記通信手段を介してアップデート情報を取得し、前記アップデート情報に基づいて前記アップデート動作を実行するアップデートステップと、
    前記アップデート動作が完了した後、受信した前記第１状態情報が正常である場合、受信した前記第２状態情報が、前記アップデート動作を実行することが可能な状態を示す前記他のホストのいずれかに対して、前記通信手段を介してアップデート開始指令を通知する通知ステップと、
    を備えたアップデート方法。

Images