Understanding the Architecture of SharePoint 2010 : Deployment

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
12/3/2012 6:37:40 PM
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
  • Web front-end server role

  • Application server role

  • Database server role

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.

Figure 1. The tree-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.


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.


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.

Figure 2. Example small farm two-tier deployment topology

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.

Figure 3. Example small farm three-tier deployment topology

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.

Figure 4. Example small farm search-optimized three-tier deployment topology

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.

Figure 5. Example medium farm deployment topology

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.

Figure 6. Example large farm deployment topology

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?


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.

Figure 7. Example deployment including configuration/development and test environments

  •  Understanding the Architecture of SharePoint 2010 : Capabilities
  •  Microsoft Dynamics AX 2009 : Building Lookups - Choosing a font
  •  Microsoft Dynamics AX 2009 : Building Lookups - Picking a color
  •  Microsoft Dynamics AX 2009 : Building Lookups - Selecting a file
  •  Programming .NET Components : Remoting - Leasing and Sponsorship (part 3) - Sponsorship Management
  •  Programming .NET Components : Remoting - Leasing and Sponsorship (part 2) - Providing a Sponsor, Leasing and Remote Activation Modes
  •  Programming .NET Components : Remoting - Leasing and Sponsorship (part 1) - Lease Properties, Configuring a Lease, Renewing a Lease
  •  DisplayPort 1.2 - Meet HDMI’s Smarter Brother
  •  HP ProLiant Servers AIS : Processors and Multiprocessing - The Processor Performance Evolution
  •  HP ProLiant Servers AIS : Processors and Multiprocessing - How Processors Work
    Top 10
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
    - Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
    - Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
    Video Sports
    - The Banner Saga 2 [PS4/XOne/PC] PC Launch Trailer
    - Welkin Road [PC] Early Access Trailer
    - 7th Dragon III Code: VFD [3DS] Character Creation Trailer
    - Human: Fall Flat [PS4/XOne/PC] Coming Soon Trailer
    - Battlefleet Gothic: Armada [PC] Eldar Trailer
    - Neon Chrome [PS4/XOne/PC] PC Release Date Trailer
    - Rocketbirds 2: Evolution [Vita/PS4] Launch Trailer
    - Battleborn [PS4/XOne/PC] 12 Min Gameplay Trailer
    - 7 Days to Die [PS4/XOne/PC] Console Trailer
    - Total War: Warhammer [PC] The Empire vs Chaos Warriors Gameplay Trailer
    - Umbrella Corps [PS4/PC] Mercenary Customization Trailer
    - Niten [PC] Debut Trailer
    - Stellaris [PC] Aiming for the Stars - Dev. Diary Trailer #1
    - LawBreakers [PC] Dev Diary #4: Concept Art Evolutions
    programming4us programming4us