Overview

Being up-to-date with the latest technologies and aiming the production stability and consistency are the top priorities for most businesses. However, that often requires business critical downtime for production systems. SAP offers a solution to this problem by providing its clients with the near-Zero Downtime Maintenance (nZDM) for SAP Java procedure for its SAP Java systems.

This blog gives an overview of the nZDM Java solution and the specifics of performing it on High Availability (HA) SAP Java systems.

What is the nZDM Java procedure?


The near-Zero Downtime Maintenance for SAP Java is a procedure that enables you to perform maintenance activities with greatly reduced business downtime on SAP Portal, SAP Process Orchestration (PO) and SAP systems that have only some of the usage types part of SAP Process Orchestration. nZDM Java deliveries are part of SAP SL Toolset program.

The nZDM Java procedure allows SAP customers to perform all maintenance activities on a copy or clone of the system (also called ‘target system’ in the context of nZDM) while the production system (called ‘source system’) is still in use.


More information about the nZDM solution can be found in the following pages:

Approaches for performing nZDM Java


Depending on the client’s system landscape and complexity, there are two main approaches for performing nZDM Java. Both rely on the copy or clone of the production system and include some basic common steps but the finalization steps differ.

Below the different approaches are explained via diagrams. The following legend describes the meaning of the different colors:

000-Legend.png

  • System switch

This approach is suitable for virtualized systems as well as HA systems. The system’s clone will become the new production system. Before replacing the production system with the target system, testing the updated clone is possible without downtime. This happens in a special ‘nZDM test mode’.

The technical downtime is approximately the time needed to restart the system. It varies depending on the type and load of the system.

These are the generic steps of performing a ‘System Switch’ on a standard Process Orchestration system:

0.     Initial State

The system on which we perform the ‘System Switch’ is a SAP Process Orchestration (PO) system consisting of several components: one or more Java Application Servers (AS), SAP Web Dispatcher (WD), SAP Central Services (SCS), SAP Enqueue Replication Service (ERS) and a database.

001-SS0.png

1.     Preparation

Prepare the production system for nZDM Java: configure database settings, deactivate background jobs, set the landscape directory (SLD) to read-only mode, download and run the nZDM Java GUI on a separate host.


2.     Connect the nZDM Java GUI to the source (production) system

Connect the nZDM Java GUI to one of the application servers of the source system.

002-SS1.png

3.     Start recording

Initialize recording of the database changes on the production system.


4.     Clone the source (production) system

Clone the source (production) system to create a target system.

003-SS2.png

5.     Isolate the cloned system

Configure the isolation (network fencing) of the target system to avoid conflict with the source (production) system.


6.     Start the target system

When the isolated clone is started, it starts as a target system.

004-SS3.png

7.     Update the target system

Perform the desired maintenance activities on the target system.

005-SS4.png

8.     (optional) Test the updated system

The updated target system can be tested before replacing the production system. No production system downtime is required for while testing on the target system. However, before performing tests it is important to do a backup of the target system. After the tests, the target system is restored to that backup.


9.     Connect nZDM Java GUI to the target system

006-SS5.png

10.   Start DB data replication from the source system to the target system

Replicate all available data changes from the source’s DB to the target system.

007-SS6.png

11.   Stop source system / enter downtime phase

To replicate the last data changes the source system is stopped, starting the downtime phase. Only the DB of the source system remains active so that the replication can be finished.

This phase is activated via the nZDM GUI.

008-SS7.png

12.   Stop and unfence target system

After finishing the replication, the updated target system is stopped and unfenced. Once unfenced, it can be started.

13.   Start updated system / end of downtime phase

After starting the updated system, it replaces the original and becomes the new production system.

010-SS9.png


  • Database switch

Recommended when there is no virtualization of the system and not suitable for High Availability systems. It uses the newly created database on the existing source system DB host. The data is cloned on the existing database server or on a shared storage. This approach is useful when the existing productive environment has a large scale and complex configurations. Therefore it might be the least costly way to use the already existing environment.


