Azure Stack HCI バージョン 23H2 のクラウド デプロイに関するネットワークに関する考慮事項

適用対象: Azure Stack HCI バージョン 23H2

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

ネットワーク設計フレームワーク

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

手順 1: クラスターのサイズを決定する

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

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

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

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

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

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

決定	考慮事項
クラスター サイズ (クラスターあたりのノード数)	Azure portal または Azure Resource Manager テンプレートを使用したスイッチレス構成は、1、2、または 3 つのノード クラスターでのみ使用できます。 4 つ以上のノードを持つクラスターでは、ストレージ ネットワーク トラフィックに物理スイッチが必要です。
スケールアウト要件	オーケストレーターを使用してクラスターをスケールアウトする場合は、ストレージ ネットワーク トラフィックに物理スイッチを使用する必要があります。

手順 2: クラスター ストレージの接続性を確認する

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

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

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

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

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

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

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

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

決定	考慮事項
ストレージ用のスイッチなし	Azure portal または Resource Manager テンプレートのデプロイを使用したスイッチレス構成は、1、2、または 3 つのノード クラスターでのみサポートされます。 1 つまたは 2 つのノード ストレージ スイッチレス クラスターは、Azure portal または Resource Manager テンプレートを使用してデプロイできます。 3 ノード ストレージ スイッチレス クラスターは、Resource Manager テンプレートを使用してのみデプロイできます。 スケールアウト操作は、スイッチレス デプロイではサポートされていません。 デプロイ後にノード数を変更するには、手動で構成する必要があります。 ストレージ スイッチレス構成を使用する場合は、少なくとも 2 つのネットワーク インテントが必要です。
記憶域のネットワーク スイッチ	オーケストレーターを使用してクラスターをスケールアウトする場合は、ストレージ ネットワーク トラフィックに物理スイッチを使用する必要があります。 このアーキテクチャは、1 から 16 までの任意の数のノードで使用できます。 は適用されませんが、すべてのネットワーク トラフィックの種類 (管理、コンピューティング、ストレージ) に対して 1 つの意図を使用できます

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

手順 3: ネットワーク トラフィックの意図を決定する

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

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

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

ネットワーク インテント: すべてのトラフィックをグループ化する

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

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

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

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

ネットワーク インテント: グループ管理とコンピューティング トラフィック

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

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

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

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

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

ネットワークインテント: コンピューティングとストレージのトラフィックをグループ化する

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

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

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

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

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

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

ネットワーク インテント: カスタム構成

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

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

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

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

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

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

手順 4: 管理ネットワーク接続を決定する

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

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

ネットワーク アダプター ドライバー

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

管理 IP プール

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

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

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

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

#	条件
1	IP 範囲では連続する IP を使用する必要があり、すべての IP がその範囲内で使用できる必要があります。 デプロイ後にこの IP 範囲を変更することはできません。
2	IP の範囲にはクラスター ノード管理 IP を含めてはいけませんが、ノードと同じサブネット上に存在する必要があります。
3	管理 IP プールに定義されている既定のゲートウェイは、インターネットへの送信接続を提供する必要があります。
4	DNS サーバーは、Active Directory とインターネットで名前解決を確保する必要があります。
5	管理 IP には送信インターネット アクセスが必要です。

管理 VLAN ID

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

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

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

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

Set-NetAdapter -Name "NIC1" -VlanID 44

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

仮想スイッチを使用した管理 VLAN ID

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

注意

仮想スイッチを作成する前に、Hype-V ロールを有効にしてください。 詳細については、「 必要な Windows ロールをインストールする」を参照してください。

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

1. 推奨される名前付け規則を使用して仮想スイッチを作成する

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

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

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

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

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

2. すべてのノードに必要なネットワーク ATC 名前付け規則を使用して管理仮想ネットワーク アダプターを構成する

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

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

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

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

$IntentName = "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)"

#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)"

3. すべてのノードの管理仮想ネットワーク アダプターに VLAN ID を構成する

