SQL Server の設計に関する考慮事項

System Center Operations Manager は、Microsoft SQL Server を利用して、運用、データ ウェアハウス、ACS 監査データベースをサポートします。 これらのデータベースは不可欠であり、管理グループ内の最初の管理サーバーまたは ACS コレクターの展開中に作成されます。

ラボ環境または Operations Manager の小規模な展開では、SQL Server を管理グループの最初の管理サーバーに併置できます。

中規模からエンタープライズ規模の分散展開では、SQL Server インスタンスは専用のスタンドアロン サーバーまたは SQL Server の高可用性構成に配置する必要があります。 どちらの場合も、SQL Server は既に存在している必要があり、最初の管理サーバーまたは ACS コレクターのインストールを開始する前にアクセス可能です。

I/O やその他のハードウェア リソース制限に関する潜在的な問題を回避するために、他のアプリケーション データベースがある SQL インスタンスから Operations Manager データベースを使用することはお勧めしません。

SQL Server 要件

Reporting Server、Operational、Data Warehouse、ACS データベースをホストする System Center Operations Manager バージョンの既存のインストールでは、次のバージョンの SQL Server Enterprise および Standard Edition がサポートされています。

SQL Server ドライバー

OLE DB と ODBC SQL Server ドライバーは、すべて管理サーバーと Web コンソール サーバーにインストールする必要があります。これらのコンポーネントはデータベースと直接インターフェイスし、これらのドライバーによって SQL への API レベルのアクセスが許可されるためです。

Operations Manager で使用するために推奨されるバージョンは次のとおりです。

• Microsoft ODBC Driver バージョン 17.10.6。
• Microsoft OLE DB Driver バージョン 18.7.4。

暗号化された SQL Server 接続を使用する場合は、代わりに最新バージョンのドライバーをインストールする必要があります。

• Microsoft OLE DB Driver 最新バージョン。
• Microsoft ODBC ドライバー 最新バージョン。

SQL 接続暗号化の構成の詳細については、接続を暗号化するための SQL Server データベース エンジンの構成に関するページを参照してください。

SQL Server の更新プログラム

Operations Manager インフラストラクチャをサポートする次の各 SQL Server コンポーネントは、同じ SQL Server メジャー バージョンである必要があります。

• 次のような Operations Manager データベースをホストする SQL Server データベース エンジン インスタンス。
  • OperationManager
  • OperationManagerDW
  • SSRS データベース ReportServer と ReportServerTempDB
• SQL Server Reporting Services (SSRS) インスタンス。

SQL Server 認証モード

既定では、SQL は混合モード認証構成で動作します。 ただし、Operations Manager では、SQL Server との通信にWindows 認証のみが使用されます。 既定のままにすると、ローカル アカウントに db_owner ロールがない場合でも、SQL 混合モード認証設定は引き続き機能します。 db_owner ロールを持つローカル アカウントは、Operations Manager で問題を引き起こすことがわかっています。

製品をインストールする前に、すべてのローカル アカウントから db_owner ロールを削除することを強くお勧めします。また、インストール後に db_owner ロールをローカル アカウントに追加しないことを強くお勧めします。

その他の考慮事項

設計計画には、ハードウェアとソフトウェアに関するその他の考慮事項が適用されます。

• NTFS ファイル形式の SQL ディスクを使用することをお勧めします。
• 運用データベースとデータ ウェアハウス データベースには少なくとも 1 GB の空きディスク領域が必要です。これは、データベースの作成時に適用されます。 データベースのディスク使用率は、セットアップ後に大幅に増加しますこの基本要件を超える十分な空きディスク領域があることを確認してください。
• .NET Framework 4 が必要です。
• .NET Framework 4.8 は Operations Manager 2022 よりサポートされています。
• レポート サーバーは、Windows Server Core ではサポートされていません。
• SQL Server 照合順序の設定は、「 SQL Server 照合順序の設定」セクションで説明されているように、サポートされている種類のいずれかである必要があります。
• Operations Manager データベースをホストするすべての SQL Server データベース エンジン インスタンスには、SQL Server フルテキスト検索が必要です。
• Operations Manager データベース コンポーネントでサポートされる Windows Server インストール オプション (Server Core、デスクトップ エクスペリエンス搭載サーバー、Nano Server) は、SQL Server でサポートされているインストール オプションに基づいています。

詳細については、「SQL Server のインストールと計画」の「ハードウェアとソフトウェアの要件」セクションを参照してください。 SQL Server のインストールを計画する

SQL Server 照合順序の設定

System Center Operations Manager では、次の SQL Server 照合順序と Windows 照合順序がサポートされています。

SQL Server の照合順序

• SQL_Latin1_General_CP1_CI_AS

[Windows 照合順序]

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinese_Simplified_Pinyin_100_CI_AS
• Chinese_Traditional_Stroke_Count_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

前述のサポートされている照合順序のいずれかで SQL Server インスタンスが構成されていない場合、Operations Manager セットアップの新しいセットアップの実行は失敗します。 ただし、インプレース アップグレードは正常に完了します。

