Background: Physical Objects in Windows SharePoint Services

Article
05/05/2014

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

This topic describes the hierarchy of physical entities in Windows SharePoint Services 3.0. These entities are modeled by the higher level classes in the The Physical Object Hierarchy of the Windows SharePoint Services object model. For background information about the content and service entities in a Windows SharePoint Services deployment, see Background: Content Entities in Windows SharePoint Services and Background: Service Entities in Windows SharePoint Services.

Overview

The classes in the Physical Objects hierarchy represent entities that are either actual physical objects or objects that, depending on the context, can be regarded either as physical objects or as non-physical.

The Farm

A Windows SharePoint Services server farm (represented by the SPFarm class) is a cluster of physical servers that includes one or more front-end servers, zero or more application servers, and an SQL Server that may be hosted on a dedicated database server or on one of the application servers (or on the server if a single server deployment). The database can also be hosted by a mirrored cluster of servers that will appear as one server to Windows SharePoint Services. (Strictly speaking, a Windows SharePoint Services 3.0 deployment is always hosted on a farm, although it may be a "farm" with just a single computer that contains the whole deployment.)

If there is more than one front-end server, the front-end servers are load-balanced. This means that load-balancing software (or load-balancing hardware) directs an incoming network connection from a client computer to whichever front-end computer in the farm is least busy at the time. Thus, the workload of servicing client connections is spread over many servers and hence many processors, hard drives, and other peripherals. Clients get much better performance. An additional advantage is that if one of the servers should crash, the others can continue to handle all incoming connections. Service is slowed, perhaps, but does not stop completely.

Because the client computer is seeking to interact with a particular application, file, database, or Web site page, all the computers to which the client could potentially be connected must be identically configured. Clients do not care, and usually do not know, which physical server they post to—the farm appears to the outer network as a single server.

The simplest way to accomplish an identical configuration would be to install the same applications on all the computers and to put copies of any needed files, databases, and Web site pages on them all (with the identical directory paths). However, this is rarely practical because it requires that every change a client makes to a file, or database, or anything else that persists on the server, is propagated to all the other servers. To ensure that the servers stay in sync, the farm would have to block incoming connections during the propagation. The decrease in performance caused by all the propagation, cancels the advantages that the farm is supposed to provide. In fact, even moderately used Windows SharePoint Services deployments would be in an almost continuous state of propagating changes.

To avoid these problems, some servers in the farm are given special tasks, such as hosting a database. The front-end servers to which clients are connected do not have the database copied to them, but they are still identically configured because they use the same connection string and network address to access the database.

The following are some of the characteristics of a Windows SharePoint Services farm:

Each Windows SharePoint Services farm has a configuration database that holds information about the farm, its servers, and the other important child classes of the farm.
The farm is the level of the object model at which Windows SharePoint Services solutions are installed and from which they can be deployed to servers and Windows SharePoint Services Web applications.
A farm is one of four levels at which a Windows SharePoint Services Feature can be activated. The other levels are Web site, site collection, Web application.

An enterprise can have more than one farm hosting Windows SharePoint Services 3.0. For example, if enhanced collaboration server software, such as Microsoft Office SharePoint Server 2007, is installed in addition to Windows SharePoint Services 3.0, that software might require separate farm licenses for Internet-facing content and intranet content.

Servers

A physical server in a farm has an IP address and a role. There are three possible roles for servers in Windows SharePoint Services:

Single server: As the name implies, a server has this role if, and only if, it is the sole server in the farm.
Front-end server: More than one server can have this role. A front-end server accepts HTTP requests from client computers. Because it serves content in response to these requests, it must have a content publishing Web application running on it.
Application server: Any Windows SharePoint Services server (with one exception) that is not functioning as either a front-end server or single server has the role of application server. These servers run specialty Windows SharePoint Services Web services or Windows services that need to be off-loaded from the front-end servers because they are very intensive in using the server's processor, hard disk, or other hardware resource. Windows SharePoint Services 3.0 ships with some services that are frequently off-loaded to application servers and developers can use the Windows SharePoint Services object model to develop and run other services as part of their Windows SharePoint Services deployment.

The exception referred to in the last bulleted item refers to the server that hosts the SQL Server database. This database can be on any of the application servers, but typically, if the Windows SharePoint Services deployment is large enough to require a multi-server farm, then the database will need its own server (and possibly a mirrored cluster of servers). When the database is on its own dedicated server (or cluster) Windows SharePoint Services is not even installed on that server. The server is identified in the configuration database of the farm and it will appear to the farm that it is running a service called the Windows SharePoint Services Database Service but this is really just an alias for the SQL Server service running on the database server. This dedicated server does not normally have Windows SharePoint Services installed on it and it does not really have a role in the farm.

More than one application server can be running a given Web or Windows service. For example, more than one server can be running the Search service. Each of the servers has a separate instance of the service.

Background: Physical Objects in Windows SharePoint Services

Overview

The Farm

Servers

See Also

Reference

Concepts

Other Resources

Additional resources