Azure Service Fabric でのディザスター リカバリーDisaster recovery in Azure Service Fabric

高可用性を実現するうえで欠かせないのは、サービスがあらゆる種類の障害を切り抜けられるようにすることです。A critical part of delivering high-availability is ensuring that services can survive all different types of failures. これは、計画外の障害や、制御できない障害に関しては特に重要です。This is especially important for failures that are unplanned and outside of your control. この記事では、正しくモデル化および管理されていない場合に、災害につながる可能性がある一般的な障害モードをいくつか取り上げて説明します。This article describes some common failure modes that could be disasters if not modeled and managed correctly. さらに、軽減策や、災害が発生した場合に実行するアクションについても解説します。It also discuss mitigations and actions to take if a disaster happened anyway. その目的は、計画的または計画外の障害が発生したときに、ダウンタイムやデータ損失のリスクを軽減または排除することです。The goal is to limit or eliminate the risk of downtime or data loss when they occur failures, planned or otherwise, occur.

災害の回避Avoiding disaster

Service Fabric の主な目的は、一般的な障害が災害につながらないように、環境とサービスの両方をモデル化できるよう支援することです。Service Fabric's primary goal is to help you model both your environment and your services in such a way that common failure types are not disasters.

一般的に、災害/障害のシナリオには 2 つの種類があります。In general there are two types of disaster/failure scenarios:

  1. ハードウェアまたはソフトウェアのエラーHardware or software faults
  2. 操作上のエラーOperational faults

ハードウェアおよびソフトウェアのエラーHardware and software faults

ハードウェアとソフトウェアのエラーは予測できません。Hardware and software faults are unpredictable. 障害を最も簡単に切り抜けるには、ハードウェアまたはソフトウェアのエラーの境界で、より多くのサービス コピーを実行します。The easiest way to survive faults is running more copies of the service spanned across hardware or software fault boundaries. たとえば、サービスが 1 つの特定のマシンでのみ実行されている場合、そのマシンで障害が発生するということは、サービスで災害が発生するということです。For example, if your service is running only on one particular machine, then the failure of that one machine is a disaster for that service. この災害は、サービスを確実に複数のマシンで実行することによって、簡単に回避できます。The simple way to avoid this disaster is to ensure that the service is actually running on multiple machines. 1 台のマシンの障害によって実行中のサービスが中断しないように、テストを行う必要もあります。Testing is also necessary to ensure the failure of one machine doesn't disrupt the running service. 容量計画によって置換インスタンスを他の場所に作成すれば、容量が減っても、残りのサービスが過負荷になりません。Capacity planning ensures a replacement instance can be created elsewhere and that reduction in capacity doesn't overload the remaining services. このパターンは、回避しようとしている障害の種類にかかわらず有効です。The same pattern works regardless of what you're trying to avoid the failure of. たとえば次のようになります。For example. SAN の障害が心配であれば、複数の SAN で実行します。if you're concerned about the failure of a SAN, you run across multiple SANs. サーバー ラックの損失が心配であれば、複数のラックで実行します。If you're concerned about the loss of a rack of servers, you run across multiple racks. データセンターの損失が心配であれば、複数の Azure リージョンまたはデータセンターでサービスを実行します。If you're worried about the loss of datacenters, your service should run across multiple Azure regions or datacenters.

このタイプのスパン モードで実行しても、同時に発生する一部の障害の影響はまだ受けます。しかし、1 つの障害と、種類によっては複数の障害 (1 つの VM またはネットワーク リンクの障害など) については自動的に処理されます (もはや "災害" ではありません)。When running in this type of spanned mode, you're still subject to some types of simultaneous failures, but single and even multiple failures of a particular type (ex: a single VM or network link failing) are automatically handled (and so no longer a "disaster"). Service Fabric には、クラスターを拡張するメカニズムが多数用意されており、障害が発生したノードとサービスを元に戻します。Service Fabric provides many mechanisms for expanding the cluster and handles bringing failed nodes and services back. また、このような計画外の障害が本当の意味での災害にならないように、Service Fabric では、サービスのインスタンスを多数実行できます。Service Fabric also allows running many instances of your services in order to avoid these types of unplanned failures from turning into real disasters.

