Highlighted
2 Iron

Failover Test and DNS

Morning,

We are going to try a Failover of some services on a clients Production Isilon so we can do the upgrade of OneFS without major service impact hopefully. The client has a DNS entry pointing to the Smartconnect zone name and our thinking was we would failover to the secondary cluster, amend the SmartConnect Service IP address within DNS to that of the secondary cluster. However we had a bit of an issue during a test while checking the process involved.

Test

Firstly all we did was set up a local host file on a server for this test. This had the SmartConnect Service IP and FQDN hostname of the SmartConnect zone name in. We had a test script just writing to a text file every 10 seconds to try mimic a normal service. At this point if you opened a Windows share to \\FQDN SmartConnect Zone Name and it opened up a Windows explorer window on the Production cluster with no problems.

I then failed this over to the secondary cluster using the Allow Writes option on the SyncIQ policy. Once we had done that we edited this host file so the Smartconnect Service IP was that of the secondary cluster, restarted this test script and it worked fine. However, we found a bit of an issue. If we opened up a Windows share again to \\FQDN SmartConnect Zone Name it would stay pointed at the Production cluster. It would not open up a Windows Explorer window on the secondary cluster.

We are a bit confused by this behaviour because if we pinged the FQDN SmartConnect Zone Name it returned the IP of the secondary cluster. And the test script we had running worked fine as well after it was restarted. We just cannot figure out why Windows will not open a share to this secondary cluster. And also no wondering if we did go change the DNS entry for the SmartConnect Zone name would it actually work.

 

Questions

So a couple of questions if i may;

  1. Does anyone know why after we had failed over, edited the IP address in our local host file when we tried to open a share to the FQDN zone name it would still open a Windows Explorer window on the the Production cluster?
  2. Should our plan of simply editing the IP in DNS entry for the SmartConnect Zone name work? If we edit that so the IP is that of the secondary cluster will it work? Or are we missing something in what seems a very simplistic process?

Any thoughts/advice would be appreciated.

Labels (3)
0 Kudos
2 Replies
Highlighted
3 Zinc

Re: Failover Test and DNS

Did you do ipconfig /flushdns on Windows client?

0 Kudos
Highlighted
2 Bronze

Re: Failover Test and DNS

1. That really is an issue you'd need to check on the client, to see where it is getting the "wrong" IP from. As stated perhaps something was cached, or wasn't using the local hosts file as expected. 2. Yes, that is how it is designed and how it works, but don't forget it's not really that simple. You need to make sure everything is setup correctly on the secondary cluster (smartconnect, shares) and in an actual failover you will want to make sure you block access to the primary cluster shares before doing a final sync to make sure you don't lose anything, before following the failover process.
0 Kudos