2017年6月10日土曜日

NSX for vSphere 6.3.2 リリースとバグフィックス内容について

NSX for vSphere 6.3.2が2017/6/8にリリースされました。
今回はバグフィックスが中心ですが、かなり大きな修正が入っております。もし、NSX6.3.0や6.3.1を利用されているのであれば、積極的にバージョンアップをしたほうが良いと思われるような内容も多く含まれています。

実際にNSX6.3.2のリリースノート(今日時点では英語ですが)を日本語でまとめてみましたので、それをもとに重要な個所を見ていきたいと思います。(重要と思われる修正番号を赤色にしています)

(参考)NSX for vSphere 6.3.2リリースノート
http://pubs.vmware.com/Release_Notes/en/nsx/6.3.2/releasenotes_nsx_vsphere_632.html



--- NSX for vSphere 6.3.2 Release Notes ---

NSX 6.3.2の一般的な解決済みの問題
修正済みの問題1839275
ハードウェアVTEPスイッチの背後にある物理サーバーとの接続が失われる
ホストVMにデータプレーンとコントロールプレーンの両方が存在し、すべてのネットワークケーブルの物理的な断線によってコントロールプレーンがダウンすると、仮想マシンはハードウェアVTEPスイッチと接続された物理サーバーとの接続を失います。


◆インストールとアップグレードNSX 6.3.2で解決された問題
修正済みの問題1811218
ホスト再起動後に、NSX以外の設定済みvSphere Distributed Switches(VDS)のVMKernelポートが接続を失う。
複数のVDSを持つホストでは、NSXで設定されたVDSのVTEP VMKernelポートと同じdvPort IDを持つ場合、非NSXでのdvSwitchのVMKernelポートはホストの再起動後に接続を失います。
詳細については、VMwareのKB:2149116を参照してください。

修正済みの問題1850690
ゲストのイントロスペクションUSVMがディスクがいっぱいと報告される
VMware NSX for vSphere 6.3.x環境のGuest Introsepction VMにて、/var/logのディスクスペースがいっぱいになっているか、空き容量が少ないというアラートが表示されます。vRealize Operations Managerまたは仮想マシンのディスク容量を追跡するその他の監視ツールでも、同じアラートが表示されます。

★これは、DeepSecurityなどとのエージェントレスアンチウイルスをしていた場合において影響する問題です。Guest Introspection VAのディスク空き容量が少ないとアラートが出た場合は、まずはNSXのバージョンを確認しましょう。

修正済みの問題1854519
VLANからブリッジドVXLANへの移行後、north-west間の接続が失われます
VMネットワークがVLANからDLR上のブリッジのVXLANに切り替わると、VMへの入力トラフィックは失われます。 6.3.2で修正。


◆NSX 6.3.2で解決されたNSXマネージャの問題

修正済みの問題1814683
複数のHTTPスレッドが認可チェックにスタックしたときにNSXマネージャが応答しなくなる
NSXマネージャが応答しなくなり、再起動する必要があります。


◆NSX 6.3.2におけるネットワークとエッジサービスの解決済みの問題
修正済みの問題1681063
一部のエッジゲートウェイのVPNトンネルステータスがvCloud Directorに正確に反映されていない
vCloud Director(vCD)とNSXは、IPSec VPNトンネルのさまざまなステータスを表示します。 vCDは、トラフィックが流れていてもIPSecトンネルをDOWNとして表示されます。

修正済みの問題1827643
コントローラダウンイベント中のユニキャストフラッディング
コントローラダウンイベントが発生すると、コントローラが停止した直後に、すべてのL3データパケットがその論理スイッチ上のすべてのVTEPに送信されます。
これは、デフォルトのL2 MACエージングタイムがL3 ARPタイムアウトよりも短く、コントローラが使用中のMACテーブルエントリをリフレッシュするために使用できないためです。フラッディングは、その負荷に耐えられない場合NICで送信リセットを引き起こす可能性があります。
これにより、ハートビートプロトコルのパケットドロップが発生し、HAアプリケーションが影響を受ける可能性があります。
たとえば、NSX EdgeアプライアンスとHAを有効にしたDLRは、DLRとECMP ESGの間のOSPFにつながるスプリットブレイン状況に陥り、フラップします。

