Skip navigation
1 2 3 Previous Next

にほんごVMware

404 posts

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、ここまでに作成した DHCP サービスを利用するオーバーレイ セグメントを追加作成します。

あわせて、前回までの投稿で追加した DHCP サーバの構成をもう少し掘り下げて確認してみます。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.8

 

今回の環境について。

前回までの投稿で作成した NSX-T ラボ環境に、オーバーレイセグメントを追加して、

Tier-1 ゲートウェイを介してオーバーレイ セグメント同士で通信できる環境を用意します。

 

すでに作成ずみのオーバーレイ セグメント「seg-overlay-01」は、説明順序の都合から

オーバーレイ セグメントに後から DHCP サーバ範囲を指定しており、手順が前後していました。

今回は、セグメント作成の時点で、あわせて DHCP 範囲を指定します。

nsxt25-add-segment.png

 

オーバーレイ セグメントの作成。(2回目)

それでは、セグメントを作成します。

NSX-T の Manager で、「ネットワーク」→「セグメント」→「セグメント」タブを開いて、

「セグメントの追加」をクリックします。

nsxt-seg2-01.png

 

次のパラメータを入力します。

  • セグメント名: セグメントに付与する名前を入力する。
  • 接続されたゲートウェイとタイプ: 接続する Tier-1 ゲートウェイを選択する。

そして、「サブネットの設定」リンクをクリックします。

nsxt-seg2-02.png

 

「サブネットの設定」画面で「サブネットの追加」をクリックして、次のパラメータを入力して「追加」をクリックします。

最初に作成したセグメント「seg-overlay-01」とはことなり、この追加作成時点で「DHCP範囲」も指定します。

  • ゲートウェイ: サブネットのゲートウェイ IP アドレスを入力する。
  • DHCP 範囲: ゲートウェイのアドレスと同じネットワークアドレスで、
    かつゲートウェイアドレスとは重複しないレンジで IP アドレスの範囲を入力する。

nsxt-seg2-04.png

 

パラメータが入力されたことを確認して、「適用」をクリックします。

nsxt-seg2-05.png

 

サブネットが作成され、サブネットの数「1」が表示されています。

トランスポート ゾーンで、作成ずみのオーバーレイ トランスポート ゾーン「tz-overlay-01」を選択して、

「保存」をクリックします。

nsxt-seg2-06.png

 

設定の続行を確認する画面は「いいえ」で閉じます。

nsxt-seg2-07.png

 

これで、Tier-1 ゲートウェイに 2つめのオーバーレイ セグメントが作成されました。

Tier-1 ゲートウェイには DHCP サーバが接続ずみであり、オーバーレイ セグメントで DHCP 範囲が指定されているので、

このセグメントに接続された VM では DHCP サービスが利用可能になっているはずです。

nsxt-seg2-08.png

 

VM へのオーバーレイ セグメントの接続と確認。

作成したオーバーレイセグメント「seg-overlay-02」を VM に接続します。

 

以前の投稿でも紹介しましたが、NSX-T のセグメントは vSphere Client ではポートグループとして扱えるので、

VM の「設定の編集」で、仮想ネットワーク アダプタに割り当てることができます。

nsxt-seg2-10.png

 

vm03 という VM に、seg-overlay-02 を割り当てました。

nsxt-seg2-21.png

 

ゲスト OS でネットワークを再起動すると、DHCP サーバから IP アドレス(172.16.2.10/24)と、

DNS サーバのアドレス(172.16.253.254)が設定されたことがわかります。

※ゲスト OS には、VMware Photon OS 3.0 を利用しました。

※この DHCP サーバ/DNS サービス の設定は、以前の投稿で設定ずみのものです。

 

そして、1つ目のセグメント(172.16.1.10)とも疎通確認できます。

nsxt-seg2-22.png

 

これで、最低限の NSX-T ラボ環境が Simplified UI で作成できたかなと思います。

 

NSX-T Polic API による DHCP サーバの補足。

NSX-T の Policy API 操作による DHCP サービスの構成は、基本的に DHCP リレー構成となるようです。

DHCP を利用するセグメントを2つ作成した状態で、「ネットワークとセキュリティの詳細設定」画面側から確認してみます。

 

「DHCP」→「サーバ」に、以前の投稿で作成した DHCP サーバ(172.16.254.254)が表示されます。

オーバーレイ セグメントで指定した DHCP 範囲も、「IP プール」に表示されています。

nsxt-seg2-15.png

 

「リレー プロファイル」を開くと、

DHCP サーバ(172.16.254.254)のプロファイルが構成されます。

nsxt-seg2-13.png

 

そして、Tier-1 ゲートウェイの、オーバーレイセグメントを接続しているポートには、

それぞれリレーサービスが構成されていることがわかります。

nsxt-seg2-14.png

 

以上、NSX-T 2.5 ラボ環境を、あえて Simplified UI だけで構築してみる話でした。

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-1 ゲートウェイ配下のオーバーレイ セグメントで DNS フォワーダを利用できるようにします。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.7

 

今回の DNS フォワーダの構成。

今回は、すでに Tier-1 ゲートウェイで NSX-T による DHCP サービスを利用可能にしてあります。(前回の投稿にて)

NSX-T による DNS フォワーダを追加して、Tier-1 ゲートウェイに接続します。

そして、DNS フォワーダから転送先 DNS サーバに到達できるようにしておく必要があるので、

Tier-1 ゲートウェイではルート アドバタイズ設定を追加します。

nsxt25-dnsf-01.png

 

デフォルト ゾーンの追加。

NSX-T の Manager で「ネットワーク」→「DNS」→「DNS ゾーン」を開き、

「DNS ゾーンの追加」→「デフォルト ゾーンの追加」をクリックします。

nsxt-t1-dns-02.png

 

DNS ゾーンのパラメータを入力して「保存」をクリックします。

  • ゾーン名: いわゆる DNS のゾーンの名前ではなく、この設定に付与するオブジェクト名を入力。
  • DNS サーバ: クエリを転送する DNS サーバをカンマ区切りで入力。
    実際に DNS フォワーダから到達できる必要あり。
  • 転送元 IP: DNS サーバに接続する際の元 IP。
    今回はルート アドバタイズと SNAT だけで到達できる環境なので空欄のまま。

nsxt-t1-dns-03.png

 

DNS ゾーンが追加されました。

nsxt-t1-dns-04.png

 

DNS サービスの追加。

DNS サービス(フォワーダ)を追加します。

となりのタブの「DNS サービス」を開き、「DNS サービスの追加」をクリックします。

そしてパラメータを入力して「保存」をクリックします。

  • 名前
  • Tier-0/Tier-1 ゲートウェイ: 以前に作成した Tier-1 ゲートウェイを選択。
  • DNS サービス IP: この DNS フォワーダに設定する IP アドレスを入力する。
    このアドレスは、NSX-T の他のセグメントで使用していない範囲にする必要がある。
  • デフォルト DNS ゾーン: 先ほど作成した「DNS ゾーン」を選択する。

nsxt-t1-dns-06.png

 

DNS サービスが追加されました。

「状態」は、更新マークをクリックすると緑の「稼働中」になるはずです。

nsxt-t1-dns-07.png

 

この画面で、フォワード先の DNS サーバのアドレスを表示することもできます。

nsxt-t1-dns-09.png

 

Tier-1 ゲートウェイ。

DNS サービスを接続した Tier-1 ゲートウェイ(今回は t1-gw-01)では、

ルート アドバタイズを追加する必要があります。

 

「ネットワーク」→「Tier-1 ゲートウェイ」を開き、

対象の Tier-1 ゲートウェイで「編集」をクリックします。

nsxt-t1-dns-12.png

 

「ルート アドバタイズ」を開き、

「DNS フォワーダのすべてのルート」を ON(緑)にして、「保存」をクリックします。

nsxt-t1-dns-14.png

 

「編集を終了」をクリックして閉じます。

これで、DNS フォワーダが利用可能になるはずです。

nsxt-t1-dns-16.png

 

ゲスト OS での確認。

Tier-1 ゲートウェイ配下のセグメントに接続している VM では、

ゲスト OS 内でネットワークを再起動(DHCP でのネットワーク再設定)をすると、

参照先の DNS サーバとして、DNS フォワーダのアドレスが設定されたことがわかります。

ちなみに、ゲスト OS は VMware Photon OS 3.0 なので、DNS サーバのアドレスは

「resolvectl dns」コマンドで確認しています。

nsxt-t1-dns-18-a.png

 

今回の手順は、製品ドキュメントだと下記のあたりが参考になります。

Add a DNS Zone

Add a DNS Forwarder Service

 

もう少し続くつもり。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.9

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、オーバーレイ セグメントで DHCP サーバを利用できるようにします。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.6

 

今回の DHCP サービスの構成。

NSX-T の従来の「ネットワークとセキュリティの詳細設定」画面から

オーバーレイ ネットワークに DHCP サーバを用意する場合、

論理スイッチ(セグメント)ごとに DHCP サーバを作成していました。

 

一方、Policy API では、 DHCP サーバを Tier-1 ゲートウェイごとに作成して、

各オーバーレイ セグメントでは DHCP リレーで利用します。

nsxt25-dhcp-sv-01.png

 

DHCP サーバの追加。

まず、DHCP サーバを追加(作成)します。

NSX-T の Manager で「ネットワーク」→「DHCP」を開き、「サーバを追加」をクリックします。

nsxt-dhcp-01.png

 

DHCP サーバのパラメータを入力して「保存」をクリックします。

  • サーバ タイプ: 「DHCP サーバ」を選択。
  • サーバ名: DHCP サーバに設定する名前を入力する。
  • サーバの IP アドレス: 「IP アドレス/サブネットマスクの長さ」を入力する。
    これは NSX-T のオーバーレイ ネットワークなどで使用中のネットワーク アドレスと重ならないようにする。
  • Edge クラスタ: 作成ずみの Edge クラスタを選択する。

