Executive summary Overview of the technologies... 3 Continuous Access EVA... 3 MA/EMA Data Replication Manager...4

Transcription

1 Comparison of HP StorageWorks Continuous Access Enterprise Virtual Array to HP StorageWorks Data Replication Manager Modular Array/Enterprise Modular Array Executive summary... 2 Overview of the technologies... 3 Continuous Access EVA... 3 MA/EMA Data Replication Manager...4 Comparison of features... 5 Disaster tolerance... 5 Recovery capabilities... 8 Solution size... 8 Supported servers and operating systems... 9 Bidirectional replication Performance Host port performance Application performance Replication efficiency Spindle count Full copy performance Replication modes Glossary For more information... 18

2 Executive summary This white paper provides a technical comparison of the capabilities of Continuous Access EVA using the HSV110 controller on the Enterprise Virtual Array (EVA) to those of Data Replication Manager using the HSG80 controller on the MA8000/EMA12000/EMA16000 and RA8000/ESA12000 storage systems. The comparison starts with a review of the technologies followed by a feature-forfeature comparison. The features compared in this paper include: disaster tolerance solution size host port performance spindle count threat radius bidirectional replication application performance full copy performance recovery capabilities array performance replication efficiency It is assumed that the reader has a basic understanding of how each replication technology works. Additional information is available from the HP storage website at 2

3 Overview of the technologies Continuous Access EVA Continuous Access EVA is a Fibre Channel storage controller based data replication (remote mirroring) solution to support disaster tolerance requirements. Continuous Access EVA works with the HP StorageWorks Enterprise Virtual Array storage system, which contains the HSV virtualized RAID controller. The HSV controller and the Virtual Controller Software (VCS) Version 3.0 enhance virtualization with remote replication technology. A basic Continuous Access EVA configuration is shown in Figure 1. Figure 1. Continuous Access EVA basic configuration The basic capabilities of the Continuous Access EVA V1.0A solution include: Up to 64 copy sets per array Up to 64 DR (data replication) groups per array, with at least one and no more than eight copy sets per DR group LUNs can be as small as 1 GB, and as large as 2 TB, in 1-GB increments. Host Ports There are four host ports available, two per controller. Each host port will automatically select either a 1 or 2 gigabits per second (Gb/s) connection depending on the capabilities of the Fibre Channel switch to which it is attached. Replication ports The same four host ports are also replication ports When the controller receives a host write, by default it will first try to use the same port as the replication port. 3

4 EVA 5000 Configurations support a minimum of two to a maximum of eighteen 14-disk-drive enclosures. Supports 36-, 72-, or 146-GB disk drives to a maximum capacity of 36 TB. The back end of the controller consists of two bidirectional 2 Gb/s Fibre Channel loops. Currently, the Continuous Access EVA solution supports several models of Fibre Channel over Internet protocol (FCIP) gateways for storage area network extensions. The maximum supported separation between any two arrays is 36 milliseconds (ms) (approximately 7200 km or 4500 mi) of fiber. Maximum of 8 snapshots or Snapclones per DR group at the local or remote site, or a maximum of 7 per LUN, either source or destination. MA/EMA Data Replication Manager DRM is a controller-based data replication software solution for disaster tolerance and data movement. DRM works with the HP StorageWorks Fibre Channel MA8000/EMA12000/EMA16000 and RA8000/ESA12000 storage systems. A basic DRM configuration is shown in Figure 2. Figure 2. DRM basic configuration The basic capabilities of the MA/EMA DRM solution based on ACS V8.6-P and V8.7-P include: Up to 12 remote copy sets per array. Up to 12 association sets, consisting of at least one and not more than 12 remote copy sets per array. 4

