JP2006113754A - ソフトウェア更新装置及び方法 - Google Patents

Abstract

【課題】短時間に複数のノードで速やかに新ＯＳへの更新および正常性の確認作業を完結することができるソフトウェア更新装置を提供する。
【解決手段】ノード一覧ファイルに記録されている各ノードに対して所定の時刻に再起動するよう指示をしておき、その所定の時刻後に各ノードに対してＰＩＮＧコマンドで応答確認をして（Ｓ２０５）、応答がない場合にリブートがなされたと確認するステップ（Ｓ２０６）と、リブート前後の各ノードの各ポートの状態を照合するステップ（Ｓ２０９〜Ｓ２１０）を作業用端末で自動実行できるようにしたソフトウェア更新装置。
【選択図】 図４

Description

本発明は、ネットワークに組み込まれている複数のノードのソフトウェアを更新するためのソフトウェア更新装置及び方法に関する。

ネットワークに組み込まれている複数のノードのソフトウェアを更新するための技術については、例えば、特許文献１〜４に記載されている。

なお、本願においてノードとは、ネットワークを構成するホスト、クライアント、交換機、端末、ネットワーク機器、通信制御装置、ネットワーク上の接合点、インターネット上の中継点等を意味するものである。また、本願においてソフトウェアとは、コンピュータを作動させるためのＯＳ（Operating System）、アプリケーションソフト等のプログラムや、それに付随するデータの総称であるとする。
特開２００２−１２３３９８号公報 特開平１１−３５３２０２号公報 特開平８−２４９１６３号公報 特開平８−１５２９９７号公報

ところで、通信事業者が提供しているネットワークサービスでは、ネットワークが、ネットワークに組み込まれた複数のコンピュータ（ノード）によって構成されている場合がある。ネットワークを構成するこれらのコンピュータに組み込まれたＯＳの改良版への置き換えや不具合が発見された場合にはコンピュータ毎にＯＳのバージョンアップ作業を行う必要がある。ＯＳのバージョンアップ作業においてはコンピュータのリブート（再起動）が必要となる場合がある。ノードとなるコンピュータをリブートすると、通信回線の遮断が生じる場合がある。そのため、このようなＯＳのバージョンアップ作業においては、重要サービスを収容するネットワークサービスであることから、回線断の期間を出来るかぎり短縮し、迅速な対応が求められている。

従来技術では、バージョンアップ作業の多くを作業者の手動の操作に頼って行っていたため、一度に実施できるノードは２０ノード程度が限界であった。また、重要回線であるにもかかわらず、複数回の回線断を伴うとしてエンドユーザから保守作業者に対しての回線借用の許可が取れない場合があった。従って、サービス提供エリア内全ノードに対して一回のバージョンアップ作業（一回の回線断）で完結することが望まれていた。一例として、バージョンアップ作業時にエンドユーザから与えられている回線借用時間は現状では５分程度しかない。このような場合、この短時間内で速やかに新ＯＳへの更新および正常性の確認作業を完結しなければならない。特に、更に詳しく述べると、以下のような状況にある。

（１）新ＯＳに更新するためにはノードのリブートが必要であり、同時刻に１００以上のノードがリブートしていることを１〜２分という短時間内に確認しなければならない。

（２）リブート前後でサービスを継続するためには、対象ノードの種類にもよるが、１ノードあたり最小４７ユーザから最大２２４ユーザを収容しているので、そのリブート前リンク状態とリブート後リンク状態をチェックする必要がある。１００ノード程度をリブートする場合、短時間内で４７００ユーザから２２４００ユーザのリンク状態を確認しなければならない。

すなわち、従来は、ネットワークに組み込まれている複数のノードのＯＳ等のソフトウェアを更新する際に、複数のノードを一度に確実にリブートさせる処理や、リブート前後すなわち更新前後の作動状態の確認処理を行う際に、対応可能なノード数に一定の制限があるという課題があった。

本発明は、上記の事情を考慮してなされたものであり、例えばエンドユーザから与えられている回線借用時間内で複数のノードにおいて速やかに新ＯＳへの更新および正常性の確認作業を完結することができるソフトウェア更新装置及び方法を提供することを目的とする。

上記課題を解決するため、請求項１記載の発明は、ネットワークに組み込まれている複数のノードのソフトウェアを更新するための装置であって、ソフトウェア更新対象のノードの一覧情報を保持するノード一覧保持手段と、各ノードの各ポートの状態を記録するための接続状態記録手段と、各ノードに対してソフトウェア更新のためのソフトウェアを転送するソフトウェア転送手段と、再起動前の各ノードの各ポートの状態を接続状態記録手段に記録するポート状態記録手段と、ノード一覧保持手段に記録されている各ノードに対して所定の時刻に再起動するよう指示する再起動指示手段と、前記所定の時刻後に各ノードに対して所定の手順で返信を求める信号を送信するとともに返信の有無を確認し、返信が無かったノードが再起動しているノードであると判定する再起動判定手段と、再起動した各ノードから再起動後の作動状態と各ポートの状態とを取得し、接続状態記録手段に記録されている再起動前の各ポートの状態と取得した各ポートの状態とを照合する再起動後状態確認手段とを備えることを特徴とする。

