スケーラビリティに関する考慮事項

Session Recordingは、数千から数万のセッションを処理できる、非常にスケーラブルなシステムです。Session Recordingのインストールと実行には、XenAppおよびXenDesktopの実行に必要なもの以外に、ほとんど追加のリソースは必要ありません。ただし、Session Recordingを使用して多数のセッションを記録する予定がある場合、または記録する予定のセッションが大きなセッションファイル（たとえば、グラフィックを多用するアプリケーション）になる可能性がある場合は、Session Recordingの展開を計画する際にシステムのパフォーマンスを考慮してください。

この記事では、Session Recordingがいかに高いスケーラビリティを実現しているか、そして最小限のコストでレコーディングシステムを最大限に活用する方法について説明します。

Session Recordingのスケーラビリティが高い理由

競合製品と比較して、Session Recordingのスケーラビリティが高い主な理由は2つあります。

• 小さいファイルサイズ

  Session Recordingで作成された記録済みセッションファイルは、非常にコンパクトです。これは、画面スクレイピングを行うソリューションで作成された同等のビデオ録画よりも、何桁も小さくなります。各Session Recordingファイルを転送および保存するために必要なネットワーク帯域幅、ディスクスペース、およびディスクIOPSは、通常、同等のビデオファイルの少なくとも10分の1です。

  記録済みセッションファイルのサイズが小さいということは、ビデオフレームのレンダリングがより速く、よりスムーズになることを意味します。また、記録は完全にロスレスであり、ほとんどのコンパクトなビデオ形式でよく見られるピクセル化もありません。記録内のテキストは、元のセッションと同様に、再生中に読みやすくなっています。ファイルサイズを小さく保つため、Session Recordingはファイル内にキーフレームを記録しません。

• ファイル生成に必要な処理が少ない

  記録済みセッションファイルには、セッションのICA®プロトコルデータが含まれており、これはほぼネイティブ形式で抽出されます。これは、ファイルがCitrix Workspace™アプリとの通信に使用されるICAプロトコルデータストリームをキャプチャすることを意味します。データをリアルタイムでフォーマット変更するために、高価なトランスコーディングまたはエンコーディングソフトウェアコンポーネントを実行する必要はありません。処理量が少ないことは、VDAのスケーラビリティにとっても重要であり、同じVDAから多数のセッションが記録される場合でも、エンドユーザーエクスペリエンスが維持されることを保証します。

  さらに、再生可能なICA仮想チャネルのみが記録されるため、さらなる最適化が実現されます。たとえば、プリンターチャネルやクライアントドライブマッピングチャネルは、ビデオ再生に何のメリットもなく大量のデータを生成する可能性があるため、記録されません。

データ入力および処理レートの見積もり

Session Recording Serverは、記録済みセッションファイルの中央収集ポイントです。Session Recordingが有効になっているマルチセッションOS VDAを実行している各マシンは、記録済みセッションデータをSession Recording Serverに送信します。Session Recordingは大量のデータを処理でき、バーストや障害にも耐えられますが、1つのサーバーが処理できるデータ量には物理的な制限があります。

各Session Recording Serverに送信するデータ量と、サーバーがこのデータを処理および保存できる速度を考慮してください。システムが受信データを保存できる速度は、データ入力レートよりも高くなければなりません。

データ入力レートを見積もるには、記録されたセッション数に各記録済みセッションの平均サイズを掛け、セッションを記録している時間で割ります。たとえば、8時間の勤務時間中に、それぞれ20 MBのMicrosoft Outlookセッションを5,000回記録する場合があります。この場合、データ入力レートは約3.5 Mbpsです。（5,000セッション × 20 MB ÷ 8時間 ÷ 3,600秒/時間）。記録されたデータを保存するのに十分なディスクスペースを持つ100 Mbps LANに接続された一般的なSession Recording Serverは、ディスクおよびネットワークIOPSによって課される物理的な制限に基づいて、約5.0 Mbpsでデータを処理できます。これが処理レートです。この例では、処理レート（5.0 Mbps）が入力レート（3.5 Mbps）よりも高いため、5,000のOutlookセッションを記録することは実現可能です。

