仮想ネットワーク内に Azure Batch プールを作成する

Azure Batch プールを作成すると、指定した Azure 仮想ネットワーク (VNet) のサブネットでプールをプロビジョニングできます。 この記事では、VNet で Batch プールを設定する方法について説明します。

VNet を使用する理由

プール内の計算ノードは、複数インスタンスのタスクの実行など、個別の VNet を必要とせずに相互に通信できます。 ただし、既定では、プール内のノードは、ライセンス サーバーやファイル サーバーなど、プールの外部にある仮想マシンとは通信できません。

計算ノードが他の仮想マシンと、あるいはオンプレミス ネットワークと安全に通信するために、Azure VNet のサブネットでプールをプロビジョニングできます。

前提条件

  • [認証] : Azure VNet を使用するには、Batch クライアント API で Azure Active Directory (AD) 認証を使用する必要があります。 Azure AD の Azure Batch のサポートについては、「Batch サービスの認証に Active Directory を使用する」に記載されています。

  • Azure VNet。 VNet の要件と構成については、次のセクションを参照してください。 1 つまたは複数のサブネットを持つ VNet を前もって用意するために、Azure Portal、Azure PowerShell、Azure コマンド ライン インターフェイス (CLI)、その他の方法を利用できます。

VNet に関する要件

一般的な要件

  • VNET が存在するサブスクリプションとリージョンは、プールの作成に使用する Batch アカウントと同じである必要があります。

  • プールに指定されたサブネットには、プールの対象となる VM 数 (つまり、プールの targetDedicatedNodes および targetLowPriorityNodes プロパティの合計) に対応できる十分な未割り当て IP アドレスが必要です。 サブネットの未割り当て IP アドレスが十分でない場合、プールによってコンピューティング ノードが部分的に割り当てられ、サイズ変更エラーが発生します。

  • VNET を提供するカスタムの DNS サーバーが、Azure Storage エンドポイントを解決できることが必要です。 具体的には、フォーム <account>.table.core.windows.net<account>.queue.core.windows.net<account>.blob.core.windows.net の URL を解決できる必要があります。

  • 同じ VNet または同じサブネットに複数のプールを作成できます (十分なアドレス空間がある場合)。 1 つのプールが複数の VNet または複数のサブネットにまたがって存在することはできません。

その他の VNET 要件は、Batch プールが仮想マシンの構成にあるかクラウド サービスの構成にあるかによって異なります。 VNET に新しいプールをデプロイする場合は、仮想マシンの構成が推奨されます。

仮想マシンの構成におけるプール

サポートされる VNET - Azure Resource Manager ベースの VNET のみ

サブネット ID - Batch API を使用してサブネットを指定するときに、そのサブネットの "リソース識別子" を使用します。 サブネット識別子の形式は次のとおりです。

/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.Network/virtualNetworks/{network}/subnets/{subnet}

アクセス許可 - VNET のサブスクリプションまたはリソース グループに対するロックまたはセキュリティ ポリシーで、VNET を管理するためのユーザーのアクセス許可が制限されているかどうかを確認します。

追加のネットワーク リソース - VNet を含んでいるリソース グループには、Batch によって自動的に追加のネットワーク リソースが作成されます。

重要

専用または低優先度のノード 100 台ごとに、1 つのネットワーク セキュリティ グループ (NSG)、1 つのパブリック IP アドレス、1 つのロード バランサーが Batch によって作成されます。 これらのリソースは、サブスクリプションのリソース クォータによって制限されます。 大規模なプールでは、これらの 1 つ以上のリソースについて、クォータの引き上げの要求が必要になる場合があります。

ネットワーク セキュリティ グループ:Batch の既定値

サブネットでは、コンピューティング ノード上のタスクをスケジュールできるよう、Batch サービスからのインバウンド通信を許可する必要があります。また、ワークロードのニーズに応じて、Azure Storage などのリソースと通信するために、アウトバウンド通信を許可する必要があります。 仮想マシンの構成におけるプールの場合は、計算ノードにアタッチされたネットワーク インターフェイス (NIC) のレベルで、Batch により NSG が追加されます。 これらの NSG は、次の追加の規則で構成されます。

  • BatchNodeManagement サービス タグに対応する Batch サービスの IP アドレスからポート 29876 と 29877 で受信するインバウンド TCP トラフィック。
  • ポート 22 (Linux ノード) またはポート 3389 (Windows ノード) のインバウンド TCP トラフィック。リモート アクセスを許可するために使用されます。 Linux 上の特定の種類のマルチインスタンス タスク (MPI など) の場合、Batch コンピューティング ノードを含むサブネット 内の IP で SSH ポート 22 のトラフィックも許可する必要があります。 これは、サブネット レベルの NSG 規則に従ってブロックされる可能性があります (下記参照)。
  • 仮想ネットワークに向かう全ポートのアウトバウンド トラフィック。 これは、サブネット レベルの NSG 規則に従って修正される可能性があります (下記参照)。
  • インターネットに向かう全ポートのアウトバウンド トラフィック。 これは、サブネット レベルの NSG 規則に従って修正される可能性があります (下記参照)。

