Preferred way of a master/slave configuration with Zentyal 3.0

[Krisztián Czakó]

Hi,

What is the preferred and recommended way of using two or more Zentyal 3.0 servers with master/slave setup?

I'd like to make a master server with DC (LDAP, Kerberos, DNS, DHCP) and file sharing (Samba) only (no mail, no other stuff).
I'd like to make a slave server with mail and Zarafa only (nothing else) which syncs all user data from the master.
I'd like to manage users on the master (all attributes, including mail).

How should I do this?
Do I need the file sharing/domain services on the mail and add it as an additional dc? Or this is just for joining to an existing Windows server's AD?

Thank you.

Regards,
Krisztián

[christian]

Kristian,

Although I didn't try this with 3.0, I don't think Zentyal is currently developed for this kind of design.
For what I understand, you will only be able to manage mail attributes (on master) if you have installed and configured mail module.
Then does it prevent to run mail on slave and ignore the one running on master? I don't know.

Another aspect not yet clear to me is how multiple Zentyal may "share" Kerberos architecture 

[Krisztián Czakó]

Hi,

What else the master/slave architecture is good for? A small business don't need two mail servers. But they may need one file and one mail server.

The question in other way: for what purpose Zentyal 3.0 master/slave architecture is developed for and how to use it (what is the best practice)?

Regards,
Krisztián

[christian]

Krisztian,

That's a very good and interesting question you raise.
master/slave design has change a lot from Zentyal 2.2 to 3.0

2.2 had some limitations in term of module one could deploy on either master or slave, due to mainly the special LDAP replication design.
This has changed with 3.0 thus such limitation doesn't exist anymore.

However, and from my own standpoint only, Zentyal global design is not made with "multi-server" in mind. What I mean to say is that each Zentyal box, aside "users & groups" works as standalone box with it's one DNS, even its own LDAP (you can't rely on remote Zentyal LDAP to provide high availability), own admin account, one single MDA per mail domain (meaning you even can't hae local mailboxes in case you deploy Zentyal in different locations for same mail domain.

I don't have clear understanding of what could be the right design in case you deploy file sharing module on both master and slave Zentyal since 3.0

Well, because of all of above statements, 'm not very comfortable with current master/slave design but I do believe that Zentyal targeting bigger and bigger organizations, this is an area where they have to improve and also domain where we could bring our inputs and expectations.
I made some comments related to this during last Zentyal summit but I would like not to be the only one as my view might be truncated 

[onex]

Hello,

I just tried to setup the same constellation with zentyal 3.1 (beta) but without success.
Is there no way to install a "main authentication server" as a master and a second server with mail and zarafa as a synchronising slave?

Any advise how to setup two servers with master/slave synchronisation and an email-server as the slave will be welcome :-)
Thanks in advance,

Christian Frey.

[christian]

I don't know 3.O enough to describe what is feasible in term and master/slave and modules dependency 
If you have some specific needs, this is perhaps the right time to join the "Zentyal gathering" topic and put feature request at the right place.

BTW, I wonder if this topic is reserved to "Christian" or "Krisztian"  or whatever similar given name  

[onex]

I don't know 3.O enough to describe what is feasible in term and master/slave and modules dependency 
If you have some specific needs, this is perhaps the right time to join the "Zentyal gathering" topic and put feature request at the right place.

I'll take a look where I have to place these requests.

BTW, I wonder if this topic is reserved to "Christian" or "Krisztian"  or whatever similar given name  

I don't hope that only [C/K]ri[s/sz]tians try to run two ore more zentyal-servers in this constellation :-) and I don't understand why this thread isn't more active. Since virtualization is nearly standard to server-infrastructures it is normal to split different services to different servers.

[christian]

To me this is not linked to virtualization.
Virtualizing (meaning multiple server on same hardware) doesn't make sense, at least to me, when goal is to deploy Zentyal servers. Or I really don't understand what it brings 

What I do understand is that you may have multiple sites but want to maintain one single account back-end or do not want to stored data or users mail on server acting as firewall at the border of your installation.
With one single hardware... well feel free to explain the added value.
There is one, for sure, if your virtual machine relies on share disk: this helps providing HA. But in such case we do not discuss Zentyal split, do we ?

[onex]

To me this is not linked to virtualization.
Virtualizing (meaning multiple server on same hardware) doesn't make sense, at least to me, when goal is to deploy Zentyal servers. Or I really don't understand what it brings 

I'll try to explain my point of view:
I earlier days smaller customers didn't want to invest in multiple server just to split different services into different maschines.
Since virtualization isn't that expensive anymore it's easier to sell a powerful server and install different virtual servers. Each server for it's own service.
The main advantage is that e.g. the authentication server is stil online while you have to reboot the mailserver, and so on ...
You can maintain single services without the need to shutdown all services at once.

What I do understand is that you may have multiple sites but want to maintain one single account back-end or do not want to stored data or users mail on server acting as firewall at the border of your installation.

I would never mix user data and firewalls on one machine!
But as written before, I'd like to seperate mail- and samba-services without having more than one authentication-backend.

With one single hardware... well feel free to explain the added value.
There is one, for sure, if your virtual machine relies on share disk: this helps providing HA. But in such case we do not discuss Zentyal split, do we ?

I don't use shared disks or HA, I just like to do those thinks written above.

Christian.

[christian]

I've to admit that I don't really understand your view.
I do understand what you explain but don't understand (or rather don't fully agree) that this is a must or at least the right approach.

Main different between Windows and Linux/Unix design is the "shared DLL" Windows concept. It looks nice but has a lot of side effects, one being that it is indeed difficult to have really isolated environments. When one application crashes, it often impacts other applications.
In such Windows environments, VM helps, indeed, having isolated deployments. Cost for this however is one Windows server license per machine 
Furthermore, nowadays, need for Windows (system) reboot is dramatically reduced. You may see Windows system not having rebooted for months.

