Azure Local のクラウド デプロイに関するネットワークに関する考慮事項

適用対象: Azure Local 2311.2 以降

この記事では、クラウド デプロイ用の Azure ローカル システム ネットワークを設計および計画する方法について説明します。 続行する前に、さまざまな Azure ローカル ネットワーク パターン 使用可能な構成について理解してください。

次の図は、Azure ローカル インスタンスのネットワーク 設計フレームワークを定義するさまざまな決定と手順を示しています。クラスター サイズ、クラスター ストレージ接続、ネットワーク トラフィックの意図、管理接続、ネットワーク アダプターの構成です。 設計の決定ごとに、後続の手順で使用できる設計オプションが有効または許可されます。

Azure ローカル インスタンスのサイズを判断するには、 Azure Local sizer ツールを使用します。このツールでは仮想マシンの数 (VM)、VM のサイズ、Azure Virtual Desktop、SQL Server、AKS などの VM のワークロードの使用などのプロファイルを定義できます。

Azure ローカル コンピューターの要件 に関する記事で説明されているように、Azure Local インスタンスでサポートされるマシンの最大数は 16 です。 ワークロードの容量計画を完了したら、インフラストラクチャでワークロードを実行するために必要なマシン ノードの数を十分に理解している必要があります。

• ワークロードに 4 つ以上のノードが必要な場合: ストレージ ネットワーク トラフィックにスイッチレス構成をデプロイして使用することはできません。 ストレージ トラフィックを処理するには、リモート ダイレクト メモリ アクセス (RDMA) をサポートする物理スイッチを含める必要があります。 Azure ローカル インスタンス のネットワーク アーキテクチャの詳細については、「 Network 参照パターンの概要を参照してください。

• ワークロードに 3 つ以下のノードが必要な場合: ストレージ接続用にスイッチレス構成または切り替え構成を選択できます。

• 後で 3 つ以上のノードにスケールアウトする場合: ストレージ ネットワーク トラフィックには物理スイッチを使用する必要があります。 スイッチレス デプロイのスケールアウト操作では、Microsoft が Azure Local のソフトウェア開発サイクルの一環としてアクティブに検証していないノード間のネットワーク ケーブル接続を手動で構成する必要があります。

クラスター サイズの決定に関する考慮事項の概要を次に示します。

物理ネットワーク要件で説明されているように、Azure Local では、ストレージ ネットワーク トラフィックに対して次の 2 種類の接続がサポートされています。

• トラフィックを処理するには、物理ネットワーク スイッチを使用します。
• ストレージ トラフィック用のクロス ネットワークまたはファイバー ケーブルを使用して、ノード間のノードを直接接続します。

各オプションの長所と短所は、上記のリンク先の記事に記載されています。

前述のように、クラスターのサイズが 3 ノード以下の場合にのみ、2 つのオプションを決定できます。 4 つ以上のノードを持つクラスターは、ストレージ用のネットワーク スイッチを使用して自動的にデプロイされます。

クラスターのノードが 3 つ未満の場合、ストレージ接続の決定は、次の手順で定義できるネットワーク意図の数と種類に影響します。

たとえば、スイッチレス構成の場合は、2 つのネットワーク トラフィックの意図を定義する必要があります。 クロス ケーブルを使用した東西通信のストレージ トラフィックには、南北接続がないため、ネットワーク インフラストラクチャの残りの部分から完全に分離されています。 つまり、管理送信接続とコンピューティング ワークロードに対して 2 つ目のネットワーク意図を定義する必要があります。

各ネットワーク インテントは、それぞれ 1 つの物理ネットワーク アダプター ポートでのみ定義できますが、フォールト トレランスは提供されません。 そのため、ネットワーク意図ごとに少なくとも 2 つの物理ネットワーク ポートを使用することをお勧めします。 記憶域にネットワーク スイッチを使用する場合は、ストレージを含むすべてのネットワーク トラフィックを 1 つのネットワーク インテントにグループ化できます。これは、 hyperconverged または 完全に集約されたホスト ネットワーク構成とも呼ばれます 。

クラスター ストレージ接続の決定に関する考慮事項の概要を次に示します。

