Deploying Hyperledger Fabric: Planning and considerations

By February 19, 2018

Has your organization been thinking about deploying a blockchain application?

First, let’s go over the basics:

  • A blockchain is a string of transaction records that is secured with cryptography.
  • Blockchains can serve as a distributed ledger in a network of peers.
  • Hyperledger Fabric, often mistakenly used interchangeably with “blockchain,” is actually a blockchain framework implementation.
  • The benefits of blockchain include decentralization, immutability, provenance and finality, which will lead to more business benefits like lower costs, higher efficiency and lower risk.

This post will help you think through what you need to know before you get started with deploying blockchain.

While the business benefits of a new blockchain application are easy to understand, getting from the original concept to a working production system requires some planning. IBM Blockchain Platform in the IBM Cloud is a fully integrated enterprise-ready blockchain platform designed to provide:

  • Accelerated development: Reducing development time with tools leveraging Hyperledger technologies that ensure close alignment between business leaders and developers
  • Democratic governance: Enabling faster activation and ongoing management of your business network policies with collaborative management tools
  • Always-on operations: Meeting the needs of the most demanding use cases and regulated industries with networks that are scalable, highly secure and always on

If you’re considering a production-ready blockchain deployment, there are many other aspects to consider.

Deployment architectures

The Hyperledger Fabric architecture can vary with each deployment. For a test or development environment, you might deploy 2 organizations, 4 peer nodes, 1 certificate authority (CA) and solo orderer. For a more robust deployment architecture, clustered CA and orderer services should be implemented.

High availability and disaster recovery

Hyperledger Fabric network nodes are distributed by nature of the solution itself, and if some of the nodes are lost, when those nodes rejoin the network, they will automatically re-sync all the blocks.

For a production environment, a well-thought-out and tested high availability and disaster recovery plan are necessary.

In a Hyperledger Fabric network, all the nodes should be clustered for availability, and all the block data and certification files should be backed up. Will you use a technology that can relocate a container to another running server? Will you use a technology that could live relocate a running host Linux to another logical partition (LPAR) or machine?

Some basic disaster protection options are:

  • Have some Hyperledger Fabric cluster nodes running at a remote site. All sites are actively processing workload all the time in the configuration.
  • Have storage level replication between two or more sites. One or more of the remote sites would be cold standby.

Monitoring and alerting

Monitoring and alerting of the Hyperledger Fabric network from an operational perspective is another requirement. For the Hyperledger Fabric network itself, the Hyperledger Explorer can be used to interactively monitor the current Hyperledger Fabric.

Is such interactive monitoring adequate, or is a more automated solution required? For host systems and containers, you can use tools such as Prometheus and Grafana to monitor and alert both, but there are many choices available at this level of the infrastructure.

Maintenance strategy

It’s important to have a tested strategy for deploying maintenance updates in your Hyperledger Fabric. How and when you update the container host and fabric images is very important. Production environments can’t just start fresh with a new ledger, throwing away all history when the next level of Fabric code is available. Ask yourself: Can you skip fabric levels and still migrate to the next level? How and when do you deploy new chain code?

Security

Hyperledger Fabric is designed to be secure, but that does not mean your deployment is automatically secure. Improper handling of user IDs, passwords, certificates, keys, role authorizations or file system permissions can leave a system vulnerable. Whether a human mistake or malicious intent, both insider and outsider threats cannot be underestimated. Important questions to consider: Are the data feeds to and from existing systems that the fabric integrates to properly secured? Is the Linux system that’s hosting the environment properly secured and regularly patched with weekly or monthly updates?

Infrastructure matters

Blockchain implementations require not only high security, but also performance, resilience and scalability. IBM LinuxONE delivers the high capacity scale-up and scale-out capability, and provides on-chip cryptographic acceleration with CP Assist for Cryptographic Functions (CPACF), CryptoExpress cards for faster cryptographic operations. With these capabilities, LinuxONE can deliver a secure blockchain network that provides excellent performance and can scale to your needs.

If you have questions about getting started with blockchain on LinuxONE, contact IBM Systems Lab Services today.

1 Print

[autopilot_shortcode]