Ignorer les liens de navigation | |
Quitter la vue de l'impression | |
Guide d'administration des systèmes Oracle® ZFS Storage Appliance, version 2013.1.3.0 |
A propos d'Oracle ZFS Storage Appliance
Configuration d'Oracle ZFS Storage Appliance
Maintenance d'Oracle ZFS Storage Appliance
Présentation des paramètres de workflow
Paramètres de workflow restreints
Paramètres de workflow facultatifs
Gestion des erreurs des workflows
Validation des entrées des workflows
Audits et rapports sur l'exécution des workflows
Présentation de la gestion des versions des workflows
Utilisation de workflows programmés
Utilisation d'un workflow programmé
Codage des calendriers de workflow
Création d'une feuille de travail à partir d'un type de lecteur donné
Téléchargement de workflows à l'aide de la BUI
Téléchargement de workflows à l'aide de la CLI
Création d'une liste de workflows à l'aide de la CLI
Il est possible d'exécuter des workflows en tant qu'alertes. Pour permettre à un workflow de faire office d'action d'alerte, son action alert doit être définie sur true.
Lorsqu'ils sont exécutés en tant qu'actions d'alerte, les workflows prennent l'identité de l'utilisateur qui les a créés. C'est pourquoi le paramètresetid de tout workflow devant pouvoir être utilisé comme action d'alerte doit être défini sur true. Les actions d'alerte ont un paramètre d'objet unique possédant les membres suivants :
|
Le membre items de l'objet de paramètre possède les membres suivants :
|
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 :
Exemple 4-9 Audit d'un échec de réinitialisation par un workflowLe 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'); } };