Tips on implementing SAP adaptive computing design with SAP LaMa on Microsoft Azure. We discuss the best options for SAP and some of the challenges faced.

1. SAP
Adaptive
Computing
Design
in
Microsoft
Azure

2. • Following on from our previous SAP LaMa Cloud Management
presentations, this slide deck provides a quick overview of the
SAP recommended approach to SAP architecture design when
operating your SAP landscape with SAP LaMa (Landscape
Management), previously SAP LVM Landscape Virtualization
Management).
• We discuss the idea of SAP Adaptive Design in Microsoft Azure.
• We highlight the potential problems this could cause with your
architecturedesign and possible mitigation.
Introduction

3. Overview
-­‐ SAP
Adaptive
Design
• A logical layer of separation between the SAP application and
the server (host) on which the SAPapplication is deployed.
• Allows redeployment of SAP applications (services) onto
different servers with reduced downtime and cost.
• Inherently more complex in design, but offers reduced
operational costs.
• Can
be
used
on-­‐premises
and
in
the
cloud
and
is
beneficial
when
using
SAP
LaMa.
• Automation is at the core of SAP LaMa and a cohesive
architecturethat is flexible will deepenthe level of automation.

4. Potential
Drivers
• Length of hostname must be <=13 characters (SAP note 611361).
• Reverse lookup must resolve back to same hostname (SAP note
129997).
• Reverse lookup response must contain required hostname on first
entry of response (if using multiple PTR records – not recommended)
(SAP note 129997).
• Domain of server hostname should satisfy cookie domain separation
across SAP Portals and across environments(DEV, TST, PRD).
• Re-­‐provisioning of SAP services onto different servers should be pain-­‐
free (a.k.a use SAP Adaptive Computing) (SAP note 962955).
• You have a desire to use SAP LaMa (see our other presentations).

5. Best
Practice
for
LaMa
• SAP
Adaptive
Design
is
highly
recommended
by
SAP
for
use
with
SAP
LaMa.
https://blogs.sap.com/2016/10/21/sap-­‐landscape-­‐
management-­‐faq-­‐lvmlama/
https://archive.sap.com/documents/docs/DOC-­‐63513

6. Example
– Service
Relocation
• With SAP Adaptive Design in place and using SAP LaMa (plus
SAP LaMa Cloud Connector for Azure) to orchestrate your SAP
systems in Microsoft Azure, it’s possible to relocate a SAP
service from one host to another.
• Service hostname (vhostname)does not change.
• Minimal impact to users.
• Fluid landscape.
• Possible benefitduringDR.
• Possible benefitduringmaintenance.
Server
“srv3.example”
Server
“srv1.example”
vhostname:
sapascs1.example
SAP
Central
Services
(active)
vhostname:
sapapas.example
SAP
Primary
App
Server

7. Example
– SAP
Portal
Cookies
• Known limitations with MYSAPSSO cookies mean it’s difficult to
adequatelysegregateSAPPortals in an SSO enabled landscape.
• SAP Adaptive Design enables different vhostname domains,
separate from the host (server) domain, which minimises
cookie overwrite or other such issues with MYSAPSSO.
Server
“srv1.ad.example”
vhostname:
sapascs1.dev.example
SAP
Central
Services
(active)

8. Other
Options
• Apart from SAP Adaptive Design, you could implement other
methods that might give the same level of flexibility as SAP
Adaptive Design but be careful, they may not be recommended
by SAP.

9. DNS
Aliases
• Not recommended by SAP, using
CNAME records in DNS with 1 IP
address for server & service.
NOTE:
Internally
SAP
uses
lookups,
even
on
same
server.
Server
“srv4.example”
vhostname:
sapaas1.example
SAP
Additional
App
Server
DNS
Name Type Value
srv1 A 10.0.0.1
srv3 A 10.0.0.3
srv4 A 10.0.0.4
10.0.0.1 PTR srv1
10.0.0.3 PTR
10.0.0.4 PTR sapaas1
srv3
10.0.0.4 PTR srv4
sapascs1
sapapas
sapaas1
CNAME
CNAME
CNAME
srv1
srv3
srv4Request
Forward
Lookup
Reverse
Lookup
Hostname
to
IP.
IP
to
hostname.

10. DNS
Aliases
– PTR
Records
• Not
recommended
by
SAP,
multiple
PTR
records
for
reverse
lookup.
• SAP
service
name
must
be
1st
in
response
(cannot
guarantee).
Forward
Lookup
Reverse
Lookup
Hostname
to
IP.
IP
to
hostname.
Server
“srv4.example”
vhostname:
sapaas1.example
SAP
Additional
App
Server
DNS
Name Type Value
srv1 A 10.0.0.1
srv3 A 10.0.0.3
srv4 A 10.0.0.4
10.0.0.1 PTR srv1
10.0.0.3 PTR
10.0.0.4 PTR sapaas1
srv3
10.0.0.4 PTR srv4
sapascs1
sapapas
sapaas1
CNAME
CNAME
CNAME
srv1
srv3
srv4

