Explorer les potins lors du démarrage d’un réseau Fabric – KC Tam

Il s’agit d’une autre démonstration «en coulisses» sur Hyperledger Fabric. Gossip joue un rôle important dans Hyperledger Fabric. Dans cet article, nous inspecterons les ragots au démarrage d’un réseau Fabric, en décomposant le processus de démarrage et en observant les journaux des composants individuels. Nous découvrirons quelques concepts dans le tissu, tels que le leader et le pair d’ancrage, et verrons comment les potins aident à construire une plateforme de consortium évolutive dans Hyperledger Fabric.

Beaucoup d’entre nous commencent à pratiquer Hyperledger Fabric avec des exemples de réseaux comme Premier réseau. First Network fournit un script, nous montrant un flux typique de mise en place d’un réseau:

1. générer du matériel cryptographique et des artefacts de canal
2. faire apparaître les composants du réseau (ordonnateurs, pairs, etc.)
3. rejoindre des pairs pour canaliser
4. mise à jour des pairs d’ancrage

Le réseau est alors prêt à l’emploi. Nous pouvons déployer le code de chaîne en mettant en œuvre notre logique de contrat intelligent.

En fait, il y a un processus intéressant derrière la scène. Ici, nous examinons le rôle des potins et comment ils aident à créer une solution évolutive. Hyperledger Fabric adopte les ragots comme communication peer to peer. Pour optimiser l’ensemble du flux, le protocole de diffusion de données Gossip est mis en œuvre pour réaliser un déploiement et un fonctionnement de réseau évolutifs.

le référence d’architecture fournit une description complète de l’ensemble de cette image. Ici, je viens d’extraire des informations pertinentes pour nous, et nous les verrons en action lors de la démonstration.

Configuration de Gossip Bootstrap

Le bootstrap Gossip est configuré dans chaque homologue. Il contient un ou une liste de pairs au sein d’une organisation. Lorsqu’un pair est opérationnel, il atteindra cette liste de pairs pour commérages.

Dans la configuration du premier réseau, comme nous avons deux homologues dans chaque organisation, une configuration raisonnable consiste à avoir l’autre homologue comme amorce de potins. Et c’est ce que nous observons dans configuration (). Ici, seuls les pairs d’Org1 sont affichés, et nous voyons un modèle similaire chez les pairs d’Org2.

Nous allons voir ce qui se passe quand un pair est opérationnel: il recherchera le bootstrap pour les commérages. En outre, nous verrons également plus tard ce qui se passe si aucun bootstrap n’est défini.

Chef

Le leader d’une organisation est responsable de la réception des blocs de la commande du service et de la distribution des blocs à d’autres homologues de la même organisation. N’oubliez pas qu’un réseau Fabric requiert que tous les homologues de tous les membres du canal (organisations) reçoivent le nouveau blocage du service de commande. L’introduction de «leader» optimise le processus global car le service de commande n’est envoyé qu’au leader de chaque organisation, et leader aux autres pairs de cette organisation.

Le leader est par organisation. Nous verrons dans la démonstration que chaque organisation aura son propre leader. Le leader est également par canal. Avant de rejoindre une chaîne, il n’y a pas de concept de «leader». Il devient pertinent après que l’homologue a rejoint un canal.

Au sein d’une organisation, la direction peut être configurée statiquement ou élue dynamiquement. La configuration par défaut dans First Network est par élection. La configuration est terminée.

Anchor Peer

Un pair d’ancrage est nécessaire dans un réseau pour que les pairs apprennent les membres du canal en dehors de sa propre organisation. Sans un point d’ancrage, la connaissance des membres du canal n’est limitée qu’à une seule organisation. Par exemple, sans homologue d’ancrage, les homologues d’Org1 ne connaissent que les homologues d’Org1 en tant que membres du canal, mais aucune connaissance des homologues d’Org2. Au moins un homologue d’ancrage est nécessaire sur un canal de sorte que tous les homologues de chaque organisation connaissent tous les autres membres de ce canal.