nsxt-dhcp-02.png

 

DHCP サーバが作成されました。

nsxt-dhcp-03.png

 

Tier-1 ゲートウェイへの DHCP サーバ接続。

作成した DHCP サーバを、オーバーレイ セグメントを接続している Tier-1 ゲートウェイに接続します。

「ネットワーク」→「Tier-1 ゲートウェイ」で、以前に作成した Tier-1 ゲートウェイ「t1-gw-01」を表示すると、

まだ「IP アドレス管理」が「未設定」になっています。

nsxt-dhcp-04.png

 

Tier-1 ゲートウェイの「編集」をクリックします。

nsxt-dhcp-05.png

 

「IP アドレス管理」の隣にある「IP を割り当てない設定」リンクをクリックします。

nsxt-dhcp-06.png

 

「IP アドレス管理の設定」画面で、パラメータを入力して「保存」をクリックします。

  • タイプ: 「DHCP ローカル サーバ」を選択。
  • DHCP サーバ: 直前に作成した「dhcp-sv-01」を選択。

nsxt-dhcp-08.png

 

「IP アドレス管理」が「ローカル | サーバ」になったことを確認して、「保存」をクリックします。

nsxt-dhcp-09.png

 

Tier-1 ゲートウェイの設定画面は「編集の終了」をクリックして閉じます。

nsxt-dhcp-10.png

 

オーバーレイ セグメントでの DHCP 範囲の設定。

オーバーレイ セグメントで DHCP リレーを構成する必要がありますが、

これは「DHCP リレー」のような設定画面はありません。

かわりに、セグメントの「サブネット」で、「DHCP 範囲」を設定します。

 

「ネットワーク」→「セグメント」→「セグメント」タブを開くと、

以前に作成したオーバーレイ セグメント「seg-overlay-01」があるので、

このセグメントで DHCP を利用できるようにします。

nsxt-dhcp-11.png

 

セグメントの「編集」をクリックします。

nsxt-dhcp-12.png

 

セグメントが編集可能な状態になるので、サブネット(の数)のリンクをクリックします。

nsxt-dhcp-13.png

 

「サブネットの設定」画面が開くので、「編集」をクリックします。

nsxt-dhcp-16.png

 

空欄になっていた「DHCP 範囲」に、IP アドレスの範囲を入力して、「追加」をクリックします。

これは入力済みの「ゲートウェイ」と合わせる必要があります。

例では、ゲートウェイが 17.16.1.1/24 と入力ずみなので、

そのネットワーク アドレス内でゲートウェイアドレスと重複しないように

「172.16.1.10-172.16.1.250」と入力しています。

nsxt-dhcp-17.png

 

DHCP 範囲が表示されたことを確認して、「適用」をクリックします。

ちなみに、セグメントに「DHCP 範囲」を設定すると UI から削除することはできず、

セグメントで DHCP 使用をやめる場合には、セグメント自体をいったん削除することになります。

nsxt-dhcp-18.png

 

「保存」をクリックします。

nsxt-dhcp-19.png

 

「編集を終了」をクリックして、画面を閉じます。

nsxt-dhcp-20.png

 

ゲスト OS でのネットワーク アドレス取得。

オーバーレイ セグメント「seg-overlay-01」を割り当てている仮想マシンでは、

ゲスト OS のネットワーク設定で DHCP を利用するようにしてあります。

 

ゲスト OS でネットワークを再起動すると、

「DHCP 範囲」で設定した範囲から、IP アドレス(172.16.1.10/24)が設定されます。

そして、デフォルト ゲートウェイには、オーバーレイ セグメントで指定した

ゲートウェイ アドレス(172.16.1.1)が設定されます。

ちなみに、例として使用しているゲスト OS は、VMware Photon OS 3.0 なので、

「systemctl restart systemd-networkd」コマンドでネットワークを再起動しています。

nsxt-dhcp-21.png

 

今回の手順については、製品ドキュメントでは下記のあたりが参考になります。

Add a DHCP Server

 

ちなみに、今回作成した DHCP サーバの仕組みについては、

下記の投稿(2つ目の DHCP 利用セグメント追加)の最後でも紹介しています。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.9

 

つづく。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.8

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-0 ゲートウェイに SNAT ルールを追加します。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.5

 

今回の NSX-T ラボでの SNAT。

ラボ環境からラボの外部(別環境のネットワークやインターネットなど)に出る場合、

ラボ環境内のネットワークアドレスがプライベートなためルーティングできず、

対策として(外部に出た通信が戻れるように)ラボの出口になるルータで SNAT を利用することがあります。

この場合、ラボの出口になるルータには(ラボ内のプライベートではない)外部ネットワークのアドレスが付与されていています。

そしてラボ内からの通信については、SNAT ルールによって、通信元アドレス(Source アドレス)を

プライベートなアドレスからラボの出口になるルータのグローバル アドレスに変換します。

 

今回は、NSX-T のオーバーレイ セグメントに接続された VM が NSX-T より外部のネットワークにアクセスした際の「戻り」のために、

Tier-0 ゲートウェイで SNAT ルールを設定します。

これにより Tier-0 ゲートウェイ「t0-gw-01」の SNAT にて、オーバーレイ セグメントからの通信元アドレス「172.16.x.x」が、

「192.168.200.2」(t0-gw-01 のアップリンク インターフェースのアドレス)に変換されるようにします。

 

そして下図の(NSX-T のラボとは直接関係しない部分の)補足として・・・

  • 「外部ルータ」は、本来は不要ですが、自宅ラボ環境と今回の SNAT とは関係ない検証の都合により配置されています。
  • 記載が省略されていますが「外部ルータ」のデフォルト ゲートウェイは「ルータ(インターネットへ)」に向けてあります。
  • 実際にこのラボ環境からインターネットなどにアクセスする場合は、図の最上部にある「ルータ」でも SNAT を利用します。

snat-01.png

 

Tier-0 ゲートウェイ への SNAT ルール追加。

それでは、Tier-0 ゲートウェイに SNAT ルールを追加します。

 

NSX-T の Manager で、「ネットワーク」→「NAT」を開き、

Tier-0 ゲートウェイ(ここでは t0-gw-01)を選択して「NAT ルールの追加」をクリックします。

nsxt25-snat-01.png

 

つぎのパラメータを入力して「保存」をクリックします。

  • 名前: SNAT ルールにつける名前を入力する。
  • アクション: SNAT を選択する。
  • 送信元 IP: SNAT の対象とするアドレスを入力する。
    今回は オーバーレイ セグメントで利用するつもりのネットワークアドレス(172.16.0.0/16)を入力。
  • 変換された IP: Tier-0 ゲートウェイの アップリンクにあたる インターフェースの IP アドレスを入力。

nsxt25-snat-02.png

 

これで SNAT ルールが作成されました。

状態が「不明」の場合は、となりの更新マークをクリックすると「稼働中」になるはずです。

nsxt25-snat-03.png

 

これで、オーバーレイ セグメントに接続された VM(vm01)のゲスト OS でネットワーク設定されていれば

SNAT ルールが機能して NSX-T 外部の(Tier-0 ゲートウェイより外部の)ネットワークに出て、戻ってこれるようになるはずです。

 

今回の手順は、製品ドキュメントだと下記のあたりが参考になります。

Configure NAT on a Gateway

 

まだ続く。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.7

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-0 ゲートウェイにスタティック ルートを追加します。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.4

 

今回の NSX-T ラボのネットワーク セグメント構成。

今回の NSX-T ラボは、下図のようなネットワークを構成しています。

  • NSX-T で Tier-0 / Tier-1 ゲートウェイを利用した最小限のネットワークを構成しようと思い、
    あえて Tier-0 ゲートウェイでルーティングプロトコル(BGP)は設定せず、スタティックルートを設定します。
    一方、その観点では図中の「外部ルータ」は不要なのですが、既存の自宅ラボのネットワーク環境で
    Tier-0 ゲートウェイのアップリンクに VLAN ID を設定したかったため、やむなく配置しています。
  • 「外部ルータ」というのは、NSX Edge ではない(NSX-T の機能によるものではない)ルータです。
    この投稿では割愛していますが、このルータにも 172.16.0.0/16 宛を 192.168.200.2 にむけるスタティック ルートを設定しています。
  • Tier-0 ゲートウェイには、デフォルトルートを外部ルータに向けるスタティックルートを設定します。
    (この設定が、この投稿の主役です)
  • Tier-0 / Tier-1 ゲートウェイ間は、Tier-1 ゲートウェイのルート アドバタイズが設定されています。
    (Tier-1 ゲートウェイ作成のときに設定ずみのものです)
  • 図では省略していますが、「クライアントマシン」には 172.16.0.0/16 宛を外部ルータに向けるスタティック ルート、
    vm01 にはデフォルトゲートウェイとして 172.16.1.1 を設定しています。

lab-static-route-01.png

 

上記のようなルーティング設定をして、図中の「クライアント マシン」と「vm01」が通信できるようにします。

lab-static-route-02.png

 

Tier-0 ゲートウェイへのスタティック ルート追加。

NSX-T の Manager で、「ネットワーク」→「Tier-0 ゲートウェイ」を開きます。

この時点では、まだ Tier-0 ゲートウェイのスタティック ルートはゼロ件です。

nsxt-t1-route-01.png

 

Tier-0 ゲートウェイの「編集」をクリックします。

nsxt-t1-route-02.png

 

「ルーティング」→「スタティック ルート」のとなりの「編集」リンクをクリックします。

nsxt-t1-route-03.png

 

「スタティック ルートの追加」をクリックして、次のパラメータを入力します。

  • 名前: このルーティングを識別する名前を入力する。
  • ネットワーク: デフォルト ルートとして「0.0.0.0/0」を入力する。

そして、「ネクスト ホップの設定」リンクをクリックします。

nsxt-t1-route-05.png

 