In comparison, Unix/Linux world do not suffer from same behaviour and sharing same OS is a rather well isolated way is much easier.
Unless there is an need for different kernel, most of the time you can easily stack applications on one single hardware.
If goal is to have different design, like multi-tiers application, then ask yourself root cause of such design ad you may end-up with deployment on different hardware.
Keep in mind that if your "single OS" machine crashes (hardware crash), then only one system will crash. If you have stacked lot of VMs there, then all will crash. This is not a major issue if you have deployed VM relying on central, highly available storage as same VM could restart on another hardware automatically but if this feature is not deployed, then impact of such hardware crash may be really annoying.

Do not take me the wrong way: I'm not against VM principle. This is very useful but very often misused.
- Hardware cost is low compared to administration overhead due to multiple OS you will have to manage.
- VM can be very efficient in term of high availability assuming you went for such design (BTW this is not what you describe)
- If deploying Windows, this is not really cheaper (again, hardware is not that expensive compared to OS). It has some pros in term of "green IT" but some cons in case of hardware crash.

Last but not least, Zentyla design is much more "all-in-one" box than "central interface for distributed services". If this is your goal, the Zentyal is perhaps not the right solution for you.
All of this being said, I do share your goal that is to be able to get flexibility in term of distributed Zentyal components, thus replication and master/slave. What I try to (slightly) challenge is reason why you push for this. Then these reasons are your  and I perhaps don't understand it the right way 

I should refrain myself to always try to understand why people are pushing for VM because it always ends up with this kind of debate 

[onex]

Furthermore, nowadays, need for Windows (system) reboot is dramatically reduced. You may see Windows system not having rebooted for months.

Please show me only one Windows server with actual patches not having rebooted since months?
Our customers servers want to reboot nearly every week because of new patches. :-)

In comparison, Unix/Linux world do not suffer from same behaviour and sharing same OS is a rather well isolated way is much easier.
Unless there is an need for different kernel, most of the time you can easily stack applications on one single hardware.
If goal is to have different design, like multi-tiers application, then ask yourself root cause of such design ad you may end-up with deployment on different hardware.

Keep in mind that if your "single OS" machine crashes (hardware crash), then only one system will crash. If you have stacked lot of VMs there, then all will crash.

Where is the difference? If I run all services on one machine and this one crashes everything is down. If the VM Host crashes, all services are down, so what? :-)
But the main advantage for virtualization is that I switch my disks to another VM Host, boot it and everything runs fine without any need to reconfigure any hardware. This is not possible with bare metal servers.
So VM is better that bare metal, even when you don't use HA, because the downtime can dramatically be reduced.
But this thread is not about virtualization but master/slave configuration of Zentyal servers.

Last but not least, Zentyla design is much more "all-in-one" box than "central interface for distributed services". If this is your goal, the Zentyal is perhaps not the right solution for you.

This all-in-one-box design is awful :-(
You wouldn't want to have file- and mail-services on the same machine as the firewall, but you also don't want to manage all users twice so what's this master/slave service for?

All of this being said, I do share your goal that is to be able to get flexibility in term of distributed Zentyal components, thus replication and master/slave. What I try to (slightly) challenge is reason why you push for this. Then these reasons are your  and I perhaps don't understand it the right way 

We just want to seperate samba and mail-services. What's wrong with that?

I should refrain myself to always try to understand why people are pushing for VM because it always ends up with this kind of debate 

Ever heard of features like snapshot, suspend, backup and moving of VMs?
I never want to miss these features anymore and you can't have them with bare metal.

Christian.

[christian]

We just want to seperate samba and mail-services. What's wrong with that?

Nothing, I've the same goal  but not same reason, that's it.

You want to split it because of some "VM" trigger while I want to split because of multi-site and/or security reason.

[onex]

You want to split it because of some "VM" trigger while I want to split because of multi-site and/or security reason.

not exactly, I want to split because of security and minimal downtime reason, too.
I only wrote that I prefer VMs than bare metals for backup and VM moving reasons ... :-)

[christian]

There is unfortunately no place in this forum structure to discuss "non-Zentyal" stuff and as you rightly pointed, this thread is about master/slave, not virtualization 

Still, to me, what is not really relevant when discussing about Zentyal is:

Since virtualization is nearly standard to server-infrastructures it is normal to split different services to different servers.

reason why I reacted.
This is not because you have deployed Zentyal within VM that you may want to split it further and this VM based deployment is supposed to be transparent. Anyway... 

Regarding "all-in-one" design.
- MTA is tightly linked to MDA and unique for one single mail domain: unless you apply some nasty port forwarding, mailboxes will be on Zentyal box acting as firewall.
- account management has to be done on Zentyal server acting as mail server (well, I'm not 100% this point is still valid with 3.0 and above)

What is  not clear to me is the potential double path between 2 Zentyal servers that could be configured:
- as LDAP master / slave (I mean directly at Zentyal LDAP level)
- as PDC / BDC (therefore aligning Samba LDAP content) 

[onex]

- account management has to be done on Zentyal server acting as mail server (well, I'm not 100% this point is still valid with 3.0 and above)

Maybe I'll try a different way:
Installing the Master-Zentyal-server as an authentication-, dc- and mail-server and a second Zentyal-server as a slave with bc- and samba-fileshares.
Maybe that's the only way to split mail- and fileservices with a master/slave construct.

It would be nice to know from the Zentyal-developers if this is the "best practise" and the right way to do it.
I don't want to switch my environment to productive with "a bad solution".

Christian.