JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Guide d'administration des systèmes Oracle® ZFS Storage Appliance
Oracle Technology Network
Bibliothque
PDF
Aperu avant impression
Commentaires
search filter icon
search icon

Informations document

Utilisation de la présente documentation

Chapitre 1 Présentation d'Oracle ZFS Storage Appliance

Chapitre 2 Statut

Chapitre 3 Configuration initiale

Chapitre 4 Configuration réseau

Chapitre 5 Configuration de stockage

Chapitre 6 Configuration du réseau de stockage SAN

Chapitre 7 Configuration utilisateur

Chapitre 8 Définition des préférences de ZFSSA

Chapitre 9 Configuration des alertes

Chapitre 10 Configuration de cluster

Chapitre 11 Services ZFSSA

Chapitre 12 Partages, projets et schéma

Chapitre 13 Réplication

Chapitre 14 Migration shadow

Chapitre 15 Ecriture de scripts à l'aide de la CLI

Chapitre 16 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

Exécution d'un audit des workflows

Rapports sur l'exécution des workflows

Gestion des versions

Versions de l'appareil

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

Chapitre 17 Intégration

Index

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