「ネクスト ホップの追加」をクリックして、下記を入力して「追加」をクリックします。

  • IP アドレス: NSX-T 環境の外部ネットワークである「外部ルータ」の IP アドレスを指定。
  • インターフェイス: Tier-0 ゲートウェイ作成時に、あわせて作成した「t0-uplink-01」を選択。

nsxt-t1-route-07.png

 

ネクスト ホップが追加されたことを確認して「適用」をクリックします。

nsxt-t1-route-08.png

 

ネクスト ホップが 1 件となったことを確認して「閉じる」をクリックします。

nsxt-t1-route-09.png

 

スタティック ルートが 1件 になったことを確認して「編集を終了」をクリックします。

nsxt-t1-route-10.png

 

これで、Tier-0 ゲートウェイにスタティック ルートが設定されました。

「クライアントマシン」には 172.16.0.0/16 宛を外部ルータに向けるスタティック ルート、

vm01 にはデフォルトゲートウェイとして 172.16.1.1 を設定すれば、相互に通信できるようになるはずです。

 

今回の設定は、製品ドキュメントだと下記のあたりが参考になります。

Configure a Static Route

 

まだつづく。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.6

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、従来の「Tier-1 ルータ」にあたる「Tier-1 ゲートウェイ」を作成して、

あわせて従来の「オーバーレイ 論理スイッチ」のかわりになるセグメントを作成/接続します。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.3

 

Tier-1 ゲートウェイの作成。

さっそくですが、Tier-1 ゲートウェイを作成します。

この先の手順で指定する Tier-0 ゲートウェイ「t0-gw-01」は、前回の投稿で作成したものです。

 

NSX-T の Manager で、「ネットワーク」→「Tier-1 ゲートウェイ」を開き、

「Tier-1 ゲートウェイの追加」をクリックします。

t1-gw-and-seg-01.png

 

今回は、最小限のパラメータだけ設定変更しています。

まだ「保存」はせず、このままルート アドバタイズの設定します。

  • Tier-1 ゲートウェイの名前: ここでは「t1-gw-01」とした。
  • リンクされた Tier-0 ゲートウェイ: 前回作成した Tier-0 ゲートウェイを選択する。
  • Edge クラスタ:  作成ずみの Edge クラスタを選択する。

t1-gw-and-seg-03.png

 

「ルート アドバタイズ」を開き、「接続されているすべてのセグメントおよびサービス ポート」を

有効 (緑)にして、「保存」をクリックします。

t1-gw-and-seg-04.png

 

その後の確認画面は「いいえ」で、Tier-1 ゲートウェイの設定画面はいったん閉じます。

t1-gw-and-seg-05.png

 

オーバーレイ セグメントの作成。

オーバーレイ セグメントを、Tier-1 ゲートウェイに接続した状態で作成します。

 

これは VLAN のセグメントの作成と同様に、

NSX-T の Manager で、「ネットワーク」→「セグメント」を開き、「セグメントの追加」をクリックします。

表示されたセグメントの設定入力の画面で、次のパラメータを入力します。

  • セグメント名
  • 接続されたゲートウェイとタイプ: これは直前に作成した Tier-1 ゲートウェイを選択します。

そうすると、「サブネット」にある「サブネットの設定」リンクがアクティブになるので、クリックします。

t1-gw-and-seg-07.png

 

「サブネットの追加」をクリックし、ここでは「ゲートウェイ」の IP アドレスだけ入力して、「追加」をクリックします。

t1-gw-and-seg-21.png

 

ゲートウェイのアドレスが追加されたことを確認して「適用」をクリックします。

t1-gw-and-seg-22.png

 

セグメントの設定入力画面に戻ると、サブネットが「1」表示されます。

トランスポート ゾーンに、作成ずみのオーバーレイ トランスポート ゾーンを選択して「保存」します。

t1-gw-and-seg-10.png

 

設定続行の確認画面は「いいえ」で閉じます。

t1-gw-and-seg-11.png

 

これで、オーバーレイ セグメント 1つ接続してある Tier-1 ゲートウェイが作成されました。

作成されたオーバーレイ セグメントで「詳細設定」をクリックすると・・・

t1-gw-and-seg-13.png

 

オーバーレイ セグメントも、VLAN セグメントと同様に、

「ネットワークとセキュリティの詳細設定」画面でのそのオブジェクトを表示することができます。

t1-gw-and-seg-14.png

 

オーバーレイ セグメントの VM への接続。

作成したオーバレイ セグメントは、従来の NSX-T オーバーレイ論理スイッチと同様に、

VM の vNIC にポートグループとして割り当てることができます。

 

vSphere Client では、VM の「設定の編集」画面にも、セグメントが表示されます。

※この VM は、NSX-T のホスト トランスポート ノードとしてセットアップずみの ESXi に配置されています。

t1-gw-and-seg-16.png

 

セグメントを割り当てた vNIC です。

VM を起動して、ゲスト OS 内でセグメントにあわせた IP アドレスを設定すれば、

さきほどセグメントの「サブネット」で設定したゲートウェイにアドレスに通信可能となるはずです。

(たとえば ping などで)

t1-gw-and-seg-17.png

 

今回の手順は、製品ドキュメントでは下記のあたりが参考になります。

Add a Tier-1 Gateway

Add a Segment ※オーバーレイ セグメントは VLAN セグメントと同じ画面から作成する。

 

続く。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.5

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、従来の「Tier-0 ルータ」にあたる「Tier-0 ゲートウェイ」を作成します。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.2

 

Tier-0 ゲートウェイの作成。

Tier-0 ゲートウェイを作成します。

この手順で指定するアップリンクの VLAN セグメント「seg-vlan-0200」は、前回の投稿で作成したものです。

 

NSX-T の Manager の「ネットワーク」→ 「Tier-0 ゲートウェイ」画面を開き、

「Tier-0 ゲートウェイの追加」をクリックします。

t0-gw-01.png

 

下記のパラメータを設定して「保存」します。

  • Tier-0 ゲートウェイの名前: ここでは「t0-gw-01」としている。
  • HA モード: アクティブ/スタンバイ
  • Edge クラスタ: 作成ずみの Edge クラスタを選択する。

t0-gw-02.png

 

Tier-0 には作成後に設定変更するパラメータがあるため、

「Tier-0 ゲートウェイの設定を続行しますか?」では「はい」を選択します。

t0-gw-03.png

 

Tier-0 ルータ作成時に表示されていた入力画面が表示されます。

アップリンクとなるポートを作成するため、

「インターフェース」→「設定」をクリックします。

t0-gw-04.png

 

「インターフェイスの設定」画面が表示されるので、「インターフェイスの追加」をクリックします。

t0-gw-05.png

 

次のパラメータを入力してから「保存」をクリックします。

  • 名前: インターフェースの名前を入力する。
  • タイプ: デフォルトのまま「外部」を選択。
  • IP アドレス/マスク: NSX 外部の VLAN と、NSX-T の VLAN セグメントにあわせた IP アドレスを入力する。
  • 接続先(セグメント): 作成ずみの VLAN セグメント「seg-vlan-0200」を選択する。
  • Edge ノード: 作成ずみの Edge ノードを選択する。

t0-gw-07.png

 

インターフェースが作成されたことを確認して「閉じる」をクリックします。

「状態」が「不明」になっている場合は、更新ボタンをクリックすると「稼働中」になるはずです。

t0-gw-08.png

 

「インターフェイス」に「1」(インターフェースの数)が表示されるようになります。

そのまま画面を下にスクロールして「編集を終了」をクリックします。

t0-gw-10.png

 

「ネットワークとセキュリティの詳細設定」での Tier-0 ゲートウェイ。

作成した Tier-0 ゲートウェイは、「ネットワークとセキュリティの詳細設定」画面では

「Tier-0 ルータ」と同様に表示されます。

 

「ネットワークとセキュリティの詳細設定」配下の対応する画面には、

「ネットワーク」画面で表示されるオブジェクトの「詳細設定」からでも表示できます。

t0-gw-011.png

 

前回作成した「セグメント」と同様に、Simplified UI で作成した Tier-0 / Tier-1 ゲートウェイの場合も、

先頭に丸いマークが表示されています。

t0-gw-12.png

 

今回の手順は、製品ドキュメントだと下記のあたりが参考になります。

Add a Tier-0 Gateway

 

つづく ...

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.4

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

まず、従来の「VLAN 論理スイッチ」にあたる「VLAN セグメント」を作成します。

 

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

VLAN セグメントの作成。

さっそくですが、VLAN のセグメントを作成します。

NSX-T の Manager にログインして、「ネットワーク」画面を開きます。

seg-vlan-01.png

 

画面左にある「セグメント」→「セグメント」タブにある、「セグメントの追加」をクリックします。

セグメントの設定入力画面が表示されるので、下記を入力して「保存」します。

  • セグメント名: 今回は、seg-vlan-0200。
  • トランスポート ゾーン: tz-vlan-01。これは Edge ノードを接続ずみの VLAN トランスポート ゾーン。
  • VLAN: 200。今回は NSX-Tと外部との境界になるネットワークに VLAN ID 200 を使用した。

seg-vlan-02.png

 

セグメントを作成すると、設定を続行するか確認があります。

「はい」を選択すると、作成したオブジェクトでそのまま(ひとつ前の画面で)設定作業を続けられます。

今回は「いいえ」で閉じます。

seg-vlan-03.png

 

セグメントが作成されました。

「状態」が稼働中(緑色)になっていない場合は、少し待ってから隣の更新ボタンをクリックすると、

稼働中の状態になるはずです。

seg-vlan-04.png

 

VLAN セグメント/VLAN 論理スイッチ は異なるのか?

セグメントを作成した後に、

「ネットワークとセキュリティの詳細設定」→「スイッチング」を開いて、

論理スイッチ(従来のセグメントにあたるもの)を確認してみます。

※この確認は、セグメント/論理スイッチの比較のためなので、通常のセグメント作成では不要です。

 

