General SharePoint Considerations in Disaster Recovery solutions

These are important points to consider with remote SharePoint disaster recovery solutions:

  • When adding new Site Collection in a database that is replicated to the Disaster Recovery farm, make sure to update the configuration database in Disaster recovery farm to register the new created site collection because it will not automatically be updated, you can updated using the following PowerShell:
    $db = Get-SPDatabase | where {$_.Name -eq “DatabaseName”}
    $db.RefreshSitesInConfigurationDatabase()
  • In case of multi subnet failover cluster, consider to use MultiSubnetFailover property for all SharePoint databases to make the connection to different subnet more stable and to avoid connection timeouts issue.
    For more information
    http://blogs.msdn.com/b/sambetts/archive/2015/02/13/multi-subnet-sql-server-clusters-sharepoint-2013-spdatabase-multisubnetfailover.aspx
Advertisements

Cluster Quorum Models

The below table show Cluster Quorum Models which give SharePoint Administrator insight which options will be appropriated the option.

The cluster contains nodes and resources, to consider these resources in High Available situation only if the nodes are up and running. The cluster required more than half of the nodes to be up and running otherwise the cluster will go down. Quorum for the cluster maintain the number of nodes (also could be disk witness or file share witness) that must be online for the cluster to be run also to prevent scenarios when nodes can’t have communicated with each other which cause each node to try to own the resources at the same time. By default, every node in a failover cluster has a vote to determine whether the cluster continues running or not.

The value ‘0’ means the node doesn’t have a vote. The value ‘1’ means the node has a vote.

Each node in a WSFC cluster participates in periodic heartbeat communication to share the node’s health status with the other nodes.

Cluster Quorum has four models, only first three are recommended to use:

  • Node Majority: only Nodes can vote
  • Node and File Share Majority: Nodes and File Share witness can vote
  • Node and Disk Majority: Nodes and Disk witness can vote
  • No Majority: Disk Only: Only disk witness can vote and this model used in prior to Windows 2003 which it was only supported disk witness quorum.

To understand the usage for these models let us assume the following examples:

  1. If you have 4 nodes which it’s equal to 4 votes, then if 1 node fail then the 3 remaining nodes which is more than half of the cluster nodes will stay running.
  2. If you have 4 nodes which it’s equal to 4 votes, then if 2 nodes fail then the 2 remaining nodes will go down because it’s not more than half of cluster nodes.
  3. To increase the high availability for the cluster with 4 nodes then we can add File Share or disk witness which can have a vote, so in this case if we have 4 nodes + 1 File Share or Disk which it’s equal 5 votes then if 1 node fail then the 4 remaining nodes will stay running and if 2 fail then the 3 remaining nodes will stay running, so by adding the File Share or Disk witnesses we increase the availability with cheap means without a need to purchase a server (node).
  4. If you have 2 nodes and there is no File Share or disk, then if one node goes down then the cluster will go down.

It’s recommended to have odd number of votes which they equal to more than half by the quorum calculation (Minimum 2 Nodes + File Share or Disk witnesses).

Which model to select?

By default, Failover Cluster manager picks the best model based on cluster configuration and nodes. If there is odd number of Nodes, then the cluster will select (Node Majority) and if there is even number of Nodes and also has File Share then the cluster will select (Node and File Share Majority) and if it’s disk then it will be (Node and Disk Majority). If there is even number of Nodes and no disk or file share witness, then the mode will be (Node Majority) with warning messages.

If the Cluster use No Majority: Disk Only, then in this case the cluster has only 1 vote and if the disk goes down then the whole cluster will go down.

High Availability features supported by different SQL Server versions

The below table show High Availability features supported by different SQL Server versions which give SharePoint Administrator insight which options will be appropriated the option.

For SQL Server 2012

2

For SQL Server 2014

3

For SQL Server 2016 and higher version

4

AlwaysOn will be supported with standard edition but with some limitations:

  • Limited to two nodes only (a primary and a secondary server)
  • Like mirroring, you can’t read from the secondary, nor take backups of it
  • It is not appropriate for a SharePoint farm as it only supports a single database within the Basic Availability Group

SharePoint High Availability and Disaster Recovery based on SQL Server Options

Microsoft provides many solutions to enable High Availability (HA) or Disaster Recovery (DR) for SharePoint based on SQL Server solutions.

At the high level, these options are:

  • Backup and Restore
  • Log Shipping
  • Replication
  • Mirroring
  • Failover Cluster
  • AlwaysOn Availability Group

There are solutions out of SQL Server product like SAN replication, Hyper-V replication and other solutions but these types of replications are not supported by Microsoft because they may cause consistency issues especially for search index and timer jobs.

The only exception for Virtual machine replication is Azure Site Recovery, which does support replication of virtual machines into Azure for the purposes of Disaster Recovery, you can find more information in these links:
https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-sharepoint

https://docs.microsoft.com/en-us/office365/enterprise/sharepoint-server-2013-disaster-recovery-in-microsoft-azure

Backup and Restore

The purpose of creating SQL Server backups is to enable you to recover a damaged database. We can summarize the Pros and Cons in the following points:

  • There is a possibility to lose Data
  • Inexpensive solution for DR
  • It doesn’t provide HA
  • Protection at database level

Log Shipping

SQL Server Log shipping allows you to automatically send transaction log backups from a primary database on a primary server instance to one or more secondary databases on separate secondary server instances. We can summarize the Pros and Cons in the following points:

  • Can be HA or DR
  • No automatic failover
  • Protection at database level
  • Inexpensive solution
  • There is a possibility to lose Data

Replication

