リモート Citrix またはターミナル・サービスの構成

BigFix は、低速接続でもコンテンツを効率的に配信できますが、コンソール自体にデータが集中すると、256 kbps よりも遅いリンクでは過負荷状態になる場合があります。クライアントをさらに追加すると、ラグ・タイムはさらに増えます。

ただし、コンソールには、Citrix、Windows Terminal Server、VNC、または Dameware スタイルのプレゼンテーション・サーバーからリモート・アクセスでき、優れたパフォーマンスを実現できます。以下に、この構成がどのようなものかを示します。

この図は、リモート Citrix またはターミナル・サービスの構成を示しています。

図に関して、以下の事項に注意してください。

  • 本社では、データを高速収集するために、サーバーに近いコンピューターにコンソールをセットアップします。これはプレゼンテーション・サーバーです。
  • 各リモート・ユーザーのユーザー・アカウントを作成する必要があります。これらのユーザーは、コンソールに迅速にアクセスすることができます。これは、速度が重視されるデータ・ロードが、高速リンクを使用して本社で実行されるためです。
  • セキュリティーを向上させるために、リモート接続は HTTPS で実行できます。
  • 秘密鍵を格納するプレゼンテーション・サーバーからコンソールを実行することは、キーがリムーバブル・ドライブに保存されている場合よりも本質的に危険ですので注意してください。
  • リモート・アクセスを複数のサーバーに分散させるロード・バランシング・ソフトウェアを使用すると適切な場合があります。
  • Citrix で実行されるコンソールの主なボトルネックは、メモリー・サイズです。コンソールでメモリー不足が発生すると、コンソールのパフォーマンスが急激に低下します。メモリー所要量を特定する適切な手法は、マスター・オペレーターとしてコンソールを開くことです。メモリーの使用状況を確認します。これにより、ユーザーあたりの最大メモリー所要量が分かります。その後、通常のオペレーターとしてログインし、平均メモリー所要量としてこれを使用します。Citrix サーバーの最大メモリーですべての同時ユーザーをサポートできる場合、その Citrix サーバー 1 台で十分です。サポートできない場合、ユーザーあたりの平均メモリー所要量を使用して、必要とされる追加 Citrix サーバーの数を特定します。
  • 2 番目の制約は CPU の処理能力です。コンソールは、更新中、CPU コアをフル活用した場合に最も適切に動作します。したがって、1 つの CPU コアで、それぞれの同時ユーザー用のコンソールを実行するように、プレゼンテーション・サーバーを最適化します。
  • 最後の考慮事項は、コンソール・キャッシュのディスク・スペースです。ローカル・コンピューターで、C:\Documents and Settings\<USERNAME>\Local Settings\Application Data\BigFix\Enterprise Console\BES_bfenterprise などを調べることにより、キャッシュのサイズを確認することができます。コンソール・オペレーターごとに 1 つのキャッシュ・ファイルを用意するために、十分なディスク・スペースが必要です。