Azure Stack HCI での SDN インフラストラクチャを計画する

完了

自身による Azure Stack HCI のソフトウェア定義ネットワーク (SDN) 機能の初期調査により、ネットワーク インフラストラクチャの回復性、機敏性、セキュリティ、管理性を改善するためにこれらを使用できるというあなたの確度は高まりました。 ただし、SDN の展開を成功させるには (特に、既存の環境と統合する必要がある場合)、適切な計画を立てる必要があることがわかっています。

SDN 展開を計画する

Azure Stack HCI クラスターに SDN を展開する前に、次のような関連するすべての前提条件をインフラストラクチャが満たしていることを確認する必要があります。

  • Azure Stack HCI クラスターのノードとインフラストラクチャの VM
  • ネットワーク コントローラー
  • Logical networks
  • ルーティング インフラストラクチャ
  • 物理ネットワーク

注意

このユニットでは、Azure Stack HCI での SDN の要件の概要を説明します。 このトピックに関する包括的な詳細情報については、このモジュールの「まとめ」ユニットで参照されている Microsoft のドキュメントをご覧ください。

Azure Stack HCI クラスターのノードとインフラストラクチャの VM

Azure Stack HCI クラスターの各ノードは、外部 Hyper-V 仮想スイッチの一部である少なくとも 1 つの物理アダプターを介して、管理論理ネットワークに接続されている必要があります。 ネットワーク コントローラー、RAS ゲートウェイ、ソフトウェア ロード バランサーなどの SDN インフラストラクチャ サービスをホストするすべての VM で、Azure Stack HCI オペレーティング システムが実行されている必要があります。

Microsoft からは、物理ホストと SDN インフラストラクチャ VM に関して、コンピューティング、ストレージ、ソフトウェアの最小限の要件が提供されています。 ただし、インフラストラクチャのサイズとリソースの要件は、最終的にはテナントのワークロード VM の要求によって決まることに注意してください。 幸い、SDN ではスケーリングが容易であり、必要に応じてネットワーク機能の仮想化ベースのサービスのインスタンスをさらに多く展開できます。 Azure Stack HCI クラスターのハードウェア機能によっては、物理クラスター ノードを追加することもできます。

注意

SDN は、ストレッチ (マルチサイト) クラスターではサポートされていません。

ネットワーク コントローラー

Active Directory (AD) Domain Services (DS) 環境でのネットワーク コントローラーのデプロイを準備するには、Kerberos ベースの認証と認可を設定する必要があります。 この承認により、ネットワーク コントローラーは SDN インフラストラクチャのすべての関連する側面を管理できます。 必要なアクセス許可は、ネットワーク コントローラーの展開の間に自動的に割り当てられます。

注意

高可用性の展開でのネットワーク コントローラーは、それぞれが個別の Azure Stack HCI クラスター ノードで実行される、3 つ以上の VM で構成されるクラスターを形成します。 すべてのネットワーク コントローラー インスタンスを、同じ AD DS ドメインに参加させます。

Logical networks

ネットワーク機能の仮想化ベースのサービスをサポートするには、次に示す必要な論理ネットワークをプロビジョニングする必要があります。

  • 管理および HNV プロバイダーの論理ネットワーク
  • ソフトウェア ロード バランサーとゲートウェイの論理ネットワーク

管理および HNV プロバイダーの論理ネットワーク

Azure Stack HCI クラスター ノードはすべて、管理論理ネットワークと Hyper-V ネットワーク仮想化 (HNV) プロバイダー論理ネットワークへのアクセス権を持っている必要があります。 IP アドレスの計画のためには、Azure Stack HCI クラスターの各ノードに、管理論理ネットワークから少なくとも 1 つの IP アドレスが割り当てられている必要があります。 管理ネットワークの IP アドレスは、静的に、または動的ホスト構成プロトコル (DHCP) を通じて、割り当てることができます。 SDN スタックにより、Azure Stack HCI クラスターの個々のノードに、HNV プロバイダー論理ネットワークの IP アドレスが自動的に割り当てられます。 アドレスは IP アドレス プールから提供され、ネットワーク コントローラーを通して指定され管理されます。

