6 p6000 sap business suite

8/4/2019 6 P6000 SAP Business Suite

1/25

HP StorageWorks Enterprise Virtual Array

configuration guide for SAP Business Suite

Table of contents

Executive summary............................................................................................................................... 2Overview............................................................................................................................................ 2EVA6400/EVA8400........................................................................................................................... 2

Feature comparison.......................................................................................................................... 3445567788

1010

101313131616

18181920

2222

2324

25252525

General recommendations.................................................................................................................... Physical disks .................................................................................................................................. Disk groups ..................................................................................................................................... Internal arbitrated loops.................................................................................................................... Disk-failure protection ....................................................................................................................... Sequential and random I/O pattern ................................................................................................... Data-availability domains..................................................................................................................

Very large databases (VLDBs) ........................................................................................................ Virtual disks.....................................................................................................................................

Number of virtual disks ............................................................................................................... The SAP database server in the HP storage area network ...................................................................

Microsoft Windows .................................................................................................................... HP-UX ....................................................................................................................................... Data replication tools .....................................................................................................................

Sizing the snapshot/snapclone working space............................................................................... Performance considerations for snapshot/snapclone operations....................................................... MirrorClone replication...............................................................................................................

Configuration examples...................................................................................................................... One-disk group configuration .......................................................................................................... Two-disk group configuration...........................................................................................................

Crossed installations ................................................................................................................... Appendix .........................................................................................................................................

A: Sample customer SAP landscape EVA configuration ...................................................................... B: Four-disk group high-end configuration with snapshot concept ......................................................... Snapshot performance and space requirements .............................................................................

For more information.......................................................................................................................... Oracle links................................................................................................................................... Microsoft links ............................................................................................................................... SAP links.......................................................................................................................................


2/25

Executive summary

Good distribution of SAP components on HP StorageWorks Enterprise Virtual Array (EVA) storageenables sufficient disk storage space and reliable data security with a high level of I/O performance.

The virtualization technology used in the EVA represents a unique approach to storage technologyone that consolidates disparate storage into a single virtual storage environment. This approachenhances storage capacity, manageability, availability, and performanceand contributes to a

dramatically reduced total cost of ownership (TCO) for SAP customers.How best to assign the SAP Business Suite system to virtual RAID levels in EVA disk groups dependson customer-specific workloads, individual performance, and availability requirements. The proposedrecommendations in this document include sample configurations for different SAP landscapes.

Overview

The HP StorageWorks EVA4400, EVA6400, and EVA8400 disk subsystems are the latest HP storageofferings based on full Fibre Channel (FC) technology and complete virtualization of physical disks.These features are HPs response to growing demands in the areas of data protection, I/Operformance, and the efficient use of disk storage capacity.

The EVA6400 and EVA8400 models are the newest in a line of successful EVAs, built on theEVAx400 architecture of dual-redundant design. With all the power and simplicity of the EVA family,the EVA6400 and EVA8400 are storage solutions of choice for mid-sized and enterprise customers.Please refer to the EVA6400/EVA8400 section of this document for further details.

This document contains basic information on how to configure an Enterprise Virtual Array to complywith SAP requirements based on version 9.5 of the EVA4400, EVA6400, and EVA8400 and version6.110 of the EVA4100/EVA6100/EVA8100 firmware XCS.

EVA6400/EVA8400

Like the other, older-generation EVAs, these newer models are modular in design. The controllerhardware is a single 2U enclosure with two controller modules. A single 2U disk enclosure contains amaximum of 12 FC/FATA disk drives. An EVA6400 model is shown in Figure 1; however, the actualconfiguration may differ depending on the number of disk enclosures and the components beingracked with the EVA. A high-level summary of supported features is shown in Table 1. Please refer tothe EVA6400/EVA8400 QuickSpecs at www.hp.com/go/storage for a complete list of supportedfeatures.

Table 1.

Feature Supported by EVA6400/EVA8400

Drives (FC/FATA) 400 GB @ 10k rpm;146 GB, 300 GB, 450 GB @15k rpm;1 TB FATA

RAID type 1, 0+1, 5, 0+5, 6

LUN size Up to 32 TB

Number of hosts supported 512/256 (single path/dual path)

Host attach FC and iSCSI (with iSCSI Connectivity option)

Management software Command View EVA v9.0

Continuous Access andBusiness Copy

Virtually capacity-free snapshots, snapclones, MirrorClones, cross-Vraid snapshots;synchronous and asynchronous replication

2
http://www.hp.com/go/storagehttp://www.hp.com/go/storage


3/25


4/25

General recommendations

The following sections provide an overview of the various components of the Enterprise Virtual Array.Some general recommendations and restrictions are given for configurations in an SAP Business Suiteenvironment. Other recommendations and up-to-date EVA management information are based onactual customer advisories for the EVA.

Physical disksFor several years, many general trends have been observed in the storage industry. With respect todatabase configurations, these trends can be summarized as follows:

Increasing disk capacity has allowed larger databases to be installed on fewer disks. The standard physical disk drives I/O performance has increased slowly in relation to their data

capacity, leading to more performance bottlenecks.

High-capacity, lower-cost, and lower-performing Fibre Attached Technology Adapted (FATA) diskdrives are available for near-online purposes. 1

Faster server CPU speed increases the number of I/O operations per second per CPU. RAM capacity is growing more slowly than disk capacity, making cache size smaller relative to disk

size.

The first three trends listed above also apply to the disk drives used in the EVA. The storagevirtualization technology used in the EVA addresses these issues by sharing all physical diskcapabilities in a disk group among all virtual disks in the group.2 However, I/O measurements on theEVA show that random I/O operations (read operations) in a small block size still depend heavily onthe number of physical disk drives belonging to the disk group, clearly revealing a random I/Obottleneck on the total number of disk drives within smaller disk groups. A virtual disk on a disk groupbuilt from 32 physical 146 GB disk drives has, in general, lower I/O capabilities than one built from64 physical 72 GB drives, even though both configurations provide the same amount of disk space.

