Azure Stack Hub のためのネットワーク統合計画

この記事では、Azure Stack Hub を既存のネットワーク環境に統合する最善の方法を決定するために役立つ Azure Stack Hub ネットワーク インフラストラクチャの情報を提供します。

注意

Azure Stack Hub から外部の DNS 名 (たとえば www.bing.com) を解決するには、DNS 要求を転送するための DNS サーバーを提供する必要があります。 Azure Stack Hub の DNS 要件の詳細については、Azure Stack Hub とデータセンターの統合 - DNSに関するページをご覧ください。

物理ネットワークの設計

Azure Stack Hub ソリューションには、その操作やサービスをサポートするための回復性と可用性の高い物理インフラストラクチャが必要です。 Azure Stack Hub をネットワークに統合するには、Top-of-Rack スイッチ (ToR) から最も近いスイッチまたはルーター (このドキュメントでは境界と呼びます) へのアップリンクが必要です。 ToR は、単一または一対の境界にアップリンクできます。 ToR は、自動化ツールによって事前に構成されます。BGP ルーティングを使用する場合は、ToR と境界の間に 1 つ以上の接続、静的ルーティングを使用する場合は、ToR と境界の間に 2 つ以上の接続 (ToR ごとに 1 つ) が必要であり、いずれかのルーティング オプションの最大の接続数は 4 つです。 これらの接続は、SFP+ または SFP28 メディアと、最低 1 GB の速度に制限されています。 OEM (Original Equipment Manufacturer) ハードウェア ベンダーに可用性を確認してください。 推奨される設計を次の図に示します。

Recommended Azure Stack network design

帯域幅割り当て

Azure Stack Hub は Windows Server 2019 のフェールオーバー クラスターおよびスペース ダイレクト テクノロジーを使用して構築されています。 Azure Stack Hub の物理ネットワーク構成の一部は、トラフィックの分離と帯域幅の保証を利用して、スペース ダイレクト ストレージ通信がソリューションに必要なパフォーマンスとスケールの要件を満たせるようにするために行われます。 ネットワーク構成では、トラフィック クラスを使用して、スペース ダイレクト (RDMA ベースの通信) が Azure Stack Hub のインフラストラクチャやテナントによるネットワーク使用から分離されます。 Windows Server 2019 用に定義されている現在のベスト プラクティスに合わせるために、Azure Stack Hub は、追加のトラフィック クラスまたは優先順位を使用して、フェールオーバー クラスタリング制御通信をサポートするサーバー間通信をさらに分離するように変更されています。 この新しいトラフィック クラス定義は、使用可能な物理帯域幅の 2% を予約するように構成されます。 このトラフィック クラスと帯域幅の予約の構成は、Azure Stack Hub ソリューションの Top-of-Rack (ToR) スイッチ上と、Azure Stack Hub のホストまたはサーバー上での変更によって実現されます。 顧客の境界ネットワーク デバイスでは変更が必要ないことに注意してください。 これらの変更により、フェールオーバー クラスター通信の回復性が向上し、ネットワーク帯域幅が完全に消費されてフェールオーバー クラスター制御メッセージが中断される状況が回避されることになります。 フェールオーバー クラスター通信は Azure Stack Hub インフラストラクチャの重要なコンポーネントであり、長期間中断された場合はスペース ダイレクト ストレージ サービスやその他のサービスが不安定になり、最終的にはテナントまたはエンドユーザーのワークロードの安定性に影響する可能性があることに注意してください。

Note

説明されている変更は、2008 リリースの Azure Stack Hub システムのホスト レベルで追加されています。 OEM に連絡して、ToR ネットワーク スイッチで必要な変更を行うように手配してください。 この ToR の変更は、2008 リリースに更新する前に実行することも、2008 に更新した後に実行することもできます。 フェールオーバー クラスター通信を向上させるには、ToR スイッチの構成を変更する必要があります。

論理ネットワーク

