Fabric はオーダラーを動的に追加します

ラフトモードでの注文者の追加については、公式サイトに大体の流れが載っています

再構成する

Raft オーダラーはノードの動的な追加と削除をサポートしますが (つまり、チャネルが使用されている間)、一度に 1 つのノードのみをサポートします。再構成を試みる前に、クラスターがメンテナンスを維持し、コンセンサスを達成できる状態にある必要があることに注意してください。最悪の例として、3 つのノードがあり、2 つのノードがダウンした場合、raft クラスターを構成してノードを削除することはできません。同様に、3 つのノードを持つチャネルに 1 つのダウン ノードがある場合、証明書を置き換えようとしないでください。これにより、2 次エラーが発生します。*ガイドラインとして、すべての consensuser がオンラインで正常でない限り、consensuser の追加または削除、consensuser の証明書の置き換えなど、Raft consensuser の構成変更を試みてはなりません。

これらのパラメーターを変更する場合は、メンテナンス サイクル中にのみ試すことをお勧めします。構成の変更に関する問題の大部分は、少数のノードしかないクラスターで発生し、1 つのノードがダウンします。たとえば、3 つのコンセンサス ノードがあり、そのうちの 1 つがダウンした場合、それは 2 つのノードしか生きていないことを意味します。この状態でクラスターを 4 つのノードにスケーリングすると、まだ 2 つのノードしか稼働していないため、クォーラムを確保できません。ノードは実行中のクラスターにしか参加できないため、4 番目のノードをオンラインにすることはできません (クラスターの合計サイズが 1 または 2 の場合)。

そのため、3 ノード クラスター (稼働中のノードは 2 つだけ) を 4 ノードにスケーリングすると、元のオフライン ノードが復旧するまで完全に行き詰まります。

Raft クラスターに新しいノードを追加するには、次の手順が必要です。

1. チャネル構成の更新トランザクションにより、新しいノードの TLS 証明書がチャネルに追加されます。注: 新しいノードは、1 つ以上のアプリケーション チャネルに参加する前に、まずシステム チャネルに参加する必要があります。
2. システム チャネルの一部であるorderer から最新のシステム チャネル構成ブロックを取得します。
3. 構成ブロックに (予定の) 参加ノード証明書が含まれていることを確認して、このノードがシステム チャネルの一部であることを確認します。
4. General.BootstrapFileconfigパラメータで指定された config ブロック パスで新しい Raft ノードを開始します。
5. Raft ノードが、既存のノードから証明書が結合されているチャネルのブロックをコピーするのを待ちます。このステップが完了すると、ノードはチャネルの提供を開始します。
6. 新しく追加された Raft ノード エンドポイントをすべてのチャネルの構成に追加します。

簡単に言えば、すでに実行されている (そしていくつかのチャネルに参加している) ノードは、実行時にチャネルに追加できます。これを行うには、ノードの証明書をチャネルのチャネル構成に追加するだけです。ノードは、新しいチャネルに参加したことを自動的に検出します (デフォルト値は 5 分ですが、ノードが新しいチャネルをより速く検出するようにしたい場合は、ノードを再起動できます)、チャネルのオーダラーからチャネル ブロックをプルします。 、そして最後にチェーン用の新しいチャネルを作成します Raft インスタンスを開始します。

上記のステップを正常に完了した後、チャネル構成を更新して、新しい Raft オーダラーのエンドポイントを含めることができます。

#查看这个介绍，我们可以感觉到官方在介绍这一部分时只给了大概流程，仅看这个的话很难操作。这是因为这类操作，官方在【动态新增组织】中进行了比较详见的流程介绍，主要区别在于
#1.在将orderer节点添加到指定应用通道前，需要先将orderer节点添加到系统通道中。
#2.修改配置区由peer修改为orderer。这部分需要自己寻找

したがって、公式の紹介を参照すると、動的追加プロセスは次のように設計できます。

プロセスを動的に追加する

環境構成

デバイスにはすでに 3 つの orderer ノードと 1 つのピア ノードがあります

注文者証明書の生成

Fabric は、証明書を生成する 2 つの方法を提供します。fabric-ca の生成と cryptogen ツールの生成。

