Hi Dojo,
we use an alias "dms.customer.net" to access our DMS, that consists of multiple redundant DMAs that are only accessible via HTTPS. The virtual IP address of the DMAs are added to the alias on the local DNS server. We also configured round robin for this alias, so that we have some sort of request distirbution and connections are established to one of the vitual IPs of the DMS in a fairly unpredictable manner. So whenever a user connects to our DMS using "dms.customer.net" a secure TLS connection to one of the DMAs is established. This is working fine both for Cube and web access. We get a pretty good connection spread across the DMAs using this configuration.
As consecutive DNS requests from the same client are resolved to different virtual IP addresses of the DMAs - depending on the DNS configuration - we have the following symptons in DataMiner:
- In Cube we can typically see all available WebApps in the "Apps" sidebar. When we start a new Cube session this is sometimes the case, but sometimes not. In the past we figured out with help from Techsupport, that this is related to the use of the alias as there are separate DNS requests for the Cube startup and for the the check for availability WebApps. When we connect via a specific virtual IP address of a DMA pair or via its specific DNS name "dma1v.customer.net" everything is workign well and Web Apps are always shown. To mitigate this behaviour we increase already the TTL setting for the DNS record for "dms.customer.net". This improves the behavior, but from time to time this still occurs.
- When we are logged in to a WebApp, e.g. a Low-Code App using the URL "https:\\dms.customer.net\..." we can see the following behavior:
- When we are logged in after some time of inactivity the TLS session seems to expire and we have to refresh the connection and log in again. When we save the credentials during login this is done upon single click, but still the WebApp is reloaded and loads with its default/startup page. Also not all users want to store their domain credentials in their browser.
- On some pages in a Low-Code app we have a filter component (e.g. to filter a query to be show the filter results in a table). When we have set some filter values and are inactive for a while we again loose the session, have to reconnect (like above) and loose the filter settings. Especially when a specific view or only a subset of data is needed by a user for a longer period this can become very annoying.
Again when we log in via a specific virtual IP address of a DMA pair or via its specific DNS name "dma1v.customer.net" everything is working well and Web Apps are always shown, also session are kept open.
After detailed discussion with the IT department the very correct way to resolve the beforementioned issues would be to get rid of the round-robin DNS and add a load balancer appliance in between the clients and the DMS, that handles all connection requests to the DMS and supports client affinity. But such application comes with comparable high cost and additional configuration effort it is hard to give the rights arguments when there is a workaround availabel already and no budget available for such a solution.
How are other DMS with mutliple DMAs set up? Is there some DNS configuration we may haved missed to add client affinity to the DNS resolving process? We actually use Microsoft DNS for this task. As far as we know this does not support client affinity.
Many thanks in advance and best regards
Hi,
Towards the end user, it may look like the DMS has a single webpage, but actually, every agent has it's own standalone webpage. So, every time the DNS cache expires and a new DNS query is executed, the user will be connecting towards a different machine. This probably explains why filters in webpages disappear after refreshing the connection, since the user is now connected to a different Agent then before.
For the missing webpages in cube, I think the following is going on: Let's say the user is connected to Agent 1 via cube. By the time the webpages are retrieved, the DNS may have expired and now is pointing to a different Agent (Agent 2). Cube will try to retrieve the webpages from Agent 2 using a connection that is only valid for Agent 1, which means that the request to fetch the webpages will fail and Cube won't be able to retrieve the webpages.
I'm not sure, but I believe that a loadbalancer would be the best solution here. As you said, I don't think there is a possibility have some kind of client persistency on the DNS server.
Kind regards,