The Basics of Basis Administration: Architecture ... · PDF fileThe Basics of Basis...

Preview:

Citation preview

© Copyright 2014Wellesley Information Services, Inc.

All rights reserved.

The Basics of Basis Administration: Architecture, Interfaces, Monitoring, and More!

Matt LonstineSymmetry Corporation

1

In This Session

• We will dive into the nuts and bolts of Basis Administration and provide tips for administrators to ensure your SAP landscape runs smoothly and efficiently

• For those new to Basis Administration, this session will provide the groundwork you need to succeed, and more experienced administrators will find it a useful refresher

• Come away with a clear understanding of SAP basic architecture, interfaces, monitoring techniques, and much more!

2

What We’ll Cover

• Intro the standard architecture for small, medium, and large SAP landscapes

• Overview of server equipment/infrastructure needed • Monitoring Fundamentals• System Performance Metrics and Customized Operations

Reporting• Tip to current system performance and maintenance best

practices for life of SAP application• SAP Fundamentals: pinpoint performance measurements from

hardware, database, and application layers• Database Optimization – archiving, DB compression• Monitoring and Business Expectations (IT role in Basis)• Wrap-up

3

SAP Architecture – Small

• The most simple SAP architecture took the following forms:

4

Typical Very Small SAP Landscapes

• One-time, “big bang” implementations• No ongoing rollouts• Less than 100 users, less than $100M enterprise• Appropriate for small SAP Business All-in-One implementations• QAS server often added later

5

Typical Small SAP Landscape

6

Typical Small SAP Landscape (cont.)

• Three-system landscape (per major SAP application) most common in SAP implementations

• Changes tested and promoted from DEV QAS PRD• Servers running SAP database and application processes connect

through Local Area Network (LAN) or Wide Area Network (WAN) to end users

• Usually SAP application processes and database processes run on the same server – 2-tier architecture

7

SAP Architecture – Medium

• Typically referred to as Distributed environments, load balancing becomes possible in this scenario

8

Typical Medium SAP Landscape

9

Features of a Medium SAP Landscape

• More and more SAP implementations involve multiple major SAP applications

• With larger total data storage requirements, Storage Area Network (SAN) technology starts to make sense

• An SAP Solution Manager system is required by SAP• A pre-DEV system, typically called “sandbox” (SID=SBX) becomes

necessary System to prototype new SAP functionality without impacting SAP

production or the support of production System to test new infrastructure operations

E.g., test a new tape backup device• A 3-tier architecture with multiple application servers becomes

necessary with higher concurrent SAP user counts Application servers give most flexibility/control for administrators

10

SAP Architecture – Large

• In a large configuration, all potential individual instance options are separated out into their own

11

Typical Large SAP Landscape

12

Features of a Large SAP Landscape

• Numerous systems to deploy and operate• Larger technical staff and more complex operations• Addition of a “Production break/fix” (PFX) system Copy of PRD data Used for testing of PRD problems without impacting production

or in-progress testing• Larger, more exotic SAN architecture• Deployment, operation of disaster recovery systems Additional set of “stand-by” servers to be used in case of a

disaster to primary servers Enables continued SAP application availability in the event of

the failure of primary SAP systems

13

SAP Architecture – New

• The standard SAP instance terminology has changed as of SAP NetWeaver® 7.3

14

SAP Architecture – Changes for 2014

• Support has ended in 2013 for the following items:

End of most dual-stack configuration options Most applications no longer offer a dual-stack option Separate stacks are required with the exception of Solution

Manager and PI Dual-stack option has been removed from sapinst or

Software Provisioning Manager 7.2x onward kernels (DCK) are now standard Downward-compatible kernel versions are now the only

maintained kernels

15

Major SAP Applications Requiring Separate Landscapes• SAP ERP (Enterprise Resource Planning) Major functionality or “modules” within ECC Financial Accounting (FI) Controlling (CO) Sales and Distribution (SD) Materials Management (MM) Warehouse Management (WM) Quality Management (QM) Plant Maintenance (PM) Production Planning (PP)

16

Major SAP Applications Requiring Separate Landscapes (cont.)• SAP Business Information Warehouse (SAP BW) SAP NetWeaver® Business Intelligence (SAP NetWeaver BI) Data warehousing, modeling, and reporting

• SAP Customer Relationship Management (SAP CRM) Sales-centric customer management

• SAP Supply Chain Management (SAP SCM) Planning, collaboration, and coordination of supply chain

• SAP Supplier Relationship Management (SAP SRM) Analysis, sourcing, invoicing throughout supply chain

• HANA, SAP BusinessObjects Analytics tools and Business Suite database alternative

17

Major SAP Applications Requiring Separate Landscapes (cont.)• SAP NetWeaver Master Data Management (SAP NetWeaver MDM) Centralized storage and management of Master Data

• SAP Product Lifecycle Management (SAP PLM) Manage design, production, sales, and enhancements of products

• SAP Enterprise Portal (up to 6.0); SAP NetWeaver Portal Java-based Web portal application

• SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI) Process-centric collaboration among SAP and non-SAP applications

• SAP Solution Manager Facilitates technical support for SAP systems Now mandatory

18

Major SAP Applications Requiring Separate Landscapes (cont.)• Significantly reduce total cost of operations with Solution Manager

features Project Management

Project Administration Service Desk Change Request Management Custom Development Management Solution Documentation

Central Monitoring EarlyWatch Alerts Service Level Reporting Change Reporting Central System Administration Impact Analysis Central Job Scheduling

19

What We’ll Cover

• Intro the standard architecture for small, medium, and large SAP landscapes

• Overview of server equipment/infrastructure needed • Monitoring Fundamentals• System Performance Metrics and Customized Operations

Reporting• Tip to current system performance and maintenance best

practices for life of SAP application• SAP Fundamentals: pinpoint performance measurements from

hardware, database, and application layers• Database Optimization – archiving, DB compression• Monitoring and Business Expectations (IT role in Basis)• Wrap-up

20

Modern Servers

• Computing technology is continuing to change rapidly More computing power for less money Smaller physical sizes Amount of data storage exploding exponentially A standard SAP environment 3 years ago is now ½ the physical

size and twice the performance

• Best practices for SAP server technology “refresh” No Production servers over 3 years old No other servers over 5 years old (e.g., “DEV” and “QAS”) Couple server replacements as part of SAP software upgrade

cycle

21

SAP and the Cloud

• Public cloud SAP offers cloud applications like HANA, Business Suite on

HANA There are caveats to use cases or scenarios that can be

deployed (data size, throughput, connectivity)• Private cloud This refers to a structured technical environment that includes

networking, storage, and computing power• Hybrid cloud A combination of SAP deployment between on-premise and

cloud architecture Example: On-demand testing environment in the cloud

22

Modern Servers

• Performance gains are a valuable hidden ROI An “hourglass” on the screen lasting more than a couple of

seconds breaks user’s concentration 1/10th of a second increase in response times for 200 users =

real ROI

• The first questions when tackling performance bottlenecks are: Do I have enough SAPS for the workload? Are there any bottlenecks that would limit capacity?

23

Storage

• SAP database sizes typically range in the 300GB to 1.5TB • “Hard drives” remain the staple in SAP server environments• “Spindle” count (i.e., number of hard drives) is critical in

database applications Numerous smaller disks are better than fewer larger disks Storage systems offer different “caching” features to achieve

high performance on the most frequently used data Storage systems offer tiered disk groups to present adequate

storage performance to the SAP systems Platinum disk – Production Silver disk – Quality Assurance Bronze disk – Development, Sandbox

24

Storage Technology Options

• SAN features Able to reallocate storage to different servers Lots of intelligence – caching, replication More options for copying, backing up data

• SANs are not inherently wonderful Expensive Tend be sold with a few large disks = poor database

performance Higher expertise to operate

25

SAP Storage Options

• The hardware is not the only variable in the equation HANA HANA’s speed is touted as a major selling point but

remember that the technology will become your RDBMS Using Solid State Drives (SSD) for selective tables may

provide adequate ROI HANA will support “most” SAP applications If you need to maintain a mixed RDBMS environment, you

will need to factor support and training into the equation Migrating to HANA may require upgrades, migrations There are requirements between SAP NetWeaver 7.31-7.4

and Unicode that are prerequisites to running HANA

26

Parts of an SAP Network Environment

Switch/Hub

Router

Firewall

Ethernet Cable

Wide Area Network (WAN)

27

Issues with Networking That Impact SAP

• Network bandwidth/segregation Need a big enough “pipe” for all needs, not just SAP Don’t want printers on same network as servers

• Network redundancy/reliability Dual switches/firewalls/routers If one device goes down, end users still in business

Dual networking paths If one network connection goes down, end users still in

business • Network security No hackers allowed in! Prevent introduction of viruses, etc.

28

Issues with Networking That Impact SAP (cont.)

• Network scalability Can your network grow with your needs?

• SAP GUI is considered a “light” client Not very heavy network load SAP network traffic seldom a source of trouble

• Network “maintenance” can be a big source of irritation in SAP environments

29

SAP Application Architecture – Instance

Source: Page 34, SAP R/3 System Administration, SAP PRESS

• If both the SAP application and database processes run on one physical server, it is called “2-tier architecture”

• If they run on separate physical servers, it is called “3-tier architecture”

30

SAP Application Architecture – Traditional

• When an SAP end user presses ENTER, the SAP GUI user screen data is sent (via TCP/IP network packets) to the dispatcher where it is queued for processing by a work process No network traffic until end user presses ENTER Queuing based on first-come, first-served basis SAP ABAP programs process business logic Number and type of SAP work processes is configurable The more work processes,

the shorter the “wait state” Number of work processes

limited by physical memory of server and other factors

31

SAP Application Architecture – Traditional (cont.)

• SAP Dispatcher When an SAP end user logs into an SAP system, a set of

memory is allocated on the application server by the “dispatcher” process

Dispatcher process stores user’s SAP security profile and information about user’s SAP session E.g., remembers previous screen when you click “green

arrow back”

32

SAP Application Architecture – Traditional (cont.)

• SAP Dispatcher (cont.) Size and characteristics of memory allocation set by SAP

system parameters Parameters set in a text file and read by the Dispatcher at

startup To change parameters, SAP application serving processes

must be stopped and restarted – requires an outage! Multiple application servers mitigate outages Size of memory limited by physical memory of server and

other factors

33

SAP Application Architecture – Traditional (cont.)

• Database thread SAP work processes result in simple SQL statements sent to a

coupled RDBMS “thread” process May or may not be on same physical server “2-tier architecture” means SAP and RDBMS processes run

on same server “3-tier architecture” means SAP application processes run

on a separate server from the RDBMS server

34

SAP Application Architecture – Traditional (cont.)

• Database thread (cont.) Database thread process calls the database and read/write/

update/delete actions performed Database thread returns results to SAP work process, to

dispatcher, and back to the end-user SAP GUI Large results buffered in dispatcher Downloaded to SAP GUI one page at a time Architecture makes for “light” network traffic and end-user

PC requirements

35

SAP Java Application Architecture

36

SAP Java Application Architecture – Web

• Numerous advantages to accessing SAP via a Web browser (e.g., Microsoft Internet Explorer) No PC client application to deploy and maintain “Magic” for access via mobile and other end-user devices

SAP doesn’t have to code the interface (already done by the standard browser)

End user doesn’t have to know what server they’re connecting to

Enables end-user business process orientation vs. “log-in here, log-in there” application orientation End user logs into his/her job, not into a set of computer

applications Key philosophical component of enterprise service-oriented

architecture (enterprise SOA)

37

SAP Java Application Architecture – Web (cont.)

• May not solve all your problems Performance is slower for high volume SAP users Those performing many, many transactions

More complex architecture Not all the bugs worked out

38

Security Tasks

• RSECNOTE Run bi-weekly or monthly to assess critical security gaps

affecting SAP applications Security corrections are contained in support packs Depending on support pack cycle frequency, you may be

somewhat current on security notes

Quicklink for SAP Security-related information –http://service.sap.com/public/security *

* Requires login credentials to the SAP Service Marketplace

39

Security Tasks (cont.)

40

Security Tasks (cont.)

• SAProuter The software firewall that SAP uses to provide support Don’t assume it’s secure! SAP Notes explain risks and remediation to make sure

SAProuter is secure Install the latest release Validate your saprouttab contains only current systems

and ports Think about ways to secure the SAProuter host (DMZ)

41

Security Tasks (cont.)

• Gateway security Methods as of Kernel 6.40 to secure the gateway against

unauthorized access Profile parameters gw/sec_info = $(DIR_GLOBAL)$(DIR_SEP)secinfo or gw/reg_info = $(DIR_GLOBAL)$(DIR_SEP)reginfo

Access Control Lists (ACL) maintained through reginfo or secinfo files P|D TP=name [NO=<n>] [HOST=<host>] [ACCESS=<host>]

[CANCEL=<host>]

42

What We’ll Cover

• Intro the standard architecture for small, medium, and large SAP landscapes

• Overview of server equipment/infrastructure needed • Monitoring Fundamentals• System Performance Metrics and Customized Operations

Reporting• Tip to current system performance and maintenance best

practices for life of SAP application• SAP Fundamentals: pinpoint performance measurements from

hardware, database, and application layers• Database Optimization – archiving, DB compression• Monitoring and Business Expectations (IT role in Basis)• Wrap-up

43

Daily Monitoring

• Daily Monitoring is all about being proactive CCMS or Technical Monitoring helps display key metrics

Create alerts for the checks above and other critical business functions to notify appropriate team members

OS Database SAPCPU DB File free space Work Process AvailabilityMemory DB Log free space Update AvailabilityDisk Cache performance ABAP Dump quantityPaging/Swap Backup Status System Availability

Java Memory PerformanceMany more …

44

Daily Monitoring – Database Analysis

• Consolidate DB views into SAP Solution Manager This is useful when you consider HANA, SAP BusinessObjects

which lack standard ABAP monitoring tools

45

SAP GUI and Other Connectivity

• Managing connectivity is becoming more challenging due to the multitude of options beyond SAP GUI

SAP BusinessObjects

46

SAP GUI and Other Connectivity (cont.)

• How to tackle the challenge Consolidate external access Citrix Xen

Organize delivery SAP GUI Server Central application deployments with preconfigured

connection properties Coordinate authorizations Single sign-on Active Directory, LDAP, SAP UME

47

What We’ll Cover

• Intro the standard architecture for small, medium, and large SAP landscapes

• Overview of server equipment/infrastructure needed • Monitoring Fundamentals• System Performance Metrics and Customized Operations

Reporting• Tip to current system performance and maintenance best

practices for life of SAP application• SAP Fundamentals: pinpoint performance measurements from

hardware, database, and application layers• Database Optimization – archiving, DB compression• Monitoring and Business Expectations (IT role in Basis)• Wrap-up

48

SAP Performance – SQL Analysis

• Analyze statements from transaction ST04 Poor SQL performance can be highlighted in EWA too

• Organize statements by heaviest Elapsed time, buffer requests and then by memory usage Keep in mind the number of executions to get put into

perspective how often then operations are accessed• To analyze the individual statements, execute an explanation on

the statements to examine the efficiency and estimated resource usage to perform the statement

• Look for notes on standard programs and tables that rank highly

49

Evolution of Basis

• As Analytics and Reporting have taken off, Basis responsibilities have grown to include monitoring performance related to SLT, HANA, SAP BusinessObjects, and associated applications Typical scenarios include: SLT Monitoring for active and failed queues Monitoring of SAP BusinessObjects performance, stability Monitoring HANA performance

50

Weekly Activities

• Review EarlyWatch Alerts Aggregate view of system performance and recommendations Great way to see trending information of important metrics

• Review SAP buffers performance• Review Java performance Java heap memory usage

and daily throughput

51

Quarterly/Bi-Annual Activities

• Review throughput of all application I/O areas Are there work process bottlenecks? Are there performance “hot spots”? Daily peak load periods System Activity bottlenecks (backups, nightly batch, etc.)

Review your worst performing transactions or processes SAP Services available to address SAP and custom code

between the database and application Kernel updates Develop a strategy to apply the latest or n-1 kernel version to

all systems

52

Quarterly/Bi-Annual Activities (cont.)

• Technical Upgrade Opportunities Operating System OS Patching Example, monthly patching of Windows systems

Review the SAP Product Availability Matrix for approved OS revisions or full versions

Database All Database patches must be approved and validated by

SAP Check PAM for approved DB versions like SQL Server 2008

R2 or Oracle 11.2.0.3

53

Quarterly/Bi-Annual Activities (cont.)

• Update ST-PI, ST-A/PI in all ABAP-based systems EarlyWatch Alerts and any other SAP delivered services

depend on these components being current• SAP Upgrades (Version Upgrades, Enhancement Packs, Support

Packs) Tools Upgrade Dependency Analyzer Helps identify business process dependencies and related

notes for explanations Business Function Prediction Service Uses SAP transactional history to validate the use of new

business processes based on enhancement pack

54

Quarterly/Bi-Annual Activities (cont.)

• As Basis, help determine application scenario dependencies

Source: SAP

55

Quarterly/Bi-Annual Activities (cont.)

• The goal is to see the forest from the trees. Where are the trends in IT performance and the business agenda that we would use to set direction? User population growth needs to be tracked Are users being spread out across applications servers?

Database growth How quickly is data being added to the SAP databases?

System activity Are new business requirements and initiatives adding

background jobs among other traffic in and out of the SAP system?

56

Quarterly/Bi-Annual Activities (cont.)

• So what are my tools?• User and System load management SM50 in each application instance can show you historical load

among process types

57

Quarterly/Bi-Annual Activities (cont.)

• So what are my tools?• Basis table maintenance SAP Note 706478 – Preventing Basis tables from increasing

considerably Over 60 tables that can be addressed for excessive growth

Table cleanup ultimately will yield some performance gains as table sizes decrease

Standards will need to be created for data retention of tables that require archiving for cleanup

58

Quarterly/Bi-Annual Activities (cont.)

• So what are my tools?• Archiving – Information Lifecycle Management (ILM) What are the benefits? Optimize system performance Control database growth Generate ROI Prerequisite to deleting old data

What is achieved? Less data – faster queries Improve batch processing (shorter run times) Improve overall user experience

59

Quarterly/Bi-Annual Activities (cont.)

• Sizing SAP sizing should be an ongoing topic not only when reviewing

hardware refresh cycles SAP Quicksizer SAP standard tool to determine hardware resources

required to support the application with a given workload SAP Benchmarks – quicklink/benchmark Published performance for different vendor hardware

configurations against 2,000 business process orders Vendor tools Example: IBM Insight or HP TVMS

60

Specific Application Monitoring

• BW/BI Process Chain failures – RSMO, Solution Manager BW

Monitoring PSA-related table cleanup – RSA1, RSMO

• SCM – liveCache Health checks – /SAPAPO/OM13 liveCache availability – LC10

• Portals – SAP NetWeaver Memory performance Portal Service Availability – SAP Solution Manager

• Process Integration Component, Message Monitoring – SXMB_MONI, Solution

Manager PI Monitoring

61

Business Intelligence (BI/BOBJ)

• SBOP BI Platform Mandatory for all business scenarios Central Management Console (CMC) Central Configuration Manager (CCM) Repository Diagnostic Tool SAP BusinessObjects Software Inventory Tool Upgrade management tool

• BI Launch Pad Installed with the BI platform SAP BusinessObjects Analysis, edition for OLAP SAP BusinessObjects Web Intelligence SAP BusinessObjects Explorer BI workspaces

62

SAP Lifecycle Management

• SAP ERP (Enterprise Resource Planning) Includes SAP ERP Central Component (SAP ECC) Key versions and progression SAP R/3 3.0F SAP R/3 3.1I SAP R/3 4.0B SAP R/3 4.6C SAP R/3 4.7 mySAP ERP 2004 (with SAP ECC 5.0) SAP ERP 6.0 (with SAP ECC 6.0) Enhancement Packages

63

SAP Lifecycle Management (cont.)

64

SAP Lifecycle Management (cont.)

• Enhancement Packages (EHPs) taking the place of traditional upgrades

• Support Packages are NOT the same as Enhancement Packages EHPs provide optional new/improved functionality like: Simplified business processes and user interfaces Industry-specific enhancements Enterprise Service Bundles – enabling SOA

Support Packs usually considered part of the general maintenance strategy and include: Corrections to existing ABAP and Java components SAP Notes too complicated for SNOTE

65

SAP Lifecycle Management (cont.)

• Enhancement Packages are cumulative – currently at EHP 7 for ERP

• Enhancement Packages are easy to implement from a functional perspective Company chooses which functionality to “turn on” in the EHP Less testing required

• BUT from the technical side EHPs require much the same investment as a traditional upgrade

66

Solution Manager 7.1

• A full suite of Basis tools for Technical Operations Solution Manager 7 is out of mainstream support Solution Manager 7.1 SP10 is latest available

Required system for approving support packs and retrieving necessary upgrade and enhancement pack media

CCMS has been supplanted by Diagnostics Agents in support of Technical Monitoring (there are exceptions to this)

67

Solution Manager 7.1 (cont.)

• Technical Monitoring

• System Monitoring App

68

Solution Manager 7.1 (cont.)

• Beyond system status and metrics, many other tools available to provide insight to the environment Root Cause Analysis Data Volume Management BW, PI Monitoring More!

• When coming up with Solution Manager use cases, ask yourself where there are gaps in your environment for monitoring, reporting, and alerting

• Many other tools available in Solution Manager outside of Technical Operations that meet needs between the IT and the business

69

Sizing Solution Manager 7.1

• SAP has provided a guided spreadsheet to help understand the resources required for Solution Manager based on technical scenarios and connected systems

• Covers current requirements and three year storage projections

70

Kernel Maintenance

• In the past, your kernel version was dictated by the SAP NetWeaver version Example:

Source: http://service.sap.com/pam * Downward Compatible Kernels As of SAP NetWeaver 7.0 forward, you can use a unified 7.20/

7.21 kernel version Follow the instructions in SAP Note 1636252 closely for your

specific landscape requirements

ECCRelease

ECC 6 ECC 6 EHP4

ECC 6 EHP6

Kernel 7.0 7.01 7.20

* Requires login credentials to the SAP Service Marketplace

71

Kernel Patching

• Rolling Kernel Switch (RKS) Depending on your system architecture, you can now perform

