EMC RepliStor vs Double Take 062008

June 2008 www.veritest.com • [email protected]

EMC RepliStor: Features, Usability and Performance Study Comparing EMC RepliStor and Double-Take Software Double-Take for Windows

Test report prepared for EMC Corporation

Executive Summary EMC Corporation commissioned VeriTest, the testing service of Lionbridge Technologies, Inc., to perform a study comparing the features, usability and performance of the EMC RepliStor 6.2 SP1 product to that of the Double-Take Software Double-Take for Windows 4.5.2. The primary focus of this study was to compare these products when used to replicate data generated via common workloads. EMC RepliStor and Double-Take for Windows replication solutions provide high availability, failover, and continuous real-time replication for Exchange Server 2003 and SQL Server 2005. For the purposes of this study we refer to a fictitious company called ABC Systems, which has a need to have their production Exchange and SQL Server systems (referred to as the “source” systems) replicated to partner systems (referred to as the “target” systems). ABC Systems wants to be able to use the target systems during times of maintenance for the source systems, and as complete copies of the source systems in the event of a disaster recovery situation. To this end, VeriTest developed a small datacenter consisting of an e-mail server running Microsoft Exchange Server 2003 and a database server running Microsoft SQL Server 2005 to act as the source servers to be tested in this study. In addition, two systems were configured with matching hardware, software and Operating System versions to act as the target systems for each of these source systems. These systems were configured to exist within a single Windows Server 2003 Active Directory (AD) domain. To simulate the workload ABC Systems experiences, a dedicated load generation server was configured with Microsoft Exchange Load Generator to simulate various e-mail workloads presented to the source Exchange 2003 server. Finally, a dedicated load generation server was configured with Microsoft Database Hammer to simulate a workload with a high-volume of SQL Server 2005 database changes on the source SQL 2005 server. Appendix A provides a high-level diagram of the datacenter created for ABC Systems.

Key findings

� RepliStor provides VSS integration which provides the ability to use VSS snapshots as backups. In addition, when taking VSS snaps RepliStor does not require any end-user downtime to be experienced.

� Double-Take required 87.2% more steps and 161% more time to complete full protection of a SQL Server 2005 configuration than it took with RepliStor.

� RepliStor replication performance scaled better than Double-Take under the Exchange 2003 workload simulations. RepliStor was able to increase its data transfer rate by 99.1% when moving from 1500 to 3000 mailboxes, whereas Double-Take achieved a 66.1% increase.

� RepliStor achieved 157% greater data transmission rate than Double-Take under the SQL Server 2005 workload.

� RepliStor exhibited a greater ability to keep up with the data replication changes necessary than Double-Take under both the Exchange 2003 and SQL Server 2005 workloads.

EMC RepliStor: Feature, Usability and Performance Study with Double-Take 2

This study found that although both RepliStor and Double-Take provide similar features for addressing the needs of ABC Systems, in some key areas RepliStor’s implementation provided a more robust and easier to manage solution. For example, with Microsoft Volume Shadow Copy (VSS) Services RepliStor provides a more seamless and deeply integrated solution than Double-Take, leading to less likelihood of experiencing an end-user downtime when VSS snapshots were taken. Also, the use of alias functionality RepliStor employs does not require Active Directory changes for Exchange Server failover to occur. In addition, the inclusion of built-in reporting and simulation features with RepliStor were not provided within the Double-Take solution. To directly compare usability between RepliStor and Double-Take, we developed a Usability test in which a series of tasks necessary to achieve a protected state between the source and target SQL Server 2005 systems were executed. We found that it required fewer steps and less time to reach the fully protected state with the RepliStor solution than it did with the Double-Take solution. Finally, we conducted real-time-replication (RTR) performance tests comparing how well each product was able to process RTR changes under various Exchange Server 2003 and SQL Server 2005 workloads. We found RepliStor was able to achieve a higher replication data transfer rate for each of the RTR tests we performed. In addition, when moving from 1500 to 3000 mailboxes with Exchange Server 2003, RepliStor scaled higher in performance and was able to keep up with the processing workload, whereas Double-Take did not scale as well, and thus was unable to keep up with the processing workload. The Test Results section of this study provides the detailed results for the features, usability and RTR performance comparisons conducted. Complete details on how each test case was executed can be found in the Testing Methodology section of this study. Finally, the Appendices at the end of this study provide further details on the hardware and software used in this study.

Test Results This section provides the results of the tests we conducted to compare the features, usability and real-time-replication performance between EMC RepliStor 6.2 SP1 and Double-Take Software Double-take v4.5.2. Please refer to the Test Methodology section of this report for complete details on how these tests were conducted.

Feature Comparison

This section provides an overview of some of the key features advertised by both RepliStor and Double-Take. The following table provides a high-level overview of many of the features available with both replication solutions.

Feature RepliStor 6.2 SP1 Double-Take 4.5.2

High Availability (HA) Capabilities Yes Yes

Failover Capabilities o Automated o Script setup/modification Required

Yes Yes No

Yes Yes Yes

Full & Incremental Synchronization Support Yes Yes

Data Compression Yes Yes

Registry Replication Yes No

Multiple Levels of Data Compression No Yes

Scripting Support to Customize Failover Behavior Yes Yes

Automatic Failover Yes Yes

Microsoft Volume Shadow Copy Services (VSS) Support o Custom Scripting Supported o Custom Scripting Required o Completely Maintained within Management GUI o Application Writer Integration

Yes Yes No Yes Yes

Yes Yes Yes No No


� E2K3 � E2K7 � SQL05

Yes Yes Yes

No No No

Reporting Capabilities Yes No – Provided by a separate application.

Simulation Capabilities Yes No

Encrypted File Replication Yes Yes

Windows Performance Monitor Support Yes Yes

Bandwidth Throttling Yes Yes

Localization o English o French o Japanese o Korean o Simplified Chinese

Yes Yes Yes Yes Yes

Yes No No No No

Table 1: High-level Feature Comparison In addition, more detailed information is provided on how RepliStor addresses each of the key features necessary to meet the requirements ABC Systems has established. ABC Systems has the following minimum requirements for their replication solution:

o Provide a High Availability framework that supports Microsoft Exchange Server 2003 and SQL Server 2005 installations.

o Provide automatic failover capabilities for both Exchange Server 2003 and SQL Server 2005. o Provide “full” and “incremental” synchronization capabilities. o Support integration with the Microsoft Volume Shadow Copy Services (VSS) available with

Microsoft Windows Server 2003. o Provide continuous real-time data replication.

The following features were considered to be not critical requirements, but the existence of these features would enhance ABC Systems experience:

o Registry replication support. o Reporting features – Does the replication solution provide the ability to analyze historical

data, real-time statistics, etc. o Windows Performance Monitor Integration/Support. o Simulation support – Does the replication solution provide an ability to simulate data

replication to be used for such things as bandwidth sizing?

High Availability

RepliStor uses modules which, when installed, launch a wizard to setup and configure HA specific to the application being protected. . Below are some details regarding how the RepliStor solution achieves HA for Exchange server and SQL Server 2005. RepliStor offers multiple source-to-target configuration options beyond a standard one-to-one configuration such as: many-to-one, one-to-many, chained and same server configurations across LAN and WAN based TCP/IP networks.

o Exchange Server 2003: The RepliStor Exchange Module for Exchange 2003 provides HA via Exchange virtual account. This removes any requirement for Windows Active Directory edits. All information store data locations are automatically discovered during the module installation/configuration, along with VSS configuration, if desired. Failover time is limited to the time it takes for the services to start on the target Exchange system, and performs a “soft recovery” of the information store. The Outlook profile does not need to be modified, and will reconnect on failover.


o SQL Server 2005: The RepliStor SQL Server Module for SQL 2005 provides HA via an alias name by which SQL clients can connect to instances. This supports the configuration of Default and Named Instances. Automatically discovers data and log file for instance(s) chosen. Also supports the ability to configure VSS during the module installation/configuration process.

The Double-Take solution also provides HA capabilities by fully replicating Exchange Server 2003 and SQL Server 2005 data, logs and configuration settings to a target system. The recommended approach to achieve HA with Double-Take is to use the Double-Take Application Manager utility which is a GUI based application (discussed further in the Usability section of this study) that assists the user in setting up Exchange Server and/or SQL Server 2005 (as well as other solutions not a focus of this study) source/target pair that can minimize downtime to the time it takes for DNS updates and target server services to start up. Double-Take also offers multiple configuration options such as: many-to-one, one-to-many, chained and same server configurations across LAN and WAN based TCP/IP networks.

Failover

RepliStor provides a failover mechanism using the concept of an alias name. The Alias can be a DNS CNAME (for WAN failover) or a dedicated IP for same subnet configurations (situations in which the source and target system exist on the same network subnet). DNS is automatically updated via activation, failover, failback or deactivation. This is the name by which client applications will connect to either the source or target depending on which is the active instance. Failover can be configured to be done automatically or manually, depending on the user’s preference. Replications Specifications can be automatically created in reverse direction (from target to source) upon failover and optionally when source returns to an online state. A reverse incremental synchronization can be initiated to facilitate fail back. RepliStor supports the implementation of scripts that can be executed before or after a failover is activated. This allows the user the ability to customize certain actions to be taken. Finally, two types of failback are supported:

o Exchange Roles: With this option the old “target” becomes the new “source” after a failover. The old “source” server becomes the new “target” once it is detected to be back online. This method involves no downtime.

o Revert: When the source server returns to an online state, the alias is moved back to the source server. Prior to the actual revert data synchronization from “target” to “source” can be occurring, thus limiting downtime to the amount of time required when the alias failback occurs.

Double-Take provides two types of failover methods when protecting Exchange Server or SQL Server 2005:

o DNS: This is the recommended failover method by Double-Take. This method updates all source server A, CNAME, MX and PTR-type DNS resource records to point to the target server.

o Identity: With this method the source servers name and IP address are transferred to the target server. This approach has a greater risk of duplicate name and/or IP address conflicts when failover occurs or when the source server is brought back online, so this method is not recommended by Double-Take.

Synchronization

RepliStor supports two primary types of synchronization between the source and target system: Full Synchronization and Incremental Synchronization. In addition the RepliStor Synchronization process is multi-threaded and multi-connection based, whereby multiple files on different connections are transferred simultaneously. In addition, RepliStor supports “orphan” deletion so that data no longer existent on the source server will be automatically deleted from the target server. Below are further details on the two synchronization types:

o Full Synchronization: This process typically occurs when the replication source/target pair is initially brought into a protected (synchronized) state. During initial synchronization the target system does not have any data. However, full


synchronization can be executed with data already existing on the target system if desired.

o Incremental Synchronization: When data between the source and target system become inconsistent, and incremental synchronization can be executed to return to a fully protected state. There are multiple options available for executing the incremental sync: Log differences, and Check only.

Double-Take also supports these same two primary types of synchronization. Double-Take supports using time-stamps or block checksums as the method for determining if synchronization is necessary during an incremental sync operation. Double-Take also supports the option to “delete orphans” similarly to what RepliStor provides.

Microsoft Volume Shadow Copy Services (VSS)

RepliStor supports full application writer integration for Exchange Server and SQL Server 2005. The following key functionality with VSS exists:

o By integrating fully with the application writer, RepliStor does not introduce any sort of downtime experienced by the end-user when a VSS snapshot is taken.

o Additionally, by integrating with the application writer, VSS snapshots taken within the RepliStor configuration can be treated as full backups and allows RepliStor to act as a centralized backup for applications such as Exchange Server and SQL Server 2005

o Coordination of freeze/thaw with the application writer on the production server. o Optionally updates backup history and perform transaction log management for

Exchange. o A temporary shadow copy is created on the source, while a permanent copy is

created on the target; thereby no additional synchronization is needed to create a permanent copy.

o Script callouts for actions after shadow copy creation facilitates additional backup to tape and/or disk.

o Utilizes ESEUTIL consistency checking for Exchange support. o Provides built-in scheduling support.

Double-Take also provides support for VSS. However, this is accomplished by modifying sample scripts provided by Double-Take, and then enabling the feature within the Double-Take Management Console to the execution of these scripts. Also, it does not appear that Double-Take supports integration with the application writer. Therefore, Double-Take does not consider VSS snapshots to be valid backups of application data. When taking a VSS snapshot, the customized scripts are invoked to halt the necessary services to insure a consistent data point is achieved. Although this downtime can be very minimal, an end-user would still experience the downtime.

Real-time Continuous Replication

RepliStor provides a number of features with regard to Continuous Real-time Replication. o Operations are multi-threaded/multi-connection based o Supports the replication from/to NAS based drives o Protection options for target files o Temporary Extension/Copy on Close – Only presents file on target after file is

completely copied to target o Optionally set RepliStor driver to be a boot-time driver. This allows replication

through startup/shutdown and allows replication of system files o Multiple Delete Options including:

� File deleted on source is deleted to the recycle bin on target � File deleted on source is moved to dedicated delete directory � Multiple deleted file versions optionally saved

Double-Take also supports Continuous Real-time Replication of data. Information could not be found to determine if the Double-Take for Windows v4.5.2 supported replication from/to NAS drives, and this was not specifically tested for this study. When replication and mirroring (synchronization) are occurring at the


same time, Double-Take gives priority to replication traffic, thereby minimizing the amount of time to reach a fully protected state.

Registry Replication

RepliStor supports the replication of registry keys. There are two methods by which registry keys can be replicated to the target:

o Same as Source: replicate registry keys to the same location on the target as they exist on the source system

o Backup Location: replicate the registry keys to a different location on the target, thereby maintaining unique keys between the two servers

Double-Take does not support Registry Replication with version 4.5.2.

Reporting

RepliStor provides built-in reporting capabilities that allow a user to collect and log performance information at defined intervals. Double-Take v4.5.2 does not provide a built-in reporting mechanism. Double-Take provides an add-on application called Double-Take Reporting Center that provides features similar to what RepliStor provides with its built-in reporting functionality.

Windows Performance Monitor Integration/Support

Both RepliStor and Double-Take provide similar capabilities with regard to integrating various performance metrics with the Windows PerfMon utility. However, one particular PerfMon metric we found useful with RepliStor that does not exist with Double-Take is the metric called “Replication Latency”. This RepliStor PerfMon metric reports the length of time (in milliseconds) it takes for a data change on the source to reach the target system. We could not find a similar Double-Take PerfMon metric that provided this level of information.

Simulation Support

RepliStor supports the ability to allow a user to simulate data replication for bandwidth sizing research. We did not find a similar feature within the Double-Take solution.

Usability Comparison – Establishing a Protected State with SQL Server 2005

This section provides the results of the usability testing in which various tasks were performed to achieve a point at which the ABC Systems SQL Server 2005 environment was in a protected state with each product. For this aspect of the study a comparison of the number of steps and time required to complete the following tasks necessary to reach the desired protection state using SQL Server 2005 as the application being protected:

• Installation of the replication software

• Replication Dataset Configuration

• Initial synchronization/mirroring configuration process

• VSS Configuration within the Replication Solution

• Failover Configuration process Both products provide a Windows installer interface for installing the core replication application. However, when configuring protection for the SQL Server 2005 (SQL05) application as part of the process, it was found that the approach taken by each replication solution is quite different. The RepliStor Installation Guide and RepliStor Administrator’s Guide were utilized as the primary sources of documentation for completing the tasks identified above. The EMC RepliStor application uses specific “modules” as part of configuring specific application protection (e.g. SQL Server 2005, Exchange Server 2003, and Exchange Server 2007). Testing showed this module approach to be quite intuitive and easy to execute. In addition, this approached saves time as it automates the discovery of the application data (specifically SQL05 for this comparison), and did not require leaving the RepliStor management interface in order to install and configure the module for SQL05.


Also, it was found beneficial that during the module installation the user is prompted to configure the VSS settings so as they would be incorporated into the finished configuration. Double-Take recommends the use of their Double Take Application Manager (DTAM) when protecting a SQL Server 2005 installation. The DTAM User’s Guide documentation was used as the base documentation followed when performing the necessary steps to achieve a protected state with Double-Take and SQL05. Other Double-Take documentation utilized included the Double-Take Getting Started Guide, Double-Take User’s Guide, Guidelines for using Microsoft SQL Server 2005 with Double-Take, and Guidelines for Protecting Data Using Double-Take® with Volume Shadow Copy Service (VSS). This approach required the installation of the core Double-Take application (DTNT) as well as Double-Take Application Manager. Following the documented guidelines for each product, tests showed that it took 161% longer to complete the steps identified above in order to achieve the desired protected state with the Double-Take solution than it did with RepliStor. It required 87.2% more steps to complete this process with Double-Take than it did with RepliStor. In addition, Double-Take uses scripts in order to accomplish failover as well as VSS scheduling, whereas RepliStor does not require additional time in order to configure scripts to accomplish these key components of protection. The time and steps presented in this study reflect the amount of time required to simply copy the sample scripts provided by Double-Take into the proper directory locations on the source and target servers as appropriate. However, in a highly customized environment, or in an environment with a large number of databases the amount of time to configure the scripts appropriately could be considerably higher than what is presented here. Figure 1 below provides further information on the number of steps and time required to complete the usability tasks for each replication solution.

Number of Steps and Time Required to Complete SQL Server 2005 Protection

287

82

47

749

Number of Steps Time to Complete

(seconds)

(Lower Number is Better)

RepliStor

Double-Take

Figure 1: Number of Steps and Time Required to Complete Protection Configuration


In addition, the RepliStor process was found to be easier and more intuitive than the Double-Take solution. The RepliStor feature of providing a “module” for the SQL05 application leads to a more intuitive, and streamlined process for setting up the various configuration aspects necessary to establish a protected state. The inclusion of VSS support within the module configuration is an additional factor which leads to the RepliStor process taking less time, and feeling more intuitive during the setup and configuration process. Double-Take provides the ability to automatically check for newer versions of the core replication engine software (DTNT) at the start of the installation process. This was a feature an end-user would find useful. Please refer to Appendix E for detailed step-by-step actions taken to complete the above tasks for each replication solution.

Performance Comparison – Real-time-replication with Exchange Server 2003

This section provides the results of the test cases comparing the real-time-replication (RTR) performance between RepliStor and Double-Take when replicating Exchange Server 2003 (E2K3) data. ABC Systems wanted to measure how each product performed when replicating the E2K3 data during normal business operations. Therefore, test cases were developed in which an E2K3 workload was simulated using the Microsoft Exchange Load Generator (LoadGen) tool. Please refer to the Test Methodology section of this study for further details on the configuration used. Each product was configured to replicate the E2K3 database and log file data to an identically configured system connected via a WAN simulator. A dedicated interface was used to transfer the replication data. Two key data metrics were captured to determine how well each product was performing the replication changes:

o Average Replication Data Transfer Rate - Measured by the average rate data is sent to the target during the workload simulation. The rate is defined as the actual bytes that are transferred to the target once decompression of the data stream has completed. For example, if 1 GB of data is compressed to 100MB and sent across the WAN link (using 100MB of available bandwidth) the actual data transferred is recorded as 1 GB and not the actual line usage of 100 MB. This metric provides a good understanding of how quickly data is being replicated from the source to the target system during day-to-day operation. This data is derived from each replication solution’s Windows PerfMon metric that reports the total bytes transferred from the source to the target.

o Average Remaining Bytes in Replication Queue – This value reflects the amount of

replication data queued on the source E2K3 server which has not yet been replicated (transferred) to the target E2K3 server. This data is derived from the replication solution’s Windows PerfMon metric which reports data queued to the target.

With 1500 mailboxes, both RepliStor and Double-Take were able to successfully keep up with the workload. In other words, both replication solutions performed essentially the same under this workload. At the end of the LoadGen workload simulation Double-Take had 2.91 MB of queued replication data, whereas RepliStor had 2.27 MB of queued replication data. This amount is statistically insignificant considering both applications were transferring replication data at similar rates during this workload. RepliStor transferred replication data at an average rate of 1.11 MB/sec, whereas Double-Take transferred replication data at an average rate of 1.24 MB/sec. This results in a situation in which less than one second after the workload simulation ends, both products have completed replication to the target E2K3 server. Figure 2 below provides further representation of these results.


Figure 2: Exchange Server 2003 RTR with 1500 Mailboxes Workload However, when the number of Exchange users was increased to the 3000 mailbox user workload, significantly different results were observed. When this workload simulation completed, RepliStor had an average of 13.96 MB of data queued for replication. By comparison, Double-Take had an average of 4121.38 MB of data queued for replication. This result shows that Double-Take had 295 times more data in queue than RepliStor when the workload simulation completed. Whereas it would require less than 6 seconds for RepliStor to replicate its remaining queued data to the E2K3 target after the workload simulation completed, it would require Double-Take 2001 seconds to finish replicating queued data to the target E2K3 system. Figure 3 below provides further examples of this comparison.

1500 Mailbox Workload

1.11

2.27

1.24

2.91

Average Transfer Rate (MB/second)

(Higher Number is Better)

Replication Data Queued (MB)


RepliStor

Double-Take


13.96

4121.38

0

500

1000

1500

2000

2500

3000

3500

4000

4500

Megabytes

Avg Queued Replication Data (MB)


3000 Mailboxes Average Queued Replication Data

RepliStor

Double-Take

Figure 3: Average Remaining Replication Data in Queue with 3000 Mailboxes

During the 3000 Mailbox simulation, RepliStor achieved an average replication data transfer rate of 2.21 MB/se, whereas Double-Take achieved an average replication data transfer rate of 2.06 MB/sec. RepliStor saw an increase of 99.1% in data transfer rate from the 1500 mailbox workload to the 3000 mailbox workload, whereas Double-Take achieved a 66.1% increase above in data transfer rate with the increased workload. This result indicates RepliStor scaled more effectively than Double-Take with our workload simulation. Figure 3 below provides further comparison of these results as they pertain to how well the data transfer rate increased when the workload increased from 1500 to 3000 mailboxes. These findings indicate that RepliStor had not yet reached the upper limit of processing it is capable of achieving with Exchange Server 2003. However, with Double-Take, the 3000 mailbox user simulation was beyond the limit in which Double-Take was able to keep up with these Exchange 2003 processing demands.


Average Data Transfer Rate Comparison Between 1500 and 3000 Mailbox Workloads

1.11

1.24

2.21

2.06

0

0.5

1

1.5

2

2.5

RepliStor (99.1% Increase) Double-Take (66.1% Increase)


MB

/second

1500 Mailbox Avg Transfer Rate (MB)

3000 Mailbox Avg Transfer Rate (MB)

Figure 4: Average Transfer Rate Comparison between 1500 and 3000 Mailbox Workloads

A final 3000 mailbox LoadGen workload simulation was executed with data compression turned off within the replication solution. At the conclusion of the workload simulation, RepliStor contained 12100.14 MB of data in replication queue, whereas Double-Take contained 16444.84 MB of data in replication queue. The average replication data transfer rate for RepliStor during this simulation was 1.53 MB/sec, as compared to Double-Take which had an average rate of 1.41 MB/sec. The higher replication data transfer rate, along with less data queued at the end of the simulation indicates RepliStor kept up with the workload better than Double-Take. At the end of this workload simulation, Double-Take had 35.9% more data queued than RepliStor. This simulation also shows that both products benefit from the use of data compression.

