36913496-Sap

Embed Size (px)

Citation preview

  • 8/8/2019 36913496-Sap

    1/31

    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 tointegrate your core business processes such as customer relationship management, supply chainmanagement, supplier relationship management, and product life-cycle management SAP ERPprovides 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 ofmidsize companies and large organizations across all industries and market sectors. It helps enter-prises like yours perform financials, human capital management, procurement and logistics, productdevelopment 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 extendend-to-end business processes to your customers, partners, and suppliers. SAP ERP can serve as abusiness 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 orientedarchitecture (enterprise SOA).

  • 8/8/2019 36913496-Sap

    2/31

    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 ofpeople, 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, Suns

    J2EE, and IBM WebSphere. SAP NetWeaver is the technical foundation for SAP ECC 6.0 solutionsand ensures maximum reliability, security, and scalability, so mission-critical business processes runsmoothly. 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

  • 8/8/2019 36913496-Sap

    3/31

    6

    1.4 Introduction to SAP Web Application Server

    Lets understand WAS in simple context. SAP Web Application Server (WAS) is integral part ofSAP Netweaver and ultimately the core engine which has the processing capabilities. There are twotypes 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 SystemLandscape you can have as many as application server you require to support business operationand only one database server.

  • 8/8/2019 36913496-Sap

    4/31

    7

    SAP Web Application Server: Each WAS (Application Server) has 2 main components, Dispatcherand 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 thedynpro 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 thenone applications server per SAP instance. The task of message server is to check the availability ofthe 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, cant 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 canaccess the SAP ECC application through SAPGUI (Thick Client) or Browser (Thin Client).Connectionrequest 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 contextalso 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 sharedbuffer. 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 multipleactive sessions and its not limited to dedicated session as in legacy system.

  • 8/8/2019 36913496-Sap

    5/31

    8

    2 PROMOTE TO PRODUCTION LANDSCAPE.

    The ideal software landscape to support the implementation is comprised of environments supportingthree distinct needs that provide a solid promote to production change manag ement and changecontrol process for all configuration and developments. These environments should provide:

    An environment where customizing and development can be performed. The environmentshould be representative of the productive environment and contain all product productioncustomizing, 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 usedfor 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 andcontains all product customizing, developments and in most cases production quality data. Inaddition this environment will also have newly completed customizing/developments that arein 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 replicatingand debugging productive issues.

    An isolated and stable production environment. The environment is the system of record andonly contains productive customizing and developments. No development tasks are per-formed in this environment, just productive tasks. This environment may additionally be usedfor 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), 1Quality Assurance system (QAS), and 1 Development System (DEV).

    Sandbox System (SBX)

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

    Development System (DEV)

  • 8/8/2019 36913496-Sap

    6/31

    9

    Since each business needs to adapt the SAP software for its own business needs, each SAP systemlandscape 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 alsoperformed 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 systemusing the change management system. This ensures consistency, management, tracking and auditcapabilities thus minimizing risk and human error by eliminating manual repetition of development andcustomizing 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 affectother 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 systemcontainingthe company's live datais where the real business processes are executed.

    The other systems in the landscape provide a safe approach to guaranteeing that only correct andtested (that is not defective) new developments and/or customizing configurations get deployed intothe 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 implementedchange management processes directly impacts the quality of the production system.

  • 8/8/2019 36913496-Sap

    7/31

    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 SAPInstance. This means that all business data within a client is protected from other clients. Each clienthas its own customer data, business data, transaction data, which can be considered as the exclusiveproperty 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 SAPSystem 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 Customizingsettings and possibly ABAP Workbench developments can be made.

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

  • 8/8/2019 36913496-Sap

    8/31

    11

    client. A TEST client is always set up in the same SAP System as the Customizing client. This meansthat any changes that are made to cross-client data in the Customizing client are also immediatelyvisible in the TEST client. Changes to client-specific data are copied from the Customizing client tothe TEST client using a special client copy function. The client copy function uses the unreleasedchange requests from the Customizing client to do this. The TEST client is set so that one cannotmake 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 notsure 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 recordchanges made to client-specific Customizing data, and does not transport them from the prototypeclient. One can be sure of this by making appropriate client settings. Required Master and Transactiondata 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 theproduction client, a separate training client can be set up. The users can use the new functions in thisclient with specially created application data. This client is set so that no changes to Customizing dataand Repository objects can be made.

    Quality Assurance Client (QTST): Before one can use the Customizing settings and Workbenchdevelopments 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 integratednature 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. Sothat 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.

  • 8/8/2019 36913496-Sap

    9/31

    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 andTransports forClient specificObjects

    Cross client objectChanges

    Protection: Clientcopier and Compari-sion tool

    CATT / SE06 Settings

    eCATT

    Sandbox(IDES)

    SAND Demo Automaticrecording ofChanges

    Changes to Repositoryand Cross - Client isallowed

    Protection Level 1:No overwriting

    Allowed Global Settings: Modifia-ble

    SoftwareComponent:Modifiable

    Name Space:Modifiable

    Development CUDV Customizingand Devel-opment

    Automaticrecording ofChanges

    Changes to Repositoryand Cross - Client isallowed

    Protection Level 1:No overwriting

    Not Allowed Global Set-tings: Modifia-ble

    Development TEST TestNo Changesallowed

    No Changes to Reposito-ry and Cross - Client isallowed

    Protection Level 1:No overwriting

    Allowed

    SoftwareComponent:Modifiable

    Name Space:Modifiable

    NA

    Development PROT Demo

    Changes with-

    out Automaticrecording, Notransportsallowed

    No Changes to Reposito-ry and Cross - Client isallowed

    Protection Level 1:No overwriting

    Allowed NA

    Quality As-surance

    QTSTQuality as-surance Test

    No Changesallowed

    No Changes to Reposito-ry and Cross - Client isallowed

    Protection Level 1:No overwriting

    AllowedGlobal Set-tings: NotModifiable

    Quality As-surance

    TRNGTraining /Education

    No Changesallowed

    No Changes to Reposito-ry and Cross - Client isallowed

    Protection Level 1:No overwriting

    Allowed

    SoftwareComponent:Not Modifiable

    Name Space:Not Modifiable

    NA

    Production PROD ProductionNo Changesallowed

    No Changes to Reposito-ry and Cross - Client isallowed

    Protection Level 2:No overwriting and noexternal availability

    Not AllowedGlobal Set-tings: NotModifiable

    2.3 User and Authorization Strategies for each Client

  • 8/8/2019 36913496-Sap

    10/31

    13

    User TypesSandbox(SAND)

    Prototype(PROT)

    Customizationand Develop-ment (CUDV)

    Test (TEST)

    QualityAssuranceTest(QTST)

    Training(TRNG)

    Production(PROD)

    Business Process Owner 3 2 2 2 3 3 3

    Functional Consultant 3 3 3 3 3 2 2

    Technical Developer 3 2 3 3 3 2 2Basis Consultant 3 3 3 3 3 3 3

    System End User 2 2 2 2 2 3 3

  • 8/8/2019 36913496-Sap

    11/31

    14

    3 SAPSERVER SIZING

    3.1 Understanding Sizing parameter

    SAPS

    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 SAPenvironment and derived from the Sales and Distribution (SD) Benchmark.

    100 SAPS means processing 2000 fully business process line items per hour. Cost Factor (Importance in System Sizing): Number of servers and/or CPUs require.

    Disk

    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) tilluser activity is complete. When data can't be avoided or needs to be moved it will stored inDatabase.

    Expressed in GB(GigaByes) / MB(MegaBytes) Cost Factor (Importance in System Sizing):

    Backup/recovery depends on size of database Disk I/O

    Memory (RAM)

    Each program execution requires real-time memory to process. SAP real-time memorystructure has many components such as User contexts (Roll area, Heap Area, Extendedmemory), shared buffer memory etc.

    Expressed in GB(GigaByes) / MB(MegaBytes)

    Cost Factor (Importance in Sizing): physical memory slots.

    3.2 General assumption for Sizing

    Sizing of SAP ECC 6.0, SAP BI 7.0 and SAP Solution Manager 7.0 is considered in currentphase of the project.

    Sizing estimation is totally based on input provided by IT team from Maihar Cement ( ForECC 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.

    Sizing and solution architecture suggested is hardware independent. Its very important tohave final solution from Hardware vendor based on Hardware technology.

    Sizing estimations are calculated to support the SAP operation after 3 years as well.

    Utilization of production resources is at 60% including buffer of 30%. Sizing estimation considered 20 ABAP object development (Objects in customer Namespace).

  • 8/8/2019 36913496-Sap

    12/31

    15

    3.3 Sizing for ECC Systems

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

    Disk Space: We have estimated that Database growth will happen at 12GB / Month. Thus144GB / Year and 432GB at end of 3 year. Plus we need to consider additional disk space fordatabase 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 shouldbe 70% so total Disk storage requirement is around 760GB.

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

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

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

    Development Server

    CPU: 3250 SAPSRAM: 6 GB

    Disk space: 200GB

    Quality Server

    6500 SAPS,12 GB

    Disk Space: 400GB

    Production DB ServerWith SCS & ASCSDisk Space: 760GB

    ProductionApps Server1

    Disk space: 50GB

    ProductionApps Server2

    Disk space: 50GB

    Production System

    ProductionApps Server3

    Disk Space: 50GB

    Sandbox Server

    CPU: 3250 SAPSRAM: 6 GB

    Disk Space: 200GB

  • 8/8/2019 36913496-Sap

    13/31

    16

    3.4 Sizing for BI Systems

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

    Sandbox (IDES) and Development system is designed to have load of 30 Concurrent SAPuser / Functional Consultant / Developer. Though compare to SAP ECC 6.0 System, SAP BI7.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, dataloading and reporting. Also SAP BI 7.0, by default comes with SAP EP 7.0 component.

    Disk Space: We have estimated that Database growth will happen at 12GB / Month. Thus144GB / Year and 432GB at end of 3 year. Plus we need to consider additional disk space fordatabase 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 shouldbe 70% so total Disk storage requirement is around 800GB.

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

    Development Server

    CPU: 4000 SAPSRAM: 8 GB

    Disk space: 200GB

    Quality Server

    8000 SAPS,12 GB

    Disk Space: 400GB

    Production DB ServerWith SCS & ASCSDisk Space: 800GB

    ProductionApps Server1

    Disk space: 50GB

    ProductionApps Server2

    Disk space: 50GB

    Production System

    Sandbox Server

    CPU: 4000 SAPSRAM: 8 GB

    Disk Space: 200GB

  • 8/8/2019 36913496-Sap

    14/31

    17

    3.5 Sizing for Solution Manager

    Explanations:

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

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

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

    o Project Management ( Document storage )o Central System monitoringo Primary SLD ( System Landscape Directory)o Maintenance optimizer

    Solution Manager Serv-er

    CPU: 4000 SAPSRAM: 8 GB

    Disk space: 200GB

  • 8/8/2019 36913496-Sap

    15/31

    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

    CPU: 8000 SAPSRAM: 12 GB

    Disk space: 400GB

    BI Production DBServer

    With SCS & ASCSDisk Space: 800GB

    ProductionApps Server2

    Disk space: 50GB

    ProductionApps Server1

    Disk space: 50GB

    Production Site

    BI Development Server

    CPU: 4000 SAPSRAM: 8 GB

    Disk Space: 200GB

    BI Sandbox Server

    4000 SAPS,8 GB

    Disk Space: 200GB

    ECC Quality Server

    CPU: 8000 SAPSRAM: 12 GB

    Disk Space: 400GB

    ECC DevelopmentServer

    CPU: 4000 SAPSRAM: 8 GB

    Disk space: 200GB

    ECC Sandbox Server4000 SAPS,

    8 GBDisk Space: 200GB

    Solution Manager

    4000 SAPS,8 GB

    Disk Space: 200GB

    Non-Production Site

    ProductionApps Server2

    Disk space:50GB

    ECC Production DBServer with SCS and

    ASCSDisk space: 760GB

    ProductionApps Server1

    Disk Space:50GB

    ProductionApps Server3Disk Space:

    50GB

  • 8/8/2019 36913496-Sap

    16/31

    19

    3.7 Requirement of Re-sizing - Post-Golive

    Prerequisites:

    9 The System is live9 The hardware and software scalable9 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

    9 Growth rate of 20 largest tables9 Average and peak CPU load9 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 causingthe 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 newhardware.

  • 8/8/2019 36913496-Sap

    17/31

    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 completeits 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 availableas all SAP HA scenarios require at least one Switchover Solution.

    Switchover Solution - As the name switchover implies, services can be automatically switchedfrom 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 softwareor other infrastructure elements such as RDBMS, server, storage, or network.

    Availability requiring additional measures. For a high availability system all single points offailure 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, theuse of multiple components that tolerate the failure of individual components or by cluster andswitchover solutions. All SAP hardware partners provide their own proven solutions, which enableSAP 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 andJ2EE in one infrastructure.

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

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

  • 8/8/2019 36913496-Sap

    18/31

    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 importantmechanisms 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. Thesecomponents 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 tobe 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 arenormally 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 providingdisk 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.

  • 8/8/2019 36913496-Sap

    19/31

    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 themtransparently 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 anothernode 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 theevent 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, notonly do you have to make sure that the database is safeguarded against failure, but you also have toregularly save the data itself and check that it can be recovered. SAP supports nearly all importantdatabase systems.

  • 8/8/2019 36913496-Sap

    20/31

    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 theremaining 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 thatthe 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 operationalduring normal operations.

    Database services and Central services supported from DB server. Apps server1 would work in cluster environment with DB server. At same time Apps server1

    work as to support Dialog server.

  • 8/8/2019 36913496-Sap

    21/31

    24

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

    Normal Business operation continues as Critical service (Database, Central services) available. SAPSystem 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 becontinue to operate with lesser load. i.e. if Application server contribute 30% dialog server loadthen 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) asresources 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 with70% processing capacity.

    BI / ECC ProductionDB Server

    With SCS & ASCSDisk Space: 760GB

    BI / ECC ProductionApps Server1

    Disk space: 50GB

    Scenario - 2

    BI / ECC ProductionDB Server

    With SCS & ASCSDisk Space: 760GB

    BI / ECC ProductionApps Server1

    Disk space: 50GB

    Scenario - 1

  • 8/8/2019 36913496-Sap

    22/31

    25

    Setup of HA: Active - Passive

    Scenario 1: Normal conditions.

    Database services and Central services supported from one server and its connected tocommon storage system.

    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. SAPSystem continues to support through other application server available in production environment.

    There will not be any loss in SAP System capacity.

    BI / ECC ProductionDB Server

    With SCS & ASCSDisk Space: 760GB

    BI / ECC ProductionDB Server Standby

    Scenario - 1

    BI / ECC ProductionApps Server 1

    DB Server

    With SCS & ASCS

    BI / ECC ProductionDB Server

    With SCS & ASCS

    Scenario - 3

  • 8/8/2019 36913496-Sap

    23/31

    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 Standbyserver, 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 withlesser 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 forActive-Active clustering.

    BI / ECC ProductionStandby Server

    DB ServerWith SCS & ASCS

    BI / ECC ProductionDB Server

    With SCS & ASCS

    Scenario - 3

    BI / ECC ProductionDB Server

    With SCS & ASCSDisk Space: 760GB

    BI / ECC ProductionDB Standby Server

    Scenario - 2

  • 8/8/2019 36913496-Sap

    24/31

    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:9 Power failure9 Flood9 Fire9 Tornado9 Earthquake9 War

    In this event Maihar Cement might need a disaster recovery site to survive, so that production canresume 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 thecase 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 databasedue to forward recovery.

  • 8/8/2019 36913496-Sap

    25/31

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

    In case of failure of Production system, Development and Sandbox system will be shutdownand 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 fewhours 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.

  • 8/8/2019 36913496-Sap

    26/31

    29

    Normal Situation:

    BI Quality Server

    CPU: 8000 SAPSRAM: 12 GB

    Disk space: 400GB

    BI Production DBServer

    With SCS & ASCSDisk Space: 800GB

    ProductionApps Server2

    Disk space: 50GB

    ProductionApps Server1Disk space: 50GB

    Production Site

    BI Development Server

    CPU: 4000 SAPSRAM: 8 GB

    Disk Space: 200GB

    BI Sandbox Server

    4000 SAPS,8 GB

    Disk Space: 200GB

    ECC Quality Server

    CPU: 8000 SAPSRAM: 12 GB

    Disk Space: 400GB

    ECC DevelopmentServer

    CPU: 4000 SAPSRAM: 8 GB

    Disk space: 200GB

    ECC Sandbox Server4000 SAPS,

    8 GBDisk Space: 200GB

    Solution Manager

    4000 SAPS,8 GB

    Disk Space: 200GB

    Non-Production Site

    ProductionApps Server2

    Disk space:50GB

    ECC Production DBServer with SCS and

    ASCSDisk space: 760GB

    ProductionApps Server1

    Disk Space:50GB

    ProductionApps Server3Disk Space:

    50GB

    DR ECC ProductionSystem

    Application Server

    DR ECC ProductionSystemDB+CI

    DR BI Production Sys-tem

    Application Server1

    DR BI Production Sys-tem

    DB+CI

  • 8/8/2019 36913496-Sap

    27/31

    30

    DR Situation:

    BI Quality Server

    CPU: 8000 SAPSRAM: 12 GB

    Disk space: 400GB

    BI Production DBServer

    With SCS & ASCSDisk Space: 800GB

    ProductionApps Server2

    Disk space: 50GB

    ProductionApps Server1Disk space: 50GB

    Production Site

    BI Development Server

    CPU: 4000 SAPS

    RAM: 8 GBDisk Space: 200GB

    BI Sandbox Server

    4000 SAPS,8 GB

    Disk Space: 200GB

    ECC Quality Server

    CPU: 8000 SAPSRAM: 12 GB

    Disk Space: 400GB

    ECC DevelopmentServer

    CPU: 4000 SAPSRAM: 8 GB

    Disk space: 200GB

    ECC Sandbox Server4000 SAPS,

    8 GBDisk Space: 200GB

    Solution Manager

    4000 SAPS,8 GB

    Disk Space: 200GB

    Non-Production Site

    ProductionApps Server2

    Disk space:50GB

    ECC Production DBServer with SCS and

    ASCSDisk space: 760GB

    ProductionApps Server1

    Disk Space:50GB

    ProductionApps Server3Disk Space:

    50GB

    DR ECC Production Sys-tem

    Application Server

    DR ECC Production Sys-tem

    DB+CI

    DR BI Production SystemApplication Server1

    DR BI Production SystemDB+CI

  • 8/8/2019 36913496-Sap

    28/31

    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 ofdatabase 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 officehours. 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 requiredfor online backup. With Online backup end user continues to work on SAP System with very littleperformance 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:Its always suggested to have update log file backup once in every 30 to60 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% ofusage i.e. 24 GB. Considering recovery point of view its suggested to go for the 1

    stmethod 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 monthor before any major upgrade planned. Typically this happens during weekends. Some of theclients also go for regular database maintenance work before this backup. It is also recommendedto have an offline backup before any of the major activity in the system like data migration. Thiscan 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 (SAPEXEs), interface files, application support scripts. In case of J2EE stack system, some of the javalevel 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 filesystem. It will be good if file system backup taken at the time of daily database backup. This willkeep file system in sync with the database.

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

  • 8/8/2019 36913496-Sap

    29/31

    32

    In most of the locations, complete system cold backup will be taken once in a month, this meansdatabase 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 filesystem 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 properlyfollowed to safeguard the business data against any abnormal condition of system crash. Anessential part of a backup strategy is the management of storage devices.

    x 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 becausethey are less expensive and easier to handle. We suggest having Tapes as storage forbackup media.

    x 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 protecttapes 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 backupin the financial year permanently.

    Complete System Backup

    Use at least two tape sets in rotation so that the last two backups are always available.

    x 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 andone for the transaction log backup.

    You are also required to take backup of Sandbox, Development and Quality systemon 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.

  • 8/8/2019 36913496-Sap

    30/31

    33

    x 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 namesticker has been placed on the tape cartridge before you insert it into the tape device.

    Character 1 identifies thedatabase 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 indicatethe day of the month

    Character 5 indicateswhether it is a parallel or asequential backup

    P: Parallel backup

    S: Sequential backup

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

  • 8/8/2019 36913496-Sap

    31/31

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

    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.