高度な概念

SQL ServerとCitrix データベース

Microsoft SQL Serverは、Citrix Virtual Apps and Desktops の展開において重要なコンポーネントです。Citrix SQLの相互作用の計画と理解は、適切で優れたパフォーマンスを維持するうえで、お客様とお客様の組織にとって非常に有益です。SQL Serverの高可用性と十分なコンピューティングリソースが不足していると、Citrix Infrastructureのユーザーエクスペリエンスとアップタイムに悪影響を及ぼします。

データベースの概要

Citrix Virtual Apps and Desktops の展開中に必要な、または作成される3つのデータベースがあります。

サイト: (サイト構成とも呼ばれます)は、実行中のサイト構成と、現在のセッション状態、接続、ロード、VDAステータス情報などの仲介に関連する動的データを格納します。

構成ログ:(ログ とも呼ばれます) には、サイト構成の変更と管理アクティビティに関する情報が格納されます。このデータベースは、構成ログ機能が有効化(デフォルトは有効)されているときに使用されます。

モニター: セッションや接続情報などのデータを格納するために、Directorにより使用されます。

以前のバージョンのCitrix Virtual Apps and Desktops(XenAppおよびXenDesktop 7.6など)では、Citrix Virtual Apps and Desktops に必要なデータベースは、初期サイトの構成時に(StudioまたはSQL Serverでスクリプトを実行することによって)1つのデータベースとして作成されています。インストール後、管理者は、パフォーマンスを向上させるために、またはバックアップ/セキュリティのガイドラインに準拠するために、別のデータベースに分割することができます。

新しいリリースのCitrix Virtual Apps and Desktops では、サイトの初期構成時、Studioを介して、またはSQL Serverでスクリプトを実行することによって、データベースを作成できます。データベースは自動的に3つの別々のデータベースに分割されます。

大規模な監視データベースがある環境では、監視データベースをサイト構成および構成ログデータベースとは異なるサーバーでホストすることが理想的です。これは、より多くのデータを記録し、変更がより頻繁に発生し、データは他のデータベースほど重要であるとはみなされません。詳しくは、「データベースのサイズ設定ガイダンス」または「VDIハンドブック」の 97 ページを参照してください。

長期サービスリリース (LTSR) の各累積的な更新プログラム (CU) には、SQL データベーススキーマの修正プログラムが含まれています。たとえば、CTX230536を参照してください。予期しない問題から環境を保護するには、環境を最新の CU に定期的にアップグレードするプロセスがあることを確認してください。また、リソース使用率が高く、空き領域がある障害イベントや問題を検出するために、適切な SQL サーバーとデータベースの監視が行われていることを確認します。

Citrix とSQLの相互作用

Citrix Virtual Apps and Desktops ブローカーは、ブローカー通信、構成、監視、および監査データの格納のためのメッセージバスとしてデータベースを使用します。データベースは常時使用されており、SQL サーバー上で大量のコンピューティングリソースを消費する可能性があります。

たとえば、リソースの列挙(ユーザーに表示されるリソース)、リソースの起動、セッションの起動の各段階では、Citrix Delivery Controller がSQLサーバーと対話する必要があります。

列挙: Citrix ADCおよびStoreFront による認証が成功すると、Delivery Controller はCitrixサイトのデータベースにアクセスして、ユーザーが利用できるアプリケーションをAD資格情報に基づいて確認します。リソースが識別されると、アプリケーション、デスクトップ、アイコンの名前などの追加情報がデータベースから取得されます。

起動: ユーザーが起動するアプリケーションまたはデスクトップを選択すると、StoreFront によってDelivery Controller への起動要求が開始されます。その後、Delivery Controller はSQLサーバー上のサイトデータベースにアクセスして、ユーザーの送信先となる適切なVDAを選択します。

セッションの初期化: セッションの起動後、VDAはDelivery Controller と通信し、セッション情報をサイトデータベースに書き込みます。

データベースの推奨事項

SQL Serverの停止がCitrix Virtual Apps and Desktops のインフラストラクチャへの影響を最小限に抑えるため、Citrixがサポートする以下の高可用性オプションから選択できます。

  • AlwaysOn可用性グループ
  • AlwaysOn フェイルオーバークラスタリング
  • 基本可用性グループ
  • Hypervisorの高可用性*