仮想スイッチと管理仮想ネットワーク アダプターが作成されたら、このアダプターに必要な 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"

4. 展開中に管理意図の物理ネットワーク アダプターを参照する

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

注意

ネットワーク意図の仮想ネットワーク アダプターを選択しないでください。

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

VLAN ID に関する要約された考慮事項を次に示します。

#	考慮事項
1	サーバーを Azure Arc に登録する前に、管理のために物理ネットワーク アダプターで VLAN ID を指定する必要があります。
2	サーバーを Azure Arc に登録する前に仮想スイッチが必要な場合は、特定の手順を使用します。
3	管理 VLAN ID は、デプロイ時にホスト構成からインフラストラクチャ VM に引き継がれます。
4	Azure portal のデプロイまたは Resource Manager テンプレートのデプロイには、VLAN ID 入力パラメーターはありません。

ノードとクラスターの IP 割り当て

Azure Stack HCI システムでは、サーバー ノードとクラスター 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 は、定義された IP 範囲の同じサブネット上にある必要があります。

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

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

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

DHCP IP の割り当て

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

たとえば、管理 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 に関する考慮事項

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

#	考慮事項
1	ノード IP は、静的アドレスか動的アドレスかに関係なく、定義された管理 IP プール範囲の同じサブネット上にある必要があります。
2	管理 IP プールには、ノード IP を含めてはなりません。 動的 IP 割り当てが使用されている場合は、DHCP の除外を使用します。
3	ノードの DHCP 予約を可能な限り使用します。
4	DHCP アドレスは、ノード IP とクラスター IP でのみサポートされます。 インフラストラクチャ サービスでは、管理プールの静的 IP が使用されます。
5	管理ネットワーク インテントが作成されると、最初の物理ネットワーク アダプターの MAC アドレスが管理仮想ネットワーク アダプターに割り当てられます。

プロキシの要件

オンプレミスインフラストラクチャ内のインターネットにアクセスするには、プロキシが必要になる可能性が高いです。 Azure Stack HCI では、認証されていないプロキシ構成のみがサポートされます。 Azure Arc にノードを登録するためにインターネット アクセスが必要な場合、サーバー ノードを登録する前に、プロキシ構成を OS 構成の一部として設定する必要があります。 詳しくは、「プロキシ設定の構成」をご覧ください。

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

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

#	考慮事項
1	Azure Arc にノードを登録する前に、プロキシ構成を完了する必要があります。
2	WinINET、WinHTTP、環境変数には、同じプロキシ構成を適用する必要があります。
3	環境チェッカーを使用すると、すべてのプロキシ コンポーネントでプロキシ構成の一貫性が確保されます。
4	Arc リソース ブリッジ VM と AKS のプロキシ構成は、デプロイ中にオーケストレーターによって自動的に行われます。
5	認証されていないプロキシのみがサポートされます。

ファイアウォールの要件

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

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

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

#	考慮事項
1	Azure Arc にノードを登録する前に、ファイアウォールの構成を行う必要があります。
2	スタンドアロン モードの環境チェッカーを使用して、ファイアウォール構成を検証できます。

手順 5: ネットワーク アダプターの構成を確認する

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

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

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

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

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

#	考慮事項
1	可能な限り既定の構成を使用します。
2	物理スイッチは、ネットワーク アダプターの構成に従って構成する必要があります。 「Azure Stack HCI の物理ネットワーク要件」を参照してください。
3	Windows Server カタログを使用して、ネットワーク アダプターが Azure Stack HCI でサポートされていることを確認します。
4	既定値を受け入れると、Network ATC によってストレージ ネットワーク アダプター IP と VLAN が自動的に構成されます。 これはストレージ自動 IP 構成と呼ばれます。 場合によっては、ストレージ自動 IP はサポートされていないため、Resource Manager テンプレートを使用して各ストレージ ネットワーク アダプター IP を宣言する必要があります。

次の手順

• Azure Stack HCI バージョン 23H2 デプロイについて。