Best practices for deploying an SAP landscape using the c3000 Blade Enclosure and the EVA4400 (Windows/MS-SQL)

Transcription

1 Best practices for deploying an SAP landscape using the c3000 Blade Enclosure and the EVA4400 (Windows/MS-SQL) Overview Goals Solution configuration Overall solution configuration Blade enclosure configuration SAP production system application server SAP production system database server SAP test/qa system server SAP development system server Management server Active Directory domain controller and load generator (optional) Storage configuration Testing Test objectives Test setup Performance testing setup User load Performance testing setup Active data sizes Backup/restore setup Test results SAP system tuning SQL memory tuning Server performance Storage results Data protector functionality SAP backup/restore testing with Data Protector Monitoring database backup/restore from SAP Best practices and results SAP administrator Database administrator Storage administrator Backup/recovery (Data Protector) administrator Conclusion We value your feedback Appendix A Bill of Materials Appendix B Setting up and using Data Protector Data Protector installation Adding clients Adding devices Set up and use SQL Server backup Restore SQL Server

2 Set up and use file system backup Restore the file system For more information CFT SAP best practices white papers Data Protector information HP solutions and training

3 Overview Small-to-medium businesses (SMBs) companies with employees are projected to increase their IT spending at rates that are higher than the overall market. Most SMBs also intend to increase their ratio of new investments to overall IT spending. These trends reflect business growth initiatives. The most prevalent initiatives include deploying major new software applications and replacing or upgrading existing applications. To support these initiatives, SMBs will be seeking to upgrade or replace their servers and storage. Goals The goal of this project is to develop detailed best practices for deploying a 250-user/250-GB three-tiered SAP ERP landscape in an HP BladeSystem c3000 blade enclosure with HP ProLiant BL460c blade servers running Microsoft Windows Server 2003, an HP StorageWorks Enterprise Virtual Array (EVA) 4400 disk array, and an Ultrium 448c tape blade with HP Data Protector software. The goal is to provide best practices that can help accomplish the following: Accelerate thetimeand reduce theeffortto deploy Optimize performance Simplify operation Lower risks Minimize total costs This paper describes the test results, methods, and best practices derived from the testing, and it addresses the following fundamental deployment and operational issues: Best practices for configuring an entire three-tiered SAP landscape across the server blades, optimizing both performance and availability The appropriate configuration for the HP EVA disk array, including the following: Data fileplacement onto theeva virtualdisks (Vdisks) Configuring the disks into the appropriate number of EVA disk groups, including a comparison of the pros and cons of using one EVA disk group for all data versus isolating production data into its own disk group Choosing the appropriate number of disks Best practices for tuning the overall environment Best practices for backing up and restoring critical SAP data 3

4 Solution configuration Overall solution configuration This project tests an SAP ERP 2005 landscape, using MS SQL Server 2005 on Windows Server The SAP landscape runs on the ERP Central Component (ECC) 6.0, NetWeaver 7.0, and includes a development system, a test/quality assurance (test/qa) system, and a highly available production system. We test performance of these systems with an ERP workload using a 250 GB database and 250 users on the production system. Additional users are simulated on the test/qa and development systems. HP also tests SAP management and backup/recovery to tape with SAP Solution Manager 7.0 and HP Data Protector 6.0 respectively. The hardware includes an HP BladeSystem c3000 with an EVA4400 for backend storage. These components are connected through two Brocade 4-GB SAN switches for HP c-class BladeSystem. Figure 1 shows the logical configuration. Figure 1. Solution logical configuration Thepowerful, yetcompactnature ofthissetupallowsthe entire SAPlandscape to fiteasilyinside a 14U rack, an ideal configuration for small and medium-sized businesses. Figure 2 shows the SAP landscape in a 14U rack. 4

5 Figure 2. SAP landscape in a 14U rack Blade enclosure configuration The blade system includes a total of six BL460c servers. One is optional for this SAP landscape, serving only as the Active Directory domain controller and a load generator for testing. For the SAP production system, the configuration uses the Microsoft cluster service (MSCS) with two server nodes to provide increased server availability. The test/qa, development, and management systems each run on individual servers. Each server has two Intel Xeon GHz dual-core processors and has the following specifications: SAP production system application server 16 GB RAM SAP Central Instance (dedicated application server, except in the case of node failover) Node 1 of 2-node MSCS cluster SAP production system database server 16 GB RAM MS SQL Server (dedicated database server, except in the case of node failover) Node 2 of 2-node MSCS cluster SAP test/qa system server 16 GB RAM Test system s Central Instance and database server 5

