図面 (/)

技術 情報処理装置、更新時間推定プログラム、及び更新時間推定方法

出願人 富士通株式会社
発明者 村山孝松尾文男榎原勝男大和貴明平島伸幸伴全栗原拓弥竹内利明
出願日 2014年12月5日 (7年2ヶ月経過) 出願番号 2014-246882
公開日 2016年6月20日 (5年7ヶ月経過) 公開番号 2016-110372
状態 特許登録済
技術分野 ストアードプログラム
主要キーワード 各対象装置 分岐ルート ルートブロック 時間推定処理 分岐ポイント 要素管理テーブル リスト構造体 モデル単位
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年6月20日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

ソフトウェア更新処理が行なわれるモジュールを複数含む対象装置について、更新時間を容易に推定する。

解決手段

ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置1aに対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報22に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第1処理ブロックを特定する特定部25と、前記複数の更新処理の各々にかかる更新時間を示す情報32を用いて、前記特定部25が特定した第1処理ブロックごとの更新時間を推定する第1推定部26,27と、更新時間を示す情報32及び前記第1推定部26,27が推定した第1処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置1aの更新時間を推定する第2推定部28と、をそなえる。

概要

背景

サーバストレージ、及びネットワーク機器等を含むシステムでは、システム内の一部の装置のファームウェアについてアップデート(以下、ファームアップともいう)が行なわれることがある。

このようなシステムでは、一部の装置がファームアップされる間、他の装置への影響を考慮して関連するシステムの運用が停止される。このため、ファームアップの作業者は、一部の装置のファームアップが可能な時間帯をシステムの運用スケジュールに照らし合わせて決定し、ファームアップのスケジュールを決定することになる。

ところで、複数の装置を組み合わせた複合システムがファームアップ対象の装置(対象装置)となる場合がある。複合システムとしては、例えば複数の装置(部品)を含み、部品単位製品化されている部品を組み合わせて、別の固有な機能を持った製品形態を構成した装置が挙げられる。また、複合システムとして、例えばCPU(Central Processing Unit)やメモリ等を含む複数のモジュールをそなえ、各モジュールに装置全体を制御するための機能を分割配置し、各モジュールの機能をファームウェアによって制御する形態の装置も挙げられる。

以下、このような複合システムとして、仮想テープライブラリ装置を例に挙げて説明する。仮想テープライブラリ装置は、例えば制御装置、RAID(Redundant Arrays of Inexpensive Disks)装置、LAN(Local Area Network)ハブ、FC(Fibre Channel)スイッチ、電源制御装置テープライブラリ装置等の部品を搭載することができる。

仮想テープライブラリ装置は、図33に例示するように、複数のモデル及びオプション構成が存在し、これらの構成別に、構成部品のタイプや搭載台数等が異なる。図33の例では、モデルAの基本構成は、制御装置、RAID装置、LANハブ、FCスイッチ、電源制御装置、テープライブラリ装置Aであり、モデルBの基本構成は、モデルAの基本構成に対して、FCスイッチを無くしテープライブラリ装置Aとは製品仕様が異なるテープライブラリ装置Bにしたものである。また、モデルCの基本構成は、モデルAの基本構成に対して、テープライブラリ装置Aとは製品仕様が異なるテープライブラリ装置Cにしたものであり、モデルCのオプション構成であるマルチLIB(Library)構成は、モデルCの基本構成に対して、テープライブラリ装置Cを2台設けたものである。

仮想テープライブラリ装置のファームアップでは、各部品の更新ファームウェアをまとめた更新ファームセットが提供され、作業者は、各部品をそれぞれ指定されたファーム版数更新する作業を行なう。更新の手順は、仮想テープライブラリ装置の構成により予めモデル単位装置構成単位)で定義された更新手順(以下、アップデートフローという)に基づいて実施される。

図34は、モデル別に定義されたアップデートフローと総ファームアップ推定時間との関係を例示する図である。図34に示すように、モデルA〜モデルCの各々は、それぞれの搭載する部品が異なり、互いに異なるアップデートフローとなるため、総ファームアップにかかる推定時間も互いに異なるものとなる。なお、図34に示すアップデートフローは、説明のためモデルごとの差異を明確に示したものであり、図33に示すモデルA〜Cの実際のアップデートフローとは異なる。

仮想テープライブラリ装置のファームアップでは、図34に例示するアップデートフロー(手順書)に従って、作業者がそれぞれの部品のファームアップを個々に行なうことになる。

次に、図35を参照して作業者が複合システムのファームアップを行なう手順の一例を説明する。

まず、作業者は、ファームアップ対象のモデルを判別し、対応するアップデートフローを入手して(ステップS101)、アップデートフローに従い、ファームアップする部品を選択する(ステップS102)。そして、作業者は、選択した部品の版数が変更されているか否かを判断する(ステップS103)。

選択した部品の版数が変更されている場合(ステップS103のYesルート)、作業者は、更新ファームセットから対象部品のファームウェアを取り出し、対象部品をファームアップして(ステップS104)、処理がステップS105に移行する。選択した部品の版数が変更されていない場合も(ステップS103のNoルート)、処理がステップS105に移行する。

ステップS105では、作業者が、構成部品で他に並行してファームアップ可能な部品があるか否かを判断し、ある場合には(ステップS105のYesルート)、処理がステップS103に移行する。一方、他に並行してファームアップ可能な部品がない場合には(ステップS105のNoルート)、作業者は、部品ごとにファームアップの完了を待ち受ける(ステップS106,S106のNoルート)。

ファームアップが完了した部品がある場合(ステップS106のYesルート)、作業者は、構成部品でファームアップが可能となった部品があるか否かを判断し(ステップS107)、ある場合には(ステップS107のYesルート)、処理がステップS103に移行する。一方、構成部品でファームアップが可能となった部品がない場合(ステップS107のNoルート)、作業者は、全ての構成部品のアップデートが完了したか否かを判断する(ステップS108)。完了していない場合(ステップS108のNoルート)、処理がステップS106に移行する。

全ての構成部品のアップデートが完了した場合(ステップS108のYesルート)、処理が終了する。

なお、ファームウェアの更新時間を算出する手法としては、種々の技術が知られている(例えば、下記特許文献1及び2参照)。

概要

ソフトウェア更新処理が行なわれるモジュールを複数含む対象装置について、更新時間を容易に推定する。ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置1aに対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報22に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第1処理ブロックを特定する特定部25と、前記複数の更新処理の各々にかかる更新時間を示す情報32を用いて、前記特定部25が特定した第1処理ブロックごとの更新時間を推定する第1推定部26,27と、更新時間を示す情報32及び前記第1推定部26,27が推定した第1処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置1aの更新時間を推定する第2推定部28と、をそなえる。

目的

本発明は、ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置について、更新時間を容易に推定することを目的とする

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ソフトウェア更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第1処理ブロックを特定する特定部と、前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定部が特定した第1処理ブロックごとの更新時間を推定する第1推定部と、更新時間を示す情報及び前記第1推定部が推定した第1処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する第2推定部と、をそなえることを特徴とする、情報処理装置

請求項2

前記第1推定部は、前記更新時間を示す情報を用いて、前記特定部が特定した第1処理ブロックにおいて並行して更新処理が実行されるルートごとの更新時間を推定し、ルートごとに推定した更新時間のうちの最長の更新時間を当該第1処理ブロックの更新時間として推定する、ことを特徴とする、請求項1記載の情報処理装置。

請求項3

前記特定部は、前記実行順序を示す情報に基づき、前記複数の更新処理から、シーケンシャルに実行される一以上の更新処理を一処理ブロックとした一以上の第2処理ブロックを特定し、前記第1推定部は、前記更新時間を示す情報を用いて、前記特定部が特定した第2処理ブロックにおける更新処理の更新時間を合計し、合計した更新時間を当該第2処理ブロックの更新時間と推定し、前記第2推定部は、前記第1推定部が推定した第1処理ブロックごとの更新時間及び第2処理ブロックごとの更新時間を合計することで、前記対象装置の更新時間を推定する、ことを特徴とする、請求項2記載の情報処理装置。

請求項4

互いに装置構成の異なる複数の対象装置について、各対象装置が含む複数のモジュールに係る複数の更新処理の実行順序を示す情報を、装置構成と対応付けて保持する保持部と、一の対象装置から当該一の対象装置の装置構成を示す情報を取得し、取得した装置構成に対応する実行順序を示す情報を前記保持部から取得する取得部と、をさらにそなえることを特徴とする、請求項1〜請求項3のいずれか1項記載の情報処理装置。

請求項5

前記更新時間を示す情報には、更新前のソフトウェアの版数ごとに更新時間が設定され、前記第1推定部は、一の対象装置から当該一の対象装置に係る更新前のソフトウェアの版数を示す情報を取得し、取得した情報が示す版数に対応する更新時間を、前記更新時間を示す情報から抽出し、抽出した更新時間を用いて前記推定を行なう、ことを特徴とする、請求項1〜請求項4のいずれか1項記載の情報処理装置。

請求項6

コンピュータに、ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第1処理ブロックを特定し、前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定した第1処理ブロックごとの更新時間を推定し、更新時間を示す情報及び前記推定した第1処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する、処理を実行させることを特徴とする、更新時間推定プログラム

請求項7

ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置を管理する情報処理装置における更新時間推定方法であって、前記情報処理装置が、ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第1処理ブロックを特定し、前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定した第1処理ブロックごとの更新時間を推定し、更新時間を示す情報及び前記推定した第1処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する、ことを特徴とする、更新時間推定方法。

技術分野

0001

本発明は、情報処理装置更新時間推定プログラム、及び更新時間推定方法に関する。

背景技術

0002

サーバストレージ、及びネットワーク機器等を含むシステムでは、システム内の一部の装置のファームウェアについてアップデート(以下、ファームアップともいう)が行なわれることがある。

0003

このようなシステムでは、一部の装置がファームアップされる間、他の装置への影響を考慮して関連するシステムの運用が停止される。このため、ファームアップの作業者は、一部の装置のファームアップが可能な時間帯をシステムの運用スケジュールに照らし合わせて決定し、ファームアップのスケジュールを決定することになる。

0004

ところで、複数の装置を組み合わせた複合システムがファームアップ対象の装置(対象装置)となる場合がある。複合システムとしては、例えば複数の装置(部品)を含み、部品単位製品化されている部品を組み合わせて、別の固有な機能を持った製品形態を構成した装置が挙げられる。また、複合システムとして、例えばCPU(Central Processing Unit)やメモリ等を含む複数のモジュールをそなえ、各モジュールに装置全体を制御するための機能を分割配置し、各モジュールの機能をファームウェアによって制御する形態の装置も挙げられる。

0005

以下、このような複合システムとして、仮想テープライブラリ装置を例に挙げて説明する。仮想テープライブラリ装置は、例えば制御装置、RAID(Redundant Arrays of Inexpensive Disks)装置、LAN(Local Area Network)ハブ、FC(Fibre Channel)スイッチ、電源制御装置テープライブラリ装置等の部品を搭載することができる。

0006

仮想テープライブラリ装置は、図33に例示するように、複数のモデル及びオプション構成が存在し、これらの構成別に、構成部品のタイプや搭載台数等が異なる。図33の例では、モデルAの基本構成は、制御装置、RAID装置、LANハブ、FCスイッチ、電源制御装置、テープライブラリ装置Aであり、モデルBの基本構成は、モデルAの基本構成に対して、FCスイッチを無くしテープライブラリ装置Aとは製品仕様が異なるテープライブラリ装置Bにしたものである。また、モデルCの基本構成は、モデルAの基本構成に対して、テープライブラリ装置Aとは製品仕様が異なるテープライブラリ装置Cにしたものであり、モデルCのオプション構成であるマルチLIB(Library)構成は、モデルCの基本構成に対して、テープライブラリ装置Cを2台設けたものである。

0007

仮想テープライブラリ装置のファームアップでは、各部品の更新ファームウェアをまとめた更新ファームセットが提供され、作業者は、各部品をそれぞれ指定されたファーム版数に更新する作業を行なう。更新の手順は、仮想テープライブラリ装置の構成により予めモデル単位装置構成単位)で定義された更新手順(以下、アップデートフローという)に基づいて実施される。

0008

図34は、モデル別に定義されたアップデートフローと総ファームアップ推定時間との関係を例示する図である。図34に示すように、モデルA〜モデルCの各々は、それぞれの搭載する部品が異なり、互いに異なるアップデートフローとなるため、総ファームアップにかかる推定時間も互いに異なるものとなる。なお、図34に示すアップデートフローは、説明のためモデルごとの差異を明確に示したものであり、図33に示すモデルA〜Cの実際のアップデートフローとは異なる。

0009

仮想テープライブラリ装置のファームアップでは、図34に例示するアップデートフロー(手順書)に従って、作業者がそれぞれの部品のファームアップを個々に行なうことになる。

0010

次に、図35を参照して作業者が複合システムのファームアップを行なう手順の一例を説明する。

0011

まず、作業者は、ファームアップ対象のモデルを判別し、対応するアップデートフローを入手して(ステップS101)、アップデートフローに従い、ファームアップする部品を選択する(ステップS102)。そして、作業者は、選択した部品の版数が変更されているか否かを判断する(ステップS103)。

0012

選択した部品の版数が変更されている場合(ステップS103のYesルート)、作業者は、更新ファームセットから対象部品のファームウェアを取り出し、対象部品をファームアップして(ステップS104)、処理がステップS105に移行する。選択した部品の版数が変更されていない場合も(ステップS103のNoルート)、処理がステップS105に移行する。

0013

ステップS105では、作業者が、構成部品で他に並行してファームアップ可能な部品があるか否かを判断し、ある場合には(ステップS105のYesルート)、処理がステップS103に移行する。一方、他に並行してファームアップ可能な部品がない場合には(ステップS105のNoルート)、作業者は、部品ごとにファームアップの完了を待ち受ける(ステップS106,S106のNoルート)。

0014

ファームアップが完了した部品がある場合(ステップS106のYesルート)、作業者は、構成部品でファームアップが可能となった部品があるか否かを判断し(ステップS107)、ある場合には(ステップS107のYesルート)、処理がステップS103に移行する。一方、構成部品でファームアップが可能となった部品がない場合(ステップS107のNoルート)、作業者は、全ての構成部品のアップデートが完了したか否かを判断する(ステップS108)。完了していない場合(ステップS108のNoルート)、処理がステップS106に移行する。

0015

全ての構成部品のアップデートが完了した場合(ステップS108のYesルート)、処理が終了する。

0016

なお、ファームウェアの更新時間を算出する手法としては、種々の技術が知られている(例えば、下記特許文献1及び2参照)。

先行技術

0017

特開2007−334636号公報
特開2003−058335号公報
特開2008−152482号公報
特開2012−043187号公報

発明が解決しようとする課題

0018

しかしながら、仮想テープライブラリ装置等の複合システムの総ファームアップ推定時間は、図34に例示するように、定義されたアップデートフロー(更新手順)、並びに、個々の部品についてのファームアップの有無及び推定時間等によって異なる。

0019

全体のシステムにおいて複合システムが活性状態の場合、当該複合システムのファームアップを行なうことは困難であり、この場合、当該複合システムのファームアップは、システムから切り離してから実施されることになる。

0020

このため、ファームアップの対象装置を使用している部門等で予め対象装置をファームアップするためのシステム運用スケジュールを立案することが好ましい。

0021

しかし、上述のように、対象装置としての複合システムのファームアップは、複数の部品等のモジュールがアップデートフローに従って処理される。従って、対象装置全体をファームアップするのにかかる総ファームアップ推定時間を容易に求めることは難しい。

0022

1つの側面では、本発明は、ソフトウェア更新処理が行なわれるモジュールを複数含む対象装置について、更新時間を容易に推定することを目的とする。

課題を解決するための手段

0023

1つの態様では、本件の情報処理装置は、特定部と、第1推定部と、第2推定部とをそなえる。前記特定部は、ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第1処理ブロックを特定する。前記第1推定部は、前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定部が特定した第1処理ブロックごとの更新時間を推定する。前記第2推定部は、更新時間を示す情報及び前記第1推定部が推定した第1処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する。

発明の効果

0024

1つの側面では、ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置について、更新時間を容易に推定することができる。

図面の簡単な説明

0025

複合システムのアップデートフローの一例を示す図である。
複合システムの部品ごとのファームアップ時間の一例を示す図である。
図2に示すファームアップ時間を図1に示すアップデートフローに適用した場合の更新時間の最長ルートの一例を示す図である。
一実施形態に係るシステムの構成例を示す図である。
一実施形態に係るシステムの詳細な構成例を示す図である。
一実施形態に係る運用コンソールの構成例を示す図である。
アップデートフローデータベースフローテーブルの一例を示す図である。
メインルートの一例を説明する図である。
分岐ルートの一例を説明する図である。
アップデートフローデータベースの要素管理テーブルの一例を示す図である。
図10に示す要素管理テーブルに部品ファームアップ処理を追加した場合の一例を示す図である。
分岐ポイントの一例を説明する図である。
合流ポイントの一例を説明する図である。
アップデートフローデータベースに基づくファームアップ手順の作成手法の一例を示す図である。
一実施形態に係るシステムの他の構成例を示す図である。
一実施形態に係るブロック分割部による処理ブロックの分割処理の一例を説明する図である。
一実施形態に係るブロック分割部による処理ブロックの分割処理の一例を説明する図である。
一実施形態に係るブロック分割部によるブロクルートの特定処理の一例を説明する図である。
一実施形態に係るブロック分割部によるブロックルートの特定処理の一例を説明する図である。
ファームアップ時間データベースの一例を示す図である。
一実施形態に係るファームアップ時間推定部による更新時間推定処理の一例を説明するフローチャートである。
一実施形態に係るDB選択部によるDB選択処理の一例を説明するフローチャートである。
一実施形態に係るブロック分割部によるブロック分割処理の一例を説明するフローチャートである。
一実施形態に係る推定時間選択部によるファームアップ時間選択処理の一例を説明するフローチャートである。
一実施形態に係る第1算出部によるブロック推定時間算出処理の一例を説明するフローチャートである。
実施例に係る複合システムのアップデートフローを示す図である。
実施例に係るファームアップ時間データベースを示す図である。
第1実施例に係るアップデートフローデータベースのフローテーブルを示す図である。
第1実施例に係る総ファームアップ推定時間の算出結果を示す図である。
第2実施例に係るアップデートフローデータベースのフローテーブルを示す図である。
第2実施例に係る総ファームアップ推定時間の算出結果を示す図である。
一実施形態に係る運用コンソールのハードウェア構成例を示す図である。
仮想テープライブラリ装置のモデル及びオプションごとの構成例を示す図である。
モデル別に定義されたアップデートフローと総ファームアップ推定時間との関係を例示する図である。
複合システムのファームアップを行なう手順の一例を説明するフローチャートである。

実施例

0026

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

0027

〔1〕複合システムの総ファームアップ推定時間について
はじめに、図1図3を参照しながら、複合システムの総ファームアップ推定時間について説明する。

0028

以下、複合システムが部品1〜部品9の9個の部品を含み、図1に例示するアップデートフローが定義されているものとして説明する。

0029

複合システムのファームアップを行なう際、作業者は、図1に示すファームアップ処理を上でシミュレートし、以下のような手順でファームアップの対象装置全体の推定時間を求めることが考えられる。

0030

(i)複合システムに適用されているファームウェアの版数情報から部品ごとのファーム更新の有無を調べる。
(ii) 使用するアップデートフローにそれぞれの部品のファームアップ時間を代入する。
(iii) アップデートフローに従い、ファームアップ対象の装置全体のファームアップにかかる時間を算出する。

0031

ここで、図1のアップデートフローにおいて、ポイント1及びポイント3は、処理が分岐して複数の部品が並行にファームアップされることを表す分岐ポイントを示す。また、ポイント2及びポイント4は、複数に分かれた分岐ルートが合流することを表す合流ポイントを示す。合流ポイントでは、対応する分岐ポイントで分岐された全てのルートの処理が完了したときに、先の処理に進むことができるものとする。

0032

複合システムの部品ごとのファームアップ時間の一例を図2に示す。図2のファームアップ時間を図1に示すアップデートフローに適用すると、図3に例示するように、矢印で示すルート(部品1,部品2,部品3,部品6,部品9)が最も時間のかかるルートであることが判明し、この時間が複合システムの総ファームアップ推定時間となる。

0033

具体的には、図3の例において、ポイント1からポイント2の分岐ルートでは、部品3+部品6のファームアップを行なう時間が残りの2ルート(部品4+部品7,部品5)よりも長い。従って、ポイント2では、残りの2ルートは、部品3+部品6のルートの完了を待ち合わせることになる。

0034

また、ポイント3からポイント4の分岐ルートでは、部品9のファームアップを行なう時間が部品8のファームアップを行なう時間よりも長く、部品8のルートは、部品9のルートの完了を待ち合わせることになる。

0035

よって、図3の例では、図1に示すアップデートフローを用いた複合システムの総ファームアップ推定時間は、部品1(20分)+部品2(10分)+部品3(80分)+部品6(40分)+部品9(60分)=総ファームアップ推定時間(210分)となる。

0036

以上のように、複合システムのファームアップにかかる更新時間は、作業者により机上で推定(算出)される。従って、複合システムの規模に従って、更新時間の計算が煩雑となり、作業者は、更新時間を容易に求めることが困難となる。

0037

〔2〕一実施形態
そこで、一実施形態に係るシステムでは、以下に詳述する手法により、ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置について、更新時間を容易に推定することを可能とする。

0038

〔2−1〕システムの構成例
以下、図4及び図5を参照して、一実施形態に係るシステムの構成例について説明する。一実施形態に係るシステムは、図4に例示するように、対象装置1及び対象装置1を管理する情報処理装置2をそなえる。

0039

対象装置1は、構成部品として、複数(図4の例ではm個;mは自然数)のモジュール100−1〜100−mをそなえる。以下、モジュール100−1〜100−mを区別しない場合には単にモジュール100という。対象装置1としては、例えば複合システムが挙げられる。

0040

情報処理装置2は、例えば対象装置1のベンダ等の開発元から提供される更新ファームセット30を入力され、対応する対象装置1に対する更新ファームセット30の適用(複数のモジュール100の各々のファームウェアの更新)を管理する。この管理には、例えば対象装置1に対する更新ファームセット30を用いたファームアップの更新時間の推定処理が含まれる。また、この管理には、対象装置1に対する更新ファームセット30の適用(更新)処理が含まれてもよい。

0041

次に、システムの詳細な構成例を説明する。図5に例示するように、システムは、仮想テープライブラリ装置1a、運用コンソール2a、及びホストサーバ3をそなえる。

0042

仮想テープライブラリ装置1aは、ホストサーバ3に対して、仮想テープライブラリを提供する装置であり、制御システム4と、1以上(図5の例では2つ)のテープライブラリ装置9a及び9bとをそなえる。

0043

テープライブラリ装置9a及び9bは、データを記憶する媒体カートリッジの一例としてのテープカートリッジ複数収納し、ホストサーバ3からのアクセス要求に応じてテープカートリッジに対するアクセスを行なう。テープライブラリ装置9a及び9bは、それぞれ、テープカートリッジに対するデータの記録及び再生等を行なう複数のドライブ91と、媒体カートリッジのピックアップ、搬送、ドライブ91への挿入等を行なうロボット92とをそなえる。

0044

制御システム4は、制御装置5a〜5d,7a〜7d,11a及び11b、FCスイッチ6a及び6b、RAID装置8、LANハブ10a及び10b、ライブラリ制御装置12a及び12b、並びに電源制御装置13a及び13bをそなえる。

0045

制御装置5a〜5dは、ホストサーバ3と物理層(PHY)を介して複数のホストI/F(Interface)バスで接続され、ホストサーバ3との間のアクセス制御を行なう。制御装置7a〜7dは、ドライブ91とFCで接続され、ドライブ91との間のアクセス制御を行なう。なお、制御装置5a〜5dはチャネルアダプタ(CA;Channel Adaptor)の一例であり、制御装置6a〜6dはデバイスアダプタ(DA;Device Adaptor)の一例である。

0046

FCスイッチ6a及び6bは、FCを介して接続された制御装置5a〜5dと制御装置7a〜7dとの間におけるデータ転送(切り替え)を行なう。RAID装置8は、FCスイッチ6a及び6bとFCを介して接続され、ホストサーバ3とテープライブラリ装置9a又は9bとの間のアクセスに係るデータ(リードライトデータ)を一時的に記憶する。RAID装置8は、仮想テープライブラリ装置1aにおけるキャッシュ役割を持つ。なお、RAID装置8は、HDD(Hard Disk Drive)等の磁気ディスク装置及びSSD(Solid State Drive)等の半導体ドライブ装置の少なくとも1つを含んでよい。或いは、RAID装置8は階層管理一次ストレージとして用いられてもよい。この場合、RAID装置8は仮想テープライブラリ装置1aとして動作して高速アクセスを可能にし、アンロード指示でRAID装置8のデータが二次ストレージとしてのテープライブラリ装置9a及び9bのテープに書き込まれる。

0047

LANハブ10a及び10bは、運用コンソール2a、制御装置5a〜5d、7a〜7d、11a及び11b、ライブラリ制御装置12a及び12b、並びに電源制御装置13a及び13bと内部制御バスを介して接続され、これらの装置間における制御信号転送を行なう。

0048

制御装置11a及び11bは、LANハブ10a及び10bを介して、制御システム4内の各装置の設定や情報の取得等の各種制御を行なう。なお、ホストサーバ3又は運用コンソール2aから制御装置11a及び11bまでの間は制御バスで接続され、制御装置11a及び11bは、ホストサーバ3又は運用コンソール2aとの間で通信を行なう。

0049

ライブラリ制御装置12a及び12bは、ロボット92の駆動制御等を行なう。電源制御装置13a及び13bは、図示しない電源装置に接続された各装置について、電源のON/OFF制御を行なう。

0050

上述した装置5a〜5d、6a及び6b,7a〜7d,8,9a及び9b,10a及び10b,11a及び11b,12a及び12b,並びに13a及び13bの各々は、ファームウェア(ソフトウェア)によってその機能の少なくとも一部が制御される。また、上記装置の各ファームウェアは、図4に例示する更新ファームセット30に含まれる複数の更新ファームウェアによって更新され得る。換言すれば、仮想テープライブラリ装置1aは、上記装置の各々のファームウェアを更新するファームアップ機能をそなえているといえる。

0051

このように、上記装置の各々は、図4に例示するモジュール100と同様のモジュール100aであるといえる。また、仮想テープライブラリ装置1aは、複数のモジュール100aを含む複合システム(対象装置1)の一例である。

0052

運用コンソール2aは、仮想テープライブラリ装置1aのインタフェース(LANハブ10a及び10b)を介して仮想テープライブラリ装置1aの管理(制御)を行なう管理サーバの一例である。例えば運用コンソール2aは、仮想テープライブラリ装置1aのファームアップの際に、仮想テープライブラリ装置1aの更新ファームセット30を読み込み、以下に詳述する総ファームアップ推定時間の算出や、ファームアップ処理等を行なうことができる。

0053

ホストサーバ3は、仮想テープライブラリ装置1aに対するアクセスを行なうサーバであり、例えば仮想テープライブラリ装置1aの利用者等により用いられる。

0054

運用コンソール2a及びホストサーバ3としては、それぞれ、例えばPCやサーバ等のコンピュータ(情報処理装置)が挙げられる。

0055

〔2−2〕運用コンソールの構成例
次に、図6を参照して、一実施形態に係る運用コンソール2aの構成例を説明する。運用コンソール2aは、仮想テープライブラリ装置1aとLAN等により接続される。また、運用コンソール2aは、更新ファームセット30を入力される。

0056

更新ファームセット30は、複数のファームウェアデータ31と、ファームアップ時間データベース32とを含む。複数のファームウェアデータ31は、対象装置1としての仮想テープライブラリ装置1aに含まれる複数のモジュール100aに適用する更新用のファームウェアである。なお、ファームアップ時間データベース32の説明は後述する。

0057

運用コンソール2aは、更新ファームセット30を入力(提供)されると、複数のファームウェアデータ31とファームアップ時間データベース32とを記憶装置、例えば保持部21に保持してよい。

0058

運用コンソール2aは、図6に例示するように、保持部21及びファームアップ時間推定部23をそなえる。なお、運用コンソール2aは、ファームウェア更新処理部29をそなえてもよい。

0059

保持部21は、データを記憶する記憶装置の一例であり、図6に例示するように、アップデートフローデータベース22を保持する。アップデートフローデータベース22には、運用コンソール2aが管理する全ての複合システムについて、複合システムごとに、構成部品と構成部品の更新順序(ファームウェアの更新処理の実行順序)とを定義した情報が含まれる。また、アップデートフローデータベース22には、更新ファームセット30に含まれる、構成部品のファームアップにかかる時間の情報が設定され得る。

0060

アップデートフローデータベース22は、システム又は仮想テープライブラリ装置1aの運用開始又は構成変更の発生等の所定のタイミングで、システム又は仮想テープライブラリ装置1aの管理者等により予め作成され、保持部21に設定される。

0061

〔2−2−1〕アップデートフローデータベースの説明
以下、アップデートフローデータベース22について説明する。なお、便宜上、以下の説明では、仮想テープライブラリ装置1aが部品1〜部品9の9個の構成部品(モジュール100a)を含み、図1に例示するアップデートフローによりファームアップが行なわれるものとする。

0062

図7は、アップデートフローデータベース22のフローテーブルの一例を示す図である。図7に例示するように、アップデートフローデータベース22は、図1に例示するアップデートフロー(手順書)を、総ファームアップ推定時間の自動算出を行なうためにデータベースとして定義したものであり、複数(図7の例では4つ)のフローテーブルを含む。

0063

フローテーブルは、各々が1つのルートを示し、各ルートは、処理要素としての“部品ファームアップ処理(UP_UNIT_xxx)”、“分岐ポイント(Branch_xx)”、“合流ポイント(Join_xx)”の少なくとも1つを含むリスト構造体集合である。

0064

フローテーブルのうちの1つは、アップデートフローのメインルート(図7の例ではRoute_001)を表し、メインルート以外のフローテーブルは、メインルートから分岐した分岐ルート(図7の例ではRoute_002〜Route_004)を表す。

0065

ルート(Route_xxx)は、リスト構造をしており、リスト順番に処理が行なわれる流れを示している。複数部品を並行して(同時に)ファームアップすることを定義するには、1つのルートではなく、並行して行なわれる部品の数のルートが用いられる。このため、複数部品を並行してファームアップするには、予め分岐ポイント(Branch_xx)により複数の分岐ルート(Route_xxx)を作成することになる。

0066

仮想テープライブラリ装置1aのファームアップが開始されると、図8に例示するように、メインルート(Route_001)が最初に処理され、部品ファームアップ処理、分岐ルートの生成、分岐ルートの合流等が行なわれる。分岐ルートにおいても、図9に例示するように、親ルート(メインルート又は分岐元の分岐ルート)の処理と並行して、部品ファームアップ処理、更なる分岐ルートの生成、別の分岐ルートからの合流等が行なわれる。分岐ルートは最終的にメインルートに合流するため、メインルートが終了した時点で、仮想テープライブラリ装置1aの全ての部品のファームアップ処理が完了する。

0067

