- Understanding the SharePoint Server Roles
- Understanding the Reasons for Deploying Multiple Farms
- Choosing the Right Hardware for SharePoint
- Determining Optimal Operating System Configuration
- Planning for Database and Additional Software
- Examining Real-World SharePoint 2013 Deployments
- Addressing Common Business Issues with SharePoint Features
- Deploying a Team Collaboration Solution with SharePoint
- Deploying a Corporate Intranet Solution with SharePoint
- Deploying a Customer Extranet Solution with SharePoint
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding the Reasons for Deploying Multiple Farms
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. In addition, other farms may be created to provide for centralized services for other farms within the organization. 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. Of course, 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 is 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.
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 usually quickly provisioned and deprovisioned, so test environments are not the best location for them.
For these organizations, it might 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, see Chapter 12.
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 Unified Access Gateway (UAG).
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 demilitarized zone (DMZ) of a firewall or in another isolated network. For an in-depth look at SharePoint extranets, including step-by-step guidance for how to set them up using claims-based authentication using various authentication providers, see Chapter 13, “Deploying SharePoint for Extranets and Alternate Authentication Scenarios.”
Deploying Global or Distributed Multifarm Environments
For environments with multiple geographic locations, it might make sense to deploy multiple farms in different geographic 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 geographic farms:
- A single SharePoint farm should not span a WAN link and should ideally be limited to one geographic location. In some organizations, in which the definition of WAN includes at least 1Gb of bandwidth with less than 10ms 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 2013. 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 might 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 Hypertext Transport Protocol (HTTP)/HTTPS protocols, so access to a centralized infrastructure might make sense. In addition, SharePoint 2013 has new minimal download features that allow a page to render much more quickly across slower WAN links. This means that centralizing SharePoint becomes much easier, and 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 members 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, dependent on the available capacity of the SQL instance.
- 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, <10ms 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 the proper 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.