JP5704756B2

JP5704756B2 - コマンドスケジュール対応型クラウド統一操作システムおよび方法

Info

Publication number: JP5704756B2
Application number: JP2011083428A
Authority: JP
Inventors: 敦奥谷
Original assignee: Hitachi Solutions Ltd
Current assignee: Hitachi Solutions Ltd
Priority date: 2011-04-05
Filing date: 2011-04-05
Publication date: 2015-04-22
Anticipated expiration: 2031-04-05
Also published as: JP2012221019A

Description

本発明は、マルチプラットフォームから構成されるクラウドシステムにおいて、投入されたコマンドのスケジューリングを自立的に行う仮想環境制御技術に関するものである。

情報システムの発達に伴い、ひとつのクラウドシステム内に複数のプラットフォームが混在するケースが増えてきている。これらの情報システムは、同種の操作を行う際、プラットフォームごとに異なるコマンドを投入する必要があり、すべて同種のシステムで構成した場合に比べて管理上の負担が大きいという問題がある。また、エンドユーザに仮想サーバを操作させるクラウドシステムでは、仮想サーバを操作するコマンド処理部に対して同時に大量の仮想サーバを操作するコマンドが投入されることがある。このような問題を解消するため、情報システム上の複数のプラットフォームを一元管理する装置を設け、プラットフォームの差異を吸収するとともに、同時に投入された仮想サーバの操作コマンドをスケジューリングする仕組みが必要とされている。

本発明に関連する公知技術文献としては下記の特許文献１がある。この文献には、所定のシステムを構成する各装置に対して、運用管理者が共通のコマンドフォーマットでそれら各装置の設定を可能とし、共通フォーマットを各装置用のコマンドに変換してから各装置に投入して各装置の設定を行う技術が開示されている。

図８は、そのような一元管理を行うシステムの例を示す。このシステムは、ネットワーク８１０に接続された仮想ノード８１８であり、該仮想ノード８１８は、ルータ８１１、スイッチ８１２、ファイアウォール８１３、スイッチ８１４、負荷分散装置８１５、スイッチ８１６、およびサーバファーム８１７を備えている。また、運用管理統合ノード８１９を備えており、該運用管理統合ノード８１９により、仮想ノード８１８の構成要素である各装置を管理する。運用管理統合ノード８１９は、運用管理者が共通のコマンドフォーマットで各装置の設定を可能とし、共通フォーマットを各装置用のコマンドに変換してから各装置に投入して、各装置の設定を行うことができる。また、共通フォーマットの設定定義の整合性チェックも行う。例えば、スイッチ８１２，８１４，８１６がそれぞれ異なるコマンドフォーマットのコマンドを受け付ける装置であったとしても、運用管理者は運用管理統合ノード８１９から共通のコマンドフォーマットでこれら各スイッチ８１２，８１４，８１６の設定を行うことができる。

特開２００５−１９７８２６号公報

上述したように１つのクラウドシステム内に複数のプラットフォームが混在するケースでは、異なるプラットフォームの仮想サーバに投入する操作コマンドを、すべて共通の形式で操作できるようにして、クラウドシステムに混在するプラットフォームにおける仮想サーバの操作コマンドを一元的に管理することが求められている。

また、仮想サーバのプラットフォームが複数混在しているようなクラウドシステムでは、仮想サーバの総数が数千から数万に及ぶことも珍しくなく、それらの仮想サーバに対する起動や停止といったコマンドが同時に大量に投入されることがあるが、仮想サーバを制御するコマンド処理部は投入されたコマンドを処理しきれずにハングアップしたり異常に遅延するなどの問題が発生することがある。コマンド処理部がこのような状態になった場合、該当のコマンド処理部が管理する仮想サーバの操作が行えなくなり、顧客満足度が低下する可能性がある。

そのような同時に大量のコマンドが投入された場合の不具合を解消するためには、投入されたコマンドをキューに格納し、１コマンドずつ実行することが考えられる。

しかし、単にコマンドをキューに格納し、順次コマンドを実行するようにしただけでは、大量にコマンドがキューに格納されているときには新たなコマンドを投入しても、実際にコマンドが実行されるまでに時間がかかることがある。クラウドシステムでは、ある時点におけるシステム負荷に応じて自由にスケールアウトするといった運用が一般的であるが、意図したタイミングにコマンドを実行できないとクラウドシステムのメリットを生かした運用ができなくなるという問題がある。このため、効率的にコマンドを実行できるようなスケジューリングを行うとともに、緊急時には管理者が最優先でコマンドを実行できるような仕組みが求められている。

