高度な概念

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

ローカルホストキャッシュは、XenDesktop 7.6で提供される接続リース機能を置き換えるために、XenAppおよびXenDesktop 7.12で導入されました。ローカルホストキャッシュは、接続リースよりも多くのシナリオをカバーしますが、設計上の考慮事項は異なります。

接続リース機能の設計上の考慮事項の詳細については、https://www.citrix.com/blogs/2014/11/11/xendesktop-7-6-connection-leasing-design-considerations/を参照してください。

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

アーキテクチャ

XenDesktop 7.6で接続リースが導入され、サイトデータベースが停止している間もリソースに引き続きアクセスできるようになりました。VDI プールされたデスクトップはサポートされていませんでした。デフォルトでは、ユーザーは過去 14 日以内にリソースに接続している必要があります。さらに制限事項として、通常の操作中に最後に接続したデスクトップまたはアプリケーションホストにユーザーを接続しようとすることがありました。これが利用できない場合、接続は仲介されません。

2つのテクノロジー(接続リースとローカルホストキャッシュ)のアーキテクチャは非常に異なっており、動作するには異なるリソースが必要です。接続リースでは、個々の XML リースファイルが作成されます。これには、サイト内のリソース数によっては、数GB のディスク容量が必要になる場合があります。ローカルホストキャッシュは、ローカル SQL Server データベースを使用し、ディスク領域の使用効率が向上しますが、接続リースよりもメモリと CPU がかなり多くなります。両方とも、メインサイトデータベースからの詳細がブローカー(コントローラ)に同期される同期のフェーズがあります。接続リースの初期同期では、ファイルシステム上に作成される個々のファイルの数が多いため、かなりのIOPSが発生する可能性があります。ローカルホストキャッシュは、IOPS を必要とする SQL データベースを使用しますが、これらの書き込みを最適化する SQL という利点があります。

複数のブローカーを使用した接続リース設定では、各ブローカーは XML リースのコピーを持ち、停止時に接続を仲介できるため、負荷の分散に役立ちます。ただし、ローカルホストキャッシュでは、すべての接続を仲介し、VDA登録を処理する単一のブローカーが選択されます。サイト内のすべてのVDAは、この単一のブローカに再登録されます。そのため、ブローカーは、通常の操作ではマルチブローカサイトと比較して、特に多数のVDAを持つサイトではリソースの需要が高くなります。

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

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

以前のリリースのXenAppおよびXenDesktop では、管理者はブローカー(コントローラー)マシンのCPU構成(物理マシンまたは仮想マシンのソケット数とコアの数のレイアウト)に必ずしも関心を寄せていませんでした。

ローカルホストキャッシュは、LocalDBと呼ばれるランタイムバージョンのSQL Serverを使用します。LocalDBには、4つのコアまたは1つのソケットのうち小さい方に制限する特定のライセンスがあります。これは、物理マシンまたは仮想マシンがシングルコアまたはデュアルコアのみを持つ複数のソケットで構成されている場合、パフォーマンスに大きな影響を与える可能性があります。4つのソケットとソケットごとに1つのコアを持つブローカーマシンは、LocalDBを単一のコアを使用するように制限しますが、1ソケット4コアマシンとして設定されている同じVMは、LocalDBが4つのコアすべてにアクセスできるようにします(他のプロセスと共有しますが)。停止モードでは、LocalDBは、通常の動作時と同じブローカとSQLコードを実行します。SQL クエリの多くは CPU を大量に消費し、停止モード中の仲介のパフォーマンスに直接影響を与えます。

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

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

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

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

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

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

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

データベースの場所

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

C: Windowsサービスプロファイルネットワークサービスデータベース名.mdf

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

ローカルホストキャッシュとコネクションリースの比較

  接続リース ローカルホストキャッシュ
