JP2022130200A - コンテナ管理方法およびコンテナ管理プログラム - Google Patents

Abstract

【課題】マルチクラスタ環境における障害の早期対処を実現することを課題とする。【解決手段】コンテナが複数のクラスタに分散されているコンテナシステムで実行されるコンテナ管理方法において、第一のクラスタ内に配備されている第一のコンテナが、第一のクラスタとは異なる第二のクラスタに配備されている第二のコンテナの状態監視を実行し、状態監視の結果に応じて、第二のクラスタとは異なる第三のクラスタに、第二のコンテナのフェイルオーバの実行を指示する。【選択図】図３

Description

本発明は、コンテナ管理方法およびコンテナ管理プログラムに関する。

近年、Kubernetes（登録商標）などのように、多数のコンテナアプリケーション（以下では、「コンテナ」と記載する場合がある）を管理する基盤（以下では、「コンテナ基盤」と記載する場合がある）を用いて、コンテナを動作させるシステムが利用されている。このようなシステムは、スケジューラがコンテナの死活監視を実行し、障害により停止したコンテナが発生した場合に、別のコンテナを生成して動作させることで、システムの可用性を向上させている。

特開２０１９－１４９１９２号公報

ところで、システムの可用性をさらに高めるために、コンテナを利用したマルチクラスタ構成も考えられる。複数のクラスタを管理するために、特定のクラスタ（マスタクラスタ）にマスタスケジューラを配備し、各クラスタにはスケジューラを配備する。そして、マスタスケジューラが各クラスタのスケジューラを管理し、各クラスタのスケジューラがコンテナの実行や管理を行う。

このようなマルチクラスタ構成において障害が発生した場合に、障害場所を特定できず、障害の早期検知ができない。例えば、クラスタ全体の障害が発生すると、当該クラスタのスケジューラでは対処できないので、マスタスケジューラが当該クラスタ上の全コンテナを別のクラスタにフェイルオーバさせる必要がある。しかしながら、マスタスケジューラは、各コンテナを直接監視出来ないので、各クラスタ内のスケジューラを監視することになるが、各クラスタのスケジューラだけの障害か、クラスタ全体の障害かを区別することができない。そのため、障害場所を特定するまでに多くの時間がかかり、障害検知が遅くなり、システムの信頼性が低下する。

一つの側面では、マルチクラスタ環境における障害の早期対処を実現することができるコンテナ管理方法およびコンテナ管理プログラムを提供することを目的とする。

第１の案では、コンテナが複数のクラスタに分散されているコンテナシステムで実行されるコンテナ管理方法において、第一のクラスタ内に配備されている第一のコンテナが、
前記第一のクラスタとは異なる第二のクラスタに配備されている第二のコンテナの状態監視を実行し、前記状態監視の結果に応じて、前記第二のクラスタとは異なる第三のクラスタに、前記第二のコンテナのフェイルオーバの実行を指示する、ことを特徴とする。

一実施形態によれば、マルチクラスタ環境における障害の早期対処を実現することができる。

図１は、実施例１にかかるコンテナシステムの全体構成例を示す図である。 図２は、実施例１にかかるコンテナシステムの相互監視を説明する図である。 図３は、実施例１にかかるコンテナシステムの障害対応例を説明する図である。 図４は、実施例２にかかる各クラスタの全体構成例を示す図である。 図５は、実施例２にかかるマスタサーバとクラスタサーバの機能構成を示す機能ブロック図である。 図６は、稼働情報管理ＤＢに記憶される情報の例を示す図である。 図７は、フェイルオーバ先ＤＢに記憶される情報の例を示す図である。 図８は、実施例２にかかるコンテナシステム内の各コンテナの機能構成を説明する図である。 図９は、コンテナ情報管理テーブルに記憶される情報の例を示す図である。 図１０は、コンテナ間の監視を説明する図である。 図１１は、障害検出を説明する図である。 図１２は、フェイルオーバを説明する図である。 図１３は、フェイルオーバ後の稼働情報の収集を説明する図である。 図１４は、実施例２にかかるフェイルオーバ処理の流れを示すフローチャートである。 図１５は、実施例３にかかるフェイルオーバ処理後の遅延による性能劣化時の流れを示すフローチャートである。 図１６は、実施例４にかかるフェイルオーバ処理後の縮退による性能劣化時の流れを示すフローチャートである。 図１７は、重複クラスタ数によるフェイルオーバ先の特定処理の流れを示すフローチャートである。 図１８は、非重複クラスタ数によるフェイルオーバ先の特定処理の流れを示すフローチャートである。 図１９は、通信遅延量によるフェイルオーバ先の特定処理の流れを示すフローチャートである。 図２０は、ハードウェア構成例を説明する図である。

以下に、本願の開示するコンテナ管理方法およびコンテナ管理プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

［全体構成］
図１は、実施例１にかかるコンテナシステムの全体構成例を示す図である。図１に示すように、実施例１にかかるコンテナシステムは、複数の物理サーバや物理サーバ上で動作する仮想マシン（VM：Virtual Machine）により提供されるマルチクラスタで構成される。図１の例では、クラスタ１からクラスタ５の５つのクラスタリングシステムが実行されている一例を図示している。また、各クラスタは、１台以上の物理サーバまたは１台以上のＶＭにより提供されるとともに、それぞれが異なる物理サーバやＶＭで提供されている。また、コンテナシステムでは、一例としてKubernetes（登録商標）を用いて、コンテナが実行されているものとする。

図１に示すように、クラスタ１には、マスタスケジューラ、コンテナＡ１、コンテナＣ１が配備される。クラスタ２には、スケジューラ、コンテナＡ２、コンテナＢ２、コンテナＣ２が配備され、クラスタ３には、スケジューラ、コンテナＢ３が配備される。クラスタ４には、スケジューラ、コンテナＡ４、コンテナＢ４、コンテナＣ４が配備され、クラスタ５には、スケジューラ、コンテナＢ５、コンテナＣ５が配備される。

マスタスケジューラは、各スケジューラからのデータ受信により、各クラスタの死活監視やスケジューラが監視したクラスタの死活監視結果などを管理し、クラスタやコンテナの制御を実行する。なお、従来から利用されるKubernetes（登録商標）では、マスタスケジューラは、各クラスタの各コンテナを直接管理することができない。したがって、マスタスケジューラは、あるクラスタのスケジューラの異常を検出すると、当該あるクラスタ、あるクラスタ内のコンテナ、あるクラスタ内のスケジューラのいずれに異常があるか特定できず、あるクラスタ内の全コンテナをフェイルオーバさせる必要がある。

各スケジューラは、各クラスタ内のコンテナに関する制御を実行する。例えば、各スケジューラは、同一クラスタ内のコンテナの稼働状況を管理し、死活情報をマスタスケジューラに通知する。マスタスケジューラは、各コンテナのスケジューラとの間で死活監視を実行し、各クラスタの死活状況や各クラスタ内のコンテナの稼働状況を管理する。