6 SAP development system server 8 GB RAM Development system s Central Instance and database server Management server 8 GB RAM SAP Solution Manager 7.0 Command View EVA 8.0 Data Protector 6.00 Cell Manager Active Directory domain controller and load generator (optional) 8 GB RAM Active Directory domain controller, dynamic host configuration protocol (DHCP), and domain name server (DNS) Load generation The enclosure has an Ultrium 448c tape blade for backup. One to two free bays remain available for future growth (depending on whether the optional sixth server is used). Figure 3 shows the blade system layout in the enclosure. Figure 3. Blade enclosure setup Storage configuration The backend storageis composed of an EVA44002C2Dwith24146-GB15KRPMFibre Channel (FC) drives, which is tested in two different configurations: 6

7 Configuration 1 consists of a single disk group for all three SAP systems. Configuration 2 consists of two disk groups: one with 16 drives for the SAP production system (because that system consistently receives the heaviest workload and its performance is more critical than that of the other two systems), and a second disk group with the remaining eight drives that is shared by the SAP test/qa and development systems. Figure 4 illustrates these configurations. Figure 4. Array configuration For both array configurations, we use Vraid 5 for all virtual disks (Vdisks) except those that store database transaction logs, which use Vraid 1. Each SAP system has its own SQL database, and we use two database data files in each database (the default is three). Because the EVA has two controllers and the data files are accessed more heavily than most of the other files created by SAP, we useanevennumberof datafiles,with eachfileon its ownvdisk. Thisconfiguration allows the EVA to evenly load balance those Vdisks and their workloads across the controllers. 7

8 Best practice Use an even number of data files balanced across an even number of Vdisks to allow optimal controller load balancing in the EVA. Table 1 summarizes the components. For more information, see Appendix A Bill of Materials. Table 1. Component list Components Component type Description/use Servers BL460c with 2 dual-core CPUs, 16 GB RAM SAP production system central instance server BL460c with 2 dual-core CPUs, 16 GB RAM BL460c with 2 dual-core CPUs, 16 GB RAM BL460c with 2 dual-core CPUs, 8 GB RAM BL460c with 2 dual-core CPUs, 8 GB RAM BL460c with 2 dual-core CPUs, 8 GB RAM (optional) SAP production system database server SAP test/qa system server SAP development system server Management server (SAP Solution Manager 7.0, Command View EVA 8.0, Data Protector 6.00 Cell Manager) Active Directory domain controller (also running DHCP and DNS as needed) Tape blade HP Ultrium 448c tape blade Backup hardware HBAs HP BLc Emulex LPe GB FC (5) 1HBA perserver Switches GbE2c Ethernet Blade switch (2) Brocade 4/24 SAN switch (2) GigabitEthernetswitch Fibre channel switch EVA Software EVA44002C2Dwith24146 GB 15 KRPM Fibre Channel drives HP OpenView Data Protector Start Pack for Windows Backend storage Backup/recovery application 8

9 Testing Test objectives The testing goal is to determine the equipment capabilities and best practices for setting up the described SAP landscape. Specific goals include the following: Determine best practices for storage configuration. Determine best practices for placing a three-system SAP landscape in a c3000 blade enclosure. Verify best practices from previous CFT SAP white papers for current hardware. For more information, see Best practices for SAP ERP using HP Blade System c-class blades at and Best practices for configuring and deploying SAP ERP using HP ProLiant servers, HP StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server at Test Data Protector backup/recovery functionality for SAP. Test setup Four different scenarios are tested to attain the most accurate data possible. The variables defining the fourtestscenarios includethe storagearray configuration(onediskgroup or two) andthe active data set size (small or large). Performance testing setup User load Fortesting theperformance of thesap landscape, we useaseries of scriptstosimulateanerp workload for a given number of users and to generate the appropriate I/O load on the system. This project requires running tests for each system concurrently. HP cautions against running the test/qa and development systems during peak usage times of the production system. However, we do this to ensure that the environment can handle the unlikely situations in which you must heavily exercise all three systems simultaneously. The primary goal is to simulate 250 production-system users, with fewer users for each additional system. Table 2 shows the simulated load for each system. Table 2. Simulated-user load System Production system Test/QA system Development system Total Users 250 users 200 users (80% of production system load) 100 users (40% of production system load) 550 simultaneous users running in the SAP landscape for each test Performance testing setup Active data sizes When analyzing performance data, keep the amount of data in the database in mind. The more data, the more total distance the drive heads may be required to move when retrieving and writing data to the disk, which means greater disk latency. 9

