Quantcast
Channel: VMware Communities : Blog List - All Communities
Viewing all 3135 articles
Browse latest View live

VMware AppVolume – Troubleshooting

$
0
0

This blog provides details on troubleshooting an App Volumes environment using the App Volumes logs. 

 

Here are the log files that you can look at in order to troubleshoot:

 

 

  • App Volumes Manager logs
  • App Volumes Agent log files

 

App Volumes Manager logs :


The App Volumes Manager log files are:

  • svmanager_server.log
  • production.log

 

These log files are located at C:\Program Files(x86)\CloudVolumes\Manager\Log on the App Volumes Manager server.

 

Here is the details about Production and SVManager logs:

 

production.log :

 

The App Volumes Manager server contains logging from the main modules of App Volumes. Use the production.log file to identify a variety of issues in an App Volumes environment.

 

Here is a description of the main modules to search for in the production.log file.

  • RADIR : RubyActiveDIRectory classes – Responsible for AD connection
  • Cvo : App Volumes logic classes
  • RvSphere : RubyvSphere wrapper classes
  • SQL : Database queries (Default logging captures only errors. Debug logging captures queries and errors)
  • PowerShell : App Volumes PowerShell interface classes
  • NTLM : App Volumes NTLM handler

 

svmanager_server.log :

The svmanager_server.log file captures App Volumes Manager server actions. You can correlate these actions with the Agent log files by checking time stamps from both the server and agent logs. The svmanager_server.log file also captures information relating to the App Volumes infrastructure.

 

App Volumes Agent log files :


The App Volumes Agent log files are:

  • svservice.log
  • svdriver.log
  • svcapture.log This log file is present only on a capture machine.

 

Locations for Agent log files :


In releases earlier than App Volumes 2.9, the App Volumes Agent logs are located at C:\Windows on the Agent machines. The svcapture.log file is also located at C:\Windows , on the capture machine.

 

For App Volumes 2.9 and later, the Agent log locations have changed.

The svservice.logfile is located at C:\Program Files (x86)\CloudVolumesAgent\Logs on the Agent machines.

The svcapture.log file is located atC:\Program Files (x86)\CloudVolumesAgent\Logs on the capture machine.

 

Here are details about Agent log files:

 

svservice.log:

SvService is the service responsible for communication between the App Volumes Agent and the App Volumes Manager, including the preparation of volumes, the running of post-attach scripts, refresh of variables, and registration of fonts. The log tracks this communication.

svcapture.log:

The SvCaptureservice performs provisioning and editing functions during application capture, such as generating policy files and metadata. The SvCapturereports this information to the App Volumes Agent and App Volumes Manager. The log tracks this activity and is available only on the capture machine.

svdriver.log:

SvDriver is a policy-driven driver file responsible for the virtualization of volume contents into the desktop OS. The policy file snapvol.cfg controls the files, directories, registry keys, and processes that are virtualized during application capture on each volume. The log tracks this activity.


スクリプトを利用した仮想マシンの操作 (1)

$
0
0

こんにちは。 VMware の松田です。

 

今回はスクリプトを利用した vCloud Air 上のマシンの操作方法を紹介します。

vCloud Air 上のマシンの操作には vCloud API などの REST API が利用できますが、

今回は Windows 上で PowerCLI を利用した操作方法を紹介します。

 

PowerCLI のインストール

本ブログ記事では PowerCLI 6.0 Release 3 を利用して検証しています。

 

vSphere PowerCLI 6.0

https://developercenter.vmware.com/web/dp/tool/vsphere_powercli/6.0

 

上記のサイトから MyVMware のアカウント情報を利用してインストーラーをダウンロードし、インストールを行います。

インストール完了後、Power shell の Execution Policy を RemoteSigned 以上に設定します。

 

設定する際には、PowerCLI を管理者として実行してコマンドを実行します。

コマンド例: Set-ExecutionPolicy remoteSigned

 

4.PNG2.PNG

上記の設定完了後、正常に PowerCLI が起動することを確認します。

正常に起動できない場合には、管理者権限で PowerCLI を実行しましょう。

5.PNG

 

PowerCLI を利用した仮想デスクトップ コンソールへのアクセス

PowerCLI を利用して契約している vCloud Air の環境にアクセスします。


> 仮想マシンへのコンソール接続

# Dedicated Cloud もしくは Virtual Private Cloud (VPC)

# PowerCLI を起動し、認証情報を入力します。

Connect-PIServer

# Compute Instance を GUI から選択します。

$CI = Get-PIDatacenter | Out-GridView -OutputMode Single

$CI | Connect-CIServer

# 仮想マシンの一覧からコンソール接続する電源が入った仮想マシンを選択します。

$selection = Get-CIVM | ? {$_.Status -eq "PoweredOn"} | Out-GridView -OutputMode Multiple

$selection | foreach { Open-VMConsoleWindow $_}

 

# OnDemand サービス

# PowerCLI を起動し、認証情報を入力します。

Connect-PIServer -vca

# Compute Instance を GUI から選択します。

$CI = Get-PIComputeInstance | Out-GridView -OutputMode Single

$CI | Connect-CIServer

# 仮想マシンの一覧からコンソール接続する電源が入った仮想マシンを選択します。

$selection = Get-CIVM | ? {$_.Status -eq "PoweredOn"} | Out-GridView -OutputMode Multiple

$selection | foreach { Open-VMConsoleWindow $_}

 

// Out-GridView を利用した仮想マシンの選択

0419.PNG

 

// ブラウザ上でコンソール表示した際のスクリーンショット

11.PNG

 

上記の方法はプラグイン (VMRC) を利用してコンソール接続しますが、2016 年 4 月時点では、Chrome はプラグインが動作しません。

そのため、Firefox か IE を利用する必要があるので、Chrome が起動してしまう人は以下の設定が必要です。

※ 既定のブラウザを変更しても対応可能です。

# 現在のセッションの既定ブラウザを 32 bit 版の Firefox を利用するよう設定する

Set-PowerCLIConfiguration -Scope Session -VMConsoleWindowBrowser "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -Confirm:$false

# 現在のセッションの既定ブラウザを 32 bit 版の IE を利用するよう設定する

