インフラSE修行日誌

2017年2月12日日曜日

NSX for vSphere 6.3リリース

ついにNSX for vSphere6.3(以下NSX)がリリースされました。
今回のリリース最大の魅力はなんと言っても、vSphere6.5の対応ですが、それ以外にもなにげに凄い機能がいろいろ入っています。

リリースノートをベースにご紹介をしたいと思います。

＜機能強化＞
・コントローラー切断操作（CDO）モード：コントローラー切断操作（CDO）モード
NSXコントローラーとの接続が失われても、VXLAN等のデータープレーンに影響を与えない機能強化となるようです。

・Closs vCenter NSXアクティブ - スタンバイDFWの拡張機能
Closs vCenter NSXにおける分散FWの機能が強化されています。

・コントロールプレーンエージェント（netcpa）自動回復
netcpaのプロセス監視を行い、自動起動処理を行います。また、再起動時はsyslogにてログの出力が行われます。

・vSphere6.5の対応
これは、見たままですね。

＜準拠＞
・FIPSへの対応
REST APIをコールすることで、、FIPSおよびCommon Criteria標準に準拠した暗号スイートのみを使用する可能。

・NSXはEAL2 +保証レベルに準拠、ICSAに準拠
セキュリティ製品でよく見るICSAにNSXは対応したようです。また、ICSAに準拠するため、分散FWのログ出力形式が変更になったと記載があります。

＜サービスとルーティングの強化＞
・BGPの4バイトASNサポート

・NAT機能の拡張
一致基準は、プロトコル、送信元IP、送信元ポート、宛先IP、宛先ポートの5つのパラメータに基づくように変更。それに伴いUIも変更。（これは、NSX Edge Service Gateway(ESG)に適用されます）

・レイヤ2 VPNのパフォーマンスの向上
1つのEdgeアプライアンスで最大1.5 Gb/sのスループットをサポートできます。これは、以前の750 Mb/sからの改善となります。（これは大きいですね）

・OSPFの改善
OSPFを設定する際、NSSAはすべてのタイプ7 LSAをタイプ5 LSAに変換できます

＜セキュリリティ強化＞
・分散ファイアーウォールにおけるセッションタイムアウト
セッションタイマーがNSX6.3から導入されます。これは、利用するアプリケーションによっては注意が必要です。

・マイクロセグメンテーションの強化
アプリケーションマネージャーを利用した自動ファイアーウォールルールの作成、エンドポイントモニタリングによるネットワーク接続プロセスの特定

・ゲストイントロスペクションのLinuxサポート
エージェントレスのウイルス対策に、なんとLinux OSがサポート！！
ただし、利用できるOSは、「RHEL7 / Suse ES 12 / Ubunts 14.0.4」に制限されています。

・Service Composerのステータス情報の表示

・NSX6.3が、vCloud Director 8.2に対応

＜インストールとアップグレード＞
・NSXカーネルモジュールはESXiバージョンとは無関係になりました。
これで、今後バージョンアップ時にはESXi再起動の回数が減ると思います。

・ホスト上での再起動なしのアップグレードとアンインストール
vSphere 6.0以降では、NSX 6.3.0にアップグレードすると、それ以降のNSX VIBの変更は再起動する必要はありません。

・OVFパラメータがカンマ区切りに対応
DNSサーバー、ドメイン検索リスト、NTPサーバリストが、カンマ区切りで複数のパラメーターを入れられるようになりました。

・NSX6.3の対応ESXi
ESXi5.5 Update3、 ESXi6.0 Update2、ESXi6.5がサポートになります。
どのESXiも最新パッチが適用されていることが条件になっていますので注意が必要です。

アップグレード時の注意事項もかなりたくさん記載されていますので、是非NSX6.3を利用する前にリリースノートを読まれるとよいかと思います。

（参考）
NSX for vSphere 6.3 リリースノート

2017年2月11日土曜日

vRealize Operationsで、OSIライセンスを上手に（節約）使う方法

vRealize Opeations(vROps)は、vSOMやCPUライセンスで購入していない場合、25OSI（OS Instance)単位での購入となります。
仮想環境内だけで、vROpsをOSIライセンスで利用する場合、管理監視対象にしたい仮想マシンとしたくない仮想マシンが同じvCenter Serverで管理されている場合、不要にOSIライセンスが消費されるといった問題が生じます。

vROpsのライセンスの画面を見ると保有ライセンスに対してvROpsで監視されている仮想マシン台数が表示されています。

