I followed the document and manual for build up two Debian Mirror server with ISPConfig. Under my test with mirror, I found slave server does not pickup the backup role. What I test ? Bring down the master server and try to login to access slave server ISPConfig admin console. It does not found the page. I read the manual again, it is because "Install ISPConfig Web-Interface (y,n) [y]: <--n" does not install on slave server. How can I active the slave server when master server go down ?? I want to ask that how many poeple install mirror server successful ?? Can anyone share the step or succesful story.
All, I was subscribed for download manual that hope for help to solve mirror issue. The manual is great but it really not work. I hope someone to help me for build a good mirror ISPconfig Server.
Can you check if the configuration files got copied to the slave? Do you have a failover IP that switches to the slave when the master fails?
Falko, I am following 3.3 Mirror setup on Manual. I am no failover IP added. After I bring down the master server, I use slave server IP to access. But it is no response. I checked server does not listen 8080 port. And other is it correct step to "rm -f /var/www/ispconfig" after secondary server installed ISPCONFIG ??
falko, I forgot tell you that the mounted volume is in sync but the configuration files doesn not copy to the slave? I check monitor tools in master ISPCONFIG, it cannot get the information from slave. It only show running for slave server.
Keith brings up 2 very good questions. 1. Has ANYONE got this to work? I've tried unsuccessfully 5 times now :-( 2. How to you access ISPCONFIG if the MASTER Fails? I would be just as Keith is, if my master fails, I want to be able to just switch my router to point to the new IP address of the slave while I repair/replace the master, or better yet, if the slave can become the master and then a new slave put in place.
I think you have the idea of the mirror slightly wrong. I do have a mirror working. And yes, I can log into the console on the mirror, but here is the really big but, you should never log into the console on the slave as if you make changes, the master will be out of sync. This is why the guide says not to install the console on the slave. The idea of the mirror is supposed to act as a mirror server not mirror ispconfig console. A better way to think of it is to think bigger. You have one ispconfig control panel server and a load of other servers being controlled as slaves. Some of those slaves may be mirrors of each other. If one goes down the other can stil be used if you adjust some ip settings. If the control panel server goes down, never mind. The other slaves don't need a master to function. If you want to make a backup master that's a different story. When Falko talks about a failover ip there are tutorials to help you achieve a system where a second server will take over the services if the first fails. Hope this helps - unless I have the concept all wrong myself! in which case we're all in trouble !
Ok, you have a mirror working . Did you install it as per the ispconfig 3.03 manual using Glusterfs and all other steps associated with it?
Thanks jtheed and Toucan for reply on this post. From Toucan replied that the mirror setting is only for service mirror. When the master goes down, smtp/pop3/ftp/webhost are still running on slave for service. Only ISPCONFIG console will not be available. Is that right ?? If really want to mirror completely, how can I do ?? I really want to have secondary or mirror for ispconfig if master fail.
You got it - the mirror will replicate services, apache etc will keep running on the mirror. What it doesn't do is mirror the contents. Personally, I achieve this using rsync. It copies the content of sites to the slave, usually no more than a minute after it is written on the master. This is a good guide: http://howtoforge.com/mirroring_with_rsync If you want the console on the mirror as backup, I just have previously just said yes when it asked to install it or not from what I remember. But as I said, there'll be no going back to the master if you make use of the slave console. I'd probably seek some other advice before going down this route as I'm not sure of any other implications.
Sorry for resurrecting this old thread Another way to achieve the "mirroring of contents" is to have the websites (and possibly mailboxes?) on a shared backend storage like a SAN or NAS. The website/mailbox directories can be connected to using iSCSI, NFS, or even SMB, that way the servers (main and backup) will all have the same contents but no need to worry about synchronising them. -SilkBC
Sorry for bumping this. It seems that 4 years have passed and the issue is still pertinent! So, the way I understand this is that the mirror is not really a mirror. It's more like a master/slave configuration, where you have one master and several slaves, each managing different services on different hardware. I can see how that is useful: log in to a single console, access lots of servers, each with its own setup, clients, etc. But you just need to use a single 'master' console to access all of them. It's a good idea! In the case of this thread (and it's certainly my case as well), what we're looking for is a failover solution, either automatic or hot standby. In my case, I'm fine with hot standby (even if it means wasting a server). My own configuration are two servers from different low-end bare metal providers. The 'master' is a Quad Xeon and has enough power for my relatively low-traffic websites (I just have many of those!). The 'hot standby' is a low-end Atom single-core server (which actually works well). Both have the same RAM and disk space, so when the master fails (I'm really on a low-end provider who does little management and technical support is slow and hard to get), I can temporarily switch over to the slave, and let everything run from there by just flipping DNS settings. Since I use CloudFlare for all sites hosted there, it's very very easy to do that (I suppose I could even automate it!). So I followed the instructions to do MySQL master/master replication, and also Unison for replication (it seems to be preferred over old faithful rsync for some reason). After many hours, I managed to replicate everything. There is, of course, a problem: each server has its own IP and FQDN. So there are slight differences in the database and the configuration files, even if all else is fine. Also, most of my sites will have the host's FQDN hidden "somewhere", which is a pain. Fortunately, most of them do not need it — they are, after all, vhosts and should be happy as such! To make ISPConfig work flawlessly in a failover situation, I think that it would need to have some sort of 'virtual' FQDN, e.g. something like this: ispconfig.mydomain.com -> this is the 'virtual' FQDN. All configuration items use that. master.mydomain.com -> first server (usually up). None of the ISPConfig configuration settings would ever, ever use that FQDN. slave.mydomain.com -> backup server. Same here: no configuration should be using this. It almost works like that. The vhost configuration is for '_', meaning 'default server'. As far as I can see, the host FQDN does not appear anywhere inside /usr/local/ispconfig — not does it appear on nginx's or php5-fpm's configuration (and possibly not on Apache's either). The only place where it appears is inside the MySQL database, which seems to be unavoidable... for now. It also means that I cannot simply synchronize the dbispconfig database, because those FQDN's will be wrong. Still, it works for me right now. I have just to change all entries in the database manually (there are not many) and change CloudFlare. The rest should work out of the box. Maybe this is something worth considering for ISPConfig 4 or 5...
For failover I use DNS failover provided by dnsmadeeasy. Within seconds of the master being unavailable traffic is redirected to the slave. When it becomes available again it redirects back.
No, the problem discussed in this thread was about a older cluster setup that offered access to the controlpanel only on the master node and not like the current setup, on both nodes. See current guide which configues the controlpanel interface to be accessible on both nodes: http://www.howtoforge.com/installin...tabase-cluster-on-debian-6.0-with-ispconfig-3 A server needs a unique fqdn and IP, otherwise you cant access it. But thats relevant for the backend system only and has no effects on your mirrored sites, as you mirrred site use the domain name of the website and thats the same on both nodes. Regarding IP addresses, you can use a virtual IP that you switch between the servers if you run a hot standby system only and not a loadbalanced cluster. Btw. you mentiined rsync, rsync is a one way replication and not a 2 way replication like unison, so rsync wont work for such a mirror.
I'm also currently at the stage that I need to provide an HA cluster for the clients. For now I'm thinking about setting up a mirror in the usual ispconfig way, with one exception. The slave server will NOT have a different hostname. It will have the exact same hostname as the master server. Their contents will be kept synced using unison, databases will be configured in a master-master replication and the HA part will come into play using CARP. Why CARP and no haproxy? No other box needed, just the servers. haproxy has its use later on. Server A is the master Server B is the slave A has its own ip + CARP ip B has its own ip + CARP ip A > B syncing using their own IPs A fails B takes over within seconds by becoming a master of the CARP IP. A is fixed and comes back online A takes over and B starts syncing to it using their own IPs. The whole process shouldn't take more than 10 minutes. Websites, emails and databases are synced back to the master. The good thing is that servers can be accessed using their own IPs or the CARP IP to access the current master. What this means is that you can set up a haproxy box upstream of them to load balance them, and in addition to them being HA, by using their own IPs, but, in the case of our hosting at least, not changing any work flow for the clients or messing with any external dns failover solutions. They have their use, but failing over a server that's 2 racks away is hardly their use. Failing over to a server that's 2 countries away, that's their use. They keep on accessing their webmail as usual. Before anyone jumps in and says that's supposed to be that way, since they are accessing their webmail on their site's address. WRONG! You should set your servers as to use the server's hostname as a central access for all the clients, and in addition to that, secure them using the server's SSL certificate. If you are using a [clientdomain]:[port]/webmail access to your clients, you are doing it wrong. Even [clientdomain]/webmail is not acceptable. I'll be doing some testing in the coming weeks for this, and hopefully it will all work out. Then it's just a matter of scaling up from there.
