No subject

databases as the main backend and leave etcd as an option.

> 3. According previous questions, what's preferred for large
> deployments? etcd or sql?

The most powerful, robust and maintainable option would be a centralized
database cluster. For most customers, I would recommend the PostgreSQL
database for such installations.


I'll add some background to shed some light on the development effort
behind LINSTOR:

I have to admit that LINSTOR is a bit of an alien in its environment.
And that was actually done on purpose. When I created the initial design
for LINSTOR in 2016, our background at LINBIT was the reliability,
robustness, scalability and maintainability nightmare that we had gone
through with drbdmanage, which was LINSTOR's predecessor (when LINSTOR
development started, the project was actually still called "drbdmanage
next generation" internally). Drbdmanage was built around its typical
environment, some Linux server with DRBD installed, with D-Bus as an IPC
protocol, a filesystem with config files, a Python interpreter, simple
JSON documents for persistence. It turned out to be way too limited to
continue developing it.

Most of the ideas behind LINSTOR were the result of ignoring all the
conventions, traditions and half-baked solutions that existed already in
those typical environments, and instead asking the question: What would
be the theoretical ideal solution in a perfect world, and then, how
close can one get to something like that within real-world limits -
limited developer time, money, limited hard- and software environments, etc.

That is why it was built around a full-blown SQL database, why it
originally used its own communication protocol for IPC, why all the
object names are different from drbdmanage's, why it doesn't have
drbdmanage's "--force" flags, why it writes its own error report files
in addition to using syslog, and that is also why it is so different
from its environment. I did not originally design LINSTOR to work or to
look like a typical Unix/Linux application, or to use whatever the most
widespread or most convenient protocol or data format is, or to e.g.
have a single simple numeric return code as most usual applications do.
Instead, my intention was to make the design more robust, more
consistent, more maintainable and also more scalable by avoiding many of
the weaknesses found in more conventional technology.

The introduction of etcd as an option, the replacement of the binary API
with a REST webserver, the use of DRBD quorum instead of fencing in
cloud environments, the presence of configuration files instead of
configuration utilities, all those things were adjustments made to fit
certain limitations, not because those solutions are technically better.
They aren't, they are just what either the rest of the technology around
LINSTOR or the users can deal with more easily.

In the real world, it's always a compromise.

As you can see, I could probably write an entire book about it all, but
I'll stop here for now.
Anyhow, I hope I could provide some insight into what the challenges and
ideas behind the development of LINSTOR are.

br,
Robert