Azure Batch のプールとノードのエラー

  • [アーティクル]

注意

この記事では、間もなくサポート終了 (EOL) 状態になる Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。

一部の Azure Batch プールの作成と管理の操作はすぐに実行されます。 これらの操作のエラーは簡単に検出できます。通常は、API、コマンド ライン、またはユーザー インターフェイスからすぐにエラーが返されるためです。 ただし、一部の操作は非同期的にバック グラウンドで実行され、完了までに数分かかります。 この記事では、プールとノードのバックグラウンド操作で発生する可能性のあるエラーを検出して回避する方法について説明します。

必ず、包括的なエラー チェック (特に非同期操作に対するもの) を実施するようにアプリケーションを設定してください。 包括的なエラー チェックは、問題を迅速に特定して診断するのに役立ちます。

プールのエラー

プールのエラーは、サイズ変更のタイムアウトやエラー、自動スケーリングのエラー、またはプールの削除エラーに関連していると考えられます。

タイムアウトまたはエラーのサイズ変更

新しいプールを作成する場合や既存のプールのサイズ変更を行う場合は、ノードのターゲット数を指定します。 作成やサイズ変更の操作はすぐに完了しますが、新しいノードを実際に割り当てたり既存のノードを削除したりするには数分かかる場合があります。 サイズ変更タイムアウトは、Pool - Add または Pool - Resize API で指定できます。 サイズ変更タイムアウトの期間中に、Batch でターゲットとする数のノードを割り当てられない場合、プールが定常状態に移行し、サイズ変更エラーが報告されます。

ResizeError プロパティに、直近の評価で発生したエラーが列挙されます。

サイズ変更エラーの一般的な原因は次のとおりです。

  • サイズ変更タイムアウトが短すぎる。 通常、既定のタイムアウトである 15 分は、プール ノードの割り当てまたは削除を行うのに十分な長さです。 多数のノード、たとえば、Azure Marketplace イメージから 1,000 を超えるノードや、カスタム仮想マシン (VM) イメージから 300 を超えるノードなどを割り当てる場合は、サイズ変更タイムアウトを 30 分に設定できます。

  • コア クォータが十分でない。 Batch アカウントにはすべてのプールに対して割り当てることができるコアの数に制限があり、そのクォータに達するとノードの割り当てが停止されます。 Batch でさらに多くのノードを割り当てられるように、コア クォータを増やすことができます。 詳しくは、「Batch サービスのクォータと制限」をご覧ください。

  • プールが仮想ネットワーク内にある場合にサブネット IP アドレスが不足している。 仮想ネットワーク サブネットには、要求されたすべてのプールのノードに割り当てるための IP アドレスが十分に存在する必要があります。 そうでない場合、ノードを作成できません。 詳細については、「仮想ネットワーク内に Azure Batch プールを作成する」を参照してください。

  • プールが仮想ネットワーク内にある場合にリソースが十分でない。 プールを仮想ネットワーク内に作成する際に、ロード バランサー、パブリック IP、ネットワーク セキュリティ グループ (NSG) などのリソースを、Batch アカウントと同じサブスクリプションに作成する場合があります。 これらのリソースのためのサブスクリプション クォータが十分であるか確認してください。

  • カスタム VM イメージを使用した大規模なプール。 カスタム VM イメージを使用する大規模なプールは割り当てに時間がかかり、タイムアウトのサイズ変更が発生することがあります。 制限と構成に関する推奨事項については、Azure Compute Gallery を使用したプール作成に関するページを参照してください。

自動スケールの失敗

プール内のノード数を自動的にスケーリングするように Azure Batch を設定でき、プールの自動スケーリング式のパラメーターを定義します。 Batch サービスではその数式を使用して、プール内のノード数を定期的に評価し、新しいターゲット数を設定します。 詳細については、Batch プール内のコンピューティング ノードをスケーリングするための自動式の作成に関するページを参照してください。

自動スケーリングを使用すると、次の問題が発生する可能性があります。

  • 自動スケール評価が失敗する。
  • 結果のサイズ変更操作が失敗してタイムアウトになることがある。
  • 自動スケールの数式に問題があるため、ノードのターゲット値が正しくなくなる。 サイズ変更は、正常に行われるかタイムアウトになります。

最後の自動スケール評価に関する情報を取得するには、autoScaleRun プロパティを使用します。 このプロパティは、評価期間、値と結果、およびパフォーマンス エラーを報告します。

プールのサイズ変更完了イベントにより、すべての評価に関する情報がキャプチャされます。

プール削除の失敗

Batch では、ノードを含むプールを削除する場合、最初にノードを削除します。削除が完了するのに数分かかる場合があります。 この後に、Batch でプール オブジェクト自体が削除されます。

削除プロセス中、Batch では poolState を deleting に設定します。 プールの削除時間がかかりすぎている場合、呼び出しアプリケーションが state と stateTransitionTime プロパティを使用して検出します。

