sap os/db migration from hp-ux platform to vblock … objectives of the sap os/db migration from...
Post on 26-Mar-2018
237 Views
Preview:
TRANSCRIPT
© 2011 VCE Company, LLC. All rights reserved. 1
SAP OS/DB MIGRATION FROM HP-UX
PLATFORM TO VBLOCKTM
PLATFORMS
July, 2011
WHITE PAPER
© 2011 VCE Company, LLC. All rights reserved. 2
Table of Contents
Executive Summary .............................................................................................. 3 Business Case .................................................................................................. 3 Key Results ....................................................................................................... 3
Scope ................................................................................................................ 4 Objectives ......................................................................................................... 4 Audience ........................................................................................................... 4
Architecture Overview ........................................................................................... 5
Vblock™ Infrastructure Platform Introduction .................................................... 5 Environment and Configuration Details ................................................................. 6
Customer HP Platform and SAP configuration .................................................. 6 Database configuration on HP-UX Platform ...................................................... 7 Vblock 700 Configuration .................................................................................. 7
SAP Server Configuration on Vblock Platforms ................................................ 8 SAP Database Storage Configuration on Vblock Platforms .............................. 8
Summary comparison of Vblock Platforms and customer‟s HP configuration ... 9 SAP Systems Sizing Considerations ............................................................... 10
Migration ............................................................................................................. 13 SAP OS/DB Migration ..................................................................................... 13 Migration Steps ............................................................................................... 13
1. Prepare the Source System ........................................................................ 13 2. Export of the Source System Database ...................................................... 15
3. Prepare the Target System ......................................................................... 20 4. Import the database into the target system ................................................. 21 5. Post-migration Activities .............................................................................. 29
Test Results ........................................................................................................ 31 Test Environment ............................................................................................ 31 Test Objectives ................................................................................................ 31
SAP performance testing includes two major components: ............................ 32 Testing Results ................................................................................................ 33
Conclusion .......................................................................................................... 34 References ......................................................................................................... 35
Appendix A ......................................................................................................... 36 Test 1 .............................................................................................................. 36 Test 2 .............................................................................................................. 38
Test 3 .............................................................................................................. 40 Test 4 .............................................................................................................. 41
© 2011 VCE Company, LLC. All rights reserved. 3
Executive Summary
This document describes best practices for the OS/DB migration of SAP from HP Integrity Itanium servers running
PA-RISC/HP-UX to the VblockTM
Infrastructure Platforms running x86/Red Hat Linux. These best practices show
how customers can lower the migration risk of moving from a physical environment running HP-UX to Vblock
platforms running Red Hat Linux in a virtualized environment.
Traditional infrastructure practices recommend sizing for the worst case, which is an inefficient approach that adds
to business risk. With Vblock platforms, customers can size for the optimum size and take advantage of the
dynamic scalability for SAP to support the worst-case scenarios.
This paper provides guidance and testing results from a proof of concept (POC) performed for a large
semiconductor equipment manufacturing company. The company‟s SAP landscape includes the following
modules: ERP, SCM, SRM, BI, PI, EP. The tests involved migration and performance of two core SAP modules,
ERP SCM and LiveCache. Vblock Series 700 model MX was used as the target environment for this migration.
Business Case
Virtualization has rapidly gained momentum in enterprise IT environments because organizations are looking for
ways to control escalating hardware costs, and to optimize their use of energy and resources while improving
business continuity. Virtualization of complex SAP applications can reduce costs and increase speed and
resilience. Virtualization also permits faster data analysis and expands data analysis capabilities.
Key Results
Key results demonstrate that once deployed on the Vblock platforms, SAP showed performance improvement
well over the incumbent hardware. The following lists the key findings:
Performance improvement of 50% or more when running SAP on the Vblock platforms compared with a
large semiconductor equipment manufacturer‟s environment.
50% less hardware was used compared to the customer‟s environment
Low migration risk of moving from an HP-UX based physical environment to a Vblock platform virtualized
environment
Fast recovery of failed application and database server blades with UIM and Cisco UCS service profiles
Increase scalability to dynamically add resources
High availability and live migration demonstrated though vMotion
© 2011 VCE Company, LLC. All rights reserved. 4
Figure 1. Vblock platform shows high performance compared to HP-UX
Scope
This document provides best practices for the OS/DB migration of SAP from HP Integrity Itanium servers running
PA-RISC/HP-UX to the Vblock Infrastructure Platforms running x86/Red Hat Linux.
Objectives
The objectives of the SAP OS/DB Migration from HP-UX Platform to Vblock Platforms best practices paper are to:
1. Show how best practices were utilized to successfully complete the SAP migration to Vblock 700 and explain
how customers can use the same best practices to perform their migration. The approaches used for sizing,
application layout, storage layout, and the SAP migration procedure are all based on best practices.
2. Provide the collected testing/monitoring results data associated with the migration, and also demonstrate
running the applications on the Vblock 700.
3. Compare performance of a Vblock platform to a customer environment.
Audience
This paper is intended for Vblock platform customers, SAP administrators and architects, and technical
engineering staff, managers, IT planners, administrators, and other IT professionals who are evaluating, acquiring,
managing, operating, or deploying SAP in a virtualized data center environment.
© 2011 VCE Company, LLC. All rights reserved. 5
Architecture Overview
Vblock™ Infrastructure Platform Introduction
Vblock platforms are enterprise- and service provider-class IT infrastructure units that are pre-engineered, tested,
and validated with pre-defined performance, capacity, and availability service levels. The standardized converged
infrastructure of the Vblock platform is a foundational building block for cloud computing that helps customers to
realize the benefits of applications running in a virtualized environment.
Vblock platforms are characterized by:
Repeatable units of construction based on matched performance, operational characteristics, and
discrete requirements of power, space, and cooling
Repeatable design patterns that facilitate rapid deployment, integration, and scalability
An architecture that can be scaled for the highest efficiencies in virtualization and workload mobility
An extensible management and orchestration model based on industry-standard tools, APIs, and
methods
A design that contains, manages, and mitigates failure scenarios in hardware and software
environments
Note: Refer to the Vblock™
Infrastructure Platform Architecture Overview for detailed information on the Vblock platforms architecture. Use the link provided in the References section of this paper.
At a high level, Figure 1 illustrates the various levels, or “layers” that make up the Vblock Infrastructure Platform.
Note that SAP applications sit above the other layers (OS, Virtualization, Compute, Storage, and Network).
Figure 2. Vblock Infrastructure Platform
© 2011 VCE Company, LLC. All rights reserved. 6
Deploying SAP applications on the Vblock platform creates minimum risk because it has:
Production-ready, pre-engineered, integrated and tested units of virtualized infrastructure
Best-of-breed virtualization, network, compute, storage, security and management products
SLA driven, providing predictable performance capabilities and operational characteristics
Environment and Configuration Details
This section contains the configuration details for: 1. Customer HP platform and SAP configuration 2. The Vblock platforms configuration
a. Vblock 700 configuration b. SAP server configuration on Vblock platforms
Customer HP Platform and SAP configuration
Below are the customer‟s SAP modules that are in the Production landscape on HP-UX Platform.
SAP Component Estimated SAPS
(Based on the Hardware Configuration)
ECC 6.0 77,528
SCM 5.0 17,620
Live Cache 7.6 N.A
CRM 6.0 10,572
BW 7.0 52,860
PI 7.0 12,334
SRM 5.0 15,858
EP 7.0 26,430
GTS 7.1 8,810
GRC 5.3 3,524
SNC 7.0 10,572
Business Objects Enterprise 3.1 10,572
MDM 7.0 10,572
TREX 7.0 3,524
NetWeaver CE 3,524
For the OS/DB Migration proof of concept, the customer‟s business critical applications – SAP ERP Central
Component (ECC), SCM, and Live Cache are considered. All the other components were not migrated.
© 2011 VCE Company, LLC. All rights reserved. 7
The following table details the servers in the ECC environment on HP-UX.
Server Model Operating System No. Of CPUs Memory in MB
ECCPDBCI ia64 hp server rx8640 HP-UX 11i v2 (11.23) 24 147,258
ECCPDI &ECCPDI1
ia64 hp server rx8640 HP-UX 11i v2 (11.23)
24 163,641
ECCPDI2 ia64 hp server rx8640 HP-UX 11i v2 (11.23) 8 65,469
ECCPDI3 ia64 hp server rx8640 HP-UX 11i v2 (11.23) 8 65,468
ECCPDI4 ia64 hp server rx8640 HP-UX 11i v2 (11.23) 8 65,468
ECCPDI5 ia64 hp server rx8640 HP-UX 11i v2 (11.23) 8 32,700
ECCPDI6 ia64 hp server rx8640 HP-UX 11i v2 (11.23) 8 65,468
The following table details the servers in the SCM environment on HP-UX.
Server Model Operating System No. Of CPUs Memory in MB
SCMPDBCI + Live Cache
ia64 hp server rx8640 HP-UX 11i v2 (11.23) 8 65,469
SCMPDI ia64 hp server rx8640 HP-UX 11i v2 (11.23) 8 98,171
SCMPDI2 ia64 hp server rx8640 HP-UX 11i v2 (11.23) 4 16,316
Database configuration on HP-UX Platform
Customer‟s SAP applications were running on Oracle database version 10.2.0.4. HP Service Guard provides high availability for the Oracle database.
Vblock 700 Configuration
The following table describes the Vblock 700 configuration that was used for this testing.
Component Configuration
Cisco Unified Computing System™
Cisco UCS B200-M2 Blade Servers – (4) 2 x Quad Core with 96 GB RAM
Cisco UCS B250-M2 Blade Servers – (4) 2 x Quad Core with 192 GB RAM
Storage EMC Symmetrix V-MAX 2 Engine Base - 112 number 15K FC Drives and 32
7.5K SATA Drives
Storage Area Network 1 FC Switch - Cisco MDS 9506 64 ports
1 Ethernet Switch
1 Virtual Switch - Nexus 1000 V
© 2011 VCE Company, LLC. All rights reserved. 8
SAP Server Configuration on Vblock Platforms
Provided in this section are the configurations of the SAP systems that are part of the migration effort.
The following table describes the ECC environment on Vblock platforms.
Server Type Server Hardware OS vCPU Memory (in GB)
Physical ECCPDBCI UCS B250 M2 RHEL 5.5 N.A 192
Physical ECCPDBCI Failover node UCS B250 M2 RHEL 5.5 N.A 192
Virtual ECCPDI1 UCS B250 M2 RHEL 5.5 4 48
Virtual ECCPDI2 UCS B250 M2 RHEL 5.5 4 48
Virtual ECCPDI3 UCS B200 M2 RHEL 5.5 4 48
Virtual ECCPDI4 UCS B200 M2 RHEL 5.5 4 48
Virtual ECCPDI5 UCS B200 M2 RHEL 5.5 4 48
Virtual ECCPDI6 UCS B200 M2 RHEL 5.5 4 48
The following table describes the SCM environment on Vblock platforms.
Server Type Server Hardware OS vCPU Memory (in GB)
Virtual SCMPDBCI & Live Cache UCS B250 M2 RHEL 5.5 4 48
Virtual SCMPDBCI Failover node UCS B200 M2 RHEL 5.5 4 48
Virtual SCMPDI1 UCS B200 M2 RHEL 5.5 4 48
Virtual SCMPDI2 UCS B250 M2 RHEL 5.5 4 48
SAP Database Storage Configuration on Vblock Platforms
The following table details SAP database storage.
System Total IOPS IOPS/Sec (based on 8x7 time frame)
Database Size (GB)
FC (95%) SATA (5%)
SCM 106692228.2 529 303.74 4.59 0.73
ECC 1817228262 9014 2606.97 78.18 12.35
The following table details the drive configuration.
Drive type Size Drive speed RAID level
FC Drive 450GB 15000 RAID-10
SATA Drive 1TB 7200 RAID-62
© 2011 VCE Company, LLC. All rights reserved. 9
Summary comparison of Vblock Platforms and customer‟s HP configuration
The following table provides an SAP ECC hardware layout comparison between HP and Vblock platforms.
Server Type Server HP Platform Vblock Platforms
Database Layer
Server type HP Integrity Superdome RX8640
Cisco UCS B250-M2
Configuration 24 Cores with 192 GB RAM 12 Cores with 192 GB RAM
OS/DB HPUX 11.23/Oracle 10.2 RHEL 5.5/Oracle 10.2
Number of DB Servers 2 (Physical) 2 (Physical)
SAPS on DB Server 42288 52960
Application Layer
Server type HP Integrity Superdome RX8640
Virtual Machine on B200-M2
Configuration 8 Cores with 65 GB RAM 4 vCPU with 48 GB RAM
OS HPUX 11.23 RHEL 5.5
Total SAPS on App servers 42288 (Physical) 47910 (Virtual)
Number of App server instances
6 6
Total SAPS on App server instances
42288 (Physical) 47910 (Virtual) with 35% of CPU Utilization
© 2011 VCE Company, LLC. All rights reserved. 10
The following table provides an SAP SCM hardware layout comparison between HP and Vblock platforms.
Server Type Server HP Platform Vblock Platforms
Database Layer
Server type HP Integrity Superdome RX8640
Virtual Machine on Cisco UCS B250-M2
Configuration 8 Cores with 65 GB RAM 4 vCPU with 56 GB RAM
OS/DB HPUX 11.23/Oracle 10.2 RHEL 5.5/Oracle 10.2
Number of DB Servers 2 (Physical) 2 (Virtual)
SAPS on DB Server 14096 (Physical) 15970 (Virtual)
Server type HP Integrity Superdome RX8640
Virtual Machine on B200-M2
Application Layer
Configuration 4 Cores with 65 GB RAM 4 vCPU with 48 GB RAM
OS HPUX 11.23 RHEL 5.5
Number of App server 2 (Physical) 1 ESXi
Total SAPS on App servers 7048 (Physical) 15970 (Virtual)
Number of App server instances
2 (Physical) 2 (Virtual)
Total SAPS on App server instances
7048 (Physical) 15970 (Virtual)
SAP Systems Sizing Considerations
For any SAP system, the basic metric for sizing is the SAPS. The SAPS provided by the HP platform was
considered as the basis of the sizing:
The customer‟s HP-UX Platform included an HP Superdome and several RX8640 servers. Below are the SAPS calculations based on the SAP certification:
Total SAPS certified for RX8640 Server with 32 CPU: 28,200
SAPS/Core: 881
The UCS Server Platform has Cisco UCS B200-M2 & B250-M2 blade servers.
Total SAPS certified for Cisco UCS B200-M2 Blade Server with 24 CPU: 26,480
SAPS/Core: 1,103
Based on the current capacity on the HP-UX Platform, the same capacity is provided on the Vblock platform to provide the same number of SAPS.
© 2011 VCE Company, LLC. All rights reserved. 11
For the SAP DB or Application servers that are running on the Virtual Platform, SAPS are calculated as below:
Total number of SAPS available on Cisco UCS B200-M2/B250-M2: 26,480
Total number of SAPS available for better performance with 65% of CPU and considering 10% VMware overhead: 26,480*0.65*0.9 = 15,490
Server
No. of CPUs
Memory in MB
Total SAPS
Blade#
# Cisco UCS M2 Blade
Type SAP Server
Hardware
ECCPDBCI 24 147,258 21,144 1 1 Physical ECCPDBCI
UCS B250 M2
ECCPDI + ECCPDI1
24 163,641 21,144 2 1 Physical
ECCPDBCI Failover node
UCS B250 M2
ECCPDI2 8 65,469 7,048 3 0.45 Virtual ECCPDI1 UCS B250 M2
ECCPDI3 8 65,468 7,048 3 0.45 Virtual ECCPDI2 UCS B250 M2
ECCPDI4 8 65,468 7,048 4 0.45 Virtual ECCPDI3 UCS B200 M2
ECCPDI5 8 32,700 7,048 4 0.45 Virtual ECCPDI4 UCS B200 M2
ECCPDI6 8 65,468 7,048 5 0.45 Virtual ECCPDI5 UCS B200 M2
8 65,468 7,048 5 0.45 Virtual ECCPDI6 UCS B200 M2
SCMPDBCI 8 65,469 7,048 6 0.45 Virtual SCMPDBCI + Live Cache
UCS B250 M2
SCMPDI 8 98,171 7,048 7 0.45 Virtual
SCMPDBCI Failover node
UCS B200 M2
SCMPDI2 4 16,316 3,524 7 0.23 Virtual SCMPDI1 UCS B200 M2
4 16,316 3,524 6 0.23 Virtual SCMPDI2 UCS B250 M2
© 2011 VCE Company, LLC. All rights reserved. 12
The following sizing was performed and represents best practices:
To utilize the advantages of the virtualization that is provided on Vblock platforms, all the SAP
application servers were sized on virtual servers
The ECC database was sized on the physical blade servers per the customer‟s requirement
The SCM database was sized on the virtualized servers
The Live Cache application and its MaxDB database were sized on the virtual servers
Storage sizing was performed using the 2-tier sizing method from EMC
© 2011 VCE Company, LLC. All rights reserved. 13
Migration
The POC migration was performed as a best practice to lower the migration risk of moving from a physical
environment to a Vblock platform virtualized environment. These migration steps demonstrate recommended best
practices.
SAP OS/DB Migration
SAP OS/DB migration is performed based on SAP‟s standard process of „heterogeneous system copy‟. SAP
standard tools are used to perform the OS/DB migration. The following sections provide the step-by-step
procedure.
Migration Steps
The migration involves 5 major steps and their related sub-steps.
1. Prepare the source system
2. Export of the source system database
3. Prepare the target system
4. Import the database into the target system
5. Post-migration activities
For more details on the specific steps, refer to the SAP documentation for Heterogeneous System Copy Guide
available at SAP Service Marketplace. See the link located in the References section of this document.
1. Prepare the Source System
Step 1. Download SAP Media
Verify that all required DVDs for the system copy are available.
Required DVDs:
Installation Master DVD
Java DVD
Step 2. Execute pending updates, if any. Delete any canceled updates
Check for pending or cancelled requests in the system. Check this in transaction SM13. If canceled or pending
updates exist, you must update these again, or delete them from all clients. You can find out whether canceled or
pending updates exist by checking if table VBDATA contains any entries.
Step 3. Delete the QCM tables
Before the export, delete QCM tables from your system. Before deleting always check:
a. That the tables are consistent: no restart log or conversion procedure termination must be displayed.
b. That the data of the original table can be read.
c. If application programs that use the affected original table do not run correctly, do not delete the QCM table, yet.
© 2011 VCE Company, LLC. All rights reserved. 14
Step 4. Delete all entries from tables TATGPC and TATGPCA
Check to make sure that the tables TATGPC and TATGPCA are empty before the export of the source system.
Step 5. Update the latest versions of R3load, R3ldctl, and R3czchk in the Kernel directory
The SAP Migration process uses the following tools. Update these tools to the latest available versions before
starting the migration process:
R3load - Unloads/loads ABAP table data from/into the database
R3ldctl - Unloads ABAP dictionary structures from the database
R3czchk - Computes size of ABAP tables and indexes for the target database and computes the ABAP
related size for the target database.
Step 6. Update the database parameters for sessions and processes
Update the database parameters for sessions and processes on the source system as per SAP
recommendations. These are the factors which affect the data export from the source system.
Step 7. Increase the table space for PSAPTEMP
Increase the table space for PSAPTEMP to avoid any unload terminations during the export process. PSAPTEMP
is the database storage unit that is used for the sorting. R3load exports data in the primary key order. More
temporary databases disk space is required for sorting.
Step 8. Perform the complete database backup
Perform a complete database backup to safeguard the changes made for the export preparation. Regular backup
methods are followed.
Step 9. Run the program SMIGR_CREATE_DDL as batch job
Run the SMIGR_CREATE_DDL program as the batch job in the background, a mandatory step before exporting
the data from the source system.
This program allows the copying of database objects that do not correspond to SAP standards. These objects
include partitioned (fragmented) tables and bitmap indexes. Special '<TABART>.SQL' files are generated for
these objects. These files contain 'native DDL' (create) statements and can be analyzed by R3load.
Step 10.Turn off the archive logs and redo logs mirroring
Disable the archive log mode and redo logs mirroring (use only one redo log member per redo group) to avoid any
space issues during the export process.
Step 11. Mount the NFS share with required size for the export dump
Separate storage is provided to store the export dump. This storage is mounted as NFS share on the source
system.
© 2011 VCE Company, LLC. All rights reserved. 15
Step 12. Check the ‘/tmp’ file system
Check the /tmp file system for its existence and to make sure that it has adequate space as required for the
SAPinst during the export process.
Step 13. Obtain root level access in the source system
Root access is needed to perform the export process on the source system.
2. Export of the Source System Database
Step 1. Start the export preparation process in the source system
Run SAPinst to perform the Export Preparation service.
1. Start the SAP INSTALLER 2. Select: System Copy Oracle Source system export Central system system based on AS
ABAP and AS JAVA Export Preparation
As soon as the export preparations have successfully completed, the complete export directory with its structure
and the generated files that are required for building up the target system are transferred to the export dump
directory. The dump directory, its subdirectories, and files are accessible for <SAPSID>adm of the target system.
Step 2. Table splitting preparation:
The processing unit for one unload/load process is a package. During the standard system copy process, all
tables of the SAP system are grouped into packages, all tables with the same data class belong to the same
package. The packages differ in the number and size of contained tables, resulting in varying unload/load
runtimes. The overall runtime can be reduced by creating packages of the same size. The method to create a
package of the same size is to create packages with a similar processing time. You can achieve this by splitting
the default packages (one package per data class) into smaller pieces.
The table splitting preparation has to be performed by splitting the large tables to parallelize more R3load processes.
1. Set the home to /home/<SID>adm
2. Start the SAP INSTALLER 3. Select: System Copy Oracle Source system export Central system system based on AS
ABAP and AS JAVA Table splitting preparation
© 2011 VCE Company, LLC. All rights reserved. 16
a. Enter the following general parameters for table splitting. The parameters are:
SAPSID
File with Tables to be split
Export Directory
Number of parallel R3ta run
Database type (Oracle)_ b. Select the table splitter option. The option for this migration is ‘R3ta table splitter’. c. Enter the number of WHR files for each table. d. The table splitting preparation is successfully completed.
© 2011 VCE Company, LLC. All rights reserved. 17
Step 3. Start database export (ABAP+JAVA)
To start the database export:
1. Start the SAP INSTALLER.
2. Select System Copy Oracle Source system export Central system system based on AS ABAP and AS JAVA Database and Central Instance Export.
3. Enter the SAP profile directory of the source system. Typically, this is /sapmnt/SAPSID/profile
© 2011 VCE Company, LLC. All rights reserved. 18
4. Choose the method for copying the database content. Use database specific tools option must be unchecked.
5. Enter the export location for the database export. This is typically a local directory or an NFS share.
6. Confirm the execution of the report, SMIGR_CREATE_DDL
a. Provide the location for the SQL File Directory. Any temporary directory will work.
The option “Yes, use the generated SQL files for the system copy” must be checked.
7. Enter the system parameters for the source system database.
8. Enter the Java splitting parameters.
9. Enter the export parameters. Pay attention to the Target Hardware Platform selected as “Little-Endian” .
© 2011 VCE Company, LLC. All rights reserved. 19
10. Enter the unload options for the database export. Unload Options: -loadprocedure fast
11. Choose the option to run the database statistics updates. Here we have chosen to skip the statistics.
12. Update before the export.
13. After you have finished entering all the parameters and options, a summary window will open.
Confirm all your options and choose „Next‟. The export process will be started.
© 2011 VCE Company, LLC. All rights reserved. 20
14. The source system database is now successfully exported.
3. Prepare the Target System
Step 1. Install all the prerequisites for SAP on Linux systems
Install all the RPM‟s that are required by SAP as per SAP Note - 171356.
Step 2. Install Java 1.4.2 IBM version
Install the Java 1.4.2 version as required by the SAP installation.
Step 3. Adopt OS level parameters required for Linux systems as recommended by SAP
Adopt the OS level parameters that are recommended by SAP.
Step 4. Validate the SAP and Oracle file systems
Validate the file systems that are required by the SAP installation.
Step 5. Enable the 3rd
party security software to create the system users
Enable the BoKS software which is required by the customer to create the system users.
© 2011 VCE Company, LLC. All rights reserved. 21
Step 6. Install the Oracle binaries and perform the database patching
Install the Oracle software and update the database and bring it to the required patch level.
Step 7. Mount the NFS file system, which contains the export dump
Mount the NFS file system which is used in the export process as export dump.
Step 8. Create the migration key
Generate the migration key at http://service.sap.com/migrationkey. Enter the installation number of the source
system when prompted.
Step 9. Adopt the database parameters for the processes, sessions and increase SGA
The database parameters are changed on the target system as per SAP recommendations. These are the factors
which affect the data import into the target system.
4. Import the database into the target system
Step 1. Install SCS and ASCS on the Virtual hosts
1. To install SCS and ASCS on the Virtual hosts, start the SAPinst.
2. Select System Copy Oracle Target System Installation Distributed System
Central Services Instance (SCS).
3. Select the parameter mode as „Custom‟.
© 2011 VCE Company, LLC. All rights reserved. 22
4. Provide SAP System parameters such as: a. SAP SID of the target system. b. System mount directory location. Ensure that Unicode System is checked.
5. Review the prerequisites checker. If there are any severe errors, take the necessary action to
resolve.
6. Provide the SCS instance parameter for SCS Instance Number. Typically this set to “00”
7. Provide the SCS instance parameter for Internal SCS Message Server Port.
Accept the default of 3900, and also the SCS instance number selected above.
8. Provide the software packages and the location.
Provide the directory locations where you have stored your installation media.
9. Select the archives that need to be unpacked for the installation.
Check all the checkboxes.
10. After you enter all the parameters and options, a summary window will open.
Confirm all your options and choose ‘Next’. The installation process will be started.
12. The installation of the SCS instance is successfully completed.
© 2011 VCE Company, LLC. All rights reserved. 23
Step 2. Import the database on Virtual hosts
To import the database on Virtual hosts:
1. Start the SAPinst and select: System Copy Oracle Target System Installation Distributed
System Database Instance.
2. Provide the software packages and the location where you have stored your installation media.
3. Provide the JDK directory.
4. Provide the JCE Policy files archive location.
5. Provide the SAP system profile directory. This is typically /sapmnt/SAPSID/profile
6. Provide the master password for all users that SAPinst creates during the installation.
7. Select the installation method as „Standard system copy/Migration (load based)’.
8. Enter the database parameters for the target system database. The database SID should be the
same as the SAPSI you selected in earlier steps.
9. Provide the location of the source system database export directory. This is the location where you
stored the export from the source system database.
© 2011 VCE Company, LLC. All rights reserved. 24
10. Provide the database system parameters.
11. Set the password for the database users.
12. Provide the media location for the database installation.
13. Provide the Oracle listener configuration parameters. Typically this is LISTENER_SAPSID;
14. Leave other options at default values.
15. Select the Oracle advanced configuration parameters.
16. Provide the database instance file systems. ORACLE_HOME, ORACLE_STAGE and sapdata home
Directory.
© 2011 VCE Company, LLC. All rights reserved. 25
17. Provide the SAP data paths. Make sure there are a minimum of 4 SAP data paths.
18. Provide the database specific information as shown below.
19. Provide the table space parameters. Sizes used in this case are listed in the table, below. The following table spaces were designed as shown in the following table.
Table space SAPDATA
Volume File size (GB)
Number of DB files
Total Size (GB)
PSAPSR3 SAPDATA1 20 46 1000
PSAPSR3 SAPDATA2 20 46 1000
PSAPSR3 SAPDATA3 20 30 600
PSAPSR3700 SAPDATA3 20 6 120
PSAPSR3701 SAPDATA3 20 6 120
PSAPSR3DB SAPDATA3 20 1 20
PSAPSR3USR SAPDATA4 20 9 180
PSAPUNDO SAPDATA3 20 4 80
SYSAUX SAPDATA3 10 1 10
SYSYEM SAPDATA3 10 1 10
PSAPTEMP SAPDATA4 20 15 300
PSAPSR3 SAPDATA4 20 8 160
© 2011 VCE Company, LLC. All rights reserved. 26
20. Provide the database control file information. Oracle best practice recommends 3 separate control files.
21. Enter the general load parameters for the database import. Important: The migration key is intentionally entered with a wrong key in order to pause the import after
the DB create. This will help tune the target DB and improve the import performance.
22. Select the option to update the database statistics at the end of the import.
23. Provide the location of the database media for the installation.
After you enter all the parameters and options, a summary window opens. Confirm all your options and choose „Next‟. The installation process begins.
© 2011 VCE Company, LLC. All rights reserved. 27
24. When the system is ready for the database installation, the SAPinst will be stopped and prompted to start the database installation. Complete the database installation and return to SAPinst.
25. When the database installation is complete, choose the „Ok‟ prompt on the SAPinst, This will resume the installation and complete it.
© 2011 VCE Company, LLC. All rights reserved. 28
The installation is now successfully completed.
Step 3. Install Central Instance using Java dump
1. To install, choose the Central Instance option.
2. Provide the software package location as in previous steps.
3. Provide the Profile Directory location; typically this is /sapmnt/SAPSID/profile
4. Enter and confirm the SAP Master Password.
5. Set the Oracle Listener Configuration. 6. Enter the Central Instance Number, typically this is “01”
7. Provide the Central Instance parameters. Leave these at default values.
8. Provide the location of the software packages. 9. Enter and confirm the J2EE Engine Administrator (j2ee_admin) password. 10. Enter the Secure Store user (administrator) and password. 11. Choose the checkbox Interrupt the installation before start of system. 12. Enter the DDIC, client 000 password. 13. Provide the location of the Oracle kernel and Oracle client software packages.
© 2011 VCE Company, LLC. All rights reserved. 29
14. Select desired archives. 15. Provide the SAP Solution Manager Key. Refer to SAP documentation for instructions to get a solution
manager key. 16. Install the Diagnostics Agent.
The installation successfully completes.
Step 6. Install the application servers
Install the application servers for the target system using the SAPinst tool. The detailed procedure is not included
in this document. The installation procedure is available in the „SAP Installation Guides‟ at the SAP site. Use the
link located in the References section of this paper.
5. Post-migration Activities
Step 1. Fine tuning the Database parameters
Follow the SAP recommendations to tune the database parameters based on the target system database. (In this scenario, the target system database is Oracle.)
Step 2. Start SAP
1. Login to the target SAP system host.
2. Start the SAP Database and instance.
Step 3. Run installation check
Run the installation check on the target system using transaction SICK
© 2011 VCE Company, LLC. All rights reserved. 30
Step 4. Install the license key
Once the installation of the target system is completed and the SAP system copy has been imported, you must
install a new license key.
Step 5. Reconfigure Java, Memory tune-up and test
Reconfigure the Java parameters using the SAP Note – 831812.
Step 6. Import the profiles
Import the profiles in transaction RZ10 by selecting from the menu: Utilities Import Profiles of active servers
Step 7. Start the application servers
1. Start the application server instances.
2. Check them in transaction SM50.
Step 8. Reconfigure the STMS and change the hostnames
Configure the Transport Management System (transaction STMS). If you did not change the SAPSID during the system copy, all of the open transport, repair, and customizing requests that have not been released in the source system will not be released automatically.
Step 9. Change all the RFC destinations
In transaction SM59, change the destinations to the new host.
Step 10. Execute the program RS_BW_POST_MIGRATION
Execute the program RS_BW_POST_MIGRATION in the background by using variant SAP&POSTMGR.
Program RS_BW_POST_MIGRATION performs necessary modifications on database-specific objects (mainly BI
objects).
Step 11. Perform TEMSE consistency check and cleanup
Using transaction SP12, check the consistency of the Temporary Sequential Objects (TemSe)
by searching for files of TemSe objects for which no TemSe objects exist, and then delete the objects as
necessary.
Step 12. Configure the logon groups
Configure the logon groups using the transaction SMLG.
Step 13. Perform a complete backup
Perform a complete backup of the system before allowing it to be used.
© 2011 VCE Company, LLC. All rights reserved. 31
Test Results
Test Environment
The test environment was set up using Load Runner 9.2.
Test Objectives
The test objective is to compare the Vblock platform system with the HP-UX environment. This was
performed in two major categories:
1. SAP performance testing.
2. Operational efficiency of a Vblock platform.
Various tests were conducted on a SAP database, central instance, and application server configuration
comparable to the large semiconductor company‟s production configurations. Performance testing was
compared to performance test results from the semiconductor company‟s production P08 and P04 system.
(P08 is the SAP Production Planning system; P04 is the SAP (Delta) Materials Management production
building block.)
Testing included these categories:
Virtualized SAP application server layer
SAP workload balancing using DRS
On demand scaling of SAP application servers
Online response times tests and batch throughput
Stress tests using HP Load Runner to test Vblock platform capacity limits
Reliability and redundancy of Server, Storage, and Network components
Dynamic resource allocation using UIM
Migration of various components
The following test sets were performed:
1. Migrate and run SAP ECC, SCM and Live Cache successfully on Vblock platforms infrastructure:
a. Using standard SAP OS/DB migration tools, the VCE team migrate the SAP landscape from the source
environment to the Vblock platform, transporting the data using an external NAS device or network.
b. Deploy SAP Applications ECC and SCM using Adaptive Installation Best Practices; configure the
systems to enable connectivity to a large semiconductor manufacturing company‟s Adaptive Computing
Controller.
c. Apply SAP best practice recommendation for tuning for optimum performance.
d. Demonstrate complete functionality of SAP ECC and SCM systems by logging into the systems and
executing a few key Basis and sample business transactions.
2. Demonstrate performance of the SAP system on Vblock platforms meets or exceeds the current
benchmarked performance (KPIs) - using standard SAP OS/DB migration tools, the VCE team migrates the
SAP landscape from the source environment to the Vblock platforms, transporting the data using an external
NAS device or network.
3. Demonstrate highly available system meets or exceeds the current SLA and the availability of the current
system.
© 2011 VCE Company, LLC. All rights reserved. 32
a. The HA solution for the SAP systems database: SAP CI & DB HA with Red Hat Linux Cluster suite
(Active, Active solution).
b. The HA solution for the application servers: Multiple DIA and BGD instances on Virtual Machines
distributed on separate ESX servers.
4. Demonstrate „stateless‟ computing (hardware failure and recovery matches or exceeds existing system) by
demonstrating the provisioning of a UCS blade on the Vblock platforms using the service profile in case of a
blade failure.
The above tests were performed using various tools and techniques. Only Vblock platforms and SAP standard
procedures and methods are used to perform benchmarking.
SAP performance testing includes two major components:
1. Interactive performance testing (Dialog Transactions)
For this testing, HP Load Runner was used to simulate Production load (1200 ECC Dialog Users + Batch Runs +
SCM Batch Jobs + Batch Runs) on the SAP Vblock platform. The Avg. Transaction response times were
compared against the Service Levels provided with the AMAT EWR.
Below are some of the metrics that were monitored during the test.
Application & Database Performance Counters:
Average CPU time
Memory
Average response time
Throughput
Average Wait time
Average load time
Database calls
Database request
2. Batch Processing
Batch workload was simulated, in addition to the Dialog runs, to significantly increase the workload on the system
to identify the capacity limits. In addition to the analysis of the Load Runner results, utilization statistics were
gathered at all infrastructure levels (OS, Hypervisor, Storage, and Network) during the runs.
© 2011 VCE Company, LLC. All rights reserved. 33
Testing Results
Performance testing results
• Vblock platforms performed 50% better compared against HP-UX
• Average CPU of HP-UX Production was 42.2%
• Average CPU on Vblock platforms was 17%, under the same load
Stress testing results
• At 42% CPU utilization, HP-UX supported an active user count of 150, and logged on user count of 1200
• At 43% CPU utilization, the Vblock platforms supported an active user count of 250, and logged on user
count of 1800
• At 100% CPU utilization, Vblock platforms supported active user count of 350 and logged on user count of
approx. 2500
SCM – OM17 Batch job testing Results
• 38% performance improvement on Vblock platforms compared to the HP-UX platform
See Appendix A for the formative test data and charts.
© 2011 VCE Company, LLC. All rights reserved. 34
Conclusion
The traditional method of sizing for SAP landscapes on physical servers is to size for the worst-case demand
scenario. This practice is known to have significantly higher initial capital acquisition costs and ongoing operational
costs that are decreasing business agility and increasing business risks.
This paper alleviates concerns of execution risks and provides guidance to customers who choose to re-platform
their SAP landscapes to an x86-based architecture and take advantage of lower capital acquisition costs and
virtualization to improve agility.
The goals for this POC and results outlined in this paper were to:
1. Show best practices were utilized to successfully complete the SAP migration to Vblock 700 model MX and
explain how customers can use the same best practices to perform their migration.
2. Provide the collected testing/monitoring results data associated with the migration that also
demonstrates running the applications on the Vblock 700 model MX.
3. Compare performance of a Vblock platform to a customer environment.
Best practice techniques from the VCE parent companies, who are industry leaders in their respective domains,
were used in sizing of the application and database servers, storage, and file-system layout. This helps remove
the guesswork that is typically used during such efforts. These best practices involved right-sizing of the Vblock
platform at compute, storage, and network layers.
In this POC, it was demonstrated that by using the Vblock platform, and its inbuilt virtualization using VMware, that
the following were achieved :
Performance improvement of 50%, or more, when running SAP on the Vblock platforms compared with a
semiconductor equipment manufacture‟s environment
50% less hardware used compared to the customer‟s environment
Low migration risk of moving from an HP-UX based physical environment to a Vblock platform virtualized
environment
Fast recovery of failed application and database server blades with UIM and Cisco UCS service profiles
Increased scalability to dynamically add resources
High availability and live migration demonstrated though vMotion
© 2011 VCE Company, LLC. All rights reserved. 35
References
VCE
Vblock™
Infrastructure Platform Architecture Overview
SAP
To read the SAP documentation on SAP Service Marketplace see the links below.
Note: To access this documentation SAP requires that you have registered and have a user id and password.
Contact SAP to set up your user id.
SAP documentation for Heterogeneous System Copy Guide:
System Copy for SAP Systems Based on NW 7.0 EHP1 ABAP+Java
SAP Installation Guides: Service.sap.com/instguides --> Installation & Upgrade Guides (left hand side menu) --> SAP Business Suite Applications --> SAP ERP 6.0 -->
© 2011 VCE Company, LLC. All rights reserved. 36
Appendix A
This appendix outlines the description and purpose of the individual test scenarios, and their results. See the
Test Results section of this paper for the summative data and discussions.
Test 1
Migrate and run SAP ECC, SCM & Live Cache successfully on Vblock platforms.
Test Description
Test 1a Using standard SAP OS/DB migration tools, the VCE team will migrate the SAP landscape from the source environment to the Vblock platform; transporting the data using an external NAS device or network.
Test 1b Deploy SAP Applications ECC and SCM using Adaptive Installation Best Practices; configure the systems to enable connectivity to a large semiconductor equipment manufacturing company‟s Adaptive Computing Controller.
Test 1c Apply SAP best practice recommendation for tuning for optimum performance.
Test 1d Demonstrate complete functionality of SAP ECC and SCM systems by logging into the systems and executing a few key Basis and sample business transactions.
Figure A.1. Using best practices, migrated SAP landscape and data, demonstrated
improvement running on Vblock platforms
© 2011 VCE Company, LLC. All rights reserved. 37
Figure A.2. Vblock platform shows high performance compared to HP-UX
Figure A.3. SAP transactions demonstrate complete functionality of SAP ECC and SCM systems.
© 2011 VCE Company, LLC. All rights reserved. 38
Test 2
Demonstrate performance of the SAP system on Vblock platforms meets or exceeds the current benchmarked performance
(KPIs). Using standard SAP OS/DB migration tools, the VCE team migrates the SAP landscape from the source environment to
the Vblock platforms, transporting the data using an external NAS device or network.
Figure A.4. Performance: P08 Workload analysis: 1200 Logged on Users; 150 Active Users
Figure A.5. KPI – CPU Performance
© 2011 VCE Company, LLC. All rights reserved. 39
Figure A.6. KPI – Memory Consumpton Performance
Figure A.7. KPI – Network Performance
© 2011 VCE Company, LLC. All rights reserved. 40
Test 3
Demonstrate highly available system meets or exceeds the current SLA and the availability of the current system.
Test Description
Test 3a The HA solution for the SAP systems database: SAP CI & DB HA with Red Hat Linux Cluster suite (Active, Active solution)
Test 3b The HA solution for the application servers: Multiple DIA and BGD instances on Virtual Machines distributed on separate ESX servers.
Figure A.8. Highly available system - LR Scenario: 1200 Total Users, 150 Active, Production Batch Load
© 2011 VCE Company, LLC. All rights reserved. 41
Test 4
Demonstrate „stateless‟ computing (hardware failure and recovery matches or exceeds existing system).
Demonstrate the provisioning of a UCS blade on the Vblock platforms using the service profile in case of a blade
failure.
Figure A.9. Rapid hardware recovery and blade provisioning
© 2011 VCE Company, LLC. All rights reserved. 42
ABOUT VCE
VCE, the Virtual Computing Environment Company formed by Cisco and EMC with investments from VMware and Intel,
accelerates the adoption of converged infrastructure and cloud-based computing models that dramatically reduce the
cost of IT while improving time to market for our customers. VCE, through the Vblock platform, delivers the industry's first
completely integrated IT offering with end-to-end vendor accountability. VCE's prepackaged solutions are available
through an extensive partner network, and cover horizontal applications, vertical industry offerings, and application
development environments, allowing customers to focus on business innovation instead of integrating, validating and
managing IT infrastructure.
For more information, go to www.vce.com.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." VCE MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OR MECHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright © 2011 VCE Company, LLC. All rights reserved. Vblock and the VCE logo are registered trademarks or trademarks of VCE Company, LLC. and/or its affiliates in the United States or other countries. All other trademarks used herein are the property of their respective owners.
top related