JP2015069524A - 情報処理装置、ストレージ制御装置、及びプログラム - Google Patents

Abstract

【課題】複数のオペレーティングシステムによって管理されるそれぞれのデバイスに対応するデバイスの保守制御の効率化を図る。【解決手段】本情報処理装置は、第１ＯＳ１２によって管理される第１デバイス２０ａ，２０ｂと、第２ＯＳ１３によって管理される第２デバイス３０ａ，３０ｂと、処理部とを備える。前記処理部は、第１ＯＳ１２と第２ＯＳ１３とを動作させ、第１ＯＳ１２に対して、第１デバイス２０ａ，２０ｂに対応する第１保守ドライバ２１ａ，２１ｂをロードさせ、第１保守ドライバ２１ａ，２１ｂに第１デバイス２０ａ，２０ｂの保守制御を実行させ、第１ＯＳ１２に対して、第２デバイス３０ａ，３０ｂに対応する第２保守ドライバ３２ａ，３２ｂをロードさせ、第２保守ドライバ３２ａ，３２ｂに第２デバイス３０ａ，３０ｂの保守制御を実行させる。【選択図】図３

Description

本発明は、情報処理装置、ストレージ制御装置、及びプログラムに関する。

ネットワークストレージシステムとして、ＮＡＳ（Network Attached Storage）やＳＡＮ（Storage Area Network）が知られている
既存のイーサネット（登録商標）ネットワークに接続するＮＡＳは、ＳＡＮに比べて管理は簡単だが、性能面で劣り、又、容量不足に陥ることが多い。一方、ＳＡＮは、一般にＮＡＳに比べて高速で、より多くのデータ保存が可能だが高価である。
これらのＮＡＳとＳＡＮとのそれぞれの長所をうまく組み合わせ、データ保存の効率向上およびコスト削減を図るために、ＳＡＮとＮＡＳとの統合が実現されつつある。

このとき、ＳＡＮ用デバイスは、ＳＡＮ用オペレーティングシステム（Operating System；ＯＳ）の制御下に置かれ、ＮＡＳ用デバイスは、ＮＡＳ用ＯＳの制御下に置かれる。しかし、両ＯＳ制御下のデバイスは、統合ストレージ装置のハードウェアとして実装されているので、各デバイスに対する保守は、共通の保守手順で行ないたい。なぜならば、ＯＳ毎に保守ガイド画面の構成や保守手順が異なると、ユーザにとって使用し難いためである。

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

したがって、複数のＯＳに対して保守制御機能を二重に実装しなければならず非効率的であるという課題がある。

一つの側面で、本発明は、複数のオペレーティングシステムによって管理されるそれぞれのデバイスに対応するデバイスの保守制御の効率化を図ることを目的とする。
なお、前記目的に限らず、後述する発明を実施するための最良の形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本件の他の目的の一つとして位置付けることができる。

本件の情報処理装置は、第１オペレーティングシステムによって管理される第１デバイスと、第２オペレーティングシステムによって管理される第２デバイスと、処理部とを備える。前記処理部は、前記第１オペレーティングシステムと前記第２オペレーティングシステムとを動作させ、前記第１オペレーティングシステムに対して、前記第１デバイスに対応する第１保守ドライバをロードさせ、前記第１保守ドライバに前記第１デバイスの保守制御を実行させ、前記第１オペレーティングシステムに対して、前記第２デバイスに対応する第２保守ドライバをロードさせ、前記第２保守ドライバに前記第２デバイスの保守制御を実行させる。

一実施形態によれば、複数のオペレーティングシステムによって管理されるそれぞれのデバイスに対応するデバイスの保守制御の効率化を図ることができる。

本実施形態のストレージ制御装置（情報処理装置）を含むストレージ装置のハードウェア構成を模式的に示す図である。 シングルＯＳのストレージ制御装置（情報処理装置）におけるＯＳを模式的に示す図である。 本実施形態のストレージ制御装置（情報処理装置）におけるハイパバイザ上の複数のＯＳを模式的に示す図である。 図１に示すストレージ制御装置（情報処理装置）における保守ドライバ（第２保守ドライバ）の動作を説明するフローチャートである。 図１に示すストレージ制御装置（情報処理装置）による起動シーケンスを説明する図である。 図１に示すストレージ制御装置（情報処理装置）による活性増設シーケンスを説明する図である。 図１に示すストレージ制御装置（情報処理装置）によるLinux稼動中の活性交換シーケンスを説明する図である。 図１に示すストレージ制御装置（情報処理装置）によるLinux停止中の活性交換シーケンスを説明する図である。

以下に、図面を参照し、本願の開示する情報処理装置、ストレージ制御装置、及びプログラムの実施形態について、詳細に説明する。ただし、以下に示す実施形態は、あくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能を含むことができる。そして、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔１〕本実施形態のストレージ制御装置（情報処理装置）の構成
まず、図２を参照しながら、シングルＯＳのストレージ制御装置（情報処理装置）におけるＯＳについて説明する。なお、図２は、当該ストレージ制御装置におけるＯＳを模式的に示す図である。

図２では、例えば、ストレージ制御装置のＣＰＵ（Central Processing Unit）においてVxWorks（登録商標）のシングルＯＳ１１２が動作する場合が示されている。VxWorksは、ＳＡＮ制御を行なうＳＡＮ用ＯＳの一例である。また、図２では、ＯＳ１１２には、VxWorks用のデバイス１２０ａ〜１２０ｃが接続されている。VxWorks用のデバイス１２０ａ〜１２０ｃは、例えばＮＩＣ（Network Interface Card），ＦＣ（Fibre Channel）カードであり、ＯＳ１１２によって管理される。