Table 3. FC disk drives in an EVA array

Capacity 146 GB 300 GB 72 GB 146 GB 300 GB 450 GB 1 TB

Spindle speed 10,000 rpm 10,000 rpm 15,000 rpm 15,000 rpm 15,000 rpm 15,000 rpm FATA1

Database-like performance tests have shown a performance increase of 30 percent in 15,000 rpmdisk drives in relation to 10,000 rpm disk drivesa direct consequence of faster seek times androtational speedsbut the I/O capabilities within a 64-disk group built from 36 GB, 10,000-rpm diskdrives are still superior to those of a 32-disk group built from 72 GB, 15,000 rpm drives.

On the other hand, when an I/O bottleneck has been detected within a group, the EVA makes itpossible to enhance virtual disk performance by dynamically adding further disk drives to the groupwithout affecting the uptime of the SAP application. (A prerequisite for this option is to ensure that free

disk slots are available in the EVA when the I/O load cannot be determined up front.)

Taking the trends and observations described above into account, it is important to size a storageconfiguration for the EVA primarily for I/O performance rather than for pure data capacity. A greaternumber of spindles within a configuration generally reduces the risk of I/O bottlenecks on the diskdrives within disk groups. To achieve a reasonable balance between disk capacity and I/Operformance based on the number of available spindles, HP therefore recommends planning forsmaller, but more disk drives in an SAP environment where the detailed I/O profile is not known.

1 Refer to the HP EVA solution paper: High-Performance and Low-Cost Disk Drives.2 Refer to the HP white paper, StorageWorks Enterprise Virtual Array configuration best practices.

4
http://www5.itrc.hp.com/service/cki/enterService.doftp://ftp.compaq.com/pub/products/storageworks/whitepapers/5982-7353EN.pdfhttp://h71028.www7.hp.com/enterprise/cache/599686-0-0-0-121.htmlhttp://h71028.www7.hp.com/enterprise/cache/599686-0-0-0-121.htmlftp://ftp.compaq.com/pub/products/storageworks/whitepapers/5982-7353EN.pdfhttp://www5.itrc.hp.com/service/cki/enterService.do


5/25

The FATA disks specified for use in the EVA are high-capacity, lower-cost, lower-performance drivesrecommended for near-online usage such as Rapid Backup 3 configurations, and are not intended asreplacements for the standard high-performance drives in an SAP environment requiring good randomaccess performance and nearly continuous operations. There is nothing that speaks against the usageof FATA drives for SAP quality assurance and development systems, possibly generated out of an SAPproduction server with EVA local replication 4 capabilities.

Disk groups

The key advantage of the EVA is its capability to virtualize multiple physical disk drives into singleblock of disk space. Any administrator configuring EVA disk groups for SAP Business Suite must bearin mind that defining each additional disk group slowly diminishes the impact and advantages of thevirtualization technology. On the other hand, a greater number of disk groups does allow for a higherdegree of data availability.

Depending on the type of installation, administrators must find an ideal balance of I/O performance,efficient use of disk capacity, and overall data availability. In general, having more disk groups tendsto make the use of disk storage capacity less efficient, but it also increases data availability related tosingle or multiple SAP instances per EVA. I/O performance depends on the number of physical disksin the disk group and the type of I/O on the disk group.

The following rules offer guidance on how best to configure an EVA group for an SAP environmentand provide general recommendations regarding EVA configuration:

The number of disk groups should be kept to a minimum. The maximum number of disk groups perEVA is 16.

Each disk group must contain a minimum of eight disk drives.A disk group should have a multiple of eight equal-size disk drives. Mixing disk types within a

group is not recommended. This approach allows the EVA firmware performance-optimizationalgorithms to work at optimum levels.

Disk groups should be sized such that they have a good margin of unreserved space in addition totheir spare storage capacity. Management flexibility improves significantly as free disk groupstorage capacity increases. A high but good value of spare capacity per group is 10 percent. To

notify users when spare capacity becomes low, the Occupancy Alarm Level under Disk GroupProperties should be set to 90 percent in HP StorageWorks Command View EVA.

Internal arbitrated loops

A maximum of 324 disks may be accessed from the EVA controllers through as many as ninearbitrated loops, as shown in Figure 2 (only four loops are shown). Note that this is a schematicfigure of the EVA; it is not a detailed configuration drawing showing the required loop switches forsome EVA5000, EVA6000, and EVA8000 configurations. Many hardware and softwareimprovements have been introduced with the EVA4400, EVA6400, and EVA 8400 models withoutcompromising compatibility with previous EVA models. Two important enhancements for scaling out inlarger SAP production environments are the availability of two mirror ports and the additional fourhost ports in the EVA6400and EVA8400.

3 Refer to HP StorageWorks solutions for SAP.4 See the Data replication tools section of this document.

5
http://h71028.www7.hp.com/enterprise/cache/231355-0-0-0-121.htmlhttp://h71028.www7.hp.com/enterprise/cache/231355-0-0-0-121.html


6/25

Two redundant loops (loop pair 2) serve the upper part of the cabinet; an additional two redundantloops (loop pair 1) serve the lower part. To facilitate equal distribution over the two loop pairs, thedisks in a disk group should be split equally over the two parts. To reduce the risk of virtual disk anddisk group failurewhich only occurs in the extremely rare event of a double-disk failure or a whole-disk-shelf failurethe disks within a disk group should always be distributed over as many diskshelves as possible, with the lowest possible number of disks used on a single shelf. Each subsequentdisk group should be added vertically.

Figure 2. EVA schematic view

