Planifier l’architecture matérielle dans Project Server 2010
S’applique à : Project Server 2010
Dernière rubrique modifiée : 2015-03-09
De nombreux facteurs peuvent avoir un impact majeur sur le débit dans Microsoft Project Server 2010. Ces facteurs comprennent le nombre d’utilisateurs, ainsi que le type, la complexité et la fréquence des opérations utilisateur, le nombre de publications dans une opération et les performances des connexions de données. Vous devez évaluer attentivement les facteurs présentés dans cette section lorsque vous planifiez votre architecture matérielle. Project Server peut être déployé et configuré de nombreuses façons. Par conséquent, il n’est pas aisé d’évaluer le nombre d’utilisateurs pouvant être pris en charge par un nombre de serveurs donné. Veillez donc à effectuer des tests dans votre propre environnement avant de déployer Project Server 2010 dans un environnement de production.
Cet article décrit les limites de performances et de capacité de Microsoft Project Server 2010 testées, fournit des informations sur l’environnement et les résultats des tests, puis propose des conseils pour des performances acceptables. Utilisez les informations contenues dans cet article pour estimer les objectifs de débit pour Project Server.
Lorsque vous entreprenez la planification de la capacité pour Microsoft Project Server 2010, tenez compte des variables pouvant avoir une incidence sur les performances d’un déploiement Project Server.
En raison du jeu de fonctionnalités enrichi fourni par Project Server, des déploiements qui semblent similaires dans leur structure générale peuvent différer sensiblement en termes de performances réelles. Il ne suffit pas de définir vos exigences uniquement en fonction du nombre de projets ou du nombre d’utilisateurs que comptera le système. Se pencher sur les performances du déploiement Project Server requiert une approche plus nuancée et holistique. Par exemple, les charges de travail et, par voie de conséquence, vos besoins matériels, diffèreront en fonction des variables suivantes :
| Facteur | Caractéristiques |
|---|---|
Projets |
|
Utilisateurs |
|
Modèles d’utilisation |
|
De nombreuses autres variables peuvent avoir une incidence sur les performances dans un environnement donné et chacune de ces variables peut avoir un impact sur les performances dans différents secteurs. Certains des résultats des tests et certaines des recommandations indiqués dans cet article peuvent concerner des fonctionnalités ou des opérations utilisateur qui n’existent pas dans votre environnement et qui, par conséquent, ne s’appliquent pas à votre solution. Seuls des tests minutieux peuvent vous fournir des données précises sur votre propre environnement.
Autres variables à prendre en compte :
Simultanéité d’utilisateurs : la charge d’utilisateurs simultanés joue souvent un rôle significatif dans la définition des contraintes de capacité. Même si le système comporte un nombre relativement réduit d’utilisateurs, ceux-ci peuvent tous solliciter le serveur simultanément pendant les périodes de trafic de pointe. Par exemple, une organisation dont tous les utilisateurs envoient des mises à jour d’état ou de feuille de temps au même moment de la semaine constatera vraisemblablement une diminution sensible des performances pendant ces périodes. Si votre système connaît des périodes d’utilisation très intensives, pensez à ajouter des ressources à la topologie recommandée pour votre jeu de données.
Fractionnement des rôles des utilisateurs : la répartition des utilisateurs entre les rôles d’administrateurs, d’administrateurs de portefeuille, de responsables de projet et de membres d’équipe a une incidence sur les performances de votre déploiement dans la mesure où chaque type d’utilisateur peut accéder à une quantité de données différente. Les utilisateurs présents dans les différentes catégories de sécurité peuvent varier en fonction du nombre de projets et de ressources qu’ils peuvent voir. Les administrateurs, par exemple, peuvent voir tous les projets sur le serveur lorsqu’ils chargent le Centre de projets et toutes les ressources lorsqu’ils chargent le Centre de ressources. Pour sa part, un responsable de projet ne peut voir que ses propres projets. Par conséquent, ces utilisateurs sont sujets à une diminution des performances perçues. Dans la mesure du possible, limitez le nombre de projets, de tâches ou de ressources présentés dans un affichage donné en définissant des filtres appropriés dans les affichages au moyen de l’option Paramètres du serveur>Gérer les affichages.
Répartition globale des utilisateurs
Problèmes, risques et livrables : un nombre élevé de ces entités risque d’accroître la charge sur votre serveur SQL Server. C’est notamment le fait d’afficher ces entités et d’interagir avec elles dans le site Projet qui peut engendrer la charge supplémentaire. Si vous utilisez ces fonctionnalités intensément, vous pouvez allouer des ressources supplémentaires à votre déploiement de SQL Server pour maintenir un niveau de performances élevé. Étant donné que ces artefacts et les fonctionnalités de site Projet sont des sites et des listes SharePoint, consultez la documentation relative à la mise à l’échelle des sites et listes SharePoint.
Calendriers : des calendriers personnalisés peuvent être définis pour les projets, les tâches et les ressources. Cela a une incidence significative sur le moteur de planification, du fait d’une utilisation plus élevée des processeurs sur les serveurs d’applications et de bases de données.
Jeux de données typiques
Les jeux de données décrits dans cette section dépendent des variables répertoriées et expliquées dans le tableau ci-après. Il est possible que ces variables ne capturent pas tous les facteurs qui ont une incidence sur les performances de Project Server (c’est-à-dire la combinaison de fonctionnalités que vous avez tendance à utiliser dans votre déploiement). Toutefois, elles capturent la plupart des informations significatives pour la détermination de la capacité appropriée.
| Entité | Description/remarques | Petite taille | Taille moyenne | Grande taille | |
|---|---|---|---|---|---|
1 |
Projets |
100 |
5 000 |
20 000 |
|
1 |
Tâches |
17 125 |
856 250 |
3 425 000 |
|
1 |
Nombre moyen de tâches par projet |
171,25 |
171,25 |
171,25 |
|
2 |
Historique des transactions des tâches |
Nombre de fois que l’état tend à être envoyé et approuvé pour une tâche donnée |
10 |
100 |
1 000 |
1 |
Affectations |
22 263 |
1 113 125 |
4 500 000 |
|
1 |
Nombre moyen d’affectations par tâche |
1,3 |
1,3 |
1,3 |
|
2/3 |
Approbations |
Mises à jour en attente par responsable |
50 |
600 |
3 000 |
Utilisateurs |
1 000 |
10 000 |
50 000 |
||
Champs personnalisés |
Projet (formule) |
3 |
20 |
25 |
|
Champs personnalisés |
Projet (manuel) |
2 |
40 |
50 |
|
Champs personnalisés |
Tâche (formule) |
Les champs de formule de tâche ont tendance à affecter le plus les performances, car ils doivent être calculés pour chaque tâche. |
6 |
12 |
15 |
Champs personnalisés |
Tâche (manuel) |
4 |
8 |
10 |
|
Champs personnalisés |
Généralisation des affectations |
50 % |
50 % |
50 % |
|
Champs personnalisés |
Ressource |
10 |
20 |
25 |
|
Champs personnalisés |
Champs personnalisés de table de choix |
2 |
15 |
100 |
|
1 |
Feuilles de temps (par an) |
Plus vous utilisez des feuilles de temps, plus les ressources du serveur SQL Server sont sollicitées. |
52 000 |
780 000 |
8 320 000 |
1 |
Lignes de feuille de temps |
5 |
10 |
10 |
Recommandations relatives au matériel
Les sections suivantes fournissent des recommandations générales sur les performances et sur la capacité. Utilisez ces recommandations pour identifier une topologie de départ convenable et pour déterminer si vous devez la soumettre à une montée en puissance parallèle ou à une montée en puissance par unité.
Tout au long de cet article, nous faisons référence aux trois différents rôles configurés dans Windows Server : le rôle Serveur Web frontal, le rôle Serveur d’applications et le rôle Serveur de bases de données (SQL). Ce sont tous des composants d’un déploiement Project Server 2010 complet. Les serveurs Web frontaux font office d’interface pour les utilisateurs qui accèdent à Project Server. Le serveur d’applications gère les demandes destinées à la couche données de Project Server et implémente la logique métier de Project Server 2010. Enfin, la couche base de données est la source de données, qui abrite les bases de données Project Server 2010. Dans le cas des déploiements de petite taille, les rôles Serveur Web frontal, Serveur d’applications et Serveur de bases de données peuvent être combinés sur le même ordinateur physique. Dans les cas des déploiements de plus grande taille, il peut s’avérer nécessaire de les répartir sur différents ordinateurs, voire d’utiliser plusieurs ordinateurs physiques pour un même rôle.
Recommandations matérielles pour les jeux de données de petite taille
Cette section suggère une topologie recommandée pour chacune des tailles de jeu de données (petite, moyenne et grande) détaillées plus haut dans la section « Jeux de données typiques ». Les topologies recommandées pour chaque jeu de données doivent permettre d’obtenir des performances acceptables avec la plupart des modèles d’utilisation sur les jeux de données de ces tailles. Toutefois, nous vous encourageons à prendre en compte les recommandations spécifiques fournies tout au long du reste de cet article pour déterminer si vous devez aller au-delà de la topologie recommandée pour le jeu de données le plus proche du vôtre. En règle générale, vous devez surveiller les métriques de performance de votre topologie et adapter celle-ci en conséquence si vous n’êtes pas satisfait des caractéristiques des performances.
Étant donné que Project Server 2010 coexiste avec SharePoint Server 2010, il utilise des ressources supplémentaires (processeur, RAM et disque dur). Les contraintes de référence pour SharePoint Server 2010 sont également valables pour une installation Project Server 2010 avec un petit jeu de données et une utilisation faible. Toutefois, pour les jeux de données et les modèles d’utilisation plus conséquents, des ressources matérielles supplémentaires sont requises. Dans le cadre d’un déploiement sur un ordinateur autonome, avec un petit jeu de données, il est recommandé de prévoir 16 Go de RAM afin d’assurer un niveau élevé de performances perçues. Au-delà, si possible, il est recommandé de séparer le serveur de bases de données des couches Serveur d’applications et serveur Web frontal en plaçant vos bases de données sur un ordinateur dédié exécutant SQL Server.
Le tableau suivant répertorie les spécifications pour un serveur unique avec installations de base de données intégrée et les installations de batterie de serveurs comportant un ou plusieurs serveurs.
Serveur Web frontal/d’applications
| Composant | Configuration recommandée |
|---|---|
Processeur |
64 bits, quatre cœurs, 2,5 gigahertz (GHz) minimum par cœur |
RAM |
4 Go pour une utilisation à des fins d’évaluation ou de développement, 8 Go pour une installation de serveur unique ou de batterie de serveurs en vue d’une utilisation en mode production |
Disque dur |
80 Go |
SQL Server
| Composant | Configuration recommandée |
|---|---|
Processeur |
64 bits, quatre cœurs, 2,5 GHz minimum par cœur. (Si la taille du jeu de données est beaucoup élevée que la taille moyenne des jeux de données, il est recommandé d’utiliser huit cœurs.) |
RAM |
4 Go pour une utilisation à des fins d’évaluation ou de développement, 8 Go pour une installation de serveur unique ou de batterie de serveurs en vue d’une utilisation en mode production |
Disque dur |
80 Go |
Recommandations matérielles pour les jeux de données de taille moyenne
La configuration minimale requise spécifiée pour les jeux de taille moyenne peut subir une montée en puissance parallèle et une montée en puissance par unité pour gérer une charge supplémentaire. Les topologies avec montée en puissance par unité et montée en puissance parallèle traitent des modalités de gestion d’un accroissement des charges utilisateur et de données.
En règle générale, pour faire face à une charge utilisateur et à une charge de données supplémentaires, vous devez disposer de suffisamment d’ordinateurs afin d’ajouter des serveurs Web frontaux et des serveurs d’applications à votre topologie. Les spécifications matérielles de vos serveurs Web frontaux et serveurs d’applications peuvent demeurer largement les mêmes. Une topologie 4 × 2 × 1 doit être suffisante dans la plupart des jeux de données de taille moyenne et des modèles d’utilisation. L’application d’une montée en puissance parallèle à vos serveurs d’applications et serveurs Web frontaux fait peser sur votre déploiement de SQL Server une charge supplémentaire, que vous devez compenser en ajoutant des ressources mémoire et processeur. La spécification SQL Server suivante doit être en mesure de gérer les besoins en termes de performances de la plupart des jeux de données de taille moyenne. La meilleure façon de déterminer si la topologie que vous avez conçue répond à ces besoins consiste à configurer un environnement intermédiaire pour tester votre topologie et surveiller les caractéristiques des performances.
Serveur Web frontal
| Composant | Configuration recommandée |
|---|---|
Processeur |
64 bits, quatre cœurs, 2,5 GHz minimum par cœur |
RAM |
4 Go pour une utilisation à des fins d’évaluation ou de développement, 8 Go pour une installation de serveur unique ou de batterie de serveurs en vue d’une utilisation en mode production |
Disque dur |
80 Go |
Serveur d’applications
| Composant | Configuration recommandée |
|---|---|
Processeur |
64 bits, quatre cœurs, 2,5 GHz minimum par cœur |
RAM |
4 Go pour une utilisation à des fins d’évaluation ou de développement, 8 Go pour une installation de serveur unique ou de batterie de serveurs en vue d’une utilisation en mode production |
Disque dur |
80 Go |
SQL Server
| Composant | Configuration recommandée |
|---|---|
Processeur |
64 bits, huit cœurs, 2,5 GHz minimum par cœur. (Si la taille du jeu de données est beaucoup élevée que la taille moyenne des jeux de données, il est recommandé d’utiliser huit cœurs.) |
RAM |
32 Go |
Disque dur |
160 Go |
Recommandations matérielles pour les jeux de données de grande taille
Pour les jeux de données de grande taille, la charge de données constitue le goulot d’étranglement de performances le plus important.
En règle générale, pour les jeux de données de grande taille, il convient de prévoir au minimum une topologie 4 × 2 × 1. Les caractéristiques matérielles des serveurs Web frontaux et des serveurs d’applications peuvent généralement demeurer identiques à celles recommandées pour les jeux de données de tailles petite et moyenne. Toutefois, étant que l’installation SQL Server constituera le goulot d’étranglement, votre possibilité d’appliquer une montée en puissance parallèle en ajoutant des serveurs Web frontaux et des serveurs d’applications pourra vous sembler limitée. Si vous constatez que la charge de données constitue le goulot d’étranglement, l’ajout de serveurs Web frontaux et de serveurs d’applications peut s’avérer inefficace pour améliorer le débit.
Pour les jeux de données de grande taille, si l’instance de SharePoint Server 2010 avec laquelle coexiste Project Server 2010 connaît également une utilisation intensive (auquel cas vous n’utilisez pas ce déploiement SharePoint Server 2010 spécifiquement pour les fonctionnalités Project Server 2010), il est recommandé de séparer les quatre bases de données Project Server 2010 des bases de données de contenu SharePoint Server 2010, en les plaçant sur leur propre instance de SQL Server dédiée.
Étant donné que le débit de données constituera le goulot d’étranglement, vous devez investir dans des ressources supplémentaires sur la couche SQL Server de votre topologie. Vous pouvez appliquer une montée en puissance par unité à votre installation de SQL Server en ajoutant des ressources en termes de RAM, de processeur et de disque dur. Les sections suivantes répertorient les spécifications minimale et recommandée pour la couche SQL Server d’une topologie de jeu de données de grande taille.
Configuration minimale requise pour SQL Server
| Composant | Configuration recommandée |
|---|---|
Processeur |
64 bits, huit cœurs, 2,5 GHz minimum par cœur. (Si la taille du jeu de données est beaucoup élevée que la taille moyenne des jeux de données, il est recommandé d’utiliser huit cœurs.) |
RAM |
32 Go |
Disque dur |
250 Go |
Configuration minimale recommandée pour SQL Server
| Composant | Configuration recommandée |
|---|---|
Processeur |
64 bits, huit cœurs, 2,5 GHz minimum par cœur. (Si la taille du jeu de données est beaucoup élevée que la taille moyenne des jeux de données, il est recommandé d’utiliser huit cœurs.) |
RAM |
64 Go |
Disque dur |
300 Go ou plus. Placez votre base de données de création de rapports sur un serveur de bases de données distinct. Dans l’idéal, vous devez séparer et hiérarchiser les données sur différents disques. Placez les fichiers de données et vos journaux des transactions SQL Server 2008 sur des disques durs physiques distincts. RAID 5 doit offrir un bon compromis entre fiabilité et débit. |
Recommandations pour la virtualisation
Project Server 2010 peut être exécuté sur des ordinateurs virtualisés. La plupart des conseils donnés pour la virtualisation de SharePoint Server 2010 concernent également Project Server 2010. Pour de la documentation sur la virtualisation dans SharePoint Server 2010, voir Planification de la virtualisation (SharePoint Server 2010). Pour plus d’informations sur la virtualisation et Project Server 2010, vous pouvez également vous reporter au guide de virtualisation de Project Server 2007, car la majeure partie de l’aide qu’il contient est toujours valide. Toutefois, comme dans toute situation où la virtualisation est utilisée, il est important d’envisager la possibilité d’un conflit autour des ressources d’un ordinateur physique entre les ordinateurs virtualisés en cours d’exécution sur la même instance physique.
Notes
Il est déconseillé d’exécuter SQL Server sur un ordinateur virtualisé. La compétition pour des ressources sur un ordinateur virtualisé peut diminuer sensiblement les performances du serveur. Si vous devez exécuter SQL Server dans un environnement virtualisé, pensez à utiliser les paramètres suivants :
-
Carte réseau :
-
Si vous utilisez la virtualisation Hyper-V, vous devez recourir à la carte réseau virtuelle plutôt qu’à la carte réseau héritée.
-
-
Disque virtuel :
-
Pour l’ordinateur virtuel sur lequel SQL Server est en cours d’exécution, il est recommandé de sélectionner l’option « pass-through » comme type de disque (plutôt que dynamique ou fixe). Si cela n’est pas possible, vous devez utiliser un disque de taille fixe plutôt qu’un disque virtuel dimensionné dynamiquement.
-
Il est recommandé de sélectionner IDE au lieu de SCSI comme lecteur de démarrage.
-
Allouez suffisamment d’espace disque dur pour gérer la taille maximale attendue de votre jeu de données et les exigences liées à journalisation du service ULS.
-
-
Mémoire :
-
Vous devez allouer autant de mémoire que possible à l’ordinateur virtuel qui exécute SQL Server. Cette quantité de mémoire doit être comparable à la quantité de mémoire requise/recommandée pour les serveurs physiques ayant la même fonction.
-
Vous devez réserver au moins 2 Go de mémoire au système d’exploitation hôte.
-
L’exécution des serveurs Web frontaux ou des serveurs d’applications dans des environnements virtualisés tend à ne pas être aussi préjudiciable que l’exécution de SQL Server dans un environnement virtualisé.
Configuration requise pour le réseau
Pour la plupart des déploiements Project Server, la bande passante réseau tend à ne pas être le goulot d’étranglement des performances. Le tableau ci-après répertorie les spécifications recommandées des composants réseau. Un objectif général doit être de maintenir une latence faible entre les couches Application et SQL Server.
| Composant | Jeux de données de tailles petite et moyenne | Jeu de données de grande taille |
|---|---|---|
Nombre de cartes réseau |
1 |
2 |
Vitesse des cartes réseau |
Toute vitesse supérieure à 100 mb/s doit convenir. |
1 Gb/s |
Type d’équilibrage de la charge |
Équilibrage de la charge réseau ou matériel (les deux sont possibles) |
Équilibrage de la charge réseau ou matériel (les deux sont possibles) |