Controlled downtime in v3 beta?

[direktorn]

First time poster. Just got my invitation on Friday and have setup my first 10TB node with dual ISP (1000/1000 and 500/100) on my SAS SAN.

I’m trying to understand how the uptime disqualification works, if at all as it seems it’s been discussed over time?

I’m normally do maintenance from time to time. I’m planning UPS work for example and that will lead to downtime for a few hours. Is this relevant during the beta?

Also I’m trying to figure out if having multiple A records for the FQDN of my node has any impact what so ever on redundancy for a dual ISP setup? Not currently running BGP so all routing is statically done…

Thanks
//Anders

[Alexey]

Hello @direktorn,
Welcome to the forum!
The disqualification for downtime is currently disabled while it’s rearchitecting:

Design draft: New way to measure SN uptimes

Hi everyone, Our initial attempt to calculate SNs reputations using based on audits and uptime reputation didn’t work out as we thought, for such reason, we disabled the disqualification due to uptime failures as it was the one which caused to disqualify several nodes without being clear how long they were offline. We need to enable back the uptime reputation calculation of the SNs and disqualify those ones which aren’t online long enough for keeping our network healthy, for such reason we are…

The support of planned downtime is not implemented yet. You can add your idea or vote for existing one on the Ideas portal

Also, you can take a look on a similar tag: Topics tagged downtime

[nerdatwork]

Congratulations!! on becoming a SNO.

If you want you can show off your Storj rig here

[Krey]

@direktorn

Also I’m trying to figure out if having multiple A records for the FQDN of my node has any impact what so ever on redundancy for a dual ISP setup?

I asked this question many times and did not receive a clear answer.
Most likely, if one provider breaks, half of the connections to you will not be successful. This is standard behavior for network appplications that have no fault tolerance.

Anyway if you have free disk space It’s much more profitable to run the second node on the second channel

[direktorn]

Thanks for your response.
Yes as round-robin might be applicable some of my traffic will go down. I doubt it will be 50% as this is strongly controlled by the inconsistency of how round robin works, or not works…

Also, depending on how the method works for re-establishing a connection it might be that 100% of the connections attempts would go to the IP adress, if no additional DNS lookup will take place, in fact even if a lockup is being made, and the returned A record belongs to the failed ISP my storage node will still be seen as offline.

Currently my FQDN is a dynDNS record and it will automatically change in the event of my primary ISP going down as my default route will change, but its not automatic, I rather do it manually as these events are really rare and I have a fixed IP on my primary ISP.

It’s just important to understand how/if redundancy might work.

[jeremyfritzen]

Hi all!

Just a question: is qualification still deactivated for failed uptime checks?
If not, what is the downtime threshold?

I’m asking this question because I added a new virtual disk to my Storj VM and, due to an error in my config, the process takes very very long time (settings have been modified more than 3 hours and it did only 27%…).

Thank you all for your help!

[nerdatwork]

@jeremyfritzen

is qualification still deactivated for failed uptime checks

DISqualification due to low uptime is currently disabled. Keep your node online and it will recover from it.