Performance Comparison – Real-time-replication with SQL Server 2005

This section provides the results of the test cases comparing the real-time-replication (RTR) performance between RepliStor and Double-Take when replicating SQL Server 2005 (SQL05) data. ABC Systems wanted to measure how each product performed when replicating their SQL05 data during normal business operations, but wanted to focus on how each performed during typical SQL05 usage experienced in their environment. The Microsoft Database Hammer utility (DBHammer) was used to generate a workload that would cause continual database updates to occur, but at a rate that would not put more than 50% CPU load on the server running the SQL05 application. Pre-test tuning was conducted to find the DBHammer settings that would use between 45% and 50% CPU using the hardware SQL05 was installed on. It was determined that configuring DBHammer with 270 instances and a 20 millisecond interval achieved the desired CPU load. This simulation was run for one (1) hour and was configured to modify the “TEST” database being replicated. Please refer to the Test Methodology section of this study for further configuration details.


The specific CPU utilization percentage experienced for RepliStor was 46.93% and 49.69% with Double-Take. In addition, to further verify the same DBHammer workload was being exercised for both products during the RTR workload simulation, the Total SQL Transactions/second PerfMon metric was recorded. RepliStor reported an average Total SQL Transactions/second rate of 8368.90, and Double-Take reported a value of 8501.47, this is a difference of 1.58% which is within a range which is statistically immaterial. Each product was configured to replicate the SQL05 database and log file data to an identically configured system connected via a WAN simulator. A dedicated interface was used to transfer the replication data. For this test, the following two metrics were focused on to determine which replication solution was able to provide the best replication performance under the SQL05 RTR workload simulation:

o Average Replication Data Transfer Rate – Measured by the average rate data is sent to the target during the workload simulation. The rate is defined as the actual bytes that are transferred to the target once decompression of the data stream has completed. For example, if 1 GB of data is compressed to 100MB and sent across the WAN link (using 100MB of available bandwidth); the actual data transferred is recorded as 1 GB and not the actual line usage of 100 MB. This metric provides a good understanding of how quickly data is being replicated from the source to the target system during day-to-day operation. This data is derived from each replication solution’s Windows PerfMon metric that reports the total bytes transferred from the source to the target.

o Average Remaining Bytes in Replication Queue – This value reflects the amount of

replication data queued on the source SQL05 server which has not yet been replicated (transferred) to the target SQL05 server. This data is derived from the replication solution’s Windows PerfMon metric which reports data queued to the target.

In this scenario, RepliStor was able to keep up with the workload better than Double-Take with this workload simulation. At the conclusion of the 1 hour simulation, RepliStor had an average of 179.44 MB of replication data queued on the source SQL05 system; whereas Double-Take had an average of 30475.64 MB of replication data queued at the end of the simulation. In other words, Double-Take had 169.84 times more data queued for replication on the source than RepliStor did. Figure 5 below provides further example of this comparison.


179.44

30475.64

0

5000

10000

15000

20000

25000

30000

35000

Megabytes

Average Remaining Bytes in Replication Queue (MB)


SQL 2005: Average Remaining Queued Replication Data

RepliStor

Double-Take

Figure 5: Average Remaining Replication Data in Queue

This large of a difference in performance prompted the VeriTest Test Engineer to contact Double-Take support. After several phone and support ticket correspondence, it was determined that there was not an issue with the configuration of the environment, or with the Double-Take software configuration. It was determined with the assistance of Double-Take support that something was triggering a “Paused” state (during this state the Double-Take application does not transmit any data to the target system). Numerous trouble-shooting efforts were executed to try and identify what was causing the “Paused” state condition. It was isolated by the VeriTest Test Engineer that when the WAN simulator impairment that dropped every 10000

th packet was in place (as it was during the workload simulation) this “Paused” state condition would be

experienced. If the “Dropped Packet” impairment was disabled, the “Paused” state condition would not be experienced. It is important to reiterate that the same WAN simulator settings were being used for both RepliStor and Double-Take applications. The recommendation from Double-Take support was to upgrade to a newly released version of Double-Take (version 5). However, since the focus of this study was to compare the latest stable release available of both products when this study started, we are presenting the results here using the Double-Take 4.5.2 version. During the workload simulation, RepliStor achieved an average replication data transfer rate of 4.63 MB/sec whereas Double-Take achieved a 1.80 MB/. This result shows that RepliStor was able to achieve a transfer rate that was 157% greater than what Double-Take achieved. Part of this may be explained by the bug encountered discussed above. However, RepliStor was able to perform at a rate that was significantly higher than what Double-Take was able to maintain. Figure 6 below represents this difference in transfer rate performance.


SQL 2005: Average Replicaton Data Transfer Rate

4.63

1.8

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5


MB

/second

RepliStor

Double-Take

Figure 6: Average Transfer Rate during SQL Server 2005 Workload

Conclusions

In many areas, RepliStor and Double-Take report similar features. However, in several key areas such as Failover and VSS support, RepliStor provided a more integrated approach. With VSS, RepliStor’s deeper integration with the application writer leads to a configuration in which the end-user would not experience any downtime when VSS snapshots were taken. However, with Double-Take a downtime would be experienced. Also, the use of alias functionality RepliStor employs does not require Active Directory changes for Exchange Server 2003 failover to occur. In addition, the inclusion of built-in reporting and simulation features with RepliStor were a nice bonus. The ability of the Double-Take application to automatically check for updated versions is a nice feature that RepliStor did not provide. The RepliStor process for configuring a replication pair to a protected state, using SQL Server 2005 as the example application protected, required less time and fewer steps. In addition, the modularized approach provided with RepliStor was found to be more intuitive, and provided for a more streamlined approach to configuring SQL Server 2005 to a protected state. As the Exchange 2003 workload increased RepliStor was able to scale its performance more effectively to keep up with the increased workload, whereas Double-Take was not able to keep pace with the increased workload. Although both products were able to keep up with the 1500 mailbox workload simulated, only RepliStor was able to keep up with the 3000 mailbox workload to provide adequate protection. Although both products did not completely keep up with the E2K3 3000 mailbox workload when data compression was disabled, we found RepliStor was able to keep up with the workload better than Double-Take was able to. This simulation shows that both products benefit from the use of data compression, however, only RepliStor saw a benefit that allowed it to perform at the level necessary to provide adequate data protection.


Overall testing showed that the RepliStor solution provided more features that met the criteria of ABC Solutions, as well as providing a better usability experience when performing the tasks necessary to achieve a protected state for the SQL Server 2005 installation. In addition, RepliStor performed better when processing real-time replication data changes under the workload simulations we conducted in this study.

Testing Methodology This section provides details on the specific test cases executed by VeriTest. The focus of this study compares the features, usability and performance of two data replication technologies: EMC Corporation’s RepliStor and Double-Take Software’s Double-Take. For the purposes of this study, a fictitious company was created called ABC Systems. ABC Systems has two types of mission critical data that need to be protected from disaster, and also to provide redundancy during times of maintenance; Exchange Server 2003 and SQL Server 2005. ABC Systems decided to test both the RepliStor and Double-Take solutions to determine which product best met their criteria for a solution that provides the features, usability and performance. For this comparison study, ABC Systems had the following requirements:

• Provide Real-Time-Replication (RTR) support for Exchange Server 2003 and SQL Server 2005.

• Provide failover and failback capabilities with both Exchange Server 2003 and SQL Server 2005.

• Integration with Microsoft Volume Shadow Copy Services (VSS), specifically with relation to Exchange Server 2003 and SQL Server 2005.

• The replication solution should be able to provide Real-Time-Replication protection under the workloads experienced by ABC Systems, with minimal delay between source and target replication updates.

