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