KMVBLOG

VMware関連のトラブルシュート・設定・検証関連の備忘録

NSX-TのSSHとWeb GUIのタイムアウト無効化について

NSX-T ManagerのSSHとWeb GUIセッションのタイムアウト無効化について記載します。

 

デフォルトのNSX-T Managerのタイムアウト値は以下です。

  • Web GUI:1800秒(30分)
  • SSHセッション:600秒(10分)

 

SSHセッションのタイムアウト無効化

 

1.NSX-T ManagerにSSH等でログインします。

2.adminユーザーでログインします。

3.set cli-timeout 0 で無効化します。

nsxtmgr> set cli-timeout 0

 4.タイムアウトの無効化を確認します。

nsxtmgr> get cli-timeout
Timeout disabled

 

Web GUIセッションのタイムアウト無効化

 

1.NSX-T ManagerにSSH等でログインします。

2.adminユーザーでログインします。

3.set service http session-timeout 0 で無効化します。

nsxtmgr> set service http session-timeout 0

4.HTTPサービスを再起動します。

nsxtmgr> restart service ui-service

5.HTTPのタイムアウト値を確認します。

nsxtmgr> get service http
Service name: http
Service state: running
Session timeout: 0 seconds   <<<★
Connection timeout: 30 seconds
Client API rate limit: 100 requests/sec
Client API concurrency limit: 40 connections
Global API concurrency limit: 199 connections
Redirect host: (not configured)

 

以上です。

 

NSX-Tのパスワード有効期限について

NSX-Tのユーザーはadmin/audit/rootの3つがありますが、全てのユーザーのパスワードは90日後に変更する必要があり、期限切れが迫ると警告がでます。

f:id:Kame-chan:20200724101033p:plain

 

NSX-Tのパスワード有効期限はデフォルト90日になっています。

f:id:Kame-chan:20200724101243p:plain

今回は、パスワードの有効期限を無効にする方法について記載します。

 

パスワードの有効期限が切れると、一部の機能(APIやWebインターフェース)が使用できなくなるため、パスワードは定期的に変更するか有効期限を無効にしてください。

 

NSX-T Managerのパスワードだけでなく、Edge TransportNode(Edge VM)のパスワードも同様に有効期限切れになりますので、そちらも同時に変更する事を推奨します。

 

次のコマンドを使用して、パスワードの有効期限ポリシーを無効にできます。

NSX-T Managerが3台で構成されている場合は、どれか1つのノードでのみ実行します。

 

1.NSX-T ManagerにSSH等でログインします。

2.adminユーザーでログインします。

3.パスワードの有効期限を削除します

 

clear user admin password-expiration 

clear user audit password-expiration

clear user root password-expiration  

 

4.パスワードの有効期限を確認します。

 

get user admin password-expiration

Password expiration not configured for this user

 

Edge TransportNode(Edge VM)も同様の手順で実施します。

 

 

vSAN6.7u3 - vSAN iSCSI ボリュームのオンライン拡張について

本BlogはvExpert Advent Calendar 2019に参加しています。

adventar.org

 vSAN6.7u3でvSAN iSCSIのボリュームをオンラインで容量拡張する事ができるようになりました。

VMware vSAN 6.7 Update 3 リリース ノート

vSAN iSCSI サービスの機能強化

vSAN iSCSI サービスが強化されて、iSCSI LUN を中断しなくても、動的にサイズ変更できるようになりました。 

 

Labで検証してみました。

vSAN iSCSIターゲットの設定を行い、以下2つのボリュームを作成済み

 ・vol-01 3G

 ・vol-02 10GB

f:id:Kame-chan:20191208182903p:plain

 

f:id:Kame-chan:20191208184953p:plain

 

"編集"からvol-02を10GB→15GBに変更してみます。

f:id:Kame-chan:20191208185903p:plain

 

15GBに容量が増えました。

f:id:Kame-chan:20191208190836p:plain

 

上記でボリュームの容量拡張後、OS側では、ディスクの管理 > 操作 > ディスクの再スキャンを行います。

f:id:Kame-chan:20191208191335p:plain

 

5GB分の未割り当て領域が作成されました。

f:id:Kame-chan:20191208191447p:plain

 

拡張したいディスクを選択して、ボリュームの拡張を行います。

f:id:Kame-chan:20191208192152p:plain

 

ディスクの拡張が完了しました。(10GB→15GB)

f:id:Kame-chan:20191208192305p:plain

 

次は、CLIでvol-01を3GB→5GBに変更してみます。

 

ターゲットエイリアスを確認