ファイアウォールの構成

Operations Manager は、SQL Server に依存してデータベースをホストし、履歴の運用データを分析して表示するレポート プラットフォームを提供します。 管理サーバー、操作、および Web コンソールの役割は、SQL Server と正常に通信できる必要があります。また、環境を正しく構成するには、通信パスとポートを理解することが重要です。

SQL Always On 可用性グループを使用する分散デプロイを設計する場合は、ファイアウォールのセキュリティ戦略に追加のファイアウォール構成設定を含める必要があります。

次の表は、管理サーバーがデータベースと通信するために SQL Server に必要なファイアウォール ポートを示しています。

シナリオ	ポート	方向	Operations Manager ロール
Operations Manager データベースをホストする SQL Server	TCP 1433 *	着信	管理サーバーと Web コンソール (Application Advisor およびアプリケーション診断用)
SQL Server Browser サービス	UDP 1434	着信	Management サーバー
SQL Server 専用管理者接続	TCP 1434	着信	Management サーバー
SQL Server で使用されるその他のポート - Microsoft リモート プロシージャ コール (MS RPC) - Windows Management Instrumentation (WMI) - Microsoft 分散トランザクション コーディネーター (MS DTC)	TCP 135	着信	Management サーバー
SQL Server Always On 可用性グループ リスナー	管理者が構成したポート	着信	Management サーバー
Operations Manager Reporting Server をホストする SQL Server Reporting Services	TCP 80 (既定値)/443 (SSL)	着信	管理サーバーとオペレーション コンソール

SQL Server のファイアウォール要件の詳細な概要については、「 WINDOWS ファイアウォールを構成して SQL Server アクセスを許可するを参照してください。

容量とストレージに関する考慮事項

Operations Manager データベース

Operations Manager データベースは、日常的な監視に Operations Manager で必要なすべてのデータを含む SQL Server データベースです。 データベース サーバーのサイズ設定と構成は、管理グループの全体的なパフォーマンスにとって重要です。 Operations Manager データベースで使用される最も重要なリソースはストレージ サブシステムですが、CPU と RAM も重要です。

Operations Manager データベースの負荷に影響を与える要因は次のとおりです。

• 運用データの収集率。
  • 運用データ収集の速度は、インポートされた管理パックの数、追加されたエージェントの数、監視対象のコンピューターの種類などの要因によって影響を受けます。 たとえば、ビジネスクリティカルなデスクトップ コンピューターを監視するエージェントでは、複数のデータベースを持つ SQL Server を実行しているサーバーを監視するエージェントに比べて収集されるデータが少なくなります。
• インスタンス領域の変更率。
  • Operations Manager データベース内の既存のデータの更新は、新しい運用データの書き込みに比べてリソースを大量に消費します。 さらに、インスタンス領域データに変更がある場合、管理サーバーはデータベースに対してさらに多くのクエリを実行して構成を計算し、変更をグループ化する必要があります。 新しい管理パックをインポートするとき、または新しいエージェントを管理グループに追加すると、インスタンス領域の変更率が増加します。
• 同時に実行されているオペレーション コンソールとその他の SDK 接続の数も、データベースの負荷に影響します。
  • 各オペレーション コンソールは、Operations Manager データベースからデータを読み取ります。 このデータのクエリを実行すると、大量のストレージ I/O リソース、CPU 時間、RAM が消費される可能性があります。 イベント ビュー、状態ビュー、アラート ビュー、パフォーマンス データ ビューに大量の操作データを表示するオペレーション コンソールでは、データベースの負荷が最も大きくなる傾向があります。

Operations Manager データベースは管理グループの単一障害原因であるため、SQL Server Always On 可用性グループやフェールオーバー クラスター インスタンスなどのサポートされているフェールオーバー構成を使用して高可用性を実現できます。

Operations Manager データベースで SQL Broker を有効にする

System Center Operations Manager は、すべてのタスク操作を実装するために SQL Server Service Broker に依存します。 SQL Server Service Broker が無効になっている場合、すべてのタスク操作が影響を受けます。 結果の動作は、開始されるタスクによって異なる場合があります。 そのため、System Center Operations Manager のタスクで予期しない動作が発生した場合は常に、SQL Server Service Broker の状態を確認することが重要です。

SQL Server Service Broker を有効にするには、次の手順に従います。

1. 次の SQL クエリを実行して、ブローカーが既に有効になっているかどうかを確認します。これは、is_broker_enabled フィールドの 1 (1) の結果で示されます。

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. is_broker_enabled フィールドに表示される値が 0 (ゼロ) の場合は、次の SQL ステートメントを実行してブローカーを有効にします。

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

Operations Manager Data Warehouse データベース

