In Chapter 3, we went through the steps to install Microsoft Office SharePoint Server 2007 onto a single server. In this chapter, we are going to broaden this basic installation out to numerous servers to create a multiserver farm. When we discuss multiserver farms, we are really addressing the subjects of availability and scalability. These topics are often discussed together and they mean numerous things. They can mean having a fast-responding environment (Multiple Web Front Ends [WFE] handling user requests) or it can mean having a redundant environment to provide increased uptime. In either case, we are looking at moving from a single server implementation to a multiple server environment. This chapter details the trade-offs, decisions, and processes in creating a multiserver MOSS implementation.
One of the challenges in scaling out a MOSS site is deciding which services need their own server(s). In this chapter, we will specifically look at Search, Index, Excel Services, and Shared Services. There are valid reasons why we place Excel Services on its own dedicated server or servers if it is being heavily used. Excel Services is a huge resource hog. Similarly, Index, Query, and Search are often best installed on their own server(s) for performance reasons. We want to isolate all of these services if possible, and using a multiserver farm allows for this type of architecture.
A small company may do very well with a server environment where the entire SharePoint environment resides on a single server. This is perfectly acceptable, but you should be aware that when running on a single server, you will have no redundancy. As your needs grow, you can always scale out by adding additional WFEs and Application servers, but if your core server goes down, your MOSS environment is dead until you recover.
You can also run your SQL environment from the core server. However, we are again looking at a failure point, and the performance degradation you will see may warrant the need to separate the WFE from the Database Server. Medium to large companies will, however, benefit from multiple servers in their farm, as it will allow more users to work without interruption in their portal environments.
Tip
Microsoft has put together some worksheets that the implementer or decision maker can use to decide whether availability is crucial to your company and how to provide for it. The link is available in the “Conclusion” section at the end of this chapter.
At the end of this chapter, you will:
Understand the different Sharepoint Farm Topologies
Be able to decide where to place the different resources, such as Search, Index, and Excel Services
Be able to install a medium to large MOSS 2007 farm
In order to scale MOSS, you have to think about which parts you can scale and also the costs you incur and benefits you gain in each scaling approach. In MOSS, you can scale in several different ways:
Adding Web Front Ends (WFEs)
Adding application servers
Scaling and clustering the database
In Figure 4-1, I have broken our environment into three tiers: Web Front Ends, Application Servers, and Database Servers. Again, as discussed earlier, this entire picture can fit onto one single server. MOSS 2007 does make it easy to scale out. Later in the chapter, we will walk through the process of adding an additional server to our farm, but first I want to explain the different tiers and help you to understand the picture in Figure 4-1 more clearly.
The Web Front End’s primary role is to render web content to the end user. Optionally, when you set up your search environment, a single WFE or multiple WFEs can also be used to query the Index server. Users interact directly with the Query server, and you can run it either on a dedicated server or on all WFEs.
Application Servers are where you set your various roles, such as Central Administration, Excel Services, Search/Index and Shared Service Providers.
Database Servers are your repositories for all that is SharePoint. What I mean is that SharePoint stores everything in SQL Server. A common question that comes up from time to time is “Where are the documents stored?” Plan your database implementation properly, and you will ensure a healthy and reliable SharePoint environment.
Before we begin our installation, it is important to plan where you want to place the various roles, such as Excel Services, Shared Service Provider, Search, Index, and so on. This is critical in ensuring a successful implementation.
These application server roles can be deployed to multiple servers. The code that is deployed to each server is identical, and the application server roles do not store any data. In other words, each instance of these server roles remains identical, so if one of the server computers fails, no saved data is lost. The web servers automatically load balance all requests to these server roles across the available application server computers.
The following application server roles can be deployed redundantly:
- Query
The query role can be deployed to any number of application server computers, or it can be deployed across web servers. There is one limitation, however: if the query role is deployed to the same server that hosts the index role, the query role cannot be deployed to any other server computers. This is because the index role recognizes that the query role is on the same server and, consequently, does not attempt to propagate the index. In some scenarios, you can optimize the throughput of your server farm by deploying the query role across your web servers. For example, if more than half of the content requests coming into the server farm are requests for static content, performance can be optimized by hosting the query role on the web servers. This is because the query role caches the content that it serves, making it available for subsequent requests during the search process.
- Excel Calculation Services
The Excel Calculation Services role performs Excel calculations on the Excel workbooks that are stored in the content databases. This application server role is unique in that it stores session-state information throughout the duration of a user session. When a workbook is opened, the web server role continues to route the user requests to the same Excel Calculation Services server until the workbook is closed and the user finishes the session. The Excel Calculation Services role can be a resource-intensive role. You can optimize the performance of your farm by deploying this role across multiple servers.
The following table indicates which application server roles can be deployed redundantly and which roles can be deployed to multiple servers but are not redundant.
|
Application server role |
Multiple servers hosting this role are redundant? |
|---|---|
|
Query |
Yes |
|
Excel Calculation Services |
Yes |
|
Office Project Server 2007 |
Yes |
|
Index |
No |
|
Windows SharePoint Services 3.0 search |
No |
Application server roles that cannot be redundant include Windows SharePoint Services 3.0 and Index search:
- Windows SharePoint Services 3.0
The Windows SharePoint Services 3.0 search application role is an option if you are not using Office SharePoint Server 2007 query and indexing. These components cannot be split. Additionally, Windows SharePoint Services 3.0 search is required to provide full-text search of Help.
- Office SharePoint Server 2007 Index
The index role is associated with a Shared Services Provider (SSP) and builds one index per SSP. One index server can be associated with multiple SSPs. You can deploy multiple index servers to improve capacity. In this case, each index server is associated with a different SSP. Content indexes produced by the MOSS 2007 index role are continuously pushed to all servers that host the query role in a farm.
These application server roles can be deployed to multiple servers; however, the multiple servers are not redundant. These server roles are configured to crawl content and generate content indexes. If you deploy these roles to multiple servers, each server will need to crawl different content.
The following list explains the risks associated with an application server failure. A better understanding of this will help with the planning and design of your implementation.
- Query
In the case of failure, users will not be able to issue full-text queries. Users can still browse through sites and access content exposed through the sites, however. If your application depends on users or customers being able to find content by searching, plan to deploy the query server role to multiple servers. In a five-server farm, this can easily be accomplished by deploying the query role to the two web server computers.
- Excel Calculation Services
Server-side rendering of Excel and business intelligence data will not be available. Spreadsheets cannot be loaded, recalculated, refreshed, or retrieved by Excel Calculation Services. Scorecards and features that use the Excel Web Renderer also are not available. Users will still be able to open spreadsheets from SharePoint libraries by using the Excel client application. However, if users don’t have permission to open files in the client, they will not be able to view those files until the Excel Calculation Services role is back online.
- Index
Query servers will continue to use existing content indexes until the index service is restored and new or updated indexes are generated. Consequently, search results will not include new or changed content while the index role is unavailable.
- Windows SharePoint Services 3.0 search
Search is unavailable. The amount of time required to restore the search capability depends on whether existing content indexes can be restored or if new indexes must be generated by recrawling the content.
The general redundancy recommendation is to plan to install an application server role to at least two application server computers if:
If your organization can tolerate temporary loss of this functionality for the amount of time it takes your IT team to deploy an application server role to a different server or to restore service to the existing server, consider deploying the role to a single application server.
In previous versions of SharePoint, we were provided with different size farms. Small farms (Figure 4-2) could consist of one WFE, the Application Server Role, and Database server all residing on the same box. Alternatively, it could be branched out to two servers. The frontend servers are designated as web servers and provide web content to clients, and the Application Server Role provides services such as Excel Services, Business Data Catalog, search queries, crawling, and indexing content. This model typically is fine for a small organization, but its suitability will really suffer when we start to look at fault tolerance and recoverability. This is where the medium to large farms come into play. Not only do the larger farms assist in spreading some of the load, but you can also gain some fault tolerance benefits with these models.
A medium server farm (Figure 4-3) typically consists of a database server, an application server running Office SharePoint Server 2007, and one or two frontend web servers running Office SharePoint Server 2007 and IIS. In this configuration, the application server provides indexing services and Excel Calculation Services, and the frontend web servers service search queries and provide web content.
A large server farm (Figure 4-4) typically consists of two or more clustered database servers, several load-balanced frontend web servers running IIS and Office SharePoint Server 2007, and two or more application servers running Office SharePoint Server 2007. In this configuration, each of the application servers provides specific Office SharePoint Server 2007 services, such as indexing or Excel Calculation Services, and the frontend servers provide web content.
Tip
All of the web servers in your server farm must have the same SharePoint Products and Technologies installed. For example, if all of the servers in your server farm are running Microsoft Office SharePoint Server 2007, you cannot add to your farm a server that is running only Microsoft Office Project Server 2007. To run Office Project Server 2007 and Office SharePoint Server 2007 in your server farm, you must install Office Project Server 2007 and Office SharePoint Server 2007 on each of your web servers. This also would be the case for other products, such as Knowledge Networks. To enhance the security of your farm and reduce the surface area that is exposed to a potential attack, you can turn off services on particular servers after you install SharePoint Products and Technologies.
The following sections go through the process of implementing a multiserver farm.
Before you begin, it’s important to remember the following:
The account that you select for installing Office SharePoint Server 2007 must be a member of the Administrators group on every server on which you install Office SharePoint Server 2007, and this account is automatically assigned as the SSP administrator. Therefore, by default the SSP administrator is also the local administrator on all of the farm servers. You can, however, remove this account from the Administrators group on the servers after installation.
To deploy Office SharePoint Server 2007 in a server farm environment, you must provide credentials for several different accounts.
You must install Office SharePoint Server 2007 on the same drive on all load-balanced frontend web server computers.
You must install Office SharePoint Server 2007 on a clean installation of the Microsoft Windows Server 2003 operating system with Service Pack 1 (SP1) or later. If you uninstall a previous version of Office SharePoint Server 2007 and then install Office SharePoint Server 2007, Setup might fail to create the configuration database, and the installation will fail.
You must install the same language packs on all servers.
All the instances of Office SharePoint Server 2007 in the farm must be in the same language.
You must use the Complete installation option on all computers you want to be index servers, query servers, or servers that run Excel Calculation Services.
If you want to have more than one index server in a farm, you must use a different Shared Services Provider (SSP) for each index server.
Install the role of Application server onto each farm server. (For detailed instructions, refer to Chapter 3.)
Install .NET 3.0. (For detailed instructions, refer to Chapter 3.)
From the product disc, run Setup.exe on one of your web server computers. Alternatively, from the product download, run Officeserver.exe.
On the “Enter your Product Key” page, enter your product key, and then click Continue.
On the “Read the Microsoft Software License Terms” page, review the terms, select the “I accept the terms of this agreement” checkbox, and then click Continue.
On the “Choose the installation you want” page, click Advanced. (The Basic option is for standalone installations.)
On the Server Type tab, select Complete.
Optionally, to install Office SharePoint Server 2007 at a custom location, select the File Location tab, and then type the location or Browse to the location.
When you have chosen the correct options, click Install Now.
When Setup finishes, a dialog box appears that prompts you to complete the configuration of your server. Be sure that the “Run the SharePoint Products and Technologies Configuration Wizard now” checkbox is not selected.
Click Close to start the configuration wizard. Instructions for completing the wizard are provided in the next set of steps.
Follow steps 1 through 11 on all additional servers in this farm.
In step 10, we unchecked the box for running the configuration wizard. If you recall from the last chapter, the configuration wizard gives you a task list of configuration items to complete after installation. On larger farms, you will generally want to finish installing your entire farm before going back through and performing configuration. After we have installed the bits to all of our servers, it’s time to run the SharePoint Configuration Wizard on our first server. Microsoft also recommends a certain order when installing.
Microsoft recommends that the Central Administration web application be installed on an application server, such as a query server or a server that runs Excel Calculation Services, but not on an index server (for performance reasons). If your farm will have an application server, install Office SharePoint Server 2007 on that server first. This also installs the Central Administration site.
All your frontend web servers.
The index server (if using a separate server for search queries and indexing).
Other application servers (optional).
In Chapter 3, we went through the steps of running the Configuration Wizard on our first server. In Figure 4-5, we see the results after installing this first server. Notice that, at this point, simply the Database Instance and the first server are showing. We are going to change that with the next series of steps.
At this point, the first server has been configured, and now we want to run the Configuration Wizard on the rest of the boxes in our farm. If you refer to the Recommended Order of Install, you can run the Configuration Wizard on every box in your farm in any order, but it must be done one server at a time. The recommended order applies when you actually start to place the services on the respective boxes in your farm, and this can be completed after you have joined the servers to the farm, which happens during the next series of steps.
When the Initial Configuration Screen (Figure 4-6) opens, click Next.
You will be greeted with a notification that services will be restarted automatically (Figure 4-7). This is normal. Click Yes.
Since we’re joining servers to an existing farm, we will select the radio button as shown in Figure 4-8 (“Yes, I want to connect to an existing server farm”).
In the next screen (Figure 4-9), enter the name of your database server. Once you do this, the button Retrieve Database Names will become active (see Figure 4-10). Click it.
After clicking Retrieve Database Names, the configuration wizard finds the correct configuration database (Sharepoint_Config) and fills in the username. Next, enter the database account password (Figure 4-11).
Click Next after entering the SQL Account Password, and then click the Advanced Settings button, as shown in Figure 4-12.
After clicking Next, you will have two choices (Figure 4-13). This screen simply asks whether you want to allow this server to host an instance of the Central Administration Web Application. Generally you should have two servers in a farm with this role, so you can fall back on one if the other is down. In this case, select the top radio button: “Do not use this machine to host the web site.” If you want to add this role to another box at a later time, you can do so via the Central Administration Web Console.
At this point (Figure 4-14), we are ready to begin the configuration; the wizard has all the information it needs. Click Next.
After selecting Next, the wizard will go through a series of nine steps (Figure 4-15). You do not need to do anything, and generally this completes within five minutes.
After the configuration part of the installation is complete (Figure 4-16), click Finish. You can go back to your Central Administration Console (Figure 4-17) and see that this server has been added to the farm.
Continue to run the installation procedure on every server that belongs in the farm. The end result should resemble Figure 4-18.
This chapter provides a step-by-step guide for building a Microsoft Office SharePoint Server 2007 multiserver farm implementation. Essentially, the build process is very simple and straightforward, but what happens after the build can make or break your implementation. Placement of services is critical, and there are many details that must be taken into consideration. As stated earlier in this chapter, there are times when a small farm will make more sense than a medium or large farm, and visa versa. Consider the following areas to start with your planning:
Number of users (multiple WFEs)
Number of documents (SQL storage)
Fault tolerance/allowable downtime (multiple WFEs, application servers, clusters)
As mentioned earlier in this chapter, there are a number of worksheets that Microsoft has placed on TechNet that will assist with planning your environment. Without proper planning, your implementation will fail or at the very least cause unnecessary headaches down the line. Using Microsoft’s planning worksheets can alleviate some future stress and allow you to provide for your customers with a well-thought-out implementation. This link will take you to the appropriate TechNet page:
| http://technet2.microsoft.com/Office/en-us/library/b28ba53d-a3e8-440f-9fcb-f592d858894a1033.mspx?mfr=true |
Tip
I suggest making these forms reusable and, in some ways, “smart documents.” With Infopath 2007, you can simply convert these forms and place them into a “Site Planning Page” on your MOSS environment. This page can then be used as a template for planning other sites in your environment. Just imagine walking into a kickoff planning meeting and having this type of a form already in place. You will be an instant hero!
Some of the information regarding roles and redundancy were taken from Microsoft’s Planning and Architecture for Microsoft Office Sharepoint Server 2007 document:
| http://technet2.microsoft.com/Office/en-us/library/d3e0e0fc-77b6-4109-87d6-53ad088db01d1033.mspx?mfr=true |
Get SharePoint 2007: The Definitive Guide now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
