Microsoft HPC Pack のデータベース容量の計画とチューニング

Microsoft HPC Pack の Windows HPC クラスター管理機能は、管理、ジョブのスケジュール設定、診断、レポート、監視の機能をサポートするために、いくつかの Microsoft SQL Server データベースに依存しています。 ヘッド ノードを作成するために HPC Pack をサーバーにインストールすると、既定のセットアップでは Microsoft SQL Server の Express エディションがインストールされ (他のエディションの SQL Server が検出されない場合)、ヘッド ノードに必要なデータベースが作成されます。 Express エディションには追加のライセンス料金はなく、概念実証または開発クラスターや小規模な運用クラスターに対してすぐに使用できるエクスペリエンスを提供するために含まれています。 クラスターのサイズ、スループット、要件に応じて、ヘッド ノードに別のエディションの SQL Server をインストールするか、リモート サーバーにデータベースをインストールできます。 このドキュメントの情報は、クラスターに適したデータベース構成と追加のチューニング オプションを決定するのに役立ちます。

このトピックでは、次の操作を行います。

• 該当するバージョンの Microsoft HPC Pack と Microsoft SQL Server

• Microsoft HPC Pack でのデータベースセットアップの基本的なオプション

• クラスター に適したエディションの SQL Server の選択

• 構成とチューニングのベスト プラクティス

• HPC データ保持設定 を する

• メンテナンス ガイドライン

該当するバージョンの Microsoft HPC Pack と Microsoft SQL Server

このトピックのガイダンスは、次の表に示す HPC Pack と SQL Server のバージョンに適用されます。

Microsoft HPC Pack でのデータベースセットアップの基本的なオプション

このセクションでは、HPC Pack を使用したデータベースセットアップの 3 つの基本的なオプションの背景情報を提供します。 デプロイに適したオプションの選択に関するガイダンスについては、このトピックの「クラスター に適したエディションの SQL Server の選択」を参照してください。

ヘッド ノード で SQL Server Express を する

これはすぐに使えるエクスペリエンスです。 これは通常、概念実証クラスターまたは開発クラスター、または小規模な運用クラスターに使用されます。 前のセクションの表に示すように、お使いのバージョンの HPC Pack、SQL Server 2016 Express、SQL Server 2014 Express、または SQL Server 2012 Express でサポートされている場合、最大 10 GB のデータベース サイズが許可されます。 このセットアップの基本的な手順は次のとおりです。

1. HPC Pack をサーバーにインストールしてヘッド ノードを作成します。

2. 必要に応じて、インストール ウィザードでデータベースとログ ファイルの場所を指定します (または既定値をそのまま使用します)。

3. SQL Server Express が自動的にインストールされ、HPC データベースが自動的に作成されます。

4. ノードをデプロイします。

ヘッド ノード で SQL Server Standard を する

これは、中規模クラスターの基本的な構成です。 SQL Server Standard エディション (または Compact ではなく別のフル エディション) では、より大きなデータベースと追加の管理機能を使用して、より多くのノードとより高いジョブ スループットをサポートできます。 このセットアップの基本的な手順は次のとおりです。

1. ヘッド ノードとして機能するサーバーに、HPC Pack のバージョンでサポートされているバージョンの SQL Server Standard Edition をインストールします。

2. HPC Pack をサーバーにインストールしてヘッド ノードを作成します。

3. 必要に応じて、インストール ウィザードでデータベースとログ ファイルの場所を指定します (または既定値をそのまま使用します)。

4. HPC データベースは自動的に作成されます。

5. 必要に応じて、SQL Server Management Studio を使用して必要に応じてデータベースを調整します。

6. ノードをデプロイします。

リモート データベース (SQL Server Standard または SQL Server Express)

リモート サーバーに 1 つ以上の HPC データベースをインストールすることは、大規模なクラスターまたはヘッド ノードの高可用性を実現するように構成されているクラスターの場合に推奨される構成です。 詳細については、「リモート データベースを使用した HPC Pack クラスターのデプロイ」ステップ バイ ステップ ガイドを参照してください。 高可用性ヘッド ノードの場合、通常、SQL Server の Standard エディションを使用してデータベースの高可用性をサポートします (HPC 管理サービスの高可用性とは異なります)。 詳細については、HPC Pack 2016の 概要ガイドを参照してください。 このセットアップの基本的な手順は次のとおりです。

1. HPC Pack のバージョンでサポートされている SQL Server Standard エディションのバージョンをリモート サーバーにインストールします。

2. SQL Server Management Studio を使用して、リモート HPC データベースを手動で作成し、必要に応じて調整します。

3. お使いのバージョンの HPC Pack で必要に応じて、SQL Server を実行しているリモート サーバーで他の構成手順を実行します。

