A
SharePoint farm is fundamentally a collection of SharePoint role
servers that provide for the base infrastructure required to house
SharePoint sites and provide for other services, such as enterprise
search. The farm level is the highest level of SharePoint architecture,
providing a distinct operational boundary for a SharePoint environment.
Each farm in an environment is a self-encompassing unit made up of one
or more servers, such as web role servers, service application role
servers, and SharePoint database servers.
In many cases, a
single SharePoint farm is not enough to provide for all the needs of an
organization. Some deploy multiple SharePoint farms to provide for test
environments, farms where development can occur, or farms for extranet
users or Internet use. You need to define how many farms are required
for an organization when beginning the design process, because the
number of farms created can directly reflect on the physical
architecture of the servers in a SharePoint environment. Generally
speaking, the more farms required, the more hardware is needed, so a
full understanding of what can be gained by deploying multiple farms is
first required.
Deploying Test Farms
Any production
SharePoint environment should have a test environment in which new
SharePoint web parts, solutions, service packs, patches, and add-ons can
be tested. This applies to all organizations, regardless of size. It is
critical to deploy test farms, because many SharePoint add-ons could
potentially disrupt or corrupt the formatting or structure of a
production environment, and trying to test these new solutions on site
collections or different web applications is not enough because the
solutions often install directly on the SharePoint servers themselves.
If there is an issue, the issue will be reflected in the entire farm.
Because of these
reasons, many organizations create a smaller SharePoint farm just for
testing. The farm should be similar to the existing environments, with
the same add-ons and solutions installed and should ideally include
restores of production site collections to make it as similar as
possible to the existing production environment. All changes and new
products or solutions installed into an environment should subsequently
be tested first in this environment.
Note
The SharePoint server or
servers used for a test farm or even a production farm do not
necessarily need to be installed on physical hardware; many scenarios
with SharePoint servers installed on virtual server infrastructure are
possible.
Deploying Development Farms
Developers in an
organization that makes heavy use of SharePoint often need environments
to test new applications, web parts, solutions, and other SharePoint
customization. These developers often need a sandbox area where these
solutions can be tested, and potentially one with different
characteristics from production. These environments are also typically
quickly provisioned and deprovisioned, so test environments are not the
best location for them.
For these organizations, it
may make sense to deploy one or more development farms so that
developers have the opportunity to run their tests and develop software
for SharePoint independent of the existing production environment. When
developed, these applications can first be tested in the test farm and
then finally deployed into production. For information on automating the
creating of test farms using virtual host management software.
Deploying Extranet or Intranet Farms
Another reason to
deploy multiple farms is for security. For security reasons, it is not
generally recommended to have an internal SharePoint document management
or intranet environment directly accessible from the Internet unless it
is secured by an advanced reverse proxy platform such as Microsoft’s
Forefront Edge line that includes the Threat Management Gateway or
Unified Access Gateway products.
Even for environments
properly secured for inbound access, there may be scenarios in which
SharePoint content needs to be made accessible by external users, such
as in anonymous Internet portal scenarios or for extranet partner
scenarios. Because a SharePoint farm requires high connectivity between
farms members, it subsequently becomes necessary in these cases to
deploy dedicated SharePoint environments in the DMZ of a firewall or in
another isolated network.
Note
SharePoint Content Deployment
can be used to push site content from one farm to another, for example,
when content from an internal farm is pushed to an external extranet
farm on a regular basis. The extranet farm remains secure and cannot
access content on the internal farm, but users can still access required
content that has selectively been chosen for publishing.
Deploying Global or Distributed Multifarm Environments
For
environments with multiple geographical locations, it may make sense to
deploy multiple farms in different geographical locations. This enables
SharePoint content to be consumed locally and is what is recommended in
scenarios in which WAN links are not as robust. Consider several key
points before deciding where to deploy geographical farms:
A single SharePoint
farm should not span a WAN link and should ideally be limited to one
geographical location. In some organizations, in which the definition of
WAN includes at least 1GB of bandwidth with less than 1ms of latency
between offices located relatively close to one another, it may be
possible to stretch a farm across locations, but this is the only
scenario in which this would be supported. If you need to consume
content locally, it must be part of a separate farm.
There
is no native way to do two-way replication of content between farms
with SharePoint 2010. However, several third-party companies on the
market enable this type of functionality, which can be advantageous in
disaster recovery scenarios in which content is replicated to multiple
farms.
For many
organizations, it may make more sense to deploy a single, centralized
SharePoint farm in one location rather than to deploy siloed SharePoint
farms in multiple locations. Clients access SharePoint using the latency
tolerant HTTP/HTTPS protocols, so access to a centralized
infrastructure may make sense. It also has the advantages of providing a
single URL to access SharePoint and keeps data in one location.
Organizations need to decide if the level of service accessing
SharePoint across a WAN is sufficient for this to be a possibility.
Planning for Multiple Farms
Consider several key points when designing a SharePoint environment to include multiple farms:
All SharePoint
server roles, with the exception of the database role, can only be a
member of a single farm. You cannot have a SharePoint server reside in
more than one farm at a time.
A
single database server can contain databases from multiple farms,
though it is generally recommended to limit the number of content
databases on a single SQL instance to no more than 50.
If
deploying multiple farms on a single SQL server, be sure to use a
common naming convention for each farm database so they can be logically
organized on the SQL server. For example, naming all databases with the
prefix SP_Farm1, SP_Farm2, and so on can help identify which databases
belong to which farm.
All
farm members must have near-full network connectivity (1Gb+ Bandwidth,
<1ms latency) to all other farm members, with a large number of open
ports with nearly all of them open. This effectively limits scenarios in
which firewalls separate farm members, unless all ports are open
between hosts.
Although
not required to have a test environment exactly match production in
terms of the number of servers or the type of server roles, it is
critical that the web role servers in each environment match each other
so that more effective testing can take place.
