test

Guide d'installation et de configuration de Sun Management Center 4.0

Annexe C Détermination des ressources matérielles

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 add-ons. Le cadre de gestion de base de Sun Management Center et chaque add-on exigent un espace disque spécifique pour les couches agent, serveur et console du logiciel Sun Management Center de base.

Cette annexe aborde les sujets suivants :

Remarque –

Les informations fournies dans cette annexe ne tiennent pas compte des modules tiers éventuels et ces modules ne sont pas pris en compte dans les chiffres de dimensionnement.

Ressources requises par la couche agent

Les agents de Sun Management Center 4.0 doivent être installés chaque nœud géré de votre réseau pour activer les fonctions de gestion et de surveillance avancées. Les agents Sun Management Center sont pris en charge par toutes les stations de travail et tous les serveurs de plates-formes SPARC exécutant le système d'exploitation Solaris 8, Solaris 9 ou Solaris 10. Les agents Sun Management Center sont également disponibles pour les systèmes exécutant les versions 9 et 10 du système d'exploitation Solaris (Édition pour plate-forme x86) et sous Linux.

Limites des agents x86

Remarque –

Les agents Linux ont les mêmes limites.

Les agents x86 ne prennent pas en charge les add-ons spécifiques au matériel (sauf Config Reader x86). Les agents x86 ont des modules sous les catégories Système d'exploitation, Applications locales et Systèmes distants de l'onglet Explorateur modules de la fenêtre Détails de l'hôte. Des fonctionnalités telles que Vue physique, Vue logique, le module Hardware Diagnostic et le module Config-Reader ne sont pas encore disponibles sur la plate-forme Solaris x86.

Dans la fenêtre de la console Java, toutes les plates-formes x86 ont la même icône x86. Par exemple, une même icône indiquera deux machines x86 différentes, comme la Sun Cobat LX50 et la VX60.

Vous pouvez effectuer un filtrage par type de plate-forme quand vous utilisez la fonctionnalité Découverte, la fonctionnalité Gérer les travaux ou le supplément PRM. Vous pouvez effectuer le filtrage avec pour critère l'option de plate-forme x86.

En ce qui concerne le supplément PRM (Performance Reporting Manager), aucun rapport système ou de configuration matérielle n'est disponible.

Ressources CPU

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 des requêtes d'utilisateurs. Le pourcentage de ressources CPU 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 CPU.

Les mini-configurations se basent sur un agent avec les modules chargés suivants :

Le tableau suivant présente des estimations sur l'utilisation de la CPU et de la RAM d'un agent pour les modules légers.

Tableau C–1 Estimations de l'utilisation de la CPU et de la RAM de l'agent pour (les mini-modules) SPARC

Machine 

Mémoire (Mo) 

CPU (%) 

Mémoire résidente définie (Mo) 

Mémoire virtuelle (Mo) 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Petite 

0,4 

0,4 

0,4 

0,3 

0,3 

0,3 

7,46 

7,46 

7,46 

9,17 

9,17 

9,17 

Moyenne 

0,2 

0,2 

0,2 

< 0,1 

< 0,1 

< 0,1 

7,38 

7,43 

7,43 

9,12 

9,17 

9,17 

Grande 

0,1 

0,1 

0,1 

< 0,1 

< 0,1 

< 0,1 

7,62 

7,68 

7,68 

9,34 

9,40 

9,40 

Très grande 

0,1 

0,1 

0,1 

< 0,1 

< 0,1 

< 0,1 

7,82 

8,08 

8,12 

9,40 

9,59 

9,62 

CMT (T2000) 

0,1 

0,1 

0,1 

< 0,1 

< 0,1 

< 0,1 

8,44 

8,44 

8,44 

9,43 

9,43 

9,43 

Tableau C–2 Estimations de l'utilisation de la CPU et de la RAM de l'agent pour (les mini-modules) x86

Machine 

Mémoire (Mo) 

CPU (%) 

Mémoire résidente définie (Mo) 

Mémoire virtuelle (Mo) 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Petite 

0,6 

0,6 

0,6 

< 0,1 

< 0,1 

< 0,1 

6,10 

6,21 

6,22 

7,69 

7,76 

7,76 

Moyenne 

0,2 

0,2 

0,2 

< 0,1 

< 0,1 

< 0,1 

6,25 

6,25 

6,25 

7,80 

7,80 

7,80 

Grande 

0,2 

0,2 

0,2 

< 0,1 

< 0,1 

< 0,1 

6,19 

6,29 

6,29 

7,76 

7,82 

7,82 

