レプリカとインスタンスReplicas and instances

この記事では、ステートフル サービスのレプリカとステートレス サービスのインスタンスのライフサイクルの概要を示します。This article gives an overview of the lifecycle of replicas of stateful services and instances of stateless services.

ステートレス サービスのインスタンスInstances of stateless services

ステートレス サービスのインスタンスとは、クラスターのいずれかのノードで実行されるサービスのロジックのコピーのことです。An instance of a stateless service is a copy of the service logic that runs on one of the nodes of the cluster. パーティション内のインスタンスは、その InstanceId によって一意に識別されます。An instance within a partition is uniquely identified by its InstanceId. インスタンスのライフサイクルは、次の図のようにモデル化されます。The lifecycle of an instance is modeled in the following diagram:

インスタンスのライフサイクル

InBuild (IB)InBuild (IB)

クラスター リソース マネージャーでインスタンスの配置が認識されると、このライフサイクルの状態に入ります。After the Cluster Resource Manager determines a placement for the instance, it enters this lifecycle state. インスタンスがノードで起動します。The instance is started on the node. アプリケーション ホストが起動し、インスタンスが作成されて開かれます。The application host is started, the instance is created and then opened. 起動が完了すると、インスタンスは準備完了状態に遷移します。After the startup finishes, the instance transitions to the ready state.

アプリケーション ホストまたはこのインスタンスのノードがクラッシュした場合は、ドロップ状態に遷移します。If the application host or node for this instance crashes, it transitions to the dropped state.

Ready (RD)Ready (RD)

準備完了 (Ready) 状態では、インスタンスはノード上で稼働中です。In the ready state, the instance is up and running on the node. このインスタンスが信頼性の高いサービスであれば、RunAsync が呼び出されています。If this instance is a reliable service, RunAsync has been invoked.

アプリケーション ホストまたはこのインスタンスのノードがクラッシュした場合は、ドロップ状態に遷移します。If the application host or node for this instance crashes, it transitions to the dropped state.

Closing (CL)Closing (CL)

クローズ中 (Closing) 状態では、Azure Service Fabric はこのノード上のインスタンスをシャットダウン処理中です。In the closing state, Azure Service Fabric is in the process of shutting down the instance on this node. このシャットダウンは、アプリケーションのアップグレード、負荷分散、またはサービスの削除など、多くの理由により発生します。This shutdown might be due to many reasons--for example, an application upgrade, load balancing, or the service being deleted. シャットダウンが完了すると、ドロップ状態に遷移します。After shutdown finishes, it transitions to the dropped state.

Dropped (DD)Dropped (DD)

ドロップ (Dropped) 状態では、既にインスタンスはノード上で実行されていません。In the dropped state, the instance is no longer running on the node. この時点では、Service Fabric はこのインスタンスに関するメタデータを保持していますが、最終的にはそれも削除されます。At this point, Service Fabric maintains the metadata about this instance, which is eventually deleted as well.

注意

Remove-ServiceFabricReplicaForceRemove オプションを使用して、いずれかの状態からドロップ状態に遷移することが可能です。It is possible to transition from any state to the dropped state by using the ForceRemove option on Remove-ServiceFabricReplica.

ステートフル サービスのレプリカReplicas of stateful services

ステートフル サービスのレプリカとは、クラスターのノードのいずれかで実行されているサービスのロジックのコピーのことです。A replica of a stateful service is a copy of the service logic running on one of the nodes of the cluster. さらに、レプリカは、そのサービスの状態のコピーを保持します。In addition, the replica maintains a copy of the state of that service. ステートフル レプリカのライフサイクルと動作は、2 つの関連する概念で説明できます。Two related concepts describe the lifecycle and behavior of stateful replicas:

  • レプリカのライフサイクルReplica lifecycle
  • レプリカのロールReplica role

次の解説では、永続化ステートフル サービスについて説明します。The following discussion describes persisted stateful services. 揮発性 (メモリ内) のステートフル サービスでは、ダウン状態とドロップ状態は同等です。For volatile (or in-memory) stateful services, the down and dropped states are equivalent.

