Microsoft HPC Pack を使用した Azure ノードの大規模デプロイのベスト プラクティス

Hpc Pack 2008 R2 Service Pack 1 以降では、Windows HPC クラスター管理者と開発者は、Azure にオンデマンドでコンピューティング リソースを追加することで、オンプレミス クラスターの機能を強化できます。 Azure worker ロール インスタンスを使用するこの HPC クラスターの "バースト" シナリオでは、大規模な HPC ワークロードが可能になり、オンプレミスのクラスター リソースに加えて、またはオンプレミスのクラスター リソースの代わりに何千ものコアが必要な場合があります。 このトピックでは、オンプレミスの HPC Pack クラスターからの Azure ノードの大規模なデプロイの計画と実装に役立つガイダンスとベスト プラクティスの推奨事項について説明します。 これらの推奨されるベスト プラクティスは、Azure デプロイのタイムアウト、デプロイエラー、ライブ インスタンスの損失の発生を最小限に抑えるのに役立ちます。

該当するバージョンの HPC Pack と Azure SDK for .NET

通常、これらの推奨事項は HPC Pack 2012 R2 と HPC Pack 2012 に基づいていますが、HPC Pack 2008 R2 で実行される大規模なデプロイにも役立ちます。

次の表に、HPC Pack のバージョンと、これらのガイドラインが適用される Azure SDK for .NET の関連バージョンを示します。

Azure ノードの大規模デプロイのしきい値

HPC クラスターの Azure ノードのデプロイは、ヘッド ノードの構成を考慮する必要が生じたときに、単一のクラウド サービスで使用できるリソースの Azure クラスターのかなりの割合を必要とする場合に、"大規模" と見なされます。 デプロイが大きくなると、デプロイのタイムアウトが発生し、ライブ インスタンスが失われるリスクがあります。

次の表は、1 つのクラウド サービスでの Azure ノードの大規模なデプロイで一般的に使用されるロール インスタンスの実際のしきい値の数を示しています。 しきい値は、Azure ロール インスタンスに対して選択される仮想マシンのサイズ (Azure で定義済み) によって異なります。

各仮想マシンのサイズ (各サイズの CPU コアとメモリの数など) の詳細については、「 Cloud Services のサイズ」を参照してください。

信頼性の高い 1 つのサービスにこれらのしきい値を超える数のロール インスタンスをデプロイするには、通常、Azure 運用チームが手動で関与する必要があります。 これを開始するには、Microsoft 営業担当者、Microsoft Premier サポート アカウント マネージャー、または Microsoft サポートにお問い合わせください。 サポート プランの詳細については、 Azure サポートを参照してください。

すべての Azure ノード デプロイに適用されるハードで強制可能な制限はありませんが、クラウド サービスあたり 1,000 インスタンスは実際の運用環境の制限です。

大規模なデプロイに Azure を使用するためのベスト プラクティス

HPC クラスターで大規模な Azure デプロイを正常に作成して使用するための一般的なガイドラインを次に示します。

Azure 運用チームに早期シグナルを提供する

データ センター内の専用の Azure クラスターにデプロイする準備を行っていない限り、最も重要な推奨事項は、(Microsoft サポート チャネルを介して) Azure 運用チームに大量の容量を事前に伝え、それに応じてデプロイを計画してボトルネックとして容量を排除することです。 これは、このトピックで説明されている以外の展開戦略に関する追加のガイダンスを取得する機会でもあります。

デプロイを複数のクラウド サービスに分散させる

次の理由から、複数のクラウド サービスを使用して、大規模なデプロイを複数の小規模なデプロイに分割することをお勧めします。

• ノードのグループの開始と停止を柔軟に行えるようにするため。

• ジョブの完了後にアイドル状態のインスタンスを停止できるようにする。

• 特に Extra Large インスタンスが使用されている場合に、Azure クラスターで使用可能なノードを見つけやすくするため。

• ディザスター リカバリーまたはビジネス継続性のシナリオで複数の Azure データ センターを使用できるようにするため。

