FVPのスケールアウトアーキテクチャ

本ブログエントリーはPernixData社のシニアテクニカルディレクターであるMahesh Patil氏のブログの翻訳版です。 

Mashesh氏はPernixData社のシニアテクニカルディレクターで、耐障害性Write-Backの主な発明者です。それ以前には彼はVMwareでスタッフエンジニアとして務め、11年以上に渡り様々な仮想化のテクノロジーを手がけてきました。

アセンブリコードを簡単に使いこなすのと同様、彼はRubyも得意としており、専門は仮想化、カーネル開発、リソース管理、OSコンテナ、クラウドオペレーティングシステムなど多岐にわたります。彼はESXi製品の基盤を成したエンジニアの一人です。クラウドOSに関する専門性を買われ、VMwareではCloud Foundryのプロジェクトにも貢献していました。

本記事の原文はScale Out Architecture of FVPで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。

スケールアウトはスケールアップとは対照的にソリューションを多くのホストをクラスタ内に追加することで成長させることを約束するものです。しかし、この約束をうまく果たせていないソリューションを目にすることも稀にあります。なぜスケールアウトは難しいのでしょうか?それぞれのソリューションが固有にもかかわらず、スケールアウトが難しい理由にはいくつかの共通したテーマがあります。

• 複数のホストは複数のデータのコピーを意味する
• 複数のコピーは一元性と一貫性を維持し続ける必要がある

コピーの一元性を維持し続けるためには、｢キャッシュの一貫性｣について紐解く必要があります。以下のリストで紐解いていきましょう。リストの下ほど一貫性のための値段(コスト)が高くなります。

• 変更できないオブジェクト
• 変更可能なオブジェクト  Single Reader, Single Writer (Single-RW)
• 変更可能なオブジェクト Multiple Readers, Multiple Writers (Multi-RW)

変更できないオブジェクトの一貫性を保つのはとても簡単です。変更可能なオブジェクトについては、システムにより多くのWriterが追加されシステムが複雑化してくると、オブジェクトの一貫性を保つために、ネットワークを通じてメッセージのやり取りを初める必要が出てきます。そして、これらのメッセージの数がクラスタ内のホストが増えるに連れて級数的に増えていくということが頻繁に起こります。つまり、クラスタ内のホスト数が増えるごとにキャッシュの一貫性のためにしなくてはならないこと(コスト)が増えるのです。

しかし、全てのスケールアウトシステムがMulti-RWに紐づく｢キャッシュの一貫性｣のためのコストを支払う必要はありません。業界ではMulti-RWのキャッシュ一貫性のためのコストを支払っている場合でも、Single-RWのキャッシュ一貫性のキャッシュ一貫性アルゴリズムしか必要ない場合が多くあります。このMulti-RWアルゴリズムのマズイ選択はシステムのパフォーマンス、複雑さ、安定性に波及効果を及ぼします。以下の例で説明していきましょう。

例1

分散ファイル編集システム

• 複数のユーザーが地理的に隔たって分散しています。
• 複数のユーザーは同じドキュメントを同時に共有、編集可能です。ドキュメントに対する更新はすべてのユーザーからほぼリアルタイムに閲覧可能です。
• ユーザーのレイテンシはローカルのデスクトップ上のドキュメントの編集とさほど変わりないことが期待されます。

もし、レイテンシがこのシステムの行く末を決めるキーメトリックであるならば、このシステムは上で表したようなソフトウェアがユーザーに対してドキュメントをローカルで編集させながら、一方でバックグラウンドで複数のユーザーの編集を調停するような分散システムになることでしょう。結果としてMulti-RWキャッシュ一貫性を保証し、システムは様々なホストが保持しているコピーを最新に保つためのメッセージを交換することになります。Multi-RWキャッシュ一貫性アルゴリズムに加え、システムは以下の点を解決しなくてはなりません。