[root@esxi01:~] esxcli vsan iscsi target list
Alias iSCSI Qualified Name (IQN) Interface Port Authentication type LUNs Is Compliant UUID I/O Owner UUID
---------- -------------------------------------------------------- --------- ---- ------------------- ---- ------------ ------------------------------------ ------------------------------------
wsfc-iscsi iqn.1998-01.com.vmware.52d9af5ef69bb645-1245c1689aee844f vmk0 3260 No-Authentication 2 true 57056a5d-26e7-6f65-ec86-005056818076 5d6603b4-b94c-e120-5140-005056818076 

 

容量を拡張するLUNのIDを確認

[root@esxi01:~] esxcli vsan iscsi target lun list -t wsfc-iscsi
ID Alias Size UUID Is Compliant Status
-- ------ --------- ------------------------------------ ------------ ------
0 vol-01 3072 MiB 7a056a5d-e028-4745-e673-005056818076 true online
1 vol-02 15360 MiB 9f056a5d-06d2-cfca-780e-005056812e61 true online

 

5GBに拡張します。

<オプション>

-s サイズ

-i LUNのID

-t ターゲットのエイリアス  

[root@esxi01:~] esxcli vsan iscsi target lun set -s 5120MB -i 0 -t wsfc-iscsi

 

拡張後のサイズを確認

[root@esxi01:~] esxcli vsan iscsi target lun list -t wsfc-iscsi
ID Alias Size UUID Is Compliant Status
-- ------ --------- ------------------------------------ ------------ ------
0 vol-01 4885 MiB 7a056a5d-e028-4745-e673-005056818076 true online
1 vol-02 15360 MiB 9f056a5d-06d2-cfca-780e-005056812e61 true online 

 

拡張はされているが、5GB(1024*5=5120MB)で指定したはずが、若干意図した容量と異なる。。

f:id:Kame-chan:20191208201516p:plain

 

OS上での認識

f:id:Kame-chan:20191208201059p:plain

 

GUI上で再度変更してみました。(4.77GB→5GB)

f:id:Kame-chan:20191208202038p:plain

 

期待する値になってました。

[root@esxi01:~] esxcli vsan iscsi target lun list -t wsfc-iscsi
ID Alias Size UUID Is Compliant Status
-- ------ --------- ------------------------------------ ------------ ------
0 vol-01 5120 MiB 7a056a5d-e028-4745-e673-005056818076 true online
1 vol-02 15360 MiB 9f056a5d-06d2-cfca-780e-005056812e61 true online 

 

-s オプションのサイズをMiBで指定(5GB→6GBに拡張)

[root@esxi01:~] esxcli vsan iscsi target lun set -s 6144MiB -i 0 -t wsfc-iscsi

[root@esxi01:~] esxcli vsan iscsi target lun list -t wsfc-iscsi
ID Alias Size UUID Is Compliant Status
-- ------ --------- ------------------------------------ ------------ ------
0 vol-01 6144 MiB 7a056a5d-e028-4745-e673-005056818076 true online
1 vol-02 15360 MiB 9f056a5d-06d2-cfca-780e-005056812e61 true online

 

サイズをMiBで指定すると意図した値になりました。

 CLIでの容量拡張はMiBで指定した方が混乱が無く実施できそうです。

f:id:Kame-chan:20191208204657p:plain

以上、vSAN6.7u3で追加されたvSAN iSCSIの機能拡張により、上記の作業(GUI/CLI)は全てオンラインで実施可能でした。

 

関連KB

https://blogs.vmware.com/virtualblocks/2019/08/13/vsan67u3-whats-new/

vSAN6.7u3 - SCSI-3 PRを使用したWSFCについて

vSAN6.7 Update3よりSCSI-3 Perssitent Reservationがネイティブにサポートされ、共有VMDKを使用したWSFCの構成が可能です。

 

https://docs.vmware.com/jp/VMware-vSphere/6.7/rn/vmware-vsan-67u3-release-notes.html

ネイティブ vSAN VMDK 上の Windows Server Failover Clusters (WSFC)

vSAN 6.7 Update 3 では SCSI-3 PR がネイティブにサポートされており、Windows Server Failover Clusters を最初のクラスのワークロードとして VMDK に直接デプロイできます。この機能を使用すると、物理 RDM のレガシー環境または外部ストレージ プロトコルを vSAN に移行できます。

 

サポートされる機能

 ・クラスタ間のvMotion(WSFCノード(VM)は異なるESXiに配置する事が推奨)

 ・vSANストレッチクラスタ

 

