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 / Disaster Recovery (HA/DR) 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 here:
nZDM Java: minimize the business downtime of your SAP Process Orchestration maintenance activity
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:
This approach is suitable for virtualized systems as well as HA/DR 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.
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.
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.
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.
7. Update the target system
Perform the desired maintenance activities on the target system.
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
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.
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.
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.
Recommended when there is no virtualization of the system and not suitable for High Availability / Disaster Recovery 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 / Disaster Recovery (HA/DR) SAP Java System
Depending on the scenario and the suitable approach for it, the steps of the nZDM Java procedure may differ. This section contains a step-by-step description of a successfully performed scenario of nZDM Java on HA/DR systems.
nZDM Java on HA/DR System: Cluster Clone
This approach for nZDM Java on HA/DR 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/DR ‘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/DR system setup:
0. Initial State
The system on which we perform the ‘Cluster Clone’ is a HA/DR 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/DR cluster via HA/DR 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.
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.
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.
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.
7. Update the target system
Perform the desired maintenance activities on the target system.
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
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.
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.
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.
Conclusion
The nZDM Java procedure offers a flexible and effective solution for updating SAP Java systems. It also supports various High Availability / Disaster Recovery 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 and the nZDM Java GUI are available at http://service.sap.com/sltoolset
Minimizing planned downtime during maintenance
What is High Availability system?
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 / Disaster Recovery (HA/DR) 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 here:
nZDM Java: minimize the business downtime of your SAP Process Orchestration maintenance activity
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:
- System switch
This approach is suitable for virtualized systems as well as HA/DR 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.
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.
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.
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.
7. Update the target system
Perform the desired maintenance activities on the target system.
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
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.
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.
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.
- Database switch
Recommended when there is no virtualization of the system and not suitable for High Availability / Disaster Recovery 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 / Disaster Recovery (HA/DR) SAP Java System
Depending on the scenario and the suitable approach for it, the steps of the nZDM Java procedure may differ. This section contains a step-by-step description of a successfully performed scenario of nZDM Java on HA/DR systems.
nZDM Java on HA/DR System: Cluster Clone
This approach for nZDM Java on HA/DR 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/DR ‘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/DR system setup:
0. Initial State
The system on which we perform the ‘Cluster Clone’ is a HA/DR 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/DR cluster via HA/DR 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.
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.
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.
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.
7. Update the target system
Perform the desired maintenance activities on the target system.
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
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.
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.
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.
Conclusion
The nZDM Java procedure offers a flexible and effective solution for updating SAP Java systems. It also supports various High Availability / Disaster Recovery 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 and the nZDM Java GUI are available at http://service.sap.com/sltoolset
Minimizing planned downtime during maintenance
What is High Availability system?
- SAP Managed Tags:
| User | Count |
|---|---|
| 11 | |
| 10 | |
| 10 | |
| 10 | |
| 8 | |
| 7 | |
| 7 | |
| 7 | |
| 7 | |
| 6 |
