管理グループの設計計画

重要

このバージョンの Operations Manager はサポート終了に達しました。 Operations Manager 2022 にアップグレードすることをお勧めします。

概要

管理グループは、単一のオペレーション データベース、1 つ以上の管理サーバー、および 1 つ以上の監視対象エージェントとデバイスで識別されます。 管理グループを接続することで、アラートやその他の監視データを単一のコンソールから表示および編集することができます。 タスクをローカルの管理グループで開始して、接続された管理グループの管理オブジェクト上で実行することもできます。

最も単純な Operations Manager の実装は、単一の管理グループです。 各追加グループには、少なくとも独自のオペレーション データベースと管理サーバーが必要です。 また、独自の構成設定、管理パック、他の監視および ITSM ソリューションとの統合で各グループを個別に維持する必要もあります。

分散管理グループを実装すると、Operations Manager を展開するための基盤が 99% 整います。 これにより、複数のサーバーに機能とサービスを分散でき、一部の機能の拡張性と冗長性が得られます。 すべての Operations Manager サーバーロールを含めることができます。また、ゲートウェイ サーバーを使用して信頼境界を越えたデバイスの監視をサポートします。

次の図は、分散型管理グループ トポロジの構成例です。

注意

オペレーション コンソールとデータベースの間に直接の通信はありません。 すべての通信はポート TCP 5724 を介して特定の管理サーバーに対して行われ、その後、TCP 1433、または SQL Server データベース エンジン インスタンスのセットアップ時に SQL 管理者によって指定されたユーザー定義ポートで OLE DB を使用してデータベース サーバーに対して行われます。 ただし、Application Diagnostics コンソール (Web コンソールと併置) と、運用およびデータ ウェアハウス データベースをホストするSQL Serverとの間には直接通信があります。

環境内に展開した管理グループは 、Microsoft Operations Management Suite (OMS) と統合できます。Log Analytics を利用することで、パフォーマンス、イベント、アラートをさらに関連付け、視覚化し、対処することができます。 これにより、オンプレミスまたはクラウドでホストされているシステムとアプリケーションの間でデータを関連付けるために、データセット全体でカスタム検索を実行できるため、可視性が向上します。

Operations Manager との統合は、BMC Remedy、IBM Netcool または組織で使用されるその他のエンタープライズ管理ソリューションなどの他の製品にまで及びます。 これらのソリューションとの相互運用の計画の詳細については、他の管理ソリューションとの統合に関するトピックを参照してください。

管理グループ コンポーネント

管理サーバー

Operations Manager 2007 では、ルート管理サーバー (RMS) は管理グループの特殊な種類の管理サーバーで、管理グループに最初にインストールされるものでした。 RMS は、管理グループ構成の管理、エージェントの管理と通信、オペレーション データベースと管理グループ内の他のデータベースとの通信を行う起点でした。 また、RMS は、オペレーション コンソールのターゲットと Web コンソールの優先ターゲットとしても機能しました。 System Center 2012 R2 – Operations Manager では、ルート管理サーバーの役割が削除され、すべての管理サーバーが同等になりました。 この構成は引き続き、System Center 2016 以降の Operations Manager に存在します。

以前は RMS だけにホストされていたサービスが、すべての管理サーバーにホストされるため、障害が 1 か所に集中することはなくなりました。 ロールはすべての管理サーバーに分散されます。 1 つの管理サーバーが使用不能になっても、その負荷が自動的に他の管理サーバーに分配されます。 RMS エミュレーター ロールは、RMS をターゲットとする管理パックとの下位互換性を維持するためのものです。 以前に RMS を対象とした管理パックがない場合は、RMS エミュレーターを使用する必要はありません。

機能を強化する場合や、問題発生時の中断を防ぐために、管理グループに複数の管理サーバーを含めることもできます。 1 つの管理グループに 2 つ以上の管理サーバーを追加すると、管理サーバーが自動的に 3 つの既定のリソース プールの一部として機能するようになり、プールの各メンバーに負荷が分散されます。 カスタム定義のリソース プールの場合、メンバーは手動で追加します。 リソース プールのメンバーの 1 つで障害が発生した場合、そのリソース プール内の他のメンバーが、そのメンバーのワークロードを引き継ぎます。 新しい管理サーバーが追加されると、新しい管理サーバーは、リソース プール内の既存のメンバーから一部の作業を自動的に取得します。 リソース プールの設計に関する考慮事項を確認して、その機能と、設計計画に影響を与える推奨事項の詳細を確認します。

