XenAppおよびXenDesktopバージョン7.6から現行リリースまでのデータベースサイジングガイダンス
免責事項
このドキュメントには、Citrix以外の当事者が管理するWebサイトへのリンクが含まれています。Citrixは、これらのサードパーティのWebサイトのコンテンツまたは使用について責任を負わず、推奨も承認もいたしません。Citrixはこれらのリンクを便宜上提供しているにすぎず、いかなるリンクの掲載も、Citrixがリンク先のWebサイトを推奨することを意味するものではありません。使用するものがウイルスやその他の破壊的な性質の項目から解放されていることを確認するための予防措置を講じるのは、お客様の責任です。
概要
一般的なXenDesktop® 7の展開は、次の3つのデータベースで構成されます。
- サイト構成データベース XenDesktop展開の現在の構成と状態を保存します
- 監視データベース Director内に表示するための履歴データを保存します
- 構成ログデータベース XenDesktop展開に対して行われた構成変更を追跡します
デフォルトでは、構成ログデータベースと監視データベース（セカンダリデータベース）は、サイト構成データベースと同じサーバーに配置されます。当初、3つのデータベースはすべて同じ名前です。Citrixは、サイトを作成した後でセカンダリデータベースの場所を変更することをお勧めします。
一般的な展開では、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分に1回ハートビートを提供し、この更新によってデータベース上でトランザクションがトリガーされます。
障害の影響
サイトデータベースが停止すると、システムは管理および監視できなくなります。既存の接続は維持されます。XenDesktop 7.6では、接続リースにより新しい接続と再接続が可能になります。以前のバージョンでは、新しい接続と再接続はできません。
監視データベース
監視データベースには、サイトに関する履歴情報が含まれています。この情報は、Directorによって履歴情報を表示するために使用されます。
その使用法は次のように特徴付けられます。
- 最大サイズは、次のように構成された保持期間によって制御されます。
- Platinum以外の顧客の場合、デフォルトは7日間で、最大期間は7日間です。
- Platinum顧客の場合、デフォルトは90日間で、最大期間はありません。
- システムが構成された保持期間に達する必要があるため、ピークサイズに達するまでには時間がかかる場合があります。
- 監視サービスによる更新のバッチ処理の性質上、1秒あたりのトランザクションレベルは低くなります。1秒あたりのトランザクションが20を超えることはめったにありません。
- 監視サービスからの定期的な統合呼び出しによって発生するいくつかのバックグラウンドトランザクション。
- 構成された保持期間外のデータを削除するために、夜間処理が実行されます。
障害の影響
監視データベースが停止すると、サイトのデータ収集が妨げられ、Director内でデータが表示されなくなります。
構成ログデータベース
構成ログデータベースには、サイトへのすべての構成変更の履歴ログが含まれています。この情報は、レポートの生成やStudioでの表示に使用されます。
その使用法は次の特徴があります。
- 最大サイズは、構成アクティビティの量に依存するため、予測が困難です。
- Directorからのすべてのアクション（例えば、セッションのリセット）はこのデータベースにログ記録されるため、管理者がDirectorを使用するにつれて、緩やかな増加が見られる場合があります。
- 構成変更が行われていない場合、データベースで発生するトランザクションは最小限です。
- 更新は可能な限りバッチ処理されるため、更新中のトランザクションレートは低いです。
- データの手動削除。構成ログデータベース内のデータはいかなる保持ポリシーの対象でもなく、管理者によって手動で削除されない限り、削除されません。
障害の影響
構成ログデータベースの停止による影響は、サイト構成によって異なり、次のとおりです。
- 構成ログデータベースが利用できないときにサイトが変更を許可しない場合、XenDesktop展開を再構成することはできません。
- 構成ログデータベースが利用できないときにサイトが変更を許可する場合、XenDesktop展開に対して追跡されない構成変更が行われる可能性があります。
一時データベース
一時データベースは、SQL Serverによって提供されるシステム全体のデータベースです。これは、Read-Committed Snapshot Isolationのバージョンストアとして使用されます。XenDesktop 7は、このSQL Server機能を使用して、XenDesktopデータベースでのロック競合を軽減します。
バージョンストアのサイズは、アクティブなトランザクションの数に依存します。ただし、一般的には数MBを超えることはありません。
新しいデータを生成するトランザクションはTempDBスペースを必要とするため、TempDBのパフォーマンスはXenDesktopのブローカリングのパフォーマンスに影響を与えます。しかし、XenDesktopは短期間のトランザクションを持つ傾向があり、これによりバージョンストアのサイズを小さく保つことができます。
一時データベースは、クエリが大量の中間結果セットを生成する場合にも使用されます。
TempDB のサイズ設定と構成に関するガイダンスは、Microsoft の製品ドキュメントで確認できます。
主な競合領域は、使用するファイルの数に集中しています。SQL Server 2000 のような古いバージョンの SQL Server は、新しいバージョンよりも多くのファイルを必要とします。使用するファイルの数に関する詳細については、以下を参照してください。
読み取りコミット済みスナップショット分離
Citrix は、すべての XenDesktop 7 データベースで読み取りコミット済みスナップショット分離を使用することを推奨しています。詳細については、「XenDesktop で読み取りコミット済みスナップショットを有効にする方法」を参照してください。
データベースのサイズ設定
データベースのサイズは、稼働中に作成されるセッション数や接続数など、いくつかの主要な要因によって異なります。
セッションとは、一定期間実行され、切断および再接続が可能なデスクトップまたはアプリケーションのことです。
接続とは、ユーザーがセッションに接続するたびに発生するものです。切断すると接続は閉じられますが、セッションは閉じられません。ユーザーが再接続すると、既存のセッションへの新しい接続が作成されます。
サイトデータベース
サイトデータベースの最大サイズは、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でのサイズ増加は、コントローラー間のレプリケーションの一部として接続リースがデータベースに保存されるためです。
監視データベース
3つのデータベースの中で、監視データベースは時間とともに最大に成長すると予想されます。
そのサイズは、以下を含む多くの要因に依存します。
- ユーザー数
- セッション数
- 接続の合計数
- VDIまたはHSDワーカー
- 設定された保持期間
以下は、いくつかのデータポイントにおけるデータベースのサイズの見積もりです。このデータは、XenDesktopのスケールテスト時に見られたデータに基づいた見積もりです。これらの見積もりは現実的であると考えられています。
ただし、データベースを保守しているお客様は、推定値よりもデータベースが小さいと感じる場合があります。
HSDユーザーは、HSDサーバーあたり100ユーザーに基づいています。
保持期間の最大値
保持されるデータの最大量は、ライセンスによって次のように制御されます。
- 非プラチナのお客様は、最大1週間（7日間）のデータを保持できます。
- プラチナのお客様は無制限のデータを保持できます。デフォルトは3か月（90日間）です。
保持期間は、Set-MonitorConfiguration コマンドレットを使用して調整できます。
データが設定された保持期間よりも古くなると、データベースから削除されます。
XenDesktop 7.5 監視データベースのサイジング
ユーザーあたり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 |
週5日勤務で、ユーザーあたり2つの接続と1セッションの場合の見積もり
| ユーザー | タイプ | 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 |
なお、HSDはロードバランシング情報のログ記録により、時間とともに生成するデータ量が増加しますが、初期サイズはVDIデスクトップと同程度です。
XenDesktop 7.6 監視データベースのサイジング
7.5からの主な変更点は次のとおりです。
- ホットフィックス情報 以下のデータは、ワーカー（VDIまたはHSD）あたり3つのホットフィックスに基づいています。
- アプリケーション使用履歴 これは主にHSDシステムに関連します。
週5日稼働で、ユーザーあたり1接続および1セッションの場合の推定値
| ユーザー | タイプ | 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 |
週5日勤務で、ユーザーあたり2接続、1セッションの場合の見積もり
| ユーザー | タイプ | 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では、構成ログデータベースに大きな変更は行われませんでした。
10万HSDセッションのログオン中のデータベースアクティビティ
スケーラビリティテスト中、10万HSDセッションのログオンをシミュレートし、トランザクションログの増加は、以下の2つのログオンレートで測定されました。
- 1時間でログインする10万ユーザー
- 2時間でログインする10万ユーザー
これらのレートは、例となるデータポイントを提供するために選択されました。
環境は以下で構成されていました。
- 2つのデリバリーコントローラー
- 43 エイチエスディー VDA ワーカー
- 3つのSQL Server（データベースが構成され、1つのAlways On可用性グループ内に保持されている）
サーバー構成の詳細は、このドキュメントの最後に記載されています。
トランザクションログの増加
すべてのデータベースのトランザクションログの増加は、パフォーマンスモニターカウンター「SqlServer:Databases – Log File(s) Used Size (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時間で100,000 | 670 | 190 |
| 2時間で100,000 | 650 | 220 |
測定期間中、ログの増加は線形です。このデータは、ユーザーのログオンごとにトランザクションログが7 KB増加することを示唆しています。ユーザーのログオフごとにトランザクションログは2 KB増加します。
したがって、1日あたりの増加は、ユーザーのログオン/ログオフサイクルごとに9 KBです。
1秒あたりのトランザクション数
すべてのデータベースのトランザクションログの増加は、以下のパフォーマンスモニターカウンターを使用して監視されました。
- SqlServer:Databases – 1秒あたりのトランザクション数
- SqlServer:Databases – 1秒あたりの書き込みトランザクション数
サイトデータベース
システムがアイドル状態の場合、1秒あたり5つのトランザクションがあり、そのうち1秒あたり1つの書き込みトランザクションがVDAとBrokerのハートビートを維持します。
注: これらの数値は、与えられた期間から得られた推定値です。正確な負荷は、1秒あたりの同時起動数によって異なります。
| テスト | 1秒あたりのログオントランザクション数 | ログオン書き込みトランザクション/秒 | ログオフ トランザクション/秒 | ログオフ書き込みトランザクション/秒 |
|---|---|---|---|---|
| 1時間あたり100,000 | 870 | 310 | 250 | 100 |
| 2時間あたり100,000 | 475 | 170 | 140 | 60 |
監視データベース
システムがアイドル状態の場合、統合ストアドプロシージャは1分に1回実行され、トランザクションを生成します。ただし、トランザクションのレベルは小さいです。一般的に、各統合ストアドプロシージャには2～3個のトランザクションと1個の書き込みトランザクションがあり、3個の統合ストアドプロシージャが実行されます。アクティブな期間中、より多くの作業が実行されるにつれてオーバーヘッドが増加します。
注: これらの数値は、指定された期間から取得された推定値です。
| テスト | 1秒あたりのログオントランザクション数 | 1秒あたりのログオン書き込みトランザクション数 | 1秒あたりのログオフ トランザクション数 | 1秒あたりのログオフ書き込みトランザクション数 |
|---|---|---|---|---|
| 1時間で100,000 | 4 | 2 | 4 | 2 |
| 2時間で100,000 | 4 | 2 | 3.5 | 2 |
CPU使用率
このテストで使用されたすべてのSQLサーバーは、ハイパースレッディングが有効なデュアルヘキサコアサーバーでした。正確なハードウェア仕様は、このドキュメントの最後に記載されています。
実行されている負荷に対して、サーバーは過剰なサイズであることがわかっていました。これにより、ハードウェアに課せられる制限と最大値を特定できました。SQL CPU負荷は、デュアルヘキサコアシステムではなく、シングルクアッドコアのSQL Serverで実際に処理できたと予想されます。
テスト中、システムCPUはパフォーマンスモニターカウンター Processor – % Processor Time – _Total を使用して監視されました。
プライマリレプリカ
アイドル状態のCPUは、利用可能なCPUの0～2%で動作していました。統合ストアドプロシージャは、システムCPUの8～10%に達するスパイクを約1秒間、毎分発生させました。これは、処理されるデータ量に基づいてスケーリングされると予想されます。
1時間で100,000ユーザーがログオンする際、CPUは7%に跳ね上がり、環境内にセッションとユーザーが増えるにつれて線形に11%まで増加しました。統合ストアドプロシージャのスパイクが合計CPUに7%追加され、スパイクがCPUの18%に達したことに注意してください。
ログオフ中、CPUは3.5%で動作し、統合ストアドプロシージャのために7%の追加CPUが使用されました。全体として、これはログオンおよびログオフレートを維持するために、デュアルヘキサコアの<20%が必要であったことを示唆しています。
注: Windows Server 2012スケジューラは、必要に応じてのみハイパースレッドを使用するように偏っています。つまり、システムが50%の負荷に達するまでは、可能な限りコアごとに1つのスレッドのみを実行するため、24のハイパースレッドでの20%の負荷は4.8コアで実行されています。
このワークロードを考慮すると、これは重いストレステストであり、XenDesktopの展開にはシングルクアッドコアのSQLサーバーで十分であると考えられます。
セカンダリレプリカ
セカンダリレプリカは、ログオン中に2%のCPU、ログオフ中に1.5%のCPUを構成することがわかりました。これは、ほとんどの場合、レプリカがプライマリからディスクにデータを保存しており、同期レプリカのみがトランザクションに関与するため、予想されることです。これは、プライマリレプリカがセカンダリレプリカがそれを認識するまでトランザクションをコミットしないためです。
プライマリレプリカに一致するHAハードウェアの推奨事項に基づくと、この負荷は同様の仕様のサーバーで非常に簡単に処理されるでしょう。
一時データベースの使用状況
TempDB は、バージョンストア、大規模なクエリセット用の領域、その他のテンポラリテーブルの使用など、多くの目的に使用されます。
TempDB のサイジング
このSQL構成では、TempDBはそれぞれ固定5GBサイズの8つのデータベースファイルを持つように構成されていました。これにより、TempDBの同時使用が向上するだけでなく、十分な領域が提供され、自動拡張イベントがトリガーされることもありません。取得されたデータに基づくと、この展開では過剰なサイズでした。ただし、十分なディスク容量は利用可能でした。
また、TempDBデータベースファイルの数は、利用可能なCPU数の4分の1から半分までという一般的なガイドラインの範囲内であり、実際の競合があることが分かっていない限り8を超えないようにしています。
SQL Serverは複数のログファイルから恩恵を受けないため、TempDBログファイルは1つしか使用されないことに注意してください。
バージョンストア
TempDBには、XenDesktopデータベースで使用されるRead Committed Snapshot Isolationに関連する行バージョンのバージョンストアが含まれています。
使用状況は、以下のパフォーマンスカウンターで測定できます。
- エスキューエルサーバー:トランザクション – バージョンストアサイズ (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、アイドル期間中に400KB/sに達しました。
ディスクI/O
ログオンテスト中、ディスクI/Oは以下のパフォーマンスカウンターで測定されました。
- PhysicalDisk – ディスク読み取りバイト/秒
- PhysicalDisk – ディスク書き込みバイト/秒
- PhysicalDisk – ディスク読み取り/秒
- PhysicalDisk – ディスク書き込み/秒
SQLサーバーがすべてのデータをメモリに保持できたため、読み取りI/Oは最小限であることが判明し、システム上での読み取りアクティビティはほとんど発生しませんでした。
データベースとストレージシステムのレイアウトにより、ボリュームは分割され、1つのボリュームにすべてのデータファイルが、もう1つのボリュームにすべてのトランザクションログファイルが格納されました。
このデータは、表にまとめるのが難しいパターンを示しています。一般的に、トランザクションログの書き込みバイト/秒は、1時間テストで800 KB/s、2時間テストで400 KB/sでした。統合ストアドプロシージャが実行される1分に1回、トランザクションログは30 MB/sにスパイクを示しました。
統合ストアドプロシージャの分析によると、統計情報がクエリプランを最適でないものにし、一時テーブルがTempDBにスピルすることがあります。これにより、TempDBのトランザクションログへの書き込みがトリガーされます。
このデータ転送は、1時間テストで300書き込みIOPS (Input/Output Operations Per Second) の定常状態、2時間テストで200書き込みIOPSに相当します。統合ストアドプロシージャのスパイクは、実行中にさらに2～300書き込みIOPSを追加します。大規模な環境では、統合ストアドプロシージャは1秒未満で実行されることに注意してください。
各データベースがチェックポイントされると、データはインメモリテーブルからデータボリューム上のデータファイルに同期されます。
SQLチェックポイントの詳細については、http://technet.microsoft.com/enus/を参照してください。
これらのチェックポイントは非常に短いアクティビティ期間であり、通常1秒未満です。
ログオン中、チェックポイントは6～7 MB/sと500書き込みIOPSを消費しました。ログオフ中、チェックポイントは7 MB/sを消費し、200～700 IOPSの範囲でした。サイトデータベースと監視データベースでチェックポイントするデータ量が異なるため、数値は異なります。
データベースのメンテナンス
大規模なデプロイメントにおけるデータベースのメンテナンスは重要です。データベースが適切にメンテナンスされていない場合、例えば、トランザクションログが自動拡張に設定されてディスクがいっぱいになったり、トランザクションログが固定サイズでいっぱいになったりすると、データベーススペースの不足によりデータベースの停止が発生する可能性があります。
トランザクションログのメンテナンス
SQL ServerのAlways On可用性グループやデータベースミラーリングなどの高可用性機能を使用する場合、XenDesktopデータベースは完全トランザクションログモードで実行されます。
完全トランザクションログモードで実行すると、データベースまたはトランザクションログのバックアップが取得されるまで、トランザクションログは増大し続けます。
デフォルトではSQL Serverがログファイルを自動拡張するように構成しているため、トランザクションログファイルが監視されていない場合、問題が発生する可能性があります。これにより、2つの問題が生じます。
- トランザクションログファイルが大量のディスクスペースを消費する可能性があります。
- トランザクションログが拡張するたびに、ログスペースがゼロ化されるまで、すべてのトランザクションが停止します。
Citrixは、ログファイルを定期的にバックアップすることを推奨しています。これは、スケジュールされたジョブまたはメンテナンスプランで実行できます。
あるいは、SQL Server Agentを使用して、ログの使用サイズがしきい値を超えたときに監視し、バックアップジョブを実行します。
スケールテストでは、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パフォーマンスカウンターは次のとおりです。
SQLServer:Databases - Percent Log Used - CitrixXenDesktopSiteDB
これを3つのデータベースそれぞれについて繰り返します。
ログファイルのバックアップは、稼働中のXenDesktop環境にほとんど影響を与えないことがわかりました。ブローカリング時間はわずかに増加しますが、これは重要であるとは考えていません。
ジョブの構成の詳細については、以下を参照してください: https://docs.microsoft.com/ja-jp/sql/ssms/agent/create-a-job?view=sql-server-ver15
アラートの設定の詳細については、以下を参照してください: (https://docs.microsoft.com/ja-jp/sql/ssms/agent/alerts?view=sql-server-ver15)
インデックスのメンテナンス
データベースにデータが入力されるにつれて、一部のインデックスの占有率が低下し始めます。つまり、各SQLページに保存されるレコードが少なくなります。SQLページは8KBです。これにより、データベースはメモリとディスクの両方でストレージの必要性を増大させます。インデックスをメンテナンスすることで、ページの占有率を上げることができ、データベースのメモリ要件を削減できます。
Citrixは、インデックスを維持するために、顧客が夜間および週次で実行するメンテナンスプランを設定することを推奨しています。メンテナンスプランは、週中は夜間にインデックスを再編成し、週末にインデックスを再構築するだけでよい場合があります。
この推奨事項により、特に大規模な監視データベースの場合、日常業務中に大規模なインデックスを再構築することによるパフォーマンスへの影響を回避できます。
Microsoftは、インデックスの断片化が30%を超える場合は再構築し、30%未満の場合は再編成することを推奨しています。詳細については、Microsoftのドキュメントを参照してください。
インデックスを再編成した後、統計も更新する必要があります。これはデータベースが成長するにつれて特に重要です。そうしないと、一部の統計が不十分になり、SQLが最適ではないSQLクエリプランを生成する可能性があります。
節約されたスペースに関して、以下のMicrosoftスクリプトを1.2GBの監視データベースに対して実行しました。これにより、ページの占有率が向上し、300MBのスペースが解放されました。
サードパーティスクリプト
マイクロソフト
Microsoftは、WSUS SQLデータベースのインデックスを更新するために、以下のスクリプトを使用することを推奨しています。
「USE SUSDB」を変更することで、このスクリプトはXenDesktopデータベースに対しても実行できます。このスクリプトは、断片化が30%を超えるインデックスを再構築し、30%未満のインデックスを再編成するというMicrosoftのベストプラクティスに従っています。その後、データベースの統計を更新します。
オーラ・ハレンゲン
より高度なスクリプトは以下からも入手できます。
これらのスクリプトは、SQL Serverコミュニティで高く評価されています。特に、以下から入手できるインデックススクリプトは、
http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
これらのスクリプトは、インデックスを再編成または再構築するレベルをより細かく制御するために使用できます。
テストサーバー構成
SQLサーバー構成
SQL可用性グループは、同一仕様のDell R720XDサーバー3台で構成されていました。
システム仕様:
- ハイパースレッディングが有効な2.30 GHzで動作する2つのヘキサコアIntel Xeon CPU E5-2630
- 64ギガバイト ECC メモリ
- 1 GBバッテリーバックアップキャッシュ付きPERC H710P Mini
- 26台の300 GB 10k RPM SASドライブ
ディスクは以下のボリュームに分割されました。
- システムボリューム
- OSとページファイルを含む
- RAID 1ミラーとして2台のディスク
- 総容量 278 GB
- データベースボリューム
- SQL Serverインスタンスとデータベースデータファイルを含む
- RAID 10ミラー化ストライプとして16台のディスク
- 総容量 2,231 GB
- ログボリューム
- データベースログファイルを含む
- RAID 10ミラー化ストライプとして8台のディスク
- 総容量 1,115 GB
- ソフトウェア:
- Windows Server 2012 R2 標準エディション、テスト実施時（2014年8月）の最新のWindows更新プログラム適用済み
- SQL Server エンタープライズ 2012 SP2 に累積更新プログラム1を適用
- 設定の変更点
- SQL Server は最大 61,440 MB を使用するように構成されました。
- すべての SQL インスタンスでデータベースの包含が有効になりました。
- SQL Server Agent サービスは自動的に開始するように構成されました。
- 可用性グループのセットアップ:
- すべてのサーバーは Windows フェールオーバー クラスター内に配置されました。
- クラスター内に Always On 可用性グループが構成されました。
- セカンダリ レプリカは同期コミットとして構成され、トランザクションが完了する前に両方のレプリカでトランザクションがコミットされる必要がありました。
- 可用性グループに対して、読み取り専用レプリカ ルーティングが構成され、有効になりました。
デリバリーコントローラー™ および HSD テストサーバー
Delivery Controller および HSD テスト サーバーは、HP BL460c G1 ブレードを使用し、同じハードウェア構成で稼働していました。Delivery Controller には 2 台のサーバーが使用され、43 台のサーバーがシミュレートされた HSD ワークロードを提供しました。
注: これらのサーバーは比較的新しくありませんが、セッション シミュレーションは HSD サーバーではなく Delivery Controller に負荷をかけることに主に焦点を当てているため、HSD サーバーのワークロードは低いです。
システム仕様:
- 1.86 GHz で動作する 2 基のクアッドコア Intel Xeon L5320、ハイパースレッド非対応
- 16 ギガバイト ECC メモリ
- HP Smart Array E200I RAID カード (バッテリーバックアップキャッシュなし)
- 36 GB または 72 GB の SAS ハードディスク
ソフトウェア:
- Windows Server 2012 R2 Standard エディション、テスト時（2014年8月）の最新Windows更新プログラム適用済み
- シトリックス ゼノンデスクトップ 7.6