L’essentiel sur le matériel

des informations de dimensionnement sérieuses pour SharePoint Portal Server. Mais il faut considérer les points suivants quand on achète du matériel destiné au nouveau serveur.

Premièrement, il faut inclure une seconde CPU chaque fois que c’est possible, pour traiter les pics de demandes et les tâches d’arrière plan comme le crawling et l’indexation. La seconde CPU offre aussi plus de souplesse à  long terme. N’importe laquelle des CPU contemporaines procurera une vitesse adéquate : le point important est le nombre de CPU disponibles.

Deuxièmement, SharePoint Portal Server partage une technologie base de données commune avec Microsoft Exchange Server. A en juger par l’Extensible Storage Engine (ESE) d’Exchange Server, qui aime la mémoire et utilise judicieusement la mémoire système disponible, je suggère de doter les machines SharePoint Portal Server d’au moins 256 Mo de RAM et de passer à  512 Mo de RAM dès que possible. Outre l’amélioration des performances, un tel système restera plus longtemps en production.

Troisièmement, les bases de données de SharePoint Portal Server utilisent un modèle de logging transactionnel, de la même manière que les bases de données d’Exchange Server. Par conséquent, il faut recenser les sources probables d’entrées/sorties et soigner la protection des fichiers importants. Il faut séparer (c’est-à -dire placer sur des unités physiques distinctes) les journaux (logs) de transactions des bases de données de SharePoint Portal Server, et tenir les journaux et les bases de données éloignés de Win2K et des applications (application binaries), dans la mesure du possible. Faute de quoi, il se peut qu’une défaillance de disque rende les journaux et les bases de données inaccessibles et aille jusqu’à  entraîner une perte de données. Pour protéger les bases de données de SharePoint Portal Server et obtenir les meilleures performances, il faut placer les bases de données sur un volume RAID 0+1 ou RAID 5. Un mécanisme miroir peut protéger adéquatement le volume qui héberge les journaux de transactions. Pour un système départemental servant jusqu’à  200 utilisateurs, un serveur biprocesseur, à  800 MHz ou plus, avec 512 Mo de RAM et des volumes distincts pour les binaires, les journaux et les bases de données, est suffisant. Avec bien sûr, un contrôleur de disque approprié.

Comme AD (Active Directory), SharePoint Portal Server pratique la journalisation (logging) circulaire pour réduire le nombre de journaux de transactions qu’engendre l’activité utilisateur. Cette étape simplifie également la gestion parce que l’on n’a plus à  craindre que le disque contenant les journaux épuise l’espace disponible par manque de sauvegarde. L’utilitaire Msmd-back.vbs, livré avec SharePoint Portal Server et qui gère la sauvegarde des restaurations, ne s’occupe des fichiers que pendant les restaurations et n’essaie pas de relire (replay) les journaux de transactions. (L’utilitaire rétablit un serveur dans l’état où il était lors de la sauvegarde la plus récente ; les transactions en cours sont perdues et donc il faut mettre en place un régime de sauvegarde rigoureux.)

Avant de choisir le mode d’installation des serveurs, lisez les recommandations de performances de Microsoft pour le déploiement de SharePoint Portal Server. Ainsi, bien qu’il n’existe aucune limitation technique quant au nombre de documents que l’on peut ranger dans un dossier, Microsoft conseille de ne pas dépasser 500. (On peut bien sûr avoir des milliers de documents dans un dossier, mais dans ce cas un client aura du mal à  obtenir les informations nécessaires pour afficher la Web Part qui donne la liste des documents.)