HP StorageWorks Enterprise Virtual Array configuration guide for SAP Business Suite

Table of contents Executive summary............................................................................................................................... 2 Overview............................................................................................................................................ 2 EVA6400/EVA8400 ........................................................................................................................... 2

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

1010101313131616

18181920

22222324

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

Executive summary Good distribution of SAP components on HP StorageWorks Enterprise Virtual Array (EVA) storage enables 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 approach enhances 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 depends on customer-specific workloads, individual performance, and availability requirements. The proposed recommendations in this document include sample configurations for different SAP landscapes.

Overview The HP StorageWorks EVA4400, EVA6400, and EVA8400 disk subsystems are the latest HP storage offerings 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/O performance, and the efficient use of disk storage capacity.

The EVA6400 and EVA8400 models are the newest in a line of successful EVAs, built on the EVAx400 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 comply with SAP requirements based on version 9.5 of the EVA4400, EVA6400, and EVA8400 and version 6.110 of the EVA4100/EVA6100/EVA8100 firmware XCS.

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

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 and Business Copy

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

2

Figure 1. HP StorageWorks EVA6400

Feature comparison When relating the configurations recommended in this document for SAP and EVA environments, please refer to the feature comparison shown in Table 2 for proper sizing and storage layout on the EVA4400, EVA6400, or EVA8400.

Table 2.

Feature EVA4400 EVA6400 EVA8400

Controller model HSV300 HSV400 HSV450

Coche (per controller pair) 4 GB 8 GB 14 or 22 GB

Fibre Channel host ports 4 8 8

FC host port speed 4 GB 4 GB 4 GB

Fibre Channel device ports 4 8 12

Device path aggregate bandwidth 16 GB 24 GB 48 GB

Switched device shelves 1 to 8 2 to 18 3 to 27

Maximum supported disks (FC/FATA)) 96 216 324

3

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 Suite environment. Other recommendations and up-to-date EVA management information are based on actual customer advisories for the EVA.

Physical disks For several years, many general trends have been observed in the storage industry. With respect to database 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) disk

drives 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 storage virtualization technology used in the EVA addresses these issues by sharing all physical disk capabilities in a disk group among all virtual disks in the group.2 However, I/O measurements on the EVA show that random I/O operations (read operations) in a small block size still depend heavily on the number of physical disk drives belonging to the disk group, clearly revealing a random I/O bottleneck on the total number of disk drives within smaller disk groups. A virtual disk on a disk group built from 32 physical 146 GB disk drives has, in general, lower I/O capabilities than one built from 64 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 rpm disk drives in relation to 10,000 rpm disk drivesa direct consequence of faster seek times and rotational speedsbut the I/O capabilities within a 64-disk group built from 36 GB, 10,000-rpm disk drives 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 it possible to enhance virtual disk performance by dynamically adding further disk drives to the group without 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 storage configuration for the EVA primarily for I/O performance rather than for pure data capacity. A greater number of spindles within a configuration generally reduces the risk of I/O bottlenecks on the disk drives within disk groups. To achieve a reasonable balance between disk capacity and I/O performance based on the number of available spindles, HP therefore recommends planning for smaller, 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

The FATA disks specified for use in the EVA are high-capacity, lower-cost, lower-performance drives recommended for near-online usage such as Rapid Backup3 configurations, and are not intended as replacements for the standard high-performance drives in an SAP environment requiring good random access performance and nearly continuous operations. There is nothing that speaks against the usage of FATA drives for SAP quality assurance and development systems, possibly generated out of an SAP production server with EVA local replication4 capabilities.

Disk groups The key advantage of the EVA is its capability to virtualize multiple physical disk drives into single block of disk space. Any administrator configuring EVA disk groups for SAP Business Suite must bear in mind that defining each additional disk group slowly diminishes the impact and advantages of the virtualization technology. On the other hand, a greater number of disk groups does allow for a higher degree 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 tends to make the use of disk storage capacity less efficient, but it also increases data availability related to single or multiple SAP instances per EVA. I/O performance depends on the number of physical disks in 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 environment and provide general recommendations regarding EVA configuration:

The number of disk groups should be kept to a minimum. The maximum number of disk groups per EVA 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-optimization algorithms to work at optimum levels.

Disk groups should be sized such that they have a good margin of unreserved space in addition to their spare storage capacity. Management flexibility improves significantly as free disk group storage 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 Group Properties 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 nine arbitrated loops, as shown in Figure 2 (only four loops are shown). Note that this is a schematic figure of the EVA; it is not a detailed configuration drawing showing the required loop switches for some EVA5000, EVA6000, and EVA8000 configurations. Many hardware and software improvements have been introduced with the EVA4400, EVA6400, and EVA 8400 models without compromising compatibility with previous EVA models. Two important enhancements for scaling out in larger SAP production environments are the availability of two mirror ports and the additional four host ports in the EVA6400 and EVA8400.

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

