JP2021184222A - 並列処理装置及びファームウェア更新プログラム - Google Patents

Abstract

【課題】ファームウェアの更新において、２次ノードによる失敗を防ぐこと。【解決手段】１次ノード２１は、管理装置３から新ファームウェアの取得を完了すると、新ファームウェアへの更新処理を行いつつ２次ノード２１へ新ファームウェアを転送する。また、２次ノード２１は、新ファームウェアへの更新処理において１次ノード２１が通信できない状態になるまでの予測時間に基づいて、新ファームウェアを１次ノード２１から受信する処理のタイムアウト時間を動的に変更する。【選択図】図１

Description

本発明は、並列処理装置及びファームウェア更新プログラムに関する。

並列処理装置は、複数のノードを有する。各ノードは、情報処理装置であり、ＣＰＵ（Central Processing Unit）及びメモリを備える複数のＣＭＵ（CPU Memory Unit）と、ＣＰＵ、メモリ等のハードウェアを管理する複数のＢＭＣ（Baseboard Management Controller）とを有する。

ノードのファームウェアは、ＢＭＣファームウェアを含み、並列処理装置とネットワークで接続された管理装置により管理される。ノードのファームウェアの更新の際に、全てのノードが管理装置にアクセスすると、管理装置の負荷が高くなるため、ノードをグループ分けし、グループの中の１つの１次ノードだけが管理装置にアクセスして新ファームウェアを取得する。グループの中の他の２次ノードは、１次ノードから新ファームウェアを取得する。

なお、管理コンピュータが、各サーバから通知されたファームウェア情報を管理し、新たに格納されたファームウェアのバージョンとファームウェア情報を比較し、所定条件下でサーバのうち特定のサーバに対して自律的にファームウェア更新を行う従来技術がある。

また、通信可能に接続される複数のＣＰＵの動作を制御するファームフェアの更新処理に要する時間を短縮する情報処理装置がある。この情報処理装置は、マスタ側ＣＰＵがマスタ側ＲＯＭに対して消去コマンド又は書き込みコマンドを発行した後、マスタ側ＲＯＭより消去完了又は書き込み完了の通知を得るまでの待ち時間に、各スレーブ側ＲＯＭに格納されたファームウェアの更新処理を行う。また、マスタ側ＣＰＵが各スレーブ側ＲＯＭに対して消去コマンド又は書き込みコマンドを発行した後、各スレーブ側ＲＯＭより消去完了又は書き込み完了の通知を得るまでの待ち時間に、マスタ側ＲＯＭに格納されたファームウェアの更新処理を行う。

また、ユーザの利便性を損なうことなく、効率的かつ確実に通信端末のファームウェアの更新を行い得るファームウェア更新装置がある。このファームウェア更新装置は、現在実装しているファームウェアを更新するための新しいファームウェアをダウンロードし、ダウンロードした新しいファームウェアに対するリブートの必要性をユーザに明示する。そして、このファームウェア更新装置は、リブートの必要性の明示に対してユーザがリブートの必要性を確認した場合、通信端末のリブートを行う。一方、リブートの必要性の明示に対して所定時間経過してもユーザからリブートの必要性の確認を得られない場合、このファームウェア更新装置は、通信端末のリブートを自動的に行う。

また、複数のファームウェアの更新を行う場合に、不要なリブート動作を排除して更新処理を効率よく行う画像形成装置がある。この画像形成装置は、更新用ファームウェアの供給元となる情報処理装置と通信可能なインタフェース手段を備える。また、この画像形成装置は、複数のファームウェアが格納された記憶手段と、情報処理装置より転送される更新用ファームウェアを記憶手段に順次格納してファームウェアの更新処理を行う制御手段とを備える。制御手段は、情報処理装置から複数の更新用ファームウェアが転送される場合、更新用ファームウェアの記憶手段への格納が全て完了した後に、更新処理の有効化のためのリブート動作を実行する。