Set-PowerCLIConfiguration -Scope Session -VMConsoleWindowBrowser "C:\Program Files (x86)\Internet Explorer\iexplore.exe" -Confirm:$false


// Firefox Tips

Firefox の設定から [アドオン] を選択して、[プラグイン] から "VMware Remote Console Plug-in" を [常に有効化する] を選択しておきましょう。

 

// IE Tips

IE11 で接続する際には以下の方法を実施してください。

1. PowerCLI から 32 bit の IE が立ち上がることを確認します。

2. ブロックされたコンテンツを有効にします。

5.PNG

3. 右上にある歯車のアイコンから F12 開発者ツール を選択します。

7.PNG

4. エミュレーション タブを選択し、ドキュメント モード に 10 を選択します。

9.PNG

 

この他の PowerCLI の便利な利用方法は今後も掲載予定です。

 

// 参考資料

VMware vSphere PowerCLI 6.3 Release 1 Release Notes

http://pubs.vmware.com/Release_Notes/en/powercli/63r1/powercli63r1-releasenotes.html

 

Compatibility Matrixes for vSphere PowerCLI 6.3 Release 1

https://www.vmware.com/support/developer/PowerCLI/doc/powercli63r1-compat-matrix.html

 

New release: PowerCLI 6.3 R1–Download it today!

http://blogs.vmware.com/PowerCLI/2016/03/new-release-powercli-6-3-r1download-today.html

 

【免責事項】

本ブログに記載された内容は情報の提供のみを目的としたもので、正式な VMware のテストやレビューを受けておりません。

内容についてできる限り正確を期すよう努めてはおりますが、いかなる明示または暗黙の保証も責任も負いかねます。

本ブログの情報は、使用先の責任において使用されるべきものであることを、あらかじめご了承ください。

 

このブログに記載された製品の仕様ならびに動作に関しては、各社ともにこれらを予告なく改変する場合があります。

非営利目的の個人利用の場合において、自由に使用してもかまいませんが、営利目的の使用は禁止させていただきます。

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

$
0
0

NSX では、API ガイドが公開されています。

 

NSX vSphere API Guide NSX 6.2 for vSphere

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

 

ためしに API を NSX Manager に実行してみたいのですが、

残念ながら NSX は評価版が一般公開されていません。

しかし、VMware Hands-on Labs(HoL)では NSX 環境を使用することができるので、そこで試してみようと思います。

 

VMware Hands-on Labs

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

 

HoL の Lab のうち、今回は「HOL-SDC-1603 VMware NSX Introduction」を使用します。

 

HOL-SDC-1603 VMware NSX Introduction の環境

 

HoL の NSX Manager のアドレスは、Web Client の

「Networking & Security」→「Installation」→「Management」タブ

を開くと確認できます。「192.168.110.15」が NSX Manager です。

nsx-api-00.png

 

この環境には、Web ブラウザの REST Cliet などがみあたらなかったので

vCenter(VCSA)の curl コマンドから API を実行してみます。

VCSA「vcsa-01a.corp.local」には、PuTTY から SSH でログインできます。

nsx-api-01.png

 

curl コマンドでの API 実行

 

API を実行する場合は、直接入力だとつらいので HoL の「テキストの送信」機能を使用します。

これで手元に、実行したコマンドラインや XML ファイルを残すことができます。

ためしに API から、論理スイッチを表示 / 作成してみます。

 

論理スイッチの表示

 

API ガイドを参考にして、下記のコマンドラインを実行してみました。

  • 論理スイッチは、「virtualwires」と指定します。※以前はこう呼ばれていました。
  • XML 表示を整形するために、パイプで xmllint をつけています。
  • 出力内容が多いので、パイプで more をつけています。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires | xmllint --format - | more

 

下記のような感じで、論理スイッチの情報が XML で表示されます。

nsx-api-02.png

 

表示量が多いので、とりあえず「| grep name」で絞ってみました。

nsx-api-03.png

 

Web Client からみた 論理スイッチ(Logical Switches)と同じ情報です。

nsx-api-04.png

 

論理スイッチの作成

 

「LS-test-01」という論理スイッチを作成してみます。

論理スイッチの作成は、表示とは異なり、XML ファイルを読み込ませます。

 

ls-test.txt ファイルの内容

<virtualWireCreateSpec>

  <name>LS-test-01</name>

  <description>Test LS</description>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

 

このファイルは、下記のように作成します。

cat <<EOF > ls-test.txt

<virtualWireCreateSpec>

  <name>LS-test-01</name>

  <description>Test LS</description>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

EOF

 

そして、下記のようにコマンドラインを実行します。

cat ls-test.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires

 

実行する様子は、このようになります。

nsx-api-05.png

 

これで、論理スイッチが作成されました。

Web Client でも、論理スイッチの作成が確認できます。

nsx-api-06.png

 

このような感じで、HoL でも NSX API を実行できます。

 

以上、HoL で NSX API を試してみる話でした。

NSX の HoL で 工夫して DFW だけ機能検証してみる。

$
0
0

NSX では、ネットワークにかかわる様々な機能を実現できます。

たとえば、VXLAN によるオーバーレイネットワーク構成、分散ルーティング、分散ファイアウォール・・・など。

それぞれを連携させて利用することができますが、

逆に、それぞれの機能を必要なものだけ利用することも可能です。

 

たとえば導入検討などで、実際は直接的に関係しない機能同士の影響が気になるケースもあると思います。

そういった場合にも、VMware Hands-on Labs(HoL)を利用して確認をすることができます。

 

今回は、HoL「HOL-SDC-1603 VMware NSX Introduction」で、(通常はそうする必要はありませんが)

あえて VXLAN を無効にして分散ファイアウォールをためしてみます。

 

VMware Hands-on Labs

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

 

準備として、あえて VXLAN を無効化。

 

HoL では、「Compute Cluster A」と「Compute ClusterB」というクラスタに検証用 VM が配置されています。

hol-nsx-1.png

 

この環境の VM は、初期状態では VXLAN の論理スイッチとなる「vxw-~」という分散ポートグループに接続されています。

これらの VM を、「vds_site_a_VM Network」という VXLAN とは関係のない普通の分散ポートグループに接続しました。

hol-nsx-2.png

 

