JP2013545151A - サーバ管理装置、サーバ管理方法およびプログラム - Google Patents

Abstract

【課題】稼働系サーバと待機系サーバを備えたサービス提供システムによるサービスの提供が、サーバの障害またはクライアントと両サーバとを接続するネットワークの障害のいずれによって停止した場合においても、サービスを回復できるようにすること。
【解決手段】サーバ管理装置は、クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視し、稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対してパケットの転送経路を変更するように指示し、転送経路の変更後に記稼動系サーバからの応答がないときに限り、稼動系サーバが停止したものと認識して、サービスの提供を代替する待機系サーバに対してサービスを提供するように指示する。
【選択図】図１

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２０１０−２７５６６７号（２０１０年１２月１０日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、サーバ管理装置、サーバ管理方法およびプログラムに関し、特に、稼動系サーバと待機系サーバを有するサービス提供システムの障害対策を行うサーバ間装置、サーバ管理方法およびプログラムに関する。

サーバの可用性（Ａｖａｉｌａｂｉｌｉｔｙ）を高めることを目的とした、ＨＡ（Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ）クラスタと呼ばれる構成が知られている。ＨＡクラスタでは、２台のサーバを用い、一方を稼働系サーバ（ａｃｔｉｖｅ ｓｅｒｖｅｒ）、他方を待機系サーバ（ｓｔａｎｄｂｙ ｓｅｒｖｅｒ）とする。稼動系サーバが正常状態である場合には、稼働系サーバがサービスを提供する。一方、待機系サーバは、稼働系サーバを監視し、稼働系サーバが正常に動作をしていないことを検出した場合に、稼動系サーバの処理を引き継ぐ。これにより、サーバの障害対策を実現する。

また、サーバの障害対策として、セッションを監視することでサーバの障害を検出するシステムが特許文献１に記載されている。

特開２００７−１５６５６９号公報

Ｎｉｃｋ ＭｃＫｅｏｗｎほか７名，"ＯｐｅｎＦｌｏｗ：Ｅｎａｂｌｉｎｇ Ｉｎｎｏｖａｔｉｏｎ ｉｎ Ｃａｍｐｕｓ Ｎｅｔｗｏｒｋｓ，"［ｏｎｌｉｎｅ］，［平成２２年９月２９日検索］，インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｆｌｏｗｓｗｉｔｃｈ．ｏｒｇ／／ｄｏｃｕｍｅｎｔｓ／ｏｐｅｎｆｌｏｗ−ｗｐ−ｌａｔｅｓｔ．ｐｄｆ〉． "ＯｐｅｎＦｌｏｗ Ｓｗｉｔｃｈ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．０．０．（Ｗｉｒｅ Ｐｒｏｔｏｃｏｌ ０ｘ０１），"［平成２２年９月２９日検索］，インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｆｌｏｗｓｗｉｔｃｈ．ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｏｐｅｎｆｌｏｗ−ｓｐｅｃ−ｖ１．０．０．ｐｄｆ〉．

上記の特許文献および非特許文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者によってなされたものである。

待機系サーバによる稼働系サーバの状態監視では、両サーバとクライアントの間のネットワークの状態を考慮することができないという問題がある。なぜなら、待機系サーバは、稼働系サーバの状態を監視するに過ぎないからである。

また、サーバとクライアントの間で障害を検出する場合、ネットワークの詳細を考慮することができないという問題がある、なぜなら、クライアントとサーバの間のセッションの状態に基づいて、障害の有無が判定されるからである。

そこで、稼働系サーバと待機系サーバを備えたサービス提供システムによるサービスの提供が、サーバの障害またはクライアントと両サーバとを接続するネットワークの障害のいずれによって停止した場合においても、サービスを回復できるようにすることが課題となる。本発明は、かかる課題を解決するサーバ管理装置、サーバ管理方法およびプログラムを提供することにある。

本発明の第１の視点に係るサーバ管理装置は、
クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視するサーバ監視部と、
前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する経路変更指示部と、
転送経路の変更後に前記記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示するサービス提供指示部と、を備えている。

本発明の第２の視点に係るサーバ管理方法は、
サーバ管理装置が、クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視する工程と、
前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する工程と、
転送経路の変更後に前記記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示する工程と、を含む。

