Microsoft Technical Training11 March 2015
Renaissance Kuala Lumpur Hotel
SAP on Microsoft Azure
Planning and Implementing SAP on Microsoft Azure March 2015
Introductions ½ hour
Cloud Computing Overview ½ hour
Microsoft Azure ½ hour
Microsoft Azure Infrastructure as a Service (IaaS) ½ hour
SAP on Microsoft Azure 2 hours
Lunch 1 hour
SQL Server for SAP on Microsoft Azure 2 hours
Azure IaaS Virtual Machines 1.5 hours
Monitoring Extensions for SAP on Azure ½ 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
Hosting & Cloud
Yo
u s
cale
, m
ake r
esi
lien
t an
d m
an
ag
e
Microsoft Azure Global Presence
US North Central
Asia Pacific Southeast
Asia Pacific East
Europe North
Europe West
US South Central
US EastUS West
Major datacenter
CDN node
Japan West
Japan East
Brazil South
Australia East and
Australia West
Current as at August 2014
China East and China
West*
*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-to-
site 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
Microsoft Azure
Azure BLOB Storage
VHD1
Operating
System
(Windows/Linux)
VHD2
Data1
VHD…
Data…
Azure
Compute
Node
Azure
Virtual
Machine
Temporary
Storage Disk
Azure Compute
Node
Azure Compute
Node
Azure BLOB Storage
Microsoft Azure VMs in a Virtual NetworkMicrosoft Azure IaaS Virtual Machine components deployed across Microsoft Azure and connected to the customer network
VHD1
OS
VHD2
Data1
VHD…
Data…
VM
Temp
Microsoft Azure
VHD1
OS
VHD2
Data1
VHD…
Data…
VM
Temp
VHD1
OS
VHD2
Data1
VHD…
Data…
VM
Temp
Azure Virtual Network
Internet VPN
ExpressRoute Services
Customer Network
Microsoft Azure IaaS Virtual Machine Types (Standard Tier)
VM Name CPU Cores Memory # Data
Disks
G1 2 24 2
G2 4 56 4
G3 8 112 8
G4 16 224 16
G5 32 448 32
G-Series – Largest VM sizes (coming very soon)
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 800Current as at October 2014
D-Series VMs, SSD D: drive and
Microsoft Azure IaaS Virtual Machine Types (Standard Tier)
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
G-Series – Largest VM sizes (coming very soon)
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 800Current 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 co-
locate 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 6th 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 DomainsPlanning 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
Azure Compute Node
Microsoft Azure
Azure Compute Node
Azure BLOB Storage
VHD VHD VHD VHD
VHD VHD VHD VHD
VHD VHD VHD VHD
Azure Compute Node
Loss of Compute Node
Availability Set 1
Availability Set 2
Availability Sets II: Upgrade DomainsPlanned 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
Azure Compute Node
Microsoft Azure
Azure Compute Node
Azure BLOB Storage
VHD VHD VHD VHD
VHD VHD VHD VHD
VHD VHD VHD VHD
Azure Compute Node
Loss of Compute Node
Availability Set 1
Availability Set 2
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 CertificationProduction-certified May 2014
Note 1928533 - SAP Applications on Azure: Supported Products and Azure VM types
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
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
ScenariosRecommended 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.
VPN
Hybrid IT Scenario SAP Virtual Machines on Azure with persistent connectivity back to the customer network.
Microsoft Azure
Azure Virtual Network
Azure Compute Node
Azure Compute Node
Azure BLOB Storage
VHD VHD VHD VHD
VHD VHD VHD VHD
VHD VHD VHD VHD
Azure Compute Node
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.
ExpressRoute
Support RequirementsNote 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
ComponentsImportant 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
Azure Compute
Node
Azure BLOB Storage
Microsoft Azure
Azure Virtual Network
VHD1 VHD2 VHD3 VHD4
A5 VM
2 Core
14 GB
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
TempDB
Log
SQL Log
File
Temp;
Page
File
2 Tier - Virtual Machine Type A5 – 2 CPU Core; 14 GB RAM; 4 VHDs
SAP 2 Tier Configuration
Azure Compute
Node
Azure BLOB Storage
Microsoft Azure
Azure Virtual Network
VHD1 VHD2 VHD3 VHD4 VHD5 VHD6 VHD7 VHD8
A6 VM
4 Core
28 GB
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
2 Tier - Virtual Machine Type A6 – 4 CPU Core; 28 GB RAM; 8 VHDs
SAP 3 Tier Configuration3 Tier - Virtual Machine Types A5 – 4 CPU Core; 28 GB RAM; 4 VHDs
Azure Compute
Node
Azure BLOB Storage
Microsoft Azure
Azure Virtual Network
VHD1 VHD2 VHD3 VHD4
A5 VM
2 Core
14 GB
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
Azure Compute
Node
CI
A5 VM
Azure Compute
Node
App 1
A5 VM
App 2
A5 VM
VHD1/usr/sap
/<SID>
VHD1/usr/sap
/<SID>
VHD1/usr/sap
/<SID>
Azure BLOB Storage
SAP Systems with SQL Data Files directly in Azure Blob Storage
Azure Compute
Node
Microsoft Azure
Azure Virtual Network
A5 VM
2 Core
14 GB
Temp;
Page
File
2 Tier example illustrating SQL Server database layout directly in Azure
VHD1
Disk 1
OS
C:\
SQL
Exec;
/usr/sap
/<SID>
TEMPDB
DB & Log Files
.mdf
.ndf
.ldf
http://contoso.blob.core.windows.net/ECD/ECDDATA1.mdf
SAP <SID>
DB & Log Files
.mdf
.ndf
.ldf
Customer
Network
Internet
High-AvailabilitySAP 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-AvailabilitySAP 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.
40
High-AvailabilityDatabase 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-in-
microsoft-azure-portal-gallery.aspx
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-continuity-
with-azure/
Backup and RestoreOptions for backing up SAP Systems running in Azure
43
• 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
Installing new SAP systems for Azure
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 systems on-premise
Installing new SAP systems for 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.
Installing directly in Azure
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 AzurePlatform 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 on-
premise
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 AzureSupported Versions
49
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
SQL Server Sizing and Performance recommendationsConfiguration 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 PerformanceSample file system layout for 2-tier SAP on SQL in Microsoft Azure
51
Azure Compute
Node
Azure BLOB Storage
Microsoft Azure
Azure Virtual Network
VHD5 VHD6 VHD7
A8 VM
8 Core
56 GB
(Striped)
SQL Log File
TempDB Log
Temp;
Page
File
VHD1 VHD2 VHD3 VHD4 VHD5 VHD6 VHD7 VHD8 VHD9
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
High-AvailabilityGeneral 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-AvailabilitySQL 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-portal-
gallery.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 GalleryChanging the SQL Server Collation
54
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.
Native Azure Data & Log File storageAzure storage as the data file/log file host
Backup and RestoreSAP 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
57
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 ;
Backup and RestoreSAP 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
60
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. [email protected]; [email protected])
Microsoft Azure Virtual MachinesAzure Management Portal View
61
https://manage.windowsazure.com
https://portal.azure.com/
Microsoft Azure Virtual MachinesCreating your first IaaS Virtual Machine
62
From the Azure Management Portal, go to Virtual Machines New
Compute Virtual Machines Quick Create
Microsoft Azure Virtual MachinesCreating your first IaaS Virtual Machine
63
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.
Virtual Machine VHD’s in Azure Blob Storage
64
How to Create or Upload your SAP systems I
65
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
How to Create or Upload your SAP systems II
66
3rd party software (Ex. CloudXplorer by ClumsyLeaf Software)
Full list: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/04/17/windows-azure-storage-explorers.aspx
SQL Server Management StudioNative access to Azure Blob Storage
67
Virtual Machine Backup and Restore
68
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.
69
Reasons and Prerequisites
70
Azure Enhanced Monitoring for SAP
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
Azure Monitoring Extension for SAPCommunication 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
73
Your
organization
Your SAP
team
Your
SAP
SI
Alignment briefing Architecture/Design Validate
Business case
• Azure for SAP trial environment - 3 months free
• Specialist SAP migration Partner services
• SAP Partner Architect engagement
Plan/Cost
Partner with us on your SAP platform/cloud journey with us by 31st March
MSFT
SAP
Partner
Architect
MSFT
SAP
data
platform
& cloud
specialist
partner
74