Hi David, this is very interesting. Would you be willing to share your code? I'd be interested at least in the SysConfig -> DB part. Making OTRS better cluster-able is definitely a goal for us.
Regards, mg Am 09.04.15 um 14:38 schrieb David Boyes: >> Which ' local file system' references are you talking about? > > Any time the code refers to a file on disk for configuration or operational > information instead of the database. My goal was to have the entire OTRS > system code (with the exception of the data it operates on) to be read-only. > I operate environments where truly read-only code can be efficiently > physically shared, and I wanted to take advantage of that. > >> There are just a few places where OTRS uses local file systems (session >> storage, attachments, VirtualFS which is used by Change >> Management) and all these also have options to use a database backend. >> Apart from that, there is the loader cache for which there is the >> '--generate' >> option now. >> There is also the SysConfig which is stored in a file on disk. > > Yes. Recent versions of the OTRS code are much, much better about not storing > node-specific code elements in external disk files (thank you!), which is why > I said my code would need updating. You weren't as careful about that in > earlier releases. > >> Did you store the minified JS and CSS files in the database? And the >> SysConfig values? that's nice but it might be a little bit over-engineered. > > OK. If it's not useful, then no harm done. I think at least the parts that > move sysconfig data into the database would be useful (one of the most common > problems I see here is caused by not regenerating that cache file), but no > big deal. > >> Also, >> the vast majority of OTRS users will not need clustered setups, and will use >> vertical scaling - bigger machines - or maybe break out the database server >> to a separate machine, and avoid all headaches that come with multiple >> master nodes. > > Here I would disagree. As people virtualize more and more of their > infrastructure, there is significant hard data that small numbers of bigger > machines perform much more poorly than multiple smaller machines and are much > harder to tune for performance. It takes a lot more work for a hypervisor to > manage a few big machines than multiple smaller machines (especially on Intel > architectures which are not optimized for this kind of thing). Consider page > table mapping, swap infrastructure for large VMs and balancing in-memory vs > file caching for big machines when you need to bring substantial numbers of > pages in and out before a machine can be dispatched efficiently. It really > does work out better in terms of system overhead in a shared resource > environment to have a horizontally scalable design than a vertically scaled > one. You also gain a measure of HA design that allows concurrent maintenance > if done properly (another common problem seen here is not having a way to do > rolling up > grades to avoid outages, which really needs to be present for > enterprise-grade services). > > Definitely break out the database server in any case, but I'd argue much more > strongly for well-behaved cluster performance than just throwing hardware at > the problem. Horizontal and vertical scaling aren't mutually exclusive if you > design for them properly. > > _______________________________________________ > OTRS mailing list: dev - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/dev > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev > -- Martin Gruner Senior Developer R&D OTRS AG Bahnhofplatz 1a 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel Schlanker, schneller und flacher denn je - OTRS 4! Und für alle, die MEHR wollen: Entdecken Sie hier die OTRS Business Solution™ mit mehr Business Features! https://www.otrs.com/otrs-business-solution-fuer-besseren-kundenservice/?lang=de _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
