Skip navigation
2019

今回は、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

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

今回はオーバーレイ ネットワークの作成として、

論理スイッチと、ゲートウェイになる Tier-1 論理ルータ ポートを作成します。

 

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

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

 

前回はこちら。

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

 

前提とする設計について。

サンプルをシンプルにするため、オブジェクト名やアドレスの規則を決めておきます。

「テナント番号」のような感じで、オーバーレイ ネットワーク番号(N)をもうけて、

それをオブジェクト名やアドレスに使用します。

 

これ以降の例では、下記のようにオブジェクト名/アドレスを採番しています。

  • オブジェクト名: ~-N(例: ls-nsxt-001)
  • ネットワークアドレス: 172.16.N.0/24(例: 172.16.1.0/24)
  • デフォルトゲートウェイ: 172.16.N.1(例: 172.16.1.1)

 

オーバーレイ 論理スイッチの作成。

論理スイッチを作成するための JSON ファイルを作成します。

オーバーレイ論理スイッチの作成には、オーバーレイ トランスポート ゾーンの ID が必要です。

※ここで指定するオーバーレイ トランスポート ゾーン「tz-overlay-01」は、前提として作成ずみのものです。

$ curl -ks -u $CRED -X GET  https://$MGR/api/v1/transport-zones | jq -r '.results[] | select(.transport_type=="OVERLAY" and .display_name=="tz-overlay-01") | .id'

4a51e97d-f991-407c-ab73-66820a117f70

 

JSON を作成します。赤字の部分は環境にあわせた値にします。

オーバーレイ トランスポート ゾーン ID は、この環境であれば、

「4a51e97d-f991-407c-ab73-66820a117f70」になります。

 

ls-nsxt-N.json

{

  "display_name": "オーバーレイ 論理スイッチの名前",

  "description": "",

  "transport_zone_id": "オーバーレイ トランスポート ゾーン ID",

  "admin_state": "UP",

  "replication_mode": "MTEP",

  "hybrid": false,

  "_revision": 0

}

 

論理スイッチを作成します。

作成と同時に、レスポンス情報から論理スイッチ ID を取得しておきます。

$ curl -ks -u $CRED -H "Content-type: application/json" -X POST -d @./ls-nsxt-N.json https://$MGR/api/v1/logical-switches | jq -r '.id'

144f4777-a514-4351-b88e-5f6a1f6877e5

 

論理スイッチ ポートの作成。

NSX Manager の Web UI から実施する場合は、論理ルータ ポートを作成すると、論理スイッチのポートも自動作成されます。

一方、API の場合は、手動で論理スイッチ ポートを作成しておく必要があります。

 

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

ここでは、先ほど作成した論理スイッチの ID が必要となります。

この環境であれば、論理スイッチ ID は「144f4777-a514-4351-b88e-5f6a1f6877e5」です。

 

ls-port-N.json

{

  "display_name": "論理スイッチ ポート名",

  "logical_switch_id": "オーバーレイ 論理スイッチ ID",

  "admin_state": "UP"

}

 

論理スイッチ ポートを作成します。

ここでも、作成した論理スイッチ ポートの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./ls-port-N.json https://$MGR/api/v1/logical-ports | jq -r '.id'

02c7afd1-20cf-4528-8de2-360534960cd6

 

Tier-1 論理ルータ ポートの作成。

論理スイッチを Tier-1 論理ルータに接続し、ゲートウェイとなる IP アドレスを設定します。

 

ここでは、先ほど作成した、論理スイッチ ポートの ID が必要になります。

さらに、Tier-1 論理スイッチの ID が必要となるため、取得しておきます。

※ここでの論理スイッチ名「t1-router-001」は、前回の投稿で作成したものを指定します。

$ 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'

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

t1-port-N.json

{

  "display_name": "論理ルータ ポートの名前",

  "resource_type": "LogicalRouterDownLinkPort",

  "linked_logical_switch_port_id": {

    "target_id": "オーバーレイ 論理スイッチ ポート ID"

  },

  "logical_router_id": "Tier-1 論理ルータ ID",

  "subnets": [

    {

      "ip_addresses": [

        "ゲートウェイの IP アドレス"

      ],

      "prefix_length": 24

    }

  ]

}

 

ここまでの情報により、ここまでの実行例であれば下記のように値を指定します。

  • logical_router_id: "b8c1e482-a6d0-47eb-aca3-315abf738c8f"
  • linked_logical_switch_port_id の target_id: "02c7afd1-20cf-4528-8de2-360534960cd6"
  • logical_router_id 配下の ip_addresses: "172.16.1.1"

 

それでは、JSON ファイルをもとに Tier-1 論理ルータ ポートを作成します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-port-N.json https://$MGR/api/v1/logical-router-ports

 

これで、オーバーレイ ネットワークとそのゲートウェイが作成されます。

今回作成した論理スイッチに VM を接続しネットワーク設定をすれば、

ping などで Tier-1 論理ルータ ポートに設定したアドレスへの疎通がとれるはずです。

 

ただ、今回作成した論理スイッチのネットワークには DHCP サーバがないため

VM には手動でのネットワーク設定が必要になります。

次回は、NSX-T による DHCP サーバを API で作成します。

 

つづく・・・

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

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

今回は、Tier-1 論理ルータの作成です。

 

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

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

 

以前に投稿した下記の、API 操作版です。

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

 

Tier-1 論理ルータの作成。

まず、Tier-1 論理ルータを作成するために、JSON ファイルを用意します。

その前提として、Tier-1 論理ルータを接続する NSX Edge クラスタ の ID を取得する必要があります。

オブジェクトの ID については、殆どのものが NSX Manager の Web UI からでも確認できます。

しかし、今回はあえて ID も API で取得してみます。

 

Edge クラスタ「edge-cluster-01」の ID を取得してみます。

なお、この Edge クラスタは、前提として作成ずみのものです。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/edge-clusters | jq -r '.results[] | select(.display_name == "edge-cluster-01") | .id'

7228228c-6d93-46be-bb7a-f5e367cf1390

 

ここで用意する JSON ファイルは、下記のような内容です。

赤字の部分は、環境固有の値となります。

※これ以降の JSON も含め、わかりやすいサンプルにするため、あえてオプション指定を少なくしています。

{

  "display_name": "Tier-1 論理ルータの名前",

  "router_type": "TIER1",

  "edge_cluster_id": "Edge クラスタ ID",

  "edge_cluster_member_indices": [

    0

  ],

  "high_availability_mode": "ACTIVE_STANDBY"

}

 

display_name と edge_cluster_id に、具体的な値を指定した JSON を作成しました。

 

t1-router-001.json

{

  "display_name": "t1-router-001",

  "router_type": "TIER1",

  "edge_cluster_id": "7228228c-6d93-46be-bb7a-f5e367cf1390",

  "edge_cluster_member_indices": [

    0

  ],

  "high_availability_mode": "ACTIVE_STANDBY"

}

 

それでは、論理ルータを作成します。

作成と同時に、レスポンス情報から作成された論理ルータの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-router-001.json https://$MGR/api/v1/logical-routers | jq -r '.id'

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

作成ずみの論理ルータの ID は、下記のように取得することもできます。

$ 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

 

Tier-0 論理ルータとの接続。

Tier-1 論理ルータを Tier-0 論理ルータを接続(リンク)させるために、

それぞれの論理ルータにポートを作成する必要があります。

 

Tier-0 論理ルータ側のルータ ポート作成。

まず、Tier-0 論理ルータ側でポートを作成します。

このとき、Tier-0 論理ルータのルータ ID が必要になります。

ここで指定する Tier-0 論理ルータ「t0-router-01」は、前提として作成ずみのものです。

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

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

 

オーバーレイ論理スイッチの論理ルータ ポート作成とは異なり、

resource_type には「LogicalRouterLinkPortOnTIER0」を指定します。

 

t1-router-001_t0-link-port.json

{

  "display_name": "作成する Tier-0 論理ルータ側のポート名",

  "resource_type": "LogicalRouterLinkPortOnTIER0",

  "logical_router_id": "Tier-0 論理ルータの ID"

}

 

それでは、ポートを作成します。

作成と同時に、レスポンス情報から作成されたポートの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-router-001_t0-link-port.json  https://$MGR/api/v1/logical-router-ports | jq -r '.id'

 

Tier-1 論理ルータ側のルータポート作成。

Tier-0 論理ルータ側のポートを作成した後に、Tier-1 論理ルータ側でポートを作成します。

こちらでは、下記のような指定をします。

  • logical_router_id には、この投稿の最初に作成した Tier-1 論理ルータのルータ ID を指定します。
  • resource_type では「LogicalRouterLinkPortOnTIER1」を指定します。
  • linked_logical_router_port_id では、ひとつ前の手順で作成した Tier-0 論理ルータのポート ID を指定します。

 