本発明の第３の視点に係るプログラムは、
クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視する処理と、
前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する処理と、
転送経路の変更後に前記記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示する処理と、をコンピュータに実行させる。なお、プログラムは、非トランジエントなコンピュータ読み取り可能記録媒体（ｎｏｎ−ｔｒａｎｓｉｅｎｔ ｃｏｍｐｕｔｅｒ−ｒｅａｄａｂｌｅ ｓｔｏｒａｇｅ ｍｅｄｉｕｍ）に記録されるようにしてもよい。

本発明に係るサーバ管理装置、サーバ管理方法およびプログラムによると、稼働系サーバと待機系サーバを備えたサービス提供システムによるサービスの提供が、サーバの障害またはクライアントと両サーバとを接続するネットワークの障害のいずれによって停止した場合においても、サービスを回復することができる。

第１の実施形態に係るサービス提供システムの構成を示すブロック図である。 第１の実施形態に係るサービス提供システムの他の構成を示すブロック図である。 オープンフローのフローテーブルのエントリを示す図である。 オープンフローのアクションを示す図である。 第１の実施形態に係るサービス提供システムにおけるスイッチの構成を示すブロック図である。 第１の実施形態に係るサービス提供システムにおけるサーバ管理装置の動作を示すフロー図である。 第２の実施形態に係るサービス提供システムにおけるサーバの構成を示すブロック図である。 第２の実施形態に係るサービス提供システムにおけるサーバ管理装置の動作を示すフロー図である。 第３の実施形態に係るサーバ管理装置の動作を示すフロー図である。 第３の実施形態に係るサーバ管理装置の動作を示すフロー図である。 第４の実施形態に係るサーバ管理装置の動作を示すフロー図である。 第４の実施形態に係るサーバ管理装置の他の動作を示すフロー図である。 第５の実施形態に係るサーバ管理装置の動作を示すフロー図である。 第５の実施形態に係るサーバ管理装置の動作を示すフロー図である。 第５の実施形態に係るサーバ管理装置の動作を示すフロー図である。 本発明に係るサーバ管理装置の構成を示すブロック図である。

はじめに、本発明の概要について説明する。なお、この概要に付記する図面参照符号は、専ら理解を助けるための例示であり、本発明を図示の態様に限定することを意図するものではない。

図１６は、本発明に係るサーバ管理装置の構成を一例として示すブロック図である。また、図１は、本発明に係るサーバ管理装置を備えたサービス提供システムの構成を示す図である。図１６および図１を参照すると、サーバ管理装置（４）は、クライアント（５）に複数のスイッチ（１ａ〜１ｃ）を介してサービスを提供する稼動系サーバ（３ａ）の稼働状態を監視するサーバ監視部（４１）と、稼動系サーバ（３ａ）からの応答がない場合には、複数のスイッチ（１ａ〜１ｃ）のルーティングを管理する経路制御装置（２）に対して、パケットの転送経路を変更するように指示する経路変更指示部（４２）と、転送経路の変更後に稼動系サーバ（３ａ）からの応答がないときには、稼動系サーバ（３ａ）が停止したものと認識して、サービスの提供を代替する待機系サーバ（３ｂ）に対してサービスを提供するように指示するサービス提供指示部（４３）と、を備えている。

また、サーバ監視部（４１）は、複数のスイッチ（１ａ〜１ｃ）のうちのクライアント（５）に最も少ないホップ数で接続されたスイッチ（１ａ）を経由して稼動系サーバ（３ａ）の稼動状態を監視することが好ましい。

さらに、経路変更指示部（４２）は、稼動系サーバ（３ａ）が停止したものと認識した場合には、パケットの転送経路を、クライアント（５）と稼働系サーバ（３ａ）の間から、クライアント（５）と待機系サーバ（３ｂ）の間へ変更するように経路制御装置（２）に指示することが好ましい。

また、サービス提供指示部（４３）は、稼動系サーバ（３ａ）が停止したものと認識した場合には、サービスの提供に関するアプリケーションプログラムを起動するように待機系サーバ（３ｂ）に指示することが好ましい。

