Windows Server 2008 R2 SP1で追加されたGPU仮想化「RemoteFX」のアーキテクチャ

　Windows Server 2008 R2 SP1が正式リリースされる前から、何度かRemoteFXに関しては解説を行ってきた。最近になって、RemoteFXの詳細なアーキテクチャに関してマイクロソフトがテクニカルドキュメントで明らかにした。

　そこで、今回は、RemoteFXがどのような仕組みで動作するのかを解説していく。ちなみに、RemoteFXは、グラフィックとUSBの仮想化を行っているが、今回はグラフィックの仮想化を中心にして解説していこう。

　RemoteFXを実際に動かす設定や手順に関しては、以前の記事「Windows Server 2008 R2 SP1が変える仮想環境――RemoteFXを試す」を参考にして欲しい。

■RemoteFXが動作する環境は？

　RemoteFXのアーキテクチャを説明する前に、RemoteFXが動作するグラフィックボードに関して説明していこう。

　まず、現状でRemoteFXが利用できるのは、PCI Express（PCIe）接続などのグラフィックボードだけのようだ。CPUやチップセットに内蔵されたグラフィック機能では、パフォーマンス不足だったり、トラブルが起こったりするようだ。特に、メインメモリをビデオメモリとして利用するGPUでは、RemoteFXは使用できない。

　RemoteFXが使用できるグラフィックボードとして、公式には、AMDのATI Firepro、NvidiaのQuadroなどのプロフェッショナル向けの製品が上げられている。これらのグラフィックボードは高額で、RemoteFXをテストするためだけに購入するのは躊躇してしまう。

　しかし実は、コンシューマ用のグラフィックボードでもRemoteFXは動作する。コンシューマ用のグラフィックボードは、Windows Server 2008 R2 SP1対応のドライバがリリースされておらず、Windows 7 x64版のドライバを使用することになるため、安定性などでトラブルが起こる可能性もあり、実際にRemoteFXの運用を行うときは、プロフェッショナル用のグラフィックボードを用意すべきだろう。しかし、RemoteFXの基本動作をテストしたい、というくらいなら、それほど問題はない。

　ただし、グラフィックボードのインターフェイスには注意が必要だ。高性能なグラフィックボードの多くは、PCIe x16 Gen2を利用する。しかし、サーバーなどでは、PCIe x16を持っていない場合も多い。また、高性能なグラフィックボードは、PCIe x16とは別に補助電源が必要になるが、サーバーでは補助電源が取れないこともある。

　さらに、グラフィックボード自体が巨大なファンを搭載する2スロット占有型も多いし、グラフィックボードの長さも、サーバーに入れるには長くて入らない場合もある。グラフィックボード自体が膨大な電力を消費するために、サーバーの冷却を考え直さなければならない。

　このように、今までのラックマウント型（1U、2Uなど）サーバーに、外付けグラフィックボードを入れてRemoteFXを運用するには、いろいろと問題が多い。

　例えばデルは、RemoteFXに対応したサーバーとしてPowerEdge R710/R610、ブレードサーバーのPowerEdge M610xなどを推奨している。このように、RemoteFXを運用するには、サーバーから考え直す必要があるそうだ。

■RDP 7.1を利用する

　RemoteFXは、サーバー上の仮想マシンに専用のグラフィックドライバをインストールして、仮想マシンからGPUが利用できるようにする。現状では、RemoteFXが利用できる仮想OSとしてはWindows 7 SP1となる。

　また、RemoteFXは、リモートデスクトップのプロトコルとしてRDP 7.1を採用しているため、現状ではクライアント側もWindows 7 SP1だけとなっている（将来的には、Windows Vista/XP用のRDP 7.1がリリースされる可能性もある）。なお、RemoteFXのクライアント側の機能をハードウェアで実現したチップもリリースされているので、シンクライアントでもRemoteFXが使用できる。

　他社のハイパーバイザーでは、1つの仮想マシンがGPUを占有する“GPUのパススルー”といった仕組みを採用しているモノがあった。しかし、RemoteFXは、複数の仮想マシンで１つのGPUを共有することができる。これは、今までのハイパーバイザーから考えると画期的なことだ。

　マイクロソフトでは、1GPUで12台のRemoteFXに対応した仮想マシンが動作できると解説している。これ以上の仮想マシンを動かす場合は、もう1枚GPUを追加することを推奨している。

　また、GPUのビデオメモリのサイズによっても、どのくらいのサイズのディスプレイが何枚サポートされるか決まってくる。このため、GPU側のビデオメモリは、出来るだけ多い方がいい。

　もう1つ制限があるとすれば、RemoteFXはDirectX 9cベースのGPUとして仮想マシンでは認識される。このため、Direct3Dなどの機能は動作するが、DirectX 10.1やDirectX 11などで追加された機能はサポートされていない。つまり、RemoteFXでは、DirectX 11で追加されたDirect Compute（GPUにプログラムを転送して、CPUとは別に処理させる機能）はサポートされていない。

■RemoteFXのアーキテクチャは？

　RemoteFXは、仮想マシン上にGPUを仮想化するRemoteFX 3Dドライバをインストールする。個々の仮想マシン上でのDirectXの処理は、この仮想GPU（vGPU）ドライバであるRemoteFX 3Dが処理をする。

　ペアレントパーティションにインストールされているグラフィックバーチャリゼーションモジュールに、複数の仮想マシン上にインストールされた仮想GPUドライバからのリクエストが集まる。グラフィックバーチャリゼーションモジュールがvGPUのリクエストを集約して、ペアレントパーティーションにインストールされているグラフィックドライバーにわたす。