t1-router-001_t1-link-port.json

{

  "display_name": "作成する Tier-1 論理ルータ側のポート名",

  "resource_type": "LogicalRouterLinkPortOnTIER1",

  "logical_router_id": "Tier-1 論理ルータの ID",

  "edge_cluster_member_index": [

    0

  ],

  "linked_logical_router_port_id": {

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

    "target_type": "LogicalRouterLinkPortOnTIER0",

    "is_valid": true

  }

}

 

作成した JSON ファイルで、論理ルータ ポートを作成します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-router-001_t1-link-port.json https://$MGR/api/v1/logical-router-ports

 

これで、Tier-1 論理ルータが作成され、Tier-0 論理ルータと接続された状態になりました。

NSX Manager の Web UI でも、Tier-0 ルータが接続されたことが確認できます。

nsxt-api-p02-01.png

 

つづく。

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

NSX-T の特徴のひとつである、REST API での操作を試してみます。

REST API を利用する場合の主な目的は、作業の自動化だと思います。

そこで、ここではいわゆる「テナント」を複数作成するようなケースを想定して、

Tier-1 論理ルータの作成から、オーバーレイ ネットワークの作成を REST API で実行してみます。

 

今回の一連の投稿です。

NSX-T 2.4 を REST API で操作してみる。Part.1 (この投稿自身)

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

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

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

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

 

それでは、まず利用する環境/ツールについて説明します。

 

利用する環境について。

以前に投稿した、自宅 NSX-T ラボ環境を利用しています。

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

 

上記 URL にある「Part.9」から先の部分(Tier-1 ルータの作成から)を、REST API で構築してみます。

イメージ図の、赤枠の部分です。

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

 

NSX-T Data Center REST API について。

NSX-T Data Center REST API は、下記のサイトにドキュメントが公開されています。

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

 

NSX Manager が展開されている環境であれば、NSX Manager ログイン後の

「?」→「API ドキュメント」でも確認できます。

nsxt-api-p01-01.png

 

API Guide のドキュメントが参照できます。

nsxt-api-p01-02.png

 

利用するツールについて。

今回は、Linux OS を実行元としています。

root@photon-machine [ ~ ]# cat /etc/photon-release

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=5e45dc9

 

REST API にアクセスする場合に一般的に利用される下記のコマンドライン ツールを利用しています。

  • curl
  • jq

 

curl と jq は、yum / tdnf などでインストールしておきます。

VMware Photon OS 3.0 を利用する場合は、デフォルトでは jq がインストールされていないので、

下記のように tdnf コマンドでインストールしておきます。

# tdnf install -y jq

 

REST API へのアクセス方法について。

REST API へのアクセスには curl コマンドを使用しますが、OS root ユーザである必要はなく一般ユーザで実行可能です。

そこで、bash のプロンプトは「$」とだけ表記しています。

今回は、コマンドライン例の見ための都合により、ユーザ:パスワード を変数に格納しています。

※ちなみに例示のパスワードは VMware のデモ/ハンズオンなどで一般的に利用されるものです。

$ CRED='admin:VMware1!VMware1!'

 

また、NSX Manager のアドレスは、変数「MGR」に格納して、

コマンドラインでも「$MGR」と表記しています。

※これは、うちの自宅 NSX Manager (ローカル)のアドレスです。

$ MGR=lab-nsxt-mgr-01.go-lab.jp

 

curl コマンドによるアクセス確認として、NSX-T のバージョンを確認してみます。

NSX-T の REST API では、JSON 形式のデータを扱います。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/node/version

{

  "node_version": "2.4.1.0.0.13716579",

  "product_version": "2.4.1.0.0.13716575"

}

 

必要に応じて、jq コマンドで JSON をフィルタ/成形します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/node/version | jq -r '.product_version'

2.4.1.0.0.13716575

 

それでは、NSX-T 環境を API で操作していきます。

つづく!

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

PowerCLI 11.3 がリリースされて、

NSX-T の論理スイッチの情報取得が簡単になりました。

New Release: VMware PowerCLI 11.3.0 - VMware PowerCLI Blog - VMware Blogs

 

PowerCLI 11.3 では、Get-VirtualNetwork コマンドレットで

NSX-T 論理スイッチの情報が取得できるようになりました。

PowerCLI> gcm Get-VirtualNetwork | select Name,Version,Source | Format-List

 

Name    : Get-VirtualNetwork

Version : 11.3.0.13964826

Source  : VMware.VimAutomation.Core

 

 

NSX-T 論理スイッチの情報取得。

NSX-T 論理スイッチは、NetworkType が「Opaque」です。

ちなみに、標準仮想スイッチ(vSS)の標準ポートグループは「Network」、

下記にはありませんが分散仮想スイッチ(vDS)の分散ポートグループは「Distributed」になります。

※Connect-VIServer で vCenter に接続ずみです。

PowerCLI> Get-VirtualNetwork

 

Name                                               NetworkType

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

pg-nsxt-edge-vtep                                  Network

pg-nsxt-edge-vlan                                  Network

VM Network                                         Network

ls-nsxt-002                                        Opaque

ls-nsxt-001                                        Opaque

 

 

ここでの ls-nsxt-001、ls-nsxt-002 は vSphere Client から見ると通常のポートグループとは異なるアイコンで、

NSX-T の論理スイッチだとわかります。

 

ちなみに、これらの NSX-T 論理スイッチは、事前に NSX Manager で作成しておいたものです。

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

powercli-nsxt-ls-02.png

 

vNIC へのNSX-T 論理スイッチ割り当て。

VM の vNIC に論理スイッチを割り当てるには、「-NetworkName」で論理スイッチ名を指定します。

vSphere の vDS による分散ポートグループでは「-Portgroup」などで指定していましたが、

NSX-T の N-VDS による論理スイッチでは、vSS の標準ポートグループの場合と同じ

「-NetworkName」オプション指定で設定することになります。

 

標準ポートグループ「VM Network」が割り当てられている

VM「vm01」の vNIC「Network adapter 1」があります。

PowerCLI> Get-VM vm01 | Get-NetworkAdapter -Name "Network adapter 1" | select Parent,Name,NetworkName | Format-List

 

Parent      : vm01

Name        : Network adapter 1

NetworkName : VM Network

 

 

vNIC のポートグループの割り当てを、NSX-T 論理スイッチ「ls-nsxt-001」に変更してみます。

PowerCLI> Get-VM vm01 | Get-NetworkAdapter -Name "Network adapter 1" | Set-NetworkAdapter -NetworkName "ls-nsxt-001" -Confirm:$false

 

Name                 Type       NetworkName  MacAddress         WakeOnLan

                                                                  Enabled

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

Network adapter 1    Vmxnet3    ls-nsxt-001  00:50:56:9f:fa:ac       True

 

 

vSphere Client からみても、vNIC の「ネットワーク」設定が

論理スイッチに変更されたことが確認できます。

powercli-nsxt-ls-01.png

 

以上、NSX-T 論理スイッチを PowerCLI で変更してみる話でした。

自宅で手軽に NSX-T の機能を確認できるように、

ネステッド ESXi 環境を利用したラボを構築してみます。

一連の投稿のまとめです。

NSX-T_Lab-2019_setup_summary.png

 

はじめに、今回のラボ構成の方針と、全体のイメージを説明します。

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

 

ネスト環境の外側の vCenter / ESXi での設定について説明します。

VM 配置と、リソースの割り当てについて、ついでに DNS などの関連サーバの準備についても説明します。

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

 

ひきつづき、ネスト環境の外側の vCenter ESXi での設定のうち

物理~ネスト外側でのネットワークの準備について説明します。

ここでのポイントは、物理 ESXi での仮想スイッチとポートグループの設定です。

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

 

ここから、ネスト環境の内側の vCenter / ESXi の準備です。

おもに、仮想スイッチとポートグループの設定について説明します。

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

 

NSX-T の「ホスト トランスポート ノード」の設定をします。

ESXi に、NSX-T 独自の仮想スイッチである N-VDS を構成します。

ここで構成するのは 2種類ある N-VDS のうち「オーバーレイ N-VDS」の方です。

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

 

NSX Edge の VM を展開します。

「Edge トランスポート ノード」とよばれるもので、

Edge にもオーバーレイ N-VDS を構成します。

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

 

NSX Edge を「VLAN トランスポート ゾーン」に追加して、VLAN N-VDS を構成します。

NSX Edge は、オーバーレイ トランスポート ゾーンと、VLAN トランスポート ゾーンの

