Skip navigation

今回は、 NSX 環境に設定されたルーティングを PowerNSX / PowerCLI で見てみます。

 

自宅環境の都合上 NSX Edge をたくさん並べるのが困難なので、

OSPF などのルーティングプロトコルは動作させていません。

単純に Edge Service Gateway(ESG)1台、DLR Control VM 1 台がある、なんとか NSX っぽい構成にしてあります。

この環境で、NSX で管理されている NSX Edge のルーティング(赤枠のフキダシ)を PowerNSX で確認してみます。

nsx-edge-route.png

 

まず vSphere Web Client でルーティング設定を見てみます。

 

NSX Edge が2台あります。

このあと ID を指定するため、ESG は edge-1、DLR Control VM は edge-5 であることをおぼえておきます。

nsx-edge-rt-00.png

 

ESG の NSX Edge です。インターフェースが 2つ作成されています。

nsx-edge-rt-01.png

 

「if-uplink」という名前の インターフェースの方向にゲートウェイを設定していますが、

これはインターネットなど、NSX 外部に接続するルータのアドレスを指定しています。

nsx-edge-rt-02.png

 

NSX のラボ環境むけに、スタティック ルートは DLR のアップリンクにむけて設定しています。

nsx-edge-rt-03.png

 

DLR Control VM の NSX Edge です。

ESG でスタティックルートをむけているアップリンクのほかに、

いくつか内部インターフェースを作成して、論理スイッチを接続しています。

nsx-edge-rt-04.png


DLR では、デフォルト ゲートウェイを ESG のインターフェースにむけています。

nsx-edge-rt-05.png

 

PowerNSX で見ると、こんな感じです。

あらためて、ESG と、DLR の Object ID を確認しておきます。

ESG は edge-1、DLR は edge-5 です。

PowerCLI C:\> Get-NsxEdge | fl id,name,type

 

id   : edge-1

name : nsxesg01

type : gatewayServices

 

 

PowerCLI C:\> Get-NsxLogicalRouter | fl id,name,type

 

 

id   : edge-5

name : nsxdlr01

type : distributedRouter

 

 

ESG のスタティックルートの設定確認については、わかりやすいコマンドレットが用意されています。

今回は DLR にはスタティックルートを設定していないのですが、DRL にも同様に、

Get-NsxLogicalRouterRouting、Get-NsxLogicalRouterStaticRoute  が用意されています。

PowerCLI C:\> Get-NsxEdge -objectId edge-1 | Get-NsxEdgeRouting | Get-NsxEdgeStaticRoute

 

 

mtu           : 1500

description   :

type          : user

vnic          : 1

network       : 10.0.0.0/8

nextHop       : 10.1.1.2

adminDistance : 1

edgeId        : edge-1

 

 

一方、デフォルトゲートウェイ(というかデフォルト ルート)の設定確認については、ちょっと工夫がいりそうな雰囲気です。

ESG の デフォルト ルートを見てみましたが、「select -ExpandProperty」でけっこう深くたどりました。

PowerCLI C:\> Get-NsxEdge -objectId edge-1 | Get-NsxEdgeRouting | select -ExpandProperty staticRouting | select -ExpandProperty defaultRoute | select gatewayAddress

 

gatewayAddress

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

192.168.1.1

 

 

DLR のデフォルト ルートの確認も同様に、シンプルなコマンドレットでというわけでなないようです。

PowerCLI C:\> Get-NsxLogicalRouter -objectId edge-5 | Get-NsxLogicalRouterRouting | select -ExpandProperty staticRouting | select -ExpandProperty defaultRoute

 

 

 

mtu  gatewayAddress adminDistance

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

1500 10.1.1.1       1

 

 

 

PowerNSX には、XPath のクエリをあつかうコマンドレット(Invoke-XpathQuery)も用意されています。

実はこの情報は XmlElement なので、そちらを使ってしまったほうがシンプルかもしれません。

PowerCLI C:\> $r = Get-NsxLogicalRouter -objectId edge-5 | Get-NsxLogicalRouterRouting

PowerCLI C:\> Invoke-XpathQuery -QueryMethod SelectNodes -Node $r -query "//gatewayAddress"

 

#text

-----

10.1.1.1

 

 

このように、PowerNSX でも vSphere Web Client と同様に

NSX Edge のルーティング 情報を取得することが(そして設定することも)できます。

一方 NSX で管理されていない、 NSX Edge 以外のルーティングは、

基本的には個別に ログインしたりして確認することになります。

 

ただし、VMware Tools がインストールされている ゲスト OS であれば、

PowerCLI から取得できたりします。

PowerCLI C:\> Get-VM vm01 | Get-VMGuest | % {$_.ExtensionData.IpStack.IpRouteConfig.IpRoute | select Network,PrefixLength,@{N="Gateway";E={$_.Gateway.IpAddress}}}

 

 

Network   PrefixLength Gateway

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

0.0.0.0              0 10.1.10.1

10.1.10.0           24

10.1.10.1           32

fe80::              64

 

 

以上、最近のほかの投稿の参考情報として、自宅 NSX のルーティングの様子を投稿してみました。

PowerNSX で、NSX vor vSphere 環境を操作するときには、まず Connect-NsxServer で接続します。

接続先の指定方法はいろいろあり、たとえば下記のようなパターンがあります。

  • vCenter を指定(-vCenterServer)して、NSX Manager にも自動接続。
  • vCenter 接続(Connect-VIServer)しておき、NSX Manager にあとから接続する。
  • NSX Manager と、vCenter を両方指定して接続する。
  • NSX Manager だけに接続する。(-DisableVIAutoConnect)

 

これまでは、NSX Manager のアドレスを指定して、NSX Manager のローカルユーザで

ログインする接続方法がとられていたようですが、

今後は、基本的に 「vCenter を指定して、NSX Manager にも自動接続」の接続が推奨されるようです。

vSphere Web Client で NSX(Network and Security 画面)を操作するときと同様、

利用者が明示的に指定するのは vCenter のアドレスだけで十分となります。

そして、その時のログインは vCenter Single Sign-On(vCenter SSO)のユーザを使用します。

 

現時点のバージョンの PowerNSX では、下記のように「-vCenterServer」で vCenter を指定してログインします。

PowerCLI> Connect-NsxServer -vCenterServer <vCenter のアドレス>

 

Connect-NsxServer で NSX 環境に接続。

下記のように Connect-NsxServer を実行することで、vCenter と NSX Manager に接続できます。

※1行目は、証明書の警告を抑止するため実行しています。

※「vc-sv02.go-lab.jp」は、うちの vCenter です。

PowerCLI C:\> Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Scope Session -Confirm:$false

PowerCLI C:\> Connect-NsxServer -vCenterServer vc-sv02.go-lab.jp

 

ユーザ / パスワードの入力画面が表示されるので、

vCenter (vCenter SSO)のユーザでログインすると NSX Manager に接続できていることがわかります。

今回は PowerCLI のウインドウから実行していますが、PowerShell のプロンプトからでも実行可能です。

conn-nsx-01.png

 

vCenter の接続

PowerCLI C:\> $global:DefaultVIServer | fl Name,Version,Build,User,ISConnected


Name        : vc-sv02.go-lab.jp

Version     : 6.5

Build       : 5318154

User        : GO-LAB\gowatana

IsConnected : True

 

NSX Manager の接続

※「192.168.1.141」は、今回の NSX Manager(nsxmgr01)の IP アドレスです。

PowerCLI C:\> $DefaultNSXConnection

 

 

Version             : 6.3.1

BuildNumber         : 5124716

Credential          : System.Management.Automation.PSCredential

Server              : 192.168.1.141

Port                : 443

Protocol            : https

ValidateCertificate : False

VIConnection        : vc-sv02.go-lab.jp

DebugLogging        : False

DebugLogfile        : C:\Users\gowatana\AppData\Local\Temp\PowerNSXLog-gowatana@-2017_07_04_23_44_35.log

 

 

今回は、NSX Manager で vCenter / vCenter SSO 連携を設定ずみです。

※下記にはありませんが、NSX のロール割り当ても設定ずみです。

※ちなみにうちの vCenter SSO では、LDAP を ID ソースにしていています。

PowerCLI C:\> Get-NsxManagerVcenterConfig | fl ipAddress,userName,Connected

 

 

