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 , ,
, 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:
/>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