両方に追加されることになります。

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

 

NSX Edge による Tier-0 論理ルータを作成して、

オーバーレイ ネットワークへの入り口になるアップリンク ポートを作成します。

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

 

オーバーレイ ネットワークで分散ルーティングする、Tier-1 論理ルータを作成します。

そして、オーバーレイ ネットワーク(の論理スイッチ)を作成して、

Tier-1 論理ルータにゲートウェイになるポートを作成します。

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

 

NSX-T 環境内の VM むけに、DHCP サーバを用意します。

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

 

自宅での NSX-T 環境への経路のとりかたについて紹介します。

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

 

以上、NSX-T 自宅ラボ構築のまとめでした。

NSX-T の、ネステッド ESXi 環境を利用したラボを構築してみました。

今回は、これまでの補足としてラボへの経路の工夫ついて説明します。

 

前回はこちら。

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

 

一連の投稿のまとめはこちら。

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

 

作成した自宅ラボのネットワーク構成の概要について。

作成したラボの、ネットワーク構成の概要です。

NSX-T_Lab-2019_setup_Part11-1.png

 

ルーティング設定について。

今回のラボは、NSX-T 環境に入ってからの動作確認をしたかったので、

NSX-T への入り口の Tier-0 ルータのアップリンク(一般的には BGP などが利用されるはずの部分)ではルーティング プロトコルは特に使用せず

外部のネットワークにある「ラボを利用する端末」をスタティックルートで NSX-T のオーバーレイネットワークにむけてしまいます。

 

オーバーレイ ネットワークとの経路では、下記のような設定をしています。

  • オーバーレイ ネットワークの VM は、ゲスト OS のデフォルトゲートウェイを Tier-1 ルータ ポートにする。
  • Tier-1 ルータでは、接続したオーバーレイ 論理スイッチのネットワークを Tier-0 ルータにアドバタイズ。
  • Tier-0 ルータは、デフォルトルート(0.0.0.0/0)を、VLAN ネットワークのゲートウェイへ。
  • 「ラボを利用する端末」のスタティックルートは、オーバーレイ ネットワーク(172.16.0.0/16)を Tier-0 ルータのアップリンクへ。

NSX-T_Lab-2019_setup_Part11-2.png

 

Tier-0 ルータでのスタティックルート の設定は、

Tier-0 ルータを選択して「ルーティング」→「スタティック ルート」を開いて、

「追加」から実施します。

nsx-t-11-02.png

 

Tier-1 ルータでのアドバタイズの設定は、

Tier-1 ルータの「ルーティング」→「ルートのアドバタイズ」から設定します。

ここでは、「すべての接続ルートをアドバタイズ」を有効にします。

nsx-t-11-01.png

 

オーバーレイ ネットワーク VM むけの SNAT。

オーバーレイ ネットワークの VM が、外部ネットワークにアクセスしやすいように、Tier-0 ルータの SNAT を利用しています。

NSX-T_Lab-2019_setup_Part11-3.png

 

この SNAT は、Tier-0 ルータで、オーバーレイ ネットワークのレンジの IP アドレスに対して設定しています。

適用対象は、Tier-0 ルータのアップリンクです。

nsx-t-11-03.png

 

以上、NSX-T のラボ環境を作成する話でした。

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、論理スイッチに DHCP サーバを追加します。

 

前回はこちら。

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

 

まとめはこちら。

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

 

NSX-T での  DHCP サービスは、

DHCP プロファイル/DHCP サーバを作成してから、論理スイッチに接続して使用します。

NSX-T_Lab-2019_setup_Part10.png

 

論理スイッチに接続した VM のゲスト OS では、手動でネットワーク設定をすることもできますが、

ラボの利用をシンプルにするため、NSX-T の DHCP サービスを利用します。

 

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

まず、DHCP サーバ プロファイルを作成します。

NSX Manager の「ネットワークとセキュリティの詳細設定」→

「ネットワーク」→「DHCP」→「サーバプロファイル」の「追加」をクリックします。

nsxt-dhcp-01.png

 

サーバ プロファイルは、名前、Edge クラスタ、メンバー(Edge トランスポート ノード)を指定して、「追加」します。

nsxt-dhcp-02.png

 

サーバ プロファイルが作成されました。

nsxt-dhcp-03.png

 

DHCP サーバの作成。

DHCP サーバは、となりの「サーバ」タブにある「追加」から実施します。

DHCP サーバには、名前、IP アドレスとサブネットマスク、DHCP サーバ プロファイルを指定します。

それ以外の DHCP オプションは、ここ(DHCP サーバ)もしくは、後で IP アドレス プールで指定します。

 

ここでの DHCP サーバの IP アドレスは、未使用のアドレス(ルータ ポートや IP プールで使用しないもの)を指定します。

このアドレスは実際にサーバに付与されるので、DHCP サービスがうまく利用できない場合は、

同じ論理スイッチに接続した VM からサーバへの疎通確認ができるか確認してみるとよいと思います。

nsxt-dhcp-04.png

 

IP アドレス プールの追加。

作成した DHCP サーバに、IP アドレス プールを追加します。

nsxt-dhcp-06.png

 

IP アドレスプールは、名前、IP アドレス 範囲、デフォルト ゲートウェイを指定して、「追加」します。

IPアドレスの範囲は開始アドレスと終了アドレスをハイフン(-)でつなげて入力します。

IP アドレス プールでは、DHCP オプション(ドメイン名、DNS サーバのアドレスなど)も指定することができます。

nsxt-dhcp-07.png

 

DHCP サーバの論理スイッチへの接続。

DHCP サーバで、「論理スイッチに接続」を実施します。

nsxt-dhcp-08.png

 

作成ずみの論理スイッチを選択して、「接続」します。

これで、論理スイッチに接続した VM に DHCP サービスが提供されるようになります。

nsxt-dhcp-09.png

 

VM での DHCP 利用について。

VM 側では、ゲスト OS のネットワーク設定で DHCP 設定にしておくと、

DHCP サービスによって IP アドレスなどが設定されるようになります。

 

Linux ゲストであれば、ログファイルなどから DHCP によるネットワーク設定の様子がわかります。

nsxt-dhcp-11.png

 

あと1回つづくつもり。

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

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、オーバーレイ ネットワーク同士の分散ルーティングをする、Tier-1 論理ルータを追加します。

 

前回はこちら。

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

 

まとめはこちら。

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

 

下記の構成イメージの、赤枠の部分が、今回の対象です。

NSX-T_Lab-2019_setup_Part09.png

 

同じ論理スイッチに接続した VM は、論理スイッチの機能により L2 通信が可能となり、

Tier-1 ルータ ポートを作成することで、L3 通信が可能になります。

※ただし VM のゲスト OS でのルーティング(デフォルトゲートウェイ/スタティックルート)設定は必要です。

 

T1 ルータの作成。

Tier-1 の論理ルータは、NSX Manager の

「ネットワークとセキュリティの詳細設定」→「ファブリック」→「ルーター」→「ルーター」画面の、

「追加」→「Tier-1 ルーター」から実施します。

nsxt-t1-01.png

 

Tier-1 ルータの、名前、接続する Tier-0 ルータ、Edge クラスタ、Edge クラスタ メンバー

(Edge トランスポート ノード)を指定して、「追加」します。

nsxt-t1-02.png

 

オーバーレイ 論理スイッチの作成。

Tier-1 ルータのダウンリンク ポートに接続する、オーバーレイ 論理スイッチを作成します。

オーバーレイ 論理スイッチも、VLAN 論理スイッチと同様に NSX Manager の

「ネットワークとセキュリティの詳細設定」→「ファブリック」→「スイッチング」→「スイッチ」画面の、「追加」から実施します。

nsxt-ls-01.png

 

作成する論理スイッチの、名前と、オーバーレイ トランスポート ノードを指定して、「追加」します。

nsxt-ls-02.png

 

トラフィック タイプが「オーバーレイ」の論理スイッチが作成されました。

nsxt-ls-03.png

 

オーバーレイ 論理スイッチは、実はオーバーレイ トランスポート ゾーンを作成した時点で、L2 スイッチとして作成/利用可能でした。

ただし、オーバーレイ 論理スイッチのネットワーク同士でルーティングするには、

ゲートウェイとして Tier-1 ルータ ポートを作成することになります。

 

T1 ルータ ポートの作成。

「ネットワークとセキュリティの詳細設定」→「ファブリック」→「ルーター」→「ルーター」画面で、

作成された Tier-1 ルータの「設定」→「ルーター ポート」を開き、「追加」をクリックします。

nsxt-t1-11.png

 

ルータ ポートの、名前と、接続する論理スイッチを指定します。

