<div dir="auto">Yep you are right.<div dir="auto">Than a more complex solution is needed with costs kept as low as possible</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 1, 2020, 23:59 Jeroen Massar via subsurface <<a href="mailto:subsurface@subsurface-divelog.org">subsurface@subsurface-divelog.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On 20201001, at 22:08, Attilla de Groot <<a href="mailto:attilla@attilla.nl" target="_blank" rel="noreferrer">attilla@attilla.nl</a>> wrote:<br>
> <br>
> I’m not familiar with all the details, but an F5 is probably an overkill and you can acomplish the same thing with quite a simple nginx setup. ;-)<br>
<br>
BIG-IP is indeed effectively an old Red-Hat, with Apache, Zebra (not even Quagga) and some other bits and pieces and a big API and UI around it.<br>
The good old hardware boxes with SSL accelerator cards where quite cool, but we have modern software and hardware-accelerated crypto in CPUs nowadays, which is exactly what the 'virtual' version does.<br>
<br>
<br>
As you say, you can just use F5's nginx (yes, they bought that) if you want load-balancing and whatever BGP daemon if you want to go there.<br>
<br>
Using a proprietary box like that for a open source project is also odd, especially as it runs mostly on open software that is an apt-get and ansible/puppet/choose-your-poison away.<br>
<br>
And as I understand Dirk is just using a NUC at the moment, if that is not sufficient, upgrading that single box is much much easier than using an overloaded VM for little gain...<br>
<br>
<br>
<br>
Also BIG-IP does not solve data sync between an active/passive host which is an actual concern from what I understand (can be off there ;) .<br>
<br>
Greets,<br>
 Jeroen<br>
<br>
<br>
>> On 1 Oct 2020, at 21:51, Chirana Gheorghita Eugeniu Theodor <<a href="mailto:office@adaptcom.ro" target="_blank" rel="noreferrer">office@adaptcom.ro</a>> wrote:<br>
>> <br>
>> This can solve the issue of transaction loss if a switch from active to standby ocures. But I think there are also some open source variants of the F5<br>
>> <br>
>> On Thu, Oct 1, 2020, 22:49 Chirana Gheorghita Eugeniu Theodor <<a href="mailto:office@adaptcom.ro" target="_blank" rel="noreferrer">office@adaptcom.ro</a>> wrote:<br>
>> The virtual version of the F5 bigip load balacer. The vm can be run in any virtial enviroment.<br>
>> <br>
>> On Thu, Oct 1, 2020, 22:06 Dirk Hohndel <<a href="mailto:dirk@hohndel.org" target="_blank" rel="noreferrer">dirk@hohndel.org</a>> wrote:<br>
>> <br>
>> <br>
>>> On Oct 1, 2020, at 11:23 AM, Chirana Gheorghita Eugeniu Theodor  wrote:<br>
>>> <br>
>>> Or we could sponsor a F5 bigip virtual appliance and that should solve the load balancing. Correct me if I am wrong.<br>
>> <br>
>> I don't even know what that is :-)<br>
>> <br>
>> /D<br>
> <br>
<br>
_______________________________________________<br>
subsurface mailing list<br>
<a href="mailto:subsurface@subsurface-divelog.org" target="_blank" rel="noreferrer">subsurface@subsurface-divelog.org</a><br>
<a href="http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface" rel="noreferrer noreferrer" target="_blank">http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface</a><br>
</blockquote></div>