次の図は、さまざまなデプロイで使用できるストレージ接続オプションをまとめたものです。

Azure Local の場合、すべてのデプロイはホスト ネットワーク構成に Network ATC に依存します。 Azure Portal を使用して Azure Local をデプロイすると、ネットワーク意図が自動的に構成されます。 ネットワークの意図とそのトラブルシューティング方法の詳細については、「 Common network ATC コマンドを参照してください。

このセクションでは、ネットワーク トラフィックの意図に対する設計上の決定の影響と、それらがフレームワークの次のステップにどのように影響するかを説明します。 クラウド デプロイの場合は、4 つのオプションから選択して、ネットワーク トラフィックを 1 つ以上の意図にグループ化できます。 使用可能なオプションは、クラスター内のノードの数と使用されるストレージ接続の種類によって異なります。

使用可能なネットワークインテントオプションについては、以下のセクションで説明します。

Network ATC は、管理、コンピューティング、ストレージのネットワーク トラフィックを含む一意の意図を構成します。 この意図に割り当てられたネットワーク アダプターは、すべてのネットワーク トラフィックの帯域幅とスループットを共有します。

• このオプションには、ストレージ トラフィック用の物理スイッチが必要です。 スイッチレス アーキテクチャが必要な場合は、この種類の意図を使用できません。 ストレージ接続のスイッチレス構成を選択すると、Azure portal によってこのオプションが自動的に除外されます。

• 高可用性を確保するには、少なくとも 2 つのネットワーク アダプター ポートを使用することをお勧めします。

• ストレージの RDMA トラフィックをサポートするには、少なくとも 10 Gbps のネットワーク インターフェイスが必要です。

ネットワーク ATC は、2 つの意図を構成します。 1 つ目の意図には管理とコンピューティング ネットワーク トラフィックが含まれており、2 番目の意図にはストレージ ネットワーク トラフィックのみが含まれます。 各意図には、異なるネットワーク アダプター ポートのセットが必要です。

このオプションは、次の場合に、切り替えストレージ接続とスイッチレス ストレージ接続の両方に使用できます。

• 高可用性を確保するために、意図ごとに少なくとも 2 つのネットワーク アダプター ポートを使用できます。

• 記憶域にネットワーク スイッチを使用する場合は、RDMA に物理スイッチが使用されます。

• ストレージの RDMA トラフィックをサポートするには、少なくとも 10 Gbps のネットワーク インターフェイスが必要です。

ネットワーク ATC は、2 つの意図を構成します。 最初の意図にはコンピューティングとストレージのネットワーク トラフィックが含まれており、2 番目の意図には管理ネットワーク トラフィックのみが含まれます。 各意図は、異なるネットワーク アダプター ポートのセットを使用する必要があります。

• このオプションでは、同じポートがコンピューティング トラフィックと共有されるため、ストレージ トラフィックの物理スイッチが必要です。これには南北通信が必要です。 スイッチレス構成が必要な場合は、この種類の意図を使用できません。 ストレージ接続のスイッチレス構成を選択すると、Azure portal によってこのオプションが自動的に除外されます。

• このオプションには、RDMA の物理スイッチが必要です。

• 高可用性を確保するには、少なくとも 2 つのネットワーク アダプター ポートを使用することをお勧めします。

• RDMA トラフィックをサポートするコンピューティングとストレージの意図には、少なくとも 10 Gbps のネットワーク インターフェイスをお勧めします。

• 管理インテントがコンピューティング意図なしで宣言されている場合でも、Network ATC はスイッチ埋め込みチーミング (SET) 仮想スイッチを作成して、管理ネットワークに高可用性を提供します。

少なくとも 1 つの意図に管理トラフィックが含まれている限り、独自の構成を使用して最大 3 つの意図を定義します。 2 つ目のコンピューティング意図が必要な場合は、このオプションを使用することをお勧めします。 この 2 つ目のコンピューティング意図要件のシナリオには、リモート ストレージ トラフィック、VM バックアップ トラフィック、または異なる種類のワークロードに対する個別のコンピューティング意図が含まれます。

• ストレージの意図が他の意図と異なる場合は、切り替えストレージ接続とスイッチレス ストレージ接続の両方にこのオプションを使用します。