クラウド サービスのサイズに固定の制限はありませんが、一般的なガイダンスは、500 から 700 個の仮想マシン インスタンス未満か、1,000 コア未満です。 大規模なデプロイでは、デプロイのタイムアウト、ライブ インスタンスの損失、仮想 IP アドレスのスワップに関する問題が発生する可能性があります。

1 つの HPC クラスター全体でテストされるクラウド サービスの最大数は 32 です。

場所に合わせて柔軟に対応

他のサービスやその他の地理的な要件に依存することは避けられない場合がありますが、Azure デプロイが特定のリージョンまたは地域に関連付けられていない場合に役立ちます。 ただし、それらの地理的リージョンに外部依存関係がある場合、または高可用性とディザスター リカバリーの要件がない限り、異なる地理的リージョンに複数のデプロイを配置することはお勧めしません。

仮想マシンのサイズに柔軟に対応する

特定の仮想マシン のサイズに厳密な依存関係 (たとえば、特大) があると、大規模なデプロイの成功に影響する可能性があります。 インスタンス数とコアのバランスを取るために、仮想マシンのサイズを柔軟に調整したり、組み合わせたりすることもできます。

ノードのデプロイに複数の Azure ストレージ アカウントを使用する

大規模な Azure ノードの同時デプロイとカスタム アプリケーションには、異なる Azure ストレージ アカウントを使用することをお勧めします。 I/O によって制約されている特定のアプリケーションでは、複数のストレージ アカウントを使用します。 さらに、ベスト プラクティスとして、Azure ノードのデプロイに使用されるストレージ アカウントは、ノード プロビジョニング以外の目的で使用しないでください。 たとえば、Azure Storage を使用して、ヘッド ノード間または Azure ノードとの間でジョブとタスクのデータを移動する場合は、その目的のために別のストレージ アカウントを構成します。

デプロイをサポートするようにプロキシ ノード インスタンスの数を調整する

プロキシ ノードは、オンプレミスのヘッド ノードと Azure ノード間の通信を容易にするために、HPC クラスターから各 Azure ノードデプロイに自動的に追加される Azure worker ロール インスタンスです。 プロキシ ノード上のリソースの需要は、Azure にデプロイされたノードの数と、それらのノードで実行されているジョブによって異なります。 通常、大規模な Azure デプロイではプロキシ ノードの数を増やす必要があります。

HPC Pack 2012 では、各 Azure ノード デプロイ (クラウド サービス) 内のプロキシ ノードの数を構成するための HPC 管理ツールが導入されました。 (HPC Pack 2008 R2 では、この数はデプロイごとに 2 つのプロキシ ノードに自動的に設定されます)。プロキシ ノードのロール インスタンスの数は、ノードを再デプロイすることなく、Azure 管理ポータルのツールを使用してスケールアップまたはスケールダウンすることもできます。 1 つのデプロイで推奨されるプロキシ ノードの最大数は 10 です。

大規模または頻繁に使用されるデプロイでは、次の表に示すプロキシ ノードの数を超える必要があります。これは、CPU 使用率が 50% 未満で、帯域幅がクォータより小さい場合に基づいています。

プロキシ ノードの構成オプションの詳細については、「 Azure プロキシ ノードの数を設定する」を参照してください。

大規模なデプロイ用にヘッド ノードを構成するためのベスト プラクティス

Azure ノードの大規模なデプロイでは、クラスターのヘッド ノード (またはヘッド ノード) に大きな需要が必要な場合があります。 ヘッド ノードは、デプロイをサポートするためにいくつかのタスクを実行します。

• Azure デプロイで作成されたプロキシ ノード インスタンスにアクセスして、Azure ノードとの通信を容易にします (このトピック の「デプロイをサポートするようにプロキシ ノード インスタンスの数を調整する」を参照してください)。

• BLOB (ランタイム パッケージなど)、キュー、テーブル データの Azure ストレージ アカウントにアクセスします。

• ハートビートの間隔と応答、プロキシの数 (HPC Pack 2012 以降)、デプロイの数、およびノードの数を管理します。