Note that the amount of data per session varies greatly depending on what is being recorded, while other factors such as the screen resolution, color depth, and graphics mode also have impacts. A session running a CAD package where graphics activity is constantly high likely generates a much larger recording than a session in which the end user sends and receives emails in Microsoft Outlook. Therefore, recording the same number of CAD sessions can generate an extremely high input rate and require the use of more Session Recording Servers.

バーストと障害

The previous example assumes a very simple uniform throughput of data but does not explain how the system deals with short periods of higher activity, known as bursts. A burst might occur when all users log on at the same time in the morning, known as the 9 o’clock rush, or when they receive the same email in their Outlook inbox at once. The 5.0 Mbps processing rate of the Session Recording Server is highly inadequate at dealing with this sudden demand.

The Session Recording Agent running on each VDA uses Microsoft Message Queuing (MSMQ) to send recorded data to the Storage Manager running on the central Session Recording Server. The data is sent in a store-and-forward manner similar to how an email is delivered between the sender, mail server, and the receiver. If the Session Recording Server or the network cannot handle the high rate of data in a burst, the recorded session data is temporarily stored until the backlog of data messages is cleared. The data message might be temporarily stored in the outgoing queue on the VDA if the network is congested, or stored on the Session Recording Server’s receiving queue if the data has traversed the network but the Storage Manager is still busy processing other messages.

MSMQ also serves as a fault tolerance mechanism. If the Session Recording Server goes down or the link is broken, recorded data is held in the outgoing queue on each VDA. When the fault is rectified, all queued data is sent together. The use of MSMQ also allows you to take a Session Recording Server offline for upgrade or maintenance without interrupting the recording of existing sessions and losing data.

The main limitation of MSMQ is that disk space for the temporary storage of data messages is finite. This limits how long a burst, fault, or maintenance event can last before data is eventually lost. The overall system can continue after data loss, but in this situation, individual recordings have chunks of data missing. A file with missing data is still playable but only up to the point where data was first lost. Note the following:

• Adding more disk space to each server, especially the Session Recording Server, and making it available to MSMQ can increase the tolerance to bursts and faults.

• It is important to configure the Message Life setting for each Session Recording Agent to an appropriate level (on the Connections tab in Session Recording Agent Properties). The default value of 7,200 seconds (two hours) means that each recorded data message has two hours to reach the Storage Manager before it is discarded and recording files are damaged. With more disk space available (or fewer sessions to record), you can choose to increase this value. The maximum value is 365 days.

The other limitation with MSMQ is that when data backlogs, there is extra disk IOPS in the queue to read and write data messages. Under normal conditions, the Storage Manager receives and processes data from the network directly without the data message ever being written to disk. Storing the data involves a single write operation to disk that appends the recorded session file. When data is backlogged, the disk IOPS is tripled: each message must be written to disk, read from disk, and written to file. As the Storage Manager is heavily IOPS bound, the processing rate of the Session Recording Server drops until the backlog of messages is cleared. To mitigate the effects of this extra IOPS, adopt the following recommendations:

• Ensure that the disk on which MSMQ stores messages is different from the recording file storage folders. Even though IOPS bus traffic is tripled, the drop in the true processing rate is never as severe.

• Have planned outages at off-peak times only. Depending on budget constraints, follow recognized approaches to building high availability servers. The approaches include the use of UPS, dual NICs, redundant switches, and hot swappable memory and disks.

予備容量の設計

