本ブログエントリーはPernixData社の顧客であるNick Casagrande氏がPernixData社のブログに寄せた記事の翻訳版です。
本記事の原文はA VDI view from the trenches: Optimizing Citrix with Zero Wasteで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
編集者による注意事項: この投稿はPernixDataの顧客によるゲスト投稿シリーズの1つです。
著者: Nick Casagrande, Southern Waste Systems
最近、Southern Waste社のCitrix XenDesktop環境にPernixDataのソフトウェアを展開したあと、新しい設計に関連するので、いくつかの考え方とベスト・プラクティスについて書いておくことにしました。
この情報が有用であると嬉しいです。もし追加で質問(コメント)があれば遠慮無く私宛にコンタクトしてください。(訳注: 原文ではNick氏のメールアドレスが記載されていますが、日本語でのお問い合せは一旦 訳者のTwitter へ DMでお問い合わせください。 @pernixdata_netw)
ストレージ要件を決めようとしているとき、実際に必要なストレージのキャパシティを決めることは非常に簡単です。ですが、ストレージのパフォーマンスになるとこれはちょっと大変になります。残念なことに、VMware社のパフォーマンスチャートは情報が多すぎます。基準となるIOPSとストレージレイテンシです。これからだけではベスト・プラクティスは難しいです。あるブロガーはデスクトップごとにX IOPS割り当てなさいというかもしれません。他にはLoginVSIを推奨されるかもしれません。CBRCのようなもので50%ものReadがRAMのキャッシュで削減されるというようなことも言われるかもしれません。(CBRCはリンククローンのVDI仮想マシンから共有で利用可能なブロックをホスト上のRAMに作る機能でReadのスピードを向上させます。)最初の回答(訳注: 固定のIOPSを割り当てる)は各々の会社でタスクワーカーからエグゼクティブまで様々なサーバやデスクトップのワークロードのヴァリエーションがあるため、問題が発生しやすくなります。2つ目のソリューション(訳注: LoginVSI)はログインのシナリオでしか有効ではありません。そして3つ目のCBRCはCitrix XenDesktopをvSphere上で動作させている時には利用ができません。(この機能はHorizon Viewの顧客のためだけのものなのです。)
盲目的にストレージパフォーマンスのために、莫大なお金をローカルストレージやフラッシュストレージ、3rd Partyのキャッシュ機能などに投入することもできます。そうではなく、私の個人的なおすすめは小さな実証実験(POC)を実施して、実際のVDI環境のストレージに必要とされる属性を(PernixDataのような)ツールを使って、監視してみることです。もしLUNがオーバープロビジョンされていて、非常に多くの、そして異なる仮想マシンのワークロードが動作していたり、日中にデフラグが動作していたり、もしくはウィルススキャンがどのような影響があるのか、バックアップは?SQLの処理は? あなたの環境のExchangeのデータベースのメンテナンスは?などを知るためにこれ以上良い方法はありません。これらのデータが有れば、ストレージパフォーマンスについて、しっかりとした決断を下すことが可能です。
レイテンシが高ければ、デスクトップの更新が遅いということを意味します。結果としてエンドユーザーのエクスペリエンスは粗末なものになります。繰り返しとなりますが、PernixData FVP ソフトウェアのような製品を利用すれば、問題を発見するためにクラスタを分けるなどということは必要ありません。(FVPは)ストレージのインテリジェンスを必要とされているホスト内で提供します。後ろにあるストレージではなく、ホストメモリにWriteが書き込まれたタイミングで完了通知を戻します。別の言い方をすればI/Oリクエストはローカル(サーバ内)で処理され、非常に大きくストレージレイテンシを削減できるのです。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