今回は、この画面で「ls-vlan-0200」という従来どおりの論理スイッチを作成してあります。

「セグメント」には、従来の論理スイッチとはことなり先頭に丸いマークが表示されています。

seg-vlan-05.png

 

この「ネットワークとセキュリティの詳細設定」で論理スイッチとセグメントそれぞれの

設定変更の画面を開くと、おたがいに違うオブジェクトとして扱われていることがわかりやすいと思います。

 

まず、「ネットワークとセキュリティの詳細設定」で

VLAN 論理スイッチの設定画面を開いてみます。

当然ながら、VLAN ID などの設定変更ができるようになっています。

seg-vlan-06.png

 

一方、「ネットワークとセキュリティの詳細設定」で

VLAN セグメントの設定画面を開いてみると、ほぼ設定変更ができなくなっています。

seg-vlan-07.png

 

Simplified UI / Policy API による NSX-T 環境には、これまでの NSX-T とは明確に差異があるので、

Policy API ならではの定義方法を意識する必要がありそうです。

 

今回の手順については、製品ドキュメントだと下記のあたりが参考になります。

Add a Segment

 

つづく。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.3

NSX-T 2.4 から、NSX-T の Web UI が大きく変更されました。

特に大きな変更点として、従来の NSX-T の操作/設定は「ネットワークとセキュリティの詳細設定」画面に移動され、

あらたに「ネットワーク」「セキュリティ」といったシンプルな画面が追加されています。

(Simplified UI や、Policy UI と呼ばれたりするようです。)

そこで、あらたな UI に慣れるべく NSX-T 2.5 のラボ環境を「ネットワーク」画面から作成してみます。

 

NSX-T 2.5 の Web UI の様子。

NSX-T の Simplified UI での「ネットワーク」「セキュリティ」の部分です。

 

新しい「ネットワーク」画面です。

以前とはオブジェクトの名前が変更(例えば「Tier-0 ルータ」が「Tier-0 ゲートウェイ」に)されています。

これらは名前が変更されただけではなく、以前の方法で作成されたオブジェクトとは

別種類のものとして扱われます。

nsxt-25-ui-01.png

 

新しい「セキュリティ」画面です。

nsxt-25-ui-02.png

 

従来どおりの操作も「ネットワークとセキュリティの詳細設定」画面から可能です。

たとえば「ネットワーク」画面で作成されたオブジェクトは、こちらの画面にも表示されますが、

基本的には設定変更などは不可で、作成された「ネットワーク」画面側で操作することになります。

nsxt-25-ui-03.png

 

Simplified UI は、NSX-T の Policy API をベースとしたもので、

今後の NSX-T では、従来からの API ではなく、おもに Policy API が使用される想定のようです。

 

NSX-T Data Center 2.5 の API Guide は、下記の Web サイトで確認することができます。

NSX-T Data Center REST API - VMware API Explorer - VMware {code}

 

リファレンス見出しの抜粋をもとに説明すると、

おおまかに下記のようなイメージとして捉えるとよさそうです。

  • 2 API Methods
    • 2.1 AAA
    • 2.2 Cloud Service Manager
    • 2.3 Management Plane API ★従来の NSX-T UI のベースとなる API(今の「~詳細設定」)
    • 2.4 Nsx-Intelligence
    • 2.5 Policy ★新たな Simplified UI のベースとなる API
    • 2.6 Upgrade

 

今回のラボ環境構築の流れ。

今回作成する NSX-T 環境は、以前に紹介した  NSX-T 2.4 環境と同様のものです。

環境のイメージについては、下記の投稿にあります。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

Simplified UI の「ネットワーク」画面から操作するのは、

Tier-0 ルータ / Tier-1 ルータ / 論理スイッチといったコンポーネントです。

その前提となる トランスポート ノード や Edge クラスタのセットアップについては、ここでは省略します。

以前に投稿した内容ですと、下記(Host / Edge トランスポート ノードのセットアップ)までは実施ずみとしています。

自宅ラボで NSX-T 2.4 環境を構築する。Part.7

 

それでは、順に Simplified UI による手順を紹介していきます。

 

VLAN セグメントの作成。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.2

 

Tier-0 ゲートウェイの作成。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.3

 

Tier-1 ゲートウェイとオーバーレイ セグメントの作成。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.4

 

Tier-0 ゲートウェイへのスタティック ルート追加。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.5

 

Tier-0 ゲートウェイへの SNAT ルール追加。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.6

 

DHCP サーバの追加。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.7

 

DNS サービス(DNS フォワーダ)の追加。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.8

 

オーバーレイ セグメントの追加。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.9

 

 

第2回(VLAN セグメントの作成)につづく・・・

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.2

vSphere 6.7 U3 / vSAN 6.7 U3 から、VMware Cloud Native Storage と呼ばれるソリューションが提供されました。

これにより、Kubernetes から vSphere Container Storage Interface(CSI)Driver で利用されているボリュームが確認しやすくなります。

vmw-cns-00.png

 

さっそく、ドキュメントをもとに試してみます。

About Getting Started with VMware Cloud Native Storage

 

今回の環境。

Kubernetes のバージョンは、ドキュメントで利用しているものにしましたが、

Kubernetes の Maser / Worker は個人的に使い慣れている Oracle Linux 7 にしています。

  • vCenter Server 6.7 U3 / ESXi 6.7 U3 / vSAN 6.7 U3
  • Kubenetes Node OS: Oracle Linux 7
    • Master x 1、Worker x3
    • ESXi / vSAN 上の VM として作成。
  • Kubernetes 1.14.2

 

VM の設定。

Cloud Native Storage(CNS)を利用する Kubernetes ノードの VM では、

disk.EnableUUID というパラメータを設定しておきます。

vSphere Client から設定可能ですが、今回は PowerCLI で設定しています。

PowerCLI> Get-Folder -Type VM -Name "ol7-k8s-lab-03" | Get-VM | Get-AdvancedSetting -Name disk.EnableUUID | select Entity,Name,Value | sort Entity

 

Entity   Name            Value

------   ----            -----

k8s-m-31 disk.EnableUUID TRUE

k8s-w-31 disk.EnableUUID TRUE

k8s-w-32 disk.EnableUUID TRUE

k8s-w-33 disk.EnableUUID TRUE

 

 

また、Kubernetes のセットアップで利用する kubeadm の要件を考慮して

VM あたりのリソースは、2 vCPU、メモリ 4GB 以上にしてあります。

PowerCLI> Get-Folder -Type VM -Name "ol7-k8s-lab-03" | Get-VM | select Name,PowerState,NumCPU,MemoryGB | sort Name | ft -AutoSize

 

 

Name     PowerState NumCpu MemoryGB

----     ---------- ------ --------

k8s-m-31  PoweredOn      2        4

k8s-w-31  PoweredOn      2        4

k8s-w-32  PoweredOn      2        4

k8s-w-33  PoweredOn      2        4

 

 

Linux OS の準備。

ドキュメントでは Ubuntu を使用していますが、

今回は、あえて Oracle Linux を使用してみました。

ただし Kubernetes にかかわる kubeadm と Docker は、Oracle Linux むけのものではなく

それぞれのプロダクトの Yum リポジトリを追加して、そこからインストールしています。

 

Linux OS は ISO インストーラからインストールし、ネットワーク設定を済ませた状態です。

今回は、kubernetes のセットアップからを手動で試しやすいように、

下記のような Ansible Playbook を作成して、OS のセットアップとファイル配布をしています。

GitHub - gowatana/vmware-cns-demo

 

Kubernetes クラスタ(Master)のセットアップ。

まず、kubeadm で Master ノードをセットアップします。

この環境での Master ノードは 1台のみです。

 

Master ノードにセットアップする OS に root ユーザでログインします。

Ansible で /root/01_kubeadm/kubeadm-init-master.yml ファイルを配置してあるので、

これをもとに kubeadm init コマンドを実行します。

[root@k8s-m-31 ~]# kubeadm init --config ./01_kubeadm/kubeadm-init-master.yml

 

Master ノードがセットアップされました。

まだ NotReady ですが、このまま進めます。

[root@k8s-m-31 ~]# export KUBECONFIG=/etc/kubernetes/admin.conf

[root@k8s-m-31 ~]# kubectl get nodes

NAME       STATUS     ROLES    AGE   VERSION

k8s-m-31   NotReady   master   58s   v1.14.2

 

今回は root ユーザのみですすめるので、

再ログイン時に環境変数 KUBECONFIG が設定されるように、.bash_profile にも追記しておきます。

[root@k8s-m-31 ~]# echo 'export KUBECONFIG=/etc/kubernetes/admin.conf' >> /root/.bash_profile

 

Worker ノードのセットアップで利用する discovery.yml を取得しておきます。

[root@k8s-m-31 ~]# kubectl -n kube-public get configmap cluster-info -o jsonpath='{.data.kubeconfig}' > /etc/kubernetes/discovery.yml

 

discovery.yml ファイルは、これから Worker ノードにする OS の、/etc/kubernetes/ ディレクトリ配下に

scp などでコピーしておきます。

[root@k8s-m-31 ~]# scp /etc/kubernetes/discovery.yml <Worker Nodeのアドレス>:/etc/kubernetes/

 

Flannel のセットアップ。

Kubernetes のノード間のネットワークを構成する、Flannel をセットアップしておきます。

[root@k8s-m-31 ~]# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml

clusterrole.rbac.authorization.k8s.io/flannel created

clusterrolebinding.rbac.authorization.k8s.io/flannel created

serviceaccount/flannel created

configmap/kube-flannel-cfg created

daemonset.extensions/kube-flannel-ds-amd64 created

daemonset.extensions/kube-flannel-ds-arm64 created

daemonset.extensions/kube-flannel-ds-arm created

daemonset.extensions/kube-flannel-ds-ppc64le created

daemonset.extensions/kube-flannel-ds-s390x created

 

Kubernetes クラスタ(Worker)のセットアップ。