レプリカのライフサイクル

InBuild (IB)InBuild (IB)

InBuild レプリカは、レプリカ セットに加えるために作成または準備されるレプリカです。An InBuild replica is a replica that's created or prepared for joining the replica set. レプリカのロールによっては、IB は異なるセマンティクスを持ちます。Depending on the replica role, the IB has different semantics.

アプリケーション ホストまたは InBuild レプリカのノードがクラッシュした場合には、ダウン状態に遷移します。If the application host or the node for an InBuild replica crashes, it transitions to the down state.

  • Primary InBuild レプリカ:Primary InBuild は、パーティションの最初のレプリカです。Primary InBuild replicas: Primary InBuild are the first replicas for a partition. このレプリカは通常、パーティションの作成中に発生します。This replica usually happens when the partition is being created. Primary InBuild レプリカは、パーティションのすべてのレプリカが再起動またはドロップされるときにも発生します。Primary InBuild replicas also arise when all the replicas of a partition restart or are dropped.

  • IdleSecondary InBuild レプリカ:これらは、クラスター リソース マネージャーによって作成される新しいレプリカか、またはダウンし、セットに戻す必要のある既存のレプリカです。IdleSecondary InBuild replicas: These are either new replicas that are created by the Cluster Resource Manager, or existing replicas that went down and need to be added back into the set. それらのレプリカが ActiveSecondary としてレプリカ セットに加わり、操作のクォーラム確認に参加するためには、まずプライマリによってそれらをシード生成またはビルドする必要があります。These replicas are seeded or built by the primary before they can join the replica set as ActiveSecondary and participate in quorum acknowledgement of operations.

  • ActiveSecondary InBuild レプリカ:一部のクエリで、この状態が見られます。ActiveSecondary InBuild replicas: This state is observed in some queries. これは、レプリカ セットに変化がないものの、レプリカをビルドする必要のある最適化です。It is an optimization where the replica set is not changing, but a replica needs to be built. レプリカ自体は、通常状態のマシンの遷移に従います (レプリカのロールのセクションで説明されているとおり)。The replica itself follows the normal state machine transitions (as described in the section on replica roles).

Ready (RD)Ready (RD)

準備完了 (Ready) のレプリカは、レプリケーションに参加し、操作のクォーラム確認に参加しているレプリカです。A Ready replica is a replica that's participating in replication and quorum acknowledgement of operations. 準備完了状態は、プライマリ レプリカと、アクティブなセカンダリ レプリカに当てはまります。The ready state is applicable to primary and active secondary replicas.

アプリケーション ホストまたは準備完了レプリカのノードがクラッシュした場合には、ダウン状態に遷移します。If the application host or the node for a ready replica crashes, it transitions to the down state.

Closing (CL)Closing (CL)

レプリカは、次のシナリオでクローズ中 (Closing) 状態に入ります。A replica enters the closing state in the following scenarios:

  • レプリカのコードをシャットダウンする:Service Fabric で、レプリカの実行中のコードをシャットダウンすることが必要な場合があります。Shutting down the code for the replica: Service Fabric might need to shut down the running code for a replica. このシャットダウンにはさまざまな理由が考えられます。This shutdown might be for many reasons. たとえば、アプリケーション、ファブリック、インフラストラクチャのアップグレードや、レプリカによって報告された障害などによって発生する可能性があります。For example, it can happen because of an application, fabric, or infrastructure upgrade, or because of a fault reported by the replica. レプリカのクローズが完了すると、ダウン状態に遷移します。When the replica close finishes, the replica transitions to the down state. ディスクに格納されているこのレプリカに関連付けられた永続的な状態は、クリーンアップされません。The persisted state associated with this replica that's stored on disk is not cleaned up.

  • クラスターからレプリカを削除する:Service Fabric で、永続的な状態を解除して、レプリカの実行中のコードをシャットダウンすることが必要な場合があります。Removing the replica from the cluster: Service Fabric might need to remove the persisted state and shut down the running code for a replica. このシャットダウンには、負荷分散など、さまざまな理由が考えられます。This shutdown might be for many reasons, for example, load balancing.

