ActiveGate redundancy, in DMZ, with Dynatrace Managed

[fstekelenburg]

With Dynatrace Managed:
In case we need to set up two Cluster ActiveGates in DMZ for redundancy purpose, still having the functionality for like when one AG is down, or internal DC link failover is at hand, what is the scenario and what needs to be configured; with the following constraints: no load balancer, no reverse proxy.

Is this supported?

Do we need two public IP (I think so, because firewall can not port forward/nat same port to two internal IPs)?

Can we use one public URL (and cert), and configure on both AGs? Or do we need two?
Will Agentless RUM (external) support this?

Bonus question: Can an F5 solution be used instead of LB/reversed proxy?

[Julius_Loman · Accepted solution]

F5 can be definitely used as a LB/reverse proxy in front of Cluster ActiveGates. We do have several customers using F5 for this. Then you can do SSL termination on F5 and you don't have to touch the Cluster ActiveGates for certificates. If you have F5 in place, I would recommend to use it unless there is a good reason not to.

Supported is only one DNS entry for the Cluster ActiveGate. It may have multiple IP addresses, but this kind of high availability depends on the clients - if they try to use different IPs in case one is not reachable.

Actually in default setup if you have Dynatrace certificates (your cluster is at *.dynatrace-managed.com), then another public hostname, including certificates for your cluster activegates will be automatically generated pointing to your ActiveGate. I did not try that with multiple Cluster ActiveGates, so I'm not sure here.

[fstekelenburg]

Thank you, and congratulations with your award 🙂

[fstekelenburg]

So, without F5 or any load balancing, we would have 1 DNS entry (e.g. dmz-ag.customer.env), with 2 public IPs (one for every AG). And clients connecting classic way round robin to any of the IP addresses configured for the DNS, that is reachable.

I think I agree that if F5 is available, that is a neater way to go.

[jhem]

Hi Frans,

The only drawback from using a DNS load balance is that clients usually cache the result of their DNS queries. Once an IP is resolved, the client will stick to this address for a while and switching to the next IP depends on the client implementation.

That's true for browsers, but I'm not sure how DynaTrace agents handle this. Even worse, some operating systems will keep their own cache independent from any application behavior. Just be aware of potential issues.

[fstekelenburg]

Hi Julio, thanks. That is indeed a drawback to take in consideration.

[rmeli]

We do exactly this of having an F5 in front of our Cluster ActiveGates with SSL termination. Works fine.

[jonas_m]

Hi, my friend.
can you ask me a question

How did you configure the URL within Dynatrace? Used port 9999 or 443

https://activegatecluster.domain.com:9999 or 443?

[fstekelenburg]

That is up to you, your implementation. Where is your activegate (or LB) reachable from the outside. But if it is for outside traffic, I strongly suggest to have it running on port 443.
I experienced that port 9999 is generally not a standard port allowed from within corporate networks, which would mean that endusers behind firewalls will not be able to connect to cag:9999 and therefor no RUM data will be collected if you do not work with oneagent, and use the Agentless RUM method with code/JS tag in the web pages.