タイプは「ダウンリンク」にしておきます。

論理スイッチ ポートの設定は、デフォルトのままで大丈夫です。

論理ルータでポートを作成すると、対応する論理スイッチ ポートもセットで作成されます。

nsxt-t1-12.png

 

画面をスクロールし、サブネットを「追加」します。

論理スイッチのゲートウェイとなる、IP アドレスとプリフィックス長

(サブネットマスクのビット数)を入力して、論理スイッチを「追加」します。

nsxt-t1-13.png

 

論理ルータのダウンリンク ポートが、作成されました。

nsxt-t1-14.png

 

このように、T1 ルータにポートを作成したオーバーレイ 論理スイッチ同士では、

分散ルーティングができるようになります。

※ゲスト OS でのデフォルト ゲートウェイは、T1 ルータ ポートの IP アドレスに設定します。

 

論理スイッチの VM への割り当て。

NSX-T の論理スイッチは ESXi でも利用できるようになっており、

vSphere Client から通常のポートグループと同様に選択/vNIC への割り当てができるようになっています。

nsxt-ls-05.png

 

あと少し続く。

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

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、NSX-T 外部/オーバーレイ ネットワークの境界になる、Tier-0 論理ルータを追加します。

 

前回はこちら。

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

 

まとめはこちら。

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

 

下記の構成イメージの、赤枠の部分が、今回の対象です。

NSX-T_Lab-2019_setup_Part08.png

 

VLAN 論理スイッチの作成。

VLAN 論理スイッチは、NSX Manager の「ネットワークとセキュリティの詳細設定」→

「ファブリック」→「スイッチング」→「スイッチ」画面の、「追加」から実施します。

nsxt-edge-uplink-01.png

 

論理スイッチの、名前、トランスポート ゾーン、VLAN ID を指定します。

ここのトランスポート ゾーンで、VLAN トランスポート ゾーンを選択する必要があります。

ここで指定する VLAN ID は、NSX Edge の管理ネットワークではなく、ルーターとして利用するアップリンクの VLAN です。

ただし、管理ネットワークと同じ VLAN ID も指定可能です。

※まちがえてオーバーレイ トランスポート ゾーンを選択した場合、論理スイッチは削除して再作成します。

nsxt-edge-uplink-02.png

 

VLAN 論理スイッチが作成されました。

「トラフィック タイプ」で VLAN ID が正しいことを確認しておきます。

nsxt-edge-uplink-03.png

 

Tier-0 ルータの作成。

Tier-0 の論理ルータは、NSX Manager の

「ネットワークとセキュリティの詳細設定」→「ファブリック」→「ルーター」→「ルーター」画面の、

「追加」→「Tier-0 ルーター」から実施します。

nsxt-edge-uplink-12.png

 

ルーターの名前と、Edge クラスタを指定します。

ラボでは Tier-0 ルーターでの SNAT も利用したいため、

高可用性モードは「アクティブ / スタンバイ」を指定しています。

 

「追加」でルーターが作成されます。

これは VM を展開するわけではなく、NSX Edge の内部にルータを作成します。

nsxt-edge-uplink-13.png

 

Tier-0 ルータのアップリンク ポートの作成。

作成された Tier-0 ルータの「設定」→「ルーター ポート」を開き、「追加」をクリックします。

nsxt-edge-uplink-15.png

 

ルーター ポートの、名前、トランスポート ノード、論理スイッチを指定します。

論理スイッチでは、さきほど作成した VLAN 論理スイッチを指定します。

タイプは「アップリンク」、オーバーレイ ネットワークの経路ではないので MTU は 1500 にしておきます。

nsxt-edge-uplink-17.png

 

IP アドレスと、プレフィックス長(サブネットマスクのビット数)を入力して、「追加」します。

nsxt-edge-uplink-18.png

 

同一ネットワーク セグメントからであれば、

作成したポートの IP アドレスへ ping などで疎通がとれるようになるはずです。

nsxt-edge-uplink-19.png

 

もうすこし続く・・・

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

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、前回の投稿で展開した NSX Edge に、VLAN のトランスポート ゾーン/N-VDS を追加します。

 

前回はこちら。

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

 

まとめはこちら。

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

 

VLAN トランスポート ゾーンの作成。

トランスポート ゾーンは、NSX Manager の

「システム」→「ファブリック」→「トランスポート ゾーン」画面の、「追加」から実施します。

※スクリーンショットでは、オーバーレイ トランスポート ゾーンだけ作成されています。

nsxt-vlan-tz-01.png

 

作成するトランスポート ゾーンと N-VDS の名前を入力します。

トラフィック タイプで「VLAN」を選択してから、「追加」します。

nsxt-vlan-tz-02.png

 

VLAN トランスポート ゾーンが作成されました。

nsxt-vlan-tz-03.png

 

VLAN トランスポート ゾーンへの NSX Edge 追加。

「システム」→「ファブリック」→「ノード」→「Edge トランスポート ノード」画面で Edge を選択し、

「概要」→「編集」から開始します。

nsxt-vlan-tz-13.png

 

作成した VLAN トランスポート ゾーンを、「選択済み」に移動して「保存」します。

nsxt-vlan-tz-15.png

 

「N-VDS の追加」で、N-VDS を選択します。

オーバーレイ トランスポート ゾーンと同様に、アップリンク プロファイルを新規作成します。

nsxt-vlan-tz-16.png

 

作成するプロファイルの名前を入力します。

nsxt-vlan-tz-17.png

 

アップリンクの名前は、Edge VM ではポートグループでのチーミングを設定するため、

オーバーレイ トランスポート ゾーンの時と同様に「アクティブ アップリンク」だけ入力し、

「スタンバイ アップリンク」は空欄にしています。

 

トランスポート VLAN、MTU は、VLAN トランスポート ゾーンの場合はデフォルト設定にしています。

※TEP の構成がなく、MTU は 1500 でも疎通が可能です。(ただ、実はデフォルトが 1600)

nsxt-vlan-tz-18.png

 

「Edge トランスポート ノードの編集」画面に戻ります。

もともと作成されていたオーバーレイ N-VDS「nvds-overlay-01」には、

アップリンクに「pg-nsxt-edge-vtep」というポートグループを割り当てています。

nsxt-vlan-uplink-06.png

 

追加作成する VLAN N-VDS「nvds-vlan-01」には、

アップリンクに「pg-nsxt-edge-vlan」というポートグループを割り当て、「保存」します。

nsxt-vlan-uplink-07.png

 

トランスポート ゾーンへ追加後の NSX Edge。

NSX Edge が、オーバーレイ トランスポート ゾーンだけでなく

VLAN トランスポート ゾーンにも追加されたことがわかります。

nsxt-vlan-tz-23.png

 

vSphere Client から NSX Edge VM の vNIC を確認すると、NSX Manager の設定によって、

オーバーレイ N-VDS で使用される vNIC(ネットワーク アダプタ 2)には、pg-nsxt-edge-vtep ポートグループ、

VLAN N-VDS で使用される vNIC(ネットワーク アダプタ 3)には、pg-nsxt-edge-vlan ポートグループが割り当てられました。

nsxt-edge-20.png

 

ちなみに、Edge VM で VLAN ID をうけるため、

物理 ESXi だけでなく、ネステッド ESXi 側の仮想スイッチでも対象 VLAN を通過させる必要があります。

今回は標準ポートグループを使用しており、

両方のポートグループで VLAN ID 4095 を設定しています。

nsxt-vlan-uplink-08.png

 

あわせて、ポートグループではセキュリティ設定を「承諾」にしています。

nsxt-vlan-uplink-09.png

 

まだまだ続く。

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

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、NSX Edge の VM を展開します。

 

前回はこちら。

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

 

まとめはこちら。

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

 

NSX Edge の VM は、そのゲスト OS 内部に N-VDS を構成する、

ESXi とは異なるトランスポート ノード(Edge トランスポート ノード)となります。

 

NSX Edge は、2種類の N-VDS をもちます。

  • オーバーレイ ネットワークを構成する「オーバーレイ N-VDS」
  • NSX-T 外部のネットワークと接続するアップリンクとなる「VLAN N-VDS」

NSX Edge の VM を展開する流れで Edge に両方の N-VDS を作成できますが、

今回はオーバーレイ N-VDS だけ作成し、あとで VLAN N-VDS を追加作成します。

 

下記の構成イメージの、赤枠の部分が、今回の対象です。

NSX-T_Lab-2019_setup_Part06.png

 

Edge トランスポート ノードの追加。

NSX Edge のデプロイは、NSX Manager の

「システム」→「ファブリック」→「ノード」→「Edge トランスポート ノード」画面にある、

「EDGE 仮想マシンの追加」から開始します。

