ローカルホストキャッシュのサイジングとスケーリング
注:
この記事では、ローカルホストキャッシュ (LHC) を使用する XenApp および XenDesktop 展開のサイズとスケールの推奨事項について説明します。Citrix DaaS のサイズとスケールの推奨事項については、「Cloud Connectors のサイズとスケールの考慮事項」を参照してください。
LHC は、障害発生時でも接続ブローカリングを継続できるようにすることで、高可用性を提供します。LHC のユーザーは、以下の設計上の考慮事項を遵守する必要があります。
- 障害発生時には、ゾーンごとに単一のブローカーが Virtual Delivery Agent (VDA) の登録とブローカーセッションを処理します。
- どのブローカーがアクティブになるかを決定する選出プロセスでは、ブローカーのリソースは考慮されません。
- ゾーン内の単一のブローカーが通常操作中にすべてのログオンを処理できない場合、障害モードではうまく機能しません。
- 障害発生中は、サイト管理は利用できません。
- 高可用性 SQL Server は、依然として推奨される設計です。
- 断続的なデータベース接続シナリオの場合でも、すべての根本的な問題が解決されるまで SQL Server を分離し、サイトを障害モードのままにしておく方が良いでしょう。
- ゾーンあたりの VDA の制限は 10,000 です。
- デフォルト構成では、プールされたデスクトップは障害モードでサポートされていません。
アーキテクチャ
LHC は、ディスク領域の使用量において接続リースよりも効率的なローカル SQL Server データベースを使用しますが、CPU とメモリをかなり多く必要とします。LHC には同期フェーズがあり、メインサイトデータベースからの詳細がブローカー (コントローラー) に同期されます。LHC は依然として IOPS を必要とする SQL データベースを使用しており、SQL がこれらの書き込みを最適化するという利点があります。
LHC は、すべての接続を仲介し、VDA 登録を処理するために選出された単一のブローカーを使用します。サイト内のすべての VDA はこの単一のブローカーに再登録され、その結果、特に多数の VDA を持つサイトでは、より高いリソース需要を経験することになります (通常の操作におけるマルチブローカーサイトと比較して)。
LHCはMicrosoft LocalDBを使用しており、これはタスクマネージャーにsqlserver.exeプロセスとして表示されます。これは、データベースバッファプールキャッシュに最大1GBのメモリを使用するように構成されています。ただし、SQLエンジンが自身や他の小さなキャッシュのためにメモリを必要とするため、プロセスはこれを超えて拡大します。一般に、停止期間が長く、停止モード中にアクセスされるリソースが多いほど、LocalDBのメモリ使用量は増加します。ただし、サイトデータベースの接続が復元されても、sqlserver.exeはこのメモリを保持し、すぐにメインプールに戻しません。
停止モード中のCPUソケットとコアの影響
LHCは、LocalDBと呼ばれるSQL Serverのランタイムバージョンを使用しており、これは4コアまたはシングルソケットのいずれか少ない方に制限される特定のライセンスを持っています。これは、物理マシンまたは仮想マシンが、単一またはデュアルコアのみで複数のソケットを持つように構成されている場合に、パフォーマンスに大きな影響を与える可能性があります。4つのソケットとソケットあたり1つのコアを持つブローカーマシンでは、LocalDBは単一のコアの使用に制限されますが、同じVMが1ソケット、4コアのマシンとして構成されている場合、LocalDBは4つのコアすべてにアクセスできます（ただし、他のプロセスと共有します）。停止モード中、LocalDBは通常の操作時と同じブローカーおよびSQLコードを実行します。多くのSQLクエリはCPU負荷が高く、停止モード中のブローカー処理のパフォーマンスに直接影響を与える可能性があります。詳細については、クラウドコネクタのサイズとスケールの考慮事項 および SQL Serverのエディションごとのコンピューティング容量制限 を参照してください。
その他の要因には、次のようなサイト構成自体が含まれます。
- 公開されているアプリケーションの数
- ブローカー処理されるユーザーの数
- ユーザーがセッションを起動しようとする頻度
- アクティブディレクトリのパフォーマンス
ブローカーのCPU使用率の合計が100%に近づくと、ブローカー処理の応答時間が増加し、ログオン処理に時間がかかり、一部のログオン試行が失敗する可能性があります。
複数のブローカーを持つサイト
サイト停止モード中、単一のブローカーのみが登録およびログオン要求を処理します。複数のブローカーを持つサイトでは、停止中にアクティブになるブローカーを指名するための選出プロセスが行われます。ただし、この選出プロセスでは、ブローカーに利用可能な物理リソースは考慮されません。これは、ブローカーが異なる量のリソースを持つサイトでは、選出されたブローカーがCPUまたはRAMの点で最も強力であるとは限らず、停止モード中にパフォーマンスが低下する可能性があることを意味します。選出された場合に備えて、各ブローカーがLHCの追加要件を満たしていることが重要です。
サイトデータベースとの同期
CitrixConfigSyncサービスは、サイトデータベースからブローカー上のローカルコピーへのデータインポートを処理します。サイト構成の変更についてサイトデータベースを監視し、変更が発生すると新しいインポートをトリガーします。インポートが開始される前に、現在のローカルデータベースのコピーが作成されます。サイト内のリソース（VDAなど）の数が多いほど、インポートには時間がかかりますが、10,000台のVDAを持つサイトでは10分未満であるはずです。
データベースの場所
ローカルデータベースは次の場所に保存されます。
C:\Windows\ServiceProfiles\NetworkService\HaDatabaseName.mdf
信頼性を確保するため、CitrixConfigSyncサービスは、新しいサイトデータベースの同期を開始する前に、以前に正常に同期されたデータベースインポートのバックアップを作成します。何らかの理由で同期が正常に完了しなかった場合、正常な同期が完了するまでバックアップが使用されます。データベースを手動でコピーしないでください。
ローカルホストキャッシュの技術仕様
| アーキテクチャ | 仕様 |
|---|---|
| ディスク容量 | サイト構成によって異なります。65,000ユーザーで1,000のRDSホストと9,500のVDIの場合、75MBが使用されます。 |
| RAM | 3 ギガバイト (SQLサーバーに約1 ギガバイト、高可用性サービスとCitrixConfigSyncサービスに2 ギガバイト) |
| 構成の同期時間 | 10,000 VDA: 約7分 |
| 障害発生時のアクティブ化時間 | VDAの数と、ブローカーとの最終登録同期によって異なります。障害モード中は、VDA登録に利用できるブローカーは1つだけであるため、VDAの数が多い場合は、すべてのVDAが登録されるまでに数分かかることがあります。 |
| 通常操作の復元時間 | 上記と同様に、VDAはセカンダリブローカーから登録解除し、プライマリブローカーに再登録する必要があります。 |
| サポートされるVDAの数 | 10,000。サイトはこれよりも多くのVDAを持つことができますが、サイトデータベースの同期に必要な時間はVDAの数とともに増加します。多数のVDAを持つ単一のブローカーのパフォーマンスは、障害発生中に一部の接続がブローカーされない結果となる可能性があります。 |
| 障害発生時のサイト管理 | いいえ |
ローカルホストキャッシュの有効化または無効化
LHCは必要に応じて有効または無効にできます。
| Set-BrokerSite –LocalHostCacheEnabled $True | $False |
制限事項
デスクトップは、障害モードで使用される前に割り当てられている必要があります。割り当てられていないデスクトップは、ブローカーの対象になりません。これにより、すべての割り当てが同期される前に障害が発生した場合、ユーザーが実際にデスクトップを割り当てられているにもかかわらず、デスクトップが利用できなくなり、「メンテナンスモード」と報告される可能性があります。
デフォルト構成では、プールされたデスクトップは障害モードでサポートされていません。回避策はありますが、セキュリティとパフォーマンスに潜在的な影響があります。ログオフ時に再起動しないようにプールされたデスクトップを含むデリバリーグループを構成した場合、そのグループ内の電源がオンになっているプールされたデスクトップはすべて障害モードで利用可能になります。ただし、ユーザーがログオフした後、デスクトップは再起動されないため、クリーンな状態ではありません。これは、どのようなシナリオでもセキュリティ上の懸念となる可能性があります。そのデスクトップの次のユーザーがそのデスクトップのローカル管理者である場合、以前のユーザーのデータにアクセスできる可能性があります。そして、そのリスクは標準（管理者以外）のユーザーにとってはそれほど懸念されませんが、アプリケーションが不適切に動作し、時間の経過とともにパフォーマンスの問題を引き起こす可能性があることに留意してください。重要: 管理者は、障害モードで再起動しないプールされたデスクトップを使用するためのこの回避策の潜在的な影響を慎重に検討する必要があります。
障害発生中は、サイトの変更はできません。データベースは実質的にメインサイトデータベースのスナップショットであり、新しい同期が発生するたびに破棄されます。
データベースサイズ
10,000 VDI構成（つまり、10,000のシングルセッションVDIデスクトップ）の場合、LocalDBは約75 MBでした。100,000 RDS構成（つまり、100,000ユーザー）の場合、LocalDBはアプリケーションとログオンの数に応じて100～300 MBの間で変動しました。新しいインポートが開始される前にデータベースのコピーが作成されるため、LocalDB用に1 GBのスペースを確保してください。
ユーザーサイジングの考慮事項
ゾーンあたりの最大VDA数は10,000ですが、障害発生時にセッションが選出されたブローカーの負荷に寄与するため、Citrixはゾーンあたりのピークセッション数も考慮することを推奨します。マルチセッションVDAを使用する場合、単一のVDAに対して複数のセッションを開始できるため、セッション密度が重要になります。
停止中、推奨されるピークはゾーンあたり25,000ユーザーであり、適切にサイジングされていれば、1分あたり1～2kのリソース起動に達する可能性があります。
アプリケーションの起動は、デスクトップの起動と同様に扱われます。両方に同じ推奨事項が適用されますが、Citrixは起動率も考慮することを推奨しています。単一のユーザーが複数のアプリケーションを起動する可能性があり、それによって停止中のブローカーにかかるユーザーあたりの負荷が増加します。
アプリケーション容量を計算する際は、ユーザーあたりの平均アプリケーション起動数を把握し、ゾーンあたり25,000という同じ推奨値内に維持してください。
概要
サイトデータベースの停止中、LHCは幅広いリソースと条件をサポートしますが、運用時にはCPUとメモリの計画と考慮が必要です。
複数のブローカーサイトでは、どのブローカーも停止ブローカーとして選出される可能性があり、そのため、すべてのブローカーが停止モードで対処できる十分なリソースを持っている必要があります。ブローカーのリソース評価は行われないため、リソース量が異なるブローカーが存在するサイトでは、停止中に最も性能の低いブローカーが選出される可能性があります。
コアとソケットのレイアウトは、ブローカーの設計の一部として考慮する必要があります。
公開されているアプリケーションとデスクトップの数は、ログオン応答時間と最大ログオンスループットに影響を与えます。
CPUリソースが不足しているブローカーでは、起動に失敗する可能性があります。
Citrixは、アンチウイルス除外を定義することを推奨しています。詳細については、技術文書：エンドポイントセキュリティ、アンチウイルス、アンチマルウェアのベストプラクティスを参照してください。
LHC停止モードでのパフォーマンスをテストするための良い出発点として、追加で2つのコアと2GBのRAMが挙げられます。
LocalDBデータベースには1GBのディスク容量で十分です。
過負荷状態のブローカーは、接続失敗の原因となります。