そして、「Compute Cluster A」と「Compute ClusterB」を

Transport Zone からはずして、VXLAN も構成解除してしまいます。

hol-nsx-3.png

 

「Compute Cluster A」と「Compute ClusterB」は、すべての ESXi ホストで

VXLAN が未構成(Not Configured)で、Firewall が有効(Enabled)の状態にしました。

hol-nsx-4.png

 

vNIC を対象に、分散ファイアウォールのルールを投入してみる。

 

今回は動作確認のため、web-02a という VM の vNIC で、Ping(ICMP)を拒否するルールを設定してみました。

hol-nsx-5.png

 

Distributed Firewall のルールを追加して、設定反映(Publish Changes)します。

hol-nsx-6.png

 

web-01a から、ルールの対象である web-02a に ping を実行していたところ、

設定反映のタイミング(赤線のところ)から拒否されるようになりました。

hol-nsx-7.png

 

このような感じで、実際に検証機材を用意できない場合でも検証方法を工夫すれば、

ある程度 HoL の Lab マニュアルにないことでも簡易 PoC 的なことができそうだと思います。

 

以上、HoL の NSX 環境で工夫してみる話でした。

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

$
0
0

以前に、HoL で、NSX API を試す方法を紹介しました。

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

 

今回は、HOL-SDC-1603 VMware NSX Introduction の Module 1 と同様の設定を

Web Client のかわりに curl コマンドで NSX API を実行して設定してみようと思います。

コマンドラインで指定している 192.168.110.15 は、NSX Manager の IP アドレスです。

 

手順の流れ

  1. 論理スイッチ「Prod_Logical_Switch」を作成する。
  2. 作成した論理スイッチと NSX Edge を接続する。
  3. VM「web-03a」と「web-04a」の vNIC を、作成した論理スイッチに接続する。
  4. 確認してみる。

 

1. 論理スイッチ作成。

 

まず、論理スイッチ「Prod_Logical_Switch」を作成します。

下記のような XML ファイルを作成しました。

 

ls-prod.txt

<virtualWireCreateSpec>

  <name>Prod_Logical_Switch</name>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

 

「テキストの送信」で、下記のようなコマンドを送信、実行して、ファイルを作成します。

cat <<EOF > ls-prod.txt

<virtualWireCreateSpec>

  <name>Prod_Logical_Switch</name>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

EOF

 

XML で指定している ID は、Web Client の NSX Edges 画面であたりがつきますが、

下記のような NSX Edge の情報を取得する API からでもわかります。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges | xmllint --format - | grep -e objectId -e name

hol-nsx-mod1-0.png

 

ファイルを読み込んで、論理スイッチを作成する API を実行します。

下記のようなコマンドラインを実行します。virtualwire は、論理スイッチのことです。

cat ls-prod.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires

 

このような感じで実行します。例では virtualwire-5 という ID で、論理スイッチが作成されました。

hol-nsx-mod1-1.png

 

2. 論理スイッチと NSX Edge を接続。

 

作成した論理スイッチと、NSX Edge Service Gateway(ESG) を接続します。

この ESG は、Perimeter-Gateway の役割として配置されているものです。

 

XML は、下記のように Lab マニュアルでの設定値を指定しました。
portgroupId には、論理スイッチ作成時に表示された virtualwire-5 を指定します。

 

edge-if-prod.txt

<vnic>

  <name>Prod_Interface</name>

  <addressGroups>

    <addressGroup>

      <primaryAddress>172.16.40.1</primaryAddress>

      <subnetMask>255.255.255.0</subnetMask>

      <subnetPrefixLength>24</subnetPrefixLength>

    </addressGroup>

  </addressGroups>

  <mtu>1500</mtu>

  <type>internal</type>

  <isConnected>true</isConnected>

  <index>5</index>

  <portgroupId>virtualwire-5</portgroupId>

  <enableProxyArp>false</enableProxyArp>

  <enableSendRedirects>false</enableSendRedirects >

</vnic>


ファイルは、下記のように作成します。

cat <<EOF > edge-if-prod.txt

<vnic>

  <name>Prod_Interface</name>

  <addressGroups>

    <addressGroup>

      <primaryAddress>172.16.40.1</primaryAddress>

      <subnetMask>255.255.255.0</subnetMask>

      <subnetPrefixLength>24</subnetPrefixLength>

    </addressGroup>

  </addressGroups>

  <mtu>1500</mtu>

  <type>internal</type>

  <isConnected>true</isConnected>

  <index>5</index>

  <portgroupId>virtualwire-5</portgroupId>

  <enableProxyArp>false</enableProxyArp>

  <enableSendRedirects>false</enableSendRedirects >

</vnic>

EOF

 

上記のファイルを指定して、ESG のインターフェースを 5 を設定して論理スイッチを接続します。

edge-id として「edge-2」、インターフェースの Index として 5 を指定しています。

cat edge-if-prod.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/vnics/5

 

3. 論理スイッチに vNIC を接続。

 

作成した論理スイッチに、VM の vNIC を接続します。

このとき使用する XML では、VM と vNIC の ID が必要になります。


VM ID と vNIC ID の確認。

 

論理スイッチに VM の vNIC を接続するときには、VM と vNIC の ID を指定する必要があります。

NSX の API ガイドでは vCenter の Web UI 経由(/mob)で確認する方法が紹介されていますが、

HoL だと操作が大変なので、web-03a と web-04a に関係する ID を、PowerCLI で確認してしまいます。

 

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

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

 

VM の ID は、下記のコマンドラインでわかります。

UUID(ここでは PersistentId)の値も指定するケースがあるようなので、ついでに見ておきます。

PowerCLI> Get-VM web-0[34]a | ft -AutoSize Id,PersistentId

 

vNIC の ID は、下記のコマンドラインでわかります。

4000 から ID が付与されていますが、API で指定するときは

4000 → 000、4001 → 001 といったように読み替えるようです。

PowerCLI> Get-VM web-0[34]a | Get-NetworkAdapter | ft -AutoSize Parent,Id,Name

 

VM の ID がそれぞれ vm-305 と vm-306 だとわかります。

hol-nsx-mod1-2.png

vNIC の ID は、4000~ の数字です。

hol-nsx-mod1-3.png

 

