Server communicating with agents on different networks

Benethor

hello,

I did setup at first a server and an agent within the same network. Everything works well.

Now, in our real testing environment, each environment has its own fenced network. I only have access to a gateway address and cannot see each VM individually. I can however create port forwarding (NAT) rules.

Do you have any documentation that details the communications between the agents and the server. I need to know the communication flow and what ports are used.

Can the product support a setup like this?

Thank you

Benethor

After some experimentation, the configuration of the agent seems "embeded" into de deployement file when it's generated from the server.

Can you confirm that I have correct understanding. Can I override that configuration with the server's network gateway address? I believe if I implement that correct port forwarding, this would work.

Mark R

All the connections between the server and the agent are outgoing TCP/HTTPS connections from the agent to the server on port 14146. Is that enough for you to set up port forwarding to get it working?

Benethor

Mark R wrote: »

All the connections between the server and the agent are outgoing TCP/HTTPS connections from the agent to the server on port 14146. Is that enough for you to set up port forwarding to get it working?

I need to be able to manually configure the agent to a network gateway ip address where server would be hosted. That advanced configuration feature used to exist when I refer to the doc of beta version. It seems to be removed in the latest version I downloaded. Can you bring it back? This would probably solve part of the issues.

Another thing : It is possible to have multiple agents on VM with the same name that would reside on different environnement (networks). So, simply using a name to identify an agent would not be enough. To be unique, it would need to be a combinaison of the VM name and of the network gateway address.

Allow me to illustrate the problem with an example.
I have 3 environments in 3 distinct networks:
1. Env-A.
Contains SQL Clone Server (internal IP: 172.100.100.10)
Network Gateway IP 192.168.250.1
Port Forwarding rule : external -> 172.100.100.10 on port 14146
2. Env-B
Contains SQL Clone Agent 1. (VM name: mySQLServerName1; internal IP: 172.100.100.11)
Network Gateway IP 192.168.250.2
3. Env-C
Contains SQL Clone Agent 2. (VM name: mySQLServerName1; internal IP: 172.100.100.11)
Network Gateway IP 192.168.250.3

As you can observe, Env-B and C are identical copies. I can only differentiate it by its network gateway IP.
One last thing, the agents in Env-B and C cannot automatically detect the SQL Clone Server since they are on different networks. I need to be able to manually configure the agents to point it to Env-A gateway (192.168.250.1).

I hope this help.
Thank you for your help.

Mark R

Thanks, that's helped me understand the situation.

A quick fix that would work with the current release would be to add an entry in the hosts file on the machines you're going to install the agent on that points the server URL to the gatway IP.

We could easily add a command line option to the installer to override the server URL - would that be an acceptable solution for you?

Benethor

Good idea.

This would certainly help with the traffic routing between the agents and the server if I have the opportunity to override the server URL.

I will try with the host file work around in the meantime.

Now, the only element I need to test is how the server would behave having 2 agents with the same name. I will let you know how this turns out.

Thank you for your help.

Benethor

The host file workaround is doing the job in the meantime. I did get the agent to communicate with its server. I did provisioned a clone. A cleaner way to register the agent (as described in your last post) would be even nicer.

I also tested two environments with the same server name inside. This is when things get messy.
The agents table in the SQLClone database, I end up with 2 agents with same name (see attachment). This does break the server but is does create some confusion. When I cloned a database, the first agent did the job. The second one did not do anything.

If I had a mean to supply a unique ID to my agent at registration time instead of automatically using the server name, I thing this would work.

Let me know if those are features you would consider introducing in a near future release.

Thanks again for your help Mark
David