kernel patches “online” through a process in which each instance is patched individually

Requirements Kernel version 7.10 onward ASCS instance configured (separate central services) Separate instance file systems (/sap/<SID>/<instance>/exe)

*SAP Note 953653 needs to be reviewed for incompatible kernels

72

Kernel Patching – Gotchas!

• Don’t forget about your custom kernel files! Often, unique files are maintained in the kernel directory that

will need to be retained and/or modified as part of the patch process Saprouttab Third-party executables Backint

• Great opportunity to patch your saphostagents Apply the latest available patch independently to each system

or a tier at a time (Dev’s, QA’s … Prod) by using a central patching location

73

What We’ll Cover

• Intro the standard architecture for small, medium, and large SAP landscapes

• Overview of server equipment/infrastructure needed • Monitoring Fundamentals• System Performance Metrics and Customized Operations

Reporting• Tip to current system performance and maintenance best

practices for life of SAP application• SAP Fundamentals: pinpoint performance measurements from

hardware, database, and application layers• Database Optimization – archiving, DB compression• Monitoring and Business Expectations (IT role in Basis)• Wrap-up

74

Causes of Poor SAP Application Performance

• Network performance from end-user PC to SAP servers and back Network capacity or “bandwidth” needs to be adequate SAP transaction ST03 (transactional performance) shows

average “end-to-end” performance Average SAP user response time of less than 1500ms is

considered acceptable

• Lack of physical memory in server SAP Transaction ST06 (OS monitor) provides information If there is not enough physical memory, the “swapping” field

is red

75

Causes of Poor SAP Application Performance (cont.)

• Not enough SAP Work Processes SAP transaction monitor showing excessive “wait times” for

user sessions indicates not enough work processes• Underlying SAP database needs optimizing SAP transaction ST04 (database statistics) monitors database

performance• 32-bit vs. 64-bit operating system and database Refers to the size of data packets server can process Newer versions of SAP, database, and operating systems can

now process in 64-bit packets A 64-bit upgrade may well be part of your next SAP upgrade

project

76

Causes of Poor SAP Application Performance (cont.)

• Disk Input/Output (I/O) too slow Too few hard drives in storage system More disks enable more concurrent I/O = faster performance

Poorly configured mapping of database to hard drives Bottlenecks occur when too many popular tables reside on

the same drive SAP Transaction ST06 (OS Monitor) helps show if disk I/O is

nicely spread out Without expertise SAN configuration tools can propagate

these issues

77

Causes of Poor SAP Application Performance (cont.)

• SAP processes maintain data in server memory locations called “buffers” Data retrieved from memory buffers is much faster than

from disk SAP transaction ST02 (memory buffers) monitors to

optimal use of these memory buffers• Some SAP programs run slow Latest support packs often have code improvements

• Custom “Z” ABAP programs often poor performers SAP transaction ST03 (transactional performance) indicates

frequency programs are used and average processing time

78

BI Platform

• Central Management Console (CMC) Most day to day Administration will be done from CMC Web-based – http://server.domain:8080/BOE/CMC User/Group management Security APS configuration – A topic all on it’s own Licensing

• Central Configuration Manager Start/Stop SIA/Tomcat Add nodes to cluster

79

Authentication

• There are 4 different ways to authenticate Enterprise – Just a local account on an SAP BusinessObjects

system LDAP SAP – Authentication against an already existing SAP system Windows AD – Authentication based on Active Directory

80

Troubleshooting

• Monitoring section of CMC provides tons of useful information Can make custom “Watches” to track whatever you want Default watches will also provide some useful information

• Logs Located at <Install_Drive_Letter>:\Program Files (x86)\SAP

BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\logging

Check here when having issues• Task Manager on OS Easy way to see which APS PIDs are using most CPU/memory Can tell which APS is getting hit when a process runs

81

What We’ll Cover

• Intro the standard architecture for small, medium, and large SAP landscapes

• Overview of server equipment/infrastructure needed • Monitoring Fundamentals• System Performance Metrics and Customized Operations

Reporting• Tip to current system performance and maintenance best

practices for life of SAP application• SAP Fundamentals: pinpoint performance measurements from

hardware, database, and application layers• Database Optimization – archiving, DB compression• Monitoring and Business Expectations (IT role in Basis)• Wrap-up

82

Emerging Trends in SAP Infrastructure

• More organizations are outsourcing to data center providers• Overall, performance is increasing and prices are dropping• Inherent high availability (redundancy) of components• Virtual Private Networks (VPNs) replacing dedicated Wide Area

