JP2021522621A - タスクスケジューリング方法、プリエンプティブスケジューリングに基づくリソース共有使用方法およびシステム、スケジューラ、装置、ならびにコンピュータ可読記憶媒体 - Google Patents

タスクスケジューリング方法、プリエンプティブスケジューリングに基づくリソース共有使用方法およびシステム、スケジューラ、装置、ならびにコンピュータ可読記憶媒体 Download PDF

Info

Publication number
JP2021522621A
JP2021522621A JP2020573022A JP2020573022A JP2021522621A JP 2021522621 A JP2021522621 A JP 2021522621A JP 2020573022 A JP2020573022 A JP 2020573022A JP 2020573022 A JP2020573022 A JP 2020573022A JP 2021522621 A JP2021522621 A JP 2021522621A
Authority
JP
Japan
Prior art keywords
task
physical node
target
priority
resources
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2020573022A
Other languages
English (en)
Other versions
JP7060724B2 (ja
Inventor
宏健 ▲孫▼
宏健 ▲孫▼
Original Assignee
星▲環▼信息科技（上▲海▼）股▲ふん▼有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 星▲環▼信息科技（上▲海▼）股▲ふん▼有限公司 filed Critical 星▲環▼信息科技（上▲海▼）股▲ふん▼有限公司
Publication of JP2021522621A publication Critical patent/JP2021522621A/ja
Application granted granted Critical
Publication of JP7060724B2 publication Critical patent/JP7060724B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/504—Resource capping
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本発明の実施例は、プリエンプティブスケジューリングに基づくリソース共有使用方法、システムおよび装置を開示し、該方法は、ＡＰＩサーバがタスクを作成することと、スケジューラが現在のタスクを処理する時、優先度に基づいて所定のスクリーニング条件に最も合致するターゲット物理的なノードをスクリーニングし、現在のタスクおよびターゲット物理的なノードバンディング情報をＡＰＩサーバに送信することと、物理的なノードがタスクキューにおける実行待ちのターゲットタスクを処理する時、物理的なノードで実行しているタスクリストを取得することと、物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、物理的なノードがタスクリストにおけるタスクを実行して得られる残りのリソースがターゲットタスクの実行に必要なリソースを満たすまで、タスクリストにおける優先度がターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに移動し、削除待ちのキューにおけるタスクをプリエンプションすることとを含む。
【選択図】図６

Description

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

Claims (15)

  1. アプリケーションプログラミングインタフェースＡＰＩサーバがタスクの作成要求を取得することと、
    ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することと、
    を含む、タスク作成方法。
  2. 前記ＡＰＩサーバがタスクの作成要求を取得することは、
    ＡＰＩサーバがｐｏｄの作成要求を取得することを含み、
    ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することは、
    前記ＡＰＩサーバが、前記ｐｏｄに対応するｎａｍｅｓｐａｃｅのｑｕｏｔａに前記ｐｏｄに対応する優先度とマッチングするリソースのｑｕｏｔａ値が含まれ、且つ前記ｑｕｏｔａ値が前記ｐｏｄの作成条件を満たすと検出した場合、前記作成要求に応じてｐｏｄを作成することを含む、請求項１に記載の方法。
  3. スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、
    前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定することと、
    前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することと、
    を含む、タスクスケジューリング方法。
  4. 前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定することは、
    前記スケジューラが前記マッピングテーブルから第１段階のスクリーニング条件に合致する物理的なノードをスクリーニングし、ノードグループを形成することと、
    前記マッピングテーブルおよび第２段階の好適な条件に基づき、前記ノードグループの物理的なノードをスコアリングし、スコアが最も高い物理的なノードをスクリーニングしてターゲット物理的なノードとすることと、
    を含む、請求項３に記載の方法。
  5. 前記スケジューラがタスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの指定優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することは、
    前記スケジューラがｐｏｄスケジューリングキューからスケジューリング待ちの現在のｐｏｄを取得し、各物理的なノードにおける前記現在のｐｏｄの優先度以上のｐｏｄを取得し、ノード−ｐｏｄのマッピングテーブルを形成することを含み、
    前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することは、
    前記スケジューラが前記現在のｐｏｄと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信することを含む、請求項３または請求項４に記載の方法。
  6. 物理的なノードが実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、
    前記物理的なノードが、残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、
    物理的なノードが、残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、前記物理的なノードは、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクの優先度よりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、
    前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することと、
    を含む、タスクプリエンプション方法。
  7. 前記物理的なノードは、設定時間おきにリソース使用情報を取得することと、
    前記物理的なノードは、前記リソース使用情報が所定の制限条件に達したことを確定した場合、前記物理的なノードが前記タスクリストにおけるタスクを実行する時に確定するリソース使用情報が所定の制限条件に達していないまで前記タスクリストにおけるタスクを優先度の低い順で前記削除待ちのキューに順に移動し、前記削除待ちのキューにおけるタスクを停止することと、
    を更に含む、請求項６に記載の方法。
  8. 前記ターゲットタスクはターゲットｐｏｄであり、前記タスクリストはｐｏｄリストであり、前記タスクリストにおけるタスクは前記物理的なノードで実行しているｐｏｄである、請求項６または請求項７に記載の方法。
  9. アプリケーションプログラミングインタフェースＡＰＩサーバがタスクの作成要求を取得することと、
    前記ＡＰＩサーバが、前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成することと、
    スケジューラが前記ＡＰＩサーバにより作成されたタスクを取得し、タスクスケジューリングキューを形成することと、
    前記スケジューラが前記タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの指定優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成することと、
    前記スケジューラが前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に最も合致するターゲット物理的なノードを確定することと、
    前記スケジューラが前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングした情報をＡＰＩサーバに送信することと、
    物理的なノードが前記ＡＰＩサーバにおけるタスクと物理的なノードとのバンディング情報を傍受し、傍受した前記バンディング情報に基づいて対応するタスクを取得し、タスクキューを形成することと、
    前記物理的なノードが前記タスクキューにおける実行待ちのターゲットタスクを処理する時、前記物理的なノードで実行しているタスクリストを取得することと、
    前記物理的なノードは、前記タスクリストにおけるタスクを実行した後の残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出することと、
    ターゲットタスクの実行に必要なリソースを満たさない場合、前記物理的なノードは、前記物理的なノードの残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおける優先度が前記ターゲットタスクよりも低いタスクを、優先度の低い順で削除待ちのキューに順に移動し、ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションすることと、
    前記物理的なノードが実行環境を呼び出し、前記ターゲットタスクを実行することと、
    を含む、プリエンプティブスケジューリングに基づくリソース共有使用方法。
  10. タスクの作成要求を取得するように構成される要求取得モジュールと、
    前記タスクに対応するテナントの割り前に前記タスクの優先度とマッチングするリソースが含まれ、且つマッチングリソースが前記タスクの作成条件を満たすと検出した場合、前記作成要求に応じて前記タスクを作成するように構成されるタスク作成モジュールと、
    を備える、ＡＰＩサーバ。
  11. タスクスケジューリングキューからスケジューリング待ちの現在のタスクを取得し、各物理的なノードにおける前記現在のタスクの優先度以上のタスクを取得し、ノード−タスクのマッピングテーブルを形成するよう構成されるマッピングテーブル形成モジュールと、
    前記マッピングテーブルおよび所定のスクリーニング条件に基づいて前記所定のスクリーニング条件に合致するターゲット物理的なノードを確定するように構成されるスクリーニングモジュールと、
    前記現在のタスクと前記ターゲット物理的なノードとをバンディングし、バンディングの情報をＡＰＩサーバに送信するように構成されるバンディングモジュールと、
    を備える、スケジューラ。
  12. 実行待ちのターゲットタスクを処理する時、物理的なノードで実行しているタスクリストを取得するように構成されるタスクリスト取得モジュールと、
    物理的なノードにおける残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすか否かを検出するように構成される検出モジュールと、
    検出モジュールが、物理的なノードにおける残りのリソースがターゲットタスクの実行に必要なリソースを満たさないと検出した場合、前記物理的なノードが前記タスクリストにおけるタスクを実行した後に得られる残りのリソースが前記ターゲットタスクの実行に必要なリソースを満たすまで、前記タスクリストにおけるタスクを、優先度の低い順で削除待ちのキューに順に移動し、且つ前記削除待ちのキューにおけるタスクの優先度が前記ターゲットタスクの優先度よりも小さく、前記ターゲットタスクを用いて前記削除待ちのキューにおけるタスクをプリエンプションするように構成されるプリエンプションモジュールと、
    実行環境を呼び出し、前記ターゲットタスクを実行するように構成されるタスク実行モジュールと、
    を備える、タスクプリエンプション装置。
  13. 請求項１０に記載のＡＰＩサーバと、請求項１１に記載のスケジューラと、請求項１２に記載のタスクプリエンプション装置とを備える、プリエンプティブスケジューリングに基づくリソース共有使用システム。
  14. １つまたは複数のプロセッサと、
    １つまたは複数のプログラムを記憶するための記憶装置と、
    を備え、
    前記１つまたは複数のプログラムが前記１つまたは複数のプロセッサにより実行されると、前記１つまたは複数のプロセッサは、請求項１または２に記載のタスク作成方法、または請求項３〜５のいずれか１項に記載のタスクスケジューリング方法、または請求項６〜８のいずれか１項に記載のタスクプリエンプション方法を実現する、装置。
  15. プロセッサにより実行されると、請求項１または２に記載のタスク作成方法、または請求項３〜５のいずれか１項に記載のタスクスケジューリング方法、または請求項６〜８のいずれか１項に記載のタスクプリエンプション方法を実現するコンピュータプログラムが記憶されている、コンピュータ可読記憶媒体。
JP2020573022A 2018-06-25 2018-12-25 タスクスケジューリング方法、リソース共有使用方法、スケジューラ、コンピュータ可読記憶媒体および装置 Active JP7060724B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201810659298.5A CN108769254B (zh) 2018-06-25 2018-06-25 基于抢占式调度的资源共享使用方法、系统及设备
CN201810659298.5 2018-06-25
PCT/CN2018/123464 WO2020000944A1 (zh) 2018-06-25 2018-12-25 基于抢占式调度的资源共享使用方法、系统及设备

Publications (2)

Publication Number Publication Date
JP2021522621A true JP2021522621A (ja) 2021-08-30
JP7060724B2 JP7060724B2 (ja) 2022-04-26

Family

ID=63977138

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020573022A Active JP7060724B2 (ja) 2018-06-25 2018-12-25 タスクスケジューリング方法、リソース共有使用方法、スケジューラ、コンピュータ可読記憶媒体および装置

Country Status (6)

Country Link
EP (1) EP3799390A4 (ja)
JP (1) JP7060724B2 (ja)
CN (1) CN108769254B (ja)
CA (1) CA3104806C (ja)
SG (1) SG11202013049XA (ja)
WO (1) WO2020000944A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022023769A (ja) * 2020-07-20 2022-02-08 ベイジン バイドゥ ネットコム サイエンス テクノロジー カンパニー リミテッド サーバリソースを割り当てるための方法、装置、電子デバイス、コンピュータ可読記憶媒体及びコンピュータプログラム

Families Citing this family (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108769254B (zh) * 2018-06-25 2019-09-20 星环信息科技（上海）有限公司 基于抢占式调度的资源共享使用方法、系统及设备
CN109656716B (zh) * 2018-12-13 2020-12-01 苏州浪潮智能科技有限公司 一种Slurm作业调度方法及系统
CN111381956B (zh) * 2018-12-28 2024-02-27 杭州海康威视数字技术股份有限公司 一种任务处理的方法、装置及云分析系统
CN109960585B (zh) * 2019-02-02 2021-05-14 浙江工业大学 一种基于kubernetes的资源调度方法
CN109933420A (zh) * 2019-04-02 2019-06-25 深圳市网心科技有限公司 节点任务调度方法、电子设备及系统
CN111800446B (zh) * 2019-04-12 2023-11-07 北京沃东天骏信息技术有限公司 调度处理方法、装置、设备和存储介质
CN112114958A (zh) * 2019-06-21 2020-12-22 上海哔哩哔哩科技有限公司 资源隔离方法、分布式平台、计算机设备和存储介质
CN112214288B (zh) * 2019-07-10 2023-04-25 中国移动通信集团上海有限公司 基于Kubernetes集群的Pod调度方法、装置、设备和介质
CN110362407A (zh) * 2019-07-19 2019-10-22 中国工商银行股份有限公司 计算资源调度方法及装置
CN110457135A (zh) * 2019-08-09 2019-11-15 重庆紫光华山智安科技有限公司 一种资源调度方法、装置及共享gpu显存的方法
CN110515730A (zh) * 2019-08-22 2019-11-29 北京宝兰德软件股份有限公司 基于kubernetes容器编排系统的资源二次调度方法及装置
CN110515704B (zh) * 2019-08-30 2023-08-04 广东浪潮大数据研究有限公司 基于Kubernetes系统的资源调度方法及装置
CN110737572B (zh) * 2019-08-31 2023-01-10 苏州浪潮智能科技有限公司 大数据平台资源抢占测试方法、系统、终端及存储介质
CN110532082A (zh) * 2019-09-04 2019-12-03 厦门商集网络科技有限责任公司 一种基于任务预分配的任务申请装置和方法
CN110727512B (zh) * 2019-09-30 2020-06-26 星环信息科技（上海）有限公司 集群资源调度方法、装置、设备及储存介质
CN110716809B (zh) * 2019-10-21 2022-06-21 北京百度网讯科技有限公司 用于调度云资源的方法和装置
CN110851236A (zh) * 2019-11-11 2020-02-28 星环信息科技（上海）有限公司 一种实时资源调度方法、装置、计算机设备及存储介质
CN110990154B (zh) * 2019-11-28 2024-02-23 曙光信息产业股份有限公司 一种大数据应用优化方法、装置及存储介质
CN111736965A (zh) * 2019-12-11 2020-10-02 西安宇视信息科技有限公司 任务调度方法、装置、调度服务器和机器可读存储介质
CN113051064A (zh) * 2019-12-26 2021-06-29 中移(上海)信息通信科技有限公司 任务调度方法、装置、设备及存储介质
CN113127178B (zh) * 2019-12-30 2024-03-29 医渡云（北京）技术有限公司 资源抢占方法及装置、计算机可读存储介质、电子设备
CN111831390B (zh) * 2020-01-08 2024-04-16 北京嘀嘀无限科技发展有限公司 服务器的资源管理方法、装置及服务器
CN111488206A (zh) * 2020-03-08 2020-08-04 苏州浪潮智能科技有限公司 一种深度学习任务调度方法、系统、终端及存储介质
CN111459666A (zh) * 2020-03-26 2020-07-28 北京金山云网络技术有限公司 任务派发方法、装置、任务执行系统和服务器
CN111506404A (zh) * 2020-04-07 2020-08-07 上海德拓信息技术股份有限公司 一种基于Kubernetes的共享GPU调度方法
CN111399989B (zh) * 2020-04-10 2022-11-18 中国人民解放军国防科技大学 一种面向容器云的任务抢占调度方法及系统
CN111464659A (zh) * 2020-04-27 2020-07-28 广州虎牙科技有限公司 节点的调度、节点的预选处理方法、装置、设备及介质
CN111641678A (zh) * 2020-04-29 2020-09-08 深圳壹账通智能科技有限公司 任务调度方法、装置、电子设备及介质
CN113742036B (zh) * 2020-05-28 2024-01-30 阿里巴巴集团控股有限公司 指标处理方法、装置及电子设备
CN111694646B (zh) * 2020-05-29 2023-11-07 北京百度网讯科技有限公司 资源调度方法、装置、电子设备及计算机可读存储介质
CN111796933B (zh) * 2020-06-28 2023-11-21 北京小米松果电子有限公司 资源调度方法、装置、存储介质和电子设备
CN113301087B (zh) * 2020-07-21 2024-04-02 阿里巴巴集团控股有限公司 资源调度方法、装置、计算设备和介质
CN112015549B (zh) * 2020-08-07 2023-01-06 苏州浪潮智能科技有限公司 一种基于服务器集群的调度节点的选择抢占方法及系统
CN112181645A (zh) * 2020-09-21 2021-01-05 中国建设银行股份有限公司 一种资源调度的方法、装置、设备及存储介质
CN112181517A (zh) * 2020-09-24 2021-01-05 北京达佳互联信息技术有限公司 一种应用软件的启动方法、装置、设备和介质
CN112035220A (zh) * 2020-09-30 2020-12-04 北京百度网讯科技有限公司 开发机操作任务的处理方法、装置、设备以及存储介质
CN114513547B (zh) * 2020-10-29 2024-02-13 浙江宇视科技有限公司 模块的节点调度方法、装置、电子设备及存储介质
CN112162865B (zh) * 2020-11-03 2023-09-01 中国工商银行股份有限公司 服务器的调度方法、装置和服务器
CN112445591A (zh) * 2020-11-03 2021-03-05 北京电子工程总体研究所 一种面向复杂任务集的任务调度系统及方法
CN112328403A (zh) * 2020-11-25 2021-02-05 北京中天孔明科技股份有限公司 一种SparkContext的配置方法、装置及服务端
CN112486642B (zh) * 2020-11-25 2024-01-19 广州虎牙科技有限公司 资源调度方法、装置、电子设备及计算机可读存储介质
CN112486648A (zh) * 2020-11-30 2021-03-12 北京百度网讯科技有限公司 任务调度方法、装置、系统、电子设备和存储介质
CN112685158B (zh) * 2020-12-29 2023-08-04 杭州海康威视数字技术股份有限公司 一种任务调度方法、装置、电子设备及存储介质
CN112528450A (zh) * 2021-01-15 2021-03-19 博智安全科技股份有限公司 网络拓扑结构构建方法、终端设备和计算机可读存储介质
CN112749221A (zh) * 2021-01-15 2021-05-04 长鑫存储技术有限公司 数据任务调度方法、装置、存储介质及调度工具
CN112749000A (zh) * 2021-01-31 2021-05-04 云知声智能科技股份有限公司 基于k8s自动拓展强化学习任务调度方法、装置及系统
CN112783659B (zh) * 2021-02-01 2023-08-04 北京百度网讯科技有限公司 一种资源分配方法、装置、计算机设备及存储介质
CN112799787B (zh) * 2021-02-07 2023-10-03 北京华如科技股份有限公司 一种在仿真运行中改进的并行行为执行冲突消解方法及其存储介质
US11861397B2 (en) 2021-02-15 2024-01-02 Kyndryl, Inc. Container scheduler with multiple queues for special workloads
CN115033352A (zh) * 2021-02-23 2022-09-09 阿里云计算有限公司 多核处理器任务调度方法、装置及设备、存储介质
CN113110927A (zh) * 2021-04-19 2021-07-13 上海商汤科技开发有限公司 一种任务调度方法、装置、计算机设备和存储介质
CN113434270B (zh) * 2021-06-15 2023-06-23 北京百度网讯科技有限公司 数据资源调度方法、装置、电子设备及存储介质
CN113419831B (zh) * 2021-06-23 2023-04-11 上海观安信息技术股份有限公司 一种沙箱任务调度方法和系统
CN113608852A (zh) * 2021-08-03 2021-11-05 科大讯飞股份有限公司 任务调度方法、调度模块、推理节点和协同作业系统
CN113672391B (zh) * 2021-08-23 2023-11-28 烽火通信科技股份有限公司 一种基于Kubernetes的并行计算任务调度方法与系统
CN113783797B (zh) * 2021-09-13 2023-11-07 京东科技信息技术有限公司 云原生容器的网络流量控制方法、装置、设备及存储介质
CN113886052A (zh) * 2021-10-26 2022-01-04 上海商汤科技开发有限公司 任务调度方法、装置、设备、存储介质
CN114265676A (zh) * 2021-12-08 2022-04-01 中国联合网络通信集团有限公司 集群资源调度方法、装置、设备及介质
CN114064296B (zh) * 2022-01-18 2022-04-26 北京建筑大学 一种Kubernetes调度方法、装置和存储介质
CN114138500B (zh) * 2022-01-29 2022-07-08 阿里云计算有限公司 资源调度系统及方法
FR3133934A1 (fr) * 2022-03-24 2023-09-29 Vitesco Technologies Procédé de gestion d’exécution d’une pluralité de fonctions
CN114860403B (zh) * 2022-05-11 2023-07-07 科东(广州)软件科技有限公司 一种任务调度方法、装置、设备和存储介质
CN115277579B (zh) * 2022-07-25 2024-03-19 广州品唯软件有限公司 仓库视频调取方法及云平台
CN115145711B (zh) * 2022-09-02 2022-12-23 北京睿企信息科技有限公司 一种获取有向无环图任务结果的数据处理系统
CN115658332A (zh) * 2022-12-28 2023-01-31 摩尔线程智能科技(北京)有限责任公司 一种gpu共享方法及装置、电子设备和存储介质
CN115915457B (zh) * 2023-01-30 2023-05-23 阿里巴巴（中国）有限公司 资源调度方法、车辆控制方法、设备及系统
CN116192222B (zh) * 2023-04-27 2023-08-29 中国西安卫星测控中心 面向天线组阵需求的资源调度方法、装置和计算机设备
CN116719628B (zh) * 2023-08-09 2024-04-19 东莞信宝电子产品检测有限公司 一种并发任务抢占式调度方法、系统及介质
CN117435142B (zh) * 2023-12-12 2024-03-01 苏州元脑智能科技有限公司 Io请求调度方法及存储装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013509657A (ja) * 2009-10-30 2013-03-14 ヒタチデータ・システムズ・コーポレイション 名前空間を用いた、区分化されたコンテンツプラットフォーム内の固定コンテンツストレージ
JP2016500854A (ja) * 2012-09-07 2016-01-14 オラクル・インターナショナル・コーポレイション Ｌｄａｐベースのマルチカスタマ・インクラウド・アイデンティティ管理システム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101227713A (zh) * 2007-01-19 2008-07-23 华为技术有限公司 一种用户接入控制的方法及其装置
US8458712B2 (en) * 2008-04-30 2013-06-04 International Business Machines Corporation System and method for multi-level preemption scheduling in high performance processing
CN102073546B (zh) * 2010-12-13 2013-07-10 北京航空航天大学 一种云计算环境中分布式计算模式下的任务动态调度方法
US9201693B2 (en) * 2012-09-04 2015-12-01 Microsoft Technology Licensing, Llc Quota-based resource management
CN103810046A (zh) * 2012-11-15 2014-05-21 百度在线网络技术（北京）有限公司 一种单机资源管理方法及系统
US9684787B2 (en) * 2014-04-08 2017-06-20 Qualcomm Incorporated Method and system for inferring application states by performing behavioral analysis operations in a mobile device
CN113687941A (zh) * 2016-06-13 2021-11-23 阿里巴巴集团控股有限公司 一种基于优先级的资源分配方法、装置和设备
AU2018100381A4 (en) * 2018-03-27 2018-05-10 Chongqing University Of Posts And Telecommunications A physical resource scheduling method in cloud cluster
CN108769254B (zh) * 2018-06-25 2019-09-20 星环信息科技（上海）有限公司 基于抢占式调度的资源共享使用方法、系统及设备

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013509657A (ja) * 2009-10-30 2013-03-14 ヒタチデータ・システムズ・コーポレイション 名前空間を用いた、区分化されたコンテンツプラットフォーム内の固定コンテンツストレージ
JP2016500854A (ja) * 2012-09-07 2016-01-14 オラクル・インターナショナル・コーポレイション Ｌｄａｐベースのマルチカスタマ・インクラウド・アイデンティティ管理システム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022023769A (ja) * 2020-07-20 2022-02-08 ベイジン バイドゥ ネットコム サイエンス テクノロジー カンパニー リミテッド サーバリソースを割り当てるための方法、装置、電子デバイス、コンピュータ可読記憶媒体及びコンピュータプログラム

Also Published As

Publication number Publication date
CN108769254B (zh) 2019-09-20
SG11202013049XA (en) 2021-02-25
EP3799390A1 (en) 2021-03-31
CA3104806C (en) 2021-05-18
WO2020000944A1 (zh) 2020-01-02
EP3799390A4 (en) 2022-06-22
JP7060724B2 (ja) 2022-04-26
CA3104806A1 (en) 2020-01-02
CN108769254A (zh) 2018-11-06

Similar Documents

Publication Publication Date Title
JP7060724B2 (ja) タスクスケジューリング方法、リソース共有使用方法、スケジューラ、コンピュータ可読記憶媒体および装置
US10908954B2 (en) Quality of service classes
CN105900063B (zh) 多处理环境中的调度方法和装置
US10896065B2 (en) Efficient critical thread scheduling for non privileged thread requests
CN108337188B (zh) 通信量和负载感知动态队列管理
EP2300910B1 (en) Scheduler instances in a process
CN107229511B (zh) 集群任务均衡调度方法、装置、存储介质及电子设备
US20230142539A1 (en) Methods and apparatus to schedule service requests in a network computing system using hardware queue managers
CN105592110B (zh) 一种资源调度方法及装置
CN109917705B (zh) 一种多任务调度方法
KR20170059465A (ko) 애플리케이션들에 대한 네트워크 분류
US10884781B2 (en) Method and apparatus for a virtual machine
CN107634978B (zh) 一种资源调度方法及装置
US8635256B2 (en) Network filesystem asynchronous I/O scheduling
CN115766582A (zh) 流量控制方法、装置和系统、介质和计算机设备
JPH1027167A (ja) 並列計算機の負荷分散方法
EP3828707A1 (fr) Procédé d'affectation de ressources en réponse à des requêtes en fonction de leur priorité, programme d'ordinateur, bloc de contrôle d'affectation et système informatique associés
CN110636013A (zh) 一种消息队列的动态调度方法及装置
CN117667324A (zh) 用于处理任务的方法、装置、设备和存储介质
CN114138480A (zh) 队列任务分类混合处理方法、装置、系统和存储介质
Lennvall Adapting to Varying Demands in Resource Constrained Real-Time Devices
KR20180107706A (ko) 계층적 네트워크에서 다중코어를 이용한 패킷 처리 방법 및 그 장치
WO2008069528A1 (en) Priority-based wireless usb transfer service management apparatus and method thereof

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201225

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201225

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20201225

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210817

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211111

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20211207

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220225

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220405

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220414

R150 Certificate of patent or registration of utility model

Ref document number: 7060724

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150