クラスター リソース マネージャーのアーキテクチャの概要

  • [アーティクル]

Service Fabric クラスター リソース マネージャーは、クラスターで実行されている中央のサービスです。 これにより、特にリソースの消費量と任意の配置ルールについて、クラスターにおけるサービスの望まれる状態が管理されます。

Service Fabric クラスター リソース マネージャーには、クラスターのリソースを管理するための情報がいくつか必要です。

  • 現在存在しているサービス
  • 各サービスの現在 (または既定) のリソース消費量
  • 残りのクラスターの容量
  • クラスター内のノードの容量
  • 各ノードで消費されるリソースの量

サービスのリソース消費量は時間の経過と共に変わりますし、サービスでは通常、複数のリソースが使用されます。 サービスによっては、実際の物理リソースと物理リソースの両方が計測されることもあります。 メモリやディスクの消費量など、物理的な指標が追跡されることもありますし、 さらに一般的な傾向として、論理的な指標 ("WorkQueueDepth" や "TotalRequests" など) が使用されることもあります。 論理および物理メトリックはいずれも、同じクラスターで使用できます。 また、数多くのサービスで共有できるメトリックや、特定のサービスに固有のメトリックがあります。

その他の考慮事項

クラスターの所有者や運営者が、サービスやアプリケーションの作成者と異なる人物であることがあります。また少なくとも、担当が違えば仕事内容も異なります。 アプリケーションを開発するとき、何が必要かについて多少はわかっています。 そして、使用するリソースを考えたり、各種サービスをどのようにデプロイするかを検討したりします。 たとえば、Web 層はインターネットに公開されているノード上で実行する必要がありますが、データベース サービスはそうではありません。 また、Web サービスは、CPU とネットワークで制限されますが、データ層サービスで大事なのはメモリとディスクの消費です。 しかし、そのサービスが本稼働になった後、ライブサイトでのインシデントに対応する担当者、またはサービスへのアップグレードを管理する担当者は、行う業務が違いますし、必要なツールも異なります。

クラスターとサービスは両方とも動的です。

  • クラスター内のノード数は増減する可能性があります
  • サイズやタイプの異なるノードが追加されたり削除される可能性があります
  • サービスの作成や削除が行われたり、望ましいリソース割り当てや配置ルールが変わる可能性があります
  • クラスター内で、アップグレードやその他の管理操作が、インフラストラクチャのアプリケーション レベルで展開される可能性があります
  • 障害がいつでも発生する可能性があります。

クラスター リソース マネージャーのコンポーネントとデータ フロー

クラスター リソース マネージャーでは、各サービスの要件と、そのサービス内の各サービス オブジェクトのリソース消費量を追跡する必要があります。 クラスター リソース マネージャーは、各ノードで実行されるエージェントと、フォールト トレラント サービスの 2 つの概念的要素で構成されます。 各ノード上のエージェントは、サービスから負荷レポートを読み込み、それらを集計して、定期的にレポートします。 クラスター リソース マネージャー サービスは、ローカル エージェントからの情報をすべて集計し、その最新の構成に基づいて状況に対応します。

次の図を見てみましょう。

Cluster Resource Manager サービスはローカル エージェントからの情報をすべて集計し、その最新の構成に基づいて状況に対応することを示す図。

実行時には、さまざまな変更が生じる可能性があります。 たとえば、一部のサービスでリソース消費量が変わったり、一部のサービスでエラーが発生したり、クラスターでノードの追加や削除が発生することがあります。 ノード上の変更はすべて集計され、クラスター リソース マネージャー サービスに定期的に送信 (1、2) されます。そこで再度集計され、分析されて格納されます。 このサービスは数秒ごとに変更を確認し、何らかのアクションが必要かどうかを判断します (3)。 たとえば、クラスターに空のノードが追加されたことが検出された場合は、 そのノードに一部のサービスを移動するかどうかを決定します。 また、クラスター リソース マネージャーでは、特定のノードに過剰な負荷がかかっていたり、特定のサービスで障害が発生したか、サービスが削除された場合に、別の場所のリソースを開放したりもします。

次の図を見て、次に何が起こるのかを考えてみましょう。 たとえば、変更が必要であるとクラスター リソース マネージャーが判断するとします。 その他のシステム サービス (具体的には Failover Manager) と調整を行い、必要な変更を行います。 その後、必要なコマンドが適切なノードに送信されます (4)。 たとえば、リソース マネージャーが Node5 に過剰な負荷がかかっていることに気付き、サービス B を Node5 から Node4 に移動することにしたとします。 再構成後 (5)、クラスターは次のようになります。

リソース バランサーのアーキテクチャ

次のステップ

  • Cluster Resource Manager には、クラスターを記述するためのさまざまなオプションがあります。 オプションの詳細については、Service Fabric クラスターの記述に関するこの記事を参照してください。
  • クラスター リソース マネージャーの主な仕事はクラスターを再調整して、配置ルールを適用することです。 こうした動作の構成の詳細については、「Service Fabric クラスターの均衡をとる」を参照してください