サポートされない機能

 ・スナップショット

 ・オンラインstorage vMotion

 ・共有ディスクのHot-extension

 ・メモリ/CPUのHot add

 ・vSphere Fault Tolerance(FT)

 ・VMサスペンドもしくはレジューム

 ・異なるESXiバージョンが混在されている環境

 

以下も参照

https://storagehub.vmware.com/t/vmware-vsan/sql-server-failover-cluster-instance-on-vmware-vsan-tm-native/vsan-native-support-for-wsfc/ 

 

SCSIコントローラは"VMware準仮想化"(VMware Paravirtual)が推奨のようです。

SCSIバスの共有を"物理"に変更します。

f:id:Kame-chan:20191130135230p:plain

f:id:Kame-chan:20191130141002p:plain

Node#2側でNode#1側のvmdkをマウント

SCSIコントローラはVMware準仮想化で作成、SCSIバスの共有を"物理"に設定

f:id:Kame-chan:20191130142026p:plain

 

f:id:Kame-chan:20191130144906p:plain

 

関連KB

https://kb.vmware.com/s/article/74786

https://kb.vmware.com/s/article/2147661

https://blogs.vmware.com/virtualblocks/2019/08/13/vsan67u3-whats-new/

https://blogs.vmware.com/virtualblocks/2019/08/23/vsan67-u3-wsfc-shared-disksupport/

https://blogs.vmware.com/apps/2019/05/wsfc-on-vsphere.html

 

vSAN6.7でのWindows Server Failover Clusters(WSFC)について

今までの記事でVIT(vSAN iSCSI Target)について記載してきました。

 vSphere6.7の問い合わせも多く入ってくるようになり、それに伴いvSAN 6.7でのWSFC構成に興味を持たれていらっしゃる方も増えてきました。

そこで、勉強のため環境を構築して、テストしてみようと思います。

 

まず、VITでのWSFC構成はvSAN6.7でサポートされました。

https://docs.vmware.com/jp/VMware-vSphere/6.7/rn/vmware-vsan-67-release-notes.html

Windows Server フェイルオーバー クラスタのサポート。vSAN 6.7 では、vSAN iSCSI ターゲットの上に Windows Failover Clustering (WSFC) ターゲットを構築することにより、WSFC をサポートしています。vSAN iSCSI ターゲット サービスは、共有ディスクの SCSI-3 の永続的な予約と、WSFC の透過的フェイルオーバーをサポートします。WSFC は、物理サーバまたは仮想マシンのいずれかで実行できます。  

f:id:Kame-chan:20190831170647p:plain

images: https://storagehub.vmware.com

 

検証環境

  • Windows Server 2016 (2ノード WSFC構成)
  • ESXi6.7u2 / vSAN 6.7EP9
  • MPIO/フェールオーバークラスタリングの機能を追加
  • VITの設定でLUNを2つ(Quorum:3GB/Share Storage:10GB)を作成
  • WSFCクラスタノードのIQNをイニシエータグループに登録済

f:id:Kame-chan:20190831174219p:plain

f:id:Kame-chan:20190831190305p:plain

フェールオーバークラスタにファイルサーバーの役割を追加

f:id:Kame-chan:20190831175019p:plain

 

f:id:Kame-chan:20190831175336p:plain

 

クライアント側に共有ドライブをマウントします

f:id:Kame-chan:20190831220258p:plain


MPIO周りの設定確認

アクティブセッションはセッション03となり、ターゲットポータルはesxi01である事がわかる

f:id:Kame-chan:20190831182425p:plain

f:id:Kame-chan:20190831195100p:plain

f:id:Kame-chan:20190831184042p:plain

f:id:Kame-chan:20190831183404p:plain


上記のMPIO設定から、アクティブセッションを張っているesxi01がダウンし、iSCSIセッションが途切れてしまった場合でも、別のノードでiSCSIセッションを再接続し、ファイルサービスへのアクセスが継続して提供される事が期待する結果です。

 

次回は本環境を使用して、動作検証を行いたいと思います。

 

関連KB

https://kb.vmware.com/s/article/54461

vSAN健全性チェックで"統計情報に影響するすべてのホスト"が記録される

vSAN健全性チェックでvSANパフォーマンスサービスの"統計情報に影響するすべてのホスト"のエラーが記録されていたので、その対処方法についてです。

f:id:Kame-chan:20190715192559p:plain

このチェックの目的はVMware KB2144400に記載されています。

