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. Visit Us to know more about UnifyCloud's Cloud consulting services
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.
Comments
Post a Comment