Dans Hyperledger Fabric, quel est le comportement attendu de l'homologue lorsque tous les nœuds de commande sont arrêtés. Le pairage doit-il également être arrêté, ou arrêter de servir la demande du client ou continuer à servir la demande de requête?
Dans notre test, une fois que les commandes sont arrêtées, le pair continue d'écrire le journal «Échec de la création de la connexion au client». Lorsque nous interrogeons une clé en appelant chaincode, la valeur est renvoyée.
Pouvez-vous aider à clarifier s'il s'agit d'un comportement attendu. Merci.
3 Réponses :
Je travaille sur un réseau de fabric hyperledger distribué. Je recommanderais le Orderer Raft Consensus https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html#ordering-service-implementations . J'ai résolu cela de telle manière que dans mon cas, j'ai trois commandes qui fonctionnent indépendamment sur différents environnements. Si je plante tous ces clients, les conteneurs homologues continueront à fonctionner sur les autres participants du réseau. Comme vous l'avez dit, ils ne peuvent effectuer aucune transaction. Si l'un de mes clients tombe en panne, ce n'est pas si grave après le consensus du radeau, les conteneurs continuent de fonctionner. Si un autre échoue, aucune transaction ne peut être effectuée. Dans ce cas, je laisse les pairs continuer et vérifier si les clients sont à nouveau disponibles.
Le comportement que vous avez décrit serait attribuable au fait que le pair demande la valeur de son grand livre, il n'a pas besoin d'un ordre pour cela. https://hyperledger.github.io/fabric-chaincode-node/master/api/fabric-shim.ChaincodeStub.html#getState
Lisez ceci: https://github.com/hyperledger/fabric/blob/master/docs/source/peers/peers.md Ceci est la meilleure documentation sur le fonctionnement du système que j'ai trouvée et il y en a plus dans le répertoire docs sur le repo pour les clients, etc.
Ma compréhension est la suivante: les pairs sont là pour signer (approuver) les propositions de transaction. Le client existe pour commander, valider, conditionner et distribuer des transactions à des pairs. Les pairs peuvent également diffuser leur connaissance des transactions validées via le canal des potins.
Si tous les clients tombent en panne, les transactions ne seront pas validées / conditionnées / distribuées et la blockchain sera donc hors service jusqu'à ce que les clients soient restaurés.
Lorsque nous interrogeons une clé en appelant chaincode, la valeur est renvoyée.
Les pairs resteront toujours prêts à signer / approuver les propositions de transaction, et l'interrogation de la blockchain détenue chez les pairs fonctionnera toujours. Les codes de chaîne sont hébergés par les pairs. Les clients n'hébergent pas de code de chaîne.
Voir également ici https://github.com/hyperledger/fabric/blob/master/docs/source/orderer/ordering_service.md#ordering-service-implementations pour les différents modes dans lesquels le client peut être exécuté: mode Raft, commande Kafka , Commande en solo.
Je pense que le comportement actuel de l'observateur est attendu et à mon avis c'est très bien.
Vérifions le but du client?
Cela signifie également que le client est nécessaire lorsque votre réseau Fabric traite les transactions qui ont l'intention d'écrire des données dans le grand livre, n'est-ce pas? Et la requête n'est pas une transaction qui écrit dans le grand livre. Donc, il n'a pas besoin du client. Pour la requête, il récupérera les données de la base de données locale de l'homologue.
Je pense donc que ce qui pourrait être fait, c'est d'envoyer une alerte au support de production lorsque votre application détecte un nœud de commande en panne (avec une vérification de l'état?). Et votre application affiche un message de capacité réduite / d'opérations limitées tout en travaillant à la mise en place du réseau de commande, le système peut toujours servir les requêtes de recherche.
De mon point de vue, c'est tout simplement fantastique. Mais c'est finalement à vous. À votre santé!!