SharePoint 2010 uses a traditional three-tier architecture based on the concept of server roles. These roles can be deployed on a single server or many servers. The three-tier roles are
In a small farm deployment, server
roles may be combined to deploy the entire application architecture on
the minimum amount of resources from a hardware standpoint. For example,
you can combine the Web server and application server roles on a single
server or on multiple servers to achieve redundancy. Figure 1 illustrates the three-tier architecture employed by SharePoint 2010.
1. Server Roles
The following sections provide
additional details about each of the three server roles identified in
the SharePoint 2010 architecture. This includes which functions each
server role performs within the farm, as well as optional deployment alternatives to be considered when deploying each.
1.1. Web Server Role
Web front-end servers provide the user-facing access to the system. The Web Application Service runs on each Web front-end server in the farm. The Web server role provides the following capabilities.
Hosts Web pages, Web services, and Web Parts that are necessary to process requests served by the farm.
Directs requests to the appropriate application servers.
This role is necessary for farms that include other SharePoint 2010 capabilities.
In small farms, this role can be shared on a server with the query role.
1.2. Application Server Role
Application server roles are associated with services that can be deployed to a physical computer.
Each service represents a separate application service that can potentially reside on a dedicated application server.
You
can group services with similar usage and performance characteristics
on a server and scale them out onto multiple servers together. For
example, you can combine client-related services into a service group.
Note:
BEST PRACTICE After deployment,
look for services that consume a disproportionate amount of resources
and consider placing these services on dedicated hardware.
1.3. Database Server Role
In a small-farm
environment, all databases can be deployed to a single server. In larger
environments, group databases by roles and deploy these to multiple
database servers. The database server role provides the following
capabilities.
Stores content databases for content applications.
Stores configuration data for the farm.
Stores service application data.
Note:
BEST PRACTICE Consider using database mirroring or clustered database server environment for redundancy.
2. Deployment Topologies
SharePoint 2010 can be configured as a small, medium, or large farm deployment. Remember, the topology
service provides you with an almost limitless amount of flexibility, so
you can tailor the topology of your farm to meet your specific needs.
It is also possible to configure farms that will experience a specific
type of process load, such as a search or Excel Services, to optimize
the topology for that load.
For example, if you wanted to
have a medium farm that was optimized for search, you would separate
the index server role from that of the query servers, perhaps even
providing dedicated hardware for the query servers. In a large farm deployment,
you may even consider designating a Web front-end server as a dedicated
index target for use while crawling. If you are expecting to have a lot
of users performing work with Excel Services, you might elect to have
one or two dedicated Excel calculation servers to handle the load.
In the following sections,
you will look at example deployment topologies for small, medium, and
large deployment to illustrate how you might designate servers in each
role and assign services.
2.1. Small Farm Deployment
When you are evaluating SharePoint 2010 or performing testing/development activities, a small
farm deployment should be sufficient. In fact, you may elect to go with
a single server farm configuration for development or configuration
testing. Often a developer will elect to use a virtual machine for
testing, because it’s less expensive and can be brought up and down as
needed. Alternatively, you could elect to deploy a two-tier farm, with
all Web and service applications running on one server and a separate
database server. For production purposes, a typical two-tier server farm
that supports 10,000 to 20,000 users might appear as shown in Figure 2.
In the case of an environment
in which you anticipate moderate service usage, you might elect to
deploy a three-tier farm, in which you separate the service applications
from the Web/query servers. This provides redundancy from a Web
front-end perspective while providing a dedicated hardware resource for
service application execution. A typical three-tiered small farm
deployment is shown in Figure 3.
If you were anticipating
heavy search traffic and/or large search indexes with frequent crawls,
you might elect to deploy a variation of the three-tier deployment
topology that is optimized for search, as shown in Figure 4.
By separating the search databases for all other databases, the farm
optimized for search shown in the figure should be capable of handling
search indexes with up to 10 million items.
All of the small
farm deployment topologies discussed here include one or more
fault-tolerant servers. Remember, with these deployment topologies, it
only takes a single hardware failure to bring down services in a
non-fault-tolerant tier. This will affect your backup and restore
planning in addition to your service level agreements. Although a small
farm deployment
is sufficient for smaller user bases, it may not be ideal for highly
sensitive application needs that require uninterrupted service and fault
tolerance. For these deployments, consider a medium farm deployment topology.
2.2. Medium Farm Deployment
When you need fault
tolerance within your environment or find your small farm is inadequate
for serving the needs of more business, it’s time to consider a medium
farm deployment. The advantage of a medium farm deployment is that it
allows you to scale out servers and services based on their utilization
and the anticipated amount of content hosted within the farm. By moving
the index and query search roles to the application tier in conjunction
with having dedicated database servers for search, the medium farm
topology shown in Figure 2-8 is capable of handling search indexes with up to 40 million items.
The basic prerequisites
for a medium farm include the presence of two dedicated Web front-end
servers, which should not host any other service applications—they are
dedicated to serving content applications. The second prerequisite for a
medium farm is two combined search query and index servers, with at
least one other application server for service applications. If you
anticipate additional service application load, you can elect to scale
out the application tier as needed, adding additional servers to handle
specific service applications. Database redundancy is highly recommended
for a medium farm deployment, and depending on your selection of
hardware, you may want to add additional database servers or clusters as
the volume of content grows. Figure 5 shows an example of a medium farm deployment.
2.3. Large Farm Deployment
In the case of a large
farm deployment, you should separate services and server roles so that
you have dedicated processing power and redundancy where it is needed.
This allows you to have servers that run or provide specific services
according to the defined scale of the identified needs. For example, you
can have a set of Web servers that are dedicated to service content
applications, while another dedicated server handles the crawling of
content applications (as an index target). You would separate the index
and query roles and perhaps even provide multiple dedicated servers for
each. You could have servers that are dedicated to running sandboxed
code, Excel calculation services, or other specific service
applications. Finally, you could have specific dedicated database
servers or clusters for search, content, and service application
databases. Figure 6 illustrates what a large farm deployment topology might look like.
3. Development and Testing Environments
One of the most often
overlooked needs in today’s SharePoint deployments is the need for both
configuration/development and testing environments. Even if you think
you can get by with a strictly out-of-the-box deployment, you will
inevitably need a dedicated environment in which to create and automate
your configuration. Likewise, you also will need an environment that is
as close to production as possible for testing and validation of your
design.
Even though you are not doing any custom development in your initial deployment, you will probably need to perform the automated configuration of new sites or services, at a minimum. Or, you may want to unit-test
a new configuration for exploratory purposes. When you do want to run
this kind of a test, what will you do? Will you be forced to put those
activities on hold while you set up new environments?
Note:
BEST PRACTICES You should have both a development/configuration environment and a dedicated testing environment.
3.1. Configuration/Development Environment
For each build you release
to production, you will need an environment in which to flush out your
design. Whether they are configurations you need to identify and test
individually or development work you need to perform to implement your
design, the right place to do these activities is your
configuration/development environment. In most cases, this environment
is a limited deployment, often consisting of only a single server.
Great! So, why can’t you just
test things in your testing environment? The answer is found in the
type of testing you are doing. First, if you are doing development of
any kind, you don’t want to be doing it in your testing environment. You
wouldn’t want to install software and tools in the dedicated testing
environment that wouldn’t exist in production. Second, if you are trying
something new in your design for the first time, you don’t want to
incur the contamination risk associated with doing it in your dedicated
testing environment. If you find yourself needing to reproduce a defect
spotted in production within your dedicated testing environment, you now
have to deal with all of the other change you have introduced into that
environment as a factor. This is not an ideal or efficient way of
testing your deployment.
3.2. Dedicated Testing Environment
Ideally, you want your
dedicated testing environment to look exactly like your production
environment, although this may not be possible due to cost constraints.
At a minimum, however, you should have each defined server role
represented in your testing environment. For example, if you have
dedicated index and query servers, make sure you have at least one of
each in your testing environment. If you can’t afford to implement your
testing environment using hardware, do it with virtual machines.
Although virtual machines are not truly representative of production,
they are better than having no dedicated testing environment at all.
The purpose of the
dedicated testing environment is to have a place to perform integration
and functional testing of your design before it is implemented in
production. Usually this means performing well-defined test cases,
capturing and recording the results, remediating the problems, and
analyzing the results in order to make a deployment decision.
Additionally, this environment should sit between production
deployments.
Unless you are readying a build for production deployment, you will need the testing
environment ready to reproduce any defects identified within
production. When you identify a potential fix for the defect, you would
first unit-test that fix in your configuration/development environment,
then move it to the dedicated test
environment, and finally into production. The rigor involved in the
movement of the build between each of these environments will vary based
on your implementation of the system development life cycle (SDLC).
3.3. Example Deployment
Figure 7 shows an example deployment that includes a configuration/development environment as well as a dedicated testing environment.
