In this blog, I want to show you how to migrate an already existing, productive Windows Failover Cluster with an installed (A)SCS instance using shared disks, to a File Share Cluster, which is not using shared disks.
The installation guide and some background information to the file share cluster scenario can be found here: SAP on Windows Blogs
A clustered (A)SCS instance in a Failover Cluster is configured using a so-called virtual hostname, sometimes also called a "logical" hostname or an "additional" hostname. The term "alias name" cannot be used here, because it refers to DNS c-names and they cannot be used in Clusters.
This picture shows a HA installation in Failover Cluster with shared disks:
You see the virtual hostname used for the (A)SCS instance:
This hostname is not only used for the (A)SCS, but also as SAPGLOBALHOST, which hosts the \sys\.. folder structure of a SAP system.
The next picture shows a HA installation in a Failover Cluster that doesn't use shared disks:
Do you see the main difference?
The virtual hostname used for the (A)SCS instance is marked in red. This hostname must be reused if you want to migrate from a Shared Disk Cluster to a File Share Cluster.
All clients (application servers, gateways, Web Dispatchers, RFC clients, etc.) have to already use this name to connect to the SAP Message Server! It would be a lot of effort to change this hostname on all clients.
New in this scenario is the remote file share for SAPGLOBALHOST, in this example marked green.
All existing application server instances (ABAP or JAVA) must be manually changed from ABC-ASCS to ABC-SAP_GLOBAL. Otherwise, their start services (sapstartsrv) will no longer start (because they will try to load their profiles from ABC-ASCS, instead of ABC-SAP_GLOBAL).
Here is a step-by-step guide how to migrate from shared disk to file share cluster:
Preparation phase:
Day of migration, SAP system is down:
Update (25.04.2018):
Do not forget the ERS (Enqueue Replication Server) instances! The instances have their profil located on \\localhost\saploc\ERSxx\profile directory. The profiles will be replicated from central staging directory to this local profil directory. Check the SCSHOST parameter in the profile. If there is still the old, maybe wrong hostname in there, the ERS will start and then suddenly stop again, because the Enqueue server cannot be reached using the wrong hostname.
The installation guide and some background information to the file share cluster scenario can be found here: SAP on Windows Blogs
A clustered (A)SCS instance in a Failover Cluster is configured using a so-called virtual hostname, sometimes also called a "logical" hostname or an "additional" hostname. The term "alias name" cannot be used here, because it refers to DNS c-names and they cannot be used in Clusters.
This picture shows a HA installation in Failover Cluster with shared disks:
You see the virtual hostname used for the (A)SCS instance:
This hostname is not only used for the (A)SCS, but also as SAPGLOBALHOST, which hosts the \sys\.. folder structure of a SAP system.
The next picture shows a HA installation in a Failover Cluster that doesn't use shared disks:
Do you see the main difference?
The virtual hostname used for the (A)SCS instance is marked in red. This hostname must be reused if you want to migrate from a Shared Disk Cluster to a File Share Cluster.
All clients (application servers, gateways, Web Dispatchers, RFC clients, etc.) have to already use this name to connect to the SAP Message Server! It would be a lot of effort to change this hostname on all clients.
New in this scenario is the remote file share for SAPGLOBALHOST, in this example marked green.
All existing application server instances (ABAP or JAVA) must be manually changed from ABC-ASCS to ABC-SAP_GLOBAL. Otherwise, their start services (sapstartsrv) will no longer start (because they will try to load their profiles from ABC-ASCS, instead of ABC-SAP_GLOBAL).
Here is a step-by-step guide how to migrate from shared disk to file share cluster:
Preparation phase:
- Prepare the new file share cluster. You cannot use the same virtual hostname ABC-ASCS, because this is already active in the productive, old cluster. Each network name in a Failover Cluster has a related computer object in Active Directory which prevents the usage for a second time (even if you would use a different IP address).
- Test the cluster (failover!) and the new landscape.
- Prepare the instance profiles for all application server instances, gateway, Web Dispatchers, etc. with the new SAPGLOBALHOST hostname.
Make sure to comment this line, for example like: # SAPGLOBALHOST = <new hostname>
Day of migration, SAP system is down:
- Remove virtual hostname (cluster network name resource) and IP address for the (A)SCS instance in the old cluster.
- Stop the cluster services. Set the services to disabled to prevent an unplanned start of the old cluster.
- Delete the related computer object in Active Directory.
- Add IP address and network name (called an "Access Point" by Microsoft) in the new cluster. The cluster will automatically create a new computer object in Active Directory.
- Change the name of the (A)SCS instance profile to the new SAPGLOBALHOST hostname.
- Change the (A)SCS start services to load their profile now from the new SAPGLOBALHOST file share.
- Change SAPGLOBALHOST in all instance profiles of this SAP system!
- Look for optional environment variables in <SID>adm user environment or Windows system environment. Maybe there are variables containing the old hostname for SAPGLOBALHOST?!
- Start (A)SCS instance in Failover Cluster via SAP MMC, Failover Cluster Manager or via sapcontrol.exe.
- Start all related SAP instances of this system.
- Test cluster failover!
- Inspect log files for errors or events
- Release system for productive use and crack open a bottle of champagne, you have done it! 🙂
Update (25.04.2018):
Do not forget the ERS (Enqueue Replication Server) instances! The instances have their profil located on \\localhost\saploc\ERSxx\profile directory. The profiles will be replicated from central staging directory to this local profil directory. Check the SCSHOST parameter in the profile. If there is still the old, maybe wrong hostname in there, the ERS will start and then suddenly stop again, because the Enqueue server cannot be reached using the wrong hostname.
- SAP Managed Tags:
2 Comments
