La couche serveur est le coeur du logiciel Sun Management Center. Il est capital de bien identifier le matériel approprié pour l'hôte de la couche serveur afin de garantir un fonctionnement fiable et adapté aux besoins de Sun Management Center. La configuration matérielle requise pour la couche serveur de Sun Management Center est considérablement supérieure à celle requise pour les agents. La configuration système requise par la couche serveur de Sun Management Center 3.6 est supérieure à celle requise pour les couches serveur de Sun Management Center 2. x et 3.0. Les hôtes du serveur de la version 2.x ou 3.0 ne présentent pas nécessairement la configuration minimale requise pour Sun Management Center 3.6.
La couche serveur de Sun Management Center est prise en charge sur les ordinateurs de bureau et les serveurs à plate-forme SPARC qui exécutent la version 8 ou la version 9 de Solaris, et présentent la configuration matérielle minimale requise décrite dans cette section.
Pour de meilleures performances, installez la couche serveur de Sun Management Center 3.6 sur une machine dédiée qui exécute uniquement les applications de la couche serveur.
Les systèmes matériels indiqués dans le tableau suivant représentent quatre grandes catégories de machines qui peuvent être employées en tant que plates-formes pour le Sun Management Center. Dans chaque cas, d'autres configurations pourraient fournir des performances équivalentes.
Tableau C–4 Plates-formes matérielles recommandées pour le serveur de Sun Management Center
Architecture |
Type de machine |
Type de CPU |
RAM |
Zone de swap |
---|---|---|---|---|
Petit serveur |
Sun Blade 100 ou équivalent |
Une CPU UltraSPARC IIe de 502 MHz ou plus |
1 Go |
512 minimum, 1 Go recommandé |
Serveur moyen |
Sun Fire 280R |
Deux CPU UltraSPARC II de 750 MHz ou plus |
1 Go |
512 minimum, 1 Go recommandé |
Grand serveur |
Sun Blade 2000 |
Deux CPU UltraSPARC III de1015 Mhz ou plus |
1 Go |
512 minimum, 1 Go recommandé |
Très grand serveur |
Sun Fire 880 |
Quatre CPU UltraSPARC III de 900 Mhz ou plus |
2 Go |
1 Go |
Le dimensionnement de l'hôte du serveur de Sun Management est étroitement lié au nombre des agents qui sont gérés par la couche serveur et aux activités de gestion sur ces mêmes agents. Les activités de gestion sont des activités générées par le système telles que la génération et le traitement des événements et les opérations lancées par l'utilisateur telles que l'exploration des données, la découverte du réseau, les opérations de groupe ainsi que la surveillance et le diagnostic du système.
Compte tenu de l'impact des activités de gestion, le dimensionnement dépend du nombre, du type et de la configuration de tous les packages add-ons de Sun Management Center qui sont installés sur le serveur, et du nombre de noeuds gérés. De manière générale, plus les add-ons utilisés sont nombreux, plus l'ampleur des activités de gestion et la configuration matérielle requise par le serveur augmentent.
Le schéma ci-dessous illustre les catégories de machines recommandées pour le serveur Sun Management Center en fonction du nombre des agents gérés et de l'activité de gestion estimée. Ce schéma suppose que les consoles de Sun Management Center ne sont pas exécutées sur la machine serveur. Il suppose aussi que 5 sessions de console à distance sont exécutées pour le petit serveur, 10 pour le serveur moyen et 15 pour les grand et très grand serveurs.
Les catégories de machines illustrées dans le schéma ci-dessus sont représentatives des catégories d'hôtes de performance similaire.
La performance du serveur est réduite par l'exécution de l'application console de Sun Management Center sur l'hôte de la couche serveur et par le nombre des sessions de console actives. Si l'hôte du serveur n'est pas généreusement dimensionné pour la prise en charge des composants de la couche serveur, n'exécutez pas les consoles de Sun Management Center sur la machine serveur.
L'add-on Performance Reporting Manager (PRM) de Sun Management Center est utilisée pour garder la trace des tendances et générer des rapports pour toute propriété de données surveillée par les agents de Sun Management Center. L'add-on PRM peut avoir un impact considérable sur la taille requise du serveur de Sun Management Center car il peut nécessiter la collecte et le traitement de volumes importants de données.
L'impact de l'add-on PRM est illustré dans le segment PRM de laFigure C–1. En général, l'augmentation des activités de gestion et du nombre total des propriétés de données suivies par PRM réduit le nombre des agents qui peuvent être gérés par le serveur de Sun Management Center.
La détermination de la configuration requise pour un serveur de Sun Management Center avec l'add-on PRM s'effectue en deux étapes.
En vous basant sur le nombre total des agents devant être gérés par le serveur de Sun Management Center avec l'add-on PRM, reportez-vous au segment de la Figure C–1 pour déterminer la catégorie de machines requise.
En fonction du nombre estimé de propriétés de données PRM que vous voulez collecter, déterminez la configuration PRM appropriée comme décrit dans la section suivante.
Pendant la configuration de Sun Management Center, vous avez la possibilité de sélectionner un des types de configurations PRM répertoriés dans le tableau suivant. La colonne Architecture renvoie à l'architecture des machines indiquées dans le Tableau C–4.
Tableau C–5 Types de configurations PRM
Types de configurations PRM |
Espace disque |
Nombre total de propriétés PRM |
Nombre d'agents dans l'exemple |
Nombre de propriétés par agent dans l'exemple |
Architecture |
---|---|---|---|---|---|
Mini PRM |
5 Go |
50 000 |
100 |
300 |
Mini |
|
|
|
400 |
100 |
Moyen |
PRM moyen |
12 Go |
150 000 |
300 |
300 |
Moyen |
|
|
|
500 |
300 |
Grand |
|
|
|
750 |
200 |
Très grand |
Grand PRM |
24 Go |
240 000 |
600 |
300 |
Grand(e) |
|
|
|
750 |
300 |
Très grand |
Les petits serveurs Sun Sun Management Center sont en général utilisés pour une mini configuration PRM ; les serveurs moyens pour une configuration PRM moyenne ; et les grands et très grands serveurs pour une configuration PRM maxi. Vous pouvez utiliser un très grand serveur Sun Sun Management Center avec une configuration PRM mini ou moyenne, selon l'espace disque disponible et les exigences de collecte de données PRM prévues.
Le tableau suivant contient des exemples du nombre d'agents qui peuvent être gérés par chaque type d'architecture, en supposant que chaque agent collecte une moyenne de 300 propriétés pour PRM. La colonne Collecte des données par heure indique la durée estimée de la collecte de données. La colonne Traitement nocturne indique la durée estimée du traitement des données collectées. La durée de la collecte des données et celle du traitement consécutif dépendent du matériel du serveur, de l'activité du serveur et de la quantité de données PRM présentes dans la base de données.
Tableau C–6 Exemples de serveurs : nombre d'agents gérés
Architecture |
Nombre d'agents |
Nombre total de propriétés PRM |
Types de configurations PRM |
Collecte de données par heure |
Traitement nocturne |
---|---|---|---|---|---|
Petite |
100 |
30 000 |
Petite |
2 minutes |
1à 2 heures |
Moyen |
300 |
90 000 |
Moyen |
7 minutes |
3 à 4 heures |
Grand |
600 |
180 000 |
Grand |
7 minutes |
3 à 6 heures |
Très grand |
750 |
225 000 |
Grand |
6 minutes |
3 à 6 heures |
Il est possible de générer un vaste éventail de rapports en spécifiant différents nombres d'agents, nombres de propriétés de données et durées de rapport de 4 heures à 1 mois.
La génération des rapports types prend de quelques secondes à plusieurs minutes. Le temps requis dépend des facteurs suivants :
Le nombre de points de données inclus dans le rapport.
Les rapports sont limités à un maximum de 10 000 points de données par rapport.
La quantité de données du gestionnaire de rapports de performance dans la base de données.
La performance et l'activité du serveur.
La génération en concomitance d'autres rapports du gestionnaire de rapports de performance.
Par exemple, sur un serveur Sun Management Center moyen configuré avec l'add-on Performance Reporting Manager, un rapport relativement simple qui inclut 5 propriétés pour un agent au cours des dernières 24 heures peut être généré en environ 20 secondes. Toujours à titre d'exemple, la génération d'un rapport plus complet incluant 5 propriétés pour 5 agents au cours des 7 derniers jours peut prendre jusqu'à 10 minutes.
Par serveur Sun Management Center moyen avec l'add-on Performance Reporting Manager on entend, dans cet exemple, un SunFire-280R avec deux CPU UltraSPARC II à 450 MHz, 1 Go de RAM et 1 Go de swap. On suppose également que le SunFire-280R surveille 300 agents et collecte 300 propriétés de données par agent pour Performance Reporting Manager.
Si la génération d'un rapport prend plus de 30 minutes, il est recommandé d'en programmer l'exécution entre 4h00 et 8h00 du matin. La programmation de grands rapports après 4h00 du matin réduit la charge sur le serveur de Sun Management Center pendant les heures de bureau, et peut également réduire les risques de conflit avec les tâches nocturnes de Sun Management Center et de Performance Reporting Manager qui se déroulent en général entre 00:00 et 4h00 du matin.
Les principaux facteurs qui affectent la performance de la couche serveur sont les suivants:
le démarrage simultané de composants de Sun Management Center ;
la configuration de groupes topologiques ;
les activités de gestion ;
le nombre d'utilisateurs de la console.
Démarrage simultané de la couche serveur et de nombreux agents peut avoir un effet négatif sur la performance de la couche serveur. L'initialisation d'une couche serveur gérant des centaines d'agents peut donner lieu à une réponse lente de la console et bloquer temporairement l'accès à certains agents.
Le nombre maximum de groupes topologiques dans un contexte serveur Sun Management Center ne doit pas dépasser :
Petits serveurs - 25 groupes topologiques
Serveurs moyens - 50 groupes topologiques
Grands serveurs - 75 groupes topologiques
Très grands serveurs - 100groupes topologiques
Le nombre maximum d'objets fils immédiats dans un groupe topologique est de 256. Pour une performance optimale, le nombre d'objets fils dans un groupe ne doit pas dépasser 100.
Si vous installez l'add-on Performance Reporting Manager, chaque domaine topologique doit contenir moins de 200 agents de Sun Management Center afin d'assurer une collecte optimale des données de Performance Reporting Manager.
L'activité du serveur de Sun Sun Management Center dépend des facteurs suivants :
Le nombre des opérations commencées par les utilisateurs.
La stabilité et l'activité des systèmes hôtes gérés.
Le nombre des modules de gestion chargés par les systèmes hôtes.
La spécification de seuils d'alarme et les paramètres des règles relatives aux propriétés gérées.
Ces deux derniers facteurs influencent considérablement la tendance qu'ont les noeuds gérés à générer des activités de gestion sous la forme de traitement d'événements.
Il en résulte que des activités de gestion importantes peuvent survenir sans add-ons si les seuils d'alarme sont mal configurés. Inversement, le niveau des activités de gestion peut rester bas même en présence de nombreux suppléments si les systèmes gérés sont stables et les seuils d'alarme raisonnables.
Augmenter le nombre des sessions d'utilisateur de console Sun Management Center concurrentes engendre une augmentation modeste de la charge sur la couche serveur. Pour l'estimation des ressources requises, on considère 5 utilisateurs actifs pour une petite configuration, 10 pour une configuration moyenne et 15 pour une grande ou une très grande configuration. Toujours à des fins d'évaluation, on suppose que les utilisateurs effectuent des opérations telles que parcourir les données des propriétés gérées et modifier des attributs de propriétés.
Certaines actions lancées par les utilisateurs peuvent affecter temporairement la performance de la couche serveur pendant la durée de l'opération.
Lesopérations de groupe importants qui ont pour cible 100 agents ou plus peuvent consommer des ressources serveur considérables. Ces opérations affecteront encore davantage la performance du serveur si les changements génèrent des alarmes sur les agents gérés. Les alarmes donnent lieu à des activités de gestion supplémentaires (traitement d'événements).
Les opérations de découverte du réseau impliquant l'ajout de nombreuses nouvelles entités devant être gérées par le serveur peuvent engendrer une charge considérable sur l'hôte de la couche serveur pendant le processus de découverte.
Les opérations d'importation de données topologiques impliquant l'ajout de nombreuses nouvelles entités à gérer peuvent donner lieu à une réponse plus lente de la couche serveur pendant la phase d'ajout des entités.
L'effet de ces actions lancées par l'utilisateur peut être minimisé en n'exécutant pas ces opérations simultanément, en subdivisant les opérations de grande envergure et, dans la mesure du possible, en effectuant ou en programmant ces opérations en dehors des heures de pointe.