次の方法で共有

構成の問題により、Azure Batch ノードが使用できない状態でスタックする

Azure Batch Batch ノードの状態 いくつかの理由で Unusable に設定される場合があります。 タスクを Unusable 状態のノードにスケジュールすることはできませんが、引き続き料金が発生します。 ほとんどの場合、Batch サービスはノードの復旧を試みます。 ただし、 Unusable 状態が構成の問題によって発生した場合、ノードを復旧することはできません。 この記事では、ノードが使用できなくなる一般的な構成の問題について説明し、解決策を提供します。

問題 1: 仮想ネットワークの構成に関する問題

このセクションでは、 classic と simplified ノード通信モードの両方での仮想ネットワーク (VNet) の構成の問題について説明します。

クラシック ノード通信

クラシック ノード通信モードは、VNet のサブネットに関連付けられているプールの元の通信方法です。 この機能は、2026 年に簡略化された通信ノード モードに置き換えられます。

VNet のサブネットに関連付けられているプールでは、すべてのノードが Unusable 状態になります。 ただし、ノードに エラー コードはありません。

ノードの状態を示すスクリーンショット。

上記の現象は、Batch サービスがノードと通信できないことを意味します。 ほとんどの場合、VNet の構成の問題が原因です。 次のセクションでは、最も一般的な 2 つの原因について説明します。

原因 1: 必要なネットワーク セキュリティ グループ (NSG) 規則がありません

NSG がサブネットで構成されている場合は、Batch サービスがノードと通信できるように、少なくとも受信と送信のセキュリティ規則 (次のスクリーンショットに示すように) を持つようにこの NSG を構成する必要があります。 指定したサブネット内のノードへの通信が NSG によって拒否された場合、Batch サービスはノードの状態を Unusable に設定します。

  • 受信セキュリティ規則

    受信セキュリティ規則のスクリーンショット。

  • 送信セキュリティ規則

    送信セキュリティ規則のスクリーンショット。

解決策 1: 必要な受信と送信のセキュリティ規則を持つ NSG を構成する

この問題を解決するには、「 仮想マシン構成プールのネットワーク セキュリティ グループ: サブネット レベルの規則の指定で推奨されているように、必要な受信と送信のセキュリティ規則を持つ NSG を構成します。

