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. OK, I was jotting down some thoughts – sorry if it came off wrong. More details inline.
We have a two app node, 3 DB server system supporting one of our labs. The OTRS application runs on the app nodes, MySQL 5.1 on the DB servers in cluster mode. The app nodes are behind a set of servers that provide a general load distribution tool for HTTP/HTTPS traffic, running Linux Virtual Server (LVS), roughly equivalent to the old Cisco content switching devices. We use the same system id on both nodes. 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. As I said, there’s a bit more database maintenance involved. Our DBA runs a script periodically that vacuums the attachments out of the database, stores them in our document management system, and replaces the entry in OTRS with a URL reference to the archived copy in the DMS. We find that keeps the DB size manageable (and keeps clear custodial records of the attachment data, along with providing a globally unique identifier for each attachment) while not requiring shared storage which is a gigantic PITA. Probably not a universal solution, but it leverages a lot of other stuff in terms of data management and storage management (the DMS has hierarchical storage management and automatic recall capabilities, as well as much more robust data management classifications that we can rely on to make sure we keep data as long as it’s required, but no longer than that). 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). The Linux-HA stuff is the second tier for managing the application processing cluster. The LVS stuff does most of the sticky session processing. Re: SSDs. I’m not sure I’d go that route for the data tables. Indexes, maybe. That’s mighty expensive storage for dead data, as you mentioned.
--------------------------------------------------------------------- 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
