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.

こんにちは。 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

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

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

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 を利用した仮想マシンの選択

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

上記の方法はプラグイン (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. ブロックされたコンテンツを有効にします。

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

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

この他の 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 では、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 です。

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

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

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

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 で表示されます。

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

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

論理スイッチの作成

「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

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

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

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

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

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

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 が配置されています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以前に、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 アドレスです。

手順の流れ

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

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

ファイルを読み込んで、論理スイッチを作成する 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 で、論理スイッチが作成されました。

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 だとわかります。

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

論理スイッチに 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

4. 設定の確認。

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

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

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

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

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 体験でした。

こんにちは。 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 を起動します。

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

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

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

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

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

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

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

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

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

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

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

最近、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 アドオンが利用可能になっています。

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

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

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

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

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

Content-Type を設定します。

Name： Content-Type
Value： application/xml

あとはラボマニュアルや 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 の指定が不要なので空欄のまま。

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

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

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

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

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

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

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

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

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

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

前回、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」

手順の流れ。

ESG からインターフェース削除。
DLR に論理インターフェース（LIF）を構成。※App 層、DB 層の間の分散ルーティングを可能にします。
DLR で OSPF を構成。
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 が構成されています。

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

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 なので「テキストの送信」（テキストをコンソールに送信）を使用しています。

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

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

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

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

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

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

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

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

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

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

3. DLR で OSPF を構成。

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

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

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

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 が設定されました。

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

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 設定状態です。

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

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

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

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

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 に、設定が反映されました。

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

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

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

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

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

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

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

これまで、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 ルールで指定するための準備です。

Security Group の作成。 ★今回はここまで。
Service の作成。
オブジェクト ID の確認。
デフォルトの FW ルールを Allow → Block に変更。
FW ルールセクションの作成。
セクションに 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」になっています。

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

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

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

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 として作成されました。

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

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

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

つづく。

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

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

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 を実行しています。

手順の流れ。

Security Group の作成。
Service の作成。 ★ここ
オブジェクト ID の確認。
デフォルトの FW ルールを Allow → Block に変更。
FW ルールセクションの作成。
セクションに 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 で作成されたことがわかります。

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

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

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

つづく。

NSX API での分散 FW 設定を体験してみる。Part 3 （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 を実行しています。

手順の流れ。

Security Group の作成。
Service の作成。
オブジェクト ID の確認。 ★ここ
デフォルトの FW ルールを Allow → Block に変更。
FW ルールセクションの作成。
セクションに 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

論理スイッチ 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

セキュリティグループ 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-」がつきます。

サービス 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

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 だということがわかります。

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 だとわかります。

つづく・・・

NSX API での分散 FW 設定を体験してみる。Part 4 （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 を実行しています。

手順の流れ。

Security Group の作成。
Service の作成。
オブジェクト ID の確認。
デフォルトの FW ルールを Allow → Block に変更。★ここ
FW ルールセクションの作成。
セクションに 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

今回は、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 になったことが確認できます。

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

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

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

つづく。

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

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

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 を実行しています。

手順の流れ。

Security Group の作成。
Service の作成。
オブジェクト ID の確認。
デフォルトの FW ルールを Allow → Block に変更。
FW ルールセクションの作成。 ★ここ
セクションに 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 で作成されました。

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

この状態で、次回の投稿で 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 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 を実行しています。

手順の流れ。

Security Group の作成。
Service の作成。
オブジェクト ID の確認。
デフォルトの FW ルールを Allow → Block に変更。
FW ルールセクションの作成。
セクションに 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 ルールの順序。

EXT to Web
Web to App
App to Database

FW ルールの作成順序。

App to Database
Web to App
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

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

確認

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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%.

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）を 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回に分けて投稿します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つづく。

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

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

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

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

手順について。

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

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

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

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

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

リソースプール（クラスタ）： Management & Edge Cluster

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

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

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

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

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

フォルダ： Edges

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

論理スイッチの 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

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 としてデプロイされました。

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

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

デフォルトトラフィックポリシー：承諾（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

設定変更されました。

つづく。

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

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

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

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

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

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

手順について。

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

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

1. LB の有効化

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

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

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 が有効な状態になりました。

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 として作成されました。

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」に変更します。

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

設定変更されました。

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 です。

作成したプールは、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

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

下記の 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...」のテストページが表示できるようになります。

つづく。

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

VMware AppVolume – Troubleshooting

App Volumes Manager logs :

App Volumes Agent log files :

Here are details about Agent log files:

svservice.log:

svcapture.log:

svdriver.log:

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

PowerCLI のインストール

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

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

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

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

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

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

利用方法

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

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

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

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

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

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

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

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

Python で vSphere を操作できるようにする。（pyvmomi）

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

Dell PowerEdge R630 VMware All-Flash Virtual SAN Specifications

SQL Server Testing Configuration (per VM)

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

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.

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

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

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

App Volumes Manager logs :

App Volumes Agent log files :

Here are details about Agent log files:

svservice.log:

svcapture.log:

svdriver.log:

PowerCLI のインストール

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

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

利用方法

Dell PowerEdge R630 VMware All-Flash Virtual SAN Specifications

SQL Server Testing Configuration (per VM)

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.

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