• Fabric网络升级(三)


    原文来自这里

    如果不熟悉capability,那么操作前可以查阅Capabilities。需要注意的是在启用capabilities前,需要升级归属该通道的peer节点和排序节点

    更多关于最新版Fabric中capabilities版本的信息,详见Upgrading your components

    注意:在Hyperledger Fabric中使用术语升级时,指的是升级组件的版本(例如,将可执行文件升级到最新版)。使用更新时,指的是配置的更新,例如更新通道的配置或部署脚本。在Fabric中,如果没有数据迁移的话,我们不会使用术语迁移

    先决条件和注意事项

    更新前,请先确保你的机器上有Prerequisites中所提及的所有依赖。这将保证你拥有更新通道配置所需的最新版工具。

    由于Fabric可以并且应该滚动更新,所以启用capabilities前需要完成Fabric的升级。任何没有升级到至少capabilities相关的可执行程序都将引起崩溃,并指出错误的配置,否则会导致账本分叉。

    一旦启用capabilities,它成为该通道的永久记录。这意味着即使之后禁用了capabilities,旧的可执行程序也无法参与到该通道中,因为它无法处理启用capabilities到禁用capabilities期间的所有区块。结果就是一旦启用了capabilities,就不建议或不支持禁用它。

    有鉴于此,可将启用capabilities视为不可逆的。所以在测试设置新capabilities,并在生成环境下启用之前,请三思。

    概览

    在接下来的教程中,我们将展示如何在所有的系统通道和应用程序通道中配置capabilities更新。

    是否需要为所有的通道更新配置的每个部分,这取决于最新版的内容以及你的使用场景。详情参见Upgrading to the latest version of Fabric。需要注意的是在使用最新版功能前,可能需要更新到最新的capability版本,最好的做法是始终使用最新版的可执行程序和最新的capability版本。

    因为更新capability版本涉及到配置更新事务流程,相关命令详见Updating a 通道 configuration

    与通道其它配置更新一样,capability版本更新也分三步(每个通道):

    1. 获取最新的通道配置
    2. 创建修改后的通道配置
    3. 创建配置更新事务

    我们将按照下面的顺序来启用capabilities:

    1. Orderer system 通道
      1. Orderer group
      2. 通道 group
    2. Application 通道
      1. Orderer group
      2. 通道 group
      3. Application group

    尽管可以同时编辑通道配置的多个部分,但在本教程中我们将展示如何逐步处理这些过程。也就是说我们不会在一次配置修改中同时修改系统通道的Orderer组和通道组。这是因为并不是每次发布都有新的Orderer组capability和通道组capability。

    在生成网络中,单个用户可以独立完成所有通道(和其它配置)更新时不可能的,也是不明智的。例如,orderer system 通道更新,只能由组织的管理员来执行(尽管可以将peer组织添加到排序服务组织中)。同样地,更新其它的Orderer通道组的通道配置除了需要排序服务组织的签名外还需要peer组织的签名。分布式系统需要协同管理。

    新建capabilities配置文件

    本教程假设名为capabilities.json的文件已创建,它包含所有你想更新的capabilities。使用jq将编辑的配置应用到修改后的文件中。

    你也不是非要创建类似capabilities.json的文件或使用jq工具。修改后的配置也可手动编辑,详见sample 通道 configuration

    然而,这里所描述的过程(使用JSON文件和jq工具)在脚本化方面确实有优势,这使得它适合想大量的通道进行配置更新。这也是这种方式为什么会成为更新通道的推荐方式

    示例中,capabilities.json文件内容如下(如果将更新通道作为你Fabric升级到最新版的一部分,则需要将capabilities设置为适合该版本的版本):

    {
         "通道": {
             "mod_policy": "Admins",
                 "value": {
                     "capabilities": {
                         "V2_0": {}
                     }
                 },
             "version": "0"
         },
         "orderer": {
             "mod_policy": "Admins",
                 "value": {
                     "capabilities": {
                         "V2_0": {}
                     }
                 },
             "version": "0"
         },
         "application": {
             "mod_policy": "Admins",
                 "value": {
                     "capabilities": {
                         "V2_0": {}
                     }
                 },
             "version": "0"
         }
       }
    

    默认情况下,peer节点并不是orderer system 通道的管理员,所以peer节点不能发起orderer system 通道配置更新。排序组织的管理员必须创建类似的文件(没application组capability,因为系统通道中不存在application组)来执行系统通道配置更新操作。默认情况下应用程序通道配置是复制系统通道的,所以除非为了特定的capability版本而创建了不同的通道配置,否则应用程序通道的Orderer组和通道组与网络中其它的系统通道是一样的。

    orderer system 通道 capabilities

    默认情况下应用程序通道复制系统通道的配置,所以最好的操作是在跟应用程序通道前先更新系统通道的capabilities。就像Upgrading your components中所述,更新peer之前先将排序节点更新至最新版。

    orderer system 通道归排序服务组织管理。默认情况下,只有一个组织(在排序服务初始化节点时创建的组织),但也可以扩展多个组织(例如,有多个组织为排序服务提供节点)。

    在更新Orderer通道 capability之前,请确保在你的排序服务中的所有节点都已经升级到所需版本。如果排序节点没有升级到所需版本,它将无法处理具有该capability的配置块,并且将崩溃。类似的,如果排序服务中新增一条通道,那所有将被加入到该通道的peer节点必须至少处于通道Application capabilities相近的节点版本,否则在处理配置块时这些peer节点将会崩溃。要了解更多信息,详见Capabilities

    设置环境变量

    你需要导入以下环境变量:

    • CH_NAME:待更新的系统通道名称。
    • CORE_PEER_LOCALMSPID:执行通道更新操作的MSP ID,排序服务组织中的MSP。
    • TLS_ROOT_CA:排序节点TLS证书的绝对路径。
    • CORE_PEER_MSPCONFIGPATH:标识你的组织的MSP存放的绝对路径。
    • ORDERER_CONTAINER:排序节点的容器名称。访问排序服务时,你可以访问排序服务中的任意节点。你的请求会自动提交给leader节点。

    Orderer

    关于如何拉取、传递和确定通道配置范围的命令,详见Step 1: Pull and translate the config。如果你有了modified_config.json文件,那你可以使用下面的命令来新增Orderer组capabilities:

    jq -s '.[0] * {"通道_group":{"groups":{"Orderer": {"values": {"Capabilities": .[1].orderer}}}}}' config.json ./capabilities.json > modified_config.json
    

    然后执行步骤Step 3: Re-encode and submit the config

    因为你现在更新的是系统通道,系统通道修改策略只需要排序服务组织的管理员签名。

    通道

    关于如何拉取、传递和确定通道配置范围的命令,详见Step 1: Pull and translate the config。如果你有了modified_config.json文件,那你可以使用下面的命令来新增通道组capabilities:

    jq -s '.[0] * {"通道_group":{"values": {"Capabilities": .[1].通道}}}' config.json ./capabilities.json > modified_config.json
    

    然后执行步骤Step 3: Re-encode and submit the config

    因为你现在更新的是系统通道,系统通道的修改策略只需要排序服务组织的管理员签名。在应用程序通道中,假如你没有修改默认值,通常需要同时满足Application组(由peer组织的MSPs组成)和Orderer组(由排序服务组织组成)的大多数管理员策略。

    在已有通道上启用capabilities

    现在我们来更新orderer system 通道的capabilities,我们将会更新已有通道(你想更新的)的配置。

    应用程序通道的配置与系统通道的非常相似。这样,我们就能复用capabilities.json文件,并使用相同的命令来进行更新(只需要重新设置环境变量即可)。

    在更新capabilities前,请确保排序服务中的所有排序节点和通道中的所有peer节点都已升级至要求的版本,否则未升级的节点将无法处理启用了capability的配置块并引起崩溃。更多信息详见Capabilities

    设置环境变量

    • CH_NAME:待更新的应用程序通道名称。
    • CORE_PEER_LOCALMSPID:执行通道更新操作的MSP ID,peer组织中的MSP。
    • TLS_ROOT_CA:peer组织TLS证书的绝对路径。
    • CORE_PEER_MSPCONFIGPATH:标识你的组织的MSP存放的绝对路径。
    • ORDERER_CONTAINER:排序节点的容器名称。访问排序服务时,你可以访问排序服务中的任意节点。你的请求会自动提交给leader节点。

    Orderer

    Step 1: Pull and translate the config。如果你有了modified_config.json文件,那你可以使用下面的命令来新增Orderer组capabilities:

    jq -s '.[0] * {"通道_group":{"groups":{"Orderer": {"values": {"Capabilities": .[1].orderer}}}}}' config.json ./capabilities.json > modified_config.json
    

    然后执行步骤Step 3: Re-encode and submit the config

    该capability默认的修改策略是需要Orderer组中大多数管理员同意(即,大多数排序服务的管理员)。peer组织可以更新该capability,但这种情况下,peer组织的签名并不满足该策略。

    通道

    Step 1: Pull and translate the config。如果你有了modified_config.json文件,那你可以使用下面的命令来新增通道组capabilities:

    jq -s '.[0] * {"通道_group":{"values": {"Capabilities": .[1].通道}}}' config.json ./capabilities.json > modified_config.json
    

    然后执行步骤Step 3: Re-encode and submit the config

    该capability默认的修改策略是需要ApplicationOrderer大多数管理员审核通过。也就是说,需要peer组织和排序服务组织中大多数管理员对该请求进行签名认证。

    Application

    Step 1: Pull and translate the config。如果你有了modified_config.json文件,那你可以使用下面的命令来新增通道组capabilities:

    jq -s '.[0] * {"通道_group":{"groups":{"Application": {"values": {"Capabilities": .[1].application}}}}}' config.json ./capabilities.json > modified_config.json
    

    然后执行步骤Step 3: Re-encode and submit the config

    该capability默认的修改策略是需要Application大多数管理员审核通过。也就是说,需要peer组织中的大多数管理员进行投票。排序服务的管理员不需要参与。

    这样的结果就是不要将此capability设置为不存在的版本。因为排序节点既不会解析应用程序capabilities,也不会验证它,排序节点会审核通过所有的应用程序capabilities版本并将新的配置块分发给peer节点以便peer节点将其保存到账本中。这样的话,peer节点将无法处理该capability并引起崩溃。即使之后再将一个合法的capability版本配置到peer节点上,但之前的配置块仍存在于账本中,当尝试处理之前的配置块时还是会引发崩溃。

    这也是为什么需要capabilities.json这样的文件。它可以有效防止简单的用户错误,例如,当将应用程序的apability设置为V20,而不是V2_0时,这会导致通道不可用且无法恢复。

    启用capabilities后进行验证

    验证capabilities是否成功启用的最好方式是在所有的通道上执行一次chaincode调用。未升级到相应版本的节点都无法解析新的capabilities,这些节点都会崩溃。在这些节点成功重启之前你需要将它们升级至相应的版本。



    声明:本作品采用署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)进行许可,使用时请注明出处。
    Author: MonsterMeng92


  • 相关阅读:
    SQLite的sqlite_sequence表
    缓存区溢出漏洞工具Doona
    SQLite的sqlite_master表
    dfs1321
    三维bfs(HUD1253胜利大逃亡)
    dfs模版
    poj3259: Wormholes(BF模板题)
    Bellman-Ford算法
    POJ1611:The Suspects(模板题)
    poj3126
  • 原文地址:https://www.cnblogs.com/lianshuiwuyi/p/14704640.html
Copyright © 2020-2023  润新知