論理ネットワークは、基礎となる物理ネットワーク インフラストラクチャの抽象化を表します。 これらは、ホスト、仮想マシン (VM)、およびサービスへのネットワーク割り当てを整理および簡略化するために使用されます。 論理ネットワーク作成の一部として、それぞれの物理的な場所にある論理ネットワークに関連付けられた仮想ローカル エリア ネットワーク (VLAN)、IP サブネット、および IP サブネット/VLAN ペアを定義するためのネットワーク サイトが作成されます。

次の表に、論理ネットワークと、計画する必要がある関連付けられた IPv4 サブネット範囲を示します。

論理ネットワーク 説明 サイズ
パブリック VIP Azure Stack Hub はこのネットワークから合計 31 のアドレスを使用し、残りはテナント VM によって使用されます。 31 個のアドレスのうち、8 つのパブリック IP アドレスが、小規模な一連の Azure Stack Hub サービスにより使用されます。 App Service と SQL リソース プロバイダーを使用する場合は、さらに 7 個のアドレスを使用します。 残りの 16 個の IP アドレスは、将来の Azure サービスのために予約されています。 /26 (62 ホスト) - /22 (1022 ホスト)

推奨 = /24 (254 ホスト)
スイッチのインフラストラクチャ ルーティングを目的としたポイント ツー ポイント IP アドレス (スイッチ管理専用インターフェイス) と、スイッチに割り当てられたループバック アドレス。 /26
インフラストラクチャ Azure Stack Hub 内部コンポーネントの通信に使用します。 /24
プライベート ストレージ ネットワーク、プライベート VIP、インフラストラクチャ コンテナー、およびその他の内部機能のために使用されます。 詳細については、この記事の「プライベート ネットワーク」セクションをご覧ください。 /20
BMC 物理ホスト上の BMC との通信に使用します。 /26

Note

ポータルにアラートが表示され、PEP コマンドレット Set-AzsPrivateNetwork を実行して新しい/20 プライベート IP 空間を追加するようにオペレーターに通知されます。 /20 プライベート IP 空間のガイダンスと選択方法の詳細については、この記事の「プライベート ネットワーク」セクションを参照してください。

ネットワーク インフラストラクチャ

Azure Stack Hub のネットワーク インフラストラクチャは、スイッチ上に構成されたいくつかの論理ネットワークから成ります。 それらの論理ネットワークを次の図に示し、各論理ネットワークと TOR (top-of-rack)、ベースボード管理コントローラー (BMC)、境界 (カスタマー ネットワーク) スイッチを統合する方法を説明します。

Logical network diagram and switch connections

BMC ネットワーク

このネットワークは、すべてのベースボード管理コントローラー (BMC またはサービス プロセッサとも呼ばれます) の管理ネットワークへの接続専用です。 例として、iDRAC、iLO、iBMC などがあります。 どの BMC ノードとの通信にも、1 つの BMC アカウントだけが使用されます。 存在する場合は、ハードウェア ライフサイクル ホスト (HLH) がこのネットワーク上に配置され、ハードウェアのメンテナンスまたは監視のための OEM 固有のソフトウェアが提供される可能性があります。

HLH では、デプロイメント仮想マシン (DVM) もホストされます。 DVM は Azure Stack Hub のデプロイ中に使用され、デプロイが完了すると削除されます。 接続されたデプロイのシナリオでは、DVM には、複数のコンポーネントのテスト、検証、およびアクセスのためにインターネット アクセスが必要です。 これらのコンポーネントは、企業ネットワークの内外に配置できます (たとえば NTP、DNS、Azure)。 接続の要件について詳しくは、「Azure Stack Hub ファイアウォールの統合」の NAT に関するセクションをご覧ください。

プライベート ネットワーク

