Skip navigation

NSX の Distributed Load Balancing(DLB)を試してみます。


概要は Part 1 をどうぞ。

NSX の分散ロードバランシング(DLB)を体験してみる。Part 1(準備編)


前回の投稿はこちらです。

NSX の分散ロードバランシング(DLB)を体験してみる。Part 4(動作確認)

 

今回は、設定した DLB の vNIC でのフィルタを、ESXi に SSH ログインして見てみます。

win8-01a と web-02a が配置されている、ESXi「esx-02a」 に SSH ログインしています。

 

DVFilter の情報を表示できる summarize-dvfilter コマンドを、FW ルール適用の前後で実行してみました。

VIP 構成(FW ルール適用)前の状態。summarize-dvfilter コマンドの抜粋です。

web-02a と win8-01a の情報が表示されています。

nsx-dlb-p5-01.png

 

そして、VIP 構成(FW ルール適用)後の状態です。

DLR クライアントになる win8-01a に、フィルタが追加されています。

nsx-dlb-p5-02.png

 

vsipioctl コマンドで、追加されたフィルタのルール設定を確認してみます。

DNAT rulees に、 下記の設定のルールが追加されています。

  • out protocol: tcp(HTTP Service)
  • from addrset: ip-securitygroup-10
  • to ip: 172.16.10.9
  • port: 80(HTTP Service)
  • dnat addrset: ip-securitygroup-11
  • round-robin

nsx-dlb-p5-03.png

 

よい確認方法がまだ見つけられませんが、

このフィルタで指定されているオブジェクトの ID をもとに、NSX API でオブジェクト名を見てみました。

(当然ですが)NSX Firewall で指定したものと一致するようです。

※ラボの vCenter(vcsa-01a)から、NSX Manager(192.168.110.15) にアクセスして情報取得しています。


securitygroup-10 の name

curl -k -s -u 'admin:VMware1!' https://192.168.110.15/api/2.0/services/securitygroup/scope/globalroot-0 | xmllint --xpath '//securitygroup[objectId="securitygroup-10"]/name' - | more

 

securitygroup-11 の name

curl -k -s -u 'admin:VMware1!' https://192.168.110.15/api/2.0/services/securitygroup/scope/globalroot-0 | xmllint --xpath '//securitygroup[objectId="securitygroup-11"]/name' - | more

 

ip-securitygroup-~ というオブジェクトは、NSX Firewall で指定したセキュリティ グ ループと対応しているようです。

nsx-dlb-p5-04.png

 

serviceprofile-1 は、名前だけに絞らず見てみました。

curl -k -s -u 'admin:VMware1!' https://192.168.110.15/api/4.0/firewall/globalroot-0/config | xmllint --xpath '//*[objectId="serviceprofile-1"]' - | xmllint --format -

 

「serviceprofile-1」は、NSX Firewall で指定した Service Profile 「DLB-Service」です。

nsx-dlb-p5-05.png

 

NSX の DLB を設定してみたところ、既存のものを例に出すと

なんとなく vNIC レイヤで設定できる iptables DNAT ルールのような印象を受けました。

現状の DLB では SSL オフロードや URL Rewrite などができないそうですが、

DC 内の East-West 通信での利用を想定している機能のようなので、

シンプルなルール設定で利用するとよさそうに思いました。


以上、NSX の DLB を試してみる話でした。

NSX の Distributed Load Balancing(DLB)を試してみます。


概要は Part 1 をどうぞ。

NSX の分散ロードバランシング(DLB)を体験してみる。Part 3(VIP 構成)

 

DLB クライアントになる VM からアクセス確認。


今回は、DLB クライアントとなる VM 「win8-01a」 の Webブラウザから、DLB の VIP にアクセスしてみます。

 

win8-01a に Remote Desktop Connection で接続します。

nsx-dlb-p4-01.png

 

CORP\Administrator ユーザで、HoL 共通のパスワードでログインできます。

nsx-dlb-p4-02.png

 

win8-01a の IE を開いて、リアル IP でそれぞれの Web サーバのページが表示されることを確認しておきます。

 

web-01a の 172.16.10.11 のページが表示できます。

nsx-dlb-p4-03.png

 

web-02a の 172.16.10.12 のページが表示できます。

nsx-dlb-p4-04.png

 

つづいて、DLB で設定した VIP である、172.16.10.9 にアクセスしてみます。

 

ちゃんと web-01a のページが表示されます。

nsx-dlb-p4-05.png

 

Roud-Robin で振り分けているので、

Web ページを開きなおすと、web-02a のページも表示されます。

※更新ボタンより、 IE を開きなおしたほうがよいかもしれません。

nsx-dlb-p4-06.png

 

East-West 通信(たとえば Web ~ App サーバ間など)むけの機能のようですが、

North-South 通信っぽい今回の構成(分散ルーティングもされていない)でも、いちおう動作しました。


まだつづく。

NSX の分散ロードバランシング(DLB)を体験してみる。Part 5(ESXi から見た DLB Filter)

NSX の Distributed Load Balancing(DLB)を試してみます。

 

概要は Part 1 をどうぞ。

NSX の分散ロードバランシング(DLB)を体験してみる。Part 1(準備編)

 

前回の投稿はこちらです。

NSX の分散ロードバランシング(DLB)を体験してみる。Part 2(DLB 有効化)

 

手順について。

 

今回は、DLB で使用する VIP を構成します。

DLB の VIP は、NSX Firewall のルールとして設定することになります。

  1. Service Instance への Service Profile 適用。
  2. NSX Firewall での Balance ルール設定。

 

今回の構成では、このような感じになります。

※Part 1 と同じ絵です。

nsx-dlb-img-02.png

 

1. Service Instance への Service Profile 適用。

 

Web Client の Network & Security →

Service Definitions → Services → NSX-DLB をダブルクリックで開きます。

nsx-dlb-p3-01.png

 

Service Instances → NSX-DLB-GlobalInstance → Related Objects を開きます。

Service Profile「DLB-Service」が選択された状態で、「Apply to Objects」ボタンをクリックします。

nsx-dlb-p3-02.png

 

Object Type で「Security Group」 を選択したあと、DLB-Client-SG を選択して「OK」 をクリックします。

※ちなみに、「Object Type」は下記から選択できます。

  • Distributed Port Group
  • Security Group
  • Logical Switch

nsx-dlb-p3-03.png

 

Service Instance「NSX-DLB-GlobalInstance」 の画面のまま、

Manage → Setting を開いて「Publish」をクリックします。

nsx-dlb-p3-04.png

 

2. NSX Firewall での Balance ルール設定。


NSX Firewall で、VIP を設定するためのルールを追加します。

Partner security services の Default セクションに、下記の Blanace ルールを追加します。

  • Name: VIP-Web
  • Source: DLB-Client-SG
  • Destination: Web-SG
  • Service: HTTP
  • Action: balance + DLB-Service

 

Web Client の Network & Security →

Firewall → Configuration → Partner security services を開きます。

※画面を広く使うため、左側の画面のピンを外しておきます。

nsx-dlb-p3-05.png

 

Default Section で、「+」ボタンをクリックします。

nsx-dlb-p3-06.png

 

FW ルールの各項目の編集ボタンをクリックして、設定していきます。

 

Name

  • Rule Name: VIP-Web

nsx-dlb-p3-07.png

 

Source

  • Security Group の DLB-Client-SG を選択。

nsx-dlb-p3-08.png

 

Destination

  • Security Group の Web-SG を選択。

nsx-dlb-p3-09.png


Service

  • Object Type で、Service を選択して、HTTP を選択。

nsx-dlb-p3-10.png

 

Action には、下記を設定します。

VIP(Virtual Server IP)は、Web サーバの IP レンジから使用されていないものを適当に選定しました。

  • Action: Blanace
  • RedirectTo: DLB-Service
  • Direction: Out
  • Log: Do not log
  • Virtual Server IP: 172.16.10.9

nsx-dlb-p3-11.png


ルール追加したら、「Publish Changes」で設定反映します。