請求項２記載の発明は、前記再起動後状態確認手段が前記作動状態としてソフトウェアのバージョンを取得し、更新後になるべきバージョンの値と比較して比較結果を出力することを特徴とする。

請求項３記載の発明は、前記再起動判定手段が、再起動しなかったと判定したノードを表示する機能を有し、前記再起動後状態確認手段が、照合の結果、一致しなかったポートの情報を表示する機能を有することを特徴とする。

請求項４記載の発明は、前記所定の手順で返信を求める信号を送信する手順が試行回数を１回に設定したＰＩＮＧ（Packet INternet Groper）によるものであることを特徴とする。

請求項５記載の発明は、前記各ノードが、複数のポートを複数のＩ／Ｏ（Input／Output）スロットを介して備えるものであって、前記再起動後状態確認手段が、Ｉ／Ｏスロット単位で各ポートの状態を取得して照合するものであることを特徴とする。

請求項６記載の発明は、ネットワークに組み込まれている複数のノードのソフトウェアを更新するための方法であって、ソフトウェア更新対象のノードの一覧情報を保持するノード一覧保持手段と、各ノードの各ポートの状態を記録するための接続状態記録手段とを用い、各ノードに対してソフトウェア更新のためのソフトウェアを転送するソフトウェア転送過程と、再起動前の各ノードの各ポートの状態を接続状態記録手段に記録するポート状態記録過程と、ノード一覧保持手段に記録されている各ノードに対して所定の時刻に再起動するよう指示する再起動指示過程と、前記所定の時刻後に各ノードに対して所定の手順で返信を求める信号を送信するとともに返信の有無を確認し、返信が無かったノードが再起動しているノードであると判定する再起動判定過程と、再起動した各ノードから再起動後の作動状態と各ポートの状態とを取得し、接続状態記録手段に記録されている再起動前の各ポートの状態と取得した各ポートの状態とを照合する再起動後状態確認過程とを含んでいることを特徴とする。

請求項７記載の発明は、ネットワークに組み込まれている複数のノードのソフトウェアを更新するためのプログラムであって、ソフトウェア更新対象のノードの一覧情報を保持するノード一覧保持手段と、各ノードの各ポートの状態を記録するための接続状態記録手段とを用い、各ノードに対してソフトウェア更新のためのソフトウェアを転送するソフトウェア転送過程と、再起動前の各ノードの各ポートの状態を接続状態記録手段に記録するポート状態記録過程と、ノード一覧保持手段に記録されている各ノードに対して所定の時刻に再起動するよう指示する再起動指示過程と、前記所定の時刻後に各ノードに対して所定の手順で返信を求める信号を送信するとともに返信の有無を確認し、返信が無かったノードが再起動しているノードであると判定する再起動判定過程と、再起動した各ノードから再起動後の作動状態と各ポートの状態とを取得し、接続状態記録手段に記録されている再起動前の各ポートの状態と取得した各ポートの状態とを照合する再起動後状態確認過程とをコンピュータを用いて実行するための記述を含んでいることを特徴とする。

本発明によれば、通信ネットワーク上に多くのノードがある場合、それら全てにＰＩＮＧ等の所定のプログラムによる信号を発信する作業を行なったり、作業前と作業後（リブート前後）のポートやI／Ｏスロットの状態が正常か否かを確認する作業を行なったりする時間が短縮され、労力の軽減を図ることが出来る。また、リブート処理などで問題が発生した場合には瞬時にそれを検知できるので、即座に対処することができる。また、作業時間が短く出来るので、通信ネットワークの遮断時間が少なくて済む。また、ノードからの応答で示されるバージョンと、予め記憶している更新後のバージョンの情報を比較して、同一であるか否かを確認することで、バージョンが正常に更新されたか否かを確実に確認することができる。

また、ＰＩＮＧの試行回数を１回に限定することでリブート状態となっているか否かの判定を短時間で行うことができる。また、Ｉ／Ｏスロット単位でポート状態を確認することで効率良く確認処理を行うことができる。

以下、図面を参照して本発明の実施の形態について説明する。図１は本発明によるソフトウェア更新装置の一実施の形態のシステム構成概念を示すシステム図である。監視制御網１は対象ノードの監視制御を行うためのネットワークであり、現実のあるいは仮想の専用回線等を用いて構成され、監視制御用のデータ通信が行われる。監視制御網１には、作業用端末２と、複数のノード３１、３２、３３、３４、３５、…が接続されている。

