知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024129247
(43)【公開日】2024-09-27
(54)【発明の名称】プログラム、情報処理方法および情報処理装置
(51)【国際特許分類】
G06F 11/20 20060101AFI20240919BHJP
【ＦＩ】
G06F11/20 628
【審査請求】未請求
【請求項の数】10
【出願形態】ＯＬ
(21)【出願番号】P 2023038328
(22)【出願日】2023-03-13
(71)【出願人】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】110002918
【氏名又は名称】弁理士法人扶桑国際特許事務所
(72)【発明者】
【氏名】金谷 良太
(72)【発明者】
【氏名】竹内 幸大
(72)【発明者】
【氏名】高石 明伸
(72)【発明者】
【氏名】小島 直己
【テーマコード（参考）】
5B034
【Ｆターム（参考）】
5B034BB02
5B034CC01
5B034DD05
(57)【要約】
【課題】可用性を効率的に向上する。
【解決手段】処理部１２は、運用系ノード２１によりアクセスされる第１記憶部２３および待機系ノード２２によりアクセスされる第２記憶部２４それぞれに、複数のユーザのジョブの実行に共通に用いられる共通データを配置する。処理部１２は、運用系ノード２１によるジョブの実行に応じて、または、第１ユーザにより更新される、第１ユーザに対応するジョブの固有データを、運用系ノードおよび待機系ノードにより共有される共有ストレージ２５に書き込ませる。処理部１２は、運用系ノード２１の稼働中には待機系ノード２２を停止状態とする。処理部１２は、ジョブの実行主体を運用系ノード２１から待機系ノード２２に切り替える際に、待機系ノード２２を起動し、共有ストレージ２５からの、待機系ノード２２による固有データの読み取りを可能にする設定を行う。
【選択図】図１
【解決手段】処理部１２は、運用系ノード２１によりアクセスされる第１記憶部２３および待機系ノード２２によりアクセスされる第２記憶部２４それぞれに、複数のユーザのジョブの実行に共通に用いられる共通データを配置する。処理部１２は、運用系ノード２１によるジョブの実行に応じて、または、第１ユーザにより更新される、第１ユーザに対応するジョブの固有データを、運用系ノードおよび待機系ノードにより共有される共有ストレージ２５に書き込ませる。処理部１２は、運用系ノード２１の稼働中には待機系ノード２２を停止状態とする。処理部１２は、ジョブの実行主体を運用系ノード２１から待機系ノード２２に切り替える際に、待機系ノード２２を起動し、共有ストレージ２５からの、待機系ノード２２による固有データの読み取りを可能にする設定を行う。
【選択図】図１
【特許請求の範囲】
【請求項1】
コンピュータに、
複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードによりアクセスされる第１記憶部および前記運用系ノードに対応する待機系ノードによりアクセスされる第２記憶部それぞれに、前記複数のユーザそれぞれに対応する前記ジョブの実行に共通に用いられる共通データを配置し、
前記運用系ノードによる前記ジョブの実行に応じて、または、前記第１ユーザにより更新される、前記第１ユーザに対応する前記ジョブの固有データを、前記運用系ノードおよび前記待機系ノードにより共有される共有ストレージに書き込ませるとともに、前記運用系ノードの稼働中には前記待機系ノードを停止状態とし、
前記ジョブの実行主体を前記運用系ノードから前記待機系ノードに切り替える際に、前記待機系ノードを起動し、前記共有ストレージからの、前記待機系ノードによる前記固有データの読み取りを可能にする設定を行う、
処理を実行させるプログラム。
複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードによりアクセスされる第１記憶部および前記運用系ノードに対応する待機系ノードによりアクセスされる第２記憶部それぞれに、前記複数のユーザそれぞれに対応する前記ジョブの実行に共通に用いられる共通データを配置し、
前記運用系ノードによる前記ジョブの実行に応じて、または、前記第１ユーザにより更新される、前記第１ユーザに対応する前記ジョブの固有データを、前記運用系ノードおよび前記待機系ノードにより共有される共有ストレージに書き込ませるとともに、前記運用系ノードの稼働中には前記待機系ノードを停止状態とし、
前記ジョブの実行主体を前記運用系ノードから前記待機系ノードに切り替える際に、前記待機系ノードを起動し、前記共有ストレージからの、前記待機系ノードによる前記固有データの読み取りを可能にする設定を行う、
処理を実行させるプログラム。
【請求項2】
前記共有ストレージは、前記運用系ノードおよび前記待機系ノードにマウント可能であり、
前記設定では、前記共有ストレージを前記待機系ノードにマウントする、
処理を前記コンピュータに実行させる請求項１記載のプログラム。
前記設定では、前記共有ストレージを前記待機系ノードにマウントする、
処理を前記コンピュータに実行させる請求項１記載のプログラム。
【請求項3】
前記設定では、前記共有ストレージを前記待機系ノードにマウントする前に、前記運用系ノードから前記共有ストレージをアンマウントする、
処理を前記コンピュータに実行させる請求項２記載のプログラム。
処理を前記コンピュータに実行させる請求項２記載のプログラム。
【請求項4】
前記運用系ノードから前記共有ストレージをアンマウントする前に、アクセス元ノードにより送信されるリクエストを前記運用系ノードへ中継する中継ノードが保持する接続先情報から前記運用系ノードの情報を削除し、
前記共有ストレージを前記待機系ノードにマウントした後に、前記接続先情報に前記待機系ノードの情報を追加する、
処理を前記コンピュータに実行させる請求項３記載のプログラム。
前記共有ストレージを前記待機系ノードにマウントした後に、前記接続先情報に前記待機系ノードの情報を追加する、
処理を前記コンピュータに実行させる請求項３記載のプログラム。
【請求項5】
前記共通データは、前記ジョブを動作させる所定プログラムであり、
前記所定プログラムをアップグレードした新ノードを用意して停止状態とし、
前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替える際に、前記新ノードを起動し、前記共有ストレージからの、前記新ノードによる前記固有データの読み取りを可能にする設定を行う、
処理を前記コンピュータに実行させる請求項１記載のプログラム。
前記所定プログラムをアップグレードした新ノードを用意して停止状態とし、
前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替える際に、前記新ノードを起動し、前記共有ストレージからの、前記新ノードによる前記固有データの読み取りを可能にする設定を行う、
処理を前記コンピュータに実行させる請求項１記載のプログラム。
【請求項6】
前記新ノードを用意すると、ノードの管理に用いられる管理テーブルに、前記運用系ノードに対して前記新ノードを用意済であることを記録し、
前記管理テーブルに基づいて前記新ノードを用意済であることを検出すると、前記運用系ノードの前記ジョブの実行状況に応じて前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替えるタイミングを決定し、
決定した前記タイミングにおいて前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替える際に、前記管理テーブルにおいて、前記運用系ノードの情報を削除し、前記新ノードを新たな運用系として設定する、
処理を前記コンピュータに実行させる請求項５記載のプログラム。
前記管理テーブルに基づいて前記新ノードを用意済であることを検出すると、前記運用系ノードの前記ジョブの実行状況に応じて前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替えるタイミングを決定し、
決定した前記タイミングにおいて前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替える際に、前記管理テーブルにおいて、前記運用系ノードの情報を削除し、前記新ノードを新たな運用系として設定する、
処理を前記コンピュータに実行させる請求項５記載のプログラム。
【請求項7】
前記運用系ノードは、第１アベイラビリティゾーンで動作し、
前記待機系ノードは、第２アベイラビリティゾーンで動作し、
前記第１アベイラビリティゾーンおよび前記第２アベイラビリティゾーンのうちの一方のアベイラビリティゾーンに前記新ノードを用意し、他方のアベイラビリティゾーンに前記新ノードに対応する待機系のノードを用意する、
処理を前記コンピュータに実行させる請求項５記載のプログラム。
前記待機系ノードは、第２アベイラビリティゾーンで動作し、
前記第１アベイラビリティゾーンおよび前記第２アベイラビリティゾーンのうちの一方のアベイラビリティゾーンに前記新ノードを用意し、他方のアベイラビリティゾーンに前記新ノードに対応する待機系のノードを用意する、
処理を前記コンピュータに実行させる請求項５記載のプログラム。
【請求項8】
前記共通データは、前記ジョブを動作させる所定プログラムであり、
前記固有データは、前記所定プログラムによって使用される、前記ジョブの定義および前記ジョブの状態を示す情報である、
請求項１記載のプログラム。
前記固有データは、前記所定プログラムによって使用される、前記ジョブの定義および前記ジョブの状態を示す情報である、
請求項１記載のプログラム。
【請求項9】
コンピュータが、
複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードによりアクセスされる第１記憶部および前記運用系ノードに対応する待機系ノードによりアクセスされる第２記憶部それぞれに、前記複数のユーザそれぞれに対応する前記ジョブの実行に共通に用いられる共通データを配置し、
前記運用系ノードによる前記ジョブの実行に応じて、または、前記第１ユーザにより更新される、前記第１ユーザに対応する前記ジョブの固有データを、前記運用系ノードおよび前記待機系ノードにより共有される共有ストレージに書き込ませるとともに、前記運用系ノードの稼働中には前記待機系ノードを停止状態とし、
前記ジョブの実行主体を前記運用系ノードから前記待機系ノードに切り替える際に、前記待機系ノードを起動し、前記共有ストレージからの、前記待機系ノードによる前記固有データの読み取りを可能にする設定を行う、
情報処理方法。
複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードによりアクセスされる第１記憶部および前記運用系ノードに対応する待機系ノードによりアクセスされる第２記憶部それぞれに、前記複数のユーザそれぞれに対応する前記ジョブの実行に共通に用いられる共通データを配置し、
前記運用系ノードによる前記ジョブの実行に応じて、または、前記第１ユーザにより更新される、前記第１ユーザに対応する前記ジョブの固有データを、前記運用系ノードおよび前記待機系ノードにより共有される共有ストレージに書き込ませるとともに、前記運用系ノードの稼働中には前記待機系ノードを停止状態とし、
前記ジョブの実行主体を前記運用系ノードから前記待機系ノードに切り替える際に、前記待機系ノードを起動し、前記共有ストレージからの、前記待機系ノードによる前記固有データの読み取りを可能にする設定を行う、
情報処理方法。
【請求項10】
複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードおよび前記運用系ノードに対応する待機系ノードとの通信に用いられる通信部と、
前記運用系ノードによりアクセスされる第１記憶部および前記待機系ノードによりアクセスされる第２記憶部それぞれに、前記複数のユーザそれぞれに対応する前記ジョブの実行に共通に用いられる共通データを配置し、前記運用系ノードによる前記ジョブの実行に応じて、または、前記第１ユーザにより更新される、前記第１ユーザに対応する前記ジョブの固有データを、前記運用系ノードおよび前記待機系ノードにより共有される共有ストレージに書き込ませるとともに、前記運用系ノードの稼働中には前記待機系ノードを停止状態とし、前記ジョブの実行主体を前記運用系ノードから前記待機系ノードに切り替える際に、前記待機系ノードを起動し、前記共有ストレージからの、前記待機系ノードによる前記固有データの読み取りを可能にする設定を行う処理部と、
を有する情報処理装置。
前記運用系ノードによりアクセスされる第１記憶部および前記待機系ノードによりアクセスされる第２記憶部それぞれに、前記複数のユーザそれぞれに対応する前記ジョブの実行に共通に用いられる共通データを配置し、前記運用系ノードによる前記ジョブの実行に応じて、または、前記第１ユーザにより更新される、前記第１ユーザに対応する前記ジョブの固有データを、前記運用系ノードおよび前記待機系ノードにより共有される共有ストレージに書き込ませるとともに、前記運用系ノードの稼働中には前記待機系ノードを停止状態とし、前記ジョブの実行主体を前記運用系ノードから前記待機系ノードに切り替える際に、前記待機系ノードを起動し、前記共有ストレージからの、前記待機系ノードによる前記固有データの読み取りを可能にする設定を行う処理部と、
を有する情報処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明はプログラム、情報処理方法および情報処理装置に関する。
【背景技術】
【0002】
近年、アプリケーションプログラムを実行する情報処理環境をユーザが自ら所有する代わりに、サービス事業者のもつ情報処理環境をネットワーク経由で利用することが増えている。ネットワーク経由で情報処理環境を利用させる情報処理システムはクラウドシステムと言われることがある。クラウドシステムは、物理マシンや仮想マシンなどの計算リソースをユーザに貸し出し、ユーザが利用するアプリケーションプログラムをその計算リソース上で実行する。
【0003】
ところで、情報処理システムではサービスの可用性の向上が図られている。例えば、地震や火災といった災害が発生した場合のデータロストに備えて、複数のサイトに配置された複数ストレージシステム間でデータを多重化して保持するシステムの提案がある。
【0004】
また、メインサイトのマスタストレージ装置にマスタデータを格納し、リモートサイトのリモートストレージ装置にマスタデータのバックアップであるバックアップデータを格納するディザスタリカバリシステムの提案がある。
【0005】
また、運用系仮想サーバがハートビートを受信せず、サービスが稼働している場合には、待機系のシステムを再起動することで、スプリットブレインの問題を回避するサービス継続システムの提案がある。
【0006】
更に、アクティブノードとスタンバイノードとを含むクラスタシステムで、アクティブノードが同期データを生成して外部記憶部に記憶させるとともに、スタンバイノードの起動指示を制御装置へ送信する同期方法の提案がある。提案の同期方法では、制御装置は、起動指示を受信した場合にスタンバイノードを起動する。スタンバイノードは、外部記憶部から同期データを取得し、同期データにより示される更新内容をスタンバイノードの記憶部に反映させる。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開２０２１－３３７８２号公報
【特許文献2】特開２０１７－１７４１０７号公報
【特許文献3】特開２０１９－１９７３５２号公報
【特許文献4】国際公開第２０１７／０４７０６５号
【発明の概要】
【発明が解決しようとする課題】
【0008】
上記提案のように、運用系ノードで同期データが生成されるたびに待機系ノードを起動して、同期データを待機系ノードへ反映させることがある。しかし、このような同期処理のたびに待機系ノードを実行すると、その分の計算リソースが消費される。このため、ユーザが本来実行したいジョブの他に、同期処理による余計なコストが発生する。
【0009】
１つの側面では、本発明は、可用性を効率的に向上することを目的とする。
【課題を解決するための手段】
【0010】
１つの態様では、プログラムが提供される。このプログラムは、コンピュータに次の処理を実行させる。コンピュータは、複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードによりアクセスされる第１記憶部および運用系ノードに対応する待機系ノードによりアクセスされる第２記憶部それぞれに、複数のユーザそれぞれに対応するジョブの実行に共通に用いられる共通データを配置する。コンピュータは、運用系ノードによるジョブの実行に応じて、または、第１ユーザにより更新される、第１ユーザに対応するジョブの固有データを、運用系ノードおよび待機系ノードにより共有される共有ストレージに書き込ませるとともに、運用系ノードの稼働中には待機系ノードを停止状態にする。コンピュータは、ジョブの実行主体を運用系ノードから待機系ノードに切り替える際に、待機系ノードを起動し、共有ストレージからの、待機系ノードによる固有データの読み取りを可能にする設定を行う。
【0011】
また、１つの態様では、情報処理方法が提供される。また、１つの態様では、通信部と処理部とを有する情報処理装置が提供される。
【発明の効果】
【0012】
１つの側面では、可用性を効率的に向上できる。
【図面の簡単な説明】
【0013】
【図1】第１の実施の形態の情報処理装置を説明する図である。
【図2】第２の実施の形態のクラウドシステムの例を示す図である。
【図3】物理マシンのハードウェア例を示す図である。
【図4】クラウドシステムのネットワーク接続関係の例を示す図である。
【図5】クラウドシステムの機能例を示す図である。
【図6】管理テーブルの例を示す図である。
【図7】運用系／待機系マシンによる共有ストレージのマウント例を示す図である。
【図8】運用系／待機系マシンの切り替えの例を示すフローチャートである。
【図9】第３の実施の形態のマシン作成例を示す図である。
【図10】管理テーブルの例を示す図である。
【図11】サーバレス関数による管理テーブルの編集例を示す図である。
【図12】サーバレス関数によるロードバランサの制御例を示す図である。
【図13】サービスアップグレード済マシン用意の例を示すフローチャートである。
【図14】サービスアップグレード済マシン作成の例を示すフローチャートである。
【図15】管理テーブルのマシンタイプ更新の例を示すフローチャートである。
【図16】管理テーブルのマシンタイプ更新の具体例を示す図である。
【図17】サービスアップグレード制御の例を示すフローチャートである。
【図18】サービスアップグレード可否判定の例を示すフローチャートである。
【図19】フェールオーバの各処理の例を示すフローチャートである。
【図20】比較例を示す図である。
【発明を実施するための形態】
【0014】
以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。
［第１の実施の形態］
第１の実施の形態を説明する。
【0015】
図１は、第１の実施の形態の情報処理装置を説明する図である。
情報処理装置１０は、情報処理システム２０に接続される。情報処理装置１０は、情報処理システム２０に含まれてもよい。情報処理システム２０は、複数の物理マシンや複数の仮想マシンで実現される複数のノードをユーザにより利用可能にする。情報処理システム２０は、複数のユーザにより利用される。なお、情報処理装置１０はコンピュータと言われてもよい。情報処理システム２０はクラウドシステムと言われてもよい。ユーザはテナントと言われてもよい。
情報処理装置１０は、情報処理システム２０に接続される。情報処理装置１０は、情報処理システム２０に含まれてもよい。情報処理システム２０は、複数の物理マシンや複数の仮想マシンで実現される複数のノードをユーザにより利用可能にする。情報処理システム２０は、複数のユーザにより利用される。なお、情報処理装置１０はコンピュータと言われてもよい。情報処理システム２０はクラウドシステムと言われてもよい。ユーザはテナントと言われてもよい。
【0016】
情報処理システム２０に含まれるノードは、ユーザにより利用されるサービスに係るジョブを実行する。例えば、ユーザは、アクセス元ノード３０を用いて、情報処理システム２０に含まれるノードを利用する。アクセス元ノード３０は、ユーザが使用するスマートフォン、タブレットおよびＰＣ（Personal Computer）などの端末装置でもよいし、情報処理システム２０に含まれる物理マシンまたは仮想マシンでもよい。
【0017】
情報処理装置１０は、情報処理システム２０に含まれる複数のノードを制御する。情報処理装置１０は、記憶部１１と処理部１２と通信部１３を有する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性の半導体メモリでもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性ストレージでもよい。記憶部１１は、処理部１２の処理に用いられるデータを記憶する。
【0018】
処理部１２は、例えば、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などのプロセッサである。ただし、処理部１２は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路を含んでもよい。プロセッサは、ＲＡＭなどのメモリ（記憶部１１でもよい）に記憶されたプログラムを実行する。複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。
【0019】
通信部１３は、情報処理システム２０に含まれる各ノードとの通信に用いられる通信インタフェースである。例えば、処理部１２は、通信部１３を介して各ノードと通信する。
情報処理システム２０は、運用系ノード２１、待機系ノード２２、第１記憶部２３、第２記憶部２４、共有ストレージ２５および中継ノード２６を有する。運用系ノード２１は、複数のユーザのうちの第１ユーザのジョブを実行する運用系のノードである。待機系ノード２２は、運用系ノード２１に対応する待機系のノードである。運用系ノード２１および待機系ノード２２は、災害などの影響を考慮して、地理的に離れたデータセンタなどの拠点に設けられてもよい。
情報処理システム２０は、運用系ノード２１、待機系ノード２２、第１記憶部２３、第２記憶部２４、共有ストレージ２５および中継ノード２６を有する。運用系ノード２１は、複数のユーザのうちの第１ユーザのジョブを実行する運用系のノードである。待機系ノード２２は、運用系ノード２１に対応する待機系のノードである。運用系ノード２１および待機系ノード２２は、災害などの影響を考慮して、地理的に離れたデータセンタなどの拠点に設けられてもよい。
【0020】
第１記憶部２３は、運用系ノード２１によりアクセスされる、運用系ノード２１のローカルストレージである。第１記憶部２３には、運用系ノード２１に割り当てられた、ＨＤＤやＳＳＤなどの記憶領域が用いられる。第２記憶部２４は、待機系ノード２２によりアクセスされる、待機系ノード２２のローカルストレージである。第２記憶部２４には待機系ノード２２に割り当てられた、ＨＤＤやＳＳＤなどの記憶領域が用いられる。共有ストレージ２５は、運用系ノード２１および待機系ノード２２により共有されるストレージであり、運用系ノード２１および待機系ノード２２にマウント可能である。共有ストレージ２５は、ＨＤＤやＳＳＤなどの記憶装置を有し、当該記憶装置の記憶領域を運用系ノード２１や待機系ノード２２に提供する。共有ストレージ２５は、運用系ノード２１および待機系ノード２２からネットワーク経由でマウントされる。
【0021】
中継ノード２６は、アクセス元ノード３０からのアクセスを、運用系ノード２１または待機系ノード２２へ中継するノードである。運用系ノード２１でジョブ運用する場合、中継ノード２６はアクセス元ノード３０からの要求を運用系ノード２１へ転送する。待機系ノード２２でジョブ運用する場合、中継ノード２６はアクセス元ノード３０からの要求を待機系ノード２２へ転送する。
【0022】
上記のように、情報処理システム２０では、運用系ノード２１に対して待機系ノード２２を設けることで、運用系ノード２１での異常発生時などに、待機系ノード２２での運用に切り替えることができる。このとき、処理部１２は、運用系ノード２１および待機系ノード２２と通信部１３を介して通信し、運用系ノード２１および待機系ノード２２を次のように制御する。下記の制御は、例えばクラウドシステムにおけるサーバレス関数と呼ばれる軽量プログラムを、処理部１２が実行することで実現されてもよい。
【0023】
処理部１２は、第１記憶部２３および第２記憶部２４それぞれに、複数のユーザそれぞれに対応するジョブの実行に共通に用いられる共通データを配置する。共通データは、例えばジョブの定義および実行などのジョブ管理を行うジョブ管理ソフトウェアのプログラムである。各ユーザは、当該ソフトウェアの機能により自身が利用したいサービスに関する処理をジョブとして定義し、自身が利用するノードに当該ジョブを実行させることができる。
【0024】
運用系ノード２１および待機系ノード２２がそれぞれ仮想マシンで実現される場合、処理部１２は、共通データを含む仮想マシンイメージを用いて運用系ノード２１および待機系ノード２２を作成する。これにより、処理部１２は、仮想マシンイメージを基に運用系ノード２１に割り当てられる第１記憶部２３、および、仮想マシンイメージを基に待機系ノード２２に割り当てられる第２記憶部２４それぞれに共通データを配置することができる。
【0025】
処理部１２は、運用系ノード２１による、第１ユーザに対応するジョブの実行に応じて、または、第１ユーザにより更新される固有データを、運用系ノード２１により共有ストレージ２５に書き込ませる。固有データは、ジョブの実行に用いられる、ユーザ固有のデータである。第１ユーザの固有データは、例えば第１ユーザにより定義されたジョブの内容を示すジョブ定義情報、および、ジョブの実行状態や実行結果を示すジョブ状態情報の少なくとも何れかを含む。ジョブ定義情報は、実行するジョブの内容に応じて、第１ユーザにより更新される。ジョブ状態情報は、ジョブの実行状況に応じて更新される。また、処理部１２は、運用系ノード２１の稼働中には待機系ノード２２を停止状態にする。具体的には、処理部１２は、運用系ノード２１に共有ストレージ２５をマウントすることで、運用系ノード２１により固有データを共有ストレージ２５に直接書き込み可能にする。また、待機系ノード２２が仮想マシンで実現される場合、処理部１２は、仮想マシンイメージから作成した待機系ノード２２を停止させ、待機系ノード２２を起動可能な状態に維持する。
【0026】
処理部１２は、ジョブの実行主体を運用系ノード２１から待機系ノード２２に切り替える際に、待機系ノード２２を起動し、共有ストレージ２５からの、待機系ノード２２による固有データの読み取りを可能にする設定を行う。具体的には、処理部１２は、待機系ノード２２に共有ストレージ２５をマウントすることで固有データを待機系ノード２２により読み取り可能にする。
【0027】
例えば、処理部１２は、運用系ノード２１におけるソフトウェアのエラーなど、運用系ノード２１でジョブ運用を継続できない異常を検知すると、ジョブの実行主体を運用系ノード２１から待機系ノード２２に切り替える。このとき、処理部１２は、共有ストレージ２５を運用系ノード２１からアンマウントし、起動させた待機系ノード２２に共有ストレージ２５をマウントする。これにより、例えば共有ストレージ２５の固有データが書き込まれた所定の記憶領域が、待機系ノード２２のマウントポイントにマウントされる。すると、待機系ノード２２は、当該マウントポイントを介して、共有ストレージ２５に書き込まれた固有データを読み取ることができる。待機系ノード２２は、第２記憶部２４に記憶される共通データおよび共有ストレージ２５に記憶される固有データに基づいて、運用系ノード２１からジョブを引き継いで実行する。
【0028】
なお、処理部１２は、運用系ノード２１から待機系ノード２２への切り替えを行う場合、アクセス元ノード３０によるアクセス先を運用系ノード２１から待機系ノード２２へ切り替える設定を中継ノード２６に対して行う。例えば、処理部１２は、共有ストレージ２５を運用系ノード２１からアンマウントする前に、中継ノード２６が保持する接続先情報から運用系ノード２１の情報（例えばホスト名またはＩＰ（Internet Protocol）アドレス）を削除する。ここで、接続先情報は、中継ノード２６によるリクエストの転送先を示し、例えば、リクエストの送信元のＩＰアドレスなどの情報に対応付けて、転送先のＩＰアドレスなどの情報が登録される。そして、処理部１２は、待機系ノード２２に共有ストレージ２５をマウントした後に、中継ノード２６が保持する接続先情報に待機系ノード２２の情報（例えばホスト名またはＩＰアドレス）を追加する。これにより、運用系ノード２１で異常が発生しても、待機系ノード２２により第１ユーザへのサービスの提供が継続される。
【0029】
第１の実施の形態の情報処理装置１０によれば、運用系ノード２１によりアクセスされる第１記憶部２３および待機系ノード２２によりアクセスされる第２記憶部２４それぞれに、各ユーザのジョブの実行に共通に用いられる共通データが配置される。運用系ノード２１によるジョブの実行に応じて、または、第１ユーザにより更新される、第１ユーザに対応するジョブの固有データが共有ストレージ２５に書き込まれるとともに、運用系ノード２１の稼働中には待機系ノード２２が停止状態とされる。ジョブの実行主体を運用系ノード２１から待機系ノード２２に切り替える際に、待機系ノード２２が起動される。そして、共有ストレージ２５からの、待機系ノード２２による固有データの読み取りを可能にする設定が行われる。
【0030】
これにより、情報処理装置１０は、サービスの可用性を効率的に向上できる。具体的には次の通りである。
運用系ノード２１と待機系ノード２２とのデータの連携は共有ストレージ２５を用いて行われる。待機系ノード２２は、運用系ノード２１が更新した固有データを共有ストレージ２５から読み取れる。このため、運用系ノード２１と待機系ノード２２とで定期的な、あるいは、データ更新毎のデータの同期処理を行わなくてよくなり、運用系ノード２１から待機系ノード２２へ切り替えるときに待機系ノード２２を起動させればよい。
運用系ノード２１と待機系ノード２２とのデータの連携は共有ストレージ２５を用いて行われる。待機系ノード２２は、運用系ノード２１が更新した固有データを共有ストレージ２５から読み取れる。このため、運用系ノード２１と待機系ノード２２とで定期的な、あるいは、データ更新毎のデータの同期処理を行わなくてよくなり、運用系ノード２１から待機系ノード２２へ切り替えるときに待機系ノード２２を起動させればよい。
【0031】
ただし、共有ストレージ２５を運用系ノード２１および待機系ノード２２からマウント可能とするなどの方法により両ノードで共有する場合、共有ストレージ２５は、運用系ノード２１および待機系ノード２２によりネットワーク経由で共有される。このため、切り替え時に共有ストレージ２５から待機系ノード２２へ比較的多量のデータを読み取らせると、当該データの読み取りに時間がかかる可能性がある。これは、切り替え完了の遅延の原因になり可用性に影響する。
【0032】
そこで、情報処理装置１０は、運用系ノード２１の第１記憶部２３および待機系ノード２２の第２記憶部２４それぞれに共通データが配置され、共有ストレージ２５には共通データ以外の固有データが書き込まれるようにする。これにより、共有ストレージ２５に共通データおよび固有データの両方を書き込むよりも、切り替え時において待機系ノード２２により共有ストレージ２５から読み取るデータ量が低減される。その結果、例えば運用系ノード２１の異常検知から待機系ノード２２によりサービスに係るジョブを再開までに要する時間が低減され、運用系ノード２１から待機系ノード２２への迅速な切り替えを行えるようになる。
【0033】
こうして、情報処理装置１０は、同期処理の都度、待機系ノード２２を起動して同期処理を行う方法に比べて、切り替え時の遅延を抑えて、当該同期処理を省略することができる。このため、情報処理装置１０は、待機系ノード２２の実行に係るコストを抑制しつつ可用性を確保できる。
【0034】
更に、共通データが共有ストレージ２５に保存されないので、共通データおよび固有データの両方を共有ストレージ２５に保存するよりも、共有ストレージ２５として割く記憶リソースを低減できるという利点もある。また、運用系ノード２１が異常により停止した場合でも、待機系ノード２２により共有ストレージ２５から最新の固有データを取得して、ジョブ運用を継続できるという利点もある。
【0035】
【0036】
クラウドシステム２は、クラウドサービスを提供する。クラウドサービスの一例として、ＡＷＳ（Amazon Web Services）がある。ＡＷＳは登録商標である。Ａｍａｚｏｎは登録商標である。ただし、クラウドシステム２は、他のクラウドサービスを提供してもよい。クラウドシステム２は、物理マシン１００，１００ａ，…を有する。物理マシン１００，１００ａ，…は、ユーザに提供される計算リソースを有するサーバである。図示を省略しているが、クラウドシステム２は、更に、ネットワーク機器やストレージ装置などのハードウェアを多数含む。クラウドシステム２は、物理マシン１００，１００ａ，…、ネットワーク機器およびストレージ装置などのリソースをユーザに貸し出し、ユーザにより利用可能にする。
【0037】
クラウドシステム２は、ユーザが利用したリソースの性能、量および利用時間などに応じた料金をユーザに課する。当該料金は、クラウドシステム２の利用に伴うユーザのコストの一例である。ただし、当該コストは、消費電力や消費電力に応じた電気代などの他の指標でもよい。
【0038】
クラウドシステム２は、インターネット３に接続される。また、インターネット３には、端末装置４が接続される。端末装置４は、ユーザが操作するクライアントコンピュータである。ユーザは端末装置４を操作して、クラウドシステム２のサービスを利用することができる。ここで、クラウドシステム２を利用するユーザまたはユーザのグループを、以下ではテナントと言う。
【0039】
図３は、物理マシンのハードウェア例を示す図である。
物理マシン１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、ＧＰＵ１０４、入力インタフェース１０５、媒体リーダ１０６および通信インタフェース１０７を有する。物理マシン１００が有するこれらのユニットは、物理マシン１００の内部でバスに接続されている。プロセッサ１０１は、第１の実施の形態の処理部１２に対応する。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１に対応する。通信インタフェース１０７は、第１の実施の形態の通信部１３に対応する。
物理マシン１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、ＧＰＵ１０４、入力インタフェース１０５、媒体リーダ１０６および通信インタフェース１０７を有する。物理マシン１００が有するこれらのユニットは、物理マシン１００の内部でバスに接続されている。プロセッサ１０１は、第１の実施の形態の処理部１２に対応する。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１に対応する。通信インタフェース１０７は、第１の実施の形態の通信部１３に対応する。
【0040】
プロセッサ１０１は、プログラムの命令を実行する演算装置である。プロセッサ１０１は、例えばＣＰＵである。プロセッサ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、プロセッサ１０１は複数のプロセッサコアを含んでもよい。また、物理マシン１００は複数のプロセッサを有してもよい。以下で説明する処理は複数のプロセッサまたはプロセッサコアを用いて並列に実行されてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。
【0041】
ＲＡＭ１０２は、プロセッサ１０１が実行するプログラムやプロセッサ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、物理マシン１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。
【0042】
ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、物理マシン１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。
【0043】
ＧＰＵ１０４は、プロセッサ１０１からの命令に従って、物理マシン１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなど、任意の種類のディスプレイを用いることができる。
【0044】
入力インタフェース１０５は、物理マシン１００に接続された入力デバイス１１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１１２としては、マウス、タッチパネル、タッチパッド、トラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、物理マシン１００に、複数の種類の入力デバイスが接続されていてもよい。
【0045】
媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。
【0046】
媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、プロセッサ１０１によって実行される。なお、記録媒体１１３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体１１３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。
【0047】
通信インタフェース１０７は、ネットワーク１１４に接続され、ネットワーク１１４を介して他の情報処理装置と通信する。通信インタフェース１０７は、スイッチやルータなどの有線通信装置に接続される有線通信インタフェースでもよいし、基地局やアクセスポイントなどの無線通信装置に接続される無線通信インタフェースでもよい。なお、ネットワーク１１４は、クラウドシステム２の内部ネットワークである。
【0048】
物理マシン１００ａを含む、クラウドシステム２の他の物理マシンや、端末装置４も物理マシン１００と同様のハードウェアにより実現される。
図４は、クラウドシステムのネットワーク接続関係の例を示す図である。
図４は、クラウドシステムのネットワーク接続関係の例を示す図である。
【0049】
クラウドシステム２は、リージョン２ａ、仮想プライベートクラウド（ＶＰＣ：Virtual Private Cloud）２ｂおよびアベイラビリティゾーン（ＡＺ：Availability Zone）２ｃ１，２ｃ２を有する。
【0050】
リージョン２ａは、複数のデータセンタを有する地域である。ＶＰＣ２ｂは、リージョン２ａ内において、クラウドシステム２に構築された、テナントの仮想ネットワークである。ＶＰＣはテナントごとに論理的に分離される。すなわち、複数のテナントに対して複数のＶＰＣが存在し得る。ＡＺ２ｃ１，２ｃ２は、それぞれリージョン２ａ内に立地する１以上のデータセンタの集合である。図示を省略しているが、ＡＺ２ｃ１，２ｃ２は、テナントが利用するネットワークの管理単位であるサブネットを含む。
【0051】
クラウドシステム２は、監視ノード４０、サーバレス関数実行ノード５０、マシンイメージ管理ノード６０、管理ＤＢ（DataBase）７０、インターネットゲートウェイ８０およびロードバランサ９０を有する。
【0052】
監視ノード４０は、テナントが利用する仮想マシンを監視することでイベントを検知し、当該イベントに応じてサーバレス関数実行ノード５０によるサーバレス関数の実行を指示する。
【0053】
サーバレス関数実行ノード５０は、サーバレス関数を実行する。サーバレス関数による処理には、テナントの仮想マシンの起動および停止などやロードバランサ９０の設定変更などの制御がある。制御内容ごとに異なるサーバレス関数が予め用意され、実行する制御内容に応じたサーバレス関数が実行されてもよい。
【0054】
マシンイメージ管理ノード６０は、テナントが利用する仮想マシンのマシンイメージを管理する。マシンイメージは、仮想マシンの起動に用いられるデータである。
監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、例えばクラウドシステム２におけるリージョン２ａと同位のネットワークに配置される。リージョン２ａのネットワークは、ＶＰＣ２ｂのネットワークと接続される。監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、リージョン２ａのネットワークを介して、ＶＰＣ２ｂ内のノードと通信し得る。
監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、例えばクラウドシステム２におけるリージョン２ａと同位のネットワークに配置される。リージョン２ａのネットワークは、ＶＰＣ２ｂのネットワークと接続される。監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、リージョン２ａのネットワークを介して、ＶＰＣ２ｂ内のノードと通信し得る。
【0055】
管理ＤＢ７０は、監視ノード４０やサーバレス関数実行ノード５０の処理に用いられるデータを記憶する。管理ＤＢ７０は、リージョン２ａのネットワークに配置される。
インターネットゲートウェイ８０は、インターネット３に接続され、インターネット３とＶＰＣ２ｂ内のノードとの通信を中継するノードである。インターネットゲートウェイ８０は、リージョン２ａに設けられる。
インターネットゲートウェイ８０は、インターネット３に接続され、インターネット３とＶＰＣ２ｂ内のノードとの通信を中継するノードである。インターネットゲートウェイ８０は、リージョン２ａに設けられる。
【0056】
ロードバランサ９０は、インターネットゲートウェイ８０とＡＺ２ｃ１，２ｃ２内の仮想マシンとの間の通信を中継するノードである。ロードバランサ９０は、端末装置４により送信されるテナントのリクエストを、インターネットゲートウェイ８０を介して受信し、ＡＺ２ｃ１，２ｃ２内の仮想マシンへ振り分ける制御を行う。ロードバランサ９０は、ＶＰＣ２ｂに設けられる。
【0057】
ＡＺ２ｃ１は、運用系マシン２００とストレージ２０１とを有する。運用系マシン２００は、ＶＰＣ２ｂに対応するテナントにより利用される運用系の仮想マシンであり、当該テナントが利用するサービスに係るジョブを実行する。ストレージ２０１は、運用系マシン２００のローカルストレージである。
【0058】
ＡＺ２ｃ２は、待機系マシン３００とストレージ３０１とを有する。待機系マシン３００は、運用系マシン２００に対応する待機系の仮想マシンである。待機系マシン３００は、ＶＰＣ２ｂに対応するテナントにより利用される。待機系マシン３００は、運用系マシン２００の稼働時には停止状態とされる。待機系マシン３００が停止されていれば、待機系マシン３００の分の計算リソースは使用されないため、テナントへの課金は生じない。待機系マシン３００は、運用系マシン２００の異常時に起動され、運用系マシン２００のジョブを引き継いで実行する。ストレージ３０１は、待機系マシン３００のローカルストレージである。ここで、運用系マシン２００での運用を待機系マシン３００に切り替える制御は、フェールオーバと言われる。後述されるように、フェールオーバは、マシンアップグレードの際にも用いられる。
【0059】
ＶＰＣ２ｂには、運用系マシン２００および待機系マシン３００からＶＰＣ２ｂ内のネットワークを介してアクセス可能な共有ストレージ４００が設けられる。共有ストレージ４００は、運用系マシン２００および待機系マシン３００からマウント可能である。共有ストレージ４００には、運用系マシン２００から待機系マシン３００への切り替えの際に、待機系マシン３００へ引き継ぐデータが格納される。
【0060】
ここで、監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、物理マシン１００，１００ａ，…に含まれる物理マシンにより実現される。監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、当該物理マシンのハードウェアリソースを用いて実行される仮想マシンにより実現されてもよい。監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、１つの物理マシンによって実現されてもよいし、異なる物理マシンによって実現されてもよい。インターネットゲートウェイ８０やロードバランサ９０は、クラウドシステム２に含まれる通信装置や当該物理マシン、あるいは、当該物理マシン上の仮想マシンにより実現される。
【0061】
運用系マシン２００および待機系マシン３００は、物理マシン１００，１００ａ，…に含まれる物理マシンのハードウェアリソースを用いて実行される仮想マシンである。ストレージ２０１は運用系マシン２００に割り当てられる物理マシンのＨＤＤやＳＳＤなどの記憶領域により実現される。ストレージ３０１は待機系マシン３００に割り当てられる物理マシンのＨＤＤやＳＳＤなどの記憶領域により実現される。管理ＤＢ７０は、リージョン２ａに含まれる物理マシンやＨＤＤやＳＳＤなどを有するストレージ装置により実現される。
【0062】
共有ストレージ４００は、運用系マシン２００および待機系マシン３００によりＶＰＣ２ｂのネットワーク経由でアクセス可能なストレージ装置により実現される。当該ストレージ装置は、ＨＤＤやＳＳＤなどを有する。例えば、当該ストレージ装置の記憶領域の一部が、共有ストレージ４００として、ＶＰＣ２ｂに対応するテナントに割り当てられる。
【0063】
図５は、クラウドシステムの機能例を示す図である。
クラウドシステム２は、監視部４１およびサーバレス関数５１を有する。監視部４１は、監視ノード４０のプロセッサが監視ノード４０のＲＡＭに記憶されたプログラムを実行することで実現される。サーバレス関数５１は、サーバレス関数実行ノード５０のプロセッサがサーバレス関数実行ノード５０のＲＡＭに記憶された軽量プログラムを実行することで実現される。
クラウドシステム２は、監視部４１およびサーバレス関数５１を有する。監視部４１は、監視ノード４０のプロセッサが監視ノード４０のＲＡＭに記憶されたプログラムを実行することで実現される。サーバレス関数５１は、サーバレス関数実行ノード５０のプロセッサがサーバレス関数実行ノード５０のＲＡＭに記憶された軽量プログラムを実行することで実現される。
【0064】
監視部４１は、運用系マシン２００を監視し、運用系マシン２００の異常を検知すると、サーバレス関数実行ノード５０によりサーバレス関数５１を起動させる。監視部４１は、サーバレス関数５１によりフェールオーバが行われると、新たにジョブの実行主体（新運用系）となった待機系マシン３００の監視を行う。
【0065】
サーバレス関数５１は、フェールオーバを行う。フェールオーバの際、サーバレス関数５１は、運用系マシン２００からの共有ストレージ４００のアンマウント、待機系マシン３００の起動、待機系マシン３００への共有ストレージのマウント、ロードバランサ９０によるリクエストの振り分け先の変更を行う。なお、サーバレス関数５１のこれらの処理は、複数のサーバレス関数により分担して行われてもよい。
【0066】
ここで、ストレージ２０１およびストレージ３０１には、運用系マシン２００および待機系マシン３００で実行されるジョブに係るテナント共通データが格納される。テナント共通データは、複数のテナントそれぞれのジョブの実行に共通に用いられるデータであり、各テナントのジョブを実行するための基盤のソフトウェアのプログラムである。各テナントは、当該ソフトウェアの機能により自身が利用したいサービスに関する処理をジョブとして定義し、自身が利用するノードに当該ジョブを実行させることができる。
【0067】
また、共有ストレージ４００には、運用系マシン２００のジョブの実行などに応じて更新される、テナント固有データが格納される。テナント固有データは、ジョブの状態（ジョブ状態）や定義（ジョブ定義）を示す情報である。ジョブ定義は、ジョブの処理内容やジョブの実行スケジュールを含み得る。ジョブ定義は、テナントが実行したいジョブの内容に応じて、当該テナントによって更新される。ジョブ状態は、これまでのジョブの実行結果を含み得る。ジョブ状態は、運用系マシン２００によるジョブの実行に応じて更新される。
【0068】
テナント共通データを共有ストレージ４００に配置しないことで、共有ストレージ４００として使用される記憶容量を節約できる。共有ストレージ４００は、利用料が比較的安価な標準ストレージと、標準ストレージよりも利用料が高い高速ストレージを含むことがある。その場合、例えば、テナント固有データのうち、比較的更新頻度の少ないジョブ定義のデータを標準ストレージに保存し、比較的更新頻度の多いジョブ状態のデータを高速ストレージに保存するようにしてもよい。これにより、運用への影響を抑えながら、テナントによる共有ストレージ４００の利用コストが低減される。
【0069】
また、管理ＤＢ７０は、フェールオーバの制御に用いられる管理テーブル７１を記憶する。管理テーブル７１は、運用系マシン２００および待機系マシン３００を含む、テナントごとの運用系／待機系マシンの稼働状態やマシンイメージの管理に用いられる。
【0070】
図６は、管理テーブルの例を示す図である。
管理テーブル７１は、テナントＩＤ（IDentifier）、テナントステータス、マシンＩＤ、マシンタイプおよびイメージＩＤの項目を含む。テナントＩＤの項目には、テナントＩＤが登録される。テナントＩＤはテナントの識別情報である。
管理テーブル７１は、テナントＩＤ（IDentifier）、テナントステータス、マシンＩＤ、マシンタイプおよびイメージＩＤの項目を含む。テナントＩＤの項目には、テナントＩＤが登録される。テナントＩＤはテナントの識別情報である。
【0071】
テナントステータスの項目には、テナントステータスが登録される。テナントステータスは、テナントに対するサービスアップグレードの状態を示す。テナントステータスには「ｎｏｒｍａｌ」または「ｐａｔｃｈ」が設定される。テナントステータス「ｎｏｒｍａｌ」は通常運用している状態を示す。テナントステータス「ｐａｔｃｈ」は、後述されるサービスアップグレード済マシンを用意済の状態を示す。
【0072】
マシンＩＤの項目には、マシンＩＤが登録される。マシンＩＤは、仮想マシンの識別情報である。
マシンタイプの項目には、マシンタイプが登録される。マシンタイプは、仮想マシンの種類を示す。マシンタイプ、すなわち、仮想マシンの種類には次の６種類がある。マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」は、運用系マシンを示す。マシンタイプ「ｓｔａｎｄｂｙ」は、待機系マシンを示す。マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」は、サービスアップグレード済の待機系マシンを示す。マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」は、サービスアップグレード済の運用系マシンを示す。マシンタイプ「ｓｔａｎｄｂｙ＿ｏｌｄ」は、フェールオーバによる切り替え直前の待機系マシン、すなわち、旧待機系マシンを示す。マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」は、フェールオーバによる切り替え直前の運用系マシン、すなわち、旧運用系マシンを示す。
マシンタイプの項目には、マシンタイプが登録される。マシンタイプは、仮想マシンの種類を示す。マシンタイプ、すなわち、仮想マシンの種類には次の６種類がある。マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」は、運用系マシンを示す。マシンタイプ「ｓｔａｎｄｂｙ」は、待機系マシンを示す。マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」は、サービスアップグレード済の待機系マシンを示す。マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」は、サービスアップグレード済の運用系マシンを示す。マシンタイプ「ｓｔａｎｄｂｙ＿ｏｌｄ」は、フェールオーバによる切り替え直前の待機系マシン、すなわち、旧待機系マシンを示す。マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」は、フェールオーバによる切り替え直前の運用系マシン、すなわち、旧運用系マシンを示す。
【0073】
イメージＩＤは、マシンＩＤに対応する仮想マシンの作成元のマシンイメージの識別情報である。イメージＩＤは、マシンイメージのデータ本体の取得に用いられる。
例えば、管理テーブル７１は、テナントＩＤ「１」に対してテナントステータス「ｎｏｒｍａｌ」を保持する。また、管理テーブル７１は、マシンＩＤ「１」に対して、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」、イメージＩＤ「ｉｍａｇｅＸＸＸ１」のレコードを有する。当該レコードは、運用系マシン２００を示すデータである。また、管理テーブル７１は、テナントＩＤ「１」に対して、マシンＩＤ「２」、マシンタイプ「ｓｔａｎｄｂｙ」、イメージＩＤ「ｉｍａｇｅＸＸＸ１」のレコードを有する。このレコードは、待機系マシン３００を示すデータである。
例えば、管理テーブル７１は、テナントＩＤ「１」に対してテナントステータス「ｎｏｒｍａｌ」を保持する。また、管理テーブル７１は、マシンＩＤ「１」に対して、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」、イメージＩＤ「ｉｍａｇｅＸＸＸ１」のレコードを有する。当該レコードは、運用系マシン２００を示すデータである。また、管理テーブル７１は、テナントＩＤ「１」に対して、マシンＩＤ「２」、マシンタイプ「ｓｔａｎｄｂｙ」、イメージＩＤ「ｉｍａｇｅＸＸＸ１」のレコードを有する。このレコードは、待機系マシン３００を示すデータである。
【0074】
管理テーブル７１には、他のテナントが利用する仮想マシンのレコードも同様に登録され得る。
図７は、運用系／待機系マシンによる共有ストレージのマウント例を示す図である。
図７は、運用系／待機系マシンによる共有ストレージのマウント例を示す図である。
【0075】
運用系マシン２００が稼働中の場合、待機系マシン３００は停止される。この場合、共有ストレージ４００は、運用系マシン２００にマウントされる。待機系マシン３００が停止中の場合、共有ストレージ４００は、待機系マシン３００にはマウントされていない状態、すなわち、待機系マシン３００に対してはアンマウントの状態となる。運用系マシン２００は、ジョブ定義およびジョブ状態をテナント固有データとして共有ストレージ４００に書き込む。運用系マシン２００は、テナントによるジョブ定義の変更の入力に応じて、共有ストレージ４００のテナント固有データに含まれるジョブ定義を更新する。また、運用系マシン２００は、ジョブの実行に応じて、共有ストレージ４００のテナント固有データに含まれるジョブ状態を更新する。
【0076】
運用系マシン２００から待機系マシン３００への切り替えが行われる場合、共有ストレージ４００は運用系マシン２００からアンマウントされる。そして、待機系マシン３００が起動され、共有ストレージ４００は待機系マシン３００にマウントされる。すると、待機系マシン３００は、共有ストレージ４００から、運用系マシン２００により書き込まれた最新のテナント固有データを読み取り可能になる。待機系マシン３００は、ストレージ３０１に記憶されるテナント共通データおよび共有ストレージ４００に記憶されるテナント固有データに基づいて、運用系マシン２００からジョブを引き継いで実行する。
【0077】
次に、運用系マシン２００から待機系マシン３００への切り替えの処理手順を説明する。以下では、テナントＩＤ「１」のテナントに関する手順を説明するが、他のテナントに対しても同様の手順となる。
【0078】
図８は、運用系／待機系マシンの切り替えの例を示すフローチャートである。
（Ｓ１０）監視部４１は、運用系マシン２００における、ジョブの実行に係るサービスの異常を検知する。監視部４１は、サーバレス関数実行ノード５０にサーバレス関数５１の実行を指示する。すると、サーバレス関数５１が起動され、下記の処理が実行される。
（Ｓ１０）監視部４１は、運用系マシン２００における、ジョブの実行に係るサービスの異常を検知する。監視部４１は、サーバレス関数実行ノード５０にサーバレス関数５１の実行を指示する。すると、サーバレス関数５１が起動され、下記の処理が実行される。
【0079】
（Ｓ１１）サーバレス関数５１は、管理テーブル７１から、運用系マシン２００に対応するテナントＩＤとマシンタイプ「ｓｔａｎｄｂｙ」のマシンのマシンＩＤとを取得する。ここで、図中、マシンタイプ「ｓｔａｎｄｂｙ」を、「ｔｙｐｅ：ｓｔａｎｄｂｙ」のように略記することがある。
【0080】
（Ｓ１２）サーバレス関数５１は、ロードバランサ９０の接続先を削除する。具体的には、サーバレス関数５１は、ロードバランサ９０によるリクエストの転送先から、運用系マシン２００を削除する。
【0081】
（Ｓ１３）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」のマシンＩＤのマシン、すなわち、運用系マシン２００の該当のサービスを停止させる。
（Ｓ１４）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」のマシンＩＤのマシン、すなわち、運用系マシン２００の共有ストレージ４００をアンマウントする。
（Ｓ１４）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」のマシンＩＤのマシン、すなわち、運用系マシン２００の共有ストレージ４００をアンマウントする。
【0082】
（Ｓ１５）サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」のマシンＩＤのマシン、すなわち、待機系マシン３００を起動させる。
（Ｓ１６）サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」のマシンＩＤのマシン、すなわち、待機系マシン３００に、共有ストレージ４００をマウントする。
（Ｓ１６）サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」のマシンＩＤのマシン、すなわち、待機系マシン３００に、共有ストレージ４００をマウントする。
【0083】
（Ｓ１７）サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」のマシンＩＤのマシン、すなわち、待機系マシン３００の該当のサービスを起動させる。
（Ｓ１８）サーバレス関数５１は、ロードバランサ９０の接続先に待機系マシン３００を追加する。これにより、テナントのリクエストがロードバランサ９０によって待機系マシン３００へ振り分けられるようになる。
（Ｓ１８）サーバレス関数５１は、ロードバランサ９０の接続先に待機系マシン３００を追加する。これにより、テナントのリクエストがロードバランサ９０によって待機系マシン３００へ振り分けられるようになる。
【0084】
（Ｓ１９）サーバレス関数５１は、管理テーブル７１を更新する。具体的には、サーバレス関数５１は、待機系マシン３００のマシンタイプを「ｐｒｏｄｕｃｔｉｏｎ」に変更する。また、サーバレス関数５１は、運用系マシン２００を停止させ、運用系マシン２００のマシンタイプを「ｓｔａｎｄｂｙ」に変更する。そして、運用系マシン２００から待機系マシン３００への切り替えが終了する。
【0085】
第２の実施の形態のクラウドシステム２では、サーバレス関数５１の制御により、運用系マシン２００と待機系マシン３００とのデータの連携は共有ストレージ４００を用いて行われる。待機系マシン３００は、運用系マシン２００が更新した固有データを共有ストレージ４００から直接読み取れる。このため、運用系マシン２００と待機系マシン３００とで定期的なデータの同期処理を行わなくてよくなり、運用系マシン２００から待機系マシン３００へ切り替えるときに待機系マシン３００を起動させればよい。
【0086】
ただし、共有ストレージ４００は、運用系マシン２００および待機系マシン３００によりネットワーク経由で共有される。このため、切り替え時に共有ストレージ４００から待機系マシン３００へ比較的多量のデータを読み取らせると、当該データの読み取りに時間がかかる可能性がある。これは、切り替え完了の遅延の原因になり可用性に影響する。
【0087】
そこで、サーバレス関数５１は、運用系マシン２００のストレージ２０１および待機系マシン３００のストレージ３０１それぞれにテナント共通データを配置し、共有ストレージ４００にはテナント固有データが書き込まれるようにする。これにより、共有ストレージ４００にテナント共通データおよびテナント固有データの両方を書き込むよりも、切り替え時において待機系マシン３００により共有ストレージ４００から読み取るデータ量が低減される。その結果、運用系マシン２００の異常検知から待機系マシン３００によりサービスに係るジョブを再開までに要する時間が低減され、運用系マシン２００から待機系マシン３００への迅速な切り替えを行えるようになる。
【0088】
こうして、同期処理の都度、待機系マシン３００を起動して同期処理を行わずに済み、待機系マシン３００の実行に係る余計なコストを削減するとともに、待機系マシン３００への切り替えを高速化できる。すなわち、運用系マシン２００により提供されるサービスの可用性が効率的に向上される。
【0089】
更に、テナント共通データが共有ストレージ４００に保存されないので、テナント共通データおよびテナント固有データの両方を共有ストレージ４００に保存するよりも、共有ストレージ４００として割く記憶リソースを低減できるという利点もある。また、運用系マシン２００が異常により停止した場合でも、待機系マシン３００により共有ストレージ４００から最新のテナント固有データを取得して、ジョブ運用を継続できる利点もある。
【0090】
［第３の実施の形態］
次に、第３の実施の形態を説明する。前述の第２の実施の形態と相違する事項を主に説明し、共通する事項の説明を省略する。
次に、第３の実施の形態を説明する。前述の第２の実施の形態と相違する事項を主に説明し、共通する事項の説明を省略する。
【0091】
第３の実施の形態では、第２の実施の形態で例示したフェールオーバの処理を、運用系マシン２００により提供されるサービスのアップグレード時に利用する例を説明する。第３の実施の形態のクラウドシステム２のハードウェアや機能は、図２～図５で例示したハードウェアや機能と同様であるため説明を省略する。
【0092】
図９は、第３の実施の形態のマシン作成例を示す図である。
ＡＺ２ｃ１は、運用系マシン２００およびストレージ２０１に加えて、サービスアップグレード済マシン２００ａを有する。サービスアップグレード済マシン２００ａは、運用系マシン２００が提供するサービスの、アップグレード後のプログラムがインストールされた仮想マシンである。サービスアップグレード済マシン２００ａは、マシンイメージ６１を用いて作成される。マシンイメージ６１は、当該アップグレード後のプログラムがインストールされた仮想マシンのイメージデータである。図示を省略しているが、サービスアップグレード済マシン２００ａもローカルストレージを有し、当該ローカルストレージにアップグレード後のプログラムがテナント共通データとして格納される。
ＡＺ２ｃ１は、運用系マシン２００およびストレージ２０１に加えて、サービスアップグレード済マシン２００ａを有する。サービスアップグレード済マシン２００ａは、運用系マシン２００が提供するサービスの、アップグレード後のプログラムがインストールされた仮想マシンである。サービスアップグレード済マシン２００ａは、マシンイメージ６１を用いて作成される。マシンイメージ６１は、当該アップグレード後のプログラムがインストールされた仮想マシンのイメージデータである。図示を省略しているが、サービスアップグレード済マシン２００ａもローカルストレージを有し、当該ローカルストレージにアップグレード後のプログラムがテナント共通データとして格納される。
【0093】
ＡＺ２ｃ２は、待機系マシン３００およびストレージ３０１に加えて、サービスアップグレード済マシン３００ａを有する。サービスアップグレード済マシン３００ａは、運用系マシン２００が提供するサービスの、アップグレード後のプログラムがインストールされた仮想マシンである。サービスアップグレード済マシン３００ａも、マシンイメージ６１を用いて作成される。図示を省略しているが、サービスアップグレード済マシン３００ａもローカルストレージを有し、当該ローカルストレージにアップグレード後のプログラムがテナント共通データとして格納される。
【0094】
例えば、サービスアップグレード済マシン２００ａは、新たな待機系（新待機系）として用いられる。また、サービスアップグレード済マシン３００ａは、新たな運用系（新運用系）として用いられる。
【0095】
なお、マシンイメージ６１は、アップグレード後のプログラムであるテナント共通データを含むがテナント固有データを含まない。このため、マシンイメージ６１は、複数のテナントに対して使い回すことができる。よって、マシンイメージ６１をテナントごとに作成しなくてよいため、サービスアップグレード済の仮想マシンの配備を効率化できる。
【0096】
サービスアップグレード済マシン２００ａ，３００ａは、マシンイメージ６１から作成されて起動された直後に停止されて起動可能な状態のまま維持される。サーバレス関数５１は、サービスアップグレード済マシン２００ａ，３００ａを次のように管理する。
【0097】
図１０は、管理テーブルの例を示す図である。
管理テーブル７１ａは、サービスアップグレード済マシン２００ａ，３００ａの情報が管理テーブル７１に追加された場合を例示する。管理テーブル７１ａに含まれる項目は、管理テーブル７１に含まれる項目と同様である。
管理テーブル７１ａは、サービスアップグレード済マシン２００ａ，３００ａの情報が管理テーブル７１に追加された場合を例示する。管理テーブル７１ａに含まれる項目は、管理テーブル７１に含まれる項目と同様である。
【0098】
例えば、管理テーブル７１ａは、テナントＩＤ「１」に対して、テナントステータス「ｐａｔｃｈ」を保持する。テナントステータス「ｐａｔｃｈ」は、前述のように、サービスアップグレード済マシン２００ａ，３００ａを用意済の状態を示す。また、管理テーブル７１ａは、テナントＩＤ「１」に対して、マシンＩＤ「３」、マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」、イメージＩＤ「ｉｍａｇｅＸＸＸ２」のレコードを保持する。当該レコードは、サービスアップグレード済マシン２００ａを示すデータである。また、管理テーブル７１ａは、テナントＩＤ「１」に対して、マシンＩＤ「４」、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」、イメージＩＤ「ｉｍａｇｅＸＸＸ２」のレコードを保持する。当該レコードは、サービスアップグレード済マシン３００ａを示すデータである。ここで、イメージＩＤ「ｉｍａｇｅＸＸＸ２」は、マシンイメージ６１を示す。
【0099】
なお、管理テーブル７１ａでは、テナントＩＤ「２」のテナントの仮想マシンに関するデータが登録される例も示されている。
図１１は、サーバレス関数による管理テーブルの編集例を示す図である。
図１１は、サーバレス関数による管理テーブルの編集例を示す図である。
【0100】
サーバレス関数５１は、マシンイメージ６１からサービスアップグレード済マシン２００ａ，３００ａが作成されると、サービスアップグレード済マシン２００ａ，３００ａの情報を管理テーブル７１ａに登録する。
【0101】
サービスアップグレード済マシン２００ａ，３００ａの作成は、運用系マシン２００を起動状態として、運用系マシン２００を稼働させたまま行われる。サービスアップグレード済マシン２００ａ，３００ａは、何れも作成後に停止状態とされる。このようにして、サーバレス関数５１は、ＡＺ２ｃ１，２ｃ２にそれぞれサービスアップグレード済マシン２００ａ，３００ａを用意する。
【0102】
図１２は、サーバレス関数によるロードバランサの制御例を示す図である。
サーバレス関数５１は、運用系マシン２００によるジョブ実行が行われない時間帯に、ジョブの実行主体を現在の運用系マシン２００からサービスアップグレード済マシン３００ａ（新運用系）に切り替える。具体的には、サーバレス関数５１は、管理テーブル７１ａに基づいて、運用系マシン２００から共有ストレージ４００をアンマウントし、運用系マシン２００を停止させる。次に、サーバレス関数５１は、サービスアップグレード済マシン３００ａを起動させ、共有ストレージ４００をサービスアップグレード済マシン３００ａにマウントする。
サーバレス関数５１は、運用系マシン２００によるジョブ実行が行われない時間帯に、ジョブの実行主体を現在の運用系マシン２００からサービスアップグレード済マシン３００ａ（新運用系）に切り替える。具体的には、サーバレス関数５１は、管理テーブル７１ａに基づいて、運用系マシン２００から共有ストレージ４００をアンマウントし、運用系マシン２００を停止させる。次に、サーバレス関数５１は、サービスアップグレード済マシン３００ａを起動させ、共有ストレージ４００をサービスアップグレード済マシン３００ａにマウントする。
【0103】
そして、サーバレス関数５１は、管理テーブル７１ａに基づいて、テナントのリクエストの転送先を、運用系マシン２００からサービスアップグレード済マシン３００ａに切り替える設定を、ロードバランサ９０に対して行う。例えば、サーバレス関数５１は、ロードバランサ９０が保持する運用系マシン接続先情報における運用系マシン２００のホスト名またはＩＰアドレスを、サービスアップグレード済マシン３００ａのホスト名またはＩＰアドレスに書き換える。また、ロードバランサ９０が待機系マシン接続先情報を有する場合、待機系マシン接続先情報における待機系マシン３００のホスト名またはＩＰアドレスを、サービスアップグレード済マシン２００ａのホスト名またはＩＰアドレスに書き換えてもよい。
【0104】
このようにして、サーバレス関数５１により、運用系マシン２００での運用からサービスアップグレード済マシン３００ａでの運用への切り替えが行われる。
次に、運用系マシン２００からサービスアップグレード済マシン３００ａへの切り替えの処理手順を説明する。以下では、テナントＩＤ「１」のテナントに関する手順を説明するが、他のテナントに対しても同様の手順となる。
次に、運用系マシン２００からサービスアップグレード済マシン３００ａへの切り替えの処理手順を説明する。以下では、テナントＩＤ「１」のテナントに関する手順を説明するが、他のテナントに対しても同様の手順となる。
【0105】
図１３は、サービスアップグレード済マシン用意の例を示すフローチャートである。
下記の手順は、マシンイメージ６１からの仮想マシンの作成指示が監視部４１に入力されると、監視部４１によりサーバレス関数５１が起動されて実行される。当該仮想マシンの作成指示は、マシンイメージ管理ノード６０に入力されてもよく、マシンイメージ管理ノード６０によりサーバレス関数５１が起動されて、下記の手順が実行されてもよい。
下記の手順は、マシンイメージ６１からの仮想マシンの作成指示が監視部４１に入力されると、監視部４１によりサーバレス関数５１が起動されて実行される。当該仮想マシンの作成指示は、マシンイメージ管理ノード６０に入力されてもよく、マシンイメージ管理ノード６０によりサーバレス関数５１が起動されて、下記の手順が実行されてもよい。
【0106】
（Ｓ２０）サーバレス関数５１は、サービスアップグレード済マシン作成を行う。サービスアップグレード済マシン作成の詳細は後述される。サービスアップグレード済マシン作成は、運用系マシン２００によるジョブ運用中に実行される。
【0107】
（Ｓ２１）サーバレス関数５１は、管理テーブルのマシンタイプ更新を行う。マシンタイプ更新の詳細は後述される。
（Ｓ２２）サーバレス関数５１は、管理テーブルのテナントステータス更新を行う。例えば、サーバレス関数５１は、テナントＩＤ「１」に対応するテナントステータスを「ｎｏｒｍａｌ」から「ｐａｔｃｈ」に更新する。そして、サービスアップグレード済マシン用意が終了する。
（Ｓ２２）サーバレス関数５１は、管理テーブルのテナントステータス更新を行う。例えば、サーバレス関数５１は、テナントＩＤ「１」に対応するテナントステータスを「ｎｏｒｍａｌ」から「ｐａｔｃｈ」に更新する。そして、サービスアップグレード済マシン用意が終了する。
【0108】
図１０の管理テーブル７１ａは、ステップＳ２２のテナントステータスの更新が、ステップＳ２１のマシンタイプ更新の前に行われる場合の、当該マシンタイプ更新の直前の段階の管理テーブルを例示している。
【0109】
図１４は、サービスアップグレード済マシン作成の例を示すフローチャートである。
サービスアップグレード済マシン作成は、ステップＳ２０に相当する。
（Ｓ３０）サーバレス関数５１は、管理テーブル７１から、テナントＩＤ「１」に対応するマシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」、「ｓｔａｎｄｂｙ」のマシン、すなわち、運用系マシン２００、待機系マシン３００の情報を取得する。
サービスアップグレード済マシン作成は、ステップＳ２０に相当する。
（Ｓ３０）サーバレス関数５１は、管理テーブル７１から、テナントＩＤ「１」に対応するマシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」、「ｓｔａｎｄｂｙ」のマシン、すなわち、運用系マシン２００、待機系マシン３００の情報を取得する。
【0110】
（Ｓ３１）サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」のマシン、すなわち、待機系マシン３００が存在するサブネットを取得する。
（Ｓ３２）サーバレス関数５１は、ステップＳ３１で取得したサブネットに、サービスアップグレード済のマシンイメージ６１から、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」のマシン、すなわち、サービスアップグレード済マシン３００ａを作成する。ここで、サーバレス関数５１は、例えば現在の運用系マシン２００が存在するＡＺ２ｃ１とは異なるＡＺ２ｃ２に、サービスアップグレード済マシン３００ａを作成する。
（Ｓ３２）サーバレス関数５１は、ステップＳ３１で取得したサブネットに、サービスアップグレード済のマシンイメージ６１から、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」のマシン、すなわち、サービスアップグレード済マシン３００ａを作成する。ここで、サーバレス関数５１は、例えば現在の運用系マシン２００が存在するＡＺ２ｃ１とは異なるＡＺ２ｃ２に、サービスアップグレード済マシン３００ａを作成する。
【0111】
（Ｓ３３）サーバレス関数５１は、ステップＳ３２の作成によりサービスアップグレード済マシン３００ａ（マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」のマシン）が起動するため、サービスアップグレード済マシン３００ａを停止させる。
【0112】
（Ｓ３４）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」のマシン、すなわち、運用系マシン２００が存在するサブネットを取得する。
（Ｓ３５）サーバレス関数５１は、ステップＳ３４で取得したサブネットに、サービスアップグレード済のマシンイメージ６１から、マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」のマシン、すなわち、サービスアップグレード済マシン２００ａを作成する。ここで、サーバレス関数５１は、例えば、新運用系となるサービスアップグレード済マシン３００ａが存在するＡＺ２ｃ２とは異なるＡＺ２ｃ１に、サービスアップグレード済マシン２００ａを作成する。
（Ｓ３５）サーバレス関数５１は、ステップＳ３４で取得したサブネットに、サービスアップグレード済のマシンイメージ６１から、マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」のマシン、すなわち、サービスアップグレード済マシン２００ａを作成する。ここで、サーバレス関数５１は、例えば、新運用系となるサービスアップグレード済マシン３００ａが存在するＡＺ２ｃ２とは異なるＡＺ２ｃ１に、サービスアップグレード済マシン２００ａを作成する。
【0113】
（Ｓ３６）サーバレス関数５１は、ステップＳ３５において作成したサービスアップグレード済マシン２００ａ（マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」のマシン）が起動するため、サービスアップグレード済マシン２００ａを停止させる。
【0114】
（Ｓ３７）サーバレス関数５１は、サービスアップグレード済マシン２００ａ，３００ａの情報を管理テーブル７１に追加する。そして、サービスアップグレード済マシン作成が終了する。
【0115】
図１５は、管理テーブルのマシンタイプ更新の例を示すフローチャートである。
管理テーブルのマシンタイプ更新は、ステップＳ２１に相当する。
（Ｓ４０）サーバレス関数５１は、テナントＩＤ「１」に対応する各マシンのマシンタイプを取得する。
管理テーブルのマシンタイプ更新は、ステップＳ２１に相当する。
（Ｓ４０）サーバレス関数５１は、テナントＩＤ「１」に対応する各マシンのマシンタイプを取得する。
【0116】
（Ｓ４１）サーバレス関数５１は、ステップＳ３７の更新後の管理テーブルに含まれるテナント「１」の各仮想マシンのマシンタイプを次のように更新する。サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」を「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」に更新する。サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」を「ｓｔａｎｄｂｙ」に更新する。サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」を「ｓｔａｎｄｂｙ＿ｏｌｄ」に更新する。サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」を「ｐｒｏｄｕｃｔｉｏｎ」に更新する。そして、管理テーブルのマシンタイプ更新が終了する。
【0117】
図１６は、管理テーブルのマシンタイプ更新の具体例を示す図である。
サーバレス関数５１は、ステップＳ３７で管理テーブル７１を管理テーブル７１ｂに更新する。サーバレス関数５１は、図１５で例示した手順により、管理テーブル７１ｂを管理テーブル７１ｃに更新する。管理テーブル７１ｃは、ステップＳ４１における更新後の管理テーブルを示す。その後、サーバレス関数５１は、ステップＳ２２を実行することで、管理テーブル７１ｃのテナントステータス「ｎｏｒｍａｌ」を「ｐａｔｃｈ」に更新する。管理テーブル７１ｄは、管理テーブル７１ｃのテナントステータス「ｎｏｒｍａｌ」を「ｐａｔｃｈ」に更新した状態を示す。
サーバレス関数５１は、ステップＳ３７で管理テーブル７１を管理テーブル７１ｂに更新する。サーバレス関数５１は、図１５で例示した手順により、管理テーブル７１ｂを管理テーブル７１ｃに更新する。管理テーブル７１ｃは、ステップＳ４１における更新後の管理テーブルを示す。その後、サーバレス関数５１は、ステップＳ２２を実行することで、管理テーブル７１ｃのテナントステータス「ｎｏｒｍａｌ」を「ｐａｔｃｈ」に更新する。管理テーブル７１ｄは、管理テーブル７１ｃのテナントステータス「ｎｏｒｍａｌ」を「ｐａｔｃｈ」に更新した状態を示す。
【0118】
図１７は、サービスアップグレード制御の例を示すフローチャートである。
下記の手順の実行主体をサーバレス関数５１として記載するが、下記の手順はサービスアップグレード済マシン用意を実行するサーバレス関数５１とは異なるサーバレス関数により実行されてもよい。例えば、サーバレス関数５１は所定の常駐プロセスにより定期的に起動されて、下記の手順を実行する。当該常駐プロセスは、例えば監視ノード４０で実行されてもよいし、サーバレス関数実行ノード５０で実行されてもよい。
下記の手順の実行主体をサーバレス関数５１として記載するが、下記の手順はサービスアップグレード済マシン用意を実行するサーバレス関数５１とは異なるサーバレス関数により実行されてもよい。例えば、サーバレス関数５１は所定の常駐プロセスにより定期的に起動されて、下記の手順を実行する。当該常駐プロセスは、例えば監視ノード４０で実行されてもよいし、サーバレス関数実行ノード５０で実行されてもよい。
【0119】
（Ｓ５０）サーバレス関数５１は、管理テーブル７１ｃから、該当のテナントのテナントステータスを取得する。なお、一例として、テナントＩＤ「１」のテナントに対する手順を示すが、他のテナントに対しても同様の手順となる。
【0120】
（Ｓ５１）サーバレス関数５１は、テナントステータスが「ｐａｔｃｈ」であるか否かを判定する。テナントステータスが「ｐａｔｃｈ」の場合、ステップＳ５３に処理が進む。テナントステータスが「ｐａｔｃｈ」ではない場合、すなわち、テナントステータスが「ｎｏｒｍａｌ」の場合、ステップＳ５２に処理が進む。
【0121】
（Ｓ５２）サーバレス関数５１は、一定時間待機する。なお、ステップＳ５２では、常駐プロセスが一定時間待機し、一定時間経過後にサーバレス関数５１を起動するようにしてもよい。そして、ステップＳ５０に処理が進む。
【0122】
（Ｓ５３）サーバレス関数５１は、サービスアップグレード可否判定を行う。サービスアップグレード可否判定の詳細は後述される。サーバレス関数５１は、サービスアップグレード可否判定において、サービスアップグレードが可能と判定されると、ステップＳ５４に処理を進める。
【0123】
（Ｓ５４）サーバレス関数５１は、ロードバランサ９０の接続先を削除する。具体的には、サーバレス関数５１は、ロードバランサ９０の接続先から、該当のテナントの運用系マシン２００の情報を削除する。
【0124】
（Ｓ５５）サーバレス関数５１は、フェールオーバの各処理を実行する。フェールオーバの各処理の詳細は後述される。フェールオーバの各処理により、管理テーブル７１ｃが更新され、ロードバランサ９０の接続先に新運用系の仮想マシンを追加する準備が整う。
【0125】
（Ｓ５６）サーバレス関数５１は、ロードバランサ９０の接続先に新運用系を追加する。具体的には、サーバレス関数５１は、新運用系の仮想マシンである、サービスアップグレード済マシン３００ａの情報を、ロードバランサ９０の接続先に追加する。
【0126】
（Ｓ５７）サーバレス関数５１は、該当のテナントについて、管理テーブルのテナントステータスを「ｎｏｒｍａｌ」に更新する。そして、ステップＳ５０に処理が進む。次のステップＳ５０以降の手順では、次のテナントに対するサービスアップグレード制御が行われる。
【0127】
図１８は、サービスアップグレード可否判定の例を示すフローチャートである。
サービスアップグレード可否判定は、ステップＳ５３に相当する。
（Ｓ６０）サーバレス関数５１は、該当のテナントのジョブの実行状態を取得する。例えば、サーバレス関数５１は、運用系マシン２００からジョブの実行状態を取得してもよい。例えば、運用系マシン２００は、共有ストレージ４００に格納されているジョブ実行状態の情報を取得し、サーバレス関数５１に提供してもよい。
サービスアップグレード可否判定は、ステップＳ５３に相当する。
（Ｓ６０）サーバレス関数５１は、該当のテナントのジョブの実行状態を取得する。例えば、サーバレス関数５１は、運用系マシン２００からジョブの実行状態を取得してもよい。例えば、運用系マシン２００は、共有ストレージ４００に格納されているジョブ実行状態の情報を取得し、サーバレス関数５１に提供してもよい。
【0128】
（Ｓ６１）サーバレス関数５１は、当該ジョブのスケジュールを取得する。例えば、サーバレス関数５１は、運用系マシン２００からジョブのスケジュールを取得してもよい。例えば、運用系マシン２００は、共有ストレージ４００に格納されているジョブ定義の情報を取得し、ジョブ定義の情報に含まれるスケジュールの情報をサーバレス関数５１に提供してもよい。
【0129】
（Ｓ６２）サーバレス関数５１は、ステップＳ６０，Ｓ６１で取得したジョブ実行状態およびジョブのスケジュールに基づいて、現在、サービスアップグレードが可能であるか否かを判定する。現在、サービスアップグレードが可能な場合、サービスアップグレード可否判定が終了する。現在、サービスアップグレードが不可能な場合、ステップＳ６３に処理が進む。例えば、サーバレス関数５１は、運用系マシン２００でジョブを実行中の場合またはジョブの実行開始までの時刻が所定時間内に迫っている場合に、現在、サービスアップグレードが不可能であると判定してもよい。一方、サーバレス関数５１は、運用系マシン２００でジョブを実行中でなく、かつ、ジョブの実行開始までの時刻が現時点から所定時間よりも後である場合に、現在、サービスアップグレードが可能と判定してもよい。なお、ステップＳ６２の判定に用いられる所定時間は、フェールオーバの所要時間に応じて予め定められる。
【0130】
（Ｓ６３）サーバレス関数５１は、一定時間待機する。そして、ステップＳ６０に処理が進む。
このように、サーバレス関数５１は、運用系マシン２００によるジョブが中断されたり、スケジュール通りに実行されなかったりすることがないように、サービスアップグレードにおけるフェールオーバの実行タイミングを決定する。これにより、運用系マシン２００によるジョブ運用への影響が低減される。
このように、サーバレス関数５１は、運用系マシン２００によるジョブが中断されたり、スケジュール通りに実行されなかったりすることがないように、サービスアップグレードにおけるフェールオーバの実行タイミングを決定する。これにより、運用系マシン２００によるジョブ運用への影響が低減される。
【0131】
図１９は、フェールオーバの各処理の例を示すフローチャートである。
フェールオーバの各処理は、ステップＳ５５に相当する。
（Ｓ７０）サーバレス関数５１は、処理対象のテナントのテナントＩＤに対応するマシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」、「ｐｒｏｄｕｃｔｉｏｎ」のマシンＩＤを、管理テーブル７１ｃから取得する。
フェールオーバの各処理は、ステップＳ５５に相当する。
（Ｓ７０）サーバレス関数５１は、処理対象のテナントのテナントＩＤに対応するマシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」、「ｐｒｏｄｕｃｔｉｏｎ」のマシンＩＤを、管理テーブル７１ｃから取得する。
【0132】
（Ｓ７１）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」のマシンＩＤのマシン、すなわち、運用系マシン２００のサービスを停止する。
（Ｓ７２）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」のマシンＩＤのマシン、すなわち、運用系マシン２００の共有ストレージ４００をアンマウントする。
（Ｓ７２）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」のマシンＩＤのマシン、すなわち、運用系マシン２００の共有ストレージ４００をアンマウントする。
【0133】
（Ｓ７３）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｉｔｏｎ」のマシンＩＤのマシン、すなわち、サービスアップグレード済マシン３００ａを起動する。
（Ｓ７４）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｉｔｏｎ」のマシンＩＤのマシン、すなわち、サービスアップグレード済マシン３００ａに共有ストレージ４００をマウントする。
（Ｓ７４）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｉｔｏｎ」のマシンＩＤのマシン、すなわち、サービスアップグレード済マシン３００ａに共有ストレージ４００をマウントする。
【0134】
（Ｓ７５）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｉｔｏｎ」のマシンＩＤのマシン、すなわち、サービスアップグレード済マシン３００ａのサービスを起動する。
【0135】
（Ｓ７６）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」のマシンＩＤのマシン、すなわち、運用系マシン２００を停止する。
（Ｓ７７）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」、「ｓｔａｎｄｂｙ＿ｏｌｄ」それぞれのマシンＩＤのマシン、すなわち、運用系マシン２００および待機系マシン３００を削除する。
（Ｓ７７）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」、「ｓｔａｎｄｂｙ＿ｏｌｄ」それぞれのマシンＩＤのマシン、すなわち、運用系マシン２００および待機系マシン３００を削除する。
【0136】
（Ｓ７８）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」、「ｓｔａｎｄｂｙ＿ｏｌｄ」それぞれのマシンＩＤのマシン、すなわち、運用系マシン２００および待機系マシン３００の情報を管理テーブル７１ｃから削除する。そして、フェールオーバの各処理が終了する。
【0137】
こうして、管理テーブル７１ｃから旧運用系の仮想マシン、および、旧待機系の仮想マシンの情報が削除され、その後、ステップＳ５７により該当のテナントのテナントステータスが「ｐａｔｃｈ」から「ｎｏｒｍａｌ」に変更される。サービスアップグレード済マシン３００ａは、運用系マシン２００により更新されたテナント固有データを共有ストレージ４００から直接読み取ることができる。また、サービスアップグレード済マシン３００ａのローカルストレージには、テナント共通データが格納されている。このため、サービスアップグレード済マシン３００ａは、テナント共通データとテナント固有データとに基づいて、運用系マシン２００からサービスのジョブを引き継いで実行することができる。
【0138】
このように、サーバレス関数５１は、運用系マシン２００からサービスアップグレード済マシン３００ａへの切り替えの際にも、共有ストレージ４００を介して両マシンによる固有データの共有を行うことで、当該切り替えを効率的に行える。例えば、共有ストレージ４００にテナント共通データおよびテナント固有データの両方を書き込むよりも、切り替え時においてサービスアップグレード済マシン３００ａにより共有ストレージ４００から読み取るデータ量が低減される。その結果、運用系マシン２００の代わりにサービスアップグレード済マシン３００ａによりサービスに係るジョブを再開までに要する時間が低減され、運用系マシン２００からサービスアップグレード済マシン３００ａへの迅速な切り替えを行えるようになる。
【0139】
次に、第２の実施の形態および第３の実施の形態に対する比較例を説明する。
図２０は、比較例を示す図である。
比較例は、ＡＺ２ｃ１，２ｃ２内の各仮想マシンにマウント可能な共有ストレージ４００ではなく、クラウドシステム２が提供する外部ストレージ５ｂを用いて、ＡＺ２ｃ１，２ｃ２内の各仮想マシンでデータを同期する場合である。外部ストレージ５ｂは、クラウドシステム２の比較的上位のネットワークに設けられ、ＡＺ２ｃ１，２ｃ２内の各仮想マシンにマウントすることはできない。外部ストレージ５ｂは、管理ノード５ａによりアクセスされる。管理ノード５ａは、例えば監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０と同じ階層のネットワークに設けられる。
図２０は、比較例を示す図である。
比較例は、ＡＺ２ｃ１，２ｃ２内の各仮想マシンにマウント可能な共有ストレージ４００ではなく、クラウドシステム２が提供する外部ストレージ５ｂを用いて、ＡＺ２ｃ１，２ｃ２内の各仮想マシンでデータを同期する場合である。外部ストレージ５ｂは、クラウドシステム２の比較的上位のネットワークに設けられ、ＡＺ２ｃ１，２ｃ２内の各仮想マシンにマウントすることはできない。外部ストレージ５ｂは、管理ノード５ａによりアクセスされる。管理ノード５ａは、例えば監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０と同じ階層のネットワークに設けられる。
【0140】
比較例では、ＡＺ２ｃ１は監視部２１０を有する。監視部２１０は、運用系マシン２００を監視し、管理ノード５ａと連携する。監視部２１０は、運用系マシン２００により実現されてもよいし、ＡＺ２ｃ１内の、運用系マシン２００とは異なる仮想マシンにより実現されてもよい。同様に、ＡＺ２ｃ２は監視部３１０を有する。監視部３１０は、待機系マシン３００を監視し、管理ノード５ａと連携する。監視部３１０は、待機系マシン３００により実現されてもよいし、ＡＺ２ｃ２内の、待機系マシン３００とは異なる仮想マシンにより実現されてもよい。例えば、監視部２１０は、運用系マシン２００の異常を検知すると、管理ノード５ａにより運用系マシン２００から待機系マシン３００への切り替えを指示する。
【0141】
ここで、比較例の構成では、運用系マシン２００は、ローカルのストレージ２０１に、テナント共通データ（プログラム）およびテナント固有データ（ジョブ定義およびジョブ状態）の両方を書き込む。そして、ストレージ２０１におけるテナント共通データやテナント固有データが更新されると、待機系マシン３００との同期のために、更新後のデータが外部ストレージ５ｂに書き込まれる。
【0142】
管理ノード５ａは、同期を行う際に、待機系マシン３００を起動させる。起動した待機系マシン３００は、外部ストレージ５ｂから最新のデータを取得し、ローカルのストレージ３０１に反映させる。
【0143】
しかし、このように同期処理のたびに、待機系マシン３００を実行すると計算リソースが消費され、テナントが本来実行したいジョブの他に、同期処理のためのコストが発生するという問題がある。
【0144】
すなわち、比較例の方法では、可用性は維持できるが外部ストレージ５ｂに更新がある毎に待機系マシン３００を起動するため、待機系マシン３００の起動時間が増加する分、運用コストの増加が起きる。
【0145】
そこで、第２の実施の形態で例示したように、サーバレス関数実行ノード５０は、運用系マシン２００と待機系マシン３００とのデータの連携が、共有ストレージ２５を用いて行われるようにする。待機系マシン３００は、運用系マシン２００が更新した固有データを共有ストレージ４００から読み取れる。これにより、運用系マシン２００と待機系マシン３００との間で定期的な、あるいは、データ更新毎のデータの同期処理を行わなくてよくなり、運用系マシン２００から待機系マシン３００へ切り替えるときに待機系マシン３００を起動させればよい。
【0146】
ただし、共有ストレージ４００を運用系マシン２００および待機系マシン３００からマウント可能とするなどの方法により両マシンで共有する場合、共有ストレージ４００は、運用系マシン２００および待機系マシン３００によりネットワーク経由で共有される。このため、切り替え時に共有ストレージ４００から待機系マシン３００へ比較的多量のデータを読み取らせると、当該データの読み取りに時間がかかる可能性がある。これは、切り替え完了の遅延の原因になり可用性に影響する。
【0147】
そこで、サーバレス関数実行ノード５０は、運用系マシン２００のストレージ２０１および待機系マシン３００のストレージ３０１それぞれにテナント共通データが配置され、共有ストレージ４００にはテナント固有データが書き込まれるようにする。これにより、共有ストレージ４００にテナント共通データおよびテナント固有データの両方を書き込むよりも、切り替え時において待機系マシン３００により共有ストレージ４００から読み取るデータ量が低減される。その結果、例えば運用系マシン２００の異常検知から待機系マシン３００によりサービスに係るジョブを再開までに要する時間が低減され、運用系マシン２００から待機系マシン３００への迅速な切り替えを行えるようになる。
【0148】
こうして、サーバレス関数実行ノード５０は、同期処理の都度、待機系マシン３００を起動して同期処理を行う方法に比べて、当該同期処理を省略することで待機系マシン３００の実行に係る余計なコストを削減するとともに、フェールオーバを高速化できる。すなわち、サーバレス関数実行ノード５０は、運用系マシン２００により提供されるサービスの可用性を効率的に向上できる。
【0149】
更に、テナント共通データが共有ストレージ４００に保存されないので、テナント共通データおよびテナント固有データの両方を共有ストレージ４００に保存するよりも、共有ストレージ４００として割く記憶リソースを低減できるという利点もある。
【0150】
第３の実施の形態で例示した、運用系マシン２００からサービスアップグレード済マシン３００ａへの切り替えの際も、運用系マシン２００から待機系マシン３００への切り替えと同様の利点がある。すなわち、第３の実施の形態においても、サーバレス関数実行ノード５０は、運用系マシン２００により提供されるサービスの可用性を効率的に向上できる。
【0151】
また、ジョブ実行では高頻度でデータ書き込みが発生するため、比較例の方法では、待機系マシン３００のストレージ３０１の更新を行う頻度が多くなり、待機系マシン３００の起動状態が続く。よって、サービスアップグレードのための隙間時間が確保できないため、ジョブ運用を止める必要がある。また、ジョブ運用を止めるため、サービスアップグレードのためにテナントとの時間調整の手間がかかる問題もある。
【0152】
一方、第３の実施の形態で例示したように、サーバレス関数実行ノード５０によれば、サービスアップグレードのために運用系マシン２００によるジョブ運用を止めなくて済む。すなわち、サーバレス関数実行ノード５０は、ジョブ運用への影響を抑えて、サービスアップグレード済マシン３００ａへの円滑な切り替えを行える。
【0153】
以上説明したように、サーバレス関数実行ノード５０に用いられるプロセッサ１０１は次の処理を実行する。下記の処理は、プロセッサ１０１がサーバレス関数５１に相当するプログラムを実行することで実現されてもよい。
【0154】
プロセッサ１０１は、複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードの第１記憶部および待機系ノードの第２記憶部それぞれに、複数のユーザそれぞれに対応するジョブの実行に共通に用いられる共通データを配置する。プロセッサ１０１は、運用系ノードによるジョブの実行に応じて、または第１ユーザにより更新される、第１ユーザに対応するジョブの固有データを運用系ノードから共有ストレージに書き込ませる。例えば、プロセッサ１０１は、運用系ノードに共有ストレージをマウントし、固有データの書き込み先を共有ストレージに指定することで、運用系ノードにより固有データを共有ストレージに書き込ませる。それとともに、プロセッサ１０１は、運用系ノードの稼働中には待機系ノードを停止状態とする。プロセッサ１０１は、ジョブの実行主体を運用系ノードから待機系ノードに切り替える際に、待機系ノードを起動し、共有ストレージからの、待機系ノードによる固有データの読み取りを可能にする設定を行う。
【0155】
これにより、プロセッサ１０１は、サービスの可用性を効率的に向上できる。例えば、同期処理のために運用系ノードの稼働中に待機系ノードを起動させずに済み、待機系ノードの実行時間を減らせる。よって、待機系ノードの利用に伴うコストが低減される。また、待機系ノードは、切り替え時に共有ストレージから固有データを読み取ればよく、共有ストレージから共通データを読み取らなくてよい。このため、切り替え時のデータ読み込みの時間が短縮され、切り替えの高速化が図られる。なお、運用系マシン２００は、運用系ノードの一例である。待機系マシン３００は、待機系ノードの一例である。ストレージ２０１は、第１記憶部の一例である。ストレージ３０１は、第２記憶部の一例である。運用系マシン２００および待機系マシン３００に対応する共有ストレージは、共有ストレージ４００である。また、ユーザは、テナントと言われてもよい。更に、プロセッサ１０１は、通信インタフェース１０７を介して、運用系ノードや待機系ノードと通信する。
【0156】
例えば、共有ストレージは、運用系ノードおよび待機系ノードにマウント可能である。プロセッサ１０１は、待機系ノードによる固有データの読み取りを可能にする設定では、共有ストレージを待機系ノードにマウントする。
【0157】
これにより、プロセッサ１０１は、運用系ノードと待機系ノードとのデータ共有を容易に実現できる。例えば、プロセッサ１０１は、通信インタフェース１０７を介して、待機系ノードのＯＳへマウントコマンドを入力して実行させればよく、データ共有のために特別なソフトウェアを運用系ノードや待機系ノードへ導入しなくて済む。
【0158】
プロセッサ１０１は、待機系ノードによる固有データの読み取りを可能にする設定では、共有ストレージを待機系ノードにマウントする前に、運用系ノードから共有ストレージをアンマウントする。
【0159】
これにより、プロセッサ１０１は、運用系ノードおよび待機系ノードの両方から共有ストレージに保持される固有データが更新されることを防ぎ、固有データの整合性を保てる。
【0160】
また、プロセッサ１０１は、運用系ノードから共有ストレージをアンマウントする前に、中継ノードが保持する接続先情報から運用系ノードの情報を削除する。ここで、中継ノードは、端末装置４などのアクセス元ノードにより送信されるリクエストを運用系ノードや待機系ノードへ中継するノードである。ロードバランサ９０は、中継ノードの一例である。そして、プロセッサ１０１は、共有ストレージを待機系ノードにマウントした後に、中継ノードが保持する接続先情報に待機系ノードの情報を追加する。
【0161】
これにより、プロセッサ１０１は、アクセス元ノードのリクエストが、運用系ノードに代えて、待機系ノードに振り分けられるように設定できる。また、プロセッサ１０１は、切り替えの最中に、運用系ノードや待機系ノードへリクエストが転送されることを防げる。
【0162】
また、共通データは、例えばジョブを動作させるジョブ管理ソフトウェアなどのプログラム、すなわち、所定プログラムである。プロセッサ１０１は、所定プログラムをアップグレードした新ノードをクラウドシステム２上に用意して停止状態としてもよい。プロセッサ１０１は、ジョブの実行主体を運用系ノードから新ノードに切り替える際に、新ノードを起動し、共有ストレージからの、新ノードによる固有データの読み取りを可能にする設定を行ってもよい。例えば、プロセッサ１０１は、新ノードによる固有データの読み取りを可能にする設定では、共有ストレージを新ノードにマウントする。前述のサービスアップグレード済マシン３００ａは新ノードの一例である。
【0163】
これにより、プロセッサ１０１は、サービスの可用性を効率的に向上できる。例えば、切り替え時だけ新ノードを起動させればよいので、同期処理のために運用系ノードの稼働中に新ノードを起動させずに済み、新ノードの実行時間を減らせる。よって、新ノードの利用に伴うコストが低減される。また、新ノードは、切り替え時に共有ストレージからテナント固有データを読み取ればよく、共有ストレージから共通データを読み取らなくてよい。このため、切り替え時のデータ読み込みの時間が短縮され、切り替えの高速化が図られる。なお、新ノードの用意は、当該新ノードに対応するマシンイメージのデータに基づいてクラウドシステム２上に新ノードを作成することで行われる。
【0164】
プロセッサ１０１は、新ノードを用意すると、ノードの管理に用いられる管理テーブルに、運用系ノードに対して新ノードを用意済であることを記録してもよい。例えば、管理テーブル７１ａにおけるテナントステータス「ｐａｔｃｈ」は新ノードを用意済であることを示す。プロセッサ１０１は、管理テーブルに基づいて新ノードを用意済であることを検出すると、運用系ノードのジョブの実行状況に応じてジョブの実行主体を運用系ノードから新ノードに切り替えるタイミングを決定する。例えば、プロセッサ１０１は、運用系ノードによるジョブの定義情報からジョブの実行スケジュールを取得し、当該ジョブが実行されない空き時間を特定し、当該空き時間に含まれる時刻を切り替えのタイミングとして決定してもよい。プロセッサ１０１は、決定したタイミングにおいてジョブの実行主体を運用系ノードから新ノードに切り替える際に、管理テーブルにおいて、運用系ノードの情報を削除し、新ノードを新たな運用系として設定する。
【0165】
これにより、プロセッサ１０１は、運用系ノードから新ノードへの切り替えに伴うジョブの実行への影響を抑えて、管理テーブルにより現在運用系となっている仮想マシンを適切に管理できる。
【0166】
また、運用系ノードは、第１アベイラビリティゾーン（例えばＡＺ２ｃ１）で動作してもよい。待機系ノードは、第２アベイラビリティゾーン（例えばＡＺ２ｃ２）で動作してもよい。この場合、プロセッサ１０１は、第１アベイラビリティゾーンおよび第２アベイラビリティゾーンのうちの一方のアベイラビリティゾーンに新ノードを用意し、他方のアベイラビリティゾーンに新ノードに対応する待機系のノードを用意してもよい。
【0167】
このように、プロセッサ１０１は、運用系／待機系マシンを異なるアベイラビリティゾーンに配置することで、アベイラビリティゾーンでの障害に対する耐障害性を高め、サービスの可用性を向上させることができる。なお、第１アベイラビリティゾーンは、運用系ノードが割り当てられる１以上の第１データセンタの集合と言われてもよいし、当該１以上の第１データセンタが属するゾーンと言われてもよい。第２アベイラビリティゾーンは、待機系ノードが割り当てられる１以上の第２データセンタの集合と言われてもよいし、当該１以上の第２データセンタが属するゾーンと言われてもよい。
【0168】
また、共通データは、例えばジョブを動作させる所定プログラムである。また、固有データは、例えば当該所定プログラムによって使用される、ジョブの定義およびジョブの状態を示す情報である。
【0169】
このように、プロセッサ１０１は、所定プログラムによりジョブ管理を行う運用系ノードや待機系ノードにより提供されるサービスの可用性の向上に特に有効である。プロセッサ１０１は、運用系ノードにより提供されるジョブ管理のサービスの可用性を効率的に向上できる。
【0170】
なお、第１の実施の形態の情報処理は、処理部１２にプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１１３に記録できる。
【0171】
例えば、プログラムを記録した記録媒体１１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
【符号の説明】
【0172】
１０ 情報処理装置
１１ 記憶部
１２ 処理部
１３ 通信部
２０ 情報処理システム
２１ 運用系ノード
２２ 待機系ノード
２３ 第１記憶部
２４ 第２記憶部
２５ 共有ストレージ
２６ 中継ノード
３０ アクセス元ノード
１１ 記憶部
１２ 処理部
１３ 通信部
２０ 情報処理システム
２１ 運用系ノード
２２ 待機系ノード
２３ 第１記憶部
２４ 第２記憶部
２５ 共有ストレージ
２６ 中継ノード
３０ アクセス元ノード
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】