高度な概念

XenAppおよびXenDesktop 7.9でのCitrix ユニバーサルプリントサーバーの負荷分散

テスト方法

すべてのテストシナリオは現実の方法で行われ、最終エンドでの印刷は唯一のシミュレーションコンポーネントでした。テストシステムは、XenServer仮想マシン、インフラストラクチャ(DDC、StoreFront、ユニバーサルプリントサーバー)用のWindows 2012R2、XenAppのVDAシステム、XenDesXenDesktopのVDAシステム用のWindows 10、Citrix Receiverを介したICA起動用のWindows 8.1で構成されています。各ICAランチャーは10台のプリンターに接続され、ICAランチャー間でプリンターが重複せず、カスタムスクリプトが使用され、XenApp VDAセッションごとにランダムプリンターが提供されます。また、カスタムスクリプトは、AutoItを使用して同一の印刷アクションを実行する各セッション内の印刷を制御しました。最後に、内部で開発されたツールを使用して、ICAセッションの起動を調整し、テスト用のperfmonデータを収集しました。

ユニバーサルプリントサーバーの負荷分散サイジング

環境内の他のすべてのコンポーネントと同様に、ユニバーサルプリントサーバーの負荷分散を最適に実行するには、サイジングが非常に重要です。大きな文書の印刷はニーズに応じて主観的であるため、この記事では主に印刷速度に焦点を当て、平均的な仕事とみなすものを使用します。

内部テストにより、負荷分散でUniversal Print Serverインスタンスを設定する必要がないことがわかりました。また、必ずしもそうではないプリンタの配布について話しているときに、追加のユニバーサルプリントサーバーインスタンスで印刷を増やすことができます。特に、構成されているユニバーサルプリントサーバーインスタンスが多すぎる場合です。この場合、最初に利用可能なユニバーサルプリントサーバーインスタンスへのユーザーのスキューがあります。

プリントサーバーあたりのユーザー数を示すグラフ

このグラフは、16台のユニバーサルプリントサーバーインスタンスを利用する48台のXenAppサーバーで3,500台のユーザーテストシナリオを示しています。上記のように、最初の8つのUniversal Print Serverインスタンスは接続の大部分を占め、接続の均等な分布はありませんでした。このシナリオでは、印刷レートが低くなることも想定しています。これについては後ほど説明します。

この問題が発生する理由を理解するには、負荷分散メカニズムがユニバーサルプリントサーバーインスタンスをどのように選択するかを検討する必要があります。16 ユニバーサルプリントサーバーのインスタンス (番号 1-16) の負荷分散と単一のXenAppサーバーで 10 最大ユーザー(便宜上誇張されています)があるとします。また、負荷分散されたユニバーサルプリントサーバーのインスタンスが、負荷分散ポリシーのユニバーサルプリントサーバーの番号順になっているとします。

XenAppでユーザーがログオンしてセッションを作成すると、そのユーザーが受信するユニバーサルプリントサーバーのインスタンスはランダムになります。これは、使用可能なユニバーサルプリントサーバーの任意のインスタンスである可能性があり、どのサーバーにも優先権が与えられていません。この例では接続のためにサーバー16を受信したとします。最初のユーザーがログオンし、セッションの作成が完了したら、別のユーザーがログインします。このユーザーは、ポリシーのリスト内の最初のユニバーサルプリントサーバーインスタンス(この場合はサーバー1)を使用します。別のユーザーがログインし、サーバ 2 を利用しています。この傾向を続けると、以下に示すサーバーのロードが提供されます。10人のユーザーがすべてログインすると、ユニバーサルプリントサーバーのインスタンス1~9と16は接続されますが、残りのサーバーは接続されません。

ユニバーサルプリントサーバーごとのユーザーを示すグラフ

これで、XenAppサーバーをミックスに追加し、最大ユーザー数は10人です。このサーバーは、最初のユーザーがサーバー 16 ではなくサーバー 4 をランダムに受信することを除いて、前の例と同じ手順に従います。この場合、後続のログインごとに同じプロセスが実行されますが、現在接続が行われているサーバ4をスキップする点が異なります。この場合、サーバ1~10が接続されます。下のグラフでオレンジ色の追加のユーザーのバランスが取れていることを観察することができます。

