What a disaster ... or how XenServer can help recovery after disaster

8:15 PM
What a disaster ... or how XenServer can help recovery after disaster -

In the computer world, we should all be aware of what happens if you lose a data center, both technical and commercial perspectives that possibility can leave us vulnerable to costly breakdowns or failure of the company itself! There may be many reasons for this to happen. Mother Nature and human error show each time a number of different contingencies can strike your data center.

XenServer integrated with Site Recovery we provide a tool that can help you get your servers, virtual desktops, databases, etc. back online.

How does XenServer this feature?

of all you need a shared storage system that is able to replicate data to a Datacenter Datacenter B. First, it is your decision how often you want the data to be replicated, which is usually governed by specific calculations RPO / RTO for your business. Distance does not matter, as with NetApp SnapMirror you can drive hundreds of miles replication and leveraging Citrix CloudBridge we can even help you compress data to be transferred over WAN!

After setting up your shared storage repository (SR) in your primary data center, you can configure the SR for disaster recovery, as shown in the graph below. SR used for disaster Recover function can be attached via iSCSI or Fiber Channel, but can not be configured if your shared storage using NFS or integrated StorageLink.

This process creates a backup metadata for virtual machines on the selected SR.

Once the configuration is made DR, backup metadata on the selected SR is always kept updated with information about the resource pool and virtual machines.

Part of the DR planning process will involve deciding what workload should be prioritized for recovery in case of disaster. This list is typically a small subset of all hosted workloads and will affect the design of your storage level. For example, you may decide that only 25 of your most critical services must be available on the website of recovery and that they can provide a lower level of service during a DR event. This decision may influence the design of your DR to provide only 2 or 3 DR SR 'on the main site running on level 1 and storage have these replicated at a lower level storage on commodity the recovery site. Many factors affect the DR design process, but the identification of workloads for recovery and their respective priorities is key.

The pool (s) of XenServer resources on the DR site can be installed and configured when you need, but ideally they should be XenServers production that are online and ready to be used if necessary to avoid delays in any recovery process. This will also be affected by your RPO / RTO desired. If your recovery time aggressive, XenServer resource pools on the recovery site should be subject to the same strict management, monitoring and change control processes that are in place for the production site. This will ensure that the state of R & D infrastructure is well known and will prevent complications or delays in recovery.

Important factors to consider when DR configuration are that levels the XenServer patch version and CPU family are identical, and sufficient resources are available on the recovery site to accommodate priority workloads for DR. The resources available on the recovery site should be sufficient to meet the performance criteria set in any business or technical SLAs that are in place, it is possible that these may be relaxed in a DR scenario, but your customers need to be made aware of any difference!

The day of truth !! -. We hope it never comes to this, but the day comes when you need to switch to your recovery data center

First, you must activate your DR-storage making it writable. Make sure that the LUN mapping and zoning is correct. As a second step, you run the iDR-Wizard in XenCenter.

The assistant probe the selected storage for the required storage depots, you then choose the SR which will be attached to the site disaster. XenServer will read metadata previously saved from the SR and ask you to confirm the names of virtual machines that you want to restore.

XenServer will now attach the SR, create virtual machines based on the metadata VM previously saved and start machines virtual you selected

Tip :.

You can also use the Disaster Recovery Wizard to run test failovers for non-disruptive testing of your disaster recovery system. In a test failover, all the steps are the same as for the changeover, but the virtual machines are not started after being recovered from the DR site, and cleaning is performed when the test is completed to eliminate all machines virtual and storage recreated on the DR site.

failback is achieved in much the same way. You configure your storage replication and configure the SR for Disaster Recovery. When you feel it is the right time to make a cut, you can start the recovery process by starting the Disaster Recovery Wizard. You choose failback, probe for your SRs, select virtual machines to restore, and did.

The only thing left is to clean your DR Site (SR forget and delete virtual machines).

All this can be achieved using the CLI as well. This section of the Citrix Knowledge Base, although specific to XenServer 5.x, contains useful information on using the CLI to script the backup pool and virtual machine metadata

http :. //support.citrix .com / article / CTX121099

All these features are included with XenServer Platinum. Please see our XenServer Administration Guide for more information.

Previous
Next Post »
0 Komentar