Knowledge Article 119417

Return
  • Title

    How to Configure Physical Standby
  • Description

    This article describes how to configure physical standby.

    In addition to the Replay’s bare-metal recovery (BMR), which protects the server with snapshots in just minutes, Replay now includes the feature Physical Standby. This feature allows you to configure a warm standby server booted into the Replay Recovery Console (RRC) ISO or CD. With the combination of BMR and Physical Standby the Replay product’s functionality and efficiency is unbeatable.

  • Resolution

    To set up physical standby, follow these steps:

    1. From the Replay Admin Console, select the Protected Server in the tree hierarchy, and then from the Summary tab, click the Physical Standby link in the Control Panel. Another way is by right-clicking the Protected Server in the tree hierarchy and select Properties, then click the Physical Standby tab.

    2. On the Physical Standby tab, check the box labeled Export latest recovery points to a physical standby.

    3. Click the Choose Standby IP button and enter the IP address for the physical standby machine.

    4. Map volumes and map the volumes between the source machine and the target machine.

    5. Click Save.

    Requirements for Replay Physical Standby Recovery

    1. The source server and the target server (for standby) must have compatible hardware abstraction layers (HALs). Refer to the Microsoft knowledgebase articles Q309283 and Q838856 .

    2. The mass–storage controllers (IDE or SCSI) must be identical between the reference and destination computers.

    3. Plug and play devices such as modems, sound cards, network cards, and video cards do not have to be the same. If they are not the same, ensure that the installed drivers are available on the destination computer at first run, so that plug and play can detect and install the drivers.

    4. The size of the destination computer’s hard disk must be at least the same size as the hard disk of the master installation. If the destination computer has a larger hard disk, the difference is not included in the primary partition. The partition can be extended using diskpart.exe.

    5. Before performing a BMR, validate the following on the source and protected servers:

    a. Processor and the Chipset – For example, Intel Dual-Core 64-bit Xeon processor 7000 sequence and Industry Standard Intel E8501 Chipset. The best practice recommendation to minimize loss of data and a quick RTO is to use identical hardware. If identical hardware is not available, use similar hardware or same class of hardware. For example, an HP ProLiant DL380 G5 to an HP ProLiant DL360 G5.

    b. Storage Controller – Onboard and Expansion. For example, HP Smart Array P400/256MB Controller (optional 512MB battery backed write cache) and HP StorageWorks 2 Gb, Dual Channel, 133 MHz PCI-X-to-Fibre Channel Host Bus AdapterP StorageWorks 2 Gb, Dual Channel, 133 MHz PCI-X-to-Fibre Channel Host Bus Adapter.

    c. Network Controller – Onboard and Expansion. For example, two embedded NC371i Multifunction Gigabit Network Adapters with TCP/IP Offload Engine and HP NC373T PCI Express Multifunction Gigabit Server.

    6. The Physical Standby volumes are for data volumes.  Prep the standby server with the OS through a Bare Metal Restore and periodically update the OS volume when significant changes occur.  It is recommended to have the OS drive dedicated to the operating system files only to minimize the need for frequent updates to the standby.  If the standby needs to go live, you will have the option to start with the OS currently on the machine from the last BMR or if needed, it can be updated once more before going live.

    Considerations for Remote Site

    Since the Physical Standby server is a replica of the protected server (servername and IP address) it is very important to consider the following when resurrecting the server in the remote site

    1. All network connections between original source server and the Physical Standby server in the remote site must appear as a single, non-routed LAN (for example, using technologies such as VLANs to ensure that all nodes in the cluster appear on the same IP subnets).

    2. There will be a limit to the maximum guaranteed round-trip latency between the two sites before it impacts Replay performance and client experience in a failed state. We estimate this latency be no more than 500 ms.

    3. Since Exchange entirely depends on Active Directory for Authentication, Configuration and User lookup all dependent servers/services will have to be made available to the server when running in state of “Continuity.” This means that all of the servers that a mailbox server depends upon in the local site such as Domain Controllers, DNS Servers, Bridgeheads, Front-ends, Connector, and so on. All of them must be protected and replicated over to the remote site. When the imaged server comes up, then it will not throw exceptions looking for these services, and offers a seamless client experience.

    Recommendations for Physical Standby:

    Creation of the RRC ISO

    Create the RRC ISO on the source server by using the Windows Server 2003 SP1 CD.

    1. In the Credentials tab, enter the credentials of the Replay Service Account.

    2. In the Drivers tab,  add WinPE/RIS compatible Network and Storage drivers for the target hardware.

    Note: From the RRC Console, when you create the volumes and cluster sizes for your physical standby, these should be exactly identical to the protected machine. Use CHKDSK/I to obtain disk details. This is required to ensure proper failback from the standby server to the primary server.

    Replication within Local Site

    1. Identical Hardware:

    a. Ensure that the identical Network and Storage drivers are injected in the RRC ISO.

    b. Ensure that the Physical Standby server is available on the local subnet.

    c. Configure Physical Standby and Monitor Replication.

    d. To test Physical Standby,  shutdown source server and power on the Physical Standby Server.

    2. Dissimilar Hardware:

    a. Install (or copy) the drivers for the new target server on the source server.

    b. Ensure that the identical Network and Storage drivers are injected in the RRC ISO.

    c. Ensure that the Physical Standby server is available on the local subnet.

    d. Configure Physical Standby and Monitor Replication.

    e. To test Physical Standby, shutdown source server and power on the Physical Standby Server.

    Replication to a Remote Site

    Before reading this section, please refer to the considerations for the remote site:

    1. Identical Hardware:

    a. Ensure that the identical Network and Storage drivers are injected in the RRC ISO.

    b. Ensure that the Physical Standby server is available on the local subnet.

    c. Configure Physical Standby and Monitor Replication. Depending on the rate of change and the available bandwidth, adjust protection interval or increase bandwidth.

    d. To test Physical Standby, shutdown source server and power on the Physical Standby Server.

    2. Dissimilar Hardware:

    a. Install (or copy) the drivers for the new target server on the source server.

    b. Ensure that the identical Network and Storage drivers are injected in the RRC ISO.

    c. Ensure that the Physical Standby server is available on the local subnet.

    d. Configure Physical Standby and Monitor Replication. Depending on the rate of change and the available bandwidth, adjust protection interval or increase bandwidth.

    e. To test Physical Standby, shutdown source server and power on the Physical Standby Server.

    Replay Physical Standby Quick Start Guide

    Replay Quick Start Guide – Physical Standby

    So I Accidentally Booted My Hot Standby With Production Exchange Running. What Do I Do Now?

    It is never a good thing when an exact replica of an existing Exchange server appears on the network. You can guarantee that at a minimum, email will stop flowing. If you accidentally bring up your Hot Standby server on the network without an actual disaster in progress, or you do not shut down your production Exchange server, do not panic. You can recover from this issue relatively quickly.

    1.  Shut down your hot standby machine.

    2.  Confirm that you cannot use a domain account to log into your production Exchange server.

    3. Do NOT use ADUC to remove the Exchange server computer account from AD: the computer account references a great deal of Exchange metadata in AD and this information is very difficult to recreate.

    4. Ensure that the production Exchange server has a local administrator’s account.

    5. Remove the Exchange server from the domain and add it to Workgroup.

    6. Reboot the Exchange server and then re-add it to the original domain.

    7. Reboot the server one more time and log in using a domain-based account.

    8. Ensure that all storage groups have correctly mounted.

Product(s):
Replay
4.7.2, 4.7.1, 4.7, 4.6.3, 4.6.2, 4.6.1, 4.6, 4.5.7, 4.5.2, 4.5.1, 4.5, 4.4.1, 4.4, 4.3, 4.2.7, 4.2.2, 4.2.1, 4.2, 4.1.7, 4.1.6, 4.1.2, 4.1.1, 4.1, 4.0

Topic(s):
Technical Solutions

Article History:
Created on: 1/27/2014
Last Update on: 2/20/2014

Feedback submitted.

Did this article help?

[Select Rating]

Thank you for your rating!

Close

Request or Create a KB Article »