Peer discovery in multiple Org network - hyperledger-fabric

We are setting up a multi-Org network, and have Anchor Peers defined and installed. We understand that Anchor Peers are used in peer discovery, but one question remains open: When a client needs to collect endorsements, how does it discover peers in the other Org to direct proposals to for endorsement? Is the Anchor Peer a "directory service" (and if so, how do we read the directory from the client SDK), or is it a "gateway" (and if so, how do we say how many endoresments we are trying to gather)?

When a client needs to collect endorsements, how does it discover
peers in the other Org to direct proposals to for endorsement?
Excellent question. There is a document for that.
Pasting below the relevant part:
The service runs on peers – not on the application – and uses the network metadata information maintained by the gossip communication layer to find out which peers are online. It also fetches information, such as any relevant endorsement policies, from the peer’s state database.
With service discovery, applications no longer need to specify which peers they need endorsements from. The SDK can simply send a query to the discovery service asking which peers are needed given a channel and a chaincode ID.
In a nutshell, starting from Fabric v1.2, the SDK can query a peer for the peers it needs to request endorsements from.
Is the Anchor Peer a "directory service"
No, it is not. The idea is that starting from Fabric v1.2, every peer that you trust as a client (i.e - a peer that belongs to your own organization) can serve your SDK as a discovery service endpoint.
There is also a brand new (friendly to use!) CLI tool that is included in v1.2 and can be used to query the discovery service on a peer.
There should be documentation published for the various SDKs once v1.2 is released.
or is it a "gateway" (and if so, how do we say how many endoresments
we are trying to gather)?
It is also not a gateway, it's only used for peers to bootstrap their membership view when they startup or join a channel.

Related

Specify endorsing peer when Service Discovery is disabled

I have a Hyperledger-Fabric network with two organisations: Org1 and Org2.
The service discovery is disabled.
When organization 1 submits a transaction in a channel, can he designate endorsing peer of other organizations in the channel to endorse it?
How to do it? Since the service discovery is disabled, organization1 may generate peer info from the channel config block?
It would help to say which client API and/or language you are using.
With discovery disabled, your client is only going to know about the nodes defined in the connection profile that it uses to connect to the network. For a Node client, you can use setEndorsingOrganizations() or setEndorsingPeers() on the Transaction object. For Java you can use setEndorsingPeers() on the Transaction object. For Go you can use the WithEndorsingPeers option.
I would recommend configuring discovery in your network and using it in your clients. You will need to have discovery enabled to use the new Fabric Gateway service and Fabric Gateway client API introduced with Fabric v2.4. If you can use that, I would highly recommend it instead of the legacy SDKs.

Should number of applications and number of peer nodes be equal?

I was reading the documentation of hyperledger (https://hyperledger-fabric.readthedocs.io/en/release-2.2/network/network.html) and I have a question from this paragraph
We can see that the careful addition of peers to the network can help support increased throughput, stability, and resilience. For example, more peers in a network will allow more applications to connect to it; and multiple peers in an organization will provide extra resilience in the case of planned or unplanned outages.
Does the sentence more peers in a network will allow more applications to connect to it mean that one application should be communicating with one peer node and thus number of nodes should be equal to the number of applications on the channel?
If so why can't multiple applications just communicate directly to one node instead?
As part of planning to create a peer, you will need to consider your strategy at an organization level in order to ensure zero downtime of your components. This means building redundant components, and specifically redundant peers. To ensure zero downtown, you need at least one redundant peer in a separate virtual machine so that peers can go down for maintenance while client applications go on submitting endorsement proposals uninterrupted.
Along similar lines, client applications should be configured to use Service Discovery to ensure that transactions are only submitted to peers that are currently available. As long as at least one peer from each organization is available, and service discovered is being used, any endorsement policy will be able to be satisfied. It is the responsibility of each organization to make sure their high availability strategy is robust enough to ensure that at least one peer owned by their organization is available at all times in every channel they’re joined to.

Hyperledger Fabric: Unable to Invoke using Node SDK

I am having an issue in the Hyperledger fabric Node SDK.
Network Details:
The network consists of 4 organisations each deployed on different Kubernetes cluster.
Each organisation has 2 peers which joined a single channel say mychannel.
Each organisation has 1 CA running.
Ordering service is Raft.
CouchDB is used as statedb.
The invokes from the CLI are also working fine and the data is being synced between all the 8 peers.
Hypelredger explorer is up and running with the one organisation details and is able to list all the other 6 peers in the dashboard.
Now back to issue, I tried to deploy the Node.js SDK for Org1.
I created a connection profile having the details of the Org1 Peers, Orderer and CA.
The users are enrolled (Admin and user1).
Now when I try to invoke transaction there are two cases:
Service discovery enabled: In this case, the SDK tries to communicate with the other peers in the network and creator org peers but all returns the context deadline exceed error.
Service discovery disabled: Invokes successful.
I have no idea why the invoke transactions are failed when the service discovery is enabled.
The above issue is resolved when I added the host aliases into my /etc/hosts file.
I need to add the host names and IP for each peer in the /etc/hosts files.
After adding the host names, the SDK started working.
Thanks
Could be your anchor peers are configured incorrectly, since discovery reports those, and some clients will use them.

Hyperledger Fabric port 7053

In the Hyperledger Fabric peer definition, we map ports 7051 and 7053. I understand that 7051 is used for connecting the peer, and it is also used by the peers for gossiping. The port 7052 is used for chaincode connections. However, I am not sure about the use of port 7053. Can anyone please describe it?
Port 7053 is the default port for the event hub service which can be used by client to subscribe to block and chaincode events. In Fabric v1.0 it was also the only mechanism used by the various client SDKs for checking the status of a transaction submitted by the client.
In Fabric v1.1 and v1.2, the event hub still exists (but it is going away in Fabric v1.3) but has been superseded by a channel-based event service which uses the same port--7051-- as other peer services. See http://hyperledger-fabric.readthedocs.io/en/release-1.2/peer_event_services.html?highlight=channel%20event%20service for additional information on this service.

List all the peers, part of the channel in hyperledger fabric

I created a channel in hyperledger fabric, and joined 7 peers to it. i did all this using CLI container. I need to know is there any command to list all the peers which are connected to a particular channel.
Thanks
There is no API / command available to list all the peers which have joined a channel. There is an API on the peer to list all the channels the peer has joined.
There are plans to have a discovery service in a future release which would allow you to discover peers which have joined a channel across organizations (although it would be based on each peer exposing it's endpoint via gossip).

Resources