本発明の目的は、マルチプラットフォームからなるクラウドシステムにおいて、単純なコマンドのキューイングではなく、ユーザから同時に大量のコマンドが投入された場合でも、物理サーバへのコマンドの投入が効率的になるように制御して、物理サーバへの動作の影響を最小限に抑えることができるコマンドスケジュール対応型クラウド操作システムおよび方法を提供することにある。

上記目的を達成するため、請求項１に係る発明は、ホスト端末と、該ホスト端末からコマンドを受け取る制御サーバとを備えるコマンドスケジュール対応型クラウド統一操作システムであって、前記ホスト端末は、前記制御サーバへ共通フォーマットのコマンドを送信する手段を備え、前記制御サーバは、仮想サーバとプラットフォームとの対応関係を記憶した仮想サーバ情報記憶手段と、前記共通フォーマットのコマンドに対応する各プラットフォームごとの実コマンドのフォーマットを記憶したコマンド変換情報記憶手段と、前記ホスト端末からの共通フォーマットのコマンドを受信する手段と、受信した共通フォーマットのコマンドに含まれる仮想サーバ名をキーとして前記仮想サーバ情報記憶手段からプラットフォームを検索する手段と、検索されたプラットフォーム名をキーとして前記コマンド変換情報記憶手段からそのプラットフォームのコマンド処理部に投入すべき実コマンドのフォーマットを取得し、取得した実コマンドのフォーマットに基づいて、前記受信した共通フォーマットのコマンドを実コマンドに変換する手段と、得られた実コマンドを含むジョブをコマンドキューに格納し、その格納の際、当該ジョブが管理者権限のもとで入力されたコマンドのジョブである場合には、前記コマンドキューの先頭に格納し、そうでない場合には、前記コマンドキューの末尾に格納する手段と、前記コマンドキューからジョブを取り出して、該ジョブの実コマンドを、対応するプラットフォームのコマンド処理部に投入する手段と、該プラットフォームのコマンド処理部が実行したコマンド結果を受け取る手段と、受け取ったコマンド結果を結果キュー処理部に格納する手段とを備えることを特徴とする。

請求項２に係る発明は、請求項１に記載のコマンドスケジュール対応型クラウド統一操作システムにおいて、前記コマンドキューからジョブを取り出して該ジョブの実コマンドをコマンド処理部に送信する際には、当該ジョブの送信先である物理サーバがジョブ実行中でないことを確認した後に送信することを特徴とする。

請求項３に係る発明は、ホスト端末と、該ホスト端末からコマンドを受け取る制御サーバとを用いたコマンドスケジュール対応型クラウド統一操作方法であって、前記制御サーバに、仮想サーバとプラットフォームとの対応関係を記憶した仮想サーバ情報記憶手段と、共通フォーマットのコマンドに対応する各プラットフォームごとの実コマンドのフォーマットを記憶したコマンド変換情報記憶手段とを設けるとともに、前記ホスト端末が、前記制御サーバへ共通フォーマットのコマンドを送信するステップと、前記制御サーバが、前記ホスト端末からの共通フォーマットのコマンドを受信するステップと、前記制御サーバが、受信した共通フォーマットのコマンドに含まれる仮想サーバ名をキーとして前記仮想サーバ情報記憶手段からプラットフォームを検索するステップと、前記制御サーバが、検索されたプラットフォーム名をキーとして前記コマンド変換情報記憶手段からそのプラットフォームのコマンド処理部に投入すべき実コマンドのフォーマットを取得し、取得した実コマンドのフォーマットに基づいて、前記受信した共通フォーマットのコマンドを実コマンドに変換するステップと、前記制御サーバが、得られた実コマンドを含むジョブをコマンドキューに格納し、その格納の際、当該ジョブが管理者権限のもとで入力されたコマンドのジョブである場合には、前記コマンドキューの先頭に格納し、そうでない場合には、前記コマンドキューの末尾に格納するステップと、前記制御サーバが、前記コマンドキューからジョブを取り出して、該ジョブの実コマンドを、対応するプラットフォームのコマンド処理部に投入するステップと、前記制御サーバが、該プラットフォームのコマンド処理部が実行したコマンド結果を受け取るステップと、前記制御サーバが、受け取ったコマンド結果を結果キュー処理部に格納するステップとを備えることを特徴とする。