ipAddress : vc-sv02.go-lab.jp

userName  : nsx-admin@go-lab.jp

Connected : true

 

 

PowerCLI C:\> Get-NsxManagerSsoConfig | fl ssoLookupServiceUrl,ssoAdminUsername,Connected

 

 

ssoLookupServiceUrl : https://vc-sv02.go-lab.jp:443/lookupservice/sdk

ssoAdminUsername    : nsx-admin@go-lab.jp

Connected           : true

 

 

 

NSX Manager を直接指定した接続。

NSX Manager を「-Server」で指定して接続する方法も将来的に廃止されて

super_user 権限が必要な場合は「-NsxServer」で NSX Manager を指定して

admin ユーザでログインすることになります。

 

たとえば、vCenter に接続しないで NSX Manager だけに admin ユーザで接続する場合は

下記のような感じになります。

conn-nsx-02.png

 

一方、「-Server」で NSX Manager を指定して接続すると、接続は可能ですが警告が表示されます。

conn-nsx-03.png

 

今回の PowerCLI / PowerNSX のバージョン。

今回の PowerNSX は、下記のバージョンでした。

PowerCLI C:\> Get-PowerNsxVersion | select Version

 

 

Version

-------

3.0.0

 

 

依存関係がある PowerCLI のモジュールのバージョンは下記です。

PowerCLI C:\> Get-Module VMware.VimAutomation.Core,VMware.VimAutomation.Vds | select Name,Version

 

 

Name                      Version

----                      -------

VMware.VimAutomation.Core 6.5.0.2604913

VMware.VimAutomation.Vds  6.5.0.4624695

 

 

以上、PowerNSX の接続方法についての話でした。

NSX for vSphere の分散ファイアウォール(DFW)のログを vRalize Log Insight(vRLI)で見てみます。

今回は、前回のインタラクティブ分析の状態をもとにカスタム ダッシュボードを作成してみます。

 

利用している環境については下記をどうぞ。

vRealize Log Insight と NSX DFW で通信の様子を可視化してみる。Part.1

 

前回のインタラクティブ分析の様子は下記をどうぞ。

vRealize Log Insight と NSX DFW で通信の様子を可視化してみる。Part.2

 

対象の VM を通信元、通信先 とした通信を確認できるダッシュボードを作成してみます。

ざっくり「10.1.30.*」を通信元、通信先としているものだけ絞って見ます。

 

カスタム ダッシュボードの作成。

まず、対象サーバ宛の通信許可ログを表示するチャートをダッシュボードに追加します。

ダッシュボードに追加するチャートを表示した「インタラクティブ分析」の画面で、

「現在のクエリをダッシュボードに追加」をクリックします。

vrli-dfw-2-3-01.png

 

名前には「サーバ宛の通信」を入力し、「ダッシュボード」で「新規ダッシュボード」を選択します。

(とはいっても今回のチャートでは、表示されるのはサーバ宛通信の pass ログです。)

vrli-dfw-2-3-02.png

 

新規ダッシュボードの名前として、「10.1.30.* の通信」と入力して「保存」します。

vrli-dfw-2-3-03.png

 

名前と、ダッシュボードが選択された状態になるので、「追加」をクリックします。

vrli-dfw-2-3-04.png

 

次に、対象サーバを通信元とした通信許可ログを表示するチャートをダッシュボードに追加します。

フィルタ設定の「vmw_nsx_firewall_dst」フィールドを「vmw_nsx_firewall_src」に変更してチャートを表示してから

「現在のクエリをダッシュボードに追加」をクリックします。

vrli-dfw-2-3-05.png

 

名前は「サーバからの通信」として入力し、

ダッシュボードは先ほど新規作成した「10.1.30.* の通信」を選択して「追加」します。

vrli-dfw-2-3-06.png

 

そして「ダッシュボード」を開くと・・・

vrli-dfw-2-3-07.png

 

カスタム ダッシュボードのマイダッシュボード配下に、

先ほど作成した「10.1.30.* の通信」ダッシュボードが追加されています。

vrli-dfw-2-3-08.png

 

ダッシュボード レイアウトのカスタマイズ。

作成したダッシュボードのレイアウトを変更します。

ダッシュボードに追加したチャート(ウィジェット)は、ドラッグ アンド ドロップで移動できます。

vrli-dfw-2-3-09.png

 

ウィジェットの右端にカーソルをおくと、展開することができます。

vrli-dfw-2-3-10.png

 

それぞれ見やすくなるように、ウィジェットを展開しました。

vrli-dfw-2-3-11.png

 

「カスタムの期間」で、チャートの表示期間を変更することができます。

vrli-dfw-2-3-13.png

 

そして、ここにあるチャートの「インタラクティブ分析 を開く」ボタンをクリックすると・・・

vrli-dfw-2-3-14.png

 

チャート表示のためのフィルタを設定した状態で、インタラクティブ分析を開くことができます。

vrli-dfw-2-3-15.png

 

このように、特定の通信の様子を簡単に確認できるダッシュボードを作成しておくことができます。

 

まだ続くかもしれない・・・

NSX for vSphere の分散ファイアウォール(DFW)のログを利用して、

vRalize Log Insight(vRLI)で通信を可視化してみます。

今回は、インタラクティブ分析 利用してログを可視化してみます。

 

この投稿の環境は、このようになっています。

vRealize Log Insight と NSX DFW で通信の様子を可視化してみる。Part.1

 

それでは、「インタラクティブ分析」の画面を開きます。

既存のダッシュボードに、すでによさそうな情報をもつチャートがある場合は、

そのチャートの「インタラクティブ分析 で開く」ボタンから、

チャートを表示しているフィルタ設定が適用された分析画面を開くことができます。

 

今回はシンプルなフィルタ操作をするだけなので、

画面上部の「インタラクティブ分析」から開いてもかまいません。

vrli-dfw-2-2a-01.png

 

DFW の通信についてのログは、ESXi の dfwpktlogs.log に出力されます。

インタラクティブ分析で DFW のログを解析するときは、

「フィルタの追加」で下記のフィルタを設定することで抽出できます。

  • フィールドは「appname」
  • 条件は「次を含む」で「dfwpktlogs」を入力する。

今回は pass のログだけ見るので、下記のフィルタも追加します。

  • フィールドは「vmw_nsx_firewall_action」
  • 条件は「次を含む」で「pass」を入力する。

 

そして対象の通信を探すためには、「text」として IP アドレスを検索することで抽出できます。

ログのテキスト全体からからIP アドレスの文字列を検索するので

送信元、送信先にかかわらず関係するログを抽出できます。

※ただし、今回に限っては分析対象にかかわるログしか表示されないので意味がないです。

 

ログを検索する期間は「カスタムの期間」を選択して、

任意の 開始 / 終了 時間を入力しておきます。

vrli-dfw-2-2a-02.png

 

通信確認の対象とする VM 同士の通信を見てみます。

通信元、通信先の IP アドレスを、両方「10.1.30.*」にして検索してみます。

 

vRLI の NSX for vSphere コンテンツパックで利用可能になるフィールドには、

Edge Firewall のものと、Distributed Firewall のものがありますが、

今回は Edge Firewall を使用していないので「edge」とつかないフィールドをフィルタに利用しています。

たとえば下記のような感じです。

 

通信元をあらわす「src」には 2 つのフィールドがありますが、
vmw_nsx_edge_firewall_src ではなく、
vmw_nsx_firewall_src  をフィルタに指定しておきます。

vrli-dfw-2-2a-03.png

 

通信先(dst)のフィールドは、通信元よりも多く用意されています。

ここではまず「vmw_nsx_firewall_dst」を選択しておきます。

vrli-dfw-2-2a-04.png

 

検索結果のグループ化の設定をします。

まずは、下記のようにして「適用」をクリックします。

  • 時系列 を選択
  • vmw_nsx_firewall_dst_ip_port を選択
  • vmw_nsx_firewall_protocol を選択 ※これで tcp / udp が判別できます。
  • vmw_nsx_firewall_src を選択

vrli-dfw-2-2a-05.png

 

結果として、下記のようなチャートが表示されました。

フィルタ、グループ化 の設定により、対象の VM 同士で

どのような通信が発生しているか可視化できました。

