1 INTRODUCTION

1.1 Goal

The goal of this document is to provide technical solutions for the ERP (SAP ECC 6.0) implementa-
tions at Maihar Cement.

This document would give a brief introduction and suggestion to the build a solution which is robust,
scalable and optimized used of resources. The key focus would be to highlight the system sizing re-
quirement, System landscape design, and strategies to ensure business continuity.

1.2 Introduction – SAP ERP Central Component (ECC) 6.0

The SAP ERP application has an extensive range of functionality – including personalized in-
formation access and tailored reporting – to help you in all areas of your business. With full support to
integrate your core business processes – such as customer relationship management, supply chain
management, supplier relationship management, and product life-cycle management – SAP ERP
provides a foundation for growth, innovation, and end-to-end business process excellence.
SAP ERP is a world-class, fully integrated application that fulfills the core business needs of
midsize companies and large organizations across all industries and market sectors. It helps enter-
prises like yours perform financials, human capital management, procurement and logistics, product
development and manufacturing, and sales and service, supported by functionality for analytics, cor-
porate services, and end-user service delivery.
In addition to increasing efficiency within your organization, SAP ERP also helps you extend
end-to-end business processes to your customers, partners, and suppliers. SAP ERP can serve as a
business process platform that supports continued growth by providing a foundation for insight, opera-
tional excellence, and innovation. SAP ERP is powered by the SAP NetWeaver technology platform,
which enables you to build new business solutions rapidly while realizing more business value from
your existing IT investments. SAP NetWeaver is also the foundation for enterprise service oriented
architecture (enterprise SOA).

4
1.3 Introduction – Netweaver 2004s

The SAP Netweaver technology platform is a comprehensive integration and application plat-
form that helps reduce the total cost of ownership (TCO). It facilitates the integration and alignment of
people, information and business processes across organizational and technological boundaries.

SAP NetWeaver easily integrates information and applications from virtually any source. It inte-
roperates with and can be extended using the primary market technologies ̼ Microsoft .NET, Sun’s
J2EE, and IBM WebSphere. SAP NetWeaver is the technical foundation for SAP ECC 6.0 solutions
and ensures maximum reliability, security, and scalability, so mission-critical business processes run
smoothly. And by providing pre-configured business content, it helps reduce the need for custom in-
tegration and lowers TCO.

SAP Netweaver supports installation based on

Operating System: Windows, Linux, HP-UX, AIX, Sun-Solaris, OS/400, z/OS, Tru64

Database: SAP DB, ORACLE, DB/2, MS SQL Server

5
1.4 Introduction to SAP Web Application Server

Lets understand WAS in simple context. SAP Web Application Server (WAS) is integral part of
SAP Netweaver and ultimately the core engine which has the processing capabilities. There are two
types of WAS, ABAP WAS and J2EE WAS which are placed at application layer. SAP ECC 6.0 re-
quires both ABAP WAS and J2EE WAS in order to use full functionality and features. In SAP System
Landscape you can have as many as application server you require to support business operation
and only one database server.

6
SAP Web Application Server: Each WAS (Application Server) has 2 main components, Dispatcher
and Work process. The task of dispatcher is to receive the request from Presentation layer and man-
age the requests in queues. Each Work process establish connection with Database, process the
dynpro logic and also shares common buffer between the work processes.

Central Instance: Message server + Enqueue server.

Message Server: The significance of Message server as load balancer is more when there are then
one applications server per SAP instance. The task of message server is to check the availability of
the application server and collect the performance statistic data of each applications server.

Enqueue server: The task of Enqueue server is to manage the data locking at SAP level. Data locked
by one user session, can’t be altered by any other user session from any application server, thus en-
sured data consistency.

Processing Logic:

Login Process: First request would be to establish connection with SAP ECC System. End Users can
access the SAP ECC application through SAPGUI (Thick Client) or Browser (Thin Client).Connection
request first addressed by Message server. The task of Message server is to identify application serv-
er with best response time. Request then routed to allocated application server and End user estab-
lishes the session with application server after successful login. Once session established, subse-
quent request from user will addressed by the allocated server.

User context (personalized data, Authorization) loaded into shared buffer from database. User context
also stores the runtime application data of the users. When user sends request to SAP ECC system,
request queued into dispatcher and which intern assign to the request to available Work Process
(WP) / Server Process (SP). Work process loads user context into main memory (roll-in) from shared
buffer. After completion of request, WP sends data back to presentation layer and User context rolls-
out from main memory into shared buffer.

Though each WP has dedicated database connection still SAP ECC system can manage multiple
active sessions and its not limited to dedicated session as in legacy system.

7
2 ‘PROMOTE TO PRODUCTION’ LANDSCAPE.

The ideal software landscape to support the implementation is comprised of environments supporting
three distinct needs that provide a solid ‘promote to production’ change management and change
control process for all configuration and developments. These environments should provide:

An environment where customizing and development can be performed. The environment