請求項４に係る発明は、請求項３に記載のコマンドスケジュール対応型クラウド統一操作方法において、前記コマンドキューからジョブを取り出して該ジョブの実コマンドをコマンド処理部に送信する際には、当該ジョブの送信先である物理サーバがジョブ実行中でないことを確認した後に送信することを特徴とする。

本発明によれば、マルチプラットフォームから構成されるクラウドシステムにおいて、コマンドを大量に投入しても、効率的にコマンドを実行できるように自動でコマンドの処理順序をスケジューリングすることが出来るインターフェースを提供することができる。

本発明の実施形態に係るクラウド統一操作システムの全体構成図である。仮想サーバ情報ＤＢの構成を示す図である。コマンド変換ＤＢの構成を示す図である。物理サーバステータスＤＢの構成を示す図である。本システムにおける全体の流れを示すフローチャートである。スケジューリング処理の流れを示すフローチャートである。コマンド送信判定処理の流れを示すフローチャートである。従来のクラウド操作システムの概略構成図である

以下、図面を用いて、本発明の実施の形態について説明する。

図１は、本発明の一実施形態を示すシステム構成図である。この実施形態のクラウド統一操作システムは、コマンド送信部１０２を備えたホスト端末１０１と、このホスト端末１０１から受信したコマンドに応じて種々のプラットフォームのコマンド処理部にコマンドを投入する制御サーバ１０３とを備える。

制御サーバ１０３は、ホスト端末１０１のコマンド送信部１０２から送信されたコマンドを受信するコマンド受信部１０４、コマンドの引数として渡された仮想サーバのプラットフォームを検索するプラットフォーム検索部１０５、プラットフォームごとに実行するコマンドを変換するコマンド変換部１０６、コマンドに優先順位を与えるスケジューリング処理部１０７、コマンドをコマンドキューに格納するコマンドキュー処理部１０８、コマンドを所定のプラットフォームのコマンド処理部に投入する実コマンド送信部１０９、実行したコマンドの結果を受信するコマンド実行結果受信部１１０、実行したコマンドの結果を格納する結果キュー処理部１１１、仮想サーバのプラットフォーム情報を格納する仮想サーバ情報ＤＢ１１２、プラットフォームごとの仮想サーバを操作するすべてのコマンドを格納するコマンド変換ＤＢ１１３、および、物理サーバがジョブを実行しているかどうかをのステータスを格納する物理サーバステータスＤＢ１１４を備える。

また、制御サーバ１０３から投入されたコマンドを実際に操作するプラットフォーム毎のコマンド処理部１１５a，１１５bと、仮想サーバの実イメージを保持する各プラットフォームの物理サーバ１１６a，１１６b，１１６cを備える。ホスト端末１０１と制御サーバ１０３、制御サーバ１０３と各プラットフォームのコマンド処理部１１５a，１１５b、各プラットフォームのコマンド処理部１１５a，１１５bとそのプラットフォームの物理サーバ１１６a，１１６b，１１６cは、それぞれネットワーク接続されている。

図２は、仮想サーバ情報ＤＢ１１２に格納される仮想サーバ関連情報の一例を示す図である。図に示すように、仮想サーバ情報ＤＢ１１２には、仮想サーバ名２０１、仮想サーバが属するプラットフォームを示すプラットフォーム名２０２、および、仮想サーバのイメージが格納されている物理サーバを示す物理サーバ名２０３が格納されている。仮想サーバ名２０１は、クラウドシステム全体において一意なサーバ名である。ホスト端末１０１のコマンド送信部１０２が送信するコマンドにおいては、引数として、この仮想サーバ名を指定する。これにより、送信したコマンドにおいて、どの物理サーバに仮想サーバのイメージファイルが格納されているかということには依存せずに、意図した仮想サーバを操作することが可能となる。

