Isilon failover with Windows clients

[rgera...@gmail.com]

Hi,

 

We currently have a Celerra environment which fails over the VDM and IP (manually) to a standby Celerra. This works fine since the windows clients can still communicate with the same IP and nothing else changes.

 

On a Isilon however, you have to change dns to point to the secondary Isilon. Which works fine if u open UNC paths, but any mapped drives refuse to follow the DNS change.

 

Any way to resolve that ? I allready tried clearing dns/netbios cache, but that does not seem to work.

 

Any ideas ?

 

Remco Gerards

[Keith Nargi]

Have you considered adding a zone alias to the failover site?  For example if you have prod.isilon.com and all of your windows user connect to this cluster's smartconnect zone. That cluster replicates to drp.isilon.com.  You have a SCZ that is called drp.isilon.com but you can also add a zone alias to that same zone by doing isi networks modify pool subnet0:pool0 --add-zone-allias=prod.isilon.com  Now if you go into DNS and change the SIP adddress from your production cluster to the SIP that is on your DR cluster you don't have to modify any UNC paths the clients will still use the same namespace but they will just be given new IP addresses for the drp cluster. 

Does that help? 

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Keith 

[Jason Davis]

Yeah, I've had experience using SCZ and it's much cleaner IMO then doing DNS cnames and what-not. 

It should be remembered that SMB is stateful so in either event end users will "feel" when you flip-flop.

[rgera...@gmail.com]

Problem is not changing the cname to the other Isilon, that works. But windows will keep going for the same IP even when clearing wins/dns cache, only solution is a reboot, but thats hard to sell when you have 8000 workstations and you want to do a simple upgrade (like 7.1 thats not rolling). So the only solution I can think off is activating the IP's on the DR-isilon. That does however create issues for synciq who uses those same ips.

 

I allmost cant believe there is no solution for this, either on the Isilon or windows side.

 

Remco

[Jason Davis]

Yeah, the current SIQ failover/failback as it's currently implemented is really there for pure "sorta" DR purposes IMO. It doesn't take into account things like moving over node facing IPs or even duplicating NFS/SMB share configurations between two clusters. SmartConnect will do the IP moving of course in a single cluster but multiple clusters? No (As far as I know).

I know that you can leverage hardware load balancers with the Isilon nodes but I've never seen it in person. Even then, looking at the guide there is a hard requirement for Direct Server Return which is more-a-less moot for your usage scenario.

"Optional: In the Hardware load balancing field, type the IP address for a hardware load

balancing switch using Direct Server Return (DSR). This routes all client traffic to the

cluster through the switch. The switch determines which node handles the traffic for

the client, and passes the traffic to that node."

--

[rgera...@gmail.com]

Yea, it appears so. However, in our case, the Isilons are in the same subnet, which does leave some room for manual ip failover. You do need to split off the SyncIQ traffic then, since that wont be happy with you when you remove the ips its using.

Was thinking about creating pool for access and synciq on both Isilons and keep it empty on the DR Isilon. When I want to fail over, I can remove the IP's from the primary and activate them on the secondary and if all shares exist (not replicated either .... sigh) windows would likely not notice the difference. The ip plan would be something like this then:

 

system	AMPERE		VOLTA
role	Primary		Secondary
Smartconnect IP	10.9.6.10		10.9.6.100
CIFS access POOL	10.9.6.11 - 10.9.6.99		none	Probably have to make it dynamic so all IP's are available since the DR Isilon is build with NL nodes, and the primary has X400's aswell for performance
REPL IP POOL	10.9.6.150 - 10.9.6.200		10.9.6.200 - 10.9.6.250	Static ip's

[rgera...@gmail.com]

regarding direct server return hardware load balancing: Aside from the obvious bottleneck, isnt that exactly what you want ? same ip for all traffic from/to client no matter what ?

[Jason Davis]

Well if it's DSR then the Isilon node is handling the return, not the load balancer. So you would still have to deal with setting your SmartConnect IP pools on the DR cluster in the event of a failover as the client would see the connection established through the Isilon node's IP rather than the VIP on the load balancer.

Unless I have this all backwards and if that's the case then forgive me in advance :)

On Mon, Nov 25, 2013 at 2:02 PM, <rgera...@gmail.com> wrote:

regarding direct server return hardware load balancing: Aside from the obvious bottleneck, isnt that exactly what you want ? same ip for all traffic from/to client no matter what ?

--

[rgera...@gmail.com]

You are right, I was reading it wrong. So yea, thats very likely not working either.

 

Op maandag 25 november 2013 21:05:43 UTC+1 schreef SCR512: