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/
vSAN iSCSIターゲット(VIT)について
vSAN 6.5でサポートされたvSAN iSCSIターゲット(VIT)について
vSAN 6.7でも機能が変わったので、改めて機能の違いや構築の仕方を勉強するため、今回、検証を行ってみました。
■vSAN 6.5での制限事項
- 物理サーバーのみ
- SQLAlways ON Availability Groups/DFS-R/Oracle RACをサポート
- WSFCの共有ボリュームとしての使用は非サポート(vSAN 6.7から)
- ESXiからの接続は非サポート
■検証環境
まずは、vSAN iSCSIターゲットサービス（VIT）を有効にします。
設定 > 全般 > 編集をクリック
チェックボックスをオンにしてVITサービスを有効にします。 iSCSIネットワークに使用するVMKernel Portを選択します。
デフォルトの認証は"なし"と一方向もしくは、双方向のCHAP認証を使用できます。
今回は"なし"を選択しました。
これで、VITサービスが有効になります。次に iSCSIターゲットとLUNを定義します。
IQNは自動的に生成されますので、ターゲットとLUNのエイリアスの定義
LUNのサイズと任意のvSAN Storage Policyを設定します。
次のステップは、イニシエータグループを作成し、イニシエータを許可します。
デフォルトでは、すべてのイニシエータが許可されていますが、セキュリティ上の理由から、イニシエータグループを作成してそのグループを許可するようにします。
ここでは、"Win-iSCSI-GRP"というiSCSIイニシエータグループを作成し、iSCSIイニシエータのWindowsマシンのIQNを登録しました。
イニシエータグループが作成されたら、イニシエータにターゲットポータルへのアクセスを許可します。 以下の画面で、"アクセス可能なターゲット"をクリックしてターゲットを追加し、ポータル検出を承認します。 これをしないと、イニシエータのDiscovery時に認証エラーが発生する可能性があります。
<Windowsマシン側の設定>
アプリから"iSCSIイニシエーター"を起動します。
探索 > ターゲットポータルの探索 > vSANクラスタホストのIPアドレスまたはDNS名を入力
IQNが表示され、非アクティブと表示されます。
”接続"をクリックすると、お気に入りのターゲットへの追加とマルチパスセッションの有効化をすることができます。 マルチパスセッションを設定するには、"複数パスを有効にする"にチェックを入れて、別のターゲットポータルを追加し、複数の異なるセッションを作成します。
OKをクリックします。
接続が完了したら、エクスプローラを開いてディスクの管理を確認します。
3GBのVolumeがマウントできてますね。
フォーマットして、ボリューム（E）を作成する事ができました。
以上です。
vSAN 6.5のVITはまだ制約がありますが、すぐに設定ができて、Storage policyが適用された可用性の高いDiskをiSCSIとして使用できるのはいいですね。
参考資料
https://storagehub.vmware.com/t/vmware-vsan/iscsi-target-usage-guide/
vSAN暗号化機能について
今回は、vSANの暗号化機能を有効にするための検証をしたので、その手順をまとめました。
検証環境
・vSphere 6.7 Update1
・vSAN 6.7 EP07
・HyTrust KeyControl v4.3.1-15304 (KMSサーバー)
※HyTrust KeyControlのOVAファイルは以下のURLからFree Trial版をダウンロードしました。
https://www.hytrust.com/products/keycontrol/
HyTrust KeyControlのOVAファイルをデプロイします。
デプロイ完了後、パワーオンしパスワードを設定します
コンソールでの設定が完了したら、Web GUIにログインします。
初回のログイン時はデフォルトの"secroot / secroot"でログインします。
User Name:secroot
Password:secroot
ログイン後はパスワードの変更が求められます。
以下のように、KMIPのStateを"ENABLED"に変更、Protocolを適切なVersionに変更します。
"Client Certificates"をクリックし、Actionsから"Create Certificate"を選択します。
Certificate Nameを入力して、"Create"をクリック
※今回はパスワード無しで設定します
"Download Certificate"をクリックします。
ダウンロードしたファイルを解凍すると、以下の2つのファイルがありますが
今回は、"kmvcert.pem"の方を使用します。
vCenterにKMSを追加します。
vCenter > 設定 > キー管理サーバ > 追加
必要情報を入力して追加をクリック
"KMSがVCENTER SERVERを信頼するようにします"をクリック
KMS証明書およびプライベートキーをチェックし"次へ"をクリック
ダウンロードして解凍したファイル(kmvcert.pem)をアップロードして、"信頼の確立"をクリックします。
接続状態が"接続済み"になりました
次は、vSANクラスタで暗号化を有効にします。
vSANクラスタ > 設定 > vSAN > サービス > 暗号化 > 編集をクリック
暗号化を有効化して、"適用"をクリックします。
上記で有効化の手順は完了です。
有効化後、vSANディスクの再フォーマットとディスクグループの再作成が行われます。
手順としては簡単ですが、注意事項として、KMSサーバーはvSANデータストア以外に配置する事が注意事項です。
※KMSサーバーが起動していない状態でESXiホストを再起動するとディスクグループがマウントされません。
[参考]
以上です。
vSAN健全性チェックで"コンポーネントのメタデータ健全性"のエラーが記録される
vSAN健全性チェックで、以下のように"コンポーネントのメタデータ健全性"のエラーが記録され、問合せを受ける事があります。
以下のVMware BlogやKBにも記載されている通り、発生する要因は様々です。
https://kb.vmware.com/s/article/2108690
基本的には、時間を置いてvSAN健全性チェックを実施し再度エラーが記録されなければ、問題無しと判断してますが、エラーが記録され続ける場合は対処が必要です。
確認すべきポイントとして、どのホストのどのDisk GroupのどのDiskにあるComponentに問題があるのか？という部分ですが、私は以下にて確認しています。
1."問題のあるコンポーネント"で報告されているホストにSSH等でアクセスします。
2,以下のコマンドを実行します。
※下記赤字のコマンドは全て一文です。
# for i in $(vsish -e ls /vmkModules/lsom/disks/ | sed 's/.$//'); do echo "Disk:" $i; localcli vsan storage list | grep $i -B 2 | grep Disp; echo "Recovered components:";vsish -e ls /vmkModules/lsom/disks/"$i"/recoveredComponents/ 2>/dev/null; echo; done
Disk: 52e942c5-0402-773e-739c-c13d4d5502d1
Display Name: naa.5000cca04eb33264
Recovered components:Disk: 5249a89f-ca32-e32b-5dd6-23a2c7cce2fd
Display Name: naa.5000cca080008db0
Recovered components:
ad5b675c-0bd5-b685-14c9-2c600cc099fb/ <<<★★★
626c6b41-7474-7243-6f6d-706f6e656e74/Disk: 5211113d-7a8d-21b0-2e80-ff2dddaf14ab
Display Name: naa.5000cca0800089d0
Recovered components:
626c6b41-7474-7243-6f6d-706f6e656e74/Disk: 524d16e1-96f4-d352-b873-904cb0ea7a32
Display Name: naa.5000cca080004ca4
Recovered components:
626c6b41-7474-7243-6f6d-706f6e656e74/
上記の出力は、DiskごとにRecoverd Componentsが表示され、問題のあるDiskをDisplay Nameから特定する事ができます。
3."vSANクラスタ" - "管理" "ディスク管理" から該当ホストのディスクグループを展開し
手順2で確認したDisplay NameのDiskを確認します。
以上の手順で問題のあるDiskを特定する事ができました。
特定した後は、監視ツールなどでハードウェアとしての正常性確認などを行います。
ハードウェア的に異常が見受けられない場合は、契約しているベンダーやVMwareのサポートに問い合わせるのが良いと思います。
- 該当DiskをDisk Groupから削除/再追加するのか
- 該当Diskが含まれるDisk Groupごと削除/再作成するのか
※Cache Diskが該当する場合は、Disk Groupの削除/再作成になります。
また、以下VMware KBに記載のある通り、ESXi 6.0, patch ESXi600-201706001以上&vSAN 6.6でFixとありますので、できるだけ最新のバージョンにした方が良さそうです。
https://kb.vmware.com/s/article/2145347
Resolution
This issue is resolved in ESXi 6.0, patch ESXi600-201706001 , available at VMware Patch Downloads. For more information on downloading the patch, see How to download patches in MyVMware (1021623).Important:
If you do not have any invalid state components at this time, upgrading to the patch is sufficient.
If your vSAN cluster is reporting invalid state errors before updating to patch ESXi600-201706001, open a Support Request with VMware support and reference this Knowledge Base article (2145347). For more information about filing a Support request, see How to file a Support Request in My VMware (2006985).For vSAN 6.5
This is a known issue affecting vSAN 6.5.
This issue is resolved in vSAN 6.6, available at VMware Downloads.
以上です。
ESGやDLRでインターフェースにIPを設定しようとすると空白のエラーが表示される
先日、Lab環境で以下のような事象に遭遇しました。
ESGもしくはDLRのインターフェースにIPを設定しようとした所、具体的なエラーメッセージは表示されないエラーがGUI上に表示され、IP設定ができませんでした。
切り分けとして、NSX Manager/ESG/DLR/vCenterの再起動も試しましたが解決せず。
ブラウザ(Google Chrome/Firefox)を変更しても同様。
調べていた所、どうやら、NSX ManagerのBugでした。
NSX v6.3.3でFixされています。
詳細は以下のVMware KBを確認して下さい。
https://kb.vmware.com/s/article/2151309
Note: This is a known issue in NSX for vSphere 6.3.2 and vSphere VCSA 6.5 U1.
上記KBによると、NSX v6.3.2とvCSA6.5U1で発生とありますが、
私の環境はNSX v6.3.1とvCSA6.5U2の環境でしたが、v6.3.3にアップグレードしたら
治りました。