Worker ノードそれぞれで kubeadm join を実行し、セットアップをすすめます。

Ansible で配置ずみの 01_kubeadm/kubeadm-init-worker.yml ファイルと、

セットアップずみの Master ノードから取得した discovery.yml ファイルを使用しています。

[root@k8s-w-31 ~]# kubeadm join --config ./01_kubeadm/kubeadm-init-worker.yml

 

kubeadm join を実行したノードが追加されたことがわかります。

[root@k8s-m-31 ~]# kubectl get nodes

NAME       STATUS   ROLES    AGE   VERSION

k8s-m-31   Ready    master   16m   v1.14.2

k8s-w-31   Ready    <none>   32s   v1.14.2

 

今回は、Master 1台、Worker 3台の構成にしました。

[root@k8s-m-31 ~]# kubectl get nodes

NAME       STATUS   ROLES    AGE     VERSION

k8s-m-31   Ready    master   18m     v1.14.2

k8s-w-31   Ready    <none>   2m40s   v1.14.2

k8s-w-32   Ready    <none>   53s     v1.14.2

k8s-w-33   Ready    <none>   31s     v1.14.2

 

この時点だと、まだ Worker ノードがコンテナを起動しない状態(NoSchedule)ですが、

このまま次に進みます。

[root@k8s-m-31 ~]# kubectl describe nodes | egrep "Taints:|Name:"

Name:               k8s-m-31

Taints:             node-role.kubernetes.io/master:NoSchedule

Name:               k8s-w-31

Taints:             node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

Name:               k8s-w-32

Taints:             node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

Name:               k8s-w-33

Taints:             node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

 

Cloud Provider for vSphere のセットアップ。

Kubernetes と vCenter が連携するための「Kubernetes Cloud Provider for vSphere」をセットアップします。

GitHub - kubernetes/cloud-provider-vsphere: Kubernetes Cloud Provider for vSphere

 

ここからは、すべて Master ノードで作業します。

今回のデモでは、Cloud Provider で指定する設定ファイルのテンプレートも、Ansible で配布しています。

[root@k8s-m-31 ~]# ls -1 ./02_k8s-csi/

csi-driver-deploy.yaml

csi-driver-rbac.yaml

csi-vsphere.conf

vsphere.conf

 

このうち、vsphere.conf を環境にあわせて編集します。

  • このサンプルファイルは自宅ラボの環境です。
  • ユーザー /  パスワードは、デモむけに あえて安直なものにしています。

[root@k8s-m-31 ~]# cat ./02_k8s-csi/vsphere.conf

[Global]

insecure-flag = "true"

 

[VirtualCenter "infra-vc-01.go-lab.jp"]

user = "administrator@vsphere.local"

password = "VMware1!"

port = "443"

datacenters = "infra-dc-01"

 

[Network]

public-network = "vxw-dvs-30-virtualwire-14-sid-10003-ls-lab-k8s-003"

 

vsphere.conf ファイルをもとに、cloud-config という ConfigMap を作成します。

この名前は、後続の kubectl apply で指定している YAML ファイルの内容に合わせてあります。

[root@k8s-m-31 ~]# kubectl create configmap cloud-config -n kube-system --from-file ./02_k8s-csi/vsphere.conf

configmap/cloud-config created

 

そして、GitHub にある YAML ファイルをもとにリソースを準備していきます。

 

ClusterRole・・・

[root@k8s-m-31 ~]# kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-roles.yaml

clusterrole.rbac.authorization.k8s.io/system:cloud-controller-manager created

 

RoleBinding、ClusterRoleBinding・・・

[root@k8s-m-31 ~]# kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-role-bindings.yaml

rolebinding.rbac.authorization.k8s.io/servicecatalog.k8s.io:apiserver-authentication-reader created

clusterrolebinding.rbac.authorization.k8s.io/system:cloud-controller-manager created

 

ServiceAccount、DaemonSet、Service・・・

[root@k8s-m-31 ~]# kubectl apply -f https://github.com/kubernetes/cloud-provider-vsphere/raw/master/manifests/controller-manager/vsphere-cloud-controller-manager-ds.yaml

serviceaccount/cloud-controller-manager created

daemonset.extensions/vsphere-cloud-controller-manager created

service/vsphere-cloud-controller-manager created

 

これで、下記のような Pod が起動された状態になります。

[root@k8s-m-31 ~]# kubectl get pods -n kube-system -l k8s-app=vsphere-cloud-controller-manager

NAME                                     READY   STATUS    RESTARTS   AGE

vsphere-cloud-controller-manager-275cj   1/1     Running   0          4m27s

 

各ノードでは、ProviderID が確認できるようになります。

[root@k8s-m-31 ~]# kubectl describe nodes | egrep "Name:|ProviderID:"

Name:               k8s-m-31

ProviderID:                  vsphere://42362f4f-d91b-4747-9d05-18c4b7287d65

Name:               k8s-w-31

ProviderID:                  vsphere://42362124-8759-dab1-e1c2-2478c6ac8450

Name:               k8s-w-32

ProviderID:                  vsphere://4236fbb9-2e70-1fc3-c87b-9dc574e80623

Name:               k8s-w-33

ProviderID:                  vsphere://4236e12c-841e-5b39-04a6-3e6b80cdc93e

 

また、Worker ノードの「NoSchedule」も解除されます。

[root@k8s-m-31 ~]# kubectl describe nodes | egrep "Name:|Taints:"

Name:               k8s-m-31

Taints:             node-role.kubernetes.io/master:NoSchedule

Name:               k8s-w-31

Taints:             <none>

Name:               k8s-w-32

Taints:             <none>

Name:               k8s-w-33

Taints:             <none>

 

CSI のセットアップ。

Container Storage Interface(CSI)Driver をデプロイします。

下記の3つのファイルを用意します。

  • csi-vsphere.conf ※環境に合わせて編集
  • csi-driver-rbac.yaml ※今回はドキュメントのまま
  • csi-driver-deploy.yaml ※今回はドキュメントのまま

参考ドキュメント: Install the vSphere Container Storage Interface Driver

 

csi-vsphere.conf ファイルに、vSphere 環境の情報を記載しておきます。

先ほどのファイルと同様、これは私の自宅ラボのものなので、適宜編集します。

[root@k8s-m-31 ~]# cat ./02_k8s-csi/csi-vsphere.conf

[Global]

cluster-id = "infra-cluster-01"

[VirtualCenter "infra-vc-01.go-lab.jp"]

insecure-flag = "true"

user = "administrator@vsphere.local"

password = "VMware1!"

port = "443"

datacenters = "infra-dc-01"

 

vCenter の情報をもつ secret を作成します。

[root@k8s-m-31 ~]# kubectl create secret generic vsphere-config-secret -n kube-system --from-file=./02_k8s-csi/csi-vsphere.conf

secret/vsphere-config-secret created

 

vSphere CSI Driver の依存コンポーネントを準備します。

[root@k8s-m-31 ~]# kubectl create -f ./02_k8s-csi/csi-driver-rbac.yaml

serviceaccount/vsphere-csi-controller created

clusterrole.rbac.authorization.k8s.io/vsphere-csi-controller-role created

clusterrolebinding.rbac.authorization.k8s.io/vsphere-csi-controller-binding created

 

vSphere CSI Driver をデプロイします。

[root@k8s-m-31 ~]# kubectl create -f ./02_k8s-csi/csi-driver-deploy.yaml

statefulset.apps/vsphere-csi-controller created

csidriver.storage.k8s.io/csi.vsphere.vmware.com created

daemonset.apps/vsphere-csi-node created

 

少し待つと、CSI Driver の Pod がすべて READY になります。

[root@k8s-m-31 ~]# kubectl get pods -n kube-system | egrep "^NAME|vsphere"

NAME                                     READY   STATUS    RESTARTS   AGE

vsphere-cloud-controller-manager-275cj   1/1     Running   0          37m

vsphere-csi-controller-0                 5/5     Running   0          2m49s

vsphere-csi-node-4s2df                   3/3     Running   0          2m49s

vsphere-csi-node-8sspf                   3/3     Running   0          2m49s

vsphere-csi-node-c68fq                   3/3     Running   0          2m49s

 

これで、Worker ノードが CSI Node として利用できる状態になります。

[root@k8s-m-31 ~]# kubectl get csinode

NAME       CREATED AT

k8s-w-31   2019-08-27T23:29:37Z

k8s-w-32   2019-08-27T23:29:30Z

k8s-w-33   2019-08-27T23:29:27Z

 

サンプル アプリケーションのデプロイ。

CSI Driver によるボリュームを使用する、ステートフル アプリケーションをデプロイします。

ここでは、MongoDB をデプロイしますが、これをそのまま何かに利用するということではなく、

ただボリューム(Kubernetes の PVC / PV)の様子を見るデモのために利用します・・・

参考ドキュメント: Deploy a Stateful Application

 

1. vSphere 側の準備。

vCenter で、「仮想マシン ストレージ ポリシー」を作成しておきます。

今回は、vSAN 環境にデフォルトで作成される「vSAN Default Storage Policy」を利用します。

vmw-cns-07.png

 

2. Kubernetes でのアプリケーションのデプロイ。

ここでは、下記のファイルを使用します。

今回のデモでは、これらのファイルも Ansible で Master ノードに配布しています。

[root@k8s-m-31 ~]# ls -1 ./03_demo/

mongodb-key.txt

mongodb-service.yaml

mongodb-statefulset.yaml

mongodb-storageclass.yaml

 

Kubernetes の StorageClass で、下記を指定します。

provisioner として「csi.vsphere.vmware.com」、

仮想マシン ストレージ ポリシー として「vSAN Default Storage Policy」を指定します。

[root@k8s-m-31 ~]# cat ./03_demo/mongodb-storageclass.yaml

---

kind: StorageClass

apiVersion: storage.k8s.io/v1

