本ブログエントリーはPernixData社のSystems EngineerであるJoshua Spencer氏のブログの翻訳版です。
PernixData社にジョインする前はVMwareでエンドユーザーコンピューティングのスペシャリストとして5年間過ごしています。その前は12年間にわたってデスクトップエンジニアリングのスペシャリストとして情報システム部門のサポートをしていました。
Joshuaはトレド大学でビジネスにおけるテクノロジー分野での学士号と修士号を保持しています。10年近くにも及ぶデスクトップ、サーバ、アプリケーション仮想化テクノロジーと幅広いハンズオンの経験を持ち、国内外でその経験を活かして活躍しています。
本記事の原文はMaximizing VDI Performance with FVP and Lakeside SysTrackで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
VMwareで8年間にもわたってVMwareのVDIの実装、販売、そしてトレブルシューティングをしてきた中で、私はこのテクノロジーの浸透を阻害する幅広く蔓延している障壁を見続けてきました。 ーそれは、ストレージのパフォーマンスですー。｢パフォーマンス｣という言葉を強調しておきます。長きにわたって、ストレージはほとんどキャパシティ(容量)という意味でだけ、評価されてきました。VDIが離陸し始めた直後は、情報システム部門は単に、エンドユーザーのローカルハードドライブにどれだけのデータが入っているか、ということにだけ注目していたのです。しかし、数百、数千のデスクトップを仮想化するという状況において、人々は突如立ち止まってしまいました。結局のところ、ローカルの100GB程度のハードドライブをリプレースすることは、同じキャパシティのエンタープライズクラスのストレージ装置リプレースすることに比べると遥かにコストがかかることだったのです。
展開のテクニック
VDIのベンダーが展開のテクニックを登場させるまでにさほど長くはかかりませんでした。例えばVMwareのコンポーザーなどがそれです。これによってキャパシティ要件を下げることが出来るのです。実際、これはうまくいきました。顧客はこれによってこれまでは一つのLUNにほんの僅かしか仮想マシンを展開できなかったところが、突然数百もの仮想マシンを展開できるようになったのです。簡単な算数を使ってこれを可視化してみましょう:
従来からのテクニック
LUN1 = RAID5構成の 500 GBのディスクドライブ x 5本 = 2 TB のストレージ利用可能領域
2TB ÷ 100 GB のディスクドライブ = LUN1上には 20の 仮想化デスクトップ
*** シンプロビジョニングや他のストレージ装置由来のテクノロジーでこの数は40～60もしくはもっと多くなりますが、これについてはコンポーザーの概念を通して次の節でお話します。
*** LUNを完全に埋めてしまうようなことは望ましくありませんが、単純化のためにこの数字を利用します。5本のディスクドライブで20のWindowsインスタンスを動作させているということだけご注意ください。
(5本のドライブで20のWindowsインスタンスを動かしています。)
コンポーザーを利用したリンククローンでの展開
コンポーザーのようなものを利用すると、算数は随分違ってきます。:
100 GB (マスター) + 100 GB (レプリカ) + (デスクトップ数 x 5 GB (クローン))
お分かりのとおり、キャパシティの観点からは同じLUN上で300以上のデスクトップを展開することが可能になりました!
IOPSとWindows OS
残念ながら、この問題を解決したところ、別の問題が出てきました。これは従来のアプローチでモノリシックな共有ストレージシステムを利用するというアプローチでは解決するのがとてもむずかしいということがわかってきます。ーつまり仮想マシンのパフォーマンスですー。御存知の通り、WindowsのデスクトップOSは非常に意地汚いものです。これはPC内の単一のドライブを専有して利用することを想定して設計されているからです。設計からして、Windowsは利用できうる限りのディスクのパフォーマンス(IOPSとスループット)を利用しようとします。これはエンドユーザーのユーザーエクスペリエンスを最善に保つために行われます。ですから、ローカルのSSDのような高速なドライブを利用することで応答時間を改善し、加速することができます。VDIではWindowsはLUNのIOPSとスループットを他の動作しているWindowsインスタンスと共有することを強制されます。新しい問題を簡単な算数でもう少しわかりやすくしてみましょう:
LUN1 = RAID5構成の 500 GBのディスクドライブ x 5
15K SASドライブそれぞれはピーク時で200 IOPSの能力が有ります。ReadとWriteの割合はデスクトップのワークロードによって変動します(ブート、ログオン/ログオフ、定常状態で大きく変わります)。270IOPS(R:W = 10:90 ーログオンストームの間など)～ 770IOPS(R:W=90:10 ーブートストームの間等)の間のあらゆる場合が想定されます。
* IOPSの計算は簡略化していますが、この例で利用できるようにしてあります :
-
最大 Read IOPS (100% Readと想定) = 200 IOPS x 5 本 = 1,000 IOPS
-
最大 Write IOPS (100% Writeと想定) = 200 IOPS x 5 本 ÷ 4 (RAID 5のWriteペナルティ) = 250 IOPS
計算をシンプルにするために、一般的な｢定常状態｣のシナリオを用いると、500 IOPSを利用できることになります。これは R:W がきっちり 65:35 の割合だと想定ことになります。
Windows デスクトップにどれだけのIOPSが必要か、ということは多くの誤解が有りますが、思い出していただきたいのはOSがハードドライブを専用するという設計になっているということです。平均的に7200 RPMのドライブは75IOPS程度です。上の計算から明らかなように、いずれのシナリオでも物理PCと比較して十分なユーザーエクスペリエンスを提供できないのです。しいて言えば、最初の想定のほうがちょっとばかり2つ目よりマシなぐらいでしょうか。
つまり、根本的な問題があるということなのです :
仮想マシンごとのコストの天井はデスクトップごとに専属のディスクを用意する場合です。そうでなく、多くの仮想マシンをスピンドル内に統合しようとするとパフォーマンスは地に落ちてしまうのです。
どうやってこれを解決するか?
業界はこの問題を解決するために何年も必死になって努力をしてきました。様々なキャッシュソリューションが登場していますが、制限事項や複雑性で謎かけを行うようなものであり、ユーザーエクスペリエンスのさらなる悪化や、情報システム部門のさらなる頭痛の種となったりもしています。殆どのキャッシュソリューションはRead IOPSにだけフォーカスしており(実際にはRAIDのWriteペナルティによってWriteのほうがもっと大きな問題になるにもかかわらず)、更に、ゲストOS内にエージェントの導入が必須であったり、特定のホストにデスクトップをピン留めしてしまったり、ストレージのLUNやデータストア、ゲストOS内のディスクなど、ストレージの複雑さを更に繰り返すことで複雑性を上げてしまうものになっています。
フラッシュですべて救済できるか?
フラッシュメディアがメインストリームになったころ、ついに、ストレージのパフォーマンス問題を解決することを約束するというハイブリッドやオールフラッシュベンダーの爆発的な増加を目の当たりにしました。こうしたストレージ装置は従来型の回転するディスク装置よりも遥かに優れたパフォーマンスを提供する一方で、非常に高価でした。こうした時に問題になるのはVDIの展開が期待通りに進まなかった時にどうするのか?ということです。使われもしないで鎮座する高価なストレージが残り、仮想マシンごとのTCOは増加します。期待以上に早く展開が進んだら?今度は高価で複雑なストレージの入れ替えと廃棄を考えなくてはなりません。今はノンパーシステントデスクトップで要件が足りると思っていたけれども、最終的にはパーシステントデスクトップが必要になったら?もしも、コストを算出した時に期待していたレベルで、重複排除が動作しなかったら?このようなことが起こると、VDIのプロジェクトは墜落するか、情報システム部門がエンドユーザーの要求に見合うだけのパフォーマンスが得られる経済性を構築するまで速度を失ってしまいます。
VDIに求められるストレージ要件を理解する
ちょっと振り返って、、、もしVDIのためのストレージを購入しようとしているとして、どれだけのIOPSが実際に必要なのかを知る必要が無いとしたらどうでしょうか?答えはもちろん｢YES｣です、しかし、言葉以上に複雑です。もし、WindowsデスクトップOSがブートすると、Read:Writeは90:10の割合のI/Oアクティビティになるということはザラです。ですが、Windowsデスクトップにログインしようとすると、その数字は簡単に反転します。100もしくは1,000のWindowsデスクトップがブートアップし、ユーザーが次々とログインをはじめたと想像してください。これは｢ブートストーム｣と｢ログインストーム｣として知られています。全ての仮想マシンが出来るだけ自分のためにディスクのパフォーマンスを利用しようとして争い、共有ストレージ上に大惨事が起こります。ストレージ装置内のディスクコントローラーは過剰不可となり、ストレージネットワークはパンパン、ディスクはReadとWriteのリクエストにはついていけず、座っているエンドユーザーは何分も待って、ようやくデスクトップが利用可能になるのです。
Lakeside SysTrack
数年前、私はLakeside Softwareという会社を紹介されました。彼らはSysTrackという業界をリードするエンドユーザー監視と解析プラットフォームを提供し、エンドポイントの定量的なデータによって興味深いデータを提供しています。SysTrackはエージェントベースのソフトウェアソリューションで、継続的に数千種ものパフォーマンス計測値を物理PCから収集します。そして、(ストレージも含め、他のインフラストラクチャコンポーネントにおいて)どれだけのパフォーマンスが、環境を上手く仮想化する際に必要なのかというレポートを生成します。私がWindows OSがディスクに対してどれだけの要求を出しているのか、そしてそれが1日の中でどんなにも変動しているのかということを視覚的に見たのはこのアセスメントの最中が初めてでした。以下にこの概念をよく表したSysTrackのレポートのサンプルを掲載します:
一週間の統計
| 統計 | ディスク I/O (IOPS) SAN | ディスク Read (IOPS) SAN | ディスク Write (IOPS) SAN |
| 最小 | 0.00 | 0.00 | 0.00 |
| 最大 | 12,000.87 | 10,872.56 | 4,310.43 |
| 算術平均 | 836.58 | 512.57 | 352.29 |
| 分布平均 | 70.91 | 35.88 | 33.39 |
| 標準偏差 | 1,776.85 | 1,178.10 | 717.32 |
| 80% | 1,085.26 | 581.76 | 500.45 |
| 90% | 3,500.18 | 2,092.61 | 1,413.52 |
| 95% | 4,751.86 | 2,879.40 | 2,120.55 |
IOPSのピークは12,000だということですが、95%の時間帯においては4,751 IOPSしか利用されていません。言い方を変えると95%もの時間はほぼ2/3の共有ストレージの能力は何もせず静かにしているだけということです。この典型的な顧客は大部分の時間には利用されもしないストレージのパフォーマンスのために60%も余分なパフォーマンスを、ユーザーエクスペリエンスの確保のために購入しないといけないということになるのです。
PernixData FVPの活用
ここで、PernixData FVPが輝きを放ちます。ホストサイドのスケールアウトパフォーマンスを利用することで情報システム部門はホストごとに数万のIOPSという設計を行うことが可能です。ストレージを過剰に購入するコストを抑制し、物理を超えるユーザーエクスペリエンスを提供し、デスクトップあたりのコストを抑えることが可能になります。しかも、仮想マシンや既存のストレージ装置への変更は一切なくこれが実現できるのです。仮想マシンやホストをVDI環境の成長に合わせて追加したい? FVPがあれば、vSphereクラスターがスケールアウトするのに合わせて、ストレージのパフォーマンスも追加が可能なのです。
FVPを利用することで、ホスト側でストレージのパフォーマンスを提供することができ、ストレージ装置は95%の分布でサイジングすることが可能です。全てのWindowsが要求するディスクアクティビティのバースト(ログオン/ログオフストーム、ブートストーム等)はFVPで簡単に取り回すことが可能です。ストレージネットワークと共有ディスク装置のIOPSとスループットの大部分はオフロードされるのです。
PernixData FVP と Lakeside MarketPlace プログラム
PernixData FVPがLakeside SysTrack MarketPlaceプログラムに参画したことをご報告致します。SysTrackの顧客は自身の環境の実際の利用に基づいて生成されたMarketPlaceのデータによって、PernixData FVPがどれだけのコスト削減を実現できるのかの詳細レポートを受け取り、VDI環境に優れたパフォーマンスをもたらすことの保証にすることができます。
VDIの展開を成功させるための最初のステップは既存のエンドユーザーの要件を理解することです。それから、複雑にすることなく最高のユーザーエクスペリエンスを提供しながらそれを拡張できるインフラストラクチャをつくり上げることが続きます。Lakeside SysTrackとPernixData FVPはそれのお手伝いをできるのです。
PernixData FVPによるVDI顧客の成功体験はこちらをクリック、日本語はこちら。
SysTrack管理製品の利用についてはこちらをクリックしてください。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
