SharePoint and Database Mirroring
If you have had any
experience using database mirroring as an HA solution for previous
versions of SharePoint, you know that it wasn’t a very good story. It
wasn’t as if the two solutions were incompatible, but there was a major
piece of the puzzle that just wasn’t there: true automatic failover. SQL
Server’s High Safety with Automatic Failover operating mode worked just
fine and was definitely capable of failing over from the principal to
the mirror when the situation called for it, but the problem was that
SharePoint had no way of knowing that a failover had happened. And
because it didn’t know about failovers, it couldn’t automatically update
itself to point at the mirror instead of the principal, which meant
that every server in a given SharePoint farm would have to be updated
every time a failover occurred to point the farm at the correct database
instance and database names.
The good news is that we
have a much different story to tell about database mirroring with
SharePoint 2010. It comes down to this: SharePoint 2010 is now
“mirroring aware,” which means it can recognize when SQL Server
automatically fails databases from the principal to the mirror and
update its configuration throughout the farm accordingly. Human
intervention or custom scripting is no longer required to set up
SharePoint to properly use database mirroring as a SQL Server HA
solution.
SharePoint Database Mirroring Recommendations and Requirements
Microsoft has stated
several recommendations and requirements you should understand, follow,
or make your best effort to follow to achieve the best possible
stability and consistency for your SharePoint database mirroring
configuration. The following list outlines several of these items and
describes their purpose:
Network latency less than one millisecond. Latency
is the time it takes for a data packet to travel from one point to
another over a network. It can be measured for one-way trips or for
round trips, although the latter is used much more commonly. The less
latency your network has, the faster data moves between your servers.
Database mirroring requires low latency to ensure that the mirror is
kept as closely synchronized with the principal as possible. One major
cause of network latency is physical distance, which means that
principal and mirror servers often need to be located near each other
and eliminates some of the true redundancy of the solution. Please note
that this is a recommended value, not a requirement.
Network bandwidth one gigabyte per second (GB/s) or greater. Bandwidth
measures the amount of data that can be transferred over a network
within a given period of time, usually one second. Microsoft recommends
(not requires) that your network be capable of transferring at least 1GB
of data per second between nodes in the network, due to the high amount
of data that will be in the target databases’ transaction logs as they
are copied from the principal to the mirror.
Physical computing resources.
Microsoft recommends that both the physical and mirror SQL Server hosts
be provisioned with sufficient processing, memory, storage, and
networking resources to accomplish mirroring without impact on
performance. Note the number of databases you are going to mirror in
your environment; the more databases you mirror, the greater the strain
on your servers. The good news is that, by default, database transaction
logs are compressed by SQL Server 2008 as they are sent from the
principal to the mirror. That does require more processing power to
compress the files, but it ensures that the smallest possible file is
sent over the network, which reduces network traffic and shortens the
time it takes to deliver each file.
Database recovery model. Database mirroring requires that the
target database is backed up using the Full recovery model. By default,
SharePoint creates several databases that are configured to use the
Simple recovery model; you are required to change that setting to
configure them for mirroring and need to account for the additional
overhead that accompanies change.
Database permissions.
The service accounts used by various components in your SharePoint
environment must be configured to have the same rights in the SQL Server
instance hosting the mirrored database as they do in the principal SQL
Server instance. Pay attention to the rights granted the service account
serving as the identity of all SharePoint’s IIS application pools
(especially the account for the Central Administration site), the
database access service account, the default content access account, all
accounts associated with Service Applications, and user accounts that
have been added to the Farm Administrations SharePoint group.
Unique instance names.
If possible, do not configure the SQL Server instance hosting mirrored
databases with the same server and instance names as the principal
instance. This can add a great deal of unnecessary confusion and
complexity to your environment and make it difficult to determine which
instance is currently hosting which role in the configuration.
SQL aliases.
You can use SQL Server aliases to abstract the actual address of a SQL
Server instance, allowing a client computer to be configured to target
the alias rather than the SQL Server
instance directly. This abstraction is helpful for applications that
have strong ties to their databases, such as SharePoint, because it adds
more flexibility on the use of those database resources than is
normally available. If the address for that SQL Server instance should
change, or if a different server altogether is used, all that is
required is a change to the SQL Server alias, rather than a major
configuration change to the application. SQL Server aliases make
database integration and management much easier for SharePoint in
general and should be used whenever possible in your mirroring
configuration. Should a mirroring target change, once the change is made
in SQL Server’s setup, you can update SharePoint via a small
modification to the alias instead of a complex change to the farm’s
configuration.
Operational mode.
SharePoint can only be configured for awareness of database mirroring
configurations that are using the High Safety with Automatic Failover
operational mode. If either of the other two operational modes are used
to configure the mirror and SQL Server fails over from the principal
database to its mirror, administrator intervention or custom scripting
is required to point SharePoint at the mirror database instead of the
principal.
How to Configure SharePoint for Database Mirroring
The first thing you need to do
if you want to set up database mirroring for your SharePoint farm’s
databases is to actually configure the mirroring in SQL Server. Make sure to
take into account the items listed in the “SharePoint Database Mirroring Recommendations and Requirements”
section, because they are crucial toward ensuring the best possible
stability and integration for your mirroring configuration in
conjunction with your SharePoint environment. Once mirroring is
configured in SQL Server, you have two options available for making your
SharePoint farm aware of your mirrored databases: the SharePoint
Central Administration Site and PowerShell.
Tip
Please note that you
are responsible for setting up the mirroring configuration in SQL
Server for the databases that you want to mirror; SharePoint 2010 does
not do that configuration for you. But the good news is that it does
validate the mirroring configuration to ensure that it is properly set
up and enabled once you notify SharePoint that a given database is
mirrored.
If you are
most comfortable administering SharePoint through its graphical user
interface (GUI), the Central Administration site, you should be glad to
hear that you can register SharePoint’s content databases as mirrored in
it. But, and this is a pretty big “but,” keep in mind that we said
“content databases” there. You can only use the Central Admin site to
register mirroring for SharePoint content databases associated with a
Web application, not Service Application databases or the farm’s
configuration database. These items can still be made mirroring aware
within SharePoint; it’s just that you must use PowerShell to do so.
Because
of this limitation, registering a content database as mirrored in the
Central Admin site is best used for one-off situations rather than a
wholesale activity for every database within the farm. To set up a
content database to make it aware of its mirroring configuration, see
the instructions that follow:
Open the Manage Content Databases page. (It’s found in the Databases section of the Application Management page.) See Figure 15 for an example of the Manage Content Databases page in the Central Administration site.
In
the Manage Content Databases page, click the link for the content
database you have mirrored in SQL Server to open the Manage Content
Database Settings page (see Figure 16).
Once the Manage Content Databases page opens, locate the Failover Server section (circled in Figure 8.26).
Enter the fully qualified domain name (FQDN) of the server (or the SQL
alias pointing to it that you configured on the SharePoint server, which
we highly recommend) hosting the mirror version of the database in the
Failover Database Server field, and click the OK button at the bottom of
the page to save your changes. If SharePoint is able to validate the
mirroring configuration, you are returned to the Manage Content
Databases page without error.
If you prefer doing your
administration from the command line, or you want to configure mirroring
awareness for SharePoint databases other than content databases,
PowerShell is the way to go. Use the Get-SPDatabase cmdlet to obtain an object based on the name of the SharePoint database you are mirroring, and then update that object’s AddFailoverServiceInstance
property with the name of the SQL Server instance hosting the mirrored
database.
Although you have to
make some tough decisions when configuring database mirroring for use
with SharePoint’s databases, a good portion of your configuration
choices is driven by other factors—mainly, how your infrastructure is or
can be implemented to meet your needs. For some enterprises, it may not
be cost effective to implement multiple farms in geographically diverse
locations, whereas for others it may be a business-critical
requirement, and each option (plus all those in between) affects how you
can use database mirroring and what can be mirrored.
For a single farm
environment with components hosted in multiple datacenters, again you
can use all three operating modes, but in this case you need to address
sticking points as part of the architecture. In this type of
environment, the mirrored database instance is hosted in a separate
datacenter from the principal instance, providing geographical
redundancy in the case of an outage. If you are using multiple
datacenters to host your database mirroring configuration, pay special
attention to the latency and bandwidth requirements listed previously in
this section. These
constraints mean that the datacenters must be capable of providing
large, fast connections to the servers they host and that, in most
cases, these datacenters must be located closely to reduce latency (at
the cost of increasing risk to localized catastrophes).
|
If a witness server is
configured for automatic failover, Microsoft recommends placing it in a
third datacenter to ensure that it can initiate the failover process in
case of an outage on the principal server. Because this may not always
be a feasible configuration, it is still possible to host the witness
server in one of the two datacenters, but you must understand that it is
exposed to the same risks as the other servers hosted with it, and a
manual failover is required if the witness server is impacted by an
outage. Microsoft also recommends hosting the witness server in the same
datacenter as the mirrored instance so that a potential outage on the
principal has a reduced chance of affecting the witness server as well,
but this is not without its own drawbacks. When the witness is in the
same datacenter as the mirror, a loss of the connection between it and
your principal instance’s datacenter can bring your entire database
environment down. This is because of the way that database mirroring’s
quorum requirements work: if the principal cannot contact the witness or
the mirror to establish a quorum, it also shuts down because it cannot
maintain transactional stability. Regardless of where you place it
within your environment, we strongly recommend including the witness
server in any monitoring solutions you may establish, not only to track
the status of the mirroring process but to confirm that the witness
server is healthy and able to execute the failover when needed.
|
If you have multiple
farms in separate datacenters, the synchronous operating modes for
database mirroring really are not an option because of the time it would
take for a transaction to be sent across the network and written to
each database, and the results sent back across the network. These
activities are directly influenced by network latency—something that is
unavoidable over a wide area network (WAN) connection between
datacenters that do not share large, fast connections. You can still use
database mirroring with the asynchronous operating modes to provide
mirrored copies of your crucial SharePoint data. The other drawback to
using mirroring for multiple farms is that, like log shipping, you can
use it only to mirror your content databases or Service Application
databases as long as their associated Service Application is not hosting
SharePoint’s search functionality.
Tip
If using the High Performance
(Asynchronous) or High Safety Without Automatic Failover operating modes
for your mirroring configuration, there is no benefit to having a
witness server. Witness servers are only required to provide automatic
failover capabilities for a mirroring configuration using the High
Safety with Automatic Failover operating mode; they are unnecessary when
using the other two operating modes.
Database Mirroring Pros
Are
you still unsure whether database mirroring is the best HA solution for
your SQL Server 2008 instances and SharePoint databases? The following
list describes the strong points of database mirroring and their
benefits for SharePoint to help you with your decision:
Independent.
Like log shipping, database mirroring’s functionality is not tied to
SharePoint, nor is it affected by any other processes in the SQL Server
database instance. This means that changes to your SharePoint
configuration or its databases do not directly impact or harm your
database mirroring procedures.
Highly configurable. There are several options and configurations to be set to allow database mirroring to meet the needs of your environment.
Easily configurable.
Not only is database mirroring straightforward for an administrator to
set up and configure, but the infrastructure to host it does not require
specific hardware to implement it. Keep in mind that this does not
necessarily mean it is easy to operate.
Immediate. When a change is made to a principal database, it is also immediately sent to the mirror.
Automated.
If a witness server is configured along with the principal and mirror
servers, when an outage occurs, a failover from the principal to the
mirror can be automatically executed without administrator intervention,
especially when combined with SharePoint 2010’s awareness of mirroring
configurations.
Responsive. Failovers are executed quickly, regardless of whether they are manually or automatically requested.
Distributed and redundant.
As previously explained, you can use database mirroring in various ways
to ensure the long-term stability of your SQL Server environment and
the SharePoint farm that depends on it.
Database Mirroring Cons
Database mirroring also comes
with its own set of drawbacks that you must consider before deciding to
implement it, as described here:
One mirror per database.
A database cannot be mirrored more than once, creating a single point
of failure for your HA solution. Regularly test and confirm your
database mirroring configuration to ensure that it continues to function
as expected.
No easy read-only option.
Mirrored databases cannot be made available for read-only querying
without the creation of an additional snapshot based on the mirror.
Operational mode limitations.
Although you can use SharePoint with all three operational modes for
SQL Server database mirroring, the only mode that it makes sense to use
is High Safety with Automatic Failover. SharePoint is not capable of
automatically failing over to a mirrored database with the High
Performance or High Safety Without Automatic Failover modes, and some
SharePoint databases can only be mirrored with the High Safety with Automatic Failover mode or not at all. (See http://technet.microsoft.com/en-us/library/cc748824.aspx
for more information on SharePoint Server 2010, its databases, and what
can or cannot be mirrored.) Because the other operational modes do not
offer the valuable feature of automatic failover, if you are not able to
use the High Safety with Automatic Failover mode, or you do not want to
use it, you may find that you are better served using log shipping to
protect your SharePoint databases, rather than mirroring.
Performance impact.
Database mirroring requires multiple processing threads on its host
servers, which can negatively affect the performance of your databases
in general (specifically utilizing CPU and RAM), especially as more and
more databases in the instance are mirrored. If you plan to highly
utilize database mirroring, make sure you have the horsepower to account
for it.
Dependence on networking.
Attempting to do synchronous database mirroring in a network with
suboptimal bandwidth or latency leads to performance issues for your
principal database and the SharePoint environment that uses it.
Geographical limitation.
Although database mirroring can be distributed across multiple
datacenters, Microsoft has stated that these datacenters cannot be more
than a few miles away from each other, which limits its ability to
deliver true geographical redundancy.
Inability to configure failover criteria.
Administrators cannot configure or manage the criteria that SQL Server
uses to determine when the configuration should be failed over from the
principal to the mirror. Because SharePoint 2010 is now mirroring aware,
this is less of a concern, but it is still problematic that you cannot
configure its tolerances to allow for the specific state of your
environment.
Incompatibility with RBS.
Databases configured to use RBS cannot be mirrored, regardless of
whether they are using Microsoft’s FILESTREAM provider or a third-party
provider.
Complexity.
Database mirroring can be an order of magnitude more involved to
implement than SQL Server backups or log shipping. It takes careful
research and planning to develop a mirroring solution that is completely
compatible with your infrastructure, SQL Server, and SharePoint
configurations, due to mirroring’s specific requirements. These
requirements and several of the items listed can also make operation of a
mirrored environment challenging.
Database mirroring is
certainly a viable HA solution for SQL Server that’s worth serious
consideration. It lets you automatically fail over to a fallback
database instance should your production database fail. It also gives
you the confidence of knowing that the data in your fallback instance is
an exact copy of your production database. It is flexible and can be
used with various hardware and software configurations. But you may find
that it is not a good fit for the needs of an
organization and its HA requirements. What if you need your databases
to always be online and cannot suffer an outage of even an hour while
you update your SharePoint farm to point at your mirrored database
instance? What if you need more than one fallback instance to add
additional redundancy to your environment but the performance
implications of log shipping rule it out as an option? These are just
two examples of when configuring a cluster of servers running SQL Server
may be the best solution to your problems.
