XenAppおよびXenDesktopバージョン7.6から現在のリリースまでのデータベースサイジングガイダンス
免責事項
このドキュメントには、シトリックス以外の第三者が管理するWebサイトへのリンクが含まれています。 シトリックスは、これらの第三者のWebサイトのコンテンツまたは使用について一切責任を負わず、保証も責任も負いません。 シトリックスは、お客様の便宜を図るためにのみこれらのリンクを提供しており、リンクが含まれていても、リンク先のWebサイトをシトリックスが推奨していることを意味するものではありません。 利用者の責任において、利用目的として選択したものがウイルスやその他の破壊的な性質のものを含まないように予防措置を講じる必要があります。
概要
一般的なXenDesktop 7環境は、次の3つのデータベースで構成されます。
- サイト構成データベース
XenDesktopデプロイメントの現在の構成と状態を保存します - モニタリングデータベース
Directorに表示する履歴データを格納 - 設定ログデータベース
XenDesktopデプロイメントに加えられた構成の変更を追跡します
デフォルトでは、構成ログと監視データベース (セカンダリデータベース) はサイト構成データベースと同じサーバーにあります。 最初は、3 つのデータベースはすべて同じ名前です。 シトリックスでは、サイトを作成した後にセカンダリデータベースの場所を変更することをお勧めします。
一般的な展開では、SQL Serverが提供する一時データベースであるTempDBも利用します。
データベースはそれぞれ目的が異なり、成長速度も異なります。
このドキュメントでは、各データベースに関する情報を提供し、XenDesktop 7をサポートするようにデータベースのサイズを決定する際に考慮すべき主な考慮事項について説明します。
注意: 記載されている数値はすべて推定値です。 デプロイメント間のばらつきは予想されます。
このドキュメントでは、ホスト型共有デスクトップ (HSD) と仮想デスクトップインフラストラクチャ (VDI) のサイズの違いについても説明します。 混合環境では、2 つのデスクトップタイプの推定値を組み合わせて、データベース全体のサイズを推定する必要があります。
XenDesktop 7.6 のドキュメントの変更点
このドキュメントは、7.6 XenDesktop を対象とするように拡張されました。 これは、7.6で追加された機能のサイズ変更を更新できるようにするためです。 データベースのサイジングに影響する新機能は次の 3 つです。
- 接続リース — 圧縮されたリースファイルはサイトデータベースに格納されます
- アプリの使用状況の監視 — 環境内で使用されるすべてのアプリの詳細が監視データベースに保存されます
- ホットフィックスインベントリの監視 — 環境内のコントローラー、VDA、VDAイメージに適用されるCitrixホットフィックスの詳細
テーブルサイズに関する情報は以下で更新されました。 1 秒あたりのトランザクション数とトランザクションログの増加率は 7.6 から 7.5 で同様であったため、これらのセクションは更新されませんでした。
大まかな考慮事項
サイトデータベース
サイトデータベースには、システムを実行するための構成情報が含まれています。
その使用法は次のような特徴があります。
- ピーク時には、ユーザーがログオンして追跡対象のセッションおよび接続情報が生成されるため、最大サイズに達します。
- アクティブなセッションがなく、VDAがすべてシャットダウンされて登録が解除されると、最小サイズに達します。
- データベースには永続的な情報がほとんど保存されないため、48 時間後にピークサイズに達します。 これは、サイトデータベース内で48時間保持されている接続の小さなログが原因です。
- サイトの構成情報が大きくなると、データベースのベースラインサイズも大きくなります。 つまり、より多くのワーカーとユーザーがより多くのデータベーススペースを消費します。
- ユーザーがログオンするたびに複数の個別のトランザクションを実行する必要があり、同時起動率に基づいてスケーリングされるため、ログオン中は 1 秒あたりのトランザクション数が多くなります。
- VDAハートビートトランザクションの低レベルのバックグラウンドノイズ。 各VDAは5分ごとにハートビートを送信し、この更新によりデータベース上のトランザクションがトリガーされます。
障害の影響
サイトデータベースが停止すると、システムを管理および監視できなくなります。 既存の接続は維持されます。 XenDesktop 7.6では、接続リース機能を使用して新しい接続や再接続を行うことができます。 以前のバージョンでは、新しい接続と再接続はできません。
モニタリングデータベース
監視データベースには、サイトに関する履歴情報が含まれています。 この情報は、Directorが履歴情報を表示するために使用されます。
その使用法は次のような特徴があります。
- 最大サイズは、次のように設定された保存期間によって制御されます。
- プラチナ以外のお客様の場合、デフォルトは7日間で、最大期間は7日間です。
- プラチナのお客様の場合、デフォルトは90日間で、最大期間はありません。
- システムが設定された保存期間に達する必要があるため、ピークサイズに達するまでに時間がかかる場合があります。
- 監視サービスによる更新はバッチ処理されるため、1 秒あたりのトランザクション数が低くなります。 1 秒あたりのトランザクション数が 1 秒あたり 20 トランザクションを超えることはめったにありません。
- 一部のバックグラウンドトランザクションは、モニタリングサービスからの定期的な統合コールによって引き起こされます。
- 設定した保持期間外のデータを削除するために、夜間処理が実行されます。
障害の影響
監視データベースが停止すると、サイトのデータが収集されなくなり、Director内でデータが表示されなくなります。
構成ログデータベース
構成ログデータベースには、サイトへのすべての構成変更の履歴ログが含まれています。 この情報は、レポートの生成や Studio での表示に使用されます。
その使用法は次のような特徴があります。
- 最大サイズは、構成アクティビティの量に依存するため、予測が困難です。
- Directorからのセッションリセットなどのアクションはすべてこのデータベースに記録されるため、管理者がDirectorを使用するにつれて増加が遅くなる可能性があります。
- 構成を変更していない場合、データベースで発生するトランザクションは最小限です。
- 更新は可能な限りバッチ処理されるため、更新中のトランザクションレートが低くなります。
- データの手動削除。 構成ログデータベース内のデータは保存ポリシーの対象ではなく、管理者が手動で削除しない限り削除されません。
障害の影響
構成ログデータベースが停止した場合の影響は、次のようにサイト構成によって異なります。
- 構成ログデータベースが使用できないときにサイトが変更を許可しない場合、XenDesktop展開を再構成することはできません。
- 構成ログデータベースが利用できない場合でもサイトが変更を許可している場合、XenDesktop展開環境に対して追跡されない構成変更が加えられる可能性があります。
テンポラリデータベース
テンポラリデータベースは、SQL Server が提供するシステム全体のデータベースです。 読み取りコミットスナップショットアイソレーションのバージョンストアとして使用されます。 XenDesktop 7では、このSQL Server機能を使用してXenDesktopデータベースでのロック競合を軽減しています。
バージョンストアのサイズは、アクティブなトランザクションの数によって異なります。 ただし、一般的には数MBにすぎません。
新しいデータを生成するトランザクションにはTempDBの容量が必要なため、TempDBのパフォーマンスはXenDesktop仲介のパフォーマンスに影響します。 ただし、XenDesktopはトランザクションの存続期間が短い傾向があるため、バージョンストアのサイズを小さく保つのに役立ちます。
テンポラリデータベースは、クエリによって大きな中間結果セットが生成される場合にも使用されます。
TempDB のサイジングと構成に関するガイダンスは、マイクロソフトの製品ドキュメントに記載されています。
主な争点は、使用するファイルの数です。 SQL Server 2000 などの古いバージョンの SQL サーバーでは、新しいバージョンよりも多くのファイルが必要になります。 使用するファイル数の詳細については、以下を参照してください。
読み取り専用スナップショット分離
Citrixでは、すべてのXenDesktop 7データベースで読み取りコミットスナップショット分離を使用することを推奨しています。 詳しくは、「 XenDesktopで読み取りコミットスナップショットを有効にする方法」を参照してください。
データベースのサイジング
データベースのサイズは、1 営業日に作成されるセッション数や接続数など、さまざまな重要な要素によって異なります。
セッションとは、一定期間実行されているデスクトップまたはアプリケーションで、切断して再接続することができます。
接続とは、ユーザーがセッションに接続する任意の時点のことです。 接続を切断すると、接続は閉じられますが、セッションは閉じません。 ユーザーが再接続すると、既存のセッションへの新しい接続が作成されます。
サイトデータベース
サイトデータベースの最大サイズは、次のように、VDAとアクティブなセッションの数に基づいています。
| ユーザ | [アプリケーション] | タイプ | 予想されるピークサイズ 7.5 (MB) | 予想されるピークサイズ 7.6 (MB) |
|---|---|---|---|---|
| 1,000 | 50 | HSD | 30 | 31 |
| 10,000 | 100 | HSD | 60 | 198 |
| 100,000 | 200 | HSD | 330 | 752 |
| 1,000 | 該当なし | VDI | 30 | 30 |
| 10,000 | 該当なし | VDI | 115 | 121 |
| 40,000 | 該当なし | VDI | 390 | 426 |
公開アプリケーションごとに 110 KB がデータベースに追加され、各固有のアイコンが格納されます。
注記:
7.6のサイズが増加したのは、Controller間のレプリケーションの一部として接続リースがデータベースに保存されるためです。
モニタリングデータベース
3つのデータベースのうち、監視データベースは時間の経過とともに最大規模に拡大すると予想されます。
そのサイズは、次のような多くの要因によって異なります。
- ユーザー数
- セッション数
- 接続数
- VDI または HSD ワーカー
- 保存期間の設定
以下は、いくつかのデータポイントにおけるデータベースサイズの推定値です。 このデータは、XenDesktopをスケールテストしたときに確認されたデータに基づく推定値です。 見積もりは現実的であると考えられています。
ただし、データベースを管理しているお客様は、データベースが推定値よりも小さいことに気付く場合があります。
HSD ユーザーは HSD サーバー 1 台につき 100 ユーザーに基づいています。
最大保存期間
保持されるデータの最大量は、ライセンスによって次のように制限されています。
- プラチナ会員以外のお客様は、最長1週間（7日間）のデータを保存できます。
- プラチナのお客様は、無制限のデータを保持できます。デフォルトは3か月（90日）です。
リテンション期間は Set-MonitorConfiguration コマンドレットを使用して調整できます。
設定された保存期間より古いデータは、データベースから削除されます。
XenDesktop 7.5 モニタリングデータベースのサイジング
1 ユーザーあたり 1 回の接続と 1 回のセッションで、週 5 日勤務した場合の見積もり
| ユーザ | タイプ | 1 週間 (MB) | 1 か月 (MB) | 3 か月 (MB) | 1 年 (MB) |
|---|---|---|---|---|---|
| 1,000 | HSD | 151 | 70 | 230 | 900 |
| 10,000 | HSD | 2,830 | 600 | 1,950 | 7,700 |
| 100,000 | HSD | 1,500 | 5,900 | 19,000 | 76,000 |
| 1,000 | VDI | 15 | 55 | 170 | 670 |
| 10,000 | VDI | 120 | 440 | 1,400 | 5,500 |
| 40,000 | VDI | 464 | 1,700 | 5,400 | 21,500 |
1 ユーザーあたり 2 つの接続と 1 つのセッションで、週 5 日勤務の場合の見積もり
| ユーザ | タイプ | 1 週間 (MB) | 1 か月 (MB) | 3 か月 (MB) | 1 年 (MB) |
|---|---|---|---|---|---|
| 1,000 | HSD | 30 | 100 | 330 | 1,300 |
| 10,000 | HSD | 240 | 925 | 3,000 | 12,000 |
| 100,000 | HSD | 2,400 | 9,200 | 30,000 | 119,000 |
| 1,000 | VDI | 25 | 85 | 280 | 1,100 |
| 10,000 | VDI | 200 | 750 | 2,500 | 9,800 |
| 40,000 | VDI | 800 | 3,000 | 9,700 | 38,600 |
HDD は、負荷分散情報のログ記録により時間の経過とともにより多くのデータを生成しますが、最初は VDI デスクトップと同じサイズであることに注意してください。
XenDesktop 7.6 モニタリングデータベースのサイジング
7.5 からの主な変更点は以下のとおりです。
- ホットフィックス情報
以下のデータは、ワーカー (VDI または HSD) あたり 3 つのホットフィックスに基づいています。 - アプリケーション使用履歴
これは主に HSD システムに関係します。
1 ユーザーあたり 1 回の接続と 1 回のセッションで、週 5 日勤務した場合の見積もり
| ユーザ | タイプ | 1 週間 (MB) | 1 か月 (MB) | 3 か月 (MB) | 1 年 (MB) |
|---|---|---|---|---|---|
| 1,000 | HSD | 151 | 605 | 1,966 | 7,865 |
| 10,000 | HSD | 2,830 | 11,301 | 36,712 | 146,834 |
| 100,000 | HSD | 7,194 | 28,585 | 92,758 | 370,841 |
| 1,000 | VDI | 13 | 49 | 157 | 622 |
| 10,000 | VDI | 117 | 409 | 1,287 | 5,090 |
| 40,000 | VDI | 460 | 1,610 | 5,058 | 19,999 |
1 ユーザーあたり 2 つの接続と 1 つのセッションで、週 5 日勤務の場合の見積もり
| ユーザ | タイプ | 1 週間 (MB) | 1 か月 (MB) | 3 か月 (MB) | 1 年 (MB) |
|---|---|---|---|---|---|
| 1,000 | HSD | 159 | 635 | 2,063 | 8,251 |
| 10,000 | HSD | 2,904 | 11,599 | 37,684 | 150,718 |
| 100,000 | HSD | 7,940 | 31,572 | 102,465 | 409,672 |
| 1,000 | VDI | 21 | 79 | 253 | 1,008 |
| 10,000 | VDI | 191 | 708 | 2,258 | 8,974 |
| 40,000 | VDI | 759 | 2,805 | 8,941 | 35,532 |
構成ログデータベース
構成ログデータベースのサイジングに関するガイダンスを提供することは、Directorの日々のアクティビティと構成されたサイトのサイズによって大幅に変化するため、はるかに困難です。
セッションやユーザーに影響を与えるアクティビティはログに記録され、セッションのログオフやリセットなどが含まれます。 ユーザーのセッションを一覧表示するなどの受動的なアクティビティはそうではありません。
デスクトップの展開に使用されるメカニズムは、ログに記録されるデータのサイズにも影響します。
MCS を使用していない HSD 環境では、データベースサイズは 30 MB から 40 MB の間になる傾向があります。
MCS 環境では、すべての VM ビルドデータがログに記録されるため、データベースのサイズが 200 MB を超えることがあります。
7.6では、構成ログデータベースに大きな変更はありませんでした。
100k HSD セッションのログオン中のデータベースアクティビティ
スケーラビリティテストでは、100,000 回の HSD セッションログオンをシミュレートし、次の 2 つのログオン率でトランザクションログの増加を測定しました。
- 10 万人のユーザーが 1 時間以上ログインしている
- 10 万人のユーザーが 2 時間以上ログインしている
これらのレートは、データポイントの例を示すために選択されました。
環境は以下で構成されています。
- 2 デリバリーコントローラー
- 43 名の医療従事者
- データベースで構成された 3 台の SQL Server を 1 つの Always On 可用性グループ内に保持
サーバー構成の詳細は、このドキュメントの最後に記載されています。
トランザクションログの増加
すべてのデータベースのトランザクションログの増加は、パフォーマンスモニターカウンター SqlServer: Databases — ログファイル使用サイズ (KB) を使用して監視されました。
サイトデータベース
システムがアイドル状態になると、トランザクションログは 1 時間あたり 3.5 MB ずつ増加します。 これはVDAとブローカーサービスのハートビートの組み合わせです。
| テスト | 総ログオン増加量 (MB) | ログオフ総増加量 (MB) |
|---|---|---|
| 1 時間で 10 万 | 1,900 | 1,150 |
| 2 時間で 10 万 | 1,900 | 1,150 |
ログの増加は、測定対象期間にわたって直線的です。 このデータは、ユーザーがログオンするごとに、トランザクションログが 20 KB 増加することを示しています。 ユーザーがログオフするごとに、トランザクションログは 12 KB 増加します。
したがって、1 日あたりの増加量は、ユーザーログオン/ログオフサイクルあたり 32 KB です。
モニタリングデータベース
システムがアイドル状態になると、トランザクションログは 1 時間あたり 30.5 MB ずつ増加します。 これは、統合ストアドプロシージャとHSD VDAロードインデックスの更新を組み合わせたものです。
| テスト | 総ログオン増加量 (MB) | ログオフ総増加量 (MB) |
|---|---|---|
| 1時間で10万人 | 670 | 190 |
| 2時間で10万人 | 650 | 220 |
対数の増加は、測定対象期間にわたって直線的です。 このデータは、ユーザーログオンごとにトランザクションログが 7 KB 増加することを示しています。 ユーザーがログオフするごとに、トランザクションログは 2 KB 増加します。
したがって、1 日あたりの増加量は、ユーザーログオン/ログオフサイクルあたり 9 KB です。
1 秒あたりのトランザクション数
すべてのデータベースのトランザクションログの増加は、次のパフォーマンスモニターカウンターを使用して監視されました。
- SQL Server: データベース — 1 秒あたりのトランザクション数
- SQL Server: データベース — 1 秒あたりの書き込みトランザクション
サイトデータベース
システムがアイドル状態の場合、1 秒あたり 5 件のトランザクションが発生し、そのうちの 1 回の書き込みトランザクションが VDA と Broker のハートビートを維持します。
注意: これらの数値は、指定された期間からの推定値です。 正確な負荷は、1 秒あたりの同時起動数によって異なります。
| テスト | 1 秒あたりのログオントランザクション | 1 秒あたりのログオン書き込みトランザクション数 | 1 秒あたりのログオフトランザクション | 1 秒あたりのログオフ書き込みトランザクション数 |
|---|---|---|---|---|
| 1時間で10万人 | 870 | 310 | 250 | 100 |
| 2時間で10万人 | 475 | 170 | 140 | 60 |
モニタリングデータベース
システムがアイドル状態のとき、連結ストアドプロシージャは 1 分に 1 回実行され、トランザクションを生成します。 ただし、トランザクションのレベルは小さいです。 一般に、各連結ストアド・プロシージャには 2 ～ 3 件のトランザクションと 1 件の書き込みトランザクションがあり、3 つの連結ストアド・プロシージャが実行されます。 アクティブな期間中は、より多くの作業が実行されるにつれてオーバーヘッドが増加します。
注意: これらの数値は、指定された期間からの推定値です。
| テスト | 1 秒あたりのログオントランザクション | 1 秒あたりのログオン書き込みトランザクション数 | 1 秒あたりのログオフトランザクション | 1 秒あたりのログオフ書き込みトランザクション数 |
|---|---|---|---|---|
| 1時間で10万人 | 4 | 2 | 4 | 2 |
| 2時間で10万人 | 4 | 2 | 3.5 | 2 |
CPU 使用率
このテストに使用したすべての SQL サーバーは、ハイパースレッディングが有効になっているデュアル 16 コアサーバーでした。 正確なハードウェア仕様は、このドキュメントの最後に記載されています。
サーバーは、実行中の負荷に対してサイズが大きすぎることが知られていました。 これにより、ハードウェアに課せられている制限と最大値を特定できました。 SQL CPU の負荷は、実際には、デュアルの 16 コアシステムではなく、1 つのクアッドコアを搭載した SQL Server で処理できたはずです。
テスト中、システム CPU はパフォーマンスモニタカウンタを使用して監視されました。 プロセッサ–% プロセッサ時間–\ _合計。
プライマリレプリカ
アイドル状態のCPUは使用可能なCPUの0〜2％で動作していました。 統合ストアドプロシージャにより、システムCPUの最大1秒から8〜10％の間、1分ごとにスパイクが発生しました。 これは、処理されるデータ量に応じて規模が拡大することが予想されます。
100,000人のユーザーが1時間でログオンすると、環境内のセッションとユーザーが増えるにつれて、CPUは 7% に急上昇し、11% まで直線的に増加しました。 統合ストアドプロシージャの急増により CPU 全体の 7% が増加し、その急増が CPU の 18% に達したことに注意してください。
ログオフ中、CPUは3.5％で動作し、統合ストアドプロシージャ用に7％余分にCPUが使用されました。 全体として、ログオンとログオフの速度を維持するには、<20% のデュアルヘックスコアが必要だったことがわかります。
注: Windows Server 2012 のスケジューラーは、必要な場合にのみハイパースレッドを使用するように偏っています。つまり、システムの負荷が 50% に達するまでは、可能な限り 1 コアあたり 1 スレッドしか実行されないため、24 個のハイパースレッドの 20% の負荷は 4.8 コアで実行されています。
ワークロードを考えると、これは負荷の高いテストであり、XenDesktopの展開にはクアッドコアSQLサーバー1台で十分であると考えられています。
セカンダリレプリカ
セカンダリレプリカは、ログオン時に 2%、ログオフ中に 1.5% の CPU を構成することがわかりました。 これは、ほとんどの場合、レプリカはプライマリからのデータをディスクに保存し、プリンシパルレプリカはセカンダリが確認するまでトランザクションをコミットしないため、同期レプリカのみがトランザクションに関与しているためです。
HA ハードウェアをプライマリレプリカと一致させるという推奨事項に基づくと、この負荷は同様の仕様のサーバで非常に簡単に処理できます。
テンポラリデータベースの使用
TempDBは、バージョンストア、大規模なクエリセット用のスペース、その他の一時テーブルの使用など、さまざまな目的で使用されます。
テンポラリデータベースサイズ
この SQL 構成では、TempDB は 8 つのデータベースファイルで構成され、それぞれのサイズは 5 GB に固定されています。 これにより、TempDB の同時使用が向上しますが、十分な容量を確保でき、自動拡張イベントは発生しません。 キャプチャされたデータによると、今回の導入ではサイズが大きすぎました。 しかし、十分なディスク容量がありました。
また、TempDB データベースファイルの数は、使用可能な CPU 数の 4 分の 1 から 2 分の 2 分の 1 という一般的な目安の範囲内ですが、実際に競合が発生していることがわかっていなければ 8 を超えないようにしています。
SQL Server は複数のログファイルの恩恵を受けないため、使用される TempDB ログファイルは 1 つだけであることに注意してください。
バージョンストア
TempDBには、XenDesktopデータベースで使用される読み取りコミットスナップショット分離に関連する行バージョンのバージョンストアが含まれています。
使用状況は次のパフォーマンスカウンターで測定できます。
- SQL Server: トランザクション–バージョンストアサイズ (KB)
- SQL Server: トランザクション–バージョンクリーンアップレート (KB/s)
- SQL Server: トランザクション–バージョン生成レート (KB/s)
1 時間以上にわたって 100,000 回ログオンしても、バージョンストアのサイズは 10 MB から 30 MB の範囲にとどまり、バージョンが作成されてからクリーンアップされるまでの間、のこぎりぎりの効果がありました。 ログオフ時の範囲は 10 MB から 21 MB でした。 アイドル時のバージョンストアのサイズは 1 MB から 4 MB の範囲でした。
バージョン生成速度は、ログオン中は 250 ～ 500 KB の範囲で、ログオフ中は 150 ～ 400 KB/s、アイドル時は 0 ～ 250 KB/s の範囲でした。
バージョンクリーンアップは 1 分に 1 回実行され、ログオン中は 2,500 KB/s、ログオフ時には 1,750 KB/s、アイドル期間中は 400 KB/s に達しました。
ディスク I/O
ログオンテスト中に、次のパフォーマンスカウンターを使用してディスク I/O を測定しました。
- 物理ディスク — ディスク読み取りバイト数/秒
- 物理ディスク — ディスク書き込みバイト/秒
- 物理ディスク — 1 秒あたりのディスク読み取り数
- 物理ディスク — 1 秒あたりのディスク書き込み数
SQL Serverはすべてのデータをメモリに保持でき、システムでの読み取りアクティビティはほとんど発生しなかったため、読み取りI/Oは最小限であることがわかりました。
データベースとストレージシステムのレイアウトにより、ボリュームは分割され、1 つのボリュームにはすべてのデータファイルが格納され、もう 1 つのボリュームにはすべてのトランザクションログファイルが格納されます。
このデータは、表にまとめるのが難しいパターンを示しています。 一般に、トランザクションログの書き込みバイト/秒は、1 時間のテストでは 800 KB/s、2 時間のテストでは 400 KB/s でした。 1 分に 1 回、統合ストアドプロシージャを実行すると、トランザクションログに 30 MB/秒の急上昇が見られました。
統合ストアドプロシージャを分析すると、統計によってクエリプランが最適ではなくなる場合があり、一時テーブルが TempDB に流出することがあることがわかります。 これにより、TempDB のトランザクションログへの書き込みがトリガーされます。
このデータ転送は、1 時間のテストで 300 回の書き込み入出力操作数 (IOPS)、2 時間のテストで 200 回の書き込み IOPS という安定した状態になります。 統合ストアドプロシージャの急増により、実行中に書き込みIOPSが2～300件追加されます。 大規模な環境では、統合ストアドプロシージャの実行時間が 1 秒未満であることに注意してください。
各データベースがチェックポイントされると、データはインメモリテーブルからデータボリューム上のデータファイルに同期されます。
SQL チェックポインティングの詳細については、 http://technet.microsoft.com/enus/を参照してください。
これらのチェックポイントはごく短時間のアクティビティで、通常は1秒未満です。
ログオン中、チェックポイントは 6 ～ 7 MB/秒と 500 回の書き込み IOPS を消費しました。 ログオフ中、チェックポイントは 200 ～ 700 IOPS の範囲で 7 MB/秒を消費しました。 サイトデータベースと監視データベースでは、チェックポイントの対象となるデータ量が異なるため、数値は異なります。
データベースメンテナンス
大規模な展開では、データベースのメンテナンスが重要です。 データベースが適切に管理されていない場合、たとえば、トランザクションログが自動拡張に設定されていてディスクがいっぱいになったり、トランザクションログのサイズが固定されていていっぱいになったりした場合など、データベース領域不足が原因でデータベースが停止することがあります。
トランザクションログのメンテナンス
AlwaysOn可用性グループやデータベースミラーリングなどのSQL Serverの高可用性機能を使用する場合、XenDesktopデータベースはフルトランザクションログモードで実行されます。
フル・トランザクション・ログ・モードで実行すると、データベースまたはトランザクション・ログのバックアップが作成されるまで、トランザクション・ログは増え続けます。
SQL Serverはデフォルトでログファイルを自動拡張するように構成しているため、トランザクションログファイルが監視されていないと問題が発生する可能性があります。 これにより、次の 2 つの問題が発生します。
- トランザクションログファイルは大量のディスク容量を消費する可能性があります。
- トランザクションログが大きくなるたびに、ログスペースがゼロになるまですべてのトランザクションが停止します。
シトリックスでは、ログファイルを定期的にバックアップすることをお勧めします。 これは、スケジュールされたジョブまたはメンテナンスプランで実行できます。
または、SQL Server エージェントを使用して、ログの使用サイズがしきい値を超えたときを監視し、バックアップジョブを実行します。
スケールテストでは、4 GB の固定サイズのログが使用され、ログファイルが 80% いっぱいになったときにログを別のファイルにバックアップするようにアラートが設定されました。 これにより、ログの増大とディスク容量の消費が止まり、ディスク容量がゼロになってデータベースが停止することもなくなりました。
サンプルジョブでは、次のようなスクリプトが実行されます。
BACKUP LOG [CitrixXenDesktop-SiteDB] TO DISK = N'D:\LogBackup\CitrixXenDesktopSiteDB.bak' WITH NOFORMAT, NOINIT, COMPRESSION, NAME = N'Site-Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD
アラートに使用する SQL パフォーマンスカウンターは次のとおりです。
SQL Server: データベース-使用されたログの割合-シトリックスエンデスクトップサイトDB
これを 3 つのデータベースそれぞれで繰り返します。
ログファイルのバックアップは、実行中のXenDesktop環境への影響は最小限であることがわかりました。仲介時間はわずかに増加しましたが、それほど重要ではないと考えています。
ジョブ設定の詳細については、 https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-job?view=sql-server-ver15を参照してください。
アラートの設定の詳細については、 https://docs.microsoft.com/en-us/sql/ssms/agent/alerts?view=sql-server-ver15を参照してください。
インデックスのメンテナンス
データベースに入力されるデータが増えるにつれて、一部のインデックスがいっぱいになり始めます。つまり、各 SQL ページに保存されるレコードが少なくなります。 SQL ページは 8 KB です。 これにより、メモリとディスクの両方で、データベースのストレージニーズが増加します。 インデックスを維持することで、ページの空き容量を増やすことができ、データベースのメモリ要件を減らすことができます。
シトリックスでは、インデックスを維持するために、メンテナンスプランを夜間または毎週実行するように設定することをお客様に推奨しています。 メンテナンス計画としては、平日の夜間にインデックスを再編成し、週末にインデックスを再構築するだけの場合もあります。
この推奨事項により、特に大規模な監視データベースの場合、日常的な操作中に大きなインデックスを再構築することによるパフォーマンスへの影響を回避できます。
Microsoft では、断片化率が 30% を超える場合はインデックスを再構築し、30% 未満の場合は再編成することを推奨しています。 詳細については、 マイクロソフトドキュメンテーションを参照してください。
インデックスを再編成したら、統計も更新する必要があります。 これは、データベースが大きくなるにつれて特に重要です。そうしないと、一部の統計が不十分になり、SQLが最適ではないSQLクエリプランを生成する可能性があります。
容量の節約という点では、以下のMicrosoftスクリプトは1.2GBの監視データベースに対して実行されました。 これにより、ページフィリングが改善され、300 MBのスペースが解放されました。
サードパーティ製スクリプト
マイクロソフト
Microsoft では、次の URL から入手できるスクリプトを使用して WSUS SQL データベースのインデックスを更新することを推奨しています。
「USE SUSDB」を変更することで、このスクリプトをXenDesktopデータベースに対して実行することもできます。 このスクリプトは、断片化された 30% を超えるインデックスを再構築し、30% 未満のインデックスを再編成するというマイクロソフトのベストプラクティスに従っています。 次に、データベースの統計を更新します。
オラ・ハレングレン
より高度なスクリプトは、以下からも入手できます。
これらのスクリプトは SQL Server コミュニティで高く評価されています。 具体的には、インデックススクリプトは以下から入手できます。
http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
これらのスクリプトを使用すると、レベルをより細かく制御してインデックスを再編成または再構築できます。
テストサーバー構成
SQL サーバーの構成
SQL アベイラビリティグループは、まったく同じ仕様の 3 台の Dell R720XD サーバで構成されていました。
システム仕様:
- ハイパースレッディングを有効にして 2.30 GHz で動作する 2 つのヘックスコアインテル Xeon CPU E5-2630
- 64 ギガバイトの ECC メモリ
- PERC H710P ミニ、1 GB のバッテリバックアップ式キャッシュ搭載
- 300 GB 10k RPM SAS ドライブ 26 台
ディスクは次のボリュームに分割されました。
- システムボリューム
- OS とページファイルを含む
- 2 台のディスクを RAID 1 ミラーとして使用
- 合計容量 278 ギガバイト
- データベースボリューム
- SQL Server インスタンスとデータベースデータファイルを含む
- RAID 10 ミラーリング・ストライプとして 16 台のディスク
- 合計容量 2,231 ギガバイト
- ログボリューム
- データベースログファイルを含む
- RAID 10 ミラーリング・ストライプとして 8 台のディスク
- 合計容量 1,115 ギガバイト
- ソフトウェア:
- Windows Server 2012 R2 スタンダードエディション (テスト時点で最新の Windows 更新プログラムを含む) (2014 年 8 月)
- SQL サーバーエンタープライズ 2012 SP2 (累積更新プログラム付き) 1
- 設定変更
- SQL サーバーは、最大 61,440 MB を使用するように構成されました
- データベースコンテインメントはすべての SQL インスタンスで有効化されました
- SQL Server エージェントサービスが自動的に起動するように構成されました
- 可用性グループのセットアップ:
- すべてのサーバーは Windows フェールオーバークラスター内に配置されました
- クラスター内にAlwaysOn可用性グループが設定されました
- セカンダリレプリカは同期コミットに設定されているため、トランザクションが完了する前に両方のレプリカでトランザクションがコミットされる必要があります
- 可用性グループに対して読み取り専用レプリカルーティングが設定され、有効化されました
デリバリーコントローラーと HSD テストサーバー
デリバリーコントローラーとHSDテストサーバーは、HP BL460c G1ブレードを使用して同じ構成のハードウェアで実行されていました。 デリバリーコントローラーには2台のサーバーが使用され、43台のサーバーがシミュレートされたHSDワークロードを提供しました。
Note: これらのサーバーは比較的古いですが、セッションシミュレーションは主にHSDサーバーではなくDelivery Controllerに負荷をかけることに重点を置いているため、HSDサーバーの負荷は低くなります。
システム仕様:
- 2 個のクアッドコアインテル Xeon L5320 は 1.86 GHz で動作しますが、ハイパースレッドには対応していません
- 16 ギガバイトの ECC メモリ
- HP スマートアレイ E200I RAID カード (バッテリバックアップキャッシュなし)
- 36 GB または 72 GB SAS ハードディスク
ソフトウェア:
- Windows Server 2012 R2 スタンダードエディション (テスト時点で最新の Windows 更新プログラムを含む) (2014 年 8 月)
- シトリックスXenDesktop 7.6