障害に対応できる規模でのデプロイを実現できないのには理由があるのでしょう。There may be reasons why running a deployment large enough to span over failures is not feasible. たとえば、ハードウェア リソースのコストが、障害が発生する可能性を考えたときに、惜しまずに支払える金額を超えているのかもしれません。For example, it may take more hardware resources than you're willing to pay for relative to the chance of failure. 分散アプリケーションを扱う場合は、地理的に離れた場所における追加の通信ホップまたは状態レプリケーション コストにより、許容できない待機時間が発生することがあります。When dealing with distributed applications, it could be that additional communication hops or state replication costs across geographic distances causes unacceptable latency. この線引きはアプリケーションごとに異なります。Where this line is drawn differs for each application. 特にソフトウェア エラーについては、スケールしようとしているサービスでエラーが発生している可能性があります。For software faults specifically, the fault could be in the service that you are trying to scale. この場合、コピーを増やしても災害を防ぐことはできません。障害の状態が、すべてのインスタンス間で相互に関連付けられているためです。In this case more copies don't prevent the disaster, since the failure condition is correlated across all the instances.

操作上のエラーOperational faults

サービスが世界規模で分散され、あらゆる冗長性が実現されていても、災害を引き起こすイベントは発生します。Even if your service is spanned across the globe with many redundancies, it can still experience disastrous events. たとえば、ユーザーは誤ってサービスの DNS 名を再構成したり、完全に削除したりするものです。For example, if someone accidentally reconfigures the dns name for the service, or deletes it outright. ステートフルな Service Fabric サービスがあり、誰かがそのサービスを誤って削除したとします。As an example, let's say you had a stateful Service Fabric service, and someone deleted that service accidentally. 軽減策がなければ、サービスとそのサービスの状態はすべて失われます。Unless there's some other mitigation, that service and all of the state it had is now gone. こうした種類の操作上の災害 ("不測") には、通常の計画外の障害とは異なる復旧対策と手順が必要です。These types of operational disasters ("oops") require different mitigations and steps for recovery than regular unplanned failures.

このような操作上のエラーを回避する最善の方法を次に示しますThe best ways to avoid these types of operational faults are to

  1. 環境への作業のためのアクセスを制限するrestrict operational access to the environment
  2. 危険な操作を厳密に監査するstrictly audit dangerous operations
  3. 自動化を実施し、手動または帯域外の変更を防止するほか、実際の環境に対する特定の変更を適用前に検証するimpose automation, prevent manual or out of band changes, and validate specific changes against the actual environment before enacting them
  4. 破壊的な操作が "ソフト" であることを確認する。ensure that destructive operations are "soft". ソフト操作はすぐには有効になりません。一定の時間内であれば操作を元に戻すことができますSoft operations don't take effect immediately or can be undone within some time window

Service Fabric には、クラスター操作に対するロールベースのアクセス制御など、操作上のエラーを回避するためのメカニズムがいくつか用意されています。Service Fabric provides some mechanisms to prevent operational faults, such as providing role-based access control for cluster operations. ただし、このような操作上のエラーのほとんどでは、組織的な取り組みと他のシステムが必要です。However, most of these operational faults require organizational efforts and other systems. Service Fabric には、操作上のエラーを切り抜けるためのメカニズムがいくつか用意されています。中でもよく知られているのは、ステートフル サービスのバックアップと復元です。Service Fabric does provide some mechanism for surviving operational faults, most notably backup and restore for stateful services.

障害の管理Managing failures

Service Fabric では、障害を常に自動管理することを目標としています。The goal of Service Fabric is almost always automatic management of failures. ただし、一部の障害については、処理のための追加コードがサービスに必要です。However, in order to handle some types of failures, services must have additional code. また、安全性とビジネス継続性の理由により、自動的に対処するべき "ではない" 種類の障害もあります。Other types of failures should not be automatically addressed because of safety and business continuity reasons.

1 つの障害への対処Handling single failures

1 台のマシンで障害が発生する理由はさまざまです。Single machines can fail for all sorts of reasons. 電源、ネットワーク ハードウェアの障害など、ハードウェアが原因である場合があります。Some of these are hardware causes, like power supplies and networking hardware failures. また、ソフトウェアが原因であることもあります。Other failures are in software. これには実際のオペレーティング システムとサービス自体の障害が含まれます。These include failures of the actual operating system and the service itself. Service Fabric では、このような障害、たとえば、ネットワークの問題によりマシンが他のマシンから切り離されている、といった状況が自動的に検出されます。Service Fabric automatically detects these types of failures, including cases where the machine becomes isolated from other machines due to network issues.

サービスの種類に関係なく、実行されているインスタンスが 1 つだと、そのコードの 1 つのコピーが何らかの理由で失敗した場合に、そのサービスでダウンタイムが発生します。Regardless of the type of service, running a single instance results in downtime for that service if that single copy of the code fails for any reason.