稼動系サーバ（３ａ）からの応答がない場合にパケットの転送経路を変更するように経路制御装置（２）に指示することを経路変更指示部（４２）が所定の回数にわたって繰り返した場合においても、稼動系サーバ（３ａ）からの応答がないときには、サービス提供指示部（４３）は、稼動系サーバ（３ａ）が停止したものと認識するようにしてもよい。

サーバ監視部（４１）は、稼動系サーバ（３ａ）が稼働していることを確認した場合には、サービスに関するアプリケーションプログラムの稼動状態を確認し、サービス提供指示部（４３）は、アプリケーションが稼動していないときには、アプリケーションを再起動するように稼動系サーバ（３ａ）に指示するようにしてもよい。

本発明に係るサーバ管理装置（４）によると、稼働系サーバ（３ａ）と待機系サーバ（３ｂ）を備えたサービス提供システムによるサービスの提供が、サーバの障害またはクライアント（５）と両サーバ（３ａ、３ｂ）とを接続するネットワークの障害のいずれによって停止した場合においても、サービスを回復することができる。

また、本発明に係るサーバ管理装置（４）によると、サービスの提供が停止した原因が、サーバの障害によるものか、クライアント（５）とサーバとの間のネットワークの障害によるものかを判別することができる。なぜなら、パケットの転送経路を変更した後においても、サーバからの応答がない場合には、サーバに障害が生じた蓋然性が高いと解されるからである。

さらに、本発明に係るサーバ管理装置（４）によると、サービスの可用性を向上させることができる。なぜなら、稼動系サーバ（３ａ）を待機系サーバ（３ｂ）に切り替える際に、サーバとクライアント（５）との間のパケットの転送経路も併せて変更するからである。

なお、本発明において、下記の形態が可能である。
［形態１］
上記第１の視点に係るサーバ管理装置のとおりである。
［形態２］
前記サーバ監視部は、前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視することが好ましい。
［形態３］
前記経路変更指示部は、前記稼動系サーバが停止したものと認識した場合には、前記クライアントと前記稼働系サーバの間の通信経路を、前記クライアントと前記待機系サーバの間の通信経路に変更するように前記経路制御装置に指示することが好ましい。
［形態４］
前記サービス提供指示部は、前記稼動系サーバが停止したものと認識した場合には、前記サービスの提供に関するアプリケーションプログラムを起動するように前記待機系サーバに指示することが好ましい。
［形態５］
前記サービス提供指示部は、前記稼動系サーバからの応答がない場合に通信経路を変更するように前記経路制御装置に指示することを前記経路変更部が所定の回数にわたって繰り返した場合においても、前記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識するようにしてもよい。
［形態６］
前記サーバ監視部は、前記稼動系サーバが稼働していることを確認した場合には、前記サービスに関するアプリケーションプログラムの稼動状態を確認し、
前記サービス提供指示部は、前記アプリケーションが稼動していないときには、前記アプリケーションを再起動するように前記稼動系サーバに指示するようにしてもよい。
［形態７］
サービス提供システムは、
前記稼動系サーバと、
前記待機系サーバと、
前記経路制御装置と、
上記サーバ管理装置と、を備えていることが好ましい。
［形態８］
上記第２の視点に係るサーバ管理方法のとおりである。
［形態９］
前記サーバ監視部が、前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視することが好ましい。
［形態１０］
前記サーバ管理装置が、前記稼動系サーバが停止したものと認識した場合には、前記クライアントと前記稼働系サーバの間の通信経路を、前記クライアントと前記待機系サーバの間の通信経路に変更する工程を含むことが好ましい。
［形態１１］
上記第３の視点に係るプログラムのとおりである。
［形態１２］
前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視する処理を、コンピュータに実行させることが好ましい。
［形態１３］
前記稼動系サーバが停止したものと認識した場合には、前記クライアントと前記稼働系サーバの間の通信経路を、前記クライアントと前記待機系サーバの間の通信経路に変更する処理を、コンピュータに実行させることが好ましい。

（実施形態１）
第１の実施形態に係るサービス提供システムについて、図面を参照して詳細に説明する。図１は、本実施形態に係るサービス提供システムの構成を示すブロック図である。

図１を参照すると、本実施形態のサービス提供システムは、ネットワークを構成するスイッチ１ａ〜１ｃと、スイッチ群１のルーティングを制御する経路制御装置２と、ネットワークを介してサービスを提供するサーバ３ａ，３ｂと、サーバ３ａ，３ｂを管理するサーバ管理装置４と、クライアント５とを備えている。