各コンテナは、同種のコンテナとコンテナグループを構成し、同種の１つまたは複数のコンテナと連携して各種サービスを実行する。例えば、コンテナＡ１とコンテナＡ２とコンテナＡ３とは同じサービスを提供するコンテナグループＡに属し、相互にレプリカの関係である。また、コンテナＢ２とコンテナＢ３とコンテナＢ４とコンテナＢ５とは同じサービスを提供するコンテナグループＢに属し、相互にレプリカの関係である。また、コンテナＣ１とコンテナＣ２とコンテナＣ４とコンテナＣ５とは同じサービスを提供するコンテナグループＣに属し、相互にレプリカの関係である。このようにすることで、同一コンテナグループに属するコンテナ同士は常に連携を行っているため、本発明のための通信を行うための接続を改めて設定する必要がないという効果がある。

また、各クラスタ内では、各コンテナのイメージデータを共有しており、各スケジューラが、同一クラスタ内で稼働中（動作中）のコンテナを停止させたり、任意のコンテナを配備したりすることができる。

このような構成において、各コンテナは、同じコンテナグループに属する他のコンテナの相互監視を実行する。図２は、実施例１にかかるコンテナシステムの相互監視を説明する図である。図２に示すように、例えば、クラスタ１のコンテナＡ１は、クラスタ２のコンテナＡ２およびクラスタ４のコンテナＡ４の死活監視を実行し、クラスタ２のコンテナＡ１は、クラスタ１のコンテナＡ１およびクラスタ４のコンテナＡ４の死活監視を実行し、クラスタ４のコンテナＡ４は、クラスタ２のコンテナＡ２およびクラスタ１のコンテナＡ１の死活監視を実行する。

そして、各コンテナは、他のコンテナの障害を検出すると、自コンテナが動作するクラスタを含む正常動作中のクラスタに、障害が検出されたコンテナをフェイルオーバさせる。図３は、実施例１にかかるコンテナシステムの障害対応例を説明する図である。図３に示すように、クラスタ４のコンテナＡ４は、クラスタＡ２のコンテナＡ２の障害を検出した場合、自クラスタ４であるスケジューラに対して、クラスタ４にコンテナＡ２をフェイルオーバさせる指示を出力する。

このように、コンテナシステムは、クラスタ全体に影響する障害が発生し、当該クラスタ内のスケジューラが障害の検知や対処を行うことができない場合であっても、他クラスタ内のコンテナが障害を検知することができるので、障害の早期検知を実現することができる。

本実施例においては、説明を簡略化するために、１台の物理サーバが１つのクラスタを実行する例で説明するが、構成手法や形式等を限定するものではない。

図４は、実施例２にかかる各クラスタの全体構成例を示す図である。図４に示すように、マスタサーバ１００がクラスタ１を動作させ、クラスタサーバ２００がクラスタ２を動作させ、クラスタサーバ３００がクラスタ３を動作させ、クラスタサーバ４００がクラスタ４を動作させ、クラスタサーバ５００がクラスタ５を動作させる。なお、各クラスタで動作するコンテナなどは、実施例１と同様なので、詳細な説明は省略する。

このような構成において、マスタサーバおよび各クラスタサーバは、同一のクラスタ内に配備する第一のコンテナであって、第一のクラスタとは異なる第二のクラスタに配備されている第二のコンテナの状態監視を実行し、状態監視の結果に応じて、第二のクラスタに、第二のコンテナのフェイルオーバの実行を指示する、第一のコンテナを動作させる。

つまり、各クラスタ内で動作する各コンテナは、クラスタ間を跨いで、同じコンテナグループのコンテナの死活監視を実行し、停止したコンテナを検出すると、停止したコンテナを別のクラスタにフェイルオーバさせることができる。この結果、コンテナシステムは、クラスタ全体に影響する障害が発生し、当該クラスタ内のスケジューラが障害の検知や対処を行うことができない場合であっても、他クラスタ内のコンテナが障害を検知することができるので、障害の早期検知を実現することができる。

［コンテナシステムの機能構成］
次に、コンテナシステムを構成する各サーバの機能構成を説明する。なお、各クラスタサーバは、同様の構成を有するので、ここではクラスタサーバ２００について説明する。図５は、実施例２にかかるマスタサーバとクラスタサーバの機能構成を示す機能ブロック図である。

（マスタサーバの機能構成）
図５に示すように、マスタサーバ１００は、通信部１０１、記憶部１０２、制御部１１０を有する。

通信部１０１は、他の装置との間の通信を制御する処理部であり、例えば通信インタフェースなどにより実現される。例えば、通信部１０１は、マスタサーバ１００と他のクラスタサーバそれぞれとの通信を制御することで、クラスタ１と他クラスタとの間で各種データ等の送受信を実行する。

記憶部１０２は、各種データや制御部１１０が実行するプログラムなどを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどにより実現される。この記憶部１０２は、クラスタ１で動作するマスタスケジューラや各コンテナがアクセス可能なデータとして、イメージファイルＤＢ１０３と稼働情報管理ＤＢ１０４を記憶する。

イメージファイルＤＢ１０３は、各コンテナのイメージファイルを記憶するデータベースである。例えば、イメージファイルＤＢ１０３は、コンテナごとに、当該コンテナを起動させることができる情報を含むイメージファイルを記憶する。なお、このイメージファイルは、コンテナシステム内の各クラスタで共通に保持されている。

稼働情報管理ＤＢ１０４は、コンテナシステムに配備されている各コンテナの稼働情報を記憶するデータベースである。図６は、稼働情報管理ＤＢ１０４に記憶される情報の例を示す図である。図６に示すように、稼働情報管理ＤＢ１０４は、「クラスタＩＤ、コンテナＩＤ、リソース使用率、サービス時間、フェイルオーバ」を記憶する。

ここで記憶される「クラスタＩＤ」は、各クラスタを識別する識別子であり、「コンテナＩＤ」は、各コンテナを識別する識別子である。「リソース使用率」は、コンテナが使用しているプロセッサ、メモリ、ハードウェアなどの各リソースの使用率である。例えば、「リソース使用率」は、コンテナに割り当てられたハードウェアのリソースのうちどのくらいのリソースを使用中かを示す割合でもよく、コンテナがクラスタ内のリソースのうちどのくらいのリソースを使用中かを示す割合でもよい。「サービス時間」は、コンテナが提供しているサービスの継続時間である。「フェイルオーバ」は、フェイルオーバされたコンテナか否かを識別する情報である。

図６の例では、クラスタ１で動作するコンテナＡ１は、リソース使用率が８０％、サービス時間１０ｍｓであることを示している。また、クラスタ１で動作するコンテナＢ１は、フェイルオーバされたコンテナであり、リソース使用率が６５％、サービス時間４ｍｓであることを示している。なお、稼働情報管理ＤＢ１０４は、マスタサーバ１００内で、他のクラスタサーバの各コンテナ等からアクセス可能に設置される。また、稼働情報管理ＤＢ１０４は、コンテナシステム内で共有のＤＢサーバなどに配備されてもよい。

