SAP on Azure Implementation Guide

Move your business data to the cloud

Nick Morgan, Bartosz Jarkowski

• Éditeur: Packt Publishing
• Année: 2020
• ISBN:
  9781838987237
• Édition: 1
• Sujet: Computer Science
• Sous-sujet: Client-Server Computing

Learn how to migrate your SAP data to Azure simply and successfully.

Key Features

• Learn why Azure is suitable for business-critical systems
• Understand how to migrate your SAP infrastructure to Azure
• Use Lift & shift migration, Lift & migrate, Lift & migrate to HANA, or Lift & transform to S/4HANA

Book Description

Cloud technologies have now reached a level where even the most critical business systems can run on them. For most organizations SAP is the key business system. If SAP is unavailable for any reason then potentially your business stops. Because of this, it is understandable that you will be concerned whether such a critical system can run in the public cloud. However, the days when you truly ran your IT system on-premises have long since gone. Most organizations have been getting rid of their own data centers and increasingly moving to co-location facilities. In this context the public cloud is nothing more than an additional virtual data center connected to your existing network.

There are typically two main reasons why you may consider migrating SAP to Azure: You need to replace the infrastructure that is currently running SAP, or you want to migrate SAP to a new database. Depending on your goal SAP offers different migration paths. You can decide either to migrate the current workload to Azure as-is, or to combine it with changing the database and execute both activities as a single step. SAP on Azure Implementation Guide covers the main migration options to lead you through migrating your SAP data to Azure simply and successfully.

What you will learn

• Successfully migrate your SAP infrastructure to Azure
• Understand the security benefits of Azure
• See how Azure can scale to meet the most demanding of business needs
• Ensure your SAP infrastructure maintains high availability
• Increase business agility through cloud capabilities
• Leverage cloud-native capabilities to enhance SAP

Who this book is for

SAP on Azure Implementation Guide is designed to benefit existing SAP architects looking to migrate their SAP infrastructure to Azure. Whether you are an architect implementing the migration or an IT decision maker evaluating the benefits of migration, this book is for you.

2

Architect SAP on Azure

This chapter will walk you through the steps required to plan your SAP on Azure architecture. As the title suggests, the focus is on the what and the why, how you architect SAP in Azure, not the how of building it, which is in the following chapter. Depending on where you are on your journey to Azure may influence which sections you need to read. We'll begin from the initial planning stage – landscape planning, where we design the structure of basic cloud artifacts. We'll call it the landing zone. It's a set of Azure resources that allows your company to build solutions in the cloud. It includes virtual networks and connections to your on-premises data centers but also the hierarchy of resources for effective management and simplified billing.

Landscape planning

If SAP is the first or only workload in Azure, then this project will need to consider all aspects of governance, security, network design, cost management, monitoring, and so on. If your organization is already running other workloads in Azure, then most if not all this work will already have been completed, and SAP will become just another workload in Azure conforming to the standards already agreed. That said, as always SAP is slightly different to many other workloads, and we will cover some of those difference as the chapter progresses.

Most organizations will have teams of people in IT responsible for each of these areas, and it will be for those teams to make many of the decisions. If SAP is the first workload, then you will need to work with all the relevant teams to create your initial migration landing zone, what Microsoft used to call the Azure enterprise scaffold.

If your landing zone is already in place, then you may want to skip the first few sections and jump straight to sizing. However, you may still find value in reading them, as you may find that there are SAP-related considerations that may not have been fully catered for when the landing zone was created.

For those for whom SAP is the first workload that is being moved to Azure, Microsoft has published the Microsoft Cloud Adoption Framework (CAF) for Azure¹. This is a best practice guide to the process of cloud adoption in Azure, and should be reviewed before you start your journey. While it is a general guide, not specific to SAP, it identifies a lot of areas that you need to consider. Rather than repeat the content that is contained in the CAF, in this chapter we will focus more on the essential areas that need consideration if you are moving SAP to Azure.

Azure landing zone

An Azure landing zone is the foundation for deploying workloads in Azure. It should provide a structure that allows you to implement the security, governance, and management controls that you require. It is important to get the basic structure in place before you start deploying workloads into Azure, as it can be difficult or impossible to retrofit it later.

As mentioned in Chapter 1, Cloud Readiness, you can use Azure Blueprints to help deploy the Azure landing zone in a consistent and repeatable way. While you may question whether investing in developing the blueprint is worthwhile, most organizations will deploy into at least two Azure Regions for protection against disasters. Larger global organizations will often deploy into many more Azure Regions, deploying some workloads close to the end users, while others may be global systems deployed into a single or pair of regions. In addition, you should use Azure Policy to implement the governance model that you require when running workloads in Azure. These are powerful Azure-native tools, and ones generally not deployed in the on-premises world; if you do not use them you are missing out on a great opportunity to enforce your organization's policies in Azure.

From a security, governance, and management perspective, one of the de facto standards that has developed is to deploy a hub and spoke network topology as shown in Figure 2-1:

Figure 2-1: Azure hub and spoke network topology²

The hub provides the connection point for network connectivity between your existing network and Azure. It is also where you will deploy security services such as firewalls, either using a third-party Network Virtual Appliance (NVA) firewall or using the cloud-based Azure Firewall. It is also where you will normally deploy directory services by extending your on-premises Active Directory into Azure.

As you start to deploy workloads into Azure, you are likely to find other shared services that are best placed into the hub. You are likely to want Jumpbox servers to help provision and manage your workloads; these can go into the hub alongside other services such as DNS, IDS, and NTP.

The spoke virtual networks are where you will deploy SAP and other workloads. You may use separate spokes for production and non-production workloads, and restrict end user access so that they can only access the production spoke, while developers and testers have access to the non-production spoke. In many cases you may outsource the management of different workloads deployed in Azure to different service providers. Similarly, you can restrict the service provider access so that they can only have access to the spokes that contain the workloads that they manage. We will look at these in more detail in a later section of this chapter.

The Jumpbox in the hub is generally used to manage the overall deployment in that region, with access restricted to specific users. The Jumpboxes in the spokes would be used by people managing specific resources within that spoke, who may well not be permitted access to the Jumpbox in the hub.

Network connectivity

As we have just seen, the hub provides the connection point between your on-premises network and Azure. There are two main ways to connect from your network to Azure:

• Site-to-site (S2S) VPN³: This connects a VPN device on your on-premises network via the public internet to a VPN gateway in Azure
• ExpressRoute⁴: It creates a private network connection between your on-premises network and Azure data centers

The S2S VPN has the benefit of being quick to set up compared with ExpressRoute. For this reason, many customers start with an S2S VPN while they plan their ExpressRoute connectivity, and work with their telecommunications provider to get the required connectivity in place. While Microsoft strongly recommends using ExpressRoute for production SAP workloads, if you are using S2S VPN today to access your SAP systems then you may consider it adequate when SAP is hosted in Azure.

The main benefits of ExpressRoute over S2S VPN are that it offers better reliability and higher security, may offer lower latency, and can ...