重要

Batch によって構成された NSG のインバウンドまたはアウトバウンド規則を変更したり追加したりする際は注意が必要です。 指定したサブネット内のコンピューティング ノードとの通信が NSG によって拒否された場合、Batch サービスによって、コンピューティング ノードの状態が 使用不可 に設定されます。 また、Batch によって作成されたリソースにはリソース ロックを適用しないでください。そうしないと、プールの削除など、ユーザーが開始した操作の結果として、リソースのクリーンアップが妨げられるからです。

ネットワーク セキュリティ グループ:サブネット レベルの規則の指定

Batch の計算ノードがデプロイされているサブネットに関連付けられている NSG がある場合、またはカスタム NSG 規則を適用して既定の適用を上書きする場合は、次のテーブルに示すように、少なくとも受信および送信のセキュリティ規則を持つ NSG を構成する必要があります。

ポート 3389 (Windows) またはポート 22 (Linux) のインバウンド トラフィックは、外部ソースからの計算ノードに対するリモート アクセスを許可する必要がある場合にのみ構成します。 特定の MPI ランタイムでマルチインスタンス タスクをサポートする必要がある場合は、Linux でポート 22 の規則を有効にすることが必要になる場合があります。 これらのポートでトラフィックを許可することは、プール計算ノードを使用できるようにするために厳密には必要ありません。

警告

Batch サービスの IP アドレスは、時間の経過と共に変化することがあります。 したがって、次の表に示す NSG 規則には、BatchNodeManagement サービス タグ (またはリージョン バリアント) を使用することを強くお勧めします。 特定の Batch サービス IP アドレスを使用して NSG 規則を設定しないでください。

[受信セキュリティ規則]

ソース IP アドレス 発信元サービス タグ ソース ポート 到着地 宛先ポート Protocol アクション
該当なし BatchNodeManagement サービス タグ (リージョン バリアントを使用している場合は、Batch アカウントと同じリージョン) * Any 29876 から 29877 TCP Allow
Linux マルチインスタンス タスクのためにコンピューティング ノードまたはコンピューティング ノード サブネット (あるいは両方) にリモート アクセスするためのユーザー ソース IP (必要な場合) 該当なし * Any 3389 (Windows)、22 (Linux) TCP Allow

アウトバウンド セキュリティ規則

source ソース ポート 到着地 宛先サービス タグ 宛先ポート Protocol アクション
Any * サービス タグ Storage (リージョン バリアントを使用している場合は、Batch アカウントと同じリージョン) 443 TCP Allow
Any * サービス タグ BatchNodeManagement (リージョン バリアントを使用している場合は、Batch アカウントと同じリージョン) 443 TCP Allow

BatchNodeManagement へのアウトバウンドは、ジョブ マネージャーのタスク用など、コンピューティング ノードから Batch サービスに接続するために必要です。

クラウド サービスの構成におけるプール

警告

Cloud Services 構成プールは非推奨とされます。 代わりに、仮想マシン構成プールを使用してください。

サポートされる VNET - クラシック VNET のみ

サブネット ID - Batch API を使用してサブネットを指定するときに、そのサブネットの "リソース識別子" を使用します。 サブネット識別子の形式は次のとおりです。

/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.ClassicNetwork /virtualNetworks/{network}/subnets/{subnet}

アクセス許可 - Microsoft Azure Batch サービス プリンシパルに、指定された VNet に対する Classic Virtual Machine Contributor Azure ロールが付与されている必要があります。

ネットワーク セキュリティ グループ

サブネットでは、コンピューティング ノード上のタスクをスケジュールできるよう、Batch サービスからのインバウンド通信を許可する必要があります。また、Azure Storage などのリソースと通信するために、アウトバウンド通信を許可する必要があります。