このとき、ＯＳ１１２は、デバイス１２０ａ〜１２０ｃ用のデバイスドライバ１２１ａ〜１２１ｃを有している。ここで用いられるデバイスドライバ１２１ａ〜１２１ｃは、フル機能ドライバである。フル機能ドライバは、起動時や保守時のデバイスの制御に使用される保守機能と、運用時のデバイス１２０ａ〜１２０ｃの制御に使用されるデバイスドライバ機能とを有する。ここで、保守機能は、各デバイス１２０ａ〜１２０ｃの状態を通知するなどの保守制御に有用な機能を実現する。また、デバイスドライバ機能とは、デバイス１２０ａ〜１２０ｃが例えばＮＩＣであれば、通信制御がデバイス１２０ａ〜１２０ｃをデバイスとして使用する機能にあたる。

こようなＳＡＮ用ＯＳ１１２を備えたＳＡＮ装置にＮＡＳ（Network Attached Storage）機能を追加するには、以下の手法が用いられる。その手法では、仮想化ＯＳ（ハイパバイザシステム）を導入し、一つのシステムハードウェア上にVxWorksとLinux（登録商標）との二つのＯＳを搭載し、一方のＯＳ（Linux）にＮＡＳ機能（例えばＮＦＳ（Network File System），Samba）を実装することである。これにより、ＳＡＮ機能とＮＡＳ機能との両方をもつ統合ストレージ装置（Unified Storage）が実現される。

ＮＡＳ機能のソフトウェアは、Linux上に安定したものがあるので、上記手法は合理的な手法である。ただし、ＮＡＳ機能によって使用されるディスクは、VxWroks側にあるので、Linuxで受け取ったデータは、ＳＡＮ機能によってVxWorks側のディスクに書き込まれる。

このとき、ＮＡＳ用に新たにデバイス（例えばＮＩＣ）を追加すると、当該デバイスは、Linuxの制御下に置かれる。しかし、当該デバイスは統合ストレージ装置のハードウェアとして実装されているので、当該デバイスに対する保守は、当該デバイスを追加する前のVxWorksによる保守手順で行ないたい。なぜならば、ＯＳ毎に保守ガイド画面の構成や保守手順が異なると、ユーザにとって使用し難いためである。

つまり、ＮＡＳ用に追加したデバイスについても、VxWorks上に実装されている保守制御機能と同じものが必要になる。そのため、
（１）保守に関する制御は、全てVxWorksで行なうか、もしくは、
（２）Linux側に、VxWorksに実装された保守制御機能と同じ保守制御機能を実装する、
必要がある。

しかしながら、上記（１）のように保守に関する制御を全てVxWorksで行なう場合、VxWorks側で必要とする情報の全てをLinuxが採取してVxWorksに通知しなければならない。また、例えばLinuxが停止している場合、VxWorksが望む情報を、VxWorksが望むタイミングで採取することができない。

また、上記（２）のように、Linux側に、VxWorksに実装された保守制御機能と同じ保守制御機能を実装する場合、VxWorksとLinuxとの両方でしたがって、複数のＯＳに対して共通の保守制御機能を二重に開発実装しなければならず非効率的である。

さらに、上記（１）および（２）に共通する課題として、以下のような課題がある。上述した統合ストレージ装置のようなシステム構成では、ディスクはVxWorks側で管理されており、二つのＯＳのうちLinuxだけが生き残ってもディスクがなくLinuxは機能できないため、Linuxだけが生き残ることはない。しかし、ディスクはVxWorks側で管理されているので、VxWorksだけが生き残る場合はある。その場合、Linuxが停止しているときでも、Linux側のデバイスの保守を可能にすることが望ましい。

以上の点から、上述した統合ストレージ装置のようなシステム構成において、Linux側に追加されるデバイスについての保守機能を、Linux側にもたせることは非合理であるといえる。

以下、図１を参照しながら、本実施形態のストレージ制御装置（情報処理装置）１００を含むストレージ装置１について説明する。なお、図１は、本実施形態のストレージ制御装置１００を含むストレージ装置１のハードウェア構成を模式的に示す図である。

本ストレージ装置１は、ドライブエンクロージャ（ＤＥ：Drive Enclosure；ストレージユニット）３００に格納された記憶装置３１０を仮想化して、仮想ストレージ環境を形成する。そしてストレージ装置１は、仮想ボリュームを上位装置である図示しないホスト装置に提供する。

本ストレージ装置１は、１以上のホスト装置（図示略）に対して通信可能に接続されている。ホスト装置とストレージ装置１とは、後述するＣＡ（Communication Adapter）１０１，１０２により接続されている。

ホスト装置は、例えば、サーバ機能をそなえた情報処理装置であり、本ストレージ装置１との間において、ＮＡＳやＳＡＮのコマンドを送受信する。このホスト装置は、例えば、ストレージ装置１に対してＮＡＳにおけるリード／ライト等のディスクアクセスコマンドを送信することにより、ストレージ装置１が提供するボリュームにデータの書き込みや読み出しを行なう。

そして、本ストレージ装置１は、ホスト装置からボリュームに対して行なわれる入出力要求（例えば、リードコマンドやライトコマンド）に応じて、このボリュームに対応する実ストレージに対して、データの読み出しや書き込み等の処理を行なう。なお、ホスト装置からの入出力要求のことをＩ／ＯコマンドもしくはＩ／Ｏ要求という場合がある。

本ストレージ装置１は、図１に示すように、複数（本実施形態では２つ）のＣＭ（Controller Module）１００を含むコントローラエンクロージャ４００と、１つ以上（図１に示す例では１つ）のドライブエンクロージャ３００とをそなえる。
ドライブエンクロージャ（ストレージユニット）３００は、１以上（図１に示す例では４つ）の記憶装置（物理ディスク；ストレージユニット）３１０を搭載可能であり、これらの記憶装置３１０の記憶領域（実ボリューム，実ストレージ）を、本ストレージ装置１に対して提供する。

例えば、ドライブエンクロージャ３００は、複数段のスロット（図示略）をそなえ、これらのスロットに、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の記憶装置３１０を挿入することにより、実ボリューム容量を随時変更することができる。又、複数の記憶装置３１０を用いてＲＡＩＤ（Redundant Arrays of Inexpensive Disks）を構成することができる。

