Skip navigation
2017

これまでの投稿にひき続き、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 の勉強方法についてでした。