NSG を指定する必要はありません。Batch IP アドレスからプールのノードへのみのインバウンド通信が Batch によって構成されるためです。 ただし、指定したサブネットに、NSG やファイアウォールが関連付けられている場合は、次の表に示すようにインバウンドとアウトバウンドのセキュリティ規則を構成します。 指定したサブネット内のコンピューティング ノードとの通信が NSG によって拒否された場合、Batch サービスによって、コンピューティング ノードの状態が 使用不可 に設定されます。

ポート 3389 (Windows) のインバウンド トラフィックは、プールのノードに対する RDP アクセスを許可する必要がある場合に構成します。 これは、プールのノードを使用可能な状態にするために必要ではありません。

[受信セキュリティ規則]

ソース IP アドレス ソース ポート 到着地 宛先ポート Protocol アクション
Any

実際上は "すべて許可" が必要ですが、Batch サービス以外の IP アドレスをすべてフィルターで除外する ACL 規則が、Batch サービスにより各ノードのレベルで適用されます。
* Any 10100、20100、30100 TCP Allow
コンピューティング ノードへの RDP アクセスを許可する場合 (省略可能) * Any 3389 TCP Allow

アウトバウンド セキュリティ規則

source ソース ポート 到着地 宛先ポート Protocol アクション
Any * Any 443 Any Allow

Azure portal で VNet を含むプールを作成する

VNet を作成し、それにサブネットを割り当てたら、その VNet で Batch プールを作成できます。 次の手順に従って、Azure Portal でプールを作成します。

  1. Azure Portal の Batch アカウントに移動します。 このアカウントは、使用する予定の VNet を含むリソース グループと同じサブスクリプションおよびリージョン内にある必要があります。
  2. 左側の [設定] ウィンドウで、 [プール] メニュー項目を選択します。
  3. [プール] ウィンドウで、 [追加] を選択します。
  4. [プールの追加] ウィンドウで、 [イメージの種類] ドロップダウンから、使用する予定のオプションを選択します。
  5. [Publisher](パブリッシャー)、[Offer](プラン)、[SKU] で、カスタム イメージに対して適切な値を選択します。
  6. [ノード サイズ][ターゲットの専用ノード数][低優先度ノード] など、残りの必須の設定ほか、オプションの設定も必要に応じて指定します。
  7. [仮想ネットワーク] で、使用する予定の仮想ネットワークとサブネットを選択します。
  8. [OK] を選択してプールを作成します。

重要

プールで使用されているサブネットを削除しようとすると、エラー メッセージが表示されます。 サブネットを使用しているすべてのプールは、そのサブネットを削除する前に削除する必要があります。

強制トンネリングのユーザー定義ルート

組織には、検査やログ記録目的で、サブネットからオンプレミスの場所にインターネット接続のトラフィックをリダイレクトする (強制的に送る) 要件がある場合があります。 さらに、VNet でサブネットの強制トンネリングを既に有効にしている場合もあります。

強制トンネリングが有効になっている VNet でプールのノードが機能することを確認するには、そのサブネットに次のユーザー定義ルート (UDR) を追加する必要があります。

  • Batch サービスは、タスクをスケジュールする目的でノードと通信する必要があります。 この通信を有効にするには、Batch アカウントが存在するリージョンで Batch サービスによって利用される IP アドレスごとに UDR を追加します。 Batch サービスの IP アドレスは BatchNodeManagement.<region> サービス タグにあります。 IP アドレスの一覧を取得するには、「オンプレミスのサービス タグ」を参照してください。

  • 宛先ポート 443 での Azure Batch サービスへの送信 TCP トラフィックが、オンプレミス ネットワークによってブロックされていないことを確認します。 これらの Azure Batch サービスの宛先 IP アドレスは、上記でルートに対して使用した、BatchNodeManagement.<region> サービス タグにあるものと同じです。

  • 宛先ポート 443 での Azure Storage への送信 TCP トラフィック (具体的には、*.table.core.windows.net*.queue.core.windows.net*.blob.core.windows.net の形式の URL) が、オンプレミス ネットワークによってブロックされていないことを確認します。

  • 仮想ファイル マウントを使用する場合は、ネットワーク要件を調べ、必要なトラフィックがブロックされていないことを確認します。

UDR を追加するときに、関連する各 Batch の IP アドレス プレフィックスのルートを定義し、 [次ホップの種類][インターネット] に設定します。

警告

Batch サービスの IP アドレスは、時間の経過と共に変化することがあります。 IP アドレスの変更による停止を防ぐために、Batch サービスの IP アドレスを自動的に更新し、ルート テーブルで最新の状態に保つプロセスを作成します。

次のステップ