作業用端末２は、ＯＳバージョンアップ作業用の端末であり、監視制御網１に接続されている。作業用端末２は、パーソナルコンピュータ等のコンピュータで構成されていて、所定のＯＳ上で本発明のソフトウェア更新装置の主要な機能をなすバージョンアップ作業用アプリケーションソフトが実行される。バージョンアップ作業用アプリケーションソフトは、対象ノード一覧ファイル２１、作業シナリオファイル２２等を読み込み、作業シナリオファイル２２に記述されている作業シナリオに従って、対象ノード一覧ファイル２１に格納されている対象ノード３１、３２、…のＯＳバージョンアップ作業を実施するソフトウェアである。本実施の形態では、作業用端末２でブラウザソフトを実行し、それを介してバージョンアップ作業用アプリケーションソフトに対する操作が行われる。

対象ノード一覧ファイル２１は、ＯＳバージョンアップ対象のノード３１、３２、…の一覧を記載したファイルである。作業シナリオファイル２２は、ＯＳバージョンアップの処理手順を記載したファイルである。この処理手順に従って、バージョンアップ作業用アプリケーションソフトが作動して、ＯＳバージョンアップが処理される。作業シナリオファイル２２は、例えば図１に示すように、「１．Ｔｅｌｎｅｔ（テルネット）接続開始」、「２．事前確認作業」、「３．リブート前最終確認」、「４．装置状態の確認」、「５．新ファイルのダウンロード」、…、「９．リブート時刻の設定」、…、といった各作業の概要を項目別にテキスト形式で記述したファイルである。作業者が任意の項目（シナリオ）を選択すると、バージョンアップ作業用アプリケーションソフトが各項目を具体的な処理過程に分解し、各過程が自動的に実行される。

ノード３１、３２、３３、３４、３５、…は、ネットワークサービスを実現するためにネットワークに組み込まれたコンピュータであり、図２に示すような他のノードが接続されている。ノード３１、３２、…では、所定のＯＳ上でネットワークサービスを提供するための各種機能に対応するプログラムが実行されている。これらのノード３１、３２、…で提供される主要な機能の一つは、ネットワーク上でスイッチとして作動する機能である。スイッチは、複数のネットワーク（通信回線）間でパケットを交換するための装置であり、ネットワークを接続するためのポートを複数有している。また、各ノード３１、３２、…には、ＯＳ等のソフトウェアをバージョンアップ（更新）する際に用いるファイルを記憶するための記憶装置（格納領域）が設けられている。各ノード３１、３２、…はまた、所定のコマンドの実行が指示されると、作業用端末２内（あるいは他の装置内）の所定の記憶領域からバージョンアップ用のソフトウェアをダウンロードしてその記憶装置（格納領域）に格納する機能、設定された時刻に自動的にリブートして運用中のＯＳ等のソフトウェアを記憶している新しいＯＳ等のソフトウェアに書き換える機能等を有している。

図２は、図１のノード３１に接続される他のノードとエンドユーザの構成例を示す図である。図２は、ある提供エリア（例えばある企業）において１０回線の契約がなされた場合の構成例を示している。ノード３１はマルチポイント部を構成し、中継機をなすノード３１１、３１２および３１３が各３回線で接続されている。ノード３１１〜３１３には、収容部をなすノード３１１１〜３１１６が１または２回線で１または２個の中継機部をなすノードに接続されている。そして、収容部をなすノード３１１１〜３１１６には、合計１０台のエンドユーザ端末４０〜４９が１台または２台それぞれ接続されている。このような構成において、例えば端末４０からノード３１１１およびノード３１１を介してノード３１にデータが送られたり、ノード３１からノード３１３およびノード３１１６を介して端末４９にデータが送られたりする。

なお、図２に示すような構成では、マルチポイント部となるノード３１のリブートを伴うソフトウェアを更新する処理を行うと、すべてのエンドユーザ端末４０〜４９にて通信断が発生する。一方、中継機部をなすノード３１１でリブートを伴うソフトウェア更新を行うと、ノード３１１２、３１１３、および３１１６では他のノードを経由することで通信断を回避することができるが、ノード３１１１では通信断が発生する。本実施の形態では、このような構成において、リブートを伴うソフトウェア更新処理が、提供エリア内の複数のノードに対して短時間に一括して確実に行うことを可能としている。

次に図３〜図４を参照して、図１に示す構成でＯＳバージョンアップ作業を行う際の手順について説明する。図３および図４はＯＳバージョンアップ作業を各ノード３１、３２、…のリブート前の処理（図３）と、リブート直前の処理およびリブート後の処理（図４）とに分けて示している。

