Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
![]() |
Guía de administración de Oracle® ZFS Storage Appliance |
Capítulo 1 Descripción general de Oracle ZFS Storage Appliance
Capítulo 3 Configuración inicial
Capítulo 4 Configuración de red
Capítulo 5 Configuración del almacenamiento
Capítulo 6 Configuración de red de área de almacenamiento
Capítulo 7 Configuración de usuario
Capítulo 8 Configuración de preferencias de dispositivos ZFSSA
Capítulo 9 Configuración de alertas
Capítulo 10 Configuración de cluster
Capítulo 11 Servicios del dispositivo ZFSSA
Capítulo 12 Recursos compartidos, proyectos y esquemas
Capítulo 15 Secuencias de comandos de la CLI
Capítulo 16 Flujos de trabajo de mantenimiento
Contexto de ejecución de flujos de trabajo
Parámetros de flujos de trabajo
Manejo de errores de flujo de trabajo
Validación de entradas de flujo de trabajo
Auditoría de ejecución de flujos de trabajo
Generación de informes de ejecución de flujos de trabajo
Control de versiones de dispositivo
Control de versiones de flujos de trabajo
Flujos de trabajo como acciones de alerta
Contexto de ejecución de las acciones de alerta
Uso de flujos de trabajo programados
Ejemplo: selección de tipo de dispositivo
Visualización de flujos de trabajo
Los flujos de trabajo que se ejecutan como acciones de alerta pueden utilizar la función audit para generar entradas de log de auditoría. Se recomienda generar toda la información de depuración relevante para el log de auditoría mediante la función audit. Por ejemplo, en el siguiente flujo de trabajo, se ejecuta el failover si se tiene el estado de cluster, pero se realiza una auditoría de los fallos que puedan producirse al reiniciar:
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'); } };