仮想ネットワーク内に Azure Batch プールを作成する
Azure Batch プールを作成すると、指定した Azure 仮想ネットワークのサブネットでプールをプロビジョニングできます。 この記事では、Virtual Network で Batch プールを設定する方法について説明します。
Virtual Network を使用する理由
プール内の計算ノードは、複数インスタンスのタスクを実行するときなど、別の Virtual Network を必要とせずに相互通信できます。 ただし、プール内のノードは、既定では、ライセンス サーバーやファイル サーバーなど、プールの外部にあるすべての仮想マシン (VM) と通信できません。
計算ノードが他の仮想マシンと、あるいはオンプレミス ネットワークと安全に通信するために、Virtual Network のサブネットでプールをプロビジョニングできます。
前提条件
[認証] : Azure Virtual Network を使用するには、Batch クライアント API で Microsoft Entra 認証を使用する必要があります。 詳細については、「Batch サービスの認証に Active Directory を使用する」を参照してください。
Azure 仮想ネットワーク。 1 つまたは複数のサブネットを持つ Virtual Network を前もって用意するために、Azure Portal、Azure PowerShell、 Microsoft Azure CLI (CLI)、その他の方法を利用できます。
Azure Resource Manager ベースの Virtual Network を作成する方法については、仮想ネットワークの作成に関するページを参照してください。 Resource Manager ベースの Virtual Network は新しいデプロイで推奨され、仮想マシン構成を使用するプールでのみサポートされます。
クラシック Virtual Network を作成する方法については、「複数のサブネットを含んだ仮想ネットワーク (クラシック) を作成する」を参照してください。 クラシック Virtual Network は、Cloud Services 構成を使用するプールでのみサポートされます。
重要
Azure Batch プール VNet には 172.17.0.0/16 を使用しないでください。 これは Docker ブリッジ ネットワークの既定値であり、VNet に接続する他のネットワークと競合する可能性があります。 Azure Batch プール用の仮想ネットワークを作成するには、ネットワーク インフラストラクチャを慎重に計画する必要があります。
一般的な仮想ネットワークの要件
Virtual Network が存在するサブスクリプションとリージョンは、プールの作成に使用する Batch アカウントと同じである必要があります。
プールに指定されたサブネットには、プールの対象となる VM 数 (つまり、プールの
targetDedicatedNodesおよびtargetLowPriorityNodesプロパティの合計) を許容できる十分な未割り当て IP アドレスが必要です。 サブネットの未割り当て IP アドレスが十分でない場合、プールによってコンピューティング ノードが部分的に割り当てられ、サイズ変更エラーが発生します。Simplified 計算ノード通信を使用していない場合は、仮想ネットワークにサービスを提供するカスタム DNS サーバーを使用して Azure Storage エンドポイントを解決する必要があります。 具体的には、フォーム
<account>.table.core.windows.net、<account>.queue.core.windows.net、<account>.blob.core.windows.netの URL を解決できる必要があります。同じ仮想ネットワークまたは同じサブネットに複数のプールを作成できます (十分なアドレス空間がある場合)。 1 つのプールが複数の仮想ネットワークまたはサブネットにまたがって存在することはできません。
重要
Batch プールは、2 つのノード通信モードのいずれかで構成できます。 クラシック ノード通信モードでは、Batch サービスが計算ノードへの通信を開始します。 シンプル ノード通信モードでは、計算ノードが Batch サービスへの通信を開始します。
- Batch プールに使用される仮想ネットワークまたはピアリングされた仮想ネットワークは、ソフトウェアで定義されたネットワークと、またはコンピューティング ノード上のルーティングと重複する IP アドレス範囲を持つことはできません。 競合のよくある要因は、docker などのコンテナー ランタイムを使用することです。 Docker により、
172.17.0.0/16のサブネット範囲が定義された既定のネットワーク ブリッジが作成されます。 その既定の IP アドレス空間内の仮想ネットワーク内で実行されているサービスは、SSH 経由のリモート アクセスなど、コンピューティング ノード上のサービスと競合します。
仮想マシン構成のプール
要件:
- サポートされている Virtual Networks: Azure Resource Manager ベースの仮想ネットワークのみ。
- サブネット ID: Batch API を使用してサブネットを指定するときに、そのサブネットの "リソース識別子" を使用します。 サブネット識別子の形式は次のとおりです。
/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.Network/virtualNetworks/{network}/subnets/{subnet}
- アクセス許可: Virtual Network のサブスクリプションまたはリソース グループに対するロックまたはセキュリティ ポリシーで、Virtual Network を管理するためのユーザーのアクセス許可が制限されているかどうかを確認します。
- ネットワーク リソース: Virtual Network を含んでいるリソース グループには、Batch によって自動的に追加のネットワーク リソースが作成されます。
重要
専用または低優先度のノード 100 台ごとに、1 つのネットワーク セキュリティ グループ (NSG)、1 つのパブリック IP アドレス、1 つのロード バランサーが Batch によって作成されます。 これらのリソースは、サブスクリプションのリソース クォータによって制限されます。 大規模なプールでは、これらの 1 つ以上のリソースについて、クォータの引き上げの要求が必要になる場合があります。
仮想マシン構成のプールのネットワーク セキュリティ グループ: Batch の既定値
Batch は、Batch プール内の各仮想マシン スケール セット デプロイのネットワーク インターフェイス レベルでネットワーク セキュリティ グループ (NSG) を作成します。 simplified 計算ノードにパブリック IP アドレスがないプールの場合、NSG は作成されません。
計算ノードと Batch サービスの間で必要な通信を提供するために、これらの NSG は次のように構成されます。
- BatchNodeManagement.region サービス タグに対応する Batch サービスの IP アドレスからポート 29876 と 29877 で受信するインバウンド TCP トラフィック。 この規則は、
classicプール通信モードでのみ作成されます。 - ポート 22 (Linux ノード) またはポート 3389 (Windows ノード) 上の受信 TCP トラフィックは、それぞれ既定のポートで SSH または RDP のリモート アクセスを許可します。 Linux 上の特定の種類のマルチインスタンス タスク (MPI など) の場合、Batch 計算ノードを含むサブネット内の IP で SSH トラフィックも許可する必要があります。 一部の MPI ランタイムでは、SSH 経由での起動が必要になる場合があります。これは通常、プライベート IP アドレス空間でルーティングされます。 このトラフィックは、サブネット レベルの NSG 規則に従ってブロックされる可能性があります。
- ポート 443 のすべてのトラフィックを、BatchNodeManagement.region サービス タグに対応する Batch サービスの IP アドレスに送信します。
- 仮想ネットワークに向かう全ポートのアウトバウンド トラフィック。 この規則は、サブネット レベルの NSG 規則ごとに修正される場合があります。
- インターネットに向かう全ポートのアウトバウンド トラフィック。 この規則は、サブネット レベルの NSG 規則ごとに修正される場合があります。
重要
Batch によって構成された NSG のインバウンドまたはアウトバウンド規則を変更したり追加したりする際は注意が必要です。 指定したサブネット内のコンピューティング ノードとの通信が NSG によって拒否された場合、Batch サービスによって、コンピューティング ノードの状態が使用不可に設定されます。 また、Batch によって作成されたリソースにはリソース ロックを適用しないでください。そうしないと、プールの削除など、ユーザーが開始した操作の結果として、リソースのクリーンアップが妨げられるからです。
仮想マシン構成プールのネットワーク セキュリティ グループ: サブネット レベルの規則の指定
Batch 計算ノードのサブネットに NSG が関連付けられている場合、次のテーブルに示すように、この NSG に少なくとも受信および送信のセキュリティ規則を構成する必要があります。
警告
Batch サービスの IP アドレスは、時間の経過と共に変化することがあります。 したがって、次の表に示す NSG 規則には、BatchNodeManagement.region サービス タグを使用する必要があります。 特定の Batch サービス IP アドレスを使用して NSG 規則を設定しないでください。
受信セキュリティ規則
| ソース サービス タグまたは IP アドレス | ターゲット ポート | Protocol | プール通信モード | 必須 |
|---|---|---|---|---|
| BatchNodeManagement.regionサービス タグ | 29876 から 29877 | TCP | クラシック | はい |
| 計算ノードにリモートでアクセスするためのソース IP アドレス | 3389 (Windows)、22 (Linux) | TCP | Classic または Simplified | いいえ |
それぞれデフォルトの RDP ポートまたは SSH ポートで、外部からの計算ノードへのリモート アクセスを許可する必要がある場合にのみ、ポート 3389 (Windows) またはポート 22 (Linux) で受信トラフィックを構成します。 サブネット レベルの NSG 規則ごとにトラフィックがブロックされる可能性があるため、Batch 計算ノードを含むサブネット内の特定のメッセージ パッシング インターフェイス (MPI) ランタイムを使用したマルチインスタンス タスクのサポートが必要な場合は、Linux で SSH トラフィックを許可する必要がある場合があります。 MPI トラフィックは通常、プライベート IP アドレス空間経由ですが、MPI ランタイムとランタイム構成によって異なる場合があります。 これらのポートでトラフィックを許可することは、プール計算ノードを使用できるようにするために厳密には必要ありません。 プール エンドポイントを構成することで、これらのポートへの既定のリモート アクセスを無効にすることもできます。
送信セキュリティ規則
| 宛先サービス タグ | ターゲット ポート | Protocol | プール通信モード | 必須 |
|---|---|---|---|---|
| BatchNodeManagement.regionサービス タグ | 443 | * | Simplified | はい |
| Storage.regionサービス タグ | 443 | TCP | クラシック | はい |
ジョブ マネージャー タスクを使用する場合、またはタスクが Batch サービスと通信を返す必要がある場合は、 classic プール通信モードで BatchNodeManagement.region サービス タグへの送信が必要です。 simplified プール通信モードで BatchNodeManagement.region に送信する場合、Batch サービスでは現在 TCP プロトコルのみが使用されますが、将来の互換性のために UDP が必要になる場合があります。 パブリック IP アドレスのないプールで、simplified 通信モードを使用し、ノード管理プライベート エンドポイントを含む場合、NSG は必要ありません。 BatchNodeManagement.region サービス タグの送信セキュリティ規則の詳細については、「 簡略化されたコンピューティング ノード通信を使用する」をご覧ください。
Azure portal に Virtual Network を含むプールを作成する
Virtual Network を作成し、それにサブネットを割り当てた後は、その Virtual Network で Batch プールを作成できます。 次の手順に従って、Azure Portal でプールを作成します。
Azure portal の上部にある検索バーで Batch アカウントを検索して選択します。 Batch アカウントを選択します。 このアカウントは、使用する予定の Virtual Network を含むリソース グループと同じサブスクリプションおよびリージョン内にある必要があります。
左側のナビゲーションから [プール] を選択します。
[プール] ウィンドウで、[追加] を選択します。
[プールの追加] ページでオプションを選択し、プールの情報を入力します。 Batch アカウントのプールの作成の詳細については、「コンピューティング ノードのプールを作成する」を参照してください。 [ノード サイズ]、[ターゲットの専用ノード数]、[ターゲットのスポットまたは低優先度ノード] など、任意のオプションの設定を行います。
[仮想ネットワーク] で、使用する予定の仮想ネットワークとサブネットを選択します。
[OK] を選択してプールを作成します。
重要
プールで使用されているサブネットを削除しようとすると、エラー メッセージが表示されます。 サブネットを使用しているすべてのプールは、そのサブネットを削除する前に削除する必要があります。
強制トンネリングのユーザー定義ルート
組織には、検査やログ記録目的で、サブネットからオンプレミスの場所にインターネット接続のトラフィックをリダイレクトする (強制的に送る) 要件がある場合があります。 さらに、Virtual Network でサブネットの強制トンネリングを既に有効にしている場合もあります。
強制トンネリングが有効になっている Virtual Network でプールのノードが機能することを確認するには、そのサブネットに次のユーザー定義ルート (UDR) を追加する必要があります。
Classic 通信モード プールの場合:
Batch サービスは、タスクをスケジュールする目的でノードと通信する必要があります。 この通信を有効にするには、Batch アカウントが存在するリージョン内でBatchNodeManagement.regionサービス タグ に対応する UDR を追加します。 [次ホップの種類] を [インターネット] に設定します。
オンプレミス ネットワークが、宛先ポート 443 での Azure Storage への送信 TCP トラフィックによってブロックされていに事を確認します (具体的には、
*.table.core.windows.net、*.queue.core.windows.net、*.blob.core.windows.netの形式の URL) 。
ノード管理プライベート エンドポイントを使用しないSimplified 通信モード プールの場合:
- オンプレミスのネットワークが、宛先ポート 443 での Azure Batch BatchNodeManagement.region サービス タグへの送信 TCP/UDP トラフィックをブロックしていないことを確認します。 現時点では TCP プロトコルのみが使用されていますが、将来の互換性のために UDP が必要になる場合があります。
すべてのプール:
- 仮想ファイル マウントを使用する場合は、ネットワーク要件を調べ、必要なトラフィックがブロックされていないことを確認します。
警告
Batch サービスの IP アドレスは、時間の経過と共に変化することがあります。 Batch サービスの IP アドレスの変更による停止を防ぐために、IP アドレスを直接指定しないでください。 代わりに、BatchNodeManagement.regionサービス タグを使用します。