No subject
Mon Sep 16 11:23:08 CEST 2019
L<br>
databases as the main backend and leave etcd as an option.<br>
<br>
> 3. According previous questions, what's preferred for large<br>
> deployments? etcd or sql?<br>
<br>
The most powerful, robust and maintainable option would be a centralized<br=
>
database cluster. For most customers, I would recommend the PostgreSQL<br>
database for such installations.<br>
<br>
<br>
I'll add some background to shed some light on the development effort<b=
r>
behind LINSTOR:<br>
<br>
I have to admit that LINSTOR is a bit of an alien in its environment.<br>
And that was actually done on purpose. When I created the initial design<br=
>
for LINSTOR in 2016, our background at LINBIT was the reliability,<br>
robustness, scalability and maintainability nightmare that we had gone<br>
through with drbdmanage, which was LINSTOR's predecessor (when LINSTOR<=
br>
development started, the project was actually still called "drbdmanage=
<br>
next generation" internally). Drbdmanage was built around its typical<=
br>
environment, some Linux server with DRBD installed, with D-Bus as an IPC<br=
>
protocol, a filesystem with config files, a Python interpreter, simple<br>
JSON documents for persistence. It turned out to be way too limited to<br>
continue developing it.<br>
<br>
Most of the ideas behind LINSTOR were the result of ignoring all the<br>
conventions, traditions and half-baked solutions that existed already in<br=
>
those typical environments, and instead asking the question: What would<br>
be the theoretical ideal solution in a perfect world, and then, how<br>
close can one get to something like that within real-world limits -<br>
limited developer time, money, limited hard- and software environments, etc=
.<br>
<br>
That is why it was built around a full-blown SQL database, why it<br>
originally used its own communication protocol for IPC, why all the<br>
object names are different from drbdmanage's, why it doesn't have<b=
r>
drbdmanage's "--force" flags, why it writes its own error rep=
ort files<br>
in addition to using syslog, and that is also why it is so different<br>
from its environment. I did not originally design LINSTOR to work or to<br>
look like a typical Unix/Linux application, or to use whatever the most<br>
widespread or most convenient protocol or data format is, or to e.g.<br>
have a single simple numeric return code as most usual applications do.<br>
Instead, my intention was to make the design more robust, more<br>
consistent, more maintainable and also more scalable by avoiding many of<br=
>
the weaknesses found in more conventional technology.<br>
<br>
The introduction of etcd as an option, the replacement of the binary API<br=
>
with a REST webserver, the use of DRBD quorum instead of fencing in<br>
cloud environments, the presence of configuration files instead of<br>
configuration utilities, all those things were adjustments made to fit<br>
certain limitations, not because those solutions are technically better.<br=
>
They aren't, they are just what either the rest of the technology aroun=
d<br>
LINSTOR or the users can deal with more easily.<br>
<br>
In the real world, it's always a compromise.<br>
<br>
As you can see, I could probably write an entire book about it all, but<br>
I'll stop here for now.<br>
Anyhow, I hope I could provide some insight into what the challenges and<br=
>
ideas behind the development of LINSTOR are.<br>
<br>
br,<br>
Robert<br>
<br>
_______________________________________________<br>
Star us on GITHUB: <a href=3D"https://github.com/LINBIT" rel=3D"noreferrer"=
target=3D"_blank">https://github.com/LINBIT</a><br>
drbd-user mailing list<br>
<a href=3D"mailto:drbd-user at lists.linbit.com" target=3D"_blank">drbd-user at l=
ists.linbit.com</a><br>
<a href=3D"https://lists.linbit.com/mailman/listinfo/drbd-user" rel=3D"nore=
ferrer" target=3D"_blank">https://lists.linbit.com/mailman/listinfo/drbd-us=
er</a><br>
</blockquote></div>
--000000000000ab879c0592bd9b53--
More information about the drbd-user
mailing list