Network of VMware Cloud on AWS

VMC on AWSのSDDCのネットワークではNSXを利用することになりますが、NSX-VまたはNSX-Tのいずれかを利用することができます。

そして、NSX-VとTではまだ利用できる機能が異なるため注意が必要です。

機能またはソリューション	NSX for vSphere	NSX-T
ポリシーベースの IPsec VPN	はい	はい
ルートベースの IPsec VPN	いいえ	はい
すべてのトラフィック用 Direct Connect	いいえ（ESXi 管理と vMotion トラフィックのみ）	はい
L2 VPN	はい	はい
Edge ファイアウォール	はい	はい
論理ネットワーク、DHCP、DNS、NAT	はい	はい
分散ファイアウォール	いいえ	はい
IPFIX、ポート ミラーリング	いいえ	はい
オーバーレイ ネットワークと Amazon VPC 間の管理アプライアンスと ESXi のアクセス	いいえ	はい
複数クラスタ	はい	はい
複数のアベイラビリティ ゾーンにまたがるストレッチ クラスタ	はい	はい
双方向の vMotion による移行	はい	はい
VMware Site Recovery	はい	はい
VMware Hybrid Cloud Extension	はい	はい
Horizon	はい	いいえ
サード パーティ ソリューション - ストレージ パートナー	はい	いいえ
セカンド パーティ ソリューション - vRA、vROps	はい	はい

引用：VMware Cloud on AWS のネットワークおよびセキュリティについて

大きいところでは、Distributed Firewallを利用するのであればNSX-Tで、vRAやvROPSを利用するのではればNSX-Vの判断でよさそうです。

両方使いたいとなると悩ましいですが。。。

Deploying NSX-T Manager

NSXのHOLではNSX ManagerはDeploy済のところからなので、自宅の環境にNSX-TのManagerをDeployしてみました。

NSX-TのManagerはいつも通りovaで提供されているのでvCenterからovaのデプロイを実行します。

基本的にはovaのDeployなのでいつもの感じで、データストアや、Deployサイズの選択しつつ、「次へ」「次へ」で進んでいきます。

テンプレートの変更では、いくつかのアプライアンスのパスワード、IPアドレス、ホスト名等々の設定を行います。

再度に設定の確認を行ってからDeployの完了を待つだけです。

っが、、、ここでエラーが出てDeploy失敗。。。

今日は時間もないので、また後日チャレンジしてみます。

VMware Cloud on AWS use case

vforum の基調講演でも触れられていましたが、
VMware Cloud on AWSはUSではリリースされて1年半がたちましたが、
利用用途として多いのは、クラウドへの移行、データセンターの拡張(DR含む)
クラウドネイティブアプリの開発の3つが多いらしいです。

日本でもまずはDR用途が多くなりそうですね。

VMware Cloud Foundation (VCF) License Edition

VMware Cloud Foundationはご存知でしょうか？
最近ではVCFといったふうに省略していることもあるのですが、数年前から提供されているクラウド運用ツールになります。

このVCFですが、vSphere、vSAN、NSXに加えて、SDDC Managerを組み合わせた製品となってます。そしてこのVCFにもライセンスのエディションがあり、当然ながら各エディションごとの機能差があります。

VMware社からの情報によると以下のような機能差があります。

	Basic	Standard	Advanced	Enterprise
コンピューティング
DRS	〇	〇	〇	〇
Cross vCenter vMotion Long Distance vMotion	〇	〇	〇	〇
高可用性とFT	〇	〇	〇	〇
管理機能
ライフサイクル管理の自動化	〇	〇	〇	〇
Business:クラウドのコスト算出と比較		〇	〇	〇
Business:クラウドビジネスの計画とショーバック			〇	〇
Automation:アプリケーションのプロビジョニング			〇	〇
AUTOMATION：インフラストラクチャのプロビジョニング、ガバナンス			〇	〇
OPERATIONS：キャパシティ プランニング、OS/アプリケーションのモニタリング		〇	〇	〇
LOG INSIGHT：ログ分析		〇	〇	〇
ネットワーク運用：フロー分析、マイクロセグメンテーションの計画		〇	〇	〇
ネットワーク運用：AWS VPC、マイクロセグメンテーションのタグの計画				〇
ネットワーク
VPN（IPsec と SSL）	〇	〇	〇	〇
CMP/NSX Cloud との連携	〇	〇	〇	〇
分散スイッチ、ルーティング、ファイアウォール	〇	〇	〇	〇
マルチサイトのコンテナ ネットワークとセキュリティ		〇	〇	〇
NSX Edge のファイアウォール、ロードバランシング		〇	〇	〇
NSX Hybrid Connect（大規模なワークロードの移行）				〇
コンテキストに応じたマイクロセグメンテーション（アプリケーション ID）				〇
		〇	〇	〇
