2 node cluster

[Gaspetaahl]

Im a bit confused with the different options for clusters and high availability. Maybe someone can clear up my confusion or link me the correct documentation.
I have two identical systems with 6 hard drives each. I want to mirror the data from one system so that I can continue accessing the data even if for example one mainboard fails.
The simplest solution would probably be to schedule an rsync task every night.
Now I saw that Scale supports cluster and high availability. Can I set up a cluster with 2 nodes so that I can access the two systems as if they were one system with redundancy? How would I do that?
I read that I need 3 clusters for Gluster. But I dont really understand why 3 nodes would be needed.
What setup would you recommend here?
Thanks in advance

 

[sretalla]

Can I set up a cluster with 2 nodes so that I can access the two systems as if they were one system with redundancy? How would I do that?

With SMB and gluster.

I read that I need 3 clusters for Gluster. But I dont really understand why 3 nodes would be needed.

It's called majority node set...

What if both systems remain alive, but lose network connections to each other?... both systems then think they are the only one running, so take ownership of publishing the storage to clients, resulting in potentially both systems taking changes with no means of tracking or conflict resolution of those changes.

You need at least a third "witness" (if not also participant) node to break the tie, where 2 systems together can agree that one node is missing.

If you don't need automatic failover, you only need 2 nodes.

If your goal is high availability, you really need to be running enterprise on hardware (with support) provided by iX, which allows a proper HA cluster of 2 storage controllers on one set of disks.

 

[Ericloewe]

You need at least a third "witness" (if not also participant)

Just a note: Arbiter nodes are a sad joke that's only supported for the absolute simplest of scenarios: Two "prime" hosts with one brick each. Don't let old docs deceive you, like they deceived me and my colleagues at work.

Of course, the "fix" was to update the docs to reflect this absurd limitation.

 

[Gaspetaahl]

Thanks for the replys. Im still a bit confused. Can I use Gluster two setup something more advanced than running zfs send every night with my 2 systems or would I need 3 systems for that?

 

[Ericloewe]

Can I use Gluster two setup something more advanced than running zfs send every night with my 2 systems or would I need 3 systems for that?

Three systems is the absolute minimum for a setup using Gluster that's remotely reliable. I guess two systems would work if the quorum were set to 100%, but I haven't tested that scenario - and you'd be read-only at the slightest bump in the road. Also, Gluster is pretty damn slow.

 

[blanchet]

The basic solution is to setup ZFS replication every hour (or even more often) between the main and secondary system.

If the main system is down then just update your DNS (or steal the IPs of the main server) and serve the data from the secondary system after disabling the readonly proprety on the target datasets.
The main drawbacks are
- you have to manually synchronize the settings (for exemple shares)
- the failover is manual

Nevertheless, the best solution is to pick a TrueNAS High-Avaibility appliance from iXsystems.

 

[NickF]

The basic solution is to setup ZFS replication every hour (or even more often) between the main and secondary system.

If the main system is down then just update your DNS (or steal the IPs of the main server) and serve the data from the secondary system after disabling the readonly proprety on the target datasets.
The main drawbacks are
- you have to manually synchronize the settings (for exemple shares)
- the failover is manual

Nevertheless, the best solution is to pick a TrueNAS High-Avaibility appliance from iXsystems.

You could theoretically automate this, it would work for some scenarios, though it is kinda hokey :)

 

[morganL]

Im a bit confused with the different options for clusters and high availability. Maybe someone can clear up my confusion or link me the correct documentation.
I have two identical systems with 6 hard drives each. I want to mirror the data from one system so that I can continue accessing the data even if for example one mainboard fails.
The simplest solution would probably be to schedule an rsync task every night.
Now I saw that Scale supports cluster and high availability. Can I set up a cluster with 2 nodes so that I can access the two systems as if they were one system with redundancy? How would I do that?
I read that I need 3 clusters for Gluster. But I dont really understand why 3 nodes would be needed.
What setup would you recommend here?
Thanks in advance

There is another solution we are working on with Syncthing App that would work with 2 nodes and SMB/NFS sharing... but not for iSCSI.

 

[caiot5]

So what about this "another solution"with Syncthing App, is it ready already? How to ensure backup/failover (manual) between the two identical nodes by using it?

 

[morganL]

So what about this "another solution"with Syncthing App, is it ready already? How to ensure backup/failover (manual) between the two identical nodes by using it?

Yes, it works for SMB (well tested) and should work with NFS and S3.

It does not work for iSCSI.

 

[Gaspetaahl]

Yes, it works for SMB (well tested) and should work with NFS and S3.

It does not work for iSCSI.

Is there any documentation on this?

 

[morganL]

Is there any documentation on this?

Syncthing is the primary documentation. More will be forthcoming.

https://docs.syncthing.net/intro/getting-started

 

[caiot5]

Syncthing is the primary documentation. More will be forthcoming.

https://docs.syncthing.net/intro/getting-started

So, the difference between Syncthing and Rsync is that, in theory, Syncthing monitors the files and synchronizes it between the nodes whenever a file is modified while with Rsync you have to create a schedule so it would be syncronized, isn't it?