ローカルホストキャッシュのサイズ設定とスケーリング

概要

この記事では、ローカルホストキャッシュ(LHC)を使用してCitrix Virtual Apps and Desktops を導入する際のサイズと拡張に関する推奨事項について説明します。Citrix DaaS のサイズとスケールの推奨事項については、「 Cloud Connectorのサイズとスケールの考慮事項」を参照してください。

LHC は、停止中も接続仲介を継続できるようにすることで、高可用性を実現します。LHCのユーザーは、以下の設計上の考慮事項を守らなければなりません:

  • 停止中は、ゾーンごとに1つのブローカーがVirtual Delivery Agent(VDA)の登録とブローカーセッションを処理します。
  • どのブローカーがアクティブであるかを決定する選挙プロセスでは、ブローカーのリソースは考慮されません。
  • ゾーン内の 1 つのブローカーが通常の操作ですべてのログオンを処理できない場合、停止モードでは正常に動作しません。
  • 停止中は、サイト管理は利用できません。
  • 高可用性の SQL Server は、引き続き推奨される設計です。
  • 断続的なデータベース接続のシナリオでは、SQL Server を分離し、根本的な問題がすべて修正されるまでサイトを停止モードのままにしておくことをお勧めします。
  • ゾーンあたりのVDA数は10,000に制限されています。
  • プールされたデスクトップは、デフォルト構成では停止モードではサポートされていません。

アーキテクチャ

LHC はローカルの SQL Server データベースを使用します。このデータベースは、接続リースよりもディスク容量の使用率が高くなりますが、必要な CPU とメモリはかなり多くなります。LHCには同期フェーズがあり、メインサイトデータベースの詳細がブローカー(コントローラー)に同期されます。LHC は、引き続き IOPS を必要とする SQL データベースを使用しており、これらの書き込みを SQL で最適化できるという利点があります。

LHCは、すべての接続を仲介し、VDA登録を処理するために選ばれた単一のブローカーを採用しています。サイト内のすべてのVDAがこの単一ブローカーに再登録されるため、特に多数のVDAがあるサイトでは、(通常の運用におけるマルチブローカーサイトと比較して)リソースに対する需要が高くなります。

LHC は Microsoft LocalDB を使用しており、タスクマネージャーでは sqlserver.exe プロセスとして表示されます。データベースバッファプールのキャッシュに最大 1 GB のメモリを使用するように構成されています。ただし、SQL エンジン自体やその他の小さなキャッシュ用のメモリが必要となるため、この処理はさらに大きくなります。一般に、停止時間が長くなり、停止モード中にアクセスされるリソースが増えるほど、LocalDB のメモリ使用量が増えます。ただし、サイトデータベースの接続が復元されても、sqlserver.exe はこのメモリを保持し、すぐにメインプールに戻すことはありません。

停止モード中の CPU ソケットとコアの影響

LHC は LocalDB と呼ばれるランタイムバージョンの SQL Server を使用しています。このバージョンには、4 コアまたは 1 ソケットのうち小さいほうに制限される特定のライセンスがあります。これは、物理マシンまたは仮想マシンがシングルコアまたはデュアルコアのみの複数のソケットで構成されている場合に、パフォーマンスに大きな影響を与える可能性があります。ソケットが4つあり、ソケットごとに1つのコアを持つブローカーマシンでは、LocalDBは1つのコアしか使用できません。一方、同じVMが1ソケット、4コアのマシンとして構成されている場合、LocalDBは4つのコアすべてにアクセスできます(他のプロセスと共有しますが)。停止モードでは、LocalDB は通常の操作時と同じブローカーと SQL コードを実行します。SQL クエリの多くはCPUを大量に消費し、停止モード中の仲介のパフォーマンスに直接影響します。詳細については、「 Cloud Connectorのサイズとスケールの考慮事項 」と「 SQL Serverのエディションごとの計算能力の制限」を参照してください。