ストレージ
イレイジャー コーディング（オールフラッシュのみ）	〇	〇	〇	〇
重複排除と圧縮（オールフラッシュのみ）	〇	〇	〇	〇
保存データ暗号化				〇
ローカル環境の障害を保護するストレッチ クラスタ				〇

※引用：VMware Cloud Foundation 主な機能 

VCFに含まれる各製品のエディションを当てはめるとこんな感じになります。

	Basic	Standard	Advanced	Enterprise
vSphere	Enterprise Plus
NSX	Advanced			Enterprise
vSAN	Advanced			Enterprise
vRealize Suite	-	Standard	Enterprise
vRealize Network Insight	-	Advanced		Enterprise

VCFはvSphere、vSAN、NSXでどの機能が利用したいか、それに加えてvRealize系製品の利用有無によってエディションを選択していきます。


利用方法は、プライベートクラウド、パブリッククラウドの両方で利用することが可能ですが、パブリッククラウドでの利用はVCFに対応しているパブリッククラウドサービスをサービスとして購入する必要があります。

2018年11月8日現在でVCFに対応しているパブリッククラウドサービスはこちらの5社になります。
AWS(VMware Cloud on AWS)、IBM Bluemix、CenturyLink、RackSpace、NTTコミュニケーションズ。　※富士通 K5も対応予定のようです。

NSX Cloud

何回か前の記事でNSX SDDSのライセンスを紹介しましたが、その中でNSXファミリーの製品についてもちょっとだけ触れました。

今回はNSX ファミリー製品の一つである、NSX Cloudについてご紹介します。

NSX Cloudは簡単にいうと、「マルチクラウド、マルチサイトにネットワークとセキュリティを提供する製品」になります。

もうちょっと詳しく説明すると、これまでのようにデータセンター内のみの自社ネットワークであれば簡単にセキュリティポリシーの一貫性を保つことはできました。しかし、パブリッククラウドを利用したマルチクラウド環境では、オンプレやパブリッククラウドごとのネットワーク構成や機能、セキュリティポリシーが異なるため一貫性を保つことが難しくなります。

そういった課題を解決するためにNSX Cloudで統一した構成、およびセキュリティポリシーを提供することが可能となります。

では、NSX Cloudで必要となるコンポーネントを紹介します。

1. Central Management Plane
• NSX Manager と NSX Cloud Service Manager
2. Central Control Plane
• NSX Controller
3. Cloud Gateway
• NSX Cloud Gateway
4. Data Plane
• Public Cloud インスタンスにインストールしたNSX Agent
5. Public Cloud Infrastructure with Hypervisor
• Public Cloud Infra 

これらのコンポーネントでNSX SDDCでは聞きなれないのは、NSX Cloud Service ManagerとNSX Cloud Gatewayになります。

NSX Cloud Service ManagerはNSX Cloud GatewayのDeployやアップデート、バックアップやリストアなどの機能を提供しています。

NSX Cloud GatewayはNATやEdgeファイアーウォールなどのサービスや、NSXエージェントのインストールなどに利用されます。

参考までにNSX Cloud GatewayのDeploy手順になります。

　※VMware HOL: HOL-1822-01-NET - VMware NSX Cloud - Secure Native Workload in AWS

Cloud Service Managerにログインし、[Cross Cloud]を選択

Compute-VPCの[Action]プルダウンメニューから、[Deploy NSX Cloud Gateway]を選択

各パラメータを設定し、NEXT→DEPLOYボタンを選択するとCloud Gatewayのデプロイが開始

デプロイ完了すると、Compute-VPCにNSX Managed YESが表示されます。

NSX-T 2.1 Updateの注意点

NSX-Tはまだまだ利用されている環境は少ないと思いますが、2.1からそれ以降へのアップデート時の注意点をご紹介します。


