1. イントロダクション
2. 前回の記事のおさらい
3. vSAN ESA ネイティブスナップショットとはどのようなもの？
4. なぜ vSAN ESA はスナップショットを取得しても高速なままなのか？
4.1. デルタディスクが無い？では vSAN ESA スナップショットはどこにあるのか？
4.2. vSAN LFS はメタデータと実データをどのように扱いスナップショットを実現させているか？
4.3. vSAN ESA のスナップショット取得時の書き込みを見てみる
4.4. vSAN ESA のスナップショット取得時の読み込みも見てみる
4.5. vSAN ESA においてスナップショットの世代を増やすインパクトは？
4.6. スナップショットの削除処理はどうなるのか？
5. ESAのスナップショットに性能劣化がないのは本当？OSAと同じ機材で比べてみる
5.1. 検証環境
5.2. 検証に用いた負荷
5.3. 検証結果と手順
6. 検証結果のまとめと意義～新しいスナップショットが生む用途は広い～
次回予告
あとがき
1. イントロダクション
VMware vSphere 8 が 2022 年 10 月にリリースされて一年以上が経過し 8.0 U2 もリリースされた 2023 年末において、弊社のミッドレンジ以上のストレージに接続された二桁万台にのぼるインストールベース ESXi ホストのバージョンを確認すると、8.0、8.0 U1、8.0 U2 で稼働しているものは未だ 2% に過ぎない。つまり、6.x、7.x で稼働しているものがまだ 98% を占めている。となると vSphere 8.0.x の導入は多くのユーザにとってこれからが本番になるだろう。そんな vSphere 8.0 のエンハンスの目玉の 1 つは VMware vSAN の新機能である vSAN ESA だ。今後の vSphere 8 導入の本格化を迎えるにあたり、vSAN ESA を検討する方が増えることが予想される。そのような方に向けて HPE では vSAN ESA で改善されたスナップショット機能の実機検証を行った。この連載ではその検証結果を今後 4 回にわたってシェアしたい。記事の内容は以下の通り。
- 長年続いた vSphere スナップショット問題を振り返る
- vSAN ESA はスナップショットを克服したか？
- vSAN ESA スナップショットを活用したバックアップ～早く、安く、シンプルに～
- vSAN ESA のスナップショットが vSphere のストレージエコシステムに与えるインパクト
vSAN ESA のスナップショットの改善は vSAN 歴史のみならず、それを超えた vSphere の歴史を通じた見た中でも非常に注目に値する改善だ。これからの vSphere を使ったアーキテクチャや運用に大きな影響を与える可能性を秘めている。特にストレージ設計、バックアップやレプリケーションの運用に悩みを抱えてきた方にとってはそれらを一挙に解決するものにもなり得る。にも関わらず、この重要なポイントに関する実測値を踏まえた検証結果は公開されてはいない。vSAN ESA の導入を検討しているにしろしないにしろ、vSAN ESA のスナップショットの効果を知らずして vSphere 8.0 のインフラを検討することは残念なことだ。得られたかもしれない vSAN ESA スナップショットの恩恵を得られないまま、次の更改のタイミングまでそのインフラで運用を続けていくことになりかねないからだ。著者としてはそのような残念な結果になるインフラが生まれるのを可能な限り防ぎたい。そう考えて実機での検証の公開に踏み切った。vSphere 8.0 の導入を検討する方への有益な情報になると願っている。
2. 前回の記事のおさらい
vSAN ESA のスナップショットについて論じる下地となる前回の記事を振り返っておこう。前回は「長年続いた vSphere スナップショット問題を振り返る」と題し vSAN ESA 登場以前の vSphere スナップショットの課題について論じた。vSAN ESA 登場以前のスナップショットでは、スナップショット運用時に様々な状況で性能面のペナルティを受けるという課題を取り上げた。そして、そのペナルティが起こるメカニズムを解説し、加えて、そのペナルティの度合いの大きさがどの程度になるのかを実機を利用した検証で確認した。その結果をまとめたのが下のグラフである。グラフから従来のスナップショットと性能の関係について以下のことが読み取れるだろう。
- スナップショット取得後に性能劣化が起こり、スナップショット保持中はそれが継続する
- スナップショット保持世代数を増やすとそれに応じて性能劣化の度合いが大きくなる
- スナップショット削除時は保持時のペナルティに更に追加の性能劣化が加わり、それは削除完了まで継続する
3. vSAN ESA ネイティブスナップショットとはどのようなもの？
ここから本題の vSAN ESA のネイティブスナップショットについての話をはじめていく。vSAN ESA のスナップショットについては VMware の記事『the vSAN Express Storage Architecture』の中で 概要が紹介されている(英語の記事ではあるがブラウザの日本語翻訳機能で比較的読みすい日本語で読める)。vSAN ESA 登場以前の歴史的経緯を追って説明されており vSAN ESA のスナップショットの重要性の理解度を深める上で有益だ。
この記事の中で言及されている「 REDO ログベースのスナップショットアーキテクチャ」というのが前回の記事で解説した、ベースディスクとデルタディスクをスナップショットマッピングファイルでマッピングするアーキテクチャのことだ。また、 VMFSsparse、SEsparse、vSANsparse というワードが紹介されているが、これらは REDO ログベースのスナップショットの実装のバリエーションだ。vSANsparse が vSAN OSA で利用される vSphere スナップショットの形式であり、その他の VMFSsparse、SEsparseが vSAN以外の内蔵・外部ストレージを利用した際の vSphere スナップショットである。よって、前の記事では vSANsparseでの性能を確認したことになる。
さて、主役の vSAN ESA のスナップショットについて見ていこう。『the vSAN Express Storage Architecture』の中で挙げられている vSAN ESA ネイティブスナップショットの特徴をピックアップすると以下の通りだ。
- ベースディスクとデルタディスクのチェーンは使わない
- ルックアップテーブルの B ツリーでメタデータを扱う
- スナップショットのデータがどこに配置されているかはメタデータのポインタで示す
- スナップショット取得後の書き込みデータは新しい空き領域に追記する
- スナップショット削除はメタデータを削除する論理的な処理
そして、記事全体を通したメッセージはこれらの特徴によって vSAN ESA のスナップショットは従来のものより高速になっているというものだ。この記事の続くセクションではこの部分に解説を加えていく。
4. なぜ vSAN ESA はスナップショットを取得しても高速なままなのか？
前のセクションでピックアップした特徴は 以前のアーキテクチャとの変更点を中心に指摘したもののため、これらがどのように高速化に寄与しているかイメージがつきにくい。これらの変更点は 従来の REDO ログベースアーキテクチャで発生していたスナップショット保持時に生じてしまっていた追加の I/O を発生させない効果をもっている。
4.1. デルタディスクが無い？では vSAN ESA スナップショットはどこにあるのか？
vSAN ESA のスナップショット取得時に従来のように追加の I/O が発生しなくなった要因の一つは、ベースディスクとデルタディスクのチェーンを使わなくなったことだ。繰り返しになるが、従来の vSphere スナップショットの実体はスナップショット取得時の状態を維持しておくための読み込み専用になったベースディスクだった。そして、スナップショット取得後に仮想マシンが書き込みを行うディスクはベースディスクとは別に作成されるデルタディスクだった。これらは VMFSや NFS のデータストアでは異なる vmdk ファイルとして格納され、さらにこれらとは別に作成されるスナップショットマッピングファイルが両者の差分をトラッキングすることで現在仮想マシンが利用しているディスクとスナップショットの関係が維持されていた(vSAN OSA の場合はファイルではなくオブジェクトだがベースディスク、デルタディスク、マッピングデータがそれぞれ異なるオブジェクトであり、マッピングデータにより差分がマッピングされている点で同じだ)。スナップショットを取得した後にこれらの別々になったファイルへそれぞれに追加の I/O を行うがために、これまでの vSphere スナップショットは遅くなっていた。
一方、vSAN ESA ではスナップショット取得時にデルタディスクもスナップショットマッピングファイルも作成しない。そのためベースディスクとデルタディスクのチェーンが存在せず、使用しない。もう少し正確に言うと、デルタディスクやマッピングデータ自体は概念としては未だに存在し続けているが、ベースディスクの内のプロパティに変わった。つまり、スナップショットを取得してもデルタディスクやマッピングファイルはベースディスクと異なる新しい個別のオブジェクトとして生成されることがなくなった。それにより従来の vSphere スナップショットで発生していた追加の I/O がなくなった。それはどのように実現されているのか、もう少し具体的にその仕組を見ていこう。その仕組みの鍵になるのは vSAN ESA で新しく vSAN スタックに追加されたレイヤ vSAN LFS だ。
4.2. vSAN LFS はメタデータと実データをどのように扱いスナップショットを実現させているか？
vSAN LFS とは何か。それは vSAN ESA に効率性と高速性を両立を実現させているキーとなるコンポーネントの一つだ。重要なコンポーネントであるため触れたい点は多いのだが、本記事ではスナップショットの性能に影響を与える部分以外はあえて大きく簡略化し、スナップショット取得時になぜ追加の I/O が生じないようになっているのかの説明になる点にだけ焦点を当てて見ていく。
LFS は Log-structured filesystem を略したもので日本語ではログ構造化ファイルシステム、またはログ構造ファイルシステムと訳され、この言葉自体はファイルシステムの実装方式についての一般的な用語だ(すぐに後述する)。VMware では vSAN ESA 向けにログ構造化ファイルシステムを独自に開発、特許を取得し実装している。vSAN ESA ではこの vSAN LFS が vmdk の実データの格納先を示すメタデータを管理する仕組みとなっている。そして、vSAN ESA の それぞれの vmdk オブジェクトは個々に vSAN LFS を持ち、vmdk オブジェクト のメタデータは1対1で対応する vSAN LFS に B-tree 形式で格納されている。この B-tree 形式のメタデータを辿ってポイントされる先が vmdk の実データである。
LFS (ログ構造化ファイルシステム)というワードに注目して別の側面も見てみよう。ログ構造化ファイルシステムは、ユーザデータとそれに対するメタデータをログをまとめて循環バッファ領域に順次書き込んでいくファイルシステムのことだ。vSAN ESA では vmdk への書き込み時に(vmdkはファイルシステムではないが)この仕組みを利用する。書き込みは実データとメタデータが追記形式で書き込まれていく。追記形式であるため既に書き込まれたデータへの更新時に上書は行わない。更新データは新たな空き領域に追記される。「上書き処理が行われない」「常に追記である」ということを既に書き込まれた後の実データの側に着目してみると、一度書き込まれた実データは、それが不要になるまで Read Only として格納されているということだ。
ここまでの話を図にすると以下のようなイメージとなる。予め「A」「B」「C」というデータが書き込まれていた vmdk に対し、「B」を「B’」への更新し、新たなデータ「D」を書いた状況を示したものとなる。
前セクションで vSAN ESA におけるスナップショットは vmdk とは別のオブジェクトではなく、vmdk オブジェクトのプロパティの一部であると説明した。そして、vmdk オブジェクトは1つの vSAN LFSを持ち、そこにメタデータを格納しているとも述べた。つまり、vSAN ESA においては、ベースとなる vmdk とそのスナップショットは vSAN LFS を内でメタデータを共有している。先ほどと類似の表現を使ってvSAN ESA でスナップショットを取得した場合のイメージは以下の図のようになる。スナップショットの有無に関わらず書き込み済みの実データは Read Only のため、スナップショット用のポインタをマッピングすればそれは静的な状態を維持した取得時点のイメージとなる。次以降のセクションでは前回の記事同様、スナップショットを取得した状態での I/O の様子を見ていこう。
4.3. vSAN ESA のスナップショット取得時の書き込みを見てみる
前のセクションで、vSAN ESA ではスナップショットのマッピングファイルがないこと、ベースディスクとスナップショットがメタデータを共有していること、データは常に追記されることを説明した。それらを踏まえて、まずはスナップショットがない状態での vSAN ESA のvmdkへの書き込みと、スナップショットを保持した状態での書き込みの違いを図示したものを見比べてみよう。
図中左側がスナップショットのない状態における vmdk へのデータの書き込みの様子だ。データ「B」を「B’」に更新し、「D」を追記している。もう一方の右側はスナップショットを保持した状態の vmdk への書き込みの様子だ。「B’」への更新、「D」への追記と、左図と同じ処理を行っている様子を表している。見比べてみていかがだろうか？パッと見た印象でもほとんど変わらないように見えないだろうか？実際、処理の上でもほぼ変わらない。追記式のため既に書き込み済みの「A」「B」「C」についてはスナップショットがあってもなくても Read Only で変更は加えられない。「B」を更新する場合は左右両者とも新たな領域に「B’」を書き加えるだけであり、メタデータについても新たな領域にポインタを貼っているだけである。ベースディスクとデルタディスクのチェーンの形式の場合はスナップ取得後の書き込み時はスナップショットのマッピングファイルを更新してから、実データをデルタディスクに書き込むというひと手間が必要でこれが追加の I/O の発生源だった。だが、vSAN ESA ではスナップショットがあってもなくても書き込み時の実質の動作は同じであり、追加の I/O を発生させない。そのため、vSAN ESA ではスナップショットを取得しても書き込み性能が落ちることはない。
4.4. vSAN ESA のスナップショット取得時の読み込みも見てみる
書き込みと同様に読み込みについてもスナップショットのない状態とスナップショットを保持した場合のイメージを比較して見てみよう。
実データの格納場所を示すポインタは vSAN LFS の B-tree に格納されておりスナップショットもアクティブな vmdkもそこからデータを参照している。そのため、vSAN ESA 以前のスナップショットのようにスナップショットのマッピングファイルを参照して読み取りたいデータがベースディスクにあるのか、デルタディスクにあるのか判断し複数のファイルをトラバースする必要がない。書き込み時の比較と同様の読み取りにおいても vSAN ESA ではスナップショットを取得していても取得していなくても同じ動作であり、スナップショット保持による追加の I/O 発生することはない。よって、vSAN ESA は読み取りにおいても性能劣化はない。
4.5. vSAN ESA においてスナップショットの世代を増やすインパクトは？
スナップショットの世代数を増やした場合はどうだろうか？この場合もスナップショットがない場合と比較してみよう。
右側の図は複数のスナップショットを保持していることを表現するために複雑な図になってしまっているがハイライトしてある青い点線に注目して欲しい。メタデータが実データの格納先を示したのが青い点線だが、図を見比べると仮想マシンが現在使用しているディスクのメタデータから実データへのマッピングについていうと、スナップショットのマッピングファイルがないのでスナップショットがあってもなくても変わらない。結果、スナップショットの世代数を増やすことも I/O の増加にはつながらず、この場合も性能劣化を招かない。
ただし注意点はある（これは vSAN ESA に限らずあらゆるストレージのスナップショットに言えることなので今更指摘することでもないかもしれないが）。スナップショットの世代数を増やし、それを（用途がないのに）長期間保持し続けることは避けたほうが良いだろう。長期間の保持によって使われていないデータが蓄積し vSAN ESA の容量枯渇を招く可能性があるからだ。
4.6. スナップショットの削除処理はどうなるのか？
データは常に追記で書かれているので、スナップショットは取得した時点の実データに対するポインタの集合体でしかない。そのためスナップショット削除はスナップショットが参照しているメタデータを削除するだけの処理となる。この処理は結局、スナップショットを取得していない状態でも発生しうるデータ更新によって参照されなくなった領域の UNMAP での回収と同じものとなる。ポインタだけの処理となるため以前の vSphere スナップショットのように削除に時間を要するということもなく、一瞬で削除が完了する。また、vSAN ESA 以前までのスナップショットのようにスナップショット削除用のスナップショットを追加で取得し、その上でベースディスクにデルタディスクの更新データを書き戻すというような重い処理は必要ない。つまり、削除完了までに発生していた長時間の性能劣化は発生しない。
5. ESA のスナップショットに性能劣化がないのは本当？ OSA と同じ機材で比べてみる
vSAN ESA のデータストア上の仮想マシンに高負荷のディスク I/O をかけた状態でスナップショット操作を実施し、その操作が性能に与える影響を確認する。
5.1. 検証環境
検証に利用した環境は以下の通りである。
仮想マシン x 1 台
- vCPU ：8 core
- メモリ ：8 GB
- 仮想ディスク：
- OS領域：16 GB
- データ領域：100 GB x 2
vSphere/vSAN クラスタ
- ESXi/vSAN ホスト x 6 台
- CPU：12 core x 2
- メモリ：192 GB
- ドライブ：NVMe SSD x 4 ※ vSAN ESA にはキャッシュとキャパシティの区別はないため OSA と異なりすべての NVMe ドライブをvSAN データストアとして構成している。
- vSAN ESA 上の仮想マシンのストレージポリシーは RAID-6、圧縮有効
ハードウェア構成のポイントは前回のvSAN OSA とまったく同じ構成になっている点だ。そのためハードウェアによる差異は排除された形で純粋にvSAN ESA とそれ以外のvSphereスナップショットの実力を比較できる形になっている。参考までに今回もvSAN ESA ReadyNode Hardware Guidanceのカテゴリと比較すると今回の構成はvSAN ESAではもっとも小規模なAF-0の構成に該当する。vSAN ESA としてはまだまだ余力を残した構成だ。このような記事でしばしば見られる”見せ玉”用の構成ではない。異なるドライブ構成で導入したとしてもこの記事の結果から期待したものと導入したものが明らかに異なるということは起きないと思われる。
5.2. 検証に用いた負荷
上記の仮想マシンからvdbenchを用い２つのデータ領域のvmdkに以下のプロファイルのIOをかけた。
- BlockSize: 8 KB
- Read: 50%
- Random: 100%
- Thereads: 16/disk ※ 1 つの vmdk あたりにかける I/O の並列度。この検証では vmdk に 16 並列で負荷をかけている。
事前調査の段階で計測したデータでは、この環境に上記のプロファイルでIOをかけた場合、以下の数値を示す。これは負荷をかけている2つのvmdkの値を合計した数値である。62,371 IOPS( @ Latency 0.51 msec)
この vSAN OSA のデータストアの性能特性を掴んでいただくため参考として Read 比率を 100% ~ 0% まで変化させた場合の性能の様子を以下に示す。
5.3. 検証結果と手順
①上記の負荷を 10 分何もしない状態でかける ②約 2 分前後の時間でスナップショットを連続取得する ③取得したスナップショットを保持した状態で 10 分間負荷を継続する ④すべてのスナップショットを一気に削除し 10 分負荷を継続する
全体で 30 分程度負荷を継続する検証となっており、この間の性能の変化を時系列で観察したものが以下のグラフである。
①はスナップショットを取得しないで負荷をかけている状態だ。事前検証と同様に平均 62,000 IOPS 近辺の IOPS を維持している。vSAN ESA は書き込みバファーに該当する Performance Leg で細かい I/O を一度受け仮想マシンに Ack を返した後に、それらの細かい I/O を 512 KB にシリアライズした後にパリティをつけて Capacity Leg にシーケンシャルに書き込むアーキテクチャのため、その処理のタイミングで性能が上下している様子も見てとれる。
②のタイミングで VM のファイルシステムの静止点を確保しつつスナップショットを取得してる。前回の vSAN OSA では 1 つのスナップショット取得に 3 分程度の時間を要したが、vSAN ESA ではスナップショットを 1 つとるのに要する時間は 4,5 秒程度である。そのため前回はスナップショットを取得する時間に 10 分を確保し 3 世代取得したが、今回は 2 分間に 10 世代取得してみた。
③スナップショットを 10 世代維持した状態で 10 分間負荷をかけ続ける。OSA の場合とは異なり目立った性能劣化はない様子。④において 10 世代のスナップショットを同時に削除する処理においても同様に性能劣化は観察されなかった。加えて OSA とは異なりスナップショットの削除も 3 秒で終了した。
6. 検証結果のまとめと意義～新しいスナップショットが生む用途は広い～
今回の記事では vSAN ESA が従来の vSphere スナップショットの課題を克服していることについて採り上げた。従来の vSphere スナップショットが I/O 性能を低下させていた要因は追加の I/O を発生させていたからだった。そのため、この記事では追加の I/O が発生するかどうかにフォーカスして、vSAN ESA のスナップショットの動きを見ていった。スナップショットを取得した状態で行う「書き込み」「読み込み」そして「世代数の増加」「スナップショットの削除」いずれの場合においても追加の I/O が発生しない仕組みであることを解説した。加えて、実機での検証を通じてその仕組が実装上においても成功していることも確認した。vSAN ESA のスナップショットは従来の vSphere スナップショットとはまったく異なるものだった。高速に取得・削除が可能で、スナップショットの有無やオペレーションが I/O 性能に影響を与えないことが確認できた。 検証結果のシメとして vSAN ESA のスナップショットが従来のスナップショットとどれほど異なるかを、前回の記事の検証結果を重ねたグラフで見ておこう。
検証結果のまとめを確認したところで、この結果の意義についても考えてみよう。端的には vSAN ESA を使用すればこれまでの vSphere スナップショットのように性能劣化を心配することなくスナップショットが取得できるということだ。そして、性能劣化がないだけでなく、スナップショットを取りたい時にすぐに取得でき、削除も性能への影響を心配なくすぐに削除できる。これまでの恐る恐るの運用はもういらないのだ。
これまでの恐る恐るのスナップショット運用をしなくて良いとなると何ができるだろうか？気軽にスナップショットを取得・削除できるとなると、ゲストOSやその上で動くアプリケーションのメンテナンスは楽になるはずだ。アップデート、パッチ適用のためのステージングのためにサッとスナップショットをとって確認することができる。CI/CD パイプラインにも組み込みやすいだろう。スナップを保持した状態でも性能に影響がないのであらば、デプロイ前後にスナップショットを取得しても心配はない。なんらかの用途で取得したスナップショットをしばらくの間保持しておくことも、以前より容易になるだろう。その保持しておいたスナップショットがランサムウェアから仮想マシンを救うことになるかもしれない。AI のモデル学習に役に立つこともあるだろう。ちょっとした学習データであればスナップショットを使ってバージョニングしても良いかもしれない。ここで挙げたのは一例に過ぎない。vSphere の環境で仮想マシンを運用されている方々であれば、今までできなかった痒いトコロに手が届くアイディアが湧いてくるのではないだろうか？ vSAN ESA は vSphere スナップショットの問題を克服した。そこにはこれまで以上に様々な用途の広がっているはずだ。
次回予告
前回・今回で vSAN ESA のスナップショットが以前とどのように改善されたのかを解説した。今回までで vSphere のスナップショットの中だけに閉じた話は終了だ。次回からはこの改善されたスナップショットを利用したバックアップについての話をしていく。これまでの記事同様、実機での検証をまじえた内容の予定だ。現場で提案活動に従事していると vSphere 環境のバックアップについて悩まれている方は多い。そんな現場で vSphere のバックアップ設計・運用をされる方にとって有益な情報になればと願っている。是非、次回もお付き合いいただきたい。
あとがき
今回も長い記事にお付き合いいただき誠にありがとうございました。今回の記事から読まれている方もいらっしゃるかと存じます。改めて自己紹介させていただきます。私は日本ヒューレット・パッカード合同会社で仮想化ソリューションを担当するプリセールス・エンジニアの植田正和と申します。弊社では今回の記事でご紹介した以外にも vSAN ESA についての多数の検証を実施しております。本記事では実測の性能データを扱っていますが、それを保証するものでないため、具体的にはご紹介できない性能データや詳細な構成・設定等もございます。しかしお問い合わせいただければ案内できるものもございます。それらの情報が必要な方は弊社担当営業、もしくはパートナー様にお気軽にお問い合わせいただければ幸いです。vSAN ESA の凄さをもっとご紹介できることを楽しみにしております。
