JP6217358B2 - 情報処理装置およびリカバリ管理方法 - Google Patents

情報処理装置およびリカバリ管理方法 Download PDF

Info

Publication number
JP6217358B2
JP6217358B2 JP2013249632A JP2013249632A JP6217358B2 JP 6217358 B2 JP6217358 B2 JP 6217358B2 JP 2013249632 A JP2013249632 A JP 2013249632A JP 2013249632 A JP2013249632 A JP 2013249632A JP 6217358 B2 JP6217358 B2 JP 6217358B2
Authority
JP
Japan
Prior art keywords
function unit
processing function
unit
address information
recovery
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013249632A
Other languages
English (en)
Other versions
JP2015106385A (ja
Inventor
郁朗 藤原
郁朗 藤原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2013249632A priority Critical patent/JP6217358B2/ja
Priority to US14/549,998 priority patent/US20150154083A1/en
Publication of JP2015106385A publication Critical patent/JP2015106385A/ja
Application granted granted Critical
Publication of JP6217358B2 publication Critical patent/JP6217358B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H04L41/0661—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities by reconfiguring faulty entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2025—Failover techniques using centralised failover control functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage

Description

本発明は、情報処理装置およびリカバリ管理方法に関する。
従来から、サーバ障害時にネットワークブートを使用して運用系サーバから待機系サーバにサーバ環境を引き継がせて、自動復旧させる技術がある。例えば、障害検出後にサーバ内のドライバやサーバ間を接続するネットワーク機器が、サーバ環境の引継ぎを実行する。なお、サーバ環境とは、ＩＰ（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）、イーサネット（登録商標）などを介して入出力デバイスと接続される。ＩＯＳＢ１５０は、入出力デバイスとＸＢ１０１との間におけるデータ転送などの処理を制御する。なお、ＳＢ１１０に搭載されるＣＰＵ、ＭＡＣ、ＤＩＭＭなどの電子機器はあくまで例示であり、電子機器の種類又は電子機器の数が図示したものに限定されるものではない。
１０、１１０ 業務サーバ
２０、５０、１２０、１５０ パーティション
３０、６０、１３０、１６０ Ｉ／Ｏ部
３１、６１ 業務ＬＡＮ通信部
３２、６２ ＳＡＮ通信部
４０、７０、１４０、１７０ 演算部
７０ａ 筐体内外情報テーブル
７０ｂ Ｂｉｎｄ ＩＰ−ＭＡＣテーブル
７０ｃ ネットワーク情報テーブル
４１、７１ 筐体内通信部
４２、７２ 故障検出部
４３、７３ サーバ停止部
４４、７４ ＮＷ切替依頼部
４５、７５ 仮想アドレス切替部
７６ 適用判定部
７７ テーブル更新部
８０、１８０ サーバ管理部
８１ 通信制御部
８２ サーバ環境情報テーブル
８３ 送受信部
８４ 検出部
８５ 調整部
８６ 監視部
８７ リカバリ実行部

Claims (7)

  1. 情報処理装置としての機能を発揮する処理機能部ごとに、当該処理機能部が使用する各デバイスに割当てられるアドレス情報と、各デバイスが接続されるネットワークが筐体内ネットワークか筐体外ネットワークかを示すネットワーク情報とを対応付けて記憶する記憶部と、
    第１の管理ネットワークを介して監視される、前記情報処理装置としての機能を発揮する第１の処理機能部で、第２の管理ネットワークを介して監視される第２の処理機能部をリカバリさせる場合、前記記憶部を参照して、前記第２の処理機能部が筐体内ネットワークで使用する筐体内アドレス情報の変更が発生するか否かを判定する判定部と、
    前記筐体内アドレス情報の変更が発生する場合、筐体内アドレス情報の変更を抑制するとともに筐体外ネットワークで使用される筐体外アドレス情報の変更を適用すると判定し、前記第１の処理機能部に対応する筐体内アドレス情報と前記第２の処理機能部に対応する筐体外アドレス情報とを設定して、前記第２の処理機能部を前記第１の処理機能部でリカバリするリカバリ実行部と
    を有することを特徴とする情報処理装置。
  2. 前記リカバリ実行部は、停止中の前記第１の処理機能部で前記第２の処理機能部をリカバリさせる場合に、前記第２の処理機能部が使用する筐体内アドレス情報の変更が発生するときは、前記第１の管理ネットワークにおいて前記第２の処理機能部が使用する筐体内アドレス情報と競合する処理機能部のいずれかの前記筐体内アドレス情報を、競合しない筐体内アドレス情報に再設定して、前記第２の処理機能部をリカバリすることを特徴とする請求項１に記載の情報処理装置。
  3. 前記リカバリ実行部は、動作中の前記第１の処理機能部で前記第２の処理機能部をリカバリさせる場合に、前記第２の処理機能部が使用する筐体内アドレス情報の変更が発生するときは、リカバリ先の前記第１の処理機能部に元々設定されている筐体内アドレス情報をリカバリ後の前記筐体内アドレス情報に設定して競合を解消し、前記第２の処理機能部の筐体外アドレス情報を前記第１の処理機能部に設定し、前記第１の処理機能部内における前記筐体外アドレス情報の設定を有効にして、前記第２の処理機能部をリカバリすることを特徴とする請求項１または２に記載の情報処理装置。
  4. 前記第１の処理機能部は、第１のサーバ装置が有するパーティションであり、
    前記第２の処理機能部は、前記第１のサーバ装置とは異なる第２のサーバ装置が有するパーティションであることを特徴とする請求項１に記載の情報処理装置。
  5. 前記判定部は、前記第２の処理機能部のリカバリが発生する前に、前記第２の処理機能部の前記筐体内アドレス情報の変更が発生するか否かを事前に判定し、
    前記リカバリ実行部は、前記第２の処理機能部のリカバリが発生する前に、前記第１の処理機能部の筐体内アドレス情報と前記第２の処理機能部の筐体外アドレス情報とを、前記第１の処理機能部に事前に設定しておくことを特徴とする請求項１に記載の情報処理装置。
  6. 情報処理装置が、
    情報処理装置としての機能を発揮する処理機能部ごとに、当該処理機能部が使用する各デバイスに割当てられるアドレス情報と、各デバイスが接続されるネットワークが筐体内ネットワークか筐体外ネットワークかを示すネットワーク情報とを対応付けて記憶する記憶部を参照し、
    第１の管理ネットワークを介して監視される、前記情報処理装置としての機能を発揮する第１の処理機能部で、第２の管理ネットワークを介して監視される第２の処理機能部をリカバリさせる場合、前記第２の処理機能部が筐体内ネットワークで使用する筐体内アドレス情報の変更が発生するか否かを判定し、
    前記筐体内アドレス情報の変更が発生する場合、筐体内アドレス情報の変更を抑制するとともに筐体外ネットワークで使用される筐体外アドレス情報の変更を適用すると判定し、前記第１の処理機能部に対応する筐体内アドレス情報と前記第２の処理機能部に対応する筐体外アドレス情報とを設定して、前記第２の処理機能部を前記第１の処理機能部でリカバリする
    処理を含んだことを特徴とするリカバリ管理方法。
  7. 前記判定する処理は、前記第２の処理機能部のリカバリが発生する前に、前記第２の処理機能部の前記筐体内アドレス情報の変更が発生するか否かを事前に判定し、
    前記リカバリする処理は、前記第２の処理機能部のリカバリが発生する前に、前記第１の処理機能部の筐体内アドレス情報と前記第２の処理機能部の筐体外アドレス情報とを、前記第１の処理機能部に事前に設定しておくことを特徴とする請求項６に記載のリカバリ管理方法。
JP2013249632A 2013-12-02 2013-12-02 情報処理装置およびリカバリ管理方法 Active JP6217358B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013249632A JP6217358B2 (ja) 2013-12-02 2013-12-02 情報処理装置およびリカバリ管理方法
US14/549,998 US20150154083A1 (en) 2013-12-02 2014-11-21 Information processing device and recovery management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013249632A JP6217358B2 (ja) 2013-12-02 2013-12-02 情報処理装置およびリカバリ管理方法

Publications (2)

Publication Number Publication Date
JP2015106385A JP2015106385A (ja) 2015-06-08
JP6217358B2 true JP6217358B2 (ja) 2017-10-25

Family

ID=53265420

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013249632A Active JP6217358B2 (ja) 2013-12-02 2013-12-02 情報処理装置およびリカバリ管理方法

Country Status (2)

Country Link
US (1) US20150154083A1 (ja)
JP (1) JP6217358B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102374767B1 (ko) * 2020-09-29 2022-03-14 엘에스일렉트릭(주) 웹 기반 인버터 설정복사 시스템 및 설정복사 장치

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3441264B2 (ja) * 1995-09-26 2003-08-25 三菱電機株式会社 多重系システム
US7499410B2 (en) * 2001-12-26 2009-03-03 Cisco Technology, Inc. Fibre channel switch that enables end devices in different fabrics to communicate with one another while retaining their unique fibre channel domain—IDs
JP4757670B2 (ja) * 2006-03-16 2011-08-24 株式会社日立製作所 システム切替方法、その計算機システム及びプログラム
JP4279298B2 (ja) * 2006-07-18 2009-06-17 株式会社東芝 サービス及びｉｐアドレスの引き継ぎが可能なコンピュータシステム及びプログラム
US8108514B2 (en) * 2008-04-02 2012-01-31 International Business Machines Corporation High availability of internet protocol addresses within a cluster
JP4811489B2 (ja) * 2009-03-27 2011-11-09 日本電気株式会社 サーバシステム、集合型サーバ装置及びｍａｃアドレス管理方法
JP5594668B2 (ja) * 2010-10-21 2014-09-24 データアクセス株式会社 ノード、クラスタリングシステム、クラスタリングシステムの制御方法、およびプログラム
US9923787B2 (en) * 2012-04-27 2018-03-20 International Business Machines Corporation Network configuration predictive analytics engine

Also Published As

Publication number Publication date
US20150154083A1 (en) 2015-06-04
JP2015106385A (ja) 2015-06-08

Similar Documents

Publication Publication Date Title
US10432470B2 (en) Distributed subnet manager for InfiniBand networks
CN105743692B (zh) 用于应用管理的基于策略的框架
Yamato et al. Fast and reliable restoration method of virtual resources on OpenStack
US9582377B1 (en) Dynamic sizing of storage capacity for a remirror buffer
US11226753B2 (en) Adaptive namespaces for multipath redundancy in cluster based computing systems
US9237093B2 (en) Bandwidth on-demand adaptive routing
US20200073656A1 (en) Method and Apparatus for Drift Management in Clustered Environments
GB2492620A (en) Midplane for blade server management
JP2007172334A (ja) 並列型演算システムの冗長性を確保するための方法、システム、およびプログラム
CN106980529B (zh) 基板管理控制器资源管理的电脑系统
WO2018137520A1 (zh) 一种业务恢复方法及装置
JP2014522052A (ja) ハードウェア故障の軽減
US11349706B2 (en) Two-channel-based high-availability
CN107645402B (zh) 一种路由管理方法和装置
US20190334990A1 (en) Distributed State Machine for High Availability of Non-Volatile Memory in Cluster Based Computing Systems
US20210075763A1 (en) System and method of using a global discovery service to enable routing of packets from a source container to a destination container
BR112017011541B1 (pt) Método para processar uma solicitação de bloqueio, aparelho de gerenciamento de solicitação de bloqueio e servidor
CN113656147A (zh) 一种集群部署方法、装置、设备及存储介质
JP5531487B2 (ja) サーバシステム及びサーバシステムの管理方法
WO2021072130A1 (en) Dynamic discovery of service nodes in a network
US9430341B2 (en) Failover in a data center that includes a multi-density server
Venâncio et al. VNF‐Consensus: A virtual network function for maintaining a consistent distributed software‐defined network control plane
JP6217358B2 (ja) 情報処理装置およびリカバリ管理方法
US10305987B2 (en) Method to syncrhonize VSAN node status in VSAN cluster
US8929251B2 (en) Selecting a master processor from an ambiguous peer group

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160804

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170412

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170418

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170614

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170829

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170911

R150 Certificate of patent or registration of utility model

Ref document number: 6217358

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150