プールの削除に予想以上の時間がかかる場合、プールが正常に削除されるまで、Batch で定期的に再試行されます。 Azure サービスの停止やその他の一時的な問題のために遅延が発生することもあります。 プールの正常な削除を妨げるその他の要因がある場合、問題を修正するためのアクションが必要になる可能性があります。 これらの要因として、次の問題があります。

  • Batch によって作成されたリソースまたは Batch で使用されているネットワーク リソースにリソース ロックが適用されている可能性があります。

  • 作成したリソースが、Batch によって作成されたリソースに依存している可能性があります。 たとえば、仮想ネットワークでプールを作成すると、Batch で NSG、パブリック IP アドレス、ロード バランサーが作成されます。 これらのリソースをプールの外部で使用している場合、プールを削除できません。

  • プールが含まれるサブスクリプションから、Microsoft.Batch リソースプロバイダーの登録が解除された可能性があります。

  • ユーザー サブスクリプション モードの Batch アカウントの場合、Microsoft Azure Batch には今後、プールが含まれるサブスクリプションの共同作成者または所有者ロールが与えられません。 詳細については、「Batch にサブスクリプションへのアクセスを許可する」を参照してください。

ノード エラー

Batch でプール内のノードが正常に割り当てられた場合でも、さまざまな問題が原因で一部のノードが異常な状態になったり、タスクを実行できなくなったりする場合があります。 これらのノードによって引き続き料金が発生してしまうので、使用できないノードに対する支払いを回避するために問題を検出することが重要です。 一般的なノード エラーについて知り、現在の jobState を把握しておくと、トラブルシューティングに役立ちます。

開始タスクの失敗

プールにはオプションの startTask を指定できます。 他のタスクと同様に、開始タスクでもコマンド ラインを使用し、ストレージからリソース ファイルをダウンロードできます。 開始タスクは、ノードの起動時に各ノードに対して実行されます。 waitForSuccess プロパティは、Batch がすべてのタスクをノードにスケジュールする前に、タスクの開始が正常に完了するまで Batch が待機するかどうかを指定します。 開始タスクが正常に完了するまで待機するようにノードを構成していて、開始タスクが失敗した場合、ノードは使用できませんが、その場合も料金は発生します。

開始タスクの失敗は、最上位レベルの startTaskInfomation ノード プロパティの taskExecutionResult と taskFailureInformation プロパティを使って検出できます。

また、waitForSuccess が true に設定された場合、開始タスクに失敗すると、Batch で computeNodeState が starttaskfailed に設定されます。

すべてのタスクと同様、開始タスクの失敗には多くの原因があります。 トラブルシューティングを実行するには、stdout、stderr、さらにタスク固有の他のログ ファイルをチェックしてください。

開始タスクは同じノードで複数回 (ノードの再イメージ化時や再起動時など) 実行される可能性があるため、再入可能である必要があります。 まれに、イベントの発生後に開始タスクが実行されたためにノードの再起動が行われた場合、一方のオペレーティング システム (OS) またはエフェメラル ディスクは再イメージ化されますが、もう一方は再イメージ化されません。 Batch 開始タスクとすべての Batch タスクはエフェメラル ディスクから実行されるため、通常、この状況は問題になりません。 ただし、開始タスクでアプリケーションが OS ディスクにインストールされ、他のデータがエフェメラル ディスクに保持される場合、同期の問題が発生するおそれがあります。 両方のディスクを使用する場合は、アプリケーションを適切に保護してください。

アプリケーション パッケージのダウンロード エラー

プール用の 1 つ以上のアプリケーション パッケージを指定できます。 Batch では、指定されたパッケージ ファイルを各ノードにダウンロードし、ノードの開始後、タスクをスケジュールする前にファイルを圧縮解除します。 一般には、別の場所へのファイルのコピーやセットアップの実行などのために、開始タスク コマンドをアプリケーション パッケージと共に使用します。

アプリケーション パッケージのダウンロードと圧縮解除が失敗した場合、computeNodeError プロパティでエラーが報告され、ノードの状態が unusable に設定されます。

コンテナーのダウンロード エラー

プールには、コンテナーの参照を 1 つまたは複数指定できます。 指定したコンテナーが Batch によって各ノードにダウンロードされます。 コンテナーのダウンロードが失敗した場合、computeNodeError プロパティでエラーが報告され、ノードの状態が unusable に設定されます。

ノード OS の更新

Windows プールの場合、enableAutomaticUpdates は既定で true に設定されます。 自動更新を許可することをお勧めしますが、更新が実行されると、特に実行時間の長いタスクでは、タスクの進行が中断されるおそれがあります。 OS の更新が予期せずに行われないようにする必要がある場合は、この値を false に設定できます。

ノードは使用できない状態

Batch では、さまざまな理由で computeNodeState を unusable に設定します。 unusable のノードに対してタスクをスケジュールすることはできませんが、その場合もノードの料金は発生します。

Batch で原因が特定できると、computeNodeError プロパティにその報告が表示されます。 ノードが unusable 状態でも computeNodeError がない場合、Batch が VM と通信できないことを意味します。 このケースでは、Batch によって常に VM の復旧が試みられます。 ただし、アプリケーション パッケージまたはコンテナーのインストール エラーが発生した VM については、その状態が unusable であっても、Batch で自動的に復旧が試みられません。

