VMwareからvSphere5.0が発表になりました。2.xから3.xへのバージョンアップは比較的劇的でしたが、3.xから4.xへは比較的シームレスなバージョンアップとなり、今回も同様となりそうです。やはりソフトウェアはバージョン3.xぐらいから成熟するということなのでしょうか(^_^;)。各仕様についてまとめたホワイトペーパーが発表されましたので、そこから情報を掻い摘んで見ていきたいと思います。まずはストレージ関連から。ホワイトペーパーはこちら。
■VMFS5
まずはVMFS5から。3.xから4.xでは継続してVMFS3を使用し、マイナーバージョンアップのみでしたが、今回はバージョンアップに合わせてVMFSもアップデートされました。vSphereに合わせて、VMFSも3.xから5.xへと4を飛ばしてバージョンが上げられています。
主な変更点としては、64TBまでサポートされた単一ボリュームに対するフォーマットサイズと、ブロックサイズの1MB固定化が挙げられます。VMFS5上に作成可能な仮想ディスクファイル(.vmdk)の制限は相変わらず2TBの模様ですが、RDM (Raw Device Mapping)を使用する場合については、2TB以上のサイズの認識ができるようになりました。Microsoft Hyper-Vの次期バージョン(2012年登場見込)では、仮想ディスクファイル(.vhd)の拡張が予定されており(.vhdxファイルとなるようです)、2TB越えがサポートされることになる模様ですので、対してVMwareはどのような対応に出てくるか、今後にも注目です。その場合はRDMを使えば良い、ということもいえるかもしれませんが。
VMFS5はVMFS3からデータを維持したまま、仮想マシンを稼働させたままでのアップグレードが可能となる模様ですが、そこには制約や制限などがないのかについては、今後確認をしていきたいと思います。また、今回はメジャーバージョンアップですが、今後VMFS5としてのマイナーバージョンアップも対応されるのかが気になるところです*1。
■Storage DRS
Storage vMotionに続いて、Storage DRS機能が追加されます。Cluster内において仮想マシンの実行ホスト選定を自動化するDRSに対して、Storage vMotionはStorage Cluster内の仮想マシンの配置選定を自動化します。基準は、データストア容量の使用率とI/O遅延の両面で判断されるようです。
DRSにおける仮想マシン間の配置ルールとなるAfinity Ruleは、Storage vMotionでもあり、仮想ディスク間での配置や、仮想マシン間の配置についてルールを構成することが可能となっています。
■vStorage API / Profile-Driven Stroage
vStorage APIは次第に連携の度合いを強めつつあり、ついに "Storage Awareness" 、ストレージのパフォーマンス状態などに応じた最適化ができるようにしようという段階に入ってきました。つまり仮想環境のパフォーマンスについて、ストレージ側も含めて判断することで、いわゆるSLAの保証をより実用的なものにすることができるようになります。
vStorage APIによってストレージ側のパフォーマンス状態をチェックし、SLAとして定義したサービスレベルを満たしているのかどうかについて仮想マシンごとに適合・不適合を判定します。
■FCoE Software Initiator
FCoEのHardware Adapter、つまりはCNAについてはすでにvSphere4からサポートされていましたが、vSphere5ではiSCSIに続いて、FCoEについてもSoftware Initiatorが実装されます。FCoEですので、iSCSIの場合と違ってどんなNICでもOKというわけではなく、FCoE Offloadに対応したNICを搭載する必要はあります。
■iSCSI Software Initiator
iSCSI Software Initiatorについても、使い勝手が格段によくなります。ポートバインディングやJunbo Frame対応などもすべてvSphere Client経由で構成することが可能となります。つまりは、これらのパラメータについてもHost Profileにおいて対応してもらえるということにもなりますので、助かります(^_^;)。
■vSphere Storage I/O Control
vSphere4.1から登場したStorage I/O Controlですが、vSphere5ではFC/iSCSIのブロックデバイスを用いたVMFSデータストアだけでなく、NFSを用いたデータストアに対しても使用可能となりました。
■vStorage API for Array Integration (VAAI)
Full Copy, Block Zeroing, Hardware-Assisted locking (ATS) などの機能がすでに実装されているVAAIですが、vSphere5ではさらに機能の拡張が行われています。もちろん、ストレージ側の対応が必要となりますが、VAAIが強化されることで仮想化とストレージの連携はさらに強化されていくこととなります。新機能としてはNAS対応などもありますが、ここではシンプロビジョニング連携について。
- vSphere Thin Provisioning
vSphereではVMFSファイルシステムを通じて仮想ディスクファイルを作成しているため、これまでストレージ側ではファイルシステム上でどのようにデータが配置されているのか、把握することはできませんでした。逆に、昨今のストレージの大半はシンプロビジョニングの機能を持っていますが、ESXホスト側はデータストアを構成したボリュームがシンプロビジョニングで構成されているのかどうか、把握することができませんでした。この問題に対して、VMwareとストレージベンダーはVAAIによって対応しようとしています。
1つ目の対応は、データストア上で解放された領域、つまりは仮想マシン構成ファイルが削除された領域や、Storage vMotionなどによって他のデータストアに移動した仮想マシンの構成ファイルが使用していた領域などについて、ストレージ側で対応したブロックを解放できるようにするという仕組みです。これが可能となれば、VMFSデータストアとして使用しているボリュームをシンプロビジョニングで構成していた場合、新しいブロックの割り当てだけではなく、回収までもを行うことができるようになります。これにより、さらにストレージが効率的に使用されるようになることが期待されます。
もう1つの対応が、仮想環境側がストレージ側のシンプロビジョニングボリュームの使用状況を把握する仕組みです。ESXホスト側がストレージ側のシンプロビジョニング状態を把握していない場合において、ストレージ側が新たなブロックをシンプロビジョニングボリュームに割り当てることができなくなった場合、ホスト側からはなぜデータストアへのアクセスができない状態となったのかについて原因を把握することはできません。しかしAPIを通じてストレージ側の状態を把握することができるようになれば、割り当て可能容量が少なくなってきた際に警告を出すこともできますし、万一割り当て可能容量がなくなってしまったとしても、原因不明の書き込みエラーとして扱うのではなく、シンプロビジョニング処理が原因であると判定し、一時的に仮想マシンの状態をポーズさせることでエラーを回避することも可能となります。
■Storage vMotion
Storage DRSが登場したこともあり、Storage vMotionはより重要な技術となります。処理性能の最適化だけではなく、Snapshotが取得された仮想マシンやLinked Cloneの仮想マシンについても対象とすることがサポートされることにより、Storage vMotionはより使い勝手の良い、「使える機能」となりそうです。
処理性能の面としては、Storage vMotionの処理の仕組みが変更され、Mirror Driverを使ったミラーモードという仕組みが導入されます。
ミラーモードにより、仮想マシンからのDisk I/Oと、移行元・移行先の両方に対する複製I/Oの全てが、単一の経路で処理されることとなります。これにより、Storage vMotionによる移行処理はより効率的に処理されるようになり、処理時間についても短縮することが期待されます。Mirror DriverはVMkernelにおいてゲストOSごとに処理を行い、Storage vMotion中のゲストからのI/Oを一元的に処理します。これにより、移行先のデータストアにも書き込んでいくこととなり、移行のために必要となる書き込み処理を最適化することとなります*2。