should be representative of the productive environment and contain all product production
customizing, developments and a sampling of production data. In addition new projects’ de-
velopments, customizing and data will exist in the system and this environment will be used
for unit testing. This environment is used for as the initial environment for resolution of pro-
duction issues and routine maintenance support.

An isolated and stable environment for testing the customizing, developments, and mainten-
ance support changes. The environment is representative of the productive environment and
contains all product customizing, developments and in most cases production quality data. In
addition this environment will also have newly completed customizing/developments that are
in quality testing phase prior to productive release. The typical testing that occurs in this envi-
ronment is regression and integration testing. No development tasks are performed in this en-
vironment, just quality assurance tasks. This environment may also be used for replicating
and debugging productive issues.

An isolated and stable production environment. The environment is the system of record and
only contains productive customizing and developments. No development tasks are per-
formed in this environment, just productive tasks. This environment may additionally be used
for debugging productive issues.

This ‘promote to production’ scenario is recommended when implementing any system based on SAP
NetWeaver. This is typically called a “Three System Landscape” with 1 Production system (PRD), 1
Quality Assurance system (QAS), and 1 Development System (DEV).

Sandbox System (SBX)

Sandbox system is standalone system and not integrated into Project landscape. Sandbox system
has more importance and it used for destructive testing, learning, and testing. Project requirement
mapping and building of prototype of solution done in Sandbox. Since system is standalone it is com-
pletely free from risk.

Development System (DEV)

8
Since each business needs to adapt the SAP software for its own business needs, each SAP system
landscape requires SAP System where Customizing settings and possibly ABAP Workbench devel-
opments can be made. All system maintenance including break-fixes for productive processes is also
performed in the system. After all the changes have been unit tested, these changes can be trans-
ferred to the quality assurance system (QAS) for further system testing.

The customizing, development and production break-fix changes are promoted to the QAS system
using the change management system. This ensures consistency, management, tracking and audit
capabilities thus minimizing risk and human error by eliminating manual repetition of development and
customizing work in each system.

Quality Assurance System (QAS)

After unit testing the customizing, development and break-fix changes in the development system
(DEV), the changes are promoted to the quality assurance system (QAS). Here, the configuration,
development or changes undergo further tests and checks to ensure that they do not adversely affect
other modules.
When the configuration, development or changes have been thoroughly tested in this system and
signed off by the quality assurance team, it can be promoted to the production system (PRD).

Production System (PRD)

A company uses the production system (PRD) for its live, productive work. This system—containing
the company's live data—is where the real business processes are executed.
The other systems in the landscape provide a safe approach to guaranteeing that only correct and
tested (that is not defective) new developments and/or customizing configurations get deployed into
the productive system. Additionally they ensure that changes to productive developments and confi-
guration by either project enhancements or maintenance do not adversely affect the production envi-
ronment when deployed. Therefore the quality of the DEV and QAS system and the implemented
change management processes directly impacts the quality of the production system.

9
2.1 Role of Client in SAP ECC Landscape

A client is defined as a self-contained commercial, organizational, and technical unit within an SAP
Instance. This means that all business data within a client is protected from other clients. Each client
has its own customer data, business data, transaction data, which can be considered as the exclusive
property of this client.

SAP's client concept allows you to split an SAP System into multiple logical sub-systems - or clients.
You can isolate these sub-systems and operate them as separate business units. However, the SAP
System offers a system solution that is implemented for all clients in a central repository and cross-
client tables (central data source).

All data in a system with multiple clients is located in a common database. SAP ECC solution can op-
erate with multiple clients if each customer has exclusive access to his or her data in an installation
with a shared system platform, database, and central services.

Customizing and Development client (CUDV): Since each business needs to adapt the SAP soft-
ware for its own business needs, each SAP system landscape requires a client where Customizing
settings and possibly ABAP Workbench developments can be made.

TEST client (TEST): Developers can use this client to test their Customizing settings and Workbench
developments, before they release their change requests. In this client the developers can create test
application data for realistic tests. If they discover errors, they can remove them in the Customizing

10
client. A TEST client is always set up in the same SAP System as the Customizing client. This means
that any changes that are made to cross-client data in the Customizing client are also immediately
visible in the TEST client. Changes to client-specific data are copied from the Customizing client to
the TEST client using a special client copy function. The client copy function uses the unreleased
change requests from the Customizing client to do this. The TEST client is set so that one cannot
make changes to Customizing data and Repository objects. Required Master and Transaction data,
for Unit Testing, has to be created manually or with Migration script / program or Catt or eCatt.

Prototype (PROT): This client is used to test any client-specific Customizing settings if one is not
sure whether one wants to use them in this form. Any settings that one wants to keep are then en-
tered in the Customizing client. To prevent conflicts between the prototype client settings and real set-
tings in the Customizing client, one cannot make changes to cross-client Customizing data and Repo-
sitory objects in the prototype client. The Change and Transport System (CTS) does not record
changes made to client-specific Customizing data, and does not transport them from the prototype
client. One can be sure of this by making appropriate client settings. Required Master and Transaction
data has to be created manually or with Migration script / program.