unusable ノードのその他の理由として、次のような原因が考えられます。

  • カスタム VM イメージが無効である。 たとえば、イメージが適切に準備されていません。
  • インフラストラクチャの障害または低レベルのアップグレードのため、VM が移動した。 Batch はノードを回復します。
  • VM イメージが、それをサポートしないハードウェアにデプロイされている。 たとえば、CentOS HPC イメージが Standard_D1_v2 の VM にデプロイされています。
  • VM が Azure Virtual Network に存在し、重要なポートへのトラフィックがブロックされている。
  • VM は仮想ネットワークに存在するが、Azure Storage へのアウトバウンド トラフィックがブロックされている。
  • カスタム DNS 構成を使用した仮想ネットワークに VM が存在し、DNS サーバーが Azure Storage を解決できない。

ノード エージェント ログ ファイル

各プール ノードで実行される Batch エージェント プロセスによってログ ファイルが作成され、プール ノードの問題についてサポートに連絡する必要があるときに、そのファイルが役立つ可能性があります。 ノードのログ ファイルは、Azure portal、Batch Explorer、または Compute Node - Upload Batch Service Logs API を使用してアップロードできます。 ログ ファイルをアップロードして保存したら、ノードまたはプールを削除するとノードの実行コストを節約できます。

ノードのディスクがいっぱいである

Batch では、ノード プール VM 上の一時ドライブを使用して、次のジョブ ファイル、タスク ファイル、共有ファイルなどのファイルを保存します。

  • アプリケーション パッケージ ファイル
  • タスク リソース ファイル
  • Batch のいずれかのフォルダーにダウンロードされたアプリケーション固有のファイル
  • タスク アプリケーションの実行ごとの stdout ファイルと stderr ファイル
  • アプリケーション固有の出力ファイル

アプリケーション パッケージや開始タスク リソース ファイルなどのファイルは、Batch でプール ノードが作成されるときに 1 回だけ書き込まれます。 1 回しか書き込まれなかったとしても、ファイルが大きすぎると、それだけで一時ドライブがいっぱいになってしまう可能性があります。

stdout や stderr などの他のファイルは、ノードで実行されるタスクごとに書き込まれます。 同じノード上で大量のタスクが実行された場合や、タスクのファイルが大きすぎる場合、一時ドライブがいっぱいになってしまう可能性があります。

また、ノードには、その起動後にユーザーを作成するための少量の領域が OS ディスク上に必要です。

一時ドライブのサイズは、VM のサイズによって異なります。 計画したワークロード用に一時ドライブの容量を十分に確保することが、VM のサイズを選ぶ際の 1 つの考慮事項となります。

Azure portal でプールを追加するときに、[リソース ディスク サイズ] 列を含む、すべての VM サイズの一覧を表示できます。 VM サイズについて説明する記事には、一時ストレージの列を含む表が記載されています。 詳しくは、「コンピューティング最適化済み仮想マシンのサイズ」をご覧ください。 サイズ表の例については、「Fsv2 シリーズ」を参照してください。

各タスクによって書き込まれたファイルの保持時間を指定できます。 この保持時間は、タスク ファイルが自動的にクリーンアップされるまでの保持期間を決定します。 保持時間を短縮すると、ストレージの所要量を減らすことができます。

一時ディスクまたは OS ディスクの空き領域が不足しているか、領域不足に近づいている場合、ノードは unusablecomputeNoteState に移行し、ノード エラーにディスクがいっぱいであることが示されます。

ノード上の領域が何によって占有されているかわからない場合、ノードにリモート接続して、手動で調査を試みます。 また、File - List From Compute Node API を使用して、Batch 管理フォルダー内のファイル (タスク出力など) を調べることもできます。 この API では、Batch 管理ディレクトリ内のファイルのみが一覧表示されます。 タスクで他の場所に作成されたファイルは、この API を使用して表示されません。

ノードから必要なデータを取得したこと、またはそのデータを永続ストアにアップロードしたことを確認したら、必要に応じてデータを削除して領域を解放できます。

タスク データがまだノード上にある完了済みの古いジョブやタスクは削除してかまいません。 ノードの taskInformation 内の recentTasks コレクションを調べるか、File - List From Compute Node API を使用します。 ジョブを削除すると、ジョブ内のすべてのタスクが削除されます。 ジョブ内のタスクを削除すると、ノード上のタスク ディレクトリ内のデータが削除され、領域が解放されます。 十分な領域を解放したら、ノードを再起動します。 ノードは unusable 状態から、もう一度 idle に移行します。

VirtualMachineConfiguration プール内の使用不可のノードを回復するために、Pool - Remove Nodes API を使用してプールからノードを削除できます。 その後、もう一度プールを拡張して、不良ノードを新しいノードに置き換えることができます。 CloudServiceConfiguration プールの場合は、Compute Node - Reimage API を使用してノードを再イメージ化し、ディスク全体をクリーンにすることができます。 VirtualMachineConfiguration プールについては、現在、再イメージ化はサポートされていません。

次のステップ