(57)【要約】【課題】リカバリの失敗を抑制することを課題とする。【解決手段】業務サーバは、第１の管理ネットワークを介して監視される、情報処理装置としての機能を発揮する第１の処理機能部で、第２の管理ネットワークを介して監視される第２の処理機能部をリカバリさせる場合、第２の処理機能部が第２の管理ネットワークで使用するネットワーク情報と、第１の管理ネットワークを介して監視される各処理機能部が使用するネットワーク情報との競合を検出する。業務サーバは、検出されたネットワーク情報の競合を解消して、第２の処理機能部を第１の処理機能部でリカバリする。【選択図】図１
2015106385.tif 000002
【特許請求の範囲】
【請求項１】
第１の管理ネットワークを介して監視される、情報処理装置としての機能を発揮する第１の処理機能部で、第２の管理ネットワークを介して監視される第２の処理機能部をリカバリさせる場合、前記第２の処理機能部が前記第２の管理ネットワークで使用するネットワーク情報と、前記第１の管理ネットワークを介して監視される各処理機能部が使用するネットワーク情報との競合を検出する検出部と、
前記検出部によって検出された前記ネットワーク情報の競合を解消して、前記第２の処理機能部を前記第１の処理機能部）でリカバリするリカバリ実行部）と
を有することを特徴とする情報処理装置。
【請求項２】
前記リカバリ実行部は、停止中の前記第１の処理機能部で前記第２の処理機能部をリカバリさせる場合、前記第１の管理ネットワークで使用される管理用のアドレスが競合する処理機能部のいずれかの前記管理用のアドレスを、競合しない管理用のアドレスに再設定して、前記第２の処理機能部をリカバリすることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記リカバリ実行部は、動作中の前記第１の処理機能部で前記第２の処理機能部をリカバリさせる場合、リカバリ先の前記第１の処理機能部に元々設定されている管理用のアドレスをリカバリ後の前記管理用のアドレスに設定して競合を解消し、前記第２の処理機能部の前記ネットワーク情報に含まれる業務用のアドレスを前記第１の処理機能部に設定し、前記第１の処理機能部内における前記業務用のアドレスの設定を有効にすることを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記第１の処理機能部は、第１のサーバ装置が有するパーティションであり、
前記第２の処理機能部は、前記第１のサーバ装置とは異なる第２のサーバ装置が有するパーティションであることを特徴とする請求項１に記載の情報処理装置。
【請求項５】
情報処理装置が、
第１の管理ネットワークを介して監視される、情報処理装置としての機能を発揮する第１の処理機能部で、第２の管理ネットワークを介して監視される第２の処理機能部をリカバリさせる場合、前記第２の処理機能部が前記第２の管理ネットワークで使用するネットワーク情報と、前記第１の管理ネットワークを介して監視される各処理機能部が使用するネットワーク情報との競合を検出し、
検出した前記ネットワーク情報の競合を解消して、前記第２の処理機能部を前記第１の処理機能部でリカバリする
処理を含んだことを特徴とするリカバリ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置およびリカバリ管理方法に関する。
【背景技術】
【０００２】
従来から、サーバ障害時にネットワークブートを使用して運用系サーバから待機系サーバにサーバ環境を引き継がせて、自動復旧させる技術がある。例えば、障害検出後にサーバ内のドライバやサーバ間を接続するネットワーク機器が、サーバ環境の引継ぎを実行する。なお、サーバ環境とは、ＩＰ（Internet  Protocol）アドレス、ＭＡＣ（Media  Access  Control）アドレスやＷＷＮ（World  Wide  Name）などである。
【０００３】
また、パーティション機能等を用いてサーバ内のリソースを分割して使用する場合でも、ネットワークブートを使用して、運用系パーティションを待機系パーティションで自動復旧することが行われている。
【０００４】
例えば、サーバＡがパーティションＡ１およびパーティションＡ２を有し、サーバＢがパーティションＢ１およびパーティションＢ２を有し、各サーバが業務ネットワークとは異なる管理ネットワークを用いて各パーティションを監視する例で説明する。このような状態でパーティションＡ１が故障した場合、管理装置は、他のパーティションにパーティションＡ１のサーバ環境を引き継がせて、パーティションＡ１を他のパーティションでリカバリする。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１７２６７８号公報
【特許文献２】特開２０１１−１８２５４号公報
【特許文献３】特開平０９−３２１７８９号公報
【特許文献４】特開２００８−２８４５６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記技術では、ネットワークブートによるリカバリが失敗してサービスが継続できないことがある。
【０００７】
具体的には、故障したパーティションの管理ネットワークとは異なる管理ネットワークを介して管理されるパーティションで、故障したパーティションをリカバリさせるとする。このとき、リカバリ先で管理用アドレスが競合してサーバ環境が移行できず、サービスが継続できない場合がある。
【０００８】
上記例では、パーティションＡ１をパーティションＢ２でリカバリする場合、パーティションＡ１の管理用アドレスと、リカバリ先のパーティションＢ２と同じ管理ネットワークに属するパーティションＢ１の管理用アドレスとが競合すると、リカバリが失敗する。
【０００９】
１つの側面では、リカバリの失敗を抑制できる情報処理装置およびリカバリ管理方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
第１の案では、情報処理装置は、第１の管理ネットワークを介して監視される、情報処理装置としての機能を発揮する第１の処理機能部で、第２の管理ネットワークを介して監視される第２の処理機能部をリカバリさせる場合、前記第２の処理機能部が前記第２の管理ネットワークで使用するネットワーク情報と、前記第１の管理ネットワークを介して監視される各処理機能部が使用するネットワーク情報との競合を検出する検出部を有する。情報処理装置は、前記検出部によって検出された前記ネットワーク情報の競合を解消して、前記第２の処理機能部を前記第１の処理機能部でリカバリするリカバリ実行部を有する。
【発明の効果】
【００１１】
１実施形態によれば、リカバリの失敗を抑制できる。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施例１に係るシステムの全体構成例を示す図である。
【図２】図２は、実施例１に係る業務サーバの機能構成を示す機能ブロック図である。
【図３】図３は、サーバ環境情報テーブルに記憶される情報の例を示す図である。
【図４】図４は、サーバ環境情報の競合検出を説明する図である。
【図５】図５は、サーバ環境情報テーブルの更新例を説明する図である。
【図６】図６は、実施例１に係るシステムが実行する処理の流れを示すフローチャートである。
【図７】図７は、実施例２に係る業務サーバの機能構成を示す機能ブロック図である。
【図８】図８は、筐体内外情報テーブルに記憶される情報の例を示す図である。
【図９】図９は、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブルに記憶される情報の例を示す図である。
【図１０】図１０は、ネットワーク情報テーブルに記憶される情報の例を示す図である。
【図１１】図１１は、ネットワーク変更の適用可否の判定例を説明する図である。
【図１２】図１２は、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブルの更新例を説明する図である。
【図１３】図１３は、実施例２に係るシステムが実行する処理の流れを示すフローチャートである。
【図１４】図１４は、業務サーバのハードウェア構成例を説明する図である。
【発明を実施するための形態】
【００１３】
以下に、本願の開示する情報処理装置およびリカバリ管理方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。なお、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。
【実施例１】
【００１４】
［全体構成図］
図１は、実施例１に係るシステムの全体構成例を示す図である。図１に示すように、このシステムは、業務サーバ１０と業務サーバ１１０とを有する。
【００１５】
業務サーバ１０は、パーティション２０とパーティション５０とサーバ管理部８０を有する。なお、各パーティションおよびサーバ管理部８０は、業務サーバ１０内の論理的なサーバでもよく、ブレードサーバのような物理的なサーバでもよい。
【００１６】
パーティション２０は、入出力を実行するＩ／Ｏ部３０と各種処理を実行する演算部４０とを有し、これらによってサービスを提供する。同様に、パーティション５０は、入出力を実行するＩ／Ｏ部６０と各種処理を実行する演算部７０とを有し、これらによって業務サービスを提供する。サーバ管理部８０は、業務サーバ１０内の各パーティションの監視やネットワークブートによるリカバリを実行する。
【００１７】
業務サーバ１１０は、パーティション１２０とパーティション１５０とサーバ管理部１８０を有する。なお、各パーティションおよびサーバ管理部１８０は、業務サーバ１１０内の論理的なサーバでもよく、ブレードサーバのように物理的なサーバでもよい。
【００１８】
パーティション１２０は、入出力を実行するＩ／Ｏ部１３０と各種処理を実行する演算部１４０とを有し、これらによってサービスを提供する。同様に、パーティション１５０は、入出力を実行するＩ／Ｏ部１６０と各種処理を実行する演算部１７０とを有し、これらによって業務サービスを提供する。サーバ管理部１８０は、業務サーバ１１０内の各パーティションの監視やネットワークブートによるリカバリを実行する。
【００１９】
また、サーバ管理部８０とサーバ管理部１８０とは、監視ＬＡＮ（Local  Area  Network）３を介して接続されて、監視状況や各パーティションの情報を共有する。
【００２０】
また、各パーティションの各Ｉ／Ｏ部は、ＮＩＣ（ネットワークインタフェースカード）とＦＣカード（ファイバチャネルカード）を有する。各パーティションの各ＮＩＣには、業務サービス用のＩＰアドレスとＭＡＣアドレスとが設定され、業務ＬＡＮ１に接続される。各パーティションの各ＦＣカードには、ＷＷＮが設定され、ＳＡＮ（Storage  Area  Network）２に接続される。
【００２１】
また、各パーティションの各演算部は、各パーティションの監視に使用される筐体内ＮＩＣを有する。各筐体内ＮＩＣには、管理用のＩＰアドレスとＭＡＣアドレスとが設定され、同一サーバ内のサーバ管理部に接続される。なお、ここで設定されるＭＡＣアドレスは、製造元によって設定されたＭＡＣアドレスをオペレーティングシステムが参照する仮想的なアドレスに変換した仮想ＭＡＣアドレスである。
【００２２】
本実施例では、パーティション２０の演算部４０の筐体内ＮＩＣには、ＩＰアドレスとして「10.18.13.11」、仮想的なＭＡＣアドレスとして「12-e2-00-03-11」が設定されている。また、パーティション５０の演算部７０の筐体内ＮＩＣには、ＩＰアドレスとして「10.18.13.12」、仮想的なＭＡＣアドレスとして「12-e2-00-03-12」が設定されている。同様に、パーティション１２０の演算部１４０の筐体内ＮＩＣには、ＩＰアドレスとして「10.18.13.11」、仮想的なＭＡＣアドレスとして「12-e2-00-03-11」が設定されている。また、パーティション１５０の演算部１７０の筐体内ＮＩＣには、ＩＰアドレスとして「10.18.13.12」、仮想的なＭＡＣアドレスとして「12-e2-00-03-12」が設定されている。なお、ここで示した数字等は例示であり、任意に変更することができる。
【００２３】
ここで、実施例１では、業務サーバ１１０のパーティション１２０およびパーティション１５０と、業務サーバ１０のパーティション２０とが動作しており、業務サーバ１０のパーティション５０が停止中であるとする。そして、業務サーバ１１０のパーティション１２０の待機系として業務サーバ１０のパーティション５０が設定されている。つまり、業務サーバ１１０のパーティション１２０と、業務サーバ１０のパーティション５０とには、同様のアプリケーション等がインストールされている。
【００２４】
この状態で、業務サーバ１１０のパーティション１２０が故障し、業務サーバ１１０のパーティション１２０を業務サーバ１０のパーティション５０で、ネットワークブートによってリカバリする例を想定する。
【００２５】
［業務サーバの機能構成］
図２は、実施例１に係る業務サーバの機能構成を示す機能ブロック図である。業務サーバ１０と業務サーバ１１０とは同様の構成を有するので、ここでは業務サーバ１０について説明する。
【００２６】
図２に示すように、業務サーバ１０は、パーティション２０とパーティション５０とサーバ管理部８０とを有する。なお、パーティション２０とパーティション５０とは同様の構成を有するので、ここではパーティション５０について説明する。
【００２７】
（パーティションの機能構成）
パーティション５０は、図２に示すように、Ｉ／Ｏ部６０と演算部７０とを有する。Ｉ／Ｏ部６０は、業務ＬＡＮ通信部６１とＳＡＮ通信部６２とを有し、これらによって業務サービスに関する情報の送受信等を実行する。
【００２８】
業務ＬＡＮ通信部６１は、業務ＬＡＮ１に接続される他の装置との間で通信を実行する処理部であり、例えばＮＩＣなどである。例えば、業務ＬＡＮ通信部６１は、業務サービスに関するパケットの送受信を実行する。
【００２９】
ＳＡＮ通信部６２は、ＳＡＮ２に接続されるストレージ装置との間で通信を実行する処理部であり、例えばＦＣカードなどである。例えば、ＳＡＮ通信部６２は、ストレージ装置へのデータ書き込みやストレージ装置からのデータ読み出しを実行する。
【００３０】
演算部７０は、パーティション５０全体の処理を司る処理部であり、例えばプロセッサまたは仮想プロセッサ、メモリなどを有する処理部である。この演算部７０は、筐体内通信部７１、故障検出部７２、サーバ停止部７３、ＮＷ切替依頼部７４、仮想アドレス切替部７５を有する。なお、故障検出部７２、サーバ停止部７３、ＮＷ切替依頼部７４、仮想アドレス切替部７５は、例えばプロセッサ等が実行するプロセスなどである。
【００３１】
筐体内通信部７１は、管理用のＩＰアドレスと仮想ＭＡＣアドレスとが設定されており、パーティション５０の監視に関する情報の送受信を実行する。具体的には、筐体内通信部７１は、サーバ管理部８０と接続され、リカバリの実行指示やサーバ環境などを受信する。また、筐体内通信部７１は、パーティション５０の故障通知やリカバリ指示などを、サーバ管理部８０に送信する。
【００３２】
故障検出部７２は、パーティション５０の故障を検出する処理部である。例えば、故障検出部７２は、監視ソフト等を用いて、パーティション５０の生死監視やパーティション５０で実行されるアプリケーションの監視を実行する。そして、故障検出部７２は、故障を検出した場合に、サーバ停止部７３に故障検出を通知するとともに、筐体内通信部７１を介して故障内容等をサーバ管理部８０に通知する。
【００３３】
サーバ停止部７３は、故障が検出されたパーティションを停止する処理部である。具体的には、サーバ停止部７３は、アプリケーション故障の場合、当該アプリケーションを停止し、パーティション５０の業務サーバとしての機能が故障した場合、当該機能を停止する。このとき、サーバ停止部７３は、監視ＬＡＮ３に接続する処理部等については停止を抑制する。また、サーバ停止部７３は、機能等を停止したことをＮＷ切替依頼部７４に通知するとともに、筐体内通信部７１を介してサーバ管理部８０に通知する。
【００３４】
ＮＷ切替依頼部７４は、故障によってパーティションが停止された場合に、ネットワークの切替をサーバ管理部８０に依頼する処理部である。具体的には、ＮＷ切替依頼部７４は、パーティション５０の故障が検出された場合に、待機系への切替をサーバ管理部８０に依頼する。つまり、ＮＷ切替依頼部７４は、ネットワークブートによるリカバリの実行を要求する。
【００３５】
仮想アドレス切替部７５は、リカバリされたパーティションのアドレス情報に切替える処理部である。具体的には、仮想アドレス切替部７５は、サーバ管理部８０から切替指示を受信した場合、リカバリ先のパーティションの管理用のアドレスを、リカバリ元のパーティションの管理用のアドレスに切替える。
【００３６】
例えば、仮想アドレス切替部７５は、リカバリ元のパーティション２０が使用する管理用のＩＰアドレスと仮想ＭＡＣアドレスとをサーバ管理部８０から取得して、筐体内通信部７１に設定する。また、仮想アドレス切替部７５は、リカバリ元のパーティション２０が使用する業務用のアドレス情報やＷＷＮをサーバ管理部８０等から取得して、業務ＬＡＮ通信部６１やＳＡＮ通信部６２に設定する。
【００３７】
（サーバ管理部の機能構成）
図２に示すように、サーバ管理部８０は、通信制御部８１、サーバ環境情報テーブル８２、送受信部８３、検出部８４、調整部８５、監視部８６、リカバリ実行部８７を有する。なお、各処理部は、例えばプロセッサが実行するプロセスや電子回路なである。
【００３８】
通信制御部８１は、監視ＬＡＮ３を介して他のサーバと接続する処理部である。具体的には、通信制御部８１は、業務サーバ１０が有する各パーティションの各筐体内通信部と接続され、業務サーバ１１０が有するサーバ管理部１８０と接続される。
【００３９】
例えば、通信制御部８１は、サーバ管理部１８０にリカバリ要求を送信し、サーバ管理部１８０からリカバリ要求を受信する。また、通信制御部８１は、各パーティションから故障通知等を受信し、リカバリ指示やアドレス情報の切替指示等を送信する。
【００４０】
サーバ環境情報テーブル８２は、システム内の各業務サーバに設定されている情報を記憶するテーブルであり、例えばメモリなどに格納される。図３は、サーバ環境情報テーブルに記憶される情報の例を示す図である。図３に示すように、サーバ環境情報テーブル８２は、各業務サーバの各パーティションに対応付けて「筐体内ＮＩＣ（ＩＰアドレス、仮想ＭＡＣアドレス）、Ｉ／Ｏ部（ＩＰアドレス、仮想ＭＡＣアドレス）、ネットワークブートリカバリ設定」を記憶する。なお、サーバ環境情報テーブル８２は、これら以外にもＷＷＮなどを対応付けて記憶することもできる。
【００４１】
ここで記憶される「筐体内ＮＩＣ（ＩＰアドレス）」は、筐体内ネットワークすなわち管理用ネットワークで使用される管理用のＩＰアドレスであり、パーティションの筐体内通信部に設定されるＩＰアドレスである。「筐体内ＮＩＣ（仮想ＭＡＣアドレス）」は、筐体内ネットワークすなわち管理用ネットワークで使用される管理用のＭＡＣアドレスであり、パーティションの筐体内通信部に設定される仮想的なＭＡＣアドレスである。パーティション内のオペレーティングシステムは、これらのＩＰアドレスと仮想ＭＡＣアドレスとを用いて、監視に関する情報を送受信する。
【００４２】
ここで記憶される「Ｉ／Ｏ部（ＩＰアドレス）」は、筐体外ネットワークすなわち業務用ネットワークで使用される業務用のＩＰアドレスであり、パーティションの業務ＬＡＮ通信部に設定されるＩＰアドレスである。「Ｉ／Ｏ部（仮想ＭＡＣアドレス）」は、筐体外ネットワークすなわち業務用ネットワークで使用される業務用のＭＡＣアドレスであり、パーティションの業務ＬＡＮ通信部に設定される仮想的なＭＡＣアドレスである。パーティション内のオペレーティングシステムは、これらのＩＰアドレスと仮想ＭＡＣアドレスとを用いて、業務に関する情報を送受信する。また、「ネットワークブートリカバリ設定」は、運用系と待機系とを示す情報を記憶する。
【００４３】
図３の例では、業務サーバ１０のパーティション５０の筐体内通信部７１にはＩＰアドレス「10.18.13.12」、仮想ＭＡＣアドレス「12-e2-00-03-12」が設定されている。また、業務サーバ１０のパーティション５０の業務ＬＡＮ通信部６１にはＩＰアドレス「10.18.26.22」と仮想ＭＡＣアドレス「12-e2-00-04-22」が設定されている。また、業務サーバ１１０のパーティション１２０が運用系であり、業務サーバ１０のパーティション５０が待機系に設定されている。
【００４４】
また、図３に示すように、異なる業務サーバ間、つまりサーバ管理部の管理対象が異なる業務サーバ間では、重複した管理アドレスが設定されているが、サーバ管理部と業務サーバ間の通信にしか使用されないので、重複によるエラーは発生しない。ところが、業務アドレスについては、各業務サーバが同じ業務ＬＡＮ１に接続されることから、一意なアドレスが設定される。
【００４５】
送受信部８３は、各サーバ管理部間でサーバ環境を送受信する処理部である。具体的には、送受信部８３は、業務サーバ１０の各パーティションに対して、管理用のアドレスや業務用のアドレス等が設定されると、設定された情報を同システム内のサーバ管理部１８０に送信する。また、送受信部８３は、サーバ管理部１８０から、業務サーバ１１０の各パーティションに設定された各アドレス情報を受信する。
【００４６】
そして、送受信部８３は、送受信した情報を用いて、サーバ環境情報テーブル８２を生成する。このとき、送受信部８３は、管理者等から運用系と待機系の情報を受信して、サーバ環境情報テーブル８２に格納する。
【００４７】
検出部８４は、リカバリ後のサーバ環境から管理アドレスの重複を検出する処理部である。具体的には、検出部８４は、停止中のパーティション５０で、故障した業務サーバ１１０のパーティション１２０をリカバリさせる場合、リカバリ先の業務サーバ１０内でリカバリ後に発生する管理アドレスの競合を検出する。
【００４８】
ここで、競合検出の処理手順の具体例を説明する。図４は、サーバ環境情報の競合検出を説明する図である。図４に示すように、まず、検出部８４は、サーバ環境情報テーブル８２に設定されたネットワークブートリカバリ設定の有無を参照する（処理１）。ここで、検出部８４は、業務サーバ１１０のパーティション１２０の待機系が業務サーバ１０のパーティション５０であることを特定する。
【００４９】
次に、検出部８４は、ネットワークリカバリ後に管理アドレスの設定を想定する（処理２）。ここでは、検出部８４は、リカバリ元のパーティション１２０の管理アドレス「10.18.13.11、12-e2-00-03-11」を、リカバリ先のパーティション５０に設定すると想定する。
【００５０】
その後、検出部８４は、リカバリ先の業務サーバ１０内で管理アドレスが重複するか否かを判定する（処理３）。図４の場合、検出部８４は、リカバリ後に想定される管理アドレスがパーティション２０とパーティション５０とで競合すると検出する。したがって、検出部８４は、管理アドレスが競合することを調整部８５に通知する。このとき、検出部８４は、管理アドレスが競合しない場合には、競合なしを調整部８５に通知する。
【００５１】
調整部８５は、検出部８４によって検出された管理アドレスの競合を解消する処理部である。具体的には、調整部８５は、競合すると検出されたいずれかのパーティションのアドレス情報を、競合しないアドレスに書換える。例えば、調整部８５は、サーバ環境情報テーブル８２において、管理アドレスが競合するパーティションのうち、リカバリ先ではないパーティションの管理アドレスを別のアドレスに書換える。
【００５２】
図５は、サーバ環境情報テーブルの更新例を説明する図である。図５に示すように、調整部８５は、管理アドレスが競合する業務サーバ１０のパーティション２０とパーティション５０のうち、リカバリ先ではないパーティション２０の管理アドレス「10.18.13.11、12-e2-00-03-11」を「10.18.13.13、12-e2-00-03-13」に書換える。このようにすることで、実際にリカバリが発生した場合であっても、管理アドレスの競合を抑制でき、ネットワークブートによるリカバリの失敗を抑制できる。
【００５３】
また、ここでは、リカバリ発生前に、管理アドレスが競合するパーティションのうち、リカバリ先ではないパーティションの管理アドレスを別のアドレスに書換える例を説明したが、他の方法で競合を解消することもできる。例えば、調整部８５は、リカバリが発生した場合に、リカバリ先のパーティション５０の管理アドレスを「10.18.13.11、12-e2-00-03-11」から「10.18.13.13、12-e2-00-03-13」に書換えてリカバリすると予約しておくこともできる。この場合、調整部８５は、実際にリカバリが行われる際に、管理アドレスの書換えを実行する。
【００５４】
監視部８６は、監視対象である各パーティションからの故障通知や正常通知を受信する処理部である。例えば、監視部８６は、業務サーバ１０のパーティション２０やパーティション５０から故障通知や正常通知を受信し、各パーティションの状態を管理する。そして、監視部８６は、パーティションの故障通知を受信した場合、リカバリ実行部８７にリカバリを要求する。
【００５５】
リカバリ実行部８７は、監視部８６によってパーティションの故障が検出された場合、サーバ管理部１８０にリカバリを要求する処理部である。また、リカバリ実行部８７は、サーバ管理部１８０からリカバリ要求を受信した場合、サーバ環境情報テーブル８２にしたがってリカバリを実行する処理部である。
【００５６】
例えば、リカバリ実行部８７は、パーティション２０が故障した場合には、パーティション２０を示す情報とともに、リカバリ要求をサーバ管理部１８０に送信して、パーティション２０のリカバリを要求する。なお、リカバリ実行部８７は、パーティション２０が故障した場合に業務サーバ１０内にリカバリ先が指定されていると、指定されているパーティションでリカバリを実行する。
【００５７】
また、リカバリ実行部８７は、業務サーバ１１０のパーティション１２０を示す情報とともにリカバリ要求をサーバ管理部１８０から受信した場合、サーバ環境情報テーブル８２を参照して、リカバリ先がパーティション５０であることを特定する。そして、リカバリ実行部８７は、筐体内通信部７１に設定する管理用アドレス、Ｉ／Ｏ部６０の各通信部に設定する業務用アドレス、ＷＷＮなどをサーバ環境情報テーブル８２から取得して、パーティション５０に通知する。その後、リカバリ実行部８７は、アドレス情報等の設定が完了した通知をパーティション５０から受信すると、リカバリさせたパーティション５０すなわち待機系サーバを起動させる。
【００５８】
［処理の流れ］
図６は、実施例１に係るシステムが実行する処理の流れを示すフローチャートである。図６に示すように、リカバリ先のサーバ管理部８０は、各業務サーバの各パーティションについてサーバ環境の設定が完了すると（Ｓ１０１：Ｙｅｓ）、Ｓ１０２を実行する。
【００５９】
すると、各サーバ管理部が、設定されたサーバ環境をやり取りし、リカバリ先となるサーバ管理部８０の検出部８４が、管理アドレスの競合を判定する（Ｓ１０２）。ここで、サーバ管理部８０は、生成したサーバ環境情報テーブル８２を参照することで、自装置がリカバリ先側と判定できる。
【００６０】
そして、リカバリ先のサーバ管理部８０は、競合があると判定すると（Ｓ１０３：Ｙｅｓ）、競合しないアドレスを再設定してサーバ環境情報テーブル８２を書換えて（Ｓ１０４）、Ｓ１０２に戻る。一方、リカバリ先のサーバ管理部８０は、競合がないと判定すると（Ｓ１０３：Ｎｏ）、Ｓ１０５の処理を実行する。
【００６１】
その後、サーバ管理部１８０がパーティション１２０の故障を検出すると（Ｓ１０５：Ｙｅｓ）、パーティション１２０は、パーティション１２０すなわち業務サーバを停止する（Ｓ１０６）。例えば、パーティション１２０は、業務サーバとして機能させるアプリケーション等を停止する。
【００６２】
続いて、故障したパーティション１２０が、サーバ管理部１８０に対してネットワークの切替を指示し、サーバ管理部１８０が、ネットワークをリカバリ先に切替える（Ｓ１０７）。このとき、サーバ管理部１８０は、リカバリ要求をサーバ管理部８０に送信する。
【００６３】
そして、サーバ管理部８０のリカバリ実行部８７が、サーバ環境情報テーブル８２に従って、設定対象である管理アドレス等のサーバ環境をリカバリ先のパーティション５０に通知し、仮想アドレス切替部７５が、各アドレス等を設定する（Ｓ１０８）。その後、サーバ管理部８０のリカバリ実行部８７は、パーティション５０すなわち待機系サーバを起動させる（Ｓ１０９）。例えば、パーティション５０の演算部７０は、サーバ管理部８０の指示にしたがって、業務サーバとして機能させるアプリケーション等を起動する。
【００６４】
［効果］
このように、リカバリ先となるサーバ管理部８０は、リカバリ発生前に、リカバリ後のサーバ環境を想定し、管理アドレスの重複が発生する場合には、事前に管理アドレスを再設定しておくことで、事前に不整合の発生を抑制できる。したがって、実際にネットワークブートによるリカバリが発生した場合に通常通り処理しても、エラーなくリカバリを完了させることができる。
【００６５】
また、同一業務サーバ内に待機系を用意しなくても、同一サブネット内の筐体で１つの待機系を用意することで、ネットワークブートによるリカバリを実現できる。同一業務サーバ内でネットワークブートによるリカバリを実行する場合と比較すると、待機系としてスタンバイさせておく台数が少なくて済む。
【実施例２】
【００６６】
ところで、実施例１では、リカバリ先が停止中である場合の例を説明したが、これに限定されるものではなく、リカバリ先が動作中であっても、エラーなくリカバリを完了させることができる。
【００６７】
そこで、実施例２では、リカバリ先が動作中の場合に、ネットワークブートによるリカバリを実行する例を説明する。実施例２が想定する全体構成図は、実施例１と同様とする。また、実施例２では、業務サーバ１１０のパーティション１２０およびパーティション１５０と、業務サーバ１０のパーティション２０およびパーティション５０が動作しているとする。そして、業務サーバ１１０のパーティション１２０の待機系として業務サーバ１０のパーティション５０が設定されている。
【００６８】
この状態で、業務サーバ１１０のパーティション１２０が故障し、業務サーバ１１０のパーティション１２０を業務サーバ１０のパーティション５０で、ネットワークブートによってリカバリする例を想定する。
【００６９】
［業務サーバの機能構成］
図７は、実施例２に係る業務サーバの機能構成を示す機能ブロック図である。業務サーバ１０と業務サーバ１１０とは同様の構成を有するので、ここでは業務サーバ１０について説明する。また、実施例１と同様の機能を有する処理部等については、図２と同様の符号をつけたので、それらの詳細な説明は省略する。
【００７０】
ここでは、実施例１とは異なる機能を有するパーティション５０の演算部７０について説明する。なお、演算部７０の筐体内通信部７１、故障検出部７２、サーバ停止部７３は、実施例１と同様の機能を実行するので、それらの詳細な説明は省略する。
【００７１】
実施例１と異なる機能として、演算部７０は、筐体内外情報テーブル７０ａ、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂ、ネットワーク情報テーブル７０ｃ、適用判定部７６、テーブル更新部７７を有する。
【００７２】
筐体内外情報テーブル７０ａは、デバイスが筐体内ネットワークか筐体外ネットワークのいずれに属するかを示す情報を記憶するテーブルである。つまり、筐体内外情報テーブル７０ａは、パーティション５０内の各デバイスが管理用か業務用かを示す情報を記憶する。
【００７３】
図８は、筐体内外情報テーブルに記憶される情報の例を示す図である。図８に示すように、筐体内外情報テーブル７０ａは、「筐体内ネットワーク、筐体外ネットワーク」を記憶する。ここで、「筐体内ネットワーク」は、管理用の監視ＬＡＮ３に接続される、管理用のデバイスを示す。「筐体外ネットワーク」は、業務用の業務ＬＡＮ１またはＳＡＮ２に接続される、業務用のデバイスを示す。
【００７４】
図８の例では、「Ｂｕｓ／Ｄｅｖ／Ｆｕｎｃ」が「０／７／０」、「０／８／０」、「０／９／０」のデバイスは管理用であることを示す。また、「Ｂｕｓ／Ｄｅｖ／Ｆｕｎｃ」が「５／０／０」、「５／１／０」、「１０／０／０」などのデバイスは業務用であることを示す。ここで「Ｂｕｓ／Ｄｅｖ／Ｆｕｎｃ」は、ＰＣＩＥｘｐｒｅｓｓにおいてデバイスを特定するアドレス表記の例であり、「Ｂｕｓ」はバス番号、「Ｄｅｖ」はデバイス番号、「Ｆｕｎｃ」はファンクション番号を示す。
【００７５】
Ｂｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂは、パーティション内のオペレーティングシステムが参照するアドレス情報を記憶するテーブルである。つまり、オペレーティングシステムは、このテーブルに記憶されるアドレス情報を用いて、データの送受信を実行する。
【００７６】
図９は、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブルに記憶される情報の例を示す図である。図９では、一例として、業務サーバ１０のパーティション５０に対応するテーブルを図示したが、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂは、パーティションごとに情報を記憶する。
【００７７】
図９に示すように、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂは、業務サーバ１０のパーティション５０の情報として、「ＩＰアドレス」と「仮想ＭＡＣアドレス」とを対応付けて記憶する。ここで記憶される「ＩＰアドレス」は、パーティション５０のオペレーティングシステムが参照するＩＰアドレスであり、「仮想ＭＡＣアドレス」は、パーティション５０のオペレーティングシステムが参照する仮想的なＭＡＣアドレスである。なお、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂは、これら以外にもＷＷＮを記憶することもできる。
【００７８】
図９の例では、パーティション５０のオペレーティングシステムは、「ＩＰアドレス、仮想ＭＡＣアドレス」として「10.18.13.12、12-e2-00-03-12」を参照する。これは、パーティション５０の演算部７０の筐体内通信部７１に設定される情報であり、管理用のアドレス情報である。また、パーティション５０のオペレーティングシステムは、「ＩＰアドレス、仮想ＭＡＣアドレス」として「10.18.26.22、12-e2-00-04-22」を参照する。これは、パーティション５０のＩ／Ｏ部６０に設定される情報であり、業務用のアドレス情報である。
【００７９】
ネットワーク情報テーブル７０ｃは、パーティション５０が有するデバイスおよびデバイスが接続されるネットワークに関する情報を記憶するテーブルである。図１０は、ネットワーク情報テーブルに記憶される情報の例を示す図である。
【００８０】
ネットワーク情報テーブル７０ｃは、「Ｂｕｓ／Ｄｅｖ／Ｆｕｎｃ、種別、ＩＰアドレス、仮想ＭＡＣアドレス、仮想ＷＷＮ」を対応付けて記憶する。「Ｂｕｓ／Ｄｅｖ／Ｆｕｎｃ」は、デバイスを特定する情報であり、「種別」は、デバイスの種別を示す情報である。「ＩＰアドレス」は、デバイスに設定されているＩＰアドレスであり、「仮想ＭＡＣアドレス」は、オペレーティングシステムが当該デバイスのＭＡＣアドレスとして認識する仮想的なＭＡＣアドレスである。「仮想ＷＷＮ」は、オペレーティングシステムが当該デバイスのＷＷＮとして認識する仮想的なＷＷＮである。
【００８１】
図１０の例では、ネットワーク情報テーブル７０ｃは、「0/7/0、ＬＡＮ、10.18.13.12、12-e2-00-03-12、−」、「8/0/0、ＬＡＮ、10.18.26.22、12-e2-00-04-22、−」、「9/0/0、ＦＣ、−、−、10：00：00：a0：98：00：00：22」を記憶する。
【００８２】
つまり、デバイス「0/7/0」は、ＬＡＮに接続されるデバイスであり、ＩＰアドレス「10.18.13.12」と仮想ＭＡＣアドレス「12-e2-00-03-12」が設定されている。また、デバイス「8/0/0」は、ＬＡＮに接続されるデバイスであり、ＩＰアドレス「10.18.26.22」と仮想ＭＡＣアドレス「12-e2-00-04-22」が設定されている。また、デバイス「9/0/0」は、ＳＡＮに接続されるデバイスであり、ＷＷＮ「10：00：00：a0：98：00：00：22」が設定されている。
【００８３】
適用判定部７６は、リカバリに伴う管理アドレスの変更適否を判定する処理部である。具体的には、適用判定部７６は、リカバリ時に管理アドレスの変更が発生するかを判定し、発生する場合に当該変更の適否を判定する。そして、適用判定部７６は、管理アドレスの変更が発生する場合、故障したパーティションに設定される管理アドレスではなく、リカバリ先のパーティションに元々設定された管理アドレスを、リカバリ後に使用することを決定する。
【００８４】
ここで、適用判定部７６による適用判定について、パーティション５０を例にして説明する。図１１は、ネットワーク変更の適用可否の判定例を説明する図である。図１１に示すように、適用判定部７６は、図１０に示したネットワーク情報テーブル７０ｃと図８に示した筐体内外情報テーブル７０ａとから、各デバイスが管理用（筐体内）ネットワークか業務用（筐体外）ネットワークのいずれに接続されるかを判定する（図１１の１１Ａ）。
【００８５】
ここでは、適用判定部７６は、デバイス「0/7/0」については管理用の筐体内ネットワークに接続されるデバイスであると判定する。つまり、デバイス「0/7/0」は、筐体内通信部７１に該当する。また、適用判定部７６は、デバイス「8/0/0」と「9/0/0」については業務用の筐体外ネットワークに接続されるデバイスであると判定する。つまり、デバイス「8/0/0」は、業務ＬＡＮ通信部６１に該当し、デバイス「9/0/0」は、ＳＡＮ通信部６２に該当する。
【００８６】
そして、適用判定部７６は、仮想アドレス切替部７５から切替対象のネットワーク情報を取得する（図１１の１１Ｂ）。具体的には、適用判定部７６は、「Ｂｕｓ／Ｄｅｖ／Ｆｕｎｃ、種別、ＩＰアドレス、仮想ＭＡＣアドレス、仮想ＷＷＮ」を対応付けた情報を取得する。ここでは、適用判定部７６は、「0/7/0、ＬＡＮ、10.18.13.11、12-e2-00-03-11、−」、「8/0/0、ＬＡＮ、10.18.23.11、12-e2-00-04-11、−」、「9/0/0、ＦＣ、−、−、10：00：00：a0：98：00：00：11」を取得する。
【００８７】
その後、適用判定部７６は、図１１の１１Ａに示すリカバリ先の現在のネットワーク情報と、図１１の１１Ｂに示すリカバリ元のネットワーク情報とを比較し、管理用アドレスの変更が発生するかを判定する（図１１の１１Ｃ）。この例では、適用判定部７６は、図１１の１１Ａに示す筐体内ネットワークと判定されたデバイス「0/7/0」のアドレスと、図１１の１１Ｂにおいてデバイス「0/7/0」に対応するアドレスとが異なっていることから、管理用アドレスの変更が発生すると判定する。
【００８８】
この結果、適用判定部７６は、リカバリにおいて、筐体内ネットワークで使用する管理アドレスの変更を拒否し、筐体外ネットワークで使用する業務アドレスの変更を許容すると判定する（図１１の１１Ｄ）。
【００８９】
具体的には、適用判定部７６は、リカバリにおいて管理アドレスの変更が仮想アドレス切替部７５より要求されているが、リカバリ前後で管理アドレスを変更することになり、競合が発生する危険があると判定する。したがって、適用判定部７６は、管理アドレスについては、リカバリ元であるパーティション１２０の管理アドレスを反映しないと判定する。一方、適用判定部７６は、リカバリ後はリカバリ元のパーティション１２０の業務を実行するので、業務アドレスは変更すると判定する。したがって、適用判定部７６は、業務アドレスについては、リカバリ元であるパーティション１２０の業務アドレスを反映すると判定する。
【００９０】
これらの結果を踏まえて、適用判定部７６は、仮想アドレス切替部７５に対して、管理アドレスの変更を拒否し、業務アドレスの変更を許容する指示を送信する。また、適用判定部７６は、テーブル更新部７７に対して、反映対象の業務アドレスを送信して、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂの更新を指示する。ここでは、適用判定部７６は、「8/0/0、ＬＡＮ、10.18.23.11、12-e2-00-04-11、−」をテーブル更新部７７に送信する。その後、仮想アドレス切替部７５は、管理アドレスの再設定を抑制し、業務アドレスとＷＷＮの設定を実行する。
【００９１】
テーブル更新部７７は、リカバリにともなって、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂの更新を実行する処理部である。具体的には、テーブル更新部７７は、適用判定部７６から受信した「8/0/0、ＬＡＮ、10.18.23.11、12-e2-00-04-11、−」をＢｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂに追加する。
【００９２】
図１２は、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブルの更新例を説明する図である。図１２に示すように、テーブル更新部７７は、「ＩＰアドレス、仮想ＭＡＣアドレス」として「10.18.13.12、12-e2-00-03-12」と「10.18.26.22、12-e2-00-04-22」が記憶される状況で、「10.18.23.11、12-e2-00-04-11」を受信する。すると、テーブル更新部７７は、Ｂｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂに、「10.18.23.11、12-e2-00-04-11」に対応する新たなレコードを追加する。この結果、パーティション５０のオペレーティングシステムは、リカバリ後に、リカバリされたパーティション１２０の業務アドレスを正確に認識することができ、通信断を発生させずに業務に関する通信等を実行できる。
【００９３】
［処理の流れ］
図１３は、実施例２に係るシステムが実行する処理の流れを示すフローチャートである。図１３に示すように、サーバ管理部１８０がパーティション１２０の故障を検出すると（Ｓ２０１：Ｙｅｓ）、パーティション１２０は、パーティション１２０すなわち業務サーバを停止する（Ｓ２０２）。
【００９４】
続いて、故障したパーティション１２０が、サーバ管理部１８０に対してネットワークの切替を指示し、サーバ管理部１８０が、ネットワークをリカバリ先に切り替える（Ｓ２０３）。このとき、サーバ管理部１８０は、リカバリ要求をサーバ管理部８０に送信する。
【００９５】
そして、サーバ管理部８０のリカバリ実行部８７が、サーバ環境情報テーブル８２に従って、設定対象である管理アドレス等のサーバ環境をリカバリ先のパーティション５０に通知し、仮想アドレス切替部７５が、各アドレス等を仮設定する（Ｓ２０４）。続いて、サーバ管理部８０のリカバリ実行部８７は、リカバリ対象のサーバ環境が設定された待機系サーバを起動させる（Ｓ２０５）。一例としては、リカバリ実行部８７は、待機系サーバにリカバリ対象のサーバ環境が設定した後、当該待機系サーバを再起動させる。
【００９６】
その後、リカバリ先のパーティション５０の適用判定部７６は、筐体内ネットワークすなわち管理アドレスの変更があるかを判定する（Ｓ２０６）。
【００９７】
ここで、適用判定部７６は、変更がないと判定した場合（Ｓ２０７：Ｎｏ）、リカバリ元の管理アドレスをそのまま設定することを許容する（Ｓ２０８）。つまり、仮想アドレス切替部７５は、Ｓ２０４で仮設定した状態を適用し、正式に設定を完了する。
【００９８】
一方、適用判定部７６は、変更があると判定した場合（Ｓ２０７：Ｙｅｓ）、筐体内ネットワークの変更を取り消す（Ｓ２０９）。つまり、適用判定部７６は、仮想アドレス切替部７５に対して、仮設定した管理アドレスの再設定を指示する。
【００９９】
そして、仮想アドレス切替部７５は、Ｓ２０４で仮設定したリカバリ元であるパーティション１２０の管理アドレスを破棄し、リカバリ先であるパーティション５０に元々設定されていた管理アドレスを再設定する（Ｓ２１０）。
【０１００】
Ｓ２０８またはＳ２１０を処理した後、仮想アドレス切替部７５は、設定対象である業務アドレス等のサーバ環境をリカバリ先のパーティション５０に設定する（Ｓ２１１）。そして、テーブル更新部７７は、パーティション５０に設定されたサーバ環境を有効にするために、設定されたサーバ環境でＢｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂを更新する（Ｓ２１２）。
【０１０１】
［効果］
このように、サーバ管理部８０は、リカバリ先のパーティションが動作中であっても、リカバリ元のパーティションを正確にリカバリすることができる。したがって、停止中の待機系を用意しなくても、運用しているパーティションでリカバリすることができるので、効率的なサーバ運用を実現できる。また、リカバリ先のパーティションは、単純にアドレス情報を設定するだけでなく、オペレーティングシステムが参照できるようにＢｉｎｄ  ＩＰ−ＭＡＣテーブル７０ｂを更新することもできる。このため、リカバリ完了後に設定ミス等による通信断の発生を抑制できる。
【実施例３】
【０１０２】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【０１０３】
（リカバリ対象）
上記実施例では、パーティション１２０をパーティション５０でリカバリする例を説明したが、リカバリ対象をパーティションに限定するものではない。例えば、物理サーバをパーティションでリカバリすることもでき、パーティションを物理サーバでリカバリすることもでき、仮想マシン等を用いてリカバリすることもできる。
【０１０４】
（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１０５】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１０６】
（業務サーバの構成）
本実施例で開示する業務サーバの構成例を図１４に示す。図１４は、業務サーバのハードウェア構成例を説明する図である。図１４に示すように、各業務サーバは、バックプレーン１００に複数の切換装置としてのクロスバとしてＸＢ１０１、ＸＢ１０２などを有し、クロスバそれぞれにシステムボードとしてＳＢ１１０〜ＳＢ１１３と入出力システムボードとしてＩＯＳＢ１５０とを有する。なお、クロスバ、システムボード、入出力システムボードの数はあくまで例示であり、これに限定されるものではない。
【０１０７】
バックプレーン１００は、複数のコネクタ等を相互接続するバスを形成する回路基板である。ＸＢ１０１、ＸＢ１０２は、システムボードと入出力システムボードとの間でやり取りされるデータの経路を動的に選択するスイッチである。
【０１０８】
また、ＸＢ１０１に接続されるＳＢ１１０、ＳＢ１１１、ＳＢ１１２、ＳＢ１１３は、電子機器を構成する電子回路基板であり同様の構成を有するので、ここではＳＢ１１０についてのみ説明する。なお、各ＳＢは、例えば各パーティションやサーバ管理部に該当する。また、ＳＢ１１０は、システムコントローラ（System  Controller：SC）１１０ａと、４台のＣＰＵ１１０ｂ〜１１０ｅと、メモリアクセスコントローラ（Memory  Access  Controller：MAC）１１０ｈおよび１１０ｉと、ＤＩＭＭ（Dual  Inline  Memory  Module）１１０ｆおよび１１０ｇとを有する。
【０１０９】
ＳＣ１１０ａは、ＳＢ１１０に搭載されるＣＰＵ１１０ｂ〜１１０ｅとＭＡＣ１１０ｈ、ＭＡＣ１１０ｉとの間におけるデータ転送などの処理を制御し、ＳＢ１１０全体を制御する。
【０１１０】
ＣＰＵ１１０ｂ〜１１０ｅそれぞれは、ＳＣ１１０ａを介して他のＬＳＩと接続され、本実施の形態で開示したリカバリ制御方法を実現するプロセッサである。例えば、各ＣＰＵは、演算部やサーバ管理部等で実行される各種処理を実行する。
【０１１１】
ＭＡＣ１１０ｈは、ＤＩＭＭ１１０ｆとＳＣ１１０ａとの間に接続され、ＤＩＭＭ１１０ｆへのアクセスを制御する。ＭＡＣ１１０ｉは、ＤＩＭＭ１１０ｇとＳＣ１１０ａとの間に接続され、ＤＩＭＭ１１０ｇへのアクセスを制御する。ＤＩＭＭ１１０ｆは、ＳＣ１１０ａを介して他の電子機器と接続され、メモリを装着してメモリ増設などを行うメモリモジュールである。ＤＩＭＭ１１０ｇは、ＳＣ１１０ａを介して他の電子機器と接続され、メモリを装着してメモリ増設などを行う主記憶装置（メインメモリ）としてのメモリモジュールである。
【０１１２】
ＩＯＳＢ１５０は、ＸＢ１０１を介してＳＢ１１０〜ＳＢ１１３それぞれと接続されるとともに、ＳＣＳＩ（Small  Computer  System  Interface）、ＦＣ（Fibre  Channel）、イーサネット（登録商標）などを介して入出力デバイスと接続される。ＩＯＳＢ１５０は、入出力デバイスとＸＢ１０１との間におけるデータ転送などの処理を制御する。なお、ＳＢ１１０に搭載されるＣＰＵ、ＭＡＣ、ＤＩＭＭなどの電子機器はあくまで例示であり、電子機器の種類又は電子機器の数が図示したものに限定されるものではない。
【符号の説明】
【０１１３】
１０、１１０  業務サーバ
２０、５０、１２０、１５０  パーティション
３０、６０、１３０、１６０  Ｉ／Ｏ部
３１、６１  業務ＬＡＮ通信部
３２、６２  ＳＡＮ通信部
４０、７０、１４０、１７０  演算部
７０ａ  筐体内外情報テーブル
７０ｂ  Ｂｉｎｄ  ＩＰ−ＭＡＣテーブル
７０ｃ  ネットワーク情報テーブル
４１、７１  筐体内通信部
４２、７２  故障検出部
４３、７３  サーバ停止部
４４、７４  ＮＷ切替依頼部
４５、７５  仮想アドレス切替部
７６  適用判定部
７７  テーブル更新部
８０、１８０  サーバ管理部
８１  通信制御部
８２  サーバ環境情報テーブル
８３  送受信部
８４  検出部
８５  調整部
８６  監視部
８７  リカバリ実行部
【図１】
2015106385.tif 000003
【図２】
2015106385.tif 000004
【図３】
2015106385.tif 000005
【図４】
2015106385.tif 000006
【図５】
2015106385.tif 000007
【図６】
2015106385.tif 000008
【図７】
2015106385.tif 000009
【図８】
2015106385.tif 000010
【図９】
2015106385.tif 000011
【図１０】
2015106385.tif 000012
【図１１】
2015106385.tif 000013
【図１２】
2015106385.tif 000014
【図１３】
2015106385.tif 000015
【図１４】
2015106385.tif 000016