ハイパーバイザー、ストレージ周りの担当をしていたm-tuchiです。
今回は、サーバー仮想化製品であるVMwareのvMotion機能とストレージのsnapshot機能の組み合わせにより障害になりかけた事例について紹介します。
弊社環境について
プライベートクラウド環境の構成（記事に関連する部分のみ）
弊社ではデータセンターに設置した物理サーバー上にVMwareを適用して、1,000台以上の仮想マシン（VM）が動作しています。 VMwareを使用する場合の物理構成としては、少し前からはやっているHCI（ハイパーコンバージドインフラ）を使用したり、小さなサーバーを複数台並べてVSAN（VMware Virtual SAN）を構成したりと色々な構成が考えられるのですが、弊社では以下のような物理サーバー＋NFSストレージの構成となっています。
本記事のテーマがディスクのため、ディスクにフォーカスして図を下から上に見る感じで説明します。
- ストレージ上に作成した2つのVolume（のデータ領域）をNFSにてESXiホスト（実際は複数台あります）に提供
- ストレージから提供されたVolumeをESXiホストがデータストアとしてマウント
- データストアをデータストアクラスタとしてグルーピング
- データストアクラスタからvmにディスクを提供
- vmは提供されたディスクをOS領域やデータ領域として使用
という構造になっています。
VMware独自の用語がいくつかあるため、簡単に概要を説明します。
ESXiホスト
VMware ESXiをインストールした物理サーバーのこと。 VMware ESXiは物理サーバーのリソースを分割管理して仮想マシンに提供する。
データストア
VMware ESXiが仮想マシンに切り売りできるディスクのこと。 ESXiホストに搭載されたHDDやSDカードなどもデータストアとして使用可能。
データストアクラスタ
複数のデータストアをグルーピングしたもの。 Storage DRSによってデータストアクラスタ内の各データストアの負荷、使用率を平準化することができる。
Storage DRS
データストアクラスタ内の各データストアの負荷、使用率を平準化する機能。 主な機能は以下。
- 仮想マシンを作るときに空き容量が多いデータストアを自動的に選択
- 低負荷データストアへ仮想マシンを (or 仮想マシンのディスクを) Storage vMotionする
自動でStorage vMotionする「完全自動化」と、移動の推奨を提案する「自動化なし」がある。 なお、弊社環境では「完全自動化」が設定されていた。
Storage vMotion
データストア間で仮想マシンが使用するディスクの移行をする機能。基本仮想マシンのOSを停止することなく移行可能。
ストレージのVolume内の構造
ストレージやバックアップ設計に関わったことのない人には理解しづらい内容ですが、今回肝となるストレージのVolumeの構造（NetApp社のcDotストレージでの構造）についても説明します。
図にある通り、Volume内は3層となっています。 バックアップ領域である"snapshot領域”の役割に注意してください。 変更を漏れなく記録することが役割であるため、データ領域に変更が入れば入るほど膨らんでいく性質を持っています。 なお、設定によってsnapshotを無効化することも可能です。
問題の発生と対処
表面事象の検知
ある日、24時間365日のシステム運用部門からストレージのsnapshot領域が肥大化しているという連絡がありました。 Volumeは容量監視されており、夜のうちにアラートを検知した運用部門が少しずつVolumeを拡張していたのですが、異常に増え続けることからシステム管理部門に原因究明依頼が回ってきたのでした。
原因の究明
肥大化が始まった時間帯を容量グラフで確認し、該当時間のデータストアのイベントログを確認した結果、つい最近動き始めた複数の仮想マシンが何度もStorage vMotionされていることが分かりました。 そこから導き出した構造は以下の通りです。
今度は上から下へ見ていきます。
VMwareレイヤー
- 仮想マシン（"vm 2"）にてディスクI/Oが増加する
- "データストア A"が高負荷となる
- Storage DRSが"データストア A"の高負荷を検知。原因となる仮想マシンを特定
- Storage DRSがStorage vMotionにて、"vm 2"を"データストア A"→"データストア B"に移動する
ストレージレイヤー
- "Volume B"のデータ領域に"vm 2"のデータが生成される
- "Volume B"のsnapshot領域に変更が記録される ⇒ 使用量増加
- "Volume A"のデータ領域から"vm 2"のデータが削除される
- "Volume A"のsnapshot領域に変更が記録される ⇒ 使用量増加
ストレージのsnapshot領域は、データの生成でも削除でも増えることが分かります。
実際は上記のようなStorage vMotionが別の仮想マシンのStorage vMotionを呼ぶという形で、次々と変更差分が積み重なっている状況でした。
対処
Storage vMotionの多発が判明してからは対応は簡単でした。
取れる対応は「Storage vMotionが起こらないようにする」か「snapshotをあきらめる」です。
snapshotはバックアップ機能ですので、機能の優先度から「Storage vMotionが起こらないようにする」を選択しました。
Storage vMotionの管理をしているStorage DRS機能を「自動化なし」モードへと変更し、仮想マシンの移動が収まりました。 これによりsnapshotの増加も止まりました。
振り返り
Storage DRSもストレージのsnapshot機能も単体で見ればよくできた機能で、これまで手動で運用していたものを自動化できるとても便利なものです。
今回の事象は、便利な機能でも組み合わせによっては困ったことになるというものでした。
便利な機能は深く知らずとも使うことはできるのですが、それだと今回のような事象発生時に原因までたどり着くことができません。
弊社システム管理部門では便利機能の中身を理解して使用しているからこそ、対処までスムーズに行けたと考えています（なお、原因特定したのは私ではありません）。
そういった技術の裏付け的なものが気づきを生む。エンジニアとして重要と感じた一件でした。
※ここまで書いていて、Storage vMotionが何度も繰り返される（同じ仮想マシンがデータストアを行ったり来たりする）ことこそが問題の本質な気がしてきました。 次回発生時はStorage DRSの暴走という観点で調査したいと思います。
採用情報
朝日ネットでは新卒採用・キャリア採用を行っております。