管理サーバーが何らかの理由で使用できない場合、既定ではそれに依存しているエージェントは別の管理サーバーに自動的にフェールオーバーします。 管理サーバーの数と配置を選択する際に、高可用性が必要な場合は、このフェールオーバー機能を考慮する必要があります。

エージェントは管理サーバーに接続し、その他のすべての Operations Manager コンポーネントと通信します。 管理サーバーで実行される作業のいくつかは、エージェントが送信するオペレーショナル データを取得し、それをオペレーション データベースとデータ ウェアハウスに挿入するプロセスです。

一般的な管理サーバーでは、約 3,000 のエージェントが処理されます。 実際のサーバーのパフォーマンスは収集されるオペレーショナル データの量によって異なります。ただし、管理サーバーは通常、オペレーショナル データ量が比較的高い場合でもそれぞれ 3,000 のエージェントをサポートできます。

管理グループあたりの管理サーバーの最大数に制限はありません。 ただし、スケーラビリティ、高可用性、ディザスター リカバリーの制約に対処した後は、できるだけ少ない管理サーバーを使用することをお勧めします。

管理サーバーは Operations Manager データベースとデータ ウェアハウスにネットワーク経由で正常に接続できる必要があります。管理サーバーはこれらのストアに大量のデータを頻繁に送信するためです。 一般に、これらの SQL Server 接続は、より多くの帯域幅を消費し、ネットワークの遅延に影響を受けやすくなります。 そのため、すべての管理サーバーは、オペレーション データベースとデータ ウェアハウス データベースと同じローカル エリア ネットワークになければなりません。また、WAN に展開することはできません。 管理サーバーと Operations Manager データベースをホストする SQL Server インスタンス間の待機時間は 10 ミリ秒未満である必要があります。

ゲートウェイ サーバー

Operations Manager では、エージェントと管理サーバーとの間で情報を交換する前に相互認証を実行する必要があります。 これらの間での認証プロセスは、保護のために暗号化されます。 エージェントと管理サーバーが同じ Active Directory ドメイン内に存在する場合、または信頼関係が確立された異なる Active Directory ドメイン内に存在する場合は、Active Directory によって提供される Kerberos V5 認証メカニズムを使用します。 エージェントと管理サーバーが同じ信頼境界内に存在しない場合は、セキュリティで保護された相互認証要件を満たすために他のメカニズムを使用する必要があります。

ゲートウェイ サーバーは、ファイアウォールがエージェントを管理サーバーから分離するとき、またはエージェントが別の信頼されていないドメインにある場合に使用されます。 ゲートウェイ サーバーは、エージェントと管理サーバー間のプロキシとして機能します。 ゲートウェイ サーバーがない場合、エージェントは引き続き管理サーバーで証明書の認証を行いますが、MOMCertImport.exe ツールを使用して各エージェントで X.509 証明書を発行し、インストールする必要があり、ファイアウォールを介して管理サーバーにアクセスする必要があります。 エージェントがゲートウェイ サーバーと同じドメイン内にある場合や、信頼されているドメイン内にある場合は、Kerberos 認証を使用することがあります。 この場合、ゲートウェイ サーバーと接続された管理サーバーにのみ証明書が必要です。 これには、Microsoft Azure サービスとしてのインフラストラクチャ (IaaS) で実行されている仮想マシンの監視、Operations Manager 管理グループをサポートするロールと同じ信頼された領域に参加していない Operations Manager (ハイブリッド クラウド監視)、または Operations Manager を Azure IaaS (SQL Serverを持つ仮想マシン) にデプロイされている仮想マシンの監視が含まれます。管理サーバーの役割をホストする 1 つ以上の仮想マシン) をホストし、信頼されていないオンプレミス ワークロードを監視しています。

Azure IaaS リソースを監視する Operations Manager 展開の例を以下に示します。

Azure IaaS でホストされている Operations Manager の展開例を以下に示します。

