みなさん、こんにちわ。VSAN 6.2がリリースされていろいろなご質問をいただくことが多くなってきました。特に通り一遍の機能紹介だけでは満足されず、その実装方式に至るまでものすごくふかーいご質問をいただくケースも有ります。こんなご質問にお答えするために今回はこんな記事を用意しました。
本記事はTech Field Day主催のイベントStorage Field Day 9内で2016年3月18日に実施されたVMware社のStorage & AvailabilityのCTOであるCristos Karamanolis氏のプレゼンテーションの録画から様々な情報を抜き出したものです。妙にマニアックな質問もありますし、実装手法をどう選んだかについてもCTO自ら意見しているケースも有りますので興味のある方は是非ビデオもご覧になってください。
実況中継というか、なんというか、ビデオから文字を起こしていますのでなんとなくゆる～い感じになってしまっていますが、内容はかなり濃いです。濃すぎてあえて文字にしなかった部分もありますので、そこは生のビデオを御覧ください。こちらの記事は雰囲気も含めてお楽しみいただければ幸いです。機能のリクエストについてや将来的な構想についての言及も有りますが、あくまでそこは保証の限りではありませんので、ご注意ください。
今回はまずは容量効率化編です。
VSANの重複排除と圧縮はクラスタの機能です。
ストレージポリシーとして実装されているというような議論も有るようですが、単一のVMに重複排除を適応したとしてもその効果はたかが知れています。ですから、クラスタ全体で実装されているのです。
重複排除と圧縮は両方を提供します。
複雑なので、どちらか一方だけ、などの選択肢をユーザーに提供はしません。ユーザーは重複排除と圧縮のどっちが有効なのかを知りません。なので選ぶこともしません。様々なデータを長時間にわたって調査しましたが、重複排除をした後に圧縮(LZ4を使っています)を行ってもさほどパフォーマンスに影響がないという結論に達しました。重複排除が聞かないようなデータベースなども、圧縮によってデータ削減がなされます。別々にする必要は無いのです。
実際に重複排除も圧縮もオーバーヘッドは非常に小さく保っています。重複排除を行った後に圧縮を行いますが、実際に利用する際にはオーバーヘッドは(圧縮単体や重複排除単体のオーバーヘッドと)さほど変わりません。ですから、両方を実施するのです。
重複排除のドメインはディスクグループです。
重複排除をクラスタ全体で実施するのか、それとも一部で実施するのか?我々の答えは重複排除はディスクグループのドメイン内で実施するというものです。これを選択するに至った経緯はいくつか有ります。VSANはロードバランシングの観点から様々なデータ分散を行っています。また、別の観点で言うと耐障害性の観点からもデータの分散を行っています。
グローバルで重複排除を行うと、せっかく障害を考慮して分散したデータが消えてしまいます。(もちろんグローバルの重複排除には劣りますが)ディスクグループ内での重複排除でもかなりのスペースの効率化が期待できます。
質問への回答の中から : ディスクグループ単位で実装することによって並列処理をおこなうためにも有利な実装になっています。
重複排除はキャッシュからキャパシティにデータが移動する際に実施されます。
もう一つの要件は可能な限りパフォーマンスに影響を及ぼしたくないということです。ですからデータはログ構造でパフォーマンス層(Writeバッファ)に書き込みます。この時点では何もしません、パフォーマンスには影響はありません。このデータをキャパシティ層に書き込む際に重複排除を実施します。この書き込みは重複排除されますからCPUなどの負荷を抑えることもできます。また、重複排除されるデータはキャッシュからキャパシティに落ちていくコールドデータのみです。書き込んだあと、すぐに更新がかかってしまうデータに対して重複排除を行う意味は無いからです。
重複排除のメタデータ自身もキャパシティ層に分散して保持されます。
重複排除のチャンクの細やかさのサイズは4Kです。ですから非常に優れた重複排除率を実現することができます。ですが、細かなブロックであるということはより多くのメタデータを必要とするという事にもなります。安価なキャパシティ層のSSDに分散して保持することにしました。ですからこのメタデータのサイズは2%～最大でも4%程度ですが、更にインメモリキャッシュなどのトリックも使って保持しています。
重複排除と圧縮はオールフラッシュのノードのみでサポートされます。
先程も述べたとおり、重複排除と圧縮は単一の機能です。ハイブリッドアーキテクチャの場合、ローカリティ(訳注:仮想マシンが動作しているノードにデータがある確率が高いこと)を考えなくてはなりません。ですが、このデータは重複排除されてしまいますので、ローカリティを考えるということがそもそも難しくなるのです。結果としてハイブリッドアーキテクチャの場合、非常に大きなキャッシュを載せなくてはなりません。だったらオールフラッシュの方がイイねという悲劇が生まれるのです。殆どの場合コスト的にオールフラッシュの方が理にかなっているという調査結果に基づいています。
会場からの補足: (サムスンの)SSDと4TBのHDDを考えて、3倍以上に圧縮が聞くようであればオールフラッシュの方がいいことになりますね。いろんな仮想マシンにおいて、大体4倍ぐらいは効いている印象です。もちろんこれは効くVMと効かないVMがあるという前提ですけど。イレイジャーコーディング(による効率化)もあるのでいいと思います。
圧縮はLZ4を利用し、ブロックが圧縮で4Kから2K未満になる場合だけ圧縮します
いろんなアルゴリズムを採用できますが、LZ4が最も効率が良いとわかりました。また、重複排除は4Kの単位ですが、この4Kを圧縮して2K未満になった場合のみ、圧縮を行い、そうでない場合は4Kのままキャパシティ層に書き込みます。
イレイジャーコーディング:RAID-5は1障害耐性、RAID-6は2障害耐性
RAID-5は3+1で最低4ホスト、RAID-6は4+2で最低6ホスト必要です。これはインライン処理(クライアント=仮想マシンで実施されます 訳注:キャッシュとキャパシティ間ではなく、仮想マシンとキャッシュ間で実施)です。ストレージポリシーで選択可能です。
イレイジャーコーディングはオールフラッシュのみでサポートされます。
イレイジャーコーディングを行うと、パフォーマンスと容量効率化にトレードオフが生じます。分散書き込みおよびパリティ計算などによって、RAID-5では1つのWriteが2つのWriteと2つのReadに増えてしまいます(合計4倍)。RAID-6では3つのReadと3つのWrite(合計6倍)になります。磁気ディスクではIOPS数が小さく、パフォーマンスに影響が出ますのでこの機能はオールフラッシュのみでサポートすることにしました。そうでないと、パフォーマンスを確保するために多くのSSDキャッシュが必要となり、結局オールフラッシュの方が安くなってしまうという、以前もお話した悲劇が起きるからです。
質問より: ROBO構成のようにノード数が小さいときに筐体内でイレイジャーコーディングを行いたいというニーズもあるのでは?
ノード単位ではなくてもっと小さな単位･･･ディスクグループ、おっと!言いすぎかな。保証はできませんが、将来的にそうしたニーズに対応するための機能は考えています。
チェックサム･･･これはエンドツーエンドです(笑)
ガンマ線やアルファ線でデータが変わってしまうことがありますんで･･･(笑)これは去年頂いたご指摘でしたね。CRC32でチェックサムを計算します。そしてデータとともにキャパシティ層に届けられます。データをReadする際にだけでなく、あらゆるステップでこのチェックサムをチェックします。これは単に保存時のデータが変わってしまうことだけではなく、いうように宇宙線など(笑)でデータが変わってしまうことに対してもデータを保護したいからです。もちろん、それだけではなく、ネットワークだったり、様々なポイントでデータが変更されてしまう可能性を排除したいからです。
チェックサムはデータが保管されているのとは別のディスクに保存されます
チェックサムはわずかばかりはパフォーマンスには影響しますが、ほとんど考えなくても良いレベルです。チェックサムは他のデータとは別に個別に管理されています。そしてこの機能はハイブリッドアーキテクチャでもオールフラッシュでもサポートされます。これは非常に重要な事です。標準でこの機能は有効になっています。要らないのであればOFFにすることもできます。
QoS機能は仮想マシンか、VMDKごとにIOPSの上限値を指定できます
サービスプロバイダなどのSLAに利用できます。いつも有効にするのではなく、システムの負荷が高い時にだけ例えば、レイテンシの閾値を設けたいなどのリクエストをもらっています。これについては将来的に対応を考えたいと思います。
CBRC(コンテンツベースのReadキャッシュ)をVSANに統合しました
VDI環境向けにCBRCを提供していますが、非常に高い効果をあげています。それをVSANに統合しました。キャッシュが分散するアーキテクチャのなので、ローカルの揮発性のつまり、インメモリのキャッシュを設けたということです。Write-Thoughのキャッシュですが、多くのワークロードに非常に有効です。仮想マシンが動作しているホスト上に構成されます。
質問より: 他のストレージ(VSAN以外の)に対しても使えるようにして欲しいなぁ。
それについては後でお話しましょう。(訳注: PernixDataが有りますよ!笑)
仮想マシンのスワップファイルをシンプロビジョニング出来るようにしました
これまで仮想マシンのスワップファイル(メモリ不足の際にメモリ内容を格納するファイル)はシックプロビジョニングされていました。今回、お客様からの要望に応える形でシンプロビジョニング出来るようになっています。
まとめ
今回は容量効率化編で、スライドを使うのではなく殆どがQ&A方式でしたので文字ばかりですが単なる機能として理解するのではなく、アーキテクチャとして理解するために重要な情報が得られますね。それぞれの箇所で述べていますが、将来的な機能については保証の限りではありませんので、ご注意ください。次回、パフォーマンス編ではスライドもご紹介したいと思います。乞うご期待!
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
