SAP Infrastructure

1
SAP Infrastructure
2
SAP Infrastructure

• SAP system landscape
• Servers and software
• Physical facilities
• Data center
• Network infrastructure
• Operating systems and DBMS
• SAP Technical Support Organization

3
Course Organization
4
The SAP Solution Stack
Databases Supported Oracle, SQL Server, DB2,
MySQL, MaxDB
Operating Systems AIX, HP-UX, Windows, Solaris,
Tru64, OS/400, zOS
Hardware Platforms Fujitsu, HP, IBM, Sun, Dell,
etc.
5
The SAP Solution Stack Options
Source Wikipedia.com
6
SAP System Landscape

• The system landscape consists of the servers in
  the SAP implementation
• A central repository of system information used
  by all SAP applications to find connection
  information
• The system landscape includes production servers
  but also many servers that are required to ensure
  that the production servers are isolated from the
  results of training, development, testing and
  other disasters

7
System Landscape Directory
8
Centralized SLD
9
SLDs for Dev/QA and Production
10
SAP System Landscape

• Technical Sandbox
• Used by technical support team to practice and to
  perfect configuration and tuning the SAP solution
  stack
• Used to test installations, upgrades, backup and
  restore processes, hands-on training, etc.
• Should be identical to production system from a
  functional standpoint
• Business Sandbox
• Used by development team (ABAP, HTML, Java, etc)

11
SAP System Landscape

• Development System
• Continuing SAP configuration and/or
  customization, maintenance, and steady-state
  updates/bug fixes
• Originator of business-process-related
  configuration and customization changes that will
  be promoted to the production system
• Test/QA System
• Used for integration and testing of business
  process configuration changes
• Changes created in the development system are
  promoted here and thoroughly tested
• Technical changes are made here if no technical
  sandbox exists

12
SAP System Landscape

• Training system
• Used for training end users
• Smaller organizations often use the Test/QA
  server
• Staging system
• Last stop for changes in largest or
  mission-critical implementations
• Functionally and physically identical to
  production system
• Subjected to stress/load tests and other
  performance tests

13
SAP System Landscape

• Production system
• Supports business groups
• Disaster recovery system
• Used when the costs of downtime exceeds cost of
  maintaining the system
• Identical to the production system but located in
  a different physical location
• Data and processes are replicated from production

14
SAP System Landscape

• Not all systems are implemented in all companies
• A three-system landscape would include
  development, test/QA, and production systems
• A four-system landscape would include the three
  above plus a DR/Staging system or technical
  sandbox

15
SAP One Server

• For small organizations SAP provides Multiple
  Components in One Box (MCOD) and the SAP One
  Server solution

16
Course Organization
17
Standardization

• Standards are the most important tool for
  avoiding problems
• Every aspect of the data center operation should
  be subject to rigorous standards, for example
• Server names
• IP addressing
• Disk naming
• Color coding cables
• Standard hardware and software
• Standard processes

18
Data Center Physical Facilities

• Adequate, robust, redundant power facilities
• Environmental controls
• Physical security
• Well designed rack layout
• Robust network infrastructure
• Cable management systems

19
Disaster Recovery and High Availability
20
Causes of Downtime

• Application failure
• Operator error
• Operating system failure
• Hardware failure
• Power outages
• Natural disasters

21
High Availability vs. Disaster Recover

• High availability is tactical
• Disaster recovery is strategic
• Both require analysis of total cost of ownership
  or return on investment to determine the amount
  of unplanned downtime that is allowable
• Both add complexity and constrain system
  landscape options
• Both implemented at all layers of the solution
  stack

22
HA Objectives

• HA is measured in terms of the percentage of time
  that a system is available
• 95 - gt18 days
• 99 - 4 days
• 99.9 - 9 hours
• 99.999 - 5.5 minutes
• 95 is easy but will cost people their jobs,
  99.999 (five nines) may be very expensive

23
Availability Planning

• HA and DR objectives must be tied to business
  requirements
• Which business processes are critical?
• What is the cost of downtime in critical
  processes?
• TCO and ROI drive HA and DR planning
• How much does each option cost and what are the
  potential savings?
• Its the responsibility of the solution architect
  to oversee HA and DR since it affects every level
  of the solution stack

24
Disaster Recovery Threshold
Costs
Org A Downtime Costs/Losses
Org B Downtime Costs/Losses
Org A Budget Constraints
X
Org B Budget Constraints
X
Downtime in Days
25
High Availability

• Ensuring HA boils down to eliminating Single
  Points of Failure (SPOF) in the solution stack
• This involves providing redundancy of vulnerable
  components

26
Data Center

• UPS and redundant power systems
• Redundant environmental controls
• Redundant network infrastructures
• Disaster Recovery often involves redundant data
  centers that are mirror images
• Often only core business processes are duplicated
• Duplicate data centers are cost justified by
  using them for development as well as pre-upgrade
  testing/staging

27
Servers

• Servers should have inside the box redundancy
  of components that are hot swappable when
  possible
• Power supplies
• RAID Drives
• Disk controllers
• CPUs
• Error code correcting (ECC) RAM

28
Servers

• Outside the box HA features include server
  clustering
• Clusters are collections of servers and storage
  systems that are combined into a single virtual
  system via clustering software
• From the outside, the cluster appears to be a
  single server but internally work loads are
  allocated across all servers

29
SAP Components

• Most critical component (besides the database) is
  the Central Instance (CI)
• CI resides on one of the basis servers and
  coordinates communication among all SAP
  components
• The CI should reside on a highly available server
• SAP is cluster aware meaning that each instance
  of the CI in a server cluster maintains state
  information on all processes
• If fail-over occurs the new CI can pick up where
  the old one left off (called active/active
  clustering)

30
HA Switchover Cluster
31
Disk Subsystems

• Redundant Arrays of Inexpensive/Independent Disks
  (RAID)
• RAID systems duplicate data across multiple disks
• HA disk controllers
• Battery backed on-board caches
• Storage system clusters with remote data centers
• Storage area networks (SAN)
• Data networks dedicated to accessing permanent
  storage

32
Database Systems

• Most DBMS have features that provide for
  duplicating the database independent of other
  duplication technologies (i.e. RAID)

33
Disaster Recovery

• Administrative organization and processes for DR
  should be formalized and tested
• Recovery manager
• Communication liaison
• Technical recovery team
• Review/certification manager
• A DR crash kit should be prepared including all
  software (application, utilities, etc.),
  documentation, procedures for recovery
• Documentation becomes critical after a disaster
• Personnel should be thoroughly trained and have
  period refreshers on procedures