今回のラボでは、リソースの都合上「Small」フォーム ファクタでデプロイします。

※ただし Small では制限があり、ロードバランサ機能が利用できなかったりします。

nsxt-edge-02.png

 

Edge のゲスト OS ユーザ admin/root のパスワードと、SSH ログイン可否を指定します。

本来であれば SSH ログインは許可しないほうが好ましいですが、

ラボでの動作確認では利便性のため許可しています。

nsxt-edge-06.png

 

vCenter インベントリでの、展開先を指定します。

「コンピュート マネージャ」は、事前登録した vCenter です。

クラスタも事前作成しておきますが、今回はESXi のホスト トランスポート ノードとは

別のクラスタを用意しています。

※ホスト トランスポート ノードのクラスタに Edge を展開することも可能です。

 

データストアは、ラボで vSphere HA の動作確認などをしないのであれば

ローカル データストアでも大丈夫です。

nsxt-edge-08.png

 

NSX Edge の管理インターフェースのネットワーク設定をします。

ここで設定する「管理 IP アドレス」は、Edge の 1つめの vNIC(ゲスト OS から見た eth0)に設定されます。

このインターフェースの vNIC は Edge の N-VDS には接続されず、一般的な Linux ゲスト OS と同様に使用されます。

そのため「管理インターフェース」には、特殊な設定をしない、一般的なポートグループが指定できます。

※vDS の分散ポートグループが使用できますが、今回は vSS の標準ポートグループを指定しています。

nsxt-edge-10.png

 

NSX-T のトランスポート ゾーン/N-VDS の設定です。

ここでは、ホスト トランスポート ゾーンをセットアップしたときに作成した

オーバーレイ トランスポート ゾーン/N-VDS を指定しています。

 

この画面は、アップリンクとなる VLAN トランスポート ゾーン/N-VDS も作成できますが、

今回は、あとから作成します。

 

ホスト トランスポート ゾーンのセットアップの際と同様に、

アップリンク プロファイルの指定が必要ですが、ESXi と Edge VM ではネットワーク構成が異なるため、

「アップリンク プロファイルの新規作成」を実施します。

nsxt-edge-12.png

 

アップリンク プロファイルの作成画面です。

プロファイルの名前と・・・

nsxt-edge-14.png

 

アップリンクの名前、トランスポート VLAN、MTU を指定します。

アップリンクの名前は、ESXi むけのプロファイルとはことなり「アクティブ アップリンク」のみ入力します。

これは、Edge VM のアップリンクは vNIC であり、冗長化する場合は ポートグループでのチーミングを設定するためです。

 

「トランスポート VLAN」は、Edge のオーバーレイ N-VDS の TEP に設定される VLAN ID です。

これは、ESXi の TEP の VLAN ID と揃えておきます。

 

オーバーレイ ネットワークのトンネルとなるため、MTU は 1500 ではなく 1600 に設定しておきます。

nsxt-edge-15.png

 

作成したアップリンク プロファイルを指定して、

IP アドレスの割り当て方法と、インターフェースのポートグループを指定します。

IP アドレスの割り当ては「IP アドレス プールを使用」を選択して、

IP アドレス プールは、ESXi の TEP 設定で指定したものと同じものを指定します。

 

「DPDK Fastpath インターフェイス」では、

TEP のオーバーレイ ネットワークが通るポートグループを指定します。

ここで指定するポートグループは、TEP と同様に MTU 1600 で、

TEP の VLAN ID が通過できるように VLAN ID 4095 または VLAN トランク設定にします。

 

ちなみに、Edge VM のポートグループは vCenter から変更できてしまいますが、

NSX Manager で Edge トランスポート ノードの設定を変更するたびに、ここでの設定に戻ってしまいます。

そのため、あとから Edge VM のポートグループを変更する場合は、

かならず NSX Manager の Edge トランスポート ノードで設定変更します。

nsxt-edge-16.png

 

「終了」して少し待つと、Edge が展開/起動されます。

ESXi のリソース不足などで展開失敗した場合は、デプロイされた Edge VM を手動起動することで完了できることもありますが、

基本的には、一度 Edge を削除して再展開したほうがよさそうです。

nsxt-edge-18.png

 

Edge クラスタ の作成。

NSX-T では、Edge トランスポート ノードは、Edge クラスタとして管理されます。

 

NSX クラスタは、NSX Manager の

「システム」→「ファブリック」→「ノード」→「Edge クラスタ」画面にある、

「追加」から作成します。

 

Edge クラスタの名前を入力し、展開ずみの Edge を「選択済み」に移動して、

「追加」をクリックします。

nsxt-edge-cluster-02.png

 

作成された Edge クラスタを選択して、「関連」→「トランスポート ノード」で

Edge トランスポート ノードが追加されたことが確認できます。

nsxt-edge-cluster-04.png

 

まだつづく。

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

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

NSX Manager 初回ログイン後の、トランスポート ノードの作成について紹介します。

 

トランスポート ノードとは、NSX-T 独自の仮想スイッチ「N-VDS」が構成されるノードです。

NSX-T のトランスポート ノードには、ESXi ホストと NSX Edge の 2種類がありますが、

ここでセットアップするのは、ESXi の「ホスト トランスポート ノード」です。

 

前回はこちら。

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

 

まとめはこちら。

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

 

今回の NSX Manager でのセットアップでは、

N-VDS を使用する ESXi に NSX-T のコンポーネントをインストールします。

そのため、事前に vCenter では下記の準備をしておきます。

  • オーバーレイ ネットワークを構成するホストのクラスタ作成
    • NSX-T コンポーネントのインストールは、クラスタ単位になります。
  • ESXi ホストの vCenter とクラスタへの登録

 

NSX Manager への初回ログイン。

NSX Manager の初回ログインの画面です。

「はじめに」で、vCenter との登録から ESXi をトランスポート ノードとしてセットアップするまでの手順を、流れに沿ってすすめらられます。

これ以降の手順を個別に実施することもできますが、今回は「はじめに」から手順をすすめます。

nsx-setup-01.png

 

「トランスポート ノードのセットアップ」を進めます。

nsx-setup-02.png

 

vCenter Server の登録。

「コンピュート マネージャの追加」で、vCenter を登録します。

nsx-setup-04.png

 

事前に準備してある vCenter の、アドレスや接続情報を入力します。

このとき SSL 証明書のサムプリントを空欄ですすめると、

vCenter 実機のサムプリントで問題ないか確認画面が表示されます。

nsx-setup-05.png

 

ESXi への NSX-T コンポーネントのインストール。

vCenter を登録すると、トランスポート ノードにする ESXi のクラスタを選択できます。

nsx-setup-08.png

 

選択したクラスタに NSX-T のコンポーネントをインストールしてよいか確認メッセージが表示されます。

nsx-setup-09.png

 

しばらく待つと、ESXi ホストが「NSX インストール済み」となります。

画面更新に時間がかかることがありますが、インストール進行中でも

あえて「前へ」「次へ」ボタンをクリックしてみると、インストール完了していることがあります。

nsx-setup-11.png

 

オーバーレイ トランスポート ゾーンとオーバーレイ N-VDS の作成。

「オーバーレイ トランスポート ゾーンの作成」をすすめます。

nsx-setup-12.png

 

「オーバーレイ トランスポート ゾーンの作成」で、

トランスポート ゾーンの名前と、N-VDS(オーバーレイ N-VDS)の名前を入力し、作成します。

nsx-setup-14.png

 

アップリンク プロファイルの作成と指定。

オーバーレイ N-VDS の「アップリンク プロファイルの作成」をします。

今回の構成では、オーバーレイ ネットワークのトンネル エンドポイント(TEP)で VLAN ID を設定するので、

アップリンク プロファイルの新規作成が必要です。

nsx-setup-15.png

 

今回のようにウィザード形式でトランスポート ノードをセットアップしない場合は、

あらかじめアップリンク プロフィルを作成しておきます。

 

アップリンク プロファイルは、名前と・・・

nsxt-setup-uplink-01.png

 

チーミング設定、トランスポート VLAN(TEP となる vmk ポートに設定する VLAN ID)、MTU を設定します。

チーミングの「アクティブ アップリンク」と「スタンバイ アップリンク」に入力する名前は、

あとで ESXi の物理 NIC(vmnic)を紐づけるために利用します。

nsxt-setup-uplink-02.png

 

作成したアップリンク プロファイルを指定して、次のステップで TEP の IP アドレスと、物理 NIC の割り当てをします。

 

オーバーレイ N-VDS の TEP アドレス/物理 NIC の指定。

ESXi は、オーバーレイ トランスポート ゾーンを、オーバーレイ N-VDS で構成します。