nsx-dlb-p3-12.png

 

ルールが登録されて、Rule ID が採番されました。

nsx-dlb-p3-13.png

 

これで DLB が動作するようになりました。

 

つづく。

NSX の分散ロードバランシング(DLB)を体験してみる。Part 4(動作確認)

NSX の Distributed Load Balancing(DLB)を試してみます。

 

前回の投稿はこちらです。

NSX の分散ロードバランシング(DLB)を体験してみる。Part 1(準備編)

 

手順について。

 

今回は、NSX で DLB を有効化します。

  1. Service Definition の作成。
  2. Service Instance へのクラスタ追加。
  3. Service Profile の作成。

 

1. Service Definition の作成。

 

Service Definition「NSX-DLB」 を作成します。

この流れで、Service Manager、Service Instance というものも作成されます。

 

Web Client の Network & Security →

Service Definitions → Services を開いて、「+」 ボタンをクリックします。

nsx-dlb-p2-01.png

 

下記を指定して「Next」をクリックします。

  • Name: NSX-DLB
  • Service Manager: Create New Service Manager ※デフォルト
  • Deployment Mechanism: Host based vNIC

nsx-dlb-p2-02.png


Service Categories では Load Balancer を選択して、「Next」 をクリックします。

nsx-dlb-p2-03.png

 

Service Manager は、名前だけ入力して「Next」 をクリックします。

  • Name: DLB-Service-Manager

nsx-dlb-p2-04.png

 

のこりは、流れに従ってデフォルトのまま「Next」 をクリックします。

下記のようになるので、「Finish」 をクリックします。

nsx-dlb-p2-05.png

 

2. Service Instance へのクラスタ追加。

 

DLB を有効化するクラスタを指定します。

作成された「NSX-DLB」 をダブルクリックして開きます。

nsx-dlb-p2-06.png

 

Service Instances → NSX-DLB-GlobalInstance → Manage → Deployment を開いて、

「+」 ボタンをクリックします。

nsx-dlb-p2-07.png

 

DLB を有効化するクラスタ 「Compute Cluster A」 を選択して「OK」 をクリックします。

※現時点では、ここで選択できるのは 1クラスタだけのようです。

nsx-dlb-p2-08.png

 

クラスタが追加されました。

nsx-dlb-p2-09.png

 

3. Service Profile の作成。

 

Service Instance で、Service Profile を作成します。

Related Objects を開いて、「+」ボタンをクリックします。

nsx-dlb-p2-10.png

 

Service Profile の名前を入力して、「OK」 をクリックします。

  • Profile Name: DLB-Service

nsx-dlb-p2-11.png

 

つづく。

NSX の分散ロードバランシング(DLB)を体験してみる。Part 3(VIP 構成)

NSX の Distributed Load Balancing (DLB)を試してみます。

まだ Preview の機能なので商用環境(いわゆる本番環境)への適用はできませんが、

既に NSX-v 6.2 には機能が含まれていて使用することが可能です。

 

VMTN に公開されている Getting Started Guide を参考にしました。

NSX Distributed Load Balancing  - Getting Started Guide

 

今回も、VMware のハンズオンラボ 「HOL-SDC-1603 VMware NSX Introduction」 を使用しています。

 

VMware Hands-on Labs(HoL)

http://labs.hol.vmware.com/HOL/catalogs/

 

今回の構成について。


DLB により、Windows 8 の VM から Web サーバへのアクセスを分散してみます。

ちなみに、NSX の DLB では分散元となる VM の vNIC に設定したフィルタで分散しているようです。

 

今回は、下記のような構成にしています。

  • 分散元/先は、別のネットワークセグメントにしています。
  • 分散ルーティングは使用していません。

nsx-dlb-img-01.png


ESXi と VM は、下記を使用します。

  • DLB の分散元: win8-01a
  • DLB の分散先: web-01a、web-02a(2 VM)
  • DLB を有効にするクラスタ: Compute Cluster A
    • esx-01a、esx-02a が含まれる。
    • NSX はすべての ESXi で構成済み。※ラボのデフォルトの状態。

 

手順の流れ。

 

今回の手順の流れです。長くなるので、5回に分けて投稿します。

  1. HoL での準備 ★この投稿。
    1. VM の停止、移動
    2. セキュリティ グループの作成
  2. DLB 有効化 ★Part 2
    1. Service Definition の作成。
    2. Service Instance へのクラスタ追加。
    3. Service Profile の作成。
  3. VIP の構成(NSX FW のルール作成) ★Part 3
    1. Service Instance への Service Profile 適用。
    2. NSX Firewall での Balance ルール設定。
  4. DLB クライアントになる VM からアクセス確認。 ★Part 4
  5. DLB 元の ESXi の様子を見てみる。 ★Part 5

 

下記のようなイメージになると思います。今回固有の設定(名前など)は赤字にしています。

オレンジ色のセキュリティグループ(DLB-Client-SG)は同一のものです。

nsx-dlb-img-02.png

 

1-1. VM の停止、移動

 

まず、ラボの VM 配置を調整します。

DLB を1つのクラスタ内で検証したいため、Compute Cluster A に関係する VM を移動します。

  • web-03a は使用しないので、シャットダウンします。
  • web-02a と win8-01a を、vMotion で esx-02a に移動します。
  • app-01a と db-01a は、テストページの表示で必要なので起動したままにしておきます。

 

VM 配置は、下記のようになります。

 

ESXi: esx-01a

nsx-dlb-p1-01.png

 

ESXi: esx-02a

nsx-dlb-p1-02.png

 

 

1-2. セキュリティ グループの作成

 

今回の DLB 設定では、仮想サーバの VIP を設定する際にセキュリティ グループを使用します。

そこで、あらかじめ下記のセキュリティ グループ作成しておきます。

  • DLB 分散元: DLB-Client-SG
  • DLB 分散先: Web-SG

 

Web Client の Network & Security →

Service Composer → Security Groups を開いて、「New Security Group」 ボタンをクリックします。

nsx-dlb-p1-07.png

 

名前は、「DLB-Client-SG」 としておきます。

nsx-dlb-p1-08.png

 

「Select objects to include」 を開いて、Object Type で Virtual Machine を選択します。

web8-01a を選択して「Finish」 をクリックします。

nsx-dlb-p1-09.png

 

同様に、「Web-SG」というセキュリティ グループを作成します。

nsx-dlb-p1-10.png

 

このグループには、web-01a と web-02a を含めます。

nsx-dlb-p1-11.png

 

セキュリティ グループ「DLB-Client-SG」と「Web-SG」が作成されました。

nsx-dlb-p1-12.png

 

つづく。

NSX の分散ロードバランシング(DLB)を体験してみる。Part 2(DLB 有効化)

NSX Edge ロードバランサ(LB)を NSX API で設定変更してみます。

 

概要については、こちらをどうぞ。

NSX Edge LB の API 操作を体験してみる。Part 1(はじめに)

 

前回の投稿はこちらです。

NSX Edge LB の API 操作を体験してみる。Part 4(LB メンバのステータス確認)

 

手順について。

 

今回は、既存の NSX Edge に、NSX API で SSL 証明書作成~仮想サーバ設定をします。

既存の NSX Edge(Perimeter-Gateway)の設定変更をします。

  1. SSL証明書の生成
    1. CSR 作成
    2. 自己署名による証明書の作成
  2. アプリケーションプロファイルの作成
  3. バックエンド プールの作成とメンバの追加
  4. 仮想サーバの設定変更

 

設定対象になる NSX Edge の ID は edge-2 です。

nsxapi-lb-p5-01.png

 

1-1. SSL証明書の生成: CSR 作成

 

今回の SSL 設定では、NSX Edge で 自己署名の証明書を作成して使用します。

 

まず CSR (証明書の署名要求)を、下記の情報で作成します。

  • 共通名: web-app.corp.local
  • 組織名: web-app.corp.local
  • 組織単位: VMWorld
  • 地域: San Francisco
  • 状態(というか州): CA
  • 国: US