metadata:

  name: mongodb-sc

  annotations:

    storageclass.kubernetes.io/is-default-class: "false"

provisioner: csi.vsphere.vmware.com

parameters:

  storagepolicyname: "vSAN Default Storage Policy"

  fstype: ext4

 

StorageClass を作成します。

[root@k8s-m-31 ~]# kubectl create -f ./03_demo/mongodb-storageclass.yaml

storageclass.storage.k8s.io/mongodb-sc created

 

StorageClassが作成されました。

[root@k8s-m-31 ~]# kubectl get storageclass mongodb-sc

NAME         PROVISIONER              AGE

mongodb-sc   csi.vsphere.vmware.com   51s

 

Service を作成します。

[root@k8s-m-31 ~]# kubectl create -f ./03_demo/mongodb-service.yaml

service/mongodb-service created

 

Secret を作成します。

[root@k8s-m-31 ~]# openssl rand -base64 741 > ./03_demo/mongodb-key.txt

[root@k8s-m-31 ~]# kubectl create secret generic shared-bootstrap-data --from-file=internal-auth-mongodb-keyfile=./03_demo/mongodb-key.txt

secret/shared-bootstrap-data created

 

そして、StatefulSet を作成します。

[root@k8s-m-31 ~]# kubectl create -f ./03_demo/mongodb-statefulset.yaml

statefulset.apps/mongod created

 

3. vCenter の vSphere Client での確認。

vSphere Client では、クラスタを選択して、

監視 → クラウド ネイティブ ストレージ → コンテナ ボリューム を開くと、Kubernetes のボリュームが確認できます。

vmw-cns-01.png

 

アプリケーションのデプロイをまち、

Kubernetes 側で PersistentVolume(PV) / PersistentVolumeClaim(PVC) が作成されたことを確認します。

※表示例は横に長いので、スクリーンショットにしてあります。

[root@k8s-m-31 ~]# kubectl get pv

[root@k8s-m-31 ~]# kubectl get pvc

vmw-cns-08.png

 

vSphere Client でも、PV が表示されるようになります。

vmw-cns-03.png

 

PV の先頭のアイコンをクリックすると、「Kubernetes オブジェクト」タブで

関連する Kubernetes オブジェクトの情報が表示できます。

vmw-cns-04.png

 

「基本」タブでは、PV の配置された vSAN データストア、VMDK の仮想マシン ストレージポリシー、

PV が接続している VM など、vSphere 管理者の視点での情報が表示されます。

vmw-cns-05.png

 

PV は、vSAN の仮想ディスクとして作成され、VM に接続されています。

上記のコンテナ ボリューム画面で PV のボリューム名をクリックするか、

監視 → vSAN → 仮想オブジェクト の画面をひらくと、VM に PV が接続されている様子がわかります。

vmw-cns-06.png

 

実は以前から Kubernetes にボリュームを提供する機能(Project Hatchway と呼ばれていた)はあったのですが、

vSphere 6.7 u3 からは、今回の例のように vSphere Clinet から「クラウド ボリューム」として

Kubernetes でボリュームとして利用している VMDK が見やすくなりました。

 

以上、vSphere / vSAN 6.7 U3 の Cloud Native Storage でした。

NSX-T による DHCP サービス機能で、MAC アドレスと IP アドレスの静的な割り当て(static-bindings)を設定してみます。

前回の投稿では、NSX Manager の Web インターフェースから設定しました。

NSX-T 2.4 で DHCP の static-bindings を使用してみる。(GUI 編)

 

今回は、REST API から同様の設定をしてみます。

 

環境の説明。

以前の投稿と同様に、下記の環境を利用しています。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

REST API へのアクセスには、下記の投稿のように curl + jq コマンドを利用しています。

NSX-T 2.4 を REST API で操作してみる。Part.1

この投稿でのコマンドライン中にある $CRED には「ユーザ:パスワード」、

$MGR には NSX Manager のアドレスを格納しています。

 

IP アドレスを割り当てる MAC アドレスの確認。

DHCP の static-bindings では、MAC アドレスに IP アドレスを割り当てます。

今回は、NSX-T を利用している vSphere(ESXi)上の VM がもつ vNIC に IP アドレスを設定します。

そのため、NSX Manager からでも VM / vNIC とその MAC アドレスが確認できます。

nsxt-dhcp-bind-02.png

 

REST API では、この情報を virtual-machines と vifs の情報を GET することで確認できます。

今回は、例をシンプルにするため下記を前提としています。

  • 環境内の VM 名に重複がない。
  • VM の vNIC は 1つだけ。

 

VM の名前(vm01)から MAC アドレスを確認してみます。

vm01 の情報は、下記のように取得できます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/virtual-machines | jq -r '.results[] | select(.display_name == "vm01")'

{

  "host_id": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

  "source": {

    "target_id": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

    "target_display_name": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

    "target_type": "HostNode",

    "is_valid": true

  },

  "external_id": "501f7750-8d29-8c53-2d5e-e5b88b06f812",

  "power_state": "VM_RUNNING",

  "local_id_on_host": "1",

  "compute_ids": [

    "moIdOnHost:1",

    "hostLocalId:1",

    "locationId:564d7a4c-fa5e-33bf-1c3e-ca12ebd75f6f",

    "instanceUuid:501f7750-8d29-8c53-2d5e-e5b88b06f812",

    "externalId:501f7750-8d29-8c53-2d5e-e5b88b06f812",

    "biosUuid:421fa276-d1a6-c34a-2dc6-ea0de1d2ace5"

  ],

  "type": "REGULAR",

  "guest_info": {

    "os_name": "Oracle Linux 7 (64-bit)",

    "computer_name": "localhost.localdomain"

  },

  "resource_type": "VirtualMachine",

  "display_name": "vm01",

  "_last_sync_time": 1563839902208

}

 

ここから、下記のように VM の ID だけを取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/virtual-machines | jq -r '.results[] | select(.display_name == "vm01") | .external_id'

501f7750-8d29-8c53-2d5e-e5b88b06f812

 

そして、VM ID をもとに、vNIC の MAC アドレスを確認します。

※ちなみにこの VM は、前回の投稿で DHCP による IP アドレス / ホスト名が設定がされた状態です。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/vifs | jq -r '.results[] | select(.owner_vm_id == "501f7750-8d29-8c53-2d5e-e5b88b06f812")'

{

  "external_id": "501f7750-8d29-8c53-2d5e-e5b88b06f812-4000",

  "owner_vm_id": "501f7750-8d29-8c53-2d5e-e5b88b06f812",

  "host_id": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

  "vm_local_id_on_host": "1",

  "device_key": "4000",

  "device_name": "Network adapter 1",

  "mac_address": "00:50:56:9f:fa:ac",

  "lport_attachment_id": "5ccf3507-1001-419e-81be-3f197bf583f4",

  "ip_address_info": [

    {

      "source": "VM_TOOLS",

      "ip_addresses": [

        "172.16.1.101",

        "fe80::1b24:4d58:f0b4:bfe8"

      ]

    }

  ],

  "resource_type": "VirtualNetworkInterface",

  "display_name": "Network adapter 1",

  "_last_sync_time": 1563839902211

}

 

MAC アドレスだけを取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/vifs | jq -r '.results[] | select(.owner_vm_id == "501f7750-8d29-8c53-2d5e-e5b88b06f812") | .mac_address'

00:50:56:9f:fa:ac

 

DHCP static-bindings の設定。

IP アドレスの静的割り当て(static-bindings)は、NSX-T による DHCP サーバに対して設定します。

まず、DHCP サーバの ID を確認します。

今回も、DHCP サーバ名は「dhcp-sv-001」にしています。

$ DHCP_SV_ID=`curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers | jq -r '.results[] | select(.display_name=="dhcp-sv-001") | .id'`

$ echo $DHCP_SV_ID

73445136-5ab5-459a-a357-d736e534a467

 

静的割り当てのための JSON ファイル「dhcp-bind_vm01.json」を作成しておきます。

今回は、下記のパラメータのみ指定しています。

  • 表示名(display_name)
  • MAC アドレス ※必須
  • IP アドレス ※必須
  • ホスト名

JSON ファイルのパラメータは、前回の GUI での設定時と同じものです。

同じ静的割り当て設定が存在するとエラーになるので、

すでに設定がある場合は、NSX Manager などから削除しておきます。

$ cat ./dhcp-bind_vm01.json

{

  "display_name": "00:50:56:9f:fa:ac",

  "mac_address": "00:50:56:9f:fa:ac",

  "ip_address": "172.16.1.101",

  "host_name": "vm01"

}

 

作成した JSON ファイルを指定して POST メソッドを実行すると、DHCP の静的割り当てを作成できます。

curl を実行すると、作成された設定の情報が表示されます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-bind_vm01.json https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings

{

  "mac_address" : "00:50:56:9f:fa:ac",

  "ip_address" : "172.16.1.101",

  "host_name" : "vm01",

  "resource_type" : "DhcpStaticBinding",

  "id" : "bb2cd277-20f3-4184-81c5-250f20f71f7a",

  "display_name" : "00:50:56:9f:fa:ac",

  "lease_time" : 86400,

  "_create_user" : "admin",

  "_create_time" : 1564095298669,

  "_last_modified_user" : "admin",

  "_last_modified_time" : 1564095298669,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

 

これで、対象 MAC アドレスに IP アドレスが設定されるようになります。

 

DHCP static-bindings の削除。

一方、 静的割り当ての削除は、DELETE メソッドで実施できます。

 

静的割り当て設定の ID は、作成時にも表示されていましたが、

下記のように VM 名などから取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings | jq -r '.results[] | select(.host_name == "vm01") | .id'

bb2cd277-20f3-4184-81c5-250f20f71f7a

 

そして、削除は DELETE メソッドで削除できます。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings/bb2cd277-20f3-4184-81c5-250f20f71f7a

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings

{

  "results" : [ ],

  "result_count" : 0

}

 

うまく工夫をすると、NSX-T で IPAM(IP アドレス管理)を実現することもできそうかなと思います。

 

以上、NSX-T での DHCP static-bindings 設定でした。

NSX-T による DHCP サービス機能では、一般的な DHCP サーバと同様に

MAC アドレスと IP アドレスの静的な割り当て(static-bindings)が可能です。

 

ドキュメントだと、下記のあたりに説明がありますが、

あまり詳しくは触れられていないため、設定の様子を残しておこうと思います。

DHCP サーバの作成

 

環境の説明。

設定は、以前に紹介した環境を利用しています。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

そして、設定対象の NSX-T の DHCP サーバは、下記のように作成しています。

自宅ラボで NSX-T 2.4 環境を構築する。Part.10

 

設定対象の(VM の)MAC アドレスは、vSphere Client からだけではなく、

NSX Manager からでも確認できます。

「ネットワークとセキュリティの詳細設定」→「インベントリ」→「仮想マシン」を開くと、

VM と、その vNIC の MAC アドレスを確認することができます。

nsxt-dhcp-bind-02.png

 

今回の ゲスト OS(DHCP クライアント)は、Oracle Linux 7 です。

また、この時点ではホスト名をあらわす「コンピュータ名」が「localhost.localdomain」になっています。

※サマリにある「名前」は、ゲスト OS のホスト名ではなく、仮想マシン名です。

 

DHCP サーバ への IP アドレスの「静的割り当て」設定追加。

今回は、NSX の Manager で設定します。

 

「ネットワークとセキュリティの詳細設定」→「ネットワーク」→「DHCP」→「サーバ」を開きます。

DHCP サーバ「dhcp-sv-001」を作成ずみです。

サブネットマスク、デフォルトゲートウェイ、DNS サーバといった DHCP オプションは、

DHCP サーバで設定してあるので、静的割り当てでは、IP アドレスとホスト名を設定してみます。

 

「静的割り当て」にある「追加」をクリックします。

nsxt-dhcp-bind-01.png

 

静的割り当ての設定を入力して、「追加」ボタンをクリックします。

今回は、下記だけ追加入力しています。

  • IP アドレス: DHCP サービスで割り当てる IP アドレス。
  • MAC アドレス: 先ほど確認した vm01 のもの。
  • ホスト名: VM のゲスト OS に、DHCP で割り当てるホスト名。

ちなみに、赤い「*」印のあるもの(IP アドレスと MAC アドレス)が必須項目です。

nsxt-dhcp-bind-03.png

 

静的割り当ての設定が追加されました。

GUI からの操作では、表示名が MAC アドレスになります。

nsxt-dhcp-bind-04.png

 

DHCP によるアドレス設定の確認。

DHCP クライアントとなる VM では、指定した MAC アドレスを持つ vNIC のポートグループとして、

DHCP サーバを接続してある NSX-T 論理スイッチ(今回は ls-nsxt-001)を割り当てます。

※これは NSX Manager ではなく vSphere Client で設定します。

nsxt-dhcp-bind-05.png

 

ゲスト OS では、DHCP クライアントによるネットワーク設定のタイミングで、

静的割り当て設定した IP アドレスとホスト名が反映されるはずです。

 

Oracle Linux 7 では、Red Hat Enterprise Linux 7 や CentOS 7 と同様に

ネットワーク設定で NetworkManager が利用されています。

たとえば VM コンソールなどからアクセスして、

下記のように journalctl コマンドなどで NetworkManager のログから

DHCP によるネットワーク設定の様子を確認することができます。

nsxt-dhcp-bind-07.png

 

NSX Manager のインベントリでも、

vm01 の IP アドレスとホスト名が変更されたことが確認できます。

nsxt-dhcp-bind-08.png

 

この機能を利用することで、VM デプロイ時などに

IP アドレスを制御しやすくなりそうかなと思います。

 

つづくつもり・・・

今回は、NSX-T の REST API でオブジェクトを削除していきます。

 

これまでの投稿で、NSX-T のネットワークを REST API で作成してみました。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

このラボ環境の概要は下記をどうぞ。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

今回の削除対象も下記イメージ図の赤枠の部分です。

基本的に、これまで API で作成したオブジェクトを、作成時とは逆順に削除することになります。

NSX-T_Lab-2019_API-Part-06.png

 

削除対象オブジェクトの ID 確認。

API によるオブジェクトの削除では、オブジェクトの ID(UUID)を指定します。

そこで、おもな削除対象オブジェクトの ID を先に確認しておきます。

 

API の利用には、これまでの投稿と同様に curl / jq コマンドを利用しています。

変数「$CRED」では「ユーザ名:パスワード」、変数 $MGR には NSX Manager のアドレスを格納しています。

 

論理ルータ「t1-router-001」の UUID を取得します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.display_name == "t1-router-001") | .id'

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

論理スイッチ「ls-nsxt-001」の UUID を取得します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-switches | jq -r '.results[] | select(.display_name=="ls-nsxt-001") | .id'

639efb66-79aa-41f2-8c34-a32d4d74a8d5

 

DHCP サービスの削除。

 

DHCP サーバと論理スイッチを切断。

論理スイッチから、attachment_type が「DHCP_SERVICE」になっている論理ポートを確認します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-ports?logical_switch_id=639efb66-79aa-41f2-8c34-a32d4d74a8d5 | jq -r '.results[] | select(.attachment.attachment_type=="DHCP_SERVICE") | .id'

f5cd00bd-143c-4506-950c-9b43112d233a

 

論理スイッチから、論理ポートを削除します。

DHCP サーバを接続している論理ポートなので、一般的な論理ポート削除とは異なり「detach=true」を指定します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-ports/f5cd00bd-143c-4506-950c-9b43112d233a?detach=true

 

DHCP サーバの削除。

DHCP サーバ「dhcp-sv-001」の ID を確認します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers | jq -r '.results[] | select(.display_name=="dhcp-sv-001") | .id'

63ad4619-3749-438e-83e9-90265604174c

 

DHCP サーバを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/dhcp/servers/63ad4619-3749-438e-83e9-90265604174c

 

DHCP サーバ プロファイルの削除。

DHCP サーバ プロファイル「dhcp-prof-001」の ID を確認します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/server-profiles | jq -r '.results[] | select(.display_name=="dhcp-prof-001") | .id'

488512e2-d953-42ea-95c4-affe4b1dc063

 

DHCP サーバ プロファイルを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/dhcp/server-profiles/488512e2-d953-42ea-95c4-affe4b1dc063

 

オーバーレイ論理スイッチの削除。

論理スイッチを削除します。論理スイッチ ID は、冒頭で確認したものを指定します。

「cascade=true」で、論理スイッチに作成されている論理ポートを一緒に削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-switches/639efb66-79aa-41f2-8c34-a32d4d74a8d5?cascade=true

 

Tier-1 論理ルータの削除。

Tier-1 論理ルータは、論理ルータ ポートが残っていると削除することができません。

そこで、対象の論理ルータにポートが残っていないか確認してみます。

logical_router_id を指定することで、特定の論理ルータに作成されているポートを取得することができます。

論理ルータの ID は、冒頭で確認したものを指定しています。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports?logical_router_id=b8c1e482-a6d0-47eb-aca3-315abf738c8f | jq -r '.results[] | {display_name:.display_name, resource_type:.resource_type, logical_router_port_id:.id}'

{

  "display_name": "LinkedPort_t1-router-001",

  "resource_type": "LogicalRouterLinkPortOnTIER1",

  "logical_router_port_id": "d580e2fb-4c10-41ff-ae1d-af2d9bc5659d"

}

{

  "display_name": "t1-port-001",

  "resource_type": "LogicalRouterDownLinkPort",

  "logical_router_port_id": "2b708512-2fab-4fd2-bc83-4ed01d0569e9"

}

 

上記のように、ルータ ポートが残っている場合は、それぞれ削除しておきます。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-router-ports/d580e2fb-4c10-41ff-ae1d-af2d9bc5659d

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-router-ports/2b708512-2fab-4fd2-bc83-4ed01d0569e9

 

下記のように、論理ルータ ポートがゼロになっていることを確認することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports?logical_router_id=b8c1e482-a6d0-47eb-aca3-315abf738c8f | jq -r '.result_count'

0

 

論理ルータを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-routers/b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

Tier-0 ルータ側の論理ルータ ポートの削除。

Tier-1 論理ルータと Tier-0 論理ルータのリンクの、Tier-0 論理ルータ側の論理ポート

(resource_type は LogicalRouterLinkPortOnTIER0)も削除しておきます。

複数の Tier-1 論理ルータ ポートを作成している場合は、Tier-1 論理ルータ側のポートを削除する前に

対向のポート ID を確認しておくとよいと思います。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports | jq -r '.results[] | select (.resource_type=="LogicalRouterLinkPortOnTIER0") | {display_name:.display_name, logical_router_id:.logical_router_id, logical_router_port_id:.id}'

{

  "display_name": "LinkedPort_t1-router-001",

  "logical_router_id": "64f51cf0-bdf8-49d2-8a51-309b97b6ab40",

  "logical_router_port_id": "722849ae-a48a-4684-99e1-d7e06dcc0a23"

}

 

論理ルータ ポートを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-routers/722849ae-a48a-4684-99e1-d7e06dcc0a23

 

API の動作確認やツール開発では、何度も環境を初期化する需要があるはずなので、

このような DELETE メソッドによるオブジェクト削除の自動化ができるようにしておくと便利かなと思います。

 

以上、NSX-T の REST API でひたすらオブジェクト作成する話でした。

NSX-T を REST API で操作してみます。

今回は、ラボで構成したルーティング/SNAT設定について API で追加設定してみます。

新規作成した Tier-1 論理ルータでのアドバタイズメント設定変更、

そして、Tier-0 論理ルータへのデフォルトルートと SNAT ルールの追加をします。

 

前回はこちら。