Q:[パフォーマンス サービス - 統計情報に影響するすべてのホスト] チェックでは何を行いますか。
A
:このチェックでは、現在同じネットワーク パーティションの一部であるすべてのホストがコレクションの統計に影響していることを確認します。同じネットワーク パーティションにないホストは、確認しません。一般的なネットワーク健全性チェックを使用して、全体的なクラスタの健全性のこの側面を評価します。このチェックは、vSAN パフォーマンス サービスがホストと通信し、統計を取得できることを確認するために使用されます。

Q:エラー状態とは、どのような状況を意味しますか。
A:このチェックが黄色の場合は、一部のホストがパフォーマンス統計に影響していないことを意味します。

 

この問題は様々な要因で発生するため、本問題を解決するための一連のトラブルシューティングを行います。

 

1.全vSAN Hostのvsanmgmtdのサービスを再起動

 

[root@esxi01:~] /etc/init.d/vsanmgmtd restart
watchdog-vsanperfsvc: Terminating watchdog process with PID 2101508
vsanperfsvc started

※この作業は稼働中のVMには影響ありません。

 

2.vCenter Server Applianceのvmware-vsan-healthサービスを再起動

 

root@vc [ ~ ]# service-control --stop vmware-vsan-health
Operation not cancellable. Please wait for it to finish...
Performing stop operation on service vsan-health...
Successfully stopped service vsan-health

 

root@vc [ ~ ]# service-control --start vmware-vsan-health
Operation not cancellable. Please wait for it to finish...
Performing start operation on service vsan-health...
Successfully started service vsan-health

 

3.vSphere Web ClientからvSANパフォーマンスサービスをOff/Onを実施

(※過去のvSANパフォーマンス統計データが削除されます)

 

vSANクラスタ > 設定 > 健全性とパフォーマンス > オフにする

f:id:Kame-chan:20190715221351p:plain


4.全vSAN HostのvSAN Storage Providerの証明書の確認

 

vCenter Server > 設定 > ストレージプロバイダ > vSAN Provider "ESXi Hostname"  > 証明書情報

 

上記で確認した所、"問題のないホスト"は証明書がPSCから発行されている事に対し、"問題のあるホスト"はvCenterから発行されている事に気が付きました。

※本環境は外部PSCなので、vCenterとPSCが独立して存在しており、本来はPSCから証明書が発行される事が正しい挙動になります。

 

問題のあるホスト

f:id:Kame-chan:20190715222528p:plain

 

問題のないホスト

f:id:Kame-chan:20190715223057p:plain

 

解決策としては、問題のあるホストの証明書を再発行します。

 

"問題のあるESXiホスト" > 設定 > 証明書 > 更新 

f:id:Kame-chan:20190715225749p:plain

 

※証明書の再発行をすると、ESXiホストのHAエージェントが再起動しますので、クラスタでHAを有効化している場合は、予期せずVMがフェールオーバーする可能性があります。

 

証明書の再発行後、vSAN健全性テストを実施して、パスする事を確認します。

f:id:Kame-chan:20190715232026p:plain

 

同様の事象が発生した場合は、参考にして頂けると幸いです。

 

関連KB

https://kb.vmware.com/s/article/2150570

https://kb.vmware.com/s/article/52567

 

以上です。

vSAN iSCSIターゲット(VIT)の高可用性について

VITでのターゲットLUN(vmdk)は、vSANクラスタ内のESXiホストとStorage Policyで冗長化されていますが、イニシエータ側はどのようにすればいいのか?

それは、Windows/LinuxMPIOを使用する事によって、イニシエータに高可用性を提供します。

 

以下はwindowsiSCSIイニシエータのターゲットポータルの画面ですが、現在2つのESXiホストを登録し、ディスクもマウント済みです。

f:id:Kame-chan:20190621171630p:plain


1つのターゲットIQNに対して、2つのセッションがあります。

f:id:Kame-chan:20190621171955p:plain

 

以下の画面は、MPIOの画面ですが、上記の2つのセッションが、アクティブ/スタンバイで構成されている事がわかります。

※前回も記載しましたが、VITは、1つのターゲット/LUNに対して、1つのアクティブ I/Oパスのみサポートするため、負荷分散ポリシーを”フェールオーバーのみ”にするのが推奨です。

f:id:Kame-chan:20190621172231p:plain

 

イニシエータ側の可用性を最大にするため、vSANクラスター内のホスト全台分をターゲットポータルに登録するのが良いのかと思ったんですが、そうではないらしいです。storagehubに、ホスト2台から3台程度を登録するのが推奨と記載がありました。(64ノードなどの対規模環境はさらに数台追加するのが推奨)FTT=1の場合は、ESXiホスト2台程度、FTT=2の場合は3台程度が推奨との事。

 