サーバ３ａ，３ｂは、サービスを提供するアプリケーションを実行する計算機である。また、本実施形態では、サーバ３ａが稼働系であり、サーバ３ｂが待機系であり、正常状態ではサーバ３ａがサービスを提供する。さらに、サーバ３ａ，３ｂは、死活確認のパケットを受け取ると応答を返す。

図２は、本実施形態に係るサービス提供システムの他の構成を示すブロック図である。サーバ３ａ，３ｂは、図２に示すように、ストレージ６によりデータを共有する構成としてもよい。また、サーバ３ａ，３ｂ間で、通信によりデータを同期するようにしてもよい。

クライアント５は、計算機等の機器であり、ネットワークを介してサーバ３ａ，３ｂが提供するサービスを使用する。なお、クライアント５は、複数あってもよい。

ネットワークは、スイッチ１ａ〜１ｃを含む。スイッチ１ａ〜１ｃは、Ｅｔｈｅｒｎｅｔ（登録商標）等のネットワークスイッチである。スイッチの数、および、スイッチ同士またはサーバ３ａ，３ｂとクライアント５との接続は、図１に示した態様に制限されない。

サーバ管理装置４は、サーバ３ａの状態を監視し、各サーバ３ａ、３ｂの役割（稼働系ないし待機系）を決定する。

経路制御装置２は、スイッチ１ａ〜１ｃのそれぞれのパケットの転送を制御する。サーバ管理装置４と経路制御装置２を、一体としてもよい。

なお、スイッチ１ａ〜１ｃおよび経路制御装置２において、非特許文献１に記載されているオープンフロー（ＯｐｅｎＦｌｏｗ）という技術を採用してもよい。

オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行うものである。転送ノードとして機能するオープンフロースイッチ（ＯＦＳ：ＯｐｅｎＦｌｏｗ Ｓｗｉｔｃｈ、スイッチ１ａ〜１ｃに相当）は、制御サーバに位置付けられるオープンフローコントローラ（ＯＦＣ：ＯｐｅｎＦｌｏｗ Ｃｏｎｔｒｏｌｌｅｒ、経路制御装置２に相当）との通信用のセキュアチャネルを備え、オープンフローコントローラから適宜追加または書き換え指示されるフローテーブルに従って動作する。

図３は、オープンフローのフローテーブルのエントリを一例として示す図である。図３を参照すると、フローテーブルには、フロー毎に、パケットヘッダと照合するルールと、処理内容を定義したアクション（ａｃｔｉｏｎｓ）と、フロー統計情報（ｓｔａｔｓ）との組が定義される。

図４は、非特許文献２に定義されているアクション名とアクションの内容を一例として示す表である。ＯＵＴＰＵＴは、指定ポート（インタフェース）に出力するアクションである。ＳＥＴ＿ＶＬＡＮ＿ＶＩＤからＳＥＴ＿ＴＰ＿ＤＳＴは、パケットヘッダのフィールドを修正するアクションである。

例えば、オープンフロースイッチは、パケットを受信すると、フローテーブル（図３）から、受信パケットのヘッダ情報に適合するルール（ＦｌｏｗＫｅｙ）を持つエントリを検索する。検索の結果、受信パケットに適合するエントリが見つかった場合、オープンフロースイッチは、受信パケットに対して、当該エントリのアクションフィールドに記述された処理内容を実施する。一方、検索の結果、受信パケットに適合するエントリが見つからなかった場合、オープンフロースイッチは、セキュアチャネルを介して、オープンフローコントローラに対して受信パケットを転送し、受信パケットの送信元・送信先に基づいたパケットの経路の決定を依頼し、これを実現するフローエントリを受け取ってフローテーブルを更新する。このように、オープンフロースイッチは、フローテーブルに格納されたエントリを処理規則として用いてパケットを転送する。

図５は、オープンフロー技術を採用した場合におけるスイッチ１ａ〜１ｃの構成を示すブロック図である。図５を参照すると、スイッチ１ａ〜１ｃは、パケット受信部１０、パケット送信部１１、フローテーブル１２、および、パケットカウンタ１３を備えている。

