配置和操作Raft排序服务

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

概念概述

关于order的概念和ordering service的实现(包含Raft)的详细描述,查看 Ordering Service

学习安装order节点(包含创建本地msp和创建创始区块),查看Setting up an ordering node

配置

每一个Raft节点必须添加到系统通道,不必添加到应用通道。此外,可以动态的删除和添加节点到通道而不用影响其它节点,这部分描述在文档下面的重新配置部分。

Raft节点身份使用TLS确认,因此攻击者要冒充节点,需要获取TLS证书的私钥。因此如果没有有效的TLS配置,就不能运行Raft节点。

一个Raft集群配置分两个层面:

  • Local configuration:管理特定于节点的方面,如TLS通信、复制行为和文件存储。
  • Channel configuration: 定义相应通道的Raft集群成员,以及特定于协议的参数,如心跳频率、引导超时等。

回想一下,每个通道都有自己运行的Raft协议实例。这样,一个Raft节点必须通过将其服务器和客户端TLS证书(PEM格式)添加到channel config中来引用它所属的每个channel的配置。这保证了其它节点接到它的信息时,它们可以安全的确认发送信息的节点身份。

下面部分是configtx.yaml中展示三个Raft节点(也叫consenters)在通道:

       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成为系统通道的consenter ,也会成为它加入的所有通道的consenter 。

当通道配置block创建后,configtxgen工具读取路径指向的TLS证书,并将路径替换成证书的字节内容。

Local configuration

orderer.yaml中有两个配置部分与Raft orderers相关。

Cluster:它决定了TLS通信配置。以及共识,它决定了 Write Ahead Logs(预写日志)和Snapshots(快照)的存储。

Cluster parameters: 默认的,Raft服务运行在相同的gRPC server作为client面对server(用来发送交易和拉取区块),但它可以配置成独立的gRPC server和独立的port。

这对于需要由组织CA颁发TLS证书的情况非常有用,但只在cluster节点之间通信时使用,公共TLS CA为面向客户端的API颁发的TLS证书。

  • ClientCertificate,ClientPrivateKey:客户端TLS证书的文件路径和相应的私钥。
  • ListenPort:cluster监听的端口。如果为空,端口和orderer的普通端口相同(general.listenPort)
  • ListenAddress:cluster 服务监听的地址。
  • ServerCertificate,ServerPrivateKey:TLS server证书秘钥对,这用来当cluster 服务运行在单独的gRPC服务器上(不同的port)。
  • SendBufferSize:调节出口缓冲区中的消息数。

注意:ListenPort,ListenAddress,ServerCertificate,ServerPrivateKey 必须要不都设置,要不都不设置。如果没有设置,从TLS部分继承,例如general.tls.{privateKey, certificate}。

他们也为general.cluster隐藏配置参数,可用于进一步微调集群通信或复制机制。

  • DialTimeoutRPCTimeout: 制定创建连接和建立流的超时。
  • ReplicationBufferSize:可为用于其他集群节点进行块复制的每个内存缓冲区分配的最大字节数。每个通道有自己的内存缓存,默认是20971520 (20MB)。
  • PullTimeout:排序节点在终止之前等待接受到块的最长持续时间,默认为5秒。
  • ReplicationRetryTimeout:排序节点在两次连续尝试之间等待的最长持续时间,默认为5秒。
  • ReplicationBackgroundRefreshInterval:连续两次尝试复制此节点添加到现有通道之间的时间,或此节点过去未能复制的通道之间的时间。默认为5分钟。
  • TLSHandshakeTimeShift:如果订购节点的TLS证书过期且未及时更换(请参阅下面的TLS证书轮换),则无法建立他们之间的通信,并且无法向订购服务发送新的事务。为了从这样的场景中恢复,有可能使排序节点之间的TLS握手考虑向后移动的时间(配置为TLSHandshakeTimeShift)。为了尽可能不具侵入性,此配置选项仅影响使用单独gRPC服务器进行集群内通信的排序节点。如果cluster的集群通过用于为客户端和peer提供服务的同一个gRPC服务器进行通信,你需要首先重新配置orderer通过增加general.cluster.ListenPortgeneral.cluster.ListenAddressServerCertificate和ServerPrivateKey,然后重启orderer使配置生效。

Consensus parameters:

  • WALDir:Write Ahead Logs为etcd/raft的存储路径。每个通道都有自己的子目录以通道ID命名。
  • SnapDir:指定存储etcd/raft的位置。每个通道都有以通道ID命名的子目录。

还有一个隐藏属性用来添加到orderer.yaml的共识部分:

  • EvictionSuspicion:通道逐出怀疑的累积时间段,触发该节点从其他节点拉取块,并查看它是否已被逐出通道以确认其怀疑。如果怀疑被确认(被检查的块不包含节点的TLS证书),则节点将停止对该通道的操作。当一个节点不知道任何被选举的领导者,也不能被选为频道中的领导者时,它就会怀疑自己的频道被逐出。默认为10分钟。

通道配置

除了consenters,Raft通道配置有Option部分,这是与协议相关的设置。当前这个不能再节点运行时动态调节。节点必须重新配置后再重启。

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

注意:建议避免更改以下值,因为一个错误可能导致无法选举leader(例如,TickInterval 和ElectionTick特别低)。无法选举leader的情况是不可解决的,因为leader需要作出改变。因为这些隐患,我们建议最好不要调整这些参数。

  • TickInterval:两个Node.Tick的调用间隔。
  • ElectionTick:每次选举之间必须传递的Node.Tick的调用次数。也就是说,如果一个追随者在选举结束前没有收到现任leader的任何信息,他将成为候选人开始选举。ElectionTick必须要比HeartbeatTick大。
  • HeartbeatTick:两个心跳之间的Node.Tick的调用数量。也就是说,一个leader发送心跳信息维持领导地位。
  • MaxInflightBlocks:限制最大in-flight追加块,在积极复制阶段。
  • SnapshotIntervalSize:定义每个快照的字节数。