Training client (TRNG): To prepare end users for new functions that are to be transported into the
production client, a separate training client can be set up. The users can use the new functions in this
client with specially created application data. This client is set so that no changes to Customizing data
and Repository objects can be made.

Quality Assurance Client (QTST): Before one can use the Customizing settings and Workbench
developments productively, one needs to test them extensively for errors. Any faulty settings can se-
riously disrupt productive operations, and at worst, lead to the loss of productive data. The integrated
nature of the various SAP applications means that there are many dependencies between the differ-
ent Customizing settings. The correctness of the settings can only be guaranteed with extensive test-
ing. The client where these tests are made is the Quality Assurance Client, QTST for short.

Production Client (PROD): A separate client is required for productive use of the SAP System. So
that this client can be used without disruption, it is essential that no Customizing settings or Work-
bench developments are made here and also that no tests are carried out.

11
 2.2 Proposed Client settings for each system

Behavior of each depends upon the setting performed in SCC4 and SE06 transaction. For more de-
tails about the settings for each client are mentioned in attached file. As SE06 settings are client inde-
pendent, Changes in SE06 setting will reflect in all the clients existing in the same system. For ABAP
Development we are proposing to have separate naming convention “/MAIHAR”.

System Client Client Role Changes and Cross client object Protection: Client CATT / SE06 Settings
Transports for Changes copier and Compari-
eCATT
Client specific sion tool
Objects
Sandbox SAND Demo Automatic Changes to Repository Protection Level 1: Allowed Global Set-
(IDES) recording of and Cross - Client is No overwriting tings: Modifia-
Changes allowed ble
Software
Component:
Modifiable

Name Space:
Modifiable
Development CUDV Customizing Automatic Changes to Repository Protection Level 1: Not Allowed Global Set-
and Devel- recording of and Cross - Client is No overwriting tings: Modifia-
opment Changes allowed ble

Software
Component:
Modifiable
Name Space:
No Changes to Reposito- Modifiable
No Changes Protection Level 1:
Development TEST Test ry and Cross - Client is Allowed
allowed No overwriting
allowed
NA

Changes with-
out Automatic No Changes to Reposito-
Protection Level 1:
Development PROT Demo recording, No ry and Cross - Client is Allowed NA
No overwriting
transports allowed
allowed

No Changes to Reposito- Global Set-

Quality As- Quality as- No Changes Protection Level 1:
QTST ry and Cross - Client is Allowed tings: Not
surance surance Test allowed No overwriting
allowed Modifiable
Software
Component:
Not Modifiable
Name Space:
No Changes to Reposito- Not Modifiable
Quality As- Training / No Changes Protection Level 1:
TRNG ry and Cross - Client is Allowed
surance Education allowed No overwriting
allowed
NA

No Changes to Reposito- Protection Level 2: Global Set-

No Changes
Production PROD Production ry and Cross - Client is No overwriting and no Not Allowed tings: Not
allowed
allowed external availability Modifiable

2.3 User and Authorization Strategies for each Client

12
 Quality
Customization
Sandbox Prototype Assurance Training Production
User Types and Develop- Test (TEST)
(SAND) (PROT) Test (TRNG) (PROD)
ment (CUDV)
(QTST)
Business Process Owner P O O O P P P
Functional Consultant P P P P P O O
Technical Developer P O P P P O O
Basis Consultant P P P P P P P
System End User O O O O O P P

13
3 SAP SERVER SIZING

3.1 Understanding Sizing parameter

v SAPS

v Understand CPU processing capacity should be hardware-independent unit as SAP Sup-

port many platforms. SAPS describe the performance of a system configuration in the SAP
environment and derived from the Sales and Distribution (SD) Benchmark.
v 100 SAPS means processing 2000 fully business process line items per hour.
v Cost Factor (Importance in System Sizing): Number of servers and/or CPUs require.

v Disk

v Business transaction and master data are placed in central database. Required data to
complete business transaction are fetched from database and stored in buffer (RAM) till
user activity is complete. When data can't be avoided or needs to be moved it will stored in
Database.
v Expressed in GB(GigaByes) / MB(MegaBytes)
v Cost Factor (Importance in System Sizing):
Ø Backup/recovery depends on size of database
Ø Disk I/O

v Memory (RAM)

v Each program execution requires real-time memory to process. SAP real-time memory
structure has many components such as User contexts (Roll area, Heap Area, Extended
memory), shared buffer memory etc.
v Expressed in GB(GigaByes) / MB(MegaBytes)
v Cost Factor (Importance in Sizing): physical memory slots.

3.2 General assumption for Sizing

