Evaluating Double-Take Availability

1. Start the Double-Take Availability Replication Console by selecting Start, Programs, Double-Take for Linux, Double-Take Replication Console.

2. Click Make a connection from the right pane of the Replication Console. If that quick launch screen is no longer visible, select Tools, Connection Wizard.

   If the Double-Take Servers root is highlighted in the left pane of the Replication Console, the Connection Wizard menu option will not be available. To access the menu, expand the server tree in the left pane, and highlight a server in the tree.

    

3. The Connection Wizard opens to the Welcome screen. Review this screen and click Next to continue.

   At any time while using the Connection Wizard, click Back to return to previous screens and review your selections.

    

4. If you highlighted a source in the Replication Console, the source will already be selected. If it is not, select the Double-Take Availability source. This is the server that you want to protect. Click Next to continue.

   Double-Take Availability will automatically attempt to log on to the selected source using previously cached credentials. If the logon is not successful, the Logon dialog box will appear prompting for your security identification.

    

5. If you highlighted a target in the Replication Console, the target will already be selected. If it is not, select the Double-Take Availability target. This is your backup server that will protect the source. Click Next to continue.

   Double-Take Availability will automatically attempt to log on to the selected targetusing previously cached credentials. If the logon is not successful, the Logon dialog box will appear prompting for your security identification.

    

6. On the next screen, verify Create a new replication set with this name is selected.
7. Enter a name for your replication set, and click Next to continue.
8. A tree display appears identifying the volumes and directories available on your source. Mark the check box of the volumes and/or directories you want to protect. Click Next to continue.
9. There are two pre-defined locations to store the source data on the target, or you can select a custom location. For this evaluation, select the option Send all data to the same path on the target. This option keeps the directory structure on the source and target identical. For example, /var/data is transmitted to /var/data. Click Next to continue.
10. Review your selections on the summary screen. You do not need to set any advanced options for this evaluation, so click Finish. The Connection Wizard will close, the connection will be established, and mirroring and replication will begin.
11. You will be prompted to save your newly created replication set. Click Yes to save it.

View your new connection in the Replication Console by highlighting the source on the left pane. The connection will appear on the right pane. Use the horizontal scroll bar at the bottom of the right pane to view the various status columns. Pay attention to the Mirror Status column which shows the status of the mirroring operation. During the mirroring process, you will see a percentage of the mirror that has been completed. When the Mirror Status changes to Idle, there is no mirroring activity, meaning your initial mirror has completed.

To view specific mirroring statistics that may be of interest, use the horizontal scroll bar at the bottom of the right pane of the Replication Console window to view the various columns.

• Sent (Bytes)—The total number of mirror and replication bytes that have been sent during this connection.
• Sent Mirror (Bytes)—The total number of mirror bytes only that have been sent during this connection.
• Skipped Mirror (Bytes)—The total number of bytes that have been skipped when performing a difference or checksum mirror. These bytes are skipped because the data is the same on the source and target machines.
• Remaining Mirror (Bytes)—The total number of mirror bytes only that remain to be sent to the target.

Monitoring a connection through the Replication Console contains complete details on all of the Replication Console statistics.

After your mirror is complete, look at your target and you will see the replicated data stored in the location you specified. Now you are ready to continue with the evaluation.

In order to test replication, you need to change the data on your source. This includes modifying existing files, creating new files, deleting files, and changing permissions and attributes.

1. On the source, browse through the directories and files contained in your replication set.
2. Select four files from your source and record the file name, date, time, and file size for each file.
3. On your target, locate those same four files that you just identified on your source. The files on the target match the files on the source.
4. Back on your source, view the contents of one of your files contained in your replication set and note the file contents.
5. On your target, view that same file that you just viewed on the source. The file contents on the target match the file contents on the source.
6. Highlight your source in the left pane of the Replication Console.
7. Locate the Replication Status and Sent (Bytes) columns in the right pane.
8. Tile your Replication Console so that you can see it while still having access to your desktop.
9. On your source, edit the file that you viewed above. Save your changes, and watch the Replication Console statistics as the file change causes replication to occur.
10. Modify the other three files so that the date, time, and/or size is updated, and again watch the Replication Console statistics as the file changes cause replication to occur. While Double-Take Availability is actively replicating, the status will be Replicating. When there is no replication activity, the status is Ready.
11. Use the horizontal scroll bars to display additional replication statistics.
• Sent (Bytes)—The total number of mirror and replication bytes that have been sent during this connection
• Queued Replication (Bytes)—The total number of replication bytes that remain in the source queue
• Sent Replication (Bytes)—The total number of replication bytes that have been sent during this connection
• Last File Touched—Identifies the last file that Double-Take Availability transmitted to the target