また、運用中のファームウェアを新たな更新ファームウェアに切り替える際に、このファームウェアの更新に起因して障害が発生することを回避する制御装置がある。この制御装置は、第１コアで稼動している現用の運用ファームウェアを新たな更新ファームウェアに更新する際に、運用ファームウェアを稼動中でない第２コアを選択し、第２コアの占有メモリ領域に更新ファームウェアとテストプログラムをロードする。そして、この制御装置は、第２コアにおいて、更新ファームウェアに対してテストプログラムを実行することにより更新ファームウェアが正常に動作するか否かを検査する。そして、この制御装置は、検査により正常に動作すると判定された後に、第２コアにおいて更新ファームウェアを稼動させ、ファームウェアに対する処理要求を、第１コアから第２コアに切り替えて処理する。

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

ノードをグループ分けし、グループの中の１つの１次ノードだけが管理装置にアクセスする従来技術では、待ち時間が発生し、更新完了までの時間が待ち時間だけ長くなる。図１１は、待ち時間の発生を説明するための図である。図１１に示すように、従来技術では、全ての１次ノードが新ファームウェアを管理装置から取得した後に２次ノードが同じグループの１次ノードから新ファームウェアを取得する。したがって、管理装置から新ファームウェアの取得を最後に完了した１次ノードを除く１次ノードには、２次ノードへの配信まで待ち時間がある。また、各ノードでの新ファームウェアへの更新は、２次ノードへの配信時間後に一斉に行われる。このため、新ファームウェアの取得を最後に完了した２次ノードを除くノードには、更新開始までの待ち時間がある。

ファームウェアを更新した場合には、テストプログラムを実行する必要があるが、テストプログラムの実行により不具合が発生すると、全てのノードが影響を受け、全てのノードにおいてリトライが発生する。このため、テストプログラムの実行による不具合の発見を、１台のノードだけでもできるだけ早期に行うことで、他のノードへの影響をできるだけ抑える必要がある。

そこで、１次ノードは、新ファームウェアの取得を完了すると、他の１次ノードが新ファームウェアの取得を完了する前に、新ファームウェアへの更新を開始することが考えられる。ただし、１次ノードは、新ファームウェアへの更新中にリブートなどを行うため、２次ノードと通信ができないことがある。すると、２次ノードは、新ファームウェアの取得に失敗し、新ファームウェアへの更新に失敗するという問題がある。

本発明は、１つの側面では、ファームウェアの更新において、２次ノードによる失敗を防ぐことを目的とする。

１つの態様では、並列処理装置は、第１ノードと第２ノードとを有する。前記第１ノードは、自身のファームウェアの新ファームウェアへの更新処理を行いつつ第２ノードへ前記新ファームウェアを転送する。前記第２ノードは、前記更新処理において前記第１ノードが通信できない状態になるまでの予測時間に応じて、前記新ファームウェアを前記第１ノードから受信する処理のタイムアウト時間を動的に変更する。

１つの側面では、本発明は、ファームウェアの更新において、２次ノードによる失敗を防ぐことができる。

図１は、実施例に係る並列処理システムの構成を示す図である。 図２は、ノードを搭載するラックを示す図である。 図３は、シェルフを示す図である。 図４は、ノードの構成を示す図である。 図５は、ＣＮＴＵの構成を示す図である。 図６は、ＢＭＣによるファームウェアの更新シーケンスを示す図である。 図７は、１次ノードと２次ノードによるファームウェア更新のシーケンスを示す図である。 図８は、１次ＢＭＣによるファームウェア更新処理のフローを示すフローチャートである。 図９は、２次ＢＭＣによるファームウェア更新処理のフローを示すフローチャートである。 図１０は、並列処理システムによる更新時間を示す図である。 図１１は、待ち時間の発生を説明するための図である。

以下に、本願の開示する並列処理装置及びファームウェア更新プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。

まず、実施例に係る並列処理システムについて説明する。図１は、実施例に係る並列処理システムの構成を示す図である。図１に示すように、実施例に係る並列処理システム１は、並列処理装置２と管理装置３とを有する。

並列処理装置２は、並列に情報処理を行う装置である。並列処理装置２は、９６台のノード２１を有する。ノード２１は、情報処理を行う装置である。９６台のノード２１は、グループ＃１〜グループ＃４で表される４つのグループ２０にグループ分けされる。なお、並列処理装置２は、より多い台数又はより少ない台数のノード２１を有してよい。また、９６台のノード２１は、より多い数又はより少ない数のグループ２０にグループ分けされてもよい。

