Thoughts:

Rather than invent a application-specific solution, look at Linux-HA 
(www.linux-ha.org<http://www.linux-ha.org>). They’ve solved most of these 
problems in a neatly packaged way.
There’s existing code to handle session affinity and most of the request 
distribution process.

If you store everything in the database (including attachments), you can easily 
separate the application logic from the database server; that introduces a bit 
more database management, but it easily allows multiple otrs instances to use 
the same data safely. It also lets you take advantage of the clustering 
features in the dbms software. You also eliminate any need for shared storage.

If you use shared storage, you MUST use a cluster-aware filesystem like GFS2 or 
OCFS. NFS won’t work reliably.

From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Bogdan 
Iosif
Sent: Tuesday, January 29, 2013 5:21 AM
To: OTRS User Mailing List
Subject: [otrs] NLB (load balancing) OTRS

Hi,
Can anyone help with some obvious issues around setting up a load balanced OTRS?
- Does last db write always win?
  I imagine there's no built in protection against it.
- Are HTTP sticky sessions required and if so, how can they be configured?
  I imagine OTRS needs some built in support to allow identification of user 
sessions in the balancer so that it maps them on the same app server.

- To what extent is shared storage required?
  An older mailing list message proposes sharing the whole /var dir through a 
storage that support file locks (mainly to safely use TicketCounter.log but 
this could be worked around by setting up different SystemIDs (via SysConfig) 
on each app server). While sharing storage is required for /var/article (when 
attachments are stored on disk) I don't know if it's required or even safe for 
the other subfolders in /var (especially /tmp).
Thanks,
Bogdan
---------------------------------------------------------------------
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

Reply via email to