Replication is a set of technologies for copying and distributing data and database objects from one database to another and then synchronizing between databases to maintain consistency. We can summarize the Pros and Cons in the following points:

  • Protection at database level
  • No automatic failover
  • Inexpensive solution
  • Can be used as load balancing
  • Can be HA or DR

Mirroring

Database mirroring is a primarily software solution for increasing database availability by replicate the data between primary and secondary servers. We can summarize the Pros and Cons in the following points:

  • Can be HA or DR
  • Limited to two servers
  • It supports automatic failover but it needs witness server for this purpose
  • Replaced with AlwaysOn in SQL Server 2012 and higher releases

Note:

Not all databases can be configured with Failover database server from central administration but you can add this property from PowerShell for these database like configuration database using the below commands:
$database = Get-SPDatabase | where { $_.Name -eq “SomeSharePointDB” }

$database.AddFailoverServiceInstance(“SQLSecond”)

$database.Update();

Failover Cluster

A Windows Server Failover Clustering (WSFC) cluster is a group of independent servers that work together to increase the availability of applications and services. SQL Server takes advantages of WSFC services to provide local high availability through redundancy at the server-instance level. We can summarize the Pros and Cons in the following points:

  • HA
  • Expensive Solution
  • Protection at instance level
  • It supports automatic failover

AlwaysOn Availability Group

This is the latest solution provided by Microsoft from SQL Server 2012 and higher releases which has the features of Database Mirroring and Failover Cluster with many enchantments and new features. We can summarize the Pros and Cons in the following points:

  • Can have up to 4 replicas or more based on SQL Server versions (In Mirroring , only one primary and one secondary servers)
  • Can be HA and DR (HA = Sync mode , DR = Async mode)
  • No need for SAN storage (In Failover cluster , SAN storage or other network disks are required)
  • Can be deployed in geographical (like in Failover Cluster but with more enchantments)
  • No need for witness Server
  • You can use Availability Group Listener (Virtual IP and Name like in Failover cluster)
  • Replica Servers can be accessed for backup or reporting service operations … etc.
  • Supports automatic failover (In case of Sync mode)
  • Needs SQL Server enterprise edition

So in this case you can use one solution to provide HA and DR instead of using multiple solutions like what it was in previous versions for example, using Database Mirroring for remote DR (or log shipping) and Failover cluster for HA.

 Terms

AlwaysOn Failover Cluster instance (FCI) = SQL Server Failover Cluster Instance

AlwaysOn Availability Group = like Database mirroring in old version but with many enhancements

This table from Microsoft whitepaper to show the differences between these solutions (Based on SQL Server 2012 version):

1

 

Scale out Search index in SharePoint Server

In order to scale out SharePoint search index component, first make sure to have an existing search topology already configured and deployed then for scaling there is two options as following:

  1. Add an index replica to an existing index partition in order to achieve fault tolerance for an existing index partition (place it on separate servers)
  2. Add a new index partition for scaling (Recommended is 10M items for each index partition)

Steps to add an index replica:

  1. Open SharePoint Management Shell with SharePoint farm account
  2. Start a search service instance on the server that you want to create the index replica
    $hostA = Get-SPEnterpriseSearchServiceInstance -Identity “Server1”
    Start-SPEnterpriseSearchServiceInstance -Identity $hostA
  3. Wait until the search service instance is running, you can check the status by
    Get-SPEnterpriseSearchServiceInstance -Identity $hostA
  4. Clone the current active search topology
    $ssa = Get-SPEnterpriseSearchServiceApplication
    $active = Get-SPEnterpriseSearchTopology -SearchApplication $ssa -Active
    $clone = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone -SearchTopology $active
  5. Add a new index component and associate it with a partition
    New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance $hostA -IndexPartition 0
  6. Where “0” is is the number of the existing index partition that you are creating a replica of
  7. Finally, Activate the clone topology
    Set-SPEnterpriseSearchTopology -Identity $clone
  8. Monitor the distribution of the existing index to the new replica. The added index replica will have the state Degraded until the distribution is finished

 

Steps to Add a new index partition:

  1. Open SharePoint Management Shell with SharePoint farm account
  2. Start a search service instance on all the servers where you want to add an index replica for the new index partition
    $hostC = Get-SPEnterpriseSearchServiceInstance -Identity “Server2”
    Start-SPEnterpriseSearchServiceInstance -Identity $hostC
    $hostD = Get-SPEnterpriseSearchServiceInstance -Identity “Server3”
    Start-SPEnterpriseSearchServiceInstance -Identity $hostD
  3. Wait until the search service instance is running, you can check the status by
    Get-SPEnterpriseSearchServiceInstance
  4. Clone the active search topology
    $ssa = Get-SPEnterpriseSearchServiceApplication $active = Get-SPEnterpriseSearchTopology -SearchApplication $ssa -Active $clone = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone -SearchTopology $active
  5. Add a new index partition by adding one or more index components and associate them with the new index partition, For example, if you have an existing index partition 0 with index replicas on Host A and Host B, and you want to add a new index partition with index replicas on Host C and Host D:
    New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance $hostC -IndexPartition 1 New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance $hostD -IndexPartition 1
  6. Verify that the Search service application is running
    $ssa.IsPaused() -ne 0
  7. If the Search service application is paused, find out why and if you have to wait for any operation to complete before you can continue
  8. Start the activation of the clone topology
    $ssa.PauseForIndexRepartitioning()
    Set-SPEnterpriseSearchTopology -Identity $clone
  9. Monitor the progress of the index repartitioning process
  10. Resume the Search service application
    $ssa.ResumeAfterIndexRepartitioning()