Citrix XenServer - Disaster Recovery

When you use Citrix XenServer virtualization servers, you have the ability to create pools and use high availability (HA) to prevent services from becoming inaccessible. However, if despite this, your service could not be accessed (for fat breakdown, for example), Citrix will allow you to quickly reconfigure a backup environment using the Disaster Recovery feature.

As you will understand, you will only need Disaster Recovery when it's too late. This will allow you to minimize the downtime of services hosted on your XenServer servers.

Then, for XenServer servers pools, we will use 2 pools with 2 XenServer 6.5.0 servers in each pool.

To make this clearer, here is the diagram of the configuration used for this tutorial.

3. Enable the Disaster Recovery protection

To use the Disaster Recovery feature, you must first enable replication of metadata on a shared storage. As mentioned earlier, we will use 2 StarWind iSCSI servers to replicate data between these 2 iSCSI servers.

The primary pool is called "IW Pool" and its shared storage is on the 1st iSCSI server.

Warning : Disaster Recovery automatically backs up only the metadata of your VM. So, their name, UUID, and configuration. It will also save the configuration of vApps. But, Disaster Recovery will not backup your VM's virtual hard disks.

4. Disable shared storage data replication

When services can no longer be accessed from the primary XenServer environment, you will need to use Disaster Recovery. However, as you will see later, you will need to disable shared storage data replication before starting the Disaster Recovery failover process.

In our case, this replication is managed by the "StarWind Management Console" program that is installed with the "StarWind Virtual SAN" solution. Note : for the moment, the 1st iSCSI server is synchronized with the 2nd server. (Synchronization Status: Synchronized)

As we will use the "DR" environment (our backup environment), we will disable replication on the 2nd server. Thus, the data will be accessible only from this 2nd server.

To do this, we select our 2nd iSCSI server and click on "Replication Manager".

We select the replication relationship displayed and click "Remove Replica".

Click Yes to confirm that this replication is stopped.

Now, StarWind warns us that replication is no longer defined. The 2nd iSCSI server is therefore independent.