sap infrastructure

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 LandscapeData Center TSO Basic SAP

Technology

The SAP Solution Stack

Network InfrastructureRack and other Physical Mounting Infrastructure

Cooling and Conditioning InfrastructurePower Infrastructure

SAPGUI/Client Components/Browser ComponentsVarious SAP Integration/Touch Points

WebAS and ITS/IIS ComponentsSAP Application Server LayerSAP Database Server LayerSAP Central Instance Layer

Database-specific Updates/Service Packs/PatchesDatabase Layer

OS High Availability Layer (clustering, etc.)OS & HW-Specific Driver Overlays

OS Service Packs/PatchesOperating System Layer

Disk Subsystem HBA LayerDisk Subsystem/SAN Interconnects, Switches, Cables

Disk Subsystem/SAN Firmware LayerDisk Subsystem/SAN Hardware Layer

Server FirmwareServer/CPU/RAM/Local Disk Hardware

The SAP Solution Stack

Hardware PlatformsFujitsu, HP, IBM, Sun, Dell, etc.

Operating SystemsAIX, HP-UX, Windows, Solaris, Tru64, OS/400, zOS

Databases SupportedOracle, 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


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)


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


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


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


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 LandscapeData 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? It’s 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 DowntimeCosts/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