What
an end user of a SharePoint environment sees on a SharePoint page is
the result of a complex interaction that occurs on one or more servers
performing varying tasks. Information
is stored in complex databases, web rendering is displayed courtesy of
the web role, and searches and processes are driven by the Search
service application role on servers.
Depending on the size of the
environment, these roles may be on one or many servers. In very small
environments, all roles may exist on a single server, whereas in very
large-scale farms, the roles may be spread across tens or even hundreds
of servers. These server roles are the base architectural elements in a
SharePoint farm, or collection, of servers that provide for SharePoint
services in an environment. It is subsequently critical to understand
what these server roles are and how they are used in a SharePoint farm.
Understanding the Database Server Role
Nearly all SharePoint
content is stored in databases, including all document library content,
list items, document metadata, and web parts. There are only two
exceptions to this. The first is if the database server uses a concept
known as Remote BLOB Storage (RBS), which allows for the storage of the
documents, or BLOBs (binary large objects), in another storage medium
such as a file server or an archive. The
other exception to this rule is the full-text search index, which is
stored in flat-file format (see the following sections on the Search
Service Application role). In some rare cases, certain web part
solutions may store flat files on web frontends as well, which is a good
idea in any case, but in reality the vast majority of SharePoint
content is stored on the database server role, making it highly critical
both for High Availability (HA) and for Disaster Recovery (DR).
The only supported
database format for SharePoint is Microsoft SQL Server, and at least one
SQL Server database role server must exist in a farm for SharePoint to
function.
Supported versions of SQL Server for SharePoint 2010 are as follows:
SQL Server 2005 SP3 x64
SQL Server 2008 x64
SQL Server 2008 R2 x64
Caution
Although SQL Server 2008
Express is supported, it is not recommended for most modern SharePoint
environments because it does not scale well. Any production SharePoint
environment should consider using either the full Standard or Enterprise
editions of SQL Server.
There
may be more than one database server role in a SharePoint farm, because
a SharePoint administrator can define where a particular SharePoint
database resides. In large environments, for example, there may be
multiple SharePoint database role servers, each serving multiple
databases as part of the farm.
Understanding the Web Server Role
The Web Server Role is the
most obvious of the SharePoint roles, as most people understand the
concept of a server running an application that serves up web pages to
users that request them. In SharePoint’s case, that application is
Windows Server’s Internet Information Services (IIS) application. A
SharePoint farm member running the Web Server Role is responsible for
rendering SharePoint content, including web parts, page layout, and all
other information displayed to the user.
A SharePoint Web Server
Role runs on either Windows Server 2008 x64 IIS 7.0 or, preferably,
Windows Server 2008 R2 x64 IIS 7. In both cases, SharePoint 2010
requires specific roles to be installed in advance of installation,
including the following components:
Application Server Role
Web Server (IIS) Role
Microsoft SQL Server 2008 Native Client
Windows Identity Foundation (KB974405)
Microsoft Sync Framework Runtime v 1.0 (x64)
Microsoft Chart Controls for Microsoft .NET Framework 3.5
Microsoft Filter Pack 2.0
Microsoft SQL Server 2008 Analysis Services ADOMD.NET
Microsoft Server Speech Platform Runtime (x64)
Microsoft Server Speech Recognition Language—TELE
Each of these components can
be installed using the SharePoint 2010 media by clicking the Install
Prerequisites link on the initial splash screen. This operation requires
Internet connectivity. If Internet access is not available, each
individual component needs to be manually installed.
Tip
Multiple web role servers
may be set up in a SharePoint environment to scale out the number of
users that can use the platform or to provide for high-availability
access to the environment. In this case, load balancing of the
connections made to a SharePoint environment allows for a larger number
of users to access the content. Load balancing can be either
hardware-based or software-based using Windows Network Load Balancing
(NLB), fully supported for SharePoint web role servers.
Service Application Roles
The
most significant architectural change in SharePoint 2010 is the
addition of service applications, which replace the SharePoint 2007
concept of Shared Services Providers (SSPs). Service applications are
independent services that can be shared across web applications or, in
some cases, across farms.
Table 1
lists the service applications available with SharePoint 2010 and which
version of SharePoint 2010 software they are available in.
Table 1. Examining a List of SharePoint 2010 Service Applications
| SharePoint Foundation 2010 | SharePoint Server 2010 Standard Edition | SharePoint Server 2010 Enterprise Edition | Office Web App Services (Can Be Added to SharePoint Farm) |
---|
Business Data Connectivity Services | X | X | X | |
Usage and Health Data Collection Services | X | X | X | |
SharePoint Foundation Subscription Settings Service | X | X | X | |
Managed Metadata Service | | X | X | |
Search Service | | X | X | |
Secure Store Service | | X | X | |
State Service | | X | X | |
User Profile Service | | X | X | |
Web Analytics Service | | X | X | |
Word Automation Services | | X | X | |
Access Services | | | X | |
Excel Services | | | X | |
PerformancePoint Service | | | X | |
Visio Graphics Services | | | X | |
Excel Calculation Services | | | | X |
PowerPoint Service | | | | X |
Word Viewing Service | | | | X |
Service
applications can be resource-intensive and are often deployed on their
own dedicated servers to separate their impact from the web role
servers.
Note
Just because you’ve
purchased access to a service application does not mean that you should
turn it on. Every service application running on a server consumes a
significant percentage of that server’s resources, and turning on all
the available service applications is a bad idea unless you’ve planned
accordingly. Turn on only those service applications that need to run a
service that satisfies a specific business need.
Search Service Application Role
One of the most commonly
used service application role in SharePoint 2010 is the search service
application role, because it is responsible for running the Enterprise
search functionality that enables you to search both within and outside
of SharePoint.
The search service
application is different than the way it was in SharePoint 2007. Gone is
the need to separate the indexing from the Query capability; in
SharePoint 2010, these roles are combined into one. In addition,
SharePoint 2010 has the capability to have multiple redundant indexes,
something that was not possible in SharePoint 2007.
Note
The native search service
application in SharePoint 2010 is different than Microsoft’s other
search offering, known as FAST Search Server 2010 for SharePoint. FAST
Search Server enables thumbnail views on search results and automatic
metadata tagging, among other improvements. The architecture of FAST
Search Server is vastly different than the native search.
Notice
a few key things when architecting for the SharePoint search service
application role. First, the index corpus used to store the full-text
copy of all documents crawled can grow large in size based on the amount
of content being indexed. The size of the corpus is directly related to
the size of the actual document data being crawled. Depending on what
is being indexed, and how much actual text is included in that data, the
index corpus can range from 5 percent to 30 percent of the size of
content being indexed, so be sure to include a large enough index disk
drive for your index server.
There are a few things to note about SharePoint search:
Search in
SharePoint is security-trimmed for supported content, excluding some
external content sources. This means that end users will get search
results only from content that they have rights to access. This is a
highly useful feature that prevents users from seeing content to which
they don’t have access.
Although
search is security-trimmed, the permissions are reevaluated only after
performing a full crawl of content. Subsequently, if someone is removed
from having permissions to a document, she can still see the text of
that document as part of a search until a full, not an incremental,
crawl has been performed.
Because
SharePoint 2010 allows for redundant search and indexing capability,
any one server being down does not take down the entire environment,
assuming the search service application is running on more than one
server.
Inbound Email Server Role
For scenarios where SharePoint is
configured to be email-enabled, various SharePoint servers can be
assigned to the inbound email server role. Servers with this role have
the SMTP service installed directly on them and are configured to enable
inbound emails to be sent directly into SharePoint document libraries
and lists. This functionality is critical for an environment looking to
use SharePoint for records management or enterprise content management.
For more information on how to configure SharePoint for inbound email
functionality.
Tip
Don’t forget to load
balance the SMTP Service across multiple inbound email role servers in
environments with HA requirements! If this is not done, inbound email
functionality will not be redundant and will be down for users if an
outage of the primary server occurs.
SharePoint Central Admin Server Role
Although more of a minor
role, the server or servers that hold the SharePoint central
administration service, the main management application for SharePoint,
are also considered a server role. In some large environments, this role
may be separated onto dedicated servers to provide for central
administration functionality without affecting existing server
functionality.
Tip
It is best
practice to make the central administration role highly available by
installing it on multiple servers, typically on multiple servers that
also run the web role. Not doing this runs the risk of a server outage
causing a loss of access to the tools necessary to troubleshoot the
outage.