• このオプションは、別のコンピューティング意図が必要な場合、または異なるネットワーク アダプター経由で異なる種類のトラフィックを完全に分離する場合に使用します。

• 高可用性を確保するには、意図ごとに少なくとも 2 つのネットワーク アダプター ポートを使用します。

• RDMA トラフィックをサポートするコンピューティングとストレージの意図には、少なくとも 10 Gbps のネットワーク インターフェイスをお勧めします。

次の図は、さまざまなデプロイで使用できるネットワークインテントオプションをまとめたものです。

この手順では、インフラストラクチャ サブネットのアドレス空間、これらのアドレスをクラスターに割り当てる方法、およびインターネットおよびドメイン ネーム システム (DNS) や Active Directory サービスなどの他のイントラネット サービスへの送信接続のためのノードにプロキシまたは VLAN ID の要件がある場合を定義します。

ルーティング、ファイアウォール、またはサブネットの要件を予測できるように、デプロイを開始する前に、次のインフラストラクチャ サブネット コンポーネントを計画して定義する必要があります。

オペレーティング システムをインストールし、ノードにネットワークを構成する前に、ネットワーク アダプターに OEM またはネットワーク インターフェイス ベンダーによって提供される最新のドライバーがあることを確認する必要があります。 既定の Microsoft ドライバーを使用する場合、ネットワーク アダプターの重要な機能が表示されない場合があります。

Azure Local インスタンスの初期デプロイを行うときは、既定でデプロイされるインフラストラクチャ サービスの連続する IP の IP 範囲を定義する必要があります。

範囲に現在および将来のインフラストラクチャ サービスに十分な IP を確保するには、少なくとも 6 つの連続する使用可能な IP アドレスの範囲を使用する必要があります。 これらのアドレスは、クラスター IP、Azure Resource Bridge VM、およびそのコンポーネントに使用されます。

インフラストラクチャ ネットワークで他のサービスを実行することが予想される場合は、インフラストラクチャ IP の追加バッファーをプールに割り当てることをお勧めします。 計画したプールのサイズが最初に使い果たされた場合は、PowerShell を使用してインフラストラクチャ ネットワークのデプロイ後に他の IP プールを追加できます。

デプロイ時にインフラストラクチャ サブネットの IP プールを定義する場合は、次の条件を満たす必要があります。

Azure ローカル インスタンスの管理サブネットでは、既定の VLAN を使用することをお勧めします。この既定の VLAN は、ほとんどの場合、VLAN ID 0 として宣言されています。 ただし、ネットワーク要件でインフラストラクチャ ネットワークに特定の管理 VLAN を使用する場合は、管理トラフィックに使用する物理ネットワーク アダプターで構成する必要があります。

管理に 2 つの物理ネットワーク アダプターを使用する場合は、両方のアダプターに VLAN を設定する必要があります。 この VLAN を使用してノードを正常に登録するには、マシンのブートストラップ構成の一部として、Azure Arc に登録する前にこれを行う必要があります。

物理ネットワーク アダプターで VLAN ID を設定するには、次の PowerShell コマンドを使用します。

この例では、物理ネットワーク アダプター NIC1で VLAN ID 44 を構成します。

Set-NetAdapter -Name "NIC1" -VlanID 44

VLAN ID が設定され、ノードの IP が物理ネットワーク アダプターで構成されると、オーケストレーターは管理に使用される物理ネットワーク アダプターからこの VLAN ID 値を読み取って格納するため、デプロイ時に必要な Azure Resource Bridge VM またはその他のインフラストラクチャ VM に使用できます。 Azure portal からのクラウド デプロイ中に管理 VLAN ID を設定することはできません。物理スイッチ VLAN が正しくルーティングされていない場合、ノードと Azure の間の接続が切断されるリスクがあるためです。

シナリオによっては、デプロイを開始する前に仮想スイッチを作成する必要があります。

仮想スイッチの構成が必要であり、特定の VLAN ID を使用する必要がある場合は、次の手順に従います。

Azure ローカル デプロイでは、管理、コンピューティング、およびストレージの意図のために仮想スイッチと仮想ネットワーク アダプターを作成して構成するために、Network ATC に依存しています。 既定では、Network ATC は意図の仮想スイッチを作成するときに、仮想スイッチの特定の名前を使用します。