すべての障害に対して最も簡単に対応するには、ご自身のサービスを、既定で、複数のノードで実行するようにします。In order to handle any single failure, the simplest thing you can do is to ensure that your services run on more than one node by default. ステートレス サービスの場合、これを行うには、InstanceCount を 1 よりも大きな値に設定します。For stateless services, this can be accomplished by having an InstanceCount greater than 1. ステートフル サービスの場合、推奨最小値は必ず TargetReplicaSetSizeMinReplicaSetSize が 3 以上です。For stateful services, the minimum recommendation is always a TargetReplicaSetSize and MinReplicaSetSize of at least 3. サービス コードのコピーを複数実行すると、サービスによって、すべての障害が確実に自動処理されます。Running more copies of your service code ensures that your service can handle any single failure automatically.

組織的障害への対処Handling coordinated failures

クラスター内での組織的障害の原因は、計画的または計画外インフラストラクチャ障害と変更、または計画的ソフトウェア変更のいずれかです。Coordinated failures can happen in a cluster due to either planned or unplanned infrastructure failures and changes, or planned software changes. Service Fabric は、組織的障害が発生しているインフラストラクチャ ゾーンを、障害ドメインとしてモデル化します。Service Fabric models infrastructure zones that experience coordinated failures as Fault Domains. 組織的ソフトウェア変更が発生する領域は、アップグレード ドメインとしてモデル化されます。Areas that will experience coordinated software changes are modeled as Upgrade Domains. 障害ドメインおよびアップグレード ドメインの詳細については、こちらのドキュメントを参照してください。このドキュメントでは、クラスター トポロジと定義について説明しています。More information about fault and upgrade domains is in this document that describes cluster topology and definition.

既定では、Service Fabric は、障害ドメインとアップグレード ドメインを考慮して、サービスを実行する場所を計画します。By default Service Fabric considers fault and upgrade domains when planning where your services should run. また、Service Fabric では、既定で複数の障害ドメインとアップグレード ドメインにわたってサービスを実行しようとするため、計画的または計画外変更が発生しても、サービスは使用可能な状態のままです。By default, Service Fabric tries to ensure that your services run across several fault and upgrade domains so if planned or unplanned changes happen your services remain available.

たとえば、電源の障害により、マシン ラックで同時に障害が発生したとします。For example, let's say that failure of a power source causes a rack of machines to fail simultaneously. サービスの複数のコピーが実行されているため、障害ドメインでの多数のマシンの喪失は、特定のサービスに対する単一障害の別の一例に過ぎません。With multiple copies of the service running the loss of many machines in fault domain failure turns into just another example of single failure for a given service. 障害ドメインの管理が、サービスの高可用性の確保に欠かせないのはこのためです。This is why managing fault domains is critical to ensuring high availability of your services. Azure で Service Fabric を実行している場合、障害ドメインは自動的に管理されます。When running Service Fabric in Azure, fault domains are managed automatically. しかし、他の環境では、そうではない可能性があります。In other environments they may not be. オンプレミスで独自のクラスターを作成する場合は、障害ドメインのレイアウトを必ず正しく計画し、マップしてください。If you're building your own clusters on premises, be sure to map and plan your fault domain layout correctly.

アップグレード ドメインは、ソフトウェア アップグレードを同時に実行する領域をモデル化するときに役に立ちます。Upgrade Domains are useful for modeling areas where software is going to be upgraded at the same time. このため、アップグレード ドメインは、多くの場合、計画的アップグレード中にソフトウェアが停止される境界も定義します。Because of this, Upgrade Domains also often define the boundaries where software is taken down during planned upgrades. Service Fabric とサービスの両方のアップグレードが同じモデルに従います。Upgrades of both Service Fabric and your services follow the same model. ローリング アップグレード、アップグレード ドメイン、および予期しない変更による影響をクラスターとサービスが受けないようにするうえで役立つ Service Fabric 正常性モデルの詳細については、次のドキュメントを参照してください。For more on rolling upgrades, upgrade domains, and the Service Fabric health model that helps prevent unintended changes from impacting the cluster and your service, see these documents:

Service Fabric Explorer で提供されるクラスター マップを使用して、クラスターのレイアウトを視覚化できます。You can visualize the layout of your cluster using the cluster map provided in Service Fabric Explorer:

Service Fabric Explorer での障害ドメインに分散されたノードの表示
Nodes spread across fault domains in Service Fabric Explorer

注意

障害領域のモデル化、ローリング アップグレード、サービス コードと状態の多くのインスタンスの実行、障害ドメインとアップグレード ドメインでサービスを確実に実行するための配置ルール、および組み込みの正常性の監視は、通常の操作上の問題や障害が災害につながるのを未然に防ぐために、Service Fabric に用意されている機能の一部にすぎません。Modeling areas of failure, rolling upgrades, running many instances of your service code and state, placement rules to ensure your services run across fault and upgrade domains, and built-in health monitoring are just some of the features that Service Fabric provides in order to keep normal operational issues and failures from turning into disasters.

