JPWO2016166880A1 - ストレージシステム、ストレージ装置 - Google Patents

Abstract

ストレージシステムは、管理サーバ計算機及びストレージ装置を備える。ストレージ装置は、第１ネットワークを介して管理サーバ計算機に接続される管理プロセッサと、管理プロセッサに第２ネットワークを介して接続され、かつ、記憶デバイスに接続されて記憶デバイスヘのＩ／Ｏを実行する複数のＩ／Ｏプロセッサと、を有する。管理サーバ計算機は、複数のＩ／ＯプロセッサのうちのいずれかのＩ／Ｏプロセッサのためのコマンドを生成する。管理サーバ計算機は、コマンドをカプセル化しかつ暗号化して暗号化メッセージを生成し、暗号化メッセージを管理プロセッサへ送信する。管理プロセッサは、暗号化メッセージを受信し、コマンドに基づいて、複数のＩ／ＯプロセッサのうちのＩ／Ｏプロセッサを第１宛先として選択する。管理プロセッサは、暗号化メッセージを復号化しカプセル化を解除してコマンドを復元し、第１宛先に対してコマンドを送信する。

Description

本発明は、ストレージ装置の保守及び管理のための技術に関する。

ストレージ装置は、物理記憶デバイス、チャネル基板、ディスクアダプタ基板、及び、１又は複数のプロセッサを含む制御基板等のコンポーネントを有し、これらの要素が相互接続される。チャネル基板は、フロントエンドのインタフェースであり、例えば、ＦＣ（Fibre Channel）やｉＳＣＳＩ（Internet Small Computer System Interface）等の通信ネットワークを介してホスト計算機に接続される。また、ディスクアダプタ基板は、バックエンドのインタフェースであり、例えばＳＡＳ（Serial Attached SCSI）等の通信ネットワークを介して物理記憶デバイスに接続される。制御基板には、１つ又は複数のプロセッサが含まれる。

ストレージ装置は、ホスト計算機からのＩ／Ｏ（Input or Output）処理を行う装置である。具体的には、ストレージ装置のプロセッサが、ホスト計算機からのＩ／Ｏ要求を受信した場合に、そのＩ／Ｏ要求に応じて物理記憶デバイスにデータをリード又はライトする。

ストレージ装置には管理サーバ計算機や保守端末が接続される。管理サーバ計算機及び保守端末は、プロセッサに対して通信することによりストレージ装置の保守及び管理を行う。

管理サーバ計算機は、通信ネットワークを介して制御基板に接続され、プロセッサ保守・管理のための制御を行っている。このため、管理サーバ計算機からストレージ装置の通信は、ストレージ装置の外部からの攻撃にさらされる場合もある。

上記課題を解決するために、本発明の一態様であるストレージシステムは、管理サーバ計算機及びストレージ装置を備える。ストレージ装置は、第１ネットワークを介して管理サーバ計算機に接続される管理プロセッサと、管理プロセッサに第２ネットワークを介して接続され、かつ、記憶デバイスに接続されて記憶デバイスへのＩ／Ｏを実行する複数のＩ／Ｏプロセッサと、を有する。管理サーバ計算機は、複数のＩ／ＯプロセッサのうちのいずれかのＩ／Ｏプロセッサのためのコマンドを生成する。管理サーバ計算機は、コマンドをカプセル化しかつ暗号化して暗号化メッセージを生成し、暗号化メッセージを管理プロセッサへ送信する。管理プロセッサは、暗号化メッセージを受信しコマンドに基づいて、複数のＩ／ＯプロセッサのうちのＩ／Ｏプロセッサを第１宛先として選択する。管理プロセッサは、暗号化メッセージを復号化しカプセル化を解除してコマンドを復元し、第１宛先に対してコマンドを送信する。

本発明のストレージシステムは、管理サーバ計算機とストレージ装置との間のセキュアな通信ができる。

本実施例に係るストレージシステムの構成図である。 ＡＰＩＤの一覧を示す図である。 Ｌ７ＳＷテーブルの一例である。 排他制御テーブル１２１の一例である。 Ｌ７ＳＷサーバ１１９を介した管理サーバ−ＭＰ間通信を説明する図である。 直接ラウンチを説明する図である。 管理サーバ−ＭＰ間通信の一例を示すシーケンス図の一部である。 管理サーバ−ＭＰ間の通信の一例を示すシーケンス図の他の一部である。 管理サーバ−ＢＭＣ間の通信の一例を示すシーケンス図の一部である。 管理サーバ−ＢＭＣ間の通信の一例を示すシーケンス図の他の一部である。 保守端末−ＭＰ間の通信の一例を示すシーケンス図である。 保守端末−ＭＰ間の通信の他の例を示すシーケンス図である。 排他制御のフローチャートの一例である。

なお、以後の説明では「ａａａテーブル」、「ａａａ一覧」等の表現にて本発明の情報を説明するが、これら情報はテーブル、一覧、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａ一覧」等について「ａａａ情報」と呼ぶことがある。

さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「番号」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート及び通信制御デバイスを用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。

また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって記憶装置にインストールされてもよい。

本発明は、以下に説明する実施例に限定されるものではない。以下、図面を用いて本実施例を説明する。

図１は、本実施例に係るストレージシステムの構成図である。本実施例のストレージシステムは、ストレージ装置１を保守及び管理するため操作を実行する管理系のシステムである。

ストレージシステムは、ストレージ装置１と、複数の管理サーバ計算機（以下、管理サーバという）２と、保守端末３とを有する。ストレージ装置１、複数の管理サーバ２及び保守端末３は、管理ＬＡＮ（第１ネットワーク）５を介して相互に接続されている。管理ＬＡＮ５は、例えばEthernet（登録商標）等のインタフェース（Ｉ／Ｆ）で接続されたネットワークである。なお、管理サーバ２は、複数には限られず１つであってもよい。

