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

ローカルホストキャッシュ機能を使用すると、Cloud ConnectorがCitrix Cloudと通信できなくなった場合でも、Citrix Virtual Apps and Desktopsサービス環境での接続仲介操作を続行できるようになります。ローカルホストキャッシュは、ネットワーク接続の切断時間が60秒に達すると作動します。

ローカルホストキャッシュがあれば、接続済みのユーザーは、停止状態が発生した場合も途切れることなく作業を続行できます。再接続時および新規接続時の接続遅延は最小限に抑えられます。

重要:

各リソースの場所には、顧客が展開するオンプレミスのStoreFrontが必要です。ローカルホストキャッシュは、オンプレミスのStoreFrontが含まれるリソースの場所でのみ動作します。

データコンテンツ

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

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

また、メインデータベースが利用できなくなったときに確立され、現在アクティブな接続に関する情報も格納されています:

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

機能

通常の操作中

通常操作時の画像

  • Cloud Connector上のプリンシパルブローカー(Citrix Remote Broker Provider Service)は、StoreFrontからの接続要求を受け取ります。プリンシパルブローカーは、Citrix Cloudと通信して、Cloud Connectorに登録済みのVDAにユーザーを接続します。
  • Citrix Config Synchronizer Service(CSS)は、Citrix Cloudのブローカーを毎分チェックして、構成に変更がないか確認します。こうした変更には、管理者によるもの(デリバリーグループのプロパティの変更など)とシステム操作(マシン割り当てなど)があります。
  • 前回のチェック以降に構成が変更された場合、CSSは、Cloud Connectorのセカンダリブローカー(つまりHigh Availability Service、前述の図のHAブローカー)に情報を同期(コピー)します。

    前回のチェック以降に変更された項目だけでなく、すべての構成データがコピーされます。CSSは、Cloud Connector上のMicrosoft SQL Server Express LocalDBデータベースに構成データをインポートします。このデータベースはローカルホストキャッシュデータベースとして参照されます。CSSは、ローカルホストキャッシュデータベースの情報がサイトデータベースの情報と一致することを確認します。ローカルホストキャッシュデータベースは、同期が発生するたびに再作成されます。

Cloud Connectorをインストールする場合、(ローカルホストキャッシュデータベースで使用するために)自動でMicrosoft SQL Server Express LocalDBがインストールされますローカルホストキャッシュデータベースをCloud Connector間で共有することはできません。ローカルホストキャッシュデータベースのバックアップを作成する必要はありません。構成の変更が検出されるたびに再作成されます。

  • 前回のチェック以降に変更が発生行われていない場合、構成データはコピーされません。

停止状態発生時

停止状態中の画像

停止状態が開始された場合:

  • セカンダリブローカーは、接続要求のリスンと処理を開始します。
  • 停止状態の開始時には、セカンダリブローカーに最新のVDA登録データはありませんが、VDAとの通信が始まるとすぐに登録処理がトリガーされます。その処理中、セカンダリブローカーは、そのVDAに関する現在のセッション情報も取得します。
  • セカンダリブローカーが接続を処理する間も、プリンシパルブローカーは引き続きCitrix Cloudへの接続を監視します。接続が回復すると、プリンシパルブローカーはセカンダリブローカーに接続情報のリスニングを停止するように指示して、仲介操作を再開します。VDAがプリンシパルブローカーと次に通信するときに、登録処理がトリガーされます。セカンダリブローカーは、前回の停止状態以降に残っているVDA登録をすべて削除します。CSSは、Citrix Cloudで構成が変更されたことを検出すると、情報の同期を再開します。

同期中に停止状態が開始されるという可能性の低い事象では、その時点のインポートは破棄され、最新の既知の構成が使用されます。

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

停止モードでの操作に時間制限は適用されませんが、

意図的に停止を引き起こすこともできます。これを行う理由と方法について詳しくは、「停止状態の強制」を参照してください。

リソースの場所にCloud Connectorが複数存在する場合

CSSは、他のタスクの合間に、リソースの場所内にあるすべてのCloud Connectorに関する情報を定期的にセカンダリブローカーに提供しますリソースの場所で他のCloud Connectorを実行している各セカンダリブローカーは、この情報からすべてのピアセカンダリブローカーを把握します。

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

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

停止状態中にCloud Connectorを再起動した場合:

  • このCloud Connectorがブローカーに選出されていない場合は、再起動しても影響はありません。
  • このCloud Connectorをブローカーに選出している場合は、別Cloud Connectorが選出されてVDAはそちらに登録されます。再起動したCloud Connectorの電源がオンになると、このCloud Connectorが自動的に仲介処理を引き継ぐため、VDAはこちらのConnectorにもう一度登録されます。このシナリオでは、登録中にパフォーマンスに影響が生じることがあります。