5 LUNs are of fixed sizes, depending on the RAID type and the size and number of disks used in their construction. All disks in a RAID set must be the same size and speed. Maximum size of any LUN is TB. RAID 0 at least 2 and up to 24 member disks RAID 1+0 (RAID 1) at least 1 and up to 6 RAID 0 stripe sets may be members of the same RAID 1 mirror set RAID 5 at least 3 and up to 14 member disks Host ports of the two ports per controller and two controllers, only two are available as host ports when using data replication manager. Replication ports the other two of the four available ports are dedicated to the replication function, and are not available for use as host ports. MA8000 supports up to 24 disk drives in one multi drive shelf enclosure. EMA12000 supports from 1 to 3 of the MA8000s, for a total of up to 72 disk drives. EMA16000 is a special configuration consisting of multiple 48-drive EMA12000s. All three models support 9-, 18-, 36-, or 72-GB SCSI-based disk drives. DRM currently supports several FCIP models and Fibre Channel over asynchronous transfer mode (ATM) based SAN extensions. Up to four active snap volumes per pair of HSG80 controllers are supported. Comparison of features This section compares and contrasts the way each solution supports the listed features. Disaster tolerance Disaster tolerance is a measure of the maximum separation distance between the two sites. This distance defines the maximum size or area of impact so that at least one of the two sites is expected to survive the disaster. This is typically measured in terms of the threat radius or threat area. Typical ranges are: local few km or miles metropolitan few 10s of km or miles regional 10s to 100s of km or miles Figure 3 is an example of the relative relationship among the three classes of threats. 5

6 Figure 3. Threat radius The larger the potential disaster (threat radius), the farther apart the local and remote sites must be. To determine an adequate distance, you must determine what kinds of disasters are probable in the local area and understand the protection distances needed to separate the two sites. Consider any local regulatory requirements that might increase or limit the separation distance. For example, some counties in the United States require both sites to remain within the same 100- to 400-square-kilometer (60- to 250-square-mile) county. This restriction has limited the maximum separation distance to less than 30 km (19 mi) in an area prone to earthquakes. Earthquakes have affected buildings several hundred kilometers from their individual epicenters. As another example, on the East Coast of the United States and on the southern and eastern coasts of the Asian subcontinent, hurricanes or typhoons can cover an area with a radius of 200 km (125 mi) or more. Other natural disasters include regional forest fires, localized tornadoes, and widespread flooding. Unnatural disasters include building fires or chemical contamination, either of which can limit access to computer facilities. In these cases, the threat can move with respect to the fixed facilities. The two sites must be sufficiently far apart, so that the disaster does not affect both. Continuous Access EVA supports separation of up to 36 ms (approximately 7200 km or 4500 mi) between source and destination arrays. This limit is imposed mostly due to the time it takes to complete array management functions over the distance of 7200 km (4500 mi) represented by the 36 ms maximum one-way delay. Table 1 shows the current configuration limits based on separation distance and a maximum time of 10 minutes to perform a set of management operations. 6

7 If more time is allowed to discover an array, more arrays could be managed at greater distances. Similarly, it can take roughly as much time to discover four small configurations as it does to discover two large configurations. Conversely, if the allowable discovery time is only 5 minutes, plan to manage fewer arrays for any given distance listed in Table 1. Table 1. Continuous Access EVA distance versus array manageability Number of Remote EVAs and Relative Config Size Campus (less than 10 km) Metro (out to 200 km or 1 ms) 1 Regional (1 ms to 9 ms) 1 Multiple Regions (9 ms to 18 ms) 1 Intracontinental (18 ms to 36 ms) 1 Intercontinental (greater than 36 ms) 1 Global (greater than 200 ms) 1 1 small 2 OK OK OK OK OK not supported not supported 1 large 3 OK OK OK OK not suggested not supported not supported 2 small 2 OK OK OK OK not suggested not supported not supported 2 large 3 OK OK OK not suggested not suggested not supported not supported 4 small 2 OK OK OK not suggested not suggested not supported not supported 4 large 3 OK OK not suggested not suggested not suggested not supported not supported 8 small 2 OK OK not suggested not suggested not suggested not supported not supported 8 large 3 OK not suggested not suggested not suggested not suggested not supported not supported 1 These are one-way latencies. 2 A small array configuration consists of 1 host using 3 DR groups and 2 copy sets per DR group, for 6 Vdisks built from 60 disk drives in one disk group. 3 A large array configuration consists of 10 hosts using 64 DR groups and 64 copy sets, for 64 Vdisks built from one disk group of 24 disks. The management-over-distance function will improve with future releases. Note that even the 7200 km (4500 mi) limit is well beyond that required by most regional disasters, and should not prevent Continuous Access EVA from being used in most environments. DRM has been tested and proven to work with one-way delays of up to 450 ms (90,000 km or 56,000 mi), which represents more than enough delay tolerance to connect any two points on the earth using a geo-synchronous satellite communications link. Because the DRM solution is managed over a low bandwidth RS-232 serial connection, there is minimal observed impact due to the extreme distances. 7

8 Recovery capabilities Recovery capabilities are a measure of how easily a part of the system recovers from a failure. Options for performing recovery include performing the failover by clicking on the LUNs, executing pretested failover scripts, and/or using manual command line interfaces (CLIs). Currently, none of these solutions supports automatic failover, only automated failover. In Continuous Access EVA, each of the three recovery options is available in some form. The Continuous Access user interface has a function to create a managed set of DR groups that can be managed together. By selecting a single managed set, users can failover all LUNs represented by that managed set. Actions similar to a managed set can be scripted sequentially to perform a single LUN failover at a time. There is also a CLI into the SSSU (storage systems scripting utility) that allows the execution of single commands against a single LUN. In DRM, the basic HSG80 CLI interface is the default management interface, and supports the failover of one LUN at a time. For more than one LUN, this can become time consuming and error prone during a recovery because it involves a lot of typing. Some failover scripts are supplied to help automate the failover and/or recovery operation. Solution size Solution size is a measure of how many LUNs can be made available to a single application and how large those LUNs might be. Solution size in the aggregate is a measure of how many arrays are supported within a single solution set. Although not discussed here, solution size is dependent on the maximum amount of storage available within a particular array. See the HP StorageWorks Continuous Access EVA Design Reference Guide or the Continuous Access EVA performance estimator and application note for details on how performance may limit the solution size and in turn the solution set size. In Continuous Access EVA, a single application is expected to use one DR group to maintain replicated write order across all LUNs within that single group. As a result, an application like Oracle is limited to using 8 LUNs at most (the DR group limit), some or all of which can be a maximum size of 2 TB. With a limit of 64 copy sets, a single array would be able to support up to 8 Oracle-like applications from a pure storage replication perspective. The solution set may consist of a maximum of 16 arrays or 8 pairs of arrays in a one-to-one replication relationship. At 16 arrays and 64 LUNS per array, a Continuous Access EVA solution set supports up to 16 times 64, or 1024 LUNs. At up to 64 servers per replicating pair of arrays, a Continuous Access EVA solution supports up to 64 times 8, or 512 servers. In DRM, a single application is expected to use one association set to maintain replicated write order across the maximum of 12 LUNs that might be in that association set. Although this larger limit increases the number of possible applications that can take advantage of storage-based replication, the array can only support 12 LUNs, thus a single application might completely allocate the replication resources within the arrays. At 12 remote copy sets per pair of arrays and a maximum of 16 arrays, a single DRM solution set might support up to 8 times 12, or 96 remote copy sets. At 12 servers per array, a single solution set might support up to 12 times 16, or 192 servers. 8

9 Supported servers and operating systems Continuous Access EVA supports the following servers and operating systems. Table 2. Continuous Access EVA supported host servers and operating systems Vendor/Server HP AlphaServer HP Blade Server Intel-based HP ProLiant server Intel-based HP PA-RISC- K, L, N, and V- class IBM RS 6000 Supported Operating System HP OpenVMS, HP Tru64 UNIX Microsoft Windows 2000 and 2003 (32-bit), Windows NT, HP-UX, Novell NetWare, Red Hat Linux, SuSE Linux Microsoft Windows 2000 and 2003 (32-bit), Windows NT, HP-UX, Novell NetWare, Red Hat Linux, SuSE Linux HP-UX IBM-AIX Note: This list is subject to change with new product releases. For the latest supported version(s), check the HP storage website at Table 3. Continuous Access EVA supported operating system versions Operating System HP HP UX HP OpenVMS HP Tru64 UNIX IBM AIX Microsoft Windows 2000/NT Server, Windows 2000/NT Advanced Server Version V11.0 and V11.11, HP Service Guard Clusters VA V7.2-2 and V7.3-1 clusters appropriate to OS version V5.1, V5.1a, and V5.1b clusters appropriate to OS version V4.3.3 and V5.1, HACMP appropriate to OS version V5.0, Service Packs 2, 3, and 4, MSCS V1.1 Microsoft Windows NT Server V4.0, Service Pack 6a, MSCS V1.1 Microsoft Windows 2003 (32-bit) V6.0, MSCS V1.1 Novell NetWare V5.1 and V6.0 Red Hat Linux Sun Solaris SuSE Linux Advanced Server V2.1, LifeKeeper Cluster V V2.6, V7, V8, and V9 VERITAS Clusters V1.3 Sun Clusters V2.2 SLES 7 and 8, LifeKeeper Cluster V Note: This list is subject to change with new product releases. For the latest supported version(s), check the HP storage website at 9

