Accelerating transformation with SAP on Azure
Microsoft continues to expand its presence in the cloud by building more data centers globally, with over 61 Azure regions in 140 countries. They are expanding their reach and capabilities to meet all the customer needs. The transition from a cloudless domain like DRDC to the entire cloud platform is possible within no time, and a serverless future awaits. Microsoft gives the platform to build and innovate at a rapid speed. Microsoft is enhancing new capabilities to meet cloud services' demands and needs, from IaaS to PaaS Data, AI, ML, and IoT. There are over 600 services available on Azure with a cloud adoption framework and enterprise-scale landing zone. Many companies look at Microsoft Azure security compliance as a significant migration driver. Microsoft Azure has an extensive list of compliance certifications across the globe. The Microsoft services have several beneficial characteristics; capabilities are broad, deep, and suited to any industry, along with a global network of skilled professionals and partners. Expertise in the Microsoft portfolio includes both technology integration and digital transformation. Accountability for the long term, addressing complex challenges while mitigating risk. Flexibility to engage in the way that works for you with the global reach to satisfy the target business audience.
SAP and Microsoft Azure
SAP and Microsoft bring together the power of industry-specific best practices, reference architectures, and professional services and support to simplify and safeguard your migration to SAP in the cloud and help manage the ongoing business operations now and in the future. SAP and Microsoft have collaborated to design and deliver a seamless, optimized experience to help manage migration and business operations as you move from on-premises editions of SAP solutions to SAP S/4 HANA on Microsoft Azure. It reduces complexity, minimizes costs, and supports end-to-end SAP migration and operations strategy, platform, and services. As a result, one can safeguard the cloud migration with out-of-box functionality and industry-specific best practices while immaculately handling the risk and optimizing the IT environment. Furthermore, the migration assimilates best-in-class technologies from SAP and Microsoft, packed with a unified business cloud platform.
SAP Deployment Options on Azure
SAP system is deployed on-premises or in Azure. One can deploy different systems into different landscapes either on Azure or on-premises. SAP HANA on Azure large instances intend to host the SAP application layer of SAP systems in Virtual Machines and the related SAP HANA instance on the unit in the 'SAP HANA Azure Large Instance Stamp.' 'A Large Instance Stamp' is a hardware infrastructure stack that is SAP HANA TDI certified and dedicated to running SAP HANA instances within Azure. 'SAP HANA Large Instances' is the official name for the solution in Azure to run HANA instances on SAP HANA TDI certified hardware that gets deployed in ‘Large Instance Stamps’ in different Azure regions. SAP or HANA Large Instances or HLI are physical servers meaning bare metal servers. HLI does not reside in the same data center as Azure services but is in close proximity and connected through high throughput links to satisfy SAP HANA network latency requirements. HLI comes in two flavors- Type 1 and 2. IaaS can install SAP HANA on a virtual machine running on Azure. Running SAP HANA on IaaS supports more Linux versions than HLI. For example, you can install SAP Netweaver on Windows and Linux IaaS Virtual Machines on Azure. SAP HANA can only run on RedHat and SUSE, while NetWeaver can run on windows SQL and Linux.
Azure Virtual Network
Azure Virtual Network or VNET is a core foundation of the infrastructure implementation on Azure. The VNET can be a communication boundary for those resources that need to communicate. You can have multiple VNETs in your subscription. If they weren't connected, we could call them Pierre in Azure wall; there will be no traffic flow in between. They can also share the same IP range. Understanding the requirements and proper setup is essential as changing them later, especially with the running production workloads, could cause downtime. When you provision a VNET, The private blocks must allocate address space. If you plan to connect multiple VNETs, you cannot have an overlapping address space. The IP range should not clash or overlap with the IP addressing in Azure while connecting on-premise to Azure via express route or site-site VPN. Configuring VNET to the IP address space becomes a DHP service. You can configure VNET with the DNS server's IP addresses to resolve services on-premise.VNETS can be split into different subnets and communicate freely with each other. Network security groups or NSGs are the control planes we use to filter traffic. NSGs are stateful but simple firewall rules based on the source and destination IP and ports.
Azure Virtual Gateway
For extensive connectivity, you must create a virtual gateway subnet. When you create a virtual gateway, you will get prompted for two options: VPN or Express Route Gateway; with VPN, you cannot connect to the Express Route Circuit. If you choose the Express Route Virtual Gateway, you can combine both.
There are two types of VPN;
1) The point-to-site VPN is used for testing and gives the lowest throughput.
2) The site-site VPN connection can offer better benefits by bridging networks.
This VPN offers zero support for SLA and uses this connection as a backup for the recommended connection on Azure, called the express route. Express route is a dedicated circuit using hardware installed on your data center, with a constant link to ‘Microsoft Azure Edge’ devices. Express route is inevitable for maintaining the communication between application VNET running in Azure and on-premise systems to HLI servers. The express route is safer and more resilient than VPN as it provides a connection through a single circuit and facilitates second redundancy; this helps route traffic between SAP application servers inside Azure and enables low latency. Furthermore, the fast path allows routine traffic between SAP application servers inside Azure VNET and HLI through an optimized route that bypasses the virtual network gateway and directly hops through edge routers to HLA servers. Therefore, an ultra-performance express route gateway must have a Fast Path feature.
SAP HANA Architecture (VM)
This design gets centered on the SAP HANA backend on the Linux Suse or RedHat distributions. Even though the Linux OS implementation is the same, the vendor licensing differs. It incorporates always-on replication and utilizes synchronous and asynchronous replication to meet the HANA DB requirements. We have also introduced NetApp file share for DFS volumes used by each SAP component using Azure site recovery and building a DR plan for App ASCs and the web dispatches servers. Azure Active directory is used in synchronization with on-premises active directory, as SAP application user authenticates from on-premises to SAP landscape on Azure with Single Sign-On credentials. Azure high-speed express route gateway securely connects on-premises networks to Azure virtual machines and other resources. The request flows into highly available SAP central, SAP ABAP services ASCS and through SAP application servers running on Azure virtual machines. The on-demand request moves from the SAP App server to the SAP HANA server running on a high-performance Azure VM. Primary active and secondary standby servers run on SAP-certified virtual machines with a cluster availability of 99.95 at the OS level. Data replication is handled through HSR in synchronous mode from primary to secondary enabling zero recovery point objective. SAP HANA data is replicated through a disaster recovery VM in another Azure region through the Azure high-speed backbone network and using HSR in asynchronous mode. The disaster recovery VM can be smaller than the production VM to save costs.
SAP systems are network sensitive, so the network system must factor the design decisions into segmenting the VNETs and NSGs. To ensure network reliability, we must use low latency cross-connections with sufficient bandwidth and no packet loss. SAP is very sensitive to these metrics, and you could experience significant issues if traffic suffers latency or packet loss between the application and the SAP system. We can use proximity placement groups called PGS to force the grouping of different VM types into a single Azure data center to optimize the network latency between the different VM types to the best possible.
Security Considerations
Security is another core pillar of any design. Role-based Access control (RBAC) gets accessed through the Azure management bay. RBAC is backed up through AD using cloud-only synchronized identities. Azure AD can back up the RBAC through cloud-only or synchronized identities. RBAC will tie in those cloud or sync identities to Azure tenants, where you can give personal access to Azure for operational purposes. Network security groups are vital for securing the network traffic both within and outside the network environment. The NSGs are stateful firewalls that preserve session information. You can have a single NSG per subnet, and multiple subnets can share the same energy. Application security group or ASG handles functions such as web servers, application servers, or backend database servers combined to perform a meaningful service. Resource encryption brings the best of security with encryption in transit. SAP recommends using encryption at rest, so for the Azure storage account, we can use storage service encryption, which would use either Microsoft or customer-managed keys to manage encryption. Azure storage also adds encryption in transit, with SSL using HTTPS traffic. You can use Azure Disk Encryption (ADE) for OS and DBA encryption for SQL.
Migration of SAP Workloads to Azure
The most critical part of the migration is understanding what you are planning to migrate and accounting for dependencies, limitations, or even blockers that might stop your migration. Following an appropriate inventory process will ensure that your migration completes successfully. You can use in-hand tools to understand the current SAP landscape in the migration scope. For example, looking at your service now or CMDB catalog might reveal some of the data that expresses your SAP system. Then take that information to start drawing out your sizing in Azure. It is essential to ensure that we have a record of the current environment configuration, such as the number of servers and their names, server roles, and data about CPU and memory. It is essential to pick up the disk sizes, configuration, and throughput to ensure that your design delivers a better experience in Azure. It is also necessary to understand database replication and throughput requirements around replicas. When performing a migration, the sizing for large HANA instances is no different from sizing for HANA in general. For existing and deployment systems you want to move from other RDBMS to HANA, SAP provides several reports that run on your existing SAP systems. If migrating the database to HANA, these reports need to check the data and calculate memory requirements for the HANA instances.
When evaluating high availability and disaster recovery requirements, it is essential to consider the implications of choosing between two-tier and three-tier architectures. To avoid network contention in a two-tier arrangement, install database and Netweaver components on the same Azure VM. The database and application components get installed in three-tier configurations on separate Azure Virtual Machines. This choice has other implications regarding sizing since two-tier, and three-tier SAP ratings for a given VM differs. The high availability option is not mandatory for the SAP application servers.
You can achieve high availability by employing redundancy. To implement it, you can install individual application servers on separate Azure VMs. For example, you can achieve high availability for ASCS and SCS servers running on windows using windows failover clustering with SIOS data keeper. We can also achieve high availability with Linux clustering using Azure NetApp files. For DBMS servers, you should use DB replication technology using redundant nodes. Azure offers high availability through redundancy of its infrastructure and capabilities, such as Azure VM restarts, which play an essential role in a single VM deployment. In addition, Azure offers different SLAs depending on your configuration. For example, SAP landscapes organize SABC servers into different tiers; there are three diverse landscapes: deployment, quality assurance, and production.
Migration Strategies:- SAP landscapes to Azure
Enterprises have SAP systems for business functions like Enterprise Resource Planning(ERP), global trade, business intelligence(BI), and others. Within those systems, there are different environments like sandbox developments, tests, and production. Each horizontal row is an environment, and each vertical dimension is the SAP system for a business function. The layers at the bottom are lower-risk environments and are less critical. Those towards the top are in high-risk environments and are more critical. As you move up the stack, there is more risk in the migration process. Production is the more critical environment. The use of test environments for business continuity is of concern. The systems at the bottom are smaller and have fewer computing resources, lower availability, size requirements, and less throughput. They have the same amount of storage as the production database with a horizontal migration strategy. To gain experience with production systems on Azure, you can use a vertical approach with low-risk factors in parallel to the horizontal design.
Horizontal Migration Strategy
To limit risk, start with low-impact sandboxes or training systems. Then, if something goes wrong, there is little danger associated with users or mission-critical business functions. After gaining experience in hosting, running, and administering SAP systems in Azure, apply to the next layer of systems up the stack. Then, estimate costs, limiting expenditures, performance, and optimization potential for each layer and adjust if needed.
Vertical Migration Strategy
The cost must be on guard along with legal requirements. Move systems from the sandbox to production with the lowest risk. First, the governance, risk, compliance system, and the object Event Repository gets driven towards production. Then the higher risk elements like BI and DRP. When you have a new system, it's better to start in Azure default mode rather than putting it on-premises and moving it later. The last system you move is the highest risk, mission-critical system, usually the ERP production system. Having the most performance virtual machines, SQL, and extensive storage would be best. Consider the earliest migration of standalone systems. If you have different SAP systems, always look for upstream and downstream dependencies from one SAP system to another.
Journey to SAP on Azure
Consider two main factors for the migration of SAP HANA to the cloud. The first is the end-of-life first-generation HANA appliance, causing customers to reevaluate their platform. The second is the desire to take advantage of the early value proposition of SAP business warehouse BW on HANA in a flexible DDA model over traditional databases and later BW for HANA. As a result, numerous initial migrations of SAP HANA to Microsoft Azure have focused on SAP BW to take advantage of SAP HANA's in-memory capability for the BW workloads. In addition, using the SAP database migration option DMO with the System Migration option of SUM facilitates single-step migration from the source system on-premises to the target system residing in Azure. As a result, it minimizes the overall downtime. In general, when initiating a project to deploy SAP workloads to Azure, you should divide it into the following phases. Project preparation and planning, pilot, non-production, production preparation, go-live, and post-production.
Use Cases for SAP Implementation in Microsoft Azure
Use cases
How does Microsoft Azure help?
How do organizations benefit?
Deliver automated disaster recovery with low RPO and RTO
Azure recovery services replicate on-premises virtual machines to Azure and orchestrate failover and failback
RPO and RTO get reduced, and the cost of ownership of disaster recovery (DR) infrastructure diminishes. While the DR systems replicate, the only cost incurred is storage
Make timely changes to SAP workloads by development teams
200-300 times faster infrastructure provisioning and rollout compared to on-premises, more rapid changes by SAP application teams
Increased agility and the ability to provision instances within 20 minutes
Fund intermittently used development and test infrastructure for SAP workloads
Supports the potential to stop development and test systems at the end of business day
Savings as much as 40-75 percent in hosting costs by exercising the ability to control instances when not in use
Increase data center capacity to serve updated SAP project requests
Frees on-premises data center capacity by moving development and test for SAP workloads to Microsoft Azure without upfront investments
Flexibility to shift from capital to operational expenditures
Provide consistent training environments based on templates
Ability to store and use pre-defined images of the training environment for updated virtual machines
Cost savings by provisioning only the instances needed for training and then deleting them when the event is complete
Archive historical systems for auditing and governance
Supports migration of physical machines to virtual machines that get activated when needed
Savings of as much as 60 percent due to cheaper storage and the ability to quickly spin up systems based on need.
References
n.d. Microsoft Azure: Cloud Computing Services. Accessed June 13, 2022. http://azure.microsoft.com.
n.d. All Blog Posts. Accessed June 13, 2022. https://blogs.sap.com.
n.d. Cloud4C: Managed Cloud Services for Enterprises. Accessed June 13, 2022. https://www.cloud4c.com.
n.d. NetApp Cloud Solutions | Optimized Storage In Any Cloud. Accessed June 13, 2022. http://cloud.netapp.com.
