ローカルホストキャッシュ
Citrix Virtual Apps and Desktopsサイトデータベースが常に利用可能であることを保証するため、CitrixはMicrosoftの高可用性ベストプラクティスに従って、フォールトトレラントなSQL Server展開から始めることを推奨します。(サポートされているSQL Serverの高可用性機能については、データベースを参照してください。)しかし、ネットワークの問題や中断により、ユーザーがアプリケーションやデスクトップに接続できなくなる可能性があります。
ローカルホストキャッシュ機能により、障害発生時にサイトでの接続仲介操作を継続できます。障害は、オンプレミスのCitrix®環境でDelivery Controller™とサイトデータベース間の接続が失敗したときに発生します。サイトデータベースに90秒間アクセスできない場合、ローカルホストキャッシュが作動します。
XenAppおよびXenDesktop 7.16以降、接続リース機能(以前のリリースにおける先行の高可用性機能)は製品から削除され、利用できなくなりました。
データコンテンツ
ローカルホストキャッシュには、メインデータベースの情報の一部である以下の情報が含まれます。
-
サイトから公開されたリソースへの権限が割り当てられているユーザーおよびグループの ID。
-
現在使用している、または最近使用した、サイトから公開されたリソースのユーザーの ID。
-
サイトで構成されている VDA マシン(リモート PC アクセス マシンを含む)の ID。
-
公開されたリソースへの接続に積極的に使用されているクライアントCitrix Receiver™マシンのID(名前とIPアドレス)。
また、メインデータベースが利用できなかった間に確立された、現在アクティブな接続に関する情報も含まれます。
-
Citrix Receiverによって実行されたクライアントマシンのエンドポイント分析の結果。
-
サイトに関与するインフラストラクチャマシン(NetScaler GatewayやStoreFront™サーバーなど)のID。
-
ユーザーによる最近のアクティビティの日時と種類。
動作の仕組み
次の図は、通常の操作中のローカルホストキャッシュのコンポーネントと通信パスを示しています。
ローカルホストキャッシュの通常の操作中の通信パスの図(/en-us/citrix-virtual-apps-desktops/2203-ltsr/media/lhc-normal1.png)
通常の操作中
-
Controller上のプリンシパルブローカー (Citrix Broker Service) は、StoreFrontからの接続要求を受け入れます。ブローカーはサイトデータベースと通信し、ユーザーをControllerに登録されているVDAに接続します。
-
Citrix Config Synchronizer Service (CSS) は、約5分ごとにブローカーに問い合わせて、変更があったかどうかを確認します。これらの変更は、管理者によって開始されたもの(デリバリーグループのプロパティの変更など)またはシステムアクション(マシンの割り当てなど)である可能性があります。
-
前回のチェック以降に構成変更があった場合、CSS は情報を Controller 上のセカンダリブローカーに同期 (コピー) します。(セカンダリブローカーは高可用性サービスとも呼ばれます。)前回のチェック以降に変更された項目だけでなく、すべての構成データがコピーされます。CSS は構成データを Controller 上の Microsoft SQL Server Express LocalDB データベースにインポートします。このデータベースはローカルホストキャッシュデータベースと呼ばれます。CSS は、ローカルホストキャッシュデータベースの情報がサイトデータベースの情報と一致することを確認します。ローカルホストキャッシュデータベースは、同期が行われるたびに再作成されます。Microsoft SQL Server Express LocalDB (ローカルホストキャッシュデータベースで使用) は、Controller をインストールするときに自動的にインストールされます。(コマンドラインから Controller をインストールする際に、このインストールを禁止できます。) ローカルホストキャッシュデータベースは、複数の Controller 間で共有できません。ローカルホストキャッシュデータベースをバックアップする必要はありません。構成変更が検出されるたびに再作成されます。
-
前回のチェック以降に変更がない場合、データはコピーされません。
次の図は、プリンシパルブローカーがサイトデータベースとの接続を失った場合 (停止が開始された場合) の通信パスの変化を示しています。
停止中
停止が開始されると:
-
セカンダリブローカーは接続要求のリッスンと処理を開始します。
-
停止が開始されると、セカンダリブローカーは最新の VDA 登録データを持っていませんが、VDA がセカンダリブローカーと通信すると、登録プロセスがトリガーされます。そのプロセス中に、セカンダリブローカーはその VDA に関する現在のセッション情報も取得します。
-
セカンダリブローカーが接続を処理している間、ブローカリングプリンシパルは接続を監視し続けます。接続が復元されると、ブローカリングプリンシパルはセカンダリブローカーに接続情報のリッスンを停止するよう指示し、ブローカリングプリンシパルはブローカリング操作を再開します。次に VDA がブローカリングプリンシパルと通信するときに、登録プロセスがトリガーされます。セカンダリブローカーは、以前の停止からの残りの VDA 登録をすべて削除します。CSS は、展開で構成変更が発生したことを認識すると、情報の同期を再開します。
同期中に停止が開始されるという万が一の事態が発生した場合、現在のインポートは破棄され、最後に認識された構成が使用されます。
イベントログ には、同期と停止に関する情報が提供されます。
停止モードでの運用に時間制限はありません。
通常モードと停止モード間の移行は、既存のセッションには影響しません。新しいセッションの起動のみに影響します。
意図的に停止をトリガーすることもできます。その理由と方法の詳細については、Force an outageを参照してください。
複数のControllerがあるサイト
CSSは、他のタスクの中でも、ゾーン内のすべてのControllerに関する情報をセカンダリブローカーに定期的に提供します。(展開に複数のゾーンが含まれていない場合、このアクションはサイト内のすべてのControllerに影響します。)その情報を持つことで、各セカンダリブローカーは、ゾーン内の他のControllerで実行されているすべてのピアセカンダリブローカーについて認識します。
セカンダリブローカーは、別のチャネルで相互に通信します。これらのブローカーは、停止が発生した場合にゾーン内でブローカー操作を行うセカンダリブローカーを決定(選出)するために、実行されているマシンのFQDN名のアルファベット順リストを使用します。停止中、すべてのVDAは選出されたセカンダリブローカーに登録します。ゾーン内の選出されていないセカンダリブローカーは、受信接続およびVDA登録要求を積極的に拒否します。
停止中に選出されたセカンダリブローカーが失敗した場合、別のセカンダリブローカーが引き継ぐために選出され、VDAは新しく選出されたセカンダリブローカーに登録します。
停止中にControllerが再起動された場合:
-
そのControllerが選出されたブローカーでない場合、再起動による影響はありません。
-
そのControllerが選出されたブローカーである場合、別のControllerが選出され、VDAが登録されます。再起動されたControllerが起動すると、自動的にブローカー処理を引き継ぎ、VDAが再度登録されます。このシナリオでは、登録中にパフォーマンスが影響を受ける可能性があります。
通常の操作中にControllerの電源をオフにし、停止中に電源をオンにした場合、そのControllerがブローカーとして選出されても、そのControllerではローカルホストキャッシュを使用できません。
イベントログは、選出に関する情報を提供します。
停止中に利用できないもの、およびその他の違い
停止モードでの運用に時間制限はありません。ただし、Citrixは可能な限り迅速に接続を復元することを推奨しています。
停止中:
-
Studioを使用できません。
-
PowerShell SDKへのアクセスは制限されます。
-
まず、次の操作を行う必要があります。
-
値が1のレジストリキー
EnableCssTestModeを追加します:New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1 -
ポート89を使用します:
Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ContollerDNSName, DesktopGroupName, RegistrationState
-
-
これらのコマンドを実行すると、以下にアクセスできます。
-
すべての
Get-Broker*コマンドレット。
-
-
-
ハイパーバイザーの資格情報はホストサービスから取得できません。すべてのマシンは不明な電源状態になり、電源操作は発行できません。ただし、電源がオンになっているホスト上のVMは、接続要求に使用できます。
-
割り当てられたマシンは、通常の操作中に割り当てが行われた場合にのみ使用できます。停止中は新しい割り当てを行うことはできません。
-
リモートPCアクセス マシンの自動登録と構成はできません。ただし、通常の操作中に登録および構成されたマシンは使用できます。
-
サーバーでホストされているアプリケーションおよびデスクトップのユーザーは、リソースが異なるゾーンにある場合、構成されているセッション制限よりも多くのセッションを使用する可能性があります。
-
ユーザーは、現在アクティブ/選出されているセカンダリブローカーを含むゾーン内の登録済みVDAからのみアプリケーションとデスクトップを起動できます。停止中は、ゾーンをまたいだ起動(あるゾーンのセカンダリブローカーから別のゾーンのVDAへの起動)はサポートされません。
-
デリバリーグループ内のVDAのスケジュールされた再起動が開始される前にサイトデータベースの停止が発生した場合、再起動は停止が終了したときに開始されます。これにより、予期しない結果が生じる可能性があります。詳しくは、「データベースの停止によりスケジュールされた再起動が遅延する」を参照してください。
-
ゾーン優先度 は構成できません。構成されている場合でも、セッション起動時には優先度は考慮されません。
-
タグがゾーンの指定に使用されるタグ制限 は、セッション起動ではサポートされません。このようなタグ制限が構成され、StoreFrontストアの高度なヘルスチェック オプションが有効になっている場合、セッションの起動が断続的に失敗する可能性があります。
アプリケーションとデスクトップのサポート
ローカルホストキャッシュは、サーバーでホストされるアプリケーションとデスクトップ、および静的(割り当て済み)デスクトップをサポートします。
ローカルホストキャッシュは、プールされたデリバリーグループ内のデスクトップVDAを次のようにサポートします。
-
デフォルトでは、
ShutdownDesktopsAfterUseプロパティが有効になっているプールされたデリバリーグループ(MCSまたはCitrix Provisioning™によって作成されたもの)内の電源管理されたデスクトップVDAは、ローカルホストキャッシュイベント中に新しい接続に利用できません。このデフォルトを変更して、ローカルホストキャッシュ中にこれらのデスクトップを使用できるようにすることができます。ただし、停止中の電源管理に頼ることはできません。(通常の操作が再開された後、電源管理が再開されます。)また、これらのデスクトップは再起動されていないため、以前のユーザーのデータが含まれている可能性があります。 -
デフォルトの動作を上書きするには、サイト全体で、および影響を受ける各デリバリーグループで有効にする必要があります。次のPowerShellコマンドレットを実行します。サイト全体:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true影響を受ける各デリバリーグループに対して、次のPowerShellコマンドを実行します。Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $trueサイトおよびデリバリーグループでこの機能を有効にしても、構成されたShutdownDesktopsAfterUseプロパティが通常の操作中にどのように機能するかには影響しません。この機能が有効になっている場合、LHCイベントが完了してもVDAは自動的に再起動しません。プールされたデリバリーグループ内の電源管理されたデスクトップVDAは、VDAが再起動されるまで以前のセッションのデータを保持できます。これは、ユーザーが非LHC操作中にVDAからログオフした場合、または再起動が手動でトリガーされた場合に発生する可能性があります。
重要:
サイトレベルでReuseMachinesWithoutShutdownInOutageAllowedを有効にし、デリバリーグループレベルでReuseMachinesWithoutShutdownInOutageを有効にしないと、ローカルホストキャッシュイベント中にプールされたデリバリーグループ内の電源管理されたデスクトップVDAへのすべてのセッション起動試行が失敗します。
RAM サイズに関する考慮事項
LocalDBサービスは、約1.2 GBのRAM(データベースキャッシュに最大1 GB、SQL Server Express LocalDBの実行に200 MB)を使用できます。障害が長期間続き、多くのログオンが発生する場合(たとえば、10,000ユーザーで12時間)、セカンダリブローカーは最大1 GBのRAMを使用できます。これらのメモリ要件は、コントローラーの通常のRAM要件に追加されるため、合計RAM容量を増やす必要がある場合があります。
サイトデータベースにSQL Server Expressインストールを使用している場合、サーバーには2つのsqlserver.exeプロセスがあります。
CPU コアとソケット構成に関する考慮事項
コントローラーのCPU構成、特にSQL Server Express LocalDBで利用可能なコア数は、メモリ割り当てよりもさらに、ローカルホストキャッシュのパフォーマンスに直接影響します。このCPUオーバーヘッドは、データベースに到達できず、セカンダリブローカーがアクティブな障害期間中にのみ観測されます。
LocalDBは複数のコア(最大4つ)を使用できますが、単一のソケットに制限されています。ソケットを追加してもパフォーマンスは向上しません(たとえば、1コアずつ4つのソケットがある場合)。代わりに、Citrixは複数のコアを持つ複数のソケットを使用することを推奨しています。Citrixのテストでは、2x3(2ソケット、3コア)構成は4x1および6x1構成よりも優れたパフォーマンスを提供しました。
ストレージに関する考慮事項
障害中にユーザーがリソースにアクセスすると、LocalDBは増大します。たとえば、1秒あたり10ログオンで実行されるログオン/ログオフテスト中に、データベースは2〜3分ごとに1 MB増加しました。通常の操作が再開されると、ローカルデータベースが再作成され、スペースが返されます。ただし、障害中のデータベースの増大を許容するために、LocalDBがインストールされているドライブに十分なスペースが利用可能である必要があります。ローカルホストキャッシュは、障害中により多くのI/Oも発生させます。約3 MB/秒の書き込みと、数十万回の読み取りです。
パフォーマンスに関する考慮事項
障害発生時には、1つのセカンダリブローカーがすべての接続を処理するため、通常の操作中に複数のコントローラー間で負荷分散を行うサイト(またはゾーン)では、選出されたセカンダリブローカーが障害発生時に通常よりもはるかに多くの要求を処理する必要がある場合があります。したがって、CPUの要求は高くなります。サイト(ゾーン)内のすべてのセカンダリブローカーは、ローカルホストキャッシュデータベースと影響を受けるすべてのVDAによって課される追加の負荷を処理できる必要があります。これは、障害発生時に選出されるセカンダリブローカーが変更される可能性があるためです。
VDIの制限:
-
シングルゾーンVDI展開では、障害発生時に最大10,000台のVDAを効果的に処理できます。
-
マルチゾーンVDI展開では、停止中に各ゾーンで最大10,000のVDA、サイト全体で最大40,000のVDAを効果的に処理できます。例えば、以下の各サイトは停止中に効果的に処理できます。
-
4つのゾーンを持ち、各ゾーンに10,000のVDAを含むサイト。
-
7つのゾーンを持ち、1つは10,000のVDAを含み、残りの6つはそれぞれ5,000のVDAを含むサイト。
-
停止中、サイト内の負荷管理が影響を受ける可能性があります。負荷評価器(特にセッション数ルール)が超過する可能性があります。
すべてのVDAがセカンダリブローカーに登録するのにかかる間、そのサービスは現在のセッションに関する完全な情報を持っていない可能性があります。そのため、その期間中のユーザー接続要求は、既存のセッションへの再接続が可能であったとしても、新しいセッションが起動される結果となる可能性があります。この期間(「新しい」セカンダリブローカーが再登録中にすべてのVDAからセッション情報を取得する間)は避けられません。停止が開始されたときに接続されているセッションは移行期間中に影響を受けませんが、新しいセッションやセッションの再接続は影響を受ける可能性があります。
この期間は、VDAが登録する必要がある場合に発生します。
-
停止が開始されたとき: プリンシパルブローカーからセカンダリブローカーに移行するとき。
-
停止中のセカンダリブローカーの障害: 障害が発生したセカンダリブローカーから新しく選出されたセカンダリブローカーに移行するとき。
-
停止からの復旧: 通常の操作が再開され、プリンシパルブローカーが制御を再開するとき。
Citrix Broker Protocolの
HeartbeatPeriodMsレジストリ値(デフォルト = 600000 ms、つまり10分)を下げることで、間隔を短縮できます。このハートビート値は、VDAがpingに使用する間隔の2倍であるため、デフォルト値では5分ごとにpingが実行されます。
例えば、次のコマンドはハートビートを5分(300000ミリ秒)に変更し、2.5分ごとにpingが実行されるようにします。
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000
ハートビート値を変更する際は注意してください。頻度を上げると、通常モードと停止モードの両方でControllerへの負荷が増大します。
VDAがどれだけ迅速に登録されても、この間隔を完全に排除することはできません。
セカンダリブローカー間の同期にかかる時間は、オブジェクト(VDA、アプリケーション、グループなど)の数が増えるにつれて長くなります。例えば、5000のVDAを同期するには10分以上かかる場合があります。
XenApp 6.xリリースとの違い
このローカルホストキャッシュの実装は、XenApp 6.xおよびそれ以前のXenAppリリースにおけるローカルホストキャッシュ機能と同じ名前を共有していますが、大幅な改善が施されています。この実装は、より堅牢で破損の影響を受けません。定期的な
dsmaintコマンドの必要性を排除するなど、メンテナンス要件が最小限に抑えられています。このローカルホストキャッシュは、技術的には全く異なる実装です。
ローカルホストキャッシュの管理
ローカルホストキャッシュが正しく機能するには、各ControllerのPowerShell実行ポリシーをRemoteSigned、Unrestricted、またはBypassに設定する必要があります。
SQL Server エクスプレス ローカルDB
ローカルホストキャッシュが使用するMicrosoft SQL Server Express LocalDBソフトウェアは、Controllerをインストールするか、バージョン7.9より前のControllerをアップグレードする際に自動的にインストールされます。このデータベースと通信するのはセカンダリブローカーのみです。PowerShellコマンドレットを使用して、このデータベースに関する何かを変更することはできません。LocalDBは複数のController間で共有できません。
SQL Server Express LocalDBデータベースソフトウェアは、ローカルホストキャッシュが有効になっているかどうかにかかわらずインストールされます。
そのインストールを防ぐには、
XenDesktopServerSetup.exeコマンドを使用してControllerをインストールまたはアップグレードし、/exclude "Local Host Cache Storage (LocalDB)"オプションを含めます。ただし、ローカルホストキャッシュ機能はデータベースなしでは機能せず、セカンダリブローカーで別のデータベースを使用することはできないことに注意してください。
このLocalDBデータベースのインストールは、サイトデータベースとして使用するためにSQL Server Expressをインストールするかどうかには影響しません。
以前のSQL Server Express LocalDBバージョンを新しいバージョンに置き換える方法については、「Replace SQL Server Express LocalDB」を参照してください。
製品のインストールとアップグレード後のデフォルト設定
Citrix Virtual Apps and Desktopsの新規インストール時(最小バージョン7.16)には、ローカルホストキャッシュが有効になります。
アップグレード後(バージョン7.16以降)は、展開全体で10,000未満のVDAがある場合、ローカルホストキャッシュが有効になります。
ローカルホストキャッシュの有効化と無効化
-
ローカルホストキャッシュを有効にするには、次のように入力します。
Set-BrokerSite -LocalHostCacheEnabled $trueローカルホストキャッシュが有効になっているかどうかを確認するには、Get-BrokerSiteと入力します。LocalHostCacheEnabledプロパティがTrueであることを確認します。 -
ローカルホストキャッシュを無効にするには、次のように入力します。
Set-BrokerSite -LocalHostCacheEnabled $false
注意: XenAppおよびXenDesktop 7.16以降、接続リース(バージョン7.6からローカルホストキャッシュに先行していた機能)は製品から削除され、利用できなくなりました。
ローカルホストキャッシュが機能していることを確認する
ローカルホストキャッシュが正しく設定され、機能していることを確認するには:
-
同期インポートが正常に完了していることを確認します。イベントログを確認してください。
-
各Delivery ControllerにSQL Server Express LocalDBデータベースが作成されていることを確認します。これにより、必要に応じてセカンダリブローカーが引き継ぐことができることが確認されます。
-
Delivery Controllerサーバーで、
C:\Windows\ServiceProfiles\NetworkServiceを参照します。 -
HaDatabaseName.mdfとHaDatabaseName_log.ldfが作成されていることを確認します。
-
-
Delivery Controllerで障害を強制的に発生させます。ローカルホストキャッシュが機能することを確認したら、すべてのControllerを通常モードに戻すことを忘れないでください。これには約15分かかる場合があります。
イベントログ
イベントログは、同期と障害が発生した時期を示します。イベントビューアログでは、障害モードはHAモードと呼ばれます*。
構成同期サービス:
通常の操作中、CSSがローカルホストキャッシュブローカーを使用して構成データをローカルホストキャッシュデータベースにインポートする際に、次のイベントが発生する可能性があります。
-
503: Citrix Config Sync Serviceが更新された構成を受信しました。このイベントは、同期プロセスの開始を示します。
-
504: Citrix Config Sync Serviceが更新された構成をインポートしました。構成のインポートが正常に完了しました。
-
505: Citrix Config Sync Serviceがインポートに失敗しました。構成のインポートは正常に完了しませんでした。以前に正常な構成が利用可能な場合、障害発生時にそれが使用されます。ただし、それは現在の構成から古くなっています。以前の構成が利用できない場合、サービスは障害発生時にセッションブローカーに参加できません。この場合、トラブルシューティングセクションを参照し、Citrixサポートに連絡してください。
-
507: システムが障害モードであり、ローカルホストキャッシュブローカーがブローカー処理に使用されているため、Citrix Config Sync Serviceがインポートを中止しました。サービスは新しい構成を受信しましたが、障害が発生したためインポートは中止されました。これは予期される動作です。
-
510: プライマリ構成サービスから構成サービス構成データが受信されませんでした。
-
517: プライマリブローカーとの通信中に問題が発生しました。
-
518: セカンダリブローカー(高可用性サービス)が実行されていないため、構成同期スクリプトが中止されました。
高可用性サービス:
このサービスは、ローカルホストキャッシュブローカーとも呼ばれます。
-
3502: 停止が発生し、ローカルホストキャッシュブローカーがブローカー操作を実行しています。
-
3503: 停止が解決され、通常の操作が再開されました。
-
3504: どのローカルホストキャッシュブローカーが選出されたか、および選出に関与した他のローカルホストキャッシュブローカーを示します。
停止を強制する
意図的に停止を強制したい場合があります。
-
ネットワークが繰り返しダウンする場合。ネットワークの問題が解決されるまで停止を強制すると、通常モードと停止モード間の継続的な移行(およびその結果として頻繁に発生するVDA登録ストーム)を防ぐことができます。
-
ディザスタリカバリ計画をテストするため。
-
ローカルホストキャッシュが正しく機能していることを確認するため。
-
サイトデータベースサーバーの交換または保守中。
停止を強制するには、Delivery Controller を含む各サーバーのレジストリを編集します。
HKLM\Software\Citrix\DesktopServer\LHCで、OutageModeForcedをREG_DWORDとして1に作成して設定します。この設定により、データベースの状態に関係なく、ローカルホストキャッシュブローカーは停止モードに入ります。値を0に設定すると、ローカルホストキャッシュブローカーは停止モードを終了します。
イベントを確認するには、
C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityServiceにあるCurrent_HighAvailabilityServiceログファイルを監視します。
トラブルシューティング
ローカルホストキャッシュデータベースへの同期インポートが失敗し、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。