■はじめに
今回はAzure上に構築したRemote Desktop Service（以下RDS）の性能向上に関する記事を書きます。
今の時代MicrosoftのVDIと言えばWindows Virtual Desktop（以下WVD）がメインストリームになりつつあり、今後縮小していくと想定されるRDSの記事を書くのは忍びないですが、事例が少ないからこそパブリックに情報を公開するのは大事、と思いテーマとして選びました。
なお、記事の内容はAzure上の環境を対象としておりますが、オンプレミスのRDSに活用できるナレッジも豊富に含みますので、RDS管理者の方々はクラウド/オンプレミス関係なく幅広くご参照ください。
■記事の目的と流れ
この記事はAzure環境上のRDSの性能向上ナレッジの紹介を目的としています。
そのため、RDSやAzureにおける基礎知識は省略しています。（そこまで専門的な用語は使っていませんので、もし知らない用語があれば適宜ググってもらえれば直ぐ情報も見つかるかと思います。）
以降の記事の流れは以下となります。
・想定環境：ナレッジを紹介するにあたり、前提となるRDSの環境を紹介します
・性能向上ナレッジ<Azure領域>：Azure領域において性能向上できるナレッジを記載します。
・性能向上ナレッジ<OS領域>：サーバOS領域において性能向上できるナレッジを記載します。
■想定環境
・環境を構成するサーバは以下とします。
－セッション管理サーバ
－セッション管理DBサーバ
－セッションホストサーバ
－ADサーバ
－プロファイルサーバ
・プロファイルの管理方式は移動ユーザープロファイル方式とし、ユーザーのログインの度にユーザープロファイルをプロファイルサーバから持ってくる形とします。
※プロファイルの方式は性能において非常に重要です。ローカルユーザープロファイル方式、移動ユーザープロファイル方式、固定ユーザープロファイル方式、フォルダリダイレクトの用語を理解したうえで、お使いの環境がどの方式かを理解しましょう。
・構成図を以下記載します。
読者の方はお使いの環境と上記環境を比較し、共通部分を確認したうえで、以下記載のナレッジをご参照いただければと思います。
■性能向上ナレッジ<Azure領域>
ここからはAzure基盤特有のRDS性能向上ポイントを紹介します。
簡単な指標としてコスト/対応工数についても目安の指標を記載していきます。「★」が多い程影響が大きいとお考え下さい。
・Azure基盤側の障害を確認する
コスト：－
対応工数：★
想定される原因：Azure基盤の障害/不具合
ケースとしてAzureの物理基盤側での障害や性能劣化の場合もあります。Azureサポートに遅延発生時間と該当サーバの情報を連絡し、障害発生の有無及び関連性を確認しましょう。
・再デプロイの実施
コスト：－
対応工数：★
想定される原因：Azure基盤の障害/不具合
Azureの物理基盤側で障害がない、としても物理の基盤上での何らかの事象があり性能に影響を及ぼしている可能性もあります。再デプロイはデメリットもなく容易に実行できますが、再起動が発生するためユーザー影響がない時間帯で実行してみましょう。
・NW高速化の有効化
コスト：－
対応工数：★
想定される原因：ユーザプロファイル移動に伴うNW性能不足
Azureの仮想マシンでは高速ネットワークという機能があり、その機能を有効にするだけでVMサイズに応じてNWのスループット上限を引き上げることができます。最近では仮想マシン構築時に自動でオンになっていますが、昔作成したマシン等では無効のままとなっている可能性もあります。注意点として、VMのコア数が4以上でないとできないことや、可用性セットを組んでいるVMの場合同可用性セット全ての高速ネットワークを有効化しなければならない事ご注意ください。高速ネットワークの有効/無効ステータスはAzureポータルネットワークインターフェースの概要から確認可能です。
・ネットワークアダプタのReceive Side Scaling（以下RSS）有効化
コスト：－
対応工数：★
想定される原因：ユーザプロファイル移動に伴うNW性能不足
Azureのネットワークアダプターにおいて、RSSを有効とすることでパケット受信後の処理を複数CPUで分散し性能向上が見込まれる場合があります。NWの一時的な断は発生しますが、追加コストは発生しないためこちらもお試しいただけると良いかと思います。実行コマンドは以下に記載します。
・有効化コマンド
PowerShell を管理者権限で起動して実行ください。
Enable-NetAdapterRSS -Name "AdapterName"・設定確認コマンド
Get-NetAdapterRssName : EthernetInterfaceDescription : Microsoft Hyper-V Network AdapterEnabled : True
上記がEnableとなっていればOKです。
・ディスクの容量アップ
コスト：★★
対応工数：★
想定される原因：ユーザプロファイル移動に伴うNW性能不足
Azureのディスクは使用可能な最大容量に応じてスループットの性能上限が決まっています。セッションホストやプロファイルサーバのディスク容量が小さい場合はご検討ください。拡張はサクッと実行できますが、Azure側だけでなくOS側でも有効にする必要がある点ご注意ください。また、ディスクのコストは基本変動せず追加となるため事前の月額費用の試算はしっかり行いましょう。
・ディスクのSSD化
コスト：★★
対応工数：★
想定される原因：ユーザプロファイル移動に伴うNW性能不足
使用ディスクがHDDで、ネットワークスループットにおいて原因がある場合、ディスクをSSD化してみましょう。StandardSSDだとスループットの変化が少ない場合もあるためPremiumSSDが推奨されますが、こちらもコストはかなり大きくなるため事前の月額費用の試算は忘れずに行いましょう。
・ディスクの管理ディスク化
コスト：★
対応工数：★★
想定される原因：ユーザプロファイル移動に伴うNW性能不足
使用ディスクが非管理ディスクの場合、ストレージアカウントの性能上限に抵触しているかもしれません。サーバディスクが存在する同じストレージアカウントで負荷の高い処理が行われている場合は影響を受けるため、ディスクを別のストレージアカウントにしたり、管理ディスクに移行しましょう。
・セッション管理/データベース/ADのVMサイズアップ
コスト：★★
対応工数：★
想定される原因：サーバのコンピュート性能不足
RDSにおけるセッション管理や認証を司るVMのサイズをアップすることでCPU性能を向上させます。この辺りが遅延の原因となる場合もありますが、ケースとしては少ない気もします。こういう時こそクラウドメリットを活かし一時的なサイズアップを行い改善が見込めなければさっさとサイズを戻し最低限のコストで選択肢をつぶしていきましょう。
・プロファイルサーバ/セッションホストのVMサイズアップ
コスト：★★
対応工数：★
想定される原因：サーバのコンピュート性能不足/サーバのNW性能不足
プロファイルサーバ、セッションホストVMのサイズをアップすることでCPU/NWの性能を向上させます。VMサイズアップを行った場合コンピューティング性能だけでなくNWスループットの上限も引き上げられるため、この2サーバにおいてはプロファイル移動の面でもメリットがあります。
■性能向上ナレッジ：OS領域
続いてはオンプレミスでも適用可能なサーバOS上での改善ポイントを紹介します。筆者がWebでざっと見ても確認できなかった情報もありますし、OS上の設定施策については基本追加コストがかからないため是非ご活用ください。
・ディスク障害を確認する
コスト：－
対応工数：★
想定される原因：サーバのディスク性能不足
ディスクに何らかの障害が起きており、性能に影響があることも可能性はゼロではありません。OSログイン後コマンドプロンプトにて以下コマンドを実行し状態を確認してみましょう。
・実行コマンド
Chkntfs "ドライブレター":
・ボリューム形式の変更
コスト：－
対応工数：★★★
想定される原因：サーバのディスク性能不足
ディスクボリュームの形式をスパンボリュームである場合、ストライプボリュームに変更することでディスクIO性能が改善する場合があります。ただし、ボリューム形式の変更はデータが削除されるため、該当ボリュームのデータ移行やその他設定も再度必要となるため作業量はかなり大きくなります。効果としても明確に見えるような施策ではないため、優先度は低くしたほうが無難かと思います。ボリューム形式の変更はググればバンバン出てくるので割愛します。
・MaxThreadsPerQueueの増加
コスト：－
対応工数：★
想定される原因：プロファイル移動処理時間の長期化
OS上の設定において、プロファイルデータ移動時にSMBリクエストを処理する際のスレッド数の上限値を上げることでキューイング処理数が増加し、速度向上に繋がる可能性があります。
以下設定変更にて適用可能です。設定を適用することで、基本デメリットはありませんが、CPU使用率やメモリ使用量が多少増加します。
・設定変更手順
①プロファイルサーバのレジストリに以下の設定を追加する
キー : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
名称 : MaxThreadsPerQueue
種類 : REG_DWORD
値：デフォルトが20、100～1000に増加することで改善可能性あり、緊急性が高くなければ段階的に数値を上げていく方法が安全かと思います。
②サーバ再起動を行う
・SMB2 Leaseの無効化
コスト：－
対応工数：★
想定される原因：プロファイル移動処理時間の長期化
OS上でOplockと言うクライアントのファイルアクセス時にファイルにキャッシュ使用権の付与/解放を行う排他制御の機能があり、更にこの機能の一部を強化した「SMB2 Lease」を無効にすることでファイル共有アクセスやファイル操作の遅延が改善された場合があるようです。以下手順にて設定変更可能です。設定を変更することで、基本デメリットはありませんが、クライアント内でのキャッシュ利用の効率が若干低下する場合があります。
・設定変更手順
①レジストリに以下の設定を追加する
キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
名前: DisableLeasing
値の種類: REG_DWORD
設定値: 1 (有効: 0, 無効: 1)
②サーバ再起動を行う
・ログオン/ログオフスクリプトの処理見直し
コスト：－
対応工数：★
想定される原因：スクリプトの処理待ちによる処理時間の長期化
エンドユーザーの機能制御のためログオン/ログオフスクリプトを仕込んでいる場合、このスクリプト処理が原因の可能性もあります。大きな処理でなければ影響は低いと思いますが、スクリプトの開始前後に時間を出力するなどして時間の影響を確認してみましょう。
・プロファイル容量の削減
コスト：－
対応工数：★★
想定される原因：プロファイル移動時間の長期化
移動プロファイル方式の場合、プロファイルサーバからセッションホストサーバにファイルを移動するため、単純に考えて移動するファイルを減らすことで起動時間は短縮すると考えられます。ファイル容量削減の方法としては、ユーザビリティとのバランス次第となりますが、xGB以上のファイルはこまめに削除する/ユーザー領域に保管せず別のファイルサーバに保存する、等運用でカバーする方法や、プロファイルサーバ上で、深夜バッチでxGB以上かつy日以上経過したファイルを削除する、といったタスクスケジューラを仕込む方法も有効かと思います。
・プロファイルファイル数の削減
コスト：－
対応工数：★★
想定される原因：プロファイル移動時間の長期化
先に記載したプロファイル容量の削減も有効ですが、こちらも効果は大きいと思います。ユーザープロファイル領域のファイル容量自体は大きくなくても、ファイル数が多いとその分ファイル転送に時間がかかり、起動遅延を引き起こします。よくあるケースとしてはブラウザのキャッシュや認証鍵のファイル数が増加するパターンです。ブラウザの設定として履歴の削除が有効になっていてもキャッシュは移動プロファイル内に保有しているため、プロファイルサーバに保管しているファイル数を確認し、ファイル数が多いディレクトリに応じた手段を打ちましょう。なお、ブラウザキャッシュのファイル数が膨らんでいる原因の場合、ファイルが作成された日時が一定期間以前のものであれば削除するスクリプトを定期的に実行する方法や、もっとシンプルにユーザーのブラウザキャッシュを毎回削除する設定とすることも有効です。
・WindowsUpdate適用パッチのアンインストール
コスト：－
対応工数：★
想定される原因：適用パッチの相性による影響
性能遅延が発生した前後で行ったアップデートが原因である可能性もゼロではありません。優先度は低いですがパッチ適用と性能不足の影響に関連性がありそうであれば社内ポリシーを鑑みて適用パッチをアンインストールすると言った対応も検討ください。
■終わりに
VDIはエンドユーザーが直接使うシステムのため非機能部分の考慮は非常に重要です。
非機能要件はあらゆる要素が関連するため改善策も数多くあるため、策を手当たり次第に実施するのではなく全体を理解したうえで優先度をつけて効果を見ながら対応していきましょう。策の1つや2つで劇的に改善するケースは少ないと思いますが粘り強く対応していけば理解も深まりますしきっといつかは改善する、、、と思います。
そしてこのような管理に疲れた方は多くの部分がマネージドに提供されているWVDの利用を是非ご検討ください。
これだけRDS推ししておいて〆がWVDの紹介・・・スミマセン笑
(この記事が参考になった人の数：2)
読み込み中...