図３は、コマンド変換ＤＢ１１３に格納されるコマンド変換関連情報の一例を示す図である。図に示すように、コマンド変換ＤＢ１１３には、プラットフォーム名３０１、変換前のコマンドであり制御サーバ１０３から投入されるコマンドそのものを示すコマンド名３０２、および、当該プラットフォームのコマンド処理部１１５に投入するコマンド形式を格納するコマンド３０３が格納されている。コマンド名３０２は、異なるプラットフォームに対しても共通に用いることができる共通コマンド名である。プラットフォーム名３０１は、プラットフォーム名２０２と対応しており、仮想サーバ情報ＤＢ１１２と組み合わせることによって当該プラットフォームのコマンド処理部に投入する実コマンドを構成することが可能となる。

ここで、例えばホスト端末１０1からpoweron vm_pA1というコマンドが投入されたとする。引数の仮想サーバ名としてvm_pA1が指定されているので、仮想サーバ情報ＤＢ１１２の仮想サーバ名２０１がvm_pA1であるレコードを参照し、vm_pA1のプラットフォーム名２０２がplatformAであり、物理サーバ名２０３がPhysicsServerAであることが検索できる。さらに、そのプラットフォーム名platformAとコマンド名poweronを、コマンド変換ＤＢ１１３から検索することにより、該当するplatformAのコマンド形式がvmpoweron -p ＜物理サーバ名＞ -v ＜仮想サーバ名＞であることが分かる。これらの情報を元に、platformAの物理サーバに投入する実際のコマンドはvmpoweron -p PhysicsServerA -v vm_pA1として投入することが可能となる。

図４は、物理サーバステータスＤＢ１１４に格納されるステータス情報の一例を示す図である。図で示すように、物理サーバステータスＤＢ１１４には、物理サーバ名４０１と、ステータス４０２が格納される。初期状態では、すべての物理サーバのステータス４０２はNotRunningに設定される。物理サーバにコマンドが投入されると、該当する物理サーバ名４０１に対するステータス４０２がRunningに更新され、ジョブが完了するとNotRunningに戻される。

図５は、本実施形態のクラウド統一操作システムにおける処理の概要を示すフローチャートである。まず、ホスト端末１０１は、利用者から入力されたコマンドをコマンド送信部１０２に渡す。コマンド送信部１０２は、制御サーバ１０３に対してネットワーク経由でそのコマンドを送信する（ステップ５０１）。そのコマンドは、プラットフォームにかかわらず共通に利用できるコマンドであり、引数として仮想サーバ名が指定されているものである。

次に、制御サーバ１０３のコマンド受信部１０４がそのコマンドを受け取る（ステップ５０２）。プラットフォーム検索部１０５は、仮想サーバ情報ＤＢ１１２に対して、コマンド受信部１０４が受け取った仮想サーバ名をキーに、仮想サーバのプラットフォーム名２０２と物理サーバ名２０３を検索する（ステップ５０３）。コマンド変換部１０６は、ステップ５０２で受け取ったコマンドとプラットフォーム名２０２の情報より、コマンド変換ＤＢ１１３のコマンド３０３を参照し、コマンド処理部に投入する実コマンドに変換する（ステップ５０４）。さらに、その実コマンドに対し、実行するコマンド全体で一意となるジョブＩＤを付与する（ステップ５０５）。スケジューリング処理部１０７は、スケジューリング処理により、コマンドキューの該当箇所にそのジョブを格納する（ステップ５０６）。このスケジューリング処理については、図６で詳しく説明する。

次に、コマンドキュー処理部１０８がコマンド送信判定処理を行う（ステップ５０７）。コマンド送信判定処理については、図７で詳しく説明するが、要するに、コマンドキューに格納されたジョブのうち各コマンド処理部に送信可能なジョブを「コマンド送信待ち状態」に設定する処理を行うものである。コマンド送信判定処理により「コマンド送信待ち状態」とされたコマンドキュー内のジョブ（ジョブＩＤと、実コマンドと、その実コマンドの送信先の物理サーバ名を含む）は、実コマンド送信部１０９に渡される（ステップ５０８）。実コマンド送信部１０９は、渡されたコマンドの投入先の物理サーバのステータス４０２をRunningに変更するように物理サーバステータスＤＢを更新する（ステップ５０９）。また、実コマンド送信部１０９は、ステップ５０８で渡されたジョブの実コマンドを、該当物理サーバのプラットフォームのコマンド処理部に送信する（ステップ５１０）。