v Sizing of SAP ECC 6.0, SAP BI 7.0 and SAP Solution Manager 7.0 is considered in current
phase of the project.
v Sizing estimation is totally based on input provided by IT team from Maihar Cement ( For
ECC attached in Annexure I) and incase of any change/addition in Sizing input, should con-
sult with Infosys / Hardware vendor or section 3.7 should be considered.
v Sizing and solution architecture suggested is hardware independent. It’s very important to
have final solution from Hardware vendor based on Hardware technology.
v Sizing estimations are calculated to support the SAP operation after 3 years as well.
v Utilization of production resources is at 60% including buffer of 30%.
v Sizing estimation considered 20 ABAP object development (Objects in customer Name
space).

14
3.3 Sizing for ECC Systems

v Total Sizing for Production system 13000 SAPS, 40GB Memory and 760GB Disk space. In-
dicative split-up is shown below.

Sandbox Server Development Server Quality Server

CPU: 3250 SAPS CPU: 3250 SAPS 6500 SAPS,

RAM: 6 GB RAM: 6 GB 12 GB
Disk Space: 200GB Disk space: 200GB Disk Space: 400GB

Production DB Server Production

With SCS & ASCS Apps Server1
Disk Space: 760GB Disk space: 50GB

Production System

Production Production
Apps Server2 Apps Server3
Disk space: 50GB Disk Space: 50GB

v Disk Space: We have estimated that Database growth will happen at 12GB / Month. Thus
144GB / Year and 432GB at end of 3 year. Plus we need to consider additional disk space for
database software, Default storage requirement for ECC software and storing the log files ap-
prox. 100GB. i.e 432 + 100 = 532 GB. Maihar Cement wants maximum disk utilization should
be 70% so total Disk storage requirement is around 760GB.

v Sandbox (IDES) and Development system is considered to have a 25% size of Production
environment.

v Quality system is considered to have 50% of production system.

v Central services of ABAP (ASCS) and J2EE (SCS) are installed along with Database.

15
3.4 Sizing for BI Systems

v Total Sizing for Production system 10000 SAPS, 36GB Memory and 800GB Disk space
(Indicative). Indicative split-up is shown below.

Sandbox Server Development Server Quality Server

CPU: 4000 SAPS CPU: 4000 SAPS 8000 SAPS,

RAM: 8 GB RAM: 8 GB 12 GB
Disk Space: 200GB Disk space: 200GB Disk Space: 400GB

Production DB Server Production

With SCS & ASCS Apps Server1
Disk Space: 800GB Disk space: 50GB

Production System

Production
Apps Server2
Disk space: 50GB

v Sandbox (IDES) and Development system is designed to have load of 30 Concurrent SAP
user / Functional Consultant / Developer. Though compare to SAP ECC 6.0 System, SAP BI
7.0 system requires more system resources because ideally SAP BI 7.0 actively use applica-
tion based on ABAP and J2EE instance, higher resource requirement for data extraction, data
loading and reporting. Also SAP BI 7.0, by default comes with SAP EP 7.0 component.

v Disk Space: We have estimated that Database growth will happen at 12GB / Month. Thus
144GB / Year and 432GB at end of 3 year. Plus we need to consider additional disk space for
database software, Default storage requirement for ECC software and storing the log files ap-
prox. 100GB. i.e 432 + 100 = 532 GB. Maihar Cement wants maximum disk utilization should
be 70% so total Disk storage requirement is around 800GB.

v Central services of ABAP (ASCS) and J2EE (SCS) are installed along with Database.

16
3.5 Sizing for Solution Manager

Solution Manager Serv-

er

CPU: 4000 SAPS

RAM: 8 GB
Disk space: 200GB

Explanations:

v Total Sizing of SAP Solution Manager system is 4000 SAPS, 8GB RAM and 200GB Disk
space.

v SAP Solution Manager 7.0 system is designed to have user load of 30 Concurrent users.

v Following features of Solution manager will be used to support the project.

o Project Management ( Document storage )

o Central System monitoring
o Primary SLD ( System Landscape Directory)
o Maintenance optimizer

17
3.6 System Architecture for Maihar Cement
Non-Production Site
Production Site

Solution Manager
ECC Production DB
4000 SAPS, Server with SCS and
8 GB ASCS
Disk Space: 200GB Disk space: 760GB

ECC Sandbox Server

4000 SAPS,
8 GB
Disk Space: 200GB

ECC Development Production Production Production

Server Apps Server1 Apps Server2 Apps Server3
CPU: 4000 SAPS Disk Space: Disk space: Disk Space:
RAM: 8 GB 50GB 50GB 50GB
Disk space: 200GB

ECC Quality Server

CPU: 8000 SAPS

RAM: 12 GB
BI Production DB
Disk Space: 400GB
Server
BI Sandbox Server With SCS & ASCS
Disk Space: 800GB
4000 SAPS,
8 GB
Disk Space: 200GB

BI Development Server

CPU: 4000 SAPS

RAM: 8 GB Production Production
Disk Space: 200GB Apps Server1 Apps Server2
Disk space: 50GB
BI Quality Server Disk space: 50GB

CPU: 8000 SAPS

RAM: 12 GB
Disk space: 400GB

* Network connection between Database and application server should be on high speed network
(Minimum 100 mbps).

18
3.7 Requirement of Re-sizing - Post-Golive

