Post reply

Moving database servers - IP address change - listeners

  • December 13, 2023 at 5:22 pm

    #4345314

    Hi,

    We will be moving our physical database servers to a new location.

    Prior to the move, new IP address for all the SQL servers will be changed/updated.

    2023-12-13 11_54_57-whoisactive MAIN.sql - Microsoft SQL Server Management Studio

     

     

    Are the IP address listed above for the cluster server?

    After the servers are moved will I need to change the IP address for the listeners? Or are they 'virtual IPs' as mentioned here:

    https://www.mssqltips.com/sqlservertip/4597/configure-sql-server-alwayson-availability-group-on-a-multisubnet-cluster/

    and wont require a change?

    Thanks!

    • This topic was modified 11 months, 1 week ago by  krypto69.
    • This topic was modified 11 months, 1 week ago by  krypto69.
    • This topic was modified 11 months, 1 week ago by  krypto69.

  • December 13, 2023 at 6:39 pm

    #4345362

    Are any of those two IPs the “new locations” IPs?

     

    If not then yes you will need to change the IPs on the listener and WSFC after they have been relocated.

  • December 13, 2023 at 7:32 pm

    #4345394

    Thanks Ant-Green. Kinda figured that.

    I have an A,B servers. Sys admins want to move the B server to the new location on one weekend and server A the following weekend.

     

    Assuming that server B would now have a new/different subnet and ip address. So do I change server A or server B listeners?

    Any issues with this plan - as they will now be on different subnets correct?

  • December 14, 2023 at 8:02 am

    #4345741

    Change the respective IP's based on what is changing.

    If the "B" side is changing first, move the "B" nodes to the new subnet, change the node IP's, change the WSFC B IP, change the listener B IP.

    Rinse and repeat for the "A" side when it is time.

  • December 14, 2023 at 5:52 pm

    #4346014

    Thanks!

  • December 18, 2023 at 8:42 am

    #4348072

    I hope your applications are connecting to your databases via DNS aliases. Using DNS aliases as a layer of indirection drastically simplifies the impact of making the type of move you are describing.

    You still have to change the IP addresses of the servers, as described in previous posts, but using DNS aliases to connect means there are no connection string changes needed to access your new location. You just need to update the DNS aliases.

    Also, I hope your SQL instances are being hosted as guest machines under Hyper-V or VMWare, etc. This is another way to gain a level of indirection to your DBs. Physical kit fails, and it is far easier to build a Hyper-V host on new kit than it is to build a new SQL instance.

    At my old place, each site had a Hyper-V cluster with the DB servers implemented as guest clusters. We could move a DB server to any of the H-V nodes whenever we wanted. At one stage all the physical servers were replaced, with zero impact to the SQL service. Virtualise everything, get layers of indirection wherever you can, and enjoy the resilience and availability your system has.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

Viewing 6 posts - 1 through 5 (of 5 total)

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