制御部１１０は、マスタサーバ１００全体を司る処理部であり、例えばプロセッサなどにより実現される。例えば、制御部１１０は、クラスタ実行部１１１、スケジュール実行部１１２、コンテナ実行部１１３を有する。なお、クラスタ実行部１１１、スケジュール実行部１１２、コンテナ実行部１１３は、プロセッサが有する電子回路やプロセッサが実行するプロセスなどにより実現される。

クラスタ実行部１１１は、マスタサーバ１００内のプロセッサやメモリなどのハードウェアリソースを用いて、クラスタ環境を提供する処理部である。例えば、クラスタ実行部１１１は、公知のクラスタリングシステムを用いてクラスタ１を提供する。

スケジュール実行部１１２は、クラスタ実行部１１１が提供するクラスタ１内でマスタスケジューラを実行する処理部である。例えば、スケジュール実行部１１２は、クラスタ１で、後述する機能を有するマスタスケジューラを実行する。

コンテナ実行部１１３は、クラスタ実行部１１１が提供するクラスタ１内でコンテナを実行する処理部である。例えば、コンテナ実行部１１３は、クラスタ１で、マスタスケジューラの指示にしたがって、後述する機能を有するコンテナＡ１、コンテナＣ１を実行する。

（クラスタサーバの機能構成）
図５に示すように、クラスタサーバ２００は、通信部２０１、記憶部２０２、制御部２１０を有する。

通信部２０１は、他の装置との間の通信を制御する処理部であり、例えば通信インタフェースなどにより実現される。例えば、通信部２０１は、クラスタサーバ２００と他のクラスタサーバそれぞれとの通信、および、クラスタサーバ２００とマスタサーバ１００との通信を制御することで、クラスタ２と他クラスタとの間で各種データ等の送受信を実行する。

記憶部２０２は、各種データや制御部２１０が実行するプログラムなどを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどにより実現される。この記憶部２０２は、クラスタ２で動作するスケジューラや各コンテナがアクセス可能なデータとして、イメージファイルＤＢ２０３とフェイルオーバ先ＤＢ２０４を記憶する。

イメージファイルＤＢ２０３は、各コンテナのイメージファイルを記憶するデータベースである。ここで記憶される情報は、マスタサーバ１００のイメージファイルＤＢ１０３と同様である。

フェイルオーバ先ＤＢ２０４は、各コンテナグループのフェイルオーバ先を記憶するデータベースである。図７は、フェイルオーバ先ＤＢ２０４に記憶される情報の例を示す図である。図７に示すように、フェイルオーバ先ＤＢ２０４は、「コンテナグループ、フェイルオーバ先」を記憶する。

ここで記憶される「コンテナグループ」は、フェイルオーバ対象のコンテナグループを示し、「フェイルオーバ先」は、フェイルオーバ先と指定されたクラスタを示す。図７の例では、コンテナグループＡに属する各コンテナのフェイルオーバ先として、コンテナグループＢが選択されており、コンテナグループＢのコンテナＢｎが配備される各クラスタのうちクラスタ３がフェイルオーバ先に設定されていることを示す。

なお、フェイルオーバ先は、制御部２１０によって決定される。例えば、制御部２１０は、ある同一コンテナグループ（対象グループ）に関して、配備先クラスタに２以上の重複があり、かつ重複しないレプリカ数が最大となるグループを選定する。そして、制御部２１０は、重複レプリカを除き、選定されたグループ内で、対象グループの各コンテナからの通信遅延の平均が最小となるクラスタを、対象グループのフェイルオーバ先として決定する。

制御部２１０は、クラスタサーバ２００全体を司る処理部であり、例えばプロセッサなどにより実現される。例えば、制御部２１０は、クラスタ実行部２１１、スケジュール実行部２１２、コンテナ実行部２１３を有する。なお、クラスタ実行部２１１、スケジュール実行部２１２、コンテナ実行部２１３は、プロセッサが有する電子回路やプロセッサが実行するプロセスなどにより実現される。

クラスタ実行部２１１は、クラスタサーバ２００内のプロセッサやメモリなどのハードウェアリソースを用いて、クラスタ環境を提供する処理部である。例えば、クラスタ実行部２１１は、公知のクラスタリングシステムを用いてクラスタ２を提供する。

スケジュール実行部２１２は、クラスタ実行部２１１が提供するクラスタ２内でスケジューラを実行する処理部である。例えば、スケジュール実行部２１２は、クラスタ２で、後述する機能を有するスケジューラを実行する。

コンテナ実行部２１３は、クラスタ実行部２１１が提供するクラスタ２内でコンテナを実行する処理部である。例えば、コンテナ実行部２１３は、クラスタ２で、マスタスケジューラやスケジューラの指示にしたがって、後述する機能を有するコンテナＡ２、コンテナＢ２、コンテナＣ２を実行する。

［コンテナの機能］
次に、コンテナシステムで実行される各コンテナの機能構成を説明する。なお、各クラスタサーバ内の各コンテナは、同様の構成を有するので、ここではクラスタサーバ２００について説明する。図８は、実施例２にかかるコンテナシステム内の各コンテナの機能構成を説明する図である。なお、各クラスタで実行される各コンテナは、図４のとおりとする。

（クラスタ１）
図４に示すように、クラスタ１では、マスタスケジューラと、コンテナＡ１と、コンテナＣ１とが実行されるが、ここではマスタスケジューラについて説明する。なお、コンテナＡ１とコンテナＣ１は、クラスタ２のコンテナと同様の構成を有するので、ここでは詳細な説明は省略する。

図８に示すように、クラスタ１のマスタスケジューラ１３０は、死活情報取得部１３１と稼働情報取得部１３２を有する。なお、マスタスケジューラ１３０は、同一クラスタ１内で、イメージファイルＤＢ１０３の記憶される情報を用いて各コンテナを生成したり（起動中）、各コンテナを稼働させたり（動作中）、各コンテナを停止させたりする（停止中）。

死活情報取得部１３１は、各クラスタの死活情報を取得して動作状態を管理する処理部である。例えば、死活情報取得部１３１は、同一クラスタ１内の各コンテナを定期的に監視して、死活情報を管理する。

また、死活情報取得部１３１は、各クラスタのスケジューラに、死活確認メッセージを定期的に送信し、その応答に基づき、各クラスタの状況を取得する。例えば、死活情報取得部１３１は、クラスタ２のスケジューラ２３０に死活確認メッセージを送信し、応答が受信できた場合には、クラスタ２が正常稼働中と判定し、応答が受信できない場合には、クラスタ２が異常と判定する。異常時は、Kubernetes（登録商標）で実装される機能により、クラスタやコンテナの回復等が実行される。