その他の要因には、次のようなサイト構成自体が含まれます。

  • 公開されたアプリケーションの数
  • 仲介されているユーザーの数
  • ユーザーがセッションを起動しようとする頻度
  • Active Directory パフォーマンス

ブローカーの合計CPU使用率が 100% に近づくと、仲介応答時間が長くなり、ログオンの処理に時間がかかり、一部のログオン試行が失敗する可能性があります。

複数のブローカーがあるサイト

サイト停止モードでは、登録要求とログオン要求を処理するブローカーは 1 つだけです。マルチブローカーのサイトでは、停止中にアクティブになるブローカーを指名するための選挙プロセスが行われます。ただし、この選挙プロセスでは、ブローカーが利用できる物理的リソースは考慮されません。つまり、ブローカーのリソース量が異なるサイトでは、選出されたブローカーが必ずしもCPUまたはRAMの観点から最も強力であるとは限らないため、停止モード中にパフォーマンスが低下する可能性があります。当選された場合に備えて、各ブローカーがLHCの追加要件を満たしていることが重要です。

サイトデータベースとの同期

CitrixConfigSync Serviceは、サイトデータベースからブローカーのローカルコピーへのデータのインポートを処理します。サイト構成の変更についてサイトデータベースを監視し、変更が発生すると新しいインポートをトリガーします。インポートが開始される前に、現在のローカルデータベースのコピーが作成されます。サイト内のリソース(VDAなど)の数が多いほどインポートに時間がかかりますが、10,000のVDAがあるサイトの場合は10分未満になる場合があります。

データベースロケーション

ローカルデータベースは次の場所に格納されます。

C:\Windows\ServiceProfiles\NetworkService\HaDatabaseName.mdf

信頼性を確保するために、CitrixConfigSync Serviceは、新しいサイトデータベースの同期を開始する前に、以前に正常に同期されたデータベースインポートのバックアップを作成します。何らかの理由で同期が正常に完了しなかった場合、同期が正常に完了するまでバックアップが使用されます。データベースは手動でコピーしないでください。

ローカルホストキャッシュの技術仕様

アーキテクチャ スペック
ディスク領域 サイト構成によって異なります。1,000 台の RDS ホストと 9,500 台の VDI と 65 ,000 人のユーザーの場合、75 MB が使用されます。
RAM 3 GB、SQL Server の場合は最大 1 GB、高可用性サービスと CitrixConfigSync サービスの場合は 2 GB。
設定を同期する時間 10,000台のVDA: 約7分
停止中にアクティブ化する時間 VDAの数とブローカーとの最終登録同期によって異なります。停止モード中にVDAを登録できるのは1つのブローカーのみであるため、VDAの数が多い場合、すべてのVDAが登録されるまでに数分かかることがあります。
通常の操作を復元する時間 前述のように、VDAはセカンダリブローカーから登録を解除し、プライマリブローカーに再登録する必要があります。
サポートされているVDAの数 10,000。サイトにはこれ以上あってもかまいませんが、サイトデータベースの同期に必要な時間はVDAの数が増えるにつれて長くなります。多数のVDAを使用する単一のブローカーのパフォーマンスにより、停止中に一部の接続が仲介されないことがあります。
停電中のサイト管理 いいえ

ローカルホストキャッシュの有効化または無効化

LHC は必要に応じて有効または無効にできます。

Set-BrokerSite –LocalHostCacheEnabled $True $False

制限事項

デスクトップは、停止モードで使用する前に割り当てられている必要があります。未割り当てのデスクトップは仲介できません。これにより、ユーザーに実際にデスクトップが割り当てられているにもかかわらず、すべての割り当てが同期される前に停止が発生した場合、デスクトップが使用できなくなり、「メンテナンスモード」と報告される可能性があります。