Prerequisites:

ü The System is live

ü The hardware and software scalable
ü Different goals
Ø Only add volume, no modified processes
Ø Add different functions
Ø Only upgrade SAP Software

Monitor & Analyze:

§ Disk Analysis: DB02, DB monitor of vendor

§ CPU Analysis: ST06, ST03N, STAD, ST03G
§ User Analysis: ST07, STAD, ST03G
§ Memory Analysis: SM04, STAD, GCLOG
§ Front-End Network Load: STAD, ST03N, ST03G, httplog

As a rule,20% of the processes cause 80% of the load. Analyze

ü Growth rate of 20 largest tables

ü Average and peak CPU load
ü Average and peak memory utilization

Procedure:

1. Monitor CPU utilization, table growth, and memory use.

2. Different procedures according to goals
a. Re-sizing: Add the load coming in through the additional users and projects causing
the same load structure.
b. Delta sizing: treat like a new sizing and add calculated load.
c. Upgrade sizing: determine additional requirements and add calculated load
3. Judge whether your current hardware is sufficient, or whether you may need to buy new
hardware.

19
4 HIGH AVAILABILITY SOLUTION

4.1 High Availability – Definitions

Availability is the capacity to function as expected. A service is considered available if it can complete
its assigned task at the appropriate time.

This is a yes-no concept: a service is available or it is not.

Ø Virtualization of services is a necessary requirement for an application to be highly available

as all SAP HA scenarios require at least one Switchover Solution.

Ø Switchover Solution - As the name switchover implies, services can be automatically switched
from a failed host to a standby host in the event of failure, allowing continuation of SAP sys-
tem operation. A switchover solution implies a third party delivered software and/or hardware
package that provides such implementation of SAP enabled (configured) application software
or other infrastructure elements such as RDBMS, server, storage, or network.

Ø Availability requiring additional measures. For a high availability system all single points of
failure have to be eliminated. High availability does not include disaster recovery.

4.2 Avoiding Single Points of Failure with the SAP NetWeaver AS

With SAP NetWeaver Technology, SAP provides a proven, scalable, fault-tolerant, multi-tier ar-
chitecture. The individual components can be protected either by horizontal scalability – that is, the
use of multiple components that tolerate the failure of individual components – or by cluster and
switchover solutions. All SAP hardware partners provide their own proven solutions, which enable
SAP applications using additional software and hardware to achieve high availability.

With the SAP NetWeaver Application Server (SAP NetWeaver AS), SAP enables web appli-
cations to be directly supported by the application server for the first time and combines ABAP and
J2EE in one infrastructure.

The Internet Communication Manager has also been implemented as another new process in
the application server framework. It enables communication between the SAP NetWeaver AS and
external partners using Internet standard protocols such as HTTP, HTTPS, SMTP, SOAP, and the
Java Communication Services. The SAP Java Connector (SAP Jco) enables method calls between
Java applications and ABAP applications (Such as SAP ECC, SAP BI).

The following levels need to be protected against single points of failure:

20
The layers below the business applications are generally transparent to these applications. However,
in the event of errors, they can affect the availability of the business applications and you must there-
fore protect them. Partners offer a number of proven solutions for this purpose. The most important
mechanisms are described briefly below.

Network

To operate SAP applications in networks, additional components (for example, routers,

switches, firewalls, load balancers) are required, which can also be single points of failure. These
components are provided by partners. Note especially the following basic measures:

Ø Provider Connection
Ø Router and Firewall
Ø Network Load Balancing
Ø Redundant Server Networks
Ø Other Network Services (DNS, e-mail, domain controllers, and directory servers) also
require to be designed with High Availability

Storage

Disk storage is particularly important for high availability. It stores important data that needs to
be called quickly and reliably.

There has been a trend away from storage units that are connected directly to local comput-
ers towards storage systems at network level. A Storage Area Network (SAN) is a highspeed net-
work of shared storage systems. SANs are intended for block-oriented input and output. They are
normally accessed using fiber channels and are suitable for large environments with high perfor-
mance and scalability requirements.

A Network Attached Storage (NAS) device is a server that has the sole task of providing
disk space. NAS enables storage systems to be provided and extended flexibly, without affecting the
servers using them. NAS devices are intended for file-oriented input and output and are normally ac-
cessed from IP networks.

Server

You can increase the availability of a server by using multiple components on different serv-
ers. This is particularly worthwhile if the applications running on the server are single points of failure.

21
The following features can increase the availability of servers:

Ø Redundant resources, such as boards, space, power supply, bus

Ø Uninterrupted power supply
Ø Error-correcting memory (ECC memory)
Ø Mirrored disks
Ø Hot-plug compatible components
Ø Partitioning of server resources

The solutions provided by SAP hardware partners include all these features.

Operating System