10 To understand how the array performs with such variations, two different active data capacities in the database are tested. This reveals difference in performance between a young, sparsely populated database and a database with large amounts of data. Similar to the user load, the active data sizes are scaled down for the test/qa and development systems. Table 3 shows the active data sets. Table 3. Active data sets Data set System Capacity Total used capacity Small data set Production system 40 GB (per data file) x 2 data files = 80 GB 150 GB Note This simulates a production system database with a 250 GB capacity that is 30% full. Test/QA system Development system 20GBx2datafiles =40GB 15 GB x2datafiles =30GB Large data set Production system 95 GB x 2 data files = 190 GB 350 GB Note This simulates a production system database with a 250 GB capacity that is 75% full. Test/QA system Development system 50 GB x 2 data files = 100 GB 30 GB x 2 data files = 60 GB Backup/restore setup We use Data Protector 6.0 to back up the SAP production system to tape through the Ultrium 448c tape blade in the c3000 enclosure. Note All three SAP systems can be backed up with Data Protector; however, we focused testing on only the production system. Data Protector contains an SAP backup agent. However, the agent component uses the SAP backup tools (BR tools) which are only available when Oracle is the underlying database. When SAP uses a database other than Oracle, the backup components for that specific database must be used along with file system backups. Therefore, we use the SQL Server and file system backup components to perform our SAP backups. For more information on the actual setup and use of Data Protector, see Appendix B Setting up and using Data Protector 6.0. Test results SAP system tuning These testing results verify best practices presented in Best practices for SAP ERP using HP Blade System c-class blades at 10

11 and Best practices for configuring and deploying SAP ERP using HP ProLiant servers, HP StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server at Before testing the SAP landscape, we run a few baseline tests and observe the swaps occurring in the production system (using SAP transaction ST02). To obtain improved performance, we then tune the SAP system according to the best practices documented in previous white papers by CFT SAP engineers. According to these white papers, SAP default values provide a very limited capacity for several memory buffers. Therefore, we tune the memory buffers using SAP transaction RZ10 and adjust the system to use the buffer values recommended in the white papers: abap/buffersize = 500,000 zcsa/db_max_buftab = 80,000 zcsa/table_buffer_area = 120,000,000 rsdb/obj/max_objects = 40,000 rsdb/obj/buffersize = 81,920 rdisp/roll_shm = 32,768 rdisp/roll_maxfs = 32,768 rdisp/pg_shm = 16,384 em/initial_size_mb = 10,000 Note These values were adjusted to eliminate SAP swapping for the current workload. Because each environment is different, tune each system in your environment based on the amount of memory given to SAP and according to the recommendations in the referenced white papers. Previous testing indicates that the default number of the Dialog, Update1, and Update2 work processes rarely equal the recommended number. Testing also indicates that it is beneficial to have five work processes per CPU core. Accordingly, we adjust the SAP systems to 20 work processes each (five work processes for each of the four CPU cores in each server). Adjusting the number of work processes involves using transaction RZ10 and changing the following parameters: rdisp/wp_no_dia (Dialog Work Process) rdisp/wp_no_vb (Update Work Process 1) rdisp/wp_no_vb2 (Update Work Process 2) The following is a good balance for the work processes of servers with two dual core processors: 17 Dialog processes 2 Update1 processes 1 Update2 process 11

12 When tuning an SAP system, tune each profile in the system (not just the default profile). Also, be sure to tune each system in the SAP landscape independently, according to the number of processor cores the system has. After tuning the memory buffers and work processes, we repeat the baseline tests and observe that all SAP swapping has ceased. Figure 5 shows the Swaps column of transaction ST02. Figure 5. SAP page swapping In addition to eliminating SAP swaps, system response times decreased by up to 5 ms, depending on the system and workload applied. While this improvement is relatively small for the workload, other environments and workloads may benefit greatly from these adjustments. These results verify the best practices presented in the previous CFT SAP white papers. Best practice To eliminate SAP swaps, tune the memory buffer according to the suggestions in Best practices for SAP ERP using HP Blade System c-class blades at and Best practices for configuring and deploying SAP ERP using HP ProLiant servers, HP StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server at 12