※チャートの凡例は「宛先 IP/ポート番号, 元 IP, プロトコル」となっています。

vrli-dfw-2-2a-06.png

 

ちょっと雑多な感じがしますが、

グループ化の条件を減らすことで、傾向を把握しやすくすることもできます。

  • vmw_nsx_firewall_dst_port ※宛先はIPをなくしてポートだけにする。
  • vmw_nsx_firewall_protocol

vrli-dfw-2-2a-07.png

 

グループ化がを「適用」すると、通信のプロトコルとポート番号だけのサマリがわかります。

vrli-dfw-2-2a-08.png

 

グループ化はそのままで、

対象 VM の IP 以外からの通信も含めたチャートを表示

(vmw_nsx_firewall_src フィールドによるフィルタを削除)してみました。

対象 VM 以外の アドレス(論理スイッチ外)からだと、

SSH(tcp, 22)や HTTP(tcp, 80)の通信があったことがわかります。

vrli-dfw-2-2a-09.png

 

うまく利用すれば、ファイアウォール ルールの検討などにも役立ちそうです。

なお、ここでは vRealize Log Insight を利用してみましたが、こういった分析は

製品としては vRealize Network Insight のほうが向いていると思います。

Software-Defined Networking 向け vRealize Network Insight: VMware

 

ちなみに、今回のログは Docker Swarm を構成している VM の状況をログ取得してみました。

まず、Docker Swarm 構成前に、論理スイッチより外の踏み台サーバから SSH 接続をしています。

最初の Swarm クラスタ構成のタイミングで TCP 2377 番ポート、UDP 7946 番ポートの通信が発生しています。

コンテナを起動したところで TCP 80 番ポート、UDP 4789 番ポートの通信が発生している様子が見られます。

 

つづく。

vRealize Log Insight と NSX DFW で通信の様子を可視化してみる。Part.3

NSX for vSphere の分散ファイアウォールでは、許可された通信のログを出力することができます。

そこで、特定の対象の通信をすべて許可するルールを作成して、

vRalize Log Insight(vRLI)で通信を可視化してみます。

 

今回の構成概要です。

ひとつの論理スイッチに接続された 3つの VM で、どのような通信が発生しているかを見てみます。

通信を確認する対象として VM を3台用意していますが、それらはすべて「ls-tenant-03」という

NSX 論理スイッチに接続しています。

DFW で許可された通信は「pass」として ESXi のログファイルに出力されるので、

それを vRLI に Syslog 転送しています。

vrli-dfw-story2-pass.png

 

今回の製品構成は、以前に投稿した下記と同様です。

vRealize Log Insight で NSX DFW の Drop を確認してみる。Part.1

 

分散ファイアウォールに許可ルールを追加してあります。

  • すべての通信を許可するかわりに、適用先を論理スイッチ「ls-tenant-03」に絞っています。
  • ルール ID は、1095 です。

vrli-dfw-2-1-01.png

 

このルールは「ログを記録」に変更してあります。

vrli-dfw-2-1-02.png

 

「ls-tenant-03」には、通信を見る対象にする VM 3台だけが接続されています。

vrli-dfw-2-1-03.png

 

それぞれの VM には、10.1.30.0/24 の IP アドレスが付与されています。

vrli-dfw-2-1-04.png

 

すでに、それぞれの VM からは通信が発生している状態です。

「Distributed Firewall - Overview」ダッシュボードで、

ルール ID 1095 にヒットして、通信が許可されている(pass している)ことがわかります。

ちなみに今回の環境では、ID 1095 のルールのみで「ログの出力」をしているので、

対象の VM にまったく関係しない通信ログは出力されません。

vrli-dfw-2-1-05.png

 

「Distributed Firewall - Traffic」ダッシュボードを見ると、受信したログの

通信の、通信元 / 先 の IP アドレス、宛先ポート番号がわかります。

「Firewall top sources」には、期待どおり 10.1.30.100 ~ 10.1.30.102 が表示されています。

vrli-dfw-2-1-06.png

 

この受信したログを、インタラクティブ分析で見てみます。

 

つづく・・・

vRealize Log Insight と NSX DFW で通信の様子を可視化してみる。Part.2

これまでの投稿にひき続き、NSX for vSphere の 分散ファイアウォール(DFW)の様子を、

vRealize Log Insight(vRLI)を利用して見てみます。

 

これまでで Drop のログを見てみたので、今回は DFW で通信が許可される様子を見てみようと思います。

ただし、システム負荷への考慮などにより、通常はファイアウォールの通信許可ログを定常取得することは少ないと思います。

ここでは DFW の様子見を目的として、あえて許可ルールのログを有効にしています。

 

この投稿での利用製品バージョンや環境については下記をご覧ください。

vRealize Log Insight で NSX DFW の Drop を確認してみる。Part.1

vRealize Log Insight で NSX DFW の Drop を確認してみる。Part.2

vRealize Log Insight で NSX DFW の Drop を確認してみる。Part.3

 

テスト用の通信を発生させる。

まず意図的に、現状だと Drop される通信を発生させます。

前回同様、curl で vm01(10.1.10.101)から ext-vm01(192.168.1.223)の 80 番ポートへひたすらアクセスします。

そして、期待どおり DFW により通信できない状態です。

root@vm01 [ ~ ]# while :; do curl --connect-timeout 1 192.168.1.223:80; sleep 2; done

curl: (28) Connection timed out after 1001 milliseconds

curl: (28) Connection timed out after 1001 milliseconds

curl: (28) Connection timed out after 1001 milliseconds

curl: (28) Connection timed out after 1001 milliseconds

(以下略・・・)

 

ただ、許可ルールが適用されると標準出力が多くなるので、

コマンドラインは下記のような感じでもよいかもしれません。

root@vm01 [ ~ ]# while :; do curl -s --connect-timeout 1 192.168.1.223:80; sleep 2; done > /dev/null

 

vRLI ダッシュ―ボードの準備。

vRLI のダッシュボードを見てみます。

まず 「Distributed Firewall - Traffic」ダッシュボードです。

  • 10.1.10101 から
  • 192.168.1.223 への
  • (TCP の)80 番ポート 宛

の通信が Drop されている様子がわかります。

vrli-dfw-04-01.png

 

そして、「Distributed Firewall - Overview」ダッシュボードを見ます。

ずっと curl を実行しているので、「Firewall actions」チャートで drop 一定量あがり続けています。

ここで、右上のボタンで「プレゼンテーション モード」を開始しておきます。

vrli-dfw-04-02.png

 

プレゼンテーション モード がオンになりました。

画面がリアルタイム更新されるので、ここで DFW のルールが反映される様子を見てみます。

vrli-dfw-04-03.png

 

DFW での許可ルール追加。

vSphere Web Client で、vm01(10.1.10.101)→ ext-vm01(192.168.1.223)への、

HTTP サービス(TCP 80 番)を許可するルールを追加します。

今回は、ルール ID 1094 でルールが作成されました。

作成したルールの「操作」列の編集ボタンをクリックして・・・

vrli-dfw-04-04.png

 

あえて許可ルールで通信がとおったログを出力するため、

「ログに記録」を選択・保存したうえで「変更の発行」をクリックします。

vrli-dfw-04-05.png

 

許可ルールがは適用されて、vm01 で実行している curl で HTML が取得できるようになりました。

vrli-dfw-04-06.png

 

vRLI のダッシュボードでは「Firewall audit events y operation」チャートで、

DFW の設定変更をした「save configuration」のカウントがあがったタイミングから通信が通過するようになり、

「Firewall actions」チャートで DFW による drop が pass に置き換わった様子が分かります。

そして、追加した許可ルールである ルール ID 1094 がヒットするようになりました。

vrli-dfw-04-07.png

 

そしてインタラクティブ分析を開いてみると・・・

vrli-dfw-04-08.png

 

ESXi から転送されてきた、DFW が PASS を示す実ログ テキストを見ることができます。

通信が通過できているときも、DFW が作用していることが可視化されています。

vrli-dfw-04-09.png

 

DFW ルールのログ出力を停止する。

DFW に追加したルール ID 1094 を「ログに記録しない」に戻して・・・

vrli-dfw-04-10.png

 

「変更の発行」をすると、このルールは有効のまま、ログは ESXi  に出力されなくなります。

