Setting Up 2 Sentries and a Validator in the Same Server in BitCanna (Cosmos Network)
We’ve been participating lately in the BitCanna Network public testnet phase 2. In that phase we’ve been playing around with different server setups and configurations to see possibilities that could fit best for some scenarios.
One of these setups tests was to set a validator and several sentry nodes (common architecture in Cosmos networks and useful to mitigate DDoS attacks) in the same server using Virtual Private Servers. BitCanna and us believe that this kind of setup could help other people trying to achieve the same, so that’s why we’re publishing this guide.
DISCLAIMER: this is just a testnet infrastructure use case, this guide is not aimed for a mainnet setup. We encourage to DYOR and implement best security and infrastructure practices for your mainnet/production setup.
Requirements
First of all is to have a bare metal server running a virtualization software such as QEmu, ProxMox or VM Ware, that will act as the host server running the guest VM’s that will run the actual BitCanna’s blockchain nodes.
Guest VM’s
In this scenario, we’ve set up 3 VM’s running Ubuntu Server 20, so you may need to tweak some commands a bit depending on your Linux distro.
- 1 validator node
- 2 sentry nodes (you can set as many as you desire)
Creating BitCanna nodes
This is out of the scope of this guide, for a quite polished and accurate documentation on how to do this please visit BitCanna’s official docs.
Useful Tip: to sync your nodes in 5 minutes or less, you can use this State Sync Script made by the BitCanna team.
The first thing is setting up, syncing and creating the validator node in a VM (refer to the official docs for thi).
The following thing would be setting up and syncing the two VM’s, but if those VM’s are running on the same host machine as the validator, won’t be able to make a P2P connection to the network persistent seed nodes, because the sentry VM’s and the validator VM are sharing the same external network IP (only one host can connect with the same IP).
Configuring the nodes
One solution we came up to, was setting the connections of the 3 nodes between them, in the following way:
- set the sentry nodes persistent peers to point to the validator node
- set the validator node persistent peers to point to the sentry nodes
- set pex to false in the validator to hide it from the public network
- set pex to true in the sentries to expose them to the public network and act as proxies for the validator
Let’s look into the real configuration:
Supposing that the VM’s have the following ips and tendermint node id’s (node_id@ip_address)
- Validator: 47a763c7c542db370f0a7e380d355f89c6f1115b@192.168.1.105
- Sentry 1: 5ff5bea2e39a9497a628dec093bac6bcc3d18b47@192.168.1.106
- Sentry 2: 8d03c8d1c570ceb7622d205f12ae7e066ee6d995@192.168.1.107
Validator configuration
192.168.1.105:~/.bcna/config/config.toml
seeds = “”
persistent_peers = “5ff5bea2e39a9497a628dec093bac6bcc3d18b47@192.168.1.106:26656,8d03c8d1c570ceb7622d205f12ae7e066ee6d995@192.168.1.107:26656”
addr_book_strict = true
pex = falseSentry 1 configuration
192.168.1.106:~/.bcna/config/config.toml
seeds = “”
persistent_peers = “47a763c7c542db370f0a7e380d355f89c6f1115b@192.168.1.105:26656”
addr_book_strict = false
pex = trueSentry 2 configuration
192.168.1.107:~/.bcna/config/config.toml
seeds = “”
persistent_peers = “47a763c7c542db370f0a7e380d355f89c6f1115b@192.168.1.105:26656”
addr_book_strict = false
pex = true
Once configured, restart all the nodes and every of them should be able to get in sync with the network, as shown in the screenshot below.
sudo systemctl restart bcna.service
And that’s all! Hope this guide has been useful for you, and if you come to other solutions please share it with other validators in the BitCanna’s validator Discord channel.
For more info about this cool project don’t hesitate to visit their site.
Happy 420 blocks guys!!!