追加のユーザーがプリントサーバー間でバランスをとる方法を示すグラフ

引き続きサーバー数を増やすと、発生するスキューがわかりにくくなります。実際には、ユニバーサルプリントサーバーのインスタンスと同等またはそれ以上の数のXenAppホストが必要です。また、より最適なロードに使用する予定のユニバーサルプリントサーバーインスタンスの倍数として、ユーザーセッション数を保持することをお勧めします。この観点から上記のシナリオを見ると, 2つの XenAppサーバーと 16のユニバーサルプリントサーバーインスタンスの場合、XenAppサーバーあたり最小16ユーザーのユーザーロードにする必要があることがわかります。同じ問題を調べるもう1つの方法は、XenAppサーバーあたり10人のユーザーのみをサポートしている場合、ユニバーサルプリントサーバーインスタンスは10個以下です。これにより、よりバランスのとれた負荷が得られ、利用可能なリソースがより効果的に利用されます。

上記は、厳密にユーザー接続バランシングを扱うセットアップを過度に単純化したものです。サーバあたりのユーザー数が増えたより複雑なセットアップは、想定される構成です。ユーザーの増加に伴い、前述の印刷速度は、ユニバーサルプリントサーバーのサイジングにおいて大きな役割を果たします。以下の式を使用して、環境に必要なユニバーサルプリントサーバーインスタンスを決定することをお勧めします。これにより、必要な印刷レートに基づいて、負荷分散に必要なユニバーサルプリントサーバーインスタンスの数を決定できます。サイジングを簡素化するために、この式を使用して、必要な印刷レートを提供するためのより理想的なセットアップのガイダンスを提供することができます。一般に、N を解決して、独自のプリントサーバー数を決定することに最も関心があります。

V\*P/N \< J

各項目の意味は次の通りです:

V = LBを使用するVDAの数

P = VDAあたりのアクティブなネットワーク印刷ジョブの1分あたりの平均数

N = 負荷分散されたプリントサーバーの数

J = ユニバーサルプリントサーバーでの1分あたりの最大ジョブ数

7.8以降のVDAでPを観察するには、VDA上の既存のUniversal Print Clientのパフォーマンスモニターカウンターを調べます。具体的には、ユニバーサルプリントサーバーポリシーが有効でネットワークが設定されているVDAで、通常の稼働日中にネットワークプリンターの1分間に作成されるジョブの平均を監視します。セッションにマッピングされたプリンタ。

J には、プリントサーバーのハードウェアパフォーマンスおよび印刷するドキュメントのサイズに応じて、50 ~ 100 の数値を指定します。

上記の式は一般化されており、お客様の環境の要件に大きく依存します。ユニバーサルプリントサーバーの負荷分散を実装する前に、ご使用の環境の印刷要件を完全に理解することが重要です。

毎分100ジョブ(JPM)テスト

新しいユニバーサルプリントサーバーの負荷分散で最大の改善点の 1 つは、1 分あたりの同時印刷ジョブの増加です。毎分100ジョブという倍増の印刷レートのしきい値により、個々のユニバーサルプリントサーバーインスタンスでさらに高い密度を実現できるようになりました。負荷分散された複数のユニバーサルプリントサーバーインスタンスに分散すると、この増加倍数の影響が大きくなります。以下は毎分作成されたジョブカウンタ(式で参照されるもの)のperfmon出力で、18時間以上のテストサイクルで毎分〜100ジョブに平均しています。

18時間のテストサイクル中に1分間に作成されたジョブを示すグラフ

VDIランダム化

VDI 環境で使用される負荷分散方法は、ランダム化機能の実装のみです。前述のように、負荷分散プロセスはVDAでのみ実行され、最初の接続がランダム化され、その後ログインはユニバーサルプリントサーバーインスタンスのリスト全体で負荷分散されます。VDI実装にはVDAごとに1人のユーザーがいるため、ランダム化機能のみが適用されます。