13 Best practice For better system performance, tune the number of SAP work processes to five per CPU core. For more information, see Best practices for SAP ERP using HP Blade System c-class blades at downloads/4aa1-5661enw.pdf and Best practices for configuring and deploying SAP ERP using HP ProLiant servers, HP StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server at SQL memory tuning Testing reveals that the dedicated database server for the production system uses less than half of the memory available on that Windows server. This reduction is caused by default settings of that SQL Server and limits the amount of data SQL Server can cache. To adjust the memory allocated to SQL Server use the following steps: 1. Start the SQL Server Management Studio and connect to the database. 2. Right-click the name of the SQL Server and select Properties. Figure 6 shows the SQL Server properties. Figure 6. SQL Server Management Studio: SQL Server properties 3. In the Server Properties window, select Memory. 4. Adjust the Minimum server and Maximum server memory values according to your system s available memory. Figure 7 shows the SQL Server memory settings. 13

14 Figure 7. Modifying SQL Server memory Best practice If using a dedicated database server, allocate all available memory except for approximately 2 GB RAM (for the operating system) to SQL Server. Doing so provides more capacity in SQL Server s cache. Server performance With SAP tuned appropriately, tests of the environment with all 550 concurrent users (250 production users and 300 users of the test/qa and development systems) reveal that the servers are fully capable of handling the user load. On the production system, average processor utilization for the application server ranges between 35% and 40%, with even lower usage of the database server processors. For scale-up testing, we double the production system workload to about 500 users on the production system alone and find its processors are still able to handle the load, running at about 70% utilization on the application server. SAP uses CPU core zero more than the other cores on each application server. During this scale-up, core zero is used at about 80%. Pay close attention to core zero because its saturation could quickly cause increased SAP system response time. This is because the SAP dispatcher does not evenly dispatch the work to all available work processes. 14

15 Best practice Be sure to monitor core zero on application servers. Saturating core zero will greatly increase response times in the system. Storage results Two array configurations are tested: Single disk group Two disk groups with the production system in its own group of 16 drives For each array configuration, two active data set sizes are tested: Small data set: 150 GB Large data set: 350 GB The production system has the highest priority in an SAP environment because of its direct impact on business data availability. To maintain a responsive production system, we target 20 ms or less for EVA disk latency. With a single disk group and a small set of active data, the production system performs well at 18 ms. However, when the database has more data, the production system disk latency degrades to 22 ms. Figure 8 shows the EVA latencies for a single disk group. Figure 8. Single disk group: EVA latencies (ms) per SAP system An analysis of the two-disk configuration (16 disks for the production system and eight disks for the test/qa and development systems), reveals that the production system (the most critical system) performs well (less than 15 ms) despite the heavy load on the other two systems. Figure 9 shows the EVA latencies for two disk groups. 15

16 Figure 9. Two disk groups: EVA latencies (ms) per SAP system Initially, the test/qa system performance looks unacceptable; however, this is a worst-case scenario. Remember that in this configuration, the test/qa system is running a workload with only slightly fewer users than that of the production system. It also has only eight disks and is sharing them with the development system, causing more I/O requests per disk for that disk group and, as expected, higher latencies in that disk group. However, we have verified that the production system performs well even with all three systems simultaneously running a heavy load. HP does not recommend that you run strenuous workloads on your test/qa and development systems during peak hours of use of the production system. However, by using two disk groups, the environment is fully capable of doing so. In fact, using two disk groups for this landscape improves production system performance by up to 40% (13 ms versus 22 ms in a single disk group). Best practice Place the SAP production system in its own disk group to prevent any impact from simultaneous workloads generated by the test/qa or development systems. Doing so can reduce production system latencies by up to 40%. Further analysis of the EVA finds that its CPU use is approximately 30%, and I/O requests have begun to queue up on the disks. From this we conclude that the number of spindles is the bottleneck; therefore, disk latency will decrease and IOPS will increase when drives are added to the EVA. Best practice Add disks to the EVA to decrease response times and increase the array s ability to handle more IOPS. Data protector functionality Keeping frequent backups of an SAP system is critical to maintaining the landscape. To back up your SAP system, back up both the full database and critical parts of the file system, such as the SAP 16

