Sentora Support Forums

Been thinking a while over sentora cluster. It was amazing challenge and idea.

A lot of issues but I think got the solution:

1. master node with full sentora install.

2. /var need to be on glusterfs (hmm logs) or maybe be only /var/sentora/hostdata

3. db on mariadb Galera or mysql. upgrade the main db to cluster.

4. install sentora stack on slave and upgrade db to cluster mode and same glusterfs setup to replicate data.

We may need too a small script on slave for apache conf rebuild or symlink it /var/sentora. same over dns data if needed.

sessions will be replicated. and all users data/bd's.

We could that way cluster web and email services.

Cluster could share load and survive disk failor but would be down if config messed up or hack.

I need to test this soon.

M B

Sounds like it could work! Looking forward to hear how the testing goes

Have the same idea running a while nnow. I replicate the databases with slaven and master configuratiob. Sentora and all /var/sentora data are mirrored with rsync. Iets cruede but working absolute fine. Purpose is redundancy.

But rsync is not real mirroring.

I was thinking about that setup for a real world WORDPRESS Customer. Offering real time loadbalancing. If you use rsync there would be a lag always for example when user update a new post and send new media. Even if you run rsync each min which will end up using too much ressources and less efficient.

That's why I thought over GlusterFS that handle it the right way. The other solution DRBD looked too heavy.

Also GlusterFS could offer replicate over more than 2 nodes and still in mirroring.

Realtime/synchronos is more complicated than master/slave setup.

(04-08-2016, 07:26 AM)Me.B Wrote: [ -> ]But rsync is not real mirroring.

I was thinking about that setup for a real world WORDPRESS Customer. Offering real time loadbalancing. If you use rsync there would be a lag always for example when user update a new post and send new media. Even if you run rsync each min which will end up using too much ressources and less efficient.

That's why I thought over GlusterFS that handle it the right way. The other solution DRBD looked too heavy.

Also GlusterFS could offer replicate over more than 2 nodes and still in mirroring.

Realtime/synchronos is more complicated than master/slave setup.

Yes I agree. I know its crude. I only needed it for reduncy. Databases are realtime. Rsync only 4 times a day. Instead of making whole backups I decided to do it this way so I had a option to switch from server and continued operation if the master fails.

Also looking into open stack

Hi, I was wondering if we have any news on this

What are your expectations?

We were checking idea's over the setup. We don't plan it as a release in short term, but you can do it.