Split Brain Resolver-akka集群脑裂问题解决

本文主要是介绍Split Brain Resolver-akka集群脑裂问题解决，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Split Brain Resolver-akka集群脑裂问题解决

  Akka集群脑裂_akka脑裂-CSDN博客
        操作 Akka 集群时必须考虑如何处理网络分区（又称裂脑场景）和机器崩溃（包括 JVM 和硬件）失败）。如果您使用集群单例或集群分片，这对于正确行为至关重要，特别是与 Akka Persistence 一起使用。
    
    使用 Akka Split Brain Resolver 是 akka-cluster 的一部分，您可能已经包含该依赖项。否则，请在您的项目中添加以下依赖项：

启用裂脑解析器

    您需要通过在 ActorSystem (application.conf) 的配置中将其配置为 downing 提供程序来启用 Split Brain Resolver：

akka.cluster.downing-provider-class = "akka.cluster.sbr.SplitBrainResolverProvider"

您还应该考虑不同的可用减量策略。

问题

    分布式系统的一个基本问题是网络分区（裂脑场景）和机器崩溃对于观察者来说是无法区分的，即一个节点可以观察到另一个节点存在问题，但它无法判断自己是否已经崩溃，并且永远不会被修复。再次可用，或者存在网络问题，一段时间后可能会或可能不会再次修复。暂时性失败和永久性失败是无法区分的，因为决策必须在有限的时间内做出，并且总是存在持续时间超过决策时限的暂时性失败。
        第三类问题是进程无响应，例如由于过载、CPU 不足或垃圾收集长时间暂停。这也与网络分区和崩溃没有区别。我们做出决定的唯一信号是“在给定的心跳时间内没有回复”，这意味着导致延迟或丢失心跳的现象彼此无法区分，必须以相同的方式处理。
        当发生崩溃时，我们希望立即从集群成员资格中删除受影响的节点。当出现网络分区或进程无响应时，我们希望等待一段时间，希望这是一个短暂的问题，能够再次修复，但在某些时候，我们必须放弃并继续处理一侧的节点分区并关闭另一侧的节点。此外，某些功能在分区期间并不完全可用，因此如果分区花费的时间太长，分区是否是暂时的可能并不重要。这两个目标是相互冲突的，并且在我们删除崩溃节点的速度和对瞬态网络分区的过早采取行动之间存在权衡。
        由于网络分区不同侧的节点无法相互通信，这是一个很难解决的问题。我们必须确保双方能够自己做出这个决定，并且对于哪些部分继续运行、哪些部分自行关闭做出相同的决定。
        另一种难以看到“正确”图片的问题是，某些节点未完全连接，无法直接相互通信，但信息可以通过其他节点在它们之间传播。
        Akka 集群有一个故障检测器，它会注意到网络分区和机器崩溃（但它无法区分两者）。它使用定期的心跳消息来检查其他节点是否可用且运行状况良好。故障检测器的这些观察结果被称为节点_不可访问_，并且可能会变得_可访问_如果故障检测器观察到它可以再次与其通信，则再次。
        故障检测器本身不足以在所有情况下做出正确的决策。最简单的方法是在超时后从集群成员资格中删除无法访问的节点。这对于崩溃和短暂的短暂网络分区非常有用，但不适用于长网络分区。网络分区的双方都会将另一方视为无法访问，并在一段时间后将其从集群成员资格中删除。由于这种情况发生在两侧，结果是创建了两个独立的、断开连接的集群。
        如果将基于超时的自动关闭功能与集群单例或集群分片结合使用，则意味着将运行两个单例实例或两个具有相同标识符的分片实体。其中一个正在运行：每个集群中都有一个。例如，当与 Akka Persistence 一起使用时，可能会导致具有相同 persistenceId 的持久 Actor 的两个实例同时运行并写入同一持久事件流，这将在以下情况下产生致命后果：重播这些事件。
        Akka Cluster 中的默认设置是不自动删除无法访问的节点，建议由人工操作员或外部监控系统来决定要做什么。这是一个有效的解决方案，但如果您因其他原因没有此人员或外部系统，则不太方便。
        如果无法访问的节点根本没有关闭，它们仍然是集群成员身份的一部分。这意味着集群单例和集群分片不会故障转移到另一个节点。虽然存在无法访问的节点，但加入集群的新节点将不会被提升为完全有价值的成员（状态为 Up）。同样，在解决所有不可达节点之前，不会删除离开的成员。换句话说，无限期地保留无法联系的成员是不可取的。
        介绍了问题域后，是时候看看所提供的处理网络分区、无响应节点和崩溃节点的策略了。

