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.

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.

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.

Database redundancy within a data center

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

• For a SAN or for shared disks, clustering is the most common and cost-effective technology. SharePoint Products and Technologies natively support the use of clusters, which are available in the SQL Server 2008 Standard Edition. Operations teams may find that clustering offers a familiar availability solution. For more information, see Configure availability in a single farm by using SQL Server clustering ( https://go.microsoft.com/fwlink/?LinkId=168606).

• For dedicated disks or disk-attached storage (DAS), , you can use SQL Server 2008 database mirroring. SharePoint is not natively aware of database mirroring. To change connections when a mirror fails over, we recommend that you use a SQL Server client alias and that you manually manage the failover process by modifying the alias to point to the failover partner. For more information, see Using Database Mirroring with Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409).

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:

• Most SAN vendors provide data mirroring across multiple sites.

• In most DAS-based scenarios, a method of software-based replication is required, either delivered by the vendor or enabled through technologies such as database mirroring or log shipping.

  If you choose to use asynchronous mirroring, SharePoint can take advantage of the SQL Server 2008 log stream compression capability, and — if you are running SQL Server 2008 Enterprise Edition — can also take advantage of the ability to use an additional redo thread per database for every four cores in the system. For more information, see:

  • Plan for availability (Office SharePoint Server)

  • Configure disaster recovery across SharePoint farms by using SQL Server log shipping

  • Integration of 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.

Download this book

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

• Planning and architecture for Office SharePoint Server 2007, part 2

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