4. HPC Pack をサーバーにインストールしてヘッド ノードを作成します。

5. インストール ウィザードで、リモート データベースの接続情報を指定します。

6. ノードをデプロイします。

クラスターに適した SQL Server のエディションの選択

次の一般的なガイドラインは、クラスターに使用する SQL Server のエディションを決定するのに役立ちます。 ノードとジョブのスループット番号は、クラスターに対して選択したハードウェアとトポロジ、およびクラスターがサポートするワークロードによってパフォーマンスが異なるため、一般的なガイドラインとしてのみ使用されます。

次のいずれかの条件が適用される場合は、SQL Server の Standard エディション (またはコンパクトではない別のフル エディション) の使用を検討してください。

• クラスターには多数のノードがあります。 ノードのプロパティ、構成、メトリック、パフォーマンス履歴などの情報は、データベースに格納されます。 大規模なクラスターでは、データベースにより多くのスペースが必要です。 一般的なガイドラインとして、Express エディションは、SQL Server Express 2012 を使用する最大 64 個のノード、または新しいバージョンの SQL Server Express を使用する最大 128 個のノードで十分です。

• クラスターでは、1 日あたり 10,000 個を超えるタスクやサブタスクなど、非常に高いジョブ スループットをサポートしています。 すべてのジョブ、タスク、およびサブタスクには、プロパティと割り当ての情報と履歴を格納するためのエントリがデータベースに含まれます。 このデータの既定の保持期間は 5 日間です。 保有期間を調整して、容量要件を減らすことができます。 このトピック HPC データ保持設定を参照してください。

• クラスターはヘッド ノードの高可用性用に構成されており、SQL Server の高可用性も構成する必要があります。

• ジョブとタスクのデータを HPCScheduler データベースに長期間格納する必要があり、SQL Server Express のバージョンによって課されるデータベースの制限を超えます。

• HPCReporting データベースを頻繁に使用し、場合によってはカスタム レポートにデータ拡張機能を使用します。 レポート機能拡張を無効にし、レポート データベースのサイズ要件を減らす方法については、このトピックで HPC データ保持設定 参照してください。

• SQL Server Management Studio ツール (メンテナンス プランのサポートを含む) によって提供される追加の信頼性、パフォーマンス、柔軟性が必要です。 たとえば、SQL Server Standard Edition には、HPC クラスター管理者に役立つ次のような機能が用意されています。

  • 無制限のデータベース サイズ

  • 高可用性構成のサポート

  • データベース キャッシュの無制限 RAM 使用率

  注:

  SQL Server Management Studio は、SQL Server の Express エディションには自動的に含まれません。 HPC データベースの設定を変更する場合は、個別にダウンロードできます。

• 数百個の Windows Azure ロール インスタンスなど、Windows Azure ノードの大規模なデプロイを計画しています。 大規模な Windows Azure ノードのデプロイの詳細については、「Microsoft HPC Packを使用した Windows Azure ノードの大規模なデプロイのベスト プラクティス」を参照してください。

構成とチューニングのベスト プラクティス

このセクションには、HPC データベースのパフォーマンス チューニングに関するいくつかのガイドラインとベスト プラクティスが含まれています。 大規模なクラスターの構成設定の例については、次の一覧で説明します。 これらの設定は、HPC Pack によって既定で構成されているものと大きく異なる場合があります。 これらのオプションの詳細については、以下のセクションを参照してください。

• 3 つのプラッタ (物理ディスク) を持つサーバーで、次の構成を行います。

  • 専用のプラッター上のオペレーティング システム。

  • 専用のプラッター上のクラスター データベース。

  • 専用プラッター上のクラスター データベース ログ ファイル。

• SQL Server Management Studio で次の構成を行います。

  • HPCManagement データベース: 初期サイズ 20 GB、増加率 100%

  • HPCManagement データベース ログ: 初期サイズ 2 GB

  • HPCScheduler データベース: 初期サイズ 30 GB、増加率 0%

    注:

    大規模なクラスターでは、HPCScheduler データベースがサイズ制限に近づいているため、HPC ジョブ スケジューラが予期せずシャットダウンされるのを防ぐために、このデータベースの自動拡張設定を構成しないことをお勧めします。

  • HPCScheduler データベース ログ: 初期サイズ 2 GB

  • HPCReporting データベース: 初期サイズ 30 GB、増加率 100%

  • HPCReporting データベース ログ: 初期サイズ 2 GB

  • HPCDiagnostics データベースとログ: 既定値を使用する

  • HPCMonitoring データベース: 1 GB、増加率 10%

    HPCMonitoring データベース ログ: 既定値を使用する

    注:

    HPCMonitoring データベースは、HPC Pack 2012 以降で構成されます。