• 一元性 - それぞれのユーザーにどのように更新を表示されるか。これは様々なモデルを採用することができます。完全一元化、時々一元化など。もしあるユーザーがとある更新を別の更新の前に見たとしたら、それ以外のユーザーも同じ順番でそれを見たいと思うはずです。
• 分断 - もしネットワークの分断が起き、いくらかのユーザーが他のユーザーから切断されてしまった場合にシステムはどうすべきなのか?
• 高可用性 - データはしっかりとレプリケーションされているべきです。

今日ではそれぞれについてよく知られたアルゴリズムやソリューションがあります。これらのソリューションの殆どはパフォーマンス、正確さ、可用性の全てのタイトロープを渡りきったものです。多くの場合、一つのことは他のものへ影響を与えます。 例えば、高いパフォーマンスを求めるシステムは完全に一貫していなくても良い事があります。様々なトレードオフがそれぞれのソリューションにありますが、詳細に分け入らなければ大きなパフォーマンスへの影響やアルゴリズムの複雑さ、各タスクが正しく実装されているかを言及することはできません。

例2

ファイル編集システム

• 複数のユーザーが地理的に隔たって分散しています。
• それぞれのユーザーは自分自身のドキュメントしか編集できません。
• ユーザーはロケーションを動きまわることができますが、自分自身のファイルしかアクセスができません。
• ユーザーのレイテンシはローカルのデスクトップのドキュメントを編集する程度であることが求められます。

この例ではドキュメントは唯一のユーザーからしか編集ができなくなっていますので、このシステムは単純にSingle-RWのためのキャッシュ一貫性アルゴリズムを利用すれば良いことになります。このアルゴリズムではドキュメントを最新に保つために他のシステムとメッセージを交換する必要がありません。｢例1｣で解決しなくてはならなかった他の問題も見てみましょう。

• 一元性 - 1人のユーザーが自身のドキュメントを更新するので、ドキュメントのコピーは常に一元的です。
• 分断 - 同様にネットワークの分断もユーザーに影響を与えません。ユーザーは自身のドキュメントを操作しているだけなので、そのまま継続ができます。ですから、この問題も些細なものになります。
• 高可用性 - ｢例1｣と同様、データはしっかりとレプリケーションされなくてはなりません。

分散スケールアウトソリューションを構築する際に、｢例1｣とは違い、こちらの立場で考えるべきだとお分かりいただけて来たのではないかと思います。どうしてどうしてこの特定の問題がスケールアウトソリューションを低遅延で構築する際に重要なのかも理解いただけてきたかもしれません。

問題に見合ったソリューション

上の2つの例からすべての分散システムが同じではないということはよくお分かりいただけたと思います。もし開発者が彼らが相対している問題に見合うソリューションを見つけられたら、それによってソリューションのメリットを阻害することなく、不必要に複雑なものを導入する必要はありません。明らかに上の例では｢例1｣のために作られたソリューション、つまりMulti-RWキャッシュ一貫性は｢例2｣つまり Single-RWキャッシュ一貫性の問題も解決できているはずです。ですが、本当にMulti-RWキャッシュ一貫性が必要なのでしょうか?

この考え方がFVPのスケールアウトデザインの根本的な部分です。我々は自らにといました。もしも、仮想化環境のスケールアウトソリューションを作ることができたら?それはどんなものか?どのキャッシュ一貫性アルゴリズムを使うべきなのか?

上の図は典型的な仮想化環境を表しています。上の絵はほとんど｢例2｣に似たようなものであるということがわかるでしょう。仮想マシンのデータは完全にvmdkファイルにカプセル化されています。仮想マシンは自分自身のvmdkにしかアクセスしません。つまりSingle-RWです。仮想マシンは任意の時点で一つのホスト上のみで動作しますので、これらのvmdkファイルは必ず唯一のホストからのみアクセスされます。もし仮想マシンがvMotionした場合、ユーザーが別のロケーションに移動するようなものです。移動後も自身のファイルにアクセスし続けるだけで、他のクラスタ内の無数の仮想マシンのファイルには興味はありません。では、FVP ソリューションを登場させましょう。

