Remote events in a load balanced setup

Vote:
 

Hi!

I am having some trouble getting remote events to work in a load-balanced environment. I have found several psts that describe this topic, but I only managed to find examples for EPiserver 5-6 and I am using Episerver 7.5 (episerver 8.11).

We only have 1 website in Episerver and use different language versions of each page. No multi-site setup.

Our setup is as follows:

Webserver #1
- dev.customer.dk
- dev.customer.de

Webserver #2
- dev.customer.dk
- dev.customer.de

Both IIS sites on webserver #1 share website rootfolder.
Both IIS sites on webserver #2 share webste rootfolder.

This is my configs: (changed IPs and names)
Webserver #1:


	
		
	      
	
		
	 


  
        


  
	
	  
	
  

Webserver#2:


  
	
  
  
	
  


  
  
        


  
	
	  
	
  

For some reason the remote events works just fine for the .dk-site but not for the .de site.

Any help would be much appreciated!

Best regards
Jesper

#138938
Sep 23, 2015 20:41
Vote:
 

If I only run with 1 endpoint, it works just fine for the .dk site, but once I start adding <service> and/or <endpoint> elements to my web.config I start getting these errors:

Server#1

Could not connect to net.tcp://server#2-ip-address:5001/RemoteEventService. The connection attempt lasted for a time span of 00:00:01.0312723. TCP error code 10061: No connection could be made because the target machine actively refused it server#2-ip-address:5001. 

I've tried to set the timeout higher (1 minute), but it still doesn't help.

I've used the remoteventlisterner test-tool to verify that the specified ports are open - they are just fine.

I've tried to disable windows firewall (public, private, domain), doesn't help.

If I wait for 30 secs - 1 minute, it seems that the majority of the remote events gets through, and the sites are updated correctly.

Anyone had any luck with a similar situation? (Multiple IIS-sites that share physical website root)

Best regards

Jesper

#139225
Edited, Sep 27, 2015 11:38
Vote:
 

If you share root folder this means that you only need one port per server. Both sites will be in the same process and share the same cache, i.e. only one port needed.

Now, you should consider separating broadcaster and listener for clarity:

On which server is the Episerver UI going? Typically you set it up as a three-server solution, with a dedicated server to serve editors and admins as well as run scheduled jobs. This is the only server where content can actually be changed. Often this server is on the corporate network while the fronts are on DmZ. This is both for security reasons and for performance.

You _can_ have both servers as broadcasters and listeners at the same time but I would not recommend it if it's a publicly facing site.

To make things more clear, have one service definition using localhost and one client definition with the IP of the other server. Also, and here's the killer, you need to use the logical site name in the client definition - not the site url. It's easy to confuse the two. Here's where you find the site name:

Site name

So, webserver #1 should have a definition like this: (assuming that site name is customer)

<services>
    <service name="EPiServer.Events.Remote.EventReplication">
        <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding"
          address="net.tcp://localhost:5000/RemoteEventService" binding="netTcpBinding"/>
    </service>      
</services>
<client>
  <endpoint name="customer-10.11.12.14" address="net.tcp://10.11.12.14:5000/RemoteEventService" binding="netTcpBinding"
    bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication"/>
</client>
<bindings>
  <netTcpBinding>
    <binding name="RemoteEventsBinding" portSharingEnabled="false">
      <security mode="None"/>
    </binding>
  </netTcpBinding>
</bindings>

Webserver #2 should have a definition like this:

<services>
    <service name="EPiServer.Events.Remote.EventReplication">
        <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding"
          address="net.tcp://localhost:5000/RemoteEventService" binding="netTcpBinding"/>
    </service>      
</services>
<client>
  <endpoint name="customer-10.11.12.13" address="net.tcp://10.11.12.13:5000/RemoteEventService" binding="netTcpBinding"
    bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication"/>
</client>
<bindings>
  <netTcpBinding>
    <binding name="RemoteEventsBinding" portSharingEnabled="false">
      <security mode="None"/>
    </binding>
  </netTcpBinding>
</bindings>
#139229
Sep 27, 2015 22:27
Vote:
 

Hi Johan

Thanks alot for your input!

I like your suggestions regarding splitting up the responsibility between servers in the DMZ and on the corporate network, however, I am not sure whether I will be able to get the network architecture changed now. For the time being, we have both servers as listeners and broadcasters.

I tried your solution and it works fine for the .dk site, but if I try to navigate to the .de site I get the following exception:

There is already a listener on IP endpoint 0.0.0.0:5001. This could happen if there is another application already listening on this endpoint or if you have multiple service endpoints in your service host with the same IP endpoint but with incompatible binding configurations.

Maybe portsharing could solve the error? Not sure whether to use it for multiple IIS websites, sharing same physical path or if its only for enterprise setups with separate physical folders?

Best regards

Jesper

#139234
Sep 28, 2015 8:34
Vote:
 

So I think we managed to solve this with the assistance of the EPiServer tech-support.

What seems to be working for us is the following:

- AppPool: Disable overlapped recycle: true
- Enable net TCP port listener service + net tcp listener adapter service
- Ensure endpoints in config is named {IIS WEBSITE NAME}-{IP}
- Enable TCP portsharing
- Change firewall rules ot allow traffic on port 808

This is the working config (server#1 - vice versa for server#2):

<services>
    <service name="dev.customer.dk/EPiServer.Events.Remote.EventReplication">
        <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding"
          address="net.tcp://10.11.12.13/RemoteEventService1" binding="netTcpBinding"/>
    </service>      
    <service name="dev.customer.de/EPiServer.Events.Remote.EventReplication">
        <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding"
        address="net.tcp://10.11.12.13/RemoteEventService2" binding="netTcpBinding"/>
    </service> 
</services>
<client>
  <endpoint name="dev.customer.dk-10.11.12.14" address="net.tcp://10.11.12.14/RemoteEventService1" binding="netTcpBinding"
    bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication"/>
  <endpoint name="dev.customer.de-10.11.12.14" address="net.tcp://10.11.12.14/RemoteEventService2" binding="netTcpBinding"
    bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication"/>      
	
	<endpoint name="dev.customer.dk-10.11.12.13" address="net.tcp://10.11.12.13/RemoteEventService1" binding="netTcpBinding"
    bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication"/>
  <endpoint name="dev.customer.de-10.11.12.13" address="net.tcp://10.11.12.13/RemoteEventService2" binding="netTcpBinding"
    bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication"/>      
</client>
<bindings>
  <netTcpBinding>
    <binding name="RemoteEventsBinding" portSharingEnabled="true">
      <security mode="None"/>
    </binding>
  </netTcpBinding>
</bindings>

Hope it helps someone!

Best regards

Jesper

#139393
Oct 01, 2015 12:19
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.