如何向正在运行的Hyperledger Fabric网络添加更多的排序节点

13

我已经搭建了一个只有1个排序节点的Hyperledger Fabric网络,但是不知道如何将更多的排序节点添加到正在运行的生产Hyperledger网络中。

非常感谢您的任何帮助。

2个回答

21
首先,您的网络订购服务必须设置为Kafka类型,而不是单独的类型。您可以在configtx.yaml文件中进行此操作,在OrdererType下进行设置。然后,您还需要创建kafka代理、zookeeper并进行配置。如果您对此不熟悉,我发现通过尝试和学习该repo https://github.com/keenkit/fabric-sample-with-kafka 可以提供很大帮助。
假设您已经拥有一个具有Kafka订购服务的工作网络,添加额外的订购者是通过通道更新完成的,这与添加新组织非常相似。涉及到一些步骤,但所有步骤都在此处http://hyperledger-fabric.readthedocs.io/en/release-1.1/channel_update_tutorial.html列出并解释了。我建议您先了解如何添加组织,但如果您感觉自己很舒适,那么添加订购者的唯一区别是:
  • 显然不需要创建新的组织加密材料,但是您需要为另一个排序节点准备加密材料。
  • 不要运行命令 jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Org3MSP":.[1]}}}}}' config.json ./channel-artifacts/org3.json > modified_config.json 来将新的组织加密材料添加到网络中,而是打开json文件并查找“OrdererAddresses”。那里应该有一个排序节点的数组,在另一个标签“addresses”下。在这里添加您的排序节点,然后将文件保存为modified_config.json。然后您可以继续运行相同的命令。
  • 当您使用peer channel signconfigtx -f org3_update_in_envelope.pb进行信封签名时,请使用一个活动的排序节点引导您的CLI,并使用OrdererMSP,否则排序节点将拒绝您的交易。用于添加新组织的组织MSP将无法工作。

为了帮助排除故障,我发现最好先启动上述github存储库创建的2个排序节点设置,然后测试删除1个排序节点,接着再添加回来。之后再进一步尝试添加第三个。

顺便提一下,您可以在这里找到所有其他可以通过通道更新更改的内容:http://hyperledger-fabric.readthedocs.io/en/release-1.1/config_update.html。单击“点击此处查看配置”以查看json配置的示例(注意:该示例是一个solo而不是Kafka)。

按照要求逐步执行:

  1. 在OrdererOrgs的crypto-config规范下:为您的orderer创建一个新的主机名(使用与其他相同的域名和名称)。
  2. 运行命令cryptogen extend --config=./crypto-config.yaml 注意:'extend'部分,以便生成您需要的内容而不是重新生成所有内容。
  3. 启动一个新的orderer容器,该容器与另一个orderer基本相同,只是加密卷指向步骤2中生成的新加密内容(根据您的设置可能具有不同的端口)。此时您可能会注意到它已连接到kafka代理并具有您的通道和块,因为它使用相同的创世块。然而,需要完成的是让网络知道这个新orderer的地址。
  4. docker exec -it cli bash进入CLI容器,并使用活动orderer信息引导它,因为您需要OrdererMSP签署此更改。

引导示例(您的可能不同):CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/Admin@example.com/msp

CORE_PEER_ADDRESS=orderer0.example.com:7050

CORE_PEER_LOCALMSPID=OrdererMSP

CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer0.example.com/tls/ca.crt

ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer0.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

CHANNEL_NAME=mychannel

  1. 在CLI容器中安装jq以将块转换为JSON格式并返回 apt update && apt install -y jq
  2. 获取最新的配置块 peer channel fetch config config_block.pb -o orderer0.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA
  3. 将其转换为JSON格式并裁剪标题 configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json
  4. 打开JSON文件,查找“OrdererAddresses”,在该标题下应该有另一个标记“addresses”。在该数组中添加新的IP和端口以用于新的排序者。将更改保存为modified_config.json
  5. 将步骤7中的JSON格式转换为块 configtxlator proto_encode --input config.json --type common.Config --output config.pb
  6. 将步骤8中的JSON格式转换为块 configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb
  7. 计算步骤9和10之间的差异 configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output org3_update.pb
  8. 将delta转换回JSON格式 configtxlator proto_decode --input org3_update.pb --type common.ConfigUpdate | jq . > org3_update.json
  9. 在标题中包装JSON格式 echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat org3_update.json)'}}}' | jq . > org3_update_in_envelope.json
  10. 将其转换回块 configtxlator proto_encode --input org3_update_in_envelope.json --type common.Envelope --output org3_update_in_envelope.pb
  11. 由于您是作为活动排序者引导的,因此只需提交即可,因为提交方会提供免费签名,并且这是您唯一需要的签名 peer channel update -f org3_update_in_envelope.pb -c $CHANNEL_NAME -o orderer0.example.com:7050 --tls --cafile $ORDERER_CA

一旦你的同行收到这个新区块,他们现在知道了新排序者的地址并可以联系它。


如果您能够提供逐步过程,那就太好了,非常有帮助,谢谢。 - Rohit Khatri
我已经添加了。由于步骤很多,所以我决定只链接http://hyperledger-fabric.readthedocs.io/en/release-1.1/channel_update_tutorial.html#prepare-the-cli-environment并指出主要的区别,因为这个过程非常相似,对其中一个的理解基本上就等于对另一个的理解。 - Antonio Glavocevic
非常感谢您的帮助,它起作用了,还有一种方法可以验证调用是否到达第二级订购者吗? - Rohit Khatri
@ShalabhNegi,增加kafka和zookeeper节点的数量不是必须的,但随着订单数量的增加,它将提高吞吐量。每个订购者都可以与不同的kafka节点通信,因此,如果您认为需要额外的kafka节点来处理流量,则由您决定。我认为锚节点对kafka集群没有任何影响,它们只是为了向网络全局宣布自己的存在。至于zookeeper,我听说3是防止脑裂(split brain)的好数量,实际上你永远不需要超过5个。 - Antonio Glavocevic
@AntonioGlavocevic 感谢您提供这么棒和干净的答案,我因为这个问题卡了很长时间。虽然我使用的是 Raft,但步骤相似,需要做一些更改。 - Adarsha Jha
显示剩余5条评论

0
继承Antonio的回答,您需要将系统通道的创世块卷入新的orderer中。
您可以通过从现有的orderer获取它并选择通道名称为testchainid(默认名称)来获得它。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接