[opencms-dev] OpenCMS 8.5.2 in Cluster

Fri Aug 2 16:49:00 CEST 2013

Hi

Georgi is leading into the correct direction, but he is missing the Core
Cache and some other caches (e.g. image cache) that spread across OpenCms,
as well as OpenCms' event system.

But the main problem in using a distributed cache like Ehcache ist that
cached objects have to be serializable. Otherwise they cannot be
transferred from one JVM to another. Most Objects that are cached in the
core cache are serializable, but the Flex Cache entries aren't.
Another problem is with singleton objects. While in a single JVM
application it is legal to compare singleton objects (or better references
to singleton objects) with == and != (but you still shouldn't), it brings
up problems in distributed applications where each instance has its own JVM
and thus their own "singleton" objects. When those objects are serialized
on one VM and deserialized on another, they are different from their
counterparts on that VM. Instead you have to use equals() or if they box
primitives compare those primitive values instead.
Sadly some core cache objects in OpenCms are singletons and in some places
equality and inequality of references to those objects are checked with ==
and !=.

The other way to cluster OpenCms is to let all instances keep their own
caches and send flush notifications on publish events to all the other
nodes, if one instance manipulates the underlying database entries of
cached objects. I guess this mainly is what other solutions do - and Achim
on request by hand ;).
One drawback of this approach is, that you can access the workplace and
offline project only through one node that is the master and propagates his
publish events to the slaves.
If the master goes down, you are not able to edit your website.

Together with Arash Kaffamanesh from Clouds Sky I am currently working on a
cloud-ready and thus distributable and cluster-ready version of OpenCms
(based on 8.5.0) that follows the first approach with a distributed cache
where possible.

Our goals are:
- unlimited number of cluster nodes
- auto-discovery
- autoscaling (up and down)
- auto-recognition of new nodes
- zero configuration (or at least identical configuration): all instances
have the same configuration, that's true also for OpenCms configuration
- no master/slave design - all nodes are equal
- fault tolerance - removing one node won't hurt others. this implies that
every node can serve the workplace at ANY time with sticky sessions

So far we have a distributable core cache and propagation of OpenCms events
to all active cluster nodes.
Thus, the core cache won't have to be flushed on publish events and the
Flex cache will flush online on all nodes on publish events just as usual.
Even static export on demand is working.
We have haproxy in front with sticky sessions, and we are able to access
the workplace just through it - no matter to which node haproxy is
directing on session creation. In the broadcast admin tool, we see all user
sessions and can send messages to all users.

All instances can startup the same from image image, i.e. a webapp that is
copied from a template, or a complete vm image.

We also wanted to be able to perform module updates much faster and more
reliable than it is possible with OpenCms' admin interface.
Therefor we are developing a driver that reads modules (at least our own)
and their contents directly from the real file system. Now when we have an
update we just have to deploy it to our template folder, update the nodes
with rsync, git or whatever and restart tomcat / reload the webapp. If you
do this one after another there won't be a downtime at all - only your
workplace users will lose their session.
No periods of unavailability of your website during module updates anymore!
As a side effect, we could also reduce our development time for our own
modules as well! No more time wasting module uploads, rfs/vfs
synchronization or coding JSPs in the browser ;)

As Clouds Sky is a silver sponsor of OpenCms days 2013, we are planning to
do a presentation there and hopefully get everything ready until then to
show how OpenCms can autoscale on Amazon EC2 or Eucalyptus.

Best regards,
Stephan

2013/7/31 Georgi Naplatanov <gosho at oles.biz>

> Hi
>
> I think that running OpenCms in a cluster won't be a problem if:
>
>  - you use 1 db server or all db servers use synchronous replication
>  - some parts of application folder are shared between all OpenCms
> instances (Samba or NFS), like /export/ folder
>  - network enabled FlexCache cache implementation, like Ehcache.
>
> As Achim mentioned in this list, OCEE module is not expensive (at least
> for western Europe standard), so you may decide to do something else.
>
> Best regards
> Georgi
>
>
> On 07/30/2013 06:13 PM, jmcl wrote:
>
>> I would like to use OpenCMS in cluster.
>> All I need to do is use it in a scenario where *no* content is served from
>> the export folder. All content is served directly from the OpenCMS web app
>> and is, if necessary, cached on a external cache engine like Varnish.
>> I understand that having two OpenCMS nodes may cause problems when it
>> comes
>> to *adding* or *changing* content (at least I think there can be
>> problems).
>> Now, as for *serving* content would this be a problem???? I don't seen
>> what
>> problems can arise from having two OpenCMSes running at the same time, as
>> web apps that they are, and externally balanced.
>> Any comments on this, that don't directly involve the OCEE module, are
>> welcome.
>> Regards.
>>
>> J.
>>
>>
>>
>> --
>> View this message in context: http://opencms.996256.n3.**
>> nabble.com/OpenCMS-8-5-2-in-**Cluster-tp23501.html<http://opencms.996256.n3.nabble.com/OpenCMS-8-5-2-in-Cluster-tp23501.html>
>> Sent from the OpenCMS mailing list archive at Nabble.com.
>> ______________________________**_________________
>> This mail is sent to you from the opencms-dev mailing list
>> To change your list options, or to unsubscribe from the list, please visit
>> http://lists.opencms.org/cgi-**bin/mailman/listinfo/opencms-**dev<http://lists.opencms.org/cgi-bin/mailman/listinfo/opencms-dev>
>>
>>
>>
>>  ______________________________**_________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/cgi-**bin/mailman/listinfo/opencms-**dev<http://lists.opencms.org/cgi-bin/mailman/listinfo/opencms-dev>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20130802/b087c9b6/attachment.htm>