ネットワーク コントローラー REST ドメイン ネーム システム (DNS) 名は、動的な DNS の更新を許可するように構成する必要があります。 すべてのネットワーク コントローラー VM が、DNS レコードの作成と更新を許可されている必要があります。

Note

論理ネットワークの構成には、VLAN やスイッチ埋め込みチーミング (SET) といった機能の使用に応じた他の考慮事項があります。 これらの考慮事項について詳しくは、このモジュールの「まとめ」ユニットで参照されている Microsoft のドキュメントをご覧ください。

ソフトウェア ロード バランサーとゲートウェイの論理ネットワーク

ソフトウェア ロード バランサー マルチプレクサーと RAS ゲートウェイの VM の展開に対応するため、論理ネットワークをさらにプロビジョニングする必要があります。 それぞれについて、IP プレフィックス、VLAN ID、ゲートウェイ IP アドレスを識別する必要があります。

  • パブリック仮想 IP 論理ネットワーク。 このネットワークは、フロントエンド IP アドレスを表す仮想 IP を割り当てるためのものです。 外部クライアントは、これらの IP アドレスを使って、仮想ネットワーク内のリソースにアクセスします。 たとえば、パブリック ロード バランサーや、サイト間 VPN ゲートウェイのフロントエンド仮想 IP などです。 実質的に、その IP アドレス空間は SDN 環境の外部でルーティング可能である必要があります。 物理スイッチやルーターでこのネットワークを事前に構成したり、それに VLAN を割り当てたりする必要はありません。
  • プライベート仮想 IP 論理ネットワーク。 このネットワークは、Azure Stack HCI テナントのワークロードによってアクセスされる仮想 IP の割り当てを目的としているため、SDN 環境の外部でルーティングできる必要はありません。 物理スイッチやルーターでこのネットワークを事前に構成したり、それに VLAN を割り当てたりする必要はありません。
  • Generic Routing Encapsulation (GRE) 仮想 IP 論理ネットワーク。 GRE 仮想 IP ネットワークは、サイト間 GRE 接続用にゲートウェイ VM に割り当てられる仮想 IP を定義するためだけに使われます。 物理スイッチやルーターでこのネットワークを事前に構成したり、それに VLAN を割り当てたりする必要はありません。

ルーティング構成

パブリック仮想 IP 論理ネットワークと外部クライアントの間の接続を可能にするには、ソフトウェア ロード バランサー マルチプレクサーまたは RAS ゲートウェイから外部 Border Gateway Protocol (BGP) ピアにルーティング情報を公開することが必要です。 実質的に、ソフトウェア ロード バランサー マルチプレクサーと RAS ゲートウェイによってアドバタイズされた仮想 IP 論理ネットワークのルートを受信するように、SDN インフラストラクチャによって使用されるルーターで BGP ピアを構成する必要があります。

Azure Stack HCI クラスターのノードやゲートウェイの VM など、複数のネットワークに接続するように構成されているコンピューターでは、1 つの既定のゲートウェイだけが構成されている必要があります。 このゲートウェイは、Azure Stack HCI クラスターのノード、ネットワーク コントローラーの VM、ソフトウェア ロード バランサー マルチプレクサーの VM のための管理ネットワークに存在する必要があります。 ゲートウェイ VM の場合は、このゲートウェイは HNV プロバイダー ネットワークに存在する必要があります。

物理ネットワーク

スイッチとルーターに適用される他の前提条件があります。 これらの前提条件では、指定された最大転送単位 (MTU) の設定、リンク制御機能、高可用性と冗長性、ルーティングと VLAN タグ付けプロトコルをサポートするためのニーズを考慮する必要があります。

注意

最も一般的なスイッチ モデルとベンダーのサンプル構成ファイルは、Microsoft SDN の GitHub リポジトリにあります。