Question regarding DataMiner Failover with Virtual Hostname over Layer 3 WAN

58 views
3
0 Comments

Hi,

We are currently designing a redundant DataMiner setup across two geographically separated sites connected only via a Layer 3 WAN connection.

in this scenario, the recommended approach is to use a **Virtual Hostname** instead of the traditional **Virtual IP** mechanism.

The proposed architecture would be:

Site A:

* DataMiner Agent (Primary)
* Local IP: 10.x.x.x

Site B:

* DataMiner Agent (Backup)
* Local IP: 10.y.y.y

Both sites are connected via Layer 3 WAN only:

* No Layer 2 connectivity
* No shared Virtual IP
* No MAC address takeover

Additionally, a third site could host the shared Cassandra and OpenSearch databases, accessible from both DataMiner sites.

We would like to better understand how this solution works and whether our understanding is correct.

Could you please clarify the following points?

1. Is this architecture officially supported by Skyline?
2. Is DataMiner Failover using a Virtual Hostname fully supported across a Layer 3 WAN?
3. Do the Primary and Backup agents still form a traditional Failover pair and therefore use the same DMA ID?
4. How does the Virtual Hostname mechanism work internally?

* Is it based on DNS updates?
* Is it managed by DataMiner itself?
* Does it require DataMiner Services / Cloud Gateway?
5. How do Cube clients and Web Apps reconnect after a failover?
6. Are there any network prerequisites or limitations (latency, routing, DNS requirements, etc.) for this type of deployment?
7. Could you provide any documentation or best practices regarding this architecture?

We are trying to determine whether this approach can replace the traditional Virtual IP-based Failover in an environment where only Layer 3 connectivity is available between the two sites.

Thank you in advance for your clarification.

Jarek Burtny

Bert Buysschaert [SLC] [DevOps Advocate] Answered question

1 Answer

2
5.24K 0 Comments

Hi Jarek,

I will try to answer your questions:

  1. Is this architecture officially supported by Skyline?

Yes

  1. Is DataMiner Failover using a Virtual Hostname fully supported across a Layer 3 WAN?

Yes, as long as all clients and all agents in the cluster

  • can communicate with both IPs 10.x.x.x and 10.y.y.y
  • resolve the shared hostname to exactly these 2 IPv4 addresses.
  1. Do the Primary and Backup agents still form a traditional Failover pair and therefore use the same DMA ID?

Yes

  1. How does the Virtual Hostname mechanism work internally?

It is based on having a DNS entry where a hostname resolves to 2 IP addresses:

<code>dma.example.com.    IN    A    10.1.1.1
dma.example.com.    IN    A    10.2.2.2</code>

Unlike failver with a virtual IP, where the network layer transparently handles the routing of traffic to the online agent based on the IP ↔ MAC address mapping, the clients must be aware of the multiple IP addresses and they are responsible for determining which one of the 2 is the online agent (see question 5).

  • Is it based on DNS updates?

No, the DNS configuration is a one-time thing and static.

  • Is it managed by DataMiner itself?

No, you need to configure the DNS entry yourself.

  • Does it require DataMiner Services / Cloud Gateway?

No.

  1. How do Cube clients and Web Apps reconnect after a failover?

For desktop based clients such as Cube, using SLNetTypes.dll, the client performs DNS resolving (through the OS) and is aware of both IP addresses. Each time when connecting to an agent, it will try the first IP and if that fails, it will try the second IP.

For web-based clients, the browser does DNS resolving and will try each IP address until one responds. The difference is that a webbrowser will be satisfied as soon as an IP address accepts a TCP connection. Under normal operation, both the online and the standby agent in the failover pair will respond. For this reason DataMiner on the standby agent will activate an IIS rewrite rule to act as a reverse web proxy towards the online agent so that all web requests are handled by that agent. This rewrite rule is automatically (de)activated on performing a failover switch. So after a failover switch, a client may keep communicating with the same IP address but have its requests forwarded transparently to the other IP address. Only when the standby agent is taken offline (e.g. hardware maintenance) will the browser detect that the IP is no longer reachable and then switch to the other IP address.

  1. Are there any network prerequisites or limitations (latency, routing, DNS requirements, etc.) for this type of deployment?

On all nodes that partake in communication (clients and dataminer agents), the shared hostname should resolve to exactly 2 IPv4 addresses.
Keep in mind that for web applications the latency of the client to the server may be increased with the latency between the 2 agents.

  1. Could you provide any documentation or best practices regarding this architecture?
  • Make sure DNS is configured correctly, this is essential.
  • When using HTTPS, make sure both agents have a certificate for the shared hostname, and optionally for their own unique hostname and/or IP.
  • If you were to put a reverse proxy or load balancer in front of the failover pair for any reason, be aware that that software should have its own detection mechanism to determine which of the 2 agents is the online one, for example by looking at the contents of http(s):///logging/FailoverStatus.txt

Let me know if you have further questions.

Bert Buysschaert [SLC] [DevOps Advocate] Answered question