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
|