5

Two redundant loops (loop pair 2) serve the upper part of the cabinet; an additional two redundant loops (loop pair 1) serve the lower part. To facilitate equal distribution over the two loop pairs, the disks in a disk group should be split equally over the two parts. To reduce the risk of virtual disk and disk 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 disk shelves as possible, with the lowest possible number of disks used on a single shelf. Each subsequent disk 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 this rule and builds disk groups vertically. In addition, it is possible to allocate specific disks manually to that new group by ungrouping the unwanted disk drives and specifying the desired ones. Other disk drives 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 be specified.5 The disk failure protection level influences the reserved spare disk storage capacity within the disk group. This disk storage capacity is used to replace the space taken by failed physical disk drives. 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.

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

6

Spare capacity is distributed over all disks within the disk group, and the disk failure protection level can 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 is sufficient in most cases. However, larger disk groups should be defined with double disk failure protection.

Sequential and random I/O pattern The HP StorageWorks Enterprise Virtual Array (EVA) controllers continuously analyze the I/O profile on a disk group level. If read access is recognized as a sequential stream by the controller, data is read from the disk into the cache before the actual read operation takes place. In addition, if the HSV controllers recognize write operations as being sequential, the main I/O stream to the disk group is split into multiple sequential streams dedicated to the underlying physical disks so that the targeted physical 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 efficiency of the mechanisms described. Measurements have shown that random read/write I/O performance improves with an increased number of disks in the disk group, whereas purely sequential read or write streams are more independent of the number of disks in the disk group. This means, as well, that enhancing 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 read performance.

When configuring an EVA for optimum I/O performance in an SAP Business Suite environment, the key considerations are the chosen number of disk groups, their size, and the kind of data put onto the groups. The optimum EVA I/O configuration depends on the amount and type of I/O performed on the 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 disk groups 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 EVA configuration metadata is replicated throughout disk groups, each one can survive as a separate entity.

In SAP database design, it is useful from a data-availability point of view to separate the database data from the database transaction logs. Database data can normally be restored from backup media, 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 the most 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 Virtual Array 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. An entry-level SAP configuration based on the HP StorageWorks Enterprise Virtual Array 4400 with two dual loops can have a maximum of eight disk shelves and 96 drives. To fine-tune a configuration for availability, performance, and scalability, if the exact growth rate cannot be determined up front, HP recommends that administrators configure an EVA for an SAP landscape with eight disk shelves per HSV controller pair (2C6D + 2D), as shown in Figure 2. This does not necessarily mean that all

7

available disk slots must be filled initially. In fact, having free disk slots available for future growth is often more practical than filling all available disk shelves at the outset and then having to add extra shelves when more disk space is needed, because much less effort is required to add disks into empty available 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 into several 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 be allowed to take.

Virtual disks Two Vraid levels are suitable for the virtual disks used in the EVA: Vraid1 and Vraid5. Virtual disks without 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 to separate physical disks within a disk group.

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

The only comparison between Vraid1 and Vraid5 levels and traditional RAID 1 and RAID 5 levels is the way in which they deal with redundancy. No further comparisons can be made because the EVA almost always uses all disks within the disk group for read/write operations, whereas RAID 1 and RAID 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 disk space 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 disk failure 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 Vraid levels. The distribution of SAPDATA on Vraid1 is suitable for average-sized production systems, whereas Vraid5 can be used for larger installations.

8

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 1

Sapdata MIN 2

/Oracle//sapdata1 1 or 5

/Oracle//sapdata2 1 or 5

/Oracle//sapdata3 1 or 5

/Oracle//sapdata4 1 or 5

/Oracle//sapdata5 6 1 or 5

/Oracle//sapdata66 1 or 5

Redo logs MIN 1

/Oracle//origlogA 1

/Oracle//origlogB 1

1

/Oracle//mirrlogA 7 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 higher 7 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

