Architecture Talk - SharePoint Farms
Microsoft Office SharePoint Server 2007 is highly scalable in both directions: vertical and horizontal. The support for 64-bit architecture, multi-CPU/multi-core hardware, and large amounts of memory makes it possible to scale up boxes running SharePoint Server 2007. The mere fact that SharePoint Server 2007 has a multi-tier architecture makes it possible to split its different components (called server roles) to different boxes. Also, each role can be installed on redundant boxes to support failover.
Referring to SharePoint Server TechCenter, you can find drill-down information for SharePoint Planning and Architecture and Deployment. Both discuss various application scenarios of MOSS, with different sizing requirements.
A proper capacity planning and availability requirement analysis should take place to reach the best fit for your organization. If that’s not possible then you can go for a small to medium-sized deployment and grow accordingly. However, meeting the bar of redundancy, you may need to deploy SharePoint on more boxes than needed.
Farms in SharePoint can have any size with X x Y x Z number of servers, and these are recommended for production environments. X is the number of Web Front Ends (Web Servers), Y is the number of Applications Servers (resource intensive servers like search, excel services, project, …), and Z is the number of Database Servers. This is compared to single server deployment, where you have one server running all SharePoint components including the database, which I recommend only for development and testing environments.
- Web-Front Ends receive the hits of users in order to serve web sites. They also deliver forms and run the workflows. If more than one server is used for this role, then load-balancing (via hardware or software load balancing) is needed. However, SharePoint handles the introduction of new servers and how different content can be served on different servers via configuring and extending web applications. Administrators need not worry about anything else, other than properly configuring NLB or the load balancers.
- Application Servers are used to for those intensive shared services like: index, query (search), and Excel calculation, and other shared services. It's also preferable to push the front-ends of admin sites to these servers, like Central and SSP Administration. You can have any number of servers to play the role of application servers (query, excel, project, ...) with the exception of Index server. You can have one Index server in a SharePoint environment, however, this only affects indexing, since querying is a different role that can be redundant. Simply, what you lose when an Index server is down is the index refresh which can be recovered quickly. Searching will continue to function even if the Index Server is down. Load balancing is not required as SharePoint will understand how to direct requests in the farm to different servers in this role.
- Database Servers run SQL Server to host and deliver the configuration database, and content databases. This is however, a pure SQL Server installation (2000 with SP4, or 2005). load balancing this role requires the use of clustering.