構成を実行するには、次の手順に従います。

  1. Azure portal からプールに移動します。

  2. プールのプロパティを調べて、VNet とサブネットの名前を取得します。

    ネットワーク構成のスクリーンショット。

  3. VNet に移動します。 [VNet] ページで、[ Settings>Subnets を選択します。 サブネットの一覧で、想定されるサブネットを選択します。 サブネット ウィンドウで、NSG を見つけます。

    サブネット情報のスクリーンショット。

  4. NSG に移動します。 NSG ページで構成を確認します。

    NSG 構成のスクリーンショット。

  5. この NSG を構成して、必要な受信および送信のセキュリティ規則を設定します。

  6. ノードを再起動して、既定の状態に戻します。

原因 2: 必要なユーザー定義ルート (UDR) がありません

プールが関連付けられている VNet で強制トンネリングが有効になっている場合は、Batch アカウントが存在するリージョンの BatchNodeManagement.<region> サービス タグに対応する UDR を追加する必要があります。 それ以外の場合、Batch サービスとノード間のトラフィックはブロックされ、コンピューティング ノードは使用できなくなります。

解決策 2: BatchNodeManagement.< に対応する UDR を追加するregion> サービス タグ

この問題を解決するには、Batch アカウントが存在するリージョンの BatchNodeManagement.<region> サービス タグに対応する UDR を追加します。 次に、 次ホップの種類 を Internet に設定します。 詳細については、「 強制トンネリングのユーザー定義ルートを参照してください。

これを行うには、次の手順を実行します。

  1. Azure portal からプールに移動します。

  2. プールのプロパティを調べて、VNet とサブネットの名前を取得します。

    ネットワーク構成のスクリーンショット。

  3. VNet に移動します。 [VNet] ページで、[ Settings>Subnets を選択します。 サブネットの一覧で、予想されるサブネットに関連付けられているルート テーブルを選択します。

    サブネットとそのルート テーブルを示すスクリーンショット。

  4. ルート テーブル ページで、 Routes>Add を選択します。 ルートの追加 ペインで、必要な UDR を追加し、次ホップの種類を Internet に設定します。

    UDR を追加する方法を示すスクリーンショット。

  5. ノードを再起動して、既定の状態に戻します。

ノード通信の簡略化

簡略化されたノード通信モードを使用すると、プール内の VNet 構成を簡略化できます。 簡略化されたノード通信モードを使用するプール内のノードに Unusable 状態が表示される場合は、次の考えられる原因と解決策を確認して自己トラブルシューティングを行います。

原因 1: 送信 NSG 規則がない

VNet を適用するときは、内部ノードから外部への送信要求を正しく構成する必要があります。 それ以外の場合、ノードは使用できなくなります。

解決策 1: 送信サービス タグ BatchNodeManagement.<を追加する地域>

この問題を解決するには、送信 NSG 規則に BatchNodeManagement.<region> サービス タグを追加します。

送信要求をブロックする NSG ルールを示すスクリーンショット。

詳細については、「 送信セキュリティ規則」を参照してください。

原因 2: Batch ノード管理の送信アクセスが見つからない

この原因は、Batch プールにパブリック IP アドレスがないシナリオにのみ適用されます。 既定では、Azure Batch 仮想マシン構成プール内のすべてのノードにパブリック IP アドレスが割り当てられます。 ただし、ユーザーはパブリック IP アドレスなしでプールをプロビジョニングして、これらのノードへのアクセスを制限し、インターネット上のこれらのノードの検出可能性を減らすことができます。 パブリック IP アドレスのないプールでは、既定でインターネット送信アクセスが有効になっていないので、Batch ノードと Batch ノード管理サービス間のネットワーク通信の問題が発生します。

解決策 2: ノード管理プライベート エンドポイントを構成する

Batch アカウントに移動し、 Settings>Networking を選択して、ネットワーク設定を確認します。 選択されたネットワークまたは Disable オプションが有効になっているが、batchAcountプライベート エンドポイントのみを構成するか、プライベート エンドポイントを構成しない場合は、ノード間の内部通信を確保するようにnodeManagementプライベート エンドポイントを構成します。

原因 3: 不適切な DNS 構成により、ノードがノード管理エンドポイントと通信できなくなる

DNS が正しく構成されていない場合、ノードは Batch サービス エンドポイントと通信できない可能性があります。 この状況により、Batch ノードが使用できない状態でスタックします。

Note

このシナリオは、ノード管理プライベート エンドポイントを有効にするバッチ プール用です。 通常、これらのプールではノード通信が簡素化され、パブリック IP アドレスは使用されません。

解決策 3: DNS 構成を修正する

DNS 名前解決が正しく機能するかどうかを確認し、必要に応じて DNS 構成を修正します。 DNS 構成を確認する正しいプロセスは、自動プライベート DNS 統合とカスタム DNS 構成のどちらを使用してノード管理プライベート エンドポイントを作成したかによって異なります。

プライベート DNS の自動統合の手順 次の手順に従って、自動プライベート DNS 統合が正しく構成されていることを確認します。

  1. プライベート エンドポイントがプライベート DNS ゾーン privatelink.batch.azure.comに統合されていることを確認します。

    ノード管理プライベート エンドポイントの DNS 構成ページ (自動構成バージョン) の Azure portal のスクリーンショット。

  2. このプライベート DNS ゾーンが、バッチ プールで使用されるのと同じまたはピアリングされた VNet にリンクされていることを確認します。

    プライベート DNS ゾーンの [仮想ネットワーク リンク] ページの Azure portal のスクリーンショット。

カスタム DNS 構成の手順 次の手順に従って、カスタム DNS が正しく構成され、プライベート エンドポイントの IP アドレスを指しているかどうかを確認します。

  1. Azure ポータルでBatch アカウントを検索して選択します。

  2. Batch アカウントの一覧で、Batch アカウントの名前を選択します。

  3. Batch アカウントの Overview ページで、 Essentials セクションを見つけて、 Node 管理エンドポイント フィールドの値をコピーします。 (この値は通常、次の形式の URL です: <guid>.<region>.service.batch.azure.com)。

    Batch アカウントの [概要] ページの Azure portal のスクリーンショット。ノード管理エンドポイントの値が強調表示されています。

  4. Batch アカウントのナビゲーション ウィンドウで、 Settings 見出しを見つけて、 Networking を選択します。 Networking ページで、[Private access] タブを選択し、プライベート エンドポイントの一覧でノード管理プライベート エンドポイントを選択します。

    Batch アカウントの [ネットワーク] ページの Azure portal のスクリーンショット。[プライベート アクセス] タブとノード管理のプライベート エンドポイントが強調表示されています。

  5. プライベート エンドポイントのナビゲーション ウィンドウで、 Settings 見出しを見つけて、 DNS 構成を選択します。 DNS 構成 ページで、Customer Visible FQDNs セクションを見つけて、ノード管理プライベート エンドポイントのネットワーク インターフェイスの IP アドレス列の値をコピーします。

    ノード管理プライベート エンドポイントの DNS 構成ページ (手動構成バージョン) の Azure portal のスクリーンショット。

  6. プールが作成されるのと同じサブネット内に、Batch ノードまたは仮想マシン (VM) を作成します。 次に、VM に接続し、PowerShell コンソール (Windows) またはシェル コンソール (Linux) を開きます。

  7. 次の nslookup コマンドを実行して、DNS 名前解決をテストします。 (Windows では、nslookup は既定でインストールされます。Linux では、nslookup をインストールするか、他のツールを使用します)。

    nslookup <node-management-endpoint-url>

    予想される結果は、ノード管理プライベート エンドポイントのプライベート IP アドレスの場合と同じです。

    PS C:\Users\xxx> nslookup <node-management-endpoint-url>
Server:  UnKnown
Address:  x.x.x.x

Name:     <node-management-endpoint-url>
Address:  <private-ipnode-management-endpoint-private-ip>
Aliases:  <node-management-endpoint-url>

  8. ポート 443 でノード管理エンドポイント URL への接続をテストします。 これを行うには、Windows で Test-NetConnection コマンドレットを実行するか、Linux で Netcat (nc) コマンドを実行します。

    Test-NetConnection -ComputerName <node-management-endpoint-url> -Port 443

    nc -v <node-management-endpoint-url> 443

    次の出力例に示すように、期待される結果は正常な接続になります。

    PS C:\Users\xxx> Test-NetConnection -ComputerName <node-management-endpoint-url> -Port 443

ComputerName     : <node-management-endpoint-url>
RemoteAddress    : <private-ipnode-management-endpoint-private-ip>
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : <vm-private-ip>
TcpTestSucceeded : True

  9. 前の 2 つの手順を試した後に問題が発生した場合は、次の表のトラブルシューティング ガイダンスを適用します。

    問題のシナリオ トラブルシューティング ガイダンス
    nslookup コマンドの結果が想定どおりではありません。 バッチ プールの VNet のカスタム DNS 設定を確認します。 確認する値には、次の項目が含まれます。
    • プライベート DNS ゾーン名
    • カスタム DNS サーバー
    • DNS 名前解決に影響する可能性があるその他のサービスまたはコンポーネント
    nslookup コマンドの結果が必要ですが、 Test-NetConnection コマンドレットまたは nc コマンドの結果は予期しません。 VNet からの送信接続をブロックできるサービス (ネットワーク セキュリティ グループやファイアウォールなど) が存在するかどうかを確認します。

詳細については、「 ノード管理プライベート エンドポイントをトラブルシューティングする」を参照してください。

問題 2: ディスクがいっぱいの問題

ノードが Unusable 状態であり、ノードに次のエラー メッセージが表示されます。

Code: DiskFull
メッセージ:
ノードに十分なディスク領域がない
[値]:
メッセージ - VM ディスクがいっぱいです。 ノード上のジョブ、タスク、またはファイルを削除して、スペースを解放してからノードを再起動します。

原因: ノードに十分なディスク領域がない

ノードでジョブを実行すると、ジョブ内の各タスクが出力データを生成できます。 この出力データは、Batch ノードのファイル システムに書き込まれます。 このデータがノード SKU のディスク サイズの 90% を超える容量に達すると、Batch サービスはノードを使用不可としてマークし、Batch サービスがクリーンアップを実行するまでノードが他のタスクを実行するのをブロックします。

Batch ノード エージェントは、その機能のためにディスク領域の 10% の容量を予約します。 タスクを実行するようにスケジュールする前に、Batch ノードの容量に応じて、ディスクに十分な領域を確保することが不可欠です。 タスクの設計時に従うベスト プラクティスについては、「 Tasks」を参照してください。

解決策: タスク フォルダー内のファイルをクリアする

この問題を解決するには、次の手順を実行します:

  1. RDP を使用してノードに接続します。

  2. ディスクで使用可能な領域を確認します。

    • ディスクに十分な空き領域がない場合は、手順 3 に進みます。

      次の例は、ディスクに十分な空き領域がないことを示しています。 この例では、Windows および Linux 用の VM SKU がStandard_D2s_V3され、ディスク サイズは 16 ギガバイト (GB) です。

      Windows の場合、次のスクリーンショットは、ディスクで使用可能な領域が 1 GB 未満であることを示しています。

      使用可能なディスク領域が 1 ギガバイト未満であることを示すスクリーンショット。

      Note

      Windows の場合は、エクスプローラーを使用してディスク領域を確認することもできます。

      Linux の場合、次のスクリーンショットは、マウントされたディスクの 100% が使用されていることを示しています。

      マウントされたディスクの 100% が使用されていることを示すスクリーンショット。

      Linux 上のタスク関連ファイルは、 ./mnt/batch/tasks/workitems/の下にあります。

    • タスクの実行に十分なディスク領域があるが、ノードが使用できない場合、Batch サービスはタスクの保持ポリシーに基づいてファイルをクリーンアップしている可能性があります。 この場合は、手順 4 に進みます。

  3. 各タスク フォルダーに移動し、ファイルをクリアします。

  4. ファイルがクリアされたら、ノードを再起動します。

    ノードが再起動されると、ノードは正常な状態になり、新しいタスクを受け入れることができます。

    正常な状態のノードのスクリーンショット。

問題 3: カスタム イメージ構成の問題

場合によっては、カスタム イメージ構成の問題 (正しくない準備など) によってノードが破損する可能性があります。 カスタム イメージでは、ノードを使用できなくなる可能性があるさまざまな変数が使用されます。

たとえば、Batch ノードが Unusable または Starting 状態にあり、ノードに次のエラー コードが表示されます。

コード:
BatchAgentInstallationFailure
メッセージ:
コンピューティング ノードでバッチ エージェント拡張機能のプロビジョニングに失敗しました

BatchAgentInstallationFailure エラー メッセージのスクリーンショット。

原因: カスタム イメージの OS SKU が、プールの作成時に選択された OS SKU と異なる

Azure portal を使用して Azure Batch プールを作成し、 Image Type を Custom Image – Shared Image Gallery に設定すると、Azure portal では OS SKU の検証は実行されません。 カスタム イメージで使用されている実際の OS SKU とは異なる OS SKU を選択した場合、Azure Batch は、カスタム イメージで使用されている実際の OS SKU ではなく、選択した OS SKU に一致する Batch ノード エージェントをインストールします。

次のスクリーンショットでは、カスタム イメージは Canonical の Ubuntu 20 Azure Marketplace イメージに基づいています。 OS sku を設定すると、Azure Batch は検証を実行しません。

プールの作成時にイメージの種類と OS SKU の設定を示すスクリーンショット。

解決策: カスタム イメージ OS SKU を持つプールを再作成する

この問題を解決するには、カスタム イメージで使用されている OS SKU を持つプールを再作成します。

カスタム イメージを作成する方法の詳細については、次の記事を参照してください。

問題 4: マネージド ID の構成に関する問題

リンクされた Azure Storage アカウント (自動ストレージ アカウントとも呼ばれます) の認証モードが Batch Account Managed Identity (次のスクリーンショットに示すように) に設定されている場合、プール ID の構成が正しくないとノードが使用できなくなります。 詳細については、 Behavior のシナリオを参照してください。

Batch ノードが Unusable 状態であり、ノードに次のエラー コードが表示されます。

Code: ApplicationPackageError
メッセージ:
プールに指定された 1 つ以上のアプリケーション パッケージが無効です
[値]:
ApplicationPackageReference - asdf:0.0.1
メッセージ - リソースのダウンロードに失敗しました

ApplicationPackageError のスクリーンショット。

原因: ノード ID 参照で定義されているマネージド ID がプール ID に追加されない

プールを作成するときに、複数のマネージド ID を指定できます。 ノード ID 参照で定義されているマネージド ID (自動ストレージ アカウントで構成) がプール ID に追加されていない場合、ノードは認証に正しいマネージド ID を使用できません。 これにより、アプリケーション パッケージのダウンロード プロセスが失敗し、ノードが使用できなくなります。

解決策: プールを再作成してマネージド ID を修正する

この問題を解決するには、ノード ID リファレンスで定義されている適切なマネージド ID (自動ストレージ アカウントで構成) を含むようにプールを再作成します。 Batch プールマネージド ID の使用方法の詳細については、「 バッチ プールでマネージド ID を設定するを参照してください。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。