Changing IP when Windows Failover Cluster is connected

[mheimberg]

IHAC running a MS SQL Server on top of a Windows 2008 Failover Cluster.

The SQL server is running two virtual instances, where the LUNs of each instance is pointing to a different NetApp system (not HA pair!).

There is multipathing in place in the form that the Windows host has 2 IPs, while the NetApp nodes have LACP vif in place but only 1 IP.

Now we need to reconfigure the storage network, on which the iSCSI connections are, to a complete different IP subnet.

So this is my procedure, that I would be glad to get your comments on:

#A: prepare Windows hosts

1. stop SQL service

2. stop the Cluster Administration service

3. disconnect the LUNs with SnapDrive on all Failover Cluster nodes

4. disconnect the iSCSI connection from SnapDrive

5. check in the Windows iSCSI configuration for target portals and devices -> delete everything

6. change IPs on the iSCSI NICs

#B: prepare NetApp

1. bring down the vif-iscsi-vlan

2. reconfigure it to new IP range

3. adjust /etc/rc and /etc/hosts to reflect changes

4. bring it up again

5. map the LUNs manually to the Failover Cluster nodes again

#C: reconfigure Windows hosts

1. re-establish iSCSI-connection on the first Windows Failover node

2. re-scan the disks

3. mount found disks to the correct drive-letters and mountpoints

4. restart Cluster service

5. re-establish iSCSI-connection on the second Windows Failover node

6. restart SQL service

The points that give me  headaches are the Quorum disk and the iSCSI reservation - that is the reason why I would try to map the LUNs manually and then connect first only one node of the Failover cluster...

Thanks for any comments

Mark

[ekashpureff]

Markus -

It's the reconnect to the LUNs and Snapdrive part that would make me nervous.

I didn't see re-establish SnapDrive mgt of luns in there.

(Once you manage with SnapDrive, always manage with SnapDrive!)

Leave your existing vlan up on the vif, and create a new vlan on that vif if you can get to that network/vlan ?

Try a dry run with an empty LUN first ?

Good luck with this migration !

At your service,

Eugene Kashpureff

[mheimberg]

Hi Eugene

It's the reconnect to the LUNs and Snapdrive part that would make me nervous.

Exactly my feeling - especially the Quorum of the Failover Cluster.

The SQL LUNs I am pretty sure I can reconnect somehow and get the SQL up again.

I didn't see re-establish SnapDrive mgt of luns in there.
(Once you manage with SnapDrive, always manage with SnapDrive!)

My experience is, that SD is quite tolerant: as soon as you got a mapping on the storage and a iSCSI session you see the drives. Here I am quite confident, but maybe it is still better to use SD, because then I am sure that the net is working, mapping is correct, mounting is done....all the little nice things SD handles for you 🙂

Try a dry run with an empty LUN first ?

Establish new vlan and do a dry run is a very good idea.

Thanks for your response.

Mark