• ヘッド ノードでホストされているデータベースの場合、SQL Server Management Studio で、データベースのメモリをノード上の物理メモリの約 2 分の 1 に構成します。 たとえば、16 GB の物理メモリを持つヘッド ノードの場合、8 から 10 GB のデータベース サイズを構成します。

• ヘッド ノードでホストされているデータベースの場合、SQL Server Management Studio で並列化フラグを 1 に設定します (既定値は 0 です)。

SQL Server 復旧モデルとディスク領域の要件

SQL Server Standard エディションでは、既定では、各データベースの SQL Server 復旧モデルは Fullに設定されます。 このモデルでは、手動メンテナンスが必要なため、ログ ファイルが非常に大きくなる可能性があります。 ログ領域を再利用し、ディスク領域の要件を小さく保つために、各データベースの復旧モデルを Simpleに変更できます。 選択する復旧モデルは、復旧要件によって異なります。 フル モデルを使用する場合は、ログ ファイル用の十分な領域を計画し、定期的なメンテナンス要件に注意してください。 詳細については、「復旧モデルの概要参照してください。

データベースとログ ファイルの初期サイズ設定と自動拡張

自動拡張は、データベースまたはログ ファイルの領域が不足すると、(自動拡張パラメーターで定義されている) 定義済みの割合でサイズが自動的に増加することを意味します。 自動拡張プロセス中、データベースはロックされます。 これはクラスターの操作とパフォーマンスに影響し、操作のデッドロックとタイムアウトを引き起こす可能性があります。 データベースの事前サイズ設定は、これらのパフォーマンスの問題を回避するのに役立ち、自動拡張の割合を大きく構成することで、自動拡張操作の頻度を減らすことができます。 ただし、100% に近づく自動拡張設定と組み合わせてサイズが大きい初期ファイルの場合、データベースの拡張にかなりの時間が必要になる場合があります。 長期間にわたってデータベースへのアクセスをブロックしない値を決定するには、ディスク サブシステムのパフォーマンスを理解することが重要です。

各データベースには、関連するログ ファイルがあります。 ログ ファイルの初期サイズと自動拡張の設定を調整することもできます。

データベースとログ ファイルの既定の構成 (SQL Server のエディションに関係なく) を次の表に示します。

たとえば、次の表に、数百以上のノードを持つクラスターに適した初期サイズと自動拡張の設定を示します。

次の画面の切り取りは、SQL Server Management Studio の HPC データベースと、データベースの初期サイズと自動拡張設定の構成に使用できるデータベースのプロパティ ダイアログ ボックスを示しています。

SQL Management Studio で HPC データベースを構成する

データベースとログ ファイルの場所

ログ ファイルとは別のプラッタ (物理ディスク) にデータベースを作成することで、パフォーマンスを向上させることができます。 これは、ヘッド ノード上にあるデータベースとリモート データベースに適用されます。 ヘッド ノード上のデータベースの場合は、セットアップ時に (インストール ウィザードで) データベースとログ ファイルの場所を指定できます。 システムパーティション、データ、ログを別々のプラッタに配置することをお勧めします。

レポートが頻繁に使用される場合は、HPCReporting データベースを別のプラッターに移動することを検討してください。

データベースの移動の詳細については、「デタッチとアタッチ (Transact-SQL)を使用してデータベースを移動する を参照してください。

SQL Server インスタンスの設定

メモリのページングを最小限に抑えるには、SQL Server インスタンスに十分なメモリ割り当てがあることを確認します。 SQL Server Management Studio を使用して、インスタンスのサーバー プロパティで SQL Server インスタンスのメモリを設定できます。 たとえば、データベースが 16 GB のメモリを持つヘッド ノード上にある場合は、SQL Server に 8 ~ 10 GB を割り当てることができます。

SQL Server プロセスと HPC プロセス間のヘッド ノードでのコア競合を最小限に抑えるには、SQL Server インスタンスの並列化フラグを 1 に設定します。 既定では、フラグは 0 に設定されています。つまり、SQL が使用するコア数に制限はありません。 これを 1 に設定すると、SQL Server プロセスを 1 コアに制限します。

HPC データ保有期間の設定

HPCManagement データベース の

HPC Pack 2012 R2 Update 1 以降、クラスター管理者は、サービスが HPCManagement データベース内の操作ログ データのアーカイブを開始するまでの日数と、アーカイブされた操作ログ データが保持される日数を指定できます。 たとえば、7 日ごとに操作ログ アーカイブを設定し、保持後に 180 日間削除するには、管理者として HPC Powershell を実行し、次のコマンドレットを入力します。

Set-HpcClusterProperty –OperationArchive 7

Set-HpcClusterProperty –OperationRetention 180

HPCScheduler データベース の