Azure デプロイのサイズとスループットが大きくなると、HPC クラスター ヘッド ノードに対する負荷が増加します。 一般に、ヘッド ノードがデプロイをサポートできるようにするために必要な重要な要素は次のとおりです。

• 十分な RAM

• 十分なディスク領域

• HPC クラスター データベース用に適切なサイズの適切に管理された SQL Server データベース

ヘッド ノードのハードウェア仕様

大規模な Azure デプロイをサポートするためのヘッド ノードの推奨される最小仕様を次に示します。

• 8 CPU コア

• 2 個のディスク

• 16 GB の RAM

リモート SQL Server データベースを構成する

大規模なデプロイでは、ヘッド ノードにクラスター データベースをインストールするのではなく、Microsoft SQL Server を実行しているリモート サーバーにクラスター データベースをインストールすることをお勧めします。 クラスターの SQL Server のエディションを選択して構成するための一般的なガイドラインについては、「 Microsoft HPC Pack のデータベース容量計画とチューニング」を参照してください。

追加のクラスター ロール用にヘッド ノードを構成しないでください

ほとんどの運用環境デプロイの一般的なベスト プラクティスとして、ヘッド ノードは追加のクラスター ロール (コンピューティング ノード ロールまたは WCF ブローカー ノード ロール) で構成しないことをお勧めします。 ヘッド ノードを複数の目的に使用すると、プライマリ管理ロールを正常に実行できなくなる可能性があります。 ヘッド ノードによって実行されるロールを変更するには、まず、HPC クラスター マネージャーの Resource Management (一部のバージョンの HPC Pack では ノード管理 と呼ばれます) のアクションを使用して、ノードをオフラインにします。 次に、ヘッド ノードを右クリックし、[ ロールの変更] をクリックします。

さらに、ヘッド ノードからクラスター ストレージを移動すると、ヘッド ノードの領域が不足せず、効果的に動作します。

HPC クライアント ユーティリティを使用してヘッド ノードにリモート接続する

ヘッド ノードが高負荷で動作している場合、多くのユーザーがリモート デスクトップ接続に接続することで、そのパフォーマンスに悪影響を及ぼす可能性があります。 ユーザーがリモート デスクトップ サービス (RDS) を使用してヘッド ノードに接続するのではなく、ユーザーと管理者はワークステーションに HPC Pack クライアント ユーティリティをインストールし、これらのリモート ツールを使用してクラスターにアクセスする必要があります。

パフォーマンス カウンターの収集とイベント転送を無効にする

大規模なデプロイでは、パフォーマンス カウンターの収集とイベント転送が HPC Management Service と SQL Server に大きな負担をかける可能性があります。 これらのデプロイでは、HPC クラスター管理ツールを使用してこれらの機能を無効にすることが望ましい場合があります。 たとえば、Set-HpcClusterProperty HPC PowerShell コマンドレットを使用して CollectCounters クラスター プロパティを false に設定します。 パフォーマンスの向上と、発生した問題のトラブルシューティングに役立つ可能性のあるメトリックの収集にはトレードオフがある可能性があります。

不要なヘッド ノード サービスを無効にする

オペレーティング システムからのハードウェアフットプリントを最小限に抑え、一般的な HPC クラスターのベスト プラクティスとして、HPC クラスターの操作に必要のないオペレーティング システム サービスを無効にします。 特に、有効になっている可能性があるデスクトップ指向の機能を無効にすることをお勧めします。

ヘッド ノードで NAT を実行しない

HPC Pack では、ヘッド ノードで実行されているルーティングおよびリモート アクセス サービス (RRAS) を迅速に構成してネットワーク アドレス変換 (NAT) を提供し、コンピューティング ノードがエンタープライズ ネットワークに到達できるようにできますが、これにより、ヘッド ノードがネットワーク帯域幅の重要なボトルネックになり、パフォーマンスにも影響する可能性があります。 コンピューティング ノードとパブリック ネットワーク間のトラフィックが多い大規模なデプロイまたはデプロイの一般的なベスト プラクティスとして、次のいずれかの方法をお勧めします。