17 profiles or other configuration files. As explained in Backup/Restore Setup, the Data Protector SAP backup component is used only when Oracle is the underlying database, so you must use the SQL Server and file system Data Protector components. For information on deploying and using Data Protector in this environment, see Appendix B Setting up and using Data Protector 6.0. Data Protector enables you to create full, differential, or transaction log backups of your SQL Server databases. Regularly creating full backups is important to any SAP environment and should be complemented with differential and transaction log backups. After restoring from full or differential backups, the database is in the same state as at the time of the backup. However, when restoring from a transaction log backup, Data Protector enables you to choose a very specific point in time from which to restore data. Best practice Use Data Protector to perform periodic full backups and more frequent differential backups, depending on how critical your SAP environment is to your business. If time-specific restoration capability is necessary, complement full and differential backups with transaction log backups. Note To keep data consistent when performing a SQL Server database restoration, the database cannot be in use by any other source. Therefore, the SAP system using that database must be shut down before you can restore the data. Data Protector also enables you to back up entire volumes, folders, or even individual files from a file system. Likewise, when restoring data to a file system, you can choose to restore individual files, folders, or entire volumes. This functionality enables you to back up only the critical SAP profile and configuration files and to save time and tape capacity. Frequent backups of the database is critical. File system backups are also important, but they do not need to be performed as often because profile and configuration data does not change as much or as frequently as the data in the database. Best practice Keep a full backup of initial SAP profiles and configuration files, using Data Protector s file system backup utility. Maintain periodic backups of critical SAP files and create a new backup after any major SAP profile or configuration changes. By creating and scheduling backup jobs (for both the database and file system), you can automate and simplify your backup procedure. Best practice Create a consistent backup schedule and use Data Protector s scheduling utility to manage your backups. Periodically verify that these scheduled backups are completing successfully and are not hindered by worn-out media or other issues. Data Protector has several other useful features that make it a powerful utility. These include the following: Backup media auto-detection: Data Protector automatically recognizes tape blades and other backup media. 17

18 Backup media pooling: If multiple sources of backup media are available (for example, if a second tape blade were in the enclosure), Data Protector allows you to create pools of media to increase performance of backup/recovery by writing to several locations simultaneously. Backup file protection: Data Protector protects backup files until a specified time, preventing you from accidentally overwriting needed backup data. Media quality assurance: Data Protector shows the age of backup media (such as a tape cartridge), its current capacity, and how many times the data has been overwritten. Data Protector assigns a lower quality value to older media that has been used extensively. When the media reaches a certain quality threshold, Data Protector stops backups to that media to prevent data loss. Figure 10. Data Protector: media capacity Predefined pre- and post-script execution: During backup setup, you can specify your own scripts to run immediately before or after a backup. For more information about features, see Appendix B Setting up and using Data Protector 6.0. SAP backup/restore testing with Data Protector Testing SAP backup and recovery with Data Protector is composed of the following steps: Perform several online SQL backups of each type (full, differential, and transaction log) with database changes between each backup. 18

19 Perform several online file system backups of the volumes with the SAP profiles and configuration files. Make changes and deletions to the database and file system. In some tests, delete some of the database data files (after shutting down SAP) and then shut down SAP to verify the ability to restore both the database and file system files. Then bring SAP back online and verify successful data restoration. Note HP does not recommend deleting data files from your database to test backup/recovery. This is a high-risk activity that was tested in this project to verify successful data restoration. Best practice Periodically restore some test data using Data Protector to verify that no hardware or other issues exist and that your data restoration process is fully functional. For steps on how to deploy and use Data Protector in its environment, see Appendix B Setting up and using Data Protector 6.0. Monitoring database backup/restore from SAP SAP provides several tools for SAP and DB administrators. One of these tools is a DBA planning calendar, from which you can track completed and scheduled tasks. This can greatly aid planning of the backup strategy. Using the calendar is especially useful if the database administrator and SAP administrator are different people, and the SAP administrator does not have access to Data Protector. These tools can be used cooperatively to ensure the system remains sufficiently backed up. Figure 11 shows the SAP DBA planning calendar. 19

20 Figure 11. SAP DBA planning calendar (transaction DB13) With SAP, you can monitor the completed database backups and restores using transaction DB12. This transaction provides links for viewing media statistics, such as which tapes are needed for data restoration. Figure 12 shows SAP backup and restore information. 20

21 Figure 12. SAP backup and restore information (transaction DB12) The screen shown in Figure 13 and several other screens with useful statistics and settings can be accessed through transaction ST04. This transaction provides several valuable links and pieces of information through the Detail analysis menu and the DB Collector buttons. 21

22 Figure 13. SAP database performance analyzer (transaction ST04) SAP and Data Protector both provide many details about the backups in your system. For SAP administrators, especially those without direct access to Data Protector or the database, using these transactions simplifies tracking database backups. Best practice Use SAP transactions DB12, DB13, and ST04 to monitor all backup/restore activity for the database SAP is using. 22

