Open topic with navigation
General optimizations
The following are general optimizations that can be used for any Double-Take Availability workload type.
- Initial mirror across slow network—A large amount of data that is being mirrored across a slow network may take days to complete the initial mirror, depending on the amount of data and the available bandwidth. You may want to consider the following options to reduce the amount of time for the initial mirror.
- Move the target server to the source's site for the initial mirror. When the mirror is complete, move the target server to its permanent location and create a new job using a difference mirror.
- Archive the data to media that can be transported to the target site and restored to the target server. When the data is restored to the target, create the job using a difference mirror.
- Create a compressed archive of the source data, copy the archive to the target, uncompress the data, and then create the job using a difference mirror.
- Disable replication during the initial mirror. This will allow the mirror to complete as quickly as possible without having to contend with replication traffic for bandwidth. After the mirror is complete, start replication and start a difference mirror.
- Compression—Double-Take Availability compression should be used when network bandwidth between the source and target is limited. In some cases, performance may also be improved by enabling compression in high-bandwidth environments. The best level of compression for a given solution will depend on a number of factors, including the type of data being replicated, CPU load, and available bandwidth. Since compression settings can be changed dynamically, the easiest way to find the best level of compression is to enable it at level 1 and monitor the results. If data is still being queued on the source, increase the compression level to 2 or 3. If CPU load becomes an issue on the server, decrease the compression level.
- Low bandwidth and queuing—In low bandwidth environments, you may need to revisit the queuing configuration you established when you were installing Double-Take Availability. See the installation optimizations and Double-Take Availability queue for more details on the memory and disk queue usage.
- High latency and mirror packet size—In a high latency environment (greater than 100 ms response times), you may want to consider increasing the size of the packets of mirror data. The default value is 65536 bytes. You may want to double that to 131072 bytes. This option is available through the source server properties.
- High latency and MaxChecksumBlocks—In a high latency environment (greater than 100 ms response times), you may want to consider increasing the number of checksum values retrieved from the target. The default is 32. You may want to double that to 64. This option is available under HKEY_LOCAL_MACHINE\SOFTWARE\NSI Software\Double-Take\CurrentVersion\MaxChecksumBlocks. The value is hexadecimal. See Server Settings in the Scripting Guide for more details on this option.
- Target write speed—In high-bandwidth environments, Double-Take Availability throughput is most often limited by the write speed of the target disks. Accordingly, optimizing the target disks for write performance will often increase Double-Take Availability performance, particularly for full mirrors and high loads of replication. Using RAID 0 and/or RAID 1 instead of RAID 5 on the target disks will improve the target write performance, as well as allocating some (or all) of the I/O controller's cache memory to write operations.
- TCPBufferSize—Network throughout is directly related to the TCP buffer size and the network latency of the LAN or WAN connection. By default, Double-Take Availability is configured for a 1Gbit LAN network. If you are replicating across a different LAN network or a WAN network, adjust the TCP buffer size accordingly. For example, for a 100Mbit LAN, the value should be around 37500, and for a WAN, the value should be around 130000. This option is available under HKEY_LOCAL_MACHINE\SOFTWARE\NSI Software\Double-Take\CurrentVersion\TCPBufferSize. The value is hexadecimal. For more details, see Server Settings in the Scripting Guide or the technical support article 1483.
- Windows MTU—The Maximum Transmission Unit (MTU) is the largest amount of data, a packet, that can be transferred in one physical frame on a network. If the MTU is too high, you may get fragmented packets which can slow down Double-Take Availability mirroring and replication and can possibly cause lost Double-Take Availability connections. Use the ping command with the -f -l 1500 options. If you receive a response that packets need to be fragmented, you should lower your MTU value. See the Microsoft article 314825 for details on specifying the MTU value.
- Disable root encryption—If the top-level folders in your jobs are not encrypted, you can gain a performance improvement by disabling root encryption. This option is available under HKEY_LOCAL_MACHINE\SOFTWARE\NSI Software\Double-Take\CurrentVersion\EnableRootEncryption. The value is hexadecimal. The valid values are 0 to disable root encryption or 1 to enable root encryption. See Server Settings in the Scripting Guide for more details on this option.
- Temporary files—Some applications create temporary files that are used to store information that may not be
necessary to replicate. If user profiles and home directories are stored on a server and replicated, some unexpected data
may be replicated if applications use the \Local Settings\Temp directory to store data. This could result in significant
amount of unnecessary data replication on large file servers. Additionally, the \Local Settings\Temporary Internet Files
directory can easily reach a few thousand files and dozens of megabytes. When this is multiplied by a hundred users it
can quickly add up to several gigabytes of data that do not need to be replicated. You may want to consider excluding temporary data like this, however it is important to know how applications may use these temporary files. For example, Microsoft Word creates a temporary file when a document is opened. When the user closes the file, the temporary file is renamed to the original file and the original file is deleted. In this case, you must replicate that temporary file so that Double-Take Availability can process the rename and delete operations appropriately on the target.
- E-mail notification—Enable e-mail notification through the e-mail notification server properties so that you are notified when a Double-Take Availability message is written to the Event log for that server.
- Target path blocking—Target path blocking prevents the modification of the copy of the source data on the target until failover has occurred or protection is disabled. This can be can be configured for some job types or for all jobs to a target through the target server properties.
- File difference mirrors—When performing a file difference mirror (or file difference restoration), you may not want to use the Send data only if Source is newer than Target option, unless you know for certain that it is acceptable. This is particularly true for database
applications since it is critical that all files, not just some of them that might be newer, are mirrored/restored.
- Disable attribute replication—On servers where the file permissions need to be different on the source and target, you can disable the replication of file attributes. When attribute replication is disabled, files on the target can inherit permissions from the parent directory on the target. This option is available under HKEY_LOCAL_MACHINE\SOFTWARE\NSI Software\Double-Take\CurrentVersion\TGDisableAttributeReplication. The value is hexadecimal. The valid values are 0 to replicate attributes or 1 to not replicate attributes. See Server Settings in the Scripting Guide for more details on this option.
- Double-Take Availability queue—Exclude the Double-Take Availability queue directory on the source and target from any real-time scanning or scheduled system scans. If a queue file is deleted by a process other than Double-Take Availability, unexpected results may occur, including an auto-disconnect due to the loss of queued data. The files in the source queue directory have already been scanned (cleaned, deleted, or quarantined) in their original storage location. The files in the target queue have already been scanned (cleaned, deleted, or quarantined) on the source.
- Target data—Exclude the copy of the source data stored on the target from any real-time scanning or scheduled system scans. The files have already been scanned (cleaned, deleted, or quarantined) on the source. If the replicated data on the target must be scanned for viruses, configure the virus protection software on both the source and target to delete or quarantine infected files to a different directory that is not being protected. If the virus software denies access to the file because it is infected, Double-Take Availability will continually attempt to commit operations to that file until it is successful, and will not commit any other data until it can write to that file. Additionally, if the virus protection software cleans the file, an operation to clean the file will likely also be replicated from the source, which may result in file corruption.
- NIC teaming—If you are using NIC teaming, set it up for fault tolerance, not load balancing.
- Device drivers—Keep your hardware device drivers, especially NIC drivers, up-to-date.
- Port speed and duplex—Set static values for port speed and duplex on NICs and switches, if possible.
Performance optimizations