部品ファームアップ処理(UP_UNIT_xxx)は、各部品のファームアップを行なう処理を示すポイント(処理要素)である。UP_UNIT_xxxに対応する部品は、図10に例示するように、アップデートフローデータベース22に含まれる要素管理テーブルで対応付けられる。一例として、図10に示すように、UP_UNIT_001には部品1のファームアップ処理が対応付けられる。

0068

図10に例示するように、部品ファームアップ処理(UP_UNIT_xxx)は、仮想テープライブラリ装置1aの全ての部品1〜9を一意に特定することができる情報である。仮想テープライブラリ装置1aの構成部品が新型モデルの追加等により追加又は変更があった場合、図11に例示するように、新たな構成部品を要素管理テーブルに追加することができる(部品10及び部品11参照)。

0069

分岐ポイント(Branch_xx)は、ルートが分岐するポイント(処理要素)、つまりファームアップの並行実施が可能となるポイントである。Branch_xxでは、1以上のルート(Route_xxx)が新たに生成され、ルートの数だけ並行して部品のファームアップが可能となる。なお、図7のRoute_001に示すように、Branch_xxに続けて付された括弧()内の1以上のRoute_xxxは、Branch_xxによって作成されるルートを示す。

0070

図12に例示するように、データベース定義されたアップデートフローでは、ファームアップの開始時に、メインルート(Route_001)のフローが作成される。Route_001のフローに分岐ポイント(Branch_xx)が定義されると、分岐ポイント(Branch_xx)が示す新規ルート(Route_xxx)が生成され、部品ファームアップ処理は分岐したルートの分だけ複数並行して実施可能となる。

0071

合流ポイント(Join_xx)は、ルートが合流するポイント(処理要素)、つまりファームアップの並行実施が終了するポイントである。Join_xxでは、2以上のルートが合流し、1つのルートとしての処理の流れに戻る。なお、図7に示すように、Join_xxに続けて付された括弧()内がBaseの場合(Route_001参照)、当該Join_xxを含むルートが合流される合流ポイントであることを示す。一方、Join_xxに続けて付された括弧()内がBaseではなくRoute_xxxの場合(Route_002〜Route_004参照)、当該Join_xxを含むルートが括弧()内のRoute_xxxで指定されたルートに合流し、当該Join_xxを含むルートが終了(消滅)することを示す。

0072

図13に例示するように、分岐したルートは合流ポイント(Join_xx)で合流し、再若番の分岐ルートを除き、その他の分岐ルートは終了する。図13の例では、Join_01でRoute_001とRoute_002とが合流する場合、Route_002の分岐ルートは終了し、Route_001の分岐ルート(メインルート)は継続する。なお、Route_001は常に合流されるルートであるため、Route_001は、アップデートフローの終了を以て終了する。

0073

このように、アップデートフローデータベース22(フローテーブル)は、メインとなるルート(Route_001)で始まり、部品が並行して処理可能な場合は分岐ポイント(Branch_xx)で新たな分岐ルート(Route_xxx)が作成される。各ルート上では、部品のファームアップ処理(UP_UNIT_xxx)が手順に沿って設定され、仮想テープライブラリ装置1aのファームアップの手順が示される。分岐ルートは、合流ポイント(Join_xx)で指定されたルートに合流して、最終的に1つのルート(メインルート)に集約される。

0074

なお、現在考えられる複合システムでは多種多様に亘る構成部品が存在するわけではないため、データベース定義されたフローテーブルに存在するルートの数(リスト構造体の数)、及び各ルートに登録される処理要素数の上限は特に定義しなくてもよい。

0075

以上のように、メインルートには、ファームアップを直列シーケンシャル)に実行する(並行して実行しない)構成部品同士の実行順序と、並行して実行できる構成部品の実行順序を定義する分岐ルートへの分岐ポイントと、分岐ルートからの合流ポイントと、が定義されるといえる。また、分岐ルートには、分岐ルートにおける構成部品のファームアップの実行順序と、どのルートのどの合流ポイントに合流するかを示す情報と、が定義されるといえる。

0076

上述したアップデートフローデータベース22(フローテーブル及び要素管理テーブル)は、図1に示すアップデートフローをデータベース定義したものであるため、アップデートフローデータベース22からアップデートフローを復元することも可能である。以下、アップデートフローに基づき定義されたアップデートフローデータベース22が可逆性を有することを説明するため、図14を参照して、運用コンソール2aによるアップデートフローデータベース22に基づくファームアップ手順(アップデートフロー)の作成手法の一例を説明する。

0077

まず、運用コンソール2aは、フローテーブルからメインルート(Route_001)のリスト構造体を取り出す。そして、運用コンソール2aは、リスト構造体の先頭から処理要素(UP_UNIT_xxx等)を取り出し、取り出した順にフローを作成する。図14の例では、運用コンソール2aは、図7のRoute_001の1、2番目等において、UP_UNIT_001,UP_UNIT_002等のフローを作成する。

0078

取り出した処理要素が分岐ポイントの場合(Branch_xx(Route_xxx,Route_xxx,…)、運用コンソール2aは、パラメータで指定されたルートの分岐を作成する。図14の例では、運用コンソール2aは、図7のRoute_001の3、7番目において、Branch_01,Branch_02等の分岐を作成する。以降、分岐ルートに対しても、メインルートと同様に処理する。

0079

取り出した処理要素が合流ポイントの場合(Join_xx(Base))、運用コンソール2aは、分岐したルートの待ち合わせポイントを作成する。図14の例では、運用コンソール2aは、図7のRoute_001の6、9番目において、Join_01,Join_02等の待ち合わせポイントを作成する。

0080

分岐ルートから取り出した処理要素が合流ポイントの場合(Join_xx(Route_xxx))、運用コンソール2aは、指定された合流ポイントの待ち合わせに合流し、当該分岐ルートを終了させる。なお、メインルートには、他のルートに合流する合流ポイントとなる処理要素(Join_xx(Route_xxx))は存在しない。図14の例では、分岐ルート(Route_002,Route_003)は、図7のRoute_002の3番目,Route_003の2番目において、それぞれRoute_001の6番目の待ち合わせポイント(Join_01(Base))に合流する。また、分岐ルート(Route_004)は、図7のRoute_004の2番目において、Route_001の9番目の待ち合わせポイント(Join_02(Base))に合流する。このとき、運用コンソール2aは、Route_002〜Route_004を終了させる。

0081

リスト構造体の全ての処理要素が取り出されたら、アップデートフローが完成する。なお、メインルート以外はいずれかのルートに合流して終了する。このように、図7に示すアップデートフローデータベース22からアップデートフローを復元した場合、図14に示すアップデートフローが確立されるのである。このアップデートフローは、図1に示すものと一致する。

0082

運用コンソール2aのファームアップ時間推定部23は、上述のようにしてデータベース定義されたアップデートフローデータベース22を使用し、総ファームアップ推定時間を自動で算出することができる。

0083

なお、図33及び図34に示すように、複合システムのモデル情報が異なると、複合システムの構成部品も異なるため、アップデートフローも異なる。更新ファームセット30の適用対象の複合システムに複数のモデルが存在し、それらに対応するアップデートフローが複数存在する場合、存在するアップデートフローの数だけアップデートフローデータベース22が定義され、複合システムの管理を行なう管理サーバ上に格納される。

0084

例えば、図15に示すように、情報処理装置2は、1台で複数の対象装置1−1〜1−n(nは自然数)の管理を行なうことも可能である。対象装置1−1〜1−nは、例えば互いにモデル/オプション等の装置構成が異なる。この場合、情報処理装置2の保持部21には、全対象装置1−1〜1−nの各々に対応するアップデートフローデータベース22−1〜22−nが格納される。なお、図15では、アップデートフローデータベース22をUFDB22と表記している。

0085

なお、アップデートフローデータベース22−1〜22−nは、それぞれ対応する対象装置1−1〜1−nのモデル/オプション等のモデルタイプ(装置構成)と対応付けられる。

0086

以上のように、保持部21は、互いに装置構成の異なる複数の仮想テープライブラリ装置1aについて、各仮想テープライブラリ装置1aが含む複数のモジュール100aに係る複数の更新処理の実行順序を示す情報(UFDB22)を、装置構成と対応付けて保持するといえる。

0087

〔2−2−2〕ファームアップ時間推定部の説明
次に、図6の説明に戻り、ファームアップ時間推定部23の詳細について説明する。ファームアップ時間推定部23は、ファームアップ対象の複合システムの総ファームアップ推定時間を算出する。

0088

ファームアップ時間推定部23は、例示的に、DB選択部24、ブロック分割部25、推定時間選択部26、第1算出部27、及び第2算出部28をそなえる。

0089

DB選択部24は、ファームアップ対象の仮想テープライブラリ装置1aのモデル用に用意されたアップデートフローデータベース22を保持部21から選択するアップデートフローデータベース選択処理を行なう。

0090

ブロック分割部25は、DB選択部24により選択されたアップデートフローデータベース22を、ブロック分割機能により、1つ又は複数の処理ブロックに分割するブロック分割処理を行なう。ここで、処理ブロックとは、複数の(一連の)部品ファームアップ処理を1つの部品ファームアップ処理と見做したブロックである。後述するように、処理ブロックには単一ルートブロック複数ルートブロックとが含まれる。単一ルートブロックは、直列に(シーケンシャルに)更新処理を行なう単一ルートの部品ファームアップ処理を含む処理ブロックであり、複数ルートブロックは、並列に(並行して;パラレルに)更新処理を行なう複数ルートの部品ファームアップ処理を含む処理ブロックである。

0091

推定時間選択部26は、構成部品ごとのファームアップ推定時間を選択する機能を用いて、アップデートフローデータベース22の部品ファームアップ処理(UP_UNIT_xxx)の各々に適切な部品のファームアップ推定時間を当て嵌めるファームアップ時間選択処理を行なう。

0092

第1算出部27は、推定時間選択部26により当て嵌められた各部品のファームアップ処理時間から、処理ブロックごとのファームアップ推定時間を算出する機能を用いて、処理ブロックごとのファームアップにかかる処理時間を求めるブロック推定時間算出処理を行なう。

0093

第2算出部28は、第1算出部27により求められた各処理ブロックの推定時間を加算し、当該アップデートフローを使用するモデルの総ファームアップ推定時間を求める。

0094

ファームウェア更新処理部29は、対象装置1としての仮想テープライブラリ装置1aのファームアップを行なう場合、各フローテーブルで定義されたルート(Route_xxx)上で処理要素を指定された順に処理することで、ファームアップを行なう。ファームウェア更新処理部29によれば、事前に定義されたアップデートフローデータベース22に基づき自動でファームアップが行なえるため、作業者等による手動でのファームアップよりも正確且つ安全にファームアップを行なうことができる。なお、ファームウェア更新処理部29の機能は運用コンソール2aから省略してもよい。

0095

以下、ファームアップ時間推定部23がそなえる各構成の詳細について説明する。

0096

(DB選択部24の説明)
上述したように、アップデートフローデータベース22は構成が異なるそれぞれのモデルタイプごとに存在し得る(図15図33図34参照)。

0097

仮想テープライブラリ装置1aには、運用コンソール2aからコマンドを発行することによって、モデル情報を取り出す機能が用意されていることが多い。従って、このコマンドを用いることで、対象装置1としての仮想テープライブラリ装置1aがどのようなモデルタイプであるのかを判別することができる。なお、モデル情報としては、モデル/オプション、例えばモデル名やモデルID等のモデルタイプを識別可能な情報が挙げられる。

0098

DB選択部24は、このモデル情報取得機能を使用して、仮想テープライブラリ装置1aのモデルタイプを取得し、取得したモデルタイプに対応するアップデートフローデータベース22を保持部21から選択する。

0099

なお、仮想テープライブラリ装置1aにモデルタイプを通知するコマンドが存在しない場合や、運用コンソール2aがコマンドを発行したときに仮想テープライブラリ装置1aがコマンドを受け付けない状態である場合等には、以下の手法を採ることもできる。例えば、予め対象装置1としての仮想テープライブラリ装置1aの情報を定義する構成定義ファイルを作成し、この構成定義ファイルに仮想テープライブラリ装置1aのモデル名を登録しておく。これにより、DB選択部24は、モデル情報取得機能に代えて、仮想テープライブラリ装置1aのモデル情報を判別し、対応するアップデートフローデータベース22を選択することも可能である。

0100

以上のように、DB選択部24は、一の仮想テープライブラリ装置1aから当該一の仮想テープライブラリ装置1aの装置構成を示す情報を取得し、取得した装置構成に対応する実行順序を示す情報(UFDB)22を保持部21から取得する取得部の一例であるといえる。

0101

(ブロック分割部25の説明)
ブロック分割部25は、アップデートフローデータベース22を、以下の手順に従って1以上の処理ブロックに分割する。

0102

一例として、ブロック分割部25は、DB選択部24が選択したアップデートフローデータベース22のメインルートのリスト構造体について、更新順序に従って分岐ポイント(Branch_xx)に到達するまで順に読み込む。このとき、ブロック分割部25は、分岐ポイントに到達するまでの一連の部品ファームアップ処理(UP_UNIT_xxx)については、直列に(シーケンシャルに)更新処理を行なう単一ルートの処理ブロック(単一ルートブロック,第2処理ブロック)と判断する。図1図14)の例では、図16に示すように、部品1+部品2(UP_UNIT_001+UP_UNIT_002)が1つの単一ルートブロックと判断される。