ドライブエンクロージャ３００は、各ＣＭ１００における複数（本実施形態では２つ）のデバイスアダプタ（Device Adapter：ＤＡ）１０３のそれぞれに接続されている。そして、ドライブエンクロージャ３００には、各ＣＭ１００からアクセスして、データの書き込みや読み出しを行なうことができる。すなわち、ドライブエンクロージャ３００の記憶装置３１０に対して、各ＣＭ１００を接続することにより、記憶装置３１０へのアクセス経路が冗長化される。

コントローラエンクロージャ４００は、１以上（図１に示す例では２つ）のＣＭ１００を備える。
各ＣＭ１００は、ストレージ装置１内の動作を制御するコントローラ（ストレージ制御装置）であり、ホスト装置から送信されるＩ／Ｏコマンドに従って、ドライブエンクロージャ３００の記憶装置３１０へのアクセス制御等、各種制御を行なう。また、各ＣＭ１００は互いにほぼ同様の構成を有している。
なお、図中、同一の符号は同一もしくは略同一の部分を示しているので、その詳細な説明は省略する。

各ＣＭ１００は二重化されており、通常は、一方のＣＭ１００がプライマリとして各種制御を行なう。しかし、このプライマリＣＭ１００の故障時には、セカンダリのＣＭ１００がプライマリとして動作を引き継ぐ。
各ＣＭ１００はＣＡ１０１，１０２を介して、それぞれホスト装置に接続される。そして、各ＣＭ１００は、ホスト装置から送信されるリード／ライト等のコマンドを受信し、ＤＡ１０３等を介して記憶装置３１０の制御を行なう。また、各ＣＭ１００は、ＰＣＩ (Peripheral Component Interconnect) Express 等の図示しないインタフェースを介して相互に接続されている。

ＣＭ１００は、図１に示すように、ＣＡ１０１，１０２と複数（図１に示す例では２つ）のＤＡ１０３，１０３とをそなえるとともに、ＣＰＵ（Central Processing Unit）１１０，メモリ１０６，ＳＳＤ１０７，ＩＯＣ１０８およびスロット１０９をそなえる。
ＣＡ１０１，１０２は、ホスト装置等から送信されたデータを受信したり、ＣＭ１００から出力するデータをホスト装置等に送信する。すなわち、ＣＡ１０１，１０２は、ホスト装置等の外部装置との間でのデータの入出力（Ｉ／Ｏ）を制御する。

ＣＡ１０１は、ＮＡＳを介してホスト装置と通信可能に接続するネットワークアダプタであり、例えば、ＬＡＮ（Local Area Network）インタフェース等である。
各ＣＭ１００は、このＣＡ１０１により図示しない通信回線を介してホスト装置等とＮＡＳにより接続され、Ｉ／Ｏコマンドの受信やデータの送受信等を行なう。図１に示す例においては、各ＣＭ１００に２つのＣＡ１０１，１０１がそなえられている。

ＣＡ１０２は、ＳＡＮを介してホスト装置と通信可能に接続するネットワークアダプタであり、例えば、ｉＳＣＳＩインタフェースやＦＣインタフェースである。
ＣＭ１００は、ＣＡ１０２により図示しない通信回線を介してホスト装置等とＳＡＮにより接続され、Ｉ／Ｏコマンドの受信やデータの送受信等を行なう。図１に示す例においては、各ＣＭ１００に１つのＣＡ１０２がそなえられている。

ＤＡ１０３は、ドライブエンクロージャ３００や記憶装置３１０等と通信可能に接続するためのインタフェースである。ＤＡ１０３は、ドライブエンクロージャ３００の記憶装置３１０が接続され、各ＣＭ１００は、ホスト装置から受信したＩ／Ｏコマンドに基づき、記憶装置３１０に対するアクセス制御を行なう。

各ＣＭ１００は、ＤＡ１０３を介して、記憶装置３１０に対するデータの書き込みや読み出しを行なう。また、図１に示す例においては、各ＣＭ１００に２つのＤＡ１０３，１０３がそなえられている。そして、各ＣＭ１００において、各ＤＡ１０３にドライブエンクロージャ３００が接続されている。
これにより、ドライブエンクロージャ３００の記憶装置３１０には、各ＣＭ１００からデータの書き込みや読み出しを行なうことができる。

ＳＳＤ１０７は、ＣＰＵ１１０が実行するプログラムや種々のデータ等を格納する記憶装置である。
メモリ１０６は、種々のデータやプログラムを一時的に格納する記憶装置であり、図示しないメモリ領域とキャッシュ領域とをそなえる。キャッシュ領域は、ホスト装置から受信したデータや、ホスト装置に対して送信するデータを一時的に格納する。メモリ領域には、ＣＰＵ１１０がプログラムを実行する際に、データやプログラムを一時的に格納・展開して用いる。なお、プログラムは、ＣＰＵ１１０を、図３を参照しながら後述する処理部として機能させるアプリケーションプログラムを含む。

ＩＯＣ（Input Output Controller）１０８は、ＣＭ１００内におけるデータ転送を制御する制御装置であり、例えば、メモリ１０６に格納されたデータをＣＰＵ１１０を介することなく転送させるＤＭＡ転送（Direct Memory Access）を実現する。
スロット１０９は、ＮＩＣ等のデバイス２０ａ，２０ｂ，３０ａ，３０ｂを挿入接続されるもので、必要に応じて、デバイス２０ａ，２０ｂ，３０ａ，３０ｂを挿抜可能に構成されている。図１では、スロット１０９には一つだけ図示されているが、実際には、２以上のスロット１０９がそなえられ、各スロット１０９に対し、一つのカード状デバイスが挿抜される。

ＣＰＵ１１０は、種々の制御や演算を行なう処理装置であり、マルチコアプロセッサ（マルチＣＰＵ）である。ＣＰＵ１１０は、ＳＳＤ１０７等に格納されたＯＳやプログラムを実行することにより、図３を参照しながら後述する処理部としての機能を含む種々の機能を実現する。

