advertisement
1
Backup and Recovery Strategies for SAP
Systems Using the Hitachi Virtual Storage
Platform
Implementation Guide
By Dhiren Patel
October 2010
Month Year
Feedback
Hitachi Data Systems welcomes your feedback. Please share your thoughts by sending an email message to [email protected]
. Be sure to include the title of this white paper in your email message.
1
Table of Contents
Appendix A — Tested Deployment Configuration, Parameter and Script Files for Replicating an
2
3
Backup and Recovery Strategies for SAP
Systems Using the Hitachi Virtual Storage
Platform
Implementation Guide
Most SAP customers rely on their IT environments to be available 24 hours a day, seven days a week.
They cannot tolerate any process that might have a negative effect on the production instance’s performance or availability. Given the critical nature of SAP deployments, it is important to have a secondary copy of the production landscape’s data available for a variety of processes.
One of the most powerful capabilities within an advanced storage infrastructure is the ability to create multiple copies of data with no negative effect on the production instance. These copies are used for a variety of purposes: backup, data mining, test environments and others. Although this capability is extremely powerful, it can also be one of the most complex storage administration tasks.
The solution described in this white paper uses the Hitachi Virtual Storage Platform and Hitachi
ShadowImage
®
In-System Replication software to replicate an SAP ERP production instance and prepare the copy for access by a secondary server to take backups of the SAP ERP production instance using Symantec NetBackup. It provides step-by-step instructions for preparing the environment for off-host backups and restores.
The Hitachi Virtual Storage Platform can help you leverage your information, which is the new currency in today’s data-driven economy. Information, which exists in many forms, must be protected and readily accessible to ensure business survival and success. The Virtual Storage Platform maximizes cost efficiency and return on investment by creating an agile storage infrastructure that reduces costs and increases performance, availability, scalability and reliability.
The Hitachi Virtual Storage Platform is the industry’s only 3D scaling storage platform. With the unique ability to concurrently scale up, scale out and scale deep in a single storage system, the Virtual Storage
Platform flexibly adapts for performance, capacity, connectivity and virtualization. No other enterprise storage platform can dynamically scale in three dimensions. Scaling up allows you to increase virtual server consolidation, improve utilization of resources, and reduce costs. Scaling out is required when you add new physical or virtual servers to your environment to meet business demands. Scaling deep extends the advanced functions of the Virtual Storage Platform to external multivendor storage.
This white paper describes how to implement this solution. It is written for IT professionals who are charged with storage or SAP system deployment or administration. It assumes basic knowledge of SAN concepts and operating practices.
4
Solution Overview
This white paper describes a solution that includes SAP clients that access the SAP application and database tiers. These tiers in turn store data in and access data from a Hitachi Virtual Storage Platform storage system, as illustrated by Figure 1.
Figure 1
Hitachi Virtual Storage Platform
The Hitachi Virtual Storage Platform is the industry’s only 3D scaling storage platform. With the unique ability to concurrently scale up, scale out and scale deep in a single storage system, the new Virtual
Storage Platform flexibly adapts for performance, capacity, connectivity and virtualization. No other enterprise storage platform can dynamically scale in three dimensions. The Virtual Storage Platform provides virtual storage that meets the growing demands of server virtualization.
The trend in server virtualization is to consolidate the I/O workload of many servers onto a single storage system. As more virtual machines are consolidated onto a physical host, storage systems must be able to dynamically add more storage resources to keep up with I/O demand. The 3D scaling capability of the Virtual Storage Platform meets that requirement.
Scaling up allows you to increase virtual server consolidation, improve utilization of resources, and reduce costs. With the Hitachi Virtual Storage Platform, you can increase performance, capacity and connectivity by adding cache, processors, connections and disks to the base system. A virtual server that accesses the storage system can use all these resources, which act as one system managed as a common pool of resources.
5
Scaling out allows you to meet increasing demands by combining multiple chassis into a single logical system with shared resources. By scaling out you can support increased resource needs in virtualized server environments.
Scaling deep extends the advanced functions of the Virtual Storage Platform to external multivendor storage. By dynamically virtualizing new and existing storage systems, those systems become part of the Virtual Storage Platform’s pool of storage resources. Once virtualized, external data can then be migrated, tiered, replicated and managed by the Virtual Storage Platform. In this manner, older data storage systems can gain a longer useful life. You can extend distance replication for business continuity to lower-cost, lower-function storage systems by virtualizing them behind a Virtual Storage
Platform.
The switch matrix architecture of the Virtual Storage Platform makes all of this possible. It connects the basic components, front-end directors, back-end directors, global cache modules and virtual storage directors. You can add redundant pairs of directors and cache modules as required without disruption to connected host servers. All these resources are tightly coupled through a global cache that creates a common pool of storage resources. These resources can include external storage that is connected through front-end director initiator ports.
Hitachi Adaptable Modular Storage 2100
As the first midrange products to offer a serial attached SCSI (SAS) architecture and the Hitachi
Dynamic Load Balancing Controller, the Hitachi Adaptable Modular Storage 2000 family delivers highly resilient, enterprise-quality storage in an affordable and easy-to-manage modular package
Although Hitachi Data Systems used an Adaptable Modular Storage 2100 to test this solution, any member of the Hitachi Adaptable Modular Storage 2000 family can be used to implement it.
Software
The following sections describe the key software components used in this solution.
Hitachi ShadowImage In-System Replication Software
Hitachi ShadowImage In-system replication software is a storage-based hardware solution that creates
RAID-protected duplicate volumes within the Hitachi Virtual Storage Platform family. ShadowImage primary volumes (P-VOLs) contain the original data and up to nine secondary volumes (S-VOLs) can be created as copies.
ShadowImage software’s non-disruptive operations allow the primary volumes to remain online to all hosts for read and write I/O operations.
The functions of ShadowImage are made available through Hitachi Storage Navigator Software graphical interface (GUI) and Hitachi Command Control Interface (CCI).
6
Hitachi Dynamic Provisioning Software
Hitachi Dynamic Provisioning software provides features that provide virtual storage capacity to eliminate application service interruptions, reduce costs, and simplify administration, as follows:
Optimizes or “right-sizes” storage performance and capacity based on business or application requirements.
Supports deferring storage capacity upgrades to align with actual business usage.
Simplifies and adds agility to the storage administration process.
Improves performance
Hitachi Storage Navigator Software
Hitachi Storage Navigator software is the integrated interface for the Virtual Storage Platform family firmware and software features. Use it to take advantage of all of the Virtual Storage Platform’s features. Storage Navigator software provides a Web-accessible graphical management interface.
Storage Navigator software is used to map security levels for SAN ports and virtual ports and for intersystem path mapping. It is used for logical unit (LU) creation and expansion, and for online volume migrations. It also configures and manages Hitachi Replication products. It enables online microcode updates and other system maintenance functions and contains tools for SNMP integration with enterprise management systems.
Hitachi Dynamic Link Manager Advanced Software
Hitachi Dynamic Link Manager Advanced software bundles Hitachi Dynamic Link Manager I/O multipathing software and Hitachi Global Link Manager software. Hitachi Dynamic Link Manager software, which is installed on the SAP ERP and SAP Solution Manager servers, includes capabilities such as path failover and failback and automatic load balancing to provide higher data availability and accessibility.
Install Hitachi Dynamic Link Manager Advanced software on the SAP ERP server, the SAP Solution
Manager server, and the backup server.
SAP Software
SAP ERP combines scalable and effective software for enterprise resource planning (ERP) with a flexible, open technology platform that can leverage and integrate SAP and non-SAP systems. This industry leading solution provides end-to-end software functionality for enterprise management and support by controlling and processing business related company processes.
SAP Solution Manager is a service and support platform that provides the integrated content, tools and methodologies to implement, support and monitor operations of SAP implementations. Solution
Manager is installed on a separate system.
SAP GUI is the client software that allows SAP users to access various functionalities in SAP applications and SAP Solution Manager.
SAP BRBackup is a backup and recovery tool specifically for Oracle databases. The flexibility of SAP
BRBackup allows users to take variety of backups such as online backups, offline backups, tape backups, split mirror backup etc.
7
SAP systems can be used with a variety of databases available from different vendors. The business transactions in SAP systems are processing units grouped to provide specific functions; these processing units execute changes to the database that are consistent. Oracle is the industry leader in providing state-of-the-art high performance database management system. Oracle has several technological features embedded in the database software that provide flexibility and manageability.
Some of these features cover backup and recovery, cloning of database etc.
Symantec NetBackup
Symantec NetBackup is a backup and recovery package for enterprise environments. It requires the following roles:
Master server — Manages backups, archives and restores. The master server is responsible for media and device selection for NetBackup. Typically, the master server contains the NetBackup catalog. The catalog contains the internal databases that contain information about NetBackup backup jobs
Media server — Provides access to additional storage by allowing NetBackup to use the storage devices that are attached to them. The use of multiple media server may also increase performance by distributing the network load.
Clients — Systems with data that must be protected. Regardless of how the data is being protected, the client is where the data originally resides. Some options blur the line of client and media server; however, from the NetBackup standpoint, when a media server is sending its own data to a device for backup, it is considered a client.
Tested Solution Components
In the tested deployment, the client tier consisted of Windows-based servers with the SAP GUI and
NetBackup Administration Console installed. The clients connected to the SAP application tier via a
Cisco Catalyst 4500 switch. SAP Solution Manager and the SAP application and database are installed on separate servers. In addition, another physical server, which this document calls the backup server, hosted the following roles:
NetBackup master server
NetBackup media server
SAP ERP off-host backup server
In the tested deployment, all servers were connected to a Hitachi Virtual Storage Platform via a
Brocade 48000 director. The Hitachi Adaptable Modular Storage 2100 is connected to the Hitachi
Virtual Storage Platform as an external storage device.
8
Hardware Components
Table 1 describes the hardware used to test this solution in the Hitachi Data Systems lab.
Table 1. Tested Deployment Hardware
Hardware
Hitachi Virtual
Storage Platform storage system
Hitachi Adaptable
Modular 2100 storage system
Brocade 48000 SAN
Fibre Channel switch
Dell Power Edge
R905 server
Dell Power Edge
R905 server
Dell Power Edge
R905 server
Dell PowerEdge 750
Dell PowerEdge 750
Quantity Configuration
1 8 Fibre Channel ports used
2 pair of front-end directors
2 pair of back-end directors
64 x 300GB 10K RPM SAS drives
64GB cache
14GB shared memory
1 Firmware version 0883/A-S
2 storage ports used
2 disk trays (RKA)
20 x 500GB 7200RPM SATA drive
2GB cache per controller
2 FOS 5.3.1a
14 4Gb Fibre Channel ports used
1 4 quad core AMD Opteron 1.9GHz processors
64GB memory
2 Emulex LPe11002-MH4 Fibre
Channel host bus adapters (HBAs)
4Gb/s
1 4 quad core AMD Opteron 1.9GHz processors
64GB memory
2 Emulex LPe11002-MH4 Fibre
Channel HBAs 4Gb/s
1 4 quad core AMD Opteron 1.9GHz processors
64GB memory
2 Emulex LPe11002-MH4 Fibre
Channel HBAs 4Gb/s
2 Intel Pentium 3.0GHz processor
1GB memory
1 Intel Pentium 3.0GHz processor
1GB memory
Role
Primary storage
External storage system attached to Hitachi Virtual
Storage Platform to store SAP backup data
N/A
SAP Solution Manager server
SAP ERP server
Backup server.
SAP clients
Management server with access to Hitachi Storage
Navigator software and
NetBackup Administration
Console.
9
SAP Servers
Servers hosting SAP Solution Manager and Solution ERP servers must meet specification requirements for the SAP roles they are hosting. For more information about server requirements for
SAP ERP, SAP Solution Manager and SAP clients, see the following SAP Notes, which are available to licensed customers from SAP’s web site :
SAP Note 1094599, Installation NW7-SR3/Business Suite 2005 SR3 Unix/Oracle
SAP Note 26147, SAP GUI Resources: Hardware and Software
SAP Note 901070, Resource Requirements for SAPECC6
NetBackup Servers
Servers hosting NetBackup master and media servers must meet requirements as documented in the
NetBackup master compatibility list available at Symantec’s web site .
Storage Area Network Components
In the tested deployment, the SAP Solution Manager and SAP ERP servers and the backup server were connected via two HBAs each to a Brocade 48000 director. The Brocade 48000 director, in turn, was connected to six ports of the Hitachi Virtual Storage Platform storage system. Two ports of the
Hitachi Virtual Storage Platform were connected to two ports of the Hitachi Adaptable Modular Storage system via the Brocade 48000 director.
Figure 2 illustrates the zones and the redundant paths that were managed by Hitachi Dynamic Link
Manager Advanced software in the deployment tested for this solution.
10
Figure 2
11
Software Components
Table 2 lists the software used to test this solution in the Hitachi Data Systems lab.
Table 2. Tested Deployment Software
Software
Hitachi Command Control Interface (CCI)
Hitachi Dynamic Link Manager
Version
01-23
6.0.1.0.804
Hitachi ShadowImage Heterogeneous Replication Licensed feature available with Hitachi Virtual
Storage Platform
Hitachi Storage Navigator N/A
SAP ERP
SAP Solution Manager
SAP GUI
Oracle Database 10g Enterprise Edition
Symantec NetBackup
NetBackup SAP and Oracle Agents
6.0 Special Release 3 (SR3)
7.0
7.1
10.2.0.4
7.0
7.0
Storage Configuration
For this solution, Hitachi Data System used a Hitachi Adaptable Modular Storage 2100, connected as external storage to a Hitachi Virtual Storage Platform, to store backup images of the SAP ERP data.
For this solution, Hitachi Data Systems used Hitachi Dynamic Provisioning software to provision storage. The storage provisioned to the servers was managed using a logical volume manager (LVM) on the host to create volume groups and logical volumes.
Table 3 lists storage configuration details for the Dynamic Provisioning pools created for SAP Solution
Manager, SAP ERP server and the backup server. All RAID groups used to create the Dynamic
Provisioning pools were RAID-5 (3D+1P).
12
Table 3. Hitachi Dynamic Provisioning Pool Configuration
Pool
61
Number of
Drives
Drive Capacity
12 300GB SAS
15K RPM
Pool
Capacity
(TB)
3.6
Number of LUs per Pool
Role
14 SAP Solution Manager server
62
63
64
12 300GB SAS
15K RPM
12 300GB SAS
15K RPM
20 500GB SATA 7.2K RPM on external storage
3.6
3.6
10
14
14
1
SAP ERP server
Backup server
Backup server
Table 4 lists storage configuration details for LDEVs created for the SAP Solution Manager server. All
LDEVs were mapped to storage ports 1A and 2A.
Table 4. LDEV Storage Configuration for SAP Solution Manager Server
Pool or RAID Group LDEV LUN Size (GB)
13
Table 5 lists storage configuration details for LDEVs created for the SAP ERP server. All LDEVs were mapped to storage ports 3A and 4A.
Table 5. LDEV Storage Configuration for SAP ERP Server
Pool or RAID
Group
LDEV LUN Size (GB)
14
Table 6 lists storage configuration details for LDEVs created for the backup server. All LDEVs were mapped to storage ports 5B and 6B.
Table 6. LDEV Storage Configuration for Backup Server
Pool or RAID Group LDEV LUN Size (GB)
15
Table 7 lists details for disk group, logical volume and file system layout of the SAP Solution Manager server and the SAP ERP server. Both servers have the same layout.
Table 7. SAP Solution Manager Server and SAP ERP Server Disk Group, Logical Volume and File System
Layout
Host
LUN
00
01
02
03
Disk Group Logical Volume
File System
Mount Point
Usage
appbin_vg appbin_sapmnt_lv /sapmnt appbin_vg appbin_usrsap<SID>
_lv
File system for central repository for SAP Solution
Manager, SAP binaries, and central location for moving data to another system when required
/usr/sap/<SID> File system for SAP binaries appbin_vg appbin_usrsap_tran s_lv
/usr/sap/trans File system for central location for moving data to another system appbin_vg appbin_oracle_lv /oracle
File system for Oracle binaries for installation of
Oracle, Oracle client, home directory for Oracle user, and to store data temporarily for online data reorganization respectively
04
05
06
07 applog_vg applogA_lv applog_vg applogB_lv
/oracle/<SID>/ origlogA
/oracle/<SID>/ origlogB
File system for online redo logs
File system for online redo logs applog_vg appmirrlogA_lv /oracle/<SID>/ mirrlogA
File system for online redo logs applog_vg appmirrlogB_lv /oracle/<SID>/
/mirrlogB logs
08
09
0A appalog_vg apparch_lv appdata_vg appdata_sapdata1_l v appdata_vg appdata_sapdata2_l v
/oracle/<SID>/ saparch
/oracle/<SID>/ sapdata1
/oracle/<SID>/ sapdata2
0B appdata_vg appdata_sapdat3_lv sapdata3
0C appdata_vg appdata_sapdata4_l v
/oracle/<SID>/ sapdata4
0D appdata_vg appdata_oradata_lv oradata
File system for archived logs
File system for SAP Solution
Manager data
File system for SAP Solution
Manager data
File system for SAP Solution
Manager data
File system for SAP Solution
Manager data
File system for Oracle data dictionary, temporary,
UNDO, and users tablespace data
16
Table 8 lists the disk group, logical volume, and file system layout for the disk storage units of the
NetBackup media server role on the backup server. The backup server is also used as the SAP ERP off-host server; however, the volume groups, logical volumes and the file systems that are mounted on this server as part of off-host backups are identical to SAP ERP server shown in Table 7 and do not need to be manually created.
Table 8. Backup Server Disk Group, Logical Volume and File System Layout
Host
LUN
101
102
Disk Group
sapbackup_vg
Logical Volume
File System Mount
Point
Usage
images of SAP data
Sapbackup2_lv /sapbackup2_dsu
When deploying an SAP system made up of SAP Solution Manager, an SAP ERP server and a backup server, the storage used by these servers must be logically isolated from each other in the SAN via the use of zones and host groups. As shown in Figure 2, eight separate Fibre Channel zones are created, one from each HBA of the SAP Solution Manager server, SAP ERP server and the backup server and two zones between the Hitachi Virtual Storage Platform and the externally connected Hitachi Adaptable
Modular Storage.
World wide names (WWNs) of the HBAs residing on a physical server can be assigned to a host group and then a logical device (LDEV) can be associated with each host group. This means that a group of
LDEVs can be isolated to be used by only the assigned physical servers.
Solution Implementation
Deploying this solution requires following these high-level steps:
3. Deploy SAP Solution Manager software.
4. Deploy SAP ERP software.
5. Deploy the backup server.
6. Install Hitachi Command Control Interface software.
7. Create command devices.
8. Configure ShadowImage software for off-host backups.
9. Backup SAP ERP data.
10. Restore SAP ERP data.
Your checklist might vary based on your environment. More information about each of these steps is included in the following sections.
17
Configure Servers
Configure the SAP Solution Manager, the SAP ERP server and the backup server as shown in Figure
1. Also configure the SAP clients and the management server. The management server accesses
Hitachi Storage Navigator software and the NetBackup remote administration client.
Configure Storage
The following sections describe how to configure your storage for this solution.
Create Dynamic Provisioning Pools
This procedure assumes that zoning within your Fibre Channel fabric is complete. To create Dynamic
Provisioning pools on a Virtual Storage Platform using Hitachi Storage Navigator software, follow these steps:
The Create Pools window displays.
The Select Pool VOLs window displays.
4. Highlight one or more pool volumes in the Available Pool Volumes pane and click OK.
The Create Pools window displays with Total Selected Pool Volume and Total Selected
Capacity fields populated.
5. Assign a prefix for the pool name in the Prefix field.
6. (Optional) Assign an initial number for the pool name in the Initial Number field.
8. Assign a pool ID in the Pool ID field.
9. Assign a subscription limit in the Subscription Limit field.
This is the percentage of oversubscription for this pool that you allow in your environment.
10. Choose a value from the User-Defined Threshold drop-down menu and click the Add button
The User Defined Threshold value determines when a pool capacity alert is triggered.
The Selected Pools pane is populated.
11. Click the Finish button.
12. The Create Pools window displays.
13. Click the Apply button.
18
Create LDEVs Within a Dynamic Provisioning Pool
This procedure assumes that Dynamic Pool creation in your environment is complete. To create one or more LDEVs within a Dynamic Provisioning pool using Hitachi Storage Navigator software, follow these steps:
The Create LDEVs window displays.
4. (Optional) Choose a menu item from the Drive Type/RPM drop-down menu and from the RAID
Level drop-down menu.
These options allow you to filter the available pool volumes.
The Select Pool window displays.
6. Highlight a pool in the Available Pools pane and click OK.
The Create LDEVs window displays with the Selected Pool Name and the Selected Pool
Capacity fields populated.
7. Enter a capacity amount in the LDEV Capacity field and choose a unit of measure from the drop-down menu.
8. Enter the number of LDEVs of that size to be created in the Number of LDEVs field.
Initial Number field.
10. Expand the Options pane.
11. Review the value in the LDKC field.
Modify the LDKC value if the default of
00 is not appropriate. This is most often the case if the storage will be configured with more than one LDKC.
12. Choose a value from the CU drop-down menu.
13. Choose a value from the DEV drop-down menu.
14. (Optional) Choose a value from Interval drop-down menu.
Leave this value at the default of 0 for sequential numbering of LDEVs. If you want a different numbering sequence, choose a different value.
15. Review the default values in the Initial SSID field, the CLPR field and Processor Blade field.
In most situations, use the default values. Change them only if your environment requires different values.
19
16. Click the Add button.
The Selected LDEVs pane is populated.
17. Click the Finish button.
The Create LDEVs window displays.
18. Click the Apply button.
Create Host Groups
To create host groups using Storage Navigator software, follow these steps:
The Create Host Groups window displays.
2. Assign a name in the Host Group Name field.
The Selected Host Groups pane is populated.
The Create Host Groups window displays.
Map LDEVs
To map LDEVS using Hitachi Storage Navigator software, follow these steps:
The Add LUN Paths window displays.
The Selected LDEVs pane is populated.
The Add LUN Paths window displays.
The Selected Host Groups pane is populated.
20
The Add LUN Paths window displays.
The Add LUN Paths window displays.
Install Hitachi Dynamic Link Manager Advanced Software and Configure Storage
System
To install Hitachi Dynamic Link Manager Advanced software and configure your storage system, follow these steps:
1. Execute the following command on the server on which you want to install Hitachi Dynamic
Link Manager Advanced software:
./installhdlm
When the installation is complete, Hitachi Dynamic Link Manager Advanced software displays a message indicating that the software was successfully installed.
Hitachi Dynamic Link Manager Advanced software names your disk device using the following format: sddlm<disk-device>
<disk-device> is a combination of letters from a to z identifying your disk device.
2. On each server, using LVM, create a physical volume (PV) on each disk device using the following syntax: pvcreate /dev/sddlm<disk-device>
3. On each server, using LVM, create volume groups using the following syntax: vgcreate –s 64 <volume group name> <physical volume name(s)>
Table 7 and Table 8 show the volume groups needed for this solution.
4. On each server, create logical volumes, using the following syntax: lvcreate –l <size of logical volume> -n <volume volume name> <volume group name>
Table 7 and Table 8 show the logical volumes and respective volume groups needed for this solution.
21
5. On each server, create a file system for each logical volume using the following syntax: mke2fs –t ext2 /dev/<volume group name>/<logical volume name>
6. Mount each file system using the following syntax: mount –t ext2 –o async /dev/<volume group name>/<logical volume name>
/<mount point>
Table 7 and Table 8 show the file systems and mount points needed for this solution.
Deploy SAP Solution Manager Software
Install SAP Solution Manager software on a dedicated server.
To deploy SAP Solution Manager, follow these steps:
1. Copy the SAP Solution Manager software from the installation media to a staging directory on the Solution Manager server.
SAP Installation Master launches.
3. Choose the Central System service by navigating the service tree as follows:
SAP Solution Manager 4.0 Support Release 4 > SAP Systems > Oracle > Central System
22
5. Identify and provide the parameters as prompted by SAP Installation Master.
SAP Installation Master verifies all parameters that you provide and begins to execute the installation. If any parameters cannot be validated, values can be changed.
23
6. Provide any input required by SAP Installation Master during the execution phase.
After all the steps are complete, SAP Installation Master displays a message indicating successful installation.
Deploy SAP ERP Software
Install SAP ERP on a dedicated server.
To install SAP ERP, follow these steps:
1. Copy the SAP ERP software from the installation media to a staging directory on the Solution
Manager server.
SAP Installation Master launches.
3. Choose the Central System service by navigating the service tree as follows:
SAP ERP 6.0 Support Release 3 > SAP Systems > Oracle > Central System
24
4. Identify and provide the parameters as prompted by SAP Installation Master.
SAP Installation Master verifies all parameters that you provide and begins to execute the installation. If any parameters cannot be validated, values can be changed.
25
5. Provide any input required by SAP Installation Master during the execution phase.
After all the steps are complete, SAP Installation Master displays a message indicating successful installation.
Deploy the Backup Server
Configure the backup server by installing the operating system, Symantec NetBackup master server, and NetBackup media server. Follow the Symantec NetBackup Installation Guide for UNIX and Linux
Release 7.0, which is available from Symantec’s web site , to install the NetBackup master server and the NetBackup media server.
Install Hitachi Command Control Interface
To install Hitachi Command Control Interface (CCI) software on the SAP ERP server and the SAP ERP off-host server, follow these steps:
1. Insert the installation media.
2. Navigate to the root directory:
# cd /
26
3. Copy all files from the installation media using the following command:
# cpio -idmu < /mnt/cdrom/LINUX/HORCM
4. Execute the HORCM installation command:
# /HORCM/horcminstall.sh
Create a Command Device
This procedure assumes that creation and mapping of the LDEV to be used as a command device is complete. This solution uses one 5GB LDEV for a command device. To create a command device using Hitachi Storage Navigator software, follow these steps:
The Logical Devices pane displays.
2. Highlight the LDEV to be converted to a command device. that displays.
The Edit Command Devices window displays.
The Confirm Edit Command Devices window displays.
Configure ShadowImage for Off-host Backups
The following procedure uses Hitachi Command Control Interface (CCI) commands. If you are not familiar with CCI commands, see Appendix B.
To configure ShadowImage in-system replication between the SAP ERP server and the backup server follow these steps:
1. Create Hitachi Open Remote Copy Manager (HORCM) configuration definition file for SAP
ERP server.
Hitachi Data Systems used the horcm0.conf file in Appendix C as the HORCM configuration definition file for the SAP ERP server.
2. Create a HORCM configuration definition file for the backup server.
Hitachi Data Systems used the horcm1.conf file in Appendix C as the HORCM configuration definition file for the backup server.
3. Start HORCM instance on the SAP ERP server using the following command:
# horcmstart.sh
27
4. Start the HORCM instance on the backup server.
5. Create ShadowImage pairs and configure them to use a consistency group between LUs of SAP
ERP server (P-VOLs ) and the corresponding LUs of the SAP ERP off-host server (S-VOLs) by executing the following command on the production server:
# paircreate –g <Consistency Group Name> -vl –m grp –IM0
Hitachi Data Systems used
SAPBKP for the consistency group name in testing this solution.
Backup SAP ERP Data
Backing up SAP ERP data involves creating consistent point in time images using ShadowImage Insystem Replication software and a backup of the data using NetBackup.
To backup SAP ERP data from the SAP ERP off-host server using NetBackup, follow these steps:
1. Initiate BRBackup to create a consistent point-in-time split image of the SAP ERP system by executing the following command as Oracle user from the SAP ERP server:
# brbackup –u system –t online_split –p initPRD.sap.onsplit
2. BRBackup places database in backup mode, splits the P-VOLs and S-VOLs using the
ShadowImage pairsplit command and takes the database out of backup mode.
3. Activate all volume groups to allow access to their logical volumes on the SAP ERP off-host server using the following command:
# vgchange –ay
4. Mount the file systems listed in Table 7 on the SAP ERP off-host server.
5. Create a disk storage unit on the NetBackup master server to store the backup image of SAP
ERP data.
Follow the Symantec NetBackup Administrator’s Guide for UNIX and Linux Release 7.0, which is available from Symantec’s web site , to create a disk storage unit. Make sure the following attributes are set:
Storage unit type — Disk
Disk type — BasicDisk
Media server — Use the host name of the NetBackup media server
Note that the absolute path name to the directory is the mount point listed in Table 8 of this document
28
6. Create a NetBackup policy on the NetBackup master server to backup SAP ERP data.
Follow the Symantec NetBackup Administrator’s Guide for UNIX and Linux Release 7.0, which is available from Symantec’s web site , to get create a policy to take a backup. Make sure the following attributes are set:
Policy type — Standard
Policy storage — Match the disk storage unit created in Step 4
Client — NetBackup media server
Backup selection — Add all the file systems listed in Table 7
7. Initiate a backup of SAP ERP data from the SAP ERP off-host server by executing a manual backup of the NetBackup policy created in Step 5.
This ensures that data from SAP ERP server is backed up on the SAP ERP off-host using the
ShadowImage S-VOL and NetBackup.
8. Check the status of backup using the NetBackup’s activity monitor.
Restore and Recover SAP ERP Data
SAP ERP data can be restored in a variety of ways depending on the availability of the backup image.
Based on the procedure described in the previous section, data can be restored and recovered in two ways:
NetBackup’s redirected restore — Use this method to restore data if the backup data is only available via the backup images created using NetBackup.
ShadowImage software — Use this method to restore if the data to restore is available as
ShadowImage S-VOLs.
The following sections describe each of the methods.
Restore and Recover SAP ERP Data Using NetBackup’s Redirected Restore
Although the SAP ERP data was backed up from SAP ERP off-host server, the data from the backup image can be restored to the SAP ERP server. To use the redirected restore method to restore and recover data, follow these steps:
1. Configure the NetBackup server and the NetBackup client to enable redirected restore.
Follow the Symantec NetBackup for SAP Administrator’s Guide for UNIX and Linux Release
7.0, which is available from Symantec’s web site , to configure these to enable redirected restore.
2. Set the following attributes in the recovery interface:
NetBackup server — Host containing NetBackup master server
Source client — Host containing NetBa ckup media server
Destination client —SAP ERP server
Policy type — Standard
29
3. Navigate to the directory containing the backup image.
In this example, the directory is
/sapbackup_dsu
5. Mount the file systems listed in Table 7 on the SAP ERP server.
6. Start the Oracle database in the mount state by executing the following command as Oracle user on the SAP ERP server:
SQLPLUS> startup mount; server:
SQLPLUS> recover database;
8. Open the database by executing the following command as Oracle user on the SAP ERP server:
SQLPLUS> alter database open;
9. Shut down the database by executing the following command as Oracle user on the SAP ERP server:
SQLPLUS> shutdown;
10. Start Oracle listener by executing the following command as Oracle user on the SAP ERP server:
# lsnrctl start
11. Start the SAP instance and the Oracle database by issuing the following command as SAP user on the SAP ERP server:
# startsap
The data on the SAP ERP server is now restored and recovered to the point-in-time backup of the previous backup.
Restore and Recover SAP ERP Data Using ShadowImage Software
SAP ERP data can be restored using ShadowImage if the needed S-VOLs are available and are in pair suspend (PSUS) state. To restore and recover SAP ERP data using ShadowImage software, follow these steps:
1. Stop the SAP instance and the Oracle databases by issuing the following command as SAP user on the SAP ERP server:
# stopsap
2. Unmount all the file systems listed in Table 7 on the SAP EPR server.
3. Restore ShadowImage Pair by executing following command on the SAP ERP server
# pairresync –g SAPBKP –restore –fq normal
4. Mount the file systems listed in Table 7 on the SAP ERP server.
30
5. Start the Oracle database in the mount state by executing the following command as Oracle user on the SAP ERP server:
SQLPLUS> startup mount; server:
SQLPLUS> recover database;
7. Open the database by executing the following command as Oracle user on the SAP ERP server:
SQLPLUS> alter database open;
8. Shut down the database by executing the following command as Oracle user on the SAP ERP server:
SQLPLUS> shutdown;
9. Start Oracle listener by executing the following command as Oracle user on the SAP ERP server.
# lsnrctl start
10. Start SAP and Oracle database by issuing the following command as SAP user on the SAP ERP server:
# startsap
The data on the SAP ERP server is now restored and recovered to the point-in-time of the previous pairsplit operation.
31
Appendix A — Tested Deployment Configuration,
Parameter and Script Files for Replicating an SAP
System
Hitachi Data Systems used the following files for replicating an SAP system:
BRBackup configuration file
Script file for splitting P-VOLs and S-VOLs
Oracle server parameter file on the SAP ERP server
Oracle server parameter file on the SAP ERP off-host server
BRBackup Configuration File
#FileName: initPRD.sap.onsplit backup_mode = full restore_mode = full backup_dev_type = disk backup_type = online_split split_cmd = "/oracle/PRD/102_64/dbs/do_onsplit.sh" primary_db = PRD orig_db_home = /oracle/PRD stage_copy_cmd = scp backup_root_dir = /oracle/PRD/sapbackup
Script File for Splitting P-VOLs and S-VOLs
#FileName: do_onsplit.sh export HOCMINST=1 export HORCC_MRCF=1 export HORCC_LOG=/home/oraprd pairsplit -g SAPBKP
32
Oracle Server Parameter File on the SAP ERP Server
#FileName: initPRD.ora
*._B_TREE_BITMAP_PLANS=FALSE
*._IN_MEMORY_UNDO=FALSE
*._INDEX_JOIN_ENABLED=FALSE
*._OPTIM_PEEK_USER_BINDS=FALSE
*._OPTIMIZER_MJC_ENABLED=FALSE
*._SORT_ELIMINATION_COST_RATIO=10
*._TABLE_LOOKUP_PREFETCH_SIZE=0
*.background_dump_dest='/oracle/PRD/saptrace/background'
*.compatible='10.2.0'
*.control_file_record_keep_time=30
*.control_files='/oracle/PRD/origlogA/cntrl/cntrlPRD.dbf','/oracle/PRD/origl ogB/cntrl/cntrlPRD.dbf','/oracle/PRD/sapdata1/cntrl/cntrlPRD.dbf'
*.core_dump_dest='/oracle/PRD/saptrace/background'
*.db_block_size=8192
*.db_cache_size=9133306675
*.db_files=254
*.db_name='PRD'
*.dml_locks=4000
*.event='10191 trace name context forever, level 1'
*.FILESYSTEMIO_OPTIONS='setall'
*.job_queue_processes=1
*.log_archive_dest='/oracle/PRD/saparch/PRDarch'
*.log_buffer=1048576
*.log_checkpoint_interval=0
*.log_checkpoints_to_alert=true
*.open_cursors=800
*.parallel_execution_message_size=16384
*.pga_aggregate_target=12177742233
*.processes=80
*.query_rewrite_enabled='false'
33
*.recyclebin='off'
*.remote_login_passwordfile='exclusive'
*.remote_os_authent=true
*.replication_dependency_tracking=false
*.sessions=96
*.sga_max_size=18266613350
*.shared_pool_reserved_size=913330667
*.shared_pool_size=9133306675
*.sort_area_retained_size=0
*.sort_area_size=2097152
*.star_transformation_enabled='true'
*.undo_management='AUTO'
*.undo_retention=43200
*.undo_tablespace='PSAPUNDO'
*.user_dump_dest='/oracle/PRD/saptrace/usertrace'
34
Appendix B — Hitachi Command Control Interface
Software
Hitachi Command Control Interface software (CCI) has two sets of components, one set residing on the storage system and another set residing on the server. The CCI components residing on the storage system are command devices and ShadowImage volumes (P-VOLs, S-VOLS). The components residing on the servers are Hitachi Open Remote Copy Manager, also known as HORCM, configuration definition files (for example, horcm1.conf) and CCI commands. Although the ShadowImage software residing in the Hitachi Virtual Storage Platform family storage system maintains the replication of data between the P-VOLs and the S-VOLs, the CCI software allows you to manage, monitor and control the
ShadowImage process.
The HORCM operational environment operates as a daemon process on the host server. When
HORCM is activated, it refers to the configuration definition files. The HORCM instance communicates with the storage system and remote or secondary servers. Two HORCM instances are required for
ShadowImage to be operational: one manages the P-VOLs and one manages the S-VOLs. The
HORCM configuration file defines the communication path and the logical units (LUs) to be controlled.
Each HORCM instance has its own HORCM configuration file. The horcm0.conf and the horcm1.conf files used for this solution are available in Appendix C.
Figure 3 shows the two-server, two-HORCM instance configuration used for CCI for this solution.
Figure 3
For more information about setting up the HORCM instances and HORCM configuration file, see the
Hitachi Command Control Interface (CCI) Users and Reference Guide that accompanies the Hitachi
Command Control Interface software.
35
The CCI commands are generally executed by the root user. However, CCI can be configured to allow users other than root user to execute the command to manager replication. For this solution, the CCI commands are executed by a user other than the root user. For more information about how to configure CCI to allow users other than root to manage replication using CCI, see the ”Changing CCI
User from root” section in this appendix.
In the Hitachi Virtual Storage Platform, the ShadowImage software consistency group function allows a user-defined group of ShadowImage volume pairs to be split simultaneously with a single command.
This copy method creates a data-consistent, point-in-time copy of an entire system, database or any related sets of volumes. Multiple ShadowImage pairs can be defined as one consistency group using
CCI.
CCI Commands
After you start the HORCM instance on all the servers, you can execute CCI commands to manage, monitor and control replication between the servers.
Table 9 lists CCI commands for PAIR operations.
Table 9. CCI Commands for PAIR Operations
Command Name
paircreate pairsplit pairresync pairresync – restore
Description
Creates a new pair.
Splits pairs and create a point-in-time backup in the S-
VOL by stopping the update of the secondary volume.
The pair relationship of the P-VOL is maintained, and the differential information is also maintained.
Resynchronizes pairs from PSUS or SSUS status.
The direction of resynchronization is from P-VOL to S-
VOL. Uses differential information to resynchronize.
Only changed data needs to be copied.
Resynchronizes pairs from PSUS or SSUS status.
The direction of resynchronization is from S-VOL to P-
VOL. Uses differential information to resynchronize.
Only changed data needs to be copied. pairsplit –S
Discards the pair’s differential information and deletes the pair. pairevtwait
Command to wait until a group enters a specified status. This command is needed to make a positive transition to the PAIR status. pairdisplay
Checks pair status and progress rate.
Notes
Status of P-VOL and S-
VOL changes from SMPL to PAIR.
Status of P-VOL changes from PAIR or COPY to
PSUS.
Status of S-VOL changes from PAIR or COPY to
SSUS.
Status of P-VOL changes from PSUS to PAIR.
Status of S-VOL changes from SSUS to PAIR.
Status of P-VOL changes from PSUS to PAIR.
Status of S-VOL changes from SSUS to PAIR.
Status of P-VOL changes to SMPL.
N/A.
N/A.
36
Changing CCI User from root
CCI software is initially configured to allow only the root user (system administrator) to execute CCI commands. If desired (for example CCI administrator does not have root access), the system administrator can change the CCI user from root to another user name.
To change the CCI user from root to another user name, follow these steps:
1. Change the owner of the following CCI files from the root user to the desired user name:
• /
HORCM/etc/horcmgr
• All CCI commands in the
/HORCM/usr/bin directory
• All CCI log directories in the
/HORCM/log* directories
2. Change the owner of the raw device file of the HORCM_CMD command in the configuration definition file from the root user to the desired user name.
Note that ownership must remain persistent across system reboots.
3. Configure the system to start the HORCM daemon during the system startup process.
4. Create a startup script and place it in the
/etc/init.d directory and execute the HORCM startup script ( horcmstart.sh) from the startup script.
The startup script must set the environment variable HORCM_EVERYCLI=1 and change the owner of the
/HORCM/.uds directory after the HORCM daemon starts.
5. When executing CCI commands, set the
HORCC_LOG variable to appropriate value indicating the HORCM LOG location where the owner has permission to create a log file.
37
Appendix C — ShadowImage Configuration Files
ShadowImage configuration files consist of following sections:
HORCM_MON — Contains information need to monitor a HORCM instance such as IP address,
HORCM instance or service, pooling interval for monitoring paired volumes and timeout period for communication with remote server.
HORCM_CMD — Contains device path information about the command device.
HORCM_LDEV —Defines the storage sub-system device address for the paired logical volume names.
HORCM_INST — Network address of the remote server.
ShadowImage Configuration Files for SAP ERP Server
#FileName: horcm0.conf
#/***************** For HORCM_MON ********************************/
HORCM_MON
#ip_address
172.17.252.105 service horcm0 poll(10ms)
1000 3000 timeout(10ms)
#/***************** For HORCM_CMD ********************************/
HORCM_CMD
/dev/sdl
#/****************** For HORCM_LDEV ******************************/
HORCM_LDEV
#dev_group dev_name Serial# CU:LDEV(LDEV#) MU#
SAPBKP SAPDEV1 53101 03:00 0
SAPBKP SAPDEV2 53101 03:01 0
SAPBKP SAPDEV3 53101 03:02 0
SAPBKP SAPDEV4 53101 03:03 0
SAPBKP SAPDEV5 53101 03:04 0
SAPBKP SAPDEV6 53101 03:05 0
SAPBKP SAPDEV7 53101 03:06 0
SAPBKP SAPDEV8 53101 03:07 0
38
SAPBKP SAPDEV9 53101 03:08 0
SAPBKP SAPDEV10 53101 03:09 0
SAPBKP SAPDEV11 53101 03:0A 0
SAPBKP SAPDEV12 53101 03:0B 0
SAPBKP SAPDEV13 53101 03:0C 0
SAPBKP SAPDEV14 53101 03:0D 0
#/********** ********* For HORCM_INST ****************************/
HORCM_INST
#dev_group ip_address service
ShadowImage Configu ration Files for SAP ERP Off-host Server
#FileName: horcm1.conf
#/********* ******** For HORCM_MON******************************/
HORCM_MON
#ip_address service poll(10ms) 10ms)
17 2.17.252.104 horcm1 1000 3000
#/********* ******** For HORCM_CMD******************************/
HORCM_CMD
#dev_name de
/d ev/sdl
#/ ************************** For HORCM_LDEV ********************/
HORCM_LDEV
#dev_group dev_name Serial# CU:LDEV(LDEV#) MU#
SAPBKP SAPDEV1 53101 04:00 0
SAPBKP SAPDEV2 53101 04:01 0
SAPBKP SAPDEV3 53101 04:02 0
SAPBKP SAPDEV4 53101 04:03 0
39
SAPBKP SAPDEV5 53101 04:04 0
SAPBKP SAPDEV6 53101 04:05 0
SAPBKP SAPDEV7 53101 04:06 0
SAPBKP SAPDEV8 53101 04:07 0
SAPBKP SAPDEV9 53101 04:08 0
SAPBKP SAPDEV10 53101 04:09 0
SAPBKP SAPDEV11 53101 04:0A 0
SAPBKP SAPDEV12 53101 04:0B 0
SAPBKP SAPDEV13 53101 04:0C 0
SAPBKP SAPDEV14 53101 04:0D 0
#/*********** ******** For HORCM_INST **************************/
HORCM_INST
#dev_group ip_address
SAPBKP 172.17.252.107 horcm0 service
40
Hitachi is a registered trademark of Hitachi, Ltd., in the United States and other countries. Hitachi Data Systems is a registered trademark and service mark of Hitachi,
Ltd., in the United States and other countries. All other trademarks, service marks and company names mentioned in this document are properties of their respective owners.
Notice: This document is for informational purposes only, and does not set forth any warranty, expressed or implied, concerning any equipment or service offered or to be offered by Hitachi Data Systems Corporation
© Hitachi Data Systems Corporation 2010. All Rights Reserved. AS-056-00 October 2010
Corporate Headquarters
750 Central Expressway,
Santa Clara, California 95050-2627 USA www.hds.com
Regional Contact Information
Americas: +1 408 970 1000 or [email protected]
Europe, Middle East and Africa: +44 (0) 1753 618000 or [email protected]
Asia Pacific: +852 3189 7900 or [email protected]
41
advertisement
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Related manuals
advertisement