Share via


Physical topology recommendations (Office SharePoint Server)

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2017-01-25

The topology of your system’s database tier, and your network, physical storage, and caching can significantly affect system performance. When you plan your hardware, remember that Microsoft Office SharePoint Server 2007 is the last version of Office SharePoint Server that will run on 32-bit operating systems and databases. This article primarily describes improvements you can make when your system is running on Microsoft SQL Server 2008.

Important

If you are using the gradual upgrade method, to maintain reasonable response times from the server running SQL Server 2008 it might be necessary to increase the SQL Server resources supporting Office SharePoint Server 2007 by at least a factor of two.

The following sections give recommendations that are based on the best practices we have found for SQL Server 2005 databases hosting Office SharePoint Server 2007.

Start with a dedicated server running SQL Server 2008

The following recommendations apply to the database tier in your topology:

  • Always put SQL Server 2008 on a dedicated server that is not running any other farm roles or hosting databases for any other application, unless you are deploying your system on a stand-alone server.

  • We highly recommend that you install SQL Server 2005 64-bit version on a 64-bit operating system, unless you have a significant business reason not to.

  • For optimal performance, use Office SharePoint Server 2007 with SQL Server 2008 with the most recent service pack, unless you have a significant business reason to use an earlier version.

  • Use SQL Server connection aliases when you configure your server farm. A connection alias is an alternate name that can be used to make a connection to a SQL Server instance. If a database server fails, you can adjust the alias on the front-end Web server to point to another server. For more information, see How to: Set a SQL Server Alias (SQL Server Management Studio) (https://go.microsoft.com/fwlink/?LinkId=132064&clcid=0x409).

  • Ensure that the SQL Server 2008 input/output (I/O) channels to the disks are not shared by other applications, such as the swap file and Internet Information Services (IIS) logs.

Consider scaling out in addition to adding resources

It is important to track the following three resource components of a server running SQL Server 2008: CPU, memory, and I/O subsystem. When one or more of the components seem stretched, analyze the appropriate course of action based on the current and projected work load. Then, determine whether to add more resources or to scale out to a new server running SQL Server 2008. In general, we recommend that you consider scaling out in addition to adding more resources. For more information, see Troubleshooting Performance Problems in SQL Server 2008 (https://go.microsoft.com/fwlink/?LinkID=168448).

We recommend that you deploy an additional server running SQL Server 2008 when you have more than four Web servers running at full capacity.

Follow the SQL Server guidelines when choosing hardware

The following sections contain recommendations from the SQL Server 2008 team for hardware that can optimize performance of Office SharePoint Server 2007.

Memory

For the purposes of determining the amount of memory required for the computers running SQL Server 2008, first determine whether the planned deployment is small, medium, or large in terms of memory consumption.

Determine your deployment size by using the following table:

  • If your deployment parameters are generally less than the listed values, your deployment can be considered small.

  • If your deployment parameters are approximately equivalent to the listed values, your deployment can be considered medium.

  • If your deployment parameters are generally greater than the upper limits of most of the listed values, your deployment can be considered large.

Metric Value

Content database size

100 GB

Number of content databases

20

Number of concurrent requests to SQL Server 2008

200

Users

1000

Number of items in regularly accessed list

2000

Number of columns in regularly accessed list

20

For SQL Server 2008, 4 gigabytes (GB) is the minimum required memory, 8 GB is recommended for medium size deployments, and 16 GB and greater is recommended for large deployments.

Other factors that can influence your memory needs include:

  • The use of SQL Server 2008 mirroring.

  • The frequent use of files larger than 15 megabytes (MB).

CPU cache

On the server running SQL Server 2008, we recommend that the L2 cache per CPU have a minimum of 2 MB to improve memory.

Bus bandwidth

Greater bus bandwidth helps improve reliability and performance. Consider that the disk is not the only user of bus bandwidth — for example, you must also account for network access.

The following list provides some best practices and recommendations for optimizing bus bandwidth.

  • For medium to large-sized servers, greater bus bandwidth improves the system’s reliability, especially with added multi-pathing software. Conversely, greater bus bandwidth does not give a significant increase in reliability for smaller systems. The bus bandwidth’s reliability is improved through the redundant paths in the system and by avoiding single-point-of failure in hardware devices.

  • Greater bus bandwidth provides improved performance in systems that frequently use large block transfers and sequential I/O.

  • In smaller servers that use mostly sequential I/O, PCI becomes a bottleneck with three disks. For a small server that has eight disks performing mostly random I/O, PCI is sufficient. However, it is more common for PCI-X to be found on servers ranging from small to very large.

  • Greater bus bandwidth is necessary to support a large number of disks.

  • The capacity of bus bandwidth might be limited by the topology of the system. If the system uses direct attached disks, the number of slots limits the bus bandwidth capacity. However, for storage area network (SAN) systems, there is no physical limiting factor.

  • More expensive servers typically have larger and faster buses. There is often no way to increase the capacity of the buses’ bandwidth without replacing the servers. However, the largest servers are more configurable. Consult with server providers for specifications.

Disk and SAN interfaces

The interfaces you use in your system can affect reliability and performance. Larger drives, all else being equal, increase mean seek time. Use the information in the following table to inform your choice of interface.

Interface Benefits Disadvantages Notes

Small Computer System Interface (SCSI)

Supports forcing data to be written to disk, improving recoverability.

SCSI with Tagged Command Queueing (TCQ) supports multiple I/O requests.

Supports hot-swapping.

SCSI can have up to 15 drives per channel.

Less restrictive on physical cable length.

Overloading the channels increases the chance of reaching the transfer rate limit.

Integrated Device Electronics (IDE)

Supports hot-swapping.

IDE has high transfer rates only if there is one drive attached per channel.

Typically greater capacity than SCSI.

Typicallly cheaper per GB than SCSI drives.

Can only handle one outstanding I/O request per channel.

Serial Advanced Technology Attachment (SATA)

SCSI with TCQ supports multiple I/O requests.

Supports hot-swapping.

Most are explicitly designed to support only one drive per channel; however, multiple SATA channels of 2 to 12+ on interface cards are also available.

Typically greater capacity than SCSI.

Typically cheaper per GB than SCSI drives.

Serial-attached SCSI (SAS)

Very fast.

Supports SCSI protocol.

Allows for a larger number of disks than SCSI.

Applicable to Direct-attached Storage (DAS) only.

Replacement technology for parallel SCSI.

Backward compatible with SATA drives.

Database redundancy within a data center

You should provide redundancy for either type of storage within a data center.

Database redundancy across data centers

Data stored in either SAN and DAS can be mirrored or replicated to support business continuity requirements, but the technique for mirroring differs as follows:

Note

Some SQL Server 2008 technologies, such as transactional replication, cannot be used with SharePoint Products and Technologies because the replication technology requires that a database have a primary key column on all tables. Before you implement replication technologies, ensure that the technology is supported for both SQL Server 2008 and Office SharePoint Server 2007. 

Snapshot technologies can be used to take point-in-time snapshots of the data hosted on a SAN. DAS, in most cases, does not offer the additional software and services to make snapshot support available.

Supporting technologies such as Microsoft System Center Data Protection Manager 2007 can be used to provide additional protection for Microsoft SQL Server and Microsoft Office SharePoint Products and Technologies.  Microsoft System Center Data Protection Manager 2007 enables disk-based and tape-based data protection and recovery for servers in and across Active Directory® domains.  .

Performance

For both DAS and SAN, the following categories of performance should be measured:

  • I/O per second

  • Megabytes per second

  • Latency

Performance of both DAS and SAN environments is affected by so many variables that simple recommendations are not possible. Examples of variables include drivers, configuration, underlying and supporting foundational technologies, and host bus adapters (HBAs).

Fibre-Channel-switched fabric can be beneficial for SAN environments, because Fibre Channels can provide multiple links through the fabric, and can thereby enable I/O path parallelism so that the SAN can process I/O requests more efficiently.

Minimal latency on the I/O subsystem that serves the server that runs SQL Server is very important. Slow response from the I/O subsystem cannot be compensated for by adding other types of resources, like CPU or memory, but it can influence and cause issues throughout the farm. Plan for minimal latency before deployment, and monitor your existing systems as described in Monitor and troubleshoot storage performance.

Network topology recommendations

Plan your network connections within and between farms. We recommend that you use a network with low latency.

The following list provides some best practices and recommendations:

  • All servers in the farm should have LAN bandwidth and latency to the server that is running SQL Server 2008(up to 1 millisecond (ms) latency).

  • We do not recommend a wide area network (WAN) topology in which a server that is running SQL Server 2008 is deployed remotely from other components of the farm with network latency greater than 1 ms. This topology has not been tested.

  • Plan for an adequate WAN network if you are planning to use SQL Server 2008 mirroring or SQL Server 2008 log shipping to keep a remote site up-to-date.

  • Plan to use the backup compression feature of SQL Server 2008 Enterprise Edition. By setting the compression option in your backup script, or by configuring the application server running SQL Server 2008 Enterprise Edition to compress by default, you can significantly decrease the size of your database backups and shipped logs. For more information, see Backup Compression (SQL Server) (https://go.microsoft.com/fwlink/?LinkId=129381&clcid=0x409).

    Note

    Database compression is not supported for SharePoint Products and Technologies.

Disk topology

The disk topology that you use in your system can affect reliability and performance.

You should minimize latency on the I/O subsystem that serves the server running SQL Server 2008. Slow response from the I/O subsystem cannot be compensated for by adding other types of resources (for example, CPU or memory), but can influence and cause issues throughout the farm.

Use the information in the following table to inform your choice of topology.

Topology Benefits Disadvantages Notes

SAN

Can serve multiple servers.

No limitations on the number of disks that can be accessible.

Easier to install additional servers. Easier to manage many servers.

Easier to reallocate disk storage between servers.

Maintenance costs tend to be lower than Direct-attached Storage (DAS).

DAS

Greater maximum bandwidth.

Easier to manage for a smaller number of servers.

Initial overhead costs are lower than SAN.

Deployed per server.

The number of disks is limited by the number of slots in the server and the type of interface used.

Consider DAS if you are experiencing bottlenecked workloads.

When the limit on the number of DAS for a particular server is reached, you must deploy an additional server running SQL Server 2008.

Network-attached storage (NAS)

I/O response time required for SQL Server 2008 cannot be guaranteed nor maintained in a NAS environment.

iSCSI can only support light I/O traffic.

We do not recommend that you use NAS due to inability to ensure sufficient latency. If networked storage is required, use iSCSI on an iSCSI- dedicated gigabit Ethernet local area network (LAN), rather than NAS.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

See the full list of available books at Downloadable content for Office SharePoint Server 2007.