[opencms-dev] OpenCMS 8.5.2 in Cluster
Stephan Hartmann
hartmann at metamesh.de
Mon Aug 5 17:34:12 CEST 2013
Hi Achim,
indeed a special case which I wouldn't expect in real life. What would you
expect to happen on a single server installation? It wouldn't be different
I think.
We can try it out on OpenCms Days ;)
Best regards,
Stephan
2013/8/3 Achim Westermann <achim.westermann at gmx.de>
> Hi Stephan,
>
> sounds interesting. A very special situation: Did you figure out what
> happens if two editors are connected to different workplace servers and
> both create a file with the same path/name and publish almost exactly at
> the same time?
> Hope I can see you there,
>
> Achim
>
>
> On 08/02/2013 04:49 PM, Stephan Hartmann wrote:
> > 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 <mailto: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>
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20130805/4c47181d/attachment.htm>
More information about the opencms-dev
mailing list