The data rate of recorded session data is unlikely to be uniform, bursts and faults might occur, and the clearing of message backlogs is expensive in IOPS. For this reason, design each Session Recording Server with plenty of spare capacity. Adding more servers or improving the specification of existing servers, as described in later sections, always gains you extra capacity. The general rule of thumb is to run each Session Recording server at a maximum of 50% of its total capacity. In the earlier example, if the server is capable of processing 5.0 Mbps, target the system to run only at 2.5 Mbps. Instead of recording 5,000 Outlook sessions that generate 3.5 Mbps on one Session Recording Server, reduce this to 3,500 sessions that generate only about 2.5 Mbps.

バックログとライブ再生

Live playback is when a reviewer opens a session recording for playback while the session is still active. During live playback, the Session Recording Agent responsible for the session switches to a streaming mode for that session, and recording data is sent immediately to the Storage Manager without internal buffering. Because the recording file is constantly updated, the Player can continue to be fed with the latest data from the live session. However, data sent from the Agent to the Storage Manager is through MSMQ, so the queuing rules described earlier apply. A problem can occur in this scenario. When MSMQ is backlogged, the new recorded data available for live playback is queued like all other data messages. The reviewer can still play the file, but viewing latest live recorded data is delayed. If live playback is an important feature for reviewers, ensure a low probability of backlog by designing spare capacity and fault tolerance into your deployment.

XenApp® および XenDesktop のスケーラビリティ

セッション録画は、セッションパフォーマンスを低下させることはなく、録画データのバックログによってセッションを停止させることもありません。エンドユーザーエクスペリエンスとシングルサーバーのスケーラビリティの維持は、セッション録画システムの設計において最も重要です。録画システムが回復不能なほど過負荷になった場合、録画されたセッションデータは破棄されます。Citrix® による広範なスケーラビリティテストにより、ICAセッションの録画がXenAppおよびXenDesktopサーバーのパフォーマンスとスケーラビリティに与える影響は小さいことが明らかになりました。影響の大きさは、プラットフォーム、利用可能なメモリ、および録画されるセッションのグラフィックの性質によって異なります。以下の構成では、シングルサーバーのスケーラビリティへの影響は1%から5%の間になると予想されます。言い換えれば、セッション録画がインストールされていないサーバーが100ユーザーをホストできる場合、インストール後は95～99ユーザーをホストできます。

• マルチセッションOS VDAを実行する8 GB RAM搭載の64ビットサーバー
• OutlookやExcelなどのOffice生産性向上アプリケーションを実行しているすべてのセッション
• アプリケーションの使用がアクティブかつ継続的である
• セッション録画ポリシーによって構成されているとおりに、すべてのセッションが録画される

録画されるセッションが少ない場合や、セッションアクティビティが継続的でなく散発的である場合、影響は小さくなります。多くの場合、スケーラビリティへの影響はごくわずかで、サーバーあたりのユーザー密度は変わりません。前述のとおり、影響が小さいのは、各VDAにインストールされているセッション録画コンポーネントの処理要件が単純であるためです。録画されたデータは、ICAセッションスタックから単純に抽出され、MSMQを介してセッション録画サーバーにそのまま送信されます。データの高価なエンコードは行われません。

セッションが録画されていない場合でも、セッション録画を使用するとわずかなオーバーヘッドが発生します。影響は小さいものの、特定のサーバーからセッションが録画されることがないと確信している場合は、そのサーバーでの録画を無効にできます。セッション録画を削除することもその1つの方法です。より侵襲性の低いアプローチは、セッション録画エージェントのプロパティの [セッション録画] タブにある [このVDAマシンでセッション録画を有効にする] チェックボックスをオフにすることです。将来的にセッション録画が必要になった場合は、このチェックボックスを再度オンにしてください。

スループットの測定