同じ名前付け規則で仮想スイッチ名に名前を付けることをお勧めします。 仮想スイッチの推奨名は次のとおりです。

"ConvergedSwitch($IntentName)"。 $IntentName は、デプロイ時にポータルに入力された意図の名前と一致する必要があります。 この文字列は、次の手順で説明するように、管理に使用される仮想ネットワーク アダプターの名前とも一致する必要があります。

次の例は、 $IntentNameで推奨される名前付け規則を使用して、PowerShell で仮想スイッチを作成する方法を示しています。 ネットワーク アダプター名の一覧は、管理およびコンピューティング ネットワーク トラフィックに使用する物理ネットワーク アダプターの一覧です。

$IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

仮想スイッチと関連する管理仮想ネットワーク アダプターが作成されたら、ネットワーク アダプター名がネットワーク ATC の名前付け標準に準拠していることを確認します。

具体的には、管理トラフィックに使用される仮想ネットワーク アダプターの名前には、次の規則を使用する必要があります。

• ネットワーク アダプターと仮想ネットワーク アダプターの名前は、 vManagement($intentname)を使用する必要があります。
• この名前では大文字と小文字が区別されます。
• $Intentname には任意の文字列を指定できますが、仮想スイッチに使用される名前と同じである必要があります。 Mgmt意図名を定義するときは、Azure portal でこの同じ文字列を使用してください。

管理仮想ネットワーク アダプター名を更新するには、次のコマンドを使用します。

$IntentName = "MgmtCompute"

#Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

#Rename NetAdapter because during creation, Hyper-V adds the string "vEthernet" to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

仮想スイッチと管理仮想ネットワーク アダプターが作成されたら、このアダプターに必要な VLAN ID を指定できます。 仮想ネットワーク アダプターに VLAN ID を割り当てるオプションは異なりますが、サポートされる唯一のオプションは、 Set-VMNetworkAdapterIsolation コマンドを使用することです。

必要な VLAN ID を構成したら、管理仮想ネットワーク アダプターに IP アドレスとゲートウェイを割り当てて、他のノード、DNS、Active Directory、およびインターネットとの接続があることを検証できます。

次の例では、既定ではなく VLAN ID 8 を使用するように管理仮想ネットワーク アダプターを構成する方法を示します。

Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID "8"

新しく作成された仮想ネットワーク アダプターは、Azure portal 経由でデプロイするときに使用可能と表示されますが、ネットワーク構成はネットワーク ATC に基づいていることに注意してください。 つまり、管理または管理とコンピューティングの意図を構成する場合でも、その意図に使用される物理ネットワーク アダプターを選択する必要があります。

同じロジックが Azure Resource Manager テンプレートに適用されます。 仮想ネットワーク アダプターを使用しない、ネットワークの意図に使用する物理ネットワーク アダプターを指定する必要があります。

VLAN ID の概要に関する考慮事項を次に示します。

既定では、ネットワーク ATC は次の表からストレージ用の IP と VLAN を自動的に割り当てます。

ただし、デプロイ要件が既定の IP と VLAN に適合しない場合は、独自の IP、サブネット、VLAN をストレージに使用できます。 この機能は、ARM テンプレートを使用してクラスターをデプロイする場合にのみ使用でき、テンプレートで次のパラメーターを指定する必要があります。

• enableStorageAutoIP: このパラメーターは、指定しない場合は true に設定されます。 デプロイ時にカスタム ストレージ IP を有効にするには、このパラメーターを false に設定する必要があります。
• storageAdapterIPInfo: このパラメーターには "enableStorageAutoIP" パラメーターとの依存関係があり、ストレージ自動 IP パラメーターが false に設定されている場合は常に必要です。 ARM テンプレートの "storageAdapterIPInfo" パラメーター内で、 "ipv4Address" と "subnetMask" パラメーターを、独自の IP とサブネット マスクを持つ各ノードとネットワーク アダプターに指定する必要もあります。
• vlanId: 上の表で説明したように、このパラメーターは、ネットワーク ATC の既定の VLAN を変更する必要がない場合に使用します。 ただし、これらの既定の VLAN がネットワークで機能しない場合は、各ストレージ ネットワークに独自の VLAN ID を指定できます。