ここでは、N-VDS のトンネル エンドポイントとなる TEP の IP アドレスと、

オーバーレイ ネットワークの物理経路となる、物理 NIC を割り当てます。

 

IP アドレスの割り当てには、DHCP(デフォルト)か IP アドレス プールが利用できます。

IP アドレス プールを使用する場合、IP アドレス プールは、この画面から作成できます。

nsx-setup-22.png

 

IP アドレス プールには、名前、IP アドレス範囲、ネットワーク アドレス(CIDR)が必須です。

TEP が複数の L3 ネットワークで構成される場合は、ゲートウェイも入力します。

nsx-setup-23.png

 

作成した IP アドレス プールを指定します。

そして ESXi の物理 NIC に対して、先ほど作成したアップリンク プロファイル名で指定した

アップリンクの名前を割り当てます。

ちなみに、ESXi で未使用(仮想スイッチに未割り当て)の物理 NIC が 3つ以上ある場合は、

さらに vmnic3 以降も表示されます。その際は、使用する物理 NIC だけにアップリンク名を指定します。

nsx-setup-26.png

 

ESXi へのトランスポート ノードのセットアップを終了します。

nsx-setup-27.png

 

オーバーレイ トランスポート ゾーンと N-VDS の確認。

「システム」→「ファブリック」→「トランスポート ゾーン」で、

作成されたトランスポート ゾーンが確認できます。

nsx-setup-29.png

 

vSphere Client では、ESXi に N-VDS が作成され、物理 NIC が接続されたことがわかります。

nsx-setup-30.png

 

トランスポート ノードのアップリンク設定の変更。

ここまでで設定したオーバーレイ N-VDS の設定変更をしたい場合には、

vSphere Client ではなく、NSX Manager で、

トランスポート ノードのアップリンク ポリシーを設定変更します。

 

アップリンク ポリシーの設定変更。

「システム」→「ファブリック」→「プロファイル」→「アップリンク プロファイル」にて、

対象のプロファイルを選択して「編集」から設定変更します。

nsx-setup-31.png

 

ESXi へのアップリンク ポリシーの指定、物理 NIC 割り当ての変更。

「システム」→「ファブリック」→「ノード」→「ホスト トランスポート ノード」にて、

管理元で vCenter の名前を選択します。

そして、対象のノードを選択して「管理」→「編集」から設定変更します。

nsx-setup-32.png

 

つづく…

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

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、ネスト内側の ESXi でのネットワーク設定について紹介します。

 

前回はこちら。

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

 

まとめはこちら。

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

 

イメージ図のうち赤枠の部分が、今回の対象です。

ネステッド ESXi 側での、仮想スイッチとポートグループの構成について説明します。

NSX-T_Lab-2019_setup_Part04-1.png

 

このラボでは、下記の 2種類のネステッド ESXi ホストを用意します。

  • オーバーレイ ネットワークへの入り口になる ESXi ホスト(NSX Edge を搭載する)
  • 一般の VM むけの オーバーレイ ネットワークを利用する ESXi ホスト

この2種類のホストは 1台のホストにすることができますが、

今回はネットワーク構成を理解しやすいように、あえて独立させました。

それぞれの、ネットワーク構成を説明します。

 

オーバーレイ ネットワークへの入り口になる ESXi ホストの構成。

NSX-T によるオーバーレイ ネットワークへの入り口となる ESXi ホストでは、

NSX Edge の VM を稼働させます。

 

ESXi から見た pNIC は、3つ(vmnic0 ~ vmnic2)用意してあります。

これの実体はネステッド ESXi の vNIC です。

 

このホストは NSX-T のオーバーレイ ネットワークの入り口となりますが、

その役割は NSX Edge VM がもつため、ESXi には NSX-T 独自の仮想スイッチである N-VDS は構成されません。

 

vmnic0 の構成。

1つめの vmnic0 は、vSS(vSwitch0)に構成して下記の通信で利用しています。

  1. ESXi の vmk0 による管理通信
  2. NSX Edge への入り口(アップリンク)となる VLAN

 

ここでの NSX Edge のアップリンクは、NSX-T による仮想スイッチ(VLAN N-VDS)に接続されます。

VLAN N-VDS は Edge VM に構成されます。そして Edge VM のポートグループ割り当てによって経路が決まるので、

後述の vmnic0 / vmnic2 の経路とすることも可能ですが、

今回は「ためしに NIC を切断してみる」のような実験の利便性のため、vmnic0 経路にしています。

 

この pNIC に構成される仮想スイッチには VLAN だけが通るので

(オーバーレイ ネットワークは通らない)ので、

MTU は 1500 のままでも大丈夫です。

 

VLAN N-VDS では Edge VM の中で VLAN ID をうけるため、

Edge VM での VLAN N-VDS の vNIC に接続するポートグループは、前回の投稿にあるような

VLAN ID 4095(vDS であれば VLAN トランク)の設定をしておきます。

 

vmnic1 / vmnic2 の構成。

vmnic1 と vmnic2 は、どちらか片方、またはアクティブ/スタンバイの構成にして、

NSX-T によるオーバーレイ ネットワークで利用します。

ただし、このホストは NSX Edge がオーバーレイ ネットワークの終端となります。

つまり NSX Edge VM が トンネルのエンドポイント(TEP)をもちます。

また、ここでの vmnic のチーミングは、一般的なポートグループのチーミングポリシーで設定します。

 

この pNIC に構成される仮想スイッチには オーバーレイ ネットワークが通るので

MTU は 1600 などに拡張します。

 

今回の オーバーレイ N-VDS では TEP で VLAN ID をうけるため、

Edge VM での オーバーレイ N-VDS の vNIC に接続するポートグループも、

VLAN ID 4095(vDS であれば VLAN トランク)の設定をしておきます。

NSX-T_Lab-2019_setup_Part04-2.png

 

オーバーレイ ネットワークを利用する ESXi ホストの構成。

NSX-T によるオーバーレイ ネットワークを VM が利用するホストで、

ESXi には NSX-T 独自の仮想スイッチである N-VDS(オーバーレイ N-VDS)が構成されます。

ESXi ホスト同士や NSX Edge とは、オーバーレイ ネットワークを通すトンネルのエンドポイント(TEP)同士で通信をします。

 

ESXi から見た pNIC は、前述の ESXi ホストと同様に、3つ(vmnic0 ~ vmnic2)用意してあります。

 

vmnic0 の構成。

1つめの vmnic0 は、vSS(vSwitch0)を構成して、ESXi の vmk0 による管理通信で利用しています。

そのため、MTU は 1500 のままです。

 

vmnic1 / vmnic2 の構成。

vmnic1 と vmnic2 は、どちらか片方、またはアクティブ/スタンバイの構成にして、

NSX-T によるオーバーレイ ネットワーク(オーバーレイ N-VDS)で利用します。

 

先ほどのホストとは異なり、vmnic に設定は、NSX-T のアップリンク プロファイルで設定します。

そのため、ESXi では特に設定を実施せず、NSX-T のセットアップまで NIC を仮想スイッチでは未使用にしておきます。

 

(のちほど)アップリンク プロファイルでは、下記のような設定をすることになります。

  • NIC のチーミング
  • オーバーレイ ネットワークが通るので、MTU は 1600 などに設定。
  • オーバーレイ N-VDS の TEP での VLAN ID の設定。

NSX-T_Lab-2019_setup_Part04-3.png

 

つづく・・・

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

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、ネスト外側の ESXi でのネットワーク設定について紹介します。

 

前回の投稿はこちら。

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

 

まとめはこちら。

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

 

1回目投稿にあるイメージ図での赤枠の部分が、今回の対象です。

物理ネットワーク ~ 物理 NIC、物理 ESXi での仮想スイッチ/ポートグループの構成について説明します。

NSX-T_Lab-2019_setup_Part03.png

 

物理(外部)ネットワーク ~ 物理 NIC の構成について。

NSX-T 環境を構成する場合、ESXi では複数の物理 NIC を利用します。

しかし、今回のラボで NSX-T をインストールするホストはネステッド ESXi なので、

物理 ESXi 側では、物理 NIC が1つだけでも十分です。

(私の自宅ラボの物理マシンが 物理 NIC ポートが1つずつしかないという事情もあります。)

そこで、物理 ESXi では、1つの 1Gbps の物理 NIC(vmnic0)だけ利用しています。

nsxt-lab-pNW-02.png

 

ラボ環境では VLAN も利用するので、物理的なネットワーク スイッチのポートでも

トランクポートに設定して対象の VLAN ID が通過できるようにしておく必要があります。

(ただ一般家庭で利用しているようなスイッチング ハブであれば、デフォルトで通るかなとは思います。)

 