ランダム化が確実に機能するように、16個のユニバーサルプリントサーバーインスタンスを使用して500人のXenDesktop テストを実行しました。これは、(完全に負荷分散された世界で)ユニバーサルプリントサーバーインスタンスあたり約31セッションに作用し、ランダム化の有効性を明確に判断します。以下は、このテストの結果として作成されたプリンタ接続です。接続がユニバーサルプリントサーバーのインスタンスにランダムに割り当てられていることは簡単に確認できます。

テスト中に作成されたプリンタ接続数を示すグラフ

5000 ユーザーテスト

XenAppサーバー自体の密度により、ユニバーサルプリントサーバーの負荷分散の最大のメリットが実現されます。ユニバーサルプリントサーバー の負荷分散の規模が大きいユーザー数環境でどれだけ大きくなるかを判断するために、5,000 のユーザーテストの実行が、負荷分散を検証するのに十分な大きさであることが決定されました。

テスト中に 5,000 人のユーザーがプリントサーバー間でどのように負荷分散されたかを示すグラフ

上記は、48台のXenAppサーバーと16台のユニバーサルプリントサーバーインスタンスを備えた5,000台のユーザーテストの結果です。このユーザー数は、XenAppサーバーあたり約100ユーザー、またはXenAppサーバーあたりユニバーサルプリントサーバーインスタンスごとに約6.5ユーザーです。この結果は、先に特定された歪みを示しています。これは、最適に設計されたテストではないためです。最終的には、これはロードバランシング機能のデモンストレーションを目的としています。

ユニバーサルプリントサーバーの負荷分散フェイルオーバー

デフォルトでは、ユニバーサルプリントサーバーのインスタンスは 180秒 MINIMUM の失敗として報告されず、360秒の失敗と見なされます。このタイムアウトは、ユニバーサルプリントサーバーインスタンスの障害が発生した瞬間にフェイルオーバーが発生しないため、理解しておくことが重要です。フェイルオーバーが発生する前に、ユニバーサルプリントサーバーインスタンスがリカバリを試行する時間があります。より迅速なフェイルオーバーが必要な場合は、環境のニーズに基づいて変更を行う必要があります。これらの変更は、Citrix ポリシーと、2つのレジストリキーを使用して行うことができます。

以下は、フェイルオーバーの実際のデモです。16台のユニバーサルプリントサーバーインスタンスで48台のXenAppサーバー間で2,304人のユーザーが使用され、初期負荷分散とその後のフェイルオーバーが示されています。上記の値は、XenAppサーバーごとにユニバーサルプリントサーバーインスタンスあたり3ユーザーになるように、理想的には選択されています。

負荷分散とフェイルオーバーを示すグラフ

すべてのユニバーサルプリントサーバーインスタンスが均等にロードされ、すべてのユーザーがログインします。ユニバーサルプリントサーバーインスタンス UPServer06 および UPServer11 は、Hypervisor レベルで (ユニバーサルプリントサーバーインスタンスの可用性状態を判断するために PING が使用されているため) 強制シャットダウンの対象となり、完全に障害が発生したと見なされます。以下では、影響を受けるサーバー接続がオレンジ色で強調表示されています。次に、オレンジ色の失敗したサーバー接続が、残りのユニバーサルプリントサーバーインスタンスに再配布されます。

失敗したサーバ接続の分布を示すグラフ

その後、使用可能な既存のサーバーへの新しい接続が確立されます。以下に、以前に失敗した接続が既存のサーバーにどのように再配布されるかを示します。

失敗した接続の再配分を示すグラフ

既に説明したように、既存の接続では動的に負荷分散されません。負荷分散は、ユーザーセッションのログオン時にのみ行われます。そのため、障害が発生した ユニバーサルプリントサーバー インスタンスが再び使用可能になると、再調整やフェールバックは発生しません。障害が発生したユニバーサルプリントサーバーインスタンスがオンラインに戻りますが、既存の接続は行われません。

障害が発生したサーバーがオンラインに戻ったときの接続の分布を示すグラフ