では、管理監視をvROpsで行う必要がない仮想マシンまでもライセンスを手配するとなるとコスト的な問題が出てくることがあります。

vROpsは、きちんとこのあたりのことを考えており、vROpsの監視対象から外す機能が存在しています。それは、関連ライセンスグループの機能を利用します。

まずは、ライセンスのメニューから「ライセンスグループ」を選択し、既存のライセンスグループを編集するか新規で作成します。

適用するフィルターを入れたいライセンスキーを選択します。

ここで、仮想マシン名の条件を設定することができます。

この後サマリーが表示されますので確認後、完了をクリックします。
これで、条件に入れたオブジェクトが除外されるはずです。

OSIライセンスを上手に使いたい場合、この方法をうまく使うことでライセンスを節約することが可能です。

2017年1月28日土曜日

vSOMとvRealize Operationsのライセンス改定について

vSphereとvRealize Operations(vROps)がセットになったvSOMというライセンス製品は、すでにご存知の方も多いと思います。
昨年に、この辺りのライセンス体系が変更になっていますので、今日はこの辺りを改めてご紹介したいと思います。

■vSOMについて
従来、vSOMには、Standard、Enterprise、Enterprise Plusという選択肢がありました
このエディションは、vSphereのエディションであり、どのエディションを手配してもvRealize OperationsのライセンスはStandardであるというのが従来までの注意点でした。ただ、vSpehreのライセンス改定が行われ、StandardとEnterprise Plusだけになったこともあり、vSOMは、vSphere Enterprise Plus と vRealize Operations Standardの一択になりました。
この点は、注意が必要です。