策略

    默认情况下，将使用保留多数策略，因为它适用于大多数系统。然而，值得考虑其他可用的策略并选择适合您系统特征的策略。例如，在 Kubernetes 环境中，租赁策略可能是一个不错的选择。
        每个策略都有一个失败场景，在该场景中它会做出“错误”的决定。本节介绍不同的策略以及何时使用什么的指南。
    当存在不确定性时，它会选择关闭超出必要数量的节点，甚至关闭所有节点。因此，Split Brain Resolver 应该始终与自动启动已关闭的节点的机制相结合，并将它们加入现有集群或再次形成新集群。
    您可以使用配置属性启用策略akka.cluster.split-brain-resolver.active-strategy

稳定后

    所有策略均处于非活动状态，直到集群成员资格和不可达节点的信息在一定时间内稳定为止。在网络分区时持续添加更多节点不会影响此超时，因为当存在不可达节点时，这些节点的状态不会更改为 Up。加入节点不计入策略逻辑中。

# To enable the split brain resolver you first need to enable the provider in your application.conf:
# akka.cluster.downing-provider-class = "akka.cluster.sbr.SplitBrainResolverProvider"akka.cluster.split-brain-resolver {# Select one of the available strategies (see descriptions below):# static-quorum, keep-majority, keep-oldest, down-all, lease-majorityactive-strategy = keep-majority# Time margin after which shards or singletons that belonged to a downed/removed# partition are created in surviving partition. The purpose of this margin is that# in case of a network partition the persistent actors in the non-surviving partitions# must be stopped before corresponding persistent actors are started somewhere else.# This is useful if you implement downing strategies that handle network partitions,# e.g. by keeping the larger side of the partition and shutting down the smaller side.# Decision is taken by the strategy when there has been no membership or# reachability changes for this duration, i.e. the cluster state is stable.stable-after = 20s# When reachability observations by the failure detector are changed the SBR decisions# are deferred until there are no changes within the 'stable-after' duration.# If this continues for too long it might be an indication of an unstable system/network# and it could result in delayed or conflicting decisions on separate sides of a network# partition.# As a precaution for that scenario all nodes are downed if no decision is made within# `stable-after + down-all-when-unstable` from the first unreachability event.# The measurement is reset if all unreachable have been healed, downed or removed, or# if there are no changes within `stable-after * 2`.# The value can be on, off, or a duration.# By default it is 'on' and then it is derived to be 3/4 of stable-after, but not less than# 4 seconds.down-all-when-unstable = on}

    将 akka.cluster.split-brain-resolver.stable-after 设置为较短的持续时间，以便更快地删除崩溃的节点，但代价是可能会过早对本来可以修复的临时网络分区采取行动。不要将此持续时间设置为比集群中的成员资格传播时间短的持续时间，这取决于集群的大小。不同集群大小的建议最短持续时间：

不同的策略可能具有如下所述的附加设置。

笔记
在所有节点上使用相同的配置非常重要。

    决定自行关闭的分片一侧将使用集群_down_ 命令来启动集群成员的删除。当它被传播到可访问的节点中时，它将从集群成员资格中删除。
    当节点从集群中删除时，最好终止ActorSystem并退出 JVM。
    这是由协调关闭处理的，但要退出 JVM，建议您启用：

akka.coordinated-shutdown.exit-jvm = on

笔记
某些旧容器可能会阻止对 System.exit(…) 的调用，您可能必须找到另一种方法来关闭应用程序。例如，当在 Spring / Tomcat 设置之上运行 Akka 时，您可以将对 System.exit(…) 的调用替换为对 Spring 的 ApplicationContext .close() 方法的调用（或对 Tomcat Manager 的 HTTP 调用）用于取消部署应用程序的 API）。

五种策略

    SBR分tatic-quorum, keep-majority, keep-oldest, down-all, lease-majority 五种strategies

保持多数

akka cluster split-brain-resolver(SBR)_lease-majority-CSDN博客
    名为keep-majority的策略将根据最后已知的成员信息，如果当前节点占多数，则关闭无法访问的节点。否则，沿着可到达的节点，即自己的部分。如果这些部分大小相等，则保留包含具有最低地址的节点的部分。
    当集群中的节点数量动态变化且因此无法使用时，此策略是一个不错的选择static-quorum。
    此策略还可以处理在网络分区发生的同时发生成员资格更改时可能发生的边缘情况。例如，一侧的两个成员的状态更改为 Up，但在连接断开之前该信息不会传播到另一侧。然后一方会看到另外两个节点，双方可能会认为自己拥有多数。它将检测到这种情况，并做出安全的决定，如果加入节点更改为另一侧的 Up，则关闭该侧可能属于少数的所有节点。请注意，这有一个缺点，如果加入节点未更改为 Up 并成为另一侧的多数节点，则每个部分将自行关闭，从而终止整个集群。
    请注意，如果有两个以上的分区且没有一个占多数，则每个部分都会自行关闭，从而终止整个集群。
    如果超过一半的节点同时崩溃，其他正在运行的节点将自行关闭，因为它们认为自己不占多数，从而整个集群被终止。
    决策可以基于已配置的节点role，而不是集群中的所有节点。当某些类型的节点比其他类型的节点更有价值时，这会很有用。例如，您可能有一些节点负责持久数据，而一些节点则负责无状态工作服务。那么，保留尽可能多的持久数据节点可能更重要，即使这意味着关闭更多工作节点。
    配置：

