SAP cross-cluster move with minimized downtime
SAP cross-cluster move with minimized downtime: Many customers are using SAP ABAP or Java application servers installed in a system architecture based on the Windows Server Failover cluster framework. This high availability architecture is well-known and has been proven to work for years. Unplanned hardware failures and maintenance activities can be covered with minimal impact for the system availability.
But in some scenarios, it is necessary to transfer an SAP system from one Failover Cluster to another one. That could be the case in these situations:
- New active directory domain name or new DNS domain name, e.g. after the acquisition of a company
- A Windows OS upgrade, e.g. from Windows Server 2012 or lower to Windows Server 2016.
- From Windows Server 2012 R2 there is the possibility to upgrade the nodes rolling and in-place
- A (partly) destroyed cluster configuration
- Redesign of the datacenter architecture
- Move to an IaaS partner like Microsoft Azure or to the Google Cloud Platform
As far as I know, there are many guides and best practices (like the official SAP installation guide or this blog) written on how to install SAP in a Windows Server Failover Cluster. But I don’t know a “best practice documentation” on how to move an SAP system from one cluster environment to a new one. I will try to change this with this blog.
Prerequisites
As a starting position, I will assume that we do have an already clustered SAP (A)SCS instance up and running. Of course, this method would work in a similar way for every clustered SAP ABAP or Java system. In this example, I am using an SAP ABAP system called “RIX”. In the beginning, RIX is running on a Windows Server 2012 R2 cluster, consisting of the nodes wsiv8050-1 and wsiv8050-2. It’s a very typical setup, as it is described in the SAP ABAP Installation Guide (find an overview of SAP NetWeaver Installation Guides here[Link]) and it looks like:
.</li>%0A<li>Create%20the%20WSFC%20following%20the%20Microsoft%20guidelines%20and%20the%20SAP%20HA%20installation%20guide.</li>%0A<li>If%20necessary,%20install%20the%20database%20software%20on%20the%20new%20cluster.%20For%20this%20blog,%20I%20installed%20a%20clustered%20SQL%20Server%202016%20instance%20on%20wsiv805<strong>1</strong>-1%20and%20wsiv805<strong>1</strong>-2.%20Another%20possible%20option%20would%20be%20to%20use%20SQL%20Server%20AlwaysOn%20instead%20of%20the%20traditional%20SQL%20Server%20Clustering.%20Or%20%E2%80%93%20depending%20on%20the%20planned%20landscape%20%E2%80%93%20install%20the%20SAP%20database%20instance%20outside%20of%20the%20SAP%20ASCS%20cluster,%20e.g.%20on%20a%20dedicated%20SQL%20Server%20Database%20cluster.</li>%0A</ol>%0A<h1>Starting%20the%20SAP%20installation</h1>%0A<p>After%20the%20new%20cluster%20has%20been%20prepared%20for%20the%20SAP%20installation,%20start%20SWPM%20on%20the%20first%20new%20cluster%20node%20to%20install%20a%20new%20%E2%80%9CFirst%20Cluster%20Node%E2%80%9D.%20Use%20the%20very%20same%20SID%20for%20the%20new%20system%20(RIX%20in%20this%20case)%20and%20the%20identical%20instance%20number%20for%20ASCS%20and%20ERS%20as%20you%20have%20used%20in%20the%20old%20clustered%20environment.%20For%20the%20SAP%20Network%20name,%20it%20is%20obviously%20impossible%20to%20choose%20the%20same%20name%20as%20it%20is%20in%20use%20in%20the%20existing%20system%20to%20avoid%20a%20naming%20collision.%20In%20my%20example,%20I%20will%20use%20%E2%80%9Cobelix%E2%80%9D%20instead%20of%20%E2%80%9Casterix%E2%80%9D%20as%20a%20temporary%20hostname%20for%20the%20SAP%20Virtual%20Instance.</p>%0A<p%20style=)
%20hostname%20%E2%80%9Cobelix%E2%80%9D,%20the%20ERS%20instances%20are%20locally%20deployed%20on%20the%20new%20Windows%20Server%20nodes%20wsiv805<strong>1</strong>-1%20and%20wsiv805<strong>1</strong>-2,%20and%20the%20SQL%20Server%20database%20software%20is%20already%20up%20and%20running.%20Now%20is%20the%20perfect%20point%20in%20time%20to%20test%20the%20failover%20capabilities.%20In%20addition%20to%20that,%20you%20can%20now%20install%20all%20the%20required%20Windows%20patches,%20upgrade%20the%20SAP%20kernel%20and%20migrate%20everything%20from%20the%20former%20cluster%20nodes%20to%20the%20new%20one,%20e.g.%20environment%20variables,%20additional%203<sup>rd</sup>%20party%20applications%20and%20so%20on:</p>%0A<p%20style=)
merge them into \obelixsapmntRIXSYSprofile.
Prepare the database move
From an SAP cluster perspective, everything is now prepared to start the move. But in my environment, it is advisable to start transferring the database to the new SQL Server instance now, because I plan to move both components, SAP and database in one short downtime from the existing environment to the new cluster. To keep the necessary downtime as short as possible, I will utilize the standard backup- and restore capabilities that are offered from the SQL Server DMBS to build up a “hot stand-by database”. To do so, there are many conceivable approaches. Read the existing database software documentation for your DBMS to find the best way for your setup. For SQL Server, a manually initiated “transaction log shipping”, as described here, is a sufficient feature to achieve the desired goal.
--execute the Full Database Backup on the existing instance :connect WSIV8050-SQLCLU GO BACKUP DATABASE [RIX] TO DISK = N'\parkplatzSamuel_BackupRIXFullRIX.bak' WITH NOFORMAT, NOINIT, NAME = N'RIX-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 5 GO --now we can connect to the target instance to restore the database fullbackup in the new Environment :connect WSIV8051-SQLC51 USE master GO RESTORE DATABASE RIX FROM DISK = N'\parkplatzSamuel_BackupRIXFullRIX.bak' WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 10, NORECOVERY GO --do the TLOG backup on the source database :connect WSIV8050-SQLCLU GO BACKUP LOG [RIX] TO DISK = N'\parkplatzSamuel_BackupRIX1-RIX.trn' WITH NOFORMAT, NOINIT, NAME = N'RIX Database Log Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO --and restore the TLOG on the target instance :connect WSIV8051-SQLC51 GO RESTORE LOG RIX FROM DISK = N'\parkplatzSamuel_BackupRIX1-RIX.trn' WITH FILE = 1, NOUNLOAD, STATS = 10, NORECOVERY GO
Pay attention to the “NORECOVERY“-option I used twice. The result on the target instance is a database in ‘Restoring’ mode. That allows to restore additional transaction log backups to bring the source and the target database in sync during downtime, before opening the RIX database on the target instance on wsiv8051-SQLC51.
Do the magic: Move the ASCS and DB instance in a short system downtime
As always, it is mandatory to have a full system backup before doing maintenance on a productive SAP system. If everything is well-prepared, the risk to need to roll back is quite low, but it’s always a possible solution to roll back and postpone the maintenance activity.
At this point, you have a clustered ASCS instance, a clustered SQL Server database instance, and local ERS instances running on both cluster environments. Your ABAP application instances are still installed on the old/existing cluster.
If your downtime window begins, stop – as always – all interfaces, your batch jobs and log off all dialog users.
- Stop the SAP application servers.
- Take the ASCS & ERS instances offline. It is recommended to “disable” the Windows services to avoid an unintended restart in future.
![]()
- Using the Windows Server Failover Cluster Management, remove (!) the IP address and the network name “asterix” from your current cluster node wsiv8050-1.
![]()
- Remove the cluster object in Active Directory “asterix”
![]()
- Modify the IP address and network name from “obelix” to “asterix” in the SAP cluster role in the new environment wsiv8051-c.
![]()
- Before we can start the new ASCS, we need to reconfigure the profile files if not already prepared at this point in time. That means:
- Rename the ASCS profile, e.g.
rename D:usrsapRIXSYSprofileRIX_ASCS00_obelix D:usrsapRIXSYSprofileRIX_ASCS00_asterix - Adjust all the parameters inside the DEFAULT.PFL and the instance profile RIX_ASCS00_asterix that are pointing to obelix, which didn’t exist anymore. To do so, you could simply copy the profiles from the former cluster. But take care of every single profile parameter and – most importantly – adjust the database related settings. For SQL Server, this would be the parameters
SAPDBHOST = WSIV8051-SQL dbms/type = mss dbs/mss/server = WSIV8051-SQLC51 dbs/mss/dbname = RIX dbs/mss/schema = rix - Modify the local profiles from the ERS instances. In my environment, they are local profile files in C:usrsapRIXERS10profile on each node. Correct all the “obelix” entries to “asterix” in these profile files on every cluster node. And remember to restart the ERS instances after the changes have been made!
- If there are adm specific user environment variables like SAPLOCALHOST=obelix or MSSQL_SERVER=wsiv8050-sqlCLU, you must modify them to the new values. E.g. using regedit HKEY_USERS –> –> Environment.
- Modify the Windows service SAPRIX_00 on both (=all!) new cluster nodes, that asterix instead of obelix is used to determine the sapstartsrv.exe parameters. You can either use sc.exe /config= or regedit.exe adjusting the “ImagePath” key in the hive HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesSAPRIX_00
--do the last TLOG backup on the source database before switching to offline :connect WSIV8050-SQLCLU GO BACKUP LOG [RIX] TO DISK = N'\parkplatzSamuel_BackupRIX2-RIX.trn' WITH NOFORMAT, NOINIT, NAME = N'RIX Database Log Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 ALTER DATABASE [RIX] SET ONLINE WITH ROLLBACK IMMEDIATE GO --and restore the TLOG on the target instance :connect WSIV8051-SQLC51 GO RESTORE LOG RIX FROM DISK = N'\parkplatzSamuel_BackupRIX2-RIX.trn' WITH FILE = 1, NOUNLOAD, STATS = 10, NORECOVERY GO :connect WSIV8051-SQLC51 GO --finally open the database on the target SQL Server instance RESTORE DATABASE RIX WITH RECOVERY - Re-configure the SQL Server logins and security. To do so, there are many possible ways. One would be to follow SAP note 1294762 – SCHEMA4SAP.VBS and create a schema repair script. That would transfer all the logins. In addition to that, remember to transfer all other database related objects like SQL Server Agent jobs, additional logins or maintenance plans.
- Start the ASCS instance using the cluster role “SAP RIX” on the new cluster node. If everything is properly configured, the ASCS is running smoothly.
- Start the old application server instances which you still have installed at least on two Windows hosts, wsiv8050-1 and wsiv8050-2. All former application instances should successfully load their profile from the “new” \asterixsapmntRIXSYSprofile without any modification. Verify that the application server instances connect to the database moved to the new server.
At this point you have successfully switched to the new ASCS instance and database on the new cluster!
Follow up activities
You can now:
- install additional application server instances on the new cluster nodes
- remove the old SAP instances on the old Windows hosts. Or simply delete the old environment.
After everything is finished, you can install two additional SAP application server instances on the two new Windows Server 2016 cluster nodes to the existing system RIX. Of course, these SAP instances are installed on local disks. Thus, your final system architecture could look like:
![]()
The difference to the starting architectural overview is marginal – only both node host names are exchanged (from wsiv8050-1/ wsiv8050-2 to wsiv8051-1/ wsiv8051-2). And of course, the new cluster nodes are completely independent from the former ones – they could be using a different Windows Server Version or changed server location (e.g. even operated in an IaaS environment).
Disclaimer
Please consider this blog as a source of inspiration. It could be very beneficial to follow such a guidance instead of obtaining knowledge by doing. But I strongly recommend to test this procedure in your environment before each production downtime. After you finished the “obelix” installation, you could perhaps move this environment to an unused dummy name, for example “idefix”. That will lead to the certainness which is necessary to do all the of steps systematically during the (short?!) downtime of your productive system.
New NetWeaver Information at SAP.com
Very Helpfull
- Rename the ASCS profile, e.g.