修正済みの問題1793575
IPハッシュチーミングが選択されている場合、すべてのNSXトラフィックが1つのNICから出力される
NSXポートグループがIPハッシュチーミングポリシー(スタティックEtherChannelまたはLACP)で設定されている場合、
これらのポートグループからのすべてのトラフィックは単一のNICから出力されます。
これによりトラフィックの損失は発生しませんが、使用可能なすべてのリンクにネットワーク負荷が分散されません。
NICの使用が失敗すると、すべてのNSXポートグループがチーム内の別のアクティブなNICにフェールオーバーします。
入力トラフィックは影響を受けず、使用可能なすべてのリンクで受信できます。 6.3.2で修正。

★NSXの設定を行う場合、LACPやイーサチャネル(LAG)を利用している場合が多いかと思いますので、こちらも要チェックです。

修正済みの問題1812445
重複したARP応答を持つ分散論理ルーター(DLR)の物理MACアドレス(PMAC)によってL2VPNブリッジテーブルが影響受ける
ホスト上のL2VPNサーバのvxlanトランクポートは、宛先MACがpMACであるクライアント仮想マシンから送信されたARP応答をドロップしません。これにより、ブリッジ上のMACテーブルがトラフィックを低下させます。

修正済みの問題1806934
OpenswanのCVE-2015-3240によりサービス拒否(DoS)
3.15より前のlibreswanのIKEデーモンとNSSを使用して構築された2.6.45より前のOpenswanは、リモートの攻撃者がIKEパケットのKEペイロードのゼロDH g ^ x値を使ってサービス拒否(アサーションエラーとデーモンの再起動) ができる脆弱性があります。

★Edge Service Gatewayを利用して、IPSECトンネル(VPN)を張っている場合は、こちらの脆弱性に該当しますので、バージョンアップを検討してください

修正済みの問題1811884
論理スイッチがUniversal Synchronization Service(Replicator)ホストで削除されない
Universal Synchronization Service(Replicator)ホストの論理スイッチを削除することはできません。

修正済みの問題1803220
コントローラとホスト間の接続が切断されたときにCDO対応ホストへのVXLAN接続が失われる
Controller Disconnected Operation(CDO)機能により、コントローラクラスタ全体がダウン/到達不能になったときにVXLAN接続が保証されます。
ただし、コントローラクラスタが稼働中でもホストとの接続が失われた場合、コントローラに接続されている他のホストからそのホストに送信されるデータプレーントラフィックは引き続き廃棄されることがあります。
この状態が発生すると、ホストはVNIごとのVTEPリストから削除され、リモートホストから送信されたARPは破棄されます。
コントローラとの接続が失われたホストからのトラフィックの場合、CDO機能により、適切な宛先に確実に到達できるようになります。

修正済みの問題1817673
DLR LIF IPが変更され、以前のIPがVMに割り当てられたときにESXiホストがクラッシュし、ルーティングの問題が発生する
ブリッジがアクティブなホストでパープルスクリーンが表示されます。 IPアドレスが以前のDLR LIFのIPアドレスであるVMと通信するとき、すべてのホストでDLRルーティングの問題が発生します。

VXLAN - VLANブリッジを行っている場合、注意が必要です。

修正済みの問題1825416
フェンス付きvAppのは、vSphere 6.3.xを含むためNSXにアップグレードした後、vCloud Directorでは8.20で失敗します
vCloud Director 8.20でNSX 6.3.xおよびNSX Edge Gatewayを6.3.xにアップグレードすると、フェンス済みvAppが失敗し、フェンス付きネットワーク内の仮想マシンがゲートウェイと通信できなくなります。

修正済みの問題1842337
ECMP ESGのDLR ARP解決に失敗しました。
ECMPのDLRでのARP解決は失敗し、North-Southトラフィックに影響を与えます。

修正済みの問題1834837
VIX通信モードで動作しているすべてのvCNSエッジ(バージョン5.5.4)およびNSXエッジ(6.1.xおよび6.2.x)は、ストレージvMotion後に管理不能になる
MessageBusを通信モードとして実行しているNSXエッジは影響を受けません。

Veeamなどのバックアップソフトウェアで、VIXを利用している場合、こちらに該当する可能性がありますので、こちらも環境によっては注意が必要です。

修正済みの問題1798469
ハイアベイラビリティのステータスが正しく表示されていても、一部のNSXエッジがスプリットブレインシナリオに入ることがある
HAメカニズムの競合状態により、NSX 6.2.5以降にアップグレードされた一部のNSXエッジは、「ハイアベイラビリティステータス」が正しく表示されていてもスプリットブレインシナリオになる可能性があります。 これは、エッジの再デプロイ後にも発生する可能性があります。

