翻译:https://hyperledger-fabric.readthedocs.io/en/latest/create_channel/create_channel_participation.html
为了简化通道创建流程并增强隐私性和通道的扩展性,现在可以创建应用通道而不需要先创建“system channel”(由ordering service管理)。使用本文档来学习怎样在不创建系统通道的前提下创建新的通道,使用configtxgen
工具来创建创始区块,并且osnadmin CLI(排序服务节点运行的REST API)来讲排序节点加入到通道。这个过程允许排序节点加入(或离开)任意数量的通道,类似的展示peer节点加入不同的通道。
与过去的流程有何不同:
- 系统通道不再必须。除了创建表示额外步骤的系统通道之外(和新流程相比),系统通道创建了一个额外的管理层,对于某些用例,它没有提供任何其他用处。
- 联盟不再必须:不必再定义一组组织——所谓的“联盟”,联盟可以在排序服务上创建通道。在新的流程里,所有的的通道都是应用通道,因此,可以创建通道的组织列表的概念不再适用。任何一组组织都可以聚集在一起,使用一组已定义的order节点(成为该渠道的排序服务)创建一个通道。
- 简化的order节点创建过程:因为在order节点创建之前系统通道的创始节点不再需要,管理员可以专注于设置其基础结果的过程,并在加入特定的应用通道之前确保其节点正常工作。
新流程的好处:
- 增强了隐私保护:因为所有的order节点用来加入到系统通道,每个网络中的排序节点都知道此节点上所有通道的存在,即使节点本身不是该通道上的审议者,因此没有排序或者存储其块。现在,一个排序节点只知道它加入的通道。
- 扩展性更好:当系统通道中有大量排序节点,启动节点需要花很长时间,因为每个排序节点需要复制系统通道账本。此外,系统通道中节点数量越多会增加节点之间心跳信息。在庞大通道中有大量节点,这可能会导致处理问题,即使没有应用通道的节点上也有大量问题。
- 灵活性更好:过去,order服务的范围是有系统通道定义的,并且在一些应用通道是由系统通道创建,现在排序节点可以按需求加入和离开通道,类似于peer加入到它组织所在的通道一样。
- 操作好处:
- 容易列出orderer节点所在的通道。
- 删除通道和通道关联的区块更容易。
- orderer节点可以在加入通道之前追踪通道,使它们更快速的检测添加。之前,这个流程需要花费几分钟,导致orderer节点管理员重启节点以便于节点加入的更加快速。
- 如果peer组织的MSP,在系统通道中列的,需要修改。peer组织不再需要系统通道管理员来协助修改MSP。
注意:创建通道的新模式不兼容使用系统通道创建通道的模式。如果系统通道存在,channel join操作不支持。类似的,channel join和channel remove不能被Solo或Kafka排序服务所使用。“混合模式”运行,一部分order节点用系统通道创建通道,另外一部分使用新流程,这样是不支持并且强烈的不推荐。你必须转化为新流程或者继续使用系统通道的流程。更多关于删除已有系统通道的作为转换为新流程的信息,查看 Remove the system channel.
创建通道,需要以下步骤和概念。
- 先决条件
- 步骤一:产生通道的创始区块。
- 步骤二:使用osnadmin CLI来增加第一个orderer节点到通道
- 步骤三:增加更多orderer节点
- 下一步
目录结构
本文使用如下的目录结构包含order组织的MSP和证书。这不是强制的,但在使用命令行时会用到。
├── organizations
│ ├── ordererOrganizations
│ │ └── ordererOrg1.example.com
│ │ ├── msp
│ │ │ ├── cacerts
│ │ │ | └── ca-cert.pem
│ │ │ ├── config.yaml
│ │ │ ├── tlscacerts
│ │ │ | └── tls-ca-cert.pem
│ │ └── ordering-service-nodes
│ │ ├── osn1.ordererOrg1.example.com
│ │ │ ├── msp
│ │ │ │ ├── IssuerPublicKey
│ │ │ │ ├── IssuerRevocationPublicKey
│ │ │ │ ├── cacerts
│ │ │ │ │ └── ca-cert.pem
│ │ │ │ ├── config.yaml
│ │ │ │ ├── keystore
│ │ │ │ │ └── key.pem
│ │ │ │ ├── signcerts
│ │ │ │ │ └── cert.pem
│ │ │ │ └── user
│ │ │ └── tls
│ │ │ ├── IssuerPublicKey
│ │ │ ├── IssuerRevocationPublicKey
│ │ │ ├── cacerts
│ │ │ │ └── tls-ca-cert.pem
│ │ │ ├── keystore
│ │ │ │ └── tls-key.pem
│ │ │ ├── signcerts
│ │ │ │ └── cert.pem
│ │ │ └── user
├── admin-client
│ ├── client-tls-cert.pem
│ ├── client-tls-key.pem
│ └── client-tls-ca-cert.pem
有三部分需要注意:
- Orderer organization MSP:organizations/ordererOrganizations/ordererOrg1.example.com/msp包含orderer组织的MSP,其中cacerts和tlscacerts需要你去创建,然后复制根证书ca-cert.pem过来。如果你使用中间CA,你需要包含相符合的intermediatecerts和tlsintermediatecerts文件。
- Orderer local MSP:organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/msp就是所谓的orderer本地msp,包含登陆证书和私钥(osn1节点的)。这个文件自动生成当你登陆orderer身份从Fabirc CA
- TLS certificates: organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/tls目录包含了TLS证书和私钥对(osn1节点),也有TLS CA根证书tls-ca-cert.pem。
- Admin client certificates admin-client/目录包含了TLS 证书admin客户端用来签发osadmin命令。客户端的链接叫做osnadmin CLI并且orderer需要多层TLS,尽管网络本身并不需要。意味着admin client需要登陆和注册TLS CA来产生TLS证书client-tls-cert.pem和私钥client-tls-key.pem这回提供给osnadmin CLI。你需要复制这些证书和客户端TLS CA根证书client-tls-ca-cert.pem到这个文件夹或者指明他们所在的路径。本文为了简便,你可以使用orderer组织相同的TLS CA。在生产环境中,你需要分开TLS CA
本例中使用的证书名称并不和CA产生的名字相同。当你获取了证书之后需要重命名来使它们更容易区分。
重要:你需要创建config.yaml文件并且添加到组织的MSP和本地MSP目录中。这个文件启用了NodeOU,这个特性可以使MSP的管理员身份基于证书中的“admin” OU。详情查看 Fabric CA
如果你选用容器来运行网络(明显是最流行的方案),最好的方式是采用挂载卷的方式来讲证书加入到容器中。这样证书可以被容器使用,而不会受容器运行错误的影响。
前提条件
因为osnadmin命令运行在orderer节点上,通道上至少要存在一个orderer节点。你可以尝试本文的存在orderer节点在order服务中,那个系统通道必须删除从orderer节点中。选择两种方式:
- 使用已有ordering service
- 部署一组新的orderer
使用已有的ordering service
在已有的ordering service上利用新特性之前,你需要在orderer节点上删除系统通道。一个通道上的“混合模式”,一部分orderer节点使用系统通道,另一部分order采用新特性,是不支持的。osadmin CLI包含了包括channel list和channel remove命令方便的删除系统通道。
删除系统通道
- 在下面的步骤之前需要保证ordering节点已经升级到Fabric 2.3以上版本。
- 修改orderer.yaml来支持新特性并重启节点。查看sampleconfig
- General.BootstrapMethod 设置此为none,因为系统通道不再需要了,每一个orderer节点的配置文件都要设置none,意味着不需要启动区块来启动orderer
- Admin.ListenAddress: orderer server的管理地址(主机和端口)这个可以用来使用osnadmin命令来配置通道。这个值需要是唯一的不能冲突。
- Admin.TLS.Enabled: 理论上这个可以设置为false,但是这不推荐。一般情况下,需要设置为true。
- Admin.TLS.PrivateKey:TLS CA签发的私钥路径
- Admin.TLS.Certificate: TLS CA签发的orderer证书
- Admin.TLS.ClientAuthRequired:这个值必须设置为true。注意虽然在orderer Admin端口上各操作需要使用TLS,但整个网络并不需要。
- Admin.TLS.ClientRootCAs: 管理员客户端的TLS CA根证书。在上面的结构中,是admin-client/client-tls-ca-cert.pem
- ChannelParticipation.Enabled:设置此值为true来启动orderer的这个特性。
- 重启每一个orderer节点。
- 放system channel into maintenance mode,Kafka和Raft同步相同。这个动作会停止通道创建新的交易。
- 从orderer节点上删除系统通道,一个接一个。在orderer节点删除系统通道的过程中,orderer会停止服务。因此,小心并确定剩余的orderer仍然可以工作并且彼此可以达成一致。这个操作可以是交错的,根据各通道的容错设置,没有让通道关闭。如果一个应用通道能容错一个server下线,你仍然可以提交交易到通道中,凭借其它orderer并没有同时处于删除流程中。使用osnadmin channel list命令展示orderer所参与的通道
export OSN_TLS_CA_ROOT_CERT=../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/tls/cacerts/tls-ca-cert.pem export ADMIN_TLS_SIGN_CERT=../config/admin-client/client-tls-cert.pem export ADMIN_TLS_PRIVATE_KEY=../config/admin-client/client-tls-key.pem osnadmin channel list -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY
-
ORDERER_ADMIN_LISTENADDRESS
与orderer.yaml中Orderer.Admin.ListenAddress一致 -
OSN_TLS_CA_ROOT_CERT
orderer组织的TLS根证书或中间证书。 -
ADMIN_TLS_SIGN_CERT
admin client的TLS CA证书 -
ADMIN_TLS_PRIVATE_KEY
TLS CA的私钥路径
-
注意:因为osnadmin CLI和orderer链接相互需要TLS,你需要传递--client-cert和--client-key参数在每一个osadmin命令。分别指向admin客户端证书和admin私钥,都是有admin客户端TLS CA签发。
例如:
osnadmin channel list -o HOST1:7081 --ca-file $TLS_CA_ROOT_CERT --client-cert $OSN_TLS_SIGN_CERT --client-key $OSN_TLS_PRIVATE_KEY
输出如下:
{
"systemChannel": {
"name": "syschannel",
"url": "/participation/v1/channels/systemchannel"
},
"channels":[
{
"name": "channel1",
"url": "/participation/v1/channels/channel1"
}
]
}
现在你可以运行osnadmin channel remove 来删除通道:
osnadmin channel remove -o [ORDERER_ADMIN_LISTENADDRESS] --channelID syschannel --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY
例如:
osnadmin channel remove -o HOST1:7081 --channelID syschannel --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY
成功的结果是:
Status: 204
并且运行了osnadmin channel list命令,你可以验证系统通道是否已经被删除
osnadmin channel list -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY
检验已经被删除:
{
"systemChannel": null,
"channels":[
{
"name": "channel1",
"url": "/participation/v1/channels/channel1"
}
]
}
重复以上命令为每一个ordering节点。
部署一组新的orderers
使用如下步骤来部署新的orderers来使用此特征。分为两步
- 创建orderer组织的MSP并生成orderer节点的证书
- 为每一个orderer节点配置orderer.yaml
创建orderer组织的MSP并生成orderer节点的证书
在部署orderer之前,你需要定义orderer的组织MSP和TLS为每一个Raft orderer节点。学习怎样创建身份,查看Registering and enrolling identities with a CA。在完成进程之后,你需要登陆获取TLS证书和orderer MSP.为了跟随本文档你可以使用上面的目录结构。
因为本文展示了使用一个组织的三个orderer来创建通道,你需要为每一个节点生成TLS证书。为什么三个orderers,这样就满足Raft的大多数策略。也就是说,当三个orderer节点,有一个停止运行,还有大多数在运行。更多关于节点数量的信息,查看The Ordering Service。为了简便和学习的目的,你也可以部署一个orderer节点,即使这个orderer服务不会高可用并且不能用于生产环境。
配置orderer.yaml为每个orderer
遵循ordering service deployment guide部署三个orderer节点。注意当你配置orderer.yaml时,你需要修改ChannelParticipation和
General.BoostrapMethod。
- General.BootstrapMethod 设置为none,因为系统通道不再需要。
- Admin.ListenAddress orderer admin server的地址,osnadmin命令配置通道。这个值必须是唯一的不能冲突。
- Admin.TLS.Enabled: 理论上这个可以设置为false,但这个并不推荐,普遍来说,你需要设置为true。
- Admin.TLS.PrivateKey: TLS CA签发的私钥路径
- Admin.TLS.Certificate: TLS CA签发的证书。
- Admin.TLS.ClientAuthRequired: 这个值必须设置为true。注意在orderer 管理地址上需要TLS,但整个网络并不需要。
- Admin.TLS.ClientRootCAs:admin客户端TLS CA的根证书。在上面的文件夹中,这是admin-client/client-tls-ca-cert.pem
- ChannelParticipation.Enabled: 设置为true来启用新特性。
启动每个orderer
1.如果还没有设置Fabric的二进制执行文件
export PATH=<path to download location>/bin:$PATH
2.如果终端设置了变量FABRIC_CFG_PATH
到orderer.yaml,是Fabric可执行文件的相对路径。如果你的执行文件在/bin中,且orderer.yaml在/config,那么路径是
export FABRIC_CFG_PATH=../config
3.你可以开启orderer通过如下命令:
orderer start
当orderer启动成功后,你会看到类似于下面的输出:
INFO 01d Registrar initializing without a system channel, number of application channels: 0, with 0 consensus.Chain(s) and 0 follower.Chain(s)
INFO 01f Starting orderer:
这个动作启动了orderer节点且没有加入任何通道,为每个orderer节点重复这个过程。此时此刻,三个节点并没有彼此通信,直到随后我们创建一个通道。
定义peer组织
因为我们创建的的通道在网络中有两个以上peer组织在通信,你至少需要一个peer组织作为通道的管理员,这样可以添加其它组织。理论上,peer节点本身还没有部署,你需要创建一个或多个peer组织MSP且至少一个组织需要在configtx.yaml中。在进入下一步之前,查看Fabric CA建立peer组织的MSP。如果peer已经部署了,你 需要包含它们的地址到锚节点。
第一步,生成通道的创始区块
创建新通道的起始是生成创始区块,在随后的channel join中要提交到orderer。只需要一个成员来创建创始区块,可以将它分享到其它通道成员中,确保有相同的通道配置,接着排序服务中的orderer都会用。
安装configtxgen工具
可以手动创建通道交易文件,这也可以使用configtxgen工具来创建通道,这很容易使用configtxgen工具读取configtx.yaml文件(包含通道配置)创建区块。
configtxgen工具是Fabric可执行文件,放在bin文件夹中。
在使用configtxgen之前,确认你已经设置了FABRIC_CFG_PATH环境变量指向到包含configtx.yaml的目录,例如
export FABRIC_CFG_PATH=../config
可以使用帮助来查看用法
configtxgen --help
configtx.yaml文件
configtx.yaml文件是configtxgen工具可读可编辑的文件,包含了新通道的配置。configtxgen工具使用此文件中的配置来设置通道并转化为Fabric识别的protobuf format 。示例configtx.yaml文件在config文件夹中与可执行文件所在的目录相邻。文件中以下配置项需要在新通道中设置:
- Organizations:通道成员的组织。每个组织有加密素材组建通道的msp.准确的说每个通道配置定义在下面的Profiles部分。
- Orderer:一个orderer节点的列表,组织了通道的参与者
- Profiles:每个通道配置信息来创建通道配置。每个通道创建必须参照profiel,包含了peer组织和通道成员。Profiles区域可以设置多个profile设置。然而,每一个必须有独有的名字(这会成为通道的名称,会在创建通道时以flag的形式来指定)
到Using configtx.yaml
to build a channel configuration文档中查看更多信息,然而,下面的三个部分需要在没有系统通道的情况下指定配置来创建通道。
注意:在通道初始化时并不需要Peer组织,但你知道推荐将它们加入到Profiles的Organizations和Applications区域,避免后面升级通道。
Organizations:
提供orderer组织MSP和任何peer组织MSP。也提供orderer节点的endpoint
- Organizations.OrdererEndpoints:
例如
OrdererEndpoints:
- "Host1:7080"
- "Host2:7080"
- "Host3:7080"
Orderer:
- Orderer.OrdererType 设置为etcdraft。之前提过,此流程不支持Solo和Kafka的orderer节点。
- Orderer.EtcdRaft.Consenters 设置orderer节点地址的列表,在host:port组成中,这被认为是激活了共识者集合。所有加入此区域的orderer节点在通道加入后都会成为共识者。
例如:
EtcdRaft:
Consenters:
- Host: Host1
Port: 7090
ClientTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/tls/signcerts/cert.pem
ServerTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/tls/signcerts/cert.pem
- Host: Host2
Port: 7091
ClientTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn2.ordererOrg1.example.com/tls/signcerts/cert.pem
ServerTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn2.ordererOrg1.example.com/tls/signcerts/cert.pem
- Host: Host3
Port: 7092
ClientTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn3.ordererOrg1.example.com/tls/signcerts/cert.pem
ServerTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn3.ordererOrg1.example.com/tls/signcerts/cert.pem
为了简明,每个orderer节点使用了相同的TLS证书,包括server和client,尽管这个没有必要。
当通道配置区块被创建了,configtxgen读取TLS的证书路径并替换并替换为证书中的数据。
Profiles
如果你对过去的创建通道流程熟悉,你可以回顾一下Profiles区域:此区域包含了联盟部分在“Orderer:”下。这个联盟定义了,之前的版本包含指定哪些peer组织可以创建通道,现在不需要了。如果此区域存在于profile部分,那就不能使用这个新特征来创建通道。更准确的说在“Orderer:"区域只是包含orderer组织的MSP ID或者多排序服务的组织和peer组织在Application区域(通道成员)。至少要有一个orderer组织和peer组织。
下面的一段是通道profile的实例,包含了orderer配置,orderer,组织和策略配置。Application区域,peer组织列表。包含了默认Application设置,至少包含一个peer组织(SampleOrg,本例中)和通道一致的协议。
Profiles:
SampleAppChannelEtcdRaft:
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
OrdererType: etcdraft
Organizations:
- <<: *SampleOrg
Policies:
<<: *SampleOrgPolicies
Admins:
Type: Signature
Rule: "OR('SampleOrg.member')"
Application:
<<: *ApplicationDefaults
Organizations:
- <<: *SampleOrg
Policies:
<<: *SampleOrgPolicies
Admins:
Type: Signature
Rule: "OR('SampleOrg.member')"
注意:为了简单,这段假设peers和orderers属于相同的SampleOrg组织。这里查看 sample config。对于生产环境的部署,推荐peer和orderer节点属于不同的组织,所以本例中使用ordererOrg1.example.com为orderer组织。如果你使用相同的组织,通过configtx.yaml你需要修改指向SampleOrg
到ordererOrg1.example.com。这需要包含新的order组织ordererOrg1.example.com到”Organizations:“
Profiles
区域可以按需设置不限个数。但是必须有不同的名字(这会成为通道的名字,当通道创建时使用flag传入)。下一步,需要生成通道的创始区块。
生成创始区块
在你编辑完成configtx.yaml之后,你可以使用它来创建新的通道。每个通道配置以创始区块启动。因为我们之前为configtxgen
设置了环境变量,你可以运行下面的命令来为通道channel1创建创始区块,使用SampleAppChannelEtcdRaft
部分的profile:
configtxgen -profile SampleAppGenesisEtcdRaft -outputBlock genesis_block.pb -channelID channel1
- -profile是configtx.yaml 的profile的名字用来创建通道。
- -outputBlock生成创始区块的保存路径
- -channelID通道的名称,名字必须全小写,少于250个字符并且匹配表达式[a-z][a-z0-9.-]*。这个命令使用-profile标识来指定“SampleAppGenesisEtcdRaft:”
当命令执行成功,你会看到configtxgen创建通道的事务:
INFO 001 Loading configuration
INFO 002 orderer type: etcdraft
INFO 003 Loaded configuration: /fabric/config/configtx.yaml
INFO 004 Generating genesis block
INFO 005 Writing genesis block
第二步:使用osnadmin CLI增加第一个orderer到通道
现在创始区块已经创建了,第一个orderer节点接收”osnadmin channel join“命令激活 “activates” 通道。尽管通道并不是完全可操作的,直到法定达到法定人数(如果你的profile列出了三个共识者,则需要两个以上,使用osnadmin channel join命令加入到通道中)。
注意:如果你试着运行osnadmin命令(除了channel list命令)在系统通道的orderer节点上,你会收到错误提示系统通道已经存在。系统通道需要在使用osnadmin之前被删除。
每个orderer节点需要运行如下命令
export OSN_TLS_CA_ROOT_CERT=../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/tls/cacerts/tls-ca-cert.pem
export ADMIN_TLS_SIGN_CERT=../config/admin-client/client-tls-cert.pem
export ADMIN_TLS_PRIVATE_KEY=../config/admin-client/client-tls-key.pem
osnadmin channel join --channel-id [CHANNEL_NAME] --config-block [CHANNEL_CONFIG_BLOCK] -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY
替代如下:
CHANNEL_NAME
通道名称CHANNEL_CONFIG_BLOCK
第一步中创建的创始区块的目录和名称,随后的orderer节点会加入配置使用此创始区块,或者使用最新的配置区块替代。ORDERER_ADMIN_LISTENADDRESS
与Orderer.Admin.ListenAddress
(定义在orderer.yaml)相符的地址OSN_TLS_CA_ROOT_CERT
orderer组织的TLS CA证书或中间证书。ADMIN_TLS_SIGN_CERT
admin client的TLS证书ADMIN_TLS_PRIVATE_KEY
admin client的私钥
例如:
osnadmin channel join --channel-id channel1 --config-block genesis_block.pb -o OSN1.example.com:7050 --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY
注意:因为osnadmin CLI和orderer通信需要TLS,需要传递--client-cert和--client-key参数在每一个osadmin命令。--client-cert参数指向admin client证书,--client-key指向admin client私钥,都是有admin client TLS CA签发。
输出如下:
{
"name": "channel1",
"url": "participation/v1/channels/channel1",
"consensusRelation": "consenter",
"status": "active",
"height": 1
}
当成功了,orderer加入通道账本高1.因为此orderer是使用创始区块加入的,status是”active“。因为orderer是通道共识集体的一员,它的consensusRelation
是“consenter”。下一部分中会详细介绍consensusRelation
。
在另外的两个orderer中重复以上命令。记得修改orderer地址, -o [ORDERER_ADMIN_LISTENADDRESS],在命令中改为相符的orderer。
因为两个orderer使用创始区块加入通道斌并且都是共识集体的一员,他们的交易状态会从“onboarding”改为“active”,且“consensusRelation” 是“consenter”。此时,通道已经可操作了,因为active的共识成员达到了大多数。会看到如下输出:
INFO 087 raft.node: 1 elected leader 1 at term 2 channel=channel1 node=1
INFO 088 Raft leader changed: 0 -> 1 channel=channel1 node=1
INFO 089 Start accepting requests as Raft leader at block [0] channel=channel1 node=1
在第一个orderer加入到通道后,其它节点可以从创始区块加入也可以从最新的区块加入。当orderer从配置区块加入时,它的状态在账本更新配置区块(命令中指定)时是onboarding,之后它的状态更改为active。
使用osadmin channel list命令时加上--channel-id标签用来查看节点的status和consensusRelation(共识关系)
osnadmin channel list --channel-id [CHANNEL_NAME] -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY
例如:
osnadmin channel list --channel-id channel1 -o HOST2:7081 --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY
CHANNEL_NAME
通道名称- ORDERER_ADMIN_LISTENADDRESS 在orderer.yaml中的Orderer.Admin.ListenAddress
OSN_TLS_CA_ROOT_CERT
orderer组织的的TLS CA根证书或者中间证书。ADMIN_TLS_SIGN_CERT
admin client的TLS CA证书ADMIN_TLS_PRIVATE_KEY
TLS CA的私钥
输出如下:
{
"name": "channel1",
"url": "participation/v1/channels/channel1",
"consensusRelation": "consenter",
"status": "active",
"height": 1
}
下面的图表展示了你刚完成的步骤
首先使用configtxgen命令创建通道创始区块,然后将此文件提供给各个orderer节点。
假设你已经在三个节上成功的运行了osnadmin channel join命令,现在你已经有一个激活的channel且ordering service已经准备好Wie交易排序。Peer已经可以加入通道且client可以开始交易。
如果你想增加orderer节点到通道,可以追踪以下文档。
第三步,新增orderer到通道
为通道的共识集体新增orderer节点可能随时发生。其它组织可能想贡献它们的orderer到集群中,或者它会在生产环境下允许多个orderer停机维护的情况下展示优越性。
任何时候新的orderer加入集群,都要保证没有在共识机制中失去法定的多数席位。增加一个节点到已有的三个orderer节点中,会改变共识的大多数数量。因此在执行进程直到新orderer开始执行共识,集群处于容错能力减低的状态。对于这种状况或者避免停机,需要使用命令查清orderer节点的consensusRelation
,状态可能是consenter或follower。当orderer加入后身份是follower,账本会从其它orderer上复制过来,但它没有参与共识,通道操作并没有中断。
因为复制长区块链可能会花很长时间,作为follower加入区块很高的通道时是非常有用的,因为这允许你确认orderer可以复制区块在拥有法定人数之前。以follower身份加入通道,请勿将节点包括在通道配置许可程序中。
文档为了清晰,我们假设新增orderer是和之前的orderer是一个组织。如果新增orderer的组织并没有在通道配置中,则orderer的组织必须先添加到通道中,在新orderer可以获取区块之前。orderer可以从其它集群成员拉取区块,如果orderer的组织在通道配置中,并且满足/Channel/Readers策略。
从这个文档中,新的orderer不是集群的一部分。运行如下命令将新的orderer加入到通道:
osnadmin channel join --channel-id [CHANNEL_NAME] --config-block [CHANNEL_CONFIG_BLOCK] -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY
orderer可以通过创始区块加入通道,或者最后的配置区块。但是consensusRelation
会一直是“follower”,直到orderer被加入到共识集体中,通道提交通道配置。
如果是加入创始区块,输出类似于:
{
"name": "channel1",
"url": "participation/v1/channels/channel1",
"status": "active",
"consensusRelation": "follower",
"height": 1
}
或者,加入的是最新的配置区块,status是onboarding ,直到通道账本更新到了指定的配置区块。你可以使用osnadmin channel list命令来确认status为active和账本高度更新完成。例如,如账本的总高度在指定的区块上是1151,在账本更新完毕后,输出会类似于:
{
"name": "channel1",
"url": "participation/v1/channels/channel1",
"status": "active",
"consensusRelation": "follower",
"height": 1151
}
然而,有一点很重要,交易的状态从onboarding 到active 不是唯一的标准来决定是否是时候将新的orderer加入到共识集中。更重要的是比对新orderer达到的高度并比较共识的高度。例如,指定的配置区块在高度1151,但下面会有大量的正常区块。在OSN4
成为active(赶上指定配置),最好比较OSN1和OSN4,当它们互相接近的时候,可以添加OSN4到通道结合中。
下图展示了ordering 节点已经作为follower加入:
OSN4作为follower加入了。状态是onboarding,直到账本追平配置区块在加入通道的osnadmin命令。
尽管orderer状态从onboarding 转化为active,但仍然不能参与到排序服务,因为consensusRelation
状态是follower,但仍然会继续拉取区块并且会随时更新。在状态变成active,就可以将orderer从follower转换成共识成员,并且任何orderer组织的admin都可以将orderer添加到共识集合中,通过channel configuration update transaction,或者使用 fabric-config可执行文件。
注意:你不能尝试对Raft共识进行更改,例如提那家一个共识者,除非所有的共识者都在线并且正常运行,因为你可能失去法定人数,从而不能处理交易事务。
确保orderer组织具有写权限在通道配置中,这样orderer可以成为一个共识者。当通道升级完成,你可以使用osnadmin channel list命令来确认,consensusRelation
状态自动更改为共识者。
{
"name": "channel1",
"url": "participation/v1/channels/channel1",
"status": "active",
"consensusRelation": "consenter",
"height": 1152
}
注意如果配置区块高度是1151,并且后面有1000个区块,那么OSN4加入共识的区块会是2152.
下一步
将peers加入通道
在通道创建之后,你可以按正常流程来讲peer加入到通道中,并配置锚节点。如果peer组织并没有包含在通道配置中,你需要提交channel configuration update transaction来增加组织。如果这个没有包含peer组织,所有通道中的peer组织可以从orderer服务中获取通道创始区块,使用peer channel fetch命令。组织可以使用创始区块来加入通道使用 peer channel join命令。一旦peer加入到通道中,peer就开始从排序服务中接受区块账本。
从通道中增加或删除orderer
你可以继续使用osnadmin channel join和osnadmin channel remove名来来增加或删除orderer。在从通道中删除orderer之前需要注意,建议首先通过通道升级请求,在共识集合中删除orderer。