ハードウェアまたはソフトウェアの同時障害への対処Handling simultaneous hardware or software failures

ここまでは 1 つの障害について説明しました。Above we talked about single failures. おわかりのように、障害ドメインとアップグレード ドメインで実行されているコード (および状態) のコピーを複数保持するだけで、ステートレス サービスとステートフル サービスの両方を簡単に処理できます。As you can see, are easy to handle for both stateless and stateful services just by keeping more copies of the code (and state) running across fault and upgrade domains. 複数の障害がランダムに同時発生することがあります。Multiple simultaneous random failures can also happen. こうした障害は、実際の災害につながる可能性が高くなります。These are more likely to lead to an actual disaster.

サービス障害につながるランダムに発生する障害Random failures leading to service failures

たとえば、サービスの InstanceCount が 5 で、このインスタンスが実行されているすべてのノードで同時に障害が発生したとします。Let's say that the service had an InstanceCount of 5, and several nodes running those instances all failed at the same time. Service Fabric は、自動的に他のノードで置換インスタンスを作成して対応します。Service Fabric responds by automatically creating replacement instances on other nodes. この Service Fabric は、サービスのインスタンス数が望ましい数に戻るまで、置換インスタンスを作成し続けます。It will continue creating replacements until the service is back to its desired instance count. また、InstanceCount が-1 に設定されているステートレス サービスがあるとします。これは、クラスター内のすべてのノードで、サービスが実行されていることを意味します。As another example, let's say there was a stateless service with an InstanceCountof -1, meaning it runs on all valid nodes in the cluster. こうしたインスタンスのいくつかで障害が発生したとします。Let's say that some of those instances were to fail. この場合、Service Fabric は、サービスが望ましい状態ではないことを認識すると、インスタンスが不足しているノードで、インスタンスを作成しようとします。In this case, Service Fabric notices that the service is not in its desired state, and tries to create the instances on the nodes where they are missing.

