[opencms-dev] OpenCMS 8.5.2 in Cluster
Achim Westermann
achim.westermann at gmx.de
Sat Aug 3 16:13:47 CEST 2013
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
>
>
>
More information about the opencms-dev
mailing list