イベントログには、選出に関する情報が含まれます。

停止中に使用できないもの、およびその他の相違点

停止モードでの操作に時間制限は適用されませんが、リソースの場所からCitrix Cloudの接続が失われた場合は、可能な限り迅速にリソースの場所の接続を復元する必要があります。

停止状態発生時:

  • 管理者はStudioやPowerShellコマンドを使用できません。
  • 停止状態中は、監視データがCitrix Cloudに送信されなくなります。このため、監視機能(Director)には、停止状態中のアクティビティは表示されません。
  • ハイパーバイザー資格情報をホストサービスから取得できません。すべてのマシンの電力状態が不明で、電源操作を発行できません。ただし、電源が入っているホスト上のVMを接続要求のために使用することができます。
  • 割り当てられたマシンは、通常の操作中に割り当てが発生した場合のみ使用できます。停止状態中は新しい割り当てはできません。
  • リモートPCアクセスマシンの自動登録と構成はできません。ただし、通常の操作中に登録、構成されたマシンは使用できます。
  • サーバーでホストされるアプリケーションとデスクトップのユーザーは、リソースが異なるゾーンにある場合、構成されている最大セッション数よりも多くのセッションを使用できる場合があります。
  • ユーザーは、現在アクティブ/選択されているブローカーを含むゾーン内の登録済みVDAからのみ、アプリケーションとデスクトップを起動できます。停止中は、ゾーン間での起動(あるゾーンのブローカーから別のゾーンのVDAへ)はサポートされません。
  • デリバリーグループ内のVDAに対してスケジュールされた再起動が開始される前にサイト構成データベースの停止が発生した場合、停止が終了すると再起動が開始されます。これは意図しない結果につながる可能性があります。詳しくは、「データベースの停止によるスケジュールされた再起動の遅延」を参照してください。

StoreFrontの要件

各リソースの場所には、顧客が展開するオンプレミスのStoreFrontが必要です。ローカルホストキャッシュは、オンプレミスのStoreFrontが含まれるリソースの場所でのみ動作します。ワークスペースはサポートしていません。

リソースの可用性

停止時のリソースの可用性(アプリとデスクトップ)を確保するには、次の2 つの方法があります:

  • 展開内のすべてのリソースの場所にリソースを公開します。
  • リソースを少なくとも1つのリソースの場所に公開します。次に、以下の手順に従って、各StoreFrontストアで詳細なヘルスチェック機能を有効にします。

    1. 各リソースの場所のStoreFrontインストールをバージョン1912 CU1以降にアップグレードします。詳しくは、StoreFrontのドキュメントを参照してください。
    2. StoreFrontストアごとに、詳細なヘルスチェックオプションを有効にします。ストアのweb.configファイルのfarmsetsの下にadvancedHealthCheck="on"を追加します。

      次に例を示します:

      StoreFrontの詳細なヘルスチェック

    3. ファイルの更新後、手動でIISを再起動します。他のストアでweb.configファイルの更新とIISの再起動を繰り返します。

アプリケーションとデスクトップのサポート

ローカルホストキャッシュは、顧客が展開するStoreFrontでのみ機能します。ワークスペースはサポートしていません。

ローカルホストキャッシュは、サーバーでホストされるアプリケーションおよびデスクトップ、および静的な(割り当て済み)デスクトップをサポートします。

ローカルホストキャッシュは、以下のようにプールされたデリバリーグループでデスクトップVDAをサポートします。

  • デフォルトでは、停止状態が発生した場合、「ShutdownDesktopsAfterUse」プロパティが有効なプールされたデリバリーグループ内で電源管理されているデスクトップVDA(MCSまたはCitrix Provisioningによって作成)は、メンテナンスモードになります。このデフォルトの設定を変更して、停止状態中にこれらのデスクトップを使用できるようにすることができます。

    ただし、停止状態中は電源管理が機能しないことがあります。(通常の操作を開始すると電源管理が始まります)。また、これらのデスクトップは再起動していないため、前のユーザーのデータが含まれている可能性があります。

  • デフォルトの動作を上書きするには、サイト全体で、影響を受けるデリバリーグループごとに、これを有効にする必要があります。サイト全体で有効にするにはサポートに連絡します(このコマンドは、Remote PowerShell SDKを使用して実行することはできません)。

    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を使用できます。これらのメモリ要件は、Cloud Connectorの通常のRAM要件とは別なので、RAMの総容量の増加が必要になる場合があります。

