Explore the nonproduction phase

Completed

In this phase, you're starting to deploy nonproduction SAP systems into Azure following a successful pilot, applying all the testing and validation tasks. All the criteria and steps applicable to the pilot do apply in this phase as well. The nonproduction environment typically includes development, unit tests, and business regression tests systems. It's recommended that at least one of them implements high availability configuration that will be used for the future production system. Other steps you need to consider during that phase include:

  1. Before moving systems from the old platform into Azure, collect resource consumption data, such as CPU usage, storage throughput, and IOPS data. This is important regarding the DBMS layer units but is also helpful in the case of the application layer units. In addition, you should measure network and storage latency.

  2. Record the availability requirements of the systems you're deploying. The goal is to determine whether nonproduction systems need to be available 24x7 or whether there are nonproduction systems that can be temporarily shut down.

  3. Determine whether you want to build your own OS images for Azure Virtual Machines or whether you want to use Azure Marketplace images. Depending on your choice, make sure to account for the licensing implications. If you decide to create your own OS images, refer to the following documentation:

  4. When deploying SAP on SLES and RHEL images from Azure Marketplace, ensure to use SAP-specific images provided by SUSE and Red Hat, respectively.

  5. Make sure you fulfill the support requirements SAP has regarding Microsoft support agreements. Information can be found in SAP Note #2015553.

  6. Identify the owners of systems being deployed to facilitate maintenance scheduling and notifications.

  7. Monitor updates to Azure documentation to identify new functionality that might affect your deployments.

  8. Monitor updates to SAP Notes related to Azure, such as SAP Note #1928533 to identify new virtual machine SKUs, or newly supported OS and DBMS releases. Take advantage of new offerings to realize the best price/performance ratio.

  9. Once again, validate the resources on SAP Notes, SAP HANA hardware directory, and SAP Product Availability Matrix (PAM) to make sure that there were no changes in supported Azure Virtual Machine SKUs, supported OS releases, and supported SAP and DBMS releases.

  10. Reference SAP HANA hardware directory regarding new HANA certified Azure Virtual Machine SKUs. For any updates, compare pricing with the SKUs you originally considered, and identify the options with the optimal price/performance ratio.

  11. Adapt your deployment scripts to apply new Azure Virtual Machine SKUs types and incorporate new features from which you can benefit.

  12. After deployment of the infrastructure, test and evaluate the network latency between SAP application layer virtual machine and DBMS virtual machine according to SAP Note #500235 and SAP Note #1100926. Evaluate the results against network latency guidance of SAP Note #1100926. The network latency should be within the moderate to good range. Make sure that none of the restrictions documented in Considerations for Azure Virtual Machines DBMS deployment for SAP workload and SAP HANA infrastructure configurations and operations on Azure apply to your deployment.

  13. Perform all the other checks included in the pilot phase before proceeding with the deployment.

  14. In migration scenarios, as part of the deployment process, record the resource consumption of systems deployed to Azure and compare it with the historical, on-premises records. Adjust Azure Virtual Machine sizing if you see that significant differences. Keep in mind that changing Azure Virtual Machine size affects its storage and network throughput. For details, refer to Sizes for virtual machines in Azure.

  15. Determine the system copy functionality and processes. The goal is to simplify copying of development and test systems to accelerate project delivery. Consider using SAP LaMa as a tool to facilitate such tasks. Since version 3.0 SP05, SAP LaMa includes a connector to Azure by default. You can use this connector to deallocate and start virtual machines, copy and relocate managed disks, and delete managed disks. With these basic operations, you can relocate, copy, clone, and refresh SAP systems by using SAP LaMa. The connector is available only in SAP LaMa Enterprise Edition.

  16. Optimize Azure role-based access, permissions, and processes to ensure separation of responsibilities, while, at the same time, streamlining your operational model.

  17. Test and document high-availability and disaster recovery-related architecture and procedures.