ローカルホストキャッシュ
Citrix Virtual Apps and Desktopsサイトデータベースを常に使用可能状態にするために、Microsoft社の高可用性ベストプラクティスに従って、耐障害性の高いSQL Server展開から開始することをお勧めします（SQL Serverのサポートされる高可用性機能については、「データベース」を参照してください）。ただし、ネットワークの問題および中断によって、ユーザーがアプリケーションやデスクトップに接続できなくなる場合があります。
ローカルホストキャッシュ（LHC：Local Host Cache）機能を使用すると、停止状態が発生しても、サイトの接続仲介操作を続行できます。オンプレミスのCitrix環境でDelivery Controllerとサイト構成データベースとの間の接続が失敗すると、停止状態が発生します。ローカルホストキャッシュは、サイトデータベースに90秒間アクセスできない場合に使用されます。
XenAppおよびXenDesktop 7.16より、接続リース機能（以前のリリースでの高可用性機能）は削除され、使用できなくなりました。
データコンテンツ
ローカルホストキャッシュには、メインデータベースの情報の一部として次の情報が格納されます：
- サイトから公開されたリソースに対する特別な権限が割り当てられているユーザーおよびグループのID
- サイトの公開リソースを現在使用しているか、最近使用したユーザーのID
- サイトに構成されているVDAマシン（リモートPCアクセスマシンを含む）のID
- 公開リソースへの接続で頻繁に使用されているCitrix ReceiverクライアントマシンのID（名前とIPアドレス）
また、メインデータベースが利用できなくなったときに確立され、現在アクティブな接続に関する情報も格納されています：
- Citrix Receiverで実行されたクライアントマシンのエンドポイント分析の結果
- サイトに関連するインフラストラクチャマシン（NetScaler GatewayやStoreFrontサーバーなど）のID
- ユーザーによる最近のアクティビティの日時とタイプ
機能
次の図は、通常の操作中のローカルホストキャッシュコンポーネントと通信経路を示しています。
通常の操作中：
- Controller上のプリンシパルブローカー（Citrix Broker Service）は、StoreFrontから接続要求を受け取り、サイトデータベースと通信して、Controllerに登録されているVDAにユーザーを接続します。
- プリンシパルブローカーの構成が変更されたかどうか判断するために、定期的（前のチェックが完了してから1分後）にチェックが行われます。この変更は、PowerShell/Studioの操作（デリバリーグループプロパティの変更など）によっても、システム操作（マシン割り当てなど）によっても開始できます。
- 最後のチェック以降に変更されると、Citrix Config Synchronizer Service（CSS）は、Controller上のCitrix High Availability Serviceに情報を同期（コピー）します。（ドキュメントによっては、High Availability Serviceはセカンダリブローカーと呼ばれます）。前回のチェック以降に変更された項目のみでなく、すべてのブローカー構成データがコピーされます。High Availability Serviceは、Controller上のMicrosoft SQL Server Express LocalDBデータベースにデータをインポートします。CSSにより、LocalDBデータベース内の情報がサイト構成データベース内の情報と一致することが保証されます。LocalDBデータベースは、同期が発生するたびに再作成されます。
- 最後のチェック以降に変更が発生しなかった場合、データはコピーされません。
次の図に、プリンシパルブローカーがサイトデータベースとの接続を失った（停止状態が開始された）場合の通信径路の変化を示します。
停止状態が開始された場合：
- プリンシパルブローカーはサイトデータベースと通信できなくなり、StoreFrontおよびVDA情報（図中のX印）のリスニングを停止します。次に、プリンシパルブローカーは、接続要求（図中の赤い点線）のリスニングと処理を開始するように、High Availability Serviceに指示します。High Availability Serviceは、CSSからのすべてのコールを破棄します。
- 停止状態の開始時には、High Availability Serviceにその時点のVDA登録データはありませんが、VDAとの通信が始まるとすぐに再登録処理がトリガーされます。その処理中に、High Availability Serviceは、そのVDAに関する現在のセッション情報も取得します。
- High Availability Serviceが接続を処理する間、プリンシパルブローカーは、サイト構成データベースへの接続の監視を続行します。接続が回復すると、プリンシパルブローカーは、High Availability Serviceに接続情報のリスニングを停止するように指示し、操作の仲介を再開します。再登録処理は、VDAがプリンシパルブローカーと次に通信するときにトリガーされます。High Availability Serviceは、前の停止状態時のVDA登録が残っていればそれを削除し、CSSから受け取った構成変更によるLocalDBデータベースの更新を再開します。
通常モードと停止モードとの間の移行は、既存のセッションには影響しません。新しいセッションの起動にのみ影響します。
同期中に停止状態が開始されるという可能性の低い事象では、その時点のインポートは破棄され、最新の既知の構成が使用されます。
イベントログには、同期および停止に関する情報が含まれます。詳しくは、下の「モニター」セクションを参照してください。
また、停止状態を意図的にトリガーすることもできます。理由と方法について詳しくは「停止状態の強制」セクションを参照してください。
複数のControllerがあるサイト
CSSは、他のタスク同様、ゾーン内のすべてのControllerに関する情報を定期的にHigh Availability Servicegへ提供します（展開に複数のゾーンがない場合、この操作はサイト内のすべてのControllerに影響します）。その情報により、各High Availability Serviceは、同じ立場にあるすべてのHigh Availability Serviceを認識します。
High Availability Serviceは、独立したチャネルで相互に通信します。それらが実行されているマシンのFQDN名の一覧（アルファベット順の）を使用して、停止状態が発生したときにどのHigh Availability Serviceがゾーン内の仲介操作を担当するかを決定（選出）します。停止状態の間に、すべてのVDAが、選出されたHigh Availability Serviceに再登録されます。ゾーン内の選出されていないHigh Availability Serviceは、着信接続とVDA登録要求を能動的に拒否します。
停止状態の間に、選出されたHigh Availability Serviceで障害が発生した場合は、引き継ぎを行う別のHigh Availability Serviceが選出され、VDAは新しく選出されたHigh Availability Serviceに再登録されます。
停止状態中にControllerを再起動した場合：
- このControllerをプライマリブローカーに選出していない場合は、再起動しても影響はありません。
- このControllerをプライマリブローカーに選出している場合は、別のControllerが選出されてVDAはそちらに再登録します。再起動したControllerの電源がオンになると、このControllerが自動的にブローカーを引き継ぐため、VDAはもう一度再登録します。このシナリオでは、再登録中にパフォーマンスが影響を受けることがあります。
プライマリブローカーに選出したControllerを、通常の操作中に電源を切ってから停止状態中に電源を入れると、ローカルホストキャッシュをこのController上で使用することはできません。
イベントログには、選出に関する情報が含まれます。後述の「モニター」セクションを参照してください。
設計に関する考慮事項および要件
停止モードでの操作に時間制限は適用されませんが、可能な限り速やかにサイトを通常操作に復元するようにします。
停止状態中にできなくなること、およびその他の相違点
- 管理者はStudioやPowerShellコマンドレットを使用できません。
- ハイパーバイザー資格情報をホストサービスから取得できません。すべてのマシンの電力状態が不明で、電源操作を発行できません。ただし、電源が入っているホスト上のVMを接続要求のために使用することができます。
- 割り当てられたマシンは、通常の操作中に割り当てが発生した場合のみ使用できます。停止状態中は新しい割り当てはできません。
- リモートPCアクセスマシンの自動登録と構成はできません。ただし、通常の操作中に登録、構成されたマシンは使用できます。
- サーバーでホストされるアプリケーションとデスクトップのユーザーは、リソースが異なるゾーンにある場合、構成されている最大セッション数よりも多くのセッションを使用できる場合があります。
- ユーザーは、現在アクティブな選出されたHigh Availability Serviceを含むゾーン内の登録済みVDAからのみ、アプリケーションとデスクトップを起動できます。停止状態の間は、ゾーン間での起動（あるゾーン内のHigh Availability Serviceから別のゾーン内のVDAへ）はサポートされません。
- デリバリーグループ内のVDAに対してスケジュールされた再起動が開始される前にサイト構成データベースの停止が発生した場合、停止が終了すると再起動が開始されます。これは意図しない結果につながる可能性があります。詳しくは、「データベースの停止によるスケジュールされた再起動の遅延」を参照してください。
- タグを使用してゾーンを指定するタグ制限機能は、セッション起動ではサポートされていません。このタグ制限が構成されていて、StoreFrontストアの ［詳細なヘルスチェック］ オプションが有効になっている場合、セッションが断続的に起動に失敗することがあります。
ローカルホストキャッシュは、サーバーでホストされるアプリケーションおよびデスクトップ、および静的な（割り当て済み）デスクトップでサポートされています。
デフォルトでは、ShutdownDesktopsAfterUseプロパティが有効になっているプールされたデリバリーグループ（MCSまたはCitrix Provisioningによって作成）内の電源管理されたデスクトップVDAは、ローカルホストキャッシュイベント中に新しい接続で使用できません。このデフォルトを変更して、ローカルホストキャッシュ中にこれらのデスクトップを使用できるようにすることが可能です。ただし、停止状態中は電源管理が機能しないことがあります。（通常の操作を開始すると電源管理が始まります）。また、これらのデスクトップは再起動していないため、前のユーザーのデータが含まれている可能性があります。
デフォルトの動作を上書きするには、サイト全体で、影響を受けるデリバリーグループごとに、これを有効にする必要があります。次のPowerShellコマンドレットを実行します。
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
この機能をサイトでデリバリーグループごとに有効にしても、構成済みの「ShutdownDesktopsAfterUse」プロパティの、通常操作時の動作には影響がありません。この機能を有効にすると、LHCイベントの完了後にVDAは自動的に再起動しません。プールされたデリバリーグループ内の電源管理されたデスクトップVDAは、VDAが再起動されるまで以前のセッションのデータを保持できます。これは、ユーザーがLHC以外の操作中にVDAからログオフした場合、または再起動が手動でトリガーされた場合に発生する可能性があります。
重要：
サイトレベルでReuseMachinesWithoutShutdownInOutageAllowedを有効にし、デリバリーグループレベルでReuseMachinesWithoutShutdownInOutageを有効にしないと、プールされたデリバリーグループ内の電源管理されたデスクトップVDAに対するすべてのセッション起動の試みが、ローカルホストキャッシュイベント中に失敗します。
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つのHigh Availability Serviceがすべての接続を処理するため、通常操作時に複数のControllerに負荷を分散するサイト（またはゾーン）では、停止状態時に、選出されたHigh Availability Serviceが通常よりはるかに多くの要求を処理しなければならない場合があります。このため、CPUへの要求が高くなります。選出されたHigh Availability Serviceが停止状態時に変更される可能性があるので、サイト（ゾーン）内のすべてのHigh Availability Serviceが、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をHigh Availability Serviceに再登録する間は、High Availability Serviceでは現在のセッションの情報を完全には把握できないことがあります。このため、その間の接続要求により、既存のセッションへの再接続が可能であっても、新しいセッションが起動される可能性があります。こうした時間（「新しい」High Availability Serviceが再登録時にすべてのVDAからセッション情報を取得する時間）が発生するのは避けられません。停止状態の開始時に接続していたセッションは移行期間に影響は受けませんが、新しいセッションおよびセッション再接続は影響を受ける可能性がある点に注意してください。
この期間は、VDAの再登録が必要なときには必ず発生します：
- 停止状態の開始：プリンシパルブローカーからHigh Availability Serviceに移行するとき。
- 停止状態時のHigh Availability Serviceの障害：障害の発生したHigh Availability Serviceから、新しく選出されたHigh Availability Serviceに移行するとき。
- 停止からの回復：通常の操作が再開し、プリンシパルブローカーが制御を再開したとき。
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
ハートビート値を変更するときは注意が必要です。頻度を増やすと、通常モードと停止モードのどちらの間でも、Controllerの負荷が増加します。
VDAの登録をどんなに早くしても、間隔を完全になくすことはできません。
High Availability Service間の同期にかかる時間は、オブジェクト（VDA、アプリケーション、グループなど）の数とともに増加します。たとえば、5000のVDAの同期を完了するには、10分以上かかる可能性があります。イベントログの同期エントリについて詳しくは、「モニター」を参照してください。
XenApp 6.xリリースとの相違点
このローカルホストキャッシュ実装は、XenApp 6.x以前のXenAppリリースのローカルホストキャッシュ機能の名前を共有しますが、大幅に改善されています。この実装は、破損に対してより頑強で耐性もあります。定期的にdsmaintコマンドを実行する必要がないなど、メンテナンス要件が最小になります。このローカルホストキャッシュは技術的にはまったく異なる実装です。
ローカルホストキャッシュの管理
ローカルホストキャッシュを正常に動作させるには、各Controller上のPowerShell実行ポリシーを、RemoteSigned、Unrestricted、またはBypassに設定する必要があります。
SQL Server Express LocalDB
ローカルホストキャッシュが使用するMicrosoft SQL Server Express LocalDBは、Controllerをインストールするか、Controllerを7.9以前のバージョンからアップグレードするときに、自動的にインストールされます。LocalDBを管理者がメンテナンスする必要はありません。High Availability Serviceのみがこのデータベースと通信します。PowerShellコマンドレットを使用して、このデータベースに関する変更を行うことはできません。LocalDBは、Controller間で共有できません。
SQL Server Express LocalDBデータベースソフトウェアは、ローカルホストキャッシュが有効かどうかに関係なくインストールされます。
このインストールを防止するには、Controllerのインストールまたはアップグレード時に、XenDesktopServerSetup.exeコマンドで「/exclude "Local Host Cache Storage (LocalDB)"」オプションを使用します。ただし、ローカルホストキャッシュ機能はデータベースがないと機能しないことと、High Availability Serviceでは異なるデータベースを使用できないことに注意してください。
このLocalDBデータベースのインストールは、サイトデータベースとして使うためにSQL Server Expressをインストールするかどうかには影響しません。
以前のバージョンのSQL Server Express LocalDBを新しいバージョンに置き換える方法について詳しくは、「SQL Server Express LocalDBの置き換え」を参照してください。
製品のインストールとアップグレード後のデフォルト設定
Citrix Virtual Apps and Desktops（バージョン7.16以降）の新規インストール時に、ローカルホストキャッシュが有効になります。アップグレード（バージョン7.16以降へ）後は、展開全体に10,000個未満のVDAが存在する場合に、ローカルホストキャッシュが有効になります。
ローカルホストキャッシュの有効化と無効化
-
ローカルホストキャッシュを有効化するには、次のように入力します：
Set-BrokerSite -LocalHostCacheEnabled $trueローカルホストキャッシュが有効かどうかを判断するには、次のように入力します。
Get-BrokerSiteLocalHostCacheEnabledプロパティがTrueであることを確認します。
-
ローカルホストキャッシュを無効にするには、次のように入力します。
Set-BrokerSite -LocalHostCacheEnabled $false
注意：XenAppおよびXenDesktop 7.16より、接続リース機能（バージョン7.6以降に提供されていた、ローカルホストキャッシュに先行する機能）は削除され、使用できなくなりました。
ローカルホストキャッシュが動作していることを確認する
ローカルホストキャッシュが適切に設定され動作していることを確認するには：
- 同期のインポートが正常に完了していることを確認します。イベントログをチェックします。
- 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を含む各サーバーのレジストリを編集します。HKLM\Software\Citrix\DesktopServer\LHCで、OutageModeForcedとしてのREG_DWORDを1に設定します。この指示により、ブローカーはデータベースの状態に関係なく停止状態モードに入ります値を0に設定すると、サーバーの停止状態モードが終了します。
監視
イベントログに、同期および停止状態が発生した時刻が示されます。
Config Synchronizer Service：
通常操作時に、CSSがブローカー構成をコピーおよびエクスポートして、High Availability Serviceを使用してLocalDBにインポートするときに、次のイベントが発生することがあります。
- 503： プリンシパルブローカー構成に変更が見つかり、インポートが開始されます。
- 504：ブローカー構成がコピーおよびエクスポートされて、LocalDBに正常にインポートされました。
- 505：LocalDBへのインポートが失敗しました。詳しくは下記を参照してください。
- 507：未解決の停止が原因で、インポートが中止されました。同期中に停止状態が開始されると、その時点のインポートは破棄され、最新の既知の構成が使用されます。
- 510：プライマリ構成サービスから構成サービス構成データを受信していません。
- 517：プライマリブローカーとの通信に問題がありました。
- 518：セカンダリブローカー（High Availability Service）が実行されていないため、Config Syncスクリプトが中止されました。
High Availability Service：
- 3502：停止状態が発生し、High Availability Serviceが操作の仲介を実行しています。
- 3503：停止状態が解決され、通常の操作が再開しました。
- 3504：どのHigh Availability Serviceが選出されたかと、選出に関わった他のHigh Availability Serviceを示します。
トラブルシューティング
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。