Skip Navigation

AlwaysOn high availability

BlackBerry UEM
 supports AlwaysOn using a Failover Cluster Instance (FCI) or availability group. Both methods require a 
Windows Server
 Failover Clustering (WSFC) cluster where independent servers interact to provide a high availability solution for databases. For more information about WSFC, visit the MSDN Library to see Windows Server Failover Clustering (WSFC) with SQL Server.
Instance-level high availability using an AlwaysOn Failover Cluster Instance
This diagram shows multiple Microsoft SQL
  Server nodes in a Failover Clustering Instance (FCI) configuration for          database high availability
An FCI is an instance of 
Microsoft SQL Server
 that is installed across multiple computers (or “nodes”) in a WSFC cluster. The nodes are members of a resource group, and all nodes have shared access to the 
BlackBerry UEM
 database. One of the nodes has ownership of the resource group and gives the 
BlackBerry UEM
 components access to the 
BlackBerry UEM
 database. If the node that owns the resource group becomes unavailable (for example, a hardware or OS failure), a different node takes ownership of the resource group. As a result, 
BlackBerry UEM
 database service continues with minimal interruption.
For more information, visit the MSDN Library to see AlwaysOn Failover Cluster Instances (SQL Server).
Database-level high availability using an AlwaysOn availability group
This diagram shows multiple Microsoft SQL
  Server nodes in an availability group for database high availability
To use an availability group, you configure a WSFC cluster with multiple nodes. Each node is a separate computer that has an instance of 
Microsoft SQL Server
. One of the nodes hosts the primary 
BlackBerry UEM
 database and gives the 
BlackBerry UEM
 components read-write access. This node is the “primary replica.” The WSFC cluster can have one to eight other nodes, each hosting a secondary database. These nodes are “secondary replicas.”
The primary database synchronizes data with the secondary databases. Data is synchronized with each secondary database independently. If one secondary database is unavailable, it does not affect the other secondary databases. You can configure the data synchronization to be asynchronous (delayed synchronization with minimal transaction latency) or synchronous (faster synchronization with increased transaction latency). 
BlackBerry
 recommends the synchronous configuration. Automatic failover requires the primary replica and secondary replicas to use synchronous-commit mode.
If you configure an availability group for automatic failover and the primary database becomes unavailable, one of the secondary replicas becomes the primary replica. That replica’s secondary database becomes the primary database. As a result, 
BlackBerry UEM
 database service continues with minimal interruption.