稼働情報取得部１３２は、複数クラスタに跨って配備されているコンテナシステムのサービス状態を監視する処理部である。例えば、稼働情報取得部１３２は、各スケジューラから、コンテナのリソース使用率やサービス時間を収集して、コンテナシステムのサービス状態を監視する。

（クラスタ２）
クラスタ２は、図４に示すように、スケジューラと、コンテナＡ２と、コンテナＢ２と、コンテナＣ２とが実行されるが、各コンテナは同様の構成を有するので、ここではスケジューラとコンテナＡ２について説明する。

図８に示すように、スケジューラ２３０は、コンテナ情報管理テーブル２３１、死活情報応答部２３２、死活情報取得部２３３、コンテナ制御部２３４、コンテナ情報取得部２３５を有する。

コンテナ情報管理テーブル２３１は、同一クラスタ内の各コンテナに関する情報を記憶する。具体的には、コンテナ情報管理テーブル２３１は、クラスタ２に配備された各コンテナについて、スケジューラ２３０により取得された情報を記憶する。

図９は、コンテナ情報管理テーブル２３１に記憶される情報の例を示す図である。図９に示すように、コンテナ情報管理テーブル２３１は、「コンテナＩＤ、死活、ステータス、障害情報を」を記憶する。「コンテナＩＤ」は、コンテナを識別する識別子である。「死活」は、コンテナの死活情報であり、正常時は「ＯＫ」、異常時は「ＮＧ」が設定される。「ステータス」は、コンテナのステータスを示す情報であり、動作中は「Running」、動作はしていないものの作成された状態である起動中は「Creating」、停止中は「Stop」が設定される。「障害情報」は、障害の発生状態を示している。

図９の例では、クラスタ２では、コンテナＡ２、コンテナＢ２、コンテナＣ２が配備されており、コンテナＡ２が動作中、コンテナＢ２が動作はしていないものの起動中、コンテナＣ２が停止中であることを示している。また、コンテナＢ２は、サービスを提供していない状態であるものの、他クラスタからコンテナグループＡに属するコンテナの障害を検出した状態であることを示している。

死活情報応答部２３２は、自身が管理するクラスタ内で動作するコンテナなどを示す各ワーカノードの死活状態を確認して応答する処理部である。例えば、死活情報応答部２３２は、クラスタ２内の各コンテナの死活状態を監視し、マスタスケジューラ１３０から受信した死活確認メッセージの応答として、各コンテナの死活状態を応答する。

死活情報取得部２３３は、ワーカノード上のクラスタの死活状態を取得する処理部である。例えば、死活情報取得部２３３は、同一クラスタ２内の各コンテナに、死活確認メッセージを定期的に送信し、その応答に基づき、各クラスタの状況を取得する。そして、死活情報取得部２３３は、取得した情報に基づき、コンテナ情報管理テーブル２３１を更新する。

コンテナ制御部２３４は、ワーカノード上で、コンテナの起動、停止、配備（作成）、削除など、コンテナに関する各種の処理を実行する処理部である。また、コンテナ制御部２３４は、後述するコンテナ情報取得部２３５等の指示により、別のクラスタ内のコンテナのフェイルオーバを実行して、クラスタ２内で当該コンテナを動作させる。

コンテナ情報取得部２３５は、コンテナグループ間連携によって更新される情報を取得する処理部である。例えば、コンテナ情報取得部２３５は、コンテナＡ２によって他クラスタ内のあるコンテナの障害が検出されると、当該あるコンテナのフェイルオーバを実行する。

すなわち、コンテナ情報取得部２３５は、当該あるコンテナをクラスタ２で実行させるために、当該あるコンテナの配備および動作をコンテナ制御部２３４に要求することで、当該あるコンテナのフェイルオーバを実現する。このとき、コンテナ情報取得部２３５は、コンテナ情報管理テーブル２３１を更新する。

図８に戻り、コンテナＡ２は、死活情報応答部２４１、稼働情報登録部２４２、グループ間処理部２４３を有する。

死活情報応答部２４１は、自コンテナの死活状態を確認して応答する処理部である。例えば、死活情報応答部２４１は、死活情報取得部２３３から受信した死活確認メッセージに対して、コンテナＡ２の死活状態を応答する。

稼働情報登録部２４２は、自コンテナの稼働情報を取得して、クラスタ１内の稼働情報管理ＤＢ１０４を更新する処理部である。例えば、稼働情報登録部２４２は、コンテナＡ４のリソース使用率やサービス時間を収集して、集中した情報で稼働情報管理ＤＢ１０４を直接的に更新したり、収集した情報をマスタスケジューラ１３０に送信して稼働情報管理ＤＢ１０４を間接的に更新したりする。

グループ間処理部２４３は、コンテナグループ間連携によって更新された情報を保持し、コンテナグループ間の情報交換を実行する処理部である。例えば、グループ間処理部２４３は、コンテナシステムで動作するコンテナのうち、コンテナＡ２が属するコンテナグループＡの各コンテナとの間で監視メッセージを送受信して、相互に死活監視を実行する。

そして、グループ間処理部２４３は、クラスタ４のコンテナＡ４の停止を検出した場合、フェイルオーバ先ＤＢ２０４のフェイルオーバ先にしたがってフェイルオーバを実行する。例えば、グループ間処理部２４３は、同一クラスタ２内のコンテナＢ２に、クラスタ４のコンテナＡ４が停止したことを通知する。すると、コンテナＢ２のグループ間処理部は、クラスタ３のコンテナＢ３にコンテナＡ４が停止したことを通知する。そして、コンテナＢ３のグループ間処理部は、クラスタ３のスケジューラにコンテナＡ４の停止を通知し、クラスタ３のスケジューラがコンテナＡ４を生成して動作させることで、フェイルオーバが完了する。

このように、マスタスケジューラ１３０では検出できないコンテナ異常が発生した場合であっても、同一コンテングループでクラスタを跨って相互に監視することで、コンテナ異常を検出することができる。また、コンテナ異常検出時は、検出したコンテンが、予め決定しておいたフェイルオーバ先に通知することで、遅滞なく、フェイルオーバを完了することができる。

また、グループ間処理部２４３は、コンテナグループ間の情報交換を実行することで、障害復旧を検出することもできる。例えば、フェイルオーバ先のグループ間処理部２４３がフェイルオーバ元の障害普及を検出すると、フェイルオーバ先のスケジューラ２３０が、フェイルオーバさせたコンテナを削除する。また、フェイルオーバ元のスケジューラは、障害発生前の各コンテナを配備して動作させる。この結果、コンテナの切り戻しが完了する。

なお、障害復旧の通知は、コンテナグループ間の情報交換に限らず、各スケジューラ間の情報交換で検出することもでき、マスタスケジューラ１３０が各スケジューラに通知することもでき、管理者が手動で各スケジューラに通知することもできる。

