Microsoft HPC Pack
ハイ パフォーマンス インフラストラクチャを高いレベルで制御する必要がある場合、またはクラウドとオンプレミスの両方の VM を管理する場合は、Microsoft HPC Pack の使用を検討してください。
あなたは、エンジニアリング会社で、オンプレミス データ センターから Azure にハイ パフォーマンス インフラストラクチャを移行したいと考えています。 これらのシステムはビジネス上重要であるため、段階的に移行したいと考えています。 オンプレミスとクラウドの両方の VM が存在する場合、移行時に VM の要求と管理を柔軟に行うために迅速な対応を確保する必要があります。
ここでは、HPC Pack で HPC インフラストラクチャを管理する方法について学習します。
HPC Pack とは
エンジニアリング組織のオプションを調べるために、Azure Batch と Azure HPC インスタンスを見てきました。 しかし、VM のクラスターの管理とスケジュール設定を完全に制御する必要がある場合はどうでしょうか? データセンター内のオンプレミス インフラストラクチャに多大な投資をしている場合はどうすればよいですか? HPC Pack では、Windows 用の一連のインストーラーが提供されます。これを使用すると、独自の制御と管理プレーン、およびオンプレミスとクラウドのノードの非常に柔軟なデプロイを構成できます。 専用のクラウドベースの Batch とは対照的に、HPC Pack ではオンプレミスとクラウドに柔軟にデプロイできます。 両方のハイブリッドを使用して、オンプレミスの予約が不十分なときにクラウドに拡張します。
HPC Pack は、お客様が完全な制御を有して責任を担う、Batch の管理およびスケジュール制御レイヤーの 1 つのバージョンです。 HPC Pack のデプロイには Windows Server 2012 以降が必要です。
HPC Pack の計画
通常は、要件を完全に確認して、HPC Pack のインストールを準備する必要があります。 SQL Server と Active Directory コントローラーが必要です。 また、トポロジを計画する必要もあります。 必要なヘッド ノードまたは制御ノードの数はいくつですか? また、ワーカー ノードの数はいくつですか? Azure に拡張する必要がありますか? そうである場合は、クラスターの一部として Azure ノードを事前にプロビジョニングします。 コントロール プレーン (ヘッドおよび制御ノード、SQL Server、Active Directory ドメイン コントローラー) を構成するメイン コンピューターのサイズは、予測されるクラスターのサイズによって異なります。
HPC Pack をインストールすると、HPC ジョブと並列ジョブの両方をサポートするジョブ スケジューラが表示されます。 スケジューラは、Microsoft メッセージ パッシング インターフェイスに表示されます。 HPC Pack は Windows と高度に統合されているので、Visual Studio を使用して並列デバッグを行うことができます。 クラスター内のコンピューティング ノードのアプリケーション、ネットワーク、およびオペレーティング システムのすべてのイベントが、単一のデバッガー ビューで表示されます。
HPC Pack では、高度なジョブ スケジューラも提供されます。 HPC Pack 専用のノードだけでなく、Linux ベースのノード、および Azure ノードにも迅速にデプロイできます。 これは、データセンター内で予備容量を使用できることを意味します。 HPC Pack では、既存のインフラストラクチャへの投資を利用し、Batch の場合と比べて、作業の分割方法をより細かく制御できる理想的な方法が提供されます。
テクノロジを組み合わせて使用する
このモジュールで検討するオプションは相互に排他的ではありません。 最後のユニットで確認した H シリーズの VM は、HPC 構成内の可能な Azure ノードとして使用できます。 Batch との違いを強調するハイブリッド ユース ケースに集中していますが、HPC Pack には柔軟性があります。 これにより、専用のオンプレミス デプロイと専用のクラウドベースのデプロイの両方が可能になります。 この柔軟性は、Batch で提供されるものより細かい制御が必要な場合に便利です。
HPC Systems のデプロイと管理
HPC システムの調整
クラウド コンピューティングの概念の 1 つは "オーケストレーション" です。 これは、クラスター内のアプリケーションのすべてのコンポーネントのデプロイ、実行、監視を監督することを意味します。
さらに、オーケストレーターは、復旧 (エラーの管理)、スケーリング、ログ記録などの他のタスクを実行することもできます。 よく知られている Kubernetes や Mesos のようなオーケストレーターは、仮想化によって直接クラウド クラスター リソースにアクセスできます。
HPC システムのデプロイ
Azure での HPC デプロイは、特定のワークロードのニーズと予算によって異なる場合があります。 デプロイには、次のようないくつかの標準コンポーネントがあります。
- Azure Resource Manager: スクリプト ファイルまたはテンプレートを使用して、クラスターへのアプリケーションのデプロイを可能にします。
- HPC ヘッド ノード: ジョブとワークロードをワーカー ノードにスケジュールできるようにします。 これは HPC クラスターの管理に使用される仮想マシン (VM) です。
- Virtual Network: ExpressRoute または IPsec VPN を使用したセキュリティで保護された接続を使用して、クラスターとストレージの分離されたネットワークを作成できるようにします。 確立された DNS サーバーと IP アドレスをネットワーク内で統合し、サブネット間のトラフィックをきめ細かく制御できます。
- Virtual Machine Scale Sets: クラスターの VM のプロビジョニングを可能にし、自動スケーリング、マルチゾーン デプロイ、負荷分散の機能が含まれています。 スケール セットを使用して、MongoDB、Cassandra、Hadoop などの複数のデータベースを実行できます。
- ストレージ: BLOB、ディスク、ファイル、ハイブリッド、またはデータ レイクのストレージ形式で永続ストレージ クラスターをマウントできるようにします。
Azure HPC デプロイの管理
Azure には、HPC デプロイの管理に役立つネイティブ サービスがいくつか用意されています。 これらのツールは管理の柔軟性を提供し、Azure とハイブリッド リソースでワークロードをスケジュールするのに役立ちます。
- Microsoft HPC Pack: VM クラスターの構成と管理、操作の監視、ワークロードのスケジュールを設定できる一連のユーティリティ。 HPC Pack には、オンプレミスのワークロードを移行したり、ハイブリッドデプロイで操作を続行したりするのに役立つ機能が含まれています。 このユーティリティでは、VM やネットワーク インフラストラクチャは自動的にプロビジョニングまたは管理されません。
- Azure CycleCloud: 選択したスケジューラのインターフェイス。 Azure CycleCloud は、HPC Pack、Grid Engine、Slurm、Symphony など、さまざまなネイティブおよびサードパーティのオプションで使用できます。 CycleCloud を使用すると、ワークロードの管理と調整、Active Directory でのアクセス制御の定義、クラスター ポリシーのカスタマイズを行えます。
- Azure Batch: デプロイを自動スケーリングし、ジョブ スケジュール用のポリシーを設定するために使用できるマネージド ツールです。 Azure Batch サービスは、ワークロードのプロビジョニング、割り当て、ランタイム、監視を処理します。 これを使用するために必要なことは、ワークロードをアップロードし、VM プールを構成することだけです。
Azure HPC ワークロードでは、機械学習、視覚化、レンダリングが提供され、そのすべてによって半導体業界でのアプリケーションが強化されます。 これにより、石油とガスのワークロードのシームレスで回復力のあるクラウド統合と、クラウドベースのゲノム配列決定と半導体設計が可能になります。
Azure HPC デプロイのベスト プラクティス
次のベスト プラクティスは、期待されるパフォーマンスと価値を得るのに役立ちます。
クラウド サービス全体にデプロイを分散する: クラウド サービス全体に大規模なデプロイを分散すると、単一のサービスを過負荷にしたり依存したりすることによって生み出される制限を回避するのに役立ちます。 デプロイをより小さなセグメントに分割すると、次のことが可能になります。
- 他のプロセスを中断することなく、アイドル状態のインスタンスをジョブの完了後に停止する
- ノード クラスターを柔軟に開始および停止する
- クラスター内の使用可能なノードをより簡単に見つける
- 複数のデータ センターを使用してディザスター リカバリーを実現する
ノードデプロイ用に複数の Azure ストレージ アカウントを使用する: 複数のサービスにデプロイを分散させるのと同様に、各デプロイに複数のストレージ アカウントをアタッチすることをお勧めします。 大規模なデプロイ、入出力操作によって制限されるアプリケーション、およびカスタム アプリケーションのパフォーマンスを向上させることができます。 ストレージ アカウントを設定するときは、一貫性と低待機時間を実現するために、ノード プロビジョニング用の 1 つのアカウントと、ジョブまたはタスク データを移動するための別のアカウントが必要です。
デプロイ サイズに合わせてプロキシ ノード インスタンスを増やす: プロキシ ノードを使用すると、オンプレミスで動作しているヘッド ノードと Azure ワーカー ノード間の通信が可能になります。 これらのノードは、Azure に worker をデプロイすると自動的にアタッチされます。 プロキシ ノードによって提供されるリソースを満たすか超える大規模なジョブを実行している場合は、実行している数を増やすことを検討してください。 デプロイが大きくなるにつれて、増加は特に重要です。
HPC クライアント ユーティリティを使用してヘッド ノードに接続する:
HPC Pack クライアント ユーティリティは、特に大規模なジョブを実行している場合に、ヘッド ノードに接続するための推奨される方法です。 これらのユーティリティをユーザーのワークステーションにインストールし、リモート デスクトップ サービス (RDS) を使用するのではなく、必要に応じてヘッド ノードにリモートでアクセスできます。 これらのユーティリティは、多くのユーザーが一度に接続している場合に特に役立ちます。
タスクのスケジュール設定
提供されるもう 1 つの HPC サービスは、タスクのスケジュール設定です。 アプリケーションのスケジューラを使用して作業をディスパッチすると、バッチ ジョブを効率的に実行できます。 スケジューラの主要な目標は次のように大まかに分類できます。
- ジョブの送信から完了までの時間を最短にします。 ジョブを長時間キューに残さないようにします。
- CPU 使用率を最適化します。 特に、CPU のダウンタイムを減らします。
- ジョブのスループット (時間単位あたりのジョブのスケーリング) を最大化します。
タスクのスケジュール設定について
ユーザーは、非対話型バッチ ジョブをスケジューラに送信します。 スケジューラでは、バッチ ジョブが格納され、リソース要件と優先順位が評価され、ジョブが適切なコンピューティング ノードに分散されます。 これらは最も能力を消費するものとして、HPC クラスターの大部分 (約 98%) を占めます。
サインイン ノードとその対話型の使用とは異なり、コンピューティング ノードには ssh 経由で直接アクセスすることはできません。 サインイン ノード上のスケジューラは、コンピューティング ノードとユーザーの間のインターフェイスとして機能します。 ユーザーは、時間とメモリのリソースに基づいてジョブ スクリプト内のアプリケーションを指定する必要があります。
スケジューラを介して送信されたジョブ スクリプトによって、ジョブがジョブ キューに追加されます。 ジョブで必要な使用可能なリソースに応じて、スケジューラではジョブがキューから出るタイミングと、実行するバックエンド ノードの一部が決定されます。
ユーザーは、要求するリソースがシステムの制限に収まることを確認する必要があります。 次に例を示します。
- ジョブでさらに多くの時間が要求される場合でも、割り当てられた時間が切れるとスケジューラによってジョブが強制終了されます。
- システムで使用可能なメモリよりも多くのメモリを要求するジョブの場合、ジョブはキューに永続的にスタックします。
図
使用しているバッチ システムが 6 つのノードで構成されていると仮定すると、スケジューラは、バッチ システムを使用して、キュー内の 9 つのジョブを対応可能なノードに配置します。 目標は、ジョブが実行されていないノードを表す空白の部分として次の図に示されている、無駄なリソースを排除することです。
したがって、ジョブは最初にキューに入ったのと同じ順序でノード間で分散されない場合があります。 タスクの実行に必要な時間とノードの数によって、ジョブが占める領域が決まります。 スケジューラは、すべてのジョブのリソース要件をクラスター内の使用可能なリソースに均等に分散することによって、クラスター内のノードを均一に満たすために多次元的なローテーションを行う役割を果たします。
スケジュール アルゴリズム
スケジューラが次に実行するジョブを決定するために使用できる 2 つの基本戦略があります。 最新のスケジューラは、これらのアルゴリズムの 1 つに厳密に従うのではなく、2 つの組み合わせを採用しています。 また、スケジューラは現在のシステム負荷など、考慮する必要がある多くの側面があります。
先着順 ジョブは、最初にキューに入る順序とまったく同じ順序で実行されます。 利点はすべてのジョブが確実に実行されることです。 ただし、少数のジョブが、実際の実行時間と釣り合わずに長く待機する場合もあります。
最短ジョブ優先 ジョブ スクリプトで宣言された実行時間に基づき、スケジューラによってジョブの実行時間が見積もられます。 ジョブは実行時間の昇順にランク付けされます。 短いジョブは短い待機時間の後に開始されますが、実行時間の長いジョブ (または少なくともそのように宣言されたジョブ) は実際には開始されない場合もあります。
バックフィル: スケジューラは、実行時間の長いジョブが実行されるのを妨げられることなく、"先着順" の概念を維持します。 スケジューラは、キュー内の最初のジョブを実行できる場合にのみジョブを実行します。 それ以外の場合、スケジューラはキューの残りの部分を通過して、キュー内の最初のジョブの待機時間を延長せずに別のジョブを実行できるかどうかを確認します。 そのようなジョブが見つかると、スケジューラはそのジョブを実行します。 小さなジョブでは、通常、短いキュー時間が発生します。
ワークフロー管理
タスクのパイプライン処理と自動化
ツールの使用状況やソフトウェア プロセスのタスク シーケンスの実行などの繰り返しの操作をパイプラインに編成できます。 これを自動化することで、ソフトウェアとツールの全体的な使用効率を高めることができます。 タスク自体を高速化し、ナレッジ ワーカーの管理に対する負担を軽減することで、効率を高めます。
自動化により、プロセスの実行方法の差異をなくすことで、プロセスのエラー率を減らすことができます。 また、タスクのパイプライン化と自動化によって、並列化やクラウド デプロイなどのさらなるプロセス イノベーションの扉を開くことができます。
ワークフロー管理用のツール
Azure Batch を使用する
Azure Batch を使用すると、大規模な並列コンピューティングやハイパフォーマンス コンピューティング (HPC) のバッチ ジョブを Azure で効率的に実行することができます。 Azure Batch は、コンピューティング ノード (仮想マシン) のプールを作成および管理し、実行するアプリケーションをインストールし、ノードで実行するジョブをスケジュールします。 インストール、管理、またはスケーリングするクラスターまたはジョブ スケジューラ ソフトウェアはありません。 代わりに、Batch API およびツール、コマンド ライン スクリプト、または Azure Portal を使用して、ジョブを構成、管理、および監視します。
その他の機能やしくみなど、Azure Batch の詳細については、Azure Batch に関する記事を参照してください。
Azure CycleCloud を使用する
Azure CycleCloud は、Azure 上のハイ パフォーマンス コンピューティング (HPC) 環境を調整および管理するためのエンタープライズ向けツールです。 CycleCloud を使用すると、ユーザーは HPC システムのインフラストラクチャを計画し、使い慣れた HPC スケジューラをデプロイし、インフラストラクチャを自動的にスケーリングして、任意の規模で効率的にジョブを実行できます。 CycleCloud を使用して、ユーザーはさまざまな種類のファイル システムを作成し、コンピューティング クラスター ノードにマウントして HPC ワークロードをサポートできます。
Azure CycleCloud の詳細については、Azure CycleCloud に関する記事を参照してください。