XML ファイル(csr-web-app.txt)を作成します。

cat <<EOF > csr-web-app.txt

<csr>

  <subject>

    <attribute>

      <key>CN</key>

      <value>web-app.corp.local</value>

    </attribute>

    <attribute>

      <key>O</key>

      <value>web-app.corp.local</value>

    </attribute>

    <attribute>

      <key>OU</key>

      <value>VMworld</value>

    </attribute>

    <attribute>

      <key>L</key>

      <value>San Francisco</value>

    </attribute>

    <attribute>

      <key>ST</key>

      <value>CA</value>

    </attribute>

    <attribute>

      <key>C</key>

      <value>US</value>

    </attribute>

  </subject>

  <algorithm>RSA</algorithm>

  <keySize>2048</keySize>

</csr>

EOF

 

XML ファイルを読み込んで、CSR を作成します。

cat csr-web-app.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/services/truststore/csr/edge-2

 

SSL 証明書の署名で指定するため、今回作成した CSR の ID を特定しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/truststore/csr/scope/edge-2 | xmllint --xpath '//csr[cn="web-app.corp.local"]/objectId' - | more

 

CSR の ID は、csr-5 でした。

nsxapi-lb-p5-02.png

 

ちなみに、この CSR の情報は、下記で表示することができます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/truststore/csr/csr-5 | xmllint --format -

 

1-2. SSL証明書の生成: 自己署名による証明書の作成

 

自己署名付き証明書を作成します。

先ほど作成した csr-5 を、有効期限 365日で署名します。

curl -k -s -u admin:VMware1! -X PUT https://192.168.110.15/api/2.0/services/truststore/csr/csr-5?noOfDays=365

 

証明書の情報は、下記のように確認することができます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/truststore/certificate/scope/edge-2 | xmllint --format -

 

後の手順で指定するため、作成した証明書の ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/truststore/certificate/scope/edge-2 | xmllint --xpath '//certificate[name="web-app.corp.local"]/objectId' - | more

 

certificate-11 として作成されたことがわかります。

nsxapi-lb-p5-03.png

 

Web Client でも、今回作成した CSR と SSL 証明書が表示されます。

nsxapi-lb-p5-04.png

 

2. アプリケーションプロファイルの作成

 

SSL 終端のためのアプリケーション プロファイルを作成します。

  • 名前: Web-SSL-Term-Profile-01
  • タイプ: HTTPS
  • サービス証明書: 証明書「web-app.corp.local」 → certificate-11

 

XML ファイル(app-prof-sslterm.txt)を作成します。

cat <<EOF > app-prof-sslterm.txt

<applicationProfile>

  <name>Web-SSL-Term-Profile-01</name>

  <insertXForwardedFor>false</insertXForwardedFor>

  <sslPassthrough>false</sslPassthrough>

  <template>HTTPS</template>

  <serverSslEnabled>false</serverSslEnabled>

  <clientSsl>

    <clientAuth>ignore</clientAuth>

    <serviceCertificate>certificate-11</serviceCertificate>

  </clientSsl>

</applicationProfile>

EOF

 

アプリケーション プロファイルを作成します。

cat app-prof-sslterm.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-2/loadbalancer/config/applicationprofiles

 

applicationProfile-2 として作成されました。

nsxapi-lb-p5-05.png

 

作成されたアプリケーション プロファイルの ID は、API でも確認できます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/loadbalancer/config/applicationprofiles | xmllint --xpath '//applicationProfile[name="Web-SSL-Term-Profile-01"]/applicationProfileId' - | more

nsxapi-lb-p5-05a.png

 

3. バックエンド プールの作成とメンバの追加

 

プールへのメンバーの追加前回と異なり、Edge から Web サーバへは 80番ポートを指定。

 

今回のプール設定です。

  • 名前: Web-Tier-Pool-02
  • モニタ: NONE のまま

 

メンバ1

  • 名前: web-01a
  • IP 172.16.10.11
  • ポート: 80
  • モニタ ポート: 80

 

メンバ2

  • 名前: web-02a
  • IP 172.16.10.12
  • ポート: 80
  • モニタ ポート: 80

 

XML ファイル(pool-web-tier-2.txt)を作成します。

cat <<EOF > pool-web-tier-2.txt

<pool>

  <name>Web-Tier-Pool-02</name>

  <description></description>

  <transparent>false</transparent>

  <algorithm>round-robin</algorithm>

  <member>

    <ipAddress>172.16.10.11</ipAddress>

    <weight>1</weight>

    <port>80</port>

    <name>web-01a</name>

    <monitorPort>80</monitorPort>

  </member>

  <member>

    <ipAddress>172.16.10.12</ipAddress>

    <weight>1</weight>

    <port>80</port>

    <name>web-02a</name>

    <monitorPort>80</monitorPort>

  </member>

</pool>

EOF

 

プールを作成します。

cat pool-web-tier-2.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-2/loadbalancer/config/pools

 

pool-2 としてプールが作成されました。Web Client ではこう見えます。

nsxapi-lb-p5-06.png

 

作成されたプールの ID は、API でも確認できます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/loadbalancer/config/pools | xmllint --xpath '//pool[name="Web-Tier-Pool-02"]/poolId' - | more

nsxapi-lb-p5-07.png

 

4. 仮想サーバの設定変更

 

今回は、既存の仮想サーバの設定を変更します。

 

仮想サーバ「Web-Tier-SSL-01」の ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/loadbalancer/config/virtualservers | xmllint --xpath '//virtualServer[name="Web-Tier-SSL-01"]/virtualServerId' - | more

 

設定対象の仮想サーバの ID は、virtualServer-1 です。

nsxapi-lb-p5-08.png

 

変更しない設定値は、もともとの値を指定しておきます。

  • 名前: Web-Tier-SSL-01 → virtualServer-1
  • IP アドレス: 192.168.100.4
  • プロトコル: HTTPS
  • ポート: 443
  • アプリケーション プロファイル: Web-SSL-Term-Profile-01 → applicationProfile-2 ★変更
  • デフォルト プール: Web-Tier-Pool-02 → pool-2 ★変更

 

XML ファイル(vs-web-tier-2.txt)を作成します。

cat <<EOF > vs-web-tier-2.txt

<virtualServer>

  <virtualServerId>virtualServer-1</virtualServerId>

  <name>Web-Tier-SSL-01</name>

  <enabled>true</enabled>

  <ipAddress>192.168.100.4</ipAddress>

  <protocol>https</protocol>

  <port>443</port>

  <connectionLimit>0</connectionLimit>

  <connectionRateLimit>0</connectionRateLimit>

  <applicationProfileId>applicationProfile-2</applicationProfileId>

  <defaultPoolId>pool-2</defaultPoolId>

  <enableServiceInsertion>false</enableServiceInsertion>

  <accelerationEnabled>false</accelerationEnabled>

</virtualServer>

EOF

 

XML ファイルを読み込んで、設定変更します。

cat vs-web-tier-2.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-2/loadbalancer/config/virtualservers/virtualServer-1

 

設定変更が反映されました。

nsxapi-lb-p5-09.png

 

これで、テストページ「SSL-Offload-Web-A...」の表示ができるようになります。

nsxapi-lb-p5-10.png

 

HoL のシナリオをもとにした単純な設定ですが、

このように NSX Edge のロードバランサを NSX API で設定するととができます。

 

以上、NSX API で NSX Edge LB を設定してみる話でした。

NSX Edge ロードバランサ(LB)を NSX API で設定変更してみます。


概要については、こちらをどうぞ。

NSX Edge LB の API 操作を体験してみる。Part 1(はじめに)


前回の投稿はこちらです。

NSX Edge LB の API 操作を体験してみる。Part 3(One-Arm LB の設定)


手順について。


今回は NSX API で、ここまでで構成した LB の、プールメンバのステータスを確認してみます。

  1. 正常な状態
  2. Web サービスの障害(HTTPD サービスの停止)
  3. Web サーバの障害(VM 停止)

 

1. 正常な状態