［具体例］
次に、図１０から図１３を用いて、フェイルオーバの具体例を説明する。図１０は、コンテナ間の監視を説明する図である。図１０に示すように、具体例に示すコンテナシステムは、クラスタ１、クラスタ２、クラスタ３、クラスタ４、クラスタ５を有する。

（構成）
クラスタ１には、マスタスケジューラ１３０とコンテナＡ１とコンテナＣ１が配備され、クラスタ２には、スケジューラ２３０とコンテナＡ２とコンテナＢ２とコンテナＣ２が配備され、クラスタ３には、スケジューラ３３０とコンテナＢ３が配備される。クラスタ４には、スケジューラ４３０とコンテナＡ４とコンテナＢ４とコンテナＣ４が配備され、クラスタ５には、スケジューラ５３０とコンテナＢ５とコンテナＣ５が配備される。

コンテナＡ１、コンテナＡ２、コンテナＡ３は、同じコンテナグループＡに属し、コンテナＢ２、コンテナＢ３、コンテナＢ４、コンテナＢ５は、同じコンテナグループＢに属し、コンテナＣ１、コンテナＣ２、コンテナＣ３、コンテナＣ４は、同じコンテナグループＣに属する。なお、マスタスケジューラ１３０は、図８で説明したマスタスケジューラ１３０と同様の機能を有する。スケジューラ２３０、スケジューラ３３０、スケジューラ４３０、スケジューラ５３０は、図８で説明したスケジューラ２３０と同様の機能を有する。

（相互監視）
このような構成において、各コンテナは、同一コンテナグループ内のコンテナ間で相互に死活監視を実行する。例えば、図１０に示すように、コンテナＡ１、コンテナＡ２、コンテナＡ４は、相互に監視する。なお、図１０では、コンテナグループＡを例示したが、コンテナＢ２、コンテナＢ３、コンテナＢ４、コンテナＢ５も相互に監視し、コンテナＣ１、コンテナＣ２、コンテナＣ４、コンテナＣ５も相互に監視する。

（障害検出）
次に、一例として、クラスタ４のコンテナＡ４がクラスタ２の障害を検出した例を説明する。図１１は、障害検出を説明する図である。図１１に示すように、コンテナＡ４は、クラスタ２のコンテナＡ２から、定期的に送信する死活確認メッセージの応答を受信できない場合に、クラスタ２またはコンテナＡ２の停止を検出する。すると、コンテナＡ４は、フェイルオーバ先ＤＢに記憶される情報にしたがって、フェイルオーバ先へ障害通知を実行する。

ここで、コンテナグループＡのフェイルオーバ先の決定例を説明する。まず、コンテナシステム内の複数のコンテナグループのうち、コンテナグループＡのコンテナＡｎ（ｎ＝１，２，・・・）と同じクラスタに配備されるクラスタの数である重複クラスタ数が閾値以上であるコンテナグループを特定する。例えば、コンテナグループＢについて、コンテナグループＡのコンテナと同じクラスタに属するコンテナの数を２（クラスタ２、クラスタ４）と特定される。同様に、コンテナグループＣについて、コンテナグループＡのコンテナＡｎと同じクラスタに属するコンテナの数を２（クラスタ２、クラスタ４）と特定される。この結果、コンテナグループＢとコンテナグループＣがフェイルオーバ先候補と特定される。コンテナグループＡに障害が発生した場合、コンテナグループＡに属するコンテナが障害を検知し、当該コンテナが、同一クラスタ内に存在する他のコンテナグループに属するコンテナに対して、フェイルオーバの依頼を行う。この時、障害を検知したコンテナと同じクラスタ内に、フェイルオーバの依頼を行うコンテナが存在する必要がある。上述の処理は、コンテナグループＡと同一のクラスタに存在していることの多いコンテナグループを、フェイルオーバの依頼を行う候補（フェイルオーバ先候補）として特定するものである。

次に、フェイルオーバ先候補のうち、コンテナグループＡのコンテナＡｎが配備されていないクラスタに配備されるクラスタの数である非重複クラスタ数が閾値以上であるコンテナグループを選択する。例えば、コンテナＡｎが配備されていないクラスタ３とクラスタ５を特定し、クラスタ３とクラスタ５のうち、コンテナグループＢのコンテナが配備されている非重複クラスタ数が２、コンテナグループＣのコンテナが配備されている非重複クラスタ数が１であることから、コンテナグループＢを移行先コンテナグループに決定する。これにより、障害発生時にフェイルオーバ先となる、コンテナＡｎが動作していないクラスタの候補が多くなるため、フェイルオーバ後のサービス性能への影響が小さいクラスタを実際のフェイルオーバ先として選択できる可能性が高まるという効果がある。

そして、移行先コンテナグループに属する各コンテナＢｎと、移行元であるコンテナグループＡに属する各コンテナＡｎとの平均遅延が最小となるコンテナが実行されるクラスタを移行先に決定する。例えば、遅延（Ａ１Ｂ３＋Ａ２Ｂ３＋Ａ４Ｂ３）＜遅延（Ａ１Ｂ５＋Ａ２Ｂ５＋Ａ４Ｂ５）の場合、クラスタ３がフェイルオーバ先に決定される。これにより、通信遅延を考慮したフェイルオーバ先の決定が可能となる。なお、遅延量の算出方法は、伝送時間などを用いた通信ネットワークの伝送遅延時間など公知の手法を採用することができる。

この結果、障害を検出したコンテナＡ４は、同一クラスタ４に配備されるコンテナのうち、移行先コンテナグループＢに属するコンテナＢ４に、クラスタ２のコンテナＡ２で障害が発生したことを通知する。そして、コンテナＢ４は、フェイルオーバ先のクラスタ３に配備される同一コンテナグループのコンテナＢ３に、クラスタ２のコンテナＡ２で障害が発生したことを通知する。その後、コンテナＢ３は、同一クラスタ内のスケジューラ３３０に、クラスタ２のコンテナＡ２で障害が発生したことを通知する。

（フェイルオーバ）
次に、フェイルオーバについて説明する。図１２は、フェイルオーバを説明する図である。図１２に示すように、クラスタ３のスケジューラ３３０は、コンテナＢ３から、クラスタ２のコンテナＡ２の障害発生が通知されると、イメージファイルＤＢからコンテナＡの情報を取得して、コンテナＡ３として配備した上で動作させる。この結果、コンテナグループＡは、障害発生前ではコンテナＡ１、コンテナＡ２、コンテナＡ４でサービスを提供していたが、障害発生後ではコンテナＡ１、コンテナＡ３、コンテナＡ４でサービス提供を継続することができる。