各グループ２０には、１台の１次ノード２１と２３台の２次ノード２１が含まれる。１次ノード２１は、管理装置３から新ファームウェアを取得する。２次ノード２１は、同じグループ２０の１次ノード２１から新ファームウェアを取得する。

管理装置３は、並列処理装置２を管理する装置である。管理装置３は、ＩＰＭＩ（Intelligent Platform Management Interface）を用いて各ノード２１と通信する。管理装置３は、ファームウェア記憶部３１と保守支援部３２とを有する。

ファームウェア記憶部３１は、ノード２１で使用されるファームウェアを複数のバージョン（版）について記憶する。

保守支援部３２は、ノード２１のファームウェアの更新を支援する。例えば、保守支援部３２は、システム管理者の指示に基づいて、１次ノード２１に新ファームウェアの取得を指示する。そして、１次ノード２１から新ファームウェアの送信要求を受信すると、保守支援部３２は、ファームウェア記憶部３１から最新のバージョンのファームウェアを読み出して新ファームウェアとして１次ノード２１に送信する。１次ノード２１は、新ファームウェアの受信を完了すると、他の１次ノード２１との待ち合わせを行うことなく、ファームウェアの更新を開始する。

また、保守支援部３２は、１次ノード２１に新ファームウェアの取得を指示して所定の時間が経過すると、２次ノード２１に１次ノード２１からの新ファームウェアの取得を指示する。２次ノード２１は、保守支援部３２から取得指示を受信すると、１次ノード２１からの新ファームウェアの取得を開始する。

図２は、ノード２１を搭載するラックを示す図である。図２に示すように、ラック２ａは、８台のシェルフ２ｂを搭載する。図３は、シェルフ２ｂを示す図である。図３に示すように、シェルフ２ｂは、３台のノード２１を搭載する。したがって、１つのラック２ａには、８×３＝２４台のノード２１が搭載され、並列処理装置２は、９６÷２４＝４つのラック２ａを含む。

図４は、ノード２１の構成を示す図である。図４に示すように、ノード２１は、８台のＣＭＵ４１と、ＣＮＴＵ（CoNTrol Unit）４２と、２台のＩＯＵ（Input Output Unit）４３とを有する。ＣＭＵ４１は、情報処理を行うユニットであり、２つのＣＰＵとメモリを有する。ＣＮＴＵ４２は、ノード２１を制御するユニットである。ＩＯＵ４３は、ＩＯカード等を搭載するユニットである。

図５は、ＣＮＴＵ４２の構成を示す図である。図５に示すように、ＣＮＴＵ４２は、ＢＭＣＢ（ＢＭＣ Board）５１とＣＮＴＢ（CoNTrol Board）５２とを有する。

ＢＭＣＢ５１は、ＢＭＣ６１を搭載するボードである。ＢＭＣＢ５１は、ＢＭＣ６１と、ＳＰＩ−ＦＭＥＭ（Serial Peripheral Interface Flash Memory）６２ａと、ＳＰＩ−ＦＭＥＭ６２ｂと、ｅＭＭＣ（embedded MultiMedia Card）６３とを有する。

ＢＭＣ６１は、ＣＭＵ４１のＣＰＵ、メモリ等のハードウェアを管理する。ＢＭＣ６１は、新ファームウェアを取得し、ファームウェアの更新を行う。ＳＰＩ−ＦＭＥＭ６２ａは、バンク＃０としてＢＭＣファームウェアを記憶する。ＳＰＩ−ＦＭＥＭ６２ｂは、バンク＃１としてＢＭＣファームウェアを記憶する。ＢＭＣＢ５１は、ＳＰＩを用いてＳＰＩ−ＦＭＥＭ６２ａ及びＳＰＩ−ＦＭＥＭ６２ｂにアクセスする。ＢＭＣ６１は、ＭＰＵ（Micro Processing Unit）などの処理装置を有し、ＢＭＣファームウェアを実行する。ＢＭＣファームウェアには、新ファームウェアを取得し、ファームウェアの更新を行う処理も含まれる。