まず、LB のメンバの状態を NSX Edge のコンソールから確認してみます。

前回デプロイした OneArm-LoadBalancer という NSX Edge に、VM コンソールからアクセスしてみます。


admin ユーザでログインして、プールのステータスを確認します。

show service loadbalancer pool


プールのメンバが、それぞれ UP になっていることがわかります。

nsxapi-lb-p4-00.png

 

API で確認する場合は、LB の統計情報(statistics)を取得するとプール メンバの状態がわかります。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/statistics | xmllint --format -


コンソールでの確認と同様に、メンバがそれぞれ UP になっています。

nsxapi-lb-p4-01.png


情報量が多いので、API での情報取得結果からメンバの status だけ表示してみます。

 

web-01a

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/statistics | xmllint --xpath '//pool[name="Web-Tier-Pool-01"]/member[name="web-01a"]/status' - | more

 

web-02a

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/statistics | xmllint --xpath '//pool[name="Web-Tier-Pool-01"]/member[name="web-02a"]/status' - | more

 

このような感じになります。

nsxapi-lb-p4-02.png

 

2. Web サービスの障害

 

Web サーバ(web-01a)の Web サービス(httpd)を停止して、NSX API でステータスを見てみます。

今回は、web-01a にログインして「service httpd stop」コマンドで Web サービスを停止しました。

nsxapi-lb-p4-03.png

 

NSX Edge のコンソールで STATUS が DOWN になりました。

nsxapi-lb-p4-04.png

 

NSX API でも、同様に DOWN が検知されます。

障害検知の内容も、NSX Edge と同様に確認することができます。

nsxapi-lb-p4-05.png

 

3. Web サーバの障害

 

Web サーバ(web-01a)を、ゲスト OS ごとシャットダウンして、NSX API でステータスを見てみます。

web-01a にログインして「shutdown -h now」コマンドで Linux を停止しました。

nsxapi-lb-p4-06.png


NSX API でステータスを確認すると、ちゃんと状態の変化が反映されました。

nsxapi-lb-p4-07.png

 

Web サーバの状態を復旧すれば、すぐにステータスが UP に戻ります。

NSX Edge や Web Client から確認できる LB メンバのステータス情報も、このように NSX API から確認できます。

 

つづく。

NSX Edge LB の API 操作を体験してみる。Part 5(SSL オフロード)

NSX Edge ロードバランサ(LB)を NSX API で設定変更してみます。


概要については、こちらをどうぞ。

NSX Edge LB の API 操作を体験してみる。Part 1(はじめに)


前回の投稿はこちらです。

NSX Edge LB の API 操作を体験してみる。Part 2(NSX Edge のデプロイ)


手順について。


今回は、前回デプロイした NSX Edge LB の設定をします。

  1. LB の有効化
  2. アプリケーション プロファイルの作成
  3. LB モニタの設定変更
  4. バックエンド プールの作成とメンバの追加
  5. 仮想サーバの作成

 

1. LB の有効化


前回デプロイした NSX Edge(ID は edge-5)で LB を有効化します。

 

この時点では、まだ LB が無効な状態です。

nsxapi-lb-p3-01.png

 

XML ファイル(edge-onearm-lb-enable.txt)を作成します。

LB 有効化のため、loadBalancer 直下の enable 要素を true にします。

Edge Service Gateway としてデプロイされた NSX Edge にデフォルトで作成されている

LB モニタ(monitor-1 ~ monitor-3)は、XML ではデフォルトの値を指定しておきます。

cat <<EOF > edge-onearm-lb-enable.txt

<loadBalancer>

  <enabled>true</enabled>

  <monitor>

    <monitorId>monitor-1</monitorId>

    <type>tcp</type>

    <interval>5</interval>

    <timeout>15</timeout>

    <maxRetries>3</maxRetries>

    <name>default_tcp_monitor</name>

  </monitor>

  <monitor>

    <monitorId>monitor-2</monitorId>

    <type>http</type>

    <interval>5</interval>

    <timeout>15</timeout>

    <maxRetries>3</maxRetries>

    <method>GET</method>

    <url>/</url>

    <name>default_http_monitor</name>

  </monitor>

  <monitor>

    <monitorId>monitor-3</monitorId>

    <type>https</type>

    <interval>5</interval>

    <timeout>15</timeout>

    <maxRetries>3</maxRetries>

    <method>GET</method>

    <url>/</url>

    <name>default_https_monitor</name>

  </monitor>

</loadBalancer>

EOF

 

XML ファイルを読み込んで、NSX Edge 「edge-5」の LB 設定を有効にします。

cat edge-onearm-lb-enable.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/config

 

Web Client での確認でも、LB が有効な状態になりました。

nsxapi-lb-p3-02.png


2. アプリケーション プロファイルの作成

 

アプリケーション プロファイルを作成します。

  • 名前: OneArmWeb-01
  • タイプ: HTTPS
  • SSL パススルーの有効化

 

XML ファイル(app-prof.txt)を作成します。

cat <<EOF > app-prof.txt

  <applicationProfile>

  <name>OneArmWeb-01</name>

  <insertXForwardedFor>false</insertXForwardedFor>

  <sslPassthrough>true</sslPassthrough>

  <template>HTTPS</template>

  <serverSslEnabled>false</serverSslEnabled>

</applicationProfile>

EOF

 

XML ファイルを読み込んで、API でアプリケーション プロファイルを作成します。

cat app-prof.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/config/applicationprofiles

 

アプリケーション プロファイルが applicationProfile-1 として作成されました。

nsxapi-lb-p3-03.png

 

API でも、アプリケーション プロファイルを確認できます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/config/applicationprofiles | xmllint --format -

 

3. LB モニタの設定変更

 

ラボの環境にあわせて、サービス監視をする LB モニタの設定を変更します。


HTTPS モニタは default_https_monitor で、ID は monitor-3 です。

この時点では、モニタ対象の URL が「/」になっているので、ラボの環境に合わせて/cgi-bin/hol.cgi」に変更します。

nsxapi-lb-p3-04.png

 

XML ファイル(mon-https.txt)を作成します。

cat <<EOF > mon-https.txt

<monitor>

  <monitorId>monitor-3</monitorId>

  <type>https</type>

  <interval>5</interval>

  <timeout>15</timeout>

  <maxRetries>3</maxRetries>

  <method>GET</method>

  <url>/cgi-bin/hol.cgi</url>

  <name>default_https_monitor</name>

</monitor>

EOF

 

モニタを設定変更します。

cat mon-https.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/config/monitors/monitor-3

 

設定変更されました。

nsxapi-lb-p3-05.png

 

API でも確認できます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/config/monitors/monitor-3 | xmllint --format -

 

 

4. バックエンド プールの作成とメンバの追加

 

LB による振り分け先となるサーバ(メンバ)をまとめるプールを作成します。

ここでは、プールのメンバ(Web サーバ 2台)も同時に指定します。

 

プール

  • 名前: Web-Tier-Pool-01
  • モニタ: default_https_monitor → monitor-3

 

メンバ1

  • 名前: web-01a
  • IP 172.16.10.11
  • ポート: 443
  • モニタ ポート: 443

 

メンバ2

  • 名前: web-02a
  • IP 172.16.10.12
  • ポート: 443
  • モニタ ポート: 443

 

上記の内容で XML ファイル(pool-web-tier.txt)を作成します。

cat <<EOF > pool-web-tier.txt

<pool>

  <name>Web-Tier-Pool-01</name>

  <description></description>

  <transparent>false</transparent>

  <algorithm>round-robin</algorithm>

  <monitorId>monitor-3</monitorId>

  <member>

    <ipAddress>172.16.10.11</ipAddress>

    <weight>1</weight>

    <port>443</port>

    <name>web-01a</name>

    <monitorPort>443</monitorPort>

  </member>

  <member>

    <ipAddress>172.16.10.12</ipAddress>

    <weight>1</weight>

    <port>443</port>

    <name>web-02a</name>

    <monitorPort>443</monitorPort>

  </member>

</pool>

EOF

 

プールを作成します。

