スケーラビリティに関する注意事項
Session Recordingは、数千の、または数万のセッションを処理する高スケーラブルなシステムです。Session Recordingのインストールと実行のために、Citrix Virtual Apps and DesktopsまたはCitrix DaaS（旧称Citrix Virtual Apps and Desktopsサービス）の実行に必要なハードウェア要件を超えて、さらにリソースを追加する必要はほとんどありません。ただし、多くのセッションを録画する場合は、システムのパフォーマンスを考慮することをお勧めします。または、録画する予定のセッションによって、セッションファイルが大きくなることがあります（たとえば、グラフィックを多用するアプリケーション）。
ここでは、Session Recordingによって高いスケーラビリティを実現し、最低限のコストで録画システムを最大限に活用できる方法について説明します。
Session Recordingのスケーラビリティが高い理由
Session Recordingが同様の他社製品と比べて高いスケーラビリティを提供できるのには、主に2つの理由があります：
-
小さなファイルサイズ
Session Recordingで作成されたセッションの録画ファイルは比較的小さなサイズです。スクリーンスクレイピングによるソリューションで作成された同様のビデオ録画に比べると、けた外れに小さなサイズです。セッションの録画ファイルを転送/格納するのに必要なネットワーク帯域幅、ディスクスペース、ディスクIOPSは通常、同様のビデオファイルの10分の1以下です。
セッションの録画ファイルのサイズが小さいと、ビデオフレームのレンダリングもより高速かつスムースになります。また、録画は無損失で、大半の小さなサイズのビデオ形式で発生しがちな表示の滑らかさの問題もありません。録画の中のテキストは、再生中でも元のセッションと同じくらい読み取りやすい状態です。ファイルサイズの小ささを維持するために、Session Recordingはファイル内でキーフレームを録画しません。Session Recordingでは、ビデオを実行するセッションの録画中にH.264パッケージをドロップできるため、録画ファイルのサイズを小さくすることができます。この機能を使用するには、Session Recording Agentで
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent\DropH264Enabledを1に設定し、［圧縮にビデオコーデックを使用する］ の値を ［領域をアクティブに変更］ に設定します。
-
ファイルの生成に必要な処理が少ない
セッションの録画ファイルには、実質的には本来の形式で抽出されたセッションのICAプロトコルデータが含まれます。ファイルはCitrix Workspaceアプリと通信していたICAプロトコルデータストリームをキャプチャします。リアルタイムでデータを変換するために高価なトランスコードやエンコード用のソフトウェアコンポーネントを実行する必要はありません。VDAのスケーラビリティでは、処理の量を抑えることも重要です。これによって、同じVDAから多くのセッションが録画された場合でも、エンドユーザーエクスペリエンスが維持されます。
また、再生が可能なICA仮想チャネルのみが録画されるため、さらに最適化が促進されます。たとえば、プリンターとクライアントドライブマッピングのチャネルは録画されません。これらのチャネルは、ビデオの再生に何のメリットもなく、大量のデータを生成する可能性があります。
データの入力速度および処理速度の推定
Session Recordingサーバーは、セッションの録画ファイルを一元的に収集する場所です。マルチセッションOS VDAを実行している各マシンでSession Recordingを有効にすると、セッションの録画データをSession Recordingサーバーに送信します。Session Recordingは、大量のデータを処理でき、バーストや障害に対応できます。ただし、1つのサーバーが処理できるデータ量には物理的な限界があります。
各Session Recordingサーバーに送信するデータ量について検討してください。サーバーがデータを処理および保存できる速度を見積もります。受信データを格納する速度がデータ入力速度より高速である必要があります。
データ入力速度を見積もるには、次の計算を行います：
- 録画されたセッションの数に平均セッションサイズを掛けます。
- その計算結果を、セッションを録画する時間で割ります。
たとえば、5,000件のMicrosoft Outlookのセッションの平均サイズが20MBとして、毎営業日に8時間録画するとします。この場合、データの入力速度は約3.5Mbpsです（5,000セッション×20MB÷8時間÷3,600秒）。通常、100Mbps LANに接続され、録画済みデータを格納する十分なディスクスペースがあるSession Recordingサーバーは、データを約5.0Mbpsで処理できます。この速度は、ディスクおよびネットワークIOPSによる物理的な制限に基づく処理速度です。この例では、処理速度（5.0Mbps）は入力速度（3.5Mbps）より高い値であるため、5,000件のOutlookセッションを録画することが可能です。
セッションあたりのデータ量は、録画内容によって大きく異なります。画面の解像度、色深度、グラフィックモードなどの他の要素も影響します。CADが実行されているセッションでは、ユーザーがOutlookでメールを送受信するセッションよりも、大幅に大きなサイズの録画データが生成されることが予想できます。したがって、同じ数でもCADセッションは高い入力速度を必要とし、Session Recordingサーバーの使用率も高くなります。
バーストや障害
前述の例では、シンプルで均一なデータのスループットを想定しましたが、短い時間に高いアクティビティが発生するバーストといわれる状態をシステムが処理する方法については、また異なります。バーストは、すべてのユーザーが朝の同じ時間に一斉にログオンするとき（9時台のラッシュ）に発生する可能性があります。また、Outlookの受信トレイで同じ電子メールを一度に受信した場合にも発生する可能性があります。このような急激な需要には、Session Recordingサーバーの5.0Mbpsという処理速度では対応が不十分になります。
各VDAで実行されているSession Recording Agentは、Microsoftメッセージキュー（MSMQ）を使用して録画済みデータをSession Recordingサーバーに送信します。データは、ストアアンドフォワード方式で送信されます。これは、メールが送信者、メールサーバー、受信者との間で送受信される方法と似たような方式です。Session Recordingサーバーやネットワークがバースト時の大量のデータを処理できない場合、録画データは一時的に保存されます。ネットワークが混雑している場合、データメッセージはVDAの送信キューに一時的に保存されることがあります。もう1つのケースは、データがネットワークを通過したが、ストレージマネージャーが他のメッセージの処理でビジー状態である場合です。この場合、データメッセージはSession Recordingサーバーの受信キューに保存されます。
MSMQはフォールトトレランスメカニズムとしても機能します。Session Recordingサーバーがダウンするかリンクが破損している場合、録画済みデータは各VDAの発信キューにとどまります。障害が解消されると、キューのすべてのデータが一度に送信されます。MSMQにより、セッション録画を中断したりデータを失ったりすることなく、サーバーをオフラインでアップグレードやメンテナンスすることもできます。
MSMQの主な制限は、データメッセージの一時ストレージとしてのディスクスペースが限られていることです。この制限のため、バースト、障害、またはメンテナンスイベントが長引く場合、最終的にデータが失われることがあります。データ損失後も総合的なシステムは機能し続けますが、この状況では個別の録画内でデータの一部が失われます。データが失われたファイルは再生可能ですが、最初に失われたデータの箇所まで進むと再生が停止します。以下の点に注意してください：
-
各サーバー、特にSession Recordingサーバーにディスクスペースを追加してMSMQで使用できるようにすると、バーストや障害時の許容値が上昇します。
-
各Session Recording Agentでメッセージの有効期間を適切なレベルに設定することが重要です（［Session Recording Agentのプロパティ］の ［接続］ タブ）。デフォルト値は、7,200秒（2時間）です。つまり、記録された各データメッセージは、ストレージマネージャーに到達するまでに2時間かかり、その後、ストレージマネージャーがそのメッセージを破棄して録画ファイルに損傷を与えます。利用可能なディスクスペースが増えると（または録画するセッションを削減すると）、この値を増やすことを選択できます。最大値は365日です。
MSMQのその他の制限は、データのバックログが作成されると、データメッセージの読み取りと書き込みのために追加のディスクIOPSが発生するということです。通常、ストレージマネージャーはネットワークから直接データを受信して処理し、データメッセージがディスクに書き込まれることはありません。データを格納するためには、セッションの録画ファイルを追加するためにディスクへの一度の書き込み操作が必要になります。データのバックログが作成された場合、ディスクIOPSが3倍になります。これは、各メッセージがディスクに書き込まれ、ディスクから読み取られ、ファイルに書き込まれる必要があるためです。ストレージマネージャーはIOPSに大幅に影響を受けるため、Session Recordingサーバーの処理速度はメッセージのバックログが消去されるまで低下します。この追加のIOPSの影響を緩和するため、以下の推奨事項を採用します：
-
MSMQがメッセージを格納するディスクは、録画ファイル格納フォルダーとは異なるディスクを使用してください。IOPSバストラフィックが3倍になっても、実際の処理率の低下は深刻なものにはなりません。
-
停止はピーク時以外にだけ計画します。予算の制限によっては、高可用性サーバーの構築で実証済みのアプローチを使用します。このアプローチには、無停電電源装置（UPS）、デュアルNIC、冗長化されたスイッチ、ホットスワップ可能なメモリとディスクの使用が含まれます。
処理能力を重視した設計
セッションの録画データが均一であることは少なく、バーストや障害が発生する可能性があり、メッセージのバックログの消去はIOPSを増加させます。このため、各Session Recordingサーバーは処理能力に余裕をもって設計します。後のセクションで説明するように、サーバーを追加するか既存のサーバーの仕様を改善することで、より多くの処理能力を獲得できます。一般的な目安は、各Session Recordingサーバーを合計処理能力の最大50%で実行することです。前述の例のように、サーバーが5.0Mbpsで処理することができる場合、システムは2.5 Mbpsで実行することを目標にします。1つのSession Recordingサーバーで5,000件のOutlookセッションの録画では3.5Mbpsですが、3,500件のセッションに抑えると約2.5Mbpsになります。
バックログとライブ再生
ライブ再生とは、セッションがアクティブなときに閲覧者がセッションの録画を開いて再生することです。ライブ再生中に、Session Recording Agentがそのセッションのストリーミングモードに切り替わります。録画データは、内部バッファリングなしで、すぐにストレージマネージャーに送信されます。録画ファイルは常に更新され、Playerは引き続きライブセッションからの最新データを取得します。Agentからストレージマネージャーに送信されたデータはMSMQを経由し、前述のキューの規則が適用されます。このシナリオでは、問題が発生する可能性があります。MSMQのバックログが作成されると、ライブ再生で利用可能な新しい録画データは、他のすべてのデータメッセージのようにキューに登録されます。閲覧者がファイルを再生することはできますが、ライブで録画された最新のデータの閲覧には遅延が発生します。ライブ再生が閲覧者にとって重要な機能である場合は、バックログの確率が低くなるように設計してください。環境で処理能力やフォールトトレランスを設計できます。
システムのスケーラビリティ
Session Recordingがセッションのパフォーマンスを低下させたり、録画済みデータのバックログへの応答でセッションを停止させたりすることは決してありません。エンドユーザーエクスペリエンスや単一サーバーのスケーラビリティを維持することが、Session Recordingシステムの設計において何よりも優先されます。録画システムが不可逆的に過負荷になった場合、録画されたセッションのデータは破棄されます。ICAセッションの録画がVDAのパフォーマンスとスケーラビリティに与える影響は大きくありません。影響の大きさは、プラットフォーム、利用可能なメモリ、録画されたセッションの画像の性質によって異なります。以下の構成では、単一サーバーのスケーラビリティへの影響は1〰5%程度と予想されます。つまり、Session Recordingをインストールしない場合に100ユーザーをホストできるサーバーの場合、インストール後は95〜99人のユーザーをホストすることができます：
- マルチセッションOS VDAを実行している8GB RAMの64ビットサーバー
- Office業務アプリケーション（OutlookやExcel）を実行しているすべてのセッション
- アプリケーションの使用が可能で維持される
- すべてのセッションがSession Recordingポリシーの構成に従って録画される
録画されているセッションの数が少ないか、維持されるセッションアクティビティが少なく散発的であれば、影響は大きくありません。多くの場合、スケーラビリティへの影響は無視できる範囲で、サーバーあたりのユーザー密度に変化はありません。前述したように、影響が少ないのは各VDAのSession Recordingコンポーネントの処理要件がシンプルであるためです。録画済みのデータは、ICAセッションスタックから抽出され、そのままMSMQ経由でSession Recordingサーバーに送信されます。コストがかかるデータのエンコードは発生しません。
セッションが録画されていない場合でも、Session Recordingの使用には多少のオーバーヘッドが発生します。特定のサーバーからのセッションを録画しない場合は、そのサーバーでの録画を無効にすることができます。Session Recordingを削除する方法もあります。より影響の少ないアプローチは、［Session Recording Agentのプロパティ］の ［Session Recording］ タブで ［このVDAマシンでセッションを録画する］ チェックボックスをオフにすることです。あとからセッションの録画が必要になった場合、このチェックボックスを再度オンにします。
スループットの測定
セッションの録画データをVDAから送信してSession Recordingサーバーで受信する場合のスループットを測定できます。録画ファイルのサイズ、およびSession Recordingサーバーでディスクスペースが消費される速度を測定するのが、シンプルで効果的なアプローチです。ディスクに書き込まれるデータの量は、生成されるネットワークトラフィックの量をほぼ反映しています。Session Recordingで提供されるカウンターに加えて、Windowsパフォーマンスモニターツール（perfmon.exe）には、監視可能な標準システムカウンターがあります。カウンターは、スループットの測定だけでなく、ボトルネックやシステムの問題を特定するために使用できます。次の表では、最も有用なパフォーマンスカウンターの一部をまとめました。
| パフォーマンスオブジェクト | カウンター名 | 説明 |
|---|---|---|
| Citrix Session Recording Agent | Active Recording Count |
現在、特定のVDAに録画されているセッションの数。 |
| Citrix Session Recording Agent | Bytes read from the Session Recording Driver |
セッションデータ取得に必要なカーネルコンポーネントからの読み取りバイト数です。そのサーバーで録画されているすべてのセッションで単一VDAが生成するデータ量を決定するために役立ちます。 |
| Citrix Session Recordingストレージマネージャー | Active Recording Count |
Session Recordingサーバーを除いてはCitrix Session Recording Agentのカウンターと同様です。現在、すべてのサーバーで録画されているセッションの合計数を示します。 |
| Citrix Session Recordingストレージマネージャー | Message bytes/sec |
すべての録画されたセッションのスループット。ストレージマネージャーがデータを処理する速度を決定するために使用できます。MSMQでメッセージのバックログが作成されている場合は、ストレージマネージャーはフルスピードで動作します。この値は、ストレージマネージャーの最大処理速度を示すために使用することができます。 |
| LogicalDisk | Disk Write Bytes/sec |
ディスクのライトスルーパフォーマンスを測定するために使用できます。これは、Session Recordingサーバーの高スケーラビリティを実現するために重要です。個々のドライブのパフォーマンスも測定することができます。 |
| MSMQキュー | Bytes in Queue |
CitrixSmAudDataメッセージキュー内でバックログが作成されたデータの量を決定するために使用できます。時間の経過とともにこの値が増加した場合、ネットワークから録画データを受信する速度は、ストレージマネージャーがデータを処理できる速度よりも大きくなります。このカウンターは、データバーストや障害の影響を測定するために有用です。 |
| MSMQキュー | Message in Queue |
キュー内のバイト数カウンターとほぼ同じですが、メッセージの数を測定します。 |
| ネットワークインターフェイス | Bytes Total/sec |
リンクの両側で、セッションの録画時に生成されるデータの量を測定するために使用できます。Session Recordingサーバーで測定すると、このカウンターは受信データを受け取る速度を示します。データの処理速度を測定するCitrix Session RecordingストレージマネージャーのMessage bytes/secカウンターとは、対照的なカウンターです。ネットワークの速度がこの値よりも大きい場合は、メッセージがメッセージキューに構築されます。 |
| プロセッサ | % Processor Time |
CPUがボトルネックになる可能性が低い場合でも、この値を監視することは役に立ちます。 |
Session Recordingサーバーのハードウェア
Session Recordingサーバーのハードウェアを慎重に選択することで、展開の処理能力を拡大できます。選択肢は、スケールアップ（各サーバーの処理能力を増やす）かスケールアウト（さらにサーバーを追加する）の2つです。最低限のコストでスケーラビリティを増やすことを念頭に、どちらかを選択します。
スケールアップ
単一のSession Recordingサーバーの場合、予算内で最適なパフォーマンスを確保する次のベストプラクティスを検討してください。このシステムは、ネットワークからディスクへ、録画済みデータの高スループットを確保できるIOPSに依存します。そのため、適切なネットワークやディスクのハードウェアに投資することが重要です。高いパフォーマンスのSession Recordingサーバーの場合、デュアルCPUまたはデュアルコアCPUをお勧めしますが、これを超える仕様にしてもさほどパフォーマンスは上昇しません。64ビットプロセッサをお勧めしますが、x86プロセッサでも問題ありません。4GBのRAMをお勧めしますが、これを超える仕様にしてもパフォーマンスに大幅な変化はありません。
スケールアウト
スケールアップのベストプラクティスを使用しても、多くのセッションを録画する場合、1つのSession Recordingサーバーではパフォーマンスとスケーラビリティに限度があります。負荷に対応するために、追加のサーバーが必要な場合があります。複数のSession Recordingサーバーを異なるマシンにインストールすることで、負荷分散プールとして機能させることができます。このタイプの展開では、Session Recordingサーバーはストレージとデータベースを共有します。負荷を分散するには、Session Recording Agentを負荷分散を担当するロードバランサーに割り当てます。
ネットワークの性能
Session Recordingサーバーに接続するには100Mbpsのネットワークリンクが適しています。ギガビットイーサネット接続ではパフォーマンスが向上するかもしれませんが、100Mbpsのリンクの10倍のパフォーマンスが得られるわけではありません。実際には、スループットの増加量は低下します。
Session Recordingで使用するネットワークスイッチを、使用できるネットワーク帯域幅を求めて競合する可能性のあるサードパーティ製のアプリケーションと共有しないようにします。Session Recordingサーバー専用のネットワークスイッチを用意することが理想的です。ネットワークの混雑がボトルネックであると判明した場合、ネットワークのアップグレードはシステムのスケーラビリティを向上させるうえで比較的安価な方法です。
ストレージ
ディスクとストレージハードウェアへの投資は、サーバーのスケーラビリティにおいて単独で最も重要な要因です。ディスクへのデータの書き込み速度が速いほど、システム全体のパフォーマンスが向上します。ストレージソリューションを選択する場合、読み取りパフォーマンスよりも書き込みパフォーマンスに重点を置いてください。
RAIDまたはSANにデータを保存します。
注：
SMBやNFSなどのファイルベースのプロトコルでNASにデータを格納すると、パフォーマンスとセキュリティ上の問題が発生する可能性があります。最新バージョンのプロトコルを使用してセキュリティ上の問題を回避し、スケールテストを実行して適切なパフォーマンスを確保します。
ローカルドライブを使用する場合、キャッシュメモリが組み込まれたディスクコントローラーを検討してください。キャッシュによって、コントローラーはライトバック中に昇順に並べ替えることができます。これにより、ディスクヘッドの動きを最小限にとどめ、物理ディスクの操作が完了するのを待たずに書き込み操作を完了できます。このため、最小限の追加コストで大幅に書き込みパフォーマンスを向上させることができます。ただしキャッシュを使用する場合、停電時にデータ損失が発生する問題を検討する必要もあります。データとファイルシステムの整合性を確保するために、キャッシュ機能付きディスクコントローラーにバッテリーバックアップ機能を使用することを検討してください。
適切なRAIDストレージソリューションを使用するようにしてください。パフォーマンスと冗長性の要件に対応した、多くのRAIDレベルがあります。次の表は、各RAIDレベルと各標準がSession Recordingにどのように適用されるかを示します。
| RAIDレベル | 種類 | 最小ディスク数 | 説明 |
|---|---|---|---|
| RAID 0 | パリティなしのストライピング設定 | 2 | 冗長性なしの高いパフォーマンスを提供します。いずれかのディスクが失われるとアレイが破損します。RAID 0は、セッションの録画ファイルを格納する低コストソリューションであり、データ損失の影響も抑えられます。さらにディスクを追加することで、簡単にパフォーマンスをスケールアップできます。 |
| RAID 1 | パリティなしのミラーリング設定 | 2 | 1つのディスクではパフォーマンスの向上が見られず、比較的コストの高いソリューションです。高いレベルの冗長性が必要な場合にのみ、このソリューションを使用します。 |
| RAID 3 | 専用パリティありのストライピング設定 | 3 | RAID 5に類似した冗長性傾向で、高い書き込みパフォーマンスを提供します。RAID 3は、ビデオ制作やライブストリーミングアプリケーションで推奨されます。Session Recordingは、この種類のアプリケーションであるため、RAID 3が最も推奨されますが、一般的な選択肢ではありません。 |
| RAID 5 | 分散パリティありのストライピング設定 | 3 | 冗長性のある高い読み取りパフォーマンスを提供しますが、書き込み速度が遅くなります。RAID 5は、汎用用途で最も一般的です。ただし書き込みパフォーマンスが遅いため、Session Recordingには推奨されません。RAID 3は、同程度のコストかつ良好なパフォーマンスで展開できます。 |
| RAID 10 | ミラーリング設定とストライピング設定 | 4 | RAID 0のパフォーマンス特性とRAID 1の冗長性のメリットを提供します。コストの高いソリューションで、Session Recordingには推奨されません。 |
RAID 0とRAID 3が、最も推奨されるRAIDレベルです。RAID 1とRAID 5は一般的な標準ですが、Session Recordingには推奨されません。RAID 10は、パフォーマンス上のいくつかのメリットを提供していますが、コストパフォーマンスは低くなります。
ディスクドライブの種類や仕様を決定します。IDE/ATAドライブや外付けUSBまたはFireWireドライブは、Session Recordingでの使用に適していません。主な選択肢は、SATAかSCSIです。SATAドライブはSCSIドライブと比較して、MB単位のコストが抑えられた十分高い転送速度を提供します。ただし、SCSIドライブはより優れたパフォーマンスを提供し、サーバー展開でより一般的です。サーバーRAIDソリューションは、主にSCSIドライブをサポートしますが、一部のSATA RAID製品も利用可能になりました。ディスクドライブ製品の仕様を評価する場合、ディスクの回転速度および他のパフォーマンス特性を考慮してください。
一日あたり数千のセッションの録画は、相当量のディスクスペースを消費する可能性があるため、総合的な処理能力とパフォーマンスのどちらかを選択する必要があります。前述の例では、毎営業日に8時間、5,000件のOutlookセッションを録画すると、約100GBの記憶域を消費します。10日間の録画（50,000件のセッションの録画ファイル）を格納するには、1,000GB（1TB）が必要です。ディスクスペースに対するこうしたプレッシャーは、古い録画をアーカイブまたは削除する前の保有期間を短縮することで緩和できます。1TBのディスクスペースが利用でき、7日間の保有期間が適切な場合、ディスクスペースの使用は約700GB程度にして、300GBは多忙な日のバッファとして確保します。Session Recordingでは、ファイルのアーカイブや削除がICLDBユーティリティでサポートされています。最短保有期間は2日間です。バックグラウンドタスクをスケジュール設定して、ピーク時以外に1日に1回実行できます。ICLDBコマンドおよびアーカイブについて詳しくは、「データベースレコードの管理」を参照してください。
ローカルドライブやコントローラーを使用する代わりに、ブロックレベルのディスクアクセスベースのSANストレージソリューションを使用できます。Session Recordingサーバーには、ディスクアレイはローカルドライブとして表示されます。SANはセットアップにコストがかかりますが、ディスクアレイが共有されると、管理が簡易化され一元化されというメリットがあります。SANには、ファイバチャネルとiSCSIという2つの主な種類があります。iSCSIは基本的にTCP/IPを介したSCSIで、ギガビットイーサネットの導入以来ファイバチャネルよりも一般的になっています。
データベースのスケーラビリティ
Session Recordingデータベースには録画されたセッションのメタデータのみが格納されるため、このデータベースに送信されるデータ量は少なくなります。セッションの録画ファイル自体は別のディスクに書き込まれます。Session RecordingイベントAPIを使用してセッションに検索可能なイベントを挿入するのでなければ、セッション録画1件につきデータベースに必要な容量は通常1KBのみです。
Microsoft SQL Server 2019、Microsoft SQL Server 2017、Microsoft SQL Server 2016、Microsoft SQL Server 2014、Microsoft SQL Server 2012、およびMicrosoft SQL Server 2008 R2のExpress Editionでは、データベースサイズの上限は10GBです。1件のセッション録画あたり1KBのデータが書き込まれるとすれば、この制限があっても、4百万件のセッションをデータベースでカタログ化できます。Microsoft SQL Serverのほかのエディションではデータベースサイズの制限はなく、使用できるディスク容量によってのみ上限が決定されます。データベース内のセッション数が増加するにつれて、データベースのパフォーマンスと検索速度はごくわずかに低下します。
Session RecordingイベントAPIによるカスタマイズを行わない場合は、録画セッションそれぞれについて、録画開始時に2件、ユーザーがセッションにログオンするときに1件、および録画終了時に1件の、合わせて4件のデータベーストランザクションが生成されます。Session RecordingイベントAPIを使用してセッションをカスタマイズする場合は、検索可能な録画イベントそれぞれについて1件のトランザクションが生成されます。最も基本的な方式で展開したデータベースで、1秒あたり何百件というトランザクションを制御できるため、データベースの処理負荷が高くなる可能性はほとんどありません。影響が十分に小さいため、Citrix Virtual Apps and Desktopsのデータストアデータベースを含めたほかのデータベースと同じSQL Serverで、Session Recordingデータベースを実行できます。
Session Recordingのデータベースで何百万というセッション録画をカタログ化する必要がある場合は、SQL Serverのスケーラビリティに関するMicrosoft社のガイドラインに従います。