When defining a disk group by specifying the number of disks for that group, the EVA follows thisrule and builds disk groups vertically. In addition, it is possible to allocate specific disks manually tothat new group by ungrouping the unwanted disk drives and specifying the desired ones. Other diskdrives can be either temporarily grouped or detached until the new disk group is defined.

Disk-failure protection

When defining a disk group, both the number of disks and a disk failure protection level must bespecified.5 The disk failure protection level influences the reserved spare disk storage capacity withinthe disk group. This disk storage capacity is used to replace the space taken by failed physical diskdrives. There are three protection levels, as shown in Table 4.

Table 4.

Protection level Description

None No spare storage capacity can be reserved.

Single Sufficient spare storage capacity can be reserved to replace one physical disk.

Double Sufficient spare storage capacity can be reserved to replace two physical disks.

5Refer to page 8 of the HP white paper, Storage Virtualization and the StorageWorks Enterprise Virtual Array.

6
ftp://ftp.compaq.com/pub/products/storageworks/whitepapers/5982-8671EN.pdfftp://ftp.compaq.com/pub/products/storageworks/whitepapers/5982-8671EN.pdf


7/25

Spare capacity is distributed over all disks within the disk group, and the disk failure protection levelcan be changed after the disk group has been defined.

For smaller disk groups with one physical disk per disk shelf, the single disk failure protection level issufficient in most cases. However, larger disk groups should be defined with double disk failureprotection.

Sequential and random I/O pattern

The HP StorageWorks Enterprise Virtual Array (EVA) controllers continuously analyze the I/O profileon a disk group level. If read access is recognized as a sequential stream by the controller, data isread from the disk into the cache before the actual read operation takes place. In addition, if the HSVcontrollers recognize write operations as being sequential, the main I/O stream to the disk group issplit into multiple sequential streams dedicated to the underlying physical disks so that the targetedphysical disks can write sequentially, at a near-maximum transfer rate.

Separating disk groups with virtual disks that have sequential I/O patterns (database transaction logs)from those that mainly exhibit random or mixed I/O patterns (database data) increases the efficiencyof the mechanisms described. Measurements have shown that random read/write I/O performanceimproves with an increased number of disks in the disk group, whereas purely sequential read orwrite streams are more independent of the number of disks in the disk group. This means, as well, thaenhancing database write performance by separating the I/O patterns comes at the cost of inefficient

disk-space utilization. Moreover, it may actually compete with the optimization of database readperformance.

When configuring an EVA for optimum I/O performance in an SAP Business Suite environment, thekey considerations are the chosen number of disk groups, their size, and the kind of data put onto thegroups. The optimum EVA I/O configuration depends on the amount and type of I/O performed onthe database by the SAP Business Suite application.

Data-availability domains

In terms of data availability, each disk group can be seen as a separate domain. Different diskgroups share resources, such as power, disk shelves, controllers, and Fibre connections, but they

reside on separate groups of physical disks with separate spare disk capacities. Because EVAconfiguration metadata is replicated throughout disk groups, each one can survive as a separateentity.

In SAP database design, it is useful from a data-availability point of view to separate the databasedata from the database transaction logs. Database data can normally be restored from backupmedia, but recent database transaction logs, in many cases, cannot be restored. In other words,database transaction logs shouldin addition to being separated from database datareside on themost robust disk groups. A disk group is at its most robust when it has:

Equal distribution of physical disks over internal arbitrated loop pairs One physical disk per disk shelf

The highest disk failure protection level (spare disk storage capacity)

Because the EVA architecture is based on a modular design, an HP StorageWorks Enterprise VirtualArray can be configured and ordered with a minimum of one disk shelf per HSV controller pair(2C1D), and with a maximum of 27 disk shelves (2C27D) and 324 disks per controller pair. Anentry-level SAP configuration based on the HP StorageWorks Enterprise Virtual Array 4400 with twodual loops can have a maximum of eight disk shelves and 96 drives. To fine-tune a configuration foravailability, performance, and scalability, if the exact growth rate cannot be determined up front, HPrecommends that administrators configure an EVA for an SAP landscape with eight disk shelves perHSV controller pair (2C6D + 2D), as shown in Figure 2. This does not necessarily mean that all

7


8/25

available disk slots must be filled initially. In fact, having free disk slots available for future growth isoften more practical than filling all available disk shelves at the outset and then having to add extrashelves when more disk space is needed, because much less effort is required to add disks into emptyavailable slots than is needed to assemble additional shelves in an existing configuration.

Very large databases (VLDBs)

For very large, multi-terabyte database installations, it is advisable to split the database data area intoseveral disk groups, creating more data-availability domains and ultimately more disk subsystems.

Although this might decrease the overall random read/write I/O performance and efficiency of disk-space utilization, it can decrease restore time should a disk group containing database data be lost.This decision mostly depends on how quickly the restoration can be achieved and how long it can beallowed to take.

Virtual disks

Two Vraid levels are suitable for the virtual disks used in the EVA: Vraid1and Vraid5. Virtual diskswithout redundancy (Vraid0) should never be used in the SAP Business Suite environment.

Vraid1 virtual disks offer the highest levels of data protection, with all data blocks written twice toseparate physical disks within a disk group.

Vraid5 virtual disks offer a balance of speed, size, and redundancy, distributing parity informationon the physical disks within the disk group.

The only comparison between Vraid1 and Vraid5 levels and traditional RAID 1 and RAID 5 levels isthe way in which they deal with redundancy. No further comparisons can be made because the EVAalmost always uses all disks within the disk group for read/write operations, whereas RAID 1 andRAID 5 sets are bound to separate groups of disks per logical unit number (LUN).

Vraid5 virtual disks are more space-efficient because they reserve 20 percent of the reserved diskspace for redundancy, whereas Vraid1 disks need 50 percent of their reserved space.

Vraid1 virtual disks offer higher redundancy, which means that they are less prone to physical diskfailure within the disk group.

