ログサーバーの推奨事項

日次ログ量 (ストレージ)

サイジングの前提条件

• この例は、約10,000の管理対象エンドポイントとインフラストラクチャコンポーネントのリファレンス展開を表しています。
• サイジングの目的で、Delivery Controller、StoreFrontサーバー、Gateway、PVS、FAS、Session Recording、およびその他のインフラストラクチャコンポーネントは、サーバーあたり1日300 MBと見積もられています。
• サーバーあたり300 MBという値は、ストレージ計画と容量計算に使用される控えめな見積もりです。

注記:

1. これらの値は概算であり、展開によって大きく異なる場合があります。ログの量は、サイトの規模、ユーザーアクティビティ、コンポーネントの組み合わせ、および保持の必要性によって異なります。これらの数値は、計画を開始するためのベースラインとしてのみ使用し、環境の実際の使用状況、成長傾向、およびパフォーマンス テストに基づいてストレージ割り当てを調整してください。

2. ログサーバーはデフォルトでLZ4圧縮アルゴリズムを使用します。圧縮率は20%から50%の間になる可能性があり、これは、最大圧縮時にはログサーバーがディスクスペースの半分を占め、最小圧縮時には80%を占めることを意味します。

3. 単一のAOTログサーバーは、最大128,000のアクティブなコンポーネント接続をサポートし、1秒あたり最大10,000のログイベントを処理できます。ログサーバーは、環境がこれらの接続およびスループットのしきい値内にある限り、AOTログを24時間体制で継続的に収集および保存するように設計されています。

4. これらの推奨事項は、仮想マシンのサイズではなく、受信するAOTログを取り込み、処理し、保存する基盤となる検索およびインデックス作成エンジンの容量によって決定されます。この検索レイヤーは、インデックス作成、クエリ、および保持操作を処理するため、最終的に最大スケールを決定します。環境が拡大するにつれて、このレイヤーはパフォーマンスを維持するために水平方向にスケールする必要があります。

5. 現在、ログサーバーは、ログサーバーサービスと検索/インデックスエンジンの両方を含む単一の統合ノードとして提供されています。これにより展開は簡素化されますが、検索層を独立してスケールする能力が制限されます。

6. 今後のリリースでは、Citrixは取り込みとストレージ/インデックス作成が独立したノードで実行される分離されたアーキテクチャに移行します。これにより、顧客は環境の成長に合わせて検索層をスケールでき、大規模またはマルチサイト展開全体でパフォーマンスが向上し、現在の単一ノード設計によって課せられるスケーラビリティの天井が解消されます。

7. AOTログサーバーはSSDベースのストレージに展開してください。特に大量の環境では、信頼性の高いログ取り込み、高速な検索パフォーマンス、効率的な相関を確保するために、SSDを強くお勧めします。

AOTログサーバーのストレージサイジング

ストレージを正しくサイジングすることは、AOTログサーバーを計画する上で最も重要なステップの1つです。必要な総ストレージは、AOTログを送信するマシンの数、1日あたりに生成されるデータ量、およびログを保持する必要がある期間によって異なります。

Citrix環境はそれぞれ異なる動作をするため、お客様はまず、VDA、Citrix Workspace Appエンドポイント、Delivery Controller、およびStoreFrontサーバーのログ生成パターンを使用して、1日のログ量を推定する必要があります。1日の量がわかれば、以下の式を使用して総ストレージを計算できます。

ストレージ計算式 総ストレージ (GB) = 1日のログ量 (GB) × 保持日数

AOTログサーバーのストレージサイジングガイダンス

デプロイメントサイズに基づいた日次ログ量とストレージ要件の見積もりについては、以下の表を参照してください。これらの見積もりは容量計画を目的としており、ユーザーアクティビティ、セッション密度、有効なコンポーネント、およびデプロイメントアーキテクチャによって異なる場合があります。

日次ログ量の見積もり

保持期間に基づくストレージ見積もり

注記:

• これらの値は、キャパシティプランニングを目的とした概算値です。実際のストレージ要件は、展開アーキテクチャ、ユーザーアクティビティ、有効なコンポーネント、保持期間、および圧縮効率によって異なります。

• 推定値は、10,000台のマシンリファレンス展開モデルに基づいており、線形にスケーリングされます。