Hi!
> You have it correct, there would be two (or more) different sites for
> complete site failover no shared IPs etc...
> I.e. if City A gets a blackout, City B should still be fine.
If you access to your OTRS service via DNS, you're going to have
some service downtime, because if you change the IP address where OTRS is
listening to, you need to change the A record for, say, otrs.foo.bar. That
implies
some lag until changes are effective on the net, even with TTL=0 (think about
proxys, dnscaches, browser caches, etc). But if you control from and who will
be accessing to your OTRS service it can be a good solution.
In a High Availability setup, you can use DRBD (www.drbd.org) to
replicate your data via internet (I would use a VPN tunnel to protect my data).
You're going to need some bandwidth, depending on how much information
you send/receive in your system. Heartbeat can be used to start/stop all the
services (Apache, Mysql, drbd) and, instead of moving a floating IP, to change
the DNS entry for OTRS. You can write your own scritps for Heartbeat, so it will
do what you need to do...
Maybe MySQL replication is enough, but I'm not completely sure that
everything that OTRS needs to run is stored in the DB. A good option is to use
a multimaster DB and drbd for the rest of files. In my setup MySQL data files
are kept in sync via DRBD, as if they where regular files... so good so far!
There are other alternatives, this one is the first that came to my
mind... I hope it helps!
Regards!
Víctor.
> Thanks,
>
> Trevor
> --
> Heredocs, theredocs, everwhereadocsdocs
> old macdonald had a server farm
> he eyed the I/O
---
Victor R. Rodriguez
Departamento de Sistemas
Valoraciones del Mediterraneo, S.A.
---
_______________________________________________
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Support oder Consulting für Ihr OTRS System?
=> http://www.otrs.de/