akka.cluster.split-brain-resolver.active-strategy=keep-majority

akka.cluster.split-brain-resolver.keep-majority {# if the 'role' is defined the decision is based only on members with that 'role'role = ""
}

静态法定人数

    如果剩余节点数量大于或等于配置的数量，名为static-quorum的策略将关闭不可达的节点。否则，它将关闭可访问的节点，即它将关闭分区的那一侧。换句话说， 定义了集群必须运行的最小节点数。quorum-sizequorum-size
    当集群中有固定数量的节点，或者可以定义具有特定角色的固定数量的节点时，此策略是一个不错的选择。
    例如，在 9 节点集群中，您将quorum-size 配置为 5。如果网络分裂为 4 和 5 个节点，则具有 5 个节点的一侧将继续存在，而另一侧将继续存在4 个节点将被关闭。此后，在 5 节点集群中，无法再处理任何故障，因为剩余集群大小将小于 5。如果该 5 节点集群中再次发生故障，所有节点都将被关闭。
    因此，在删除旧节点后加入新节点非常重要。
    这样做的另一个后果是，如果在启动集群时存在不可访问的节点，在达到此限制之前，集群可能会立即自行关闭。如果您几乎同时启动所有节点或在领导者将“正在加入”成员的成员状态更改为“已启动”之前使用 akka.cluster.min-nr-of-members 定义所需的成员数量，则这不是问题。您可以使用 stable-after 设置来调整超时时间，在该超时时间后做出停机决定。
    向集群添加的成员数量不得超过quorum-size * 2 - 1。如果违反此建议，则会记录警告。如果在需要 SBR 决策时仍然超出集群大小，它将关闭所有节点，否则存在双方可能互相关闭并从而形成两个独立集群的风险。
    对于滚动更新，最好通过协调关闭 (SIGTERM) 优雅地离开集群。为了成功离开，将不会使用 SBR（不会停机），但如果在滚动更新过程中同时出现不可达问题，则可能会做出 SBR 决策。为避免滚动更新期间未超出成员总数限制，建议在使用 static-quorum 时，先保留并完全删除一个节点，然后再添加新节点。
    如果集群分为 3 个（或更多）部分，每个部分都小于配置时的数量quorum-size 将自行关闭并可能关闭整个集群。
    如果超过配置的节点数量quorum-size同时崩溃，其他正在运行的节点将自行关闭，因为它们认为自己不占多数，从而导致整个集群终止.
    决策可以基于已配置的节点role，而不是集群中的所有节点。当某些类型的节点比其他类型的节点更有价值时，这会很有用。例如，您可能有一些节点负责持久数据，而一些节点则负责无状态工作服务。那么，保留尽可能多的持久数据节点可能更重要，即使这意味着关闭更多工作节点。
    role还有另一种用途。通过为集群中的一些（例如 7 个）稳定节点定义 role 并在 static-quorum 的配置中使用它，您将能够动态添加和删除其他节点没有此角色的节点仍然可以很好地决定在网络分区的情况下哪些节点保持运行以及关闭哪些节点。与 keep-majority（如下所述）相比，此方法的优点是您_不会_冒将集群分成两个独立的风险集群，即_裂脑_*。您仍然必须遵守如上所述的不要使用此 role 启动太多节点的规则。如上所述，如果集群中没有足够的节点剩余此role，并且出现故障，它还会面临关闭所有节点的风险。
    配置：

akka.cluster.split-brain-resolver.active-strategy=static-quorum

akka.cluster.split-brain-resolver.static-quorum {# minimum number of nodes that the cluster must havequorum-size = undefined# if the 'role' is defined the decision is based only on members with that 'role'role = ""
}