この /20 (4096 IP) ネットワークは Azure Stack Hub リージョンに対してプライベートであり (Azure Stack Hub システムの境界スイッチ デバイスを超えてルーティングされることはありません)、複数のサブネットに分割されます。いくつかの例を次に示します。

  • ストレージ ネットワーク:スペース ダイレクトおよびサーバー メッセージ ブロック (SMB) ストレージ トラフィックの使用や VM のライブ マイグレーションをサポートするために使用される /25 (128 IP) ネットワーク。
  • 内部仮想 IP ネットワーク:ソフトウェア ロード バランサーのための内部のみの VIP 専用の /25 ネットワーク。
  • コンテナー ネットワーク:インフラストラクチャ サービスを実行しているコンテナー間の内部トラフィックのみを対象とする専用 /23 (512 IP) ネットワーク。

Azure Stack Hub システムには追加の /20 プライベート内部 IP 空間が必要です。 このネットワークは Azure Stack Hub リージョンに対してプライベートになり (Azure Stack Hub システムの境界スイッチ デバイスを超えてルーティングされることはありません)、データセンター内の複数の Azure Stack Hub システムで再利用できます。 ネットワークは Azure Stack に対してプライベートですが、データセンター内の他のネットワークと重複することはできません。 /20 プライベート IP 空間は複数のネットワークに分割されており、複数のコンテナー上で Azure Stack Hub インフラストラクチャを実行できます。 さらに、この新しいプライベート IP 空間によって、デプロイ前に必要となるルーティング可能な IP 空間を減少させるための継続的な作業が可能になります。 コンテナーで Azure Stack Hub インフラストラクチャを実行する目的は、使用率を最適化し、パフォーマンスを向上させることです。 さらに、/20 プライベート IP 空間は、デプロイ前に必要なルーティング可能な IP 空間を減らす継続的な取り組みを可能にするためにも使用されます。 プライベート IP 空間のガイダンスについては、RFC 1918 に従うことをお勧めします。

1910 より前にデプロイされたシステムでは、この /20 サブネットは、1910 の更新後にシステムに入力される追加のネットワークになります。 追加のネットワークは、Set-AzsPrivateNetwork PEP コマンドレットを使用して、システムに提供する必要があります。

Note

/20 の入力は、1910 の次の Azure Stack Hub 更新プログラムの前提条件となります。 1910 の次の Azure Stack Hub 更新プログラムがリリースされ、それをインストールしようとすると、後述する修復手順で説明するように /20 の入力を完了していない場合、更新は失敗します。 前記の修復手順が完了するまで、管理者ポータルにはアラートが表示されます。 この新しいプライベート空間がどのように使用されるかについては、データセンターのネットワーク統合に関する記事を参照してください。

修復手順: 修復するには、次の手順に従って PEP セッション開きます。 サイズ /20 のプライベート内部 IP 範囲を準備し、次の例を使用して、PEP セッション内で次のコマンドレットを実行します: 。 操作が正常に実行されると、"Azs Internal Network range added to the config (構成に Azs 内部ネットワーク範囲が追加されました)" というメッセージが表示されます。正常に完了すると、管理者ポータル上のアラートは閉じられます。 これで、Azure Stack Hub システムは、次のバージョンに更新できるようになります。

Azure Stack Hub インフラストラクチャ ネットワーク

この /24 ネットワークは、内部の Azure Stack Hub コンポーネントが互いにデータを通信したり交換したりできるように、これらのコンポーネント専用です。 このサブネットは、Azure Stack Hub ソリューションの外部からデータセンターにルーティングできます。このサブネットでパブリックまたはインターネットのルーティング可能な IP アドレスを使用することはお勧めしません。 このネットワークは境界にアドバタイズされますが、そのほとんどの IP はアクセス制御リスト (ACL) によって保護されています。 アクセスが許可される IP は、/27 ネットワークや、特権エンド ポイント (PEP)Azure Stack Hub Backup などのホスト サービスとサイズが同等の小さな範囲内です。

パブリック VIP ネットワーク