MTU は、オーバーレイ ネットワークを構成するためすこし大きめ(一般的な 1500 ではなく 1600 など)に

する必要があり、物理スイッチがでもそのサイズの MTU に対応しておく必要があります。

(ちなみに、これも一般家庭で利用しているようなスイッチング ハブであれば、デフォルトで満たしているはずです。)

物理 ESXi 側での MTU は仮想スイッチで設定することになります。

 

仮想スイッチの構成について。

物理 ESXi での仮想スイッチは、標準仮想スイッチ(vSS)/分散仮想スイッチ(vDS)のどちらでも構いません。

私のラボでは、物理 ESXi 6 台でのクラスタで vDS を利用しています。

nsxt-lab-pNW-01.png

 

NSX-T でのオーバーレイ ネットワークのために、

仮想スイッチでは MTU を拡張(1600 などに)しておきます。

仮想スイッチでの MTU 設定は、仮想ポート単位ではなく、スイッチ全体での設定です。

 

vDS の場合の MTU 設定

vDS の設定の場合は、vDS で 1回 MTU の設定を変更すれば、すべての ESXi に設定反映されます。

vDS の MTU は、下記のように vDS の「設定」→「プロパティ」画面で確認できます。

nsxt-lab-pNW-03.png

 

vSS の場合の MTU 設定

vSS の設定の場合は、それぞれの ESXi ホストの vSS(vSwtich0 など)で、MTU の設定を変更する必要があります。

vSS の MTU 設定は、ESXi ホストで仮想スイッチの「設定の表示」を開くと確認できます。

nsxt-lab-pNW-04a.png

nsxt-lab-pNW-04.png

 

ちなみに、ネステッド ESXi 側でも MTU 1600 に設定する部分がありますが、

物理 ESXi 側でその値以上に MTU を拡張する必要はありません。

仮想スイッチについては、ネスト(入れ子)にしているというより連結している構成となるので、

通常の物理ネットワーク スイッチを連結するときのように経路上の MTU を揃えておきます。

(外側 ESXi をより大きな MTU にするというわけではなく)

 

ポートグループの構成について。

ネスト環境では、ポートグループで VLAN とセキュリティ ポリシーの設定に工夫が必要です。

 

ちょっと古い投稿ですが、下記のような設定をします。

ネステッド ESXi で仮想スイッチ側 VLAN をためす。(VLAN4095 で VST)

 

1つめのポイントは、 VLAN の設定についてです。

ネスト環境でのネットワーク構成では、

できるだけ、物理 ESXi ではなくネステッド ESXi 側のネットワーク構成を

本来構成したいネットワーク(仮想スイッチ/ポートグループ/vNIC)の設定にすると扱いやすいかなと思います。

そこで、物理 ESXi 側の仮想スイッチでは VLAN をそのまま通して、ネステッド ESXi 側の仮想スイッチで VLAN を終端させます。

この設定は、物理 ESXi で vDS/vSS のどちらを利用しているかによって設定が異なります。

 

vSS を利用している場合は、トランクポートの設定ができないので、

VLAN ID 4095 を設定することで、

すべての VLAN ID をそのまま通過させてネステッド ESXi 側の仮想スイッチに渡します。

nsxt-lab-pNW-07.png

 

vDS を利用している場合、トランクポートの設定ができるので、

ネステッド ESXi で利用する VLAN ID の範囲をトランクで設定します。

逆に、vDS では VLAN ID 4095 が設定できないので、

すべての VLAN ID を通す場合は「0-4094」のように設定します。

nsxt-lab-pNW-05.png

 

2つめのポイントは、セキュリティの設定変更です。

ネステッド ESXi の環境では、ESXi VM 自身の vNIC(ネステッド ESXi での vmnic0 などにあたる)に設定される MAC アドレスと、

ネステッド ESXi 上の vmk ポートや vNIC とで MAC アドレスとが、不一致になります。

そのため、物理 ESXi 側の仮想スイッチではセキュリティ設定を緩和(「承諾」に変更)しておく必要があります。

この設定は、vDS / vSS どちらも共通で必要です。

(ただし vDS のほうがデフォルト値がセキュリティが高く設定されており、デフォルト値は異なります。)

なお、標準的にインストールした ESXi の vmk0 ポートは vmnic0 と MAC アドレスが一致するようになっており、

この設定をしなくても、ネステッド ESXi の vmk0 だけは通信ができてしまうはずです。

nsxt-lab-pNW-06.png

 

ちなみに、物理 ESXi に直接搭載する VCSA や NSX Manager の VM については

とくにネスト環境を意識することなく普通のポートグループを割り当てます。

 

続く。

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

NSX-T の機能を確認できるように、ネステッド ESXi 環境を利用したラボを構築してみます。

ネスト環境として土台になる、外側の vCenter での設定について紹介します。

ここでは、VM の配置と、リソース割り当てについて紹介します。

 

前回はこちら。

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

 

まとめはこちら。

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

 

前提となるサーバの準備。

まずは、DNS / NTP / NTP / vCenter(VCSA)を用意しておきます。

これらのサーバは、vSphere にとっては、NSX-T を利用するか、ネスト環境であるかどうか

にかかわらず必要であり、特にネスト特有ではない一般的な手順で構築します。

ポイントは、下記のあたりかなと思います。

  • DNS サーバには、NSX Manager の 正引き/逆引きの設定(A / PTR レコード)も登録しておきます。
  • 共有データストアにする NFS サーバを VM として用意する場合も、ここに配置しておきます。
  • VCSA は、最小(tiny)サイズでのデプロイでも NSX-T の動作確認は可能です。

nsxt-lab-base-01.png

 

NSX Manager デプロイのポイント。

NSX Manager をデプロイして、起動しておきます。

nsxt-lab-base-02.png

 

NSX-T 2.4 の NSX Manager には、従来の NSX Manager と Controller 機能が統合されました。

NSX Unified Appliance という OVA ファイル(ファイル名は nsx-unified-appliance-2.4.1.0.0.13716579.ova)をデプロイします。

NSX Manager および利用可能なアプライアンスのインストール

 

デプロイ時のポイントは下記かなと思います。

  • 「nsx-manager nsx-controller」というロールを選択しておきます。
  • 最小サイズは「Cloud Service Manager」むけのもので、NSX Manger のサービスが起動できなくなるので、16GB メモリ / 4 vCPU以上のサイズを選択しておきます。

nsxt-lab-base-11.png

 

また、NSX Manager の VM は vCPU / メモリ(vRAM)の割り当てが大きいので、

小規模のラボむけに、リソース予約をあえて解除してから VM を起動します。

nsxt-lab-base-12.png

 

ESXi VM 設定のポイント。

ネステッド ESXi にする、ESXi VM の設定についてです。

nsxt-lab-base-03.png

 

ESXi VM では、ネステッド ハイパーバイザ上で VM を起動するため、

vCPU で「ハードウェア仮想化」を有効化しておきます。

仮想スイッチとポートグループの設定には工夫が必要です。※次回紹介する予定です。

 

そして、ESXi は、普通のインストーラ ISO ファイルからインストールします。

nsxt-lab-base-13.png

 

次は、土台になる外側の vCenter での、ネットワーク設定における工夫について紹介します。

 

つづく!

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

NSX-T の機能を確認できるように、ネステッド ESXi 環境を利用したラボを構築してみます。

今回は、構築する NSX-T 環境の概要を紹介します。

 

一連の投稿のまとめはこちら。

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

 

今回のラボ構成の方針。

現時点で NSX-T に取り組む場合は、新技術のキャッチアップを目的とすることが多いかなと思います。

そこで、ソフトウェアはできるだけ新しいものを利用します。

  • NSX-T 2.4.1
  • vCenter Server 6.7 U2 / ESXi 6.7 U2

 

私の自宅ラボには高スペックなマシンがないので、VM 配置/リソース設定に工夫をしています。

  • 本当は手軽に物理マシン 1台でネスト環境を構成したいが、スペック不足のため複数台の物理 ESXi ホストを使用。
  • VCSA と NSX-T Manager などはリソース割り当てが大きいので、あえてネスト環境よりも外(NSX-T 環境の vCenter より外)に配置。
    • ただし実環境では、これらは NSX-T 環境の vCenter で管理することになるはずです。
  • 各 VM の構成/リソース割り当ては、推奨値以下のものもあり。
    • NSX Manager は VM のリソース予約を解除。そしてクラスタ構成ではなくシングル構成にする。
    • NSX Edge は最小のサイズ。
  • ネステッド ESXi でのメモリ節約のため、共有データストアは vSAN ではなく NFS にする。

NSX-T_Lab-2019_setup-VM.png

 