0103

分岐ポイントに到達すると、ブロック分割部25は、当該分岐ポイントで分岐した全てのルートが再度合流して一つのルートに戻る合流ポイントまでを、並列に(並行して)更新処理を行なう複数ルートの処理ブロック(複数ルートブロック,第1処理ブロック)と判断する。図1図14)の例では、図16に示すように、ポイント1〜ポイント2(Branch_01〜Join_01)の、部品3+部品6、部品4+部品7、並びに部品5(UP_UNIT_003+UP_UNIT_006,UP_UNIT_004+UP_UNIT_007,UP_UNIT_005)が1つの複数ルートブロックと判断される。また、図1図14)の他の例では、図16に示すように、ポイント3〜ポイント4(Branch_02〜Join_02)の、部品8+部品9(UP_UNIT_008+UP_UNIT_009)が1つの複数ルートブロックと判断される。

0104

なお、複数ルートブロック内で分岐したブロックルートが、他のルートの合流前に再分岐した場合、ブロック分割部25は、再分岐した全てのブロックルートが合流するまでを1つの処理ブロックと判断する。

0105

例えば、図17に示すように、Branch_0aにおいて部品A+部品C、部品Bの2つのルートに分岐した後、部品Bが部品A+部品Cに合流する前に、Branch_0bで部品D、部品E+部品Gに分岐することがある。なお、部品DはJoin_0aで部品A+部品Cと合流し、部品E+部品GはJoin_0bで部品Dに続く部品Fと合流する。このような場合、ブロック分割部25は、最初の分岐ポイント(Branch_0a)から全ての分岐ルートが合流する合流ポイント(Join_0b)までを1つの複数ルートブロックと判断する。

0106

また、ブロック分割部25は、複数ルートブロックと判断した処理ブロックについて、当該処理ブロックの先頭から末尾の間の全てのルートをブロックルートとして定義(特定)する。図1図14)の例では、図18に示すように、ポイント1からポイント2まで(Branch_01〜Join_01)の処理ブロックは、部品3+部品6のルート(Route_001)、部品4+部品7のルート(Route_002)、及び部品5のルート(Route_003)の3ルートが、ブロックルートとして定義される。また、図1図14)の他の例では、図18に示すように、ポイント3からポイント4まで(Branch_02〜Join_02)の処理ブロックは、部品8のルート(Route_001)及び部品9のルート(Route_004)の2ルートが、ブロックルートとして定義される。

0107

また、処理ブロック内で、再分岐が行なわれて分岐ポイントが複数存在したり、合流ポイントが複数存在する場合、特定のファームアップ処理(UP_UNIT_xxx)が、2以上のブロックルートに含まれてもよい。

0108

図17の例では、図19に示すように、部品A+部品C+部品Fのルート(Route_00aの少なくとも一部)、部品B+部品D+部品Fのルート(Route_00bの少なくとも一部)、部品B+部品E+部品Gのルート(Route_00cの少なくとも一部)の3ルートが、ブロックルートとして定義される。

0109

ブロック分割部25は、上述のようにしてブロック分割を行なうと、アップデートフローデータベース22のフローテーブルに対して、各処理要素がいずれの処理ブロックに属するかを特定する情報を設定してよい。ブロック分割部25により加工されたアップデートフローデータベース22は、以降の推定時間選択部26及び第1算出部27の処理においても利用される。なお、ブロック分割部25は、アップデートフローデータベース22(フローテーブル)のコピーを作成し、当該コピーにアップデートフローを分割して得られた処理ブロックの情報を設定することが好ましい。

0110

なお、ブロック分割部25は、アップデートフローデータベース22に含まれる複数のモジュール100a(の更新処理)から、シーケンシャルに実行される一以上の更新処理、つまり単一ルートブロック(第2処理ブロック)の定義(特定)を行なわなくてもよい。単一ルートブロックは、当該処理ブロック内の複数のモジュール100aの更新処理が直列に行なわれるため、これらのモジュール100aの各々を個々の処理ブロックと見做しても、総ファームアップ推定時間の算出結果に与える影響が少ないためである。

0111

換言すれば、ブロック分割部25は、アップデートフローデータベース22に含まれる複数のモジュール100a(の更新処理)から、少なくとも複数ルートブロック(第1処理ブロック)を特定すればよい。なお、ブロック分割部25は、複数ルートブロックとともに単一ルートブロックの特定についても行なうことにより、第1算出部27及び第2算出部28の処理負荷を低減させることができる。

0112

以上のように、ブロック分割部25は、実行順序を示す情報(UFDB)22に基づき、複数の更新処理(処理要素)から、並行して実行される複数の更新処理を1つの処理ブロックとした1以上の第1処理ブロックを特定する特定部の一例であるといえる。

0113

(推定時間選択部26の説明)
仮想テープライブラリ装置1aに含まれる個々の部品(モジュール100a)のファームアップにかかる更新時間(ファームアップ時間)は、アップデートされるファームウェアの機能やプログラムの性能等によって異なる場合がある。個々の部品のファームアップ時間が異なると、総ファームアップ推定時間にも誤差が生じ得る。

0114

また、個々の部品のファームアップ方式は、部品によって多様であり、例えばファームウェア全体を置き換える(上書きする)方式のほか、旧版からの差分のみを更新する差分ファームアップ方式が用いられる場合もある。差分ファームアップ方式の場合、現在運用中の部品のファーム版数によって、ファームアップにかかる更新時間が変化し得る。

0115

さらに、仮想テープライブラリ装置1aの全ての部品(モジュール100a)のファームウェアがアップデートされるとは限らない。

0116

ところで、複合システムのファームウェア管理では、過去にリリースされた複合システムのファーム版数と、今回リリースされるファーム版数とについて、それぞれの部品のファーム版数が管理されていることが多い。すなわち、過去にリリースされた(適用された)複合システムのファーム版数から、今回のファーム版数にファームアップする場合、複合システムの各々の部品のファーム版数が何版から何版にファームアップされるのかが、ファーム管理情報として管理されている。

0117

そこで、一実施形態に係るシステムでは、このファーム管理情報を拡張し、総ファームアップ推定時間をより正確に求めるために、更新ファームセット30に構成部品(モジュール100a)ごとのファームアップ時間データベース32を追加する(図6参照)。

0118

ファームアップ時間データベース32は、図20に例示するように、部品(モジュール100a)ごとに、現在の運用版数から更新ファームセット30に含まれるファームウェアデータ31の版数にファームアップする場合の更新時間が設定される。一例として、図20に示すように、部品1(UP_UNIT_001)のファームアップにかかる更新時間は、運用版数が○○版の場合XX分、運用版数が□□版の場合YY分、運用版数が△△版の場合ZZ分となる。

0119

ファームアップ時間データベース32は、対象装置1としての仮想テープライブラリ装置1aのファームリリース(更新ファームセット30の提供)の際に、更新ファームセット30に含まれる。

0120

推定時間選択部26は、所定のコマンドを用いて、対象装置1としての仮想テープライブラリ装置1aから現行の運用版数を取得する。そして、推定時間選択部26は、保持部21からファームアップ時間データベース32を読み出し、仮想テープライブラリ装置1aの運用版数に対応する各部品の更新時間を、ブロック分割部25が加工したアップデートフローデータベース22に適用(設定)する。これにより、第1算出部27及び第2算出部28では、提供された更新ファームセット30を仮想テープライブラリ装置1aのモデルに適用する場合の総ファームアップ推定時間を、より正確に求めることができる。

0121

(第1算出部27の説明)
第1算出部27は、ブロック分割部25が分割した処理ブロックごとのファームアップにかかる更新時間を算出する。

0122

例えば、第1算出部27は、アップデートフローデータベース22を参照し、ブロック分割部25が設定した処理ブロックごとに、当該処理ブロック内の各モジュール100aの更新時間を用いて当該処理ブロックの全体の更新時間を算出する。

0123