スイッチ１ａ〜１ｃは、経路制御装置２が設定したフローテーブル１２に従い、パケット受信部１０で受信したパケットをパケット送信部１１により適切な接続された装置（スイッチ１ａ〜１ｃ、サーバ３ａ，３ｂ、クライアント５等）に送信する。

また、通過したパケット数をパケットカウンタ１３に記録する。パケットカウンタ１３は、フローテーブル１２中のｓｔａｔｕｓとして記録されるようにしてもよい。

図６は、サーバ管理装置４の動作を一例として示すフローチャートである。

図６を参照すると、サーバ管理装置４は、サーバ３ａを宛先とする、または、サーバ３ａから送られたパケット数をスイッチ１ａから取得する（ステップＳ１００）。サーバ３ａから送られたパケットがある場合には（ステップＳ１０１のＹｅｓ）、ステップＳ１０８へ移行し、それ以外の場合には（ステップＳ１０１のＮｏ）、ステップＳ１０２へ移行する。

スイッチ１ａから、サーバ３ａ宛てに死活確認パケットを送信する（ステップＳ１０２）。死活確認パケットの応答が返ってきた場合には（ステップＳ１０３のＹｅｓ）、ステップＳ１０８へ移行する。

一方、死活確認パケットの応答が返ってこない場合には（ステップＳ１０３のＮｏ）、サーバ管理装置４は、経路制御装置２へ、スイッチ１ａとサーバ３ａとの間の経路の変更を指示し（ステップＳ１０４）、スイッチ１ａから、サーバ３ａ宛てに死活確認パケットを送信する（ステップＳ１０５）。

死活確認パケットの応答が返ってこない場合には（ステップＳ１０６のＮｏ）、サーバ管理装置４は、経路制御装置２へ、スイッチ１ａとサーバ３ｂとの間に通信経路を設定し、サーバ３ｂ宛てのパケットを設定した通信経路を通すように指示する（ステップＳ１０７）。

一方、死活確認パケットの応答が返ってきた場合には（ステップＳ１０６のＹｅｓ）、サーバ管理装置４は、システムで規定した時間待ち（ステップＳ１０８）、ステップＳ１００へ移行する。

このように通信経路を変更したうえでサーバ３ａの死活を確認することで、クライアント５との通信経路も考慮した上での障害対処を行うことが可能となる。

なお、ステップＳ１００では、前回確認してからのパケット数の差分を取得するようにしてもよい。また、サーバ管理装置４は、前回のパケット数を記憶し、前回と今回のパケット数の差分を算出するようにしてもよい。

なお、ステップＳ１０１で、サーバ３ａ宛てに送られたパケットがなかった場合にもステップＳ１０８へ移行してもよい。このようにすることで、サーバ３に処理が発生しないためにサーバ３からのパケットが来ない場合の死活確認を行わずに済む。すなわち、死活確認に伴うネットワーク負荷の軽減と、サーバ３ａの死活確認処理に伴う処理の軽減が可能となる。

ステップＳ１０２，Ｓ１０５での死活確認パケットとして、一例として、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）のＥＣＨＯを送るようにしてもよい。

オープンフローを使用する場合には、サーバ管理装置４から、ＯＦＣ（経路制御装置２）を介してセキュアチャネルを経由でスイッチ１ａへ死活確認パケットを送り、死活確認パケットの応答もセキュアチャネルを介してＯＦＣからサーバ管理装置４へ送る方法を利用することができる。

ステップＳ１０３，Ｓ１０６では、システムに設定された期間内に、死活確認パケットの応答が返ってこなかった場合に応答がなかったものとみなすようにしてもよい。

ステップＳ１０７での通信経路の設定は、例えば、ダイクストラ法により通信経路を算出し、通信経路を形成するスイッチ１ａ〜１ｃのフローテーブルにパケットの転送ルールを記録することでにより実現しうる。

また、ステップＳ１０７では、スイッチ１ａとサーバ３ａとの通信経路を削除してもよい。このようにすることで、スイッチ１ａ〜１ｃのフローテーブルを節約することができる。

なお、パケット数を確認するスイッチ１ａとして、サーバ３ａを使用するクライアント５と接続されるスイッチを用いることで、クライアント５とサーバ３ａ間で通信が可能となるスイッチ１ａ〜１ｃで形成される経路を網羅的に確認することが可能となる。

