Partager via

Meilleures pratiques pour un fonctionnement optimal

  • Article

Mise à jour : 2008-08-28

Microsoft Office SharePoint Server 2007 is used for a broad set of applications and solutions, either stand-alone or in concert with other systems. To accomplish this flexibility, the platform supports lots of possible architectures and configurations. Some parts of the system are well-known, but we still see variances to these parts. This article focuses on the top configuration best practices that you should consider, such as front-end Web server configuration, database configuration, servicing and patching, and improvements included in the Mise à jour d’infrastructure pour les produits serveur de Microsoft Office.

This article is one of a series of Best Practices articles for Office SharePoint Server 2007. This article describes best practices for operational excellence. For more articles in the series, see Meilleures pratiques. For additional information and resources regarding Best Practices for Office SharePoint Server 2007, see the Best Practices Resource Center (https://go.microsoft.com/fwlink/?LinkID=125981&clcid=0x409).

1. Use 64-bit hardware, plenty of memory, and fast network cards

64-bit hardware (for all server roles) offers the best performance for Office SharePoint Server 2007. In addition, make sure that you allocate appropriate memory for each server role:

  • Allocate at least 2 gigabytes (GB) of RAM per processor for front-end Web servers and application servers.

  • Allocate at least 4 GB of RAM per processor for database servers.

  • Use gigabit network cards for all server roles.

  • For front-end Web servers and application servers, use dual NICs in production environments: one for users, one for SQL Server communication.

  • Under heavy load, consider using virtual local area networks (vLANs) to reduce network traffic.

For more information, see Recommandations pour la topologie physique (Office SharePoint Server) and Autres facteurs de planification de la capacité et des performances (Office SharePoint Server).

2. Stay close: Do not put too much network distance between front-end Web servers, application servers, and database servers

No front-end Web server or application server should have more than 1 millisecond (ms) of latency between it and the database server. In practice, this generally means that you should keep all the servers in a farm in the same data center. All servers in a farm have to be in the same time zone.

For more information, see Planifier la configuration requise pour la bande passante and Optimisation d’Office SharePoint Server pour des environnements de réseau étendu.

3. Configure front-end Web servers and application servers with performance and availability in mind

The way you configure front-end Web servers and application servers can have a big effect on throughput and availability. Follow these recommendations for best results.

  • Separate system components into logical drives with the following RAID levels for redundancy:

    Components on drive Recommended RAID level

    Windows and Program Files drive

    RAID 1

    Operating System swap drive

    RAID 1

    Log files

    RAID 1

    Boot disk for imaging and Windows Desktop Search (Optional)

    RAID 1

  • Use at least four physical disks and use separate disks to keep the log files and swap drive separate from the Windows/Program Files drive.

  • Allow at least one front-end Web server for every 20,000 users. Note that for high availability, you have to have two front-end Web servers for every 20,000 users.

For more information, see the following resources:

4. Configure database servers with performance and availability in mind

As is also the case with front-end Web servers and application servers, the configuration for database servers affects how well Office SharePoint Server 2007 performs. Separate each type of data onto individual spindle sets, with the appropriate RAID level, spindles, and optimization for each data type, as shown in the following table.

Type RAID level Spindles Optimization

TempDB

[RAID 1+0] - 10% of total database size

2 IOPS/ GB

Write optimized

Transaction Logs

[RAID 1+0]

2 IOPS/GB

Write optimized

Search property store (Search database)

[RAID 1+0]

2 IOPS/GB

Read/Write optimized

Content databases

[RAID 1+0]

0.75 IOPS / GB

Read optimized

For more information, see Recommandations pour le stockage physique (Office SharePoint Server) and Planification et surveillance du stockage SQL Server pour Office SharePoint Server : recommandations et meilleures pratiques pour optimiser les performances : livre blanc.

5. Keep it clean: Maintain databases in a healthy state

A healthy database server has enough headroom for databases and log files, plus enough capacity to keep up with requests. Use the recommendations in the following list to keep database servers performing optimally.

  • Pre-grow all databases and logs if you can. Be sure to monitor the sizes so that you do not run out of disk space.

  • Do not overload database servers by using too many databases or data. Use the following guidelines:

    • When using SQL Server mirroring, do not store more than 50 databases on a single physical instance of SQL Server.

    • Limit content databases to 100 GB.

  • Defragment and rebuild indices daily, if you can absorb the downtime required to rebuild.

  • Monitor the database server to make sure that it is responding appropriately and is not overloaded. Key performance counters to monitor include the following:

    • Network Wait Queue: at 0 or 1 for good performance

    • Average Disk Queue Length (latency): less than 5 ms

    • Memory used: less than 70%

    • Free disk space: more than 25%

For more information, see the following resources:

6. Keep servers current with the latest updates

It is important to keep current by applying the latest hotfixes, updates, and service packs. These updates contain important product enhancements and improvements. However, be sure that you thoroughly test these updates on the pre-production environments before you apply them to the production environments. Follow the recommended procedure for deploying the updates, including the following:

  • Turn on Windows Update to download updates automatically, but not install automatically.

  • Schedule time to install updates at off-peak hours.

  • For high availability, rotate servers out of service one at a time during the update process.

Make sure that you are patching the BIOS (server computers, controllers, and disks), Windows operating system, Windows SharePoint Services 3.0 and Office SharePoint Server 2007, and SQL Server.

For more information, view the presentation Understanding and deploying hotfixes, public updates, and service packs (https://go.microsoft.com/fwlink/?LinkId=123927&clcid=0x409), and see the Updates Resource Center for SharePoint Products and Technologies (https://go.microsoft.com/fwlink/?LinkID=106182&clcid=0x409).

7. Use different accounts for different actions

Use appropriate accounts for the Web applications and services. All accounts should be domain accounts (reminder: do not use Network Service). For best results, use separate accounts for the following:

  • Web applications: Use different accounts for each Web application.

  • Search account: Use one account for the farm.

  • Excel Services account: Use one account for external connections.

For more information, see Autorisations de compte et paramètres de sécurité (Office SharePoint Server).

There are many more accounts that are used by Office SharePoint Server 2007, such as SQL Server services accounts, the Central Administration application pool identity, the Windows SharePoint Services Timer service account, the default content access account, the single sign-on account, and the profile import account. Be sure to follow recommended procedures to keep their passwords current and ensure that the services keep working.

For more information, see Changer les mots de passe utilisés pour les comptes d’administration (Office SharePoint Server).

8. Follow recommendations for backing up and restoring data

In general, it is best to use a local disk, not a network drive, for backups, and then copy the data later. Use compression when you can, but when you use compression with backups, be mindful not to overwhelm SQL Server. For example, SQL LightSpeed compresses during backup which can disrupt SQL Server performance.

For large databases, rely on incremental backups such as those available with Microsoft System Center Data Protection Manager (DPM). Do not rely on full backups as your primary mechanism — they are too large to restore quickly.

For more information, see Conseils pour améliorer les performances de sauvegarde et de récupération (Office SharePoint Server) and Protection et récupération des données pour Office SharePoint Server (livre blanc).

9. Be sure that you back up and truncate the log files

Do not just back up the data. Back up the log files, too. The usage logs, IIS logs, transaction logs, and SMTP e-mail logs all must be backed up. For transaction logs, you should back up and truncate the log file every five minutes. However, never shrink the transaction log because you may experience performance issues while the log re-grows.

For more information, see Sauvegarder les journaux (Office SharePoint Server 2007) and How to stop the transaction log of a SQL Server database from growing unexpectedly (https://go.microsoft.com/fwlink/?LinkID=111458&clcid=0x409).

10. Restoring data: Test backups and have a standby environment available for service continuity

Routinely test backups and validate their consistency. Do not assume that the backup will work when you need it to. Make sure that it will. Practice recovery to learn what else you must do to bring back the whole environment. For geographically dispersed environments, prepare for disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Similarly, you can set up a standby environment running the same version of software as the production environment so that you can restore the databases and recover documents quickly. Keep databases small to speed recovery.

For more information, see Protection et récupération des données pour Office SharePoint Server (livre blanc).

Acknowledgements

The Office SharePoint Server 2007 Content Publishing team thanks the following contributors to this article:

  • Simon Skaria, Microsoft SharePoint Customer Advisory Team

  • Doron Bar-Caspi, Microsoft SharePoint Customer Advisory Team

  • Steve Peschka, Microsoft Consulting Services

  • Jason Cahill, Microsoft Office SharePoint Server Core

  • Mark Harmsworth, Microsoft Office SharePoint Server Core

  • Todd Carter, Microsoft Premiere Field Engineering

  • Cory Burns, Microsoft Hosted SharePoint

Voir aussi

Concepts

Exécuter l’outil Best Practices Analyzer (Office SharePoint Server)

Autres ressources

Microsoft Best Practices Analyzer for Windows SharePoint Services 3.0 and the 2007 Microsoft Office System
Best Practices for Managing and Securing SharePoint 2007