ＣＰＵ１１０は、仮想化ＯＳであるハイパバイザ（Hypervisor）１１（図３参照）を実行し、このハイパバイザ１１上で複数の仮想マシン（Virtual Machine；ＶＭ）を実行することで複数のＯＳ１２，１３（図３参照）を実行させることができる。複数のゲストＯＳ１２，１３はＣＰＵ１１０やメモリ１０６，ＳＳＤ１０７，スロット１０９等のハードウェア資源を共有することができる。
なお、各ＣＭ１００において複数のＣＰＵ１１０を備え、これらの複数のＣＰＵ１１０上でハイパバイザ１１を実行してもよい。

次に、図３を参照しながら、本実施形態の各ＣＭ１００におけるハイパバイザ１１上の複数（本実施形態では２つ）のＯＳ１２，１３について説明する。図３は、本実施形態の各ＣＭ１００におけるハイパバイザ１１上の複数のＯＳ１２，１３を模式的に示す図である。本実施形態においては、図３に示すように、ハイパバイザ１１上で、ＳＡＮ用ＯＳ（第１ＯＳ）１２とＮＡＳ用ＯＳ（第２ＯＳ）１３とを実行する。

ＳＡＮ用ＯＳ１２は、ＳＡＮ制御を行なうもので、ＮＩＣ，ＦＣカード等の第１デバイス２０ａ，２０ｂを管理する。なお、図３では、２つの第１デバイス２０ａ，２０ｂが図示されているが、本発明はこれに限定されるものではなく、第１デバイスは、１つだけそなえられてもよいし、３以上そなえられてもよい。

ＮＡＳ用ＯＳ１３は、ＮＡＳ制御を行なうもので、ＮＩＣ等の第２デバイス３０ａ，３０ｂを管理する。なお、図３では、２つの第２デバイス３０ａ，３０ｂが図示されているが、本発明はこれに限定されるものではなく、第２デバイスは、１つだけそなえられてもよいし、３以上そなえられてもよい。

そして、本実施形態の各ＣＭ１００におけるＣＰＵ１１０は、以下のような処理部として機能する。
つまり、当該処理部は、ＳＡＮ用ＯＳ１２とＮＡＳ用ＯＳ１３とを動作させる。また、当該処理部は、ＳＡＮ用ＯＳ１２に対して、第１デバイス２０ａ，２０ｂにそれぞれ対応する第１保守ドライバ２１ａ，２１ｂをロードさせ、当該第１保守ドライバ２１ａ，２１ｂにそれぞれ第１デバイス２０ａ，２０ｂの保守制御を実行させる。さらに、当該処理部は、ＳＡＮ用ＯＳ１２に対して、第２デバイス３０ａ，３０ｂにそれぞれ対応する第２保守ドライバ３２ａ，３２ｂをロードさせ、当該第２保守ドライバ３２ａ，３２ｂにそれぞれ第２デバイス３０ａ，３０ｂの保守制御を実行させる。

また、当該処理部は、ＮＡＳ用ＯＳ１３の動作の停止中に、ＳＡＮ用ＯＳ１２に対して、第２保守ドライバ３２ａ，３２ｂを用いて、それぞれ、第２デバイス３０ａ，３０ｂに係る情報を取得し、第２デバイス３０ａ，３０ｂの保守制御を実行させる。さらに、当該処理部は、ＮＡＳ用ＯＳ１３の動作の停止中に、ＳＡＮ用ＯＳ１２に対して、第２保守ドライバ３２ａ，３２ｂを用いて、それぞれ、第２デバイス３０ａ，３０ｂの設定制御を実行させる。

また、第１保守ドライバ２１ａ，２１ｂは、ＳＡＮ用ＯＳ１２が行なう第１デバイス２０ａ，２０ｂの運用時の制御に使用される制御機能（デバイスドライバ機能）を含んでいる。つまり、第１保守ドライバ２１ａ，２１ｂは、フル機能ドライバであり、起動時や保守時のデバイスの制御に使用される保守機能と、運用時の第１デバイス２０ａ，２０ｂの制御に使用されるデバイスドライバ機能（制御ドライバ）とを有する。ここで、保守機能は、第１デバイス２０ａ，２０ｂの状態を通知するなどの保守制御に有用な機能を実現する。また、デバイスドライバ機能とは、第１デバイス２０ａ，２０ｂが例えばＮＩＣであれば、通信制御が第１デバイス２０ａ，２０ｂをデバイスとして使用する機能にあたる。

さらに、上記処理部は、ＮＡＳ用ＯＳ１３に対して、第２デバイス３０ａ，３０ｂにそれぞれ対応する制御ドライバ３１ａ，３１ｂをロードさせる。ここで、制御ドライバ３１ａ，３１ｂは、ＮＡＳ用ＯＳ１３が行なう第２デバイス３０ａ，３０ｂの運用時の制御に使用されるものである。したがって、ＳＡＮ用ＯＳ１２に対してロードされた第２保守ドライバ３２ａ，３２ｂは、それぞれ、第１デバイス２０ａ，２０ｂの状態を通知するなどの保守制御に有用な機能を実現する保守機能のみを有する。また、ＮＡＳ用ＯＳ１３に対してロードされた制御ドライバ３１ａ，３１ｂは、それぞれ、運用時の第２デバイス３０ａ，３０ｂの制御に使用されるデバイスドライバ機能を有する。

なお、図３に示すように、本実施形態の各ＣＭ（ストレージ制御装置）１００のＣＰＵ１１０においては、ハイパバイザ１１上に第１仮想マシンおよび第２仮想マシンが構築される。そして、第１仮想マシンには、ＳＡＮ制御を行なうＳＡＮ用ＯＳ（例えばVxWorks；第１ＯＳ）１２が搭載され、第２仮想マシンには、ＮＡＳ制御を行なうＮＡＳ用ＯＳ（例えばLinux；第２ＯＳ）１３が搭載される。