また、クライアント５が経路制御装置２の管理外のスイッチに接続されている場合、クライアント５からの通信が最初に到着する経路制御装置２の管理下のスイッチ１ａでパケット数を確認することが望ましい。

オープンフローを使用する場合には、監視および死活確認パケットを送り出すスイッチ１ａとして、ｆｉｒｓｔ ｐａｃｋｅｔをＯＦＣに送ったＯＦＳを選ぶようにしてもよい。

（実施形態２）
第２の実施形態に係るサービス提供システムについて、図面を参照して説明する。図７は、本実施形態に係るサービス提供システムにおけるサーバ３ａ，３ｂの構成を示すブロック図である。

図７を参照すると、サーバ３ａ，３ｂは、サービス活性化部２０およびサービス構成ＤＢ２１を備えている。

サービス活性化部２０は、サーバ管理装置４からの指示により指定されたサービスに対応するアプリケーションプログラムの起動を行う。このとき、サービス活性化部２０は、サービス開始時に行う処理を記録したサービス構成ＤＢ２１を使用する。

サービス構成ＤＢ２１は、サービスの識別子とサービス開始時に行う処理をセットで記録したデータベースである。

サービス開始時に行う処理に関しては、シェルスクリプトに記述し、そのシェルスクリプトを起動するようにしてもよい。

図８は、サーバ管理装置４の動作を示すフロー図である。図８を参照して、サーバ管理装置４の動作を説明する。

本実施形態におけるサーバ管理装置４の動作は、ステップＳ１０６で、死活確認パケットの応答が返ってこない場合には（ステップＳ１０６のＮｏ）、ステップＳ２００へ移行する点を除き、第１の実施形態におけるサーバ管理装置４の動作と同じである。

ステップＳ２００において、サーバ管理装置４は、待機系サーバ３ｂへ、サービスの活性化を指示し、ステップＳ１０７へ移行する。

待機系サーバ３ｂは、サービス活性化の指示を受けると、サービス構成ＤＢ２１に記録されたサービス開始時に行う処理を実行する。

このようにすることで、待機系サーバ３ｂは、稼働系サーバ３ａから処理を引き継ぐ場合を除いて、サービスを提供するアプリケーションプログラムを動作させる必要がなくなる。したがって、待機系サーバ３ｂにおいて、ＣＰＵの負荷を軽減することができる。

（実施形態３）
第３の実施形態に係るサーバ管理装置について、図面を参照して説明する。図９は、本実施形態に係るサーバ管理装置４の動作を示すフロー図である。

本実施形態におけるサーバ管理装置４の動作は、死活確認パケットの応答が返ってこない場合には（ステップＳ１０６のＮｏ）、ステップＳ３００へ移行する点を除き、第１の実施形態のサーバ管理装置４の動作と同じである。

サーバ管理装置４は、システムで規定された回数にわたって経路変更を行った場合には（ステップＳ３００のＹｅｓ）、ステップＳ１０７へ移行し、それ以外の場合には（ステップＳ３００のＮｏ）、ステップＳ１０４へ移行し、他の通信経路を試す。

これにより、スイッチ１ａとサーバ３ａとの間で多数の通信経路をとりうる場合においても、各通信経路を経由した死活確認を行うことができる。すなわち、本実施形態によると、多数の通信経路を持ちうるネットワークにも対応することができる。

図１０は、本実施形態に係るサーバ管理装置４の他の動作を示すフロー図である。図１０を参照すると、本実施形態においても、第２の実施形態と同様に、待機系サーバ３ｂの活性化（ステップＳ２００）を行うようにしてもよい。このとき、第２の実施形態のサービス提供システムと同様に、待機系サーバ３ｂにおいて、ＣＰＵの負荷を軽減することができる。

（実施形態４）
第４の実施形態に係るサーバ管理装置について、図面を参照して説明する。図１１は、本実施形態に係るサーバ管理装置４の動作を示すフロー図である。

本実施形態におけるサーバ管理装置４の動作は、死活確認パケットの応答が返ってきた場合には（ステップＳ１０３のＹｅｓまたはステップＳ１０６のＹｅｓ）、ステップＳ４００へ移行する点を除き、第１の実施形態のサーバ管理装置４の動作と同じである。