23 Best practices and results SAP administrator To eliminate SAP swaps, use suggestions for the memory buffer tuning cited in Best practices for SAP ERP using HP Blade System c-class blades at downloads/4aa1-5661enw.pdf and Best practices for configuring and deploying SAP ERP using HP ProLiant servers, HP StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server at For increased system performance, tune the number of SAP work processes to five per CPU core, as explained in Best practices for SAP ERP using HP Blade System c-class blades at and Best practices for configuring and deploying SAP ERP using HP ProLiant servers, HP StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server at Use SAP transactions DB12, DB13, and ST04 to monitor all backup/restore activity for the database SAP is using. Be sure to monitor core zero on application servers. Saturating core zero will greatly increase response times in the system. Database administrator If using a dedicated database server, allocate all available memory except for approximately 2 GB RAM (for the operating system) to SQL Server to provide more capacity in SQL Server s cache. Storage administrator Place the SAP production system in its own disk group to prevent impact from simultaneous workloads generated by the test/qa or development systems. This configuration can reduce production system latencies by up to 40%. Add disks to the EVA to decrease response times and increase the array s ability to handle more IOPS. Use an even number of data files, placing each on its own Vdisk to allow optimal controller load balancing in the EVA. Backup/recovery (Data Protector) administrator Use Data Protector to perform periodic full backups and more frequent differential backups, depending how critical your SAP environment is to your business. If time-specific restoration capability is necessary, complement full and differential backups with transaction log backups. Keep a full backup of initial SAP profiles and configuration files, using Data Protector s file system backup utility. Maintain periodic backups of critical SAP files and create a new backup after any major SAP profile or configuration changes. 23

24 Create a consistent backup schedule and use Data Protector s scheduling utility to manage your backups. Periodically verify that these scheduled backups are completing successfully and are not hindered by worn-out media or other issues. Periodically restore some test data, using Data Protector, to verify that no hardware or other issues exist and that your data restoration process is fully functional. 24

25 Conclusion The test results and related information in this paper demonstrate how to properly plan for, successfully deploy, and productively use a fully operational three-tiered SAP NetWeaver landscape on an HP server/storage infrastructure. Key planning considerations include the following: When selecting and configuring the servers, use dedicated blades for each function in the landscape. When configuring the disk array, use two disk groups, with the production system in a disk group with 16 drives, and test and development systems sharing an eight-drive disk group. This provides up to a 40% improvement in production system response time. Increasing the workloads in SAP systems tends to cause high disk queue depths and latencies. The best practice is to increase the number of spindles by adding disks to the array to increase overall IOPS and decrease response times. When deploying HP Data Protector, acquire the latest patches, determine the best system to be the cell manager, and perform the installation. Key software tuning considerations include the following: Tune the SAP buffers until no swaps (that is, no paging to disks) are observed. Configure the appropriate number of SAP work processes. Testing confirmed earlier results that using a ratio for SAP work processes to CPU cores of 5:1 is optimal. Configure the dedicated database server. Some memory might not be used unless specifically allocated for SQL Server. To efficiently use memory in a dedicated database server, adjust the memory given to the database to consume available memory (memory not needed for the OS). This allows SQL Server to cache more data and spend less time going to the disk. Key operating considerations include the following: When using Data Protector for backup of MS SQL data in SAP environments, the database and file system are backed up separately. While it is both possible and a best practice to back up while running, SAP must be shut down when restoring data to ensure integrity of the restored data. Key backup considerations include the following: Use a variety of database and file system backups to ensure your data is secure. Maintain a consistent backup schedule with Data Protector to minimize potential impact to the environment in case of data loss. Periodically restore test data to verify that data restoration is functioning as expected. A good understanding of these major considerations and the procedures associated with them are key to successfully deploying and operating a three-tiered SAP NetWeaver landscape using HP servers, storage, and enterprise management. The test-proven techniques developed here serve as a complete guide that can be used with confidence to ensure success. 25

26 We value your feedback To develop technical materials that address your information needs, we need your feedback. We appreciate your time and value your opinion. The following link will take you to a short eight-question survey regarding the quality of this paper: 26