FVPがシステムに導入されると、仮想マシンはローカルフラッシュデバイスを利用してローカルにキャッシュを構築し始めます。それぞれのホスト上のフラッシュデバイスはそのホスト上で動作している仮想マシンのvmdkすべてを格納できるほどに大きいと思ってください。このすべてのvmdkを格納できるという想定や実際にどれだけのデータがローカルに保存されているのかという点はスケールアウトの観点からは全く問題にはなりません。

上のシナリオでは、それぞれの仮想マシンのvmdkへのReadは全てローカルのキャッシュから提供されます。もし、ユーザーがクラスタに1つのホストを追加したとしたら、図は以下のように変わります。

リニアにスケール

上にある通り、FVPクラスタに新しいホストが追加され、追加の高速化リソースがホスト上で高速化されている仮想マシンで利用できるようになっています。今のところ、仮想マシンは動きまわらないと考えてください(後でこの単純化については戻ってきて言及します)、ですから、これらの仮想マシンはローカルフラッシュデバイスのみで高速化されます。この実装ではクラスタ内の他のホストとのやり取りは一切発生しません。キャッシュ一貫性のためのメッセージはネットワークを流れることはないのです。クラスタのサイズではFVPソフトウェアの挙動は一切変わることはありません。1台、32台、1000台のクラスタであっても問題にならないのです。Readのパフォーマンスは仮想マシンが動作しているホストで利用可能なフラッシュの総量によってのみ制限をうけ、クラスタ内のホスト数の影響は受けないのです。お分かりのとおり、このソリューションではReadはシステム内のホストの数が増えるに連れてリニアにスケールし、フラッシュの容量によってのみ制限を受けることになります。これは非常に重要な特性です。クラスタ内のホスト数によってリニアにスケールする能力を備えているのです。

Single-RWキャッシュ一貫性

一般的な分散システムではMulti-RWキャッシュ一貫性問題を解決しなければならないことで、リニアにスケールすることが難しくなっています。｢例1｣において、ユーザーに対して書き込みの順序を保証できるように合意を取ろうとしてクラスタ内の全てのシステム･ホストが一貫した表示を実現しようとすることはシステムに非常に巨大なオーバーヘッドを生み出します。そして、このオーバーヘッドは大抵の場合、クラスタ内のホストの数によって増大します。FVPソリューションはこのような制限に悩まされることはありません。問題の解決はSingle-RWキャッシュ一貫性ソリューションによって実現可能で、分散された同士がコンセンサスを取ることが必須とされているMulti-RWキャッシュ一貫性ソリューションを使う必要が無いからです。

キャッシュ一貫性とvMotion

しかしながら、現実の世界では仮想マシンは動き回ります。仮想マシンが別のホストに移動を始めると、キャッシュの一貫性を維持するためにFVPのキャッシュ一貫性アルゴリズムが呼び出されます。我々のキャッシュ一貫性アルゴリズムは仮想マシンが新しいホストへ移行する際にのみ、呼び出される様になっています。その後の仮想マシンからのIOはキャッシュの一貫性にペナルティを与えることはありません。全てのIOについてキャッシュの一貫性についてのタスクを実施するのではなく、FVPソリューションは上の図の通りに再度動き始めます。つまり、システム内のホスト数でリニアにスケールするのです。vMotion後のリモートのReadについてもシステム内のホスト数が増えることで、増えるものではないことをご確認ください。FVPのキャッシュ一貫性アルゴリズムは以前どのホストでその仮想マシンが動作していたということを理解しており、リモートReadを行うホストにダイレクトにアクセスするのです。

まとめ

FVPのパフォーマンスのスケールアウトは仮想マシンが自分自身のvmdkファイルにしかアクセスしないということをよく理解した上でそれを活用するように構成されています。仮想マシンがSAN/NAS上の自分自身のデータにアクセスする際に、周りと相互確認を行うことはありません。このことをキャッシュ一貫性アルゴリズムと結合することで、仮想マシンのIOへオーバーヘッドを全く与えない、システム内のホスト数でほとんどリニアにスケールするスケールアウトアーキテクチャをFVPは提供するのです。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)