これらのユニバーサルプリントサーバーインスタンスが再び利用可能になり、接続を受け入れることを示すには、追加のユーザーにログオンするか、それ以上のユニバーサルプリントサーバーインスタンスの障害を強制する必要があります。以下では、ユニバーサルプリントサーバーインスタンス UPServer08 および UPServer10 に強制的な障害が発生し、それぞれの接続がオレンジ色で強調表示されています。

障害が発生したサーバの分布を示すグラフ

失敗すると、接続が他のサーバーに移行されることが分かります。この場合、以前に障害が発生した 2 台のサーバーに戻され、再度接続できるようになります。これらのサーバーは最も負荷が少ない(負荷がない)ため、接続の大部分を使用します。

複数のプリントサーバーの追加

複数のユニバーサルプリントサーバーインスタンスを負荷分散ポリシーに追加するには、Citrix ポリシーGUIまたはPowerShell コマンドレットを使用します。Citrix ポリシーGUIは、その使用において自明です。以下に、PowerShell を利用して、複数のユニバーサルプリントサーバーインスタンスを負荷分散ポリシーに追加する方法を示します。

  1. Add-PSSnapin Citrix.Common.GroupPolicy
  2. New-PSDrive –PSProvider CitrixGroupPolicy –Name Site –Root \ -Controller localhost
  3. CD サイト:コンピュータ
  4. 編集するポリシーを CD に追加 (UPSLB ポリシーを含むポリシー名)
  5. CD 設定ICAPRingユニバーサルプリントサーバー負荷分散プリントサーバー
  6. New-Itemを使用して新しいプリンターを一覧に追加する

PowerShell スクリプトの実行を示す画像

しかし、この方法の使用にはいくつかの注意点があります。まず、情報を正しく入力していることを確認してください。いくつかのプリンターをポリシーに手動で追加し、PowerShell ディスプレイでどのように表示されるかを確認して、正しく追加することができます。第 2 に、ポリシー UI をサイドステッピングしているため、実行されるプリントサーバーの検証はありません。

ユニバーサルプリントサーバーカウンタ

サイジングセクションで述べたように、現在の印刷状況に関する情報を決定するために使用できる新しい perfmon カウンタがあります。ユニバーサルプリントサーバーインスタンスとXenApp/XenDesktopシステムの両方に一意のカウンタが存在します。

ユニバーサルプリントサーバーインスタンス全体に関連するカウンターは、前述の 1 分間に作成されたジョブカウンターなど、対応するユニバーサルプリントサーバーインスタンスに配置されます (これらのカウンターは、そのユニバーサルプリントサーバーインスタンスのみ、複数のインスタンス)。ユニバーサルプリントサーバーの負荷分散に関連するカウンターは、現在の接続カウンターなど、各XenApp/XenDesktopシステム上に存在します(負荷分散は個々のVDAレベルで行われます)。

UPClient(VDAコンポーネント)固有のカウンタは、特定のユニバーサルプリントサーバーインスタンス、すべてのユニバーサルプリントサーバーインスタンス、またはVDA上のすべてのユニバーサルプリントサーバーインスタンスの合計としてデータをキャプチャするように構成できます。これらのカウンタは、perfmon から直接確認することも、PowerShell を使用してスクリプトを作成することもできます。次のカウンタは、perfmonのCitrix Printing Load Balancingセクションで使用できます。これらのカウンタは、VDAの合計(_loadbalancers_total)を選択するか、特定のVDAで使用可能なユニバーサルプリントサーバーインスタンス(ユニバーサルプリントサーバーインスタンス名)を選択することによってさらに選択できます。

アクティブなプリンタ接続カウンタ: Performance\\Citrix Printing Load Balancer (SELECTION)\\Active Printer Connections

作成されたプリンタ接続カウンタ: Performance\\Citrix Printing Load Balancer (SELECTION)\\Created Printer Connections

削除されたプリンタ接続カウンタ: Performance\\Citrix Printing Load Balancer (SELECTION)\\Deleted Printer Connections

