Skip to Content
Technical Articles

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

 

8 Comments
You must be Logged on to comment or reply to a post.
  • Hi Boris,

    Thanks for detailing this procedure within SUM. Sometime within the next year I expect we’ll want to make use of it, as part of our overall migration project to move onto Suite on HANA and introduce further HA configuration into our production landscape. Currently our ASCS instance does indeed reside colocated on a host shared with a dialog instance (a ‘PAS’ setup, I suppose you’d call it), and we have one additional dialog instance (‘AAS’).

    So, if I’m reading your blog correctly, in order to isolate our ASCS, moving it away from dialog instances and giving it its own HA setup, we would need to temporarily install an AAS on the intended target (taking care not to reuse the same instance/port number as the ASCS), then use SUM to move the ASCS to that new host, then de-install the temporary AAS? Is that the recommended procedure? It feels like added complexity to achieve the objective, but I can understand that SUM might require the presence of the AAS in order to correctly detect all components of the system (is that right?).

    Cheers,
    Matt

    • Hi Matt,

      thanks for asking – I agree that SUM may add complexity and that there are probably easier ways to achieve a specific goal. My intention was to explain what SUM does, but this approach may not always be the smartest way. Yes, like you said: SUM requires an instance (AAS) to run on a specific host.

      Cheers,
      Boris

  • Dear Boris,

    Thanks for the detailed explanation on ASCS instance move! Before this, we can only read very limit information from SUM guide.

    Now we are running an S/4HANA conversion project with the exact approach (Case 2). We are not only converting the database (HANA) and application (S/4HANA), but also switching SAP application servers’ OS (RHEL -> SLES). We think ASCS instance move can save us some efforts to switch application server’s OS (ASCS, PAS, AAS …).

     

    One interesting thing we are facing is the global folder handling. Let us re-use your picture for Case 2:

    Before upgrade/conversion, AS host 2’s (in our case, it is SLES) global folder(/sapmnt) was mounted from CS host (in our case, it is RHEL), and after upgrade w/ ASCS instance move feature, ASCS will be moved to AS host 2, however, the global folder is still mounted on CS host.

    Since the original CS host will be closed after upgrade, we have to manually move the global folder’s file system from CS host to AS host 2.

    Actually, we used to try to create a global folder with local file system on AS host 2, however, during SUM check, we may encounter many annoying errors due to the fact that the global folder on AS host2 is not updated. (e.g. “sapcontrol … GetSystemInstanceList” will not get the status from other AAS )

     

    So, do you have some recommendations for global folder handling, when using ASCS instance move feature?

     

    Thanks,

    Brad

    /
    • Hello Brad,

      How did you handle the /sapmnt folder?

      We founded that the SAPGLOBALHOST is pointing to the PAS server and we want to know all the post-steps after the system move.The guide don’t mention that.

      Thanks in advance.

      Regards

  • Hi Boris,

     

    Thanks for introducing “inbuilt” or integrated option in SUM 2.0 to split off ASCS from CI. This seems pretty handy option while upgrading from old setup to new one (e.g. ecc 6.0 ehp4 with CI (DVEB*) to ecc 6.0 ehp8 (ASCS*)) .

     

    Thanks,
    Ambarish

  • Hi Boris ,

    Can we use the same procedure to move the SCS ( Java EN+MS) instance ? My existing system is installed as a distributed system and SCS running on a dedicated instance. I want to reduce the complexity and wat to move the SCS instance to one of the JAVA application server instance .

    Thanks

    Prasit