(57)【要約】【課題】  サービスへの影響を最小限に抑えてＯＳのファイル更新を行い、問題が生じた場合には容易に復旧できるクラスタシステムを提供する。【解決手段】  本発明のクラスタシステムは、各サーバのＯＳのファイル更新を行う場合に、現在待機系の第１のサーバ又は第２のサーバは、ＯＳ切り替え制御部を用いて、一世代前の停止系のＯＳである第１のＯＳ又は第２のＯＳを、起動系に切り替え、ファイル更新制御部を用いて、予め取得した更新ファイルにより、起動系に切り替えた第１のＯＳ又は第２のＯＳのファイル更新を行い、第１のＯＳ又は第２のＯＳのファイル更新後、サーバ切り替え制御部を用いて、第１のサーバ及び第２のサーバの運用系と待機系を切り替える制御を行い、待機系に切り替わったもう一方の第１のサーバ又は第２のサーバは、同様の手順により、ＯＳのファイル更新を行うことを特徴とする。【選択図】      図１
2018018328.tif 000002
【特許請求の範囲】
【請求項１】
第１のサーバ及び第２のサーバを有し、前記第１のサーバ及び第２のサーバの内、いずれか一方のサーバが運用系として動作し、他方のサーバが待機系として待機するクラスタシステムにおいて、
前記各サーバは、
運用系と待機系を切り替える制御を行うサーバ切り替え制御部と、
第１のＯＳ及び第２のＯＳを別々の記憶領域に保持する記憶部と、
前記第１のＯＳ及び第２のＯＳの内、いずれか一方のＯＳをサーバとしての基本的な機能を発揮するための起動系のＯＳとして起動し、もう一方のＯＳを停止系のＯＳとして停止させる制御を行うＯＳ切り替え制御部と、
前記第１のＯＳ及び第２のＯＳの内、いずれか一方のＯＳのみを最新の状態にファイル更新し、他方のＯＳを一世代前の状態のまま保持するファイル更新制御部とを備え、
前記各サーバのＯＳのファイル更新を行う場合に、
現在待機系の第１のサーバ又は第２のサーバは、
前記ＯＳ切り替え制御部を用いて、一世代前の停止系のＯＳである前記第１のＯＳ又は第２のＯＳを、起動系に切り替え、
前記ファイル更新制御部を用いて、予め取得した更新ファイルにより、起動系に切り替えた前記第１のＯＳ又は第２のＯＳのファイル更新を行い、
前記第１のＯＳ又は第２のＯＳのファイル更新後、前記サーバ切り替え制御部を用いて、前記第１のサーバ及び第２のサーバの運用系と待機系を切り替える制御を行い、
待機系に切り替わったもう一方の第１のサーバ又は第２のサーバは、切り替え前に待機系であった第１のサーバ又は第２のサーバと同様の手順により、ＯＳのファイル更新を行う
ことを特徴とするクラスタシステム。
【請求項２】
前記各サーバのＯＳのファイル更新を行う場合に、
現在待機系の第１のサーバ又は第２のサーバは、
前記ファイル更新制御部を用いて、予め取得した更新ファイルにより、一世代前の停止系のＯＳである前記第１のＯＳ又は第２のＯＳのファイル更新を行い、
前記ＯＳ切り替え制御部を用いて、ファイル更新した前記第１のＯＳ又は第２のＯＳを、起動系に切り替える制御を行う
ことを特徴とする請求項１に記載のクラスタシステム。
【請求項３】
前記各サーバは、ネットワークを介して、前記第１のＯＳ又は第２のＯＳの更新ファイルを取得する通信部を有することを特徴とする請求項１又は２に記載のクラスタシステム。
【請求項４】
前記各サーバの起動系のＯＳに不具合が発見された場合には、
現在待機系の第１のサーバ又は第２のサーバは、
前記ＯＳ切り替え制御部を用いて、一世代前の停止系のＯＳである前記第１のＯＳ又は第２のＯＳを、起動系に切り替え、
前記サーバ切り替え制御部を用いて、前記第１のサーバ及び第２のサーバの運用系と待機系を切り替える制御を行い、
待機系に切り替わったもう一方の第１のサーバ又は第２のサーバは、
前記ＯＳ切り替え制御部を用いて、一世代前の停止系のＯＳである前記第１のＯＳ又は第２のＯＳを、起動系に切り替える
ことを特徴とする請求項１〜３のいずれかに記載のクラスタシステム。
【請求項５】
第１のＯＳ及び第２のＯＳを別々の記憶領域に保持する記憶部を備える第１のサーバ及び第２のサーバを有し、前記第１のサーバ及び第２のサーバの内、いずれか一方のサーバが運用系として動作し、他方のサーバが待機系として待機するクラスタシステムを構成する各サーバに搭載されるコンピュータを、
運用系と待機系を切り替える制御を行うサーバ切り替え制御部と、
前記第１のＯＳ及び第２のＯＳの内、いずれか一方のＯＳをサーバとしての基本的な機能を発揮するための起動系のＯＳとして起動し、もう一方のＯＳを停止系のＯＳとして停止させる制御を行うＯＳ切り替え制御部と、
前記第１のＯＳ及び第２のＯＳの内、いずれか一方のＯＳのみを最新の状態にファイル更新し、他方のＯＳを一世代前の状態のまま保持するファイル更新制御部として機能させ、
前記各サーバのＯＳのファイル更新を行う場合に、
現在待機系の第１のサーバ又は第２のサーバは、
前記ＯＳ切り替え制御部を用いて、一世代前の停止系のＯＳである前記第１のＯＳ又は第２のＯＳを、起動系に切り替え、
前記ファイル更新制御部を用いて、予め取得した更新ファイルにより、起動系に切り替えた前記第１のＯＳ又は第２のＯＳのファイル更新を行い、
前記第１のＯＳ又は第２のＯＳのファイル更新後、前記サーバ切り替え制御部を用いて、前記第１のサーバ及び第２のサーバの運用系と待機系を切り替える制御を行い、
待機系に切り替わったもう一方の第１のサーバ又は第２のサーバは、切り替え前に待機系であった第１のサーバ又は第２のサーバと同様の手順により、ＯＳのファイル更新を行う
ことを特徴とするサーバ制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスタシステム及びサーバ制御プログラムに関し、例えば、例えば、２重化冗長構成（運用系（ＡＣＴ系）／待機系（ＳＢＹ系））のサーバを有するクラスタシステムに適用し得るものである。
【背景技術】
【０００２】
近年、継続的にサービスを提供するためにクラスタシステムが広く普及している。クラスタシステムの方式としては種々の方式があるが、複数のサーバを使用して冗長化し、システムの停止時間を最小限に抑え、業務の可用性を向上させる方式としてＨＡ（Ｈｉｇｈ  Ａｖａｉｌａｂｉｌｉｔｙ）クラスタシステムが存在する。
【０００３】
このＨＡクラスタシステムは、サービス提供中（以下、「ＡＣＴ」系と呼ぶ）サーバで障害を検知すると、サービス未提供サーバ（以下、「ＳＢＹ」系と呼ぶ）に切り替え、業務のダウンタイムを短くすることでサーバの信頼性を向上させるシステムである。
【０００４】
ところで、ＨＡクラスタシステムのサーバは、サービスの提供中に、サーバ上のプログラムに問題（不具合等）が発生した場合は、サーバ上にインストールされているソフトウェアの更新（以下、「ファイル更新」と呼ぶ）が必要となる（例えば、特許文献１参照）。
【０００５】
また、通信機器等のサーバは、提供中のサービスを停止することなく、ファイル更新を行う必要がある。通常、ＨＡクラスタシステムでファイル更新を行う場合は、まずＳＢＹ系のサーバをファイル更新した後に、ＡＣＴ系のサーバとＳＢＹ系のサーバの切り替えを行い、切り替えた後にＳＢＹ系（元はＡＣＴ系）のサーバのファイル更新を再度行う。このような手順を取ることで、サービスの停止時間を最小限に抑えることが可能となる。
【０００６】
また、ファイル更新を行うサーバは、更新前に更新対象のファイルをバックアップしておくことで、もしファイル更新後に、更新したファイルのどこかで不具合が発生してしまい、ファイル更新前の状態に戻したい場合に、このバックアップしたファイルを使用して、ファイル更新前の状態に戻すことが可能である。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−２４２６７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、サーバ上のＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）やカーネル関連のファイルについては、通常はＲＰＭ等のファイル形式でパッケージ管理されていることが多い。
【０００９】
しかしながら、ＲＰＭパッケージは、パッケージ単位で他のパッケージとの依存関係を持っているため、インストールは容易に行えても、アンインストールするときに、対象のパッケージが他のパッケージと依存関係にある場合には、アンインストール出来ない制限がある。この場合、サーバは、他の依存関係にあるパッケージを全てアンインストールした後に、対象のパッケージをアンインストールする必要が生じる。
【００１０】
そのため、サーバは、ＲＰＭパッケージをファイル更新した後に、ファイル更新前の状態に戻す場合には、ＲＰＭパッケージの依存関係のチェックが必要となる。よって、パッケージの管理が必要となり、更新するＲＰＭパッケージ量が膨大となった場合には、管理が非常に煩雑となってしまう懸念がある。また、サーバは、誤ったＲＰＭファイルをインストールしてしまった場合など、場合によっては対象装置のＯＳの再インストールが必要になってしまう可能性もあり、容易に元の状態に戻すことが難しいという課題がある。
【００１１】
そのため、サービスへの影響を最小限に抑えてＯＳのファイル更新を行い、更新したファイルに問題が生じた場合には容易に復旧作業を行うことができるクラスタシステム及びサーバ制御プログラムが望まれている。
【課題を解決するための手段】
【００１２】
第１の本発明は、第１のサーバ及び第２のサーバを有し、前記第１のサーバ及び第２のサーバの内、いずれか一方のサーバが運用系として動作し、他方のサーバが待機系として待機するクラスタシステムにおいて、前記各サーバは、（１）運用系と待機系を切り替える制御を行うサーバ切り替え制御部と、（２）第１のＯＳ及び第２のＯＳを別々の記憶領域に保持する記憶部と、（３）前記第１のＯＳ及び第２のＯＳの内、いずれか一方のＯＳをサーバとしての基本的な機能を発揮するための起動系のＯＳとして起動し、もう一方のＯＳを停止系のＯＳとして停止させる制御を行うＯＳ切り替え制御部と、（４）前記第１のＯＳ及び第２のＯＳの内、いずれか一方のＯＳのみを最新の状態にファイル更新し、他方のＯＳを一世代前の状態のまま保持するファイル更新制御部とを備え、（５）前記各サーバのＯＳのファイル更新を行う場合に、現在待機系の第１のサーバ又は第２のサーバは、前記ＯＳ切り替え制御部を用いて、一世代前の停止系のＯＳである前記第１のＯＳ又は第２のＯＳを、起動系に切り替え、前記ファイル更新制御部を用いて、予め取得した更新ファイルにより、起動系に切り替えた前記第１のＯＳ又は第２のＯＳのファイル更新を行い、前記第１のＯＳ又は第２のＯＳのファイル更新後、前記サーバ切り替え制御部を用いて、前記第１のサーバ及び第２のサーバの運用系と待機系を切り替える制御を行い、待機系に切り替わったもう一方の第１のサーバ又は第２のサーバは、切り替え前に待機系であった第１のサーバ又は第２のサーバと同様の手順により、ＯＳのファイル更新を行うことを特徴とする。
【００１３】
第２の本発明のサーバ制御プログラムは、第１のＯＳ及び第２のＯＳを別々の記憶領域に保持する記憶部を備える第１のサーバ及び第２のサーバを有し、前記第１のサーバ及び第２のサーバの内、いずれか一方のサーバが運用系として動作し、他方のサーバが待機系として待機するクラスタシステムを構成する各サーバに搭載されるコンピュータを、（１）運用系と待機系を切り替える制御を行うサーバ切り替え制御部と、（２）前記第１のＯＳ及び第２のＯＳの内、いずれか一方のＯＳをサーバとしての基本的な機能を発揮するための起動系のＯＳとして起動し、もう一方のＯＳを停止系のＯＳとして停止させる制御を行うＯＳ切り替え制御部と、（３）前記第１のＯＳ及び第２のＯＳの内、いずれか一方のＯＳのみを最新の状態にファイル更新し、他方のＯＳを一世代前の状態のまま保持するファイル更新制御部として機能させ、（４）前記各サーバのＯＳのファイル更新を行う場合に、現在待機系の第１のサーバ又は第２のサーバは、前記ＯＳ切り替え制御部を用いて、一世代前の停止系のＯＳである前記第１のＯＳ又は第２のＯＳを、起動系に切り替え、前記ファイル更新制御部を用いて、予め取得した更新ファイルにより、起動系に切り替えた前記第１のＯＳ又は第２のＯＳのファイル更新を行い、前記第１のＯＳ又は第２のＯＳのファイル更新後、前記サーバ切り替え制御部を用いて、前記第１のサーバ及び第２のサーバの運用系と待機系を切り替える制御を行い、待機系に切り替わったもう一方の第１のサーバ又は第２のサーバは、切り替え前に待機系であった第１のサーバ又は第２のサーバと同様の手順により、ＯＳのファイル更新を行うことを特徴とする。
【発明の効果】
【００１４】
本発明によれば、サービスへの影響を最小限に抑えてＯＳのファイル更新を行い、更新したファイルに問題が生じた場合には容易に復旧作業を行うことができる。
【図面の簡単な説明】
【００１５】
【図１】実施形態の記憶部の詳細構成を示すブロック図である。
【図２】実施形態のクラスタシステムの構成及びサーバの内部構成を示すブロック図である。
【図３】実施形態のサーバの制御系の機能的構成を示すブロック図である。
【図４】実施形態のクラスタシステムを構成する各サーバのＯＳ関連ファイルの更新動作を示す説明図である。
【図５】実施形態のクラスタシステムを構成する各サーバのＯＳ関連ファイルの戻し動作を示す説明図である
【図６】実施形態のクラスタシステムの各サーバのＯＳの版（バージョン）が、ファイル更新（アップデート）、及びファイル戻し（ダウングレード）を実行する毎に変化する様子をイメージ化した説明図である。
【発明を実施するための形態】
【００１６】
（Ａ）主たる実施形態
以下、本発明によるクラスタシステム及びサーバ制御プログラムの実施形態を、図面を参照しながら詳述する。
【００１７】
（Ａ−１）実施形態の構成
（Ａ−１−１）全体構成
図２は、この実施形態のクラスタシステムの構成及びサーバの内部構成を示すブロック図である。
【００１８】
図２において、クラスタシステム１は、２台のサーバ１０（サーバ１０−１及びサーバ１０−２）を有して構成されるものである。以下、サーバ１０−１を、単に「第１サーバ」と呼ぶときもある。同様に、サーバ１０−２を、「第２サーバ」と呼ぶときもある。
【００１９】
第１サーバ及び第２サーバは、様々なサービスを提供するものであり、例えばＩＰ電話サービスの管理、制御を行うＳＩＰサーバ等の種々の業務サービスを提供するサーバが該当する。また、第１サーバ及び第２サーバのハードウェア構成は、一般的な情報処理装置と同じ構成を有しており、ソフトウェア構成としては、例えば、Ｌｉｎｕｘ（登録商標）、ＵＮＩＸ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）等をＯＳとするものが該当する。
【００２０】
さらに、第１サーバ及び第２サーバは、ＨＡクラスタシステムの構成サーバであるから、双方とも同じ機能を備えるものであり、相互に死活監視を行っている。運用系（ＡＣＴ系）サーバに障害が生じた場合には、待機系（ＳＢＹ系）サーバへの切り替え処理が行われる。
【００２１】
（Ａ−１−２）サーバの詳細な構成
図２に示すように、本実施形態に係るサーバ１０（１０−１、１０−２）は、ＣＰＵ１１（１１−１、１１−２）、メモリ１２（１２−１、１２−２）、記憶部１３（１３−１、１３−２）、及び通信部１４（１４−１、１４−２）を少なくとも備える。なお、以下では、２台のサーバ１０（１０−１、１０−２）の共通する処理を説明する場合においては、符号の枝番を省略して説明する。
【００２２】
ＣＰＵ１１は、サーバ１０の演算処理装置である。
【００２３】
メモリ１２は、サーバ１０のメインメモリ（揮発性メモリ）である。メモリ１２は、記憶部１３から読み込んだプログラムが展開され、ＣＰＵ１１により実行される領域である。
【００２４】
通信部１４は、例えば、図示しないＩＰネットワークに接続するインタフェースであり、パケットの送受信をして通信する部分である。
【００２５】
記憶部１３は、ＣＰＵ１１により実行される処理プログラムや、情報処理に必要な各種情報等を記憶するものである。記憶部１３は、例えば、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、及びフラッシュメモリ等の不揮発性の記憶装置を適用することができる。
【００２６】
図１は、記憶部の詳細構成を示すブロック図である。図１において、記憶部１３は、５つのパーティションに分割されており、第１のパーティションから順に、ブートローダ１３１、第１のサーバＯＳ１３２、第２のサーバＯＳ１３３、アプリケーション１３４、及びその他１３５が格納されている。なお、図１の構成例は、一例であって、記憶部１３内のパーティション分割方法、及び各パーティションに格納されるプログラムについてはこれに限定されるものではない。
【００２７】
ブートローダ１３１は、サーバ１０の電源投入時（再起動時を含む）に最初に起動されるものであり、第１のサーバＯＳ１３２、又は第２のサーバＯＳ１３３のいずれかを選択してＯＳを起動させる。例えば、ブートローダ１３１は、ｇｒｕｂ等に相当するプログラムである。
【００２８】
第１のサーバＯＳ１３２及び第２のサーバＯＳ１３３は、サーバ本来としての基本的な機能を発揮させるためのプログラムである。第１のサーバＯＳ１３２及び第２のサーバＯＳ１３３は、Ｌｉｎｕｘ、ＵＮＩＸ、及びＷｉｎｄｏｗｓ等が該当する。なお、この実施形態では、ブートローダ１３１により選択されて起動しているサーバ１０のＯＳ（第１のサーバＯＳ１３２、又は第２のサーバＯＳ１３３のいずれか）を「起動系」と呼び、もう一方の起動していないＯＳを「停止系」と呼ぶものとする。また、ＯＳ関連のファイルは、ＲＰＭ等のパッケージ形式で管理されていても良いし、個別に管理されていても良い（この実施形態では、ＯＳ関連のファイルは、パッケージ形式で管理されているものとする）。
【００２９】
アプリケーション１３４は、第１のサーバＯＳ１３２、又は第２のサーバＯＳ１３３が共通に使用するアプリケーションプログラムである。例えば、アプリケーション１３４は、サーバ１０が、ＳＩＰサーバとして機能する場合には、ＳＩＰサーバとして機能させるプログラムが該当する。また、サーバ１０が、データベースサーバとして機能する場合には、データベースサーバとして機能させるプログラムが該当する。
【００３０】
その他１３５は、第１のサーバＯＳ１３２、又は第２のサーバＯＳ１３３が共通に使用する領域であって、例えば、第１のサーバＯＳ１３２、及び第２のサーバＯＳ１３３のログを記憶させる領域である。例えば、第１のサーバＯＳ１３２、及び第２のサーバＯＳ１３３が、Ｌｉｎｕｘであれば、ｔｍｐディレクトリが該当する。
【００３１】
図３は、サーバ１０の制御系の機能的構成を示すブロック図である。
【００３２】
図３において、サーバ１０は、制御部１００を有する。この実施形態では、制御部１００は、記憶部１３に記憶されたＯＳを含む種々のプログラムをメモリ１２に展開し、ＣＰＵ１１により各プログラムを実行することにより実現されるが、実現方法はこれに限らず、サーバ１０のソフトウェア構成部の一部をハードウェアで実現しても良い（又はその逆でも良い）。いずれの手法で実現したとしても、サーバ１０の制御系の構成は、図３で示すものである。
【００３３】
制御部１００は、サーバ１０の機能を制御するものであり、本実施形態の特徴部分として、サーバ切り替え制御部１０１、ＯＳ切り替え制御部１０２、及びファイル更新制御部１０３を備える。
【００３４】
サーバ切り替え制御部１０１は、サーバ１０（１０−１、１０−２）をＳＢＹ系からＡＣＴ系（又はその逆）に切り替える制御を行う。例えば、サーバ１０−２（ＳＢＹ系）のサーバ切り替え制御部１０１は、サーバ１０−１（ＡＣＴ系）の障害を検知した場合には、サーバ１０−２をＳＢＹ系からＡＣＴ系に切り替える制御を行う。また、サーバ切り替え制御部１０１は、第１のサーバＯＳ１３２、又は第２のサーバＯＳ１３３のファイル更新を行う場合にも実行される（詳しい動作は、後述する）。
【００３５】
ＯＳ切り替え制御部１０２は、サーバ１０のＯＳを、第１のサーバＯＳ１３２、又は第２のサーバＯＳ１３３に切り替える制御を行うもの（先述のブートローダ１３１に相当するもの）である。この実施形態では、ＯＳ切り替え制御部１０２は、第１のサーバＯＳ１３２及び第２のサーバＯＳ１３３のファイル更新（アップデート）に伴い実行される（詳しい動作は、後述する）。
【００３６】
ファイル更新制御部１０３は、ＯＳ（第１のサーバＯＳ１３２及び第２のサーバＯＳ１３３）及びアプリケーションのファイル更新（アップデート）の制御を行うものである。例えば、ファイル更新制御部１０３は、通信部１４を介して、アプリケーション１３４のファイル更新の要求を外部から受信した場合には、図示しないファイル配信サーバから更新ファイルをダウンロードし、アプリケーション１３４のアップデートを行う。なお、更新ファイルは、例えば、ＵＳＢを介してサーバ１０へ提供されても良い。
【００３７】
次に、本実施形態の特徴部分であるＯＳのファイル更新手順の説明を行う。
【００３８】
ＯＳのファイル更新は、クラスタシステム１の２台のサーバ１０（第１サーバ、第２サーバ）の内、ＳＢＹ系のサーバ１０から実行される。例えば、第１サーバがＡＣＴ系で、第２サーバがＳＢＹ系の場合には、第２サーバからＯＳのファイル更新が実行される。
【００３９】
また、この実施形態では、第１サーバ及び第２サーバは、各々、二つのＯＳ（第１のサーバＯＳ１３２及び第２のサーバＯＳ１３３）を備える構成であり、いずれかのＯＳが起動系として動作し、もう一方のＯＳが停止系の状態となっている。ＳＢＹ系の第２サーバは、停止系のＯＳ（停止系のＯＳを起動系に切り替えて）からファイル更新を行う。例えば、第１のサーバＯＳ１３２が起動系で、第２のサーバＯＳ１３３が停止系であるものとする。この場合、ＳＢＹ系の第２サーバのＯＳ切り替え制御部１０２は、第２のサーバＯＳ１３３を起動系（第１のサーバＯＳ１３２を停止系）に切り替える。切り替え後、ファイル更新制御部１０３は、通信部を介して、図示しない配信サーバから予め取得したＯＳ関連のファイルを用いて、第２のサーバＯＳ１３３（起動系）のアップデートを行う。
【００４０】
ここまでの処理により、ＳＢＹ系の第２サーバの第２のサーバＯＳ１３３（起動系）は、最新のバージョンとなる。一方、第１のサーバＯＳ１３２は、最新から一世代前のバージョンのままである。このように、サーバ１０は、ＯＳのファイル更新が実行されるごとに、第１のサーバＯＳ１３２又は第２のサーバＯＳ１３３のいずれかを更新することになるために、言い換えれば、異なるＯＳのバージョンを常に保持することになる。一般的に、最新のバージョンは、不具合を伴う可能性も高い。よって、これ以前に起動系として動作していた１世代前のＯＳを保持（バックアップ）することは、不具合を治癒する手段として有効である。この実施形態では、最新のバージョンのＯＳに不具合が見つかった場合には、１世代前のＯＳである停止系のＯＳ（第１のサーバＯＳ１３２又は第２のサーバＯＳ１３３のいずれか）を、ＯＳ切り替え制御部１０２の切り替え制御により起動系に切り替えるだけで、不具合の存在しないＯＳ（１世代前のＯＳ）に戻すことが可能である。
【００４１】
ＳＢＹ系の第２サーバのＯＳファイル更新が終了した後、サーバ切り替え制御部１０１の制御により、第２サーバをＡＣＴ系として、第１サーバをＳＢＹ系とする。
【００４２】
そして、ＡＣＴ系からＳＢＹ系となった第１サーバについても、上記第２サーバで示した同様の手順により、第１のサーバＯＳ１３２又は第２のサーバＯＳ１３３のいずれかのファイル更新を行う。
【００４３】
（Ａ−２）実施形態の動作
次に、以上のような構成を有する実施形態のクラスタシステム１の動作を説明する。
【００４４】
（Ａ−２−１）ＯＳファイルの更新動作（アップデート）
図４は、クラスタシステムを構成する各サーバのＯＳ関連ファイルの更新動作を示す説明図である。図４において、左半分のステップＳ１、Ｓ４、Ｓ６、Ｓ７は、第１サーバ（サーバ１０−１）の状態を示している。また、図４において、右半分のステップＳ２、Ｓ３、Ｓ５、Ｓ８は、第２サーバ（サーバ１０−２）の状態を示している。なお、ステップＳ１及びＳ２は、第１サーバ及び第２サーバの初期状態を示しており、実際のファイル更新の動作はステップＳ３から開始される。なお、この実施形態では、ＯＳをアップデートする更新ファイルは、予め配信サーバからダウンロードし、記憶部１３内（例えば、その他１３５−１、１３５−２）に保持されているものとする。
【００４５】
クラスタシステム１において、第１サーバがＡＣＴ系であって、第２サーバがＳＢＹ系である（Ｓ１、Ｓ２）。また、第１サーバは、第１のサーバＯＳ１３２−１が起動系として起動している。同様に、第２サーバは、第１のサーバＯＳ１３２−２が起動系として起動している。
【００４６】
第２サーバ（ＳＢＹ系）のＯＳ切り替え制御部１０２は、ＯＳを第１のサーバＯＳ１３２−２から第２のサーバＯＳ１３３−２へ切り替える制御（リブート）を行う（Ｓ３）。切り替え後、第２サーバ（ＳＢＹ系）のファイル更新制御部１０３は、予め所得した更新ファイルを用いて、ＯＳのアップデートを行う。
【００４７】
一方、第２サーバ（ＳＢＹ系）がＯＳをアップデータしている間、第１サーバ（ＡＣＴ系）は、運用サーバとして稼働している（Ｓ４）。
【００４８】
先述のステップＳ３の処理の後（第２のサーバＯＳ１３３−２のファイル更新後）、第２サーバ（ＳＢＹ系）のサーバ切り替え制御部１０１は、第２サーバをＡＣＴ系として、第１サーバをＳＢＹ系とするサーバの切り替え制御を行う（Ｓ５、Ｓ６）。
【００４９】
ＡＣＴ系からＳＢＹ系に切り替わった第１サーバは、先述のステップＳ３と同様の手順によりファイル更新を行う（Ｓ７）。具体的には、第１サーバ（ＳＢＹ系）のＯＳ切り替え制御部１０２は、ＯＳを第１のサーバＯＳ１３２−１から第２のサーバＯＳ１３３−１へ切り替える制御（リブート）を行う。切り替え後、第１サーバ（ＳＢＹ系）のファイル更新制御部１０３は、予め所得した更新ファイルを用いて、ＯＳのアップデートを行う。
【００５０】
一方、第１サーバ（ＳＢＹ系）がＯＳをアップデータしている間、第２サーバ（ＡＣＴ系）は、運用サーバとして稼働している（Ｓ８）。
【００５１】
（Ａ−２−２）ＯＳファイルの戻し動作（ダウングレード）
次に、クラスタシステム１の各サーバ（第１サーバ、第２サーバ）ＯＳ更新後、更新したファイルの不具合（バグ）により、各サーバのＯＳを更新前の状態に復旧させる処理について説明する。
【００５２】
図５は、クラスタシステムを構成する各サーバのＯＳ関連ファイルの戻し動作を示す説明図である。図５において、左半分のステップＳ９、Ｓ１１、Ｓ１４は、第１サーバ（サーバ１０−１）の状態を示している。また、図５において、右半分のステップＳ１０、Ｓ１２、Ｓ１３は、第２サーバ（サーバ１０−２）の状態を示している。なお、図５のステップＳ９からの処理は、先述のステップＳ８から続く処理である。すなわち、Ｓ９の直前のクラスタシステムは、第１サーバがＳＢＹ系であって、第２サーバがＡＣＴ系である。また、第１サーバは、ファイル更新済み（最新版）の第２のサーバＯＳ１３３−１が、起動系として動作している。同様に、第２サーバは、ファイル更新済み（最新版）の第２のサーバＯＳ１３３−２が起動系として動作している。なお、第１サーバの停止系の第１のサーバＯＳ１３２−１は、不具合の最新版から１世代前のＯＳ（言い換えれば、不具合の無い安定した版）である。第２サーバの停止系の第１のサーバＯＳ１３２−２も同様である。
【００５３】
第１サーバ（ＳＢＹ系）のＯＳ切り替え制御部１０２は、ＯＳを第２のサーバＯＳ１３３−１から、第１のサーバＯＳ１３２−１へ切り替える制御（リブート）を行う（Ｓ９）。このＯＳ切り替え処理により、第２サーバ（ＳＢＹ系）のＯＳは、安定的な一世代前のＯＳ（ダウングレードしたＯＳ）となる。
【００５４】
一方、第１サーバ（ＳＢＹ系）がＯＳをダウングレードしている間、第２サーバ（ＡＣＴ系）は、運用サーバとして稼働している（Ｓ１０）。
【００５５】
先述のステップＳ９の処理の後、第１サーバ（ＳＢＹ系）のサーバ切り替え制御部１０１は、第１サーバをＡＣＴ系として、第２サーバをＳＢＹ系とするサーバの切り替え制御を行う（Ｓ１１、Ｓ１２）。
【００５６】
ＡＣＴ系からＳＢＹ系に切り替わった第２サーバは、先述のステップＳ９と同様の手順によりダウングレードを行う（Ｓ１３）。具体的には、第２サーバ（ＳＢＹ系）のＯＳ切り替え制御部１０２は、ＯＳを第２のサーバＯＳ１３３−２から、第１のサーバＯＳ１３２−２へ切り替える制御（リブート）を行う。
【００５７】
一方、第２サーバ（ＳＢＹ系）がＯＳをダウングレードしている間、第１サーバ（ＡＣＴ系）は、運用サーバとして稼働している（Ｓ１４）。
【００５８】
以上により、クラスタシステム１の第１サーバ及び第２サーバは、１世代前の安定的なＯＳで起動している状態となる。
【００５９】
なお、復旧完了後、バグの存在する第２のサーバＯＳ１３３（ＯＳ１３３−１、ＯＳ１３３−２）について、第１サーバ及び第２サーバは、第１のサーバＯＳ１３２（ＯＳ１３２−１、ＯＳ１３２−２）内容に書き換える処理（例えば、ディスクコピー）を行っても良い。
【００６０】
（Ａ−３）実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。
【００６１】
クラスタシステム１の各サーバ１０は、記憶部１３内の各パーティションに２個のＯＳ（第１のサーバＯＳ１３２、第２のサーバＯＳ１３３）を設けることにより、一方のＯＳをファイル更新により最新版とし、他方のＯＳを１世代前の状態で保持することが可能となった。
【００６２】
これにより、例えば、最新版としたＯＳのファイルに不具合が生じた場合には、各サーバ１０は、ＯＳ切り替え制御部１０２により、１世代前のＯＳに切り替える（リブート）ことにより、容易に復旧できる。つまり、サーバ１０は、ＯＳのファイルをパッケージ単位で管理していた場合においても、不具合のあるパッケージ（ファイル）と他のパッケージとの依存関係を考慮する必要無く（また、再インストールする必要も無く）容易に復旧することができる。以下、図６を挙げて説明する。
【００６３】
図６は、クラスタシステムの各サーバのＯＳの版（バージョン）が、ファイル更新（アップデート）、及びファイル戻し（ダウングレード）を実行する毎に変化する様子をイメージ化した説明図である。なお、図６では、サーバ１０の記憶部１３内の第１のサーバＯＳ１３２及び第２のサーバＯＳ１３３のみ図示している。
【００６４】
図６（Ａ）では、初期状態であるため、各サーバ１０の第１のサーバＯＳ１３２及び第２のサーバＯＳ１３３のＯＳのバージョンは、「Ｖ１」で同一である。
【００６５】
図６（Ｂ）では、第２のサーバＯＳ１３３を更新したために、起動している第２のサーバＯＳ１３３のＯＳのバージョンは、「Ｖ２」となる。一方、停止した第１のサーバＯＳ１３２のＯＳのバージョンは、「Ｖ１」のままである。
【００６６】
図６（Ｃ）では、第１のサーバＯＳ１３２を更新したために、起動している第１のサーバＯＳ１３２のＯＳのバージョンは、「Ｖ３」となる。一方、停止した第２のサーバＯＳ１３３のＯＳのバージョンは、「Ｖ２」のままである。
【００６７】
ここで、第１のサーバＯＳ１３２のＯＳ（Ｖ３）に不具合の混入が認められると、起動しているＯＳを切り替えることになる。そうすると、図６（Ｄ）では、起動している第２のサーバＯＳ１３３のＯＳのバージョンは、「Ｖ２」である。一方、停止した第１のサーバＯＳ１３２のＯＳのバージョンは、不具合のある「Ｖ３」のままである。
【００６８】
図６（Ｅ）では、不具合のあるＶ３を除去するために、停止している第１のサーバＯＳ１３２のＯＳのバージョンを、「Ｖ３→Ｖ２」とする（Ｖ２の第２のサーバＯＳ１３３をコピーする）。これにより、サーバ１０は、通常通りアップデータすることが可能となる。
【００６９】
図６（Ｆ）では、第１のサーバＯＳ１３２を更新したために、起動している第１のサーバＯＳ１３２のＯＳのバージョンは、「Ｖ４」となる。一方、停止した第２のサーバＯＳ１３３のＯＳのバージョンは、「Ｖ２」のままである。
【００７０】
以上、本実施形態のクラスタシステム１は、更新したＯＳに不具合が生じたとしても、容易に不具合の存在しない状態に短時間に復旧することができ、サービスに影響を与えること無くシステムを運用することができる。
【００７１】
（Ｂ）他の実施形態
本発明は、上記実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【００７２】
（Ｂ−１）上記実施形態では、ファイル更新制御部１０３によりＯＳのファイル更新を行う際、各サーバ１０は、ＯＳ切り替え制御部１０２を用いて、現在停止系のＯＳ（第１のサーバＯＳ１３２又は第２のサーバＯＳ１３３）を起動系に切り替えた後、ファイル更新する処理を行っていた（図４のステップＳ３、Ｓ７）。変形例として、ファイル更新制御部１０３が、現在起動しているＯＳだけでは無く、現在停止しているＯＳのファイル更新も実行できる場合には、各サーバ１０は、停止系のＯＳ（第１のサーバＯＳ１３２又は第２のサーバＯＳ１３３）のファイル更新を実行した後、ＯＳ切り替え制御部１０２を用いて、現在停止系のＯＳ（第１のサーバＯＳ１３２又は第２のサーバＯＳ１３３）を起動系に切り替ても良い。
【００７３】
（Ｂ−２）上記実施形態では、各サーバ１０は、２個のＯＳ（第１のサーバＯＳ１３２及び第２のサーバＯＳ１３３）を用いてファイル更新を行う例を示した。変形例として、各サーバ１０は、３個以上のＯＳを用いてファイル更新を行っても良い。例えば、３個のＯＳを所持している場合には、ファイル更新を行うと、起動系のＯＳと、第１の停止系ＯＳ、及び第２の停止系ＯＳについて、それぞれ異なるバージョンのＯＳを所持することになる。つまり、起動系のＯＳに不具合が生じた場合には、最新の不具合の存在するバージョンから１世代前だけでなく、２世代前のＯＳに切り替えることができる。
【符号の説明】
【００７４】
１…クラスタシステム、１０（１０−１、１０−２）…サーバ、１１（１１−１、１１−２）…ＣＰＵ、１２（１２−１、１２−２）…メモリ、１３（１３−１、１３−２）…記憶部、１４（１４−１、１４−２）…通信部、１００…制御部、１０１…サーバ切り替え制御部、１０２…ＯＳ切り替え制御部、１０３…ファイル更新制御部、１３１（１３１−１、１３１−２）…ブートローダ、１３２（１３２−１、１３２−２）…第１のサーバＯＳ、１３３（１３３−１、１３３−２）…第２のサーバＯＳ、１３４（１３４−１、１３４−２）…アプリケーション、１３５（１３５−１、１３５−２）…その他。
【図１】
2018018328.tif 000003
【図２】
2018018328.tif 000004
【図３】
2018018328.tif 000005
【図４】
2018018328.tif 000006
【図５】
2018018328.tif 000007
【図６】
2018018328.tif 000008