そのため vRLI にも、このルールにかかわる pass のログは転送されなくなります。

vrli-dfw-04-11.png

 

vRLI のダッシュボードを見ると、

2度目の「save configuration」があがったタイミング以降、

pass についてのログが出力されなくなった様子がわかります。

※途中で pass ログが途切れているのは、一時的に curl コマンドを止めて再実行したためです。

vrli-dfw-04-12.png

 

このように、vRLI で DFW の作用する様子を見ることができます。

 

つぎは、pass ログに注目してみます。

vRealize Log Insight と NSX DFW で通信の様子を可視化してみる。Part.1

NSX for vSphere の 分散ファイアウォール(DFW)の様子を、

vRealize Log Insight(vRLI)を利用してみてみます。

 

この投稿での利用製品と構成状態について。

vRealize Log Insight で NSX DFW の Drop を確認してみる。Part.1

 

この投稿の環境について。

vRealize Log Insight で NSX DFW の Drop を確認してみる。Part.2

 

それでは、vRLI で、DFW のログを見てみます。

 

DFW ルールでの、ログ出力の有効化。

まず DFW のファイアウォール ルールで、通信が Drop されたときにログが出力されるよう設定します。

この環境では デフォルト ルールを「ブロック」にしていて、明示的に通信を許可するルールを設定しない限り

このルールで通信が遮断されるようになっています。

そこで、この「デフォルト ルール」を編集して、Drop したときに「ログに記録」するようにしておきます。

 

まず「デフォルト ルール」の「操作」列のあたりで、編集ボタンをクリックします。

vrli-dfw-03-01.png

 

デフォルトでは「ログに記録しない」になっているので、「ログに記録」に設定変更します。

vrli-dfw-03-02.png

 

通信を発生させる。

Drop のログを出力するため、意図的に Drop される通信を発生させます。

今回は、vm01 (IP は 10.1.10.101)から ext-vm01(IP は 192.168.1.223)に、

curl で Web サーバ(TCP 80 番ポート)宛の通信を発生させてみます。

 

期待どおり、通信できない状態です。

root@vm01 [ ~ ]# ip a show eth0 | grep inet -m 1

    inet 10.1.10.101/24 brd 10.1.10.255 scope global dynamic eth0

root@vm01 [ ~ ]# curl 192.168.1.223:80

curl: (7) Failed to connect to 192.168.1.223 port 80: Connection timed out

 

vRLI ダッシュボードでのログ確認。

vRLI には NSX for vSphere のコンテンツパックをインストール済みなので、

「VMware NSX-vSphere」というダッシュボードが利用可能になっています。

 

まず、「Distributed Firewall - Overview」ダッシュボードを見てみます。

ログが転送される前には何も表示されませんが・・・

vrli-dfw-03-03.png

 

DFW 関連のログを受信すると、表示されます。

意図的に発生させた、通信が Drop されたログを受信できています。

デフォルト ルールで Drop されているので、ルール ID 1001 のカウントも上がっています。

vrli-dfw-03-04.png

 

「Distributed Firewall - Traffic」ダッシュボードでは、

「Firewall application ports denied」80 番ポート宛の通信が Drop されていそうなことが見られます。

一緒に 別の VM の NTP 通信(123 番ポート)も遮断されている様子が見えます。

vrli-dfw-03-05.png

 

ダッシュボードにはフィルタも設置されているので、

「vmw_nsx_firewall_src」で、通信元 IP アドレスを指定してフィルタリングしてみました。

「Firewall top sources」が指定した IP「10.1.10.101」のみに絞られ、

そこから 192.168.1.223 宛の 80 番ポートが DFW で遮断されていることが明確にわかります。

vrli-dfw-03-06.png

 

インタラクティブ分析 でのログ テキストの表示。

表示されているチャートにある「インタラクティブ分析 で開く」というボタンをクリックすると・・・

vrli-dfw-03-07.png

 

ダッシュボードのチャート表示で使用されていたフィルタ設定で、

インタラクティブ分析 画面に移動できます。

ここで、分析のもとになっている実ログのテキストを見ることができるので、

Drop を示すログ テキスト自体を確認することが可能です。

vrli-dfw-03-08.png

 

DFW 環境で期待どおり通信許可できているか(Drop されていないか)を

このようにダッシュボードや IP アドレスをもとにした検索から調査することができます。

個々の ESXi に直接ログインしてログ確認をするより便利ではないかと思います。

 

続く。

vRealize Log Insight で NSX DFW の Drop を確認してみる。Part.4

NSX for vSphere の 分散ファイアウォール(DFW)の様子を、

vRealize Log Insight(vRLI)を利用してみてみようと思います。

 

前回は、製品構成を説明しました。

vRealize Log Insight で NSX DFW の Drop を確認してみる。Part.1

 

今回は、実際に見てみる環境の概要を説明しておこうと思います。

 

ネットワーク構成と VM 配置。

下記のような簡易的なネットワーク環境を構成しました。

DFW が作用する通信を発生させるため、2台の Linux VM を

アクセス元 VM「vm01」と、アクセス先 VM「ext-vm01」として用意しました。

  • ext-vm01 (IP: 192.168.1.223)  ※Web サーバ
  • vm01(IP: 10.1.10.101)
  • 実際は他にも何台か VM あり。

 

DFW 環境内から外部の Web サーバ(Yum や GitHub なども)にアクセスするようなケースもあるかなと思い、

アクセス先の ext-vm01 では、Web サーバを起動してみました。

vrli-dfw-02-1a.PNG

 

ちなみに、ext-vm01 の Web サーバはただ nginx の Docker コンテナを起動しているだけです。

root@ext-vm01 [ ~ ]# ip a show eth0 | grep inet -m 1

  inet 192.168.1.223/24 brd 192.168.1.255 scope global dynamic eth0

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

VMware Photon Linux 1.0

PHOTON_BUILD_NUMBER=62c543d

root@ext-vm01 [ ~ ]# systemctl start docker

root@ext-vm01 [ ~ ]# docker run -d -p 80:80 nginx

Unable to find image 'nginx:latest' locally

latest: Pulling from library/nginx

e6e142a99202: Pull complete

8c317a037432: Pull complete

af2ddac66ed0: Pull complete

Digest: sha256:72c7191585e9b79cde433c89955547685db00f3a8595a750339549f6acef7702

Status: Downloaded newer image for nginx:latest

925d315458f74068fba33a907e33e4690c448b25646cad585a9f4a766109f842

root@ext-vm01 [ ~ ]#

 

コンテンツも、ただ Welcome ページが置かれているだけです。

root@ext-vm01 [ ~ ]# curl -s 192.168.1.223:80 | head -n 4

<!DOCTYPE html>

<html>

<head>

<title>Welcome to nginx!</title>

 

通信経路と、利用するファイアウォール機能。

今回は、すでに vm01 と ext-vm01 が相互に通信可能になるようにルーティングしてある状態です。

NSX で利用できるファイアウォールは、2種類あります。

 

NSX Edge Service Gateway(ESG)の Edge Firewall

  • ESG の VM がもつファイアウォール機能。
  • ESXi は関与せず、ESG がファイアウォール仮想アプライアンスとして動作する。

分散ファイアウォール(DFW)

  • ESXi の VMkernel がもつファイアウォール機能。
  • DFW を有効にしているクラスタで起動する VM の vNIC で作用する。

 

どちらも vSphere Web Client の NSX 管理画面(Network and Security)から

設定変更することができます。

両方同時に利用することも、片方だけ利用することも可能です。

今回は、Edge Firewall は特に使用せず、DFW だけ扱います。

 

ちなみに、ESXi がもつ ESXi Firewall もありますが、これは VMkernel の通信を制御するもので、

基本的に VM の通信には作用しないファイアウォールです。

vrli-dfw-02-2a.PNG

 

DFW は、VM の vNIC で作用するファイアウォールなので、

ファイアウォールの動作(許可や拒否など)は、ESXi のログとして出力することが可能です。

ESXi はこのログを Syslog 転送することが可能なので、Log Insight に転送して分析 / 可視化することができます。

vrli-dfw-02-3a.PNG

 

つづく・・・

vRealize Log Insight で NSX DFW の Drop を確認してみる。Part.3

NSX for vSphere の 分散ファイアウォール(DFW)のログは、ESXi に出力されます。