　GPU側から見れば、ペアレントパーティションにグラフィックバーチャリゼーションモジュールからだけリクエストが来ることになる。これなら、グラフィックボード側に仮想化をサポートするための特別な機能は必要ない。現在、発売されているグラフィックボードがそのまま利用できるのは、メリットが大きい。


Hypre-V環境でRemoteFXを動かす場合のブロック図。Hyper-Vのペアレントパーティーションに仮想GPUからのコマンドを調停する機能と仮想GPUが描画したイメージを圧縮する機能を持つ	RemoteFXを利用するには、各仮想マシン上にRemoteFX対応のvGPUドライバーをインストールする。GPUに対応するすべてのアクセスは、ペアレントパーティーションが管理するRendering、Capturing、and Compression（RCC）とGraphics Virtualizationでまとめられ、物理的なGPUに送られる

仮想マシン上で動作しているアプリケーションは、普通にDirectXやGDIなどを使い画面描画を行う。下層のvGPUドライバは、ペアレントパーティーションのRD Virtual Graphics Managerに転送して、実際の描画を行うGPUに送られる	ペアレントパーティーションのGPUで描画されたイメージは、サーバーにRemoteFX ASICがあれば、ASICを使って符号化するが、ASICが無ければソフトウェアで符号化する。このデータをVMBUSを使って、仮想マシンに送信する。さらに、仮想マシンから、RDP7.1を使ってセッションを張っているクライアントに送信される

　前述しようにRemoteFXは、Windows 7で採用されていたRDP 7.0から、RDP7.1にアップデートされている。RDP7.0では、ビデオ再生などは、ホスト側で処理せずに、クライアント側にMPEGやWMVのビデオフォーマットのまま転送して、クライアント側でデコードして表示している。このため、ビデオなどを表示しても、ホスト側のCPUパワーはほとんど必要なく、ネットワークの帯域もビデオファイルを転送するため、それほど消費しない。

　RDP 7.1は、RDP 7.0に新たにRemoteFX機能を追加しているが、クライアント側では、以前のRDP 7.0とRemoteFXを分離して処理する。最後に、画面出力でRDP 7.0とRemoteFXのイメージを合成する。

　このデスクトップイメージは、ソフトウェアで符号化（Encode）/復号化（Decode）されている。マイクロソフトでは、RemoteFXの発表と同時に、RemoteFXの符号化、復号化をおこなう専用ASICをいくつかのメーカーとリリースすると発表している。RemoteFX用のASICに関しては、まだリリースされていないが、今年の夏までにはリリースされる予定だ。

　RemoteFX専用のASICを利用すれば、CPU側にかかる負荷が小さくなるために、RemoteFXをホスト側、クライアント側で利用してもオーバーヘッドが小さくなる。ただし、RemoteFXは、デスクトップのイメージ全体をRDP 7.1で転送するため、ある程度のネットワーク帯域を消費する。

　このため、現状では、イントラネットなどのLANが前提になっている。インターネットなどを経由したWANでRemoteFXを利用するためには、高速のインターネットアクセス回線が必要になる。

　RDP 7.1は、ネットワーク帯域を消費するデメリットがあるが、RDP 7.0で満足なパフォーマンスで表示できなかったSilverlightやFlashなどのコンテンツを表示することができる。もちろん、SilverlightやFlashなどのビデオコンテンツもリモートのクライアントで表示可能だ。


クライアント側では、GDI、Aero、Windows MediaなどをRDP 7.0で処理し、RemoteFXを別のパスで処理する。さらにRemoteFXの処理は、専用ASICがあればASICを使い、なければソフトウェアで処理する	RemoteFXは、RDP 7.1の中に包含されている。RDP 7.1は、まったく新しいプロトコルというわけではなく、RDP 5、RDP 6.0/6.1、RDP 7.0などのプロトコルに追加されている

　さらに、GPUを使った画面表示が仮想環境でもサポートされる。いくら、DirectX 9cがサポートされるといっても、ゲームソフトなどが、満足のいくスピードで表示されるわけではない。やはり、ローカルPCで動かすのとは異なる。

　RemoteFXでGPU利用を念頭にしているのは、IE9などのGPUを利用したHTML5コンテンツの表示だ。今後、HTML5コンテンツが普及するにつれて、ダイナミックで、高度なグラフィック表示が可能になる。IE9では、こういったコンテンツ表示にGPU（DirectX)を使用しているため、今後VDI（Virtual Desktop Infrastructure）が普及するには、絶対に必要な機能だ。

　将来的には、Windows OSのPCをクライアントとして利用する時には、WPFの描画コマンドを転送するようにして、クライアントPC側のCPU/GPUをより活かした仕組みが必要になるのかもしれない。シンクライアントなどは、RDP 7.1のようなデスクトップイメージの転送を使い、Windows OSのPCはより上位レイヤのコマンドを転送するようになれば、Windows PCとシンクライアントの性能差がはっきりわかるようになるかもしれない。

　もう1つは、DirectX 10.1やDirectX 11などへの対応だろう。より高度なGPUを仮想GPU化出来るようになれば、CPUやメモリなどのCompute部分とGPUなどのディスプレイ部分を完全に切り離すことが出来る。そうなれば、クラウドにCPUやメモリ、ストレージなどを置き、クライアントにはディスプレイ機能だけを持ったクライアントだけで済むようになるかもしれない。

RemoteFXは、マイクロソフトだけでなく、AMD、NVIDIAなど、さまざまなサードパーティがかかわるエコシステムを提供している。特に、シンクライアントなどは、Wyseなどのシンクライアントベンダーがサポートを表明している