前回の記事ではSoftware-Defined StorageとVVOLの位置づけについて解説しました。
つまりVVOLは｢Sotware-Defined Storage｣を実現しようとしながら、同時に｢ストレージオフロード｣を実現しようとしているということです。前回は後者のストレージオフロードが悩みの種でありそれはストレージのアーキテクチャへも影響を与える可能性があるからというところまで解説しました。
今回は従来のストレージやファイルストレージを簡単に紐解きながら、なぜそれが難しいのか見ていきます。
技術的に正確であることよりも、わかりやすいことを優先しているのと、各社がVVOL実装のために様々な努力を重ねていますのですべてが以下のままということはありません。一般論として見ていただければ幸いです。
LUNとVMFSのギャップを埋める必要がある
ストレージは歴史的にブロックデバイスです。ファイルと言う単位を管理しているのはストレージではなく、ファイルシステムという(通常は)OS側の機能が管理しています。ファイルストレージという言葉もありますが、これはストレージOSがファイルとしてブロックを解析して別のOSへTCPなどで配布を行う形態をとっているからであり、ファイルストレージの実態も中身をよく見てみると実はブロックデバイスなのです。
ブロックは単なるデータの羅列です。このままではデータを取り扱いにくかったり、直感的にわかりにくかったり、障害ドメインを組みにくかったりなどがあったため、生み出されてきたのがLUNという単位です。ストレージを利用者の都合ではなく、ストレージデバイスの都合で適当に割ったものになります。
LUNはまだ単なるブロックです。このLUNを今度はファイルシステムでフォーマットすることになります。ここからはOSの領分です。VMwareの場合、VMFSというファイルシステムを利用します。ファイルシステムでフォーマットすることで、初めてファイルという概念が利用できるようになります。VMwareの場合、いろいろなメタデータも一緒に保持されますが、基本的に仮想マシンはVMDKというファイルとしてファイルシステム内に管理されています。
まとめると上の図のようになりますが、ここで問題が明らかになります。ストレージコントローラーはLUNしか理解ができないのですが、VMDKはファイルとしてVMFSというファイルシステム以下に管理されています。LUNとVMFSの両方を理解できるESXiからはすべてが見えていますが、ストレージコントローラーからはLUNしか見えていないため、ESXiからVMDKについて何か仕事をしてほしいと頼まれても(オフロード)、何をしていいのかわからないわけです。
1つ1つのVMDKファイルが1つのLUNに1つづつ入っていれば問題ないのですが、LUNの数にはストレージごと上限が決められており、破綻してしまいます。また、LUNはファイルと違って頻繁にサイズを変更するような運用を想定している技術ではないので、VMDKのサイズがどんどん大きくなってくる要な場合には、これまた破綻してしまいます。
このギャップを埋めようとしているのがVVOLです。
ファイルストレージなら簡単なのか?
ファイルストレージならVMDKというファイルが見えるので問題が解決するのでは?というご意見もあるでしょう。ESXiはNFSもサポートしているためNFSストレージを例に取ります。
あれ?と思った方もいらっしゃるかもしれませんが、(通常の)ファイルストレージもハードウェア的には一切変わりません。ストレージOSが仲介に入っているだけで、根本的にはブロックストレージと変わらないのです。単なるブロックストレージとの違いでいうと、ストレージOSがVMDKファイルを理解しているため、VVOLを実装するのはブロックストレージ上に実装するよりは比較的簡単といえるかもしれませんが、ストレージOSのファイルシステムの機能を拡張して行く必要があります。さらにレプリケーションや重複排除などの既存の機能を残しながらの実装になるため別の懸案も増えるのではないかと思います。例えばノンインラインで実装された重複排除を有するストレージは重複排除をバックエンドで実行中に、ユーザーからレプリケーションをリクエストされるなどが生じた場合にどう処理すべきなのか?などでしょうか。この場合、ファイルストレージであってもLUN単位で処理を実装している場合(LUNを超えてブロックの重複を排除しないような実装)があるため、問題はブロックストレージでの実装よりも複雑になる可能性があります。
結局のところ
ブロックストレージは管理の最小の単位がLUNですので、ファイルであるVMDKを直接取り扱うVVOLの実装を難しくしています。また、ファイルストレージの場合はVMDKをファイルとして理解してはいるのですが、既存のファイル機能を残しながら、VVOLの互換機能を新たに実装していくという作業を残しています。いずれにしろVVOLに足並みをそろえるというのは既存のストレージの実装からハードウェア的にもソフトウェア的にも大きく踏み出す必要があり、VVOLの登場から数年が立っているにもかかわらずVVOL完全互換を謳う製品が出てこない理由かもしれません。
では、次回いよいよVVOL自身を見ていきます。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