サーバ管理装置４は、サービス稼働確認パケットを送信する（ステップＳ４００）。稼働確認パケットの応答が返ってきた場合には（ステップＳ４０１のＹｅｓ）、ステップＳ１０８へ移行する。

一方、稼働確認パケットの応答が返ってこなかった場合には（ステップＳ４０１のＮｏ）、サーバ管理装置４は、稼働系サーバ３ａにサービスの再起動を指示する（ステップＳ４０２）。

次に、サーバ管理装置４は、サービス稼働確認パケットを送信する（ステップＳ４０３）。稼働確認パケットの応答が返ってきた場合には（ステップＳ４０４のＹｅｓ）、ステップＳ１０８へ移行し、返ってこなかった場合には（ステップＳ４０４のＮｏ）、ステップＳ１０７へ移行する。

サーバ３ａは、サービス再起動の指示を受けると、サービス構成ＤＢ２１に記録されたサービスの停止処理を行った後に、サービスの開始時に行う処理を実行する。

ステップＳ４００，Ｓ４０３でのサービス稼働確認パケットとして、一例として、サービスが使用するポートにＨＥＬＬＯパケットを送るようにしてもよい。

なお、ステップＳ４０１，Ｓ４０４では、システムに設定された期間内に、死活確認パケットの応答が返ってこなかった場合に応答がなかったとみなすようにしてもよい。

本実施形態でのサービス活性化部２０は、サーバ管理装置４からの指示により、指定されたサービスに対応するアプリケーションプログラムの停止を行う。このとき、サービス活性化部２０は、サービス停止時に行う処理を記録したサービス構成ＤＢ２１を使用する。

サービス構成ＤＢ２１は、サービスの識別子とサービス停止時に行う処理をセットで記録したデータベースである。

サービス停止時に行う処理に関しては、シェルスクリプトに記述し、そのシェルスクリプトを起動するようにしてもよい。

このようにすることで、サーバ３ａは稼働しているものの、サービスを提供するアプリケーションが停止していた場合に、アプリケーションを再起動することでサービスを提供可能とすることができる。すなわち、アプリケーション障害に対応することが可能である。

図１２は、本実施形態に係るサーバ管理装置４の他の動作を示すフロー図である。図１２を参照すると、本実施形態においても、第２の実施形態と同様に、待機系サーバ３ｂの活性化（ステップＳ２００）を行うようにしてもよい。このとき、第２の実施形態のサービス提供システムと同様に、待機系サーバ３ｂにおいて、ＣＰＵの負荷を軽減することができる。

（実施形態５）
第５の実施形態に係るサーバ管理装置について、図面を参照して説明する。図１３は、本実施形態に係るサーバ管理装置４の動作を示すフロー図である。

本実施形態におけるサーバ管理装置４の動作は、稼働確認パケットの応答が返ってこなかった場合には（ステップＳ４０４のＮｏ）、ステップＳ５００へ移行する点を除き、第４の実施形態におけるサーバ管理装置４の動作（図１１）と同じである。

サーバ管理装置４は、スイッチ１ａとサーバ３ａとの通信経路を他の通信経路に変更するように経路制御装置２に指示する（ステップＳ５００）。

次に、サーバ管理装置４は、サービス稼働確認パケットを送信する（ステップＳ５０１）。稼働確認パケットの応答が返ってきた場合には（ステップＳ５０２のＹｅｓ）、ステップＳ１０８へ移行し、返ってこなかった場合には（ステップＳ５０２のＮｏ）、ステップＳ１０７へ移行する。

このようにすることで、特定のサービスの通信が通らない通信経路があった場合にも対応することが可能となる。

図１４は、本実施形態に係るサーバ管理装置４の他の動作を示すフロー図である。図１４を参照すると、本実施形態においても、第２の実施形態（図８）と同様に、待機系サーバ３ｂの活性化（ステップＳ２００）を行うようにしてもよい。このとき、第２の実施形態のサービス提供システムと同様に、待機系サーバ３ｂにおいて、ＣＰＵの負荷を軽減することができる。

