CycleCloud 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クラスター構成に従ってクラスターにホストを追加します。 自動スケーリング操作では、次のアクションが実行されます。

1. ジョブ リソース要求を読み取り、開始する適切な VM を見つける
2. VM を起動し、準備が整うのを待ちます
3. ジョブからキューと並列環境を読み取る
4. キュー/pe に基づいて、適切なホスト グループにホストを割り当てます
5. ホストをクラスターに追加し、ホスト グループを含む他のキューに追加します

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 にも追加されます。

pe を指定しないと、 qsub -q short.q my-script.sh 結果の VM が @allhosts に追加され、キュー内のホスト グループが pes に割り当てられない @lowpriority されます。

最後に、 で qsub -q short.q -pe mpi0* 12 my-script.sh 送信されたジョブでは、CycleCloud 割り当ての予測に応じて、 @mpihg01 または @mpihg02 に VM が追加されます。

並列環境は、暗黙的に 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 とのみ共有します。 これらのサイロを直感的に保持するために、配置グループは 1 対 1 と gridengine 並列環境をマップします。

ジョブの並列環境を指定すると、スマート ホスト グループ割り当てロジックを使用して配置グループで実行するジョブが制限されます。 autoscale.json : "required_placement_groups" : falseの前述の構成を使用して、この動作をオプトアウトできます。

自動スケーリング構成

このプラグインは、ワークロードの要求に合わせてグリッドを自動的にスケーリングします。 autoscale.json 構成ファイルは、グリッド エンジン オートスケーラーの動作を決定します。

• cyclecloud 接続の詳細を設定する
• アイドル 状態のノードの終了タイマーを設定する
• スロット、メモリなど、ジョブ パッキングで使用する属性を設定して、多次元自動スケーリングを実行できます。
• 管理するキュー、並列環境、ホスト グループを登録する

構成	Type	説明
url	String	CC URL
username/password	String	CC 接続の詳細
cluster_name	String	CC クラスター名
default_resources	マップ	ノード リソースを自動スケーリング用のグリッド エンジン ホスト リソースにリンクする
idle_timeout	int	アイドル 状態のノードを終了するまでの待機時間 (秒)
boot_timeout	int	長い構成フェーズ中にノードを終了するまでの待機時間 (秒)
gridengine.relevant_complexes	List (String)	自動スケーリングで考慮するグリッド エンジンの複雑性 (スロット、mem_freeなど)
gridengine.logging	ファイル	ログ記録構成ファイルの場所
gridengine.pes	構造体	REQUIRES_PLACEMENT_GROUP = false など、ES の動作を指定する

自動スケーリング プログラムでは、関連リソースのみが考慮されます

その他の自動スケーリング リソース

既定では、ジョブによって要求されるスロットの数に基づくスケールを持つクラスター。 自動スケーリングに別のディメンションを追加できます。

たとえば、 のジョブ リソース要求 m_mem_freeによって自動スケーリングを行うとします。

1. autoscale.json 内の gridengine.relevant_resources にを追加m_mem_freeする
2. autoscale.json のノード レベルのメモリ リソースへのリンクm_mem_free

これらの属性は、_default/リソースの値として を使用した参照node.*にすることができます。

ノード	Type	説明
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	ユニット インジケーター (例: "8.0g") を使用して VM で使用可能なおおよその物理メモリ

名前空間には node.resources.* 、'node.resources など、追加の属性があります。

ノード	Type	説明
ncpus	String	VM で使用可能な CPU の数
pcpus	String	VM で使用できる物理 CPU の数
ngpus	整数型	VM で使用可能な GPU の数
memb	String	ユニット インジケーター (例: "8.0b") を使用して VM で使用可能なおおよその物理メモリ
memkb	String	ユニット インジケーター (例: "8.0k") を使用して VM で使用可能なおおよその物理メモリ
memmb	String	ユニット インジケーター (例: "8.0m") を使用して VM で使用可能なおおよその物理メモリ
memgb	String	ユニット インジケーター (例: "8.0g") を使用して VM で使用可能なおおよその物理メモリ
memtb	String	ユニット インジケーター (例: "8.0t") を使用して VM で使用可能なおおよその物理メモリ
slots	整数型	ncpus と同じ
slot_type	String	拡張機能の追加ラベル。 一般的には使用されません。
m_mem_free	String	実行ホストで必要な空きメモリ (例: "3.0g")
mfree	String	_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"
    }
 ],

複合に値全体と等しくないショートカットがある場合は、 default_resourcesで両方 を定義します。ここで 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 は、次のホスト グループの共通部分を取得します。

1. cloud.q のpe_listに含まれ、pe 名 (例: ) と一致します。 pe_list [@allhosts=mpislots],[@hpc1=mpi]
2. すべてのジョブ リソースを提供するための十分なリソースとサブスクリプション クォータを用意します。
3. ホスト グループ制約の構成ではフィルター処理されません。

複数のホスト グループがこれらの要件を満たしている可能性があります。その場合、ロジックを選択する必要があります。 ホスト グループ メンバーシップのあいまいさを解決するには、次の 3 つの方法があります。

1. あいまいさがないようにキューを構成します。
2. autoscale.json に制約を追加します。
3. スケジューラ構成で を調整して、CycleCloud で一致するホスト グループを weight_queue_host_sort < weight_queue_seqno 名前順に選択できるようにします。
4. ホスト グループの基本設定を示すように、キュー構成で を設定 seq_no 10000,[@hostgroup1=100],[@hostgroup2=200] します。

Hostgroup 制約

キューまたは xproject によって複数のホスト グループが定義されている場合、これらのすべてのホスト グループにホストが追加される可能性があります。 hostgroup 制約を設定することで、どの種類のホストをどのキューに追加できるかを制限できます。 ノードのプロパティに基づいて制約を設定します。

"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から と qsub を呼び出qconfすことができる必要があります。

azge コマンド	説明
validate	自動スケーラーまたは gridengine で既知の構成エラーを確認します
jobs	キュー内のすべてのジョブを表示します
バケット	自動スケーリングに使用できるリソース プールを示します
nodes	クラスターのホストとプロパティを表示します
demand	ジョブ要件を cyclecloud バケットに一致させ、自動スケーリングの結果を提供します
自動スケーリング	構成に従ってノードのフル 自動スケーリング、開始、および削除を行います

スケジューラ構成 (qconf) または自動スケーリング構成 (autoscale.json) を変更する場合、または初めて設定する場合でも、 azge を 使用して自動スケーリングの動作が期待値と一致することを確認できます。 ルートとして、次の操作を実行できます。 自動スケーリングの動作を理解するには、これらを理解することをお勧めします。

1. を実行 azge validate して、既知の問題の構成を確認します。
2. を実行 azge buckets して、CycleCloud クラスターが提供しているリソースを調べます。
3. を実行 azge jobs して、キューに登録されたジョブの詳細を調べます。
4. を実行 azge demand して、バケットマッチングにジョブを実行し、どのジョブがどのバケットとホストグループに一致するかを調べます。
5. を実行 azge autoscale してノード割り当てプロセスを開始するか、参加する準備ができているノードを追加します。

次に、これらのコマンドが期待どおりに動作している場合は、ルート crontab に コマンドを azge autoscale 追加して、継続的な自動スケーリングを有効にします。 (グリッドエンジン環境変数のリソース)

* * * * * . $SGE_ROOT/common/settings.sh && /usr/local/bin/azge autoscale -c /opt/cycle/gridengine/autoscale.json

ハイブリッド クラスターの作成

CycleCloud では、クラウドへのバーストのシナリオがサポートされます。 基本構成では、ディレクトリが $SGE_ROOT クラウド ノードで使用できるものとします。 この想定は、 を設定gridengine.shared.spool = falsegridengine.shared.bin = falseし、GridEngine をローカルにインストールすることで緩和できます。 簡単なケースでは、ディレクトリを含む $SGE_ROOT 実行ノードによってマウントできるファイルシステムを提供し、オプションの設定でそのマウントを構成する必要があります。 sched ディレクトリと共有ディレクトリの依存関係が解放されたら、クラスターの一部であるスケジューラ ノードを既定でシャットダウンし、外部ファイルシステムの構成を使用できます。

1. 新しい gridengine クラスターを作成します。
2. リターン プロキシを無効にします。
3. /sched と /shared を外部ファイルシステムに置き換えます。
4. クラスターを保存します。
5. UI のアクションとしてスケジューラ ノードを削除します。
6. クラスターを起動します。ノードは最初に開始されません。
7. 新しいクラスターを使用するように autoscale.json を使用して構成cyclecloud-gridengineする

CycleCloud での Univa グリッド エンジンの使用

GridEngine 用 CycleCloud プロジェクトでは、既定で sge-2011.11 が 使用されます。 Altair ライセンス契約に従って、独自の Altair GridEngine インストーラーを使用できます。
このセクションでは、CycleCloud GridEngine プロジェクトで Altair GridEngine を使用する方法について説明します。

前提条件

この例では 8.6.1-demo バージョンを使用しますが、すべての ge バージョン > 8.4.0 がサポートされています。

1. ユーザーは UGE バイナリを提供する必要があります

• ge-8.6.x-bin-lx-amd64.tar.gz
• ge-8.6.x-common.tar.gz

2. 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 のバージョンとインストール場所をオーバーライドします。 クラスター内の /sched 特に共有された nfs の場所であるため、 から移動しても安全ではありません。