Thủ thuật Sharepoint 2010 part 52 pdf

High Availability

341
deployment with minimal disruption in the event of a disaster or major failure in the primary site.
Warm standby solutions provide a second copy of the data that can be leveraged in a secondary data
center if necessary.
HIGH AVAILABILITY
High availability is the implementation of a system to ensure a certain degree of operational conti-
nuity during a given measurement period, typically defined by service-level agreements (SLAs), and
can encompass the entirety of a solution or just a portion thereof.
Service-level agreements are a form of contractual agreement whereby the level of service is for-
mally defined, and they can include both performance and delivery time. For example, a guarantee
of 99.9% system availability may be a facet of a service-level agreement. Service-level agreements
are commonly mapped to operational-level agreements, which define internal support relation-
ships, such as those defined between two services — for example, infrastructure and the consuming
application.
SharePoint 2010 offers new high-availability scenarios that provide capabilities to mitigate downtime,
promote redundancy, increase resiliency, and drive a highly scalable architecture. Among these
improvements are a new service application architecture, native support for SQL Server database
mirroring, and improvements to the methods by which costly operations such as large list querying
and site collection deletion are handled.
Load Balancing
Load balancing can be a combination of software- and hardware-based solutions designed to distrib-
ute workload evenly across two or more computers, such as two front-end web, query, or indexing
servers in a SharePoint 2010 topology. The decision to leverage a software or hardware load-balanced
solution is determined by the capabilities and scale you require to meet your objectives. These can
include compliance requirements, geographic needs, and overall scale and performance in addition
to manageability.
SQL Server Database Mirroring
SQL Server database mirroring is becoming a popular option not only to provide a highly resilient
and performance-oriented data replication solution, but also to move toward commodity storage

servers and inexpensive direct-access storage (DAS). SQL Server database mirroring can serve as either
a high-availability solution or a disaster-recovery solution, but it cannot be both. SQL Server database
mirroring works by maintaining two copies of a single database on separate SQL Server instances.
In a database mirroring session, one database, the principal, serves the database to clients; while the
other, the mirror, provides a hot or warm standby server. Whether a database is a hot standby or a
warm standby is dictated by the operating mode of the mirroring session:
Synchronous

— In a synchronous database mirroring configuration, database mirroring
provides a hot standby solution that provides rapid failover without data loss (committed
transactions). This is accomplished because each transaction must be acknowledged by the
342

CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs
mirror before it is hardened on the principal. While this method offers the highest resiliency,
there is the potential to lose infl ight transactions in some scenarios.
Asynchronous

— In asynchronous confi gurations (i.e., sessions are not synchronized), there
is the potential to incur data loss; therefore, it is considered a warm standby solution.
Asynchronous database mirroring is commonly confi gured to support and drive disaster-
recovery solutions due to its effi ciencies over latent links, such as a WAN.
When implementing database mirroring with SharePoint 2010 as a high-availability solution, it
must be confi gured synchronously in the High-safety with automatic failover operating mode, which
includes a witness server. The witness server provides automatic failover by periodically “polling”
the principal server to determine whether it is up and functioning. The mirror server initiates auto-
matic failover only when the mirror and the witness remain connected to each other after both have
been disconnected from the principal server. This confi guration enables a seamless client experience
if a database is compromised and unable to serve clients.
Table 12-1 provides an overview of SQL Server database mirroring availability according to SQL

Server edition.
TABLE 121: Database Mirroring Features by SQL Server Edition
FEATURE CORE EDITIONS SPECIALIZED EDITIONS
ENTERPRISE STANDARD WORKGROUP WEB EXPRESS
Database
Mirroring
Yes (full) Yes (Single
Threaded,
Safety Full
Only)
Witness only Witness only Witness
SQL Server 2008 Enterprise and Standard Editions include a number of database
mirroring improvements that provide further resiliency with SharePoint 2010,
including, for example, Torn Page Repair. With Torn Page Repair, a database
mirroring partner will attempt to recover from corrupted pages on the mirror-
ing database by resolving a limited set of errors, which can enable a data page
to be read. If a partner is unable to read a page, it will request a copy from the
other partner. If the request succeeds, then the unreadable page is replaced by
the good copy, resolving the error in most cases. This illustrates only one of the
many improvements in SQL Server 2008; to learn more, see also
http://msdn
.microsoft.com/en-us/library/ms130214.aspx
.
Most databases in SharePoint 2010 can be confi gured using a standard Windows PowerShell noun
and verb combination, although in some cases varying statements are required to successfully
High Availability