SQL Server Express LocalDBは、最大1.2GBのRAM(データベースキャッシュ用に最大1GB、SQL Server Express LocalDBの実行用にさらに200MB)を使用できます。High Availability Service(ローカルホストキャッシュブローカー)は、停止状態が長時間続き、多数のログオンが発生した場合(たとえば12時間でユーザー数1万人)、最大1GBのRAMを使用できます。これらのメモリ要件は、Cloud Connectorの通常のRAM要件への追加です。そのため、RAMの総容量は増加が必要になることがあります。

CPUコアとソケットの構成に関する考慮事項

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

SQL Server Express LocalDBは複数のコア(最大4つ)を使用できますが、単一のソケットだけに制限されます。1つのコアを持つソケットを4つ用意するなどしてソケットを増やしても、パフォーマンスは向上しません。それよりも複数のコアを持つ複数のソケットの使用をお勧めします。Citrixのテストでは、2x3(2つのソケット、3つのコア)の構成が、4x1および6x1の構成より良好なパフォーマンスを示しました。

ストレージの考慮事項

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

パフォーマンスについての考慮事項

停止状態中は、選出されたローカルホストキャッシュブローカーがすべての接続を処理します。通常の操作時に複数のCloud Connectorに負荷を分散するリソースの場所では、停止状態中に、選出されたローカルホストキャッシュブローカーが通常よりはるかに多くの要求を処理しなければならなくなる可能性があります。このため、CPUにかかる負荷が大きくなります。選出されたローカーが変更される可能性があるので、リソースの場所内のすべてのローカルホストキャッシュブローカーが、追加の負荷と影響を受けるすべてのVDAを処理できる必要があります。

VDIの制限事項:

  • 単一のリソースの場所に展開する場合、停止状態時に実際に処理できるVDAの上限は10,000個です。
  • 複数のリソースの場所にVDIを展開する場合、停止状態時に実際に処理できるVDAの上限は各ゾーンで10,000個であり、環境全体では40,000個になります。たとえば、停止状態中も、次の展開環境は有効に処理できます:
    • 10,000個のVDAを含む二次リソースの場所が4つ設定された展開環境
    • 10,000個のVDAを含むリソースの場所1つと、5,000個のVDAを含むリソースの場所6つの計7つのセカンダリリソースの場所で構成された展開環境

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

すべてのVDAがローカルホストキャッシュブローカーに登録する間、そのブローカーは現在のセッションの一部を把握できなくなる場合があります。このため、その間の接続要求により、既存のセッションへの再接続が可能であっても、新しいセッションが起動される可能性があります。こうした時間(新しいローカルホストキャッシュブローカーが登録時にすべてのVDAからセッション情報を取得する時間)が発生するのは避けられません。停止状態の発生時に接続済みのセッションが、この移行期間に影響を受けることはありませんが、新しいセッションおよびセッションの再接続は影響を受ける可能性があります。

VDAが異なるローカルホストキャッシュブローカーに登録する必要がある次のシナリオで、この期間が発生します:

  • 停止状態の発生時:プリンシパルブローカーからローカルホストキャッシュブローカーに移行するとき。
  • 停止状態中にローカルホストキャッシュブローカーに障害が発生した場合:障害が発生したローカルホストキャッシュブローカーから新しく選出されたローカルホストキャッシュブローカーに移行するとき。
  • 停止からの回復:通常の操作が再開されプリンシパルブローカーが制御を再開したとき

構成の同期にかかる時間は、オブジェクト(VDA、アプリケーション、グループなど)の数により増加します。たとえば、5000個のVDAを同期する場合には、10分以上かかる可能性があります。

XenApp 6.xリリースとの相違点

このローカルホストキャッシュ実装は、XenApp 6.x以前のXenAppリリースのローカルホストキャッシュ機能の名前を共有しますが、これは技術的に完全に異なる実装です。これは大幅に改善された実装で、破損に対してより頑強で耐性があり、メンテナンスも少なくて済みます。

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

Citrix Virtual Apps and Desktopsサービス環境では、ローカルホストキャッシュは常に有効になっています。構成や管理の操作を行う必要はありません。

前述のように、Cloud Connectorをリソースの場所にインストールするとMicrosoft SQL Server Express LocalDBデータベースが自動でインストールされます。このデータベースを無効にしたり、削除したりしないでくださいCloud Connectorはシトリックスにより定期的に更新されます。SQL Server Express LocalDBソフトウェアを手動で無効にするか削除しても、次回のCloud Connectorの更新時に置き換えられます。

