[opencms-dev] OpenCMS 8.5.2 in Cluster

[Sebastian Himberger]

That sounds pretty much awesome. Will this be open source? It sounds
like it won't but it would be nice.

2013/8/2 Stephan Hartmann <hartmann at metamesh.de>:
> 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
>>> 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
>>>
>>>
>>>
>> _______________________________________________
>> 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
>>
>>
>>
>
>
> _______________________________________________
> 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
>
>
>
>