Network IP address is changing - What is the impact on SQL server?

  • Dear All,

    My company is changing the IP address of our network. So, I have a few questions:

    1. Do I need to change anything on the SQL servers and clients accessing the SQL server?
    2. Where do I need to make these changes, and how do I test them?

    Are there any articles that explain this?

    Your help is highly appreciated.

    Thanks.

  • I'm assuming your talking about change the SQL Server's IP address.  If so there is not much to account for.  Just make sure that DNS is updated correctly after the change has taken place.  Also note that any client connections, linked servers, etc that use the servers IP will need to be repointed to the new IP.   You will of course have to restart any existing connections after changing IP's.  SQL server in general doesn't care about an IP change. 

    If the change is different or more comlex than this please be a bit more specific and I'll try to help.

     

  • Everything above is correct plus:

    Client Network Utility Aliases

    DNS Aliases (in addition to correctly mentioned DNS itself)

    Client Connections should include both Data Sources (DSN), Hardcoded Connections Strings, Configuration Files, TNS names for connections from Oracle etc. - everything that may connect by IP.

    Firewall Settings: Make sure your network admin changes that!

    Send email to users before the change.

    Regards,Yelena Varsha

  • You may also want to issue an "ipconfig" command on the workstations as well - this is because Windows also caches DNS information. You only need to do this for problematic workstations - ones that have not been rebooted since the SQL Server IP address change. The command you need is:

    ipconfig /flushdns

    RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

  • Are you using microsoft clustering services?

    if so, when you setup the sql server cluster, you specified an IP address that you will need to rerun setup to alter. SQL may have issues if you just try editing the SQL IP Address resource.

    Otherwise, if your instances are not clustered, you should be fine making sure that dns is updated correctly.

    Test well.

  • There will be an issue if you are referring to the server by its IP address instead of its name.

    In this case you will have to manually (or by any kind of SW distribution tool) change the reference on each and every machine/SW/tool/application



    Bye
    Gabor

  • I'm posting this because I never found the exact document I needed to change ips/subnets on a cluster-it might help others. I needed to move a Windows 2003 Enterprise x32 two node active passive SQL 2005 Enterprise cluster with only the default instance to a new public interface subnet. The cluster used a public interface subnet/nic and a crossover for internal cluster traffic on a private net. The following two articles are the main articles for this that I know of; however, I add to sort of combine the steps to figure this out. I didn’t have any problems; although some do as described in http://support.microsoft.com/kb/319578/ and others.

    How to change the network IP addresses of SQL Server failover cluster instances

    http://support.microsoft.com/default.aspx/kb/244980

    Changing the IP address of network adapters in cluster server

    http://support.microsoft.com/kb/230356

    In our environment, we use static DNS. The DNS changes were made for the node and shared addresses around 3am, and I made the following changes soon thereafter.

    1)I logged into the local console for both nodes. I opened cluster admin with “.” Instead of sql-cm(cluster name). “.” Lets you connect during the changes, as you will be changing the ip of the cluster management ip.

    2)Take SQL Group offline on active node that is holding the Cluster group and SQL group(I start with these both active on the first node).

    3)Reip “passive” node e.g. from 111.111.69.110 to 111.111.67.110, changing gateway appropriately, swap cable to new switch port on new subnet, and reboot node( I use IPFilters, and I unassigned the filter group during this process to avoid issues)

    4)after the “passive” node has rebooted, on “active” (although SQL group offline), go to cluster group, and change the IP of the cluster ip in the parameters. It will warn that this change will take effect the next time this resource is brought online. (I also needed to change my cluster name and I did that at this time as well, and it gave me a similar warning, but that’s outside the scope of changing the ips in these directions-it worked)

    5)On the active node where the SQL group is still offline, change the DTC IP the new IP on the new subnet(I also changed the DTC network name now, but that is also outside of the scope of the ip/subnet change-it worked)

    6)On the active node where the SQL group is still offline, change the SQL IP to the new IP on the new subnet.

    7)Failover Cluster Group to the “passive” node making it hold the new cluster group IP which should be on the new subnet that you changed this node to in step 3)

    8)Move SQL group to the “Passive” node .

    9)re-ip the former “active node” to the new subnet and IP, swap the cable to the new switch port, and reboot.

    10)when the node is back online and the cluster admin console on the “passive”/second node is showing the cluster as healthy, bring the SQL group back online. SQL and DTC, etc. should all come back online.

    11)You should check the SQL log to see that SQL is listening on the new address, it will be in the first 20 or 30 lines of the sql log if you open SQL management studio>instance>management>log…, etc.

    12)You can fail the groups back to the normal “active”/primary node now if you wish. (Note, that during this process, a network named something like “Public” in cluster admin will create a second network like “Public(1)” during this change process. However, once both nodes are on the new subnet, MSCS removes the old “Public” leaving you with the new network “Public(1)” on the new subnet. Rename that now if you want and check your cluster traffic setting on this network, public only etc…)

    13)If you are using IPfilters, you would want to double check your IPSec and filters now and assign the group etc. now to put the security back on.

    --Forrest

  • Thanks for point-by-point steps.

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply