リソース プールの設計に関する考慮事項Resource pool design considerations

重要

このバージョンの Operations Manager はサポート終了に達したので、Operations Manager 2019 にアップグレードすることをお勧めします。This version of Operations Manager has reached the end of support, we recommend you to upgrade to Operations Manager 2019.

リソース プールは、複数の管理サーバーまたはゲートウェイ サーバーの論理的な集まりで、これらのサーバーで負荷を分散し、他のサーバーで問題が発生した場合に負荷を引き継ぎます。A Resource Pool is a logical grouping of management servers and/or gateway servers used to distribute work among themselves and take over work from a failed member. つまり、ワークフローに高可用性と拡張性を提供します。In other words, they provide high availability and scalability for workflows. 管理グループを設計する場合、ネットワーク デバイス、Linux または UNIX システム、およびリソース プールを活用するために設計されるその他のワークロードの監視を考慮する必要があります。When designing a management group, considerations must be made for monitoring of network devices, Linux/UNIX systems, and other workloads that are designed to take advantage of a resource pool.

概要Overview

リソース プールに複数の "メンバー" (管理サーバーまたはゲートウェイ サーバー) を提供することで、プールのメンバーの 1 つが利用不可になった場合でも、代わりのメンバーがワークフローの監視を引き続き行い、監視が確実に続行されます。Resource pools ensure the continuity of monitoring by providing multiple members, which are management servers and/or gateway servers that can take over monitoring workflows if one of the members of the pool becomes unavailable. リソース プールは、特定の目的のために作成することができます。You can create resource pools for specific purposes. たとえば、ネットワーク デバイスを監視するために、プライマリ データ センターに管理サーバーのリソース プールを作成することがあります。For example, you might create a resource pool of management servers in your primary data center to monitor network devices.

リソース プールでは、(<プールのメンバーとしてのノード数> /2) + 1 の “ほとんどのノード セット” をクラスタリングするのと同様の論理を適用します。Resource pools apply a logic similar to clustering “majority node set”, where (< number of nodes as members of the pool > /2) + 1. クォーラムを維持するにはプールに少なくとも 3 つのメンバーが存在する必要があり、プールの可用性を維持するにはプール内のクォーラム投票メンバーの 50% より多くが必要です。At a minimum, there must be three members in the pool to maintain quorum, which must be more than 50% of the quorum voting members in a pool to maintain availability of the pool. プールのメンバーが 2 つだけの場合、そのうちの 1 つが利用できなくなると、クォーラムは失われます。If you only have two members of the pool, and one is unavailable, you have lost quorum.

オペレーション コンソールで作成されるすべてのリソース プールについては、プール内のメンバーの数が偶数であっても、クォーラムに達することができるように、Operations Manager データベース ("既定のオブザーバー" と呼ばれます) には常に投票権が与えられます。For every resource pool created in the Operations console, the Operations Manager database, which is referred to as the default observer, is always given a vote, even if you have an even number of members in the pool to allow quorum to be reached. これは、管理グループを最初に作成するときに既定で作成される 3 つのリソース プールにも当てはまります。これについては後で説明します。This also applies to the three resource pools created by default when you first create the management group, which is discussed later in this topic. PowerShell コマンドレット NewSCOM-ResourcePool を使って作成されるすべてのリソース プールについては、既定で無効に設定されます。For all resource pools created using the PowerShell cmdlet NewSCOM-ResourcePool, it's set to disabled by default. Operations Manager データベースを "既定のオブザーバー" として含めると、リソース プールの高可用性を維持するために展開する必要のある管理サーバーは少なくとも 2 つになるため、管理グループの複雑さが軽減されます。Including the Operations Manager database as the default observer reduces complexity of your management group by only requiring you to deploy two management servers at a minimum to maintain high availability of your resource pools.

リソース プールをサポートするもう 1 つのロールは "オブザーバー" です。Another role supporting a resource pool are Observers. これは、プールのワークフローの読み込みには関与しない管理サーバーまたはゲートウェイ サーバーです。ただし、クォーラムの決定には参加します。This is a management server or a Gateway server that doesn't participate in loading workflows for the pool; however they participate in quorum decisions.  これは通常の状況では使われないので、考慮する必要はありません。  This is never used under normal circumstances, and therefore shouldn't be considered.

メンバーシップには、自動と手動の 2 種類があります。There are two types of membership, automatic and manual. リソース プールを作成する場合、そのメンバーシップは手動に設定され、自動に再構成することはできません。When you create a resource pool, its membership is set to manual and can't be reconfigured to automatic. System Center - Operations Manager 管理グループが作成されると、自動のメンバーシップと共に、既定で 3 つのリソース プールが作成されます。When a System Center – Operations Manager management group is created, three resource pools are created by default with automatic membership. 次の表では、3 つのリソース プールについて説明します。The following table describes these three resource pools.