ローカルホストキャッシュが動作していることを確認する

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

  • リソースの場所に、このリソースの場所内のCloud ConnectorをポイントするローカルのStoreFrontが含まれていることを確認します。
  • 同期のインポートが正常に完了していることを確認します。イベントログで確認してください。
  • 各Cloud Connectorにローカルホストキャッシュデータベースが作成されていることを確認します。これにより、必要に応じてHigh Availability Serviceが処理を引き継げるようになります。
    • Cloud Connectorサーバーでc:\Windows\ServiceProfiles\NetworkServiceを参照します。
    • HaDatabaseName.mdfおよびHaDatabaseName_log.ldfが作成されたことを確認します。
  • リソースの場所にあるすべてのCloud Connectorで、停止状態の強制を実行してください。ローカルホストキャッシュが動作することを確認したら、すべてのCloud Connectorを通常モードに戻します。これには約15分かかります。

Cloud Connectorでのローカルホストキャッシュによるスケーラビリティに関する注意事項」を参照してください

イベントログ

イベントログに、同期および停止状態が発生した時刻が示されます。イベントビューアーのログでは、停止状態モードはHAモードと見なされます。

Config Synchronizer Service

通常の操作中、ローカルホストキャッシュブローカーを使用してCSSが構成データをローカルホストキャッシュデータベースにインポートすると次のイベントが発生することがあります。

  • 503:Citrix Config Sync Serviceが更新された構成を受信しました。このイベントは、Citrix Cloudから更新済みの構成を受信するたびに発生します。このイベントは、同期プロセスが開始されたことを表します。
  • 504:Citrix Config Sync Serviceが更新された構成をインポートしました。構成のインポートが正常に完了しました。
  • 505:Citrix Config Sync Serviceがインポートに失敗しました。構成のインポートが正常に完了しませんでした。過去に正常にインポートされた構成がある場合、停止状態の発生時にはその構成が使用されます。ただし、この構成は現在の構成よりも古いものです。使用可能な過去の構成がない場合、停止状態中、サービスはセッション仲介に参加できません。この場合は、「トラブルシューティング」セクションを参照し、シトリックスサポートにお問い合わせください。
  • 507:システムが停止状態であり、ローカルホストキャッシュブローカーが使用中であるため、Citrix Config Sync Serviceによりインポートが中止されました。サービスは新しい構成を受け取りましたが、停止状態が発生したためインポートは中止されました。これは正常な動作です。

高可用性サービス

このサービスは、ローカルホストキャッシュブローカーとも呼ばれます。

  • 3502:停止状態が発生しローカルホストキャッシュブローカーが仲介操作を実行しています。
  • 3503:停止状態が解消され、通常の操作が再開しました。
  • 3504:どのローカルホストキャッシュブローカーが選出されたかと、選出に関わった他のローカルホストキャッシュブローカーを示します。

停止状態の強制

停止状態は意図的に発生させることもできます。

  • ネットワークが稼働と停止を繰り返している場合。ネットワークの問題が解決するまで強制的に停止状態にすることにより、通常モードと停止状態モードの移行が繰り返され、VDA登録ストームが頻繁に発生するのを防げます。
  • 障害回復プランをテストするには:
  • ローカルホストキャッシュが正常に動作することを確認する場合。

強制的に停止状態にするには、各Cloud Connectorサーバーのレジストリを編集します。HKLM\Software\Citrix\DesktopServer\LHCOutageModeForcedを作成し、REG_DWORD1に設定します。この設定により、ローカルホストキャッシュブローカーはCitrix Cloudへの接続状態に関係なく停止状態モードに入ります。値を0に設定すると、ローカルホストキャッシュブローカーの停止状態モードは終了します。

イベントを確認するには、C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityServiceCurrent_HighAvailabilityServiceログファイルを監視します。

トラブルシューティング

ローカルホストキャッシュデータベースへの同期インポートが失敗し505イベントがポストされた場合には、次のトラブルシューティングツールが役立ちます。

CDFトレーシング:ConfigSyncServerモジュールおよびBrokerLHCモジュール向けのオプションが用意されています。これらのオプションと他のブローカーモジュールを組み合わせることで、問題を特定できます。

レポート:同期インポートが失敗した場合、レポートを生成できます。このレポートの最後に、エラーの原因となったオブジェクトが記載されています。このレポート機能は同期速度に影響するため、使用しないときは無効にしておくことをお勧めします。

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