図３は作業用端末２を操作して、ノード３１、３２、…のＯＳをバージョンアップする処理の事前作業の処理手順を示すシーケンス図である。図３に示す処理は、リブート予定時刻に対して、バージョンアップ用ファイルの転送に必要となる時間を十分確保できる時刻に実行される。まず、作業者が作業用端末２を操作して、バージョンアップ作業用アプリケーションソフトを起動すると、ブラウザ上に操作画面が表示される。ここで、作業シナリオファイル２２に記述されている複数のシナリオから「１．Ｔｅｌｎｅｔ接続開始」シナリオを選択すると、あらかじめ作成されている対象ノード一覧ファイル２１が読み込まれて、対象ノード一覧ファイル２１に記述されている各ノード３１、３２、…に対して順次、Ｔｅｌｎｅｔによるログイン処理が行われる（ステップＳ１０１）。Ｔｅｌｎｅｔは、離れた他のコンピュータにログインし、そのコンピュータ上でコマンドを実行可能することで遠隔操作を行うための仮想端末プロトコルである。ログイン処理が完了すると、各ノード３１、３２、…からログイン成功通知が送信され、各ノード３１、３２、…がコマンド投入待機状態となる（ステップＳ１０２）。

次に作業者が作業シナリオファイル２２に記述されている「２．事前確認作業」シナリオを選択すると、事前確認作業シナリオに対応する確認のための各処理が対象ノード３１、３２、…に対して実行される（ステップＳ１０３）。例えば、各ノードの電源の作動状態が正常か、所定のログに記録されいるメッセージに異常がないか、ファンの状態は正常かといった事項について問い合わせがなされる。これに対して各対象ノード３１、３２、…から作業用端末２へ応答通知がなされる（ステップＳ１０４）。ここで作業用端末２では応答通知の内容に応じた表示が行われる。

次に作業者が作業シナリオファイル２２に記述されている「５．新ファイルのダウンロード」シナリオを選択すると、新ファイルのダウンロードシナリオに対応するコマンドの実行が対象ノード３１、３２、…に対して指示される（ステップＳ１０５）。各対象ノード３１、３２、…において指示されたコマンドが実行され、例えば作業用端末２の所定の記憶領域から指示されたＯＳファイルがダウンロードされ、各対象ノード３１、３２、…の所定の記憶領域に格納される（ステップＳ１０６）。ダウンロードが完了すると、各ノード３１、３２、…から作業用端末２に対して新ＯＳダウンロード完了通知が送信される（ステップＳ１０７）。ここで作業用端末２では完了通知の内容が表示される。

次に作業者が作業シナリオファイル２２に記述されている「９．リブート時刻の設定」シナリオを選択すると、入力したリブート時刻を示す時刻情報が送信されるとともに、リブート時刻を設定するためのコマンドの実行が対象ノード３１、３２、…に対して指示される（ステップＳ１０８）。各対象ノード３１、３２、…で指示されたコマンドが実行され、例えば午前１時３０分にリブートするような設定がなされ、各対象ノード３１、３２、…から作業用端末２に対して設定の完了通知が送信される（ステップＳ１０９）。ここで作業用端末２では設定完了通知の内容が表示される。

次に作業者が作業シナリオファイル２２に記述されている「３．リブート前最終確認」シナリオを選択すると、ＯＳが正常にダウンロードできているか、リブート時刻が正常に設定されているかなどを最終的に確認して応答するようなコマンドや、Ｔｅｌｎｅｔのログアウト処理を行うコマンドの実行が対象ノード３１、３２、…に対して指示される（ステップＳ１１０）。次に、各対象ノード３１、３２、…で指示されたコマンドが実行され、各対象ノード３１、３２、…から作業用端末２に対して応答通知が送信されたり、ログアウト処理が実行されたりする（ステップＳ１１１）。ここで作業用端末２では応答通知の内容が表示される。

図４は作業用端末２を操作してノード３１、３２、…のＯＳをバージョンアップする作業のうち、リブート処理直前の作業およびリブート後の作業の処理手順を示すシーケンス図である。まず、作業者が作業用端末２を操作して、バージョンアップ作業用アプリケーションソフトを起動すると、ブラウザ上に操作画面が表示される。ここで、作業シナリオファイル２２に記述されている複数のシナリオから「シナリオ（１）」（図示せず。）を選択すると、あらかじめ作成されている対象ノード一覧ファイル２１が読み込まれて、対象ノード一覧ファイル２１に記述されている各ノード３１、３２、…に対してＴｅｌｎｅｔによるログイン処理が行われる（ステップＳ２０１）。ログイン処理が終了すると、各ノード３１、３２、…からログイン成功通知が送信され、各ノード３１、３２、…がコマンド投入待機状態となる（ステップＳ２０２）。次にシナリオ（１）に記述されたリブート直前確認作業シナリオ処理に対応する各コマンドの実行が対象ノード３１、３２、…に対して指示される（ステップＳ２０３）。コマンドの内容としては、各収容ノード（図２のノード３１１１〜３１１６等）の各ポートにおけるエンドユーザ端末（図２の端末４０〜４９等）のリンク状態を収集する処理を実行するためのコマンド、その収集結果を作業用端末２宛に送信するためのコマンド等である。ここで各ノードで指示されたコマンドが実行され、各ノードの各ポートの状態を示す情報等が応答通知として作業用端末２へ送信される（ステップＳ２０４）。作業用端末２では、応答通知に含まれるリンクアクティブあるいはリンクダウンといった各ポートの状態を示す情報が、所定のファイルとして記録されるとともに、その情報に基づく表示が行われる。