論理スイッチに vNIC を接続する。

 

今回の XML の内容は、下記のようにしました。

 

vnic-attach_web-03a.txt

  • web-03a を Prod_Logical_Switch に接続する。
    • 502e58e2-c139-f2d9-5560-9df1ffa26b45 が web-03a を表します。
    • vnicUuid は、先頭が VM ID で、 「.000」が vNIC の順番によって変わります。
    • vitualwire-5 が、Prod_Logical_Switch を表します。

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>502e58e2-c139-f2d9-5560-9df1ffa26b45</objectId>

  <vnicUuid>502e58e2-c139-f2d9-5560-9df1ffa26b45.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

 

vnic-attach_web-04a.txt

  • web-04a を Prod_Logical_Switch に接続する。
  • 502ea036-ec16-45e1-2a61-a702e7f73d5a.000 と vm-306 は、どちらも web-04a を表します。
  • ためしに objectId を、vm-N 形式の VM ID を指定しても設定できました。
    ただし API Guide は UUID 指定なので、その方がよいかもしれません。
  • ちなみに、vnicUuid は vm-N 形式だとダメでした。

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>vm-306</objectId>

  <vnicUuid>502ea036-ec16-45e1-2a61-a702e7f73d5a.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

 

それぞれ、下記のようにファイル作成します。

 

web-03a 用

cat <<EOF > vnic-attach_web-03a.txt

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>502e58e2-c139-f2d9-5560-9df1ffa26b45 </objectId>

  <vnicUuid>502e58e2-c139-f2d9-5560-9df1ffa26b45.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

EOF


web-04a 用

cat <<EOF > vnic-attach_web-04a.txt

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>vm-306</objectId>

  <vnicUuid>502ea036-ec16-45e1-2a61-a702e7f73d5a.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

EOF

 

web-03a の vNIC を接続します。

cat vnic-attach_web-03a.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/virtualwires/vm/vnic

 

web-04a の vNIC を接続します。

cat vnic-attach_web-04a.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/virtualwires/vm/vnic

hol-nsx-mod1-6.png

 

4. 設定の確認。

 

Web Client でも、作成した論理スイッチ「Prod_Logical_Switch」が表示されます。

hol-nsx-mod1-4.png

 

ESG(Perimeter-Gateway) の vNIC 5 に、「Prod_Interface」 が設定されています。

hol-nsx-mod1-5.png


論理スイッチ「Prod_Logical_Switch」 に、VM が接続されています。

接続した VM 同士である web-03a から web-04a に Ping も飛びます。

hol-nsx-mod1-7.png

 

Lab の冒頭ということもあり簡単な設定内容の例でしたが、NSX API は多くの機能に対応しています。

REST API は今回の curl コマンドに限らず様々な言語、ツールから実行することができるので、

うまく利用すれば、ネットワーク構成変更を柔軟に自動化したりできそうです。

 

API ガイドはこちらです。

 

NSX vSphere API Guide

NSX 6.2 for vSphere

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

 

以上、NSX API 体験でした。

vCloud Air 上の仮想マシン等をローカルにダウンロードする方法

$
0
0

こんにちは。 VMware の松田です。

 

今回は vCloud Air 上に保存されているファイル (vApp/OVF/ISO など) をローカルに移動するスクリプトの紹介となります。

すでにスクリプトは GitHub 上に公開されており、どなたでもダウンロードすることができます。

 

GitHub - naokanak/EasyDownload: Download vApps/OVF/ISO from vCloud Air.

 

用意するものとしては以下の 3 つです。

  • PowerCLI (PowerCLI 6.0 Release 3 以降)
  • OVFtool (Version 4.1.0 で確認済み)
  • vCloud Air のログインアカウント

 

PowerCLI および OVFTool の入手については以下の資料を参照してください。

 

// PowerCLI のインストールについて

スクリプトを利用した仮想マシンの操作 (1)

 

// OVFTool のインストールについて

VMware KB:     vCloud AirユーザーのためのOVFツールのインストールおよびご利用ガイド

 

利用方法

1. PowerCLI を起動します。

1.PNG

2. OVFTool.exe が PATH に含まれていない場合には OVFTool.exe の保存先を入力します。

2.PNG

3. どのような操作を実施するか指定します。ダウンロードは Dedicated/VPC もしくは OnDemand サービスの両方から実行できます。

14.PNG

4. 本例では選択肢 1 (Dedicated/VPC から停止状態の vApp をダウンロードする) を選択します。

5. まずはダウンロード先のディレクトリを指定します。

3.PNG

6. 続いて vCloud Air へのログイン情報を入力します。

4.PNG

7. 接続対象の vCloud Air の組織名を指定します。

5.PNG

8. 続いて接続対象の vDC (仮想データセンター) を選択します。

6.PNG

9. 自動的に停止状態の vApp の一覧が取得されます。すべてをダウンロードしない場合には、”Y" 以外を入力します。

10.PNG

10 特定の vApp をダウンロードする場合にはする、GUI で自由に選択します。

11.PNG

11. 最後にダウンロード対象を確認し、ダウンロードを開始します

12.PNG

12. 正常にダウンロードを完了することを確認します。

13.PNG

NSX-v の API を HoL で実行してみる。(Firefox RESTClient 編)

$
0
0

最近、HOL-SDC-1603 VMware NSX Introduction で NSX API を試す方法を紹介をしてみましたが・・・

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

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

 

よく見たら、下記のラボにも NSX API の紹介がありました。

 

HOL-SDC-1625 VMware NSX Advanced

MODULE 7 - NSX AUTOMATION

 

英語マニュアルのみのラボですが、

Firefox の RESTClient アドオンが用意されていて、GUI から NSX API 実行を試すことができます。

これは下記 URL のアドオンで、わりとよく使われている REST Client ではないかと思います。

RESTClient, a debugger for RESTful web services. :: Add-ons for Firefox

 

このラボで Firefox を起動すると、すでに RESTClient アドオンが利用可能になっています。

hol-nsx-1625-restclient-01.png

 

リクエスト送信前に、Authentication と Content-Type のヘッダを設定しておきます。

Authentication」→「Basic Authentication」をクリックして・・・

hol-nsx-1625-restclient-02.png

 

NSX Manager のログインユーザ名とパスワードを入力します。

※ラボでは admin ユーザを使用します。

hol-nsx-1625-restclient-03.png

 

「Headers」→「Custom Header」をクリックして・・・

hol-nsx-1625-restclient-04.png

 

Content-Type を設定します。

  • Name: Content-Type
  • Value: application/xml

hol-nsx-1625-restclient-05.png

 

あとはラボマニュアルや API Guide をもとに、ラボの「テキストの送信」を利用して API を実行します。

例えば API Guide にある、NSX Contrller の情報取得 API を実行する場合・・・

Query Controllers

 

Request:

GET https://NSX-Manager-IP-Address/api/2.0/vdn/controller

 

下記のような感じで指定して、「SEND」 ボタンを押すと Response に結果が表示されます。

  • Method は「GET」 。
  • URL では、NSX Manager のアドレスとして「nsxmgr-01a.corp.local」を指定。
  • Headers に Application と Content-Type が追加されている。
  • Body は、Request Body の指定が不要なので空欄のまま。

hol-nsx-1625-restclient-06.png

 

取得できた情報は、「Response Body (Preview)」タブに表示される情報が見やすいと思います。

XML 要素を折りたたむことができるので、下記では id が controller-1 の NSX Controller の情報だけ展開しています。

hol-nsx-1625-restclient-07.png


実際の運用やツールから API を利用することになると、この REST Client を使用することはないと思います。

しかし、導入が簡単で利用方法も簡単なので、API 自体の調査や、デバッグなどで便利です。

 

ちなみに、このラボ(HOL-SDC-1625)では、下記のような API 使用例が紹介されています。

  • NSX Controller の設定確認と Syslog 転送先設定
  • 論理スイッチの作成
    ※あわせて、指定が必要になる Transport Zone(Scope ID)の確認方法なども紹介されています。

 

実際のところ NSX Manager や Controller にはあまり設定要素がないので、

個人的には、論理スイッチの管理や vNIC の接続、ファイアウォール ルールのメンテナンスなどの方が

NSX API の使いどころなのではないかと思っています。

 

以上、NSX API を HoL で試す話の補足でした。

NSX API で NW 構成変更を体験してみる。Part 2(HOL-SDC-1603 Module 2 より)

$
0
0

前回、HOL-SDC-1603 の Module 1 をもとに、論理スイッチの作成して VM を接続してみました。

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

 

今回は同じラボの Module 2 のシナリオをもとに、NSX Edge を API で設定変更してみようと思います。

 

設定変更対象の NSX Edge

 

設定変更対象の NSX Edge は、下記の 2つです。

 

Perimeter-Gateway

  • ルータや、FW などのネットワークサービスをを実現する VM。NSX Edge Service Gateway。※以下 ESG
  • Web Client では、Type: NSX Edge
  • 今回の環境での edge-id は「edge-2」

 

Distributed-Router

  • 分散ルーティングをコントロールする。分散論理ルータ。※以下 DLR
  • Web Client では、Type: Logical Router
  • 今回の環境での edge-id は「edge-4」

hol-1603-mod2-01.png

 

手順の流れ。

 

  1. ESG からインターフェース削除。
  2. DLR に論理インターフェース(LIF)を構成。※App 層、DB 層の間の分散ルーティングを可能にします。
  3. DLR で OSPF を構成。
  4. ESG で OSPF の設定を修正。※DLR と動的ルーティングが構成される。


※今回も、VCSA(vcsa-01a)から NSX Manager(192.168.110.15)に curl コマンドを実行しています。

※NSX Edge の追加と ECMP の構成は、今回は省略しています。

 

1. ESG からインターフェース削除。

 

まず、ESG から Internal_App と Internal_DB というインターフェースを削除します。

この時点では、どちらも ESG に構成されています。

 

Web Client から見た、ESG のインターフェースの状態です。

まだ Internal_App と Internal_DB が構成されています。

hol-1603-mod2-02.png

 

この時点では、「3-Tier Web App」のテストページが表示できます。

hol-1603-mod2-03.png

 

API では、下記のコマンドラインでインターフェースの状態が確認できます。

ここで、論理スイッチの ID も表示されるので控えておきます。

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

 

Internal_App インターフェースの確認

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/vnics/3 | xmllint --format -

 

Internal_DB インターフェースの確認

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/vnics/4 | xmllint --format -


ESG からインターフェースを削除します。

ちなみに、API からの設定変更は、Web Client とはことなり「Publish Changes」 ボタンををクリックするようなことなく、

即時反映されるようです。

 

Internal_App インターフェースの削除

curl -k -s -u admin:VMware1! -X DELETE https://192.168.110.15/api/4.0/edges/edge-2/vnics/3

 

Internal_DB  インターフェースの削除

curl -k -s -u admin:VMware1! -X DELETE https://192.168.110.15/api/4.0/edges/edge-2/vnics/4

 

API をコマンドラインで実行している様子です。

HoL なので「テキストの送信」(テキストをコンソールに送信)を使用しています。

hol-1603-mod2-04.png

 

ESG からインターフェースが削除されました。

hol-1603-mod2-05.png

 

そして、「3-Tier Web App」のテストページはエラーになります。

hol-1603-mod2-06.png

 

2. DLR に論理インターフェース(LIF)を構成。

 

この時点での、DLR のインターフェースの状態です。

まだ App 層、DB 層のネットワークに接続するインターフェースは作成されていません。

hol-1603-mod2-07.png

 

API では、下記のコマンドラインで確認できます。

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

 

DLR インターフェースを作成する API で指定する XML ファイル「dlr-if.txt」を作成します。

今回は、App_Interface、DB_Interface を同時に指定しています。

XML で指定している「virtualwire-3」と「virtualwire-4」は、それそれ App 層、DB 層のネットワークとして作成されている

論理スイッチの ID を指定しています。※先ほど ESG で確認したものを指定します。

cat <<EOF > dlr-if.txt