（稼働情報の収集）
その後は、マスタスケジューラ１３０が稼働情報を収集することで、コンテナシステム内でフェイルオーバが共有される。図１３は、フェイルオーバ後の稼働情報の収集を説明する図である。図１３に示すように、マスタスケジューラ１３０は、各クラスタの各スケジューラに定期的に死活監視メッセージを送信する。ここで、マスタスケジューラ１３０は、クラスタ２のスケジューラ２３０からの応答が検出できないことから、クラスタ２の障害を検出する。そして、マスタスケジューラ１３０は、クラスタ３のスケジューラ３３０から、配備されているコンテナ一覧の情報を取得することで、コンテナＡ４（コンテナＡ２）のフェイルオーバを検出する。このとき、マスタスケジューラ１３０は、各スケジューラから、各コンテナの稼働情報も取得する。

このようにして、マスタスケジューラ１３０は、稼働情報管理ＤＢ１０４を最新に更新する。また、各スケジューラは、自クラスタのコンテナ情報を定期的に取得することで、コンテナ情報管理テーブルを最新に維持する。

なお、上記例では、クラスタ２で障害が発生した場合のコンテナＡ２のフェイルオーバについて説明したが、クラスタ２内のコンテナＢ２およびコンテナＣ２についても同様の処理手順により、フェイルオーバが実行される。

［処理の流れ］
図１４は、実施例２にかかるフェイルオーバ処理の流れを示すフローチャートである。図１４に示すように、各コンテナは、監視タイミングに到達すると（Ｓ１０１：Ｙｅｓ）、同一コンテナグループ内のコンテナを選択し（Ｓ１０２）、死活監視メッセージを送信する（Ｓ１０３）。

そして、各コンテナは、死活監視メッセージへの応答を受信すると（Ｓ１０４：Ｙｅｓ）、同一コンテナグループ内で未選択のコンテナが存在するか否かを判定する（Ｓ１０５）。ここで、未選択のコンテナが存在しない場合（Ｓ１０５：Ｎｏ）、今回の監視タイミングにおける処理が終了する。

一方、未選択のコンテナが存在する場合（Ｓ１０５：Ｙｅｓ）、各コンテナは、Ｓ１０２以降に戻り、同一コンテナグループ内のコンテナを選択し、死活監視メッセージを送信する。

また、Ｓ１０４において、各コンテナのいずれかが、死活監視メッセージへの応答を受信できない場合（Ｓ１０４：Ｎｏ）、コンテナまたはクラスタの障害を検知し、フェイルオーバ処理が実行される（Ｓ１０６）。

例えば、コンテナＡ４は、死活監視メッセージの応答を受信できなかったコンテナＡ２について事前に選定されたコンテナグループＢの同一クラスタ内のコンテナＢ４に障害を通知する。そして、コンテナＢ４が、コンテナグループＢ間で障害情報を、フェイルオーバ先のクラスタ３に通知する。その後、クラスタ３のコンテナＢ３がコンテナ情報管理テーブルを更新したり、スケジューラ３３０に障害を通知したりする。この結果、クラスタ３のスケジューラ３３０は、コンテナ情報管理テーブルの参照やコンテナＢ３からの通知によりコンテナグループＡの障害を検出し、クラスタ３内にコンテナＡ３を新たに配備して動作させることで、コンテナグループＡのフェイルオーバを完成させる。

その後、障害が復旧すると（Ｓ１０７：Ｙｅｓ）、障害前のコンテナへの切り戻しが実行される（Ｓ１０８）。例えば、フェイルオーバ先のクラスタ３のスケジューラ３３０は、障害時と同じ経路またはマスタスケジューラ１３０から、障害復旧が通知されると、フェイルオーバさせたコンテナＡ３を削除する。また、障害が復旧したクラスタ２のスケジューラ２３０は、障害で停止していたコンテナＡ２を含む各コンテナを動作させる。

［効果］
上述したように、コンテナシステムは、第一のコンテナが他のクラスタに配備されている、第一のコンテナのレプリカである同グループの第二のコンテナの死活監視を行い、コンテナ間で障害検出を実現することができる。この結果、システム外部から全コンテナの死活監視を行う場合に比べて、限られた範囲の監視だけで、迅速に障害検知を行うことができ、フェイルオーバによる障害対処を高速に実現することができる。

また、あるクラスタに属するコンテナから、別クラスタのスケジューラへ各種指示を送信する手法は、宛先管理が複雑で、アクセス制御が煩雑になるので、好ましい手法ではない。これに対して、上記コンテナシステムは、クラスタ間で監視し、クラスタ間で障害情報を伝達するので、煩雑な設定を不要にすることができる。

また、各コンテナグループが独立にフェイルオーバ先を選定してしまうと、偏りが生じてフェイルオーバ先でリソース逼迫による性能劣化が生じる場合がある。また、各コンテナグループ間でフェイルオーバ先を分散させると、応答遅延が大きくなりサービス品質劣化が生じる場合がある。これらに対して、実施例１にかかるコンテナシステムでは、障害発生時のフェイルオーバ先を同一コンテナグループ内で選定および合意しておくことができるので、サービス劣化を抑制しつつ、高速なフェイルオーバを実現することができ、サービス可用性の向上および信頼性の向上を実現することができる。

また、上記コンテナシステムは、クラスタ障害が短時間で復旧する可能性もあるので、優先度の高いコンテナや緊急性の高いコンテナからフェイルオーバを実行することで、高速かつ安定的なサービス復旧を実現することができる。例えば、上記コンテナシステムは、予め優先度を決めておく、停止しているコンテナが多いコンテナグループを優先する、または、サービス利用者やサービス継続時間が長いコンテナを優先するなど、任意の手法により、フェイルオーバの順序を制御することができる。

一般的に、コンテナは起動時間が短く、クラスタ間の移動コストが小さいので、高速なフェイルオーバを実現できる。そこで、実施例１で説明したように、クラスタ障害時の他クラスタの負荷状態等を予測できないが、ある程度投機的にフェイルオーバによるコンテナ移動を優先することで、高速な障害対処を実現できる。このとき、フェイルオーバ先の性能を監視し、性能劣化が現れた場合には同一コンテナグループ内で順次対処することで、サービスの品質劣化を抑制することができる。

例えば、フェイルオーバ先のクラスタのスケジューラは、同一クラスタ内の各コンテナの稼働状況を監視し、サービス遅延などが発生したことを検出すると、フェイルオーバさせたコンテナを一時的に削除したり、一時的に停止させたりして、サービス遅延の回復を図ることができる。

上記例を実施例１の例で説明すると、フェイルオーバ先のクラスタ３のスケジューラ３３０は、コンテナＡ３を含むいずれかのコンテナの通信遅延が閾値以上になって、あるコンテナグループのサービス性能劣化を検出すると、コンテナＡ３を削除する。この結果、コンテナシステムでは、コンテナグループＡに関してはコンテナＡ１とコンテナＡ４との縮退運転を実行する。

