Cette annexe fournit des lignes directrices qui facilitent la sélection du matériel approprié pour le cadre de gestion de base de Sun Management Center et les produits supplémentaires. Le cadre de gestion de base de Sun Management Center et chaque produit supplémentaire exigent un espace disque spécifique pour les couches agent, serveur et console du logiciel Sun Management Center de base.
Ce chapitre présente les rubriques suivantes :
Serveur de Sun Management Center plus Supplément Performance Reporting Manager ;
Ressources requises par les agents de plate-forme/proxy Sun Fire.
Les informations fournies dans cette section ne tiennent pas compte des éventuels modules d'autres sociétés, modules qui ne sont par ailleurs pris en compte dans aucun chiffre d'évaluation.
Les agents de Sun Management Center 3.5 doivent être installés sur chaque nud géré de votre réseau pour activer les fonctions de gestion et de surveillance avancées. Les agents de Sun Management Center sont pris en charge sur l'ensemble des stations de travail et des serveurs à plate-forme SPARC qui exécutent Solaris version 2.6, Solaris version 7, Solaris version 8 ou Solaris version 9. Les agents de Sun Management Center ne sont pas disponibles pour les systèmes dotés de l'environnement d'exploitation Solaris (x86 Platform Edition) ni pour les systèmes Microsoft Windows.
La charge de calcul ajoutée au système hôte par les agents de Sun Management Center est minimale. Elle est due aux opérations de gestion normales telles que l'acquisition périodique de données, le traitement des règles d'alarme, l'annonce des alarmes, l'exécution des actions en cas d'alarme et le traitement des requêtes émanant des clients.
Le volume de cette charge est proportionnel à la fréquence à laquelle les données sont recueillies, à la quantité de données recueillies, au nombre d'alarmes détectées et au nombre de requêtes des utilisateurs. Le pourcentage de ressources UC consommées dépend par conséquent du nombre et du type des modules chargés sur le système, de leur configuration et de la capacité de calcul du système hôte.
Même sur les machines d'entrée de gamme sur lesquelles une suite complète de modules est chargée et qui présentent une activité de gestion élevée, un agent ne devrait en aucun cas consommer plus d'une fraction des ressources UC.
Le tableau suivant donne une estimation de l'utilisation de l'UC et de la RAM.
Tableau C–1 Utilisation estimée de l'UC et de la RAM par agent par type de système
Type de serveur |
Configuration |
Utilisation de l'UC |
Utilisation de la RAM (moyenne) |
|||
---|---|---|---|---|---|---|
Maxi ou mini |
Maximum |
Minimum |
Moyenne |
Taille |
Taille résidante |
|
Netra X1 |
Mini |
16,3% |
0,0% |
0,09% |
12 Mo |
10 Mo |
Sun Enterprise 420R |
Mini |
14,3% |
0,0% |
0,13% |
15 Mo |
14 Mo |
Sun Blade 1000 |
Mini |
0,3% |
0,0% |
0,03% |
17 Mo |
16 Mo |
Sun Blade 100 |
Maxi |
14,0% |
0,2% |
8,9% |
29 Mo |
29 Mo |
Les configurations dites « mini » (light) se composent d'un agent avec les modules suivants installés :
Lecteur de noyau simple ;
Statistiques agent ;
MIB-II simple.
Les configurations dites « maxi » (heavy) se composent d'un agent avec les modules suivants installés :
Il est probable que les configurations maxi soient supérieures aux besoins. Les plus grandes machines présentent en général des configurations matérielles plus importantes comportant davantage de processeurs et de disques. Ces configurations se traduisent par une consommation de mémoire plus élevée de la part des agents qui sont exécutés sur ces machines.
La mémoire virtuelle utilisée par un agent dépend de plusieurs facteurs. Les premiers points à prendre en compte sont le nombre des modules de gestion chargés et la quantité des informations surveillées par ces modules. Charger de nombreux modules sur un agent augmente la mémoire requise. De façon similaire, les agents qui gèrent des hôtes présentant de grandes piles de disques ou d'autres éléments hautement évolutifs requerront probablement davantage de mémoire virtuelle puisque le volume des informations de gestion transférées par le biais des agents augmentera.
En général, un agent de base sur lequel l'ensemble par défaut des modules de gestion est chargé est en dessous de 10 Mo en taille. Avec un agent de base, seuls 50% à 60% des 10 Mo doivent résider dans la mémoire physique.
La majorité des modules de gestion de Sun Management Center peuvent être utilisés avec tous les systèmes à plate-forme SPARC qui exécutent les agents de Sun Management Center. Certains modules avancés de Sun Management Center toutefois sont spécifiques d'un matériel donné et ne sont pas pris en charge sur tout le matériel Sun. Plus précisément, les modules Lecteur de configuration et Reconfiguration dynamique spécifiques d'une plate-forme donnée fournissent une gestion de plate-forme avancée adaptée à la plate-forme matérielle en question. Les fonctions assurées par ces modules ne s'appliquent pas nécessairement à tous les systèmes matériels de la gamme de produits Sun.
Le tableau suivant fait le point sur la disponibilité des modules de gestion de Sun Management Center sur les différentes plates-formes matérielles.
Tableau C–2 Disponibilité des modules en fonction du matériel
Matériel |
Module Lecteur de configuration |
Module Reconfiguration dynamique |
Autres modules de Sun Management Center |
---|---|---|---|
SPARCStation 1, 2, 5, 10, 20 |
Non |
Non |
Oui |
Sun Ultra 1, 2, 5, 10, 30, 60, 80 |
Oui |
Non |
Oui |
Sun Enterprise 5, 10, 150, 250, 450, 220R, 420R, Sun Fire 280R, Sun Fire V480 |
Oui |
Non |
Oui |
SPARCserver 1000, 1000E |
Oui |
Non |
Oui |
SPARCcenter 2000, 2000E |
Oui |
Non |
Oui |
Sun Enterprise 3x00, 4x00, 5x00, 6x000 |
Oui |
Oui |
Oui |
Sun Enterprise 10000 |
Oui |
Non |
Oui |
Sun StorEdge A5x00, T3 |
Oui |
Non |
Oui |
Netra T1, T1120-1125, T1400-T1405 |
Oui |
Non |
Oui |
Sun Blade 100, 1000 |
Oui |
Non |
Oui |
Sun Fire, 3800, 4800, 4810, 6800, V880 |
Oui |
Oui |
Oui |
Les ressources requises par les modules de gestion dépendent des facteurs suivants :
Le nombre des propriétés gérées dans le module.
Le volume des données de propriétés gérées traitées dans le module. Les tables qui comptent de nombreuses lignes de données utilisent davantage de ressources.
Les intervalles de rafraîchissement des propriétés gérées.
La complexité de la collecte des données et du traitement des règles.
Le tableau suivant résume l'impact sur les ressources des modules de gestion de Sun Management Center.
Tableau C–3 Résumé de l'impact des modules de gestion de Sun Management Center sur le système
La couche serveur est le cur du logiciel Sun Management Center. Bien cerner le matériel approprié pour l'hôte de la couche serveur est capital pour 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.5 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.5.
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.5 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 serveur de Sun Management Center. Dans chaque cas, d'autres configurations peuvent 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 d'UC |
RAM |
Zone de swap |
---|---|---|---|---|
Petit serveur |
Netra X1, Netra T1, Sun Blade 100 ou équivalent |
Une UC UltraSPARC IIe à 502 MHz ou mieux |
1 Go |
512 Mo minimum, 1 Go recommandé |
Serveur moyen |
Sun Enterprise 80 ou équivalent |
Deux UC UltraSPARC II à 450 MHz ou mieux |
1 Go |
512 Mo minimum, 1 Go recommandé |
Grand serveur |
Sun Fire 280R, Netra T4 ou Sun Blade 1000 |
Deux UC UltraSPARC III à 750 MHz ou mieux |
1 Go |
512 Mo minimum, 1 Go recommandé |
Très grand serveur |
Sun Fire 480R ou équivalent |
Quatre UC UltraSPARC III à 900 MHz ou mieux |
2 Go |
1 Go |
Les exigences d'évaluation de la configuration de l'hôte du serveur de Sun Management sont étroitement liées 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 système et le diagnostic.
Compte tenu de l'impact des activités de gestion, l'estimation dépend du nombre, du type et de la configuration de tous les modules de suppléments de Sun Management Center qui sont installés sur le serveur, et du nombre de nuds gérés. De manière générale, plus les suppléments utilisés sont nombreux, plus l'ampleur des activités de gestion et la configuration matérielle requise par le serveur augmentent.
Le graphe ci-après illustre les catégories de machines recommandées pour le serveur de Sun Management Center en fonction du nombre des agents gérés et de l'activité de gestion estimée. On suppose dans le schéma que les consoles de Sun Management Center ne sont pas exécutées sur la machine serveur. On y suppose aussi qu'il y a cinq sessions de console à distance pour le petit serveur ; dix pour le serveur moyen ; et quinze pour les serveurs grand et très grand.
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 affectée de façon négative 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'estimation relative à l'hôte du serveur pour la prise en charge des composants de la couche serveur n'est pas large, n'exécutez pas les consoles de Sun Management Center sur la machine serveur.
Le supplément Performance Reporting Manager (PRM) de Sun Management Center est utilisé 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. Le supplément 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 de données importants.
L'impact du supplément PRM est illustré dans le segment PRM de la Figure 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.
Déterminer la configuration requise pour un serveur de Sun Management Center doté du supplément PRM se fait 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 le supplément PRM, reportez-vous au segment PRM de 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 fait référence à l'architecture des machines listée dans Tableau C–4.
Tableau C–5 Types de configurations PRM
Type de configuration PRM |
Espace disque |
Nombre total de propriétés PRM |
Nombre d'agents de l'exemple |
Nombre de propriétés par agent de l'exemple |
Architecture |
---|---|---|---|---|---|
Mini PRM |
5 Go |
50 000 |
100 |
300 |
Mini |
|
|
|
400 |
100 |
Moyenne |
PRM moyen |
2 Go |
150 000 |
300 |
300 |
Moyenne |
|
|
|
500 |
300 |
Grande |
|
|
|
750 |
200 |
Très grande |
Très grand PRM |
24 Go |
240 000 |
600 |
300 |
Grande |
|
|
|
750 |
300 |
Très grande |
Les petits serveurs 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 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 |
Type de configuration PRM |
Collecte de données par heure |
Traitement nocturne |
---|---|---|---|---|---|
Petite |
100 |
30 000 |
Mini |
2 minutes |
1 à 2 heures |
Moyenne |
300 |
90 000 |
Moyenne |
7 minutes |
3 à 4 heures |
Grande |
600 |
180 000 |
Maxi |
7 minutes |
3 à 6 heures |
Très grande |
750 |
225 000 |
Maxi |
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 quatre heures à un mois.
La génération des rapports typiques 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 le supplément Performance Reporting Manager, un rapport relativement simple qui inclut cinq 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 cinq propriétés pour cinq agents au cours des sept derniers jours peut prendre jusqu'à dix minutes.
Un exemple de serveur Sun Management Center moyen doté du supplément Performance Reporting Manager est un Ultra-80 avec deux UC UltraSPARC II à 450 MHz, 1 Go de RAM et 1 Go de swap. On assume que cet Ultra-80 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. Programmer des rapports importants 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 le risque de conflit avec les tâches de nuit de Sun Management Center et de Performance Reporting Manager qui se déroulent en général entre 24h00 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 de personnes utilisant la console.
Le 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 de groupes topologiques dans un contexte serveur Sun Management Center ne doit pas excéder ce qui suit :
Petits serveurs - 25 groupes topologiques
Serveurs moyens - 50 groupes topologiques
Grands serveurs - 75 groupes topologiques
Très grands serveurs - 100 groupes 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 le supplément 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 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 des nuds gérés à générer des activités de gestion sous la forme de traitement d'événements.
Par conséquence, des activités de gestion importantes peuvent survenir sans suppléments 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 de sessions d'utilisateur de console Sun Management Center concurrentes engendre une augmentation modeste de la charge sur la couche serveur. Pour estimer les ressources requises, il faut prendre en compte cinq utilisateurs actifs pour une petite configuration, dix pour une configuration moyenne et quinze pour une grande ou une très grande configuration. Toujours à des fins d'évaluation, on assume 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.
Les opérations de groupe importantes 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 celles de grande ampleur et, dans la mesure du possible, en effectuant ou en programmant ces opérations en dehors des heures de pointe.
Pour une performance optimale, la console de Sun Management Center doit être exécutée depuis un hôte différent de celui de la couche serveur. La console peut d'emblée être installée sur tout hôte et utilisée pour se connecter à distance à la couche serveur. On assume dans les configurations recommandées pour la couche serveur que le système hôte est entièrement dédié à la seule exécution des applications de la couche serveur. Exécuter d'autres applications telles que la console de Sun Management Center sur l'hôte de la couche serveur doit être évité à moins que la configuration de l'hôte du serveur n'ait été estimée largement de façon à laisser une marge suffisante.
La console de Sun Management Center repose sur la technologie Java. La console est prise en charge sur les systèmes à plate-forme SPARC qui exécutent l'environnement d'exploitation Solaris 2.6, Solaris 7, Solaris 8 ou Solaris 9. La console est également prise en charge sur les systèmes Intel qui exécutent Microsoft Windows 2000 ou Microsoft Windows NT 4.0 avec le Service Pack 3 ou 4, ou Windows 98.
Les agents de plate-forme Sun Fire requièrent une procédure d'installation différente de celle employée pour les agents standard de Sun Management Center. Les plates-formes Sun Fire contiennent un certain nombre de domaines, chaque domaine se voyant allouer un matériel propre. Chaque domaine exécute une instance séparée de l'environnement d'exploitation Solaris. Chacun des domaines Sun Fire exécute un agent de domaine.
La plate-forme Sun Fire dans son ensemble se compose de l'ensemble du matériel de plate-forme alloué aux différents domaines. Cette plate-forme est contrôlée par une carte de contrôleur système (SC, System Controller) au sein de la plate-forme.
Pour gérer les serveurs Sun Fire, le logiciel Sun Management Center utilise les agents de plate-forme Sun Fire qui interagissent avec le contrôleur système du serveur Sun Fire et les agents de domaine Sun Fire. Les agents de plate-forme doivent être déployés sur un hôte Solaris externe au châssis Sun Fire que les agents doivent surveiller. Il est possible de déployer plusieurs agents de plate-forme sur un unique système hôte pour gérer plusieurs serveurs Sun Fire, du moment que la configuration du système hôte des agents de plate-forme a été évaluée de façon appropriée.
En moyenne, chaque agent de plate-forme consomme de 5% à 9% de l'UC et de 15 à 18 Mo de mémoire. Les consommations d'UC et de mémoire des agents de plate-forme déployés sur le même système hôte s'ajoutent et peuvent être utilisées pour estimer la configuration matérielle requise. L'espace disque requis pour plusieurs instances d'agent de plate-forme est de peu supérieur à celui requis pour une unique instance d'agent de plate-forme car les agents partagent les mêmes modules logiciels.
En général, les ressources UC et mémoire requises par un agent de plate-forme sont proportionnelles à la taille et à la complexité de la configuration du serveur Sun Fire qui est géré. Les systèmes Sun Fire présentant des configurations plus importantes requièrent davantage de ressources pour l'agent de plate-forme sur l'hôte de l'agent de plate-forme.
Vous pouvez installer les agents de plate-forme sur au choix :
un hôte comportant la couche serveur de Sun Management Center ;
un hôte d'agent de plate-forme de Sun Management Center dédié.
Le nombre des agents de plate-forme qui peuvent être installés sur un hôte donné varie en fonction de si cet hôte héberge la couche serveur ou la couche agent de plate-forme de Sun Management Center. Pour maximiser la performance globale et la capacité de réponse de Sun Management Center, les agents de plate-forme doivent être déployés sur des hôtes dédiés au lieu de l'être sur l'hôte de la couche serveur. Si la couche serveur est déployée sur un système à plusieurs UC de capacité excessive, vous pouvez envisager d'exécuter les agents de plate-forme sur cet hôte.
La figure ci-après représente l'architecture d'un déploiement sur un hôte d'agent de plate-forme dédié et celle d'un déploiement sur l'hôte de la couche serveur.
Les agents de plate-forme Sun Fire rafraîchissent par défaut leurs informations de gestion toutes les heures. Quand plusieurs agents de plate-forme sont déployés sur le même hôte et initialisés en même temps, ils ont tendance à effectuer leurs rafraîchissements de données en succession rapide. Si de trop nombreux agents de plate-forme essayent de rafraîchir simultanément leurs données, la capacité de réponse globale du système hôte peut être affectée de façon négative.
Pour réduire la probabilité que des opérations concurrentes soient lancées par plusieurs agents de plate-forme sur le même hôte, ne démarrez pas tous les agents de plate-forme en même temps.
Le tableau suivant liste les configurations matérielle types et le nombre correspondant d'agents de plate-forme qui peuvent être déployés sur le système hôte dédié.
Tableau C–7 Hôte dédié : capacité en agents de plate-forme Sun Fire
Configurations matérielles représentatives |
Nombre maximum d'agents de plate-forme |
---|---|
Un Netra X1, un Netra T1 ou un Sun Blade 100 avec une UC UltraSPARC IIe à 500 MHz, 1 Go de RAM et 1 Go de swap |
5 à 7 |
Un Sun Enterprise 420R ou un Ultra 60 avec deux UC UltraSPARC II à 450 MHz, 1 Go de RAM et 1 Go de swap |
11à 15 |
Un Sun Fire 280R, un Netra T4 ou un Sun Blade 1000 avec deux UC UltraSPARC III à 750 MHz, 1 Go de RAM et 1 Go de swap |
14 à 20 |
Etant donné que l'utilisation des ressources par les agents de plate-forme peut varier, les limites indiquées dans le tableau représentent une plage de valeurs acceptable qui laisse une capacité suffisante pour assurer que les pointes d'activité n'excèdent pas la capacité du système. Les plates-formes Sun Fire plus grandes requièrent davantage de ressources pour l'agent de plate-forme et le résultat est qu'un nombre moindre d'agents de plate-forme peut être exécuté sur un hôte donné. Inversement, les plates-formes Sun Fire plus petites requièrent moins de ressources pour l'agent de plate-forme et il est donc possible d'exécuter davantage d'agents de plate-forme sur un unique hôte.
La configuration matérielle que doit présenter un système hôte exécutant la couche serveur de Sun Management Center est fonction du nombre d'agents de plate-forme gérés par la couche serveur et des activités de gestion du système.
Seuls les grands systèmes à plusieurs UC doivent être pris en considération pour exécuter à la fois la couche serveur de Sun Management Center et les agents de plate-forme Sun Fire. Le déploiement d'agents de plate-forme sur un hôte hébergeant la couche serveur de capacité limitée peut influer négativement sur la performance globale de Sun Management Center.
En supposant un niveau d'activités de gestion modéré de moins de 1000 événements par hôte et par jour, le nombre maximum d'agents de plate-forme qui peuvent être déployés sur un hôte hébergeant la couche serveur de Sun Management Center est fonction du nombre des agents gérés et de la catégorie de la machine. Le tableau suivant indique la capacité de systèmes typiques.
Tableau C–8 Hôte de la couche serveur : capacité en agents de plate-forme Sun Fire
Nombre des agents gérés |
Nombre maximum d'agents de plate-forme |
|
---|---|---|
Sun Enterprise 420R |
Sun Fire 280R |
|
100 |
6 |
7 |
300 |
5 |
7 |
500 |
4 |
6 |
750 |
NA |
6 |
Sun Enterprise 420R correspond à un hôte de couche serveur de type Enterprise 420R ou Ultra 60 à deux UC UltraSPARC-II à 450 MHz, avec 1 Go de RAM et 1 Go de swap.
Sun Fire 280R correspond à un hôte de couche serveur de type Sun Fire 280R, Sun Blade 1000 ou Netra T4 à deux UC UltraSPARC III à 750 MHz, avec 1 Go de RAM et 1 Go de swap.
Pour les procédures d'installation de Sun Management Center pour Sun Fire, reportez-vous au Sun Management Center 3.5 Supplément pour systèmes Sun Fire 6800/4810/4800/3800.