モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段とを含むソフトウェア更新装置。前記負荷記憶手段は、冗長構成をとり、各々が前記ソフトウェアを備える複数のモジュール各々の負荷の合計の予測値を時刻に対応付けた前記負荷推移データを記憶し、前記アップデート見積もり手段は、少なくとも1個の正常動作中のモジュールを除く前記複数のモジュールから、モジュールを選択し、選択した前記モジュールに対して前記実行予定を割り当てる請求項1に記載のソフトウェア更新装置。時刻に応じた前記閾値を前記時刻に対応付けて記憶する負荷閾値記憶手段を含み、前記アップデート見積もり手段は、同一の時刻に対応する、負荷の前記合計値と、前記負荷閾値記憶手段から読み出した前記閾値を比較し、負荷の前記合計値が前記閾値を下回る時間帯を抽出する請求項1又は2に記載のソフトウェア更新装置。前記モジュールと、請求項1乃至3のいずれかに記載のソフトウェア更新装置を含む情報処理システム。モジュールの負荷の予測値を時刻に対応付けた負荷推移データを負荷記憶手段に記憶し、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けてパッチ記憶手段に記憶し、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当て、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するソフトウェア更新方法。冗長構成をとり、各々が前記ソフトウェアを備える複数のモジュール各々の負荷の合計の予測値を時刻に対応付けた前記負荷推移データを前記負荷記憶手段に記憶し、少なくとも1個の正常動作中のモジュールを除く前記複数のモジュールから、モジュールを選択し、選択した前記モジュールに対して前記実行予定を割り当てる請求項5に記載のソフトウェア更新方法。時刻に応じた前記閾値を前記時刻に対応付けて負荷閾値記憶手段に記憶し、同一の時刻に対応する、負荷の前記合計値と、前記負荷閾値記憶手段から読み出した前記閾値を比較し、負荷の前記合計値が前記閾値を下回る時間帯を抽出する請求項5又は6に記載のソフトウェア更新方法。コンピュータを、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段として動作させるソフトウェア更新プログラム。コンピュータを、冗長構成をとり、各々が前記ソフトウェアを備える複数のモジュール各々の負荷の合計の予測値を時刻に対応付けた前記負荷推移データを記憶する前記負荷記憶手段と、少なくとも1個の正常動作中のモジュールを除く前記複数のモジュールから、モジュールを選択し、選択した前記モジュールに対して前記実行予定を割り当てる前記アップデート見積もり手段として動作させる請求項8に記載のソフトウェア更新プログラム。コンピュータを、時刻に応じた前記閾値を前記時刻に対応付けて記憶する負荷閾値記憶手段と、同一の時刻に対応する、負荷の前記合計値と、前記負荷閾値記憶手段から読み出した前記閾値を比較し、負荷の前記合計値が前記閾値を下回る時間帯を抽出する前記アップデート見積もり手段として動作させる請求項8又は9に記載のソフトウェア更新プログラム。特許文献1に記載のストレージ装置は、マイクロプログラムの交換の際、各入出力ポートに対するI/Oの負荷の大きさによらず、マイクロプログラムの交換の対象となる入出力ポートに対応する接続パスを休止する。この場合、マイクロプログラムの交換の対象となる入出力ポートが負担しているI/Oの負荷を、他の入出力ポートが分担して負担する。しかし、各入出力ポートのI/Oの負荷の和が、マイクロプログラムの交換の対象となる入出力ポート以外の入出力ポートの処理能力の和を超える場合、ストレージ装置に遅延などの性能低下が生じたり、性能低下が拡大したりすることがある。特許文献2のディスクアレイ装置は、監視部による監視の結果、所定時間連続して記憶装置へのアクセスがない場合や、所定期間内のアクセス頻度が所定値以下の場合に、指定した記憶装置への制御ファームの適用を実行する。しかし、制御ファームの適用開始前の所定時間内において、アクセスが無いかアクセスの頻度が所定値以下であっても、制御ファームの適用開始後に、同様にアクセスが無いかアクセスの頻度が所定値以下であるわけではない。制御ファームの適用開始後にアクセス頻度が増大した場合、ディスクアレイ装置に遅延などの性能低下が生じたり、性能低下が拡大したりすることがある。特許文献3のストレージ装置は、性能への影響を考慮してダウンロードを実施する場合、指定した時刻即座を含むか、I/Oが少ない時にファームウェアの更新を行う。しかし、指定した時刻にI/Oが少ないとは限らない。また、I/Oの多さを計測した時にI/Oが少なくても、ファームウェアの更新開始後に継続してI/Oが少ないとは限らない。ファームウェアの更新開始後にI/Oが増加し、ファームウェアの更新を行っていないコントローラ部やエンクロージャの処理能力を超えた場合、ストレージ装置に遅延などの性能低下が生じたり、性能低下が拡大したりすることがある。本発明の目的は、上記問題を解決するソフトウェア更新装置を提供することにある。本発明のソフトウェア更新装置は、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段とを含む。本発明のソフトウェア更新方法は、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを負荷記憶手段に記憶し、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けてパッチ記憶手段に記憶し、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当て、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行する。本発明のソフトウェア更新プログラムは、コンピュータを、モジュールの負荷の予測値を時刻に対応付けた負荷推移データを記憶する負荷記憶手段と、前記モジュールを制御するソフトウェアに対する更新データと、前記ソフトウェアに前記更新データを適用するための所要時間を、対応付けて記憶するパッチ記憶手段と、前記パッチ記憶手段から読み出した前記所要時間以上継続して、負荷の前記合計値が閾値を下回る時間帯を、前記負荷推移データから抽出し、抽出した前記時間帯に前記ソフトウェアの更新の実行予定を割り当てるアップデート見積もり手段と、前記実行予定に基づき、前記ソフトウェアの更新の対象となる前記モジュールにサービスの提供を停止させ、前記ソフトウェアの更新を実行するアップデート実行手段として動作させる。本発明には、モジュールが提供するサービスに対して、モジュールのソフトウェアの更新が与える影響を低減すると言う効果がある。次に、本発明の実施形態について、図面を参照して詳細に説明する。以下で説明する本発明の各実施形態は、ハードウェア、コンピュータとコンピュータを制御するプログラム、あるいは、ハードウェアと、コンピュータとコンピュータを制御するプログラムとの組み合わせにより実現することができる。図1は、本発明の第1の実施形態の構成を表すブロック図である。図1を参照すると、本実施形態のソフトウェア更新装置1Aは、負荷記憶部11と、パッチ記憶部12と、アップデート見積もり部13と、アップデート実行部14を含む。アップデート実行部14には、モジュール21A及びモジュール22Aが接続されている。なお、アップデート実行部14に接続されているモジュールの数は、図1に記載した例では2個であるが、2個に限らない。負荷記憶部11は、サービスを提供することによる各モジュールの負荷の合計の予測値を、時刻に対応付けた負荷推移データを記憶する。負荷の合計の予測値は、例えば、過去に測定した各モジュールの負荷の時系列データから算出した、負荷の合計値の同一時刻における平均値や中間値であればよい。負荷推移データは、負荷の合計値の同一時刻における平均値や中間値を、その時刻に対応付けたデータであればよい。パッチ記憶部12は、各モジュールを制御するソフトウェアに対する更新データと、その更新データを、各モジュールを制御するソフトウェアに適用するために要する所要時間を、対応付けて記憶する。以下の説明では、更新データをソフトウェアに適用することを、更新を実行すると表記する。アップデート見積もり手段13は、パッチ記憶部12から所要時間を読み出す。アップデート見積もり手段13は、読み出した所要時間以上継続して、負荷の合計の予測値が所定の閾値を下回る時間帯を、負荷記憶部11が記憶する負荷推移データから抽出する。アップデート見積もり手段13は、抽出した時間帯に、読み出した所要時間に対応する、ソフトウェアの更新の実行予定を割り当てる。アップデート実行手段14は、アップデート見積もり手段13が割り当てた実行予定におけるソフトウェアの更新の実行開始時刻になると、ソフトウェアの更新の対象となるモジュールによるサービスの提供を停止させる。アップデート実行手段14は、モジュールにサービスの提供を停止させた後、そのモジュールのソフトウェアに対して更新を実行する。各モジュールは、各モジュールに接続されている、例えば計算装置や端末装置などに対して、何らかのサービスを提供する。各モジュールは、ソフトウェアにより制御される。各モジュールは、例えば、RAIDに代表されるディスクアレイ装置の、ソフトウェアにより制御されるコントローラ部である。各モジュールは、コンピュータクラスタにおけるコンピュータや、コンピュータのネットワークインターフェースのコントローラであってもよい。本発明の各実施形態では、モジュールがディスクアレイ装置のI/Oを制御するコントローラ部である場合の説明を行う。図2は、各モジュールが、ディスクアレイ装置のコントローラ部である場合の、ディスクアレイ装置2Aの構成を表すブロック図である。ディスクアレイ装置2Aは、前述のモジュールであるコントローラ部21及びコントローラ部22と、ディスクアレイ23を含む。ディスクアレイ23は、ディスク231、ディスク232、...、ディスク23Nを含む。コントローラ部21及びコントローラ部22は、それぞれ、業務ホスト3A及び業務ホスト3Bの両方に接続されている。コントローラ部21及びコントローラ部22は、業務ホスト3A及び業務ホスト3Bに対して、ディスクアレイ装置に記録されているデータの読み書きのサービスを提供している。図2の例では、コントローラ部21及びコントローラ部22は冗長構成になっており、どちらか一方が停止しても、他方が動作することにより、業務ホスト3A及び業務ホスト3Bに対するサービスの提供を継続することができる。次に、本実施形態の動作について、図面を参照して詳細に説明する。図3は本実施形態のソフトウェア更新装置1Aの動作を表すフローチャートである。ソフトウェア更新装置1Aは、例えば、所定の時間毎にモジュールのソフトウェアに対して適用すべき更新データの有無を調べ、適用すべき更新データが存在する場合、図3の動作を開始すればよい。ソフトウェア更新装置1Aは、例えば、図示しない管理ホストからの指示により、図3の動作を開始してもよい。どちらの場合も、例えば図示しない管理ホストが、パッチ記憶部12に適用すべき更新データを格納し、適用すべき更新データを特定する情報をソフトウェア更新装置1Aに送信しておけばよい。図3を参照すると、まず、アップデート見積もり部13が、パッチ記憶部12から、モジュールのソフトウェアの更新データに対応付けられた、ソフトウェアの更新を実行するために要する所要時間を読み出すステップS11。パッチ記憶部12は、所要時間を、例えばテーブルの形で記憶しておけばよい。図4は、パッチ記憶部12が記憶する、所要時間の例である。図4の例では、所要時間に更新データ名が対応付けられている。更新データ及び所要時間を、例えば図示しない管理ホストが、パッチ記憶部12に予め記憶させておけばよい。更新データは、複数の更新データを一つにまとめたパッチセットであってもよい。更新データがパッチセットである場合、所要時間は、パッチセットに含まれる全ての更新データをソフトウェアに適用するために要する時間である。パッチ記憶部12は、パッチセットに対応する所要時間を記憶しておけばよい。また、アップデート見積もり部13が、パッチセットに含まれる個々の更新データに対応する所要時間をパッチ記憶部12から読み出し、例えば所要時間の中で最長の所要時間をパッチセットの所要時間にするなど、既存の方法でパッチセットの所要時間を算出してもよい。次に、アップデート見積もり部13が、ソフトウェアの更新の所要時間以上継続して、負荷の合計が閾値を下回る時間帯を、負荷記憶部11が記憶する負荷推移データから抽出するステップS12。負荷記憶部11は、負荷推移データを、例えばテーブルの形で記憶しておけばよい。図5は、負荷推移データの例を表す図である。図5の例では、負荷推移データは、10秒間隔の負荷の合計値である。負荷推移データは、時刻に対応付けられた、例えば所定の時間間隔の、例えばIOPSで表した各モジュールの負荷の合計値である。負荷の大きさを表す値は、既存の任意の値であってよい。なお、IOPSは、1秒当たりのI/O数である。負荷推移データの時間間隔は任意であり、1秒であっても、10秒であっても、1分であっても、それ以外の時間であってもよい。また、負荷記憶部11が記憶する負荷推移データの量は任意であり、1日分であっても、1ヶ月分であっても、1年分であっても、それ以外の量であってもよい。負荷推移データが含む負荷の合計値は、同一時刻に計測した各モジュールの負荷を合計した値の、例えば平均や中央値などの統計量であればよい。負荷の合計値に対する閾値は、ソフトウェアの更新の対象となるモジュール以外のモジュールだけで全ての負荷を負担しても、提供するサービスに遅延などの悪影響が及ばないような負荷の合計値を、適宜選択した値であればよい。閾値は、計算上提供するサービスに遅延などの影響が及ばないような負荷の合計値から、安全を考えたマージン分を引いた値であってもよい。アップデート見積もり部13は、次に、読み出した所要時間に対応する更新データをソフトウェアに対して適用するソフトウェアの更新の実行予定を、抽出した時間帯に割り当てるステップS13。なお、複数のモジュールのソフトウェアに対して同一の更新を適用する場合、更新を適用していないモジュールが無くなるまで、ステップS12及びステップS13の処理を繰り返せばよい。また、適用すべき更新データが複数存在する場合、更新の実行予定を割り当てていない更新データが無くなるまで、ステップS12及びステップS13の処理を繰り返せばよい。アップデート見積もり部13が割り当てた更新予定における、更新の開始時刻になるまで、アップデート実行部14は何も行わないステップS14、N。アップデート見積もり部13が割り当てた更新予定における、更新の開始時刻になるとステップS14、Y、アップデート実行部14は、ソフトウェアの更新の対象となるモジュールに、サービスの提供を中止させるステップS15。なお、アップデート実行部14は、ソフトウェアの更新の対象となるモジュールにサービスの提供を中止させる前に、ソフトウェアの更新の対象となるモジュール以外に正常動作しているモジュールが存在するか確認してもよい。そして、ソフトウェアの更新の対象となるモジュール以外に正常動作しているモジュールが存在しない場合、アップデート実行部14は、ソフトウェアの更新の対象となるモジュールにサービスの提供を継続させてもよい。この場合、ソフトウェア更新装置1Aはソフトウェアの更新を中止すればよい。また、ソフトウェアの更新の対象となるモジュール以外に正常動作しているモジュールが存在する場合、アップデート実行部14は、ソフトウェアの更新の対象となるモジュールにサービスの提供を中止させればよい。各モジュールがディスクアレイ装置のコントローラ部である場合、アップデート実行部14は、データの転送において、ソフトウェアの更新の対象となるコントローラ部を経由しないよう、データ転送のパスを変更するのに必要な処理を適宜行えばよい。各パスは、各コントローラ部と各業務ホストとの間の、データ転送のための接続である。次に、アップデート実行部14は、パッチ記憶部12から更新データを読み出し、ソフトウェアの更新の対象となるモジュールのソフトウェアに対して、読み出した更新データを適用してソフトウェアの更新を行うステップS16。アップデート実行部14は、ソフトウェアの更新を終了すると、ソフトウェアの更新の対象であったモジュールに、サービスの提供を再開させるステップS17。各モジュールがディスクアレイ装置のコントローラ部である場合、アップデート実行部14は、ソフトウェアの更新の対象であったコントローラ部を適宜経由してデータの転送が行われるよう、データ転送のパスを変更するのに必要な処理を適宜行えばよい。次に、本実施形態の効果について説明する。本実施形態には、モジュールが提供するサービスに対して、モジュールのソフトウェアの更新が与える影響を低減すると言う効果がある。その理由は、ソフトウェアの更新の所要時間以上継続して、負荷の合計が閾値を下回る時間帯を、負荷記憶部11が記憶する負荷推移データから抽出し、ソフトウェアの更新の実行予定を割り当てるからである。負荷の合計に対する閾値は、ソフトウェアの更新の対象となるモジュール以外のモジュールで全ての負荷を負担しても、各モジュールが提供するサービスに遅延などの影響が及ばないように選択した値である。従って、本実施形態のソフトウェア更新装置1Aは、アップデート実行部14がソフトウェアの更新を行っている間における、各モジュールが提供するサービスに対する遅延などの影響を軽減することができる。以上では、複数のモジュールが冗長な構成で存在するとして説明を行った。しかし、モジュールは、冗長な構成でなくてもよく、複数でなくてもよい。その場合、負荷記憶部11は、モジュール毎の負荷を時刻に対応付けて記憶しておけばよい。また、アップデート見積もり部13は、長さがソフトウェアの更新の所要時間以上であり、ソフトウェアの更新の対象となるモジュールの負荷が所定の閾値を下回る時間帯を抽出する。さらに、アップデート実行部14がソフトウェアの更新を行う間、モジュールはサービスの提供を停止する。しかし、アップデート見積もり部13が、ソフトウェアの更新の対象となるモジュールの負荷が所定の閾値を下回る時間帯を抽出するので、モジュールが提供するサービスに対して、モジュールのソフトウェアの更新が与える影響を低減することができる。次に、本発明の第2の実施形態について、図面を参照して詳細に説明する。図6は、本実施形態の構成を表すブロック図である。図6を参照すると、本実施形態は、ソフトウェア更新装置1と、ディスクアレイ装置2と、業務ホスト3A及び業務ホスト3Bと、管理ホスト4を含む。図6では、ソフトウェア更新装置1とディスクアレイ装置2は、別の装置であるが、ディスクアレイ装置2がソフトウェア更新装置1を含んでいても構わない。ソフトウェア更新装置1は、図1に示すソフトウェア更新装置1Aの構成に加えて、閾値記憶部15を含む。また、ソフトウェア更新装置1は、負荷監視部16を含んでいてもよい。なお、本実施形態では、ソフトウェアの更新の対象であるモジュールは、ディスクアレイ装置2の各コントローラ部である。アップデート実行部14は、アップデート見積もり手段13が割り当てた実行予定におけるソフトウェアの更新の実行開始時刻になると、ソフトウェアの更新の対象となるコントローラ部を経由しないよう、データ転送のパスを切り替える指示を出力する。この指示の出力先は、後述のディスクアレイ装置2のパス切り替え部25である。アップデート実行手段14は、パスを切り替える指示を出力した後、そのコントローラ部のソフトウェアに対して更新を実行する。閾値記憶部15は、負荷の合計値に対する閾値を、時刻に対応させて記憶する。閾値記憶部15が記憶する閾値は、時刻によって異なる値であってよい。例えば管理ホスト4が、時刻に対応付けた閾値を、予め閾値記憶部15に記憶させておけばよい。負荷監視部16は、例えば所定の時間毎に、各コントローラの負荷を計測する。負荷監視部16は、過去の所定の期間内における同一時刻の負荷の計測値から、例えば平均などの統計値を算出し、時刻毎の負荷の合計の予測値を算出してもよい。負荷監視部16は、算出した予測値を、随時負荷記憶部11に記憶させればよい。負荷監視部16は、過去の所定の期間内における同一時刻の負荷の計測値から、ディスクアレイ装置2からの応答に遅延を発生させずに、コントローラ部を利用不可にできるか否かを判定するための閾値を算出してもよい。この場合の算出方法は、既存の任意の方法でよい。負荷監視部16は、算出した閾値を、随時閾値算出部12に記憶させればよい。本実施形態のソフトウェア更新装置1の他の構成要素は、第1の実施形態の同一の記号を付した構成要素と同じであるので、説明を省略する。ディスクアレイ装置2は、コントローラ部21及びコントローラ部22と、ディスクアレイ23と、パス状態登録部24と、パス切り替え部25を含む。ディスクアレイ装置2のコントローラ部21及びコントローラ部22は、それぞれ各業務ホストに接続されている。各コントローラは、各業務ホストと通信可能である。各コントローラと、各業務ホストとの間は、例えばSANStorageAreaNetworkのネットワークで接続されている。コントローラ部21及びコントローラ部22は、ディスクアレイ23に対するデータの読み書きや転送を制御する。コントローラ部21及びコントローラ部22は冗長構成になっている。また、コントローラ部は3個以上存在していてもよい。各コントローラ部はソフトウェアにより制御される。図7は、コントローラ部21を制御するソフトウェアの構成の例を表す図である。他のコントローラ部の構成も、図7の構成と同じである。なお、コントローラ部の構成は図7の構成に限らない。図7を参照すると、コントローラ部21は、実行環境211で動作するソフトウェアにより制御される。図7の例では、実行環境211のソフトウェアには、管理SWSoftwareと、RAID制御RAID制御ドライバと、OSOperationgSystemの3種類の種別が存在する。バックアップ環境212は、実行環境211のコピーである。ディスクアレイ23は、各業務ホストが各コントローラ部を介して読み書きするデータを記憶する。パス状態登録部24は、各コントローラと各業務ホストとの間のパスが、有効であるか否かを表すパス状態を記憶する。また、パス状態登録部24は、後述の各業務ホストのパス管理部31からパス状態を受信し、記憶しているパス状態を変更する。パス切り替え部25は、アップデート実行部14からの指示に基づき、各コントローラ部を各業務ホストから利用できない状態に変更する。また、パス切り替え部25は、アップデート実行部14からの指示に基づき、各コントローラ部を各業務ホストから利用できる状態に変更する。図6には、業務ホスト3A及び業務ホスト3Bの2台の業務ホストが記載されているが、業務ホストは2台でなくてもよい。各業務ホストは、パス管理部31を含む。各業務ホストは各コントローラに同時に接続され、各コントローラ部を介して、ディスクアレイ23が記憶するデータの読み書きを行う。パス管理部31は、各コントローラ部との間のパスが利用可能であるか否かを監視する。パス管理部31は、例えば、各コントローラ部に対するI/Oエラーの発生の有無を定期的に確認することで、監視を行えばよい。パス管理部31は、利用不可であるコントローラ部が存在すれば、業務ホストとそのコントローラ部との間のパスの利用を禁止する。また、パス管理部31は、利用不可であったコントローラ部が利用可能になれば、業務ホストとそのコントローラ部との間のパスの利用を許可する。例えば、図6のようにディスクアレイ装置2と業務ホスト3Aが接続されており、各コントローラが正常動作していれば、コントローラ部21と業務ホスト3Aの間、及び、コントローラ部22と業務ホスト3Aの間の2つのパスが利用できる。この状態から、パス切り替え部25が、例えばコントローラ部21を利用不可にした場合、パス管理部31はコントローラ部21に対するI/Oエラーの発生を検出し、コントローラ部21との間のパスを利用不可にする。このようにして、2本のパスが利用可能な状態から1本のパスだけが可能な状態にパスの状態が切り替わる、いわゆる片寄せが行われる。また、各装置が図6のような構成であり、パス切り替え部25が、コントローラ部21を、利用不可な状態から利用可能な状態に切り替えた場合、パス管理部31はコントローラ部21に対するI/Oエラーが発生しないことを検出する。I/Oエラーが発生しないことを検出したパス管理部31は、コントローラ部21との間のパスを利用可能にする。パス管理部31は、業務ホストとストレージ装置2との間のいずれかのパスを介して、監視の結果得られた各パスの状態を、ストレージ装置2のパス状態登録部24に記憶させる。なお、以上で説明したパスの切り替えは単なる例である。ディスクアレイ装置2及び各業務ホストは、既存の任意の方法でパスの切り替えを行うことができる。管理ホスト4は、アップデート指示部41を含む。アップデート指示部41は、パッチ記憶部12に更新データ及び所要時間を記憶させる。アップデート指示部41は、アップデート見積もり部13に対して、ソフトウェアの更新の実行予定を割り当てる指示を送信してもよい。次に、本実施形態のソフトウェア更新装置1の動作について、図面を参照して詳細に説明する。図8は、本実施形態のソフトウェア更新装置1の、更新の実行予定を割り当てる動作を表すフローチャートである。ソフトウェア更新装置1は、例えば、アップデート指示部41から適用すべき更新データを特定する情報を受け取り、以下の動作を開始する。図8を参照すると、まず、アップデート見積もり部13が、各コントローラ部のソフトウェアに適用する更新データに対応付けられた更新の所要時間を、パッチ記憶部12から読み出すステップS21。パッチ記憶部12は、所要時間を、対応する更新データに関する情報に関連付けて、例えばテーブルの形で記憶することもできる。図9は、パッチ記憶部12が記憶する、所要時間と、対応する更新データに関する情報を含むテーブルの例である。図9のテーブルは、更新の対象となるソフトウェアの種別と、更新の対象となるモジュール名と、更新後の再起動の要否を含む再起動種別と、所要時間と、更新時におけるパスの切替要否を含む。種別は、パッチを適用する対象となる制御ソフトの種別を表す。種別には、例えば、前述の、管理ソフトウェア、RAID制御ドライバ、OSなどがある。ソフトウェアモジュール名は、ソフトウェを構成するソフトウェアモジュールを識別する名前である。再起動種別は、更新の実行後に再起動が不要であるか、再起動が必要な場合は再起動後に高速再起動が可能であるか否かを表す。なお、高速再起動は、例えばPOSTPowerOnSelfTestを実行しない再起動である。再起動種別が無しの場合、更新の実行後の再起動は不要である。再起動種別が高速の場合、パッチ適用後に再起動が必要だが高速再起動が可能である。再起動種別が通常の場合、パッチ適用後に通常の再起動が必要である。所要時間は、更新を開始してからコントローラ部が再び動作可能になるまでに必要な時間である。所要時間は、適宜見積もった必要な時間の概算で構わない。図9の例では、再起動種別が無しの場合、所要時間は0秒である。再起動種別が高速の場合、所要時間は10秒である。再起動種別が通常の場合、所要時間は600秒~700秒である。切替要否は、更新の実行時に、パス切り替えが必要になるかどうかを表す。切り替え要否は、例えば、所要時間が所定の閾値以上であるか閾値未満であるかにより、予め決めておけばよい。各業務ホストから利用可能であったコントローラ部が、継続して利用できなくなった場合、利用できなくなってから各業務ホストで行われている処理に影響を及ぼすと考えられる時間を、予めこの閾値に設定しておけばよい。図7の切替要否は、閾値が10以上600未満の場合の例である。なお、パッチ記憶部12は、各更新データに対応した切替要否を記憶しておく必要はない。パッチ記憶部12が切替要否を記憶していない場合、後述のステップS22において、アップデート見積もり部13が、所要時間と閾値を比較することで、パスの切替要否を判定すればよい。また、後述のステップS32において、パッチ実行部14は、アップデート見積もり部13によるパスの切替要否を判定結果をそのまま利用すればよい。あるいは、パッチ実行部14が、所要時間と閾値を比較することで、パスの切替要否を判定してもよい。パッチ記憶部12は、個別の更新データの所要時間やその更新データに関する情報だけでなく、複数の更新データをまとめたパッチセットの所要時間などの情報を、パッチセットに関連付けて記憶していてもよい。アップデート見積もり部13は、次に、更新データを適用する際のパスの切替要否を判定するステップS22。単体の更新データを適用する場合、アップデート見積もり部13は、パッチ記憶部12から読み出した、適用する更新データの切替要否のデータに基づき、パスの切替要否を判定すればよい。ソフトウェアに対してパッチセットを適用する場合、パッチ記憶部12がそのパッチセットのパス切替要否のデータを記憶していれば、アップデート見積もり部13は、そのデータに基づきパスの切替要否を判定すればよい。パッチ記憶部12がそのパッチセットのパス切替要否のデータを記憶していない場合、アップデート見積もり部13は、そのパッチセットが、パス切替が必要な更新データを含んでいれば、パス切替が必要と判定すればよい。パス切替が不要である場合ステップS23、N、アップデート実行部14はすぐに更新を実行すればよいステップS27。更新の実行については後述する。パス切替が必要である場合ステップS23、Y、アップデート見積もり部13は、更新の所要時間以上継続して、負荷の合計値が閾値を下回る時間帯を、負荷記憶部11が記憶する負荷推移データから抽出するステップS24。アップデート見積もり部13は、更新の所要時間を、パッチ記憶部12から読み出せばよい。図10は、負荷記憶部11が記憶する負荷推移データの例を表す図である。負荷推移データは、少なくとも負荷の合計値の推移を含んでいればよい。負荷記憶部11が記憶する負荷の値は、例えばIOPSである。また、アップデート見積もり部13は、負荷の合計値に対する閾値を、閾値記憶部15から読み出せばよい。前述のように、閾値記憶部15が記憶する閾値は、時刻によって変動してもよい。この場合、例えばディスクアレイ装置2の管理者が、時刻に応じて適宜定めた閾値を、予め閾値記憶部15に記憶させておけばよい。閾値記憶部15が記憶する閾値は、過去の同時刻において、例えば負荷監視部16が観測した、負荷の値のばらつきの大きさに応じた値であってもよい。閾値記憶部15が記憶する閾値は、例えば、計算上提供するサービスに遅延などの影響が及ばないような負荷の合計値から、各時刻における負荷の観測値のばらつきの大きさに応じた値を引いた値であってもよい。この場合、負荷の観測値のばらつきが大きい時刻の閾値は小さく、負荷の観測値のばらつきが小さい時刻の閾値は大きくなる。図11は、アップデート見積もり部13が抽出した時間帯を表す図である。アップデート見積もり部13は、図11のようなテーブルを生成して、時間帯の抽出を行うことができる。図11の負荷の閾値は、閾値記憶部15が記憶する閾値である。負荷の予測値は、負荷記憶部11が記憶する負荷の合計値である。アップデート見積もり部13は、負荷の閾値より負荷の予測値が小さく、差分が正である時間帯を抽出する。図11でアップデート見積もり部13が抽出した時間帯は、実行可否がOKである時間帯である。条件に適合する時間帯が存在しない場合ステップS25、N、ソフトウェア更新装置1は、更新の実行や更新の実行予定の割り当てを行わずに、処理を終了する。この場合は、例えばディスクアレイ装置2の管理者が手動で更新を実行するなどすればよい。条件に適合する時間帯が存在する場合ステップS25、Y、その時間帯が現在であり即時更新を実行することが可能であればステップS26、Y、アップデート実行部14は更新を実行するステップS27。条件に適合する時間帯が現在ではなく、即時更新を実行できない場合ステップS26、N、アップデート見積もり部13は、更新の実行予定を割り当てるステップS28。この場合、更新の実行予定時刻に、アップデート実行部14が、以下で述べるように更新を実行すればよい。次に、更新実行時の本実施形態の動作について説明する。図12は、更新実行時の本実施形態の動作を表すフローチャートである。なお、ソフトウェア更新装置1は、負荷監視部16が測定した更新の実行予定時刻における負荷の合計値が、閾値記憶部15が記憶する同時刻における閾値より大きい場合、更新の実行を中止してもよい。その場合、ソフトウェア更新装置1は、前述の更新の実行予定の割り当てを再び行えばよい。図12を参照すると、アップデート実行部14が、更新データ、及び、所要時間等の、その更新データに対応する情報を含むパッチ情報を、パッチ記憶部12から読み出すステップS31。アップデート実行部14は、次に、例えば読み出したパッチ情報から、更新の実行時におけるパスの切替の要否を判別するステップS32。アップデート実行部14は、更新を実行する際のパスの切替の要否を、アップデート見積もり部13から受け取ってもよい。パスの切替が必要ない場合ステップS33、N、アップデート実行部14は、更新を実行するステップS38。パスの切替が必要である場合ステップS33、Y、アップデート実行部14は、ディスクアレイ装置2と全ての業務ホストとの間のパスが正常であるか確認するステップS34。ステップS34において、アップデート実行部14は、ソフトウェアの更新の対象となるコントローラ部を停止させた場合、全ての業務ホストとの間に正常なパスが存在するか否かを確認すればよい。アップデート実行部14は、各コントローラ部と各業務ホストとの間の、全てのパスが正常であるか確認してもよい。アップデート実行部14は、ステップS34の確認を、例えば、ストレージ装置2のパス状態登録部24から各パスの状態を受け取ることで行えばよい。パスが正常でない業務ホストが存在する場合ステップS34、N、ソフトウェア更新装置1は処理を終了する。パスが正常でない業務ホストが存在しない場合ステップS34、Y、アップデート実行部14は、パス切り替え部25に指示を送信してパスの切り替えを行うステップS35。アップデート実行部14からパスの切り替えの指示を受信したパス切り替え部25は、ソフトウェアの更新の対象であるコントローラ部と各業務ホストとの間の全てのパスを、利用不可にすればよい。アップデート実行部14は、パスの切替を行った後、更新を実行するステップS36。アップデート実行部14は、更新の実行後、パス切り替え部25に指示を送信して、パスの復旧を行うステップS37。アップデート実行部14からパスの復旧の指示を受信したパス切り替え部25は、ソフトウェアの更新を行ったコントローラ部と各業務ホストとの間の全てのパスを、再び利用可能にすればよい。以上で説明した本実施形態には、第1の実施形態の効果に加えて、同一時刻の負荷の大きさにばらつきがある場合でも、コントローラ部が提供するサービスに対して、コントローラ部のソフトウェアの更新が与える影響を低減すると言う効果がある。その理由は、更新の実行予定を割り当てる際、アップデート見積もり部13が、時刻に応じて値が変動する閾値と、負荷の合計値を比較するからである。例えば、負荷の大きさのばらつきが大きい時刻の閾値を小さく、負荷の大きさのばらつきが小さい時刻の閾値を大きくしておくことで、負荷の予測値は小さいが大きな負荷の変動が起こりうる時間帯の更新を実行することを避けることができる。このことにより、例えば、更新の実行中に急に負荷が増大することで発生する遅延のような、コントローラ部のソフトウェアの更新による影響の発生を減少させることができる。以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解しうる様々な変更をすることができる。