なお、フェイルオーバ先に関わらず、他のクラスタのスケジューラも、同一クラスタ内の各コンテナの稼働状況を監視し、サービス遅延などが発生すると、フェイルオーバ先に、フェイルオーバさせたコンテナの停止等を要求することもできる。

図１５は、実施例３にかかるフェイルオーバ処理後の遅延による性能劣化時の流れを示すフローチャートである。図１５に示すＳ２０１からＳ２０６は、図１４で説明したＳ１０１からＳ１０６までの処理と同様なので、詳細な説明は省略する。

フェイルオーバ後、フェイルオーバ先のクラスタのスケジューラは、障害が復旧するまで、遅延による性能劣化を検出すると（Ｓ２０７：Ｙｅｓ）、フェイルオーバしたコンテナの削除を実行する（Ｓ２０８）。一方、フェイルオーバ先のクラスタのスケジューラは、遅延による性能劣化を検出しない間は（Ｓ２０７：Ｎｏ）、フェイルオーバしたコンテナの稼働を維持する。なお、性能劣化の一例としては、通信遅延、サービス遅延、処理遅延など、一般的に利用される情報を用いることができる。

その後のＳ２０９とＳ２１０は、図１４で説明したＳ１０７とＳ１０８と同様なので、詳細な説明は省略する。

例えば、実施例３の縮退運転中に、プロセッサやメモリなどのリソース使用率の異常な増加などで、あるリソース逼迫によるサービスの性能劣化が生じた場合、スケールアウトによりサービス品質の向上を図ることもできる。

上記実施例の例で説明すると、フェイルオーバ先のクラスタ３のスケジューラ３３０がコンテナＡ３を削除することで、コンテナシステムで、コンテナグループＡに関してはコンテナＡ１とコンテナＡ４との縮退運転が実行されている。この状態で、例えば、クラスタ４のスケジューラ４３０が、クラスタ４内のコンテナＡ４のリソース使用率が閾値以上となったことを検出すると、クラスタ４内にコンテナＡ４－２を新たに生成して、コンテナグループＡのサービス性能の向上を図ることができる。

図１６は、実施例４にかかるフェイルオーバ処理後の縮退による性能劣化時の流れを示すフローチャートである。図１６に示すＳ３０１からＳ３０８は、図１５で説明したＳ２０１からＳ２０８までの処理と同様なので、詳細な説明は省略する。

縮退運転後、各クラスタの各スケジューラは、縮退による性能劣化を検出すると（Ｓ３０９：Ｙｅｓ）、自クラスタ内で、性能劣化した対象のコンテナのスケールアウトを実行する（Ｓ３１０）。一方、各クラスタの各スケジューラは、縮退による性能劣化を検出しない間は（Ｓ３０９：Ｎｏ）、縮退中のコンテナの稼働を維持する。

その後のＳ３１１とＳ３１２は、図１４で説明したＳ１０７とＳ１０８と同様なので、詳細な説明は省略する。なお、障害復旧した場合、スケールアウトも終了する。上記例では、クラスタ４のスケジューラ４３０は、クラスタ４内に生成したコンテナＡ４－２を削除する。

上述したフェイルオーバ先の決定方法は、それぞれ独立して実行することができる。具体的には、重複クラスタ数による決定手法、非重複クラスタ数による決定手法、通信遅延量による決定手法のいずれかの手法を用いて決定することもでき、すべての条件を満たすフェイルオーバ先を決定することもできる。そこで、ここでは、一例として、クラスタサーバ２００が各決定手法を実行する場合の処理の流れを説明する。

（重複クラスタ数による決定手法）
図１７は、重複クラスタ数によるフェイルオーバ先の特定処理の流れを示すフローチャートである。図１７に示すように、クラスタサーバ２００は、コンテナグループを１つ選択し（Ｓ４０１）、選択したコンテナグループのコンテナが動作するクラスタを特定し（Ｓ４０２）、選択したコンテナグルーブ以外の他コンテナグループのコンテナが動作するクラスタを特定する（Ｓ４０３）。

そして、クラスタサーバ２００は、重複クラスタ数を算出する（Ｓ４０４）。例えば、クラスタサーバ２００は、他コンテナグループについて、選択済みのコンテナグループのコンテナと同じクラスタに配備されるクラスタの数である重複クラスタ数を計数する。

その後、クラスタサーバ２００は、重複クラスタ数によりフェイルオーバ先を決定する（Ｓ４０５）。例えば、クラスタサーバ２００は、重複クラスタ数が最も多い他コンテナグループを、選択済みのコンテナグループのフェイルオーバの依頼を行う候補（フェイルオーバ先候補）として特定する。

なお、クラスタサーバ２００は、未処理のコンテナグループがある場合（Ｓ４０６：Ｙｅｓ）、Ｓ４０１以降を繰り返し、未処理のコンテナグループがない場合（Ｓ４０６：Ｎｏ）、処理を終了する。

（非重複クラスタ数による決定手法）
図１８は、非重複クラスタ数によるフェイルオーバ先の特定処理の流れを示すフローチャートである。この処理は、例えば、図１７の手法により複数の候補が選択されたときに、その複数の候補について実行して最終的に決定することができる。また、図１８の手法により複数の候補が選択されたときに、その複数の候補について図１７を実行して最終的に決定することができる。

図１８に示すように、クラスタサーバ２００は、コンテナグループを１つ選択し（Ｓ５０１）、選択したコンテナグループのコンテナが動作するクラスタを特定し（Ｓ５０２）、選択したコンテナグルーブ以外の他コンテナグループのコンテナが動作するクラスタを特定する（Ｓ５０３）。

そして、クラスタサーバ２００は、非重複クラスタ数を算出する（Ｓ５０４）。例えば、クラスタサーバ２００は、他コンテナグループについて、選択済みのコンテナグループのコンテナが配備されていないクラスタの数である非重複クラスタ数を計数する。

その後、クラスタサーバ２００は、非重複クラスタ数によりフェイルオーバ先を決定する（Ｓ５０５）。例えば、クラスタサーバ２００は、非重複クラスタ数が最も多い他コンテナグループを、選択済みのコンテナグループのフェイルオーバの依頼を行う候補（フェイルオーバ先候補）として特定する。

なお、クラスタサーバ２００は、未処理のコンテナグループがある場合（Ｓ５０６：Ｙｅｓ）、Ｓ５０１以降を繰り返し、未処理のコンテナグループがない場合（Ｓ５０６：Ｎｏ）、処理を終了する。

（通信遅延量による決定手法による決定手法）
図１９は、通信遅延量によるフェイルオーバ先の特定処理の流れを示すフローチャートである。この処理は、例えば、図１７や図１８の手法、人手等により複数の候補が選択されたときに、その複数の候補について実行して最終的に決定することができる。また、図１９の手法により複数の候補が選択されたときに、その複数の候補について図１７や図１８を実行して最終的に決定することができる。