Edge Service GatewayをHAモードで利用している場合、こちらも症状が出る可能性がありますので、ESGを利用されている方は、お早目のバージョンアップをお勧めします。

修正済みの問題1828060
強制同期操作中にトラフィックが多い状態でNSX Edgeに接続の問題が発生することがある。
NSX Edgeは、Force Sync操作中にトラフィックが多い場合に接続の問題が発生する可能性があります。


◆NSX 6.3.2におけるセキュリティサービスの解決済みの問題
修正済みの問題1798537
ESXi(vsfwd)のDFWコントローラプロセスでメモリが不足することがある
DFW構成で大量のルールまたは大きなサイズのセキュリティグループが存在する環境では、ESXi(vsfwd)上のDFWコントローラプロセスがメモリ不足になり、ルールをデータパスに公開できません。

分散ファイアーウォールに多くのルールを書く場合、また、Service Composer等で大量のグループオブジェクトを作成している場合には該当する可能性があります。

修正済みの問題1853106
認証がチェックされていないか、PSKモードのIPsec VPNのIPsec設定の変更が変更された場合、UIでエラーが発生する
証明書ベースの認証でIPsec VPNのPSKモード認証がチェックされていないか変更されている場合、「グローバル設定」タブの「証明書と秘密を読み込めませんでした:002忘れた秘密」というエラーが表示されます。

修正済みの問題1725524
Hostdを再起動すると、RabbitMQを使用してデータを送信しているときにvsfwdがクラッシュすることがある
hostdプロセスを再起動する操作によって、vsfwdの接続が再確立されます。 一部のスレッドが古いチャネルを使用してデータを送信している間に、メインスレッドが古い接続をクリアしているときにvsfwdがクラッシュする可能性があります。

修正済みの問題点1800196
Broadcast MACアドレスを持つ多数のIPパケットがDistributed Firewallの拒否ルールと一致するとVMkernelのログ記録が停止する
分散ファイアウォールは、拒否パケットをユニキャストMACアドレスにのみ送信します。 ブロードキャストMACアドレスを持つIPパケットが拒否ルールと一致する場合、拒否パケットは送信されません。 ただし、このイベントはvmkernel.logに記録されます。 ネットワークがこのトラフィックでいっぱいになると、vmkernel.logはログストレスによってメッセージを廃棄し、ログは停止します。 ブロードキャストMACアドレスを持つパケットの拒否は、デバッグがイネーブルの場合にのみロギングされるようになりました。 6.3.2で修正。 ブロードキャストMACアドレスを持つパケットの拒否は、デバッグがイネーブルになっている場合にのみ記録されるようになりました。

ブロードキャスト通信とMACアドレスベースでのフィルターを利用している場合、ログが出なくなる恐れがありますので、こちらも要注意です。

修正済みの問題1807152
VMを1つのクラスタから別の新たに準備されたクラスタに移動すると、appliedToという仮想ワイヤを持つルールはVMに適用されません。
新しいクラスタをデータセンターに追加すると、[仮想ワイヤとして適用]を持つルールのクラスタリストは更新されません。 したがって、VMが古いクラスタから新しく準備されたクラスタに移行されるとき、ルールは適用されません。


修正済みの問題1812467
ネストされたSGの大文字小文字を使用する大規模なVMでのコンテナの更新で、ホストの更新が長く遅延する
ホストにSGがネスト化された大規模なVMがある場合、1回のインベントリ変更によってコンテナの更新がフラッシュされ、最終的にホストに変更が反映されるまでに非常に遅れが生じます。

修正済みの問題1847880
特定のクラスタ内のホストからVIBをアンロードすると、「vmkload_mod:モジュールvsipを削除できません:モジュールの消費されたリソース数がゼロではありません」というエラーが表示される。
VIBのアンインストールがトリガーされ、他のNSX VIBがアンインストールされると、コマンド”esxcli software vib list | grep vsip”にはまだインストールされているesx-vsipが表示されます。

修正済みの問題1812792
分割されたTCPハンドシェイクに関連するDFWパケットの廃棄。
分散ファイアウォールは分割されたTCPハンドシェイクを適切に処理しません。 ウインドウ計算が不正確であるため、今後のパケットドロップにつながるウインドウスケールオプションは無視されます。 これは、最初のSYN ACKパケットが失われ、SYNの再送信によって、分割されたTCPハンドシェイクを引き起こしたチャレンジACKが生成されたために発生していました。

リリースノートにおける、修正情報は、以上となります。

NSX6.3は、Linuxベースのアンチウイルス機能など新機能もありますが、既存機能のブラッシュアップがなされているバージョンとなります。
6.3.2では、かなりのバグが修正されていますので、本番環境でもNSX 6.3.2を利用してもよい状況になったと思います。既存で、NSX6.3.1以下をご利用の方は、ぜひお早目の6.3.2へのバージョンアップをお勧めします。




NSX6.3からの新機能セッションタイムアウトについて

NSX for vSphere 6.3の1つ大きな仕様変更が、分散ファイアーウォール機能にセッションタイムアウト機能がついたことです。
本来ファイアーウォールですから、一定時間利用していないポートを閉じるというのがセキュリティ上好ましいのですが、NSX6.2まではそのような機能実装はなくどちらかというとL3スイッチのような感じのACLで動作していた感があります。
今回のセッションタイマー機能は、まさに「ファイアーウォール」としては必要な機能が導入されたということになります。
このセッションタイマーについて紹介します。

まず、このセッションタイマー設定は、vSphere Web ClientのNetwork and Security→ファイアーウォールの画面から、新たに追加された"設定"タブ"を開きます。

ポリシーは、新規で追加可能ですので、自由にポリシーを作成できます。


まず各タイムアウト値ですが、TCP/UDP/ICMPで各パラメーターの設定が可能です。


ポリシーで設定できるパラメーターと範囲は以下の通りです。

TCP 説明
最初のパケット
(First Packet)
最初のパケットが送信された後の、接続のタイムアウト値です。デフォルトは 120 秒です。
設定範囲:10~4320000
開く
(Open)
2 番目のパケットが転送された後の、接続のタイムアウト値です。デフォルトは 30 秒です。
設定範囲:10~4320000
Established接続が完全に確立された後の、接続のタイムアウト値です。
設定範囲:120~4320000
Closing最初の FIN が送信された後の、接続のタイムアウト値です。デフォルトは 120 秒です。
設定範囲:10~4320000
Fin Wait両方の FIN が交換され、接続が閉じられた後の、接続のタイムアウト値です。デフォルトは 45 秒です。
設定範囲:10~4320000
Closed1 つのエンドポイントが RST を送信した後の、接続のタイムアウト値です。デフォルトは 20 秒です。
設定範囲:10~4320000
UDP 説明
最初のパケット
(First Packet)
最初のパケットが送信された後の、接続のタイムアウト値です。これは、新しい UDP フローの最初のタイムアウトになります。
設定範囲:10~4320000
単一
(Single)
送信元ホストが複数のパケットを送信し、宛先ホストが送り返さなかった場合の、接続のタイムアウト値です。
設定範囲:10~4320000
複数
(Multiple)
両方のホストがパケットを送信した場合の、接続のタイムアウト値です。
設定範囲:10~4320000
ICMP 説明
最初のパケット
(First Packet)
最初のパケットが送信された後の、接続のタイムアウト値です。これは、新しい ICMP フローの最初のタイムアウトになります。
設定範囲:10~4320000
応答エラー
(Error reply)
ICMP パケットへの応答で ICMP エラーが返された後の、接続のタイムアウト値です。
設定範囲:10~4320000

(参考)セッションタイマー
http://pubs.vmware.com/nsx-63/index.jsp#com.vmware.nsx.admin.doc/GUID-0A88046C-D77B-4380-99C3-A631A93E4999.html

なお、設定範囲はVMware提供のドキュメントには、設定できる範囲が記載されていませんが、画面上に設定範囲外の値を入力すると、設定できる範囲が表示されます。

また、このパラメーターの適用範囲は、「仮想マシン」と「vNIC」の2つから選択可能です。
仮想マシンの場合は、ポリシーに対して、仮想マシンを選択する形となります。

一方で、vNICの場合、仮想マシンから仮想NICを選択する形となります。

仮想NICごとにタイムアウトパラメーターを変更することが可能ですので、DBサーバーとアプリケーションサーバーのコネクションプールによる接続などが行われている場合、柔軟な設定が可能となります。

ちなみに、複数のポリシーを作成することが可能ですが、1つの仮想マシンや仮想NICなどのオブジェクトを複数のポリシーに適用させることはできません。1つのオブジェクト(仮想マシンまたは仮想NIC)は、かならず1つのポリシーにしか属せないという制約があります。なお、すでに別のポリシーが適用されたものを別のポリシーに二重で適用しようとした場合、「仮想マシンvNICはすでに別のタイマーの一部として設定されています。[解決]をクリックして、選択されたリストから削除してください」とエラー画面が表示されます。


ただし、タイムアウト値を「0」つまりタイムアウトさせないという設定はできませんので、注意が必要です。NSX6.3にアップデートした場合は、重要な仕様変更ですので、注意が必要です。




2017年5月31日水曜日

Edge Service Gatewayのファイアーウォールタイムアウト値について

ファイアーウォールにおいて、一定時間無通信だったポートを閉じるという機能は必要不可欠な機能ですが、このタイムアウト値は各ファイアーウォール機器によってまちまちです。では、NSX for vSphereで提供されるEdge Service Gatewayのタイムアウト値はどのようになっているのでしょうか?

これは、KB2101275にて掲載されています。

(参考)vCNS/NSX Edge Firewall TCP Timeout Values
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2101275

こちらをもとに確認していきたいともいます。
まず、このKBは、vShield EdgeとNSXのEdge Serviceと同一で記載されています。ここで重要なのはAPIバージョンです。NSXで提供されるEdge Service Gatewayは、API4.0が搭載されていることが、以下の表からわかります。

APIバージョン

リリースバージョンAPIバージョン設定の永続性
vCNS 5.1.2 and earlierNot supported-
vCNS 5.1.3 and laterapi/3.0No
vCNS 5.5.1 and laterapi/3.0No
NSX for vSphere 6.0 and laterapi/4.0Yes

設定の永続性とは、Edge Service Gatewayを再デプロイしたり、バージョンアップをした際に、以前に設定したパラメーターが引き継がれるかという意味になります。

各タイムアウト値は以下の通りとなります。

Protocol/State(Version 4.0)
Inactivity Timeout (seconds)
※NSXのEdge Service Gateway
(Version 3.0)
Inactivity Timeout (seconds)
※vShiled Edge 5.5.1/5.1.3
TCP Open
(SYS-SENT, SYN-RCVD states)
3030
TCP Established3,6003,600
TCP Close
(TIME-WAIT, FIN_WAIT states)
3020
UDP6030
ICMP/ICMPv61010
All other protocols120120

このパラメーターは、REST APIをコールすることで変更することができます。
NSXの場合、NSX ManagerにREST APIを発行します。

APIURL:https://nsx-manager/api/4.0/edges/{edgeId}/firewall/config/global
メソッド: PUT

送信するXML
<globalConfig> <!-- Optional -->...
  <tcpTimeoutOpen>30</tcpTimeoutOpen> <!-- Optional. Defaults to 30 -->
  <tcpTimeoutEstablished>3600</tcpTimeoutEstablished> <!-- Optional. Defaults to 3600 -->
  <tcpTimeoutClose>30</tcpTimeoutClose> <!-- Optional. Defaults to 30 -->
  <udpTimeout>60</udpTimeout> <!-- Optional. Defaults to 60 -->
  <icmpTimeout>10</icmpTimeout> <!-- Optional. Defaults to 10 -->
  <icmp6Timeout>10</icmp6Timeout> <!-- Optional. Defaults to 10 -->
  <ipGenericTimeout>120</ipGenericTimeout> <!-- Optional. Defaults to 120 -->
</globalConfig>


アプリケーション利用で、知らないうちにセッションが切られて業務アプリケーションが異常終了したなどのトラブルを防ぐためにも、ファイアーウォールのタイムアウト値には、気を配ったうえでのネットワーク設計をお勧めします。


2017年4月19日水曜日

VCP-NVのすすめとメリットをご紹介

今日は、VCP-NVの取得メリットについて自分の経験を交えてご紹介をしたいと思います。

私自身、プリセースルという立場のため、NSXに興味があるとか、NSX導入したメリットを知りたいというお客様に対して、どのようにNSX for vSphereを導入するとメリットがあるかや、正しいインプリメント(導入)のお手伝いをすることが仕事だったりします。