• The replication solution should provide a usability experience during initial software installation, protection configuration, and daily maintenance which require the least effort by the system administrator.

A single Windows Server 2003 Active Directory domain was setup as the test bed environment to perform the various usability and performance comparisons detailed in this study. The domain consisted of one Microsoft Windows Server 2003 Active Directory domain controller server providing all AD services to the test bed environment. A Microsoft Exchange Server 2003 (E2K3) system was configured as the “source” production server along with an identically configured server acting as the “target” replication system. A Microsoft SQL Server 2005 (SQL05) system was also configured as the “source” production SQL server, along with an identically configured “target” replication server. In addition, the domain contained one dedicated Microsoft Exchange Load Generator (LoadGen) x86 server and one dedicated Microsoft SQL Server Database Hammer (DBHammer) load generator server, which were each used to generate the client load for each application replicated. All systems had Microsoft Windows Server 2003 R2 w/SP2 OS installed. For this study, we compared EMC Corporation’s RepliStor v6.2 SP1 and Double-Take Software’s Double-Take v4.5.2. Each product was configured with defaults, other than the following settings:

• RepliStor: o Queue Memory was increased from the default of 5% to a static 1024 MB o FastWAN settings were selected. o Target Connections was increased from the default of 8 to 16.

• Double-Take o Memory Queue increased from default of 128 MB to 1024 MB. o Compression level set to “2” when used.

To simulate a WAN connection with various impairments an Anue Systems network simulator was employed. This device was a “maui” class device with two GEM based blades installed. Each blade used a copper-based gigabit Ethernet RJ-45 connection. The simulated line was set to a T3 (DS3) connection rate of 45 megabits per second (Mbps). In addition, the following impairment settings were setup to simulate various conditions experienced over WAN links that can negatively impact performance:


• Jitter: Each packet was set to experience 40 milliseconds latency for both RX and TX traffic, resulting in a total round-trip latency of 80 milliseconds.

• Dropped packets: 1 out of every 10000 packets was dropped. This was set uniformly.

• Duplicate packets: 1 out of every 50000 packets was duplicated. This was set uniformly.

• Reordered packets: 1 out of every 100000 packets was reordered. This was set uniformly.

• Corrupt packets: 1 out of every 1000000 packets was corrupted. This was set uniformly. Both replication products were configured to send all replication traffic over a dedicated interface configured on both the source and target replication system. This interface was routed through the WAN simulator. For e-mail ABC Systems currently uses a Microsoft Exchange 2003 solution. In addition, ABC Solutions currently has approximately 1500 e-mail users; however, the number of e-mail users is expected to grow to 3000 users. Therefore, ABC Systems wants to compare replication of e-mail workloads at both 1500 and 3000 user mailbox levels. For database, ABC Systems uses a Microsoft SQL Server 2005 solution. Currently ABC Systems database data consumes approximately 200 GB of data. Therefore, as we constructed the ABC Systems environment we created a SQL database of 200 GB that needed to be replicated. In addition, ABC Systems experiences a fairly consistent database workload, therefore, it is important that the workload simulated is of a consistent usage nature to best determine which replication solution is able to maintain pace with the changes occurring in real-time on the production database. Please refer to Appendix A for a detailed diagram of the test bed environment’s network topology. As previously mentioned, ABC Systems is interested in comparing the features available to them from each replication solution. This aspect of the study was mainly a research effort in which advertised features are compared between RepliStor and Double-Take. Key features such as VSS integration and failover/failback of the protected system are compared in more detail. In addition to comparing key features between the two replication solutions, this study also present a specific usability comparison between the two products when deployed using the SQL Server 2005 application as the target application to be protected. A series of tasks were identified to simulate the initial setup and configuration experienced when deploying the replication solution within the ABC Systems’ SQL Server 2005 production environment. The number of steps and time required to complete these tasks is compared as part of this study. A step was defined as a point in which a mouse action occurred (such as selecting a radio button), as well as any typed actions (such as filling in a text field). At a high-level the tasks that needed to be executed included:

• Replication Software Installation.

• Replication Dataset Configuration.

• Initial Synchronization/mirroring configuration process.

• VSS Configuration within the Replication Solution.

• Failover Configuration process. Please refer to Appendix E for further details on the steps executed during the usability comparison for each replication solution. Day-to-day real-time replication (RTR) performance of the replication solution is important for ABC Systems. It is important that a replication solution is able to keep up with the day-to-day demands placed on the core services being protected. To test the relative performance of the replication solutions, industry standard workload generation tools were utilized to simulate the day-to-day workload experienced in the ABC Systems production environment. For Exchange Server 2003 workload comparison the Microsoft Exchange Load Generator tool was utilized to simulate workloads at both 1500 and 3000 mailbox levels. For SQL Server 2005 workload generation the SQL Server tool Database Hammer was used to generate a rapid series of database changes.


For all RTR test cases measured, compression was enabled within the replication solution. Double-Take provides three different levels of compression; we chose their compression level 2 (L2) as the level of compression to use during the workload simulations as our pre-test tuning revealed this setting provided the best balance between CPU utilization and compression rate. In addition, we also ran an Exchange Server 2003 with 3000 mailboxes simulation with compression disabled for both replication solutions.

Exchange Server 2003 Workload Simulation