ｅＭＭＣ６３は、管理装置３から取得した新ファームウェアの複数のバージョンを記憶する。新ファームウェアには、ＢＭＣファームウェアと、ＣＰＵファームウェアと、ＣＮＴＢ５２の構成データと、テストプログラムが含まれる。

ＣＮＴＢ５２は、並列処理装置２を制御する部品を搭載するボードである。ＣＮＴＢ５２は、ＦＰＧＡ（Field-Programmable Gate Array）７１と、ＦＭＥＭ７２と、ＲＡＭ（Random Access Memory）７３とを有する。ＦＰＧＡ７１は、並列処理装置２を制御する。ＦＰＧＡ７１は、ＢＭＣＢ５１と接続される。ＦＭＥＭ７２は、ＣＮＴＢ５２の構成データを記憶する。ＲＡＭ７３は、ＣＰＵファームウェアとテストプログラムを記憶する。ＣＮＴＵ４２とＣＭＵ４１のＣＰＵはＩ２Ｃで接続される。

次に、ＢＭＣ６１によるファームウェアの更新シーケンスについて説明する。図６は、ＢＭＣ６１によるファームウェアの更新シーケンスを示す図である。図６において、通信状態は、ＢＭＣ６１が１次ノード２１に含まれる場合に２次ノード２１との通信が可能であるか否かを示す。

図６に示すように、ＢＭＣ６１は、ＢＭＣファームウェア（ＢＭＣＦＷ）をバンク＃１に書き込む（ｔ１）。書き込み時間は３〜５分である。この間、２次ノード２１との通信は可能であり、２次ノード２１は１次ノード２１から新ファームウェアのデータを取得することができる。

そして、ＢＭＣファームウェアのバンク＃１への書き込みが終了すると、ＢＭＣ６１は、リブートする（ｔ２）。リブート時間は約３分である。この間、２次ノード２１との通信は不可であり、２次ノード２１は１次ノード２１からデータを取得することができない。

そして、ＢＭＣ６１は、ＢＭＣファームウェアをバンク＃０に書き込む（ｔ３）。書き込み時間は３〜５分である。この間、２次ノード２１との通信は可能であり、２次ノード２１は１次ノード２１からデータを取得することができる。

そして、ＢＭＣファームウェアのバンク＃０への書き込みが終了すると、ＢＭＣ６１は、リブートする（ｔ４）。リブート時間は約３分である。この間、２次ノード２１との通信は不可であり、２次ノード２１は１次ノード２１からデータを取得することができない。

そして、ＢＭＣ６１は、ＦＭＥＭ７２にＣＮＴＢ５２の構成データを書き込む（ｔ５）。書き込み時間は５〜１０分である。この間、２次ノード２１との通信は可能であり、２次ノード２１は１次ノード２１からデータを取得することができる。

そして、ＣＮＴＢ５２の構成データのＦＭＥＭ７２への書き込みが終了すると、ＢＭＣ６１は、電源を再投入（ＯＦＦしてＯＮ）する（ｔ６）。再投入時間は約５分である。この間、２次ノード２１との通信は不可であり、２次ノード２１は１次ノード２１からデータを取得することができない。

そして、ＢＭＣ６１は、他のデータを書き込む（ｔ７）。書き込み時間は１〜１０分である。この間、２次ノード２１との通信は可能であり、２次ノード２１は１次ノード２１からデータを取得することができる。

このように、ＢＭＣ６１は、ファームウェアの更新中に通信できない時間帯がある。また、１次ノード２１は、新ファームウェアを取得後、他の１次ノード２１との待ち合わせを行うことなく、ファームウェアの更新を開始する。このため、２次ノード２１は、１次ノード２１から新ファームウェアを受信中に通信できない状態になる。すると、タイムアウトが発生し、２次ノード２１は、ファームウェアの更新に失敗する。

そこで、２次ＢＭＣ６１は、新ファームウェアを取得する際に、タイムアウトが発生しないように、タイムアウト時間を動的に変更する。ここで、２次ＢＭＣ６１は、２次ノード２１のＢＭＣ６１である。同様に、１次ＢＭＣ６１は、１次ノード２１のＢＭＣ６１である。

