Upload
datacenters
View
312
Download
0
Embed Size (px)
Citation preview
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
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
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 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
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)
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