次の ARM テンプレートには、ストレージ用のネットワーク スイッチを備えた 2 つのノード Azure Local インスタンスの例が含まれています。ストレージ IP は、カスタム ストレージ IP を使用して 2 ノードデプロイにカスタマイズされます

Azure ローカル インスタンスの場合、マシン ノードとクラスター IP に IP を割り当てるには、2 つのオプションがあります。

• 静的ホスト構成プロトコルと動的ホスト構成プロトコル (DHCP) プロトコルの両方がサポートされています。

• 適切なノード IP 割り当ては、クラスターライフサイクル管理の鍵となります。 Azure Arc にノードを登録する前に、静的オプションと DHCP オプションを決定します。

• Arc リソース ブリッジやネットワーク コントローラーなどのインフラストラクチャ VM とサービスでは、管理 IP プールの静的 IP が使用され続けます。 これは、DHCP を使用して IP をノードとクラスター IP に割り当てる場合でも、管理 IP プールが引き続き必要であることを意味します。

以降のセクションでは、各オプションの影響について説明します。

ノードに静的 IP が使用されている場合、管理 IP プールを使用して使用可能な IP を取得し、デプロイ時にクラスター IP に自動的に割り当てます。

管理 IP プールに定義されている IP 範囲の一部ではないノードには、管理 IP を使用することが重要です。 マシン ノード IP は、定義された IP 範囲の同じサブネット上にある必要があります。

ノードのすべての物理ネットワーク アダプターに対して、既定のゲートウェイと構成済みの DNS サーバーの管理 IP を 1 つだけ割り当てることをお勧めします。 これにより、管理ネットワークの意図が作成された後に IP が変更されないようにします。 これにより、デプロイ プロセス中 (Azure Arc の登録中も含む) にノードが送信接続を維持することも保証されます。

ルーティングの問題を回避し、送信接続と Arc 登録に使用される IP を特定するために、Azure portal では、複数の既定のゲートウェイが構成されているかどうかを検証します。

OS 構成中に仮想スイッチと管理仮想ネットワーク アダプターが作成された場合、ノードの管理 IP をその仮想ネットワーク アダプターに割り当てる必要があります。

ノードの IP が DHCP サーバーから取得された場合は、クラスター IP にも動的 IP が使用されます。 インフラストラクチャ VM とサービスには静的 IP が引き続き必要です。つまり、管理 IP プールのアドレス範囲は、ノードとクラスター IP に使用される DHCP スコープから除外する必要があります。

たとえば、インフラストラクチャの静的 IP に対して管理 IP 範囲が 192.168.1.20/24 から 192.168.1.30/24 と定義されている場合、サブネット 192.168.1.0/24 に定義されている DHCP スコープには、インフラストラクチャ サービスとの IP 競合を回避するために、管理 IP プールと同等の除外が必要です。 また、ノード IP に DHCP 予約を使用することをお勧めします。

管理インテントを作成した後に管理 IP を定義するプロセスでは、ネットワークインテント用に選択された最初の物理ネットワーク アダプターの MAC アドレスを使用する必要があります。 この MAC アドレスは、管理目的で作成された仮想ネットワーク アダプターに割り当てられます。 つまり、最初の物理ネットワーク アダプターが DHCP サーバーから取得する IP アドレスは、仮想ネットワーク アダプターが管理 IP として使用するのと同じ IP アドレスです。 そのため、ノード IP の DHCP 予約を作成することが重要です。

クラウドのデプロイ時に使用されるネットワーク検証ロジックは、構成に既定のゲートウェイがある複数の物理ネットワーク インターフェイスを検出すると失敗します。 ホスト IP 割り当てに DHCP を使用する必要がある場合は、前述のように SET (スイッチ埋め込みチーミング) 仮想スイッチと管理仮想ネットワーク アダプターを事前に作成する必要があるため、管理仮想ネットワーク アダプターのみが DHCP サーバーから IP アドレスを取得します。

IP アドレスの概要に関する考慮事項を次に示します。

