VVOLがやってきた。さあ、準備はOK?(前編)
Storage Magazine 2015年4月号より
VVOLによって、ストレージ製品は大きな変化を求められている。
しかし、多くのITの現場は移行に苦労するかもしれない
「VVOLがやってくる」というフレーズは、VMwareがVMworldのテクニカル・セッションにおいてそのコンセプトを2011年8月に最初に発表して以来、ずーっと繰り返されてきた。4年の時を経て、VMware Partner Exchange 2015において、VMwareはついに、vSphere 6 およびvSphere APIs for Storage Awareness (VASA) 2.0と同時にVirtual Volumes (VVOLs)の一般販売が開始されたことを公表した。これと同時に、多数のベンダーが特定の製品におけるVVOLサポートを公表した。さて、VMware社のVVOLとは何だろう?この技術はどのように動き、ユーザーにどんなメリットをもたらすのか?
簡単に言うとVVOLとは、VVOLに対応しているストレージアレイにおいて、仮想マシン(VM)レベルの粒度で、アプリケーション・ストレージの割り当て、監視、管理を行えるようにする技術である。VMwareがコンピューターの世界にやってくる以前、アプリケーションはストレージアレイから割り当てられたLUNまたはボリュームとの一対一の関係を享受していた。パフォーマンス、容量、データサービス(圧縮、キャッシング、シン・プロビジョニング、スナップショット、クローニング、レプリケーション、重複排除、暗号化、等々)が、LUN用に正確に、ただし静的に定義されていた。物理サーバー上で稼動するアプリケーションは、そのLUNで使える全てのサービスにアクセスすることができた。VMwareがハイパーバイザで計算機能を抽象化したことにより、ユーザーは1台の物理サーバー上で、複数のアプリをVMの形態で動かせるようになった。
だが、ストレージは基本的に元のままで残った。VMwareがVMと話しているとき、ストレージは依然としてLUNやボリュームと話をしていた。この不一致は結果として10年間の混乱をもたらした。VMwareとストレージが調和的に動く唯一の方法は、ひとつのLUNにかなり多くのVMをサポートさせることだけだった。アプリケーションのパフォーマンスが低下した時、正確な原因を見つける方法は存在しなかった。ストレージ・パフォーマンスのデータは、LUNレベルでしか見られなかったからだ。全く不可能ではないにせよ、VMから見えるものだけでは問題の切り分けと対処が極めて難しかった。
VVOLはどのように動くのか?
VVOLは、ストレージとVM間のアーキテクチャー上の不一致を無くすことにより、この問題を根本的に解決すべく設計されたものだ。この技術によって、VMに対しポリシーに基づいた正確なストレージリソースの割り当てができるようになった。ここで言うリソースには多くの場合、ストレージのタイプ、全容量、空き容量、および重複排除、スナップショット、レプリケーション、等々のサービスが含まれる。また、これらのリソースは、アプリケーションの要件が変わったとき、即座に変更可能だ。VMware VVOLの入出力を完全に把握するには、以下にまとめたVVOLのコンセプトを理解することが重要になる。
ストレージコンテナと仮想データストア
NASやSANストレージは最初にいくつかのストレージコンテナに分けられる。ひとつひとつのコンテナが、異なる容量と機能(サービス・クラス)を持っている。ストレージコンテナは論理的構造体であり、通常はストレージ管理者によって作成される。これらのコンテナは、vSphereにたいして仮想データストアとして渡されるため、vSphere側では何も変更する必要が無い。VVOLはストレージコンテナの中に常駐する。時として仮想ディスクとも呼ばれるVVOLは、下層の物理ストレージ表現(LUN、ファイルシステム、オブジェクト)から独立した新しい仮想ディスクコンテナを定義する。違う言い方をすると、接続する物理ストレージのタイプ(DAS以外)に関わらず、ストレージはVVOLの抽象化されたフォーマットでvSphereに渡される、ということだ。これはVMに対して割り当てられる最小単位のストレージリソースである(コラム「VMを解剖する」を参照)。これはまた、ストレージアレイを管理する上でも最小の測定単位である。このことが意味するのは、リソースはVMレベルで供給され、全ての監視や管理もVMレベルでできる、ということだ。
ストレージポリシー・ベースの管理とポリシー駆動型コントロールプレーン
ポリシー駆動型コントロールプレーンは、アプリケーションとストレージ基盤の橋渡しを行う。このプレーンは、ポリシーに適合した能力を持ったストレージコンテナをVMにマッピングする役割を担っている。このソフトウェア定義のストレージモデルにおいて、VM管理者は、各VMに個別に適用できるポリシー・セットを定義するのに、vSphereのストレージポリシー・ベース管理:Storage Policy-Based Management (SPBM)インターフェースを使用する。これらのポリシーは、ストレージアレイから提供されるリソースのタイプを定義する。例えば、プラチナ・ポリシーで、半導体ストレージリソースおよびそのストレージアレイが提供する最高クラスのデータ保護、容量最適化、DR機能を使用するとすれば、ゴールドポリシーではそれ以下のリソースを使うことになる。
VVOLとVMは、SPBMを使ったポリシーに応じて自動的に紐付けられ管理されるため、VMware基盤はコストを増やさずに、数千あるいは数万のVMにまで拡張可能だ。VMがLUNと紐付いているときにアップグレードやダウングレードがどれだけ大変か、これと比べて頂きたい。
VMに適切なストレージサービスを割り付ける仕事のほかに、コントロールプレーンはVMがポリシーによって割り当てられたリソースを引き続き取得しているかを確認するために、常時これらのVMの監視を行う役割も持っている。
仮想データプレーン
仮想データプレーンは、1台のアレイ上で利用可能な全てのストレージサービスを抽象化しているため、これらのサービスは個々のVMに供給することも(しないことも)可能だ。これまでは、所与のLUNに常駐しているVMはそのLUNで利用可能な機能やサービスは全て供給されていた。例えば、他のサイトにレプリケートする必要のないVMでもLUNはそのサービス付きで設定されていた。
これらの抽象化されたサービスは、コントロールパネルからVMでの使用を設定できるようになっている。これらのリソースは、外部のストレージアレイから来るだけとは限らない。仮想SAN(VSAN)から来るかも知れないし、vSphere本体から、あるいはサードパーティー製品から来るかも知れない。コントロールプレーンは、所与のVMに対し、そのVMに関連するポリシーに基づいて、どのサービスを使えるようにするかを決める。VVOLは外部ストレージアレイ用仮想データプレーンのVMwareによる実装であり、VSANはx86ハイパーコンバージド・ストレージを供給するものである。
(後編に続く)
著者略歴:Arun Taneja はストレージおよびストレージ・セントリック技術に特化したアナリストとコンサルタント集団Tanejaグループの創設者兼社長。
Copyright 2000 - 2015, TechTarget. All Rights Reserved,
*この翻訳記事の翻訳著作権はJDSFが所有しています。
このページに掲載されている記事・写真・図表などの無断転載を禁じます。