パブリック VIP ネットワークは、Azure Stack 内のネットワーク コントローラーに割り当てられます。 これはスイッチ上の論理ネットワークではありません。 SLB はアドレスのプールを使用して、テナント ワークロードに /32 ネットワークを割り当てます。 スイッチのルーティング テーブルでは、これらの /32 IP は BGP 経由で使用可能なルートとしてアドバタイズされます。 このネットワークには外部からアクセス可能な、つまりパブリック IP アドレスが含まれています。 Azure Stack Hub インフラストラクチャは、このパブリック VIP ネットワークの最初の 31 個のアドレスを予約し、残りはテナント VM によって使用されます。 このサブネット上のネットワーク サイズは、最小 /26 (64 のホスト) から最大 /22 (1022 のホスト) までの範囲があります。 /24 ネットワークを計画することをお勧めします。

オンプレミス ネットワークへの接続

Azure Stack Hub は、仮想マシン、ロード バランサーなどの顧客リソースに仮想ネットワークを使用します。

仮想ネットワーク内のリソースからオンプレミス/企業リソースに接続するには、複数の種類のオプションがあります。

  • パブリック VIP ネットワークのパブリック IP アドレスを使用する。
  • 仮想ネットワーク ゲートウェイまたはネットワーク仮想アプライアンス (NVA) を使用する。

S2S VPN トンネルを使用してオンプレミス ネットワークとの間でリソースを接続する場合、リソースにもパブリック IP アドレスが割り当てられており、そのパブリック IP アドレスを介してそのリソースに接続できなくなるケースが発生する可能性があります。 ソースが、ローカル ネットワーク ゲートウェイ ルート (仮想ネットワーク ゲートウェイ) または NVA ソリューションのユーザー定義ルートで定義されているのと同じサブネット範囲内にあるパブリック IP にアクセスしようとすると、Azure Stack Hub は、構成されているルーティング規則に基づいて、そのトラフィックを、S2S トンネルを通じてソースにルーティングしようとします。 戻りトラフィックでは、パブリック IP アドレスとして NAT 変換されたソースではなく、VM のプライベート IP アドレスが使用されます。

Route traffic

この問題には 2 つの解決策があります。

  • パブリック VIP ネットワークに向けられたトラフィックを、インターネットにルーティングします。
  • パブリック VIP ネットワークに向けられたローカル ネットワーク ゲートウェイで定義されているあらゆるサブネット IP を NAT 変換する NAT デバイスを追加します。

Route traffic solution

スイッチ インフラストラクチャ ネットワーク

この /26 ネットワークは、ルーティング可能なポイント ツー ポイント IP /30 (2 つのホスト IP) サブネット、およびインバンド スイッチ管理と BGP ルーター ID に専用の /32 サブネットであるループバックを含むサブネットです。 この範囲の IP アドレスを、Azure Stack Hub ソリューションの外部のデータセンターにルーティング可能にする必要があります。 それらは、プライベート IP またはパブリック IP のどちらでもかまいません。

スイッチ管理ネットワーク

この /29 (6 つのホスト IP) ネットワークは、スイッチの管理ポートの接続専用です。 これにより、デプロイ、管理、およびトラブルシューティングのためのアウトオブバンド アクセスが可能になります。 これは、上で説明したスイッチ インフラストラクチャ ネットワークから計算されます。

許可されるネットワーク

デプロイ ワークシートには、オペレーターがいくつかのアクセス制御リスト (ACL) を変更して、信頼されたデータセンター ネットワーク範囲から、ネットワーク デバイス管理インターフェイスとハードウェア ライフサイクル ホスト (HLH) にアクセスできるようにするためのフィールドがあります。 アクセス制御リストの変更によって、オペレーターは、特定のネットワーク範囲内の管理ジャンプボックス VM に、スイッチ管理インターフェイス、HLH OS、および HLH BMC へのアクセスを許可することができます。 オペレーターは、このリストに 1 つまたは複数のサブネットを指定できます。空白のままにすると、既定でアクセスが拒否されます。 「Azure Stack Hub スイッチ構成の特定の設定を変更する」で説明されていたデプロイ後に実行する必要がある手動介入に代わって、この新機能が使用されます。

次のステップ