通常、ゲートウェイ サーバーは、ゲートウェイ サーバーが使用されているかどうかに関係なく、エージェントから管理サーバーに送信されるデータの全体的な量が似ているため、帯域幅使用率の管理には使用されません。 ゲートウェイ サーバーの目的は、信頼されていないドメイン内のエージェントの証明書の管理に必要な労力を減らし、ファイアウォールを介して許可する必要がある通信パスの数を減らすことです。

• ゲートウェイ サーバーあたり 2,000 を超えるエージェントがあると、ゲートウェイ サーバーが管理サーバーと通信できなくなる継続的な停止が発生した場合に回復する機能に悪影響を与える可能性があります。 2,000 を超えるエージェントが必要な場合は、複数のゲートウェイ サーバーを使用することをお勧めします。 また、ゲートウェイ サーバーの復旧時間が問題である場合は、ゲートウェイ サーバーと管理サーバーの間で継続的な停止が発生した後に、ゲートウェイ サーバーがキューをすばやく空にできることを確認するために、システムをテストします。 また、ゲートウェイ サーバーの受信キューがいっぱいになった場合は、キュー内のデータが優先順位に従って削除されます。これは、このシナリオのゲートウェイ サーバーでの継続的な障害が原因でデータが失われる可能性があることを意味します。
• ゲートウェイ サーバー経由で接続されているエージェントの数が多い場合は、すべてのゲートウェイ サーバーに専用の管理サーバーを使用することを検討してください。 他のエージェントが接続されていない単一の管理サーバーにすべてのゲートウェイ サーバーを接続すると、継続的な停止が発生した場合の復旧時間を短縮できます。 管理サーバーの有効負荷は、直接またはゲートウェイ サーバー経由でレポートされるエージェントの合計数です。
• 高可用性のために複数の管理サーバー間でフェールオーバーするように構成されている場合など、ゲートウェイ サーバーが管理サーバーとの通信を開始しないように、ゲートウェイ承認ツールには /ManagementServerInitiatesConnection コマンド ライン引数が含まれています。 これにより、システムが DMZ に展開されている場合や、他のネットワーク環境と通信がイントラネットからのみ開始できる場合は、Operations Manager がお客様のセキュリティ ポリシーに準拠できます。

Web コンソール サーバー

Web コンソールは、Web ブラウザーを介してアクセス可能なインターフェイスを管理グループに提供します。 オペレーション コンソールの完全な機能は備えされておらず、監視ビューとマイ ワークスペース ビューにのみアクセスできます。 Web コンソールでは、オペレーション コンソールから監視対象コンピューターに対して実行できるアクションである監視タスクと監視データのすべてにアクセスできます。 Web コンソール内のデータへのアクセスには、オペレーション コンソールのコンテンツへのアクセスの場合と同じ制限があります。

レポート サーバー

System Center のレポート – Operations Manager はSQL Server Reporting Servicesにインストールされ (使用している Operations Manager のバージョンでサポートされます)、Operations Manager Reporting でサポートされるReporting Servicesの有効な構成はネイティブ モードのみです。

Note

System Center – Operations Manager Reporting Services をインストールすると、SQL Reporting Services インスタンスのセキュリティと Operations Manager ロール ベース セキュリティが統合されます。 SQL Serverのこの同じインスタンスに他のReporting Services アプリケーションをインストールしないでください。

Operations Manager Report Server コンポーネントは、SQL Server 2014 または 2016 Reporting Services を実行している同じサーバー、または別のコンピューターにインストールできます。 最適なパフォーマンスを得るには、特に、対話型またはスケジュールされたレポートが同時に処理されている間に、ユーザーによる大量の並列レポート生成があるエンタープライズ環境では、より多くの同時実行ユーザーとより大きなレポート実行負荷を処理するためにスケールアップする必要があります。 Operations Manager Reporting サービスは、データ ウェアハウス データベースをホストする同じSQL Serverに併置されておらず、専用システムにインストールすることをお勧めします。

オペレーション データベース

オペレーション データベースは、すべてのオペレーショナル データ、構成情報、および管理グループの監視ルールを保持する SQL Server データベースです。 管理グループの障害の原因となるのは Operations Manager データベースのみです。したがって、サポートされているクラスター構成を使用して可用性を高めることができます。

このデータベースを一貫したサイズに維持するために、Operations Manager のクリーンアップ設定で、データを維持できる時間の長さが指定されます。 既定では、この期間は 7 日です。

レポート データ ウェアハウス データベース