重新配置

Raft orderer在运行时支持动态添加和移除节点(同时只能新增或移除一个节点)。注意cluster必须是可操作的,并且在重新配置之前能够达成共识。例如,如果有三个节点,其中有两个节点关掉了,就不能重新配置来移除这些节点。相似的,如果有三个中一个节点关掉了,你不能尝试换证书,这会导致第二次错误。通常,不能对Raft consenters进行任何配置更改,例如添加或删除同意者,或换证书,除非所有consenters在线且健康。

如果你决定改变这些参数,建议仅在维护周期内尝试这样的更改。当集群中只有几个节点在更改配置,且一个节点关闭时,最有可能发生问题。例如,如果你有三个节点且一个关停了,意味着三分之二的节点在线。此时如果拓展节点到4个,那会有四分之二的节点在线,没有满足策略。第四个节点不能加入,因为节点只能加到功能正常的集群上(除非集群的大小是一或二)。

因此,想将三个节点拓展到四个节点(只有两个节点是活动的),你将被卡主,直到down掉的节点恢复。

向Raft添加新节点的方法如下:

1.通过通道配置更新事务将新节点的TLS证书添加到通道。注意:新节点必须增加到系统通道,然后才能添加到应用通道。

2.从系统通道的orderer节点拉取最新的系统配置区块。

3.通过检查获取的配置块是否包含(即将添加)添加节点的证书,确保将要添加的节点是系统通道的一部分。

4.使用配置文件中General.BootstrapFile参数指向的配置区块启动新的Raft节点。

5.等待Raft节点从现有节点复制其证书到所有通道的块。一旦这不完成了,节点开始为通道服务。

6.将新添加的Raft节点的端点到所有通道的配置中。

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

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

删除Raft集群中的节点步骤:

1.从所有通道的通道配置中删除其端点,包括由orderer管理员控制的系统通道。

2.从所有通道的配置中删除其条目(由其证书标识)。同样,这包括系统通道。

3.关闭节点。

从特定通道中删除节点,但保持其为其它通道提供服务的方法是:

1.从这个通道的配置中删除端点。

2.从这个通道的配置中删除其条目(由其证书标识)。

3.第二阶段造成:

  • 通道中剩余的orderer将停止与已移除节点的通信,他们可能还在其它channel上通信。
  • 从通道中移除的节点将自动检测到它被移除,无论是立即还是在EvictionSuspicion 时间过去后(默认为10分钟),并将关闭其Raft实例。

Orderer节点的TLS证书替换

所有TLS证书都有一个有颁发者设定的过期时间。这些有效期从发行之日起10年到几个月不等,从颁发者那里查询。在过期日期之前,你需要在节点本身和节点加入的每个通道(包括系统通道)上替换掉这些证书。

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

1.使用新证书更新通道配置。

2.在节点的文件系统中替换证书。

3.重启节点。

因为节点有单独的TLS证书私钥对,在更新过程中,节点将无法为其新证书尚未添加到的通道提供服务,降低容错能力。因此,替换证书流程一旦启动,需要尽快完成。

如果处于某种原因,TLS证书的替换已经开始,但无法再所有通道中完成,建议将TLS证书替换为原来的状态,然后稍后尝试。

证书过期相关身份验证

当有过期日期的标识(例如给予x509证书的标识)的客户机向orderer发送事务时,orderer检查其标识是否已过期,如果过期,则拒绝事务提交。

然而,可以通过orderer.yaml中General.Authentication.NoExpirationChecks项来配置orderer忽略过期验证。

只有在极端情况下才这样做,即管理员的证书已过期,因此无法发送配置更新来用更新的证书替换管理员证书,因为由现有管理员签名的配置事务现在被拒绝,因为它们已过期。更新通道后,建议更改会默认配置,继续执行过期检查。

Metrics

有关操作服务以及如何设置它的说明,查看our documentation on the Operations Service。

对于操作服务收集的指标列表,查看 reference material on metrics。

虽然有限考虑的指标与特定场景有很大关系,但你可能需要特别监视两个度量。

  • consensus_etcdraft_is_leader:集群中当前哪个节点是主节点。如果没有节点是,那么会失去法定人数。
  • consensus_etcdraft_data_persist_duration:指示对Raft集群的永久性提前写入日志的写入操作需要多长时间。为了协议的安全性,消息必须是持久的,在可以和consenter 共享之前,在适当的地方调用fsync。如果该值开始上升,则该节点可能无法参与协商一致(这可能导致该节点和网络的服务中断)。
  • consensus_etcdraft_cluster_size 和consensus_etcdraft_active_nodes:这些通道指标有助于跟踪“活动”节点(听起来,这些节点是当前对集群有贡献的节点,与集群中的节点总数相比)。如果活动节点的数量低于集群中的大多数节点,则定额将丢失,并且排序服务将停止处理通道上的块。

故障排除

对节点施加的压力越大,可能需要更改的某些参数就越多。与任何系统,计算机或机械一样,压力会导致性能下降。正如我们在概念文档中所指出的,Raft中的leader选举是在跟随节点在一定时间内没有收到heartbeat或append消息时触发的。因为Raft节点跨通道共享同一通信层(这并不意味着他们共享数据——他们不共享),如果Raft节点是许多通道中的consenter 集的一部分,则可能需要延长触发选举所需的时间,以避免无意中的领导人选举。

你可能感兴趣的:(区块链,Hyperledger,Fabric)