Good Day: I have been looking around in howtoforge for something that might help me with this implementation. I know there is one for Debian but not Ubuntu. https://www.howtoforge.com/tutorial...abase-cluster-on-debian-8.4-with-ispconfig-3/ Also would not know if the DEVIAN version can be used for UBUNTU as well. To be honest, I don't need load balancing. Just redundancy (ideally the system should be transparent to the network - only comes up when needed with same IP address as the down server) and Rsync Backup. Any comments are appreciated Cheers.
It does work with ubuntu, but I am planning to write a new guide which will use the autoinstaller on Debian 10.
Thank you ahrasis and Th0m. Question. How would this system operate - lets say in the event that the master server goes down and goes up again automatically. Also. Because it can do Load Balancing, does this system requires to have two public IP's. My original intent is to only have one server going out and in the event of that server also going down, to have redundancy with a second server. So to the Public, it would look as only one server is operating regardless of the situation. Would this https://www.howtoforge.com/mirroring_with_rsync be more suitable? Cheers
Everything keeps working when the master goes down and when it comes up again, you are able to log in to the panel and do eventual changes, that will be processed on the slaves. When the master is down, some cron scripts won't work on the slave, so it is a good idea to bring it down for a long time (several hours). It is not a good idea to set up 2 master servers as this can cause more downtime than just having one. For slave servers, like web and mail, you can set up mirrored systems behind a load balancer. For web servers, the data should be located on a network filesystem, and for mail, you can use dsync.
The tutorial requires two ip addresses, that is one for each server, but that doesn't mean that they need to be public, as private ip should work with capable router as well. In case of public ip, dns server A record entry will be two and they need to point one to the master and one to the slave. Almost similar to that, a capable router may do the same or better, since in the event it detected the master server failed, it can automatically points to the slave. The different is, dns server will try connection to the master ip several times before deciding to connect to the slave ip. A load balancing server in front of the two, however, can do very much the same as a capable router may. Both load balancing server and capable router also may fail, so actually there is no easy way out either. Something like that for the said tutorial.
Good Day. Just to clarify. When I meant Public IP was to say, when the servers go outbound. For example: I would have thought that the way this worked was having the two servers - each - with there own private IP (LAN) like so: Server 1: 192.168.0.2 Server 2: 192.168.0.3 But only one Public IP (WAN) being that this is a HighAvailability operation between two machines and only one is is receiving SMTP queries while the other one is replicating. DNS for Public IP's could be Two MX Records for mydomain (solves the FQDN issue) One A Record for mydomain (maybe Dynamic PAT on the Router) From your comments it would seem that I will need two public IP's (two A Records - one for each MX). This is not an issue (two public IP's) but I'm curious to know if the mentioned approach wouldn't work. Comments are appreciated Cheers
I think one static / fixed public ip will work for this redundant system sufficiently, if managed properly by the intermediate machine, whether it is a router or server. ip1 > HA / LB router / server > ISPConfig multiple servers DNS servers were seemed as not your main concern but two public ip is normally used when you want your dns servers (two machines) to manage itself and other servers as well, round robin way, without any other machine in the middle of all servers. ip1 > dns1 > > ISPConfig multiple serversip2 > dns2 > The first approach requires minimum of three machines (one intermediate) with minimum of one static / fixed public ip. The second approach requires minimum of only two machines but two static / fixed public ip are needed.
You would need a professional router for this and you still miss the connection redundancy. If you want to have a redundant system, spread your service over different servers, connected through different networks, located "far" away from each other.
redundancy can be done with just two servers. assuming you want 1 active 1 passive, with the passive server taking over on problems. you could install and configure a service like heartbeat, use it to monitor both the internet facing ip, and the private network facing ip's (if used) on both servers. the active server will also have the floating ip assigned to it. if the passive server misses a number of heartbeat signals (number defined in the config) from the active server it assigns the floating ip's to itself and all traffic should now go to this server, the failed server should change it's state to passive. if the problem on the failed server is resolved, it can either remain as the passive server until a problem occurs on the now active server, remain passive until manually re-assigned as active, or automatically take over as active and force the other server to passive. the actual fixed ip's on the server are only used for direct access to the server for admin purposes, and for the faillover/heartbeat monitoring services. all internet traffic in/out traffic should only ever use the floating ip. this method avoids end users having failed to connect messages when they get the ip of a failed server from dns in the second method described by @ahrasis where round-robin dns is used as a method of load-balancing. it does have a drawback in that it is possible for both servers to believe they are the active server and the other server has failed, and thus both servers are announcing themselves to the network as responsible for the floating ip. although if one of them is configured to force itself to master that should only happen if there is a definite problem in the network links between both servers.