注:

Citrix はHypervisorの高可用性をサポートしていますが、稼働時間が最も重要であるEHRアプリケーションをホストする環境では使用することはお勧めしません。

Citrix とEpicでは、エンドユーザーセッションの確立に構成ログとデータベースの可用性の監視は必要ありませんが、3つのデータベースすべてで同じ高可用性アプローチを使用することをお勧めします。たとえば、SQL Always-On 可用性グループを HA 戦略として使用する場合は、これを 3 つのデータベースオブジェクトすべてに使用します。

また、Citrix データベース自体、特にサイトデータベースの完全バックアップを毎日実行することをお勧めします。保存期間は組織の要件によって異なりますが、通常、7日間のフルバックアップと少なくとも1か月分の週単位のバックアップを維持します。トランザクションログのバックアップスケジュールは、組織の標準と、割り当てる必要がある使用可能なストレージの量に対するトランザクションログの増加率の組み合わせに基づいて作成する必要があります。SQL サーバーで利用可能なストレージを監視してください。

Citrix データベースのリカバリモデルを、使用している高可用性アプローチの要件に合わせます。

Microsoftの推奨事項では、インデックスを維持するために、お客様のセットアップメンテナンスプランを毎晩および毎週実行することをお勧めします。保守計画は、単に週に夜間にインデックスを再編成し、週末にインデックスを再構築することです。

この推奨事項により、特に大規模な監視データベースの場合、今日の操作中に大きなインデックスを再構築することによるパフォーマンスへの影響を回避できます。

Microsoftでは、断片化が 30% を超える場合はインデックスを再構築し、30% 未満の場合は再編成することをお勧めしています。詳しくは、「データベースのメンテナンス」セクションを参照してください。

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

データベースが使用できなくなるシナリオを考慮するため、Citrix はローカルホストキャッシュ(LHC)機能をCitrix Virtual Apps and Desktops 7.xプラットフォーム(7.12以降、XenAppおよびXenDesktop 7.15 LTSRを含む)に追加しました。このオプションを有効にすると、Delivery ControllerとCitrix サイト構成データベース間の通信が中断された場合に、公開アプリケーションのユーザーが接続できるようになります。SQL が、常時オン、ミラーリング、クラスタリングなどの高可用性アーキテクチャで構成されている場合、この機能により、SQL の完全停止が発生したり、ネットワーク接続が中断されたりしたときに、フォールトトレランスがさらに高くなります。

SQL の停止中はサイト管理機能を使用できず、フェイルオーバープロセスが瞬時に行われないため、これは SQL 高可用性の代替とは見なされません。SQLが停止した場合、仲介機能はLHCに移行し、VDAが再登録されるまで失われます。このシナリオは、SQL の接続性/可用性が復元されたときに、通常の操作モードに戻るときにも発生します。

ローカルホストキャッシュは、すべてのDelivery Controller 上のローカルSQL Express LocalDBデータベースに静的サイトデータのコピーを保持し、データベースの停止中もこのデータを利用して、VDA登録とセッション仲介要求を継続的にサポートします。

ローカルホストキャッシュの設計上の考慮事項

Epic Community Memberの展開のサイズはさまざまであるため、Citrix と緊密に協力して、LHCを利用するために必要な追加のリソースを特定することをお勧めします。

  • スケーラビリティに関する注意事項
    • XenAppおよびXenDesktop 7.15のLHCに関する文書化された最大制限は、シングルゾーンでは10,000のVDA、マルチゾーン展開では40,000のVDAです。Citrix Virtual Apps 環境では、LHCとゾーンのスケーラビリティはログオン速度とユーザー数に依存します。したがって、環境で観察される実際のスケーラビリティは、公開された最大値よりも低くなる可能性があります。このアーキテクチャでは、予想されるセッション数が 10,000 を超えたり、ログオンレートが 1 秒あたり 10 ユーザーを超えたりする場合は、追加のゾーンを検討することをお勧めします。
  • Delivery Controller のサイズ設定:LHCが有効な場合、ゾーンごとに選択されたプライマリDelivery Controller(DC)がすべてのVDA登録、列挙、起動、および更新を処理します。
    • RAM: ローカルホストキャッシュサービスは、停止の期間と停止中のユーザーの起動回数に応じて、2 GB の RAM を消費する可能性があります。
    • CPU: 選出された DC の CPU 負荷が増えるため、補うために余分なコアを考慮する必要があります。

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

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

  • ストレージ:ローカルホストキャッシュモードでは、ストレージ使用率は 2 ~ 3 分ごとに約 1 MB 増加します。1 秒あたりの平均ログオン数は 10 と仮定します。ストレージ消費量は、ログオン率に比例して増加します。詳しくは、「ローカルホストキャッシュ」の記事を参照してください。