nZDM Java on High Availability System

Depending on the scenario and the suitable approach for it, the steps of the nZDM Java procedure may differ.

This section contains step-by-step descriptions, of two successfully performed scenarios of nZDM Java on HA systems. The first scenario demonstrates the above-mentioned ‘Cluster Clone’ and for the second a split of the cluster is performed.


nZDM Java on High Availability System: Cluster Clone

This approach for nZDM Java on HA system is more suitable for virtualized systems or other environments where making a clone or a copy of the system can be easily performed. With the HA ‘Cluster Clone’ the update is performed on a clone / copy of the production system. During the maintenance performed on of the clone (target system), the production system (source system) is active. The downtime is required for completion of the replication of data changes from source to target and takes about one system restart time.

These are the generic steps of performing a ‘Cluster Clone’ on a two-node HA system setup:

0.     Initial State

The system on which we perform the ‘Cluster Clone’ is a High Availability / Disaster Recovery SAP Java system with two nodes and multiple application servers. Each node may have SAP Web Dispatcher (WD), SAP Central Services (SCS), SAP Enqueue Replication Service (ERS) and a database. The nodes are bound together in a HA cluster via HA software.

There is only one active WD, SCS, ERS and DB instance in the cluster of nodes at any given moment. If an active instance fails, the inactive activates and replaces it.

011-HASS0.png

1.     Preparation

Prepare the production system for nZDM Java: configure database settings, deactivate background jobs, set the landscape directory (SLD) to read-only mode, download and run the nZDM Java GUI on a separate host.

2.     Connect nZDM Java GUI to the source (production) system

Connect the nZDM Java GUI to one of the application servers of the source system.

012-HASS1.png

3.     Start recording

Initialize recording of the database changes on the production system.


4.     Clone the source (production) system

Clone the whole cluster of nodes to create a target system.

013-HASS2.png

5.     Isolate the cloned system

Configure the isolation (network fencing) of the target system to avoid conflict with the source (production) system.


6.     Start the target system

When the isolated clone is started, it becomes our target system.

014-HASS3.png

7.     Update the target system

Perform the desired maintenance activities on the target system.

015-HASS4.png

8.     (optional) Test the updated system

The updated target system can be tested before replacing the production system. No production system downtime is required for while testing on the target system. However, before performing tests it is important to do a backup of the target system. After the tests, the target system is restored to that backup.


9.     Connect nZDM Java GUI to the target system

016-HASS5.png

10.   Start DB data replication from the source system to the target system

Begin replication of data changes from the source’s DB to the target system.

017-HASS6.png

11.   Stop source system / enter downtime phase

To replicate the last data changes the source system is stopped, starting the downtime phase. Only the DB of the source system remains active so that the replication can be finished.

This phase is activated via the nZDM GUI.

018-HASS7.png

12.   Stop and unfence target system

After finishing the replication, the updated target system is stopped and unfenced. Once unfenced, it can be started.

13.   Start updated system / end of downtime phase

After starting the updated system, it replaces the original and becomes the new production system.

020-HASS9.png

nZDM Java on HA System: Cluster Split


This is an alternative approach for nZDM Java on HA systems having limited hardware resources at their disposal. It is suitable for non-virtualized systems. With the ‘Cluster Split’ instead of making a clone of the system including all of its nodes (like we do with ‘System switch’), we split the cluster of nodes and use one of the already available cluster nodes as a target system. The other node serves as a source system and remains active until the finalization phase of the nZDM Java procedure. The downtime takes about one system restart time but recreation of the HA setup may need additional planning, time and efforts.

The following describes the generic steps of a ‘Cluster Split’ nZDM Java approach on a two-node HA system:

0.     Initial State

The system on which we perform the ‘Cluster Split’ is a High Availability / Disaster Recovery SAP Java system with two nodes and multiple application servers. Each node may have SAP Web Dispatcher (WD), SAP Central Services (SCS), SAP Enqueue Replication Service (ERS) and a database. The nodes are bound together in a HA cluster via HA software.