343
configure database mirroring. While Windows PowerShell is most frequently used to configure
database mirroring, the SharePoint 2010 Central Administration user interface also provides sup-

port for configuring database mirroring — the exception being the configuration database, which
must be configured through Windows PowerShell.
Note that unlike previous versions of SharePoint, SharePoint 2010 supports database mirroring without
the implementation of connection aliases or middle-tier software to manage the failover. This is possible
because SharePoint 2010 databases are built on the SQL Native Client (SNAC) that introduces support
for the
Failover_Partner keyword in the connection string.
Although database mirroring can be configured through SharePoint 2010, it simply enables the sup-
port for database mirroring — it does not configure mirroring at the database level, which must be
completed through the SQL Server management tools or Transact-SQL prior to enabling a database
with SharePoint. To learn more about database mirroring and how to configure it in SQL Server, see
/>Configuring Database Mirroring for the Configuration Database
To configure database mirroring for the configuration database, enter the following command in the
Microsoft SharePoint 2010 Management Shell:
$db = Get-SPDatabase | where {$_.Name -match “SharePoint_Config”}
$db.AddFailoverServiceInstance(“mirrorservername”)
$db.Update()
Configure Database Mirroring for Content Databases
Database mirroring for a content database can be configured with either Windows PowerShell or
Central Administration.
To use Windows PowerShell, enter the following command in the Microsoft SharePoint 2010
Management Shell:
$db = Get-SPDatabase | where {$_.name -match “WSS_Content”}
$db.AddFailoverServiceInstance(“mirrorservername”)
$db.Update()
To configure mirroring on a content database using Central Administration, follow these steps:

1. On the SharePoint 2010 Central Administration home page, select Application Management 
Manage content databases.

2. On the Manage Content Databases page, select a web application from the list of available
web applications, and then select a content database associated with that web application.

3. On the Manage Content Database Settings page, specify the mirror server in the Failover
Database Server field.

4. Click OK.
344

CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs
Configure Database Mirroring for Service Application Databases
Many of the new service applications in SharePoint 2010 provide a user interface entry point to con-
figure the failover partner when using database mirroring; however, they differ in implementation.
To configure service applications for database mirroring using Windows PowerShell, enter the fol-
lowing command in the Microsoft SharePoint 2010 Management Shell:
$db = Get-SPDatabase | where {$_.name -match “Search_PropertyStore_<GUID>”}
$db.AddFailoverServiceInstance(“mirrorservername”)
$db.Update()
Failover Clustering
While SQL Server database mirroring support has been included in SharePoint 2010, full support of
failover clustering remains.
Failover clustering helps ensure that applications and services, such as SharePoint, are available when
you need them. A failover cluster is a group of computers working together to increase the availability
of applications and services, such as SQL Server. The clustered servers are commonly connected by
physical cables and software. In the event that one of the cluster nodes fails, another node takes over;
as a result, users experience a minimum of disruption in service.
The key difference between database mirroring and failover clustering is that database mirroring
provides a second warm or hot standby of one or more databases, whereas failover clustering protec-
tion occurs at the server level.
To learn more about failover clustering, see

/>ff182326(WS.10).aspx
.
Read-Only Mode
SharePoint 2010 supports configuring its content databases in read-only mode. When databases
are configured as read-only, SharePoint 2010 detects and seamlessly responds to the situation and
disables any user interface options associated with write and edit scenarios. This enables users to
continue working normally with SharePoint 2010 by allowing them to retrieve data and work with
content until the environment is placed into a read/write mode. Read-only scenarios can be used in
disaster-recovery solutions in the secondary environment or in a localized secondary environment
during patching and upgrade. Read-only mode is configured through SQL Server management tools
or Transact-SQL.
To configure a database as read-only:

1. Open SQL Server Management Studio.

2. Right-click the database to be configured as read-only, and then click Properties.

3. On the Options page, in the Other options list, navigate to the State section.

4. On the Database Read-Only entry, select True from the menu as shown in Figure 12-21 and
then click OK.
High Availability

345
Repeat the preceding steps for each database to be configured.
FIGURE 1221
HTTP Request Monitoring and Throttling
SharePoint is popular, sometimes too popular for its own good. There are times when a SharePoint server
can get more requests than it can handle in a timely fashion. In the dark ages, with SharePoint 2007,
those requests would get dropped in a somewhat random fashion. While a user getting an error try-

ing to get to your portal home is bad, getting that same error when hitting Submit on their vacation
approval form is even worse. To help reduce the impact of an overburdened server, SharePoint 2010
introduces HTTP Request Monitoring and Throttling. Hallelujah! Vacations everywhere will be saved!
How does this all work? Every five seconds each server checks various aspects of its performance. It
looks at metrics like memory available and ASP.NET requests queued, and compares them against
acceptable thresholds. If the server is overworked and exceeds the defined thresholds three times in a
row, the red lights start flashing and the server goes into throttled mode. Web applications that have
HTTP throttling enabled get some new instructions. They will not accept any new requests. New
requests will be met with a very friendly, but firm HTTP 503 error, server busy. The server will,
however, accept connections from existing sessions. This should help free up server resources to let
that vacation request form get submitted. No new timer jobs will be started on that server, and any
running timer jobs will be paused, if they can be. The server continues to check itself every five sec-
onds, and stays in the throttled state until all the metrics it checks fall back into acceptable ranges.
All of this will be logged in the server’s System log in the Event Viewer.
346

CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs
HTTP Request Monitoring and Throttling can be enabled through both Central Administration
and Windows PowerShell on a per web application basis.
To view and change the values associated with HTTP Request Monitoring and Throttling, use these
Windows PowerShell cmdlets:
Get-SPWebApplicationHttpThrottlingMonitor
Set-SPWebApplicationHttpThrottlingMonitor
You can use Get-SPWebApplicationHttpThrottlingMonitor -identity http://www
.contoso.com
to return the HTTP Throttling values. To change the values, you can use
Set-SPWebApplicationHttpThrottlingMonitor.
To configure HTTP Request Monitoring and Throttling from Central Administration, follow
these steps:

1. On the SharePoint 2010 Central Administration home page, select Application Management 
Manage web applications.

2. On the Manage Web Applications page, select a web application from the list of available
web applications and click General Settings on the Ribbon.

3. From the General Settings menu options, select Resource Throttling.

4. On the Resource Throttling dialog, select On or Off in the HTTP Request Monitoring and
Throttling section.

5. Click OK.
List Throttling
List Throttling is a new feature in SharePoint 2010 that enables administrators to proactively pro-
tect server resources from the impact of large lists and their associated views. In order to provide
a consistent server response, SharePoint 2010 provides several settings that can be used to restrict
queries executed against large lists. To provide the greatest amount of flexibility, these settings are
configured on a per web application basis.
To configure list throttling from Central Administration, follow these steps:

1. On the SharePoint 2010 Central Administration home page, select Application Management 
Manage web applications.

2. On the Manage Web Applications page, select a web application from the list of available
web applications and click General Settings on the Ribbon.

3. From the General Settings menu options, select Resource Throttling.

4. On the Resource Throttling dialog, specify a value for each setting you wish to configure:
List View Threshold


— Specifies the maximum number of items that can be retrieved
in a single request. The default value is 5,000; the minimum value is 2,000.
High Availability

347
Object Model Override

— It is possible for developers to override list throttling in the
object model. In order for this to work, you must enable the Object Model Override.
List View Threshold for Auditors and Administrators

