Site Recovery for Hyper-V

During my search on Building Hyper-V Disaster Recovery site i allocate a lot of ways and knowledge about building DR site and stretching Hyper-V Cluster. i will try here to share all my knowledge and gathered information about this subject

Why do we need Site Recovery with virtualization?  Well, think about it – lots of organizations are virtualizing, which means they’re placing more eggs, in fewer baskets, however, at the same time, they are benefiting from features like Live Migration and High Availability to ensure uptime is as high as possible.  What would happen though, if their site lost power?  Well, for a short time, the UPS will keep you going, but before long…the SAN – gone.  Servers – gone.  Switches – gone.  The site is down – even High Availability won’t save you there.  Well, local High Availability won’t.

So what is the difference between High Availability (HA) and Disaster Recovery (DR)

High-Availability (HA) allows applications or VMs to maintain service availability by moving them between nodes in a cluster but whenever a catastrophic event that lead to lose of the entire datacenter the HA won’t be useful in this situation and that drive us to define the Disaster Recovery (DR)

Disaster Recovery (DR) allows applications or VMs to maintain service availability by moving them to a cluster node in a different physical location and this also drive us to think on Multi-Site Cluster

Multi-site Clustering

A feature of Windows Server Enterprise, since, well, 2003, has been Multi-site Clustering, or, as it has been known, Stretch Clustering, where you’re effectively stretching a cluster over WAN distances.  Problem with 2003 Multi-site clusters, was the requirement, among other things, for a single-subnet environment across the WAN.  In 2008, and subsequently in R2, this requirement no longer exists, but can be used if required.

The concept behind failover clustering across multiple sites is very simple. Why have separate islands of management for HA and DR? Why not take your HA setup and extend it to another site, thereby obtaining the added protection of geographic distance? Having a single management interface with failover automation provides an easy-to-use solution that gives you the best of both worlds.  Multi-site failover clustering does exactly this. Multiple local nodes provide traditional HA functionality in the event of local server failure. Local application migration (from physical server to physical server) is also available for zero-downtime server maintenance. The cluster is then extended to another site. The process is as easy as adding another node to the cluster. It even works across different subnets, thus eliminating the need for stretched subnets. Multi-site failover clustering can be used to protect key Microsoft Windows workloads like SQL – Exchange and Hyper-V

The key element that the in-box feature does not orchestrate is the failover of the storage.  Think about it for a second – Site 1 is your active site, and has a SAN in Read/Write, along with nodes actively hosting VMs.  The SAN is being replicated to Site 2, where the SAN is in Read mode.  Site 1 goes BOOM.  What orchestrates the SAN switchover?  What orchestrates the connection of replicated LUNS to standby nodes in Site 2?  These are just 2 of the factors that need to be considered, and factored in, when planning a Multi-site configuration another consideration also have to be taken into account, my recommendation also is to consult the Storage provider before designing a DR site.

So what’s happened when…..

No Second SAN?

What about smaller environments, that don’t have the infrastructure, nor the budget, to house a second SAN and associated cluster nodes in another site?  Can they not achieve site resiliency?  Of course they can – there are a number of options available to them, from vendors like FalconStor, DoubleTake, and Steeleye

I will take a dive here on Citrix Essential for Hyper-V as a site recovery provider which enables the Cluster stretching with Hyper-V but in the presence of SAN storage

Citrix Essentials for Hyper-V

Before we go into the specifics around Site Recovery, it’s important to expand on what Essentials for Hyper-V actually is, as it’s more than just Site Recovery.  From the Citrix Essential for Hyper-V website:

Citrix Essentials for Hyper-V includes:

• Citrix® StorageLink™ technology exposes the advanced data and storage management features in today’s storage systems directly to a Hyper-V environment.
• StorageLink Site Recovery allows organizations to easily implement and manage site-to-site disaster recovery for Hyper-V virtual machines.
• Automated lab management enables self-service setup and tear down of non-production Hyper-V virtual environments typically used in development, support, and training organizations reducing management complexity, time, and cost.
• Stage management streamlines the process of building, testing, sharing, and delivering applications, using Hyper-V virtual machines, on demand, into production environments.
• Dynamic provisioning services provides simple deployment of workloads to any combination of Hyper-V virtual machines or physical Windows® servers from a single golden image.
• Workflow Orchestration enables customized automation of key management processes for Hyper-V virtual infrastructure.

