This document is a response to a request involving ePO releases and support for the SQL
AlwaysOn feature. Our analysis of the issue has concluded that this feature functions without issue as long as it's set up properly.
Description
- The AlwaysOn Availability Groups feature is a high availability and disaster-recovery solution that provides an Enterprise alternative to database mirroring.
- Introduced in SQL Server 2012, AlwaysOn Availability Groups maximize the availability of a set of user databases for an Enterprise.
- An availability group supports a failover environment for a discrete set of user databases, known as availability databases, that fail over together.
- An availability group supports both of the following:
- A set of read or write primary databases
- 1–8 sets of corresponding secondary databases
Research and Conclusions
- ePO works with the SQL function AlwaysOn.
- There's no difference if the database is running on an AlwaysOn Failover Cluster Instance or Windows Server Failover Cluster. For more information, see KB74034 - Support for ePolicy Orchestrator and SQL mirroring.
- The AlwaysOn function is part of SQL, not ePO, and any issues would be in the proper setup of the AlwaysOn function.
- But, there's a limitation to what ePO supports failover cluster nodes on the same subnet.
- A multi-subnet failover cluster configuration doesn't work with ePO.
- There are two ways to configure an SQL Server failover cluster, as described in the following excerpt from the Microsoft article. For details, see this Microsoft article:
Depending on how the nodes are clustered, the SQL Server failover cluster is configured in the following ways:
- Nodes on different subnet
The IP address resource dependency is set to OR. This configuration is called an SQL Server multi-subnet failover cluster configuration. For more information, see SQL Server Multi-Subnet Clustering (SQL Server).
- Nodes on the same subnet or the same set of subnets
The IP address resource dependency is set to AND for these types of configurations.
IMPORTANT: The first option above isn't supported and doesn't work with ePO. But, ePO does support the second option.
NOTES:
- Server tasks in-progress during the failover can't complete successfully after the failover occurs.
- Such tasks need to be ended using the 'End Task' option within the ePO console Server Task Log. This action is needed because ePO isn't aware of the Database failover operation.
- During failover, the open database connections that are associated with an ePO Server Task, and primary node, which the SQL Server drops. Thus, server tasks remain in the state of 'In-Progress' or 'Waiting' until the task is closed through the ePO console.
NOTE: Any future product functionality or releases mentioned in the Knowledge Base are intended to outline our general product direction and should not be relied on, either as a commitment, or when making a purchasing decision.
