ソフトウェアのインストールをカスタマイズする

完了

Azure CycleCloud テンプレートを使用すると、基になるインフラストラクチャの実装の詳細を抽象化することで HPC クラスターの設定が容易になり、ワークロード管理に集中できます。 ただし、通常、そのワークロードには複数のソフトウェア関連の依存関係があり、追加のカスタマイズ手順が必要です。 さいわい、Azure CycleCloud には、クラスター ノードに直接適用されるプロビジョニングタスクと構成管理タスクのサポートを通じて、これらの手順を実装するためのフレームワークも用意されています。

目標には、カスタム イメージをデプロイし、オンプレミスの HPC 環境で使用していた社内開発の構成スクリプトを使用する必要があります。 Azure CycleCloud 機能を使用してこれらの目標を達成する方法を決定する必要があります。

Azure CycleCloud で構成管理を実装する方法

Azure CycleCloud には、任意の方法で組み合わせて、独自の要件または設定に従ってクラスター ノード上のオペレーティング システムとソフトウェアをカスタマイズできる 3 つの主要な方法が用意されています。

  • カスタム イメージ
  • プロジェクト
  • cloud-init

Azure CycleCloud でカスタム イメージを使用する方法

Azure CycleCloud では、最も一般的な Linux ディストリビューションを実行するクラスター ノードと、スケジューラに応じて Windows Server がサポートされます。 組み込みのテンプレートは、推奨される既定値で事前構成されていますが、Azure Marketplace イメージを選択するか、カスタム イメージに基づいてノードをプロビジョニングすることもできます。 オペレーティング システムのデプロイ後のセットアップと HPC ワークロードの追加の依存関係に関連する遅延を最小限に抑える場合は、後者のオプションをお勧めします。 ビジネス、セキュリティ、またはコンプライアンスのニーズを満たす必要がある場合もあります。

カスタム イメージを使用すると、プレインストールされているソフトウェアとオペレーティング システムの初期構成を完全に制御できます。 主な欠点は、アプリケーションとそのバージョンの異なる組み合わせ (特に開発シナリオ) に対応するために複数のイメージを維持することに関連するオーバーヘッドです。

ソフトウェアのインストールに Azure CycleCloud プロジェクトを使用する方法

Azure CycleCloud プロジェクトは、テンプレートを使用してクラスター ノードの構成を定義するときに参照するファイルのコレクションです。 プロジェクトのディレクトリ構造は次のとおりです。

\project
      |- project.ini
      |- blobs
      |- templates
      |- specs
      |      | 
      |    default
      |      |- cluster-init
      |            |- scripts
      |            |- files
      |            |- tests
      |      | - chef
      |            |- site-cookbooks
      |            |- data_bag
      |            |- roles

project.ini ファイルには、プロジェクトのメタデータ (名前、ラベル、バージョン、型など) が含まれます。 サポートされている型には、スケジューラとアプリケーションが含まれます。 1 つ目はヘッド ノードとコンピューティング ノードにスケジューラ デーモンをインストールして初期化するために使用され、後者はクラスター ワークロードを定義します。

BLOB ディレクトリには、自由に再配布できるオープンソース プロジェクトのバイナリ ファイルなどのプロジェクト BLOB と、ライセンス制約のためにプロジェクトの再配布から除外する必要があるユーザー BLOB が含まれています。

templates ディレクトリにはテンプレートが含まれていますが、specs ディレクトリはターゲット クラスター ノードに適用する構成を定義する仕様をホストします。

たとえば、Slurm プロジェクトには、少なくともスケジューラ ヘッド ノード用とコンピューティング ノード用の 2 つの仕様が含まれています。

specs ディレクトリ内には、 cluster-initカスタム Chef という名前の 2 つのサブディレクトリがあります。 Cluster-init には、ターゲット ノードで自動的に実行されるスクリプトが含まれています。 ターゲット ノードにコピーされる生データ ファイルと、クラスターがテスト モードで開始されたときに実行されるテスト。 カスタム Chef サブディレクトリには、クックブック、データ バッグ、ロール定義ファイルなど、Chef 固有のファイルが含まれています。 Chef クックブックとレシピを使用してノードを構成できます。 cluster-init の仕様は、Chef のロールとクックブックに対応します。

Azure CycleCloud は、各ノードを準備および構成するための構成管理ツールとして Chef を使用します。 CycleCloud は、一元化された Chef サーバーに依存しないスタンドアロン モードで Chef を使用します。 代わりに、マネージド クラスター ノード宛てのすべてのクックブックは、オペレーティング システムの起動フェーズ中にロッカーからダウンロードされます。 その時点で、Chef はノードの cluster-init 仕様で定義されているレシピの一覧を処理し、基になる VM を実際の HPC ノードに効果的に変換します。

プロジェクトに基づいてクラスターをプロビジョニングするには、プロジェクトのコンテンツを Azure CycleCloud ロッカーにアップロードする必要があります。 次に、ターゲット ノードが起動するたびに、必要なプロジェクト ファイルがロッカーから自動的にダウンロードされ、必要な仕様が処理されます。

Azure CycleCloud で cloud-init を使用する方法

Azure CycleCloud では、プロジェクト関連の仕様が適用される前に、ブート フェーズ中にクラスター ノードを構成する方法として cloud-init がサポートされています。 これにより、ネットワーク設定の構成やオペレーティング システム パッケージの更新の適用など、インフラストラクチャやソフトウェア関連の依存関係に対処するための便利な方法が提供されます。

テンプレートを使用して cloud-init 構成を定義できますが、Azure CycleCloud グラフィカル インターフェイスから直接これを行うこともできます。 クラスターを作成または編集するときに、 Cloud-Init というラベルのタブに関連する設定が表示されます。ここで、各ノード タイプのスクリプトを入力できます。

Cloud-init は CycleCloud プロジェクト 仕様の前に実行されるため、スケジューラと Azure CycleCloud がノードに適用される構成によって、cloud-init を介して行われた変更が上書きされる可能性があります。 スケジューラのインストール後にコマンドを確実に実行する必要がある場合は、代わりに Azure CycleCloud プロジェクト スペックを使用する必要があります。