Monthly Archives: February 2012

Sharepoint Farms

Posted by Jim on February 23, 2012
SharePoint, SharePoint 2010 / Comments Off on Sharepoint Farms
Why a multi-farms?
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.

NoteThe 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.