一例として、単一ルートブロックは、当該処理ブロック内のモジュール100aが直列的に(1つずつ順に)更新される。従って、第1算出部27は、単一ルートブロックについては、当該処理ブロック内の各モジュール100aの更新時間の合計を算出すればよい。

0124

一方、複数ルートブロックは、当該処理ブロック内のモジュール100aが並列的に(並行して)更新される。従って、複数ルートブロックの更新時間については、当該処理ブロックに定義されたブロックルートごとの更新時間が最も大きな値を持つブロックルート(最もファームアップの合計時間が大きいブロックルート)が、当該処理ブロックの更新時間となる。そこで、第1算出部27は、複数ルートブロックのブロックルートごとに、当該ブロックルートに含まれる各モジュール100aの更新時間の合計を算出し、最も大きい合計時間を複数ルートブロックの更新時間とすればよい。

0125

第1算出部27は、上述のようにして算出した処理ブロックごとの更新時間を、アップデートフローデータベース22に設定する。例えば、ブロック分割部25がアップデートフローデータベース22のフローテーブルに処理ブロックの情報を設定しているため、この情報に対して処理ブロックごとの更新時間を追記してもよい。

0126

以上のように、推定時間選択部26及び第1算出部27は、複数の更新処理(処理要素)の各々にかかる更新時間を示す情報(ファームアップ時間DB)32を用いて、ブロック分割部25が特定した複数ルートブロックごとの更新時間を推定する第1推定部の一例であるといえる。

0127

また、推定時間選択部26及び第1算出部27は、ブロック分割部25が特定した複数ルートブロックにおいて並行して更新処理が実行されるルートごとの更新時間を推定し、ルートごとに推定した更新時間のうちの最長の更新時間を当該複数ルートブロックの更新時間として推定する。これにより、更新処理が分岐する場合でも、当該複数ルートブロックについて、正確にファームアップ推定時間を算出することができる。

0128

(第2算出部28の説明)
第2算出部28は、第1算出部27が算出した処理ブロックごとの更新時間に基づき、対象装置1としての仮想テープライブラリ装置1aの総ファームアップ推定時間を算出する。

0129

上述のように、第1算出部27によって、各処理ブロック(単一ルートブロック及び複数ルートブロック)の更新時間が算出されている。従って、第2算出部28は、これらの更新時間を合計することで、仮想テープライブラリ装置1a全体のファームアップ時間を算出することができる。

0130

このように、第2算出部28は、更新時間を示す情報(ファームアップ時間DB)32及び推定時間選択部26及び第1算出部27が推定した第1処理ブロックごとの更新時間の少なくとも一方に基づいて、仮想テープライブラリ装置1aの更新時間を推定する第2推定部の一例であるといえる。例えば、第2算出部28は、推定時間選択部26及び第1算出部27が推定した複数ルートブロックごとの更新時間及び単一ルートブロックごとの更新時間を合計する。これにより、仮想テープライブラリ装置1aの更新時間を正確に推定することができる。

0131

運用コンソール2aは、上述のようにして推定した総ファームアップ推定時間を、作業者へ出力する。出力の手法としては、例えばモニタ等の出力装置への表示、ファイルへの格納、電子メールの送信等、既知の種々の手法を用いることができる。

0132

以上のように、一実施形態に係るシステム(情報処理装置2)によれば、データベース定義したアップデートフローを使用することで、対象装置1の総ファームアップ推定時間の算出を自動化することができる。これにより、ファームアップの作業者の負荷を減らし、正確且つ安全に、対象装置1(複合システム)のファームアップにかかる時間(総ファームアップ推定時間)を導出することができる。

0133

上述したように、総ファームアップ推定時間は、ファームアップの作業者がアップデートフローを参照して机上シミュレートを行なって求めることが考えられる。

0134

これに対し、一実施形態に係るシステムでは、情報処理装置2が、ファームアップを行なうルートが設定されたアップデートフローのデータベース22を、モデル(構成)ごとに管理する。情報処理装置2は、このデータベース22を用いて、対象装置1のファームアップにおいて並列処理が可能なモジュール100aを処理ブロックとして分割することができる。従って、情報処理装置2は、複雑なアップデートフローを持つ対象装置1であっても、ファームアップの並列処理を考慮することで、総ファームアップ推定時間の算出を容易に行なうことができる。

0135

また、情報処理装置2としての機能は、図5に示すように、例えば対象装置1としての仮想テープライブラリ装置1aを管理する管理サーバに集約することができる。管理対象となる仮想テープライブラリ装置1a(複合システム)では、管理サーバとのインタフェースを介して管理サーバにより制御され、総ファームアップ推定時間の算出が行なわれる。従って、ファームアップ時間推定部23の処理に伴う管理サーバからの指示、複合システムでの処理、複合システムから管理サーバへの応答等は、既存のインタフェースを用いて実行されてよい。これにより、情報処理装置2に所定のプログラム(更新時間推定プログラム)を設定するだけで、上述した機能を実現することができ、コストの増加を抑制することができる。

0136

〔2−3〕動作例
次に、上述の如く構成されたシステムの情報処理装置2(運用コンソール2a)の動作例を、図21図25を参照して説明する。

0137

はじめに、図21を参照して、ファームアップ時間推定部23による全体の処理(更新時間推定処理)について説明する。

0138

まず、DB選択部24は、ファームアップの対象モデル(仮想テープライブラリ装置1a)のアップデートフローデータベース22を選択する(ステップS1)。

0139

次いで、ブロック分割部25は、アップデートフローデータベース22を1以上の処理ブロックに分割する(ステップS2)。

0140

次に、推定時間選択部26は、アップデートフローデータベース22における各部品のファームアップ時間をファームアップ時間データベース32から選択し、アップデートフローデータベース22に設定する(ステップS3)。

0141

そして、第1算出部27は、ファームアップ推定時間を処理ブロック単位で求める(ステップS4)。

0142

最後に、第2算出部28は、メインルートの処理ブロック(第1算出部27が決定した処理ブロック)の推定時間を加算(合計)して、総ファームアップ推定時間を求め(ステップS5)、処理が終了する。

0143

次に、図22を参照して、DB選択部24によるDB選択処理(図21のステップS1)について説明する。

0144

DB選択部24は、ファームアップの対象装置1である仮想テープライブラリ装置1aに装置モデル情報取得コマンドを発行して、モデル情報を取得する(ステップS11)。

0145

取得コマンドによりモデル情報が取得できた場合(ステップS12,S12のYesルート)、DB選択部24は、対応するアップデートフローデータベース22が保持部21に保持されているか否かを判断する(ステップS13)。保持されている場合(ステップS13のYesルート)、DB選択部24は、適合するアップデートフローデータベース22を選択し(ステップS14)、処理が終了する。

0146

一方、ステップS13において対応するアップデートフローデータベース22が保持部21に保持されていない場合(ステップS13のNoルート)、データベース選択不可として、処理がエラー終了する。

0147

また、ステップS12において、取得コマンドによりモデル情報を取得していない場合(ステップS12のNoルート)、DB選択部24は、構成定義ファイルからモデル情報を取得できるか否かを判断する(ステップS15)。構成定義ファイルからモデル情報を取得できる場合(ステップS15のYesルート)、処理がステップS13に移行する。

0148

一方、ステップS15において構成定義ファイルからモデル情報が取得されない場合(ステップS15のNoルート)、構成定義ファイルがない、又は、構成定義ファイルに対象装置1のモデル情報が登録されていないため、データベース選択不可として、処理がエラー終了する。

0149

DB選択部24は、以上の処理によって選択したアップデートフローデータベース22を対象装置1のアップデートフローデータベース22として決定する。

0150

次に、図23を参照して、ブロック分割部25によるブロック分割処理(図21のステップS2)について説明する。なお、前提として、ブロック分割部25は、DB選択部24が選択したアップデートフローデータベース22のフローテーブルからメインルートのリスト構造体を順に読み出しているものとする。

0151

まず、ブロック分割部25は、フローテーブルにおいて、現在のルートの位置が分岐ポイント(Branch_xx)であるか否かを判断する(ステップS21)。現在のルートの位置が分岐ポイント(Branch_xx)である場合(ステップS21のYesルート)、ブロック分割部25は、分岐した全てのルートが再度合流して1つのルートに戻る合流ポイントまでを1つの処理ブロックとして定義する(ステップS22)。なお、この処理ブロックは複数ルートブロックとなる。

0152

なお、分岐したブロックルートが他のルートの合流前に再分岐した場合、ブロック分割部25は、その再分岐した全てのブロックルートが合流するまでを1つの処理ブロックとする。

0153

次いで、ブロック分割部25は、複数ルートブロックとして定義した処理ブロックで、処理ブロックの先頭から終了までの全てのルートをブロックルートとして定義し(ステップS23)、処理がステップS25に移行する。

0154

一方、ステップS21において、現在のルートの位置が分岐ポイント(Branch_xx)ではない場合(ステップS21のNoルート)、ブロック分割部25は、次に存在する分岐ポイント又は終了ポイントまでを1つの処理ブロックとして定義し(ステップS24)、処理がステップS25に移行する。なお、この処理ブロックは単一ルートブロックとなる。

0155

ステップS25では、ブロック分割部25は、分割処理が終了ポイント(メインルートのリスト構造体の最終行)まで進んだか否かを判断し、分割処理が終了ポイントまで処理された場合(ステップS25のYesルート)、処理が終了する。

0156

一方、分割処理が終了ポイントまで処理されていない場合(ステップS25のNoルート)、処理がステップS21に移行する。

0157

次に、図24を参照して、推定時間選択部26によるファームアップ時間選択処理(図21のステップS3)について説明する。

0158

推定時間選択部26は、ファームアップの対象装置1としての仮想テープライブラリ装置1aから、現在運用中の版数情報を、所定のコマンドの発行を通じて取得する(ステップS31)。なお、版数情報の取得は、DB選択部24による仮想テープライブラリ装置1aのモデル情報の取得と同様のタイミングで行なわれてもよい。

0159

次いで、推定時間選択部26は、更新ファームセット30に追加された、ファームアップ時間データベース32を取り込む(ステップS32)。なお、推定時間選択部26は、運用コンソール2aが事前に更新ファームセット30の情報を保持部21に保持している場合には、保持部21からファームアップ時間データベース32を取得してもよい。

0160

また、推定時間選択部26は、ファームアップ時間データベース32から、ステップS31で取得した仮想テープライブラリ装置1aの運用版数に対応する各部品のファームアップ時間を抽出する(ステップS33)。

0161

そして、推定時間選択部26は、アップデートフローデータベース22に対して、ステップS33で抽出した各部品のファームアップ時間を当て嵌めて(ステップS34)、処理が終了する。

0162

