Open Grid Scheduler (Grid Engine) は、クラスター定義の "run_list" を変更することで、Azure CycleCloud クラスターで簡単に有効にすることができます。 グリッド エンジン クラスターは、2 つの主要なコンポーネントで構成されます。 1 つ目は、グリッド エンジン ソフトウェアが実行される共有ファイル システムを提供する "マスター" ノードです。 2 つ目は、共有ファイルシステムをマウントし、送信されたジョブを実行するホストである "execute" ノードのセットです。 たとえば、単純な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
Grid Engine の自動スケーリング
Azure CycleCloud では、グリッド エンジンの自動スケールがサポートされています。 この動作は、ソフトウェアがキューの状態を継続的に監視し、必要に応じてノードを自動的にオンまたはオフにして、時間とコストの両方の観点からワークロードを効率的に完了することを意味します。 クラスター定義に Autoscale = true
を追加することで、Grid Engine の自動スケーリングを有効にすることができます:
[cluster grid-engine]
Autoscale = True
既定では、グリッド エンジン キューに送信されたすべてのジョブは、種類が "execute" のマシンで実行されます。 これらのマシンは、"execute" という名前のノード配列によって定義されます。 "execute" という名前に限定されるものではなく、ジョブを実行して自動スケールする単一の種類のコンピューター構成に限定することもありません。
たとえば、一般的なシナリオでは、2 つの異なるノード定義を持つクラスターが含まれます。 1 つは、標準 CPU を使用する "通常の" ジョブを実行するように設計されています。 もう 1 つは、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
この例では、次の 2 つのノード配列があります。1 つは "standard" 実行ノード配列、2 つ目は 2 つの NVIDIA GPU (Azure でStandard_NV12) を持つ MachineType を提供する "gpu" という名前です。 また、構成セクションには、'csge:sgeexec' レシピ以外に 2 つの新しい項目があることにも注意してください。
gridengine.slot_type = gpu
を追加すると、Grid Engine スケジューラに対して、これらのノードには 'gpu' ノードという名前を付ける必要があるため、'gpu' ジョブのみを実行する必要があることを示します。 名前 'gpu' は任意ですが、ノードを記述する名前が最も役立ちます。
gridengine.slots = 2
を設定すると、この種類のノードで一度に 2 つのジョブのみを実行できることを確認するようにソフトウェアに指示されます (Standard_NV12 GPU は 2 つのみです)。
既定では、グリッド エンジンは、システムの CPU 数に基づいてノードあたりのスロット数を割り当てます。 この場合、その既定の動作により、1 つのノードで同時に実行されるジョブが多すぎる可能性があります。 次に示す例では、machineType で使用可能な GPU の数と一致するように nodearray に CoreCount=2
が設定されているため、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' に 'execute' と 'gpu' が指定されていることに注意してください。 slot_typesは個別に構成され、"execute" スロットのスロット数は 4 です。これはマシン上の CPU の数です。 'gpu' スロットの種類のスロット数は 2 で、クラスター構成テンプレートで指定しました。 3 番目のマシンは、ジョブを実行しないマスター ノードです。
Grid Engine の高度な使用
これらの構成設定により、ノードとノード配列の高度なカスタマイズが可能になります。 たとえば、ジョブに特定の量のメモリ (たとえば、それぞれ 10 GB) が必要な場合は、60 GB のメモリを持つマシンを起動する nodearray の実行を定義し、構成オプション gridengine.slots = 6
を追加して、この種類のノードで同時に実行できるジョブが 6 個だけになるようにします (各ジョブで動作するメモリが少なくとも 10 GB であることを確認します)。
Grid Engine のグループ化されたノード
並列ジョブがグリッド エンジンに送信されると、CycleCloud が各 MPI ジョブをグループ化されたノード要求として処理するために使用する既定の自動スケーリング動作。 グループ化されたノードは緊密に結合され、MPI ワークフローに最適です。
グループ化されたノードのセットがグリッド エンジン クラスターに参加すると、各ノードのグループ ID が affinity_group
複合値の値として使用されます。 ジョブに対して affinity_group
を指定する必要があるため、Grid Engine スケジューラは、ジョブが同じグループ内のマシンにのみ配置されるようにすることができます。
CycleCloud の自動化により、並列ジョブが発生したときに、グループ化されたノードが自動的に要求され、使用可能なアフィニティ グループに割り当てられます。
Grid Engine へのジョブの送信
Grid Engine スケジューラにジョブを送信する最も一般的な方法は、次のコマンドです:
qsub my_job.sh
このコマンドは、"execute" 型のノード (nodearray 'execute' によって定義されたノード) で実行されるジョブを送信します。 示されている 'gpu' ノードの種類など、異なる種類の nodearray でジョブを実行するには、送信を変更します:
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" が含まれる 5 つのジョブは、'slot_type=gpu' のノードでのみ実行されるように自動的に構成されます。 CycleCloud 自動スケーリング メカニズムでは、5 つの 'gpu' ジョブと 5 つの 'execute' ジョブがあることを検出します。 'gpu' nodearray はノードあたり 2 つのスロットを持つものとして定義されているため、CycleCloud はこれらのノードのうち 3 つを開始します (5/2= 2.5 は 3 に切り上げられます)。
通常のジョブが5つあるため、「execute」ノードアレイのマシンタイプはそれぞれ4つのCPUを備えており、CycleCloudはこのジョブを処理するために、これらのノードのうち2つを開始します(5/4=1.25は2に切り上げられます)。 短い起動期間の後で、新しく起動されたノードが自身を構成します。 準備ができたら、10 個のジョブすべてが完了まで実行されます。 その後、クラウド プロバイダーで別の課金サイクルが開始される前に、5 つのノードが自動的にシャットダウンされます。
ジョブの期間は 1 時間と見なされます。 ジョブ ランタイムがわかっている場合は、自動スケーリング アルゴリズムでこの情報を利用できます。 予想されるジョブの実行時間をジョブのコンテキストに追加して、それを自動スケーリングに通知します。 次の例では、自動スケーリングのジョブ ランタイムを 10 分に設定します。
qsub -ac average_runtime=10 job_with_duration_of_10m.sh
Grid Engine 構成リファレンス
機能をカスタマイズするために切り替えることができる Grid Engine 固有の構成オプションを次に示します:
SGE 固有の構成オプション | 説明 |
---|---|
gridengine.slots | Grid Engine に報告する特定のノードのスロット数。 スロットの数は、ノードが実行できる同時実行ジョブの数です。この値の既定値は、特定のマシン上の CPU の数です。 CPU に基づいてジョブを実行せず、メモリや GPU などでジョブを実行する場合は、この値をオーバーライドできます。 |
gridengine.slot_type | ノードが提供する 'slot' の種類の名前。 既定値は 'execute' です。 ジョブがハード リソース 'slot_type=' でタグ付けされている場合、そのジョブは同じスロットタイプのマシン でのみ 実行されます。 このタグ付けにより、ノードごとに異なるソフトウェア構成とハードウェア構成を作成し、適切なジョブが常に適切な種類のノードでスケジュールされるようにすることができます。 |
gridengine.ignore_fqdn | 既定値: true。 クラスター内のすべてのノードが 1 つの DNS ドメインに含まれていない場合は false に設定します。 |
gridengine.version | 既定値: '2011.11'。 この構成オプションは、インストールして実行するグリッド エンジンのバージョンを指定します。 現時点では、これは既定のオプションであり、 使用可能な唯一 のオプションです。 他のバージョンの Grid Engine ソフトウェアは、今後サポートされる可能性があります。 |
gridengine.root | 既定値: '/sched/sge/sge-2011.11' この場所は、グリッド エンジンがシステム内の各ノードにインストールおよびマウントする場所です。 この値は変更せずにおくことをお勧めします。 ただし、変更する場合は、クラスター 内のすべての ノードで同じ値を設定してください。 |
CycleCloud では、スケジューラ全体でオートストップ属性の標準セットがサポートされています。
特性 | 説明 |
---|---|
cyclecloud.cluster.autoscale.stop_enabled | このノードで自動停止は有効になっていますか? [真/偽] |
cyclecloud.cluster.autoscale.idle_time_after_jobs | ノードがスケールダウンされるまでのジョブの完了後にアイドル状態になるまでの時間 (秒単位)。 |
cyclecloud.cluster.autoscale.ジョブ前待機時間 | ノードがスケールダウンされるまで、ジョブを完了する前にアイドル状態である時間(秒単位)。 |
既知の問題
-
qsh
対話型セッションのコマンドが機能しません。 代わりにqrsh
を使用します。 - 自動スケールでは、複雑な
exclusive=1
が考慮されないため、開始するノードの数が予想よりも少なくなる可能性があります。
注
Windows は公式にサポートされている GridEngine プラットフォームですが、現在、CycleCloud は Windows での GridEngine の実行をサポートしていません。
このページでは、CycleCloud で (Altair) GridEngine を使用する機能と構成について説明します。
リソースの構成
cyclecloud-gridengine アプリケーションは、リソースを 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 管理コマンドもファイルに記録されます。
説明 | 場所 |
---|---|
自動スケーリングの構成 | /opt/cycle/gridengine/autoscale.json |
自動スケーリング ログ | /opt/cycle/jetpack/logs/autoscale.log |
qconf トレース ログ | /opt/cycle/jetpack/logs/qcmd.log |
SGE キュー、ホスト グループ、および並列環境
cyclecloud-gridengine 自動スケーリング ユーティリティ azge
、クラスター構成に従ってクラスターにホストを追加します。 自動スケーリング操作では、次のアクションが実行されます。
- ジョブ リソース要求を読み取り、開始する適切な VM を見つけます
- VM を起動し、準備が整うのを待ちます
- ジョブからキューと並列環境を読み取ります
- queue/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
によるジョブの送信は、1 つの VM をリースすることから始まります。 クラスターが追加されると、 @mpihg02 ホスト グループが参加します。これは、キューと並列環境の両方で使用できるホスト グループであるためです。 また、特別なホスト グループ @allhosts参加します。
qsub -q short.q my-script.sh
でジョブを送信して並列環境 pe を指定しない場合、結果として該当する VM は@allhostsおよび@lowpriorityホストグループに参加し、pes が割り当てられていないキューにリンクされます。
最後に、 qsub -q short.q -pe mpi0* 12 my-script.sh
で送信されたジョブにより、CycleCloud の割り当て予測に応じて VM が@mpihg01 または @mpihg02 に追加されます。
並列環境は、暗黙的に CycleCloud 配置グループに相当します。 PE 内の VM は、同じネットワーク内に存在するように制限されます。 配置グループを保持しない PE を使用する場合は、autoscale.json を使用してオプトアウトします。
ここでは、make pe の配置グループをオプトアウトします。
"gridengine": {
"pes": {
"make": {
"requires_placement_groups": false
}
},
CycleCloud 配置グループ
CycleCloud 配置グループは、SinglePlacementGroup を使用して Azure VMSS に 1 対 1 でマップします。配置グループ内の VM は Infiniband Fabric を共有し、配置グループ内の VM とのみ共有します。 これらのサイロを直感的に維持するために、この配置グループでは gridengine の並列環境とも 1 対 1 でマップします。
ジョブの並列環境を指定すると、スマート ホスト グループの割り当てロジックを使用して配置グループで実行するジョブが制限されます。 この動作は、autoscale.json: の対応する構成を使用して無効にすることができます。
自動スケーリングの構成
このプラグインは、ワークロードの需要に合わせてグリッドを自動的にスケーリングします。 autoscale.json 構成ファイルは、Grid Engine 自動スケーラーの動作を決定します。
- CycleCloud 接続の詳細を設定する
- アイドル状態のノードの終了タイマーを設定する
- 多次元自動スケーリングが可能で、ジョブのパッキングで使用する属性 (スロット、メモリなど) を設定できます
- 管理するキュー、並列環境、およびホスト グループを登録する
コンフィギュレーション | タイプ | 説明 |
---|---|---|
URL | 糸 | CC URL |
ユーザー名/パスワード | 糸 | CC 接続の詳細 |
クラスター名 | 糸 | CC クラスター名 |
デフォルトリソース | 地図 | ノード リソースを自動スケーリング用の Grid Engine ホスト リソースにリンクする |
idle_timeout | 整数 | アイドル状態のノードが終了されるまでの待機時間 (秒) |
ブートタイムアウト | 整数 | 長い構成フェーズ中にノードを終了するまでの待機時間 |
グリッドエンジン.関連コンプレックス | リスト (文字列) | 自動スケールで考慮するグリッド エンジンの複雑さ (スロット、mem_freeなど) |
gridengine.logging | ファイル | ログ記録構成ファイルの場所 |
gridengine.pes | 構造体 | PE の動作を指定します (例: requires_placement_group = false) |
自動スケール プログラムでは、関連リソースのみが考慮されます
別のオートスケーリング リソース
既定では、ジョブは多数のスロットを要求し、クラスターはこれらの要求に基づいてスケーリングします。
たとえば、m_mem_free
のジョブ リソース要求によって自動スケーリングを行うとします。
- autoscale.json の
m_mem_free
にgridengine.relevant_resources
を追加する -
m_mem_free
を autoscale.json のノード レベルのメモリ リソースにリンクする
これらの属性は、_default/resources の値として node.*
で参照できます。
ノード | タイプ | 説明 |
---|---|---|
ノードアレイ | 糸 | cyclecloud nodearray の名前 |
placement_group | 糸 | ノード配列内の CycleCloud 配置グループの名前 |
vm_size | 糸 | VM の製品名 (例: "Standard_F2s_v2" |
vcpu_count | 整数 | 個々の製品ページで示されているように、ノードで使用可能な仮想 CPU |
pcpu_count | 整数 | ノードで使用可能な物理 CPU |
メモリ | 糸 | ユニット インジケーター (例: "8.0g") を使用して VM で使用可能な物理メモリの概算 |
その他の属性は、 node.resources.*
名前空間 (例: 'node.resources) にあります。
ノード | タイプ | 説明 |
---|---|---|
ncpus | 糸 | VM で使用可能な CPU の数 |
pcpus | 糸 | VM で使用可能な物理 CPU の数 |
ngpus | 整数 | VM で使用可能な GPU の数 |
memb | 糸 | ユニット インジケーター (例: "8.0b") を使用して VM で使用可能な物理メモリの概算 |
memkb | 糸 | ユニット インジケーター (例: "8.0k") を使用して VM で使用可能な物理メモリの概算 |
memmb | 糸 | ユニット インジケーター (例: "8.0m") を使用して VM で使用可能な物理メモリの概算 |
memgb | 糸 | ユニット インジケーター (例: "8.0g") を使用して VM で使用可能な物理メモリの概算 |
memtb | 糸 | "8.0t" などのユニット インジケーターを使用して VM で使用可能な物理メモリの概算 |
スロット | 整数 | ncpus と同じ |
slot_type | 糸 | 拡張機能の追加ラベル。 未使用。 |
m_mem_free | 糸 | 実行ホストに必要な空きメモリ (例: "3.0g" ) |
mfree | 糸 | _m/_mem/free と同じです |
リソース マッピング
また、default_resourcesで使用できる数学もあります。特定のノード配列のスロットを 2 つ減らし、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"
}
],
複合型に値全体と等しくないショートカットがある場合は、が複合名であるphysical_cpu
で両方を定義します。
"default_resources": [
{
"select": {},
"name": "physical_cpu",
"value": "node.pcpu_count"
},
{
"select": {},
"name": "pcpu",
"value": "node.resources.physical_cpu"
}
]
順序付けは、特定の属性に対して特定の動作が必要な場合に重要です。 他のすべての nodearray の既定のスロット数を保持しながら、特定の nodearray に 1 つのスロットを割り当てるには:
"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]
)。 - すべてのジョブ リソースを提供するための十分なリソースとサブスクリプション クォータを用意します。
- ホストグループの制約構成ではそれらのフィルタリングが行われません。
複数のホスト グループがこれらの要件を満たしている場合があります。 その場合、システムはどれを使用するかを決定する必要があります。 ホスト グループ メンバーシップの競合を解決するには、次の 3 つの方法があります。
- あいまいさを避けるためにキューを構成します。
- autoscale.json に制約を追加します。
- スケジューラ構成の
weight_queue_host_sort < weight_queue_seqno
を調整して、CycleCloud が名前順に一致するホストグループを選択できるようにします。 - キュー構成で
seq_no 10000,[@hostgroup1=100],[@hostgroup2=200]
を設定して、ホスト グループの基本設定を示します。
Hostgroup 制約
キューまたは 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 環境変数に依存します。qconf
が呼び出されるのと同じプロファイルから qsub
と azge
を呼び出すことができる必要があります。
azge コマンド | 説明 |
---|---|
検証 | 自動スケーラーまたは gridengine で既知の構成エラーを確認します |
ジョブ | キュー内のすべてのジョブを表示します |
バケット | 自動スケーリングで使用可能なリソース プールを表示します |
ノード | クラスター ホストとプロパティを表示します |
需要 | ジョブ要件をサイクルクラウド バケットに一致させ、自動スケーリングの結果を提供します |
自動スケーリング | 構成に従ってノードの完全自動スケーリング、開始、および削除を行います |
スケジューラ構成 (qconf) または自動スケール構成 (autoscale.json) を変更する場合、または初めて設定する場合でも、 azge を使用して自動スケールの動作が期待値と一致することを確認できます。 ルートとして、次の操作を実行できます。 自動スケールのしくみを理解するには、これらの概念を理解することが重要です。
-
azge validate
を実行して、既知の問題の構成を確認します。 -
azge buckets
を実行して、CycleCloud クラスターによって提供されるリソースを確認します。 -
azge jobs
を実行して、キューに登録されたジョブの詳細を調べます。 -
azge demand
を実行して、バケット マッチングするジョブを実行します。 次に、どのジョブがどのバケットとホスト グループに一致するかを調べます。 -
azge autoscale
を実行して、ノード割り当てプロセスを開始するか、参加する準備ができているノードを追加します。
コマンドが想定どおりに動作したら、ルート crontab に azge autoscale
コマンドを追加して、継続的な自動スケーリングを有効にします。 必ず、事前に 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 をローカルにインストールすることで緩和できます。
単純なケースでは、実行ノードがマウントできるファイルシステムを提供する必要があります。 このファイルシステムには、…が含まれている必要があります ディレクトリに移動し、オプションの設定でマウントを構成します。 sched ディレクトリと共有ディレクトリの依存関係が解放されたら、既定でクラスターの一部であるスケジューラ ノードをシャットダウンし、外部ファイルシステムの構成を使用できます。
- 新しい gridengine クラスターを作成します。
- リターン プロキシを無効にします。
- /sched と /shared を外部ファイルシステムに置き換えます。
- クラスターを保存します。
- UI のアクションとしてスケジューラ ノードを削除します。
- クラスターを起動します。ノードは最初に起動しません。
- 新しいクラスターを使用するように autoscale.json で
cyclecloud-gridengine
を構成します
CycleCloud での Univa Grid Engine の使用
GridEngine 用 CycleCloud プロジェクトでは、既定で sge-2011.11 が使用されます。 Altair ライセンス契約に従って、独自の Altair GridEngine インストーラーを使用できます。 このセクションでは、CycleCloud GridEngine プロジェクトで Altair GridEngine を使用する方法について説明します。
前提条件
この例では、8.6.1 デモ バージョンを使用していますが、8.4.0 > すべての ge バージョンがサポートされています。
- ユーザーは 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"
これらの gridengine 構成は、クラスターの起動時に既定の gridengine のバージョンとインストール場所をオーバーライドします。 クラスター内の共有 nfs の場所であるため、 /sched
から移動しても安全ではありません。