When you need better performance, stability and availability for your OpenCms installation, you should think about setting up a cluster. There are many pieces in this puzzle, and OCEE is just part of the solution. This session will describe a simple but robust cluster architecture for OpenCms. Insights how a cluster with just 2 OpenCms instances can be configured to handle websites with many page views will be provided. Also some useful open-source tools will be shown that help in the setup and maintenance of an OpenCms cluster.

1. 13.10.2015
Filip Kratochvil
NELASOFT Technologies, s.r.o.
Robust OpenCms cluster setups

2. 1
About me and our company
Filip Kratochvil
• Web consultant and OpenCms template developer
• Works with OpenCms almost 5 years
• Technical enthusiast, you can find me on LinkedIn or Twitter
NELASOFT Technologies, s.r.o.
• Based in Prague, Czech Republic, small company up to 10 people
• Focused on creating mid-size webapps based on OpenCms
• Sometimes we develop custom Java webapps

3. 2
Summary
• why do you need a cluster?
• architecture and software overview
• Alkacon OCEE Cluster package
• pros and cons + statistics
• questions and your experience

4. 3
Architecture - basic overview
• Requests are sent to the loadbalancer
and he splits them (using set of rules)
between application servers
• Application servers use same
database, so replication isn’t needed

5. 4
Architecture – deeper insight
• All servers must be duplicated for
High Availability
• Loadbalancers and database
uses primary/secondary mode
with floating IP
• Consistency between application
servers is ensured by Alkacon
OCEE Cluster package
• At database layer we use DRBD
cluster

6. 5
Software
Loadbalancers
• HAProxy (http://www.haproxy.org/)
• Heartbeat for floating IP (http://linux-ha.org/wiki/Heartbeat)
Application servers
• Apache HTTP Server
• Apache Tomcat
• OpenCms + OCEE cluster package
Database servers
• MySQL + DRBD cluster (http://drbd.linbit.com/)
• Heartbeat for floating IP

7. 6
Setting tips
Loadbalancers
• Balancer should hold user on the same physical server for every request, so you
need to setup „sticky session“
Application servers
• Use 2 network cards per 1 application server if it is possible. One for standard traffic
and one for communication between aplication servers using OCEE
Database servers
• MySQL + DRBD cluster (http://drbd.linbit.com/)
• Heartbeat for floating IP

8. 7
Statistics
Each application server have quad-core CPU with 24GB RAM
• 500 000 unique users/month
• 1 100 000 visits/month
• 3 100 000 pageviews/month
It can handle more than 6 500 users/hour or more than 300 concurrent users in the
maximal load.

9. 8
Performance tips
• Flex cache
• Static export
• OCEE Accelerator
• Revisit your dynamic components and scheduled jobs
• Increase RAM size and CPU power
• Add another application nod in to the cluster

10. 9
Pros and cons
PROS +
• good performance and availability
• simple solution with quite easy setup
• Alkacon OCEE Cluster Package offer more usable modules
CONS –
• you need to switch workplace server manually (OCEE)
• logged users are not present on the second machine during the crash,
you need to setup session replication on Tomcat (we didn’t do that:)

11. 10
Future
• Using of OCEE Replication
• Tomcat session replication setup
• Auto-switch when workplace server goes down (using script?)
• Custom cluster module development (event forwarding)

12. 11
Questions

13. Contacts
Filip Kratochvil
filip.kratochvil@nelasoft.cz
NELASOFT Technologies, s.r.o.
info@nelasoft.cz