Monitoring a connection through the Replication Console contains complete details on all of the Replication Console statistics.

Many user applications typically save an entire file even though only a portion of the file may have changed. Therefore, the replication statistics will show the entire file being transmitted, not just the changed data. To confirm that replication only transmits the changed segments of files, you must use an application, such as a database application, or a command, such as the echo command, to save only the changed portions of a file.

 

You may notice your Replication Status toggle between Replicating and Ready as it continues processing the file changes, when your Replication Status stays at Ready, Double-Take Availability is waiting for additional changes to transmit. After replication is complete, you are ready to continue with the evaluation.

Now that you have modified some of the files, you want to be sure that the file modifications were applied correctly.

Machines that are doing minimal or light processing, as you are in this evaluation, may have file operations that remain in memory until additional operations flush them out and they are written to disk. This may make Double-Take Availability files on the target appear as if they are not synchronized. When the operations in memory are released, the files will be updated on the target. To make sure this does not impact your testing, flush memory by copying a couple of files from one directory to another and then deleting them. You can also use the sync program (which exercises the sync(2) system call) to flush memory.

 

1. Browse your source and target. Compare the directory structures and the total number of files.
2. Look again at the four files you modified earlier. Verify manually that the changes you made have been applied to the target copy of the file.
3. Right-click the connection on the right pane of the Replication Console and select Verify. You will see two choices on the Start Verification dialog box.
• Verify only—This option performs the verification process by comparing the date, time and size of each file and generates a verification report identifying the files that are not synchronized.
• Remirror data to the target automatically—This options performs the verification process by the comparison method specified, generates a verification report, and then remirrors those files from the source to the target that are not synchronized.

4. Select Verify only and click OK.

   

   Just like when you were monitoring the mirror and replication processes, you can monitor the verification process. Notice that the Mirror Status column changes to Verifying while the verification process occurs. When the verification is complete, Double-Take Availability will have created a log file for you to review.

5. Wait until your Mirror Status has returned to Idle and then open the file DTVerify.log located in the Double-Take Availability installation directory on your source. You will see that all of the files are reported as the same.

6. Modify one of your files on the target and repeat the verification process, but this time, select Remirror data to the target automatically.

   Since your target file is newer, make sure that Only if the source’s date is newer than the target’s date is not selected.

    

7. Look at the file on the target that you modified and confirm that your changes are gone. The source version has overwritten the file on the target.

At this point in your evaluation, you may want to test your target data. The type of testing you will need to perform will depend on the type of data you are protecting.

• User data—If you are protecting user files, you can use the associated application to open the files on the target. Open one or more of the files to test the integrity of the data. Do not save the file after you have opened it, because that will update the copy of the data on the target, which you do not want to do at this point in the evaluation.
• Application data—If you are protecting application data, for example a database application, you will need to use that application to test the integrity of the data and the files. Use the following instructions to test application data on the target.
1. In order to test the application data on the target, you will need to start the application on the target. But Double-Take Availability requires applications to be in a standby mode in order to update files on the target. In order to meet both of those requirements, you will need to pause the target. When you pause the target, the source begins to queue the data changes that are occurring. This will give you an opportunity to start the services on the target, test the data, stop the services, and then resume the target. Make sure your mirror is Idle and then pause the target by right-clicking the connection in the Replication Console and selecting Pause Target.
2. Once the target is paused, you can start the application services on the target. Test the application data by using clients to connect to the application. For this evaluation, the clients will need to be configured to access the application from the target. In a real-world scenario, if failover has occurred, the target would be standing in for the source and the clients would still be accessing the application from the source identity.
3. After you have completed your testing, stop the application services on the target.
4. After the application services on the target have been stopped, you can resume your target through the Replication Console by right-clicking the connection and selecting Resume Target.
5. While you were testing the application on the target, the application files were updated on the target, thus your source and target are no longer synchronized. You will need to perform a manual remirror to resynchronize the files on the source and target. Right-click the connection and select Mirroring, Start. Select a Difference Mirror. Make sure that Only send if source’s date is newer than the target’s date is not selected. Since your target files are actually newer than the source (because of the testing you performed), you do want the newer files on the target to be overwritten by the files from the source. Click OK to begin the mirror.

When the mirror is complete, your source and target will again be synchronized and you can continue with your evaluation.

The following instructions will configure failover monitoring.

1. The Failover Control Center can be started from within the Replication Console or from the Windows desktop.
• From the Replication Console, select Tools, Failover Control Center.
• From the Windows desktop, select Start, Programs, Double-Take for Linux, Availability, Double-Take Failover Control Center.
2. Select your target from the Target Machine list box.
3. Click Login to login to the selected target.
4. Click Add Monitor. The Insert Source Machine dialog box appears in front of the Monitor Settings dialog box.
5. Type in your source machine name and click OK. The Insert Source Machine dialog box will close and the Monitor Settings dialog box will be available for updating. This is where you configure failover monitoring.