Vraid1 virtual disks offer better write performance than Vraid5.In general, Vraid1 is recommended for use with all virtual disks in an SAP Business Suite environment.For installations with large volumes of database data, however, it may be advantageous to use

Vraid5 virtual disks.

Tables 5 and 6 illustrate how SAP and database components should be distributed on different Vraidlevels. The distribution of SAPDATA on Vraid1 is suitable for average-sized production systems,whereas Vraid5 can be used for larger installations.

8


9/25

Table 5. Oracle database

Directories Vraid No. Vdisk

SAP R/3 executable 1

/usr/sap 1

/usr/sap/trans 1

DBMS software 1

/Oracle//920 1

/Oracle//saptrace 1Sapdata MIN 2

/Oracle//sapdata1 1 or 5






Redo logs MIN 1

/Oracle//origlogA 1

/Oracle//origlogB 1

1

/Oracle//mirrlogA7 1

/Oracle//mirrlogB7 1

/Oracle//saparch 1

1

SAPDBA 1

/Oracle//sapcheck 1

/Oracle//sapbackup 1

/Oracle//sapreorg 1

1

Table 6. Microsoft SQL Server database

Directories Vraid No. Vdisk

SAP R/3 executable 1

\usr\sap 1

\usr\sap\trans 1

DBMS software 1

\MSSQL 1

\MSSQLDB 1

\TEMPDB 1

Sapdata MIN 2

\DATA1 1 or 5\DATA2 1 or 5

\DATA3 1 or 5

transaction log 1

\log1 1

6 Not applicable for SAP R/3 4.7 and higher7 When mirroring the origlogs through Vraid1, the usage of the mirrlogs is only reasonable when storing in a different disk groupeventually, on

a different EVAfor availability reasons.

9


10/25

Number of virtual disks

On the EVA3000 and EVA5000, I/O performance tends to improve with a higher number of virtualdisks because a LUN is active on only one HSV controller at one point in time. HP recommendsconfiguring at least two virtual disks for the SAPDATA area so that both HSV controllers can operateto greater efficiency. The use of separate virtual disks for SAPDATA 1/3/5 and SAPDATA 2/4/6 forOracle as well as the DATA areas for SQL Server (Table 6) generally offers a good balance in aMicrosoft Windows environment with a size of up to 400 GB per LUN. In a multi-terabyte UNIXenvironment, there can be more and larger LUNs for the SAPDATA areas. Although a single LUN is

active and visible to an SAP database server now on all host ports of both HSV controllers of the EVA4400, EVA6400, and EVA8400 models,running the database on a single LUN is not recommended

If an SAP database server is configured with more than two active Fibre Channel adapters (FCAs), HPrecommends having at least the same number of virtual disks for the SAPDATA area as the number ofactive FCA ports for the EVA3000 and EVA5000 models where a LUN is visible on the host ports ofone HSV 100/110 controller at one point in time. This may facilitate all available FCA ports in adatabase server to be engaged in parallel.

The SAP database server in the HP storage area network

The EVA3000 and EVA5000 models are connected to servers through a storage area network (SAN)infrastructure, while the EVA4400, EVA6400, and EVA8400 allow, in addition, direct connectivity toa host. The general rules and restrictions of SAN operations, outlined in the actual HP SAN designreference guide and SAN product support tables, fully apply to an EVA configuration for an SAPserver. When planning an EVA configuration, it is necessary to check these tables for actual FibreChannel infrastructure compatibility, as well as for platform or operating system dependencies withFCA drivers and firmware revisions. Access to an EVA through a server using one single FCA issupported (refer to the EVA4400/EVA6400/EVA8400 QuickSpecs). Due to availabilityconsiderations, this approach is recommended only for special configurations such as a dedicatedbackup server, not for an SAP production database. The recommended number of FCAs in an SAPserver is therefore two. The maximum number of FCAs per server is outlined in a servers descriptiontables (found in the QuickSpecs for the product), but only very-high-end SAP database serverconfigurations may experience performance benefits when more than four 4Gb FCAs are used in a

single system. Some SAN configuration characteristics are operating system dependent.

Microsoft Windows

Setting Fibre Channel adapter parameters

With the HBA driver installation on Windows, the latest driver for the QLogic and Emulex-based FibreChannel adapters and their default parameters are installed or refreshed.

The latest version of the Emulex-based FCA drivers sets two performance-related parameters to theactual supported default values: QueueDepth and QueueTarget. For QLogic adapters, the ExecutionThrottle performance parameter is responsible for the number of I/O requests this adapter can haveoutstanding at one point in time. Changing these values toward their maximum using the EmulexHBAnyware or the QLogic SANsurfer utility allows a higher I/O load on the EVA from a single server

system with one or more FCAs. This way, the EVA controllerslike any other storage arraycanbecome highly loaded with outstanding I/Os from a single server.

In an SAP production environment, the database server is the one that needs the most I/O resources.Changing these driver parameter values for a single SAP database server in an EVA-only storageenvironment may be considered, but doing so on an SAP production server is not recommendedwithout first consulting an HP StorageWorks specialist.

10
http://h18006.www1.hp.com/products/storageworks/san/documentation.htmlhttp://h18006.www1.hp.com/products/storageworks/san/documentation.htmlhttp://h18006.www1.hp.com/products/storageworks/san/documentation.htmlhttp://h10025.www1.hp.com/ewfrf/wc/document?lc=en&dlc=en&cc=us&docname=c01677617#N817http://h10025.www1.hp.com/ewfrf/wc/document?lc=en&dlc=en&cc=us&docname=c01677617#N817http://h18006.www1.hp.com/products/storageworks/san/documentation.htmlhttp://h18006.www1.hp.com/products/storageworks/san/documentation.htmlhttp://h18006.www1.hp.com/products/storageworks/san/documentation.html


11/25

Multi-pathing