構成ファイルを変更する

証明書生成ファイル crypto-config.yaml は orderer4 の構成を追加します

OrdererOrgs:
  # ---------------------------------------------------------------------------
  # Orderer
  # ---------------------------------------------------------------------------
  - Name: Orderer
    Domain: example.com.local
    # ---------------------------------------------------------------------------
    # "Specs" - See PeerOrgs below for complete description
    # ---------------------------------------------------------------------------
    Specs:
      - Hostname: orderer1
      - Hostname: orderer2
      - Hostname: orderer3
      - Hostname: orderer4     #新增

証明書を生成する

ファブリック ネイティブ コマンド

cryptogen extend --input crypto-config  --config ./crypto-config.yaml    

アリン変身後

#allin改造中使用证书合并模式。复制orderer1的证书，修改路径及证书名称

更新するデータを含むチャネル構成ファイルを準備します

オプション 1

configtx.yaml ファイルを変更し、orderer4 に関する情報を追加します。このプロセスは、主に組織を動的に追加するプロセスを指します。高度に自動化されたファブリック独自のコマンドを使用して、json ファイルを自動的に生成します。

    SampleMultiNodeEtcdRaft:
        <<: *ChannelDefaults
        Capabilities:
            <<: *ChannelCapabilities
        Orderer:
            <<: *OrdererDefaults
            OrdererType: etcdraft
            EtcdRaft:
                Consenters:
                - Host: orderer1.example.com.local
                  Port: 7050 
                  ClientTLSCert: crypto-config/ordererOrganizations/example.com.local/orderers/orderer1.example.com.local/tls/server.crt
                  ServerTLSCert: crypto-config/ordererOrganizations/example.com.local/orderers/orderer1.example.com.local/tls/server.crt
                - Host: orderer2.example.com.local
                  Port: 8050 
                  ClientTLSCert: crypto-config/ordererOrganizations/example.com.local/orderers/orderer2.example.com.local/tls/server.crt
                  ServerTLSCert: crypto-config/ordererOrganizations/example.com.local/orderers/orderer2.example.com.local/tls/server.crt
                - Host: orderer3.example.com.local
                  Port: 9050 
                  ClientTLSCert: crypto-config/ordererOrganizations/example.com.local/orderers/orderer3.example.com.local/tls/server.crt
                  ServerTLSCert: crypto-config/ordererOrganizations/example.com.local/orderers/orderer3.example.com.local/tls/server.crt
                - Host: orderer4.example.com.local                                                                                        #新增
                  Port: 10050                                                                                                             #新增
                  ClientTLSCert: crypto-config/ordererOrganizations/example.com.local/orderers/orderer4.example.com.local/tls/server.crt  #新增
                  ServerTLSCert: crypto-config/ordererOrganizations/example.com.local/orderers/orderer4.example.com.local/tls/server.crt  #新增
            Addresses:
                - orderer1.example.com.local:7050 
                - orderer2.example.com.local:8050 
                - orderer3.example.com.local:9050
                - orderer4.example.com.local:10050                                                                                         #新增
            Organizations:
            - *OrdererOrg
            Capabilities:
                <<: *OrdererCapabilities
        Application:
            <<: *ApplicationDefaults
            Organizations:
            - <<: *Org1
        Consortiums:
            SampleConsortium:
                Organizations:
                - *Org1

テストを変更した後、ファブリックによって提供されるコマンドは組織レベルの選択のみをサポートすることがわかりましたが、変更する必要がある部分は、プロファイル モジュールを使用できないことです。

    configtxgen -configPath $FABRIC_CFG_PATH/configs -printOrg ${SET_MSP_ID} >$FABRIC_CFG_PATH/configs/${SET_PEER_ORG_NAME}.json
     -printOrg    string   将组织的定义打印为JSON。(对于手动向通道添加组织非常有用)

オプション II

追加するデータを事前に用意せず、更新時に直接生成して該当ファイルに更新する

現在のチャネル プロファイルを取得する

環境変数を設定する