<interfaces>

  <interface>

    <name>App_Interface</name>

    <addressGroups>

      <addressGroup>

        <primaryAddress>172.16.20.1</primaryAddress>

        <subnetMask>255.255.255.0</subnetMask>

      </addressGroup>

    </addressGroups>

    <mtu>1500</mtu>

    <type>internal</type>

    <isConnected>true</isConnected>

    <connectedToId>virtualwire-3</connectedToId>

  </interface>

  <interface>

    <name>DB_Interface</name>

    <addressGroups>

      <addressGroup>

        <primaryAddress>172.16.30.1</primaryAddress>

        <subnetMask>255.255.255.0</subnetMask>

      </addressGroup>

    </addressGroups>

    <mtu>1500</mtu>

    <type>internal</type>

    <isConnected>true</isConnected>

    <connectedToId>virtualwire-4</connectedToId>

  </interface>

</interfaces>

EOF

 

DLR にインターフェースを追加します。

cat dlr-if.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-4/interfaces/?action=patch

 

インターフェースが追加されました。

hol-1603-mod2-08.png

 

ここまでで、App 層、DB 層での分散ルーティングが構成されます。

App 層の VM 「app-01a」 から DB 層の VM 「db-01a」 に Ping が飛ぶようになります。

※「DUP!」と出ることがあるのは HoL 特有の環境によるものです。

hol-1603-mod2-09.png

 

3. DLR で OSPF を構成。

 

ESG と DLR の間で動的ルーティングを構成するため、DLR に OSPF を有効化します。

 

まず、DLR に Router ID を設定します。

Router ID は、まだ未設定の状態です。

hol-1603-mod2-10.png

 

API での設定確認は、下記のコマンドラインで可能です。

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

 

API で指定する XML ファイル「rt-id.txt」 を作成しておきます。

cat <<EOF > rt-id.txt

<routingGlobalConfig>

  <routerId>192.168.5.2</routerId>

</routingGlobalConfig>

EOF

 

DLR に Router ID を設定します。

cat rt-id.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-4/routing/config/global

 

Router ID が 設定されました。

hol-1603-mod2-11.png


この時点の、DLR の OSPF 設定状態です。

hol-1603-mod2-12.png


DLR に OSPF の設定を投入する XML ファイル「dlr-ospf.txt」を作成しておきます。

ちなみに、この環境での DLR の Edge_Uplink インターフェースは vnic 2 で、

そこに OSPF エリア ID 10 を設定しています。

cat <<EOF > dlr-ospf.txt

<ospf>

  <enabled>true</enabled>

  <protocolAddress>192.168.5.3</protocolAddress>

  <forwardingAddress>192.168.5.2</forwardingAddress>

  <ospfAreas>

    <ospfArea>

      <areaId>51</areaId>

      <type>nssa</type>

      <authentication>

        <type>none</type>

      </authentication>

    </ospfArea>

    <ospfArea>

      <areaId>10</areaId>

      <type>normal</type>

      <authentication>

        <type>none</type>

      </authentication>

    </ospfArea>

  </ospfAreas>

  <ospfInterfaces>

    <ospfInterface>

      <vnic>2</vnic>

      <areaId>10</areaId>

      <cost>1</cost>

      <mtuIgnore>false</mtuIgnore>

    </ospfInterface>

  </ospfInterfaces>

  <redistribution>

    <enabled>true</enabled>

    <rules>

      <rule>

        <id>0</id>

        <from>

          <isis>false</isis>

          <ospf>false</ospf>

          <bgp>false</bgp>

          <static>false</static>

          <connected>true</connected>

        </from>

        <action>permit</action>

      </rule>

    </rules>

  </redistribution>

  <gracefulRestart>true</gracefulRestart>

</ospf>

EOF

 

DLR に OSPF を設定します。

cat dlr-ospf.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-4/routing/config/ospf

 

API 実行後の、DLR の OSPF 設定状態です。

hol-1603-mod2-13.png

 

4. ESG で OSPF の設定を修正。

 

この環境の ESG では、もともと OSPF が有効化されています。

この時点では、ESG が NSX 環境外部と接続する Uplink にだけ OSPF のエリア ID がマッピングされています。

ESG の DLR と通信するインターフェースに OSPF エリア ID を設定します。

hol-1603-mod2-14.png

 

HoL の環境で ESG むけの XML ファイル全体を作成するのは大変なので、

今回は ESG の現在の OSPF 設定を保存した XML ファイルに、(強引に)追加分の設定を追記します。

追加分の OSPF 設定の内容は下記で、OSPF の エリア ID 10 を、Transit_Network のインターフェースにマッピングしています。

<ospfInterface>

  <vnic>1</vnic>

  <areaId>10</areaId>

  <cost>1</cost>

  <mtuIgnore>false</mtuIgnore>

</ospfInterface>

 

コマンドラインで、ESG の OSPF 設定情報の XML を「esg-ospf_pre.txt」ファイルに保存して・・・

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/routing/config/ospf | xmllint --format - > esg-ospf_pre.txt

 

sed で、</ospfInterfaces> の前に今回設定したい XML 要素を追加して、「esg-ospf.txt」ファイルとして保存しています。

sed -e "s|</ospfInterfaces>|<ospfInterface><vnic>1</vnic><areaId>10</areaId><cost>1</cost><mtuIgnore>false</mtuIgnore></ospfInterface></ospfInterfaces>|" esg-ospf_pre.txt > esg-ospf.txt

 

そして、API で ESG に設定します。

cat esg-ospf.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/routing/config/ospf

 

ESG に、設定が反映されました。

hol-1603-mod2-15.png

 

これにより、ESG と DLR との間で OSPF による動的ルーティングが構成されました。

ESG に接続されている Web 層のネットワークと App 層のネットワークとが接続できるようになり、

手順の途中でエラーになっていたテストページも正常に表示できるようになります。

hol-1603-mod2-16.png

 

このように GUI(Web Client)から実施できる設定は、API からも可能です。

設定内容のわりに XML が大げさになることもある気がしますが、

API を利用して手順を自動化することで作業ミスの抑止などもできそうです。

 

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


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

$
0
0

これまで、VMware Hands-on Labs(HoL)で NSX API を試すポストをしてきました。

今回は、分散ファイアウォール(DFW)を、API で設定してみようと思います。

DFW の設定については、「HOL-SDC-1603 VMware NSX Introduction」の Module 3 シナリオをもとにしました。

 

VMware Hands-on Labs

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

 

