sap

4

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

5

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

6

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.

7

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.

8

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)

9

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.

10

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

11

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.

12

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

Transports for Client specific Objects

Cross client object Changes

Protection: Client copier and Compari-sion tool

CATT / SE06 Settings

eCATT

Sandbox (IDES)

SAND Demo Automatic recording of Changes

Changes to Repository and Cross - Client is allowed

Protection Level 1: No overwriting

Allowed Global Set-tings: Modifia-ble

Software Component: Modifiable

Name Space: Modifiable

Development CUDV Customizing and Devel-opment

Automatic recording of Changes

Changes to Repository and Cross - Client is allowed


Not Allowed Global Set-tings: Modifia-ble

Development

TEST

Test

No Changes allowed

No Changes to Reposito-ry and Cross - Client is allowed


Allowed

Software Component: Modifiable

Name Space: Modifiable

NA

Development

PROT

Demo

Changes with-out Automatic recording, No transports allowed



Allowed

NA

Quality As-surance

QTST

Quality as-surance Test

No Changes allowed



Allowed

Global Set-tings: Not Modifiable

Quality As-surance

TRNG

Training / Education

No Changes allowed



Allowed

Software Component: Not Modifiable

Name Space: Not Modifiable

NA

Production

PROD

Production

No Changes allowed


Protection Level 2: No overwriting and no external availability

Not Allowed

Global Set-tings: Not Modifiable

2.3 User and Authorization Strategies for each Client

13

User Types Sandbox (SAND)

Prototype (PROT)

Customization and Develop-ment (CUDV)

Test (TEST)

Quality Assurance Test (QTST)

Training (TRNG)

Production (PROD)

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

14

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

15

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.

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.

Development Server

CPU: 3250 SAPS RAM: 6 GB

Disk space: 200GB

Quality Server

6500 SAPS, 12 GB

Disk Space: 400GB

Production DB Server With SCS & ASCS Disk Space: 760GB

Production Apps Server1

Disk space: 50GB


Disk space: 50GB

Production System


Disk Space: 50GB

Sandbox Server


Disk Space: 200GB

16

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.

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.

Development Server


Disk space: 200GB

Quality Server

8000 SAPS, 12 GB

Disk Space: 400GB

Production DB Server With SCS & ASCS Disk Space: 800GB


Disk space: 50GB


Disk space: 50GB

Production System

Sandbox Server


Disk Space: 200GB

17

3.5 Sizing for Solution Manager

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

Solution Manager Serv-er


Disk space: 200GB

18

3.6 System Architecture for Maihar Cement

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

BI Quality Server


Disk space: 400GB

BI Production DB Server

With SCS & ASCS Disk Space: 800GB


Disk space: 50GB


Disk space: 50GB

Production Site

BI Development Server


Disk Space: 200GB

BI Sandbox Server

4000 SAPS, 8 GB

Disk Space: 200GB

ECC Quality Server


Disk Space: 400GB

ECC Development Server


Disk space: 200GB

ECC Sandbox Server 4000 SAPS,

8 GB Disk Space: 200GB

Solution Manager

4000 SAPS, 8 GB

Disk Space: 200GB

Non-Production Site


Disk space: 50GB

ECC Production DB Server with SCS and

ASCS Disk space: 760GB


Disk Space: 50GB


Disk Space: 50GB

19

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.

20

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:

21

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.

22

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.

23

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.

24

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

BI / ECC Production DB Server


BI / ECC Production Apps Server1

Disk space: 50GB

Scenario - 2



BI / ECC Production Apps Server1

Disk space: 50GB

Scenario - 1

25

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



BI / ECC Production DB Server Standby

Scenario - 1

BI / ECC Production Apps Server 1

DB Server With SCS & ASCS


With SCS & ASCS

Scenario - 3

26

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.

Active - Active Active - Passive

Pros: 1. Lesser hardware cost. 2. Maximum Utilization of resouces.

Pros: 1. SAP System will always able to perform at 100%. 2. Cluster setup is easy.

Cons: 1. Incase of Failover, System will operate with lesser load.

Cons: 1. Resource remain ideal which can be use for produc-tive use.

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

BI / ECC Production Standby Server

DB Server With SCS & ASCS


With SCS & ASCS

Scenario - 3



BI / ECC Production DB Standby Server

Scenario - 2

27

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.

28

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.

29

Normal Situation:

BI Quality Server


Disk space: 400GB




Disk space: 50GB


Disk space: 50GB

Production Site



Disk Space: 200GB

BI Sandbox Server

4000 SAPS, 8 GB

Disk Space: 200GB

ECC Quality Server


Disk Space: 400GB



Disk space: 200GB



Solution Manager

4000 SAPS, 8 GB

Disk Space: 200GB

Non-Production Site


Disk space: 50GB




Disk Space: 50GB


Disk Space: 50GB

DR ECC Production System

Application Server

DR ECC Production System DB+CI

DR BI Production Sys-tem

Application Server1

DR BI Production Sys-tem

DB+CI

30

DR Situation:

BI Quality Server


Disk space: 400GB




Disk space: 50GB


Disk space: 50GB

Production Site



Disk Space: 200GB

BI Sandbox Server

4000 SAPS, 8 GB

Disk Space: 200GB

ECC Quality Server


Disk Space: 400GB



Disk space: 200GB



Solution Manager

4000 SAPS, 8 GB

Disk Space: 200GB

Non-Production Site


Disk space: 50GB




Disk Space: 50GB


Disk Space: 50GB

DR ECC Production Sys-tem

Application Server

DR ECC Production Sys-tem

DB+CI

DR BI Production System Application Server1

DR BI Production System DB+CI

31

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 usage i.e. 24 GB. Considering recovery point of view its suggested to go for the 1

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

32

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.

33

· 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 database on the tape

Single Database:

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 type of backup

L: Transaction log 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 whether it is a parallel or a sequential backup

P: Parallel backup

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

34

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.

sap

Documents

sap web application

sap erp application

sap ecc application

database server

sap instance

sap db

applications server

sap level