Ah, interesting that they’re managing rollout at the app level Thanks for sharing.
Thanks.
I have a question about the unit service file. The first commented lines say:
Ensure that the Storage Node binary is in /usr/local/bin and is named storagenode (or edit the ExecStart line below to reflect the name and location of your binary
And the ExecStart line refers to "/var/lib/storagenode/storagenode run --config-dir "/etc/storagenode". Are you sure this is not an error? Shouldn’t it be "/usr/local/bin as stated in the first commented lines?
Thanks for your insight 
I believe there config is used as an example you can change the location of you don’t have to run it exactly as they have it.
You just need to have the service file in the correct location. It says (or edit the ExecStart line # below to reflect the name and location of your binary
I didnt follow any of the locations I put the files where I wanted them to be then changed the config to run from that location, Then I enabled the service to run and everything ran completely fine.
1 Like
OK, now that my 2 services are set up, I can give you a first feedback
Just some information about my test configuration:
- I’m on a Debian VM (1 vCPU ; 2 GB RAM).
- I set up a node with 600 GB. The storage node seems to work well.
The storagenode-updater service gives me the following logs:
INFO Configuration loaded {"Location": "/home/jeremy/.local/share/storj/storagenode/config.yaml"}
INFO Running on version {"version": "v1.15.3"}
INFO Downloading versions. {"Server Address": "https://version.storj.io"}
INFO New version is being rolled out but hasn't made it to this node yet {"Service": "storagenode"}
INFO New version is being rolled out but hasn't made it to this node yet {"Service": "storagenode-updater"}
So I suppose everything is working well so far. I am waiting for the roll-out to be processed.
One comment though: I had to set the log.encoding parameter in the storagenode config.yaml file (I suppose this is absolutely normal but I prefer to tell you ).
Do you know how long should I have to wait for the roll-out to be processed?
1 Like
What do you mean exactly?
Not sure if I’m using the right terminology, but the lines from your storagenode-updater service are what I’m referring to:
I’m contrasting that with the Docker method where the roll-out methodology was just based on a randomized interval for watchtower checking Docker hub for updates, when in reality, you could manually pull the new container image as soon as it’s up on Docker hub.
1 Like
The problem with that is that we would have no control over the rollout. Most of the storage nodes would update in 5 minutes even if we ask everyone to slowly updater over 3 days. That comes with a risk. We might rollout a bug and if too many storage nodes are installing it we are screwed. Our current rollout process gives us more control. If we discover a bug we can pause the rollout, create a point release, rollout the fix on the same set of storage nodes, repeat it if needed and finally continue with the rollout.
2 Likes
For sure, I agree with this compared to the hacky watchtower method. Good to see that it’s built-in to the app directly now.
1 Like
Hi there!
Im new here.
Running a production node already, with the same setup, but with docker.
And just started a Testnode with updater Service. As described here.
Had to be a little sketchy with configs and setup but works now.
Running on Xen-Virtualized Debian 9 running completely off of an Remote Nas over 40gbit Infiniband Connection. (OS and Storage)
Update: My test node updated perfectly with no hiccups.
1 Like
My Storagenode also Updated without any Problems.
Hey guys, I moved house a couple of months ago and since i wasn’t moving straight into my new place, I ran a graceful exit on 10 of my nodes so need to start again now I’ve got all sorted.
Since i’ll be setting these up from fresh, on my Ordoid HC2 machines I thought I could set them up with the native linux install and avoid docker. I also thought this would be a great opportunity to redo my Odroid HC2 setup tutorial video with the linux package.
Before I decide which way to go, I was hoping you could answer the following…
1 - Is the native linux install likely to use less system resources since it won’t have the docker overhead? (RAM is limited to 2GB on HC2 so if it does save a bit id rather wait for linux package)
2 - I’d rather set them up with the native linux installer when it’s ready without having to setup services manually, especially when taking the time to redo the setup videos. Any idea when this will be available? Are we talking weeks or months?
Cheers!
3 Likes
My 7TB node uses 40MB of RAM. Not sure that’s going to get a lot better. But if you don’t use any docker on the HC2, then you will surely use less RAM overall.
1 Like
Cheers, @kevink i suspect it’s not using a lot of RAM at the moment because it’s not fully vetted or under any load though, but appreciate the info. Will assume this means its also super low on resource consumption too.
Well my node is 20 months old and I never saw a higher RAM usage than 200MB iirc. But it might heavily depend on the network load. And as the network is currently rather idle…
However, the difference between using docker and native shouldn’t be that big. RAM consumption will rise in either scenario if the load goes up.
3 Likes
I’ve discovered that drive speed plays a major role in ram consumption. Fast drives with good IO should need less ram (they dump the data to disk faster, so don’t need as large of a buffer). This is most noticable for me on a SMR drive after restarting a node and the filewalker runs (even more so if you say, run a defrag at the same time), if we have a large network surge my ram usage balloons (I have broken 1.2GB on my node during the most non ideal conditions with the default setup; naturally, if you increase your buffer size to improve SMR performance this number will grow faster).
Containers are designed to be very light weight, and actually link into the host kernel (Stack Overflow). This means that their overhead is very low when the code is done right. You may save some overhead with a native install, but it will likely be significantly less than you are expecting (Stack Overflow). Most slow downs will likely come from frequently spinning up and down containers, if you leave them up it shouldn’t be an issue for most folks (unless you run it on Windows; as if I recall correctly, running a Linux docker imagine spins up a light Linux VM to then run the containers (WSL might help this some?)).
The one thing to be aware of with docker is the potential for root breakout since the docker service runs as a root daemon (this is one of the main reasons for Red Hat’s recent work on podman, I’m not sure how that one performs currently).
2 Likes
I’m too unfamiliar with manual services, but I have a spare RPi4 and HDD that I can spin up when the installer or docker container are ready!
1 Like
@will.topping, I just got 8x Odroid HC2 units and watched your setup video to get them going. I’ve got two of them set up, one using the Docker setup and the other using the Linux binaries directly. I’m not sure there’s a huge difference in resource usage. The Docker Odroid is currently using 395MiB RAM while the non-Docker Odroid is using 247MiB. I wrote up a guide that was split off from this thread for setting up the Linux binaries + systemd services. I think the complexity is pretty similar to the Docker-based installation so it should be pretty painless to get it going.
3 Likes
Are the ARM binaries monolithic, or do they require OS libs? My Storj drives are on a QNAP NAS which has a cut-down Linux and can’t run Docker. I have never succeeded in getting non-QNAP binaries to run, because they all require libs the NAS doesn’t have. Because of this the SN runs on a Windows PC, accessing the drives via iSCSI.
If the binaries need libs then there is no point in me trying them.
I ran it on my nas without installing anything ontop so to answer your question No you do not need to install libs. You should be able to run it no problem if you can SSH into the Nas.