cat pool-web-tier.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/config/pools

 

プールが作成されました。今回作成されたプールの ID は、pool-1 です。

nsxapi-lb-p3-06.png

 

作成したプールは、API でも確認できます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/config/pools | xmllint --format -

 

5. 仮想サーバの作成

 

LB の仮想サーバを作成します。

ここでの「仮想サーバ」は VM のことではなく、VIP やプロトコル、ポート番号などを指定した LB の設定のことです。

  • 名前: Web-Tier-VIP-01
  • アプリケーション プロファイル: OneArmWeb-01 → applicationProfile-1
  • IP アドレス: 172.16.10.10
  • プロトコル: HTTPS
  • ポート: 443
  • デフォルト プール: Web-Tier-Pool-01 → pool-1


XML ファイル(vs-web-tier.txt)を作成します。

cat <<EOF > vs-web-tier.txt

<virtualServer>

  <name>Web-Tier-VIP-01</name>

  <enabled>true</enabled>

  <ipAddress>172.16.10.10</ipAddress>

  <protocol>https</protocol>

  <port>443</port>

  <connectionLimit>0</connectionLimit>

  <connectionRateLimit>0</connectionRateLimit>

  <applicationProfileId>applicationProfile-1</applicationProfileId>

  <defaultPoolId>pool-1</defaultPoolId>

  <enableServiceInsertion>false</enableServiceInsertion>

  <accelerationEnabled>false</accelerationEnabled>

</virtualServer>

EOF


仮想サーバを作成します。

cat vs-web-tier.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/config/virtualservers


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

nsxapi-lb-p3-07.png


下記の API でも、仮想サーバの確認ができます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-5/loadbalancer/config/virtualservers | xmllint --format -

 

これで、「One-Arm Load Bala...」のテストページが表示できるようになります。

nsxapi-lb-p3-08.png


つづく。

NSX Edge LB の API 操作を体験してみる。Part 4(LB メンバのステータス確認)


NSX Edge ロードバランサ(LB)を NSX API で設定変更してみます。


前回の投稿は、こちらをどうぞ。

NSX Edge LB の API 操作を体験してみる。Part 1(はじめに)


手順について。


今回は、NSX API で One-Arm LB として使用する NSX Edge をデプロイします。

  1. API で指定するオブジェクト ID の確認
  2. NSX Edge のデプロイ

 

初期状態では、NSX Edge が2台だけデプロイされていて、

今回は 3台目の NSX Edge をデプロイします。

nsxapi-lb-p1-00.png

 

1. API で指定するオブジェクト ID の確認

 

NSX Edge を API でデプロイするときに、Web Client では 名前で指定していた vCenter インベントリのオブジェクトを、

ID で指定する必要があります。

色々な確認方法がありますが、今回は PowerCLI で簡易的に確認します。

 

まず、PowerCLI を起動して、vCenter に接続します。

PowerCLI> Connect-VIServer -Server vcsa-01a -User CORP\Administrator -Password VMware1!

 

それぞれ、ID を確認しておきます。

 

データセンター: Datacenter Site A

PowerCLI> Get-Datacenter "Datacenter Site A" | ft -AutoSize Name,Id

nsxapi-lb-p1-01.png

 

リソースプール(クラスタ): Management & Edge Cluster

PowerCLI> Get-Cluster "Management & Edge Cluster" | ft -AutoSize Name,Id

nsxapi-lb-p1-02.png

 

ホスト: esx-04a.corp.local

PowerCLI> Get-VMHost "esx-04a.corp.local"  | ft -AutoSize Name,Id

nsxapi-lb-p1-03.png

 

データストア: ds-site-a-nfs01

PowerCLI> Get-Datastore "ds-site-a-nfs01"  | ft -AutoSize Name,Id

nsxapi-lb-p1-04.png

 

フォルダ: Edges

PowerCLI> Get-Folder "Edges" | ft -AutoSize Name,Id

nsxapi-lb-p1-05.png

 

論理スイッチの ID は、NSX API で確認します。

 

論理スイッチ: Web_Tier_01

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/virtualwires | xmllint --xpath '//virtualWire[name="Web_Tier_01"]/objectId' - | more

nsxapi-lb-p1-06.png

 

2. NSX Edge のデプロイ

 

「OneArm-LoadBalancer」 という名前で、Edge Service Gataway をデプロイします。

 

NSX Edge の設定

  • 名前: OneArm-LoadBalancer
  • HA: 設定なし
  • データセンター: Datacenter Site A → datacenter-21
  • Edge の制御レベルログ(ログレベル): 緊急

 

Appliance 配置パラメータ

  • Appliance のサイズ: コンパクト
  • リソースプール: Management & Edge Cluster → datacenter-21
  • ホスト: esx-04a.corp.local → host-46
  • データストア: ds-site-a-nfs01 → datastore-29
  • フォルダ: Edges → group-v261

 

CLI の設定

  • ユーザ名: admin
  • パスワード: VMware1!VMware1!
  • SSH アクセス(remoteAccess): 無効

 

インターフェースの設定

  • vNIC 番号: 0
  • 名前: WebNetwork
  • タイプ: 内部
  • 接続先: 論理スイッチ「Web_Tier_01」 → virtualwire-2
  • IP アドレス: 172.16.10.10
  • サブネットの接頭辞の長さ: 24
  • 接続ステータス: 接続中

 

ルーティングの設定

  • デフォルトゲートウェイ IP の構成: 172.16.10.1

 

これらの設定を指定した XML ファイル(edge-onearm-lb-deploy.txt)を作成します。

cat <<EOF > edge-onearm-lb-deploy.txt

<edge>

  <datacenterMoid>datacenter-21</datacenterMoid>

  <name>OneArm-LoadBalancer</name>

  <vseLogLevel>emergency</vseLogLevel>

  <appliances>

    <applianceSize>compact</applianceSize>

    <appliance>

      <resourcePoolId>domain-c41</resourcePoolId>

      <datastoreId>datastore-29</datastoreId>

      <hostId>host-46</hostId>

      <vmFolderId>group-v261</vmFolderId>

    </appliance>

  </appliances>

  <vnics>

    <vnic>

      <index>0</index>

      <name>WebNetwork</name>

      <type>internal</type>

      <portgroupId>virtualwire-2</portgroupId>

      <addressGroups>

        <addressGroup>

          <primaryAddress>172.16.10.10</primaryAddress>

          <subnetMask>255.255.255.0</subnetMask>

        </addressGroup>

      </addressGroups>

      <mtu>1500</mtu>

      <enableProxyArp>false</enableProxyArp>

      <enableSendRedirects>false</enableSendRedirects>

      <isConnected>true</isConnected>

    </vnic>

  </vnics>

  <cliSettings>

    <userName>admin</userName>

    <password>VMware1!VMware1!</password>

    <remoteAccess>false</remoteAccess>

  </cliSettings>

  <features>

    <routing>

      <staticRouting>

        <defaultRoute>

            <vnic>0</vnic>

            <mtu>1500</mtu>

            <gatewayAddress>172.16.10.1</gatewayAddress>

            <adminDistance>0</adminDistance>

        </defaultRoute>

      </staticRouting>

    </routing>

  </features>

</edge>

EOF

 

XML ファイルを読み込んで、API で NSX Edge をデプロイします。

cat edge-onearm-lb-deploy.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges

 

NSX Edge 「OneArm-LoadBalancer」が、今回は edge-5 としてデプロイされました。

nsxapi-lb-p1-07.png

 

デプロイ直後は NSX Edge ファイアウォールの設定が Deny になっています。

nsxapi-lb-p1-08.png

 

ラボのシナリオとは異なるので、デフォルトのファイアウォールルールの設定を変更します。

  • デフォルト トラフィックポリシー: 承諾(Accept)
  • ログ:無効化

 

XML ファイル(edgefw-default.txt)を作成します。

cat <<EOF > edgefw-default.txt

<firewallDefaultPolicy>

  <action>accept</action>

  <loggingEnabled>false</loggingEnabled>

