ASCS instance move: use SUM to switch your ASCS

This blog illustrates the feature “ASCS instance move” as part of the Software Update Manager (SUM) 2.0. Readers should be familiar with the SUM, as introduced in the blog Software Update Manager (SUM): introducing the tool for software maintenance.

Introduction

ASCS instance move of SUM is available as of SUM 2.0 SP 03 and higher (so not in SUM 1.0). This feature is described in the SUM guide, and can be used during an update/upgrade as well as in DMO & System Conversion scenarios.

ASCS instance move allows to move the ASCS instance from one host to another, as part of the SUM processing. Reason to move the ASCS may be new hardware, or a host with operating system (OS) that is no longer supported. The latter is especially important for a System Conversion targeting SAP S/4HANA 1809, in case the existing ASCS runs on a host with OS that is no longer supported for ABAP Platform 1809, as described in SAP Note 2620910.

ASCS considerations

The ASCS instance is the central ABAP service instance with standalone Enqueue and Message Server, running separated from any dialog work processes. SAP recommends to use this ASCS setup, instead of the old architecture (with Message and Enqueue as part of a dialog instance (DVEBMGS##)). For most cases the standalone ASCS is even required, see SAP Note 2146940.

You must be aware that using ASCS instance move will result in a setup that is not recommended, as the ASCS instance will afterwards run on a host together which another instance (a dialog instance). Consider additional activities afterwards to have ASCS running exclusively on that host.

If your system is using the embedded instead of standalone ASCS, SUM will execute the ASCS Instance Split (at least for target product versions based on 7.50 and higher). For details on this feature, check the SUM guide as well. You may use the split, and then manually move the ASCS.

Apart from ASCS instance move and ASCS instance split, SUM offers “DMO with System Move” as third option, but only for DMO scenarios (so only if a database migration is involved). DMO with System Move allows to move a complete system between data center, or into cloud environments (IAAS). Check the following blogs for details on DMO (Database Migration Option (DMO) of SUM – Introduction) and DMO with System Move (DMO with System Move – the use case to change PAS host during DMO).

When is ASCS instance move offered by SUM

If SUM is running on a host that does not contain the ASCS instance (i.e. on an Additional Application Server AAS), it will detect the ASCS instance on a remote application server host and will offer a dialog in phase ASCS_ASK, offering the ASCS Instance Move (in roadmap step Checks).

(Note: the screenshots use the new SUM UI, with URL suffix /slui, not /sluigui.)

If you select the option, the SUM will move the existing ASCS instance from the remote application server host to the host on which SUM is running, during the downtime of the procedure. (Note that remote application server is from the perspective of SUM).

So, if you want to move the ASCS instance to a different host, you will

• Ensure that an Additional Application Server (AAS) is existing
  • SUM will not install an application server for you
  • For targeting S/4HANA 1809, use an OS supported for that host (Note 2620910)
• Extract and start SUM on that AAS
• On the SUM dialog, choose the option to move the ASCS instance
• After the SUM procedure is finished, post activities are required, as listed in the guide
  • As an example, delete the source ASCS instance
• You may not immediately shutdown the old ASCS host, e.g. it may host SAPGLOBALHOST

For a High Availability (HA) setup, special restrictions apply, see SUM guide.

The ASCS instance move happens in downtime and does not influence (extend) the downtime.

Is it really a move?

Well, actually it is not a move: SUM creates a new ASCS instance and does not start the old one after the procedure. But move sounds better, doesn’t it? 🙂

That means the instance number is not necessarily the same. This is important as the ASCS instance is relevant for communication: the port depends on the instance number! That is why you may want to set the instance number for the new ASCS instance. This is possible if you switch on the expert mode in SUM, in the dialog Tool Configuration (in roadmap step Configuration), as highlighted in the screenshot below.

Among others, the expert mode shows additional dialogs. And for the ASCS instance move dialog, the expert mode will show an additional entry field which allows you to set the instance number for the new ASCS instance, see below.

Note that you can only maintain a number that is not yet existing on that host. So, if your existing ASCS instance number is 00, and the AAS has a dialog instance with that number, you will not be able to keep the ASCS instance number with the ASCS instance move.

Use case illustrations

Let’s quickly check some illustrations for the feature. In the following pictures, instance names are written in green when running, and red if they are stopped.

1) First case is that the PAS host shall be replaced by a host on a different OS.

In this case, the choice was to set the new ASCS instance number to 0, to keep the previous ASCS instance number. Note that like in the initial setup, the central services are not running exclusively on a host.

2) Second case has a host that only contains the ASCS instance (CS: central services) – for performance reasons.

As you see, the result of using the feature is in this case that the ASCS instance is no longer running exclusively on a dedicated host. In addition, the instance on AS host 1 is still running. If your scenario is targeting SAP S/4HANA 1809 (for which HP-UX is not supported for the AS host), you will have to consider the option to not update additional application server instances (see section below).

3) Third case shows the instance number conflict: it is not possible to keep the previous ASCS instance number in case that the AAS already has an instance with that number. For this case which is similar to first case, we do not show the illustrations, but have a look at the instances and directories prior and after the SUM run.

Prior to the SUM run

• <host_1> (as AAS) has one dialog instance (#00)
• <host_2> (as PAS) has the ASCS instance (#00) and a dialog instance (#01)
• SUM is extracted and started on <host_1> (AAS) to have new ASCS on that host

See screenshot below for instance and directory list.

During the SUM run, instance number for the new ASCS is set to 1 (either manually in expert mode, or automatically by SUM).

After the SUM run

• <host_1> has the new ASCS (#01), and still the dialog instance (#00)
• <host_2> still has the dialog instance (#01)
• The old ASCS on <host_2>is not running, adaptations required as mentioned above

Update of additional application server instances

For non-DMO scenarios, you have the option to let SUM update the additional application server instances. The option is offered in phase INITSUBST (roadmap step Configuration), as shown below.

For case 3 above, this option was chosen, so that dialog instance 01 on <host_2> was considered and started after the SUM downtime. If the option was not chosen, that dialog instance would not have been updated and would not be started at the end of the SUM procedure.

For DMO scenarios, it is not possible to choose this option. DMO is the migration to a new database type. Requirement would be to install appropriate database client software on that host (remote host from SUM perspective), to adapt environment variables. This is not possible for SUM.

Alternatives to ASCS instance move

You may decide not to use this feature. Alternatives are shortly mentioned in SAP Note 2696472.

Kind regards,
Boris Rubarth, Product Manager Software Update Manager, SAP SE