(57)【要約】  統合プラットフォームは、現用及び予備サーバと、ストレージ装置とを有する。ストレージ装置は、複数のストレージポートを有し、当該複数のストレージポートには、それぞれ、ＷＷＮが付与されている。ストレージ装置が提供する複数の論理ボリュームには、それぞれ、ＬＵＩＤが付与されている。現用及び予備サーバは、それぞれ、ストレージポートと１対１で接続されている。現用サーバは、接続先のストレージポートのＷＷＮと、ブート時にアクセスする論理ボリュームであるブート論理ボリュームのＬＵＮと、当該ブート論理ボリュームのＬＵＩＤと、を関連付けるブート検索情報、を有する。フェイルオーバが実行される際、現用サーバが有するブート検索情報は、予備サーバへコピーされる。
2017119116.tif 000002
【特許請求の範囲】
【請求項１】
現用及び予備サーバと、ストレージ装置とを有する統合プラットフォームであって、
前記ストレージ装置は、複数のストレージポートを有し、当該複数のストレージポートには、それぞれ、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｎａｍｅ（ＷＷＮ）が付与されており、
前記ストレージ装置が提供する複数の論理ボリュームには、それぞれ、一意に識別可能なＬｏｇｉｃａｌ  Ｕｎｉｔ  ＩＤ（ＬＵＩＤ）が付与されており、
前記現用及び予備サーバは、それぞれ、ストレージポートと１対１で接続されており、
前記現用サーバは、接続先のストレージポートのＷＷＮと、ブート時にアクセスする論理ボリュームであるブート論理ボリュームのＬｏｇｉｃａｌ  Ｕｎｉｔ  Ｎｕｍｂｅｒ（ＬＵＮ）と、当該ブート論理ボリュームのＬＵＩＤと、を関連付けるブート検索情報、を有し、
フェイルオーバが実行される際、前記現用サーバが有するブート検索情報は、前記予備サーバへコピーされる
統合プラットフォーム。
【請求項２】
前記現用及び予備サーバは、それぞれ、Ｅｘｔｅｎｓｉｂｌｅ  Ｆｉｒｍｗａｒｅ  Ｉｎｔｅｒｆａｃｅ（ＥＦＩ）部と、ＥＦＩドライバ部とを含み、
前記ＥＦＩ部は、ＥＦＩの仕様に準拠し、前記ブート論理ボリュームへのデバイスパス情報を含むブート順序情報を有し、前記デバイスパス情報は、ＬＵＩＤを用いて記述されており、
前記ＥＦＩドライバ部は、前記ブート検索情報を有し、
フェイルオーバが実行される際、前記現用サーバのＥＦＩ部が有するブート検索情報は、前記予備サーバのＥＦＩ部へコピーされ、前記現用サーバのＥＦＩドライバ部が有する前記ブート順序情報は、前記予備サーバのＥＦＩドライバ部へコピーされる
請求項１に記載の統合プラットフォーム。
【請求項３】
前記ＥＦＩ部は、前記ブート順序情報のデバイスバス情報に含まれるＬＵＩＤを、前記ＥＦＩドライバ部へ発行し、
前記ＥＦＩドライバ部は、
前記ブート検索情報において、前記ＥＦＩから発行されたＬＵＩＤと関連付けられているＷＷＮを用いて、前記ブート論理ボリュームを検索し、
その検索の結果、前記ブート論理ボリュームを発見できない場合、当該ブート検索情報において、前記ＥＦＩから発行されたＬＵＩＤを用いて、前記ブート論理ボリュームを検索する
請求項２に記載の統合プラットフォーム。
【請求項４】
前記ＥＦＩドライバ部は、
前記ＥＦＩから発行されたＬＵＩＤを用いた前記ブート論理ボリュームの検索の結果、前記ブート論理ボリュームを発見できた場合、前記ブート検索情報において、前記ＬＵＩＤと関連付けられているＷＷＮを、そのブート論理ボリュームを発見できた経路上のストレージポートのＷＷＮに変更する
請求項３に記載の統合プラットフォーム。
【請求項５】
前記ＥＦＩドライバ部は、
前記ブート論理ボリュームを発見できた場合、そのブート論理ボリュームへのＬＵＩＤを含むデバイスパス情報を、前記ＥＦＩ部へ返し、
前記ＥＦＩ部は、
前記ＥＦＩドライバ部へ発行したＬＵＩＤを含むデバイスパス情報と、前記ＥＦＩドライバ部から返されたＬＵＩＤを含むデバイスパス情報が一致する場合、当該デバイスパス情報の示すブート論理ボリュームからブートを開始する
請求項４に記載の統合プラットフォーム。
【請求項６】
ストレージ装置と接続されているサーバであって、
前記ストレージ装置は、複数のストレージポートを有し、当該複数のストレージポートには、それぞれ、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｎａｍｅ（ＷＷＮ）が付与されており、
前記ストレージ装置が提供する複数の論理ボリュームには、それぞれ、一意に識別可能なＬｏｇｉｃａｌ  Ｕｎｉｔ  ＩＤ（ＬＵＩＤ）が付与されており、
前記サーバは、ストレージポートと１対１で接続されており、
前記サーバは、接続先のストレージポートのＷＷＮと、ブート時にアクセスする論理ボリュームであるブート論理ボリュームのＬｏｇｉｃａｌ  Ｕｎｉｔ  Ｎｕｍｂｅｒ（ＬＵＮ）と、当該ブート論理ボリュームのＬＵＩＤと、を関連付けるブート検索情報、を有し、
フェイルオーバが実行される際、前記サーバが有するブート検索情報は、他のサーバへコピーされる
サーバ。
【請求項７】
前記サーバは、Ｅｘｔｅｎｓｉｂｌｅ  Ｆｉｒｍｗａｒｅ  Ｉｎｔｅｒｆａｃｅ（ＥＦＩ）部と、ＥＦＩドライバ部とを含み、
前記ＥＦＩ部は、ＥＦＩの仕様に準拠し、前記ブート論理ボリュームへのデバイスパス情報を含むブート順序情報を有し、前記デバイスパス情報は、ＬＵＩＤを用いて記述されており、
前記ＥＦＩドライバ部は、前記ブート検索情報を有し、
フェイルオーバが実行される際、前記サーバのＥＦＩ部が有するブート検索情報は、前記他のサーバのＥＦＩ部へコピーされ、前記サーバのＥＦＩドライバ部が有する前記ブート順序情報は、前記他のサーバのＥＦＩドライバ部へコピーされる
請求項６に記載のサーバ。
【請求項８】
ストレージ装置に接続されている現用サーバ及び予備サーバ間におけるフェイルオーバ方法であって、
前記ストレージ装置は、複数のストレージポートを有し、当該複数のストレージポートには、それぞれ、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｎａｍｅ（ＷＷＮ）が付与されており、
前記ストレージ装置が提供する複数の論理ボリュームには、それぞれ、一意に識別可能なＬｏｇｉｃａｌ  Ｕｎｉｔ  ＩＤ（ＬＵＩＤ）が付与されており、
前記現用及び予備サーバは、それぞれ、ストレージポートと１対１で接続されており、
前記現用サーバは、接続先のストレージポートのＷＷＮと、ブート時にアクセスする論理ボリュームであるブート論理ボリュームのＬｏｇｉｃａｌ  Ｕｎｉｔ  Ｎｕｍｂｅｒ（ＬＵＮ）と、当該ブート論理ボリュームのＬＵＩＤと、を関連付けるブート検索情報、を有し、
前記現用サーバから前記予備サーバに対してフェイルオーバを実行する際、前記現用サーバが有するブート検索情報を、前記予備サーバにコピーする
フェイルオーバ方法。
【請求項９】
前記現用及び予備サーバは、それぞれ、Ｅｘｔｅｎｓｉｂｌｅ  Ｆｉｒｍｗａｒｅ  Ｉｎｔｅｒｆａｃｅ（ＥＦＩ）部と、ＥＦＩドライバ部とを含み、
前記ＥＦＩ部は、ＥＦＩの仕様に準拠し、前記ブート論理ボリュームへのデバイスパス情報を含むブート順序情報を有し、前記デバイスパス情報は、ＬＵＩＤを用いて記述されており、
前記ＥＦＩドライバ部は、前記ブート検索情報を有し、
前記フェイルオーバを実行する際、前記現用サーバのＥＦＩ部が有するブート検索情報を、前記予備サーバのＥＦＩ部にコピーし、前記現用サーバのＥＦＩドライバ部が有する前記ブート順序情報を、前記予備サーバのＥＦＩドライバ部にコピーする
請求項８に記載のフェイルオーバ方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、計算機制御に関し、特に、計算機の冗長化に関する。
【背景技術】
【０００２】
ストレージネットワークにおいては、ＬＵ（Ｌｏｇｉｃａｌ  Ｕｎｉｔ）へのアクセスを特定のサーバに限定することが望ましい。サーバが、アクセス（Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ））してはいけないＬＵ（例えば論理ボリューム（論理ＶＯＬ））に誤ってアクセスし、そのＬＵのデータを誤って更新してしまうおそれがあるからである。【０００３】
ＬＵへのアクセスを特定のサーバに限定する技術として、ＬＵマスキング機能が知られている。このＬＵマスキング機能は、ストレージ装置が有するポート毎に、ＬＵについてのアクセス制御リストを作成する。アクセス制御リストは、ストレージ装置内でＬＵへのアクセスを許可されたＦＣ−ＨＢＡ（Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ−Ｈｏｓｔ  Ｂｕｓ  Ａｄａｐｔｅｒ）の物理ポートのＷＷＮ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｎａｍｅ）を含む。【０００４】
また、ストレージ装置のＩ／Ｏポート（ストレージポートという）は、従来、１から２ポート程度と少なく、ＦＣスイッチを用いて、複数のサーバからのアクセスを可能とする。しかし、近年、ストレージポートは、１０以上のポートを搭載していることも多く、高額なＦＣスイッチを用いずとも、複数のサーバと直結して接続できるようになってきている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第４７１０５１８号公報
【特許文献２】特開２０１４−４１３９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１では、ＦＣ−ＨＢＡとストレージ装置のＦＣ（Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ）ポートとが、ＦＣスイッチを介して接続されることが前提となっている。このため、ＦＣスイッチの機能により、現用サーバから予備サーバへの切り替えの前後において、切り替え前の現用サーバが発行するＩ／Ｏ要求と、切り換え後の予備サーバが発行するＩ／Ｏ要求とは、同じストレージポートで受領される。ＬＵについてのアクセス制御リストは、ストレージポート単位で適用される（例えばストレージポートにアクセス制御リストが割り当てられる）が、上記のように、同一ＬＵを指定したＩ／Ｏ要求を受けるストレージポートは、現用サーバから予備サーバへの切り替えの前後で同じなので、切り替え前のサーバは、その同じＬＵにアクセスできてしまう。【０００７】
一方、ストレージポートとサーバの物理ポートとがＦＣケーブル又はＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｅｘｐｒｅｓｓ）バス等によって直結されている場合（言い換えれば、ストレージポートとサーバの物理ポートとが１対１で対応している場合）、現用サーバから予備サーバへの切り替えの前後において、切り替え前の現用サーバが発行するＩ／Ｏ要求と、切り換え後の予備サーバが発行するＩ／Ｏ要求とは、異なるストレージポートで受領される。切り換え後の予備サーバは、Ｉ／Ｏ要求の送出先のストレージポートのＷＷＮを元に、ＬＵの検索指示を送出するが、Ｉ／Ｏ要求を受けるストレージポートのＷＷＮは変わってしまっているため、ＬＵを見つけることができない。そのため、切換え後の予備サーバは、ＬＵへアクセスすることができない。【０００８】
また、特許文献２では、仮想化したＬＰＡＲ（Ｌｏｇｉｃａｌ  ＰＡＲｔｉｔｉｏｎ）の構成が条件となっているため、仮想化を行っていない計算機システムにおいて上述の課題を解決することができない。【０００９】
そこで、本発明の目的は、フェイルオーバが実行された際に、予備サーバが正常にブートできるようにすることにある。
【課題を解決するための手段】
【００１０】
一実施例に係る統合プラットフォームは、現用及び予備サーバと、ストレージ装置とを有する。
ストレージ装置は、複数のストレージポートを有し、当該複数のストレージポートには、それぞれ、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｎａｍｅ（ＷＷＮ）が付与されている。
ストレージ装置が提供する複数の論理ボリュームには、それぞれ、一意に識別可能なＬｏｇｉｃａｌ  Ｕｎｉｔ  ＩＤ（ＬＵＩＤ）が付与されている。
現用及び予備サーバは、それぞれ、ストレージポートと１対１で接続されている。
現用サーバは、接続先のストレージポートのＷＷＮと、ブート時にアクセスする論理ボリュームであるブート論理ボリュームのＬｏｇｉｃａｌ  Ｕｎｉｔ  Ｎｕｍｂｅｒ（ＬＵＮ）と、当該ブート論理ボリュームのＬＵＩＤと、を関連付けるブート検索情報、を有する。
フェイルオーバが実行される際、現用サーバが有するブート検索情報は、予備サーバへコピーされる。
【発明の効果】
【００１１】
本発明によれば、フェイルオーバが実行された際に、予備サーバが正常にブートすることができる。
【図面の簡単な説明】
【００１２】
【図１】統合プラットフォームの構成例を示す。
【図２】サーバの構成例を示す。
【図３】ストレージ装置の構成例を示す。
【図４】管理サーバの構成例を示す。
【図５】Ｂｏｏｔ  Ｏｒｄｅｒの参考例を示す。
【図６】本実施例に係るＢｏｏｔ  Ｏｒｄｅｒの一例を示す。
【図７】Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙの構成例を示す。
【図８】Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙの構成例を示す。
【図９】現用サーバから予備サーバにフェイルオーバする動作の一例を示す。
【図１０】現用サーバのブート動作例を示すシーケンスチャートである。
【図１１】フェイルオーバ後の予備サーバのブート動作例を示すシーケンスチャートである。
【図１２】本実施例に係るＥＦＩドライバの処理例を示すフローチャートである。
【発明を実施するための形態】
【００１３】
以下、図面を参照して、実施例を説明する。なお、以下の説明で、は「ａａａ表」、及び「ａａａリスト」等の表現にて実施例の情報を説明するが、これらは表及びリスト等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために、「ａａａ表」及び「ａａａリスト」等を「ａａａ情報」と呼ぶことができる。
【００１４】
また、以下の説明では、各情報の要素の識別情報の一例として、「名前」及び「ＩＤ」の少なくとも１つを用いることがあるが、これらについては互いに置換が可能である。
【００１５】
また、下記の説明では、仮想化の環境でも実現可能であり、その場合、「Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ」をＬＰＡＲ上の仮想ＦＣ−ＨＢＡ所有する「仮想Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ」として、「Ｂｏｏｔ  Ｏｒｄｅｒ」をＬＰＡＲ上のゲストＥＦＩが所有する「仮想Ｂｏｏｔ  Ｏｒｄｅｒ」として置換が可能である。
【００１６】
また、以下の説明では、同種の要素を区別しないで説明する場合には名称及び参照符号を使用し（例えばサーバ１００）、同種の要素を区別して説明する場合にはその要素に割り振られた識別情報を使用する（例えばサーバ１００Ａ、１００Ｂ）を使用することがある。
【００１７】
また、以下の説明では、「プログラム」を主語として処理の説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、当該処理の説明は、プロセッサを主語とした処理の説明としてもよい。また、プログラムを主語として開示された処理は、そのプログラムを実行するプロセッサを有する装置（例えば、管理システム又はストレージ装置）が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
【実施例１】
【００１８】
図１は、本実施例に係る統合プラットフォームの構成例を示す。【００１９】
統合プラットフォーム１は、ストレージ装置２００と、複数のサーバ１００とを有する。ストレージ装置２００と複数のサーバ１００とは、ＰＣＩｅバス４６を介して双方向通信可能に接続されている。複数のサーバ１００が、サーバシャーシ１５に搭載されている。ストレージ装置２００と複数のサーバ１００とは、管理ネットワーク４５を介して、管理サーバ３００と双方向通信可能に接続されている。管理ネットワーク４５には、管理サーバ３００の管理クライアント３５０と、サーバシャーシ１５に搭載されているサービスプロセッサ（ＳＶＰ）１７とが接続されてよい。管理ネットワーク４５は、例えばＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などの通信ネットワークであってよい。【００２０】
サーバ１００は、例えば、図示しないクライアントコンピュータからファイルのＩ／Ｏ要求を受信すると、その受信したＩ／Ｏ要求に基づいて、ストレージ装置２００にアクセスしてよい。ストレージ装置２００へのアクセスとは、サーバ１００がストレージ装置２００にＩ／Ｏ要求を送信することであってよい。サーバシャーシ１５の内部には、内部ネットワーク（例えばＬＡＮ）４７が存在してよい。【００２１】
ＳＶＰ１７は、コントローラの一例であり、内部ネットワーク４７を介して、各サーバ１００を管理する。ＳＶＰ１６は、切り替え元のサーバ１００及び切り替え先のサーバ１００の少なくとも一方に、フェイルオーバの指示を出すことができてよい。ＳＶＰ１７は、サーバシャーシ１５の内部の保守ポート１６と、内部バス等の回路を介して、双方向通信可能に接続されてよい。管理者は、保守ポート１６に保守用の端末を直接接続し、その保守用の端末を用いることにより、管理ネットワーク４５を介することなく、ＳＶＰ１７を操作することができてよい。【００２２】
管理サーバ３００は、管理システムの一例であり、管理ネットワーク４５を介して、計算機システムを管理する。管理サーバ３００も、切り替え元のサーバ１００及び切り替え先のサーバ１００の少なくとも一方に、フェイルオーバの指示を出すことができてよい。言い換えれば、各サーバ１００が、ＳＶＰ１７及び管理サーバ３００００の少なくとも一方からフェイルオーバの指示を受けることができてよい。これにより、ＳＶＰ１７は、サーバシャーシ１５内において、所定のイベントを検出し、管理サーバ３００からの指示無しに、自動的にフェイルオーバを行うこともできるし、管理サーバ３００からの指示を受けて（例えば、管理クライアント３５０の操作者（管理者）によるマニュアル操作に応答して）、フェイルオーバを行うこともできる。【００２３】
管理クライアント３５０は、管理ネットワーク４５を介して、管理サーバ３００のＧＵＩ表示処理モジュール３２３００（図４参照）と通信し、ＷＥＢブラウザ上に各種情報を表示する計算機である。管理者は管理クライアント上のＷＥＢブラウザに表示された情報を参照することで、計算機システム内の装置を管理することができる。管理サーバ３００と管理クライアント３５０とは、１台のサーバから構成されてもよい。【００２４】
図２は、サーバ１００の構成例を示す。【００２５】
サーバ１００は、管理ネットワーク４５に接続される管理ポート１１１００と、内部ネットワーク４７に接続されるポート１１０００と、１以上のＩ／Ｏポート１４０００と、ＰＣＩｅバスを介してストレージ装置２００に接続されるＦＣ−ＨＢＡ１２０と、メモリ１３０００と、プロセッサ１２０００と、ＥＦＩ１９０とを有する。これらの要素は、内部バス等の回路を介して双方向通信可能に接続されている。【００２６】
プロセッサ１２０００は、１以上のプロセッサで構成されてよい。メモリ１３０００は、１以上のメモリで構成されてよく、また、補助記憶デバイスのような記憶デバイスを含んでよい。ＥＦＩ１９０は、Ｂｏｏｔ  Ｏｒｄｅｒ１８０を有し、Ｂｏｏｔ  Ｏｒｄｅｒ１８０は、ストレージ装置２００の論理ＶＯＬへアクセスするために使用される。【００２７】
サーバ１００は、ＦＣ−ＨＢＡ１２０を介して、ストレージ装置２００へアクセスする。ＦＣ−ＨＢＡ１２０は、サーバ１００が、論理ＶＯＬにアクセスするために使用するＢｏｏｔ  Ｐｒｉｏｒｉｔｙ１５０を有する。また、ＦＣ−ＨＢＡ１２０は、当該ＦＣ−ＨＢＡ１２０の初期化やストレージ装置２００へのアクセスを行うためのＥＦＩドライバ１７０を有する。【００２８】
メモリ１３０００には、ＯＳ１３１００と、ＬＰＡＲ管理プログラム１３２００と、Ｉ／Ｏポート管理表１３３００と、ＬＰＡＲ管理表１３４００と、ＬＰＡＲ稼動スケジュール管理表１３５００と、が格納されてよい。【００２９】
ＬＰＡＲ管理プログラム１３２００は、オペレーティングシステム１３１００から提供されたプロセッサ１２０００及びメモリ１３０００のような物理資源（コンピュータリソース）を論理的に分割し、ＬＰＡＲを作成する。ＬＰＡＲは、管理計算機と呼ぶこともできる。ＬＰＡＲ管理プログラム１３２００が作成したＬＰＡＲは、ＰＣＩｅバス４６０００を介して、サーバ１００に接続されたストレージ装置２００上の論理ＶＯＬを、記憶領域として認識する。【００３０】
なお、図２では、ＬＰＡＲ管理プログラム１３２００がメモリ１３０００に存在しているが、ＬＰＡＲ管理プログラムが存在せず、オペレーティングシステム１３１００から提供された記憶領域を使用し、当該記憶領域に対してＩ／Ｏを行う業務アプリケーションが代わりに存在しても良い。つまり、ＬＰＡＲを構築できない（実行できない）サーバ１００が存在してよい。【００３１】
また、図２では、ＬＰＡＲ管理プログラム１３２００がメモリ１３０００に存在しているが、ＬＰＡＲ管理プログラムの代わりに仮想化制御プログラムが存在し、仮想化制御プログラムが、プロセッサ１２０００及びメモリ１３０００のような物理資源を抽象化及び標準化して、仮想マシンに仮想的なハードウェアを提供してもよい。その場合、以下の説明において、ＬＰＡＲが仮想マシンに、仮想化制御プログラムがＬＰＡＲ管理プログラムに相当する。【００３２】
図３は、ストレージ装置２００の構成例を示す。【００３３】
ストレージ装置２００は、ストレージシステムの一例であり、複数のストレージポート２１０００と、管理ポート２１１００と、メモリ２３０００と、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙｓ  ｏｆ  Ｉｎｅｘｐｅｎｓｉｖｅ  （ｏｒ  Ｉｎｄｅｐｅｎｄｅｎｔ）  Ｄｉｓｋｓ）グループ２４０１０と、コントローラ２５０００とを有する。それらの要素は、内部バス等の回路を介して双方向通信可能に接続されている。【００３４】
ストレージポート２１０００は、ＰＣＩｅバス４６を介してサーバ１００に接続してよい。【００３５】
管理ポート２１１００は、管理ネットワーク４５を介して管理サーバ３００に接続してよい。【００３６】
メモリ２３０００には、プログラムや管理情報などが格納されてよい。メモリ２３０００は、１以上のメモリで構成されてよく、また、補助記憶デバイスのような記憶デバイスを含んでよい。【００３７】
ＲＡＩＤグループ２４０１０には、様々なデータが格納されてよい。【００３８】
コントローラ２５０００は、データやメモリ内の管理情報を制御してよい。【００３９】
メモリ２３０００には、ディスク管理プログラム２３１００と、ポート管理表２３２００と、ホストグループ管理表２３３００と、ＲＡＩＤグループ管理表２３４００と、ボリューム管理表２３５００と、ホストグループ−ボリューム関連管理表２３６００と、テーブルサイズ上限管理表２３７００と、が格納される。【００４０】
ディスク管理プログラム２３１００は、管理ポート２１１００を経由して管理サーバ３００と通信し、管理サーバ３００に対して、ポート管理表２３２００と、ホストグループ管理表２３３００と、ＲＡＩＤグループ管理表２３４００と、ボリューム管理表２３５００と、ホストグループ−ボリューム関連管理表２３６００と、テーブルサイズ上限管理表２３７００と、のうちの少なくとも１つの表が有する情報を、ストレージ装置２００へ提供する。【００４１】
ＲＡＩＤグループ２４０１０は、複数の不揮発記憶デバイス２４２２０によって構成されている。ＲＡＩＤグループ２４０１０に代えて１つの不揮発記憶デバイス２４２２０が採用されてもよい。ＲＡＩＤグループ２４０１０のような１以上の不揮発記憶デバイス２４２２０を基に、論理ＶＯＬ２４１１０が提供される。少なくとも１つの論理ＶＯＬ２４１１０は、Ｔｈｉｎ  Ｐｒｏｖｉｓｉｏｎｉｎｇに従う仮想ボリュームのような仮想的な論理ＶＯＬであってよい。【００４２】
コントローラ２５０００は、内部に、ストレージ装置２００内の制御を行うプロセッサや、サーバ１００との間でやりとりするデータを一時的に記憶するキャッシュメモリを有してよい。そして、それぞれのコントローラ２５０００は、ストレージポート２１０００とＲＡＩＤグループ２４０１０との間に介在し、両者の間におけるデータの受け渡しを制御してよい。【００４３】
なお、ストレージ装置２００は、サーバ１００に提供した論理ＶＯＬ２４１１０を指定したアクセス要求（Ｉ／Ｏ要求を指す）を受信し、その論理ＶＯＬ２４１１０（例えば、その論理ＶＯＬ２４１１０の基になっている記憶デバイス）への読み書きを行うストレージコントローラと、記憶領域を提供する前述の記憶デバイスを含めば、図３及び前述以外の構成であってもよい。例えば、ストレージコントローラと記憶領域とを提供する記憶デバイスが別な筐体に格納されていてもよい。例えば、メモリ２３０００とコントローラ２５０００とがストレージコントローラであってもよい。ストレージコントローラと記憶デバイスとが同じ筐体に存在する場合及び別な筐体に存在する場合の両方を含む表現として、ストレージ装置を、ストレージシステムと呼び変えても良い。ストレージシステムは、複数のストレージ装置であってもよい。【００４４】
図４は、管理サーバ３００の構成例を示す。【００４５】
管理サーバ３００は、管理システムの一例であり、管理ネットワーク４５に接続するための管理ポート３１０００と、プロセッサ３１１００と、記憶資源３３０００と、後述する処理結果を出力するためのディスプレイ装置等の出力デバイス３１２００と、管理者が指示を入力するためのキーボード等の入力デバイス３１３００とを有してよい。これらの要素は、内部バス等の回路を介して双方向通信可能に接続されている。記憶資源３３０００は、１以上のメモリ（例えば半導体メモリ）でもよいし、不揮発記憶デバイスが混在してよい。【００４６】
記憶資源３３０００には、管理プログラム３２０００が格納されている。管理プログラム３２０００は、装置管理モジュール３２１００と、装置通信モジュール３２２００と、ＧＵＩ表示処理モジュール３２３００と、を含んでよい。各モジュールは、記憶資源３３０００のプログラムモジュールとして提供されているが、ハードウェアモジュールとして提供されてもよい。管理プログラム３２０００は、各モジュールの処理を実現できるのであれば、モジュールによって構成されなくてもよい。すなわち、以下の説明における各モジュールについての説明は、管理プログラム３２０００に関する説明に置き換えられてもよい。【００４７】
記憶資源３３０００には、さらに、装置管理表３３２００と、ホスト−ストレージパス管理表３３３００と、構成表９３４００とが格納されてよい。構成表９３４００には、構成情報が格納されてよい。構成情報は、例えば、装置通信モジュール３２２００が管理対象の各サーバ１００から収集してきたＩ／Ｏポート管理表１３３００の各項目と、ＬＰＡＲ管理表１３４００の各項目と、ＬＰＡＲ稼動スケジュール管理表１３５００の各項目と、管理対象の各ストレージから収集してきたポート管理表２３２００の各項目と、ホストグループ管理表２３３００の各項目と、ＲＡＩＤグループ管理表２３４００の各項目と、ボリューム管理表２３５００の各項目と、ホストグループ−ボリューム関連管理表２３６００の各項目と、テーブルサイズ上限管理表２３７００の各項目とを含んでよい。構成表９３４００には、必ずしも、管理対象装置の全ての表、又は、表中の全ての項目が格納されなくてもよい。構成表９３４００に格納される各項目のデータ表現形式及びデータ構造は、管理対象装置と同じでなくてもよい。管理プログラム３２０００は、管理対象装置からこれら各項目を受信する場合、管理対象装置のデータ構造やデータ表現形式でこれら各項目を受信してもよい。【００４８】
装置通信モジュール３２２００は、管理下の管理対象装置に定期的又は繰り返しアクセスし、管理対象装置内の各コンポーネントの構成情報を取得する。なお、当該実行指示の繰り返しは、厳密に一定期間毎である必要は無く、どのようなタイミングであってもよい。装置通信モジュール３２２００は、管理者からの要求に応じて、管理下の管理対象装置に対して構成変更を指示してよい。装置通信モジュール３２２００は、管理対象装置に対して構成変更を指示した後、管理対象装置内の各コンポーネントの構成情報を再取得し、構成表９３４００に格納された構成情報を最新の状態に保ってよい。【００４９】
ＧＵＩ表示処理モジュール３２３００は、入力デバイス３１３００を介した管理者からの要求に応じ、取得した構成管理情報を、出力デバイス３１２００を介して表示する。入力デバイスと出力デバイスとは別々なデバイスでもよいし、一つ以上のまとまったデバイスであってもよい。【００５０】
管理サーバ（管理計算機）は、例えば、入出力デバイスとして、ディスプレイとキーボードとポインタデバイス等を有してもよいし、これ以外の装置を有してもよい。入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを用い、当該インターフェースに、ディスプレイ、キーボード及び／又はポインタデバイスを有する表示用計算機（例えば、管理クライアント３５０００）が接続されてもよい。そして、管理サーバは、当該インターフェースを介して、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信して表示用計算機に表示したり、入力を受け付けたりすることで、入出力デバイスでの入力及び表示を代替してもよい。【００５１】
本明細書では、計算機システム（情報処理システム）を管理し、表示用情報を表示する１つ以上の計算機の集合を「管理システム」と呼ぶことができる。表示デバイス又は遠隔の表示用計算機に表示用情報を表示する管理計算機を管理システムと呼ぶことができ、管理計算機と表示用計算機（例えば図１の管理クライアント３５０００）の組み合わせも管理システムと呼ぶことができる。また、処理の高速化や高信頼化のために複数の計算機で管理計算機と同等の処理を実現してもよく、この場合は複数の計算機（表示用計算機を含んでよい）を管理システムと呼ぶことができる。【００５２】
図５は、Ｂｏｏｔ  Ｏｒｄｅｒの参考例を示す。【００５３】
Ｂｏｏｔ  Ｏｒｄｅｒは、サーバが使用するＤｅｖｉｃｅ  Ｐａｔｈの優先順位を管理するためのテーブルである。Ｂｏｏｔ  Ｏｒｄｅｒは、ユーザが任意の表現で記述するＤｅｓｃｒｉｐｔｉｏｎと、ブートするデバイスの場所を示すＤｅｖｉｃｅ  Ｐａｔｈとで構成されてよい。Ｄｅｖｉｃｅ  Ｐａｔｈの記述は、ＵＥＦＩの仕様で規定されており、ＥＦＩやＥＦＩドライバによって生成されてよい。Ｂｏｏｔ  Ｏｒｄｅｒは、ブート順序情報と呼ばれてよい。Ｂｏｏｔ  Ｏｒｄｅｒの各エントリは、Ｂｏｏｔ  Ｏｐｔｉｏｎと呼ばれてよい。【００５４】
図５は、Ｂｏｏｔ  ＯｒｄｅｒのＤｅｖｉｃｅ  Ｐａｔｈが、Ｆｉｂｒｅ  Ｃｈａｎｎｅｌに割り当てられているＷＷＮをキーとして構成されている例である。【００５５】
図６は、本実施例に係るＢｏｏｔ  Ｏｒｄｅｒ１８００の一例を示す。【００５６】
本実施例に係るＢｏｏｔ  Ｏｒｄｅｒ１８００のＤｅｖｉｃｅ  Ｐａｔｈは、図５のようなＦｉｂｒｅ  Ｃｈａｎｎｅｌに割り当てられるＷＷＮに代えて、ベンダーが任意の番号を割り当てるＧＵＩＤと、ＬＵ（例えば論理ＶＯＬ）に割り当てられたＬＵＩＤとによって構成される。【００５７】
なお、本実施例において、図６の「ＶｅｎＭｓｇ（Ｖｅｎｄｅｒ  ＧＵＩＤ，ＬＵＩＤ＃Ｃ）」を、「ＬＵＩＤ＃Ｃ」と表記する。また、本実施例において、図６のＤｅｖｉｃｅ  Ｐａｔｈの「ＨＤ（１，ＭＢＲ，０ｘＡ０６Ａ９１５Ｆ，０ｘ８００，０ｘＡＦ０００）」を、「ＬＵＮ＃ｚ」と表記する。【００５８】
Ｄｅｖｉｃｅ  Ｐａｔｈは、ＥＦＩドライバ１７０がデバイスを検索するときに使用され、ＥＦＩドライバ１７０毎に異なる記述であってよい。【００５９】
図６のＢｏｏｔ  Ｏｒｄｅｒ１８００は、優先順位の高い順に、「ＦＣ１」、「ＦＣ２」、「ＦＣ３」であることを示す。図６のＢｏｏｔ  Ｏｒｄｅｒを参照したシステムは、エントリ「１」の「ＦＣ１」のＤｅｖｉｃｅ  Ｐａｔｈから起動を試み、失敗した場合、次に、エントリ「２」の「ＦＣ２」のＤｅｖｉｃｅ  Ｐａｔｈから起動を試みる、ということを繰り返す。【００６０】
図５及び図６のＢｏｏｔ  Ｏｒｄｅｒは、共にＵＥＦＩの仕様を満たした記述であり、典型的には、図５の表記で使用されることが多い。しかし、本実施例では、図６の表記を使用する。【００６１】
図７及び図８は、ＦＣ−ＨＢＡ１２０が有するＢｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００の構成例を示す。【００６２】
Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００は、項目値として、ストレージ装置のＩ／ＯポートのＷＷＮと、ストレージ装置のＬＵＮと、ストレージ装置の論理ＶＯＬに割り当てられているＬＵＩＤとを有してよい。ＬＵＩＤは、複数のストレージ装置に存在する複数の論理ＶＯＬに対してもユニークなＩＤである。例えば、図９において、現用サーバと予備サーバとに、それぞれ、別々のストレージ装置の論理ＶＯＬが割り当てられた場合であっても、それぞれの論理ＶＯＬのＬＵＩＤは重複しない。【００６３】
Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００は、ブート検索情報と呼ばれてもよい。Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００の項目値は、ユーザによって設定されてよい。Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００の項目値を設定及び変更するためのインターフェースは、ＥＦＩドライバ１７０が提供してよい。Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００は、ＥＦＩドライバ１７０が、ＥＦＩ１９０から受領したデバイスの検索指示に対して、優先順位を応答するために使用される。【００６４】
典型的には、ＬＵＩＤは、ＥＦＩドライバ１７０が、Ｄｅｖｉｃｅ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ＶＰＤ  Ｐａｇｅを要求するＩｎｑｕｉｒｙコマンドをストレージ装置に発行し、返答してきたＩｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎリストの情報からＤｅｎｔｉｆｉｅｒ  ＴｙｐｅがＮａｍｅ  Ａｄｄｒｅｓｓ  Ａｕｔｈｏｒｉｔｙ、若しくは、Ｉｄｅｎｔｉｆｉｅｒ  Ｔｙｐｅが、Ｔ１０  Ｖｅｎｄｏｒ  ＩｄｅｎｔｉｆｉｃａｔｉｏｎのＩｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒの値を示す。【００６５】
図９は、冗長化システムにおいて障害が発生し、現用サーバから予備サーバに切り替える動作の一例を示す。【００６６】
現用サーバ１００Ａに障害が発生した場合、ＳＶＰは、フェイルオーバ処理として、その現用サーバ１００のＥＦＩ１９０が有するＢｏｏｔ  Ｏｒｄｅｒ１８００Ｃを、予備サーバ１００ＢのＥＦＩ１９０Ｂにコピーする（コピー後をＢｏｏｔ  Ｏｒｄｅｒ１８００Ｄとする）。また、ＳＶＰは、現用ＦＣ−ＨＢＡ１２０Ａが有するＢｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００Ｃも、予備ＦＣ―ＨＢＡ１２０Ｂにコピーする（コピー後をＢｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００Ｄとする）。【００６７】
次に、図１０に現用サーバ１００Ａのブート動作例を、図１１にフェイルオーバ後における待機サーバ１００Ｃのブート動作の例を示す。【００６８】
図１０は、図９において、現用サーバ１００Ａのブート動作例を示すシーケンスチャートである。【００６９】
ここで、現用サーバ１００ＡのＢｏｏｔ  Ｏｒｄｅｒ１８００Ｃのエントリ「１」には、ＬＵＩＤ＃Ｃを含むＤｅｖｉｃｅ  Ｐａｔｈが設定されているとする。また、ＥＦＩドライバ１７０ＡのＢｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００Ｃのエントリ「１」には、ＷＷＮ＃１、ＬＵＮ＃ｚ、ＬＵＩＤ＃Ｃが設定されているとする。【００７０】
現用サーバ１００Ａに電源が投入されたとき、ＥＦＩ１９０ＡとＥＦＩドライバ１７０Ａとは、連携しつつ起動する。【００７１】
ＥＦＩ１９０Ａは、最初に、Ｂｏｏｔ  Ｏｒｄｅｒ１８００Ｃのエントリ「１」のＤｅｖｉｃｅ  Ｐａｔｈを読み込み（Ｓ４０１００）、ＥＦＩドライバ１７０Ａに対して実行指示を行う（Ｓ４０３００）。この実行指示には、読み込んだＤｅｖｉｃｅ  Ｐａｔｈに記述されているＬＵＩＤ＃Ｃが含まれてよい。そして、ＥＦＩ１９０Ａは、ＥＦＩドライバ１７０Ａの実行完了を待つ（Ｓ４０４００）。【００７２】
一方、ＥＦＩドライバ１７０Ａは、Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００Ｃのエントリ「１」に、ＷＷＮ＃１、ＬＵＮ＃ｚ、ＬＵＩＤ＃Ｃが設定されていることを確認し（Ｓ４０２００）、ＥＦＩ１９０Ａに呼び出されるのを待つ（Ｓ４０５００）。【００７３】
ＥＦＩドライバ１９０Ａは、ＥＦＩ１９０Ａから実行指示を受けると、Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００Ｃから、その実行指示に含まれるＬＵＩＤ＃Ｃに対応するＷＷＮ＃１及びＬＵＮ＃ｚを特定する。そして、ＥＦＩドライバ１９０Ａは、その特定したＷＷＮ＃１をキーとして、ＬＵＮ＃ｚの論理ＶＯＬを検索する（Ｓ４０６００）。【００７４】
ＦＣ―ＨＢＡ１２０Ａは、ストレージ装置２００のＷＷＮ＃１に接続されているので、ＥＦＩドライバ１７０Ａは、そのＷＷＮ＃１をキーとして、ＬＵＮ＃ｚの論理ＶＯＬを発見できる。【００７５】
そこで、ＥＦＩドライバ１７０Ａは、その発見した論理ＶＯＬのＬＵＩＤ＃Ｃを用いて記述したＤｅｖｉｃｅ  Ｐａｔｈを、ＥＦＩ１９０Ａに送信する（Ｓ４０７００）。【００７６】
ＥＦＩ１９０Ａは、ＥＦＩドライバ１７０Ａから送信されたＤｅｖｉｃｅ  Ｐａｔｈと、Ｓ４０３００で実行指示を行ったＤｅｖｉｃｅ  Ｐａｔｈと、を比較する（Ｓ４０８００）。【００７７】
この比較の結果、何れのＤｅｖｉｃｅ  ＰａｔｈもＬＵＩＤ＃Ｃに対する記述で一致するので、ＥＦＩ１９０Ａは、エントリ「１」のＤｅｖｉｃｅ  Ｐａｔｈからブートする（Ｓ４０９００）。【００７８】
図１１は、図９において、フェイルオーバ後の予備サーバ１００Ｂのブート動作例を示すシーケンスチャートである。【００７９】
予備サーバ１００Ｂに電源が投入されたとき、ＥＦＩ１９０ＢとＥＦＩドライバ１７０Ｂとは、連携しつつ起動する。【００８０】
ＥＦＩ１９０ＢのＢｏｏｔ  Ｏｒｄｅｒ１８００Ｄは、ＥＦＩ１９０ＡのＢｏｏｔ  Ｏｒｄｅｒ１８００Ｃのコピーである。【００８１】
また、ＦＣ−ＨＢＡ１２０ＢのＢｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００Ｄは、ＦＣ−ＨＢＡ１２０ＡのＢｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００Ｃのコピーである。【００８２】
ＥＦＩ１９０Ｂは、最初に、Ｂｏｏｔ  Ｏｒｄｅｒ１８００Ｄのエントリ「１」のＤｅｖｉｃｅ  Ｐａｔｈを読み込み（Ｓ５０１００）、ＥＦＩドライバ１７０Ｂに対して実行指示を行う（Ｓ５０３００）。この実行指示には、Ｄｅｖｉｃｅ  Ｐａｔｈに記述されているＬＵＩＤ＃Ｃが含まれてよい。そして、ＥＦＩ１９０Ｂは、ＥＦＩドライバ１７０Ｂの実行完了を待つ（Ｓ５０４００）。【００８３】
一方、ＥＦＩドライバ１７０Ｂは、Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００Ｄのエントリ「１」に、ＷＷＮ＃１、ＬＵＮ＃ｚ、ＬＵＩＤ＃Ｃが設定されていることを確認し（Ｓ５０２００）、ＥＦＩ１９０Ｂに呼び出されるのを待つ（Ｓ５０５００）。【００８４】
ＥＦＩドライバ１７０Ｂは、ＥＦＩ１９０Ｂから実行指示を受けると、Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００Ｄから、その実行指示に含まれるＬＵＩＤ＃Ｃに対応するＷＷＮ＃１及びＬＵＮ＃ｚを特定する。そして、ＥＦＩドライバ１７０Ｂは、その特定したＷＷＮ＃１及びＬＵＮ＃ｚの論理ＶＯＬを検索する（Ｓ５０６００）。【００８５】
しかし、ＦＣ―ＨＢＡ１２０Ｂは、ストレージ装置２００のＷＷＮ＃２に接続されているので、ＥＦＩドライバ１７０Ｂは、そのＷＷＮ＃１をキーとして、ＬＵＮ＃ｚの論理ＶＯＬを発見できない（Ｓ５０７００）。【００８６】
そこで、ＥＦＩドライバ１７０Ｂは、次に、ＬＵＩＤ＃Ｃをキーとして、ＬＵＮ＃ｚの論理ＶＯＬを検索する（Ｓ５０８００）。【００８７】
ＬＵＩＤ＃Ｃの論理ＶＯＬは、ＷＷＮ＃２に接続されているストレージ装置２００に存在するので、ＥＦＩドライバ１７０Ｂは、ＬＵＩＤ＃Ｃをキーとして、ＬＵＮ＃ｚの論理ＶＯＬを発見できる。そして、ＥＦＩドライバ１７０Ｂは、そのＬＵＮ＃ｚの論理ＶＯＬへの経路はＷＷＮ＃２であることを認識する（Ｓ５０９００）。【００８８】
そこで、ＥＦＩドライバ１７０Ｂは、Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００Ｄのエントリ「１」のＷＷＮ＃１をＷＷＮ＃２に書き換える（Ｓ５１０００）。この書き換えにより、次回からは、図１０と同様、ＬＵＩＤ＃Ｃに対応するＷＷＮ＃２をキーとして、ＬＵＮ＃ｚの論理ＶＯＬを直ちに発見できる。【００８９】
ＥＦＩドライバ１７０Ｂは、その発見した論理ＶＯＬのＬＵＩＤ＃Ｃを用いて記述したＤｅｖｉｃｅ  Ｐａｔｈを、ＥＦＩ１９０Ｂに送信する（Ｓ５１１００）。【００９０】
ＥＦＩ１９０Ｂは、ＥＦＩドライバ１７０Ｂから送信されたＤｅｖｉｃｅ  Ｐａｔｈと、Ｓ４０３００で実行指示を行ったＤｅｖｉｃｅ  Ｐａｔｈとを比較する（Ｓ５１２００）。【００９１】
この比較の結果、何れのＤｅｖｉｃｅ  ＰａｔｈもＬＵＩＤ＃Ｃに対する記述で一致するので、ＥＦＩ１９０Ｂは、エントリ「１」のＤｅｖｉｃｅ  Ｐａｔｈからブートする（Ｓ５１３００）。【００９２】
図１２は、本実施例に係るＥＦＩドライバ１７０の処理例を示すフローチャートである。【００９３】
現用ＦＣ−ＨＢＡ１２０ＡのＥＦＩドライバ１７０Ａは、図１０のＳ４０６００で、予備ＦＣ―ＨＢＡ１２０ＢのＥＦＩドライバ１７０Ｂは、図１１のＳ５０６００、Ｓ５０７００、Ｓ５０８００、Ｓ５０９００で、この図１２の処理を行ってよい。【００９４】
ＥＦＩドライバ１７０は、Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００の最大エントリ数（例えば「８」）を管理するための変数ｎ（ｎは整数）を「１」に初期化する（Ｓ７０１００）。【００９５】
ＥＦＩドライバ１７０は、Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００のｎ番目のエントリを確認する（Ｓ７０２００）。【００９６】
ＥＦＩドライバ１７０は、そのｎ番目のエントリに設定が存在しない場合（Ｓ７０３００：ＮＯ）、ｎを１つインクリメントし（Ｓ７１０００）、Ｓ７１２００へ進む。【００９７】
ＥＦＩドライバ１７０は、そのｎ番目のエントリに設定が存在する場合（Ｓ７０３００：ＹＥＳ）、そのｎ番目のエントリに設定されているＷＷＮ及びＬＵＮが一致する論理ＶＯＬを検索する（Ｓ７０４００）。そしてＳ７０５００へ進む。【００９８】
Ｓ７０４００の検索において、ＷＷＮ及びＬＵＮが一致する論理ＶＯＬが見つかった場合（Ｓ７０５００：ＹＥＳ）、ＥＦＩドライバ１７０は、その見つかった論理ＶＯＬのＬＵＩＤを、そのｎ番目のエントリに格納する（Ｓ７０６００）。【００９９】
そして、ＥＦＩドライバ１７０は、その見つかった論理ＶＯＬのＬＵＩＤを用いて記述したＤｅｖｉｃｅ  Ｐａｔｈを、Ｂｏｏｔ  Ｏｒｄｅｒ１８００に格納する（Ｓ７１１００）。そして、ＥＦＩドライバ１７０は、変数ｎを１つインクリメントし（Ｓ７１０００）、Ｓ７１２００へ進む。【０１００】
Ｓ７０４００の検索において、ＷＷＮ及びＬＵＮが一致する論理ＶＯＬが見つからなかった場合（Ｓ７０５００：ＮＯ）、ＥＦＩドライバ１７０は、そのｎ番目のエントリに設定されているＬＵＩＤが一致する論理ＶＯＬを検索する（Ｓ７０７００）。そして、Ｓ７０８００へ進む。【０１０１】
Ｓ７０７００の検索において、ＬＵＩＤが一致する論理ＶＯＬが見つかった場合（Ｓ７０８００：ＹＥＳ）、ＥＦＩドライバ１７０は、その見つかった論理ＶＯＬのＷＷＮ及びＬＵＮを、そのｎ番目のエントリに上書きする（Ｓ７０９００）。【０１０２】
そして、ＥＦＩドライバ１７０は、その見つかった論理ＶＯＬのＬＵＩＤを用いて記述したＤｅｖｉｃｅ  Ｐａｔｈを、Ｂｏｏｔ  Ｏｒｄｅｒ１８００に格納する（Ｓ７１１００）。そして、ＥＦＩドライバ１７０は、変数ｎを１つインクリメントし（Ｓ７１０００）、Ｓ７１２００へ進む。【０１０３】
Ｓ７０７００の検索において、ＬＵＩＤが一致する論理ＶＯＬが見つからなかった場合（Ｓ７０８００：ＮＯ）、ＥＦＩドライバ１７０は、変数ｎを１つインクリメントし（Ｓ７１０００）、Ｓ７１２００へ進む。【０１０４】
Ｓ７１２００において、ＥＦＩドライバ１７０は、ｎが８よりも大きい場合（ｎ≦８：ＮＯ）、論理ＶＯＬの検索を終了し、ｎが８以下の場合（ｎ≦８：ＹＥＳ）、Ｓ７０２００に戻り、論理ＶＯＬの検索を続ける。【０１０５】
図１０のＳ４０６００は、当該図１２の処理において、Ｓ７０５００でＷＷＮ及びＬＵＮが一致する論理ＶＯＬが見つかった場合の処理に相当する。【０１０６】
図１１のＳ５０６００、Ｓ５０７００、Ｓ５０８００、Ｓ５０９００は、当該図１２の処理において、Ｓ７０５００でＷＷＮ及びＬＵＮが一致する論理ボリュームが見つからず、Ｓ７０８００でＬＵＩＤが一致する論理ＶＯＬが見つかった場合の処理に相当する。【０１０７】
本実施例によれば、図１１、図１２の例に示すように、現用サーバ１００Ａから予備サーバ１００Ｂにフェイルオーバが行われても、予備サーバ１００Ｂが、正常に起動することができる。仮に、Ｂｏｏｔ  Ｏｒｄｅｒが図５の例のように記述されている場合、予備サーバは、Ｓ５０７００で論理ＶＯＬを見つけることができず、起動に失敗してしまう。【０１０８】
図１０乃至図１２において、まず、ＷＷＮをキーとして論理ＶＯＬを検索し、その検索で見つからなかった場合にＬＵＩＤをキーとして論理ＶＯＬを検索しているのは、ＷＷＮをキーとする方が、ＬＵＩＤをキーとするよりも、高速に検索できる（つまりブート時間が短くなる）からである。故に、本実施例では、図７及び図８に示すように、ＬＵＩＤをキーとして論理ＶＯＬを見つけた場合に、Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ１５００のＷＷＮを、その見つけた論理ＶＯＬへのパス上のＷＷＮに更新し、次回のブート時間が短くなるようにしている。【０１０９】
以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。
【符号の説明】
【０１１０】
１：統合プラットフォーム  １００：サーバ  １２０：ＦＣ−ＨＢＡ  ２００：ストレージ装置  １９０：ＥＦＩ  １７０：ＥＦＩドライバ  １５００：Ｂｏｏｔ  Ｐｒｉｏｒｉｔｙ  １８００：Ｂｏｏｔ  Ｏｒｄｅｒ
【図１】
2017119116.tif 000003
【図２】
2017119116.tif 000004
【図３】
2017119116.tif 000005
【図４】
2017119116.tif 000006
【図５】
2017119116.tif 000007
【図６】
2017119116.tif 000008
【図７】
2017119116.tif 000009
【図８】
2017119116.tif 000010
【図９】
2017119116.tif 000011
【図１０】
2017119116.tif 000012
【図１１】
2017119116.tif 000013
【図１２】
2017119116.tif 000014
【国際調査報告】
2017119116.tif 000015
2017119116.tif 000016