A
drastic improvement for SharePoint in terms of high availability is the
full support of database mirroring. Content databases, configuration
databases, and the majority of the service application databases can now
be mirrored to provide for automatic data redundancy, provided that
synchronous mirroring is used, because the config database and other
noncontent databases need to be in exact alignment with each other.
If using asynchronous mirroring, however, only content databases can be supported for mirroring.
Using these concepts,
there are effectively three types of mirroring topologies supported for
SharePoint content, as discussed in the following sections.
Single Data Center High-Availability Model
In this model, shown in Figure 1,
SQL mirroring is used solely to create a backup copy of the SharePoint
databases so that they can be used to failover the environment in the
event of a problem on the principal SQL server. Because synchronous DB
mirroring is used, all SharePoint databases (excluding a few services
databases that cannot be mirrored; more on this later) can be mirrored
from the principal server to another.
This model requires two distinct
SQL instances, and uses a SQL witness server to fail over from the
principal to the mirror databases in the event of a failure. Because all
SharePoint servers are in the same data center, there are only two
SharePoint Web/Query/Service App servers in the farm.
Cross-Site High-Availability Model
In the next model, illustrated in Figure 2,
the same concepts apply, except that the SQL mirror, witness, and
additional SharePoint farm members are physically housed in a separate
site. This is an ideal model, but it requires a backup data center that
is physically close by because the network latency must be less than 1ms
and the bandwidth between sites must be verifiably above 1Gb at all
times.
In this model, if the
primary data center were to completely fail, the SharePoint environment
would continue to run on the synchronously mirrored databases in the
backup data center.
As a side note, Microsoft
has supported enviroments with latency levels up to 10ms, but it is
critical that there not be spikes in the WAN traffic and that there is
guaranteed bandwidth and low latency because these spikes can cause
transactions to timeout on the production
side of the SQL mirror. That said, the official Microsoft stance at the
time of this writing is that 1ms of latency is required.
Multiple-Farm Cross-Site Model
In the next supported SQL mirroring model, shown in Figure 3,
only the SharePoint content databases are mirrored to a remote
location, using SQL Enterprise edition’s asynchronous mirroring.
Failover to the remote site is manual, and involves attaching the
content databases to a new farm that is identically configured to the
main production farm.
This model is ideal
for environments that are separated by greater distances or that don’t
have the necessary bandwidth to support synchronous mirroring. A
suboption to this model is one where the failover farm itself is only
provisioned in the event of a site outage, rather than built as a “warm”
farm.
Note
These three models are
supported using native Microsoft technologies. A broad third-party space
exists that provides tools that allow for full two way replication of
data between multiple SharePoint farms that can provide for similar or
greater DR and HA functionality.