System Center - Operations Manager は、ほぼリアルタイムでデータ ウェアハウスにデータを挿入します。このサーバーには、データ ウェアハウスに収集されるすべてのデータの書き込みをサポートする十分な容量が必要です。 Operations Manager データベースと同様に、データ ウェアハウスで最も重要なリソースはストレージ I/O サブシステムです。 ほとんどのシステムでは、データ ウェアハウスの負荷は Operations Manager データベースに似ていますが、異なる場合があります。 さらに、レポートによってデータ ウェアハウスに配置されるワークロードは、Operations Manager データベースに対するオペレーション コンソールの使用状況による負荷とは異なります。

データ ウェアハウスの負荷に影響を与える要因は次のとおりです。

• 運用データの収集率。
  • データ ウェアハウスは計算を実行し、集計データと限られた量の生データを格納して、より効率的なレポートを可能にします。 その結果、運用データをデータ ウェアハウスに収集するコストは、Operations Manager データベースと比較して若干高くなります。 ただし、このコストは、Operations Manager データベースと比較して、データ ウェアハウス内の探索データの処理コストの削減によって相殺されます。
• 同時レポート ユーザーまたはスケジュールされたレポート生成の数。
  • レポートでは大量のデータが頻繁に集計されるため、各レポート ユーザーはシステムに大きな負荷を追加できます。 全体的な容量のニーズは、同時に実行されるレポートの数と実行されるレポートの種類によって影響を受けます。 大きな日付範囲または多数のオブジェクトに対してクエリを実行するレポートには、追加のシステム リソースが必要です。

これらの要因に基づいて、データ ウェアハウスのサイズを設定するときに考慮すべきいくつかの推奨プラクティスがあります。

• 適切なストレージ サブシステムを選択します。
  • データ ウェアハウスは管理グループ全体のデータ フローに不可欠な部分であるため、データ ウェアハウスに適したストレージ サブシステムを選択することが重要です。 Operations Manager データベースと同様に、多くの場合、RAID 0 + 1 が最適な選択肢です。 一般に、データ ウェアハウスのストレージ サブシステムは Operations Manager データベースのストレージ サブシステムに似ている必要があり、Operations Manager データベースに適用されるガイダンスはデータ ウェアハウスにも適用されます。
• データ ログとトランザクション ログの適切な配置を検討してください。
  • Operations Manager データベースに関しては、多くの場合、エージェントの数をスケールアップするときに、SQL データとトランザクション ログを分離することが適切な選択肢です。 Operations Manager データベースとデータ ウェアハウスの両方が同じサーバー上にあり、データとトランザクション ログを分離する場合は、Operations Manager データベースのトランザクション ログをデータ ウェアハウスとは別の物理ボリュームとディスク スピンドルに配置して、メリットを受け取る必要があります。 Operations Manager データベースとデータ ウェアハウスのデータ ファイルは、ボリュームが十分な容量を提供し、ディスク I/O パフォーマンスが監視およびレポート機能に悪影響を与えない限り、同じ物理ボリュームを共有できます。
• Operations Manager データベースとは別のサーバーにデータ ウェアハウスを配置することを検討してください。
  • 小規模なデプロイでは、多くの場合、Operations Manager データベースとデータ ウェアハウスを同じサーバーに統合できますが、エージェントの数と受信操作データの量をスケールアップするときに、それらを分離すると便利です。 データ ウェアハウスとレポート サーバーが Operations Manager データベースとは別のサーバー上にある場合、レポートのパフォーマンスが向上します。

Operations Manager Data Warehouse データベースは、管理グループの単一障害原因であるため、SQL Server Always On 可用性グループやフェールオーバー クラスター インスタンスなどのサポートされているフェールオーバー構成を使用して高可用性を実現できます。

SQL Server AlwaysOn

SQL Server Always On 可用性グループは、個別のユーザー データベース (可用性データベース) のフェールオーバー環境をサポートします。 可用性データベースの各セットは、可用性レプリカでホストされます。

System Center 2016 以降 - Operations Manager では、データベースの高可用性を実現するために、フェールオーバー クラスタリングよりも SQL Always On が推奨されます。 ネイティブ モードの Reporting Services インストールを除くすべてのデータベースは、2 つのデータベースを使用して永続データ ストレージを一時ストレージ要件から分離し、AlwaysOn 可用性グループでホストできます。

可用性グループを設定するには、Windows Server フェールオーバー クラスタリング (WSFC) クラスターをデプロイして可用性レプリカをホストし、クラスター ノードで Always On を有効にします。 その後、Operations Manager SQL Server データベースを可用性データベースとして追加できます。

• Always On の前提条件の詳細。
• Always On 可用性グループの WSFC の 設定の詳細については。
• 可用性グループの 設定の詳細についてはを参照してください。

Multisubnet 文字列

Operations Manager では、接続文字列キーワード (MultiSubnetFailover=True) はサポートされていません。 可用性グループには、クロスサイト フェールオーバー構成で展開する場合など、異なるサブネットの複数の IP アドレスに応じてリスナー名 (WSFC クラスター マネージャーのネットワーク名またはクライアント アクセス ポイントと呼ばれます) があるため、管理サーバーから可用性グループ リスナーへのクライアント接続要求は接続タイムアウトに達します。

