With the release of Agent 2.24+ and Appliance 8.4.0+, x360Recover now provides support for failover clusters, and Cluster Shared Volume (CSV)-aware backups.
This guide will give an overview of failover cluster services, discuss Cluster Shared Volume (CSV) support available in x360Recover, and describe some best practices to consider. A high-level description of the virtualization and recovery process using failover clusters is also included.
The following topics are included in this Guide:
Overview of failover clusters
A failover cluster is a group of independent physical or virtual computers that work together to increase the availability and scalability of clustered roles (formerly called clustered applications and services).
Clustered servers (called nodes) are connected via network and by software.
If one or more of the cluster nodes fail, other nodes begin to provide service. This process is known as failover.
A failover server delivers highly available services known as roles. Examples of cluster roles include WIndow services (DHCP Server, File Server) as well as tangible objects like iSCSI targets, virtual machines, and disk volumes (Shared Disks, and Cluster Shared Volumes.)
With failover clustering, users experience a minimum of disruptions in service if a server failure occurs. Logical roles will automatically be restarted on another node in the event of a failure and can be manually live-migrated from node to node without disruptions of service, to facilitate maintenance of individual nodes.
Roles within a failover cluster are proactively monitored to verify that they are working properly. If they are not working, they are restarted or moved to another node, providing high availability of the services being provided.
Failover clustering has many practical applications, including:
- Providing highly-available file storage for critical applications such as Microsoft SQL Server and Hyper-V virtual machines
- Providing high availability for essential services like DHCP, DNS, or File Shares
- Distributing and scaling applications across multiple nodes using Cluster Shared Volumes (CSV)
Cluster Shared Volumes (CSV) provide Windows storage that is simultaneously shared across multiple nodes in a failover cluster.
- Each CSV disk that is ‘Online’ is available for direct read and write operations by every member of the cluster concurrently.
- At the physical level, a CSV disk is hosted (or ‘attached’) by only a single node at any given time, and all other nodes within the cluster proxy communications via the host node.
- At the logical level, all nodes can concurrently read and write to any CSV in the cluster, allowing applications to scale to multiple server nodes with shared file resources.
A CSV volume can be moved from node to node, changing servers within the host cluster, at any time without disrupting storage operations.
CSV volumes can be placed in ‘Maintenance’ mode, making them accessible only by the node to which they are currently attached, effectively removing them temporarily from the cluster.
With the release of Agent 2.24+ and Appliance 8.4.0+, x360Recover now provides support for failover clusters, and cluster shared volume (CSV)-aware backups.
- Each node in the cluster will backup all volumes ‘attached’ to it during each backup window.
- As CSV volumes are relocated within the cluster over time, all nodes will eventually capture an independent copy of each volume that will be stored within the backup of the node on the BDR.
- All CSV volumes currently attached to a given node will be backed up as local disks on the appliance.
Operating system considerations
Failover cluster was first introduced by Microsoft with Windows Server 2008 R2 and the initial feature set in that release is very limited when compared with later versions of Windows Server.
- In particular, backup operations for Cluster Shared Volumes in Server 2008 R2 are not well implemented. Whenever a Volume Shadow Copy (VSS Snapshot) exists on a Cluster Shared Volume hosted on Server 2008 (a requirement for performing a backup), the volume will be locked into a pseudo maintenance mode and visually display a ‘Backup in Progress’ status within Failover Cluster Manager. If an interrupted or failed backup is forced to leave behind the Shadow Copy image, the volume will remain locked until the shadow copy is removed. Although a ‘Backup in Progress’ state does not interfere with data access within the cluster, it does prevent administrative actions (like migrating to another node, failover of the volume, taking the volume offline, and so on )
- x360Recover FastDelta backup mode is not available for Windows Server 2008 R2 Cluster Shared Volumes because, in order to operate, FastDelta is required to leave a Volume Shadow Copy image behind from the previous backup.
- Another limitation within Server 2008 R2 is that drive letters cannot be assigned to Cluster Shared Volumes. They are only accessible utilizing their special mount point path at C:\ClusterStorage\<Volume>.
Note: The only use case for Cluster Shared Volumes within a Windows Server 2008 R2 Failover Cluster which is supported by Microsoft is for storage of cluster-hosted Hyper-V Virtual Machine disks. As you should not backup the underlying Hyper-V virtual disk files from the hypervisor (but, instead, back up the running virtual machines with their own agent instance), we do not recommend enabling CSV support for Windows Server 2008 R2 Failover Cluster.
Windows Server 2012 and newer provides a much more robust implementation of Failover Cluster Server and Cluster Shared Volumes. Although backup of Server 2008 R2 Failover Cluster volumes has limited support, we recommend upgrading all such servers to Server 2012 or newer if possible, in order to take advantage of the greatly improved functionality.
SUPPORT | 720-204-4500 | 800-352-0248
- Contact Axcient Support at https://partner.axcient.com/login or call 800-352-0248
- Have you tried our Support chat for quick questions?
- Free certification courses are available in the Axcient x360Portal under Training
- Subscribe to Axcient Status page for updates and scheduled maintenance
1765