In the area of multi-pathing under Windows for the EVA3000 and EVA5000, the HP StorageWorksSecure Path software provides failover and load-balancing functionality, whereas the downloadableMPIO Basic DSM failover software provides failover capabilities only.

For the EVA4400, EVA6400, EVA8400, EVA3000, and EVA5000 with active/active firmwarebeyond version 3.110, the full-featured MPIO DSM for Windows has both failover and load-balancing capabilities. Setting load-balancing is achieved by using either the MPIO DSM Managersnap-in for the Microsoft Management console, as shown in Figure 3, or the hpdsm command line

utility.

Figure 3. MPIO DSM Manager load-balancing

Setting one of the four different load-balancing methods from Figure 3 allows a good distribution forsingle and multiple EVA Vdisks to be quickly achieved over the available paths. In lab and SAPcustomer situations, Round Robin (RR) is a good mechanism to start with, providing about 60 to 70percent of the possible capabilities in an EVA configuration. Here it is accepted that LUNs areaccessed eventually via the non-managing HSV controller, causing so-called proxy-reads stressing theEVA mirror ports.

11
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=421494&prodTypeId=18964&prodSeriesId=421492&swLang=8&taskId=135&swEnvOID=1005http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=421494&prodTypeId=18964&prodSeriesId=421492&swLang=8&taskId=135&swEnvOID=1005http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=421494&prodTypeId=18964&prodSeriesId=421492&swLang=8&taskId=135&swEnvOID=1005http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=421494&prodTypeId=18964&prodSeriesId=421492&swLang=8&taskId=135&swEnvOID=1005http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=421494&prodTypeId=18964&prodSeriesId=421492&swLang=8&taskId=135&swEnvOID=1005


12/25

Figure 4. Verify manual load-balancing with no HSV mirror port usage on read operations by EVAPerf

In a large SAP landscape with a single database server having four or more FCAs and, eventually,more than one EVA per production SAP database, spreading the load manually over the availablepaths is the preferable way to achieve greater throughput, as long as the number of availablephysical disks does not become the bottleneck. The goal is to set the path explicitly with either MPIODSM utility and to be sure that no two LUNs have the same access path from the FCA to the EVA hostports until each path is in use at least once. In addition, it is a good idea to spread the load over the

two HSV controllers of an EVA. It is helpful to proof path settings by generating a read load to eachindividual LUN with an I/O generator and then verifying the access path using the EVAPerfmonitoring utility, as shown in Figure 4. Here, a close to 600 MB/second sequential read stream withno mirror port access is seen out of two 2Gb FCAs and two 1Gb FCAs spread over the two HSVs ofan EVA8000. For the configuration shown, this is close to the theoretical maximum of thisconfiguration, clearly limited by the FCA capabilities.

NTFS partition alignment

As referenced in various notes from SAP, Microsoft, and HP, especially in the SAP note 886337, thefact that Windows primary partitions have only 63 hidden sectors while a primary NTFS partitionstarts, by default, at the 64th sector of a logical disk causes misalignment and overhead in any RAIDcontroller, especially for large sequential writes (greater than 64 KB) on RAID5 volumes. It is therefore

a good practice to create a partition under Windows Server 2003 SP1 using the standard diskpartutility and the command:

DISKPART> Create PARTITION PRIMARY align=32

This creates a primary partition of exactly 32,768 bytes (32 KB). To verify the correct alignment of aprimary partition, thewinmsd utility shows the partitions starting offset underComponents/Storage/Disks.

No significant performance improvements have been observed in SAP customer production systemson EVA4x00, EVA6x00, or EVA8x00 models when a partition is reinitialized for alignment purposes

12


13/25

in situations when an I/O bottleneck is suspected. Therefore, it should be seriously consideredwhether to go through a backup/restore situation for re-creation of a partition involving a productiondowntime of a large SAP database when partition alignment is not the definite cause in a situationwhere an I/O bottleneck has to be identified.

HP-UX

In an HP-UX environment, the common usage of the host-based striping capabilities of the LogicalVolume Manager (LVM) are not required for performance reasons when EVA storage is connected,

because the EVA balances all I/O requests of a virtual disk to all physical disk drives that belong tothe disk group of this virtual disk.

The HP-UX system automatically sets the queue depth to the default value of 8. The scsictlcommandallows viewing and changing the queue depth parameter for each device, as shown in the followingexample:

root@:/> /usr/sbin/scsictl -a /dev/rdsk/c12t0d0

immediate_report = 0; queue_depth = 8

root@:/>

root@:/> /usr/sbin/scsictl -m queue_depth=25 a /dev/rdsk/c12t0d0


root@:/>

root@:/> /usr/sbin/scsictl -a /dev/rdsk/c12t0d0


root@:/>

Setting the queue depth is valid only until the next reboot; queue depth must be set during HP-UXstartup for a permanent change.

Multi-pathing with load-balancing for HP-UX is achieved by using the actual version of Secure Path forHP-UX on the EVA3000, EVA5000, EVA4400, EVA6400, and EVA8400.

Data replication tools

The HP white paper, Storage Virtualization and the StorageWorks Enterprise Virtual Array, brieflydescribes the three EVA built-in data replication tools: traditional snapshot, virtually capacity-freesnapshot, and virtually instantaneous snapclone. These data migration and replication tools havebeen refined in the EVA to provide flexibility and data protection. Using these tools, the generaladvantages of virtualization at the controller level can be realized in an SAP Business Suiteenvironment:

Efficient storage management Better utilization of capacity and assetsA dynamic storage environment More effective storage utilization with virtually capacity-free snapshots Immediate access with virtually instantaneous snapclone

A detailed solution implementation description of how to build, for example, a non-disruptive backupsolution based on the EVA data replication tools for SAP Business Suite is beyond the scope of thispaper, but it can be found at HP StorageWorks solutions for SAP.