マルチサブネット環境にデプロイされた可用性グループ サーバー ノードでこの制限を回避するには、次の方法をお勧めします。

1. 可用性グループ リスナーのネットワーク名を、DNS に 1 つのアクティブな IP アドレスのみを登録するように設定します。
2. 登録済みの DNS レコードに低い TTL 値を使用するようにクラスターを構成します。

これらの設定を使用すると、別のサブネット内のノードにフェールオーバーするときに、新しい IP アドレスを使用してクラスター名を迅速に復旧および解決できます。

いずれかの SQL ノードで次の PowerShell コマンドを実行して、これらの設定を変更します。

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

リスナー名で Always On を使用している場合は、リスナーでこれらの構成を変更する必要もあります。 可用性グループ リスナーの構成の詳細については、「 可用性グループ リスナーの構成 - SQL Server Always On」のドキュメントを参照してください。

次の PowerShell コマンドは、リスナーを現在ホストしている SQL ノードで実行して、その設定を変更できます。

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

高可用性のためにクラスター化または Always On SQL インスタンスを使用する場合は、ノード間のフェールオーバーが発生するたびに Operations Manager データ アクセス サービスが再起動されないように、管理サーバーで自動復旧機能を有効にする必要があります。 構成情報については、次の KB 記事を参照してください System Center Management サービスは、SQL Server のインスタンスがオフラインになった後に応答を停止します。

SQL Server の最適化

サポート エクスペリエンスでは、パフォーマンスの問題は、通常、SQL Server 自体でのリソース使用率 (つまり、プロセッサまたはメモリ) が高いことが原因で発生しないことを示しています。むしろ、この問題はストレージ サブシステムの構成に直接関連しています。 パフォーマンスのボトルネックは、一般に、SQL Server データベース インスタンス用にプロビジョニングされたストレージで推奨される構成ガイダンスに従っていない場合に発生します。 次に例を示します。

• Operations Manager の IO 要件をサポートするために LUN に対するスピンドルの割り当てが不十分です。
• 同じボリューム上のトランザクション ログとデータベース ファイルをホストします。 これら 2 つのワークロードには、IO と待機時間の特性が異なります。
• TempDB の構成は、配置、サイズ設定などについて正しくありません。
• データベース トランザクション ログ、データベース ファイル、および TempDB をホストするボリュームのディスク パーティションの位置が正しく配置されなかっています。
• データベースおよびトランザクション ログ ファイルに AUTOGROW を使用する、クエリの並列処理用の MAXDOP 設定、CPU コアごとに複数の TempDB データ ファイルを作成するなど、基本的な SQL Server 構成を見落とします。

記憶域の構成は、Operations Manager の SQL Server 展開にとって重要なコンポーネントの 1 つです。 データベース サーバーは、厳密なデータベース読み取り/書き込みアクティビティとトランザクション ログ処理により、I/O が頻繁にバインドされる傾向があります。 Operations Manager の I/O 動作パターンは、通常、80% の書き込みと 20% の読み取りです。 その結果、I/O サブシステムを不適切に構成すると、SQL Server システムのパフォーマンスと動作が低下し、Operations Manager で顕著になる可能性があります。

SQL Server をデプロイする前に、IO サブシステムのスループット テストを実行して、SQL Server の設計をテストすることが重要です。 これらのテストで、許容可能な待機時間で IO 要件を達成できることを確認します。 Diskspd ユーティリティを使用して、SQL Server をサポートするストレージ サブシステムの I/O 容量を評価します。 製品グループのファイル サーバー チームのメンバーが作成した次のブログ記事では、このツールを使用してストレス テストを実行する方法に関する詳細なガイダンスと推奨事項 ( DiskSpd、PowerShell、ストレージのパフォーマンス) について説明します。IOPS の測定、ローカル ディスクと SMB ファイル共有の両方のスループットと待機時間。

NTFS アロケーション ユニット のサイズ

ボリュームの配置 (一般にセクターアラインメントと呼ばれます) は、RAID デバイスでボリュームが作成されるたびに、ファイル システム (NTFS) で実行する必要があります。 これを行わないと、パフォーマンスが大幅に低下する可能性があり、最も一般的には、ストライプ ユニットの境界によるパーティションの不整合の結果です。 また、ハードウェア キャッシュの配置が間違いになり、配列キャッシュが非効率的に使用される可能性もあります。

SQL Server データ ファイルに使用されるパーティションを書式設定する場合は、データ、ログ、TempDB に 64 KB のアロケーション ユニット サイズ (つまり、65,536 バイト) を使用することをお勧めします。 ただし、4 KB を超える割り当てユニット サイズを使用すると、ボリュームで NTFS 圧縮を使用できなくなることに注意してください。 SQL Server では圧縮ボリューム上の読み取り専用データがサポートされていますが、推奨されません。

メモリを予約する

