6.3.2 A Virtual Cluster

6.3.2.1 Setup Virtual Nodes

Deploying a virtual cluster is the easiest way to run multiple nodes within a single virtual server (using Docker technology):

• Deployment of a small network of several nodes for test purposes.

• Designing your own subnet, which is expected to include nodes of different types.

• Development and testing of applied solutions based on the DGT platform.

• The basic steps to initializing a virtual cluster are as follows:

• Prepare the server in accordance with the requirements listed in 6.1 (including setting up the operational system, Docker, Docker Compose, and the necessary instruments). Verify the correctness of the configuration.

• Download the latest version of dgt through the “git clone” command:

git clone https://github.com/DGT-Network/DGT-Matagami

As a result of execution, the DGT-Matagami/CORE directory is formed in the home folder of the user (HOME/DGT), from which the image of the cluster’s servers is built.

• Go to the relevant folder and make sure the files are present:

cd DGT-Matagami
cd CORE

• Go to the CORE/etc directory to set up settings. First, you need to edit the template for creating certificates: etc/certificate.json, by specifying the relevant parameters, including country, region, administrator e-mail and others:

nano certificate.json

• Set up the topology (see 6.7.1):

nano dgt.net.map

You need to pay attention to the lists of nodes within each cluster, as well as the «static_map» parameter, which will define the Seed Bundle (the static core of the network); see 6.7.1:

Figure 121 Net Settings in CORE/etc/dgt.net/map[1]

• Use the «bash upDgtCluster.sh N M» command to sequentially build each of the nodes included in the Seed bundle (if necessary, install the Dashboard for a given node):

bash upDgtCluster.sh -G -SC -CB openssl NumCluster NumNode

Here:

- -G – flag indicates the necessity of creating a genesis-block

- -SC – flag indicates the requirement of having nodes sign transactions

- -CB openssl – indicates the selectable type of cryptography (must be consistent with the network to which the node belongs). Options include openssl or bitcoin

- NumCluster NumNode – cluster number and the node number in the cluster. For the first node, we set “1 1”. The mapping of the number to a notation variant using segments and clusters is reflected in the dgt.net.map file.

For example, to bring up four nodes located in two clusters, we use the following set of commands:

bash upDgtCluster.sh -G -SC -CB openssl 1 1
bash upDgtDashboard.sh -CB openssl
bash upDgtCluster.sh -G -SC -CB openssl 1 2
bash upDgtCluster.sh -G -SC -CB openssl 1 3
bash upDgtCluster.sh -G -SC -CB openssl 2 1

As a result of this set of commands, two clusters with four nodes will be created. To create another configuration, see 6.7.1.

6.3.2.2 Virtual Cluster Evaluation

After deploying a cluster, you need to perform the initial health check.

• Using the API, we poll the available nodes:

curl -v http://[SERVER_IP] :8108/peers

Where SERVER_IP is the address of the virtual machine hosting the nodes. The typical output of the command is shown in the figure below:

Figure 122 Peer List for Virtual Cluster

Note that the nodes have received different ports and URLs:

- tcp://validator-dgt-c1-1:8101 - tcp://validator-dgt-c1-2:8102 - tcp://validator-dgt-c1-3:8103 - tcp://validator-dgt-c2-1:8201

- is not displayed, since the request was made to this node

• Let’s display the complete network topology, indicating the status of each of the nodes:

curl -v “http://[SERVER_IP]:8108/topology

A typical output contains a complete network map, for which the active nodes receive the «node_state: active» status, as well as an indication of the corresponding roles: plink, leader, etc.

Figure 123 Output for topology API endpoint

• Verifying the interaction via console

Each of the running nodes has its own console. This allows for the testing of a scenario where one of the nodes executes commands and then the results are checked through another node.

- Log in to the console of the first node and create some bgt-wallets. Then exit the console:

docker exec -it shell-dgt-c1-1 bash
bgt set wallet_1 1000
bgt set wallet_2 700
exit

- Through the console of another node, we display a list of bgt-wallets:

docker exec -it shell-dgt-c1-3 bash
bgt list

The output should confirm data synchronization between nodes. The output contains commands that display a list of wallets created through the console of another node.

Figure 124 CLI Transaction synchronization test

• Checking node status via Dashboard

If the Dashboard component is installed, checking the status of the nodes can be performed using the browser of the client computer:

🌐 http://[SERVER_IP]:8003/ -> Nodes

Figure 125. Active nodes are reflected in the Nodes tab of the Dashboard

• Querying the API of each of the nodes allows for finer testing of transaction execution.

By default, each of the nodes is associated with its own API service that executes the appropriate commands (endpoints). If a virtual cluster is launched, the corresponding IP servers have the same [SERVER_IP], however, they use different ports, the correspondence of which to a given node is determined by the file. The default ports ([API] parameter) are as follows:

- Cluster 1 Node 1: 8108

- Cluster 1 Node 2: 8109

- Cluster 1 Node 3: 8110

- Cluster 2 Node 1: 8208

To check using the API, execute the command to display a list of bgt- wallets for the first node, change the amount on the first one by using the “inc” increasing command, then check the balance through an API of another node. We call the API from the client system using the curl utility.

We display the status of bgt-wallets on the first node and make an increase (we use the previously created test wallets wallet_1 and wallet_2; if they are not available, you must also execute the commands to create them (see 7.1.9.2):

curl "[SERVER_IP]:8108/run?family=bgt&url=tcp%3A%2F%2Fvalidator-dgt-c1-1%3A8101&cmd=list"
curl "[SERVER_IP]:8108/run?family=bgt&url=tcp%3A%2F%2Fvalidator-dgt-c1-1%3A8101&cmd=inc&wallet=wallet_1&amount=100"

We check the received amount through another node:

curl "[SERVER_IP]:8208/run?family=bgt&url=tcp%3A%2F%2Fvalidator-dgt-c2-1%3A8201&cmd=list"

Expected result: even though the command was sent to the node in the second cluster, the data is synchronized, and the correct amount was displayed for the first wallet.