A Microsoft Office SharePoint Server 2007 (MOSS) production environment is designed according to projected load, usage pattern, services, content volume and growth projections. There is a lot of information that has been published by Microsoft and others on these topics, but i recently had a need to summarize this for a client, so here are hardware and server sizing guidelines for MOSS - brief, to the point and all in one place.
 
Virtualized deployments will be covered in a follow-up post.
 

Guidelines

  • Memory will typically be the first bottleneck on all MOSS server roles.
  • I highly recommend 64-bit for the entire infrastructure. A single web-server, single database server 64-bit environment will support up to 3,000 users. 64-bit offers the following advantages:
    • Memory addressability (up to 1,024 gigabytes vs 4-GB on a 23-bit system)
    • Larger numbers of processors (up to 64 vs. 32 on 32-bit) and more linear scalability per processor
    • Enhanced (faster and wider) bus architecture. This is somewhat analogous to the improvement that broadband connections offer over dial-up connections

      Note: Itanium-based systems are not supported
  • Office SharePoint Server 2007 requires Active Directory services for farm (multi-server) deployments.
 

Server Roles

A MOSS environment typically consists of at least two physical machines – a Web Server and a Database Server. It is not recommended to deploy MOSS to a one-server production environment.  Larger environments, or computing-intensive environments may also include an Application Server role, which may host Excel Calculation Services and/or Indexing Services, or even Project Server 2007.

Web Front End Farm Server

One or more Web FE Serves will be specified for your environment, depending on load and high-availability requirements.
 
Hardware Specification
Processor
2 dual-core 2.5+ GHz
64-bit
Memory
4 GB
Disk Space
15 GB (web server only)
 
50 GB (if running index service)
Network
1 Gbps connection to other farm machines
 
56 Kbps or faster to client
Software Pre-Requisites
OS
Windows Server 2003 SP 1, Standard x64 Ed.
+ most recent updates
Software
.NET Framework 2.0 x64
 
Windows Workflow Foundation (.NET 3.0)
Updates
.NET Framework update KB923197 for x64
 
.NET Framework update KB925613

 

Application / Index Server

If a separate Index, Search, or Excel Services server has been specified, use the following guidelines for hardware procurement.
Hardware Specification
Processor
2 dual-core 2.5+ GHz
64-bit
Memory
8 GB
Disk Space
50GB (pending detailed requirements) *
Network
1 Gbps connection to other farm machines
* The above disk space recommendation can accommodate indexing of around 100GB of content.  Exact disk space requirements also depend on the server role.
Software Pre-Requisites
OS
Windows Server 2003 SP 1, Standard x64 Ed.
+ most recent updates
Software
.NET Framework 2.0 x64
 
Windows Workflow Foundation (.NET 3.0)
Updates
.NET Framework update KB923197 for x64
 
.NET Framework update KB925613

Database Server

While SharePoint 2007 supports SQL Server 2000, I recommend using SQL Server 2005 which displays dramatic performance improvements over SQL 2000.
 
Hardware Specification
Processor
2 (or 4) dual-core 2.5+ GHz
64-bit
Memory
16GB for one FE server / 32 GB for MOSS farms
Disk Space
 (see below)
Network
1 Gbps connection to other farm machines

To estimate data storage requirements for a MOSS environment, please use the worksheet below.   Raw Content Size refers to the volume of documents or pages that are to be stored in MOSS. 

 
Storage Requirements Worksheet
Raw Content Size
_____
x 2.4
______
OS install
 
 
4 GB
SQL install
 
 
.5 GB
MOSS config db
 
 
1.5 GB
SubTotal
 
 
______
Min free space
SubTotal / 3
 
______
Total Diskspace Requirement
 
 

______
Storage Requirements Worksheet Sample
Raw Content Size
10 GB
x 2.4
22 GB   
OS install
 
 
4 GB
SQL install
 
 
.5 GB
MOSS config db
 
 
1.5 GB
SubTotal
 
 
28 GB
Min free space
SubTotal / 3
 
9 GB
Total Diskspace Requirement
 
 
37 GB
 
Software Pre-Requisites
OS
Windows Server 2003 SP 1, Enterprise x64 Ed.
+ most recent updates
Software
.NET Framework 2.0 x64
 
Microsoft SQL Server 2005 x64
 
Windows Workflow Foundation (.NET 3.0)
Updates
.NET Framework update KB923197 for x64
 
.NET Framework update KB925613

 

High Availability Options

Like any computing or application environment, scalability and availability are important factors to consider when deploying a MOSS environment. MOSS supports various options and topologies for scale, alleviating the paing of planning ahead by allowing future addition of a web server, or isolating an application server at a later time.
The question of high availability, however, is critical to ask upfront. When deciding on an infrastructure, customers should answer the following questions to determine if they need hardware redundancy or other high availability options:
  • Is your availability requirement 99% or greater?
  • If the service becomes unavailable, will employees of your organization be unable to reasonably perform their expected job responsibilities?
  • If the service becomes unavailable, will business and customer transactions be halted, leading to loss of business and customers?
If you answered any or all of these questions with “yes”, database redundancy and automatic failover is important for your organization and you should consider the options described below.
 

Web Front End and Application Server

Network Load Balancing
At the web front-end, high availability can be achieved using two or more active web servers on distinct hardware. These web servers are identical MOSS server instances that are load-balanced using a hardware load-balancing device such as Cisco's Local Director (CLD), or Big IP.  In the case of hardware failure, the alternate web server will carry the load until the failed server is brought back online.
Virtual Image
In a virtualized deployment (not addressed in this white-paper), a virtual image of the FE web server is base-lined and backed up. In the case of hardware or software failure, the backup image is brought online on a different machine. This solution does not provide automatic failover or high-availability, but may be implemented if scheduled and unscheduled outages are acceptable.

Database Server

Disk Drive
The database server should have at the very least a RAID 5 configuration for disk redundancy, better RAID 10 for increased data recoverability should one or more hard drives fail.  
A SAN or similar shared storage solution typically already accounts for data recoverability and is the preferred approach, if available.
Clustering
Failover (active/passive) clustering provides high availability database solution that addresses availability through redundancy, and performance through additional computing capacity. Clustering requires two distinct processing servers that share a common data store.
Failover clustering can be combined with other high availability methods such as log shipping or mirroring to minimize the loss of data and productivity in case of catastrophic hardware failures.
Mirroring
Database mirroring is a new SQL Server 2005 technology that can deliver high availability and high performance solutions for database redundancy. In database mirroring, transaction log records are sent directly from a principal to a mirror database whenever the principal's transaction log buffer is written to disk (hardened). This technique can keep the mirror database nearly up to date with the principal, and with no loss of committed data. In the High Availability operating mode, if the principal fails, the mirror server will automatically become a new principal and recover its database. As with log shipping, implementing database mirroring does require additional hardware to be purchased.
Log Shipping
Log shipping automatically sends transaction log backups from a primary database on a primary server instance to one or more secondary databases on separate secondary server instances. The transaction log backups are applied to each of the secondary databases individually. Log shipping requires that additional hardware be purchased (unlike failover clustering).
 
Below is a table that compares the three supported high-availability database solutions:

 

Category or Feature
Failover Clustering
Log Shipping
Database Mirroring
Scope of Availability
Server instance
Database
Database
Standby type
Hot
Warm
Hot
Database downtime during failure
30 seconds + database recovery
variable
<10 seconds
Redundant storage locations
No (shared disk)
Yes
Yes
Hardware requirements
Cluster certified servers and storage
Standard servers
Standard servers
Physical distance limit
100 miles
None
None
SQL Server version
All
All
SQL Server 2005 SP1