export FABRIC_CFG_PATH=/root/raft/configs
export CORE_PEER_LOCALMSPID=Org1MSP
export CORE_PEER_MSPCONFIGPATH=${FABRIC_CFG_PATH}/crypto-config/peerOrganizations/org1.example.local/users/[email protected]/msp
export CORE_PEER_ADDRESS=peer1.org1.example.local:7051
export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_TLS_ROOTCERT_FILE=${FABRIC_CFG_PATH}/crypto-config/peerOrganizations/org1.example.local/peers/peer1.org1.example.local/tls/ca.crt
export CORE_PEER_TLS_KEY_FILE=${FABRIC_CFG_PATH}/crypto-config/peerOrganizations/org1.example.local/peers/peer1.org1.example.local/tls/server.key
export CORE_PEER_TLS_CERT_FILE=${FABRIC_CFG_PATH}/crypto-config/peerOrganizations/org1.example.local/peers/peer1.org1.example.local/tls/server.crt
export ordererCa=${FABRIC_CFG_PATH}/crypto-config/ordererOrganizations/example.local/orderers/orderer1.example.local/msp/tlscacerts/tlsca.example.local-cert.pem

注意：新节点在加入一个或更多应用通道前，必须先加入到#系统通道 即syschannel
所以在文档中以syschannel为例，讲解流程。在加入应用通道是，需要经syschannel 更换为对应应用通道的名称

最新の構成ブロック ファイルをプルする

config_block.pb

peer channel fetch config $FABRIC_CFG_PATH/config_block.pb -o orderer1.example.com:7050 -c syschannel --tls --cafile $ordererCa

フォーマットの抽出と変換

config_block.pb から有効なデータを抽出し、編集可能な json 形式に変換します

configtxlator proto_decode --input $FABRIC_CFG_PATH/config_block.pb --type common.Block | jq .data.data[0].payload.data.config > $FABRIC_CFG_PATH/config.json

注文者の構成を変更する

生成された json ファイルで、orderer4 の情報 (証明書関連のパスを証明書ファイル自体の形式 (base64) に変更する必要があります) を、ソリューション 1 で新しく追加された対応する位置に記述します。新しい json ファイル config_updated.json を取得します

//此处应有图，脚本编写完成,实际执行成功后补

新しい構成を構築する

#把前后的两个json文件重新转换回pb类型文件 
configtxlator proto_encode --input $FABRIC_CFG_PATH/config.json --type common.Config > $FABRIC_CFG_PATH/config_block_origin.pb
configtxlator proto_encode --input $FABRIC_CFG_PATH/config_updated.json --type common.Config > $FABRIC_CFG_PATH/config_block_updated.pb
#比较前后两个pb文件的差异，得到改动部分 
configtxlator compute_update --channel_id byfn-sys-channel --original $FABRIC_CFG_PATH/config_block_origin.pb --updated $FABRIC_CFG_PATH/config_block_updated.pb > $FABRIC_CFG_PATH/config_diff.pb
#把配置变化部分转化为json文件
configtxlator proto_decode --input $FABRIC_CFG_PATH/config_diff.pb --type common.ConfigUpdate > $FABRIC_CFG_PATH/config_diff.json
#为上述json文件添加头部信息(Header)，封装成一个完整的config update请求
echo '{"payload":{"header":{"channel_header":{"channel_id":"byfn-sys-channel", "type":2}},"data":{"config_update":'$(cat $FABRIC_CFG_PATH/config_diff.json)'}}}' | jq . > $FABRIC_CFG_PATH/config_diff_envelope.json
#把封装好的json文件转换回pb格式文件
configtxlator proto_encode --input $FABRIC_CFG_PATH/config_diff_envelope.json --type common.Envelope > $FABRIC_CFG_PATH/config_diff_envelope.pb

サイン

peer channel signconfigtx -f $FABRIC_CFG_PATH/config_diff_envelope.pb

更新リクエストを送信する

peer channel update -f $FABRIC_CFG_PATH/config_diff_envelope.pb -c byfn-sys-channel -o orderer.example.com:7050 --tls true --cafile $ORDERER_CA

終了

システムチャンネル追加後、チャンネル名を申請チャンネル（参加したいチャンネル）に変更し、再度異議申し立て手続きを行ってください。

orderer4 ノードを起動します

