この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です
Azure Virtual Machine ではNVIDIA および AMD のGPUを搭載するNシリーズを利用可能です。 GPUの利用シーンはDeep Learning やHigh Performance Computing が主流かと思います。 今回の用途はDeep Learning でもHPC でもなく VDI でのGPU 仮想化です。 Windows Virtual Machine で CAD やGIS など高性能なGPUを利用したいという方に参考になる情報を共有します。
GPU 仮想化を利用する目的はCAD やGIS などアプリケーションの特性上必要であった高性能な物理ワークステーションを仮想化することでVDI のメリットをそれらの業務に適用することだったり、CAD以外でも 性能問題になることが多いCPU リソースについてその処理をGPU にオフロードすることの2点でしょうか。
これまでのオンプレミスの VDI での GPU 仮想化の取り組みではコストパフォーマンスの課題と最新GPUへの追従が難しい（GPUは年単位で著しく性能アップするがオンプレミスでは4-5年単位でのハード更新）課題がありました。 そういう意味では使った分だけコストが発生するパブリッククラウドはコストパフォーマンスを最適化するにふさわしいプラットフォームです。
今回はHost pool や Session host の展開の手順等は省略し、仮想マシンが出来上がったところから紹介します。
今回は1回目のテストということでNV6 シリーズのもっとも安価でスモールな仮想マシンを利用します。 スモールといっても 6 vCPU、56GBメモリを搭載しています。 肝心のGPU はM60 です。 M60 はMaxwell 世代のGPU ですので大分古いです。 Ampere←Volte ← Pascal ← Maxwell なので3世代前のアーキテクチャになります。
リモートデスクトップクライアントから WVD 上の仮想マシンにサインインします。
まずは状態を確認していきます。
システムのプロパティからハードウェアスペックを確認します。 CPU はXeon E5 2690 v3 とHawell 世代です。 GPU 同様、骨董品とまでは言いませんが3世代位古いです。 一言でいえばシングルスレッド処理で新しいCPUと比べて差がでます。世の中のアプリケーションはそれほどスレッド処理（複数CPUに処理を分散する）に最適化されていません。
2.6GHz のクロック数だけ見ると最新世代のCPUと大差ないように見えますがその考えは危険です。 VDI へ移行後、エンドユーザサイドで”遅い”と感じる原因の大半はCPU リソース不足だったりします。
5年位前まではHDD ベースのストレージの遅さが表に立ち、CPUのリソース不足は陰に隠れていました。SSD ベースが当たり前になった現状、CPU がボトルネックになることが多くなっています。 ストレージの処理が早くなった結果、CPUから見るとIO 待ちがは減りますがその分またCPUで処理が必要になります。 CPUでリソース不足があると非常に目立ちます。
ボトルネックも大きく2つにわけられます。 1つはシングルスレッドの処理性能の違いです。例えば3.7GHz のクロックのCPUを搭載するデスクトップ環境をVDI に移行します。 VDIのクロックは2.6GHz です。利用者からはアプリケーションの起動が遅い、バッチ処理的なものが前の環境よりも格段に時間がかかる、とクレームが入ります。 これはシングルスレッドについてVDI側の処理能力が低いという話です。 ここにCPU 世代のギャップも加わると処理時間の差は開きます。 このケースだと仮想マシンに割り当てるvCPU 数を増やしても解決しないのも困りものです。 Azure だと高いクロック(3.7-4.7GHz)のCPU をもつDC シリーズで解決できるとは思います。
ボトルネックの2つ目は仮想マシンが要求するCPUリソースが増えていることです。 10年前ごろのVDI 黎明期は物理1core に 8VM 、CPUクロックでいうと300MHz / VM などの環境も普通にありました。 （当時はWindows XP や 7ということもありましたが）。 一方、Windows 10 になりOffice やブラウザのような一般的なアプリケーションでのGPU処理も増え（VDIではそれはすべてCPUで処理する必要がある）、攻撃方法の多様化に比例するようにセキュリティソリューションも必要なリソースを増やし（4core 環境の20%のリソース消費とかよくありますが約1core分ですよね）、また、物理的なディスプレイの高解像度化・マルチディスプレイ化も進んでいます（解像度が増えれば増えるほど画面転送プロトコルのCPUリソース消費は増える）。
エンドユーザに快適なデスクトップ環境を渡そうと考えると、平均 1,000 MHz / VM がスタートラインとなってきています。 それくらいCPU リソースが準備出来ないとVDI システム全体でCPUリソースが枯渇してしまうわけです。
この話の一番の解決策はパブリッククラウド、特にMicrosoft Azure の利用になると考えています。 Azure ではCPU リソースとメモリリソースについてオーバコミットかけない考えです（ハイパースレッディングはありますが）。 また、豊富な仮想マシンのラインナップは多種多様なワークロードへの対応、将来への変化にも柔軟に対応できるためです。
デバイスマネージャで GPU カードの状態を確認します。Windows 10 に標準で含まれるドライバではないため、Display adapters には M60 が認識されていない状態です。
ということで ドライバをインストールします。 基本的にはMicrosoft Docs に手順等すべて乗っています。
今回はDeep Learning ではなくグラフィック機能を利用するので GRID ドライバをインストールします。 こちらも Microsoft Docs にダウンロードリンク含めて案内があります。
ここで2つ注意事項があります。 1つはNVIDIA のMaxwell 世代（今回のM60もMaxwell）から必要になったライセンスサーバが不要とのこと。これは展開が楽になって良いですね。 2つ目、本当はNvidia 拡張機能を使えばVirtual Machines の展開時に最新版を自動インストール出来るのですが、WVD のhost pool 展開では拡張機能を設定できないので手動でのインストールしか出来ない、ということです。本格利用時はマーケットプレイスのイメージをそのまま使うことはなく別途イメージを作ることになると思えば問題なしです。
ダウンロードしたインストールモジュールを実行します。
展開場所を確認しつつ、”OK”をクリックします。
展開が進みます。
展開が完了すると自動的にインストールアプリケーションが起動します。
NVIDIA software license agreement の内容確認し、”AGREE AND CONTINUE”をクリックします。
”Installation options” ではどんな項目があるかの確認のために”Custom”を選んで”NEXT”で次へ進みます。
Custom するものは無さそうです。
インストールを開始します。
インストールが完了。 OS を再起動する必要があります。
WVD 上のWindows 10 を再起動し、再度リモートデスクトップクライアントからサインインします。
デバイスマネージャーから確認すると”NVIDIA Tesla M60″ が認識できています。OK です。
ドライバが提供する nvidia-smi.exe コマンドからも状態を確認可能です。
GPUメモリの使用状況は以下の部分でわかります。 8192 MiB中181 MiB です。ここはアプリケーションの状況により変動していきます。
アプリケーション毎のGPU メモリは以下のブロックで確認できるのですがすべて N / A なのでドライバに何か問題があるのかもしれません。
タスクマネージャのPerformance でもGPU の状況を確認できます。 以下ではほとんど使われていない状況です。ただ、メモリも0となっているので上のnvidia-smi.exe の結果同様正しく取得できていないようにも見えます。 今回は時間の都合で実施しなかったドライバの最新化、その他トラブルシューティングが必要かもしれません。 なお、別記事となりますがGPU が必要なアプリケーションではこのPerformance が正常に機能することは確認しています。
OSや一部アプリケーションのGPU の利用には設定が必要なことがわかりました。 詳しくはこちら
あとはおなじみのNVIDIA コントロールパネルからの確認です。スクリーンショットは静止画ですが実際には緑色のモデルが回転しています。
昨日の記事でも紹介した Youtube のPlaystation 5 の紹介動画もテストします。
しかし、FPS は14と昨日の28-29の半分です。 スループットも50Mbps と悪くはないのですが昨日よりはよくない。
ただ、すぐあとでは30 FPS 、85.37Mbps なのでインターネットの経路上の通信品質に一時的に左右されたのかもしれません。
しかし、気になるのはEdge でのYoutube 閲覧ではGPU を全くつかっているように見えません。 CPU リソース消費は昨日のテストよりも減っているのでGPUへオフロードされているようにも見えますがちょっとわからないですね。（昨日のテストは4vCPUのB4msで今日は6vCPUです。 CPU性能も違うので昨日80-90%のCPU使用率で今日が40-50%ですがその違いは単純に仮想マシンのCPU 性能だけの可能性もあるかなと）
OSや一部アプリケーションのGPU の利用には設定が必要なことがわかりました。 詳しくはこちら。
Windows Virtual Machine でのNVIDIA のGPU利用について初期セットアップが中心でしたが一通り確認出来ました。 一言でいえばとても簡単でした。 ほかの仮想マシンとの違いはNVIDIA のドライバのインストール作業の有無だけです。 VDI 上で3D CAD を実行したい、ArcGIS のようなGIS アプリケーションを実行したいというニーズは昨今のコロナに起因するリモートワーク環境の必要性に比例して高まっていると思います。 そのような中、パブリッククラウドでは唯一といえる共有リソース型のIaaS 上にWindows 10 を展開可能で、また、VDI 管理基盤を無償提供するWindows Virtual Desktop は有力な選択肢になると思います。
今回の記事はここまで。 次の記事ではこのGPU付仮想マシンで Windows 用のゲーム、MONSTER HUNTER WORLD を動かします。
以上