DFW の作用している様子を、ESXi の Syslog を受け取る vRealize Log Insight(vRLI)を利用して

確認してみてみようと思います。

 

vRLI で NSX の DFW によるパケット ドロップの様子を確認してみます。

 

今回は、使用している製品と構成状態を説明しておきます。

 

製品とバージョンについて。

この一連の投稿で利用している製品と、そのバージョンは下記です。

  • vCenter Server 6.5d
  • ESXi 6.5d
  • NSX for vSphere 6.3.1
  • vRealize Log Insight 4.5

 

構成状態について。

NSX 環境で利用する ESXi は 3台あります。

すでに NSX コンポーネントをインストール済みで、DFW が有効になっています。

vrli-dfw-01-0.png

 

vRLI のバージョンは 4.5 です。

vRLI は 1 VM だけですが仮想 IP を構成しています。

この環境では以前のバージョンから利用している都合で仮想 IP を使用していますが、

NSX と vRLI を連携させるうえで 仮想 IP が必須というわけではありません。

この環境では、FQDN を DNS サーバに登録して名前解決できるようにしてあります。

vrli-dfw-01-1.png

 

ESXi の Syslog 転送も設定済みです。

vRLI の「管理」画面の「vSphere 統合」にある、登録済みの vCenter Server の「詳細表示」から・・・

vrli-dfw-01-2.png

 

ESXi のログを vRLI に転送するように設定ずみであることがわかります。

vrli-dfw-01-3.png

 

ESXi の「システムの詳細設定」を見ると、

Syslog 転送先として vRLI のアドレスが指定されていることが確認できます。

vrli-dfw-01-3b.png

 

vRLI の「管理」→「ホスト」を確認すると「過去 5 分以内」に

ESXi 3台のログが受信できていることがわかります。

ログに含まれるホスト名や、名前解決の都合などにより、

同一ホストのホスト名が FQDN とショートネームで検知されています。

vrli-dfw-01-4.png

 

NSX のダッシュボードを利用するためのコンテンツパックは、

すでにインストール済みです。

まだインストールされていない場合も、vRLI のこの Web UI を表示している端末が

インターネット接続できているようであれば、この「マーケット プレイス」画面からインストールできます。

vrli-dfw-01-5.png

 

つづく・・・

vRealize Log Insight で NSX DFW の Drop を確認してみる。Part.2

NSX Manager のデータ バックアップは、FTP もしくは SFTP サーバに取得できます。

Back Up NSX Manager Data

 

たとえば、下記のように Linux サーバを簡易的なバックアップ先とすることもできます。

NSX-v の簡易バックアップサーバ (SFTP) を Linux で用意する。

 

ただ、NSX Manager のバックアップは自動削除されません。

下記のように、取得したバックアップ ファイルはひたすら残ります。

※これは NSX 6.3.1 の NSX Manager の画面です。

nsx-bk-cleanup-01.png

 

この「Backup History」に表示されているバックアップは、

バックアップ先でファイルを削除すれば、Web UI 側からも表示されなくなります。

 

そこで、Linux の cron を使用してバックアップをクリーンアップしてみます。

今回は、以前の投稿(下記)の環境で実施しています。

NSX-v の簡易バックアップサーバ (SFTP) を Linux で用意する。

 

1回の NSX Manager のバックアップでは、

バックアップ先に指定したフォルダ配下に、下記のような2つのファイルセットが作成されます。

<Backup Directory>/<Backup Prefix><タイムスタンプ>.backupproperties

<Backup Directory>/<Backup Prefix><タイムスタンプ>

 

具体的には、下記のような感じのファイル名になります。

/home/nsx-bk-user01/nsxmgr01-17_10_00_Sun18Jun2017.backupproperties

/home/nsx-bk-user01/nsxmgr01-17_10_00_Sun18Jun2017

 

これらのバックアップ ファイルを、cron で定期的に自動削除します。

今回は、下記のような corn 定義ファイルを作成してみました。

 

1行だけ記載した /etc/cron.d/nsx-backup-cleanup ファイルを新規作成しています。

内容は下記のような感じです。

  • 毎時 15分に自動実行。
    NSX Manager を毎時10分にバックアップ取得するように設定しているので、その少し後。
  • nsx-bk-user01 ユーザで実行。
    SFTP 接続用として作成したユーザにあわせて。root などでもよい。
  • 今回は 3世代のバックアップファイルを残す。
    世代数をわかりやすくするため、あえて GEN=3 と指定してみた。
  • バックアップファイル名は、NSX Manager の「Backup Directory」と「Backup Prefix」
    に合わせて「/home/nsx-bk-user01/nsxmgr01-」。
  • ls コマンドで、タイムスタンプ順にバックアップファイルをリスト。
    そして「残す世代数 * 1回のバックアップセット(2つ)」 以降のファイルを
    tail コマンドで取得して、xargs コマンドで削除(rm)する。

[root@nsx-work ~]# cat /etc/cron.d/nsx-backup-cleanup

15 * * * * nsx-bk-user01 GEN=3; ls -t /home/nsx-bk-user01/nsxmgr01-* | tail -n +`expr $GEN \* 2 + 1` | xargs rm

 

この cron ファイルを作成して、自動実行されるのを待つと、
下記のような感じで 3世代分のファイルだけ残して、他のバックアップ ファイルは削除されます。

[root@nsx-work ~]# ls -t /home/nsx-bk-user01/nsxmgr01-*

/home/nsx-bk-user01/nsxmgr01-17_10_00_Sun18Jun2017.backupproperties

/home/nsx-bk-user01/nsxmgr01-17_10_00_Sun18Jun2017

/home/nsx-bk-user01/nsxmgr01-16_10_00_Sun18Jun2017.backupproperties

/home/nsx-bk-user01/nsxmgr01-16_10_00_Sun18Jun2017

/home/nsx-bk-user01/nsxmgr01-15_10_00_Sun18Jun2017.backupproperties

/home/nsx-bk-user01/nsxmgr01-15_10_00_Sun18Jun2017

[root@nsx-work ~]#

 

NSX Manager から見える Backup History も、3世代分だけになっています。

nsx-bk-cleanup-02.png

 

このような感じで、バックアップ先のファイルを削除すれば、
NSX Manger から見たバックアップ履歴も削除されます。

ただ、ファイル削除はしっかり検証 / 動作確認したうえで実装してもらえればと思います。

 

以上、NSX Manager のデータ バックアップのクリーンアップをしてみる話でした。

NSX for vSphere を PowerCLI で操作する、PowerNSX  というツールが公開されています。

実は、PowerNSX は VMware の Docker Hub で公開されている

PowerCLI Core のコンテナイメージ「vmware/powerclicore」にも含まれています。

ということで、Docker コンテナから PowerNSX を起動してみます。

 

以前の投稿もどうぞ・・・

PowerCLI Core を Docker コンテナでためしてみる。

PowerNSX で VMware NSX の論理スイッチ (Logical Switch) を作成してみる。

 

 

Docker ホストの用意

今回の Docker ホストは、Photon OS です。

あらかじめ、下記からダウンロードした OVA ファイル(OVA with virtual hardware v11)をデプロイして、

ホスト名と root パスワードだけ変更してあります。

Downloading Photon OS · vmware/photon Wiki · GitHub

 

まずパッケージを最新化して、OS を再起動しておきます。

※Photon OS は、yum のかわりに、tdnf コマンドを使用します。

root@photon01 [ ~ ]# tdnf upgrade -y

root@photon01 [ ~ ]# reboot

 

Photon OS のバージョンです。

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

VMware Photon Linux 1.0

PHOTON_BUILD_NUMBER=62c543d

root@photon01 [ ~ ]# uname -r

4.4.70-3.ph1-esx

 

Docker のバージョンです。

root@photon01 [ ~ ]# rpm -q docker

docker-1.13.1-3.ph1.x86_64

 

そして Docker サービスを起動しておきます。

root@photon01 [ ~ ]# systemctl enable docker

Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.

root@photon01 [ ~ ]# systemctl start docker

root@photon01 [ ~ ]# docker version

Client:

Version:      1.13.1

API version:  1.26

Go version:   go1.8.1

Git commit:   092cba3

Built:        Fri May  5 02:08:33 2017