There is only one active WD, SCS, ERS and DB instance in the cluster of nodes at any given moment. If an active instance fails, the inactive activates and replaces it.

021-HACS0.png

1.     Preparation

Prepare the production system for nZDM Java: configure database settings, deactivate background jobs, set the landscape directory (SLD) to read-only mode, download and run nZDM Java GUI.

2.     Connect nZDM Java GUI to the source (production) system

Connect the nZDM Java GUI to one of the application servers of the source system.

022-HACS1.png

3.     Start recording

Initialize recording of the database changes on the production system.


4.     Split the cluster / break HA

Remove from the cluster the node that will be used as a target system.

023-HACS2.png

5.     Isolate the removed node

Configure the isolation (network fencing) of the removed node to avoid conflict with the source (production) system.


6.     Add one Java Application Server (AS) to the removed node

Add an application server to the node that was removed from the cluster and create new Java system (target). That application server will be used for the connection between the target system and the nZDM Java GUI.

7.     Start the target system

When the removed node is started it starts as a target system.

024-HACS3.png

8.     Update the target system

Perform the desired maintenance activities on the target system.

025-HACS4.png

9.     (optional) Test the updated system

The updated target system can be tested before replacing the production system. No production system downtime is required for while testing on the target system. However, Before performing tests it is important to do a backup of the target system. After the tests, the target system is restored to that backup.


10.   Create cluster from the target system

Configure a HA cluster from the target system.


11.   Connect nZDM Java GUI to the target system

Connect the nZDM Java GUI to the application server, added to the target system.

026-HACS5.png

12.   Start DB data replication from the source system to the target system

Replicate all available data changes from the source’s DB to the target system.

027-HACS6.png

13.   Stop source system / enter downtime phase

To replicate the last data changes the source system is stopped, starting the downtime phase. Only the DB of the source system remains active so that the replication can be finished. This phase is activated via the nZDM GUI.

028-HACS7.png

14.   Stop and unfence target system

After finishing the replication, the updated target system is stopped and unfenced.

15.   Reconfigure application servers

Reconnect the application servers to the updated system.

030-HACS8.png

16.   Recreate the high availability system

To complete the process we must recreate the high availability setup of the production system. This is done by adding the former source system to the cluster we created with the updated system. Once the nodes are synced (via the HA software) the HA setup is restored and the system is successfully updated.

031-HACS9.png


* The steps described above are highly dependent on the system’s specific setup. Therefore on a different system than the one used in this scenario there will be differences in the steps.

Conclusion

The nZDM Java procedure offers a flexible and effective solution for updating SAP Java systems. It also supports various High Availability landscapes of SAP Java systems. The main benefits of the procedure are the significantly reduced downtime and the ability to test the updated system before making it a production system, minimizing the risk of possible problems.



Further Information


nZDM Java user guides are available at http://service.sap.com/sltoolset -> SL Toolset -> Software Logistics Toolset 1.0 -> section “Documentation” -> Expand All -> System Maintenance -> near-Zero Downtime Maintenance <version> Java.

nZDM Java GUI archive can be downloaded by going to http://service.sap.com/sltoolset -> SL Toolset -> Software Logistics Toolset 1.0 -> “near-zero downtime Maintenance for (nZDM) for Java” -> Download


Central note for nZDM Java for SP14

Central note for nZDM Java for SP13

Minimizing planned downtime during maintenance

What is High Availability system?

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Kumar Avi

    While using nzdm method – system switch in a virtualized environment network fencing is not possible\allowed. How can we isolate the target system?

    Can we achieve isolation by using different Virtual host-names for source and target ? e.g.

    Source : virtualcs01 \ virtualci01 \virtualdb01
    Target : virtualcs02 \ virtualci02 \virtualdb02

    Will nzdm work in this scenario.

    (0) 

Leave a Reply