ディスク領域 2 GB を推奨 サイトの構成によって異なります。125 K ユーザを持つ 50 台の RDS ホストでは、300 MB が使用されます。
RAM 100 MB 3 GB、最大 1 GB、高可用性サービスおよび CitrixConfigSync サービスの場合は 2 GB です。
構成を同期する時間 IOPSに依存、40,000のVDA:約26分 5,000台のVDA:約7分
停止中のアクティブ化に要する時間 150秒、30秒のデフォルトSQLタイムアウト+ 120秒の待機期間(設定可能) VDAの数とブローカとの最後の登録同期によって異なります。停止モード中にVDA登録に使用できるブローカは1つのみであるため、多数のVDAでは、すべてのVDAが登録されるまでに数分かかることがあります。
通常のオペレーションのリストアに要する時間 リースを無効にするのに120秒かかります。その後、VDAをブローカーに再登録する必要があります。 上記のように、VDAはセカンダリブローカからの登録を解除し、プライマリブローカに再登録する必要があります。
サポートされるVDAの数 50,000 5,000. サイトにはこれ以上のものがありますが、サイトデータベースの同期に必要な時間はVDAの数に応じて増加します。多数のVDAを持つ単一のブローカーのパフォーマンスにより、停止中に一部の接続が仲介されないことがあります。
停止中のサイト管理 いいえ いいえ

ローカル DB のメモリ制限の設定

LocalDB プロセスは、キャッシュ用に 1 GB の RAM に制限されていますが、通常は変更する必要はありません。この値は、必要に応じて変更できます。変更を有効にするには、サイトが通常の操作 (停止モードではなく) で、サイトデータベースの同期を強制する必要があります。

メモリを 768 MB に減らすには、次の手順に従います。

手順1. C:\Program ファイル\ Citrix\ ブローカー\ サービス\ 高可用性サービス.exe.config ファイルを編集します。

<appSettings>`` セクションを探し、エントリを追加します。

<add key="MaxServerMemoryInMB" value="768" />

手順2. データベースの同期を強制するには、高可用性サービスを停止します。sqlserver.exe が実行されている場合は、タスクマネージャーまたは PowerShell を使用して停止します。

手順3. 次に、サイトに簡単な変更を加えます。たとえば、デリバリーグループの説明を「.」を追加して変更し、再度削除します。次に、高可用性サービスを起動します。これは sqlserver.exe を起動し、同期が発生します。

メモリを減らしすぎるとパフォーマンスに影響するため、推奨されません。ただし、2 GB に増やすとパフォーマンスが大幅に向上せず、CPU リソースは RAM よりもボトルネックになります。

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

接続リースとローカルホストキャッシュの両方を無効にできますが、一度にアクティブにできるのはそのうちの 1 つだけです。

ブローカーサイトの設定 — コネクションリースの有効化 $False

Set-BrokerSite –LocalHostCacheEnabled $True

制限事項

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

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

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

ストレス条件下での6および8のvCPUブローカの性能比較

サイトは、50のRDSワーカーと5075のVDI VDAで構成されていました。各 RDS ワーカーは、2500 人のシミュレートされたユーザーをサポートできます。1 秒あたり 20 ユーザーという起動レートが設定されました。異なる数の公開アプリケーションがサイトに追加されました。

RDS ワーカーの場合、VDI 5075 では 100,000 人のユーザーが起動されました。

テストは、通常およびローカルホストキャッシュの動作(停止)モードで実施されました。

6 vCPUシステムでは、CPUのヘッドルームはほとんどなく、少数の例外があります <10) occurred when the published app count was >。

Windows 更新プログラムは、多くの実行中にグループポリシーによって無効にされ、tiworker.exe プロセス (Windows インストーラーモジュール) が長期間にわたってコア全体を使用することがわかりました。これにより、多数の起動失敗が発生し、テストが再実行されました。ブローカープロセッサはかなり古いですが、tiworkerプロセスは新しいものの単一のコアを消費し、テストに影響を与えます。

ハイパーバイザー構成

  • XenServer 7.0
  • AMD オプテロン 8431 2.4 GHz — 4 x 6 コア
  • 128 GB RAM
  • 読み取りキャッシュが有効
  • SSD ベースのストレージを搭載したWindows Storage Server 2012R2

ブローカー構成

  • 3つのコアを備えた2つのソケット、4つのコアを備えた2つのソケット
  • 10 GB RAM
  • Windows Server 2016
  • VDAタイプごとに1つのデリバリーグループ
  • ユーザーに表示されるすべてのアプリケーション
  • XenDesktop 7.12