OS/Arch:      linux/amd64

 

Server:

Version:      1.13.1

API version:  1.26 (minimum version 1.12)

Go version:   go1.8.1

Git commit:   092cba3

Built:        Fri May  5 02:08:33 2017

OS/Arch:      linux/amd64

Experimental: false

 

PowerCLI Core コンテナの起動

Docker Hub から、vmware/powerclicore をダウンロード(pull)しておきます。

root@photon01 [ ~ ]# docker pull vmware/powerclicore

Using default tag: latest

latest: Pulling from vmware/powerclicore

93b3dcee11d6: Pull complete

64180fb7dedf: Pull complete

46c9ea8ba821: Pull complete

b0ad35240277: Pull complete

f537a588698e: Pull complete

b821ac08cbe0: Pull complete

a76c30f73a8e: Pull complete

e5d8130503e2: Pull complete

a72ad7270123: Pull complete

c6b89e0875bf: Pull complete

d1628dac3e00: Pull complete

57fb698e34cd: Pull complete

9a9d3505a642: Pull complete

bf20548eaf12: Pull complete

a27e923ed27a: Pull complete

f0ecdd77fe48: Pull complete

7b8113d29296: Pull complete

2590b0e2e842: Pull complete

e3b9ecfe2ca0: Pull complete

d4838036c9df: Pull complete

5a536d9f1f30: Pull complete

3f9566a85b2e: Pull complete

bdb2ac6e70be: Pull complete

Digest: sha256:ffe996f7d664b2d8d9cd25501a8cb0a2f7459871b09523c1d3545df780ace211

Status: Downloaded newer image for vmware/powerclicore:latest

 

イメージがダウンロードできました。

root@photon01 [ ~ ]# docker images

REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE

vmware/powerclicore   latest              a8e3349371c5        6 weeks ago         610 MB

 

コンテナを起動します。

root@photon01 [ ~ ]# docker run -it vmware/powerclicore

 

コンテナを起動すると、このような感じになります。

docker-powernsx-01.png

 

PowerCLI Core のバージョンです。

PS /powershell> Get-PowerCLIVersion

 

PowerCLI Version

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

   VMware PowerCLI Core 1.0 build 5327113

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

Component Versions

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

   VMware vSphere PowerCLI Component 1.22 build 5327113

   VMware VDS PowerCLI Component 5.1 build 5327113

   VMware VDS PowerCLI Component 1.21 build 5327113

 

 

 

PS /powershell>

 

PowerNSX での vCenter と NSX への接続

それでは、PowerNSX で vCenter / NSX に接続してみます。

 

PowerNSX のバージョンを見ておきます。

PS /powershell> Import-Module -Name PowerNSX

PS /powershell> Get-Module PowerNSX | select Name,Version

 

 

Name     Version

----     -------

PowerNSX 2.1.0

 

 

ちなみに、まだ安定版というわけではないこともあり

Import-Module -Name PowerNSX を実行したタイミングで赤字で注意書きが表示されます。

docker-powernsx-02.png

 

PowerNSX では NSX Manager と vCenter に接続してから実行します。

Connect-NSXServer では、vCenter に同時接続する機能がありますが、

いまのところちょっとうまくいかないので、vCenter と NSX Manager をそれぞれ別に接続します。

 

まず、vCenter に接続します。「vc-sv02」が今回の vCenter です。

PS /powershell> Connect-VIServer vc-sv02.go-lab.jp -Force

 

Specify Credential

Please specify server credential

User: gowatana ★VCにログインするユーザを入力。

Password for user gowatana: ******** ★パスワードを入力。

 

vCenter に接続できました。

PS /powershell> $Global:DefaultVIServer | fl Name,IsConnected

 

 

Name        : vc-sv02.go-lab.jp

IsConnected : True

 

 

NSX Manager に接続します。「nsxmgr01」が今回の NSX Manager です。

「Using existing PowerCLI connection to ~」にある IP アドレスは、
すでに接続済みのvCenter の IP アドレスです。

そして VIConnection を見ると、vCenter への接続を認識していることが分かります。

PS /powershell> Connect-NsxServer -NsxServer nsxmgr01.go-lab.jp -ValidateCertificate:$false

 

 

Windows PowerShell credential request

NSX Manager Local or Enterprise Admin SSO Credentials

User: admin ★NSX Manager のユーザを入力。

Password for user admin: ********** ★パスワードを入力。

 

Using existing PowerCLI connection to 192.168.1.96

 

 

Version             : 6.3.1

BuildNumber         : 5124716

Credential          : System.Management.Automation.PSCredential

Server              : nsxmgr01.go-lab.jp

Port                : 443

Protocol            : https

ValidateCertificate : False

VIConnection        : vc-sv02.go-lab.jp

DebugLogging        : False

DebugLogfile        : \PowerNSXLog-admin@nsxmgr01.go-lab.jp-2017_06_13_14_41_28.log

 

 

 

PS /powershell>

 

PowerNSX に含まれるコマンドレットで、情報取得できるようになります。

PS /powershell> Get-NsxManagerSystemSummary

 

ipv4Address       : 192.168.1.141

dnsName           : nsxmgr01.go-lab.jp

hostName          : nsxmgr01

domainName        : go-lab.jp

applianceName     : vShield Virtual Appliance Management

versionInfo       : versionInfo

uptime            : 2 days, 3 hours, 14 minutes

cpuInfoDto        : cpuInfoDto

memInfoDto        : memInfoDto

storageInfoDto    : storageInfoDto

currentSystemDate : Tuesday, 13 June 2017 11:41:50 PM JST

 

 

これで、便利な PowerNSX を手軽にためすことができます。

ただ PowerCLI Core も、まだ Technical Preview なので

まだメインで使う PowerNSX は Windows の PowerCLI とかなと思います。

 

以上、PowerCLI Core コンテナ同梱の PowerNSX を実行してみる話でした。

NSX for vSphere (NSX-v) では、NSX Manager からのデータバックアップ先として

FTP サーバ、もしくは SFTP サーバを指定できます。

Back Up NSX Manager Data

 

今回は、検証環境や自宅ラボなどで、

NSX Manager の簡易的なバックアップ先を用意する方法を紹介しようと思います。

 

Red Hat Enterprise Linux や、CentOS など、一般的な Linux ディストリビューションでは

SSH Server がデフォルトでセットアップされています。

その SSH Server に含まれる SFTP Server を利用すると便利ではないかと思います。

バックアップ先 として利用する Linux

今回は、Oracle Linux 7.3 を利用します。

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

Oracle Linux Server release 7.3

 

OS の Minimal Install でも、デフォルトで openssh-server がインストールされていて、

サービスが起動されています。

[root@nsx-work ~]# rpm -q openssh-server

openssh-server-6.6.1p1-35.el7_3.x86_64

[root@nsx-work ~]# systemctl is-enabled sshd

enabled

[root@nsx-work ~]# systemctl is-active sshd

active

 

そして sftp-server も含まれていて、

デフォルトで OS ユーザで接続することが可能になっています。

[root@nsx-work ~]# rpm -ql openssh-server | grep sftp

/usr/libexec/openssh/sftp-server

/usr/share/man/man8/sftp-server.8.gz

 

バックアップ先 SFTP Server での準備

バックアップ先の Linux は、OS ユーザを作成するだけで SFTP サーバとして利用できます。

 

それでは、バックアップ先の Linux で、SFTP 接続で利用する OS ユーザを作成しておきます。

今回は「nsx-bk-user01」という名前のユーザを作成します。

[root@nsx-work ~]# useradd nsx-bk-user01

[root@nsx-work ~]# passwd nsx-bk-user01

ユーザー nsx-bk-user01 のパスワードを変更。

新しいパスワード:  ★パスワードを入力。

新しいパスワードを再入力してください:

passwd: すべての認証トークンが正しく更新できました。

 

今回は、作成したユーザのホームディレクトリ「/home/nsx-bk-user01」をバックアップ先に指定するつもりです。

[root@nsx-work ~]# su - nsx-bk-user01

[nsx-bk-user01@nsx-work ~]$ echo $HOME

/home/nsx-bk-user01

[nsx-bk-user01@nsx-work ~]$ pwd

/home/nsx-bk-user01

 

NSX Manager でのバックアップ先指定

