ローカルホストキャッシュのサイズ設定とスケーリング

注：

この記事では、ローカルホストキャッシュ（LHC）を使用するXenApp およびXenDesktopの展開における推奨サイズおよびスケールについて説明します。Citrix DaaS のサイズとスケールの推奨事項については、「 Cloud Connectorのサイズとスケールの考慮事項」を参照してください。

LHC は、停止中も接続仲介を継続できるようにすることで、高可用性を実現します。LHC を使用するユーザーは、以下の設計上の考慮事項を守ってください。

• 停止中は、ゾーンごとに1つのブローカーがVirtual Delivery Agent（VDA）の登録とブローカーセッションを処理します。
• どのブローカーをアクティブにするかを決定する選挙プロセスでは、ブローカーのリソースは考慮されません。
• ゾーン内の 1 つのブローカーが通常の操作ですべてのログオンを処理できない場合、停止モードでは正常に動作しません。
• 停止中は、サイト管理は利用できません。
• 高可用性の 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 プロセスとして表示されます。データベースバッファプールのキャッシュに最大 1 GB のメモリを使用するように構成されています。ただし、SQL エンジンが自身や他の小さなキャッシュのためにメモリを必要とするため、プロセスはこれ以上大きくなります。一般に、停止時間が長くなり、停止モード中にアクセスされるリソースが増えるほど、LocalDB のメモリ使用量が増えます。ただし、サイトデータベースの接続が復元されると、sqlserver.exe はこのメモリを保持し、すぐにメインプールに戻すことはありません。

停止モード中の CPU ソケットとコアの影響

LHC は LocalDB と呼ばれるランタイムバージョンの SQL Server を使用しています。このバージョンには、4 コアまたは 1 ソケットのうち小さいほうに制限される特定のライセンスがあります。これは、物理マシンまたは仮想マシンがシングルコアまたはデュアルコアのみの複数のソケットで構成されている場合に、パフォーマンスに大きな影響を与える可能性があります。ソケットが4つあり、ソケットごとに1つのコアを持つブローカーマシンでは、LocalDBは1つのコアしか使用できません。一方、同じVMが1ソケット、4コアのマシンとして構成されている場合、LocalDBは4つのコアすべてにアクセスできます（他のプロセスと共有しますが）。停止モードでは、LocalDB は通常の操作時と同じブローカーと SQL コードを実行します。SQL クエリの多くはCPUを大量に消費し、停止モード中の仲介のパフォーマンスに直接影響します。詳細については、「 クラウドコネクタのサイズとスケールの考慮事項 」と「 SQL Serverのエディションごとの計算能力の制限」を参照してください。

その他の要因には、次のようなサイト構成自体が含まれます。

• 公開されたアプリケーションの数
• 仲介されているユーザーの数
• ユーザーがセッションを起動しようとする頻度
• Active Directory パフォーマンス

ブローカーの総CPU使用率が 100% に近づくと、仲介の応答時間が長くなり、ログオンの処理に時間がかかり、一部のログオン試行が失敗する可能性があります。

複数のブローカーがあるサイト

サイト停止モードでは、登録要求とログオン要求を処理するブローカーは 1 つだけです。マルチブローカーのサイトでは、停止中にアクティブになるブローカーを指名するための選挙プロセスが行われます。ただし、この選挙プロセスでは、ブローカーが利用できる物理的リソースは考慮されません。これは、ブローカーが異なるリソース量を持つサイトでは、選択されたブローカーが必ずしもCPUまたはRAMの点で最も強力であるとは限らず、停止モード中のパフォーマンスの低下につながる可能性があることを意味します。当選された場合に備えて、各ブローカーがLHCの追加要件を満たしていることが重要です。

サイトデータベースとの同期

CitrixConfigSync Serviceは、サイトデータベースからブローカーのローカルコピーへのデータのインポートを処理します。サイト構成の変更についてサイトデータベースを監視し、変更が発生すると新しいインポートをトリガーします。インポートが開始される前に、現在のローカルデータベースのコピーが作成されます。サイト内のリソース（VDAなど）の数が多いほど、インポートにかかる時間は長くなりますが、10,000個のVDAがあるサイトの場合は10分未満になるはずです。

データベースロケーション

ローカルデータベースは次の場所に格納されます。

C:\Windows\ServiceProfiles\NetworkService\HaDatabaseName.mdf

信頼性を確保するために、CitrixConfigSync Serviceは、新しいサイトデータベースの同期を開始する前に、以前に正常に同期されたデータベースインポートのバックアップを作成します。何らかの理由で同期が正常に完了しなかった場合、同期が正常に完了するまでバックアップが使用されます。データベースは手動でコピーしないでください。

