Show last authors
1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4
5 XWiki provides an easy way to setup clustered instances of XWiki based on network events distribution.
6
7 = Features =
8
9 * events synchronization between XWiki instances
10 * multiple clustering channels
11 * possibility to start/stop the clustering channel at runtime
12
13 = Setup =
14
15 == Enable event distribution ==
16
17 To enable event distribution in an XWiki instance go to ##xwiki.properties## file and set the property ##observation.remote.enabled## to ##true##.
18
19 == Setup communication channels ==
20
21 Then you need to create a JGroups configuration file for each different cluster group you want to setup.
22
23 For this go to the ##/WEB-INF/observation/remote/jgroups## folder and add one xml file by clustering group. Generally there is only one for a simple cluster.
24
25 See [[JGroups documentation>>http://www.jgroups.org/ug.html]] for more details on how to setup JGroups configuration files.
26
27 If you have IPv6 on your server, you are also advised to read [[this IPv6 article>>https://community.jboss.org/wiki/IPv6]]. Defining ##-Djava.net.preferIPv4Stack=true## when launching the JVM is probably your best bet in most cases. If your really want to use IPv6 for your channels, you should probably upgrade JGroup to version 2.10.0.GA and use a JVM 6 at least.
28
29 == Start communication channels ==
30
31 The name of the xml file matches the identifier of the channel.
32
33 To indicate which channels to start when XWiki starts list them in the property ##observation.remote.channels## of the ##xwiki.properties## file.
34
35 == Choose network adaptor implementation to use ==
36
37 By default only JGroups implementation is provided, but it's possible to add more. See the [[Remote Observation Module>>extensions:Extension.Observation Module Remote#HAddcustomnetworkadaptor]] for more details.
38
39 = Limitations =
40
41 The following limitations currently exist when you use clustering:
42
43 * [[XWIKI-6235>>https://jira.xwiki.org/browse/XWIKI-6235]]: The Scheduler feature is not cluster-aware and thus each node of XWiki runs its own scheduler and thus the same scheduler jobs will execute on all nodes. The workaround is to disable the Scheduler plugin on all nodes except on one. Note that this creates a [[SPOF>>https://en.wikipedia.org/wiki/Single_point_of_failure]]
44 * [[XWIKI-14722>>https://jira.xwiki.org/browse/XWIKI-14722]] If you use Filesystem-based attachments then you'll need to set up a shared filesystem that all nodes in the cluster can access. Otherwise only the node on which the attachment was added will see the attachment (it'll be broken on other nodes).
45 * [[XWIKI-11441>>https://jira.xwiki.org/browse/XWIKI-11441]] If a node is down and events happen, these events won't be propagated to the node when it comes back up. For example, imagine you install an extension on a node of the cluster while another node is down. When that node is restarted, the extension won't be installed on it.
46
47 = Performances =
48
49 * You may want to [[configure SOLR to use an external SOLR instance>>xwiki:Documentation.AdminGuide.Performances.WebHome||anchor="HStandaloneSolr"]] instead of having each node maintain its own SOLR index (even though that would work fine but you'd be less performant since each node would do the same work)
50 * See [[general performance page>>Documentation.AdminGuide.Performances]] for more ideas.
51
52 = More =
53
54 See the [[Remote Observation Module>>extensions:Extension.Observation Module Remote]] for more details of the event distribution features and extension capabilities.
55
56 Follow the [[test clustering tutorial>>Documentation.AdminGuide.Clustering.DistributedEventClusterSetup.WebHome]] for a complete tutorial on how to setup a simple cluster between two instances of XWiki on the same server.

Get Connected