NSX Manager の 管理画面にアクセスして、バックアップ先を指定します。

ちなみに今回の NSX Manager は「nsxmgr01」という名前にしています。

 

NSX Manager の管理画面に admin ユーザでログインします。

nsx-mgr-bk-00.png

 

「Backup & Restore」画面の「FTP Server Settings」で「Change」ボタンをクリックして設定します。

nsx-mgr-bk-01.png

 

バックアップ先の設定をします。

  • IP/Host name → SFTP サーバのアドレスを指定。
  • Transfer Protocol → SFTP を指定。
  • Port → SFTP (SSH) なので 22。
  • User name / Password → 作成した nsx-bk-user01 ユーザを指定。
  • Backup Directory → バックアップ先ディレクトリを指定。
  • Backup Prefix → バックアップファイルの先頭文字列を指定。今回は「nsxmgr01-」
  • Pass Phrase → パスフレーズを指定。

nsx-mgr-bk-02.png

 

バックアップの実行

バックアップは Scheduling(定期実行)を設定できますが、今回は手動実行します。

「Bakcup」をクリックします。

nsx-mgr-bk-04.png

 

「Start」をクリックすると、バックアップが実行されます。

nsx-mgr-bk-05.png

 

バックアップ ファイルが表示されます。

nsx-mgr-bk-06.png

 

SFTP サーバでディレクトリを見ると、NSX Manager のバックアップファイルが作成されています。

2つファイルが作成されていますが、セットで 1回分のバックアップファイルです。

[nsx-bk-user01@nsx-work ~]$ pwd

/home/nsx-bk-user01

[nsx-bk-user01@nsx-work ~]$ ls -lh

合計 568K

-rw-rw-r--. 1 nsx-bk-user01 nsx-bk-user01 561K  6月 12 23:06 nsxmgr01-23_06_25_Mon12Jun2017

-rw-rw-r--. 1 nsx-bk-user01 nsx-bk-user01  230  6月 12 23:06 nsxmgr01-23_06_25_Mon12Jun2017.backupproperties

 

NSX Manager が壊れることもありうるので、

簡易的にでもバックアップを取得しておくと便利かなと思います。

 

以上、Linux SFTP サーバを NSX Manager のバックアップ先にしてみる話でした。

VMware NSX と その認定資格試験の勉強方法についてのヒントを、

いくつか紹介してみようと思います。

 

まず、NSX の技術認定資格についてですが、vSphere(DCV)とは別に

NV(Network Virtualization)というトラックがあり、DCV トラックと同様に

VCA / VCP / VCIX(VCAP 試験に合格すると認定される)/ VCDX があります。

NSX とはいっても、NSX for vSphere(NSX-v)のみを対象とした試験です。

つまり現時点の NSX の認定資格には NSX for Multi-Hypervisor については、まったく含まれません。

 

具体的な資格の体系や出題範囲などについては

VMware Education のサイトを参照いただければと思います。

※たまに変更があったり、具体的な出題内容には触れられなかったりするため。

VMware NSX Training and Certification

 

NSX の試験の勉強については、正攻法でいくとすると、

可能な限り VMware の認定トレーニングコースを受講するのがよいと思います。

たとえば、下記のような・・・

VMware NSX: Install, Configure, Manage [V6.2]

 

ただ、費用や受講時間帯などの問題で受講が難しいケースがあると思うので、

※ちなみに、私も NSX のトレーニングコースは受講できてません。

 

実は、私が NSX の資格(VCP-NV / VCIX-NV)を取得したのは 2014年
VMware Certified Implementation Expert 6 – Network Virtualization - Acclaim )で

ちょっとノウハウが古いかもしれませんが、

このあと紹介するコンテンツは最新化されているようです。

 

1. 知識習得について

 

基礎知識

NSX の基礎知識の習得については、マニュアル(ドキュメント)を読むことが一番だと思います。

対象の NSX のバージョン(6.2、6.3 ・・・)を選択してからドキュメントを参照します。

VMware NSX for vSphere のドキュメント

 

NSX の基本的なマニュアルは、日本語で公開されています。

これまでの VMware 製品のドキュメントよりも、図やスクリーンショットが多い印象があります。

洋書や、VMware 公式の日本語技術書(2014年11月頃)も出版されていますが、

正直なところ個人的には、それらよりマニュアルのほうが分かりやすい気がします。

 

設計 / 操作手順

NSX の設計や、具体的な操作についての勉強については、

VMTN の VMware NSX  フォーラムにあるドキュメント(「文章」タブ)を活用するとよいと思います。

 

まずおすすめなのは下記の 2つです。

ただし、NSX フォーラムのドキュメントやディスカッションは英語のみです。

特に VCP-NV の勉強では、「VMware NSX for vSphere Network Virtualization Design Guide」が役立ちます。

VMware® NSX for vSphere Network Virtualization Design Guide ver 3.0

NSX-v Operations Guide, rev 1.5

 

 

2. 実機操作について

 

VMware Hands-on Labs を利用する

NSX の実機環境を用意するのは、なかなかハードルが高いと思います。

 

Hands-on Labs(HoL)では、手軽に実機によるラボを使用することができます。

VMware Hands-on Labs

このページは VMTN の一部ですが、HoL を利用する場合は

あらたに VMTN アカウントとは別のアカウントを作成することになります。

 

HoL は、ラボ マニュアルのシナリオをもとに手順を進めるようになっていて、

ひと通りの機能を、実機で試すことができます。

VCIX の実技試験の準備としても、ラボ マニュアルのシナリオが参考になります。

 

下記のページに日本語化された主要なラボがまとめられています。
NSX については、まずは HOL-1703 から始まる名前のラボに取り組むとよいと思います。

VMware Hands-on Labs

 

HoL は無償で、何回でも同じラボを利用することができます。

私が VCIX-NV を取得した時には、20回以上 HoL-1403 を実行しました。

また、HoL ではラボ マニュアルのシナリオに沿わない操作も可能であり、

工夫すれば NSX API を試したりすることもできます。

※当時の NSX の基本的なラボは HoL-1703 ではなく、HoL-1403 でした。

※ラボを繰り返し利用する場合は、環境は初期化されてしまいます。

 

ただし、基本的に HoL で試せるのは NSX 自体の機能のみで、

物理的なネットワークにかかわる機能などは試せません。

 

評価用ライセンスを利用する

以前は、検証環境や自宅ラボなどで、実際に NSX 環境を構築しようとしても、

NSX は(vSphere などとは異なり)一般向けに無償評価ライセンスは提供されていませんでした。

 

しかし最近、有償ですが VMUG Advantage というサービスで
NSX の評価ライセンスが利用できるようになりました。

https://www.vmug.com/Join//EVALExperience

※ただし私は vExpert 用の評価ライセンスを利用させてもらっているので、これは利用してません。

 

 

NSX は技術要素としてはまだ新しめのもので、手探りで技術習得をしている人が多いと思いますので

なにかしら役立てていただければと思います。

 

以上、 NSX の勉強方法についてでした。

ためしに vCenter Server Appliance 6.0 (VCSA)  を、Datadog に登録してみました。

 

Datadog は、Datadog 社による 性能情報やイベントのモニタリングができるクラウドサービスです。

 

VMware vSphere のモニタリングにも対応しているようです。

Datadog-VMware Integration

Datadog-VMware Integration  (英語)

https://www.datadoghq.com/blog/unified-vsphere-app-monitoring-datadog/ (英語)

 

今回の環境について。

今回は、VCSA 6.0 U3 を使用しています。

Command> system.version.get

Version:

   Product: VMware vCenter Server Appliance

   Installtime: 2017-04-02T04:55:33 UTC

   Summary: VMware vCenter Server Appliance 6.0 Update 3

   Releasedate: February 23, 2017

   Version: 6.0.0.30000

   Build: 5112509

   Type: vCenter Server with an embedded Platform Services Controller

 

VCSA 6.0 は、SUSE Linux をベースとしています。

Command> shell.set --enabled True

Command> shell

    ---------- !!!! WARNING WARNING WARNING !!!! ----------

Your use of "pi shell" has been logged!

The "pi shell" is intended for advanced troubleshooting operations and while

supported in this release, is a deprecated interface, and may be removed in a

future version of the product.  For alternative commands, exit the "pi shell"

