ソフトウェア更新装置、ソフトウェア更新方法、及びソフトウェア更新プログラム
【課題】 モジュールが提供するサービスに対して、モジュールのソフトウェアの更新が与える影響を低減する、ソフトウェア更新装置を提供する。
【解決手段】＿本発明のソフトウェア更新装置は、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段とを含む。
【解決手段】＿本発明のソフトウェア更新装置は、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はソフトウェアの更新を行うためのソフトウェア更新装置、ソフトウェア更新方法、及びソフトウェア更新プログラムに関する。
【背景技術】
【０００２】
サービスを提供するモジュールを制御するソフトウェアに対して、例えば問題修正等の何らかの理由により更新を行う場合、通常、モジュールはサービスの提供を止める必要がある。しかし、サービスの提供に２４時間３６５日の継続性が求められている場合、ソフトウェアの更新の際でも、サービスの提供が中断されてはならない。ソフトウェアの更新は、サービスの提供を継続したまま安全かつ確実に実施される必要がある。このようなソフトウェアの例として、例えば、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）に代表されるディスクアレイ装置のコントローラの制御ソフトがある。ディスクアレイ装置は、例えば、ハードディスクなどの磁気ディスクの集合から構成したディスクプールを含む。ディスクアレイ装置は、ディスクプール上の領域を論理的に分割した論理ディスクを、例えば、ネットワーク（ＳＡＮ、Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）で接続された業務ホストに利用させる。業務ホストが２４時間３６５日継続して動作する場合、ディスクアレイ装置は、２４時間３６５日継続して、業務ホストが利用できるように、論理ディスクを提供する必要がある。
【０００３】
特許文献１には、２つの接続パスを介してホストコンピュータに接続されるストレージ装置の、各接続パスに対応する入出力ポートのマイクロプログラムの交換を、無停止で自動的に行う情報処理システムが記載されている。特許文献１のストレージ装置が含む各ハードディスクドライブは、それぞれ複数の入出力ポートに接続されている。
【０００４】
特許文献１に記載のストレージ装置は、まず、接続パスを介してホストコンピュータにマイクロプログラムの交換の開始を通知し、マイクロプログラムの交換のために閉塞する入出力ポートに対応する接続パスを休止させ、別の接続パスに切り替えさせる。接続パスの切り替えが完了した場合、ストレージ装置は、マイクロプログラムの交換を行う。ストレージ装置は、マイクロプログラムの交換の対象となる入出力ポートに対して、順次マイクロプログラムの交換を行う。
【０００５】
特許文献２には、稼働中であっても、ディスクアレイ装置を構成する記憶装置の制御ファームの適用を行うことができるディスクアレイ装置が記載されている。特許文献２のディスクアレイ装置は、ディスクアレイ装置が含む各記憶装置へのアクセス状況の監視を行う監視部を含む。
【０００６】
特許文献２のディスクアレイ装置は、監視部による監視の結果が所定条件を満たす場合に、指定した記憶装置への制御ファームの適用を実行する。所定条件は、例えば、所定時間連続して記憶装置へのアクセスがない場合や、所定期間内のアクセス頻度が所定値以下の場合である。
【０００７】
特許文献３には、ディスク装置と２つのコントローラ部（又は２つのエンクロージャ）を備えた基本筐体を含み、それぞれのコントローラ部又はエンクロージャが含むエクスパンダの制御プログラム（ファームウェア）を更新するストレージ装置が記載されている。特許文献３のストレージ装置は、ディスク装置と２つのエンクロージャを備えた１個以上の増設筐体も含む。エクスパンダは、ストレージ装置が含む基本筐体や増設筐体と、ディスク装置や他の増設筐体との間のインタフェースである。
【０００８】
特許文献３のストレージ装置は、コントローラ部又はエンクロージャのいずれかを指定した、管理端末からのダウンロード方法の指示に基づき、指定されたコントローラ部又はエンクロージャが含むエクスパンダのファームウェアの更新を行う。例えば、管理端末からの指示が、「省電力機能により電源を切る際にダウンロードを実行する」である場合、ストレージ装置は、省電力モードに移行する時にファームウェアの更新を行う。管理端末からの指示が、「即座にダウンロードを実行する」である場合、ストレージ装置は、即座にファームウェアの更新を行う。
【０００９】
管理端末からの指示が、「性能への影響を考慮してダウンロードを実施する」である場合、管理端末からのファームウェアの更新のタイミングの指示に基づき、エクスパンダのファームウェアの更新を行う。管理端末からの指示が、「指定した時間にダウンロードを実行する」である場合、ストレージ装置は、指定された時間にファームウェアの更新を行う。管理端末からの指示が、「即座にダウンロードを実行する」である場合、ストレージ装置は、即座にファームウェアの更新を行う。管理端末からの指示が、「Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）が少ないときにダウンロードを実施する」である場合、例えば、ＩＯＰＳ（Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｐｅｒ Ｓｅｃｏｎｄ）の値が所定値より小さい時にファームウェアの更新を行う。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００５−２４２５７４号公報
【特許文献２】特開２００９−２８２８３４号公報
【特許文献３】特開２０１０−０６１２８８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
特許文献１に記載のストレージ装置は、マイクロプログラムの交換の際、各入出力ポートに対するＩ／Ｏの負荷の大きさによらず、マイクロプログラムの交換の対象となる入出力ポートに対応する接続パスを休止する。この場合、マイクロプログラムの交換の対象となる入出力ポートが負担しているＩ／Ｏの負荷を、他の入出力ポートが分担して負担する。しかし、各入出力ポートのＩ／Ｏの負荷の和が、マイクロプログラムの交換の対象となる入出力ポート以外の入出力ポートの処理能力の和を超える場合、ストレージ装置に遅延などの性能低下が生じたり、性能低下が拡大したりすることがある。
【００１２】
特許文献２のディスクアレイ装置は、監視部による監視の結果、所定時間連続して記憶装置へのアクセスがない場合や、所定期間内のアクセス頻度が所定値以下の場合に、指定した記憶装置への制御ファームの適用を実行する。しかし、制御ファームの適用開始前の所定時間内において、アクセスが無いかアクセスの頻度が所定値以下であっても、制御ファームの適用開始後に、同様にアクセスが無いかアクセスの頻度が所定値以下であるわけではない。制御ファームの適用開始後にアクセス頻度が増大した場合、ディスクアレイ装置に遅延などの性能低下が生じたり、性能低下が拡大したりすることがある。
【００１３】
特許文献３のストレージ装置は、「性能への影響を考慮してダウンロードを実施する」場合、指定した時刻（即座を含む）か、Ｉ／Ｏが少ない時にファームウェアの更新を行う。しかし、指定した時刻にＩ／Ｏが少ないとは限らない。また、Ｉ／Ｏの多さを計測した時にＩ／Ｏが少なくても、ファームウェアの更新開始後に継続してＩ／Ｏが少ないとは限らない。ファームウェアの更新開始後にＩ／Ｏが増加し、ファームウェアの更新を行っていないコントローラ部やエンクロージャの処理能力を超えた場合、ストレージ装置に遅延などの性能低下が生じたり、性能低下が拡大したりすることがある。
【００１４】
本発明の目的は、上記問題を解決するソフトウェア更新装置を提供することにある。
【課題を解決するための手段】
【００１５】
本発明のソフトウェア更新装置は、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段とを含む。
【００１６】
本発明のソフトウェア更新方法は、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを負荷記憶手段に記憶し、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けてパッチ記憶手段に記憶し、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当て、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行する。
【００１７】
本発明のソフトウェア更新プログラムは、コンピュータを、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段として動作させる。
【発明の効果】
【００１８】
本発明には、モジュールが提供するサービスに対して、モジュールのソフトウェアの更新が与える影響を低減すると言う効果がある。
【図面の簡単な説明】
【００１９】
【図１】第１の実施形態の構成を表すブロック図である。
【図２】第１の実施形態のモジュールの例であるコントローラ部を含む、ディスクアレイ装置の構成の例を表すブロック図である。
【図３】第１の実施形態の動作を表すフローチャートである。
【図４】パッチ記憶部１２が記憶する更新の所要時間の例を表す図である。
【図５】負荷記憶部１１が記憶する負荷推移データの例を表す図である。
【図６】第２の実施形態の構成を表すブロック図である。
【図７】第２の実施形態のコントローラ部の構成の例を表すブロック図である。
【図８】第２の実施形態の更新実行予定割り当て時の動作を表すフローチャートである。
【図９】パッチ記憶部１２が記憶する更新の所要時間の第２の例を表す図である。
【図１０】負荷記憶部１１が記憶する負荷推移データの第２の例を表す図である。
【図１１】アップデート見積もり部による実行予定の割り当ての結果の例を表す図である。
【図１２】第２の実施形態の更新実行時の動作を表すフローチャートである。
【発明を実施するための形態】
【００２０】
次に、本発明の実施形態について、図面を参照して詳細に説明する。
【００２１】
以下で説明する本発明の各実施形態は、ハードウェア、コンピュータとコンピュータを制御するプログラム、あるいは、ハードウェアと、コンピュータとコンピュータを制御するプログラムとの組み合わせにより実現することができる。
【００２２】
図１は、本発明の第１の実施形態の構成を表すブロック図である。
【００２３】
図１を参照すると、本実施形態のソフトウェア更新装置１Ａは、負荷記憶部１１と、パッチ記憶部１２と、アップデート見積もり部１３と、アップデート実行部１４を含む。アップデート実行部１４には、モジュール２１Ａ及びモジュール２２Ａが接続されている。なお、アップデート実行部１４に接続されているモジュールの数は、図１に記載した例では２個であるが、２個に限らない。
【００２４】
負荷記憶部１１は、サービスを提供することによる各モジュールの負荷の合計の予測値を、時刻に対応付けた負荷推移データを記憶する。負荷の合計の予測値は、例えば、過去に測定した各モジュールの負荷の時系列データから算出した、負荷の合計値の同一時刻における平均値や中間値であればよい。負荷推移データは、負荷の合計値の同一時刻における平均値や中間値を、その時刻に対応付けたデータであればよい。
【００２５】
パッチ記憶部１２は、各モジュールを制御するソフトウェアに対する更新データと、その更新データを、各モジュールを制御するソフトウェアに適用するために要する所要時間を、対応付けて記憶する。以下の説明では、更新データをソフトウェアに適用することを、更新を実行すると表記する。
【００２６】
アップデート見積もり手段１３は、パッチ記憶部１２から所要時間を読み出す。アップデート見積もり手段１３は、読み出した所要時間以上継続して、負荷の合計の予測値が所定の閾値を下回る時間帯を、負荷記憶部１１が記憶する負荷推移データから抽出する。アップデート見積もり手段１３は、抽出した時間帯に、読み出した所要時間に対応する、ソフトウェアの更新の実行予定を割り当てる。
【００２７】
アップデート実行手段１４は、アップデート見積もり手段１３が割り当てた実行予定におけるソフトウェアの更新の実行開始時刻になると、ソフトウェアの更新の対象となるモジュールによるサービスの提供を停止させる。アップデート実行手段１４は、モジュールにサービスの提供を停止させた後、そのモジュールのソフトウェアに対して更新を実行する。
【００２８】
各モジュールは、各モジュールに接続されている、例えば計算装置や端末装置などに対して、何らかのサービスを提供する。各モジュールは、ソフトウェアにより制御される。各モジュールは、例えば、ＲＡＩＤに代表されるディスクアレイ装置の、ソフトウェアにより制御されるコントローラ部である。各モジュールは、コンピュータクラスタにおけるコンピュータや、コンピュータのネットワークインターフェースのコントローラであってもよい。本発明の各実施形態では、モジュールがディスクアレイ装置のＩ／Ｏを制御するコントローラ部である場合の説明を行う。
【００２９】
図２は、各モジュールが、ディスクアレイ装置のコントローラ部である場合の、ディスクアレイ装置２Ａの構成を表すブロック図である。
【００３０】
ディスクアレイ装置２Ａは、前述のモジュールであるコントローラ部２１及びコントローラ部２２と、ディスクアレイ２３を含む。ディスクアレイ２３は、ディスク２３１、ディスク２３２、…、ディスク２３Ｎを含む。
【００３１】
コントローラ部２１及びコントローラ部２２は、それぞれ、業務ホスト３Ａ及び業務ホスト３Ｂの両方に接続されている。コントローラ部２１及びコントローラ部２２は、業務ホスト３Ａ及び業務ホスト３Ｂに対して、ディスクアレイ装置に記録されているデータの読み書きのサービスを提供している。図２の例では、コントローラ部２１及びコントローラ部２２は冗長構成になっており、どちらか一方が停止しても、他方が動作することにより、業務ホスト３Ａ及び業務ホスト３Ｂに対するサービスの提供を継続することができる。
【００３２】
次に、本実施形態の動作について、図面を参照して詳細に説明する。
【００３３】
図３は本実施形態のソフトウェア更新装置１Ａの動作を表すフローチャートである。
【００３４】
ソフトウェア更新装置１Ａは、例えば、所定の時間毎にモジュールのソフトウェアに対して適用すべき更新データの有無を調べ、適用すべき更新データが存在する場合、図３の動作を開始すればよい。ソフトウェア更新装置１Ａは、例えば、図示しない管理ホストからの指示により、図３の動作を開始してもよい。どちらの場合も、例えば図示しない管理ホストが、パッチ記憶部１２に適用すべき更新データを格納し、適用すべき更新データを特定する情報をソフトウェア更新装置１Ａに送信しておけばよい。
【００３５】
図３を参照すると、まず、アップデート見積もり部１３が、パッチ記憶部１２から、モジュールのソフトウェアの更新データに対応付けられた、ソフトウェアの更新を実行するために要する所要時間を読み出す（ステップＳ１１）。
【００３６】
パッチ記憶部１２は、所要時間を、例えばテーブルの形で記憶しておけばよい。
【００３７】
図４は、パッチ記憶部１２が記憶する、所要時間の例である。図４の例では、所要時間に更新データ名が対応付けられている。
【００３８】
更新データ及び所要時間を、例えば図示しない管理ホストが、パッチ記憶部１２に予め記憶させておけばよい。更新データは、複数の更新データを一つにまとめたパッチセットであってもよい。更新データがパッチセットである場合、所要時間は、パッチセットに含まれる全ての更新データをソフトウェアに適用するために要する時間である。パッチ記憶部１２は、パッチセットに対応する所要時間を記憶しておけばよい。また、アップデート見積もり部１３が、パッチセットに含まれる個々の更新データに対応する所要時間をパッチ記憶部１２から読み出し、例えば所要時間の中で最長の所要時間をパッチセットの所要時間にするなど、既存の方法でパッチセットの所要時間を算出してもよい。
【００３９】
次に、アップデート見積もり部１３が、ソフトウェアの更新の所要時間以上継続して、負荷の合計が閾値を下回る時間帯を、負荷記憶部１１が記憶する負荷推移データから抽出する（ステップＳ１２）。
【００４０】
負荷記憶部１１は、負荷推移データを、例えばテーブルの形で記憶しておけばよい。
【００４１】
図５は、負荷推移データの例を表す図である。図５の例では、負荷推移データは、１０秒間隔の負荷の合計値である。
【００４２】
負荷推移データは、時刻に対応付けられた、例えば所定の時間間隔の、例えばＩＯＰＳで表した各モジュールの負荷の合計値である。負荷の大きさを表す値は、既存の任意の値であってよい。なお、ＩＯＰＳは、１秒当たりのＩ／Ｏ数である。
【００４３】
負荷推移データの時間間隔は任意であり、１秒であっても、１０秒であっても、１分であっても、それ以外の時間であってもよい。また、負荷記憶部１１が記憶する負荷推移データの量は任意であり、１日分であっても、１ヶ月分であっても、１年分であっても、それ以外の量であってもよい。負荷推移データが含む負荷の合計値は、同一時刻に計測した各モジュールの負荷を合計した値の、例えば平均や中央値などの統計量であればよい。
【００４４】
負荷の合計値に対する閾値は、ソフトウェアの更新の対象となるモジュール以外のモジュールだけで全ての負荷を負担しても、提供するサービスに遅延などの悪影響が及ばないような負荷の合計値を、適宜選択した値であればよい。閾値は、計算上提供するサービスに遅延などの影響が及ばないような負荷の合計値から、安全を考えたマージン分を引いた値であってもよい。
【００４５】
アップデート見積もり部１３は、次に、読み出した所要時間に対応する更新データをソフトウェアに対して適用するソフトウェアの更新の実行予定を、抽出した時間帯に割り当てる（ステップＳ１３）。
【００４６】
なお、複数のモジュールのソフトウェアに対して同一の更新を適用する場合、更新を適用していないモジュールが無くなるまで、ステップＳ１２及びステップＳ１３の処理を繰り返せばよい。また、適用すべき更新データが複数存在する場合、更新の実行予定を割り当てていない更新データが無くなるまで、ステップＳ１２及びステップＳ１３の処理を繰り返せばよい。
【００４７】
アップデート見積もり部１３が割り当てた更新予定における、更新の開始時刻になるまで、アップデート実行部１４は何も行わない（ステップＳ１４、Ｎ）。
【００４８】
アップデート見積もり部１３が割り当てた更新予定における、更新の開始時刻になると（ステップＳ１４、Ｙ）、アップデート実行部１４は、ソフトウェアの更新の対象となるモジュールに、サービスの提供を中止させる（ステップＳ１５）。
【００４９】
なお、アップデート実行部１４は、ソフトウェアの更新の対象となるモジュールにサービスの提供を中止させる前に、ソフトウェアの更新の対象となるモジュール以外に正常動作しているモジュールが存在するか確認してもよい。そして、ソフトウェアの更新の対象となるモジュール以外に正常動作しているモジュールが存在しない場合、アップデート実行部１４は、ソフトウェアの更新の対象となるモジュールにサービスの提供を継続させてもよい。この場合、ソフトウェア更新装置１Ａはソフトウェアの更新を中止すればよい。また、ソフトウェアの更新の対象となるモジュール以外に正常動作しているモジュールが存在する場合、アップデート実行部１４は、ソフトウェアの更新の対象となるモジュールにサービスの提供を中止させればよい。
【００５０】
各モジュールがディスクアレイ装置のコントローラ部である場合、アップデート実行部１４は、データの転送において、ソフトウェアの更新の対象となるコントローラ部を経由しないよう、データ転送のパスを変更するのに必要な処理を適宜行えばよい。各パスは、各コントローラ部と各業務ホストとの間の、データ転送のための接続である。
【００５１】
次に、アップデート実行部１４は、パッチ記憶部１２から更新データを読み出し、ソフトウェアの更新の対象となるモジュールのソフトウェアに対して、読み出した更新データを適用してソフトウェアの更新を行う（ステップＳ１６）。
【００５２】
アップデート実行部１４は、ソフトウェアの更新を終了すると、ソフトウェアの更新の対象であったモジュールに、サービスの提供を再開させる（ステップＳ１７）。
【００５３】
各モジュールがディスクアレイ装置のコントローラ部である場合、アップデート実行部１４は、ソフトウェアの更新の対象であったコントローラ部を適宜経由してデータの転送が行われるよう、データ転送のパスを変更するのに必要な処理を適宜行えばよい。
【００５４】
次に、本実施形態の効果について説明する。
【００５５】
本実施形態には、モジュールが提供するサービスに対して、モジュールのソフトウェアの更新が与える影響を低減すると言う効果がある。
【００５６】
その理由は、ソフトウェアの更新の所要時間以上継続して、負荷の合計が閾値を下回る時間帯を、負荷記憶部１１が記憶する負荷推移データから抽出し、ソフトウェアの更新の実行予定を割り当てるからである。負荷の合計に対する閾値は、ソフトウェアの更新の対象となるモジュール以外のモジュールで全ての負荷を負担しても、各モジュールが提供するサービスに遅延などの影響が及ばないように選択した値である。従って、本実施形態のソフトウェア更新装置１Ａは、アップデート実行部１４がソフトウェアの更新を行っている間における、各モジュールが提供するサービスに対する遅延などの影響を軽減することができる。
【００５７】
以上では、複数のモジュールが冗長な構成で存在するとして説明を行った。しかし、モジュールは、冗長な構成でなくてもよく、複数でなくてもよい。その場合、負荷記憶部１１は、モジュール毎の負荷を時刻に対応付けて記憶しておけばよい。また、アップデート見積もり部１３は、長さがソフトウェアの更新の所要時間以上であり、ソフトウェアの更新の対象となるモジュールの負荷が所定の閾値を下回る時間帯を抽出する。さらに、アップデート実行部１４がソフトウェアの更新を行う間、モジュールはサービスの提供を停止する。しかし、アップデート見積もり部１３が、ソフトウェアの更新の対象となるモジュールの負荷が所定の閾値を下回る時間帯を抽出するので、モジュールが提供するサービスに対して、モジュールのソフトウェアの更新が与える影響を低減することができる。
【００５８】
次に、本発明の第２の実施形態について、図面を参照して詳細に説明する。
【００５９】
図６は、本実施形態の構成を表すブロック図である。
【００６０】
図６を参照すると、本実施形態は、ソフトウェア更新装置１と、ディスクアレイ装置２と、業務ホスト３Ａ及び業務ホスト３Ｂと、管理ホスト４を含む。図６では、ソフトウェア更新装置１とディスクアレイ装置２は、別の装置であるが、ディスクアレイ装置２がソフトウェア更新装置１を含んでいても構わない。
【００６１】
ソフトウェア更新装置１は、図１に示すソフトウェア更新装置１Ａの構成に加えて、閾値記憶部１５を含む。また、ソフトウェア更新装置１は、負荷監視部１６を含んでいてもよい。なお、本実施形態では、ソフトウェアの更新の対象であるモジュールは、ディスクアレイ装置２の各コントローラ部である。
【００６２】
アップデート実行部１４は、アップデート見積もり手段１３が割り当てた実行予定におけるソフトウェアの更新の実行開始時刻になると、ソフトウェアの更新の対象となるコントローラ部を経由しないよう、データ転送のパスを切り替える指示を出力する。この指示の出力先は、後述のディスクアレイ装置２のパス切り替え部２５である。アップデート実行手段１４は、パスを切り替える指示を出力した後、そのコントローラ部のソフトウェアに対して更新を実行する。
【００６３】
閾値記憶部１５は、負荷の合計値に対する閾値を、時刻に対応させて記憶する。閾値記憶部１５が記憶する閾値は、時刻によって異なる値であってよい。例えば管理ホスト４が、時刻に対応付けた閾値を、予め閾値記憶部１５に記憶させておけばよい。
【００６４】
負荷監視部１６は、例えば所定の時間毎に、各コントローラの負荷を計測する。負荷監視部１６は、過去の所定の期間内における同一時刻の負荷の計測値から、例えば平均などの統計値を算出し、時刻毎の負荷の合計の予測値を算出してもよい。負荷監視部１６は、算出した予測値を、随時負荷記憶部１１に記憶させればよい。負荷監視部１６は、過去の所定の期間内における同一時刻の負荷の計測値から、ディスクアレイ装置２からの応答に遅延を発生させずに、コントローラ部を利用不可にできるか否かを判定するための閾値を算出してもよい。この場合の算出方法は、既存の任意の方法でよい。負荷監視部１６は、算出した閾値を、随時閾値算出部１２に記憶させればよい。
【００６５】
本実施形態のソフトウェア更新装置１の他の構成要素は、第１の実施形態の同一の記号を付した構成要素と同じであるので、説明を省略する。
【００６６】
ディスクアレイ装置２は、コントローラ部２１及びコントローラ部２２と、ディスクアレイ２３と、パス状態登録部２４と、パス切り替え部２５を含む。
【００６７】
ディスクアレイ装置２のコントローラ部２１及びコントローラ部２２は、それぞれ各業務ホストに接続されている。各コントローラは、各業務ホストと通信可能である。各コントローラと、各業務ホストとの間は、例えばＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）のネットワークで接続されている。
【００６８】
コントローラ部２１及びコントローラ部２２は、ディスクアレイ２３に対するデータの読み書きや転送を制御する。コントローラ部２１及びコントローラ部２２は冗長構成になっている。また、コントローラ部は３個以上存在していてもよい。各コントローラ部はソフトウェアにより制御される。
【００６９】
図７は、コントローラ部２１を制御するソフトウェアの構成の例を表す図である。他のコントローラ部の構成も、図７の構成と同じである。なお、コントローラ部の構成は図７の構成に限らない。
【００７０】
図７を参照すると、コントローラ部２１は、実行環境２１１で動作するソフトウェアにより制御される。図７の例では、実行環境２１１のソフトウェアには、管理ＳＷ（Ｓｏｆｔｗａｒｅ）と、ＲＡＩＤ制御（ＲＡＩＤ制御ドライバ）と、ＯＳ（Ｏｐｅｒａｔｉｏｎｇ Ｓｙｓｔｅｍ）の３種類の種別が存在する。バックアップ環境２１２は、実行環境２１１のコピーである。
【００７１】
ディスクアレイ２３は、各業務ホストが各コントローラ部を介して読み書きするデータを記憶する。
【００７２】
パス状態登録部２４は、各コントローラと各業務ホストとの間のパスが、有効であるか否かを表すパス状態を記憶する。また、パス状態登録部２４は、後述の各業務ホストのパス管理部３１からパス状態を受信し、記憶しているパス状態を変更する。
【００７３】
パス切り替え部２５は、アップデート実行部１４からの指示に基づき、各コントローラ部を各業務ホストから利用できない状態に変更する。また、パス切り替え部２５は、アップデート実行部１４からの指示に基づき、各コントローラ部を各業務ホストから利用できる状態に変更する。
【００７４】
図６には、業務ホスト３Ａ及び業務ホスト３Ｂの２台の業務ホストが記載されているが、業務ホストは２台でなくてもよい。各業務ホストは、パス管理部３１を含む。各業務ホストは各コントローラに同時に接続され、各コントローラ部を介して、ディスクアレイ２３が記憶するデータの読み書きを行う。
【００７５】
パス管理部３１は、各コントローラ部との間のパスが利用可能であるか否かを監視する。パス管理部３１は、例えば、各コントローラ部に対するＩ／Ｏエラーの発生の有無を定期的に確認することで、監視を行えばよい。パス管理部３１は、利用不可であるコントローラ部が存在すれば、業務ホストとそのコントローラ部との間のパスの利用を禁止する。また、パス管理部３１は、利用不可であったコントローラ部が利用可能になれば、業務ホストとそのコントローラ部との間のパスの利用を許可する。
【００７６】
例えば、図６のようにディスクアレイ装置２と業務ホスト３Ａが接続されており、各コントローラが正常動作していれば、コントローラ部２１と業務ホスト３Ａの間、及び、コントローラ部２２と業務ホスト３Ａの間の２つのパスが利用できる。この状態から、パス切り替え部２５が、例えばコントローラ部２１を利用不可にした場合、パス管理部３１はコントローラ部２１に対するＩ／Ｏエラーの発生を検出し、コントローラ部２１との間のパスを利用不可にする。このようにして、２本のパスが利用可能な状態から１本のパスだけが可能な状態にパスの状態が切り替わる、いわゆる片寄せが行われる。
【００７７】
また、各装置が図６のような構成であり、パス切り替え部２５が、コントローラ部２１を、利用不可な状態から利用可能な状態に切り替えた場合、パス管理部３１はコントローラ部２１に対するＩ／Ｏエラーが発生しないことを検出する。Ｉ／Ｏエラーが発生しないことを検出したパス管理部３１は、コントローラ部２１との間のパスを利用可能にする。
【００７８】
パス管理部３１は、業務ホストとストレージ装置２との間のいずれかのパスを介して、監視の結果得られた各パスの状態を、ストレージ装置２のパス状態登録部２４に記憶させる。
【００７９】
なお、以上で説明したパスの切り替えは単なる例である。ディスクアレイ装置２及び各業務ホストは、既存の任意の方法でパスの切り替えを行うことができる。
【００８０】
管理ホスト４は、アップデート指示部４１を含む。
【００８１】
アップデート指示部４１は、パッチ記憶部１２に更新データ及び所要時間を記憶させる。アップデート指示部４１は、アップデート見積もり部１３に対して、ソフトウェアの更新の実行予定を割り当てる指示を送信してもよい。
【００８２】
次に、本実施形態のソフトウェア更新装置１の動作について、図面を参照して詳細に説明する。
【００８３】
図８は、本実施形態のソフトウェア更新装置１の、更新の実行予定を割り当てる動作を表すフローチャートである。ソフトウェア更新装置１は、例えば、アップデート指示部４１から適用すべき更新データを特定する情報を受け取り、以下の動作を開始する。
【００８４】
図８を参照すると、まず、アップデート見積もり部１３が、各コントローラ部のソフトウェアに適用する更新データに対応付けられた更新の所要時間を、パッチ記憶部１２から読み出す（ステップＳ２１）。
【００８５】
パッチ記憶部１２は、所要時間を、対応する更新データに関する情報に関連付けて、例えばテーブルの形で記憶することもできる。
【００８６】
図９は、パッチ記憶部１２が記憶する、所要時間と、対応する更新データに関する情報を含むテーブルの例である。図９のテーブルは、更新の対象となるソフトウェアの種別と、更新の対象となるモジュール名と、更新後の再起動の要否を含む再起動種別と、所要時間と、更新時におけるパスの切替要否を含む。
【００８７】
種別は、パッチを適用する対象となる制御ソフトの種別を表す。種別には、例えば、前述の、管理ソフトウェア、ＲＡＩＤ制御ドライバ、ＯＳなどがある。ソフトウェアモジュール名は、ソフトウェを構成するソフトウェアモジュールを識別する名前である。再起動種別は、更新の実行後に再起動が不要であるか、再起動が必要な場合は再起動後に高速再起動が可能であるか否かを表す。なお、高速再起動は、例えばＰＯＳＴ（Ｐｏｗｅｒ Ｏｎ Ｓｅｌｆ Ｔｅｓｔ）を実行しない再起動である。再起動種別が「無し」の場合、更新の実行後の再起動は不要である。再起動種別が「高速」の場合、パッチ適用後に再起動が必要だが高速再起動が可能である。再起動種別が「通常」の場合、パッチ適用後に通常の再起動が必要である。
【００８８】
所要時間は、更新を開始してからコントローラ部が再び動作可能になるまでに必要な時間である。所要時間は、適宜見積もった必要な時間の概算で構わない。図９の例では、再起動種別が「無し」の場合、所要時間は０秒である。再起動種別が「高速」の場合、所要時間は１０秒である。再起動種別が「通常」の場合、所要時間は６００秒〜７００秒である。
【００８９】
切替要否は、更新の実行時に、パス切り替えが必要になるかどうかを表す。切り替え要否は、例えば、所要時間が所定の閾値以上であるか閾値未満であるかにより、予め決めておけばよい。各業務ホストから利用可能であったコントローラ部が、継続して利用できなくなった場合、利用できなくなってから各業務ホストで行われている処理に影響を及ぼすと考えられる時間を、予めこの閾値に設定しておけばよい。図７の切替要否は、閾値が１０以上６００未満の場合の例である。
【００９０】
なお、パッチ記憶部１２は、各更新データに対応した切替要否を記憶しておく必要はない。パッチ記憶部１２が切替要否を記憶していない場合、後述のステップＳ２２において、アップデート見積もり部１３が、所要時間と閾値を比較することで、パスの切替要否を判定すればよい。また、後述のステップＳ３２において、パッチ実行部１４は、アップデート見積もり部１３によるパスの切替要否を判定結果をそのまま利用すればよい。あるいは、パッチ実行部１４が、所要時間と閾値を比較することで、パスの切替要否を判定してもよい。
【００９１】
パッチ記憶部１２は、個別の更新データの所要時間やその更新データに関する情報だけでなく、複数の更新データをまとめたパッチセットの所要時間などの情報を、パッチセットに関連付けて記憶していてもよい。
【００９２】
アップデート見積もり部１３は、次に、更新データを適用する際のパスの切替要否を判定する（ステップＳ２２）。
【００９３】
単体の更新データを適用する場合、アップデート見積もり部１３は、パッチ記憶部１２から読み出した、適用する更新データの切替要否のデータに基づき、パスの切替要否を判定すればよい。ソフトウェアに対してパッチセットを適用する場合、パッチ記憶部１２がそのパッチセットのパス切替要否のデータを記憶していれば、アップデート見積もり部１３は、そのデータに基づきパスの切替要否を判定すればよい。パッチ記憶部１２がそのパッチセットのパス切替要否のデータを記憶していない場合、アップデート見積もり部１３は、そのパッチセットが、パス切替が必要な更新データを含んでいれば、パス切替が必要と判定すればよい。
【００９４】
パス切替が不要である場合（ステップＳ２３、Ｎ）、アップデート実行部１４はすぐに更新を実行すればよい（ステップＳ２７）。更新の実行については後述する。
【００９５】
パス切替が必要である場合（ステップＳ２３、Ｙ）、アップデート見積もり部１３は、更新の所要時間以上継続して、負荷の合計値が閾値を下回る時間帯を、負荷記憶部１１が記憶する負荷推移データから抽出する（ステップＳ２４）。
【００９６】
アップデート見積もり部１３は、更新の所要時間を、パッチ記憶部１２から読み出せばよい。
【００９７】
図１０は、負荷記憶部１１が記憶する負荷推移データの例を表す図である。負荷推移データは、少なくとも負荷の合計値の推移を含んでいればよい。負荷記憶部１１が記憶する負荷の値は、例えばＩＯＰＳである。
【００９８】
また、アップデート見積もり部１３は、負荷の合計値に対する閾値を、閾値記憶部１５から読み出せばよい。前述のように、閾値記憶部１５が記憶する閾値は、時刻によって変動してもよい。この場合、例えばディスクアレイ装置２の管理者が、時刻に応じて適宜定めた閾値を、予め閾値記憶部１５に記憶させておけばよい。閾値記憶部１５が記憶する閾値は、過去の同時刻において、例えば負荷監視部１６が観測した、負荷の値のばらつきの大きさに応じた値であってもよい。閾値記憶部１５が記憶する閾値は、例えば、計算上提供するサービスに遅延などの影響が及ばないような負荷の合計値から、各時刻における負荷の観測値のばらつきの大きさに応じた値を引いた値であってもよい。この場合、負荷の観測値のばらつきが大きい時刻の閾値は小さく、負荷の観測値のばらつきが小さい時刻の閾値は大きくなる。
【００９９】
図１１は、アップデート見積もり部１３が抽出した時間帯を表す図である。アップデート見積もり部１３は、図１１のようなテーブルを生成して、時間帯の抽出を行うことができる。図１１の「負荷の閾値」は、閾値記憶部１５が記憶する閾値である。「負荷の予測値」は、負荷記憶部１１が記憶する負荷の合計値である。アップデート見積もり部１３は、「負荷の閾値」より「負荷の予測値」が小さく、「差分」が正である時間帯を抽出する。図１１でアップデート見積もり部１３が抽出した時間帯は、実行可否が「ＯＫ」である時間帯である。
【０１００】
条件に適合する時間帯が存在しない場合（ステップＳ２５、Ｎ）、ソフトウェア更新装置１は、更新の実行や更新の実行予定の割り当てを行わずに、処理を終了する。この場合は、例えばディスクアレイ装置２の管理者が手動で更新を実行するなどすればよい。
【０１０１】
条件に適合する時間帯が存在する場合（ステップＳ２５、Ｙ）、その時間帯が現在であり即時更新を実行することが可能であれば（ステップＳ２６、Ｙ）、アップデート実行部１４は更新を実行する（ステップＳ２７）。
【０１０２】
条件に適合する時間帯が現在ではなく、即時更新を実行できない場合（ステップＳ２６、Ｎ）、アップデート見積もり部１３は、更新の実行予定を割り当てる（ステップＳ２８）。この場合、更新の実行予定時刻に、アップデート実行部１４が、以下で述べるように更新を実行すればよい。
【０１０３】
次に、更新実行時の本実施形態の動作について説明する。
【０１０４】
図１２は、更新実行時の本実施形態の動作を表すフローチャートである。なお、ソフトウェア更新装置１は、負荷監視部１６が測定した更新の実行予定時刻における負荷の合計値が、閾値記憶部１５が記憶する同時刻における閾値より大きい場合、更新の実行を中止してもよい。その場合、ソフトウェア更新装置１は、前述の更新の実行予定の割り当てを再び行えばよい。
【０１０５】
図１２を参照すると、アップデート実行部１４が、更新データ、及び、所要時間等の、その更新データに対応する情報を含むパッチ情報を、パッチ記憶部１２から読み出す（ステップＳ３１）。
【０１０６】
アップデート実行部１４は、次に、例えば読み出したパッチ情報から、更新の実行時におけるパスの切替の要否を判別する（ステップＳ３２）。アップデート実行部１４は、更新を実行する際のパスの切替の要否を、アップデート見積もり部１３から受け取ってもよい。
【０１０７】
パスの切替が必要ない場合（ステップＳ３３、Ｎ）、アップデート実行部１４は、更新を実行する（ステップＳ３８）。
【０１０８】
パスの切替が必要である場合（ステップＳ３３、Ｙ）、アップデート実行部１４は、ディスクアレイ装置２と全ての業務ホストとの間のパスが正常であるか確認する（ステップＳ３４）。ステップＳ３４において、アップデート実行部１４は、ソフトウェアの更新の対象となるコントローラ部を停止させた場合、全ての業務ホストとの間に正常なパスが存在するか否かを確認すればよい。アップデート実行部１４は、各コントローラ部と各業務ホストとの間の、全てのパスが正常であるか確認してもよい。
【０１０９】
アップデート実行部１４は、ステップＳ３４の確認を、例えば、ストレージ装置２のパス状態登録部２４から各パスの状態を受け取ることで行えばよい。
【０１１０】
パスが正常でない業務ホストが存在する場合（ステップＳ３４、Ｎ）、ソフトウェア更新装置１は処理を終了する。
【０１１１】
パスが正常でない業務ホストが存在しない場合（ステップＳ３４、Ｙ）、アップデート実行部１４は、パス切り替え部２５に指示を送信してパスの切り替えを行う（ステップＳ３５）。アップデート実行部１４からパスの切り替えの指示を受信したパス切り替え部２５は、ソフトウェアの更新の対象であるコントローラ部と各業務ホストとの間の全てのパスを、利用不可にすればよい。
【０１１２】
アップデート実行部１４は、パスの切替を行った後、更新を実行する（ステップＳ３６）。
【０１１３】
アップデート実行部１４は、更新の実行後、パス切り替え部２５に指示を送信して、パスの復旧を行う（ステップＳ３７）。アップデート実行部１４からパスの復旧の指示を受信したパス切り替え部２５は、ソフトウェアの更新を行ったコントローラ部と各業務ホストとの間の全てのパスを、再び利用可能にすればよい。
【０１１４】
以上で説明した本実施形態には、第１の実施形態の効果に加えて、同一時刻の負荷の大きさにばらつきがある場合でも、コントローラ部が提供するサービスに対して、コントローラ部のソフトウェアの更新が与える影響を低減すると言う効果がある。
【０１１５】
その理由は、更新の実行予定を割り当てる際、アップデート見積もり部１３が、時刻に応じて値が変動する閾値と、負荷の合計値を比較するからである。例えば、負荷の大きさのばらつきが大きい時刻の閾値を小さく、負荷の大きさのばらつきが小さい時刻の閾値を大きくしておくことで、負荷の予測値は小さいが大きな負荷の変動が起こりうる時間帯の更新を実行することを避けることができる。このことにより、例えば、更新の実行中に急に負荷が増大することで発生する遅延のような、コントローラ部のソフトウェアの更新による影響の発生を減少させることができる。
【０１１６】
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解しうる様々な変更をすることができる。
【符号の説明】
【０１１７】
１、１Ａ ソフトウェア更新装置
２、２Ａ ディスクアレイ装置
３Ａ、３Ｂ 業務ホスト
４ 管理ホスト
１１ 負荷記憶部
１２ パッチ記憶部
１３ アップデート見積もり部
１４ アップデート実行部
１５ 閾値記憶部
１６ 負荷監視部
２１、２２ コントローラ部
２１Ａ、２２Ａ モジュール
２３ ディスクアレイ
２４ パス状態登録部
２５ パス切り替え部
３１ パス管理部
４１ アップデート指示部
２１１ 実行環境
２１２ バックアップ環境
【技術分野】
【０００１】
本発明はソフトウェアの更新を行うためのソフトウェア更新装置、ソフトウェア更新方法、及びソフトウェア更新プログラムに関する。
【背景技術】
【０００２】
サービスを提供するモジュールを制御するソフトウェアに対して、例えば問題修正等の何らかの理由により更新を行う場合、通常、モジュールはサービスの提供を止める必要がある。しかし、サービスの提供に２４時間３６５日の継続性が求められている場合、ソフトウェアの更新の際でも、サービスの提供が中断されてはならない。ソフトウェアの更新は、サービスの提供を継続したまま安全かつ確実に実施される必要がある。このようなソフトウェアの例として、例えば、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）に代表されるディスクアレイ装置のコントローラの制御ソフトがある。ディスクアレイ装置は、例えば、ハードディスクなどの磁気ディスクの集合から構成したディスクプールを含む。ディスクアレイ装置は、ディスクプール上の領域を論理的に分割した論理ディスクを、例えば、ネットワーク（ＳＡＮ、Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）で接続された業務ホストに利用させる。業務ホストが２４時間３６５日継続して動作する場合、ディスクアレイ装置は、２４時間３６５日継続して、業務ホストが利用できるように、論理ディスクを提供する必要がある。
【０００３】
特許文献１には、２つの接続パスを介してホストコンピュータに接続されるストレージ装置の、各接続パスに対応する入出力ポートのマイクロプログラムの交換を、無停止で自動的に行う情報処理システムが記載されている。特許文献１のストレージ装置が含む各ハードディスクドライブは、それぞれ複数の入出力ポートに接続されている。
【０００４】
特許文献１に記載のストレージ装置は、まず、接続パスを介してホストコンピュータにマイクロプログラムの交換の開始を通知し、マイクロプログラムの交換のために閉塞する入出力ポートに対応する接続パスを休止させ、別の接続パスに切り替えさせる。接続パスの切り替えが完了した場合、ストレージ装置は、マイクロプログラムの交換を行う。ストレージ装置は、マイクロプログラムの交換の対象となる入出力ポートに対して、順次マイクロプログラムの交換を行う。
【０００５】
特許文献２には、稼働中であっても、ディスクアレイ装置を構成する記憶装置の制御ファームの適用を行うことができるディスクアレイ装置が記載されている。特許文献２のディスクアレイ装置は、ディスクアレイ装置が含む各記憶装置へのアクセス状況の監視を行う監視部を含む。
【０００６】
特許文献２のディスクアレイ装置は、監視部による監視の結果が所定条件を満たす場合に、指定した記憶装置への制御ファームの適用を実行する。所定条件は、例えば、所定時間連続して記憶装置へのアクセスがない場合や、所定期間内のアクセス頻度が所定値以下の場合である。
【０００７】
特許文献３には、ディスク装置と２つのコントローラ部（又は２つのエンクロージャ）を備えた基本筐体を含み、それぞれのコントローラ部又はエンクロージャが含むエクスパンダの制御プログラム（ファームウェア）を更新するストレージ装置が記載されている。特許文献３のストレージ装置は、ディスク装置と２つのエンクロージャを備えた１個以上の増設筐体も含む。エクスパンダは、ストレージ装置が含む基本筐体や増設筐体と、ディスク装置や他の増設筐体との間のインタフェースである。
【０００８】
特許文献３のストレージ装置は、コントローラ部又はエンクロージャのいずれかを指定した、管理端末からのダウンロード方法の指示に基づき、指定されたコントローラ部又はエンクロージャが含むエクスパンダのファームウェアの更新を行う。例えば、管理端末からの指示が、「省電力機能により電源を切る際にダウンロードを実行する」である場合、ストレージ装置は、省電力モードに移行する時にファームウェアの更新を行う。管理端末からの指示が、「即座にダウンロードを実行する」である場合、ストレージ装置は、即座にファームウェアの更新を行う。
【０００９】
管理端末からの指示が、「性能への影響を考慮してダウンロードを実施する」である場合、管理端末からのファームウェアの更新のタイミングの指示に基づき、エクスパンダのファームウェアの更新を行う。管理端末からの指示が、「指定した時間にダウンロードを実行する」である場合、ストレージ装置は、指定された時間にファームウェアの更新を行う。管理端末からの指示が、「即座にダウンロードを実行する」である場合、ストレージ装置は、即座にファームウェアの更新を行う。管理端末からの指示が、「Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）が少ないときにダウンロードを実施する」である場合、例えば、ＩＯＰＳ（Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｐｅｒ Ｓｅｃｏｎｄ）の値が所定値より小さい時にファームウェアの更新を行う。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００５−２４２５７４号公報
【特許文献２】特開２００９−２８２８３４号公報
【特許文献３】特開２０１０−０６１２８８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
特許文献１に記載のストレージ装置は、マイクロプログラムの交換の際、各入出力ポートに対するＩ／Ｏの負荷の大きさによらず、マイクロプログラムの交換の対象となる入出力ポートに対応する接続パスを休止する。この場合、マイクロプログラムの交換の対象となる入出力ポートが負担しているＩ／Ｏの負荷を、他の入出力ポートが分担して負担する。しかし、各入出力ポートのＩ／Ｏの負荷の和が、マイクロプログラムの交換の対象となる入出力ポート以外の入出力ポートの処理能力の和を超える場合、ストレージ装置に遅延などの性能低下が生じたり、性能低下が拡大したりすることがある。
【００１２】
特許文献２のディスクアレイ装置は、監視部による監視の結果、所定時間連続して記憶装置へのアクセスがない場合や、所定期間内のアクセス頻度が所定値以下の場合に、指定した記憶装置への制御ファームの適用を実行する。しかし、制御ファームの適用開始前の所定時間内において、アクセスが無いかアクセスの頻度が所定値以下であっても、制御ファームの適用開始後に、同様にアクセスが無いかアクセスの頻度が所定値以下であるわけではない。制御ファームの適用開始後にアクセス頻度が増大した場合、ディスクアレイ装置に遅延などの性能低下が生じたり、性能低下が拡大したりすることがある。
【００１３】
特許文献３のストレージ装置は、「性能への影響を考慮してダウンロードを実施する」場合、指定した時刻（即座を含む）か、Ｉ／Ｏが少ない時にファームウェアの更新を行う。しかし、指定した時刻にＩ／Ｏが少ないとは限らない。また、Ｉ／Ｏの多さを計測した時にＩ／Ｏが少なくても、ファームウェアの更新開始後に継続してＩ／Ｏが少ないとは限らない。ファームウェアの更新開始後にＩ／Ｏが増加し、ファームウェアの更新を行っていないコントローラ部やエンクロージャの処理能力を超えた場合、ストレージ装置に遅延などの性能低下が生じたり、性能低下が拡大したりすることがある。
【００１４】
本発明の目的は、上記問題を解決するソフトウェア更新装置を提供することにある。
【課題を解決するための手段】
【００１５】
本発明のソフトウェア更新装置は、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段とを含む。
【００１６】
本発明のソフトウェア更新方法は、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを負荷記憶手段に記憶し、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けてパッチ記憶手段に記憶し、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当て、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行する。
【００１７】
本発明のソフトウェア更新プログラムは、コンピュータを、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段として動作させる。
【発明の効果】
【００１８】
本発明には、モジュールが提供するサービスに対して、モジュールのソフトウェアの更新が与える影響を低減すると言う効果がある。
【図面の簡単な説明】
【００１９】
【図１】第１の実施形態の構成を表すブロック図である。
【図２】第１の実施形態のモジュールの例であるコントローラ部を含む、ディスクアレイ装置の構成の例を表すブロック図である。
【図３】第１の実施形態の動作を表すフローチャートである。
【図４】パッチ記憶部１２が記憶する更新の所要時間の例を表す図である。
【図５】負荷記憶部１１が記憶する負荷推移データの例を表す図である。
【図６】第２の実施形態の構成を表すブロック図である。
【図７】第２の実施形態のコントローラ部の構成の例を表すブロック図である。
【図８】第２の実施形態の更新実行予定割り当て時の動作を表すフローチャートである。
【図９】パッチ記憶部１２が記憶する更新の所要時間の第２の例を表す図である。
【図１０】負荷記憶部１１が記憶する負荷推移データの第２の例を表す図である。
【図１１】アップデート見積もり部による実行予定の割り当ての結果の例を表す図である。
【図１２】第２の実施形態の更新実行時の動作を表すフローチャートである。
【発明を実施するための形態】
【００２０】
次に、本発明の実施形態について、図面を参照して詳細に説明する。
【００２１】
以下で説明する本発明の各実施形態は、ハードウェア、コンピュータとコンピュータを制御するプログラム、あるいは、ハードウェアと、コンピュータとコンピュータを制御するプログラムとの組み合わせにより実現することができる。
【００２２】
図１は、本発明の第１の実施形態の構成を表すブロック図である。
【００２３】
図１を参照すると、本実施形態のソフトウェア更新装置１Ａは、負荷記憶部１１と、パッチ記憶部１２と、アップデート見積もり部１３と、アップデート実行部１４を含む。アップデート実行部１４には、モジュール２１Ａ及びモジュール２２Ａが接続されている。なお、アップデート実行部１４に接続されているモジュールの数は、図１に記載した例では２個であるが、２個に限らない。
【００２４】
負荷記憶部１１は、サービスを提供することによる各モジュールの負荷の合計の予測値を、時刻に対応付けた負荷推移データを記憶する。負荷の合計の予測値は、例えば、過去に測定した各モジュールの負荷の時系列データから算出した、負荷の合計値の同一時刻における平均値や中間値であればよい。負荷推移データは、負荷の合計値の同一時刻における平均値や中間値を、その時刻に対応付けたデータであればよい。
【００２５】
パッチ記憶部１２は、各モジュールを制御するソフトウェアに対する更新データと、その更新データを、各モジュールを制御するソフトウェアに適用するために要する所要時間を、対応付けて記憶する。以下の説明では、更新データをソフトウェアに適用することを、更新を実行すると表記する。
【００２６】
アップデート見積もり手段１３は、パッチ記憶部１２から所要時間を読み出す。アップデート見積もり手段１３は、読み出した所要時間以上継続して、負荷の合計の予測値が所定の閾値を下回る時間帯を、負荷記憶部１１が記憶する負荷推移データから抽出する。アップデート見積もり手段１３は、抽出した時間帯に、読み出した所要時間に対応する、ソフトウェアの更新の実行予定を割り当てる。
【００２７】
アップデート実行手段１４は、アップデート見積もり手段１３が割り当てた実行予定におけるソフトウェアの更新の実行開始時刻になると、ソフトウェアの更新の対象となるモジュールによるサービスの提供を停止させる。アップデート実行手段１４は、モジュールにサービスの提供を停止させた後、そのモジュールのソフトウェアに対して更新を実行する。
【００２８】
各モジュールは、各モジュールに接続されている、例えば計算装置や端末装置などに対して、何らかのサービスを提供する。各モジュールは、ソフトウェアにより制御される。各モジュールは、例えば、ＲＡＩＤに代表されるディスクアレイ装置の、ソフトウェアにより制御されるコントローラ部である。各モジュールは、コンピュータクラスタにおけるコンピュータや、コンピュータのネットワークインターフェースのコントローラであってもよい。本発明の各実施形態では、モジュールがディスクアレイ装置のＩ／Ｏを制御するコントローラ部である場合の説明を行う。
【００２９】
図２は、各モジュールが、ディスクアレイ装置のコントローラ部である場合の、ディスクアレイ装置２Ａの構成を表すブロック図である。
【００３０】
ディスクアレイ装置２Ａは、前述のモジュールであるコントローラ部２１及びコントローラ部２２と、ディスクアレイ２３を含む。ディスクアレイ２３は、ディスク２３１、ディスク２３２、…、ディスク２３Ｎを含む。
【００３１】
コントローラ部２１及びコントローラ部２２は、それぞれ、業務ホスト３Ａ及び業務ホスト３Ｂの両方に接続されている。コントローラ部２１及びコントローラ部２２は、業務ホスト３Ａ及び業務ホスト３Ｂに対して、ディスクアレイ装置に記録されているデータの読み書きのサービスを提供している。図２の例では、コントローラ部２１及びコントローラ部２２は冗長構成になっており、どちらか一方が停止しても、他方が動作することにより、業務ホスト３Ａ及び業務ホスト３Ｂに対するサービスの提供を継続することができる。
【００３２】
次に、本実施形態の動作について、図面を参照して詳細に説明する。
【００３３】
図３は本実施形態のソフトウェア更新装置１Ａの動作を表すフローチャートである。
【００３４】
ソフトウェア更新装置１Ａは、例えば、所定の時間毎にモジュールのソフトウェアに対して適用すべき更新データの有無を調べ、適用すべき更新データが存在する場合、図３の動作を開始すればよい。ソフトウェア更新装置１Ａは、例えば、図示しない管理ホストからの指示により、図３の動作を開始してもよい。どちらの場合も、例えば図示しない管理ホストが、パッチ記憶部１２に適用すべき更新データを格納し、適用すべき更新データを特定する情報をソフトウェア更新装置１Ａに送信しておけばよい。
【００３５】
図３を参照すると、まず、アップデート見積もり部１３が、パッチ記憶部１２から、モジュールのソフトウェアの更新データに対応付けられた、ソフトウェアの更新を実行するために要する所要時間を読み出す（ステップＳ１１）。
【００３６】
パッチ記憶部１２は、所要時間を、例えばテーブルの形で記憶しておけばよい。
【００３７】
図４は、パッチ記憶部１２が記憶する、所要時間の例である。図４の例では、所要時間に更新データ名が対応付けられている。
【００３８】
更新データ及び所要時間を、例えば図示しない管理ホストが、パッチ記憶部１２に予め記憶させておけばよい。更新データは、複数の更新データを一つにまとめたパッチセットであってもよい。更新データがパッチセットである場合、所要時間は、パッチセットに含まれる全ての更新データをソフトウェアに適用するために要する時間である。パッチ記憶部１２は、パッチセットに対応する所要時間を記憶しておけばよい。また、アップデート見積もり部１３が、パッチセットに含まれる個々の更新データに対応する所要時間をパッチ記憶部１２から読み出し、例えば所要時間の中で最長の所要時間をパッチセットの所要時間にするなど、既存の方法でパッチセットの所要時間を算出してもよい。
【００３９】
次に、アップデート見積もり部１３が、ソフトウェアの更新の所要時間以上継続して、負荷の合計が閾値を下回る時間帯を、負荷記憶部１１が記憶する負荷推移データから抽出する（ステップＳ１２）。
【００４０】
負荷記憶部１１は、負荷推移データを、例えばテーブルの形で記憶しておけばよい。
【００４１】
図５は、負荷推移データの例を表す図である。図５の例では、負荷推移データは、１０秒間隔の負荷の合計値である。
【００４２】
負荷推移データは、時刻に対応付けられた、例えば所定の時間間隔の、例えばＩＯＰＳで表した各モジュールの負荷の合計値である。負荷の大きさを表す値は、既存の任意の値であってよい。なお、ＩＯＰＳは、１秒当たりのＩ／Ｏ数である。
【００４３】
負荷推移データの時間間隔は任意であり、１秒であっても、１０秒であっても、１分であっても、それ以外の時間であってもよい。また、負荷記憶部１１が記憶する負荷推移データの量は任意であり、１日分であっても、１ヶ月分であっても、１年分であっても、それ以外の量であってもよい。負荷推移データが含む負荷の合計値は、同一時刻に計測した各モジュールの負荷を合計した値の、例えば平均や中央値などの統計量であればよい。
【００４４】
負荷の合計値に対する閾値は、ソフトウェアの更新の対象となるモジュール以外のモジュールだけで全ての負荷を負担しても、提供するサービスに遅延などの悪影響が及ばないような負荷の合計値を、適宜選択した値であればよい。閾値は、計算上提供するサービスに遅延などの影響が及ばないような負荷の合計値から、安全を考えたマージン分を引いた値であってもよい。
【００４５】
アップデート見積もり部１３は、次に、読み出した所要時間に対応する更新データをソフトウェアに対して適用するソフトウェアの更新の実行予定を、抽出した時間帯に割り当てる（ステップＳ１３）。
【００４６】
なお、複数のモジュールのソフトウェアに対して同一の更新を適用する場合、更新を適用していないモジュールが無くなるまで、ステップＳ１２及びステップＳ１３の処理を繰り返せばよい。また、適用すべき更新データが複数存在する場合、更新の実行予定を割り当てていない更新データが無くなるまで、ステップＳ１２及びステップＳ１３の処理を繰り返せばよい。
【００４７】
アップデート見積もり部１３が割り当てた更新予定における、更新の開始時刻になるまで、アップデート実行部１４は何も行わない（ステップＳ１４、Ｎ）。
【００４８】
アップデート見積もり部１３が割り当てた更新予定における、更新の開始時刻になると（ステップＳ１４、Ｙ）、アップデート実行部１４は、ソフトウェアの更新の対象となるモジュールに、サービスの提供を中止させる（ステップＳ１５）。
【００４９】
なお、アップデート実行部１４は、ソフトウェアの更新の対象となるモジュールにサービスの提供を中止させる前に、ソフトウェアの更新の対象となるモジュール以外に正常動作しているモジュールが存在するか確認してもよい。そして、ソフトウェアの更新の対象となるモジュール以外に正常動作しているモジュールが存在しない場合、アップデート実行部１４は、ソフトウェアの更新の対象となるモジュールにサービスの提供を継続させてもよい。この場合、ソフトウェア更新装置１Ａはソフトウェアの更新を中止すればよい。また、ソフトウェアの更新の対象となるモジュール以外に正常動作しているモジュールが存在する場合、アップデート実行部１４は、ソフトウェアの更新の対象となるモジュールにサービスの提供を中止させればよい。
【００５０】
各モジュールがディスクアレイ装置のコントローラ部である場合、アップデート実行部１４は、データの転送において、ソフトウェアの更新の対象となるコントローラ部を経由しないよう、データ転送のパスを変更するのに必要な処理を適宜行えばよい。各パスは、各コントローラ部と各業務ホストとの間の、データ転送のための接続である。
【００５１】
次に、アップデート実行部１４は、パッチ記憶部１２から更新データを読み出し、ソフトウェアの更新の対象となるモジュールのソフトウェアに対して、読み出した更新データを適用してソフトウェアの更新を行う（ステップＳ１６）。
【００５２】
アップデート実行部１４は、ソフトウェアの更新を終了すると、ソフトウェアの更新の対象であったモジュールに、サービスの提供を再開させる（ステップＳ１７）。
【００５３】
各モジュールがディスクアレイ装置のコントローラ部である場合、アップデート実行部１４は、ソフトウェアの更新の対象であったコントローラ部を適宜経由してデータの転送が行われるよう、データ転送のパスを変更するのに必要な処理を適宜行えばよい。
【００５４】
次に、本実施形態の効果について説明する。
【００５５】
本実施形態には、モジュールが提供するサービスに対して、モジュールのソフトウェアの更新が与える影響を低減すると言う効果がある。
【００５６】
その理由は、ソフトウェアの更新の所要時間以上継続して、負荷の合計が閾値を下回る時間帯を、負荷記憶部１１が記憶する負荷推移データから抽出し、ソフトウェアの更新の実行予定を割り当てるからである。負荷の合計に対する閾値は、ソフトウェアの更新の対象となるモジュール以外のモジュールで全ての負荷を負担しても、各モジュールが提供するサービスに遅延などの影響が及ばないように選択した値である。従って、本実施形態のソフトウェア更新装置１Ａは、アップデート実行部１４がソフトウェアの更新を行っている間における、各モジュールが提供するサービスに対する遅延などの影響を軽減することができる。
【００５７】
以上では、複数のモジュールが冗長な構成で存在するとして説明を行った。しかし、モジュールは、冗長な構成でなくてもよく、複数でなくてもよい。その場合、負荷記憶部１１は、モジュール毎の負荷を時刻に対応付けて記憶しておけばよい。また、アップデート見積もり部１３は、長さがソフトウェアの更新の所要時間以上であり、ソフトウェアの更新の対象となるモジュールの負荷が所定の閾値を下回る時間帯を抽出する。さらに、アップデート実行部１４がソフトウェアの更新を行う間、モジュールはサービスの提供を停止する。しかし、アップデート見積もり部１３が、ソフトウェアの更新の対象となるモジュールの負荷が所定の閾値を下回る時間帯を抽出するので、モジュールが提供するサービスに対して、モジュールのソフトウェアの更新が与える影響を低減することができる。
【００５８】
次に、本発明の第２の実施形態について、図面を参照して詳細に説明する。
【００５９】
図６は、本実施形態の構成を表すブロック図である。
【００６０】
図６を参照すると、本実施形態は、ソフトウェア更新装置１と、ディスクアレイ装置２と、業務ホスト３Ａ及び業務ホスト３Ｂと、管理ホスト４を含む。図６では、ソフトウェア更新装置１とディスクアレイ装置２は、別の装置であるが、ディスクアレイ装置２がソフトウェア更新装置１を含んでいても構わない。
【００６１】
ソフトウェア更新装置１は、図１に示すソフトウェア更新装置１Ａの構成に加えて、閾値記憶部１５を含む。また、ソフトウェア更新装置１は、負荷監視部１６を含んでいてもよい。なお、本実施形態では、ソフトウェアの更新の対象であるモジュールは、ディスクアレイ装置２の各コントローラ部である。
【００６２】
アップデート実行部１４は、アップデート見積もり手段１３が割り当てた実行予定におけるソフトウェアの更新の実行開始時刻になると、ソフトウェアの更新の対象となるコントローラ部を経由しないよう、データ転送のパスを切り替える指示を出力する。この指示の出力先は、後述のディスクアレイ装置２のパス切り替え部２５である。アップデート実行手段１４は、パスを切り替える指示を出力した後、そのコントローラ部のソフトウェアに対して更新を実行する。
【００６３】
閾値記憶部１５は、負荷の合計値に対する閾値を、時刻に対応させて記憶する。閾値記憶部１５が記憶する閾値は、時刻によって異なる値であってよい。例えば管理ホスト４が、時刻に対応付けた閾値を、予め閾値記憶部１５に記憶させておけばよい。
【００６４】
負荷監視部１６は、例えば所定の時間毎に、各コントローラの負荷を計測する。負荷監視部１６は、過去の所定の期間内における同一時刻の負荷の計測値から、例えば平均などの統計値を算出し、時刻毎の負荷の合計の予測値を算出してもよい。負荷監視部１６は、算出した予測値を、随時負荷記憶部１１に記憶させればよい。負荷監視部１６は、過去の所定の期間内における同一時刻の負荷の計測値から、ディスクアレイ装置２からの応答に遅延を発生させずに、コントローラ部を利用不可にできるか否かを判定するための閾値を算出してもよい。この場合の算出方法は、既存の任意の方法でよい。負荷監視部１６は、算出した閾値を、随時閾値算出部１２に記憶させればよい。
【００６５】
本実施形態のソフトウェア更新装置１の他の構成要素は、第１の実施形態の同一の記号を付した構成要素と同じであるので、説明を省略する。
【００６６】
ディスクアレイ装置２は、コントローラ部２１及びコントローラ部２２と、ディスクアレイ２３と、パス状態登録部２４と、パス切り替え部２５を含む。
【００６７】
ディスクアレイ装置２のコントローラ部２１及びコントローラ部２２は、それぞれ各業務ホストに接続されている。各コントローラは、各業務ホストと通信可能である。各コントローラと、各業務ホストとの間は、例えばＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）のネットワークで接続されている。
【００６８】
コントローラ部２１及びコントローラ部２２は、ディスクアレイ２３に対するデータの読み書きや転送を制御する。コントローラ部２１及びコントローラ部２２は冗長構成になっている。また、コントローラ部は３個以上存在していてもよい。各コントローラ部はソフトウェアにより制御される。
【００６９】
図７は、コントローラ部２１を制御するソフトウェアの構成の例を表す図である。他のコントローラ部の構成も、図７の構成と同じである。なお、コントローラ部の構成は図７の構成に限らない。
【００７０】
図７を参照すると、コントローラ部２１は、実行環境２１１で動作するソフトウェアにより制御される。図７の例では、実行環境２１１のソフトウェアには、管理ＳＷ（Ｓｏｆｔｗａｒｅ）と、ＲＡＩＤ制御（ＲＡＩＤ制御ドライバ）と、ＯＳ（Ｏｐｅｒａｔｉｏｎｇ Ｓｙｓｔｅｍ）の３種類の種別が存在する。バックアップ環境２１２は、実行環境２１１のコピーである。
【００７１】
ディスクアレイ２３は、各業務ホストが各コントローラ部を介して読み書きするデータを記憶する。
【００７２】
パス状態登録部２４は、各コントローラと各業務ホストとの間のパスが、有効であるか否かを表すパス状態を記憶する。また、パス状態登録部２４は、後述の各業務ホストのパス管理部３１からパス状態を受信し、記憶しているパス状態を変更する。
【００７３】
パス切り替え部２５は、アップデート実行部１４からの指示に基づき、各コントローラ部を各業務ホストから利用できない状態に変更する。また、パス切り替え部２５は、アップデート実行部１４からの指示に基づき、各コントローラ部を各業務ホストから利用できる状態に変更する。
【００７４】
図６には、業務ホスト３Ａ及び業務ホスト３Ｂの２台の業務ホストが記載されているが、業務ホストは２台でなくてもよい。各業務ホストは、パス管理部３１を含む。各業務ホストは各コントローラに同時に接続され、各コントローラ部を介して、ディスクアレイ２３が記憶するデータの読み書きを行う。
【００７５】
パス管理部３１は、各コントローラ部との間のパスが利用可能であるか否かを監視する。パス管理部３１は、例えば、各コントローラ部に対するＩ／Ｏエラーの発生の有無を定期的に確認することで、監視を行えばよい。パス管理部３１は、利用不可であるコントローラ部が存在すれば、業務ホストとそのコントローラ部との間のパスの利用を禁止する。また、パス管理部３１は、利用不可であったコントローラ部が利用可能になれば、業務ホストとそのコントローラ部との間のパスの利用を許可する。
【００７６】
例えば、図６のようにディスクアレイ装置２と業務ホスト３Ａが接続されており、各コントローラが正常動作していれば、コントローラ部２１と業務ホスト３Ａの間、及び、コントローラ部２２と業務ホスト３Ａの間の２つのパスが利用できる。この状態から、パス切り替え部２５が、例えばコントローラ部２１を利用不可にした場合、パス管理部３１はコントローラ部２１に対するＩ／Ｏエラーの発生を検出し、コントローラ部２１との間のパスを利用不可にする。このようにして、２本のパスが利用可能な状態から１本のパスだけが可能な状態にパスの状態が切り替わる、いわゆる片寄せが行われる。
【００７７】
また、各装置が図６のような構成であり、パス切り替え部２５が、コントローラ部２１を、利用不可な状態から利用可能な状態に切り替えた場合、パス管理部３１はコントローラ部２１に対するＩ／Ｏエラーが発生しないことを検出する。Ｉ／Ｏエラーが発生しないことを検出したパス管理部３１は、コントローラ部２１との間のパスを利用可能にする。
【００７８】
パス管理部３１は、業務ホストとストレージ装置２との間のいずれかのパスを介して、監視の結果得られた各パスの状態を、ストレージ装置２のパス状態登録部２４に記憶させる。
【００７９】
なお、以上で説明したパスの切り替えは単なる例である。ディスクアレイ装置２及び各業務ホストは、既存の任意の方法でパスの切り替えを行うことができる。
【００８０】
管理ホスト４は、アップデート指示部４１を含む。
【００８１】
アップデート指示部４１は、パッチ記憶部１２に更新データ及び所要時間を記憶させる。アップデート指示部４１は、アップデート見積もり部１３に対して、ソフトウェアの更新の実行予定を割り当てる指示を送信してもよい。
【００８２】
次に、本実施形態のソフトウェア更新装置１の動作について、図面を参照して詳細に説明する。
【００８３】
図８は、本実施形態のソフトウェア更新装置１の、更新の実行予定を割り当てる動作を表すフローチャートである。ソフトウェア更新装置１は、例えば、アップデート指示部４１から適用すべき更新データを特定する情報を受け取り、以下の動作を開始する。
【００８４】
図８を参照すると、まず、アップデート見積もり部１３が、各コントローラ部のソフトウェアに適用する更新データに対応付けられた更新の所要時間を、パッチ記憶部１２から読み出す（ステップＳ２１）。
【００８５】
パッチ記憶部１２は、所要時間を、対応する更新データに関する情報に関連付けて、例えばテーブルの形で記憶することもできる。
【００８６】
図９は、パッチ記憶部１２が記憶する、所要時間と、対応する更新データに関する情報を含むテーブルの例である。図９のテーブルは、更新の対象となるソフトウェアの種別と、更新の対象となるモジュール名と、更新後の再起動の要否を含む再起動種別と、所要時間と、更新時におけるパスの切替要否を含む。
【００８７】
種別は、パッチを適用する対象となる制御ソフトの種別を表す。種別には、例えば、前述の、管理ソフトウェア、ＲＡＩＤ制御ドライバ、ＯＳなどがある。ソフトウェアモジュール名は、ソフトウェを構成するソフトウェアモジュールを識別する名前である。再起動種別は、更新の実行後に再起動が不要であるか、再起動が必要な場合は再起動後に高速再起動が可能であるか否かを表す。なお、高速再起動は、例えばＰＯＳＴ（Ｐｏｗｅｒ Ｏｎ Ｓｅｌｆ Ｔｅｓｔ）を実行しない再起動である。再起動種別が「無し」の場合、更新の実行後の再起動は不要である。再起動種別が「高速」の場合、パッチ適用後に再起動が必要だが高速再起動が可能である。再起動種別が「通常」の場合、パッチ適用後に通常の再起動が必要である。
【００８８】
所要時間は、更新を開始してからコントローラ部が再び動作可能になるまでに必要な時間である。所要時間は、適宜見積もった必要な時間の概算で構わない。図９の例では、再起動種別が「無し」の場合、所要時間は０秒である。再起動種別が「高速」の場合、所要時間は１０秒である。再起動種別が「通常」の場合、所要時間は６００秒〜７００秒である。
【００８９】
切替要否は、更新の実行時に、パス切り替えが必要になるかどうかを表す。切り替え要否は、例えば、所要時間が所定の閾値以上であるか閾値未満であるかにより、予め決めておけばよい。各業務ホストから利用可能であったコントローラ部が、継続して利用できなくなった場合、利用できなくなってから各業務ホストで行われている処理に影響を及ぼすと考えられる時間を、予めこの閾値に設定しておけばよい。図７の切替要否は、閾値が１０以上６００未満の場合の例である。
【００９０】
なお、パッチ記憶部１２は、各更新データに対応した切替要否を記憶しておく必要はない。パッチ記憶部１２が切替要否を記憶していない場合、後述のステップＳ２２において、アップデート見積もり部１３が、所要時間と閾値を比較することで、パスの切替要否を判定すればよい。また、後述のステップＳ３２において、パッチ実行部１４は、アップデート見積もり部１３によるパスの切替要否を判定結果をそのまま利用すればよい。あるいは、パッチ実行部１４が、所要時間と閾値を比較することで、パスの切替要否を判定してもよい。
【００９１】
パッチ記憶部１２は、個別の更新データの所要時間やその更新データに関する情報だけでなく、複数の更新データをまとめたパッチセットの所要時間などの情報を、パッチセットに関連付けて記憶していてもよい。
【００９２】
アップデート見積もり部１３は、次に、更新データを適用する際のパスの切替要否を判定する（ステップＳ２２）。
【００９３】
単体の更新データを適用する場合、アップデート見積もり部１３は、パッチ記憶部１２から読み出した、適用する更新データの切替要否のデータに基づき、パスの切替要否を判定すればよい。ソフトウェアに対してパッチセットを適用する場合、パッチ記憶部１２がそのパッチセットのパス切替要否のデータを記憶していれば、アップデート見積もり部１３は、そのデータに基づきパスの切替要否を判定すればよい。パッチ記憶部１２がそのパッチセットのパス切替要否のデータを記憶していない場合、アップデート見積もり部１３は、そのパッチセットが、パス切替が必要な更新データを含んでいれば、パス切替が必要と判定すればよい。
【００９４】
パス切替が不要である場合（ステップＳ２３、Ｎ）、アップデート実行部１４はすぐに更新を実行すればよい（ステップＳ２７）。更新の実行については後述する。
【００９５】
パス切替が必要である場合（ステップＳ２３、Ｙ）、アップデート見積もり部１３は、更新の所要時間以上継続して、負荷の合計値が閾値を下回る時間帯を、負荷記憶部１１が記憶する負荷推移データから抽出する（ステップＳ２４）。
【００９６】
アップデート見積もり部１３は、更新の所要時間を、パッチ記憶部１２から読み出せばよい。
【００９７】
図１０は、負荷記憶部１１が記憶する負荷推移データの例を表す図である。負荷推移データは、少なくとも負荷の合計値の推移を含んでいればよい。負荷記憶部１１が記憶する負荷の値は、例えばＩＯＰＳである。
【００９８】
また、アップデート見積もり部１３は、負荷の合計値に対する閾値を、閾値記憶部１５から読み出せばよい。前述のように、閾値記憶部１５が記憶する閾値は、時刻によって変動してもよい。この場合、例えばディスクアレイ装置２の管理者が、時刻に応じて適宜定めた閾値を、予め閾値記憶部１５に記憶させておけばよい。閾値記憶部１５が記憶する閾値は、過去の同時刻において、例えば負荷監視部１６が観測した、負荷の値のばらつきの大きさに応じた値であってもよい。閾値記憶部１５が記憶する閾値は、例えば、計算上提供するサービスに遅延などの影響が及ばないような負荷の合計値から、各時刻における負荷の観測値のばらつきの大きさに応じた値を引いた値であってもよい。この場合、負荷の観測値のばらつきが大きい時刻の閾値は小さく、負荷の観測値のばらつきが小さい時刻の閾値は大きくなる。
【００９９】
図１１は、アップデート見積もり部１３が抽出した時間帯を表す図である。アップデート見積もり部１３は、図１１のようなテーブルを生成して、時間帯の抽出を行うことができる。図１１の「負荷の閾値」は、閾値記憶部１５が記憶する閾値である。「負荷の予測値」は、負荷記憶部１１が記憶する負荷の合計値である。アップデート見積もり部１３は、「負荷の閾値」より「負荷の予測値」が小さく、「差分」が正である時間帯を抽出する。図１１でアップデート見積もり部１３が抽出した時間帯は、実行可否が「ＯＫ」である時間帯である。
【０１００】
条件に適合する時間帯が存在しない場合（ステップＳ２５、Ｎ）、ソフトウェア更新装置１は、更新の実行や更新の実行予定の割り当てを行わずに、処理を終了する。この場合は、例えばディスクアレイ装置２の管理者が手動で更新を実行するなどすればよい。
【０１０１】
条件に適合する時間帯が存在する場合（ステップＳ２５、Ｙ）、その時間帯が現在であり即時更新を実行することが可能であれば（ステップＳ２６、Ｙ）、アップデート実行部１４は更新を実行する（ステップＳ２７）。
【０１０２】
条件に適合する時間帯が現在ではなく、即時更新を実行できない場合（ステップＳ２６、Ｎ）、アップデート見積もり部１３は、更新の実行予定を割り当てる（ステップＳ２８）。この場合、更新の実行予定時刻に、アップデート実行部１４が、以下で述べるように更新を実行すればよい。
【０１０３】
次に、更新実行時の本実施形態の動作について説明する。
【０１０４】
図１２は、更新実行時の本実施形態の動作を表すフローチャートである。なお、ソフトウェア更新装置１は、負荷監視部１６が測定した更新の実行予定時刻における負荷の合計値が、閾値記憶部１５が記憶する同時刻における閾値より大きい場合、更新の実行を中止してもよい。その場合、ソフトウェア更新装置１は、前述の更新の実行予定の割り当てを再び行えばよい。
【０１０５】
図１２を参照すると、アップデート実行部１４が、更新データ、及び、所要時間等の、その更新データに対応する情報を含むパッチ情報を、パッチ記憶部１２から読み出す（ステップＳ３１）。
【０１０６】
アップデート実行部１４は、次に、例えば読み出したパッチ情報から、更新の実行時におけるパスの切替の要否を判別する（ステップＳ３２）。アップデート実行部１４は、更新を実行する際のパスの切替の要否を、アップデート見積もり部１３から受け取ってもよい。
【０１０７】
パスの切替が必要ない場合（ステップＳ３３、Ｎ）、アップデート実行部１４は、更新を実行する（ステップＳ３８）。
【０１０８】
パスの切替が必要である場合（ステップＳ３３、Ｙ）、アップデート実行部１４は、ディスクアレイ装置２と全ての業務ホストとの間のパスが正常であるか確認する（ステップＳ３４）。ステップＳ３４において、アップデート実行部１４は、ソフトウェアの更新の対象となるコントローラ部を停止させた場合、全ての業務ホストとの間に正常なパスが存在するか否かを確認すればよい。アップデート実行部１４は、各コントローラ部と各業務ホストとの間の、全てのパスが正常であるか確認してもよい。
【０１０９】
アップデート実行部１４は、ステップＳ３４の確認を、例えば、ストレージ装置２のパス状態登録部２４から各パスの状態を受け取ることで行えばよい。
【０１１０】
パスが正常でない業務ホストが存在する場合（ステップＳ３４、Ｎ）、ソフトウェア更新装置１は処理を終了する。
【０１１１】
パスが正常でない業務ホストが存在しない場合（ステップＳ３４、Ｙ）、アップデート実行部１４は、パス切り替え部２５に指示を送信してパスの切り替えを行う（ステップＳ３５）。アップデート実行部１４からパスの切り替えの指示を受信したパス切り替え部２５は、ソフトウェアの更新の対象であるコントローラ部と各業務ホストとの間の全てのパスを、利用不可にすればよい。
【０１１２】
アップデート実行部１４は、パスの切替を行った後、更新を実行する（ステップＳ３６）。
【０１１３】
アップデート実行部１４は、更新の実行後、パス切り替え部２５に指示を送信して、パスの復旧を行う（ステップＳ３７）。アップデート実行部１４からパスの復旧の指示を受信したパス切り替え部２５は、ソフトウェアの更新を行ったコントローラ部と各業務ホストとの間の全てのパスを、再び利用可能にすればよい。
【０１１４】
以上で説明した本実施形態には、第１の実施形態の効果に加えて、同一時刻の負荷の大きさにばらつきがある場合でも、コントローラ部が提供するサービスに対して、コントローラ部のソフトウェアの更新が与える影響を低減すると言う効果がある。
【０１１５】
その理由は、更新の実行予定を割り当てる際、アップデート見積もり部１３が、時刻に応じて値が変動する閾値と、負荷の合計値を比較するからである。例えば、負荷の大きさのばらつきが大きい時刻の閾値を小さく、負荷の大きさのばらつきが小さい時刻の閾値を大きくしておくことで、負荷の予測値は小さいが大きな負荷の変動が起こりうる時間帯の更新を実行することを避けることができる。このことにより、例えば、更新の実行中に急に負荷が増大することで発生する遅延のような、コントローラ部のソフトウェアの更新による影響の発生を減少させることができる。
【０１１６】
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解しうる様々な変更をすることができる。
【符号の説明】
【０１１７】
１、１Ａ ソフトウェア更新装置
２、２Ａ ディスクアレイ装置
３Ａ、３Ｂ 業務ホスト
４ 管理ホスト
１１ 負荷記憶部
１２ パッチ記憶部
１３ アップデート見積もり部
１４ アップデート実行部
１５ 閾値記憶部
１６ 負荷監視部
２１、２２ コントローラ部
２１Ａ、２２Ａ モジュール
２３ ディスクアレイ
２４ パス状態登録部
２５ パス切り替え部
３１ パス管理部
４１ アップデート指示部
２１１ 実行環境
２１２ バックアップ環境
【特許請求の範囲】
【請求項１】
モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、
前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、
前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、
前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段と
を含むソフトウェア更新装置。
【請求項２】
前記負荷記憶手段は、冗長構成をとり、各々が前記ソフトウェアを備える複数のモジュール各々の負荷の合計の予測値を時刻に対応付けた前記負荷推移データを記憶し、
前記アップデート見積もり手段は、少なくとも１個の正常動作中のモジュールを除く前記複数のモジュールから、モジュールを選択し、選択した前記モジュールに対して前記実行予定を割り当てる
請求項１に記載のソフトウェア更新装置。
【請求項３】
時刻に応じた前記閾値を前記時刻に対応付けて記憶する負荷閾値記憶手段を含み、
前記アップデート見積もり手段は、同一の時刻に対応する、負荷の前記合計値と、前記負荷閾値記憶手段から読み出した前記閾値を比較し、負荷の前記合計値が前記閾値を下回る時間帯を抽出する
請求項１又は２に記載のソフトウェア更新装置。
【請求項４】
前記モジュールと、請求項１乃至３のいずれかに記載のソフトウェア更新装置を含む情報処理システム。
【請求項５】
モジュールの負荷の予測値を時刻に対応付けた負荷推移データを負荷記憶手段に記憶し、
前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けてパッチ記憶手段に記憶し、
前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当て、
前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行する
ソフトウェア更新方法。
【請求項６】
冗長構成をとり、各々が前記ソフトウェアを備える複数のモジュール各々の負荷の合計の予測値を時刻に対応付けた前記負荷推移データを前記負荷記憶手段に記憶し、
少なくとも１個の正常動作中のモジュールを除く前記複数のモジュールから、モジュールを選択し、選択した前記モジュールに対して前記実行予定を割り当てる
請求項５に記載のソフトウェア更新方法。
【請求項７】
時刻に応じた前記閾値を前記時刻に対応付けて負荷閾値記憶手段に記憶し、
同一の時刻に対応する、負荷の前記合計値と、前記負荷閾値記憶手段から読み出した前記閾値を比較し、負荷の前記合計値が前記閾値を下回る時間帯を抽出する
請求項５又は６に記載のソフトウェア更新方法。
【請求項８】
コンピュータを、
モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、
前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、
前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、
前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段と
して動作させるソフトウェア更新プログラム。
【請求項９】
コンピュータを、
冗長構成をとり、各々が前記ソフトウェアを備える複数のモジュール各々の負荷の合計の予測値を時刻に対応付けた前記負荷推移データを記憶する前記負荷記憶手段と、
少なくとも１個の正常動作中のモジュールを除く前記複数のモジュールから、モジュールを選択し、選択した前記モジュールに対して前記実行予定を割り当てる前記アップデート見積もり手段と
して動作させる請求項８に記載のソフトウェア更新プログラム。
【請求項１０】
コンピュータを、
時刻に応じた前記閾値を前記時刻に対応付けて記憶する負荷閾値記憶手段と、
同一の時刻に対応する、負荷の前記合計値と、前記負荷閾値記憶手段から読み出した前記閾値を比較し、負荷の前記合計値が前記閾値を下回る時間帯を抽出する前記アップデート見積もり手段と
して動作させる請求項８又は９に記載のソフトウェア更新プログラム。
【請求項１】
モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、
前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、
前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、
前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段と
を含むソフトウェア更新装置。
【請求項２】
前記負荷記憶手段は、冗長構成をとり、各々が前記ソフトウェアを備える複数のモジュール各々の負荷の合計の予測値を時刻に対応付けた前記負荷推移データを記憶し、
前記アップデート見積もり手段は、少なくとも１個の正常動作中のモジュールを除く前記複数のモジュールから、モジュールを選択し、選択した前記モジュールに対して前記実行予定を割り当てる
請求項１に記載のソフトウェア更新装置。
【請求項３】
時刻に応じた前記閾値を前記時刻に対応付けて記憶する負荷閾値記憶手段を含み、
前記アップデート見積もり手段は、同一の時刻に対応する、負荷の前記合計値と、前記負荷閾値記憶手段から読み出した前記閾値を比較し、負荷の前記合計値が前記閾値を下回る時間帯を抽出する
請求項１又は２に記載のソフトウェア更新装置。
【請求項４】
前記モジュールと、請求項１乃至３のいずれかに記載のソフトウェア更新装置を含む情報処理システム。
【請求項５】
モジュールの負荷の予測値を時刻に対応付けた負荷推移データを負荷記憶手段に記憶し、
前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けてパッチ記憶手段に記憶し、
前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当て、
前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行する
ソフトウェア更新方法。
【請求項６】
冗長構成をとり、各々が前記ソフトウェアを備える複数のモジュール各々の負荷の合計の予測値を時刻に対応付けた前記負荷推移データを前記負荷記憶手段に記憶し、
少なくとも１個の正常動作中のモジュールを除く前記複数のモジュールから、モジュールを選択し、選択した前記モジュールに対して前記実行予定を割り当てる
請求項５に記載のソフトウェア更新方法。
【請求項７】
時刻に応じた前記閾値を前記時刻に対応付けて負荷閾値記憶手段に記憶し、
同一の時刻に対応する、負荷の前記合計値と、前記負荷閾値記憶手段から読み出した前記閾値を比較し、負荷の前記合計値が前記閾値を下回る時間帯を抽出する
請求項５又は６に記載のソフトウェア更新方法。
【請求項８】
コンピュータを、
モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、
前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、
前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、
前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段と
して動作させるソフトウェア更新プログラム。
【請求項９】
コンピュータを、
冗長構成をとり、各々が前記ソフトウェアを備える複数のモジュール各々の負荷の合計の予測値を時刻に対応付けた前記負荷推移データを記憶する前記負荷記憶手段と、
少なくとも１個の正常動作中のモジュールを除く前記複数のモジュールから、モジュールを選択し、選択した前記モジュールに対して前記実行予定を割り当てる前記アップデート見積もり手段と
して動作させる請求項８に記載のソフトウェア更新プログラム。
【請求項１０】
コンピュータを、
時刻に応じた前記閾値を前記時刻に対応付けて記憶する負荷閾値記憶手段と、
同一の時刻に対応する、負荷の前記合計値と、前記負荷閾値記憶手段から読み出した前記閾値を比較し、負荷の前記合計値が前記閾値を下回る時間帯を抽出する前記アップデート見積もり手段と
して動作させる請求項８又は９に記載のソフトウェア更新プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−１９４８９２（Ｐ２０１２−１９４８９２Ａ）
【公開日】平成２４年１０月１１日（２０１２．１０．１１）
【国際特許分類】
【出願番号】特願２０１１−５９５５８（Ｐ２０１１−５９５５８）
【出願日】平成２３年３月１７日（２０１１．３．１７）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年１０月１１日（２０１２．１０．１１）
【国際特許分類】
【出願日】平成２３年３月１７日（２０１１．３．１７）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]