次の方法で共有

Azure CycleCloud でのスポット VM の使用

  • [アーティクル]

Azure CycleCloud では、クラスターの運用コストを大幅に削減するために、Nodearray にスポット VM を デプロイすることがサポートされています。

注意事項

スポット VM は、すべてのワークロードとクラスターの種類に適しているわけではありません。 可用性または容量に対する SLA は提供されません。 これらは "割り込み可能" または "優先順位の低い" インスタンスであり、容量を管理し、スポット価格の変化に応じて Azure ファブリックによって削除される可能性があります。

スポットの Nodearray の構成

nodearray のスポットを有効にするには、セクションで true に[[nodearray]]設定Interruptibleするだけです。

CycleCloud では、クラスターでスポット インスタンスを MaxPrice 指定できます。 スポット価格は定期的に調整される可能性があり、リージョンと SKU によって大きく異なる場合があるため、 MaxPrice ユーザーは VM に対して支払う最大価格 ($/時間) を制御できます。 既定では、CycleCloud は特に指定されていない場合に設定 MaxPrice=-1 されます。これは、"スポット価格に基づいて削除しないでください" ことを意味します。この設定では、容量要求の変更やその他のプラットフォーム レベルの決定によってのみインスタンスが削除されます。

スポット インスタンスの可変 価格 の詳細については、「スポット価格」を参照してください。

ほとんどの HPC アプリケーションでは、 MaxPrice=-1 適切な既定の選択肢です。 ただし、nodearray が一連の VM SKU で 複数選択の自動スケーリングを サポートしている場合は、 MaxPrice 複数選択リストで低価格の SKU の優先順位を作成するようにカスタマイズすることもできます。

[cluster demo]

  [[nodearray execute]]
  Interruptible = true
  MaxPrice = 0.2

詳細については、クラスター テンプレート ガイドのスポット Virtual Machinesを参照してください。

スポット VM の削除

CycleCloud は、 スケジュールされたイベント 機能を使用してスポット削除を監視します。 スポットプリエンプション イベントが検出されると、CycleCloud は VM から通知を受け取り、インスタンスは "削除を待機しています" 状態に移動します。

よく寄せられる質問

CycleCloud でのスポットの使用には、HPC ワークロードと CycleCloud の自動スケーリングに固有の考慮事項がいくつかあります。

スポットの使用を検討する必要がある場合

  • 個々の仕事は比較的短いですか?
    • 経験則として、1 時間以内に実行されるジョブはスポット インスタンスに適している可能性があります。これは、インスタンスが削除された場合、比較的少ない順方向の進行状況が失われるためです。
  • スケジューラは、失敗したホストでジョブを自動的に再試行または再キューしますか?
  • 実行中にホストが削除された場合、ジョブは安全に再実行できますか?
    • 一般に、スポット インスタンスはステートレス ワークロードに最適です。
  • 実行のコストを最小限に抑えることは、完了時間よりも重要ですか?
    • スポットは、多くの場合、オンプレミスの優先順位の低いキューまたはバックフィル キューでスケジュールされる可能性があるワークロードに最適です。
    • これは、短い MPI ジョブでも Spot が適切な場合の 1 つです。

スポットの使用を避ける必要がある状況

  • ジョブが密結合された HPC ジョブ (MPI ジョブなど) の場合は、スポット候補として適していない可能性があります。
  • ジョブが重要な場合や、完了期限がある場合は、削除と再試行によって完了までの時間が長くなる可能性があるため、通常の優先度のインスタンスの方が適している可能性があります。
    • ただし、スポット インスタンスを追加してランタイムとコストを削減しようとするときに、定期的な優先順位とスポット インスタンスを組み合わせて使用して期限を確実に満たすようクラスターを構成する絶好の機会となる場合があります。
  • ジョブを再実行しても安全でない場合は、スポットを回避する必要があります。
    • たとえば、実行中にジョブがデータベースを変更した場合、ジョブを自動的に再実行すると、エラーや無効な結果が発生する可能性があります。
  • ジョブランタイムが非常に長い場合は、スポットが適していない可能性があります。
    • 長いプロセスでは、スポット削除とドルの可能性と再試行の時間コストの両方が増加します。
    • ただし、これはケースごとに測定が必要になる場合があります。

削除/プリエンプション

Azure でのスポット削除の詳細については、「 スポット削除ポリシー」 を参照してください。

Q. CycleCloud はスポット インスタンスの削除/プリエンプションを追跡できますか?

A. はい。 スポット削除イベントは、[クラスター UI] ページにイベント ログ通知を生成します。

Q. ユーザーに削除の通知を受け取る方法

