本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はFVP 2.5 Server side storage intelligence in the post flash eraで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
昨日我々(PernixData)はFVPプラットフォームの最新ヴァージョンをリリースいたしました。FVP 2.5はストレージ高速化ソフトウェアとして着実にその機能を改善し続けています。これによってデータセンタで従来のストレージアレイのアーキテクチャでは絶対に実現ができなかったストレージアーキテクチャを実現できるようになっています。
サーバサイドストレージインテリジェンス
FVPはVMware ESXiハイパーバイザーに統合されています。これによってFVPは最高水準の高速化リソースをアプリケーションに可能な限り近いところで、統合することができるようになっています。FVPはフラッシュテクノロジーとRAMテクノロジーの双方を高速化リソースとしてサポートしています。高速化リソースをコンピューティングレイヤー内に組み入れることで、前例のないスケールアウト可能なアーキテクチャと実現でき、しかも最新で、最高のテクノロジーを活用することができるのです。
業界における最も大きな課題のうちの一つが、新しいテクノロジーの登場に追従していくことです。フラッシュのテクノロジーを例に取ると、最近のフラッシュデバイスは1デバイスあたり実効で250,000 IOPSを簡単にさばけるようになっています。強力で、最新鋭のCPUはこの能力を活用する必要があります。幸運なことにサーバーハードウェアはその設計に新しいテクノロジーを取り入れることでアーキテクチャとして最新鋭に追従してきています。一方でほとんどのストレージコントローラーは最新から遅れを取りつつ有ります。これは古いCPU世代のマイクロアーキテクチャを利用しているためで、I/Oの処理以外にデータサービスや管理タスクをすべてそれで実行しているためです。ほとんどのモノリシックストレージアレイは2つのコントローラーを搭載するアーキテクチャを採用しており、その役割はお互いにフェイルオーバーしあい、有限のCPUリソースを融通しあってより活用するためです。ご想像のとおり、このアーキテクチャでは先へ進むことができません。こうしたシステムでは先進的なストレージリソースのための負荷を理想的な場所へ配置していないからです。フラッシュベンダーの勢いは衰えていません。今後2015年、2016年に登場が予定されているフラッシュのテクノロジーは素晴らしい物になるでしょう。2,3年先を見据えると、非揮発性のDIMMや相変化メモリなどとともに、フラッシュ以降の時代がゆっくりとスタートしつつあるようです。
残念ながら、これらの新しいメモリが利用できるようになるまでにはもう数年の時間が必要です。しかし、同時にこれはデータセンタにおいて古いが、素晴らしいDDRメモリを活用して仮想データセンタ内のワークロードを高速化できるとういことを意味します。コンピューティング内のメモリを活用する業界のトレンドに習って、FVP 2.0では分散耐障害性メモリを登場させました。
分散耐障害性メモリ
分散冗長性メモリ(DFTM-Distirbuted Fault Tolerant Memory)ではFVPのすべての機能を耐障害性とデータの整合性持ちながら、フラッシュテクノロジーに対してそうであったように、RAMでも活用することができます。FVPは書き込みデータのレプリカをクラスタ内の他のホストのフラッシュもしくはRAMの高速化リソースに転送する機能を提供しています。また、FVPはFVP Clusterをデータセンタの障害ドメイントポロジに合わせて構成することができるようになっています。DFTMはFVPクラスタへのメモリのホットアド、ホットシュリンクにも対応しています。もっと多くの高速化リソースが必要とされた場合、単にもっと多くのRAMをFVP Clusterに追加すればよいのです。もしメモリリソースのためにRAMが必要な場合、もしくは別のことにメモリを利用する計画があればFVP Clusterに提供されているホストのRAMの総量を減らすだけです。ホストメモリは今日では複数の目的で利用ができるように成ったのです。仮想マシンのコンピューティングメモリとしての役割と、仮想マシンのI/O高速化です。どのように利用するかはあなたの決定次第です。もし仮想化データセンタが新しい仮想マシンの動作を必要としている場合、新しいホストをクラスタに追加し、ホストメモリの一部をFVPクラスタに追加することで、ストレージのパフォーマンスをもスケールアウトさせることができるようになっているのです。
DFTM-Z
FVP 2.5ではDFTM-Z - 調整型メモリ圧縮 - が搭載されました。これによってパフォーマンスを向上させながら、より少ないリソースで高速化レイヤー内にこれまでより多くのアプリケーションのワーキングセットをフィットさせることができるようになっています。
興味深い点としてあげられるのは、圧縮はこれまでいつも、キャパシティを拡張するための機能であったという点です。エンジニアリングチームはこの技術をキャパシティの代わりにパフォーマンスのために利用することを実現しました。ご想像のとおり、世界を全く別の方法で見るのがエンジニアチームの仕事の根本です。
圧縮について議論するとき、明らかな疑問として、データの圧縮と、展開のレイテンシはどうなんだ?ということがあげられます。FVPはパフォーマンスのプラットフォームですから、DFTM-Zは根本からその影響を絶対的に最小にするように設計されています。
圧縮は高いレベルの圧縮を行えば行うほど時間とCPUサイクルのトレードオフを持っています。多くの時間とCPUリソースを利用すれば高いレベルの圧縮を行うこともできますし、CPUサイクルと時間をあまり使わず、低いレベルの圧縮を行うこともできます。ストレージシステム出会った場合、この選択は簡単です。すべてを圧縮し、多くの時間とCPUのサイクルを利用します。圧縮をパフォーマンスのために利用する場合、これは全く違うものになります、というのも時間はパフォーマンスそのものだからです。オーバーヘッドの追加をさける調整型の圧縮エンジンが必要になりますそして、ここでFVPの圧縮エンジンが光り輝くのです。少ないコストで高い圧縮率を実現します。面白いことに、これは我々の第2世代の圧縮エンジンは大きな成功を収めた第1世代の調整型ネットワーク圧縮エンジンと同様なのです。
DFTM-Zは20GB以上のメモリがFVP Clusterに提供されている際に自動的に有効になります。DFTM-Zが有効になったら、メモリ管理機能が圧縮データを保存する領域を作成します。圧縮された領域はホストの高速化リソースの総容量に応じて拡張され、圧縮領域と非圧縮領域の割合を最適化します。
圧縮はバックグラウンドで、コールドデータに対して行われるため、書き込みに対する影響は最小です。仮想マシンのワーキングセットが割り当てられた容量よりも大きくなると、DFTM-Zは古いデータを圧縮し、圧縮領域へと保存します。これによってFVPはアクティブな書き込み操作への影響なくデータを保存できます。FVPは動的なしきい値を用いて高速化リソースが最適状態で管理され利用できるようにするのです。
もしアプリケーションが圧縮領域にあるデータをリクエストした場合、データは展開され、非圧縮領域へと戻されます。FVPはデータの一元性を管理しデータのローカルにあることにフォーカスしています。データが圧縮される場合、FVPは隣接するメモリのチャンクも合わせて全体を圧縮します。そのチャンクの一部にでもアクセスが発生した場合、FVPはチャンク全体を展開します。アプリケーションがアクセスのローカル性のためにすべてのデータを読み込む事になった場合、展開のレイテンシは正規化されます。オーバーヘッドを絶対的に最小に保っています。それでも幾らかのレイテンシが追加されますが、必要なデータをアレイ内のスピンドルまで取りに降りて行くよりははるかに小さなものになります。それでは前に進めないことはみんなわかっていますよね?
ユーザーインターフェース
FVP Clusterのダッシュボードが2つの数字を表示しています。以前まではキャパシティを表示していましたが、DFTM-Zが搭載されたことにより、キャパシティとともにその横に圧縮した場合のキャパシティを表示しています。以下のスクリーンショットではFVP Clusterのキャパシティは128GBです。これはホストからクラスターへ提供されている実際のフラッシュやRAMの容量を合計したものです。2つ目の数字がメモリ圧縮時のキャパシティです。このシナリオでは133.91GBになっています。これは実際のフラッシュのキャパシティと圧縮を有効にしたあとのメモリキャパシティを足したものになっています。これは仮想的なキャパシティです。仮想的なキャパシティは非圧縮領域+(圧縮領域/平均圧縮率)で算出されます。
仮想キャパシティのサイズはリアルタイムではなく、時々更新されるものであることを覚えておいてください。このスクリーンショットはベータソフトウェアのもので、仮想キャパシティを小数点以下のレベルの正確さで表示していますが、もうすぐリリースされる正式版2.5では四捨五入した値が表示されることになると思います。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
