This is a great place to express a concept that I have been trying to think through ... A secondary DNS or Mail server, ns2 or mail2, will operate until ns1 or mail1 is back in service. These systems expect the primary system to come back. They expect that they will always be the backup, the #2 to the #1. But if these #2 systems are truly mirroring the #1 systems then they should be able to take over, such that the #2 becomes the #1 and a new '2' system can get built and sync'd. A shuffle of hostnames and IP addresses would be required in such a transition but that's not a big deal. I've wondered if we could do the same with ISPConfig, promoting a slave to master if required, and just changing the "X is a mirror of Y" to re-assign roles. Is it more appropriate to think of a secondary box as always being a secondary? Or is this concept of succession a common/expected goal?
As confirmed by @till above, currently, you have to manually restore ISPConfig master if it is down as there is no way to promote its mirror or slave to replace its place. A lot of discussions have taken place but I think so far there is no best way suggested to have multiple copies of the same for automatic replacement in case of its breakdown.
This is possible, however there are so many things to bring up why you shouldn't do that. For example you need to rewrite the whole DNS structure, slave becomes master, the DNS settings are cached all over the world, so it needs time to synchronize. One big issue you can have is that the master can be down for the slave, but not for the rest of the internet... that will give a whole bunch of conflicts. The question is, what do you gain with it? the DNS does have a secondary DNS structure and works well for everybody. You need a whole lot of checks so that you do not end up with a non working system at all (DNS is picky, errors will result in rejection of a whole domain) If you don't want to do this automatic , it's easier to just restore a backup and change the IP's (that's something you could make automaticly) Also what's impossible to automate is changing the nameserver settings at the domain registars, so in my opinion, it's not so easy to accomplish this and I doubt you will benefit from it.
There is no problem to make a master server highly available and many larger ISPConfig installations do that. What matters for the master server is its MySQL database as the master itself has no config files or other system config, this database must be accessible by the slaves all time and also by the interface, while you can have as many copies of the interface running on different servers as you like as long as they all connect to that highly available master database. There are various technologies available to make a mysql/mariadb databases highly available and that's basically all that you have to do to make an ISPConfig master highly available. But for most users, that#s actually not an issue as the slave nodes are not affected by master being down, so the worst thing that can happen is that users can't add new websites, while the website and mail accounts on the slave nodes continue to work. and when you have a good backup strategy, e.g. based on virtualization, then you can restore a master in case it's down within minutes. When you then take into account that such a short downtime maybe happens once in 5 - 10 years when your servers are maintained properly, then you have to ask yourself if the additional complexity of running a HA MySQL database is necessary at all. Especially as I've seen many setups that had more downtime due to the added complexity of a HA database than downtime that would have occurred without it. So to come to a point, for a larger ISPConfig setup, make sure you have a dedicated master node that does not host any other services. Then take care that this master node has a good backup and restore strategy, e.g. by using virtualization and putting it in the cloud, so you can restore or spawn a new copy of the master within minutes.
With floating IPs this isn't a problem. The external DNS doesn't change at all. The machine assigned the floating IP changes. Ultimately I do plan to automate this. I just didn't know the best approach. Look into the concept of a floating IP. It's really nice. I value your opinion and with this discussion I agree with you. But your reasoning is based on some missing information. I hope learning about floating IPs will help you in the future. If you wish, I can document here why I use them.
That's the complete answer to all of this. I simply did not know if there was any other ISPConfig-specific strategy available. I run small businesses with about 10 domains, maybe 15 sites total. They all have very low traffic right now. I need several email accounts for each domain - free email services from ISPs suck, and for-fee costs too much for this scenario. It's a tiny environment compared to ISPs and large companies, but large enough to warrant centralized tooling, automation, and some very basic HA. As business owner, developer, sysadmin, and resource to our clients, I need to have a stable environment with minimal administrative requirements. I've been running my sites in a combination of shared space and VPS. I was running a Zimbra email server until a few months ago when the backup of the server instance locked right before a distro upgrade of Ubuntu 18 to 20 failed. It was a weird coincidence that left the environment unrecoverable. I was OK with that. I wanted to redesign it anyway and move away from Zimbra. I created a new subnet where I'm doing all of this work with ISPConfig, spinning up new servers, testing, blowing them away to start over, and writing scripts to reduce recovery time. As I get more familiar with each application in the ISPC ecosystem and others, I ask myself what can happen to it and what needs to be done to protect it. That leads to backup strategies, mount points for data, instance/shard duplication, redundant servers, DNS management, and plans for recovery from all of these mechanisms. So I ask a lot of questions here and I spend a lot of time searching for documentation here and elsewhere. In return for the help I get to do this for my purposes, I offer back what I can. That includes a contribution to documentation, helping others to navigate this software where I find difficulty, and as time permits I write notes about marketing and other topics related to getting more people to use good software. That's where ALL of this is coming from. Sincere thanks to everyone here for sharing your insight, knowledge, and time.
I didn't know you meant working with floating IPs, but why shouldn't you use a load balancer to do this kind of stuff, that would save you a lot of trouble.
I will look into the details of doing this, very soon. I just wanted to ask first if there was another approach that I should consider.
if you want something stable and opensource, you could take a look at PFSense. it supports virtual IP. I used CARP on PFSense, it works great. (biggest downside, CARP needs to be in the same subnet)
