配置和管理raft排序服务--翻译自Fabric1.4官方文档

     最近又需要用fabric来做项目,之前只关注到fabric1.1版本,现在最新的是1.4版本。因此主要看了一些1.4和之前的版本不同的内容。比如1.4增加了etcdraft共识算法。因此接下来会翻译几篇fabric1.4官方文档,供大家参考。基本都是对着google翻译来做的,把一些不符合中文顺序和专业术语的地方,稍微调整下,并且加了一些自己的理解和解释。

下面这篇“配置和管理raft排序服务”,原文链接是:

https://hyperledger-fabric.readthedocs.io/en/latest/raft_configuration.html

如果觉得看得不太理解的时候,可以对着英文版来看。

 

以下是正文:

 

配置和管理raft排序服务

适合读者:raft排序节点管理员

 

概念概述:

    对于排序服务的概念和怎样支持排序服务(包括raft),可以查看“排序服务”的文档。

   要了解设置排序节点的过程 - 包括创建本地MSP和创建创建块 - 请查看我们关于“设置排序节点”的文档。

一.配置

   每个raft节点必须加入系统channel,而不必加入每一个应用channel(解释:因为Raft服务是嵌入在orderer节点里。)并且raft节点可以动态的加入或者退出某个channel,而不影响其他节点。后面的“重设配置”部分描述了该过程。

   Raft节点通过tls证书互相认证,如果想冒充一个raft节点,攻击者必须获得tls证书的私钥。总的来说就是,如果没有有效的tls配置,是不可能运行一个raft节点的。

  一个raft集群需要配置以下两方面:

  1. 本地配置。包括治理节点的详细配置,比如tls通信,备份副本的行为和文件存储。
  2. 管道配置。定义相应的管道下包含的raft集群的成员关系,协议的详细参数,比如心跳频率,领导者超时时间等。

 

每个channel都有属于它自己的正在运行的raft协议实例。因此,必须在其所属的每个channel的配置中引用该Raft节点,方法是将其服务器和客户端TLS证书(PEM格式)添加到通道配置中。这确保了当其他节点从其接收消息时,它们可以安全地确认发送消息的节点的身份。

(注解: 1个channel可以包含多个raft节点,一个raft节点可以加入多个channel,不同的channel可能包含不同的raft集群,这些不同的raft集群可能会拥有不同的leader节点)

 

下面的配置来自于configtx.yaml里的片段,展示了在一个channel里包含了三个raft节点(也称之为共识节点)

Consenters:

            - Host: raft0.example.com

              Port: 7050

              ClientTLSCert: path/to/ClientTLSCert0

              ServerTLSCert: path/to/ServerTLSCert0

            - Host: raft1.example.com

              Port: 7050

              ClientTLSCert: path/to/ClientTLSCert1

              ServerTLSCert: path/to/ServerTLSCert1

            - Host: raft2.example.com

              Port: 7050

              ClientTLSCert: path/to/ClientTLSCert2

              ServerTLSCert: path/to/ServerTLSCert2

 注意,一个orderer将会作为系统channel和任何人们加入的应用channel的共识节点。

   (总结:证明channel分两种,一种是系统channel,另一种是用户新建的应用channel)

 

创建channel配置块后,configtxgen工具将读取TLS证书的路径,并将这些路径替换为证书的相应字节。

 

第一部分:本地配置

   Orderer.yaml配置文件里包含两部分配置是和raft orderer相关的。

   一个是集群配置,主要包含tls通信的配置。另一个是共识配置,主要包含写入的日志和快照存储在哪里。

  (1)集群参数:

   默认情况下, Raft服务在与面向客户端的服务器(用于发送事务或拉块)相同的gRPC服务器上运行,但它可以配置为具有单独的gRPC服务器和单独的端口。

这对于您希望由组织CA颁发的TLS证书,但仅由群集节点用于彼此之间通信的情况以及由面向客户端的API的公共TLS CA颁发的TLS证书的情况非常有用。

  1. ClientCertificateClientPrivateKey:客户端TLS证书和相应私钥的文件路径。
  2. ListenPort:群集侦听的端口。如果为空,则端口与orderer general port(general.listenPort)的端口相同
  3. ListenAddress:群集服务正在侦听的地址。
  4. ServerCertificateServerPrivateKey:TLS服务器证书密钥对,在群集服务在单独的gRPC服务器(不同端口)上运行时使用。
  5. SendBufferSize:规定出口缓冲区中的消息数。