A. CycleCloud ノードが削除されると、クラスターの CycleCloud UI のイベント ログにログ メッセージが表示されます。 ユーザーは、スポット インスタンスが削除された後、 Azure EventGrid を介して CycleCloud からイベントを受信するように登録することもできます。

  • ユーザーは、削除の 30 秒前にコンピューターで削除通知を確認できます。 イベントの登録方法の詳細については、「 スケジュールされた イベント」を参照してください。
  • 一般に、削除はオンプレミスのマシンでプラグをプルするのと似ていると見なし、同じ方法で処理する必要があります。
  • 大事な イベント ハンドラーはスポット削除イベントを 確認しないでください 。Cyclecloud イベント ハンドラーは、受信確認された場合にイベントを受信しない可能性があるためです。

Q. 削除はどのくらいの頻度で行われますか?

A. 立ち退き率は大きく変動し、リージョン全体の需要の変化に大きく依存します。

Q. インスタンスが削除される理由

A. スポット VM は可用性に関する保証を行わず、いつでも削除される可能性があります。 詳細については 、スポット VM のドキュメント を参照してください。 nodearray が設定 MaxPrice されている場合、スポット価格 MaxPriceが . スポット価格は非常にゆっくりと動くので、これは まれになる 傾向があります。 削除をトリガーする 可能性がある いくつかのシナリオを次に示します。

  1. 定期的な優先度 VM の需要が増加するにつれて、スポット容量が減少します。
  2. 計画されたハードウェア メンテナンスなどのプラットフォーム レベルのイベント。

ワークフローが削除の影響を受けますか?

Q. スポット インスタンスが削除されると、ジョブはどうなりますか?

A. 30 秒の削除通知を処理し、適切に処理するようにジョブがコーディングされていない限り、ノードは単純に終了し、ジョブは失敗します (そして、できればもう一度試みられます)。

Q. ノードはクラスターから削除されますか?

A. はい。ノードは CycleCloud UI でクリーンアップされます。 サポートされているスケジューラでは、ノードもスケジューラでクリーンアップされます。

Q. ジョブを再実行する必要がありますか?

A. 一般に、削除されたジョブを再試行/再実行するのはスケジューラのジョブです。 ただし、ジョブの多くのクラスは再試行に耐えられません (たとえば、実行時に部分データを永続ストレージに書き込む場合など)。 これらのジョブは、スポット インスタンスでの実行に適していない可能性があります。

Q. スポット VM とオンデマンド VM と通常優先 VM を組み合わせて使用できますか?

A. はい。 個別のスポット (Interruptible) ノード配列と非スポット ノード配列を使用して、スポットと標準優先度の組み合わせを作成できます。 一般に、インスタンスの種類を組み合わせて使用するには、要件とユーザーが選択したスケジューラに応じて、いくつかの構成の決定を行う必要があります。 いくつかの一般的な構成を次に示します。

  • スポット VM と Regular-Priority VM をスケジューラ内の個別のキューに分割します。
    • この構成により、提出者は適切な VM の種類でジョブを簡単にターゲットにできます
  • スポット インスタンスと Regular-Priority インスタンスの両方を含む単一の大規模なリソース プールを作成します。
    • この構成は、通常の優先度インスタンスのごく一部を使用して前方の進行状況を確保し、スポットの大部分を使用してコストとランタイムを削減する拡張性の高いワークロードに役立ちます。

Q. CycleCloud ノードアレイの スポット削除ポリシー を変更できますか?

A. はい。 nodearray で属性を EvictionPolicy 直接設定して、ポリシーをいずれかの Delete ポリシーまたは Deallocate (既定: Delete) に変更できます。 ただし、現在、これは、割り当て解除を適切に処理するカスタム 自動スケーラーにのみ役立ちます。 現在の Azure CycleCloud 自動スケーラーでは、削除時にスポット インスタンスが削除されることを想定しています。

CycleCloud でのスポット削除のスケジューラのサポート

スケジューラの CycleCloud 実装の詳細については、スケジューラ固有のガイドを参照してください。

Q. Scheduler の自動スケーラーはスポット削除をどのように処理しますか?

A. 組み込み/サポートされているスケジューラ (HTCondor、GridEngine、PBS Professional、Slurm、LSF) のすべての自動スケーラーは、スポット削除を適切に処理しようとします。 一般に、削除されたインスタンスは Scheduler から削除され、削除後に使用可能な新しい容量よりも容量の需要が高い場合は、自動スケーラーによってインスタンスが置き換えられます。

カスタム 自動スケーラーは、スポット削除または一般的なマシンエラーを想定して、適切に処理するように構築する 必要があります 。

Q. 削除されたインスタンスで実行されていたジョブに何が起こると思いますか?

A. これは、ジョブの送信時に構成するユーザーに大きく応じて行われます。 GridEngine などの一部のスケジューラでは、キューごとに既定のアクションを構成することもできます。 既定では、HTCondor を除くすべての組み込みの CycleCloud スケジューラデプロイは、実行中のノードが削除されるか、予期せず終了したときにジョブが失敗としてマークされるように構成されます。 この動作は、ジョブが安全に再試行される可能性があるかどうかをユーザーのみが認識できるため、設計上の動作です。