"クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視するサーバ監視部と、前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する経路変更指示部と、転送経路の変更後に前記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示するサービス提供指示部と、を備えていることを特徴とするサーバ管理装置。前記経路変更指示部は、前記稼動系サーバが停止したものと認識した場合には、パケットの転送経路を、前記クライアントと前記稼働系サーバの間から、前記クライアントと前記待機系サーバの間へ変更するように前記経路制御装置に指示することを特徴とする、請求項1に記載のサーバ管理装置。前記サーバ監視部は、前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視することを特徴とする、請求項1または2に記載のサーバ管理装置。前記サービス提供指示部は、前記稼動系サーバが停止したものと認識した場合には、前記サービスの提供に関するアプリケーションプログラムを起動するように前記待機系サーバに指示することを特徴とする、請求項1ないし3のいずれか1項に記載のサーバ管理装置。前記サービス提供指示部は、前記稼動系サーバからの応答がない場合にパケットの転送経路を変更するように前記経路制御装置に指示することを前記経路変更部が所定の回数にわたって繰り返した場合においても、前記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識することを特徴とする、請求項1ないし4のいずれか1項に記載のサーバ管理装置。前記サーバ監視部は、前記稼動系サーバが稼働していることを確認した場合には、前記サービスに関するアプリケーションプログラムの稼動状態を確認し、前記サービス提供指示部は、前記アプリケーションが稼動していないときには、前記アプリケーションを再起動するように前記稼動系サーバに指示することを特徴とする、請求項1ないし5のいずれか1項に記載のサーバ管理装置。稼動系サーバと、待機系サーバと、経路制御装置と、請求項1ないし6のいずれか1項に記載のサーバ管理装置と、を備えていることを特徴とするサービス提供システム。サーバ管理装置が、クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視する工程と、前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する工程と、転送経路の変更後に前記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示する工程と、を含むことを特徴とするサーバ管理方法。前記サーバ管理装置が、前記稼動系サーバが停止したものと認識した場合には、前記クライアントと前記稼働系サーバの間の通信経路を、前記クライアントと前記待機系サーバの間の通信経路に変更する工程をさらに含むことを特徴とする、請求項8に記載のサーバ管理方法。前記監視工程において、前記サーバ監視部が、前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視することを特徴とする、請求項8または9に記載のサーバ管理方法。クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視する処理と、前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する処理と、転送経路の変更後に前記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示する処理と、をコンピュータに実行させることを特徴とするプログラム。前記稼動系サーバが停止したものと認識した場合には、前記クライアントと前記稼働系サーバの間の通信経路を、前記クライアントと前記待機系サーバの間の通信経路に変更する処理を、さらにコンピュータに実行させることを特徴とする、請求項11に記載のプログラム。前記監視処理において、前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視する処理を、コンピュータに実行させることを特徴とする、請求項11または12に記載のプログラム。上記の特許文献および非特許文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者によってなされたものである。待機系サーバによる稼働系サーバの状態監視では、両サーバとクライアントの間のネットワークの状態を考慮することができないという問題がある。なぜなら、待機系サーバは、稼働系サーバの状態を監視するに過ぎないからである。また、サーバとクライアントの間で障害を検出する場合、ネットワークの詳細を考慮することができないという問題がある、なぜなら、クライアントとサーバの間のセッションの状態に基づいて、障害の有無が判定されるからである。そこで、稼働系サーバと待機系サーバを備えたサービス提供システムによるサービスの提供が、サーバの障害またはクライアントと両サーバとを接続するネットワークの障害のいずれによって停止した場合においても、サービスを回復できるようにすることが課題となる。本発明は、かかる課題を解決するサーバ管理装置、サーバ管理方法およびプログラムを提供することにある。本発明の第1の視点に係るサーバ管理装置は、クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視するサーバ監視部と、前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する経路変更指示部と、転送経路の変更後に前記記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示するサービス提供指示部と、を備えている。本発明の第2の視点に係るサーバ管理方法は、サーバ管理装置が、クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視する工程と、前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する工程と、転送経路の変更後に前記記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示する工程と、を含む。本発明の第3の視点に係るプログラムは、クライアントに複数のスイッチを介してサービスを提供する稼動系サーバの稼働状態を監視する処理と、前記稼動系サーバからの応答がない場合には、前記複数のスイッチのルーティングを管理する経路制御装置に対して、パケットの転送経路を変更するように指示する処理と、転送経路の変更後に前記記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識して、前記サービスの提供を代替する待機系サーバに対して前記サービスを提供するように指示する処理と、をコンピュータに実行させる。なお、プログラムは、非トランジエントなコンピュータ読み取り可能記録媒体non-transientcomputer-readablestoragemediumに記録されるようにしてもよい。本発明に係るサーバ管理装置、サーバ管理方法およびプログラムによると、稼働系サーバと待機系サーバを備えたサービス提供システムによるサービスの提供が、サーバの障害またはクライアントと両サーバとを接続するネットワークの障害のいずれによって停止した場合においても、サービスを回復することができる。はじめに、本発明の概要について説明する。なお、この概要に付記する図面参照符号は、専ら理解を助けるための例示であり、本発明を図示の態様に限定することを意図するものではない。図16は、本発明に係るサーバ管理装置の構成を一例として示すブロック図である。また、図1は、本発明に係るサーバ管理装置を備えたサービス提供システムの構成を示す図である。図16および図1を参照すると、サーバ管理装置4は、クライアント5に複数のスイッチ1a~1cを介してサービスを提供する稼動系サーバ3aの稼働状態を監視するサーバ監視部41と、稼動系サーバ3aからの応答がない場合には、複数のスイッチ1a~1cのルーティングを管理する経路制御装置2に対して、パケットの転送経路を変更するように指示する経路変更指示部42と、転送経路の変更後に稼動系サーバ3aからの応答がないときには、稼動系サーバ3aが停止したものと認識して、サービスの提供を代替する待機系サーバ3bに対してサービスを提供するように指示するサービス提供指示部43と、を備えている。また、サーバ監視部41は、複数のスイッチ1a~1cのうちのクライアント5に最も少ないホップ数で接続されたスイッチ1aを経由して稼動系サーバ3aの稼動状態を監視することが好ましい。さらに、経路変更指示部42は、稼動系サーバ3aが停止したものと認識した場合には、パケットの転送経路を、クライアント5と稼働系サーバ3aの間から、クライアント5と待機系サーバ3bの間へ変更するように経路制御装置2に指示することが好ましい。また、サービス提供指示部43は、稼動系サーバ3aが停止したものと認識した場合には、サービスの提供に関するアプリケーションプログラムを起動するように待機系サーバ3bに指示することが好ましい。稼動系サーバ3aからの応答がない場合にパケットの転送経路を変更するように経路制御装置2に指示することを経路変更指示部42が所定の回数にわたって繰り返した場合においても、稼動系サーバ3aからの応答がないときには、サービス提供指示部43は、稼動系サーバ3aが停止したものと認識するようにしてもよい。サーバ監視部41は、稼動系サーバ3aが稼働していることを確認した場合には、サービスに関するアプリケーションプログラムの稼動状態を確認し、サービス提供指示部43は、アプリケーションが稼動していないときには、アプリケーションを再起動するように稼動系サーバ3aに指示するようにしてもよい。本発明に係るサーバ管理装置4によると、稼働系サーバ3aと待機系サーバ3bを備えたサービス提供システムによるサービスの提供が、サーバの障害またはクライアント5と両サーバ3a、3bとを接続するネットワークの障害のいずれによって停止した場合においても、サービスを回復することができる。また、本発明に係るサーバ管理装置4によると、サービスの提供が停止した原因が、サーバの障害によるものか、クライアント5とサーバとの間のネットワークの障害によるものかを判別することができる。なぜなら、パケットの転送経路を変更した後においても、サーバからの応答がない場合には、サーバに障害が生じた蓋然性が高いと解されるからである。さらに、本発明に係るサーバ管理装置4によると、サービスの可用性を向上させることができる。なぜなら、稼動系サーバ3aを待機系サーバ3bに切り替える際に、サーバとクライアント5との間のパケットの転送経路も併せて変更するからである。なお、本発明において、下記の形態が可能である。[形態1]上記第1の視点に係るサーバ管理装置のとおりである。[形態2]前記サーバ監視部は、前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視することが好ましい。[形態3]前記経路変更指示部は、前記稼動系サーバが停止したものと認識した場合には、前記クライアントと前記稼働系サーバの間の通信経路を、前記クライアントと前記待機系サーバの間の通信経路に変更するように前記経路制御装置に指示することが好ましい。[形態4]前記サービス提供指示部は、前記稼動系サーバが停止したものと認識した場合には、前記サービスの提供に関するアプリケーションプログラムを起動するように前記待機系サーバに指示することが好ましい。[形態5]前記サービス提供指示部は、前記稼動系サーバからの応答がない場合に通信経路を変更するように前記経路制御装置に指示することを前記経路変更部が所定の回数にわたって繰り返した場合においても、前記稼動系サーバからの応答がないときには、前記稼動系サーバが停止したものと認識するようにしてもよい。[形態6]前記サーバ監視部は、前記稼動系サーバが稼働していることを確認した場合には、前記サービスに関するアプリケーションプログラムの稼動状態を確認し、前記サービス提供指示部は、前記アプリケーションが稼動していないときには、前記アプリケーションを再起動するように前記稼動系サーバに指示するようにしてもよい。[形態7]サービス提供システムは、前記稼動系サーバと、前記待機系サーバと、前記経路制御装置と、上記サーバ管理装置と、を備えていることが好ましい。[形態8]上記第2の視点に係るサーバ管理方法のとおりである。[形態9]前記サーバ監視部が、前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視することが好ましい。[形態10]前記サーバ管理装置が、前記稼動系サーバが停止したものと認識した場合には、前記クライアントと前記稼働系サーバの間の通信経路を、前記クライアントと前記待機系サーバの間の通信経路に変更する工程を含むことが好ましい。[形態11]上記第3の視点に係るプログラムのとおりである。[形態12]前記複数のスイッチのうちの前記クライアントに最も少ないホップ数で接続されたスイッチを経由して前記稼動系サーバの稼動状態を監視する処理を、コンピュータに実行させることが好ましい。[形態13]前記稼動系サーバが停止したものと認識した場合には、前記クライアントと前記稼働系サーバの間の通信経路を、前記クライアントと前記待機系サーバの間の通信経路に変更する処理を、コンピュータに実行させることが好ましい。実施形態1第1の実施形態に係るサービス提供システムについて、図面を参照して詳細に説明する。図1は、本実施形態に係るサービス提供システムの構成を示すブロック図である。図1を参照すると、本実施形態のサービス提供システムは、ネットワークを構成するスイッチ1a~1cと、スイッチ群1のルーティングを制御する経路制御装置2と、ネットワークを介してサービスを提供するサーバ3a,3bと、サーバ3a,3bを管理するサーバ管理装置4と、クライアント5とを備えている。サーバ3a,3bは、サービスを提供するアプリケーションを実行する計算機である。また、本実施形態では、サーバ3aが稼働系であり、サーバ3bが待機系であり、正常状態ではサーバ3aがサービスを提供する。さらに、サーバ3a,3bは、死活確認のパケットを受け取ると応答を返す。図2は、本実施形態に係るサービス提供システムの他の構成を示すブロック図である。サーバ3a,3bは、図2に示すように、ストレージ6によりデータを共有する構成としてもよい。また、サーバ3a,3b間で、通信によりデータを同期するようにしてもよい。クライアント5は、計算機等の機器であり、ネットワークを介してサーバ3a,3bが提供するサービスを使用する。なお、クライアント5は、複数あってもよい。ネットワークは、スイッチ1a~1cを含む。スイッチ1a~1cは、Ethernet登録商標等のネットワークスイッチである。スイッチの数、および、スイッチ同士またはサーバ3a,3bとクライアント5との接続は、図1に示した態様に制限されない。サーバ管理装置4は、サーバ3aの状態を監視し、各サーバ3a、3bの役割稼働系ないし待機系を決定する。経路制御装置2は、スイッチ1a~1cのそれぞれのパケットの転送を制御する。サーバ管理装置4と経路制御装置2を、一体としてもよい。なお、スイッチ1a~1cおよび経路制御装置2において、非特許文献1に記載されているオープンフローOpenFlowという技術を採用してもよい。オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行うものである。転送ノードとして機能するオープンフロースイッチOFS:OpenFlowSwitch、スイッチ1a~1cに相当は、制御サーバに位置付けられるオープンフローコントローラOFC:OpenFlowController、経路制御装置2に相当との通信用のセキュアチャネルを備え、オープンフローコントローラから適宜追加または書き換え指示されるフローテーブルに従って動作する。図3は、オープンフローのフローテーブルのエントリを一例として示す図である。図3を参照すると、フローテーブルには、フロー毎に、パケットヘッダと照合するルールと、処理内容を定義したアクションactionsと、フロー統計情報statsとの組が定義される。図4は、非特許文献2に定義されているアクション名とアクションの内容を一例として示す表である。OUTPUTは、指定ポートインタフェースに出力するアクションである。SET_VLAN_VIDからSET_TP_DSTは、パケットヘッダのフィールドを修正するアクションである。例えば、オープンフロースイッチは、パケットを受信すると、フローテーブル図3から、受信パケットのヘッダ情報に適合するルールFlowKeyを持つエントリを検索する。検索の結果、受信パケットに適合するエントリが見つかった場合、オープンフロースイッチは、受信パケットに対して、当該エントリのアクションフィールドに記述された処理内容を実施する。一方、検索の結果、受信パケットに適合するエントリが見つからなかった場合、オープンフロースイッチは、セキュアチャネルを介して、オープンフローコントローラに対して受信パケットを転送し、受信パケットの送信元送信先に基づいたパケットの経路の決定を依頼し、これを実現するフローエントリを受け取ってフローテーブルを更新する。このように、オープンフロースイッチは、フローテーブルに格納されたエントリを処理規則として用いてパケットを転送する。図5は、オープンフロー技術を採用した場合におけるスイッチ1a~1cの構成を示すブロック図である。図5を参照すると、スイッチ1a~1cは、パケット受信部10、パケット送信部11、フローテーブル12、および、パケットカウンタ13を備えている。スイッチ1a~1cは、経路制御装置2が設定したフローテーブル12に従い、パケット受信部10で受信したパケットをパケット送信部11により適切な接続された装置スイッチ1a~1c、サーバ3a,3b、クライアント5等に送信する。また、通過したパケット数をパケットカウンタ13に記録する。パケットカウンタ13は、フローテーブル12中のstatusとして記録されるようにしてもよい。図6は、サーバ管理装置4の動作を一例として示すフローチャートである。図6を参照すると、サーバ管理装置4は、サーバ3aを宛先とする、または、サーバ3aから送られたパケット数をスイッチ1aから取得するステップS100。サーバ3aから送られたパケットがある場合にはステップS101のYes、ステップS108へ移行し、それ以外の場合にはステップS101のNo、ステップS102へ移行する。スイッチ1aから、サーバ3a宛てに死活確認パケットを送信するステップS102。死活確認パケットの応答が返ってきた場合にはステップS103のYes、ステップS108へ移行する。一方、死活確認パケットの応答が返ってこない場合にはステップS103のNo、サーバ管理装置4は、経路制御装置2へ、スイッチ1aとサーバ3aとの間の経路の変更を指示しステップS104、スイッチ1aから、サーバ3a宛てに死活確認パケットを送信するステップS105。死活確認パケットの応答が返ってこない場合にはステップS106のNo、サーバ管理装置4は、経路制御装置2へ、スイッチ1aとサーバ3bとの間に通信経路を設定し、サーバ3b宛てのパケットを設定した通信経路を通すように指示するステップS107。一方、死活確認パケットの応答が返ってきた場合にはステップS106のYes、サーバ管理装置4は、システムで規定した時間待ちステップS108、ステップS100へ移行する。このように通信経路を変更したうえでサーバ3aの死活を確認することで、クライアント5との通信経路も考慮した上での障害対処を行うことが可能となる。なお、ステップS100では、前回確認してからのパケット数の差分を取得するようにしてもよい。また、サーバ管理装置4は、前回のパケット数を記憶し、前回と今回のパケット数の差分を算出するようにしてもよい。なお、ステップS101で、サーバ3a宛てに送られたパケットがなかった場合にもステップS108へ移行してもよい。このようにすることで、サーバ3に処理が発生しないためにサーバ3からのパケットが来ない場合の死活確認を行わずに済む。すなわち、死活確認に伴うネットワーク負荷の軽減と、サーバ3aの死活確認処理に伴う処理の軽減が可能となる。ステップS102,S105での死活確認パケットとして、一例として、ICMPInternetControlMessageProtocolのECHOを送るようにしてもよい。オープンフローを使用する場合には、サーバ管理装置4から、OFC経路制御装置2を介してセキュアチャネルを経由でスイッチ1aへ死活確認パケットを送り、死活確認パケットの応答もセキュアチャネルを介してOFCからサーバ管理装置4へ送る方法を利用することができる。ステップS103,S106では、システムに設定された期間内に、死活確認パケットの応答が返ってこなかった場合に応答がなかったものとみなすようにしてもよい。ステップS107での通信経路の設定は、例えば、ダイクストラ法により通信経路を算出し、通信経路を形成するスイッチ1a~1cのフローテーブルにパケットの転送ルールを記録することでにより実現しうる。また、ステップS107では、スイッチ1aとサーバ3aとの通信経路を削除してもよい。このようにすることで、スイッチ1a~1cのフローテーブルを節約することができる。なお、パケット数を確認するスイッチ1aとして、サーバ3aを使用するクライアント5と接続されるスイッチを用いることで、クライアント5とサーバ3a間で通信が可能となるスイッチ1a~1cで形成される経路を網羅的に確認することが可能となる。また、クライアント5が経路制御装置2の管理外のスイッチに接続されている場合、クライアント5からの通信が最初に到着する経路制御装置2の管理下のスイッチ1aでパケット数を確認することが望ましい。オープンフローを使用する場合には、監視および死活確認パケットを送り出すスイッチ1aとして、firstpacketをOFCに送ったOFSを選ぶようにしてもよい。実施形態2第2の実施形態に係るサービス提供システムについて、図面を参照して説明する。図7は、本実施形態に係るサービス提供システムにおけるサーバ3a,3bの構成を示すブロック図である。図7を参照すると、サーバ3a,3bは、サービス活性化部20およびサービス構成DB21を備えている。サービス活性化部20は、サーバ管理装置4からの指示により指定されたサービスに対応するアプリケーションプログラムの起動を行う。このとき、サービス活性化部20は、サービス開始時に行う処理を記録したサービス構成DB21を使用する。サービス構成DB21は、サービスの識別子とサービス開始時に行う処理をセットで記録したデータベースである。サービス開始時に行う処理に関しては、シェルスクリプトに記述し、そのシェルスクリプトを起動するようにしてもよい。図8は、サーバ管理装置4の動作を示すフロー図である。図8を参照して、サーバ管理装置4の動作を説明する。本実施形態におけるサーバ管理装置4の動作は、ステップS106で、死活確認パケットの応答が返ってこない場合にはステップS106のNo、ステップS200へ移行する点を除き、第1の実施形態におけるサーバ管理装置4の動作と同じである。ステップS200において、サーバ管理装置4は、待機系サーバ3bへ、サービスの活性化を指示し、ステップS107へ移行する。待機系サーバ3bは、サービス活性化の指示を受けると、サービス構成DB21に記録されたサービス開始時に行う処理を実行する。このようにすることで、待機系サーバ3bは、稼働系サーバ3aから処理を引き継ぐ場合を除いて、サービスを提供するアプリケーションプログラムを動作させる必要がなくなる。したがって、待機系サーバ3bにおいて、CPUの負荷を軽減することができる。実施形態3第3の実施形態に係るサーバ管理装置について、図面を参照して説明する。図9は、本実施形態に係るサーバ管理装置4の動作を示すフロー図である。本実施形態におけるサーバ管理装置4の動作は、死活確認パケットの応答が返ってこない場合にはステップS106のNo、ステップS300へ移行する点を除き、第1の実施形態のサーバ管理装置4の動作と同じである。サーバ管理装置4は、システムで規定された回数にわたって経路変更を行った場合にはステップS300のYes、ステップS107へ移行し、それ以外の場合にはステップS300のNo、ステップS104へ移行し、他の通信経路を試す。これにより、スイッチ1aとサーバ3aとの間で多数の通信経路をとりうる場合においても、各通信経路を経由した死活確認を行うことができる。すなわち、本実施形態によると、多数の通信経路を持ちうるネットワークにも対応することができる。図10は、本実施形態に係るサーバ管理装置4の他の動作を示すフロー図である。図10を参照すると、本実施形態においても、第2の実施形態と同様に、待機系サーバ3bの活性化ステップS200を行うようにしてもよい。このとき、第2の実施形態のサービス提供システムと同様に、待機系サーバ3bにおいて、CPUの負荷を軽減することができる。実施形態4第4の実施形態に係るサーバ管理装置について、図面を参照して説明する。図11は、本実施形態に係るサーバ管理装置4の動作を示すフロー図である。本実施形態におけるサーバ管理装置4の動作は、死活確認パケットの応答が返ってきた場合にはステップS103のYesまたはステップS106のYes、ステップS400へ移行する点を除き、第1の実施形態のサーバ管理装置4の動作と同じである。サーバ管理装置4は、サービス稼働確認パケットを送信するステップS400。稼働確認パケットの応答が返ってきた場合にはステップS401のYes、ステップS108へ移行する。一方、稼働確認パケットの応答が返ってこなかった場合にはステップS401のNo、サーバ管理装置4は、稼働系サーバ3aにサービスの再起動を指示するステップS402。次に、サーバ管理装置4は、サービス稼働確認パケットを送信するステップS403。稼働確認パケットの応答が返ってきた場合にはステップS404のYes、ステップS108へ移行し、返ってこなかった場合にはステップS404のNo、ステップS107へ移行する。サーバ3aは、サービス再起動の指示を受けると、サービス構成DB21に記録されたサービスの停止処理を行った後に、サービスの開始時に行う処理を実行する。ステップS400,S403でのサービス稼働確認パケットとして、一例として、サービスが使用するポートにHELLOパケットを送るようにしてもよい。なお、ステップS401,S404では、システムに設定された期間内に、死活確認パケットの応答が返ってこなかった場合に応答がなかったとみなすようにしてもよい。本実施形態でのサービス活性化部20は、サーバ管理装置4からの指示により、指定されたサービスに対応するアプリケーションプログラムの停止を行う。このとき、サービス活性化部20は、サービス停止時に行う処理を記録したサービス構成DB21を使用する。サービス構成DB21は、サービスの識別子とサービス停止時に行う処理をセットで記録したデータベースである。サービス停止時に行う処理に関しては、シェルスクリプトに記述し、そのシェルスクリプトを起動するようにしてもよい。このようにすることで、サーバ3aは稼働しているものの、サービスを提供するアプリケーションが停止していた場合に、アプリケーションを再起動することでサービスを提供可能とすることができる。すなわち、アプリケーション障害に対応することが可能である。図12は、本実施形態に係るサーバ管理装置4の他の動作を示すフロー図である。図12を参照すると、本実施形態においても、第2の実施形態と同様に、待機系サーバ3bの活性化ステップS200を行うようにしてもよい。このとき、第2の実施形態のサービス提供システムと同様に、待機系サーバ3bにおいて、CPUの負荷を軽減することができる。実施形態5第5の実施形態に係るサーバ管理装置について、図面を参照して説明する。図13は、本実施形態に係るサーバ管理装置4の動作を示すフロー図である。本実施形態におけるサーバ管理装置4の動作は、稼働確認パケットの応答が返ってこなかった場合にはステップS404のNo、ステップS500へ移行する点を除き、第4の実施形態におけるサーバ管理装置4の動作図11と同じである。サーバ管理装置4は、スイッチ1aとサーバ3aとの通信経路を他の通信経路に変更するように経路制御装置2に指示するステップS500。次に、サーバ管理装置4は、サービス稼働確認パケットを送信するステップS501。稼働確認パケットの応答が返ってきた場合にはステップS502のYes、ステップS108へ移行し、返ってこなかった場合にはステップS502のNo、ステップS107へ移行する。このようにすることで、特定のサービスの通信が通らない通信経路があった場合にも対応することが可能となる。図14は、本実施形態に係るサーバ管理装置4の他の動作を示すフロー図である。図14を参照すると、本実施形態においても、第2の実施形態図8と同様に、待機系サーバ3bの活性化ステップS200を行うようにしてもよい。このとき、第2の実施形態のサービス提供システムと同様に、待機系サーバ3bにおいて、CPUの負荷を軽減することができる。図15は、本実施形態に係るサーバ管理装置4のさらに他の動作を示すフロー図である。図15を参照すると、本実施形態においても、第3の実施形態図9と同様に、応答がなかった場合にはステップS502のNoステップS500へ移行し、複数の通信経路を試みるようにしてもよい。このようにすることにより、スイッチ1aとサーバ3aとの間に多数の通信経路をとりうる場合において、特定のサービスの通信が通らない通信経路が存在するときにも対応することができる。本発明の全開示請求の範囲を含むの枠内において、さらにその基本的技術思想に基づいて、実施形態の変更調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。"