本ブログはPernixDataのシステムズエンジニアであるTodd Mace氏のブログの翻訳版です。
記事原文はFVP Linked Clone Optimizations Part 1にて閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
PernixDataはあらゆる異なるタイプのワークロードに対してシームレスな高速化をするという点で業界随一のものを持っています。プラットフォームにおける運用のシンプルさは我々にとっては複雑な機能を提供していないということではありません。事実は真逆で、FVPは非常に複雑なシステムであり、動的に多くのワークロードの属性に適合し、高速化を実現します。よくあるものの一つとして例にあげられるのがHorizon Viewのリンククローンテクノロジーの最適化と高速化です。
我々のリンククローン最適化が優れている点は完全にシームレスであるということです。これは既存のVDI環境の構成を一切変更する必要がないというだけでなく、FVP自身の設定も変える必要がないということです。Horizon View マネージャーや他のHorizon View 製品(例 : ThinApp, ペルソナ管理、コンポーザー、クライアント)への変更はありません。そして、リンククローンがパーシステントモデルなのか、ノンパーシステントモデルなのかということも問題にはなりません。FVPは仮想デスクトップ環境全体を高速化し、最適化します。
仮想デスクトップが多くのディスクで構成されるというのはよくあるケースです。OSディスク、ユーザーデータやプロファイルデータのためのディスク、一時ファイルのためのディスクなどです。仮想デスクトップにどんなに多くのディスクが接続されていても、FVPが仮想マシンからのIOをどのように高速化するか、という点は一切替わりません。FVPのインテリジェンスが自動的にIOがどこから来ており、どのディスクが高速化のためのリソースを必要としているのかを自動的に見極めます。管理者はただ、どのデスクトップ(リンククローン、もしくはフルローン)をFVP Clusterに追加するかを決めるだけで良いのです。これは以下のダイアグラムのようにパーシステントとノンパーシステントのディスクが混在していても構いません。FVPは自動的にデスクトップのクローンの一部のあらゆるパーシステント、ノンパーシステントのディスクからのすべてのI/Oを自動的に高速化します。
上のダイアグラムが表しているようにリンククローン環境は構成によって様々なディスクを包含することが可能です。私が思うに、これが混乱を引き起こしているポイントです。リンククローンをはじめに作成した際、クローンにこれらの異なるディスクが接続され、それぞれが何をするためのものなのか、そして、なぜ別々の機能を持っているのかわからなくなります。どうして一部はパーシステント、そして一部はノンパーシステントなのか? そしてどっちの構成がFVPの高速化にベストなのか?このトピックスについてはパート2のためにとっておきます。そしてこの投稿では、レプリカ(ベース)ディスクについてに終始したいと思っています。
Horizon View環境内において、フルクローンとリンククローンはいずれもOSディスクを保持します、違いはリンククローンはノンパーシステントデルタディスクをデスクトップの変更の記録に利用し、レプリカ(ベース)ディスクは親となるスナップショットであり、永続のイメージとして利用します。このデルタディスクはあらゆるデスクトップの操作について有効になるため、高速化の第一の候補となります。クローンされたデスクトップのReadとWriteを高速化するのに加え、FVPは自動的にリンククローンプール内のレプリカディスクを特定し、すべてのクローンがだた1つだけのコピーであるレプリカディスクのデータを活用するように最適化を実施します。
注意 : FVPに取ってはCitrix社のXenDesktopのテクノロジーも根本的に同じように動作します。違いはレプリカディスクではなく、マスターイメージと呼ばれていることです。
以下のスクリーンショットにあるように、リンククローンが使われている場合、FVPは自動的にレプリカディスク(リンククローンのベースディスク)を高速化リソース上に格納します。それだけではなく、FVPはデスクトップクローンのアクティブなブロックだけを高速化リソース上に格納します。これによりレプリカディスクを高速化リソース上に格納する容量は少なくてすみます。プール内の最初のデスクトップがブートした後、すべてのクローンが共通するブロックを高速化リソース上のレプリカディスクから活用できるようになっています。まだキャッシュされていない他のブロックからリクエストが有った場合、FVPはリクエストされたブロックだけを取得し、すでに作成されているレプリカディスクに追加するだけです。新たに作成されるリンククローンのプールについてもすべて同じです。新しいレプリカディスクが高速化リソース上に新しいリンククローンのプールのベースとして追加されます。これはFVPのUsage タブにおいて、すべてのアクティブなレプリカディスクの合計としてどれだけの高速化リソースが割り当てられているかとして確認ができます。ご想像のとおり、レプリカディスクのアクティブなブロックのみを追加することはメモリを高速化リソースとして利用する場合に非常に大きな効果があります。Windows 7の起動時間が5～7秒というのは稀なことではありません。
FVPはこの最適化をvMotionなどのハイパーバイザーのクラスター操作時も実施します。これはもしもデスクトップクローンが現在のホストから別のホストへ移行した場合でも、デスクトップクローンはFVPのリモートアクセスクラスタリングを利用して、移行前のホストにあるデータにアクセスができることを意味します。これは一時的な状態として発現します。というのも、FVPは自動的に新しく稼働を始めたホスト上の高速化リソース上に新しいレプリカディスクのアクティブブロックを作成するからです。FVPのリモートアクセスクラスタリングと、あらゆる新しいデスクトップクローンの再起動などを通して、新しいホスト上に作成されたレプリカディスクは作成、更新され、効率的にローカルからReadができるようになっていくのです。もしデスクトップクローンがWrite Backモード出会った場合、Writeの高速化はデスクトップクローンの新しいホストへの移行が完了するまで継続します。レプリカディスクの最適化は問題にはなりません。
以下のダイアグラムはレプリカディスクが最初に移行前のホストで作成されてから、最初のデスクトップクローンが新しいホストに移行するまでを表したものです。新しいレプリカディスクの作成が、新しいホストで1回のみ行われるようになっており、それ以降のクローンされたデスクトップはこのディスクを活用することができるようになり、今後のマイグレーションでメリットを得ることができるようになっています。
デスクトップクローンが起動した時、(1)クローンはプール内の接続されたレプリカディスクからブロックをリクエストします。FVPはこのブロックへのリクエストを横取りし、(2)それをFVP Clusterに割り当てられた高速化リソースへとコピーします。この後のすべてのデスクトップクローンのブートはレプリカディスクが格納されたデータストアまではるばるデータを取得しに行く代わりに、高速化リソース上からブロックを読み出します。もし、再構成や再バランス操作が行われ、元のレプリカディスクに変更が生じた場合には、この手順がリンククローンに対して再度最初から実行されます。(3) DRSやHA、もしくは手動のvMotion操作でデスクトップクローンの移行が行われた場合、(4) FVPはデスクトップクローンが以前いたホストにReadのリクエストを送信します。(5) ブロックが新しいホストの高速化リソース上にコピーされ、(6) これ以降のリクエストは新しいローカルホストからの提供になります。この間のすべてのリンククローンの再起動では、すべての共通ブロックを新しいホスト上の高速化リソースへコピーすることになります。
見ていただいたとおり、VDIの観点でFVPはデータセンターに根本的な変化をもたらすことができます。仮想デスクトップを動作させるためだけの環境を別に設計していたような日々はもう過去のものです。FVPはテクノロジーのサイロを破壊し、仮想化管理者にストレージのパフォーマンスの制限を心配する必要のない完全にオンデマンドでスケールするパフォーマンスをお約束するのです。
更に詳しくは以下の｢PernixData FVPをVDIインフラストラクチャで利用する(リンク先は英語)｣もご参照ください。