同じく HOL-SDC-1603 をもとにした、以前のポストもどうぞ・・・

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

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

NSX API で NW 構成変更を体験してみる。Part 2(HOL-SDC-1603 Module 2 より)

 

NSX API ガイドは下記です。

 

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 のシナリオと同様の設定をしますが、グループオブジェクトの作成などは順番を工夫しています。

1 ~ 3 については、あとで FW ルールで指定するための準備です。

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

 

今回も、ラボの vCenter Server Appliance「vcsa-01a」の curl コマンドで、

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

 

Lab の初期状態。

 

設定変更前の Lab の環境について Web Client で状態確認しておきます。

「Default Section Layer3」セクションにある「Default Rule」が、この環境でデフォルトになる FW ルールです。

Action が「Allow」になっています。

hol-1603-mod3-p1-01.png

 

Web ブラウザで、「3-Tier Web App」のテストページが表示できます。

hol-1603-mod3-p1-02.png

 

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

hol-1603-mod3-p1-03.png

 

Security Group の作成。

 

ラボのシナリオでは、FW ルールでの送信元と送信元として、Security Group を指定しています。

そのため、FW ルール作成の準備として Security Group を作成しておきます。

 

「web-01a」、「web-02a」 という VM を含む、「Web-tier」という名前の Security Group を作成します。

今回は、Security Group の作成と、VM の追加を同時に実施します。

Security Group の設定を記載する XML では VM ID の指定が必要なので、

ここでは PowerCLI で確認しておきます。

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

PowerCLI> Get-VM web-0[12]a | sort Name | ft -AutoSize Name,Id

 

Security Group のメンバーにする VM のID がわかりました。

  • web-01a → vm-350
  • web-02a → vm-304

hol-1603-mod3-p1-04.png

 

XML ファイル(sg-web-tier.txt)を下記のように作成しておきます。

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

<securitygroup>

  <objectId />

  <objectTypeName>SecurityGroup</objectTypeName>

  <name>Web-tier</name>

  <description></description>

  <scope>

    <id>globalroot-0</id>

    <objectTypeName>GlobalRoot</objectTypeName>

  </scope>

  <member>

    <name>web-01a</name>

    <objectId>vm-350</objectId>

    <objectTypeName>VirtualMachine</objectTypeName>

  </member>

  <member>

    <name>web-02a</name>

    <objectId>vm-304</objectId>

    <objectTypeName>VirtualMachine</objectTypeName>

  </member>

</securitygroup>

EOF

 

下記のコマンドラインで、Security Group を作成します。

cat sg-web-tier.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @-  https://192.168.110.15/api/2.0/services/securitygroup/bulk/globalroot-0

 

実行すると、作成された Security Group の ID がわかります。

「Web-tier」は、securitygroup-10 として作成されました。

hol-1603-mod3-p1-05.png

 

Web Client からも確認できます。

Security Group は、ホームの「Network & Security」 → 「NSX Managers」 → NSX Manager(192.168.110.15)→

「Manage」 →「Grouping Objects」 →「Security Group」 で確認できます。

hol-1603-mod3-p1-06.png

 

つづく。

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

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

$
0
0

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

NSX API での 分散 FW 設定を体験してみる。Part 1 (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 ルールで通信許可のために指定する Service オブジェクトを作成します。

 

Service の作成

 

下記のサービスを作成します。

  • サービス名: MyApp
  • プロトコル: TCP
  • ボート番号: 8443

 

サービスの設定を記載した XML ファイルを作成します。

API ガイドをもとにすると、下記のような XML になりますが・・・

<application>

  <objectId></objectId>

  <type>

    <typeName/>

  </type>

  <description></description>

  <name>MyApp</name>

  <revision>0</revision>

  <objectTypeName></objectTypeName>

  <element>

    <applicationProtocol>TCP</applicationProtocol>

    <value>8443</value>

  </element>

</application>

 

今回は、デフォルト値でよいものは省略して、下記のように XML ファイルを作成しました。

cat <<EOF > app-myapp.txt

<application>

  <name>MyApp</name>

  <description/>

  <element>

    <applicationProtocol>TCP</applicationProtocol>

    <value>8443</value>

  </element>

</application>

EOF

 

作成した XML ファイルをもとに、API でサービスを作成します。

サービスは、API では「Application」 として扱われています。

cat app-myapp.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @-  https://192.168.110.15/api/2.0/services/application/globalroot-0

 

「MyApp」 サービスが、「application-371」 という ID で作成されたことがわかります。

hol-1603-mod3-p2-01.png

 

Web Client でも、サービスが作成されたことが確認できます。

サービスは、ホームの「Network & Security」 → 「NSX Managers」 → NSX Manager →

「Manage」 →「Grouping Objects」 →「Service」 で確認できます。

hol-1603-mod3-p2-02.png

 

つづく。

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

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

$
0
0

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

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 より)

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

$
0
0

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

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 5 (HOL-SDC-1603 Module 3 より)

$
0
0

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

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 6 (HOL-SDC-1603 Module 3 より)

$
0
0

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

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 を設定してみる話でした。

Python で vSphere を操作できるようにする。(pyvmomi)

$
0
0

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 に接続してみる話でした。


SQL Server on Virtual SAN Stretched Cluster – FTT1 versus RAID0 with AlwaysOn

$
0
0

Virtual SAN Stretched Cluster provides an option for users to build SQL Server application across two sites that are connected through a high bandwidth and low latency link, or makes active-active data centers possible.  Stretched Cluster enables automatic handling of either active/active site failure, or network failure link failing between the sites. If one site fails, data on the other site is up to date and continues to be served.

SQL Server, as one of the major products in the global DBMS market, also provides the function named AlwaysOn Availability Group which relies on the multiple database copies to serve the application continuously when the primary database service is interrupted.

Although the two business continuity technology can co-exist, implementing them together means more space usage: using FTT1 with AlwaysOn means 4x space usage for one database set.

We measured and compared the configuration of FTT1 over Virtual SAN Stretched Cluster and the configuration of RAI0 with AlwaysOn database availability group (AAG) across the two sites from the resource consumption, performance, serviceability on the site failure perspectives.