ネットワークまわりの構成は、ラボ目的での環境構築として意図的に下記のような構成としています。

作成するラボでは、主に操作感(GUI / API)、オーバーレイ ネットワーク、ファイアウォール機能を確認するつもりです。

  • NSX Edge は、あえてオーバーレイ ネットワークを構成するクラスタとは別のクラスタに配置。
    • これは、NSX Edge 専用のクラスタが必要、というわけではありません。
    • ESXi のトランスポート ノードと、Edge トランスポート ノードとで、搭載する側の ESXi の構成差異を見やすくするため。
  • Tier-0 ルータのアップリンク(オーバーレイ ネットワークへの入り口)は管理ネットワークと兼用。
    • NSX 特有のネットワークに入るまでの部分はシンプルにしたかったため。
  • Tier-0 ルータではルーティング プロトコルを利用せず、たんにスタティックルートで NSX のネットワークへ。
  • オーバーレイの TEP(VTEP)には VLAN ID を付与。
  • オーバーレイ ネットワークの、元 / 先 / それ以外、として 3ノードの ESXi を用意。
  • NFS データストアの接続は、NSX が構成するネットワークとは直接的に関係しないので、vmk0 の管理ネットワークを兼用。
  • オーバーレイ ネットワークで利用する pNIC ポート(ESXi VM の vNIC)はあえて複数構成。
    • アップリンク プロファイルを理解しやすいように複数本(vmnic1 + vmnic2 のような)で冗長化。

NSX-T_Lab-2019_setup_Part01.png

※そのうち物理 / 論理構成を分けて、アドレス例も入れてあらためて・・・

 

実際に構築する NSX-T ラボの様子。

まず、ラボ全体を管理する vCenter の vSphere Client(HTML5 Client)です。

vCenter 6.7 では、基本的にこの vSphere Client を利用します。

 

物理 ESXi ホストには、vCenter(VCSA)、NSX Manger、NFS サーバ、ESXi VM といったものが配置されます。

それぞれ、役割の想像がしやすそうな VM 名にしてみました。

ここでの「ESXi VM」とは VM に ESXi をインストールしたもの(ネステッド ESXi)で、

通常の ESXi と同様に VM を起動したり、vCenter から管理したりできます。

nsxt-lab-01-ext.png

 

そして次は、「ネステッド ESXi + NSX-T」環境を管理する vCenter の、vSphere Client です。

上記のスクリーンショットにある lab-esxi-~ という VM は、この vCenter に ESXi として登録してあります。

この環境では、すでに NSX-T との連携がされており、ESXi に「N-VDS」という

NSX-T ならではの特別な仮想スイッチが構成されています。

nsxt-lab-02-nested.png

 

最後に、NSX Manager の画面です。

これは、上記のスクリーンショットと同じ環境を NSX Manager から見たところです。

NSX for vSphere(NSX-V)では、vSphere Client から NSX の設定をしていましたが、

NSX-T では、NSX Manager が提供する別の UI から、NSX の設定をすることになります。

nsxt-lab-03-mgr.png

 

では、これから下記のような流れでポイントを紹介していこうと思います。

  • 土台になる、外側の物理 ESXi ホスト(の vCenter)での設定。
  • NSX-T と連携する vCenter(ネステッド ESXi を利用した環境)での設定。
  • NSX-T 環境のセットアップ。

 

つづく。

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

前回の投稿では、ESXi のインストールメディアの転送に TFTP を利用しました。

 

ESXi を PXE Boot でインストールしてみる。(dnsmasq)

https://communities.vmware.com/people/gowatana/blog/2019/05/30/esxi-pxe-tftp

 

今回は、ESXi のインストーラの転送を HTTP に変更してみます。

ドキュメントでは、下記のあたりです。

Web サーバを使用した ESXi インストーラの PXE ブート

 

今回の環境。

今回は、前回の投稿で作成した環境を構成変更します。

おもな差分は、赤字の部分です。

  • OS: Oracle Linux 7
  • DHCP / TFTP サーバ: OS 標準提供の dnsmasq RPM
  • syslinux ブートローダ: OS 標準提供の syslinux-tftpboot RPM
  • PXE Boot 対象マシンのファームウェア: BIOS
  • ESXi インストール メディア: HTTP サーバに配置。Apache HTTP Server(httpd)を利用

 

PXE 環境の構成変更。

前回の構成では、ブートローダファイル pxelinux.0 を使用していました。

一方 HTTP でのインストールイメージ転送では、HTTP に対応している gpxelinux.0 を利用します。

そこで、DHCP オプションで指定してるファイル名を変更します。

 

ちなみに、前回利用した  pxelinux.0 のままだと、

下記のように URL を指定した HTTP によるファイルの読み込みができないようです。

esxi-pxeboot-10.png

 

今回は dnsmasq の DHCP 機能を利用しているので、/etc/dnsmasq.conf ファイルを編集します。

  • 赤字部分が前回からの差分です。
  • gpxelinux.0 は、syslinux-tftpboot RPM に含まれています。
  • PXE のプロセスでは TFTP を利用するので、TFTP 関連の設定はそのまま残します。

(省略)

interface=ens33

dhcp-range=192.168.163.200,192.168.163.209,6h

dhcp-boot=gpxelinux.0

enable-tftp

tftp-root=/var/lib/tftpboot

 

dnsmasq のサービスを再起動しておきます。

[root@pxe01 ~]# systemctl restart dnsmasq

 

前回 ESXi の ISO イメージ ファイルの内容をコピーした

TFTP サーバの公開ディレクトリ /var/lib/tftpboot/ESXi67u2/ には、

ブートで必要な下記のファイル(boot.cfg と mboot.c32)を残します。

[root@pxe01 ~]# ls -l /var/lib/tftpboot/ESXi67u2/

合計 96

-r-xr-xr-x. 1 root root  2713  5月 31 07:34 boot.cfg

-r-xr-xr-x. 1 root root 93288  3月 27 13:47 mboot.c32

 

そして boot.cfg の prefix を編集します。

 

編集前(前回のファイル)

[root@pxe01 ~]# cat /var/lib/tftpboot/ESXi67u2/boot.cfg | head -n 4

bootstate=0

title=Loading ESXi installer

timeout=5

prefix=ESXi67u2

 

編集後

※「192.168.163.149」はESXi のインストーラを配置する HTTP サーバのアドレスです。

[root@pxe01 ~]# cat /var/lib/tftpboot/ESXi67u2/boot.cfg | head -n 4

bootstate=0

title=Loading ESXi installer

timeout=5

prefix=http://192.168.163.149/ESXi67u2

 

HTTP サーバの用意。

OS 標準提供の Apache HTTP Server の RPM をインストールして、起動します。

[root@pxe01 ~]# yum install -y httpd

[root@pxe01 ~]# systemctl start httpd

[root@pxe01 ~]# systemctl enable httpd

 

HTTP サーバが起動して、Test Page が参照(HTTP でダウンロード)できるようになります。

※Test Page は Web ブラウザからでも確認できます。

[root@pxe01 ~]# curl -s http://192.168.163.149/ | head -n 3

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

        <head>

                <title>Apache HTTP Server Test Page powered by Linux</title>

 

ESXi インストールメディアの配置。

HTTP サーバの公開ディレクトリ(デフォルトの /var/www/html)配下に

「ESXi67u2」というディレクトリを作成して、そこに ESXi の ISO ファイルの内容をコピーします。

[root@pxe01 ~]# mkdir /var/www/html/ESXi67u2

[root@pxe01 ~]# mount -o loop VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso /mnt

[root@pxe01 ~]# cp -pr /mnt/* /var/www/html/ESXi67u2/

 

配置したファイルに HTTP 経由でアクセスできることを確認しておきます。

※Web ブラウザからでも確認できます。

[root@pxe01 ~]# curl -s http://192.168.163.149/ESXi67u2/ | head -n 5

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<html>

<head>

  <title>Index of /ESXi67u2</title>

</head>

 

PXE Boot での ESXi インストーラ起動の様子。

PXE Boot のメニューで、ESXi インストーラを選択すると・・・

esxi-pxeboot-11.png

 

boot.cfg の prefix で指定したアドレスの HTTP サーバから

ファイルが読み込まれていることがわかります。

esxi-pxeboot-12.png

 

PXE Boot を利用するような環境では、RPM などの OS パッケージを配置したリポジトリ

(YUM サーバなど)を用意しているケースがあるかなと思います。

ESXi インストーラも HTTP サーバに配置することで、

PXE 環境と、OS & ESXi のリポジトリを分離して管理できそうです。

 

以上、ESXi インストーラを HTTP サーバに配置してみる話でした。