ローカルホストキャッシュ

XenApp的および的XenDesktopサイトデータベースを常に使用可能状态にするために，微软社の高可用性ベストプラクティスに従って耐障害性の高いSQL服务器展开から开始することをお勧めします（「システム要件”“のデータベースにXenAppおよびXenDesktopでサポートされているSQL Serverの高可用性機能が一覧にされています)。ただし,ネットワークの問題および中断によってユーザーがアプリケーションやデスクトップに接続できなくなる場合があります。

ローカルホストキャッシュ(LHC)機能を使用すると,停止状態が発生しても,XenAppまたはXenDesktopサイトの接続仲介操作を続行できます。交付控制器とサイト構成データベースとの間の接続が失敗すると,停止状態が発生します。ローカルホストキャッシュは,サイトデータベースに90秒間アクセスできない場合に使用されます。

ローカルホストキャッシュは，XenApp的および的XenDesktopの最も包括的な高可用性机能です.XenApp 7.6で导入された接続リース机能のより强力な代替选択肢です。

このローカルホストキャッシュ実装は,XenApp 6. x以前のXenAppリリースのローカルホストキャッシュ機能の名前を共有しますが,大幅に改善されています。この実装は,破損に対してより頑強で耐性もあります。定期的にdsmaintコマンドを実行する必要がないなど,メンテナンス要件が最小になります。このローカルホストキャッシュは技術的にはまったく異なる実装です。以下,その仕組みについて説明します。

注：

7.15バージョンLTSRでは接続リース機能はサポートされていますが,それ以降のリリースでは削除される予定です。

データコンテンツ

ローカルホストキャッシュには，メインデータベースの情报の一部として次の情报が格纳されます：

• サイトから公开されたリソースに対する特别な権限が割り当てられているユーザーおよびグループのID
• サイトの公開リソースを現在使用しているか,最近使用したユーザーのID
• サイトに构成されているVDAマシン（リモートPCアクセスマシンを含む）のID
• 公開リソースへの接続で頻繁に使用されているCitrix接收机クライアントマシンのID(名前とIPアドレス)

また，メインデータベースが利用できなくなったときに确立され，现在アクティブな接続に关する情报も格纳されています：

• Citrix接收机で実行されたクライアントマシンのエンドポイント分析の結果
• サイトに関連するインフラストラクチャマシン(NetScaler网关や店面サーバーなど)のID
• ユーザによる最近のアクティビティの日時とタイプ

机能

次の図は,通常の操作中のローカルホストキャッシュコンポーネントと通信経路を示しています。

通常の操作中：

• 控制器上のプリンシパルブローカー(Citrix代理服务)は店面から接続要求を受け取り,サイトデータベースと通信して,控制器に登録されているVDAにユーザーを接続します。
• 2分おきにチェックして,プリンシパルブローカーの構成が変更されたかどうか判断します。この変更はPowerShell /工作室の操作(デリバリーグループプロパティの変更など)によっても,システム操作(マシン割り当てなど)によっても開始できます。
• 最后のチェック以降に変更されると，プリンシパルブローカーは，配置的Citrix同步服务（CSS）を使用して控制器上のセカンダリブローカー（思杰高可用性服务）に情报を同期（コピー）します。前回のチェック以降に変更された项目だけでなく，すべてのブローカー构成データがコピーされます。セカンダリブローカーは，控制器上の微软的SQL Server Express的LocalDBデータベースにデータをインポートします.CSSにより，セカンダリブローカーの的LocalDBデータベースの情报がサイトデータベースの情报に一致することが保证されます.LocalDBデータベースは，同期が発生するたびに再作成されます。
• 最後のチェック以降に変更が発生しなかった場合,データはコピーされません。

次の図は,プリンシパルブローカーがサイトデータベースとの接続を失った場合の通信径路の変更を示しています(停止状態の開始):

停止状态が开始された场合：