NSX-T 2.4 を REST API で操作してみる。Part.4

 

一連の投稿の前提/想定環境などは下記をどうぞ。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

この投稿は、以前の下記投稿の API 版です。

自宅ラボで NSX-T 2.4 環境を構築する。Part.11

 

論理ルータ ID の取得。

今回の設定追加では、Tier-0/Tier-1 論理ルータ ID が必要になります。

論理ルータ ID の取得例はこれまでの投稿でも紹介しましたが、

下記のように NSX Manater の Web UI での表示名(display_name)と ID を一覧することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | {"LR_Name": .display_name, "ID": .id}'

{

  "LR_Name": "t0-router-01",

  "ID": "64f51cf0-bdf8-49d2-8a51-309b97b6ab40"

}

{

  "LR_Name": "t1-router-001",

  "ID": "b8c1e482-a6d0-47eb-aca3-315abf738c8f"

}

 

今回は、URI の一部としてルータ ID を指定したいので、変数に格納しておきます。

たとえば、下記のようなコマンドラインでもルータ ID を取得できます。

 

Tier-0 論理ルータの ID です。

$ T0_LR_ID=`curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.router_type=="TIER0" and .display_name=="t0-router-01") | .id'`

$ echo $T0_LR_ID

64f51cf0-bdf8-49d2-8a51-309b97b6ab40

 

Tier-1 論理ルータの ID です。

$ T1_LR_ID=`curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.router_type=="TIER1" and .display_name=="t1-router-001") | .id'`

$ echo $T1_LR_ID

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

Tier-1 論理ルータのアドバタイズメント設定変更。

API で新規作成した Tier-1 論理ルータの、ルート アドバタイズメントの有効化と、

 

念のため、現在のアドバタイズメント設定の _revision を確認しておきます。

「$T1_LR_ID」には、前の手順で取得した論理ルータ ID が含まれています。

数値がゼロ以外の場合は、JSON ファイルでもその値にあわせます。

 

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers/$T1_LR_ID/routing/advertisement | jq -r '._revision'

0

 

JSON ファイルを作成します。

今回は、アドバタイズの状態と、「すべての接続ルートをアドバタイズ」にあたる

advertise_nsx_connected_routes を有効にします。

 

t1-adv-rule.json

{

  "resource_type" : "AdvertisementConfig",

  "enabled" : true,

  "advertise_nsx_connected_routes" : true,

  "_revision" : 0

}

 

そして、アドバタイズを設定変更します。

$ curl -ks -u $CRED -X PUT -H "Content-type: application/json" -d @./t1-adv-rule.json https://$MGR/api/v1/logical-routers/$T1_LR_ID/routing/advertisement

 

Tier-0 論理ルータへのスタティック ルート追加。

NSX-T のラボ環境で必須というわけではありませんが、Tier-0 ルータへのスタティック ルートを追加します。

 

下記のような、ルーティング情報の JSON ファイルを作成します。

デフォルト ルートとして、「"network": "0.0.0.0/0"」宛のネクスト ホップとして、192.168.1.46 を指定しています。

※宛先の IP アドレスは、前提環境としてNSX-T ネットワークの外部に用意してあるゲートウェイです。

 

t0-default-route-01.json

{

  "display_name": "t0-default-route-01",

  "network": "0.0.0.0/0",

  "next_hops": [

    {

      "ip_address": "192.168.1.1",

      "administrative_distance": 1

    }

  ]

}

 

下記のようなコマンドラインで、スタティックルートを追加できます。

「$T0_LR_ID」には、前の手順で取得した論理ルータ ID が含まれています。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t0-default-route-01.json https://$MGR/api/v1/logical-routers/$T0_LR_ID/routing/static-routes

 

Tier-0 ルータへの SNAT ルール追加。

これも必須ではありませんが、Tier-0 論理ルータへの SNAT ルールを追加しておきます。

SNAT ルールは Tier-0/Tier-1 どちらでも設定できますが、

今回はこの環境のネットワーク構成にあわせて Tier-0 ルータで設定します。

 

今回は、172.16.1.0/24 からのソース アドレスを 192.168.1.46 に変換します。

ルール適用するポートは、論理ルータ ポート ID で指定します。

 

Tier-0 論理ルータ ポートは、下記のように情報取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports?logical_router_id=$T0_LR_ID

 

下記のような JSON ファイルを用意します。

applied_tos には、適用先の Tier-0 論理ルータ ポートの情報を指定しています。

 

t0-nat-rule-01.json

{

  "action": "SNAT",

  "match_source_network": "172.16.1.0/24",

  "translated_network": "192.168.1.46",

  "enabled": true,

  "applied_tos": [

    {

      "target_id": "ルール適用先の Tier-0 論理ルータ ポート ID",

      "target_display_name": "t0-uplink-port",

      "target_type": "LogicalRouterPort",

      "is_valid": true

    }

  ]

}

 

そして、下記のようなコマンドラインで SNAT ルールを追加します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t0-nat-rule-01.json https://$MGR/api/v1/logical-routers/$T0_LR_ID/nat/rules

 

これで API を利用して、以前に構築した NSX-T のテナントネットワークと同様のラボ環境ができました。

ID の取得や JSON ファイルの生成なども含めて、一連の手順をスクリプトにしておくと、

複数環境の構成を自動化したりできるかなと思います。

 

以上、NSX-T 2.4 を API で操作してみる話でした。

NSX-T を REST API で操作してみます。

今回は NSX-T による DHCP サーバを作成して、オーバーレイ論理スイッチに接続します。

 

一連の投稿の前提/想定環境などは下記をどうぞ。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

前回はこちら。

NSX-T 2.4 を REST API で操作してみる。Part.3

 

この投稿は、以前の下記投稿の API 版です。

自宅ラボで NSX-T 2.4 環境を構築する。Part.10

 

NSX-T の DHCP サーバ作成は、下記のような流れです。

  • サーバ プロファイルの作成
  • DHCP サーバの作成
  • DHCP サーバへの IP アドレス プールの作成
  • DHCP サーバを論理スイッチに接続

 

DHCP サーバ プロファイルの作成。

まず、サーバ プロファイルの定義を記載した JSON ファイルを作成します。

NSX Edge クラスタ ID が必要なので、前回まで内容をもとに ID を確認して、

JSON ファイルを完成させます。

 

下記のような JSON を作成します。

 

dhcp-prof-N.json

{

  "display_name": "DHCP プロファイル名",

  "edge_cluster_id": "Edge クラスタ ID"

}

 

DHCP サーバ プロファイルを作成します。

コマンドライン末尾の jq コマンドにより、作成された サーバ プロファイルの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-prof-N.json https://$MGR/api/v1/dhcp/server-profiles | jq -r '.id'

 

DHCP サーバの作成。

JSON ファイルを作成します。おもに赤字部分を、ネットワーク環境にあわせます。

dhcp_server_ip には、未使用の IP アドレスを指定します。

gateway_ip には、DHCP サービスを利用する論理スイッチを接続した

論理ルータ ポートの IP アドレスを指定します。

 

DNS や ドメイン名の設定といった、DHCP オプションも指定できます。

 

dhcp-sv-N.json

{

  "display_name": "DHCP サーバ名",

  "dhcp_profile_id": "DHCP サーバ プロファイルの ID",

  "ipv4_dhcp_server": {

    "dhcp_server_ip": "172.16.1.2/24",

    "dns_nameservers": [

      "192.168.1.101",

      "192.168.1.102"

    ],

    "domain_name": "go-lab.jp",

    "gateway_ip": "172.16.1.1"

  }

}

 

DHCP サーバを作成します。

ここでも、作成した DHCP サーバの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-sv-N.json https://$MGR/api/v1/dhcp/servers | jq -r '.id'

 

DHCP の IP プールの作成。

DHCP サーバには、IP アドレス プールを作成します。

 

JSON ファイルを作成します。赤字の部分を、ネットワークにあわせて修正します。

ここでの gateway_ip は、論理スイッチを接続している Tier-1 論理ルータ ポートの IP アドレスを指定します。

 

dhcp-pool-N.json

{

  "display_name": "DHCP IP アドレス プール名",

  "gateway_ip": "172.16.1.1",

  "allocation_ranges": [

    {

      "start": "172.16.1.10",

      "end": "172.16.1.99"

    }

  ]

}

 

IP アドレス プールを作成します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-pool-N.json https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/ip-pools

 

論理スイッチへの DHCP サーバの接続。

作成した DHCP サーバを、論理スイッチに接続します。

対象の論理スイッチの ID が必要になるため、取得しておきます。

※論理スイッチ「ls-nsxt-001」は、前回に作成したものです。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-switches | jq -r '.results[] | select(.display_name == "ls-nsxt-001") | .id'

 

これまでの Tier-1/Tier-0 のリンクや、論理ルータ ポート作成とは異なり、

「"attachment_type" : "DHCP_SERVICE"」という DHCP 接続のための指定をします。

 

下記のような JSON ファイルを作成します。

 

dhcp-port-N.json

{

  "display_name": "DHCP サーバを接続する論理スイッチ ポートの名前",

  "logical_switch_id": "論理スイッチ ID",

  "attachment" : {

    "attachment_type" : "DHCP_SERVICE",

    "id" : "DHCP サーバの ID"

  },

  "admin_state": "UP"

}

 

では、DHCP サーバを論理スイッチに接続(ポートを作成)します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-port-N.json https://$MGR/api/v1/logical-ports

 

これで、論理スイッチに接続した VM で、DHCP サービスが利用可能になります。

ここまでの DHCP サービスの簡易的な設定確認には、

論理スイッチ に接続している VM などからの下記のようなものが考えられます。

  • 実際に VM で DHCP によるネットワーク設定がされるか?
  • VM から、DHCP サーバに指定した dhcp_server_ip への疎通確認などが可能か?

 

もうすこし続く。

NSX-T 2.4 を REST API で操作してみる。Part.5