CycleCloud GridEngine 叢集
在 Azure CycleCloud 叢集上修改 「run_list」,即可輕鬆地在 Azure CycleCloud 叢集上啟用方格排程器 (Grid Engine) 。 Grid Engine 叢集的兩個基本元件是 「主要」節點,提供格線引擎軟體執行所在的共用檔案系統,以及裝載共用檔案系統並執行所提交作業的「執行」節點。 例如,簡單的 Grid Engine 叢集範本程式碼片段可能如下所示:
[cluster grid-engine]
[[node master]]
ImageName = cycle.image.centos7
MachineType = Standard_A4 # 8 cores
[[[configuration]]]
run_list = role[sge_master_role]
[[nodearray execute]]
ImageName = cycle.image.centos7
MachineType = Standard_A1 # 1 core
[[[configuration]]]
run_list = role[sge_execute_role]
注意
角色名稱包含 'sge',因為舊版原因:Grid Engine 是 Sun Microsystems 的產品。
在 CycleCloud 中使用定義匯入和啟動叢集會產生單一「主要」節點。 您可以透過 cyclecloud add_node
命令將執行節點新增至叢集。 例如,若要新增 10 個更多執行節點:
cyclecloud add_node grid-engine -t execute -c 10
格線引擎自動調整
Azure CycleCloud 支援 Grid Engine 的自動調整,這表示軟體會監視佇列的狀態,並視需要開啟和關閉節點,以最佳時間/成本完成工作。 您可以新增 Autoscale = true
至叢集定義,以啟用 Grid Engine 的自動調整:
[cluster grid-engine]
Autoscale = True
根據預設,提交到 Grid Engine 佇列的所有作業都會在類型為 'execute' 的機器上執行,這些是由名為 'execute' 的節點陣列所定義的機器。 您不限於名稱 'execute',也不會限制為單一類型的電腦群組態來執行作業和自動調整。
例如,常見的案例可能是您有兩個不同節點定義的叢集,一個是執行使用標準 CPU 的「正常」作業,而另一種作業類型可能會使用 GPU 機器。 在此情況下,您會想要透過一般作業和 GPU 作業來獨立調整佇列,以確保您有適當的每部機器數量來取用工作佇列。 範例定義會像這樣:
[cluster grid-engine]
Autoscale = True
[[node master]]
ImageName = cycle.image.centos7
MachineType = Standard_A3 # 4 cores
[[[configuration]]]
run_list = role[sge_master_role]
[[nodearray execute]]
ImageName = cycle.image.centos7
MachineType = Standard_A4 # 8 cores
[[[configuration]]]
run_list = role[sge_execute_role]
[[nodearray gpu]]
MachineType = Standard_NV12 # 2 GPUs
ImageName = cycle.image.centos7
# Set the number of cores to the number of GPUs for autoscaling purposes
CoreCount = 2
[[[configuration]]]
run_list = role[sge_execute_role]
gridengine.slot_type = gpu
gridengine.slots = 2
在上述範例中,現在有兩個節點陣列:一個是「標準」執行節點陣列,第二個節點陣列名稱為 'gpu',提供在 Azure) 中具有兩個 Nvidia GPU (Standard_NV12的 MachineType。 另請注意,除了 'csge:sgeexec' 配方之外,組態區段中現在還有兩個新專案。 新增 gridengine.slot_type = gpu
會告訴 Grid Engine 排程器,這些節點應該命名為 'gpu' 節點,因此應該只執行 'gpu' 作業。 名稱 'gpu' 是任意名稱,但描述節點的名稱最實用。 設定 gridengine.slots = 2
,告知軟體確定這種類型的節點一次只能執行兩個作業, (Standard_NV12只有 2 個 GPU) 。 根據預設,Grid Engine 中每個節點的插槽數目將會是系統上 CPU 的數目,在此情況下,會導致節點上同時執行太多作業。 在上述範例中, CoreCount=2
會在 nodearray 上設定,以符合 MachineType 上可用的 GPU 數目,讓 CycleCloud 能夠在 GPU 與 CPU 計數上正確調整該陣列。
您可以執行 命令來確認機器具有的插槽數目和slot_type:
-bash-4.1# qstat -F slot_type
queuename qtype resv/used/tot. load_avg arch states
---------------------------------------------------------------------------------
all.q@ip-0A000404 BIP 0/0/4 0.17 linux-x64
hf:slot_type=execute
---------------------------------------------------------------------------------
all.q@ip-0A000405 BIP 0/0/2 2.18 linux-x64
hf:slot_type=gpu
---------------------------------------------------------------------------------
all.q@ip-0A000406 BIP 0/0/4 0.25 linux-x64
請注意,我們指定了其中一個「slot_type」, (執行和 gpu) ,而「執行」位置的插槽數目是 4,這是電腦上的 CPU 數目。 'gpu' 插槽類型的插槽數目是 2,我們在叢集組態範本中指定。 第三部電腦是不會執行作業的主要節點。
方格引擎進階使用方式
上述組態設定允許進階自訂節點和節點陣列。 例如,如果作業需要特定數量的記憶體,例如每個作業 10GB,您可以定義一個執行 nodearray 來啟動具有 60 GB 記憶體的電腦,然後新增組態選項 gridengine.slots = 6
,以確保只有 6 個作業可以在這種類型的節點上同時執行, (確保每個作業至少有 10 GB 的記憶體才能使用) 。
格線引擎中的群組節點
當平行作業提交至方格引擎時,CycleCloud 將使用的預設自動調整行為是將每個 MPI 作業視為群組節點要求。 群組節點緊密結合,最適合 MPI 工作流程。
當一組群組節點聯結 Grid Engine 叢集時,會使用每個節點的群組識別碼做為複雜值 的值 affinity_group
。 藉由要求為作業指定 , affinity_group
它可讓 Grid Engine 排程器確保工作只落在相同群組中的機器上。
CycleCloud 的自動化會自動要求已分組的節點,並在遇到平行作業時將它們指派給可用的同質群組。
將作業提交至方格引擎
將作業提交至 Grid Engine 排程器的最一般方式是命令:
qsub my_job.sh
此命令會提交將在類型為 'execute' 的節點上執行的作業,這是 nodearray 'execute' 所定義的節點。 若要讓作業在不同類型的 nodearray 上執行,例如上述 'gpu' 節點類型,我們會修改我們的提交:
qsub -l slot_type=gpu my_gpu_job.sh
此命令可確保作業只會在 'gpu' 的 'slot_type' 上執行。
如果省略slot_type,則會自動將 'execute' 指派給作業。 使用者可以修改自動將slot_type指派給作業的機制。 您可以建立位於 /opt/cycle/jetpack/config/autoscale.py 的 Python 腳本,其應該定義單一函式 「sge_job_handler」。 此函式會接收作業的字典標記法,類似于命令的 qstat -j JOB_ID
輸出,而且應該傳回需要更新作業之硬式資源的字典。 例如,下列腳本會在作業名稱包含字母 'gpu' 時,將作業指派給 'gpu' slot_type。 這可讓使用者從自動化系統提交其作業,而不需要修改作業參數,而且作業仍會在 上執行,並自動調整正確的節點:
#!/usr/env python
#
# File: /opt/cycle/jetpack/config/autoscale.py
#
def sge_job_handler(job):
# The 'job' parameter is a dictionary containing the data present in a 'qstat -j JOB_ID':
hard_resources = {'slot_type': 'execute', 'affinity_group' : 'default' }
# Don't modify anything if the job already has a slot type
# You could modify the slot type at runtime by not checking this
if 'hard_resources' in job and 'slot_type' in job['hard_resources']:
return hard_resources
# If the job's script name contains the string 'gpu' then it's assumed to be a GPU job.
# Return a dictionary containing the new job_slot requirement to be updated.
# For example: 'big_data_gpu.sh' would be run on a 'gpu' node.
if job['job_name'].find('gpu') != -1:
hard_resources {'slot_type': 'gpu'}
else:
return hard_resources
傳入的參數 'job' 是包含呼叫中 qstat -j JOB_ID
資料的字典:
{
"job_number": 5,
"job_name": "test.sh",
"script_file": "test.sh",
"account": "sge",
"owner": "cluster.user",
"uid": 100,
"group": "cluster.user",
"gid": 200,
"submission_time": "2013-10-09T09:09:09",
"job_args": ['arg1', 'arg2', 'arg3'],
"hard_resources": {
'mem_free': '15G',
'slot_type': 'execute'
}
}
您可以使用此腳本功能,根據作業中定義的任何參數自動指派slot_type,例如引數、其他資源需求,例如記憶體、提交使用者等等。
如果您要提交每個「slot_type」的 5 個作業:
qsub -t 1:5 gpu_job.sh
qsub -t 1:5 normal_job.sh
佇列中現在會有 10 個作業。 由於上述定義的腳本,名稱中有 'gpu' 的五個作業會自動設定為只在 'slot_type=gpu' 的節點上執行。 CycleCloud 自動調整機制會偵測到有 5 個 「gpu」作業和 5 個「執行」作業。 由於 'gpu' nodearray 定義為每個節點有 2 個位置,所以 CycleCloud 會啟動 3 個節點, (5/2=2.5 四捨五入到 3) 。 有 5 個正常作業,因為「執行」節點陣列的電腦類型各有 4 個 CPU,CycleCloud 會啟動 2 個節點來處理 (5/4=1.25 四捨五入到 2 個) 。 在短時間內,新啟動的節點要開機和設定之後,所有 10 個作業都會執行完成,然後 5 個節點會自動關閉,再由雲端提供者再次計費。
作業假設持續時間為一小時。 如果作業執行時間已知,自動調整演算法可以受益于這項資訊。 將它新增至作業內容,以通知預期的作業執行時間自動調整。 下列範例會告訴自動調整作業執行時間平均為 10 分鐘:
qsub -ac average_runtime=10 job_with_duration_of_10m.sh
方格引擎組態參考
以下是您可以切換以自訂功能的方格引擎特定組態選項:
SGE-Specific組態選項 | Description |
---|---|
gridengine.slots | 要向 Grid Engine 回報之指定節點的插槽數目。 位置數目是節點可執行檔並行作業數目,此值預設為指定電腦上的 CPU 數目。 在未根據 CPU 但記憶體、GPU 等執行作業的情況下,您可以覆寫此值。 |
gridengine.slot_type | 節點提供的 'slot' 類型名稱。 預設值為 'execute'。 當作業以硬式資源 'slot_type=' 標記時,該作業 只會 在相同位置類型的電腦上執行。 這可讓您為每個節點建立不同的軟體和硬體組態,並確保適當作業一律排程在正確的節點類型上。 |
gridengine.ignore_fqdn | 預設:True。 如果叢集中的所有節點不是單一 DNS 網域的一部分,請將 設定為 false。 |
gridengine.version | 預設值:'2011.11'。 這是要安裝和執行的 Grid Engine 版本。 這是目前預設且 唯一 的選項。 未來可能會支援其他版本的 Grid Engine 軟體。 |
gridengine.root | 預設值:'/sched/sge/sge-2011.11' 這是格線引擎將安裝在系統上的每個節點上並掛接的位置。 建議您不要變更此值,但如果此值應該設定為叢集中 每個 節點上的相同值,則為 。 |
CycleCloud 支援跨排程器的標準自動停止屬性集:
屬性 | 描述 |
---|---|
cyclecloud.cluster.autoscale.stop_enabled | 此節點上是否已啟用自動停止功能? [true/false] |
cyclecloud.cluster.autoscale.idle_time_after_jobs | 節點在相應減少之前完成作業之後,) 以秒為單位的時間量 (閒置。 |
cyclecloud.cluster.autoscale.idle_time_before_jobs | 節點在相應減少作業之前,) 以秒為單位 (的時間量。 |
已知問題
-
qsh
互動式會話的 命令無法運作。 使用qrsh
做為替代方案。 - 自動
exclusive=1
調整不會遵守複雜專案。 比預期少的節點可能會因為結果而啟動。
注意
雖然 Windows 是正式支援的 GridEngine 平臺,但 CycleCloud 目前不支援在 Windows 上執行 GridEngine。
此頁面涉及搭配 CycleCloud 使用 (Altair) GridEngine 的功能和設定。
設定資源
cyclecloud-gridengine 應用程式會比對 sge 資源與 Azure 雲端資源,以提供豐富的自動調整和叢集設定工具。 應用程式將會針對透過 CycleCloud UI 建立的叢集自動部署,也可以安裝在現有叢集上的任何 gridengine 系統管理主機上。
安裝或升級 cyclecloud-gridengine
cyclecloud-gridengine 套件組合可在 github 中作為發行成品使用。 安裝和升級的程式會相同。 應用程式需要具有 virtualenv 的 python3。
tar xzf cyclecloud-gridengine-pkg-*.tar.gz
cd cyclecloud-gridengine
./install.sh
重要檔案
應用程式會在每次呼叫 時剖析 sge 組態 - 作業、佇列、複雜專案。 命令的 stderr 和 stdout 以及可設定層級的記錄檔中會提供資訊。 所有具有引數的 gridengine 管理命令也會記錄到檔案中。
Description | 位置 |
---|---|
自動調整設定 | /opt/cycle/gridengine/autoscale.json |
自動調整記錄檔 | /opt/cycle/jetpack/logs/autoscale.log |
qconf 追蹤記錄 | /opt/cycle/jetpack/logs/qcmd.log |
SGE 佇列、主機群組和平行環境
cyclecloud-gridengine 自動調整公用程式 azge
會根據叢集組態將主機新增至叢集。 自動調整作業會執行下列動作。
- 讀取作業資源要求,並尋找要啟動的適當 VM
- 啟動 VM 並等候 VM 就緒
- 從作業讀取佇列和平行環境
- 根據佇列/pe 將主機指派給適當的主機群組
- 將主機新增至叢集以及包含主機群組的任何其他佇列
針對名為short.q的佇列,請考慮下列佇列定義
hostlist @allhosts @mpihg01 @mpihg02 @lowprio
...
seq_no 10000,[@lowprio=10],[@mpihg01=100],[@mpihg02=200]
pe_list NONE,[@mpihg01=mpi01], \
[@mpihg02=mpi02]
提交作業時 qsub -q short.q -pe mpi02 12 my-script.sh
,會從租用一部 VM 開始,並在它新增至叢集時加入主機群組 @mpihg02 ,因為這是佇列和平行環境的主機群組。 它也會新增至 @allhosts,這是特殊的主機群組。
若未指定 pe, qsub -q short.q my-script.sh
產生的 VM 將會新增至@allhosts,@lowpriority這些是佇列中未指派 pes 的主機群組。
最後,使用 提交的 qsub -q short.q -pe mpi0* 12 my-script.sh
作業會導致 VM 新增至 @mpihg01 或 @mpihg02 ,視 CycleCloud 配置預測而定。
平行環境會隱含地等於 cyclecloud 放置群組。 PE 中的 VM 受限於相同網路內。 如果您想要使用不會保留放置群組的 PE,請使用 autoscale.json 退出宣告。
在這裡,我們退出宣告放置 群組以進行 pe :
"gridengine": {
"pes": {
"make": {
"requires_placement_groups": false
}
},
CycleCloud 放置群組
CycleCloud 放置群組會使用 SinglePlacementGroup 將一對一對應至 Azure VMSS - placementgroup 中的 VM 會共用 Infiniband Fabric,並只與放置群組內的 VM 共用。 為了以直覺方式保留這些定址接收器,放置群組也會對應 1:1 與格線平行環境。
指定作業的平行環境將會限制作業透過智慧主機群組指派邏輯在放置群組中執行。 您可以使用 autoscale.json 中的上述組態退出宣告此行為: "required_placement_groups" : false
。
自動調整設定
此外掛程式會自動調整格線,以符合工作負載的需求。 autoscale.json組態檔會決定 Grid Engine 自動調整程式的行為。
- 設定 cyclecloud 連線詳細資料
- 設定閒置節點的終止計時器
- 可以進行多維度自動調整,設定作業封裝中要使用的屬性,例如位置、記憶體
- 註冊要管理的佇列、平行環境和主機群組
設定 | 類型 | Description |
---|---|---|
url | String | 副本 URL |
username/password | String | CC 連線詳細資料 |
cluster_name | String | CC 叢集名稱 |
default_resources | 對應 | 將節點資源連結至自動調整的 Grid Engine 主機資源 |
idle_timeout | Int | 在終止閒置節點 () 之前等候時間 |
boot_timeout | Int | 在長時間設定階段終止節點之前,等候時間 () |
gridengine.relevant_complexes | 列出字串) ( | 在自動調整中考慮的格線引擎複雜專案,例如位置、mem_free |
gridengine.logging | 檔案 | 記錄設定檔的位置 |
gridengine.pes | 結構 | 指定 PE 的行為,例如 requires_placement_group = false |
自動調整程式只會考慮 相關資源
其他自動調整資源
根據預設,根據作業要求多少位置,具有縮放比例的叢集。 我們可以新增另一個維度來自動調整。
假設我們想要依 的作業資源要求 m_mem_free
自動調整。
- 在autoscale.json中新增
m_mem_free
至gridengine.relevant_resources
- 在autoscale.json中連結
m_mem_free
至節點層級記憶體資源
這些屬性可以使用 作為 _default/resources中的值來參考 node.*
。
節點 | 類型 | Description |
---|---|---|
nodearray | String | cyclecloud nodearray 的名稱 |
placement_group | String | nodearray 內的 cyclecloud 放置群組名稱 |
vm_size | String | VM 產品名稱,例如 「Standard_F2s_v2」 |
vcpu_count | Int | 節點上可用的虛擬 CPU,如個別產品頁面上所示 |
pcpu_count | Int | 節點上可用的實體 CPU |
記憶體 | String | VM 中可用的近似實體記憶體,單位指標,例如 「8.0g」 |
其他屬性位於 命名空間中 node.resources.*
,例如 'node.resources。
節點 | 類型 | Description |
---|---|---|
ncpus | String | VM 中可用的 CPU 數目 |
pcpus | String | VM 中可用的實體 CPU 數目 |
ngpus | 整數 | VM 中可用的 GPU 數目 |
memb | String | VM 中可用的近似實體記憶體,單位指標,例如 「8.0b」 |
memkb | String | VM 中可用的近似實體記憶體,單位指標,例如 「8.0k」 |
memmb | String | VM 中可用的近似實體記憶體,單位指標,例如 「8.0m」 |
memgb | String | VM 中可用的近似實體記憶體,單位指標,例如 「8.0g」 |
memtb | String | VM 中可用的近似實體記憶體,單位指標,例如 「8.0t」 |
slots | 整數 | 與 ncpus 相同 |
slot_type | String | 延伸模組的加法標籤。 通常不會使用。 |
m_mem_free | String | 執行主機上預期的可用記憶體,例如 「3.0g」 |
mfree | String | 與 _m/_mem/free相同 |
資源對應
default_resources也有可用的數學運算 - 將特定節點陣列上的位置減少兩個,並將 Docker 資源新增至所有節點:
"default_resources": [
{
"select": {"node.nodearray": "beegfs"},
"name": "slots",
"value": "node.vcpu_count",
"subtract": 2
},
{
"select": {},
"name": "docker",
"value": true
},
將節點 vCPU 對應至複雜位置,而且 memmb
mem_free
通常會使用預設值。
第一個關聯是必要的。
"default_resources": [
{
"select": {},
"name": "slots",
"value": "node.vcpu_count"
},
{
"select": {},
"name": "mem_free",
"value": "node.resources.memmb"
}
],
請注意,如果複本的快捷方式不等於整個值,請在 default_resources 中定義兩者,其中 physical_cpu
是複雜名稱:
"default_resources": [
{
"select": {},
"name": "physical_cpu",
"value": "node.pcpu_count"
},
{
"select": {},
"name": "pcpu",
"value": "node.resources.physical_cpu"
}
]
當您想要特定屬性的特定行為時,排序很重要。 若要為特定 nodearray 配置單一位置,同時保留所有其他 nodearray 的預設位置計數:
"default_resources": [
{
"select": {"node.nodearray": "FPGA"},
"name": "slots",
"value": "1",
},
{
"select": {},
"name": "slots",
"value": "node.vcpu_count"
},
]
主機群組
CycleCloud 自動調整程式嘗試滿足作業需求時,會將節點對應至適當的主機群組。 佇列、平行環境和複雜專案全都會考慮。 大部分邏輯都符合適當的 cyclecloud 貯體 (和節點數量,) 適當的 sge 主機群組。
針對提交為: qsub -q "cloud.q" -l "m_mem_free=4g" -pe "mpi*" 48 ./myjob.sh
CycleCloud 會找到主機群組的交集,其中:
- 包含在cloud.q的pe_list中,並符合 pe 名稱,例如 。
pe_list [@allhosts=mpislots],[@hpc1=mpi]
- 有足夠的資源和訂用帳戶配額,以提供所有作業資源。
- 不會依主機群組條件約束組態進行篩選。
可能會有多個主機群組符合這些需求,在此情況下,邏輯將需要選擇。 有三種方式可以解決主機群組成員資格中的模棱兩可:
- 設定佇列,使其沒有模棱兩可。
- 將條件約束新增至 autoscale.json。
- 讓 CycleCloud 藉由在排程器組態中調整
weight_queue_host_sort < weight_queue_seqno
,以名稱排序的方式選擇最相符的主機群組。 - 在佇列組態中設定
seq_no 10000,[@hostgroup1=100],[@hostgroup2=200]
,以指出主機群組喜好設定。
主機群組條件約束
當佇列或 xproject 定義多個主機群組時,所有這些主機群組都可能會將主機新增至其中。 您可以藉由設定主機群組條件約束,限制可以新增至哪些佇列的主機類型。 根據節點屬性設定條件約束。
"gridengine": {
"hostgroups": {
"@mpi": {
"constraints": {
"node.vm_size": "Standard_H44rs"
}
},
"@amd-mem": {
"constraints" : {
"node.vm_size": "Standard_D2_v3",
"node.nodearray": "hpc"
}
},
}
}
提示:依 檢查所有可用的節點屬性
azge buckets
。
azge
此套件隨附命令列 azge。 此程式應該用來執行自動調整,並已細分自動調整下的所有子進程。
這些命令依賴要設定的 gridengine 環境變數 - 您必須能夠呼叫和從呼叫的相同設定檔 azge
呼叫 qconf
和 qsub
。
azge 命令 | Description |
---|---|
validate | 檢查自動調整程式或 gridengine 中的已知組態錯誤 |
jobs | 顯示佇列中的所有作業 |
貯體 | 顯示自動調整的可用資源集區 |
nodes | 顯示叢集主機和屬性 |
demand | 符合迴圈雲端貯體的工作需求,並提供自動調整結果 |
自動調整 | 根據組態執行完整自動調整、啟動和移除節點 |
修改排程器組態 (qconf) 或自動調整組態 (autoscale.json) ,或甚至第一次設定時, azge 可用來檢查自動調整行為是否符合預期。 身為根目錄,您可以執行下列作業。 建議您熟悉這些動作,以瞭解自動調整行為。
- 執行
azge validate
以確認已知問題的設定。 - 執行
azge buckets
以檢查 CycleCloud 叢集提供哪些資源。 - 執行
azge jobs
以檢查已排入佇列的作業詳細資料。 - 執行
azge demand
執行作業以符合貯體比對,檢查哪些作業符合哪些貯體和主機群組。 - 執行
azge autoscale
以啟動節點配置程式,或新增準備好加入的節點。
然後,當這些命令如預期般運作時,請將 命令新增 azge autoscale
至根 crontab,以啟用進行中的自動調整。 (souce gridengine 環境變數)
* * * * * . $SGE_ROOT/common/settings.sh && /usr/local/bin/azge autoscale -c /opt/cycle/gridengine/autoscale.json
建立混合式叢集
CycleCloud 將支援高載至雲端的案例。 基底組態假設 $SGE_ROOT
目錄可供雲端節點使用。 藉由在本機設定 gridengine.shared.spool = false
和 gridengine.shared.bin = false
安裝 GridEngine,即可放寬此假設。
針對簡單的案例,您應該提供檔案系統,該檔案系統可由包含 $SGE_ROOT
目錄的執行節點掛接,並在選擇性設定中設定掛接。 發行 sched 和共用目錄的相依性時,您可以關閉預設屬於叢集一部分的排程器節點,並使用來自外部檔案系統的組態。
- 建立新的 gridengine 叢集。
- 停用傳回 Proxy。
- 以外部檔案系統取代 /sched 和 /shared 。
- 儲存叢集。
- 移除排程器節點作為 UI 中的動作。
- 啟動叢集,一開始不會啟動任何節點。
- 使用
cyclecloud-gridengine
autoscale.json 設定以使用新的叢集
在 CycleCloud 中使用 Univa Grid Engine
GridEngine 的 CycleCloud 專案預設會使用 sge-2011.11 。 您可以根據 Altair 授權合約使用自己的 Altair GridEngine 安裝程式。
本節說明如何搭配 CycleCloud GridEngine 專案使用 Altair GridEngine。
必要條件
此範例將使用 8.6.1-demo 版本,但支援所有 ge > 8.4.0 版。
- 使用者必須提供 UGE 二進位檔
- ge-8.6.x-bin-lx-amd64.tar.gz
- ge-8.6.x-common.tar.gz
- 必須設定 CycleCloud CLI。 檔可在這裡取得
將二進位檔複製到雲端保險箱
AGE (8.6.7-demo) 的互補版本會與 CycleCloud 一起散發。 若要使用另一個版本,請將二進位檔上傳至 CycleCloud 所使用的儲存體帳戶。
$ azcopy cp ge-8.6.12-bin-lx-amd64.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/
$ azcopy cp ge-8.6.12-common.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/
修改叢集範本的組態
製作 gridengine 範本的本機複本,並將其修改為使用 UGE 安裝程式,而不是預設值。
wget https://raw.githubusercontent.com/Azure/cyclecloud-gridengine/master/templates/gridengine.txt
在 gridengine.txt 檔案中,找出第一個出現的 [[[configuration]]]
並插入文字,使其符合下列程式碼片段。 此檔案不區分縮排。
注意:組態中的詳細資料,特別是版本應該符合安裝程式檔案名。
[[[configuration gridengine]]]
make = ge
version = 8.6.12-demo
root = /sched/ge/ge-8.6.12-demo
cell = "default"
sge_qmaster_port = "537"
sge_execd_port = "538"
sge_cluster_name = "grid1"
gid_range = "20000-20100"
qmaster_spool_dir = "/sched/ge/ge-8.6.12-demo/default/spool/qmaster"
execd_spool_dir = "/sched/ge/ge-8.6.12-demo/default/spool"
spooling_method = "berkeleydb"
shadow_host = ""
admin_mail = ""
idle_timeout = 300
managed_fs = true
shared.bin = true
ignore_fqdn = true
group.name = "sgeadmin"
group.gid = 536
user.name = "sgeadmin"
user.uid = 536
user.gid = 536
user.description = "SGE admin user"
user.home = "/shared/home/sgeadmin"
user.shell = "/bin/bash"
這些設定會在叢集啟動時覆寫預設方格引擎版本和安裝位置。
移出 /sched
並不安全,因為它是叢集中特別共用的 nfs 位置。