
I've searched through the archives and haven't found anything on this yet. Has anyone managed to set up OTRS in a multi-homed setting? If so, how would you go about this? Is it just a matter of setting up multi-master MySQL databases? Thanks, Trevor -- Heredocs, theredocs, everwhereadocsdocs old macdonald had a server farm he eyed the I/O

Hi!
I've searched through the archives and haven't found anything on this yet. Has anyone managed to set up OTRS in a multi-homed setting? If so, how would you go about this?
What do you mean with "multi-homed"? Sorry, I don't speak english natively and I don't really know how to translate "multi-homed" to spanish when refering to OTRS ;)
Is it just a matter of setting up multi-master MySQL databases?
I suppose that it depends on what do you need to archieve using a "multi- homed setting". If you need to distribute the load, you can put Apache and OTRS on one server, an SMTP server on another and the MySQL database on a third machine, for example. If you need High Availability, you may use HeartBeat+DRBD and share mysql and OTRS data between 2 machines, so if the "master" goes down, the "slave" server will startup the service with little service loss. That's how I have it right now.
Thanks,
Trevor
Regards, --- Victor R. Rodriguez Departamento de Sistemas Valoraciones del Mediterraneo, S.A. ---

Victor,
Thanks for the response and I apologize for the confusing language.
Basically, what I am asking is if a hot backup site can be configured.
I.e. Site A has the main OTRS service and Site B has a backup that
must be synchronized with Site A.
In the case that Site A fails, Site B should be able to pick up from
where Site A left off with no major problems (I understand that
e-mails may be forced into queues).
Finally, when Site A comes back online, it should synchronize with
Site B and resume the primary server function.
I believe that the setup you describe would work but it may be
interesting getting the heartbeat metrics correct at distributed
sites.
Thanks!
Trevor
On 7/6/05, Victor Rodriguez Cortes
Hi!
I've searched through the archives and haven't found anything on this yet. Has anyone managed to set up OTRS in a multi-homed setting? If so, how would you go about this?
What do you mean with "multi-homed"? Sorry, I don't speak english natively and I don't really know how to translate "multi-homed" to spanish when refering to OTRS ;)
Is it just a matter of setting up multi-master MySQL databases?
I suppose that it depends on what do you need to archieve using a "multi- homed setting". If you need to distribute the load, you can put Apache and OTRS on one server, an SMTP server on another and the MySQL database on a third machine, for example. If you need High Availability, you may use HeartBeat+DRBD and share mysql and OTRS data between 2 machines, so if the "master" goes down, the "slave" server will startup the service with little service loss. That's how I have it right now.
Thanks,
Trevor
Regards,
--- 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/
-- Heredocs, theredocs, everwhereadocsdocs old macdonald had a server farm he eyed the I/O

Trevor Vaughan typed, at or about 7/6/2005 12:09 PM, ...
Basically, what I am asking is if a hot backup site can be configured. I.e. Site A has the main OTRS service and Site B has a backup that must be synchronized with Site A.
In the case that Site A fails, Site B should be able to pick up from where Site A left off with no major problems (I understand that e-mails may be forced into queues). Finally, when Site A comes back online, it should synchronize with Site B and resume the primary server function.
I believe that the setup you describe would work but it may be interesting getting the heartbeat metrics correct at distributed sites.
Not at all! heres an idea: All the main data is in a centralized database. OTRS runs on multiple webservers, all talking to the same database, that way theres no need to synchronize. Just make sure the Database machine is rock solid. The only thing you need to really worry about is both websesrvers replicating work with their cron jobs You can do one of two things: A) Make a "WhichServer" table in your database, each webserver gets a script to check and see whis supposed to be the main server, and who is still alive, and who needs to be running the cron jobs B) Let BOTH webservers run the cronjobs, just stagger them a little. You wouldnt even need heartbeats, then. -- -Tony