２次ＢＭＣ６１は、新ファームウェアの取得が１次ノード２１におけるリブート又は電源再投入にかからないように、タイムアウト時間を設定する。このため、２次ＢＭＣ６１は、１次ノード２１からの新ファームウェアの取得を開始する際に、次のリブート又は電源再投入までの予測時間を１次ＢＭＣ６１に問い合わせる。そして、２次ＢＭＣ６１は、１次ＢＭＣ６１から予測時間を受け取ると、予測時間に基づいて新ファームウェアの取得時間を決定し、１次ＢＭＣ６１に通知するとともに、タイムアウト時間を設定する。

１次ＢＭＣ６１は、１ブロックのデータの書き込みを行うことによって、次のリブート又は電源再投入までの予測時間を算出する。１次ＢＭＣ６１は、１ブロックのデータの書き込みを行うことによって、１次ＢＭＣ６１の負荷状態を把握することができる。１次ＢＭＣ６１は、予測時間＝１ブロック書き込み時間×残りのブロック数＝１ブロック書き込み時間×（全ブロック数−書き込み済ブロック数）により、予測時間を算出する。そして、１次ＢＭＣ６１は、２次ノード２１からの問い合わせに対して予測時間を応答する。

また、１次ＢＭＣ６１は、２次ＢＭＣ６１から取得時間を通知されると、取得時間の範囲で転送できるデータ量に基づいて、新ファームウェアのデータを２次ノード２１に送信する。

図７は、１次ノード２１と２次ノード２１によるファームウェア更新のシーケンスを示す図である。図７〜図９において、「ＦＷＵＰ（FirmWare UPdate）」は、ファームウェア更新を表す。

図７に示すように、管理装置３は、ＦＷＵＰを１次ノード２１に指示する（ｔ１１）。すると、１次ノード２１は、管理装置３に新ファームウェアの送信を依頼する（ｔ１２）。そして、１次ノード２１は、管理装置３から新ファームウェアを受信する（ｔ１３）。そして、１次ノード２１は、新ファームウェアの受信を完了すると、バンク＃１への書き込みを行う（ｔ１４）。

その後、所定の時間が経過すると、管理装置３は、ＦＷＵＰを２次ノード２１に指示する（ｔ１５）。すると、２次ノード２１は、リブートまでの予測時間の送信を１次ノード２１に依頼する（ｔ１６）。そして、２次ノード２１は、１次ノード２１から予測時間を受信し（ｔ１７）、受信した予測時間に基づいて、データの取得時間を１次ノード２１に通知し（ｔ１８）、タイムアウト時間を設定する。そして、２次ノード２１は、１次ノード２１からデータを受信する（ｔ１９）。

その後、バンク＃１への書き込みが完了すると、１次ノード２１は、リブートを行い（ｔ２０）、リブートが完了すると、バンク＃０への書き込みを行う（ｔ２１）。２次ノード２１は、リブートが完了したと推定されるタイミングで、次のリブートまでの予測時間の送信を１次ノード２１に依頼する（ｔ２２）。そして、２次ノード２１は、１次ノード２１から予測時間を受信し（ｔ２３）、受信した予測時間に基づいて、データの取得時間を１次ノード２１に通知し（ｔ２４）、タイムアウト時間を設定する。そして、２次ノード２１は、１次ノード２１からデータを受信する（ｔ２５）。

その後、バンク＃０への書き込みが完了すると、１次ノード２１は、リブートを行い（ｔ２６）、リブートが完了すると、構成データの書き込みを行う（ｔ２７）。２次ノード２１は、リブートが完了したと推定されるタイミングで、次のリブートまでの予測時間の送信を１次ノード２１に依頼する（ｔ２８）。そして、２次ノード２１は、１次ノード２１から予測時間を受信し（ｔ２９）、予測時間に基づいて最後までデータが取得できると判断し、タイムアウト時間を設定することなく、残りのデータの送信を要求する（ｔ３０）。