ステートフル サービスについては、この状況は、サービスが永続化状態かどうかによって異なります。For stateful services the situation depends on whether the service has persisted state or not. また、サービスのレプリカ数と障害の数によっても異なります。It also depends on how many replicas the service had and how many failed. ステートフル サービスについて災害が発生したかどうかを判断し、それを管理するプロセスは、3 つの段階に従って実行されます。Determining whether a disaster occurred for a stateful service and managing it follows three stages:

  1. クォーラムの損失があるかどうかを確認するDetermining if there has been quorum loss or not
    • ステートフル サービスのレプリカの大部分が同時にダウンしているときはいつでも、クォーラムの損失が発生しています (プライマリを含む)。A quorum loss is any time a majority of the replicas of a stateful service are down at the same time, including the Primary.
  2. クォーラムの損失が永続的かどうかを確認するDetermining if the quorum loss is permanent or not
    • ほとんどの場合、障害は一時的なものです。Most of the time, failures are transient. プロセス、ノード、VM が再起動され、ネットワーク パーティションは修復します。Processes are restarted, nodes are restarted, VMs are relaunched, network partitions heal. ただし、障害が永続的である場合もあります。Sometimes though, failures are permanent.
      • 永続化状態でないサービスの場合、クォーラムまたはレプリカで障害が発生すると、"直ちに" 永続的なクォーラム損失が発生します。For services without persisted state, a failure of a quorum or more of replicas results immediately in permanent quorum loss. Service Fabric は、非永続的なステートフル サービスでクォーラムの損失を検出するとすぐに、(潜在的な) データ損失を宣言して、手順 3. に進みます。When Service Fabric detects quorum loss in a stateful non-persistent service, it immediately proceeds to step 3 by declaring (potential) dataloss. データ損失に進むことは理にかなっています。Service Fabric は、レプリカが戻るのを待っても意味がないことを認識しているためです。また、復旧したとしても、空だからです。Proceeding to dataloss makes sense because Service Fabric knows that there's no point in waiting for the replicas to come back, because even if they were recovered they would be empty.
      • 永続的なステートフル サービスの場合、クォーラムまたはレプリカで障害が発生すると、Service Fabric は、レプリカが戻ってクォーラムを復元するのを待ち始めます。For stateful persistent services, a failure of a quorum or more of replicas causes Service Fabric to start waiting for the replicas to come back and restore quorum. これにより、影響を受けるサービス パーティション ("レプリカ セット") に対するすべての "書き込み" でサービス停止が発生します。This results in a service outage for any writes to the affected partition (or "replica set") of the service. ただし、一貫性の保証は少なくなりますが、読み取りはまだ可能です。However, reads may still be possible with reduced consistency guarantees. 続行することは (潜在的な) データ損失イベントとなり、その他のリスクが伴うため、既定では、Service Fabric はクォーラムが復元されるのを無制限に待ち続けます。The default amount of time that Service Fabric waits for quorum to be restored is infinite, since proceeding is a (potential) dataloss event and carries other risks. QuorumLossWaitDuration の既定値は上書きできますが、お勧めしません。Overriding the default QuorumLossWaitDuration value is possible but is not recommended. 代わりに、この時点で、停止しているレプリカを復元することに全力を尽くしてください。Instead at this time, all efforts should be made to restore the down replicas. それには、停止したノードをバックアップし、ローカル継続状態を格納したドライブを確実に再マウントできなければなりません。This requires bringing the nodes that are down back up, and ensuring that they can remount the drives where they stored the local persistent state. クォーラム損失の原因がプロセス障害である場合、Service Fabric は自動的にプロセスを再作成し、その内部でレプリカを再起動しようとします。If the quorum loss is caused by process failure, Service Fabric automatically tries to recreate the processes and restart the replicas inside them. これが失敗すると、Service Fabric は正常性エラーを報告します。If this fails, Service Fabric reports health errors. 解決できた場合、通常、レプリカは戻ります。If these can be resolved then the replicas usually come back. ただし、場合によっては、戻らないこともあります。Sometimes, though, the replicas can't be brought back. たとえば、すべてのドライブで障害が発生した場合、または何らかの理由でマシンが物理的に壊れている場合です。For example, the drives may all have failed, or the machines physically destroyed somehow. このような場合は、永続的なクォーラム損失イベントが発生します。In these cases, we now have a permanent quorum loss event. 停止したレプリカが戻るのを待っている Service Fabric に対して、待つのをやめるように指示するために、クラスター管理者は、どのサービスのどのパーティションが影響を受ているかを判断し、Repair-ServiceFabricPartition -PartitionId または System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) API を呼び出す必要があります。To tell Service Fabric to stop waiting for the down replicas to come back, a cluster administrator must determine which partitions of which services are affected and call the Repair-ServiceFabricPartition -PartitionId or System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) API. この API により、クォーラム損失から潜在的なデータ損失に移行するために、パーティションの ID を指定できます。This API allows specifying the ID of the partition to move out of QuorumLoss and into potential dataloss.

注意

対象の方法以外で特定のパーティションに対してこの API を使用するのは、"決して" 安全ではありません。It is never safe to use this API other than in a targeted way against specific partitions.

  1. 実際にデータ損失があったかどうかを確認し、バックアップから復元するDetermining if there has been actual data loss, and restoring from backups
    • Service Fabric が OnDataLossAsync メソッドを呼び出す場合、その理由は必ずデータ損失の "疑いがある" ためです。When Service Fabric calls the OnDataLossAsync method it is always because of suspected dataloss. Service Fabric により、この呼び出しは確実に "最適" な残りのレプリカに配信されます。Service Fabric ensures that this call is delivered to the best remaining replica. これは、最も進捗しているレプリカです。This is whichever replica has made the most progress. データ損失の "疑いがある" があるという場合、その理由は、残りのレプリカの実際の状態が、プライマリが停止したときのプライマリの状態とまったく同じである可能性があるためです。The reason we always say suspected dataloss is that it is possible that the remaining replica actually has all same state as the Primary did when it went down. しかし、比較対象となる状態がなければ、Service Fabric やオペレーターが適切な方法でそれを確信することはできません。However, without that state to compare it to, there's no good way for Service Fabric or operators to know for sure. この時点で、Service Fabric は、他のレプリカが戻らないこともわかっています。At this point, Service Fabric also knows the other replicas are not coming back. これは、クォーラム損失が解決されるのを待つことをやめたとき行われた決定です。That was the decision made when we stopped waiting for the quorum loss to resolve itself. サービスに対する最善なアクションは、通常、アクションを凍結し、特定の管理介入を待つことです。The best course of action for the service is usually to freeze and wait for specific administrative intervention. では、OnDataLossAsync メソッドの一般的な実装では何を行うのでしょう。So what does a typical implementation of the OnDataLossAsync method do?
    • 最初に、OnDataLossAsync がトリガーされたことをログに記録し、必要な管理アラートを起動します。First, log that OnDataLossAsync has been triggered, and fire off any necessary administrative alerts.
    • 通常、この時点で、一時停止し、さらなる決定と、手動アクションが実行されるのを待ちます。Usually at this point, to pause and wait for further decisions and manual actions to be taken. これは、バックアップを使用できる場合でも、準備が必要な可能性があるためです。This is because even if backups are available they may need to be prepared. たとえば、2 つの異なるサービスで情報を調整する場合、復元が発生したときに、その 2 つのサービスに関連する情報の一貫性を確保するために、こうしたバックアップの変更が必要になることがあります。For example, if two different services coordinate information, those backups may need to be modified in order to ensure that once the restore happens that the information those two services care about is consistent.
    • 多くの場合、サービスの他のテレメトリや消費データも存在します。Often there is also some other telemetry or exhaust from the service. このメタデータは、他のサービスまたはログに含まれている可能性があります。This metadata may be contained in other services or in logs. この情報を使用して、バックアップに存在しない、またはこの特定のレプリカにレプリケートされなかった呼び出しが、プライマリで受信および処理されたかどうかを判断します。This information can be used needed to determine if there were any calls received and processed at the primary that were not present in the backup or replicated to this particular replica. 復元を実現するには、これを再生するか、バックアップに追加しなければならないことがあります。These may need to be replayed or added to the backup before restoration is feasible.
    • 残りのレプリカの状態を、バックアップに含まれるものを比較できます。Comparisons of the remaining replica's state to that contained in any backups that are available. Service Fabric の信頼できるコレクションを使用すると、このためのツールやプロセスを入手できます。詳細については、こちらの記事を参照してください。If using the Service Fabric reliable collections then there are tools and processes available for doing so, described in this article. その目的は、レプリカ内の状態が十分かどうか、また、バックアップで何が不足しているかを確認することです。The goal is to see if the state within the replica is sufficient, or also what the backup may be missing.
    • 比較の後、必要に応じて復元が行われ、状態が変更されると、サービス コードは true を返します。Once the comparison is done, and if necessary the restore completed, the service code should return true if any state changes were made. レプリカが使用可能な最善の状態のコピーであると判断された場合、変更は行われず、false を返します。If the replica determined that it was the best available copy of the state and made no changes, then return false. True は、"" の残りのレプリカが、このレプリカと整合性がとれていない可能性があることを示します。True indicates that any other remaining replicas may now be inconsistent with this one. 残りのレプリカは削除され、このレプリカから再作成されます。They will be dropped and rebuilt from this replica. False は、状態の変更は行われていないため、他のレプリカをそのまま保持できることを意味します。False indicates that no state changes were made, so the other replicas can keep what they have.

サービス作成者が、サービスを運用環境にデプロイする前に、潜在的なデータ損失および障害シナリオを実施することが非常に重要です。It is critically important that service authors practice potential dataloss and failure scenarios before services are ever deployed in production. データ損失の可能性を防ぐために、地理冗長ストアへのステートフル サービスの状態のバックアップを定期的に行うことも重要です。To protect against the possibility of dataloss, it is important to periodically back up the state of any of your stateful services to a geo-redundant store. また、それを復元する機能を確保する必要もあります。You must also ensure that you have the ability to restore it. さまざまなサービスのバックアップがそれぞれ異なるタイミングで行われるため、復元後、こうしたサービスのビューが相互に一貫性があることを確認する必要があります。Since backups of many different services are taken at different times, you need to ensure that after a restore your services have a consistent view of each other. たとえば、あるサービスが数値を生成して格納し、その数値を他のサービスに送信したとします。送信先のサービスも、受け取った数値を格納します。For example, consider a situation where one service generates a number and stores it, then sends it to another service that also stores it. 復元後、2 番目のサービスに数値があり、最初のサービスにはないことに気が付きました。これはバックアップに、この操作が含まれていなかったためです。After a restore, you might discover that the second service has the number but the first does not, because it's backup didn't include that operation.

残りのレプリカが不十分で、データ損失シナリオを続行できない場合、テレメトリまたは消費データからサービスの状態を再構築できないときは、最適な目標復旧時点 (RPO) はバックアップの頻度によって決まります。If you find out that the remaining replicas are insufficient to continue from in a dataloss scenario, and you can't reconstruct service state from telemetry or exhaust, the frequency of your backups determines your best possible recovery point objective (RPO). Service Fabric には、バックアップからの復元を必要とする永続的なクォーラムとデータ損失など、さまざまな障害シナリオをテストするツールが多数用意されています。Service Fabric provides many tools for testing various failure scenarios, including permanent quorum and dataloss requiring restoration from a backup. こうしたシナリオは、Fault Analysis Service によって管理される、Service Fabric の Testability ツールに含まれています。These scenarios are included as a part of Service Fabric's testability tools, managed by the Fault Analysis Service. こうしたツールおよびパターンの詳細については、こちらを参照してください。More info on those tools and patterns is available here.

