JavaScript is required to for searching.
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

Oracle Technology Network
Bibliothque
PDF
Aperu avant impression
Commentaires
search filter icon
search icon

Informations document

Utilisation de la présente documentation

Chapitre 1 Introduction

Chapitre 2 Maintenance de l'équipement

Chapitre 3 Maintenance du système

Système

Introduction

Disques système

Lots de support

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

Configuration initiale

Réinitialisation des paramètres d'usine

Mises à jour

Mises à jour du système

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

Conditions préalables

Vérifications d'intégrité préalables à la mise à jour

BUI

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

Etapes de résolution des alertes de vérification d'intégrité

Mises à jour différées

Réinitialisation après une mise à jour

Mises à jour de microprogrammes du matériel

Restauration

Restauration de secours

Mise à niveau d'un cluster

Réalisation d'une mise à niveau de cluster

Etats du cluster pendant la mise à niveau

Mise à jour via la BUI

Décompression et vérification du média

Lancement de la mise à niveau

Restauration

Suppression d'un média de mise à jour

Application de mises à jour différées

Mise à jour via la CLI

Décompression et vérification du média

Lancement d'une mise à niveau

Restauration

Suppression d'un média de mise à jour

Application de mises à jour différées (CLI)

Passthrough x

Mise à jour différée Passthrough-x

Quotas d'utilisateurs

Mise à jour différée Quotas d'utilisateurs

COMSTAR

Mise à jour différée COMSTAR

RAID triple parité

Mise à jour différée RAID triple parité

Suppr doublons

Mise à jour différée Suppression des doublons de données

Réplication

Mise à jour différée Réplication

Propriétés reçues

Mise à jour différée Propriétés reçues

Slim ZIL

Introduction

Suppression d'instantanés

Mise à jour différée Suppression d'instantanés

Instantanés récursifs

Mise à jour différée Instantanés récursifs

Remplacement multiple

Mise à jour différée Remplacement multiple

Miroir RAIDZ

Mise à jour différée RAIDZ/Miroir

Répertoire enfant facultatif

Introduction

Groupes d'initiateurs multiples par LUN

Introduction

Support pour les blocs de très grande taille

Support pour les blocs de très grande taille

Réargenture séquentielle

Réargenture séquentielle

Sauvegarde de configuration

Sauvegarde de configuration

Contenu d'une sauvegarde

Impact d'une restauration

Considérations de sécurité

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

Problèmes

Problèmes

Affichage des problèmes actifs

Réparation des problèmes

Fonctionnalités connexes

Journaux

Journaux

Alertes

Erreurs

Système

Audit

Phone Home

BUI

Affichage des journaux

Exportation des journaux

Interface de ligne de commande

Affichage de la liste de journaux

Affichage d'un journal

Afficher toutes les entrées du journal

Afficher des groupes d'entrées du journal

Affichage des détails d'une entrée

Exportation des journaux

Maintenance des workflows

Utilisation des workflows

Contexte d'exécution des workflows

Paramètres des workflows

Paramètres restreints

Paramètres facultatifs

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

Versions d'Appliance

Gestion des versions des workflows

Workflows en tant qu'actions d'alerte

Contexte d'exécution des actions d'alerte

Réalisation d'audits sur les actions d'alerte

Utilisation de workflows programmés

Utilisation de la CLI

Codage du calendrier

Exemple : sélection du type de périphérique

BUI

Interface de ligne de commande

Téléchargement de workflows

Affichage de workflows

Exécution de workflows

Réalisation d'audits sur les actions d'alerte

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');
       }
};