Capítulo 2 Mantenimiento de hardware
Capítulo 3 Mantenimiento del sistema
Gestión de paquetes de asistencia con la BUI
Generación y carga de paquetes de asistencia con la BUI
Opciones de paquetes de asistencia
Gestión de paquetes de asistencia con la CLI
Restablecimiento de configuración de fábrica
Notificación de actualizaciones de software
Programación de notificaciones de software con la BUI
Programación de notificaciones de software con la CLI
Comprobación de actualizaciones con la BUI
Comprobación de actualizaciones con la CLI
Descripción general de la actualización del sistema
Comprobaciones del estado de la actualización
Resolución de fallos en comprobaciones del estado de la actualización
Acciones necesarias para resolver alertas de comprobación del estado
Pasos para resolver alertas de comprobaciones de estado
Reinicio tras una actualización
Actualizaciones de firmware del hardware
Reversión en modo a prueba de fallos
Aplicación de la actualización del cluster
Estados del cluster durante la actualización
Desempaquetado y verificación de medios
Eliminación del medio de actualización
Aplicación de actualizaciones diferidas
Desempaquetado y verificación de medios
Eliminación del medio de actualización
Aplicación de actualizaciones diferidas (CLI)
Actualización diferida de passthrough-x
Actualización diferida de cuotas de usuario
Actualización diferida de COMSTAR
Actualización diferida de RAID de paridad triple
Actualización diferida de anulación de duplicación de datos
Actualización diferida de replicación
Actualización diferida de propiedades recibidas
Actualización diferida de supresión de instantáneas
Actualización diferida de instantáneas recursivas
Actualización diferida de reemplazo múltiple
Actualización diferida de reflejo RAID-Z
Directorio secundario opcional
Varios grupos de iniciadores por LUN
Compatibilidad para bloques de gran tamaño
Compatibilidad para bloques de gran tamaño
Copia de seguridad de configuración
Copia de seguridad de la configuración
Contenido de la copia de seguridad
Gestión de copias de seguridad de configuración con la BUI
Creación de una copia de seguridad de configuración
Restauración de una configuración guardada
Supresión de una configuración guardada
Exportación de una configuración guardada
Importación de una configuración guardada
Gestión de copias de seguridad de configuración con la CLI
Visualización de configuraciones
Creación de una copia de seguridad de configuración
Restauración de una configuración guardada
Supresión de una configuración guardada
Exportación de una configuración guardada
Importación de una configuración guardada
Visualización de problemas activos
Visualización de todas las entradas de log
Visualización de grupos de entradas de log
Visualización de detalles de entradas
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
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'); } };