本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はWhat’s new in PernixData FVP 2.0 – Distributed Fault Tolerant Memoryで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
PernixData FVP 2.0は複数の高速化リソースを利用可能になりました. FVP 1.xでは仮想マシンのI/O操作の高速化に様々なタイプのフラッシュデバイスを活用することが出来ました。FVP 2.0ではサーバーサイドのメモリ(RAM)のサポートを開始しました。
メモリ(RAM)が支配する世界
近年のチップセットの進歩とソフトウェアの開発によって、数テラバイトものメモリを1つのvSphereホスト上で利用できるようになってきました。VMworldでVMwareはvSphere 6.0では6TBのメモリをサポートするとアナウンスし、最近ではvSphere 5.5 update 2で同じだけのメモリをサポートするとアナウンスしました。インテルの最新のプロセッサはCPUごとに最大1536GBのメモリをサポートしており、4wayのサーバで容易にvSphereでサポートされている最大のメモリにまで達する事ができます。
しかしながら、こんなに多くのメモリで一体何をしますか? 今日では、仮想インフラストラクチャから提供されるメモリを仮想マシンのI/Oを加速させるために利用できるようになりました。他のアプリケーションベンダーや独立系ソフトウェアベンダー(ISV)はこれらの巨大なメモリを活用して、IT運用やサービスに対して影響を及ぼそうとしています。
上から始めましょう。広大なメモリをデータ高速化に活用するアプリケーションですが、ユーザーはアプリケーションを変更する必要があり、これを実装するのはちょっとその辺を散歩してくるように簡単ではありません。ISVはこれに追従して、既存の利用者が多いことを利用しました。しかし、それでもストレージにメモリのパフォーマンスを提供できる特定のアプリケーションを利用する必要があります。分散耐障害性メモリ(DFTM)は仮想化データセンタのあらゆるアプリケーションに対して利用ができ、その素晴らしいストレージパフォーマンスを運用や管理のオーバーヘッドなく利用することができます。DFTMの紹介はvSphere Hight Availabiltiy(HA)と似たようなものと考えてください。すでにベリタスやマイクロソフトクラスタリングサービスのようなアプリケーションレベルのHAやクラスタサービスを利用できます。HAはあらゆる仮想マシンに対して、シンプルなvSphereクラスタサービスを設定するだけで、障害回避の機能を提供します。
拡張機能
DFTMはFVPが以前から提供していた、クラスタ化された、耐障害性を備えたストレージキャパシティとは独立してパフォーマンスを拡張できるプラットフォームの上に成り立っています。DFTMはFVPクラスタへのメモリ(RAM)リソースの動的追加、縮退を透過的に実現します。追加の高速化リソースが必要になった場合、単にFVPクラスタにメモリ(RAM)を追加すればよいのです。もしRAMがメモリリソースとして必要になる、もしくは他の計画のために利用したいという場合には、単にFVPクラスタに提供されているホストのメモリ(RAM)を縮退すればよいのです。今やホストメモリは多様な用途で利用できるリソースになりました、仮想マシンのコンピューティングメモリもしくは仮想マシンのI/Oの高速化にも利用できます。どんな役割を果たすべきなのか決めるのはあなたです。もし仮想化データセンタが新しい仮想マシンを動作させる必要が出てきた場合、新しいホストをクラスタに追加し、ホストメモリの一部をFVPクラスタに割り当てて、ストレージのパフォーマンスも拡張させることができます。
耐障害性書き込み高速化
FVPはメモリ(RAM)においてもフラッシュと同様に耐障害性とデータの一貫性を提供することができます。FVPは書き込みデータのレプリカをクラスタ内の他のホストのフラッシュやメモリ(RAM)などの高速化リソースに保存します。FVP 2.0はFVPクラスタをデータセンタの障害ドメイントポロジに合わせて構成することも可能になります。詳しくは｢PernixData 2.0の新機能 ー ユーザー定義の障害ドメイン｣を参照してください。
クラスタ化されたソリューション
FVPはクラスタ化テクノロジーをベースとして、耐障害性書き込み高速化を提供し、障害対応も実現しています。もし、ホストやネットワークなどのコンポーネント障害が起きた場合、FVPは透過的に書き込みポリシーを切り替え、新しく流入してくるデータの可用性を確保します。ソースホストか、もしもソースホスト側に問題がある場合にはピアホストのいずれかが、FVPクラスタ内にあるコミットされていないデータを自動的にストレージアレイに書き込みます。ピアホストの側に問題がある場合には、FVPは新しく流入してくるデータを安全に保ちながら、自動的に新しいピアホストを書き込みの耐障害性サービスを継続できるように選択します。これら全てはユーザーからのいかなる操作も必要としません。更に詳しく知りたい場合には｢耐障害性書き込みの高速化(フォルトトレラントライトアクセラレーション)｣を参照してください。
仮想化データセンタを長年にわたってサポートしてきたvSphereのクラスタリングサービスをサポートするためにもクラスタ化されたプラットフォームが必要不可欠です。DRSやHAは完全にサポートされています。FVPのリモートアクセスは仮想マシンのモビリティに対応でき、どのホストにデータが有ったとしても仮想マシンからデータにアクセスすることが可能です。詳しくは｢PernixData FVP リモートフラッシュアクセス｣を参照してください。ホスト障害の際には、FVPはコミットされていないすべてのデータをストレージアレイに書き込み、HAや仮想マシンの再起動ができることを保証します。
構成の簡単さ
フラッシュやメモリ(RAM)を高速化リソースとして利用しようとした際に、パフォーマンス面での素晴らしいメリット以外にも、構成が簡単という点も非常に大きなポイントです。メモリはCPUに可能な限り近いところに配置されています。可動部分、サードパーティ製のストレージコントローラーのドライバー、RAIDやキャッシュ構造のような特殊な構成もありません。単にFVPをインストールし、メモリ量を割り当てて、それでおしまいです。可動部分がなく、フラッシュに比べてCPUに近いということで、メモリ(RAM)は非常に一貫した予測可能なパフォーマンスを提供します。これによって、素晴らしい帯域と、低い遅延、高いIOパフォーマンスを利用できるようになります。以下のスクリーンショットはSQL DBサーバのものです。下のグリーンの平坦なラインはネットワークと仮想マシンから見た際のレイテンシです。
メモリ(RAM)のI/Oのレイテンシは20マイクロ秒で、ネットワークのレイテンシが270マイクロ秒で、これが明らかに｢遅くしている｣要素です。カーネルによって幾らかのオーバーヘッドが追加され、アプリケーションからは安定的にそして、予測可能的に320マイクロ秒のレイテンシとなっています。振動しているのではないかと思ったのでズームインしてみましたが、仮想マシンから見たレイテンシは一定でした。
ブルーのライン : 仮想マシンから見たレイテンシ
グリーンのライン : ネットワークのレイテンシ
イエローのライン : メモリ(RAM)のレイテンシ
ネットワークのレイテンシーはクラスタ内の他のホストにデータを安全に書き込むために追加されています。書き込みは同期されて行われます。つまり、ソースホストはI/Oの完了をアプリケーションに伝える前に、両方のリソースから通知を受け取る必要があります。
これは、DFTMを利用すれば、最もリソースが必要になるようなアプリケーションを仮想化でき、メモリ(RAM)を利用して耐障害性を備えたストレージパフォーマンスを利用可能になるということです。SAP-HANAは非常に良い事例です。最近私はSAP-HANA環境のストレージ要件についての記事を書きました。SAP-HANAはインメモリのデータベースプラットフォームでは有りますが、ログ操作のためのパフォーマンスを提供するためにフラッシュのような高速なストレージリソースを利用するように推奨されています。ログはデータベースのACID(Atomicity,Consistency, Isolation, Durailiby)を保証するために、揮発性構造のメモリ以外に書き込まれる必要があります。FVPのDFTMを利用することで、すべてのデータ(データベース と ログ)はメモリ上に保持され、十分なパフォーマンスを確保しながら、耐障害性書き込み高速化を活用して、ACID要件を保証します。モビリティがサポートされているため、SAP-HANAもしくは類似の構成のアプリケーションはvSphereクラスタ内を自由に動き回ることができます。仮想化データセンタ内の最後のサイロをブチ壊しましょう。
次の大きな事
Satyam Vaghani氏の名言によると : この開発の本当の成果は予測可能な一定したマイクロ秒のストレージパフォーマンスを利用可能になることです。業界のあちこちで日々行われている開発によって、いつかはナノ秒のレイテンシに到達するであろうということに対しては何ら疑問は生まれません。このようなレベルのスピードに業界が到達した際、我々はPernixDataとして、完全に、そして根本的にアプリケーションがストレージインフラストラクチャに求めるものを変えてしまえると信じています。アプリケーションはストレージプラットフォームにミリ秒レベルのパフォーマンスを期待して、ストレージパフォーマンスがボトルネックなのだからと、コードを改善することを諦めてきました。FVPとサーバーサイドの高速化リソースによって、歴史上、始めてストレージパフォーマンスはボトルネックではなくなり、また、歴史上、初めて驚異的に早いストレージに手が届くようになりました。中小企業クラスのプラットフォームでも望むのであれば、100万IOPS、超低レイテンシーの構成を利用できるようになります。次のステップについての本当の疑問は、もしも100万IOPS、マイクロ秒のレイテンシの仮想化データセンタを利用できるようになった際に、その力を何に利用するか?どんなアプリケーションを開発するのか?この力を使ってどんなユースケースが考えられるのか?ということになります。
PernixDataにおいて、我々はもしストレージシステムとその使い方を取り巻く大前提を変えることができたとしたら、アプリケーション開発の常識やアプリケーションのインフラの使い方などの新しい革命を目の当たりにすることになると信じています。そして、その革命はもっともっと胸が高鳴るものになりつつあると考えています。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
