nZDM.ppt
Download as PPT, PDF0 likes957 views
nZDM (Near Zero Downtime Maintenance) and nZDT (Near Zero Downtime Technology) are methods to minimize downtime during SAP system updates and conversions. nZDM reduces downtime for SUM updates by performing more tasks while the system is still available, though it increases runtime. nZDT is a service offered by SAP that uses cloning to perform conversion tasks on a clone system during uptime and only requires a brief downtime for final switching to the new system. While both help lower downtime, nZDT can achieve even lower business downtimes of 8-16 hours depending on validation needed.
nZDM.ppt
- 1. 1 nZDM – Near Zero Downtime Maintenance nZDM is not possible for ● SUM with Database Migration Option (DMO) ● SUM with S/4HANA Conversion, if DMO is contained nZDM reduces downtime - but increases the runtime significantly. nZDM for SUM can be used to apply Support Packages, applying enhancement packages (EHP) or to upgrade an ABAP-based SAP Business Suite or SAP NetWeaver system. Benefits: Significant Reduction of Business Downtime compared to current standard update and upgrade tools, because more relevant deployment phases will be executed while system is still available for business users:
- 2. 2 nZDM – Test Cases Which improvement can you expect when nZDM is used in SUM? - A word of caution, these results will vary between each environment due to the size of the database, complexity of their environment and network bandwidth between data centers. This is only for the purpose of reference. The downtime minimization benefit depends on the level of your update. An update of ECC 6.0 EHP1 to EHP7 is much more beneficial than an SPS implementation of SP9 to SPS10. Therefore the main focus of customer activities is on EHP implementations or upgrades. Please find 4 examples and a comparison between the overall technical downtime with SUM without nZDM or EHPi and SUM with nZDM Based on experiences on customer site nZDM for SUM enables a minimum downtime of around 2:30h – 3:00h when implementing an EHP or running an upgrade. The overall technical downtime (= minimum downtime + post- processing) is reduced significantly although the post-processing phase is extended due to the nZDM feature to around 0:45h – 1:00h So in total we have an overall technical downtime of 3:15h – 4:00h
- 3. 3 nZDT – Near Zero Downtime Technology (SAP Service) If you are planning a system conversion for your SAP ERP 6.0 system to SAP S/4HANA 1809 or higher, either on-premise or move to a hyperscale, there are several options available regarding downtime optimization. The demand for business continuity in today’s business has challenge IT professionals to perform system upgrades with the least amount of downtime as possible. SAP NZDT (Near Zero Downtime Technology) is a service in which can help you achieve your next conversion downtime requirements. The nZDT is a service offered by SAP. It is a customer specific procedure that is technically a clone approach. When using the nZDT service, the maintenance is performed on the clone of the source system. All changes are recorded and transferred to the clone after the maintenance tasks are completed. During the final downtime, only a few activities are executed, including a switch of the production to the new system (clone). The nZDT is very flexible regarding planned downtime activities. Database upgrades or migrations, OS migrations or Unicode migrations can be done on the clone in parallel to SAP upgrades as well. The nZDT is a bigger project and not a tool that is available in the SL Toolset on the SAP Marketplace. In order to get further info, please get in contact with your main SAP contact. NZDT reduced considerably the business downtime • Table conversions are executed on the clone during the uptime • The switch to the new software and the generation (SGEN) executed during the uptime • Import of the customer’s transports and 3rd party add-ons in the uptime • Achievable business downtime 8-16 hrs depending on the necessary validation in the downtime NZDT requires a significant customer-specific effort • Additional hardware is required for the clone • Recording of changes results in a performance impact on heavily used systems • Additional testing cycles in the NZDT project have to be considered • Customer’s individual table classification
- 4. 4 nZDT – Near Zero Downtime Technology (High Level Diagram)
- 5. 5 nZDT – Hardware & Technical Requirements Example 1. ~200GB Additional DB Space for Logging Tables, DMIS SP15, NZDT Notes, Users and Authorizations 2. Clone Server with 50-60% compute and 100% DB Size of PRD 3. MWB (migration workbench) Server, APP, and DB (64GB RAM, 16 core CPU, 500GB DB Storage) DBCO Connections to Source, Clone and Target 4. App Server for DMO run at source (128GB RAM, 32 Core CPU, 2.5 TB Storage) 5. In case migrating to cloud environment - network bandwidth between on-prim Data Center and Cloud environment (5Gbps to 10Gbps) 6. MCOD Deployment. After data replay, Proxy schema would be deleted 7. Minimum requirement of app server for DMO run at target (128GB RAM, 32 Core CPU, 2.5 TB Storage)
- 6. 6 nZDT – Test Cases How much downtime was actually achieved by using nZDT for a conversion? - A word of caution, these results will vary between each environment due to the size of the database, complexity of their environment and network bandwidth between data centers. This is only for the purpose of reference. Key Tables ACDOCA = ~ 1.3 Billion records MATDOC = 120 Million records Total DB size: SAP HANA DB = 6TB Achievement: The technical downtime using nZDT was about 8.5 hours while the Business Downtime was roughly 39 hours. nZDT will help lower the Business downtime by reducing the technical timing. Post activities which also influence Business Downtime are based on system validation, testing and Basis related technical work. It should be noted that the involvement of both the technical and functional team are critical as you perform multiple cycles leading up to cutover weekend. Since the clone did most of the heavy lifting during uptime, only the delta processing occurred during the cutover weekend. This cutover was completed over the weekend with the business online on Monday morning.
- 8. Thank You