• プリンシパルブローカーはサイトデータベースと通信できなくなり,店面およびVDA情報(図中のX印)のリスニングを停止します。次に,プリンシパルブローカーは,接続要求(図中の赤い点線)のリスニングと処理を開始するように,セカンダリブローカー(高可用性服务)に指示します。
• 停止状態の開始時に,セカンダリブローカーにはその時点のVDA登録データがありませんが,VDAとの通信が始まるとすぐに再登録処理がトリガーされます。その処理中,セカンダリブローカーは,そのVDAに関する現在のセッション情報も取得します。
• セカンダリブローカーが接続を処理する間,プリンシパルブローカーはサイトデータベースへの接続の監視を続行します。接続が回復すると,プリンシパルブローカーはセカンダリブローカーに接続情報のリスニングを停止するように指示し,プリンシパルブローカーが操作の仲介を再開します。再登録処理は,VDAがプリンシパルブローカーと次に通信するときにトリガーされます。セカンダリブローカーは、前回の停止状態以降に残ったVDA登録があれば削除して、CSSから受け取った構成変更によるLocalDBデータベースの更新を再開します。

同期中に停止状态が开始されるという可能性の低い事象では，その时点のインポートは破弃され，最新の既知の构成が使用されます。

イベントログには,同期および停止に関する情報が含まれます。詳しくは,下の”モニター”セクションを参照してください。

また，停止状态を意図的にトリガーすることもできます。理由と方法について详しくは「停止状态の强制」セクションを参照してください。

複数の控制器があるサイト

CSSは，他のタスク同様，ゾーン内のすべての控制器に关する情报を日常作业としてセカンダリブローカーに提供します（展开に复数のゾーンがない场合，この操作はサイト内のすべての控制器に影响します）。その情报により，各セカンダリブローカーは，同じ立场にあるすべてのセカンダリブローカーを认识します。

セカンダリブローカーは独立したチャネルで相互に通信します。実行しているマシンのFQDN名のアルファベット顺の一覧を使用して，停止状态が発生したときにどのセカンダリブローカーがゾーン内の仲介操作を担当するかを决定（选出）します。停止状态中，すべてのVDAが，选出されたセカンダリブローカーに再登录します。选出されていないゾーン内のセカンダリブローカーは，着信接続とVDA登录要求を能动的に拒否します。

停止状態中に,選出されたセカンダリブローカーに障害が発生した場合,別のセカンダリブローカーが選出されて引き継ぎ,VDAは選出されたセカンダリブローカーに新しく再登録します。

停止状態中に控制器を再起動した場合:

• この控制器をプライマリブローカーに選出していない場合は,再起動しても影響はありません。
• この控制器をプライマリブローカーに選出している場合は,別の控制器が選出されてVDAはそちらに再登録します。再起動した控制器の電源がオンになると,この控制器が自動的にブローカーを引き継ぐため,VDAはもう一度再登録します。このシナリオでは,再登録中にパフォーマンスが影響を受けることがあります。

プライマリブローカーに选出した控制器を，通常の操作中に电源を切ってから停止状态中に电源を入れると，ローカルホストキャッシュをこの控制器上で使用することはできません。

イベントログには,選出に関する情報が含まれます。後述の”モニター”セクションを参照してください。

設計に関する考慮事項および要件

ローカルホストキャッシュは，サーバーでホストされるアプリケーションおよびデスクトップと静的な（割り当て済み）デスクトップでサポートされます。プール型のVDIデスクトップ（MCSやPVSで作成）ではサポートされません。

停止モードでの操作に时间制限は适用されませんが，可能な限り速やかにサイトを通常操作に复元するようにします。

停止状态中にできなくなることと変更されること：

• 管理者は工作室やPowerShellコマンドレットを使用できません。
• ハイパーバイザー資格情報をホストサービスから取得できません。すべてのマシンの電力状態が不明で,電源操作を発行できません。ただし,電源が入っているホスト上のVMを接続要求のために使用することができます。
• 割り当てられたマシンは，通常の操作中に割り当てが発生した场合のみ使用できます。停止状态中は新しい割り当てはできません。
• リモートPCアクセスマシンの自动登录と构成はできません。ただし，通常の操作中に登录，构成されたマシンは使用できます。
• サーバーでホストされるアプリケーションとデスクトップのユーザーは,リソースが異なるゾーンにある場合,構成されている最大セッション数よりも多くのセッションを使用できる場合があります。
• ユーザーは，现在アクティブ/选択されている（セカンダリ）ブローカーを含むゾーン内の登录済みVDAからのみ，アプリケーションとデスクトップを起动できます。停止状态中は，ゾーン间での起动（あるゾーンのブローカーから别のゾーンのVDAへ）はサポートされません。