System Center Operations Manager (またはこの製品以外の他のワークロード) をサポートするために SQL Server に割り当てる物理メモリとプロセッサの適切な量を特定することは必ずしも簡単ではありません。 製品グループによって提供されるサイズ変更計算ツールは、ワークロードのスケールに基づくガイダンスを提供しますが、その推奨事項は、実際のワークロードと構成と一致する場合と合わないラボ環境で実行されるテストに基づいています。

SQL Server を使用すると、そのプロセスによって予約および使用されるメモリの最小量と最大量構成できます。 既定では、SQL Server は使用可能なシステム リソースに基づいてメモリ要件を動的に変更できます。 min サーバー メモリの既定の設定は 0、max サーバー メモリの既定の設定は 2,147,483,647 MB です。

max サーバー メモリに適切な値を設定しないと、パフォーマンスとメモリ関連の問題が発生する可能性があります。 多くの要因は、オペレーティング システムが HBA カード、管理エージェント、ウイルス対策リアルタイム スキャンなど、そのシステムで実行されている他のプロセスをサポートできるようにするために、SQL Server に割り当てる必要があるメモリの量に影響します。 十分なメモリが設定されていない場合、OS と SQL はディスクにページングします。 これにより、ディスク I/O が増加し、パフォーマンスがさらに低下し、Operations Manager で目立つ波及効果が生じる可能性があります。

min サーバー メモリには、少なくとも 4 GB の RAM を指定することをお勧めします。 これは、Operations Manager データベース (運用、データ ウェアハウス、ACS) のいずれかをホストするすべての SQL ノードに対して行う必要があります。

max サーバー メモリでは、最初に次の合計を予約することをお勧めします。

• OS 用の 1 GB の RAM
• インストールされている 4 GB の RAM ごとに 1 GB の RAM (最大 16 GB の RAM)
• インストールされている 8 GB の RAM ごとに 1 GB の RAM (16 GB 以上の RAM)

これらの値を設定したら、Windows の Memory\Available MBytes カウンターを監視して、SQL Server で使用可能なメモリを増やすことができるかどうかを判断します。 Windows は、使用可能な物理メモリが 96 MB で低く実行されていることを通知します。そのため、バッファーを確保するために、カウンターを約 200 ~ 300 MB 未満で実行することが理想的です。 256 GB 以上の RAM を持つサーバーの場合は、1 GB より低く実行されないようにします。

これらの計算では、他のアプリケーションを考慮するように変更しない限り、SQL Server で使用可能なすべてのメモリを使用できることを前提としています。 OS、他のアプリケーション、SQL Server スレッド スタック、およびその他のマルチページ アロケーターの特定のメモリ要件を考慮してください。 一般的な数式は ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators))され、スレッド スタックのメモリは ((max worker threads) (stack size))。 スタック サイズは、x86 システムの場合は 512 KB、x64 システムの場合は 2 MB、IA64 システムの場合は 4 MB であり、sys.dm_os_sys_infoの max_worker_count 列の最大ワーカー スレッドの値を確認できます。

これらの考慮事項は、仮想マシンで実行する SQL Server のメモリ要件にも適用されます。 SQL Server はバッファー プール内のデータをキャッシュするように設計されており、可能な限り多くのメモリを使用するため、必要な RAM の最適な量を判断することが困難な場合があります。 SQL Server インスタンスに割り当てられたメモリを減らすと、ディスク I/O アクセスが高くなるように、メモリ割り当てが低くなるポイントに達する可能性があります。

過剰プロビジョニングされた環境で SQL Server メモリを構成するには、まず、SQL Server Buffer Manager ページの平均寿命 ページ読み取り/秒 物理ディスク ディスクの読み取り/秒 値など、環境と現在のパフォーマンス メトリックを監視します。 環境に過剰なメモリがある場合、 ページの平均寿命 は、キャッシュが原因でワークロードの下で低下することなく 1 秒ごとに 1 秒ずつ増加します。SQL Server バッファー マネージャーの ページ読み取り/秒 値はキャッシュ ランプアップ後に低くなります。また、物理ディスク ディスクの読み取り/秒 も低いままです。

環境ベースラインを理解したら、 max サーバー メモリ を 1 GB 減らし、(初期キャッシュ フラッシュが沈静化した後) パフォーマンス カウンターに与える影響を確認できます。 メトリックが引き続き許容される場合は、さらに 1 GB 減らしてから、必要に応じて監視し、理想的な構成を決定するまで繰り返します。

詳細については、「 Server memory configuration options」を参照してください。

TempDB の最適化

TempDB データベースのサイズと物理的な配置は、Operations Manager のパフォーマンスに影響する可能性があります。 たとえば、TempDB に対して定義されているサイズが小さすぎる場合、SQL Server のインスタンスを再起動するたびに、ワークロードをサポートするために必要なサイズに TempDB を自動拡張することで、システム処理の負荷の一部が占められる可能性があります。 最適な TempDB パフォーマンスを実現するには、運用環境での TempDB に対して次の構成をお勧めします。

• TempDB の 回復モデル を SIMPLE に設定します。
  • このモデルでは、領域の要件を小さく保つために、ログ領域が自動的に再利用されます。
