By:Edwin Sarmiento | Last Updated: 2018-11-19 || Related Tips:More > Clustering
ProblemWe are upgrading a SQL Server failover clustered instance (FCI) to a higher version and on newer hardware. We do not know how many applications are connecting to the database so we would like to keep the same virtual network name and virtual IP address to prevent applications from failing after the upgrade. We would also like to do this with the least amount of downtime. How do we go about upgrading a SQL Server FCI to a higher version and on newer hardware while keeping the same virtual network name and virtual IP address?
SolutionOne challenge with a database upgrade and migration is making sure that applications can still connect to the new platform after the upgrade. Without proper documentation, it would be challenging to identify all of the applications that use the database to change the database connection string. That's why most organizations opt to reuse the same server name and IP address. This eliminates the need to track every single application connecting to the database to make connection string changes.
It's a bit tricky to do this with a SQL Server FCI, mainly, because of the other external dependencies like Active Directory and DNS. A SQL Server FCI virtual network name is created as a virtual computer object (VCO) in Active Directory. Active Directory, then, triggers the creation of the corresponding DNS entry with the virtual IP address for the virtual network name. So, you have to consider a lot of Active Directory-related concerns as part of the upgrade and migration.
I'm not a big fan of in-place upgrades because of the risks associated with it, especially with high availability solutions like a SQL Server FCI. You need to consider the amount of allowable downtime (maintenance window) during the upgrade. If an upgrade or a migration fails, the amount of time necessary to implement your rollback plan should be included in the maintenance window. I highly recommend doing a side-by-side migration. This is where your old and new environments exist side-by-side, reducing the amount of risks associated with the upgrade. You can also perform tests on the new environment prior to going live into production without causing any issues to the old environment.
However, with a side-by-side migration, you cannot have the same virtual network name and virtual IP address running at the same time on both environments. You will end up with a duplicate name and IP address on the network and won't be able to run both of the SQL Server FCI. Hence, you would need different virtual network names and virtual IP addresses.
In this tip, I will show you how to upgrade or migrate a SQL Server FCI while using the same virtual network name and virtual IP address via a side-by-side migration.
For this example, I will be performing a side-by-side upgrade and migration of a SQL Server 2012 with Service Pack 4 FCI to a SQL Server 2017 FCI. Below are the details of the implementation.
Old Environment New Environment WSFC OS: windows Server 2012 R2 OS: Windows Server 2016 Nodes: TDPRD211 and TDPRD212 Nodes: TDPRD221 and TDPRD222 Cluster Name Object: TDPRDSQLCLS12 Cluster Name Object: TDPRDSQLCLS16 Virtual IP Address: 172.16.0.213/16 Virtual IP Address: 172.16.0.223/16 SQL Server FCI Instance Name: DEFAULT Instance Name: DEFAULT Version: SQL Server 2012 with SP4 Version: SQL Server 2017 RTM Virtual Network Name: PRODDBSQL10 Virtual Network Name: PRODDBSQL02 Virtual IP Address: 172.16.0.210/16 Virtual IP Address: 172.16.0.225/16The query below is used to display the properties of the two SQL Server FCIs.
:CONNECT PRODDBSQL10SELECT nodeName, status_description, is_current_owner FROM sys.dm_os_cluster_nodes ORDER BY 1
SELECT @@SERVERNAME as InstanceName, @@VERSION as Version,
SERVERPROPERTY('IsClustered') as [Is_FCI]
SELECT @@SERVERNAME as InstanceName, LOCAL_NET_ADDRESS AS [IP Address Of SQL Server FCI]
FROM SYS.DM_EXEC_CONNECTIONS WHERE SESSION_ID = @@SPID
GO
:CONNECT PRODDBSQL02
SELECT nodeName, status_description, is_current_owner FROM sys.dm_os_cluster_nodes ORDER BY 1
SELECT @@SERVERNAME as InstanceName, @@VERSION as Version, SERVERPROPERTY('IsClustered') as [Is_FCI]
SELECT @@SERVERNAME as InstanceName, LOCAL_NET_ADDRESS AS [IP Address Of SQL Server FCI] FROM SYS.DM_EXEC_CONNECTIONS WHERE SESSION_ID = @@SPID
The shared disk layouts are the same for both SQL Server FCIs to maintain consistency.
Here's a high-level overview of the process involved in upgrading or migrating a SQL Server FCI using the same virtual network name and virtual IP address via a side-by-side migration.
Take the SQL Server FCI offline (old environment) Delete the virtual computer object of the SQL Server FCI virtual network name (old environment) in Active Directory Rename the SQL Server FCI virtual network name (new environment) Change the SQL Server FCI virtual IP address (new environment) Bring the SQL Server FCI online (new environment)At the end of the process, the new environment should have the old virtual network name and virtual IP address. In this example, PRODDBSQL10 and 172.16.0.210 , respectively.
You don't have to change the cluster name object (CNO) of the Windows Server Failover Cluster (WSFC) since the applications only need the SQL Server FCI virtual network name and virtual IP address to connect to the databases.
Take the SQL Server FCI offline (old environment)The first step is to take the SQL Server FCI offline. This is to make sure that no other applications can connect to the databases during the migration. This also prepares you to move the virtual network name and virtual IP address from the old environment to the new environment.
NOTE:Be sure to complete everything you need to migrate the databases from the old environment to the new environment prior to performing this step. You won't be able to access the old environment after taking the SQL Server FCI offline. This is also when your maintenance window officially starts.
To take the SQL Server FCI offline using the Failover Cluster Manager:
Select the role that contains the SQL Server FCI. In this example, it's SQL Server (mssqlSERVER) . Right-click on the role and select Stop Role . This will take the SQL Server FCI offline.
To take the SQL Server FCI offline via PowerShell, use the Stop-ClusterGroup PowerShell cmdlet, passing the role name.
Stop-ClusterGroup "SQL Server (MSSQLSERVER)" -Cluster TDPRDSQLCLS12
Once the SQL Server FCI is offline, you can proceed to delete the virtual computer object of th