Dropped (DD)Dropped (DD)

ドロップ (Dropped) 状態では、既にインスタンスはノード上で実行されていません。In the dropped state, the instance is no longer running on the node. ノード上に残される状態もありません。There is also no state left on the node. この時点では、Service Fabric はこのインスタンスに関するメタデータを保持していますが、最終的にはそれも削除されます。At this point, Service Fabric maintains the metadata about this instance, which is eventually deleted as well.

Down (D)Down (D)

ダウン (Down) 状態では、レプリカ コードは実行されていませんが、そのレプリカの永続的な状態がそのノードに存在します。In the down state, the replica code is not running, but the persisted state for that replica exists on that node. レプリカがダウンする理由はさまざまです。たとえば、ノードのダウン、レプリカ コードでのクラッシュ、アプリケーションのアップグレード、レプリカの障害などです。A replica can be down for many reasons--for example, the node being down, a crash in the replica code, an application upgrade, or replica faults.

ダウン レプリカは、必要に応じて、Service Fabric によって開かれます。たとえば、ノードでのアップグレードが完了したときなどです。A down replica is opened by Service Fabric as required, for example, when the upgrade finishes on the node.

ダウン状態では、レプリカのロールは関係ありません。The replica role is not relevant in the down state.

Opening (OP)Opening (OP)

Service Fabric がレプリカをバックアップに戻す必要がある場合に、ダウン レプリカはオープン中 (Opening) 状態に入ります。A down replica enters the opening state when Service Fabric needs to bring the replica back up again. この状態は、たとえば、ノード上でアプリケーションのコードのアップグレードが完了した後などに発生します。For example, this state might be after a code upgrade for the application finishes on a node.

アプリケーション ホストまたはオープン中のレプリカのノードがクラッシュした場合には、ダウン状態に遷移します。If the application host or the node for an opening replica crashes, it transitions to the down state.

オープン中 (Opening) 状態では、レプリカのロールは関係ありません。The replica role is not relevant in the opening state.

StandBy (SB)StandBy (SB)

スタンバイ (StandBy) レプリカは、ダウン後に再び開かれた、永続的なサービスのレプリカです。A StandBy replica is a replica of a persisted service that went down and was then opened. このレプリカは、レプリカ セットに別のレプリカを追加する必要がある場合に、Service Fabric によって使用されることがあります (状態の一部が既にあって、ビルド処理が高速であるため)。This replica might be used by Service Fabric if it needs to add another replica to the replica set (because the replica already has some portion of the state and the build process is faster). StandByReplicaKeepDuration の期限が切れると、スタンバイ レプリカは破棄されます。After the StandByReplicaKeepDuration expires, the standby replica is discarded.

アプリケーション ホストまたはスタンバイ レプリカのノードがクラッシュした場合には、ダウン状態に遷移します。If the application host or the node for a standby replica crashes, it transitions to the down state.

スタンバイ状態では、レプリカのロールは関係ありません。The replica role is not relevant in the standby state.

注意

ダウン状態でもドロップ状態でもないレプリカは、稼働中と見なされます。Any replica that's not down or dropped is considered to be up.

注意

Remove-ServiceFabricReplicaForceRemove オプションを使用して、いずれかの状態からドロップ状態に遷移することが可能です。It's possible to transition from any state to the dropped state by using the ForceRemove option on Remove-ServiceFabricReplica.

レプリカのロールReplica role