— Specifies the maximum
number of items that can be retrieved in a single request through the object model for
appropriately permissioned users. This value does not allow users to see more items
in a list view than a standard user.
List View Lookup Threshold

— Specifies the maximum number of Lookup, Person/
Group, or Workflow status fields that are returned in a single request.
Daily Time Window for Large Queries

— Specifies a date/time range and duration
in which you will allow queries to run while not enforcing any configured throttling
limits. Queries that have executed but not completed within the range will continue
to run until complete.
List Unique Permissions Threshold

— Specifies the maximum number of unique per-
missions that an individual list can support.

5. Click OK.
Gradual Site Delete
Gradual Site Delete is an improvement in the manner by which site collections are deleted in
SharePoint 2010, provided through the new Gradual Site Delete Timer Job Definition.
In SharePoint 2007 a seemingly innocent operation of deleting a site collection could make site
collections inexplicably unavailable. When a site collection was deleted in SharePoint 2007, a SQL
stored procedure was run. It was given the ID of the site collection that had been given its walking
papers. The SQL stored procedure searched through all the tables in the content database that held
the site collection, and deleted all rows that were associated to that ID. While this seems like a good
idea, it turns out it could wreak a fair amount of havoc. A couple of tables could potentially have
thousands of rows associated with a single site collection. When SQL starts deleting a large number
of rows in a table it may choose to lock that table. Once it does that, all the site collections in the
database will be offline until the rows are deleted and the lock is released. Users HATE that.
To help make SharePoint 2010 more resilient, this problem has been addressed. The folks at
Microsoft went back to the drawing board and designed a whole new way to delete site collec-
tions in SharePoint 2010. Now when a site collection is deleted the job is broken down into smaller
steps, so as to not anger SQL and elicit one of its nasty locks. First SharePoint deletes the pointer to
the site collection in the configuration database, and from the Sites table in the content database. At
that point it is no longer available to end users. As far as they know it is gone. Behind the scenes
SharePoint has put a sticky reminder note on its monitor reminding it to delete those old rows
when it gets a chance. Then, via a timer job, it deletes small groups of rows until all signs of the site
collection are gone. It does this all under the cover of darkness and SQL has no idea. While this isn’t
technically something a SharePoint 2010 administrator can do to improve SharePoint’s availability,
it is worth mentioning in this section.
348

CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs
SUMMARY
Whew, we covered a lot of ground in this chapter. The big message is that there are many ways to

look at disaster recovery and fault tolerance. The techniques you use with your environment depend
on which problems you want to protect against, and what your budget is.
The first thing to consider is content recovery. We would get so much done if it weren’t for those darned
users. Recovering their content is one of the things we need to plan for. In this chapter we covered
various methods of protecting users from themselves. These include how to use versions and recycle
bins to recover data. We also discussed a variety of ways to back up content from lists, all the way to
site collections.
High availability as described here crosses many boundaries and is not limited to strictly component
redundancy; it not only spans technologies, but is contained and managed within the product itself,
as illustrated in new resource throttling capabilities and how simple site deletion actions are managed.
Like all aspects of continuity management, prior to embarking on developing a high-availability solu-
tion, you should clearly understand both your objectives and how SharePoint 2010 is intended to be
used in your organization.
The cost and complexity of your high-availability solution will be largely based on your service-
level agreements — a very conservative SLA may require a costly and complex solution to meet its
requirements, whereas a very liberal SLA may require an inexpensive solution based primarily on
warm standby solutions.
Disaster recovery is a critical component of a SharePoint deployment, and planning should begin
once a topology has been identified. This planning should not only include consideration of your
physical and logical topologies, but also ensure that your strategy supports all underlying RTO
and RPO objectives established by your organization. The previous pages have covered some of the
available technologies at a high level. While this chapter can’t tell you exactly what’s right for your
environment, hopefully it did give an introduction to the tools you can use, and it got you thinking
about what aspects of disaster recovery you need to consider.