I'm doing a POC that involves 4 types of entities. All of them will have different types of participants in the network. I have drafted out an architecture that needs validations and considerations that I might be missing out.
Architecture:
Created 4 Orgs on the Fabric. One for each of the entities.
The first org contains 1 CA, 1 Orderer, and 2 Peers.
The other three org contains 1 CA and 2 Peers.
All the Orgs will run on a different host machine.
All the Orgs are on the same channel.
Employ docker swarm to create an overlay and make these containers talk to each other.
Next, setup composer REST server on each of these machines, such that the PeerAdminCard and BusinessAdminCard are logically mapped to its own Org.
Use permissions.acl to control access to the participant's data.
A central server will get the requests from all these Org's client and pass it to the respective composer REST server.
Questions that I have pertaining this one:
Is this feasible to implement or am I missing any crucial point?
If we use docker swarm, then there will be a kind of master-slave communication. Does it break the essence of the blockchain?
There are different interactions happening between the clients and that is the purpose of using a central server. Is there other way to handle this without a central server?
Is the acl file enough to control access to the data? If someone has a physical access to the peer's couchdb, he'll be able to see the other participant's data?
Any guidance or references will be helpful.
Related
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.
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.
I am working on setting up a Business Network for Multiple Organizations (two physical machines).
I did the setup of a business network using Hyperledger Composer Playground and achieved querying, rest-server implementation etc.
I have configured a multi-org (multiple organizations) setup for a single business network in a single cloud server (Reference link used: https://hyperledger.github.io/composer/latest/tutorials/deploy-to-fabric-multi-org). But, as in real scenario, I want to configure a multi-org functionality with two separate cloud servers.
I met with an error like below.
Error: Unable to Communicate with Peers. Peers not found.
Version of Composer : latest
Version of Fabric : V1.0
Thanks in Advance.
If you are using Composer latest (v0.19) then you have to use Fabric v1.1.
If you are Running on 2 servers with 2 IP addresses you need to solve the communications (IP Addressing and Routing) between you client and the servers, and between the containers on each server.
For the client to server you need to manage the addresses in the connection.json files for composer.
For the connectivity between the Peers and other containers the correct solution is to use Kubernetes or Docker Swarm to manage the addressing/routing. It is possible to use the extra_hosts feature of docker-compose for a simple demo but you might be restricted to one peer per org because of port conflicts.
I have completed this tutorial and successfully deployed a business network over what it seems to be a generic hyperledger fabric blockchain.
What i want to do now is to create a new peer in diffenrent machine but connected to the same blockchain. Can't find any information. Any help?
Thank you community!
To deploy hyperledger on a different machine you need to take advantage of docker swarm and overlay network. You can find the guide at
Deploying Hyperledger on Multiple Hosts
for the next question about extending your existing network by adding peers, follow Extending your network
I suggest you start looking at the hyperledger fabric documentation
http://hyperledger-fabric.readthedocs.io/en/latest/
You will need to understand about a hyperledger fabric network topology. There are many things you need to understand in order to understand how to configure a peer correctly and join it to a channel. The build your first network section will take you through creating a fabric network from scratch.
I implemented hyperledger composer tutorial and create a simple business network definition and deploy it on through composer and implement it's rest API's through composer-rest-server. Now I want to add one more peer to it on a different local machine which can access blockchain I created previously, so my question is How can I achieve that a different peer node (another local machine) connected to blockchain I created in the composer tutorial?
you can check the S/Overflow link provided by Ahmed Nasser relating to adding your peer to an existing Fabric network.
Once you have your Fabric network up and running, and all of your network configuration / resolution / docker configuration tested and working, you can come to Composer to define the connection info, such as adding additional peers (and therefore create the requisite business network cards that contain that info).
This single organisation tutorial can give you an idea of what's involved - it builds upon a Fabric network that was already created (a simple, one-peer Fabric blockchain Dev environment) ..see here -> https://hyperledger.github.io/composer/tutorials/deploy-to-fabric-single-org.html
It obviously refers to 'localhost' in this scenario - obviously, you are creating something on an IP network, so you will need IP addresses/ host resolution as appropriate.