このように、２次ノード２１は、１次ノード２１から受信した予測時間に基づいて、タイムアウト時間を設定するので、ＦＷＵＰの失敗を防ぐことができる。

次に、１次ＢＭＣ６１及び２次ＢＭＣ６１によるファームウェア更新処理のフローについて図８及び図９をそれぞれ用いて説明する。図８は、１次ＢＭＣ６１によるファームウェア更新処理のフローを示すフローチャートである。図８に示すように、１次ＢＭＣ６１は、管理装置３よりＦＷＵＰ開始を指示するコマンドを受信する（ステップＳ１）。

そして、１次ＢＭＣ６１は、コマンドで指定された場所から新ファームウェアを取得する（ステップＳ２）。ここで、指定された場所とは、管理装置上のパスである。そして、１次ＢＭＣ６１は、ＢＭＣファームウェア、ＣＰＵファームウェア、ＣＮＴＢ５２の構成データ及びテストプログラムに新ファームウェアを展開する（ステップＳ３）。

そして、１次ＢＭＣ６１は、バンク＃１へのＢＭＣファームウェアの書き込みを行う（ステップＳ４）。そして、１次ＢＭＣ６１は、バンクを切り替え、セルフリブートを行う（ステップＳ５）。そして、起動後に、１次ＢＭＣ６１は、バンク＃０へのＢＭＣファームウェアの書き込みを行う（ステップＳ６）。そして、１次ＢＭＣ６１は、バンクを切り替え、セルフリブートを行う（ステップＳ７）。

そして、１次ＢＭＣ６１は、ＣＮＴＢ５２のＦＭＥＭ７２への構成データの書き込みを行い（ステップＳ８）、セルフ電源再投入を行う（ステップＳ９）。そして、１次ＢＭＣ６１は、ＣＮＴＢ５２のＲＡＭ７３へＣＰＵファームウェアとテストプログラムの書き込みを行い（ステップＳ１０）、ＦＷＵＰを完了する（ステップＳ１１）。

なお、１次ＢＭＣ６１は、セルフリブートでもセルフ電源再投入でもない間は、２次ＢＭＣ６１と、新ファームウェアの転送に関する通信を行う。

図９は、２次ＢＭＣ６１によるファームウェア更新処理のフローを示すフローチャートである。図９に示すように、２次ＢＭＣ６１は、管理装置３よりＦＷＵＰ指示を受信する（ステップＳ２１）。すると、２次ＢＭＣ６１は、１次ＢＭＣ６１へ状態を問い合わせる（ステップＳ２２）。そして、２次ＢＭＣ６１は、１次ＢＭＣ６１が対象の版を取得したか否かを判定し（ステップＳ２３）、未取得の場合には、ステップＳ２２へ戻る。

一方、１次ＢＭＣ６１が対象の版を取得済みの場合には、２次ＢＭＣ６１は、次のリブート又は電源再投入までの予測時間を１次ＢＭＣ６１から取得し、タイムアウト時間を設定する（ステップＳ２４）。そして、２次ＢＭＣ６１は、１次ＢＭＣ６１に新ファームウェアのデータを要求する（ステップＳ２５）。その際、２次ＢＭＣ６１は、予測時間に基づくデータ取得時間を１次ＢＭＣ６１に通知する。１次ＢＭＣ６１は、データ取得時間の範囲で転送できるデータを２次ＢＭＣ６１に送信する。

そして、２次ＢＭＣ６１は、新ファームウェアのデータを受信すると、全データを取得したか否かを判定し（ステップＳ２６）、未取得の場合には、ステップＳ２４へ戻る。一方、全データを取得した場合には、２次ＢＭＣ６１は、取得データを結合し（ステップＳ２７）、ファームウェアを更新する（ステップＳ２８）。

このように、２次ＢＭＣ６１は、次のリブート又は電源再投入までの予測時間を１次ＢＭＣ６１から取得し、タイムアウト時間を設定するので、ファームウェア更新の失敗を防ぐことができる。

