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:

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.

Hardware Specification

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.

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:

Pramod - You may want to switch your SQL Server recovery model from Full to Simple to have your transaction log truncated every now and then. See: http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1069109,00.html

I am curious as to how much load a single SQL server could handle. I am implementing WSS with 14 content databases (each being 100 GB). My server will be Win2K3 x64, 32 GB RAM, fibre channel SAN for disk storage, dual 8-core Intel Xeon 7500 series CPU with Hyper-threading and SQL 2K5 standard. Can a single SQL server handle the load or should I be looking at an active cluster.