NSX-T 2.1まではトランスポートノードからNSX Controllerへの通信ポートは1234番が利用されていましたが、2.2移行は1235番が利用されるようになりました。

2.1からのアップデート後に、つながらない！！！　といったことが発生したら、通信ポートを疑ってみてください。

NSX-T Data Center 2.3 Release

もう、先月の話となってしまいましたが、2018年9月18日にNSX-T 2.3がリリースされました。

今回のリリースで大きな変更としては、製品名称が NSX-T Data Centerに変更となりました。　NSXファミリーの変更に伴う名称変更なんですかね。


機能的な部分での変更は、やはりクラウドとコンテナ対応を進めているといったイメージがあります。

NSX Cloud の機能強化

• AWS 環境のサポート：AWS 環境での NSX Cloud のサポート。 
• Azure VNET での NSX Agent の自動プロビジョニング
• オンプレミスとパブリック クラウド間の VPN サポートNSX Cloud Public Cloud Gateway 内部に、API を使用する組み込みのVPN 機能が含まれています。VPN 機能を使用して、以下の間に IPsec リンクを作成することができます。
  • 管理対象のコンピュート Amazon VPC/Azure VNET と、トランジット Amazon VPC/Azure VNET のサードパーティ製サービスの仮想マシン
  • 管理対象の Amazon VPC/Azure VNET と、オンプレミス VPN デバイス
• NSX Cloud エージェントの OS サポートの拡張：NSX Cloud は、パブリック クラウドで RHEL 7.5 オペレーティング システムをサポートしています。

ベアメタル ホストでの NSX-T Data Center サポートの導入

ベアメタルのサポートには、ベアメタル サーバで実行する Linux ベースのワークロードや、ハイパーバイザーを使用せずにベアメタル サーバで実行するコンテナが含まれます。NSX-T Data Center は Open vSwitch を利用して、Linux ホストを NSX-T Data Center トランスポート ノードとして使用できるようにします。

• ベアメタル サーバのサポート：RHEL 7.4、CentOS 7.4、Ubuntu 16.0.4 オペレーション システムを実行するネイティブ コンピュート ワークロードが含まれます。これにより、ユーザーは VLAN やオーバーレイ バッキング接続を介してベアメタル コンピュート ワークロードを接続できるほか、仮想から物理への通信フローや物理から物理への通信フローに対してマイクロセグメンテーション ポリシーを適用（ステートフル レイヤー 4 を適用）することができます。
• ベアメタルの Linux コンテナのサポート：Kubernetes および RedHat OpenShift Container Platform を使用して、RHEL 7.4 または RHEL 7.5 を使用したベアメタルの Linux ホスト上で Docker Containers を実行します。

