Thủ thuật Sharepoint 2010 part 12 pdf

68 ❘ CHAPTER 3 architectUre aNd caPacity PlaNNiNg With this configured, e-mails will be sent to doclib1@sharepoint.company.com. Your corporate e-mail server will relay that mail to the SMTP service running on the SharePoint server. The SMTP service will then take that e-mail and put it in a maildrop folder. The SharePoint timer service checks that folder once a minute by default, looking for e-mail. When it finds an e-mail, it routes it to the appro- priate list or library based on the address. While that is a simple scenario, many configuration options are available. You can, for example, configure Exchange Server and Active Directory to allow users to create their own e-mail addresses. This is done through the creation of an additional Organization Unit in your domain. This is a more complex scenario, but it eliminates the administrative burden of having to set up e-mail contacts each time a new list or library requires mail functionality. You can find detailed configuration information, with multiple scenarios and troubleshooting steps, on TechNet ( http://technet.microsoft.com/en-us/library/cc262947(office.14).aspx). Text Message (SMS) Service Settings That is right — SharePoint has become so cool that it can even send text messages. And since SharePoint still isn’t old enough to drive, you don’t even have to worry about it texting and driving. Once the ser- vice is configured, users can choose to have alerts sent to e-mail or text message or to both. The service is pretty straightforward to set up from within Central Administration and can be scoped at either the farm or the web application level. You will need to provide the URL of an SMS sending service. If you don’t have one handy, you can click the link on the Mobile Account Settings page in Central Administration to find one based on your preferred wireless provider. Just watch out for this functionality: It can easily become a runaway cost. HARDWARE REQUIREMENTS Build it and they will come. Underpower it and they will complain. (No user has ever complained that SharePoint is too fast.) Of course, with budgets being very tight, you will feel the pressure to keep hardware costs as low as possible. This tension between functionality and cost creates a fine line to walk. Perhaps the easiest way to start thinking about hardware is to do a comparison of the minimum recommended requirements from MOSS 2007 and the minimums for SharePoint Server 2010 (see Table 3-1). TABLE 31 MOSS 2007 versus Server 2010 Recommended Minimum Hardware Requirements MOSS 2007 SERVER 2010 Processor 2 core / 3 GHz 4 core / 2.5 GHz RAM 2GB 8GB Hardware Requirements ❘ 69 Note that part of this discrepancy is that Microsoft has done a better job of setting the minimum bar this time. Despite these recommendations, it is not practical today to run a MOSS 2007 server with less than 4GB of RAM. Even taking that into account, it is safe to assume that SharePoint 2010 will require at least twice as much hardware as an existing SharePoint 2007 farm. This is assuming properly sized 2007 hardware today. Experience has shown that SharePoint farms tend to range from vastly undersized desktop-class machines running thousands of users, slowly, to super- computer-class machines that on their best day use 20 percent of their resources to serve 100 users. So if you are going to make hardware assumptions at least in part based on your 2007 environment, make sure you understand how that hardware is utilized today. The next few pages describe the dif- ferent server types and how the hardware considerations vary for each. Web Servers Often referred to as web front-end (WFE) servers, these are the machines ultimately responsible for the rendering of the SharePoint pages. They typically do not have a high CPU load because they attempt to cache as much content as possible to avoid doing the same work over and over. To do caching properly, the server does consume quite a bit of RAM, so be sure to dedicate a substantial portion of your spending on this server to RAM. A key consideration when determining how much memory you might need is the number of applica- tion pools you plan to have. In a nutshell, application pools are the various IIS processes that listen for incoming web traffi c and then handle it accordingly. In Task Manager, you will see each application pool as w3wp.exe. For example, when you create a new SharePoint web application and choose a new application pool, you get a new instance of this process running. Now when you access SharePoint, this process is actually receiving your request and coordinating with SharePoint to render your page. When SharePoint is caching content in memory, it is being stored in RAM associated with this process. Part of this consideration, though, is that every application pool has a certain amount of overhead associated with it, the process, and the memory it needs to do its job. Therefore, for each new appli- cation pool you create, your RAM requirements will increase, so plan accordingly. This role requires very little local storage and does not need to be optimized in any way. The only storage this machine is doing is the SharePoint root, all of the local ULS and IIS logs, and possibly some disk-based BLOB caching. In other words, don’t get carried away here and create a 10GB C: drive. SharePoint occasionally needs to have extra space for temporary fi les, maybe to unpack a solu- tion or to deploy a service pack, so an 80GB or 100GB C: drive is reasonable for your WFE. SharePoint root refers to a folder structure: C:\program files\common files\ Microsoft shared\web server extensions\14. In SharePoint v3, the \12 folder was called the 12 Hive, so you may hear some people refer to the SharePoint root as the “14 Hive.” If you do, try not to make fun of them. 70 ❘ CHAPTER 3 architectUre aNd caPacity PlaNNiNg Application Servers Application server is the generic name for servers that are responsible for providing resources for the various service applications. The tricky part of sizing these boxes is that each service application has a different usage profile, so the requirements will vary depending on what is running on the box and how heavily that functionality is being used. In addition, when building out an application tier, you should consider scaling out versus scaling up. In other words, is it better to have one large application server with a lot of resources but a single point of failure, or several smaller boxes running the same services that provide fault tolerance but require more administration? The following sections describe some of the key types of application servers and their individual considerations. Query Server A query server is the server responsible for responding to user search requests. When a user opens a SharePoint page, types into the search box, and presses Search, that request is routed by the WFE to the query server. The query server processes the request and then forwards the information back to the WFE for security trimming and rendering of the results. This server uses CPU and memory to process the request and will try to cache as much of the index as possible within RAM. This role is also unique in that it requires local storage on the machine. The query file is kept on local disks and processed on the server. In environments with large indexes (one million plus items) and high search demand, it is best to optimize the storage of this file for fast retrieval. Conversely, in smaller environments it is not unusual to see the WFE and query server on the same machine. The Search architecture for SharePoint 2010 is completely new compared to 2007 and is covered in full detail in Chapter 14. Index Server You will hear the index server also referred to as the crawl server. Unlike its predecessors, this ver- sion is stateless, which means it does not store any information locally. Therefore, your index server does not have any extra disk storage requirements. Typically, indexing of content is a processor- intensive task, so consider additional CPU capacity if you are in an environment with intensive indexing requirements. This tier is also covered extensively in Chapter 14. Excel Services Excel services and the other service applications that are focused on Office client tasks and compat- ibility features are generally more CPU heavy. This is because they typically do not have any storage and are only being used to offload processing from the clients to the server. These features generally require the business units to work with their data differently. They are often not in high demand, especially during early phases of a SharePoint rollout. Therefore, don’t overscale for this functional- ity until you confirm that the business adoption will increase demand. Usage and Health Data Collection The Usage and Health Data Collection service application might be the most data-intensive piece of SharePoint. It enables the collection of all the diagnostic and usage data from your entire SharePoint Hardware Requirements ❘ 71 farm into one database. This database can then be used for reporting, and is even fl exible enough to accommodate custom reporting. Early results have shown that in large environments, this feature creates a very large SQL load, especially on the storage side. Therefore, in order to fully utilize it, you may want to consider putting it onto its own SQL server. Check out Chapter 15 for full details, but make sure that the amount of usage of this functionality factors into your farm planning. SQL Servers It turns out there are entire multi-book series on this one topic and even if you have read all of them you still wouldn’t have a defi nitive answer about sizing your SQL Server. Therefore, as you approach sizing this particular box or boxes, don’t be afraid to ask for help. Also, keep in mind that over the years, the main bottleneck in most SharePoint farms is SQL Server performance. The key thing to remember is that all of the standard SQL Server hardware best practices are impor- tant. SQL Server loves memory and will utilize every bit it can get its hands on, so you should plan accordingly. Eight GB of memory should be the absolute minimum you consider, and 16GB or even 32GB might be appropriate in a heavily used environment. CPUs require the same consideration; a quad-core processor might get you started, but boxes with multiple quad-core processors are more common. Even if you buy enough CPU and RAM, you still are not out of the woods. Disk confi guration has as much, if not more, to do with performance. You will need to plan for the number of spindles your SQL Server has access to and how they will be confi gured; and to do this properly, you need to con- sider the amount and shape of data you plan to store in SharePoint. You should be following the SQL best practices specifying that the data (*. mdf) and log (*.ldf) fi les are on different disks, and that the log fi les are optimized for write. When you are considering which databases to optimize fi rst, the order is as follows: 1. Tempdb (a SQL System database) 2. Search databases 3. Content databases While tempdb should clearly always be the fi rst database optimized, your needs for the Search databases and content databases may vary based on your specifi c scenario. For example, if you have created a content database for collaboration that is excessively large (greater than 100GB), then in order to minimize locking issues you may need to move that database to optimized disks instead of the typical content database that will perform adequately on a basic RAID 5 volume. The key here is to make sure either you understand all of your SQL disk requirements before you purchase the box or you have access to a fl exible solution, such as a SAN, for storing your databases. Check out the TechNet SQL Server TechCenter at http://technet.microsoft .com/en-us/sqlserver/default.aspx for guidance on planning and sizing a SQL Server deployment. 72 ❘ CHAPTER 3 architectUre aNd caPacity PlaNNiNg Finally, when it comes to SQL Server, SharePoint doesn’t really care how you set it up. As long as SQL Server is running a supported version and can serve databases back to SharePoint, it doesn’t matter whether SQL Server is dedicated to SharePoint or is shared with other applications in the company. Nor does SharePoint care whether SQL Server is clustered or doing database mirroring or even trans- parent encryption. SharePoint will simply call to a SQL Server instance for a database, and if it gets data back it is happy. Mixing and Matching Servers Now that you have an understanding of the different types of servers, you need to consider how those will be deployed onto physical hardware. As you combine them, you need to consider the hardware profile of each, and what the server will need to support the aggregate load. One Server This is a configuration you will typically see only for demonstration and evaluation purposes. In the example shown in Figure 3-1, all SharePoint server roles and SQL Server will be configured to run on one machine. Two Servers A two-server configuration is generally considered the minimum point of entry for a small SharePoint deployment. In this scenario (see Figure 3-2), all of the SharePoint services will run on one server, and SQL Server will run on a separate server. Three Servers By adding a second server with SharePoint installed, you create the possibility to reach a high-availability solution (see Figure 3-3). By putting some type of network load-balancing (NLB) device in front of SharePoint, you can ensure that the WFE services are fault tolerant. Make sure your NLB device is configured for persistent sessions. This is a SharePoint requirement and covered in more detail later in the chapter. Then, by configuring the service applications to run on both machines, you can avoid one server crashing and causing you to have a bad day. SharePoint Server 2010 WFE Server Application Server SQL Server FIGURE 31 SharePoint Server 2010 WFE Server Application Server SQL Server FIGURE 32 Hardware Requirements ❘ 73 SharePoint Server 2010 WFE Server Application Server SharePoint Server 2010 WFE Server Application Server SQL Server Network Load Balancer FIGURE 33 Four or More Servers This is where you start making choices. Figure 3-4 shows a scenario in which the environment has been optimized for performance and availability for the WFE and query roles, but the downside is that the application tier does not provide high availability. This is generally not a good idea, so you may want to skip straight to introducing a fifth server to the farm in order to bring high availability to the other service applications. You will not need another NLB device because service applications handle their own load balancing. SharePoint Server 2010 WFE Server Query Server SharePoint Server 2010 Application Server SharePoint Server 2010 WFE Server Query Server SQL Server Network Load Balancer FIGURE 34 At this point, you probably get the idea that you can scale out any of the various service applications as necessary to meet your needs, which leads to our next topic: server groups. 74 ❘ CHAPTER 3 architectUre aNd caPacity PlaNNiNg The Search service application architecture is the most complex and demanding of all the service applications. For many administrators, the majority of their farm architecture will be based on meeting the demand of this feature. Please see Chapter 14, which explains all of the components of the Search architecture in full detail, including additional farm topologies for optimizing the Search service application. Server Groups A server group refers to the logical concept of grouping similar SharePoint service applications together on the same physical hardware. This enables you to add servers, which means additional capacity, for each tier as demand increases. This also segregates the performance impact of the various service applications. Figure 3-5 shows an example. Search Group running Index and Query SQL Server Group hosting Search databases only Web Group Business Intelligence Group running Excel Services and Performance Point Services SQL Server Group hosting Content databases only Other Service Application Group running all other service applications and Central Administration SQL Server Group hosting all other SharePoint databases FIGURE 35 This example isolates the web, search, business intelligence (BI), and all of the other service applica- tions. Now, if business adoption of the BI increases beyond the current capacity, it will not affect the performance or stability of the rest of the farm. It is also simple to purchase another server, install SharePoint onto the box, and then add it to the farm. Once it is a member, you would then add 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. . applications handle their own load balancing. SharePoint Server 2010 WFE Server Query Server SharePoint Server 2010 Application Server SharePoint Server 2010 WFE Server Query Server SQL Server Network. bad day. SharePoint Server 2010 WFE Server Application Server SQL Server FIGURE 31 SharePoint Server 2010 WFE Server Application Server SQL Server FIGURE 32 Hardware Requirements ❘ 73 SharePoint. your WFE. SharePoint root refers to a folder structure: C:program filescommon files Microsoft sharedweb server extensions14. In SharePoint v3, the 12 folder was called the 12 Hive,