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

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

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

データコンテンツ

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

  • サイトから公開されたリソースに対する特別な権限が割り当てられているユーザーおよびグループの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のブローカーを約2分おきにチェックして、構成に変更がないか確認します。こうした変更には、管理者によるもの(デリバリーグループのプロパティの変更など)とシステム操作(マシン割り当てなど)があります。
  • 前回のチェック以降に構成が変更された場合、CSSは、Cloud Connectorのセカンダリブローカー(Citrix High Availability Service、上図のHAブローカー)に情報を同期(コピー)します。前回のチェック以降に変更された項目だけでなく、すべての構成データがコピーされます。セカンダリブローカーは、Cloud Connector上のMicrosoft SQL Server Express LocalDBデータベースにデータをインポートします。CSSが、セカンダリブローカーのLocalDBデータベースの情報がサイトデータベースの情報と一致することを確認します。LocalDBデータベースは、同期が発生するたびに再作成されます。

LocalDBデータベースは、Cloud Connectorのインストール時に自動でインストールされます。このデータベースをCloud Connector間で共有することはできません。このデータベースは、構成の変更が検出されるたびに再作成されるため、バックアップする必要はありません。

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

停止状態発生時:

停止状態中の画像

停止状態になった場合:

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

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

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

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

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

リソースの場所(サテライトゾーン)にCloud Connectorが複数存在する場合

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

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

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

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

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

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

制限事項、考慮事項、要件

ローカルホストキャッシュは、サーバーでホストされるアプリケーションおよびデスクトップ、および静的な(割り当て済み)デスクトップでサポートされています。MCSまたはCitrix Provisioningで作成されたプール済みVDIデスクトップではサポートされていません(停止中には、VDIマシンを、使用後にクリーンなマスターの状態に復元できないため)。

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

  • 停止状態のリソースの場所にある項目に対してCitrix Cloudの管理機能(Studio)を使用したり、PowerShellコマンドレットを実行したりすることはできません。
  • 停止状態中は、監視データがCitrix Cloudに送信されなくなります。このため、監視機能(Director)には、停止状態中のアクティビティは表示されません。
  • ハイパーバイザー資格情報をホストサービスから取得できません。マシンはすべて不明な電力状態となり、電源操作を実行できなくなります。ただし、電源が入っているホスト上のVMを接続要求のために使用することができます。
  • 停止状態が発生した場合、ShutDownDesktopsAfterUseプロパティが有効なデリバリーグループにプールされている電源管理対象のデスクトップVDAは保守モードになります。
  • 割り当て済みのマシンは、停止状態の発生前に割り当てが行われている場合のみ使用できます。停止状態中は新しい割り当てはできません。
  • リモートPCアクセスマシンの自動登録と構成はできません。ただし、停止前に登録および構成されたマシンは、接続を受け入れることができます。
  • サーバーでホストされるアプリケーションとデスクトップのユーザーは、リソースが異なるリソースの場所にある場合、構成済みの最大セッション数よりも多くのセッションを使用できる場合があります。

RAMサイズの考慮事項

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オーバーヘッドが発生するのは、データベースとの接続が失われ、High Availability Serviceがアクティブである停止状態の間だけです。

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

ストレージの考慮事項

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

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

停止状態中は、1つのブローカーがすべての接続を処理します。通常の操作時に複数のCloud Connectorに負荷を分散するリソースの場所では、停止状態中に、選出されたブローカーが通常よりはるかに多くの要求を処理しなければならなくなる可能性があります。このため、CPUにかかる負荷が大きくなります。停止状態中には選出されたブローカーが変更される可能性があるので、リソースの場所内のすべてのブローカーが、LocalDBと影響を受けるすべての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分以上かかる可能性があります。

StoreFrontの要件

重要:

各サテライトゾーン(リソースの場所)には、オンプレミスのStoreFrontをインストールし構成する必要があります。ローカルホストキャッシュは、オンプレミスのStoreFrontが含まれるリソースの場所でのみ動作します。

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

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

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

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

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

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

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

  • リソースの場所に、このリソースの場所内のCloud ConnectorをポイントするローカルのStoreFrontが含まれていることを確認します。
  • 同期のインポートが正常に完了していることを確認します。イベントログをチェックします。
  • 各Cloud ConnectorにSQL Server LocalDBが作成されていることを確認します。これにより、必要に応じてHigh Availability Serviceが処理を引き継げるようになります。
    • Cloud Connectorサーバーで、c:\Windows\ServiceProfiles\NetworkServiceに移動します。\
    • HaDatabaseName.mdfおよびHaDatabaseName_logldfが作成されていることを確認します。
  • リソースの場所にあるすべてのCloud Connectorを強制的に停止します。ローカルホストキャッシュが動作することを確認したら、すべてのCloud Connectorを通常モードに戻します。この処理には、大量のVDA登録を避けるために15分程度かかることがあります。

Scalability considerations for using Local Host Cache with Cloud Connectors』も参照してください。

イベントログ

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

Config Synchronizer Service:

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

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

High Availability Service:

  • 3502:停止状態が発生し、セカンダリブローカー(High Availability Service)が仲介操作を実行しています。
  • 3503:停止状態が解消され、通常の操作が再開しました。
  • 3504:どのセカンダリブローカーが選出されたかと、選出に関わった他のブローカーを示します。

停止状態の強制

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

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

強制的に停止状態にするには、各Cloud Connectorサーバーのレジストリを編集します。HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\LHCで、OutageModeForcedを1に設定します。この設定により、ブローカーはCitrix Cloudへの接続状態に関係なく停止状態モードに入ります。値を0に設定すると、ブローカーの停止状態モードは終了します。

トラブルシューティング

LocalDBへの同期インポートが失敗し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