Designing Scalable Blockchain Networking Topology in Azure


Considerations for Designing Scalable Blockchain Networks using Virtual Network Peering in Azure

One Azure customer asked us for help creating a mesh network topology to support a Blockchain consortium. Blockchains are distributed transactional systems that allow assets and investments to be exchanged based on smart contracts and predefined ledgers. In this scenario, four business partners wanted to start a Société Anonyme (SA), an anonymous corporation to serve as the basis of their Blockchain consortium. For Blockchain applications to run across the member’s digital assets, a mesh network topology provides connectivity between all virtual networks in one consortium as Figure 1 shows.

A mesh topology can be used to support a blockchain consortium on Azure as long as the number of members is very small.

A mesh topology can be used to support a blockchain consortium on Azure as long as the number of members is very small.

With four members, a mesh network requires three peering links per virtual network for a total of 12 links. With appropriate permissions, the members can peer virtual networks that exist in two different Azure Active Directory tenants. The ability to set up peering links across Azure regions is in preview, so the consortium could theoretically support global membership.

The consortium also plans to expand to more than 15 members, each with their own virtual network. When fully deployed, 14 peering links are needed per virtual network for a total of 105 links, but that might quickly exceed the Azure defaults as the number of members grow. The real challenge arises when the planned expansion scales to 50+ members, requiring more than 1200+ links to establish a mesh network between them.

Virtual network chaining: hub and spoke

In our recently published whitepaper on Mesh and Hub-and-Spoke network architectures in Azure (http://aka.ms/HubAndSpoke), we showcase how to build mesh networks connectivity using Hub-and-Spoke network architecture without being constraints with the number of VNet peering limits.

At 50+ members in the Blockchain consortium, it is when the virtual network chaining can provide an alternative architecture to support the new scale. This network topology is also known as hub and spoke. This topology connects groups of virtual networks to a hub virtual network, which then connects to other hub virtual networks like links in a chain. This can provide an alternative architecture that enables a larger number of virtual networks to be connected, beyond what the traditional mesh network architecture can today achieve with the virtual networking peering limitations. 

In this model, it’s easy to add and remove spokes without affecting the rest of the network, giving business units great flexibility within their environments. This topology supports centralized monitoring and management. In addition, hubs aggregate connections so you’re less likely to encounter the peering link limit. Azure also provides many ways to control network traffic using network security groups that specify rules to allow or deny traffic and user-defined routes that control the routing of packets.

This topology does, however, introduce a few tradeoffs. The hubs can become a potential single-point of failure—if one hub goes down for any reason, it breaks the chain. In addition, when communication between virtual networks travels through two or more hubs, the custom route tables and network virtual appliances (NVAs) can cause higher latency. The cost of these resources can add up, too, while the combination of traffic rules and peering links can make deployments challenging to deploy and manage. For implementation details, see Implement a hub-spoke network topology in Azure.

In this published whitepaper on Mesh and hub-and-spoke networks on Azure, we have outlined some of the trade-offs between hub-and-spoke network topology and mesh networks in Azure. Additionally, we have also provided more insights into controlling access of the various VNets through policy and role-based access.

We hope you find this article and that whitepaper useful.

Comments (3)

  1. This is quite interesting. What are the major pros for this versus, let’s just say, taking super huge VM’s as network virtual appliances using something like SecureSwan on Linux images, and doing large numbers of multisite gateway connections as a hub and spoke model? Seems like you would have to worry about less links and a way cheaper price for gateways.. Thoughts?

    1. Lamia Youseff says:

      Hi Eric, Thanks for your comment. The VNA (Virtual network appliances) approach can surely provide a valid implementation for a hub and spoke architecture, but I don’t agree with you that the cost of VNA will be more effective than the VNet peering. We kept the discussion in this article and paper to the architecture level, but that other article covers in more depth on the implementation details (https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke). Hope this helps.

Skip to main content