【翻译】从 Kafka 迁移到 Raft

作者 tinywell 日期 2019-07-23
fabric 翻译
【翻译】从 Kafka 迁移到 Raft

从 Kafka 迁移到 Raft

注意：这篇文档预设前提是对通道配置更新交易有非常丰富的经验，因为这个迁移交易会涉及到多个通道配置更新交易。在你熟悉Add an Organization to a Channel这篇详细介绍如何进行通道更新的操作文章之前，请不要尝试进行 Kafka 到 Raft 的迁移

对于那些希望将基于 Kafka 共识的通道过渡到基于 Raft 共识的通道的用户来说，v1.4.2 版本允许网络中的每个通道通过一系列的通道配置更新交易实现这个目标。

这篇教程将会从一个比较宏观的层次来描述这个过程，必要时会提供具体细节，但是不会展示具体的命令操作。

假设和前提

在尝试迁移之前，请先考虑以下因素：

  1. 这个过程仅仅用于从 Kafka 到 Raft 的迁移。其他任何共识类型之间的迁移现阶段是不支持的；
  2. 迁移过程是单向的。一旦共识服务迁移到 Raft 并开始提交交易之后，就再也不可能回到 Kafka 共识了；
  3. 由于共识节点在这个过程中会停机和重启，因此迁移过程需要允许停机；
  4. 只有在合适的时间点（本文后面会介绍）进行数据备份之后才有可能从对失败的迁移进行回滚。如果你不进行备份，而迁移有失败了，那么之前的状态将无法恢复；
  5. 所有的通道必须都在同一个维护窗口期进行迁移。在恢复操作之前只对部分通道进行迁移是不可行的；
  6. 在迁移过程的最后，所有的通道都将拥有相同的 Raft 节点共识集合。这也是和系统通道中的共识集合一样的。这个特征使得我们可以判断一个迁移过程是否成功；
  7. 迁移是使用现有的已部署排序节点的账本完成的，增加或移除排序节点都需要在迁移动作完成后再进行；

宏观的迁移流程

迁移分5个阶段进行。

  1. 系统进入维护模式，应用交易将被拒绝，只有排序服务管理员可以对通道配置进行更新；
  2. 系统停止运行，考虑到迁移过程可能出错，对数据进行备份；
  3. 系统启动，每个通道的共识类型和基础数据进行了修改；
  4. 系统重启，并开始以 Raft 共识模式运行；每个通道都验证确认已经完成了选举；
  5. 系统退出维护模式并正常提供服务；

迁移准备

在尝试迁移之前有几步需要准备：

  • 规划 Raft 的部署，决定将哪些排序服务节点保留作为 Raft 的共识节点。你需要在集群中部署至少3个排序节点，但是你要知道部署至少5个节点会使得系统允许一个节点down掉从而具备高可用性，但是3节点的配置一旦有一个节点因任何原因（比如节点处于维护周期）down掉，系统将失去高可用性；
  • 准备生成 Raft 的Metadata 配置的素材。注意：所有的通道都应该接收相同的 Raft Metadata配置。参考[Raft configuration guide](Raft configuration guide) 获取这些配置项的细节。提示：你会发现使用 Raft 共识协议启动一个排序服务网络是非常容易的，然后拷贝和修改共识配置相关的基本配置参数。任何情况下，你都需要以下元素（没一个排序服务节点）：
    • hostname
    • port
    • server certificate
    • client certificate
  • 整理出系统中所有的通道（系统通道和应用通道）列表。确保你拥有合适的身份对通道配置更新进行签名。比如相应的排序服务管理员身份；
  • 确保所有的共识服务节点都运行在相同的 Fabric 版本下，这个版本需要是 v1.4.2 或更高；
  • 确保所有的 peer 节点至少是 v1.4.2 版本，确保所有的通道配置具备允许迁移的配置：
    • Orderer capability V1_4_2 （或更高）
    • Channel capability V1_4_2（或更高）

进入维护模式

在将排序服务设置为维护模式之前，建议将网络中的 peer 服务和客户端都关停。保持 peer 节点和客户端正常运行可是可行的，但是排序服务会拒绝所有请求，它们的日志中会充满无害但是容易引起误导的错误信息。

依照Add an Organization to a Channel 的知道来为所有的通道准备配置更新，从系统通道开始。在这一步中，你唯一需要修改的通道配置项是/Channel/Orderer/ConsensusType。用 JSON 格式表示的话就是：.channel_group.groups.Orderer.values.ConsensusType。

ConsensusType 配置节包含三部分：Type、Metadata 和 State：

  • Type 要么是kafka要么是etcdraft(Raft)，这个值只允许在维护模式时更改；
  • Metadata会为空当Type为kafka的时候，但当Type为 etcdraft时，这个配置项就需要携带正确的 Raft 基础参数。下文会有更多描述；
  • State 可以是NORMAL，当通道正在正常处理交易的时候，或者为MAINTENANCE，当处于迁移过程时；

通道配置更新的第一步，仅仅是将State 从 NORMAL 修改为 MAINTENANCE。不要修改 Type 和 Metadata 这两个域。注意，此时的 Type 应该为kafka。