Autre qu’une configuration prédéfinie, l’homologue d’ancrage nécessite une mise à jour de la configuration sur un canal en direct. Une transaction de mise à jour est d’abord créée à l’aide d’un fichier de configuration approprié. Cette transaction est signée et envoyée au service de commande. Un nouveau bloc de configuration portant cette transaction de mise à jour de pair d’ancre, est généré par le service de commande. Une fois que ce bloc a atteint tous les homologues rejoignant ce canal, chaque homologue valide le bloc et connaît désormais l’homologue d’ancrage. Grâce aux commérages, chaque pair connaît désormais tous les pairs, à l’intérieur et à l’extérieur de sa propre organisation, en tant que membres du canal.

Nous verrons plus tard dans l’illustration avant et après la configuration d’un homologue d’ancrage dans le réseau.

Premier réseau et script

Comme nous utilisons First Network, un réseau de deux organisations homologues, Org1 et Org2, chacune est configurée avec deux homologues (peer0 et peer1). Un canal mychannel est créé et rejoint par les quatre pairs. Enfin, peer0 des deux organisations est configuré en tant que pairs d’ancrage.

Le script, une fois exécuté, exécute les tâches suivantes (les étapes indiquées entre parenthèses sont celles de la démonstration)

1. Générez du matériel cryptographique et des artefacts de canal pour l’ensemble du réseau (étape 1)
2. Affichez tous les composants réseau (conteneurs) avec docker-compose (Étape 2–5)
3. Créer un bloc de genèse (bloc # 0) pour mychannel (étape 6)
4. Rejoignez les quatre pairs (des deux organisations) à mychannel (étape 7–10)
5. Mettre à jour la configuration des pairs d’ancrage pour les deux organisations (étape 11–12)

Le réseau est prêt pour le déploiement. Chaque pair connaît d’autres pairs dans ce canal, dans sa propre organisation et d’autres. Voici le résultat après avoir exécuté le script (en utilisant l’option: pas de chaincode déployé).

Dans notre illustration, nous suivons largement ce flux. Pour faire de meilleures observations, nous décomposons un par un le docker-compose pour les pairs. Plus tard, nous modifions également le fichier de configuration ou réorganisons la séquence pour faire des observations.

Étape 0: Préparation

Un nouveau répertoire est directement copié depuis.

cd fabric-samples
cp -r first-network kc-first-network

Nous allons y travailler.

Pendant ce temps, le conteneur CLI d’origine dépend de tous les composants réseau opérationnels. Puisque nous apporterons les composants un par un, nous commentons la dépendance.

Étape 1: générer du matériel cryptographique et des artefacts de canal

Nous nous appuyons pour générer le matériel cryptographique requis et les artefacts de canal pour le réseau.

cd kc-first-network
./byfn.sh generate

Étape 2: Affichez Orderer et CLI

docker-compose -f docker-compose-cli.yaml up -d orderer.example.com cli

Étape 3: Bring Up peer0.org1

docker-compose -f docker-compose-cli.yaml up -d peer0.org1.example.com

Ouvrez un terminal pour inspecter le journal peer0.org1.example.com.

docker logs -f peer0.org1.example.com

Concentrons-nous uniquement sur les activités liées aux potins. À partir du journal, nous avons supposé que Gossip s’initialise avec la configuration (point externe et bootstrap) et que l’instance Gossip démarre.

Cependant, étant donné que le bootstrap Gossip est configuré, peer0.org1.example.com atteint peer1.org1.example.com, qui ne fonctionne pas encore.

Étape 4: Bring Up peer1.org1

docker-compose -f docker-compose-cli.yaml up -d peer1.org1.example.com

Nous ne voyons pas le problème de portée comme peer0.org1.example.com. En réalité peer1.org1.example.com est également configuré avec peer0.org1.example.com comme son bootstrap potins, et commence à atteindre peer0.org1.example.com. Depuis peer0.org1.example.com est opérationnel, nous voyons dans le journal qu’il atteint déjà peer0.org1.example.com (grpc.method = Ping, grpc.code = OK).

Et presque au même moment où peer1.org1.example.com a démarré, peer0.org1.example.com atteint également peer1.org1.example.com. Les horodatages correspondent bien.

• instance de potins de peer1.org1.example.com commencé en 06: 39: 05.878 (ci-dessus)
• peer0.org1.example.com atteint peer1.org1.example.com en 06: 39: 05.892 (ci-dessous)

Avec cela, les deux pairs sont connectés au niveau des potins. Notez qu’il n’y a pas encore de rôle lié au canal comme leader ou pair d’ancrage. Cela se produit lorsque nous rejoignons les pairs à canaliser.

Étape 5: Faire apparaître des pairs d’Org2

Pour garder le flux de démonstration du script, nous apportons peer0.org2.example.com et peer1.org2.example.com ainsi que. Nous observons un comportement similaire.

docker-compose -f docker-compose-cli.yaml up -d peer0.org2.example.com peer1.org2.example.com

Et puisque les deux homologues sont opérationnels presque en même temps, nous ne voyons pas le message de problème de connexion comme nous le voyons à l’étape 3.

Étape 6: préparer le bloc Genesis pour mychannel

docker exec cli peer channel create -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -c mychannel -f ./channel-artifacts/channel.tx

Le résultat est un fichier de bloc de genèse mychannel.block stocké dans le conteneur CLI. Ceci est utilisé pour joindre des pairs à ma Chaîne.

Étape 7: Rejoignez peer0.org1 sur mychannel

Notez le paramètre par défaut des cibles CLI sur peer0.org1.example.com à l’aide de Admin of Org1.

docker exec cli peer channel join -b mychannel.block

Observation à partir du journal

• Créer un livre pour ma Chaîne avec bloc de genèse
• Valider le bloc # 0
• Rejoignez le réseau de potins pour ma Chaîne (avec 2 organisations apprises du bloc # 0)
• Trouver aucune configuration d’ancres homologues des deux organisations pour le moment (cela sera fait à l’étape finale)
• Devenez un leader et élu en tant que leader

Étape 8: Joignez peer1.org1 à mychannel

docker exec -e CORE_PEER_ADDRESS=peer1.org1.example.com:8051 -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/ca.crt cli peer channel join -b mychannel.block

Observation similaire des journaux de peer0.org1.example.com, sauf pour le leadership.

Par conséquent, de la vue des chaînes, peer0.org1.example.com est le leader d’Org1, responsable de la réception de nouveaux blocs provenant du service de commande et de l’envoi à d’autres pairs d’Org1.

Étape 9: Adhésion à Peers of Org1 Learn Channel

Une fois le leadership d’une organisation terminé, nous voyons immédiatement les journaux des deux pairs montrant ce qu’ils apprennent sur l’appartenance au canal.

peer0.org1.example.com: sache maintenant peer1.org1.example.com en tant que membre du canal

peer1.org1.example.com: sache maintenant peer0.org1.example.com en tant que membre du canal

Étape 10: Rejoindre les pairs d’Org2 à mychannel

docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt cli peer channel join -b mychannel.blockdocker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer1.org2.example.com:10051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/tls/ca.crt cli peer channel join -b mychannel.block

Résultat similaire à celui attendu. À propos de l’appartenance à la chaîne sur ces deux pairs. Maintenant on voit

peer0.org2.example.com: en tant que leader, et aussi savoir peer1.org2.example.com en tant que membre du canal

peer1.org2.example.com: voir quelqu’un comme un leader et savoir aussi peer0.org2.example.com en tant que membre du canal

Pour l’instant, nous savons que les ragots fonctionnent bien au sein d’une organisation, car les pairs se connaissent au sein d’une organisation. Mais ce n’est pas encore le tableau final, car les pairs doivent également connaître les pairs d’autres organisations. Ce n’est pas encore disponible jusqu’à ce qu’un homologue d’ancrage soit configuré.

Étape 11: Mettre à jour le pair d’ancrage pour Org1

docker exec cli peer channel update -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -c mychannel -f ./channel-artifacts/Org1MSPanchors.tx

Nous voyons d’abord qu’un nouveau bloc # 1 est créé, reçu et engagé par tout les pairs d’Org1 et d’Org2. Faisons quelques observations.

Tout d’abord, nous observons comment le nouveau bloc atteint chaque pair. Nous savons que de nouveaux blocs sont créés par l’acheteur. À partir de la trace tcpdump, nous voyons seulement que orderer.example.com communiquait avec peer0.org1.example.com et peer0.org2.example.com. Ne pas peer1 sur les deux organisations. C’est parce que les deux pairs des deux organisations sont des leaders.

Notez que cela ne montre que deux paquets. Il s’agit d’une série de paquets entre l’ordonnanceur et les deux pairs0. Mais nous ne voyons pas non plus peer1.

De plus, en capturant le journal de réception du bloc # 1 sur chaque pair, nous pouvons dire que

peer0.org1.example.com (horodatage: 07: 01: 34.583)

peer1.org1.example.com (horodatage: 07: 01: 34.588)

peer0.org2.example.com (horodatage: 07: 01: 34.631)

peer1.org2.example.com (horodatage: 07: 01: 34.637)

Nous voyons peer1 recevoir le bloc un peu plus tard que peer0, dans les deux organisations. Bien que cela ne puisse pas être une preuve solide, au moins cela correspond à ce que l’on nous dit qu’un leader envoie à d’autres pairs au sein d’une organisation. C’est ainsi que l’évolutivité est obtenue, en introduisant des leaders et en divisant la «diffusion» à canaliser en deux niveaux.

Deuxièmement, nous observerons ce qui se passe après que chaque pair a validé le bloc dans le grand livre. Ils commettent tous des ragots une fois qu’ils savent qu’un pair d’ancrage leur est connu. Après plusieurs tours de commérages, nous voyons le résultat de l’adhésion à la chaîne.

peer0.org1.example.com

peer1.org1.example.com

peer0.org2.example.com

peer1.org2.example.com

La carte d’adhésion entière pour chaque pair est complètement apprise. En bonus, nous voyons également comment les pairs d’Org2 apprennent peer1.org1.example.com dans les potins suivants.

Désormais, chaque homologue d’un canal connaît tous les autres homologues, à l’intérieur et à l’extérieur de son organisation. Avec cela, le réseau doit être prêt à l’emploi.

Étape 12: Mettre à jour l’ancre homologue pour Org2

Nous voyons qu’un seul point d’ancrage dans un canal rend le réseau prêt à l’emploi. Il est fortement recommandé d’avoir un pair d’ancrage par organisation.

docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt cli peer channel update -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -c mychannel -f ./channel-artifacts/Org2MSPanchors.tx

Nous voyons maintenant le changement de vue d’appartenance à la chaîne, car celui de l’étape précédente est déjà la dernière vue.

À des fins d’apprentissage, nous ferons quelques observations en faisant varier certaines étapes. Cela nous aide à mieux comprendre comment le changement affecte le réseau Fabric.

Suppression de Gossip Bootstrap de la configuration d’homologue

Le bootstrap de potins est installé. Commentez les variables sur chaque pair.

Nous répétons le flux global ci-dessus. Ici, je souligne simplement les résultats des journaux.

Après les étapes 3 et 4, nous voyons deux pairs dans Org1 ne pas se parler au niveau des potins. Similaire dans Org2 après l’étape 5.

Après avoir rejoint tous les pairs de mychannel avec le fichier de blocage, nous observons tous les pairs sont désormais élus à la tête.

peer0.org1.example.com

peer1.org1.example.com

peer0.org2.example.com

peer1.org2.example.com

Cela est dû au manque de ragots au sein d’une organisation.

Est-ce un problème? Voyons ce qui se passe si nous mettons à jour l’homologue d’ancrage (étape 11).

peer0.org1.example.com

peer1.org1.example.com

peer0.org2.example.com

peer1.org2.example.com

Après avoir bavardé, tous les pairs du canal ont la bonne vue d’appartenance au canal. Nous observons également que certains pairs ont arrêté ou renoncé à la direction.

peer0.org1.example.com

peer0.org2.example.com

Notre observation est que, sans bootstrap de ragots configuré sur chaque pair, l’élection du leader au sein d’une organisation est hors de contrôle, car chaque pair prétend être leader. Ce n’est certainement pas la situation souhaitée, car l’ordonnateur doit parler à chaque leader. Après la mise à jour d’une configuration d’ancre homologue, tous les homologues apprennent enfin la vue complète de l’appartenance au canal. Dans le même temps, certains pairs cessent également d’être un leader. Cela réalise ce que nous souhaitons avoir. Par conséquent, l’image finale devrait bien fonctionner, même si nous n’avons pas de bootstrap de potins configuré sur chaque homologue.

Avoir Anchor Peer Update avant de rejoindre une autre organisation

Dans la mise à jour de l’ancre (étape 11) est effectuée après que les pairs d’Org2 ont rejoint le canal (étape 10). Ici, nous observons ce qui se passe si nous échangeons ces deux étapes. C’est-à-dire, ma Chaîne a déjà un pair d’ancrage avant que les pairs d’Org2 ne rejoignent ma Chaîne.

Ici, nous nous joignons seulement peer0.org2.example.com à ma Chaîne. Après avoir rejoint, nous voyons d’abord le même processus se produire que ce que nous avons vu à l’étape 7.

• Créer un livre pour ma Chaîne avec bloc de genèse
• Valider le bloc # 0
• Rejoignez le réseau de potins pour ma Chaîne (avec 2 organisations apprises du bloc # 0)
• Trouver aucune configuration d’ancres homologues des deux organisations pour le moment (cela sera fait à l’étape finale)
• Devenez un leader et élu en tant que leader

Juste après ça, peer0.org2.example.com reçoit le bloc # 1 (de la part du client). Et après avoir validé le bloc # 1, il apprend un pair d’ancrage peer0.org1.example.com, et commence à bavarder.

Le résultat est positif: peer0.org2.example.com apprend aux deux pairs d’Org1 en tant que membres du canal.

Et presque en même temps, les pairs d’Org1 apprennent également ce nouveau pair en tant que membre du canal.

peer0.org1.example.com

peer1.org1.example.com

Le résultat semble le même que ce que le script exécute, avec un changement de moment où le pair d’ancrage est mis à jour. Je vois cela comme un scénario plus réaliste, car dans de nombreux cas, une nouvelle organisation rejoint un réseau en direct (où des pairs d’ancrage auraient déjà dû être là). Il élimine également la courte fenêtre de fractionnement lorsque la configuration des pairs d’ancrage n’est pas encore mise à jour.

Dans cet article, nous avons examiné le rôle des ragots dans la mise en place d’un réseau de fabric. Nous avons suivi le script de First Network en décomposant en étapes, et observé à partir des journaux les comportements lors de l’apparition d’un homologue, de l’adhésion d’un homologue à un canal, le rôle d’ancre homologue dans l’apprentissage de l’appartenance à plusieurs organisations. Nous avons également fait quelques variations pour en savoir plus sur les potins et le réseau de tissus. J’espère que vous pourrez avoir plus d’idées sur Hyperledger Fabric.