Regarding system IDs... you couldn't give each system it's own system ID, otherwise they would function as distinct systems (each system wouldn't be able to act on tickets generated by the other etc.). Shared systems would have to share the same system ID.
And OTRS sessions can be stored either in the DB (by default) or the filesystem, so not sure why that would be an issue? With the "does last DB write always win", if the write was committed then yes, it's committed to the database, I don't really understand what your question is, that is how a database works? whether or not the last commit was successfully synchronised to other database servers will entirely depend on your database clustering configuration. I don't see why you couldn't have multiple front end "web" servers and a clustered database in the backend, and I'm not aware of any hard and fast rules that dictate you can't store articles in the DB once you reach a certain size, yes you are possibly going to run into some performance issues (maybe, depends on how tuned your DB is) and it will be quite a chunk of data to backup. Generally for the front end you will need at least 4 servers (2 load balancers sharing an additional virtual IP and the 2 web servers you want to load balance) queries hit the virtual IP and the LB node proxies the connection to one of the backend web servers. Steve On 29 January 2013 16:58, Bogdan Iosif <bogdan.io...@gmail.com> wrote: > 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 >
--------------------------------------------------------------------- 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
