30 メッセージ
0
286
VxRailのvSANデータストアの環境において、仮想ディスクのThick→Thin変換は可能でしょうか。
皆様、いつもお世話になっております。
VxRailのvSANデータストアの環境において、仮想ディスクのThick→Thin変換は可能でしょうか。
vSAN環境ではSP(ストレージポリシー)のOSR=100 (オブジェクト スペース予約)の状態から、OSR=0とすることで Thick→Thin変換が可能であると考えております。
この際に方法としては、OSR=0となる新しいSPを作成し、対象仮想ディスクに適用する。
もしくは現在、対象仮想ディスクに適用されているSPのOSR=0とすることで可能である考えております。
この作業のみでThick→Thinへの変換が完了されますでしょうか。
もし、他に有効な方法があればご教授いただけますと幸いです。
以下では上記のようにSPのOSRを変更することで変換できるということが書かれていました。
DELL-Naoyuki K
4 Operator
4 Operator
•
1.7K メッセージ
0
2023年1月20日 01:00
はい。VxRailにおいても通常のvSANと同じようにThick->Thinの変換は可能です。
手順もご想定のとおりですが、適用済みのStoragePolicyの設定を変更する場合は、該当のStoragePolicyを利用するVMおよびVMDKのすべてが影響を受けますので、新規でStoragePolicyを作成し、適用する方が一般的に安全です。
比較的最近のvSANストレージポリシーにおいてはOSR=100 or 0としてThick/Thinを表現するのではなく、GUI上においてもThick/Thinの表記に変わっております。
また、VxRailの場合は管理VMに対してはThickで容量を割り当てるデザインになっています。万一の容量枯渇時においてもトラブルシューティングや復旧作業で必要となる管理VMを維持する意味でも、管理VMの設定はThick維持が推奨です。
なお、vSANにおいてThick -> Thinの変換は瞬時に完了しますが、Thin -> Thickの変換はオブジェクトのリビルドが開始される都合上時間がかかりますので、もしうっかり対象外のVMをThinにしてしまって、Thickに戻す場合はその点はご注意ください
DELL-Naoyuki K
4 Operator
4 Operator
•
1.7K メッセージ
0
2023年1月22日 17:00
具体的な処理内容まではvSANについての公開資料からは確認ができませんでしたが、おそらくはThickにするためのマッピング処理（容量確保）をしているか、もしくはvSAN Object自体を再作成しているものと思います。
いずれにしても、Resyncという枠組みで実施されている限りは、vSANの帯域調整が自動的に走りますので、パフォーマンスに大きな影響がないと考えてよいと思います。
gazania
30 メッセージ
0
2023年1月22日 17:00
もう一点確認させていただきたいです。
Thin -> Thickの変更時に起こるオブジェクトのリビルドに関して具体的に起こる処理をご教授いただけないでしょうか。
この時、容量確保を行っているだけの状態を考えていました。そのため、書き込みパフォーマンスなどに大きな影響はないと考えていましたが、その他に大きな処理が走る想定でしょうか。
gazania
30 メッセージ
0
2023年1月22日 21:00
Resyncという枠組みで実施されている限りは、vSANの帯域調整が自動的に走るので、パフォーマンスに大きな影響がない旨、承知しました。
ご回答ありがとうございました。
DELL-Naoyuki K
4 Operator
4 Operator
•
1.7K メッセージ
0
2023年1月22日 23:00
kwmtさん、コメントありがとうございます。
Thick -> Thin の場合はRebuidが走らない、というのは同じ認識です。
私がラボでRebuild（Resync）が走る挙動を確認したのは、逆向きの Thin -> Thick ですね。
少し前にラボで確認し、細かい手順やバージョンなどは控えていなかったのですが、VxRail 4.7.x（vSAN 6.7）とVxRail 7.0（vSAN7）で試しました。
結果は、
Thin -> Thick はResyncあり。
Thick -> Thin はResycnなし。
となりました。
kwmt
4 Operator
4 Operator
•
877 メッセージ
0
2023年1月22日 23:00
横からすみません、kanedaさん、Thick -> Thin 時に RAID 構成に変更がなければ OSR 100 -> 0 でもリビルド(最同期 IO) は走らなかったはずです。
試しに手元の環境で初期状態で OSR 100% でクローンして作った VM を起動した状態で OSR 0% を適用しましたが、オブジェクト再同期モニタの他、バックエンド IO、サポートパフォーマンス上の再同期 IO 関連の PerfMon を確認しましたが通信は発生していませんでした。
vSphere 7.x 以降、vSAN 上だと PowerCLI でも eagerzeroedthick は作れなくなりましたり、実質的に Thin と Thick は容量予約の観点だけだと認識しています。
※ vmkfstools で zeroedthick / eagerzeroedthick を指定で作成した場合の挙動は未確認
その他詳細情報無いかもう少し調べてみます。
kwmt
4 Operator
4 Operator
•
877 メッセージ
1
2023年1月23日 00:00
あ、読み間違えていました、理解しました(^^;
Thin -> Thick 時の挙動に関して、これ実際は Resync (再同期) ではなく内部的にはポリシー変更 IO としてクラスタ内で更新が走っているだけなので通常の Resync とは処置が異なります。恐らく予約領域のマッピングをしているのだと思われます。
実際にどの程度の IO が発生しているかは、
クラスタ > 監視 > vSAN - サポート > サポートのパフォーマンス > クラスタの再同期
このグラフを見ると通常の再同期 IO とは別に、「ポリシー変更書き込み」「ポリシー変更読み込み」のメトリックがあり、ここで今回のような OSR 変更時の IO の状況が確認できます。