vSANの空き容量の考え方について教えてください。
①vSAN 7U1から、Slack spaceとして30%程度空きを考慮せずに、Capacity Reserveにより効率化されてより少ない空き容量で良くなったと理解しましたが、これは、Capacity Reserveを有効化(「OperationsReserve」と「HostRebuildReserve」を有効化)しないと、効率的な処理が行われないのでしょうか?
それとも、Capacity Reserveの有効・無効に関わらず効率的な処理は行われて、Capacity Reserveを有効化すると「OperationsReserve」と「HostRebuildReserve」用に容量を強制的に確保することになるだけなのでしょうか?
イマイチここが理解できませんでした。
②上記で空き容量は少なくサイジングできるようになったと理解したのですが、一方で、vSANのリアクティブリバランスのドキュメントには、以下のように、30%の空きを確保した方がよい記載が残っていました。
結局30%の空きを見込むことが推奨なのでしょうか?
「メンテナンスおよび再保護のために十分な容量を確保し、 vSAN クラスタでの自動リバランス イベントを最小化するため、常時 30% の空き容量を確保することを考慮します。」
① の vSAN 7.0u1 以降の Operations Reserve / Host Rebuild Reserve について、
まず vSphere Client から Capacity Reserve を有効化する事で予約した閾値に達した時点で新規の仮想マシンの作成やパワーオンが禁止されます。(既に起動中の仮想マシンの IO には影響ありませんがアラームが上がります)
以下のページの説明も併せてご確認ください。
つまり、Capacity Reserve を有効にしておく事で予定を超えた大量の書き込みで容量が枯渇しそうになる前にアラームを上げつつ、新規作成を禁止する事が出来るので以前より安全に運用できるようになったのが 7.0u1 の改善点です。
その意味で、
> Capacity Reserveの有効・無効に関わらず効率的な処理は行われて、Capacity Reserveを有効化すると「OperationsReserve」と「HostRebuildReserve」用に容量を強制的に確保することになる
この認識で合っています。
容量予約は、全体の 10% の Operations Reserve + 1/N の Host Rebuild Reserve が基本的なサイジングになります。
ただ、この上限ギリギリまで使い切るサイジングはやはり突発的なリソース要求や、Thinprovisioning で展開した仮想マシンのデータ容量の急激な増加で足りなくなるリスクもあるので、実際の用途や運用後の柔軟なドライブ追加が可能か否かである程度の余裕は確保した方が安全です。
また、バランスよくデータを配置する事も重要なので、自動バランシングは併用したほうが良いと考えます。
② のご確認いただいたリバランスの説明ページの 「30%」は、
恐らく従来のバージョンのページから記載が変わっていないため変更漏れと思われるのと、
もしくは 1/N の Host Rebuild Reserve が組める最小 4 Node 構成時の 30% の予約を考慮した値と思われます。
実際は Design Guide や vSAN Ready Node Sizer で計算されるものを前提として問題ないです。
1点注意が必要なのがサーバーメーカー、HDD/SSD メーカーが各ドライブの容量として載せている数値は SI 接頭辞(10進)での容量のため、実際に Hypervisor・OS から認識する 2進接頭辞では TB → TiB の換算の時点で 10% 近く目減りする事です。
1.92TB の SSD も OS から見ると 1.75 TiB として認識されるため、
机上計算時にメーカーカタログの容量で計算する際に 10% を考慮し忘れると容量が足りなくなる、ということになりますのでご注意ください。
※ vSAN Ready Node Sizer などはこの辺りは考慮した数値でサイジングされます。
① の vSAN 7.0u1 以降の Operations Reserve / Host Rebuild Reserve について、
まず vSphere Client から Capacity Reserve を有効化する事で予約した閾値に達した時点で新規の仮想マシンの作成やパワーオンが禁止されます。(既に起動中の仮想マシンの IO には影響ありませんがアラームが上がります)
以下のページの説明も併せてご確認ください。
つまり、Capacity Reserve を有効にしておく事で予定を超えた大量の書き込みで容量が枯渇しそうになる前にアラームを上げつつ、新規作成を禁止する事が出来るので以前より安全に運用できるようになったのが 7.0u1 の改善点です。
その意味で、
> Capacity Reserveの有効・無効に関わらず効率的な処理は行われて、Capacity Reserveを有効化すると「OperationsReserve」と「HostRebuildReserve」用に容量を強制的に確保することになる
この認識で合っています。
容量予約は、全体の 10% の Operations Reserve + 1/N の Host Rebuild Reserve が基本的なサイジングになります。
ただ、この上限ギリギリまで使い切るサイジングはやはり突発的なリソース要求や、Thinprovisioning で展開した仮想マシンのデータ容量の急激な増加で足りなくなるリスクもあるので、実際の用途や運用後の柔軟なドライブ追加が可能か否かである程度の余裕は確保した方が安全です。
また、バランスよくデータを配置する事も重要なので、自動バランシングは併用したほうが良いと考えます。
② のご確認いただいたリバランスの説明ページの 「30%」は、
恐らく従来のバージョンのページから記載が変わっていないため変更漏れと思われるのと、
もしくは 1/N の Host Rebuild Reserve が組める最小 4 Node 構成時の 30% の予約を考慮した値と思われます。
実際は Design Guide や vSAN Ready Node Sizer で計算されるものを前提として問題ないです。
1点注意が必要なのがサーバーメーカー、HDD/SSD メーカーが各ドライブの容量として載せている数値は SI 接頭辞(10進)での容量のため、実際に Hypervisor・OS から認識する 2進接頭辞では TB → TiB の換算の時点で 10% 近く目減りする事です。
1.92TB の SSD も OS から見ると 1.75 TiB として認識されるため、
机上計算時にメーカーカタログの容量で計算する際に 10% を考慮し忘れると容量が足りなくなる、ということになりますのでご注意ください。
※ vSAN Ready Node Sizer などはこの辺りは考慮した数値でサイジングされます。
kawamanさん
早急なご回答ありがとうございます。
また詳細なご説明ありがとうございます。