• すべての TempDB ファイルに対する領域をあらかじめ割り当てるには、環境における一般的なワークロードに十分に対応できる大きさの値にファイル サイズを設定します。 TempDB の展開頻度が高くなりすぎず、パフォーマンスに影響する可能性があります。 TempDB データベースは自動拡張に設定できますが、これは計画外の例外のディスク領域を増やすために使用する必要があります。
• ディスク帯域幅を最大化するために必要な数のファイルを作成します。
  • 複数のファイルを使用すると、TempDB ストレージの競合が減少し、スケーラビリティが向上します。 ただし、パフォーマンスを低下させ、管理オーバーヘッドを増やすことができるため、作成するファイルが多くなりすぎないようにしてください。
  • 一般的なガイドラインとして、サーバー上の論理プロセッサごとに 1 つのデータ ファイルを作成し (アフィニティ マスク設定を表します)、必要に応じてファイルの数を上下に調整します。
  • 一般的なルールとしては、論理プロセッサの数が 8 以下の場合、論理プロセッサと同じ数のデータ ファイルを使用します。
    • 論理プロセッサの数が 8 を超える場合は、8 つのデータ ファイルを使用し、競合が続く場合は、競合が許容できるレベルに減少するか、ワークロード/コードに変更を加えるまで、データ ファイルの数を 4 の倍数 (論理プロセッサの数まで) 増やします。
    • 競合が減らない場合は、データ ファイルの数を増やす必要があります。
• 各データ ファイルのサイズを同じにして、最適なプロポーショナル フィル パフォーマンスを実現します。
  • プロポーショナル フィル アルゴリズムはファイルのサイズに基づいているため、データ ファイルのサイズを等しくすることが重要です。 データ ファイルが等しくないサイズで作成された場合、プロポーショナル フィル アルゴリズムは、すべてのファイル間で割り当てを分散するのではなく、GAM 割り当てに最大のファイルをより多く使用しようとします。これにより、複数のデータ ファイルを作成する目的が失われます。
• 最適なパフォーマンスを得るためのソリッド ステート ドライブを使用して、TempDB データベースを高速 I/O サブシステムに配置します。
  • 直接アタッチされたディスクが多数ある場合は、ディスク ストライピングを使用します。
• ユーザー データベースによって使用されるディスクとは異なるディスクに TempDB データベースを配置します。

TempDB を構成するには、次のクエリを実行するか、Management Studio でそのプロパティを変更します。