We deployed Virtual SAN Stretched Cluster with three sites: Site A and B has two ESXi hosts with 2ms inter-site delay and a witness appliance in a third site which has 200ms network latency to the two sites, for above measurement purpose.

 

figure1-ftt1.pngfigure2-alwayson.png

 

Figure 1. SQL Server database over Virtual SAN Stretched Cluster (FTT1)

Figure 2. SQL Server AlwaysOn Availability Group over Virtual SAN Stretched Cluster (FTT0 or RAID0)

  

Dell PowerEdge R630 VMware All-Flash Virtual SAN Specifications

  • Dell PowerEdge R630
  • CPUs: Two 24-core Intel(R) Xeon(R) CPU E5-2670 @ 2.3GHz v3
  • Memory: 256GB DDR4 RDIMM
  • SSD: 2 x 400GB Solid State Drive (SSDSC2BA40) as Cache SSD
  • SSD: 8 x 400GB Solid State Drive (SSDSC2BX40) as Capacity SSD
  • Networking: 2 x Intel 10 Gigabit X540-AT2, + I350 1Gb Ethernet
  • Storage Raw Capacity: 11.88TB

SQL Server Testing Configuration (per VM)

  • Windows Server 2012 R2
  • SQL Server 2014 Enterprise Edition, SP1
    • Database Size: 20 scale
    • RAM: 80GB
    • Buffer Pool: 48GB
    • CPU: 24

Resource consumption

For a virtual machine with a single user database to be deployed on the Virtual SAN, if you want to deploy the VM with the single database with FTT1, the storage consumption is 2x; if you want to deploy AlwaysOn Availability Group (two replicas) with FTT0 or RAID0, the storage consumption is 2x too. But AlwaysOn Availability Group with FTT0 or RAID0 needs another virtual machine, generally having identical configuration (vCPU/Memory) to guarantee the performance be kept the same level after AlwaysON failover to the secondary replica.

Performance

We measured a 200GB TPC-E like database workload on the two configurations on the Virtual SAN Stretched Cluster. This test used SQL Server 2014 Enterprise Edition running on Windows Server 2012 R2 guest VMs, being stressed by Dell's Benchmark Factory for Databases. Each test used new restored database. The preconditioning duration is 15 minutes and the sampling duration was 45 minutes.

In FTT1 scenario, 4-node cluster is split into two sites and one site hosts the 200GB database, and in the RAID 0 & AlwaysOn scenario, 4-node cluster also is split into two sites with each site hosting one virtual machine and one database. The AlwaysOn Availability Group used the synchronous mode to allow automatic failover happened when the primary database virtual machine cannot work.

We measured 1958 TPS in the single database (FTT1) scenario, comparing with 1633 in the RAID 0 & AlwaysOn scenario. As for the response time, they are 6-7 milliseconds. But FTT1 can achieve better transaction time which was 34ms but in the RAID 0 & AlwaysOn scenario the Average transaction time was 42ms due to the log transferring and hardening on the secondary database.

Scenarios

TPS

Average Response time (ms)

  1. Avg. Transaction time(ms)

FTT1

1958

7

34

RAID 0 & AlwaysOn

1633

6

42

The variable we pay the most attention to is average disk latency. We measured the average data and log disk write latency 4ms and 8ms in the FTT1 scenario and 15ms for data and log all in the RAID 0 & AlwaysOn scenario. For the most of the mission critical databases, using FTT1 can achieve better application response time and can satisfy the DBA’s requirement to the I/O subsystem.

 

 

Recovery duration from disaster on the production site

  Single database deployment (FTT1) cannot rely on the multiple database copies to recover the service of the database quickly. It needs the vSphere HA to reboot the virtual machine as well as the database service on another site.  The duration can often be a few minutes to finish, while AlwaysOn Availability Group needs 1-2 seconds to fail over the database (change the role of the secondary to primary)

SQL Server on All-Flash Virtual SAN – update from the RA trenches

$
0
0


Over the past few months we have been working on SQL Server 2014 on Virtual SAN and I just wanted to peep my head out and give our customers and partners an update.

First of all, if you aren’t running SQL Server on Virtual SAN yet then let me give you 3 reasons why you might want consider it. #1, 50% Lower TCO overall by deploying SQL Server on inexpensive industry-standard server components to remove large, upfront investments. Further improve TCO with storage efficiency features like deduplication and enhanced automation capabilities.  #2, Virtual SAN delivers enterprise availability for the most demanding business critical applications, capable of delivering 99.999% uptime and beyond with built-in and tunable failure tolerance settings. #3, Virtual SAN provides the simplicity of managing storage along with compute and networking in a single, tightly integrated interface--the vSphere Web Client.

In Virtual SAN 6.2 we introduced key space efficiency features such as Deduplication, Compression, and Erasure Coding (RAID5/6). During our testing one of our goals was to drive OLTP workload and test performance with the new space savings enabled. Using a four node All Flash cluster with (4) SQL Servers 2 database sizes were used; (2) 200GB and (2) 500GB. To drive the workload we used Benchmark Factory’s TPC-E. During our tests, four virtual machines on a four node All-Flash SAN cluster can consistently achieve the aggregate TPS (transactions per second) up-to 8079 (deduplication/compression enabled Virtual SAN), and can achieve predictable virtual disk latency ranging from 1ms to 2ms for read and write on average.  That means with all of the space efficiency features of Virtual SAN 6.2 enabled VSAN provides great performance with minimal impact.

blog1-1.png

 

Looking specifically at space savings within a SQL Server environment in the chart below starting with a baseline of 5TB of data and by enabling Deduplication and compression the data size was reduced to 2.2TB which is a space savings of 56%. Then we enabled Erasure Encoding (RAID5) this reduced the data to 1.9TB and we observed a savings of up-to 62%.

 

blog1-2.png

Virtual SAN is optimized for modern all-flash storage with efficient near-line deduplication, compression, and erasure coding capabilities that lower TCO while delivering incredible performance. Virtual SAN 6.2 is ready for any application with tested and validated deployments of Microsoft SQL Server. The Reference Architecture will be ready within weeks. 

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

$
0
0

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 のデプロイ)

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

$
0
0

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 の API 操作を体験してみる。Part 3(One-Arm LB の設定)

$
0
0

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 メンバのステータス確認)


Viewing all 3135 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>