いよいよリリース! VSAN 6.2 すべてはErasure Coding!! 細かな機能も抑えておこう

この記事は前々回、前回につづき新しいVSAN 6.2についての記事です。是非こちらの記事もお読みください。

いよいよVSAN 6.2がリリースされています。詳しくはこちらの桂島様の記事でカバーされていますので、是非ご覧になってください。

ご紹介している｢Erasure Coding｣、大注目の｢インライン重複排除&圧縮｣についてはAll flash構成のみでサポートされます。桂島様の記事によると重複排除&圧縮で2～7倍の容量効率、Erasure Codingを併用する10倍までの容量効率を実現できるとのことです!

また、EMC/VCE社からはVSPEX BLUEの後継に当たるVxRailも発表されています。VSAN Ready Node程細かく指定はできませんが、選べる構成の幅が大きく広がり、さらに｢4ノード縛りにこだわらない｣という発言も飛び出しているようです(ネタ元)ので、EVO:Railの画一的な構成ではなく、今後幅広く利用していくことが可能になっています。

リリースされたErasure Codingの実装について(前回の記事の訂正を含む)

先日の記事ではリリース前の情報から推測しての記載でしたのであたかもパリティデータを専門で担当するノードがあるような図になっていましたが、実際の実装ではパリティも各ノードに分散して保持されます。

※ 図については桂島様の記事よりお借りしてきました。

また、サポートされるのはRAID-5およびRAID-6のみで、それぞれの最小要件はRAID-5は4ノード(3+1)から、RAID-6は6ノード(4+2)からとなります。つまり、VxRailのような4ノードのアプライアンスでもRAID-5が利用できるため、VDIなどのある程度キャパシティの必要な構成も対応が可能です。(クドいかもしれませんが、RAID-5を含むErasure Codingはオールフラッシュ構成のみでサポートされます)

QoS

ストレージポリシー内で各VMDKあたりのIOPSの上限値を設定できるようになりました。ストレージポリシー内で設定できるということはオンデマンドで(VMの再起動などなく)これを変更出来るということです。過度にオーバープロビジョニングするような構成は想定されていない(コスト高になりますから･･･)ので最低値の設定はありませんが、業務に不必要なVMがノードのI/Oを食い潰すようなことを防ぐことができますので、ビジネスクリティカルアプリケーションの動作について、より安心が出来るようになっています。IOPSでの指定ですので、ブロックサイズも見なくてはなりませんが、非常に強力な機能です。(今回の記事内で唯一Erasure Codingと直接関係しません。)

※ 上の画像はVMwareのCTOオフィスのDuncan Epping氏のブログからお借りしました。

インメモリ･リードキャッシュ

容量効率やQoSの影に隠れていますが、個人的には非常に重要と思う機能がこちらです。VSANはノード間でデータを分散します。VMのReadリクエストに対する応答は｢データを持っているもっとも遅いノードを待たなければならない｣ことになります。

前回の記事はWriteのトラフィックだけを解説しましたが、Readのトラフィックも同様にネットワークを何度も流れることになります。特にRAID5/6の構成の場合、｢たまたまローカルのノードにデータが有った｣ということもありえませんので、ローカルのノードにリードキャッシュを保持するということはパフォーマンスの観点からもネットワークの観点からも非常に重要な機能です。

※ 図の統一のためにErasure Codingもハイブリッド構成のようにしてありますが、All Flashのみで対応です

Duncanさんの記事によるとこのリードキャッシュは非常に小さいもので、各ホストの物理メモリの0.4%または最大でも1GBとのことですが、上で解説したとおり、Readのためのネットワークトラフィックを削減するため、およびネットワークトラフィックによるレイテンシの低下を防ぐためには非常に重要な機能です。

気がついている方も入るかもしれませんが、このインメモリキャッシュはPernixData社の無償製品FVP Freedomエディションに相当する機能です。アプリケーションにとっては小さなキャッシュサイズでも非常に大きな効果が得られる場合がありますので、是非心に留めておいてください。

CheckSum

VSANはネットワークを通じてデータを書き込むため、ネットワーク転送によってデータが変化していないことを保証する必要があります。近年のネットワーク品質を考えればほとんどありえないことですが、そこまで保証するのがVSANです。金融機関などで万が一が起こったとしたら、大混乱です。これも一種のErasure Codingと言えるかもしれませんが、RAID5/6が横方向にパリティを発行するものだとすると、CheckSum機能は縦方向に対してはチェックサムを発行し、VMから出たデータが正しくキャパシティ層に着地したことを保証するものです(データが変更されていることを検知するのが目的で、復元することが目的ではないのでパリティではなく、チェックサムが利用されています)。