Networks (WANs)• Server virtualization 1 physical server acts like multiple servers Increased hardware utilization Decreased energy costs

Increases flexibility in server management Allocation and Provisioning Clustering

Improved Replication and backup features

83

Emerging Trends in SAP Infrastructure (cont.)

• Cloud computing Software as a Service (SAAS) – Applications on the Net that are

generally sold per user by month SAP Business by Design True “cloud-based” application Contains ERP, CRM, Analytics, and other functionality

“Apps” on Demand (i.e., CRM on Demand) Same applications as Business Suite, but hosted and

provided at a per user per, month pricing model Infrastructure as a Service (IaaS) – Outsourced infrastructure in

terms of servers, storage, and networking

84

Emerging Trends in SAP Infrastructure (cont.)

Cloud

Firewall

FirewallHosted ECC

SAP CRM on Demand

Fax

85

Emerging Trends in SAP Infrastructure (cont.)

• Cloud Computing What it is … Opportunity to leverage best TCO solutions for your

organization Business opportunities: Prototype new application with little or no up-front

investment Dynamically grow resources as needed – On-demand Licensing by the drink

The cloud has bridged the gap to allow access to applications anywhere

Another tool in the IT belt to be used where appropriate

86

Emerging Trends in SAP Infrastructure (cont.)

• Cloud Computing (cont.) What it is not … An end to current mainstream SAP architecture Complete replacement of your current landscape It is not a perfect fit for all situations or all customers A computing environment without issues Multi-tenancy concerns – performance, availability Security – access, compliance, data Less control over environment Time to enhancement modifications and patches

87

What We’ll Cover

• Intro the standard architecture for small, medium, and large SAP landscapes

• Overview of server equipment/infrastructure needed • Monitoring Fundamentals• System Performance Metrics and Customized Operations

Reporting• Tip to current system performance and maintenance best

practices for life of SAP application• SAP Fundamentals: pinpoint performance measurements from

hardware, database, and application layers• Database Optimization – archiving, DB compression• Monitoring and Business Expectations (IT role in Basis)• Wrap-up

88

Definitions

• High Availability (HA) Measures to ensure application availability

“in place” Reducing single points of failure in

technical architecture Utilizing redundant components – if one

goes down the other keeps working Having sound operations, competent

administrators• Disaster Recovery (DR) Measures to ensure application availability

after a catastrophic event Think loss of your data center

89

High Availability (HA) for SAP

• Hardware venders provide proprietary “fail-over” solutions Microsoft – MS Cluster HPUX – Service Guard IBM AIX – HACMP IBM AS/400 – various; e.g., MIMIX

• These solutions connect your SAP PRD system with another server “Heartbeat” monitor back and forth Scripts executed upon detection of a failure to move SAP to the

other server End users interrupted to last SAP transaction, simply log

back in

90

High Availability – Active-Passive

91

High Availability – Active-Active

92

High Availability

• SAP SPOF Enqueue, Message Server Services

• Database failover Failover based on host failure triggers Automated cutover procedure

• Host failover Virtual Machine cutover based on custom failure scenarios

• Storage Failover SAN replication as an example

• (Not factoring in total Datacenter relevant pieces – Power, Cooling, etc.)

93

High Availability (cont.)

• SPOF (Single Points of Failure) Application, Database, Host failover Solutions are dependent on OS platform and Database IT needs to understand business requirements for SAP

availability This determines the layers and overall complexity of HA

systems

94

Disaster Recovery (DR)

• Resumption of SAP availability somewhere else• IT budget line item that gets deleted every year • Primary business considerations Recovery Point Objective = RPO How much data is the business willing to lose?

Recovery Time Objective = RTO How quickly do you need to be back in operation?

Cost How much is the business willing to spend to minimize RPO

and RTO?

95

Disaster Recovery Options

• Classic off-site tape recovery Lowest cost solution RPO and RTO measured in days

• Classic off-site tape with active log shipping RPO reduced to minutes/hours via copying database logs over

the network RTO still measured in days

• “Hot” standby server Most expensive High network bandwidth required to replicate database RPO and RTO measured in minutes

96

Disaster Recovery

• The topic of DR is much bigger than copying SAP ECC to another Datacenter Start with RPO and RTO objectives RPO (Recovery Point Objective) How much data can be lost? 5 minutes … 5 hours?

RTO (Recovery Time Objective) How quickly do we need to be back up and running?

Determine what functionality the Business deems necessary in the event of a true DR Example, running payroll is a requirement Third-party solutions need to be included in the DR plan

97

Disaster Recovery – Technical Considerations

• Tiered DR Plan Providing DR for every productive system may be too