and run the "help" command.

The "pi shell" command launches a root bash shell.  Commands within the shell

are not audited, and improper use of this command can severely harm the

system.

Help us improve the product!  If your scenario requires "pi shell," please

submit a Service Request, or post your scenario to the

https://communities.vmware.com/community/vmtn/vcenter/vc forum and add

"appliance" tag.

 

vc02:~ # uname -n

vc02.go-lab.jp

vc02:~ # cat /etc/SuSE-release

SUSE Linux Enterprise Server 11 (x86_64)

VERSION = 11

PATCHLEVEL = 3

 

なお、この VCSA からは自宅ラボにあり、直接インターネットに出ることができます。

Datadog Agent インストール。

インストールは、DD_API_KEY を指定しつつ、curl コマンドで取得したスクリプトを実行します。
ちなみに このコマンドラインと DD_API_KEY は、Datadog の無料体験の登録時などにわかります。

vc02:~ # DD_API_KEY=182b0~ bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)"

 

スクリプトの内容は下記でわかります。

dd-agent/install_agent.sh at master · DataDog/dd-agent · GitHub

 

これで、Datadog Agent の RPM がインストールされました。

vc02:~ # rpm -qa | grep datadog

datadog-agent-5.13.2-1

 

デフォルトで Agent は起動します。

vc02:~ # chkconfig --list datadog-agent

datadog-agent             0:off  1:off  2:on   3:on   4:on   5:on   6:off

vc02:~ # service datadog-agent status

Datadog Agent (supervisor) is running all child processes

 

Datadog Agent 連携用ユーザの作成。

 

Datadog 連携用のユーザとして、今回は datadog-user@vsphere.local ユーザを

vCenter のもつ PSC のローカルユーザとして作成しています。

dd-01.png

 

作成したユーザには、vCenter の「読み取り専用」ロールを付与しています。

dd-02.png

 

Datadog Agent の連携設定。

Datadog Agent に含まれる /etc/dd-agent/conf.d/vsphere.yaml.example ファイルをもとに、
設定ファイルを作成します。

 

今回は下記のようにしました。

vc02:~ # vi /etc/dd-agent/conf.d/vsphere.yaml

vc02:~ # chown dd-agent:dd-agent /etc/dd-agent/conf.d/vsphere.yaml

vc02:~ # grep -E -v "#|^$" /etc/dd-agent/conf.d/vsphere.yaml

init_config:

instances:

  - name: vc02-home

    host: vc02.go-lab.jp

    username: 'datadog-user@vsphere.local'

    password: 'パスワード'

    ssl_verify: false

 

Datadog Agent を再起動します。

vc02:~ # service datadog-agent restart

* Stopping Datadog Agent (stopping supervisord) datadog-agent            [ OK ]

* Starting Datadog Agent (using supervisord) datadog-agent               [ OK ]

 

これで、vSphere の情報が Datadog に情報が転送されるようになります。
Datadog の Web UI (下記は Infrastructure → Infrastructure List を開いた画面)から、

VCSA と(赤枠のもの)、その vCenter が管理する ESXi と VM が自動検出されたことがわかります。
VM は、起動されているもののみ表示されるようです。

dd-03.png

 

以上、VCSA 6.0 を Datadog に登録してみる話でした。つづくかもしれない・・・

PowerCLI で vCenter / ESXi に接続する Connect-VIServer は以前に接続したサーバを記録していて、

「-Menu」オプションで過去に接続したサーバを表示、選択して接続することができます。

PowerCLI> Connect-VIServer -Menu

 

下記のような感じになります。

powercli-menu-01.png

 

このサーバリストは、PowerShell からみて下記のパスにあります。

$HOME\AppData\Roaming\VMware\PowerCLI\RecentServerList.xml

 

XML ファイルを見てみると、下記のような感じになっています。

Server ごとに指定されている Position の数字が、-Menu での表示順です。
すでに表示されない(おそらく 10件をこえたもの)は、Position 属性が削除されています。

<ServerList>

  <CurrentMonth>May</CurrentMonth>

  <Server Name="vc60n01.godc.lab" January="0" February="0" March="0" April="0" May="0" June="8" July="3" August="0" September="0" October="0" November="0" December="0" Position="1" />

  <Server Name="vc55n01.godc.lab" January="0" February="0" March="0" April="0" May="0" June="0" July="0" August="0" September="0" October="0" November="0" December="0" />

  <Server Name="vc60n02.godc.lab" January="0" February="0" March="0" April="0" May="0" June="3" July="2" August="0" September="0" October="0" November="0" December="0" Position="3" />

  <Server Name="192.168.5.75" January="0" February="0" March="0" April="0" May="0" June="0" July="0" August="0" September="0" October="0" November="0" December="0" />

  <Server Name="vc01.godc.lab" January="1" February="9" March="1" April="0" May="0" June="0" July="4" August="2" September="2" October="0" November="4" December="1" Position="5" />

  <Server Name="vc02.godc.lab" January="0" February="0" March="0" April="0" May="0" June="0" July="2" August="0" September="0" October="0" November="0" December="0" Position="6" />

  <Server Name="vcsa50-01.godc.lab" January="0" February="0" March="0" April="0" May="0" June="0" July="0" August="0" September="1" October="0" November="0" December="0" Position="7" />

  <Server Name="192.168.1.71" January="0" February="0" March="0" April="0" May="0" June="0" July="0" August="0" September="1" October="0" November="0" December="0" Position="8" />

  <Server Name="vc65-1.go-lab.jp" January="1" February="4" March="3" April="0" May="0" June="0" July="0" August="0" September="0" October="0" November="0" December="0" Position="9" />

  <Server Name="vc-sv01.go-lab.jp" January="0" February="0" March="4" April="9" May="10" June="0" July="0" August="0" September="0" October="0" November="0" December="0" Position="10" />

  <Server Name="vc02.go-lab.jp" January="0" February="0" March="0" April="1" May="0" June="0" July="0" August="0" September="0" October="0" November="0" December="0" Position="2" />

  <Server Name="vc-sv02.go-lab.jp" January="0" February="0" March="0" April="0" May="4" June="0" July="0" August="0" September="0" October="0" November="0" December="0" Position="4" />

</ServerList>

 

見やすく 接続先サーバ(Name)と Position を抜粋すると、下記のようになっています。

PS C:\> $sv_list = [xml](gc $HOME\AppData\Roaming\VMware\PowerCLI\RecentServerList.xml)

PS C:\> $sv_list.ServerList.Server | sort {[int]$_.Position} | ft -AutoSize Name,Position

 

 

Name               Position

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

192.168.5.75

vc55n01.godc.lab

vc60n01.godc.lab   1

vc02.go-lab.jp     2

vc60n02.godc.lab   3

vc-sv02.go-lab.jp  4

vc01.godc.lab      5

vc02.godc.lab      6

vcsa50-01.godc.lab 7

192.168.1.71       8

vc65-1.go-lab.jp   9

vc-sv01.go-lab.jp  10

 

最近使用してる vCenter 2台を残して、削除してみました。

<ServerList>

  <CurrentMonth>May</CurrentMonth>

  <Server Name="vc-sv01.go-lab.jp" January="0" February="0" March="4" April="9" May="10" June="0" July="0" August="0" September="0" October="0" November="0" December="0" Position="1" />

  <Server Name="vc-sv02.go-lab.jp" January="0" February="0" March="0" April="0" May="4" June="0" July="0" August="0" September="0" October="0" November="0" December="0" Position="2" />

</ServerList>

 

Connect-VIServer -Menu を実行してみると、2台だけ表示されるようになりました。

powercli-menu-02.png

 

ちなみに、不要になったサーバを Position=""  とするとリストを読まなくなるようで、
XML ファイルを編集してサーバを削除するには
今回のように Server 要素ごと削除するか、Position 属性を削除する必要があるようです。

 

なお、今回は PowerCLI 6.5 Release 1 を Windows 10 で実行しています。

PowerCLI C:\> (Get-PowerCLIVersion).UserFriendlyVersion

VMware PowerCLI 6.5 Release 1 build 4624819

 

検証環境などで多数の vCenter に接続する場合には「-Menu」オプションが便利かもしれません。

 

以上、PowerCLI の -menu リストを更新してみる話でした。