Sunday, 13 April 2014

Simulating a GSLB DNS Load Balancing and Failover Configuration for File Access

Scenario

Currently client access to CIFS shares is achieved by accessing the share over a DFS Namespace, and the DNS entry in the DFS path to target folder is simply an A-record of a NetApp 7-Mode Filer/vFiler.

As part of a migration to Clustered ONTAP, we’re going to implement external DNS load balancing across a number of data LIFs owned by the SVM (Storage Virtual Machine.) Also, we’ve going to implement a GSLB (Global Site Load Balancing) mechanism to control site failover.

Note that the detail is intentionally light here.

In this post, we set out to simulate how the DNS side of it works simply using Windows DNS (time permitting; I might post about the client access, SnapMirror setup, failover, and behaviour during failover, at a later stage). First a little more explanation...

Client Access to the SVM

The following diagram hopefully demonstrates what we’re trying to achieve. The client accesses the share over a DFS Namespace. The DFS Namespace maps to a server share. The server name in the DFS path to folder target is a CNAME. This CNAME maps to an A-Record. And the A-Record contains multiple IP addresses (or more accurately - multiple A-Records with the same IP address.) And these IP address in the DNS A-Record relate 1-1 to Data LIFs on the SVM.

Image: Client access over DFS, showing how DNS works to reach our destination - the SVM
Site Failover

Site failover is achieved simply by updating the A-Records’ IP Addresses in the GSLB mechanism to point to the DR SVM and its LIFs.

Image: A-Records before failover pointing to the production SVMs Data LIFs
Image: A-Records after failover pointing to the DR SVMs Data LIFs
Simulating This in the Lab

I have a Windows 2008R2 AD Integrated DNS server (Domain Controller with DNS on), and a standalone, non-domain joined, Windows 2003 DNS server to simulate my GSLB appliance.

On the Windows 2008R2 AD DNS box, I create a CNAME for fileserver.lab.domain and this points to fileserver.gslb.domain:

Image: CNAME mapping fileserver.lab.domain to fileserver.gslb.domain

On the Windows 2003 DNS box, I create four DNS A-records each with a different IP address.

Image: DNSMGMT - 4 x A-Records for fileserver.gslb.domain (Production site IPs)
From the Windows 2003 DNS box, we can test our “load balancing” by pinging fileserver.gslb.domain:

ping fileserver.gslb.domain

Then do an:

ipconfig /flushdns

Then ping again and you’ll see the IP address changes.

Now, back on the Windows 2008R2 AD DNS box, we want to configure it to know what to do with DNS requests for the gslb.domain. Here we configure a conditional forward to the gslb.domain and point it to the Windows 2003 DNS box.

Image: New Conditional Forward to gslb.domain
Testing from the Windows 2008R2 AD DNS box, and we can now ping fileserver.gslb.domain. And if we do the ‘ipconfig /flushdns’ and ping fileserver.gslb.domain again, we are pinging another IP address.

And if we ping fileserver.lab.domain, it similarly works as desired, as we see from the abridged output below:

C:\Users\Administrator>ping fileserver.lab.domain

Pinging fileserver.gslb.domain [10.10.10.10] with 32 bytes of data:
Reply from 10.10.10.101: bytes=32 time<1ms ttl="254<o:p">

C:\Users\Administrator>ipconfig /flushdns

Successfully flushed the DNS Resolver Cache

C:\Users\Administrator>ping fileserver.lab.domain

Pinging fileserver.gslb.domain [10.10.10.102] with 32 bytes of data:
Reply from 10.10.10.102: bytes=32 time=1ms TTL=254

C:\Users\Administrator>ipconfig /flushdns

Successfully flushed the DNS Resolver Cache

C:\Users\Administrator>ping fileserver.lab.domain

Pinging fileserver.gslb.domain [10.10.10.103] with 32 bytes of data:
Reply from 10.10.10.103: bytes=32 time=1ms TTL=254

C:\Users\Administrator>ipconfig /flushdns

Successfully flushed the DNS Resolver Cache

C:\Users\Administrator>ping fileserver.lab.domain

Pinging fileserver.gslb.domain [10.10.10.104] with 32 bytes of data:
Reply from 10.10.10.104: bytes=32 time<1ms ttl="254<o:p">


Note: The only reason why we’re doing ipconfig /flushdns here is because we’re testing from just one client. If we had four clients and pinged fileserver.lab.domain in turn, we’d get four different IP Addresses.

So, that’s great! Now what happens when we update the A-records on the Windows 2003 DNS box as below:

Image: DNSMGMT - 4 x A-Records for fileserver.gslb.domain (DR site IPs)
After clearing the cache on the Windows 2008R2 AD DNS box -

Image: DNS Manager - Clear Cache
- and using ‘ipconfig /flushdns’ and pinging fileserver.lab.domain to test, we get our 4 DR site IP Addresses which is exactly what we wanted. Our site has failed over successfully in DNS!

C:\Users\Administrator>ping fileserver.lab.domain

Pinging fileserver.gslb.domain [20.20.20.10] with 32 bytes of data:
Reply from 20.20.20.101: bytes=32 time<1ms ttl="254<o:p">

C:\Users\Administrator>ipconfig /flushdns

Successfully flushed the DNS Resolver Cache

C:\Users\Administrator>ping fileserver.lab.domain

Pinging fileserver.gslb.domain [20.20.20.102] with 32 bytes of data:
Reply from 20.20.20.102: bytes=32 time=1ms TTL=254

C:\Users\Administrator>ipconfig /flushdns

Successfully flushed the DNS Resolver Cache

C:\Users\Administrator>ping fileserver.lab.domain

Pinging fileserver.gslb.domain [20.20.20.103] with 32 bytes of data:
Reply from 20.20.20.103: bytes=32 time=1ms TTL=254

C:\Users\Administrator>ipconfig /flushdns

Successfully flushed the DNS Resolver Cache

C:\Users\Administrator>ping fileserver.lab.domain

Pinging fileserver.gslb.domain [20.20.20.104] with 32 bytes of data:
Reply from 20.20.20.104: bytes=32 time<1ms ttl="254<o:p">


Simulation successful!

THE END

Not quite ... Continued here http://www.cosonok.com/2014/04/simulating-gslb-dns-load-balancing-and_16.html

No comments:

Post a Comment