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

重要

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

リソース プールは、複数の管理サーバーまたはゲートウェイ サーバーの論理的な集まりで、これらのサーバーで負荷を分散し、他のサーバーで問題が発生した場合に負荷を引き継ぎます。 つまり、ワークフローに高可用性と拡張性を提供します。 管理グループを設計する場合、ネットワーク デバイス、Linux または UNIX システム、およびリソース プールを活用するために設計されるその他のワークロードの監視を考慮する必要があります。

概要

リソース プールに複数の "メンバー" (管理サーバーまたはゲートウェイ サーバー) を提供することで、プールのメンバーの 1 つが利用不可になった場合でも、代わりのメンバーがワークフローの監視を引き続き行い、監視が確実に続行されます。 リソース プールは、特定の目的のために作成することができます。 たとえば、ネットワーク デバイスを監視するために、プライマリ データ センターに管理サーバーのリソース プールを作成することがあります。

リソース プールでは、(<プールのメンバーとしてのノード数> /2) + 1 の “ほとんどのノード セット” をクラスタリングするのと同様の論理を適用します。 クォーラムを維持するにはプールに少なくとも 3 つのメンバーが存在する必要があり、プールの可用性を維持するにはプール内のクォーラム投票メンバーの 50% より多くが必要です。 プールのメンバーが 2 人しかおり、1 つを使用できない場合は、クォーラムが失われます。

オペレーション コンソールで作成されたすべてのリソース プールに対して、 既定のオブザーバーと呼ばれる Operations Manager データベースには、クォーラムへの到達を許可するメンバーがプール内に偶数である場合でも、常に投票が行われます。 これは、最初に管理グループを作成するときに既定で作成される 3 つのリソース プールにも適用されます。これについては、この記事で後述します。 PowerShell コマンドレット NewSCOM-ResourcePool を使って作成されるすべてのリソース プールについては、既定で無効に設定されます。 Operations Manager データベースを "既定のオブザーバー" として含めると、リソース プールの高可用性を維持するために展開する必要のある管理サーバーは少なくとも 2 つになるため、管理グループの複雑さが軽減されます。

リソース プールをサポートするもう 1 つのロールは "オブザーバー" です。 これは、プールのワークフローの読み込みに参加しない管理サーバーまたはゲートウェイ サーバーです。ただし、クォーラムの決定に参加します。 これは通常の状況では使われないので、考慮する必要はありません。

メンバーシップには次の 2 種類があります。

• 自動
• マニュアル

リソース プールを作成する場合、そのメンバーシップは手動に設定され、自動に再構成することはできません。 System Center - Operations Manager 管理グループが作成されると、自動のメンバーシップと共に、既定で 3 つのリソース プールが作成されます。 次の表では、3 つのリソース プールについて説明します。

リソース プール名	説明
すべての管理サーバーのリソース プール	グループの計算、可用性、分散されたモニター ヘルス ロールアップ、およびデータベースのクリーンアップのワークフローを実行します。
通知のリソース プール	アラート配信サービスのワークフローは、アラート通知をサポートするために、このリソース プールを対象とします。
AD 割り当てのリソース プール	AD 統合のワークフローは、管理サーバーへのエージェントの自動割り当てをサポートするために、このリソース プールを対象にします。

すべての管理サーバー リソース プールのメンバーシップは自動であるため、権限を与えられた管理サーバーは、自動的にこのリソース プールのメンバーになります。 地理的に分散している、障害時対応が組み込まれている特定のアーキテクチャおよび設計では、すべての管理サーバーのリソース プールに自動で割り当てを行うことは望ましくありません。 このような状況では、メンバーシップの割り当てを自動から手動に変更することができます。 そのような場合、管理サーバーは、手動の割り当てによってすべての管理サーバー リソース プールに追加する必要があります。

Note

[すべての管理サーバー リソース プール] のメンバーは読み取り専用です。 メンバーシップを自動から手動に変更するには、「リソース プールのメンバーを変更する」をご覧ください。

リソース プールの導入により、すべてのメンバーが待機時間の短いネットワーク (10 ミリ秒未満) で接続することをお勧めします。 リソース プールは、複数のデータ センターにデプロイしたり、Microsoft Azure などのハイブリッド クラウド環境にデプロイしたりしないでください。

リソース プールの可用性の例

以下の例では、管理サーバーだけ、またはゲートウェイ サーバーだけの構成に基づいて、リソース プールの可用性の概念を示します。

管理サーバーが 1 つ

• "既定のオブザーバー" は既定で有効になりますが、メンバーが 2 つだけでクォーラムに達しないので、メリットはありません。
• 管理サーバーは単一障害点であるため、高可用性はありません。

管理サーバーが 2 つ

• "既定のオブザーバー" は既定で有効になります。
• プールの高可用性は、3 つの投票メンバー (2 つの管理サーバーと 既定のオブザーバー) があるためです。
• "既定のオブザーバー" を無効にした場合、プールの高可用性は失われます。

管理サーバーが 3 つ

• "既定のオブザーバー" は既定で有効になります。
• プールには高可用性があります。4 つの投票メンバー (3 つの管理サーバーと 既定のオブザーバー) があるためです。
• 既定では、使用できなくなってもクォーラムを維持できる管理サーバーは 1 つだけです。 2 つの管理サーバーが使用できない場合は、投票メンバーの 50% が存在し、リソース プールは監視ワークロードを管理するために機能しなくなります。
• "既定のオブザーバー" があっても、ダウンしてもよい管理サーバーの数は増えないので、プールの可用性は高くなりません。
• このシナリオでは、"既定のオブザーバー" の削除を検討してもかまいません。