次に作業シナリオファイル２２に記述されている「シナリオ（２）」が選択されると、図３のステップＳ１０８で各ノード３１、３２、…で設定されたリブート時刻になるまで待機した後、リブート発生確認処理が行われる（ステップＳ２０５）。リブート発生確認処理は、リブート設定時刻から所定時間内に各ノードに対して所定の手順で返信を求める信号を送信し、それに対する各ノードからの返信の有無を確認して、返信が無かったノードがリブートしている状態のノードであると判定する処理である。所定の手順による確認処理とは例えばＰＩＮＧ（Packet Internet Groper）によってアクセスを試みてアクセスが不能である場合にリブートが正常に行われていると確認（判定）する処理である。ＰＩＮＧは、ネットワーク上のコンピュータが通信可能な状態であるかどうかを確認するためのプログラムであり、ＩＣＭＰ（Internet Control Message Protocol）というプロトコルを使って実現される。そして、作業用端末２では、一方、応答の無かったノードが設定時刻にリブートが発生した正常なものであると判定され、他方、応答のあったノードがリブートが発生しなかったと判定され、そのノードを示す情報が表示される（ステップＳ２０６）。作業者は、この時点でリブートが発生しなかったノードに対する対応を行うことが可能となる。

図５はＯＳバージョンアップの際のリブート時の複数のノードの作動状態の時間変化を示す概念図である。全ノード（図５ではノード１〜１００）に同一のリブート時刻（午前１：３０）が設定されていたとすると、バージョンアップ前の旧ＯＳで運用されていたノードが設定時刻に一斉にリブートし、バージョンアップ後の新ＯＳで起動するまでの間のリブート処理時間（例えば１〜２分）通信断が発生する。この間は例えばＰＩＮＧコマンドが各ノードを宛先として実行されたとしても、各ノードから応答信号は送出されない。

次に作業用端末２では、作業者が「シナリオ（３）」を選択することで、リブート設定時刻から所定時間後に各ノード３１、３２、…の立ち上がりの有無を確認する処理が行われる（図４のステップＳ２０７〜Ｓ２０８）。この確認処理は、例えばステップＳ２０５~Ｓ２０６と同様に、ＰＩＮＧコマンドを各ノード３１、３２、…に対して実行することで行うことができる。

次に作業用端末２では、作業者が「シナリオ（４）」を選択することで、エンドユーザリンク状態照合処理とノード状態確認処理が行われる（ステップＳ２０９〜Ｓ２１０）。エンドユーザリンク状態照合処理は、各ノード３１、３２、…に対して各ノードの各ポートにおけるエンドユーザ端末（図２の端末４０〜４９等）のリンク状態を収集する処理を行うコマンドの実行を指示し（ステップＳ２０９）、その応答通知（ステップＳ２１０）として送られてきた各ポートの状態を、ステップＳ２０４でリブート前に所定のファイルに記録した各ポートの状態と比較、照合する処理である。この照合結果としては、作業用端末２でリブート前後で差分が検知されたものについて表示がなされる。他方、ノード状態確認処理は、各ノード３１、３２、…の作動状態を確認する処理であり、例えば運用中のＯＳのバージョンに関する情報（バージョン値）等を各ノード３１、３２、…から作業用端末２へ送信する処理である。例えばバージョンアップ後に設定されるべきバージョンの値と不一致の値がいずれかのノードから返信されてきた場合には、バージョンアップが正常に完了していないことを意味するので、その旨が作業用端末２にて所定の形式で表示される。

次に作業者が「シナリオ（５）」を選択すると、事後処理を実行する要求が送出され（ステップＳ２１１）、その処理結果が返送される（ステップＳ２１２）。事後処理としては、例えば上述したような確認処理で結果がリブート前後で不一致であったり、リブートが発生しなかったり、あるいはバージョンアップが行われなかったりしたノードに対して、再度情報を求めたり、あるいは復旧のためのリブート等の処理を行ったりすることや、または、正常の処理がなされたと確認されノードに対して再度確認処理を行ったり、あるいは他のコマンドの実行を要求したりする処理が含まれる。このような処理をあらかじめシナリオとして準備しておくことで、各処理が自動的に実行される。

なお、図３あるいは図４に示す処理例では、複数のシナリオを作業者が個々に選択して起動させることで一連の処理を実行するようにしているが、複数のシナリオの起動を自動化することも可能である。例えば図４の例でシナリオ（１）の結果に基づいてシナリオ（２）を自動的に起動したり、シナリオ（２）の処理結果に基づいて正常作動したノードに対象ノードを限定した上でシナリオ（３）を自動的に実行するようにしたりすることができる。