You should make sure that resources managed by the operating system (for example, host-
name, IP address, disk storage, processes) are set up so that applications can continue using them
transparently if the underlying hardware fails. To achieve this, multiple layers of hardware can be used
with controlling cluster software, which appears externally as one unit. A switchover mechanism en-
sures that the resources assigned to a node in the cluster are automatically reassigned to another
node in the cluster in the event of the first node failing. The affected resources remain available, ex-
cept at switchover time.

There are the following cluster types:

Ø Shared Nothing Cluster is a cluster in which each node has its own tasks but also, in the
event of another node failing, takes on the tasks of the failed node. Also, in the event of serv-
er resources failing, nodes are assigned other server resources.

Ø Shared Everything Cluster is a clustering model in which each server can have simultane-
ous read and write access to all common data.

Database

The database is a central building block in the SAP component. Since the data is crucial, not
only do you have to make sure that the database is safeguarded against failure, but you also have to
regularly save the data itself and check that it can be recovered. SAP supports nearly all important
database systems.

22
4.3 HA Solution for Maihar

For an SAP component, you can operate the database host and the central instance on two
opposite nodes of a cluster, for example. If one of the nodes fails, its resources are transferred to the
remaining node, so that the database host and the central instance then run on this remaining host.
This normally results in a loss of information. And also while sizing the system, it need to ensure that
the remaining host now has to perform both tasks.

Responsibility to configure High availability other than Database lies with Infrastruc-
ture partner.

Setup of HA: Active - Active

Scenario – 1: Normal conditions.

Use of Active – Active clustering. i.e Host which are used in HA scenario would be used operational
during normal operations.
v Database services and Central services supported from DB server.
v Apps server1 would work in cluster environment with DB server. At same time Apps server1
work as to support Dialog server.

23
 Scenario - 1
BI / ECC Production BI / ECC Production
DB Server Apps Server1
With SCS & ASCS Disk space: 50GB
Disk Space: 760GB

Scenario - 2 : In case of Apps server1 failure in cluster environment.

Normal Business operation continues as Critical service (Database, Central services) available. SAP
System continues to support through other application server available in production environment.

At the same time, it is to be note that, since due to loss of one application server, system would be
continue to operate with lesser load. i.e. if Application server contribute 30% dialog server load
then system would continue to operate with 70% processing capacity.

Scenario - 2
BI / ECC Production BI / ECC Production
DB Server Apps Server1
With SCS & ASCS Disk space: 50GB
Disk Space: 760GB

Scenario - 3 : In case of DB failure in cluster environment

Normal Business operation will affect temporary as Critical service (Database, Central services) as
resources and services from DB server transferred to Apps Server1. Once resources moved from to
Apps server1 SAP System continues to support through other application server available in produc-
tion environment.

At the same time, it is to be note that, since due to loss of one application server to database server,
system would be continue to operate with lesser load. i.e. if Application server contribute 30%
dialog server load which later on transfer to DB server then system would continue to operate with
70% processing capacity.

24
 Scenario - 3

BI / ECC Production BI / ECC Production

DB Server Apps Server 1
With SCS & ASCS DB Server
With SCS & ASCS

Setup of HA: Active - Passive

Scenario – 1: Normal conditions.

v Database services and Central services supported from one server and its connected to
common storage system.
v Standby server with same configuration of DB server remains available in cluster environ-
ment.

Scenario - 1
BI / ECC Production BI / ECC Production
DB Server DB Server Standby
With SCS & ASCS
Disk Space: 760GB

Scenario - 2 : In case of Standby system failure in cluster environment.

Normal Business operation continues as Critical service (Database, Central services) available. SAP
System continues to support through other application server available in production environment.

There will not be any loss in SAP System capacity.

25
 Scenario - 2
BI / ECC Production BI / ECC Production
DB Server DB Standby Server
With SCS & ASCS
Disk Space: 760GB

Scenario - 3 : In case of DB failure in cluster environment

Normal Business operation will affect temporary as Critical service (Database, Central services) as
resources and services from DB server transferred Standby. Once resources moved from to Standby
server, SAP System continues to support through other application server available in production en-
vironment.

Scenario - 3

BI / ECC Production BI / ECC Production

DB Server Standby Server
With SCS & ASCS DB Server
With SCS & ASCS

Active - Active Active - Passive

Pros: Pros:
1. Lesser hardware cost. 1. SAP System will always able to perform at 100%.
2. Maximum Utilization of resouces. 2. Cluster setup is easy.

Cons: Cons:
1. Incase of Failover, System will operate with 1. Resource remain ideal which can be use for produc-
lesser load. tive use.

Seeing MAIHAR requirement, We suggest to have further discussion with hardware vendor for
Active-Active clustering.

26
5 DISASTER RECOVERY SOLUTION

5.1 Understanding DR

A disaster is a failure that prevents production at an entire location for an extended period.

For example, a disaster might have the following causes:

ü Power failure
ü Flood
ü Fire
ü Tornado
ü Earthquake
ü War

In this event Maihar Cement might need a disaster recovery site to survive, so that production can
resume quickly at a separate location.

5.2 DR with Replicated Database

