On Mon, Aug 1, 2016 at 3:58 PM, Adrian <[email protected]> wrote: > A couple of hours downtime in case of failure is acceptable so the > switch between them can even be done manually by changing the settings > in the firewall, but most likely I will automate the switch and set an > alarm or notification for the event.
So you've already committed to an approach where "the" production server is completely self-contained, and isn't going to be relying on other machines like DB servers and so on. Fair enough. The "couple of hours downtime" is interesting, now it's beginning to look like there isn't much data being *created* on the server that needs to be preserved. Can you clarify that? When the production server goes down, how old can the state of the standby be, in comparison? If what you have is effectively a publishing platform, rather than an updating one, then life becomes much easier - all you have to do is to make sure that configuration and data changes are made on both internal machines at the same time (with the added benefit that the warm spare machine can be designated "test", and you can push changes to that first, then test to make sure they work; then switch over from one to the other and do the changes on what was the prod box before you started) Because you have multiple VMs, you might need to consider automation within each VM being responsible for updating its partner, rather than trying to do it from the host OS. If you can expose any updated state on these machines as a simple filesystem change, than you can't get much better than rsync in an infinite loop :-) (don't call things like rsync from cron, unless you also include locking checks to make sure you aren't running multiple simultaneous copies of the command when things go wrong). _______________________________________________ Linux-users mailing list [email protected] http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