図１５は、本実施形態に係るサーバ管理装置４のさらに他の動作を示すフロー図である。図１５を参照すると、本実施形態においても、第３の実施形態（図９）と同様に、応答がなかった場合には（ステップＳ５０２のＮｏ）ステップＳ５００へ移行し、複数の通信経路を試みるようにしてもよい。

このようにすることにより、スイッチ１ａとサーバ３ａとの間に多数の通信経路をとりうる場合において、特定のサービスの通信が通らない通信経路が存在するときにも対応することができる。

本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

１，１ａ〜１ｃ スイッチ（ｓｗｉｔｃｈ）
２ 経路制御装置（ｒｏｕｔｉｎｇ ｃｏｎｔｒｏｌｌｅｒ）
３，３ａ，３ｂ サーバ（ｓｅｒｖｅｒ）
４ サーバ管理装置（ｓｅｒｖｅｒ ｍａｎａｇｅｒ）
５ クライアント（ｃｌｉｅｎｔ）
６ ストレージ（ｓｔｏｒａｇｅ）
１０ パケット受信部
１１ パケット送信部
１２ フローテーブル
１３ パケットカウンタ
２０ サービス（ｓｅｒｖｉｃｅ）活性化部
２１ サービス構成ＤＢ
４１ サーバ監視部
４２ 経路変更指示部
４３ サービス提供指示部

Claims (13)

1. クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視するサーバ監視部と、
   前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する経路変更指示部と、
   転送経路の変更後に前記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示するサービス提供指示部と、を備えていることを特徴とするサーバ管理装置。
2. 前記経路変更指示部は、前記稼動系サーバが停止したものと認識した場合には、パケットの転送経路を、前記クライアントと前記稼働系サーバの間から、前記クライアントと前記待機系サーバの間へ変更するように前記経路制御装置に指示することを特徴とする、請求項１に記載のサーバ管理装置。
3. 前記サーバ監視部は、前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視することを特徴とする、請求項１または２に記載のサーバ管理装置。
4. 前記サービス提供指示部は、前記稼動系サーバが停止したものと認識した場合には、前記サービスの提供に関するアプリケーションプログラムを起動するように前記待機系サーバに指示することを特徴とする、請求項１ないし３のいずれか１項に記載のサーバ管理装置。
5. 前記サービス提供指示部は、前記稼動系サーバからの応答がない場合にパケットの転送経路を変更するように前記経路制御装置に指示することを前記経路変更部が所定の回数にわたって繰り返した場合においても、前記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識することを特徴とする、請求項１ないし４のいずれか１項に記載のサーバ管理装置。
6. 前記サーバ監視部は、前記稼動系サーバが稼働していることを確認した場合には、前記サービスに関するアプリケーションプログラムの稼動状態を確認し、
   前記サービス提供指示部は、前記アプリケーションが稼動していないときには、前記アプリケーションを再起動するように前記稼動系サーバに指示することを特徴とする、請求項１ないし５のいずれか１項に記載のサーバ管理装置。
7. 稼動系サーバと、
   待機系サーバと、
   経路制御装置と、
   請求項１ないし６のいずれか１項に記載のサーバ管理装置と、を備えていることを特徴とするサービス提供システム。
8. サーバ管理装置が、クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視する工程と、
   前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する工程と、
   転送経路の変更後に前記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示する工程と、を含むことを特徴とするサーバ管理方法。
9. 前記サーバ管理装置が、前記稼動系サーバが停止したものと認識した場合には、前記クライアントと前記稼働系サーバの間の通信経路を、前記クライアントと前記待機系サーバの間の通信経路に変更する工程をさらに含むことを特徴とする、請求項８に記載のサーバ管理方法。
10. 前記監視工程において、前記サーバ監視部が、前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視することを特徴とする、請求項８または９に記載のサーバ管理方法。
11. クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視する処理と、
    前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する処理と、
    転送経路の変更後に前記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示する処理と、をコンピュータに実行させることを特徴とするプログラム。
12. 前記稼動系サーバが停止したものと認識した場合には、前記クライアントと前記稼働系サーバの間の通信経路を、前記クライアントと前記待機系サーバの間の通信経路に変更する処理を、さらにコンピュータに実行させることを特徴とする、請求項１１に記載のプログラム。
13. 前記監視処理において、前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視する処理を、コンピュータに実行させることを特徴とする、請求項１１または１２に記載のプログラム。

Images