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 <jer...@massar.ch> wrote:
> 
> On 20201001, at 07:00, Dirk Hohndel via subsurface 
> <subsurface@subsurface-divelog.org> wrote:
>> 
>>> On Sep 30, 2020, at 8:36 PM, Chirana Gheorghita Eugeniu Theodor 
>>> <off...@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 <jer...@massar.ch> wrote:
> 
> On 20201001, at 10:38, Chirana Gheorghita Eugeniu Theodor 
> <off...@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 <atti...@attilla.nl> wrote:
> 
>> On 1 Oct 2020, at 07:00, Dirk Hohndel via subsurface 
>> <subsurface@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

_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
  • services should be back ... Dirk Hohndel via subsurface
    • Re: services should... Rick Walsh via subsurface
      • Re: services sh... Chirana Gheorghita Eugeniu Theodor via subsurface
        • Re: service... Dirk Hohndel via subsurface
          • Re: ser... Jeroen Massar via subsurface
            • Re... Chirana Gheorghita Eugeniu Theodor via subsurface
              • ... Jeroen Massar via subsurface
            • Re... Dirk Hohndel via subsurface
              • ... Jeroen Massar via subsurface
                • ... Chirana Gheorghita Eugeniu Theodor via subsurface
                • ... Dirk Hohndel via subsurface
                • ... Chirana Gheorghita Eugeniu Theodor via subsurface
                • ... Chirana Gheorghita Eugeniu Theodor via subsurface
                • ... Attilla de Groot via subsurface
                • ... Jeroen Massar via subsurface
                • ... Chirana Gheorghita Eugeniu Theodor via subsurface
          • Re: ser... Attilla de Groot via subsurface

Reply via email to