NSX for vSphereは、ネットワークの仮想化という言葉でひとくくりにされてしまうことが多いですが、VXLANによるデーターセンター間のL2延伸や、分散ファイアーウォールによるマイクロセグメンテーション、Edge Service Gatewaが提供する高度なロードバランサー機能(ADC)やSSL-VPNなどの様々な機能を持ち合わせており、単純にNSXを導入ししたいというお客様にとっても、どの機能を使いたいかでエディションを含め大きく変わることがありますし、提案する側としては、幅広いNSX for vSphereの機能を一通り把握しておく必要があります。
NSXは、様々なコンポーネントがありますが、実際の導入作業においては、あまり意識せずとも導入できてしまうというのが実情です。ただ、トラブルや想定していない事項が発生した際には、このコンポーネントの詳細な動作を理解しておく必要があり、この理解具合を確認するという観点においてもVCP-NVは大変有益なものと私自身思っています。

私自身は、VCP-NVを取得する形で、NSX for vSphereの機能や特にVX-LANのメリットや導入時の注意点を習得することができました。

VX-LANによるネットワークのL2延伸は、大変魅力的ですが、このVX-LANには、既存の物理ネットワークに対して極力影響をなくし、仮想的なネットワークを作成し、マルチテナントや場所的な問題を解決するためのソリューションですが、VX-LANを実際に導入するために、あらかじめ押さえておくべき事項がいくつかあります。

このあたりの実践的な導入における注意点が、VCP-NVの問題としてよく登場しますので、VCP-NVを取得またVCP-NV取得へ向けての学習をすることで、VXLANの根本やUWA役割などの、NSXのコンポーネントと役割をしっかりと学習することができます。

これは、NSXを導入後におけるトラブルにおいても非常に有効です。

実際にNSX導入後においてトラブル相談を受けるケースもありますが、その際に必要なことは、VTEPの動作とNSX Controllerの動きをしっかりと理解していれば、なにも難しいことではないのですが、このあたりの理解や動きを習得するためには、VCP-NV取得に向けての勉強は大変に役立ったと感じています。

また、NSXにおいては、分散スイッチの導入が基本必須となりますが、分散スイッチのメリットをわかりつつも標準スイッチで構成されている現場を多く見ますが、NSXを学習すると、vDSの機能やメリットも今一度おさらいすることができます。VCP-DCVにおいては、vDSの概要は少ししか触れられませんが、VCP-NVにおいては、vDSの内容もしっかり出てきますので、vDSがより身近になると思います。

また、今まで仮想化を中心としたサーバーエンジニアにとっても、ネットワークという基礎概念とネットワークの仮想化を学ぶ大変良い材料になると思います。

ぜひ、仮想ネットワークの世界に踏み出す一歩として、VCP-NVの取得にチャレンジをされてみてはいかがでしょうか?



2017年4月2日日曜日

Windows10のSysprep時注意点

世間では、Windows10も一般化し企業での導入も普及期に入りWin7からの移行のケースも増えてきたかと思います。
Windows10には、様々なエディションが有りアップデートプログラムの適用について、様々なパターンを選ぶことができるようになっています。

さて、Windows10で一般的なVLKイメージで展開する際に、まずゴールドイメージにWindows Updateを施した後に、Horizon View側で展開の設定を行うかと思います。
この際に、Sysprep経由での展開時に失敗することがあります。

実際に手動でWindows10のゴールドイメージにsysprepをかけようとしても、以下のようなエラーが出て正しくsysprep自体が動作しません。
 

実際に、C:\Windows\System32\Sysprep\Panther\setupact.logを見ると以下のようなエラーが出ています。

2017-04-02 16:25:16, Error SYSPRP Package Microsoft.MicrosoftSolitaireCollection_3.9.5100.0_x64__8wekyb3d8bbwe was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.
2017-04-02 16:25:16, Error SYSPRP Failed to remove apps for the current user: 0x80073cf2.
2017-04-02 16:25:16, Error SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.
2017-04-02 16:25:16, Error [0x0f0082] SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'SysprepGeneralizeValidate' from C:\Windows\System32\AppxSysprep.dll; dwRet = 0x3cf2
2017-04-02 16:25:16, Error SYSPRP SysprepSession::Validate: Error in validating actions from C:\Windows\System32\Sysprep\ActionFiles\Generalize.xml; dwRet = 0x3cf2
2017-04-02 16:25:16, Error SYSPRP RunPlatformActions:Failed while validating SysprepSession actions; dwRet = 0x3cf2
2017-04-02 16:25:16, Error [0x0f0070] SYSPRP RunExternalDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 0x3cf2
2017-04-02 16:25:16, Error [0x0f00d8] SYSPRP WinMain:Hit failure while pre-validate sysprep generalize internal providers; hr = 0x80073cf2

さて、これはWindows Updateによりストアアプリの変更がおこなわれてしまうことによる弊害のようです。

