ローカルホストキャッシュ
XenAppおよびXenDesktopサイトデータベースを常に使用可能状態にするために、Microsoft社の高可用性ベストプラクティスに従って耐障害性の高いSQL Server展開から開始することをお勧めします（「システム要件」の「データベース」にXenAppおよびXenDesktopでサポートされているSQL Serverの高可用性機能が一覧にされています）。ただし、ネットワークの問題および中断によってユーザーがアプリケーションやデスクトップに接続できなくなる場合があります。
ローカルホストキャッシュ（LHC）機能を使用すると、停止状態が発生しても、XenAppまたはXenDesktopサイトの接続仲介操作を続行できます。Delivery Controllerとサイト構成データベースとの間の接続が失敗すると、停止状態が発生します。ローカルホストキャッシュは、サイトデータベースに90秒間アクセスできない場合に使用されます。
ローカルホストキャッシュは、XenAppおよびXenDesktopの最も包括的な高可用性機能です。XenApp 7.6で導入された接続リース機能のより強力な代替選択肢です。
このローカルホストキャッシュ実装は、XenApp 6.x以前のXenAppリリースのローカルホストキャッシュ機能の名前を共有しますが、大幅に改善されています。この実装は、破損に対してより頑強で耐性もあります。定期的にdsmaintコマンドを実行する必要がないなど、メンテナンス要件が最小になります。このローカルホストキャッシュは技術的にはまったく異なる実装です。以下、その仕組みについて説明します。
注：
バージョン7.15 LTSRでは接続リース機能はサポートされていますが、それ以降のリリースでは削除される予定です。
データコンテンツ
ローカルホストキャッシュには、メインデータベースの情報の一部として次の情報が格納されます：
- サイトから公開されたリソースに対する特別な権限が割り当てられているユーザーおよびグループのID
- サイトの公開リソースを現在使用しているか、最近使用したユーザーのID
- サイトに構成されているVDAマシン（リモートPCアクセスマシンを含む）のID
- 公開リソースへの接続で頻繁に使用されているCitrix ReceiverクライアントマシンのID（名前とIPアドレス）
また、メインデータベースが利用できなくなったときに確立され、現在アクティブな接続に関する情報も格納されています：
- Citrix Receiverで実行されたクライアントマシンのエンドポイント分析の結果
- サイトに関連するインフラストラクチャマシン（NetScaler GatewayやStoreFrontサーバーなど）のID
- ユーザによる最近のアクティビティの日時とタイプ
機能
次の図は、通常の操作中のローカルホストキャッシュコンポーネントと通信経路を示しています。
通常の操作中：
- Controller上のプリンシパルブローカー（Citrix Broker Service）は、StoreFrontから接続要求を受け取り、サイトデータベースと通信して、Controllerに登録されているVDAにユーザーを接続します。
- 2分おきにチェックして、プリンシパルブローカーの構成が変更されたかどうか判断します。この変更は、PowerShell/Studioの操作（デリバリーグループプロパティの変更など）によっても、システム操作（マシン割り当てなど）によっても開始できます。
- 最後のチェック以降に変更されると、プリンシパルブローカーは、Citrix Config Synchronizer Service（CSS）を使用してController上のセカンダリブローカー（Citrix High Availability Service）に情報を同期（コピー）します。前回のチェック以降に変更された項目だけでなく、すべてのブローカー構成データがコピーされます。セカンダリブローカーは、Controller上のMicrosoft SQL Server Express LocalDBデータベースにデータをインポートします。CSSにより、セカンダリブローカーのLocalDBデータベースの情報がサイトデータベースの情報に一致することが保証されます。LocalDBデータベースは、同期が発生するたびに再作成されます。
- 最後のチェック以降に変更が発生しなかった場合、データはコピーされません。
次の図は、プリンシパルブローカーがサイトデータベースとの接続を失った場合の通信径路の変更を示しています（停止状態の開始）：
停止状態が開始された場合：
- プリンシパルブローカーはサイトデータベースと通信できなくなり、StoreFrontおよびVDA情報（図中のX印）のリスニングを停止します。次に、プリンシパルブローカーは、接続要求（図中の赤い点線）のリスニングと処理を開始するように、セカンダリブローカー（High Availability Service）に指示します。
- 停止状態の開始時に、セカンダリブローカーにはその時点のVDA登録データがありませんが、VDAとの通信が始まるとすぐに再登録処理がトリガーされます。その処理中、セカンダリブローカーは、そのVDAに関する現在のセッション情報も取得します。
- セカンダリブローカーが接続を処理する間、プリンシパルブローカーはサイトデータベースへの接続の監視を続行します。接続が回復すると、プリンシパルブローカーはセカンダリブローカーに接続情報のリスニングを停止するように指示し、プリンシパルブローカーが操作の仲介を再開します。再登録処理は、VDAがプリンシパルブローカーと次に通信するときにトリガーされます。セカンダリブローカーは、前回の停止状態以降に残ったVDA登録があれば削除して、CSSから受け取った構成変更によるLocalDBデータベースの更新を再開します。
同期中に停止状態が開始されるという可能性の低い事象では、その時点のインポートは破棄され、最新の既知の構成が使用されます。
イベントログには、同期および停止に関する情報が含まれます。詳しくは、下の「モニター」セクションを参照してください。
また、停止状態を意図的にトリガーすることもできます。理由と方法について詳しくは「停止状態の強制」セクションを参照してください。
複数のControllerがあるサイト
CSSは、他のタスク同様、ゾーン内のすべてのControllerに関する情報を日常作業としてセカンダリブローカーに提供します（展開に複数のゾーンがない場合、この操作はサイト内のすべてのControllerに影響します）。その情報により、各セカンダリブローカーは、同じ立場にあるすべてのセカンダリブローカーを認識します。
セカンダリブローカーは独立したチャネルで相互に通信します。実行しているマシンのFQDN名のアルファベット順の一覧を使用して、停止状態が発生したときにどのセカンダリブローカーがゾーン内の仲介操作を担当するかを決定（選出）します。停止状態中、すべてのVDAが、選出されたセカンダリブローカーに再登録します。選出されていないゾーン内のセカンダリブローカーは、着信接続とVDA登録要求を能動的に拒否します。
停止状態中に、選出されたセカンダリブローカーに障害が発生した場合、別のセカンダリブローカーが選出されて引き継ぎ、VDAは選出されたセカンダリブローカーに新しく再登録します。
停止状態中にControllerを再起動した場合：
- このControllerをプライマリブローカーに選出していない場合は、再起動しても影響はありません。
- このControllerをプライマリブローカーに選出している場合は、別のControllerが選出されてVDAはそちらに再登録します。再起動したControllerの電源がオンになると、このControllerが自動的にブローカーを引き継ぐため、VDAはもう一度再登録します。このシナリオでは、再登録中にパフォーマンスが影響を受けることがあります。
プライマリブローカーに選出したControllerを、通常の操作中に電源を切ってから停止状態中に電源を入れると、ローカルホストキャッシュをこのController上で使用することはできません。
イベントログには、選出に関する情報が含まれます。後述の「モニター」セクションを参照してください。
設計に関する考慮事項および要件
ローカルホストキャッシュは、サーバーでホストされるアプリケーションおよびデスクトップと静的な（割り当て済み）デスクトップでサポートされます。プール型のVDIデスクトップ（MCSやPVSで作成）ではサポートされません。
停止モードでの操作に時間制限は適用されませんが、可能な限り速やかにサイトを通常操作に復元するようにします。
停止状態中にできなくなることと変更されること：
- 管理者はStudioやPowerShellコマンドレットを使用できません。
- ハイパーバイザー資格情報をホストサービスから取得できません。すべてのマシンの電力状態が不明で、電源操作を発行できません。ただし、電源が入っているホスト上のVMを接続要求のために使用することができます。
- 割り当てられたマシンは、通常の操作中に割り当てが発生した場合のみ使用できます。停止状態中は新しい割り当てはできません。
- リモートPCアクセスマシンの自動登録と構成はできません。ただし、通常の操作中に登録、構成されたマシンは使用できます。
- サーバーでホストされるアプリケーションとデスクトップのユーザーは、リソースが異なるゾーンにある場合、構成されている最大セッション数よりも多くのセッションを使用できる場合があります。
- ユーザーは、現在アクティブ/選択されている（セカンダリ）ブローカーを含むゾーン内の登録済みVDAからのみ、アプリケーションとデスクトップを起動できます。停止状態中は、ゾーン間での起動（あるゾーンのブローカーから別のゾーンのVDAへ）はサポートされません。
停止状態が発生した場合、ShutdownDesktopsAfterUseプロパティが有効なデリバリーグループにプールされている電源管理対象のデスクトップVDAは、デフォルトで保守モードになります。このデフォルトの設定を変更して、停止状態中にこれらのデスクトップを使用できるようにすることができます。ただし、停止状態中は電源管理が機能しないことがあります。（通常の操作を開始すると電源管理が始まります）。また、これらのデスクトップは再起動していないため、前のユーザーのデータが含まれている可能性があります。
デフォルトの動作を上書きするには、サイト全体で、影響を受けるデリバリーグループごとに、これを有効にする必要があります。
サイトに対して次のPowerShellコマンドレットを実行します：
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
影響を受ける各デリバリーグループに対して、次のPowerShellコマンドレットを実行します：
Set-BrokerDesktopGroup -Name "\<*name*\>" -ReuseMachinesWithoutShutdownInOutage $true
この機能をサイトでデリバリーグループごとに有効にしても、構成済みの「ShutdownDesktopsAfterUse」プロパティの、通常操作時の動作には影響がありません。
RAMサイズ：
LocalDBサービスは、約1.2GBのRAM（データベースキャッシュ用に最大1GB、SQL Server Express LocalDBの実行用にさらに200MB）を使用できます。High Availability Serviceは、停止状態が長時間続き、多数のログオンが発生した場合（たとえば12時間でユーザー数1万人）、最大1GBのRAMを使用できます。これらのメモリ要件はControllerの通常のRAM要件とは別なので、RAMの総容量を増やす必要がある場合があります。
サイトデータベースにSQL Server Expressインストールを使用する場合、サーバーに2つのsqlserver.exeプロセスを持つ点に注意してください。
CPUコアとソケットの構成：
ControllerのCPU構成、特にSQL Server Express LocalDBが利用できるコア数は、メモリ割り当て以上に、ローカルホストキャッシュのパフォーマンスに直接影響を及ぼします。このCPUオーバーヘッドが発生するのは、データベースとの接続が失われ、High Availability Serviceがアクティブである停止状態の間だけです。
LocalDBは複数のコア（最大4つ）を使用できますが、単一のソケットだけに制限されます。ソケットを追加しても（たとえば、4つのソケットにそれぞれ1つのコア）、パフォーマンスは向上しません。それよりも複数のコアを持つ複数のソケットの使用をCitrixではお勧めします。Citrixのテストでは、2x3（2つのソケット、3つのコア）の構成が、4x1および6x1の構成より良好なパフォーマンスを示しました。
ストレージ：
ユーザーが停止状態の間にリソースにアクセスすると、LocalDBは増大します。たとえば、1秒に10回ログオンするログオン/ログオフテスト実行では、データベースは2～3分に1MB増大しました。通常の操作が再開すると、ローカルデータベースが再作成され、容量は元に戻ります。ただし、停止状態中のデータベース増大を考慮に入れて、LocalDBがインストールされるドライブ上のブローカーは十分な容量を持つ必要があります。ローカルホストキャッシュを使用すると、停止状態中に追加のI/Oが生じます（数十万の読み取りで、1秒あたり約3MBの書き込み）。
パフォーマンス：
停止状態中は1つのブローカーがすべての接続を処理するため、通常の操作時に複数のControllerに負荷を分散するサイト（あるいは、ゾーン）では、停止状態中に、選出されたブローカーが普通よりはるかに多くの要求を処理する必要があることがあります。このため、CPUへの要求が高くなります。選出されたブローカーが停止状態中に変更される可能性があるため、サイト（ゾーン）内のすべてのブローカーが、LocalDBと影響を受けるすべてのVDAによって課される追加の負荷を処理できる必要があります。
VDIの制限事項：
- 単一ゾーンにVDIを展開する場合、停止状態時には最大10,000のVDAを効果的に処理できます。
- 複数ゾーンにVDIを展開する場合、停止状態時には各ゾーンで最大10,000のVDA、サイト全体では最大40,000のVDAを効果的に処理できます。たとえば次のそれぞれのサイトが、停止状態時に効果的に処理されます。
- 4つのゾーンそれぞれに10,000のVDAが含まれるサイト。
- 1つのゾーンには10,000のVDAが含まれ、残り6つのゾーンにはそれぞれ5,000のVDAが含まれる、合計7つのゾーンからなるサイト。
停止状態中に、サイト内の負荷管理が影響を受ける可能性があります。負荷評価基準（特にセッション数規則）を超過する可能性があります。
すべてのVDAがブローカーに再登録する間、そのブローカーには現在のセッションについての完全な情報がないことがあります。このため、その間の接続要求により、既存のセッションへの再接続が可能であっても、新しいセッションが起動される可能性があります。こうした時間（「新しい」ブローカーが再登録時にすべてのVDAからセッション情報を取得する時間）が発生するのは避けられません。停止状態の開始時に接続していたセッションは移行期間に影響は受けませんが、新しいセッションおよびセッション再接続は影響を受ける可能性がある点に注意してください。
この期間は、VDAが異なるブローカーに再登録する必要があるときは常に発生します。
- 停止状態の開始：プリンシパルブローカーからセカンダリブローカーに移行するとき。
- 停止状態中のブローカー障害：障害が発生したセカンダリブローカーから新しく選出されたセカンダリブローカーに移行するとき。
- 停止からの回復：通常の操作が再開し、プリンシパルブローカーが制御を再開したとき。
Citrix Broker ProtocolのHeartbeatPeriodMsレジストリ値（デフォルト = 600000ms（10分））を小さくすることによって期間を短縮できます。このハートビート値は、VDAがpingに使用する間隔の2倍であるため、デフォルト値では5分ごとにpingが発生します。
たとえば、ハートビートを5分（300000ms）に変更するには、次のコマンドを実行します。このようにすると、pingは2.5分ごとに発生します：
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000
VDAの登録をどんなに早くしても、間隔を完全になくすことはできません。
ブローカー間の同期にかかる時間は、オブジェクト（VDA、アプリケーション、グループなど）の数により増加します。たとえば、5000個のVDAを同期する場合には、10分以上かかる可能性があります。イベントログの同期エントリについて詳しくは、後述の「モニター」セクションを参照してください。
ローカルホストキャッシュの管理
ローカルホストキャッシュを正常に動作させるには、各Controller上のPowerShell実行ポリシーを、RemoteSigned、Unrestricted、またはBypassに設定する必要があります。
SQL Server Express LocalDB
ローカルホストキャッシュが使用するMicrosoft SQL Server Express LocalDBは、Controllerをインストールするか、Controllerを7.9以前のバージョンからアップグレードするときに、自動的にインストールされます。LocalDBを管理者がメンテナンスする必要はありません。セカンダリブローカーだけがこのデータベースと通信します。PowerShellコマンドレットを使用してこのデータベースに関する変更を行うことはいっさいできません。LocalDBは、Controller間で共有できません。
SQL Server Express LocalDBデータベースソフトウェアは、ローカルホストキャッシュが有効かどうかに関係なくインストールされます。
このインストールを防止するには、Controllerのインストールまたはアップグレード時に、XenDesktopServerSetup.exeコマンドで「/exclude “Local Host Cache Storage (LocalDB)”」オプションを使用します。ただし、ローカルホストキャッシュ機能はデータベースがないと機能しないことと、セカンダリブローカーでは異なるデータベースを使用できないことに注意してください。
このLocalDBデータベースのインストールは、サイトデータベースとして使うためにSQL Server Expressをインストールするかどうかには影響しません。
XenAppまたはXenDesktopのインストールとアップグレード後のデフォルト設定
XenAppおよびXenDesktopの新規インストール時に、ローカルホストキャッシュはデフォルトで有効になっています。（接続リース機能は、デフォルトで無効になっています。）
アップグレード後、ローカルホストキャッシュ設定は変更されません。たとえば、ローカルホストキャッシュが以前のバージョンで有効にされていると、アップグレードされたバージョンでも引き続き有効になっています。以前のバージョンで無効な場合、またはサポートされていなかった場合、アップグレードされたバージョンでも無効のままです。
ローカルホストキャッシュの有効化と無効化
ローカルホストキャッシュを有効化するには、次のように入力します：
Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false
このコマンドレットは、接続リース機能も無効化します。ローカルホストキャッシュと接続リースの両方を有効化しないでください。
ローカルホストキャッシュが有効かどうかを判断するには、次のように入力します。
Get-BrokerSite
LocalHostCacheEnabledプロパティがTrueで、ConnectionLeasingEnabledプロパティがFalseであることを確認します。
ローカルホストキャッシュを無効化（および接続リースを有効化）するには、次のように入力します：
Set-BrokerSite -LocalHostCacheEnabled $false -ConnectionLeasingEnabled $true
ローカルホストキャッシュが動作していることを確認する
ローカルホストキャッシュが適切に設定され動作していることを確認するには：
- 同期のインポートが正常に完了していることを確認します。イベントログをチェックします。
- SQL Server Express LocalDBデータベースがDelivery Controllerごとに作成されたことを確認します。これにより、必要に応じてHigh Availability Serviceが処理を引き継げるようになります。
- Delivery Controllerサーバーで、C:\Windows\ServiceProfiles\NetworkServiceに移動します。
- HaDatabaseName.mdfおよびHaDatabaseName_log.ldfが作成されていることを確認します。
- Delivery Controllerに停止状態を強制します。ローカルホストキャッシュが動作することを確認したら、すべてのControllerを通常モードに戻します。この処理には、大量のVDA登録を避けるために15分程度かかることがあります。
停止状態の強制
データベースの停止状態を意図的に強制することもできます。
- ネットワークが稼動と停止を繰り返している場合。ネットワークの問題が解決するまで停止状態を強制することにより、通常モードと停止状態モードの移行が繰り返されるのを防げます。
- 障害回復プランをテストするには：
- サイトデータベースサーバーの交換または修理中。
停止状態を強制するには、Delivery Controllerを含む各サーバーのレジストリを編集します。
- HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\LHCで、［OutageModeForced］ を ［1］ に設定します。この指示により、ブローカーはデータベースの状態に関係なく停止状態モードに入ります （値を0に設定すると、サーバーの停止状態モードが終了します）。
- Citrix Cloudのシナリオでは、コントロールプレーンやプライマリゾーンへの接続の状態に関係なく、コネクタが停止状態モードに入ります。
モニター
イベントログに、同期および停止状態が発生した時刻が示されます。
Config Synchronizer Service：
通常の操作中に、CSSがブローカー構成をコピーおよびエクスポートして、High Availability Service（セカンダリブローカー）を使用してそれをLocalDBにインポートするとき、次のイベントが発生することがあります。
- 503： プリンシパルブローカー構成に変更が見つかり、インポートが開始されます。
- 504：ブローカー構成がコピーおよびエクスポートされて、LocalDBに正常にインポートされました。
- 505：LocalDBへのインポートが失敗しました。詳しくは下記を参照してください。
- 510：プライマリ構成サービスから構成サービス構成データを受信していません。
- 517：プライマリブローカーとの通信に問題がありました。
- 518：セカンダリブローカー（High Availability Service）が実行されていないため、Config Syncスクリプトが中止されました。
High Availability Service：
- 3502：停止状態が発生し、セカンダリブローカー（High Availability Service）が操作の仲介を実行しています。
- 3503：停止状態が解決され、通常の操作が再開しました。
- 3504：どのセカンダリブローカーが選出されたかと、選出に関わった他のブローカーを示します。
トラブルシューティング
LocalDBへの同期インポートが失敗し、505イベントがポストされた場合、いくつかのトラブルシューティングツールを利用できます。
CDFトレーシング： ConfigSyncServerモジュールおよびBrokerLHCモジュール向けのオプションが用意されています。それらのオプションと他のブローカーモジュールの組み合わせで問題を識別できるはずです。
レポート：同期インポートが失敗した場合、レポートを生成できます。このレポートの最後に、エラーの原因となったオブジェクトが記載されています。このレポート機能は同期速度に影響するため、Citrixでは使用しないときは無効にしておくことをお勧めします。
CSSトレースレポートを有効化および作成するには、次のコマンドを入力します：
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1
HTMLレポートはC:\\Windows\\ServiceProfiles\\NetworkService\\AppData\\Local\\Temp\\CitrixBrokerConfigSyncReport.htmlに格納されます。
レポートが生成されたら、次のコマンドを入力してレポート機能を無効にします：
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
ブローカー構成のエクスポート： デバッグのために正確な構成を提供します。
Export-BrokerConfiguration | Out-File file-pathname
たとえば、Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xmlなどです。