27 Appendix A Bill of Materials Quantity Part Number Description c3000 Blade Enclosure B21 HP BLc3000 CTO Enclosure B21 HP BL460c G1 Dvlss CTO Blade L21 HP X5160 BL460c G1 FIO Kit B21 HP X5160 BL460c/xw460c G1 Kit B21 HP 8GB FBD PC x4GB Kit B21 HP HDD Bkpln BL460c FIO Kit B21 HP 146GB 10K SAS 2.5 DP HDD B21 HP BLc NC373m Mfn Gigabit Svr Adapter B21 HP BLc Emulex LPe1105 FC HBA Opt Kit B21 HP SA 641/642/E MB BBWC Kit B21 HP Ultrium 448c Tape Blade B21 HP BLc Bnt 1GbE2 Switch Opt Kit 2 AE371A Brocade BladeSystem 4/24 SAN Swt Powr Pk B21 HP BLc3000 FIO Onboard Admin Option EVA AG637A HP EVA4400 Dual Controller Enclosure 4 AG638A HP M6412 Fibre Channel Drive Enclosure 24 AG556A HP 146GB 15K FC EVA M6412 Enc HDD Applications 1 B6961AA HP OpenView Data Protector Start Pack for Windows 27

28 Appendix B Setting up and using Data Protector 6.0 This section details how to configure and use Data Protector. Data Protector installation 1. On the Cell Manager server, start the Data Protector installation and accept the license agreement. 2. Select Cell Manager as the Installation type. Figure 14 shows the installation type. Figure 14. Data Protector installation type 3. Enter the appropriate username and password. 4. Select the installation path. 5. Select the components you want to install on the Cell Manager and click Next. For testing, we use the default settings. Figure 15 shows the component selection screen. 28

29 Figure 15. Data Protector Cell Manager component installation 6. Download and install on Cell Manager all necessary Data Protector patches from the patch download site at DriverDownload.jsp?prodNameId= &lang=en&cc=us&taskId=135&prodClassId= 1&prodTypeId=18964&prodSeriesId= Start the Data Protector GUI. Adding clients 1. Select Add New Clients from the pop-up window. 2. Right-click Clients in the scoping pane (the tree menu on the left part of the window), and select Add Clients. Figure 16 shows how to add clients. 29

30 Figure 16. Adding clients 3. Browse to each of the servers you need, including the virtual name for the SQL Server (not just the physical box that it is on) and click Add. When added, the servers are listed under Client Systems. Figure 17 shows how to add servers. 30

31 Figure 17. Added servers 4. Click Next and select the components to be installed on all of your servers, or click I wantto customize these options for client systems independently (below the component list). Figure 18 shows how to customize client systems. Figure 19 shows how to install specific components on each server. 31

32 Figure 18. Customize options for client systems Figure 19. Adding server components 32

33 HP customizes components for each server. Table 4 shows the installed modules. If you choose to customize servers, keep the following information in mind: The modules specific to SAP integration are not used for MS SQL Server, so do not include those. Table 4. Modules installed Installed modules Functions Location Disk Agent For each system involved in data backup Every server Media Agent User interface MS SQL 7.0/2000 Integration For the server in the same enclosure quadrant as the tape blade or that is connected to other necessary backup media For the server used for managing Data Protector Forall serversacting assql clients or servers Management server, because it is in the same quadrant as the tape blade Management server with Solution Manager, Command View, and Data Protector Cell Manager Both servers in the production system and the test/qa and development servers Figure 20 lists the Data Protector server components. Figure 20. Data Protector server components Adding devices 1. Select Devices & Media from the context list. 2. In the scoping pane, under Environment, right-click Devices and select Autoconfigure Devices. Figure 21 shows how to set automatic configuring of devices and media. 33

34 Figure 21. Automatically configuring devices and media 3. Select the client server with access to the backup device. 4. Select the device found (in this case, HP:Ultrium 2-SCSI) and click Finish. Figure 22 shows how to add devices. 34

35 Figure 22. Adding devices 5. Expand Media in the scoping pane. 6. If the devices do not appear, right-click Pools and select Add Media Pool. 7. Provide a pool name, select the media type (we selected LTO-Ultrium), and finish creating the pool. 8. Right-click on the media pool you created and select Format. Figure 23 shows how to format media. 35

36 Figure 23. Formatting media 9. Select thedeviceto format and click Next. 10. Provide a name for the media and click Next. 11. If the media has been used before, you may need to click the Force operation check box. Click Finish. Figure 24 shows where to select Force operation. 36

37 Figure 24. Force operation Your system is now ready to create backups. Set up and use SQL Server backup 1. Select Backup from the context list. 2. Expand Templates, right-click MS SQL Server, and select Add Template. 3. Select the backup device, make sure Load Balancing is not selected, and click Properties. If you have only one backup device, load balancing will have no effect regardless of the selection. For a small SAP landscape similar to that used in this project, HP does not recommend using load balancing unless you are using multiple device streaming. This is because you may wish to explicitly select where backup objects are stored, and because you will likely be backing up only a few items. For more information about device lists and load balancing, see the HP OpenView Storage Data Protector Concepts Guide at SupportManual/c /c pdf. 37