在维护模式期间，正常交易、与迁移无关的配置更新交易以及来自其他 peer 节点的用于获取新块的 Deliver 请求都将被拒绝。这样做是为了防止 peer 迁移期间备份和必要时的还原动作同时出现，因为它们只会在迁移成功完成后才会接收更新。换句话说，我们希望能够保持排序服务的备份点（下一步将要处理的）在 peer 节点的账本前面，以便在需要时能够进行回滚。然而排序服务节点管理员可以处理 Deliver 请求（他们需要具备能力以保证迁移过程的继续）。

确保每个排序服务节点上的每一个通道都进入了维护模式。这个可以通过拉取每个通道最新的配置块并确认 Type 、Metadata 和 State 分别是 kafka 、空值(回想下，kafka 模式下没有元数据)和 MAINTENANCE。

如果通道配置都成功更新了，排序服务就可以准备开始备份了。

停止服务并备份文件

停止所有的排序服务节点，Kafka 服务和 Zookeeper 服务。首先关停排序服务节点很重要。之后，等 Kafka 服务将日志刷写到磁盘之后（通常会花费30s，但是取决于你的系统情况也可能花费更长时间），Kakfa 服务应该就停掉了。在关闭排序节点的同时关闭 kafka 服务节点可能会导致排序节点写入文件系统的状态比 kafka 记录的更新从而导致网络无法重启。

为这些服务的文件系统创建备份。然后重启 kafka 服务，在重启排序服务节点。

在维护模式下切换到 Raft

迁移过程的下一个步骤是针对每个通道的又一次通道配置更新。在这次的配置更新中，将 Tyte 修改为 etcdraft（代表 Raft）同时保持 State 为 MAINTENANCE，并填充 metadata 相关配置。强烈建议所有通道的 Metadata 配置保持一致。如果你想要使用不同的节点设置不同的共识集合，那么你需要在系统重启为etcdraft 之后重新配置 Metadata 配置项。提供相同的 Metadata 元数据就是提供相同的共识集合，这意味着当节点重启后，入股系统通道能够成功完成选举并退出维护模式，那么其他通道也能一样。为不通通道提供不通的共识集可能导致有的通道成功组件集群而有的失败。

然后，通过拉取并检查每个通道最新的配置信息来验证是否成功提交了针对 ConsensusType 的配置更新。

注意：修改 ConsensusType 的配置交易必须是重启节点（下一步）前的最后一个配置交易。如果在这一步之后有其他配置交易发生，那么很可能节点重启后会崩溃，或者产生其他未知行为。

重启并验证领导者

注意：退出维护模式必须在重启之后做。

在所有通道的 ConsensusType 都成功更新只有，停止所有排序服务节点、Kafka 服务和 Zookeeper 服务，然后仅重启排序服务节点。它们应该重启成为 Raft 节点，每个通道组建一个集群并推选出领导者。一定要确保通过观察节点日志（你会在下文中看到需要观察什么日志）来验证每个通道都选出了领导者。通过这个来确认整个过程是否成功完成。

当领导者成功选举之后，日志将会显示如下信息：

1
2
"Raft leader changed: 0 -> node-number channel=channel-name
node=node-number "

例如：

1
2
2019-05-26 10:07:44.075 UTC [orderer.consensus.etcdraft] serveRequest ->
INFO 047 Raft leader changed: 0 -> 1 channel=testchannel1 node=2

在这个例子中，节点 node2 报告通道 testchannel1 的集群中领导者已经选举出来了（领导者是 node1）。

退出维护模式

为每个通道在执行一次配置更新（把配置更新发到之前一直发的那个排序节点上），将 State 从 MAINTENANCE 修改为 NORMAL。跟以前一样，从系统通道开始。如果在系统通道上成功了，那么这个迁移在其他通道基本也是成功的。为了验证，从排序节点拉取系统通道最新的配置块并检查它的 State 是否为 NORMAL 。为了完整，在每个排序节点上都做一次这个验证。

这个过程完成之后，排序服务就准备好了在所有通道上接收任何交易。如果你按照建议的那样关停了 peer 节点和应用端，那么此时你可以重启它们了。

中止和回滚

在迁移过程中，如果是在退出维护模式之前出现了问题，那么按照如下流程执行回滚程序即可：

  1. 关停排序服务节点和 Kafka 服务（Kafka 服务节点以及配套的 Zookeeper 节点）；
  2. 将这些服务的文件系统回滚到维护模式期间在修改 ConsensusType 之前的备份上；
  3. 重启相关服务，排序服务会以维护模式下的 Kafka 共识启动；
  4. 发送配置更新退出维护模式使排序服务继续使用 Kafka 作为共识算法，或者在备份点之后恢复操作并修复阻止 Raft 节点组成合法共识集群的错误，然后使用正确的 Raft 配置元数据 Metadata 重试迁移操作。

下面有几种状态可以用来判断迁移是否失败：

  1. 有些节点崩溃或停止运行；
  2. 日志中没有针对每个通道正常选举出领导者的记录；
  3. 将系统通道的维护模式修改为 NORMAL 动作失败。

附录

原文：Migrating from Kafka to Raft

FEATURED TAGS
fabric 翻译
FRIENDS