先の記事ではブロックストレージとファイルストレージの両方についてVVOLの実装を難しくするそれぞれの原因があるという話を述べてきました。
その理由は「ストレージオフロード」であり、ブロックストレージからは仮想マシンの実体であるVMDKを理解できないこと、VMDKを理解しているファイルストレージであっても、アーキテクチャ的にブロックストレージのアーキテクチャを引きずっていることや、既存のファイルサービスとの互換性の実現などに難しさがあることを述べてきました。
今回はいよいよVVOLについて解説していきたいと思います。
VVOLとは?SPBM(Storage Policy-Based Management)とは?
VVOLはSoftware-Defined Storage + ストレージオフロードの2つを実現しようとしているもの、という話は先の記事でも解説しています。まずはSoftware-Defined Storageを実現するという部分について、解説しています。
VVOLを利用している場合、仮想マシンが利用するストレージの属性は仮想マシンを作成する際に決定されます。ただし、毎度毎度ストレージの属性を設定するのは骨が折れますので、ストレージの属性のテンプレートを用意することになります。このポリシーをストレージポリシーと呼びます。最初の記事で述べた回転寿司のお皿のことですね。うにとイクラは同じお皿に乗せて出す、というような事さえ決めておけば、あとはお皿の値段(属性)をメニューに乗せておけばよいわけです。
ESXiはVVOLを通してストレージポリシーに従った属性のストレージを仮想マシンに対して提供します。
上はこれを図示したものになりますが、SAN/NASに対してストレージポリシーを提供する部分がVVOLで実装されています。となりにx86サーバという記載がありこちらは皆さんがすでによくご存知のVSANです。つまり、VVOLを使うと、VSANと同じことがSAN/NASでできるようになるのです。
VSANのストレージポリシー
VSANで利用可能なストレージの属性パラメーターは以下の5つです。
VVOLを利用すると外部ストレージでもこのようなストレージポリシーを利用できるようになります。むしろVSANはVVOLを最初に実装した製品で、たまたま外部ストレージではなく内蔵ストレージを利用しているという風に考えるほうが良いかもしれません。
VVOLのストレージポリシー
VVOLで指定できるストレージポリシーについてはストレージベンダーごとに異なります。これについてはVASA経由でESXiに対して通知されてるようになっているため、ユーザー側で指定するわけではなく、VVOL対応のデータストア(LUNに変わるもの)をマウントした際に決まります。(ユーザー側でストレージができない属性を指定するような間違いが起こることはありません)
VVOLでできること
結局のところ、VASA経由で通知されてくるストレージの属性の幅に縛られてしまうため、VVOLができたらストレージはどれを選んでも一緒ということはありませんが、VVOL対応のストレージを利用することでできるようになることを以下に列挙します。
ポリシーの生成と適応
サービスの自動化
- ポリシーに基づくストレージ内の初期配置の決定、およびポリシーコンプライアンスの維持
- 動的なサービス提供(ポリシーの動的な変更)
外部ストレージへの仮想マシンの露出
共通の管理プレーン
- 仮想マシンのライフサイクル全体(作成、監視、変更)にわたってハードウェアから完全に独立した管理プレーンからポリシーベースに管理が可能
クラウド自動化のAPIを統合
- vCloud Automation Center、OpenStack、PowerShellなどとの統合でセルフサービスの展開において、ストレージサービスの適応を自動化できる
何を気をつけるべきなのか?
今回は3回にわたってVVOLについて解説してきましたが、今回述べたようにVVOLはストレージのクラウド対応・自動化のために用意されたAPIです。VVOLの登場によってストレージの利用の仕方はポリシーベースになり、クラウド、仮想マシンを利用するという意味においては非常に簡単、かつ、柔軟性が許されたものになります。Tier-1、Tier-2、Tier-3など仮想マシンの属性を分け、それぞれに違う属性のストレージを用意するのではなく、単一のストレージで効率よくそれぞれの仮想マシンにストレージサービスを提供することができるようになってくるため、ストレージのコストを抑えながら、多様な仮想マシンに柔軟に対応することも可能になってきます。
唯一難しくなってくるポイントはどのVVOL対応ストレージを選ぶか?という点でしょう。VVOLの登場の前後から様々なストレージソリューションが生まれて、またレガシーなベンダーもしのぎを削っています。
製品を購入する立場、製品を提案する立場においてはVVOLは特定のベンダーの味方をするために作られたAPIではないということをよく理解しておいてください。逆にVVOLは第2回めの記事に述べてきたように各ストレージベンダーに非常に難しい実装やアーキテクチャの変革を求めています。安易な製品選定やベンダー側のVVOL対応の実装の甘さが問題を引き起こすことになるケースも増えてくる可能性をはらんでいます。VVOLという非常に優れた互換レイヤーの裏で何が起こっているのか?(各ベンダーがVVOLをどう実装しているのか?)をよく理解した上で最適なストレージを選択する時代がもうそこまで来ています!
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)