services should be back up - power outage

Dirk Hohndel dirk at hohndel.org
Thu Oct 1 09:23:11 PDT 2020


So many good and kind responses to that post... I'll try to reply this in one message, so scroll down :-)

> On Oct 1, 2020, at 12:15 AM, Jeroen Massar <jeroen at massar.ch> wrote:
> 
> On 20201001, at 07:00, Dirk Hohndel via subsurface <subsurface at subsurface-divelog.org> wrote:
>> 
>>> On Sep 30, 2020, at 8:36 PM, Chirana Gheorghita Eugeniu Theodor <office at adaptcom.ro> wrote:
>>> 
>>> What would be needed to have a secondary server in a new location? what setup are we talking about? 
>> 
>> It’s actually rather difficult to load-balance this without adding a ton (and I mean a TON) of infrastructure that I’m not really interested in maintaining. I have spent a bit of time trying to figure out if there’s a way to cheat and not need a storage engine, but if there is, I haven’t found any pointers on how to do this.
> 
> Do you have a mini description of the server side setup (code/fs/db)? Is it Git based?

It's a Ubuntu VM with a couple of small helper apps that I have hacked together, git as storage, apache for the web connection, mysql as the authentication database.
The code is terrifyingly bad (as I said, I wrote it), but it seems to work reasonably well as long as the power stays up.

>> I do have a way to do a hot standby, I may have deleted that hot standby from AWS because I was ticked off about the money they charged me for it - when it never once got used. And this still had the problem with figuring out how to implement the traffic distribution without incurring even more AWS fees.
> 
> Active/standy should be fine for this purpose.

That's what I have indeed. Only right now (because I'm stupid) the standby is on a different machine in the same room. So not really useful as standby :-)

> Just rsync/git-pull the stuff over, so that if the primary dies, that you can switch over manually.

I actually use some simple git hooks to completely automate that. The system is actively keeping its standby in sync, and the standby does the same with the live system if it were to become the live system. So yes, one could switch between them.
BUT - you can't switch in the middle of a transaction, and there's of course a short delay, so a simple web round-robin style handoff creates a mess.
Additionally, I have not thought through the solution to the authentication problem. That mysql database also runs on a VM in that same room - and making that be redundant and consistent... that's usually when I decide that this isn't a life-and-death critical system and go back to doing something else :-)

> Split-brain is the biggest issue in these kind of setups.

With the way git works, as long as you don't switch in the middle of a transaction it's actually fairly resilient. But still, I'm sure I'm missing subtle issues that could go wrong.
As a simple backup solution this has worked well. We did have a catastrophic outage a while ago (as I'm sure some of you will remember) and switching to the standby caused only new users that created an account in a relatively small window a problem (and that was not a hot standby issue, that was a "me" issue where I had one script set up subtly differently between the two systems).

> The fun detail is that basement servers are typically the most stable (except for the connectivity possibly), and if something breaks one can actually walk to that "datacenter" easily, often much quicker to fix too if one needs spare parts etc. And with cheap-ish power, and free cooling / colder environment (we got first snow at 1200m) it is price-wise cheaper than a colo'd box.

yes. That's why I am exiting the colo I was in in favor of my basement.

> That said though, I use private colo'd servers (because of home connectivity not always being superb and could not get more than slow cable speeds and upload at home still is slow), if you need a secondary/third VM somewhere on a static IP (colo'd), don't hesitate to yell, more than happy to donate one for Subsurface (and I am sure others here can do the same; it is always funny the names you see on this list ;) ).

Symmetrical Gb/s plus backup 200Mb/s on a different provider. Great UPS setup (cough, cough), soon a solar setup plus Tesla PowerWall to take the UPS setup to the ridiculous level :-)

> Also, the expertise + time for doing a full active-active version if one wants to go in that direction, I have setup my share of those systems.
> 
> But as you say,.... if it is 99.8% running, meh, is not life critical. Long live git.

That. Exactly that.

>>> To conserve money, much of the infrastructure is actually running in my basement.
>>> All of course on a UPS, with redundant internet connection, etc.
>>> 
>>> Power went out today. And my UPS failed.
>>> I've always wondered what that U in UPS actually stands for.
>> 
>> Oh, speaking of saving money… yeah, I bought a new UPS. Oh, and one of my little NUCs needed a bigger NVMe M.2 SSD.
>> So maybe I really don’t understand how to save money :-)
> 
> Sounds like a still cheap rabbit hole to me ;)


Oh definitely. And that's why I shouldn't even whine and complain - none of this is a hardship. I just like to whine. All of this really is banter, not complaint.

> On Oct 1, 2020, at 1:45 AM, Jeroen Massar <jeroen at massar.ch> wrote:
> 
> On 20201001, at 10:38, Chirana Gheorghita Eugeniu Theodor <office at adaptcom.ro> wrote:
>> 
>> Peacemaker and corosync?
> 
> There are hundreds of options to achieve these kind of goals, but without knowing the type of data that one wants to synchronise and how they are updated.... and how locking works and how much latency there is between nodes (same datacenter/rack/country/continent?) and..... many factors, I would not suggest a single one before hand...
> 
> Mid-write syncs & disconnects are bad after-all.

Yes, that's the reason why I do this in a push hook. So the sync happens synchronously once we have a known good state. But that's the problem why I can't just do round robin IP balancing between two servers. Because I need the full transaction to complete with a single backend. 
I'm sure all this could be designed differently. :-)

> On Oct 1, 2020, at 5:57 AM, Attilla de Groot <attilla at attilla.nl> wrote:
> 
>> On 1 Oct 2020, at 07:00, Dirk Hohndel via subsurface <subsurface at subsurface-divelog.org> wrote:
>> 
>> The beauty of the current situation is that outside the (grumble, grumble) hours that I spend on this
> 
> How / where can we do an anti-grumble, pro-infrastructure donation?


Thank you. I got a lot of generous offers of donations and support. I really appreciate them. But I have a simple rule. I never take money for the work on Subsurface that I do. That makes things so much simpler. And my day job does cover my basic and not so basic needs.


All of you: thank you. What a nice thread to wake up to. This community is what really makes it worth investing in Subsurface. Be it time or money.

/D



More information about the subsurface mailing list