We are having a major issue with getting EPiServer to work over loadbalanced servers.
We have followed the steps in the following article by Allen Thraen “Load Balancing in 6 Steps” (http://labs.episerver.com/en/Blogs/Allan/Dates/112230/11/LoadBalancing-in-6-steps/)
We have had the listening/broadcasting tool developed listening on both servers for changes – is appears that when we update anything on the CMS aspects of the site e.g. publishing new pages etc... we can see the activity in the listening tool.
However, if we change any of the community aspects (creating new blogs, updating user profiles, forum posts) we can’t see anything within the listening tool, and as a result we have items that are being created/changed on one server, that are not visible on the other.
Does the loadbalancing work with the community aspect within relate+? Can anyone point me in the direction of the EPiServer Community Deployment Documentation?
Any luck getting this resolved? We're working on a large Relate+ implementation and i'm keen to avoid this issue.
Not yet, I placed a support ticket in with EPiServer last week and we are waiting for a response, as soon as I hear anything I shall update the thread.
The CMS and Community platforms currently operate on two separate frameworks, hence the detection of happenings on one does not mean the detection of happenings on the other.
Operating Community in a load-balanced environment was covered in earlier documentation. Unfortunately the relevant sections seems to have become detached in the latest documentation - this is currently being corrected.
I will therefore provide you with a preliminary version of the new documentation - see below:
1) The Cache Replication System
Required Framework Components contains functionality to clear cached data on all remote nodes in a web cluster when that data is cleared locally; this is to make sure that the cached data on all nodes is kept synchronized when changes are made. To do this, special UDP datagrams are broadcasted to all nodes.
A replication section exists in the web.config for a newly installed community site, which will allow custom settings to be made.
Initially, this replication section looks like:
<replication> <subscriber serverName="myWebServer1" siteName="mySite" port="0" alternatePort="0" broadcastAddress="192.168.0.255" /></replication>
Port and AlternatePort in the configuration file are the UDP ports that it will try to listen to and send requests to. In reality only one of these ports is bound to, the reason why two ports are configured is that when the application is recycled it may not be possible to reclaim the same port.
BroadcastAddress should be set to the broadcast address for a locally connected network that all nodes are reachable on.
Noting: If Port or AlternatePort are set to 0, cache replication is disabled.
2) Running multiple EPiServer Community instances on the same server
When running multiple instances on the same server, Port and AlternatePort should, unless set to 0, be different for each instance. If, several instances run on a server with the same ports configured errors will occur on startup and all instances will not be able to bind their configured ports.
3) Running EPiServer Community in a Web Cluster
When running EPiServer Community in a web cluster you need to share the content of the ImageGallery and DocumentArchive directories between all web servers in the web cluster. These shared directories can be located anywhere as long as they are accessible (with read and write permissions) by all web servers in the cluster.
EPiServer Developer Support Team