The Basics of Basis Administration: Architecture ... · PDF fileThe Basics of Basis...
-
Upload
truongkhanh -
Category
Documents
-
view
240 -
download
6
Transcript of The Basics of Basis Administration: Architecture ... · PDF fileThe Basics of Basis...
© 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
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.