次の方法で共有

Planning a Management Group Design

  • [アーティクル]

概要

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

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

MG 単一サーバーの例の図。

分散管理グループの実装は、Operations Manager デプロイの 99% の基盤となります。 これにより、複数のサーバー間で機能とサービスを分散して、それらの機能の一部のスケーラビリティと冗長性を実現できます。 すべての Operations Manager サーバーの役割を含めることができます。また、ゲートウェイ サーバーを使用して、信頼境界を越えたデバイスの監視をサポートします。

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

OM 分散 MG の例の図。

Note

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

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

OM と Microsoft OMS の統合の図。

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

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

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

エージェントは管理サーバーに接続して、他のすべての Operations Manager コンポーネントと通信します。 管理サーバーによって実行される作業の一部は、エージェントによって送信された運用データを取得し、運用データベースとデータ ウェアハウスに挿入するプロセスです。

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

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

管理サーバーは、多くの場合、これらのストアに大量のデータを送信するため、Operations Manager データベースとデータ ウェアハウスに適切なネットワーク接続が必要です。 一般に、これらの SQL Server 接続はより多くの帯域幅を消費し、ネットワーク待機時間の影響を受けやすくなります。 そのため、すべての管理サーバーは、オペレーション データベースと Data Warehouse データベースと同じローカル エリア ネットワーク上にあり、ワイド エリア ネットワークにデプロイされることはありません。 Operations Manager データベースをホストしている管理サーバーと SQL Server インスタンスの間には、10 ミリ秒未満の待機時間が必要です。

ゲートウェイ サーバー

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

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

次に、Azure IaaS リソースを監視する Operations Manager デプロイの例を示します。
Azure リソースを監視する OpsMgr の図。

Azure IaaS でホストされている Operations Manager デプロイの例を次に示します。
Azure Iaas でホストされている OpsMgr の図。

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

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

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

運用データベースは、管理グループのすべての運用データ、構成情報、および監視規則を保持する SQL Server データベースです。 Operations Manager データベースは、管理グループの単一障害原因であるため、サポートされているクラスタリング構成を使用して高可用性を実現できます。

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

Reporting Data Warehouse データベース

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

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

データセット 集計の種類 保有期間 (日数)
アラート 直接 400
クライアントの監視 直接 30
クライアントの監視 毎日 400
Events 直接 100
パフォーマンス 直接 10
パフォーマンス 1 時間ごと 400
パフォーマンス 毎日 400
都道府県 直接 180
都道府県 1 時間ごと 400
都道府県 毎日 400

データ ウェアハウスは、複数の管理グループにサービスを提供できます。 これにより、1 つのレポートに組織全体のすべてのコンピューターのデータを組み込むことができます。

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

ACS コレクター

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

ACS データベース

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

ACS フォワーダー

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

設計上の考慮事項

1 つまたは複数の管理グループを実装する場合は、次の要因を考慮する必要があります。

  • 容量の増加。 Operations Manager には、1 つの管理グループでサポートできるエージェントの数に関する組み込みの制限はありません。 使用するハードウェアと、管理グループの監視負荷 (展開される管理パックが増えるほど監視負荷が高いことを意味) によっては、許容されるパフォーマンスを維持するために複数の管理グループが必要になる場合があります。
  • 統合ビュー。 複数の管理グループを使用して環境を監視する場合、監視データとアラート データを統合して表示するメカニズムが必要です。 これを実現するには、他のすべての管理グループ内のすべてのデータにアクセスできる追加の管理グループ (監視の責任がある場合とない場合があります) を展開します。 その後、これらの管理グループは接続されていると言われます。 データの統合ビューを提供するために使用される管理グループはローカル管理グループと呼ばれ、データを提供する他のグループは接続管理グループと呼ばれます。
  • セキュリティと管理。 セキュリティ上および管理上の理由から管理グループをパーティション分割することは、概念上、Active Directory 組織単位またはドメインに対する管理権限を異なる管理グループに委任する場合と似ています。 会社には複数の IT グループが含まれている場合があります。それぞれに独自の責任領域があります。 この領域は、特定の地理的領域またはビジネス部門である可能性があります。 たとえば、持株会社の場合は、子会社の 1 つにすることができます。 この種の一元化された 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 つの管理グループが必要となります。