次に、コマンド実行結果受信部１１０は、各プラットフォームのコマンド処理部１１５ａ，１１５ｂから送信されるコマンドの結果を受信し（ステップ５１１）、そのコマンドの結果を結果キューに格納する（ステップ５１２）。結果キュー処理部１１１は、コマンドキューと結果キューとで同一のジョブＩＤを持つものをファイルに出力し、両キューから削除する（ステップ５１３）。コマンドキューと結果キューとで同一のジョブＩＤを持つものとは、要するにサーバによる処理が終了したジョブである。次に、結果キュー処理部１１１は、そのコマンドを実行した物理サーバのステータスをNotRunningに変更するように物理サーバステータスＤＢを更新する(ステップ５１４)。

図６は、図５のステップ５０６のスケジューリング処理の詳細を示すフローチャートである。まず、受信したコマンドに管理者権限が付与されているかどうかを確認する（ステップ６０１）。付与されていない場合は、コマンドキューの最後にジョブをキューインする（ステップ６０２）。付与されている場合は、コマンドキューで待ち状態となっているジョブの先頭にジョブをキューインする（ステップ６０３）。

なお、図６の処理でコマンドキューにキューインしたジョブは、キューイン直後の初期状態では全て「待ち状態」とされる。コマンドキュー内の「待ち状態」のジョブは、後述する図７の処理（図５のステップ５０７）で「待ち状態」から「コマンド送信待ち状態」に変更される。コマンドキュー内の「コマンド送信待ち状態」のジョブは、図５のステップ５０８で実コマンド送信部に渡される。

図７は、図５のステップ５０７のコマンド送信判定処理の詳細を示すフローチャートである。まず、物理サーバステータスＤＢ１１４（図４）から全物理サーバのステータスを取得する（ステップ７０１）。次に、ステータスがNotRunning状態となっている物理サーバに対するコマンドがコマンドキュー内に存在するかどうかを判定する（ステップ７０２）。存在していたら、コマンドキュー内の当該ジョブの状態を「コマンド送信待ち状態」に変更する（ステップ７０３）。存在していなかったら、ステップ７０１に戻り、コマンドキューに次のジョブが投入されるまで待つ（ステップ７０２）。

なお、図５では説明の便宜のため全体の処理の流れをつなげて表記したが、実際にはステップ５０２〜５０６の処理と、ステップ５０７の処理と、ステップ５０８〜５１０の処理と、ステップ５１１〜５１４の処理とは、別タスクで実行している。すなわち、ステップ５０２〜５０６の処理では、ユーザから入力されたコマンドに応じて、コマンドキューにジョブをキューインする処理を繰り返している。ステップ５０７の処理では、コマンドキューに格納されているジョブに対して、当該ジョブの送信先である物理サーバがNotRunningであるジョブを「コマンド送信待ち状態」に変更する処理を繰り返している。ステップ５０８〜５１０の処理では、コマンドキュー内の「コマンド送信待ち状態」のジョブを取り出して、該当物理サーバのコマンド処理部に送信する処理を繰り返している。ステップ５１１〜５１４の処理では、コマンド処理結果が得られた後の処理を繰り返している。

上記実施形態のシステムによれば、異なるプラットフォームが混在する場合でも共通のコマンドフォーマットを利用して各プラットフォームに対してコマンドを投入できる。また、同時に大量の仮想サーバを操作するコマンドが投入された場合でも、投入されたコマンドを一旦コマンドキューに格納し、NotRunning状態となっている物理サーバに対するコマンドを該コマンドキューから取り出しながら処理していくので、コマンドを処理しきれずにハングアップしたり異常に遅延することはない。さらに、同時に大量の仮想サーバを操作するコマンドが投入された後に入力されたコマンドでも、ステップ５０６〜５１０のようにスケジューリングされて物理サーバに投入されるので、全体として効率的な処理が可能となる。

１０１…ホスト端末、１０２…コマンド送信部、１０３…制御サーバ、１０４…コマンド受信部、１０５…プラットフォーム検索部、１０６…コマンド変換部、１０７…スケジューリング処理部、１０８…コマンドキュー処理部、１０９…実コマンド送信部、１１０…コマンド実行結果受信部、１１１…結果キュー処理部、１１２…仮想サーバ情報ＤＢ、１１３…コマンド変換ＤＢ、１１４…物理サーバステータスＤＢ、１１５…各プラットフォームのコマンド処理部、１１６…各プラットフォームの物理サーバ。

Claims