プールされたデスクトップは、デフォルト構成では停止モードではサポートされません。回避策はありますが、セキュリティとパフォーマンスに影響する可能性があります。プールされたデスクトップを含むデリバリーグループをログオフ時に再起動しないように構成すると、そのグループ内のパワーオン状態のプールデスクトップはすべて停止モードで使用できます。ただし、ユーザーがログオフすると、デスクトップは再起動されないため、デスクトップはクリーンな状態にはなりません。これは、どのようなシナリオでもセキュリティ上の問題になる可能性があります。そのデスクトップの次のユーザーがそのデスクトップのローカル管理者である場合、前のユーザーのデータにアクセスできる可能性があります。また、このリスクは標準 (管理者以外) のユーザーにとってはそれほど問題にはなりませんが、時間が経つとアプリケーションが正しく動作せず、パフォーマンス上の問題が発生する可能性があることに注意してください。重要:管理者は、再起動されていないプールデスクトップをシステム停止モードで使用する場合に、この回避策を使用することによる潜在的な影響を慎重に検討する必要があります。

停止中は、サイトを変更できません。このデータベースは実質的にはメインサイトデータベースのスナップショットであり、新しい同期が発生するたびに破棄されます。

データベースサイズ

10,000 VDI 構成 (つまり 10,000 台のシングルセッション VDI デスクトップ) では、LocalDB は約75 MBでした。100,000 RDS 構成 (つまり 100,000 ユーザー) の場合、LocalDB はアプリケーションとログオンの数に応じて 100 ~ 300 MB の範囲で変動しました。新しいインポートが開始される前にデータベースのコピーが作成されるため、LocalDB 用に 1 GB の領域を確保してください。

ユーザーサイジングに関する考慮事項

ゾーンあたりの最大VDAは10,000ですが、停止中はセッションが選択したブローカーの負荷に寄与するため、ゾーンごとのピークセッション数も考慮することをCitrixではお勧めします。マルチセッションVDAを使用すると、1つのVDAに対して複数のセッションを開始できるため、セッション密度が重要になります。

停止中の推奨ピークは、ゾーンあたり 25,000 ユーザーです。適切なサイズであれば、1 分あたり 1 ~ 2,000 回のリソース起動に達する可能性があります。

アプリケーションの起動はデスクトップの起動と同様に扱われます。どちらにも同じ推奨事項が適用されます。ただし、Citrix では起動率も考慮することを推奨しています。1人のユーザーが複数のアプリケーションを起動できるため、停止時にユーザーごとにブローカーにかかる負荷が増加します。

アプリケーション容量を計算する際には、ユーザーごとに起動されるアプリケーションの平均数を把握し、同じ推奨値 (ゾーンあたり 25,000) の範囲内に抑えてください。

まとめ

サイトデータベースの停止中、LHC はさまざまなリソースと条件をサポートしますが、運用時には CPU とメモリの計画と考慮が必要です。

複数のブローカーサイトでは、どのブローカーも停止ブローカーとして選出される可能性があるため、すべてのブローカーが停止モードに対処するのに十分なリソースを持っている必要があります。ブローカーリソースの評価は行われないため、さまざまなリソースを持つブローカーがいるサイトでは、停止時に最も強力なブローカーが選出される可能性があります。

コアとソケットのレイアウトは、ブローカーの設計の一部として考慮する必要があります。

公開アプリケーションとデスクトップの数は、ログオン応答時間と最大ログオンスループットに影響します。

CPU リソースが不十分なブローカーでは、起動が失敗する可能性があります。

Citrix では、ウイルス対策の除外を定義することを推奨します。詳細については、「 テクニカルペーパー:エンドポイントセキュリティ、ウイルス対策、およびマルウェア対策のベストプラクティス」を参照してください。

LHC 停止モードでのパフォーマンスをテストするには、2 コアと 2 GB の RAM を追加することから始めるとよいでしょう。

LocalDB データベースには 1 GB のディスク容量で十分です。

ブローカーが過負荷になると、接続が失敗します。

ローカルホストキャッシュのサイズ設定とスケーリング