vSAN File Service DEEP DIVE (1)
vSAN7.0のdebutと共に、大きな新機能として公開されている"vSAN File Service"について
確認した内容を備忘録としてまとめます。
※ DEEP DIVE と銘打ってますが、ほとんどは基礎的な内容です。
期待を煽る内容で申し訳ないですが暖かい目で見ていただければ幸いです。
簡単な構築並びにマウントまでのデモ・VIT(vSAN iSCSI Target Service)との比較や
ログバンドルからの状態確認等をしていきたいと思います。
■検証環境
vCSA 7.0 build: 16189207
ESXi 7.0 build: 16324942
vSAN 4node cluster (All Flash)
iSCSI/NFSマウント用VM：Windows Server2016 (IP: 10.10.35.54)
vSAN File Serviceとは？
基礎的な内容らしく、vSAN File Serviceとは何か、から抑えたいと思います。
既に色々なBlogでまとめられていますので、簡単に記載するにとどめておきます。
・vSAN File Serviceとは、vSAN datastoreをNFSストレージとして提供する機能である。
・vSAN Enterprise / Enterprise Plusエディションで使用可能な機能である。
※ VITは全エディションで使用可能。
・有効化する事で各Host上にvSAN File Service提供用のVMが構築される(FS VM)。
このVMは4CPU/ 4GB RAM / 12GBの仮想Diskを保持する。
固定IP + DNS登録が必要となり、全FSVMが同じIPサブネットに属する必要がある。
・このVMはEAM (ESX Agent Manager)が管理元となり、DRSの影響を受けない。
(1Host 1FSVMである事が求められているのでDRSの影響を受ける必要が無い)
・vSAN FSVMのストレージポリシーは初期状態から変更してはいけない。
・分散スイッチは6.6.0以降である必要がある。
また、強い推奨としてvSAN FSVM専用の分散ポートグループ設定が求められる。
・寄稿時点ではNFS3 / NFS4.1プロトコルでの提供がサポートされている。
・ESXi自体にNFSストレージとしてマウントする事も可能であるが、
vmware社としてその構成をサポートしていない。
・最低3ノードのvSANクラスタ上で構成可能であり、ストレッチクラスタや
2ノードvSANでは寄稿時点で使用出来ない。
vSAN iSCSI Target Serviceとの併用・比較について
vSAN iSCSI Target ServiceとvSAN File Serviceを併用する事は、
結論から言えば全く問題ありません。
以下、vSAN iSCSI Target Serviceを有効化するまでの簡単なキャプチャです。
vSAN上でVITを有効化させ、IQNを発行しています。
LUN単位での切り出しをするので、事前に容量定義が必要です。
今回はテスト用に10GBの容量を定義してみました。
Windows上で切り出された容量と同じだけのiSCSI接続デバイスが表示されている事がわかります。
この状態で、更にvSAN File Serviceを有効化していきたいと思います。
事前準備として、FS VM構築に必要なAD DNSに登録を済ませておきます。
構築にあたって入力する必要がある内容は以下KBにもまとめられています。
FS VMのOVFは初期有効化画面でダウンロードする事が可能です。
このダウンロードを一回しておけば、一旦無効化した後も
再度同じOVFを使いまわす事が出来ます。
インターネット接続がされていない場合は、手動でOVFアップロードをする事も可能です。
ただ、例えばDownloadが始まったものの上手くいかなかった等の場合も
次回再有効化する時にそのOVFを使いまわすような表記が出てしまい
例えばOVFを手動でアップロードしたり、Downloadしなおす選択肢が出ない事を確認しました。
そんなときは事前に以下作業をする事で、再度OVFのDownload または手動Uploadが
出来る事を確認しています。
■ vCenterへログインしOVFを削除する作業
vCenterにログインし、/storage/updatemgr/vsan/fileservice 配下にダウンロードしたOVFが格納されているような状況でしたので、
シンプルにrmコマンドで削除をしています。
一応この後service-controlコマンドで全サービス再起動もしていたのですが、
もしかしたらその必要も無いかもしれません。
・全て入力が終わり、有効化を押すとFSVMのDeploymentが始まります。
検証環境で何度か有効/無効を繰り返していますが、
いずれも大体15分程度でDeployが完了しました。
Deploymentのタスクを追いかけていましたが、どうやら1台FSVMが作成された後
そのFSVMをクローンする形で残りのFSVMを作成しているように見えました。
Deploymentが完了するとこんな感じでFSVMが作成されます。
各Hostに1台ずつ、計4台のFSVMが作成されています。
FSVMの作成が完了後、VITとvSANFSが問題なく併用出来ている事がわかります。
テストマウント用VMにNFS Clientを導入し、実際にマウントした図がこちら。
vSAN File Serviceで閲覧できている残容量はvSANの容量と(ほぼ)同義です。
VITでは先にLUNを切り出す必要がある為、最初に設定した容量で
空き領域が反映しているのに対して
vSAN File ServiceではvSAN容量の全てが表示されている事がわかります。
一旦アンマウントの後vSAN File Serviceを再設定し、
そのうえでHard Quotaを設定して再マウントしてみましたが
マウントしているVM側から見る限り容量値にほぼ変化はありません。
※ このHard Quotaは、Nutanix機能で言う所のAdvertised Capacityに非常に近いものと捉えていただいて問題ないと思います。
Hard Quota設定後の再マウントも見えてくる容量の結果は変わらず。
また、Hostのパフォーマンス項目を確認するとVITに関連する項目はありますが
vSAN File Serviceに関するPerformance項目はありません。
これはVITが物理ホストを使用してサービスを提供しているのに対して
vSAN File ServiceはFSVMが機能を提供している事による差異だと思われます。
<Performance Chart >
vSAN File Serviceの使用量について
使用を検討した時、恐らく一番最初に気になるであろう "実容量確認方法" ですが
特別な手順を踏む事なくvCenter上で確認が可能です。
試しにファイルを少し入れてみました。
テキストファイルとフォルダ内のファイルは合計16KBのファイルです。
ファイルが認識されると、vCenter上でも実行容量が確認出来ています。
vSAN File Serviceとして配置されるデータのObject処理について
※ こちらは残念ながら検証環境が小さい関係で一部検証が出来ておらず
推察による考察部分が大きいので、実際の仕様と異なる可能性があります。
参考としていただければ幸いです。
vSAN File Serviceとして配置されるデータについて、Object増減の推移を確認してみます。
■ vSAN File Serviceのルートとして記載されているObjectについて
先程配置したテスト用データを全て削除し、vSAN File Serviceで展開しているNFSについて
中身を空にした状態でのObjectはこのような状態です。
RVCのobj_status_reportでも同様の結果です。
一応Object Infoも確認しておきます。
この状態で、テスト用のファイルを改めて格納してみます。
※ 余談ですが"割り当てを超える使用量"という日本語はすこし不自然ですね...
この値はこの後の検証での増減を見るに"HardQuotaの単純使用率"という認識でいいと思います。
格納後改めてObject Infoを確認していますが、USAGEに特段の反映はありませんでした。
あくまでこのObjectはvSAN File Serviceを展開する為だけのObjectなのかなと思います。
■ データの実体はどこにあるか
さて、問題のファイル実体オブジェクトはどこにいるのかという事で、
確認しやすくするために新しいStorage Policyを作っておきました。
"vSANFS-Dedicated-Policy-FTT1"と便宜上名付けています。
このオブジェクトはvm_object_infoでは出てこないので、
diskのobject_infoから検索したところ無事発見する事が出来ました。
(やはりポリシー名は細かく分けておくに限りますね。)
さて、このオブジェクトについてさらに確認をする為、100MB程度のファイルを
たくさん突っ込んでみます。
GUIへの反映も、一応都度確認しておきます。
この状態で、Objectがどうなるかを確認してみます。
配置されたファイル毎にオブジェクトが作成される訳ではなく、一つのオブジェクトが
足されたファイルの分だけ肥大している事がわかります。
恐らくこちらは容量が255GBを超えると通常のvSAN同様に
オブジェクトがStripeされるのだろうと想定されます。
一つのファイル毎にWitnessが作成される訳では無いため、ファイルの数だけメタデータが作られないという意味では
容量効率の良い構造だと言えると思います。
GUIで閲覧できる使用率や初回設定するHard Quotaの値等はFTT計算前の値になるので
実際はGUIに表示される使用量以上のデータがvSAN datastoreに配置されます。
サイジングについては運用上要注意ですね。
vSAN File ServiceのLoggingについて
vSAN File Serviceのログ出力についても簡単に確認をしてみます。
例えばVITを動作させると、iSCSI Connection等を司る"vitd"サービスのログ出力が開始されます。
vSAN File Serviceについて確認をしてみたところ、/var/run/log 配下でいくつか動きのあるファイルがいたので記載しておきます。
・vdfstool
・vsanfs.mgmt
・vsanfs.vdfsop
何か問題があった時はこの辺りから確認してみると良さそうです。
また、ESXi Hostを見るとvSAN DatastoreだけでなくVDFS Datastoreが作成されています。
CLIであればどのようなファイルが格納されているか、等もESXi側から確認が出来そうです。
以上、備忘録でした。
疑似障害を発生させた時の挙動はまた次のタイミングで検証したいと思います。
