Hyperledger Fabric2.3创建通道(无系统通道)文档翻译

翻译: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时,你需要修改ChannelParticipationGeneral.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
}

下面的图表展示了你刚完成的步骤

create-channel.osnadmin1-3

首先使用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。

评论 10
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值
>