次に図６を参照して、図４のステップＳ２０５〜Ｓ２０６によるリブート発生確認処理について説明する。この処理の際、作業用端末２は、まず、対象ノード一覧ファイルをオープンする（ステップＳ３０１）。対象ノード一覧ファイルは、図１（対象ノード一覧ファイル２１）あるいは図９（対象ノード一覧ファイル２１ａ）に示すように、作業対象の各ノードのＩＰ（Internet Protocol）アドレス（図９の符号２１ａ１）とノード名（図９の符号２１ａ２）とから構成されている。次に、対象ノード一覧ファイル２１（あるいは２１ａ）に登録されている全ノードに対する処理が終了していない場合には（ステップ３０２で「ＮＯ」）、対象ノード一覧ファイル２１（２１ａ）から１行すなわち１ノード分のＩＰアドレスおよびノード名が読み出される（ステップＳ３０３）。

次に、読み出したＩＰアドレスに対しＰＩＮＧを１回送出する（ステップＳ３０４）。ＰＩＮＧコマンドはデフォルトでは４回連続して送出（試行）されるが、本実施の形態では１ノード当たり１回のみの送出にして、確認処理の時間短縮を図っている。

次にＰＩＮＧ応答を確認してリブート起動が正常か否かを判定する（ステップＳ３０５）。ＰＩＮＧ応答がＮＧの場合（応答が無い場合）には、リブート起動が正常になされたと判定して結果がＯＫである旨を作業用端末２で実行中のブラウザに表示する（ステップＳ３０６）。他方、ＰＩＮＧ応答がＯＫの場合（応答があった場合）、旧ＯＳで稼働継続中であり、リブート起動が正常でなかった判定して結果がＮＧ（異常）である旨を作業用端末２で実行中のブラウザに表示する（ステップＳ３０７）。

次にステップＳ３０８からラベルAA１へ戻り、ステップＳ３０２で対象ノード一覧ファイル２１（２１ａ）に登録されている全ノードに対する処理が終了したか否かを判定する。終了していない場合には上記と同様にステップＳ３０３〜Ｓ３０７の処理を実行し、全ノードの処理が終了した場合には、対象ノード一覧ファイル２１（２１ａ）をクローズして処理が終了する（ステップＳ３０９）。

次に図７および図８を参照して、図４のステップＳ２０９〜Ｓ２１０によるエンドユーザのリンク状態確認処理について説明する。なお、図７および図８はそれぞれ結合子Ａ、Ｂ、およびＣで結合されている。この処理の際、作業用端末２は、まず、対象ノード一覧ファイル２１（２１ａ）をオープンする（ステップＳ４０１）。次に、対象ノード一覧ファイル２１（２１ａ）に登録されている全ノードに対する処理が終了していない場合には（ステップ４０２で「ＮＯ」）、対象ノード一覧ファイル２１（２１ａ）から１行すなわち１ノード分のＩＰアドレスおよびノード名を読み出す（ステップＳ４０３）。

次に、読み出したＩＰアドレスに対しＴｅｌｎｅｔでログインする（ステップＳ４０４）。そして、所定のコマンドを対象ノードで実行し、その応答に応じて対象ノードの機種を判定する（ステップＳ４０５）。

本実施の形態では、ノード３１、３２、…の構成としてシャーシータイプとボックス（ＢＯＸ）タイプの２種類が用いられるものとする。シャーシータイプのノードは、メインボードに８個のＩ／Ｏスロット（拡張スロット）を有していて、８個のＩ／Ｏスロットにそれぞれ各３２個のポートを備えたＩ／Ｏボードが複数の接点を用いて装着され、構成されている。一方、ボックスタイプのノードは、４８個のポートを備えて構成されている。各ノード３１、３２、…には、これらの種類を応答するコマンドが用意されていて、作業用端末２ではこのコマンドを実行した結果に基づいてノードのタイプを判定する。

シャーシータイプの場合はＩ／Ｏスロットの状態を収集するとともに、各Ｉ／Ｏポートの各ポートのリンク状態を収集し、Ｉ／Ｏスロット単位でリスト化する（ステップＳ４０６）。他方、ボックスタイプの場合は、各ポートのリンク状態を収集し、リスト化する（ステップＳ４１０）。図１０にシャーシータイプの場合のリスト（リンク状態ファイル２３）の例、図１１にボックスタイプの場合のリスト（リンク状態ファイル２３ａ）の例を示した。

図１０のリンク状態ファイル２３には、Ｉ／Ｏスロット１〜８におけるスロットの状態および収容されるポート１〜３２のリンク状態がスロット毎に格納されている。またファイル名は例えば対象ノード一覧ファイル２１から抽出したノード名が自動付与される。各スロットの状態は、正常（Operational）または故障（Failed等Operational以外）で示される（符号２３１、２３４）。各ポートの状態は、リンクアクティブ（２３２）またはリンクダウン（２３３）のいずれかに分類されてその番号によって格納される。他方、図１１のリンク状態ファイル２３ａには、ポート１〜４８の状態（２３ａ１）が格納されている。ファイル名は例えば対象ノード一覧ファイル２１から抽出したノード名が自動付与される。