Mmaxi-configurations se basent sur un agent avec les modules suivants chargés :

  • Statistiques des agents

  • Registre d'enregistrement de données

  • État de santé

  • Lecteur de noyau complet (complet)

  • Instrumentation MIB-II

  • Surveillance proxy MIB-II

  • Détails des processus Solaris

  • Config Reader

  • Surveillance de la taille des répertoires

  • Balayage des fichiers

  • Lanceur de scripts

  • Référentiel de scripts

  • Service Management Facility

Il est probable que les configurations maxi soient supérieures aux besoins. Les plus grosses 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.Les modules maxi peuvent comprendre divers modules personnalisés définis par l'utilisateur.

Les tableaux suivants donnent une estimation de l'utilisation de la CPU et de la RAM de l'agent par type de système pour les maxi-modules.

Tableau C–3 Estimations de l'utilisation de la CPU et de la RAM de l'agent pour (les modules maxi) SPARC

Machine 

Mémoire (Mo) 

CPU (%) 

Mémoire résidente définie (Mo) 

Mémoire virtuelle (Mo) 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Petite 

1,0 

1,0 

1,0 

1,2 

1,24 

1,4 

19,15 

19,15 

19,15 

21,68 

21,68 

21,68 

Moyenne 

0,5 

0,5 

0,6 

< 0,1 

0.66 

1,3 

20,93 

20,95 

20,96 

23,60 

23,61 

23,61 

Grande 

0,2 

0,2 

0,2 

0,1 

0,12 

0,2 

19,13 

19,16 

19,20 

21,88 

21,88 

21,88 

Très grande 

0,1 

0,1 

0,1 

0,1 

0,1 

0,1 

23,97 

23,99 

24,00 

26,38 

26,38 

26,38 

CMT (T2000) 

0,3 

0,35 

0,4 

0,1 

0,19 

0,3 

22,42 

24,41 

26,53 

23,69 

25,74 

27,79 

Tableau C–4 Estimations de l'utilisation de la CPU et de la RAM de l'agent pour (les modules maxi) x86

Machine 

Mémoire (Mo) 

CPU (%) 

Mémoire résidente définie (Mo) 

Mémoire virtuelle (Mo) 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Min. 

Moy. 

Max. 

Petite 

1,3 

1,4 

1,4 

0,1 

0,1 

0,1 

13,40 

13,76 

13,79 

16,60 

16,96 

17,00 

Moyenne 

0,4 

0,4 

0,4 

0,1 

0,2 

0,3 

14,25 

14,43 

14,45 

17,33 

17,50 

17,52 

Grande 

0,4 

0,4 

0,4 

< 0,1 

0,06 

0,1 

13,97 

14,81 

14,89 

17,00 

17,82 

17,90 

Mémoire virtuelle requise

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.

Disponibilité des modules en fonction du matériel

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 Config-Reader 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–5 Disponibilité des modules spécifiques au matériel

Matériel 

Module Config-Reader 

Module Reconfiguration dynamique  

Autres modules de Sun Management Center 

SPARCStation 1, 2, 5, 10, 20 

Non 

Non 

Oui 

Sun Ultra 1, 450 

Oui 

Non 

Oui 

Sun Enterprise 5, 10, 150, Sun Fire 280R, Sun Fire V480 

Oui 

Non 

Oui 

SPARCserver 1000, 1000E 

Oui 

Non 

Oui 

SPARCcenter 2000, 2000E 

Oui 

Non 

Oui 

Netra T1120-1125, T1400-T1405 

Oui 

Non 

Oui 

Sun Blade 100, 1000, 1500, 2500 

Oui 

Non 

Oui 

Sun Fire 3800, 4800, 4810, 6800, V210, V240, V250, V440, V880, E25K, E20K, E6900, E4900 

Oui 

Oui 

Oui 

Ressources requises par les modules de gestion

Les ressources requises par les modules de gestion dépendent des facteurs suivants :

Le tableau suivant décrit l'impact des modules de gestion de Sun Management Center sur les ressources.

Tableau C–6 Description de l'impact des modules de gestion de Sun Management Center sur le système

Module 

Impact 

Statistiques de l'agent

Cause une faible augmentation de l'encombrement et une faible augmentation de la charge au niveau de la CPU. 

Config-Reader

Utilise la CPU et la mémoire en fonction de la complexité de la configuration matérielle du noeud géré. 

Registre de connexion des données

Cause une faible augmentation de l'encombrement et de la charge CPU, qui est proportionnelle à la quantité de valeurs de données en cours d'enregistrement. 

Contrôle de la taille des répertoires

Cause une faible augmentation de l'encombrement, qui est proportionnelle au nombre des répertoires surveillés. Cause une charge faible à modérée au niveau de la CPU, qui dépend à la fois du nombre des répertoires surveillés et de l'activité au sein de ces répertoires. 

