VMware Virtual SAN 6.0の新機能

Virtual SANは、2014年3月11日にリリースされたvSphere5.5 Update1で追加された新機能です。VMwareの目指す「Software-Defined-Datacenter」の1つの柱としてVirtual SAN 5.5をグローバルで提供を開始しました。翌年の2015年3月13日には、vSphere6の提供開始と共にVirtual SAN 6.0がグローバルで提供開始となりました。ここではVirtual SAN 5.5と6.0でのアーキテクチャの違いや新機能について紹介します。

1．VMware Virtual SANとは？

ここではVirtual SANの復習を兼ねて、Virtual SANの概要やコンセプトについて簡単に紹介します。より詳細なVirtual SANのアーキテクチャについては前回の記事をご参考ください。

Virtual SANは、ESXiホストが持つ内蔵ディスクをスケールアウト型のハイブリッドストレージとして動作させることができます。従来は仮想マシンをvSphere HAなどで保護する場合、共有ストレージを用意することが一般的でした。しかし、Virtual SANではサーバ内蔵のHDDとSSDを組み合わせることで、仮想的な共有ストレージを実現することが可能です。ESXiホストを追加することで、ストレージの容量とパフォーマンスが向上するため、環境に応じて柔軟にすることが可能です。また、CPU、メモリのみを追加したい場合には、ディスクレスのESXiホストをVirtual SANの構成されたクラスタに追加するだけで、簡単にリソースの追加を実現することができます。必要なリソースを必要な分だけ追加することができる、柔軟な仮想基盤を実現できるという特徴を持っています。

Virtual SANではボリューム単位でストレージの設定を行う必要はなく、仮想マシン単位でストレージのポリシーを設定します。ストレージポリシーは、仮想マシンの冗長化、データの配置方法、データの保存領域の予約など、全部で5つの項目から定義することが可能です。仮想マシン単位でストレージポリシーを設定することで、仮想マシン1台1台を意識したストレージの管理ができるため、従来までの物理共有ストレージよりも柔軟に運用管理することができます。従来のVirtual SANでは、仮想デスクトップ環境、Tier2やTier3といったテスト環境、プライベートクラウド環境、災害対策サイト環境での利用が主な用途として想定されており、本番環境での利用は想定されていませんでした。しかしVirtual SAN 6.0では、アーキテクチャや新機能の追加に伴い、性能や管理性が向上し、物理共有ストレージと同様に本番環境でも扱えるまでに成熟したと発表されています。以下では、従来のVirtual SAN 5.5と比較し、性能と管理性の2つの観点でどのように進化したか見ていきましょう。

2．パフォーマンスの向上

Virtual SANのアーキテクチャの刷新

Virtual SAN 5.5はVMFS-Lと呼ばれる、従来のVMFSに手を加えたファイルシステムが採用されています。このファイルシステムは、Virtual SAN用に改良されたものではありましたが、完全にVirtual SANに特化したファイルシステムではありません。このため、仮想マシンのクローン作成に時間がかかり、仮想マシンのスナップショットを取得すると、仮想マシンのパフォーマンスが著しく低下するなどの弊害がありました。Virtual SAN 6.0では、ファイルシステムの改良が施され、VSAN FSと呼ばれるVirtual SAN専用のファイルシステムを取り込みました。ファイルシステムの変更により、仮想マシンにスナップショットを32階層取得しても、パフォーマンス低下はおよそ2%以内に抑えることができます。

図1：スナップショットのパフォーマンス劣化グラフ（クリックで拡大）

スケーラビリティの拡張

Virtual SAN 5.5と6.0では、スケーラビリティの拡大とパフォーマンスの改善が行われました。スケーラビリティの拡大ではVirtual SANクラスタのESXiホスト数の増加や仮想ディスクのサイズが大幅に向上しました。

Virtual SAN スケーラビリティの拡大

Virtual SAN 6.0では、本番環境を視野に入れた設計がされていることもあり、仮想ディスクの最大サイズが物理ストレージでvSphereを構成する際の制限と同様となりました。

オールフラッシュのサポート

Virtual SANでは、HDDとSSDをサーバに搭載するスケールアウト型のハイブリッドストレージと紹介しました。つまり、Virtual SANを構成するにあたりHDDとSSDの2種類が必須でした。しかし、より高いパフォーマンスが要求されるシステムでは、ハイブリッドストレージのVirtual SANには不向きだったため、今回のバージョンアップでは、Virtual SAN 6.0ではサーバに内蔵するHDDをすべてSSDにするオールフラッシュ構成のサポートを新たに追加しました。

ハイブリッド型では、1つのキャッシュ用のSSDと複数のデータ永続保存用のHDDを組み合わせたものをディスクグループとして定義されます。この場合、SSDの領域は読み込みキャッシュ：書き込みキャッシュ＝7：3として利用します。仮想マシンからの書き込みは、一度、キャッシュ用のSSDで受け止め、その後、データ永続保存用のHDDにデータは保存されます。読み込みは、読み込むデータがキャッシュ用のSSDにあるようであればSSDから読み込み、そうでなければデータ永続保存用のHDDから読み込み、新たにSSDにキャッシュされます。

