TWI826137B - 電腦系統、應用於電腦系統的資源分配方法及執行資源分配方法的電腦程式產品 - Google Patents

電腦系統、應用於電腦系統的資源分配方法及執行資源分配方法的電腦程式產品 Download PDF

Info

Publication number
TWI826137B
TWI826137B TW111144588A TW111144588A TWI826137B TW I826137 B TWI826137 B TW I826137B TW 111144588 A TW111144588 A TW 111144588A TW 111144588 A TW111144588 A TW 111144588A TW I826137 B TWI826137 B TW I826137B
Authority
TW
Taiwan
Prior art keywords
computer system
nodes
working
memory
node
Prior art date
Application number
TW111144588A
Other languages
English (en)
Other versions
TW202422466A (zh
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 宏碁股份有限公司
Priority to TW111144588A priority Critical patent/TWI826137B/zh
Application granted granted Critical
Publication of TWI826137B publication Critical patent/TWI826137B/zh
Publication of TW202422466A publication Critical patent/TW202422466A/zh

Links

Images

Landscapes

  • Stored Programmes (AREA)
  • Image Generation (AREA)

Abstract

本發明係為一種電腦系統、應用於電腦系統的資源分配方法及執行資源分配方法的電腦程式產品。電腦系統包含:M個工作節點與控制平面。在使用者發出硬體資源請求時,M個工作節點中的第m個工作節點包含gpuAVL[m]個可用的圖形處理器、cpuAVL[m]個可用的中央處理器,以及容量為memAVL[m]的記憶體。控制平面係執行排程器。排程器因應硬體資源請求中的圖形處理器需求量自M個工作節點中選取N個預選工作節點。且,依據硬體資源請求中的中央處理器需求量與記憶體需求量而自N個預選工作節點中選取一者作為目標工作節點。

Description

電腦系統、應用於電腦系統的資源分配方法及執行 資源分配方法的電腦程式產品
本發明是有關於一種電腦系統、資源分配方法及執行資源分配方法的電腦程式產品,且特別是有關於一種因應使用者的個人化需求而調度硬體資源的電腦系統、資源分配方法及執行資源分配方法的電腦程式產品。
舵手(Kubernetes)是一套由谷歌(Google)所開發之,可自動化部署(deployment)、擴展(scaling)與管理(management)容器化應用程式(containerized applications)的開放式原始碼系統。隨著微服務(Microservice)架構、分散式系統與雲端系統的普及,讓具有自動化部屬、擴展及管理容器(Container)功能的Kubernetes成為機器學習(machine learning)的重要平台。在Kubernetes上進行機器學習模型的訓練時,需要使用大量的中央處理器(Central Processing Unit,簡稱為CPU)和圖形處理器(Graphic Processing Unit,簡稱為GPU)。
在訓練過程中,能運用的硬體資源越多,整體的訓練速度也越快。因此,雲端業者需提供多重GPU的虛擬機器(virtual machine)讓使用者選取。Kubernetes使用排程器(scheduler)管理整個電腦系統(例如,一個叢集(cluster))的硬體資源。例如,圖形處理器的數量、中央處理器的數量、記憶體數量等。在同一個電腦系統中,各個主機所提供的圖形處理器的類型不盡相同。因此,使用者可能會想依據圖形處理器的類型不同,配置數量不等的中央處理器和所需的記憶體,以便讓使用者的容器能具有最大的效能。基於不同使用者不同的個人化需求,可能衍生的工作負載也不盡相同。因此,Kubernetes需在此前提下,確保能提供適當的運算與硬體資源予使用者。
本發明係有關於一種電腦系統、應用於電腦系統的資源分配方法及執行資源分配方法的電腦程式產品。
根據本發明之第一方面,提出一種電腦系統。電腦系統包含:M個工作節點與控制平面。在使用者發出硬體資源請求時,M個工作節點中的第m個工作節點包含gpuAVL[m]個可調度使用的圖形處理器、cpuAVL[m]個可調度使用的中央處理器,以及可調度使用之容量為memAVL[m]的記憶體。控制平面信號連接於M個工作節點。控制平面執行排程器。排程器因應硬體資源請求中的圖形處理器需求量而自M個工作節點中選取N個預選工作節點。接著,依據硬體資源請求中的中央處理器需求量與記憶體需求量而自N個預選工作節點中選取一者作為目標工作節點。其中,M、m為正整數、gpuAVL[m]、 cpuAVL[m]、memAVL[m]、N為大於或等於0的整數、m小於或等於M,且N小於或等於M。
根據本發明之第二方面,提出一種應用於一電腦系統的資源分配方法。資源分配方法包含以下步驟。首先,提供M個工作節點。在使用者發出硬體資源請求時,M個工作節點中的第m個工作節點包含gpuAVL[m]個可調度使用的圖形處理器、cpuAVL[m]個可調度使用的中央處理器,以及可調度使用之容量為memAVL[m]的記憶體。接著,因應硬體資源請求中的圖形處理器需求量而自M個工作節點中選取N個預選工作節點。以及,依據硬體資源請求中的中央處理器需求量與記憶體需求量而自N個預選工作節點中選取一者作為目標工作節點。其中M、m為正整數、gpuAVL[m]、cpuAVL[m]、memAVL[m]、N為大於或等於0的整數、m小於或等於M,且N小於或等於M。
根據本發明之第三方面,提出一種電腦程式產品。電腦程式產品儲存軟體程式,該軟體程式執行時將使具有控制平面之電腦系統進行前述的資源分配方法。
為了對本發明之上述及其他方面有更佳的瞭解,下文特舉實施例,並配合所附圖式詳細說明如下:
30:電腦系統
ND[1]~ND[7]:預選工作節點
gpuTOT[1]~gpuTOT[7]:圖形處理器的總量
cpuTOT[1]~cpuTOT[7]:中央處理器的總量
memTOT[1]~memTOT[7]:記憶體的總量
31:控制平面
33,22:網路
reqSTG1:第一請求階段
reqSTG2:第二請求階段
evaSTG:評估階段
outSTG1,outSTG2:輸出階段
assSTG:資源分配階段
usrX:使用者
23:電子裝置
gpuAVL[1]~gpuAVL[7]:可調度使用的圖形處理器數量
aGPU,bGPU,cGPU:圖形處理器的類型
gpuREQ:圖形處理器需求量
preND[1]~preND[5]:預選工作節點
canND[1],canND[2],canND[3]:候選工作節點
S501,S503,S505,S507,S509,S511,S512,S513,S515,S517,S519,S521,S523,S503aS503b,S503c,S503e,S503g,S503i,S513a,S513b,S513c,S513e,S513g,S513i,S513k:步驟
第1圖,其係電腦系統的示意圖;第2圖,其係使用者針對根據本揭露構想之實施例的電腦系統請求硬體 資源時,電腦系統的狀態圖;第3A~3D圖,其係根據本揭露構想之實施例的電腦系統操作於第一請求階段reqSTG1的示意圖;第4A~4C圖,其係根據本揭露構想之實施例的電腦系統操作於第二請求階段reqSTG2的示意圖;第5圖,其係根據本揭露構想之實施例的電腦系統操作於評估階段evaSTG的示意圖;第6A、6B圖,其係根據本揭露構想之實施例之應用於電腦系統的資源分配方法的流程圖;第7圖,其係根據本揭露構想之實施例的電腦系統操作於第一請求階段reqSTG1的流程圖;及第8圖,其係根據本揭露構想之實施例的電腦系統操作於第二請求階段reqSTG2的流程圖。
請參照第1圖,其繪示電腦系統的示意圖。電腦系統30包含M個工作節點(Worker Node)ND[1]~ND[M]與控制平面(control plane)(或稱為主節點(Master Node))31。其中,M為正整數。為便於說明,此處假設M=7。控制平面31負責各個工作節點ND[1]~ND[M]的管理。控制平面31包含:庫柏介面伺服器(kube-apiserver)、資料存放叢集(etcd)、庫柏排程器(kube-scheduler),以及庫柏控制器管理者(kube-controller-manager)。且,控制平面31使用裝置外掛(device plugin)的方式調度工作節點ND[1]~ND[M]的硬體資源。
為便於說明,本文以大寫字母的變數M、N、P代表不同元件的數量,並以其對應之小寫字母代表所指的元件。例如,以M代表工作節點ND[1]~ND[M]的總數量,並以ND[m]代表其中的某個工作節點。
工作節點ND為主要執行的運行節點。一個工作節點ND對應於一台主機(host)。工作節點ND包含:微庫柏(kubelet)、庫柏代理器(kube-proxy)與容器執行時間(container runtime)。
容器(container)是指,將應用程式視為沙箱(sandbox),且包含應用程式所需的關聯系統程式、必要的執行檔等內容,讓其無須再透過另外部署安裝,即可在各種容器平台中執行。容器集(Pod)為Kubernetes運作的最小單位。根據執行需求,容器集Pod相當於容器上的封裝,容器集Pod由一組運行在同一主機的一個或者多個容器組成。一個容器集Pod對應於一個應用程式,且同一個容器集Pod內的容器共享相同的網路資源(如:IP地址、主機名稱等)。
在Kubernetes中,應用程式運作於容器集Pod內,與應用程式相關的設定則可放在組態映射(ConfigMap)內。組態映射ConfigMap用於將非敏感配置工作(例如,配置文件、命令行參數與環境變數)連結至容器集Pod和系統組件。Kubernetes使用組態映射ConfigMap呈現組態資訊,進而設定應用程式。組態映射ConfigMap透過檔案或是環境變數將組態資訊提交至容器集Pod裡的容器,以便各個應用程式能掌握各自的組態設定。
使用組態映射ConfigMap可讓應用程式與設定脫鉤(另稱為,解耦(decoupled))。即,在Kubernetes的叢集中,組態映射ConfigMap與 容器集Pod可以分別存在Kubernetes的叢集中。當容器集Pod需要使用組態映射ConfigMap時才需要將組態映射ConfigMap掛載到容器集Pod內使用。
在第1圖中,假設在電腦系統在剛開始運行時,工作節點ND[1]~ND[7]各自包含種類和數量不等的圖形處理器、數量不等的中央處理器和容量不等的記憶體,如表1列。
Figure 111144588-A0305-02-0008-1
請參見第2圖,其係使用者針對根據本揭露構想之實施例的電腦系統請求硬體資源時,電腦系統的狀態圖。根據本揭露的構想,電腦系統30可能處於第一請求階段reqSTG1、第二請求階段reqSTG2、評估階段evaSTG,或輸出階段outSTG1、outSTG2。
當電腦系統30處於第一請求階段reqSTG1時,先從使用者usrX接收一個圖形處理器需求量gpuREQ,並判斷工作節點ND[1]~ND[M]中,有哪些工作節點ND[1]~ND[M]符合需使用之圖形處理器數量的請求gpuREQ。此處假設工作節點ND[1]~ND[M]中,共有N個工作節點所提供之可調度使用的圖形處理器數量gpuAVL[m](m=1~M),大於或等於使用者usrX的圖形處理器需求量gpuREQ。其中,0
Figure 111144588-A0305-02-0008-11
gpuAVL[m],且0
Figure 111144588-A0305-02-0008-12
N
Figure 111144588-A0305-02-0008-13
M。這 N個可提供符合使用者usrX需求之圖形處理器需求量gpuREQ的工作節點ND[m](m=1~M)可進一步稱為,預選工作節點preND[1]~preND[N]。關於第一請求階段reqSTG1的細節,請一併參看第3A~3D圖的舉例和步驟S505的說明。
當電腦系統30處於第二請求階段reqSTG2時,先從使用者usrX接收一個中央處理器需求量cpuREQ和一個需使用之記憶體容量memREQ,並判斷N個符合圖形處理器需求量gpuREQ的預選工作節點preND[1]~preND[N]中,有哪些預選工作節點preND[1]~preND[N]所提供之可調度使用的中央處理器數量cpuAVL[m](m=1~M),大於或等於使用者usrX所提出的中央處理器需求量cpuREQ,且可調度使用的記憶體容量memAVL[m](m=1~M),亦大於或等於使用者usrX所提出的記憶體容量memREQ。其中,0
Figure 111144588-A0305-02-0009-14
cpuAVL[m],且0
Figure 111144588-A0305-02-0009-15
memAVL[m]。此處假設N個預選工作節點preND[1]~preND[N]中,共有P個預選工作節點同時滿足使用者usrX所提出之中央處理器需求量cpuREQ和需使用之記憶體容量memREQ。其中,0
Figure 111144588-A0305-02-0009-16
P
Figure 111144588-A0305-02-0009-17
N。這P個同時符合使用者usrX之中央處理器需求量cpuREQ和需使用之記憶體容量memREQ的預選工作節點可進一步定義為,候選工作節點canND[1]~canND[P]。關於第二請求階段reqSTG2的細節,請一併參看第4A~4C圖的舉例與步驟S521的說明。
當電腦系統30處於評估階段evaSTG時,排程器從P個候選工作節點canND[1]~canND[P]中,選擇其中一者做為分配給使用者usrX使用的目標工作節點tgtND。其中,P>0。此處,排程器從候選工作節點canND[1]~canND[P]選取目標工作節點tgtND的方式,可根據排程器對系統 資源的排程策略而定。關於評估階段evaSTG的細節,請一併參看第5圖的舉例與步驟S527的說明。
當電腦系統30處於輸出階段outSTG1時,代表排程器無法自工作節點ND[1]~ND[M]中,找到任何一個符合使用者usrX需求的工作節點。即,P=0。另一方面,當電腦系統30處於輸出階段outSTG2時,代表排程器自工作節點ND[1]~ND[M]中,剛好找到一個符合使用者usrX所需的工作節點ND[m](m=1~M)。即,P=1。此時,排程器將這個符合使用者usrX所需的工作節點視為目標工作節點tgtND。
當評估階段evaSTG或輸出階段outSTG2結束後,電腦系統30將操作於資源分配階段assSTG。當電腦系統30處於資源分配階段assSTG時,排程器將綁定目標工作節點tgtND與容器集Pod之間的關係。
第2圖呈現電腦系統30所處的狀態之間的關係。關於電腦系統30的操作如何在第一請求階段reqSTG1、第二請求階段reqSTG2、評估階段evaSTG、輸出階段outSTG1、outSTG2,或資源分配階段assSTG改變之細節,將於後續說明。為便於說明,以下圖式裡的電腦系統30僅繪式工作節點ND[1]~ND[7],未再重複繪式控制平面31。
排程器掌握在電腦系統30中的M個工作節點ND[1]~ND[M]所配備的硬體資源,並針對使用者的各種容器集Pod的執行需求而對工作節點ND[1]~ND[M]所提供的硬體資源進行資源分配。例如,排程器掌握工作節點ND[1]~ND[M]最初配置的GPU類型typeGPU、GPU的總量gpuTOT[1]~gpuTOT[M]、CPU的總量cpuTOT[1]~cpuTOT[M],以及記憶體的總量memTOT[1]~memTOT[M]。且,排程器亦掌握在執行期間,與各個 工作節點ND[1]~ND[M]對應之可調度使用的圖形處理器數量gpuAVL[1]~gpuAVL[M]、可調度使用的中央處理器數量cpuAVL[1]~cpuAVL[M],以及可調度使用之記憶體容量量memAVL[1]~memAVL[M]。
使用者usrX針對電腦系統30執行容器集Pod的需求,向排程器提出硬體資源請求usrREQ。例如,usrREQ(gpuREQ,cpuREQ,memREQ)。gpuREQ代表使用者usrX向排程器所請求用於執行容器集Pod的圖形處理器需求量;cpuREQ代表使用者usrX向排程器所請求用於執行容器集Pod的中央處理器需求量;以及,memREQ代表使用者usrX向排程器所請求用於執行容器集Pod的記憶體需求量。其中,中央處理器需求量cpuREQ和記憶體需求量memREQ的數值,隨著排程器所調度之圖形處理器的類型typeGPU不同而改變。
為便於說明,以下以實際的數字為例,搭配第3A~3D、4A~4C、5圖說明本案針對電腦系統30提供的管理方法。其中,第3A~3D圖對應於第一請求階段reqSTG1;第4A~4C圖對應於第二請求階段reqSTG2;且,第5圖對應於評估階段evaSTG。在這些圖式中,關於工作節點的數量、各種硬體元件的種類、個數、搭配之數字組合等,均為舉例使用。實際應用時,工作節點的數量、各種硬體元件的種類、個數、搭配之數字組合等,均不以此處的舉例為限。
請參見第3A~3D圖,其係根據本揭露構想之實施例的電腦系統操作於第一請求階段reqSTG1的示意圖。
在第3A圖中,假設使用者usrX操作電子裝置23,並向電腦系統30請求使用兩個圖形處理器(gpuREQ=2)。在第3B圖中,假設工作節 點ND[1]~ND[7]各自提供之可用的圖形處理器的類型(aGPU、bGPU、cGPU)與可調度使用的圖形處理器數量gpuAVL[1]~gpuAVL[7]如表2所列。
Figure 111144588-A0305-02-0012-2
排程器將比較各個工作節點ND[1]~ND[7]所包含之可調度使用的圖形處理器數量gpuAVL[m]是否可滿足使用者usrX所提出的圖形處理器需求量gpuREQ(gpuAVL[m]
Figure 111144588-A0305-02-0012-18
gpuREQ?)。如表2所列,此處假設工作節點ND[2]、ND[4]的可調度使用的圖形處理器數量gpuAVL[2]、gpuAVL[4]不足以提供使用者usrX的圖形處理器需求量gpuREQ,僅工作節點ND[1]、ND[3]、ND[5]、ND[6]、ND[7]的可調度使用的圖形處理器數量gpuAVL[1]、gpuAVL[3]、gpuAVL[5]、gpuAVL[6]、gpuAVL[7]足以提供使用者usrX的圖形處理器需求量gpuREQ。即,gpuAVL[1]
Figure 111144588-A0305-02-0012-19
gpuREQ、gpuAVL[2]<gpuREQ、gpuAVL[3]
Figure 111144588-A0305-02-0012-20
gpuREQ、gpuAVL[4]<gpuREQ、gpuAVL[5]
Figure 111144588-A0305-02-0012-21
gpuREQ、gpuAVL[6]
Figure 111144588-A0305-02-0012-22
gpuREQ、gpuAVL[7]
Figure 111144588-A0305-02-0012-23
gpuREQ。
第3C圖為,第一請求階段reqSTG1選取後的結果。在第3C圖中,以較細的虛線描繪經排程器判斷為,可調度使用的圖形處理器數量gpuAVL[2]、gpuAVL[4]不符合使用者usrX所提出的圖形處理器需求量 gpuREQ的工作節點ND[2]、ND[4]。表3所列為,經過第一請求階段reqSTG1的選取後,所提供之可調度使用的圖形處理器的數量gpuAVL[1]、gpuAVL[3]、gpuAVL[5]、gpuAVL[6]大於或等於使用者usrX所提出之圖形處理器需求量gpuREQ(gpuAVL[m]
Figure 111144588-A0305-02-0013-24
gpuREQ)的工作節點ND[1]、ND[3]、ND[5]、ND[6]、ND[7]。
Figure 111144588-A0305-02-0013-3
根據表3可以看出,在電腦系統30中,可提供使用者usrX所提出之圖形處理器需求量gpuREQ的工作節點ND[1]、ND[3]、ND[5]、ND[6]、ND[7],共採用三種類型的圖形處理器aGPU、bGPU、cGPU。表4所列為不同類型的的圖形處理器aGPU、bGPU、cGPU和工作節點ND[1]、ND[3]、ND[5]、ND[6]、ND[7]的對應關係。
Figure 111144588-A0305-02-0013-4
因此,在第3C圖中,排程器從工作節點ND[1]~ND[7]中,共找出N=5個可提供兩個圖形處理器(gpuREQ=2)的工作節點ND[1]、ND[3]、ND[5]、ND[6]、ND[7]。且,排程器進一步將工作節點ND[1]定義為預選工作節點preND[1];將工作節點ND[3]定義為預選工作節點preND[2];將工作 節點ND[5]定義為預選工作節點preND[3];將工作節點ND[6]定義為預選工作節點preND[4];以及,將工作節點ND[7]定義為預選工作節點preND[5]。
第3D圖為,排程器在第一請求階段reqSTG1針對使用者usr所提出的圖形處理器需求量gpuREQ而回傳的查詢結果。查詢結果包含,目前在電腦系統30所查詢到之可調度使用的圖形處理器數量滿足圖形處理器需求量gpuREQ的N個預選工作節點preND[1]~preND[N],以及該N個預選工作節點preND[1]~preND[N]所提供之圖形處理器的類型typeGPU。例如,在此實施例中,目前在電腦系統30所查詢到可用的圖形處理器的類型typeGPU為:圖形處理器aGPU、bGPU、cGPU;且,符合查詢結果的N=5個預選工作節點preND[1]~preND[5]如表5所列。
Figure 111144588-A0305-02-0014-5
請參見第4A~4C圖,其係根據本揭露構想之實施例的電腦系統操作於第二請求階段reqSTG2的示意圖。第4A圖代表使用者usrX可利用組態映射ConfigMAP通知排程器,針對可能被分配使用之圖形處理器的類型aGPU、bGPU、cGPU,使用者usrX期能搭配使用之中央處理器的數量和記憶體的容量,如表6所列。
Figure 111144588-A0305-02-0014-6
Figure 111144588-A0305-02-0015-7
根據表6的假設,若排程器選取的工作節點ND[m]提供圖形處理器aGPU時,則使用者usrX希望該被選取之工作節點ND[m]可同步提供32個中央處理器(中央處理器需求量cpuREQ_a=32)和容量為500G的記憶體(記憶體需求量memREQ_a=500G)。若排程器選取的工作節點ND[m]提供圖形處理器bGPU時,則使用者usrX希望該被選取之工作節點ND[m]可同步提供64個中央處理器(中央處理器需求量cpuREQ_b=64)和容量為400G的記憶體(記憶體需求量memREQ_b=400G)。若排程器選取的工作節點ND[m]提供圖形處理器cGPU時,則使用者usrX該被選取之工作節點ND[m]可同步提供16個中央處理器(中央處理器需求量cpuREQ_c=16)和容量為2T的記憶體(記憶體需求量memREQ_c=2T)。
由表6可以看出,即便是使用者usrX同樣請求使用2個圖形處理器(gpuREQ=2)的情況下,使用者usrX仍保有因應圖形處理器的類型typeGPU而決定中央處理器需求量cpuREQ和記憶體需求量memREQ的彈性。換言之,使用者usrX針對與圖形處理器aGPU、bGPU、cGPU對應提出的中央處理器需求量cpuREQ_a、cpuREQ_b、cpuREQ_c可以相等或不等;且,使用者usrX針對與圖形處理器aGPU、bGPU、cGPU對應提出的記憶體需求量memREQ_a、memREQ_b、memREQ_c可以相等或不等。
例如,比較圖形處理器類型為bGPU、cGPU的情況可以看出,使用者usrX認為若排程器分配的工作節點利用圖形處理器bGPU執行容器集Pod時,需要較多個中央處理器,但可搭配容量較小的記憶體。另一方面,若排程器分配的工作節點利用圖形處理器cGPU執行容器集Pod時,可使用較少的中央處理器,但需要搭配容量較大的記憶體。即,cpuREQ_b>cpuREQ_c,且memREQ_b<memREQ_c。據此,排程器讓使用 者usrX在既有且已知被分配之圖形處理器的類型aGPU、bGPU、cGPU的前提下,進一步選擇與其容器集Pod搭配使用之中央處理器需求量和記憶體需求量的彈性。
為簡化說明,前述舉例僅說明本案可透過在組態映射ConfigMap額外加入偏好資訊或個人化設定的方式。惟,在前述舉例中,並未依照組態映射ConfigMap實際使用的格式。在實際應用時,組態映射ConfigMap的設定格式,需依循Kubernetes的規範。
再者,將使用者usrX的需求傳送至排程器的方式,亦不限於以組態映射ConfigMap的方式進行。例如,使用者usrX可在要求創建容器集Pod時,利用在容器集樣板(pod template)中定義新的欄位的方式帶入額外的硬體資源請求資訊。或者,使用者usrX可利用節點標籤(node label)標註工作節點所配置的圖形處理器的類型aGPU、bGPU、cGPU,以及在工作節點ND[1]~ND[7]配置之中央處理器的總量、可調度使用的中央處理器數量、記憶體的總量和可調度使用之記憶體容量等資訊。實際應用時,關於如何將使用者usrX的硬體需求通知排程器,以及傳送硬體需求的格式和過程等,並不需要加以限定。
在第4B圖中,排程器針對N=5個預選工作節點preND[1]~preND[5],分別將其所提供之可調度使用的中央處理器數量cpuAVL[1]~cpuAVL[5]和與其圖形處理器相對應之中央處理器需求量cpuREQ_a、cpuREQ_b、cpuREQ_c進行比較;且,排程器針對N=5個預選工作節點preND[1]~preND[5],分別將其所提供之可調度使用之記憶體容量memAVL[1]~memAVL[5]和與其圖形處理器的類型aGPU、bGPU、cGPU相對應之記憶體需求量memREQ_a、memREQ_b、memREQ_c進行比較。
在此實施例中,假設工作節點ND[1]具有圖形處理器cGPU。且,假設工作節點ND[1]所提供之可調度使用的中央處理器數量cpuAVL[1]為8個(cpuAVL[1]=8)、可調度使用之記憶體容量memAVL[1]為2T(memAVL[1]=2T)。因工作節點ND[1]所提供之可調度使用的中央處理器數量cpuAVL[1],少於使用者usrX認為其容器集Pod若搭配圖形處理器cGPU執行時所需使用之中央處理器需求量cpuREQ_c(即,cpuAVL[1]<cpuREQ_c)的緣故,代表工作節點ND[1](即,預選工作節點preND[1])不適合用於執行使用者usrX所提出的容器集Pod。
在此實施例中,假設工作節點ND[3]具有圖形處理器bGPU。且,假設工作節點ND[3]所提供之可調度使用的中央處理器數量cpuAVL[3]為96個(cpuAVL[3]=96)、可調度使用之記憶體容量memAVL[3]為2T(memAVL[3]=2T)。因工作節點ND[3]所提供之可調度使用的中央處理器數量cpuAVL[1],大於使用者usrX認為其容器集Pod若搭配圖形處理器bGPU執行時所需使用之中央處理器需求量cpuREQ_c(即,cpuAVL[1]=96>cpuREQ_c=64),且工作節點ND[3]所提供之可調度使用之記憶體容量memAVL[3]大於使用者usrX認為其容器集Pod若搭配圖形處理器bGPU時所需使用之記憶體需求量memREQ_b(即,memAVL[3]=2T>memREQ_b=400G)的緣故,代表工作節點ND[3](即,預選工作節點preND[2])適合用於執行使用者usrX所提出的容器集Pod。
在此實施例中,假設工作節點ND[5]具有圖形處理器aGPU。且,假設工作節點ND[5]所提供之可調度使用的中央處理器數量cpuAVL[5]為32個(cpuAVL[5]=32)、可調度使用之記憶體容量memAVL[5]為400G(memAVL[5]=400G)。因工作節點ND[5]所提供之可調度使用之記憶體容量memAVL[5],小於使用者usrX認為其容器集Pod若搭配圖形處理 器aGPU執行時所需使用之記憶體需求量memREQ_a(即,memAVL[5]=400G<memREQ_a=500G)的緣故,代表工作節點ND[5](即,預選工作節點preND[3])不適合用於執行使用者usrX所提出的容器集Pod。
在此實施例中,假設工作節點ND[6]具有圖形處理器cGPU。且,假設工作節點ND[6]所提供之可調度使用的中央處理器數量cpuAVL[6]=20、可調度使用之記憶體容量memAVL[6]=4T。因工作節點ND[6]所提供之可調度使用的中央處理器數量cpuAVL[6],等於使用者usrX認為其容器集Pod若搭配圖形處理器cGPU時所需使用之中央處理器需求量cpuREQ_c(即,cpuAVL[6]=20>cpuREQ_c=16,且工作節點ND[6]所提供之可調度使用之記憶體容量memAVL[6],大於使用者usrX認為其容器集Pod若搭配圖形處理器cGPU執行時所需使用之記憶體需求量memREQ_c(memAVL[6]=4T>memREQ_c=2T)的緣故,代表工作節點ND[6](即,預選工作節點preND[4])適合用於執行使用者usrX所提出的容器集Pod。
在此實施例中,假設工作節點ND[7]具有圖形處理器aGPU。且,假設工作節點ND[7]所提供之,可調度使用的中央處理器數量cpuAVL[7]=32、可調度使用之記憶體容量memAVL[7]=1T。因工作節點ND[7]所提供之可調度使用的中央處理器數量cpuAVL[7],等於使用者usrX認為其容器集Pod若搭配圖形處理器aGPU執行時所需使用之中央處理器需求量cpuREQ_a(即,cpuAVL[7]=32=cpuREQ_a=32),且因工作節點ND[7]所提供之可調度使用之記憶體容量memAVL[7],大於使用者usrX認為其容器集Pod若搭配圖形處理器aGPU時所需使用之記憶體需求量memREQ_a(memAVL[7]=1T>memREQ_a=500G)的緣故,代表工作節點 ND[6](即,預選工作節點preND[5])適合用於執行使用者usrX所提出的容器集Pod。
根據第4B圖的說明可以得知,工作節點ND[1]~ND[7]中,僅工作節點ND[3]、ND[6]、ND[7]所提供之可調度使用的圖形處理器數量gpuAVL[3]、gpuAVL[6]、gpuAVL[7]、可調度使用的中央處理器數量cpuAVL[3]、cpuAVL[6]、cpuAVL[7],和可調度使用之記憶體容量memAVL[3]、memAVL[6]、memAVL[7]均符合使用者usrX的需求。此處將可調度使用的圖形處理器數量、可調度使用的中央處理器數量和可調度使用之記憶體容量均符合使用者usrX需求的預選工作節點preND[2]、preND[4]、preND[5]定義為P個候選工作節點canND[1]~canND[P]。在此實施例中,P=3。因此,在第4C圖中,排程器在第二請求階段reqSTG2結束時,將工作節點ND[3](即,預選工作節點preND[2])定義為候選工作節點canND[1];將工作節點ND[6](即,預選工作節點preND[4])定義為候選工作節點canND[2];以及,將工作節點ND[7](即,預選工作節點preND[5])定義為候選工作節點canND[3]。
請參見第5圖,其係根據本揭露構想之實施例的電腦系統操作於評估階段evaSTG的示意圖。排程器評估候選工作節點canND[1]~canND[3]中的何者較適合作為目標工作節點tgtND。請留意,排程器自候選工作節點canND[1]~canND[3]中,選取目標工作節點tgtND的方式,可根據排程器的排程策略(scheduling strategy)而異。
例如,若排程器評估候選工作節點canND[1]~canND[3]時,排程策略是從其中選取具有最充分之硬體資源者,則排程器可能選取工作節點ND[3](即,候選工作節點canND[1])作為目標工作節點tgtND。或者,若排程策略希望保留硬體資源給未來其他使用者usrY的請求時,則排程器 在評估候選工作節點canND[1]~canND[3]時,可能是依據硬體資源最符合者。此時,排程器可能選取工作節點ND[7](即,候選工作節點canND[3])作為目標工作節點tgtND。關於排程器如何因應排程策略的不同而對候選工作節點canND[1]~canND[3]進行評估,進而選擇目標工作節點tgtND的考量和應用上的變化,此處不予詳述。
請參見第6A、6B圖,其係根據本揭露構想之實施例之應用於電腦系統的資源分配方法的流程圖。首先,在排程器接收使用者usrX發出的圖形處理器需求量gpuREQ(步驟S501,可參見第3A圖的舉例)後,電腦系統30操作於第一請求階段reqSTG1(步驟S503,可參見第3B、3C圖的舉例)。當電腦系統30操作於第一請求階段reqSTG1時,排程器自工作節點ND[1]~ND[M]中選取N個預選工作節點preND[1]~preND[N]。
第7圖為執行步驟S503的一種方式的相關細節。實際應用時,排程器亦可採用其他方式獲知工作節點ND[1]~ND[M]中,有哪些工作節點可做為預選工作節點preND[1]~preND[N]使用。例如,排程器可動態維護一個表格,並以查表方式得知工作節點ND[1]~ND[M]在即時狀態下,可供使用之圖形處理器的類型aGPU、bGPU、cGPU和可調度使用的圖形處理器數量gpuAVL[1]~gpuAVL[7]。
接著,排程器判斷預選工作節點總量N是否等於0(步驟S507)。若步驟S507的判斷結果為肯定,代表目前電腦系統30中,並無任何工作節點ND[1]~ND[M]可以提供符合使用者usrX請求的圖形處理器需求量gpuREQ。因此,排程器通知使用者usrX目前電腦系統30中的硬體資源不足(步驟S509)。步驟S509對應於第2圖的輸出階段outSTG1。
若步驟S507的判斷結果為否定,排程器將通知使用者usrX,為因應使用者usrX的圖形處理器需求量gpuREQ,目前電腦系統30可提供的圖形處理器的類型typeGPU(步驟S511,可參見第3D圖的舉例)。接著,排程器將接收使用者usrX利用電子裝置23所發出的中央處理器需求量cpuREQ與記憶體需求量memREQ(步驟S512)。另請留意,在此流程圖中,中央處理器需求量cpuREQ與記憶體需求量memREQ係指使用者usrX針對不同類型之圖形處理器aGPU、bGPU、cGPU,向排程器所提出之,應搭配使用的中央處理器需求量cpuREQ_a、cpuREQ_b、cpuREQ_c與記憶體需求量memREQ_a、memREQ_b、memREQ_c。其中,中央處理器需求量cpuREQ_a、cpuREQ_b、cpuREQ_c可能相等或不等,且記憶體需求量memREQ_a、memREQ_b、memREQ_c可能相等或不等。
例如,使用者usrX認為,若預選工作節點ND[n]提供圖形處理器aGPU時,則其欲使用的容器集Pod須搭配使用cpuREQ_a個中央處理器和容量為memREQ_a的記憶體。或者,使用者usrX認為,若預選工作節點ND[n]提供圖形處理器bGPU時,則其欲使用的容器集Pod須搭配使用cpuREQ_b個中央處理器和容量為memREQ_b的記憶體。再者,使用者usrX認為,若預選工作節點ND[n]提供圖形處理器cGPU時,則其欲使用的容器集Pod須搭配使用cpuREQ_c個中央處理器和容量為memREQ_c的記憶體。
實際應用時,使用者usrX根據圖形處理器aGPU、bGPU、cGPU而通知排程器其所需之中央處理器需求量cpuREQ與記憶體需求量memREQ的組合,可能隨著預選工作節點preND[1]~preND[N]實際可提供的圖形處理器的類型而決定。例如,若排程器發現預選工作節點preND[1]~ preND[N]僅提供圖形處理器aGPU、bGPU時,則使用者usrX可能僅提供針對這兩種類型之圖形處理器aGPU、bGPU的中央處理器需求量cpuREQ_a、cpuREQ_b與記憶體需求量memREQ_a、memREQ_b。此種關於應用上的變化,此處不予詳述。
當電腦系統30操作於第二請求階段reqSTG2時,排程器自預選工作節點preND[1]~preND[N]中選取P個候選工作節點canND[1]~canND[P](步驟S513,可參見第4B、4C圖的舉例)。關於步驟S513的相關細節,將於第8圖說明。
第二請求階段reqSTG2結束後,排程器判斷P是否等於0(步驟S515)。若步驟S507的判斷結果為肯定,代表目前電腦系統30中,並無任何工作節點ND[1]~ND[M]可以提供符合使用者usrX之需求的中央處理器數量和記憶體的容量。因此,排程器通知使用者usrX目前電腦系統30中的硬體資源不足(步驟S509)。
若步驟S515的判斷結果為否定,排程器進一步判斷P是否等於1(步驟S517)。若步驟S517的判斷結果為肯定,排程器以唯一的候選工作節點canND[1]作為目標工作節點tgtND(步驟S519)。步驟S519對應於第2圖的輸出階段outSTG2。
若步驟S517的判斷結果為否定,排程器根據排程策略自評估清單所列的P個候選工作節點canND[1]~canND[P]中,選取一者作為目標工作節點tgtND(步驟S521,可參見第5圖的舉例)。隨著排程策略的不同,排程器自P個候選工作節點canND[1]~canND[P]所選取的目標工作節點tgtND也可能不同。步驟S521對應於第2圖的評估階段evaSTG。
步驟S519、S521結束後,排程器將使用者usrX的容器集Pod綁定(bind)至目標工作節點tgtND(步驟S523,可參見第5圖的舉例)後,流程結束。其中,步驟S523對應於第2圖的資源分配階段assSTG。
請參見第7圖,其係根據本揭露構想之實施例的電腦系統操作於第一請求階段reqSTG1的流程圖。第7圖的流程對應於第3B、3C圖的舉例。
首先,排程器初始化工作節點計數值m(m=1)和初始化預選工作節點總量N(N=0)(步驟S503)。其次,排程器確認第m個工作節點ND[m]提供的可調度使用的圖形處理器數量gpuAVL[m]是否大於或等於使用者usrX所提出之圖形處理器需求量gpuREQ(即,gpuAVL[m]
Figure 111144588-A0305-02-0023-25
gpuREQ?)(步驟S503b)。若步驟S503b的判斷結果為肯定,則累加預選工作節點總量N(N++)(步驟S503c),並將第m個工作節點ND[m]列入預選工作節點preND[1]~preND[N]中(步驟S503e)。
若步驟S503b的判斷結果為否定,或步驟S503e結束後,排程器將於步驟S503i中,判斷是否M個工作節點ND[1]~ND[M]均已完成步驟S503b、S503c、S503e。若步驟S503i的判斷結果為否定,則在累加工作節點計數值m(m++)(步驟S503g)後,重複執行步驟S503b。若步驟S503i的判斷結果為肯定,則結束第一請求階段reqSTG1。
請參見第8圖,其係根據本揭露構想之實施例的電腦系統操作於第二請求階段reqSTG2的流程圖。第8圖的流程對應於第4B、4C圖的舉例。
首先,排程器初始化預選工作節點計數值n、候選工作節點總量P(設定n=1,且設定P=0)(步驟S513a)。其次,排程器確認預選工作節點preND[n]所代表之工作節點ND[m]提供的可調度使用的中央處理器數量cpuAVL[m],是否大於或等於中央處理器需求量cpuREQ(cpuAVL[m]
Figure 111144588-A0305-02-0024-26
cpuREQ?)(步驟S513b)。如前所述,在實際應用時,步驟S513b的中央處理器需求量cpuREQ的數值(cpuREQ_a、cpuREQ_b、cpuREQ_c),會根據工作節點ND[m]所具備之圖形處理器的類型aGPU、bGPU、cGPU而異。
若步驟S513b的判斷結果為肯定,排程器接著確認預選工作節點preND[n]所代表之工作節點ND[m]提供的可調度使用之記憶體容量memAVL[n],是否大於或等於記憶體需求量memREQ(memAVL[m]
Figure 111144588-A0305-02-0024-27
memREQ?)(步驟S513c)。如前所述,在實際應用時,步驟S513c的記憶體需求量memREQ的數值,會根據工作節點ND[m]所具備之圖形處理器的類型aGPU、bGPU、cGPU而異。
若步驟S513c的判斷結果為肯定,排程器先累加候選工作節點總量P(P++)(步驟S513e)。接著,排程器再將預選工作節點preND[n]所代表之工作節點ND[m]視為候選工作節點canND[P](步驟S513g)。
若步驟S513b的判斷結果為否定、步驟S513c的判斷結果為否定,或步驟S513g結束後,排程器將判斷預選工作節點計數值n是否等於預選工作節點總量N。即,排程器判斷是否與N個預選工作節點preND[1]~pre[N]所代表之工作節點ND[m]對應的中央處理器數量和記憶體數量均已經過確認(步驟S513j)。若步驟S513j的判斷結果為肯定,則第二請 求階段reqSTG2的流程結束。若步驟S513j的判斷結果為否定,則排程器累加預選工作節點計數值n(n++)(步驟S513k)後,再針對另一個預選工作節點preND[n]執行步驟S513b。
根據本揭露的構想,排程器接收使用者usrX所提出之,關於圖形處理器需求量gpuREQ、中央處理器需求量cpuREQ與記憶體需求量memREQ的格式並不需要加以限定。在前述實施例中,假設排程器在第一請求階段reqSTG1前接收圖形處理器需求量gpuREQ,以及,在第一請求階段reqSTG1結束後,才接收中央處理器需求量cpuREQ與記憶體需求量memREQ。但,在實際應用時,排程器亦可在第一請求階段reqSTG1前,同時接收圖形處理器需求量gpuREQ、中央處理器需求量cpuREQ與記憶體需求量memREQ。儘管排程器在第一請求階段reqSTG1前,已預先收到中央處理器需求量cpuREQ與記憶體需求量memREQ,但仍然僅在第一請求階段reqSTG1處理關於圖形處理器需求量gpuREQ的相關判斷。之後,方於第二請求階段reqSTG2處理關於中央處理器需求量cpuREQ與記憶體需求量memREQ的判斷。
根據前述說明可以得知,本揭露透過兩階段(第一請求階段reqSTG1、第二請求階段reqSTG2)的方式,讓使用者usrX可以依循個入偏好,在第一請求階段reqSTG1先得知被符合圖形處理器需求量gpuREQ的圖形處理器類型aGPU、bGPU、cGPU後,進一步根據被分配之圖形處理器的類型aGPU、bGPU、cGPU,於第二請求階段reqSTG2向排程器請求中央處理器需求量cpuREQ與記憶體需求量memREQ。除前述實施例外,本揭露 的管理方法亦可針對應用的不同,修改部分細節。以下舉例說明幾種應用時可能的變化。
首先,在前述實施例中,使用者usrX分別在第一請求階段reqSTG1、第二請求階段reqSTG2前,向排程器發出硬體資源請求。即,使用者usrX在第一請求階段reqSTG1請求圖形處理器需求量gpuREQ後,再視排程器實際蒐尋得出之圖形處理器的類型aGPU、bGPU、cGPU,才在第二請求階段reqSTG2視圖形處理器的類型aGPU、bGPU、cGPU,發出中央處理器需求量cpuREQ_a、cpuREQ_b、cpuREQ_c和記憶體需求量memREQ_a、memREQ_b、memREQ_c。在實際應用時,使用者usrX亦可透過在組態映射ConfigMap中,預先以預設條件的方式或格式呈現個人化需求,如表7所列。
Figure 111144588-A0305-02-0026-8
例如,使用者usrX可以請求2個圖形處理器(gpuREQ=2),並加註若排程器檢視可用之圖形處理器後,確認目前電腦系統30可提供圖形處理器aGPU時,則需搭配32個中央處理器(cpuREQ_a=32)與容量為500G的記憶體(memREQ_a=500G);若排程器檢視可用之圖形處理器後,確認電腦系統30可提供圖形處理器bGPU時,則需搭配64個中央處理器(cpuREQ_b=64)與容量為400G的記憶體(memREQ_b=400G);以及,若排程器檢視可用之圖形處理器後,確認電腦系統30可提供圖形處理器cGPU時, 則須搭配16個中央處理器(cpuREQ_c=16)與容量為2T的記憶體(cpuREQ_c=2T)。
則,排程器在進行硬體資源的分配與調度時,仍然可以先就圖形處理器需求量gpuREQ進行查詢。之後,再由排程器直接基於第一請求階段reqSTG1的搜尋結果,進行第二請求階段reqSTG2的判斷。採用此種作法時,可以讓使用者usrX單次將硬體資源請求的條件下達清楚,亦不影響排程器針對電腦系統30中的可用硬體資源的判斷結果。
此外,因電腦系統30可能同時提供給多個使用者usrX、usrY使用。因此,不同的使用者usrX、usrY針對同類型之圖形處理器所需搭配的中央處理器需求量cpuREQ、記憶體需求量memREQ。亦即,在不同的組態映射ConfigMap中,可針對個別的使用者usrX、usrY提供個別的專屬設定。表8不同使用者usrX、usrY可能提出之不同硬體資源請求的舉例。
Figure 111144588-A0305-02-0027-9
表8假設,使用者usrX可根據所請求使用之圖形處理器的類型aGPU、bGPU、cGPU,在組態映射ConfigMap中,針對圖形處理器GPUa標註硬體資源請求usrREQ(aGPU,2,32,500G)、針對圖形處理器GPUb標註硬體資源請求usrREQ(bGPU,2,32,500G),或針對圖形處理器GPUc標註硬 體資源請求usrREQ(cGPU,1,8,2T)。同理,使用者usrY可根據所請求使用之圖形處理器的類型aGPU、bGPU、cGPU,在組態映射ConfigMap中,針對圖形處理器GPUa標註硬體資源請求usrREQ(aGPU,2,16,1T)、針對圖形處理器GPUb標註硬體資源請求usrREQ(bGPU,4,64,4T),或針對圖形處理器GPUc標註硬體資源請求usrREQ(cGPU,2,4,2T)。
再者,關於使用者usrX所給之元件組合的方式,除了在第二請求階段reqSTG2以單次下達請求的方式明確告知排程器其容器集Pod所需使用之中央處理器需求量cpuREQ和記憶體需求量memREQ外,亦可以在第二請求階段reqSTG2前(甚至可在第一請求階段reqSTG1前),預先提供與圖形處理器aGPU、bGPU、cGPU分別對應的預設比率aRatio、bRatio、cRatio。
後續,若使用者usrX向排程器請求所需之圖形處理器需求量gpuREQ時,排程器可在查詢電腦系統30並得知可用之圖形處理器的類型aGPU、bGPU、cGPU和預選工作節點preND[1]~preND[N]後,直接參酌預設比例aRatio、bRatio、cRatio判斷該些預選工作節點preND[1]~preND[N]的可調度使用的中央處理器數量cpuAVL和可調度使用之記憶體容量memAVL是否符合需求。表9為,根據圖形處理器的類型aGPU、bGPU、cGPU不同而定義之預設比率的舉例列表。
Figure 111144588-A0305-02-0028-10
例如:假設使用者usrX預先提供三組預設比率aRatio=1:16:250G、bRatio=1:32:200G、cRatio=1:8:1T,並向排程器請求3個(圖形處理器需求量gpuREQ=3)圖形處理器的情況。則,基於此種比例關係,排程器再個別判斷經查詢後實際得到之可用的圖形處理器的類型aGPU、bGPU、cGPU,是否仍有足夠數量的中央處理器(cpuAVL[m]
Figure 111144588-A0305-02-0029-28
cpuREQ?)和足夠的記憶體容量(memAVL[m]
Figure 111144588-A0305-02-0029-29
memREQ?)可用。
假設排程器在第一請求階段reqSTG1得知,在電腦系統30中,確實存在至少一個預選工作節點preND[n](n=1~N)可提供足夠數量的圖形處理器aGPU(圖形處理器數量gpuAVL[m]
Figure 111144588-A0305-02-0029-30
圖形處理器需求量gpuREQ=3)。則,在第二請求階段reqSTG2,排程器需進一步基於與圖形處理器GPUa對應之預設比率aRatio=1:16:250G和圖形處理器需求量gpuREQ=3,確認可提供足夠之圖形處理器aGPU的該至少一個預選工作節點preND[n](n=1~N)可否進一步提供數量大於或等於中央處理器需求量cpuAMTu_a*gpuREQ=cpuREQ_a=48個的中央處理器,和容量大於或等於記憶體需求量memAMTu_a *gpuREQ=memREQ_a=750G的記憶體。
假設排程器查詢電腦系統30後得知,在電腦系統30中,確實存在至少一個預選工作節點preND[n](n=1~N)可提供足夠數量的圖形處理器bGPU(圖形處理器數量gpuAVL[m]
Figure 111144588-A0305-02-0029-31
圖形處理器需求量gpuREQ=3)。則,在第二請求階段reqSTG2,排程器需進一步基於與圖形處理器bGPU對應之預設比率bRatio=1:32:200G和圖形處理器需求量gpuREQ=3,確認可提供足夠之圖形處理器bGPU的該至少一個預選工作節點preND[n](n=1~N)可否進一步提供數量大於或等於中央處理器需求量cpuAMTu_b*gpuREQ=cpuREQ_b=96個的中央處理器,和容量大於或等於記憶體需求量memAMTu_b*gpuREQ=memREQ_b=600G的記憶體。
假設排程器查詢電腦系統30後得知,在電腦系統30中,確實存在至少一個預選工作節點preND[n](n=1~N)可提供足夠數量的圖形處理器cGPU(圖形處理器數量gpuAVL[m]
Figure 111144588-A0305-02-0030-32
圖形處理器需求量gpuREQ=3)。則,在第二請求階段reqSTG2,排程器需進一步基於與圖形處理器cGPU對應之預設比率cRatio=1:8:1T和圖形處理器需求量gpuREQ=3,確認可提供足夠之圖形處理器cGPU的該至少一個預選工作節點preND[n](n=1~N)可否進一步提供數量大於或等於中央處理器需求量cpuAMTu_c*gpuREQ=cpuREQ_c=24個的中央處理器,和容量大於或等於記憶體需求量memAMTu_c*gpuREQ=memREQ_a=3T的記憶體。
另請留意,在前述實施例中,雖假設在各個工作節點ND[1]~ND[M]均僅提供單一類型的圖形處理器(例如,單獨提供圖形處理器aGPU、bGPU、cGPU)。惟,若電腦系統中的一個或多個工作節點同時包含不同類型的圖形處理器的情況時,前述的資源分配方法,亦可在略加修改後,應用於工作節點同時包含不同類型之圖形處理器aGPU、bGPU、cGPU的情況。
承上,根據本揭露的構想,當使用者usrX想依據圖形處理器的類型不同,配置數量不等的中央處理器和所需的記憶體時,根據本揭露構想的電腦系統與資源分配方法,能將使用者的容器集Pod綁定至最適當的具圖形處理器、中央處理器和記憶體的數量和組合。本揭露並可利用軟體程式執行前述的資源分配方法,並將軟體程式儲存於電腦程式產品上。
綜上所述,雖然本發明已以實施例揭露如上,然其並非用以限定本發明。本發明所屬技術領域中具有通常知識者,在不脫離 本發明之精神和範圍內,當可作各種之更動與潤飾。因此,本發明之保護範圍當視後附之申請專利範圍所界定者為準。
reqSTG1:第一請求階段
reqSTG2:第二請求階段
evaSTG:評估階段
outSTG1,outSTG2:輸出階段
assSTG:資源分配階段

Claims (11)

  1. 一種電腦系統,包含:M個工作節點,其中在該電腦系統接收一硬體資源請求時,該M個工作節點中的一第m個工作節點係包含gpuAVL[m]個可調度使用的圖形處理器、cpuAVL[m]個可調度使用的中央處理器,以及可調度使用之容量為memAVL[m]的記憶體;以及一控制平面,信號連接於各該M個工作節點,其係執行一排程器,其中該排程器係因應該硬體資源請求中的一圖形處理器需求量而自該M個工作節點中選取N個預選工作節點後,依據該硬體資源請求中的一中央處理器需求量與一記憶體需求量而自該N個預選工作節點中選取一者作為一目標工作節點後,於該目標工作節點執行該硬體資源請求,其中M、m為正整數、gpuAVL[m]、cpuAVL[m]、memAVL[m]、N為大於或等於0的整數、m小於或等於M,且N小於或等於M。
  2. 如請求項1所述之電腦系統,其中該排程器係依據該硬體資源請求中的該中央處理器需求量與該記憶體需求量而自該N個預選工作節點中,先選取P個候選節點後,再依據一排程策略而自該P個待評估節點選取該目標工作節點,其中P為大於或等於0的整數,且P小於或等於N。
  3. 如請求項2所述之電腦系統,其中,該圖形處理器需求量係指該使用者擬利用該電腦系統執行一容器集所需使用之圖形處理器的數量; 該中央處理器需求量係指該使用者擬利用該電腦系統執行該容器集所需使用之中央處理器的數量;且該記憶體需求量係指該使用者擬利用該電腦系統執行該容器集所需使用之記憶體的容量。
  4. 如請求項2所述之電腦系統,其中當該N個預選工作節點包含該第m個工作節點時,該第m個工作節點所提供之該gpuAVL[m]個可調度使用的圖形處理器的數量係大於或等於該圖形處理器需求量。
  5. 如請求項2所述之電腦系統,其中當該目標工作節點為該第m個工作節點時,該第m個工作節點所提供之該cpuAVL[m]個可調度使用的中央處理器的數量係大於或等於該中央處理器需求量,且該第m個工作節點所提供之該可調度使用且容量為memAVL[m]的記憶體的容量係大於或等於該記憶體需求量。
  6. 如請求項1所述之電腦系統,其中該硬體資源請求係紀錄於一組態映射中。
  7. 如請求項1所述之電腦系統,其中該排程器係在選取該N個預選工作節點前接收該圖形處理器需求量,並在選取該N個預選工作節點後接收該中央處理器需求量與該記憶體需求量。
  8. 如請求項1所述之電腦系統,其中該排程器係在選取該N個預選工作節點前接收該圖形處理器需求量、該中央處理器需求量與該記憶體需求量。
  9. 一種應用於一電腦系統的資源分配方法,包含以下步驟:提供M個工作節點,其中在該電腦系統接收一硬體資源請求時,該M個工作節點中的一第m個工作節點係包含gpuAVL[m]個可調度使用的圖形處理器、cpuAVL[m]個可調度使用的中央處理器,以及可調度使用之容量為memAVL[m]的記憶體;因應該硬體資源請求中的一圖形處理器需求量而自該M個工作節點中選取N個預選工作節點;以及依據該硬體資源請求中的一中央處理器需求量與一記憶體需求量而自該N個預選工作節點中選取一者作為一目標工作節點後,於該目標工作節點執行該硬體資源請求,其中M、m為正整數、gpuAVL[m]、cpuAVL[m]、memAVL[m]、N為大於或等於0的整數、m小於或等於M,且N小於或等於M。
  10. 如請求項9所述之資源分配方法,其中依據該硬體資源請求中的該中央處理器需求量與該記憶體需求量而自該N個預選工作節點中選取一者作為該目標工作節點之步驟係包含以下步驟:依據該硬體資源請求中的該中央處理器需求量與該記憶體需求量而自該N個預選工作節點中,選取P個待評估節點;以及, 依據一排程策略而自該P個待評估節點選取該目標工作節點,其中P為大於或等於0的整數,且P小於或等於N。
  11. 一種電腦程式產品,其上儲存有一軟體程式,該軟體程式執行時將使具有一控制平面之一電腦系統進行一資源分配方法,該資源分配方法包括下列步驟:提供M個工作節點,其中在該電腦系統接收一硬體資源請求時,該M個工作節點中的一第m個工作節點係包含gpuAVL[m]個可調度使用的圖形處理器、cpuAVL[m]個可調度使用的中央處理器,以及可調度使用之容量為memAVL[m]記憶體;因應該硬體資源請求中的一圖形處理器需求量而自該M個工作節點中選取N個預選工作節點;以及依據該硬體資源請求中的一中央處理器需求量與一記憶體需求量而自該N個預選工作節點中選取一者作為一目標工作節點後,於該目標工作節點執行該硬體資源請求,其中M、m為正整數、gpuAVL[m]、cpuAVL[m]、memAVL[m]、N為大於或等於0的整數、m小於或等於M,且N小於或等於M。
TW111144588A 2022-11-22 2022-11-22 電腦系統、應用於電腦系統的資源分配方法及執行資源分配方法的電腦程式產品 TWI826137B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
TW111144588A TWI826137B (zh) 2022-11-22 2022-11-22 電腦系統、應用於電腦系統的資源分配方法及執行資源分配方法的電腦程式產品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
TW111144588A TWI826137B (zh) 2022-11-22 2022-11-22 電腦系統、應用於電腦系統的資源分配方法及執行資源分配方法的電腦程式產品

Publications (2)

Publication Number Publication Date
TWI826137B true TWI826137B (zh) 2023-12-11
TW202422466A TW202422466A (zh) 2024-06-01

Family

ID=90053231

Family Applications (1)

Application Number Title Priority Date Filing Date
TW111144588A TWI826137B (zh) 2022-11-22 2022-11-22 電腦系統、應用於電腦系統的資源分配方法及執行資源分配方法的電腦程式產品

Country Status (1)

Country Link
TW (1) TWI826137B (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI553472B (zh) * 2010-12-20 2016-10-11 微軟技術授權有限責任公司 個人資料中心內的排程和管理
CN111552550A (zh) * 2020-04-26 2020-08-18 星环信息科技(上海)有限公司 一种基于图形处理器gpu资源的任务调度方法、设备及介质
CN111966500A (zh) * 2020-09-07 2020-11-20 网易(杭州)网络有限公司 资源调度方法、装置、电子设备及存储介质
TW202211065A (zh) * 2020-04-08 2022-03-16 南韓商三星電子股份有限公司 在包括網路鍵值客戶端及網路鍵值目標的網路鍵值儲存體中對鎖定請求進行協調的系統與方法以及包含指令的非暫時性電腦可讀取媒體
TW202227965A (zh) * 2020-12-21 2022-07-16 美商英特爾股份有限公司 用於服務等級遵循之有效率資源配置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI553472B (zh) * 2010-12-20 2016-10-11 微軟技術授權有限責任公司 個人資料中心內的排程和管理
TW202211065A (zh) * 2020-04-08 2022-03-16 南韓商三星電子股份有限公司 在包括網路鍵值客戶端及網路鍵值目標的網路鍵值儲存體中對鎖定請求進行協調的系統與方法以及包含指令的非暫時性電腦可讀取媒體
CN111552550A (zh) * 2020-04-26 2020-08-18 星环信息科技(上海)有限公司 一种基于图形处理器gpu资源的任务调度方法、设备及介质
CN111966500A (zh) * 2020-09-07 2020-11-20 网易(杭州)网络有限公司 资源调度方法、装置、电子设备及存储介质
TW202227965A (zh) * 2020-12-21 2022-07-16 美商英特爾股份有限公司 用於服務等級遵循之有效率資源配置

Also Published As

Publication number Publication date
TW202422466A (zh) 2024-06-01

Similar Documents

Publication Publication Date Title
CN115248728B (zh) 面向智能计算的分布式训练任务调度方法、系统和装置
CN110764901B (zh) 基于gpu资源的数据处理方法、电子设备及系统
US7945913B2 (en) Method, system and computer program product for optimizing allocation of resources on partitions of a data processing system
US8296771B2 (en) System and method for mapping between resource consumers and resource providers in a computing system
CN109564528B (zh) 分布式计算中计算资源分配的系统和方法
CN103279390B (zh) 一种面向小作业优化的并行处理系统
TWI747092B (zh) 資源調度方法、設備、系統及中心伺服器
CN113064712B (zh) 基于云边环境的微服务优化部署控制方法、系统及集群
CN108337109A (zh) 一种资源分配方法及装置和资源分配系统
JP2005534116A (ja) 複数の消費者をもつコンピュータシステムで資源を動的に割当てて管理する方法
CN109144710A (zh) 资源调度方法、装置及计算机可读存储介质
CN109992373B (zh) 资源调度方法、信息管理方法和装置及任务部署系统
CN112463390A (zh) 一种分布式任务调度方法、装置、终端设备及存储介质
WO2023000673A1 (zh) 硬件加速器设备管理方法、装置及电子设备和存储介质
CN104331332A (zh) 一种基于sla的虚拟资源预分配算法
WO2020108337A1 (zh) 一种cpu资源调度方法及电子设备
US20140351550A1 (en) Memory management apparatus and method for threads of data distribution service middleware
CN114968601A (zh) 一种按比例预留资源的ai训练作业的调度方法和调度系统
EP3994574A1 (en) Harvest virtual machine for utilizing cloud-computing resources
TWI826137B (zh) 電腦系統、應用於電腦系統的資源分配方法及執行資源分配方法的電腦程式產品
CN111796932A (zh) 一种gpu资源调度方法
CN116483547A (zh) 资源调度方法、装置、计算机设备和存储介质
CN116800846A (zh) 一种影视数据分布式管理方法
US10248459B2 (en) Operating system support for game mode
CN114860417A (zh) 多核神经网络处理器及用于该处理器多任务分配调度方法