Thủ thuật Sharepoint 2010 part 12 pdf

68
❘
CHAPTER 3 architectUre aNd caPacity PlaNNiNg
With this configured, e-mails will be sent to 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 (
/>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 rosoft
.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.