## Storage Automated Diagnostic Environment 2.x (StorADE)
Présentation de l'administration

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 :

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

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

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

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

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

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

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

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

1. Le serveur a accès aux périphériques de stockage en intrabande (par exemple Sun StorEdge A5K).

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

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

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

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

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

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

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

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

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

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

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

4. 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 '. Cette commande fonctionne tant en intrabande que hors bande. StorADE utilise la même interface de programmation pour les commandes intrabande et hors bande. Cette commande extrait des informations sur le boîtier et le contenu du journal de messages 3310.

- 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