注意

システム サービスでもクォーラム損失が発生する可能性があり、その影響は問題のあるサービスに固有です。System services can also suffer quorum loss, with the impact being specific to the service in question. たとえば、ネーム サービスでクォーラム損失が発生すると名前の解決に影響があり、フェールオーバー マネージャー サービスの場合は新しいサービスの作成とフェールオーバーがブロックされます。For instance, quorum loss in the naming service impacts name resolution, whereas quorum loss in the failover manager service blocks new service creation and failovers. Service Fabric システム サービスは、状態管理のサービスと同じパターンに従いますが、クォーラム損失から潜在的なデータ損失への移行はお勧めしません。While the Service Fabric system services follow the same pattern as your services for state management, it is not recommended that you should attempt to move them out of Quorum Loss and into potential dataloss. 代わりに、サポートを利用して、個別の状況に合ったソリューションを判断することをお勧めします。The recommendation is instead to seek support to determine a solution that is targeted to your specific situation. 通常は、ダウンしたレプリカが復旧するまで待つことをお勧めします。Usually it is preferable to simply wait until the down replicas return.

Service Fabric クラスターの可用性Availability of the Service Fabric cluster

一般的には、Service Fabric クラスター自体は高度な分散環境で、単一障害点がありません。Generally speaking, the Service Fabric cluster itself is a highly distributed environment with no single points of failure. どのノードで障害が発生しても、クラスターの可用性または信頼性で問題が発生することはありません。これは主に Service Fabric システム サービスが、前に説明したものと同じガイドラインに従っているためです。つまり、既定で常に 3 つ以上のレプリカで実行され、こうしたステートレスのシステム サービスはすべてのノードで実行されています。A failure of any one node will not cause availability or reliability issues for the cluster, primarily because the Service Fabric system services follow the same guidelines provided earlier: they always run with three or more replicas by default, and those system services that are stateless run on all nodes. 基になる Service Fabric ネットワークとエラー検出レイヤーは完全に分散されています。The underlying Service Fabric networking and failure detection layers are fully distributed. システム サービスは総じてメタデータから再構築できるか、他の場所から状態を再同期する方法を認識しています。Most system services can be rebuilt from metadata in the cluster, or know how to resynchronize their state from other places. クラスターの可用性が低下する可能性があるのは、これまで説明したようなクォーラム損失状態がシステム サービスで発生した場合です。The availability of the cluster can become compromised if system services get into quorum loss situations like those described above. このような場合、アップグレードの開始、新しいサービスのデプロイなど、一部の操作をクラスターで実行できないことがありますが、クラスター自体はまだ起動しています。In these cases you may not be able to perform certain operations on the cluster like starting an upgrade or deploying new services, but the cluster itself is still up. 既に実行中のサービスについては、システム サービスに書き込まなくても継続して動作できるのであれば、こうした状況でも引き続き実行されます。Services on already running will remain running in these conditions unless they require writes to the system services to continue functioning. たとえば、Failover Manager でクォーラム損失が発生しても、すべてのサービスが継続して実行されますが、障害が発生しているサービスについては、Failover Manager の関与が必要であるため、自動的に再起動することはできません。For example, if the Failover Manager is in quorum loss all services will continue to run, but any services that fail will not be able to automatically restart, since this requires the involvement of the Failover Manager.

データセンターまたはAzure リージョンの障害Failures of a datacenter or Azure region

まれに、停電やネットワーク切断のために、物理的なデータ センターが一時的に使用できなくなることがあります。In rare cases, a physical data center can become temporarily unavailable due to loss of power or network connectivity. このような場合、そのデータセンターまたは Azure リージョンの Service Fabric クラスターとサービスは使用できなくなります。In these cases, your Service Fabric clusters and services in that datacenter or Azure region will be unavailable. ただし、"データは保存されます"。However, your data is preserved. Azure で実行されているクラスターの場合、Azure ステータス ページで停止時の更新を確認できます。For clusters running in Azure, you can view updates on outages on the Azure status page. 極めてまれなことですが、データ センターが物理的に一部または全体が破壊された場合、そこでホストされている Service Fabric クラスター、またはその中のサービスが失われる可能性があります。In the highly unlikely event that a physical data center is partially or fully destroyed, any Service Fabric clusters hosted there or the services inside them could be lost. これには、そのデータセンターやリージョンの外でバックアップされていない状態も含まれます。This includes any state not backed up outside of that datacenter or region.