実際には以下の情報が参考になります。

(参考)Windows 10 (バージョン 1511) における Sysprep 実行時の注意点
https://blogs.technet.microsoft.com/askcorejp/2015/12/20/windows-10-1511-sysprep/

こちらの中で紹介があるとおり、グループポリシーの変更行うことで対応が可能なようです。
私が検証する限り、1611ビルドのWindow10 Proのメディアに対して、Windows Update後に以下の対応を行ってもsysprepは成功しましたので、誤ってWindows Updateをかけてしまった後でもマスターの再作成は不要だと思います。


では回避法の手順を、おさらいしておきましょう。
※グループポリシーといえども、今回はClientOSのマスターであるためドメインに参加する前と考え、AD側での適用ではなく、クライアントOS本体のポリシー(ローカルコンピューターポリシー)を変更します。

1.まずは、該当のWindows10 Clientからファイル名を指定して実行をクリックします。

2.実行アプリケーションに「gpedit.msc」を入れて起動します。


3. [ローカルコンピューターポリシー]→[Windows コンポーネント]→[クラウド コンテンツ]の順にツリーを奨めていきます。

4.「Microsoft コンシューマー エクスペリエンスを無効にする」をダブルクリックします。

5.オプション選択画面が表示されますので、「有効」を選択し、OKをクリックします。

6.パラメーターが有効になっていることを確認し、ローカルグループポリシーエディタを終了します。

7.最後にコマンドプロンプトから「gpupdate」を実行し、ポリシーを反映させます。

これで、完了です。
この後は、sysprepを実行すると、正常に処理が完了します。

Horizon Viewのマスターとして利用する際に、Quickprepではなく、Sysprepを利用する場合は、あらかじめこの作業を行っておきましょう。





2017年4月1日土曜日

VCP6-NV 取得の薦め その2

前回は、VCP6-NVを取得するためのプロセスをご紹介しました。


では、実際にVCP6-NVを取得するためにはどのような勉強をすればよいのでしょうか?

一応ですが私もVCP6-NVホルダーですので、資格取得までのことをお伝えしたいと思います。


私自身も当然ながら仕事の中でVMware NSXを扱うことが多く、さすがに無免許では・・・と思いながら取得したのが、私の受験の理由だったりしますが。
(昔からそうですが試験というのはあまりうれしいものではないので)


さて、まず問題の傾向ですがVMware NSX for vSphereという製品自体が、かなり多くの機能が実装されているので、その基本機能や機能実装についてはある程度頭に入れておく必要があるでしょう。また、NSXの特徴でもあるネットワーク仮想化機能はしっかりと押さえておきましょう。
VXLANについては詳細に動きを把握することや、DLRによるルーティングの動作なども押さえておきましょう。

ここで大事なことは、NSXは、vSphere上で動作するネットワーク仮想化製品であるということです。NSXを利用する上で必要不可欠な分散スイッチ(vDS)やvmkernelなどのvSphereの基本を押さえておかないと、うわべだけの机上だけのVXLANスキルだけだと、おそらく難しいのではないかと思います。

ネットワーク全体の設計スキルも問われますが、NSXにおける制限事項等も押さえておく必要があります。

とはいえ、実際に触る機器もないケースが多いでしょうから、是非VMwareのHands On Laboを利用して、思いっきりさわり倒すことがまず大事だと思います。


では、VCP6-NVを取得するまでの押さえておきたいプロセスをまとめておきます。

<その1>
Hands On Laboをさわりたおして、動きや操作手順、感覚を学ぶ
おすすめコース
HOL-1703-SDC-1 - VMware NSX: Introduction and Feature Tour


<その2>
リリースノートとドキュメントを読んで、制限事項やアップグレードの制限、操作手順などの条件を確認する


<その3>
基本的なネットワークのスキルを身につける。
スイッチ+ルーティングはもちろん、ダイナミックルーティングやVPNの仕組み(特にIPSEC)、ネットワークの基本設計(Leaf & Spineの考え方や、North - South通信とEast - West通信など)

<その4>
もし、VMware Partner Network(VPN)に加盟している会社に所属している場合は、Partner Centralから、VSP-NVとVTSP-NVをあらかじめ取得しておく。(ここで結構基本的なスキルが取得できます)

<その5>
体調を整えて、試験に臨む。