11. Multiple
IP
Addresses
• Recommended by SAP, each
service name (vhostname) has a
unique IP address.
• Better lookupperformance.
Forward
Lookup
Reverse
Lookup
Hostname
to
IP.
IP
to
hostname.
Server
“srv4.example”
vhostname:
sapaas1.example
SAP
Additional
App
Server
DNS
Name Type Value
srv1 A 10.0.0.1
srv3 A 10.0.0.3
srv4 A 10.0.0.4
10.0.0.1 PTR srv1
10.0.0.3 PTR srv3
10.0.0.4 PTR srv4
sapascs1 A 10.0.0.10
sapapas A 10.0.0.11
sapaas1 A 10.0.0.12
10.0.0.10 PTR sapascs1
10.0.0.11 PTR sapapas
10.0.0.12 PTR sapaas1

12. Multiple
IP
Addresses
in
Azure
• Azure only recently supports multiple IP addresses on one NIC.

13. Potential
Pitfall
• During a Disaster Recovery scenario, if you’re using Azure Site Recovery
(ASR) to replicate your servers, ASR currently only “recovers” primary IP
address on each NIC.
Server
“srv4.example”
Primary
IP:
10.0.0.4
Secondary
IP:
10.0.0.12
Server
“srv4.example”
Primary
IP:
10.0.1.4ASR
replication
Primary
Azure
Region DR
Azure
Region

14. Mitigation
• To work around the ASR limitation, and as per Microsoft Best Practice, you
can use a Recovery Plan script to re-­‐add the additional IP addresses.
https://docs.microsoft.com/en-­‐us/azure/site-­‐recovery/site-­‐recovery-­‐runbook-­‐
automation
https://docs.microsoft.com/en-­‐us/azure/site-­‐recovery/recovery-­‐plan-­‐overview
Server
“srv4.example”
Primary
IP:
10.0.0.4
Secondary
IP:
10.0.0.12
Server
“srv4.example”
Primary
IP:
10.0.1.4ASR
replication
Primary
Azure
Region DR
Azure
Region
Script
add IP x.x.x.x
add IP x.x.x.x
add IP x.x.x.x
Secondary
IP:
10.0.1.12

15. The
Future
• Microsoft Azure ASR may in future support multiple IP addresses.
• Whatever the effort up-­‐front, automation is the way forward.
• Building flexibility into the SAP architecture design (outside of the agility of
the cloud) will bring benefits in the future (multi-­‐cloud) and allow easy
migration of SAP services with minimal disruption (minimal re-­‐installs)
decreased costs of M&A activities.
• Easy relocation (compaction) of services could permit easier service
restoration in a catastrophic DR situation (complete Azure region failure).

16. Reference
Material
• SAP
Notes:
611361,
962955,
129997,
1928533
• SAP-­‐Press:
https://s3-­‐eu-­‐west-­‐1.amazonaws.com/gxmedia.galileo-­‐
press.de/leseproben/3841/Reading_Sample_SAPPRESS_1221_Operating_SAP_in_the_Cloud_updated.pdf
• SAP
Blogs:
https://blogs.sap.com/2016/10/21/sap-­‐landscape-­‐management-­‐faq-­‐lvmlama/
• Microsoft
Docs:
Reference
architecture:
https://docs.microsoft.com/en-­‐us/azure/architecture/reference-­‐architectures/sap/sap-­‐netweaver
Multiple
IP
support:
https://azure.microsoft.com/en-­‐gb/updates/ga-­‐multiple-­‐ips-­‐per-­‐nic/
How
to
add
multiple
IPs
to
a
NIC:
https://docs.microsoft.com/en-­‐us/azure/virtual-­‐network/virtual-­‐network-­‐multiple-­‐ip-­‐
addresses-­‐portal
https://docs.microsoft.com/en-­‐us/azure/virtual-­‐network/virtual-­‐network-­‐network-­‐interface-­‐addresses
Recovery
Automation:
https://docs.microsoft.com/en-­‐us/azure/site-­‐recovery/site-­‐recovery-­‐runbook-­‐automation
Recovery
tasks
with
SAP:
https://docs.microsoft.com/en-­‐us/azure/site-­‐recovery/site-­‐recovery-­‐sap
ASR
Support
matrix:
https://docs.microsoft.com/en-­‐us/azure/site-­‐recovery/azure-­‐to-­‐azure-­‐support-­‐matrix
SAP
with
ASR:
https://docs.microsoft.com/en-­‐us/azure/site-­‐recovery/site-­‐recovery-­‐sap
• Wikipedia:
DNS
record
types:
https://en.wikipedia.org/wiki/List_of_DNS_record_types
• Further
details
are
available
on
request
from
our
SAP
LaMa
Certified
Consultants
– mailto:info@aliterconsulting.co.uk

17. Thank-­‐you