Database methods for replicating data are used. The type and method of implementation de-
pend on the respective database platform.

For example, the log files can be replicated so that, in the event of database failure, the stand-
by database can be started up using the log files and a consistent status reached. However, in the
case of asynchronous replication (for example, log-file replication), be aware that the standby data-
base might have an older dataset than the original and that it takes longer to start up the database
due to forward recovery.

27
5.3 DR Solution for Maihar

We Suggest to Maihar cement to have DR site in their environment. In order to reduce the cost
and better utilization of resources, DR site can be constructed at Non-productive environment. In or-
der to have characteristic of DR site, Non-productive environment need to be at location other than
Productive environment.

In case of failure of Production system, Development and Sandbox system will be shutdown
and the resource allocated to Development and Sandbox system will transfer to DR production sys-
tem.

Background to setup DR:

1. Strong network connection is required between Productive and Non-productive environment.

Strong network will help to have DR synchronization and DR site would be lagging by few
hours to production environment.
2. If Network is restriction then, backup restore technology can be used for DR synchronization.
3. Dynamic Hardware allocation is required in non-productive environment.
4. Typically DR site operate at 40-60% load of actual production system. Business approval is
required before accepting and activating DR system.

Non- Production Site in Normal Situation:

1. All Development, Quality and Sandbox system is operated at actual Size.

2. DR CI+DB server remains operation with minimal resources which are required to sync the
database.
3. Application servers of production system (for ECC, BI) are in shutdown mode.

Non-production Site in DR Situation (Production Landscape crashed) :

1. Shutdown the Development and Sandbox system.

2. Transfer of resources from Development and Sandbox system to DR CI+DB and DR applica-
tion servers.
3. Activating Standby database and start the DR production system.

28
Normal Situation:

Non-Production Site
Production Site
Solution Manager

4000 SAPS, ECC Production DB

8 GB Server with SCS and
Disk Space: 200GB ASCS
Disk space: 760GB
ECC Sandbox Server
4000 SAPS,
8 GB
Disk Space: 200GB

ECC Development
Server Production Production Production
CPU: 4000 SAPS Apps Server1 Apps Server2 Apps Server3
RAM: 8 GB Disk Space: Disk space: Disk Space:
Disk space: 200GB 50GB 50GB 50GB

ECC Quality Server

CPU: 8000 SAPS

RAM: 12 GB
Disk Space: 400GB
BI Production DB
BI Sandbox Server Server
With SCS & ASCS
4000 SAPS, Disk Space: 800GB
8 GB
Disk Space: 200GB

BI Development Server

CPU: 4000 SAPS

RAM: 8 GB
Disk Space: 200GB Production Production
Apps Server1 Apps Server2
BI Quality Server Disk space: 50GB
Disk space: 50GB
CPU: 8000 SAPS
RAM: 12 GB
Disk space: 400GB

DR BI Production Sys-
tem
DB+CI

DR BI Production Sys-
tem
Application Server1

DR ECC Production
System
DB+CI

DR ECC Production
System
Application Server

29
DR Situation:

Non-Production Site
Production Site

Solution Manager
ECC Production DB
4000 SAPS, Server with SCS and
8 GB ASCS
Disk Space: 200GB Disk space: 760GB

ECC Sandbox Server

4000 SAPS,
8 GB
Disk Space: 200GB

ECC Development Production Production Production

Server Apps Server1 Apps Server2 Apps Server3
CPU: 4000 SAPS Disk Space: Disk space: Disk Space:
RAM: 8 GB 50GB 50GB 50GB
Disk space: 200GB

ECC Quality Server

CPU: 8000 SAPS

RAM: 12 GB
BI Production DB
Disk Space: 400GB
Server
BI Sandbox Server With SCS & ASCS
Disk Space: 800GB
4000 SAPS,
8 GB
Disk Space: 200GB

BI Development Server

CPU: 4000 SAPS

RAM: 8 GB Production Production
Disk Space: 200GB Apps Server1 Apps Server2
Disk space: 50GB
BI Quality Server Disk space: 50GB

CPU: 8000 SAPS

RAM: 12 GB
Disk space: 400GB

DR BI Production System
DB+CI

DR BI Production System
Application Server1

DR ECC Production Sys-

tem
DB+CI

DR ECC Production Sys-

tem
Application Server

30
6 BACKUP STRATEGY
6.1 Types of Backup in SAP Environment

1 Database backup

Database backup will take care of the backup for RDBMS data. All the customization, compa-
ny data, transaction data are stored in the Database. It is very important to have regular backup of
database to secure the company data. You can rebuild the system, if you have a copy of Data-
base. Thus database backup is critical and also requires security measures.

1.1 Online backup: System should have daily on-line backup, which should run during off office
hours. It is possible to recover system for any given date with online consistent backup and data-
base logs. Before starting schedule of online backup it is necessary to estimate the time required
for online backup. With Online backup end user continues to work on SAP System with very little
performance impact. Therefore one has to see for the depending factors which are …

- Database size
- Backup device
- Network interface and network bandwidth between backup device and Server

