Thủ thuật Sharepoint 2010 part 13 docx

Hardware Requirements ❘ 75 it to the BI group by configuring it to only run the Excel and Performance Point services. Note that you will not see the term “server group” in Central Administration anywhere; it is only a logical concept. Notice also in Figure 3-5 that SQL Server has been exploded out into various logical groupings. The performance characteristics and demands of different databases can vary greatly, and in large envi- ronments it can be very helpful to configure and manage each one separately. Other Hardware Notes Now that you have gotten the hang of all this hardware, the following sections describe a few more considerations to think through before you move on. The Network Network connectivity between the servers in your farm is hugely important. At a minimum, all servers in the farm should be connected through gigabit connections. The hard requirement here is that each server should be connected by a gigabit connection with less than one millisecond of latency. This precludes most companies from having a SharePoint farm with servers in multiple, geographically dispersed data centers. For many companies, the sheer volume of network traffic generated between the members of the farm is overwhelming. In order to better control this traffic, they move all of the inter-farm traffic to a dedicated virtual local area network (VLAN). This is like the server groups discussed earlier. By grouping all of this traffic, it is easier to monitor and administer in the case of any issues. A dedi- cated VLAN is not a requirement for SharePoint, but in a large farm it is often recommended. Network Load Balancers In order to achieve high availability of the SharePoint web applications, it is necessary to introduce a tool to do network load balancing. This can be either a hardware-based tool, such as an F5 device, or an external software solution, such as ISA or TMG Server, or even something as simple as the built-in Windows Network Load Balancing (NLB) feature. Hardware-based solutions are generally best, as they offer the most configuration options and usually the best performance, but they are also typically very expensive. The software-based solutions such as TMG provide a happy middle ground, especially if you are already using them in your environ- ment. They include just enough options and monitoring to make the cut. Although using the Windows NLB is free because Windows provides it out of the box, it is a very rudimentary feature. It cannot do tasks like validate whether the server is serving valid pages, and instead only confirms that the server responds to ping traffic. For mission-critical scenarios this is not an ideal solution. Regardless of which option you choose, you must configure NLB properly. You are required to set the NLB to a persistent or sticky session or single affinity, meaning when a user opens a browser and navigates to SharePoint their entire session must be against one WFE. SharePoint caches too many requests and does not share that cache across WFEs, so if users are constantly moving from server to server, it is possible for them to have erratic results. 76 ❘ CHAPTER 3 architectUre aNd caPacity PlaNNiNg Server Drives When you configure SharePoint, it is generally a good idea to get everything possible off of the C: drive. For example, navigate to Central Administration and change the diagnostic logs to be hosted on the E: drive instead of the C: drive. Remember that this is a farm-wide setting, so all servers in your farm now must have an E: drive or they will get errors and stop logging. This is inconvenient but not the end of the world. The end of the world happens if you try to add a server to this farm now that doesn’t have an E: drive. You will get file I/O errors running the configuration wizard and it can take a long time to figure out the cause. That is why it is recommended that all of the SharePoint servers in your farm have standard drive letters. A simple design choice like that can greatly reduce your head- aches going forward. Virtualization Now that you have learned about hardware considerations, the question that logically follows is, “Which servers can I virtualize?” After looking at some of those server groups, it is very easy to see some opportunities. Typically, when it comes to virtualization, it is recommended that you start at top of the farm and work your way down. Web front ends have almost no disk requirements and generally are consum- ing RAM and some CPU. They virtualize very well. How well application servers virtualize depends on what service applications they are hosting. For example, if you have a server group that is only host- ing things like Office Web Apps and the Managed Metadata service, they would virtualize easily — again, because they have almost no disk requirements. Your query and index servers can be virtualized but the benefit will depend on your performance expectations. Crawling 10 or 20 thousand items once a day is a pretty light load, and will virtualize without issue. However, trying to crawl 100 million items virtualizing and getting the performance you need would be extremely difficult. The moral of the story when it comes to virtualizing SharePoint servers is that you should first under- stand how hard that server is working and where its first bottlenecks occur. If you can safely virtualize without reducing performance, then do so. Also, if you are building test and development environ- ments where performance is not a critical factor, then virtualization is the way to go. Should you virtualize SQL Server? That question generates almost as much passionate debate as Mac versus PC. Virtualizing SQL Server and achieving acceptable performance is possible; unfortunately, your average virtualization administrator, in partnership with your average SQL Server database administrator, cannot do it well. It is too complex a configuration for someone to stumble through. As a SharePoint administrator, you already know that SQL Server is going to be the factor holding your farm’s performance down; do you really want to gamble with virtualization, which is likely to further decrease that performance? TERMINOLOGY One of the biggest challenges for SharePoint administrators new and old is the vocabulary. SharePoint is littered with words, such as “site,” that have about a dozen different meanings (no one is ever really sure what a site actually is, and many consider it suitable that site is a four-letter word). To this end, Terminology ❘ 77 Figure 3-6 is here to save the day. Once you can speak to the entire hierarchy from top to bottom your job is complete, you have practically conquered SharePoint — so study hard. Services Web Applications Service Applications Content Database Service Application Databases Site Collections Webs Lists Items Servers Farm = Configuration Database Many too Many FIGURE 36 Starting from the top you see Farm = Configuration Database. This means that each SharePoint server can belong to only one farm. A farm can be a single server (refer to Figure 3-1) or something as com- plex as what is shown earlier in Figure 3-4. A farm refers to all of the servers that are using the same configuration database. When you run the configuration wizard, you choose to connect to an existing configuration database (join a farm) or create a new configuration database (create a farm). All servers in a farm, therefore, share everything, including the fact that there is only a single Central Administration site that controls all servers in the farm. Below this, in the column on the right, you come to Services. These are the actual services on the server that run to provide functionality to the Service Applications. For example, the Excel Service Application you create in Central Administration from Manage Service Applications is a Service Appli- cation Connection point. That Service Application Connection point is the proxy to the instances of the Excel Service that is running on the server(s) in the farm. Don’t worry if that isn’t completely clear; Chapter 7 is dedicated to the inner workings of service applications. Finally, at the bottom of the right-hand column you have Service Application Databases. Some ser- vice applications require database(s) to store information in order to work, while others do not. This is just one of the many reasons why using SharePoint 2010 means you will be getting to know SQL Server. Web Applications, at the top of the left column, are the actual SharePoint websites you visit. Because they appear in IIS, you will hear people refer to them as sites, websites, IIS sites, and other creative things. However, it is very important that you refer to them as web applications or web apps for short, as everything in the SharePoint management interface and all of the documentation always refers 78 ❘ CHAPTER 3 architectUre aNd caPacity PlaNNiNg to them as web applications. Examples are http://portal.company.com, http://www.company.com, https://extranet.company.com, or http://team. Between Web Applications and Service Applications you see a double-headed arrow labeled Many to Many. This is your reminder that this is the only place on the hierarchy with a many-to-many relationship — in other words, one web application can consume multiple service applications, and service applications can also service multiple web applications. This is one of those seemingly infinite configuration options that make SharePoint so fun to architect. Every time you create a new web application, SharePoint will automatically create a new Content Database for you and associate it with the web application. This will be the default location for stor- ing content from the web application. It is possible for you to also create additional content databases to associate with the web application. This is done to help scale. Two unique web applications cannot share a content database. That brings you to the most important concept in SharePoint: the Site Collection. Site collections are the unit of scale in SharePoint. The easiest way to think of a site collection is as a bag, because they are really just a boundary or container. They are not actually content users can touch. The reason why this “bag” is so important is because it determines a lot about how your information is stored. Site collections are a storage boundary and are stored in one and only one content database. They cannot span multiple databases. When you create a site collection it is created in a database and that is where it will stay unless you manually move it. If, for example, you want to limit all of your con- tent databases to 40GB because that is the largest size you are comfortable with, then you need to ensure that no site collection is larger than 40GB. Similarly, if you have multiple site collections (and everyone does), then you would need to apply quotas to those site collections to ensure that the sum of the site collections doesn’t exceed your 40GB database limit. For instance, if you had 10 site col- lections, then you would want to set your quotas to 4GB per site collection. Site collections are the only objects in SharePoint to which you can apply a storage quota. If you want to limit a user to storing only 10GB of content in a particular document library, there is no way to do that. You would have to set that entire site collection to a 10GB limit. If you have two docu- ment libraries and you want to give each one 10GB of storage, then you have to ensure that each document library is in its own site collection. Even if you have no intention of holding users to limits, quotas are generally recommended for all site collections, as they serve as a checkpoint and keep you from having runaway site collections. If a user calls and says that he is getting warnings or errors because he has met his quota, it is a simple process for you to increase his quota, and it gives you a chance to ask, “So what are you doing with SharePoint that you need so much storage space?” It would be good to know if he is just backing up his MP3 collection to SharePoint. Site collections also serve as an administrative boundary. Site collection administrators are a special group of users who have complete power over the site collection without necessarily having any access to other site collections. There is an entire menu on the Site Settings page of configuration options that only a site collection admin can make (see Chapter 8). If you have two groups, such as Terminology ❘ 79 HR and Accounting for example, in the same site collection and one of them comes to you because they need to administer one of these special settings, you will have to do some rearranging. If you make Nicola from Accounting a site collection administrator, then she can fully administer the account site as needed but she also has full control over the entire site collection, including the HR web. You need to instead move the Accounting web to its own site collection and then make Nicola an administrator there. Site collections are also boundaries for out-of-the-box functionality such as navigation and the various galleries. This can be a drawback of many site collections. Out of the box, it is impossible to enforce consistent, self-maintaining navigation across site collections. The galleries such as the themes, Web Parts, lists, and solutions are all scoped at the site collection level. For example, if you need a list tem- plate to be available to multiple site collections, then you have to manually deploy it to each. Site collections also serve as security boundaries. The All People list and the various SharePoint groups are all scoped at the site collection level and are not accessible for reuse outside of the site collection. Developers and Windows PowerShell refer to a site collection as an SPSite. So when you hear that word, equate it to site collection. Inside of site collections you have one or more webs. A web is the object that is referred to through- out the user interface as a site. It can also be called a subsite or a subweb. Again, because the term site can be very confusing, whenever possible refer to these as webs. This is the fi rst object users can actually touch. You can apply security to it, and it contains all of the user content. Each web has its own lists (libraries are just a special type of list) and all of those lists store items, which refers to the actual content, such as documents and contacts. As you look at the hierarchy from Web Applications to Items, remember that it is a one-to-many relationship going down but a one-to-one relationship going up. That is, an item can belong to only one list, a list can belong to only one web, a web is part of only a single site collection, a site collec- tion lives in only one content database, and a content database can be associated with only one web application. Still a little fuzzy? Try this metaphor to understand how these pieces work together: Web applications are the landfi ll. Content databases are giant dumpsters. A site collection is a big, black 50-gallon gar- bage bag. And webs, lists, and items are pieces of trash. Your users spend all week creating garbage, continuously stuffi ng it in the garbage bags, with each piece of trash existing in only one garbage bag at a time. Each garbage bag can hold only 50 gallons of trash (quotas) before it is full, after which the user has to either ask for a new garbage bag or get a bigger garbage bag. That full garbage bag is placed in a dumpster, and it is not possible to put a garbage bag in more than one dumpster without destroying it. Dumpsters are serviced only by one landfi ll but that landfi ll can handle thousands of dumpsters without issue. How was that? Clear as mud? 80 ❘ CHAPTER 3 architectUre aNd caPacity PlaNNiNg CONTROLLING DEPLOYMENTS SharePoint 2010 ships with more than a handful of tools that will help you to keep it under control — from tools that block and/or discover rogue deployments to built-in throttling capabilities that will help to prevent lost data and oversized lists from destroying your farm. Blocking Rogue Deployments SharePoint, especially Foundation, is sneaking into more and more enterprises. Business units who don’t want to go through the proper channels have been caught standing up their own SharePoint servers in alarming numbers. That wouldn’t be so horrible, but these rogue servers often house business- critical data but have no backups and no redundancy. IT generally doesn’t find out about them until it is too late and someone has already lost critical data. To help prevent this SharePoint 2010 has implemented a new registry key: HKLM\Software\policies\microsoft\SharePoint\14.0\blocksharepointinstall If you set the dword blocksharepointinstall equal to 1, the installation of SharePoint is blocked. The key challenge is getting this registry key added to all of the machines in your farm in time, as it is not there by default. It will not affect servers that already have SharePoint installed. Also, you need to keep this key a secret between you and this page. If a user knows to look for it they can remove it from the registry and then install SharePoint anyway. If you are considering using this key it is probably easiest to create a group policy object that adds it to all the machines in your domain. Registering SharePoint Servers in Active Directory Rogue SharePoint servers have become an issue in many large enterprises, but sometimes block- ing them as described in the previous section is considered too drastic. Wouldn’t it be great if you could keep track of every server in your Active Directory that someone installed SharePoint on, so you could find the culprits and smack them on the hand with a ruler? With a little AD work you can. When a SharePoint farm first comes online it will attempt to register itself through an Active Directory Service Connection Point, also referred to as an AD Marker. The challenge is this container is not in AD by default; you must create and configure it before SharePoint is deployed. If you do it after the fact, existing farms will not be registered. To configure this you must be a domain administrator and have access to a domain controller. Then you will need to follow the steps documented here: http://blogs.msdn.com/opal/archive/ 2010/04/18/ track-sharepoint-2010-installations-by-service-connection-point-ad-marker.aspx . HTTP Throttling A potential challenge SharePoint administrators have faced in the past and are certain to see again is lack of resources and the odd behaviors it produces. One scenario is an overworked WFE server. As a WFE is processing requests, it might reach a point where it is not immediately responding to a request due to a lack of resources. It will then begin to queue requests, but it has a limited capacity for storing requests also. If the queue fills up, then it will just start indiscriminately dropping requests until it catches up. While this is not a big deal for a typical GET request, what if you are a user who . To help prevent this SharePoint 2010 has implemented a new registry key: HKLMSoftwarepoliciesmicrosoft SharePoint 14.0locksharepointinstall If you set the dword blocksharepointinstall equal. http://blogs.msdn.com/opal/archive/ 2010/ 04/18/ track -sharepoint- 2010- installations-by-service-connection-point-ad-marker.aspx . HTTP Throttling A potential challenge SharePoint administrators have. one of the many reasons why using SharePoint 2010 means you will be getting to know SQL Server. Web Applications, at the top of the left column, are the actual SharePoint websites you visit. Because