図７のステップＳ４０６の処理が終了すると、Ｉ／Ｏスロットの状態がリブート前と同一か否かが判定される（ステップＳ４０７）。Ｉ／Ｏスロットの状態が同一でない場合には、該当ノードの処理を中止し、ブラウザにその旨を表示し、そして、ログファイルにスロット状態の判定結果を格納する（ステップＳ４０８）。そして、ステップＳ４０８からラベルBB１へ戻り、ステップＳ４０２の判定処理を再び実行する。なお、ステップＳ４０７の判定の結果、Ｉ／Ｏスロットの状態が不一致の場合は、該当ノードに対する以後の処理を中止し、保守者へ通知して早期対処を促す作業が行われる。

他方、Ｉ／Ｏスロットの状態が同一の場合は、ログファイルに結果が格納される（ステップＳ４０９）。ログファイルの構成例を図１２に示した。図１２のログファイル２４には、各スロットのリブート前後の状態がスロット毎に格納されている。

次にリブート直前に収集した該当ノードのリンク状態ファイルがオープンされる（ステップＳ４１１）。次に全ポートまたは全Ｉ／Ｏスロットの照合処理が終了したか否かが判定される（ステップＳ４１２）。終了していない場合には、リンク状態ファイルから事前のポート状態が読み出される（ステップＳ４１３）。なお、ステップＳ４１１でオープンされるリンク状態ファイルは、図４のステップＳ２０３〜Ｓ２０４の処理で、図１０あるいは図１１と同様の形式のファイルとして作成されていたものとする。

次にリブート後に収集したリンク状態ファイル２３（２３ａ）から対応するポート番号のリンク状態が読み出される（ステップＳ４１４）。ここでリブート前リンク状態とリブート後リンク状態が照合される（ステップＳ４１５）。そして照合の結果が作業用端末２で実行されているブラウザに表示される（ステップＳ４１６またはＳ４１７）。次に照合結果が所定のログファイル（例えば図１２のログファイル２４）に各ポートに対応した情報として格納される（ステップＳ４１８）。

次にステップＳ４１９からステップＳ４１２へ戻り、全ポートが終了したか否かを再度判定し、終了していない場合にはステップＳ４１３以降の処理を再度実行する。全ポートの処理が終了した場合には（ステップＳ４１２で「ＹＥＳ」）、リブート直前に収集した該当ノードのリンク状態ファイルをクローズする（ステップＳ４２０）。次に図７のラベルBB１へ戻り、再びステップＳ４０２の判定処理を実行する。

以上のように本実施の形態では、リブート状態確認の際に、全対象ノードに対してリブート処理の正常／異常を判断する機能を採用している。これによって、リブート起動の有無がリブート処理時間内に確認でき、問題の発生したノードが早期に発見・対処が可能となった。

また、エンドユーザのリンク状態確認の際には、リブート前に収集したエンドユーザのリンク状態とリブート後収集したリンク状態照合を実施し、差分があった場合は速やかに作業者へ通知でき、例えば回線借用時間内（５分）に回復処置を実施することが可能となった。

なお、本発明の実施の形態は、上記のものに限定されず、例えば各構成（処理実行手段、ファイル、処理ステップ等）を統合したりあるいは分散したりする変更が可能である。また、ソフトウェアの更新処理は、ＯＳのバージョンアップに限らず、リブート処理を伴うソフトウェアの更新すべてを含むものとする。また、ノードの構成は汎用のＯＳまたは汎用の組込用ＯＳが稼働するコンピュータによるものに限られず、専用ハードウェア構成とファームウェアとからなるものであってもよい。その場合、ファームウェアの更新作業が本発明の適用対象となる。また、本発明の実施の形態は、コンピュータとそれによって実行されるプログラムとを要素として構成されるものであり、そのプログラムはコンピュータ読み取り可能な記録媒体または通信回線を介して配布することが可能である。

本発明の実施の形態のシステム図。 図１のノード３１に接続される他の構成を示すシステム図。 図１に示す構成におけるＯＳバージョンアップ作業の処理概要（事前作業〜リブート実施前）を示す図。 図１に示す構成におけるＯＳバージョンアップ作業の処理概要（リブート直前作業〜リブート後正常正確認作業）を示す図。 図４のスケジュールリブート確認中の処理を説明するための概念図。 図４のステップＳ２０５〜Ｓ２０６の処理のフローを示す図。 図４のステップＳ２０９〜Ｓ２１０の処理のフローを示す図（１／２）。 図４のステップＳ２０９〜Ｓ２１０の処理のフローを示す図（２／２）。 対象ノード一覧ファイルの構成例を示す図。 リンク状態ファイル（シャーシータイプ）の構成例を示す図。 リンク状態ファイル（ボックスタイプ）の構成例を示す図。 ログファイル（シャーシータイプ）の構成例を示す図。