保守端末３は、図示しないプロセッサ及びメモリとＮＩＣ(network interface card）等の通信Ｉ／Fとを有する汎用計算機である。保守端末３では、ｗｅｂブラウザ３１が実行されている。ｗｅｂブラウザ３１は、ストレージ装置１のｗｅｂサーバ１１１に対して、ｈｔｔｐや、ｈｔｔｐｓなどのプロトコルを用いて接続される。なお、ｈｔｔｐｓの通信には、ＳＳＬ（Secure Sockets Layer）が用いられる。ユーザ又は保守員は、保守端末３のｗｅｂブラウザ３１を介してストレージ装置１におけるプログラムのインストールや初期設定、ＦＲＵ（Field Replaceable Unit）等の交換可能なハードウェアの閉塞及び交換指示、障害又は保守に関する情報の取得を行う。

管理サーバ２は、図示しないプロセッサ及びメモリと通信Ｉ／Fとを有する。管理サーバ２では、メモリ内のプログラムをプロセッサが実行することにより複数の管理アプリケーション２１及び通信アプリケーション２３が実行される。また、管理サーバ２では、ストレージ装置１のＬ７ＳＷ（レイヤ７スイッチ）機能を利用するＬ７ＳＷクライアント２５が実行されている。図中では、複数の管理アプリケーション２１が、管理ＡＰＰ＃Ａ、管理ＡＰＰ＃Ｂとして示されているが、１つの管理アプリケーションのみが実行されていてもよい。なお、管理サーバ２で実行される通信アプリケーション２３を、以下では、サーバＡＰＰ２３という場合がある。

管理アプリケーション２１は、ストレージ装置１の論理デバイス（ＬＤＥＶ）の管理、ＰＡＴＨの定義、及び、モニタ情報採取などの機能を有する。

ストレージ装置１は、冗長化された２つのコントローラ（ＣＴＬ、制御基板）１０を有する。なお、本実施例ではストレージ装置１が有するＣＴＬ１０の数は２つであるが、ＣＴＬ１０の数は２つには限られず１つであってもよいし、３つ以上であってもよい。２つのＣＴＬ＃１と＃２の構成は、基本的に同様である。

各ＣＴＬ１０は、複数のＩ／Ｏプロセッサ（以下、ＭＰ：Main Processerという）１３と、管理プロセッサ（以下、ＢＭＣ：Baseboard Management Controllerという）１１とを有する。各ＣＴＬ１０内の複数のＭＰ１７及びＢＭＣ１１は、内部ＬＡＮ（第２ネットワーク）１５を介して相互に接続されている。また、２つのＣＴＬ＃１、＃２は、内部ＬＡＮ１５を介して接続されることで冗長化されている。なお、この例では、管理プロセッサをＢＭＣとして説明しているが、これに限定されない。管理プロセッサは、例えば、ＳＯＣ（System on Chip）等の他のプロセッサでもよい。

内部ＬＡＮ１５は、例えば、Gigabit EthernetなどのＩ／Ｆで接続されており、ストレージ装置１の外部から遮断されたネットワークである。一方、管理ＬＡＮ５には、ＢＭＣ１１が接続される。管理サーバ２及び保守端末３は、ＢＭＣ１１を介してＭＰ１７と通信する。なお、内部ＬＡＮ１５は、ＰＣＩｅ（PCI Express）等の高速通信Ｉ／Ｆであってもよい。

ＢＭＣ１１は、図示しないプロセッサ、メモリ、管理ＬＡＮ５に接続される通信Ｉ／F、及び内部ＬＡＮ１５に接続される通信Ｉ／Fを有する。ＢＭＣ１１には、例えばフラッシュメモリＲＯＭ（ＦＲＯＭ）等の記憶デバイス１４が接続される。記憶デバイス１４には、ストレージ装置１の保守及び管理を行うプログラムであるＢＭＣファームウェア（ＢＭＣＦ／Ｗ）、ネットワークの設定情報及び認証情報等の各種構成情報が格納される。

ストレージ装置１を起動した場合に、ＢＭＣＦ／ＷがＢＭＣ１１のメモリに展開され実行される。ＢＭＣＦ／Ｗにより、ＢＭＣ１１は、ｗｅｂサーバ１１１と、保守／ＵＩ ＡＰＩ（Application Programming Interface）１１７と、通信アプリケーション１１３と、Ｌ７ＳＷサーバ１１９と、排他制御機能１１５と、を実現する。このとき、メモリ上にＬ７ＳＷテーブル４１、及び、排他制御テーブル１２１が展開される。なお、ＢＭＣ１１で実行される通信アプリケーション１１３を、以下では、ＢＭＣＡＰＰ１１３という場合がある。ＢＭＣＦ／Ｗにより、ＢＭＣ１１はさらに、ストレージ装置１の電源制御、管理サーバがストレージ装置を遠隔操作するリモートＫＶＭ機能、電圧や温度情報などの環境情報を収集する等のストレージ装置１を保守・管理するための機能を実現する。

管理サーバ２のＬ７ＳＷクライアント２５と、ＢＭＣ１１のＬ７ＳＷサーバ１１９とは、ＴＣＰ／ＩＰベースのソケット通信プロトコルを用いて接続される。

複数のＭＰ１７には、例えばＳＳＤ（Solid State Drive）等の１つ又は複数の記憶デバイス１２が接続される。記憶デバイス１２には、メインマイクロプログラム（メインマイクロ）１７１が格納される。ＭＰ１７は更に、図示しないチャネル基板、ＳＡＮ（Storage Area Network）等のネットワークを介して、図示しないホスト計算機に接続される。

ストレージ装置１を起動した場合に、メインマイクロ１７１が各ＭＰ１７内のメモリに展開され実行される。メインマイクロ１７１により、各ＭＰ１７では、通信アプリケーション１７２、ＩＯ制御モジュール１７３及び保守制御モジュール１７４が実現される。なお、ＭＰ１７で実行される通信アプリケーション１７２を、以下では、ＭＰＡＰＰ１７２という場合がある。

ＩＯ制御モジュール１７３は、ホスト計算機からのＩ／Ｏ要求に応じて、図示しない物理記憶デバイスとのＩ／Ｏを制御する。保守制御モジュール１７４は、ＢＭＣ１１のＬ７ＳＷサーバ１１９を介して管理サーバ２の管理アプリケーション２１と通信する。また、保守制御モジュール１７４は、ＢＭＣ１１の保守／ＵＩ ＡＰＩ１１７とＷｅｂサーバ１１１を介して、保守端末３又は管理サーバ２の管理アプリケーション２１と通信する。

各管理サーバ２、ＢＭＣ１１及び各ＭＰ１７上で、通信アプリケーション２３、１１３、１７２がそれぞれ動作することにより、各管理サーバ２、ＢＭＣ１１及び各ＭＰ１７の間で共通Ｉ／Ｆでの通信が可能となる。通信アプリケーション２３、１１３、１７２は、要求される機能を示すＡＰＩＤ（Application ＩＤ）を含むコマンドによるコマンド通信を行う。各通信アプリケーション２３、１１３、１７２間の通信は、ＡＰＩＤに依存しないＴＣＰセッション層によるハンドシェーク論理を用いている。なお、ＡＰＩＤを用いたコマンド通信は、ＴＣＰのセッションとは異なるより上位層であるアプリケーション層の通信となる。

なお、管理サーバ２のＬ７ＳＷクライアント２５とＢＭＣ１１のＬ７ＳＷサーバ１１９との間の通信を、管理サーバ−ＢＭＣ間通信という。また、Ｌ７Ｗクライアント及びＬ７ＳＷサーバ１１９を介した管理サーバ２とＭＰ１７との間の通信を管理サーバ−ＭＰ間通信という。また、ＢＭＣ１１の保守／ＵＩ ＡＰＩ１１７を介した保守端末３とＭＰ１７との間のｈｔｔｐ／ｈｔｔｐｓを用いた通信を直接ラウンチといい、保守ＵＩ／ＡＰＩ１１７を介した管理サーバ２の管理アプリケーション２１とＭＰ１７との間のｈｔｔｐ／ｈｔｔｐｓを用いた通信を間接ラウンチという。

ＭＰ１７は、管理ＬＡＮ５に直接接続されずに、ＢＭＣ１１を介して管理ＬＡＮ５に接続される。これにより、ＭＰ１７が、ストレージ装置１の外部からの攻撃を受けにくくなる。

また、保守ＵＩ／ＡＰＩ１１７がＢＭＣ１１で実行されることにより以下（１）−（３）の効果を有する。

（１）保守端末３の画面表示などのＵＩ処理を、ＭＰ１７のＩ／Ｏ処理とは独立して行うことができる。つまり、保守ＵＩ／ＡＰＩ１１７がＭＰ１７の資源を使用しないため、ＵＩ処理を行うことでのＩ／Ｏのスループットの低下や応答遅延を回避することができる。
（２）ＭＰ１７に障害が発生した場合であっても、保守ＵＩ／ＡＰＩ１１７がＭＰ１７の障害情報をモニタ及び収集できる。
（３）例えば、ＯｐｅｎＳＳＬなどのセキュリティのアップデートが必要になった場合に、ＢＭＣ／ＦＷのアップデートを行うたけでよい。つまり、セキュリティのアップデートの度にメインマイクロのアップデートを行う必要はない。このため、保守ＵＩ／ＡＰＩ１１７がＭＰ１７で実行される場合に比べて、メインマイクロのアップデート回数や、アップデート中及びアップデート後のリブート等による、Ｉ／Ｏ処理への影響を回避できる。

図２は、ＡＰＩＤの一覧を示す図である。

ＡＰＩＤの一覧を説明する。ＡＰＩＤは、前述の通り、通信アプリケーション２３、１１３、１７２において事前に定義されたＩＤである。この一覧は、各管理サーバ２、ＢＭＣ１１及びＭＰがそれぞれ記憶する。

一覧は、ＡＰＩＤの毎のエントリを有する。各エントリは、ＡＰＩＤ３０１と、当該ＡＰＩＤを含むコマンド（以下、ＡＰコマンドという）の送信先の装置を指定した通信タイプ３０２と、当該ＡＰコマンドの機能３０３と、当該通信に使用されるＢＭＣのＣＴＬを指定したＢＭＣ３０４と、送信先ＭＰ１７にＡＰコマンドを送信するＢＭＣ１１のアプリケーションの種別を示すＡＰＰ種別３０５と、を有する。

例えば、ＡＰＩＤ０ｘ１０は、管理サーバ２がＣＴＬ１又は２のうちの閉塞の対象となるＭＰ１７に対し、対象ＭＰの閉塞を指示する場合のＩＤである。ＢＭＣＡＰＰ１１３が対象ＭＰにＡＰコマンドを送信する。また、例えば、ＡＰＩＤ０ｘ８１は、管理サーバ２が対象のＢＭＣ１１に対し、ＢＭＣＦ／Ｗの交換を指示する場合のＩＤである。

図３は、Ｌ７ＳＷテーブル４１の一例である。

Ｌ７ＳＷテーブル４１は、ＢＭＣ１１のメモリに記憶され、Ｌ７ＳＷサーバ１１９により更新され参照されるテーブルである。

Ｌ７ＳＷテーブル４１は、メッセージＩＤ毎のエントリを有する。各エントリは、Ｌ７ＳＷクライアント２５からＬ７ＳＷサーバ１１９に送信されるメッセージを識別するメッセージＩＤ４０１と、当該メッセージの送信元の装置のＩＰアドレスである送信元ＩＰ４０２と、当該メッセージの送信先の装置のＩＰアドレスである送信先ＩＰ４０３と、当該メッセージの送信がＳＳＬを用いて行われた場合の接続先を示すＳＳＬ構造体ポインタ４０４と、接続状態を示す接続ステータス４０５と、接続先の装置が有するＭＰのＭＰ番号４０６と、Ｌ７ＳＷクライアント２５及びＬ７ＳＷサーバ１１９の間の通信を識別する管理サーバ−ＢＭＣ間ＦＤ番号４０７と、Ｌ７ＳＷサーバ１１９及びＭＰ１７の間の通信の識別子であるＢＭＣ−ＭＰ間ＦＤ番号４０８とを有する。管理サーバ−ＢＭＣ間ＦＤ番号４０７及びＢＭＣ−ＭＰ間ＦＤ番号４０８により、Ｌ７ＳＷクライアント２５及びＬ７ＳＷサーバ１１９の間の通信とＢＭＣ１１及びＭＰ１７間の通信とが関連づけられる。なお、Ｌ７ＳＷクライアント２５及びＬ７ＳＷサーバ１１９間の通信の識別は、メッセージＩＤ５０１を用いて識別することができる。このため、Ｌ７ＳＷテーブル４１には、管理サーバ−ＢＭＣ間ＦＤ番号４０７の欄を設けなくてもよい。

なお、この例では、送信元又は送信先の装置は、保守端末３、ＢＭＣ１１又はＭＰ１７のいずれかである。ＳＳＬ構造ポインタは、暗号化されたメッセージを送信する場合の接続先である。接続ステータスは、例えば、初期状態、セッションの待ち状態（listen）、通常のセッション（ｈｔｔｐ）を受け付けた状態（accept済み）、ＳＳＬでのセッション（ｈｔｔｐｓ）を受け付けた状態（SSL accept済み）、通常のセッションのクローズ待ちの状態、接続の認証済み状態、ＳＳＬでのセッションのクローズ待ち状態などがコード化されて入力される。例えば、１０はセッションの待ち状態、３０はＳＳＬを用いたセッションを受け付けた状態である。

図４は、排他制御テーブル１２１の一例である。

排他制御テーブル１２１は、ＢＭＣ１１のメモリに記憶され、保守／ＵＩ ＡＰＩ１１７又はＬ７ＳＷサーバ１１９により更新され参照されるテーブルである。排他制御テーブル１２１は、ＭＰ１７毎に排他制御を行うためのテーブルである。つまり、このテーブル１２１は、各ＭＰ１７対し２つ以上のＡＰコマンドを送信することを防ぐために使用される。

排他制御テーブル１２１は、ＭＰ１７毎のエントリを有する。各エントリは、ＭＰ１７の識別子であるＭＰ番号５０１と、当該ＭＰの実行状態を示すステータス５０２、当該ＭＰのエントリ中ＡＰＩＤ５０３と、コマンドの要求元のＩＤの種別を示すＩＤ種５０４と、当該コマンドのＩＤを示す要求元ＩＤ５０５と、要求元のＩＰアドレスを示す要求元ＩＰ５０６と、を有する。本実施例では、要求元ＩＤ種５０４は、保守／ＵＩ ＡＰＩ１１７のプロセスのＰＩＤ（Process ＩＤ）又はメッセージのメッセージＩＤのいずれかである。要求元ＩＤ種５０４がＰＩＤである場合、保守端末３のｗｅｂブラウザ３１とＢＭＣ１１のｗｅｂサーバ１１１との間の通信を経由したコマンドであることを示す。要求元ＩＤ種５０４がメッセージＩＤである場合、管理サーバ２のＬ７ＳＷクライアント２５とＢＭＣ１１との間の通信を経由したコマンドであることを示す。要求元ＩＤ５０５は、ＰＩＤ又はメッセージＩＤのいずれかのＩＤを示す。要求元ＩＰ５０６は、要求元である保守端末３又は管理サーバ２のＩＰアドレスである。なお、エントリ中ＡＰＩＤ５０３、要求元ＩＤ種５０４、要求元ＩＤ５０５及び要求元ＩＰ５０６の各情報は、管理目的の情報である。このため、排他制御テーブル１２１には、これらの欄を設けなくてもよい。

図５は、Ｌ７ＳＷサーバ１１９を介した管理サーバ−ＭＰ間通信を説明する図である。

管理サーバ２の管理アプリケーション２１が、Ｌ７ＳＷサーバ１１９を介してＭＰ１７の保守制御モジュール１７４と通信を行う場合を説明する。管理アプリケーション２１から関数をコールされた場合、サーバＡＰＰ２３は、その関数を示すＡＰＩＤ及び宛先のＭＰ番号（ＭＰ＃）を含めたヘッダをデータに付与したＡＰコマンドを、Ｌ７ＳＷクライアント２５に引き渡す。このヘッダを、以下の説明及び図では通信ＡＰＰヘッダ７１という。通信ＡＰＰヘッダ７１には、ＡＰコマンドの識別子が指定される。識別子として、例えば、ＡＰコマンドの送信の開始を示す送信フラグ、ＡＰコマンドの正常受信の受信応答であるＡＣＫフラグ、ＡＰコマンドの異常受信の受信応答であるＮＡＫフラグ、ＡＰコマンドに実データが存在することを示すデータフラグ、ＡＰコマンドがデータの再送であることを示す再送フラグ等が指定される。また、宛先のＭＰ番号には、例えば”any“として、宛先のＭＰが指定されなくてもよい。

Ｌ７ＳＷクライアント２５は、管理アプリケーション２１から関数コールによりサーバＡＰＰ２３が呼び出されると、このサーバＡＰＰ２３の指示により、Ｌ７ＳＷサーバ１１９とのセッションを確立する。Ｌ７ＳＷクライアント２５は、受信したＡＰコマンドにＬ７ヘッダ７２を付与することによりカプセル化したメッセージを生成し、メッセージをＳＳＬ２６により暗号化しＴＣＰヘッダ７３及びＩＰヘッダ７４を付与し、管理ＬＡＮ５を通じて暗号化されたメッセージを送信する。Ｌ７ヘッダ７２には、前述のメッセージＩＤと、送信元の管理サーバ２及び管理アプリケーション２１を指定する送信元種類、送信先のＢＭＣ１１又はＭＰ１７を指定する送信先種類が指定される。なお、Ｌ７ＳＷクライアント２５は、生成したメッセージを暗号化せずに平文のまま平文のメッセージとして送信してもよい。

Ｌ７ＳＷサーバ１１９は、メッセージＩＤ解釈機能４２と、セッション終端機能４６と、メッセージＩＤ管理機能４５と、ＭＰ振分機能４４と、Ｌ７ＳＷテーブル参照更新機能４７と、ＳＳＬ４３と、排他制御機能１１５とを有する。

Ｌ７ＳＷサーバ１１９は、Ｌ７クライアント２５とのセッションを確立した後、Ｌ７ＳＷサーバ１１９から暗号化されたメッセージを受信し、ＴＣＰヘッダ７３及びＩＰヘッダ７４を除去し、復号する。なお、受信したメッセージが平文のメッセージの場合は、Ｌ７ＳＷサーバ１１９は、ＴＣＰヘッダ７３及びＩＰヘッダ７４を除去した後の複合はしない。

Ｌ７ＳＷサーバ１１９は、メッセージのＬ７ヘッダ７２の情報に基づき、メモリ内のＬ７ＳＷテーブル４１を更新する（メッセージＩＤ解釈機能４２）。このとき、送信先がＭＰである場合には、Ｌ７ＳＷサーバ１１９は、宛先のＭＰを決定する（ＭＰ振分機能４４）。この場合、Ｌ７ＳＷサーバ１１９は、排他制御テーブル１２１に基づき、宛先となるＭＰ１７への通信が多重化されないよう、排他制御を行う（排他制御機能１１５）。排他制御については、後述する。

Ｌ７ＳＷサーバ１１９は、メッセージのＬ７ヘッダを除去する。これにより、ＡＰコマンドが復元される。更にＬ７ＳＷサーバ１１９は、Ｌ７ＳＷクライアント２５とのセッションを終端する（セッション終端機能４６）。

Ｌ７ＳＷサーバ１１９は、復元したＡＰコマンドに、宛先ＭＰを示すＴＣＰヘッダ７３及びＩＰヘッダ７４を付与し、内部ＬＡＮ１５を介して宛先ＭＰに送信する。内部ＬＡＮ１５上のＡＰコマンドの通信は、暗号化されていない平文の通信となる。なお、Ｌ７ＳＷサーバ１１９は、復元したＡＰコマンド内に宛先のＭＰ番号が指定されていない場合、ＭＰ１７への多重化を回避する為後述の排他制御により宛先のＭＰ１７を選択する。そして、Ｌ７ＳＷサーバ１１９は、選択した宛先のＭＰ番号を通信ＡＰＰヘッダ７１に含めたＡＰコマンドを宛先のＭＰ１７に送信する。

本実施例では、各管理サーバ２にＬ７ＳＷクライアント２５を設け、ＢＭＣ１１にＬ７ＳＷサーバ１１９を設けた。これにより、Ｌ７ＳＷサーバ１１９は、１又は複数の管理サーバ２内の複数の管理アプリケーション２１からの要求に基づくメッセージを一括して受付けることができるとともに、その内部のＡＰコマンドを複数のＭＰに振り分ける事ができる。また、Ｌ７ＳＷサーバ１１９は、ＭＰ１７とのＡＰコマンドによる通信をメッセージ毎に管理することができる。

Ｌ７ＳＷクライアント２５が、（ａ）Ｌ７ヘッダを付与したメッセージを生成することで、管理ＬＡＮ５上でＡＰコマンドがカプセル化されたメッセージを用いてＬ７ＳＷサーバ１１９と通信を行うことができる。これにより、メッセージの宛先をＬ７ＳＷサーバにする等、コマンドのフォーマットを隠蔽することができる。

さらに、Ｌ７ＳＷクライアント２５がＳＳＬを有することにより、（ｂ）Ｌ７ＳＷサーバ１１９に対する管理ＬＡＮ５上のメッセージの通信が暗号化される。このため、管理ＬＡＮ５におけるストレージ装置１の外部からの盗聴、改ざん、なりすまし又はＤＤｏＳ（Distributed Denial of Service）攻撃などのセキュリティ上のリスクを低減できる。

一方、ＢＭＣ１１にＬ７ＳＷサーバ１１９を設けたことにより、メッセージを用いることで、（ｃ）管理サーバ２からＭＰ１７への通信を一旦ＢＭＣ１１のＬ７ＳＷサーバ１１９で完結させることができる。これにより、下記に示す（ｄ）〜（ｆ）の効果が得られる。

（ｄ）管理サーバ２からＭＰ１７への通信を一旦ＢＭＣ１１のＬ７ＳＷサーバ１１９で完結させることにより、各管理サーバ２上で複数の管理アプリケーション２１が実行される場合であっても、Ｌ７ヘッダ７２（送信元種類）により送信元の管理アプリケーション２１が識別できる。これにより、複数の管理アプリケーション２１から非同期でメッセージでの通信を行うことができ、管理アプリケーション２１間で同期をとる必要がなくなる。これは複数の管理サーバ２を有する場合も同様である。Ｌ７ＳＷサーバ１１９は、１又は複数のＬ７ＳＷクライアント２５から送信されるメッセージに基づくＡＰコマンドの処理を、メッセージＩＤ毎のスレッドで管理することができる。

（ｅ）Ｌ７ＳＷサーバ１１９により、管理サーバ−ＭＰ間通信を、管理サーバ２とＢＭＣ１１との間の第１通信と、ＢＭＣ１１とＭＰ１７との間の第２通信に分離することができる。これにより、第１通信ではコマンドを暗号化し、第２ではコマンドを非暗号化することができる。従って、高いスループット及び応答性能を求められるＩ／Ｏ制御を行うＭＰ１７は、暗号処理による負荷を負うことがない。

（ｆ）Ｌ７ＳＷサーバ１１９により、第２通信においては、Ｌ７ヘッダを除去したＡＰコマンドを用いた通信が可能になる。つまり、第１通信とは分離した第２通信を用いることにより、管理サーバ−ＭＰ間の通信がＢＭＣ１１で一旦バッファされ、ＢＭＣ１１とＭＰ１７との間の第２通信となる。このようにすることで、管理サーバ−ＭＰ間のコマンドの直接の送受信機会（ＴＣＰ層でのハンドシェーク及び通信を含む）を少なくすることができるため、管理サーバ２とＢＭＣ１１との間の管理ＬＡＮ５の帯域幅に拘束されずにすむ。また、管理ＬＡＮ５に通信障害が発生した場合であっても、ＢＭＣ１１が受信したメッセージに基づくＡＰコマンドの処理については、内部ＬＡＮ１５を介したＢＭＣ−ＭＰ間の第２通信を行えばよいこととなり、管理ＬＡＮ５側の障害の影響を受けにくい。

（ｇ）また例えば、管理サーバ２が、ＢＭＣ１１が有する情報にアクセスしたい場合もある。この場合、メッセージを用いた管理サーバ−ＢＭＣ間通信のみで通信を完結できる。なお、ＢＭＣ１１は、例えば、Networkの設定情報や認証情報などを記憶している。

図６は、直接ラウンチを説明する図である。

ＢＭＣ１１における保守／ＵＩ ＡＰＩ１１７は、ｗｅｂサーバ１１１を介してｗｅｂブラウザ３１に画面表示情報を提供する。また、保守／ＵＩ ＡＰＩ１１７は、ｗｅｂブラウザ３１からのアクセスに基づき、メインマイクロ１７１の保守制御モジュール１７４に対してＡＰコマンドを送信し、保守制御モジュール１７４から情報を取得する。具体的には、例えば、保守／ＵＩ ＡＰＩ１１７は、ストレージ装置１の構成情報や状態のモニタ情報の取得、保守交換対象部品に対する閉塞指示などを行う。

例えば、ｗｅｂブラウザ３１がｗｅｂサーバ１１１に対してｈｔｔｐ又はｈｔｔｐｓ（暗号化）を用いたセッションを確立する。保守／ＵＩ ＡＰＩ１１７は、直接ラウンチと間接ラウンチの何れかの方法により起動される。直接ラウンチでは、ｗｅｂブラウザ３１がｗｅｂサーバ１１１を介して保守／ＵＩ ＡＰＩ１１７を起動する。間接ラウンチでは、管理サーバ２の管理アプリケーション２１がｗｅｂサーバ１１１を介して保守／ＵＩ ＡＰＩ１１７を起動する。

ｗｅｂブラウザ３１から保守／ＵＩ ＡＰＩ１１７に対して要求があった場合、保守／ＵＩ ＡＰＩ１１７は、要求に基づいたＡＰＩＤ及び宛先のＭＰ１７を指定したＡＰコマンドを生成する。このＡＰコマンドを以下では、保守側ＡＰコマンドという。そして、ＢＭＣＡＰＰ１１３は、通信排他制御を実施した後、通信ＡＰＰヘッダ７１で指定されたＭＰ番号を有するＭＰを指定したＴＣＰヘッダ及びＩＰヘッダを保守側ＡＰコマンドに付与し、内部ＬＡＮ１５を介して宛先のＭＰに送信する。内部ＬＡＮ上では、暗号化されていない平文の通信となる。

保守制御モジュール１７４は、メインマイクロ１７１側で閉塞や回復指示等の保守制御のスケジュール管理や構成情報の参照及び更新等、保守／ＵＩ ＡＰＩ１１７とメインマイクロ１７１との通信のためのＩ／Ｆの機能を有する。これにより、保守端末３又は管理サーバ（間接ラウンチの場合）２１からＭＰ１７に対して、ストレージ装置１の保守制御のための操作を行うことができる。

なお、保守／ＵＩ ＡＰＩ１１７は、ＭＰ１７にＡＰコマンドを送信した後、その応答を待って、次のＡＰコマンドをＭＰ１７に送信する。つまり、保守／ＵＩ ＡＰＩ１１７から各ＭＰ１７へのＡＰコマンドは、多重化されない。しかし、Ｌ７ＳＷサーバ１１９から各ＭＰ１７に対するＡＰコマンドが送信される。
このため、保守／ＵＩ ＡＰＩ１１７も、排他制御機能１１５により、各ＭＰへの通信に対して排他制御を行う。

間接ラウンチでは、管理アプリケーション２１がｗｅｂサーバ１１１を介して保守／ＵＩ ＡＰＩ１１７にアクセスすることで、画面表示情報等の情報を取得できる。これにより、管理サーバ２が保守／ＵＩ ＡＰＩ１１７と同等の機能を実装しなくても、管理アプリケーション２１が保守／ＵＩ ＡＰＩ１１７の機能を利用することができる。

図７は、管理サーバ−ＭＰ間通信の一例を示すシーケンス図の一部である。図８は、管理サーバ−ＭＰ間の通信の一例を示すシーケンス図の他の一部である。

この通信は、管理アプリケーション２がＭＰ１７の処理の要求を示す関数をコールした場合に開始される。管理アプリケーション＃Ａは、サーバＡＰＰ２３の関数Ａをコール（関数ｃａｌｌＡ）する（Ｓ７０１）。

サーバＡＰＰ２３は、関数Ａに対応するＡＰＩＤを指定し、ＡＰＩＤ及び宛先のＭＰ番号を含めた通信ＡＰＰヘッダ７１をデータに付与しＡＰコマンドを生成する。サーバＡＰＰ２３は、ＡＰコマンドをＬ７ＳＷクライアント２５に引渡す（Ｓ７０２）。

Ｌ７ＳＷクライアント２５は、Ｌ７ＳＷサーバ１１９との間にＳＳＬ又は通常のセッションを確立する。Ｌ７ＳＷクライアント２５は、新規のメッセージＩＤ（０x１０）と、送信元種類と、送信先種類を含めたＬ７ヘッダ７２をＡＰコマンドに付与し暗号化して（通常のセッションの場合は平文のまま）メッセージを生成する。Ｌ７ＳＷクライアント２５は、メッセージをＬ７ＳＷサーバ１１９に送信する（Ｓ７０３）。なお、Ｌ７ＳＷクライアント２５は、Ｌ７ＳＷサーバ１１９との間のセッション毎に、異なるメッセージＩＤを生成する。

Ｌ７ＳＷサーバ１１９は、メッセージを受信し、メッセージ内のメッセージＩＤ（０x１０）に基づくスレッドを管理する（７００）。メッセージＩＤ０x１０のスレッドを破線で示す。Ｌ７ＳＷサーバ１１９は、メッセージに基づきＬ７ＳＷテーブル４１及び排他制御テーブル１２１を更新し、排他制御を実行し、ＡＰコマンドの宛先のＭＰを選択する。排他制御の詳細は後述する。

Ｌ７ＳＷサーバ１１９は、メッセージ復号しＬ７ヘッダを除去することによりＡＰコマンドを復元する。なお、この例ではＡＰコマンドに、実データの存在を意味する（Data Flag ON）の識別子が含まれる。Ｌ７ＳＷサーバ１１９は、ＡＰコマンドをＭＰＡＰＰ１７２に送信する（Ｓ７０４）。

ＭＰＡＰＰ１７２は、ＡＰコマンドを受信し、Ｌ７ＳＷサーバ１１９に受信応答を送信する（Ｓ７０６）。この例では、ＡＰコマンドの受信応答（ＡＰ応答）のＡＰヘッダには、正常応答である旨の識別子（ACK Flag ON）が含まれる。

Ｌ７ＳＷサーバ１１９は、ＡＰ応答を受信し、Ｌ７ＳＷクライアント２５に対し、メッセージの受信応答（メッセージ応答）を送信する（Ｓ７０７）。なお、メッセージ応答には、対応するメッセージと同じメッセージＩＤ０x１０が付与される。

ＭＰＡＰＰ１７２は、Ｓ７０４で受信したＡＰコマンド内のＡＰＩＤ及びデータを、メインマイクロ１７１に引き渡す（Ｓ７０８）。

メインマイクロ１７１は、ＡＰＩＤを解釈し、その要求に基づく処理を実行する。この例では、ＡＰＩＤが０x０４であるので、メインマイクロ１７１は、構成情報を参照し、情報を返す処理を実行する（図２参照）。

メインマイクロ１７１は、処理が終了した後、ＡＰコマンドに基づく処理の結果を、ＭＰＡＰＰ１７２に引き渡す（Ｓ７１０）。

ＭＰＡＰＰ１７２は、メインマイクロ１７１から処理の結果を取得し、結果に基づきＡＰ処理応答を生成し、ＡＰ処理応答をＬ７ＳＷサーバ１１９に送信する（Ｓ７１１）。なお、ＡＰ処理応答は、結果となるデータに通信ＡＰＰヘッダ７１を付したＡＰコマンドの形式で送信される。この例では、ＡＰ処理応答のＡＰヘッダには、実データの存在を意味する識別子に（Data Flag ON）が含まれる。

Ｌ７ＳＷサーバ１１９は、ＡＰ処理応答を受信し、ＡＰ処理応答に基づきメッセージ処理応答を生成し、メッセージ処理応答をＬ７ＳＷクライアント２５に送信する（Ｓ７１２）。メッセージ処理応答は、ＡＰ処理応答にL７ヘッダを付与して生成される。このＬ７ヘッダには、当該処理要求のメッセージに含まれるメッセージＩＤに関連するメッセージＩＤが含まれる。具体的には、この例では、処理要求のメッセージＩＤ０x１０に０ｘ１０を加えて０x２０とする。

Ｌ７ＳＷクライアント２５は、メッセージ処理応答を受信し、管理アプリケーション＃Ａに関数Ａに基づく要求の結果及び完了応答を通知する（Ｓ７１３）。

管理アプリケーション＃Ａは、結果及び完了応答を受信し、完了応答の受信応答をＬ７ＳＷクライアント２５に通知する（Ｓ７１４）。

Ｌ７ＳＷクライアント２５は、受信応答を受信し、その受信応答にＬ７ヘッダを付与したメッセージ受信応答を、Ｌ７ＳＷサーバ１１９に送信する（Ｓ７１５）。メッセージ受信応答には、メッセージ処理応答と同一のメッセージＩＤ（０x２０）が含まれる。

Ｌ７ＳＷサーバ１１９は、メッセージ受信応答を受信し、メッセージ受信応答に基づきＬ７ＳＷテーブル４１及び排他制御テーブル１２１を更新し、メッセージ受信応答のＬ７ヘッダを除去したＡＰ受信応答をＭＰＡＰＰ１７２に送信する（Ｓ７１６）。ＭＰＡＰＰ１７２は、ＡＰ受信応答を受信し、関数Ａの要求に基づく通信を終了する。

図８を説明する。ここでは、管理アプリケーション＃Ｂが、サーバＡＰＰ２３の関数Ｂをコール（関数ｃａｌｌＢ）する（Ｓ８０１）場合を説明する。サーバＡＰＰ２３は、関数Ｂに対応するＡＰＩＤを指定し、ＡＰＩＤ及び宛先のＭＰ番号を含めた通信ＡＰＰヘッダ７１をデータに付与しＡＰコマンドを生成する。サーバＡＰＰ２３は、ＡＰコマンドをＬ７ＳＷクライアント２５に引渡す（Ｓ８０２）。

この場合の管理アプリケーション＃Ｂ−ＭＰ１７間の通信も、管理アプリケーション＃Ａ−ＭＰ１７間の通信と基本的に同様である。ただし、要求に基づきＬ７ＳＷクライアント２５が生成するメッセージのメッセージＩＤが異なる（Ｓ８０３）。このメッセージは、メッセージＩＤ０x１１が付与される。Ｌ７ＳＷサーバ１１９は、メインマイクロ１７１との間の通信を、メッセージのメッセージＩＤ（０x１１）に基づくスレッドで管理する（８００）。破線で示すメッセージＩＤ０x１１のスレッドは、メッセージＩＤ０ｘ１０のスレッドと基本的に同様である。

Ｌ７ＳＷサーバ１１９がＬ７ＳＷクライアント２５に送信するメッセージ応答には、メッセージと同じメッセージＩＤ０x１１が付与される。

なお、Ｌ７ＳＷサーバ１１９及びＬ７ＳＷクライアント２５間のメッセージ処理応答及びメッセージ受信応答のＬ７ヘッダには、当該メッセージのメッセージに関連するメッセージＩＤ（０x２１）が含まれる（Ｓ８１２、Ｓ８１５）。

上記の通信においては、管理アプリケーション２１からメインマイクロ１７１に対する１つの要求について、Ｌ７ＳＷクライアント２５がＬ７ヘッダ７１にメッセージＩＤを含めたメッセージを生成する。これにより、Ｌ７ヘッダを除去したＡＰコマンドでのＬ７ＳＷサーバ１１９とメインマイクロ１７１との間の通信が、メッセージＩＤを用いてスレッド管理できる。これにより、Ｌ７クライアント２５から複数のメッセージが送信された場合であっても、Ｌ７ＳＷサーバ１１９は、メッセージ毎に通信を管理することができる。図７及び８は、メッセージの０ｘ１０系と０ｘ１１系の通信スレッドをシリアルに記載しているが、上記の通り多重での処理も可能である。

図９は、管理サーバ−ＢＭＣ間の通信の一例を示すシーケンス図の一部である。図１０は、管理サーバ−ＢＭＣ間の通信の一例を示すシーケンス図の他の一部である。

この通信は、管理アプリケーション２がＢＭＣ１１で完結する処理の要求を示す関数をコールした場合に開始される。管理アプリケーション＃Ａは、サーバＡＰＰ２３の関数Ｃをコール（関数ｃａｌｌＣ）する（Ｓ９０１）。

サーバＡＰＰ２３は、要求Ｃに対応するＡＰＩＤを指定し、ＡＰＩＤ及び宛先をＢＭＣ１１とした通信ＡＰＰヘッダ７１をデータに付与しＡＰコマンドを生成する。サーバＡＰＰ２３は、ＡＰコマンドをＬ７ＳＷクライアント２５に引渡す（Ｓ９０２）。

Ｌ７ＳＷクライアント２５は、Ｌ７ＳＷサーバ１１９との間にセッションを確立する。Ｌ７ＳＷクライアント２５は、新規のメッセージＩＤ（０x１２）と、送信元種類と、送信先種類を含めたＬ７ヘッダ７２をＡＰコマンドに付与しメッセージを生成する。Ｌ７ＳＷクライアント２５は、メッセージをＬ７ＳＷサーバ１１９に送信する（Ｓ９０３）。

Ｌ７ＳＷサーバ１１９は、メッセージを受信し、メッセージ内のメッセージＩＤ（０x１２）に基づくスレッドを管理する（９００）。メッセージＩＤ０x１２のスレッドを破線で示す。Ｌ７ＳＷサーバ１１９は、メッセージに基づきＬ７ＳＷテーブル４１を更新する。

Ｌ７ＳＷサーバ１１９は、メッセージのＬ７ヘッダを除去しＡＰコマンドを生成する。なお、この例ではＡＰコマンドに、実データの存在を意味する（Data Flag ON）の識別子が含まれる。Ｌ７ＳＷサーバ１１９は、ＡＰコマンドをＢＭＣＡＰＰ１１３に送信する（Ｓ９０４）。

ＢＭＣＡＰＰ１１３は、ＡＰコマンドを受信し、Ｌ７ＳＷサーバ１１９に受信応答を送信する（Ｓ９０６）。この例では、ＡＰコマンドの受信応答（ＡＰ応答）のＡＰヘッダには、正常応答である旨の識別子（ACK Flag ON）が含まれる。

Ｌ７ＳＷサーバ１１９は、ＡＰ応答を受信し、Ｌ７ＳＷクライアント２５に対し、メッセージの受信応答（メッセージ応答）を送信する（Ｓ９０７）。なお、メッセージ応答には、対応するメッセージと同じメッセージＩＤ０x１２が付与される。

ＢＭＣＡＰＰ１１３は、ＡＰＩＤを解釈し、その要求に基づく処理を実行する。この例では、ＡＰＩＤが０x８４であるので、ＢＭＣＡＰＰ１１３は、ＢＭＣ構成情報を参照し、情報を返す処理を実行する（図２参照）。

ＢＭＣＡＰＰ１１３は、処理が終了した後、ＡＰコマンドに基づく処理の結果に基づきＡＰ処理応答を生成し、ＡＰ処理応答をＬ７ＳＷサーバ１１９に送信する（Ｓ９１１）。なお、ＡＰ処理応答は、結果となるデータに通信ＡＰＰヘッダ７１を付したＡＰコマンドの形式で送信される。この例では、ＡＰ処理応答のＡＰヘッダには、実データの存在を意味する識別子に（Data Flag ON）が含まれる。

Ｌ７ＳＷサーバ１１９は、ＡＰ処理応答を受信し、ＡＰ処理応答に基づきメッセージ処理応答を生成し、メッセージ処理応答をＬ７ＳＷクライアント２５に送信する（Ｓ９１２）。メッセージ処理応答は、ＡＰ処理応答にＬ７ヘッダを付与して生成される。このＬ７ヘッダには、当該処理要求のメッセージに含まれるメッセージＩＤに関連するメッセージＩＤが含まれる。具体的には、この例では、処理要求のメッセージＩＤ０x１２に０ｘ１０を加えて０x２２とする。

Ｌ７ＳＷクライアント２５は、メッセージ処理応答を受信し、管理アプリケーション＃Ａに関数Ｃに基づく要求の結果及び完了応答を通知する（Ｓ９１３）。

管理アプリケーション＃Ａは、結果及び完了応答を受信し、完了応答の受信応答をＬ７ＳＷクライアント２５に通知する（Ｓ９１４）。

Ｌ７ＳＷクライアント２５は、受信応答を受信し、その受信応答にＬ７ヘッダを付与したメッセージ受信応答を、Ｌ７ＳＷサーバ１１９に送信する（Ｓ９１５）。メッセージ受信応答には、メッセージ処理応答と同一のメッセージＩＤ（０x２２）が含まれる。

Ｌ７ＳＷサーバ１１９は、メッセージ受信応答を受信し、メッセージ受信応答に基づきＬ７ＳＷテーブル４１を更新し、メッセージ受信応答のＬ７ヘッダを除去したＡＰ受信応答をＢＭＣＡＰＰ１１３に送信する（Ｓ９１６）。ＢＭＣＡＰＰ１１３は、ＡＰ受信応答を受信し、関数Ｃの要求に基づく通信を終了する。

図１０を説明する。ここでは、管理アプリケーション＃Ｂが、サーバＡＰＰ２３の関数Ｄをコール（関数ｃａｌｌＤ）する（Ｓ１００１）場合を説明する。サーバＡＰＰ２３は、要求Ｄに対応するＡＰＩＤを指定し、ＡＰＩＤ及び宛先をＢＭＣ１１とした通信ＡＰＰヘッダ７１をデータに付与しＡＰコマンドを生成する。サーバＡＰＰ２３は、ＡＰコマンドをＬ７ＳＷクライアント２５に引渡す（Ｓ１００２）。

この場合の管理アプリケーション＃Ｂ−ＢＭＣ１１間の通信も、管理アプリケーション＃Ａ−ＢＭＣ１１間の通信と基本的に同様である。ただし、要求に基づきＬ７ＳＷクライアント２５が生成するメッセージのメッセージＩＤが異なる（Ｓ１００３）。このメッセージは、メッセージＩＤ０x１３が付与される。Ｌ７ＳＷサーバ１１９は、ＢＭＣＡＰＰ１１３との間の通信を、メッセージのメッセージＩＤ（０x１３）に基づくスレッドで管理する（１０００）。破線で示すメッセージＩＤ０x１３のスレッドは、図９のメッセージＩＤ０ｘ１２のスレッドと基本的に同様である。

Ｌ７ＳＷサーバ１１９がＬ７ＳＷクライアント２５に送信するメッセージ応答には、メッセージと同じメッセージＩＤ０x１３が付与される。

なお、Ｌ７ＳＷサーバ１１９及びＬ７ＳＷクライアント２５間のメッセージ処理応答及びメッセージ受信応答のＬ７ヘッダには、当該メッセージのメッセージに関連するメッセージＩＤ（０x２３）が含まれる（Ｓ１０１２、Ｓ１０１５）。

上記の通信では、管理アプリケーション２１が、ＢＭＣ１１に対する要求を行った場合であっても、ＭＰ１７に対する要求と同様にＬ７ＳＷクライアント２５がＬ７ヘッダ７１にメッセージＩＤを含めたメッセージを生成する。これにより、Ｌ７ヘッダを除去したＡＰコマンドでのＬ７ＳＷサーバ１１９とＢＭＣＡＰＰ１１３との間の通信もメッセージＩＤのスレッドで管理できる。つまり、Ｌ７ＳＷサーバ１１９は、宛先に関わらずＬ７クライアント２５から複数のメッセージをメッセージ毎に管理できる。図９及び１０は、メッセージの０ｘ１２系と０ｘ１３系の通信スレッドをシリアルに記載しているが、上記の通り多重での処理も可能である。

図１１は、保守端末−ＭＰ間の通信の一例を示すシーケンス図の一部である。

保守端末３がｗｅｂブラウザ３１を起動した場合、ｗｅｂブラウザ３１がｗｅｂサーバ１１１に接続する（ｈｔｔｐ／ｈｔｔｐｓ接続）（Ｓ１１０２）。

ｗｅｂサーバ１１１は、要求として、画面表示情報の取得要求を保守／ＵＩ ＡＰＩ１１７に送信する（Ｓ１１０３）。保守／ＵＩ ＡＰＩ１１７は、排他制御テーブル１２１を更新し、取得要求に基づき排他制御を実行し、宛先のＭＰを選択する。排他制御の詳細は後述する。保守／ＵＩ ＡＰＩ１１７は、取得要求に基づくＡＰＩＤを指定し、ＡＰＩＤをＢＭＣＡＰＰ１１３に引き渡す（Ｓ１１０５）。

ＢＭＣＡＰＰ１１３は、ＡＰＩＤ及び宛先のＭＰ番号を含めた通信ＡＰＰヘッダ７１をデータに付与しＡＰコマンドを生成する。ＢＭＣＡＰＰ１１３は、ＡＰコマンドを宛先ＭＰのＭＰＡＰＰ１７２に送信する（Ｓ１１０６）。なお、この例ではＡＰコマンドに、実データの存在を意味する（Data Flag ON）の識別子が含まれる。

ＭＰＡＰＰ１７２は、ＡＰコマンドを受信し、受信応答をＢＭＣＡＰＰ１１３に送信する（Ｓ１１０８）。この例では、ＡＰコマンドの受信応答（ＡＰ応答）のＡＰヘッダには、正常応答である旨の識別子（ACK Flag ON）が含まれる。

ＢＭＣＡＰＰ１１３は、ＡＰ応答を受信し、保守／ＵＩ ＡＰＩ１１７に取得要求に対する受信応答を引き渡す（Ｓ１１０９）。

ＭＰＡＰＰ１７２は、ＡＰＩＤ及びデータをメインマイクロ１７１に引き渡す（Ｓ１１１０）。

メインマイクロ１７１は、ＡＰＩＤを解釈し、その要求に基づく処理を実行する。この例では、ＡＰＩＤが０x０４であるので、メインマイクロ１７１は、構成情報を参照する処理を実行する（図２参照）。メインマイクロ１７１は、処理が終了した後、ＡＰコマンドに基づく処理の結果を、ＭＰＡＰＰ１７２に引き渡す（Ｓ１１１２）。

ＭＰＡＰＰ１７２は、メインマイクロ１７１から処理の結果となる画面表示用データを取得し、このデータに基づきＡＰ処理応答を生成し、ＡＰ処理応答をＢＭＣＡＰＰ１１３に送信する（Ｓ１１１３）。なお、ＡＰ処理応答は、結果となるデータに通信ＡＰＰヘッダ７１を付したＡＰコマンドの形式で送信される。この例では、ＡＰ処理応答のＡＰヘッダには、実データの存在を意味する識別子に（Data Flag ON）が含まれる。なお、ＡＰ処理応答は、画面表示用データのデータ量に応じて、データを分割して送信される。

ＢＭＣＡＰＰ１１３は、ＡＰ処理応答を受信し、通信ＡＰＰヘッダ７１を除去した処理応答を保守／ＵＩ ＡＰＩ１１７に引き渡す（Ｓ１１１４）。なお、処理応答は、画面表示用データのデータ量に応じて、データを分割して引き渡される。

保守／ＵＩ ＡＰＩ１１７は、処理応答を取得し、その受信応答をＢＭＣＡＰＰ１１３に引き渡す（Ｓ１１１７）。ＢＭＣＡＰＰ１１３は、受信応答にデータ通信ＡＰＰヘッダを付したＡＰ受信応答をＭＰＡＰＰ１７２に送信する（Ｓ１１２１）。この例では、ＡＰ受信応答のＡＰヘッダには、正常応答である旨の識別子（ACK Flag ON）が含まれる。

保守／ＵＩ ＡＰＩ１１７は、処理応答に基づき排他制御テーブルを更新し、画面表示用データをｗｅｂサーバ１１１に送信する（Ｓ１１１８）。

ｗｅｂサーバ１１１は、画面表示用データをｗｅｂブラウザ３１に送信する（Ｓ１１１９）。これにより、ｗｅｂブラウザ３１上で装置の状態が表示される。

上記処理により、保守端末３のｗｅｂブラウザ３１からユーザ又は保守員が直接操作した場合であっても、ＢＭＣ１１０の保守ＵＩ／ＵＩＡＰＩ１１７を介してＭＰ１７の情報を取得できる。なお、ここでは、保守端末３のｗｅｂブラウザ３１からｗｅｂサーバ１１１を介して保守ＵＩ／ＵＩＡＰＩ１１７にアクセスしていたが（直接ラウンチ）、管理アプリケーションを介して保守ＵＩ／ＡＰＩ１１７にアクセスされてもよい（間接ラウンチ）。

図１２は、保守端末−ＭＰ間の通信の他の例を示すシーケンス図である。

保守端末３がｗｅｂブラウザ３１を起動した場合、ｗｅｂブラウザ３１がｗｅｂサーバ１１１に接続する（ｈｔｔｐ／ｈｔｔｐｓ接続）（Ｓ１２０２）。ユーザは、ｗｅｂブラウザを介して障害が発生した制御基板中のＭＰ（対象ＭＰ）の閉塞を指示する（保守閉塞指示）。

ｗｅｂサーバ１１１は、保守閉塞指示に基づき、対象ＭＰの閉塞要求を保守／ＵＩ ＡＰＩ１１７に引き渡す（Ｓ１２０３）。保守／ＵＩ ＡＰＩ１１７は、取得要求に基づき排他制御テーブル１２１を更新する。テーブル１２１の更新は、対象ＭＰをエントリ禁止とする。保守／ＵＩ ＡＰＩ１１７は、取得要求をＢＭＣＡＰＰ１１３に引き渡す（Ｓ１２０５）。

ＢＭＣＡＰＰ１１３は、取得要求に基づくＡＰＩＤを指定し、ＡＰＩＤ及び対象ＭＰ番号を含めた通信ＡＰＰヘッダ７１をデータに付与しＡＰコマンドを生成する。ＢＭＣＡＰＰ１１３は、ＡＰコマンドを対象ＭＰのＭＰＡＰＰ１７２に送信する（Ｓ１２０６）。なお、この例ではＡＰコマンドに、実データの存在を意味する（Data Flag ON）の識別子が含まれる。

ＭＰＡＰＰ１７２は、ＡＰコマンドを受信し、受信応答をＢＭＣＡＰＰ１１３に送信する（Ｓ１２０８）。この例では、ＡＰコマンドの受信応答（ＡＰ応答）のＡＰヘッダには、正常応答である旨の識別子（ACK Flag ON）が含まれる。

ＢＭＣＡＰＰ１１３は、ＡＰ応答を受信し、保守ＵＩ ＡＰＩ１１７に取得要求に対する受信応答を引き渡す（Ｓ１２０９）。

ＭＰＡＰＰ１７２は、ＡＰＩＤ及びデータをメインマイクロ１７１に引き渡す（Ｓ１２１０）。

メインマイクロ１７１は、ＡＰＩＤを解釈し、その要求に基づく処理を実行する。この例では、ＡＰＩＤが０x１０であるので、メインマイクロ１７１は、自身の閉塞処理を実行し、その結果を、ＭＰＡＰＰ１７２に引き渡す（Ｓ１２１２）。

ＭＰＡＰＰ１７２は、メインマイクロ１７１から処理の結果である閉塞完了通知を取得し、これに基づきＡＰ処理応答を生成し、ＡＰ処理応答をＢＭＣＡＰＰ１１３に送信する（Ｓ１２１３）。なお、ＡＰ処理応答は、結果となるデータ（閉塞完了通知）に通信ＡＰＰヘッダ７１を付したＡＰコマンドの形式で送信される。この例では、ＡＰ処理応答のＡＰヘッダには、実データの存在を意味する識別子に（Data Flag ON）が含まれる。なお、ここでの閉塞処理はＩ／Ｏ制御モジュールの閉塞処理であり、ＡＰ処理応答が返却可能な例である。ＭＰ１７全体を閉塞させる処理の場合には、ＡＰ処理応答が返却されない場合もある。

ＢＭＣＡＰＰ１１３は、ＡＰ処理応答を受信し、通信ＡＰＰヘッダ７１を除去した処理応答を保守／ＵＩ ＡＰＩ１１７に引き渡す（Ｓ１２１４）。

保守／ＵＩ ＡＰＩ１１７は、処理応答を受信し、その受信応答をＢＭＣＡＰＰ１１３に引き渡す（Ｓ１２１７）。ＢＭＣＡＰＰ１１３は、受信応答にデータ通信ＡＰＰヘッダを付したＡＰ受信応答をＭＰＡＰＰ１７２に送信する（Ｓ１２２１）。この例では、ＡＰ受信応答のＡＰヘッダには、正常応答である旨の識別子（ACK Flag ON）が含まれる。

保守／ＵＩ ＡＰＩ１１７は、処理応答に基づき排他制御テーブルを更新し、対象ＭＰの閉塞完了通知をｗｅｂサーバ１１１に引き渡す送信する（Ｓ１２２２）。

ｗｅｂサーバ１１１は、対象ＭＰの閉塞が完了した旨をｗｅｂブラウザ３１に表示する（Ｓ１２２３）（保守閉塞完了Mssg転送）。

保守／ＵＩ ＡＰＩ１１７は、処理応答に基づき画面表示用データ（更新情報）をｗｅｂサーバ１１１に送信する（Ｓ１２２４）。ｗｅｂサーバ１１１は、画面表示用データ（更新情報）をｗｅｂブラウザ３１に送信する（Ｓ１２２５）。これにより、ｗｅｂブラウザ３１上で対象ＭＰ閉塞後の装置の状態が表示される。

上記処理により、保守端末３のｗｅｂブラウザ３１からユーザ又は保守員が直接操作した場合であっても（直接ラウンチ）、ＢＭＣ１１０の保守ＵＩ／ＵＩＡＰＩ１１７を介して障害のある制御基板中のＭＰ１７を閉塞し、その後の装置の状態を取得できる。なお、ここでは、保守端末３のｗｅｂブラウザ３１からｗｅｂサーバ１１１を介して保守ＵＩ／ＵＩＡＰＩ１１７にアクセスしていたが、管理アプリケーションを介して保守ＵＩ／ＡＰＩ１１７にアクセスされてもよい（間接ラウンチ）。

図１３は、排他制御のフローチャートの一例である。

この処理は、ＭＰ１７に対する要求を受信したＢＭＣ１１の各部（Ｌ７ＳＷサーバ１１９又は保守／ＵＩ ＡＰＩ１１７）が実行する処理である。本実施例では、Ｌ７ＳＷサーバ１１９がＬ７ＳＷクライアント２５からメッセージを受信した場合、又は、保守／ＵＩ ＡＰＩ１１７がｗｅｂサーバ１１１を介してユーザからの要求を受信した場合に、それらの要求の宛先のＭＰを決定する処理である。以下では、処理の主体をＢＭＣ１１として説明する。

ＢＭＣ１１は、要求対象のＭＰが指定されているか否かを判定する（Ｓ１３０１）。要求の対象となるＭＰが指定されている場合（Ｓ１３０１；指定）、ＢＭＣ１１は、排他制御テーブル１２１に基づき指定のＭＰのステータスを判定する（S１３０３）。指定のＭＰのステータスがエントリ待ち以外の場合、つまり、実行中又はエントリ禁止の場合、ＢＭＣ１１はエラーコードをＢＭＣＡＰＰ１１３に引き渡し（Ｓ１３０６）、処理を終了する。

一方、要求の対象となるＭＰが指定されていない場合（Ｓ１３０１；ａｎｙ）、ＢＭＣ１１は、排他制御テーブル１２１に基づきステータスが“エントリ待ち”のＭＰがあるか否かを判定する（Ｓ１３０２）。“エントリ待ち”のＭＰがない場合（Ｓ１３０２；Ｎｏ）ＢＭＣ１１はエラーコードをＢＭＣＡＰＰ１１３に引き渡し（Ｓ１３０６）、処理を終了する。

“エントリ待ち”のＭＰがある場合（Ｓ１３０２；Ｙｅｓ）ＢＭＣ１１は、エントリ待ちの１つのＭＰを宛先ＭＰとして選択する（Ｓ１３０４）。そして、ＢＭＣ１１は、選択された宛先ＭＰに基づき、排他制御テーブル１２１を更新し、処理を終了する（Ｓ１３０５）。具体的には、ＢＭＣ１１は、宛先ＭＰのステータス５０２を“実行中”とし、自身が送信するＡＰコマンドに含まれるＡＰＩＤを、エントリ中ＩＤ５０３に指定するとともに、要求に応じて要求元ＩＤ種５０４、要求元ＩＤ５０５及び要求元ＩＰ５０６を指定する。ただし、前述の通り、エントリ中ＡＰＩＤ５０３、要求元ＩＤ種５０４、要求元ＩＤ５０５及び要求元ＩＰ５０６は管理目的の情報であるため、ＢＭＣ１１はこれらを指定しなくてもよい。

上記処理により、要求に宛先ＭＰが指定されていない場合は、エントリ可能なＭＰを宛先ＭＰに指定できる。また、要求に宛先ＭＰが指定されている場合も、宛先ＭＰがエントリ可能な状態か否かを判定できる。このようにすることで、ＢＭＣのＬ７ＳＷサーバ１１９は、複数の要求を受信した場合であっても、それらの要求を効率よくＭＰに振り分けることができる。

また、直接ラウンチ及び間接ラウンチにおいて、宛先ＭＰを指定しない指示があった場合は、エントリ可能なＭＰを宛先ＭＰに指定できる。また、宛先ＭＰが指定された指示の場合は、宛先ＭＰがエントリ可能な状態か否かを判定できる。

なお、本発明は、本実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

１：ストレージ装置 ２：管理サーバ ３：保守端末 ５：管理ＬＡＮ １０：コントローラ １１：ＢＭＣ １５：内部ＬＡＮ １７：メインプロセッサ

Claims (10)

1. 管理サーバ計算機及びストレージ装置を備え、
   前記ストレージ装置は、
   第１ネットワークを介して前記管理サーバ計算機に接続される管理プロセッサと、
   前記管理プロセッサに第２ネットワークを介して接続され、かつ、記憶デバイスに接続されて前記記憶デバイスへのＩ／Ｏを実行する複数のＩ／Ｏプロセッサと、
   を有し、
   前記管理サーバ計算機は、前記複数のＩ／ＯプロセッサのうちのいずれかのＩ／Ｏプロセッサのためのコマンドを生成し、
   前記管理サーバ計算機は、前記コマンドをカプセル化しかつ暗号化して暗号化メッセージを生成し、前記暗号化メッセージを前記管理プロセッサへ送信し、
   前記管理プロセッサは、前記暗号化メッセージを受信し、前記暗号化メッセージを復号化しかつカプセル化を解除して前記コマンドを復元し、前記コマンドに基づいて、前記複数のＩ／ＯプロセッサのうちのＩ／Ｏプロセッサを第１宛先として選択し、前記第１宛先に対して前記コマンドを送信する、
   ストレージシステム。
2. 前記管理サーバ計算機が前記コマンドに前記複数のＩ／Ｏプロセッサのうちの第１Ｉ／Ｏプロセッサを指定した場合、前記管理プロセッサは、前記コマンドで指定された前記第１プロセッサを前記第１宛先として選択する、
   請求項１に記載のストレージシステム。
3. 前記管理プロセッサは、前記複数のＩ／Ｏプロセッサの状態を示す状態情報を記憶し、
   前記管理プロセッサは、前記状態情報に基づき、前記第１Ｉ／Ｏプロセッサが処理を受付できるエントリ待ち状態であるか否かを判定し、
   前記管理プロセッサは、前記第１Ｉ／Ｏプロセッサがエントリ待ち状態である場合に前記コマンドを前記第１Ｉ／Ｏプロセッサへ送信する、
   請求項２に記載のストレージシステム。
4. 前記管理サーバ計算機が前記コマンドにＩ／Ｏプロセッサを指定していない場合、前記管理プロセッサは、前記状態情報に基づき前記複数のＩ／Ｏプロセッサのうちの、エントリ待ち状態である第２Ｉ／Ｏプロセッサを前記第１宛先として選択し、
   前記管理プロセッサは、前記コマンドに前記第１宛先を指定し、前記第２Ｉ／Ｏプロセッサに送信する、
   請求項３に記載のストレージシステム。
5. 前記管理サーバ計算機は、前記管理プロセッサに対する管理コマンドを発行し、
   前記管理サーバ計算機は、前記管理コマンドをカプセル化しかつ暗号化して暗号化管理メッセージを生成し、前記暗号化管理メッセージを前記管理プロセッサへ送信し、
   前記管理プロセッサは、前記暗号化管理メッセージを受信し、前記暗号化管理メッセージを復号化し前記カプセル化を解除して前記管理コマンドを復元し、前記管理コマンドに基づく処理を実行する、
   請求項４に記載のストレージシステム。
6. 前記第１ネットワークを介して前記ストレージ装置及び前記管理サーバ計算機に接続される保守端末装置をさらに備え、
   前記保守端末装置は、前記管理プロセッサに対して、前記複数のＩ／ＯプロセッサのうちのいずれかのＩ／Ｏプロセッサのための要求を送信し、
   前記管理プロセッサは、前記要求に基づいて、前記複数のＩ／ＯプロセッサのうちのＩ／Ｏプロセッサを第２宛先として選択しかつ保守コマンドを生成し、前記第２宛先に前記保守コマンドを送信する、
   請求項５に記載のストレージシステム。
7. 前記保守端末装置が前記要求に前記複数のＩ／Ｏプロセッサの中の第３Ｉ／Ｏプロセッサを指定した場合、前記管理プロセッサは、前記第３Ｉ／Ｏプロセッサを前記第２宛先として選択し、前記状態情報に基づき、前記第３Ｉ／Ｏプロセッサが前記要求に基づく処理を受付できるエントリ待ち状態か否かを判定し、
   前記管理プロセッサは、前記第３Ｉ／Ｏプロセッサがエントリ待ち状態である場合に、前記保守コマンドを前記第３Ｉ／Ｏプロセッサへ送信する、
   請求項６に記載のストレージシステム。
8. 前記保守端末装置が前記要求にＩ／Ｏプロセッサを指定していない場合、前記管理プロセッサは、前記状態情報に基づき、前記複数のＩ／Ｏプロセッサのうちの、エントリ待ち状態である第４Ｉ／Ｏプロセッサを前記第２宛先として選択し、
   前記第４Ｉ／Ｏプロセッサに対して前記保守コマンドを送信する、
   請求項７に記載のストレージシステム。
9. 前記管理サーバ計算機は、前記複数のＩ／ＯプロセッサのうちのいずれかのＩ／Ｏプロセッサに対する処理の指示を前記管理プロセッサへ送信し、
   前記管理プロセッサは、前記指示に基づいて、前記複数のＩ／Ｏプロセッサのうちの第２宛先を選択し、前記指示に基づいて前記コマンドを生成し、前記第２宛先に前記コマンドを送信する、
   請求項８に記載のストレージシステム。
10. 第１ネットワークを介して管理サーバ計算機に接続される管理プロセッサと、
    前記管理プロセッサに第２ネットワークを介して接続され、かつ、記憶デバイスに接続されて前記記憶デバイスのＩ／Ｏを実行する複数のＩ／Ｏプロセッサと、
    を有し、
    前記管理サーバ計算機から、前記複数のＩ／ＯプロセッサのうちのいずれかのＩ／Ｏプロセッサのための、カプセル化されかつ暗号化されたコマンドである暗号化メッセージを受信した場合、前記管理プロセッサは、前記コマンドに基づいて、前記暗号化メッセージを復号化しかつカプセル化を解除して前記コマンドを復元し、前記コマンドに基づいて、前記複数のＩ／ＯプロセッサのうちのＩ／Ｏプロセッサを第１宛先として選択し、前記第１宛先に対して前記コマンドを送信する、
    ストレージ装置。
    
    

Images