Now this is some mighty useful info. Thanks a lot. I'm not familiar with LVS or Linux-HA (mostly used MS platforms until ~ recently) so the next question may be born out of confusion: You have the load balancing performed by machines runnings LVS and the Linux-HA is running on the app nodes?
Just to make sure I understood some of your points: a. You have a load balancer in front of your app nodes using a generic sticky sessions algorithm that you didn't have to configure in any way for the OTRS nodes. Correct? b. In addition, because of your clever attachment juggling and because the user session is stored in the db you did not have to set up shared storage between the app nodes. Correct? One last question: If you have no shared storage, how did you solve the default ticket number generator's dependency of TicketCounter.log file? A custom generator? /bogdan On Tue, Jan 29, 2013 at 10:01 PM, David Boyes <dbo...@sinenomine.net> wrote: > ** ** > > 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 >
--------------------------------------------------------------------- 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