送信側VDAから受信側セッション録画サーバーへの録画済みセッションデータのスループットを測定する方法はいくつかあります。最も単純で効果的なアプローチの1つは、録画されるファイルのサイズと、セッション録画サーバーのディスク領域が消費される速度を監視することです。ディスクに書き込まれるデータ量は、生成されるネットワークトラフィック量と密接に相関しています。Windowsパフォーマンスモニターツール（perfmon.exe）には、セッション録画によって提供されるいくつかのカウンターに加えて、監視できる標準システムカウンターが多数あります。カウンターは、スループットの測定、ボトルネックの特定、およびシステムの問題の特定に使用できます。次の表に、最も有用なパフォーマンスカウンターの一部を示します。

セッション録画サーバーのハードウェア

セッション録画サーバーに使用するハードウェアを慎重に選択することで、展開の容量を増やすことができます。選択肢は2つあります。スケールアップ（各サーバーの容量を増やす）またはスケールアウト（サーバーを追加する）です。どちらの選択肢を選ぶにしても、目標は最小限のコストでスケーラビリティを向上させることです。

スケールアップ

単一のセッション録画サーバーを検討する際には、利用可能な予算で最適なパフォーマンスを確保するために、以下のベストプラクティスを考慮してください。システムはIOPSに依存します。これにより、ネットワークからディスクへの録画データの高いスループットが保証されます。そのため、適切なネットワークおよびディスクハードウェアに投資することが重要です。高性能なセッション録画サーバーには、デュアルCPUまたはデュアルコアCPUが推奨されますが、それ以上のスペックにしてもほとんどメリットはありません。64ビットプロセッサーアーキテクチャが推奨されますが、x86プロセッサータイプも適しています。4 GBのRAMが推奨されますが、これもまた、それ以上追加してもほとんどメリットはありません。

スケールアウト

最高のスケールアッププラクティスを採用しても、多数のセッションを記録する場合、単一のSession Recording Serverで達成できるパフォーマンスとスケーラビリティには限界があります。負荷に対応するために、追加のサーバーが必要になる場合があります。複数のマシンにSession Recording Serverを追加インストールして、Session Recording Serverをロードバランシングプールとして機能させることができます。この種の展開では、Session Recording Serverはストレージとデータベースを共有します。負荷を分散するには、Session Recording Agentをワークロードの分散を担当するロードバランサーに向けます。

ネットワーク容量

100 Mbpsのネットワークリンクは、Session Recording Serverの接続に適しています。ギガビットイーサネット接続はパフォーマンスを向上させる可能性がありますが、100 Mbpsリンクの10倍のパフォーマンスにはなりません。実際には、スループットの向上は大幅に少なくなります。

Session Recordingで使用されるネットワークスイッチが、利用可能なネットワーク帯域幅を競合する可能性のあるサードパーティアプリケーションと共有されていないことを確認してください。理想的には、ネットワークスイッチはSession Recording Server専用であるべきです。ネットワークの輻輳がボトルネックであることが判明した場合、ネットワークのアップグレードは、システムの拡張性を高める比較的安価な方法です。

ストレージ

ディスクおよびストレージハードウェアへの投資は、サーバーのスケーラビリティにおいて最も重要な単一の要素です。データがディスクに書き込まれる速度が速いほど、システム全体のパフォーマンスは高くなります。ストレージソリューションを選択する際には、読み取りパフォーマンスよりも書き込みパフォーマンスに注目してください。

データを、ローカルディスクコントローラーによるRAIDとして、またはSANとして制御されるローカルディスクのセットに保存します。

注：

SMB、CIFS、NFSなどのファイルベースプロトコルに基づくNASにデータを保存することは、重大なパフォーマンスとセキュリティ上の影響があります。Session Recordingの本番展開では、この構成を絶対に使用しないでください。

ローカルドライブのセットアップの場合、内蔵キャッシュメモリを備えたディスクコントローラーを目指してください。キャッシングにより、コントローラーはライトバック中にエレベーターソートを使用でき、これによりディスクヘッドの移動が最小限に抑えられ、物理ディスク操作の完了を待たずに書き込み操作が完了します。これにより、最小限の追加コストで書き込みパフォーマンスを大幅に向上させることができます。ただし、キャッシングは停電後のデータ損失の問題を引き起こします。データとファイルシステムの整合性を確保するため、キャッシングディスクコントローラー用のバッテリーバックアップ設備を検討してください。これにより、停電が発生した場合でもキャッシュが維持され、最終的に電源が復旧したときにデータがディスクに書き込まれることが保証されます。

