Новый заказчик RAFT не может обнаружить, что он принадлежит каналу приложения

Question

Исходная сеть Hyperledger Fabric имеет следующую структуру:

org1.example.com имеет 2 узла RAFT.Название системного канала system-channel (определен только 1 консорциум).Имя канала приложения - channel1, в котором одноранговый узел из org1.example.com работает chaincode1.Обратите внимание, что нет отдельной организации-заказчика.

Профиль системного канала:

    OrdererGenesis:
        <<: *ChannelDefaults
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *Org1
        Consortiums:
            SampleConsortium:
                Organizations:
                    - *Org1

Я хочу добавить другую организацию org2.example.com, чтобы конечная сеть была:

Шаги, которые я предпринял для system-channel (я следовал https://hyperledger -fabric.readthedocs.io / en / release-1.4 / raft_configuration.html # reconfiguration ):

1. Добавить определение Org2MSP в группу каналов Orderer в system-channel
2. Добавить определение Org2MSP в группу каналов Consortium в system-channel
3. Добавить в Org2 заказчикинформация (сертификаты TLS и т. д.) к списку участников, например channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters в system-channel
4. Запустить Org2, например, orderer0.org2.example.com
5. Добавить orderer0.org2.example.com в списокадреса заказчиков в system-channel т.е. .channel_group.values.OrdererAddresses.value.addresses

Все вышеперечисленные шаги работают хорошо и orderer0.org2.example.com обслуживает system-channel

Продолжая, шаги, которые я предпринял для channel1:

1. Добавить определение Org2MSP в группу каналов Orderer в channel1
2. Добавить определение Org2MSP в группу каналов приложений в channel1
3. Добавить orderer0.org2.example.com в список адресов заказчиков в channel1, например, .channel_group.values.OrdererAddresses.value.addresses
4. Добавить информацию orderer0.org2.example.com (tls certs и т. Д.) В список участников, т.е. channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters в channel1

До шага № 3 все ок.После выполнения шага 4 я начинаю видеть channel1 does not exist ошибки в новом добавленном заказчике orderer0.org2.example.com:

2019-05-09 09:38:03.360 UTC [comm.grpc.server] 1 -> INFO 05a streaming call completed grpc.service=orderer.Cluster grpc.method=Step grpc.peer_address=192.168.224.6:43116 grpc.peer_subject="CN=orderer0.org1.example.com,OU=peer+OU=org1,O=org1.example.com,L=Singapore,ST=Singapore,C=SG" error="channel channel1 doesn't exist" grpc.code=Unknown grpc.call_duration=711.5µs

В текущем руководстве RAFT также есть сообщения об ошибках (3 относится кorderer0.org2.example.com:

2019-05-09 09:38:02.859 UTC [orderer.consensus.etcdraft] logSendFailure -> ERRO 0c5 Failed to send StepRequest to 3, because: aborted channel=channel1 node=1

Кажется, что orderer0.org2.example.com не знает, что он должен обслуживать channel1. Я также не вижу папку channel1 в /var/hyperledger/production/orderer/chains в orderer0.org2.example.com

В процессе устранения неполадок я попытался сохранить папку /var/hyperledger/production/orderer всех заказчиков, в которой содержится цепочка, завершить работу orderer0.org1.example.com и orderer0.org2.example.com и скопировать папку channel1 из orderer0.org1.example.com в * 1101.* и, наконец, запустите обоих заказчиков.

Теперь orderer0.org2.example.com знает, что он должен обслуживать channel1, что подтверждается в журналах

2019-05-10 02:36:04.161 UTC [orderer.consensus.etcdraft] apply -> INFO 044 Applied config change to add node 1, current nodes in channel: [1] channel=channel1 node=3
2019-05-10 02:36:04.161 UTC [orderer.consensus.etcdraft] apply -> INFO 045 Applied config change to add node 2, current nodes in channel: [1 2] channel=channel1 node=3
2019-05-10 02:36:04.161 UTC [orderer.consensus.etcdraft] writeBlock -> INFO 046 Got block [6], expect block [7], this node was forced to catch up channel=channel1 node=3
2019-05-10 02:36:04.161 UTC [orderer.consensus.etcdraft] apply -> INFO 047 Applied config change to add node 3, current nodes in channel: [1 2 3] channel=channel1 node=3

Исходя из вышесказанного, очевидно, что orderer0.org2.example,com не может получить блок channel1 для начала обслуживания канала. Для пиров одноранговый узел может получить блок и выдать peer channel join block_name.block, но заказчики не могутсделайте это. Мне интересно, какой шаг я пропускаю.

Чтобы смоделировать окружающую среду и воспроизвести проблемусм .: https://github.com/aldredb/bring-your-own-orderer

Answer 1

Это решено. Проблема заключается в том, что я не использовал последний блок конфигурации в качестве блока начальной загрузки в новом заказчике, orderer0.org2.example.com. Как только я это сделаю, orderer0.org2.example.com сможет обнаружить channel1:

2019-05-10 14:06:04.778 UTC [orderer.common.server] replicateDisabledChains -> INFO 072 Successfully replicated 0 chains: []
2019-05-10 14:06:44.680 UTC [orderer.common.server] replicateDisabledChains -> INFO 073 Found 1 inactive chains: [channel1]
2019-05-10 14:06:44.689 UTC [orderer.common.cluster] ReplicateChains -> INFO 074 Will now replicate chains [channel1]