Résumé :
Ce document décrit les différents éléments de l'environnement StorADE, dont l'utilisation de démons et de crons, les techniques de test utilisées pour contrôler les périphériques, les fournisseurs de notification et la structure de génération d'événements. Il s'adresse aux administrateurs système et requiert certaines connaissances d'Unix (Solaris). Il peut être utilisé conjointement au Guide de l'utilisateur qui décrit de manière détaillée les fonctions de l'interface utilisateur graphique. Ce document désigne les produits de stockage Sun à l'aide d'abréviations. La liste des abréviations que vous trouverez dans l'annexe A définit ces produits plus précisément.
Qu'est-ce que StorADE ?
StorADE est une application distribuée utilisée pour contrôler et procéder au diagnostic de produits Sun, de commutateurs pris en charge par Sun et de produits de virtualisation Sun. Les principales fonctions de StorADE sont le contrôle des périphériques, la génération d'événements, la présentation et la détection de la topologie, les diagnostics, le contrôle de révision, les rapports de périphérique/unités remplaçables sur site (FRU) et la configuration (édition système). StorADE dépend d'agents installés en intrabande (sur le chemin de données) et hors bande (via Ethernet) pour effectuer son contrôle. L'installation du logiciel StorADE sur un serveur ajoute une entrée cron au serveur et un service http spécifique de StorADE à la liste des services gérés par inetd sur ce même serveur. Le cron active régulièrement l'agent StorADE (paramétrable) pour tester les périphériques et contrôler les fichiers journaux. Un fichier de configuration conservé dans l'interface utilisateur graphique StorADE est utilisé pour gérer la liste de périphériques que l'agent ou les agents doivent contrôler. Un de ces agents est considéré comme l'agent maître et tous les agent esclaves transmettent leurs conclusions (alertes et événements) à l'agent maître pour la suite du traitement. Les événements générés se basent sur une grille de services identiant les causes probables et les actions recommandées jusqu'au niveau d'une unité remplaçable sur site individuelle.
La principale fonction de l'agent maître consiste à présenter la base de données de contrôle (y compris la configuration, les rapports d'outils, les événements, la maintenance, la topologie, etc.) via une interface utilisateur graphique et à envoyer tous les messages aux consommateurs d'événements (appelés fournisseurs de notifications dans l'interface utilisateur graphique), tels que SRS. L'interface utilisateur graphique maître centralise toutes les fonctions de configuration tant pour l'agent maître que les agents esclaves. Il n'est pas nécessaire de pointer un navigateur vers un serveur esclave pour configurer cet agent esclave. Les événements peuvent être envoyés aux administrateurs du site sous forme de notifications locales par courrier électronique ou d'alertes et d'événements à SRS, NetConnect et à Sun Network Storage Command Center (NSCC). Le centre NSCC est une base de données statistique utilisée par les équipes techniques de Sun pour détecter les tendances et les problèmes liés aux produits de stockage Sun. La configuration des courriers électroniques et des fournisseurs est également réalisée à l'aide de l'interface utilisateur graphique StorADE et enregistrée dans le fichier de configuration.
Le diagramme suivant présente un exemple de configuration où un maître et un esclave collaborent pour contrôler 2 groupes partenaires Sun T3, 1 commutateur et 3 Sun A5000 :
Il existe deux versions de StorADE, une édition pour périphériques qui comprend toutes les fonctions StorADE (sauf quelques fonctions spécifiques à Sun Solution) et une édition Sun Solution utilisée sur le processeur de service des produits 3900/6900/6320). L'édition pour périphériques (nom du logiciel SUNWstade) est une véritable édition SAN étant donné qu'elle comprend toutes les fonctions de topologie et d'agrégation SAN de StorADE. L'édition Sun Solution (nom du logiciel SUNWstads) est préinstallée sur le processeur de service des produits de la solution et comprend certaines fonctionnalités différentes par rapport à l'édition pour périphériques.Elle comprend également des fonctions de gestion spécialisées comme la fonction 'Configuration 3900/6900'. Ces deux logiciels sont créés à partir de la même base de codes.
Cycle d'installation de StorADE :
Une installation StorADE se compose généralement des étapes suivantes :
Installation de StorADE sur un ensemble de serveurs, l'un d'eux étant désigné comme l'agent maître, généralement parce qu'il s'agit déjà d'une station de gestion ou parce qu'il a accès aux courriers électroniques, est enregistré avec le serveur de noms et est facilement accessible. L'agent maître est celui qui fournit l'interface utilisateur. Il est appelé 'maître' même s'il n'y a pas d'esclave. Chaque instance d'agent, qu'elle soit maître ou esclave, peut contrôler des périphériques. Les périphériques peuvent être contrôlés en intrabande (généralement par des agents esclaves installés sur le serveur adéquat) ou hors bande (à partir de n'importe quel agent). Lorsque des fichiers journaux sont disponibles (comme dans le cas des t3/t4 et 3310 minnow), il est généralement recommandé d'installer un agent sur le serveur où ces fichiers journaux sont répliqués et de contrôler les périphériques hors bande à partir de cet agent. Cette configuration permet au même agent de consulter les informations des fichiers journaux, de vérifier les périphériques et de mettre en corrélation les informations trouvées. Après pkgadd, exécutez /opt/SUNWstade/bin/ras_install pour installer les crons et les services inetd. Le programme ras_install vous posera quelques questions de base, telles que 'Cet agent est-il maître ou esclave ?' , 'Où est le maître ?', 'Souhaitez-vous activer la sécurité SSL ?', etc.
Initialisation de la configuration. Accédez à StorADE en pointant un navigateur vers l'hôte qui présente le numéro de port adéquat. Les numéros de port StorADE sont 7654 (non sécurisé) et 7443 (sécurisé). REMARQUE :La connexion initiale se fait toujours avec le nom d'utilisateur ras et le mot de passe agent. Ces informations peuvent être modifiées après la première connexion. Des utilisateurs complémentaires avec différentes permissions, préférences locales et de navigateur peuvent également être créés. La configuration initiale consiste à introduire les informations du site, à détecter les périphériques, à ajouter manuellement les périphériques de stockage à la configuration StorADE, à ajouter les adresses locales de courrier électronique pour la réception d'événements et à ajouter des fournisseurs de notification pour la transmission d'événements à SRS, SSRR, NetConnect etc. La plupart de ces fonctions peuvent également être exécutées à partir l'interface de ligne de commande (CLI) à des fins de facilité et d'automatisation. Un rapport de vérification de configuration peut être exécuté à partir de l'interface utilisateur graphique pour vérifier que tout est conforme à la configuration.
Devices Discovery. StorADE contrôle les périphériques inclus dans son fichier de configuration (/opt/SUNWstade/DATA/rasagent.conf). Des périphériques peuvent être ajoutés dans ce fichier à l'aide de l'option "Ajout d'un périphérique", "Détecter périphériques" ou la commande CLI 'ras_admin' (/opt/SUNWstade/bin/ras_admin). L'option "Ajout d'un périphérique" est très directe et implique généralement la saisie de l'IP du périphérique. Pour que StorADE puisse ajouter un périphérique à sa configuration, il doit d'abord pouvoir accéder à ce périphérique et l'identifier. L'identification implique en principe la détection du port WWN de ce périphérique ainsi que l'identificateur de boîtier. Le fichier /etc/deviceIP.conf permet d'automatiser la détection de périphériques. Ce fichier utilise une syntaxe identique à celle de /etc/hosts et est géré par l'administrateur système. Il contient la liste de tous les périphériques qui doivent être contrôlés par StorADE. Consultez l'annexe D, vous y trouverez un exemple de ce fichier. Vous pouvez utiliser le CLI (ras_admin discover_deviceIP) tout comme le GUI pour détecter des périphériques sur base du fichier /etc/deviceIP.conf.
Détection de la topologie. Il s'agit seulement d'une étape de configuration supplémentaire légèrement plus complexe. Pour effectuer une détection de topologie StorADE complète, chaque agent (maître ou esclave) doit détecter sa section du SAN (à la fois intrabande et hors bande), fusionner ces informations en une seule topologie et envoyer cette topologie à l'agent maître pour la suite de l'agrégation. L'agent maître fusionne toutes les topologies reçues avec sa propre topologie afin de créer une seule topologie StorADE 'MAÎTRE'. La topologie créée par StorADE est essentiellement physique. Elle comprend des informations sur les boîtiers, des informations sur les groupes partenaires, des informations sur les chemins intrabandes, le nom universel, etc. Elle est enregistrée comme image instantanée (capture) du réseau SAN et est utilisée dans toutes les opérations liées au SAN jusqu'à ce qu'un nouvel instantané de la topologie SAN soit créé par le client. Elle est disponible à partir de Admin -> Maintenance de la topologie -> Capture de la topologie.
Lancement des agents. Lorsque StorADE est installé et que le programme ras_install a été exécuté, les agents des périphériques peuvent ne pas être tous lancés. Les agents sont lancés à partir de l'interface utilisateur graphique, généralement après la détection des périphériques et l'initialisation des fournisseurs de notification. Le lancement des agents signifie pratiquement que les crons StorADE sont à présent actifs sur tous les agents (maître et esclaves). Cette fonction est disponible à partir de Admin -> Maintenance générale -> Lancement des agents (voir figure 1, carte du site). Référez-vous au Guide de l'utilisateur StorADE pour plus de détails sur l'initialisation des périphériques et des fournisseurs.
En cas d'alerte concernant un périphérique, StorADE avertit l'administrateur du site par courrier électronique (s'il est configuré) et envoit une notification à Sun par l'intermédiaire d'un des services à distance (SRS, SSRR, etc.) configurés d'origine. Les courriers électroniques envoyés à l'administrateur suffisent souvent pour isoler le problème étant donné qu'ils comprennent une cause probable et l'action recommandée. Pour obtenir une meilleure vue d'ensemble du problème, l'administrateur du site ou le personnel de Sun peut demander l'accès à l'interface utilisateur graphique StorADE (ou à l'interface de ligne de commande) afin d'étuder les informations communiquées en contexte. Cela peut se faire en examinant directement le périphérique (Contrôle -> Périphériques), la topologie (Contrôle -> Topologie) ou le journal d'événements StorADE complet (Contrôle -> Journal d'événements). Vous trouverez des exemples de ces fonctions dans les figures 2, 3 et 4. La figure 5 présente un exemple de courrier électronique. Après avoir relu les informations, des diagnostics peuvent être posés pour identifier plus précisément la cause du problème.
Identification du problème Les diagnostics peuvent être exécutés à partir de l'interface de ligne de commande ou à partir de l'interface utilisateur graphique. L'interface utilisateur graphique StorADE permet aux utilisateurs d'exécuter des tests à distance à l'aide d'agents esclaves. Cette fonctionnalité permet à l'utilisateur de lancer et de contrôler un test à partir d'une interface utilisateur graphique centralisée sur le serveur maître, même lorsque le test de diagnostic à proprement parler s'exécute sur un serveur esclave.
Lorsque le problème est réglé, l'utilisateur peut effacer la maintenance du périphérique dans l'interface utilisateur graphique StorADE, recréer une topologie si de nouveaux périphériques de stockage ont été ajoutés et revenir à l'étape 5.
Stratégie de contrôle :
Le contrôle est effectué par les agents maître et esclaves installés sur un ensemble de serveurs. Ces serveurs sont sélectionnés pour les raisons suivantes :
Le serveur a accès aux périphériques de stockage en intrabande (par exemple Sun StorEdge A5K).
Le serveur a accès aux fichiers journaux comme /var/adm/messages ou aux fichiers journaux des périphériques de stockage comme /var/adm/messages.t3.
Le serveur dispose d'un accès hors bande aux périphériques de stockage qui peuvent être contrôlés hors bande comme les T3 et les commutateurs Sun.
Différents serveurs sont utilisés pour distribuer la charge de contrôle. Par exemple, toutes les baies de disques Sun StorEdge T3 ne doivent pas être contrôlées à partir du même agent. Bien souvent, les systèmes Sun StorEdge T3 sont installés en groupes et répliquent leurs fichiers journaux (messages.t3) sur plusieurs serveurs. Dans ce cas, il est recommandé d'installer un agent esclave sur chaque serveur pour avoir accès au fichier journal et aux t3 correspondants à partir du même agent. Référez-vous au guide de planification de l'installation et de la configuration pour plus de détails sur les configurations StorADE.
Cycle de contrôle :
L'exécution des agents est contrôlée par le démon du cron sur chaque serveur. Les principales étapes d'un cycle de contrôle sont les suivantes :
Vérifiez que l'agent est seul à s'exécuter. Si la précédente exécution de l'agent n'est pas terminée :attendez qu'elle soit finie. Une seule instance de l'agent de contrôle (./opt/SUNWstade/bin/rasagent) peut s'exécuter à un moment précis.
Chargez et exécutez tous les modules de périphérique appropriés utilisés pour générer des rapports d'outils ainsi que des événements de maintenance. Les rapports d'outils sont générés en recherchant toutes les informations pertinentes sur les périphériques et en enregistrant ces informations dans un rapport sauvegardé dans /var/opt/SUNWstade/DATA. Ces rapports sont comparés d'une exécution de l'agent à l'autre afin de générer des événements liés à la maintenance. Les événements sont également créés en relayant les informations trouvées dans les fichiers journaux. Par exemple, toutes les erreurs et tous les avertissements trouvés dans /var/adm/messages.t3 sont traduits en un événement 'de journal' sans autre analyse. La plupart des événements sont générés car une règle ou une politique dans StorADE a conclu qu'il existait un problème. Cependant, si le système T3 indique des problèmes dans le fichier journal du système, un événement est immédiatement généré. Référez-vous à l'annexe C pour plus de détails sur les commandes utilisées pour contrôler les périphériques.
Envoyez ces événements à l'agent maître s'ils ont été générés par un esclave. Si les événements sont générés par l'agent maître, envoyez-les à toutes les parties intéressées. L'agent maître est responsable de la génération de ses propres événements et de la collecte des événements générés par les esclaves. Les événements peuvent aussi être rassemblés sur le serveur maître avant diffusion.
Enregistrez les rapports d'instrumentation dans le répertoire DATA. REMARQUE :Les journaux d'événements sont accessibles à partir de l'interface utilisateur graphique sous Contrôle -> Journaux (/opt/SUNWstade/DATA/Events.log). StorADE met alors la base de données d'états à jour à l'aide des statistiques concernées. Certains événements nécessitent qu'un certain seuil soit atteint avant qu'un événement puisse être généré. Par exemple, le fait que le nombre CRC d'un port de commutateur augmente d'une unité n'est pas suffisant pour déclencher un événement dans la mesure où un certain seuil est requis. Un seuil doit également être atteint en ce qui concerne le courrier électronique. StorADE prend en charge les seuils de courrier électronique qui peuvent être utilisés pour empêcher la génération de multiples courriers électroniques à propos du même composant d'un périphérique déterminé. En suivant le nombre d'événements déjà envoyés dans un délai donné, il est possible d'éviter les alertes par courrier électronique redondantes. REMARQUE : Certains fournisseurs (hors courrier électronique) ne prennent pas en charge cette fonctionnalité étant donné qu'il peut être important de suivre toutes les indications qui sont envoyées. La plupart des événements ne sont pas affectés par ce problème étant donné qu'ils ne sont envoyés que lors du changement d'état initial. Par exemple, si l'alimentation par batterie est perdue, une alerte est envoyée pour cette transition (à savoir la panne de courant) et aucun événement n'est envoyé jusqu'à ce que l'état redevienne positif (à savoir lorsque l'alimentation est rétablie) ou jusqu'au passage à un autre état (à savoir la suppression de l'alimentation).
Envoyez les événements appropriés aux parties intéressées. Tous les événements ne sont pas envoyés à tout le monde. Par exemple, les administrateurs locaux peuvent choisir le genre d'événements qu'ils souhaitent recevoir. Ainsi, ils peuvent choisir les types de périphériques ou d'événements qui les intéressent (p. ex. perte de communication) ainsi que le niveau des alertes qu'ils souhaitent recevoir (p. ex. uniquement des avertissements et des erreurs). REMARQUE : Le fournisseur Sun SRS ne reçoit que des événements susceptibles de donner lieu à une action (voir la structure des événements) mais le Sun Network Storage Command Center (NSCC via NetConnect) reçoit tous les événements.
Cycle des événements :
La plupart des événements StorADE sont basés sur des transitions de maintenance. Par exemple, le passage d'un périphérique de l'état 'En ligne' à l'état 'Hors ligne' donne lieu à une transition de maintenance. C'est la transition de l'état 'hors ligne' à l'état 'en ligne' qui génère un événement, et non la valeur 'hors ligne'. Si seul l'état était utilisé pour générer des événements, les mêmes événements seraient sans cesse générés. Les transitions ne peuvent être utilisées lors du contrôle des fichiers journaux, de sorte que les événements journaux peuvent être très répétitifs. Ce problème est minimisé par la définition de seuils pour les entrées des fichiers journaux. Les seuils garantissent qu'un nombre minimum d'entrées seront enregistrés dans les journaux au cours d'une période déterminée avant qu'un événement soit généré. StorADE comprend également une base de données de 'maxima d'événements' qui suit le nombre d'événements relatifs à un sujet déterminé générés au cours d'une même période de 8 heures. Cette base de données est utilisée pour arrêter la génération d'événements répétitifs lorsqu'il n'y a pas d'autre moyen de le faire. Par exemple, si le port d'un commutateur basculait entre l'état hors ligne et en ligne à quelques minutes d'intervalle, la base de données de maxima d'événements garantit que ce basculement ne sera signalé qu'une fois toutes les 8 heures plutôt que toutes les 5 minutes.
D'une manière générale, les événements sont générés à l'aide des règles suivantes :
La toute première fois qu'un périphérique est contrôlé, un événement de détection est généré. Cet événement n'est pas susceptible de donner lieu à une action et est utilisé pour définir une base de contrôle, essentiellement pour le NSCC. Cet événement décrit en détail les composants du périphérique du stockage. Chaque semaine après la détection, un événement de vérification est généré. Son contenu est identique à un événement de détection.
Un événement de journal peut être généré lorsque des informations intéressantes sont trouvées dans les fichiers journaux d'hôte ou de stockage . Ces informations sont généralement liées aux périphériques de stockage appropriés dans la mesure du possible et envoyées à tous les consommateurs. Ces événements peuvent donner lieu à une action sur la base des seuils et être envoyés à SRS, SSRR, NetConnect, etc.
Des événements sont générés lorsque des changements sont constatés dans le contenu du rapport d'instrumentation généré lors du test des périphérique en comparaison avec le dernier rapport d'instrumentation (datant généralement de x minutes). C'est à ce niveau que la plupart des événements StorADE sont générés : événement de changement d'état (StateChangeEvent), événement de topologie (TopologyEvent), événement d'alarme (AlarmEvent), etc. Référez-vous à l'annexe B pour obtenir la liste complète des événements par périphérique. Dans l'interface utilisateur graphique StorADE, consultez Rapport -> Grille de services -> Grille d'événements pour en savoir plus sur les événements.
Lorsque cela s'avère possible, les événements liés sont combinés par l'agent maître StorADE pour générer des événements agrégés (AggregatedEvents). Remarque :L'agrégation d'événements n'est pas activée par défaut mais peut être utilisée pour automatiser l'agrégation de plusieurs événements en un seul courrier électronique qui reprend l'événement agrégé ainsi que les événements originaux qui ont été utilisés pour arriver à cette conclusion.
Tous les événements comprennent les zones suivantes :
Une zone Type d'événement qui décrit de quel type d'événement il s'agit :détection, événement de journal, événement de changement d'état, etc.
Une zone Catégorie de périphérique qui correspond à une catégorie de périphérique Storade : a5k, t3, a3500fc, commutateur, brocade, etc.
Une zone Gravité de l'événement : La gravité dans StorADE2 est indiquée par les valeurs suivantes : 0 = notification normale, 1 = avertissement, 2 = erreur, 3 = erreur critique.
Les niveaux de sécurité sont signalés dans l'interface utilisateur graphique à l'aide des icônes suivantes :
Un indicateur Action requise :Lorsqu'une action est requise, les événements sont transmis à Sun SRS, par exemple. Les événements Erreur et Erreur critique sont aussi susceptibles de donner lieu à une action. Certains avertissements sont également susceptibles de donner lieu à une action, mais la plupart ne le sont pas. Les notifications ne nécessitent pas d'action.
Une zone Sujet d'événement : Le sujet est spécifique du périphérique. Par exemple, sur un commutateur, le type d'événement peut être un changement d'état (StateChangeEvent) et le sujet 'port.1' :Ce sujet d'événement est utilisé pour signaler que le port d'un commutateur est passé, par exemple, de l'état 'en ligne' à l'état 'hors ligne'. .
Un code d'événement : Ce code se compose d'un ensemble de 3 chiffres séparés par des points. Il est utilisé pour identifier les événements et est équivalent à device_category.event_type.event_topic, mais en beaucoup plus court. Vous trouverez une liste complète des codes dans la grille d'événements. Les codes d'événements sont souvent visibles dans l'interface utilisateur graphique et permettent un accès facile à la base de données de la grille de services où sont enregistrées les causes et les actions.
Maître de remplacement :
StorADE prend en charge le concept de maître de remplacement. Un maître de remplacement est un esclave qui, à chaque exécution du cron, vérifie que le maître réel est toujours actif et assume certaines responsabilités du maître réel lorsque celui-ci ne répond pas. Tous les esclaves, y compris le maître de remplacement, disposent d'une copie de la configuration complète de StorADE. Cette configuration comprend l'emplacement de tous les agents (adresse IP, etc.). Ces informations permettent au maître de remplacement d'appeler les esclaves et de réorienter provisoirement le flux d'événements du maître réel vers le maître de remplacement.
Étant donné que le maître réel est responsable de l'envoi des événements et des courriers électroniques, une des pincipales fonctions du maître de remplacement consiste à avertir l'administrateur que le serveur maître n'est plus opérationnel, sinon cet événement ne serait jamais envoyé. Le maître de remplacement ne tente pas de prendre la place du maître réel. Il se rappelle quel agent est le maître réel et renonce à son rôle de maître temporaire lorsque la communication avec le maître réel est rétablie. Cette architecture est destinée à faire face à la perte temporaire de l'agent maître :Si l'agent maître est supprimé du site, un autre serveur peut devenir le maître permanent (en exécutant à nouveau le programme ras_install).
Encombrement du produit :
StorADE a été conçu pour occuper un espace minimum et être invisible lorsqu'il n'est pas utilisé. Il comprend un cron et un service http à la demande utilisé pour la communication navigateur/esclave/maître.
Le logiciel StorADE comprend un cron qui s'exécute toutes les 5 minutes. À chaque démarrage du programme du cron, celui-ci vérifie avec le fichier de configuration StorADE s'il convient d'exécuter les agents. La fréquence de l'agent réel peut être modifiée d'agent en agent grâce à l'interface utilisateur graphique. Si, par exemple, la fréquence de l'agent a été modifiée à 30 minutes, le cron est annulé 5 fois sur 6. Cet agent cron (/opt/SUNWstade/bin/rasagent) s'exécute à la fois sur les agents maître et esclaves. Il s'agit d'un programme Perl qui peut atteindre approximativement 15 Mo de mémoire. Le programme Perl n'est pas inclus dans StorADE. Une version de Perl doit donc être installée sur le serveur pour que StorADE fonctionne (version Perl 5.005 ou supérieure). Lorsqu'il s'exécute, l'agent cron enregistre des informations spécifiques du périphérique dans le répertoire /opt/SUNWstade/DATA et la taille de son processus n'est pas affectée par le nombre de périphériques contrôlés :Lorsque le contrôle d'un périphérique est terminé, les données de l'outil sont enregistrées sur le disque et effacées de la mémoire.
L'agent cron n'est utilisé que pour tester des périphériques et générer des événements. Il ne donne pas accès à l'interface utilisateur graphique StorADE. Cette opération est réalisée par un service http généralement installé sur les ports 7654 et 7443 (sécurisés). Ce programme, appelé /opt/SUNWstade/rashttp, est lancé à partir du fichier inetd et reste en mémoire tant qu'un utilisateur a besoin de l'interface utilisateur graphique. Une période de temporisation est définie pour le rashttp (par défaut 30 secondes), après quoi le programme est arrêté. Cette période de temporisation est destinée à minimiser le nombre de processus présents sur les serveurs. Ce service http est aussi un programme Perl et son encombrement est similaire à l'agent cron. Il est utilisé pour répondre aux demandes http émanant des navigateurs ou des esclaves. Le maître et les esclaves utilisent le protocole http pour partager des informations sur la configuration, la topologie, de nouveaux événements, etc.
Options de sécurité :
Vous pouvez installer StorADE avec une option de sécurité en exécutant le programme ras_install et en répondant 'Oui' à la question relative à la sécurité. Le protocole SSL (Secure Socket Layer) est alors utilisé pour la transmission d'informations entre l'agent maître et le navigateur et entre l'agent maître et les agents esclaves. Le logiciel StorADE comprend par défaut un certificat expirant en 2008 (situé dans /opt/SUNWstade/System/certificate.pem), qui fait appel au plus haut niveau de cryptage (RC4 avec clé secrète de 128 bits). Lorsque le mode sécurisé est utilisé, l'adresse universelle (URL) utilisée pour accéder à l'agent maître est https://nom-hôte:7443. L'URL non sécurisée est http://nom-hôte:7654. Des certificats spécifiques du site peuvent être créés grâce aux utilitaires openssl (qui font partie du produit OpenSSL de domaine public). Le type de commande qui serait utilisée est la suivante : /usr/local/ssl/bin/openssl req -days 200 -new -nodes -x509 -out new_certificate.pem -keyout new_certificate.pem2. Référez-vous à l'annexe C pour plus de détails sur le certificat.
Pour une sécurité optimale, StorADE prend en charge les noms d'utilisateur multiples. Ces noms d'utilisateur peuvent être ajoutés par le superutilisateur (nom d'utilisateur 'ras', mot de passe par défaut 'agent') en même temps que des fonctionnalités spécifiques (invité, admin, expert, test). Cela permet à différents utilisateurs de se connecter avec leur propre nom d'utilisateur/mot de passe et de disposer d'un ensemble limité de fonctions disponibles dans l'interface utilisateur graphique.
Sun-Solutions:
Les solutions Sun StorEdge, notamment Sun 3900/6900 (Indy) et Sun 6320 (Maserati) sont des périphériques de stockage logique créés à partir de commutateurs Sun, de systèmes Sun T3/6120, de moteurs de virtualisation Sun et d'un processeur de service. Ces composants sont préconfigurés en un seul produit qui comprend une version de StorADE sur le processeur de service (StorADE édition système). Vous pouvez accéder à la version de StorADE dans la baie de la solution, comme tout autre agent maître StorADE, à l'aide d'un navigateur paramétré avec l'adresse IP du processeur de service. REMARQUE :Pour le monde extérieur (y compris une instance externe de StorADE), la baie de la solution est considérée comme un seul périphérique.
Dans les versions précédentes, il était possible de configurer l'agent sur une baie de la solution Sun comme esclave, mais cette option a été supprimée dans la version StorADE 2.2 à des fins d'évolutivité et de maintenabilité. Lorsqu'un agent StorADE installé en dehors de la baie doit contrôler cette baie, il détecte la baie de la solution Sun comme un seul périphérique avec sa propre icône spécifique. Dans le graphique ci-dessous, les deux commutateurs de la baie de la solution Sun présentent actuellement une erreur (en rouge). Ces erreurs sont représentées dans l'icône de la baie par deux cases rouges, une pour chaque logement de commutateur. Pour consulter la topologie détaillée de la baie, l'utilisateur doit consulter la version StorADE sur le processeur de service du système 3900 ou utiliser la fonction de lien et de lancement disponible sur l'agent maître (en dehors de la baie). La figure 3 présente un exemple de topologie avec une solution Sun en tant qu'icône unique.
Fournisseurs de notifications :
StorADE prend en charge toute une série de fournisseurs de notifications, y compris les courriers électroniques locaux, SRS, NetConnect, Trap et SSRR. Ces fournisseurs doivent être activés manuellement. Pour ce faire, vous pouvez utiliser l'interface utilisateur graphique ou l'interface de ligne de commande (CLI) ras_admin. Les informations sont envoyées aux fournisseurs chaque fois que l'agent termine son cycle. REMARQUE :Les agents esclaves envoient des événements au 'maître' et le 'maître' envoie des événements aux fournisseurs.
Notification locale par courrier électronique :La fonction de notification locale par courrier électronique est essentiellement utilisée pour envoyer des informations d'événements aux administrateurs locaux. Vous pouvez saisir plusieurs adresses de courrier électronique dans l'interface utilisateur graphique, chacune avec un filtre différent. Lorsque des messages électroniques sont générés, ils sont regroupés par niveau de gravité et par adresse de courrier électronique. Cela signifie qu'un message électronique peut contenir plusieurs événements, mais que ces événements doivent avoir le même niveau de gravité :Une erreur et un avertissement ne seront jamais combinés dans un même message électronique. Outre les principales informations relatives aux événements, le message électronique comprend des informations de la grille de services (informations, cause probable et action recommandée). Les événements comprennent également un code d'événement qui peut être utilisé comme clé de recherche dans la base de données de la grille d'événements (également accessible à partir de l'interface utilisateur graphique StorADE).
Fournisseur SRS :Ce module StorADE envoie une topologie de contrôle de base et tous les événements susceptibles de donner lieu à une action à la console SRS installée sur le site client. SRS ne reçoit que des événements susceptibles de donner lieu à une action et non, par exemple, toutes les informations relatives aux événements disponibles pour la notification locale par courrier électronique :seuls la source de l'événement, la description de l'événement et le code de l'événement sont envoyés. La console SRS doit être visible pour le maître StorADE afin que ce fournisseur fonctionne. La communication avec la console est basée sur le protocole http.
La communication avec le fournisseur SSRR repose sur Unix. Lorsque des événements sont disponibles, le programme SendToSupport (/va/remote.support/scripts/sendtosupport) est exécuté avec un fichier contenant ces événements comme argument. Les événements tant susceptibles que non susceptibles de donner lieu à une action sont envoyés à SSRR. Les événements nécessitant une action sont envoyés séparément et sont signalés comme tels (à la différence des autres, qui ne font pas l'objet d'une signalisation particulière).
Le module NetConnect repose sur le fichier SHUTTLE (/opt/SUNWstade/DATA/SHUTTLE) pour communiquer avec NetConnect. Il existe 2 fichiers SHUTTLE (SHUTTLE.1 et SHUTTLE.3 pour distinguer les événements nécessitant une action et les autres). Lorsqu'il est disponible, le programme ncsend est également exécuté (package_base/SUNWnc/bin/ncsend). Tous les événements sont envoyés à NetConnect. NSCC utilise NetConnect pour charger sa base de données avec des événements provenant des clients.
SunMC. L'activation du logiciel SunMC permet à storADE d'envoyer à un agent SunMC des informations relatives à la topologie et aux alertes. Ces alertes sont visibles depuis la console SunMC. Un logiciel 'rasagent' spécial doit être installés sur l'agent SunMC pour recevoir ces alertes. Ce logiciel est inclus avec StorADE (/opt/SUNWstade/System/SunMC/SUNWesraa.tar.gz).
Trappes SNMP Des trappes SNMP peuvent être envoyées pour des événements susceptibles de donner lieu à une action et réceptionnées par toute application de gestion pouvant recevoir des interruptions.
FIGURES
Figure 1 : Plan du site :
Cette page indique toutes les fonctions disponibles. Elle est générée dynamiquement et peut varier en fonction de l'édition de StorADE et des fonctions autorisées pour l'utilisateur connecté à l'application (en effet, un utilisateur qui ne dispose pas de la permission d'exécuter des tests de diagnostic ne verra pas les informations d'aide relatives aux diagnostics.)
Figure 2 :Contrôle des périphériques :
Cette page présente le contenu de StorADE lorsque 3 cadres sont utilisés. Le cadre supérieur est réservé à la navigation. Le cadre de gauche présente la liste des périphériques contrôlés ainsi que leur niveau de maintenance respectif ('Grav' = gravité). Le cadre de droite peut présenter 5 pages ([ Synthèse | Maintenance | Journal | Rapport | Graphique ]) . La page de graphique présente une icône du périphérique sélectionné (dans ce cas un commutateur) et tous les voisins immédiats de ce périphérique dans le réseau SAN (fichier graphique png). Ce graphique est également suivi de la liste des problèmes courants de maintenance concernant ce commutateur.
Figure3: Topology Graph:
Cette page présente les topologies générées par chaque esclave et par le maître séparément ou la topologie combinée (appelée MAÎTRE). Les topologies peuvent être filtrées et groupées pour un accès aisé. Les icônes de la topologie peuvent être déplacées et enregistrées dans leur nouvelle position pour créer une présentation plus lisible. En cliquant avec le bouton droit sur l'icône, vous accédez au menu des fonctions qui peuvent être appelées pour cette icône (à savoir utiliser le bouton droit de la souris pour afficher un rapport de périphérique ou exécuter un diagnostic). Le fait de cliquer avec le bouton droit autre part que sur une icône permet à l'utilisateur de modifier le niveau de zoom du diagramme. Maintenir la touche MAJ permet de mettre en surbrillance plusieurs icônes en même temps, ce qui peut s'avérer utile pour déplacer des icônes. Dans ce graphique, vous pouvez marquer et cliquer sur des périphériques et des liens. À l'instar des périphériques, les liens peuvent être sélectionnés (par un clic droit) afin d'obtenir plus de détails à leur sujet. Le graphique de la topologie est produit par un applet mais la fonction [ Imprimer ] permet de générer une représentation png (format graphique semblable au gif) pour une impression sans souci.
Figure 3a : Vision intérieure d'une solution Sun :
Cette topologie, visible à partir d'un processeur de service d'une solution Sun, illustre le processeur proprement dit ainsi que les commutateurs externes, les moteurs de virtualisation, les commutateurs internes et les baies de stockage, dans ce cas 3 systèmes T3. Elle illustre également les connexions SAN entre les composants de la baie. Dans cette figure, la solution Sun est appelée 'wst31' ; dans la figure précédente, il s'agissait d'une baie différente appelée 'sp87'. Il existe toute une série de modèles de solutions Sun. Le type et le nombre de composants peuvent donc varier.
Figure 4 :Analyse de journal :
Cette page de journal d'événement peut être utilisée pour afficher un sous-ensemble du journal des événements enregistrés dans le fichier DATA/Events.log. Les événements sont présentés avec un lien à la grille de services pour plus d'informations sur un événement particulier.
Figure 6 :Notification locale par courrier électronique :
Les messages électroniques sont générés à partir de l'agent maître et envoyés aux adresses électroniques introduites dans la configuration StorADE à l'aide de l'interface utilisateur graphique. Les filtres d'événement peuvent être différents pour chaque adresse de courrier électronique. Les messages électroniques peuvent comprendre des informations telles que 'description', 'informations' , 'cause probable' et 'action recommandée'. Par exemple, ce message électronique ne comprend pas de section 'cause probable' .
Annexe A : Liste des abréviations :
Annexe B : Commandes utilisées dans le cadre du contrôle :
Cette section décrit les commandes et les techniques utilisées pour contrôler les périphériques de stockage pris en charge par StorADE.
3310 (Minnow) :Cet agent utilise la commande de ligne de commande '/opt/SUNWstade/bin/sccli show
A3500FC :Cet agent utilise les commandes du logiciel rm6 (healthck, lad, rdacutil, etc.). Ces commandes fonctionnent en intrabande.
A5000 :La commande luxadm est utilisée pour contrôler le système A5K. Il est important de s'assurer que les derniers patchs luxadm sont installés avant d'installer StorADE afin de contrôler l'A5000.
Brocade :StorADE fait appel à la bibliothèque snmp (snmpget, snmpwalk) pour extraire des informations des commutateurs brocade hors bande.
D2 :La commande Luxadm ainsi que d'autres commandes de ligne de commande intrabande (disk_inquiry, rdbuf, identify et vpd) sont utilisées pour contrôler le D2.
Hôte :L'agent hôte utilise également la commande luxadm pour lire les états lun et hba. Il utilise également des commandes Unix (df, showrev, pkginfo) pour extraire des informations des hôtes.
MCData :StorADE utilise également snmp pour les commutateurs McData.
Commutateurs Sun :Pour les commutateurs 1 Go, StorADE utilise la commande de ligne de commande sanbox. Pour les commutateurs 2 Go plus récents, c'est la commande snmp qui est utilisée.
T3 :StorADE utilise des requêtes http pour extraire les propriétés des baies de disques T3 (ces requêtes sont appelées jetons). Les baies de disques Sun StorEdge T3 sont munies d'un serveur Web qui peut être utilisé pour contrôler l'état de la baie de disques. Le contenu des jetons T3 est similaire au résultat des commandes telnet 'fru stat', 'fru list', 'vol stat' etc. Le contenu du fichier journal messages.t3/messages.6120 est aussi utilisé :Les avertissements (A : ), les erreurs (E :) et les notifications importantes sont contrôlées par StorADE.
6120 (T4) :Utilisation de la même technique que T3.
FC-TAPE :La commande Luxadm est aussi utilisée pour contrôler les bandes Fibre Channel.
V880Disk :StorADE utilise l'affichage luxadm pour contrôler le V880Disk dans la bande.
Fichiers de messages :Un module séparé contrôle le fichier /var/adm/message. Ce module enregistre la valeur 'seek' à la fin du fichier et lit les nouvelles entrées dans les fichiers. Lorsque ces nouvelles entrées sont considérées importantes du point de vue du stockage, des événements de journal sont générés. Les pilotes Hba écrivent dans ce fichier journal.
Virtualisation Sun (moteurs de virtualisation) Les périphériques de virtualisation Sun (appelés précédemment Vicom) sont contrôlés hors bande à l'aide de commandes spécifiques des moteurs de virtualisation (showmap, slicview, svstat, mpdrive). Les périphériques de virtualisation sont compris dans la série des solutions Sun 6900.
Baies des solutions Sun StorEdge 39xx/69xx StorADE contrôle une baie de solution en communiquant avec l'agent StorADE sur le processeur de service de la baie. Cette communication est basée sur le protocole HTTP.
Annexe C : Détails sur les certificats
Annexe D : /etc/deviceIP.conf
Vous pouvez uniquement utiliser ce fichier avec des périphériques accessibles hors bande à l'aide du numéro IP. Commutateurs, Sun T3, Sun 6120, Sun 3510 et Sun Solution sont actuellement pris en charge.
#IPNO NAME TYPE(optional)
10.10.10.1 t3-b1
10.10.10.2 t3-b2
10.10.10.3 switch-s1
10.10.10.4 switch-s2
10.10.10.5 minnow1 3510
10.10.10.6 indy-1 rack
10.10.10.7 6120-1
10.10.10.8
Annexe E : Liste d'événements
############################ 3310.grid: Sun 3310/3510 ############################ 3310 AlarmEvent Revision 3310 AlarmEvent channel 3310 AlarmEvent enclosure 3310 AlarmEvent fan 3310 AlarmEvent firmware_version 3310 AlarmEvent part 3310 AlarmEvent power 3310 AlarmEvent raid_level 3310 AlarmEvent size 3310 AlarmEvent temperature 3310 AlarmEvent volume 3310 CommunicationEstablishedEvent ib 3310 CommunicationEstablishedEvent oob 3310 CommunicationLostEvent e 3310 CommunicationLostEvent ib 3310 composantInsertEvent disk 3310 composantInsertEvent power 3310 composantRemoveEvent disk 3310 DeviceLostEvent aggregate 3310 DiscoveryEvent enclosure 3310 LocationChangeEvent enclosure 3310 LogEvent cpu 3310 QuiesceEndEvent enclosure 3310 QuiesceStartEvent enclosure 3310 StateChangeEvent+ disk 3310 StateChangeEvent+ volume 3310 StateChangeEvent- disk 3310 StateChangeEvent- volume ############################ 6120.grid: StorEdge 6120 ############################ 6120 AlarmEvent+ power.temp 6120 AlarmEvent- disk.pathstat 6120 AlarmEvent- disk.port 6120 AlarmEvent- disk.temperature 6120 AlarmEvent- interface.loopcard.cable 6120 AlarmEvent- power.battery 6120 AlarmEvent- power.fan 6120 AlarmEvent- power.output 6120 AlarmEvent- power.temp 6120 AlarmEvent cacheMode 6120 AlarmEvent cacheModeBehind 6120 AlarmEvent initiators 6120 AlarmEvent log 6120 AlarmEvent lunPermission 6120 AlarmEvent revision 6120 AlarmEvent system_reboot 6120 AlarmEvent sysvolslice 6120 AlarmEvent time_diff 6120 AlarmEvent volCount 6120 AlarmEvent volOwner 6120 AuditEvent enclosure 6120 CommunicationEstablishedEvent ib 6120 CommunicationEstablishedEvent oob 6120 CommunicationLostEvent ib 6120 CommunicationLostEvent oob 6120 composantInsertEvent controller 6120 composantInsertEvent disk 6120 composantInsertEvent interface.loopcard 6120 composantInsertEvent power 6120 composantRemoveEvent controller 6120 composantRemoveEvent disk 6120 composantRemoveEvent interface.loopcard 6120 composantRemoveEvent power 6120 DeviceLostEvent aggregate 6120 DiagnosticTest- 6120ofdg 6120 DiagnosticTest- 6120test 6120 DiagnosticTest- 6120volverify 6120 DiscoveryEvent enclosure 6120 LocationChangeEvent enclosure 6120 LogEvent array_error 6120 LogEvent array_warning 6120 LogEvent controller.port 6120 LogEvent disk 6120 LogEvent disk.log 6120 LogEvent disk.senseKey 6120 LogEvent driver.SSD_WARN 6120 LogEvent power 6120 LogEvent power.refreshBattery 6120 LogEvent power.replaceBattery 6120 LogEvent temp_threshold 6120 QuiesceEndEvent enclosure 6120 QuiesceStartEvent enclosure 6120 StateChangeEvent+ controller 6120 StateChangeEvent+ disk 6120 StateChangeEvent+ interface.loopcard 6120 StateChangeEvent+ power 6120 StateChangeEvent+ volume 6120 StateChangeEvent- controller 6120 StateChangeEvent- disk 6120 StateChangeEvent- interface.loopcard 6120 StateChangeEvent- power 6120 StateChangeEvent- volume 6120 Statistics enclosure ############################ a3500fc.grid: Sun A3500FC ############################ a3500fc AlarmEvent- battery a3500fc AuditEvent enclosure a3500fc CommunicationEstablishedEvent ib a3500fc CommunicationLostEvent ib a3500fc composantInsertEvent controller a3500fc composantInsertEvent disk a3500fc composantRemoveEvent controller a3500fc composantRemoveEvent disk a3500fc DeviceLostEvent aggregate a3500fc DiagnosticTest- a3500fctest a3500fc DiscoveryEvent enclosure a3500fc LocationChangeEvent enclosure a3500fc StateChangeEvent+ disk a3500fc StateChangeEvent- controller a3500fc StateChangeEvent- disk ############################ a5k.grid: Sun A5000 ############################ a5k AlarmEvent- backplane a5k AlarmEvent- backplane.fan a5k AlarmEvent- disk a5k AlarmEvent- interface.gbic a5k AlarmEvent- interface.iboard a5k AuditEvent enclosure a5k CommunicationEstablishedEvent ib a5k CommunicationLostEvent ib a5k composantInsertEvent disk a5k composantRemoveEvent disk a5k DeviceLostEvent aggregate a5k DiagnosticTest- a5ksestest a5k DiagnosticTest- a5ktest a5k DiscoveryEvent enclosure a5k LocationChangeEvent enclosure a5k StateChangeEvent+ disk a5k StateChangeEvent+ interface.iboard a5k StateChangeEvent+ power a5k StateChangeEvent- disk a5k StateChangeEvent- interface.iboard a5k StateChangeEvent- power a5k logEvent driver ############################ agent.grid: ############################ agent AgentDeinstallEvent enclosure agent AgentInstallEvent enclosure agent AlarmEvent system_errors agent AlternateMaster+ enclosure agent AlternateMaster- enclosure agent CommunicationEstablishedEvent oob agent CommunicationLostEvent ntc agent CommunicationLostEvent oob agent HeartbeatEvent enclosure ############################ brocade.grid: Brocade switch ############################ brocade AlarmEvent sensor.fan brocade AlarmEvent sensor.power brocade AlarmEvent sensor.temperature brocade AlarmEvent system_reboot brocade AuditEvent enclosure brocade CommunicationEstablishedEvent oob brocade CommunicationLostEvent oob brocade ConnectivityLostEvent aggregate brocade DeviceLostEvent aggregate brocade DiagnosticTest- switchtest brocade DiscoveryEvent enclosure brocade LocationChangeEvent enclosure brocade LogEvent PhysState brocade LogEvent port.statistics brocade StateChangeEvent+ port brocade StateChangeEvent- port brocade Statistics enclosure ############################ d2.grid: Sun D2 ############################ d2 AlarmEvent- fan d2 AlarmEvent- power d2 AlarmEvent esm.revision d2 AlarmEvent midplane.revision d2 AlarmEvent slot_count d2 AlarmEvent temperature d2 AuditEvent enclosure d2 CommunicationEstablishedEvent ib d2 CommunicationLostEvent ib d2 composantRemoveEvent esm d2 composantRemoveEvent midplane d2 DeviceLostEvent aggregate d2 DiagnosticTest- d2test d2 DiscoveryEvent enclosure d2 LocationChangeEvent enclosure d2 StateChangeEvent+ disk d2 StateChangeEvent- disk ############################ host.grid: Host ############################ host AlarmEvent+ hba host AlarmEvent- hba host AlarmEvent- lun.T300 host AlarmEvent- lun.VE host AlarmEvent disk_capacity host AlarmEvent disk_capacity_okay host DiagnosticTest- ifptest host DiagnosticTest- qlctest host DiagnosticTest- socaltest host LogEvent array_error host LogEvent array_warning host LogEvent driver.ELS_RETRY host LogEvent driver.Fabric_Warning host LogEvent driver.Firmware_Change host LogEvent driver.LOOP_hors ligne host LogEvent driver.LOOP_en ligne host LogEvent driver.MPXIO host LogEvent driver.MPXIO_hors ligne host LogEvent driver.PFA host LogEvent driver.QLC_LOOP_hors ligne host LogEvent driver.QLC_LOOP_en ligne host LogEvent driver.SCSI_ASC host LogEvent driver.SCSI_TRAN_FAILED host LogEvent driver.SCSI_TR_READ host LogEvent driver.SCSI_TR_WRITE host LogEvent driver.SFOFFTOWARN host LogEvent driver.SF_CRC_ALERT host LogEvent driver.SF_CRC_WARN host LogEvent driver.SF_DMA_WARN host LogEvent driver.SF_OFFLALERT host LogEvent driver.SF_hors ligne host LogEvent driver.SF_RESET host LogEvent driver.SF_RETRY host LogEvent driver.SSD_ALERT host LogEvent driver.SSD_WARN host LogEvent error host LogEvent warning host PatchInfo enclosure host backup enclosure host patchInfo enclosure ############################ internal.grid: ############################ internal AuditEvent enclosure internal CommunicationEstablishedEvent ib internal CommunicationLostEvent ib internal composantInsertEvent disk internal composantRemoveEvent disk internal DiagnosticTest- fcdisktest internal DiscoveryEvent enclosure ############################ mcdata.grid: McData switch ############################ mcdata AlarmEvent fan mcdata AlarmEvent power mcdata AlarmEvent system_reboot mcdata AuditEvent enclosure mcdata CommunicationEstablishedEvent oob mcdata CommunicationLostEvent oob mcdata ConnectivityLostEvent aggregate mcdata DeviceLostEvent aggregate mcdata DiscoveryEvent enclosure mcdata LocationChangeEvent enclosure mcdata LogEvent PhysState mcdata LogEvent port.statistics mcdata StateChangeEvent+ port mcdata StateChangeEvent- port mcdata Statistics enclosure ############################ san.grid: ############################ san LinkEvent_CRC Any|Any san LinkEvent_CRC host| san LinkEvent_CRC host|switch san LinkEvent_CRC switch|a3500fc san LinkEvent_CRC switch|a5k san LinkEvent_CRC switch|storage san LinkEvent_CRC switch|switch san LinkEvent_CRC switch|t3 san LinkEvent_CRC ve|switch san LinkEvent_ITW Any|Any san LinkEvent_ITW host|storage san LinkEvent_ITW host|switch san LinkEvent_ITW switch|a3500fc san LinkEvent_ITW switch|a5k san LinkEvent_ITW switch|storage san LinkEvent_ITW switch|switch san LinkEvent_ITW switch|t3 san LinkEvent_ITW ve|switch san LinkEvent_SIG Any|Any san LinkEvent_SIG host|storage san LinkEvent_SIG host|switch san LinkEvent_SIG switch|a3500fc san LinkEvent_SIG switch|a5k san LinkEvent_SIG switch|storage san LinkEvent_SIG switch|switch san LinkEvent_SIG switch|t3 san LinkEvent_SIG ve|switch ############################ se.grid: Sun 3900/6900 ############################ se AggregatedEvent POWERSEQ1 se AlarmEvent- lun se AlarmEvent- remove_lun se CommunicationLostEvent oob se composantInsertEvent lun se composantRemoveEvent lun se composantRemoveEvent slot se DeviceLostEvent aggregate se StateChangeEvent links se StateChangeEvent port se StateChangeEvent slot se StateChangeEvent sp ############################ se2.grid: Sun 6320 ############################ se2 AggregatedEvent POWERSEQ1 se2 AlarmEvent- lun se2 AlarmEvent- power_sequencer se2 composantInsertEvent lun se2 composantRemoveEvent lun se2 DeviceLostEvent aggregate ############################ switch.grid: Sun Switch ############################ switch AlarmEvent chassis.fan switch AlarmEvent chassis.power switch AlarmEvent chassis.temperature switch AlarmEvent port.statistics switch AlarmEvent system_reboot switch AlarmEvent zone_change switch AuditEvent enclosure switch CommunicationEstablishedEvent oob switch CommunicationLostEvent oob switch ConnectivityLostEvent aggregate switch DeviceLostEvent aggregate switch DeviceLostEvent ib switch DiagnosticTest- switchtest switch DiscoveryEvent enclosure switch LocationChangeEvent enclosure switch LogEvent port.statistics switch StateChangeEvent+ port switch StateChangeEvent- port switch Statistics enclosure ############################ switch2.grid: Sun Switch2 ############################ switch2 AlarmEvent- chassis.board switch2 AlarmEvent- chassis.fan switch2 AlarmEvent chassis.power switch2 AlarmEvent port.statistics switch2 AlarmEvent system_reboot switch2 AuditEvent enclosure switch2 CommunicationEstablishedEvent oob switch2 CommunicationLostEvent fsa switch2 CommunicationLostEvent oob switch2 ConnectivityLostEvent aggregate switch2 DeviceLostEvent aggregate switch2 DiagnosticTest- switch2test switch2 DiscoveryEvent enclosure switch2 LocationChangeEvent enclosure switch2 StateChangeEvent+ port switch2 StateChangeEvent- port switch2 Statistics enclosure ############################ t3.grid: Sun T3 ############################ t3 AlarmEvent+ power.temp t3 AlarmEvent- disk.pathstat t3 AlarmEvent- disk.port t3 AlarmEvent- disk.temperature t3 AlarmEvent- interface.loopcard.cable t3 AlarmEvent- power.battery t3 AlarmEvent- power.fan t3 AlarmEvent- power.output t3 AlarmEvent- power.temp t3 AlarmEvent add_initiators t3 AlarmEvent backend_loop t3 AlarmEvent cacheMode t3 AlarmEvent cacheModeBehind t3 AlarmEvent device_path t3 AlarmEvent initiators t3 AlarmEvent log t3 AlarmEvent loop.statistics t3 AlarmEvent lunPermission t3 AlarmEvent remove_initiators t3 AlarmEvent revision t3 AlarmEvent system_reboot t3 AlarmEvent sysvolslice t3 AlarmEvent time_diff t3 AlarmEvent volCount t3 AlarmEvent volOwner t3 AuditEvent enclosure t3 CommunicationEstablishedEvent ib t3 CommunicationEstablishedEvent oob t3 CommunicationLostEvent ib t3 CommunicationLostEvent oob t3 composantInsertEvent controller t3 composantInsertEvent disk t3 composantInsertEvent interface.loopcard t3 composantInsertEvent power t3 composantRemoveEvent controller t3 composantRemoveEvent disk t3 composantRemoveEvent interface.loopcard t3 composantRemoveEvent power t3 DeviceLostEvent aggregate t3 DiagnosticTest- t3ofdg t3 DiagnosticTest- t3test t3 DiagnosticTest- t3volverify t3 DiscoveryEvent enclosure t3 LocationChangeEvent enclosure t3 LogEvent array_error t3 LogEvent array_warning t3 LogEvent controller.port t3 LogEvent disk t3 LogEvent disk.error t3 LogEvent disk.log t3 LogEvent disk.senseKey t3 LogEvent power.battery t3 LogEvent power.battery.refresh t3 LogEvent power.battery.replace t3 LogEvent temp_threshold t3 QuiesceEndEvent enclosure t3 QuiesceStartEvent enclosure t3 RemovalEvent enclosure t3 StateChangeEvent+ controller t3 StateChangeEvent+ disk t3 StateChangeEvent+ interface.loopcard t3 StateChangeEvent+ power t3 StateChangeEvent+ volume t3 StateChangeEvent- controller t3 StateChangeEvent- disk t3 StateChangeEvent- interface.loopcard t3 StateChangeEvent- power t3 StateChangeEvent- volume t3 Statistics enclosure ############################ tape.grid: FC-Tape ############################ tape AuditEvent enclosure tape CommunicationEstablishedEvent ib tape CommunicationLostEvent ib tape DeviceLostEvent aggregate tape DiagnosticTest- fctapetest tape DiscoveryEvent enclosure tape LocationChangeEvent enclosure tape StateChangeEvent+ port tape StateChangeEvent- port ############################ v880disk.grid: Sun V880 Disk ############################ v880disk AlarmEvent- backplane v880disk AlarmEvent- loop v880disk AlarmEvent- temperature v880disk AuditEvent enclosure v880disk CommunicationEstablishedEvent ib v880disk CommunicationLostEvent ib v880disk composantInsertEvent disk v880disk composantRemoveEvent disk v880disk DeviceLostEvent aggregate v880disk DiagnosticTest- daktest v880disk DiscoveryEvent enclosure v880disk LocationChangeEvent enclosure ############################ ve.grid: Vicom VE ############################ ve AlarmEvent log ve AlarmEvent volume ve AlarmEvent volume_add ve AlarmEvent volume_delete ve AuditEvent enclosure ve CommunicationEstablishedEvent oob ve CommunicationLostEvent oob.command ve CommunicationLostEvent oob.ping ve CommunicationLostEvent oob.slicd ve DeviceLostEvent aggregate ve DiagnosticTest- ve_diag ve DiagnosticTest- veluntest ve DiscoveryEvent enclosure ve LocationChangeEvent enclosure