38 Figure 25. Creating a backup template 4. From the Device Properties window, select the media pool you wish to use and click OK. 5. Click Next, set any other optional changes, and then click Next. (Default settings were used in testing.) 6. Setupaschedule (optional) and click Next to save the template. 7. Create a backup specification by expanding Backup Specification. Figure 26 shows how to select databases. 8. Right-click MS SQL Server and select Add Backup. 9. Select the backup template you just created. 10. Select Local or network backup, clear Load balanced, and click OK. 11. Under the Application section, and from the Client menu, select the name of the SQL Server (not the physical server that the database resides on, but the name of the virtual server managing your database). Click Next to continue. 12. If an authentication window pops up, use Integrated Security if using a domain account with access to the database, or select Standard Security to use a database user. 13. Select the databases you wish to back up, and then click Next. 38

39 Figure 26. Selecting databases to back up 14. Make selections on subsequent screens, as you did when setting up the template. 15. Save the backup specification. You are now ready to back up your database. 16. Right-clickthe backupyou just createdinthe scopingpane, andclick Start Backup. 17. Select the backup type to create and click OK. Note Differential and transaction log backups are an option only if a full backup already exists. Restore SQL Server Note To maintain data consistency in the database, SQL Server requires that there be no active connections to the database. Therefore, before restoring your data, you must shut down all SAP instances with connections to that database. 1. Select Restore from the context list. 2. Expand the MS SQL Server list to display the backed-up databases. 3. Select the components to restore. For simple SAP system restorations, select only your primary system database. Figure 27 shows where to select components to restore. 4. Right-click the name of the database and click Properties. 39

40 Figure 27. Restoring SQL database files 5. Select the backup version you wish to restore from and click OK. If you select a transaction log backup, you can restore to a specific point in time. Figure 28 shows where to select a backup version. 40

41 Figure 28. Selecting a backup version 6. Click Restore to start restoring your database. Set up and use file system backup 1. Select Backup from the context list and expand Templates. Figure 29 shows where to select thefilesystembackupfile. 2. Right-click Filesystem and select Add Template. 3. Select the backup device, clear Load balancing, and click Properties. 4. Select themedia pool to useand click OK. 5. Click Next and give the backup a description. 6. Select the protection level, apply a filter (optional), and then click Next. 7. Set up a schedule if necessary, and save the template. 8. Expand Backup Specifications, right-click Filesystem, and click Add Backup. 9. Select the template you created, clear Load Balanced, and then click OK. 41

42 10. Select what to back up and then click Next. You can select volumes, folders, and files. Figure 29. File system backup file selection 11. Select the appropriate backup device and media pool, and then click Next. 12. Continue clicking Next to usedefault settings andsavethe backup. 13. In the scoping pane, expand Filesystem and select the backup specification you created to make changes, or right-click the backup and select Start Backup. 14. Select the backup type and start the backup. Note A full backup must exist before incremental backups can be created. Restore the file system 1. Select Restore from the context list. Figure 30 shows the file system restore feature. 2. Expand Backup Specifications and Filesystem. 3. Select the backup specification from the scoping pane, and then select the volumes, folders, or files you wish to restore. 4. Right click a volume and select Restore Version. 42

43 Figure 30. File system restore 5. Select thefilesystembackupversion to restoreand click OK. 6. Click Restore. 43

44 For more information CFT SAP best practices white papers Best practices for SAP ERP using HP Blade System c-class blades Best practices for configuring and deploying SAP ERP using HP ProLiant servers, HP StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server Data Protector information Patch download site NameId= &lang=en&cc=us&taskId=135&prodClassId=-1&prodTypeId=18964&prod SeriesId= Data protector manuals/guides site portmanual&lang=en&cc=us&docindexid=64179&taskid=135&prodtypeid=18964&prod SeriesId= HP OpenView Storage Data Protector Concepts Guide c pdf HP solutions and training Customer Focused Testing solutions Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. SAP, SAP NetWeaver, SAP Solution Manager, SAP ERP, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Microsoft and Windows are U.S. registered trademark of Microsoft Corporation. Intel and Intel Xeon are trademarks of Intel Corporation in the U.S. and other countries. 4AA1-7725ENW, October