符号の説明

１ 監視制御網
２ 作業用端末
３１〜３５、３１１〜３１２、３１１１〜３１１６ ノード
４０〜４９ エンドユーザ端末
２１、２１ａ 対象ノード一覧ファイル
２２ 作業シナリオファイル
２３、２３ａ リンク状態ファイル

Claims (7)

1. ネットワークに組み込まれている複数のノードのソフトウェアを更新するための装置であって、
   ソフトウェア更新対象のノードの一覧情報を保持するノード一覧保持手段と、
   各ノードの各ポートの状態を記録するための接続状態記録手段と、
   各ノードに対してソフトウェア更新のためのソフトウェアを転送するソフトウェア転送手段と、
   再起動前の各ノードの各ポートの状態を接続状態記録手段に記録するポート状態記録手段と、
   ノード一覧保持手段に記録されている各ノードに対して所定の時刻に再起動するよう指示する再起動指示手段と、
   前記所定の時刻後に各ノードに対して所定の手順で返信を求める信号を送信するとともに返信の有無を確認し、返信が無かったノードが再起動しているノードであると判定する再起動判定手段と、
   再起動した各ノードから再起動後の作動状態と各ポートの状態とを取得し、接続状態記録手段に記録されている再起動前の各ポートの状態と取得した各ポートの状態とを照合する再起動後状態確認手段と
   を備えることを特徴とするソフトウェア更新装置。
2. 前記再起動後状態確認手段が前記作動状態としてソフトウェアのバージョンを取得し、更新後になるべきバージョンの値と比較して比較結果を出力することを特徴とする請求項１記載のソフトウェア更新装置。
3. 前記再起動判定手段が、再起動しなかったと判定したノードを表示する機能を有し、
   前記再起動後状態確認手段が、照合の結果、一致しなかったポートの情報を表示する機能を有する
   ことを特徴とする請求項１又は２記載のソフトウェア更新装置。
4. 前記所定の手順で返信を求める信号を送信する手順が試行回数を１回に設定したＰＩＮＧ（Packet INternet Groper）によるものであることを特徴とする請求項１〜３のいずれか１項に記載のソフトウェア更新装置。
5. 前記各ノードが、複数のポートを複数のＩ／Ｏ（Input／Output）スロットを介して備えるものであって、
   前記再起動後状態確認手段が、Ｉ／Ｏスロット単位で各ポートの状態を取得して照合するものである
   ことを特徴とする請求項１〜４のいずれか１項に記載のソフトウェア更新装置。
6. ネットワークに組み込まれている複数のノードのソフトウェアを更新するための方法であって、
   ソフトウェア更新対象のノードの一覧情報を保持するノード一覧保持手段と、
   各ノードの各ポートの状態を記録するための接続状態記録手段とを用い、
   各ノードに対してソフトウェア更新のためのソフトウェアを転送するソフトウェア転送過程と、
   再起動前の各ノードの各ポートの状態を接続状態記録手段に記録するポート状態記録過程と、
   ノード一覧保持手段に記録されている各ノードに対して所定の時刻に再起動するよう指示する再起動指示過程と、
   前記所定の時刻後に各ノードに対して所定の手順で返信を求める信号を送信するとともに返信の有無を確認し、返信が無かったノードが再起動しているノードであると判定する再起動判定過程と、
   再起動した各ノードから再起動後の作動状態と各ポートの状態とを取得し、接続状態記録手段に記録されている再起動前の各ポートの状態と取得した各ポートの状態とを照合する再起動後状態確認過程と
   を含んでいることを特徴とするソフトウェア更新方法。
7. ネットワークに組み込まれている複数のノードのソフトウェアを更新するためのプログラムであって、
   ソフトウェア更新対象のノードの一覧情報を保持するノード一覧保持手段と、
   各ノードの各ポートの状態を記録するための接続状態記録手段とを用い、
   各ノードに対してソフトウェア更新のためのソフトウェアを転送するソフトウェア転送過程と、
   再起動前の各ノードの各ポートの状態を接続状態記録手段に記録するポート状態記録過程と、
   ノード一覧保持手段に記録されている各ノードに対して所定の時刻に再起動するよう指示する再起動指示過程と、
   前記所定の時刻後に各ノードに対して所定の手順で返信を求める信号を送信するとともに返信の有無を確認し、返信が無かったノードが再起動しているノードであると判定する再起動判定過程と、
   再起動した各ノードから再起動後の作動状態と各ポートの状態とを取得し、接続状態記録手段に記録されている再起動前の各ポートの状態と取得した各ポートの状態とを照合する再起動後状態確認過程と
   をコンピュータを用いて実行するための記述を含んでいることを特徴とするソフトウェア更新プログラム。

Images