6. Select the source to be monitored by marking the check box to the left of the source server name in the Names to Monitor tree.

   

At this point, in terms of your evaluation, your failover configuration is complete because you will be using the default settings for the remaining options. But while you are viewing the Monitor Settings dialog box, notice the configuration options available to you.

Since it can be essential to quickly know the status of failover, Double-Take Availability offers various methods for monitoring the state of failover. When the Failover Control Center is running, you will see four visual indicators.

• The Failover Control Center Time to Fail counter
• The Failover Control Center status bar located at the bottom of the window
• The Failover Control Center colored bullets to the left of each IP address and source machine
• The Windows desktop icon tray containing a failover icon

You can minimize the Failover Control Center and, although it will not appear in your Windows taskbar, it will still be active and the failover icon will still appear in the desktop icon tray.

The Failover Control Center does not have to be running for failover to occur.

 

Monitoring failover contains more information on the Failover Control Center visual indicators.

To fully evaluate failover, you need to simulate a failure. The Failover Control Center does not have to be running in order for failover to occur, but for the purpose of this evaluation, make sure that it is running so that you can see each step of the process.

1. Ping the source’s IP address from a client machine.
2. Ping the source’s machine name from a client machine.

3. Disconnect the network cable(s) on the source. Notice immediately, that the Failover Control Center Time to Fail counter decreases and never resets. You will see the icons change to yellow and eventually to red. Once the icons are red and the Failed Over message is displayed, failover has occurred.

   The Linux system log on the target provides details on the actual steps that have occurred during failover.

    

4. Ping the source’s IP address from a client machine.
5. Ping the source’s machine name from a client machine.

As you can see, the target has taken on the identity of the source. Application and user requests destined for the source are routed directly to the target. The impact on your end users is minimal.

While your source is failed over to your target, end users continue to work without interruption and the data on the target will be updated. To fully evaluate the next step, restoration, simulate the changes that the end users would have made on the target while the source was unavailable.

1. Identify the file that you edited earlier on the source.
2. Locate that same file on the target and make edits to it. Save the changes.
3. Repeat that process, modifying the other three files from earlier, but this time make the modifications on the target copy of the file. Save the changes.

If desired, you can also test the target data as you did earlier. You can test user data using the associated application, and you can save the changes if desired. If you want to test application data, start the application services on the target, and test the application data by using clients to connect to the application. Because the source is now failed over, you will not need to worry about pausing the target or configuring clients to access the application from the target. The clients will continue to access the source, which is now being handled by the target machine.

When failover occurs, a source machine has failed. The steps below must be used to complete failback, which releases the source identity from the target. .

1. If this were a real failure scenario and not an evaluation, you would first verify that your source machine is not connected to the network. If it is, you would have to disconnect it from the network.

2. Next you would resolve the source machine problem that caused the failure.

   Do not connect the source machine to the network at this time.

    

3. In the Failover Control Center, select the target that is currently standing in for the failed source.

4. Select the failed source and click Failback.

   

5. You will be prompted to determine if you want to continue monitoring the source. Do not make any selections at this time.
6. At this time, you would connect the source to the network. For this evaluation, reconnect the network cable(s) on the source that you disconnected to simulate the failure.
7. After the source is online, select Stop in the Failover Control Center to indicate that you do not want to continue monitoring the source.

At this time, your target is back to its original identity and the source is back online.

The Replication Console provides an easy method for restoring replicated data from the target back to the original source or to a new source server. You are only required to input the original source, the target, and the name of the replication set you want to restore. Double-Take Availability handles the rest, including selecting the files in the replication set and restoring them to the correct location.

1. From the Replication Console, select Tools, Restoration Manager.

   

2. Identify the Original Source machine. This is your source machine where the data originally resided.
3. Select the Restore From machine. This is the target machine where the copy of the data is stored.
4. Replication Set contains the replication set information stored on the target machine (the machine in Restore From). If no replication sets are available, the list will be blank. Select the replication set that corresponds to the data that you need to restore.
5. Select the Restore To machine. For this evaluation, select the original source. This is the machine where the copy of the data will be sent.
6. The Restore To and Restore From paths will automatically be populated when the replication set is selected. The restore to path is the directory that is the common parent directory for all of the directories in the replication set. If the replication set crosses volumes, then there will be a separate path for each volume. The restore from path is the path on the target server where the replicated files are located.
7. Use the default settings for the remaining restoration options.
8. Click Restore to begin the restoration.

Once the restoration is complete, your evaluation is complete. Congratulations!