適切なRAIDストレージソリューションの使用を検討してください。パフォーマンスと冗長性の要件に応じて、多くのRAIDレベルが利用可能です。次の表は、各RAIDレベルと、各標準が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製品も現在利用可能です。ディスクドライブ製品の仕様を評価する際には、ディスクの回転速度やその他のパフォーマンス特性を考慮してください。

1日あたり数千のセッションを記録すると、相当な量のディスク領域を消費する可能性があるため、全体的な容量とパフォーマンスのどちらかを選択する必要があります。前述の例では、8時間の勤務時間中に5,000のOutlookセッションを記録すると、約100 GBのストレージ領域を消費します。10日分の記録（つまり50,000の記録済みセッションファイル）を保存するには、1,000 GB（1 TB）が必要です。ディスク領域へのこの負荷は、古い記録をアーカイブまたは削除する前に保持期間を短縮することで軽減できます。1 TBのディスク領域が利用可能な場合、7日間の保持期間は妥当であり、ディスク領域の使用量が約700 GBに保たれ、300 GBが繁忙期のバッファーとして残ります。Session Recordingでは、ファイルのアーカイブと削除はICLDBユーティリティでサポートされており、最低2日間の保持期間があります。ピーク時以外の時間に1日1回実行されるバックグラウンドタスクをスケジュールできます。ICLDBコマンドとアーカイブの詳細については、「データベースレコードの管理」を参照してください。

ローカルドライブとコントローラーを使用する代わりに、ブロックレベルのディスクアクセスに基づくSANストレージソリューションを使用する方法があります。Session Recordingサーバーにとって、ディスクアレイはローカルドライブとして表示されます。SANはセットアップに費用がかかりますが、ディスクアレイが共有されるため、管理が簡素化され一元化されるという利点があります。SANには主に2つのタイプがあります。Fibre ChannelとiSCSIです。iSCSIは本質的にTCP/IP上のSCSIであり、Gbイーサネットの導入以来、Fibre Channelよりも人気を集めています。

データベースのスケーラビリティ

Session Recordingデータベースには、Microsoft SQL Server 2016、Microsoft SQL Server 2014、Microsoft SQL Server 2012、またはMicrosoft SQL Server 2008 R2が必要です。データベースに送信されるデータ量は少量です。これは、データベースが記録されたセッションに関するメタデータのみを保存するためです。記録されたセッションのファイル自体は、別のディスクに書き込まれます。通常、各記録済みセッションはデータベース内で約1 KBの領域しか必要としません。ただし、Session RecordingイベントAPIを使用して検索可能なイベントをセッションに挿入する場合は除きます。

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イベントAPIを介してカスタマイズを行わない場合、各記録済みセッションは4つのデータベーストランザクションを生成します。記録開始時に2つ、ユーザーが記録中のセッションにログオンしたときに1つ、記録終了時に1つです。Session RecordingイベントAPIを使用してセッションをカスタマイズする場合、記録された検索可能なイベントごとに1つのトランザクションが生成されます。最も基本的なデータベース展開でも1秒あたり数百のトランザクションを処理できるため、データベースへの処理負荷が問題になる可能性は低いでしょう。その影響は非常に軽微であるため、Session Recordingデータベースは、XenAppまたはXenDesktopデータストアデータベースを含む他のデータベースと同じSQL Server上で実行できます。

Session Recording展開で数百万もの記録済みセッションをデータベースにカタログ化する必要がある場合は、SQL Serverのスケーラビリティに関するMicrosoftのガイドラインに従ってください。