So, 6 technologies in there, each with significant benefits of their own (of which the links above will provide you with more information, but what about pricing and versions?

 

As you can see, the Express Edition provides the StorageLink technology, which provides Windows administrators running Hyper-V virtual machines the ability to dramatically simplify their storage management processes with quick and easy storage configuration and provisioning for their Windows Server 2008 Hyper-V and System Center virtual infrastructures.  Citrix Essentials helps Hyper-V administrators take full advantage of powerful storage-based features like deduplication, thin provisioning, cloning, snapshots and replication.  You can get more info on Express here, but remember, the Express Edition of Citrix Essentials for Hyper-V supports up to two Hyper-V servers and one storage array.  If you need more, you’ll have to look at the Enterprise of Platinum Editions, which are priced at $1500 and $3000 per host respectively. At $3000 per Server, it compares pretty favourably with VMware SRM from a pricing perspective, with SRM coming in at $2118 per CPU (inc 1 year Gold S&S), up to $2867 per CPU (inc 3 year Platinum S&S), which, for a typical 2 CPU box, would mean $4216 and $5734 respectively, but remember, for your $3000 per server, you’re also getting 5 other technologies thrown in too

StorageLink Site Recovery

Citrix StorageLink Site Recovery dramatically simplifies the setup and configuration of disaster recovery protection of Hyper-V workloads through direct integration with storage array-based controls for data replication and copy services.  Together, Microsoft Hyper-V and Citrix StorageLink Site Recovery reduce the cost and complexity of implementing disaster recovery for critical server workloads

What about other benefits?

• Easy setup – Use StorageLink Site Recovery wizards to initiate remote replication between arrays, and designate Hyper-V virtual machines for protection in minutes.
• Reliable configuration – Automate disaster recovery configuration validation with built-in configuration checks to eliminate complex, error prone operations that can otherwise hinder recovery of critical infrastructure.
• Non-disruptive testing – StorageLink Site Recovery includes the ability to stage replicated virtual machines in isolated environments for testing and validation of disaster recovery plans without disrupting ongoing replication.
• Fast recovery – Single-click controls for failover of protected Hyper-V workloads helps ensure fast recovery at remote disaster recovery locations

What about requirements?

The following are the basic requirements:

• At least one Microsoft Hyper-V host at both the primary and secondary locations.
• Replication-enabled storage arrays (See the Citrix StorageLink Gateway HCL for a list of supported arrays).
• A StorageLink Site Recovery-enabled version of Citrix Essentials for Microsoft Hyper-V for each Hyper-V host involved in the Site Recovery configuration.
• Network connectivity between the primary and secondary locations with sufficient bandwidth to handle ongoing replication of protected virtual machines.

Once organizations have the basic Citrix and Microsoft components in place, the implementation of disaster recovery protection is very easy:

1. Configure StorageLink Storage Repositories at both primary and secondary locations.
2. Designate a primary storage array and secondary storage array using the StorageLink interface.
3. Map StorageLink Storage Repositories for replication.
4. Use the StorageLink interface to select the virtual machines to be protected.
5. Export the disaster recovery configuration from the primary StorageLink instance.  Then import the configuration to the secondary instance of StorageLink.
6. Once initial synchronization of primary and secondary storage resources completes, Hyper-V workloads are ready for testing and fail-over operations.

For more details on Citrix Essential for Hyper-V (Site Recovery)

 Citrix Essentials Site Recovery – Setting Up Protection

Citrix Essentials Site Recovery – Validation and Testing

Citrix Essentials Site Recovery – Initiating Failover

Finally there is some validations and checking list that you have to go through before start building multi-site cluster or stretch your existing cluster to DR site:

Task	Reference
Review the hardware and infrastructure requirements for a failover cluster.	Failover Cluster Requirements (http://go.microsoft.com/fwlink/?LinkId=129108)
Review the documentation for your multi-site cluster hardware and firmware, including networking documentation and documentation for the replication solution that you will use.	Documentation for your multi-site cluster hardware and firmware
Review the requirements and recommendations for a multi-site failover cluster.	Requirements and Recommendations for a Multi-Site Failover Cluster (http://go.microsoft.com/fwlink/?LinkId=129109)
Review the documentation for the role, service, or application you want to use in the cluster, and install that role, service, or application on every server that will be in the cluster, or as instructed in the application documentation.  Important If the documentation for your application contains instructions for installing the application in the context of a failover cluster, and those instructions differ from this checklist, use that documentation, not the checklist.	Documentation for your server role, service, or application
Install the failover clustering feature on every server that will be in the cluster.	Install the Failover Clustering Feature on a Set of Servers
Connect the networks and storage that the cluster will use.	Prepare Hardware Before Validating a Failover Cluster
Run the Validate a Configuration wizard to confirm that the hardware and hardware settings of the servers, network, and storage are compatible with failover clustering. If necessary, adjust hardware or hardware settings and rerun the wizard.	Validate the Nodes, Networks, and Storage for a Failover Cluster
Create the failover cluster.	Create a New Failover Cluster
If the clustered servers are connected to a network that is not to be used for network communication in the cluster (for example, a network intended only for iSCSI or only for backup), then configure that network so that it does not allow cluster communication.	Modify Network Settings for a Failover Cluster
Configure the heartbeat and DNS settings for the multi-site cluster.	Configure Heartbeat and DNS Settings in a Multi-Site Failover ClusterRequirements and Recommendations for a Multi-Site Failover Cluster (http://go.microsoft.com/fwlink/?LinkId=129109)
Configure the quorum options for the multi-site cluster. In many cases, the design for a multi-site failover cluster uses the Node and File Share Majority option.	Configure Quorum in a Single-Site or Multi-Site Failover ClusterRequirements and Recommendations for a Multi-Site Failover Cluster (http://go.microsoft.com/fwlink/?LinkId=129109)
If your application provides specific instructions for installation in a cluster, follow those instructions. Otherwise, run the High Availability Wizard to specify configuration information for a service or application that you want the cluster to provide.	Configure a Service or Application for High Availability
Configure the failback settings and a sequence of preferred owners for each clustered service or application according to your design. In other words, specify servers at the main site as being more preferred than servers at the secondary site, so that services and applications will fail over to the secondary site only when servers at the main site are unavailable.	Configure Failover and Failback Settings for a Clustered Service or Application
For a clustered file server, add shared folders. For a clustered print server, configure print settings such as the setting that specifies the printer. For a clustered application, check the length of time that the Cluster service allows for starting the application when it is brought online.	Create a Shared Folder in a Clustered File ServerConfigure Print Settings for a Clustered Print ServerConfigure the Pending Timeout for a Clustered Service or Application
Test failover of the clustered service or application, including failover between sites.	Verify the Configuration and Failover of a Clustered Service or Application

In my Next Post on Hyper-V Cluster Streatching i will go more deep on how to build and streatch the Cluster to establish the DR site.