ちなみに試験は500万点中300点合格(6割)です。
問題ごとに点数が異なるため1問何点という配分は、わかりません。
問題は選択式で、複数の回答を求めるもののほうが得点配分が高く、制限事項等をもとめるような単一の回答は得点配分が低いという話を聞いたことがあります。

上記の手順をしっかり行っておけば、すくなからず合格点には行けると思います。


新年度で新しいことを始めたりチャレンジしたいと思う時期ですので、是非、VCP6-NVにチャレンジしてみてください!









VCP6-NV 取得の薦め その1

4月に入り新入社員が入ることもあり、インフラ系のSEさんにとっては資格という一つのチャレンジに向かう人も増える季節かと思います。
以前に、VMwareの資格試験についてご紹介をしました。

(参考)VMwareにおける認定資格について(1)
http://infratraining.blogspot.jp/2015/12/vmware1.html

VMwareにおける資格として、一般的に登竜門的な扱いになっているのが「VCP」です。
VCPホルダーであれば、仮想化に対して、頭でっかちの机上だけのスキルではなく、手を動かしている実践的なスキルを持ったエンジニアと見られるのが、世間一般のSE会社から見た扱いになると思います。

このVCPには、プロダクトごとにジャンルが分かれています。
そこで、私のお勧めするジャンルは「Network Virtualization」です。

通常VCPの試験を受けるためには、Install, Configure, Managerd(ICM)のトレーニング(1週間で約40万円程度)を受講後、2段階の試験受ける必要があり、コスト的にも少々ハードルが高い側面があります。


しかし、CCNA、CCNP、CCIEをすでにお持ちであれば、 ICMのトレーニングをスキップすることが可能になります。ネットワークの勉強をするために、CCNAを取得される方も多くいるかと思いますが、CCNAを持っておけば、VCP-NVの取得もハードルが下がるという事実があります。

詳細はこちらを参考にしてください。
https://mylearn.vmware.com/mgrReg/plan.cfm?plan=64294&ui=www_cert

では、取得のプロセスもまとめておきましょう。


 ◆新規でVCP-NVを取得する場合
順序条件コース・試験名日数価格(1名)
1必須NSX Install, Configure, Managed[6.2]5$4,125
2必須vSphere6 Foundation Exam-¥10,560
3必須VCP6-NV (VCP6-Network Virtualization 試験)-¥20,120



◆すでに有効なCiscoの資格を保有している場合
順序条件コース・試験名日数価格(1名)
1必須CCNA Data Center / CCNA Routing & Switching
CCNP Data Center / CCNP Routing & Switching
CCIE Data Center / CCIE Routing & Switching
--
2必須vSphere6 Foundation Exam-¥10,560
3必須VCP6-NV (VCP6-Network Virtualization試験)-¥20,120


次回は、VCP-NVの勉強のコツなどをお伝えしたいと思います。




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 (必須コンポーネント)
名称vCPURAMHDD備考
NSX Manager41660NSX適用サイズによっては、8vCPUを適用
NSX Controller 14420
1環境に最低3台必要
NSX Controller 24420
NSX Controller 34420


■NSX Edge (Edge Service Gateway)

名称vCPURAMHDD備考
NSX Edge Service Gateway 小10.50.5
HA構成にする場合は、2台分のリソースが必要
一般利用用途の場合は、サイズは大以上
NSX Edge Service Gateway 大211
NSX Edge Service Gateway 特大411
NSX Edge Service Gateway 超特大682.5

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

■その他サービスVA

名称vCPURAMHDD備考
Guest Introspection20.54vShield Ednpoint及びアージェントレスアンチウイルス機能利用時に必要なVA。
ESXiホストの台数分だけ積算が必要
NSX Data Security10.56ESXiホストの台数分だけ積算が必要

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

名称vCPURAMHDD備考
極 小
(ESXi10台 / VM100台)
210250
小規模
(ESXi100台 / VM1000台)
416290
中規模
(ESXi400台 / VM4000台)
824425
大規模
(ESXi1000台 / VM10000台)
1632640
超大規模
(ESXi2000台 / VM35000台)
2448980

・PSC

名称vCPURAMHDD備考
PSC2460

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

■おまけ・TrendMicro Deep Security

名称vCPURAMHDD備考
Deep Security Manager48100SQL Serverの別途手配が必要です
Deep Security VA
(〜32VM)
4420
Guest Introspection VAと同じ台数分だけ展開が必要
Deep Security VA
(〜64VM)
4620
Deep Security VA
(65〜VM)
41020

  • 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

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