ターゲットのI/Oオーナーは、esxi02で、イニシエータにLUNアクセスを提供しています。

f:id:Kame-chan:20190621173156p:plain

 

この状態でローカルPCからISCSI LUNへのファイルコピー中に、ESXiホストを停止させる障害試験を行います。

  • iSCSI LUN:(E)にファイルをコピー中にesxi01を停止
  • 結果:問題なくコピー完了

 

  • iSCSI LUN:(E)にファイルをコピー中にesxi02(ターゲットのI/Oオーナー)を停止
  • 結果:問題なくコピー完了

 

どちらも、ファイルのコピーが完了しました。 

ターゲットI/Oオーナーであるesxi02のダウン時は一旦コピーが停止したように見えましたが、オーナーが切り替わり、I/Oがリダイレクトされるまでの間は、OS側のキャッシュで吸収され、その後はコピーも進行し、完了しました。

※ボリュームが3GBと小さく、1GB程度のファイルコピーだったので、その影響かもしれません。もう少し大きなファイルだと結果は異なるかも。

 

vitd.logの出力結果から内部の動作を確認してみます。

2019-06-21T10:16:21Z vitd[67266]: VITD: Thread-0x9666f4a700 accepted connection from xx.xx.xx.xx; portal group "pg-vmk0-3260" ///イニシエータはLUNへのアクセスを要求

 

2019-06-21T10:16:21Z vitd[67266]: VITD: Thread-0x9666f4a700 xx.xx.xx.xx (iqn.1991-05.com.microsoft:win-53ggkq348ci): initiator requests to connect to target "iqn.1998-01.com.vmware:a985217e-de62-a4e7-671a-5f5c5b9b2e35"; auth-group "89fb055d-dc24-d742-9a22-0050568e1413" ///イニシエータがホストesxi01にターゲットアドレスを提供


2019-06-21T10:16:21Z vitd[67266]: VITD: Thread-0x9666f4a700 xx.xx.xx.xx (iqn.1991-05.com.microsoft:win-53ggkq348ci): operational parameter negotiation done; transitioning to Full Feature Phase ///ターゲットが検出され、認証をPassし、承認されました


2019-06-21T10:16:21Z vitd[67266]: VITD: Thread-0x9666f4a700 xx.xx.xx.xx (iqn.1991-05.com.microsoft:win-53ggkq348ci): VitdGetTargetAddr: target owner for target iqn.1998-01.com.vmware:a985217e-de62-a4e7-671a-5f5c5b9b2e35 is 5d05f041-9f31-dacf-4e20-0050568e042f ///オーナーシップがホストUUID:5d05f041-9f31-dacf-4e20-0050568e042fへ移動


2019-06-21T10:16:21Z vitd[67266]: VITD: Thread-0x9666f4a700 xx.xx.xx.xx (iqn.1991-05.com.microsoft:win-53ggkq348ci): Got redirect IP address and port number: xx.xx.xx.104:3260, ///esxi04へリダイレクト


2019-06-21T10:16:21Z vitd[67266]: VITD: Thread-0x9666f4a700 xx.xx.xx.xx (iqn.1991-05.com.microsoft:win-53ggkq348ci): The connection is redirected. Drop the connection!

 

ホストのUUIDは以下のコマンドで確認します

[root@esxi01:~] cmmds-tool find -t HOSTNAME -u 5d05f041-9f31-dacf-4e20-0050568e042f

owner=5d05f041-9f31-dacf-4e20-0050568e042f(Health: Healthy) uuid=5d05f041-9f31-dacf-4e20-0050568e042f type=HOSTNAME rev=0 minHostVer=0 [content = ("esxi04.lab.local")], errorStr=(null)

 

 vSAN iSCSIターゲット(VIT)の挙動について、ある程度理解する事ができました。

ターゲットLUN(vmdk)への接続は、アクティブ/パッシブ構成で行われ、単一の接続のみが

アクティブになり、障害が発生した場合、別のホストにアクティブオーナーが移行されます。

従来の、iSCSIストレージであれば、ロードバランシングの機能がありますが、VITはまだ対応してないので、ターゲットLUNが単一のオーナー(ESXIホスト)に偏ると、負荷がそのホストに集中してしまうという欠点がありますが、そこは今後の機能拡張に期待です。

 

今度は、vSAN6.7でWSFCのサポートがされたので、6.7環境でも構築・検証してみたいと思います。

 

 以上です