10 DRM supports the following servers and operating systems. Table 4. DRM supported host servers/operating systems Host Server HP AlphaServer HP ProLiant server Hewlett-Packard HP9000 L, N, V class IBM RS6000 Sun Ultra SPARC Supported Operating System HP OpenVMS, HP Tru64 UNIX Novell NetWare, Windows 2000, Windows NT HP-UX AIX Solaris Note: This list is subject to change with new product releases. For the latest supported version(s), check the HP storage website at Table 5. DRM supported operating system versions Operating System Supported Version SCSI-2 Support SCSI-3 Support HP OpenVMS V7.2-2 and 7.3, VMS Clusters appropriate to OS version No Yes HP Tru64 UNIX V5.1 and 5.1a, TruClusters appropriate to OS version Yes Yes HP-UX V11.0 & V11.11, HP Service Guard Clusters VA Yes Yes IBM AIX V4.3.3 & 5.1, HACMP Clusters V4.4.1 Yes Yes Microsoft Windows 2000 for Server, Advanced Server, Datacenter Server Microsoft Windows NT Server V5.0, Service Pack 2, MSCS V1.1 Yes Yes V4.0, Service Pack 6a with hotfix, MSCS V1.1 Yes Yes Novell Netware V5.1 and 6.0 Yes Yes Sun Solaris V2.6 (32-bit mode only), V7 and V8 (32- and 64-bit mode) VERITAS Clusters V1.3 Sun Clusters V2.2 Yes Yes (V7 & V8) No (V2.6) Note: This list is subject to change with new product releases. For the latest supported version(s), check the HP storage website at 10

11 Bidirectional replication Bidirectional replication is a description of how to use the available equipment within a solution. The equipment includes the arrays and servers at each site. In unidirectional replication, all operations are performed at the primary site only, with the backup site accepting data and the servers limited to functions like moving copies of the data to tape backup. Bidirectional replication supports two unidirectional data streams, one each way. In either case, the two streams of data share the same intersite links. In Continuous Access EVA, these two unidirectional streams can share the same arrays, just not the same DR groups or the LUNs within those DR groups. DRM, as shown in Figure 4, requires two sets of arrays, one for each unidirectional replication, although the servers might be attached to both. Figure 4. Bidirectional DRM solution 11

12 Performance There are several ways to measure the performance of an array. They include: Examine the raw bandwidth of the host ports and how replication affects that performance bandwidth. Measure the peak throughput of the controller doing replication at zero distance. Then scale the metric using the mathematics similar to what is described in either the performance estimator, white paper, or design reference guide to determine the effect of array separation distances larger than zero. Examine the efficiency of the replication algorithm and how that affects the performance over distance. Count the number of spindles (physical disk drives) involved in the moving of data onto and off of the array. Measure the full copy or normalization efficiency and how that affects the performance during set up or resynchronization operations. Compare the synchronous and asynchronous performance curves. How performance is measured also depends on the customer s comfort level and understanding of the configuration. Customer results may vary. The following sections provide details on the ways to compare the performance of Continuous Access EVA and HSG80 arrays. Host port performance In the EVA, each host port auto-negotiates with the switch to which it is attached and establishes either a 1-Gb/s or 2-Gb/s link with that switch. If the switch and the server Fibre Channel adapter are also running at 2 Gb/s, the server to the storage connection will run at 2 Gb/s. Note that this bandwidth is shared between the host reads and writes and the replication writes. Therefore, in a traditional database application with 60/40 reads versus writes, the port will instead see 60/40/40 (read, write, replicated write). The total is greater than 100 percent, but it includes the additional write to the remote array. Using this same example, the actual capacity of the port is only about 70 (100/140) percent of the available bandwidth. Using other ratios will produce different effective bandwidths. Remember that this is the use for just one of the four host ports. In the HSG80, both the host and replication ports are fixed at 1 Gb/s. Because the replication port uses a dedicated port that is separate from the host port, there is no bandwidth sharing and both host and replication ports have access to the full bandwidth of the port. Using the same example of a database with 60/40, all 100 percent of the 1-Gb/s port is available to the host, while 40 percent of the replication port is consumed by the 40 percent writes from the host. Stated another way: consider the combination of the two ports 60/40 on the host and 40 percent of the replication, or divided by the 200 percent (because two host ports are being used). In this case, the math (140/200) shows a similar 70 percent utilization of the two ports, and there are only four available, two on each controller. 12