また、図３では、ＳＡＮ用ＯＳ１２には、VxWorks用のデバイス（第１デバイス）２０ａ，２０ｂが接続されている。VxWorks用のデバイス２０ａ，２０ｂは、例えばＮＩＣ，ＦＣカードであり、ＳＡＮ用ＯＳ１２によって管理される。同様に、図１では、ＮＡＳ用ＯＳ１３には、Linux用のデバイス（第２デバイス）３０ａ，３０ｂが接続されている。Linux用のデバイス３０ａ，３０ｂは、例えばＮＩＣであり、ＮＡＳ用ＯＳ１３によって管理される。

上述の構成により、ＳＡＮ用ＯＳ１２は、第２保守ドライバ３２ａ，３２ｂの保守機能を用いて、それぞれ、第２デバイス３０ａ，３０ｂに係る情報を取得し、第２デバイス３０ａ，３０ｂの保守制御を行なう。

また、ＳＡＮ用ＯＳ１２は、第２保守ドライバ３２ａ，３２ｂを用いて、第２デバイス３０ａ，３０ｂの設定制御、例えばＰＣＩ Configuration（ＰＣＩ構成）設定／リソース配置設定を行なう。

つまり、ＳＡＮ用ＯＳ（VxWorks）１２は、ＳＡＮ用ＯＳ１２上の制御ドライバ３１ａ，３１ｂを通して、ＮＡＳ用ＯＳ（Linux）１３の管理下における第２デバイス３０ａ，３０ｂの情報を取得する。

これにより、ＳＡＮ用ＯＳ（VxWorks）１２は、取得した情報を用い、ＳＡＮ用ＯＳ（VxWorks）１２の管理下における第１デバイス２０ａ，２０ｂに対する保守制御等の手順と同様にして、ＮＡＳ用ＯＳ（Linux）１３の管理下における第２デバイス３０ａ，３０ｂに対する保守制御等を行なう。このとき、保守制御等の仲立ちはハイパバイザ１１によって行なわれる。

また、本実施形態では、ＮＡＳ用ＯＳ１３であるLinux側の第２デバイス３０ａ，３０ｂの設定を、ＳＡＮ用ＯＳ１２であるVxWorks側から制御することができる。ここで、第２デバイス３０ａ，３０ｂとしてはＰＣＩ-Expressデバイスを想定している。ＰＣＩ-ExpressのリソースはLinuxとVxWorksとで共用されており、リソースを自由に設定するとリソースの衝突が生じるため、Linuxは、ＰＣＩ-Expressのリソースを自由に設定することはできないようになっている。しかし、本実施形態では、Linuxの起動前にＰＣＩ構成設定を済ませることで、リソースの衝突を発生させることなく、Linux側のリソース使用を制御することができる。

〔２〕本実施形態のストレージ制御装置（情報処理装置）の動作
次に、上述のごとく構成された本実施形態のストレージ制御装置（情報処理装置）であるＣＭ１００の動作について、図４〜図８を参照しながら説明する。
まず、図４に示すフローチャート（ステップＳ１〜Ｓ５）に従って、本実施形態のＣＭ１００における第２保守ドライバ３２ａ，３２ｂの動作について説明する。

第２保守ドライバ３２ａ，３２ｂは、ＳＡＮ用ＯＳ１２において情報採取の要求の有無を判断する（ステップＳ１）。第２保守ドライバ３２ａ，３２ｂは、ＳＡＮ用ＯＳ１２において情報採取の要求を受けると（ステップＳ１のＹＥＳルート）、それぞれ第２デバイス３０ａ，３０ｂに係る情報を取得する（ステップＳ２）。そして、保守ドライバ３２ａ，３２ｂは、採取した情報を要求元に受け渡したり、保守用の情報としてメモリ４０等に記憶する（ステップＳ３）。この後、第２保守ドライバ３２ａ，３２ｂは、ステップＳ１の処理に戻る。

また、情報採取の要求が無い場合（ステップＳ１のＮＯルート）、第２保守ドライバ３２ａ，３２ｂは、ＳＡＮ用ＯＳ１２において設定要求の有無を判断する（ステップＳ４）。第２保守ドライバ３２ａ，３２ｂは、ＳＡＮ用ＯＳ１２において情報採取の要求を受けると（ステップＳ４のＹＥＳルート）、要求元からの要求内容に従って、それぞれ第２デバイス３０ａ，３０ｂの設定制御、例えばＰＣＩ構成設定、あるいは、リソース配置設定を行なう（ステップＳ５）。この後、第２保守ドライバ３２ａ，３２ｂは、ステップＳ１の処理に戻る。なお、設定要求が無い場合（ステップＳ４のＮＯルート）、第２保守ドライバ３２ａ，３２ｂは、ステップＳ１の処理に戻る。

次に、図５を参照しながら、図１に示すストレージ制御装置（情報処理装置）であるＣＭ１００による起動シーケンス（ステップＡ１〜Ａ１０，Ａ１′，Ａ２′，Ａ６′，Ａ１０′）について説明する。

起動時には、第１ＯＳ（以下VxWorksという）１２Ａおよび第２ＯＳ（以下Linuxという）１３の電源をオンする（ステップＡ１，Ａ１′）。これにより、VxWorksの起動を開始するとともに（ステップＡ２）、Linuxも起動するが、Linuxについては、一旦起動した後、一時的に停止する（ステップＡ２′）。

この後、VxWorksにおいてＰＣＩスキャンが開始される（ステップＡ３）。そして、ＰＣＩスキャンの結果に従って、第１保守ドライバ（フル機能ドライバ）２１ａ，２１ｂや第２保守ドライバ（保守機能）３２ａ，３２ｂがロードされる。また、Linux管理下の第２デバイス３０ａ，３０ｂについて、ＰＣＩ構成の設定およびデバイス情報の採取が、第２保守ドライバ３２ａ，３２ｂを用いて行なわれ、採取された情報が、保守用の情報としてメモリ１０６等に記憶される（ステップＡ４）。

以上で、VxWorks側のＰＣＩデバイスの初期設定を終了し（ステップＡ５）、Linuxの停止状態（suspend状態）を解除することで（ステップＡ６）、Linuxの起動が再開される（ステップＡ６′）。
これに伴い、LinuxにおいてＰＣＩスキャンが開始される（ステップＡ７）。そして、ＰＣＩスキャンの結果に従って、制御ドライバ（デバイスドライバ機能）３１ａ，３１ｂがロードされる。このとき、ＰＣＩ構成は設定済みであるので、それ以外の制御に必要な設定が実行されるとともに、デバイス情報が採取される（ステップＡ８）。