データベース停止の影響

データベース全体の停止が発生した場合、Delivery Controller の重要な機能のほとんどが影響を受け、推奨されるSQL HA戦略の1つを設計および実装することの重要性が強調されます。次の表では、これらの効果について説明します。

コンポーネント データベース停止の影響
サイト構成データベース ユーザーは、仮想デスクトップに接続または再接続できません。注: ローカルホストキャッシュ (LHC) を使用すると、ホストされている共有デスクトップ、ホストされている Windows およびブラウザアプリケーション、および個人用デスクトップを持つユーザーは、サイトデータベースが使用できない場合でも、アプリケーションおよびデスクトップに再接続できます。LHCモードの場合、監視データは収集されず、サイトの設定変更はできません。
監視データベース Directorには履歴データが表示されず、Studioを起動できません。受信したユーザー要求と既存のユーザーセッションの仲介は影響を受けません。
構成ログ データベース [Citrix Virtual Apps and Desktops]のログ設定で[ データベースの切断時に変更を許可する ]が有効になっている場合、構成ログデータベースの停止は影響を受けません(構成変更がログに記録されない場合を除く)。そうしないと、管理者はCitrix Virtual Apps and Desktops に変更を加えることができません。

SQLサイジングの推奨事項

環境のパフォーマンスと安定性を確保するために、SQL Server のサイズを正しく設定する必要があります。すべてのCitrix 製品では異なる方法でSQL Serverを使用し、お客様ごとに異なる使用パターンがあるため、一般的なサイズに関する推奨事項は提供できません。代わりに、製品ごとの SQL Server のサイジングに関する推奨事項を以下に示します。また、展開時にパフォーマンスを慎重に監視して、サイジングの前提を検証する必要があります。

Citrix関連データベースのみをホストするSQL環境の場合、最大10,000人のユーザーに対して最低4vCPUと8GBのRAMをSQLサーバーにプロビジョニングする必要があります。大規模な展開または高いログオンレートの展開では、最低 8 vCPU および 16 GB の RAM を使用することをお勧めします。Citrix Virtual Apps and Desktops 7.xの展開におけるSQLデータベースのサイズ設定の概念について詳しくは、データベースのサイズ設定を参照してください。この資料には、予想されるトランザクションログの増加率など、ワークロードの特性に関する情報も含まれています。

監視データベースのサイズは、データ保持の設定によって異なることに注意してください。XenAppおよびXenDesktop 7.15 LTSRには、詳細なVDAパフォーマンスデータをキャプチャする機能を追加した後、7.6 LTSRよりも多くのオプションがあります。これらの設定の構成について詳しくは、「「監視のポリシー設定」」を参照してください。これをデータベースサイジング計算で考慮してください。

CU の更新と修正

Citrix は年に数回、Citrix Virtual Apps and Desktops LTSR用のCUをリリースします。これらの CU には、セキュリティ更新プログラムとバグ修正のみが含まれており、新機能は導入されていません。製品で特定された問題を解決するため、最新のCUを実行することをお勧めします。これらの修正の一部は SQL に関連しています。Citrix またはお客様によって特定されたロック、デッドロック、ストア手順などの問題に対処します。たとえば、XenApp 7.6のCU5まで、多くのSQL関連の修正が行われています。推奨されるのは、各 CU の「 解決済みの問題 」セクションを確認し、ページ内の SQL を検索することです。

修正された問題

注:

は、7.6 キュー5 および 7.17 でリリースされました。

その他の参考ドキュメント

Contributed by Henry Vernov, Principal System Engineer.