Ce chapitre propose une aide au dimensionnement des serveurs Liunx suivant différents types d'utilisation. Il faut d'abord considérer que cet exercice est toujours périlleux. En effet, seule la réalité permet de mettre à l'épreuve de telles prévisions. Néanmoins, avec l'expérience des solutions déployées par le passé, on peut arriver à donner quelques règles utiles.
On peut appliquer un certain nombre de règles en vigueur pour le dimensionnement de serveurs Unix classique, en considérant que les systèmes CISC (majoritaires en environnement Linux) consomment environ 2,5 fois moins de ressources en mémoire que les systèmes RISC, étant donné que les binaires manipulés sont plus petits. Ceci influence aussi l'occupation disque. Il faut également tenir compte du fait que les plateformes Intel sont pour le moment des architectures 32 bits.
Il est évident qu'il faut, quel que soit le système, considérer les goulets d'étranglement de la solution mise en place, car ils détermineront le maillon le plus faible.
On prêtra une attention particulière au nombre et à la vitesse des disques (jusqu'à 15 Mo/s pour des disques 10.000tr/mn) ainsi qu'au nombre et à la vitesse des contrôleurs SCSI (jusqu'à 80 Mo/s pour les contrôleurs Ultra2 LVD du LH3), au fait de rajouter une carte SCSI prise en charge lors d'ajout de périphériques lents (DAT, DLT, graveur de CDs...) pour ne pas faire passer le contrôleur en mode compatible descsendant, et dégrader nettement les performances en entrées/sorties.
On se méfiera également du caractère extensible des machines. En effet, il est souvent préférable pour un client, de rajouter un serveur, plutôt que d'augmenter les capacités de celui en place. La raison en est d'ordre financier d'une part, le coût des ajouts se révelant, sur un système déjà ancien, proches de ceux d'un nouveau système dont les prix baissent continuellement. D'autre part, techniquement, il peut être plus intéressant de bénéficier des dernières technologies pour obtenir une machine plus équilibrée et plus performante. Par exemple, lors de l'introduction de l'Ultra2 LVD, il était plus intéressant de racheter un serveur pour bénéficier d'une vitesse de bus de 80 Mo/s, plutôt que de mettre à jour un serveur en Ultra Wide à 40 Mo/s. Ceci implique qu'il est intéressant de dimensionner correctement son serveur, dès le départ, pour toute la durée prévisible de son utilisation (typiquement 3 ans aujourd'hui).
Dans le même ordre d'idées, on examinera soigneusement le fait de conseiller une machine multi-processeurs au lieu de deux machines mono-processeur. 2 systèmes différents impliquent 2 contrôleurs disques, 2 séries de disques, 2 bus mémoires séparés, donc une meilleure performance mais une administration plus importante. En revanche, un seul système facilite cette tâche, permet une communication rapide entre processeurs, ce qui peut être nécessaire pour certaines applications, mais rend l'environnement plus fragile (potentiellement plus d'indisponibilité). D'autre part, il y a plus de pertes intrinsèquement sur un modèle multi-processeurs, en communications au niveau système. Cette question sera notamment à envisager dans le cas d'un ajout d'un processeur (obsolète par nature) sur une machine a posteriori, au lieu de l'ajout d'un serveur complet.
Sur les aspects mémoire, Linux ne peut gérer aujourd'hui plus de 2 Go (Cf ). En revanche, Linux tire partie de toute la mémoire qui lui est donnée, notamment dans la constitution d'un cache disque qui améliore considérablement les performances du système. On peut donc surdimensionner la quantité de mémoire installée, car ceci est préférable à une situation où le serveur serait obligé de paginer (ce qui pénalise énormément les performances). La taille minimale fournie sur les serveurs (64 Mo ou 128 Mo) correspond parfaitement à une utilisation normale d'un système et ne nécessite pas d'ajout particulier. (Il faut se souvenir qu'il n'y a pas utilisation d'environnement graphique sur les serveurs de production). Pour ce qui est de la mémoire de pagination (swap), sous Linux, elle vient en addition de la mémoire réelle pour donner la mémoire virtuelle totale dont dispose le serveur. Comme règle de base, il est conseillé de doter la machine d'autant de mémoire de pagination que de mémoire réelle. Il est à noter que Linux peut être amené à paginer certains processus inactifs pour libérer le maximum de mémoire vive possible. Avoir un système dont une partie du swap est occupé n'est donc pas nécessairement une preuve de manque de mémoire.
Vous trouverez ci-dessous des recommandations suivant le type d'utilisation faite du serveur HP Linux. Il est possible de cumuler plusieurs fonctions sur un même serveur. On prendra soin dans ce cas à additionner les ressources nécessaires pour remplir les services Ceci est encore incomplet et reste à affiner.
Ce type de serveur ne requiert pas d'attention particulière. Il faut savoir de combien d'espace disque l'on a besoin pour choisir le bon type de serveur (moins de 50 Go en 3 ans un E60 ou LC3 - plus de 50 Go sur 3 ans un LH3). Les ressources processeur consommées sont relativement faibles en général, un modèle d'entrée de gamme sera donc suffisant sur ce plan. On privilégiera plutôt une rapidité d'entrées/sorties avec de l'Ultra 2 LVD à 80 Mo/s, si le budget le permet (cela implique un LH3) et des disques 10.000 tr/mn. Il peut être utile d'ajouter des cartes réseau sur ce type de machine pour lisser le traffic, en fonction du nombre de clients. Côté mémoire, il faut considérer une consommation de 1 Mo par partage SMB. Typiquement un LH3 PIII 450MHz 256 Mo/2*9Go 10krpm peut servir sans soucis une centaine d'utilisateurs via SaMBa.