以上で、Linux側のＰＣＩデバイスの初期設定を終了し（ステップＡ９）、VxWorksおよびLinuxは、運用を開始する（ステップＡ１０，Ａ１０′）。
次に、図６を参照しながら、図１に示すストレージ制御装置（情報処理装置）であるＣＭ１００による活性増設シーケンス（ステップＢ１〜Ｂ１０，Ｂ１′，Ｂ１０′）について説明する。

活性増設時には、VxWorksが、ＰＣＩ-Expressデバイス（第２デバイス）のマウントを検出する（ステップＢ１）。このとき、Linuxは、デバイスのマウントに気付かずマウントを検出しない（ステップＢ１′）。
VxWorksは、ＰＣＩ-Expressデバイスの電源をオンし（ステップＢ２）、ＰＣＩスキャンを開始する（ステップＢ３）。

そして、ＰＣＩスキャンの結果に従って、マウントされたデバイス用の第２保守ドライバ（保守機能のみ）がロードされる。また、Linux側でマウントされた第２デバイスについて、ＰＣＩ構成の設定およびデバイス情報の採取が、第２保守ドライバを用いて行なわれ、採取された情報が、保守用の情報としてメモリ１０６等に記憶される（ステップＢ４）。

以上で、VxWorks側のＰＣＩデバイスの初期設定を終了し（ステップＢ５）、Linuxに対し、マウントされたデバイスの組込みの開始通知が行なわれる（ステップＢ６）。
これに伴い、LinuxにおいてＰＣＩスキャンが開始される（ステップＢ７）。そして、ＰＣＩスキャンの結果に従って、マウントされた第２デバイス用の制御ドライバ（デバイスドライバ機能）がロードされる。このとき、ＰＣＩ構成は設定済みであるので、それ以外の制御に必要な設定が実行されるとともに、デバイス情報が採取される（ステップＢ８）。

以上で、Linux側のＰＣＩデバイスの初期設定を終了し（ステップＢ９）、VxWorksおよびLinuxは、新たなデバイスを活性増設した状態で運用を開始する（ステップＢ１０，Ｂ１０′）。
次に、図７を参照しながら、図１に示すストレージ制御装置（情報処理装置）であるＣＭ１００によるLinux稼動中の活性交換シーケンス（ステップＣ１〜Ｃ８）について説明する。

Linux稼動中にデバイス（第２デバイス）の活性交換を行なう場合、VxWorksからLinuxへＰＣＩ-Expressデバイスのデグレード通知が行なわれる（ステップＣ１）。デグレード通知を受けたLinuxは、交換対象のデバイスのドライバ（第２ドライバ）をアンロードし（ステップＣ２）、デグレード完了通知をVxWorksへ行なう（ステップＣ３）。

Linuxからデグレード完了通知を受けたVxWorksは、交換対象のデバイスのドライバ（第２保守ドライバ）をアンロードし（ステップＣ４）、交換対象のＰＣＩ-Expressデバイスの電源をオフにする（ステップＣ５）。
これにより、ＰＣＩ-Expressデバイスの保守準備が完了し（ステップＣ６）、交換対象のＰＣＩ-Expressデバイスの挿抜が実行される（ステップＣ７）。つまり、交換対象のデバイスが抜き取られ、新たなデバイスが挿し込まれる。新たなデバイスの挿し込みに応じて、図６の活性増設と同じ処理（ステップＢ１〜Ｂ１０，Ｂ１′，Ｂ１０′）が行なわれ（ステップＣ８）、Linux稼動中の活性交換が完了する。

次に、図８を参照しながら、図１に示すストレージ制御装置（情報処理装置）であるＣＭ１００によるLinux停止中の活性交換シーケンス（ステップＤ１〜Ｄ１０）について説明する。
Linux停止中にデバイス（第２デバイス）の活性交換を行なう場合、VxWorksは、交換対象のデバイスのドライバ（第２保守ドライバ）をアンロードし（ステップＤ１）、交換対象のＰＣＩ-Expressデバイスの電源をオフにする（ステップＤ２）。

これにより、ＰＣＩ-Expressデバイスの保守準備が完了し（ステップＤ３）、交換対象のＰＣＩ-Expressデバイスの挿抜が実行される（ステップＤ４）。つまり、交換対象のデバイスが抜き取られ、新たなデバイスが挿し込まれる。
新たなデバイスの挿し込みに応じて、VxWorksが、新たなＰＣＩ-Expressデバイス（第２デバイス）のマウントを検出する（ステップＤ５）。これに伴い、VxWorksは、ＰＣＩ-Expressデバイスの電源をオンし（ステップＤ６）、ＰＣＩスキャンを開始する（ステップＤ７）。

そして、ＰＣＩスキャンの結果に従って、マウントされた第２デバイス用の第２保守ドライバがロードされる。また、マウントされた第２デバイスについて、ＰＣＩ構成の設定およびデバイス情報の採取が、第２保守ドライバを用いて行なわれ、採取された情報が、保守用の情報としてメモリ１０６等に記憶される（ステップＤ８）。
以上で、VxWorks側のＰＣＩデバイスの初期設定を終了し（ステップＤ９）、VxWorksは、Linuxの復旧待ちとなり（ステップＤ１０）、Linux停止中の活性交換が完了する。

〔３〕本実施形態の効果
本実施形態によれば、ハイパバイザ１１上の第１ＯＳ（VxWorks）１２に、第２ＯＳ（Linux）１３に接続された第２デバイス３０ａ，３０ｂ用の第２保守ドライバ３１ａ，３１ｂを備えることで、第１ＯＳ１２に接続された第１デバイス２０ａ，２０ｂの保守制御手順と同様の手順で、第１ＯＳ１２から、第２ＯＳ１３管理下の第２デバイス３０ａ，３０ｂの保守制御等を行なうことが可能になる。

