(57)【要約】  本発明の実施例は、プリエンプティブスケジューリングに基づくリソース共有使用方法、システムおよび装置を開示し、該方法は、ＡＰＩサーバがタスクを作成することと、スケジューラが現在のタスクを処理する時、優先度に基づいて所定のスクリーニング条件に最も合致するターゲット物理的なノードをスクリーニングし、現在のタスクおよびターゲット物理的なノードバンディング情報をＡＰＩサーバに送信することと、物理的なノードがタスクキューにおける実行待ちのターゲットタスクを処理する時、物理的なノードで実行しているタスクリストを取得することと、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、物理的なノードがタスクリストにおけるタスクを実行して得られる残りのリソースがターゲットタスクの実行に必要なリソースを満たすまで、タスクリストにおける優先度がターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに移動し、削除待ちのキューにおけるタスクをプリエンプションすることとを含む。【選択図】図６
2021522621.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラミングインタフェースＡＰＩサーバがタスクの作成要求を取得することと、
ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することと、
を含む、タスク作成方法。
【請求項２】
前記ＡＰＩサーバがタスクの作成要求を取得することは、
ＡＰＩサーバがｐｏｄの作成要求を取得することを含み、
ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することは、
前記ＡＰＩサーバが、前記ｐｏｄに対応するｎａｍｅｓｐａｃｅのｑｕｏｔａに前記ｐｏｄに対応する優先度とマッチングするリソースのｑｕｏｔａ値が含まれ、且つ前記ｑｕｏｔａ値が前記ｐｏｄの作成条件を満たすと検出した場合、前記作成要求に応じてｐｏｄを作成することを含む、請求項１に記載の方法。
【請求項３】
スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、
前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定することと、
前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することと、
を含む、タスクスケジューリング方法。
【請求項４】
前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定することは、
前記スケジューラが前記マッピングテーブルから第１段階のスクリーニング条件に合致する物理的なノードをスクリーニングし、ノードグループを形成することと、
前記マッピングテーブルおよび第２段階の好適な条件に基づき、前記ノードグループの物理的なノードをスコアリングし、スコアが最も高い物理的なノードをスクリーニングしてターゲット物理的なノードとすることと、
を含む、請求項３に記載の方法。
【請求項５】
前記スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの指定優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することは、
前記スケジューラがｐｏｄスケジューリングキューからスケジューリング待ちの現在のｐｏｄを取得し、各物理的なノードにおける前記現在のｐｏｄの優先度以上のｐｏｄを取得し、ノード−ｐｏｄのマッピングテーブルを形成することを含み、
前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することは、
前記スケジューラが前記現在のｐｏｄと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信することを含む、請求項３または請求項４に記載の方法。
【請求項６】
物理的なノードが実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、
前記物理的なノードが、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、
物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、
前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することと、
を含む、タスクプリエンプション方法。
【請求項７】
前記物理的なノードは、設定時間おきにリソース使用情報を取得することと、
前記物理的なノードは、前記リソース使用情報が所定の制限条件に達したことを確定した場合、前記物理的なノードが前記タスクリストにおけるタスクを実行する時に確定するリソース使用情報が所定の制限条件に達していないまで前記タスクリストにおけるタスクを優先度の低い順で前記削除待ちのキューに順に移動し、前記削除待ちのキューにおけるタスクを停止することと、
を更に含む、請求項６に記載の方法。
【請求項８】
前記ターゲットタスクはターゲットｐｏｄであり、前記タスクリストはｐｏｄリストであり、前記タスクリストにおけるタスクは前記物理的なノードで実行しているｐｏｄである、請求項６または請求項７に記載の方法。
【請求項９】
アプリケーションプログラミングインタフェースＡＰＩサーバがタスクの作成要求を取得することと、
前記ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することと、
スケジューラが前記ＡＰＩサーバにより作成されたタスクを取得し、タスクスケジューリングキューを形成することと、
前記スケジューラが前記タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの指定優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、
前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定することと、
前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することと、
物理的なノードが前記ＡＰＩサーバにおけるタスクと物理的なノードとのバンディング情報を傍受し、傍受した前記バンディング情報に基づいて対応するタスクを取得し、タスクキューを形成することと、
前記物理的なノードが前記タスクキューにおける実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、
前記物理的なノードは、前記タスクリストにおけるタスクを実行した後の残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、
ターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードは、前記物理的なノードの残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクよりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、
前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することと、
を含む、プリエンプティブスケジューリングに基づくリソース共有使用方法。
【請求項１０】
タスクの作成要求を取得するように構成される要求取得モジュールと、
前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成するように構成されるタスク作成モジュールと、
を備える、ＡＰＩサーバ。
【請求項１１】
タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成するよう構成されるマッピングテーブル形成モジュールと、
前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定するように構成されるスクリーニングモジュールと、
前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信するように構成されるバンディングモジュールと、
を備える、スケジューラ。
【請求項１２】
実行待ちのターゲットタスクを処理する時、物理的なノードで実行しているタスクリストを取得するように構成されるタスクリスト取得モジュールと、
物理的なノードにおける残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出するように構成される検出モジュールと、
検出モジュールが、物理的なノードにおける残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおけるタスクを、優先度の低い順で削除待ちのキューに順に移動し、且つ前記削除待ちのキューにおけるタスクの優先度が前記ターゲットタスクの優先度よりも小さく、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションするように構成されるプリエンプションモジュールと、
実行環境を呼び出し、前記ターゲットタスクを実行するように構成されるタスク実行モジュールと、
を備える、タスクプリエンプション装置。
【請求項１３】
請求項１０に記載のＡＰＩサーバと、請求項１１に記載のスケジューラと、請求項１２に記載のタスクプリエンプション装置とを備える、プリエンプティブスケジューリングに基づくリソース共有使用システム。
【請求項１４】
１つまたは複数のプロセッサと、
１つまたは複数のプログラムを記憶するための記憶装置と、
を備え、
前記１つまたは複数のプログラムが前記１つまたは複数のプロセッサにより実行されると、前記１つまたは複数のプロセッサは、請求項１または２に記載のタスク作成方法、または請求項３〜５のいずれか１項に記載のタスクスケジューリング方法、または請求項６〜８のいずれか１項に記載のタスクプリエンプション方法を実現する、装置。
【請求項１５】
プロセッサにより実行されると、請求項１または２に記載のタスク作成方法、または請求項３〜５のいずれか１項に記載のタスクスケジューリング方法、または請求項６〜８のいずれか１項に記載のタスクプリエンプション方法を実現するコンピュータプログラムが記憶されている、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、２０１８年６月２５日に中国専利局に提出された出願番号が２０１８１０６５９２９８．５である中国特許出願に対して優先権を主張するものであり、該出願の全ての内容を引用により本発明に援用する。
【０００２】
本発明は、コンピュータ技術分野に関し、例えば、プリエンプティブスケジューリングに基づくリソース共有使用方法、システムおよび装置に関する。
【背景技術】
【０００３】
リソース共有の分散システムにおいて、複数のテナントがリソースを共有して使用し、それと同時に、各テナントがいずれも使用可能なリソースを有することを確保し、テナントのリソースが「餓死」となる現象がないように、各テナントが使用するリソースに対してある程度限定する必要がある。分散システムにおけるスケジューラは、複数のテナントの作業またはタスクを効果的にスケジューリングすることにより、各テナントの作業またはタスクが安定して迅速に実行されるとともに、分散システム内のリソースが十分に利用されることを確保する。
【０００４】
従来の分散管理システムは、複数のスケジューリングポリシーを提供することにより、複数のテナントのタスクが分散システムで物理的なノードにバランスよく割り当てられ、更に物理的なノードが割り当てられたタスクを実行することを確保する。しかし、タスクの処理方式には、リソースが十分に利用されていない現象が存在する。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の実施例は、リソースの利用率を向上させることができる、プリエンプティブスケジューリングに基づくリソース共有使用方法、システムおよび装置を提供する。
【課題を解決するための手段】
【０００６】
第１態様において、本発明の実施例は、ＡＰＩサーバがタスクの作成要求を取得することと、ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することとを含む、タスク作成方法を提供する。
【０００７】
第２態様において、本発明の実施例は、スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定することと、前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することとを含む、タスクスケジューリング方法を更に提供する。
【０００８】
第３態様において、本発明の実施例は、物理的なノードが実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、前記物理的なノードが、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、残りのリソースがターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することとを含むタスクプリエンプション方法を更に提供する。
【０００９】
第４態様において、本発明の実施例は、ＡＰＩサーバがタスクの作成要求を取得することと、前記ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することと、スケジューラが前記ＡＰＩサーバにより作成されたタスクを取得し、タスクスケジューリングキューを形成することと、前記スケジューラが前記タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定することと、前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することと、物理的なノードが前記ＡＰＩサーバにおけるタスクと物理的なノードとのバンディング情報を傍受し、傍受した前記バンディング情報に基づいて対応するタスクを取得し、タスクキューを形成することと、前記物理的なノードが前記タスクキューにおける実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、前記物理的なノードが、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、残りのリソースがターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することとを含むプリエンプティブスケジューリングに基づくリソース共有使用方法を更に提供する。
【００１０】
第５態様において、本発明の実施例は、タスクの作成要求を取得するように構成される要求取得モジュールと、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成するように構成されるタスク作成モジュールとを備えるＡＰＩサーバを更に提供する。
【００１１】
第６態様において、本発明の実施例は、タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成するよう構成されるマッピングテーブル形成モジュールと、前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定するように構成されるスクリーニングモジュールと、前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信するように構成されるバンディングモジュールとを備えるスケジューラを更に提供する。
【００１２】
第７態様において、本発明の実施例は、実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得するように構成されるタスクリスト取得モジュールと、物理的なノードにおける残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出するように構成される検出モジュールと、残りのリソースがターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードが前記タスクリストにおけるタスクを実行して得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションするように構成されるプリエンプションモジュールと、実行環境を呼び出し、前記ターゲットタスクを実行するように構成されるタスク実行モジュールとを備えるタスクプリエンプション装置を更に提供する。
【００１３】
第８態様において、本発明の実施例は、本発明の実施例に係るＡＰＩサーバと、スケジューラと、タスクプリエンプション装置とを備えるプリエンプティブスケジューリングに基づくリソース共有使用システムを更に提供する。
【００１４】
第９態様において、本発明の実施例は、１つまたは複数のプロセッサと、１つまたは複数のプログラムを記憶するための記憶装置とを備える装置を更に提供する。
【００１５】
前記１つまたは複数のプログラムが前記１つまたは複数のプロセッサにより実行されると、前記１つまたは複数のプロセッサは、本発明の実施例に係るタスク作成方法、または本発明の実施例に係るタスクスケジューリング方法、または本発明の実施例に係るタスクプリエンプション方法を実現する。
【００１６】
第１０態様において、本発明の実施例は、プロセッサにより実行されると、本発明の実施例に係るタスク作成方法、または本発明の実施例に係るタスクスケジューリング方法、または本発明の実施例に係るタスクプリエンプション方法を実現するコンピュータプログラムが記憶されているコンピュータ可読記憶媒体を提供する。
【発明の効果】
【００１７】
本発明の実施例に係る技術案は、テナントのリソース割り前に対して優先度を設定し、タスクの優先度と対応するテナントにおける各優先度のリソースとをマッチングすることにより、タスクを作成するか否かを確定し、テナントにリソースが逼迫している場合にリソースを優先的に使用させ、テナントが高優先度のリソースを悪用して低優先度のタスクがリソースを持続的に取得できなくて「餓死」という現象が現れることを防止することができる。スケジューラは、タスクの優先度および所定のスクリーニング条件により物理的なノードをスクリーニングし、最適な物理的なノードをスクリーニングし、スケジューリング待ちの現在のタスクを最適な物理的なノードにスケジューリングし、リソースが逼迫している場合、論理的なリソースプリエンプションのみを行い、リソースを直ちにプリエンプションせず、このようなプリエンプションを遅延させるスケジューリング方法は、論理的に高優先度のタスクにリソースを譲ることができ、リソースが十分に利用されていない場合、プリエンプションされたタスクを実行し続け、リソースの利用率を向上させることができる。物理的なノードが実行待ちのターゲットタスクを処理する時、物理的なノードの残りのリソースがターゲットタスクの実行に必要な条件を満たさないと、低優先度のタスクをプリエンプションすることに基づき、物理的なノードは重要なタスクを優先的に処理することができ、リソースの利用率を向上させることができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施例に係るタスク作成方法のフローチャートである。
【図２】本発明の実施例に係るタスクスケジューリング方法のフローチャートである。
【図３】本発明の実施例に係るタスクスケジューリング方法のフローチャートである。
【図４】本発明の実施例に係るタスクプリエンプション方法のフローチャートである。
【図５】本発明の実施例に係るタスクプリエンプション方法のフローチャートである。
【図６】本発明の実施例に係るプリエンプティブスケジューリングに基づくリソース共有使用方法のフローチャートである。
【図７】本発明の実施例に係るＡＰＩサーバの構造ブロック図である。
【図８ａ】本発明の実施例に係るスケジューラの構造ブロック図である。
【図８ｂ】本発明の実施例に係るスケジューリングシステムの構造模式図である。
【図９】本発明の実施例に係るタスクプリエンプション装置の構造ブロック図である。
【図１０】本発明の実施例に係るプリエンプティブスケジューリングに基づくリソース共有使用システムの構造ブロック図である。
【図１１】本発明の実施例に係る装置の構造模式図である。
【発明を実施するための形態】
【００１９】
以下、図面および実施例を参照しながら本発明について説明する。ここで説明する具体的な実施例は本発明を解釈するためのものに過ぎず、本発明を限定するものではないことが理解できる。なお、説明の便宜上、図面において、全ての内容ではなく、本発明に関連する部分のみを示す。
【００２０】
図１は、本発明の実施例に係るタスク作成方法のフローチャートであり、前記方法は、アプリケーションプログラミングインタフェース（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ、ＡＰＩ）サーバ（ＡＰＩ  Ｓｅｒｖｅｒ）に適用でき、ＡＰＩサーバにより実行され、該ＡＰＩサーバは、クラスタ管理プラットフォームにおける１つのコンポーネントであってもよく、ソフトウェアおよび／またはハードウェアの形態で実現され、クラスタ管理プラットフォームは、クラスタにおける大量のリソースを管理するプラットフォームであってもよく、クラスタ管理プラットフォームは、ＫｕｂｅｒｎｅｔｅｓおよびＭｅｓｏｓを含んでもよいが、これらに限定されず、且つ、複数のコンピュータ装置に集積できる。図１に示すように、本発明の実施例に係るタスク作成方法はＳ１１０〜Ｓ１２０を含む。
【００２１】
Ｓ１１０において、ＡＰＩサーバがタスクの作成要求を取得する。
【００２２】
本発明の実施例に係る方法はクラスタに適用でき、クラスタには複数の物理的なノードが含まれてもよく、各物理的なノードにおけるリソースは複数のテナントの共有リソースであってもよく、複数の物理的なノードはクラスタ管理プラットフォームにより管理されてもよく、クラスタ管理プラットフォームはタスクを物理的なノードに割り当てて物理的なノードに対応するタスクを実行させる。クラスタ管理プラットフォームは複数のコンピュータ装置に集積でき、複数のコンピュータ装置はユーザが操作でき、ユーザはクラスタ管理プラットフォームに登録してタスクの作成要求を提出することができ、クラスタ管理プラットフォームにおけるＡＰＩサーバはユーザにより提出されたタスクの作成要求を取得してタスクを作成する。クラスタ管理プラットフォームにおけるスケジューラはタスクスケジューリングを行い、タスクを対応する物理的なノードに合理的に割り当てる。物理的なノードは該タスクを実行する。
【００２３】
ここで、ＡＰＩサーバはクラスタ管理プラットフォームにおける１つのコンポーネントであってもよく、タスクの作成を完了することができ、豊かな機能性プラグインを提供し、クラスタに対する管理等を完備する。
【００２４】
ここで、ＡＰＩサーバは、ユーザが提出した１つのタスクの作成要求を取得することができ、例えば、ユーザが提出した１つのアプリケーションを作成する要求を取得することができる。ここで、ユーザがタスクの作成要求を提出する時、タスクの優先度を設定することができる。
【００２５】
Ｓ１２０において、ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成する。
【００２６】
ユーザが管理粒度で複数のグループに分けられ、各グループが１つのテナントと呼ばれ、必要に応じて各テナントに割り前を予め設定することができ、割り前は１グループのリソースであってもよく、例えば、該グループのリソースは、プロセッサ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、ＣＰＵ）、メモリ、グラフィックプロセッサ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、ＧＰＵ）、フィールドプログラマブルゲートアレイ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ、ＦＰＧＡ）、人工知能（Ａｒｔｉｆｉｃｉａｌ  Ｉｎｔｅｌｌｉｇｅｎｃｅ、ＡＩ）チップ、プロセッサの優先度およびメモリの優先度、ＧＰＵ優先度、ＦＰＧＡ優先度、ＡＩチップ優先度等を含んでもよく、各テナントにリソース割り前を予め設定することができる。割り前を合理的に設定することにより、適当な優先度のリソースを使用するようにテナントをグラントすることができ、テナントは、リソースが逼迫している場合にリソースを優先的に使用でき、更に、テナントが高優先度のリソースを悪用して低優先度のタスクがリソースを持続的に取得できなくて「餓死」の現象が現れることを制限することができる。
【００２７】
ユーザがクラスタ管理プラットフォームによりタスクの作成要求を提出する場合、各タスクには識別情報が担持され、ＡＰＩサーバは、識別情報に基づいて各タスクに対応するテナントを識別し、該テナントの割り前に該タスクの優先度とマッチングするリソースが含まれるか否か判断し、該タスクの優先度とマッチングするリソースが含まれている場合、該マッチングリソースが該タスクの作成条件を満たすか否かを判断し続け、該マッチングリソースが該タスクの作成条件を満たすと、タスクを作成することができる。
【００２８】
作成条件はＣＰＵの数および／またはメモリの占有率であってもよく、他の条件であってもよい。例えば、ユーザがタスクの作成要求を提出する時、クラスタ管理プラットフォームにより該タスクの優先度を高優先度とすることができ、すると、該タスクに必要なリソースの優先度も高優先度となり、例えば、該タスクは１０個の高優先度のＣＰＵを必要とする。該タスクに対応するテナントの割り前には高優先度のＣＰＵが含まれ、且つ高優先度のＣＰＵの数が１０以上であれば、該タスクを作成する。
【００２９】
本発明の１つの実施形態において、好ましくは、本発明の実施例に係る方法はＫｕｂｅｒｎｅｔｅｓ環境に適用できる。前記サーバがタスクの作成要求を取得することは、ＡＰＩサーバがタスクｐｏｄの作成要求を取得することを含む。ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することは、前記ＡＰＩサーバが、前記タスクｐｏｄに対応するテナントｎａｍｅｓｐａｃｅの割り前ｑｕｏｔａに前記ｐｏｄに対応する優先度とマッチングするリソースのｑｕｏｔａ値が含まれ、且つ該ｑｕｏｔａ値が前記タスクｐｏｄの作成条件を満たすと検出した場合、ＡＰＩサーバは前記作成要求に応じてｐｏｄを作成することを含む。
【００３０】
ここで、ｐｏｄは、ｋｕｂｅｒｎｅｔｅｓにおける最小に作成されて配置できる最も簡略な単位である。１つのｐｏｄは、クラスタ内で実行している１つのプロセスを表す。ｐｏｄはＫｕｂｅｒｎｅｔｅｓにおけるコンポーネントであり、例えば、１つのアプリケーションを作成してもよく、１つのプロセス等を起動してもよい。ｐｏｄにアプリケーションのコンテナー（ある場合に、いくつかのコンテナー）がパッケージされ、該コンテナーは独立したネットワークＩＰ、コンテナーがどのように実行するかを管理するポリシーオプション等を記憶することができる。ここで、ｐｏｄは配置された１つの単位を表し、ｋｕｂｅｒｎｅｔｅｓに適用される１つのインスタンスであり、１つまたは複数のコンテナーで組み合わせられてリソースを共有する可能性がある。ここで、１つのｐｏｄの作成は、１つのアプリケーションの作成等であってもよい。
【００３１】
ここで、Ｎａｍｅｓｐａｃｅは、１グループのリソースおよびオブジェクトの抽象的な集合であり、例えば、ｋｕｂｅｒｎｅｔｅｓシステム内部のオブジェクトを異なる項目グループまたはユーザグループに分けるために使用でき、ｎａｍｅｓｐａｃｅは、異なるテナントまたはユーザを隔離するために使用されることが多い。ｋｕｂｅｒｎｅｔｅｓにおいて、ｑｕｏｔａは、リソース管理およびリソース制限を行うために使用でき、ｑｕｏｔａ値の大きさは、リソースの多少を表すことができ、例えば、１つのテナントで設定されたリソースが２０個の高優先度のＣＰＵであれば、ｎａｍｅｓｐａｃｅにおけるｑｕｏｔａ値は２０であってもよく、即ち、ｑｕｏｔａ値はリソースの数を表すことができる。
【００３２】
本発明の実施例に係るタスク作成方法は、タスクの作成要求を取得すると、タスクに対応するテナントの割り前にタスクの優先度とマッチングするリソースが含まれるか否かを検出し、且つタスクの優先度とマッチングするリソースがタスクの作成条件を満たすか否かを検出し、２つの条件がいずれも満たされる（対応するテナントの割り前に該タスクの優先度とマッチングするリソースが含まれているとともに、該リソースも該タスクの作成条件を満たす）場合、該タスクを作成し、本実施例は、テナントのリソース割り前に対して優先度を設定し、タスクの優先度と対応するテナントにおける各優先度のリソースとをマッチングすることにより、タスクを作成するか否かを確定し、テナントにリソースが逼迫している場合にリソースを優先的に使用させ、テナントが高優先度のリソースを悪用して低優先度のタスクがリソースを持続的に取得できなくて「餓死」という現象が現れることを防止することができる。
【００３３】
図２は、本発明の実施例に係るタスクスケジューリング方法のフローチャートであり、前記方法はスケジューラに適用でき、スケジューラはクラスタ管理プラットフォームのコンポーネントであってもよく、ソフトウェアおよび／またはハードウェアの形態で実現され、クラスタ管理プラットフォームは、クラスタにおける大量のハードウェアリソースを管理するプラットフォームであってもよく、クラスタ管理プラットフォームは、ＫｕｂｅｒｎｅｔｅｓおよびＭｅｓｏｓを含んでもよいが、これらに限定されず、且つ、複数のコンピュータ装置に集積できる。本発明の実施例に係る方法は以下のような環境に適用できる。クラスタに複数の物理的なノードが含まれてもよく、複数の物理的なノードにおけるリソースは複数のテナントの共有リソースであってもよく、複数の物理的なノードはクラスタ管理プラットフォームにより管理されてもよく、クラスタ管理プラットフォームはタスクを物理的なノードに割り当てて物理的なノードに対応するタスクを実行させる。クラスタ管理プラットフォームは複数のコンピュータ装置に集積でき、複数のコンピュータ装置はユーザが操作でき、ユーザはクラスタ管理プラットフォームに登録してタスクの作成要求を提出することができ、クラスタ管理プラットフォームにおけるＡＰＩサーバはユーザにより提出されたタスクの作成要求を取得してタスクを作成し、クラスタ管理プラットフォームにおけるスケジューラはタスクスケジューリングを行い、タスクを対応する物理的なノードに合理的に割り当て、物理的なノードが該タスクを実行する。ここで、本発明の実施例はスケジューラがタスクスケジューリングを行う段階に適用される。
【００３４】
図２に示すように、本発明の実施例に係る技術案はＳ２１０〜Ｓ２３０を含む。
【００３５】
Ｓ２１０において、スケジューラはタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成する。
【００３６】
ここで、スケジューラはクラスタ管理プラットフォームのコンポーネントであってもよく、ＡＰＩサーバからＡＰＩサーバで作成されたタスクを傍受し、ＡＰＩサーバからタスクを読み取ることができ、読み取ったタスクがタスクスケジューリングキューを形成する。ここで、スケジューラはタスクスケジューリングキューにおけるタスクの順に従ってタスクをスケジューリングする。
【００３７】
物理的なノードは各種の物理マシンであってもよく、スケジューラは各物理的なノードからリソース情報（全てのリソースおよび使用可能なリソースを含む）および各物理的なノードで実行しているタスクキューを取得することができる。ここで、該タスクキューにおける各タスクはいずれも優先度を有する。スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得する時、各物理的なノードにおける現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成する。例えば、現在のタスクの優先度が高優先度であり、物理的なノード１における高優先度以上のタスクがタスク１、タスク２およびタスク３を有する場合、スケジューラは物理的なノード１におけるタスク１、タスク２およびタスク３を取得し、ノード−タスクのマッピングテーブルを形成する。ここで、物理的なノードにおける現在のタスクの優先度以上のタスクは、物理的なノードで実行している現在のタスクの優先度以上のタスクと、物理的なノードにおける実行待ちの現在のタスクの優先度以上のタスクとを含む。
【００３８】
Ｓ２２０において、前記スケジューラは前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定する。
【００３９】
スケジューラはノード−タスクマッピングテーブルから所定のスクリーニング条件に基づいてスクリーニングを行い、所定のスクリーニング条件に最も合致するターゲット物理的なノードをスクリーニングする。ここで、所定のスクリーニング条件は、現在のタスクに必要なリソースと物理的なノードにおける残りのリソースとの間のマッチング条件、および現在のタスクに必要なポートと物理的なノードにおけるポートとの間のマッチング条件等を含んでもよい。
【００４０】
本発明の１つの実施形態において、好ましくは、前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定することは、前記スケジューラがマッピングテーブルから第１段階のスクリーニング条件に合致する物理的なノードをスクリーニングし、ノードグループを形成することと、マッピングテーブルおよび第２段階の好適な条件に基づき、前記ノードグループの物理的なノードをスコアリングし、スコアが最も高い物理的なノードをターゲット物理的なノードとしてスクリーニングすることとを含む。
【００４１】
ここで、第１段階のスクリーニング条件と第２段階の好適な条件とは異なる。例えば、第１段階のスクリーニング条件は、現在のタスクに必要なポートと物理的なノード上のポートとの間のマッチング条件、物理的なノードに特殊なタグがあるか否か等であってもよく、第２段階の好適な条件は、現在のタスクに必要なリソースと物理的なノードにおける残りのリソースとの間のマッチング条件であってもよく、且つ、第２段階の好適な条件は１つの条件を含んでもよいし、複数の条件を含んでもよい。第２段階の好適な条件が複数の条件を含む場合、各条件に重みを設け、重みに基づいて物理的なノードのスコアリングを確定してもよい。
【００４２】
該実施形態について例を挙げて説明し、第１段階のスクリーニング条件が、物理的なノードがＧＰＵのタグを有する必要があることであれば、第２段階のスクリーニング条件は、現在のタスクに必要なリソースと物理的なノードにおける残りのリソースとの間のマッチング条件を予め設定することである。ノード−タスクマッピングテーブルおよび取得した物理的なノードの情報を照合し、スケジューラは、ＧＰＵを有する物理的なノードを選択し、ノードグループを形成する。スケジューラは、ノードグループ内の物理的なノードにおける残りのリソースが現在のタスクに必要なリソース条件を満たすか否かを判断し、条件を満たさない物理的なノードを除去し、現在のタスクに必要なリソース条件の物理的なノードをスコアリングし、物理的なノードにおける残りのリソースが多ければ多いほど、該物理的なノードのスコアは高くなることで、スコアが最も高い物理的なノードはターゲット物理的なノードである。ここで、ターゲット物理的なノードをスクリーニングする方法は上記方法を含むが、これらに限定されない。
【００４３】
上記２回のスクリーニングにより、スコアが最も高い物理的なノードをターゲット物理的なノードとしてスクリーニングし、即ち、スコアが最も高い物理的なノードを最適な物理的なノードとしてスクリーニングし、１回のスクリーニングの場合に対し、毎回のスクリーニング時のデータの処理量を減少してタスクスケジューリングの効率を向上させることができる。
【００４４】
Ｓ２３０において、前記スケジューラは前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信する。
【００４５】
スケジューラは、現在のタスクとスクリーニングした所定のスクリーニング条件に最も合致する物理的なノード（即ち、ターゲット物理的なノード）とをバンディングすることにより、バンディングした情報をＡＰＩサーバに送信することで、各物理的なノードはＡＰＩサーバからそれぞれが実行するタスクを読み取ることができる。
【００４６】
本発明の実施例のスケジューラは、タスクの優先度および所定のスクリーニング条件に基づいて複数の物理的なノードをスクリーニングし、各タスクに対応する最適な物理的なノード（即ち、ターゲット物理的なノード）をスクリーニングし、スケジューリング待ちの現在のタスクを最適な物理的なノードにスケジューリングする。リソースが逼迫している場合、論理的なリソースプリエンプションのみを行い、リソースを直ちにプリエンプションせず、このようなプリエンプションを遅延させるスケジューリング方法は、論理的に高優先度のタスクにリソースを譲ることができ、リソースが十分に利用されていない場合、プリエンプションされたタスクを保留し続け、リソースの利用率を向上させることができる。
【００４７】
図３は、本発明の実施例に係るタスクスケジューリング方法のフローチャートであり、ここで、該実施例に係る方法はｋｕｂｅｒｎｅｔｅｓシステムに適用でき、図３に示すように、本実施例に係る技術案はＳ３１０〜Ｓ３４０を含む。
【００４８】
Ｓ３１０において、スケジューラはｐｏｄスケジューリングキューからスケジューリング待ちの現在のｐｏｄを取得し、各物理的なノードにおける前記現在のｐｏｄの優先度以上のｐｏｄを取得し、ノード−ｐｏｄのマッピングテーブルを形成する。
【００４９】
Ｓ３２０において、前記スケジューラはマッピングテーブルから第１段階のスクリーニング条件に合致する物理的なノードをスクリーニングし、ノードグループを形成する。
【００５０】
Ｓ３３０において、マッピングテーブルおよび第２段階の好適な条件に基づき、前記ノードグループの物理的なノードをスコアリングし、スコアが最も高い物理的なノードをターゲット物理的なノードとしてスクリーニングする。
【００５１】
Ｓ３４０において、前記スケジューラは前記現在のｐｏｄと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信する。
【００５２】
これにより、スケジューラは、タスクの優先度および所定のスクリーニング条件に基づいて物理的なノードをスクリーニングし、最適な物理的なノードをスクリーニングし、スケジューリング待ちの現在のタスクを最適な物理的なノードにスケジューリングする。リソースが逼迫している場合、論理的なのリソースプリエンプションのみを行い、リソースを直ちにプリエンプションせず、このようなプリエンプションを遅延させるスケジューリング方法は、論理的に高優先度のタスクにリソースを譲ることができ、リソースが十分に利用されていない場合、プリエンプションされたタスクを保留し続け、リソースの利用率を向上させることができる。
【００５３】
図４は、本発明の実施例に係るタスクプリエンプション方法のフローチャートであり、前記方法は、タスクプリエンプション装置により実行でき、前記装置はソフトウェアおよび／またはハードウェアで実現され、前記装置はコンピュータ装置に集積できる。本発明の実施例に係るタスクプリエンプション方法は、物理的なノードがタスクを処理するシーンに適用される。図４に示すように、本発明の実施例に係る技術案はＳ４１０〜Ｓ４４０を含む。
【００５４】
Ｓ４１０において、物理的なノードが実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得する。
【００５５】
ここで、物理的なノードは、物理マシン等のようなコンピュータ装置であってもよい。物理的なノードは、ＡＰＩサーバにおけるタスクと物理的なノードとのバンディング情報を傍受することにより対応するタスクを取得し、取得したタスクでタスクキューを形成することができる。物理的なノードは、タスクキューにおけるタスクの順序に応じて処理を順に行い、現在の処理のタスクは実行待ちのターゲットタスクと呼ばれる。物理的なノードが実行待ちのターゲットタスクを処理する時、物理的なノードは該物理的なノードで実行しているタスクリストを取得する。ここで、タスクリストには、物理的なノードで実行しているタスクの情報が記載されている。物理的なノードで実行しているタスクは１つであってもよいし、複数であってもよい。
【００５６】
Ｓ４２０において、前記物理的なノードは、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出する。
【００５７】
物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、Ｓ４３０を実行し、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たすと検出した場合、Ｓ４４０を実行する。
【００５８】
本ステップにおいて、ターゲットタスクの実行に必要なリソースは、ＣＰＵ、メモリ等を含んでもよい。物理的なノードの残りのリソースは、物理的なノードにおける使用可能なリソースと理解されてもよい。例えば、物理的なノードにおける残りのＣＰＵの数が１０個でメモリが１Ｇであり、ターゲットタスクの実行に必要なＣＰＵが１０でメモリが２Ｇであると、物理的なノードにおける残りのリソースはターゲットタスクの実行に必要なリソースを満たすことができない。
【００５９】
Ｓ４３０において、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し（該物理的なノードは、削除待ちのキューに移動されるタスクを実行しない）、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションする。
【００６０】
本ステップにおいて、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たすことができると検出した場合、実行環境を直接呼び出し、ターゲットタスクを実行する。物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たすことができないと検出した場合、タスクリストにおけるタスクを優先度の低い順で順番付け、且つ、物理的なノードがタスクリストにおけるタスクを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソースを満たすまで、優先度がターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに移動し、ターゲットタスクを用いて削除待ちのキューにおけるタスクのリソースをプリエンプションし、即ち、削除待ちのキューにおけるタスクの実行を停止する。
【００６１】
タスクリストにおけるタスクを削除待ちのキューに移動する過程において、物理的なノードにおける残りのリソースがターゲットタスクの実行条件を満たさない場合、ターゲットタスクの実行を拒否する。
【００６２】
なお、タスクリストにおける優先度がターゲットタスクの優先度よりも低いタスクを削除待ちのキューに移動する過程において、削除待ちのキューにおけるタスクの実行を停止せず、物理的なノードがタスクリストにおけるタスクを実行した後に得られた残りのリソースがターゲットタスクの実行に必要なリソースを満たすと判断した場合、削除待ちのキュー中のタスクを実行する。
【００６３】
本ステップについて例を挙げて説明し、タスクリストには合計５つのタスク（物理的なノードで実行しているタスクが５つある）があり、それぞれＡ、Ｂ、Ｃ、ＤおよびＥであれば、優先度はそれぞれ１、２、３、４および５であり、ここで、タスクリストにおけるタスクは優先度の低い順で順番付けると、Ａ、Ｂ、Ｃ、ＤおよびＥである。処理待ちのターゲットタスクの優先度は４である。物理的なノードにおける残りのリソースがターゲットタスクの実行に必要なリソース条件を満たすことができない場合、物理的なノードで実行しているタスクリストにおける優先度がターゲットタスクの優先度よりも低いタスク（それぞれＡ、ＢおよびＣ）を優先度の低い順で削除待ちのキューに順に移動し、即ち、まず、Ａを削除待ちのキューに移動し、物理的なノードがタスクリストにおけるＢ、Ｃ、ＤおよびＥを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たすか否かを判断する。物理的なノードがタスクＢ、Ｃ、ＤおよびＥを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たす場合、ターゲットタスクを用いて実行しているＡをプリエンプションし、即ち、Ａを停止する。
【００６４】
Ａを削除待ちのキューに移動した後、物理的なノードがタスクリストにおけるＢ、Ｃ、ＤおよびＥを実行して得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たさない場合、Ｂを削除待ちのキューに移動し続け、タスクリストにおけるタスクＣ、ＤおよびＥを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たすか否かを再び検出し、タスクリストにおけるタスクを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たすと検出したまで上記判断ステップを繰り返す。タスクリストにおけるタスクの優先度がターゲットタスクの優先度以上である場合（即ち、タスクリストにおけるタスクＡ、ＢおよびＣがいずれも移出待ちのキューに移動され、タスクＤおよびＥのみが残っている場合）、物理的なノードがタスクリストにおけるタスクＤおよびＥを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たさないと、ターゲットタスクの実行を拒否する。
【００６５】
Ｓ４４０において、前記物理的なノードは実行環境を呼び出し、前記ターゲットタスクを実行する。
【００６６】
本発明の実施例は、物理的なノードが実行待ちのターゲットタスクを処理する時、物理的なノードの残りのリソースがターゲットタスクの実行に必要な条件を満たさないと、低優先度のタスクをプリエンプションし、物理的なノードは重要なタスクを優先的に処理することができ、リソースの利用率を向上させることができる。
【００６７】
上記実施例の基に、前記のタスクプリエンプション方法は、前記物理的なノードが設定時間おきにリソース使用情報を取得することと、前記物理的なノードが、前記リソース使用情報が所定の制限条件に達したことを確定した場合、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に確定されるリソース使用情報が所定の制限条件に達していないまで前記タスクリストにおけるタスクを優先度の低い順で前記削除待ちのキューに移動し、前記削除待ちのキューにおけるタスクを停止する。
【００６８】
好ましくは、タスクリストにおけるタスクは現在の物理的なノードで実行しているタスクである。ここで、各物理的なノードは設定時間おきにリソース使用情報を取得し、リソースの使用情報が所定の制限条件に達したか否かを判断することで、タスクプリエンプションをトリガする必要があるか否かを判断する。リソースの使用情報が所定の制限条件に達すると、タスクプリエンプションをトリガし、リソース使用情報が所定の制限条件に達していないと、タスクプリエンプションをトリガする必要がない。タスクプリエンプションの過程は以下のとおりである。タスクリストにおけるタスクを優先度で順番付け、前記物理的なノードがタスクリストにおけるタスクを実行した後に確定されるリソース使用情報が所定の制限条件に達していないまでタスクリストにおけるタスクを優先度の低い順で削除待ちのキューに順に移動し、削除待ちのキューにおけるタスクを停止する。
【００６９】
ここで、所定の制限条件は、リソース使用が設定値に達することであってもよく、他の制限条件であってもよい。例えば、物理的なノードのリソース使用が設定値に達すると、タスクプリエンプションをトリガする。
【００７０】
これにより、物理的なノードは、リソース使用情報に基づいてタスクプリエンプションをトリガすることで、リソース利用率を向上させることができ、更に、リソースが逼迫している場合、低優先度のタスクからリソースをプリエンプションして重要なタスクを優先的に処理することができる。
【００７１】
図５は、本発明の実施例に係るタスクプリエンプション方法のフローチャートであり、本発明の実施例に係る方法はＫｕｂｅｒｎｅｔｅｓシステムに実行される。図５に示すように、本発明の実施例に係る方法はＳ５１０〜Ｓ５４０を含む。
【００７２】
Ｓ５１０において、物理的なノードがｋｕｂｅｌｅｔにより実行待ちのターゲットｐｏｄを処理する時、前記物理的なノードで実行しているｐｏｄリストを取得する。
【００７３】
ここで、ｋｕｂｅｌｅｔはＫｕｂｅｒｎｅｔｅｓシステムのコンポーネントであり、ｐｏｄ、ｐｏｄのマウントに必要なｖｏｌｕｍｅｓ、ｐｏｄをダウンロードするｓｅｃｒｅｔ、ｄｏｃｋｅｒ／ｒｋｔによりｐｏｄにおけるコンテナーを実行すること、ｐｏｄにおけるコンテナーに定義されたｌｉｖｅｎｅｓｓプローブを周期的に実行すること、ｐｏｄの状態をシステムの他のコンポーネントに報告すること、およびノードの状態を監視することができる。
【００７４】
Ｓ５２０において、前記物理的なノードはｋｕｂｅｌｅｔにより、残りのリソースが前記ターゲットｐｏｄの実行に必要なリソースを満たすか否かを検出する。
【００７５】
物理的なノードが、残りのリソースがターゲットｐｏｄの実行に必要なリソースを満たさないと検出した場合、Ｓ５３０を実行し、物理的なノードが、残りのリソースがターゲットｐｏｄ実行に必要なリソースを満たすと検出した場合、Ｓ５４０を実行する。
【００７６】
Ｓ５３０において、前記物理的なノードはｋｕｂｅｌｅｔにより、前記物理的なノードが前記ｐｏｄリストにおけるｐｏｄを実行した後に得られる残りのリソースが前記ターゲットｐｏｄの実行に必要なリソースを満たすまで、前記ｐｏｄリストにおける優先度が前記ターゲットｐｏｄの優先度よりも低いｐｏｄを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットｐｏｄを用いて前記削除待ちのキューにおけるｐｏｄをプリエンプションする。
【００７７】
Ｓ５４０において、前記物理的なノードはｋｕｂｅｌｅｔにより実行環境を呼び出し、前記ターゲットｐｏｄを実行する。
【００７８】
これにより、物理的なノードが実行待ちのターゲットｐｏｄを処理する時、物理的なノードの残りのリソースがターゲットｐｏｄの実行に必要な条件を満たさないと、低優先度のｐｏｄ（優先度はターゲットｐｏｄの優先度よりも低い）をプリエンプションし、物理的なノードは重要なタスク（本実施例において、該重要タスクとはターゲットｐｏｄを意味する）を優先的に処理してリソースの利用率を向上させることができる。
【００７９】
図６は、本発明の実施例に係るプリエンプティブスケジューリングに基づくリソース共有使用方法のフローチャートであり、前記方法は、プリエンプティブスケジューリングに基づくリソース共有使用システムにより実行され、前記システムは、ソフトウェアおよび／またはハードウェアで実現できる。本発明の実施例に係る方法はクラスタに適用でき、クラスタには複数の物理的なノードが含まれてもよく、各物理的なノードにおけるリソースは複数のテナントの共有リソースであってもよく、複数の物理的なノードはクラスタ管理プラットフォームにより管理されてもよく、タスクを物理的なノードに割り当てて物理的なノードに対応するタスクを実行させる。クラスタ管理プラットフォームは複数のコンピュータ装置に集積でき、複数のコンピュータ装置はユーザが操作でき、ユーザはクラスタ管理プラットフォームに登録してタスクの作成要求を提出することができ、クラスタ管理プラットフォームにおけるＡＰＩサーバはユーザにより提出されたタスクの作成要求を取得してタスクを作成し、クラスタ管理プラットフォームにおけるスケジューラはタスクスケジューリングを行い、タスクを対応する物理的なノードに合理的に割り当て、物理的なノードが該タスクを実行する。
【００８０】
図６に示すように、本発明の実施例に係る技術案はＳ６１０〜Ｓ６９２を含む。
【００８１】
Ｓ６１０において、ＡＰＩサーバはタスクの作成要求を取得する。
【００８２】
Ｓ６２０において、前記ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成する。
【００８３】
Ｓ６３０において、スケジューラは前記ＡＰＩサーバにより作成されたタスクを取得し、タスクスケジューリングキューを形成する。
【００８４】
ＡＰＩサーバはタスクの作成要求をリアルタイムに取得し、条件を満たした作成要求のためにタスクを作成する。そのため、ＡＰＩサーバには少なくとも１つのタスクがある。スケジューラはＡＰＩサーバが作成する全てのタスクを取得し、これらのタスクをタスクスケジューリングキューに形成する。
【００８５】
Ｓ６４０において、前記スケジューラは前記タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成する。
【００８６】
スケジューラは、タスクスケジューリングキューにおけるタスクの並び順に基づき、タスクを順にスケジューリングする。スケジューリング待ちの現在のタスクとは、タスクスケジューリングキューにおけるスケジューラが現在スケジューリングしているタスクを意味する。
【００８７】
Ｓ６５０において、前記スケジューラは前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定する。
【００８８】
Ｓ６６０において、前記スケジューラは前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信する。
【００８９】
スケジューラは、タスクスケジューリングキューにおけるタスクをスケジューリングし、タスクスケジューリングキューにおける各タスクとそれに対応するターゲット物理的なノードとのバンディング情報を取得する。
【００９０】
Ｓ６７０において、物理的なノードは前記ＡＰＩサーバにおけるタスクと物理的なノードとのバンディング情報を傍受することにより、対応するタスクを取得し、タスクキューを形成する。
【００９１】
物理的なノードは、ＡＰＩサーバにおけるバンディング情報を傍受し、バンディング情報におけるターゲット物理的なノードにより、該物理的なノードに対応するタスクを確定する。該タスクは１つであってもよいし、複数であってもよく、これらのタスクをタスクキューに形成する。
【００９２】
Ｓ６８０において、前記物理的なノードが前記タスクキューにおける実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得する。
【００９３】
物理的なノードは、タスクキューにおけるタスクの並び順に基づき、タスクを順に処理する。実行待ちのターゲットタスクとは、タスクキューにおける物理的なノードが現在処理しているタスクを意味する。
【００９４】
Ｓ６９０において、前記物理的なノードは、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出する。
【００９５】
物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、Ｓ６９１を実行し、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たすと検出した場合、Ｓ６９２を実行する。
【００９６】
Ｓ６９１において、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行して得る残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクよりも低いタスクを、優先度の低い順で削除待ちのキューに移動し、ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションする。
【００９７】
Ｓ６９２において、前記物理的なノードは実行環境を呼び出し、前記ターゲットタスクを実行する。
【００９８】
関連技術のＫｕｂｅｒｎｅｔｅｓ  １．３バージョンは、サービス品質（Ｑｕａｌｉｔｙ  Ｏｆ  Ｓｅｒｖｉｃｅ）のリソース共有形態に基づき、共有リソースを管理するために使用され、サービス品質は高い順でそれぞれＧｕａｒａｎｔｅｅ、ＢｕｒｓｔａｂｌｅおよびＢｅｓｔ  Ｅｆｆｏｒｔである。ここで、Ｂｅｓｔ  Ｅｆｆｏｒｔのタスクは、クラスタリソースが十分に使用されていない場合にスケジューリングされて実行できる。クラスタリソースが逼迫している場合、Ｂｅｓｔ  Ｅｆｆｏｒｔのタスクは優先的にプリエンプションされる。このような形態は、タスクスケジューリングの一環を考慮したことがなく、クラスタのスケジューリングが満了した場合、高いサービス品質のタスクにリソースを譲ることができず、且つテナント内のＢｅｓｔ  Ｅｆｆｏｒｔタスクの数を制限することができず、Ｂｅｓｔ  Ｅｆｆｏｒｔタスクのプリエンプションされる順を区別することができない。
【００９９】
関連技術のＫｕｂｅｒｎｅｔｅｓ  １．８バージョンに導入された優先度に基づくスケジューリング形態は、タスクの優先度を設定することができ、リソースが逼迫している場合、スケジューラは低優先度のタスクをプリエンプションし、高優先度のタスクに十分なリソースを提供する。しかし、該形態において、タスクのプリエンプションはスケジューラで発生し、即ち、クラスタロジックのスケジューリングが満了した時に発生し、クラスタにはリソースが十分に利用されていない場合があり、リソースの利用率は高くなく、且つ各優先度のタスクの数を正確に制限することができない。
【０１００】
関連技術におけるスケジューリング形態に対し、本発明の実施例に係る方法は、テナントのリソース割り前に対して優先度を設定し、各テナントにおける複数種の優先度のタスクの数を正確に制限することができ、タスクの優先度の設定により、タスクがプリエンプションされる時、タスクのプリエンプションされる順を区別することができる。本発明の実施例において、優先度に基づくタスクプリエンプションは物理的なノードで発生し、スケジューラで発生することがなく、論理的には高優先度のタスクにリソースを譲ることができ、リソースが十分に利用されていない場合、プリエンプションされたタスクを実行し続け、リソースの利用率を向上させることができる。
【０１０１】
本発明の実施例に係る方法は、テナントのリソース割り前に対して優先度を設定し、タスクの優先度と対応するテナントにおける複数の優先度のリソースとをマッチングすることにより、タスクを作成するか否かを確定し、テナントにリソースが逼迫している場合にリソースを優先的に使用させ、テナントが高優先度のリソースを悪用して低優先度のタスクがリソースを持続的に取得できなくて「餓死」という現象が現れることを防止することができる。スケジューラは、タスクの優先度および所定のスクリーニング条件に基づいて物理的なノードをスクリーニングし、最適な物理的なノードをスクリーニングし、スケジューリング待ちの現在のタスクを最適な物理的なノードにスケジューリングし、リソースが逼迫している場合、論理的なのリソースプリエンプションのみを行い、リソースを直ちにプリエンプションせず、このようなプリエンプションを遅延させるスケジューリング方法は、論理的に高優先度のタスクにリソースを譲ることができ、リソースが十分に利用されていない場合、プリエンプションされたタスクを実行し続け、リソースの利用率を向上させることができる。物理的なノードが実行待ちのターゲットタスクを処理する時、物理的なノードの残りのリソースがターゲットタスクの実行に必要な条件を満たさないと、低優先度のタスクをプリエンプションすることに基づき、物理的なノードは重要なタスクを優先的に処理し、リソースの利用率を向上させることができる。
【０１０２】
図７は、本発明の実施例に係るＡＰＩサーバの構造ブロック図であり、図７に示すように、前記ＡＰＩサーバは、要求取得モジュール７１０と、タスク作成モジュール７２０とを備える。
【０１０３】
要求取得モジュール７１０は、タスクの作成要求を取得するように構成される。
【０１０４】
タスク作成モジュール７２０は、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成するように構成される。
【０１０５】
好ましくは、前記装置はＫｕｂｅｒｎｅｔｅｓシステムに適用され、要求取得モジュール７１０は、ｐｏｄの作成要求を取得するように構成される。
【０１０６】
タスク作成モジュール７２０は、前記ｐｏｄに対応するｎａｍｅｓｐａｃｅのｑｕｏｔａに前記ｐｏｄの優先度とマッチングするリソースｑｕｏｔａ値が含まれ、且つｑｕｏｔａ値が前記ｐｏｄの作成条件を満たすと検出した場合、前記作成要求に応じてｐｏｄを作成するように構成される。
【０１０７】
上記タスク作成装置は、本発明のいずれかの実施例に係るタスク作成方法を実行でき、タスク作成方法の実行に対応する機能モジュールおよび有益な効果を有する。
【０１０８】
図８ａは、本発明の実施例に係るスケジューラの構造ブロック図であり、図８ａに示すように、前記スケジューラは、マッピングテーブル形成モジュール８１０と、スクリーニングモジュール８２０と、バンディングモジュール８３０とを備える。
【０１０９】
マッピングテーブル形成モジュール８１０は、タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成するように構成される。
【０１１０】
スクリーニングモジュール８２０は、前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定するように構成される。
【０１１１】
バンディングモジュール８３０は、前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信するように構成される。
【０１１２】
好ましくは、スクリーニングモジュール８２０は、
前記マッピングテーブルから第１段階のスクリーニング条件に合致する物理的なノードをスクリーニングし、ノードグループを形成し、
前記マッピングテーブルおよび第２段階の好適な条件に基づき、前記ノードグループの物理的なノードをスコアリングし、スコアが最も高い物理的なノードをターゲット物理的なノードとしてスクリーニングするように構成される。
【０１１３】
好ましくは、前記装置はＫｕｂｅｒｎｅｔｅｓシステムに適用され、マッピングテーブル形成モジュール８１０は、ｐｏｄスケジューリングキューからスケジューリング待ちの現在のｐｏｄを取得し、各物理的なノードにおける前記現在のｐｏｄの指定優先度以上のｐｏｄを取得し、ノード−ｐｏｄのマッピングテーブルを形成するように構成される。
【０１１４】
それに対応し、バンディングモジュール８３０は、前記現在のｐｏｄと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信するように構成される。
【０１１５】
ここで、スケジューラ構造は他の構造形式であってもよく、タスクスケジューリング方法を実行できればよい。例えば、スケジューラにはスケジューリングシステムが含まれ、図８ｂに示すように、スケジューリングシステムは、ノード情報リスト８４０と、スクリーニングアルゴリズムライブラリ８５０と、好適なアルゴリズムライブラリ８６０と、スケジューリングされていないキュー８７０という４つの部分を含んでもよい。
【０１１６】
ここで、ノード情報リスト８４０は、物理的なノードにおけるリソース情報（全てのリソースおよび使用可能なリソース）および物理的なノードで実行しているタスクキューを含む現在の使用可能な物理的なノード情報を記載するように構成される。この部分の情報はスケジューリング方法を指定する際にキーとなる情報であり、スケジューリングシステムがリソースおよびタスクを全面的に認知することを確保するために、リアルタイムかつ同期する必要がある。
【０１１７】
スクリーニングアルゴリズムライブラリ８５０は、複数種の物理的なノードをスクリーニングするアルゴリズムを予め定義し、タスク実行条件を満たさない物理的なノードを除去することを確保するように構成される。
【０１１８】
好適なアルゴリズムライブラリ８６０は、複数種の好適なノードのアルゴリズムおよびアルゴリズムの重みを予め定義するように構成され、好適なアルゴリズムで計算されたスコアが最も高い物理的なノードは、スケジューリングノード、即ち、ターゲット物理的なノードとして選択される。
【０１１９】
スケジューリングキュー８７０は、スケジューリングされていないタスクで形成されたキューとして構成され、高優先度のタスクが先にスケジューリングされることを確保するための１つの優先度キューである。
【０１２０】
上記装置は、本発明のいずれかの実施例に係るタスクスケジューリング方法を実行することができ、タスクスケジューリング方法の実行に対応する機能モジュールおよび有益な効果を備える。
【０１２１】
図９は、本発明の実施例に係るタスクプリエンプション装置の構造ブロック図であり、図９に示すように、前記タスクプリエンプション装置は、タスクリスト取得モジュール９１０と、検出モジュール９２０と、プリエンプションモジュール９３０と、タスク実行モジュール９４０とを備える。
【０１２２】
ここで、タスクリスト取得モジュール９１０は、実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得するように構成される。
【０１２３】
検出モジュール９２０は、物理的なノードにおける残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出するように構成される。
【０１２４】
プリエンプションモジュール９３０は、物理的なノードにおける残りのリソースがターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクよりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し（即ち、優先度の低い順でタスクをタスクリストから順に移出する）、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションするように構成される。
【０１２５】
タスク実行モジュール９４０は、前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行するように構成される。
【０１２６】
好ましくは、前記プリエンプションモジュールは、更に、設定時間おきにリソース使用情報を取得するように構成されてもよい。
【０１２７】
前記リソース使用情報が所定の制限条件に達したことを確定すると、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に確定されるリソース使用情報が所定の制限条件に達していないまで前記タスクリストにおけるタスクを優先度の低い順で前記削除待ちのキューに順に移動し、前記削除待ちのキューにおけるタスクを停止する。
【０１２８】
好ましくは、前記装置はＫｕｂｅｒｎｅｔｅｓシステムに適用され、前記ターゲットタスクはターゲットｐｏｄであり、前記タスクリストはｐｏｄリストであり、前記タスクリストにおけるタスクは前記物理的なノードで実行しているｐｏｄである。
【０１２９】
上記装置は、本発明のいずれかの実施例に係るタスクプリエンプション方法を実行でき、タスクプリエンプション方法の実行に対応する機能モジュールおよび有益な効果を備える。
【０１３０】
図１０は、本発明の実施例に係るタスクプリエンプションシステムの構造模式図であり、図１０に示すように、前記タスクプリエンプションシステムは、上記実施例に係るＡＰＩサーバ１０１０と、上記実施例に係るスケジューラ１０２０と、上記実施例に係るタスクプリエンプション装置１０３０とを備える。
【０１３１】
好ましくは、ＡＰＩサーバ１０１０およびスケジューラ１０２０はそれぞれクラスタ管理プラットフォームのコンポーネントであり、クラスタ管理プラットフォームはユーザが使用するコンピュータ装置に集積される。タスクプリエンプション装置１０３０は物理的なノードにおける物理マシンに集積されてもよい。
【０１３２】
図１１は、本発明の実施例に係る装置の構造模式図であり、図１１に示すように、該装置は、１つまたは複数のプロセッサ１１１０（図１１では１つのプロセッサ１１１０を例とする）と、メモリ１１２０とを備える。
【０１３３】
前記装置は、入力装置１１３０と、出力装置１１４０とを更に備えてもよい。
【０１３４】
前記装置におけるプロセッサ１１１０、メモリ１１２０、入力装置１１３０および出力装置１１４０は、バスまたは他の方式により接続でき、図１１ではバスによる接続を例とする。
【０１３５】
メモリ１１２０は、非一時的コンピュータ可読記憶媒体として、本発明の実施例におけるタスク作成方法に対応するプログラム命令／モジュール（例えば、図面７に示す要求取得モジュール７１０およびタスク作成モジュール７２０）、または本発明の実施例におけるタスクスケジューリング方法に対応するプログラム命令／モジュール（例えば、図面８に示すマッピングテーブル形成モジュール８１０、スクリーニングモジュール８２０およびバンディングモジュール８３０）、または本発明の実施例におけるタスクプリエンプション方法に対応するプログラム命令／モジュール（例えば、図面９に示すタスクリスト取得モジュール９１０、検出モジュール９２０、プリエンプションモジュール９３０およびタスク実行モジュール９４０）のようなソフトウェアプログラム、コンピュータ実行可能プログラムおよびモジュールを記憶するために使用できる。プロセッサ１１１０は、メモリ１１２０に記憶されたソフトウェアプログラム、命令およびモジュールを実行することにより、コンピュータ装置の様々な機能アプリケーションおよびデータ処理を実行し、即ち、ＡＰＩサーバがタスクの作成要求を取得することと、ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することとを含む上記方法実施例のタスク作成方法を実現する。
【０１３６】
または、プロセッサ１１１０は、メモリ１１２０に記憶されたソフトウェアプログラム、命令およびモジュールを実行することにより、スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定することと、前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することとを含む上記方法の実施例のタスクスケジューリング方法を実現する。
【０１３７】
または、プロセッサ１１１０は、メモリ１１２０に記憶されたソフトウェアプログラム、命令およびモジュールを実行することにより、物理的なノードが実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、前記物理的なノードが、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することとを含む上記方法の実施例のタスクプリエンプション方法を実現する。
【０１３８】
メモリ１１２０は、プログラム記憶エリアおよびデータ記憶エリアを含んでもよく、ここで、プログラム記憶エリアはオペレーティングシステム、少なくとも１つの機能に必要なアプリケーションプログラムを記憶することができ、データ記憶エリアは、コンピュータ装置の使用に基づいて作成されたデータ等を記憶することができる。また、メモリ１１２０は高速ランダムアクセスメモリを含んでもよく、少なくとも１つの磁気ディスク記憶装置、フラッシュメモリ装置、または他の非一時的固体記憶装置のような非一時的メモリを更に含んでもよい。好ましくは、いくつかの実施例において、メモリ１１２０は、プロセッサ１１１０に対して遠隔に設けられたメモリを含んでもよく、これらのリモートメモリは、ネットワークを介して端末装置に接続することができる。上記ネットワークのインスタンスは、インターネット、イントラネット、ローカルエリアネットワーク、移動体通信ネットワークおよびその組み合わせを含むが、これらに限定されない。
【０１３９】
入力装置１１３０は、入力された数字または文字情報を受信し、およびコンピュータ装置のユーザ設定および機能制御に関連するキー信号入力を生じるために使用できる。出力装置１１４０はディスプレイ等の表示装置を含んでもよい。
【０１４０】
本発明の実施例は、コンピュータプログラムが記憶されているコンピュータ可読記憶媒体を提供し、該プログラムがプロセッサにより実行されると、タスクの作成要求を取得することと、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出し場合、前記作成要求に応じて前記タスクを作成することとを含む本発明の実施例に係るタスク作成方法を実現する。
【０１４１】
または、該プログラムがプロセッサにより実行されると、スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定することと、前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することとを含む上記方法の実施例のタスクスケジューリング方法を実現する。
【０１４２】
または、該プログラムがプロセッサにより実行されと、物理的なノードが実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、前記物理的なノードが、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することとを含む上記方法実施例のタスクプリエンプション方法を実現する。
【０１４３】
１つまたは複数のコンピュータ可読信号媒体の任意の組み合わせを採用してもよい。コンピュータ可読信号媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体であってもよい。コンピュータ可読記憶媒体は、例えば、電気、磁気、光、電磁、赤外線、または半導体のシステム、装置もしくは装置、または以上の任意の組み合わせであってもよいが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例（非網羅的なリスト）は、１つまたは複数の導線を有する電気的接続、携帯型コンピュータ磁気ディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラマブル読み出し専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、光ファイバ、携帯型コンパクト磁気ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、または上記任意の適当な組み合わせを含む。本明細書において、コンピュータ可読記憶媒体は、プログラムを含むまたは記憶する任意の有形媒体であってもよく、該プログラムは、命令実行システム、装置または装置により使用されてもよく、それと合わせて使用されてもよい。
【０１４４】
コンピュータ可読信号媒体は、ベースバンドでまたはキャリアの一部として伝播するデータ信号を含んでもよく、その中にコンピュータ可読プログラムコードが担持されている。このような伝播するデータ信号は様々な形式を採用することができ、電磁信号、光信号または上記任意の適当な組み合わせを含むが、これらに限定されない。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体以外の任意のコンピュータ可読信号媒体であってもよく、該コンピュータ可読信号媒体は、命令実行システム、装置または装置に使用されるまたはそれと合わせて使用されるプログラムを送信、伝播または伝送することができる。
【０１４５】
コンピュータ可読信号媒体に含まれるプログラムコードは、任意の適当な媒体で伝送でき、無線、電線、光ケーブル、ＲＦ等、または上記任意の適当な組み合わせを含むが、これらに限定されない。
【０１４６】
本発明の操作を実行するためのコンピュータプログラムコードは、１種または複数種のプログラミング言語またはその組み合わせでプログラミングすることができ、前記プログラミング言語は、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋のようなオブジェクト指向プログラミング言語を含み、「Ｃ」言語または類似するプログラミング言語のような通常の手続き型プログラミング言語を更に含む。プログラムコードは、完全にユーザコンピュータで実行されてもよく、一部がユーザコンピュータで実行されてもよく、１つの独立したソフトウェアパッケージとして実行されてもよく、一部がユーザコンピュータで一部がリモートコンピュータで実行されてもよく、または完全にリモートコンピュータまたはサーバで実行されてもよい。リモートコンピュータに関する場合に、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意種のネットワークを介してユーザコンピュータに接続でき、または、外部のコンピュータ（例えば、インターネットサービスを提供するプロバイダを利用してインターネットを介して接続される）に接続できる。
【図１】
2021522621.tif 000003
【図２】
2021522621.tif 000004
【図３】
2021522621.tif 000005
【図４】
2021522621.tif 000006
【図５】
2021522621.tif 000007
【図６】
2021522621.tif 000008
【図７】
2021522621.tif 000009
【図８ａ】
2021522621.tif 000010
【図８ｂ】
2021522621.tif 000011
【図９】
2021522621.tif 000012
【図１０】
2021522621.tif 000013
【図１１】
2021522621.tif 000014
【手続補正書】
【提出日】令和2年12月25日(2020.12.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、
前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定することと、
前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することと、
を含む、タスクスケジューリング方法。
【請求項２】
前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定することは、
前記スケジューラが前記マッピングテーブルから第１段階のスクリーニング条件に合致する物理的なノードをスクリーニングし、ノードグループを形成することと、
前記マッピングテーブルおよび第２段階のスクリーニング条件に基づき、前記ノードグループの物理的なノードをスコアリングし、スコアが最も高い物理的なノードをスクリーニングしてターゲット物理的なノードとすることと、
を含む、請求項１に記載の方法。
【請求項３】
前記スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの指定優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することは、
前記スケジューラがｐｏｄスケジューリングキューからスケジューリング待ちの現在のｐｏｄを取得し、各物理的なノードにおける前記現在のｐｏｄの優先度以上のｐｏｄを取得し、ノード−ｐｏｄのマッピングテーブルを形成することを含み、
前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することは、
前記スケジューラが前記現在のｐｏｄと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信することを含む、請求項１または請求項２に記載の方法。
【請求項４】
アプリケーションプログラミングインタフェースＡＰＩサーバがタスクの作成要求を取得することと、
前記ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することと、
スケジューラが前記ＡＰＩサーバにより作成されたタスクを取得し、タスクスケジューリングキューを形成することと、
前記スケジューラが前記タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの指定優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、
前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定することと、
前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することと、
物理的なノードが前記ＡＰＩサーバにおけるタスクと物理的なノードとのバンディング情報を傍受し、傍受した前記バンディング情報に基づいて対応するタスクを取得し、タスクキューを形成することと、
前記物理的なノードが前記タスクキューにおける実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、
前記物理的なノードは、前記タスクリストにおけるタスクを実行した後の残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、
ターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードは、前記物理的なノードの残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクよりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、
前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することと、
を含む、プリエンプティブスケジューリングに基づくリソース共有使用方法。
【請求項５】
ＡＰＩサーバがタスクの作成要求を取得することは、
ＡＰＩサーバがｐｏｄの作成要求を取得することを含み、
前記ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することは、
前記ＡＰＩサーバが、前記ｐｏｄに対応するｎａｍｅｓｐａｃｅのｑｕｏｔａに前記ｐｏｄに対応する優先度とマッチングするリソースのｑｕｏｔａ値が含まれ、且つ前記ｑｕｏｔａ値が前記ｐｏｄの作成条件を満たすと検出した場合、前記作成要求に応じてｐｏｄを作成することを含む、請求項４に記載の方法。
【請求項６】
前記物理的なノードは、設定時間おきにリソース使用情報を取得することと、
前記物理的なノードは、前記リソース使用情報が所定の制限条件に達したことを確定した場合、前記物理的なノードが前記タスクリストにおけるタスクを実行する時に確定するリソース使用情報が所定の制限条件に達していないまで前記タスクリストにおけるタスクを優先度の低い順で前記削除待ちのキューに順に移動し、前記削除待ちのキューにおけるタスクを停止することと、
を更に含む、請求項４に記載の方法。
【請求項７】
前記ターゲットタスクはターゲットｐｏｄであり、前記タスクリストはｐｏｄリストであり、前記タスクリストにおけるタスクは前記物理的なノードで実行しているｐｏｄである、請求項４または請求項６に記載の方法。
【請求項８】
タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成するよう構成されるマッピングテーブル形成モジュールと、
前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定するように構成されるスクリーニングモジュールと、
前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信するように構成されるバンディングモジュールと、
を備える、スケジューラ。
【請求項９】
ＡＰＩサーバと、請求項８に記載のスケジューラと、タスクプリエンプション装置とを備え、
前記ＡＰＩサーバは、
タスクの作成要求を取得するように構成される要求取得モジュールと、
前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成するように構成されるタスク作成モジュールと、
を備え、
前記タスクプリエンプション装置は、
実行待ちのターゲットタスクを処理する時、物理的なノードで実行しているタスクリストを取得するように構成されるタスクリスト取得モジュールと、
物理的なノードにおける残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出するように構成される検出モジュールと、
検出モジュールが、物理的なノードにおける残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおけるタスクを、優先度の低い順で削除待ちのキューに順に移動し、且つ前記削除待ちのキューにおけるタスクの優先度が前記ターゲットタスクの優先度よりも小さく、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションするように構成されるプリエンプションモジュールと、
実行環境を呼び出し、前記ターゲットタスクを実行するように構成されるタスク実行モジュールと、
を備える、プリエンプティブスケジューリングに基づくリソース共有使用システム。
【請求項１０】
１つまたは複数のプロセッサと、
１つまたは複数のプログラムを記憶するための記憶装置と、
を備え、
前記１つまたは複数のプログラムが前記１つまたは複数のプロセッサにより実行されると、前記１つまたは複数のプロセッサは、請求項１〜３のいずれか１項に記載のタスクスケジューリング方法を実現する、装置。
【請求項１１】
プロセッサにより実行されると、請求項１〜３のいずれか１項に記載のタスクスケジューリング方法を実現するコンピュータプログラムが記憶されている、コンピュータ可読記憶媒体。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、２０１８年６月２５日に中国専利局に提出された出願番号が２０１８１０６５９２９８．５である中国特許出願に対して優先権を主張するものであり、該出願の全ての内容を引用により本発明に援用する。
【０００２】
本発明は、コンピュータ技術分野に関し、例えば、タスクスケジューリング方法、プリエンプティブスケジューリングに基づくリソース共有使用方法およびシステム、スケジューラ、装置、ならびにコンピュータ可読記憶媒体に関する。
【背景技術】
【０００３】
リソース共有の分散システムにおいて、複数のテナントがリソースを共有して使用し、それと同時に、各テナントがいずれも使用可能なリソースを有することを確保し、テナントのリソースが「餓死」となる現象がないように、各テナントが使用するリソースに対してある程度限定する必要がある。分散システムにおけるスケジューラは、複数のテナントの作業またはタスクを効果的にスケジューリングすることにより、各テナントの作業またはタスクが安定して迅速に実行されるとともに、分散システム内のリソースが十分に利用されることを確保する。
【０００４】
従来の分散管理システムは、複数のスケジューリングポリシーを提供することにより、複数のテナントのタスクが分散システムで物理的なノードにバランスよく割り当てられ、更に物理的なノードが割り当てられたタスクを実行することを確保する。しかし、タスクの処理方式には、リソースが十分に利用されていない現象が存在する。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の実施例は、リソースの利用率を向上させることができる、プリエンプティブスケジューリングに基づくリソース共有使用方法、システムおよび装置を提供する。
【課題を解決するための手段】
【０００６】
第１態様において、本発明の実施例は、ＡＰＩサーバがタスクの作成要求を取得することと、ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することとを含む、タスク作成方法を提供する。
【０００７】
第２態様において、本発明の実施例は、スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定することと、前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することとを含む、タスクスケジューリング方法を更に提供する。
【０００８】
第３態様において、本発明の実施例は、物理的なノードが実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、前記物理的なノードが、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、残りのリソースがターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することとを含むタスクプリエンプション方法を更に提供する。
【０００９】
第４態様において、本発明の実施例は、ＡＰＩサーバがタスクの作成要求を取得することと、前記ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することと、スケジューラが前記ＡＰＩサーバにより作成されたタスクを取得し、タスクスケジューリングキューを形成することと、前記スケジューラが前記タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定することと、前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することと、物理的なノードが前記ＡＰＩサーバにおけるタスクと物理的なノードとのバンディング情報を傍受し、傍受した前記バンディング情報に基づいて対応するタスクを取得し、タスクキューを形成することと、前記物理的なノードが前記タスクキューにおける実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、前記物理的なノードが、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、残りのリソースがターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することとを含むプリエンプティブスケジューリングに基づくリソース共有使用方法を更に提供する。
【００１０】
第５態様において、本発明の実施例は、タスクの作成要求を取得するように構成される要求取得モジュールと、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成するように構成されるタスク作成モジュールとを備えるＡＰＩサーバを更に提供する。
【００１１】
第６態様において、本発明の実施例は、タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成するよう構成されるマッピングテーブル形成モジュールと、前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定するように構成されるスクリーニングモジュールと、前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信するように構成されるバンディングモジュールとを備えるスケジューラを更に提供する。
【００１２】
第７態様において、本発明の実施例は、実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得するように構成されるタスクリスト取得モジュールと、物理的なノードにおける残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出するように構成される検出モジュールと、残りのリソースがターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードが前記タスクリストにおけるタスクを実行して得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションするように構成されるプリエンプションモジュールと、実行環境を呼び出し、前記ターゲットタスクを実行するように構成されるタスク実行モジュールとを備えるタスクプリエンプション装置を更に提供する。
【００１３】
第８態様において、本発明の実施例は、本発明の実施例に係るＡＰＩサーバと、スケジューラと、タスクプリエンプション装置とを備えるプリエンプティブスケジューリングに基づくリソース共有使用システムを更に提供する。
【００１４】
第９態様において、本発明の実施例は、１つまたは複数のプロセッサと、１つまたは複数のプログラムを記憶するための記憶装置とを備える装置を更に提供する。
【００１５】
前記１つまたは複数のプログラムが前記１つまたは複数のプロセッサにより実行されると、前記１つまたは複数のプロセッサは、本発明の実施例に係るタスク作成方法、または本発明の実施例に係るタスクスケジューリング方法、または本発明の実施例に係るタスクプリエンプション方法を実現する。
【００１６】
第１０態様において、本発明の実施例は、プロセッサにより実行されると、本発明の実施例に係るタスク作成方法、または本発明の実施例に係るタスクスケジューリング方法、または本発明の実施例に係るタスクプリエンプション方法を実現するコンピュータプログラムが記憶されているコンピュータ可読記憶媒体を提供する。
【発明の効果】
【００１７】
本発明の実施例に係る技術案は、テナントのリソース割り前に対して優先度を設定し、タスクの優先度と対応するテナントにおける各優先度のリソースとをマッチングすることにより、タスクを作成するか否かを確定し、テナントにリソースが逼迫している場合にリソースを優先的に使用させ、テナントが高優先度のリソースを悪用して低優先度のタスクがリソースを持続的に取得できなくて「餓死」という現象が現れることを防止することができる。スケジューラは、タスクの優先度および所定のスクリーニング条件により物理的なノードをスクリーニングし、最適な物理的なノードをスクリーニングし、スケジューリング待ちの現在のタスクを最適な物理的なノードにスケジューリングし、リソースが逼迫している場合、論理的なリソースプリエンプションのみを行い、リソースを直ちにプリエンプションせず、このようなプリエンプションを遅延させるスケジューリング方法は、論理的に高優先度のタスクにリソースを譲ることができ、リソースが十分に利用されていない場合、プリエンプションされたタスクを実行し続け、リソースの利用率を向上させることができる。物理的なノードが実行待ちのターゲットタスクを処理する時、物理的なノードの残りのリソースがターゲットタスクの実行に必要な条件を満たさないと、低優先度のタスクをプリエンプションすることに基づき、物理的なノードは重要なタスクを優先的に処理することができ、リソースの利用率を向上させることができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施例に係るタスク作成方法のフローチャートである。
【図２】本発明の実施例に係るタスクスケジューリング方法のフローチャートである。
【図３】本発明の実施例に係るタスクスケジューリング方法のフローチャートである。
【図４】本発明の実施例に係るタスクプリエンプション方法のフローチャートである。
【図５】本発明の実施例に係るタスクプリエンプション方法のフローチャートである。
【図６】本発明の実施例に係るプリエンプティブスケジューリングに基づくリソース共有使用方法のフローチャートである。
【図７】本発明の実施例に係るＡＰＩサーバの構造ブロック図である。
【図８ａ】本発明の実施例に係るスケジューラの構造ブロック図である。
【図８ｂ】本発明の実施例に係るスケジューリングシステムの構造模式図である。
【図９】本発明の実施例に係るタスクプリエンプション装置の構造ブロック図である。
【図１０】本発明の実施例に係るプリエンプティブスケジューリングに基づくリソース共有使用システムの構造ブロック図である。
【図１１】本発明の実施例に係る装置の構造模式図である。
【発明を実施するための形態】
【００１９】
以下、図面および実施例を参照しながら本発明について説明する。ここで説明する具体的な実施例は本発明を解釈するためのものに過ぎず、本発明を限定するものではないことが理解できる。なお、説明の便宜上、図面において、全ての内容ではなく、本発明に関連する部分のみを示す。
【００２０】
図１は、本発明の実施例に係るタスク作成方法のフローチャートであり、前記方法は、アプリケーションプログラミングインタフェース（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ、ＡＰＩ）サーバ（ＡＰＩ  Ｓｅｒｖｅｒ）に適用でき、ＡＰＩサーバにより実行され、該ＡＰＩサーバは、クラスタ管理プラットフォームにおける１つのコンポーネントであってもよく、ソフトウェアおよび／またはハードウェアの形態で実現され、クラスタ管理プラットフォームは、クラスタにおける大量のリソースを管理するプラットフォームであってもよく、クラスタ管理プラットフォームは、ＫｕｂｅｒｎｅｔｅｓおよびＭｅｓｏｓを含んでもよいが、これらに限定されず、且つ、複数のコンピュータ装置に集積できる。図１に示すように、本発明の実施例に係るタスク作成方法はＳ１１０〜Ｓ１２０を含む。
【００２１】
Ｓ１１０において、ＡＰＩサーバがタスクの作成要求を取得する。
【００２２】
本発明の実施例に係る方法はクラスタに適用でき、クラスタには複数の物理的なノードが含まれてもよく、各物理的なノードにおけるリソースは複数のテナントの共有リソースであってもよく、複数の物理的なノードはクラスタ管理プラットフォームにより管理されてもよく、クラスタ管理プラットフォームはタスクを物理的なノードに割り当てて物理的なノードに対応するタスクを実行させる。クラスタ管理プラットフォームは複数のコンピュータ装置に集積でき、複数のコンピュータ装置はユーザが操作でき、ユーザはクラスタ管理プラットフォームに登録してタスクの作成要求を提出することができ、クラスタ管理プラットフォームにおけるＡＰＩサーバはユーザにより提出されたタスクの作成要求を取得してタスクを作成する。クラスタ管理プラットフォームにおけるスケジューラはタスクスケジューリングを行い、タスクを対応する物理的なノードに合理的に割り当てる。物理的なノードは該タスクを実行する。
【００２３】
ここで、ＡＰＩサーバはクラスタ管理プラットフォームにおける１つのコンポーネントであってもよく、タスクの作成を完了することができ、豊かな機能性プラグインを提供し、クラスタに対する管理等を完備する。
【００２４】
ここで、ＡＰＩサーバは、ユーザが提出した１つのタスクの作成要求を取得することができ、例えば、ユーザが提出した１つのアプリケーションを作成する要求を取得することができる。ここで、ユーザがタスクの作成要求を提出する時、タスクの優先度を設定することができる。
【００２５】
Ｓ１２０において、ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成する。
【００２６】
ユーザが管理粒度で複数のグループに分けられ、各グループが１つのテナントと呼ばれ、必要に応じて各テナントに割り前を予め設定することができ、割り前は１グループのリソースであってもよく、例えば、該グループのリソースは、プロセッサ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、ＣＰＵ）、メモリ、グラフィックプロセッサ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、ＧＰＵ）、フィールドプログラマブルゲートアレイ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ、ＦＰＧＡ）、人工知能（Ａｒｔｉｆｉｃｉａｌ  Ｉｎｔｅｌｌｉｇｅｎｃｅ、ＡＩ）チップ、プロセッサの優先度およびメモリの優先度、ＧＰＵ優先度、ＦＰＧＡ優先度、ＡＩチップ優先度等を含んでもよく、各テナントにリソース割り前を予め設定することができる。割り前を合理的に設定することにより、適当な優先度のリソースを使用するようにテナントをグラントすることができ、テナントは、リソースが逼迫している場合にリソースを優先的に使用でき、更に、テナントが高優先度のリソースを悪用して低優先度のタスクがリソースを持続的に取得できなくて「餓死」の現象が現れることを制限することができる。
【００２７】
ユーザがクラスタ管理プラットフォームによりタスクの作成要求を提出する場合、各タスクには識別情報が担持され、ＡＰＩサーバは、識別情報に基づいて各タスクに対応するテナントを識別し、該テナントの割り前に該タスクの優先度とマッチングするリソースが含まれるか否か判断し、該タスクの優先度とマッチングするリソースが含まれている場合、該マッチングリソースが該タスクの作成条件を満たすか否かを判断し続け、該マッチングリソースが該タスクの作成条件を満たすと、タスクを作成することができる。
【００２８】
作成条件はＣＰＵの数および／またはメモリの占有率であってもよく、他の条件であってもよい。例えば、ユーザがタスクの作成要求を提出する時、クラスタ管理プラットフォームにより該タスクの優先度を高優先度とすることができ、すると、該タスクに必要なリソースの優先度も高優先度となり、例えば、該タスクは１０個の高優先度のＣＰＵを必要とする。該タスクに対応するテナントの割り前には高優先度のＣＰＵが含まれ、且つ高優先度のＣＰＵの数が１０以上であれば、該タスクを作成する。
【００２９】
本発明の１つの実施形態において、好ましくは、本発明の実施例に係る方法はＫｕｂｅｒｎｅｔｅｓ環境に適用できる。前記サーバがタスクの作成要求を取得することは、ＡＰＩサーバがタスクｐｏｄの作成要求を取得することを含む。ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することは、前記ＡＰＩサーバが、前記タスクｐｏｄに対応するテナントｎａｍｅｓｐａｃｅの割り前ｑｕｏｔａに前記ｐｏｄに対応する優先度とマッチングするリソースのｑｕｏｔａ値が含まれ、且つ該ｑｕｏｔａ値が前記タスクｐｏｄの作成条件を満たすと検出した場合、ＡＰＩサーバは前記作成要求に応じてｐｏｄを作成することを含む。
【００３０】
ここで、ｐｏｄは、ｋｕｂｅｒｎｅｔｅｓにおける最小に作成されて配置できる最も簡略な単位である。１つのｐｏｄは、クラスタ内で実行している１つのプロセスを表す。ｐｏｄはＫｕｂｅｒｎｅｔｅｓにおけるコンポーネントであり、例えば、１つのアプリケーションを作成してもよく、１つのプロセス等を起動してもよい。ｐｏｄにアプリケーションのコンテナー（ある場合に、いくつかのコンテナー）がパッケージされ、該コンテナーは独立したネットワークＩＰ、コンテナーがどのように実行するかを管理するポリシーオプション等を記憶することができる。ここで、ｐｏｄは配置された１つの単位を表し、ｋｕｂｅｒｎｅｔｅｓに適用される１つのインスタンスであり、１つまたは複数のコンテナーで組み合わせられてリソースを共有する可能性がある。ここで、１つのｐｏｄの作成は、１つのアプリケーションの作成等であってもよい。
【００３１】
ここで、Ｎａｍｅｓｐａｃｅは、１グループのリソースおよびオブジェクトの抽象的な集合であり、例えば、ｋｕｂｅｒｎｅｔｅｓシステム内部のオブジェクトを異なる項目グループまたはユーザグループに分けるために使用でき、ｎａｍｅｓｐａｃｅは、異なるテナントまたはユーザを隔離するために使用されることが多い。ｋｕｂｅｒｎｅｔｅｓにおいて、ｑｕｏｔａは、リソース管理およびリソース制限を行うために使用でき、ｑｕｏｔａ値の大きさは、リソースの多少を表すことができ、例えば、１つのテナントで設定されたリソースが２０個の高優先度のＣＰＵであれば、ｎａｍｅｓｐａｃｅにおけるｑｕｏｔａ値は２０であってもよく、即ち、ｑｕｏｔａ値はリソースの数を表すことができる。
【００３２】
本発明の実施例に係るタスク作成方法は、タスクの作成要求を取得すると、タスクに対応するテナントの割り前にタスクの優先度とマッチングするリソースが含まれるか否かを検出し、且つタスクの優先度とマッチングするリソースがタスクの作成条件を満たすか否かを検出し、２つの条件がいずれも満たされる（対応するテナントの割り前に該タスクの優先度とマッチングするリソースが含まれているとともに、該リソースも該タスクの作成条件を満たす）場合、該タスクを作成し、本実施例は、テナントのリソース割り前に対して優先度を設定し、タスクの優先度と対応するテナントにおける各優先度のリソースとをマッチングすることにより、タスクを作成するか否かを確定し、テナントにリソースが逼迫している場合にリソースを優先的に使用させ、テナントが高優先度のリソースを悪用して低優先度のタスクがリソースを持続的に取得できなくて「餓死」という現象が現れることを防止することができる。
【００３３】
図２は、本発明の実施例に係るタスクスケジューリング方法のフローチャートであり、前記方法はスケジューラに適用でき、スケジューラはクラスタ管理プラットフォームのコンポーネントであってもよく、ソフトウェアおよび／またはハードウェアの形態で実現され、クラスタ管理プラットフォームは、クラスタにおける大量のハードウェアリソースを管理するプラットフォームであってもよく、クラスタ管理プラットフォームは、ＫｕｂｅｒｎｅｔｅｓおよびＭｅｓｏｓを含んでもよいが、これらに限定されず、且つ、複数のコンピュータ装置に集積できる。本発明の実施例に係る方法は以下のような環境に適用できる。クラスタに複数の物理的なノードが含まれてもよく、複数の物理的なノードにおけるリソースは複数のテナントの共有リソースであってもよく、複数の物理的なノードはクラスタ管理プラットフォームにより管理されてもよく、クラスタ管理プラットフォームはタスクを物理的なノードに割り当てて物理的なノードに対応するタスクを実行させる。クラスタ管理プラットフォームは複数のコンピュータ装置に集積でき、複数のコンピュータ装置はユーザが操作でき、ユーザはクラスタ管理プラットフォームに登録してタスクの作成要求を提出することができ、クラスタ管理プラットフォームにおけるＡＰＩサーバはユーザにより提出されたタスクの作成要求を取得してタスクを作成し、クラスタ管理プラットフォームにおけるスケジューラはタスクスケジューリングを行い、タスクを対応する物理的なノードに合理的に割り当て、物理的なノードが該タスクを実行する。ここで、本発明の実施例はスケジューラがタスクスケジューリングを行う段階に適用される。
【００３４】
図２に示すように、本発明の実施例に係る技術案はＳ２１０〜Ｓ２３０を含む。
【００３５】
Ｓ２１０において、スケジューラはタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成する。
【００３６】
ここで、スケジューラはクラスタ管理プラットフォームのコンポーネントであってもよく、ＡＰＩサーバからＡＰＩサーバで作成されたタスクを傍受し、ＡＰＩサーバからタスクを読み取ることができ、読み取ったタスクがタスクスケジューリングキューを形成する。ここで、スケジューラはタスクスケジューリングキューにおけるタスクの順に従ってタスクをスケジューリングする。
【００３７】
物理的なノードは各種の物理マシンであってもよく、スケジューラは各物理的なノードからリソース情報（全てのリソースおよび使用可能なリソースを含む）および各物理的なノードで実行しているタスクキューを取得することができる。ここで、該タスクキューにおける各タスクはいずれも優先度を有する。スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得する時、各物理的なノードにおける現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成する。例えば、現在のタスクの優先度が高優先度であり、物理的なノード１における高優先度以上のタスクがタスク１、タスク２およびタスク３を有する場合、スケジューラは物理的なノード１におけるタスク１、タスク２およびタスク３を取得し、ノード−タスクのマッピングテーブルを形成する。ここで、物理的なノードにおける現在のタスクの優先度以上のタスクは、物理的なノードで実行している現在のタスクの優先度以上のタスクと、物理的なノードにおける実行待ちの現在のタスクの優先度以上のタスクとを含む。
【００３８】
Ｓ２２０において、前記スケジューラは前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定する。
【００３９】
スケジューラはノード−タスクマッピングテーブルから所定のスクリーニング条件に基づいてスクリーニングを行い、所定のスクリーニング条件に最も合致するターゲット物理的なノードをスクリーニングする。ここで、所定のスクリーニング条件は、現在のタスクに必要なリソースと物理的なノードにおける残りのリソースとの間のマッチング条件、および現在のタスクに必要なポートと物理的なノードにおけるポートとの間のマッチング条件等を含んでもよい。
【００４０】
本発明の１つの実施形態において、好ましくは、前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定することは、前記スケジューラがマッピングテーブルから第１段階のスクリーニング条件に合致する物理的なノードをスクリーニングし、ノードグループを形成することと、マッピングテーブルおよび第２段階のスクリーニング条件に基づき、前記ノードグループの物理的なノードをスコアリングし、スコアが最も高い物理的なノードをターゲット物理的なノードとしてスクリーニングすることとを含む。
【００４１】
ここで、第１段階のスクリーニング条件と第２段階のスクリーニング条件とは異なる。例えば、第１段階のスクリーニング条件は、現在のタスクに必要なポートと物理的なノード上のポートとの間のマッチング条件、物理的なノードに特殊なタグがあるか否か等であってもよく、第２段階のスクリーニング条件は、現在のタスクに必要なリソースと物理的なノードにおける残りのリソースとの間のマッチング条件であってもよく、且つ、第２段階のスクリーニング条件は１つの条件を含んでもよいし、複数の条件を含んでもよい。第２段階のスクリーニング条件が複数の条件を含む場合、各条件に重みを設け、重みに基づいて物理的なノードのスコアリングを確定してもよい。
【００４２】
該実施形態について例を挙げて説明し、第１段階のスクリーニング条件が、物理的なノードがＧＰＵのタグを有する必要があることであれば、第２段階のスクリーニング条件は、現在のタスクに必要なリソースと物理的なノードにおける残りのリソースとの間のマッチング条件を予め設定することである。ノード−タスクマッピングテーブルおよび取得した物理的なノードの情報を照合し、スケジューラは、ＧＰＵを有する物理的なノードを選択し、ノードグループを形成する。スケジューラは、ノードグループ内の物理的なノードにおける残りのリソースが現在のタスクに必要なリソース条件を満たすか否かを判断し、条件を満たさない物理的なノードを除去し、現在のタスクに必要なリソース条件の物理的なノードをスコアリングし、物理的なノードにおける残りのリソースが多ければ多いほど、該物理的なノードのスコアは高くなることで、スコアが最も高い物理的なノードはターゲット物理的なノードである。ここで、ターゲット物理的なノードをスクリーニングする方法は上記方法を含むが、これらに限定されない。
【００４３】
上記２回のスクリーニングにより、スコアが最も高い物理的なノードをターゲット物理的なノードとしてスクリーニングし、即ち、スコアが最も高い物理的なノードを最適な物理的なノードとしてスクリーニングし、１回のスクリーニングの場合に対し、毎回のスクリーニング時のデータの処理量を減少してタスクスケジューリングの効率を向上させることができる。
【００４４】
Ｓ２３０において、前記スケジューラは前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信する。
【００４５】
スケジューラは、現在のタスクとスクリーニングした所定のスクリーニング条件に最も合致する物理的なノード（即ち、ターゲット物理的なノード）とをバンディングすることにより、バンディングした情報をＡＰＩサーバに送信することで、各物理的なノードはＡＰＩサーバからそれぞれが実行するタスクを読み取ることができる。
【００４６】
本発明の実施例のスケジューラは、タスクの優先度および所定のスクリーニング条件に基づいて複数の物理的なノードをスクリーニングし、各タスクに対応する最適な物理的なノード（即ち、ターゲット物理的なノード）をスクリーニングし、スケジューリング待ちの現在のタスクを最適な物理的なノードにスケジューリングする。リソースが逼迫している場合、論理的なリソースプリエンプションのみを行い、リソースを直ちにプリエンプションせず、このようなプリエンプションを遅延させるスケジューリング方法は、論理的に高優先度のタスクにリソースを譲ることができ、リソースが十分に利用されていない場合、プリエンプションされたタスクを保留し続け、リソースの利用率を向上させることができる。
【００４７】
図３は、本発明の実施例に係るタスクスケジューリング方法のフローチャートであり、ここで、該実施例に係る方法はｋｕｂｅｒｎｅｔｅｓシステムに適用でき、図３に示すように、本実施例に係る技術案はＳ３１０〜Ｓ３４０を含む。
【００４８】
Ｓ３１０において、スケジューラはｐｏｄスケジューリングキューからスケジューリング待ちの現在のｐｏｄを取得し、各物理的なノードにおける前記現在のｐｏｄの優先度以上のｐｏｄを取得し、ノード−ｐｏｄのマッピングテーブルを形成する。
【００４９】
Ｓ３２０において、前記スケジューラはマッピングテーブルから第１段階のスクリーニング条件に合致する物理的なノードをスクリーニングし、ノードグループを形成する。
【００５０】
Ｓ３３０において、マッピングテーブルおよび第２段階のスクリーニング条件に基づき、前記ノードグループの物理的なノードをスコアリングし、スコアが最も高い物理的なノードをターゲット物理的なノードとしてスクリーニングする。
【００５１】
Ｓ３４０において、前記スケジューラは前記現在のｐｏｄと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信する。
【００５２】
これにより、スケジューラは、タスクの優先度および所定のスクリーニング条件に基づいて物理的なノードをスクリーニングし、最適な物理的なノードをスクリーニングし、スケジューリング待ちの現在のタスクを最適な物理的なノードにスケジューリングする。リソースが逼迫している場合、論理的なのリソースプリエンプションのみを行い、リソースを直ちにプリエンプションせず、このようなプリエンプションを遅延させるスケジューリング方法は、論理的に高優先度のタスクにリソースを譲ることができ、リソースが十分に利用されていない場合、プリエンプションされたタスクを保留し続け、リソースの利用率を向上させることができる。
【００５３】
図４は、本発明の実施例に係るタスクプリエンプション方法のフローチャートであり、前記方法は、タスクプリエンプション装置により実行でき、前記装置はソフトウェアおよび／またはハードウェアで実現され、前記装置はコンピュータ装置に集積できる。本発明の実施例に係るタスクプリエンプション方法は、物理的なノードがタスクを処理するシーンに適用される。図４に示すように、本発明の実施例に係る技術案はＳ４１０〜Ｓ４４０を含む。
【００５４】
Ｓ４１０において、物理的なノードが実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得する。
【００５５】
ここで、物理的なノードは、物理マシン等のようなコンピュータ装置であってもよい。物理的なノードは、ＡＰＩサーバにおけるタスクと物理的なノードとのバンディング情報を傍受することにより対応するタスクを取得し、取得したタスクでタスクキューを形成することができる。物理的なノードは、タスクキューにおけるタスクの順序に応じて処理を順に行い、現在の処理のタスクは実行待ちのターゲットタスクと呼ばれる。物理的なノードが実行待ちのターゲットタスクを処理する時、物理的なノードは該物理的なノードで実行しているタスクリストを取得する。ここで、タスクリストには、物理的なノードで実行しているタスクの情報が記載されている。物理的なノードで実行しているタスクは１つであってもよいし、複数であってもよい。
【００５６】
Ｓ４２０において、前記物理的なノードは、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出する。
【００５７】
物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、Ｓ４３０を実行し、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たすと検出した場合、Ｓ４４０を実行する。
【００５８】
本ステップにおいて、ターゲットタスクの実行に必要なリソースは、ＣＰＵ、メモリ等を含んでもよい。物理的なノードの残りのリソースは、物理的なノードにおける使用可能なリソースと理解されてもよい。例えば、物理的なノードにおける残りのＣＰＵの数が１０個でメモリが１Ｇであり、ターゲットタスクの実行に必要なＣＰＵが１０でメモリが２Ｇであると、物理的なノードにおける残りのリソースはターゲットタスクの実行に必要なリソースを満たすことができない。
【００５９】
Ｓ４３０において、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し（該物理的なノードは、削除待ちのキューに移動されるタスクを実行しない）、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションする。
【００６０】
本ステップにおいて、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たすことができると検出した場合、実行環境を直接呼び出し、ターゲットタスクを実行する。物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たすことができないと検出した場合、タスクリストにおけるタスクを優先度の低い順で順番付け、且つ、物理的なノードがタスクリストにおけるタスクを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソースを満たすまで、優先度がターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに移動し、ターゲットタスクを用いて削除待ちのキューにおけるタスクのリソースをプリエンプションし、即ち、削除待ちのキューにおけるタスクの実行を停止する。
【００６１】
タスクリストにおけるタスクを削除待ちのキューに移動する過程において、物理的なノードにおける残りのリソースがターゲットタスクの実行条件を満たさない場合、ターゲットタスクの実行を拒否する。
【００６２】
なお、タスクリストにおける優先度がターゲットタスクの優先度よりも低いタスクを削除待ちのキューに移動する過程において、削除待ちのキューにおけるタスクの実行を停止せず、物理的なノードがタスクリストにおけるタスクを実行した後に得られた残りのリソースがターゲットタスクの実行に必要なリソースを満たすと判断した場合、削除待ちのキュー中のタスクを実行する。
【００６３】
本ステップについて例を挙げて説明し、タスクリストには合計５つのタスク（物理的なノードで実行しているタスクが５つある）があり、それぞれＡ、Ｂ、Ｃ、ＤおよびＥであれば、優先度はそれぞれ１、２、３、４および５であり、ここで、タスクリストにおけるタスクは優先度の低い順で順番付けると、Ａ、Ｂ、Ｃ、ＤおよびＥである。処理待ちのターゲットタスクの優先度は４である。物理的なノードにおける残りのリソースがターゲットタスクの実行に必要なリソース条件を満たすことができない場合、物理的なノードで実行しているタスクリストにおける優先度がターゲットタスクの優先度よりも低いタスク（それぞれＡ、ＢおよびＣ）を優先度の低い順で削除待ちのキューに順に移動し、即ち、まず、Ａを削除待ちのキューに移動し、物理的なノードがタスクリストにおけるＢ、Ｃ、ＤおよびＥを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たすか否かを判断する。物理的なノードがタスクＢ、Ｃ、ＤおよびＥを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たす場合、ターゲットタスクを用いて実行しているＡをプリエンプションし、即ち、Ａを停止する。
【００６４】
Ａを削除待ちのキューに移動した後、物理的なノードがタスクリストにおけるＢ、Ｃ、ＤおよびＥを実行して得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たさない場合、Ｂを削除待ちのキューに移動し続け、タスクリストにおけるタスクＣ、ＤおよびＥを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たすか否かを再び検出し、タスクリストにおけるタスクを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たすと検出したまで上記判断ステップを繰り返す。タスクリストにおけるタスクの優先度がターゲットタスクの優先度以上である場合（即ち、タスクリストにおけるタスクＡ、ＢおよびＣがいずれも移出待ちのキューに移動され、タスクＤおよびＥのみが残っている場合）、物理的なノードがタスクリストにおけるタスクＤおよびＥを実行した後に得られる残りのリソースがターゲットタスクの実行に必要なリソース条件を満たさないと、ターゲットタスクの実行を拒否する。
【００６５】
Ｓ４４０において、前記物理的なノードは実行環境を呼び出し、前記ターゲットタスクを実行する。
【００６６】
本発明の実施例は、物理的なノードが実行待ちのターゲットタスクを処理する時、物理的なノードの残りのリソースがターゲットタスクの実行に必要な条件を満たさないと、低優先度のタスクをプリエンプションし、物理的なノードは重要なタスクを優先的に処理することができ、リソースの利用率を向上させることができる。
【００６７】
上記実施例の基に、前記のタスクプリエンプション方法は、前記物理的なノードが設定時間おきにリソース使用情報を取得することと、前記物理的なノードが、前記リソース使用情報が所定の制限条件に達したことを確定した場合、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に確定されるリソース使用情報が所定の制限条件に達していないまで前記タスクリストにおけるタスクを優先度の低い順で前記削除待ちのキューに移動し、前記削除待ちのキューにおけるタスクを停止する。
【００６８】
好ましくは、タスクリストにおけるタスクは現在の物理的なノードで実行しているタスクである。ここで、各物理的なノードは設定時間おきにリソース使用情報を取得し、リソースの使用情報が所定の制限条件に達したか否かを判断することで、タスクプリエンプションをトリガする必要があるか否かを判断する。リソースの使用情報が所定の制限条件に達すると、タスクプリエンプションをトリガし、リソース使用情報が所定の制限条件に達していないと、タスクプリエンプションをトリガする必要がない。タスクプリエンプションの過程は以下のとおりである。タスクリストにおけるタスクを優先度で順番付け、前記物理的なノードがタスクリストにおけるタスクを実行した後に確定されるリソース使用情報が所定の制限条件に達していないまでタスクリストにおけるタスクを優先度の低い順で削除待ちのキューに順に移動し、削除待ちのキューにおけるタスクを停止する。
【００６９】
ここで、所定の制限条件は、リソース使用が設定値に達することであってもよく、他の制限条件であってもよい。例えば、物理的なノードのリソース使用が設定値に達すると、タスクプリエンプションをトリガする。
【００７０】
これにより、物理的なノードは、リソース使用情報に基づいてタスクプリエンプションをトリガすることで、リソース利用率を向上させることができ、更に、リソースが逼迫している場合、低優先度のタスクからリソースをプリエンプションして重要なタスクを優先的に処理することができる。
【００７１】
図５は、本発明の実施例に係るタスクプリエンプション方法のフローチャートであり、本発明の実施例に係る方法はＫｕｂｅｒｎｅｔｅｓシステムに実行される。図５に示すように、本発明の実施例に係る方法はＳ５１０〜Ｓ５４０を含む。
【００７２】
Ｓ５１０において、物理的なノードがｋｕｂｅｌｅｔにより実行待ちのターゲットｐｏｄを処理する時、前記物理的なノードで実行しているｐｏｄリストを取得する。
【００７３】
ここで、ｋｕｂｅｌｅｔはＫｕｂｅｒｎｅｔｅｓシステムのコンポーネントであり、ｐｏｄ、ｐｏｄのマウントに必要なｖｏｌｕｍｅｓ、ｐｏｄをダウンロードするｓｅｃｒｅｔ、ｄｏｃｋｅｒ／ｒｋｔによりｐｏｄにおけるコンテナーを実行すること、ｐｏｄにおけるコンテナーに定義されたｌｉｖｅｎｅｓｓプローブを周期的に実行すること、ｐｏｄの状態をシステムの他のコンポーネントに報告すること、およびノードの状態を監視することができる。
【００７４】
Ｓ５２０において、前記物理的なノードはｋｕｂｅｌｅｔにより、残りのリソースが前記ターゲットｐｏｄの実行に必要なリソースを満たすか否かを検出する。
【００７５】
物理的なノードが、残りのリソースがターゲットｐｏｄの実行に必要なリソースを満たさないと検出した場合、Ｓ５３０を実行し、物理的なノードが、残りのリソースがターゲットｐｏｄ実行に必要なリソースを満たすと検出した場合、Ｓ５４０を実行する。
【００７６】
Ｓ５３０において、前記物理的なノードはｋｕｂｅｌｅｔにより、前記物理的なノードが前記ｐｏｄリストにおけるｐｏｄを実行した後に得られる残りのリソースが前記ターゲットｐｏｄの実行に必要なリソースを満たすまで、前記ｐｏｄリストにおける優先度が前記ターゲットｐｏｄの優先度よりも低いｐｏｄを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットｐｏｄを用いて前記削除待ちのキューにおけるｐｏｄをプリエンプションする。
【００７７】
Ｓ５４０において、前記物理的なノードはｋｕｂｅｌｅｔにより実行環境を呼び出し、前記ターゲットｐｏｄを実行する。
【００７８】
これにより、物理的なノードが実行待ちのターゲットｐｏｄを処理する時、物理的なノードの残りのリソースがターゲットｐｏｄの実行に必要な条件を満たさないと、低優先度のｐｏｄ（優先度はターゲットｐｏｄの優先度よりも低い）をプリエンプションし、物理的なノードは重要なタスク（本実施例において、該重要タスクとはターゲットｐｏｄを意味する）を優先的に処理してリソースの利用率を向上させることができる。
【００７９】
図６は、本発明の実施例に係るプリエンプティブスケジューリングに基づくリソース共有使用方法のフローチャートであり、前記方法は、プリエンプティブスケジューリングに基づくリソース共有使用システムにより実行され、前記システムは、ソフトウェアおよび／またはハードウェアで実現できる。本発明の実施例に係る方法はクラスタに適用でき、クラスタには複数の物理的なノードが含まれてもよく、各物理的なノードにおけるリソースは複数のテナントの共有リソースであってもよく、複数の物理的なノードはクラスタ管理プラットフォームにより管理されてもよく、タスクを物理的なノードに割り当てて物理的なノードに対応するタスクを実行させる。クラスタ管理プラットフォームは複数のコンピュータ装置に集積でき、複数のコンピュータ装置はユーザが操作でき、ユーザはクラスタ管理プラットフォームに登録してタスクの作成要求を提出することができ、クラスタ管理プラットフォームにおけるＡＰＩサーバはユーザにより提出されたタスクの作成要求を取得してタスクを作成し、クラスタ管理プラットフォームにおけるスケジューラはタスクスケジューリングを行い、タスクを対応する物理的なノードに合理的に割り当て、物理的なノードが該タスクを実行する。
【００８０】
図６に示すように、本発明の実施例に係る技術案はＳ６１０〜Ｓ６９２を含む。
【００８１】
Ｓ６１０において、ＡＰＩサーバはタスクの作成要求を取得する。
【００８２】
Ｓ６２０において、前記ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成する。
【００８３】
Ｓ６３０において、スケジューラは前記ＡＰＩサーバにより作成されたタスクを取得し、タスクスケジューリングキューを形成する。
【００８４】
ＡＰＩサーバはタスクの作成要求をリアルタイムに取得し、条件を満たした作成要求のためにタスクを作成する。そのため、ＡＰＩサーバには少なくとも１つのタスクがある。スケジューラはＡＰＩサーバが作成する全てのタスクを取得し、これらのタスクをタスクスケジューリングキューに形成する。
【００８５】
Ｓ６４０において、前記スケジューラは前記タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成する。
【００８６】
スケジューラは、タスクスケジューリングキューにおけるタスクの並び順に基づき、タスクを順にスケジューリングする。スケジューリング待ちの現在のタスクとは、タスクスケジューリングキューにおけるスケジューラが現在スケジューリングしているタスクを意味する。
【００８７】
Ｓ６５０において、前記スケジューラは前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定する。
【００８８】
Ｓ６６０において、前記スケジューラは前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信する。
【００８９】
スケジューラは、タスクスケジューリングキューにおけるタスクをスケジューリングし、タスクスケジューリングキューにおける各タスクとそれに対応するターゲット物理的なノードとのバンディング情報を取得する。
【００９０】
Ｓ６７０において、物理的なノードは前記ＡＰＩサーバにおけるタスクと物理的なノードとのバンディング情報を傍受することにより、対応するタスクを取得し、タスクキューを形成する。
【００９１】
物理的なノードは、ＡＰＩサーバにおけるバンディング情報を傍受し、バンディング情報におけるターゲット物理的なノードにより、該物理的なノードに対応するタスクを確定する。該タスクは１つであってもよいし、複数であってもよく、これらのタスクをタスクキューに形成する。
【００９２】
Ｓ６８０において、前記物理的なノードが前記タスクキューにおける実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得する。
【００９３】
物理的なノードは、タスクキューにおけるタスクの並び順に基づき、タスクを順に処理する。実行待ちのターゲットタスクとは、タスクキューにおける物理的なノードが現在処理しているタスクを意味する。
【００９４】
Ｓ６９０において、前記物理的なノードは、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出する。
【００９５】
物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、Ｓ６９１を実行し、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たすと検出した場合、Ｓ６９２を実行する。
【００９６】
Ｓ６９１において、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行して得る残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクよりも低いタスクを、優先度の低い順で削除待ちのキューに移動し、ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションする。
【００９７】
Ｓ６９２において、前記物理的なノードは実行環境を呼び出し、前記ターゲットタスクを実行する。
【００９８】
関連技術のＫｕｂｅｒｎｅｔｅｓ  １．３バージョンは、サービス品質（Ｑｕａｌｉｔｙ  Ｏｆ  Ｓｅｒｖｉｃｅ）のリソース共有形態に基づき、共有リソースを管理するために使用され、サービス品質は高い順でそれぞれＧｕａｒａｎｔｅｅ、ＢｕｒｓｔａｂｌｅおよびＢｅｓｔ  Ｅｆｆｏｒｔである。ここで、Ｂｅｓｔ  Ｅｆｆｏｒｔのタスクは、クラスタリソースが十分に使用されていない場合にスケジューリングされて実行できる。クラスタリソースが逼迫している場合、Ｂｅｓｔ  Ｅｆｆｏｒｔのタスクは優先的にプリエンプションされる。このような形態は、タスクスケジューリングの一環を考慮したことがなく、クラスタのスケジューリングが満了した場合、高いサービス品質のタスクにリソースを譲ることができず、且つテナント内のＢｅｓｔ  Ｅｆｆｏｒｔタスクの数を制限することができず、Ｂｅｓｔ  Ｅｆｆｏｒｔタスクのプリエンプションされる順を区別することができない。
【００９９】
関連技術のＫｕｂｅｒｎｅｔｅｓ  １．８バージョンに導入された優先度に基づくスケジューリング形態は、タスクの優先度を設定することができ、リソースが逼迫している場合、スケジューラは低優先度のタスクをプリエンプションし、高優先度のタスクに十分なリソースを提供する。しかし、該形態において、タスクのプリエンプションはスケジューラで発生し、即ち、クラスタロジックのスケジューリングが満了した時に発生し、クラスタにはリソースが十分に利用されていない場合があり、リソースの利用率は高くなく、且つ各優先度のタスクの数を正確に制限することができない。
【０１００】
関連技術におけるスケジューリング形態に対し、本発明の実施例に係る方法は、テナントのリソース割り前に対して優先度を設定し、各テナントにおける複数種の優先度のタスクの数を正確に制限することができ、タスクの優先度の設定により、タスクがプリエンプションされる時、タスクのプリエンプションされる順を区別することができる。本発明の実施例において、優先度に基づくタスクプリエンプションは物理的なノードで発生し、スケジューラで発生することがなく、論理的には高優先度のタスクにリソースを譲ることができ、リソースが十分に利用されていない場合、プリエンプションされたタスクを実行し続け、リソースの利用率を向上させることができる。
【０１０１】
本発明の実施例に係る方法は、テナントのリソース割り前に対して優先度を設定し、タスクの優先度と対応するテナントにおける複数の優先度のリソースとをマッチングすることにより、タスクを作成するか否かを確定し、テナントにリソースが逼迫している場合にリソースを優先的に使用させ、テナントが高優先度のリソースを悪用して低優先度のタスクがリソースを持続的に取得できなくて「餓死」という現象が現れることを防止することができる。スケジューラは、タスクの優先度および所定のスクリーニング条件に基づいて物理的なノードをスクリーニングし、最適な物理的なノードをスクリーニングし、スケジューリング待ちの現在のタスクを最適な物理的なノードにスケジューリングし、リソースが逼迫している場合、論理的なのリソースプリエンプションのみを行い、リソースを直ちにプリエンプションせず、このようなプリエンプションを遅延させるスケジューリング方法は、論理的に高優先度のタスクにリソースを譲ることができ、リソースが十分に利用されていない場合、プリエンプションされたタスクを実行し続け、リソースの利用率を向上させることができる。物理的なノードが実行待ちのターゲットタスクを処理する時、物理的なノードの残りのリソースがターゲットタスクの実行に必要な条件を満たさないと、低優先度のタスクをプリエンプションすることに基づき、物理的なノードは重要なタスクを優先的に処理し、リソースの利用率を向上させることができる。
【０１０２】
図７は、本発明の実施例に係るＡＰＩサーバの構造ブロック図であり、図７に示すように、前記ＡＰＩサーバは、要求取得モジュール７１０と、タスク作成モジュール７２０とを備える。
【０１０３】
要求取得モジュール７１０は、タスクの作成要求を取得するように構成される。
【０１０４】
タスク作成モジュール７２０は、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成するように構成される。
【０１０５】
好ましくは、前記装置はＫｕｂｅｒｎｅｔｅｓシステムに適用され、要求取得モジュール７１０は、ｐｏｄの作成要求を取得するように構成される。
【０１０６】
タスク作成モジュール７２０は、前記ｐｏｄに対応するｎａｍｅｓｐａｃｅのｑｕｏｔａに前記ｐｏｄの優先度とマッチングするリソースｑｕｏｔａ値が含まれ、且つｑｕｏｔａ値が前記ｐｏｄの作成条件を満たすと検出した場合、前記作成要求に応じてｐｏｄを作成するように構成される。
【０１０７】
上記タスク作成装置は、本発明のいずれかの実施例に係るタスク作成方法を実行でき、タスク作成方法の実行に対応する機能モジュールおよび有益な効果を有する。
【０１０８】
図８ａは、本発明の実施例に係るスケジューラの構造ブロック図であり、図８ａに示すように、前記スケジューラは、マッピングテーブル形成モジュール８１０と、スクリーニングモジュール８２０と、バンディングモジュール８３０とを備える。
【０１０９】
マッピングテーブル形成モジュール８１０は、タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成するように構成される。
【０１１０】
スクリーニングモジュール８２０は、前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定するように構成される。
【０１１１】
バンディングモジュール８３０は、前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信するように構成される。
【０１１２】
好ましくは、スクリーニングモジュール８２０は、
前記マッピングテーブルから第１段階のスクリーニング条件に合致する物理的なノードをスクリーニングし、ノードグループを形成し、
前記マッピングテーブルおよび第２段階のスクリーニング条件に基づき、前記ノードグループの物理的なノードをスコアリングし、スコアが最も高い物理的なノードをターゲット物理的なノードとしてスクリーニングするように構成される。
【０１１３】
好ましくは、前記装置はＫｕｂｅｒｎｅｔｅｓシステムに適用され、マッピングテーブル形成モジュール８１０は、ｐｏｄスケジューリングキューからスケジューリング待ちの現在のｐｏｄを取得し、各物理的なノードにおける前記現在のｐｏｄの指定優先度以上のｐｏｄを取得し、ノード−ｐｏｄのマッピングテーブルを形成するように構成される。
【０１１４】
それに対応し、バンディングモジュール８３０は、前記現在のｐｏｄと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信するように構成される。
【０１１５】
ここで、スケジューラ構造は他の構造形式であってもよく、タスクスケジューリング方法を実行できればよい。例えば、スケジューラにはスケジューリングシステムが含まれ、図８ｂに示すように、スケジューリングシステムは、ノード情報リスト８４０と、スクリーニングアルゴリズムライブラリ８５０と、スクリーニングアルゴリズムライブラリ８６０と、スケジューリングされていないキュー８７０という４つの部分を含んでもよい。
【０１１６】
ここで、ノード情報リスト８４０は、物理的なノードにおけるリソース情報（全てのリソースおよび使用可能なリソース）および物理的なノードで実行しているタスクキューを含む現在の使用可能な物理的なノード情報を記載するように構成される。この部分の情報はスケジューリング方法を指定する際にキーとなる情報であり、スケジューリングシステムがリソースおよびタスクを全面的に認知することを確保するために、リアルタイムかつ同期する必要がある。
【０１１７】
スクリーニングアルゴリズムライブラリ８５０は、複数種の物理的なノードをスクリーニングするアルゴリズムを予め定義し、タスク実行条件を満たさない物理的なノードを除去することを確保するように構成される。
【０１１８】
スクリーニングアルゴリズムライブラリ８６０は、複数種のスクリーニングノードのアルゴリズムおよびアルゴリズムの重みを予め定義するように構成され、スクリーニングアルゴリズムで計算されたスコアが最も高い物理的なノードは、スケジューリングノード、即ち、ターゲット物理的なノードとして選択される。
【０１１９】
スケジューリングキュー８７０は、スケジューリングされていないタスクで形成されたキューとして構成され、高優先度のタスクが先にスケジューリングされることを確保するための１つの優先度キューである。
【０１２０】
上記装置は、本発明のいずれかの実施例に係るタスクスケジューリング方法を実行することができ、タスクスケジューリング方法の実行に対応する機能モジュールおよび有益な効果を備える。
【０１２１】
図９は、本発明の実施例に係るタスクプリエンプション装置の構造ブロック図であり、図９に示すように、前記タスクプリエンプション装置は、タスクリスト取得モジュール９１０と、検出モジュール９２０と、プリエンプションモジュール９３０と、タスク実行モジュール９４０とを備える。
【０１２２】
ここで、タスクリスト取得モジュール９１０は、実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得するように構成される。
【０１２３】
検出モジュール９２０は、物理的なノードにおける残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出するように構成される。
【０１２４】
プリエンプションモジュール９３０は、物理的なノードにおける残りのリソースがターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクよりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し（即ち、優先度の低い順でタスクをタスクリストから順に移出する）、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションするように構成される。
【０１２５】
タスク実行モジュール９４０は、前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行するように構成される。
【０１２６】
好ましくは、前記プリエンプションモジュールは、更に、設定時間おきにリソース使用情報を取得するように構成されてもよい。
【０１２７】
前記リソース使用情報が所定の制限条件に達したことを確定すると、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に確定されるリソース使用情報が所定の制限条件に達していないまで前記タスクリストにおけるタスクを優先度の低い順で前記削除待ちのキューに順に移動し、前記削除待ちのキューにおけるタスクを停止する。
【０１２８】
好ましくは、前記装置はＫｕｂｅｒｎｅｔｅｓシステムに適用され、前記ターゲットタスクはターゲットｐｏｄであり、前記タスクリストはｐｏｄリストであり、前記タスクリストにおけるタスクは前記物理的なノードで実行しているｐｏｄである。
【０１２９】
上記装置は、本発明のいずれかの実施例に係るタスクプリエンプション方法を実行でき、タスクプリエンプション方法の実行に対応する機能モジュールおよび有益な効果を備える。
【０１３０】
図１０は、本発明の実施例に係るタスクプリエンプションシステムの構造模式図であり、図１０に示すように、前記タスクプリエンプションシステムは、上記実施例に係るＡＰＩサーバ１０１０と、上記実施例に係るスケジューラ１０２０と、上記実施例に係るタスクプリエンプション装置１０３０とを備える。
【０１３１】
好ましくは、ＡＰＩサーバ１０１０およびスケジューラ１０２０はそれぞれクラスタ管理プラットフォームのコンポーネントであり、クラスタ管理プラットフォームはユーザが使用するコンピュータ装置に集積される。タスクプリエンプション装置１０３０は物理的なノードにおける物理マシンに集積されてもよい。
【０１３２】
図１１は、本発明の実施例に係る装置の構造模式図であり、図１１に示すように、該装置は、１つまたは複数のプロセッサ１１１０（図１１では１つのプロセッサ１１１０を例とする）と、メモリ１１２０とを備える。
【０１３３】
前記装置は、入力装置１１３０と、出力装置１１４０とを更に備えてもよい。
【０１３４】
前記装置におけるプロセッサ１１１０、メモリ１１２０、入力装置１１３０および出力装置１１４０は、バスまたは他の方式により接続でき、図１１ではバスによる接続を例とする。
【０１３５】
メモリ１１２０は、非一時的コンピュータ可読記憶媒体として、本発明の実施例におけるタスク作成方法に対応するプログラム命令／モジュール（例えば、図面７に示す要求取得モジュール７１０およびタスク作成モジュール７２０）、または本発明の実施例におけるタスクスケジューリング方法に対応するプログラム命令／モジュール（例えば、図面８に示すマッピングテーブル形成モジュール８１０、スクリーニングモジュール８２０およびバンディングモジュール８３０）、または本発明の実施例におけるタスクプリエンプション方法に対応するプログラム命令／モジュール（例えば、図面９に示すタスクリスト取得モジュール９１０、検出モジュール９２０、プリエンプションモジュール９３０およびタスク実行モジュール９４０）のようなソフトウェアプログラム、コンピュータ実行可能プログラムおよびモジュールを記憶するために使用できる。プロセッサ１１１０は、メモリ１１２０に記憶されたソフトウェアプログラム、命令およびモジュールを実行することにより、コンピュータ装置の様々な機能アプリケーションおよびデータ処理を実行し、即ち、ＡＰＩサーバがタスクの作成要求を取得することと、ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することとを含む上記方法実施例のタスク作成方法を実現する。
【０１３６】
または、プロセッサ１１１０は、メモリ１１２０に記憶されたソフトウェアプログラム、命令およびモジュールを実行することにより、スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定することと、前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することとを含む上記方法の実施例のタスクスケジューリング方法を実現する。
【０１３７】
または、プロセッサ１１１０は、メモリ１１２０に記憶されたソフトウェアプログラム、命令およびモジュールを実行することにより、物理的なノードが実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、前記物理的なノードが、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することとを含む上記方法の実施例のタスクプリエンプション方法を実現する。
【０１３８】
メモリ１１２０は、プログラム記憶エリアおよびデータ記憶エリアを含んでもよく、ここで、プログラム記憶エリアはオペレーティングシステム、少なくとも１つの機能に必要なアプリケーションプログラムを記憶することができ、データ記憶エリアは、コンピュータ装置の使用に基づいて作成されたデータ等を記憶することができる。また、メモリ１１２０は高速ランダムアクセスメモリを含んでもよく、少なくとも１つの磁気ディスク記憶装置、フラッシュメモリ装置、または他の非一時的固体記憶装置のような非一時的メモリを更に含んでもよい。好ましくは、いくつかの実施例において、メモリ１１２０は、プロセッサ１１１０に対して遠隔に設けられたメモリを含んでもよく、これらのリモートメモリは、ネットワークを介して端末装置に接続することができる。上記ネットワークのインスタンスは、インターネット、イントラネット、ローカルエリアネットワーク、移動体通信ネットワークおよびその組み合わせを含むが、これらに限定されない。
【０１３９】
入力装置１１３０は、入力された数字または文字情報を受信し、およびコンピュータ装置のユーザ設定および機能制御に関連するキー信号入力を生じるために使用できる。出力装置１１４０はディスプレイ等の表示装置を含んでもよい。
【０１４０】
本発明の実施例は、コンピュータプログラムが記憶されているコンピュータ可読記憶媒体を提供し、該プログラムがプロセッサにより実行されると、タスクの作成要求を取得することと、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出し場合、前記作成要求に応じて前記タスクを作成することとを含む本発明の実施例に係るタスク作成方法を実現する。
【０１４１】
または、該プログラムがプロセッサにより実行されると、スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定することと、前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することとを含む上記方法の実施例のタスクスケジューリング方法を実現する。
【０１４２】
または、該プログラムがプロセッサにより実行されと、物理的なノードが実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、前記物理的なノードが、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することとを含む上記方法実施例のタスクプリエンプション方法を実現する。
【０１４３】
１つまたは複数のコンピュータ可読信号媒体の任意の組み合わせを採用してもよい。コンピュータ可読信号媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体であってもよい。コンピュータ可読記憶媒体は、例えば、電気、磁気、光、電磁、赤外線、または半導体のシステム、装置もしくは装置、または以上の任意の組み合わせであってもよいが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例（非網羅的なリスト）は、１つまたは複数の導線を有する電気的接続、携帯型コンピュータ磁気ディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラマブル読み出し専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、光ファイバ、携帯型コンパクト磁気ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、または上記任意の適当な組み合わせを含む。本明細書において、コンピュータ可読記憶媒体は、プログラムを含むまたは記憶する任意の有形媒体であってもよく、該プログラムは、命令実行システム、装置または装置により使用されてもよく、それと合わせて使用されてもよい。
【０１４４】
コンピュータ可読信号媒体は、ベースバンドでまたはキャリアの一部として伝播するデータ信号を含んでもよく、その中にコンピュータ可読プログラムコードが担持されている。このような伝播するデータ信号は様々な形式を採用することができ、電磁信号、光信号または上記任意の適当な組み合わせを含むが、これらに限定されない。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体以外の任意のコンピュータ可読信号媒体であってもよく、該コンピュータ可読信号媒体は、命令実行システム、装置または装置に使用されるまたはそれと合わせて使用されるプログラムを送信、伝播または伝送することができる。
【０１４５】
コンピュータ可読信号媒体に含まれるプログラムコードは、任意の適当な媒体で伝送でき、無線、電線、光ケーブル、ＲＦ等、または上記任意の適当な組み合わせを含むが、これらに限定されない。
【０１４６】
本発明の操作を実行するためのコンピュータプログラムコードは、１種または複数種のプログラミング言語またはその組み合わせでプログラミングすることができ、前記プログラミング言語は、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋のようなオブジェクト指向プログラミング言語を含み、「Ｃ」言語または類似するプログラミング言語のような通常の手続き型プログラミング言語を更に含む。プログラムコードは、完全にユーザコンピュータで実行されてもよく、一部がユーザコンピュータで実行されてもよく、１つの独立したソフトウェアパッケージとして実行されてもよく、一部がユーザコンピュータで一部がリモートコンピュータで実行されてもよく、または完全にリモートコンピュータまたはサーバで実行されてもよい。リモートコンピュータに関する場合に、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意種のネットワークを介してユーザコンピュータに接続でき、または、外部のコンピュータ（例えば、インターネットサービスを提供するプロバイダを利用してインターネットを介して接続される）に接続できる。
【国際調査報告】
2021522621.tif 000015
2021522621.tif 000016
2021522621.tif 000017
2021522621.tif 000018
2021522621.tif 000019