Thủ thuật Sharepoint 2010 part 52 pdf

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

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 compdistrib-uters, 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

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

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 resolvmirror-ing 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

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

http://technet.microsoft.com/en-us/library/ms189852.aspx

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

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 http://technet.microsoft.com/en-us/library/ 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

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, getttry-ing that same error when hitttry-ing 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

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

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

➤

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

➤

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

➤

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

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