これにより、ストレージ制御装置（情報処理装置）であるＣＭ１００においてハイパバイザ１１を使用して新しいＯＳを搭載し当該ＯＳに新機能を追加して機能強化を図った際、追加した新機能の保守インタフェースを効率的に実装することができる。また、追加した新機能の保守インタフェースとして、従来と同じ保守ガイド画面の構成や保守手順を用いることでき、ユーザは、追加した新機能に対しても違和感なく保守等の操作を行なうことができる。つまり、複数のＯＳに対して保守制御機能を二重に実装する必要がなく、複数のＯＳによって管理されるそれぞれのデバイスに対応する保守制御が効率化される。

また、第１ＯＳ（VxWorks）１２は、第２保守ドライバ３２ａ，３２ｂを用いて第２ＯＳ（Linux）１３管理下の第２デバイス３０ａ，３０ｂの情報を採取することができる。したがって、第２ＯＳ（Linux）１３が停止している場合でも、第１ＯＳ（VxWorks）１２が望む情報を、第１ＯＳ（VxWorks）１２が望むタイミングで採取することができる。さらに、図７を参照しながら上述したように、第２ＯＳ（Linux）１３が停止しているときでも、第２ＯＳ（Linux）１３側のデバイス３０ａ，３０ｂの保守制御等を行なうことが可能になる。

〔４〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。

上述した実施形態では、情報処理装置が、統合ストレージ装置用のストレージ制御装置である場合について説明したが、本発明は、これに限定されるものではない。本発明は、ハイパバイザ上に複数のＯＳを実装し各ＯＳにデバイスを接続するよう構成された情報処理装置であれば、上述した実施形態と同様に適用され、上述した実施形態と同様の作用効果を得ることができる。

また、上述した実施形態では、第１ＯＡがVxWorksであり、第２ＯＡがLinuxである場合について説明したが、本発明は、これに限定されるものではない。さらに、上述した実施形態では、第１デバイスおよび第２デバイスが２個ずつ備えられる場合について説明したが、本発明は、これに限定されるものではない。

上述したＣＰＵ１１０による処理部としての機能の全部もしくは一部は、コンピュータ（ＭＰＵ（Micro-Processing Unit），ＣＰＵ，各種端末を含む）が所定のプログラムを実行することによって実現されてもよい。そのプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷなど），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷなど），ブルーレイディスク等のコンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。

〔５〕付記
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
第１オペレーティングシステムによって管理される第１デバイスと、
第２オペレーティングシステムによって管理される第２デバイスと、
前記第１オペレーティングシステムと前記第２オペレーティングシステムとを動作させ、前記第１オペレーティングシステムに対して、前記第１デバイスに対応する第１保守ドライバをロードさせ、前記第１保守ドライバに前記第１デバイスの保守制御を実行させ、前記第１オペレーティングシステムに対して、前記第２デバイスに対応する第２保守ドライバをロードさせ、前記第２保守ドライバに前記第２デバイスの保守制御を実行させる処理部と 、
を備えることを特徴とする情報処理装置。

（付記２）
前記処理部は、前記第２オペレーティングシステムの動作の停止中に、前記第１オペレーティングシステムに対して、前記第２保守ドライバを用いて、前記第２デバイスに係る情報を取得し、前記第２デバイスの保守制御を実行させる、付記１記載の情報処理装置。

（付記３）
前記処理部は、前記第２オペレーティングシステムの動作の停止中に、前記第１オペレーティングシステムに対して、前記第２保守ドライバを用いて、前記第２デバイスの設定制御を実行させる、付記１または付記２に記載の情報処理装置。

（付記４）
前記第１オペレーティングシステムは、ＳＡＮ（Storage Area Network）制御を行なうＳＡＮ用オペレーティングシステムであり、
前記第２オペレーティングシステムは、ＮＡＳ（Network Attached Storage）制御を行なうＮＡＳ用オペレーティングシステムである、付記１〜付記３のいずれか一項に記載の情報処理装置。

（付記５）
前記第１保守ドライバは、前記第１オペレーティングシステムが行なう前記第１デバイスの運用時の制御に使用される制御機能を含む、付記１〜付記４のいずれか一項に記載の情報処理装置。

（付記６）
前記第２オペレーティングシステムが行なう前記第２デバイスの運用時の制御に使用される制御ドライバを備える、付記１〜付記５のいずれか一項に記載の情報処理装置。

（付記７）
ストレージユニットを制御するストレージ制御装置であって、
ＳＡＮ（Storage Area Network）制御を行なう第１オペレーティングシステムによって管理される第１デバイスと、
ＮＡＳ（Network Attached Storage）制御を行なう第２オペレーティングシステムによって管理される第２デバイスと、
前記第１オペレーティングシステムと前記第２オペレーティングシステムとを動作させ、前記第１オペレーティングシステムに対して、前記第１デバイスに対応する第１保守ドライバをロードさせ、前記第１保守ドライバに前記第１デバイスの保守制御を実行させ、前記第１オペレーティングシステムに対して、前記第２デバイスに対応する第２保守ドライバをロードさせ、前記第２保守ドライバに前記第２デバイスの保守制御を実行させる処理部と 、
を備えることを特徴とするストレージ制御装置。

（付記８）
前記処理部は、前記第２オペレーティングシステムの動作の停止中に、前記第１オペレーティングシステムに対して、前記第２保守ドライバを用いて、前記第２デバイスに係る情報を取得し、前記第２デバイスの保守制御を実行させる、付記７記載のストレージ制御装置。

（付記９）
前記処理部は、前記第２オペレーティングシステムの動作の停止中に、前記第１オペレーティングシステムに対して、前記第２保守ドライバを用いて、前記第２デバイスの設定制御を実行させる、付記７または付記８に記載のストレージ制御装置。

（付記１０）
前記第１保守ドライバは、前記第１オペレーティングシステムが行なう前記第１デバイスの運用時の制御に使用される制御機能を含む、付記７〜付記９のいずれか一項に記載のストレージ制御装置。