次に、図25を参照して、第1算出部27によるブロック推定時間算出処理(図21のステップS4)について説明する。なお、図25の処理は、ブロック分割部25が特定した処理ブロックの数分繰り返し実行される。

0163

まず、第1算出部27は、推定時間を求める処理ブロックが単一ルートブロック(処理ブロック内にブロックルートが1本のみ存在する)か否かを判断する(ステップS41)。処理ブロックが単一ルートブロックである場合(ステップS41のYesルート)、第1算出部27は、当該処理ブロックに含まれる部品のファームアップ時間を全て加算し、その加算値を処理ブロックの推定時間として(ステップS42)、当該処理ブロックのブロック推定時間の算出を終了する。

0164

一方、処理ブロックが単一ルートブロックではない場合(ステップS41のNoルート)、第1算出部27は、当該処理ブロックは複数ルートブロックであると判断し、当該処理ブロックに含まれる全てのブロックルートについての推定時間を、ステップS42と同様の手法で求める。そして、第1算出部27は、推定時間を求めた全てのブロックルートのうち、最も加算値の大きなブロックルートの推定時間を当該処理ブロックの推定時間として(ステップS43)、当該処理ブロックのブロック推定時間の算出を終了する。

0165

〔2−4〕実施例
次に、上述の如く構成された一実施形態に係るシステムの実施例について説明する。なお、前提として、対象装置1の一例としての仮想テープライブラリ装置1aは、部品1〜部品9の9個の部品を含み、図26に例示するアップデートフローを持つものとする。また、ファームアップ時間データベース32は、図27に例示するものであるとする。

0166

〔2−4−1〕第1実施例
はじめに、図28及び図29を参照して、仮想テープライブラリ装置1aを01版から更新ファームセット30の最新版へファームアップする場合について説明する。

0167

図26に示すアップデートフローの場合、図27に示すファームアップ時間データベース32に従って、現行運用版数が01版からリリースされた版数にファームアップされる場合のアップデートフローデータベース22(フローテーブル)は、図28に示すものとなる。

0168

すなわち、図28に例示するように、ブロック分割部25により、図7に示す基本のアップデートフローデータベース22のフローテーブル(又はコピー)に、アップデートフローを分割して得られた処理ブロック(図28中、“処理ブロック”と表記)情報が設定される。また、推定時間選択部26により、当該フローテーブルに、選択した各部品のファームアップ時間(図28中、“推定時間”と表記)情報が設定される。さらに、第1算出部27により、当該フローテーブルの処理ブロック情報に、処理ブロックごとの推定時間(図28中、“処理ブロック[推定時間]”と表記)が設定される。

0169

図28に示すように、ブロック分割部25は、仮想テープライブラリ装置1aのアップデートフローを処理ブロックA、処理ブロックB、処理ブロックCの3つの処理ブロックに分割する。

0170

図29に例示するように、処理ブロックAは、単一ルートブロックであるため、第1算出部27は、部品1及び部品2のファームアップ時間を加算したトータル時間として20分+10分=30分を得る。

0171

処理ブロックBは、複数ルートブロックである。部品3及び部品6のファームアップが実施されるブロックルートは80分+40分=120分、部品4及び部品7のファームアップが実施されるブロックルートは60分+50分=110分、部品5のファームアップが実施されるブロックルートは100分である。第1算出部27は、これらの時間を算出し、最大値である部品3及び部品6のファームアップが実施されるブロックルートの120分を、処理ブロックBの推定時間と決定する。

0172

同様に、処理ブロックCは、複数ルートブロックであり、第1算出部27は、部品9のブロックルートにかかる60分を、処理ブロックCの推定時間と決定する。

0173

このようにして、推定時間選択部26及び第1算出部27は、処理ブロックAについてRoute_001の30分、処理ブロックBについてRoute_001の120分、処理ブロックCについてRoute_004の60分を、それぞれ各処理ブロックの(最長の)推定時間として算出(決定)する。

0174

第2算出部28は、全ての処理ブロックの推定時間を加算し、30分+120分+60分=210分を得る。

0175

以上のように、第1実施例では、運用版数の01版からリリースされた版数へのファームアップにかかる総ファームアップ推定時間が210分と導出される。

0176

〔2−4−2〕第2実施例
次に、図30及び図31を参照して、仮想テープライブラリ装置1aを03版から更新ファームセット30の最新版へファームアップする場合について説明する。

0177

第1実施例と同様に、図26に示すアップデートフローの場合、図27に示すファームアップ時間データベース32に従って、現行運用版数が03版からリリースされた版数にファームアップされる場合のアップデートフローデータベース22(フローテーブル)は、図30に示すものとなる。

0178

図27に示すように、現行運用版数が03版の場合、部品4及び部品9ではファームアップ時間が0分、つまりファームアップが不要となる。また、部品1〜部品3、部品5、部品6、部品8についても、現行運用版数が01版のときよりもファームアップ時間が短縮される。

0179

この場合、図31に例示するように、処理ブロックAについて、第1算出部27は、部品1及び部品2のファームアップ時間を加算したトータル時間として13分+9.5分=22.5分を得る。

0180

処理ブロックBは、部品3及び部品6のファームアップが実施されるブロックルートが45分+25分=70分、部品4及び部品7のファームアップが実施されるブロックルートが0分+51分=51分、部品5のファームアップが実施されるブロックルートが90分である。第1算出部27は、これらの時間を算出し、最大値である部品5のファームアップが実施されるブロックルートの90分を、処理ブロックBの推定時間と決定する。

0181

同様に、処理ブロックCについて、第1算出部27は、部品8のブロックルートにかかる32分を、処理ブロックCの推定時間と決定する。

0182

このようにして、推定時間選択部26及び第1算出部27は、処理ブロックAについてRoute_001の22.5分、処理ブロックBについてRoute_003の90分、処理ブロックCについてRoute_001の32分を、それぞれ各処理ブロックの(最長の)推定時間として算出(決定)する。

0183

第2算出部28は、全ての処理ブロックの推定時間を加算し、22.5分+90分+32分=144.5分を得る。

0184

以上のように、第1実施例では、運用版数の03版からリリースされた版数へのファームアップにかかる総ファームアップ推定時間が144.5分と導出される。

0185

以上のように、一実施形態に係る運用コンソール2aでは、仮想テープライブラリ装置1aの装置ファームアップにおいて、データベース化されたアップデートフローを使用して、更新ファームセット30に追加されたファームアップ時間データベース32を取り込む。これにより、運用コンソール2aは、仮想テープライブラリ装置1aに更新ファームセット30を適用する正確な総ファームアップ推定時間を自動で求めることができるため、作業者は、対象装置1のファームアップスケジュールを無駄のない時間帯で立案することができ、ファームアップに伴う対象装置1の可用性の低下を抑制することもできる。

0186

また、人手で実施するファームアップ実施前の机上シミュレーションを不要とすることができるため、より短期間で対象装置1のファームアップスケジュールを立案することができる。

0187

〔3〕ハードウェア構成例
図32に示すように、上述した一実施形態に係る運用コンソール2a(情報処理装置2)は、CPU20a、メモリ20b、記憶部20c、インタフェース部20d、入出力部20e、及び読取部20fをそなえることができる。

0188

CPU20aは、種々の制御や演算を行なう演算処理装置プロセッサ)の一例である。CPU20aは、対応する各ブロック20b〜20fと接続され、メモリ20b、記憶部20c、記録媒体20g、又は図示しないROM(Read Only Memory)等に格納されたプログラムを実行することにより、種々の機能を実現することができる。

0189

メモリ20bは、種々のデータやプログラムを格納する記憶装置である。CPU20aは、プログラムを実行する際に、メモリ20bにデータやプログラムを格納し展開する。なお、メモリ20bとしては、例えばRAM(Random Access Memory)等の揮発性メモリが挙げられる。

0190

記憶部20cは、種々のデータやプログラム等を格納するハードウェアである。記憶部20cとしては、例えばHDD等の磁気ディスク装置、SSD等の半導体ドライブ装置、フラッシュメモリやROM等の不揮発性メモリ等の各種装置が挙げられる。なお、図6に示す保持部21は、メモリ20b又は記憶部20cにより実現されてよい。

0191

例えば、記憶部20cは、運用コンソール2aの各種機能の全部もしくは一部を実現する更新時間推定プログラム200及び1以上のアップデートフローデータベース22を格納することができる。また、記憶部20cは、提供された更新ファームセット30に含まれる複数のファームウェアデータ31及びファームアップ時間データベース32を格納することができる。

0192

インタフェース部20dは、有線又は無線による、対象装置1としての仮想テープライブラリ装置1a及びネットワークや他の情報処理装置等との間の接続及び通信の制御等を行なう通信インタフェースである。インタフェース部20dとしては、例えば、LAN、FC、インフィニバンド(InfiniBand)等に準拠したアダプタが挙げられる。例えば、CPU20aは、インタフェース部20dを介してネットワークから取得した端末プログラム200を記憶部20cに格納してもよい。

0193

入出力部20eは、マウスキーボードタッチパネル音声操作のためのマイク等の入力装置(操作部)、並びにディスプレイスピーカー、及びプリンタ等の出力装置(出力部、表示部)の少なくとも一方を含むことができる。例えば、入力装置はファームアップの作業者や仮想テープライブラリ装置1aの管理者等による運用コンソール2aの各種操作やデータの入力等の作業に用いられてよく、出力装置は総ファームアップ推定時間の算出結果や各種通知等の出力に用いられてよい。

0194

読取部20fは、コンピュータ読取可能な記録媒体20gに記録されたデータやプログラムを読み出す装置である。この記録媒体20gには端末プログラム200が格納されてもよい。

0195

例えば、CPU20aは、記憶部20cに格納された端末プログラム200を、メモリ20b等の記憶装置に展開して実行することにより、運用コンソール2aのファームアップ時間推定部23(及びファームウェア更新処理部29)の機能を実現することができる。

0196

なお、記録媒体20gとしては、例えばフレキシブルディスク、CD(Compact Disc)、DVD(Digital Versatile Disc)、ブルーレイディスク等の光ディスクや、USB(Universal Serial Bus)メモリやSDカード等のフラッシュメモリが挙げられる。なお、CDとしては、CD−ROM、CD−R(CD-Recordable)、CD−RW(CD-Rewritable)等が挙げられる。また、DVDとしては、DVD−ROM、DVD−RAM、DVD−R、DVD−RW、DVD+R、DVD+RW等が挙げられる。

0197

上述した各ブロック20a〜20f間はそれぞれバスで相互に通信可能に接続される。また、運用コンソール2aの上述したハードウェア構成は例示である。従って、運用コンソール2a内でのハードウェアの増減(例えば任意のブロックの追加や省略)、分割、任意の組み合わせでの統合、バスの追加又は省略等は適宜行なわれてもよい。