これらは標準のパフォーマンスモニターカウンターであるため、PowerShell の組み込みGet-Counterコマンドレットを使用して、特定のVDAから情報を取得できます。

Get-Counter -Counter \\\\VDAName\\Citrix Printing Load Balancer(SELECTION)\\COUNTER

上記のコマンドは、SELECTION(ユニバーサルプリントサーバーインスタンス名または_loadbalancers_total)の目的のVDAName(名前、FQDN、またはIPアドレス)から目的のカウンター(アクティブ/作成/削除されたプリンター接続)情報を取得します。これにより、カウンタオブジェクトの完全なリストが提供されます。

PowerShell カウンタオブジェクトの出力を示す画像

実際の値だけに関心がある場合は、このコマンドを他のコマンドにパイプして、調理された値(または接続値だけ)を取得する必要があります。これを実現するために、このコマンドを前のコマンドの最後に追加します。 | Foreach-Object {$_.CounterSamples.CookedValue[0]}

返された値のみを示す画像

テスト環境

テスト環境は、XenServer 6.2および6.5を実行する3つの別々のプールされたハードウェアセットで構成されていました。Citrix インフラストラクチャコンポーネント(DDC、StoreFront、ICAランチャー、メトリック収集)を含む単一のXenServer 6.2プールと、ユニバーサルプリントサーバーインスタンスとテストRDS VDAを含む2つの6.5プールが存在していました。テストには 2 つの独立した集中型ストレージリポジトリが使用され (プールバージョンごとに 1 つ)、すべてのテスト用仮想マシンがそこに配置されました。使用されるすべてのソフトウェアは、実施されたテストの時点で最も最新のものでした。すべてのテストは、結果の一貫性を保証するために、同じドライバとドライバのバージョンで実施されました。追加のドライバがテストされました。個々の結果は、使用するドライバによって異なります。

XenServer 6.2 物理サーバー (x10)

  • インテル Xeon E5620 x 2.40 GHz (4 — コアハイパースレッディング) — 16 CPU
  • 64 GB のメモリ
  • NFSストレージ

XenServer 6.5物理サーバ(x25)

  • インテル Xeon E5-2640 x 2.50 GHz (6 — コアハイパースレッディング) — 24 CPU
  • 256 GB のメモリ
  • NFSストレージ

ユニバーサルプリントサーバVM

  • 16 vCPU(16 ソケット x 1 コア)
  • 16 GB vRAM
  • 75 GB のストレージ
  • Windows Server 2012 R2

RDS仮想仮想仮想機

  • 16 vCPU(16 ソケット x 1 コア)
  • 16 GB vRAM
  • 75 GB のストレージ
  • Windows Server 2012 R2

ICAランチャー仮想マシン

  • 2 vCPU(2 ソケット x 1 コア)
  • メモリメモリ
  • 60 GB のストレージ
  • Windows 8.1 x64 Enterprise

Citrix ユニバーサルプリントサーバーポリシー

ICA\印刷

  • ユニバーサルドライバープリファレンス-XPS、EMF、PCL5c、PCL4、PS
  • ユニバーサルプリンタードライバーの使用 — ユニバーサル印刷のみを使用
  • ユニバーサルプリントサーバーの有効化 — Windowsのネイティブリモート印刷へのフォールバックなしで有効
  • プリンターが作成されるのを待つ — 有効
  • 負荷分散のためのユニバーサルプリントサーバー — プリントサーバーのリスト

ユニバーサルプリントサーバーとRDS/VDA VMは、同じハードウェアプール物理サーバー内に保持され、一貫したハードウェア構成でテストが実行されることを確認しました。DDCおよびStoreFront サーバーは、DDCからのポリシーの伝播を除き、ユニバーサルプリントサーバーの負荷分散に影響を与えないため、上記に含まれていません。ドメインでは最小限のポリシーが使用され、XenDesktop/XenAppサイトはデフォルトのインストールであり、上記のユニバーサルプリントサーバーおよび負荷分散ポリシーを除きます。

XenAppおよびXenDesktop 7.9でのCitrix ユニバーサルプリントサーバーの負荷分散