リソース プール名Resource Pool Name [説明]Description
すべての管理サーバーのリソース プールAll Management Servers Resource Pool グループの計算、可用性、分散されたモニター ヘルス ロールアップ、およびデータベースのクリーンアップのワークフローを実行します。Performs workflows for group calculation, availability, distributed monitor health rollup, and database grooming.
通知のリソース プールNotifications Resource Pool アラート配信サービスのワークフローは、アラート通知をサポートするために、このリソース プールを対象とします。The Alert Subscription Service workflows are targeted to this Resource Pool to support alert notifications.
AD 割り当てのリソース プールAD Assignment Resource Pool AD 統合のワークフローは、管理サーバーへのエージェントの自動割り当てをサポートするために、このリソース プールを対象にします。The AD Integration workflows are targeted to this Resource Pool to support automatic agent assignment to management servers.

すべての管理サーバー リソース プールのメンバーシップは自動であるため、権限を与えられた管理サーバーは、自動的にこのリソース プールのメンバーになります。Because membership of the All Management Servers Resource Pool is automatic, any management server that is commissioned is automatically made a member of this resource pool. 地理的に分散した危機管理操作など、特定のアーキテクチャおよび設計に関する考慮事項で、すべての管理サーバー リソース プールへの自動割り当てを要求されることはありません。In certain architectures and design considerations, such as those incorporating geographically dispersed contingency operations, automatic assignment to the All Management Servers Resource Pool may not be desired. このような状況では、メンバーシップの割り当てを自動から手動に変更することができます。In these situations, it's possible to change the membership assignment from automatic to manual. そのような場合、管理サーバーは、手動の割り当てによってすべての管理サーバー リソース プールに追加する必要があります。As such, management servers must be added to the All Management Servers Resource Pool through manual assignment.

注意

[すべての管理サーバー リソース プール] のメンバーは読み取り専用です。The membership of the All Management Servers Resource Pool is read-only. メンバーシップを自動から手動に変更するには、「リソース プールのメンバーを変更する」をご覧ください。To change its membership from automatic to manual, see Modifying Pool Membership.

リソース プールを使用する関係上、すべてのメンバーを低遅延のネットワーク (10 ミリ秒未満) で接続することをお勧めします。With the introduction of resource pools, it is recommended that all members are connected by a low latency network (less than 10 ms). リソース プールは、複数のデータ センターまたは Microsoft Azure などのハイブリッド クラウド環境に展開しないでください。Resource pools should not be deployed across multiple data centers or in a hybrid-cloud environment like Microsoft Azure.

リソース プールの可用性の例Resource Pool availability examples

以下の例では、管理サーバーだけ、またはゲートウェイ サーバーだけの構成に基づいて、リソース プールの可用性の概念を示します。The following examples demonstrate the concept of resource pool availability based on the following configurations, only with management servers or only with Gateway servers.

管理サーバーが 1 つSingle management server

  • "既定のオブザーバー" は既定で有効になりますが、メンバーが 2 つだけでクォーラムに達しないので、メリットはありません。The default observer is enabled by default and provides no benefit since there are only two members and quorum isn't reached.
  • 管理サーバーが単一障害点であるため、高可用性はありません。There is no high availability, because the management server is a single point of failure.

管理サーバーが 2 つTwo management servers

  • "既定のオブザーバー" は既定で有効になります。The default observer is enabled by default.
  • 投票メンバーが 3 つ (2 つの管理サーバーと "既定のオブザーバー") なので、プールには高可用性があります。There is high availability for the pool, because there are three voting members - two management servers and the default observer.
  • "既定のオブザーバー" を無効にした場合、プールの高可用性は失われます。If you disable the default observer, you'll lose high availability for the pool.

管理サーバーが 3 つThree management servers

  • "既定のオブザーバー" は既定で有効になります。The default observer is enabled by default.
  • 投票メンバーが 4 つ (3 つの管理サーバーと既定のオブザーバー) なので、プールには高可用性があります。There is high availability for the pool, because there are four voting members - three management serves and the default observer.
  • 既定では、使用できなくなってもクォーラムを維持できる管理サーバーは 1 つだけです。By default you can only have one management server unavailable to maintain quorum. 2 つの管理サーバーが使用できなくなると、投票メンバーはちょうど 50% になり、リソース プールによる監視ワークロードの管理は機能しなくなります。If two management servers are unavailable, you have exactly 50% of voting members and the resource pool no longer functions to manage the monitoring workloads.
  • "既定のオブザーバー" があっても、ダウンしてもよい管理サーバーの数は増えないので、プールの可用性は高くなりません。The default observer doesn't increase the number of management servers that can be down, therefore it doesn't increase pool availability.
  • このシナリオでは、"既定のオブザーバー" の削除を検討してもかまいません。You can consider removing the default observer in this scenario.

