You are here: Connections > Data queues > Queuing data

Queuing data

You should configure queuing on both the source and target.

Open the Replication Console and right-click the server on the left pane of the Replication Console.
Select Properties.
Select the Queue tab.
Specify the queue settings for the server.

Folder—This is the location where the disk queue will be stored. Double-Take Availability displays the amount of free space on the volume selected. Any changes made to the queue location will not take effect until the Double-Take service has been restarted on the server.

Select a location on a non-clustered volume that will have minimal impact on the operating system and applications being protected. For best results and reliability, this should be a dedicated, non-boot volume. The disk queue should not be on the same physical or logical volume as the data being replicated. Also, for best results, select a location that is on a different volume as the location of the Windows pagefile.

Although the read/write ratio on queue files will be 1:1, optimizing the disk for write activity will benefit performance because the writes will typically be occurring when the server is under a high load, and more reads will be occurring after the load is reduced. Accordingly, use a standalone disk, mirrored (RAID 1) or non-parity striped (RAID 0) RAID set, and allocate more I/O adapter cache memory to writes for best performance. A RAID 5 array will not perform as well as a mirrored or non-parity striped set because writing to a RAID 5 array incurs the overhead of generating and writing parity data. RAID 5 write performance can be up to 50% less than the write performance of a single disk, depending on the adapter and disk.

Another option is to use a solid state disk, which are hard drives that use RAM instead of disk platters. These devices are typically quite costly, but they will provide superior performance as a queuing device when the best performance is required.

Note:

Scanning the Double-Take Availability queue files for viruses can cause unexpected results. If anti-virus software detects a virus in a queue file and deletes or moves it, data integrity on the target cannot be guaranteed. As long as you have your anti-virus software configured to protect the actual production data, the anti-virus software can clean, delete, or move an infected file and the clean, delete, or move will be replicated to the target. This will keep the target from becoming infected and will not impact the Double-Take Availability queues.

Maximum system memory for queue—This is the amount of Windows system memory, in MB, that will be used to store data in queues. When exceeded, queuing to disk will be triggered. This value is dependent on the amount of physical memory available but has a minimum of 32 MB. By default, 128 MB or 512 MB of memory is used, depending on your operating system. If you set it lower, Double-Take Availability will use less system memory, but you will queue to disk sooner which may impact system performance. If you set it higher, Double-Take Availability will maximize system performance by not queuing to disk as soon, but the system may have to swap the memory to disk if the system memory is not available.

Since the source is typically running a production application, it is important that the amount of memory Double-Take Availability and the other applications use does not exceed the amount of RAM in the system. If the applications are configured to use more memory than there is RAM, the system will begin to swap pages of memory to disk and the system performance will degrade. For example, by default an application may be configured to use all of the available system memory when needed, and this may happen during high-load operations. These high-load operations cause Double-Take Availability to need memory to queue the data being changed by the application. In this case, you would need to configure the applications so that they collectively do not exceed the amount of RAM on the server. Perhaps on a server with 1 GB of RAM running the application and Double-Take Availability, you might configure the application to use 512 MB and Double-Take Availability to use 256 MB, leaving 256 MB for the operating system and other applications on the system. Many server applications default to using all available system memory, so it is important to check and configure applications appropriately, particularly on high-capacity servers.

Any changes to the memory usage will not take effect until the Double-Take service has been restarted on the server.

Maximum disk space for queue—This is the maximum amount of disk space, in MB, in the specified Folder that can be used for Double-Take Availability disk queuing, or you can select Unlimited which will allow the queue usage to automatically expand whenever the available disk space expands. When the disk space limit is reached, Double-Take Availability will automatically begin the auto-disconnect process. By default, Double-Take Availability will use an unlimited amount of disk space. Setting this value to zero (0) disables disk queuing.
Minimum Free Space—This is the minimum amount of disk space in the specified Folder that must be available at all times. By default, 50 MB of disk space will always remain free. The Minimum Free Space should be less than the amount of physical disk space minus Maximum disk space for queue.

Note:

The Maximum disk space for queue and Minimum Free Space settings work in conjunction with each other. For example, assume your queues are stored on a 10 GB disk with the Maximum disk space for queue set to 10 GB and the Minimum Free Space set to 500 MB. If another program uses 5 GB, Double-Take Availability will only be able to use 4.5 GB so that 500 MB remains free.

Specify the Alert at following queue usage percentage. This is the percentage of the disk queue that must be in use to trigger an alert message in the Linux system log. By default, the alert will be generated when the queue reaches 50%.

Click OK to save the settings.