orderer ノードを起動するプロセスは、元の起動方法と大差ありませんが、注意と解決が必要な点がいくつかあります。

1.新节点的hosts更新
2.peer的客户端维护的orderer列表里，需要把新增的orderer更新进去

ログを確認します。正常に起動し、(参加しているすべてのアプリケーション チャネルの) ブロックの同期を開始する場合は、プロセス全体が正常に完了したことを意味します。

参照文書

RAFT の再構成に関する公式ドキュメント: https://hyperledger-fabric.readthedocs.io/en/latest/raft_configuration.html#reconfiguration

公式文書の動的な新しい組織: https://hyperledger-fabric.readthedocs.io/en/latest/channel_update_tutorial.html

Fabric 1.4.2 はオーダーノードを動的に追加します: https://www.jianshu.com/p/49a915bed152

Fabric は Raft ノードを動的に構成します: https://www.cnblogs.com/cbkj-xd/p/12123860.html

発注者プロセス設計を動的に追加

プロダクトの境界で、守らなければならない設定がありますが、この設計では守らなければならない点がいくつかあります。

1、每台机器上的orderer节点不允许超过3个。
2、sdk（即peer的客户端），需要动态的更新最新的orderer列表，以便可发送消息给最新的orderer节点
3、私钥不出设备

上記制限事項を遵守することを前提として、工程設計を行ってください。

実行環境

事前調査の過程で、プロセスの実行環境、証明書の生成、および署名機関を決定する主な要因はすべて、発注者組織の管理者が配置されているノードを指していることがわかりました。

署名権限

ただし、アクセス許可ポリシーを変更することで、すべての注文者メンバーに管理者アクセス許可を付与できます。ただし、チェーン上の注文者の秘密鍵を、注文者ノードのないデバイスと共有することはできません。

すべて、実行オブジェクトは

1.如果不将Admin权限下放，执行对象应该是orderer组织Admin在的设备，即联盟的第一台设备。
2.如果将权限下放给组织成员，那执行对象也至少要是一个已存在orderer节点的设备，而不是任意一台机器。

これには、チェーンで利用可能なオーダラーのリストを維持し、どのオーダラーのデバイスを実行環境として使用するかをいつ選択するかについてのルールを設定する必要があります。

証明書の生成

秘密鍵はデバイスから出てこないため、新しいデバイスにはオーダラー ノードがありません。既存の注文者証明書を直接共有することはできなくなります。

この場合、CSR のみを使用して発注元組織 ca に証明書を申請し、発注元の秘密鍵と証明書を新しいデバイスで事前に準備します。

この場合、証明書を生成するステップはプロセス内に確保する必要があり、2 つのプロセスの違いをユーザーに説明することはできません (注文者ユーザーはそれを認識できません)。

また、現在の製品は主に csr-ca-cert 証明書スキームに適合しているため、既存の注文者がいるデバイスに注文者が追加されても、証明書共有モードは選択されなくなりました。

投票

組織内のメンバーが参加するときに、構成センターでノードを動的に追加する設計を参照してください。組織内の管理者ノードが同意する必要があるのは 1 回だけです。

このように、新しい組織オーダラを非動的に追加する場合、選択された実行デバイスは、投票なしで署名操作を直接実行できます。発注者はコンセプトをユーザーに公開しないように配慮する必要があるため、この場合、投票プロセスは当面追加されません。

SDKの更新

新しく参加したノードがオーダラーが配置されているデバイスの IP を取得し、独自のホストをセットアップするため。最初のデバイスがネットワークを初期化した後、注文者リストがチェーンにアップロードされます。アップリンク データは、デバイス IP と orderer1 の ca/tlsca 証明書 (チャネル作成用) です。したがって、新しいオーダラーが操作を完了すると、更新が必要な現在のデバイスを非常に簡単な方法で知ることができ、リスト内の IP に通知を送信すると、対応するデバイスがチェーンに移動して最新のオーダラーを取得します。通知を受け取った後にリストします。独自のホストと SDK で orderer ユーザーのリストを更新します。

SDKユーザーリストの更新も動的である必要があり、通常の使用に影響を与えることなく実行する必要があることに注意してください