0198

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

0199

例えば、図6に示す運用コンソール2aの各機能ブロックは、任意の組み合わせで併合してもよく、分割してもよい。

0200

また、上述した説明では、ファームアップ時間データベース32における現行の運用版数が、仮想テープライブラリ装置1a全体のファームウェアの版数であるものとして説明したが、これに限定されるものではない。例えば、現行の運用版数は、部品(モジュール100a)ごとのファームウェアの運用版数であってもよい。この場合、ファームアップ時間データベース32で参照される現行の運用版数の列は、部品ごとに異なる列となり得る。

0201

さらに、仮想テープライブラリ装置1aのアップデートフローは、基本的にはモデルタイプ(装置構成)等に従って決定されるため、ブロック分割処理で定義された処理ブロックの情報やブロックルート情報を含むアップデートフローデータベース22は頻繁に更新しなくてもよい。

0202

すなわち、アップデートフローのデータベース22と、このアップデートフローからブロック分割部25により作成される処理ブロック情報が含まれたアップデートフローデータベース22は、運用コンソール2aに常時保持され得る。運用コンソール2aに接続されている仮想テープライブラリ装置1aは構成が基本的に固定であるためである。

0203

なお、仮想テープライブラリ装置1aのファームアップに伴い、ファームアップの手順自体が変更される場合がある。この場合、アップデートフローの変更となるため、運用コンソール2aは、別途、更新ファームセット30とともに、アップデートされたアップデートフローがベンダ等の開発元から提供され、運用コンソール2a内のデータベース22が更新される。この場合、運用コンソール2aでは、再度、DB選択部24によるDB選択処理やブロック分割部25によるブロック分割処理が実行され、処理ブロック情報やブロックルート情報が再生成される。

0204

一方、ファームアップ時間データベース32については、仮想テープライブラリ装置1aのファームリリースごとに最新のデータベース32が更新ファームセット30に含められ提供される。従って、ファームアップ時間データベース32は、運用コンソール2aが更新ファームセット30を受領する都度更新されることが好ましい。

0205

以上のことから、DB選択部24及びブロック分割部25の処理(図21のステップS1及びS2の処理、並びに図22及び図23の処理)は、仮想テープライブラリ装置1aのアップデートフロー一覧の更新があった場合に実行されればよい。一方、推定時間選択部26、第1算出部27、及び第2算出部28の処理(図21のステップS3〜S5の処理、並びに図24及び図25の処理)は、更新ファームセット30を受領した都度(ファームアップ処理を実行する都度)、実行されることが好ましい。

0206

以上のように、仮想テープライブラリ装置1aは、ファームウェアが新たにリリースされると、更新ファームセット30に含まれるファームアップ時間データベース32を用いて、ファームアップ時間推定部23により、総ファームアップ推定時間を求める。

0207

〔4〕付記
以上の実施形態に関し、更に以下の付記を開示する。

0208

(付記1)
ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第1処理ブロックを特定する特定部と、
前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定部が特定した第1処理ブロックごとの更新時間を推定する第1推定部と、
更新時間を示す情報及び前記第1推定部が推定した第1処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する第2推定部と、をそなえる
ことを特徴とする、情報処理装置。

0209

(付記2)
前記第1推定部は、前記更新時間を示す情報を用いて、前記特定部が特定した第1処理ブロックにおいて並行して更新処理が実行されるルートごとの更新時間を推定し、ルートごとに推定した更新時間のうちの最長の更新時間を当該第1処理ブロックの更新時間として推定する、
ことを特徴とする、付記1記載の情報処理装置。

0210

(付記3)
前記特定部は、前記実行順序を示す情報に基づき、前記複数の更新処理から、シーケンシャルに実行される一以上の更新処理を一処理ブロックとした一以上の第2処理ブロックを特定し、
前記第1推定部は、前記更新時間を示す情報を用いて、前記特定部が特定した第2処理ブロックにおける更新処理の更新時間を合計し、合計した更新時間を当該第2処理ブロックの更新時間と推定し、
前記第2推定部は、前記第1推定部が推定した第1処理ブロックごとの更新時間及び第2処理ブロックごとの更新時間を合計することで、前記対象装置の更新時間を推定する、
ことを特徴とする、付記2記載の情報処理装置。

0211

(付記4)
互いに装置構成の異なる複数の対象装置について、各対象装置が含む複数のモジュールに係る複数の更新処理の実行順序を示す情報を、装置構成と対応付けて保持する保持部と、
一の対象装置から当該一の対象装置の装置構成を示す情報を取得し、取得した装置構成に対応する実行順序を示す情報を前記保持部から取得する取得部と、をさらにそなえる
ことを特徴とする、付記1〜付記3のいずれか1項記載の情報処理装置。

0212

(付記5)
前記更新時間を示す情報には、更新前のソフトウェアの版数ごとに更新時間が設定され、
前記第1推定部は、一の対象装置から当該一の対象装置に係る更新前のソフトウェアの版数を示す情報を取得し、取得した情報が示す版数に対応する更新時間を、前記更新時間を示す情報から抽出し、抽出した更新時間を用いて前記推定を行なう、
ことを特徴とする、付記1〜付記4のいずれか1項記載の情報処理装置。

0213

(付記6)
コンピュータに、
ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第1処理ブロックを特定し、
前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定した第1処理ブロックごとの更新時間を推定し、
更新時間を示す情報及び前記推定した第1処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する、
処理を実行させることを特徴とする、更新時間推定プログラム。

0214

(付記7)
前記コンピュータに、
前記更新時間を示す情報を用いて、前記特定した第1処理ブロックにおいて並行して更新処理が実行されるルートごとの更新時間を推定し、ルートごとに推定した更新時間のうちの最長の更新時間を当該第1処理ブロックの更新時間として推定する、
処理を実行させることを特徴とする、付記6記載の更新時間推定プログラム。

0215

(付記8)
前記コンピュータに、
前記実行順序を示す情報に基づき、前記複数の更新処理から、シーケンシャルに実行される一以上の更新処理を一処理ブロックとした一以上の第2処理ブロックを特定し、
前記更新時間を示す情報を用いて、前記特定した第2処理ブロックにおける更新処理の更新時間を合計し、合計した更新時間を当該第2処理ブロックの更新時間と推定し、
前記推定した第1処理ブロックごとの更新時間及び第2処理ブロックごとの更新時間を合計することで、前記対象装置の更新時間を推定する、
処理を実行させることを特徴とする、付記7記載の更新時間推定プログラム。

0216

(付記9)
前記コンピュータに、
一の対象装置から当該一の対象装置の装置構成を示す情報を取得し、
互いに装置構成の異なる複数の対象装置について、各対象装置が含む複数のモジュールに係る複数の更新処理の実行順序を示す情報を装置構成と対応付けて保持する保持部から、前記取得した装置構成に対応する実行順序を示す情報を取得する、
処理を実行させることを特徴とする、付記6〜付記8のいずれか1項記載の更新時間推定プログラム。

0217

(付記10)
前記更新時間を示す情報には、更新前のソフトウェアの版数ごとに更新時間が設定され、
前記コンピュータに、
一の対象装置から当該一の対象装置に係る更新前のソフトウェアの版数を示す情報を取得し、
前記取得した情報が示す版数に対応する更新時間を、前記更新時間を示す情報から抽出し、
前記抽出した更新時間を用いて前記推定を行なう、
処理を実行させることを特徴とする、付記6〜付記9のいずれか1項記載の更新時間推定プログラム。

0218

(付記11)
ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置を管理する情報処理装置における更新時間推定方法であって、
前記情報処理装置が、
ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第1処理ブロックを特定し、
前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定した第1処理ブロックごとの更新時間を推定し、
更新時間を示す情報及び前記推定した第1処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する、
ことを特徴とする、更新時間推定方法。

0219

(付記12)
前記情報処理装置が、
前記更新時間を示す情報を用いて、前記特定した第1処理ブロックにおいて並行して更新処理が実行されるルートごとの更新時間を推定し、ルートごとに推定した更新時間のうちの最長の更新時間を当該第1処理ブロックの更新時間として推定する、
ことを特徴とする、付記11記載の更新時間推定方法。

0220

(付記13)
前記情報処理装置が、
前記実行順序を示す情報に基づき、前記複数の更新処理から、シーケンシャルに実行される一以上の更新処理を一処理ブロックとした一以上の第2処理ブロックを特定し、
前記更新時間を示す情報を用いて、前記特定した第2処理ブロックにおける更新処理の更新時間を合計し、合計した更新時間を当該第2処理ブロックの更新時間と推定し、
前記推定した第1処理ブロックごとの更新時間及び第2処理ブロックごとの更新時間を合計することで、前記対象装置の更新時間を推定する、
ことを特徴とする、付記12記載の更新時間推定方法。

0221

(付記14)
前記情報処理装置が、
一の対象装置から当該一の対象装置の装置構成を示す情報を取得し、
互いに装置構成の異なる複数の対象装置について、各対象装置が含む複数のモジュールに係る複数の更新処理の実行順序を示す情報を装置構成と対応付けて保持する保持部から、前記取得した装置構成に対応する実行順序を示す情報を取得する、
ことを特徴とする、付記11〜付記13のいずれか1項記載の更新時間推定方法。

0222

(付記15)
前記更新時間を示す情報には、更新前のソフトウェアの版数ごとに更新時間が設定され、
前記情報処理装置が、
一の対象装置から当該一の対象装置に係る更新前のソフトウェアの版数を示す情報を取得し、
前記取得した情報が示す版数に対応する更新時間を、前記更新時間を示す情報から抽出し、
前記抽出した更新時間を用いて前記推定を行なう、
ことを特徴とする、付記11〜付記14のいずれか1項記載の更新時間推定方法。

0223

1,1−1〜1−n対象装置
1a仮想テープライブラリ装置(複合システム)
2情報処理装置
2a運用コンソール(管理サーバ)
3ホストサーバ
4 制御システム
5a〜5d,7a〜7d,11a,11b制御装置
6a,6bFCスイッチ
8RAID装置
9a,9bテープライブラリ装置
10a,10b LANハブ
12a,12bライブラリ制御装置
13a,13b電源制御装置
21 保持部
22,22−1〜22−nアップデートフローデータベース
23ファームアップ時間推定部
24 DB選択部
25ブロック分割部
26推定時間選択部
27 第1算出部
28 第2算出部
29ファームウェア更新処理部
30更新ファームセット
31ファームウェアデータ
32 ファームアップ時間データベース
100,100−1〜100−m,100a モジュール

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