図１０は、並列処理システム１による更新時間を示す図である。図１０に示すように、例えば、グループ＃１の１次ノード２１は、管理装置３からの新ファームウェアの取得を最も早く完了し、新ファームウェアへの更新を開始する。したがって、グループ＃１の１次ノード２１は、新ファームウェアへの更新を最も早く完了することができ、テストプログラムの実行による不具合の発生を早期に見つけることができる。

上述してきたように、実施例では、１次ノード２１は、管理装置３から新ファームウェアの取得を完了すると、新ファームウェアへの更新処理を行いつつ２次ノード２１へ新ファームウェアを転送する。また、２次ノード２１は、新ファームウェアの受信処理において１次ノード２１が通信できない状態になるまでの予測時間に基づいて、新ファームウェアを１次ノード２１から受信する処理のタイムアウト時間を動的に変更する。したがって、２次ノード２１は、１次ノード２１からの新ファームウェアの受信の失敗を防ぐことができ、新ファームウェアへの更新の失敗を防ぐことができる。

また、実施例では、２次ノード２１は、１次ノード２１の次のリブート又は電源再投入までの予測時間を１次ノード２１が通信できない状態になるまでの予測時間とするので、１次ノード２１が通信できない状態になるまでの時間を正確に予測することができる。

また、実施例では、１次ノード２１は、１ブロック書き込み時間×（全ブロック数−書き込み済ブロック数）に基づいて、予測時間を計算し、２次ノード２１は、１次ノード２１から予測時間を取得する。したがって、２次ノード２１は、正確な予測時間を取得することができる。

また、実施例では、２次ノード２１は、予測時間に基づいて、データの取得時間を１次ノード２１に通知し、１次ノード２１は、取得時間の範囲で転送できる量のデータを２次ノード２１に送信する。したがって、１次ノード２１は、新ファームウェアの送信の失敗を防ぐことができる。

１ 並列処理システム
２ 並列処理装置
２ａ ラック
２ｂ シェルフ
３ 管理装置
２０ グループ
２１ ノード
３１ ファームウェア記憶部
３２ 保守支援部
４１ ＣＭＵ
４２ ＣＮＴＵ
４３ ＩＯＵ
５１ ＢＭＣＢ
５２ ＣＮＴＢ
６１ ＢＭＣ
６２ａ，６２ｂ ＳＰＩ−ＦＭＥＭ
６３ ｅＭＭＣ
７１ ＦＰＧＡ
７２ ＦＭＥＭ
７３ ＲＡＭ

Claims (5)

1. 自身のファームウェアの新ファームウェアへの更新処理を行いつつ第２ノードへ前記新ファームウェアを転送する第１ノードと、
   前記更新処理において前記第１ノードが通信できない状態になるまでの予測時間に応じて、前記新ファームウェアを前記第１ノードから受信する処理のタイムアウト時間を動的に変更する第２ノードと
   を有することを特徴とする並列処理装置。
2. 前記第２ノードは、前記更新処理におけるリブート又は電源再投入までの予測時間に応じて、前記タイムアウト時間を動的に変更することを特徴とする請求項１に記載の並列処理装置。
3. 前記第２ノードは、前記予測時間を前記第１ノードから取得し、
   前記第１ノードは、単位量の前記新ファームウェアの書き込み時間と、通信できない状態になるまでに書き込みが行われる前記新ファームウェアの量に基づいて前記予測時間を計算して前記第２ノードに通知することを特徴とする請求項１又は２に記載の並列処理装置。
4. 前記第２ノードは、前記予測時間に基づいて前記新ファームウェアの取得時間を前記第１ノードに通知し、
   前記第１ノードは、前記取得時間において転送できるデータ量に基づいて、前記新ファームウェアの一部を前記第２ノードに送信することを特徴とする請求項３に記載の並列処理装置。
5. コンピュータに、
   新ファームウェアへの更新処理を行いつつ前記新ファームウェアを送信する第１ノードから前記新ファームウェアを受信する際に、前記更新処理において前記第１ノードが通信できない状態になるまでの予測時間を取得し、
   取得した予測時間に基づいて、前記新ファームウェアを前記第１ノードから受信する処理のタイムアウト時間を動的に変更する
   処理を実行させることを特徴とするファームウェア更新プログラム。

Images