关于阿里云centos多机布署Fabric集群环境的疑问

在阿里云买了三台服务器分别是A   B   C,其中A为orderer节点   BC为peer节点 在这三台机器上面单机布署都是成功的...在A节点启动orderer服务没有报错,在BC节点启动peer服务也没有报错 最后进入BC其中一个节点输入:docker exec -it cli bash 再执行
./scripts/script.sh mychannel   
 
 
 
 
  orderer日志显示   2018-04-16 10:01:28.128 UTC [orderer/main] Deliver -> DEBU 959 Starting new Deliver handler 2018-04-16 10:01:28.128 UTC [orderer/common/deliver] Handle -> DEBU 95a Starting new deliver loop 2018-04-16 10:01:28.128 UTC [orderer/common/deliver] Handle -> DEBU 95b Attempting to read seek info message 2018-04-16 10:01:28.135 UTC [orderer/main] Broadcast -> DEBU 95c Starting new Broadcast handler 2018-04-16 10:01:28.135 UTC [orderer/common/broadcast] Handle -> DEBU 95d Starting new broadcast loop 2018-04-16 10:01:28.135 UTC [orderer/common/broadcast] Handle -> DEBU 95e Preprocessing CONFIG_UPDATE 2018-04-16 10:01:28.135 UTC [orderer/configupdate] Process -> DEBU 95f Processing channel reconfiguration request for channel mychannel 2018-04-16 10:01:28.135 UTC [common/configtx] addToMap -> DEBU 960 Adding to config map: [Groups] /Channel 2018-04-16 10:01:28.135 UTC [common/configtx] addToMap -> DEBU 961 Adding to config map: [Groups] /Channel/Application 2018-04-16 10:01:28.135 UTC [common/configtx] addToMap -> DEBU 962 Adding to config map: [Groups] /Channel/Application/Org1MSP 2018-04-16 10:01:28.135 UTC [common/configtx] addToMap -> DEBU 963 Adding to config map: [Groups] /Channel/Application/Org2MSP 2018-04-16 10:01:28.135 UTC [common/configtx] addToMap -> DEBU 964 Adding to config map: [Values] /Channel/Consortium2018-04-16 10:01:28.135 UTC [orderer/common/broadcast] Handle -> WARN 965 Rejecting CONFIG_UPDATE because: Error authorizing update: Error validating ReadSet: Readset expected key [Groups] /Channel/Application at version 0, but got version 1 2018-04-16 10:01:28.135 UTC [orderer/main] func1 -> DEBU 966 Closing Broadcast stream 2018-04-16 10:01:28.137 UTC [orderer/common/deliver] Handle -> WARN 967 Error reading from stream: rpc error: code = Canceled desc = context canceled 2018-04-16 10:01:28.137 UTC [orderer/main] func1 -> DEBU 968 Closing Deliver stream 加黑是报错的信息     在peer节点上面则有以下日志 2018-04-16 09:58:26.478 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP 2018-04-16 09:58:26.478 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity 2018-04-16 09:58:26.481 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized 2018-04-16 09:58:26.481 UTC [msp] GetLocalMSP -> DEBU 004 Returning existing local MSP 2018-04-16 09:58:26.481 UTC [msp] GetDefaultSigningIdentity -> DEBU 005 Obtaining default signing identity 2018-04-16 09:58:26.481 UTC [msp] GetLocalMSP -> DEBU 006 Returning existing local MSP 2018-04-16 09:58:26.481 UTC [msp] GetDefaultSigningIdentity -> DEBU 007 Obtaining default signing identity 2018-04-16 09:58:26.481 UTC [msp/identity] Sign -> DEBU 008 Sign: plaintext: 0A8C060A074F7267314D53501280062D...53616D706C65436F6E736F727469756D 2018-04-16 09:58:26.481 UTC [msp/identity] Sign -> DEBU 009 Sign: digest: 56BEAA35F8668B3A055A9FA59AFAF88F97E60B7FF096FD350FE4D3DD82F7C5C7 2018-04-16 09:58:26.481 UTC [msp] GetLocalMSP -> DEBU 00a Returning existing local MSP 2018-04-16 09:58:26.481 UTC [msp] GetDefaultSigningIdentity -> DEBU 00b Obtaining default signing identity 2018-04-16 09:58:26.481 UTC [msp] GetLocalMSP -> DEBU 00c Returning existing local MSP 2018-04-16 09:58:26.481 UTC [msp] GetDefaultSigningIdentity -> DEBU 00d Obtaining default signing identity 2018-04-16 09:58:26.481 UTC [msp/identity] Sign -> DEBU 00e Sign: plaintext: 0AC3060A1508021A0608C2E7D1D60522...C869CB75F991FF291F6A02DF24B01143 2018-04-16 09:58:26.481 UTC [msp/identity] Sign -> DEBU 00f Sign: digest: 7F75720A3F6A59AF9B09F6C548C765778A7B2B8E30A408D5D23B5B4D850A0852 Error: Got unexpected status: BAD_REQUEST Usage:   peer channel create [flags] Flags:   -c, --channelID string   In case of a newChain command, the channel ID to create.   -f, --file string        Configuration transaction file generated by a tool such as configtxgen for submitting to orderer   -t, --timeout int        Channel creation timeout (default 5) Global Flags:       --cafile string              Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint       --logging-level string       Default logging level and overrides, see core.yaml for full syntax   -o, --orderer string             Ordering service endpoint       --test.coverprofile string   Done (default "coverage.cov")       --tls                        Use TLS when communicating with the orderer endpoint   -v, --version                    Display current version of fabric peer server !!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!! ================== ERROR !!! FAILED to execute End-2-End Scenario ==================    实在找不到是什么问题  

