1. イントロダクション
2. vSAN ESA の進化がもたらすもの
2.1. vSAN ESA とは何か
2.2. vSAN ESA がもたらす 5 つの代表的なメリット
3. vSAN ESA ネイティブスナップショット～vSAN ESA で最も大きな意義を持つもの～
4. vSphere が長年抱え続けたスナップショットの課題
5. スナップショットによる性能劣化が起きるのはなぜか？
5.1. vSphere のスナップショットの仕組み
5.2. 書き込みが遅くなるのはなぜか？
5.3. 読み込みも遅くなるのはなぜか？
5.4. 世代数が増えても遅くなるのはなぜか？
5.5. 削除する時まで遅くなってしまうのはなぜか？
6. スナップショットでどこまで遅くなる？最新の実機検証で明らかにする
6.1. 検証環境
6.2. 検証に用いた負荷
6.3. 検証結果と手順【←重要！忙しい人はココだけ】
7. 検証結果のまとめと意義～スナップショットの問題が影響する範囲は広い～
次回予告
あとがき
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 のストレージエコシステムに与えるインパクト
2. vSAN ESA の進化がもたらすもの
2.1. vSAN ESA とは何か
vSAN ESA のスナップショット検証の中身に入っていく前に簡単に vSAN ESA について触れておきたい。vSAN ESA は 2022 年 10 月に vSphere 8.0 と同時にリリースされた vSAN 8.0 から選択できる vSAN の新しいアーキテクチャのことだ。この新しいアーキテクチャのリリースによって vSAN は従来までのアーキテクチャのものと新しいものとの 2 種類で提供されるようになった。アーキテクチャが 2 種類になったのを受け、従来までの vSAN アーキテクチャを OSA (Original Storage Architecture)、vSAN 8.0 から追加された新しいものを ESA (Express Storage Architecture) と呼び分けるようになった。
vSAN が開発されてから現在までの約 10 年間で vSAN は大きな進化を遂げてきたが、その裏で vSAN という SDS (Software Defined Storage) を下支えするハードウェアも進化を遂げた。vSAN ESA はこの 10 年のハードウェア側の進化を最大限活用できるように再構築されたアーキテクチャだ。最新のハードウェア技術を最大限取り込むため、vSAN ESA で構成できるストレージデバイスは NVMe のみであり、vSAN のノード間通信に用いるネットワークは基本的に 25 Gb 以上（一部 10 Gb）となっている。そして、NVMe の恩恵を受けることで従来必要だったキャッシュティアとキャパシティティアの 2 階層の構造は不要となり、シンプル化されたシングルティアアーキテクチャとなった。
2.2. vSAN ESA がもたらす 5 つの代表的なメリット
vSAN ESA が取り込んだ数々のハードウェアの進化や vSAN ESA がどのようなメリットをもたらすのかについては既に VMware によって様々な場所で語られており良質な解説記事も豊富にある。そのためこの記事でそれについては多くは語らず代表的な 5 つのメリットだけを挙げ、詳細については記事の紹介に留めそちらに譲る。
- RAID-1 相当のパフォーマンスで利用できる RAID-5/6
- I/O 処理の CPU 使用率の低減
- ドライブ障害の影響範囲の縮小による耐障害性の向上
- 簡素化されたストレージデバイス・サービスのプロビジョニング
- パフォーマンスの影響を最小化した ESA ネイティブスナップショット
以下2 つの記事が vSAN ESA の概要とメリットの把握に有効だ。英語の記事ではあるがブラウザで日本語翻訳を利用すると自然な訳で読むことができ、お勧めだ。 『An Introduction to the vSAN Express Storage Architecture』 『Announcing vSAN 8』
3. vSAN ESA ネイティブスナップショット～vSAN ESA で最も大きな意義を持つもの～
vSAN ESA は多くのメリットをもたらすことが語られているが、この記事では冒頭で触れた通り vSAN ESA のネイティブスナップショットに焦点を絞って解説していく。というのも、この vSAN ESA ネイティブスナップショットは vSAN の歴史をも超え、vSAN 登場以前の vSphere の歴史を遡って見た上でも大きなインパクトを与える可能性をもつからだ。それにも関わらず、vSAN ESA のネイティブスナップショットに関する実機での検証結果を示した解説は国内外問わず公開されたものはほとんどない。(2024/01/01時点) vSAN ESA ネイティブスナップショットがもつ価値は vSphere 環境において非常に大きいため、要件上の観点から vSAN ESA の採用を見送る結果になったとしても、vSphere 8.0 のアーキテクチャを検討する過程において目を配っておくべきものだと考えている。公開された情報が不足していたために検討事項として登らず、導入後になって vSAN ESA ネイティブスナップショットの効果が明らかになっていくにつれ「導入前にこの情報を知っていれば…」という後悔の声が聞こえてくるような残念な状況は避けたい。 よってこの記事では今後 vSphere 8.0 の導入を検討する方々の検討の一助となるよう、実機での検証結果を示しながら vSAN ESA のスナップショットの実力を探っていく。手前味噌ながら vSphere におけるストレージ、とくにスナップショットやバックアップ運用で長らく悩みを抱えきた方々には有益な情報を提供できると確信している。また vSphere 環境のストレージ運用でまだ課題を抱えたことをない方へも、今後起こり得る課題を明らかにすると同時にその解決策を提示できるだろう。すぐに検証内容を紹介したいところだが、足並みを揃えるためにどのような課題が vSphere に存在し続けていたのかをまずは確認したい。
4. vSphere が長年抱え続けたスナップショットの課題
vSphere が長年抱えてきた課題はスナップショット利用時の性能劣化だ。スナップショットを取得した仮想マシンの仮想ディスクへの I/O 性能が大幅に遅くなってしまうのだ。その性能劣化はスナップショット取得時のみではなくスナップショットを保持し続ける限り継続する。加えて、スナップショットを取得する数(世代数)が多くなればなるほど、それに応じて性能劣化の度合いも大きくなる。 さらにスナップショットは削除時にも性能劣化のペナルティを受ける。削除時はスナップショットの取得・保持によって生じた劣化に上乗せされた追加の劣化を招く。削除による追加の性能劣化は削除処理が完了するまで継続し、その処理時間は削除対象となるスナップショットが取得された以降の累積更新量に依存する。つまり、スナップショットを取得した仮想マシンで書き込みを行えば、その時間と量に応じて削除時のペナルティを受ける期間が長期化する。 スナップショットはある一時点の仮想マシンの状態を保存しておく機能のため、一時点の状態を残した上で何らかの書き込みを伴う変更に備えるために使用する。このためスナップショット取得後に書き込みが行われないことは考えにくい（書き込みを伴う変更をしない仮想マシンに対してはそもそもスナップショットを取る必要がない）。よって、スナップショット取得後の更新が生む削除時のペナルティはその使用目的に照らすと回避できない。 スナップショット自体は仮想マシン運用に柔軟性を生む強力な機能だ。好きなタイミングで仮想マシンの一時点の状態を保存でき、それを好きなタイミングで戻すことができるというのは活用の幅が広く多くのユーザにとって魅力的だろう。魅力的であるが故にこの性能劣化は vSphere 環境での大きな悩の種であり続けてきた。このような背景を受け VMware もスナップショットの斬新的な改善を繰り返してきた。結果、VMware は VMFS / NFS におけるスナップショットの使用についてのベストプラクティスについては
- 優れたパフォーマンスを得るには、2 つか 3 つのスナップショットのみを使用
- 1 つのスナップショットを 72 時間を超えて使用しない
と案内している。 （参考）vSphere 環境でスナップショットを使用するベスト プラクティス (1025279) vSAN OSA においてはインメモリキャッシュの使用が実装されVMFS ベースのスナップショットと比較すると性能劣化の緩和され、保持世代数の制限はないものの、VMFS と同様のスナップショットアーキテクチャであるため、この後の検証結果でも詳細にお伝えするが性能劣化は課題である。
5. スナップショットによる性能劣化が起きるのはなぜか？
ここまで vSphere のスナップショットが抱える課題について論じてきたが、このような性能劣化が起こってしまうのはなぜなのだろうか？ここでは vSphere スナップショットの仕組みに触れ、性能劣化が起こってしまう要因を明確にしたい。明確にすると同時にその要因の影響する境界（どのような状態・構成で起こり得るのか）も明らかにしておきたい。
5.1. vSphere のスナップショットの仕組み
vSphere の仮想マシンはスナップショットを取得てしない時は vmdk という仮想ディスクファイル（vSAN の場合はオブジェクト）に Read / Write を行っている。スナップショットを取得するとこの vmdk は Read Only となり Write が行われないことで静的な状態を維持する。この Read Only の vmdk がスナップショットの実体となる。仮想マシンは稼働を続ける限り書き込み先が必要になるので、スナップショット取得時に元の vmdk とは異なる新たな仮想ディスク（「vSphere のスナップショットの仕組み」図中の vmdk-01）が作成され、仮想マシンは新たに作られたこの仮想ディスク上で稼働する。これが vSphere スナップショットの基本的な仕組みだ（新たに作られた仮想ディスクは、デルタファイルや Redo ログ、子ディスクと呼ばれることもり、もう一方の元の仮想ディスクをベースディスクや親ディスクと呼ぶこともある。そちらの方が馴染み深いかもしれないが、ここではデルタディスク、ベースディスクと呼ぶ）。 
性能の劣化はこのベースディスクとデルタディスクが分かれてしまい、それぞれの関係をメタデータファイルがマッピングすることによって生じる。vSphere でスナップショットを取得した後に、書き込みや読み込みがどのようになされるのかを見てみよう。
5.2. 書き込みが遅くなるのはなぜか？
前述したようにスナップショット取得後、仮想マシンはデルタディスク側で稼働しておりベースディスクは Read Only になっているため、スナップショット取得後の書き込みはすべてデルタディスクに書かれることになる。ただし、以降の読み取りのためにベースディスクのどの部分が更新されたかのマッピング情報もデルタディスクにデータを書くのと同時に記録しておく必要がある。そのためvSphere のスナップショットではベースディスク/デルタディスクとは別にメタデータファイル（オブジェクト）を作成し、そこにマッピング情報を記録する書き込みを行う。このようにスナップショット取得後は仮想ディスクの更新に加えてメタデータを更新する必要が生じ、仮想マシンの裏での書き込み処理が多くなるために性能劣化が生じる。
5.3. 読み込みも遅くなるのはなぜか？
スナップショット取得後の仮想マシンが稼働しているデルタディスクにはスナップショット取得後に書き込まれたデータしか書かれていない。そのためスナップショットを取得後も更新されていないデータはベースディスクから読み込む必要があり参照する必要のあるディスクが増える。また、読み込みたいデータがベースディスクにあるのかデルタディスクにあるのかメタデータを参照し判断した上での読み込みが必要になる。結果、書き込みの場合と同様に裏での読み込み処理がスナップショットがない状態の時より多くなるために性能は劣化する。
5.4. 世代数が増えても遅くなるのはなぜか？
スナップショットは世代数を重ねる度に現在 Read / Write しているディスクを Read Only にし、新たなデルタディスク作成し仮想マシンはその新たなデルタディスクを書き込み先として稼働する。それにともない Read Only になった以前のデルタファイルと新しいデルタファイルをマッピングをする新たなメタデータファイルも作成される。この動きによって、データ読み出し時に必要なデルタディスクとメタデータファイルはスナップショットの世代数が多くなるに従い増え、参照するべきディスクとメタデータが増える。そして仮想ディスクの裏で行われる I/O 処理も比例して多くなる。これがスナップショットの世代が増えるに従い仮想マシンがより遅くなっていくメカニズムだ。
5.5 削除する時まで遅くなってしまうのはなぜか？
最後にスナップショットを削除する処理についても見ておこう。ここではスナップショット取得時点に戻るのではなく、スナップショット取得後、更新を加えた最新の状態を維持した上でスナップショットを削除するケースを考える。おそらく本番稼働の環境で最も利用されるケースだろう。スナップショット削除前の仮想マシンは読み書き可能な領域としてデルタディスクを利用してその上で稼働しており、スナップ取得後も更新されていないデータをベースディスク（あるいはベースディスク +現世代より前のデルタディスク群）から読み込み専用で参照している状態だ。 vSphere でスナップショットを削除する場合は仮想マシンがベースディスクに対して読み書きをする状態に戻すためにデルタディスクを削除することになる。そのためにスナップショット取得後にデルタディスクに書かれたデータをベースディスクにすべて書き戻し、書き戻しが終了した時点で仮想マシンが稼働するディスクをデルタディスクからベースディスクに切り替えるというプロセスを辿る。 ただし、このデルタディスクからベースディスクへの書き戻しの過程に懸念がある。というのも書き戻しの進行中も仮想マシンはデルタディスク上で稼働しており、書き戻し用のデータの読み取り元となるデルタディスクが動的に変化する可能性があるという懸念だ。この懸念に対して vSphere ではスナップショット削除に伴う書き戻し実行のために、更に追加のスナップショットを取得することで対応している。どういうことかと言うと、新たに追加のスナップショットを取得することで書き戻し元のデルタディスクも読み取り専用にし、書き戻し中に発生する書き込みを新たなデルタディスクに逃がすことで、書き戻し元のデルタの静的な状態を確保する。
追加のスナップショットを取得することでスナップショットの世代増加による性能ペナルティを受ける。もちろんベースディスクへの書き戻しも追加の I/O を生むので性能劣化を招く。新たなデルタに書き込みを逃がしながら元のデルタからの書き戻しが完了すると最後に削除用に取得した追加のデルタをベースのディスクに書き戻して削除完了となる。この際、最後の同期に向けた静的な状態を確保するためにベースとデルタ両方へのIOを一時的に停止する必要があり、この同期のタイミングでわずかな時間ではあるが仮想マシンの I/O は停止する（VM Stunと呼ばれる状態）。 ここまで vSphere のスナップショットが抱えた性能劣化という課題とそれが発生する要因について説明してきたが、性能はハードウェアに依存する部分も大きい。そして性能の劣化はそれが許容できるのかできないのかを評価するため、それがどの程度のインパクトであるのかが重要だ。次のセクションでは実機を使ってここまでで語られた課題がどれほどのインパクトを持つのか確認してみよう。
6. スナップショットでどこまで遅くなる？最新の実機検証で明らかにする
まずは従来の方式である vSAN OSA のデータストア上の仮想マシンに高負荷のディスク I/O をかけた状態でスナップショット操作を実施し、その操作が性能にあたえる影響を確認する。
6.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 OSA を構成するするため SSD の 1 つはキャッシュディスク、残り 3 つの SSD はキャパシティディスク
- vSAN OSA 上の仮想マシンのストレージポリシーは RAID-6、圧縮有効、重複排除無効
ハードウェア構成のポイントはすべて NVMe のドライブを用いたオールフラッシュである点だ。これは次回の記事で同一ハードウェアで vSAN ESA に構成し、同一ハードウェアにおける vSAN ESA と vSAN OSA の性能比較をするためである。また、全ドライブが NVMe であることからもわかる通り、この構成は vSAN OSA であったとしてもかなり高いストレージ性能が出るリッチな構成となっている。参考までに vSAN Hardware Quick Reference Guide のリファレンス構成と比較すると、この構成は All NVMe 構成でキャッシュ領域が 1.6 TB であるため完全に合致はしないが vSAN OSA の構成の中では最上位の “AF-8” のカテゴリに該当する構成だ。多くの vSAN はこの構成より I/O 性能が劣る構成であると思われるため、この構成においてでもスナップショットの性能劣化が気になるのあれば vSphere でのスナップショット運用には注意した方が良いだろう。
6.2. 検証に用いた負荷
上記の仮想マシンから vdbench を用い 2 つのデータ領域の vmdk に以下のプロファイルの I/O をかけた。
- BlockSize : 8 KB
- Read : 50 %
- Random : 100 %
- Thereads : 16 per disk ※ 1 つの vmdk あたりにかける I/O の並列度。この検証では vmdk に 16 並列で負荷をかけている。
事前調査の段階で計測したデータでは、この環境に上記のプロファイルで I/O をかけた場合、以下の数値を示す。これは負荷をかけている 2 つの vmdk の値を合計した数値である。 40,226 IOPS ( @ Latency 0.764 msec) この vSAN OSA のデータストアの性能特性を掴んでいただくため参考として Read 比率を 100 % ~ 0 % まで変化させた場合の性能の様子を以下に示す。
6.3. 検証結果と手順
①上記の負荷を 10 分何もしない状態でかける ②約 10 分前後の時間でスナップショットを連続取得する ③取得したスナップショットを保持した状態で 10 分間負荷を継続する ④すべてのスナップショットを一気に削除し 30 分負荷を継続する 全体で 1 時間負荷を継続する検証となっており、この間の性能の変化を時系列で観察したものが以下のグラフである。
①～④の手順実施時の様子を見てみよう。 ①はスナップショットなしで負荷をかけている状態だ。事前検証で確認した 40,226 IOPS に近い性能が発揮できている。ただし、vSAN OSA はキャッシュデバイスを持つアーキテクチャのためキャッシュがホットになるまで本調子の性能には少し届かないようで、37,000 IOPS からじわじわ性能が上がっていく様子を見せている（本検証では負荷をかける前にキャッシュデバイス上のデータは一度ドロップしている）。 ②の期間でスナップショットを取得している。この約 10 分間にスナップショットは 3 つ取得できている。1 つ目のスナップショット取得直後から性能は大きく劣化し IOPS は 25,000 IOPSまで落ち、1 msec 以内だったレイテンシも 1.3 msec 程度に伸びている。負荷をかけた状態でファイルシステムの静止点を確保するオプション付きでスナップショットを取得しているため 1 つのスナップショットの取得完了にも時間がかかる。この検証では 1 つめのスナップショットの取得には 3 分ちょっとの時間がかかっている。
同様に 2 つ目、3 つ目とスナップショットを取得していくが、これらも取得に同程度の時間がかかるので 10 分の間に取得できるのは 3 つが限界だった。スナップショットの仕組みを反映して世代を重ねていくごとに仮想マシンの性能は劣化していく。3 つめのスナップショットの取得を開始した時点で 20,000 IOPS を下回りはじめ、スナップショット取得前の 37,000 IOPS と比較すると 60% 程度の性能になってしまっている。 ③スナップショット 3 世代を取得した後の 10 分間負荷をかけ続けると約 19,500 IOPS 近辺で性能は落ち着く。 ④3 つのスナップショットを同時にすべて削除して性能変化を見るフェーズ。デルタディスクの削除用に追加でスナップショット取得し、かつ、バックグラウンドでデルタディスクからベースディスクへのデータの書き戻しが発生するために更に性能が劣化する。今回のケースでは 15,000 IOPS まで落ち込みスナップショット取得前の状態の半分以下にまでなってしまった。また、デルタディスクの書き戻し処理にも時間を要し、すべてのスナップショットの削除が完了するまでに 17 分弱の時間を要した。この 17 分弱の間、大幅な性能劣化の時間は継続した。スナップショットの削除が完了した後は性能は通常の状態に復帰した。
7. 検証結果のまとめと意義～スナップショットの問題が影響する範囲は広い～
この記事では vSphere スナップショット課題を取り上げ、それが様々な面で性能劣化を招くものであることを指摘した。そしてその性能劣化の要因をスナップショットの仕組みの観点から解説した。加えてその仕組みが抱える性能劣化が最新のハードウェアを用いた場合でも発生することを検証を通じて実証した。仕組みの通り、スナップショットを取得することで性能劣化は起き、世代を重ねることで劣化の度合いは大きくなった。さらにスナップショット削除時には追加で性能劣化が起き、それは削除処理が完了するまで継続することが確認できた。ところで、この検証結果の意味するところは何か、その影響範囲について考えてみたい。 性能劣化は vSphere のスナップショットの仕組みに起因するものだ。そのため（vSAN ESA 登場以前は）vSphere のスナップショットを利用する限りどのようなストレージをデータストアにしても発生する可能性がある。All NVMe の外部接続ハイエンドストレージを選択したとしてもそれは例外ではない。むしろ、ハイエンドの 3 Tier で検証した場合の方が今回より劣化の度合いはより大きかったかもしれない。 というのも、VMware もこの課題は認識しており vSphereのスナップショットに漸進的な改善を加え続けてきた。結果、vSAN OSA の利用しているスナップショットのみ少し進化しており、vSAN OSA 以外の外部ストレージや SDS をデータストアとした場合よりスナップショットによる劣化が穏やかになっているためだ。 詳細は VMware から記事が出ているのでそちらに譲るが、穏やかになる理由のポイントだけ指摘するとベースディスクとデルタディスクを結ぶメタデータが vSAN OSA ではメモリ上に一部キャッシュされるようになっているためだ。繰り返しになるが、今回の vSAN OSA の結果は決してワーストなケースではない。よって、vSAN OSA 以外のストレージを使う場合はスナップショットの利用にはより注意が必要だと考えられる。
次回予告
今回は vSAN ESA のネイティブスナップショットが持つ大きな意義を解説する前の課題共有として vSphere のスナップショットの問題を取り上げた。vSAN ESA じゃない方のスナップショットの話が長くなったが本連載のメインは vSAN ESA だ。次回はいよいよ vSAN ESA ネイティブスナップショットの実力を披露したい。今回と同じ実機で vSAN OSA 部分のみをESA に組み替えて検証を行ったので両者の違いを高い精度でご確認いただけるだろう。 次回記事はこちら。
あとがき
長い記事にお付き合いいただき誠にありがとうございました。ご紹介が遅れましたが、私は日本ヒューレット・パッカード合同会社で仮想化ソリューションを担当するプリセールス・エンジニアの植田正和と申します。弊社では今回の記事でご紹介した以外にも vSAN ESA についての多数の検証を実施しております。本記事では実測の性能データを扱っていますが、それを保証するものでないため、具体的にはご紹介できない性能データや詳細な構成・設定等もございます。しかしお問い合わせいただければ案内できるものもございます。それらの情報が必要な方は弊社担当営業、もしくはパートナー様にお気軽にお問い合わせいただければ幸いです。個人的にvSAN ESA はとても好きな製品です。喜んでご紹介させていただきたいと考えています。