13 Application performance Performance of both arrays was measured using a simulated workload consisting of 70 percent reads and 30 percent writes. The read and write requests varied in size from 512 bytes to 64 KB, and were randomly spread across similarly sized RAID1 or Vraid1 LUNs. The request rate results of both tests are shown in Figure 5, with Continuous Access EVA shown by the solid line, and DRM shown by the dashed line. Figure 5. Performance comparison Request Rate (I/O Operations per Second) versus Request Size (KB) EVA MA/EMA

14 During the same set of tests described above, the transfer rates in MB/s were also recorded and are shown in Figure 6. Figure 6. Transfer rate versus request size Transfer Rate (MB/s) versus Request Size (KB) EVA MA/EMA Note that these numbers represent maximum capability for a single application and the performance of a single controller under ideal conditions. It may not be possible to duplicate this level of performance in practice. Replication efficiency Replication efficiency is a measure of the number of steps involved in performing the replication; the fewer the steps the higher the efficiency. In Continuous Access EVA, the completion of the replication write takes one round trip from the source controller to the destination controller. Using a proprietary protocol, only the write and its acknowledgement are needed for the replication write to complete. Thus, the Continuous Access EVA replication process can be summarized as follows: 1. Initiator to target: "Here is the data <data>." 2. Target to initiator: "I got it." (the acknowledgement) In DRM, the completion of the replication write takes two round trips: one round trip to set up the SCSI write and another to move that data and acknowledge its receipt. This is a basic SCSI write and can be summarized in the following steps: 1. Initiator to target: "Are you ready?" 2. Target to initiator: "Yes I am." 3. Initiator to target: "Here is the data <data>." 4. Target to initiator: "I got it." (The acknowledgement) For similar distances, DRM will take almost twice as long as Continuous Access EVA to complete a similarly sized write. 14

15 Spindle count Similar to application performance, it is possible to determine the maximum obtainable read or write performance based on the number of spindles (disk drives) used to create the logical device. This number will vary (explained below) based on how the redundancy affects the total. The process involves inverting the average read or write time for a particular device to get an average peak read or write rate for that disk. These rates are then multiplied by the number of devices involved to get the theoretical peak read or write rate. Both rates are limited by the interconnect or the controller as described in the other parts of this section of the paper. In Continuous Access EVA, the disks rotate at either 10,000 or 15,000 rpm and have average response times of around 4 to 5 ms. The size of a logical device depends on the number of physical devices within the disk group and the HP VersaStor-enabled virtual RAID (Vraid) type of the logical device. There is a one-to-one correspondence between the number of disks in the disk group and the number of spindles in the Vdisk, which means if the disk group contains 120 disk drives, the Vdisk also uses 120 drives. Therefore, to calculate the peak performance for a given Vraid type and given number of drives in a disk group, use 100 percent of the count for Vraid0 LUNs, 50 percent for Vraid1, and 80 percent for Vraid5. The EVA backplane runs at 2 Gb/s on each of the four Fibre Channel Arbitrated Loops. In DRM, the disks rotate at either 7200 or 10,000 rpm and have average response times of around 6 to 8 ms. The maximum number of drives that can be used to build a logical device varies with the RAID type as shown in the text following Figure 2. Of that number, 100 percent in RAID 0, 50 percent in RAID 1, or 80 percent in RAID 5 are used in the peak performance calculation. The HSG80 backplane runs at 40 MB/s on each of the six ultra SCSI buses. Full copy performance When either a copy set or remote copy set is initially created, the source or initiator copy of the pair may contain data. The process for copying that data to the replication destination or target is called full copy or normalization. In Continuous Access EVA, a full copy of the data from the source to the destination Vdisk moves only those 1-MB blocks of data that have been written to the Vdisk since it was created. This seems advantageous until the performance impact of the EVA first write penalty is considered. If both the source and destination have been prewritten, and are fully allocated, then copy rates may exceed 100 megabytes per second (MB/s). If the Vdisks are newly created, this number drops to 20 to 40 MB/s depending on the Vraid type of the Vdisks (where Vraid0 is the fastest, and Vraid1 the slowest). The 100 MB/s rate is sustainable from zero separation to almost 100 km (62 mi) of separation before it starts to diminish. In DRM, a full copy of the data from the initiator to the target involves moving the data in 64-KB chunks and reading every block of the remote copy set. Typical rates are around 15 MB/s and seem to be independent of the target disk drive RAID type. This is because the target copy is erased and prewritten during the creation of the logical disk and not on creation of the remote copy set. The 15 MB/s is the peak observed at zero separation and falls to approximately 10 MB/s at 100 km (62 mi). 15