1.2 Database log backup: It’s always suggested to have update log file backup once in every 30 to
60 mins to have minimum data loss incase of database crash. Size of Database logs and fre-
quency of backup decide the business data loss in terms of time.

For e.g. - If a client have Oracle database running on Solaris. Size defined for ORAARCH file sys-
tem is 30 GB. In this case, archive log backup will be triggered when file system reached 80% of
st
usage i.e. 24 GB. Considering recovery point of view its suggested to go for the 1 method of up-
date log backup. This will give the time dependant recovery.

1.3 Offline backup: It is suggested to have a complete cold backup i.e. offline backup once in month
or before any major upgrade planned. Typically this happens during weekends. Some of the
clients also go for regular database maintenance work before this backup. It is also recommended
to have an offline backup before any of the major activity in the system like data migration. This
can be used for single point of recovery for database.

2 File system backup

Some of the application files resides on the operating system like application executable (SAP
EXEs), interface files, application support scripts. In case of J2EE stack system, some of the java
level configurations will also be stored in the file system (and not in database).

2.1 Daily online incremental backup: It is suggested to have daily online incremental backup for file
system. It will be good if file system backup taken at the time of daily database backup. This will
keep file system in sync with the database.

2.2 Offline complete backup: Once in a month complete offline backup needs to be done.

31
 In most of the locations, complete system cold backup will be taken once in a month, this means
database and application will be brought down and complete file system backup (along with data-
base files) will be done. This will give single point of recovery for entire system. It is also recom-
mended to go with this backup before staring the major activities like SPS upgrade.

Now difference between Offline Database backup (1.3) and offline file system backup (2.2) is file
system backup gives you single point of recovery for entire system where as with database back-
up only data will be recovered. In case of change in files like kernel upgrade, java configuration,
interface scrip changes one has to go for file system backup. In case of data upload or data mi-
gration activity only database backup is sufficient.

6.2 Backup Solution for Maihar

Each company must have backup strategy is well established and backup schedule properly
followed to safeguard the business data against any abnormal condition of system crash. An
essential part of a backup strategy is the management of storage devices.

· What type of backup media is to be used, for example, disks or tapes?

You can choose to backup either to tape or to disk. Usually tapes are used because
they are less expensive and easier to handle. We suggest having Tapes as storage for
backup media.

· How long tapes should be saved before they are overwritten?

§ Transaction log, full database backups and differential database backups
Set the expiration period to 27 days for Online database backup. This means the back-
up cannot be overwritten for 27 days. SAP Planning Calendar provide options to protect
tapes or disk backup devices from being overwritten during the backup cycle.
It is also recommended to have one offline backup in backup cycle.
Keep the last database backup of each month for a year and the last database backup
in the financial year permanently.
§ Complete System Backup
Use at least two tape sets in rotation so that the last two backups are always available.

· How many tapes are needed and their capacity?

The number of tapes you need depends on:

§ The number of days in the backup cycle
§ The number of tapes required for the various database and transaction log back-
ups of the day.

You are strongly advised to use 2 tapes per day; one for the database backup and
one for the transaction log backup.
You are also required to take backup of Sandbox, Development and Quality system
on atleast weekly offline backup with database log. 1 Tape for each system also re-
quired to backup the transaction logs on daily basis.
Apart from this, additional tape blank tape should be made available for case of urgency.

32
· How tapes should be labeled?
If you use the tape naming conventions that SAP recommends, you can identify the con-
tents of a tape simply by looking at the label. Always make sure that the correct name
sticker has been placed on the tape cartridge before you insert it into the tape device.

Character 1 identifies the Single Database:

database on the tape S: Master database backup
M: msdb database backup
R: SAP database backup
O: Other databases backup
Multiple Database:
C: Combination (SAP database not in-
cluded)
I: Combination (SAP database in-
cluded)
Character 2 identifies the L: Transaction log backup
type of backup D: Database backup
+: Differential database backup
Do not mix transaction log backups and data-
base backups on one tape
Characters 3 and 4 indicate
the day of the month
Character 5 indicates P: Parallel backup
whether it is a parallel or a S: Sequential backup
sequential backup

· How backups that need more than one tape should be organized
It is recommends you to test and validate the backup and restore process regularly so
that you can restore your database to a correct and consistent state

33
7 ANNEXURE

7.1 Annexure – 1 Sizing Input Sheet provided by Maihar

7.2 Annexure – 2 Product Availability Matrix (OS / DB Matrix for SAP Net-
weaver SR2)

SAP ECC 6.0 , SAP BI 7.0 and SAP Solution Manager is based on SAP Netweaver SR2. At-
tached sheet shows the possible combination of OS and database platform, on which product can be
installed.

7.3 Annexure – 3 SAPGUI Support matrix for OS

SAPGUI is client software, which is required to access ECC 6.0, BI 7.0 and Solution manager 7.0 ap-
plications. Following is matrix which shows available version of SAPGUI supported on OS platform.

34