停止状态が発生した场合，ShutdownDesktopsAfterUseプロパティが有効なデリバリーグループにプールされている電源管理対象のデスクトップVDAは,デフォルトで保守モードになります。このデフォルトの設定を変更して,停止状態中にこれらのデスクトップを使用できるようにすることができます。ただし,停止状態中は電源管理が機能しないことがあります。(通常の操作を開始すると電源管理が始まります)。また,これらのデスクトップは再起動していないため,前のユーザーのデータが含まれている可能性があります。

デフォルトの動作を上書きするには,サイト全体で,影響を受けるデリバリーグループごとに,これを有効にする必要があります。

サイトに対して次のPowerShellコマンドレットを実行します:

设置BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $真

影响を受ける各デリバリーグループに対して，次のPowerShell的コマンドレットを実行します：

Set-BrokerDesktopGroup -Name "\<*name*\>" -ReuseMachinesWithoutShutdownInOutage $true

この機能をサイトでデリバリーグループごとに有効にしても,構成済みの”ShutdownDesktopsAfterUse“プロパティの,通常操作時の動作には影響がありません。

RAMサイズ：

的LocalDBサービスは，约1.2GBのRAM（データベースキャッシュ用に最大1GB，SQL Server Express中的LocalDBの実行用にさらに200MB）を使用できます。高可用性服务は，停止状态が长时间続き，多数のログオンが発生した场合（たとえば12时间でユーザー数1万人），最大1GBのRAMを使用できます。これらのメモリ要件は控制器の通常のRAM要件とは别なので，RAMの総容量を増やす必要がある场合があります。

サイトデータベースにSQL Server Express的インストールを使用する场合，サーバーに2つのsqlserver.exeプロセスを持つ点に注意してください。

CPUコアとソケットの构成：

控制器のCPU構成,特にSQL Server Express LocalDBが利用できるコア数は,メモリ割り当て以上に,ローカルホストキャッシュのパフォーマンスに直接影響を及ぼします。このCPUオーバーヘッドが発生するのは,データベースとの接続が失われ,高可用性服务がアクティブである停止状態の間だけです。

的LocalDBは复数のコア（最大4つ）を使用できますが，単一のソケットだけに制限されます。ソケットを追加しても（たとえば，4つのソケットにそれぞれ1つのコア），パフォーマンスは向上しません。それよりも复数のコアを持つ复数のソケットの使用を的Citrixではお勧めします.Citrixのテストでは，2×3（2つのソケット，3つのコア）の构成が，4X1および6X1の构成より良好なパフォーマンスを示しました。

ストレージ:

ユーザーが停止状態の間にリソースにアクセスすると,LocalDBは増大します。たとえば，1秒に10回ログオンするログオン/ログオフテスト実行では、データベースは2～3分に1MB増大しました。通常の操作が再開すると、ローカルデータベースが再作成され、容量は元に戻ります。ただし、停止状態中のデータベース増大を考慮に入れて、LocalDBがインストールされるドライブ上のブローカーは十分な容量を持つ必要があります。ローカルホストキャッシュを使用すると、停止状態中に追加のI/Oが生じます（数十万の読み取りで、1秒あたり約3MBの書き込み）。

パフォーマンス：

停止状态中は1つのブローカーがすべての接続を处理するため，通常の操作时に复数の控制器に负荷を分散するサイト（あるいは，ゾーン）では，停止状态中に，选出されたブローカーが普通よりはるかに多くの要求を处理する必要があることがあります。このため，CPUへの要求が高くなります。选出されたブローカーが停止状态中に変更される可能性があるため，サイト（ゾーン）内のすべてのブローカーが，的LocalDBと影响を受けるすべてのVDAによって课される追加の负荷を处理できる必要があります。

VDIの制限事項:

• 単一ゾーンにVDIを展开する场合，停止状态时には最大の万VDAを效果的に处理できます。
• 复数ゾーンにVDIを展开する场合，停止状态时には各ゾーンで最大万のVDA，サイト全体では最大40000のVDAを效果的に处理できます。たとえば次のそれぞれのサイトが，停止状态时に效果的に处理されます。
  • 4つのゾーンそれぞれにの万VDAが含まれるサイト。
  • 10000年1つのゾーンにはのVDAが含まれ,残り6つのゾーンにはそれぞれ5000のVDAが含まれる,合計7つのゾーンからなるサイト。

停止状態中に,サイト内の負荷管理が影響を受ける可能性があります。負荷評価基準(特にセッション数規則)を超過する可能性があります。