レポート データ ウェアハウスは、長期間のレポート用にオペレーショナル データを収集し、格納する SQL Server データベースです。 このデータは直接、レポートするデータを収集するルールからと、オペレーション データベースでのデータ同期プロセスから書き込まれます。 集計、クリーンアップ、最適化を含め、データ ウェアハウスのメンテナンスは Operations Manager によって自動的に行われます。

次の表に、既定のデータの種類と、データ ウェアハウス データベースの初期セットアップ後の保持期間のみを示します。

データセット	集計の種類	保持期間 (日数)
アラート:	Raw	400
クライアント監視	Raw	30
クライアント監視	毎日	400
イベント	Raw	100
パフォーマンス	Raw	10
パフォーマンス	1 時間ごと	400
パフォーマンス	毎日	400
State	Raw	180
State	1 時間ごと	400
State	毎日	400

1 つのデータ ウェアハウスで複数の管理グループに対応することができます。 これにより、単一のレポートで、組織全体のすべてのコンピューターからデータを取り込むことができます。

Operations Manager データベースと同じように、データ ウェアハウス データベースを高可用性のためにクラスター化することができます。 クラスター化されていない場合は、問題に迅速に対処できるように、慎重に監視する必要があります。

ACS コレクター

ACS コレクターは、ACS フォワーダーからイベントを受信して処理し、このデータを ACS データベースに送信します。 この処理には、ACS データベース内の複数のテーブルに分散できるようにデータを逆アセンブルし、データの冗長性を最小限に抑え、不要なイベントが ACS データベースに追加されないようにフィルターを適用することが含まれます。

ACS データベース

ACS データベースは、ACS 展開内の監査ポリシーによって生成されるイベント用の中央リポジトリです。 ACS データベースは、ACS コレクターと同じコンピューターに配置できますが、パフォーマンスを最大化するためには、それぞれを専用のサーバーにインストールしてください。 既定では、データは 14 日間保持されます。

ACS フォワーダー

ACS フォワーダー上で実行されるサービスは、Operations Manager エージェントに含まれます。 既定では、このサービスはインストールされていますが、Operations Manager エージェントのインストール時は無効になっています。 監査コレクションを有効にするタスクまたは PowerShell を使用すると、このサービスを一度に複数のエージェント コンピューターで有効にすることができます。 このサービスを有効にすると、すべてのセキュリティ イベントは、ローカル セキュリティ ログに加え、ACS コレクターにも送信されます。

設計上の考慮事項

単一または複数の管理グループの実装を決定する際には、次の要因を考慮する必要があります。

