VMware Horizonの画面録画機能を触ってみた

はじめに

VMware社が提供するデスクトップ/アプリケーション仮想化製品としてVMware Horizonがありますが、本製品のバージョン8 2106からユーザーの操作画面を録画するVMware Horizon Recordingという機能が実装されました。

当機能の主な目的としてはユーザー操作に対する監査が想定されますが、録画したデータは任意のタイミングで再生できるため、ユーザー環境で発生している問題の再現/トラブルシュートのような使い方もできるかと思います。

本記事では、執筆時点で最新版であるバージョン8 2209におけるHorizon Recording機能の仕組みや各設定、実際のデータサイズ等を確認してみます。

Horizon Recording機能の仕組み

Recording機能について、マニュアルから読み取れる内容をざっくり書き出してみます。

  • Recording用のサーバー/エージェントコンポーネントが存在する
  • Recordingはエージェント側で実行される
  • Recordingデータは特定のデータサイズ(チャンクサイズ)に到達 or 特定の時間経過後にサーバー側に転送される
  • ログオフ後にまとめて転送される形態ではないため、Recording中に何らかの障害が発生した場合でも、障害発生前までに転送済みのRecordingデータは確保される
  • 転送されたデータはサーバー側で処理を行い、MP4形式で指定したフォルダに保存される (暗号化も可能)

【参考】Recording機能のイメージ

チャンクサイズおよび経過時間はそれぞれ任意の値を設定できます。
小さい値を設定することで障害時に取得できない期間を短縮できるため、特に要件等が無ければ短めの方がよいかもしれません。
(デフォルトが最小値なので、基本的にはそのまま利用がよさそうです)

実装方法について

Recording機能の利用には以下コンポーネントが必要です。
VMware社のCustomer Connectよりダウンロード可能です。

  • Horizon Recording Server:レコーディングデータの処理、保存、再生を行うサーバーにインストールを行う
  • Horizon Recording Agent:レコーディングを行うデスクトップにインストールを行う

各モジュールのインストール自体は非常に簡単で、サーバーはインストール先、エージェントはインストール先と紐づけるRecordingサーバーを指定するのみでした。

【参考】Recordingエージェントのインストール画面

※仮想マシンを元に仮想デスクトップを展開する場合は"このマシンはテンプレートです"にチェックを入れます (インスタントクローン等)

Recording Server の主な設定項目について

Recordingデータ関連

サーバー側設定
  • Recordingデータの保持設定 (1日~365日)
    • 特定のデータを自動削除の対象から外すことも可能 (ロック機能)
  • Recordingデータの保存先
    • Recording サーバーのローカル or NTFS共有
  • データファイルの暗号化
    • データがMP4ではなくbin形式で保存され、再生はWebUIでのみ可能となる
エージェント側設定
  • チャンクサイズ (5MB~50MB)
  • アップロード間隔 (5分~60分)

Recording対象関連

接続元ベースでの制御
  • ローカルセッションの記録
    • 接続サーバーから仲介されたセッションを記録
  • リモートセッションの記録
    • UAGから仲介されたセッションを記録
ユーザーベースでの制御
  • 記録するグループ
    • ActiveDirectoryのユーザーグループに所属しているユーザーがログオンした際に記録する

【参考】Recording対象指定例

Recordingデータについて

取得したデータはWebUI上の"ダッシュボード"に一覧化されます。
"名前"列のユーザー名をクリックすることで、Recordingデータを再生することができます。


実際のRecordingデータがどのくらいのサイズとなるか、2ケースに分けて確認してみました。

No. 主な操作 録画時間 録画サイズ フレームレート データサイズ
フォルダ/ブラウザ推移、テキスト編集等の一般的な操作(常時)  2分57秒 1920x1200 7.48 / 秒 5.38MB
ログオフ関連以外の操作なし 2分57秒 1920x1200 0.81 / 秒 306.9KB


比較してみると、操作のあり/なしでデータサイズにかなりの差が出る結果となりました。
WebUI上で対象のRecordingデータを確認してみると、無操作期間は"アイドル状態"として扱われているため、その期間中はRecordingデータの更新が抑えられているのかもしれません。

【参考】アイドル状態 (シークバーがグレーアウトされている範囲)

データ保存領域のサイジングを行う際は、実際の利用状況に近しい形で測定した上で最終的な数字に落とし込む必要がありそうです。

おわりに

余談になりますが、Recordingサーバは4vCPU/8GBメモリで2,000のアクティブRecordingに対応しているようです。

個人的にはかなり要求が少ない印象を受けましたが、このあたりは実環境で動作を見てみないと分からないところもあるので、あらかじめ増設分の余裕を見込んでおく方がよいかと思います。
ロードバランサーにも対応しているとのことで、スケールアウト観点でも検討できそうですね。

ご興味がある方、機会がある方は触ってみてはいかがでしょうか。

執筆担当者プロフィール
曽我 剛志

曽我 剛志(日本ビジネスシステムズ株式会社)

ハイブリッドクラウド本部に所属。 仮想化技術を中心に、設計・構築、導入支援等を行ってきました。 最近はセキュリティ分野に触手を伸ばしています。

担当記事一覧