Background: Physical Objects in Microsoft SharePoint Foundation
Applies to: SharePoint Foundation 2010
This topic describes the hierarchy of physical entities in Microsoft SharePoint Foundation. These entities are modeled by the higher-level classes in The Physical Object Hierarchy of the SharePoint Foundation object model. For background information about the content and service entities in a SharePoint Foundation deployment, see Background: Content Entities in Microsoft SharePoint Foundation and Background: Service Entities in Microsoft SharePoint Foundation.
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.
A SharePoint Foundation 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 SharePoint Foundation. (Strictly speaking, a SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation farm:
Each SharePoint Foundation 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 SharePoint Foundation solutions are installed and from which they can be deployed to servers and SharePoint Foundation Web applications.
A farm is one of four levels at which a SharePoint Foundation Feature can be activated. The other levels are Web site, site collection, Web application.
An enterprise can have more than one farm hosting SharePoint Foundation. For example, if enhanced collaboration server software, such as Microsoft SharePoint Server, is installed in addition to SharePoint Foundation, that software might require separate farm licenses for Internet-facing content and intranet content.
A physical server in a SharePoint Foundation farm has an IP address and a role. There are three possible roles for servers in SharePoint Foundation:
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 SharePoint Foundation 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 SharePoint Foundation 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. SharePoint Foundation ships with some services that are frequently off-loaded to application servers and developers can use the SharePoint Foundation object model to develop and run other services as part of their SharePoint Foundation 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 SharePoint Foundation 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) SharePoint Foundation 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 SharePoint Foundation 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.