Reconfiguration dynamique 

A un impact minimal sur l'encombrement, utilise la CPU seulement lors de l'accomplissement d'opérations de reconfiguration. 

Contrôle des fichiers

Cause une faible augmentation de l'encombrement, qui est proportionnelle au nombre des fichiers surveillés. Cause une charge faible à modérée au niveau de la CPU, qui dépend à la fois du nombre des fichiers surveillés et de l'activité au sein de ces fichiers. 

Analyse de fichiers (journal système)

Cause une faible augmentation de l'encombrement et de la charge au niveau de la CPU. 

Contrôle de maintenance

A un impact relativement faible sur les ressources. 

HP JetDirect

Cause une faible augmentation de l'encombrement et de la charge au niveau de la CPU. 

Module d'instrumentation IPV6

Cause une faible augmentation de la charge CPU et une augmentation faible à moyenne de l'encombrement, qui est proportionnelle au nombre des interfaces réseau. 

Lecteur de noyau, complet

Affecte la CPU et la mémoire en fonction du nombre des systèmes de fichiers, des CPU et des autres ressources systèmes gérés ainsi qu'en fonction de la fréquence de rafraîchissement de ces informations. Consomme davantage de ressources que le Lecteur de noyau simple. 

Lecteur de noyau (simple) 

A un impact minimal sur la CPU et la mémoire. 

Instrumentation MIB-II

Cause une charge CPU minimale et une augmentation faible à modérée de l'encombrement qui est fonction du nombre des interfaces réseau et de la taille des tables de routage, des tables ARP et des tables système associées. 

Surveillance proxy MIB-II 

Cause une augmentation modérée de l'encombrement, qui est proportionnelle à la taille de la MIB de l'agent SNMP surveillé par le proxy. Cause une augmentation modérée de la charge CPU, qui est proportionnelle au nombre des objets gérés dans l'agent SNMP surveillé par le proxy. 

MIB-II simple

Cause une charge CPU pratiquement inexistante et une augmentation très faible de l'encombrement, qui est proportionnelle à la taille des interfaces système, à la transmission IP et à la table des adresses IP. 

NFS (Network File System)

Cause une faible augmentation de l'encombrement, qui est proportionnelle au nombre des systèmes de fichiers montés sur la machine hôte, et une charge CPU faible. 

Statistiques NFS

Cause une faible augmentation de l'encombrement et une augmentation faible à modérée de la charge au niveau de la CPU. 

Spooler d'impression

Cause une faible augmentation de l'encombrement et de la charge au niveau de la CPU. 

Contrôle des processus Solaris

Cause une faible augmentation de l'encombrement, qui est proportionnelle au nombre des processus surveillés. Cause une charge faible à modérée au niveau de la CPU, qui dépend à la fois du nombre des processus surveillés et de la fréquence à laquelle ces processus sont démarrés et arrêtés. 

Ressources requises par la couche serveur

La couche serveur est le cœur 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 couche serveur de Sun Management Center est prise en charge par les serveurs et postes de travail pour plates-formes SPARC et x86 exécutant Solaris 10 11/06 ou Solaris 10 8/07 sous réserve de répondre à la configuration matérielle minimale requise décrite dans cette section.

Remarque –

Pour de meilleures performances, installez la couche serveur de Sun Management Center 4.0 sur une machine dédiée qui exécute uniquement les applications de la couche serveur.

Plates-formes matérielles recommandées pour le serveur

Les systèmes matériels indiqués dans le tableau suivant représentent quatre grandes catégories de machines pouvant servir de plates-formes serveur Sun Management Center. Dans chaque cas, d'autres configurations pourraient fournir des performances équivalentes.

Sous Solaris SPARC :

Tableau C–7 Plates-formes matérielles serveur Sun Management Center pour Solaris SPARC

Architecture 

Type de machine 

Type de CPU 

RAM 

Zone de swap 

Petit 

Sun Fire V120 

Une CPU UltraSPARC IIe/i de 650 MHz 

2 Go 

1 Go minimum, 2 Go recommandés 

Serveur 

Sun Fire V440 

Deux CPU UltraSPARC III de 1,02 GHz 

4 096 Go 

1 Go minimum, 2 Go recommandés 

Grand 

Sun Fire V480 

Quatre CPU UltraSPARC III de 900 MHz 

16 384 Go 

1 Go minimum, 2 Go recommandés 

Très grande 

Netra-T12 

24 CPU UltraSPARC III de 1,35 GHz 

49,152 Go 

1 Go minimum, 2 Go recommandés 

T2000 (CMT) 

Sun Fire T2000 

16 CPU SPARCv9 de 1 GHz 

8,184 Go 

1 Go minimum, 2 Go recommandés 