</firewallDefaultPolicy>

EOF

 

XML ファイルを読み込んで、API で設定変更します。

cat edgefw-default.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-5/firewall/config/defaultpolicy

 

設定変更されました。

nsxapi-lb-p1-09.png

 

つづく。

NSX Edge LB の API 操作を体験してみる。Part 3(One-Arm LB の設定)

NSX Edge ロードバランサ(LB)を NSX API で設定変更してみます。

設定については、HOL-SDC-1603 VMware NSX Introduction の Module 4 のシナリオを参考にしました。

 

VMware Hands-on Labs(HoL)

http://labs.hol.vmware.com/HOL/catalogs/

 

NSX API については、API Guide が参考になります。

 

NSX vSphere API Guide NSX 6.2 for vSphere

http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf

 

HoL では、下記のように NSX API をためすことができます。

NSX-v の API を HoL で実行してみる。

 

今回も、ラボの vCenter Server Appliance(vcsa-01a)から curl コマンドで、

NSX Manager(192.168.110.15)にアクセスしています。

NSX での 論理 LB の機能は、NSX Edge(Edge Service Gataway)が受け持ちます。

NSX API で NSX Manager に設定変更をリクエストすることで、NSX Edge の設定が変更されます。

 

今回の流れ。

 

長くなってしまうので、今回も含めて 5回に分けて投稿します。

  1. はじめに ※この投稿。
  2. NSX Edge LB の API 操作を体験してみる。Part 2(NSX Edge のデプロイ)
  3. NSX Edge LB の API 操作を体験してみる。Part 3(One-Arm LB の設定)
  4. NSX Edge LB の API 操作を体験してみる。Part 4(LB メンバのステータス確認)
  5. NSX Edge LB の API 操作を体験してみる。Part 5(SSL オフロード)

 

手順は、だいたい下記のような感じになります。

 

まず、One Arm トポロジの NSX Edge LB を構成します。

ここでは、新規で NSX Edge(OneArm-LoadBalancer)を追加してから設定します。

 

NSX Edge をデプロイします。 ★Part 2

  1. API で指定するオブジェクト ID の確認
  2. NSX Edge のデプロイ

 

そして、One Arm の LB を構成します。 ★Part 3

  1. LB の有効化
  2. アプリケーション プロファイルの作成
  3. LB モニタの設定変更
  4. バックエンド プールの作成とメンバの追加
  5. 仮想サーバの作成

 

その後、LB メンバのステータス確認も API で実施してみます。★Part 4

 

最後に、SSL オフロードを構成します。 ★Part 5

In Line トポロジで配置されている既存の NSX Edge LB を、SSL 終端となるように設定変更します。

この構成では、Web サーバでされていた HTTPS の SSL(TLS)終端の処理が NSX Edge にオフロードされます。

ここまでとは異なり、既存の NSX Edge(Perimeter-Gateway)の設定変更です。

  1. SSL証明書の生成
    1. CSR 作成
    2. 自己署名による証明書の作成
  2. アプリケーションプロファイルの作成
  3. バックエンド プールの作成とメンバの追加
  4. 仮想サーバの設定変更

 

次回は、One Arm LB として設定する NSX Edge のデプロイです。

つづく。

NSX Edge LB の API 操作を体験してみる。Part 2(NSX Edge のデプロイ)

Oracle Linux 7 から、Python で vSphere を操作できるようにしてみようと思います。

※いわゆる Red Hat 系ディストリビューションなので RHEL 7.x や CentOS 7.x なども同様です。

 

pyvmomi という Python のライブラリを使用します。

これは、VMware の GitHub サイトにあります。


vmware/pyvmomi

https://github.com/vmware/pyvmomi

 

PyPI にも登録されているので、今回は pip コマンドでインストールします。

 

PyPI - the Python Package Index

pyvmomi

https://pypi.python.org/pypi/pyvmomi/6.0.0.2016.4

 

今回の環境。

 

Oracle Linux 7.2 にインストールします。

[root@vm01 ~]# cat /etc/oracle-release

Oracle Linux Server release 7.2

 

Python のバージョンはこれです。

[root@vm01 ~]# python -V

Python 2.7.5

 

接続先は、vCenter Server Applicance 6.0 u1 です。

 

pyvmomi のインストール。

 

Oracle Linux 7.x は、デフォルトではパッケージがほとんどインストールされていないので、

今回は開発ツール(Development Tools)をグループインストールしてしまいます。

[root@vm01 ~]# yum groupinstall -y "Development Tools"

 

easy_install が含まれる python-setuptools をインストールします。

[root@vm01 ~]# yum install -y python-setuptools

 

pip をインストールします。

[root@vm01 ~]# easy_install pip

 

pip で、pyvmomi をインストールします。

[root@vm01 ~]# pip install pyvmomi

 

pyvmomi がインストールされました。

[root@vm01 ~]# pip freeze

backports.ssl-match-hostname==3.4.0.2

configobj==4.7.2

decorator==3.4.0

ethtool==0.8

iniparse==0.4

M2Crypto==0.21.1

pciutils==1.7.3

perf==0.1

pycurl==7.19.0

pygobject==3.14.0

pygpgme==0.3

pyliblzma==0.5.3

pyOpenSSL==0.13.1

python-dmidecode==3.10.13

pyudev==0.15

pyvmomi==6.0.0.2016.4

pyxattr==0.5.1

requests==2.10.0

rhnlib==2.5.65

six==1.10.0

slip==0.4.0

slip.dbus==0.4.0

urlgrabber==3.10

yum-metadata-parser==1.1.4

 

サンプルスクリプトのインストール。

 

サンプルスクリプトも VMware の GitHub サイトにあるので、git clone します。

[root@vm01 ~]# git clone https://github.com/vmware/pyvmomi-community-samples

 

下記のようなサンプルファイルが配置されます。

[root@vm01 ~]# cd pyvmomi-community-samples/samples/

[root@vm01 samples]# ls -1

README.md

__init__.py

add_disk_to_vm.py

add_vm_extra_config_tags.py

change_disk_mode.py

change_vm_cd_backend.py

change_vm_nic_state.py

change_vm_vif.py

clone_vm.py

create_folder_in_datacenter.py

create_random_marvel_vms.py

create_snapshot.py

delete_disk_from_vm.py

deploy_ovf.py

destroy_vm.py

esxi_perf_sample.py

execute_program_in_vm.py

export_vm.py

find_by_uuid.py

generate_html5_console.py

getallvms.py

getorphanedvms.py

getvnicinfo.py

hello_world_vcenter.py

hello_world_vcenter_with_yaml_recorder.py

list_datastore_cluster.py

list_datastore_info.py

list_dc_datastore_info.py

list_host_alarms.py

list_vmwaretools_status.py

make_dc_and_cluster.py

pyvmomi-to-suds.py

reboot_vm.py

reconfigure_host_for_ha.py

renamer.py

sessions_list.py

set_note.py

set_vcenter_motd.py

soft_reboot.py

suds-to-pyvmomi.py

tests

tools

upload_file_to_datastore.py

upload_file_to_vm.py

vSphereAutoRestartManager.py

vcenter_details.py

virtual_machine_device_info.py

virtual_machine_power_cycle_and_question.py

vminfo_quick.py

waitforupdates.py

 

動作確認。

 

ためしにサンプルスクリプト「hello_world_vcenter.py」で、vCenter(192.168.5.75)に接続してみます。

 

このスクリプトの使用方法です。

[root@vm01 samples]# python hello_world_vcenter.py --help

usage: hello_world_vcenter.py [-h] -s HOST [-o PORT] -u USER [-p PASSWORD]

 

 

Standard Arguments for talking to vCenter

 

 

optional arguments:

  -h, --help            show this help message and exit

  -s HOST, --host HOST  vSphere service to connect to

  -o PORT, --port PORT  Port to connect on

  -u USER, --user USER  User name to use when connecting to host

  -p PASSWORD, --password PASSWORD

                        Password to use when connecting to host

 

接続できました。

