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.
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.
So a couple of questions if i may;
Any thoughts/advice would be appreciated.