cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Platform registering into Zookeeper with wrong IP address

tcoufal
12-Amethyst

Platform registering into Zookeeper with wrong IP address

I have 3Node Zookeeper Ensemble running on 3 VMs. 

I have 2Node Application cluster running TW 9.1 and ConnectionServer on 2VMs each on the same VM (so 2 total).

Those VMs have 2 network interfaces (1 for administration and for any other traffic)

After platform has started I can confirm that it registers itself under (vie ZkCli.cmd):

/services/thingworx-https

Content of that Znode is:

 

[zk: localhost:2181(CONNECTED) 4] get /services/thingworx-https/68640d69-8959-4656-a5ba-36557f2a05e8
{"name":"thingworx-https","id":"68640d69-8959-4656-a5ba-36557f2a05e8","address":"172.20.75.223","port":443,"sslPort":null,"payload":{"@class":"com.thingworx.discovery.zk.ServiceInstanceDetails","attributes":{"PLATFORM_ID":"platform2"}},"registrationTimeUTC":1615373781104,"serviceType":"DYNAMIC","uriSpec":{"parts":[{"value":"address","variable":true},{"value":":","variable":false},{"value":"port","variable":true}]}}

 

And here lies the problem, it seems that platform registers itself with the first IP that finds on it self (so I assume). In my case it is the Admin network, which cannot be used for normal operation traffic. That network could be un-provisioned at any time. 

 

Only place that I can think off that would allow me to set it up correctly would be the paltform-settings.json the Clustered Mode Settings section, but there is no parameter that would serve such a purpose. 

 

Registering under wrong IP also leads to CxServer instances not working properly. They try to communicate to IP that is not reachable (since FW rules are applied on Interface basis and on admin network are much more strict), also that network can be un-provisioned at any time as I stated before. 

 

Anyone any idea how to solve this? 

 

1 ACCEPTED SOLUTION

Accepted Solutions

Hi@tcoufal ,

 

Can you review the following article :

https://www.ptc.com/en/support/article/CS326556

 

New environment variables (HTTP_ADDRESS and HTTPS_ADDRESS) have been introduced in 9.0.1 to avoid this behavior.

 

View solution in original post

3 REPLIES 3

Hi@tcoufal ,

 

Can you review the following article :

https://www.ptc.com/en/support/article/CS326556

 

New environment variables (HTTP_ADDRESS and HTTPS_ADDRESS) have been introduced in 9.0.1 to avoid this behavior.

 

View solution in original post

tcoufal
12-Amethyst
(To:smainente)

Hi, 

thanks, that is very helpful. 

It would be great if this is appended to TW 9 Help Center, not just in release notes. Also, there are some additional parameters that could be useful, but not documented at all.:

 

For ThingWorx High Availability Clustering, optional environment variables HTTP_ADDRESS and HTTPS_ADDRESS that impact service discovery were added. For more information, see Configuring ThingWorx Foundation for Clustering. Optional platform settings IgnoreInactiveInterfacesIgnoreVirtualInterfaces, and HostAddressFilter were also added. For more information, see Platform Settings for ThingWorx HA. 

 

Thanks again. I will try it.

Thanks for the feedback. I will report to the documentation Team.

 

 

Announcements