expensive Hot DR for critical SAP production components (Tier 1) Cold DR for ancillary applications that would need the

application reinstalled (Tier 2, 3)• Bandwidth Can your communication channel support the change

replication rates to your DR environment? Hardware and software solutions available to help compress

network traffic Plan for capacity increases based on Business initiatives for

new applications or additional system load

98

What We’ll Cover

• Intro the standard architecture for small, medium, and large SAP landscapes

• Overview of server equipment/infrastructure needed • Monitoring Fundamentals• System Performance Metrics and Customized Operations

Reporting• Tip to current system performance and maintenance best

practices for life of SAP application• SAP Fundamentals: pinpoint performance measurements from

hardware, database, and application layers• Database Optimization – archiving, DB compression• Monitoring and Business Expectations (IT role in Basis)• Wrap-up

99

SAP Technical Staffing

• Help Desk/Data Center operations Receive and escalate end-user problems

• Network administration Masters of the wiring closet

• Desktop administration (PC support) Distribute and maintain SAP GUI to end-user PCs

• Server infrastructure administration UNIX or Windows administrators SAN and backup administration

• Database administration (DBA) Manage SAP and other databases in the enterprise

• SAP Security administration Often a part-time role

100

SAP Basis Administration

• Basis/SAP NetWeaver administrators manage the technical application of SAP Basis Administrators work with SAP project teams to:

Translate business requirements into technical requirements Engineer change management system Design SAP server landscape (size and specifications)

Provide project technical support Perform day-to-day monitoring and maintenance of SAP systems

Monitor all SAP NetWeaver components and performance Look for errors in database and OS logs Oversee batch schedule Apply SAP Notes and Support Packs Oversee availability, capacity, and performance

Level 2 and 3 problem escalation

101

Strategies for SAP Technical Staffing

• Consider outsourcing of entire SAP environment – “managed hosting”

• Consider outsourcing or staff augmentation of SAP NetWeaver admin Basis administration is a highly specialized role Out-tasking is an alternative to hiring, training, and retaining Access to a much larger support team – deeper expertise

• Rethink internal technical staffing Reorganize to have a dedicated SAP technical team Don’t try to scrimp or “get by” with inadequate staffing Consider the cost of a day of down time

Is IT truly a core competency of your enterprise?

102

What We’ll Cover

• Intro the standard architecture for small, medium, and large SAP landscapes

• Overview of server equipment/infrastructure needed • Monitoring Fundamentals• System Performance Metrics and Customized Operations

Reporting• Tip to current system performance and maintenance best

practices for life of SAP application• SAP Fundamentals: pinpoint performance measurements from

hardware, database, and application layers• Database Optimization – archiving, DB compression• Monitoring and Business Expectations (IT role in Basis)• Wrap-up

103

Where to Find More Information

• http://scn.sap.com/docs/DOC-25454#section55 High Availability – Frequently Asked Questions on SCN

• www.saphana.com/community/blogs/blog/2013/04/30/what-is-the-definition-of-a-cloud Floyd Strimling, “What Is the Definition of a Cloud?” (SAP

HANA Blog, April 2013). • http://wiki.scn.sap.com/wiki/display/TechOps/Home SAP source for Solution Manager technical offerings (Wikis and

How-To documents)• http://scn.sap.com/community/netweaver SAP NetWeaver Technology Platform on SCN

104

7 Key Points to Take Home

• Analyzing performance goals is a moving target. Factor in all pertinent performance metrics across the OS, DB and application during assessments.

• SAP Solution Manager 7.1 should be a key component of your SAP Operational strategy

• When performing system analyses, review the entire technology stack from the OS and underlying hardware to database and finally SAP

• Consider the many permutations and configuration options for your SAP architecture to cover availability, disaster recovery, and load balancing

105

7 Key Points to Take Home (cont.)

• Always consider end-to-end business process effects when taking on upgrades or support packs Only changing a portion of the systems involved in the process

will create major headaches• When implementing a monitoring and alerting framework, look to

create alerts before they become critical events, and assign notifications to the proper individuals

• Maintaining a healthy SAP environment requires a structured maintenance approach through a weekly, monthly, and bi-annual analysis and corrective activities

106

Your Turn!

How to contact me:Matt Lonstine

mlonstine@sym-corp.com

Please remember to complete your session evaluation

107

Disclaimer

SAP, R/3, mySAP, mySAP.com, SAP NetWeaver®, Duet\®, PartnerEdge, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP.

Wellesley Information Services, 20 Carematrix Drive, Dedham, MA 02026 Copyright © 2014 Wellesley Information Services. All rights reserved.