■vRealize Operations単体のライセンス体系増加
vSOMは、CPU単位での手配となるため、利用できるvRealize Operationsも、そのESXiが稼働する物理CPUに紐づくライセンスでした。
一方で、vRealize Operationsは、25OSI(OS Instanceの略で物理もしくは仮想マシンを1とカウント）単位であり、CPUライセンスとして手配することができないという特徴がありました。
この場合、vRealize Operations Standardを利用したいケースで高集約な環境の場合、vSOMの方が割安になるケースがありましたが、昨年のライセンス体系変更で、vRealize Operations Standardおよび、Advancedは、CPUライセンスでの提供が開始されました。
VMwareのホームページ上には、「Standard」のみがCPUライセンスで販売されるような記載がありますが、そののち、「Advanced」もその対象になったようです。

実際に、VMwareのサイトでダウンロードできるデーターシートには、ライセンスの形態として、vRealize OperationsのStandardとAdvancedにて、CPUライセンスが提供される記載があります。

（参考）vRealize Operationsのデーターシート

今まで、vRealize Operationsの良さは理解していても、OSI単位のライセンスで手が届かなかった方にもこの機会に、検討してみるのもよいかもしれません。

2017年1月14日土曜日

NSX for vSphereを利用する際に必要なリソース

NSX for vSphereを利用するには、NSX ManagerやNSX Controllerなどの様々なコンポーネントが必要となり、リソースもそれなりに必要になります。

導入をする際には、あらかじめサーバーリソースのサイジングが必要になります。

実際にNSX for vSphereで必要なリソースの一覧を紹介したいと思います。

■NSX Manager + NSX Controller (必須コンポーネント）

名称	vCPU	RAM	HDD	備考
NSX Manager	4	16	60	NSX適用サイズによっては、8vCPUを適用
NSX Controller 1	4	4	20	1環境に最低３台必要
NSX Controller 2	4	4	20
NSX Controller 3	4	4	20

■NSX Edge (Edge Service Gateway）

名称	vCPU	RAM	HDD	備考
NSX Edge Service Gateway 小	1	0.5	0.5	HA構成にする場合は、２台分のリソースが必要一般利用用途の場合は、サイズは大以上
NSX Edge Service Gateway 大	2	1	1
NSX Edge Service Gateway 特大	4	1	1
NSX Edge Service Gateway 超特大	6	8	2.5

Edge Service Gatewayは必須コンポーネントではありませんが、VPN機能などを利用する場合に必要になります。
HA構成を組む場合、VM-HAとは別にEdge Service Gateway独自の機能を利用しますので、VAが2台稼働することなります。そのため、HA構成の場合は、VAのリソースを×２で積算しておく必要があります。
Edge Service Gatewayは、1つの環境に複数立てることができます。その場合、その数量分のVAが稼働するため、Edge Service Gatwayのサイズに応じたリソースがVAの数分、必要となります。

■その他サービスVA

名称	vCPU	RAM	HDD	備考
Guest Introspection	2	0.5	4	vShield Ednpoint及びアージェントレスアンチウイルス機能利用時に必要なVA。 ESXiホストの台数分だけ積算が必要
NSX Data Security	1	0.5	6	ESXiホストの台数分だけ積算が必要

Trend Micro Deep Securityなどを利用して、エージェントレスアンチウイルス機能を利用する場合、Guest Introspectionが必要となります。
上記のVAは、有効にするクラスターのESXiホストの台数分だけVAが展開されます。

■vCenter Server 6.5
・PSC組み込みの場合・vCenter Server単独の場合

名称	vCPU	RAM	HDD	備考
極　小（ESXi10台 / VM100台）	2	10	250
小規模（ESXi100台 / VM1000台）	4	16	290
中規模（ESXi400台 / VM4000台）	8	24	425
大規模（ESXi1000台 / VM10000台）	16	32	640
超大規模（ESXi2000台 / VM35000台）	24	48	980

・PSC

名称	vCPU	RAM	HDD	備考
PSC	2	4	60

vCenter Serverは、PSCが必ず１つ必要です。複数のvCenter Serverを設置せず1台のvCenter Serverで運用を行う場合、PSC+vCenter Serverの構成で問題ありません。
vCenter Serverは、管理するESXiホストと仮想マシンの数によって利用するリソースが異なります。

■おまけ・TrendMicro Deep Security

名称	vCPU	RAM	HDD	備考
Deep Security Manager	4	8	100	SQL Serverの別途手配が必要です
Deep Security VA （〜32VM）	4	4	20	Guest Introspection VAと同じ台数分だけ展開が必要
Deep Security VA （〜64VM）	4	6	20
Deep Security VA （65〜VM）	4	10	20

Relayサーバーを別建てする場合は、Relayサーバーのリソースが別途必要となります。
DeepSecurity VAは、稼働するESXiホストで稼働する仮想マシンの台数によってリソースのサイズが異なります。
Deep Security VAは、機能を有効にするクラスターのESXiホスト分だけVAが展開されます。

※NSX for vSheildを利用する場合のリソースについて
NSX for vShieldについては、NSX ManagerとGuest Introspectionが利用するリソースになります。NSX ControllerやNSX Edgeは、利用しませんのでリソースに含む必要はありません。

サイジングをする際には、これを見てExcelに入れていただければ、あとからのリソース不足に陥ることはないと思います。

（参考）
NSX for vSphere のシステム要件
http://pubs.vmware.com/NSX-62/index.jsp#com.vmware.nsx.admin.doc/GUID-311BBB9F-32CC-4633-9F91-26A39296381A.html

ｖCenter Server Applianceのシステム要件
http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.install.doc/GUID-88571D8A-46E1-464D-A349-4DC43DCAF320.html

2017年1月8日日曜日

HW-VTEPを活用したVX-LAN

NSXにおけるネットワーク仮想化において、非常に重要な役割を果たすのが、VXLANです。
そのVXLANの通信を行うために必要なものが「VTEP」（VXLAN Tunnel End Point）です。

VTEPは、VXLAN通信のL2フレームをUDPパケットにカプセル化し、L3ネットワークに通信を流し、受取先で、UDPのカプセルを外し、元のL2フレームに戻す役割があります。

このVTEPは、通常NSX-vを利用する場合、NSXを有効化した各ESXiホストにvibモジュールとしてカーネルにインストールされ、ESXiホストでVTEPが動作します。

しかし、ネットワークアプライアンス機器など物理層のネットワークとの接続においては、NSXのVXLANと直接通信をする方法がなく、VXLAN - VLANブリッジを行う必要がありますが、この場合特定のESXiホストに通信が寄ってしまうという問題もあります。

そこで、登場するのがHW-VTEP（ハードウェアヴイテップ）というものがあります。
HW-VTEPとは、物理的な機器でVTEPが動作する機器のことになります。

現状、NSX for vSphereに対応しているHW-VTEPは、

Arista Network 7050/7060/7150/7250/7280E
HPE 5930 / 5940
Brocade VDX6740 / VDX6940
DELL S4048 / S6000
Juniper QFX5100

になります。

これらの機器を使えば、VXLANを物理ネットワークとの接続に利用できるようになり、NSXにおけるネットワーク設計時にも、シンプルかつ融通のきく構成ができるようになるかと思います。

尚、NSX for vSphereで対応するHW-VTEPは、コンパチビリティリストから確認することができます。

VMware Compatibility Guide Hardware VXLAN Gateway

http://www.vmware.com/resources/compatibility/search.php?deviceCategory=hvxg

2016年10月16日日曜日

NSXコンポーネントの起動とシャットダウン手順

NSX for vSphere(NSX-v)は、NSX ControllerやNSX Manager、Edge Service Gatewayなどかなりのアプライアンスが展開されます。

例えば電源設備のメンテナンスなどでESXiホストの電源などを落とす際にどの順序で落とすのが正なのかというのが、わからないというケースに出会うこともあるかと思いますので、今回は、シャットダウン及び、起動の手順をお伝えします。

＜シャットダウン順序＞

セカンダリNSXマネージャーのシャットダウン（マルチvCenterの場合のみ）
プライマリNSXマネージャーのシャットダウン
プライマリサイトNSX コントローラーのシャットダウン
分散論理ルーター（DLR ）制御VMのシャットダウン
一般仮想マシン及びGuest Introspection、NSX Edge等のNSX関連仮想マシンのシャットダウン
（シャットダウンの順序は任意）
ESXiホストのシャットダウン

＜起動順序＞

ESXiホストのパワーオン
vCenter Serverのパワーオン
NSX Managerをパワーオンし、「NSX Management Service」が起動していることを確認
（マルチvCenter構成の場合は、はじめにプライマリNSX Managerを、次にセカンダリNSX Managerを起動します）
Guest Introspection及びNSX関連のサードパーティーVM（たとえば、Deep Security Manager等)を起動します。
NSXコントローラーをパワーオン
vSphere Web Clientから「Network and Security」の「インストール手順」項の「管理」タブの「NSX コントローラーノード」を確認し、NSXコントローラーが正しく起動及びNSX Managerによって認識されていることを確認します。※
NSX Edge及び分散論理ルーター（DLR ）制御VMのパワーオン
一般仮想マシンのパワーオン

※NSXコントローラーの確認場所

シャットダウン手順に比べ、起動手順は少々順序が厳しいので注意が必要です。
UPS連携は、スクリプトでの対応が必要になるかと思います。

より詳細な手順は以下のKBを参考にしてください。

Shutdown/Startup order of the NSX for vSphere 6.x environment after a maintenance window or a power outage (2139067)

2016年10月10日月曜日

NSX for vSphereのSSLVPNを使ってみよう（その１）

NSX for vSphereで提供される、Edge Service Gatewayには、「SSL VPN Plus」と言われる、端末VPNの機能が提供されています。
これ、あまり知られていないケースが多いのですが、いわゆる端末にインストールしてSSLでVPNトンネルを張ることができる製品です。

このSSL VPN Plusですが、元々は、NeoAccel社のSSL VPN Plusをカスタマイズしたものになっています。そもそもNeoAccel社をVMwareが買収したことで、Edge Service Gatewayに実装されているようです。
このNeoAccel社のSSL VPN Plusですが、あまり見覚えはないかもしれませんが、6年ぐらい前にアライドテレシスがSSL VPN Plusという形で、独自アプライアンスにSSL VPN Plusを導入したアプライアンスを販売していました。

[アライドテレシスのホームページより]

（参考）https://www.allied-telesis.co.jp/products/list/others/sslvpn/sslvpnplus/catalog.html

このページを見てもらえればわかりますが、ユーザーサイドの画面は今でもほとんど変わっていません...。

NSX SSL VPN Plusで提供されるWindowsクライアントの画面

ちなみに、対応クライアントはNSX-v 6.2.4の場合以下となります。

OS	対応バージョン
Windows	XP以降～Windows 8
Linux	ユーザーインターフェイスを機能させるには TCL-TK が必要です。 TCL-TK がない場合は、CLI を使用します。
Mac	Tiger、Leopard、Snow Leopard、Lion、Mountain Lion、Maverick、Yosemite、ElCapitan

NSX-vでSSL-VPNを利用すると、CPUライセンスでNSXを購入した場合、そのESXiホストにEdge Service Gatewayを大量に展開すれば、大量のユーザーに対して安価にSSL-VPNを提供することも可能です。

尚、1つのESGで接続できる最大ユーザーは以下が最大値となっているようです。

ESGのサイズ	最大接続数
compact	50
large	100
quad-large	100
x-large	1,000

（参考）https://d-fens.ch/2015/02/16/nsx-v-6-1-configuration-maximums/

次回から、SSLVPNの利用するまでの設定方法とAD連携などをご紹介したいと思います。

登録: 投稿 (Atom)