This section contains details on how this study compared each replication solution’s performance when providing protection to Exchange 2003 (E2K3) w/SP2 based data. The source and target systems each used servers that contained the exact same hardware, firmware, and driver releases. Each system was installed with Windows Server 2003 R2 EE w/SP2 32-bit. The Exchange 2003 application was installed and configured following the Microsoft Exchange Server 2003 Deployment Guide: (http://www.microsoft.com/downloads/details.aspx?FamilyID=77B6D819-C7B3-42D1-8FBB-FE6339FFA1ED&displaylang=en). The source E2K3 server was configured to contain a total of 3000 mailboxes. Two Storage Groups were configured, each containing three Mailstores. Each Mailstore was configured to contain 500 mailboxes. The Exchange database files (EDB) were configured to reside on a separate Fibre Channel attached storage LUN from the Exchange log file data. Please refer to Appendix X for detailed E2K3 configuration information. Once E2K3 was installed on the source server, and configured to receive the mailbox data, mailbox data was loaded using Microsoft Load Generator (LoadGen). A dedicated LoadGen server was installed into the domain to be used throughout the RTR performance comparison. Once the initial mailbox data was loaded, the Mailstores were brought offline, and all Exchange services were stopped to ensure no data change could occur. This baseline database data and log file data was then copied to a backup location. Prior to each test run, the replication software was disabled and shutdown. Exchange mailboxes were taken offline, and Exchange services stopped on the source E2K3 server. The baseline mailbox database data was then copied from the backup location to the production location on the source E2K3 server. E2K3 baseline log data was not restored as this data was not necessary to the function of the E2K3 application, and was not data indicative of typical data-to-day usage being simulated. The replicated data on the target E2K3 server was deleted. Once all data was restored, the source and target E2K3 servers were rebooted to return to a “fresh” startup state. The system Event Logs were reviewed to verify applications were functioning properly. The E2K3 management GUI was also launched to verify mailboxes were online. The Replication software’s management GUI was then started up and the replication set was re-enabled. The data was allowed to replicate to the target system to achieve a synchronized/mirrored state, also referred to as a “protected” state. Once the source and target E2K3 servers are in a protected state, the RTR simulation can be started. First, the Windows Performance Monitor session is started, and then the Exchange LoadGen simulation is started. This simulation runs for approximately 10 hours, simulating an 8 hour day, using the MMB3 profile and Exchange 2003 Online client type. Each simulation is run twice (with the above baseline data reset procedure executed) to verify the consistency of the results, and then an average of the two runs is presented. Please refer to Appendix B for further details on the Exchange Server 2003 RTR performance test methodology.

SQL Server 2005 Workload Simulation

This section contains details on how this study compared each replication solution’s performance when providing protection to SQL Server 2005 (SQL05) based data. The source and target systems each used servers that contained the exact same hardware, firmware, and driver releases. Each system was installed with Windows Server 2003 R2 EE w/SP2 32-bit. The SQL Server 2005 application was installed following Microsoft Best Practices guides found at http://technet.microsoft.com/en-us/sqlserver/bb671430.aspx. The source SQL05 server was configured to use default installation paths, with the “default” instance setup. A test database called “TEST” was created, with an initial size of 200 GB. The SQL database files (mdf) were


configured to reside on a separate Fibre channel attached storage LUN from the SQL log file data. Please refer to Appendix X for detailed SQL05 configuration information. Once SQL05 was installed on the source server, and configured with the TEST database, the TEST database was populated with 10 million rows of data using the Microsoft Database Hammer (DBHammer) utility. A dedicated DBHammer server was installed into the domain to be used throughout the RTR performance comparison. Once the initial SQL data was loaded, SQL Server was brought offline, and all SQL services were stopped to ensure no data change could occur. This baseline database data and log file data was then copied to a backup location. Prior to each test run, the replication software was disabled and shutdown. SQL05 was taken offline, and SQL services stopped on the source SQL05 server. The baseline TEST database data was then copied from the backup location to the production location on the source SQL05 server. SQL05 baseline log data was not restored as this data was not necessary to the function of the SQL05 application, and was not data indicative of typical data-to-day usage being simulated, as it had been generated during the TEST database population exercise. The replicated data on the target SQL05 server was deleted. Once all data was restored, the source and target SQL05 servers were rebooted to return to a “fresh” startup state. The system Event Logs were reviewed to verify applications were functioning properly. The SQL05 management GUI was also launched to verify the TEST database was online. The Replication software’s management GUI was then started up and the replication set was re-enabled. The data was allowed to replicate to the target system to achieve a synchronized/mirrored state, also referred to as a “protected” state. Once the source and target SQL05 servers are in a protected state, the RTR simulation can be started. First, the Windows Performance Monitor session is started, and then the SQL05 simulation is started. This simulation was allowed to run for 1 hour, using 270 instances and 20 milliseconds latency. Each simulation was run twice (with the above baseline data reset procedure executed) to verify the consistency of the results, and then an average of the two runs is presented. Please refer to Appendix C for further details on the SQL Server 2005 RTR performance test methodology.


Appendix A

ABC Systems Replication Environment Topology


Appendix B

Microsoft Exchange Server 2003 Configuration and Workload Details

Below is the detailed configuration settings used for the Exchange Server 2003 installation.

• Operating System: Microsoft Windows Server 2003 R2 w/SP2 32-bit

• Exchange Version: 6.5.7638.1

• Storage Group Configuration: o Number of Storage Groups: 2 o Mailstores per Storage Group: 3

� Storage Group 1 (SG1) also contained the Public Folder Store o Mailboxes per Mailstore: 500 o Total Number of Mailboxes: 3000

• Storage Configuration: o Mailbox Layout:

� F:\ Drive configured to contain SG1 mailbox databases. � G:\ Drive configured to contain SG1 mailbox log files. � H:\ Drive configured to contain SG2 mailbox databases. � I:\ Drive configured to contain SG2 mailbox log files.

o Storage Protocol: Fibre Channel o Storage Array: EMC CLARiiON CX700

• Data Creation Method: o During the mailbox generation process, Exchange was configured to use “Circular Logging”. o Microsoft Exchange Load Generator v8.01.0136 was used with the following settings:

� Simulation Day Length: 8 hours � Simulation Run Length: 10 hours � Non-Stress Mode � Storage Group 1 contained 1500 mailboxes selected. � Storage Group 2 contained 1500 mailboxes selected. � Distribution Lists: Not configured. � Contact Settings: Not configured. � External Recipient Settings: Not configured. � UserGroup0 Configuration:

• Client Type: Outlook 2003 Online

• Action Profile: MMB3

• Pretest Logon: Checked.

• Container: OU=SG1 (1500 mailboxes) � UserGroup1 Configuration:

• Client Type: Outlook 2003 Online

• Action Profile: MMB3

• Pretest Logon: Checked.

• Container: OU=SG2 (1500 mailboxes) � Remote Load Generators: Not configured. � LoadGen was then executed to initialize the 3000 total mailboxes. � When the mailbox initialization process completed, LoadGen was then exited. � Exchange was brought offline and the database and log data generated was copied

to a backup location located on the CX700 (mapped as drive B:\). This data was retained to be used as the start point for each test cycle for both products.

• Workload Generation Method: o Exchange configuration was modified to disable the “Circular Logging” option. o Verify source and target are fully synchronized/mirrored. This can be verified by each

replication solution’s Management GUI. o Enable the WAN simulator settings. o Login to the “Source” Exchange 2003 server and start Windows Performance Monitor with

the following metrics captured at 10 second intervals. Set this to run for 14 hours to allow


data to be captured shortly before the simulation was started, and for a period of time after the simulation ended:

� RepliStor:

• RepliStor Server\Bandwidth Usage - Bytes Sent (bytes/sec)

• RepliStor Server\Bytes Sent (bytes/sec)

• RepliStor Site\Data Queued to Target (KB) � Double-Take:

• Double-Take Connection(_Total )\Bytes transferred

• Double-Take Connection(_Total )\Compressed bytes transferred

• Double-Take Connection(_Total )\Bytes in replication queue o Login to the Exchange LoadGen client system. o Start a LoadGen simulation using the settings identified above. For a simulation with only

1500 mailboxes, only UserGroup0 was defined. For a simulation with 3000 mailboxes, both UserGroup0 and UserGroup1 were defined.


Appendix C

Microsoft SQL Server 2005 Configuration and Workload Details

Below is the detailed configuration settings used for the SQL Server 2005 installation.

• Operating System: Microsoft Windows Server 2003 R2 w/SP2 32-bit

• SQL Server Version: SQL 2005 w/SP2 (v9.0.3042)

• Installation Settings: o Default Installation location selected. o Default Instance created. o Windows and SQL Authentication enabled. o Single database configured for performance testing purposes.

� Database Name: TEST � Database Size: 200GB � Database Location: F:\SQL05\TEST\ � Log File Location: G:\SQL05\TEST\

• Storage Configuration: o Database and log files split to two different LUNs. o Storage Protocol: Fibre Channel o Storage Array: EMC CLARiiON CX700

• Data Creation Method: o Database Hammer used to create data populated to the ‘TEST’ database. o The following process was used to create the data populated to the ‘TEST’ database on the

SQL Server: � Install Database Hammer from the Microsoft SQL Server tools. � Start the SQL Server Management Studio � Expand the Database tree to the TEST database location. � Right-click in the right-pane and select New Query. � In the SQLQuery1.sql window copy/paste the contents of the

C:\databasehammer\createdb.txt and execute. � In the SQLQuery1.sql window copy/paste the contents of the

C:\databasehammer\storedprocs.txt and execute. � It is necessary to setup the proper ODBC connection as well:

• Click Start -> Programs -> Administrator Tools -> Data Source (ODBC)

• Click on the SystemDSN tab.

• Highlight Local Server and click configure.

• Change the SQL Server to your server name. Click Next.

• Check the Radio button “With SQL Server Authentication”. Leave other settings at default values.

• Change login ID to the SQL Server administrator account (e.g. sa), and enter the password. Click Next.

• Click save. � If an ODBC connection does not exist, follow these steps:

• Click Start -> Programs -> Administrator Tools -> Data Source (ODBC)

• Click on the SystemDSN tab.

• Click Add

• Scroll to “SQL Server” and select that item. Click Finish.

• Set a name (e.g. system hostname)

• Click on the drop-down menu, select sql server name and then click Next.

• Check the radio button “With SQL Server Authentication”. Leave all other settings at default values.

• Set the login ID and password.

• Change the default database to the database setup for testing purposes (i.e. the “TEST” database).


• Click Next.

• Click Finish. � Now it is time to populate the TEST database with some data:

• Open a command prompt, and change to the c:\databasehammer directory.

• Execute: loadslave.exe

• Execute: loadmaster.exe o A window will pop up with various settings that need to be defined. o The following settings were used for this study:

� Server: <hostname of SQL server> � Database: TEST <name of database to populate> � UserID: sa � Password: <password for sa account>

o This will create 10 million rows of data. o Steps necessary to setup DBHammer on the client side for load generation. A separate

client was used to generate the SQL Server load during the Real-Time-Replication performance test case.

� Copy the C:\databasehammer directory from the SQL Server host to the client.

• Workload Generation Method: o Login to the SQL Server 2005 source server and execute Windows Performance Monitor.

This is set to run long enough to capture 60 minutes of SQL DBHammer generated workload with replication performance metrics.

o The following Performance Monitor metrics were captured during this period. These were captured at 10 second intervals.

� RepliStor:

• RepliStor Server\Bandwidth Usage - Bytes Sent (bytes/sec)

• RepliStor Server\Bytes Sent (bytes/sec)

• RepliStor Site\Data Queued to Target (KB) � Double-Take

• Double-Take Connection(_Total )\Bytes transferred

• Double-Take Connection(_Total )\Compressed bytes transferred

• Double-Take Connection(_Total )\Bytes in replication queue o Steps necessary to execute the DBHammer workload used during the Real-Time-Replication

performance test case: � Open a command prompt and change to the C:\databasehammer directory on the

client. � Execute: procslave.exe � Execute: procmaster.exe

• A window will pop up with various settings needing to be defined to run the load generation. For the purposes of this study, the following settings were used to generate the SQL Server load during the Real-Time-Replication performance test cases:

o Instances: 270 o Interval (ms): 20 o Server: <SQL Server hostname> o Database: Test o UserID: sa o Password: <sa password>

• This was run for 1 hour.


Appendix D

Hardware and Software Disclosures

• RepliStor Version Tested: 6.2 SP1

• Double-Take Version Tested: 4.5.2.1910

• Exchange 2003 Servers: Source and Target server used identical hardware specifications. o Operating System: Windows Server 2003 R2 w/SP2 Enterprise Edition (x86) o Exchange Version: Exchange Server 2003 w/SP2 o Hardware Specifications:

� CPU: 4 x Intel Xeon 5160 � RAM: 8 GB � NIC: 2 x Intel Pro/1000 EB � HDD: 2 x 72 GB SAS, 15K RPM (RAID-1)

o FCP HBA: � Manufacturer: QLogic � Model: QLA2340 � Driver: 9.1.7.16

• SQL 2005 Servers: Source and Target server used identical hardware specifications. o Operating System: Windows Server 2003 R2 w/SP2 Enterprise Edition (x86) o SQL Server 2005 Version: o Hardware Specifications:

� CPU: 4 x Intel Xeon 5160 � RAM: 8 GB � NIC: 2 x Intel Pro/1000 EB � HDD: 2 x 72 GB SAS, 15K RPM (RAID-1)

o FCP HBA: � Manufacturer: QLogic � Model: QLA2340 � Driver: 9.1.7.16

• Exchange Load Generator Server: o Operating System: Windows Server 2003 R2 w/SP2 Enterprise Edition (x86) o SQL Server 2005 Version: o Hardware Specifications:

� CPU: 4 x AMD Opteron 2220 � RAM: 8 GB � NIC: 2 x nVidia MCP55Pro GbE � HDD: 2 x 72 GB SAS, 15K RPM (RAID-1)

• SQL DBHammer Server: o Operating System: Windows Server 2003 R2 w/SP2 Enterprise Edition (x86) o SQL Version: SQL Server 2005 w/SP2 o Hardware Specifications:

� CPU: 4 x AMD Opteron 2220 � RAM: 8 GB � NIC: 2 x nVidia MCP55Pro GbE � HDD: 2 x 72 GB SAS, 15K RPM (RAID-1)

• Active Directory Domain Controller: o Operating System: Windows Server 2003 R2 w/SP2 Enterprise Edition (x86) o Hardware Specifications:

� CPU: 2 x Intel Xeon HT � RAM: 4 GB � NIC: 2 x � HDD: 2 x 36 GB SCSI, 15K RPM (RAID-1)

• WAN Simulator: o Manufacturer: Anue Systems


o Model: Maui o Software Version: 3.6

• Fibre Channel Switch: o Manufacturer: Brocade o Model: Silkworm 3800 o Software Version: 3.2

• Network Switch: o Manufacturer: Netgear o Model: GS748T o Software Version: 1.3.0_0606

• Storage Array (Source): o Vendor: EMC o Model: CLARiiON CX700 o FLARE OE: 2.19.700.5.007 o Disk Trays: 4 o Disk Type: 60 @ 144 GB, 15000 RPM, F-SCSI o RAID Groups: 8

� RAID Group 0: Hot Spare (1 Disk) � RAID Group 1: Hot Spare (1 Disk) � RAID Group 10: RAID1+0 (4 Disks)

• Number of LUNs: 1

• LUN Number: 10

• Exchange 2003 Database Storage (SG1) � RAID Group 11: RAID1+0 (4 Disks)


• LUN Number: 11

• Exchange 2003 Log File Storage (SG1) � RAID Group 20: RAID1+0 (4 Disks)


• LUN Number: 20

• Exchange 2003 Database Storage (SG2) � RAID Group 21: RAID1+0 (4 Disks)


• LUN Number: 21

• Exchange 2003 Log File Storage (SG2) � RAID Group 30: RAID1+0 (4 Disks)


• LUN Number: 30

• SQL Server 2005 Database Storage � RAID Group 31: RAID1+0 (4 Disks)


• LUN Number: 31

• SQL Server 2005 Log File Storage o Storage Groups: 2

� Storage Group 1:

• Name: E2K3

• LUNs: 4 (LUNs: 10,11,20,21) � Storage Group 2:

• Name: SQL05

• LUNs: 2 (LUNs: 30, 31)

• Storage Array (Target): o Vendor: EMC o Model: Clariion CX500 o FLARE OE: 2.19.500.5.034 o Disk Trays: 2


o Disk Type: 20 @ 144 GB, 15000 RPM, F-SCSI o RAID Groups: 2

� RAID Group 0: Hot Spare (1 disk) � RAID Group 1: RAID5 (16 disks)


• LUN10: E2K3 SG1 Database Replication

• LUN11: E2K3 SG1 Log File Replication



• LUN30: SQL05 Database Replication

• LUN31: SQL05 Log File Replication o Storage Groups: 2

� Storage Group 1:

• Name: E2K3

• LUNs: 4 (10, 11, 20, 21) � Storage Group 2:

• Name: SQL05

• LUNs: 2 (30, 31)


Appendix E

Detailed Steps Conducted for the Usability Comparison using SQL Server 2005

Note: For both products, the software to be installed was copied to local disk on the server for which it was to be installed on.

o RepliStor 1. Unpack the software archive by double-clicking on rep.6.2.SP1.msi file on the source

system. 2. Click Run. 3. Click OK. (Language selection did not need to be changed). 4. Click Next. 5. Click on the radio button to accept the license, and then click Next. 6. Click on checkbox to register server in Active Directory, other default values are

appropriate, click Next. 7. Default “Complete” installation selection is appropriate, click Next. 8. Enter the License Code, and then click Next. 9. Click on the Install button. 10. Click on the Finish button. 11. Repeat the above process on the “target” server. 12. Open up the RepliStor Datacenter GUI: Start -> All Programs -> RepliStor 13. Click Maintenance -> Manage Modules 14. Click on the Add button. 15. Select the RepliStorSQL.msi file. Click Open. 16. Click Next. 17. Click on the radio button to accept the license agreement, and then click Next. 18. Select the target server listed under the Select Target Site drop-down box. 19. Leave the Select Instance drop-down box on the <Default Instance> selection. 20. Click on the Configure Alias checkbox. 21. Type an alias name in the Alias to Create: text field. 22. Enter the IP Address to use for the Alias in the IP Address for Alias: text fields. 23. Click Next. 24. Leave radio button selected for the Disable the loopback check option, and then

click Next. 25. Click on the Configure VSS check box. 26. In the Maximum Shadow Copies: field enter a number, and then click Next.

• Note: This screen has the option to check these as Full Backups. This was left unchecked for this study.

27. Click on the Install button. 28. Click on the Finish button. 29. Right-click on the name of the Replication Set, under the Target Sites expansion and

click Enable All. 30. Right-click on the name of the Replication Set, under the Target Sites expansion, and

click Synchronize All. 31. When the synchronization tasks complete, the source/target pair are in a protected

state, failover is configured using the Alias function, and VSS functionality is enabled. Total Number of distinct Steps: 47 (including installation steps on target system).

o Double-Take: 1. Unzip the DTNT45201910_I386.exe archive on the source system. Click OK when

unzip operation completes. Installation program will automatically launch when the unzip operation completes.

2. Select the radio button to not check for an updated version of the DTNT software. Click Next.

3. Select the radio button to accept the license agreement, and then click Next.


4. Click Next. 5. Click Next. 6. Leave username and organization fields at default values, and enter the activation

code. 7. Click Next. 8. Confirm information, and then click Next. 9. Change the default for the Maximum system memory for Double-Take to queue…

from 128 MB to 1024 MB, and then click Next. 10. Leave the Minimum Disk Space Free: setting at 50 MB, and then click Next. 11. The Security Groups screen appears, read this information, then click Next. 12. Click on the Install button. 13. Click on the Finish button. 14. When installation completes, click on the Yes button to reboot the server.

• Note: Since RepliStor doesn’t require a reboot, the need to reboot after Double-Take is installed leads to a longer time required to install the software, not to mention the possible end-user downtime associated with rebooting a SQL Server 2005 server.

15. Repeat the above actions on the target system.

• For the purposes of this study we installed the DTAM application on the DBHammer load generation system.36

16. Login to the designated DTAM system and double-click on the DTAM_426B1903_setup.exe.

17. Click Next. 18. Select the radio button to accept the license agreement, and then click Next. 19. Click on the Install button. 20. Click on the Download SQLDMO button.

• Note: The amount of time required to download the DMO software is not counted in the total time for this study, however, the time required to install/configure is included.

21. Click on the Finish button. 22. Installed the SQL Server 2005 Backward compatibility software. 23. Click Next. 24. Select the radio button to accept the license agreement, and then click Next. 25. Click Next. 26. Feature Selection screen is presented. Leave at defaults, and then click Next. 27. Click on the Install button. 28. Click on the Finish button. 29. Launch the Double Take Application Manager GUI: Start -> All Programs ->

Double-Take -> Application Manager. 30. Select the Protect SQL Server task. 31. Enter the Windows Domain Name. 32. Server Login window is presented. Enter the Domain User Name to use

(DOMAIN\Administrator) and Password. Click OK. 33. Select the Source and Target Server from the drop-down menus. 34. Click on the Configure button. 35. On the Failover tab, select the Failover Enabled checkbox. 36. Select DNS Failover, and then click on the Configure button. 37. Verify DNS Server information is accurate, and select the Source IP addresses to be

monitored. Update the TTL to 600 seconds. Enter the DNS Credentials, and then click OK.

• Note: The TTL was set to 600 as 1200 was later reported as too long when the failover configuration was validated by DTAM.

38. On the Connection tab, verify the target IP address in the drop down menu. Select the radio button for SQL Instance, and verify all components are selected properly. Select the radio button for a mirror type of checksum. Click on the checkbox for Enable Compression, and set compression to the middle (L2). Click on OK.

39. Click on the Validate button.


40. Several warnings appeared regarding the SQL server services running and transaction control process. DTAM was allowed to automatically fix all these.

41. Click on the Enable Protection button. 42. The initial synchronization process is started to bring the source/target systems to a

protected state. At this point HA, failover and protection are fully configured, however, VSS has not yet been configured.

43. The following steps were executed based on the Double-Take document: Guidelines for Protecting Data Using Double-Take with Volume Shadow Copy Service (VSS). The process to setup crash-consistent synchronous snapshots was followed as that was the recommended approach with transactional database data.

1. Login to the source SQL server. 2. Launch the DT management console. 3. In the DT Management Console, double-click on the source server to log in. 4. Right-click on the server and choose properties. 5. Click on the setup tab and Select Enable Task Command Processing. 6. Repeat the above on the target SQL Server. 7. Install the sample VSS snap scripts to their appropriate locations as well as

the sample TASK.txt file.

• Note: For the purposes of this study, these sample scripts were not modified from the default state. Therefore, only the steps to install these to their proper locations and the time that required are calculated. However, if customizations were required, then additional time would be necessary to enable VSS functionality with the Double-Take solution.


VeriTest (www.veritest.com), the testing service of Lionbridge Technologies, Inc., provides outsourced testing solutions that maximize revenue and reduce costs for our clients. For companies who use high-tech products as well as those who produce them, smoothly functioning technology is essential to business success. VeriTest helps our clients identify and correct technology problems in their products and in their line of business applications by providing the widest range of testing services available.

VeriTest created the suite of industry-standard benchmark software that includes WebBench, NetBench, Winstone, and WinBench. We've distributed over 20 million copies of these tools, which are in use at every one of the 2001 Fortune 100 companies. Our Internet BenchMark service provides the definitive ratings for Internet Service Providers in the US, Canada, and the UK.

Under our former names of ZD Labs and eTesting Labs, and as part of VeriTest since July of 2002, we have delivered rigorous, objective, independent testing and analysis for over a decade. With the most knowledgeable staff in the business, testing facilities around the world, and almost 1,600 dedicated network PCs, VeriTest offers our clients the expertise and equipment necessary to meet all their testing needs.

For more information email us at [email protected] or call us at 919-380-2800.

Disclaimer of Warranties; Limitation of Liability: VERITEST HAS MADE REASONABLE EFFORTS TO ENSURE THE ACCURACY AND VALIDITY OF ITS TESTING, HOWEVER, VERITEST SPECIFICALLY DISCLAIMS ANY WARRANTY, EXPRESSED OR IMPLIED, RELATING TO THE TEST RESULTS AND ANALYSIS, THEIR ACCURACY, COMPLETENESS OR QUALITY, INCLUDING ANY IMPLIED WARRANTY OF FITNESS FOR ANY PARTICULAR PURPOSE. ALL PERSONS OR ENTITIES RELYING ON THE RESULTS OF ANY TESTING DO SO AT THEIR OWN RISK, AND AGREE THAT VERITEST, ITS EMPLOYEES AND ITS SUBCONTRACTORS SHALL HAVE NO LIABILITY WHATSOEVER FROM ANY CLAIM OF LOSS OR DAMAGE ON ACCOUNT OF ANY ALLEGED ERROR OR DEFECT IN ANY TESTING PROCEDURE OR RESULT. IN NO EVENT SHALL VERITEST BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH ITS TESTING, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL VERITEST'S LIABILITY, INCLUDING FOR DIRECT DAMAGES, EXCEED THE AMOUNTS PAID IN CONNECTION WITH VERITEST'S TESTING. CUSTOMER’S SOLE AND EXCLUSIVE REMEDIES ARE AS SET FORTH HEREIN.

EMC RepliStor vs Double Take 062008

Documents

Transcript of EMC RepliStor vs Double Take 062008