First of all, below is an example of what I mean by Multi Layer Environment:
Hub Connection Hub Connection Hub
PrimaryHub -> (NameServices) ProxyHub1 -> (Tunnel) CustomerHubA
PrimaryHub -> (NameServices) ProxyHub1 -> (Tunnel) CustomerHubB
PrimaryHub -> (NameServices) ProxyHub2 -> (Tunnel) CustomerHubC
PrimaryHub -> (NameServices) ProxyHub2 -> (Tunnel) CustomerHubD
The intention is to segregate the connections through the Proxy Hubs and avoid overload of the Primary Hub, besides the matter of different networks involved.
The communication between the PrimaryHub and the Proxies are made by NameServices because it is the same network (internal environment) and the CustomerHubs to the Proxies needs a Tunnel since they are different environments.
We actually have this configured already but we ran into a problem related to the discovery server way of working.
On the below article, it states the following:
- If there is NO tunnel, nametoip will return the actual IP/port of the robot itself on port 48000 and the discovery_server will try to connect directly to the robot - so this may fail if a) there is not route to the robot from the primary or b) there is no tunnel between hubs.
So basically, if there is no direct communication from the CustomerHub to the PrimaryHub we need a Tunnel configured? If so, it makes no sense to build a Multi Layer environment like we did, since it is impossible to communicate with all the customers networks directly without the ProxyHubs.
We bumped into this situation after finding out many monitored devices not displaying any metrics within the USM portlet on the UMP Portal, and the reason is because the Discovery Server probe seems to be trying to reach the robots through a directly communication and not using the tunnel instead (see logs on the article mentioned above).
If anyone could share any thoughts?