Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Manuel d'entretien client des systèmes Oracle® ZFS Storage Appliance Pour les contrôleurs ZS3-x, 7x20 et les étagères de disques DE2-24, Sun Disk Shelf |
Utilisation de la présente documentation
Chapitre 2 Maintenance de l'équipement
Chapitre 3 Maintenance du système
Gestion des lots de support à l'aide de la BUI
Génération et téléchargement d'un lot de support à l'aide de la BUI
Options pour les lots de support
Gestion des lots de support à l'aide de la CLI
Réinitialisation des paramètres d'usine
Notification de mises à jour logicielles
Planification des notifications de logiciels à l'aide de la BUI :
Planification des notifications de logiciels à l'aide de la CLI :
Vérification de mises à jour à l'aide de la BUI
Vérification de mises à jour à l'aide de la CLI
Présentation des mises à jour du système
Vérifications d'intégrité préalables à la mise à jour
Interface de ligne de commande
Dépannage des échecs de vérifications d'intégrité préalables à la mise à jour
Mesures à prendre pour résoudre les alertes concernant des vérifications d'intégrité
Etapes de résolution des alertes de vérification d'intégrité
Réinitialisation après une mise à jour
Mises à jour de microprogrammes du matériel
Réalisation d'une mise à niveau de cluster
Etats du cluster pendant la mise à niveau
Décompression et vérification du média
Suppression d'un média de mise à jour
Application de mises à jour différées
Décompression et vérification du média
Suppression d'un média de mise à jour
Application de mises à jour différées (CLI)
Mise à jour différée Passthrough-x
Mise à jour différée Quotas d'utilisateurs
Mise à jour différée RAID triple parité
Mise à jour différée Suppression des doublons de données
Mise à jour différée Réplication
Mise à jour différée Propriétés reçues
Mise à jour différée Suppression d'instantanés
Mise à jour différée Instantanés récursifs
Mise à jour différée Remplacement multiple
Mise à jour différée RAIDZ/Miroir
Groupes d'initiateurs multiples par LUN
Support pour les blocs de très grande taille
Support pour les blocs de très grande taille
Gestion des sauvegardes de configuration à l'aide de la BUI
Création d'une sauvegarde de configuration
Restauration à partir d'une configuration enregistrée
Suppression d'une configuration enregistrée
Exportation d'une configuration enregistrée
Importation d'une configuration enregistrée
Gestion de sauvegardes de configuration à l'aide de la CLI
Affichage de la liste des configurations
Création d'une sauvegarde de configuration
Restauration à partir d'une configuration enregistrée
Suppression d'une configuration enregistrée
Exportation d'une configuration enregistrée
Importation d'une configuration enregistrée
Affichage des problèmes actifs
Interface de ligne de commande
Affichage de la liste de journaux
Afficher toutes les entrées du journal
Afficher des groupes d'entrées du journal
Affichage des détails d'une entrée
Contexte d'exécution des workflows
Gestion des erreurs des workflows
Validation des entrées des workflows
Audit sur l'exécution de workflows
Rapports sur l'exécution de workflows
Gestion des versions des workflows
Workflows en tant qu'actions d'alerte
Contexte d'exécution des actions d'alerte
Utilisation de workflows programmés
Exemple : sélection du type de périphérique
Les workflows exécutant les actions d'alerte peuvent utiliser la fonction audit pour générer des entrées de journal. Il est recommandé d'utiliser la fonction audit pour ajouter toute information de débogage pertinente au journal d'audit. Le workflow suivant par exemple exécute un basculement lorsqu'il est en état clustérisé, mais audite tout échec de réinitialisation :
var workflow = { name: 'Failover', description: 'Fail the node over to its clustered peer', alert: true, setid: true, execute: function (params) { /* * To failover, we first confirm that clustering is configured * and that we are in the clustered state. We then reboot, * which will force our peer to takeover. Note that we're * being very conservative by only rebooting if in the * AKCS_CLUSTERED state: there are other states in which it * may well be valid to failback (e.g., we are in AKCS_OWNER, * and our peer is AKCS_STRIPPED), but those states may also * indicate aberrent operation, and we therefore refuse to * failback. (Even in an active/passive clustered config, a * FAILBACK should always be performed to transition the * cluster peers from OWNER/STRIPPED to CLUSTERED/CLUSTERED.) */ var uuid = params.uuid; var clustered = 'AKCS_CLUSTERED'; audit('attempting failover in response to alert ' + uuid); try { run('configuration cluster'); } catch (err) { audit('could not get clustered state; aborting'); return; } if ((state = get('state')) != clustered) { audit('state is ' + state + '; aborting'); return; } if ((state = get('peer_state')) != clustered) { audit('peer state is ' + state + '; aborting'); return; } run('cd /'); run('confirm maintenance system reboot'); } };