Sizing the snapshot/snapclone working space

A snapclone and a pre-allocated (traditional) snapshot consume the same amount of physical spaceas the original virtual disk. This additional capacity is consumed during the creation of the snapclone

13
ftp://ftp.compaq.com/pub/products/storageworks/whitepapers/5982-8671EN.pdfhttp://h71028.www7.hp.com/enterprise/cache/231355-0-0-0-121.htmlhttp://h71028.www7.hp.com/enterprise/cache/231355-0-0-0-121.htmlftp://ftp.compaq.com/pub/products/storageworks/whitepapers/5982-8671EN.pdf


14/25

or standard snapshot. The RAID protection level of a snapshot or snapclone is selectable and candiffer from that of the original Vdisk. As shown in Figure 5, before a host-initiated command to writeI/O to a Vdisk A (Step 1) can be completed, the EVA must copy the original, unmodified data from

Vdisk A to the pre-allocated working space of Vsnap A (Step 2) to maintain consistency with theoriginally created snapshot.

Figure 5. Maintain the consistency of a snapshot

The important difference between a traditional snapshot and a snapclone is that, as part of theoperation that creates the snapclone, a background operation is initiated on the EVA that copies thecomplete original Vdisk as fast as transfer rates permit, resulting in two identical independent copies.This means that, at the time of creation, a snapclone bears all the characteristics of a snapshot and isexpected to become an independent clone over time. As long as this process is not completed, thescenario in Figure 5 applies to a snapclone as well as to a snapshot.

A virtually capacity-free snapshot (Vsnap) consumes physical capacity only when new data is written.When the Vsnap is first taken, both the Vsnap and the original Vdisk contain the same data and thusshare the same physical storage. Whenever a block on the original target disk is due to be written

following the initial snapshot operation (Figure 6, Step 1), additional snapshot working space has tobe allocated (Figure 6, Step 2), and the snapshot content is preserved by copying the original data tothe new location (Figure 6, Step 3). The original target virtual disk block is then updated with the newwrite data. If the allocation of additional snapshot working space fails due to a lack of free diskcapacity in the disk group, the Vsnap becomes invalid.

14


15/25

Figure 6. Virtually capacity-free snapshot

In general, therefore, a Vsnap consumes physical capacity in proportion to the rate at which theoriginal target disk is changed. In other words, a Vsnap for a virtual disk that changes at a slow ratemay consume little additional storage, whereas a Vsnap for a virtual disk that is completely rewritten

after the initial snapshot operation may consume the same physical capacity as the original virtualdisk.

In an SAP environment, it has been observed that with high, random small-block changes within thetotal database space, the initial growth rate of the snapshot working area is exponential and cannotbe calculated beforehand. It is thus recommended that users allow 30 to 50 percent of the original

Vdisk disk space for the Vsnap working area, with additional free disk slots in case of higher spacerequirements.

In addition, it is recognized that end-of-month, end-of-quarter, and end-of-year processes typicallymodify considerably more information in the database than normal daily jobs, and Vsnap canconsume more physical capacity at these times.

It is the first write operation on any given block following the snapshot creation that may consumephysical storage and EVA resources to fill this space. Thereafter, any later write operations simplyoverwrite the old dataalthough the Vsnap data itself is unaffected, having already been preservedin the allocated space.

15


16/25

Table 7 summarizes the space requirements for the different data replication tools on the EVA in anSAP environment.

Table 7.

Data replication tool Space requirement of the original Vdisk (percentage)

Fully allocated (traditional) 100 percentSnapshot

Virtually capacity-free (on demand) Initial 30 to 50 percent

Snapclone Virtually instantaneous 100 percent

Performance considerations for snapshot/snapclone operations

With the introduction of the EVA4400, EVA6400, and EVA8400 and of version 4 of the EVA3000and EVA5000, a three-phase-snapclone mechanism has been made available to shift the introductionof multi-snapclone scenarios in SAP production environments to higher boundaries. In such a scenarioa snapclone is not deleted before a new instance is created but converted into an empty container. Anew instance of a snapclone is then created by reusing this pre-allocated container after havingchanged the cache policy to write-through for this particular Vdisk until the snapclone creation iscompleted. This saves the effort of deleting the old snapclone and re-allocating space for thesnapclone to be created.

Depending on the available disk configuration and how frequently host-I/O operations occur duringthe snapclone-replication process, transfer rates may vary between 6 and 9 GB per minute for asingle snapclone. The fastest snapclone operations of up to 16 GB per minute can be expected whencreating a pre-allocated snapclone into a different disk group from the original Vdisk, having a rangeof 60 to 80 disks per disk group. Having the Vdisks that contain SAPDATA database files equallyserved by the two HSV controllers enables parallel snapclone creation, because it is the HSVcontroller serving the LUN of a Vdisk that is responsible for snapclone creation. In case higher levelsof snapclone performance are required for multi-terabyte SAP databases to be cloned, there is alwaysthe option of distributing the SAP database over more than one HSV controller pair, as the HSVcontroller becomes the limiting factor once there are sufficient disk drives available.

The Vraid level of the source Vdisk or of the snapclone to be created has no major impact onsnapclone creation performance; however, Vraid1 is able to maintain a higher transaction load ofongoing SAP I/O requests than Vraid5. To reduce the effect of a snapclone copy operation onongoing SAP I/O requests, it is recommended that snapclone copies be created at a time when fewerhost write I/O operations are likely to occur.

MirrorClone replication

With XCS 6.110 for the EVA4x00, EVA6x00, and EVA8x00, MirrorClone replication mechanismanew capability complementing existing snapclone functionalityhas been introduced. Here, a user isallowed to pre-normalize a mirror (as shown in Figure 7) and then fracture the mirror to create aninstantaneous byte-for-byte replica while the SAP database is in a file consistent state. There is nolonger any need to wait for snapclone/snapshot completion in a replication-based backup scenario;