[root@vm01 samples]# python hello_world_vcenter.py -s 192.168.5.75 -u administrator@vsphere.local -p 'パスワード'

 

Hello World!

 

If you got here, you authenticted into vCenter.

The server is 192.168.5.75!

current session id: 52fa04cc-85ad-e576-3925-6d7f11776e22

Well done!

 

 

Download, learn and contribute back:

https://github.com/vmware/pyvmomi-community-samples

 

 

 

[root@vm01 samples]#

 

ためしに、対話モードの Python で ESXi (HostSystem)の情報を取得してみました。

[root@vm01 samples]# python

Python 2.7.5 (default, Nov 21 2015, 00:39:04)

[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> from pyVim import connect

>>> from pyVmomi import vim

>>> si = connect.SmartConnect(host='192.168.5.75',user='administrator@vsphere.local',pwd='パスワード')

>>> content = si.RetrieveContent()

>>> host_view = content.viewManager.CreateContainerView(content.rootFolder,[vim.HostSystem],True)

>>> for h in host_view.view:

...   print 'HostName:', h.name

...   print 'Hardware:', h.hardware.systemInfo.vendor, h.hardware.systemInfo.model

...   print 'Version: ', h.summary.config.product.version, h.summary.config.product.build

...   print '---'

...

HostName: hv-h01.godc.lab

Hardware: HP ProLiant Micro Server

Version : 6.0.0 3029758

---

HostName: hv-d02.godc.lab

Hardware: Dell Inc. OptiPlex 9010

Version : 6.0.0 3073146

---

HostName: hv-d01.godc.lab

Hardware: Dell Inc. OptiPlex 780

Version : 6.0.0 3073146

---

HostName: hv-i01.godc.lab

Hardware: To Be Filled By O.E.M.

Version : 6.0.0 3247720

---

>>> quit()

[root@vm01 samples]#

 

このように Python から vSphere にアクセスすることができます。

 

ちなみに、VMOMI は VMware Managed Object Management Interface の略のようなので、

pyvmomi は Python の VMOMI ということなのでしょう。

 

VMware API Related Acronyms

http://www.virtuallyghetto.com/2010/08/vmware-api-related-acronyms.html

 

以上、pyvmomi で vCenter に接続してみる話でした。

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 5 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。


手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。 ★ここ

 

FW ルール セクションに FW ルールを追加して、通信が許可されたことを確認してみます。


FW ルール セクションに FW ルールを作成。


FW ルールごとに、XML ファイルを作成します。

XML で指定している 各オブジェクトの ID は、以前の投稿(下記)で確認ずみのものです。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

「EXT to Web」 ルール

NSX 環境の外部から、Web 層ネットワークの VM に SSH と HTTPS の通信を許可します。

  • ソース: 任意
  • ターゲット: Security Group 「Web-tier」
  • サービス: SSH、HTTPS
  • 操作: 許可

 

「EXT to Web」 ルール用の XML ファイル(dfw-rule-ext2web.txt)

cat <<EOF > dfw-rule-ext2web.txt

<rule id="0" disabled="false" logged="false">

  <name>EXT to Web</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <destinations excluded="false">

    <destination>

      <name>Web-tier</name>

      <value>securitygroup-10</value>

      <type>SecurityGroup</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>SSH</name>

      <value>application-305</value>

      <type>Application</type>

    </service>

    <service>

      <name>HTTPS</name>

      <value>application-67</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

「Web to App」ルール

Web 層ネットワークの VM から、 App 層ネットワークの論理スイッチに接続されている VM に、

MyApp サービス(TCP 8443 番ポート)の通信を許可します。

  • ソース: Security Group 「Web-tier」
  • ターゲット:論理スイッチ 「App_Tier_01」
  • サービス: サービス 「MyApp」
  • 操作: 許可

 

Web to App」 ルール用の XML ファイル(dfw-rule-web2app.txt)

cat <<EOF > dfw-rule-web2app.txt

<rule id="0" disabled="false" logged="false">

  <name>Web to App</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <sources excluded="false">

    <source>

      <name>Web-tier</name>

      <value>securitygroup-10</value>

      <type>SecurityGroup</type>

    </source>

  </sources>

  <destinations excluded="false">

    <destination>

      <name>App_Tier_01</name>

      <value>virtualwire-3</value>

      <type>VirtualWire</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>MyApp</name>

      <value>application-371</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

「App to Database」ルール

App 層ネットワークの論理スイッチに接続されている VM から DB 層ネットワークの論理スイッチに接続されている VM に、

MySQL サービスの通信を許可します。

  • ソース: 論理スイッチ「App_Tier_01」
  • ターゲット:論理スイッチ「DB_Tier_01」
  • サービス: サービス「MySQL」
  • 操作: 許可

 

「App to Database」 ルール用の XML ファイル(dfw-rule-app2db.txt)

cat <<EOF > dfw-rule-app2db.txt

<rule id="0" disabled="false" logged="false">

  <name>App to Database</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <sources excluded="false">

    <source>

      <name>App_Tier_01</name>

      <value>virtualwire-3</value>

      <type>VirtualWire</type>

    </source>

  </sources>

  <destinations excluded="false">

    <destination>

      <name>DB_Tier_01</name>

      <value>virtualwire-4</value>

      <type>VirtualWire</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>MySQL</name>

      <value>application-23</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

作成された FW ルールは、既存ルールの一番上に配置されるので、

今回は、ルールが下記の順になるように、作成順序を工夫しています。

 

FW ルールの順序。

  1. EXT to Web
  2. Web to App
  3. App to Database

 

FW ルールの作成順序。

  1. App to Database
  2. Web to App
  3. EXT to Web

 

※ただし今回の FW ルールでは、FW ルールセクション内で順序が異なっても問題になりません。

 

「App to Database」 ルールの作成

 

FW ルール セッション ID 1005 の ETag を取得して・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

FW ルールを作成します。

cat dfw-rule-app2db.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

「Web to App」ルールの作成

 

同様にセクションの Etag を取得しなおして・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

 

FW ルールを作成します。

cat dfw-rule-web2app.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

「EXT to Web」ルールの作成

 

同様にセクションの Etag を取得しなおして・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

 

FW ルールを作成します。

cat dfw-rule-ext2web.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

このような感じで実行します。

hol-1603-mod3-p6-01.png

 

確認

 

Web Client からでも、FW ルールが作成されていることが確認できます。

hol-1603-mod3-p6-02.png

 

Web テストページが表示可能になったことを確認します。

hol-1603-mod3-p6-03.png

 

Web サーバ「web-01a」 にSSH アクセスが可能になったことを確認します。

ちなみに、マイクロセグメンテーションを意識した FW ルール設定なので、

この状態では Web 層のネットワークに所属する VM 同士(web-01a と web-02a) でも

不要な通信は許可されていません。

hol-1603-mod3-p6-04.png

 

このような感じで、Web Client で設定できる FW 設定は、NSX API でも可能です。

XML で設定値を指定しているので複雑に見えるかもしれませんが、

API 実行時に変更が必要な設定値は、ある程度、環境によって限定されるはずです。

今回は XML ファイルを手作業で作成したり、ID を grep で探したりしていますが、

ちゃんとツールを作成すれば手作業より安全に NSX の FW 設定を管理できそうです。

 

以上、NSX API で DFW を設定してみる話でした。

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 4 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。 ★ここ
  6. セクションに FW ルールを作成。


今回は FW ルール作成の準備として、FW ルールのセクションを作成します。


FW ルール セクションの作成。

 

FW ルールのセクション「3-tier App」を作成します。

 

セクションを作成する場合、XML はセクション名(name)だけでも大丈夫です。

また、NSX API ガイドにあるように FW ルールを含めてセクションを作成することも可能です。

API ガイドを見た様子では、FW ルールの順序の入れ替えなどはセクション全体の更新となるようなので、

実際は FW ルールもセッションと同時に作成したほうが便利かもしれません。

 

ここでは下記の XML で空のセクションを作成して、後から FW ルールを作成してみます。

<section name="3-tier App"/>

 

API でセクションを作成します。

テキストの量が少なかったので、今回は XML ファイルを作成してません。

echo '<section name="3-tier App"/>' | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections

 

「3-tier App」セクションは、ID 1005 で作成されました。

hol-1603-mod3-p5-01.png

 

Web Client でも「3-tier App」 セクションの作成が確認できます。

hol-1603-mod3-p5-02.png

 

この状態で、次回の投稿で FW ルールを追加してみます。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

参考: FW ルールセクションの作成。(FW ルール含む)

 

FW ルールも含めてセクションを作成する場合は、下記のような XML になります。

この XML を投入すれば今回の設定は終わりですが、HoL の「テキストの送信」で

この量のテキストを送信するのはつらいので、あえて今回は FW ルールを別作成にしました。

<section name="3-tier App" >

  <rule disabled="false" logged="false">

    <name>EXT to Web</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <destinations excluded="false">

      <destination>

        <name>Web-tier</name>

        <value>securitygroup-10</value>

        <type>SecurityGroup</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>SSH</name>

        <value>application-305</value>

        <type>Application</type>

      </service>

      <service>

        <name>HTTPS</name>

        <value>application-67</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

  <rule disabled="false" logged="false">

    <name>Web to App</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <sources excluded="false">

      <source>

        <name>Web-tier</name>

        <value>securitygroup-10</value>

        <type>SecurityGroup</type>

      </source>

    </sources>

    <destinations excluded="false">

      <destination>

        <name>App_Tier_01</name>

        <value>virtualwire-3</value>

        <type>VirtualWire</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>MyApp</name>

        <value>application-371</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

  <rule disabled="false" logged="false">

    <name>App to Database</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <sources excluded="false">

      <source>

        <name>App_Tier_01</name>

        <value>virtualwire-3</value>

        <type>VirtualWire</type>

      </source>

    </sources>

    <destinations excluded="false">

      <destination>

        <name>DB_Tier_01</name>

        <value>virtualwire-4</value>

        <type>VirtualWire</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>MySQL</name>

        <value>application-23</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

</section>

 

ちなみに、FW セッションを作成する API では、FW ルールを含んでいても ETtag (If-Match ヘッダ)の指定は不要です。

上記の XML を「dfw-section-3tier.txt」 というファイルに保存してあるとすると、

下記のようなコマンドラインで FW セッションが作成できます。

cat dfw-section-3tier.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections

 

まだつづく・・・

NSX API での 分散 FW 設定を体験してみる。Part 6 (HOL-SDC-1603 Module 3 より)

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。 ★ここ
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

ここから、FW ルールの設定を変更します。

FW ルールで設定した通信のみ許可するため、まず FW のデフォルトルールを

すべて許可(Allow)される状態から、すべてブロックされる状態に変更します。

 

デフォルトの FW ルールを Allow → Block に変更。

 

「Default Section Layer3」セクションの「Default Rule」を、Allow から Block(deny)に変更します。

NSX API での FW ルールの設定変更では、まず XML ファイルを作成しておきます。

 

既存の FW ルールの情報は下記のようなコマンドラインで確認できるので、用意する XML の参考にします。

URL に含まれる ID は、前回の投稿で確認したものを指定しています。

  • 「Default Section Layer3」 の Section ID = 1003
  • 「Default Rule」 の Rule ID = 1001

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001 | xmllint --format -

 

今回は「Default Rule」ルールを設定変更するための XML を、「dfw-rule-default.txt」として用意します。

  • ルールの ID は、1001。※前回の投稿で確認した ID。
  • action で、Block に対応する「deny」を指定。

cat <<EOF > dfw-rule-default.txt

<rule id="1001" disabled="false" logged="false">

  <name>Default Rule</name>

  <action>deny</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

</rule>

EOF

 

FW ルールの設定を変更する NSX API では、ETag ヘッダの指定が必要なため、設定変更の対象となるリソースの ETag を確認しておきます。

ヘッダ情報を確認するため、下記の curl コマンドラインでは「-I」 オプションを付けています。

curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001

hol-1603-mod3-p4-01.png


今回は、ETag の値を「ETAG」 という変数に代入して、コマンドラインで指定しています。

Etag の値を取得します。

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001 | grep ETag | awk '{print $2}'`

 

さきほど作成した XML ファイル(dfw-rule-default.txt) の内容で、FW ルールを設定変更します。

cat dfw-rule-default.txt | curl -k -s -u admin:VMware1! -X PUT -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001

 

コマンドラインの実行結果から、action が deny になったことが確認できます。

hol-1603-mod3-p4-02.png

 

Web Client の情報を更新すると、ルールの Action が Allow から Block に変更されたことがわかります。

hol-1603-mod3-p4-03.png

 

「3-Tier Web App」のテストページが表示できなくなります。

hol-1603-mod3-p4-04.png

 

NSX 管理外の環境(ラボのコンソール)から、Web 層の VM 「web-01a」 への SSH アクセスができなくなります。

hol-1603-mod3-p4-05.png

 

つづく。

NSX API での 分散 FW 設定を体験してみる。Part 5 (HOL-SDC-1603 Module 3 より)

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 2 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。 ★ここ
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

NSX API では、URL や XML で設定対象を指定するときに、対象オブジェクトの ID 指定が必要になります。

そこで、各オブジェクトの ID を確認しておきます。

XML の出力結果を整形するため、パイプで 「xmllint --format -」 をつけています。

また、NSX API で取得した情報は、XML としてパースするわけではなく grep で簡易的に絞り込んでいます。

 

Transport Zone ID


Transport Zone の ID を確認しておきます。

今回の設定では、「Local-Transport-Zone-A」 という名前の Transport Zone を指定します。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes | xmllint --format - | grep -E "vdnscope-|name" | grep -B1 "Local-Transport-Zone-A"

 

ID には、「vdnscope-」 がつきます。

  • Local-Transport-Zone-A → vdnscope-1

hol-1603-mod3-p3-01.png

 

論理スイッチ ID

 

論理スイッチ「App_Tier_01」、「DB_Tier_01」 の ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires | xmllint --format - | grep -E "virtualwire-|name" | grep -B1 -E "App_Tier_01|DB_Tier_01"

 

ID には、「virtualwire-」 がつきます。

  • App_Tier_01 → virtualwire-3
  • DB_Tier_01 → virtualwire-4

hol-1603-mod3-p3-02.png


セキュリティグループ ID

 

FW ルールで指定する、セキュリティグループの ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/securitygroup/scope/globalroot-0 | xmllint --format - | grep -E "securitygroup-|name" | grep -B1 "Web-tier"

 

ID には、「securitygroup-」 がつきます。

hol-1603-mod3-p3-03.png

 

サービス ID

 

FW ルールで指定するサービスの ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/application/scope/globalroot-0 | xmllint --format - | grep -E "objectId|name" | grep -B1 -E "SSH|HTTPS|MyApp|MySQL"

 

ID には、「application-」 がつきます。

  • HTTPS → application-67
  • SSH → application-305
  • MyApp → application-371 ※ここまでの手順で作成したサービス。
  • MySQL → application-23

hol-1603-mod3-p3-04.png

 

FW ルール セクション ID


「Default Section Layer3」セクションの情報を確認します。

ルール名に含まれる半角スペースは、URL エンコーディングの都合で 「%20」 としています。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections?name=Default%20Section%20Layer3 | xmllint --format - | grep section

 

「Default Section Layer3」 セクションが ID = 1003 だということがわかります。

hol-1603-mod3-p3-05.png

 

FW ルール ID


ruleType=LAYER3 のルールで、ルール名に「default」 が含まれるルールの情報を取得してみます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config?ruleType=LAYER3\&name=default | xmllint --format - | grep -E "id=|name=" -A1

 

「Default Rule」 ルールが ID = 1001 だとわかります。

hol-1603-mod3-p3-06.png

 

つづく・・・

NSX API での 分散 FW 設定を体験してみる。Part 4 (HOL-SDC-1603 Module 3 より)