Number of virtual disks On the EVA3000 and EVA5000, I/O performance tends to improve with a higher number of virtual disks because a LUN is active on only one HSV controller at one point in time. HP recommends configuring at least two virtual disks for the SAPDATA area so that both HSV controllers can operate to greater efficiency. The use of separate virtual disks for SAPDATA 1/3/5 and SAPDATA 2/4/6 for Oracle as well as the DATA areas for SQL Server (Table 6) generally offers a good balance in a Microsoft Windows environment with a size of up to 400 GB per LUN. In a multi-terabyte UNIX environment, 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 EVA 4400, 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), HP recommends having at least the same number of virtual disks for the SAPDATA area as the number of active FCA ports for the EVA3000 and EVA5000 models where a LUN is visible on the host ports of one HSV 100/110 controller at one point in time. This may facilitate all available FCA ports in a database 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 to a host. The general rules and restrictions of SAN operations, outlined in the actual HP SAN design reference guide and SAN product support tables, fully apply to an EVA configuration for an SAP server. When planning an EVA configuration, it is necessary to check these tables for actual Fibre Channel infrastructure compatibility, as well as for platform or operating system dependencies with FCA drivers and firmware revisions. Access to an EVA through a server using one single FCA is supported (refer to the EVA4400/EVA6400/EVA8400 QuickSpecs). Due to availability considerations, this approach is recommended only for special configurations such as a dedicated backup server, not for an SAP production database. The recommended number of FCAs in an SAP server is therefore two. The maximum number of FCAs per server is outlined in a servers description tables (found in the QuickSpecs for the product), but only very-high-end SAP database server configurations 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 Fibre Channel adapters and their default parameters are installed or refreshed.

The latest version of the Emulex-based FCA drivers sets two performance-related parameters to the actual supported default values: QueueDepth and QueueTarget. For QLogic adapters, the Execution Throttle performance parameter is responsible for the number of I/O requests this adapter can have outstanding at one point in time. Changing these values toward their maximum using the Emulex HBAnyware 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 arraycan become 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 storage environment may be considered, but doing so on an SAP production server is not recommended without first consulting an HP StorageWorks specialist.

10

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

For the EVA4400, EVA6400, EVA8400, EVA3000, and EVA5000 with active/active firmware beyond 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 Manager snap-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 for single and multiple EVA Vdisks to be quickly achieved over the available paths. In lab and SAP customer situations, Round Robin (RR) is a good mechanism to start with, providing about 60 to 70 percent of the possible capabilities in an EVA configuration. Here it is accepted that LUNs are accessed eventually via the non-managing HSV controller, causing so-called proxy-reads stressing the EVA mirror ports.

11

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 available paths is the preferable way to achieve greater throughput, as long as the number of available physical disks does not become the bottleneck. The goal is to set the path explicitly with either MPIO DSM utility and to be sure that no two LUNs have the same access path from the FCA to the EVA host ports 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 each individual LUN with an I/O generator and then verifying the access path using the EVAPerf monitoring utility, as shown in Figure 4. Here, a close to 600 MB/second sequential read stream with no mirror port access is seen out of two 2Gb FCAs and two 1Gb FCAs spread over the two HSVs of an EVA8000. For the configuration shown, this is close to the theoretical maximum of this configuration, 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, the fact that Windows primary partitions have only 63 hidden sectors while a primary NTFS partition starts, by default, at the 64th sector of a logical disk causes misalignment and overhead in any RAID controller, 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 diskpart utility 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 a primary partition, the winmsd utility shows the partitions starting offset under Components/Storage/Disks.

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

12

in situations when an I/O bottleneck is suspected. Therefore, it should be seriously considered whether to go through a backup/restore situation for re-creation of a partition involving a production downtime of a large SAP database when partition alignment is not the definite cause in a situation where 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 Logical Volume 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 to the disk group of this virtual disk.

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

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

immediate_report = 0; queue_depth = 25

root@:/>

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

immediate_report = 0; queue_depth = 25

root@:/>

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

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

Data replication tools The HP white paper, Storage Virtualization and the StorageWorks Enterprise Virtual Array, briefly describes the three EVA built-in data replication tools: traditional snapshot, virtually capacity-free snapshot, and virtually instantaneous snapclone. These data migration and replication tools have been refined in the EVA to provide flexibility and data protection. Using these tools, the general advantages of virtualization at the controller level can be realized in an SAP Business Suite environment:

Efficient storage management Better utilization of capacity and assets A 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 backup solution based on the EVA data replication tools for SAP Business Suite is beyond the scope of this paper, 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 space as the original virtual disk. This additional capacity is consumed during the creation of the snapclone

13