管理サーバーが 4 つFour management servers

  • "既定のオブザーバー" は既定で有効になります。The default observer is enabled by default.
  • 投票メンバーが 4 つ (3 つの管理サーバーと "既定のオブザーバー") なので、プールには高可用性があります。There is high availability for the pool, because there are five voting members - four management servers and the default observer.
  • 既定では、使用できなくなってもクォーラムを維持できる管理サーバーは 2 つだけです。By default you can only have two management server unavailable to maintain quorum. 3 つの管理サーバーがダウンすると、投票メンバーは 50% より少なくなり、リソース プールによる監視ワークロードの管理は機能しなくなります。If three management servers are down, you have less than 50% of voting members and the resource pool no longer functions to manage the monitoring workloads.
  • このシナリオでの "既定のオブザーバー" は、ダウンしてもかまわない管理サーバーの数が増えるため、重要な価値を提供します。The default observer in this scenario provides significant value, because it increases the number of management servers that can be down. "既定のオブザーバー" がないと、クォーラム メンバーは 4 つだけになり、使用できなくなってもかまわないメンバーは 1 つだけです。Without the default observer, you would only have four quorum members, which only allows for one member to be unavailable.

管理サーバーが 5 つFive management servers

  • "既定のオブザーバー" は既定で有効になります。The default observer is enabled by default.
  • 投票メンバーが 5 つ (4 つの管理サーバーと既定のオブザーバー) なので、プールには高可用性があります。There is high availability for the pool, because there are six voting members - five management servers and the default observer.
  • 既定では、使用できなくなってもクォーラムを維持できる管理サーバーは 2 つだけです。By default you can only have two management servers unavailable to maintain quorum. 3 つの管理サーバーが使用できなくなると、投票メンバーはちょうど 50% になり、リソース プールによる監視ワークロードの管理は機能しなくなります。If three management servers are unavailable, this is exactly 50% of voting members, and the resource pool no longer functions to manage the monitoring workloads.
  • "既定のオブザーバー" があっても、ダウンしてもよい管理サーバーの数は増えないので、プールの可用性は高くなりません。The default observer doesn't increase the number of management servers that can be down, therefore it doesn't increase pool availability.
  • このシナリオでは、"既定のオブザーバー" の削除を検討してもかまいません。You can consider removing the default observer in this scenario.

リソース プール内の管理サーバーの数が 3 以上の奇数の場合、メンバーとしての "既定のオブザーバー" の削除を考慮できます。Once you reach three or more management servers in a resource pool, where you have an odd number of members in the pool, you can consider removing the default observer as a member. 管理サーバーが 5 つになると、オペレーション データベースの負荷が大きくなり、リソース プールの計算に影響を与えるほどの遅延が発生する可能性があります。If you reach five management servers, there is the potential for the Operational database to experience significant load, which might generate enough latency to affect resource pool calculations.

"既定のオブザーバー" の動作方法では、プール内の各管理サーバーは独自のローカル SDK サービスに対して照会を行い、"既定のオブザーバー" 用のオペレーション データベース内のテーブルを照会できます。With the way the default observer plays a role, each management server in the pool queries its own local SDK service, which allows it to query a table in the Operational database for the default observer. SDK サービスまたはデータベースに負荷がかかると、それ以外の場合には存在しない遅延が発生します。If the SDK service or database is under a load, you'll experience latency that would otherwise not exist.

ゲートウェイ サーバーが 1 つSingle Gateway server

  • "既定のオブザーバー" は既定で有効になります。The default observer is enabled by default.
  • ゲートウェイ サーバーが単一障害点であるため、高可用性はありません。There is no high availability because the Gateway server is a single point of failure.
  • ゲートウェイ サーバーにはローカル SDK サービスがなく、オペレーション データベースを照会できないため、この場合は "既定のオブザーバー" を使うことはできません。The default observer should not be used here because Gateway servers don't have a local SDK service and therefore can't query the Operational database.