※引用：リリースノート(　https://docs.vmware.com/jp/VMware-NSX-T-Data-Center/2.3/rn/VMware-NSX-T-Data-Center-23-Release-Notes.html　)

クラウド連携としては上記のとおり、AWSとAzureの機能強化を連携しています。コンテナ対応はベアメタルのLinuxサーバ及びベアメタルのLinuxコンテナをサポート強化しています。


NSX-Tは将来のハイブリッドクラウド、コンテナを見据えたアップデートがされているようなので、今後は注目の製品だと感じています。

NSX Data Center License Edition

2018年5月からVMware NSXのライセンス体系が変更になっているのはご存知でしょうか？

これまでNSXといえば、分散FWができて、VXLANが利用できて、Edgeでいろいろなサービス動かせてというのがNSXでしたが、名称もVMware NSX Data Centerへ変更となりました。

よって、これまでのNSXといったらNSX Data Centerのこととなります。


参考までにNSXファミリーについて簡単にご紹介します。

NSX Data Center
先ほど紹介しましたとおり、これまでのNSXと同等製品となります。

NSX Hybrid Connect
vsphere 5.0との相互運用でも利用できる製品で、旧環境からの移行や、平行運用などで
利用できます。

NSX Cloud
マルチクラウド、マルチサイトにネットワークとセキュリティを提供する製品

NSX SD-WAN by VeloCloud
2017年末にVMware社が買収したVeloCloud社製品。
SD-WANソリューションを提供


では、タイトルにもどりNSX Data Centerのライセンスについてです。

これまで、NSXのライセンスはStandard, Advanced, Enterpriseの3種類でした。
分散FWを利用したマイセグや、Edge LBを利用するのであればAdvancedライセンスで、
Cross vCenter NSXやVPNを利用するのであればEnterpriseといった感じで選定していました。

では、新しいライセンス体系ですが、以下のようになりました。

・Standard
分散スイッチング、分散ルーティング、Edge FWなど

・Professional
Stdに加え、分散FW、VPN(L2,L3)など

・Advanced
Proに加え、Edge LB、分散FWとADやAirWatch連携、マルチサイト、コンテナ、HW VTEPなど

・Enterprise Plus
Advに加え、vRealize Network Insight Advanced、NSX Hybrid Connect Advanced

・ROBO
リモートオフィス向けの一部機能


価格帯はまだ確認していないのですが、分散FWを導入するためにはAdvではなくProでいいので、NSXの導入敷居も低くなったのではないかと思います。

VMware Cloud on AWSって？

VMware Cloud on AWSの東京リージョン開設が近づき、徐々に日本語情報も出始めましたね。

VMware Cloud on AWSはざっくりいうと、オンプレのvSphere環境とAWSのハイブリッドクラウドというところですが、仮想マシンがオンプレとクラウドを行ったり、来たりになります。

それだけだとAWSじゃなくても。。。となってしまいますので、VMware Cloud on AWSの特徴的な部分をご紹介します。


まず、VMware Cloud on AWSの利点ですが、AWSのサイト(　https://aws.amazon.com/jp/vmware/faqs/ )では次のように紹介されています。


================================

VMware Cloud on AWS を使用する利点は何ですか?

VMware Cloud on AWS では、VMware ベースのデータセンターと AWS クラウド間で、一貫性のある相互運用可能なインフラストラクチャとサービスが提供されるため、多様な環境を管理する複雑さと、それに関連するリスクを最小限に抑えることができます。VMware Cloud on AWS により、AWS のサービスへのネイティブなアクセスや、ライフサイクルの中でエンタープライズアプリケーションの価値を高めるイノベーションを実現できます。

================================

簡単にいうと、オンプレとクラウドで同じ感じで運用できて、AWSのサービス(S3やElastic Load Balancing, Amazon RDSなどなど)も利用できるということです。

そして、現時点(2018,9,21)で利用できるリージョンは下の5か所となっています。

AWS 米国東部 (バージニア北部)
AWS 米国西部 (オレゴン)
AWS 欧州 (フランクフルト)
AWS 欧州 (ロンドン) 
AWS アジアパシフィック (シドニー) 

今時点で、日本から海外のリージョンを利用することもできますが、やはり距離の問題もあり遅延が大きくて操作にはストレスがあるとのことです。

そして、VMware Cloud on AWSを利用する場合には、オンプレ側がvSphere6.0移行である必要があります。



次回は、AWS側のハードウェア仕様を説明します。

vSANの重複排除とSSD障害

vSANではSSDとHDDを組み合わせたハイブリッド構成とSSDのみで構成するAll Flash構成を組むことができます。

All Flash構成の場合、SSDの価格が安くなったとは言えHDDに比べればGB単価は高く、容量効率化のため重複排除や圧縮などの利用を検討されることもあると思います。

重複排除と圧縮で容量削減できてSSDを必要以上に搭載する必要もなく、お財布的にも有効な機能ではありますが、ちょっと注意点を。。。

まず、注意点の前に理解しておくことですが、vSANの重複排除の単位はクラスタではなくディスクグループ単位となります。

なので、重複排除を利用している環境でキャパシティディスクの障害が発生した場合には障害が発生したディスクが含まれるディスクグループ全体がアクセス不可となります。よって障害復旧までの時間が重複排除無しの環境に比べて長くかかる傾向にあります。

ハイブリッド構成およびAll Flashで重複排除を利用していない場合は、影響範囲は障害が発生したディスク1本のみとなります。

重複排除は価格面でとてもメリットのある機能ですが、平常運転時のみではなく障害発生時、復旧時の挙動も理解したうえで利用していただければと思います。

NSX Edge on Bare Metal

NSXには仮想NWアプライアンスとしてEdgeが提供されていて、EdgeではRouting、Firewall、LoadBalancerなどNWの機能を提供しています。

NSX-VではEdgeはESXi上に展開されますが、NSX-TではBare Metalとして物理環境に直接Edgeを導入することができます。

まだまだ利用されることは少ないからでしょうか、インストール要件の条件(サポートされるハードウェア)がまだまだ少ないのが現状です。


※NSX-Tのマニュアルから要件の抜粋

NSX Edge 仮想マシンとベア メタル NSX Edge CPU の要件

ハードウェア	タイプ
CPU	Xeon 56xx (Westmere-EP) Xeon E7-xxxx（Westmere-EX 以降の世代の CPU） Xeon E5-xxxx（Sandy Bridge 以降の世代の CPU）

ベア メタル NSX Edge 固有の NIC 要件

NIC タイプ	説明	PCI デバイス ID
Intel X520/Intel 82599	IXGBE_DEV_ID_82599_KX4 IXGBE_DEV_ID_82599_KX4_MEZZ IXGBE_DEV_ID_82599_KR IXGBE_DEV_ID_82599_COMBO_BACKPLANE IXGBE_SUBDEV_ID_82599_KX4_KR_MEZZ IXGBE_DEV_ID_82599_CX4 IXGBE_DEV_ID_82599_SFP IXGBE_SUBDEV_ID_82599_SFP IXGBE_SUBDEV_ID_82599_RNDC IXGBE_SUBDEV_ID_82599_560FLR IXGBE_SUBDEV_ID_82599_ECNA_DP IXGBE_DEV_ID_82599_SFP_EM IXGBE_DEV_ID_82599_SFP_SF2 IXGBE_DEV_ID_82599_SFP_SF_QP IXGBE_DEV_ID_82599_QSFP_SF_QP IXGBE_DEV_ID_82599EN_SFP IXGBE_DEV_ID_82599_XAUI_LOM IXGBE_DEV_ID_82599_T3_LOM	0x10F7 0x1514 0x1517 0x10F8 0x000C 0x10F9 0x10FB 0x11A9 0x1F72 0x17D0 0x0470 0x1507 0x154D 0x154A 0x1558 0x1557 0x10FC 0x151C
Intel X540	IXGBE_DEV_ID_X540T IXGBE_DEV_ID_X540T1	0x1528 0x1560
Intel X550	IXGBE_DEV_ID_X550T IXGBE_DEV_ID_X550T1	0x1563 0x15D1
Intel X710	I40E_DEV_ID_SFP_X710 I40E_DEV_ID_KX_C I40E_DEV_ID_10G_BASE_T	0x1572 0x1581 0x1586
Intel XL710	I40E_DEV_ID_KX_B I40E_DEV_ID_QSFP_A I40E_DEV_ID_QSFP_B I40E_DEV_ID_QSFP_C	0x1580 0x1583 0x1584 0x1585

ベア メタル NSX Edge のメモリ、CPU、ディスクの要件

メモリ	CPU コア	ディスク容量
32 GB	8	200 GB

どのようなシチュエーションで利用するかは今後書いていきます。

NSXとエンジニア

ITニュースサイトのクラウドウォッチに国内SDN市場の記事(2018/8/20）が掲載されていました。

クラウドウォッチ(国内SDN市場)

記事によると、国内SDN市場は3強(VMware, Cisco, NEC)でそのうちオーバーレイ型はVMware、コントローラアプライアンス型のCiscoとNECに分けられています。

記事内のグラフを見てみるとSDN市場が急速に拡大していることが推測でき、その中でもコントローラ型に比べてNSXの売り上げはかなり大きなものだと見て取れます。

NSXは当初セキュリティの観点でマイクロセグメンテーションを目的とした導入ほとんどだったようですが、昨年からはネットワーク仮想化での検討が増えてきた印象で、将来のマルチクラウド環境の導入まで考慮している企業が多くなっています。

個人的にはここ2，3年でNSXも急速に広がっていくのではないかと思いますが、課題なのは構築はだれが？　運用はだれが？だと思います。

NSXは当然ネットワークの知識が必要ですが、仮想サーバ(vSphere)の知識も必要です。サーバエンジニアが今までのスキルでは扱いきれないですし、ネットワークエンジニアもESXやvCenterなど仮想化のスキル習得も必要です。

エンジニアもサーバだけ、ネットワークだけでは生き残れない時代になってきています。デジタルトランスフォーメーションと同時にエンジニアトランスフォーメーションも必要になっています。

NSX-T 2.2.1 Maintenace release!

2018/7/19にNSX-T 2.2.1 メンテナンスアップデートがリリースされました。

アップデート内容はバグフィックスに加えて以下内容になります。

What's New

NSX Container Plug-in 2.2.1 is a maintenance release specifically for the NSX Container Plug-in (NCP) feature of NSX-T 2.2. This release resolves a number of issues found in previous releases and has the following new features:

• Support for limiting SNAT IP pool to specific Kubernetes or OpenShift namespaces or PCF orgs.
• Pivotal Application Service (PAS) NSX-T tile improvements.
• Open vSwitch is now a separate package.
• Improvements in Open vSwitch kernel module compilation.

メンテナンスリリースなので大きな機能追加はありませんが、Pivotal系サービスとの連携が強化されたイメージです。

NSX-Tでホストの追加

NSX-Tのホストの追加手順を簡単ですが、紹介したいと思います。

ホストの追加自体は難しいことはないので、下のスクリーンショットを確認してもらうだけでも把握いただけるのではないかと思います。

 NSX Managerログイン後に左ペインから Fablic → Nodeを選択し、右ペインで +Addを選択します。

追加するホスト情報を入力し、Saveボタンを選択します。
　・Name
　・IP Addresses
　・Operationg System (ESXi, RHEL KVM, Ubuntu KVMから選択)
　・Username
　・Password

Yesボタンを選択します。

Deployment Stausが NSX Installedになればホストの追加は完了です。

このあとにTranxport Nodeの設定などホストをNSXで利用するための設定が必要となりますが、そこは今後書いていきます。

VMware NSX-VとNSX-T

ネットワークの仮想化といえばNSXですが、NSXにはNSX-VとNSX-Tの2種類があるってご存知でしたか？

一般的には単にNSXといったらNSX-Vをさしますが、NSX-Tも徐々に注目されてきています。 ※VはvSphere、TはTransformの略

NSX-VはvSphere用のNSXで、NSX-Tはマルチハイパーバイザ対応となっていて、最新のNSX-T2.2以下のハイパーバイザをサポートしています。

ハイパーバイザ	NSX-T2.2	NSX-T2.1	NSX-T2.0
vSphere	6.7.0, 6.5U2, 6.5U1	6.5U1, 6.5	6.5U1, 6.5
RHEL KVM	7.4	7.4, 7.3	7.3
Ubuntu KVM	16.04.2 LTS	16.04.2 LTS	16.04.x

また、最新のNSX-T2.2のリリースノートには次のような記載があり、マルチハイパーバイザ環境およびパブリッククラウドでNSXを利用したネットワーク仮想化が実現できるようになります。

「オンプレミス ワークロードおよび Azure のワークロードを 1 つの画面で管理できます。」


NSX-TはNSX-Vに比べて機能的にはまだ追いついていない部分もありますが、今後はNSX-Tの機能拡張も予定されていて遠くない未来にはNSX-Vに機能としては追いつくのではないかと思います。

じゃぁ、実際に操作感はというと。。。
GUIはNSX－Vと全く違います。

NSX-Vは基本的にはvCenterからNSXの設定を行いましたが、NSX-TはNSX Managerにログインして設定を行います。

そして、以下がNSX-Managerのログイン画面と、ログイン直後の画面になります。

NSX-Vとはまったく違いますね。

まだ、私もそれほどいじってはいないのですが、画面デザインの違いはあれど
まぁまぁ、こんな感じってのは理解できます。

もうちょっと操作してみて、私自身NSX-Tをもう勉強していきたいと思います。

NSX Command Guide

NSXの操作は基本的にはGUIでできますが、一部操作はCLIを利用しますし、NWの設定はCLI！　という意見もあるかと思います。

基本的にはVMware社から公開されているマニュアル( NSX Command Line Interface Reference ) を参照してもらえればと思いますが、ちょっと簡単にWebで。。。だったりよく使うコマンドを。。。といったことが私自身多いので、私なりに準備してみました。


NSX Command List


とりあえず、暇なときに少しずつ書き溜めていきたいと思いますが、思い付きでやっているので使いにくかったりしたら、途中で削除するかもしれないです。

NSX Controller の Syslog 設定

前回、CLIユーザの作成でPostmanを利用してユーザの役割設定を行いましたが、
今回もAPIを利用しないと設定できない項目であるNSX ControllerのSyslog設定について
書いてきます。

NSXのSyslog設定というとNSX ManagerにGUIログインすることによってSyslogサーバの
設定はできますが、ここで設定できるのはNSX ManagerのSyslog設定であって、ControllerのSyslogまでは設定できません。

  ※いつものとおりHOL-1803のスクリーンショットです。


では、HOL-1803を利用してNSX ControllerのSyslog設定を行ってみます。

Authorizationは前回同様にBasicにして必要事項を入力します。

リクエストメソッドは Get のままで、URLは以下を入力して、Send ボタンを押します。

https://NSX-ManagerのIP/api/2.0/vdn/controller


スクリーン下段に結果が表示されるので、<id>Controller-ID</id>の項目を探し、
Controller-IDを控えておきます。
　※通常はController*3台分


では、先ほど控えたController-IDを利用して、現在のControllerのsyslog設定を確認してみます。

https://NSX-ManagerのIP/api/2.0/vdn/controller/controller-ID/syslog

初期段階ではNSX ControllerにSyslogが設定されていないため、<details>にSyslog Server is not configuredと表示されていることが確認できます。


では、ここでNSX ControllerにSyslogサーバを設定します。

リクエストメソッドは Post に変更してURLはさっきのSyslog設定を確認したURLのままにします。
Bodyを選択してrawのXML(application/xml)は前回と同様です。

以下を入力し、Sendボタンを選択します。

<controllerSyslogServer>
<syslogServer>SyslogサーバのIP or FQDN</syslogServer>
<port>514</port>
<protocol>UDP</protocol>
<level>INFO</level>
</controllerSyslogServer>

右下部のStatusが200 OKと表示されていればNSX ControllerにSyslogサーバの設定が完了しています。

再度、NSX ControllerのSyslog設定を確認してみます。

先ほどは、<details>にSyslog Server is not configuredと表示されていましたが、Syslog設定後にはSyslogサーバ情報が表示されていることが確認できます。

これで1台のSyslogサーバ設定が完了したので、残りのControllerにも設定を行えば完了です。


HOLのテキストにはSyslog設定手順はありませんが、やってみると簡単なのでぜひ試してみてください。

NSX Manager CLI User の作成

NSX Managerのユーザ追加は通常GUIで行います。

上のスクリーンショットの +ボタンからユーザを追加できますが、こちらで追加できるユーザは以下の4つのRoleとなります。

Role	実行可能範囲
Auditor	参照のみ
Security Administrator	セキュリティ関連。分散FirewallやNATなどの一部サービスの操作
NSX Administrator	EdgeのデプロイやNSXの操作
Enterprise Administrator	Edgeのデプロイや操作とセキュリティの操作

ですが、ここではNSX ManagerのCLIユーザは追加することができず、NSX ManagerでCLIを利用して作成する必要があります。

> enable　←Privilegedモードへ移行

password: xxxxx　←パスワード入力

#conf t　←Configuration Modeへ移行

(config)#user ユーザ名 password plaintext パスワード　←ユーザ作成とパスワードの設定

(config)#user ユーザ名 privilege web-interface　←作成したユーザにAPIの実行権限を付与

(config)#write mem　←設定保存

(config)#exit

#

CLIでユーザを作成しただけではRoleがアサインされていないため、GUIのリストにはユーザが表示されません。

CLIで作成したユーザへのRole設定はAPIで行います。

①で POST 選択して、下のURLを入力します。
https://<NSX-Manager-IP Address>/api/2.0/services/usermgmt/role/<userId>?isCli=true

②で認証の項目を入力します。
Type：Basic Auth
username :admin
password：adminのパスワード

③でBodyタブを選択し、raw、XML(application/xml)を選択します。
Request　Bodyには以下の内容を入力します。

<accessControlEntry>
<role>new-role</role>　←割り当てるロール(auditor, security_admin, enterprise_admin, vshield_admin, super_user)
<resource>
<resourceId>globalroot-0</resourceId>
</resource>

</accessControlEntry>

④のSendボタンを押すと、⑤のステータスが 204 No Content と表示されれば完了です。

先ほどGUIで表示されていなかったCLIユーザが表示されていることが確認できます。

NSXは基本はGUIで操作が完了しますが、CLIやAPIを利用する必要があることもあります。APIはちょっと難しそうだなぁということで抵抗あるひとも多いかと思いますが、

利用してみれば意外と簡単なのでチャレンジしてみてください。