(57)【要約】【課題】複数のサーバ３１、３２、３３に対するファイル更新を容易に且つ正確に実行することができるシステム及び方法を提供すること。【解決手段】保守端末１０は管理サーバ２０に接続され、管理サーバ２０は複数の被管理サーバ３０に接続されている。保守端末１０は被管理サーバ３０の中からファイル更新をすべきサーバ（ファイル更新対象サーバ）３１、３２、３３を選択し、管理サーバ２０に対してファイル更新の指示を送信する（ステップＳ５５）。この指示を受けて管理サーバ２０は複数のファイル更新対象サーバ３１、３２、３３に対して一括ファイル更新を行う。【選択図】  図３
2007226651.tif 000002
【特許請求の範囲】
【請求項１】
保守端末と、当該保守端末に接続された管理サーバと、当該管理サーバに接続された複数の被管理サーバとからなり、前記保守端末からのファイル更新指示を受けた前記管理サーバが前記複数の被管理サーバに対して一括ファイル更新処理を行うことを特徴とするファイル更新システム。
【請求項２】
前記保守端末は、前記一括ファイル更新処理が実行されるべき被管理サーバを選択することができる請求項１記載のファイル更新システム。
【請求項３】
前記被管理サーバのファイル更新に関する情報を当該被管理サーバが保有する請求項１または２記載のファイル更新システム。
【請求項４】
前記保守端末と前記管理サーバはＳＳＬ接続され、前記管理サーバと前記被管理サーバはＳＳＨ接続される請求項１、２または３記載のファイル更新システム。
【請求項５】
保守端末と、当該保守端末に接続された管理サーバと、当該管理サーバに接続された複数の被管理サーバとからなるシステムに使用されるファイル更新方法であって、前記保守端末からのファイル更新指示を受けた前記管理サーバが前記複数の被管理サーバに対して一括ファイル更新処理を行うことを特徴とするファイル更新方法。
【請求項６】
前記保守端末は、前記一括ファイル更新処理が実行される被管理サーバを選択することができる請求項５記載のファイル更新方法。
【請求項７】
前記被管理サーバのファイル更新に関する情報を前記被管理サーバが保有する請求項５または６記載のファイル更新方法。
【請求項８】
前記保守端末と前記管理サーバはＳＳＬ接続され、前記管理サーバと前記被管理サーバはＳＳＨ接続される請求項５、６または７記載のファイル更新方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は複数のサーバへのファイル更新を効率的に行う方法及びシステムに関し、特に、煩雑な手順や確認を行うことなく新プログラムを複数のサーバに対して更新することができる方法及びシステムに関する。
【背景技術】
【０００２】
サーバにインストールされているプログラムを保守端末が新しいプログラムに更新する（ファイル更新する）場合、保守端末には例えば図１のような機能が必要となる。即ち、転送機能（サーバに新プログラムを転送する機能）、ファイル更新機能（旧プログラムをバックアップして新プログラムを配置する機能）、ロールバック機能（旧プログラムに戻す機能）及び版数管理機能（投入済みプログラムの版数を管理する機能）が必要となる。尚、図中のＦＴＰはFile Transfer Protocolの略である。
【０００３】
以下、図１に示す機能を用いて保守端末がサーバのファイル更新を行う場合を、図２を参照して示す。
【０００４】
まず、保守端末がサーバに新ファイルを転送すると共にファイル更新を指示する（ステップＳ１及びＳ２）。するとサーバは旧プログラムのバックアップを取り（ステップＳ３）、新プログラムの配置を行う（ステップＳ４）。その後、サーバは新版数への書き換えを行う（ステップＳ５）。そしてサーバは上記処理を終了したことを保守端末に通知する（ステップＳ６）。上記終了通知を受けると、保守端末はサーバに対し、版数の確認と新プログラムでの機能確認を指示する（ステップＳ７）。この指示に基づきサーバは確認処理を行い、確認結果を保守端末に送信する（ステップＳ８）。版数が正しく更新されていることと新プログラムで正常にサーバが正しく機能することが確認されると（ステップＳ９：ＹＥＳ）、ファイル更新処理が終了する。そうでない場合には（ステップＳ９：ＮＯ）、保守端末はサーバに対してロールバック処理を指示する（ステップＳ１０）。サーバはロールバック完了後、その旨を保守端末に通知する（ステップＳ１１）。
【０００５】
上記一連の処理により、１つのサーバのファイル更新は終了する。しかしながら、実際のシステムにおいては、ファイル更新されるべきサーバ（ファイル更新対象サーバ）が１つである場合は少ない。つまり複数のサーバに対してファイル更新を行う場合が多い。そのような場合、従来、例えば、同一の複数のサーバが稼動しているときに、ロードバランサーなどでロードを振り分けて、１つの１つのサーバに対してファイル更新を行っている。
【０００６】
つまり、このような構成の場合、ファイル更新はそれぞれのサーバに実施する必要がある（図２の作業を個々のサーバに対して実施する必要がある）。このようなファイル更新では、全てのサーバに対するファイル更新が終了するまでの時間や費用がかかり過ぎ、効率の悪いファイル更新となってしまう。
【０００７】
また、例えば数十台のサーバにファイル更新を行う場合には、複数の作業者が必要となる。さらに、同じ作業を何度も行うため、人為的な作業ミスも発生し易いと考えられる。
【０００８】
尚、複数の基地局のシステムファイルを更新する際に、効率良く短時間にファイル転送を実行するためのシステムファイル更新方法が特許文献１に開示されている。また、アプリケーション手段を追加したり一部機能を変更する場合に、他の全てのアプリケーション手段の動作を停止することなく上記変更を行うことができるプログラムファイル更新方法が特許文献２に開示されている。
【特許文献１】特開平１０−２２４２８６号公報
【特許文献２】特開２００１−７６２１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の１つの目的は、複数のサーバに対するファイル更新を容易に且つ正確に実行することができるシステムを提供することである。
【００１０】
本発明の他の目的は、複数のサーバに対するファイル更新を容易に且つ正確に実行することができる方法を提供することである。
【課題を解決するための手段】
【００１１】
本発明によれば、保守端末と、当該保守端末に接続された管理サーバと、当該管理サーバに接続された複数の被管理サーバとからなり、前記保守端末からのファイル更新指示を受けた前記管理サーバが前記複数の被管理サーバに対して一括ファイル更新処理を行うことを特徴とするファイル更新システムが提供される。
【００１２】
好ましくは、前記保守端末は、前記一括ファイル更新処理が実行されるべき被管理サーバを選択することができる。好ましくは、前記被管理サーバのファイル更新に関する情報（版数情報等）を当該被管理サーバが保有する。好ましくは、前記保守端末と前記管理サーバはＳＳＬ接続され、前記管理サーバと前記被管理サーバはＳＳＨ接続される。
【００１３】
また、本発明によれば、保守端末と、当該保守端末に接続された管理サーバと、当該管理サーバに接続された複数の被管理サーバとからなるシステムに使用されるファイル更新方法であって、前記保守端末からのファイル更新指示を受けた前記管理サーバが前記複数の被管理サーバに対して一括ファイル更新処理を行うことを特徴とするファイル更新方法が提供される。
【００１４】
好ましくは、前記保守端末は、前記一括ファイル更新処理が実行される被管理サーバを選択することができる。好ましくは、前記被管理サーバのファイル更新に関する情報（版数情報等）を前記被管理サーバが保有する。好ましくは、前記保守端末と前記管理サーバはＳＳＬ接続され、前記管理サーバと前記被管理サーバはＳＳＨ接続される。
【発明を実施するための形態】
【００１５】
以下、本発明の実施例を図３から図６に基づいて説明する。
【００１６】
図３は本実施例のシステムの概念図である。
【００１７】
図３のシステムには、１つの保守端末１０と１つの管理サーバ２０と複数の被管理サーバ３０（３１、３２、３３）が含まれている。保守端末１０と管理サーバ２０は所定のネットワークで接続されており、管理サーバ２０と被管理サーバ３０も所定のネットワークで接続されている。また、保守端末１０、管理サーバ２０、被管理サーバ３０間のセキュリティを確保するため、通信は暗号化して行う。保守端末１０と管理サーバ２０の間はＷＥＢベースであるため、保守端末１０と管理サーバ２０は例えばＳＳＬ接続される。管理サーバ２０と被管理サーバ３０の間はＳＳＨ接続される。
【００１８】
尚、本実施例では被管理サーバ３０は３つ（３１、３２、３３）であるが、被管理サーバ３０が２つまたは４つ以上の場合にも、以下に説明する処理と同様な処理を行えばよい。
【００１９】
この実施例では、保守端末１０が管理サーバ２０に対してファイルの更新を指示すると、管理サーバ２０が被管理サーバ３０の内の選択されたサーバに対して所定の処理を行うようになっている。つまり、ファイル更新をする場合、保守端末１０は管理サーバ２０を経由して複数のファイル更新対象サーバに対してファイル更新を一括して行うようになっている。尚、以下の説明においては、全ての被管理サーバ３１、３２、３３がファイル更新対象サーバとして選択される場合を説明する。
【００２０】
ファイル更新を行うオペレータは、保守端末１０を操作してファイル更新を行うべきサーバを選択して（ステップＳ５０）、新ファイルを管理サーバ２０に転送する（ステップＳ５１）。管理サーバ２０は、ファイル更新対象サーバとして選択されたサーバ３１、３２、３３に対してファイルを転送する（一括ファイル転送）（ステップＳ５２）。各ファイルインストール対象サーバ３１、３２、３３はファイル転送が終了したことを管理サーバ２０に報告する（ステップＳ５３）。すべてのファイル更新対象サーバ３１、３２、３３から報告が来たならば、管理サーバ２０はその旨を保守端末１０に通知する（ステップＳ５４）。
【００２１】
次に、保守端末１０はファイル更新処理をするよう管理サーバ２０に指示を出す（ステップＳ５５）。この指示を受けて管理サーバ２０は各ファイル更新対象サーバ３１、３２、３３にファイル更新を行う（ステップＳ５６）。即ち、ファイル更新対象サーバ３１、３２、３３に一括ファイル更新を行う。ファイル更新対象サーバ３１、３２、３３はそれぞれ旧ファイル（旧プログラム）のバックアップ処理を行い（ステップＳ５７）、新ファイル（新プログラム）の配置処理を行い（ステップＳ５８）、版数の書き換え処理を行う（ステップＳ５９）。これら処理が全て終了すると、各ファイル更新対象サーバ３１、３２、３３はその旨を管理サーバ２０に通知する（ステップＳ６０）。そして全てのファイル更新対象サーバ３１、３２、３３から終了通知が届いたならば、管理サーバ２０はその旨を保守端末１０に報告する（ステップＳ６１）。
【００２２】
次に、保守端末１０は管理サーバ２０に対して版数確認と機能確認をするよう指示する（ステップＳ６２）。この指示を受けて管理サーバ２０は全てファイル更新対象サーバ３１、３２、３３に対して版数確認処理と機能確認処理を行う（ステップＳ６３）。即ち、ファイル更新対象サーバ３１、３２、３３に一括版数確認及び一括機能確認を行う。各ファイル更新対象サーバ３１、３２、３３は版数の更新が適切になされていることを確認し且つ新しいプログラムで正しく機能するかを確認し、確認結果を管理サーバ２０に通知する（ステップＳ６４）。全てのファイル更新対象サーバから確認結果が来たならば、管理サーバ２０は当該確認結果を保守端末１０に報告する（ステップＳ６５）。版数の更新が正しくなされていることと新プログラム下で正常に作動することが保守端末１０（オペレータ）により確認されたならば、ファイル更新は終了する（ステップＳ６６：ＹＥＳ）。そうでない場合には（ステップＳ６６：ＮＯ）、保守端末１０は管理サーバ２０にロールバックを指示する（ステップＳ６７）。管理サーバ２０はファイル更新が適正に行われなかったファイル更新対象サーバに対してロールバックを行う（ステップＳ６８）。ロールバックが終了したファイル更新対象サーバはその旨を管理サーバ２０に通知する（ステップＳ６９）。管理サーバ２０は全てのロールバック対象サーバからの通知が届いたならば、ロールバックが全て終了したことを保守端末１０に報告する（ステップＳ７０）。
【００２３】
以上の説明から分かるように、ファイル更新する場合、保守端末１０のオペレータが１回の操作を実施すると、管理サーバ２０が各ファイル更新対象サーバ３１、３２、３３へ自動的に同一の更新処理を行う。よって、ファイル更新処理のため操作は容易である。またオペレータの操作ミスの可能性も低減される。
【００２４】
尚、本実施例では、ネットワークを介して種々の操作・処理を行うため、管理サーバ２０及びファイル更新対象サーバ３１、３２、３３はそれぞれ図４の機能を有している。即ち、管理サーバ２０は一括転送実行機能、一括ファイル更新実施機能、一括ロールバック実行機能及び一括版数管理取得機能を有し、ファイル更新対象サーバ３１、３２、３３はファイル更新機能、ロールバック機能、版数管理機能及び版数・状態表示機能を有する。尚、図中、ＭＩＢはManagement Information Baseの略であり、ＳＮＭＰはSimple Network Management Protocolの略である。ファイル更新対象サーバは、現状における版数やサーバの状態をＭＩＢに持つことにより、必要な情報を保守端末１０（オペレータ）及び管理サーバ２０に知らせることができる。ファイル更新対象サーバ３１、３２、３３は各操作・処理を行われるごとにＭＩＢの内容を変更していく。オペレータ及び管理サーバは、ＭＩＢの内容を見ることにより操作・処理の完了（成功）・未了（未成功）を判断することができる。ＭＩＢの例が図５に示されている。また、ＭＩＢの内容が変更される例が図６に示されている。
【００２５】
本実施例では、ファイル更新対象サーバ３１、３２、３３のＭＩＢに版数や状態の情報を持たせている。その理由は、管理サーバ２０が版数や状態の情報を持つと、もしファイル更新対象サーバが手動でファイル更新をされた場合、管理サーバ２０と当該ファイル更新対象サーバの間で保持情報の不一致が生じるからである。このような事態を避けるため、版数や状態といった情報はファイル更新対象サーバ３０で管理し、管理サーバ２０は更新処理のみを実施することとしている。
【００２６】
つまり、ファイル更新対象サーバ３１、３２、３３が各種処理（ファイル更新、エラー時の自動ロールバック等）に必要な情報と版数・状態といったファイル更新に必要な情報の全てを持つことになる。よって、保守端末を選ばない処理が可能となる。
【００２７】
上記説明から分かるように、保守端末１０は、（１）ファイル更新対象サーバ３０ヘのファイル転送、（２）ファイル更新対象サーバ３０の状態表示、（３）ファイル更新対象サーバ３０に対して版数に合わせた処理の実行、及び（４）ファイル更新対象サーバ３０の版数表示、を行うためのデータを保持しない。従って、ファイル転送する処理とファイル更新する処理を別々の保守端末で行うことも可能となり、自由度の高い保守が可能となる。但し、複数の保守端末を使用する場合には、同一処理の同時実行等は不可能にする必要がある。
【００２８】
以上のように実施例によれば、同一機能のサーバが複数台存在した場合のファイル更新を容易に行うことが可能となる。また、新プログラムの転送から更新処理までを全サーバに対して半自動的に行うため、オペレーションミスが発生しにくく、更新処理を正確に行うことが可能となる。
【００２９】
尚、上記実施例ではファイル更新処理の方法を示したが、これは、論理的な機能を示したものであり、実装上のハードウェア・ソフトウェア構成を限定するものではない。
【００３０】
また、上記実施例では新プログラムの転送処理及び更新処埋の自動化のみを示したが、実際のファイル更新では、より複雑なファイル更新を行う必要がある場合も存在する。そのような場合でも、ＭＩＢの項目である「状態」の種類を増やし、増えた処理ごとに状態を変更していくことで対応することが可能となる。
【図面の簡単な説明】
【００３１】
【図１】ファイル更新に必要な機能群を示す図である。
【図２】基本的なファイル更新を説明するための図である。
【図３】本発明の実施例におけるファイル更新を説明するための図である。
【図４】図３のファイル更新を実行するために各装置に必要となる機能群を示す図である。
【図５】図３のファイル更新を実行する場合に使用されるＭＩＢの内容を示す図である。
【図６】図５のＭＩＢの内容を書き換える場合を示す図である。
【符号の説明】
【００３２】
１０  保守端末
２０  管理サーバ
３０  被管理サーバ
３１、３２、３３  ファイル更新対象サーバ
【図１】
2007226651.tif 000003
【図２】
2007226651.tif 000004
【図３】
2007226651.tif 000005
【図４】
2007226651.tif 000006
【図５】
2007226651.tif 000007
【図６】
2007226651.tif 000008