USE [TempDB]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [TempDB] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'TempDB', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [TempDB] ADD FILE ( NAME = N'TempDB2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TempDB2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

T-SQL クエリ SELECT * from sys.sysprocesses を実行して、TempDB データベースのページ割り当ての競合を検出します。 システム テーブルの出力では、待機リソースは "2:1:1" (PFS ページ) または "2:1:3" (共有グローバル割り当てマップ ページ) として表示できます。 競合の程度によっては、この設定により、SQL Server が短時間応答しなくなる可能性があります。 もう 1 つの方法は、動的管理ビュー [sys.dm_exec_requestまたはsys.dm_os_waiting_tasks] を調べることです。 結果は、これらの要求またはタスクが TempDB リソースを待機しており、 sys.sysprocesses クエリの実行時に前に強調表示したのと同様の値を持っていることを示しています。

前の推奨事項で割り当ての競合が大幅に減少せず、競合が SGAM ページにある場合は、SQL Server のスタートアップ パラメーターで -T1118トレース フラグをして、SQL Server のリサイクル後もトレース フラグが有効なままになるようにします。 このトレース フラグの下で、SQL Server は各データベース オブジェクトに完全なエクステントを割り当てて、SGAM ページでの競合を排除します。

並列処理の最大次数

Operations Manager の小規模から中規模の展開に対する SQL Server の既定の構成は、ほとんどのニーズに適しています。 ただし、管理グループのワークロードがエンタープライズ クラスのシナリオ (通常は 2,000 以上のエージェントマネージド システムと高度な監視構成 (高度な代理トランザクションによるサービス レベルの監視、ネットワーク デバイスの監視、クロスプラットフォームなど) に向かってスケールアップする場合は、ドキュメントのこのセクションで説明する SQL Server の構成を最適化する必要があります。 前のガイダンスで説明していない構成オプションの 1 つは MAXDOP です。

Microsoft SQL Server max degree of parallelism (MAXDOP) 構成オプションは、並列プランでのクエリの実行に使用されるプロセッサの数を制御します。 このオプションは、作業を並列で実行するクエリ プラン演算子に使用されるコンピューティング リソースとスレッド リソースを決定します。 SQL Server が対称マルチプロセッシング (SMP) コンピューター、一様でないメモリ アクセス (NUMA) コンピューター、またはハイパースレッディング対応プロセッサのいずれに設定されているかに応じて、並列処理の最大限度オプションを適切に構成する必要があります。

SQL Server は、複数のマイクロプロセッサまたは CPU を搭載したコンピューター上で実行する場合、並列プランの実行ごとに、1 つのステートメントを実行するために使用される最適な並列処理の度合い、つまりプロセッサの数を検出します。 既定では、このオプションの値は 0 です。これにより、SQL Server は並列処理の最大次数を決定できます。

Operations Manager で定義済みのストアド プロシージャとクエリは、運用、データ ウェアハウス、および監査データベースに関連するため、MAXDOP オプションは含まれません。インストール中にオペレーティング システムに表示されるプロセッサの数を動的に照会する方法はなく、この設定の値をハードコーディングしようともしないため、クエリの実行時に悪影響を及ぼす可能性があります。

• 8 個を超えるプロセッサを使用するサーバーの場合は、次の構成を使用します: MAXDOP=8

• 8 個以下のプロセッサを使用するサーバーの場合は、MAXDOP=0 から N の構成を使用します。

  ヒント

  この構成では、 N はプロセッサの数を表します。

• NUMA が構成されているサーバーの場合、MAXDOP は各 NUMA ノードに割り当てられている CPU の数を超えないようにする必要があります。

• ハイパースレッディングが有効になっているサーバーの場合、MAXDOP 値は物理プロセッサの数を超えないようにする必要があります。

• NUMA が構成され、ハイパースレッディングが有効になっているサーバーの場合、MAXDOP 値は NUMA ノードあたりの物理プロセッサの数を超えないようにする必要があります。

select * from sys.dm_os_tasksクエリを実行して、並列ワーカーの数を監視できます。

この例では、サーバーのハードウェア構成は、24 個のコア プロセッサと 196 GB の RAM を備えた HP Blade G6 でした。 Operations Manager データベースをホストしているインスタンスの MAXMEM 設定は 64 GB でした。 このセクションで推奨される最適化を実行すると、パフォーマンスが向上しました。 ただし、クエリの並列処理のボトルネックは引き続き保持されます。 異なる値をテストした後、MAXDOP=4 を設定することで最も最適なパフォーマンスが見つかりました。

データベースの初期サイズ設定

デプロイ後の最初の数か月以内に、Operations Manager データベース (特に運用データベースとデータ ウェアハウス データベース) の将来の成長を見積もろうとすることは、簡単な演習ではありません。 Operations Manager のサイズ設定ヘルパーは、ラボでのテストから製品グループによって派生した式に基づいて潜在的な成長を推定するのに妥当ですが、いくつかの要因は考慮されません。これは、近い将来と長期的な成長に影響を与える可能性があります。

サイズ設定ヘルパーで提案されているように、初期データベース サイズは、断片化と対応するオーバーヘッドを減らすために予測サイズに割り当てる必要があります。これは、運用データベースと Data Warehouse データベースのセットアップ時に指定できます。 セットアップ中に十分な記憶域領域がない場合は、SQL Management Studio を使用して後でデータベースを拡張し、その後インデックスを再作成して最適化し、それに応じて最適化することができます。 この推奨事項は、ACS データベースにも適用されます。

運用およびデータ ウェアハウス データベースの増加を事前に監視するには、毎日または毎週のサイクルで実行する必要があります。 これは、予期しない重大な増加のスプリアスを特定し、原因を特定するためにトラブルシューティングを開始するために必要です。これは、管理パック ワークフローのバグ (検出ルール、パフォーマンス、イベント収集ルール、監視またはアラート ルールなど) によって、またはリリース管理プロセスのテストおよび品質保証フェーズ中に識別されなかった管理パックのその他の症状を特定するために必要です。

データベースの自動拡張

予約済みデータベースのファイル サイズがいっぱいになると、SQL Server はサイズをパーセンテージまたは固定量で自動的に増やすことができます。 さらに、最大データベース サイズを構成して、ディスク上で使用可能なすべての領域がいっぱいにならないようにすることができます。 既定では、Operations Manager データベースは自動拡張を有効にして構成されていません。データ ウェアハウスと ACS データベースのみが存在します。

予期しない成長のコンティンジェンシーとしてのみ自動拡張に依存します。 自動拡張では、高度なトランザクション データベースを処理するときに考慮する必要があるパフォーマンスの低下が発生します。 パフォーマンスの低下は次のとおりです。

• 適切な増加増分を指定しないと、ログ ファイルまたはデータベースの断片化が発生する可能性があります。
• 使用できるよりも多くのログ領域を必要とするトランザクションを実行し、そのデータベースのトランザクション ログに対して自動拡張が有効になっている場合、トランザクションの完了にかかる時間には、トランザクション ログが構成された量分増加するまでの時間が含まれます。
• ログを拡大する必要がある大きなトランザクションを実行する場合、トランザクション ログへの書き込みを必要とする他のトランザクションも、拡張操作が完了するまで待機する必要があります。

自動拡張オプションと自動圧縮オプションを組み合わせると、不要なオーバーヘッドが発生する可能性があります。 拡大および縮小操作をトリガーするしきい値によって、サイズの変更が頻繁に発生しないようにします。 たとえば、トランザクション ログがコミット時までに 100 MB 増加するトランザクションを実行できます。その後しばらくすると、トランザクション ログが開始され、100 MB 縮小されます。 その後、同じトランザクションを実行すると、トランザクション ログが再び 100 MB 増加します。 この例では、不要なオーバーヘッドを作成し、ログ ファイルの断片化が発生する可能性があり、どちらかがパフォーマンスに悪影響を与える可能性があります。

これら 2 つの設定は慎重に構成してください。 特定の構成は実際には環境によって異なります。 一般的な推奨事項は、ディスクの断片化を減らすために、データベース サイズを固定量増やすことです。 たとえば、次の図を参照してください。自動拡張が必要になるたびに、データベースが 1,024 MB 増加するように構成されています。

クラスター フェールオーバー ポリシー

Windows Server フェールオーバー クラスタリングは、クラスター内のノードのネットワーク接続と正常性を絶えず監視している高可用性プラットフォームです。 ノードがネットワーク経由で到達できない場合は、復旧アクションが実行され、クラスター内の別のノードでアプリケーションとサービスがオンラインになります。 既定の設定は、サーバーが完全に失われ、"ハード" 障害と見なされる障害に最適化されています。 これらは、回復不能なハードウェアや電源の障害などの回復不可能な障害シナリオです。 このような状況では、サーバーが失われ、フェールオーバー クラスタリングがサーバーの損失をすばやく検出し、クラスター内の別のサーバーで迅速に復旧することが目標です。 ハード 障害からのこの高速復旧を実現するために、クラスターの正常性監視の既定の設定はかなり積極的です。 ただし、さまざまなシナリオに柔軟に対応できるように完全に構成できます。

これらの既定の設定は、ほとんどのお客様に最適な動作を提供します。ただし、クラスターがインチから数マイル離れた場所まで拡張されると、ノード間のネットワーク コンポーネントが増え、信頼性が低くなる可能性があります。 もう 1 つの要因は、冗長コンポーネント (デュアル電源、NIC チーミング、マルチパス I/O など) を介した回復性の強化と相まって、コモディティ サーバーの品質が絶えず向上していることです。非冗長なハードウェア障害の数は非常にまれである可能性があります。 ハード 障害の頻度が低い場合があるため、一時的な障害に備えてクラスターを調整したい場合があります。一部のお客様は、ノード間の短いネットワーク障害に対する回復性が高くなります。 既定の障害しきい値を増やすと、短時間続く短いネットワークの問題に対する感度を低下させることができます。

ここでは正しい答えがなく、最適化された設定は、特定のビジネス要件とサービス レベル アグリーメントによって異なる場合があることを理解しておくことが重要です。

SQL Server の仮想化

仮想環境では、パフォーマンス上の理由から、オペレーション データベースとデータ ウェアハウス データベースは、仮想ディスクではなく、直接接続されたストレージに格納することをお勧めします。 Operations Manager 2012 用にリリースされた Operations Manager サイズ変更ヘルパー ユーティリティを使用して、必要な IOPS を見積もり、データ ディスクをストレス テストして検証できます。 ストレージのパフォーマンスは、 DiskSpd ユーティリティを使用してテストできます。 仮想化された Operations Manager 環境に関する追加のガイダンスについては、 Operations Manager 仮想化のサポート も参照してください。

Always On と復旧モデル

厳密には最適化ではありませんが、Always On 可用性グループに関する重要な考慮事項は、設計上、この機能ではデータベースを "完全" 復旧モデルに設定する必要があるという事実です。 つまり、完全バックアップが完了するか、トランザクション ログのみが完了するまで、トランザクション ログは破棄されません。 このため、バックアップ戦略は省略可能ではなく、Operations Manager データベースの AlwaysOn 設計に必要な部分です。 それ以外の場合は、トランザクション ログを含むディスクがいっぱいになります。

バックアップ戦略では、環境の詳細を考慮する必要があります。 一般的なバックアップ スケジュールを次の表に示します。

バックアップの種類	スケジュール
トランザクション ログのみ	1 時間ごと
完全	毎週、日曜日の午前 3:00

SQL Server レポート サービスの最適化

Reporting Services インスタンスは、Data Warehouse データベース内のデータにアクセスするためのプロキシとして機能します。 管理パック内に格納されているテンプレートに基づいてレポートを生成して表示します。

Operations Manager レポート ロールは、以前のバージョンのレポート ロールと並べてインストールすることはできません。また、 must ネイティブ モードでのみインストールできます (SharePoint 統合モードはサポートされていません)。

Reporting Services の背後には、ReportServer データベースと ReportServerTempDB データベースをホストする SQL Server データベース インスタンスがあります。 このインスタンスのパフォーマンス チューニングに関する一般的な推奨事項が適用されます。

次のステップ

ファイアウォールの内側で (レポート) データ ウェアハウスをホストするように構成する方法については、「 ファイアウォールを越えて (レポート) データ ウェアハウスを接続するを参照してください。