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

リソース プールとは、管理サーバーやゲートウェイ サーバーを論理的にグループ化したものであり、サーバー間で作業を分散し、障害が発生したメンバーから作業を引き継ぐのに使用されます。 つまり、ワークフローに高可用性とスケーラビリティをもたらします。 管理グループを設計するときは、ネットワーク デバイス、Linux/UNIX システム、そしてリソース プールを活用するように設計されたその他のワークロードの監視について考慮する必要があります。

概要

リソース プールは、複数の メンバーを提供することで監視の継続性を確保します。管理サーバーやゲートウェイ サーバーは、プールのメンバーの 1 つが使用できなくなった場合に監視ワークフローを引き継ぐ可能性があります。 リソース プールは、特定の目的のために作成することができます。 たとえば、ネットワーク デバイスを監視するために、プライマリ データ センターに管理サーバーのリソース プールを作成できます。

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

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

リソース プールをサポートするもう 1 つのロールは、 Observers です。 これは、プールのワークフローの読み込みに関与しない管理サーバーまたはゲートウェイ サーバーです。ただし、クォーラムの決定に参加します。 これは通常の状況では使用されないため、考慮しないでください。

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

• 自動
• 手動

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

すべての管理サーバー リソース プールのメンバーシップは自動的に行われるため、委託されたすべての管理サーバーは自動的にこのリソース プールのメンバーになります。 地理的に分散したコンティンジェンシー操作を組み込むアーキテクチャや設計上の考慮事項によっては、すべての管理サーバー リソース プールへの自動割り当てが望ましくない場合があります。 このような状況では、メンバーシップの割り当てを自動から手動に変更できます。 そのため、管理サーバーを手動で割り当て、すべての管理サーバー リソース プールに追加する必要があります。

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

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

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

単一管理サーバー

• 既定のオブザーバーは既定で有効になっており、メンバーが 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 サービスまたはデータベースに負荷がかかると、それ以外の場合には存在しない遅延が発生します。

単一ゲートウェイ サーバー

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

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

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

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

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

リソース プールをサポートする監視シナリオ

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

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

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

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

次のステップ

リソース プールを作成および管理する方法については、「 リソース プールを管理する方法を参照してください。