レプリカのロールは、レプリカ セット内での機能を決定します。The role of the replica determines its function in the replica set:

  • Primary (P) :レプリカ セットには、読み取りおよび書き込み操作の実行を担当する 1 つのプライマリがあります。Primary (P): There is one primary in the replica set that is responsible for performing read and write operations.
  • ActiveSecondary (S) :これらは、状態の更新をプライマリから受け取り、それらを適用し、確認を戻すレプリカです。ActiveSecondary (S): These are replicas that receive state updates from the primary, apply them, and then send back acknowledgements. レプリカ セットには複数のアクティブなセカンダリがあります。There are multiple active secondaries in the replica set. それらのアクティブなセカンダリの数によって、サービスで処理できるエラーの数が決まります。The number of these active secondaries determines the number of faults the service can handle.
  • IdleSecondary (I) :これらのレプリカはプライマリによってビルドされているもので、IdleSecondary (I): These replicas are being built by the primary. アクティブなセカンダリに昇格する前に、プライマリから状態を受信します。They are receiving state from the primary before they can be promoted to active secondary.
  • None (N) :これらのレプリカは、レプリカ セットで何も担当しません。None (N): These replicas don't have a responsibility in the replica set.
  • Unknown (U) :Service Fabric から何らかの ChangeRole API 呼び出しを受け取る前の、レプリカの初期ロールです。Unknown (U): This is the initial role of a replica before it receives any ChangeRole API call from Service Fabric.

次の図は、レプリカのロールの遷移と、それらが発生するいくつかのシナリオの例を示しています。The following diagram illustrates the replica role transitions and some example scenarios in which they can occur:

レプリカのロール

  • U -> P:新しいプライマリ レプリカの作成。U -> P: Creation of a new primary replica.
  • U -> I:新しいアイドル レプリカの作成。U -> I: Creation of a new idle replica.
  • U -> N:スタンバイ レプリカの削除。U -> N: Deletion of a standby replica.
  • I -> S:アイドル状態のセカンダリをアクティブなセカンダリに昇格して、その確認がクォーラムに貢献するようにします。I -> S: Promotion of the idle secondary to active secondary so that its acknowledgements contribute toward quorum.
  • I -> P:アイドル状態のセカンダリからプライマリへの昇格。I -> P: Promotion of the idle secondary to primary. アイドル セカンダリがプライマリの適切な候補になる、特別な再構成のもとで発生する可能性があります。This can happen under special reconfigurations when the idle secondary is the correct candidate to be primary.
  • I -> N:アイドル状態のセカンダリ レプリカの削除。I -> N: Deletion of the idle secondary replica.
  • S -> P:アクティブなセカンダリからプライマリへの昇格。S -> P: Promotion of the active secondary to primary. これは、クラスター リソース マネージャーによって開始されたプライマリのフェールオーバーまたはプライマリの動きが理由で発生します。This can be due to failover of the primary or a primary movement initiated by the Cluster Resource Manager. たとえば、アプリケーションのアップグレードまたは負荷分散への応答で発生します。For example, it might be in response to an application upgrade or load balancing.
  • S -> N:アクティブなセカンダリ レプリカの削除。S -> N: Deletion of the active secondary replica.
  • P -> S:プライマリ レプリカの降格。P -> S: Demotion of the primary replica. これは、クラスター リソース マネージャーによって開始されたプライマリの動きが理由で発生します。This can be due to a primary movement initiated by the Cluster Resource Manager. たとえば、アプリケーションのアップグレードまたは負荷分散への応答で発生します。For example, it might be in response to an application upgrade or load balancing.
  • P -> N:プライマリ レプリカの削除。P -> N: Deletion of the primary replica.

注意

Reliable ActorsReliable Services など、抽象度の高いプログラミング モデルの場合、レプリカ ロールの概念は開発者には隠されています。Higher-level programming models, such as Reliable Actors and Reliable Services, hide the concept of replica roles from the developer. Actors では、ロールの概念は不要です。In Actors, the notion of a role is unnecessary. Services では、ほとんどのシナリオで大幅に簡略化されます。In Services, it's largely simplified for most scenarios.

次の手順Next steps

Service Fabric の概念について詳しくは、次の記事をご覧ください。For more information on Service Fabric concepts, see the following article:

Reliable Services のライフサイクル - C#Reliable Services lifecycle - C#