孙善禄

赞同来自: 小象老师 fish

create channel 操作是直接cli 连接orderer 来创建channel,如果失败,做如下检查: 1. 首先确保cli 所在机器能访问orderer:7050服务,可以使用telnet工具来验证,确保,cli能连上orderer的服务 2. 【MSP】确保cli 的script脚本加载的orderer的相关证书文件是与实际orderer服务的msp证书一致的 3. 【TLS】 如果启用了tls,确保cli使用的tls证书,与orderer服务的tls证书load正确,并且握手成功(通过orderer日志检查)

掂吾掂

赞同来自:

另外我确认过...是在orderer节点执行了
./generateArtifacts.sh mychannel
生成的channel-artifacts与crypto-config之后把这两个文件发送到 peer节点... 但是不知道为什么老是报这个错误..

掂吾掂

赞同来自:

有一个非常奇怪的问题...我用windows的telnet连接orderer:7050服务是可以的... 但是当我用peer节点手动去连orderer:7050就会出现图片里面的错误... 奇怪的是我的orderer和peer机器都是配置了ssh证书   我查阅了一下资料...   这个条链接下面的评论有人遇到过同样的问题 http://www.cnblogs.com/aberic/p/8618556.html​   另外我也看到有人说是因为linux内核的问题,我的是阿里云centos 7.4 内核是3.10 http://www.cnblogs.com/aberic/p/8618556.html   按照老师你的讲课的步骤去配置多节点是没有问题的...只是可能由于阿里云服务器的部分问题,我会继续排查一下  

掂吾掂

赞同来自:

弄了一天...原来是阿里云的安全组的问题...之前忘了设置,所以连接的问题解决了...   但是现在重新了一个新问题...当我进入peer节点启动:   ./script/script mychannel  的时候 peer节点给orderer节点tls请求握手的时候or会报错误(172.16.82.191是peer节点,日志是orderer节点打印出来)...    grpc: Server.Serve failed to complete security handshake from "172.16.82.191:45728": tls: first record does not look like a TLS handshake   我并没有更改任何关于tls的配置... 麻烦一下老师能否上传一下上课的时候成功运行的e2e_cli的整个目录...让我看对比一下是否我的参数有误...  

孙善禄

赞同来自:

为什么进入peer节点执行 ./script/script mychannel ?  正常不是进入cli 节点执行么?   e2e_cli的整个目录,只要从v1.0.3拉下来就可以,我没做任何修改。

掂吾掂

赞同来自:

经历千辛万苦...终于成功布署多机环境...
381524130262_.pic_hd_.jpg
但是我有一个疑问想问一下老师.. 上图中: 区块链1服务器 = orderer    区块链2服务器 = peer0.org1 区块链3服务器 = peer0.org2 区块链4服务器 = peer1.org1 区块链5服务器 = peer1.org2   在peer0.org1执行完./script/script mychannel之后 peer0.org1   peer1.org1  peer1.org2  输入docker ps都会有dev-peer1.org2.example.com-mycc-1.0-XX 的镜像
WechatIMG43.jpeg
  但是在peer0.org2 输入docker ps 却没有dev-peer1.org2.example.com-mycc-1.0-XX 的镜像
WechatIMG44.jpeg
  然后我在peer0.org1   peer1.org1  peer1.org2之间执行转账和查账记录,这三台机器都可以查到相应的记录,唯独peer0.org2不能执转账和查账,请问这是什么?     然后我再单独去找了一台测试服务器,执行官方e2e_cli的官方DEMO脚本也就是: ./network_setup.sh up,成功之后再执行docker ps
WechatIMG45.jpeg
  同样的官方的单机环境里面也只有3个dev-peer1.org2.example.com-mycc-1.0-XX这样的镜像..请问这是否属于正常现象嘛?        

孙善禄

赞同来自:

1.dev-peer开头的容器是chaincode所在容器,由peer 生成,当peer执行了instantiate chaincode 之后才会产生,因此请仔细检查是否对peer0.org2执行过instantiate 建议详细阅读执行脚本:e2e_cli/scripts/script.sh 2. 既然已经有多个节点可以正常工作,对比配置和运行情况,对peer的操作情况即可找到差异

要回复问题请先登录注册