Virtual SAN 6.0のオールフラッシュ構成では、キャッシュ用のSSDとデータの永続保存用のSSDの2種類のフラッシュデバイスで構成されます。SSDはHDDと比べ非常に高速であるため、キャッシュ用のSSDは読み込みのキャッシュは持たず、データの永続保存用のSSDから直接データを読み込みます。書き込みキャッシュはディスクグループのキャッシュ用SSD 1つをまるごと利用して、書き込みキャッシュ用のSSDにデータを格納後、データ永続保存用のSSDにデータを格納します。

図2：ハイブリッド型とオールフラッシュ型の読み込み/書き込み動作（クリックで拡大）

読み込みキャッシュ領域を確保する必要がなくなったため、高価なキャッシュ用のSSDを有効利用することが出来るため、よりコストパフォーマンスに優れた構成を実現できます。

3．管理性の向上

フォルトドメインを意識したデータの保護

仮想マシンを障害から保護するには、ストレージポリシーの「許容される障害数」を適切な数値に設定の上、ポリシーを仮想マシンに反映させる必要があります。ストレージポリシーによって保存されるデータは、ESXiホスト単位で分散されて配置されるため、物理のラックや電源、スイッチなどの構成まで考慮することは想定されていませんでした。

図3：従来のデータ配置（クリックで拡大）

そこでVirtual SAN 6.0では、フォルトドメインと呼ばれる抽象的なグループを定義することで、これを回避することができます。

図4：フォルトドメインを使ったデータの配置（クリックで拡大）

フォルトドメインは、抽象的なグループをユーザがサービスレベルに応じて定義し、Virtual SANは、フォルトドメインを意識してデータを配置します。こうすることで、「サーバラックを跨いで配置したい」、「ブレードシャーシ内で配置したい」、「ブレードシャーシを跨いで配置したい」といった、柔軟な構成を実現できるようになっています。

vSphere Web Clientへの再同期ステータスの統合

サーバに搭載したHDDやSSDに障害が発生すると、Virtual SANはその障害内容に応じて自動的に再同期（修復）を実施します。旧バージョンでは、その再同期処理が実行されているか、またどの程度まで再同期がされているかを確認するには、RVCと呼ばれるvCenter Serverのコマンドを実行し確認する必要がありました。Virtual SAN 6.0では、再同期処理のステータスがvSphere Web Clientに統合され、GUIから確認することができます。

図5：vSphere Web Clientに統合された再同期ステータス（クリックで拡大）

HDD単位のデータの退避と削除

HDDの予防交換や他用途への転用をする場合、今まではESXiホストが持つすべてのデータを別のESXiホストに移動する、または強制的にHDDを引き抜き、意図的に障害を発生させてVirtual SANの自動復旧を待つ必要がありました。Virtual SAN 6.0では、特定のHDDに保存されているデータのみを退避するよう指定可能となりました。

図6：特定のHDDのデータだけを移動（クリックで拡大）

これにより、大量にデータを移動させることなく、安全にディスクグループからHDDを取り外すことができるようになりました。

HDDの管理

Virtual SANでは、以下の2通りのHDDの接続をサポートしています。

1. RAIDコントローラーを利用してHDDをすべてRaid0で利用する。
2. RAID機能を持たないSAS/SATA HBAを利用して、すべてのHDDをパススルーで利用する。

1つめのパターンでは、RAIDコントローラーがHDDを管理しているためディスクのステータスを監視することが可能です。2つめのパターンではRAIDコントローラーがHDDを管理していないため、サーバが直接HDDを利用します。このため、HDDが障害等で故障した場合、HDDが故障した事実は判明しますが、HDDの障害を検知するLEDが発光せず、どのHDDを交換すべきか、管理者はサーバを目の前にして立ち尽くすことになるかもしれません。

Virtual SAN 6.0では、HDDをパススルーで利用している場合、vSphere Web Clientから該当のHDDのLEDを発光させることが可能となりました。

図7：vSphere Web ClientからHDDのLEDを発光（クリックで拡大）

データの再配置

Virtual SANを構成しているクラスタに、新しいESXiホストを追加することで、VSANデータストアは自動的に拡張するスケールアウト構成が可能です。ところがこれまでの仕様では、新たにESXiホストを追加しても、データの再配置はVirtual SANデータストアの利用率が80%を超えているときにのみ実行されていました。

Virtual SAN 6.0では、Virtual SANデータストアの利用率にかかわらず、ESXiホストを追加するとデータの再配置を実施します。再配置は負荷の低い時間帯等に実施するなど、任意の時間帯を指定して実行することができます。

このように、Virtual SAN 6.0ではスケーラビリティ、パフォーマンス、管理の柔軟性が大きく向上していることがお分かりいただけたかと思います。今回のVirtual SAN 6.0 の登場によって、VMwareの目指す「Software-Defined-Datacenter」が完成に近づいてきていると実感することができるでしょう。