StoreFrontの構成

  • StoreFront サーバー×6
  • Windows Server 2016
  • 仮想CPU×4
  • 10 GB RAM

NetScaler の構成

  • VPX 8000 version 11.063.16

SQL サーバーの構成

  • インテル E5-2630 2.3GHz 2x12コア
  • SQL Server 2012
  • RAM (メモリ)

注:サイトデータベース のみがオフラインになりました。監視データベースと構成データベースは、テスト中もアクセス可能でした。これは、モニタサービスがテスト中に一部の CPU を消費していたことを意味します。

ログオン応答時間を示すグラフ

通常、アプリケーションの数が増えると、ログオンの応答時間が長くなり、停止の応答時間は通常の操作よりも悪くなります。vCPU 数を増やすと、応答時間が短縮されます。テストで使用されるCPUはかなり古く、より現代的なCPUは一般的により良いパフォーマンスを与えることに注意してください。

ログオン時間を示すグラフ

「理論上の最小」行は、環境が 1 秒あたり 20 回の起動を処理できた場合に、100,000 人のユーザーがログオンに要する絶対最小時間であり、1 時間 23 分 20 秒になります。これらのテストでは、0 のアプリケーション行が 6 vCPU の場合は 1:30:57、8 vCPU の場合は 1:30:48 を管理していました。Active Directory ドメインのパフォーマンスは、ユーザーが認証される速度に多少影響します。

ローカルホストキャッシュローカルデータベースのメモリー使用量を示すグラフ

通常の条件下では、LocalDB メモリの使用は動作中に増加し、システムに負荷がない限り、そのメモリにハングアップします。処理されるユーザーが多いほど、使用されるメモリは最大で 1 GB まで大きくなります。最初の VDI テストでは、LocalDB は以前の RDS 実行からメモリを解放していませんでした。後続の VDI テストでは、テストの前にブローカが再起動され、使用メモリが少なくなりました。

ローカルホストキャッシュの高可用性サービスメモリ使用量を示すグラフ

ローカルホストキャッシュの CPU 使用率を示すグラフ

注: 値は合計システム CPU に正規化されているため、33.33% は 6 つのコアのうち 2 つであり、30% は 8 vCPU セットアップでは 2-1/2 コアです。

「オフ」という用語は通常のサイト動作を指し、「オン」はローカルホストキャッシュがアクティブであることを意味します。

毎秒20人のユーザーのリクエスト起動率は、通常の操作でもブローカーにとって非常に厳しいものです。通常の動作では、6 vCPU システムにはヘッドルームがありません。公開アプリケーションの数が増えるにつれてブローカの CPU が増加し、応答時間が遅くなります。ローカルホストキャッシュがアクティブな場合、セカンダリブローカー(HA)サービスは、CPUリソースのためのLocalDB(SQL)と競合し、通常の動作よりも悪い応答時間を与える必要があります。

8 vCPUシステムでは、いくつかのヘッドルームがあり、LocalDBはスケールアップしますが、この環境では、CPUが少量であるにもかかわらず、2-1/2コアでピークに達しました。

通常の操作では、同期が発生しない限り、LocalDB は CPU を消費しません。

停止中、プライマリブローカーは事実上CPUを使用しません。

データベースのサイズ

5075 VDI 構成の場合、LocalDB は約 40 MB でした。これは、アプリケーションおよびログオンの数に応じて、100,000 RDS で 100 ~ 300 MB の間で変化しました。新しいインポートが開始される前にデータベースのコピーが作成されるので、LocalDB 用に 1 GB の領域を許可します。

概要

サイトデータベースが停止している間、ローカルホストキャッシュは接続リースよりも幅広いリソースと条件をサポートしますが、運用時には多くの CPU とメモリが必要になります。

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

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

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

CPU リソースが不足しているブローカは、起動に失敗する可能性があります。

接続リースと比較して、ローカルホストキャッシュの停止モードでのパフォーマンスをテストするには、2 つのコアと 2 GB の RAM を追加することをお勧めします。

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

オーバーロードされたブローカは、接続に失敗します。

This article was written by Joe Deller.