ゲートウェイ サーバーが 2 つTwo Gateway servers

  • "既定のオブザーバー" は既定で有効になります。The default observer is enabled by default.
  • ゲートウェイ サーバーはオペレーション データベースと直接通信しないために "既定のオブザーバー" は参加せず、プールのメンバーは 2 つだけなので、高可用性はありません。There is no high availability because there are only two members of the pool and the default observer isn't a participant because Gateway servers don't directly communicate with the Operational database. プールのクォーラムを維持するためには、3 つのゲートウェイ サーバーが必要です。Three Gateway servers are required to maintain pool quorum.

ゲートウェイ サーバーが 3 つThree Gateway servers

  • "既定のオブザーバー" は既定で有効になります。The default observer is enabled by default.
  • 投票メンバーが 3 つ (3 つのゲートウェイ サーバー) なので、プールには高可用性があります。There is high availability for the pool, because there are three voting members - three Gateway servers.
  • 既定では、使用できなくなってもクォーラムを維持できるゲートウェイ サーバーの数は 1 つだけです。By default you can only have one Gateway server unavailable to maintain to maintain quorum. 2 つのゲートウェイ サーバーがダウンすると、投票メンバーは 50% より少なくなり、リソース プールによる監視ワークロードの管理は機能しなくなります。If two Gateway servers are down, this is less than 50% of voting members, and the resource pool no longer functions to manage the monitoring workloads.
  • ゲートウェイ サーバーにはローカル SDK サービスがなく、オペレーション データベースを照会できないため、この場合は "既定のオブザーバー" を使うことはできません。The default observer should not be used here because Gateway servers don't have a local SDK service and therefore can't query the Operational database.

リソース プールをサポートしているシナリオの監視Monitoring scenarios supporting resource pools

次のワークフローは、Operations Manager のリソース プールによってホストされます。The following workflows are hosted by resource pools in Operations Manager:

  • ネットワーク デバイスの管理Management of network devices
  • UNIX または Linux エージェントの管理Management of UNIX/Linux agents
  • Web アプリケーション URL の監視Monitoring web application URLs

注意

Windows エージェントは、リソース プールに報告しません。Windows agents don't report to resource pools.

Operations Manager でのネットワーク監視には、独自の専用リソース プールが必要です。Network monitoring in Operations Manager requires its own separate, dedicated resource pool. これは、ネットワークの監視ワークフローが、エージェントではなく、管理サーバー (SNMP モジュール) 上で実行されるためです。This is because network monitoring workflows run on management servers (on the SNMP module) and not on agents. 特にデバイスで利用可能なほとんどのアクティブなポートを選択した場合、ネットワーク ポートの監視を含めると、管理サーバーに大きな負荷がかかります。This places a heavy load on the management servers once you include monitoring of network ports, especially if you select most of the active ports available on the device. そのため、パフォーマンスの向上を図るために、ネットワークの監視には、専用のリソース プールに含まれている専用の管理サーバーを使用してください。Therefore, for better performance, we recommend using dedicated management servers in dedicated resource pools for network monitoring. また、このプールのメンバーである管理サーバーは、すべての管理サーバー、通知、および AD 割り当てプールから削除する必要があります。Additionally, the management servers that are members of this pool should be removed from the All Management Servers, Notifications, and AD Assignment pools.

Operations Manager での Linux または UNIX の監視は、必要に応じて専用リソース プールに割り当て、高可用性の監視とエージェントの管理を有効にすることができますが、必須ではありません。Linux/UNIX monitoring in Operations Manager can be assigned to a dedicated resource pool if necessary to enable high-availability monitoring and agent management, but isn't required. Operations Manager は、管理対象のコンピューターへのアクセスの認証に証明書を使用します。Operations Manager uses certificates to authenticate access to the computers it is managing. 検出ウィザードがエージェントを展開するときに、エージェントから証明書を取得して署名し、証明書をエージェントに戻して展開してから、エージェントを再開します。When the Discovery Wizard deploys an agent, it retrieves the certificate from the agent, signs the certificate, deploys the certificate back to the agent, and then restarts the agent. 高可用性をサポートする場合、リソース プール内の各管理サーバーは、UNIX および Linux コンピューターのエージェントに展開されている証明書の署名に使用するルート証明書をすべて保有している必要があります。To support high availability, each management server in the resource pool must have all the root certificates that are used to sign the certificates that are deployed to the agents on the UNIX and Linux computers. そうしないと、管理サーバーが利用できなくなった場合に、障害が発生したサーバーによって署名された証明書を他の管理サーバーが信頼できなくなります。Otherwise, if a management server becomes unavailable, the other management servers would not be able to trust the certificates that were signed by the server that failed.

次のステップNext steps

リソース プールを作成して管理する方法については、「リソース プールを管理する方法」をご覧ください。To learn how to create and manage resource pools, see How to manage resource pools.