16 Replication modes In data replication, there are traditionally two types of replication modes: synchronous and asynchronous. In synchronous mode, the host write is acknowledged by the storage array after a copy of the write has been written to the cache in both arrays. In asynchronous mode, the host write is acknowledged back to the host after a copy of the data is in the first array; only then does the host send the data to the second array. In Continuous Access EVA, the replication mode is called the write mode. Continuous Access EVA supports synchronous replication only. Asynchronous replication is expected in the next release. Assuming that both are supported, the peak performance that can be expected using either mode is shown in Figure 7. Note that Figure 7 and Figure 8 are not to scale and cannot be compared to each other. Figure 7. Continuous Access EVA asynchronous versus synchronous replication In DRM, both synchronous and asynchronous replication modes are supported. In DRM, the replication mode is called the remote copy operation mode. Figure 8 shows that the peak performance of asynchronous mode is so much lower than that of synchronous mode that although it is supported, it is not recommended in most cases. Figure 8. DRM asynchronous versus synchronous replication 16

17 Glossary Continuous Access EVA and MA/EMA Data Replication Manager use slightly different terms in almost the same way. It is important to understand how the following definitions are used. Table 6. Glossary of terms Term association set copy set destination disk group DR group Fibre Channel host port initiator remote copy set (RCS) replication port source target ultra SCSI Definition The DRM term for a group of one or more remote copy sets (RCS) that share a common write history log. (See DR group.) The Continuous Access EVA term for a pair of LUNs, one at the source and presented to the host accessing the copy set, and the other at the destination of the replication from the source. (See remote copy set.) The Continuous Access EVA term for the Vdisk that is the recipient of the replicated data from a source. (See target.) The Continuous Access EVA term for a group of physical disks selected from all the available physical disks in the storage system, where one or more Vdisks can be created. A physical disk can belong to only one disk group. There is no corresponding term in DRM. The Continuous Access EVA term for a group of one or more copy sets that share some common properties such as mode of replication, failsafe mode, and a common write history log. (See association set.) A 1- or 2-Gb/s optical-based communications bus. It is used between the host and the storage, and the backend of the HSV110 controller to access the actual disk drives within the array. (See Ultra SCSI.) The controller port through which the host issues reads and writes to the storage, and in particular to the LUNs presented to that host by the controller. (See replication port.) The DRM term for the storage array that contains the primary copy of the data within an RCS. The DRM term for a pair of LUNs, one the initiator and presented to the host accessing the RCS, and the other the SCSI target of the replication write from the initiating controller. (See copy set.) The controller port through which the source or initiator controller issues the replication write to the destination or target copy of the LUN. (See host port.) The Continuous Access EVA term for the primary Vdisk containing the data that is replicated to its destination. (See initiator.) The DRM term for the storage array that is the secondary or backup source of information. In the event of a system outage, the database would be recovered from the target system. The target site is also referred to as the remote site. (See destination.) As implemented in the backend of the MA/EMA based storage, the ultra SCSI is a 40-Mega-Byte-per-second parallel Small Computer Systems Interface used by the HSG80 controller to access the actual disk drives within the array. (See Fibre Channel.) 17

18 For more information The references listed in this section provide additional information and were used to develop this white paper. To access the following references, go to In the gray box on the right side of the page, select the link indicated after each title. HP StorageWorks Continuous Access EVA Design Reference Guide (select technical documentation) HP StorageWorks Continuous Access EVA Replication Performance Estimator Application Note (select technical documentation) HP StorageWorks Continuous Access EVA Replication Performance Estimator spreadsheet (select technical documentation) HP StorageWorks Continuous Access EVA QuickSpecs (select specifications & warranty) To access the following references, go to In the gray box on the right side of the page, select the link indicated after each title. HP StorageWorks Data Replication Manager Design Guide (select technical documentation) HP StorageWorks Data Replication Manager Inter site Link Performance Analyzer calculation tool (select technical documentation) HP StorageWorks Data Replication Manager Inter site Link Performance whitepaper (select technical documentation) HP StorageWorks Data Replication Manager QuickSpecs (select specifications & warranty) 2003 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 or registered trademark of Intel Corporation in the U.S. and other countries and is used under license EN, 08/