Active Directory に基づく Azure ローカル デプロイには、オンプレミス ドメインとインターネット パブリック エンドポイントを解決できる DNS サーバーが必要です。 デプロイの一環として、ノード上で構成されているインフラストラクチャ IP アドレス範囲に対して同じ DNS サーバーを定義する必要があります。 Azure Resource Bridge コントロール プレーン VM と AKS コントロール プレーンでは、名前解決に同じ DNS サーバーが使用されます。 デプロイが完了すると、DNS サーバー IP の変更はサポートされず、Azure ローカル プラットフォーム スタック全体のアドレスを更新することができなくなります。

Azure Local に使用される DNS サーバーは、デプロイ前に外部であり、運用可能である必要があります。 Azure ローカル仮想マシンとして実行することはサポートされていません。

DNS サーバー アドレスの概要に関する考慮事項を次に示します。

"dnsServers": [
                        "10.250.16.124",
                        "10.250.17.232",
                        "10.250.18.107"
                    ]

多くの場合、プロキシは、オンプレミス インフラストラクチャ内のインターネットにアクセスするために必要です。 Azure Local では、認証されていないプロキシ構成のみがサポートされます。 Azure Arc にノードを登録するにはインターネット アクセスが必要であるため、マシン ノードを登録する前に、プロキシ構成を OS 構成の一部として設定する必要があります。 (詳細については、プロキシ設定の構成に関するページを参照してください。)

Azure Stack HCI OS には、すべての OS コンポーネントがインターネットにアクセスできるようにするために同じプロキシ構成を必要とする 3 つの異なるサービス (WinInet、WinHTTP、環境変数) があります。 ノードに使用されるのと同じプロキシ構成が Arc Resource Bridge VM と AKS に自動的に引き継がれ、デプロイ時にインターネットにアクセスできるようになります。

プロキシ構成に関する考慮事項の概要を次に示します。

現在、Azure Local とそのコンポーネントが正常に接続できるように、ファイアウォールで複数のインターネット エンドポイントを開く必要があります。 必要なエンドポイントの詳細な一覧については、 ファイアウォールの要件を参照してください。

Azure Arc にノードを登録する前に、ファイアウォールの構成を行う必要があります。スタンドアロン バージョンの環境チェッカーを使用して、ファイアウォールがこれらのエンドポイントに送信されるトラフィックをブロックしていないことを検証できます。 詳細については、「 Azure Local Environment Checker を参照して、Azure Local のデプロイの準備状況を評価します。

ファイアウォールに関する考慮事項の概要を次に示します。

ネットワーク アダプターは、使用されるネットワーク トラフィックの種類 (管理、コンピューティング、ストレージ) によって修飾されます。 Windows Server カタログを確認すると、Windows Server 2022 認定は、どのアダプターがどのネットワーク トラフィックに適合しているかを示します。

Azure Local 用のマシンを購入する前に、3 つのトラフィックの種類すべてが Azure Local で必要であるため、管理、コンピューティング、およびストレージの認定を受けたアダプターが少なくとも 1 つ必要です。 クラウド展開では、ネットワーク ATC に依存して、適切なトラフィックの種類のネットワーク アダプターを構成するため、サポートされているネットワーク アダプターを使用することが重要です。

Network ATC で使用される既定値については、 クラスター ネットワーク設定に記載されています。 既定値を使用することをお勧めします。 そのため、必要に応じて、Azure portal または Resource Manager テンプレートを使用して次のオプションをオーバーライドできます。

• ストレージ VLAN: この値をストレージに必要な VLAN に設定します。
• ジャンボ パケット: ジャンボ パケットのサイズを定義します。
• ネットワーク ダイレクト: ネットワーク アダプターの RDMA を無効にする場合は、この値を false に設定します。
• ネットワーク ダイレクト テクノロジ: この値を RoCEv2 または iWarpに設定します。
• トラフィック優先度データセンター ブリッジング (DCB): 要件に合った優先順位を設定します。 既定の DCB 値は、Microsoft と顧客によって検証されるため、使用することを強くお勧めします。

ネットワーク アダプターの構成に関する考慮事項の概要を次に示します。

• Azure ローカル デプロイについて。