すべてのVDAがブローカーに再登录する间，そのブローカーには现在のセッションについての完全な情报がないことがあります。このため，その间の接続要求により，既存のセッションへの再接続が可能であっても，新しいセッションが起动される可能性があります。こうした时间（「新しい」ブローカーが再登录时にすべてのVDAからセッション情报を取得する时间）が発生するのは避けられません。停止状态の开始时に接続していたセッションは移行期间に影响は受けませんが，新しいセッションおよびセッション再接続は影响を受ける可能性がある点に注意してください。

この期间は，VDAが异なるブローカーに再登录する必要があるときは常に発生します。

• 停止状態の開始:プリンシパルブローカーからセカンダリブローカーに移行するとき。
• 停止状态中のブローカー障害：障害が発生したセカンダリブローカーから新しく选出されたセカンダリブローカーに移行するとき。
• 停止からの回復:通常の操作が再開し,プリンシパルブローカーが制御を再開したとき。

Citrix代理协议のHeartbeatPeriodMsレジストリ値(デフォルト= 600000(10分)女士)を小さくすることによって期間を短縮できます。このハートビート値は,VDAが萍に使用する間隔の2倍であるため,デフォルト値では5分ごとに萍が発生します。

たとえば，ハートビートを5分（300000ms）に変更するには，次のコマンドを実行しますこのようにすると，平は2.5分ごとに発生します：

新-ItemProperty -Path HKLM：\ SOFTWARE \思杰\ DesktopServer杂牌HeartbeatPeriodMs -PropertyType DWORD - 值30万

VDAの登录をどんなに早くしても，间隔を完全になくすことはできません。

ブローカー間の同期にかかる時間は,オブジェクト(VDA,アプリケーション,グループなど)の数により増加します。5000年たとえば個のVDAを同期する場合には,10分以上かかる可能性があります。イベントログの同期エントリについて詳しくは、後述の「モニター」セクションを参照してください。

ローカルホストキャッシュの管理

ローカルホストキャッシュを正常に动作させるには，各控制器上のPowerShell的実行ポリシーを，下RemoteSigned，无限制，または旁路に设定する必要があります。

SQL Server Express中的LocalDB

ローカルホストキャッシュが使用する微软的SQL Server Express的LocalDBは，控制器をインストールするか，控制器を7.9以前のバージョンからアップグレードするときに，自动的にインストールされます.LocalDBを管理者がメンテナンスする必要はありません。セカンダリブローカーだけがこのデータベースと通信します.PowerShellコマンドレットを使用してこのデータベースに关する変更を行うことはいっさいできません.LocalDBは，控制器间で共有できません。

SQL Server Express中的LocalDBデータベースソフトウェアは，ローカルホストキャッシュが有效かどうかに关系なくインストールされます。

このインストールを防止するには,控制器のインストールまたはアップグレード時に,XenDesktopServerSetup.exeコマンドで" /排除“本地主机缓存存储(LocalDB)”“オプションを使用します。ただし,ローカルホストキャッシュ機能はデータベースがないと機能しないことと,セカンダリブローカーでは異なるデータベースを使用できないことに注意してください。

この的LocalDBデータベースのインストールは，サイトデータベースとして使うためにSQL Server Express的をインストールするかどうかには影响しません。

XenApp的または的XenDesktopのインストールとアップグレード后のデフォルト设定

XenAppおよびXenDesktopの新規インストール時に,ローカルホストキャッシュはデフォルトで有効になっています。(接続リース機能は,デフォルトで無効になっています)。

アップグレード後,ローカルホストキャッシュ設定は変更されません。たとえば，ローカルホストキャッシュが以前のバージョンで有効にされていると、アップグレードされたバージョンでも引き続き有効になっています。以前のバージョンで無効な場合、またはサポートされていなかった場合、アップグレードされたバージョンでも無効のままです。

ローカルホストキャッシュの有效化と无效化

ローカルホストキャッシュを有効化するには,次のように入力します:

Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false

このコマンドレットは，接続リース机能も无效化します。ローカルホストキャッシュと接続リースの両方を有效化しないでください。

ローカルホストキャッシュが有效かどうかを判断するには，次のように入力します。

Get-BrokerSite

LocalHostCacheEnabledプロパティが真でConnectionLeasingEnabledプロパティが假であることを確認します。

ローカルホストキャッシュを無効化(および接続リースを有効化)するには,次のように入力します:

Set-BrokerSite -LocalHostCacheEnabled $false -ConnectionLeasingEnabled $true

ローカルホストキャッシュが动作していることを确认する

ローカルホストキャッシュが適切に設定され動作していることを確認するには:

• 同期のインポートが正常に完了していることを確認します。イベントログをチェックします。
• SQL Server Express中的LocalDBデータベースが交付控制器ごとに作成されたことを确认します。これにより，必要に応じて高可用性服务が处理を引き継げるようになります。
• 交付控制器サーバーで，C：\ WINDOWS \ ServiceProfiles \网络服务に移动します。
• HaDatabaseName.mdfおよびHaDatabaseName_log.ldfが作成されていることを确认します。
• 交付控制器に停止状態を強制します。ローカルホストキャッシュが動作することを確認したら,すべての控制器を通常モードに戻します。この処理には,大量のVDA登録を避けるために15分程度かかることがあります。

停止状态の强制

データベースの停止状態を意図的に強制することもできます。

• ネットワークが稼动と停止を缲り返している场合。ネットワークの问题が解决するまで停止状态を强制することにより，通常モードと停止状态モードの移行が缲り返されるのを防げます。
• 障害回復プランをテストするには:
• サイトデータベースサーバーの交換または修理中。

停止状态を强制するには，交付控制器を含む各サーバーのレジストリを编集します。

• HKEY_LOCAL_MACHINE \ Software \ Citrix \ DesktopServer \ LHCで[OutageModeForced]を[1]に設定します。この指示により,ブローカーはデータベースの状態に関係なく停止状態モードに入ります(値を0に設定すると,サーバーの停止状態モードが終了します)。
• Citrix云のシナリオでは，コントロールプレーンやプライマリゾーンへの接続の状态に关系なく，コネクタが停止状态モードに入ります。

モニター

イベントログに,同期および停止状態が発生した時刻が示されます。

配置同步器服务:

通常の操作中に、CSSがブローカー構成をコピーおよびエクスポートして,高可用性服务(セカンダリブローカー)を使用してそれをLocalDBにインポートするとき,次のイベントが発生することがあります。

• 503：プリンシパルブローカー构成に変更が见つかり，インポートが开始されます。
• 504：ブローカー构成がコピーおよびエクスポートされて，的LocalDBに正常にインポートされました。
• 505：的LocalDBへのインポートが失败しました详しくは下记を参照してください。
• 510：プライマリ构成サービスから构成サービス构成データを受信して​​いません。
• 517：プライマリブローカーとの通信に问题がありました。
• 518：セカンダリブローカー（高可用性业务）が実行されていないため，设定同步スクリプトが中止されました。

高可用性服务:

• 3502：停止状态が発生し，セカンダリブローカー（高可用性业务）が操作の仲介を実行しています。
• 3503:停止状態が解決され,通常の操作が再開しました。
• 3504:どのセカンダリブローカーが選出されたかと,選出に関わった他のブローカーを示します。

トラブルシューティング

LocalDBへの同期インポートが失敗し,505イベントがポストされた場合,いくつかのトラブルシューティングツールを利用できます。

它强调トレーシング:ConfigSyncServerモジュールおよびBrokerLHCモジュール向けのオプションが用意されています。それらのオプションと他のブローカーモジュールの组み合わせで问题を识别できるはずです。

レポート：。同期インポートが失败した场合，レポートを生成できますこのレポートの最后に，エラーの原因となったオブジェクトが记载されていますこのレポート机能は同期速度に影响するため，思杰では使用しないときは无效にしておくことをお勧めします。

CSSトレースレポートを有効化および作成するには,次のコマンドを入力します:

新-ItemProperty -Path HKLM：\ SOFTWARE \思杰\ DesktopServer \ LHC杂牌EnableCssTraceMode -PropertyType DWORD - 数值1

HTMLレポートはC：\\的Windows \\ \\ ServiceProfiles网络服务\\ AppData的\\ \\本地临时\\ CitrixBrokerConfigSyncReport.htmlに格納されます。

レポートが生成されたら，次のコマンドを入力してレポート机能を无效にします：

Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC name EnableCssTraceMode -Value 0

ブローカー构成のエクスポート：デバッグのために正確な構成を提供します。

出口BrokerConfiguration |出文件的文件路径名

たとえば，出口BrokerConfiguration |出文件C：\\ BrokerConfig.xmlなどです。