Category: Windows Server 2016

Disaster Recovery and Replication for Hyper-V VMs using Altaro VM Backup

If you are responsible for virtualized workloads using Hyper-V, ensuring the highest possible availability and minimising downtime should be one of your biggest priorities. Experiencing a loss in a business-critical application or service can result in an interruption in services affecting the ability to carry out work and affect your reputation as a reliable service provider.

Altaro VM Backup is a fast, reliable, and easy to use backup solution for virtualized workloads and features disaster recovery (DR) and replication which can drastically reduce downtime when the unexpected occurs. Altaro prides itself on its industry-leading support, however, knowing the basics of DR and replication can be hugely valuable in getting the most out of the software.

This whitepaper explains how to secure critical business operations and ensure availability of critical VMs in your infrastructure using Altaro and Public Cloud technologies. It covers everything you need to get started including:

  • Defining RPOs and RTOs
  • How to set up replication and conduct the initial replication
  • How to monitor replication jobs
  • How to failover to a DR site

Download the White Paper

SQL Cluster: There was a failure to call cluster code from a provider

Scenario:

You have had successfully configured SQL Server 2016 (or other version) cluster on the first node and tried to add the second node to the cluster, but with no luck:

“Microsoft.SqlServer.Configuration.Cluster.EnumerateClusterSupportedIPAddressResourcesAction” threw an exception during execution.Microsoft.SqlServer.Setup.Chainer.Workflow.ActionExecutionException: The cluster group could not be determined for resource ‘Cluster IP Address’. Error: There was a failure to call cluster code from a provider. Exception message: Generic failure . Status code: 4098. Description: Not found

  • Both servers running on Windows Server 2016
  • SAN and MPIO are configured
  • Cluster is up and running
  • Migration of cluster resources works fine
  • There are no network issues between the servers
  • You use appropriate user account for setting the cluster

Solution 1: 

If you don’t have Internet on servers and can’t update them, start SQL Server installation on the node with the lower build number. For example, my SQL01 node had 14393.2273 build, while SQL02 – 14393.447. So, I used SQL02 as a first cluster node, and then added SQL01 to the cluster.  In my case, such configuration was just for test/demo, so I can’t recommend that solution for production even if the cluster seems to work fine.

Solution 2:

Just update your servers and make sure that they all have the same build number. Then, run cluster validation report, it should be “green”. Re-run cluster setup wizard on the second node.

%d bloggers like this: