Multi Site SQL High Availability group

Question

Hi,
We have our primary Data Centre where we have 2 MS SQL 2012 Enterprise Servers and 2 SharePoint 2013 Enterprise servers.
We have SQL High Availability group implemented on our primary Site (Site A)
Site A has subnet of 192.168.0.0.
We recently added a new DR Site (Site B). Site B we have MS SQL 2012 Enterprise Servers.  Site B have a subnet of
172.1.1.0
Both sites are connected via a VPN Tunnel. MS SQL 2012 Enterprise Server on Site B has been added in have SQL High Availability
group of Site A.
SQL High Availability group have 2 IPs 192.168.0.32 and 172.1.1.32. SQL Listener have 2 IPs 192.168.0.33 and 172.1.1.33
We want to make sure that if Site A completely down then Site B work as an active Site. But when Site A down we are unable
to ping High Availability group and Site B is unable to work as active site. SQL and SharePoint services are completely down.
Site A has AD(Primary Domain  Controller) and Site B has ADC(Additional Domain Controller).
 Site A has witness server.
We are using Server 2012 Data Centre
Please suggest.
Farooq

Answer 1

SharePoint is not the same as any other applications. The DR site has to be a completely different farm from your production. This means that the SharePoint_AdminContent and config databases on both farms are different and should not be included in the Availability
Group (they do not support asynchronous Availability Group.) Only content databases and other SharePoint databases supported in an Availability Group should be included as per this
TechNet article. Have a look at this
blog post for your networking configuration.
The reason your Windows cluster service goes down in the DR data center when the when your primary data center goes down is because the cluster has no majority votes. You have 4 available votes in your cluster - 3 in the primary data center in the form of
the 2 Availability Group replicas and the witness server and 1 in the DR data center. If the Windows cluster does not have majority of votes, it automatically shuts down the cluster. This is by design. That is why when this situation happens, you need to force
the cluster to start without a quorum as described in
this article (Windows Server 2012 R2 introduced the concept of dynamic witness and dynamic quorum to address this concern.) By default, the IP address of the Availability Group listener name will be registered on all of the DNS servers if the cluster is
running Windows Server 2012 and higher (this is the RegisterAllProvidersIP property that Samir mentioned.) However, you need to flush the DNS cache on the SharePoint web and application servers and point them to the correct IP address on the DR server after
failover. This is because the default TTL value of the Availability Group listener name is 20 minutes. 
It is important to define your DR strategies and objectives when designing the architecture to make sure that the solution will meet your goals. This will also help you automate some of the processes in the DR data center when failover or a disaster occurs.
Edwin Sarmiento SQL Server MVP | Microsoft Certified Master
Blog |
Twitter | LinkedIn
SQL Server High Availability and Disaster Recover Deep Dive Course