注:ListenPortListenAddressServerCertificateServerPrivateKey必须是一起设置或取消在一起。如果它们未设置,则它们继承自通用TLS部分,例如。general.tls.{privateKeycertificate}

 

   (解释:默认情况下,raft服务的端口和orderer之前互相通信的grpc端口是一样的,但可以把端口配置成不一样。主要用于以下用途,如果不想继承通用TLS的配置,而是使用某些ca组织颁发的TLS证书,配置成不一样后,这些TLS证书则仅限于raft服务集群的节点使用,并且可以和同样使用这些CA组织颁发的证书的客户端进行通信)

  

   其他的一些隐藏的配置参数,比如general.cluster可用于进一步微调集群通信或复制机制:

  1. DialTimeoutRPCTimeout:指定创建连接和建立流的超时。
  2. ReplicationBufferSize:为从其他集群节点进行块复制,而分配的内存缓冲区的最大字节数。Raft节点里可以属于多个通道,每个通道都有自己的内存缓冲区,因此可以为不同的channel设置不同的值。默认20971520,即为20MB。
  3. PullTimeout:排序节点在中止之前等待接收块的最​​长持续时间。默认为五秒。
  4. ReplicationRetryTimeout:排序节点在两次连续尝试(重试)之间等待的最长持续时间。默认为五秒。(这是排序节点之前的通信出错后,等待重试的时间)
  5. ReplicationBackgroundRefreshInterval:连续两次尝试复制添加此节点的现有通道之间的时间,或此节点过去无法复制的通道之间的时间。默认为五分钟。(注解:对于节点正常加入的通道,和过去复制日志失败的通道,定时尝试的时间,默认为5分钟进行一次channel的复制)

  

 (2)共识参数

   WALDiretcd/raft存储Write Ahead Logs的位置。每个通道都有自己的子目录,以通道ID命名。

SnapDir:指定etcd/raft存储快照的位置。每个通道都有自己的子目录,以通道ID命名。

  

   还有一个隐藏的配置参数可以通过在orderer.yaml的共识部分添加以下参数来设置。

  1. EvictionSuspicion:怀疑已经被channel驱逐(表示channel认为节点已经失去连接)的累积时间段。时间到达后,将会触发节点从其他节点拉取块,并查看它是否已从channel中逐出,以确认其怀疑。如果怀疑被确认(被检查的块不包含该节点的TLS证书),则该节点停止其对该channel的操作。当一个节点不知道任何当选的领导者,也不能被选为该频道的领导者时,该节点怀疑其频道被驱逐。默认为10分钟。

(注解:这个参数主要是用来处理raft集群脑裂或者节点因为某些原因和集群断开连接的处理。)这里应该会有一个类似的机制,如果一直有通信,在区块里能找到节点的tls证书,则不会怀疑,如果长时间没有通信,并且从其他节点拉去块后发现并不包含该节点的tls证书,证明channel已经把该节点剔除在外了。)

      这两类参数需要实际调试下,才能知道效果怎样。

 

  第二部分:channel配置

除了已经讨论过的共识参数之外,Raft channel配置还有一个与协议相关的Options配置。目前无法在节点运行时动态更改这些配置的值,必须重设配置并重新启动节点。

唯一的例外是SnapshotIntervalSize参数,可以在运行时调整。

注意:建议避免更改以下值,因为错误的配置可能会导致根本无法选出领导者的状态(例如:如果TickIntervalElectionTick参数的值都非常低)。在这种配置情况下,领导者节点是无法被选出的,因为领导者需要做出改变。由于存在这样的危险,我们建议大多数情况下不要调整这些参数。

  • TickInterval:两次Node.Tick调用之间的时间间隔。
  • ElectionTickNode.Tick选举之间必须通过的调用次数。也就是说,如果追随者在ElectionTick过去之前没有收到当前任期的领导者的任何消息,它将成为候选人并开始选举。
  • ElectionTick必须大于HeartbeatTick
  • HeartbeatTickNode.Tick必须在心跳之间传递的调用数。也就是说,领导者发送心跳消息以维持其领导地位HeartbeatTick
  • MaxInflightBlocks:在乐观复制阶段限制正在进行的附加块的最大数量。
  • SnapshotIntervalSize:定义拍摄快照的字节数。

 

(注意:这里设置的各种tick的次数后,所花的实际时间=TickInterval* Tick的次数。比如,TickInterval=5秒,ElectionTick=3,也就是15秒之内如果收不到leader的任何消息,则节点会成为候选人,发起选举流程。

 

二.重设配置

Raft orderer支持动态(意味着在通道正在服务时)添加和删除节点,只要一次只添加或删除一个节点。请注意,在尝试重新配置群集之前,群集必须是可操作的并且能够达成共识。例如,如果您有三个节点,并且两个节点发生故障,您将无法通过重新配置群集来删除这些节点。同样,如果在具有三个节点的通道中有一个故障节点,则不应尝试轮换证书,因为这会导致第二个故障。作为一项规则,除非所有共识节点都在线且健康,否则你不应尝试对Raft共识节点进行任何配置更改,例如添加或删除共识节点,或更换共识节点的证书,

如果您决定更改这些参数,建议仅在维护周期中尝试进行此类更改。在仅具有少数节点的群集中,并且其中一个节点已经关闭,这时尝试更新配置,最有可能发生问题。例如,如果您的共识集群中有三个节点,其中一个节点已关闭,则表示三个节点中有两个处于活动状态。如果在此状态下将群集扩展到四个节点,则四个节点中只有两个处于活动状态,这不是法定数量(需要大于一半数量)。那么这时第四个节点将无法登陆,因为节点只能登陆到正常运行的集群(除非集群的总大小为一或两个)。

因此,通过将三个节点的集群扩展到四个节点(而只有两个节点处于活动状态),您实际上讲会被卡住,直到原始离线节点重新正常上线为止。

将新节点添加到Raft群集可以通过以下方式:

  1. 通过通道配置更新事务将新节点的TLS证书添加到通道。注意:在添加到一个或多个应用程序通道之前,必须将新节点添加到系统通道。
  2. 从作为系统通道一部分的orderer节点获取系统通道的最新配置块
  3. 通过检查所获取的配置块是否包含(即将添加)节点的证书,确保将要添加的节点是系统通道一部分
  4. 使用General.GenesisFile配置参数中配置块的路径 启动新的Raft节点
  5. 等待Raft节点从已添加其证书的所有通道的现有节点复制块。完成此步骤后,节点开始为通道提供服务。
  6. 新添加的Raft节点的端点添加到所有通道的通道配置中。

在节点本身运行时,可以将已经运行的节点(并且已经参与某些通道)添加到通道。为此,只需将节点的证书添加到通道的通道配置中。节点将自动检测其对新通道的添加(此处的默认值为五分钟,但如果您希望节点更快地检测新通道,请重新启动节点)并从通道中的orderer处提取通道块,然后启动该链的Raft实例。

成功完成后,可以更新通道配置以包括新Raft orderer的endpoint。

从Raft集群中删除节点是通过以下方式完成的:

  1. 从所有通道的通道配置中删除其endpoint,包括由orderer管理员控制的系统通道。
  2. 从所有通道的通道配置中删除通过证书认证的节点条目。同样,这包括系统通道。
  3. 关闭节点。

从特定通道中删除节点,但保持其为其他通道服务是通过以下方式完成的:

  1. 从通道的通道配置中删除其endpoint。
  2. 从通道配置中删除通过证书认证的节点条目。
  3. 第二阶段导致:
    • 对于这个删除了该节点的channel,通道中剩余的orderer节点停止与该orderer节点通信。但他们可能仍然在同该节点的其他channel进行通信。
    • 从通道中删除的节点将立即或在经过EvictionSuspicion一段时间(默认为10分钟)后自动检测到它已被channel移除,接着将关闭其Raft实例。

 

 三.orderer节点的TLS证书轮换

所有TLS证书的到期日期均由发行方确定。这些到期日期可以从发布之日起10年到最短几个月,因此请咨询您的发行人。在到期日之前,您需要在节点本身和节点所连接的每个通道(包括系统通道)上轮换这些证书。

(解释:order集群里的节点证书是有可能会过期的,因此快过期的时候,为了避免停止所有节点去更换证书,采取逐个节点更新证书,直至所有节点都更新完证书这样的操作,称之为证书轮换)

对于节点参与的每个频道:

  1. 使用新证书更新通道配置。
  2. 在节点的文件系统中替换其证书。
  3. 重新启动节点。

由于节点只能有一个TLS证书密钥对,因此该节点将无法为更新过程中未添加新证书的服务提供服务,从而降低了容错能力。因此, 一旦证书轮换过程开始,就应该尽快完成。

如果由于某种原因TLS证书的轮换已经开始但无法在所有通道中完成,建议将TLS证书转回原来的版本并稍后尝试轮换。

 

四.度量

有关Operations Service的说明以及如何进行设置,请查看 有关Operations Service的文档

有关运营服务收集的指标的列表,请查看有关指标参考资料

虽然您优先考虑的指标与您的特定用例和配置有很大关系,但您可能希望监控两个指标:

  • consensus_etcdraft_is_leader:标识群集中的哪个节点当前是领导者。如果没有此节点的节点,则代表节点已经和leader节点失联。
  • consensus_etcdraft_data_persist_duration:表示对Raft集群的持久写入日志记录执行的写入操作的时间。为了协议安全,消息必须持久保存,fsync在适当的情况下调用,然后才能与同意者集合共享。如果此值开始攀升,则此节点可能无法参与共识(这可能导致此节点和可能的网络的服务中断)。

五.故障排除

  • 您对节点施加的压力越大,您可能需要更改某些参数。与任何系统,计算机或机械一样,压力会导致性能下降。正如我们在概念部分中所提到的那样,当跟随者节点一定时间内,没有收到从领导者那里传过来的“心跳”消息或“追加(日志)”消息时,会触发Raft中的领导者选举。因为Raft节点在多个通道中共享相同的通信层(这并不意味着它们共享数据 - 它们不共享!),如果Raft节点是许多通道中的共识集合的一部分,您可能希望延长触发领导者选举的时间,来避免无意(无意义)的领导人的选举。

(解释:多个channel的raft实例可以在同一个orderer节点运行,因此才说raft节点在多个通道中共享相同的通信层。如果触发领导着选举的时间过短,则代表在很短的时间内如果收不到领导节点的消息,则认为已经和领导节点失去联系,而重新进行领导者选举。这样极有可能是其实和领导者并没有失去联系,只是因为网络波动的原因,数据传输出现一定延时而已,频繁的进行领导者重选,会大大降低整个集群的服务性能)

 

 

 

 

你可能感兴趣的:(区块链,hyperledger,fabric)