Microsoft Technical Training 11 March 2015 Renaissance Kuala Lumpur Hotel
SAP on Microsoft Azure Planning and Implementing SAP on Microsoft Azure March 2015
Introductions Cloud Computing Overview Microsoft Azure Microsoft Azure Infrastructure as a Service (IaaS) SAP on Microsoft Azure Lunch SQL Server for SAP on Microsoft Azure Azure IaaS Virtual Machines Monitoring Extensions for SAP on Azure ½ hour ½ hour ½ hour ½ hour 2 hours 1 hour 2 hours 1.5 hours ½ hour
An overview of Cloud Computing Cloud Computing originated from the simple model of leasing out excess computing capacity The progression from physical computing evolved to virtualization, on-premise, private clouds, and most recently to 3 classes of cloud computing: IaaS Infrastructure as a Service PaaS Platform as a Service SaaS Software as a Service Modern cloud services are highly tuned and highly scalable, enabling instant access to computing capacity, on demand
You scale, make resilient and manage Hosting & Cloud
Microsoft Azure Global Presence US North Central Europe North Europe West Japan East Japan West US West US East US South Central China East and China West* Major datacenter CDN node Brazil South Asia Pacific East Asia Pacific Southeast Australia East and Australia West Current as at August 2014 *partner datacenter
Microsoft Azure by the numbers 1989: The year Microsoft opened its first datacenter on its Redmond, Washington campus 1 billion customers, 20 million businesses: The number of customers and businesses in more than 90 countries that use the Microsoft cloud 90: The number of marketplaces that our cloud services are available in today 200+: The number of online services delivered by Microsoft s datacenters 24x7x365 $15 billion+: Microsoft s investment in building our huge cloud infrastructure 1 million+: The number of servers hosted in our datacenters 100+: The number of datacenters Microsoft has in its global cloud infrastructure portfolio 15 trillion+: The number of data objects we store in our datacenters 1.5 million+: The average number of requests our networks process per second 3: The number of times Microsoft s fiber optic network, one of North America s largest, could stretch to the moon and back 1.125: Microsoft s average PUE for its new datacenters. Power usage effectiveness (PUE) is a metric of datacenter energy efficiency and is the ratio of the power and cooling overhead required to support our server load. The industry average is 1.8 2.3 billion kwh: The amount of green power purchased by Microsoft as part of our carbon-neutral goal ranking as the third most purchased by any U.S. company, according to the U.S. Environmental Protection Agency 16: The number of carbon offset projects Microsoft has invested in, including projects in Brazil, Cambodia, China, Guatemala, India, Kenya, Mongolia, Peru, Turkey and the United States (including Keechi Wind Power investment announced November 4, 2013) 100%: The percentage of our servers and electronic equipment that we send to a third-party vendor for recycling and/or reselling after it has been securely decommissioned 2007: The year Microsoft began sharing its best practices for cloud infrastructure with the industry. Download our latest Top Ten Best Business Practices for Environmentally Sustainable Datacenters white paper Source: Microsoft s Cloud Infrastructure Datacenters and Network Fact Sheet, June 2014 http://cdn.globalfoundationservices.com/documents/datacenter_and_network_facts_june_2014.pdf
Azure Services and Management
Microsoft Azure Management Portal (Web and REST API)
Microsoft Azure Preview Portal
Microsoft Azure IaaS What is it? Microsoft Azure Infrastructure as a Service consists of several key components equating to the common components found in todays datacenters; as well as additional facilities designed to further take advantage of Microsoft Azure capabilities, though drastically reducing the infrastructure planning and expense obligations from the customer. Virtual Machines Units of CPU and RAM, deployed to run an Operating System (Windows or Linux) Includes OS license. Microsoft Azure BLOB Storage Highly scalable storage, providing Virtual Hard Disk (VHD) and native large data file storage (e.g. SQL Data and Log files) Network Services designed to connect Azure Virtual Machines and customer WAN Affinity Groups logical grouping of Azure Services to ensure colocation and optimized performance (5) Availability Sets Categorization of Azure VM s to ensure deployment across Fault Domains and availability Cloud Services Designed to assist in management of network resources Virtual Networks Networks created within Microsoft Azure to link Virtual Machines together VPN & ExpressRoute Connectivity options for on-premises networks; VPN offering point-to-site and site-tosite connectivity through common device configuration scripts and Windows Server; and ExpressRoute with increasing degrees of bandwidth and latency over VPN
Microsoft Azure Virtual Machines Microsoft Azure IaaS Single Virtual Machine components Operating System (Windows/Linux) Data1 Data Temporary Storage Disk VHD1 VHD2 VHD Azure Virtual Machine Azure BLOB Storage Azure Compute Node Microsoft Azure
Microsoft Azure VMs in a Virtual Network Microsoft Azure IaaS Virtual Machine components deployed across Microsoft Azure and connected to the customer network Azure BLOB Storage Azure Compute Node Azure Compute Node OS Data1 Data Temp Customer Network VHD1 VHD2 VHD VM Internet VPN OS Data1 Data Temp VHD1 VHD2 VHD VM OS Data1 Data Temp VHD1 VHD2 VHD VM Microsoft Azure Azure Virtual Network ExpressRoute Services
Microsoft Azure IaaS Virtual Machine Types (Standard Tier) G-Series Largest VM sizes (coming very soon) VM Name CPU Cores Memory # Data Disks Memory Intensive Instances G1 2 24 2 G2 4 56 4 G3 8 112 8 G4 16 224 16 G5 32 448 32 VM Name CPU Cores Memory # Data Disks IOPS SSD (D-series) A5 / D11 * 2 14 GB 4 4 x 500 100 A6 / D12 * 4 28 Gb 8 8 x 500 200 A7 / D13 * 8 56 GB 16 16 x 500 400 Compute Intensive Instances VM Size CPU Cores Memory # Data Disks IOPS SSD (D-series) A8 / D13 * 8 56 GB 16 16 x 500 400 A9 / D14 * 16 112 Gb 16 16 x 500 800 Current as at October 2014 D-Series VMs, SSD D: drive and
Microsoft Azure IaaS Virtual Machine Types (Standard Tier) G-Series Largest VM sizes (coming very soon) VM Name CPU Cores Memory # Data Disks SAPS G1 2 24 2 2,200 G2 4 56 4 4,400 G3 8 112 8 8,800 G4 16 224 16 17,600 G5 32 448 32 36,000 Memory Intensive Instances VM Name CPU Cores Memory # Data Disks IOPS SSD (D-series) A5 / D11 * 2 14 GB 4 4 x 500 100 A6 / D12 * 4 28 Gb 8 8 x 500 200 A7 / D13 * 8 56 GB 16 16 x 500 400 Compute Intensive Instances VM Size CPU Cores Memory # Data Disks IOPS SSD (D-series) A8 / D13 * 8 56 GB 16 16 x 500 400 A9 / D14 * 16 112 Gb 16 16 x 500 800 Current as at October 2014 D-Series VMs, SSD D: drive and
Azure Blob Storage concepts Persistent Virtual Machine VHDs are stored in Azure Blob Storage, attached at VM configuration time and exist through start/stop/restart and allocation/de-allocation of Virtual Machines to Compute Nodes. Azure Storage accounts are allocated to Azure subscriptions (multiple storage accounts can exist within a subscription) and are organized in a hierarchical fashion, with VHD s being stored in individual containers within the storage account. Each Azure subscription can have up to 50 Azure Storage Accounts. VHD s are Page BLOB objects (optimized for frequent read/write) are up to 1 TB in size, provide up to 500 IOPS each, need to be fixed (i.e. not dynamic) and are the location where you install the OS, applications or databases and store data. Azure Storage accounts have a 20,000 IOPS limit per account, so it is important to manage your SAP system deployments across storage accounts to achieve optimal performance. Note: VHDX format hard drives are not supported on Microsoft Azure IaaS
Microsoft Azure Page Blob Storage and Data Disks Microsoft Azure Infrastructure as a Service (IaaS) Virtual Machines have access to two types of storage: 1 x Temporary, non-persistent storage disk Multiple, persistent VHD s stored in Azure Page Blob Storage Temporary storage exists on the compute nodes that the Virtual Machines are allocated to and can be used for non-permanent data, like the OS Pagefile. It does not persist through VM de-allocation. This is commonly the D: Drive, but can be changed from within the VM. The VHD s attached to your IaaS Virtual Machines are stored in BLOB Storage, are triple redundant (at a minimum with LRS), optimized for frequent read/write and are the cornerstone to build your Virtual Machines. The Operating System is installed to the first disk, and subsequent disks are available from within the operating system for various uses. VHDs are created or uploaded as Disks within Blob storage. Images are either supplied from the VM depot or created from existing Disks, and used as a template to create a new VM. Larger Virtual Machine types allow more VHD s to be attached than smaller Virtual Machine Types. (e.g. A0 = 1 VHD; A9 = up to 16 VHD s)
Affinity Groups Within Microsoft Azure s global datacenter network, selecting the Azure region to deploy Virtual Machines provides a coarse granularity of control over the VM deployment location and little guarantee of networking communication performance, across hundreds of thousands of compute nodes within the datacenter. Affinity Groups are an Azure Virtual Machine attribute indicating to Microsoft Azure to co-locate specific Azure Virtual Machines to ensure optimal communication between compute and storage clusters and store the VHDs as close to their respective VMs as possible. It is ideal to have all the Cloud Services within one region assigned to a single Affinity Group in order to optimize low-latency system-to-system communication (ex. ECC to BW.)
Availability Sets Within Microsoft Azure s datacenters, compute nodes are divided into Fault Domains and Upgrade Domains, in order to safeguard against, respectively, localized hardware failure (Server, rack, network, power) and to allow for orderly maintenance of the computer nodes. Availability Sets are an Azure Virtual Machine attribute indicating to Microsoft Azure to NOT colocate specific Azure Virtual Machines on the same compute nodes, in order to ensure availability and manage VM planned maintenance through a mechanism that allows for service continuity. These Availability Sets can safely protect a maximum of 5 Virtual Machines at a time. In the case of a 6 th VM being placed in an Availability Set, there is a chance that it is collocated with another VM in the same Availability Set, thereby reducing the protection offered. It is recommended to collocate VMs hosting similar services within Availability Sets to ensure Service Continuity. In the case of SAP, this means Application Servers and Database Servers separated, each within their own Availability Set.
Availability Sets I: Fault Domains Planning for resilient Virtual Machine Availability When you deploy multiple Virtual Machines, there are steps that can be taken to ensure that potential outages limit the impact on running applications. Availability Sets ensure that Virtual Machines within them do not get deployed within the same fault or upgrade domains, thereby limiting the impact of hardware/server/rack failures. Azure Virtual Network Loss of Compute Node Azure Compute Node Azure Compute Node Azure Compute Node Azure BLOB Storage Availability Set 1 VHD VHD VHD VHD VHD VHD VHD VHD Availability Set 2 VHD VHD VHD VHD Microsoft Azure
Availability Sets II: Upgrade Domains Planned Azure Infrastructure Maintenance Similar to the potential for Single Points of Failure (SPOFs) with servers, racks and hardware; planned maintenance of Azure Infrastructure can disrupt Virtual Machine Availability. Azure Maintenance awareness is typically advertised via email and RSS feed with sufficient advance notice to plan around outages, and normally outside of typical business hours for the regional datacenter. Azure Virtual Network Loss of Compute Node Azure Compute Node Azure Compute Node Azure Compute Node Azure BLOB Storage Availability Set 1 VHD VHD VHD VHD VHD VHD VHD VHD Availability Set 2 VHD VHD VHD VHD Microsoft Azure
Microsoft Azure Virtual Networks One of the most important aspects of deploying SAP on Microsoft Azure is a robust network architecture that will support your SAP deployments requirements, either entirely in Azure, or in the Hybrid-IT scenario. It is also important to recognize one of the main impacting factors in cloud deployments; bandwidth and latency in network communications within Azure, within your network and between the Azure and your network sites. Some important features of the Azure network deployments that are not common to on-premises deployments: Cloud Services An efficient method for deploying private network resources like DHCP, gateway, and Azure DNS. 1 Cloud Service to many VM relationship. Virtual Networks A self-contained virtual network that you can deploy. 1 Virtual Network to many VM relationship. Virtual Machine Endpoints TCP Ports exposed on each Virtual Machine to allow applications/services communication, by default on the *.cloudapp.net domain, or alternately on the customer-specified domain.
Microsoft Azure Virtual Network planning IP Addressing & Sub-netting Virtual Machines in Azure are, by default, allocated dynamic IP addresses through DHCP which persist through the existence of the VM deployment. Once deallocated from Azure that IP address may change when allocated again. Static IP addresses can also be assigned to specific VMs, at creation or afterwards. Proper allocation of subnets to allow sufficient IP addresses is an important consideration when structuring Azure Virtual Networks. Active Directory Traditional on-premise Active Directory is supplemented by the directory services in Microsoft Azure, and the two can be synced to extend the on-premise identity management to Azure through the use of the Windows Azure Directory Sync Tool. Active Directory can also be deployed within an Azure Virtual Machine, for either Azure-only, or Hybrid-IT scenarios, Network Name/IP Resolution Services (i.e. DNS) can be offered through a customer-deployed DNS Virtual Machine, or through the Azure DNS capabilities
Microsoft Azure Virtual Private Networks & ExpressRoute Utilizing VPN negates the requirement to expose specific TCP ports on Virtual Machines to the Internet, resulting in a more secure deployment and reducing potential attack surfaces Point-to-Site VPN used to set up secure VPN connections between specific computers using Secure Sockets Tunneling Protocol (SSTP) Site-to-Site VPN The most Common deployment pattern In SAP Landscapes, site-to-site VPN allows for a flat or transparent network between On-premise and Azure, enabling printing, monitoring, SAP transports and other common network traffic
28
SAP on Azure Certification Production-certified May 2014 Note 1928533 - SAP Applications on Azure: Supported Products and Azure VM types SAP Product Guest Operating System RDBMS SAP Business Suite Software 1 Windows SQL Server \ Oracle \ SAP ASE SAP Business All-in-One Windows SQL Server \ Oracle \ SAP ASE SAP NetWeaver Application Server ABAP/Java 1 Windows SQL Server \ Oracle \ SAP ASE SAP HANA Developer Edition (including the HANA Client software comprised of SQLDBC, ODBO (Windows only), ODBC, AND JDBC drivers), HANA Studio, and HANA Database) SUSE, Linux N/A 1. SAP ABAP or Java Applications on SAP NetWeaver 7.0 or higher (Kernel 7.21 pl. 218 /7.21 EXT pl. 23) Operating Systems: Windows Server 2008 R2, Windows Server 2012 & Windows Server 2012 R2 Databases: Microsoft SQL Server 2008 R2 and later, Oracle 11.2.0.4 and later, SAP ASE 16.0 PL02 or later
Scenarios Recommended scenarios for running SAP on Azure There are two scenarios that customers can use to take advantage of the nature of Microsoft Azure to be a very flexible, low-cost platform for deploying SAP, although the difference is not one that most customers will have encountered in traditional datacenters. Azure-Only SAP Virtual Machines on Azure, without connectivity back to the customer network or systems Hybrid IT SAP Virtual Machines on Azure with persistent connectivity back to the customer network Disaster Recovery Utilizing Microsoft Azure storage and Virtual Machines as a Disaster Recovery target datacenter, failing over to Azure Infrastructure as a Service in the event disaster strikes. In the past, customers have adapted Technology infrastructure (Servers, networks, storage, CPU, memory) to meet the requirements of their SAP and surrounding systems deployed at their datacenters or colo facilities. With the adoption of the Azure Cloud computing platform, the technology infrastructure is abstracted in such a way as to simplify the deployment of that infrastructure as a commodity platform, to meet the requirements of the SAP application.
Hybrid IT Scenario SAP Virtual Machines on Azure with persistent connectivity back to the customer network. Customers connect to the Virtual Machines through site-to-site VPN or ExpressRoute, accessing Azure as a persistent part of their network (RFC, Printing, SAP GUI, HTTP). Typically Dev, QA, Production systems. Only supported scenario for Productive SAP systems. Azure Compute Node Azure Compute Node Azure Virtual Network Azure Compute Node Azure BLOB Storage VHD VHD VHD VHD VPN Customer Network VHD VHD VHD VHD VHD VHD VHD VHD ExpressRoute Microsoft Azure
Support Requirements Note 2015553 SAP on Microsoft Azure Support Prerequisites To ensure support from both Microsoft and SAP specific prerequisites. Azure Enhanced Monitoring Extensions for SAP are deployed correctly to every instance of SAP on Azure Deployment according to the technical prerequisites outlined in the 3 documents at http://msdn.microsoft.com/library/dn745892.aspx : SAP NetWeaver on Microsoft Azure Virtual Machine Services Planning and Implementation Guide SAP NetWeaver on Microsoft Azure Virtual Machine Services Deployment Guide DBMS Deployment Guide for SAP on Microsoft Azure Virtual Machine Services Azure site-to-site or ExpressRoute connectivity from customer network to Azure Virtual Networks SAP 3-tier deployments cannot be split across Azure and customer network, Application Servers and DBMS Servers must exist in Azure OR on-premise SAP Application Servers and DBMS Servers must exist within the same Affinity Group and Virtual Network All VHDs for a VM must exist within the same Storage Account Microsoft Premier Support customer Not required, however general recommendation: Use the closest regional datacenter in order to minimize network latency http://service.sap.com/sap/support/notes/2015553
Components Important aspects related to SAP deployments Active Directory used to authenticate and protect Windows Administrators, Database users and SAP Service Users VPN / ExpressRoute Required to connect customer and Azure networks to allow transfer of typical SAP System traffic; SAP GUI, HTTP, SAP Transports (STMS), Remote Function Call (RFC), System Monitoring, System Center communication etc VHD s & Azure BLOB Storage An important aspect of the Database performance is the layout of the underlying filesystem for data file storage Virtual Machine Type Provides scalable compute resources, allowing a fine degree of performance control
SAP 2 Tier Configuration 2 Tier - Virtual Machine Type A5 2 CPU Core; 14 GB RAM; 4 VHDs Azure BLOB Storage Azure Compute Node Disk 1 Disk2 Disk 3 Disk 4 OS C:\ SQL Exec; /usr/sap /<SID> SQL DATA FILE 1 TempDB 1 SQL DATA FILE 2 TempDB 2 TempDB Log SQL Log File Temp; Page File VHD1 VHD2 VHD3 VHD4 A5 VM 2 Core 14 GB Azure Virtual Network Microsoft Azure
SAP 2 Tier Configuration 2 Tier - Virtual Machine Type A6 4 CPU Core; 28 GB RAM; 8 VHDs Azure BLOB Storage Azure Compute Node Disk 1 OS C:\ SQL Exec; /usr/sap /<SID> Disk2 SQL DATA FILE 1 TempDB 1 Disk 3 SQL DATA FILE 2 TempDB 2 Disk 4 SQL DATA FILE 3 TempDB 3 Disk 5 SQL DATA FILE 4 TempDB 4 Disk 7 (Striped) SQL Log File TempDB Log Temp; Page File VHD1 VHD2 VHD3 VHD4 VHD5 VHD6 VHD7 VHD8 A6 VM 4 Core 28 GB Azure Virtual Network Microsoft Azure
SAP 3 Tier Configuration 3 Tier - Virtual Machine Types A5 4 CPU Core; 28 GB RAM; 4 VHDs Azure Compute Node Azure Compute Node Azure BLOB Storage Azure Compute Node App 1 A5 VM App 2 A5 VM VHD1 /usr/sap /<SID> VHD1 /usr/sap /<SID> Disk 1 OS C:\ SQL Exec Disk2 SQL DATA FILE 1 TempDB 1 Disk 3 SQL DATA FILE 2 TempDB 2 Disk 4 SQL DATA FILE 3 SQL Log File TempDB Log Temp; Page File CI A5 VM VHD1 /usr/sap /<SID> VHD1 VHD2 VHD3 VHD4 A5 VM 2 Core 14 GB Azure Virtual Network Microsoft Azure
SAP Systems with SQL Data Files directly in Azure Blob Storage 2 Tier example illustrating SQL Server database layout directly in Azure Customer Network TEMPDB DB & Log Files.mdf.ndf Azure BLOB Storage SAP <SID> DB & Log Files.mdf.ndf Disk 1 OS C:\ SQL Exec; Azure Compute Node Temp; Page File Internet.ldf.ldf http://contoso.blob.core.windows.net/ecd/ecddata1.mdf /usr/sap /<SID> VHD1 A5 VM 2 Core 14 GB Azure Virtual Network Microsoft Azure
High-Availability SAP High Availability concepts There are 2 Single Points of Failure (SPOF) in an SAP system that require protection in the event of localized hardware failure: SAP Central Services - SAP Message Server and SAP Enqueue Server SAP Database SQL Server 2008/2012/2014 Enterprise In a conventional datacenter, the SAP SCS is protected with Windows FailOver Clustering Services (WFCS) providing a failover node that hosts standby services for the Message Server and Enqueue Server, as well as a replicated Enqueue table, holding the logical SAP Locks in the SAP system, allowing failover within seconds, often times without an interruption in services. SQL Server protects SAP data through its Log shipping, database mirroring or AlwaysOn capabilities, hosting database copies with manual or automatic failover.
High-Availability SAP High Availability within Microsoft Azure When protecting these two SPOF components within Microsoft Azure, you need to take into account the capabilities that Azure brings to address availability (Availability Sets), and the differences between on-premise and Azure. SCS In Azure, Virtual Machines cannot share disks, as they do in an SAP HA WFCS cluster, so there is no capability to protect the SCS in an automatic HA capability. The SLA for the various components that make up a Virtual Machine are as such: - Cloud service 99.95 % -> 21.6 min - Virtual Network 99.9 % -> 43.2 min - Storage 99.9% -> 43.2 min - Single VM estimate 99.9% -> 43,2 min Taken as a cumulative risk, this arrives at 99.65% total availability for a Virtual Machine and therefore the SAP system.
High-Availability Database High Availability within Microsoft Azure Database Azure Virtual Machines do not support shared VHDs, so SQL Server clustered databases are not a possibility in Azure, however SQL Server still offers several methods for protecting databases from localized failure: SQL Server Log Shipping Database Mirroring SQL Server AlwaysOn The Microsoft Azure Portal gallery offers a SQL Server AlwaysOn template that fully automates the configuration and deployment of an AlwaysOn Availability Group that can then be used to protect an SAP System database. http://blogs.technet.com/b/dataplatforminsider/archive/2014/08/25/sql-server-alwayson-offering-inmicrosoft-azure-portal-gallery.aspx 40
Disaster Recovery The goals and expectations for Disaster Recovery are different than in a High Availability event, where we expect all capability of the Primary Region to be unavailable and we look to protect the important data and then resume service out of a secondary region, separated by a considerable distance. For SAP Service Disaster Recovery, it would be important to plan to have duplicate Application Tier (CI, App servers) VMs prepared to be deployed in the case of a Disaster. This would mean that, at the declaration of a Disaster event, the de-allocated SAP App VMs are deployed in the secondary Azure region. The SQL Server Database would be protected through Log Shipping, Database Mirroring or AlwaysOn Availability Groups with an allocated and running Virtual Machine in the secondary datacenter that would become the active SAP Database. Azure Site Recovery Services offers another, less intensive option for ensuring SAP service in a disaster.
Disaster Recovery II Microsoft Azure Recovery Services http://azure.microsoft.com/en-us/services/site-recovery/ Automated protection and replication of VMs Integrated with System Center, SQL Server and Hyper-V Replica Policy driven, orchestrated recovery Customizable recovery plans On-premise to on-premise or on-premise to Azure recovery Replication and Recovery to Azure Microsoft recently acquired the cloud-based business continuity company InMage to enhance the Virtual Machine replication capabilities. InMage provides hybrid cloud business continuity across almost any platform; Windows or Linux, physical or virtual, Hyper-V or VMWare, and is now part of the Azure Recovery Services portfolio. http://blogs.microsoft.com/blog/2014/07/11/microsoft-acquires-inmage-better-business-continuitywith-azure/
Backup and Restore Options for backing up SAP Systems running in Azure Offline vs. Online Virtual Machine Backups Optimizing backup performance Traditional SQL database backups to local disk, in this case a VHD attached to the Virtual Machine SQL Database backups natively to Azure Blob Storage 43
Installing new SAP systems for Azure Installing systems on-premise The installation of new systems that will run in Azure should be done in such a way that they are optimized for Azure at the outset: The Virtual Machine specs (CPU/RAM) should closely align with the targeted VM type in Azure (e.g. A5; A7 etc.) to ensure deterministic performance. The Windows and SQL Server releases should be supported versions in Azure File system layout should be optimized to ensure proper performance once running in Azure. SQL Server Data & Log Files should be evenly spread across smaller VHD s to ensure sufficient IOPS during operation. VHDs must be type fixed (not dynamically growing) so plan accordingly for space. Installation should be done in a VM on Microsoft Hyper-V to avoid a complicated conversion process. If VMWare is the hypervisor of choice on-premise, Microsoft Tools such as System Center Virtual Machine Manager or the Microsoft Virtual Machine Converter 2.0 Solution Accelerator can be utilized to convert the Virtual Machine once installation is complete. http://www.microsoft.com/en-us/download/details.aspx?id=42497
Installing new SAP systems for Azure Installing directly in Azure The installation of systems directly in Azure simplifies new installs: The Virtual Machine size can be chosen initially and then adapted subsequently if the need changes. Ensure to tune SAP Profiles and the SQL Server database parameters (initial/max memory) accordingly Customer Images, or Azure provided images can be used File system layout should be set up initially to ensure proper performance at peak load. SQL Server Data & Log Files should be evenly spread across smaller VHD s to ensure sufficient IOPS during operation SQL Server s Proportional Fill algorithm, as described in SAP Note 1238993 - Proportional File Auto-Growth with SQL Server 2008 can be used to distribute the SAP System I/O evenly across the database data files, ensuring consistent performance. VHDs will be allocated properly initially, however this may not be sufficient over the life span of your SAP system. Plan space properly for future growth.
Migrating SAP systems to Azure Assessing a customer SAP landscape for migration to Azure has several dimensions. What is the motivation for moving to Azure? Simplicity? Flexibility? Cost? Which of the SAP landscapes are desired to be moved? (SBX/DEV/QA/TST/TRN/PRE/PRD) What is the current customer situation? Current SAP datacenter / hosting arrangements? SAP Services agreements (infrastructure / basis / functional support?) SAP systems platform? Hypervisor? SAP release versions, both technical & functional? SAP peak processing requirements? SAPS? IOPS?
47
SQL Server for SAP in Azure Platform for Hybrid Cloud SQL Server has been enhanced over several generations and has increasing capabilities that provide significant value in an IaaS Cloud deployment in Microsoft Azure. SQL Server Data Files can reside natively in Azure Blob Storage SQL Server can backup and restore directly to/from Azure Blob Storage Microsoft Azure offers several Images in the Azure Gallery with SQL pre-deployed SQL Server Virtual Machines can be deployed that include both the Windows Server and SQL Server licenses in their hourly cost SQL Server licenses through Software Assurance enjoy full mobility to be run in Azure or onpremise It is important to note that in the context of SAP on Azure, we are referring to SQL Server Enterprise deployed in an IaaS Virtual Machine, as opposed to Azure SQL Database, which is a SaaS Service and not supported for SAP deployments
SQL Server in Azure Supported Versions SQL Server is supported in several different versions for use with SAP in Azure: SQL Server 2008 R2 SQL Server 2012 SQL Server 2014 While earlier SQL versions are supported by Microsoft, for SAP deployments it was decided to support SQL Server 2008 R2 as a minimum due to it s significant SAP-related functionality. It is recommended to use the latest supported version of SQL Server due to the increasing integration capabilities (like native Azure backup and data/log file storage.) Restrictions SQL Server Failover Clustering is not supported in Azure SQL Server images in the Azure gallery are the incorrect collation for use with SAP. The collation must be changed prior to using these images 49
SQL Server Sizing and Performance recommendations Configuration Guidelines for performant SAP on Azure systems Install the SQL Server Executables on the same VHD as the OS The master, msdb and model databases can all also be located on the C:\ Locate the TempDB data and log files on the same set of VHDs as the SAP database Place SQL Server data and log files directly on Azure BLOB Storage if possible, for both the SAP Database, and TempDB Do NOT put TempDB on the temporary Azure partition (initially Drive D:\) Relates to A series VMs VHD s containing SQL Data/Log files should have an NTFS block size of 64K The SQL Server Service User should have the Perform volume maintenance tasks user right SQL Server UCS2 Page Compression is strongly recommended SQL Server s Proportional Fill algorithm, carefully managed data file free space and SQL Trace file 1117 should be used to strive for homogenous IO performance across the SQL Data Files of the SAP Database Use SQL Server to backup to native Azure Blob Storage rather than to a VHD to avoid impacting the overall system IOPS. Store backup files in separate Storage Account from SAP VHDs. Create a unique naming convention for backups to Azure Blob Storage to avoid mistakes in managing backups
SQL Server Sizing and Performance Sample file system layout for 2-tier SAP on SQL in Microsoft Azure Azure BLOB Storage Azure Compute Node OS C:\ SQL Exec; /usr/sa p/<sid > SQL DATA FILE 1 TempD B1 SQL DATA FILE 2 TempD B2 SQL DATA FILE 3 TempD B3 SQL DATA FILE 4 TempD B4 SQL DATA FILE 4 TempD B5 SQL DATA FILE 4 TempD B6 SQL DATA FILE 4 TempD B7 SQL DATA FILE 4 TempD B8 (Striped) SQL Log File TempDB Log Temp; Page File VHD1 VHD2 VHD3 VHD4 VHD5 VHD6 VHD7 VHD8 VHD9 VHD5 VHD6 VHD7 A8 VM 8 Core 56 GB Azure Virtual Network Microsoft Azure 51
High-Availability General recommendations Place the Database tier (primary & secondary's) of the SAP System into one Availability Set Place the Application Tier of the SAP system (CI, App Server 1, App Server 2 etc.) into a separate Availability Set Different Availability Sets can be used even with all the VMs part of one Cloud Service, Affinity Group and Virtual Network. Please note that there is a risk that putting more than 5 VMs into one Availability Set will mean that 2 VMs may go down at one time. Static IP addresses are now available within Azure to be assigned to VMs at creation or afterwards, and are a good idea for SAP systems to ensure that operations are not affected by the case where IP addresses for a VM may change when allocated/deallocated While Static IP addresses are recommended, name resolution should still always utilize FQDN
High-Availability SQL Server High Availability within Microsoft Azure No support at present for Clustered SQL Databases in Azure. SQL Server Log Shipping Provide fine grain control over restore timeframe allowing time lag in DB state, protecting against logical errors. Database Mirroring Failover partner defined in SAP connection string SQL Server AlwaysOn SQL Server s AlwaysOn capabilities (or database mirroring in SQL Server 2008 R2) allow synchronous or asynchronous database replicas to be mirrored much the same as on premise, however the means to implement AlwaysOn are slightly different in Microsoft Azure. AlwaysOn Availability Group can be deployed from the Microsoft Azure Portal Gallery (Recommended): http://blogs.technet.com/b/dataplatforminsider/archive/2014/08/25/sql-server-alwayson-offering-in-microsoft-azure-portalgallery.aspx AlwaysOn Availability Group (AG) Listener Manual creation needs to be created through specific steps, differing from on-premises http://msdn.microsoft.com/en-us/library/dn425027.aspx
Azure Image Gallery Changing the SQL Server Collation In order to use an image from the Azure Image Gallery, you must first change the default collation to match SAP s requirements. Open a CMD Prompt as Administrator, change to C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012 Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=Administrator /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2 Execute the sp_helpsort Stored procedure against the master database to verify the change. 54
Native Azure Data & Log File storage Azure storage as the data file/log file host
Backup and Restore SAP Database backups in Microsoft Azure Backup to VM local disk Traditional SQL Server backup to disk Backup the database to a backup file on a VHD attached to the VM, residing on BLOB Storage. Addressed through drive letter and path, much like any other SQL Server backup. This VHD can then be detached and stored for the desired retention period, in the desired Azure regional datacenter, or even in geo-redundant storage.
Native Azure Backups Azure Storage as a backup location BACKUP DATABASE[NW1] TO URL = https://<storageaccount>.blob.core.windows.net/sqlbackups/nw1_feb4_2014-2.bak' WITH CREDENTIAL = 'mycredential', STATS = 5, COMPRESSION; GO ; 57
Backup and Restore SAP Database backups in Microsoft Azure Backup natively to Azure Blob Storage SQL Server backup directly to Azure Blob storage SQL Server 2012 CU4 and later can read and write natively to Azure Blob Storage allowing the SQL backup and restore operations to address a backup file by URL and bypass the VHD on Blob storage convention. Prior SQL Server releases (starting with SQL Server 2005) can leverage the Microsoft SQL Server Backup to Microsoft Windows Azure Tool to encrypt, compress and redirect the backup to Azure Blob Storage. http://www.microsoft.com/en-us/download/details.aspx?id=40740 This backup strategy can provide a low-cost, highly-available, geographically redundant storage for backups.
59
How to get started with SAP on Azure Individuals receive a free one-month azure trial with $200 of credit. Visit http://azure.microsoft.com for more details. MSDN Subscriptions receive up to $150/month in Azure credit, including a 33% discount on rates for Virtual Machines and 25% discount on several other Azure Services. http://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-details/ Requires a Microsoft Account (e.g. tester@outlook.com; tester@hotmail.com) 60
Microsoft Azure Virtual Machines Azure Management Portal View https://manage.windowsazure.com https://portal.azure.com/ 61
Microsoft Azure Virtual Machines Creating your first IaaS Virtual Machine From the Azure Management Portal, go to Virtual Machines New Compute Virtual Machines Quick Create 62
Microsoft Azure Virtual Machines Creating your first IaaS Virtual Machine Once the Virtual Machine is created, provisioned and started, you can view it s status, properties and performance metrics through the portal, configure network endpoints or VM type. You can also connect to it through Remote Desktop, attach Virtual Hard Disks, Shutdown (de-allocate,) capture an image (for redeployment) or delete it. 63
Virtual Machine VHD s in Azure Blob Storage 64
How to Create or Upload your SAP systems I Use the Azure PowerShell Module to upload VHD Add-AzureVHD Add-AzureVhd [-Destination] <Uri> [[-BaseImageUriToPatch] <Uri>] [[-OverWrite]] [-LocalFilePath <FileInfo>] [-NumberOfThreads <int>] Example: C:\>Add-AzureVhd -Destination http://testaccount.blob.core.windows.net/vhds/win7image.vhd -LocalFilePath C:\vhd\Win7.vhd - NumberOfThreads 32 http://msdn.microsoft.com/en-us/library/dn495173.aspx 65
How to Create or Upload your SAP systems II 3 rd party software (Ex. CloudXplorer by ClumsyLeaf Software) Full list: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/04/17/windows-azure-storage-explorers.aspx 66
SQL Server Management Studio Native access to Azure Blob Storage 67
Virtual Machine Backup and Restore Differing from database backups, there is often the need to backup the central SAP System objects on the SAP global directory file system (Profiles, transports, logs, scripts, etc.) Dialog Instances are usually quicker to simply reinstall. Online The Windows Server Backup feature is a native utility in Windows (needs to be added in 2008 R2; installed by default in 2012/R2) that allows the backup of Server contents. In Server 2008 R2, you would attach a VHD as a backup target; in Server 2012/(R2) you can do the same things, or it is able to backup natively to Azure Blob storage. This involves the Microsoft Azure Recovery Service. Offline There is sometimes the need to backup the entire VM as a singular unit, in a consistent state. To achieve this, the simplest method is simply to Shutdown the Virtual machine, and make a copy of the underlying VHD s to another location in Blob Storage. Restoring the VM would consist of the reverse steps; shutting down the VM, deleting the current VHD s and copying the VHD s back from the alternative location and starting the VM up again. 68
69
Azure Enhanced Monitoring for SAP Reasons and Prerequisites As a prerequisite for support from Microsoft and SAP, the Azure Enhanced Monitoring for SAP needs to be deployed on every SAP Virtual Machine running in Azure Infrastructure as a Service. Microsoft s Azure VM Agent and Extension framework was developed in order to allow the specialized deployment of specific capabilities, with Virtual Machines after they had been deployed to Microsoft Azure. The VM Agent framework is used in conjunction with a delivered PowerShell script to install the Enhanced Monitoring components and start the communication between the SAP Kernel components (SAPOSCOL / SAP HostControl) and the Microsoft Azure Diagnostics Extension 70
Azure Monitoring Extension for SAP Communication Flow 71
Azure Enhanced Monitoring for SAP Virtual Machines deployed out of the Azure gallery since Feb 2014 will have the VM Agent installed on them, VMs uploaded or already deployed will need to download and install the VM Agent. http://go.microsoft.com/fwlink/p/?linkid=397964 Details can be found at: Note 1409604 - Virtualization on Windows: Enhanced monitoring Once that is completed, the customer will need to download and import the PowerShell Module http://go.microsoft.com/?linkid=9811175&clcid=0x409 then run the PowerShell script Update-WMConfigForSAP_GUI
Partnering for success data platform/hybrid cloud Your organization Your SAP team MSFT SAP data platform & cloud specialist partner MSFT SAP Partner Architect Your SAP SI Partner with us on your SAP platform/cloud journey with us by 31 st March Azure for SAP trial environment - 3 months free Specialist SAP migration Partner services SAP Partner Architect engagement Alignment briefing Architecture/Design Validate Plan/Cost Business case 73
74