ホスト端末と、該ホスト端末からコマンドを受け取る制御サーバとを備えるコマンドスケジュール対応型クラウド統一操作システムであって、
前記ホスト端末は、前記制御サーバへ共通フォーマットのコマンドを送信する手段を備え、
前記制御サーバは、
仮想サーバとプラットフォームとの対応関係を記憶した仮想サーバ情報記憶手段と、
前記共通フォーマットのコマンドに対応する各プラットフォームごとの実コマンドのフォーマットを記憶したコマンド変換情報記憶手段と、
前記ホスト端末からの共通フォーマットのコマンドを受信する手段と、
受信した共通フォーマットのコマンドに含まれる仮想サーバ名をキーとして前記仮想サーバ情報記憶手段からプラットフォームを検索する手段と、
検索されたプラットフォーム名をキーとして前記コマンド変換情報記憶手段からそのプラットフォームのコマンド処理部に投入すべき実コマンドのフォーマットを取得し、取得した実コマンドのフォーマットに基づいて、前記受信した共通フォーマットのコマンドを実コマンドに変換する手段と、
得られた実コマンドを含むジョブをコマンドキューに格納し、その格納の際、当該ジョブが管理者権限のもとで入力されたコマンドのジョブである場合には、前記コマンドキューの先頭に格納し、そうでない場合には、前記コマンドキューの末尾に格納する手段と、
前記コマンドキューからジョブを取り出して、該ジョブの実コマンドを、対応するプラットフォームのコマンド処理部に投入する手段と、
該プラットフォームのコマンド処理部が実行したコマンド結果を受け取る手段と、
受け取ったコマンド結果を結果キュー処理部に格納する手段と
を備えることを特徴とするコマンドスケジュール対応型クラウド統一操作システム。
請求項１に記載のコマンドスケジュール対応型クラウド統一操作システムにおいて、
前記コマンドキューからジョブを取り出して該ジョブの実コマンドをコマンド処理部に送信する際には、当該ジョブの送信先である物理サーバがジョブ実行中でないことを確認した後に送信することを特徴とするコマンドスケジュール対応型クラウド統一操作システム。
ホスト端末と、該ホスト端末からコマンドを受け取る制御サーバとを用いたコマンドスケジュール対応型クラウド統一操作方法であって、
前記制御サーバに、仮想サーバとプラットフォームとの対応関係を記憶した仮想サーバ情報記憶手段と、共通フォーマットのコマンドに対応する各プラットフォームごとの実コマンドのフォーマットを記憶したコマンド変換情報記憶手段とを設けるとともに、
前記ホスト端末が、前記制御サーバへ共通フォーマットのコマンドを送信するステップと、
前記制御サーバが、前記ホスト端末からの共通フォーマットのコマンドを受信するステップと、
前記制御サーバが、受信した共通フォーマットのコマンドに含まれる仮想サーバ名をキーとして前記仮想サーバ情報記憶手段からプラットフォームを検索するステップと、
前記制御サーバが、検索されたプラットフォーム名をキーとして前記コマンド変換情報記憶手段からそのプラットフォームのコマンド処理部に投入すべき実コマンドのフォーマットを取得し、取得した実コマンドのフォーマットに基づいて、前記受信した共通フォーマットのコマンドを実コマンドに変換するステップと、
前記制御サーバが、得られた実コマンドを含むジョブをコマンドキューに格納し、その格納の際、当該ジョブが管理者権限のもとで入力されたコマンドのジョブである場合には、前記コマンドキューの先頭に格納し、そうでない場合には、前記コマンドキューの末尾に格納するステップと、
前記制御サーバが、前記コマンドキューからジョブを取り出して、該ジョブの実コマンドを、対応するプラットフォームのコマンド処理部に投入するステップと、
前記制御サーバが、該プラットフォームのコマンド処理部が実行したコマンド結果を受け取るステップと、
前記制御サーバが、受け取ったコマンド結果を結果キュー処理部に格納するステップと
を備えることを特徴とするコマンドスケジュール対応型クラウド統一操作方法。
請求項３に記載のコマンドスケジュール対応型クラウド統一操作方法において、
前記コマンドキューからジョブを取り出して該ジョブの実コマンドをコマンド処理部に送信する際には、当該ジョブの送信先である物理サーバがジョブ実行中でないことを確認した後に送信することを特徴とするコマンドスケジュール対応型クラウド統一操作方法。