• 各コンピューティング ノードに直接パブリック ネットワーク接続を提供します。

• Windows Server オペレーティング システムを実行し、2 つのネットワーク上でデュアルホーム化され、RRAS を実行している別のサーバーなど、専用の NAT ルーターを提供します。

完了したジョブに対して適切なストレージ期間を確保する

cluscfg コマンドと Set-HpcClusterProperty HPC コマンドレットの TtlCompletedJobs プロパティは、完了したジョブが HPC クラスターの SQL Server データベースに残っている期間を制御します。 このプロパティに大きな値を設定すると、ジョブ情報がシステム内で長時間維持され、レポート目的に適している可能性があります。 ただし、データベース (およびそれに対するクエリ) は一般的に大きくなるため、システム内のジョブの数が多いと、システムのストレージとメモリの要件が増加します。

ノードに到達不能をマークする前に、適切な数のハートビートを構成する

HPC Pack では、ハートビート信号を使用してノードの可用性を確認します。 HPC ジョブ スケジューラ サービスによるこの定期的な正常性プローブに対するコンピューティング ノードの応答がない場合、ノードに到達不能としてマークされるかどうかが決まります。 HPC クラスター マネージャーでジョブ スケジューラ構成でハートビート オプションを構成するか、 cluscfg コマンドまたは Set-HpcClusterProperty HPC コマンドレットを使用して、クラスター管理者は、ハートビートの頻度 (HeartbeatInterval) とノードが到達不能としてマークされるまでにノードがミスするハートビートの数 (InactivityCount) を設定できます。 たとえば、クラスターに大規模な Azure デプロイが含まれている場合、30 秒の既定の HeartbeatInterval を 2 分に増やすことができます。 既定 の InactivityCount は 3 に設定されています。これは、一部のオンプレミスデプロイに適していますが、Azure ノードをデプロイするときに 10 以上に増やす必要があります。

フェールオーバー クラスターでヘッド ノードまたは WCF ブローカー ノードが高可用性用に構成されている場合は、フェールオーバー クラスター内の他のコンピューター (またはコンピューター) の可用性を監視するために、各フェールオーバー クラスター コンピューターで使用されるハートビート信号も考慮する必要があります。 既定では、1 台のコンピューターが 5 つのハートビートを逃した場合、1 秒に 1 回、そのコンピューターとの通信が失敗したと見なされます。 フェールオーバー クラスター マネージャーを使用すると、大規模な Azure デプロイを使用するクラスターで、ハートビートの頻度を減らしたり、ハートビートの不足の数を増やすことができます。

Azure ノードでサービス指向アーキテクチャ (SOA) ジョブを実行している場合は、大規模なセッションを管理するために、サービス登録ファイルの監視タイムアウト設定の調整が必要になる場合があります。 SOA サービス構成ファイルの詳細については、「 Windows HPC Server 2008 R2 の SOA サービス構成ファイル」を参照してください。

ファイル ステージング操作のパフォーマンスを向上させるためにレジストリ キーを構成する

HPC Pack 2008 R2 SP2 以降では、ヘッド ノード コンピューターにレジストリ キーを設定して、Azure ノードの大規模なデプロイでの診断テスト、 clusrun 操作、 hpcfile ユーティリティのパフォーマンスを向上させることができます。 これを行うには、 FileStagingMaxConcurrentCalls という新しい DWORD 値を HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HPCに追加します。 デプロイする予定の Azure ノード数の 50% から 100% までの値を構成することをお勧めします。 構成を完了するには、 FileStagingMaxConcurrentCalls 値を 設定した後、HPC ジョブ スケジューラ サービスを停止してから再起動する必要があります。

こちらもご覧ください

Microsoft HPC Pack を使用して Azure Worker インスタンスにバーストする
Azure Cloud Services での Large-Scale サービスの設計に関するベスト プラクティス
Windows Azure ビジネス継続性に関するテクニカル ガイダンス