管理サーバーが 4 つ

• "既定のオブザーバー" は既定で有効になります。
• プールには高可用性があります。5 つの投票メンバー (4 つの管理サーバーと 既定のオブザーバー) があるためです。
• 既定では、使用できなくなってもクォーラムを維持できる管理サーバーは 2 つだけです。 3 台の管理サーバーがダウンしている場合、投票メンバーの 50% 未満になり、リソース プールは監視ワークロードを管理するために機能しなくなります。
• このシナリオでの "既定のオブザーバー" は、ダウンしてもかまわない管理サーバーの数が増えるため、重要な価値を提供します。 "既定のオブザーバー" がないと、クォーラム メンバーは 4 つだけになり、使用できなくなってもかまわないメンバーは 1 つだけです。

管理サーバーが 5 つ

• "既定のオブザーバー" は既定で有効になります。
• 6 つの投票メンバー (5 つの管理サーバーと 既定のオブザーバー) があるため、プールの高可用性があります。
• 既定では、使用できなくなってもクォーラムを維持できる管理サーバーは 2 つだけです。 3 つの管理サーバーが使用できなくなると、投票メンバーはちょうど 50% になり、リソース プールによる監視ワークロードの管理は機能しなくなります。
• "既定のオブザーバー" があっても、ダウンしてもよい管理サーバーの数は増えないので、プールの可用性は高くなりません。
• このシナリオでは、"既定のオブザーバー" の削除を検討してもかまいません。

リソース プール内の 3 つ以上の管理サーバー (プール内に奇数のメンバーがある) に到達したら、 既定のオブザーバー をメンバーとして削除することを検討できます。 5 台の管理サーバーに達すると、運用データベースで大量の負荷が発生する可能性があるため、リソース プールの計算に影響を与えるのに十分な待機時間が発生する可能性があります。

"既定のオブザーバー" の動作方法では、プール内の各管理サーバーは独自のローカル SDK サービスに対して照会を行い、"既定のオブザーバー" 用のオペレーション データベース内のテーブルを照会できます。 SDK サービスまたはデータベースに負荷がかかると、それ以外の場合には存在しない遅延が発生します。

ゲートウェイ サーバーが 1 つ

• "既定のオブザーバー" は既定で有効になります。
• ゲートウェイ サーバーは単一障害点であるため、高可用性はありません。
• ゲートウェイ サーバーにはローカル SDK サービスがないため、運用データベースに対してクエリを実行できないため、 ここでは既定のオブザーバー を使用しないでください。

ゲートウェイ サーバーが 2 つ

• "既定のオブザーバー" は既定で有効になります。
• ゲートウェイ サーバーが運用データベースと直接通信しないため、プールのメンバーは 2 人しかなく、 既定のオブザーバー は参加要素ではないので、高可用性はありません。 プールのクォーラムを維持するためには、3 つのゲートウェイ サーバーが必要です。

ゲートウェイ サーバーが 3 つ

• "既定のオブザーバー" は既定で有効になります。
• 3 つの投票メンバー (3 つのゲートウェイ サーバー) があるため、プールの高可用性があります。
• 既定では、クォーラムを維持するために使用できないゲートウェイ サーバーは 1 つだけです。 2 つのゲートウェイ サーバーがダウンすると、投票メンバーは 50% より少なくなり、リソース プールによる監視ワークロードの管理は機能しなくなります。
• ゲートウェイ サーバーにはローカル SDK サービスがないため、運用データベースに対してクエリを実行できないため、 ここでは既定のオブザーバー を使用しないでください。

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

次のワークフローは、Operations Manager のリソース プールによってホストされます。

• ネットワーク デバイスの管理
• UNIX または Linux エージェントの管理
• Web アプリケーション URL の監視

Note

Windows エージェントは、リソース プールに報告しません。

Operations Manager でのネットワーク監視には、独自の専用リソース プールが必要です。 これは、ネットワークの監視ワークフローが、エージェントではなく、管理サーバー (SNMP モジュール) 上で実行されるためです。 特にデバイスで利用可能なほとんどのアクティブなポートを選択した場合、ネットワーク ポートの監視を含めると、管理サーバーに大きな負荷がかかります。 そのため、パフォーマンスの向上を図るために、ネットワークの監視には、専用のリソース プールに含まれている専用の管理サーバーを使用してください。 また、このプールのメンバーである管理サーバーは、すべての管理サーバー、通知、および AD 割り当てプールから削除する必要があります。

Operations Manager での Linux または UNIX の監視は、必要に応じて専用リソース プールに割り当て、高可用性の監視とエージェントの管理を有効にすることができますが、必須ではありません。 Operations Manager は、管理しているコンピューターへのアクセスを認証するために証明書を使用します。 検出ウィザードがエージェントを展開するときに、エージェントから証明書を取得して署名し、証明書をエージェントに戻して展開してから、エージェントを再開します。 高可用性をサポートする場合、リソース プール内の各管理サーバーは、UNIX および Linux コンピューターのエージェントに展開されている証明書の署名に使用するルート証明書をすべて保有している必要があります。 そうしないと、管理サーバーが使用できなくなった場合、他の管理サーバーは、失敗したサーバーによって署名された証明書を信頼できなくなります。

次の手順

リソース プールを作成して管理する方法については、「リソース プールを管理する方法」をご覧ください。