（付記１１）
前記第２オペレーティングシステムが行なう前記第２デバイスの運用時の制御に使用される制御ドライバを備える、付記７〜付記１０のいずれか一項に記載のストレージ制御装置。

（付記１２）
コンピュータに、
第１デバイスを管理する第１オペレーティングシステムと第２デバイスを管理する第２オペレーティングシステムとを動作させ、
前記第１オペレーティングシステムに対して、前記第１デバイスに対応する第１保守ドライバをロードさせ、前記第１保守ドライバに前記第１デバイスの保守制御を実行させ、
前記第１オペレーティングシステムに対して、前記第２デバイスに対応する第２保守ドライバをロードさせ、前記第２保守ドライバに前記第２デバイスの保守制御を実行させる、プログラム。

（付記１３）
前記コンピュータに、
前記第２オペレーティングシステムの動作の停止中に、前記第１オペレーティングシステムに対して、前記第２保守ドライバを用いて、前記第２デバイスに係る情報を取得し、前記第２デバイスの保守制御を実行させる、付記１２記載のプログラム。

（付記１４）
前記コンピュータに、
前記第２オペレーティングシステムの動作の停止中に、前記第１オペレーティングシステムに対して、前記第２保守ドライバを用いて、前記第２デバイスの設定制御を実行させる、付記１２または付記１３に記載のプログラム。

（付記１５）
前記第１オペレーティングシステムは、ＳＡＮ（Storage Area Network）制御を行なうＳＡＮ用オペレーティングシステムであり、
前記第２オペレーティングシステムは、ＮＡＳ（Network Attached Storage）制御を行なうＮＡＳ用オペレーティングシステムである、付記１２〜付記１４のいずれか一項に記載のプログラム。

（付記１６）
前記第１保守ドライバは、前記第１オペレーティングシステムが行なう前記第１デバイスの運用時の制御に使用される制御機能を含む、付記１２〜付記１５のいずれか一項に記載のプログラム。

１ ストレージ装置
１１ ハイパバイザ（仮想化ＯＳ）
１２ 第１オペレーティングシステム（ＳＡＮ用ＯＳ；VxWorks）
１３ 第２オペレーティングシステム（ＮＡＳ用ＯＳ；Linux）
２０ａ，２０ｂ 第１デバイス
２１ａ，２１ｂ 第１保守ドライバ（フル機能ドライバ）
３０ａ，３０ｂ 第２デバイス
３１ａ，３１ｂ 制御ドライバ（デバイスドライバ機能）
３２ａ，３２ｂ 第２保守ドライバ（保守機能）
１００ ＣＭ（ストレージ制御装置，情報処理装置）
１０１，１０２ ＣＡ
１０３ ＤＡ
１０６ メモリ
１０７ ＳＳＤ
１０８ ＩＯＣ
１０９ スロット
１１０ ＣＰＵ（処理部）
３００ ドライブエンクロージャ（ストレージユニット）
３１０ 記憶装置（ストレージユニット）
４００ コントローラエンクロージャ

Claims (6)

1. 第１オペレーティングシステムによって管理される第１デバイスと、
   第２オペレーティングシステムによって管理される第２デバイスと、
   前記第１オペレーティングシステムと前記第２オペレーティングシステムとを動作させ、前記第１オペレーティングシステムに対して、前記第１デバイスに対応する第１保守ドライバをロードさせ、前記第１保守ドライバに前記第１デバイスの保守制御を実行させ、前記第１オペレーティングシステムに対して、前記第２デバイスに対応する第２保守ドライバをロードさせ、前記第２保守ドライバに前記第２デバイスの保守制御を実行させる処理部と 、
   を備えることを特徴とする情報処理装置。
2. 前記処理部は、前記第２オペレーティングシステムの動作の停止中に、前記第１オペレーティングシステムに対して、前記第２保守ドライバを用いて、前記第２デバイスに係る情報を取得し、前記第２デバイスの保守制御を実行させる、請求項１記載の情報処理装置。
3. 前記処理部は、前記第２オペレーティングシステムの動作の停止中に、前記第１オペレーティングシステムに対して、前記第２保守ドライバを用いて、前記第２デバイスの設定制御を実行させる、請求項１または請求項２に記載の情報処理装置。
4. 前記第１オペレーティングシステムは、ＳＡＮ（Storage Area Network）制御を行なうＳＡＮ用オペレーティングシステムであり、
   前記第２オペレーティングシステムは、ＮＡＳ（Network Attached Storage）制御を行なうＮＡＳ用オペレーティングシステムである、請求項１〜請求項３のいずれか一項に記載の情報処理装置。
5. ストレージユニットを制御するストレージ制御装置であって、
   ＳＡＮ（Storage Area Network）制御を行なう第１オペレーティングシステムによって管理される第１デバイスと、
   ＮＡＳ（Network Attached Storage）制御を行なう第２オペレーティングシステムによって管理される第２デバイスと、
   前記第１オペレーティングシステムと前記第２オペレーティングシステムとを動作させ、前記第１オペレーティングシステムに対して、前記第１デバイスに対応する第１保守ドライバをロードさせ、前記第１保守ドライバに前記第１デバイスの保守制御を実行させ、前記第１オペレーティングシステムに対して、前記第２デバイスに対応する第２保守ドライバをロードさせ、前記第２保守ドライバに前記第２デバイスの保守制御を実行させる処理部と 、
   を備えることを特徴とするストレージ制御装置。
6. コンピュータに、
   第１デバイスを管理する第１オペレーティングシステムと第２デバイスを管理する第２オペレーティングシステムとを動作させ、
   前記第１オペレーティングシステムに対して、前記第１デバイスに対応する第１保守ドライバをロードさせ、前記第１保守ドライバに前記第１デバイスの保守制御を実行させ、
   前記第１オペレーティングシステムに対して、前記第２デバイスに対応する第２保守ドライバをロードさせ、前記第２保守ドライバに前記第２デバイスの保守制御を実行させる、プログラム。

Images