図１９に示すように、クラスタサーバ２００は、フェイルオーバ先候補のコンテナグループを１つ選択（Ｓ６０１）、選択したコンテナグループのコンテナが動作するクラスタを特定し（Ｓ６０２）、選択したコンテナグルーブ以外の他コンテナグループのコンテナが動作するクラスタを特定する（Ｓ６０３）。

そして、クラスタサーバ２００は、各クラスタ間の通信遅延量を測定する（Ｓ６０４）。例えば、クラスタサーバ２００は、移行元の各コンテナと移行先の各コンテナとの通信遅延を測定し、コンテナ間の通信遅延を用いてクラスタ間の平均遅延量を算出する。

その後、クラスタサーバ２００は、通信遅延量が最も少ないクラスタをフェイルオーバ先に決定する（Ｓ６０５）。なお、クラスタサーバ２００は、未処理のコンテナグループがある場合（Ｓ６０６：Ｙｅｓ）、Ｓ６０１以降を繰り返し、未処理のコンテナグループがない場合（Ｓ６０６：Ｎｏ）、処理を終了する。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

［数値等］
上記実施例で用いたクラスタ数、コンテナ数、クラスタリング技術、障害内容、性能劣化の検出手法、数値例、閾値等は、あくまで一例であり、任意に変更することができる。

［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

［ハードウェア］
次に、上記実施例で説明した各装置のハードウェア構成例を説明する。なお、各装置は、同様のハードウェア構成を有するので、ここでは、クラスタサーバ２００を例にして説明する。図２０は、ハードウェア構成例を説明する図である。図２０に示すように、クラスタサーバ２００は、通信装置２００ａ、ＨＤＤ（Hard Disk Drive）２００ｂ、メモリ２００ｃ、プロセッサ２００ｄを有する。また、図２０に示した各部は、バス等で相互に接続される。

通信装置２００ａは、ネットワークインタフェースカードなどであり、他のサーバとの通信を行う。ＨＤＤ２００ｂは、図５等に示した機能を動作させるプログラムやＤＢを記憶する。

プロセッサ２００ｄは、図５等に示した各処理部と同様の処理を実行するプログラムをＨＤＤ２００ｂ等から読み出してメモリ２００ｃに展開することで、図５等で説明した各機能を実行するプロセスを動作させる。例えば、このプロセスは、クラスタサーバ２００が有する各処理部と同様の機能を実行する。具体的には、プロセッサ２００ｄは、クラスタ実行部２１１、スケジュール実行部２１２、コンテナ実行部２１３等と同様の機能を有するプログラムをＨＤＤ２００ｂ等から読み出す。そして、プロセッサ２００ｄは、クラスタ実行部２１１、スケジュール実行部２１２、コンテナ実行部２１３等と同様の処理を実行するプロセスを実行する。

このように、クラスタサーバ２００は、プログラムを読み出して実行することで各種処理方法を実行する情報処理装置として動作する。また、クラスタサーバ２００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、クラスタサーバ２００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＭＯ（Magneto－Optical disk）、ＤＶＤ（Digital Versatile Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。

１００ マスタサーバ
１０１ 通信部
１０２ 記憶部
１０３ イメージファイルＤＢ
１０４ 稼働情報管理ＤＢ
１１０ 制御部
１１１ クラスタ実行部
１１２ スケジュール実行部
１１３ コンテナ実行部
２００ クラスタサーバ
２０１ 通信部
２０２ 記憶部
２０３ イメージファイルＤＢ
２０４ フェイルオーバ先ＤＢ
２１０ 制御部
２１１ クラスタ実行部
２１２ スケジュール実行部
２１３ コンテナ実行部

Claims (8)

1. コンテナが複数のクラスタに分散されているコンテナシステムで実行されるコンテナ管理方法において、
   第一のクラスタ内に配備されている第一のコンテナが、
   前記第一のクラスタとは異なる第二のクラスタに配備されている第二のコンテナの状態監視を実行し、
   前記状態監視の結果に応じて、前記第二のクラスタとは異なる第三のクラスタに、前記第二のコンテナのフェイルオーバの実行を指示する、
   ことを特徴とするコンテナ管理方法。
2. 前記第一のコンテナは、同じサービスを提供するコンテナグループに属する他コンテナとの間で生死確認を行うことを特徴とする請求項１に記載のコンテナ管理方法。
3. 前記第一のコンテナが、
   前記第一のコンテナおよび前記第二のコンテナが属する第一のコンテナグループのフェイルオーバ先として、
   前記コンテナシステム内の複数のコンテナグループのうち、前記第一のコンテナグループのコンテナと同じクラスタに配備される重複クラスタ数が閾値以上であるコンテナグループを選択することを特徴とする請求項１または２に記載のコンテナ管理方法。
4. 前記第一のコンテナが、
   前記第一のコンテナおよび前記第二のコンテナが属する第一のコンテナグループのフェイルオーバ先として、
   前記コンテナシステム内の複数のコンテナグループのうち、前記第一のコンテナグループのコンテナが配備されていないクラスタに配備される非重複クラスタ数が閾値以上であるコンテナグループを選択することを特徴とする請求項１から３のいずれか一つに記載のコンテナ管理方法。
5. 前記第一のコンテナが、
   移行先として選択された移行先のコンテナグループに属する各コンテナと、移行元である前記第一のコンテナグループに属する各コンテナとの通信遅延量が最小となるコンテナが配備されるクラスタを前記フェイルオーバによる移行先に決定することを特徴とする請求項３または４に記載のコンテナ管理方法。
6. 前記第三のクラスタが、
   前記第二のコンテナをフェイルオーバさせた第四のコンテナを実行し、
   前記第四のコンテナを実行後に、前記第三のクラスタの性能状態を監視し、
   前記第三のクラスタの性能劣化を検出した場合に、前記第四のコンテナを削除して、前記第二のコンテナが属する前記第一のコンテナグループの縮退運転を実行する、ことを特徴とする請求項３から５のいずれか一つに記載のコンテナ管理方法。
7. 前記コンテナシステム内の第四のクラスタが、
   前記第一のコンテナグループの縮退運転後に、前記第一のコンテナグループの性能劣化を検出した場合に、フェイルオーバ元の前記第二のコンテナに対応する第五のコンテナを、前記第四のクラスタ内に配備したスケールアウトを実行する、ことを特徴とする請求項５に記載のコンテナ管理方法。
8. コンテナが複数のクラスタに分散されているコンテナシステムで実行されるコンテナ管理プログラムにおいて、
   第一のクラスタ内に配備されている第一のコンテナが、
   前記第一のクラスタとは異なる第二のクラスタに配備されている第二のコンテナの状態監視を実行し、
   前記状態監視の結果に応じて、前記第二のクラスタとは異なる第三のクラスタに、前記第二のコンテナのフェイルオーバの実行を指示する、
   処理をコンピュータに実行させることを特徴とするコンテナ管理プログラム。

Images