Thanks for the suggestions, questions inline... <Snip/>
All the main data is in a centralized database. OTRS runs on multiple webservers, all talking to the same database, that way theres no need to synchronize. Just make sure the Database machine is rock solid.
This is where I was thinking about the multi-master database. I can't use just one database because that still gives me a single point of failure which is a bad thing. It shouldn't be too hard since MySQL supports this now.
The only thing you need to really worry about is both websesrvers replicating work with their cron jobs
You can do one of two things: A) Make a "WhichServer" table in your database, each webserver gets a script to check and see whis supposed to be the main server, and who is still alive, and who needs to be running the cron jobs
B) Let BOTH webservers run the cronjobs, just stagger them a little. You wouldnt even need heartbeats, then.
Unfortunately, it would be very difficult to prevent race conditions here, especially if the clocks on the servers had significant drift. With a heartbeat, it would allow a more serialized process which would prevent race conditions. Of course, where do I put my heartbeat server ;-). Can two heartbeat servers monitor the same boxes? How does that work? Thanks! Trevor -- Heredocs, theredocs, everwhereadocsdocs old macdonald had a server farm he eyed the I/O

inline commentary yet again...
All the main data is in a centralized database. ... Just make sure the Database machine is rock solid. This is where I was thinking about the multi-master database. I can't use just one database because that still gives me a single point of failure which is a bad thing. It shouldn't be too hard since MySQL supports this now.
The database can either be a pair of machines, or you just get one big fat beefy badass box as your webserver. I worked for an online shop in the states that had doubled hardware that ran in lockstep, but those are silly expensive. I think NEC makes them,
The only thing you need to really worry about is both websesrvers replicating work with their cron jobs Unfortunately, it would be very difficult to prevent race conditions here, especially if the clocks on the servers had significant drift. With a heartbeat, it would allow a more serialized process which would prevent race conditions. Of course, where do I put my heartbeat server ;-). Can two heartbeat servers monitor the same boxes? How does that work?
You don't use a heartbeat server at all. Each webserver has a script that loops every N seconds that checks in with a table on the database that updates its own record Then it checks the records of the other machines against it. The records use the DATABASE clock for timestamping (with a "NOW" function or whatever) to the time is always relative to the database clock. If it tries to check the database and THAT is down, wewll, you have bigger peoblems on your hands and the webserver can raise all sorts of alarms, send pages, and make a general huge fuss. 2012 Olympics are in London, by the way. -- -Tony Saurini Eitri Ltd. tony@eitri.com eitri. we make hammers. Big Hammers.

Victor,
Thanks for the response and I apologize for the confusing language.
Don't worry... probably it's my fault as I haven't sleeped enough...
Basically, what I am asking is if a hot backup site can be configured. I.e. Site A has the main OTRS service and Site B has a backup that must be synchronized with Site A.
In the case that Site A fails, Site B should be able to pick up from where Site A left off with no major problems (I understand that e-mails may be forced into queues).
Finally, when Site A comes back online, it should synchronize with Site B and resume the primary server function.
Ok but... Site A and Site B are different locations? (different internet addresses, different ISP's, and so on) If they are, things will be a bit more complicated. In my setup, OTRS is accessed using an internal IP address (192.168.0.23) that "floats" between my two servers (it's on the master until it fails or I take it down). That will work exactly the same using Internet IP's of the same range, but not if they're of different ranges.
I believe that the setup you describe would work but it may be interesting getting the heartbeat metrics correct at distributed sites.
When making this kind of resilient setups is important to know exactly what kind of circumstances you want to survive: server hardware failures, network hardware failures, OS failures, network/ISP failures. Some are easier/cheaper to accomplish, but others are really difficult. Which ones do you need to survive? If I know exactly what you need maybe I can help you a bit more ;-) Regards, Victor. --- Victor R. Rodriguez Departamento de Sistemas Valoraciones del Mediterraneo, S.A. ---

Victor, 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. Thanks, Trevor -- Heredocs, theredocs, everwhereadocsdocs old macdonald had a server farm he eyed the I/O

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. ---

Great idea Victor. Thanks for all the input to everyone who posted, it's greatly appreciated. Trevor
participants (3)
-
Tony Saurini
-
Trevor Vaughan
-
Victor Rodriguez Cortes