Help! Our legacy modalities are awesome — but they don't understand DNS!

We've recently spoken to a number of hospital groups facing a growing issue with legacy modalities.

More and more of them are trying to connect remote hospital sites to central data centers for a variety of reasons, such as critical system redundancy and disaster recovery. This means load balancing between the sites becomes a necessity. To do this, Global Server Load Balancing (GSLB) is the go-to solution used to achieve this. But utilizing GSLB for legacy modalities isn't straightforward.

The customer was rolling out a brand new radiology system across multiple hospitals, and obviously needed high performance and high availability. To try and achieve this he was using the industry standard combination of load balancing techniques for high availability (HA) — several pairs of load balancers for local HA, paired with Global Server Load Balancing (GSLB) for multi-site resilience and failover. But it wasn't working, due to some infrastructure peculiarities I'll explain. So he asked me for help.

Here's an explainer of the issue and the workaround our team came up with...

What normally happens: DNS-aware modalities

Normally, when you're load balancing an application, you just point the clients at the IP address of the load balancer handling the application. And you would do this by modifying the application server's DNS record i.e. mydicomapp.myhospital.com -> VIP shared on a pair load balancers.

And then, typically, rather than using basic DNS, we would use our GSLB server to ensure that the IP address returned would take into account multi-site topology, location affinity and failover, combined with health checking, as shown below:

The result? High availability, performance and failover for a modern DNS capable modality is achieved relatively simply.

The problem: Legacy modalities not DNS-aware

But, as is often the case in the real world, hospital groups have some very old and very expensive legacy modalities that don't speak DNS. This means that in order to utilize DNS, they need to be hard coded with a DICOM server's IP address.

Now that's not really a problem as far as load balancing and performance is concerned — you can just hard code the virtual IP address of a DICOM cluster. But how is the hospital going to get high availability and failover without DNS capability?

Hospital groups don't have the budget to just go out and buy newer kit. They've already invested millions of dollars in their legacy modalities (for example, an MRI scanner can cost around $500,000, with a lifespan of around 15 years).

Thankfully, there's a pretty easy workaround that we've developed: using the load balancer as a DNS resolver proxy.

The solution: Using a load balancer as a DNS resolver proxy

How it works

It is possible to use a load balancer as DNS resolver proxy, and improve the reliability of current DNS environments, by making the lookup dynamic by default, with automated health checks.

This screenshot shows a simple example with a load balancer cluster configured to respond to DICOM requests and proxy the DICOM response from one of the two DNS records that are configured as backend servers:

Why use a load balancer as a DNS resolver proxy?

The benefit of this approach is that the backend servers then dynamically lookup their own address!

This kind of configuration allows older devices to be hard coded to connect to the Floating IP/VIP of a pair of load balancers for initial high availability.

The load balancers can then do a dynamic DNS lookup, to ensure that they forward the modality to the correct DICOM server.

What's so dynamic about it?

Well for a start, the load balancer keeps checking the DNS records every 10 seconds. So any record changes are picked up pretty quickly. Also, if you get several failed attempts it will actually mark the backend server as offline.

But, it's adding GSLB that really makes the difference...

GSLB using a DNS resolver proxy

Dynamic DNS lookups are handy for high availability. But for multi-site configurations, you might also want active-active with site affinity or active-passive failover. So how to you solve that particular problem?

Again, it's simple really. We usually run GSLB on the same load balancers that we use for the DICOM cluster. You then tell your primary DNS infrastructure to delegate requests to the GSLB i.e. dicom.mysite.com.

Now, in addition to the normal configuration, we simply tell the load balancer to use its local GSLB (127.0.0.1) for DNS lookups before it checks the primary infrastructure:

In this scenario, high availability, performance and failover of DICOM is achieved even when your ancient modality can't do a DNS lookup.

The network diagrams can get a bit messy

Because all of these services...

• Can run on a single load balancer instance
• All talk to each other local and across the network
• Also integrate with your existing DNS infrastructure.

....things can look very messy in logical and physical network diagrams.

For example, imagine your hospital has an old modality you're trying to get to talk to Exchange, with Layer 4 load balancing and GSLB. Things might look something like this:

The good news, is that once everything is configured, using a load balancer as a DNS resolver proxy is incredibly reliable and highly available.

Anyway, back to the GSLB configuration...

How to configure Global Server Load Balancing (GSLB)

Configuring GSLB may seem a little bit daunting the first time you do it. But its actually very easy. Firstly you'll need to decide on a global name for your application and delegate the control of that domain from your primary DNS infrastructure.

If you are using Microsoft DNS, then simply open the DNS Manager and create A records for each GSLB enabled load balancer in your domain i.e. dicom-primary-a, dicom-primary-b, dicom-secondary-a, dicom-secondary-b

Then create a New Delegation and using the wizard provide your subdomain i.e. dicom.mysite.com and add your GSLB's by their new FQDN's that you just created:

Then on the primary balancer on each site, you need to configure the GSLB with the same global name:

Then add the two members, i.e. the VIPs shared between the load balancer clustered pairs on each site:

Then configure a Pool with the two members, and a TCP health check on port 104:

Then define the data centers using subnet topology to ensure site affinity, because we want all traffic from the local site to stay on the local site when possible (saving on bandwidth costs, increasing performance and lowering latency):

Then, a few seconds after you restart the service, it will start responding to DNS requests for the domain.

So what's the end result? Did we solve the customer's problem? We sure did!

Here's an example which nicely illustrates the power of this solution.

Bringing all the magic together

In the screenshot below you can see an example where the DICOM_DNS_PROXY cluster just has one backend server (dicom.mysite.com). The sole purpose of this cluster is to lookup the local GSLB record for this domain, which returns the address of the best local DICOM cluster.

In this scenario, it's highly likely it will return the address of DICOM_CLUSTER_A (192.168.1.73), which is also hosted on the same load balancer:

That may have seemed like a lot of work, but think about the level of redundancy we have created!

We now have 2 data centers, 4 x GSLBs, 4 x DNS Proxies, and 4 x load balancers, enabling two highly available DICOM application clusters!

Moving forward: help for hospitals

Often hospital groups know exactly what they want to achieve, but doing so within the constraints of their existing network infrastructure and legacy systems makes that seem impossible. How they get from A to B is rarely straightforward.

Of course, they'd like to have DNS-aware legacy modalities to work with, but budgets don't always stretch to that ideal.

Thankfully, we're here to help.

This workaround, leveraging our Enterprise load balancer as a DNS-resolver proxy for GSLB, can help hospitals overcome this problem to achieve both high availability and disaster recovery across multiple hospital sites with legacy modalities.

Our engineers like to get to the heart of the problem, so if you've got a thorny problem, please give us a try. You might be pleasantly surprised by what we can do.