スケーラビリティに関する考慮事項
Session Recordingは、数千から数万のセッションを処理できる、非常にスケーラブルなシステムです。Session Recordingのインストールと実行には、Citrix Virtual Apps and Desktops™またはCitrix DaaS（旧称Citrix Virtual Apps and Desktops service）の実行に必要なリソース以外に、ほとんど追加のリソースは必要ありません。ただし、多数のセッションを記録する予定がある場合、または記録する予定のセッションが大きなセッションファイル（グラフィックを多用するアプリケーションなど）になる可能性がある場合は、システムのパフォーマンスを考慮することをお勧めします。
この記事では、Session Recordingがいかに高いスケーラビリティを実現しているか、そして最小限のコストで録画システムを最大限に活用する方法について説明します。
Session Recordingのスケーラビリティが高い理由
競合製品と比較してSession Recordingのスケーラビリティが高い主な理由は2つあります。
-
小さいファイルサイズ
Session Recordingで作成された記録済みセッションファイルは、非常にコンパクトです。これは、スクリーンキャプチャを行うソリューションで作成された同等のビデオ録画よりも、何桁も小さくなります。記録済みセッションファイルを転送/保存するために必要なネットワーク帯域幅、ディスク容量、およびディスクIOPSは、通常、同等のビデオファイルの少なくとも10分の1です。
記録済みセッションファイルのサイズが小さいということは、ビデオフレームのレンダリングがより高速かつスムーズになることを意味します。また、録画はロスレスであり、ほとんどのコンパクトなビデオ形式でよく見られるピクセル化もありません。録画内のテキストは、元のセッションと同様に再生中に読みやすくなっています。ファイルサイズを小さく保つため、Session Recordingはファイル内にキーフレームを記録しません。Session Recordingは、ビデオが実行されているセッションを記録する際にH.264パッケージをドロップできるため、記録ファイルサイズを削減できます。この機能を使用するには、Session Recordingエージェントで
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent\DropH264Enabledを1に設定し、Use video codec for compressionの値をFor actively changing regionsに設定します。
-
ファイル生成に必要な処理が少ない
記録済みセッションファイルには、ネイティブ形式で仮想的に抽出されたセッションのICA®プロトコルデータが含まれています。このファイルは、Citrix Workspace™アプリとの通信に使用されるICAプロトコルデータストリームをキャプチャします。リアルタイムでデータの形式を変更するために、高価なトランスコーディングまたはエンコーディングソフトウェアコンポーネントを実行する必要はありません。処理量が少ないことは、VDAのスケーラビリティにとっても重要です。これにより、同じVDAから多数のセッションが記録される場合でも、エンドユーザーエクスペリエンスが維持されます。
さらに、再生可能なICA仮想チャネルのみが記録されるため、さらなる最適化が実現されます。たとえば、プリンターチャネルやクライアントドライブマッピングチャネルは記録されません。これらのチャネルは、ビデオ再生に何のメリットもなく大量のデータを生成する可能性があります。
データ入力および処理レートの見積もり
Session Recordingサーバーは、記録済みセッションファイルの中央収集ポイントです。Session Recordingが有効になっているマルチセッションOS VDAを実行している各マシンは、記録済みセッションデータをSession Recordingサーバーに送信します。Session Recordingは大量のデータを処理でき、バーストや障害にも耐えられます。しかし、1台のサーバーが処理できるデータ量には物理的な限界があります。
各Session Recordingサーバーに送信するデータ量を考慮してください。サーバーがデータを処理および保存できる速度を見積もってください。システムが受信データを保存できる速度は、データ入力速度よりも速くなければなりません。
データ入力レートを推定するには、次の計算を実行します。
- 記録されたセッション数に平均セッションサイズを掛けます。
- その積をセッションを記録している時間で割ります。
例えば、8時間の勤務時間中に、それぞれ20 MBのMicrosoft Outlookセッションを5,000回記録する場合があります。この場合、データ入力レートは約3.5 Mbpsです。(5,000セッション × 20 MB ÷ 8時間 ÷ 3,600秒/時間)。記録されたデータを保存するのに十分なディスク容量を持つ100 Mbps LANに接続された一般的なSession Recordingサーバーは、約5.0 Mbpsでデータを処理できます。このレートは、ディスクおよびネットワークIOPSによって課される物理的制限に基づく処理レートです。この例では、処理レート (5.0 Mbps) が入力レート (3.5 Mbps) よりも高いため、5,000のOutlookセッションを記録することは実現可能です。
セッションあたりのデータ量は、記録される内容によって大きく異なります。画面解像度、色深度、グラフィックモードなどの他の要因も影響します。CADが実行されているセッションは、ユーザーがOutlookでメールを送受信するセッションよりもはるかに大きな記録を生成する可能性があります。したがって、同数のCADセッションを記録すると、高い入力レートが生成され、より多くのSession Recordingサーバーを使用する必要がある場合があります。
バーストと障害
前の例では、データの単純な均一スループットを想定していますが、バーストとして知られる短期間のより高いアクティビティにシステムがどのように対処するかは説明していません。バーストは、朝にすべてのユーザーが同時にログオンする「9時のラッシュ」として知られる状況で発生する可能性があります。また、Outlookの受信トレイに同じメールが一度に届いたときにも発生する可能性があります。Session Recordingサーバーの5.0 Mbpsの処理レートは、この突然の需要に対処するには非常に不十分です。
各VDAで実行されているSession Recordingエージェントは、Microsoft Message Queuing (MSMQ) を使用して、記録されたデータを中央のSession Recordingサーバーで実行されているStorage Managerに送信します。データは、送信者、メールサーバー、受信者の間でメールが配信されるのと同様に、ストアアンドフォワード方式で送信されます。Session Recordingサーバーまたはネットワークがバースト時の高いデータレートを処理できない場合、記録されたデータは一時的に保存されます。ネットワークが混雑している場合、データメッセージはVDAの送信キューに一時的に保存されることがあります。もう1つのケースは、データがネットワークを通過したが、Storage Managerが他のメッセージの処理でビジーである場合です。この場合、データメッセージはSession Recordingサーバーの受信キューに保存されます。
MSMQはフォールトトレランスメカニズムとしても機能します。Session Recordingサーバーがダウンしたり、リンクが切断されたりした場合、記録されたデータは各VDAの送信キューに残ります。障害が修正されると、キューに入れられたすべてのデータがまとめて送信されます。MSMQを使用すると、セッション記録を中断したりデータを失ったりすることなく、アップグレードやメンテナンスのためにサーバーをオフラインにすることもできます。
MSMQの主な制限は、データメッセージの一時保存用のディスク容量が有限であることです。この制限により、データが最終的に失われるまでにバースト、障害、またはメンテナンスイベントがどれくらいの期間続くことができるかが決まります。データ損失後もシステム全体は継続できますが、この状況では、個々の記録にデータのチャンクが欠落しています。データが欠落しているファイルは再生可能ですが、データが最初に失われた時点までしか再生できません。以下に注意してください。
-
各サーバー、特にSession Recordingサーバーにディスク容量を追加し、それをMSMQで利用できるようにすることで、バーストや障害に対する耐性を高めることができます。
-
各Session Recordingエージェントのメッセージライフ設定を適切なレベルに構成することが重要です（Session Recordingエージェントのプロパティの接続タブ）。デフォルト値は7,200秒（2時間）です。これは、各記録されたデータメッセージがStorage Managerに到達するまでに2時間の猶予があり、それを過ぎるとStorage Managerがメッセージを破棄し、記録ファイルを破損することを意味します。より多くのディスク容量が利用できる場合（または記録するセッションが少ない場合）、この値を増やすことを選択できます。最大値は365日です。
MSMQのもう1つの制限は、データがバックログされると、データメッセージの読み書きのためにキューで追加のディスクIOPSが発生することです。通常、Storage Managerは、データメッセージがディスクに書き込まれることなく、ネットワークから直接データを受信および処理します。データの保存には、記録されたセッションファイルに追記する単一のディスク書き込み操作が含まれます。データがバックログされると、ディスクIOPSは3倍になります。各メッセージはディスクに書き込まれ、ディスクから読み取られ、ファイルに書き込まれる必要があります。Storage ManagerはIOPSに大きく依存しているため、メッセージのバックログがクリアされるまでSession Recordingサーバーの処理レートが低下します。この追加のIOPSの影響を軽減するには、次の推奨事項を採用してください。
-
MSMQがメッセージを保存するディスクが、記録ファイルストレージフォルダーとは異なることを確認してください。IOPSバストラフィックが3倍になったとしても、実際の処理レートの低下はそれほど深刻ではありません。
-
停止はオフピーク時のみに計画してください。予算の制約に応じて、高可用性サーバーを構築するための認識されたアプローチに従ってください。これらのアプローチには、無停電電源装置 (UPS)、デュアルNIC、冗長スイッチ、ホットスワップ可能なメモリとディスクの使用が含まれます。
予備容量を考慮した設計
記録されたセッションデータのデータレートは均一ではない可能性が高く、バーストや障害が発生する可能性があり、メッセージのバックログをクリアするにはIOPSのコストがかかります。このため、各Session Recordingサーバーは十分な予備容量を持つように設計してください。後続のセクションで説明するように、サーバーを追加したり、既存のサーバーの仕様を改善したりすることで、常に余分な容量が得られます。一般的な経験則として、各Session Recordingサーバーは総容量の最大50%で稼働させるべきです。前述の例では、サーバーが5.0 Mbpsを処理できる場合、システムは2.5 Mbpsのみで稼働するように目標を設定します。1つのSession Recordingサーバーで3.5 Mbpsを生成する5,000のOutlookセッションを記録する代わりに、約2.5 Mbpsのみを生成する3,500のセッションに減らしてください。
バックログとライブ再生
ライブ再生とは、レビュー担当者がセッションがアクティブな間に再生のためにセッション記録を開くことです。ライブ再生中、担当のSession Recordingエージェントはそのセッションに対してストリーミングモードに切り替わります。記録データは内部バッファリングなしでStorage Managerに即座に送信されます。記録ファイルは常に更新されるため、プレーヤーはライブセッションからの最新データを継続的に受け取ることができます。ただし、エージェントからStorage Managerに送信されるデータはMSMQを介しているため、前述のキューイングルールが適用されます。このシナリオでは問題が発生する可能性があります。MSMQがバックログ状態になると、ライブ再生で利用可能な新しい記録データは、他のすべてのデータメッセージと同様にキューに入れられます。レビュー担当者は引き続きファイルを再生できますが、最新のライブ記録データの表示は遅延します。ライブ再生がレビュー担当者にとって重要な機能である場合、バックログの発生確率を低く抑えるようにしてください。デプロイメントに予備容量とフォールトトレランスを設計できます。
システムのスケーラビリティ
Session Recordingは、セッションのパフォーマンスを低下させたり、記録データのバックログに応じてセッションを停止させたりすることはありません。エンドユーザーエクスペリエンスとシングルサーバーのスケーラビリティを維持することは、Session Recordingシステムの設計において最も重要です。記録システムが回復不能なほど過負荷になった場合、記録されたセッションデータは破棄されます。ICAセッションの記録は、VDAのパフォーマンスとスケーラビリティにほとんど影響を与えません。影響の大きさは、プラットフォーム、利用可能なメモリ、および記録されるセッションのグラフィックの性質によって異なります。以下の構成では、シングルサーバーのスケーラビリティへの影響は1%から5%の間と予想されます。言い換えれば、Session Recordingがインストールされていないサーバーが100ユーザーをホストできる場合、インストール後は95～99ユーザーをホストできます。
- マルチセッションOS VDAを実行する8 GB RAM搭載の64ビットサーバー
- OutlookやExcelなどのOffice生産性向上アプリケーションを実行するすべてのセッション
- アプリケーションの使用がアクティブかつ持続的であること
- Session Recordingポリシーで構成されているとおりにすべてのセッションが記録されること
記録されるセッションが少ない場合や、セッションアクティビティが持続的でなく散発的である場合、影響は少なくなります。多くの場合、スケーラビリティへの影響はごくわずかで、サーバーあたりのユーザー密度は変わりません。前述のとおり、影響が少ないのは、各VDA上のSession Recordingコンポーネントの処理要件が単純であるためです。記録データはICAセッションスタックから抽出され、MSMQを介してSession Recordingサーバーにそのまま送信されます。データの高価なエンコードは行われません。
セッションが記録されていない場合でも、Session Recordingを使用することにはわずかなオーバーヘッドがあります。特定のサーバーからセッションを記録しない場合は、そのサーバーでの記録を無効にできます。Session Recordingを削除するのも一つの方法です。より侵襲性の低いアプローチは、Session Recording Agent PropertiesのSession RecordingタブにあるこのVDAマシンでセッション記録を有効にするチェックボックスをオフにすることです。将来的にセッション記録が必要になった場合は、このチェックボックスを再度オンにしてください。
スループットの測定
送信元のVDAから受信側のSession Recordingサーバーへの記録されたセッションデータのスループットを測定できます。簡単で効果的なアプローチは、記録ファイルのサイズと、Session Recordingサーバー上のディスクスペースが消費される速度を監視することです。ディスクに書き込まれるデータ量は、生成されるネットワークトラフィック量と密接に相関しています。Windowsパフォーマンスモニターツール (perfmon.exe) には、Session Recordingによって提供されるいくつかのカウンターに加えて、監視できる標準システムカウンターがあります。カウンターは、スループットの測定、ボトルネックとシステム問題の特定に使用できます。次の表は、最も有用なパフォーマンスカウンターの一部を示しています。
| パフォーマンスオブジェクト | カウンター名 | 説明 |
|---|---|---|
| Citrix Session Recording Agent | Active Recording Count |
特定のVDAで現在記録されているセッションの数。 |
| Citrix Session Recording Agent | Bytes read from the Session Recording Driver |
セッションデータの取得を担当するカーネルコンポーネントから読み取られたバイト数。単一のVDAがそのサーバーで記録されたすべてのセッションに対して生成するデータ量を判断するのに役立ちます。 |
| Citrix Session Recording Storage Manager | Active Recording Count |
Session Recordingサーバーを除き、Citrix Session Recordingエージェントカウンターと同様です。すべてのサーバーで現在記録されているセッションの総数を示します。 |
| Citrix Session Recording Storage Manager | Message bytes/sec |
記録されたすべてのセッションのスループット。Storage Managerがデータを処理する速度を判断するために使用できます。MSMQにメッセージがバックログされている場合、Storage Managerはフルスピードで実行されます。この値は、Storage Managerの最大処理速度を示すために使用できます。 |
| LogicalDisk | Disk Write Bytes/sec |
ディスクの書き込みスループットパフォーマンスを測定するために使用できます。これは、Session Recordingサーバーの高いスケーラビリティを達成するために重要です。個々のドライブのパフォーマンスも監視できます。 |
| MSMQ Queue | Bytes in Queue |
CitrixSmAudDataメッセージキューにバックログされているデータ量を判断するために使用できます。この値が時間とともに増加する場合、ネットワークから受信される記録データの速度は、Storage Managerがデータを処理できる速度よりも大きいことを意味します。このカウンターは、データバーストや障害の影響を監視するのに役立ちます。 |
| MSMQ Queue | Message in Queue |
キュー内のバイト数カウンターに似ていますが、メッセージ数を測定します。 |
| Network Interface | Bytes Total/sec |
セッションが記録されるときにどれくらいのデータが生成されるかを観察するために、リンクの両側で測定するために使用できます。Session Recordingサーバーで測定された場合、このカウンターは受信データが受信される速度を示します。データの処理速度を測定するCitrix Session Recording Storage Manager Message bytes/secカウンターとは対照的です。ネットワーク速度がこの値よりも大きい場合、メッセージはメッセージキューに蓄積されます。 |
| Processor | % Processor Time |
CPUがボトルネックになる可能性は低いですが、監視する価値があります。 |
セッションレコーディング サーバーハードウェア
Session Recording サーバーのハードウェアを慎重に選択することで、展開の容量を増やすことができます。選択肢は2つあります。スケールアップ（各サーバーの容量を増やす）とスケールアウト（サーバーを追加する）です。どちらの選択肢を選ぶにしても、目標は最小限のコストでスケーラビリティを向上させることです。
スケールアップ
単一のSession Recordingサーバーを検討する際は、利用可能な予算で最適なパフォーマンスを確保するために、以下のベストプラクティスを考慮してください。システムは、ネットワークからディスクへの記録データの高スループットを保証できるIOPSに依存します。そのため、適切なネットワークおよびディスクハードウェアに投資することが重要です。高性能なSession Recordingサーバーには、デュアルCPUまたはデュアルコアCPUが推奨されますが、それ以上のスペックにしてもほとんどメリットはありません。64ビットプロセッサアーキテクチャが推奨されますが、x86プロセッサタイプも適しています。4 GBのRAMが推奨されますが、これもまた、それ以上追加してもほとんどメリットはありません。
スケールアウト
最高のスケールアッププラクティスを適用しても、多数のセッションを記録する際に単一のSession Recordingサーバーで達成できるパフォーマンスとスケーラビリティには限界があります。負荷に対応するために、追加のサーバーが必要になる場合があります。Session Recordingサーバーをロードバランシングプールとして機能させるために、異なるマシンに複数のSession Recordingサーバーをインストールできます。このタイプの展開では、Session Recordingサーバーはストレージとデータベースを共有します。負荷を分散するには、Session Recordingエージェントをワークロード分散を担当するロードバランサーにポイントします。
ネットワーク容量
100 Mbpsのネットワークリンクは、Session Recordingサーバーの接続に適しています。ギガビットイーサネット接続はパフォーマンスを向上させる可能性がありますが、100 Mbpsリンクの10倍のパフォーマンスが得られるわけではありません。実際には、スループットの向上はそれほど大きくありません。
Session Recordingで使用されるネットワークスイッチが、利用可能なネットワーク帯域幅を競合する可能性のあるサードパーティアプリケーションと共有されていないことを確認してください。理想的には、ネットワークスイッチはSession Recordingサーバー専用であるべきです。ネットワークの輻輳がボトルネックであることが判明した場合、ネットワークのアップグレードはシステムの拡張性を高める比較的安価な方法です。
ストレージ
ディスクおよびストレージハードウェアへの投資は、サーバーのスケーラビリティにおいて最も重要な単一の要素です。データがディスクに書き込まれる速度が速いほど、システム全体のパフォーマンスは向上します。ストレージソリューションを選択する際は、読み取りパフォーマンスよりも書き込みパフォーマンスに注目してください。
データをRAIDまたはSANに保存します。
注:
SMBやNFSなどのファイルベースプロトコルに基づくNASにデータを保存すると、パフォーマンスとセキュリティに影響を与える可能性があります。セキュリティ上の問題を回避し、適切なパフォーマンスを確保するためにスケールテストを実行するには、最新バージョンのプロトコルを使用してください。
ローカルドライブのセットアップでは、内蔵キャッシュメモリを備えたディスクコントローラーを目指してください。キャッシングにより、コントローラーはライトバック中にエレベーターソートを使用できます。これにより、ディスクヘッドの移動が最小限に抑えられ、物理ディスク操作の完了を待たずに書き込み操作が完了します。これにより、最小限の追加コストで書き込みパフォーマンスを大幅に向上させることができます。ただし、キャッシングは停電後のデータ損失の問題を引き起こします。データとファイルシステムの整合性を確保するために、キャッシングディスクコントローラー用のバッテリーバックアップ設備を検討してください。
適切なRAIDストレージソリューションの使用を検討してください。パフォーマンスと冗長性の要件に応じて、利用可能なRAIDレベルは多数あります。以下の表は、各RAIDレベルと、各標準がセッション録画にどの程度適用可能かを示しています。
| RAIDレベル | タイプ | 最小ディスク数 | 説明 |
|---|---|---|---|
| RAID 0 | パリティなしのストライピングセット | 2 | 高いパフォーマンスを提供しますが、冗長性はありません。いずれかのディスクが失われると、アレイが破壊されます。RAID 0は、データ損失の影響が低い録画セッションファイルを保存するための低コストソリューションです。ディスクを追加することでパフォーマンスを簡単にスケールアップできます。 |
| RAID 1 | パリティなしのミラーリングセット | 2 | 1つのディスクと比較してパフォーマンスの向上はなく、比較的高価なソリューションです。高いレベルの冗長性が必要な場合にのみ、このソリューションを使用してください。 |
| RAID 3 | 専用パリティ付きストライピングセット | 3 | RAID 5と同様の冗長性特性を持つ高い書き込みパフォーマンスを提供します。RAID 3は、ビデオ制作およびライブストリーミングアプリケーションに推奨されます。セッション録画もこの種のアプリケーションであるため、RAID 3が最も強く推奨されますが、一般的ではありません。 |
| RAID 5 | 分散パリティ付きストライピングセット | 3 | 冗長性のある高い読み取りパフォーマンスを提供しますが、書き込みパフォーマンスが遅くなるという犠牲を伴います。RAID 5は一般的な用途で最も普及していますが、書き込みパフォーマンスが遅いため、セッション録画には推奨されません。RAID 3は同程度のコストで、より優れた書き込みパフォーマンスで展開できます。 |
| RAID 10 | ミラーリングセットとストライピングセット | 4 | RAID 0のパフォーマンス特性とRAID 1の冗長性メリットを提供します。セッション録画には推奨されない高価なソリューションです。 |
RAID 0とRAID 3が最も推奨されるRAIDレベルです。RAID 1とRAID 5は一般的な標準ですが、セッション録画には推奨されません。RAID 10はいくつかのパフォーマンス上の利点を提供しますが、追加の利得に対しては高価すぎます。
ディスクドライブの種類と仕様を決定します。IDE/ATAドライブ、外部USBドライブ、またはFirewireドライブは、セッション録画での使用には適していません。主な選択肢はSATAとSCSIです。SATAドライブは、SCSIドライブと比較して、MBあたりのコストを抑えながら、かなり高い転送速度を提供します。しかし、SCSIドライブはより優れたパフォーマンスを提供し、サーバー展開でより一般的です。サーバーRAIDソリューションは主にSCSIドライブをサポートしていますが、一部のSATA RAID製品も現在利用可能です。ディスクドライブ製品の仕様を評価する際には、ディスクの回転速度やその他のパフォーマンス特性を考慮してください。
1日あたり数千のセッションを録画すると、大量のディスク容量を消費する可能性があるため、全体的な容量とパフォーマンスのどちらかを選択する必要があります。前の例では、8時間の勤務時間中に5,000のOutlookセッションを録画すると、約100 GBのストレージ容量を消費します。10日分の録画（つまり50,000の録画セッションファイル）を保存するには、1,000 GB（1 TB）が必要です。このディスク容量への圧迫は、古い録画をアーカイブまたは削除する前に保持期間を短縮することで軽減できます。1 TBのディスク容量が利用可能な場合、7日間の保持期間は妥当であり、ディスク容量の使用量が約700 GBに保たれ、300 GBが忙しい日のためのバッファとして残ります。セッション録画では、ICLDBユーティリティを使用してファイルのアーカイブと削除がサポートされています。最小保持期間は2日間です。1日に1回、オフピーク時にバックグラウンドタスクを実行するようにスケジュールできます。ICLDBコマンドとアーカイブの詳細については、「データベースレコードの管理」を参照してください。
ローカルドライブとコントローラーを使用する代わりに、ブロックレベルのディスクアクセスに基づくSANストレージソリューションを使用する方法があります。セッション録画サーバーにとって、ディスクアレイはローカルドライブとして表示されます。SANはセットアップに費用がかかりますが、ディスクアレイが共有されるため、簡素化された一元管理という利点があります。SANには、Fibre ChannelとiSCSIの2つの主要なタイプがあります。iSCSIは本質的にTCP/IP上のSCSIであり、Gbイーサネットの導入以来、Fibre Channelよりも人気を集めています。
データベースのスケーラビリティ
データベースには録画されたセッションに関するメタデータのみが保存されるため、セッション録画データベースに送信されるデータ量は少量です。録画されたセッションのファイル自体は、別のディスクに書き込まれます。通常、各録画セッションはデータベース内で約1 KBのスペースしか必要としません。ただし、セッションに検索可能なイベントを挿入するためにSession Recording Event APIが使用される場合は除きます。
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では、データベースサイズが10 GBに制限されています。録画セッションあたり1 KBの場合、データベースは約4,000,000セッションをカタログ化できます。Microsoft SQL Serverの他のエディションにはデータベースサイズの制限はなく、利用可能なディスク容量によってのみ制限されます。データベース内のセッション数が増加しても、データベースのパフォーマンスと検索速度の低下はごくわずかです。
Session Recording Event APIを介してカスタマイズを行わない場合、各録画セッションは4つのデータベーストランザクションを生成します。録画開始時に2つ、ユーザーが録画中のセッションにログオンしたときに1つ、録画終了時に1つです。Session Recording Event APIを使用してセッションをカスタマイズする場合、記録された検索可能なイベントごとに1つのトランザクションが生成されます。最も基本的なデータベース展開でも1秒あたり数百のトランザクションを処理できるため、データベースへの処理負荷が問題になる可能性は低いでしょう。その影響は非常に軽微であるため、セッション録画データベースは、Citrix Virtual Apps and Desktopsデータストアデータベースを含む他のデータベースと同じSQL Server上で実行できます。
セッション録画の展開で数百万もの録画セッションをデータベースにカタログ化する必要がある場合は、SQL Serverのスケーラビリティに関するMicrosoftのガイドラインに従ってください。