Hi,

While I appreciate the general advice, please note I'm not trying to
reinvent anything. Instead, I want to prepare for natural problems that
OTRS will run into when reaching a size that requires load balancing.

For example, articles can't be stored in the database for installations
where articles size exceeds a couple of gb. In my case, the initial OTRS
installation has 25 GB of attachments. Storing those in the db would blow
query performance and lead me to having daily backups of unmanageable size.
So shared storage is a must. The problem is what needs to be shared and
what needs to *never* be shared.

I don't know about the code in Linux-HA but the load balancers I worked
with require some minimal support from applications behind them when the
app requires sticky app sessions (not http sessions, OTRS keeps a user
session alive across multiple http sessions).

Do you have load balanced OTRS installation?

/bogdan



On Tue, Jan 29, 2013 at 6:34 PM, David Boyes <dbo...@sinenomine.net> wrote:

>  Thoughts: ****
>
> ** **
>
> Rather than invent a application-specific solution, look at Linux-HA (
> 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
>
---------------------------------------------------------------------
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