XenAppおよびXenDesktop ktopバージョン7.6のデータベースサイズ設定ガイダンス
免責事項
このドキュメントには、Citrix 以外の関係者が管理するWebサイトへのリンクが含まれています。Citrix は、これらの第三者のウェブサイトのコンテンツまたは使用について責任を負わず、いかなる責任も負いません。Citrix は、これらのリンクをお客様に提供することを目的としてのみ提供しており、リンクを含めることは、Citrix がリンク先のウェブサイトを推奨することを意味するものではありません。お客様の責任の下で、お客様が使用するWebサイトにコンピューターウィルスやそのほかの破壊的な問題がないことを確認してください。
概要
一般的なXenDesktop 7の展開環境は、次の3つのデータベースで構成されます。
- サイト構成データベース：
XenDesktop展開の現在の構成と状態を保存します - 監視データベース
Directorに表示する履歴データを格納 - 構成ログデータベース：
XenDesktop展開に加えられた構成変更を追跡します
既定では、構成ログと監視データベース (セカンダリデータベース) は、サイト構成データベースと同じサーバーにあります。初期状態では、これらのデータベースに同じ名前が設定されます。サイトを作成した後で、セカンダリデータベースの場所を変更することをお勧めします。
一般的な展開では、SQL Server によって提供される一時データベース TempDB も使用します。
各データベースは、異なる目的を果たし、異なる速度で成長します。
このドキュメントでは、各データベースに関する情報と、XenDesktop 7をサポートするようにデータベースのサイズを設定する際に考慮すべき主な考慮事項について説明します。
注： 提供されるすべての数字は推定値です。展開間のバリエーションが予想されます。
このドキュメントでは、ホストされた共有デスクトップ (HSD) と仮想デスクトップインフラストラクチャ (VDI) のサイズ設定の違いについても説明します。混在環境では、2 つのデスクトップタイプの推定値を組み合わせて、データベース全体のサイズの見積もりを生成する必要があります。
ドキュメントXenDesktop 点
このドキュメントは、7.6 XenDesktop をカバーするように拡張されました。これは、7.6 で追加された機能のサイズ変更に関する更新を可能にするためです。データベースのサイジングに影響する 3 つの新機能は次のとおりです。
- 接続リース — 圧縮されたリースファイルは、サイトデータベースに格納されます。
- アプリケーション使用率の監視 — 環境内で使用されるすべてのアプリケーションの詳細が監視データベースに格納されます。
- 修正プログラムインベントリの監視 — 環境内のコントローラー、VDA、およびVDAイメージに適用されるCitrix 修正プログラムの詳細
テーブルサイズに関する情報が以下で更新されました。7.6 から 7.5 では、1 秒あたりのトランザクションとトランザクションログの増加が類似していることがわかりました。そのため、これらのセクションは更新されませんでした。
概要レベルの考慮事項
サイトデータベース
サイトデータベースには、システムを実行するための構成情報が含まれています。
その使用法は、次の特徴があります。
- ユーザーのログオン時に追跡するセッションおよび接続情報が生成されると、最大サイズに達します。
- アクティブなセッションがなく、VDAがすべてシャットダウンされ、登録解除されると、最小サイズに達します。
- データベースには永続情報がほとんど格納されていないため、48時間後にピークサイズに達します。 これは、サイトデータベース内で48時間維持されている接続のログが小さいためです。
- データベースのベースラインサイズは、サイトの構成情報が大きくなるにつれて大きくなります。 つまり、より多くのワーカーとユーザーがより多くのデータベース領域を消費します。
- ログオン中に1秒あたりのトランザクション数が高くなります。各ユーザーのログオンでは、複数の個別のトランザクションが実行され、同時起動レートに基づいて拡張されるためです。
- VDAハートビートトランザクションの低レベルのバックグラウンドノイズ。各VDAは5分に1回ハートビートを提供し、この更新によってデータベース上のトランザクションがトリガーされます。
障害の影響
サイトデータベースが停止すると、システムの管理と監視ができなくなります。既存の接続は維持されます。XenDesktop 7.6の接続リースでは、新しい接続と再接続を行うことができます。以前のバージョンでは、新しい接続と再接続はできません。
監視データベース
監視データベースには、サイトに関する履歴情報が含まれています。この情報は、Directorが履歴情報を表示するために使用されます。
その使用法は、次の特徴があります。
- 最大サイズは、次のように構成された保存期間によって制御されます。
- プラチナ以外のお客様の場合、デフォルトは7日間で、最大期間は7日間です。
- プラチナ会員の場合、デフォルトは90日間で、最大期間はありません。
- システムが構成された保持期間に達する必要があるため、ピークサイズに達するまでに時間がかかる場合があります。
- 監視サービスによる更新のバッチ処理の特性により、1 秒あたりのトランザクションのレベルが低くなります。1 秒あたりのトランザクションが 20 回のトランザクション/秒のマークを通過することはまれです。
- 監視サービスからの定期的な連結呼び出しが原因で発生するバックグラウンドトランザクション。
- 一晩処理が実行され、構成された保存期間外のデータが削除されます。
障害の影響
監視データベースが停止すると、サイトのデータが収集されなくなります。つまり、Director内ではデータが表示されません。
構成ログデータベース
構成ログデータベースには、サイトに対するすべての構成変更の履歴ログが含まれます。この情報は、レポートの生成やStudioでの表示に使用されます。
その使用法は、次の特徴があります。
- 最大サイズは、構成アクティビティの量に依存するため、予測するのが難しいです。
- Directorからのすべてのアクション（セッションのリセットなど）はこのデータベースにログに記録されるため、管理者がDirectorを使用するにつれ、増加が遅くなる可能性があります。
- 構成の変更が行われていない場合に、データベースで発生する最小限のトランザクション。
- 更新は可能な限りバッチ処理されるため、更新中のトランザクションレートは低くなります。
- データを手動で削除する。構成ログデータベース内のデータは、保持ポリシーの対象ではなく、管理者が手動で行う場合を除き、削除されません。
障害の影響
構成ログデータベースが停止した場合の影響は、次のように、サイト構成によって異なります。
- 構成ログデータベースが使用できないときにサイトが変更を許可しない場合、XenDesktop 展開を再構成することはできません。
- 構成ログデータベースが使用できないときにサイトで変更が許可されている場合は、追跡されていない構成変更がXenDesktop 展開に加えられることがあります。
一時データベース
テンポラリデータベースは、SQL Server によって提供されるシステム全体のデータベースです。これは、読み取りコミットされたスナップショット分離用のバージョンストアとして使用されます。XenDesktop 7では、このSQL Server機能を使用して、XenDesktop データベース内のロック競合を軽減します。
バージョンストアのサイズは、アクティブなトランザクションの数によって異なります。しかし、一般的に、それは数MBを超えていません。
TempDBのパフォーマンスは、XenDesktop ktop仲介のパフォーマンスに影響します。これは、新しいデータを生成するトランザクションにはTempDB領域が必要となるためです。ただし、XenDesktop ではトランザクションが短くなる傾向があり、バージョンストアのサイズを小さく保つのに役立ちます。
テンポラリデータベースは、クエリが大きな中間結果セットを生成する場合にも使用されます。
TempDB のサイズ設定と構成に関するガイダンスは、Microsoft の製品ドキュメントに記載されています。
競合の主な領域は、使用するファイル数の中心です。SQL Server 2000 などの古いバージョンの SQL Server では、新しいバージョンよりも多くのファイルが必要です。使用するファイル数について詳しくは、以下を参照してください。
読み取りコミットされたスナップショットの分離
すべてのXenDesktop 7データベースでは、Read-Committed Snapshot Isolationを使用することをお勧めします。詳しくは、「 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 のサイズが大きくなるのは、Controller間のレプリケーションの一部として接続リースがデータベースに格納されているためです。
監視データベース
3 つのデータベースのうち、監視データベースは時間の経過とともに最大に成長すると予想されます。
そのサイズは、以下を含む多くの要因に依存します。
- ユーザー数
- セッションの数
- 接続数
- VDIワーカーまたはHSDワーカー
- 保存期間の構成
以下は、いくつかのデータポイントでのデータベースのサイズの見積りです。このデータは、XenDesktop のスケールテスト時に表示されるデータに基づく推定値です。推定値は現実的であると考えられている。
しかし、データベースを維持しているお客様は、自分のデータベースが推定値よりも小さいことがわかります。
HSD ユーザーは、HSD サーバーあたり 100 ユーザーに基づいています。
最大保存期間
保持されるデータの最大量は、ライセンスによって次のように制御されます。
- プラチナ以外のお客様は、最大1週間（7日）のデータを保持できます。
- プラチナのお客様は、無制限のデータを保持できます。デフォルトは 3 か月 (90 日) です。
保持期間は、 Set-MonitorConfiguration コマンドレットを使用して調整できます。
構成された保存期間より古いデータは、データベースから削除されます。
XenDesktop 7.5 監視データベースのサイジング
稼働週5日で、ユーザー1人あたり1回の接続と1回のセッションで見積もり
| ユーザー | 種類 | 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 からの主な変更点は次のとおりです。
- Hotfix情報
以下のデータは、ワーカー (VDI または HSD) ごとに 3 つの修正プログラムに基づいています - アプリケーション使用履歴
これは主にHSDシステムに関係します。
稼働週5日で、ユーザー1人あたり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 では、構成ログデータベースに対する大幅な変更は行われませんでした。
100 k の HSD セッションのログオン時のデータベースアクティビティ
スケーラビリティテストで、100k の HSD セッションログオンをシミュレートする際、トランザクションログの増加は、次の 2 つのログオンレートで測定されました。
- 100,000人のユーザーが1時間以上ログインしています
- 2時間以上ログインしているユーザー数100万人
これらのレートは、サンプルデータポイントを提供するために選択されました。
環境は、次のもので構成されています。
- 2台のDelivery Controller
- 43人のHSDのVDAワーカー
- データベースで構成された 3 つの SQL Server が 1 つの常時可用性グループ内に保持
サーバ設定の詳細については、このドキュメントの最後を参照してください。
トランザクションログの増加
すべてのデータベースのトランザクションログの増加は、パフォーマンスモニターカウンター SqlServer: データベース — ログファイル使用サイズ (KB) を使用して監視されました。
サイトデータベース
システムがアイドル状態になると、トランザクションログは 1 時間に 3.5 MB ずつ増加します。これは、VDAとブローカーサービスのハートビートの組み合わせです。
| テスト | ログオンの総増加量 (MB) | ログオフの総増加量 (MB) |
|---|---|---|
| 1時間以上100万回 | 1,900 | 1,150 |
| 2時間以上100万回 | 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 秒あたりのトランザクション数
すべてのデータベースのトランザクションログの増加は、次のパフォーマンスモニターカウンターを使用して監視されました。
- SQL サーバー:データベース — トランザクション/秒
- SQL Server: データベース — 書き込みトランザクション/秒
サイトデータベース
システムがアイドル状態の場合、5トランザクション/秒で、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時間以上で100,000 | 4 | 2 | 4 | 2 |
| 2時間以上で100,000 | 4 | 2 | 3.5 | 2 |
CPU使用率
このテストに使用されたすべてのSQLサーバーは、ハイパースレッディングが有効になっているデュアルヘキサコアサーバーでした。ハードウェアの正確な仕様については、このドキュメントの最後に記載されています。
サーバーは、実行中の負荷に対してサイズが大きすぎることがわかっていました。これにより、ハードウェアに適用される制限と最大値を特定することができました。SQL CPU の負荷は、デュアル 16 進コアシステムではなく、単一のクアッドコアを持つ SQL Server によって実際に処理されることが予想されます。
テスト中に、パフォーマンスモニタカウンタ Processor – % Processor Time – _Totalを使用してシステムCPUを監視しました。
プライマリレプリカ
アイドル状態のCPUは、使用可能なCPUの0〜2％で実行されました。統合ストアドプロシージャにより、システム CPU の 1 ～ 8 ～ 10% の間、毎分スパイクが発生しました。これは、処理されるデータの量に基づいて拡張されることが予想されます。
1時間で100,000人のユーザーのログオン中、CPUは7％に上昇し、環境内にセッションとユーザーが増えるにつれて、11％に直線的に増加しました。統合ストアドプロシージャのスパイクは、CPU の 18% に達するスパイクを引き起こす、合計 CPU に 7% を追加することに注意してください。
ログオフ中 CPU は 3.5% で稼働し、統合ストアドプロシージャの 7% 余分な CPU を使用しました。全体的に、ログオンおよびログオフ率を維持するために、デュアルヘキサコアの20％未満が必要であることを示唆しています。
注: Windows Server 2012 スケジューラは、必要な場合にのみハイパースレッドを使用するバイアスです。つまり、システムが 50% の負荷に達するまで、可能な場合はコアごとに 1 つのスレッドしか実行されないため、24 のハイパースレッドで 20% の負荷が 4.8 コアで実行されます。
ワークロードを考慮すると、これは負荷の高いテストであり、XenDesktop の展開には単一のクアッドコアSQLサーバーが適切であると考えられます。
セカンダリレプリカ
セカンダリレプリカは、ログオン時に 2% の CPU、ログオフ時に 1.5% を構成していることが判明しました。これは、ほとんどの場合、レプリカがプライマリのデータをディスクに格納し、同期レプリカのみがトランザクションに関与するため、プリンシパルレプリカはセカンダリが確認するまでトランザクションをコミットしないためです。
プライマリレプリカに一致する HA ハードウェアの推奨事項に基づいて、この負荷は、同様に指定されたサーバーによって非常に簡単に処理されます。
一時データベースの使用
TempDB は、バージョンストア、大規模なクエリセット用の領域、その他のテンポラリテーブルの使用など、多くの目的で使用されます。
一時データベースのサイズ設定
この SQL 構成では、TempDB は 8 つのデータベースファイルで構成され、それぞれのサイズが 5 GB に固定されています。これにより、TempDB の同時使用が向上しますが、十分なスペースが提供され、自動拡張イベントは発生しません。キャプチャされたデータに基づいて、この展開ではサイズが大きすぎました。しかし、十分なディスク容量がありました。
また、TempDB データベースファイルの数が、利用可能な CPUS 数の1/2の間にあるが、実際の競合が存在することを知らずに 8 を超えないという一般的なガイダンスにも対応しています。
SQL Server では複数のログファイルの利点がないため、TempDB ログファイルは 1 つだけ使用されます。
バージョンストア
TempDBには、XenDesktop データベースで使用されるコミットされたスナップショットの読み取り分離に関連する行バージョンのバージョンストアが含まれています。
使用状況は、次のパフォーマンスカウンターで測定できます。
- SQL Server: トランザクション — バージョンストアサイズ (KB)
- SQLServer: トランザクション — バージョンクリーンアップレート (KB/秒)
- SQLServer: トランザクション — バージョン生成レート (KB/秒)
1 時間で 100,000 ログオン中に、バージョンストアのサイズは 10 MB から 30 MB の範囲にとどまりました。バージョンが作成され、クリーンアップされた際のこぎり歯の効果があります。ログオフ時の範囲は 10 MB から 21 MB でした。アイドル状態のとき、バージョンストアのサイズは 1 MB から 4 MB の範囲でした。
バージョン生成率は、ログオン時の 250 ～ 500 KB の範囲でした。ログオフ時は 150 ～ 400 KB/秒、アイドル時は 0 ～ 250 KB/秒でした。
バージョンクリーンアップは、1 分に 1 回実行され、ログオン時に 2,500 KB/s、ログオフ時に 1,750 KB/s、アイドル期間中に 400 KB/s に達しました。
ディスク I/O
ログオンテスト中に、ディスク I/O は、次のパフォーマンスカウンターで測定されました。
- 物理ディスク — ディスク読み取りバイト/秒
- 物理ディスク：ディスク書き込みバイト/秒
- 物理ディスク — ディスク読み取り/秒
- 物理ディスク：ディスク書き込み/秒
SQL サーバーはすべてのデータをメモリに保持でき、システムでの読み取りアクティビティはほとんど発生していないため、読み取りI/Oは最小限であることが判明しました。
データベースとストレージシステムのレイアウトにより、ボリュームは分割され、1 つのボリュームはすべてのデータファイルを保持し、もう 1 つのボリュームはすべてのトランザクションログファイルを保持していました。
データには、テーブルに配置するのが難しいパターンが表示されます。一般に、トランザクションログの書き込みバイト/秒は、1時間のテストでは800 KB/秒、2時間のテストでは400 KB/秒でした。1 分に 1 回、統合ストアドプロシージャを実行すると、トランザクションログに 30 MB/秒のスパイクが表示されました。
統合ストアドプロシージャの分析は、統計がクエリプランを最適ではないし、一時テーブルが TempDB に流出することを示しています。これにより、TempDB のトランザクションログへの書き込みがトリガーされます。
このデータ転送は、1 時間のテストでは 300 回の書き込み入出力操作/秒 (IOPS)、2 時間のテストでは 200 回の書き込み IOPS という定常状態になります。統合ストアドプロシージャの急増により、実行中にさらに 2～300 の書き込み IOPS が追加されます。大規模な環境では、統合ストアドプロシージャが 1 秒未満で実行されることに注意してください。
各データベースがチェックポイントされると、データはメモリ内のテーブルからデータボリューム上のデータファイルに同期されます。
SQL チェックポイントの詳細については、 http://technet.microsoft.com/enus/を参照してください。
これらのチェックポイントは、アクティビティが非常に短く、通常は1秒未満です。
ログオン中、チェックポイントは6～7 MB/秒と500回の書き込み IOPSを消費しました。ログオフの間、チェックポイントは7 MB/秒（200～700 IOPS）を消費しました。サイトデータベースと監視データベースでは、チェックポイントまでのデータ量が異なるため、数値は異なります。
データベースのメンテナンス
大規模な展開でのデータベースのメンテナンスは重要です。データベースが適切に管理されていない場合、データベース領域が不足しているためにデータベースが停止することがあります。たとえば、トランザクションログが自動拡張に設定されてディスクがいっぱいになったり、トランザクションログが固定サイズでいっぱいになったりします。
トランザクションログの保守
常時可用性グループやデータベースミラーリングなどの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パフォーマンスカウンタは次のとおりです。
SQLServer: データベース-使用率のログ-CitrixXenDesktopサイトデータベース
3 つのデータベースそれぞれについて、この操作を繰り返します。
ログファイルのバックアップは、実行中のXenDesktop ktop環境への影響を最小限に抑えることが判明しました。仲介時間はごくわずかですが、重要なものではありません。
ジョブの構成のついて詳しくは、次を参照してください。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% 未満の場合は再編成することをお勧めしています。詳細については、 Microsoft のドキュメントを参照してください。
インデックスを再編成した後、統計も更新する必要があります。これは、データベースが大きくなるにつれて特に重要です。そうしないと、統計が低くなり、SQL が最適ではない SQL クエリプランを生成する可能性があります。
省スペースの観点から、次の Microsoft スクリプトは 1.2 GB の監視データベースに対して実行されました。これは、ページの充填を改善し、300 MBのスペースを解放しました。
サードパーティ製スクリプト
Microsoft
Microsoftでは、次のスクリプトを使用して、WSUS SQLデータベースのインデックスを更新することをお勧めしています。
http://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61
「USE SUSDB」を変更することで、このスクリプトをXenDesktopデータベースに対して実行することもできます。このスクリプトは、断片化された 30% を超えるインデックスを再構築し、30% 未満のインデックスを再編成するというMicrosoftのベストプラクティスに従います。次に、データベースの統計情報を更新します。
オーラ・ハレングレン
より高度なスクリプトは、次の場所から入手できます。
これらのスクリプトは、SQL Server コミュニティでよく評価されています。具体的には、次のインデックススクリプトを使用できます。
http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
これらのスクリプトは、インデックスを再編成または再構築するためのレベルをより細かく制御するために使用できます。
サーバ構成のテスト
SQL サーバーの構成
SQL 可用性グループは、同じように指定された 3 台のDell R720XD サーバーで構成されています。
システム仕様:
- ハイパースレッディングを有効にした2.30GHzで動作する2ヘキサコアのインテルXeon CPU E5-2630
- 64 GB ECC RAM
- PERC H710Pミニ（1 GBのバッテリバックアップ式キャッシュ搭載）
- 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ギガバイト
- ソフトウェア：
- Windows Server 2012 R2 のStandardエディション、テスト時の最新のWindows更新プログラムを含む (2014 年 8 月)
- 累積更新プログラム1を適用したSQL Server Enterprise 2012 SP2
- 設定の変更
- 最大 61,440 MB を使用するように SQL Server が構成されました。
- データベース包含がすべての SQL インスタンスで有効になっている
- SQL Server エージェントサービスが自動的に開始するように構成されました。
- 可用性グループの設定:
- すべてのサーバーが Windows フェイルオーバークラスター内に配置されている
- 常時可用性グループがクラスター内で構成されました。
- セカンダリレプリカは同期コミットするように構成されており、トランザクションが完了する前に両方のレプリカでトランザクションがコミットされている必要があります。
- 可用性グループに対して読み取り専用レプリカルーティングが構成され、有効になっています。
Delivery Controller とHSDテストサーバ
Delivery Controller とHSDテストサーバーは、HP BL460c G1ブレードを使用して、同じ構成のハードウェアで実行されていました。デリバリーコントローラには2台のサーバーが使用され、43台のサーバーでHSDワークロードがシミュレートされました。
注： これらのサーバーは比較的古いですが、セッションシミュレーションは主にHSDサーバーではなくデリバリーコントローラに負荷をかけることに重点を置いているため、HSDサーバーのワークロードは低くなります。
システム仕様:
- 1.86 GHz で動作する 2 つのクアッドコア Intel Xeon L5320、ハイパースレッド対応ではない
- 16 GB ECC RAM
- HPスマートアレイE200IRAIDカード（バッテリバックアップキャッシュなし）
- 36 GBまたは72 GBのSASハードディスク
ソフトウェア：
- Windows Server 2012 R2 のStandardエディション、テスト時の最新のWindows更新プログラムを含む (2014 年 8 月)
- Citrix XenDesktop 7.6