the fracture can happen any time a MirrorClone is in normal state.

16


17/25

Figure 7. Initial synchronization of MirrorClone

A delta resync with the MirrorClone feature accelerates the time required to resynchronize the sourceVdisk with the MirrorClone copy of an SAP database improved performance. Figure 8 shows the twovolumes of a detached MirrorClone, each volume having been written on both sides. In this state, aresync of the MirrorClone target can be initiated, which results in data at both volumes being

identical to the MirrorClone source.

Figure 8. MirrorClone in fractured state before resync

An instant restore from a MirrorClone allows SAP customers to quickly recover the Vdisks of theproduction database from a normalized snapclone and, under XCS 6, from a MirrorClone.

Performance tests in an SAP environment with a database larger than .5 TB distributed over fourVdisks in RAID1 have shown that once a MirrorClone has been fractured, there is less than fivepercent overhead to maintain the delta table if the change/write rate is between 15 to 20 percent(usual for many SAP customers during SAP dialog times). In this case, the required resync time isroughly 10 to 15 percent of the initial MirrorClone creation time. In the SAP test scenario, the initial

MirrorClone creation within a single disk group of 72 disk drives (10,000 rpm) takes 40 minutes.

17


18/25

Configuration examples

In this section, some layout examples for SAP Business Suite installations on the EVA are described,and the advantages and disadvantages of each configuration are discussed. These configurationexamples are based on observations made during SAP test configuration efforts with variousHP StorageWorks Enterprise Virtual Array models.

One-disk group configuration

All SAP and database components are stored in the same disk group (see Figure 9), as are additionalSAP installations.

This configuration has the following characteristics:

Most efficient use of disk space Lowest administrative effort Highest possible read I/O (depending on the size of the disk group) Balanced but not best possible write I/O (depending on the number of disks in the disk group) Lower data availability

Figure 9. One-disk group configuration

18


19/25

Multiple installations can be implemented in the same manner and on the same disk group withoutsplitting it. Database data and transaction logs reside on the same disk group; therefore, a loss of thisdisk group in the extremely rare event of multiple disk failures or a disk enclosure malfunction canrequire restoration of all SAP database components from backup media. Any database transactionlogs not backed up to separate media before the loss of the disk group cannot be used for point-in-time recovery.

This configuration type has been seen at many SAP customer environments where entry-level EVAconfigurations (ranging up to 48 disk drives) are in place.

Two-disk group configuration

A two-disk group configuration can comprise either one small and one large disk group (Figure 10) ortwo approximately equal-sized disk groups (Figure 11). The main difference between these twoconfigurations is in the way in which multiple SAP installations can be distributed.

Figure 10. Two-disk group configuration with both a small and a large disk group

The smaller disk group contains the database transaction logs, SAP, and database executables.Optionally, it can also contain operating system virtual disks. The second, larger disk group containsdatabase data and the original online (Oracle) database transaction logs. Putting the Oracle redo logfiles and database data together in this way validates the integrity of the database in case the smallerdisk group is lost. The smaller disk group can be used primarily for sequential writing to the mirroredonline and archived redo logs.

19


20/25

For Oracle and SQL Server installations, these possibilities are expected to appear as follows:

Table 8.

RDBMS Disk group SAP database component

1 Mirrored online, archived redo logs, SAP/Oracle executablesOracle

2 Database data, original online redo logs

1 Transaction log file, SQL executablesSQL Server

2 MASTER, MSDB, TEMPDB, database data

Multiple installations can be carried out in the same wayand on the same disk groupswithoutsplitting them further. The properties of the configurations described can be summarized as follows:

Good read I/O (depending on the number of disks in the large disk group) Good write I/O (depending on number of disks in both disk groups) Good data availability Less efficient use of disk space on the smaller disk group

As mentioned earlier, the remaining space in the smaller disk group with higher-capacity drives canalso be used for database backups, using the EVA snapclone capability to implement a non-disruptivebackup solution based on the EVA data replication tools. A detailed solution can be found atHP StorageWorks solutions for SAP.

Crossed installations

In an EVA configuration for crossed SAP Business Suite installations, multiple database instancesare split into two groups based on their I/O properties. The database components of these twoinstallation groups are distributed among the disk groups to enhance use of disk capacity, I/Operformance, and data availability.

Most SAP customers have system landscapes containing multiple databases. A classic example isthe SAP Business Suite transport landscape, which includes development systems (DEV); training,

consolidation, and test systems (CON); and productive systems (PROD). Because these systems rarelyhave simultaneously high I/O rates, they can be cross-installed across two disk groups ofapproximately the same size.

20
http://h71028.www7.hp.com/enterprise/cache/231355-0-0-0-121.htmlhttp://h71028.www7.hp.com/enterprise/cache/231355-0-0-0-121.html


21/25

Figure 11. Two-disk group configuration with two approximately equal-sized disk groups

In this example, Figure 11 illustrates the way in which the Oracle RDBMS can be used to mirroronline database transaction logs across disk groups so that, in the event of any disk group failure, aconsistent point-in-time database recovery is possible. Note that, because Microsoft SQL Server doesnot offer this feature, HP does not recommend using this configuration for the SQL Server application.

A sample configuration for an Oracle database is as follows:

Table 9.

RDBMS Disk group SAP database component

Oracle 1 PROD: mirrored online and archived redo logs, SAP and Oracle executables

CON/DEV: database data, original online redo logs

2 PROD: database data, original online redo logs

CON/DEV : mirrored online and archived redo logs, SAP and Oracle executables

At times of high write I/O activity on the PROD system and typically low I/O rates on the CON/DEVsystem, the PROD system can use the disks in disk group 1 for sequential access. Disk space can stillbe used efficiently because of the data volume of CON/DEV residing on disk group 1. To improvedata availability, transaction logs of all installations are separated from their database data.

