Deploy and Migrate an SAP Landscape to Azure
The course is part of this learning path
After planning and researching the migration of an SAP landscape to Azure, words must become action. In Deploy and Migrate as SAP Landscape to Azure, we look at how crucial infrastructure components can be deployed and configured in preparation for migrating servers and data from "on-premises" to the Azure cloud.
This course looks at deployment and migration options and tools and services available within the Azure and broader Microsoft ecosystem that will save you time and effort. We touch on SAP-specific issues you need to be aware of and general best practices for Azure resources deployment. The Deployment and Migration course builds on Designing a Migration Strategy for SAP and Designing an Azure Infrastructure for SAP courses.
- Understand the methods for deploying VMs and prerequisites for hosting SAP
- Learn about ExpressRoute, Azure Load Balancer, and Accelerated networking
- Understand how to deploy Azure resources
- Learn about Desired State Configuration and policy compliance
- Learn about general database and version-specific storage configuration in Azure
- Learn about the SQL Server Migration Assistant and Azure Migration tools
This course is intended for anyone looking to migrate their SAP infrastructure to Azure.
Desired state configuration is exactly what it sounds like and addresses the ongoing problem of configuration drift in Windows and Linux operating systems on physical and virtual machines. DSC is designed to assist in solving administration issues like:
- Are all machines conforming to their intended configuration as when they were originally deployed?
- How can unintended changes to a machine's configuration by people and applications be prevented?
- How can new machines be deployed with the same configuration as those performing the same role?
- How can access permission to change a machine's configuration be enforced and managed?
- How can a machine's or group of machines' configurations be updated with minimal downtime?
This nirvana of configuration stability can be achieved with Azure Automation Desired State Configuration. Automation DSC will allow you to deploy, maintain and monitor infrastructure resources from the cloud, even across hybrid environments, making sure that physical and virtual machines conform to intended and pre-defined configurations.
Essentially Azure Automation State Configuration takes PowerShell Desired State Configuration functionality and wraps it in a user friendlier experience allowing you to create, manage, apply, and report on DSC resources and their implemented configurations. The DSC resources are stored on an Automation DSC server where machines can pull the desired state configurations and apply them, ensuring they are in a conforming state, reporting back their compliance or lack of.
Azure allows you to access resources' compliance to predefined policies and quickly identify those that are non-compliant. The assessment is performed by comparing a resource's properties with a known policy definition defined in a JSON template. This is an extension of the ARM template paradigm, which makes sense – no need to reinvent the wheel. Like all resources, policies can be assigned in a multitude of ways, through the portal, with PowerShell or Azure CLI. Here we are assigning a predefined policy through the portal to identify Azure VMs that don't use managed disks.
If we look at the policy detail, we can see the JSON definition, shown here on the left, where the policy definition id is the third line from the bottom. On the right is an ARM template for deploying the policy with the policy assignment name parameter default value made up from the policy definition id and resource group.
No matter the OS, a single instance of a VM is guaranteed up-time and connectivity of 99.9%. If you deploy two or more instances of a VM within a data center in an Availability Set, you are guaranteed 99.95% up-time. When the instances are deployed across multiple data centers in an Availability Zone configuration, at least 99.99% connectivity is guaranteed. At 99.99%, you can still potentially face over 52 minutes a year of interrupted service. A minute a week during off-peak hours might be OK if there were no follow-on consequences, but 26 minutes twice a year during crucial peak load periods is unsatisfactory. To take advantage of Azures' single instance SLA, all disks attached to a VM must be either Premium or Ultra SSDs.
When it comes to the database setup, the system's heart, it is recommended to deploy a hot standby backup database server. At a minimum, this should be two VMs in an Availability Set at another data center in the same region with database replication from the primary servers. The assumption being the primary servers are also in an Availability Set configuration. The backup servers are deployed in the same virtual network. Depending on the DBMS, replication can be facilitated via HANA System Replication, Oracle Data Guard, or SQL Server Always On technologies. For added peace of mind, in the unlikely but possible case of a complete Azure region outage, you can deploy an asynchronously replicating database VM in another Azure region.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.