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 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. 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 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. 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. . 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. 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. 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