or standard snapshot. The RAID protection level of a snapshot or snapclone is selectable and can differ from that of the original Vdisk. As shown in Figure 5, before a host-initiated command to write I/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 the originally 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 the operation that creates the snapclone, a background operation is initiated on the EVA that copies the complete 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 is expected to become an independent clone over time. As long as this process is not completed, the scenario 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 thus share 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 to be allocated (Figure 6, Step 2), and the snapshot content is preserved by copying the original data to the new location (Figure 6, Step 3). The original target virtual disk block is then updated with the new write data. If the allocation of additional snapshot working space fails due to a lack of free disk capacity in the disk group, the Vsnap becomes invalid.

14

Figure 6. Virtually capacity-free snapshot

In general, therefore, a Vsnap consumes physical capacity in proportion to the rate at which the original target disk is changed. In other words, a Vsnap for a virtual disk that changes at a slow rate may 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 virtual disk.

In an SAP environment, it has been observed that with high, random small-block changes within the total database space, the initial growth rate of the snapshot working area is exponential and cannot be 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 space requirements.

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

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

15

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

Table 7.

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

Fully allocated (traditional) 100 percent Snapshot

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 EVA3000 and EVA5000, a three-phase-snapclone mechanism has been made available to shift the introduction of multi-snapclone scenarios in SAP production environments to higher boundaries. In such a scenario, a snapclone is not deleted before a new instance is created but converted into an empty container. A new instance of a snapclone is then created by reusing this pre-allocated container after having changed the cache policy to write-through for this particular Vdisk until the snapclone creation is completed. This saves the effort of deleting the old snapclone and re-allocating space for the snapclone to be created.

Depending on the available disk configuration and how frequently host-I/O operations occur during the snapclone-replication process, transfer rates may vary between 6 and 9 GB per minute for a single snapclone. The fastest snapclone operations of up to 16 GB per minute can be expected when creating a pre-allocated snapclone into a different disk group from the original Vdisk, having a range of 60 to 80 disks per disk group. Having the Vdisks that contain SAPDATA database files equally served by the two HSV controllers enables parallel snapclone creation, because it is the HSV controller serving the LUN of a Vdisk that is responsible for snapclone creation. In case higher levels of snapclone performance are required for multi-terabyte SAP databases to be cloned, there is always the option of distributing the SAP database over more than one HSV controller pair, as the HSV controller 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 on snapclone creation performance; however, Vraid1 is able to maintain a higher transaction load of ongoing SAP I/O requests than Vraid5. To reduce the effect of a snapclone copy operation on ongoing SAP I/O requests, it is recommended that snapclone copies be created at a time when fewer host write I/O operations are likely to occur.

MirrorClone replication With XCS 6.110 for the EVA4x00, EVA6x00, and EVA8x00, MirrorClone replication mechanisma new capability complementing existing snapclone functionalityhas been introduced. Here, a user is allowed to pre-normalize a mirror (as shown in Figure 7) and then fracture the mirror to create an instantaneous byte-for-byte replica while the SAP database is in a file consistent state. There is no longer 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

Figure 7. Initial synchronization of MirrorClone

A delta resync with the MirrorClone feature accelerates the time required to resynchronize the source Vdisk with the MirrorClone copy of an SAP database improved performance. Figure 8 shows the two volumes of a detached MirrorClone, each volume having been written on both sides. In this state, a resync 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 the production 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 four Vdisks in RAID1 have shown that once a MirrorClone has been fractured, there is less than five percent 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 is roughly 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

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 configuration examples are based on observations made during SAP test configuration efforts with various HP 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 additional SAP 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

Multiple installations can be implemented in the same manner and on the same disk group without splitting it. Database data and transaction logs reside on the same disk group; therefore, a loss of this disk group in the extremely rare event of multiple disk failures or a disk enclosure malfunction can require restoration of all SAP database components from backup media. Any database transaction logs 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 EVA configurations (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) or two approximately equal-sized disk groups (Figure 11). The main difference between these two configurations 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 contains database data and the original online (Oracle) database transaction logs. Putting the Oracle redo log files and database data together in this way validates the integrity of the database in case the smaller disk group is lost. The smaller disk group can be used primarily for sequential writing to the mirrored online and archived redo logs.

19

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 executables Oracle

2 Database data, original online redo logs

1 Transaction log file, SQL executables SQL Server

2 MASTER, MSDB, TEMPDB, database data

Multiple installations can be carried out in the same wayand on the same disk groupswithout splitting 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 can also be used for database backups, using the EVA snapclone capability to implement a non-disruptive backup solution based on the EVA data replication tools. A detailed solution can be found at HP StorageWorks solutions for SAP.

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

Most SAP customers have system landscapes containing multiple databases. A classic example is the SAP Business Suite transport landscape, which includes development systems (DEV); training, consolidation, and test systems (CON); and productive systems (PROD). Because these systems rarely have simultaneously high I/O rates, they can be cross-installed across two disk groups of approximately the same size.

