SAP Infrastructure

SAP Infrastructure
SAP system landscape
Servers and software
Physical facilities
Data center
Network infrastructure
Operating systems and DBMS
SAP Technical Support Organization
Course Organization
Infrastructure
Organization
Infrastructure
SAP
Technology
NetWeaver
SAP System
Landscape
Data Center TSO
Basic SAP
Technology
The SAP Solution Stack
Network Infrastructure
Rack and other Physical Mounting Infrastructure
Cooling and Conditioning Infrastructure
Power Infrastructure
SAPGUI/Client Components/Browser Components
Various SAP Integration/Touch Points
WebAS and ITS/IIS Components
SAP Application Server Layer
SAP Database Server Layer
SAP Central Instance Layer
Database-specific Updates/Service Packs/Patches
Database Layer
OS High Availability Layer (clustering, etc.)
OS & HW-Specific Driver Overlays
OS Service Packs/Patches
Operating System Layer
Disk Subsystem HBA Layer
Disk Subsystem/SAN Interconnects, Switches, Cables
Disk Subsystem/SAN Firmware Layer
Disk Subsystem/SAN Hardware Layer
Server Firmware
Server/CPU/RAM/Local Disk Hardware
The SAP Solution Stack
Hardware Platforms
Fujitsu, HP, IBM, Sun, Dell, etc.
Operating Systems
AIX, HP-UX, Windows, Solaris,
Tru64, OS/400, zOS
Databases Supported
Oracle, SQL Server, DB2, MySQL,
MaxDB
The SAP Solution Stack Options
Source: Wikipedia.com
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
System Landscape Directory
Centralized SLD
SLDs for Dev/QA and Production
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)
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
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
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
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
SAP One Server
For small organizations SAP provides
Multiple Components in One Box (MCOD)
and the SAP One Server solution
Course Organization
Infrastructure
Organization
Infrastructure
SAP
Technology
NetWeaver
SAP System
Landscape
Data Center TSO
Basic SAP
Technology
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
Data Center Physical Facilities
Adequate, robust, redundant power facilities
Environmental controls
Physical security
Well designed rack layout
Robust network infrastructure
Cable management systems
Disaster Recovery and High Availability
Causes of Downtime
Application failure
Operator error
Operating system failure
Hardware failure
Power outages
Natural disasters
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
HA Objectives
HA is measured in terms of the percentage of
time that a system is available
95% - >18 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
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
Disaster Recovery Threshold
Org A Budget
Constraints
Costs
Downtime in Days
Org B Downtime
Costs/Losses
Org B Budget
Constraints
Org A Downtime
Costs/Losses
X
X
High Availability
Ensuring HA boils down to eliminating Single
Points of Failure (SPOF) in the solution stack
This involves providing redundancy of
vulnerable components

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
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
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

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)
HA Switchover Cluster
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

Database Systems
Most DBMS have features that provide for
duplicating the database independent of
other duplication technologies (i.e. RAID)
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