[opencms-dev] OpenCMS 8.5.2 in Cluster

Mon Aug 5 15:50:29 CEST 2013

Hi Sebastian,

As we announced last year on OpenCms Days 2012, our goal is to support
organizations and service providers to provide OpenCms as a Service (SaaS)
with the highest level of elasticity and service automation.

For this reason Stephan developed OpenCms Cloud Extensions, which is using
other open source components and data grid platforms which are currently
under other licensing modes and we have to examine till OpenCms Days 2013
if and how we can provide the whole thing as open source.

But for now, if someone would like to see the whole thing in action, or
would like to test our cloudified version of OpenCms 8.5.0 with
Multi-Workplace support, we would be more than happy to grant access to our
development and testing environment, please feel free to drop me an email.

Kind Regards,
Arash

-- 
CSG CloudSites powered by Metamesh's OpenCms Cloud Extensions
<http://www.cloudssky.com/en/cloud_products/cloudsites.html>
 <http://www.cloudssky.com/en/cloud_products/cloudsites.html>

 *________________**____________**   **  *

*Arash Kaffamanesh**
Clouds Sky GmbH
*

*Im Mediapark 4C*

*50760 Köln
*
+49 221 370 90 680
www.cloudssky.com*
_________________**___________*

On Sat, Aug 3, 2013 at 11:09 AM, Sebastian Himberger <sebastian at himberger.de
> wrote:

> 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
> >
> >
> >
> >
> _______________________________________________
> 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-d<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/c2031e15/attachment.htm>