ジョブのプロパティ、割り当て、履歴は HPCScheduler データベースに格納されます。 既定では、完了したジョブに関するデータは 5 日間保持されます。 ジョブ レコードの保持期間 (TtlCompletedJobs) によって、次のレコードのデータを格納する期間が決まります。

• HPCScheduler データベースの完了したジョブ (完了した、失敗した、または取り消されたの ) に関するデータ。

• Runtime$ 共有に格納されている SOA 共通データ。

• HPCDiagnostics データベースの診断テスト結果とデータ。

• MSMQ を使用してブローカー ノードによって格納される、完了した永続セッションのメッセージ。

構成 状態のジョブは、データベースから削除されません。 ジョブは、ジョブ所有者またはクラスター管理者によって取り消される (または何らかの方法で完了する) 必要があり、ジョブ履歴ポリシーに従って削除されます。

このプロパティは、Set-HpcClusterProperty コマンドレットを使用して構成できます。 たとえば、ジョブ レコードの保持期間を 3 日に設定するには、HPC PowerShell を管理者として実行し、次のコマンドレットを入力します。

Set-HpcClusterProperty –TtlCompletedJobs 3

このプロパティは、[HPC ジョブ スケジューラの構成] ダイアログ ボックスの ジョブ履歴 設定で構成することもできます。

HPCReporting データベース の

クラスターの使用率、ノードの可用性、ジョブ統計などのクラスターに関する履歴データが集計され、HPCReporting データベースに格納されます。 また、データベースには、データ拡張が有効になっているときにカスタム レポートをサポートするために使用できるジョブに関する生データも格納されます (既定で有効になっています)。 たとえば、組織で使用される課金方法に対応するカスタムのチャージバック レポートを作成できます。 カスタム レポートに生データを使用する方法については、「Reporting Extensibility Step-by-Step Guideを参照してください。

次の表では、生データのデータ拡張と保持期間を制御するクラスター プロパティについて説明します。 これらの設定は、組み込みレポートに使用される集計データには影響しません。 Get-HPCClusterProperty コマンドレットを使用してプロパティの値を表示し、Set-HpcClusterProperty コマンドレットを使用して値を設定できます。 たとえば、データ拡張を無効にするには、HPC PowerShell を管理者として実行し、次のコマンドレットを入力します。

Set-HpcClusterProperty –DataExtensibilityEnabled $false

クラスター内の HPCReporting データベースに必要なサイズを見積もる場合は、「Reporting Databaseのサイズの見積もり」を参照してください。

HPCDiagnostics データベース の

診断テストの実行の情報と結果は、HPCDiagnostics データベースに格納されます。 ジョブ レコードの保持期間 (TtlCompletedJobs) によって、完了したテスト実行に関するデータを格納する期間が決まります。

HPCMonitoring データベース の

HPC Monitoring Server Service と HPC Monitoring Client Service によってクラスター ノードから収集および集計されたパフォーマンス カウンター データは、HPCMonitoring データベースに格納されます。

パフォーマンス カウンター データは、分、時間、日で集計されます。 ノード パフォーマンス カウンター データのデータ保有期間は、次の表のクラスター プロパティによって定義されます。 これらのプロパティは、Set-HpcClusterProperty コマンドレットを使用して構成できます。

HpcMonitoring データベースに必要なサイズは、ノードの数、パフォーマンス カウンターの数、保持期間に基づいて見積もることができます。 たとえば、既定の MinuteCounterRetention 3 日間 (4,320 分) の期間と、各パフォーマンス値エントリに約 40 バイトを必要とする 27 個のパフォーマンス カウンターを使用すると、各ノードで次の処理が必要になります。

4,320 x 27 x 40 = 4,665,600 バイト、または約 5 MB。

ノード数が 1000 のクラスターでは、約 5 GB のストレージが必要になります。

メンテナンスガイドライン

一般的な SQL Server メンテナンス プランでは、次の内容について説明します。

• データベース バックアップ

• 整合性チェック

• インデックスの最適化

SQL Server Management Studio を使用してインデックスの断片化を監視し、必要に応じてメンテナンス プランでインデックスを最適化できます。

通常は、250,000 個のジョブまたは 1 か月 (どちらか短い方) の後にインデックスを再構築することをお勧めします (それ以上頻繁ではない場合)。 整合性チェックとバックアップを実行する頻度は、ビジネス要件によって異なります。 メンテナンスの実行は、ジョブのスループットとユーザー エクスペリエンスに重大な影響を与える可能性があるため、ユーザー アクティビティがほとんどない場合 (特に大規模なクラスターの場合) にスケジュールされたダウンタイム中に実行することをお勧めします。

データベース メンテナンスのベスト プラクティスについては、「効果的なデータベース メンテナンスのに関するヒント」を参照してください。

関連項目

• microsoft HPC Pack 2016 の製品評価と計画の

• Microsoft HPC Pack 2016 の概要