vSAN6.7u3 - vSAN iSCSI ボリュームのオンライン拡張について
本BlogはvExpert Advent Calendar 2019に参加しています。
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
"編集"からvol-02を10GB→15GBに変更してみます。
15GBに容量が増えました。
上記でボリュームの容量拡張後、OS側では、ディスクの管理 > 操作 > ディスクの再スキャンを行います。
5GB分の未割り当て領域が作成されました。
拡張したいディスクを選択して、ボリュームの拡張を行います。
ディスクの拡張が完了しました。(10GB→15GB)
次は、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)で指定したはずが、若干意図した容量と異なる。。
OS上での認識
GUI上で再度変更してみました。(4.77GB→5GB)
期待する値になってました。
[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で指定した方が混乱が無く実施できそうです。
以上、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)
・異なるESXiバージョンが混在されている環境
以下も参照
SCSIコントローラは"VMware準仮想化"(VMware Paravirtual)が推奨のようです。
SCSIバスの共有を"物理"に変更します。
Node#2側でNode#1側のvmdkをマウント
SCSIコントローラはVMware準仮想化で作成、SCSIバスの共有を"物理"に設定
関連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 は、物理サーバまたは仮想マシンのいずれかで実行できます。
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をイニシエータグループに登録済
フェールオーバークラスタにファイルサーバーの役割を追加
クライアント側に共有ドライブをマウントします
MPIO周りの設定確認
アクティブセッションはセッション03となり、ターゲットポータルはesxi01である事がわかる
上記のMPIO設定から、アクティブセッションを張っているesxi01がダウンし、iSCSIセッションが途切れてしまった場合でも、別のノードでiSCSIセッションを再接続し、ファイルサービスへのアクセスが継続して提供される事が期待する結果です。
次回は本環境を使用して、動作検証を行いたいと思います。
関連KB
vSAN健全性チェックで"統計情報に影響するすべてのホスト"が記録される
vSAN健全性チェックでvSANパフォーマンスサービスの"統計情報に影響するすべてのホスト"のエラーが記録されていたので、その対処方法についてです。
このチェックの目的は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クラスタ > 設定 > 健全性とパフォーマンス > オフにする
4.全vSAN HostのvSAN Storage Providerの証明書の確認
vCenter Server > 設定 > ストレージプロバイダ > vSAN Provider "ESXi Hostname" > 証明書情報
上記で確認した所、"問題のないホスト"は証明書がPSCから発行されている事に対し、"問題のあるホスト"はvCenterから発行されている事に気が付きました。
※本環境は外部PSCなので、vCenterとPSCが独立して存在しており、本来はPSCから証明書が発行される事が正しい挙動になります。
問題のあるホスト
問題のないホスト
解決策としては、問題のあるホストの証明書を再発行します。
"問題のあるESXiホスト" > 設定 > 証明書 > 更新
※証明書の再発行をすると、ESXiホストのHAエージェントが再起動しますので、クラスタでHAを有効化している場合は、予期せずVMがフェールオーバーする可能性があります。
証明書の再発行後、vSAN健全性テストを実施して、パスする事を確認します。
同様の事象が発生した場合は、参考にして頂けると幸いです。
関連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/LinuxでMPIOを使用する事によって、イニシエータに高可用性を提供します。
以下はwindowsのiSCSIイニシエータのターゲットポータルの画面ですが、現在2つのESXiホストを登録し、ディスクもマウント済みです。
1つのターゲットIQNに対して、2つのセッションがあります。
以下の画面は、MPIOの画面ですが、上記の2つのセッションが、アクティブ/スタンバイで構成されている事がわかります。
※前回も記載しましたが、VITは、1つのターゲット/LUNに対して、1つのアクティブ I/Oパスのみサポートするため、負荷分散ポリシーを”フェールオーバーのみ”にするのが推奨です。
イニシエータ側の可用性を最大にするため、vSANクラスター内のホスト全台分をターゲットポータルに登録するのが良いのかと思ったんですが、そうではないらしいです。storagehubに、ホスト2台から3台程度を登録するのが推奨と記載がありました。(64ノードなどの対規模環境はさらに数台追加するのが推奨)FTT=1の場合は、ESXiホスト2台程度、FTT=2の場合は3台程度が推奨との事。
ターゲットのI/Oオーナーは、esxi02で、イニシエータにLUNアクセスを提供しています。
この状態でローカル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環境でも構築・検証してみたいと思います。
以上です
vSAN iSCSIターゲット(VIT)の障害時の挙動について
VITは、アクティブ/パッシブな構成なので、1つのターゲット/LUNに対して、1つのアクティブ I/Oパスのみサポートします。
以下の図がわかりやすいですが、ターゲットのI/Oオーナーがダウンした場合、イニシエータは既存のターゲットポータルへの接続を再試行し、新しくI/Oオーナーになったホストにリダイレクトされます。
images: https://storagehub.vmware.com
"ターゲットのI/Oオーナー"は以下の赤枠で囲まれたESXiホスト(esxi02.lab.local)
"ターゲットポータル"は、以下の赤枠で囲まれたESXiホスト(esxi01.lab.local)
先に説明した通り、VITはアクティブ/パッシブな構成なので、アクティブなI/Oオーナーはesxi02になり、esxi01はパッシブになります。
次に、アクティブオーナーである、esxi02が予期せずダウンした事を想定して、再起動させてみます。
IOオーナーのホストがesxi04に切り替わりました。
挙動としては、おおまかには以下のような動作です。
- イニシエータは、IOオーナーのホスト(esxi02)との接続が失われ、ターゲットポータル(esxi01)へ接続の再試行要求を出す。
- 新しいI/Oオーナーのホスト(esxi04)が選出される。
- ターゲットポータル(esxi01)は、選出されたI/Oオーナーのホスト(esxi04)にリダイレクトする。
以下は、切り替わり時のvitd.logの出力結果です。
2019-06-20T14:43:54Z vitd[67222]: VITD: Thread-0x7514336700 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
2019-06-20T14:43:54Z vitd[67222]: VITD: Thread-0x7514336700 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-20T14:43:54Z vitd[67222]: VITD: Thread-0x7514336700 xx.xx.xx.xx (iqn.1991-05.com.microsoft:win-53ggkq348ci): The connection is redirected. Drop the connection!
以上です。
次回は、MPIOについても、記載する予定です。
vSAN iSCSIターゲット(VIT)の仕組みについて
日々サポートをしていても、VITについての問い合わせが来ることは、ほとんどないのですが、万が一障害が発生した場合に備えて、内部の挙動について勉強しようと思ったので、そのまとめです。
まず、iSCSIターゲットサービスの機能を有効にすると、"/vmfs/volumes/vsanDatastore"の配下にiSCSIの設定などが保存されたホームオブジェクト(.iSCSI-Config)が作成されます。
このホームオブジェクトには以下のフォルダが含まれています。
1.)etc
2.)targets
etcには、VITの構成情報が記載されたvit.confがあります。
このvit.conf設定ファイルは、vSANクラスタ内のすべてのホストからアクセス可能である必要があります。たとえば、どのLUNがどのターゲットに関連付けられているかを判断するために使用されます。
targetsには、iSCSIターゲットネームスペースオブジェクトへのシンボリックリンクと各ターゲットに関連付けされているiSCSI LUN(vmdkオブジェクト)の情報があります。
以下の図が参考になります。
images: https://storagehub.vmware.com
検証機の出力結果
[root@esxi01:~] ls -l /vmfs/volumes/vsanDatastore/.iSCSI-CONFIG/
total 16
drwx------ 1 root root 420 Jun 18 17:15 etc
drwx------ 1 root root 420 Jun 16 08:19 targets
[root@esxi01:~] ls -l /vmfs/volumes/vsanDatastore/.iSCSI-CONFIG/etc/
total 0
-rw-rw---- 1 root root 1007 Jun 18 17:15 vit.conf
[root@esxi01:~] cat /vmfs/volumes/vsanDatastore/.iSCSI-CONFIG/etc/vit.conf
generation 17
initiator-group Win-iSCSI-GRP {
initiator iqn.1991-05.com.microsoft:win-53ggkq348ci
}
auth-group default {
auth-type none
}
auth-group 89fb055d-dc24-d742-9a22-0050568e1413 {
auth-type none
initiator-group Win-iSCSI-GRP
}
portal-group default {
discovery-auth-group no-authentication
listen vmk0:3260
}
portal-group pg-vmk0-3260 {
discovery-auth-group no-authentication
listen vmk0:3260
}
target iqn.1998-01.com.vmware:a985217e-de62-a4e7-671a-5f5c5b9b2e35 {
alias "vsantarget"
portal-group pg-vmk0-3260
auth-group 89fb055d-dc24-d742-9a22-0050568e1413
option uuid 89fb055d-dc24-d742-9a22-0050568e1413
option owner-id 89fb055d-dc24-d742-9a22-0050568e1413
lun 0 {
backend vmdk
path 89fb055d-dc24-d742-9a22-0050568e1413/90fb055d-ba4d-0420-d59d-0050568e042f.vmdk
size 6291456
option lun-alias "vsanluns"
}
lun 1 {
backend vmdk
path 89fb055d-dc24-d742-9a22-0050568e1413/391c095d-06a3-2cac-27b2-0050568e042f.vmdk
size 2097152
option lun-alias "vsanluns2"
}
}
[root@esxi01:~] ls -l /vmfs/volumes/vsanDatastore/.iSCSI-CONFIG/targets/
total 8
lrwxrwxrwx 1 root root 42 Jun 16 08:19 89fb055d-dc24-d742-9a22-0050568e1413 -> ../../89fb055d-dc24-d742-9a22-0050568e1413
[root@esxi01:~] ls -l /vmfs/volumes/vsanDatastore/.iSCSI-CONFIG/targets/89fb055d-dc24-d742-9a22-0050568e1413/
total 0
-rw------- 1 root root 519 Jun 18 17:15 391c095d-06a3-2cac-27b2-0050568e042f.vmdk
-rw------- 1 root root 519 Jun 16 08:19 90fb055d-ba4d-0420-d59d-0050568e042f.vmdk
- VITサービスを有効にすると、vSANクラスタのESXiホストはiSCSIのサービスを起動させる。
- iSCSIの操作/制御は、vitd(vSAN iSCSI Target Deamon)によって処理される。
- vitdはiSCSI Discovery protocolに応答/接続を待ち受ける。(CHAP認証もvitdが処理)
- ターゲット/ LUN作成などの管理操作は、vSphere UIまたはesxcliコマンドからのどちらかによって、vsanmgmtdもしくはhostdによって処理される。
- Initial Discovery Process中に、すべてのホストが全ターゲットLUNをイニシエータに提示する。これにより、イニシエータはクラスタ内の任意のホストに接続できる。
- 接続を受け付けると、vitdはvitsafehdと連携し、VMDKファイルをOpen/Closeする。
まず、VITで何かしらトラブル(ex.イニシエータからターゲットボリュームが見えないなど)が発生した場合は、以下の確認が必要そうです。
- vSAN DataStore配下に.iSCSI-Configが存在するか？
- vSANクラスタ内の各ESXiホストはアクセス可能か？
- vCenterから正しく検出されているか?
- vSAN Health TestはAll Passか？
- vitd,vitsafehdなどのiSCSIサービス、vsanmgmtd,hostdなどの管理用サービスが正しく起動しているか?
参考資料
https://storagehub.vmware.com/t/vmware-vsan/vmware-r-vsan-tm-network-design/vit-internals/
