Experiment: installing Nginx on a Ubuntu 22.04 server with almost 200 masternodes

HelmutsHelmuts is verified member.

Domain Summit | HostMaria
Staff member
Joined
Dec 23, 2022
Messages
678
Reaction score
0
I am doing an experiment, and for this reason have a server with almost 200 $Maria masternodes (on ipv6)

** Note: I will make a post in tutorials on how this can be done.


yes, that is *** of mns :D :D .. and yes, most mn owners are informed of my experiment.

tech specs:
CPU: Intel Xeon-E 2136 - 6c/12t - 3.3 GHz/4.5 GHz
RAM: 64 GB ECC 2666 MHz
Data disks: 2×4 TB HDD SATA
OS: Ubuntu Server 22.04 LTS "Jammy Jellyfish"
Swap: 20Gb

--

The issue is: the set-up masternodes keep going missing randomly after 3-4 days of being Enabled. .. and it didn't seem to be the case when the server has 100 masternodes on it.

--

I have to admit that the 64 GB ram limit was met at around 100-120 masternodes. .. and I kept pushing :)

--

ok, let me open the server and check processor, swap and memory status:
Code:
htop

The visually displayed information is quite clear: there are lots of processor resources left // and both RAM and SWAP are full/overloaded.

nAxaDP9.png


---------------------------

So, I have this idea on installing Nginx and see will it reduce the usage of RAM.

The theory of potential benefits of using Nginx with a masternode server:
[list type=decimal]
[*]Load balancing: Nginx can be used to distribute incoming traffic across multiple $Maria masternodes, which can help to improve the overall performance of the network.
[*]Caching: Nginx can cache frequently accessed content, such as $Maria block data or API responses, reducing the number of requests that need to be processed by the node.
[*]Improved stability: Nginx can act as a reverse proxy for the $Maria masternode software, which can help to isolate the software from potential security vulnerabilities or system crashes.
[*]Improved security: Nginx includes several security features, such as rate limiting and SSL/TLS encryption, which can help to protect the $Maria masternode software from potential attacks.
[/list]

 
making this thread that anybody can correct me, if I'm wrong at some point.

my setup process:

switching over as admin (now I will be not required to start commands with 'sudo':
Code:
sudo su

The usual, updating the package list and upgrading the installed packages:
Code:
apt update
apt upgrade

Next, installing Nginx:
Code:
apt install nginx

The process has started:
0nX8PtJ.png


.. complete

quick test if Nginx is running shows all is fine:
Code:
nginx -t

screenshot:
VKuaDEv.png


=============

running a quick 'htop' to see if anything has changed shows nothing:
ViR5VJT.png


**********************

now, this part is over..
 
and now to the next step: configuring Nginx to act as a reverse proxy for each $Maria masternode

*******
one more time: do you see me doing something stupid? :) just let me know here in the comments), tx
*******

The task is to configure Nginx to act as a reverse proxy for each $Maria masternode.

Theoretically this can be done by creating a new server block in the Nginx configuration file for each masternode.

For example, to configure Nginx to act as a reverse proxy for a MARIA masternode running on port 11111, you can create a new server block in the /etc/nginx/sites-available/default file with the following configuration:

1. opening nginx configuration file
Code:
sudo nano /etc/nginx/sites-available/default

2. Adding the following server blocks to the end of the file, replacing example.com with my server's IP:
Code:
server {
    listen 80;
    location / {
        proxy_pass http://localhost:11111;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Note: I will replace example.com with my server's IP address, and 11111 with the port number used by the masternode.

---

and here is the same last part with 5 ports:
Code:
server {
    listen 80;
    location /masternode1/ {
        proxy_pass http://localhost:11111/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    location /masternode2/ {
        proxy_pass http://localhost:11112/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    location /masternode3/ {
        proxy_pass http://localhost:11113/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    location /masternode4/ {
        proxy_pass http://localhost:11114/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    location /masternode5/ {
        proxy_pass http://localhost:11115/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

again a test:
Code:
nginx -t

If you want Nginx to start automatically on boot, enable it with the following command:
Code:
sudo systemctl enable nginx

If you have a firewall enabled, allow incoming traffic on port 80, which is the default port for HTTP traffic:
Code:
sudo ufw allow 'Nginx HTTP'

and, if the configuration test is successful, should reload Nginx using the following command:
Code:
systemctl reload nginx

... will take a short break and off to this task :) .. theory is 1 thing, now it is time to test it in practice

the-simpsons-homer-simpson.gif
 
with some issues and changes.. done

will see how it goes.

--

I would love to increase the swap or add additional swap file > the system is so busy that kills any attempts to do this..

will continue another day.

gn
 
Another thing one can do is to release the memory page cache with this command.

echo 3 | sudo tee /proc/sys/vm/drop_caches


drop_caches

Writing this will cause the kernel to delete clean caches, as well as renameable slab objects (such as dentries and inodes). Once dropped, their memory becomes free

To release the pagecache: echo 1> / proc / sys / vm / drop_caches To release recyclable slab objects (including dentries and inodes): echo 2> / proc / sys / vm / drop_caches To release the slab objects and pagecache: echo 3> / proc / SYS / VM / drop_caches

This is a non-destructive operation that does not release any dirty objects. To increase the number of objects released by this operation, the user can run `sync' before writing to / proc / sys / vm / drop_caches. This will minimize the number of dirty objects on the system and create more candidate objects to be deleted.

sudo swapoff -a will disable swapping and the kernel will automatically terminate the process with the highest score if the system is running low on memory. I use this if I know I'll be running something RAM heavy and if it gets out of control I'd rather kill it than let it go into swap and get stuck forever. Afterwards use sudo swapon -a to re-enable it.

Later, you may need to check the swap settings. It sounds like your swap is on the same disk as the root partition, which will slow down your system when you hit swap, so avoid doing that if you can. Also, in my opinion, modern systems are usually configured with too many swaps. 32GiB RAM usually means 32GiB swap allocated by default, as if you really wanted to put 32GiB into the swap space.

 
Back
Top