The properties of these configurations can be summarized as follows:

Efficient use of disk space in both disk groups Good read I/O (depending on the number of disks in both disk groups) Good write I/O (depending on the number of disks in both disk groups and on the amount of

parallel I/O activity on CON/DEV and PROD)

Good data availability for multiple installationsIn the event that one disk group is lost, it is not necessary to restore all of the database data in thelandscape.

21


22/25

Appendix

This appendix briefly describes several configuration examples using the HP StorageWorks EnterpriseVirtual Array (EVA) in various SAP customer environments.

A: Sample customer SAP landscape EVA configuration

The configuration in Figure 12 shows a three-group SAP landscape configuration that spreads a total

of 11 database server SAP instances over 82 disk drives with development, test, and productionsystems.

Figure 12. Three-group SAP landscape configuration

22


23/25


24/25

To characterize the performance requirements for this SAP multi-instance configuration, the mainproduction instance produces, on average, 270 MB of archived redo-log information every fiveminutes. Within 24 hours, approximately 200 Oracle-archived redo-logs are generated, transferred,and applied at the standby site, with an average apply time of 50 seconds per archived redo log.

When I/O of all SAPDATA areas for this particular SAP instance is measured at the operating-systemlevel, it is apparent that, on average, 2,000 I/O operations per second are carried out at abandwidth of 25 MB/ssaturating neither the HSV controllers nor the number of available diskdrives. Thus, in terms of the environments main SAP instance, the configuration is driven by capacity

and not by performance.

Snapshot performance and space requirements

The backup scenario in this customer configuration is as follows:

1. Stop the Oracle standby database.2. Create a virtually capacity-free snapshot on the EVA for each SAP data area.3. Restart the standby database and continue applying archived redo logs.4. Mount the snapshots and back up the database to tape.

A detailed solution implementation description of how to build, for example, a non-disruptive backupsolution based on the EVA data-replication tools for SAP Business Suite is beyond the scope of this

paper, but detailed solutions are available at HP Business Continuity and Availability Solutions forSAP. The two following graphs (Figure 14) indicate how virtually capacity-free EVA snapshots(Vsnaps) behave in an Oracle standby database configuration.

Figure 14. EVA snapshot area space allocation characterization for an Oracle standby database

Applying archived redo-log files immediately after the snapshots have been created forces the HSVcontrollers to maintain a consistent view of the database snapshot and fill the snapshot area withoriginal data blocks that can be changed by applying the redo logs. This is called the copy-on-first-write effect.

24
http://h71028.www7.hp.com/enterprise/cache/377131-0-0-0-121.htmlhttp://h71028.www7.hp.com/enterprise/cache/377131-0-0-0-121.htmlhttp://h71028.www7.hp.com/enterprise/cache/377131-0-0-0-121.htmlhttp://h71028.www7.hp.com/enterprise/cache/377131-0-0-0-121.htmlhttp://h71028.www7.hp.com/enterprise/cache/377131-0-0-0-121.htmlhttp://h71028.www7.hp.com/enterprise/cache/377131-0-0-0-121.htmlhttp://h71028.www7.hp.com/enterprise/cache/377131-0-0-0-121.html


25/25

For more information

HP & SAP alliancewww.hp.com/go/sap

HP data storage solutionswww.hp.com/go/storage

HP StorageWorks Enterprise Virtual Array configuration best practiceswhite paper

http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA1-5661ENW.pdfHP business continuity and availability solutions for SAPhttp://h71028.www7.hp.com/enterprise/cache/377131-0-0-0-121.html

HP StorageWorks Enterprise Backup Solutionoverview and featureswww.hp.com/go/ebs

HP storage array systems white papershttp://h18006.www1.hp.com/storage/arraywhitepapers.html

Booting Windows Server 2003 for Itanium-based systems from a storage area networkapplicationnoteshttp://h20000.www2.hp.com/bc/docs/support/SupportManual/c00193929/c00193929.pdf

HP supportreference librarycustomer advisories for the EVA

http://www5.itrc.hp.com/service/cki/enterService.doStorage virtualization and the EVAftp://ftp.compaq.com/pub/products/storageworks/whitepapers/5982-8671EN.pdf

HP SAN product support, design reference guides

ftp://ftp.compaq.com/pub/products/storageworks/techdoc/san

SPC benchmark 1 executive summarywww.storageperformance.org/results/

Oracle links

Oracle Technology Networkhttp://otn.oracle.com/index.html

Microsoft links

www.microsoft.com/

SAP links

SAP documentation libraryhttp://help.sap.com/

SAP OSS note 515014 SAP Business Suite on the Enterprise Virtual Arrayhttp://service.sap.com/notes

To help us improve our documents, please provide feedback at www.hp.com/solutions/feedback

Copyright 2008, 2009 Hewlett-Packard Development Company, L.P. Theinformation contained herein is subject to change without notice. The onlywarranties for HP products and services are set forth in the express warrantystatements accompanying such products and services. Nothing herein should beconstrued as constituting an additional warranty. HP shall not be liable for technicalor editorial errors or omissions contained herein.

Itanium is a trademark of Intel Corporation in the United States and other countries.Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.Oracle is a registered trademark of Oracle Corporation and/or its affiliates. UNIX
http://www.hp.com/go/saphttp://www.hp.com/go/saphttp://www.hp.com/go/storagehttp://www.hp.com/go/storagehttp://www.hp.com/go/ebshttp://www.storageperformance.org/results/http://www.microsoft.com/http://www.hp.com/solutions/feedbackhttp://www.hp.com/solutions/feedbackhttp://www.microsoft.com/http://www.storageperformance.org/results/http://www.hp.com/go/ebshttp://www.hp.com/go/storagehttp://www.hp.com/go/sap

6 p6000 sap business suite

Documents