保持最旧的

    名为keep-oldest的策略将删除不包含最旧成员的部分。最旧的成员很有趣，因为活动的 Cluster Singleton 实例运行在最旧的成员上。
    如果 down-if-alone 配置为 on，则此规则有一个例外。然后，如果最旧的节点已与所有其他节点分区，则最旧的节点将自行关闭并保持所有其他节点运行。当最旧的节点是集群中唯一剩余的节点时，该策略不会关闭该节点。
    请注意，如果最旧的节点崩溃，其他节点会在 down-if-alone on 时将其从集群中删除，否则如果最旧的节点崩溃，它们将自行关闭崩溃，即关闭整个集群以及最旧的节点。
    如果您使用 Cluster Singleton 并且不想关闭单例实例运行的节点，则可以很好地使用此策略。如果最旧的节点崩溃，新的单例实例将在下一个最旧的节点上启动。缺点是该策略可能只保留大型集群中的少数节点。例如，如果最旧的一部分由 2 个节点组成，另一部分由 98 个节点组成，那么它将保留 2 个节点并关闭 98 个节点。
    此策略还可以处理在网络分区发生的同时发生成员资格更改时可能发生的边缘情况。例如，最旧成员的状态在一侧更改为 Exiting，但在连接断开之前该信息不会传播到另一侧。它将检测到这种情况，并做出安全的决定，关闭最旧的节点一侧的所有节点Leaving。请注意，这有一个缺点，如果最旧的是 Leaving 并且未更改为 Exiting，那么每个部分都会自行关闭，从而终止整个集群。
    决策可以基于已配置的节点role而不是集群中的所有节点，即使用具有该角色的节点内最旧的成员（单例）。
    配置：

akka.cluster.split-brain-resolver.active-strategy=keep-oldest

akka.cluster.split-brain-resolver.keep-oldest {# Enable downing of the oldest node when it is partitioned from all other nodesdown-if-alone = on# if the 'role' is defined the decision is based only on members with that 'role',# i.e. using the oldest member (singleton) within the nodes with that rolerole = ""
}

全部下down-all

    名为的策略down-all将关闭所有节点。
    如果网络环境高度不稳定，无法完全信任不可达观察结果，并且经常出现间接连接的节点。由于不稳定性，分区不同侧的不同信息的风险增加，因此其他策略可能会导致决策冲突。在这种环境中，最好关闭所有节点并启动一个新的集群。
    关闭所有节点意味着系统将完全不可用，直到节点重新启动并形成新的集群。不建议大型集群（> 10 个节点）使用此策略，因为任何小问题都会关闭所有节点，并且在较大的集群中更有可能发生这种情况，因为有更多节点可能会发生故障。
另请参阅不稳定时关闭所有和间接连接的节点.

租多数

    名为lease-majority的策略使用分布式租约（锁）来决定允许哪些节点生存。只有一个 SBR 实例可以获得租约并决定保持运行状态。另一方将无法获得租约，因此将自行放弃。
    最好的努力是保留拥有最多节点的一侧，即多数一侧。这是通过在少数一方尝试获得租赁之前增加延迟来实现的。
    目前有一种受支持的租约实现，由 Kubernetes 中的自定义资源定义 (CRD) 支持。 Kubernetes Lease 文档对此进行了描述。
    该策略非常安全，因为协调是由外部仲裁器添加的。与其他策略相比，其需要权衡的是，它需要额外的基础设施来实施租赁，并且降低了支持租赁存储的系统决策的可用性。
    与其他策略类似，重要的是决策不要推迟太久，因为无法获取租约的节点必须自行决定关闭，请参阅不稳定时关闭全部。
    在某些情况下，当所有 SBR 实例需要做出决策时，租约将不可用，例如因为它位于网络分区的另一侧，然后所有节点都将被关闭。
    配置：

akka {cluster {downing-provider-class = "akka.cluster.sbr.SplitBrainResolverProvider"split-brain-resolver {active-strategy = "lease-majority"lease-majority {lease-implementation = "akka.coordination.lease.kubernetes"}}}
}

akka.cluster.split-brain-resolver.lease-majority {lease-implementation = ""# The recommended format for the lease name is "<service-name>-akka-sbr".# When lease-name is not defined, the name will be set to "<actor-system-name>-akka-sbr"lease-name = ""# This delay is used on the minority side before trying to acquire the lease,# as an best effort to try to keep the majority side.acquire-lease-delay-for-minority = 2s# Release the lease after this duration.release-after = 40s# If the 'role' is defined the majority/minority is based only on members with that 'role'.role = ""
}

另请参阅Kubernetes Lease中的配置和其他依赖项

间接连接的节点

    在出现故障的网络中，可能会出现这样的情况：节点通过某些网络链路被观察为无法访问，但它们仍然通过其他节点间接连接，即这不是一个干净的网络分区（或节点崩溃）。
    当检测到这种情况时，裂脑解析器将保持完全连接的节点并关闭所有间接连接的节点。
    如果存在间接连接的节点和干净的网络分区的组合，它将把上述决策与普通决策结合起来，例如在排除可疑故障检测观察结果后保留多数。

down-all-when-unstable不稳定时全部下降

akka.cluster.split-brain-resolver {down-all-when-unstable = 15sstable-after = 20s
}

multiple-data-centers多个数据中心

cluster-singleton-and-cluster-sharding集群单例和集群分片

expected-failover-time预期故障转移时间

这篇关于Split Brain Resolver-akka集群脑裂问题解决的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！