スケーラビリティに関する注意事項
Session Recordingのインストールと実行のために、Citrix Virtual Apps and Desktopsの実行に必要なハードウェア要件を超えて、さらにリソースを追加する必要はほとんどありません。ただし、Session Recordingを使用して多くのセッションを録画する可能性がある場合、または画像処理に多くのリソースを消費するアプリケーションを録画するなど、セッションの録画ファイルのサイズが大きくなることが予測される場合は、Session Recordingの展開計画を立てるときに、使用するシステムのパフォーマンスについて検討します。
高スケーラブルなSession Recordingシステムの構築について詳しくは、Citrix記事CTX200869を参照してください。
ハードウェアの推奨事項
各Session Recordingサーバーに送信するデータの量と、サーバーでこのデータを処理し格納するのにかかる時間について考慮します。受信データを格納する速度がデータ入力速度より高速である必要があります。
データ入力速度を推定するには、録画対象のセッションの数をその平均サイズで乗算してから、セッションの録画時間で除算します。たとえば、5,000件のMicrosoft Outlookのセッションの平均サイズが20MBとして、毎営業日に8時間録画するとします。この場合は、データ入力速度はおよそ28Mbpsです （5,000セッション × 20MB ÷ 8時間 ÷ 3,600秒/時間 x 8（Mbpsへの変換用））。
単一のSession Recordingサーバーのパフォーマンスを最適化するか、複数のマシンにSession Recordingサーバーをインストールすることによって、パフォーマンスを向上させることができます。
ディスクとストレージ
ディスクとストレージは、Session Recordingの展開を計画するときに考慮すべき最も重要な要素です。使用するストレージソリューションの書き込み性能は特に重要です。データの書き込み速度が速いほど、システム全体のパフォーマンスが向上します。
ローカルディスクコントローラーまたは接続されたSANにより、RAIDアレイとしてローカルディスクのセットを制御する方法は、Session Recordingでの使用に適したストレージソリューションです。
注：
SMBやNFSなどのファイルベースのプロトコルでNASにデータを格納すると、パフォーマンスとセキュリティ上の問題が発生する可能性があります。最新バージョンのプロトコルを使用してセキュリティ上の問題を回避し、スケールテストを実行して適切なパフォーマンスを確保します。
ローカルドライブにキャッシュメモリが組み込まれているディスクコントローラーを使用すると、パフォーマンスが向上します。キャッシュ機能付きディスクコントローラーには予備電源装置を付け、停電時にもデータの整合性を確保できるようにする必要があります。
ネットワークの性能
Session Recordingサーバーに接続するには100Mbpsのネットワークリンクが適しています。ギガビットイーサネット接続ではパフォーマンスが向上するかもしれませんが、100Mbpsのリンクの10倍のパフォーマンスが得られるわけではありません。
Session Recordingで使用するネットワークスイッチを、使用できるネットワーク帯域幅を求めて競合する可能性のあるサードパーティ製のアプリケーションと共有しないようにします。Session Recordingサーバー専用のネットワークスイッチを用意することが理想的です。
コンピューターの処理性能
Session Recordingサーバーをインストールするコンピューターについて、次の仕様を検討します：
- デュアルCPUまたはデュアルコアCPUをお勧めします。
- 4GBのRAMをお勧めします。
これらの仕様を超えるコンピューターを使用しても、パフォーマンスが大幅に向上することはありません。
複数のSession Recordingサーバーの展開
単一のSession Recordingサーバーではパフォーマンスのニーズを満たせない場合、複数のSession Recordingサーバーを異なるマシンにインストールして、負荷分散プールとして機能させることができます。このタイプの展開では、Session Recordingサーバーはストレージとデータベースを共有します。負荷を分散するには、Session Recording Agentを負荷分散を担当するロードバランサーに割り当てます。
データベースのスケーラビリティ
Session Recordingデータベースでは、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が必要です。データベースにはセッション録画のメタデータのみが格納されるため、データベースに送信されるデータ量は少なくなります。セッションの録画ファイル自体は別のディスクに書き込まれます。Session RecordingイベントAPIを使用してセッションに検索可能なイベントを挿入するのでなければ、Session Recording1件につきデータベースに必要な容量は通常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件のSession Recordingあたり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のデータベースで何百万というSession Recordingをカタログ化する必要がある場合は、SQL Serverのスケーラビリティに関するMicrosoft社のガイドラインに従います。