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