Sous Solaris x86 :

Tableau C–8 Plates-formes matérielles serveur Sun Management Center recommandées pour Solaris x86

Architecture 

Type de machine 

Type de CPU 

RAM 

Zone de swap 

Petite 

PC AMD 

1 processeur AMD de 2,393 GHz 

1,023 Go 

1 Go minimum, 2 Go recommandés 

Moyenne 

Sun Fire V20z 

Deux processeurs AMD de 2,393 GHz 

4,096 Go 

1 Go minimum, 2 Go recommandés 

Grande 

Sun Fire X4100 

4 processeurs AMD de 2,200 GHz 

3,968 Go 

1 Go minimum, 2 Go recommandés 

Configuration de dimensionnement requise

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 d'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.

Figure C–1 Charge du serveur de Sun Management Center en événements par jour et par objet géré

Charge du serveur de Sun Management Center en événements par jour et par objet géré

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.

Attention – Attention –

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.

Serveur de Sun Management Center avec l'add-on Performance Reporting Manager

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 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.

La détermination de la configuration requise pour un serveur de Sun Management Center avec l'add-on PRM s'effectue en deux étapes.

  1. 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.

  2. 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.

Génération de rapports Performance Reporting Manager

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 :

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.

Remarque –

Un serveur Sun Management Center moyen accompagné de l'add-on Performance Reporting Manager est supposé être un modèle SunFire x4200 équipé de deux CPU x86 cadencées à 2 200 MHz ou un modèle SunFire-v440 avec deux CPU à 1 281 MHz SPARCv9 , 1 Go de RAM et 1 Go de swap. On suppose également que le serveur surveille 300 agents et collecte 300 propriétés de données par agent pour Performance Reporting Manager.

Programmation des rapports de 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.

Considérations sur les performances

Les principaux facteurs qui affectent la performance de la couche serveur sont les suivants:

Démarrage simultané de composants de Sun Management Center

Le démarrage simultané de la couche serveur et de nombreux agents peut avoir un impact négatif sur les performances 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.

Configuration de groupes topologiques

Le nombre maximum de groupes topologiques dans un contexte serveur Sun Management Center ne doit pas dépasser :

Activités de gestion

L'activité du serveur de Sun Sun Management Center dépend des facteurs suivants :

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.

Nombre d'utilisateurs de la console.

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.

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.

Ressources requises par la couche console Java

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 par les systèmes SPARC exécutant les systèmes d'exploitation Solaris 8, Solaris 9 ou Solaris 10 et les systèmes x86 exécutant les systèmes d'exploitation Solaris 9 et Solaris 10. La console est également prise en charge par les systèmes Intel exécutant Microsoft Windows 2000, Microsoft Windows XP Professionnel, RedHat Enterprise Linux 4.0, SUSE 9.3, SLES 10.0 et Fedora Core 4.0.

Ressources requises par les agents de plate-forme/proxy Sun Fire

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 des domaines ayant chacun une allocation matérielle. 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 la 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 la CPU et de 15 à 18 Mo de mémoire. Les consommations de CPU 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 CPU 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.

Configuration système requise

Vous pouvez installer les agents de plate-forme sur au choix :

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 CPU 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.

Figure C–2 Architecture de l'agent de plate-forme

Architecture de l'agent de plate-forme

Démarrage de plusieurs agents de plate-forme

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 sont initialisés en même temps, ils tendent à 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.

Déploiement des agents de plate-forme Sun Fire sur un hôte dédié

Le tableau suivant indique les configurations matérielles 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–9 Hôte dédié : capacité en agents de plate-forme Sun Fire

Configurations matérielles représentatives 

Nombre maximum d'agents de plate-forme 

Sun Fire V120 équipé d'une CPU UltraSPARC IIe/i de 650 MHz, de 2 Go de RAM et de 1 Go d'espace swap  

5 à 7 

Sun Fire V440 équipé de deux CPU UltraSPARC III de 1,2 GHz, 4 Go de RAM et de 1 Go d'espace 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 des ressources pour agent de plate-forme plus importantes, 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 agents de plate-forme et il est donc possible d'exécuter davantage d'agents de plate-forme sur un unique hôte.

Déploiement des agents de plate-forme Sun Fire sur un hôte hébergeant la couche serveur

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 CPU doivent être pris en compte 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 types.

Tableau C–10 Hôte hébergeant la couche serveur : capacité en agents de plate-forme Sun Fire

Nombre des agents gérés 

Nombre maximum d'agents de plate-forme 

100 

6 

300 

5 

500 

4 

750 

SO 

Sun Fire 280R correspond à un hôte de la couche serveur de type Sun Fire 280R, Sun Blade 1000 ou Netra T4 à deux CPU 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.