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をもう勉強していきたいと思います。