1 つのデータセンターやリージョンにおける永続的または持続的な障害を切り抜けるための戦略は 2 つあります。There's two different strategies for surviving the permanent or sustained failure of a single datacenter or region.

  1. このような複数のリージョンで Service Fabric クラスターをそれぞれ実行し、こうした環境間でのフェールオーバーとフェールバックのメカニズムをいくつか使用します。Run separate Service Fabric clusters in multiple such regions, and utilize some mechanism for failover and fail-back between these environments. このような複数クラスターのアクティブ/アクティブまたはアクティブ/パッシブ モデルには、追加の管理および操作コードが必要です。This sort of multi-cluster active-active or active-passive model requires additional management and operations code. また、あるデータセンターやリージョンで障害が発生したときに、その中のサービスを他のデータセンターやリージョンで使用できるように、サービスのバックアップの調整も必要です。This also requires coordination of backups from the services in one datacenter or region so that they are available in other datacenters or regions when one fails.
  2. 複数のデータセンターやリージョンにまたがる 1 つの Service Fabric クラスターを実行します。Run a single Service Fabric cluster that spans multiple datacenters or regions. これがサポートされる最小構成は 3 つのデータ センターまたはリージョンです。The minimum supported configuration for this is three datacenters or regions. 推奨されるリージョンまたはデータセンターの数は 5 つです。The recommended number of regions or datacenters is five. これには、さらに複雑なクラスター トポロジが必要になります。This requires a more complex cluster topology. ただし、このモデルの利点は、1 つのデータセンターまたはリージョンの障害が、災害から通常の障害に変換される点です。However, the benefit of this model is that failure of one datacenter or region is converted from a disaster into a normal failure. こうした障害は、1 つのリージョン内のクラスターに対して有効なメカニズムで処理できます。These failures can be handled by the mechanisms that work for clusters within a single region. 障害ドメイン、アップグレード ドメイン、および Service Fabric の配置ルールにより、通常の障害が許容されるようにワークロードが分散されます。Fault domains, upgrade domains, and Service Fabric's placement rules ensure workloads are distributed so that they tolerate normal failures. この種類のクラスターにおけるサービス操作に役立つポリシーの詳細については、配置ポリシーに関するページをご覧ください。For more information on policies that can help operate services in this type of cluster, read up on placement policies

クラスター障害につながるランダムに発生する障害Random failures leading to cluster failures

Service Fabric にはシード ノードの概念があります。Service Fabric has the concept of Seed Nodes. これは基になるクラスターの可用性を維持するノードです。These are nodes that maintain the availability of the underlying cluster. 特定の種類のネットワーク障害が発生しているときに、他のノードとのリースを確立し、タイブレーカーとして機能することで、クラスターが確実に稼働し続けるうえで役立ちます。These nodes help to ensure the cluster remains up by establishing leases with other nodes and serving as tiebreakers during certain kinds of network failures. ランダムに発生する障害によりクラスターのシード ノードの大部分が削除され、元に戻らない場合、クラスターは自動的にシャット ダウンします。If random failures remove a majority of the seed nodes in the cluster and they are not brought back, the cluster automatically shuts down. Azure では、シード ノードが自動的に管理されます。つまり、シード ノードは、使用可能な障害ドメインとアップグレード ドメインに分散され、いずれか 1 つがクラスターから削除されると、代わりとなる 1 つが作成されます。In Azure, Seed Nodes are automatically managed: they are distributed over the available fault and upgrade domains, and if a single seed node is removed from the cluster another one will be created in its place.

スタンドアロンの Service Fabric クラスターと Azure の両方について、シードを実行するのは "プライマリ ノード タイプ" です。In both standalone Service Fabric clusters and Azure, the "Primary Node Type" is the one that runs the seeds. プライマリ ノード タイプを定義するとき、Service Fabric では、システム サービスごとに最大 9 個のシード ノードと 9 個のレプリカを作成することで、提供されるノード数が自動的に使用されます。When defining a primary node type, Service Fabric will automatically take advantage of the number of nodes provided by creating up to 9 seed nodes and 9 replicas of each of the system services. ランダムに発生する障害によって、こうしたシステム サービス レプリカの大部分が同時に削除されると、前に説明したように、システム サービスはクォーラム損失に移行します。If a set of random failures takes out a majority of those system service replicas simultaneously, the system services will enter quorum loss, as we described above. シード ノードの大部分が失われた場合、クラスターは直ちにシャット ダウンします。If a majority of the seed nodes are lost, the cluster will shut down soon after.

次のステップNext steps