ローカルホストキャッシュの技術仕様

ローカルホストキャッシュの有効化または無効化

LHC は必要に応じて有効または無効にできます。

制限事項

デスクトップは、停止モードで使用する前に割り当てられている必要があります。未割り当てのデスクトップは仲介できません。これにより、ユーザーに実際にデスクトップが割り当てられているにもかかわらず、すべての割り当てが同期される前に停止が発生した場合、デスクトップが使用できなくなり、「メンテナンスモード」と報告される可能性があります。

プールされたデスクトップは、デフォルト構成では停止モードではサポートされていません。回避策はありますが、セキュリティとパフォーマンスに影響する可能性があります。プールされたデスクトップを含むデリバリーグループをログオフ時に再起動しないように構成すると、そのグループ内のパワーオン状態のプールされたデスクトップはすべて停止モードで使用可能になります。ただし、ユーザーがログオフすると、デスクトップは再起動されないため、デスクトップはクリーンな状態にはなりません。これは、どのようなシナリオでもセキュリティ上の問題になる可能性があります。そのデスクトップの次のユーザーがそのデスクトップのローカル管理者である場合、前のユーザーのデータにアクセスできる可能性があります。また、このリスクは標準（管理者以外）のユーザーにとってはそれほど問題ではありませんが、アプリケーションが不適切に動作し、時間の経過とともにパフォーマンスの問題を引き起こす可能性があることに注意してください。重要: 管理者は、再起動されていないプールされたデスクトップを停止状態モードで使用する場合に、この回避策を使用することによる潜在的な影響を慎重に検討する必要があります。

停止中は、サイトを変更することはできません。データベースは実質的にメインサイトデータベースのスナップショットであり、新しい同期が行われるたびに破棄されます。

データベースサイズ

10,000 VDI 構成 (つまり 10,000 台のシングルセッション VDI デスクトップ) では、LocalDB は約75 MBでした。100,000 RDS 構成 (つまり 100,000 ユーザー) の場合、LocalDB はアプリケーションとログオンの数に応じて 100 ～ 300 MB の範囲で変動しました。新しいインポートが開始される前にデータベースのコピーが作成されるため、LocalDB 用に 1 GB の領域を確保してください。

ユーザーサイジングに関する考慮事項

ゾーンあたり最大10,000のVDAですが、停止中はセッションが選択したブローカーの負荷に寄与するため、Citrixではゾーンごとのピークセッションも考慮することを推奨します。マルチセッションVDAを使用すると、1つのVDAに対して複数のセッションを開始できるため、セッション密度が重要になります。

停止中の推奨ピークユーザー数は、ゾーンあたり 25,000 ユーザーです。適切な規模であれば、1 分あたり 1 ～ 2,000 個のリソース起動に達する可能性があります。

アプリケーションの起動はデスクトップの起動と同様に扱われます。どちらにも同じ推奨事項が適用されますが、Citrixでは起動率も考慮することを推奨しています。1人のユーザーが複数のアプリケーションを起動する可能性があるため、停止中にユーザーごとにブローカーにかかる負荷が増加します。

アプリケーション容量を計算する際には、ユーザーごとに起動されるアプリケーションの平均数を把握し、同じ推奨値 (ゾーンあたり 25,000) の範囲内に抑えてください。

概要

サイトデータベースの停止中、LHC はさまざまなリソースと条件をサポートしますが、運用時には CPU とメモリの計画と考慮が必要です。

複数のブローカーサイトでは、どのブローカーも停止ブローカーとして選出される可能性があるため、すべてのブローカーが停止モードに対処するのに十分なリソースを持っている必要があります。ブローカーリソースの評価は行われないため、さまざまなリソースを持つブローカーがいるサイトでは、停止時に最も強力なブローカーが選出される可能性があります。

コアとソケットのレイアウトは、ブローカーの設計の一部として考慮する必要があります。

公開アプリケーションとデスクトップの数は、ログオン応答時間と最大ログオンスループットに影響します。

CPU リソースが不足しているブローカーでは、起動に失敗する可能性があります。

Citrix では、ウイルス対策の除外を定義することを推奨します。詳細については、「 テックペーパー:エンドポイントセキュリティ、ウイルス対策、およびマルウェア対策のベストプラクティス」を参照してください。

LHC 停止モードでのパフォーマンスをテストするには、まず 2 つのコアと 2 GB の RAM を追加するとよいでしょう。

LocalDB データベースには 1 GB のディスク容量で十分です。

ブローカーが過負荷になると、接続に失敗します。