• 容量の増加。 Operations Manager には、単一の管理グループでサポートできるエージェントの数に関する制限が設定されていません。 使用するハードウェアと管理グループに対する監視負荷に応じて (展開される管理パックが多いほど、監視負荷が高くなります)、許容可能なパフォーマンスを維持するために複数の管理グループが必要になる場合があります。
• 統合ビュー。 環境を監視するために複数の管理グループが使用されている場合は、それらのグループからの監視データとアラート データの統合ビューを提供するためのメカニズムが必要になります。 これは、他のすべての管理グループ内のすべてのデータにアクセスできる追加の管理グループ (監視担当グループである場合とそうでない場合があります) を展開することで実現できます。 そのため、これらは接続された管理グループと呼ばれます。 データの統合ビューを提供するために使用される管理グループはローカル管理グループと呼ばれ、このグループにデータを提供する他のグループは接続された管理グループと呼ばれます。
• セキュリティと管理。 セキュリティと管理上の理由で管理グループをパーティション分割することは、概念上、Active Directory 組織単位またはドメインに対する管理機関の委任と異なる管理グループに似ています。 企業には複数の IT グループがあり、それぞれに責任の範囲があります。 その範囲は、特定の地理的領域または部署である場合があります。 たとえば、親会社の場合、子会社のいずれかになる場合があります。 一元管理された IT グループからの管理権限のこの種の完全委任は、範囲ごとに管理グループの構造を実装するのに便利な場合があります。 したがって、これらのグループを、一元管理された IT データ センター内のローカル管理グループに接続された管理グループとして構成することができます。
• インストールされている言語。 Operations Manager サーバー ロールがインストールされているサーバーはすべて同じ言語でインストールする必要があります。 つまり、英語版の Operations Manager 2012 R2 を使用して管理サーバーをインストールし、日本語版を使用してオペレーション コンソールを展開することはできません。 複数の言語にまたがる監視が必要な場合は、オペレーターの言語ごとに管理グループを追加する必要があります。
• 運用と運用前の機能。 Operations Manager では、運用アプリケーションの監視に使用される運用実装と、運用環境との対話を最小限に抑えた実稼働前実装を使用することをお勧めします。 運用前管理グループは、運用環境に移行する前に、管理パック機能のテストとチューニングに使用されます。 さらに、一部の企業では、運用に移る前のバーンイン期間に新たに構築されるサーバーが配置されるサーバーのステージング環境が採用されます。 運用前管理グループを使用してステージング環境を監視し、運用ロールアウトの前にサーバーの正常性を確保できます。
• 専用の ACS 機能。 要件に Windows 監査セキュリティ ログ イベントまたは UNIX/Linux セキュリティ イベントを収集する必要がある場合は、監査コレクション サービス (ACS) を実装します。 企業のセキュリティ要件で、運用環境の残りの部分を管理するグループ以外の管理グループによって ACS 機能を制御および管理することが定められている場合は、ACS 機能のみをサポートする管理グループを実装することをお勧めします。
• 障害回復機能。 Operations Manager では、Operations Manager データベースとのすべての対話はデータベースにコミットされる前にトランザクション ログに記録されます。 これらのトランザクション ログは、Microsoft SQL Serverを実行している別のサーバーに送信し、そこで Operations Manager データベースのコピーにコミットできます。 この機能は、同じ管理グループ内の 2 つの SQL Server 間での Operations Manager オペレーション データベースの冗長性を提供するためのオプションです。 制御されたフェールオーバーを実行する必要がある場合、管理グループ内の管理サーバーではレジストリを変更して、セカンダリ SQL Server の参照と通信を行う必要があります。 フェールオーバー管理グループをデプロイできます。これは、プライマリ管理グループの正確な構成 (管理パック、オーバーライド、通知サブスクリプション、セキュリティなど) と一致し、エージェントは両方の管理グループにレポートするように構成されます。 何らかの理由でプライマリ管理グループ全体が使用できなくなった場合、監視環境のダウンタイムはありません。 このソリューションにより、管理グループのサービス継続性が確保され、運用監視が妨げられることはなくなります。

運用環境で System Center Operations Manager を展開する前に、管理グループの設計を計画します。 計画フェーズでは、IT サービス コンポーネント (インフラストラクチャとアプリケーション レベル) と、それらをサポートするシステムとデバイスの数、インシデントと問題の管理プロセスを統合してサポートする方法、さまざまなインシデント エスカレーション サポート レベル、エンジニアリング、サービス コンシューマー、および管理に関するデータを視覚化する方法について理解します。

接続された管理グループ

複数の地理的な場所にあるサーバーを持つ多くの企業では、それらのサーバーの集中監視が必要になります。 下図に示されている接続された管理グループ構成は、階層システム管理インフラストラクチャを作成するために設計された一連のワークフロー プロセスです。

この構成を使用して、集中監視を実現できます。 これは、アラートと監視データの表示をサポートし、接続された管理グループのマネージド オブジェクトに対してタスクを開始するように設計されています。

Operations Manager 管理グループを接続することによって、次の機能を有効にしながら、集中監視機能を維持することができます。

• 1 つの管理グループより多くの管理オブジェクトを監視できます。
• 論理的な事業単位 ("マーケティング" など) や物理的な場所 (ローマなど) による、監視操作の切り分け。

管理グループに接続する場合、新しいサーバーは展開されません。代わりに、ローカル管理グループが、接続された管理グループ内のアラートと検出情報にアクセスできるようにします。 ここの方法では、単一のオペレーション コンソールの複数の管理グループからすべてのアラートおよびその他の監視データを表示および操作できます。 さらに、接続された管理グループの監視対象コンピューターのタスクを実行することもできます。 管理グループの接続に関する詳細については、「Operations Manager の管理グループの接続」を参照してください。

インストールされている言語

Operations Manager の管理グループでサポートされるのは、インストールされている 1 つの言語のみです。 モニターする必要のある IT 環境全体に複数の言語がインストールされている場合は、各言語にそれぞれ 1 つの管理グループが必要となります。