20

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 mirror online database transaction logs across disk groups so that, in the event of any disk group failure, a consistent point-in-time database recovery is possible. Note that, because Microsoft SQL Server does not 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/DEV system, the PROD system can use the disks in disk group 1 for sequential access. Disk space can still be used efficiently because of the data volume of CON/DEV residing on disk group 1. To improve data 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 installations

In the event that one disk group is lost, it is not necessary to restore all of the database data in the landscape.

21

Appendix This appendix briefly describes several configuration examples using the HP StorageWorks Enterprise Virtual 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 production systems.

Figure 12. Three-group SAP landscape configuration

22

B: Four-disk group high-end configuration with snapshot concept This configuration (Figure 13), using a four-disk group approach, has been implemented at a large SAP multi-instance retail site that uses two EVAs in an SAP Oracle standby-database environment.

Figure 13. Four-disk group high-end configuration with snapshot concept

In this instance, Oracle-archived redo-log information is shipped by way of Oracle functionality over IP from EVA1 at a production site to EVA2 at a standby data center. The two EVAs are equally configured in terms of disk size and number of disk groups (four). The difference is that EVA2 at the standby site has more disk space configured to allow use of the EVA snapshot mechanism for backup purposes.

The SAP components are spread over the four disk groups, using different Vraid levels with 400 GB LUN size for the sapdata1 to sapdata8 areas, as shown in Table 10 for the main production instance. The nine remaining SAP instances residing on this EVA are laid out the same way, sharing the same disk groups.

Table 10.

Disk group Database layout of the main SAP instance Vraid

1 Original online redo logs, SAP/Oracle executables 1

2 Archived redo logs 5

2 Mirrored online redo logs 1

3 sapdata1, sapdata3, sapdata5, sapdata7 5

4 sapdata2, sapdata4, sapdata6, sapdata8 5

23

To characterize the performance requirements for this SAP multi-instance configuration, the main production instance produces, on average, 270 MB of archived redo-log information every five minutes. 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-system level, it is apparent that, on average, 2,000 I/O operations per second are carried out at a bandwidth of 25 MB/ssaturating neither the HSV controllers nor the number of available disk drives. 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 backup solution 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 for SAP. 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 HSV controllers to maintain a consistent view of the database snapshot and fill the snapshot area with original data blocks that can be changed by applying the redo logs. This is called the copy-on-first-write effect.

24

For more information HP & SAP alliance www.hp.com/go/sap HP data storage solutions www.hp.com/go/storage HP StorageWorks Enterprise Virtual Array configuration best practiceswhite paper http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA1-5661ENW.pdf HP business continuity and availability solutions for SAP http://h71028.www7.hp.com/enterprise/cache/377131-0-0-0-121.html HP StorageWorks Enterprise Backup Solutionoverview and features www.hp.com/go/ebs HP storage array systems white papers http://h18006.www1.hp.com/storage/arraywhitepapers.html Booting Windows Server 2003 for Itanium-based systems from a storage area networkapplication notes http://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.do Storage virtualization and the EVA ftp://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 summary www.storageperformance.org/results/

Oracle links Oracle Technology Network http://otn.oracle.com/index.html

Microsoft links www.microsoft.com/

SAP links SAP documentation library http://help.sap.com/ SAP OSS note 515014 SAP Business Suite on the Enterprise Virtual Array http://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. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

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 is a registered trademark of The Open Group.

4AA0-6011ENW, Rev. 8, March 2009

0BExecutive summary1BOverview2BEVA6400/EVA84007BFeature comparison

3BGeneral recommendations8BPhysical disks9BDisk groups10BInternal arbitrated loops11BDisk-failure protection12BSequential and random I/O pattern13BData-availability domains24BVery large databases (VLDBs)

14BVirtual disks25BNumber of virtual disks

15BThe SAP database server in the HP storage area network26BMicrosoft Windows33BSetting Fibre Channel adapter parameters34BMulti-pathing35BNTFS partition alignment

27BHP-UX

16BData replication tools28BSizing the snapshot/snapclone working space29BPerformance considerations for snapshot/snapclone operations30BMirrorClone replication

4BConfiguration examples17BOne-disk group configuration18BTwo-disk group configuration 31BCrossed installations

5BAppendix19BA: Sample customer SAP landscape EVA configuration20BB: Four-disk group high-end configuration with snapshot concept32BSnapshot performance and space requirements

6BFor more information 21BOracle links22BMicrosoft links 23BSAP links