Site-level Disaster recovery
Site-level disaster recovery – includes procedures and technologies that an organization uses to get its networks and servers running quickly after a disaster that affects some/all of its IT infrastructure.
Configuring Hyper-V Replica
Hyper-V Replica – periodically replicates changes in a VM to a mirror VM hosted on another Hyper-V server.
–Works over a regular IP network and can be enabled on stand-alone servers or servers in a failover cluster.
–Hyper-V servers can be at the same site or at different sites.
Replication occurs asynchronously: delays a couple of seconds or minutes.
Can configure encryption so that data transfer between hosts is secure, Can also configure compression to reduce bandwidth.
Hyper-V Replica can be used for site-level disaster recovery if your organization maintains a hot backup site. Which is a location that duplicates much of the main site’s IT infrastructure and can be switched to if a disaster occurs at the main site.
Hyper-V Replica Broker – used to configure Hyper-V Replica between failover cluster nodes.
Configure it by adding the Hyper-V Replica Broker role in the Failover Cluster Manager console. Right-click the role in the FCM console and click Replication Settings.
Hyper-V Extended Replication
Extended replication – used to replicate a replica, which give you a third location from which to run a VM. It is a “backup of a backup”.
After initial replication between the original VM and the first replica server, you can configure replication.
–On the replica server in Hyper-V Manager, click the replica VM on the replica server,
–Click Replication in the Actions pane.
–Click Extended Replication.
Multisite Clustering
A drawback of using Hyper-V Replica for multisite fault tolerance:
–Some loss of data between the source VMs being replicated and the replica VMs is inevitable.
–There’s a lag between changes occurring on the source VM and the time replication occurs.
Hyper-V Replica provides fault tolerance only for VMs, not physical computers.
Requirements – same as for any failover cluster
–Use similar server hardware for the cluster nodes in all sites.
–Be sure network infrastructure in all sites supports the shared storage scheme you’re using.
Multisite cluster network configuration
Network design probably includes multiple IP subnets
–Client computers must be able to discover network services on another subnet when a site failover occurs.
–Should consider multisite/multisubnet Hyper-V clusters.
–Another option to consider is configuring the network with VLANs so that the cluster nodes on each site are in the same IP subnet.
Data replication options
Windows doesn’t have an automatic mechanism to replicate storage data from the shared storage location on one site to another
–You must provide the replication
–Don’t use Distributed File System Replication (DFSR) because it replicates data only when files are closed
–Replication of data can be synchronous or asynchronous
Heartbeat settings
The heartbeat is a signal sent between cluster nodes to inform them that a node is up and running.
–If a cluster node fails to send a heartbeat signal in a specific time, the node is considered unavailable.
–You can configure heartbeat settings to account for varying network speeds.
–If five heartbeats in a row are missed, failover to another cluster node occurs.
- Change frequency by PowerShell cmdlet:
cluster /cluster:clustername /prop SameSubnetDelay=timeInms
To configure the heartbeat frequency for cluster nodes in a different subnet, change the SameSubnetDelay parameter to CrossSubnetDelay.
- To change the number of times the heartbeat can be missed before a failover occurs:
cluster /cluster:clustername /prop SameSubnetThreshhold=ThresholdValue
To configure the threshold value for cluster nodes in a different subnet, change the SameSubnetThreshold parameter to CrossSubnetThreshold.
Other software:
http://www.backup-utility.com/wbadmin/delete-backup-4348.html